Organizations are on the quest to mirror physical realities as digital systems. These “real-world” digital representations, sometimes called “digital twins”, transform how manufacturers create products, enabling them to make things better and cheaper than ever before.
Today, manufacturers are burdened by complex systems with interdependent components and demand for shorter development cycles. This necessitates more efficient and less error-prone development approaches. The concept of digital twins is designed to address these challenges.
The use of digital twins in manufacturing refers to the creation of an exact digital representation of a physical entity. It is related to another concept we’ve discussed before on this blog, the idea of a “digital thread” in which a digital representation of a product is tracked end-to-end through the entire product lifecycle.
Having a digital twin offers incredible benefits as engineering teams are better able to understand the products they build. They can improve product quality. And, they can improve product times.
The challenge in creating digital twins, however, is that traditional IT is not designed to support it. You need a new approach to model reality. The old system – creating long written documents that describe a system – doesn’t work. Instead, organizations need a more modern approach, and that’s where model-based systems engineering comes in.
Model-based systems engineering is a methodology in which a single digital model depicts and relates the components and architecture of a system and the requirements and restrictions of a system in order for it to perform a function or for it to be safe.
To understand MBSE, let’s use the example of the device you’re using to read this blog. There might be a functional requirement for adjustable screen brightness. There are several components that make up a screen. The screen and the components interact with the greater system that makes up the device. Different teams work on producing all the components and put together what works as a reading device. But, let’s imagine that the battery only lasts for an hour, making the whole device insufficient. The overall design intent was lost in the design of the individual components.
At this point, different parts of this poorly designed device might already be in production to meet tight deadlines. You go back and rework everything and produce new parts. Then someone specifies a new requirement for better screen quality. How does this impact the battery life? At this point there’s so many changes and different teams responsible for the different parts, it would be hard to answer that question.
This is a simplified and dramatized example, but you get the point. It’s extremely complicated to keep track of the functional requirements, the parts, how they interact, and the restrictions on a product.
With MBSE, engineering teams have a digital representation of everything involved in the systems and parts to create a product. So in our simple example, the team would have documentation on the functional requirements, the design intent, the components, and how the parts work together for the device, in one place.
The end result with MBSE? In our example, it means that if someone suddenly changes a requirement like the one around screen brightness, its impact on the entire system can be easily mapped out and analyzed.
In a real-world manufacturing scenario, like when building a plane with over 6 million parts, teams can finally understand how a tiny change in a requirement impacts the delivery of the whole product. This is incredibly valuable in terms of time, money, and safety.
Without MBSE, teams are left to rely on document-based systems engineering where the primary method of knowledge storage and communication reside in emails, slides, or spreadsheets within different organizations of a business. The old document-based systems result in communication challenges, time wasted to curate data, and expertise in one specific component without a grasp of the larger system.
When used properly, model-based systems engineering can improve efficiency, communication, and delivery time since teams can all understand what’s going on at different stages of the system development life cycle.
How Databases Play a Part
Moving towards MBSE is foundational for digital transformation at many large manufacturers, but it’s a challenge. Most companies have dispersed data that’s inconsistent and poorly managed.
For example, imagine a large manufacturer that went through a bunch of M&A. Over time they might have developed various names for the same parts. The data might be in hundreds of different systems, and integrating all of that data in one system would be expensive and would take years.
You would want to be able to track lineage and keep records of what the data looked like at different times. And of course, since this might be a highly sensitive product the company is building, you need to carefully manage access to this data and secure everything.
That’s where your database comes in. It’s important that organizations have a database with the flexibility to handle the size and complexity of the data sets. It’s also important to be able to manage the inherent relationships between all of the parts. And, of course, it has to be secure and governed.
MarkLogic is a great choice as the database platform for MBSE because it fulfills all of those requirements—it has multi-model flexibility, can manage semantic data, and has a long list of enterprise features.
Let’s take a closer look at how one of our customers, Boeing, is basing its MBSE initiative on MarkLogic.
How MarkLogic Enables MBSE at a Top Aircraft Manufacturer
MarkLogic’s multi-model and semantic capabilities make it an excellent candidate for MBSE, as we’ve seen with Boeing, who spoke at MarkLogic World.
With MarkLogic as their bedrock for their MBSE project, they have been able to digitalize their engineering methods.
Here are just some of the top three benefits of their MBSE project:
Everyone speaks the same language
Because data for each sub-system and component is tied up within different organizations working on a small piece of the overall system, there are different naming conventions and uses for a single part. For example, the same screw might be referred by many different names and used in different systems.
This data needs to map to an ontology to relate all the concepts. An ontology is set of relationships and objects. It defines specific objects and how they’re used within different business units in the same organization, thus eliminating the issue. In our example of screws, an ontology helps everyone understand that a specific screw is the same part even if it’s referred to with different names and works both in the passenger seat build as well as the bathroom.
Modeling data using an ontology requires semantic capabilities in which the data is expressed as RDF triples. In Boeing’s implementation of MBSE, semantics allows for consistent querying on parts and sub-systems which eliminates their need for manually curating the data. This improves efficiency and streamlines processes.
One repository of information, viewed at any point in time
Prior to this customer’s MBSE project, each component was a part of a sub-assembly for building into larger parts. This resulted in many “black box” components that the next group in the assembly line wouldn’t understand. The ability to store multiple formats of data, link everything together, and use bitemporal capabilities in one data platform with the proper lineage is key to a successful MBSE initiative.
MarkLogic’s unrivaled flexibility to integrate multi-model data makes it possible for this customer to load aircraft data and link it all together. In addition, MarkLogic’s bitemporal capability makes it easy to store multiple versions of the data, on multiple timelines. Engineers can keep track of when an event occurred (the valid time) as well as when the data was entered into the database (the system time). This allows for more complex, rich queries to better understand full system impacts and how to repair any problems with the system.
And not only are complex queries possible, this customer has the ability to trace lineage and track provenance to ensure data quality. Data is now easily traced throughout its lifecycle– its origins, the path it takes and the transformations it undergoes. This provides visibility and allows the data to be trusted.
Instead of dispersed data that requires manual curation, tracking a paper trail, or finding a specific subject matter expert, data can be queried in one repository!
Better analysis by querying the model as a semantic graph
Manufacturing companies need to understand the ripple effect on system and requirements. How does a certain part (such as specific wiring or sensors) affect other parts when there are hundreds of models of just one product? If a component is 5% cheaper if there’s a 10% weight increase, is it a worthwhile change?
Today, manufacturing companies need fast and safe data analysis to remain competitive. Prior to MBSE, many systems were documented on paper, which required manual curation of often outdated information. If information was stored digitally, analysts could only run limited batch analysis on a current state snap-shot. And, it would take days or weeks. delaying builds and increasing cost.
Using MBSE, Boeing with can complete flexible queries and explore their model in real time. This allows them to perform impact analysis and validate their products while simulating the model. The end result? It means they can ensure all aircraft safety checks are done on time and within budget.
It’s always a challenge to obtain a single, integrated repository of data and even more difficult to create digital representations of physical assets. In cases such as manufacturing complex vehicles such as planes, safety depends on everyone having a complete understanding of the system. Data needs to be integrated and searchable for effective MBSE methodology and analysis to ensure safety, cost savings, and overall business success.
Watch the MarkLogic World presentation