In my previous posts I started to talk about traceability by illustrating traceability between requirements or connecting requirements with test cases. In engineering the scope of traceability is usually much larger and represents for many companies still a big challenge as they are struggling to establish a traceability throughout the product engineering process (and maybe even beyond). I want to use this post to explain the motivation for traceability and what someone can finally do with it. I will also share a demo example that was built for an automotive customer of mine to connect the different engineering disciplines with each other in a heterogenous tool landscape (which is the standard situation in companies that want to introduce end-to-end traceability in their processes).

I am often asked by my customers "what's the benefit of establishing a traceability?". The best way to explain this is to put ourselves into the shoes of the people that are part of the engineering process. Assuming we have 3 members of our corporate engineering team who are fulfilling different roles in the organization: 

Dave, he is a requirements manager and needs to collect and manage the product requirements and also works with the downstream domain engineering teams to ensure product requirements are implemented & satisfied. Dave gets throughout the development process requests (e.g. from an OEM customer) to change a set of requirements that were previously retrieved from the customer. How do we cope with this request as it will require to analyze what things are impacted?

Sarah, she is a safety engineer in our organization and she is also working with external authorities when we have to go through an ISO26262 assessment to show that our R&D process is ISO26262 compliant. One thing that the auditor wants to see is that all artifacts are in place and that we can easily trace/navigate from one artifact to another. How can we achieve this?

Tim, he is one of our software developers and turns model based functional specifications into software code. When he needs to change pieces of the code because of a change request how can we easily do an upstream traceability analysis to figure out which upstream product requirements we have to comply with aside from conducting the requested change?

The good news: 3DEXPERIENCE provides technology to cover all these uses cases using the system traceability solution (TRY) in the 3DEXPERIENCE platform. Looking again at the particular use case from Dave in more detail and embedding this into a typical change management request in engineering as illustrated below, we can better understand the value that traceability contributes to such a use case. 

Assuming we retrieve the request (like Dave usually does) to change a product requirement then we are asking ourselves the question "what will that change mean for us in engineering?" There is a lot of elements that were either specified or already implemented that would be impacted if we were changing this requirement. It can range from simple changes in the software (such as a parameter value), more intensive changes in the hardware or even architectural changes of the product. We want to understand which elements will be impacted and must be "touched/changed" to satisfy this change request. The reason why we want to know this is the fact that we have to run an assessment to better understand:

1. What resources will be needed to conduct this change?

2. What will be cost associated with this change (customer needs to pay for it)?

3. What is the risk that goes along with this change, can we really achieve this in the given amount of time?

... and possibly lots of other questions to support our decision making. At the end of the day, we need to decide whether we do the change or not (or do it just partially if possible). If we decide "yes", then we have to start the change planning and execute the implementation. But an important piece to accelerate the collection of information for our decision making is an impact analysis by leveraging an end-to-end traceability model in the 3DEXPERIENCE platform.

In the following demo example I have built a demonstration for an automotive customer that was exactly in such a change management dilemma and was looking for a solution to accelerate the impact analysis. The particular challenge, a heterogenous tool landscape where we need to connect data residing in different data bases and various different types of formats. The demonstrator was made for an automated emergency braking system function (a simplified version as we had only a short amount of time to built it). The requirements were authored primarily in DOORS and managed in a DOORS data bas paired with requirements in Word and PDF docs. From these requirements a system specification was evolved using the MagicGrid in CATIA Magic in SysML and the data was stored in TeamWorkCloud (nowadays called Magic Collaboration Studio). An alternative way to manage the CATIA Magic data is the new Power'By technology to store the models directly in 3DEXPERIENCE. Subsequently a partitioning was performed to define which pieces of that system specification go into software and which ones go into hardware. The detailed behavior model for the software part was created in Simulink and software code was produced from that which is managed in git as SCM system. For the hardware a physical product was created in CATIA. All of that was than assembled to an end-to-end traceability model in 3DEXPERIENCE. The demo video below shows the following areas:

1. Authored DOORS requirements residing in the DOORS data base.

2. Performing an impact analysis for some DOORS requirements over the entire artifact chain over architecture into software code (stored in git as SCM repository) and physical product structure of the ECU. This addresses the use case of Dave from above.

3. Navigation on the artifacts e.g. the Simulink model is introspected as the traceability connector can also show the content of external models. This navigation goes back to the use case of our safety engineer Sara from above that wants to run reviews/navigation on the artifacts.

4. Running an impact analysis for requirements in a PDF.

5. Perform upstream impact analysis from software code up to the product requirements addressing the use case of Tim from above.

Have fun watching the demo video. I already know today that some readers will ask how did you set up this model and made for instance the connection into git for software management? Stay tuned, this will come in the next posts of mine.