Download the full article for FREE here: http://bit.ly/Software_Safety_Risk This exclusive article "ISO 26262 and E/E Software Safety Risk" details: • Product development at the software level • Using the V-Model to guide the software development process • Reusable software to accelerate development • Trend: Suppliers will make compliance easier • Safer driving with safer software Download the full article for FREE here: http://bit.ly/Software_Safety_Risk

1. Applying ISO 26262
Part 2: Advanced
Application
• Article: ISO 26262 and E/E software safety risk
www.iso26262-conference.com

2. ISO 26262 and E/E software safety risk
By Karen Wilhelm, Editor
Programmable and embedded electric/electronic
(E/E) systems in automobiles perform safety-critical
functions once controlled mechanically. Software in
each system that controls its function can contain
safety faults that must be discovered and corrected.
The complexity of safety-critical software has
increased exponentially, making managing safety
risk ever more difficult.
One of the things addressed by ISO 26262 is the
development of the software in E/E systems and the
importance of standardizing development and test
methods.
ISO 26262 Part 6,
Product development at the software level
them and develop plans for confirming that the
implementation behaves as intended. The team
also needs to determine the language to be used in
the models and in implementation, and select and
document any other tools to be used in software
development. A number of tools are on the market
for design, testing, and validation.
Using the V-Model to guide the software
development process
In ISO 26262, a V-Model is often used to represent
the development process because testing and
verification takes place in reverse order from design
and implementation.
The software level of component
design is divided into seven phases:
Initiation, safety requirements
specification, architectural design,
unit design and implementation, unit
testing, integration testing, and safety
requirements verification.
In addition to the design of
components, the design process itself
follows these phases. Among the
requirements defined by the design
team are modular design, identification
of software units, categorizing
components, failure analysis, safety
mechanisms, and error detection and
handling. The design team must select the software
development process and tools to be used, and
document their choice.
Model-based software design is often selected.
While ISO 26262 does not require the use of modelbased development, the value and importance of its
engineering paradigm is emphasized in Annex B of
ISO 26262-6. This means that model-based design
and ISO 26262 complement each other in that
both approaches aim for high quality development
processes for electronic embedded systems.
If models will be used, the team must also
implement appropriate software based on
The software development phase in ISO 26262 is subdivided
into sub-phases as in this V-Model. (In this image, the model
begins with “6” which should be considered the first step for the
sake of this discussion.) Diagram courtesy of Reactive Systems,
Inc.
The model-based development process has several
advantages. During the design phase, the model can
be tested against the requirements specification,
allowing design flaws to be found and fixed early
in the development process. Since the models are
graphical visual representations of system structure
and data flow, they are easier to comprehend than
written descriptions. The executable models make it
possible to automate implementation testing. When
design issues are found, the executable models can
be changed and re-tested. Model-based software
www.iso26262-conference.com