Why Automate Traceability?

Over the years, Arteris IP has worked with several aerospace, transportation and automotive partners on design systems for avionics, space image processing and processing for scientific payloads. More recently, complex advanced driver-assistance systems (ADAS) projects at various levels of autonomy have been added to the list. One thing common between all these projects has been the tight coupling between system-level specification and all aspects of software and hardware from multiple suppliers and integrators, along with the very tight demands on safety and reliability. All are governed by standards like DO-254, ISO 26262, ECSS-Q80 and others. A common theme in all these standards is the expectation of being able to trace requirements from the system definition to implementation and verification. If a change is made anywhere which invalidates a requirement in this complex web of suppliers and integrators, that problem should be immediately detectable.

Figure 1: Traceability requires linking artifacts and decisions forwards and backwards in time, and at two different
levels: (1) Along the “V” and (2) Across the “V.”

There Is no Escaping Traceability

Although traceability has always been expected in aircraft and spacecraft design, the scope of safety-critical applications has grown beyond the traditional bounds. ISO 26262 requires that safety requirements in the automotive industry must be traceable. Also, IEC 61508 (general electronic safety) and IEC 60601 (medical electrical equipment) require traceability for functional safety. The bottom line, it is getting much harder to avoid traceability requirements.

This is no problem, an engineer might think. If a customer supplies its vendor with a long list of documents, the initial reflex is to reach for the engineer’s Swiss Army knife – Microsoft Excel. The idea is to map the key requirements into rows in a spreadsheet and then to augment those with assignments of the checking responsibilities, confirmation of latest status, notes on blocking, etcetera.

But how often should the document be checked? If it is only checked when the project is about to be signed off, accumulated problems in correspondence between requirements and implementation may require very painful rework. If, on the other hand, it is checked more frequently, that necessitates repeatedly comparing the requirements document and the implementation, which will quickly become tedious and, therefore, very error-prone.

Figure 2: Manual traceability through human inspection, tagging, and review is usually required to bridge
the “air gaps” between the multiple computer systems, tools, standards and databases used by the various
stakeholders and teams in the product development process. Automation reduces effort, duplication and the chance for
systematic errors.

The Limits of Excel

A Tier 1 customer in aerospace, defense and transportation brought this home in a presentation shared with us. As electronic systems, software and system-on-chip (SoC) become a larger part of the total system, traceability must extend further into the implementation of those components. At this customer’s level, spreadsheets must be hierarchical to address both the multiplication of suppliers and the increasing complexity of the components. The client was already very experienced in managing requirements and traceability through many documents and spreadsheets but shared that their engineers were starting to rebel. These engineers had signed up to design, verify and build complex electronic systems, not to spend most of their time building and checking Excel spreadsheets. The teams wanted more of this traceability management to be automated. SoC suppliers serving any of these system domains are beginning to see similar challenges.

This is why it is so common now to see requirements defined through platforms like IBM DOORS and Jama Connect. These requirement management tools standardize the starting point of the whole process rather than having requirements spread across multiple PDFs. However, they do not connect directly to electronic design automation (EDA) environments. That requires another level of standardization and automation.

Traceability Within an SoC

System requirements are written in terms of system objectives – intellectual property (IP) block configuration options, bus widths, memory maps, bandwidths and latencies. The standardizations needed here are for system-level modeling and SoC assembly. Also, the ability to accommodate transaction-level modeling (TLM)/virtual prototype models supporting software development and the ability to standardize the electronic documentation of assembly above the IP level have become key. The active standards here are IEEE 1666

SystemC/TLM and IEEE 1685 IP-XACT (which supports SystemC/TLM). IP-XACT is already widely used at the IP level and increasingly at the IP assembly and system levels. This standard provides an essential starting point to automate traceability.

Traceability is a very active area of research, especially in software. Fortunately, today’s traceability needs for SoC assembly are more bounded and can be quite well covered through label-matching techniques, perhaps augmented with natural language processing. For example, a bus width or a register name with characteristics can be tracked through links automatically generated from requirements through implementation. This process will not necessarily be hands-free – there may be ambiguities in some cases which require human resolution. Even then, per design or even design family, resolution is likely to be a one-time activity requiring little further human intervention beyond the first pass.

Automating traceability of requirements through modern SoC designs will replace unmanageable and unreliable Excel spreadsheets tracing with a practical alternative. Talk to us at Arteris IP to understand our direction in this important area.

Category: SOC

This entry was posted on Wednesday, October 13th, 2021 at 9:57 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.