AUTOSAR and Functional Safety
Simon Fürst, BMW GroupSafetronic 20118 Nov. 2011, Sheraton Arabellapark Hotel, Munich
8 Nov. 20112
AUTOSAR and Functional SafetyOverview
� Basic aspects of AUTOSAR architecture and methodology
� Safety mechanisms supported by AUTOSAR
� Technical safety concepts supported by AUTOSAR
� Relationship to ISO 26262 and Conclusion
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
AUTOSAR and Functional SafetyAUTOSAR Vision
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR8 Nov. 20113
� 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.
Yesterday
Application Software
Hardware
standardized
HW-specific
AUTOSARCustomer needs� Adaptive Cruise Control� Lane Departure
Warning� Advanced Front
Lighting System� ..
Using standards� Communication Stack� OSEK� Diagnostics� CAN, FlexRay
Hardware
Software
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.
AUTOSAR and Functional SafetyIntra- and Inter-ECU Communication
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR8 Nov. 20114
� Ports implement the interface according to the communication paradigm (here client-server based).
� 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.
Appli-cationSW-C
A
RTE
BSW
ECU I
Appli-cationSW-C
B
RTE
BSW
ECU II
Appli-cationSW-C
C
VFB
Sensor
Communication Bus
Communication Path
Hardware
AUTOSARInfrastructure
Ports
Application
AUTOSAR and Functional SafetySoftware Architecture – AUTOSAR Defined Interfaces
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR8 Nov. 20115
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.
Automotive Open System Architecture (AUTOSAR):� Standardized, openly disclosed
interfaces� HW independent SW layer� Transferability of functions� Redundancy activation
AUTOSARSoftware
Component
StandardSoftwareInterface
VFB & RTE relevant
RTErelevant
BSWrelevant
Interfaces:
ECU-Hardware
AUTOSAR Runtime Environment (RTE)
Application Software
Component
..............
AUTOSAR Software
Basic Software
AUTOSAR Interface
Complex Device Drivers
Standardized Interface
Operating System
Actuator Software
Component
AUTOSAR Interface
Sensor Software
Component
AUTOSAR Interface
Application Software
Component
AUTOSAR Interface
Standardized Interface
Standardized AUTOSAR Interface
AUTOSAR Interface
AUTOSAR Interface
Services
Standardized Interface
Communication
Standardized Interface
ECUAbstraction
Standardized Interface
Microcontroller Abstraction
Standardized Interface
Standardized Interface
AUTOSAR and Functional SafetySoftware Architecture: Software Abstraction inside the Infrastructure Architecture
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR8 Nov. 20116
ECU-Hardware
AUTOSAR Runtime Environment (RTE)
ActuatorSoftware
ComponentAUTOSARInterface
ApplicationSoftware
Component
SensorSoftware
Component
ApplicationSoftware
Component
..............AUTOSARSoftwareAUTOSAR
InterfaceAUTOSARInterface
AUTOSARInterface
ComplexDrivers
Microcontroller Drivers
Memory Drivers I/O Drivers
I/O Hardware Abstraction
Memory Hardware Abstraction
Memory ServicesSystem Services
Onboard Device Abstraction
Communication Drivers
Communication Hardware
Abstraction
Communication Services
Bas
ic S
oftw
are
ECU
R
esou
rces COM Drivers
Memory Hardware Abstraction
µC
Memory Drivers
EEPROM Driver
SPIHandlerDriver
SPI EEPROM Flash
Internal Flash Driver
External Flash Driver
Memory Abstraction Interface
ExternalEEPROM Driver
EEPROM Abstraction Flash EEPROM Emulation
Memory Services
NVRAM Manager
SWC
ompo
nent
sThe Basic Software Layers are further divided into functional groups. Each functional group consist of multiple basic software modules.
AUTOSAR and Functional SafetyMethodology and Templates: The AUTOSAR Meta Model
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR8 Nov. 20117
M0: Realized System in the car(Implements a real system)
M1: Model of the system(Defines a real system)
M2: Model of the model(Meta Model)
(Defines AUTOSAR Modeling Elements)
M3: Model of the Meta Model(Meta-Meta Model)
(Defines UML Modeling Elements)
The AUTOSAR Meta Model� is the backbone of the AUTOSAR architecture definition� contains complete specification, how to model AUTOSAR systems
Common Structure
ECU Parameter Def Template
Metamodel Package Overview
Generic Structure
BSW Module Template
System Template
SW Component Template
ECU Resource Template
ECU Description Template
All other top-level packages aggregate meta-classes from “Generic Structure”
AUTOSAR and Functional SafetyAUTOSAR Methodology – Alternative Visualization
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR8 Nov. 20118
SystemConfigurationDescription
AUTOSARSystem
ConfigurationGenerator
ComponentAPI
Generator
Generation step:complex algorithm or engineering work
Information / Database (no files)
per ECU
SW-ComponentDescription
ECUResource
Description(HW only)
System –ConstraintDescription
ComponentAPI
(e.g. app.h)
ECU ConfigurationDescription
AUTOSARECU
ConfigurationGenerator
SW-CImplementation
RTE extract ofECU configuration
OS extract ofECU configuration
Basic SWModule A extract
of ECUconfiguration
Basic SWModule A extract
of ECUconfiguration
Basic SWModule A extract
of ECUconfiguration
List ofimplementations
of SWcomponents
e.g. OIL
ECU extractof System
Configuration
ECU extractof System
ConfigurationDecisions(e.g. mapping)
AUTOSARRTE
Generator
OS, COM, …Generator
Other BasicSW Generator
MCAL –Generator
Decisions(e.g. scheduling)
System
8 Nov. 20119
AUTOSAR and Functional SafetyOverview
� Basic aspects of AUTOSAR architecture and methodology
� Safety mechanisms supported by AUTOSAR
� Technical safety concepts supported by AUTOSAR
� Relationship to ISO 26262 and Conclusion
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
AUTOSAR and Functional SafetyApproach of AUTOSAR with regard to Functional Safety.
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR8 Nov. 201110
Requirements from Applications
Requirements from WPs & WGs
Requirements from Safety Concepts
Process SafetyRequirements
AUTOSARSafety
Guidelines
Technical SafetyRequirements
Interface Class 1
ISO WD 26262
Ass
ignm
ent
Stru
ctur
e an
d A
lloca
tion
Sou
rces
Development Process
BSW & RTE
Tools
Methodology SafetyRequirements
Tools
Generation
Interface Class 3
BSW & RTE Requirements
SRS
SWS
SW-C HW
ECUSensorActor
Consolidated Safety Requirements
Tools and Generation Process
Tools
Generation
Update of existing documents of WPs
List of safety requirements allocated to BSW & RTE
Requirements on how to develop AUTOSAR SW and Tools
List of safety requirements allocated to methodology
Requirements on tools and generation process
List of requirements on development processes
8 Nov. 201111
AUTOSAR and Functional SafetyOverview 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
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
AUTOSAR and Functional SafetySafety mechanisms for detecting errors.
� Memory:� RAM Test� Flash Test� Support for ECC memory
� Core:� Core Test
� Watch Dog� Logical and temporal program flow
monitoring
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR8 Nov. 201112
8 Nov. 201113
AUTOSAR and Functional SafetyRun-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
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
8 Nov. 201114
AUTOSAR and Functional SafetyMemory 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 partitioned. It runs with in CPU super-visor mode with full access to memory, CPU and all other hard-ware resources
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
ECU-Hardware
AUTOSAR Runtime Environment (RTE)
ActuatorSoftware
Component
AUTOSARInterface
ApplicationSoftware
Component
SensorSoftware
Component
ApplicationSoftware
Component
..............
AUTOSARSoftware
Basic SoftwareStandardized
Interface
AUTOSARInterface
AUTOSARInterface
AUTOSARInterface
MicrocontrollerAbstraction
StandardizedAUTOSARInterface
Services
StandardizedInterface
ECUAbstraction
AUTOSARInterface
StandardizedInterface
ComplexDeviceDrivers
AUTOSARInterface
StandardizedInterface
Communication
StandardizedInterface
StandardizedInterface
OperatingSystem
StandardizedInteface
8 Nov. 201115
AUTOSAR and Functional SafetyEnd-to-End communication protection (1/4)
� E2E protection detects faults in data caused by both hardware and in software
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
Libraries
CDD
Microcontroller 1 / ECU 1
AUTOSAR Runtime Environment (RTE)
Microcontroller Drivers Memory Drivers I/O Drivers
I/O Hardware Abstraction
Memory Hardware Abstraction
Memory ServicesSystem Services
Onboard Device Abstraction
Communication Drivers
Communication Hardware Abstraction
Communication Services
OS-Application 1
Sender
Receiver 2
IOC
OS-Application 2
Receiver 1
Microcontroller 2 / ECU 2
S1
Direct function call
Typical sources of 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 COMS3. Error in network stackS4. Error in generated IOC or OS
HW-related sources:H1. Microcontroller error during core/partition switchH2. Failure of HW networkH2. Network EMIH3. Microcontroller failure during context switch (partition) or on the communication between cores
S2
S3
H3
H3
S3
H4
8 Nov. 201116
AUTOSAR and Functional SafetyEnd-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
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
Libraries
AUTOSAR Runtime Environment (RTE)
OS-Application 1
Sender 1
OS-Application 2
Receiver 1
E2E protection wrapperE2E protection wrapper
E2E Lib
1 Produce safe data elements
2 Invoke safe transmission request -E2EPW_Write()
3 Call E2E protect on array – E2E_P0x_Protect()
4 Invoke RTE - RTE_Write() to transmit the data element
5: RTE communication (intra or inter ECU), either through COM, IOC, or local in RTE
Application logicApplication logic
7 Invoke RTE read - RTE_Read() to get the data element
9 Consume safe data elements
6 Invoke safe read do get the data element - E2EPW_Read()
8 Call E2E check on array - E2E_P0xCheck()
AUTOSAR Runtime Environment (RTE)
Libraries
E2E Lib
8 Nov. 201117
AUTOSAR and Functional SafetyEnd-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
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
CRC := CRC8 over (1) Data Id, (2) all serialized signal (including empty areas, excluding CRC byte itself)
Data Id Signal1Counter
CRC Signal 20xFF0xF
8 Nov. 201118
AUTOSAR and Functional SafetyEnd-to-End communication protection: future considerations (4/4)
� Fully AUTOSAR compliant design with major impact on ASIL inheritance� Example: overall flow at
sender
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
Libraries
AUTOSAR Runtime Environment (RTE)
OS-Application 1
SW-C 1
E2E Lib
1. Produce safe data elements
2. Invoke RTE - RTE_*_<p>_<o>() to transmit the data element
Communication Services
COM
4. COM Signals
5. Serialize signals on I-PDU
3. Map Data Elements to signals
6. IPDU_E2EProtect_<IPDU ID>( PduId, IPduData)
7. E2E_PXXProtect(&Config, &State, (unit8*) IPduData)
8. Execute E2E Library, wrte control fields (e.g. CRC, Counter) in IPduData
9. Updated parameters State and IPduData
COM E2E Callouts
10. ret: TRUE if no error else FALSE; updated IPduData
PDU Router
11. If (ret = TRUE) deliver IPduData;else no action
8 Nov. 201119
AUTOSAR and Functional SafetyOverview
� Basic aspects of AUTOSAR architecture and methodology
� Safety mechanisms supported by AUTOSAR
� Technical safety concepts supported by AUTOSAR
� Relationship to ISO 26262 and Conclusion
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
8 Nov. 201120
AUTOSAR and Functional SafetyTechnical 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
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
8 Nov. 201121
AUTOSAR and Functional SafetyApplication 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..
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
µC core 1 µC core 2
SW-C Channel 1
AUTOSAR
SW-C Channel 2
ECU 1
SW-C Channel 1
AUTOSAR
ECU 2
AUTOSAR
SW-C Channel 2
8 Nov. 201122
AUTOSAR and Functional SafetyBasic 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 integration of complexdrivers runn-ing on the same µC offering a redundant data path
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
SW-C Channel 1 SW-C Channel 2
Runtime Environment
COM Drivers
I/O Hardware Abstraction
I/O Signal Interface 1
µC
I/O Drivers
DIO
Driver
SP
IHandler
Driver
SP
I
DIO
Driver for ext.ADC ASIC
AD
C D
river 2 A
DC
2
I/O Signal Interface 2
AD
C D
river 1 A
DC
1
SW-C Channel 1 SW-C Channel 2
Runtime Environment
COM Drivers
I/O Hardware Abstraction
I/O Signal Interface 1
µC
AD
C D
river 1 A
DC
Complex Drivers
Complex Driver
HW
com
ponent
8 Nov. 201123
AUTOSAR and Functional SafetyOverview
� Basic aspects of AUTOSAR architecture and methodology
� Safety mechanisms supported by AUTOSAR
� Technical safety concepts supported by AUTOSAR
� Relationship to ISO 26262 and Conclusion
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
8 Nov. 201124
AUTOSAR and Functional SafetyRelationship 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
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
3-7 Hazard analysis and risk assessment
Hazard analysis and risk assessment
3-7 Hazard analysis and risk assessment
Specification of safety goals
3-8 Functional safety concept
Specification of functional safety requirements
4-6 Specification of technical safety concept
Specification of technical safety requirements
4-7 System design
System design specification
5-6 Specification of HW safety requirements
Hardware safety requirements
6-6 Specification of SW safety requirements
Software safety requirements
Ove
rall
man
agem
ento
fsaf
ety
requ
i rem
ents
8-6
Ove
rall
man
agem
e nto
f saf
ety
requ
irem
ents
Pro
duct
dev e
lopm
ent
Con
cept
phas
e
Assumptions on functional safety concept
Assumptions on functional safety requirements
Af t
erS
OP
ASIL Capability
Assumptions on safety goals (ASIL Safety Element out of Context Capability per system failure )
SEooC Development
”Item” Development
3-7 Hazard analysis and risk assessment
Hazard analysis and risk assessment
3-7 Hazard analysis and risk assessment
Specification of safety goals
3-8 Functional safety concept
Specification of functional safety requirements
4-6 Specification of technical safety concept
Specification of technical safety requirements
4-7 System design
System design specification
5-6 Specification of HW safety requirements
Hardware safety requirements
6-6 Specification of SW safety requirements
Software safety requirements
Ove
rall
man
agem
ento
fsaf
ety
requ
i rem
ents
8-6
Ove
rall
man
agem
e nto
f saf
ety
requ
ire
3-7 Hazard analysis and risk assessment
Hazard analysis and risk assessment
3-7 Hazard analysis and risk assessment
Specification of safety goals
3-8 Functional safety concept
Specification of functional safety requirements
4-6 Specification of technical safety concept
Specification of technical safety requirements
4-7 System design
System design specification
5-6 Specification of HW safety requirements
Hardware safety requirements
6-6 Specification of SW safety requirements
Software safety requirements
Ove
rall
man
agem
ento
fsaf
ety
requ
i rem
ents
8-6
Ove
rall
man
agem
e nto
f saf
ety
requ
irem
ents
Pro
duct
dev e
lopm
ent
Con
cept
phas
e
Assumptions on functional safety concept
Assumptions on functional safety requirements
Af t
erS
OP
ASIL Capability
Assumptions on safety goals (ASIL Safety Element out of Context Capability per system failure )
SEooC Development
”Item” Development
8 Nov. 201125
AUTOSAR and Functional SafetyRelationship 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
� 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
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR
3. Concept phase
2. Management of functional safety
2-5 Overall safety management 2-6 Safety management during item development
7. Production and operation
6-5 Initiation of product development at the software level6-6 Specification of software safety requirements6-7 Software architectural design
6-8 Software unit design and implementation
6-9 Software unit testing
6-10 Software integration and testing
6-11 Verification of software safety requirements
5-5 Initiation of product development at the hardware level5-6 Specification of hardware safety requirements5-7 Hardware design
5-8 Hardware architectural metrics
5-10 Hardware integration and testing
Cor
e pr
oces
ses
2-7 Safety management after release for production
3-6 Initiation of the safety lifecycle
1. Vocabulary
3-5 Item definition
3-7 Hazard analysis and risk assessment
3-8 Functional safety concept
7-5 Operation, service (maintenance and repair), and decommissioning
7-5 Production
8. Supporting processes
8-5 Interfaces within distributed developments8-6 Specification and management of safety requirements
8-8 Change management8-9 Verification
8-7 Configuration management
4. Product development: system level
4-5 Initiation of product development at the system level
4-7 System design 4-8 Item integration and testing
4-9 Safety validation
4-10 Functional safety assessment
4-11 Release for production
6. Product development:software level
5. Product development:hardware level
5-9 Evaluation of violation of the safety goal due to random HW failures
4-6 Specification of the technical safety requirements
9. ASIL-oriented and safety-oriented analyses9-5 Requirements decomposition with respect to ASIL tailoring9-6 Criteria for coexistence of elements
8-10 Documentation8-11 Qualification of software tools
8-13 Qualification of hardware components8-14 Proven in use argument
8-12 Qualification of software components
9-7 Analysis of dependent failures9-8 Safety analyses
10. Guideline on ISO 26262 (informative)
Chapters to be considered by Implementers
8 Nov. 201126
AUTOSAR and Functional SafetyConclusion
� 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
Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR