AUTOSAR and Functional Safety

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

2 8 Nov. 2011 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
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.
Customer needs
Yesterday AUTOSAR Adaptive Cruise Control
Lane Departure
Warning
Advanced Front
Application Software Lighting System
Software ..
standardized
Using standards
Communication Stack
OSEK
HW-specific Diagnostics
Hardware
CAN, FlexRay
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
Appli- Appli- Appli-
Ports are the interaction cation cation cation
Application
SW-C SW-C SW-C
points of software A B C

components.
Ports
The communication is
channeled via the RTE. RTE VFB RTE
AUTOSAR
Infrastructure
The communication layer BSW BSW

in the basic software is

encapsulated and not
Hardware
visible at the application Sensor

layer.
Communication Bus
Communication Path

4 8 Nov. 2011 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
AUTOSAR and Functional Safety
Software Architecture AUTOSAR Defined Interfaces

Application Actuator Sensor Application

Automotive Open System Software Software Software AUTOSAR Software
Architecture (AUTOSAR): Component Component Component Software Component
Standardized, openly disclosed AUTOSAR AUTOSAR AUTOSAR AUTOSAR
Interface Interface Interface .............. Interface
interfaces
HW independent SW layer AUTOSAR Runtime Environment (RTE)
Transferability of functions
Redundancy activation Standardized Standardized Standardized AUTOSAR AUTOSAR
Interface AUTOSAR Interface Interface Interface
Interface
ECU
AUTOSAR RTE: Services Communication
Abstraction
by specifying interfaces and their Standardized Standardized Standardized

Standardized
Interface Interface Interface
communication mechanisms, the

Interface
Complex
Operating
applications are decoupled from System
Device
Standardized Drivers
the underlying HW and Basic SW
Interface
by the RTE. This enables the Basic Software
Microcontroller
realization of re-usable Abstraction
application software ECU-Hardware
components.
Interfaces:
AUTOSAR Standard VFB & RTE BSW
Software Interface Software RTE relevant relevant relevant
Component

5 8 Nov. 2011 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
 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.

Application Actuator Sensor Application

Components

Software Software Software Software

Component Component Component
AUTOSAR Component
SW

Software
AUTOSAR AUTOSAR AUTOSAR AUTOSAR
Interface Interface Interface
..............
Memory Services
Interface

AUTOSAR Runtime Environment (RTE)

NVRAM Manager
System Services Memory Services Communication I/O Hardware Complex
Services Abstraction Drivers
Basic Software

Memory Hardware Abstraction

Memory Abstraction Interface

Onboard Device Memory Hardware Communication
Abstraction Abstraction Hardware Flash EEPROM
EEPROM Abstraction
Abstraction Emulation

Microcontroller Memory Drivers Communication

External I/O Drivers External Flash
Drivers EEPROM Driver
Drivers Driver
Resources

COM Drivers Memory Drivers

ECU

ECU-Hardware SPIHandler
Driver
EEPROM
Driver
Internal
Flash Driver

SPI C EEPROM Flash

6 8 Nov. 2011 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
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
All other top-level
M3: Model of the Meta Model packages Generic Structure
Common
(Meta-Meta Model) aggregate meta- Structure
(Defines UML Modeling classes from
Elements) Generic
Structure

SW Component ECU Resource

M2: Model of the model Template Template
(Meta Model)
(Defines AUTOSAR Modeling
Elements) System Template

M1: Model of the system

(Defines a real system)
ECU Description
Template

BSW Module
Template
M0: Realized System in the car
(Implements a real system) ECU Parameter
Def Template

7 8 Nov. 2011 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
AUTOSAR and Functional Safety
AUTOSAR Methodology Alternative Visualization

Component SW-C
Component API Implementation
API (e.g. app.h)
Generator
ECU Configuration
Description

SW- System AUTOSAR

Component Configuration RTE extract of RTE
Description Description ECU configuration Generator

ECU OS, COM,

AUTOSAR AUTOSAR OS extract of
Resource ECU extract Generator
System ECU ECU configuration
Description of System
Configuration Configuration
(HW only) Configuration e.g. OIL
Generator Generator

Basic SW
Basic SW Other Basic
ModuleBasic
A extract
SW
System Module A extract SW Generator
of ECU
Module
Constraint ECU extract of ECU extract
A
of System configuration
of ECU
Description Decisions Decisions configuration
Configuration (e.g. scheduling) configuration
(e.g. mapping)
List of MCAL
implementations Generator
Information / Database (no files) of SW
components
Generation step: System per ECU
complex algorithm or engineering work

8 8 Nov. 2011 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
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

9 8 Nov. 2011 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
 AUTOSAR and Functional Safety
Approach of AUTOSAR with regard to Functional Safety.

Requirements from Requirements from Requirements from

Sources

ISO WD 26262
WPs & WGs Applications Safety Concepts

Consolidated Safety Requirements

Process Safety Technical Safety Methodology Safety

Requirements Requirements Requirements
Structure and Allocation

Interface Class 1 SW-C HW Tools

AUTOSAR
Safety
Guidelines ECU Generation
Sensor
Interface Class 3 Actor List of safety requirements
allocated to methodology
List of requirements on
List of safety requirements
development processes
allocated to BSW & RTE

BSW & RTE Tools and

Development Process Generation Process
Requirements
Update of existing
Assignment

documents of WPs
BSW & RTE SRS Tools
Requirements on tools
Tools SWS and generation process Generation
Requirements on how to
develop AUTOSAR SW
and Tools

10 8 Nov. 2011 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
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 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
AUTOSAR and Functional Safety
Safety mechanisms for detecting errors.

Memory: Watch Dog

RAM Test Logical and temporal program flow
Flash Test monitoring
Support for ECC memory
Core:
Core Test

12 8 Nov. 2011 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
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 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
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 Application Actuator Sensor Application
Software AUTOSAR
Software Software Software
partitioned. It runs Component Component
Software
Component Component
AUTOSAR AUTOSAR AUTOSAR AUTOSAR
with in CPU super- Interface
..............
Interface Interface Interface

visor mode with AUTOSAR Runtime Environment (RTE)

full access to Standardized
Standardized
AUTOSAR AUTOSAR
Standardized
memory, CPU and Interface
AUTOSAR
Interface Interface Interface Interface

ECU
all other hard- Services Communication
Abstraction
Standardized Standardized Standardized
ware resources Standardized
Inteface
Interface Interface Interface
Complex
Operating
Device
System
Drivers
Standardized
Interface
Basic Software Microcontroller
Abstraction

ECU-Hardware

14 8 Nov. 2011 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
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 OS-Application 1
interferences, causing errors
detected by E2E protection:
Receiver 1 Sender
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
S1 OS
H3
AUTOSAR Runtime Environment (RTE)
HW-related sources:
H1. Microcontroller error during
System Services Memory Services Communication Services I/O Hardw are Abstraction CDD
core/partition switch
H2. Failure of HW network
S3 S2
H2. Network EMI
IOC
H3. Microcontroller failure
during context switch (partition)
or on the communication
Direct function between cores
call
Onboard Device Memory Hardware Communication Hardw are
Abstraction Abstraction Abstraction

S3
Receiver 2

Microcontroller Drivers Memory Drivers Communication Drivers I/O Drivers

H3 H4

Microcontroller 2
Microcontroller 1 / ECU 1 / ECU 2

15 8 Nov. 2011 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
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
OS-Application 2
End-to-End Protection
OS-Application 1

Sender 1 Receiver 1

wrapper encapsulates Application logic Application logic

the data protection and 1 Produce safe data elements

9 Consume safe data elements

also invokes RTE

2 Invoke safe transmission request - 6 Invoke safe read do get the data element
E2EPW_Write() - E2EPW_Read()
E2E protection wrapper E2E protection wrapper

3 Call E2E protect on array E2E_P0x_Protect() 8 Call E2E check on array - E2E_P0xCheck()

4 Invoke RTE - RTE_Write() to transmit the data element 7 Invoke RTE read - RTE_Read() to get the data element

AUTOSAR Runtime Environment (RTE) AUTOSAR Runtime Environment (RTE)

Libraries Libraries

5: RTE communication (intra or inter ECU), either through COM, IOC, or local in RTE

E2E E2E
Lib Lib

16 8 Nov. 2011 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
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 0xF Count Signal1 0xFF Signal 2

er

CRC := CRC8 over

(1) Data Id,
(2) all serialized signal (including empty areas, excluding CRC byte itself)

17 8 Nov. 2011 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
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
OS-Application 1
sender SW-C 1

1. Produce safe data elements

2. Invoke RTE - RTE_*_<p>_<o>() to transmit the data element

AUTOSAR Runtime Environment (RTE) 3. Map Data Elements to signals

Libraries
Communication Services

4. COM Signals

7. E2E_PXXProtect(&Config, &State,
(unit8*) IPduData) COM E2E
8. Execute E2E Library, wrte control fields E2E Lib COM 5. Serialize signals on I-PDU
(e.g. CRC, Counter) in IPduData
Callouts
9. Updated parameters State and IPduData

6. IPDU_E2EProtect_<IPDU ID>( PduId, IPduData)

11. If (ret = TRUE) deliver IPduData;
else no action

10. ret: TRUE if no error else FALSE; updated IPduData

PDU Router

18 8 Nov. 2011 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
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 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
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 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
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

AUTOSAR AUTOSAR
C core 1 C core 2

ECU 1 ECU 2

21 8 Nov. 2011 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
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 runn- I/O Hardware Abstraction I/O Hardware Abstraction Complex Drivers
ing on the I/O Signal Interface 1 I/O Signal Interface 2 I/O Signal Interface 1
same C
offering a Driver for ext.
ADC ASIC
redundant
Complex
data path COM Drivers I/O Drivers COM Drivers
Driver

ADC Driver 1
ADC Driver 1

ADC Driver 2
SPIHandler

DIO Driver
Driver

component
ADC 1

ADC 2

ADC

HW
DIO
SPI

C C

22 8 Nov. 2011 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
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 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
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
3-7 Hazard analysis and risk
Concept phase

ASIL Capability assessment

Assumptions on safety goals (ASIL

Safety Element out of Context Specification of safety goals
Capability per system failure )
8-6 Overall management of safety requirements

Overall management of safety requirements

require

Assumptions on functional safety

3-8 Functional safety concept
concept

Assumptions on functional safety Specification of functional safety

requirements requirements

4-6 Specification of technical safety

concept

Specification of technical safety

requirements
Product development

4-7 System design

System design specification

5-6 Specification of HW safety 6-6 Specification of SW safety

requirements requirements

Hardware safety requirements Software safety requirements

After SOP

24 8 Nov. 2011 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
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

2-7 Safety management after release for

Implementers have to tailor

2-5 Overall safety management 2-6 Safety management during item development
production

Chapters to 3. Concept phase 4. Product development: system level 7. Production and operation

ISO 26262 according to their be considered

by
3-5 Item definition
4-5 Initiation of product
development at the system level
4-11 Release for production
7-5 Production

activities in the safety-lifecycle

Implementers 4-10 Functional safety assessment 7-5 Operation, service
3-6 Initiation of the safety lifecycle 4-6 Specification of the technical (maintenance and repair), and
safety requirements decommissioning
4-9 Safety validation
3-7 Hazard analysis and risk
assessment
4-7 System design 4-8 Item integration and testing
3-8 Functional safety

Core processes
concept 5. Product development: 6. Product development:

For all implemented safety hardware level

5-5 Initiation of product
development at the hardware level
software level
6-5 Initiation of product
development at the software level

mechanisms a safety manual is

5-6 Specification of hardware 6-6 Specification of software safety
safety requirements requirements
5-7 Hardware design 6-7 Software architectural design

needed containing 5-8 Hardware architectural metrics

5-9 Evaluation of violation of the
6-8 Software unit design and
implementation

6-9 Software unit testing

safety goal due to random HW
failures

The fault model according to 5-10 Hardware integration and

testing
6-10 Software integration and
testing
6-11 Verification of software safety

which the safety mechanism requirements

8. Supporting processes

was developed 8-5 Interfaces within distributed developments

8-6 Specification and management of safety requirements
8-10 Documentation
8-11 Qualification of software tools
8-7 Configuration management 8-12 Qualification of software components

The constraints that must be 8-8 Change management

8-9 Verification
8-13 Qualification of hardware components
8-14 Proven in use argument

fulfilled when applying a safety 9. ASIL-oriented and safety-oriented analyses

9-5 Requirements decomposition with respect to ASIL tailoring 9-7 Analysis of dependent failures
9-6 Criteria for coexistence of elements 9-8 Safety analyses

mechanism 10. Guideline on ISO 26262 (informative)

25 8 Nov. 2011 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR
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 Safetronic 2011 - Simon Frst - Functional Safety and AUTOSAR