EAST-ADL Introduction EAST-ADL Overview 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. 2003 2004 2005 2006 2007 2008 2009 2010 EAST-ADL Introduction: Overview Background Capture Specifications of Automotive Electronic Systems Architecture Description Language An information model that captures engineering information inEAST a- ADLstandardized Introduction: Overview way 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: Overview 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 EAST-ADL Introduction: Overview EAST-ADL ADAMS TIMMO2 EDONA Related Projects SAFE CESAR TIMMO EAST-EEA ATESST ATESST2 MAENAD AUTOSAR JASPAR EAST-ADL Association 2005 2010 2000 UML2 EEA AIL SYSML UML2 AADL Titus AUTOSAR SYSML EAST-ADL AADL EAST-ADL EAST-ADL2 EAST-ADL 2.1 EAST-ADL 2.x EAST-ADL Introduction: Overview 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 … EAST-ADL Introduction: Overview EAST-ADL Contributors 2000-2010 AUDI AG Vector BMW AG Volvo Car Corporation Carmeq GmbH Volvo Technology AB CRF ZF Daimler AG CEA-LIST ETAS GmbH INRIA Mecel AB LORIA Mentor Graphics Paderborn Univerisity-C-LAB OPEL GmbH TU of Darmstadt PSA Technische Universität Berlin Renault The Royal Institute of Robert Bosch GmbH Technology Siemens, Continental The University of Hull Valeo … EAST-ADL Introduction: Overview 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 EAST-ADL Introduction: Overview 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 EAST-ADL Introduction: Overview are integrated EAST-ADL+AUTOSAR Representation TechnicalFeatureModel Features SystemModel ExtensionsChassis … of the vehicle Steer Brake Cruise VehicleLevel TechnicalFeatureModel <<AnalysisArchitecture>> DemonstratorAA <<FunctionalAnalysisArchitecture>> DemoFAA <<FunctionalDevice>> BrakePedal VehicleSpeed Abstract <<ADLFunction>> <<ADLFunction>> AbstractABSFrontLeft <<FunctionalDevice>> BrakeAlgorithm BrakeFrontLeft AnalysisLevel <<FunctionalDevice>> functions WheelSensorFrontLeft FunctionalAnalysisArchitecture FunctionalDesignArchitecture <<LocalDeviceManagerTiming >> <<BSWFunction>> <<HWFunction>> BrakePedal PedalIO BrakePedal DesignLevel Hardware topology, VehicleSpeed Requirements Requirements Variability <<DesignFunction>> <<DesignFunction>> <<LocalDeviceManager>> <<BSWFunction>> <<HWFunction>> Dependability ABSFrontLeft BrakeController BrakeActuatorFL BrakeIO BrakeFrontLeft Environment Model Environment FunctionalDesignArchitecture concrete functions, <<LocalDeviceManager>> <<BSWFunction>> <<HWFunction>> WheelSensorFL WSensIO WheelSensorFrontLeft HardwareDesignArchitecture <<Sensor>> <<ECUNode>> HardwareDesignArchitecture <<ECUNoder>> <<Actuator>> Pedal allocation to nodes PedalNode WheelNode Brake ImplementationLevel AUTOSAR AUTOSAR Basic AUTOSAR <<Realize>> Application SW SW HW Software Architecture SWComposition <<SensorSWC>> BrakePedal VehicleSpeed as represented <<SWC>> <<SWC>> <<ActuatorSWC>> ABSFrontLeft BaseBrake Brake Data exchange over portsby AUTOSARAllocation <<LocalDeviceManager>> WheelSensorFL EAST-ADL Introduction: Overview EAST-ADL Abstraction Levels TechnicalFeatureModel ExampleFeatureTree DoorLock BaseBrake Vehicle Level Vehicle Wheel Brake Brake WheelSpeed Speed BrakeForce WheelCtrl Actuator Sensor Brake Request Lock Lock Brake Button Brake PedalBrk Request Controller Lock Lock Pedal Request Lock Controller Activation Actuator Level Analysis Vehicle Vehicle Speed SpeedSensor EAST-ADL Introduction: Overview EAST-ADL Abstraction Levels TechnicalFeatureModel ExampleFeatureTree DoorLock BaseBrake ABS BrakeLight Level Vehicle Realization relations FunctionalAnalysisArchitecture Lock Lock LockRequest Lock Lock Button Activation Vehicle Controller Actuator Vehicle Speed SpeedCalc WheelSpeed WheelSpeed Sensor Brake BrakeForce Brake Brake WheelCtrl Actuator Level Analysis Brake Request Brake PedalBrk Controller Pedal Request EAST-ADL Introduction: Overview 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 EAST-ADL Introduction: Overview 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 EAST-ADL Introduction: Overview 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 EAST-ADL Introduction: Overview Function interaction – end-to-end <<FunctionalDesignArchitecture>> DemonstratorFDA Application Functionality BSW Functionality HW Functionality PedalAngle <<LocalDeviceManager>> <<BSWFunction>> <<HWFunction>> BrakePedal PedalIO PedalSensor >> DemonstratorEM >> VehicleSpeed Model <<DesignFunction>> <<LocalDeviceManager>> <<BSWFunction>> <<HWFunction>> BrakeForce <<DesignFunction>> ABSFrontLeft BrakeController BrakeActuatorFL BrakeIO BrakeActuatorFrontLeft BrakePlant AnalysisFunction < <<LocalDeviceManager>> <<BSWFunction>> <<HWFunction>> WheelSensorFL WSensIO WheelSensorFrontLeft WheelSpeedFL EnvironmentModel << Model structure supports interaction with the environment and end-to-end functional definitions EAST-ADL Introduction: Overview 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 EAST-ADL Introduction: Overview EAST-ADL Extensions SystemModel Extensions … VehicleLevel TechnicalFeatureModel AnalysisLevel FunctionalAnalysisArchitecture Timing DesignLevel Requirements Requirements Variability Dependability Environment Model Environment FunctionalDesignArchitecture HardwareDesignArchitecture ImplementationLevel AUTOSAR AUTOSAR Basic AUTOSAR Application SW SW HW Data exchange over ports Allocation EAST-ADL Introduction: Overview EAST-ADL Extensions SystemModel Extensions … VehicleLevel § TechnicalFeatureModel § § AnalysisLevel § FunctionalAnalysisArchitecture § § Timing DesignLevel Requirements Requirements Variability Dependability § Environment Model Environment FunctionalDesignArchitecture § § HardwareDesignArchitecture § § ImplementationLevel § AUTOSAR AUTOSAR Basic AUTOSAR Application SW SW HW Data exchange over ports Allocation EAST-ADL Introduction: Overview 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 EAST-ADL Introduction: Overview Model Definition and Exchange UML2 Model with EAST-ADL Profile (and MARTE, …) EAST-ADL XML EAST-ADL Introduction: Overview 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: Overview 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: Overview .