Reinventing Traceability: Adding domain intelligence with Arteris Harmony Trace

Find the Latest SoC Solutions
for... Automotive... IoT... Security... Audio... Video

Arteris IP, Jan. 12, 2022 – 

What Is Traceability and Why Is it Needed?

Markets today depend on supply chains to deliver the advanced products on which modern economies run. Sub-components are sourced from manufacturers with expertise in each of their respective fields. Other experts higher in the chain assemble sub-components into subsystems. This continues up the supply chain until, ultimately, an OEM builds a finished product around an assembly of subsystems. Product manufacturing built on supply chains is now almost universal and works extremely well to make sophisticated products possible at attractive prices. The approach raises some concerns, however, such as mistakes creeping into the chain of complex and divided responsibilities and the ability to detect those mistakes. It would be impractical for integrators to test exhaustively the components they get from their suppliers. Instead, they rely on a "Trust but Verify" procedure. Suppliers must provide the means for integrators to determine exactly how each expectation was met. The method through which they do this is Traceability, a mechanism to step from each requirement down through the chain to supporting evidence in each sub-component. Making review possible is enough to ensure that all suppliers will strive to be as diligent as possible in compliance, even if that review will only take place on a random sample basis.

Semiconductor chips were historically viewed as one of the lowest levels in these chains. They were too hard to trace inside and were known to be dependable based on the manufacturer's reputation and ample evidence of reliability of their products in multiple markets. That viewpoint changed dramatically with the explosion of highly complex system-on-chip (SoC) devices into almost all applications. The advanced capabilities enjoyed in consumers' phones are now migrating into cars, homes, retail, finance, factories, communications, public infrastructure, aerospace and defense. Semiconductor companies continue to build many of these SoCs; however, companies higher in the supply chain now are also building SoCs as they seek differentiated advantages and faster time to market. These products are all new; none can boast long-established fit within their markets or benefit from proven reliability. New entrants and new products mean that quality through the supply chain – through traceability – must now continue down inside these semiconductor devices.

Fig. 1 Functional safety and quality standards require forward and backward traceability, which also helps meet change management and configuration management requirements. Source: ISO 26262-2:2011

Traceability isn't just a good idea. In safety-critical products, it is a requirement, either as a government regulation or an industry de-facto standard. For safety applications, it is important that tracing extends down as far as reasonable. The Spanghero canned horse meat scandal is a sobering example of not taking traceability far enough. There, traceability extended only down to barcodes on cans; fraud slipped through because the cans were later found to contain substandard meat. In safety-critical systems design, several standards require traceability down into SoCs. ISO 26262 defines this expectation for automotive and other vehicles. DO-254 does the same for aircraft electronics, and IEC 61508 details a similar expectation used as a reference in many other systems domains such as industrial applications.

As we all know, semiconductor product development is not a pure waterfall process, and specification changes are not unusual rippling up and down the supply chain. A better approach to traceability must enable change management processes that help supply chain participants stay connected to requirements and meet industry functional safety and quality requirements.

As essential contributors in the supply chains building the advanced products of tomorrow, SoC builders have little choice but to support traceability requirements down into their devices. No one wants to work with a Spanghero of SoCs.

The Path to Implementing Traceability

Traceability starts with a contract between the integrator and the component supplier. This might include a PDF specification, a requirements document and a definition of use-cases that should be tested against the design. The supplier commits to meeting the specification. Following this, the supplier architect and other teams refine the contract into more detailed requirements and test plans to guide their design teams in implementation and validation. Detailed product documents generated in this process are important for early marketing, helping the supplier sell the specification many months before a prototype becomes available. If the integrator makes a provisional commitment based on this specification, they can start software development for their ultimate product. However, then they expect the supplier to stick to what they committed. This expectation makes it very important to assess the several impacts of each minor change for any new requirement, meeting a local implementation goal or responding to other prospective customers.

The old way to implement traceability was to capture those elaborated requirements in a traceability matrix - a spreadsheet with one requirement per line and columns to track ownership, dependencies, and status. Twenty of the smartest engineers in the company would gather around a table, once a month for days at a time, to compare the spreadsheet with the detailed implementation, current verification status and other collateral generated by the design team. In the first review, this would be a very detailed, line-by-line check. Since design might take a year, there would be a natural eagerness to check "just whatever changed" in later reviews. But that choice often depends on subjective judgment; it is quite possible to overlook subtle but important changes in cursory checks.

Fig. 2 Harmony Trace™ addresses the gaps between different product lifecycle requirements, development, test and documentation systems by linking data between these sources. Source: Arteris IP

This process is very manual, very difficult to scale to larger systems, and error prone. It cries out to be automated. Because it deals with requirements, specifications, implementation, and other objectives, any automation must be able to talk intelligently to all necessary tools across these domains. One solution, called application lifecycle management (ALM) or product lifecycle management (PLM), aims to pull all tools under common control, usually under the control of a single vendor. This is challenging in most contexts given the breadth of applications and becomes essentially impossible in SoC design, where tools are based on deep computational algorithms and are constantly evolving to track technological advances. SoC makers assemble best-in-class tool suites from multiple suppliers and refine these selections as tool vendors advance their technology. No SoC design team will be willing to sacrifice this competitive edge simply to enable traceability.

A second approach is based on a surrogate mechanism. Requirements management tools allow the ability to import "foreign" artifacts as surrogate requirements, which can then be traced with the tool's requirements tracing methods. This method can work but relies on SoC teams to manage the conversion between SoC artifacts and surrogate requirements. All responsibility for semantic understanding of this mapping still rests with the designers. The requirements tool is inevitably unaware of whatever those designers miss or get wrong or instances where the meaning of an artifact may change during design.

A far superior approach is to avoid both problems through an independent tool with rich semantic domain understanding of traceability needs for SoCs, together with the ability to connect to best-in-class design tools in the semiconductor and software development domains. This is what Arteris IP provides in the Arteris® Harmony Trace™ product. Harmony Trace builds and maintains semantic-aware links between EDA design and software development tools, requirements management, documentation, and other content relevant to SoC design. Most of these links are built automatically, precisely because Harmony Trace has this semantic understanding. The tool also computes the impact of changes on any connected data and detects changes at the lowest possible level to avoid information overloading. With such a platform, a design team can even explore what-if scenarios prior to implementing changes to the design to find potential traceability disconnects that might result from implementation choices they are considering.

Fig. 3 Harmony Trace™ correlates data from existing SoC design systems to create traceability between them. Source: Arteris IP

Behind the Scenes

To achieve these goals, Harmony Trace works directly with data in formats produced natively by the various domain tools. Mainstream platforms in system design already support open standards for data exchange. For example, requirements tools such as IBM DOORS and Atlassian Jira support ReqIF. Documentation tools such as Microsoft Word and Adobe FrameMaker support DITA, and SoC design tools such as Arteris IP SoC/HSI Assembly and Arteris IP, Synopsys, Cadence and Arm IP products support IP-XACT.

Fig. 4 Harmony Trace™ uses multiple APIs and data formats to correlate data from existing SoC design systems to create traceability between them. Source: Arteris IP

However, being able to access open standards is not enough. An effective traceability tool must also understand the semantics applicable to SoC design within these standards. For Arteris IP, the foundation for this understanding started with the IEEE IP-XACT standard, developed more than a decade ago and now used by many top semiconductor and systems companies in mobile, automotive, and other markets. The intent behind the standard was to provide a bridge from hardware to software design and applications. At Arteris IP, an early adopter of the standard, that objective was extended to encompass documentation generation through DITA for datasheets and specifications and now provides a very secure footing for Harmony Trace.

Harmony Trace avoids pitfalls in ALM methods by not trying to capture domain content within its database. Instead, it captures links between significant design objects found in the native tool databases, essentially providing a "system of systems" that creates and maintains traceability links at an elemental level between varying requirements management, engineering ticketing, user support, code repository and documentation systems. It also avoids drawbacks in surrogate methods by developing the great majority of these links automatically, based on domain-specific semantic understanding. This is where Arteris IP experience with the IP-XACT and DITA standards becomes so important. Harmony Trace knows how to find and interpret key information like hardware design clocks, IP selections, versions and configurations, and software memory and register maps. It can identify this information in IP-XACT databases, in documentation through tables detailing this data, and in requirements data, enabling the tool to find and establish most of these links without engineer guidance.

Fig. 5 A semiconductor-centric view of the ADAS and autonomous driving system value chain. Source: Arteris IP

There will always be a subset of requirement or specification links that can only be annotated through user know-how, such as a requirement that reflects a global expectation not visible within the collateral provided to Harmony Trace. Adding these human-determined constraints is also supported. This important capability is provided to handle a minority of exceptions, not most of the links. Equally important is that establishing these links is typically a one-time operation per system design. Once an association is identified, it remains identified and is tagged between logical containers, which may encompass multiple physical objects (files or databases) or fragments of those objects. Physical objects may change while logical connections remain intact.

A Representative Deployment

Harmony Trace runs as a customer-hosted server-based application, essential for a capability that must be accessible to geographically distributed design groups, partners, and clients. Setup starts with subscribing to information resources through monitors. These monitors observe physical resources subscribed to logical containers in the Harmony Trace information model. This observation detects changes in a resource, triggering the platform to identify if those changes impact items linked in the information model.

Fig. 6 Setup starts with subscribing to information resources through monitors, which observe changes in subscribed systems. Source: Arteris IP

For example, an architect might subscribe to a DOORS requirement database, one or more specification documents and a list of IP-XACT design databases. Harmony Trace will then establish most links automatically (one customer example created 5,000-6,000 links for a single SoC project). An architect could then add more links that might be required but which could only be created manually (in the same example, about 120 links).

Fig. 7 A High-Level Link Graph provides the big picture. Source: Arteris IP

Fig. 8 Drilling down into the lower levels of the link graph. Source: Arteris IP

This setup is a one-time activity, requiring only occasional maintenance to add or modify such link changes as might be required during the evolution of the project. Traceability checking then follows those links automatically as updates are detected. Discrepancies can be reported in various ways: through a graph of faulty trace links highlighted in red and through lists in error reports.

Consider how requirements and specification compliance validation can be accomplished with this modern approach versus the old manual approach:

Old approach: Remember the example of twenty of the smartest engineers in the company gathering around a table, once a month for days on end, to compare the spreadsheet with the detailed implementation, current verification status and other collateral generated by the design team? Painful, slow and error prone. Up to now, this process has been the state of the art in traceability and change management.

Automated approach:All the traceability links are established up-front, most of them automatically. As the design evolves, traceability checks can be scheduled to run automatically and comprehensively on key milestones. Disconnects are reported automatically and can be visualized and debugged quickly through Harmony Trace. For example, an implementation change to a monitored bus width will trigger a notification at any point in design development. This notification is addressed to all design stakeholders who should be notified – architects, designers and product engineers who must approve or disapprove any change.

Now consider the benefit of traceability through the supply chain. After the customer/integrator builds the SoC into their systems, and their customer/integrator builds their systems, sometimes unexpected problems are found. Problems can happen even when finished products are deployed to end-users, and these must be debugged and traced back to root causes. Perhaps the system software made an incorrect assumption about SoC behavior, or maybe the SoC functionality is incorrect. Finding a root cause is simplified through traceable paths, from requirements to implementation evidence of how those requirements were implemented, verified, tested and documented, which is why standards such as ISO 26262 require traceability from product providers in the supply chain. ISO 26262 does not specify how providers should offer this traceability. Practicality requires that the process be automated and that suppliers who provide an easy path to this access will flourish. Harmony Trace provides that automation.

Takeaways

The demands of modern supply chains require that traceability inside SoCs no longer be optional, nor can these needs be practically satisfied with traditional spreadsheets as evidence of compliance. SoC builders who aim to participate in the accelerating growth of smart systems opportunities in the new economy must pay close attention to these requirements.

Author

Vincent Thibault is the director of product strategy at Arteris IP, focusing on IP deployment technologies. He has spent the last 13 years working with the world's most advanced semiconductor and systems companies to build comprehensive solutions for IP reuse based around the IEEE 1685 IP-XACT standard. Vincent's passion is creating the future of SoC integration technologies and methods. In pursuit of this, he is an active member of Accellera's IP-XACT standard working group and a member of the IEEE P1685 working group that is defining the next version of the IEEE IP-XACT standard. His most recent focus has been around documentation, traceability and certification, as well as integration into systems engineering methodologies.

Vincent has a master diploma in Software Engineering with a specialization in embedded systems and artificial intelligence (AI) from Ecole Internationale des Sciences du Traitement de l'Information (EISTI) in France.

 Back