Applying ISO 26262

Part 2: Advanced 		
Application
•	 Article: ISO 26262 and E/E software safety risk			

www.iso26262-co...
ISO 26262 and E/E software safety risk
By Karen Wilhelm, Editor
Programmable and embedded electric/electronic
(E/E) system...
Upcoming SlideShare
Loading in...5
×

Article: ISO 26262 and E/E Software Safety Risk

298

Published on

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

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
298
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Article: ISO 26262 and E/E Software Safety Risk

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

×