Your SlideShare is downloading. ×
Article: ISO 26262 and E/E Software Safety Risk
Article: ISO 26262 and E/E Software Safety Risk
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Article: ISO 26262 and E/E Software Safety Risk


Published on

Download the full article for FREE here: …

Download the full article for FREE here:

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:

Published in: Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Applying ISO 26262 Part 2: Advanced Application • Article: ISO 26262 and E/E software safety risk
  • 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