A risk-based approach to determining Automotive Safety Integrity Levels - Embedded.com

A risk-based approach to determining Automotive Safety Integrity Levels

With recentquality concerns, the automotive industryhas started looking seriously at ways toimprove software development. The increaseduse of electronic systems that affect thecar’s safety has driven automotive companiesto look at standards such as ISO/DIS 26262to help them comply with the specific needsof the electrical, electronic, andprogrammable electronic (E/E/PE) vehiclesystems.

The ISO/DIS 26262 standard provides arisk-based approach for determiningAutomotive Safety Integrity Levels (ASILs).There are four levels (A-D) of ASILs tospecify the necessary safety measures toavoid an unreasonable residual risk, with Drepresenting the most stringent level.

What ISO/DIS 26262 (Part 4) brings to thetable is an outline of the practice ofallocating technical safety requirements inthe system design. The standard mandates howto develop a design and specifies how toderive an item integration and testing planand subsequently the tests themselves.

In general, automotive companies are seekingto evolve and improve, whether to reduceoverhead or achieve a demonstrable level ofquality. As companies begin to incorporateISO/DIS 26262, the easiest way to prepare aplan for business evolution is by gapanalysis. The methodology starts bygathering data, then analyzing them to gaugethe difference between where the business iscurrently and where it wants to be. Gapanalysis examines operating processes andgenerated artifacts, typically employing athird party for the assessment. The outcomewill be notes and findings upon which thecompany or individual project principals mayact.

Companies involved in systems and softwaredevelopment for the automotive industry arenow joining counterparts in industries suchas aerospace and railroads in facingcompliance with a demanding standard. Theneed for such compliance has mandatedbusiness evolution in which processes andproject plans are documented, requirementscaptured, implementation and verificationcarried out with respect to therequirements, and all artifacts fullycontrolled in a configuration managementsystem.

Using gap analysis, companies have anestablished method that isolates the areasin which they need to improve with respectto a standard, such as ISO/DIS 26262.Theresults from the gap analysis allow thecompany to correctly and efficiently focusresources to achieve that improvement.

System shortfalls
When companies undergo gap analysis, theresults reveal the level of maturity withineach phase of the software developmentlifecycle, and the amount of tool investmentat each phase. Even when processes aremature and tools are adequate, the greatestshortfall typically stems from a failure toestablish traceability between the softwaredevelopment phases so that requirementsdirectly link to design, code, test, andverification stages of development. Gapanalysis reveals the shortcomings in thesystem, because even where each individualphase is well controlled and adequatelytooled, traceability between the phasestends to be lacking.

To compound the issue, as noted in a recentForresterreport , “Analyzing theinterdependencies that software designs havewith other cross-functional views—likelinking a camera’s zoom software with theelectrical motor, the electronics processor,and the mechanical lens and bearings—isoften a late-stage process conducted onlyafter the software is uploaded to the firstphysical prototype .” So, not only istraceability lacking between the variousstages of development, but it is lackingacross engineering disciplines—a factorwhich can only be exacerbated by thedistributed nature of automotive developmentteams.

For most commercially developed software,the construction and maintenance ofrequirements traceability matrices isperformed as a low-priority task and carriedout via manual methods such as Excelspreadsheets. Such approaches requirecontinuous human interaction andinterpretation of how traceability should beapplied, and manual effort to make anyupdates.

With a strong correlation betweenrequirements degradation and softwaredefects, companies are becoming more focusedon ways to mitigate this risk throughrigorous requirements and traceabilitymanagement. And, the cost of managingrequirements manually (the expense fortraditional manual approaches totraceability, verification, andcertification accounts for 50-70% of theoverall development budget for a projectdeveloped to the highest safety levels) iscreating mounting pressure to find betterways to comply to rigorous standards withoutescalating costs. Modern requirementsengineering and traceability toolsrepresents a way to maintain high-qualitysoftware with cost savings.

Requirements traceability
Requirements traceability is widely acceptedas a development best practice to ensurethat all requirements are implemented andthat all development artifacts can be tracedback to one or more requirements. ARequirements Traceability Matrix (RTM) isalso a key deliverable within manydevelopment standards.

Sidebar:Maintain bidirectional traceability ofrequirements
The intent of this specific practice is tomaintain the bidirectional traceability ofrequirements for each level of productdecomposition. When the requirements aremanaged well, traceability can beestablished from the source requirement toits lower level requirements, and from thelower level requirements back to theirsource. Such bidirectional traceabilityhelps determine that all sourcerequirements have been completelyaddressed and that all lower levelrequirements can be traced to a validsource. Requirements traceability can alsocover the relationships to other entitiessuch as intermediate and final workproducts, changes in design documentation,and test plans.

Despite good intentions, many projects fallinto a pattern of disjointed softwaredevelopment in which requirements, design,implementation, and testing artifacts areproduced from isolated development phases.Such isolation results in tenuous linksbetween that stage and development team andthe overall RTM.

Unfortunately, these situations can just aseasily occur on projects using state of theart requirements management tools, modelingtools, integrated development environments,and testing tools. Typically, this occursbecause many requirement management toolsuse centralized, database-style architectureand application models. With theseimplementations, there is plenty offunctionality to encourage good quality andgood management in the requirements domain,yet little to aid the downstream effortwhere projects are designed, implemented,and tested.

The tradition view of software developmentshows each phase flowing into the next,perhaps with feedback to earlier phases, anda surrounding framework of configurationmanagement and processes (e.g., Agile, RUP).Traceability is assumed to be part of therelationships between phases; however, themechanism by which trace links are recordedis seldom stated.

The reality is, while each individual phasemay be conducted efficiently thanks toinvestment in up-to-date tool technology,these tools are unlikely to contributedirectly to the RTM. As a result, the RTMbecomes increasingly poorly maintained overthe duration of projects and is typicallycompleted as a “rush job.” The net result isabsent or superficial cross checking betweenrequirements and implementation andconsequent inadequacies in the resultingsystem.

In truth, the RTM sits at the heart of anyproject (see Figure 1 below). Whether or notthe links are physically recorded andmanaged, they still exist. For example, adeveloper creates a link simply by reading adesign specification and using that to drivethe implementation.

Figure 1: The RTM sits at the heart of theproject, defining and describing theinteraction between the design, code, test,and verification stages of development.

To read more of this article go to “ Gap analysis forges the links from requirements to verification.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.