Beruflich Dokumente
Kultur Dokumente
Simon Frst, BMW Group Safetronic 2011 8 Nov. 2011, Sheraton Arabellapark Hotel, Munich
AUTOSAR and Functional Safety Overview Basic aspects of AUTOSAR architecture and methodology Safety mechanisms supported by AUTOSAR Technical safety concepts supported by AUTOSAR Relationship to ISO 26262 and Conclusion
8 Nov. 2011
AUTOSAR and Functional Safety AUTOSAR Vision AUTOSAR aims to standardize the software architecture of ECUs. AUTOSAR paves the way for innovative electronic systems that further improve performance, safety and environmental friendliness.
Yesterday
Customer needs
Adaptive Cruise Control Lane Departure Warning Advanced Front Lighting System ..
Software
Hardware
Hardware
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.
3 8 Nov. 2011 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
AUTOSAR and Functional Safety Intra- and Inter-ECU Communication Ports implement the interface according to the communication paradigm (here client-server based).
ECU I ECU II
Application SW-C B Application SW-C C
Ports are the interaction points of software components. The communication is channeled via the RTE. The communication layer in the basic software is encapsulated and not visible at the application layer.
Application SW-C A
Application
Ports
RTE
VFB
RTE
AUTOSAR Infrastructure
BSW BSW
Sensor
Hardware
8 Nov. 2011
Automotive Open System Architecture (AUTOSAR): Standardized, openly disclosed interfaces HW independent SW layer Transferability of functions Redundancy activation AUTOSAR RTE: by specifying interfaces and their communication mechanisms, the applications are decoupled from the underlying HW and Basic SW by the RTE. This enables the realization of re-usable application software components.
AUTOSAR Software
..............
Operating System
Basic Software
ECU-Hardware
Interfaces: AUTOSAR Software Component Interface Standard Software
RTE relevant
BSW relevant
8 Nov. 2011
AUTOSAR and Functional Safety Software Architecture: Software Abstraction inside the Infrastructure Architecture The Basic Software Layers are further divided into functional groups. Each functional group consist of multiple basic software modules.
SW Components
Application Software Component AUTOSAR Interface Actuator Software Component AUTOSAR Interface Sensor Software Component AUTOSAR Interface
AUTOSAR Software
..............
Memory Services
Complex Drivers
Basic Software
Communication Hardware EEPROM Abstraction Abstraction Communication External EEPROM Driver Drivers
COM Drivers
Microcontroller Drivers
Memory Drivers
I/O Drivers
ECU Resources
ECU-Hardware
SPIHandler Driver
SPI
EEPROM
8 Nov. 2011
AUTOSAR and Functional Safety Methodology and Templates: The AUTOSAR Meta Model The AUTOSAR Meta Model is the backbone of the AUTOSAR architecture definition contains complete specification, how to model AUTOSAR systems
Metamodel Package Overview M3: Model of the Meta Model (Meta-Meta Model) (Defines UML Modeling Elements)
All other top-level packages aggregate metaclasses from Generic Structure SW Component Template Generic Structure Common Structure
M2: Model of the model (Meta Model) (Defines AUTOSAR Modeling Elements)
System Template
ECU Description Template BSW Module Template ECU Parameter Def Template
8 Nov. 2011
SWComponent Description
OS extract of ECU configuration e.g. OIL Basic SW Basic SW ModuleBasic A extract SW Module A extract of ECU Module A of ECU extract configuration of ECU configuration configuration List of implementations of SW components
MCAL Generator
Information / Database (no files) Generation step: complex algorithm or engineering work
8 Nov. 2011
AUTOSAR and Functional Safety Overview Basic aspects of AUTOSAR architecture and methodology Safety mechanisms supported by AUTOSAR Technical safety concepts supported by AUTOSAR Relationship to ISO 26262 and Conclusion
8 Nov. 2011
AUTOSAR and Functional Safety Approach of AUTOSAR with regard to Functional Safety.
Sources ISO WD 26262 Requirements from WPs & WGs Requirements from Applications Requirements from Safety Concepts
Consolidated Safety Requirements Process Safety Requirements Technical Safety Requirements Interface Class 1 SW-C HW ECU Sensor Actor
List of safety requirements allocated to BSW & RTE
Interface Class 3
List of requirements on development processes
AUTOSAR and Functional Safety Overview on Safety Mechanisms Supported by AUTOSAR Built-in self test mechanisms for detecting hardware faults (testing and monitoring) Run-time mechanisms for detecting software faults during the execution of software Program flow monitoring Run-time mechanisms for preventing fault interference Memory partitioning for SW-Cs Time partitioning for applications Run-time mechanisms for protecting the communication End-to-end (E2E) communication protection for SW-Cs Run-time mechanisms for error handling
11
8 Nov. 2011
AUTOSAR and Functional Safety Safety mechanisms for detecting errors. Memory: RAM Test Flash Test Support for ECC memory Core: Core Test Watch Dog Logical and temporal program flow monitoring
12
8 Nov. 2011
AUTOSAR and Functional Safety Run-time mechanisms for error handling Detected errors in the basic software: Are reported through DEM to SW-Cs. SW-Cs then executes application-specific actions Are reported to FIM, which permits to disable some functions of SW-C Detected hardware errors: Arithmetic exceptions (e.g. division by 0): handled by OS callouts (small error handling routines in the context of basic software). Typical reaction ECU reset HW errors detected by HW testing: handled by callouts. Typical reaction ECU reset Errors detected my MMU/MPU (memory and time partitioning). It will shut down or restart the faulty SW-C partition
13
8 Nov. 2011
AUTOSAR and Functional Safety Memory partitioning for Software-Components Enables create protection boundaries around groups of SW-Cs This is realized by user-mode/non-trusted memory partitions (for groups of SW-Cs) This protects from interference: (1) basic software and (2) SW-Cs in other partitions Basic software is not AUTOSAR partitioned. It runs Software with in CPU super.............. visor mode with AUTOSAR Runtime Environment (RTE) full access to memory, CPU and all other hardware resources
Application Software Component AUTOSAR Interface Actuator Software Component AUTOSAR Interface Sensor Software Component AUTOSAR Interface Application Software Component AUTOSAR Interface Standardized Interface Standardized AUTOSAR Interface Services Standardized Interface AUTOSAR Interface AUTOSAR Interface Communication Standardized Interface ECU Abstraction Standardized Interface Standardized Interface
Standardized Inteface
Operating System
14
8 Nov. 2011
AUTOSAR and Functional Safety End-to-End communication protection (1/4) E2E protection detects faults in data caused by both hardware and in software Typical sources of
Libraries OS-Application 2 Receiver 1 OS-Application 1 Sender
interferences, causing errors detected by E2E protection: SW-related sources: S1. Error in mostly generated RTE, S2. Error in partially generated and partially hand-coded COM S3. Error in network stack S4. Error in generated IOC or OS HW-related sources: H1. Microcontroller error during core/partition switch H2. Failure of HW network H2. Network EMI H3. Microcontroller failure during context switch (partition) or on the communication between cores
Memory Services
Communication Services S2
CDD
Receiver 2
Microcontroller Drivers
Memory Drivers
Communication Drivers
I/O Drivers
H3
H4
Microcontroller 1 / ECU 1
Microcontroller 2 / ECU 2
15
8 Nov. 2011
AUTOSAR and Functional Safety End-to-End communication protection (2/4) Application is almost un-impacted by the introduction of end-to-end protection wrapper End-to-End protection wrapper protects/checks the communication on behalf of application, i.e. SW-Cs End-to-End Protection wrapper encapsulates the data protection and also invokes RTE
OS-Application 1 OS-Application 2 Sender 1 Receiver 1 Application logic Application logic 1 Produce safe data elements 2 Invoke safe transmission request E2EPW_Write()
E2E protection wrapper E2E protection wrapper
3 Call E2E protect on array E2E_P0x_Protect() 4 Invoke RTE - RTE_Write() to transmit the data element
8 Call E2E check on array - E2E_P0xCheck() 7 Invoke RTE read - RTE_Read() to get the data element
5: RTE communication (intra or inter ECU), either through COM, IOC, or local in RTE
E2E Lib
E2E Lib
16
8 Nov. 2011
AUTOSAR and Functional Safety End-to-End communication protection (3/4) Protection of data exchanged over communication channels like FlexRay and CAN Failure modes addressed as defined by ISO DIS 26262 for communication (repetition, deletion, insertion, incorrect sequence, corruption, timing faults, addressing faults, inconsistency, masquerading) Three different protection mechanisms for data are used CRC, counter, Data ID, timeout detection Data ID included in to calculated CRC, but not sent
Data Id
CRC
0xFF
Signal 2
CRC := CRC8 over (1) Data Id, (2) all serialized signal (including empty areas, excluding CRC byte itself)
17
8 Nov. 2011
AUTOSAR and Functional Safety End-to-End communication protection: future considerations (4/4) Fully AUTOSAR compliant design with major impact on ASIL inheritance Example: overall flow at sender
OS-Application 1 SW-C 1 1. Produce safe data elements
AUTOSAR Runtime Environment (RTE) Libraries Communication Services 4. COM Signals 7. E2E_PXXProtect(&Config, &State, (unit8*) IPduData)
8. Execute E2E Library, wrte control fields (e.g. CRC, Counter) in IPduData
E2E Lib
COM
PDU Router
18
8 Nov. 2011
AUTOSAR and Functional Safety Overview Basic aspects of AUTOSAR architecture and methodology Safety mechanisms supported by AUTOSAR Technical safety concepts supported by AUTOSAR Relationship to ISO 26262 and Conclusion
19
8 Nov. 2011
AUTOSAR and Functional Safety Technical safety concepts supported by AUTOSAR Implementation of typical safety concepts in the automotive domain Intelligent HW watchdog (ASIC) / 3-level safety concept Monitored channel (2 Cs, the second is a simple C monitoring the first C) Dual channel (2 AUTOSAR Cs) Application redundancy (on the same or different Cs) Basic Software redundancy inside one ECU
20
8 Nov. 2011
AUTOSAR and Functional Safety Application redundancy Assuming integrity of HW/ECU and AUTOSAR basic software implementation, software redundancy with ASIL decomposition can be used within the same ECU. Distribution of SW channels across ECUs is also possible..
SW-C Channel 1
SW-C Channel 2
AUTOSAR
SW-C Channel 1
SW-C Channel 2
C core 1
C core 2
AUTOSAR
AUTOSAR
ECU 1
ECU 2
21
8 Nov. 2011
AUTOSAR and Functional Safety Basic Software redundancy inside one ECU Redundancy inside AUTOSAR e.g. double input/output data paths through Redundant IO hardware abstraction and IO drivers Redundant and diverse (e.g. ADC + DIO, internal ADC + external ADC) Redundancy through SW-C Channel 1 SW-C Channel 2 SW-C Channel 1 SW-C Channel 2 integration of complex Runtime Environment Runtime Environment drivers runnComplex Drivers I/O Hardware Abstraction I/O Hardware Abstraction ing on the I/O Signal Interface 1 I/O Signal Interface 2 I/O Signal Interface 1 same C Driver for ext. offering a ADC ASIC redundant Complex data path Driver COM Drivers COM Drivers I/O Drivers
ADC Driver 1 ADC Driver 1 ADC Driver 2 SPIHandler Driver SPI DIO Driver DIO
HW component
ADC 1
ADC 2
ADC
22
8 Nov. 2011
AUTOSAR and Functional Safety Overview Basic aspects of AUTOSAR architecture and methodology Safety mechanisms supported by AUTOSAR Technical safety concepts supported by AUTOSAR Relationship to ISO 26262 and Conclusion
23
8 Nov. 2011
AUTOSAR and Functional Safety Relationship to ISO 26262 Essential concepts of ISO 26262 have been developed in sync with AUTOSAR Software configuration Part 6, Chapter 7 and Annex C Freedom of interference by partitioning Part 6, Chapter 7 and Annex D Safety Element out of Context (SEooC) Part 10, Chapter 9 Qualification of software tools Part 8, Chapter 10
Item Development
3-7 Hazard analysis and risk assessment Hazard analysis and risk assessment
SEooC Development
Concept phase ASIL Capability Assumptions on safety goals (ASIL Safety Element out of Context Capability per system failure ) Overall management of safety requirements 3-7 Hazard analysis and risk assessment Specification of safety goals
Product development
24
8 Nov. 2011
After SOP
AUTOSAR and Functional Safety Relationship to ISO 26262 Due to rules on ASIL inheritance defined in ISO 26262 the AUTOSAR basic software and RTE inherits safety relevance. Either implement complete AUTOSAR basic software according to max. ASIL of application software or demonstrate freedom of inference in basic software by appropriate mechanisms
1. Vocabulary 2. Management of functional safety
Implementers have to tailor ISO 26262 according to their activities in the safety-lifecycle For all implemented safety mechanisms a safety manual is needed containing The fault model according to which the safety mechanism was developed The constraints that must be fulfilled when applying a safety mechanism
25 8 Nov. 2011
3. Concept phase
3-5 Item definition 3-6 Initiation of the safety lifecycle 3-7 Hazard analysis and risk assessment 3-8 Functional safety concept
8. Supporting processes
8-5 Interfaces within distributed developments 8-6 Specification and management of safety requirements 8-7 Configuration management 8-8 Change management 8-9 Verification 8-10 Documentation 8-11 Qualification of software tools 8-12 Qualification of software components 8-13 Qualification of hardware components 8-14 Proven in use argument
Core processes
AUTOSAR and Functional Safety Conclusion AUTOSAR systematically derived safety mechanisms supported in release 4.0 AUTOSAR provides support for dedicated safety mechanisms with generic fault models AUTOSAR supports typical technical safety concepts During system and software design the safety manual is considered to appropriately use the safety mechanisms of an AUTOSAR implementation. AUTOSAR provides essential support for building of safety related systems
26
8 Nov. 2011