Business Considerations in Traceability

Traceability as an emerging debate around hardware is gaining a lot of traction. As a reminder, traceability is the need to support a disciplined ability to trace from initial OEM requirements down through the value chain to implementation support and confirmed verification in software and hardware. Demand for traceability appears most commonly in safety-critical applications, from automotive and rail to mil-aero. In process industries such as petroleum, petrochemical and pharmaceutical, to power plants and machinery safety-related controls. These are today’s applications. The more we push the IoT envelope, Industry 4.0, smart cities and homes, the more cannot-fail products we will inevitably create.

Why bother?

Traceability requirements in our world started in software to ensure that what an OEM wanted was actually built and tested. Now that application-specific hardware plays a bigger role in many modern designs, effective traceability must look inside some aspects of hardware as much as it does in software.

But why is traceability support important? Is this a temporary business fad we’ll soon forget? Or is it an unavoidable secular shift? And what kind of investment will it require? Tools and servers, probably, but added engineering effort is a bigger concern. Will you need to add more staff and more time to schedules? Let’s start with potential market downsides to ignoring traceability.

Locking out regulated markets

It’s easy to understand any case where regulation requires traceability. For medical devices covered by ISO 14971, one source asserts, “Auditing capabilities are also critical for regulatory compliance traceability. The FDA has been known to close down a product or prevent it from being shipped, or even shut down a whole division until you are in compliance.”

Jama Software – who know a thing or two about traceability – add, “even if everything goes according to plan, there’s no guarantee that the traceability workflows in use will account for all relevant requirements and risks. For instance, in the case of a medical device, a matrix created within Excel won’t come with frameworks aligned with industry standards like ISO 14971, making it more difficult to ensure coordinated traceability and ensure successful proof of compliance.”

You shouldn’t assume this only applies to medical devices. OEMs are now working more closely with SoC builders and expect more detailed evidence that device meet all requirements. Coverage reports won’t satisfy this need. They’d rather have a traceability path, from their requirement to a point in the RTL and test plans where you can defend your implementation.

Locking out a geography

Problems don’t only arise in highly regulated industries. We all know of cases when features requested in one geographical region are not important in others. In theory, detailed specifications and lists of requirements capture all needs and variations between clients and geographies. In practice, some escapes slip through. Remember the call from a client, after the spec is finalized, that they forgot one very important feature? The local apps guy takes careful notes and promises the spec will reflect this requirement. But it never appears in the official spec

In one case I heard of, an Asia-Pac client had such a requirement – perhaps a control/status register extension they needed which no other geography had asked for. Seemed harmless enough. But the R&D team didn’t see that requirement in the specs. They built the chip without that feature, and the customer rejected the product. That client was going to be the reference account for the region but became the wrong kind of reference. They lost the whole geography for that product.

The point here being that specs are not quite structured enough for a formal agreement on what you are going to build. Which is why software product builders now depend heavily on formal requirements documentation and traceability. Specs are a good way to elaborate on and explain requirements, but requirements are becoming the definitive definition. Clients won’t find this to be a problem. They are often already very familiar with requirements traceability and related tools. You will just need to build the same awareness/discipline in your team, from the field to R&D.

Won’t that create a big overhead for you?

That depends. If you are going to use a general-purpose requirements tool with no understanding of hardware design, then probably yes, you will have to put quite a bit of work into traceability bookkeeping. It might be time to learn more about the Arteris® Harmony Trace platform. This links intimately to hardware design on one end and traceability standards on the other end. With design semantic know-how to greatly reduce the burden on engineering teams.

Also read:

Traceability and ISO 26262

Physically Aware SoC Assembly

More Tales from the NoC Trenches