1April 2012

Intrinsic Safety of AUTOSAR Basic Software

In developing safety-related ECUs, the primary focus is on the

safety of new customer functions. Another challenge must be over-

come as well: Older ‘tried and true’ functions that are carried over

must be combined with ‘service functions’ (such as diagnostics or

bootloaders) and critical core components, and they must conform

to all functional safety requirements of ISO 26262. This requires

evaluating the risk potentials of both new and familiar functions

and implementing them according to the standard. Risk potential

is classified as an Automotive Safety Integrity Level (ASIL). When

the various classification levels are assigned to vehicle functions,

this results in a broad distribution of levels ranging from QM

(“quality managed”, no safety relevance) to ASIL D (maximum

safety relevance). In integrating functions with different safety

relevance levels, the standard requires that “freedom from inter-

ference” must be assured [1]. Carryover parts and software devel-

oped based on a QM process must not interfere with the safety-

relevant function. As a result, combining functions with different

ASIL classifications can require cost-intensive developments,

because proven functions need to be modified. This is often impos-

sible to achieve when one considers the narrow time windows of

development cycles and the close mutual interactions of many

sub-components.

To attain a lean implementation of the standard’s requirements,

a modular software platform is ideal; it must permit integration of

software functions of different producers and different safety clas-

sifications – ranging from QM to ASIL D – on a single ECU. Such an

implementation will be presented in the following. For the

customer, the platform enables reuse of proven but non-safety rel-

evant software in unmodified form, while maintaining the highest

levels of safety requirements.

Integrating software components with different safety relevance in one ECU

The newly established automotive standard ISO 26262 defines processes for developing safety-related ECU software. A high level of intrinsic safety of the individual software components is required to ensure that derived system-specific safety goals conform to the standard. This is also necessary to prevent potentially hazardous situations from occurring in case of error.

2

Technical Article

Integrating software functions from different manufac-turers and mixed ASIL classifications in one ECU

The core requirement of ISO 26262 for the integration of mixed

critical system parts is that the safety-relevant software must not

be affected or disturbed. The concept of “freedom from interfer-

ence” consists of three sub-requirements:

> No unintentional changes are made to the memory of the safety-

related function, e.g. it is not destroyed by “faulty pointer

accesses”.

> The safety-relevant function always has the specified execution

time available, i.e. it is not erroneously interrupted, started too

late, etc.

> The data that the safety-related function receives or sends remains

unaffected – i.e. it is not delayed, blocked, modified, etc.

In the following, a strategy is described that allows the coexis-

tence of safety-relevant and non-safety relevant software modules

on one ECU, such as a safety-relevant inverter monitoring unit and

a non-safety relevant diagnostic module. The individual actions of

this strategy assure that all three requirements are fulfilled.

The standard does not absolutely require that existing software

(e.g. AUTOSAR basic software) must be redeveloped to guarantee

freedom from interference, as long as the safety-relevant software

is not negatively affected or interfered with. Nonetheless, freedom

from interference between all software components – up to classi-

fication level ASIL D – must be constantly assured for the safety of

the overall system. This is accomplished by additional safeguarding

of software components by independent safety modules for memo-

ry access, program flow and communication areas as shown in

figure 1. Presented in the following are the functions of individual

safety modules that are used to achieve validation of the overall

system in ASIL D according to the requirements of ISO 26262 – with

reuse of existing basic software components. German based quality

specialists TÜV has pre-certified this solution to ISO 26262.

Protection against memory violations

Protection against unauthorized access to the memory area of a

safety-relevant software component is assured by an operating

system that supports memory protection mechanisms, specifically

a MICROSAR operating system of Scalability Class 3 or 4 (AUTOSAR

OS SC3/SC4). In this case, a Memory Protection Unit (MPU) imple-

ments the memory protection mechanism; this solution assumes

the use of a suitable microprocessor. The software part of the

MICROSAR operating system known as SafeContext controls the

isolation of software components during task switches and inter-

rupts. This prevents one software component from writing to the

memory of another software component without permission. Safe-

Context was developed to ASIL D and is therefore authorized to

reconfigure the memory ranges of the various tasks and interrupts

that are protected by the MPU at runtime. This arrangement also

assures conformance to ASIL D in saving and restoring context

data, including the MPU configuration.

The concept of the OS Application specified in AUTOSAR is used

to configure the operating system. This involves logically grouping

operating system objects such as tasks and interrupts and assign-

ing them to MPU configurations. Basic software modules

Figure 1: MICROSARE Safe

3April 2012

data contents. A message counter is used that can detect an incor-

rect message sequence, message failure or undesired repetitions.

Summary

All three of the safety modules presented here supplement one

another in their functionalities, and together they achieve freedom

from interference. They fulfill the highest requirement levels of ISO

26262 and can also be used in ASIL D ECUs. When they are integrat-

ed in MICROSAR – the AUTOSAR solution from Vector – they also

represent validated basic software from a single source.

The development effort that would otherwise be necessary to

bring software up to higher ASIL levels is avoided, where it is

unnecessary, by using software with various levels of safety rele-

vance and providing freedom from interference for these software

components. This leads to substantial cost optimizations. Integrat-

ing or linking pre-certified safety modules developed in compli-

ance with ISO 26262 ASIL D creates an overall software platform

that conforms to the highest necessary ASILs. Safety modules can

be integrated together with software applications and AUTOSAR

basic software components developed according to a QM standard.

Integrating ASIL D safety modules that guarantee freedom from

interference makes it possible for software modules of different

safety relevance to coexist. This can result in considerable cost sav-

ings in the development of safety-relevant modules. It also short-

ens development cycle times.

developed according to the QM process are combined in a separate

OS Application and are isolated from the software with ASIL classi-

fication. This also prevents the memory of ASIL software from

being overwritten by the basic software.

Protection against runtime interference

The Safe Watchdog Manager (SWdgM) is the safety mechanism that

is responsible for timing and program flow monitoring (Figure 2).

Safety-relevant functions are monitored to ensure that the func-

tions are executed in their correct sequential flow. Checkpoints in

all relevant software components regularly report to the Safe

Watchdog Manager on the program flow. This enables reliable

detection of all types of runtime interference. If an application,

interrupt or function is not activated in a timely manner, the Safe

Watchdog Manager detects this and initiates a reaction to the

error. Along with time durations, correct sequence in the program

flow is also monitored. The Safe Watchdog Manager services the

independent Hardware Watchdog, and – as a last resort – can reset

the ECU to a safe state in case of errors. If the Safe Watchdog

Manager itself is not correctly activated, the independent watch-

dog is not serviced, and the error reaction is also reliably initiated

in this case.

Protection against corruption of input/output data

The End-To-End Library (E2ELib) safeguards safety-relevant com-

munication in the Tx and Rx directions (Figure 3). The data is pro-

tected by a checksum here to enable detection of any corrupted

Fig ure 2: MICROSAR Safe Watchdog Manager

4

Technical Article

[1] ISO/DIS 26262: Road vehicles – Functional safety, Part 1-10.

International Organization for Standardization, 2009.

http://www.iso.org/

Translation of a German publication in Hanser automotive, issue 3-4/2012

Figures:

All figures: TTTech Automotive and Vector Informatik GmbH

Fig ure 3: SafeCOM Architecture

>> Your Contact:

Germany and all countries, not named belowVector Informatik GmbH, Stuttgart, Germany, www.vector.com

France, Belgium, Luxembourg Vector France, Paris, France, www.vector-france.com

Sweden, Denmark, Norway, Finland, IcelandVecScan AB, Göteborg, Sweden, www.vector-scandinavia.com

Great BritainVector GB Ltd., Birmingham, United Kingdom, www.vector-gb.co.uk

USA, Canada, MexicoVector CANtech, Inc., Detroit, USA, www.vector-cantech.com

JapanVector Japan Co., Ltd., Tokyo, Japan, www.vector-japan.co.jp

KoreaVector Korea IT Inc., Seoul, Republic of Korea, www.vector.kr

ChinaVector Automotive Technology Co., Ltd., www.vector-china.com

IndiaVector Informatik India Prv. Ltd., Pune, India, www.vector.in

E-Mail Contactinfo@vector.com

Dr. rer. nat. Matthias Krause works at Vector in the product management for embedded software and is responsible for the concepts and implementation of securi-ty-related AUTOSAR basic software.

Dipl. Ing. Dr. Carsten Weich is head of the automotive software develop-ment at TTTech. He was head of development projects for the series production of Audi, as well as security-related projects according to IEC 61508 and ISO 26262.