What you’ll learn:
- How to bridge the gaps between requirements, architecture, design, verification, and validation.
- How to use requirements management to support ISO 26262 standards.
The ISO 26262 standard states that functional-safety assessors should consider if requirements management, including bidirectional traceability, is adequately implemented. The standard doesn’t specify how an assessor should go about accomplishing this task. However, it’s reasonable to assume that a limited subset of connections between requirements and implementation probably doesn’t rise to the expectation.
An apparently simple requirement from a customer, such as “The software interface of the device should be compliant in all respects with specification ABCD-123, except where explicitly noted elsewhere in these requirements,” expands into a very complex set of requirements when fully elaborated.
How can an architect and design team effectively manage this level of traceability amid a mountain of specifications and requirements lists? How can they ensure that what they have built and tested at each step of the development cycle ties back to the original requirements (Fig. 1)? This is especially challenging since handoffs between requirements, architecture, design, verification, and validation depend on human interpretation to bridge the gaps between these steps.
The Default Approach to Traceability
The most obvious way to implement traceability is through a matrix, whether implemented in a dedicated tool like Jama Connect or an Excel spreadsheet. One requirement per line, maybe hierarchically organized, with ownership, source reference, implementation reference, status and so on. This matrix is a bidirectional reference.
Matrices can work well when they’re relatively small. Perhaps the architect will split these up into sub-teams and assign the responsibility for checking correspondence between sub-matrices and the system matrix to an integrator.
Matrices become unmanageable, though, when the number of requirements moves into the thousands. A matrix provides a disciplined way to organize data, but it doesn’t provide automation. Ensuring correspondence between requirements and implementation is still a manual task.
First Steps to Automation
The core problem is connecting between domains that speak very different languages: requirements management, documentation, chip assembly, verification, and hardware/software interface (HSI) descriptions. One approach common in software and mechanical systems is through application-lifecycle-management (ALM) or product-lifecycle-management (PLM) solutions, where all development tools are offered under a common umbrella by a single provider. With that level of control, an ALM or PLM could manage traceability in data between these domains.
However, it’s difficult to see how that kind of integration could work with electronic-design-automation (EDA) tool flows, where the overriding priority is to stay current with leading technologies and complexities. System-on-chip (SoC) development teams demand best-in-class flows and are unlikely to settle for solutions offering traceability at the expense of lower capability.
A second approach expands the scope of requirements-management tools by connecting to data assets within implementation files. Requirements tools naturally have no semantic understanding of these foreign objects, so all responsibility to capture, check, and maintain these links still rests entirely with the SoC development team. Tracing is simplified under a common interface, but the approach doesn’t significantly reduce manual effort or opportunity for errors in creation or maintenance.
Semantically Aware Traceability Links
Effective automation requires some level of semantic understanding in each domain: requirements, assembly, documentation, and HSI. It’s not necessary to comprehend every possible object, only those likely to be referenced through requirements. Standards help with “best-in-class” compatibility: ReqIF for requirements, DITA for documentation and IP-XACT (an XML format) for assembly, and HSI. A tool like Arteris’s Harmony Trace can tie all this together (Fig. 2).
Trace links should connect to meaningful objects – a requirement object, a port width, an IP version, and configuration or a register offset. Rather than file and line number links, these can move around as requirements, implementation, and verification evolve and remain valid. Some effort is required to establish links at the outset, but checking the impact of changes is automatic after that.
Moreover, there’s opportunity to derive many of these links from the data. In IP-XACT, such objects are easy to find. With a little more intelligence, they also can be found in documentation and requirements descriptions.
Semantic connectivity simplifies checking the completeness of tracing and diagnosis of problems. As development moves from concept to architect to design, then through unit testing, system testing, and full system validation in the V-development flow, floating or incomplete links immediately become apparent, whether from requirements, implementation, or documentation. The source of the problem is also immediately obvious. In addition, customers or auditors can instantly see evidence that a compliant implementation meets a requirement.