EAST-ADL Introduction. EAST-ADL Overview

Size: px
Start display at page:

Download "EAST-ADL Introduction. EAST-ADL Overview"

Transcription

1 EAST-ADL Introduction EAST-ADL Overview

2 Background Increasing Complexity and Criticality of Vehicle Electronics Errors due to engineering flaws are a major threat to Safety Improved Engineering Methods are Necessary Standardization of ontology and specifications Approach: System Modelling based on EAST-ADL AUTOSAR EAST-EEA, ATESST,TIMMO, MAENAD, etc

3 Background Capture Specifications of Automotive Electronic Systems Architecture Description Language An information model that captures engineering information in EAST-ADL a standardized Introduction: Overview way

4 Why Collaborative Research? Enable long-term, pro-active work Leverage of company effort through collaborative work Reaching common approach in the automotive industry Influence Research Community to address automotive needs Influence other Research Projects to address automotive needs Exchange of experience - suppliers, OEMs and institiutes

5 Why EAST-ADL? Background System complexity is increasing Lead times are reduced Criticality is increasing Quality is at stake Safety is at stake ISO26262 Standardization of specification means = EAST-ADL Collaborate on tools Collaborate on methods Exchange models, not documents

6 EAST-ADL Related Projects ADAMS EDONA TIMMO2 SAFE CESAR TIMMO EAST-EEA ATESST ATESST2 MAENAD AUTOSAR JASPAR EAST-ADL Association EEA AIL UML2 Titus SYSML AADL UML2 SYSML AADL AUTOSAR EAST-ADL EAST-ADL EAST-ADL2 EAST-ADL 2.1 EAST-ADL 2.x Models Meeting Automotive Design Challenges. Henrik Lönn, Volvo Technology 6

7 EAST-ADL Related Projects ATESST: Refining EAST-ADL language, profile, methodology, tools ADAMS: Promoting MARTE UML2 profile and EAST-ADL as UML solution CESAR: EAST-ADL is input to Reference Technology Platform TIMMO: Timing model for AUTOSAR and EAST-ADL EDONA: Deployment of AUTOSAR and EAST-ADL MeMVaTex: Requirements modelling for EAST-ADL MAENAD: Refining EAST-ADL language, profile, methodology, tools TIMMO2: Timing model for AUTOSAR and EAST-ADL, focus on deployment SAFE: Safe Automotive software architecture, ISO26262 Support MBAT: Model-based analysis and test

8 EAST-ADL Contributors AUDI AG BMW AG Carmeq GmbH CRF Daimler AG ETAS GmbH Mecel AB Mentor Graphics OPEL GmbH PSA Renault Robert Bosch GmbH Siemens, Continental Valeo Vector Volvo Car Corporation Volvo Technology AB ZF CEA-LIST INRIA LORIA Paderborn Univerisity-C-LAB TU of Darmstadt Technische Universität Berlin The Royal Institute of Technology The University of Hull

9 EAST-ADL Association Non-profit, non-governmental organization Assist and promote the development and application of the EAST-ADL. The EAST-ADL Association will stipulate the content of new versions of the EAST-ADL language. The EAST-ADL Association has no fees or funds, and each member carry any costs for contributing. Membership is open to individuals and organizations 50 members: OEMs, Suppliers, Tool Vendors, Institutes, Academia Models Meeting Automotive Design Challenges. Henrik Lönn, Volvo Technology 9

10 Approach EAST-ADL provides means to represent the embedded system in several abstraction levels Different kinds of engineering information Feature content Functional content Software architecture (AUTOSAR) Requirements Vehicle Level Variability Analysis Level Safety information V&V Information Design Level Behavior Implementation Level Traceability is supported Analysis and synthesis Document generation and views Brake

11 Re-Inventing the Wheel? Why not UML? The EAST-ADL profile allows usage of UML Why not SysML? EAST-ADL is based on applicable SysML concepts Why not Autosar? EAST-ADL Complements Autosar Why not proven proprietary tools? EAST-ADL integrates external tools and provides an information structure for the engineering data regardless of tool Why not proven open scientific/academic approaches? EAST-ADL integrates relevant approaches Various Technologies are integrated

12 Environment Model Requirements Variability Timing Dependability EAST-ADL+AUTOSAR Representation SystemModel VehicleLevel TechnicalFeatureModel AnalysisLevel FunctionalAnalysisArchitecture Features of the vehicle Abstract functions Chassis Extensions Steer Brake Cruise TechnicalFeatureModel <<AnalysisArchitecture>> DemonstratorAA <<FunctionalAnalysisArchitecture>> DemoFAA <<FunctionalDevice>> BrakePedal VehicleSpeed <<ADLFunction>> <<ADLFunction>> AbstractABSFrontLeft <<FunctionalDevice>> BrakeAlgorithm BrakeFrontLeft <<FunctionalDevice>> WheelSensorFrontLeft DesignLevel FunctionalDesignArchitecture HardwareDesignArchitecture Hardware topology, concrete functions, allocation to nodes FunctionalDesignArchitecture <<LocalDeviceManager>> <<BSWFunction>> BrakePedal PedalIO VehicleSpeed <<DesignFunction>> <<DesignFunction>> <<LocalDeviceManager>> <<BSWFunction>> ABSFrontLeft BrakeController BrakeActuatorFL BrakeIO <<LocalDeviceManager>> <<BSWFunction>> WheelSensorFL WSensIO <<Sensor>> <<ECUNode>> Pedal PedalNode HardwareDesignArchitecture <<ECUNoder>> WheelNode <<HWFunction>> BrakePedal <<HWFunction>> BrakeFrontLeft <<HWFunction>> WheelSensorFrontLeft <<Actuator>> Brake ImplementationLevel AUTOSAR Application SW AUTOSAR Basic AUTOSAR Software SW Architecture HW as represented Data exchange over ports by AUTOSAR Allocation SWComposition <<SensorSWC>> BrakePedal VehicleSpeed <<SWC>> <<SWC>> ABSFrontLeft BaseBrake <<LocalDeviceManager>> WheelSensorFL <<Realize>> <<ActuatorSWC>> Brake

13 Analysis Level Vehicle Level EAST-ADL Abstraction Levels TechnicalFeatureModel ExampleFeatureTree DoorLock BaseBrake WheelSpeed Sensor Wheel Speed Brake WheelCtrl BrakeForce Brake Actuator Brake Request Brake Pedal PedalBrk Request Brake Controller Lock Button Vehicle SpeedSensor Lock Request Vehicle Speed Lock Controller Lock Activation Lock Actuator

14 Analysis Level Vehicle Level EAST-ADL Abstraction Levels TechnicalFeatureModel ExampleFeatureTree DoorLock BaseBrake Realization relations ABS BrakeLight FunctionalAnalysisArchitecture Lock Button LockRequest Vehicle SpeedCalc Vehicle Speed Lock Controller Lock Activation Lock Actuator WheelSpeed Sensor Brake Pedal WheelSpeed PedalBrk Request Brake Controller Brake Request Brake WheelCtrl BrakeForce Brake Actuator

15 Vehicle Level Characterization of Vehicle by a means of Features Stakeholder requested functional or non-functional characteristics Describes "what", but shall not fix the "how" Specified by requirements and use cases Configuration points to create a vehicle variant ProductFeatureModels for Configuration of TechnicalFeatureModel

16 Analysis Level Abstract Functional description of the EE system Realizes functionality based on the features and requirements Abstract functional definition avoiding implementation details Defines the system boundary Environment model defines context Basis for abstract safety analysis

17 Design Level Concrete functional definition Functional definition of application software Functional abstraction of hardware and middleware Hardware architecture Function-to-hardware allocation No SW Architecture

18 Function interaction end-to-end <<LocalDeviceManager>> BrakePedal <<DesignFunction>> BrakeController VehicleSpeed <<LocalDeviceManager>> WheelSensorFL <<FunctionalDesignArchitecture>> DemonstratorFDA Application Functionality <<DesignFunction>> ABSFrontLeft <<LocalDeviceManager>> BrakeActuatorFL BSW Functionality <<BSWFunction>> PedalIO <<BSWFunction>> BrakeIO <<BSWFunction>> WSensIO HW Functionality <<HWFunction>> PedalSensor <<HWFunction>> BrakeActuatorFrontLeft <<HWFunction>> WheelSensorFrontLeft PedalAngle BrakeForce WheelSpeedFL <<EnvironmentModel>> DemonstratorEM <AnalysisFunction>> BrakePlantModel Model structure supports interaction with the environment and end-to-end functional definitions

19 Implementation Level Software-based implementation of the system AUTOSAR Software components represent application functionality AUTOSAR Basic software represents platform ECU specifications and topology represent hardware Model is captured in AUTOSAR Software component template ECU resource template System Template

20 Environment Model Requirements Variability Timing Dependability EAST-ADL Extensions SystemModel Extensions VehicleLevel TechnicalFeatureModel AnalysisLevel FunctionalAnalysisArchitecture DesignLevel FunctionalDesignArchitecture HardwareDesignArchitecture ImplementationLevel AUTOSAR Application SW AUTOSAR Basic SW AUTOSAR HW Data exchange over ports Allocation

21 Environment Model Requirements Variability Timing Dependability EAST-ADL Extensions SystemModel VehicleLevel TechnicalFeatureModel Extensions AnalysisLevel FunctionalAnalysisArchitecture DesignLevel FunctionalDesignArchitecture HardwareDesignArchitecture ImplementationLevel AUTOSAR Application SW AUTOSAR Basic SW AUTOSAR HW Data exchange over ports Allocation

22 EAST-ADL Extensions: Summary Constructs for requirements, safety, variability, timing, environment, etc. represents extensions Extensions are organized according to abstraction level Extensions reference the structural core Language may be supported in steps UML Profile Application can be modular Language annexes can be added Changes in one annex does not affect rest Extensions can be applied to AUTOSAR

23 Model Definition and Exchange UML2 Model with EAST-ADL Profile (and MARTE, ) EAST-ADL XML

24 Language Definition Metamodel defined in Enterprise Architect Documentation autogenerated from model Exchange format autogenerated using AUTOSAR rules AUTOSAR elements can be integrated

25 Conclusion EAST-ADL supports automotive embedded systems modelling starting with needs and requirements and ending with an AUTOSAR SW architecture An agreed modelling language makes it possible to understand engineering information from other departments/disciplines and companies to exchange engineering models between different organizations to progress jointly on tools and methodology for modelling, analysis and synthesis

26 Ongoing Activities MAENAD: Extends EAST-ADL for Fully Electrical Vehicle Needs TIMMO2-USE: Timing annotations, methodology and algorithms for AUTOSAR and EAST-ADL SAFE: Model Based support for ISO26262 CESAR: Multi-domain, cost efficient and safe development of embedded systems MBAT: Model-based analysis and test