iso 26262 and autosar. requirements and solutions for safety

ISO 26262 and AUTOSAR. Requirements and Solutions for Safety Related Software.

Simon Fürst.5th Vector Congress.1st and 2nd December 2010, Stuttgart.

5. Vector CongressISO 26262 and AUTOSARSimon Fürst2. Dec. 2010Page 3

ISO 26262 and AUTOSAR. Preamble.

− ISO 26262 address the development of safety-related systems

� AUTOSAR is “only” the infrastructure part of the software of a systemsystem

− ISO 26262 contains two different kind of requirements

− Process related requirements: “how to develop the system”

− Technical requirements: “what system to develop”

� The AUTOSAR development partnership as well as the implementers of AUTOSAR have to respect both

− AUTOSAR only provides specifications− AUTOSAR only provides specifications

� Only a subset of the requirements of ISO 26262 are applicable

� For the implementers of AUTOSAR an overlapping subset of the requirements of ISO 26262 are applicable


ISO 26262 and AUTOSAR. AUTOSAR.

What has AUTOSAR done so far?


ISO 26262 and AUTOSAR. AUTOSAR’s basic approach.

Virtual Integration

AU

TO

SA

R

SW

-C1 AU

TO

SA

R

SW

-C2 A

UT

OS

AR

SW

-C3 AU

TO

SA

R

SW

-Cn

...

SW-CDescription

SW-CDescription

SW-CDescription

SW-CDescription

Virtual Integration

Independent of hardware

Virtual Functional Bus

Introduction of HW Attributes

Holistic view of the entire system,

both software and hardware

Virtual Functional Bus

System Constraint Description

ECU Descriptions

Tool Supporting development of SW components

ECU Configuration

Run-Time Environment

Separation of system into its ECU

(plus common infrastructure)

ECU I ECU II

AUTOSAR SW-C 1

AUTOSAR SW-C3

AUTOSAR SW-C 2

ECU n

AUTOSAR SW-C n

RTE

Basic Software

RTE

Basic Software

RTE

Basic Software

...

Gateway

ECU Description

ECU Description

Flex Ray CAN

System Description


ISO 26262 and AUTOSAR. AUTOSAR Methodology.

Component

APIGenerator

Component

APIe.g. app.h

ECU Configuration

SW-CImplementation

SystemConfigurationDescription

AUTOSAR

SystemConfiguration

Generator

SW-

ComponentDescription

ECU

ResourceDescription

(HW only)

ECU ConfigurationDescription

AUTOSAR

ECUConfiguration

Generator

RTE extract of

ECU configuration

OS extract of

ECU configuration

Basic SW

e.g. OIL

ECU extract

of SystemConfiguration

AUTOSAR

RTEGenerator

OS, COM, …

Generator

Generation step:complex algorithm or engineering work

Information / Database (no files)

per ECU

System –

ConstraintDescription

Basic SW

Module A extractof ECU

configuration

Basic SW


configuration

Basic SW


configuration

List of

implementationsof SW

components

ECU extract

of SystemConfigurationDecisions (e.g.

mapping)

Other Basic

SW Generator

MCAL –

Generator

Decisions (e.g. scheduling, …)

System


ISO 26262 und AUTOSAR. Approach of AUTOSAR w.r.t. Functional Safety.

Requirements from Applications

Requirements from WPs & WGs

Requirements from Safety Concepts

ISO WD 26262

Sou

rces

Consolidated Safety Requirements

Process SafetyRequirements

AUTOSARSafety

Guidelines

Technical SafetyRequirements

Interface Class 1

Str

uctu

re a

nd A

lloca

tio

n

Methodology SafetyRequirements

Tools

Generation

Interface Class 3

SW-C HW

ECUSensor

Actor

Consolidated Safety Requirements

List of safety requirements

allocated to methodology

List of requirements on

Assig

nm

ent

Str

uctu

re a

nd A

lloca

tio

n

Development Process

BSW & RTE

Tools

BSW & RTE Requirements

SRS

SWS

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

Requirements on tools

and generation process

List of requirements on

development processes


ISO 26262 and AUTOSAR. Overview of available, built-in AUTOSAR safety mechanisms.

−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


ISO 26262 and AUTOSAR. Built in safety mechanisms for detecting errors.

− Memory:− RAM Test− Flash Test

− Logical and temporal program flow monitoring

− Flash Test− Support for ECC memory

− Core:− Core Test

Microcontroller Drivers Memory Drivers

Onboard Device Abstraction

Watchdog Interface

System Services

Watchdog Manager (WdgM)

Microcontroller

EE

PR

OM

FLA

SH

WD

T

GP

T

RA

M T

est

Watc

hdog D

river

MC

U D

river

Co

re T

est

MC

U

Po

wer &

C

lock U

nit

Fla

sh

Test

RA

M

COM Drivers

µC

Microcontroller Drivers

SPIHandlerDriver

SP

I

internal watchdog

driver

Int. W

dg

External Watchdog Driver

Ext. W

dg


ISO 26262 and AUTOSAR. 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 actionsapplication-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 resetreaction – ECU reset

− Errors detected my MMU/MPU (memory and time partitioning). It will shut down or restart the faulty SW-C partition


ISO 26262 and AUTOSAR. Memory partitioning for SW-Cs.

− 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: − 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 AUTOSAR Runtime Environment (RTE)

ActuatorSoftware

Component

AUTOSARInterface

ApplicationSoftware

Component

SensorSoftware

Component

ApplicationSoftware

Component

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

AUTOSARSoftware

AUTOSARInterface

AUTOSARInterface

AUTOSARInterface

full access to memory, CPU and all other hard-ware resources

ECU-Hardware

AUTOSAR Runtime Environment (RTE)

Basic Software

StandardizedInterface

MicrocontrollerAbstraction

StandardizedAUTOSARInterface

Services


ECUAbstraction

AUTOSARInterface


ComplexDeviceDrivers

AUTOSARInterface


Communication



OperatingSystem

Sta

nd

ard

ize

dIn

tefa

ce


ISO 26262 and AUTOSAR. End-to-End communication protection (1/2).

− E2E protection detects faults in data caused by both hardware and in software

Libraries OS-Application 1OS-Application 2

Typical sources of interferences, causing errors detected by E2E protection:

CDD

AUTOSAR Runtime Environment (RTE)

I/O Hardware AbstractionMemory ServicesSystem Services Communication Services

Sender

IOC

Receiver 1

S1

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

S2

H3

S3

Microcontroller 1 / ECU 1

Microcontroller Drivers Memory Drivers I/O Drivers

Memory Hardware Abstraction

Onboard Device Abstraction

Communication Drivers

Communication Hardware Abstraction

Receiver 2

Microcontroller 2 / ECU 2

Direct function call

or on the communication between cores

S3

H3 H4


ISO 26262 and AUTOSAR. End-to-End communication protection (2/2).

− 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, 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 Sig1CounterCRC Sig10xFF0xF

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


ISO 26262 and AUTOSAR. Safety mechanisms supported by AUTOSAR.

− Implementation of typical safety concepts in the automotive domain− Intelligent HW watchdog (ASIC) / 3-level safety concept− 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


ISO 26262 and AUTOSAR. Application redundancy.

− Assuming integrity of HW/ECU and AUTOSAR Basic Software implementation, SW redundancy with ASIL decomposition can be used within the same ECU.decomposition can be used within the same ECU.

− Distribution of SW channels across ECUs is also possible.

SW-C Channel 1

AUTOSAR

SW-C Channel 2

SW-C Channel 1 SW-C Channel 2

µC core 1 µC core 2

ECU 1

SW-C Channel 1

AUTOSAR

ECU 2

AUTOSAR

SW-C Channel 2


ISO 26262 and AUTOSAR. 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 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


Runtime Environment

I/O Hardware Abstraction

I/O Signal Interface 1

Driver for ext.ADC ASIC



Runtime Environment

I/O Hardware Abstraction


Complex Drivers

ing on the same µC offering a redundant data path

COM Drivers

µC

I/O Drivers

DIO

Driv

er

SP

IHa

nd

ler

Driv

er

SP

I

DIO

ADC ASIC

AD

C D

rive

r 2

AD

C 2

AD

C D

rive

r 1

AD

C 1

COM Drivers

µC

AD

C D

rive

r 1

AD

C

Complex

Device

Driver

(non-

AUTOSAR)

HW

co

mp

on

en

t


ISO 26262 and AUTOSAR. AUTOSAR.

What is ISO 26262 saying?


ISO 26262 and AUTOSAR. Safety Element out of Context.

Idea− A SEooC is a pre-qualified safety element that is developed independently from an item development

− A SEooC must be usable in an item development while taking benefit − A SEooC must be usable in an item development while taking benefit from the work done during the pre-qualification

DefinitionA Safety Element out of Context (SEooC) is a safety element for which an item does not exist at the time of the development. A SEooC can either be a subsystem, a software component, or a hardware component.− A SEooC is never an item.− A SEooC can either be a subsystem, a hardware component, or a software component.− Typically, requirements at higher levels remain in the status "assumed" (see ISO°26262-8, − Typically, requirements at higher levels remain in the status "assumed" (see ISO°26262-8,

Clause°5) and will be confirmed when the SEooC is used in an item development.− The correct implementation of the assumed requirements will be verified during the SEooC

development, but the validation takes place during the item development. The development of a SEooC starts at a certain level of requirements and design, and all information on requirements or design prerequisites, are pre-determined in the status "assumed".

− Non-functional requirements might be in the status "assumed" at the same level of requirements where functional ones are in the status "accepted“.


ISO 26262 and AUTOSAR. SEooC and configurable software.

Configuration of an AUTOSAR Basic Software Stack is heavily based on−Configuration data and−Calibration dataConfiguration and calibration data is fully described in standardized XML templates


ISO 26262 und AUTOSAR. Part 6: Software architectural design (1/2).

Excerpt from chapter 7 “Software architectural design”

7.4.3 The software architectural design shall exhibit the following 7.4.3 The software architectural design shall exhibit the following properties by use of the principles listed in Table 4:a) modularity;b) encapsulation and;c) minimum complexity.

Table 4 — Principles for software architectural design Methods ASIL

A B C D

1a Hierarchical structure of software components ++ ++ ++ ++1a Hierarchical structure of software components ++ ++ ++ ++

1b Restricted size of software components ++ ++ ++ ++

1c Restricted size of interfaces + + + +

1d High cohesion within each software component + ++ ++ ++

1e Restricted coupling between software components + ++ ++ ++

1f Appropriate scheduling properties ++ ++ ++ ++

1g Restricted use of interrupts + + + ++


ISO 26262 und AUTOSAR. Part 6: Software architectural design (2/2).

Table 5 —Mechanisms for error detection at software architectural level

MethodsASIL

A B C D

Table 6 —Mechanisms for error handling at software architectural level

1a Plausibility checka ++ ++ ++ ++

1b Detection of data errorsb + + + +

1c External monitoring facility o + + ++

1d Control flow monitoring o + ++ ++

1e Diverse software designc o o + ++

a Plausibility checks include assertion checks. Complex plausibility checks can be realised by using a reference model of the desiredbehaviour.

b Types of methods that may be used to detect data errors include error detecting codes and multiple data storage.c Diverse software design is not intended to imply n-version programming.

ASILMethods

ASIL

A B C D

1a Static recovery mechanisma + + + +

1b Graceful degradationb + + ++ ++

1c Independent parallel redundancyc o o + ++

1d Correcting codes for data + + + +

a Static recovery mechanisms can be realised by recovery blocks, backward recovery, forward recovery and recovery throughrepetition.

b Graceful degradation at the software level refers to prioritising functions to minimise the adverse effects of potential failures onfunctional safety.c For parallel redundancy to be independent there has to be dissimilar software in each parallel path.


ISO 26262 and AUTOSAR. Safety lifecycle for AUTOSAR as SEooC.

3. Concept phase

2. Management of functional safety

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

7. Production and operation

2-7 Safety management after release for production

1. Vocabulary

3-5 Item definition 7-5 Production

4. Product development: system level

4-5 Initiation of product development at the system level

4-11 Release for production

Chapters to be considered by AUTOSAR

6-5 Initiation of product development at the software level6-6 Specification of software safety requirements

6-7 Software architectural design

6-8 Software unit design and implementation

6-9 Software unit testing

6-10 Software integration and

5-5 Initiation of product development at the hardware level5-6 Specification of hardware safety requirements

5-7 Hardware design

5-8 Hardware architectural metrics

5-10 Hardware integration and

Co

re p

roc

ess

es

3-6 Initiation of the safety lifecycle

3-7 Hazard analysis and risk assessment

3-8 Functional safety concept

7-5 Operation, service (maintenance and repair), and decommissioning

4-7 System design 4-8 Item integration and testing

4-9 Safety validation

4-10 Functional safety assessment

6. Product development:

software level


hardware level

5-9 Evaluation of violation of the safety goal due to random HW failures

4-6 Specification of the technical safety requirements

6-10 Software integration and testing

6-11 Verification of software safety requirements

5-10 Hardware integration and testing

8. Supporting processes

8-5 Interfaces within distributed developments

8-6 Specification and management of safety requirements

8-8 Change management

8-9 Verification

8-7 Configuration management

9. ASIL-oriented and safety-oriented analyses

9-5 Requirements decomposition with respect to ASIL tailoring

9-6 Criteria for coexistence of elements

8-10 Documentation

8-11 Qualification of software tools

8-13 Qualification of hardware components

8-14 Proven in use argument

8-12 Qualification of software components

9-7 Analysis of dependent failures

9-8 Safety analyses

10. Guideline on ISO 26262 (informative)


ISO 26262 and AUTOSAR. Safety lifecycle for Implementers of 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

2-7 Safety management after release for production

1. Vocabulary

3-5 Item definition 7-5 Production

4. Product development: system level

4-5 Initiation of product development at the system level

4-11 Release for production

Chapters to be considered by Implementers

6-5 Initiation of product development at the software level6-6 Specification of software safety requirements

6-7 Software architectural design

6-8 Software unit design and implementation

6-9 Software unit testing

6-10 Software integration and

5-5 Initiation of product development at the hardware level5-6 Specification of hardware safety requirements

5-7 Hardware design

5-8 Hardware architectural metrics

5-10 Hardware integration and

Co

re p

roc

ess

es

3-6 Initiation of the safety lifecycle

3-7 Hazard analysis and risk assessment

3-8 Functional safety concept

7-5 Operation, service (maintenance and repair), and decommissioning

4-7 System design 4-8 Item integration and testing

4-9 Safety validation

4-10 Functional safety assessment


software level


hardware level

5-9 Evaluation of violation of the safety goal due to random HW failures

4-6 Specification of the technical safety requirements

Implementers

6-10 Software integration and testing

6-11 Verification of software safety requirements

5-10 Hardware integration and testing

8. Supporting processes

8-5 Interfaces within distributed developments

8-6 Specification and management of safety requirements

8-8 Change management

8-9 Verification

8-7 Configuration management

9. ASIL-oriented and safety-oriented analyses

9-5 Requirements decomposition with respect to ASIL tailoring

9-6 Criteria for coexistence of elements

8-10 Documentation

8-11 Qualification of software tools

8-13 Qualification of hardware components

8-14 Proven in use argument

8-12 Qualification of software components

9-7 Analysis of dependent failures

9-8 Safety analyses

10. Guideline on ISO 26262 (informative)


ISO 26262 and AUTOSAR. Conclusion.

− AUTOSAR systematically derived safety mechanisms supported in R4.0

− AUTOSAR provides support for dedicated safety mechanisms with generic fault modelsgeneric fault models

− 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

− During system and software design the safety manual is considered to − During system and software design the safety manual is considered to appropriately use the safety mechanisms of an AUTOSAR implementation.

− Safety related systems can by build with AUTOSAR compliant systems.


ISO 26262 und AUTOSAR.Thank you for your attention.


ISO 26262 and AUTOSAR. Backup.


ISO 26262 and AUTOSAR. Software reference phase model.


ISO 26262 and AUTOSAR. Requirements, design and test phases.

Design PhasesRequirements Phases

3-7 Safetygoals

Test Phases

4-9System safety

validation

3-5Item

definition

3-8Functional

safety

requirements

4-6 Technical

safety

requirements

3-7Functionalsafety

concept

4-6/7Technicalsafety

concept

6-66-6 SW safety

3-8, 4-6Systemsafety

requirements

6-10

4-8System

integration

test

validation

System design V 0.1

System design V 0.2

System design V 1.0

3-8Preliminary architectural

assumptions

4-7System design

6-7

definition

Requirements, design and test flowRequirements / design interaction

Softwaresafety

requirements

6-6 SW safety requirements

at architectural

level

6-6SW safety

requirements

at unit level

6-9Software unit

test

6-10Software

integration

test

6-8Software unit

design

6-7Software

architectural

design

iso 26262 and autosar. requirements and solutions for safety

Documents