[Webinar Recap] Best Practices: Unlocking the Power of the Digital Thread in Traceable MBSE™
|
In this blog, we recap our recent webinar, “Unlocking the Power of the Digital Thread in MBSE”
Best Practices: Unlocking the Power of the Digital Thread in Traceable MBSE™
In the world of product and systems development, integrating the digital thread throughout Model-Based Systems Engineering process isn’t just an advantage — it’s a game-changer.
In this engaging webinar, host Brian Kennedy, Principal Solutions Consultant at Jama Software, will show how the digital thread transforms MBSE, driving better traceability, stronger collaboration, and greater efficiency across the product lifecycle. You’ll also see how Live Trace Explorer™ helps connect your MBSE tools seamlessly, creating Traceable MBSE™.
What You’ll Learn:
- The role of the digital thread in enhancing Traceable MBSE workflows
- Best practices for building a connected thread across diverse systems
- How Live Trace Explorer improves product quality, reduces risks, and accelerates delivery
- Using coverage metrics to identify gaps and ensure process completeness
- Proven strategies to reduce iteration loops and support regulatory compliance
Walk away with actionable insights to strengthen your Traceable MBSE processes — and see how Jama Connect® can elevate your engineering workflows.
Below is an abbreviated transcript of our webinar.
Briand Kennedy: During today’s webinar, I’m going to be discussing the process of unlocking the power of the digital thread in Traceable MBSE. To begin with, let’s just take a step back and understand what exactly is the Traceable MBSE process and where did it originate from? Today, many products that companies produce are live for safety-critical and one of the requirements for life and safety-critical products is that the company must completely document how the product should perform. Additionally, they have to also prove that it performs as specified. As products have become much more complicated and sophisticated and systems have become much more integrated and difficult to model doing this process has become a greater challenge than it was maybe previously.
As a result of us interviewing various engineering leaders who are responsible for product release, we asked them what keeps you up at night? What are the top things that these engineering leaders say keeps them up at night? As we listened to them, we heard many common questions come up. These are the five top questions or issues that they indicated. The first one is, how do I know which product requirements have been missed in my design? How do I know which product requirements are not fully covered by my test cases that I’ve defined? How do I know which product requirements have failed to pass tests? How do I identify development activity that happens to be using incorrect requirements or maybe isn’t even directly connected to requirements? And finally, how do I know if changes that have been made in say, hardware impacts my software team or if a requirement change impacts either the hardware or software team? How do I understand this traceability? These are the things that we’ve heard a lot about. I bet one of these might resonate with you.
RELATED: Bridging ALM and MBSE: Strategies for Seamless Integration
Kennedy: I’ll tell you what, why don’t we take a quick survey? There’s going to be a survey that pops up, and we’ll give you a couple of minutes to walk through these questions and tell us which one of these questions do you identify most with or is most pressing on your needs. Thank you very much for answering which one of these questions is the one you most identify with. At the end of this presentation, we’re going to come back to each one of these questions and show you how Traceable Model-Based System Engineering processes and the digital thread can help address each one of these items.
So, let’s talk a little bit about how we have developed Traceable MBSE to address these situations. To start with, let’s talk about where we came from. And we came from a paper-based system, and it doesn’t fully address these questions that we have here. And so, in order to solve these problems, we’ve performed a digital transformation, and that started with a very simple thing a long time ago of actually switching from physical paper over to electronic files. This provided significant improvements in efficiency and allowed each domain and discipline to be able to capture their data electronically versus on paper. It does improve communication, allows us to share data more easily, and allows us to reuse data in a much easier process. But fundamentally, this first step of converting from paper to electronic file, although it was a huge advantage, didn’t fundamentally change the process in which we did system engineering. We were still stuck with disconnected data.
So the next phase in this is what I call the decomposition phase. This occurred when we actually took those individual documents, for example, a complete requirement specification, and decomposed it to individual items. And this was very powerful. What we were able to do is instead of having a single document with all the specifications in it, we would decompose it to individual requirements, and each individual requirement could be referenced independently. And in fact, they allowed us to reuse this data and such. So you could have the same requirement being reused in multiple places, whereas before, you literally had two separate pieces of text that you were duplicating. Once again, another huge improvement in efficiency. This concept of decomposition doesn’t just isolate two requirements. It implemented various other things, such as the modeling systems for various other things. And it ended up creating a capability so that each discipline, each domain was able to create unique tools that address decomposition or analysis or simulation of their particular areas.
RELATED: Jama Connect for Traceable MBSE™
Kennedy: So what we saw was requirements identification and subsystem requirement identification, being executed in Word or Excel spreadsheets initially, and even going into some modeling techniques and different tools. So we ended up with a verification validation process that for each individual domain we were able to create some decent automation, but they weren’t connected. Each group was independently looking at their data and creating it, and there wasn’t consistent reuse across it and no consistent way of knowing what was the correct stuff. We depended on things like email and such like that. So it really created an impact on things like a lack of ongoing risk assessment, and change management became very difficult because even though we had decomposed some of the things and we had captured all the documents electronically, we still were not interconnected. We didn’t have a uniform interconnectivity, and this meant we had to take one more step in our digital transformation. And that final step was to create a true full model definition.
And when we talk about creating a full model, it involves quite a few things. First is governance. We have to create a structure and version control on top of the data. So we would classify the data in groups and control each one of those individual items, requirements simulations, functional definition, architectures as individual items and version control them in a controlled system in a database framework. So, we had a governance structure and control framework that needed to be defined. We then expanded from just having text-based or static images to having full diagrams where each item was interrelated and connected together. And we were able to create visual diagrams that illustrated how our systems were being designed, how functions and sub-functions and systems and subsystems were supposed to interact, and how data was supposed to flow from one part of our system to another. And we created these diagrams. Finally, we created a common data model, which allowed us to capture all these different pieces of data and define relationships from one item to the other and have consistent terminology and consistent use of that data. So we had one requirement defined in one place,e and it was used wherever it was needed by referencing that single item. And so that’s where we talk about a data model. We needed a complete data model to capture all this data that we were governing in the governance area and in the diagrams.
To watch the entire webinar, visit:
Best Practices: Unlocking the Power of the Digital Thread in Traceable MBSE™
Principal Solutions Consultant, Digital Thread at Jama Software
For the past 25 years I have been involved in pioneering enterprise simulation process data management and supported its inclusion of the the Digital Twin and the overall Model Based Systems Engineering approach to design.
Latest posts by Brian Kennedy (see all)