Simplifying The Road To ISO 26262 Compliance

By Joseph Dailey and Robert Bates

Since the release of ISO 26262 in November 2011, companies have had to figure out how to navigate the standard’s requirements throughout the development process of electrical and/or electronic systems for road vehicles. Recently new trends have emerged — software companies have started pre-qualifying both their software tools for use by their customers, as well as pre-certifying their embedded software that customers will use to build their applications. These developments have helped those teams streamline ISO 26262 compliance but also led to new questions, especially given the complexity of the design flow to build contemporary automotive electronics, among the most complex engineering work being done today.

Mentor Safe is a newly expanded initiative within Mentor Graphics to help address these concerns and to simplify the job of the system designer to conform to ISO 26262.

Software tool qualification
ISO 26262 gives criteria for determining the degree of confidence required for any design tool or an entire toolchain and methodology (i.e., a set of tools used together) used to create an end product. This product may be any safety-critical automotive ECU, such as those controlling the braking system or those on the dashboard display showing safety critical information, including digital speedometers, fuel gauges and so on.

Consider the case of the auto supplier attempting to comply with this part of the ISO 26262 requirements. For each step in the design flow, their design team must catalog their tool methodology for that step, and then they must assess both:

• The Tool Impact (TI), which measures the possibility that the tool methodology will either inject or fail to detect errors in the item, and
• The Tool error Detection probability (TD), which measures the confidence that the tool will either prevent errors being injected into the device, or that it will detect that this error has occurred. Note that this is a subjective measure, requiring strong argumentation for a rating of high confidence.

Note that the flow in question involves both the error detection capabilities of the tool as well as those of any processes in place to control the usage or to check the output of the tool. If a step in the flow is determined to be a tool confidence level 1 (TCL1), then no further evaluation for that step is required.

Here are three of the possible outcomes of a design team’s attempts to evaluate and classify a tool used to develop complex auto-related IC or system:

• The team may determine a tool’s use case to be TCL1 after the evaluation of their use cases. No further qualification is necessary.
• Due to lack of information on how the tool provider develops and verifies the tool, the team may misclassify the use case to be TCL2 or TCL3.
• The team may properly classify the use case as TCL2 or TCL3.

If a use case is classified as a TCL2 or TCL3, qualification is required, using measures specified in the standard, which can be difficult for the design team.

Mentor Safe provides all of the information needed to both properly classify the use case, and if a particular use case is TCL2 or 3, all of the qualification data needed to justify the tool’s use. Also, Mentor provides guidance to the team on other tools that might be used in their workflow to remove the uncertainty in the tool confidence, allowing the team to lower the TCL to TCL1.

Embedded software
Software tools are used by development teams to help them design and develop their products, while embedded software is used directly to help the product satisfy safety goals. As a result, embedded software is held to the same design and development standards as the software written by the development teams.

ISO 26262 creates the concept of a Safety Element out of Context (or SEooC). Most third party software providers, including Mentor, provide their software components as SEooCs. An SEooC is a software component that satisfies assumed safety requirements to the development guidelines of ISO 26262. In many cases, the software provider doesn’t know which of the requirements of their software will be safety relevant for a particular design, so they make the simplifying assumption that all requirements are safety relevant, which is precisely what Mentor does with their safety relevant software offerings such as VSTAR and Nucleus SafetyCert.

The main concerns when deploying embedded software as an SEooC is the assurance that the software was developed to the ISO 26262 guidelines, and that the embedded software comes with sufficient documentation to both allow successful integration of the components, as well as any caveats on its use that might cause safety-related problems. This information is generally provided in a Safety Case, which includes both the evidence of compliant development and a Safety Manual describing these integration requirements to successfully use the software. As part of Mentor Safe, Mentor Graphics assures that when a safety case is released that it is fully conformant to ISO 26262 as well as other industry standards as appropriate.

Mentor Safe expands upon Mentor Graphics’ broad focus on hardware, system and software design and embedded software to make it as simple as possible for designers to conform to ISO 26262.

Related whitepaper: Understanding Automotive Reliability and ISO 26262 for Safety-Critical Systems

Joseph Dailey is Mentor Graphics global functional safety manager based in Phoenix, Arizona.