The AUTOSAR Way of Model-Based Engineering of Automotive Systems

Transcription

1 The Way of Model-Based Engineering of Automotive Systems Heiko Dörr International Conference on Graph Transformation Leicester, Purpose of the Presentation. Long history of graph transformation Sound body of theory Several areas of application Tool-support available to handle larger models Future model-based engineering of automotive systems will use Explore potentials of of the application of of graph transformation in in an an development - - Folie 2 Identification of of research and development topics 1

2 1 1 ECU s ECU I RTE 3 Basic Software 2 3 Virtual Functional Bus Tool supporting deployment of SW components 2 ECU II RTE Basic Software Gateway n System Constraint ECU m n RTE Basic Software Content. 1 Automotive System System Engineering 2 3 Methodology of of Standardization System System Development 4 R&D R&D Topics Topics... Architecture s Methodology Methodology Folie 3 Automotive Systems and SW Engineering 4 2

3 Automotive Open System Architecture Cooperate on standards compete on implementation Non functional legal requirements Vehicle family management Resource efficiency Driver assistance Driving dynamics Safety functions (active/passive) Comfort functions 5 Managing Complexity by Exchangeability and Reuse of Software Components OEM a OEM b Platform b.1 Platform b.2 Platform b.n Exchangeability between supplier s solutions OEM c Platform a.1 Platform a.2 Platform a.n Exchangeability between manufacturer s applications OEM f Supplier A Chassis Safety Body/Comfort Multimedia OEM e Supplier B Chassis Safety Telematics Multimedia Supplier C Body/Comfort Powertrain Telematics Multimedia Platform c.1 Platform c.2 Platform c.n OEM d Platform d.1 Platform d.2 Platform d.n Platform f.1 Platform f.2 Platform f.n Platform e.1 Platform e.2 Platform e.n Exchangeability between vehicle platforms 6 3

4 Model-based Development. General Task. Driver W* Demand Sensors W R Measurement Control U Actuators Y Vehicle X Plant Z Environment W (Electronic) Control Unit U R Control Unit - - Folie 7 W R Input Decoder W INT R INT Microcontroller U INT Power / Communi cation Control U MbE-Slides by M. Conrad, Abb: Schäuffele/Zurawka: Automotive Software Engineering; Foto: images/ecu.jpg Model-based Development. Paradigm Shift. Document based development process Idea Model based development process Micro controller W INT R INT A/D converter A/D converter W DIS R DIS Software U DIS D/A converter U INT - - Folie 8 Software component for computation of control functions MbE-Slides by M. Conrad 4

5 Model-based Development. Evolution of Models. Requirements / Behavioral model of system Idea t Physical model Implementation model Autocode Micro controller *.c *.h - - Folie 9 W INT R INT A/D converter A/D converter W DIS R DIS Software U DIS D/A converter U INT MbE-Slides by M. Conrad Use case Front-Light Management SwitchEvent check_switch () switch_event (event) Int. LightRequest switch_event(event) request_light (type, mode) Front-Light Manager request_light(type, mode) get_keyposition() set_light(type, mode) RTE Headlight set_light(type, mode) set_current ( ) ECU1 Operating System Std. Services Std. Operating System Control Memory Management Drivers Std. Hardware ECU Std. DIO PWM CAN Driver Microcontroller Complex Device Drivers 10 5

6 Use case Front-Light Management Exchange of type of front-light SwitchEvent check_switch () switch_event (event) Int. LightRequest switch_event(even t) request_light (type, mode) Front-Light Manager request_light(type, mode) get_keyposition() set_light(type, mode) RTE Xenonlight Headlight set_light(type, mode) set_current ( ) ECU2 Operating System Std. Services Std. Operating System Control Memory Management Drivers Std. Hardware ECU Std. DIO PWM DIO CAN Driver Microcontroller Complex Device Drivers 11 Distribution on ECUs SwitchEvent check_switch () switch_event (event) LightRequest switch_event(even t) request_light (type, mode) Front-Light Manager request_light(type, mode) get_keyposition() set_light(type, mode) Xenonlight set_light(type, mode) set_current ( ) Int. RTE Operating System Std. Services Std. DIO Std. PWM DIO Microcontroller ECU-Hardware ECU Std. CAN Driver Complex Device Drivers 12 6

7 Use case Front-Light Management Multiple ECUs SwitchEvent check_switch () switch_event (event) Int. LightRequest switch_event(event) request_light (type, mode) RTE ECU3 Front-Light Manager request_light(type, mode) get_keyposition() set_light(type, mode) ECU4 RTE Xenonlight set_light(type, mode) set_current ( ) ECU5 RTE Std. Services Std. Operating System Control ECU Memory Management Std. Drivers Hardware Microcontroller ECU-Hardware Std. DIO CAN Driver Operating System Cont. Memory Management CAN Driver Std. Drivers Hardware Microcontroller ECU-Hardware Operating System Std. Microcontroller ECU-Hardware Cont. ECU Memory Management Drivers Hardware Std. CAN Driver PWM CAN Bus 13 Standardization 14 7

8 Core Partners and Members Status: 13th March Core Partner 6 Development Member 52 Premium Member 67 Associate Member General OEM Generic Tier 1 Standard Software Tools and Services Semiconductors Up-to-date status see: 15 Project Objectives and Main Working Topics Implementation and standardization of basic system functions as an OEM wide Standard Core solution Scalability to different vehicle and platform variants Transferability of functions throughout network Integration of functional modules from multiple suppliers s Architecture Methodology Maintainability throughout the whole Product Life Cycle Increased use of Commercial off the shelf hardware Software updates and upgrades over vehicle lifetime Consideration of availability and safety requirements 16 8

9 Main Working Topics Architecture s Methodology Architecture s Methodology Architecture: Software architecture including a complete basic or environmental software stack for ECUs the so called Basic Software as an integration platform for hardware independent software applications. Methodology: Exchange formats or description templates to enable a seamless configuration process of the basic software stack and the integration of application software in ECUs and it includes even the methodology how to use this framework. Architecture s Methodology s: Specification of interfaces of typical automotive applications from all domains in terms of syntax and semantics, which should serve as a standard for application software. 17 Main Concepts: Architecture Basic Software modules Run time environment and communication 18 9

10 ECU Software Architecture Software (ASW) Standardization of interfaces Not standardized in Basic Software (BSW) +RTE Standardization of interfaces and behavior Objectives: Basic SW: Decoupling of Hardware and Software SW: Relocation / Reuse of omponents between ECUs 19 Basic Software Modules Layer Runtime Environment (RTE) System Services Memory Services I/O Hardware ECU State Manager Function Inhibition Manager FIM Diagnostic Event Manager DEM Watchdog Manager Manager Development Error Tracer Services NVRAM Manager IPDU Multiplexer DCM Diagnostic COM Com. Manager PDU Router LIN CAN FlexRay TP TP TP CAN SM LIN SM FR SM Generic NM Interf. CAN NM FlexRay NM I/O Hardware Onboard Device Memory Hardware Hardware OS BSW Scheduler CRC Lib Flash Check Watchdog External Watchdog Driver Microcontroller Drivers Watchdog Driver MCU Driver GPT Driver Memory EEPROM Ext. EEPROM Driver RAM Test Memory Drivers internal EEPROM Driver Flash EEPROM Emulation Ext. Flash Driver internal Flash Driver SPI Handler Driver LIN LIN Stack Drivers LIN Driver CAN CAN transc Driver Ext. CAN Driver CAN Driver FR FR transc Driver Ext. FR Driver FR Driver ICU Driver I/O Drivers DIO Driver ADC Driver PWM Driver PORT Driver Microcontroller GPT MCU Power & Clock Unit WDT Ext. BUS EEPROM FLASH SPI SCI LIN CAN FlexRay CCU PWM ADC DIO e.g. TPU µc e.g. PCP e.g. CCU 20 10

11 Intra- and Inter-ECU BSW VFB ECU II RTE BSW Ports implement the interface according to the communication paradigm (here client-server based). Ports are the interaction ECU I points of a component. The communication is A channeled via the RTE. The communication layer in the basic software is encapsulated and not RTE visible at the application layer. B C Ports Infrastructure Sensor Hardware Bus Path 21 Architecture Conclusion harmonizes already existing basic software solutions and closes gaps for a seamless basic software architecture. aims at finding the best solution for each requirement and not finding the highest common multiple. The decomposition of the layered architecture into some 40 modules has proven to be functional and complete

12 Main Concepts: s Standardization approach Current stage of standardization 23 s Software Component Actuator Software Component Sensor Software Component Software... Runtime Environment (RTE) Software Component Layer Operating System Services Semantics of s: Physical properties, units, etc. Supporting Basic re-use Software across product Microcontroller lines In scope of work packages specifying application interfaces ECU-Hardware Syntax of s: Meta-model, Software Component Template Supporting transferability within the network ECU Complex Device Drivers 24 12

13 To ease the re-use of software components across several OEMs, proceeds on the standardization of the application interfaces agreed among the partners. 2nd Yaw Rate Controller Example Base Sensor Signals Ínterface of ESP and external yaw rate controller I 6 System-level Brake Actuator I 7 ESP-Sensors I 1 ESP omponent Brake Actuator of ESP and VLC I 4 I 2 I 3 I 5 Vehicle Longitudinal Controller Standard Signals from ESP Information signals from other functions / domains Command signals to other functions / domains application interfaces on system level (ESP-system, chassis domain) Data Type Name Data Type Name Data Type Integer Range Physical Range Physical Offset Unit Remarks Data Type Name LongAccBase YawRateBase Yaw rate measured along vehicle z- axis (i.e. compensated for orientation). Coordinate system according to ISO 8855 S , , rad/sec. This data element can also be used to instantiate a redundant sensor interface. Range might have to be extended for future applications (passive safety). RollRateBase 25 Major task: Conflict Resolution Example Vehicle Speed Body Domain CentralLockingMaster InteriorLight DriverReq VehicleSpeed Powertrain Domain ActualVehicleSpeed? DataElement Name value DataType t_vehiculespeed DataElement Name DataType ActualVehicleSpeed VehicleSpeed Min Bit size; Res; phys low; phys up; Unit Uint km/h OK Min Bit; size; Res; phys low; phys up; Unit Uint km/h OK CentralLockingMaster ESP VehicleLongSpeed Chassis Domain ACC SSM EPB VLC ActualVehicleSpeed Steering Suspension DataElement Name DataType VehicleLongSpeed VehicleLongitudinalSpeed Min Bit; size; Res; phys low; phys up; Unit????????????? 26 13

14 s Conclusion 1 2 For several domains a subset of application interfaces has been standardized to agreed levels. It is a challenge to align standardization with the pace of application development. 27 Main Concepts: Methodology Overall methodology Structure of configuration information System Design Implementation Process 28 14

15 Following the Methodology, the E/E architecture is derived from the formal description of software and hardware components n Virtual Functional Bus Tool supporting deployment of SW components ECU System Constraint s ECU I ECU II ECU m n Functional software is described formally in terms of Software Components (). Using Software Component s as input, the Virtual Functional Bus validates the interaction of all components and interfaces before software implementation. Mapping of Software Components to ECUs and configuration of basic software. The Methodology supports the generation of an E/E architecture. RTE Basic Software RTE Basic Software RTE Basic Software Gateway 29 Methodology Derive E/E architecture from formal descriptions of soft- and hardware components VFB view n description templates for application software components (interfaces and BSW requirements) ECU s Virtual Functional Bus System Constraint exchange formats and methodology for component, ECU, and system level Tool supporting deployment of SW components Mapping 1 ECU I RTE Basic Software 3 ECU II 2 RTE Basic Software... ECU m n RTE Basic Software Tools for - support of component mapping - generation of RTE, i.e. inter- and intra ECU communication Basic Software (BSW) architecture, detailed specifications for implementation and configuration of BSW Gateway 30 15

16 To configure the system, input descriptions of all software components, ECU resources and system constraints are necessary. Example ECUs Software Components SwitchEval ECU Resource Supported protocols: CAN, LIN, FlexRay LIN ECU Resource BC-V CAN ECU Resource SMLS BC-H System omponent BlinkInputModule omponent BlinkMaster omponent LightActuatorsControl omponent LightSourceSetting SwitchEval BlinkInputModule BlinkMaster LightActuatorsControl LightSourceSetting LM-L LM-R omponent 31 The system configuration maps software components to ECUs and links interface connections to bus signals. Example System Configuration SWCMappingDefs DataMappingDefs BlinkRequest SwitchEval BlinkInputModule Blink Input Module Blink Master BlinkMaster LightActuatorsControl LightSourceSetting Comm.Matrix for BodyCAN FrameInstance BlinkRequest SignalBS1SignalBS2 SignalBS

17 System Design Implementation Process Input: Requirements & Vehicle Info 1a 1c 1b SW Component System ECU Resource SW Component Configure System & generate extracts of ECU descriptions Configure each ECU Generate SW executables for each ECU Iterative corrections and(/or optimizations (if required) SW executables for each ECU 33 The Virtual Functional Bus Input to the System Design on an abstract level Function Bus Integrator omponent Template get_v() v_warn() SW Component 3... SW Component m Example: speed warning device Virtual Functional Bus omponent- get_v() describes a function to acquire the current vehicle speed and defines the necessary resources (such as memory, run-time and computing power requirements, etc.) Function v_warn() makes use of get_v() Virtual Integration by check of - completeness of omponent-s (entirety of interconnections) - integrity/correctness of interfaces The Virtual Functional Bus is implemented by the -Runtime-Environment (RTE) and underlying Basic-SW = tool based 34 17

18 Input s (1 of 3) Step 1a): of omponents independently of hardware Information for each SWC e.g. get_v() - interfaces, behavior (repetition rate,...) - direct hardware interfaces (I/O) - requirements on run-time performance (memory, computing power, throughput, timing/latency, ) -... SW Component General characteristics (name, manufacturer, etc.) properties: - p_ports - r_ports - interfaces inner structure (composition) - sub-components - connections required HW resources: - processing time - scheduling - memory (size, type, etc.) = tool based - Editor get_v() Software Component 35 Input s (2 of 3) Step 1b): of hardware independently of application software Information for each ECU e.g. ECU1 - sensors and actuators - hardware interfaces - HW attributes (memory, processor, computing power, ) - connections and bandwidths, etc ECU Resource General characteristics (name, manufacturer, etc.) Temperature (own, environment, cooling/heating) Available signal processing methods Available programming capabilities Available HW: - µc, architecture (e.g. multiprocessor) - memory - interfaces (CAN, LIN, MOST, FlexRay) - periphery (sensor / actuator) - connectors (i.e. number of pins) SW below RTE for micro controller Signal path from Pin to ECU-abstraction - Editor ECU 1 Resource = tool based 36 18

19 Input s (3 of 3) Step 1c): of system System Information overall system - bus systems, protocols, communication matrix and attributes (e.g. data rates, timing, ) - function clustering - function deployment (distribution to ECU) -... System Network topology - bus systems: CAN, LIN, FlexRay - connected ECUs, Gateways - power supply, system activation (for each channel) - K-matrix - gateway table Mapping / Clustering of SW components - Editor System- = tool based 37 System Configuration Step 2: Distribution of omponent-s to ECU Configuration on the basis of descriptions (not on the basis of implementations!) of SW- Components, ECU-Resources and System- Consideration of ECU-Resources available and constraints given in the System- get_v() v_warn() SW Component System Definition (Distribution of omponent-s considering resources available) SW Component n System- Configuration- Descript. Configuration- ECU1 - Descript. Configuration- 1, ECU2 - - Descript. 2, 5, ECUm , k, - Resources n, Ressources Ressources ECU-Resource - ECU 1 ECU-Resource - ECU 2 ECU-Resource - ECU 3... ECU-Resource - ECU m System - e.g. mapping of signals to CAN matrices -... = tool based an iterative process 38 19

20 ECU-Configuration Step 3: Generation of required configuration for -Infrastructure per ECU Configuration- Descript. ECU1-1, - 2, Resources System - e.g. mapping of signals to CAN matrices Configuration ECU1 configuration of the -RTE configuration of OS - ECU Configuration Generator -RTE-Config-Info - communication mechanisms - transport protocols -... configuration of MCAL Configuration of COM stack etc = tool based 39 Generation of Software Executables Step 4: Based on the configuration information for each ECU (example ECU1) SW Body of the SW components -Library - communication - transport protocols,... (code, macros, Objects,...) -Configuration ECU1 configuration of the -RTE Tooling - RTE Generator omponents ECU1 (derived partially from the Virtual Function Bus) -RTE configuration of OS OS Generator OS configuration of MCAL MCAL- Generator MCAL COM Configuration of COM stack COM Generator Basic system functions core functions, drivers Hardware 40 20

21 Methodology Conclusion The E/E system architecture can be described by means of. The meta model approach and the tool support for specifying the information model allow working at the right level of abstraction. A methodology to integrate software modules has been designed. pushes the paradigm shift from an ECU based approach to a function based approach in automotive software development. 41 Use case Front-Light Management applying SwitchEvent check_switch () switch_event (event) Int. LightRequest switch_event(event) request_light (type, mode) Front-Light Manager request_light(type, mode) get_keyposition() set_light(type, mode) Xenonlight set_light(type, mode) set_current ( ) RTE RTE RTE Std. Services Std. ECU Std. Std. Std. Std. ECU Std. DIO CAN Driver Microcontroller ECU-Hardware CAN Driver Microcontroller ECU-Hardware CAN Driver PWM Microcontroller ECU-Hardware CAN Bus 42 21

22 Topics for Research and Development System configuration Semi-automatic mapping of communication - - Folie 43 System Configuration. 1a 1c 1b SW Component System ECU Resource 2 Configure System & generate extracts of ECU descriptions Step 2 System Configuration has high complexity Contains mappings of Data Signals Network Implementations SW-compositions ECU Logical HW resources ECU Under the existence of mappings constraints System configuration is data structure covering the whole system description - - Folie 44 22

23 System Configuration. Mapping. ECU I ECU II A B C Data Types Ports System Signals RTE BSW VFB RTE BSW Infrastructure Interaction Protocol Data Units Sensor Hardware Frames Bus Path - - Folie 45 Mapping. Level 1: Primitive Data Types System Signals. between SW Components mapped onto Run Time Environment Mapping defined as set of associations Similar, but more complex mappings for Complex data types Client-server communication between SW- Components Additionally, signal paths can be constraint - - Folie 46 23

24 Mapping. Level 2: System Signals Run Time Environment Interaction Protocol Data Units. Mapping of RTE signals to Manager Interaction layer defines also timing and triggering of ISignals - - Folie 47 Mapping. Level 3: Interaction Protocol Data Units Frames. Mapping of Manager to PDU Router PDU Router deploys frames to different communication protocols Frame definitions configure all communication stacks of full network Different segments of system configuration will be used to configure each communication stack at each ECU - - Folie 48 24

25 Mapping. Tooling. get_v() v_warn() SW Component 3... SW Component n -System Configuration Generator (Definition of mappings) Configuration- Descript. Configuration- ECU1 - Descript. Configuration- 1, ECU2 - - Descript. 2, 5, ECUm , k, - Resources n, Ressources Ressources -... System-... ECU-Resource - ECU 1 ECU-Resource - ECU 2 ECU-Resource - ECU 3... ECU-Resource - ECU m System - e.g. mapping of signals to CAN matrices -... Generation of mappings based on graph transformation rules - - Folie 49 Challenges Complexity and size of system configuration Interaction with decisions by system designer Conclusion Leverages model-based engineering of automotive software to whole systems Standardization itself is highly formalized and so supports formal system development Shifts implementation efforts to configuration Graph Transformation Is the technology for semi-automatic configuration Can reduce the configuration complexity Needs to build domain knowledge - - Folie 50 25

26 Further Information Published version of Release Folie 51 Backup - - Folie 52 26

27 Challenges in Automotive E/E Development Extend product offering and increase product differentiation Stable or decreasing development costs Strengthen brand image in the market Propose specific features and functions across the product range Ensure long term competitiveness, as well as presence in emerging markets, through cost reduction Increase quality and reduce non quality costs Increasing share of electronics in vehicle value Electronics share (in value): 2004: 20% 2015: 40% (McKinsey, Automotive Electronics - Managing innovations on the road) Software share (in value): 2000: 4,5% 2010: 13% (Mercer Consulting, Automobile technologie 2010) 53 Basic Software Layer Runtime Environment (RTE) System Services Memory Services Services I/O Hardware Complex Drivers Onboard Device Memory Hardware Hardware Microcontroller Drivers Memory Drivers I/O Drivers Drivers Microcontroller 54 27

28 Example: NVRAM Manager ensures the storage and maintenance of non-volatile data and is independent of the design of the ECU. Memory Services NVRAM Manager Example Layer Runtime Environment (RTE) Memory Hardware Mem EEPROM EepIf_Read() EepIf_Write() System Services Onboard Device Memory Services Memory Hardware Services Hardware I/O Hardware Complex Drivers Ext. EEPROM Driver Spi_Read() Spi_Write() Microcontroller Drivers Memory Drivers I/O Drivers Drivers Microcontroller COM Drivers SPI Handler + Driver Memory Drivers Int. EEPROM Driver SPI µc EEPROM External EEPROM 55 Glance on s Body Domain CmdWashing is the interface defined by following information: It is provided by the WiperWasherManager component through the [Washer]Activation port CmdWashing contains one data element command Command is of type t_onoff t_onoff is a RecordType, which describes a generic on/off information 56 28

29 Metamodel Formal description of all methodology related information The metamodel is modeled in UML The structure of the information can be clearly visualized The consistency of the information is guaranteed Using XML, a data exchange format can be generated automatically out of the metamodel SW- Component METAMODEL Mirror Adjustment MODEL Datatype Mirror Actuator 57 29