AUTOSAR and Functional Safety PDF

AUTOSAR and Functional Safety
Simon Frst, BMW Group

Safetronic 2011
8 Nov. 2011, Sheraton Arabellapark Hotel, Munich
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 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.
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
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
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
..............
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
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
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
Overview
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
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
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
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
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
..............
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
Complex
Operating
Device
System
Drivers
Standardized
Interface
Basic Software Microcontroller
Abstraction
ECU-Hardware
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
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
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)
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
Overview
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
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
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
Overview
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 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
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
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

development at the hardware level
software level
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)
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

AUTOSAR and Functional Safety PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

AUTOSAR and Functional Safety PDF

Enviado por

Direitos autorais:

Formatos disponíveis

AUTOSAR and Functional Safety

Simon Frst, BMW Group

Basic aspects of AUTOSAR architecture and methodology

Safety mechanisms supported by AUTOSAR

Technical safety concepts supported by AUTOSAR

Relationship to ISO 26262 and Conclusion

AUTOSAR aims to standardize the software architecture of ECUs.

Hardware and software will be widely independent of each other.

Ports implement the interface according

in the basic software is

Application Actuator Sensor Application

Application Actuator Sensor Application

Software Software Software Software

AUTOSAR Runtime Environment (RTE)

Memory Hardware Abstraction

Memory Abstraction Interface

Microcontroller Memory Drivers Communication

COM Drivers Memory Drivers

SPI C EEPROM Flash

The AUTOSAR Meta Model

SW Component ECU Resource

M1: Model of the system

SW- System AUTOSAR

ECU OS, COM,

Basic aspects of AUTOSAR architecture and methodology

Safety mechanisms supported by AUTOSAR

Technical safety concepts supported by AUTOSAR

Relationship to ISO 26262 and Conclusion

Requirements from Requirements from Requirements from

Consolidated Safety Requirements

Process Safety Technical Safety Methodology Safety

Interface Class 1 SW-C HW Tools

BSW & RTE Tools and

Run-time mechanisms for preventing fault interference

Run-time mechanisms for protecting the communication

Run-time mechanisms for error handling

Memory: Watch Dog

Detected errors in the basic software:

Detected hardware errors:

Enables create protection boundaries around groups of SW-Cs

visor mode with AUTOSAR Runtime Environment (RTE)

Microcontroller Drivers Memory Drivers Communication Drivers I/O Drivers

Application is almost un-impacted by the introduction of end-to-end protection wrapper

wrapper encapsulates Application logic Application logic

the data protection and 1 Produce safe data elements

also invokes RTE

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

Data Id CRC 0xF Count Signal1 0xFF Signal 2

CRC := CRC8 over

Fully AUTOSAR compliant design with major impact on ASIL inheritance

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

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

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

Basic aspects of AUTOSAR architecture and methodology

Safety mechanisms supported by AUTOSAR

Technical safety concepts supported by AUTOSAR

Relationship to ISO 26262 and Conclusion

Implementation of typical safety concepts in the automotive domain

Application redundancy (on the same or different Cs)

Assuming integrity of HW/ECU and AUTOSAR basic software implementation, software

SW-C Channel 1 SW-C Channel 2