EAST-ADL Introduction: Overview

Transcription

1 EAST-ADL Introduction: 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 EAST-ADL Introduction 2

3 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 EAST-ADL Introduction 3

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

5 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 Technical University of Darmstadt Technische Universität Berlin The Royal Institute of Technology The University of Hull EAST-ADL Introduction 5

6 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 EAST-ADL Introduction 6

7 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 Variability Safety information V&V Information Behavior Traceability is supported Analysis and synthesis Document generation and views Vehicle Analysis Design Implementation EAST-ADL Introduction 7

8 Relation to other approaches Why Not UML? EAST-ADL is domain-specific but its UML2 profile gives access to UML2 tools. Why not SysML? EAST-ADL takes up applicable SysML concepts but provides additional domain-specific support Why not Autosar? EAST-ADL complements Autosar with respect to feature content, functional structure, safety properties, etc. Why not AADL AADL represent the software implementation of a system while EAST-ADL starts on a more abstract level. Why not proprietary tools (Simulink, Statemate, Modelica, ASCET, )? EAST-ADL is integration structure and supports use of established tools EAST-ADL Introduction 8

9 EAST-ADL Abstraction s TechnicalFeatureModel Features of the vehicle Chassis Steer Cruise Vehicle Analysis Design Abstract functions <<ADLFunction>> Algorithm <<AnalysisArchitecture>> DemonstratorAA <<FunctionalAnalysisArchitecture>> DemoFAA <<FunctionalDevice>> Pedal VehicleSpeed <<ADLFunction>> AbstractABSFrontLeft <<FunctionalDevice>> FrontLeft <<FunctionalDevice>> WheelSensorFrontLeft Implementation Hardware topology, concrete functions, allocation to nodes FunctionalDesignArchitecture <<LocalDeviceManager>> <<BSWFunction>> Pedal PedalIO VehicleSpeed <<DesignFunction>> <<DesignFunction>> <<LocalDeviceManager>> <<BSWFunction>> ABSFrontLeft Controller ActuatorFL IO <<LocalDeviceManager>> <<BSWFunction>> WheelSensorFL WSensIO <<Sensor>> <<ECUNode>> Pedal PedalNode HardwareDesignArchitecture <<ECUNoder>> WheelNode <<HWFunction>> Pedal <<HWFunction>> FrontLeft <<HWFunction>> WheelSensorFrontLeft <<Actuator>> Software Architecture as represented by AUTOSAR SWComposition <<SensorSWC>> Pedal VehicleSpeed <<SWC>> <<SWC>> ABSFrontLeft Base <<LocalDeviceManager>> WheelSensorFL <<ActuatorSWC>> EAST-ADL Introduction 9

10 EAST-ADL Abstraction s TechnicalFeatureModel DoorLock ExampleFeatureTree Base Vehicle WheelSpeed Sensor Pedal Wheel Speed PedalBrk Request WheelCtrl Request Controller Force Actuator Lock Button Vehicle SpeedSensor Lock Request Vehicle Speed Lock Controller Lock Activation Singular Functions Lock Actuator Analysis EAST-ADL Introduction 10

11 EAST-ADL Abstraction s TechnicalFeatureModel WheelSpeed Sensor Pedal DoorLock Lock Button Realization relations LockRequest WheelSpeed PedalBrk Request ExampleFeatureTree FunctionalAnalysisArchitecture Vehicle SpeedCalc Controller Vehicle Speed Request ABS Lock Controller WheelCtrl Base Light Lock Activation Force Integrated Functions Lock Actuator Actuator Vehicle Analysis EAST-ADL Introduction 11

12 Vehicle 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 EAST-ADL Introduction 12

13 Analysis 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 define context Basis for abstract safety analysis EAST-ADL Introduction 13

14 Design Concrete functional definition Functional definition of application software Functional abstraction of hardware and middleware Hardware architecture Function-to-hardware allocation No SW Architecture EAST-ADL Introduction 14

15 Function interaction end-to-end <<LocalDeviceManager>> Pedal <<DesignFunction>> Controller VehicleSpeed <<LocalDeviceManager>> WheelSensorFL <<FunctionalDesignArchitecture>> DemonstratorFDA Application Functionality <<DesignFunction>> ABSFrontLeft <<LocalDeviceManager>> ActuatorFL BSW Functionality <<BSWFunction>> PedalIO <<BSWFunction>> IO <<BSWFunction>> WSensIO HW Functionality <<HWFunction>> PedalSensor <<HWFunction>> ActuatorFrontLeft <<HWFunction>> WheelSensorFrontLeft PedalAngle Force WheelSpeedFL <<EnvironmentModel>> DemonstratorEM <AnalysisFunction>> PlantModel Model structure supports interaction with the environment and end-to-end functional definitions EAST-ADL Introduction 15

16 Implementation 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 EAST-ADL Introduction 16

17 Extensions Constructs for requirements, safety, variability, timing, environment, etc. represents extensions Extensions are organized according to abstraction level SystemModel Vehicle TechnicalFeatureModel Vehicle Extensions reference the structural core Analysis FunctionalAnalysisArchitecture Design Functional Design Architecture Hardware Design Architecture Analysis Design Implementation AUTOSAR System Requirements Dependability Variability Implementation Operational EAST-ADL Introduction 17

18 EAST-ADL Metamodel Structure Vehicle SystemModel Vehicle TechnicalFeatureModel Extensions Analysis Design Environment Model Analysis FunctionalAnalysisArchitecture Design FunctionalDesignArchitecture HardwareDesignArchitecture Requirements Variability Timing Dependability Implementation Implementation AUTOSAR Application SW AUTOSAR Basic SW AUTOSAR HW Data exchange over ports Allocation EAST-ADL Introduction 18

19 EAST-ADL Metamodel Structure Language may be supported in steps UML Profile Application can be modular Language annexes can be added Vehicle Analysis Design Implementation Environment Model SystemModel Vehicle TechnicalFeatureModel Analysis FunctionalAnalysisArchitecture Design FunctionalDesignArchitecture HardwareDesignArchitecture Implementation AUTOSAR Application SW AUTOSAR Basic SW AUTOSAR HW Extensions Requirements Variability Timing Dependability Changes in one annex does not affect rest Extensions can be applied to AUTOSAR EAST-ADL Introduction 19

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

21 Language Definition Metamodel defined in Enterprise Architect Documentation autogenerated from model Exchange format autogenerated using AUTOSAR rules AUTOSAR elements can be integrated EAST-ADL Introduction 21

22 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 EAST-ADL Introduction 22

23 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