AUTOSAR and Functional Safety - AUTOMOTIVE BASICS · PDF fileAUTOSAR and Functional Safety AUTOSAR Vision 3 8 Nov. 2011 Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR

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


� 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


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)


Component

..............

AUTOSAR Software

Basic Software

AUTOSAR Interface

Complex Device Drivers

Standardized Interface

Operating System

Actuator Software

Component

AUTOSAR Interface

Sensor Software

Component

AUTOSAR Interface


Component

AUTOSAR Interface


Standardized AUTOSAR Interface

AUTOSAR Interface

AUTOSAR Interface

Services


Communication


ECUAbstraction


Microcontroller Abstraction



AUTOSAR and Functional SafetySoftware Architecture: Software Abstraction inside the Infrastructure Architecture


ECU-Hardware


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


µ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


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


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


of ECUconfiguration


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 SafetyApproach of AUTOSAR with regard to Functional Safety.


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


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


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


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


ECU-Hardware


ActuatorSoftware

Component

AUTOSARInterface

ApplicationSoftware

Component

SensorSoftware

Component

ApplicationSoftware

Component

..............

AUTOSARSoftware

Basic SoftwareStandardized

Interface

AUTOSARInterface

AUTOSARInterface

AUTOSARInterface

MicrocontrollerAbstraction

StandardizedAUTOSARInterface

Services

StandardizedInterface

ECUAbstraction

AUTOSARInterface


ComplexDeviceDrivers

AUTOSARInterface


Communication



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


Libraries

CDD

Microcontroller 1 / ECU 1


Microcontroller Drivers Memory Drivers I/O Drivers



Memory ServicesSystem Services

Onboard Device Abstraction

Communication Drivers

Communication Hardware Abstraction


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


� 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


Libraries


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()


Libraries

E2E Lib

8 Nov. 201117


� 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


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


Libraries


OS-Application 1

SW-C 1

E2E Lib

1. Produce safe data elements

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


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







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


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..


µ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


SW-C Channel 1 SW-C Channel 2

Runtime Environment

COM Drivers


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


AD

C D

river 1 A

DC

1

SW-C Channel 1 SW-C Channel 2

Runtime Environment

COM Drivers



µC

AD

C D

river 1 A

DC

Complex Drivers

Complex Driver

HW

com

ponent

8 Nov. 201123







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


3-7 Hazard analysis and risk assessment

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









4-7 System design






Ove

rall

man

agem

ento

fsaf

ety

requ

i rem

ents

8-6

Ove

rall

man

agem

e nto

f saf

ety

requ

ire









4-7 System design






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


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



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


Documents

AUTOSAR and Functional Safety - AUTOMOTIVE BASICS · PDF fileAUTOSAR and Functional Safety AUTOSAR Vision 3 8 Nov. 2011 Safetronic 2011 - Simon Fürst - Functional Safety and AUTOSAR