18 aprile 2012 Gli standard emergenti per lo sviluppo del software dei sistemi automotive Edoardo Sivera E/E System Responsible
AGENDA: : Main purposes : architecture : SW Development Process and ISO 26262 18 aprile 2012 2
: main purposes Complex Systems challenges Autosar Goals Autosar Consortium 18 aprile 2012 3
New Challenges for Automotive Development Growing software and system complexity of vehicle Inside the vehicle Many electronic systems Full interconnection of all systems High integration of functionality in ECUs Large amount of External information exchange among vehicles among vehicle and infrastructure 4 18 aprile 2012 4
Degree of Interdependence Increasing Complexity in Vehicle Development 90% of all innovations are driven by electronics and software. controls a large number of functions, which make use of linked networks. Up to 40% of a vehicle s development costs are determined by electronics and software. Mainly mechanical systems Electronic support mainly in the area of chassis and engine control. Infotainment functions gave software dedicated meaning in the automotive domain of the 90ties. 50-70% of the development costs for an ECU (Electronic Control Unit) are related to software. 1970 1980 1990 2000 2010 18 aprile 2012 5
Electronic Architecture: an example 18 aprile 2012 6
The Main Challenge: Complexity Management Classic Structure of E/E Architectures Body GW SZL/LWS B1 DISP Infotain Rear Infotain GEAR Engine LMV B2 CAN Video Switch comm Tel HiFi Satellite Crash EN5 H11 SENSE CH1 B3 B12 IT1 EN1 H10 CH2 B4 B11 IT2 EN2 CH9 CH3 B5 B10 IT3 EN3 CH8 CH4 B6 B9 MOST EN4 CH7 CH5 B7 B8 KOMBI CH6 DSC CAN CAN CAN FlexRay 18 aprile 2012 7
Vision aims to improve complexity management of integrated E/E architectures through increased reuse and exchangeability of SW modules between OEMs and suppliers. OEM b OEM a Platform b.1 Platform b.2 Platform b.n Exchangeability between OEM c suppliers solutions Platform a.1 Platform a.2 Platform a.n Exchangeability between manufacturers applications OEM f Platform f.1 Platform f.2 Platform f.n Supplier A Chassis Safety Body/ Comfort OEM e Platform e.1 Platform e.2 Platform e.n Supplier B Chassis Safety Telematic s Supplier C Body/Comfort Powertrain Telematics Platform c.1 Platform c.2 Platform c.n OEM d Platform d.1 Platform d.2 Platform d.n Exchangeability between vehicle platforms 18 aprile 2012 8
Vision aims to: standardize the software architecture of ECUs define a new standard development process of systems and software. Yesterday Hardware Application Hardware standardized HW-specific Customer needs Adaptive Cruise Control Lane Departure Warning Advanced Front Lighting System. Using standards Communication Stack OSEK Diagnostics CAN, FlexRay Hardware and software will be widely independent of each other. Development can be de-coupled by horizontal layers. This reduces development time and costs. The reuse of software increases at OEM as well as at suppliers. This enhances quality and efficiency. 18 aprile 2012 9
9 Main Project Objectives and 3 Main Working Topics PO1: Implementation and standardization of basic system functions as an OEM wide Standard Core solution PO2: Scalability to different vehicle and platform variants PO3: Transferability of functions throughout network PO4: Integration of functional modules from multiple suppliers Application s Architecture Methodology PO5: Maintainability throughout the whole Product Life Cycle PO6: Increased use of Commercial off the shelf hardware PO7: updates and upgrades over vehicle lifetime PO8: Consideration of availability and safety requirements PO9: Redundancy activation 18 aprile 2012 10
: Functional Domains Functional Domains Vehicle centric Chassis Powertrain Safety (active/ passive) Multimedia/ Telematics Human Machine Cooperate on standards, compete on implementation. Body and Comfort Passenger centric 18 aprile 2012 11
Core Partners and Members 9 Core Partners 11 Development Members ~ 50 Premium Member 88 Associate Members 17 Attendees General OEM Generic Tier 1 Standard Tools and Services 18 aprile 2012 Semiconductor s 12
: Architecture Main concepts Standard SW Architecture How it works: a real example SW distribution on ECUs of the EE System 18 aprile 2012 13
supports HW independence and enable the standardization of SW components. SW-Component 1 SW-Component 2... RTE SW-Component n (main goals):, openly disclosed interfaces HW independent SW layer Transferability of functions Redundancy activation Basic Transfer layers for different communication technologies (e.g. CAN, LIN, ) Network management System services (diagnostic protocols, ) NVRAM management Microcontroller Abstraction ECU Hardware RTE: by specifying interfaces and their communication mechanisms, the applications are decoupled from the underlying HW and Basic SW, enabling the realization of Stan-dard Library Functions. 18 aprile 2012 14
Autosar: ECU Standard Architecture Application Component Actuator Component Sensor Component Application Component... Runtime Environment (RTE) Operating System Services Basic Communication ECU Abstraction Microcontroller Abstraction Complex Device Drivers ECU-Hardware Component Standard s: VFB & RTE relevant RTE relevant BSW relevant 18 aprile 2012 15
Use case Front-Light Management in SwitchEvent check_switch () switch_event (event) LightRequest switch_event(event) request_light (type, mode) Front-Light Manager request_light(type, mode) get_keyposition() set_light(type, mode) Headlight set_light(type, mode) set_current ( ) Int. RTE Operating System Std. Services Std. Communication Std. ECU Abstraction Std. Complex Device Drivers DIO PWM CAN Driver Microcontroller Abstraction ECU-Hardware 18 aprile 2012 16
Exchange of type of front-light 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 Headlight set_light(type, mode) set_current ( ) Int. RTE Operating System Std. Services Std. Communication Std. ECU Abstraction Std. Complex Device Drivers DIO PWM DIO CAN Driver Microcontroller Abstraction ECU-Hardware 18 aprile 2012 17
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. Communication Std. ECU Abstraction Std. Complex Device Drivers DIO PWM DIO CAN Driver Microcontroller Abstraction ECU-Hardware 18 aprile 2012 18
Use case Front-Light Management in SwitchEvent check_switch () switch_event (event) 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 ( ) Int. RTE RTE RTE Std. Services ECU Abstraction Communication Communication Communication ECU Abstraction Std. Std. Std. Std. Std. Std. DIO CAN Driver Microcontroller Abstraction ECU-Hardware CAN Driver Microcontroller Abstraction ECU-Hardware CAN Driver PWM Microcontroller Abstraction ECU-Hardware CAN Bus 18 aprile 2012 19
: SW Development Process Overall methodology Structure of configuration information System Design Implementation Process 18 aprile 2012 20
1 1 2 3 n Development Methodology Virtual Functional Bus Concept... Virtual Functional Bus Application software functionality implemented in Components () Handling of vehicle wide functions, independent from ECUs or network s can communicate between each other and access functions from the standardized set of infrastructure functions Communication needs of a are formally described in a standard template, i.e. the Any interaction runs via Ports, which implement different communication paradigms, e.g. sender-receiver or client-server The VFB enables a virtual integration of s and allows to formally verify structural and dynamic compatibility of s 18 aprile 2012 21
1 3 2 n 1 2 3 n Development Methodology ECU I RTE Basic... Virtual Functional Bus ECU ECU II ECU RTE Basic... ECU m ECU RTE Basic description templates: description: application software ECU description: ECU characteristics and configuration System description: network and assignment of s to ECUs s for s + ECUs + system description Allow a tool-based deployment of s to ECUs FlexRay Gateway CAN System 18 aprile 2012 22
Methodology VFB view SW-C SW-C SW-C SW-C 1 SW-C 2 SW-C 3... SW-C SW-C 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 SW-C 1 ECU I RTE Basic SW-C 3 ECU II SW-C 2 RTE Basic... ECU m SW-C n RTE Basic Tools for - support of component mapping - generation of RTE, i.e. inter- and intra ECU communication Basic (BSW) architecture, detailed specifications for implementation and configuration of BSW Gateway 18 aprile 2012 23
Development Methodology Development steps From functional level to the ECU binaries. Functional architecture level Component modeling Data model development VFB Timing Develop VFB System Physical architecture level Design System System topology Network Mapping of components to ECUs Internal behavior Implementation Component timing Develop Application Component BSW implementation Configuration Deliver Basic Generate ECU Extract Build ECU Hardware dependent Hardware independent 18 aprile 2012 24
and ISO 26262 Relatioship between Autosar development process ans ISO 26262 Use case: how Autosar implements a safety relevant feature 18 aprile 2012 25
methodology according to ISO26262 Functional Safety Concept 3-8 Specification of Technical Safety Requirements 4-6 SYSTEM Specification of SW Safety Requirements 6-6 SW architectural design 6-7 18 aprile 2012 26
methodology according to ISO26262 Functional Safety Concept 3-8 Specification of Technical Safety Requirements 4-6 SYSTEM Supports safety by offering standard safety mechanisms Core Tests, Flash tests E2E protection Memory partitioning Specification of SW Safety Requirements REQ 6-6 architectural design 6-7 SW REQ SPECIFICATIONS REQ REQ Requirements (SRS) REQ REQ Specifications (SWS) REQ Some safety requirements in ISO26262 part6 are related to SW implementation BSWs BSWs Config SW-Cs Safety related CDDs SW implementation 18 aprile 2012 27
Release 4.0 - Partitioning Use Case Memory partitioning: separate software applications from each other in order to avoid any data corruption between applications Partitions are used as fault containment regions Partitions can be terminated or restarted during run-time as a result of a detected error Partitions are configured in the ECU-C Partition 0 (No ASIL) Partition 1 (ASIL A) Partition 4 (ASIL D) Application Component Operating System Actuator Component Basic Sensor Component ECU-Hardware... Application Component Runtime Environment (RTE) with build-in protection layer Services Communication Partition 5 (ASIL D) ECU Abstraction Microcontroller Abstraction Complex Device Drivers 18 aprile 2012 28
Release 4.0 - Example for Partitioning 1. A violation (error) has occurred in the system (e.g., memory or timing violation) 2. The partition is terminated by the OS, cleanup possible communication is stopped 3. The partition is restarting, initial environment for partition set up 4. The partition is restarted and up and running Partition 0 (No ASIL) Partition 1 (ASIL A) Partition 4 (ASIL D) Application Component Operating System Actuator Component Services Basic Sensor Component Stop Communication ECU-Hardware... ECU Abstraction Microcontroller Abstraction Application Component Runtime Environment (RTE) with build-in protection layer Partition 5 (ASIL D) Complex Device Drivers 18 aprile 2012 29
Thank You for your attention! Edoardo Sivera edoardo.sivera@iveco.com +39 347 8739986 18 aprile 2012 30
Back Up 31 March 8th 2010 Date 2010 - Tutorial on
Motivation and Principles Visions and Objectives Main Working Topics Architecture Application s Methodology Architecture: architecture including a complete basic software stack for ECUs the so called Basic as an integration platform for hardware independent software applications. Architecture Application s Methodology Methodology: Defines exchange formats and description templates to enable a seamless configuration process of the basic software stack and the integration of application software in ECUs. It includes even the methodology how to use this framework. Architecture Application s Methodology Application 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. 18 aprile 2012 32
To configure the system, input descriptions of all software components, ECU resources and system constraints are necessary. Example ECUs Components SwitchEval ECU Resource ECU Resource ECU Resource SW-Component BlinkInputModule SW-Component SwitchEval Supported protocols: CAN, LIN, FlexRay BC-V SMLS BC-H System BlinkMaster SW-Component LightActuatorsControl BlinkInputModule BlinkMaster LightActuatorsControl CAN SW-Component LightSourceSetting LIN LightSourceSetting LM-L LM-R SW-Component 18 aprile 2012 33
The system configuration maps software components to ECUs and links interface connections to bus signals. Example System Configuration MappingDefs DataMappingDefs BlinkRequest SwitchEval BlinkInputModule Blink Input Module Blink Master BlinkMaster LightActuatorsControl LightSourceSetting Comm.Matrix for BodyCAN FrameInstance BlinkRequest SignalBS1 SignalBS2 SignalBS3 18 aprile 2012 34