Intrinsic Safety of AUTOSAR Basic Software€¦ · · 2012-05-25Intrinsic Safety of AUTOSAR Basic...
Transcript of Intrinsic Safety of AUTOSAR Basic Software€¦ · · 2012-05-25Intrinsic Safety of AUTOSAR Basic...
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 [email protected]
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.