Traceability for Embedded Systems

By Paul Graykowski, Arteris IP

Traceability can seem an obscure and/or bureaucratic concept to most. It entails cross-checking requirements between a spreadsheet, specifications, and the implementation and verification, rinse and repeat. From a view in the trenches where real problems must be solved, it can be hard to understand how this exercise adds value. Indeed, if the design team perfectly understands all requirements at the outset and retains that perfect understanding through the design cycle as changes are made to meet power, performance, area (PPA) and other goals, and system/software requirements remain perfectly static through that whole period, there would be no need to keep checking. But few teams experience such an ideal project in practice. Understanding is not always perfect, and requirements are rarely completely static. Maintaining connection between requirements and implementation is where traceability for embedded systems can show value. Traceability support is mandatory for safety-critical systems, but the broader value in other complex embedded systems is worth reviewing.

Cross-checking Through the V-diagram

^{Click to enlarge}

System development, verification and validation

The V-diagram is a widely used representation of the systems development lifecycle. It graphs design evolution from concept to implementation and verification from low-level tests to full system validation. In the (left) development arm, the concept is progressively refined through requirements to architecture, then to more detailed design and ultimately to design implementation. In the right arm, verification starts with unit and subsystem tests, then progresses to integration tests and finally to full system validation. All of this is very familiar, but the process does not track the possibility of drifting away from original requirements or human translation errors across the gaps between islands of automation in the V.

In an embedded system, the hardware/software interface (HSI) is a representation of requirements between hardware and software development teams. This description elaborates a huge wealth of detail in memory and IP register offsets, bitfields and detailed behavior specifications. In this representation, at least some aspects must be met precisely. This expectation is especially important because many designs must work with legacy software, not only to minimize development time but also to preserve reliability. A new device replacing one from a different vendor must often mirror all or most of the original HSI. In this context, capturing those requirements and using traceability to track compliance through development becomes a clear advantage.

Spreadsheets for Traceability

The obvious solution for most of us is to capture requirements in a spreadsheet or maybe a dedicated tool like Jama Connect. In spreadsheet terminology, the table has one entry per requirement with columns to locate supporting artifacts in the implementation (file and function name, for example). Next is a similar column for test evidence, owners' names, status, and last checked date. A development team will probably organize the spreadsheet hierarchically, maybe even into multiple files by groups of requirements. This is standard engineering practice in tracking any kind of status. A part of each design review will be dedicated to checking correspondence between such spreadsheets and the corresponding design components.

Spreadsheets can work well when hundreds of requirements must be tracked. But the method breaks down when there is a need to track many thousands of requirements. Worse yet, it does not provide any obvious way to recognize changes in requirements. That problem can be solved by using a requirements-tracking tool. Such a tool certainly helps the requirements developers, but not the checkers. Checking is still manual, and changes may require updates for where supporting evidence can be found, demanding significant manual effort.

Arteris® Harmony Trace™ – Intelligent Traceability

The big challenge in establishing automated traceability across the scope of system design is that the tools and flows involved speak very different languages. From DOORS or Jama Connect for requirements to C++, SystemC and Matlab for architecture. From register-transfer level (RTL) for design to universal verification methodology (UVM) for unit and block-level test to Accellera's Portable Test and Stimulus Standard (PSS) for system-level verification. All of these tools are complemented by in-circuit emulation and lab testing for full system validation. Linking between these domains requires an intelligent approach to establishing and checking traceability across this wide range. At the same time, there is a need to limit what must be understood from each domain to just what is needed to support trace validation. Harmony Trace from Arteris IP provides that intelligent support.

^{Click to enlarge}

Bridging the gaps with Harmony Trace

Harmony Trace understands and can leverage multiple domain-specific standards: REQ-IF for requirements, IP-XACT for system-on-chip (SoC) assembly and HSI, and DITA for documentation. Since the tool understands the semantics in each domain, it can track domain-specific know-how, such as what version of an IP has been used and with what configuration or width a bus has. It can also note whether a bitfield supports simple read or will clear the bitfield on read. In addition, it can understand parametric tables in documentation and even parametric references in requirements to correlate between these domains. Further, when it tracks evidence references in implementation or test, it tracks the semantic objects, not "dumb" file/line references, providing much higher reliability in the currency of references as the design evolves.

These capabilities greatly simplify design review checking. Once a design team has set up initial requirements linkages to implementation and test, subsequent compliance checks become much easier. A hardware designer can jump straight to the evidence for a requirement and validate that both continue to provide valid support. Better yet, there is potential to automatically set up most initial linkages, which will remove a further level of manual effort in ensuring traceability.

Want to learn more? Click HERE to download the white paper.