ISO 26262 Traceability Requirements for Automotive Electronics Design

Reading the many articles on SemiWiki and other publications we find experts talking about the automotive market, mostly because it’s in growth mode, has large volumes and vehicles consume more semiconductors every year. OK, that’s on the plus side, but what about functional safety for automotive electronics? Every time that an autonomous car has an accident or a fatality it makes front page news on CNN and across social media, so we’re keen to understand how safety is supposed to protect us from driving mishaps. The automotive industry has already published a functional safety standard known as ISO 26262, which is a necessary first step, and for us in the design community we need to be aware that this standard mandates traceability requirements.

An automotive system starts out in the conceptual phase with a set of written requirements, then as the system is refined into hardware, software and firmware we need to be able to trace and document how every requirement gets designed, implemented and tested. Because of time to market and complexity, there are no companies using a purely manual system for traceability of requirements, instead each team is using some form of software automation.

So the ISO 26262 standard covers the following range of activities which are part of a 10-part guildeline:

• Conceptual phase
• System level design
• Design
• Verification
• Testing

Everything that a team does in these five activities must be traced back to a requirement. Here’s a snapshot of what the 10-part ISO 26262 guideline looks like:

Design Challenges
Some IC design teams can have hundreds of engineers assigned to a single project, and across such teams there is a variety of software being used, like:

• Data management systems (Perforce) – tracking design files
• Bug tracking (Bugzilla)
• Verification plans and continuous integration (Jenkins)
• Workspace management tools
• IC point design tools (Cadence, Mentor, Synopsys, Ansys, etc.)

Semiconductor IP is purchased, re-used and created for teams designing an SoC, so this all has to be managed and tracked. Here’s a simplified work flow for IC design teams, and the large blue arrow pointing back to the left means that all this data needs to be traced back to requirements:

Modern IC designs can consume Terabytes of design, verification and test data across thousands to millions of files, which makes compliance with ISO 26262 traceability sound rather daunting. Having a software platform to manage all of this for us sounds ideal, a way to manage all of the data and IP blocks across my entire team and geographies. I’d call this IP Lifecycle Management (IPLM).

One commercial IP Lifecycle Management system out there is called Percipient, from Methodics, and I’ve blogged about them before over the past year or so. The Percipient tool is engineered to meet the needs of traceability requirements for the ISO 26262 standard, and here are some of the other industry tools it works well with:

Abstraction

With Percipient a design team can now connect high-level requirements to documentation to design to manufacturing, with traceability built-in. This methodology will keep track of all your semiconductor IP, cell libraries, scripts, verification files, results, bugs and even bug fixes. You use Percipient in all six phases of design to manufacturing:

The abstraction model used by Percipient enables it find and track all data from your SoC design project, it even knows low-level details like file permissions, bug tracking, locations for all IP instances, who is using each IP block, who owns an IP block, who created a cell, and even which workspace it all belongs to. Industry tools play well together with Percipient, by design. Here’s a quick summary of useful features in Percipient:

• Workspace tracking
• IP usage tracking
• Release management
• Bug tracking
• IP versioning
• Tracking design files
• Tracking file permissions
• Uses labels and custom fields
• Handles hierarchy
• Hooks for integrating any other tool

Self-documentation is a goal of the ISO 26262 standard and using a tool like Percipient really automates that process.

Summary
Driving a car today provides us mobility and we all want to arrive at our destination safely and without drama, so the automotive industry has wisely created and followed the ISO 266262 standard for functional safety requirements. The traceability part of the standard is now automated for semiconductor design through the use of a tool like Percipient. With it’s unique IP abstraction model this approach provides traceability across design, verification and testing.

The folks at Methodics will be attending the ISO 26262 To Semiconductors USA conference, June 11-14 in Michigan.

Read the complete White Paper here, after a brief registration process.

Related

• Combining IP and Product Lifecycle Tools
• SoC Design Management with Git
• Hierarchy Applied to Semiconductor IP Reuse
• Achieving Requirements Traceability from Concept through Design and Test