PDF
Key takeaways
- Digital threads enable the sharing of stable configurations of product artifacts throughout the product’s lifecycle.
- Ontologies define the semantic foundation for meaningful digital threads that support any products’ systems of systems.
- Digital threads have impact across the full product lifecycle of tools and information so an adaptive framework is essential for providing an integrated environment.
- Model-Based Engineering (MBSE) helps companies achieve superior products quickly and with fewer issues and flaws.
- SBE Vision’s architecture provides a base upon which companies can develop digital threads to support decision making within their specific information and development tools environment.
Introduction
The Digital thread has become a leading concept in today’s model-based product development world. It promises compelling benefits throughout product lifecycles from conception through end of life. Many companies are trying to embrace these concepts as part of their development of products.
The sequence of product-related decisions, embodied in the digital thread, in which decisions are made during product development, deployment, and operation, are critical to determining a company’s long-term success. The digital thread includes many decisions around design including concept development, systems architecture, and simulation and analysis—decisions that are made long before even a single part exists. The digital thread also includes factors beyond design, like safety margins, compliance, performance, and finances that influence when and how both design and operational decisions are made. A safety margin example is crash worthiness or breakage of automobiles, aircraft, and other products. Decisions for the safety margin first and foremost focus on protecting the users. Performance drives sales—whether it is longevity, range and speed, passenger capacity, or energy consumption. for instance a lighter car or aircraft can go further, faster, while a more energy efficient machine lowers operating costs. Profitable products can only be achieved through a progression of decisions that are heavily influenced by the interactions of requirements linked to the components of the item—the digital thread contains and maintains a multitude of critical relationships.[1]
Supporting these complex decisions during product development and deployment is a systems problem. Systems are best designed around a framework of requirements. The problem is to assure that the requirements are fulfilled and not violated throughout the life of a product, from its conception to retirement. Requirements change, which is fine as long as the impact of any change can be easily discerned, the changes can be controlled, are fit for purpose, then managed through the lifecycle. It is one thing to define requirements before a product is designed and built, but after a product enters service new operational issues and upgrades arise, leading to new requirements that were not perceived during design and build. An important issue is how the system’s defining constraints are documented, maintained, traced, adhered to, and managed as the product is placed in use, and inevitably changes. This requires the concept of a digital thread that includes requirements and other product attributes tied to an ever-changing set of digital model artifacts. Digital threads don’t simply exist, they have to be created in a managed environment with an understanding of a product’s requirements and how those requirements form the basis of the digital product definition and how the digital thread transforms over time. SBE Vision is providing a method and solution to the difficult problems of getting from product requirements and other data elements to a sustainable digital thread that can drive complex, evolving systems of systems.
Digital Threads and Systems Engineering
Systems engineering (SE) has been used for decades. Computer-based or digital systems engineering improves meeting overall product requirements because it allows designers to see more interactions among those requirements and how solutions fulfill them before a product is produced.
Systems engineering is often supported by using a modelling language that allows the designer to define fundamental relationships of the design, including physical and logical interactions. Not all systems engineering modeling languages achieve this, especially those languages developed by committee.
Some desired, perhaps required, outcomes may include:
- Higher system reliability, due to better integration of reliability considerations into design on a real-time basis (DFMEA)
- Opportunity to better integrate product design with design of its manufacturing system, supporting improved, lower cost production
- The same for development of the maintenance system, resulting in improved service and lower costs
- Overall improved understandability of the design by others, reducing life cycle costs by reducing costs or increasing the benefits
The digital thread allows the relationships among requirements and their MBSE architectures and subsequent design implementations to be documented and linked throughout the system’s lifecycle.
Requirements Use in Decision Making
A monolithic product lifecycle management (PLM) system, that is, one which expects a single database of product artifacts for decision making, is neither workable nor practical culturally. Rather a framework of openness and services, coming from many innovative sources, leads us to a different architecture for PLM-enabling tools and services—a PLM platform. Within that platform, services for grouping related sets of objects to make the best decisions is required.
While the effort required for creating requirements, sharing them among tools, allocating them appropriately, and maintaining their initial traceability has been reduced, the substantial workload required to maintain these linkages discourages many from continuing to use their requirements throughout a product’s lifecycle, reducing their value and negating an essential factor for maintaining the digital thread. Yet, as system complexity and the number of artifacts increases, poor requirements management, especially supporting traceability throughout the lifecycle, becomes a company’s Achilles heel.
What is needed is in-context viewing and exploring to improve decision making. With a live, active, and connected ontology (see below) and best in class applications, sharing requirements linked to product elements (parts, components, assemblies, etc.) creating stable configurations is critical.
An ontology is a precise definition of objects, their taxonomy, relationships, attributes, and related knowledge in a context or configuration. When defined correctly, a product and process ontology will effectively manage an enterprise’s products. It is important that solutions (such as the components of PLM) share a single ontology that enables the exchange and sharing of knowledge among applications. This supports better decisions. The ontology acts as an application language broker, a Rosetta stone, enabling sharing of elements from different requirements authoring and management domains.
Developing an ontology:[2]
- Enables sharing common understandings of the structure of information among people or software solutions
- Enables reuse of domain knowledge
- Makes domain assumptions explicit
- Separates domain knowledge from operational knowledge
- Allows analysis of domain knowledge
Monolithic PLM ecosystems have evolved in parallel with computing power. However, a problem arises because specific actors within the development and operational processes have codified knowledge and competitive practices inside their specific applications. Removing these implies a certain loss of knowledge so it becomes imperative to deal with them in a heterogeneous environment supported by a platform architecture.
PLM platforms delivered as Software-as-a-Service (SaaS) or Container-as-a-service (CaaS) have emerged providing a richer ecosystem. Recent CIMdata research has noted the growth of PLM platforms vs. monolithic solutions. But a platform with applications exchanging information is just a start. You also need consistent, repeatable contexts in a stable configuration across these applications.
A product ontology and services help create solutions to support and satisfy requirements, making sure stable configurations are used to exchange knowledge and insights consistently. This enables product teams to manage complex systems of requirements and create a digital thread. The result is that effective product decisions occur faster and change management cycle times and quality improve.
SBE Vision’s Solution
SBE Vision’s solution is a key part of a design responsible organization’s digital environment that utilizes ontologies to facilitate digital engineering and related activities. It solves many of the pitfalls inherent in achieving a viable digital thread.
The Internet shares information efficiently via living links (i.e., URLs). This provides a clue on how to define a viable digital thread. Standards like OSLC and RESTful APIs provide some of the exchange capabilities needed to connect heterogeneous applications. This is critical because it is desirable to use the best requirements management and MBSE applications with the best of an organization’s mechanical, electrical, software, simulation, and verification engineering applications, regardless of differences in data structure and format. To provide a stable context, i.e., a configuration, these applications need a service which can broker communications and data flows among them—similar to how the Internet works in a scalable and secure environment.
Product developers need a persistent set of data and services (a digital thread) to organize and explore all requirements and systems engineering contexts so that customers and partners can make the best decisions about a product. However, remote linking standards like OSLC have inherent weaknesses: missing contexts, absence of cross-system search, lack of a consistent user experience, and most importantly, an inability to communicate states across application boundaries. As a result, remote linking standards are best employed in specific situations where the links are few, well defined, and not subject to frequent change.
A focus on using requirements, architectures, and designs in different contexts is a key to improving decisions, but they need to be delivered to the ecosystem of consumers in the context of their particular applications. Accomplishing this requires the bi-directional transformation of complex product-related data which effectively can only be achieved via semantic transformation such as by using SBE Vision’s Semantic Data Broker (see Figure 1). Beyond remote linking, the SBE Vision provides a mechanism for sharing data between applications via a publish and subscribe approach. This technology delivers a highly configurable synchronization capability that supplements remote linking to allow digital threads to be constructed through either means—even combined with remote linking. In SBE Vision’s data broker, every object on the digital thread is an OSLC resource that is OSLC-GC (global configuration management) aware. SBE has synthesized this remote linking technology with its publish/subscribe technology in a seamless way.
SBE Vision continues to develop solutions to support requirements, model, and verification management in a heterogenous authoring and usage environment, including DOORS Next, Teamcenter, Windchill, a variety of MBSE and analysis tools such as Cameo, ModelCenter, Rhapsody, Genesys, Simulink, Jama, Jira, and others. The solution is ontology-centric. It uses a semantic ontology as the universal language through which systems share data. It is based on open ontologies where users of any engineering tool can work in their preferred system and can examine requirements or models authored and managed in foreign systems. This includes support for industry standard ontologies such as the Basic Formal Ontology (BFO).[3] Their Semantic Data Broker provides the essential link to the plethora of tools in use today to support a digital thread.
Figure 1—SBE Vision as the Basis for a Semantic Data Broker
(Courtesy of SBE Vision)
SBE Vision’s platform technology helps build and maintain requirements traceability across requirements and model management tools, and establish and share stable views, that is, configurations or contexts. These contexts can be coherently examined, even when they come from different requirements authoring systems. This allows systems engineers to provide views across stable digital thread contexts, thus improving decisions. These stable configurations can link any elements of information in a PLM ecosystem, not just requirements.
Digital thread visualization is a serious problem when models have hundreds of thousands of nodes. SBE’s approach is to focus on providing end users with task-specific dashboards, reporting, and analytics that provide answers to important process specific questions with rapid response times. This allows users to work in their solutions’ UIs, without switching to SBE’s.
An adapter strategy is key to a well-functioning digital thread—allowing integration and interoperability with siloed tools and information. Adapters are required to support a typically complex environment of preexisting tools and data models to accommodate complexity, compliance, and completeness. An adapter Software Development Kit (SDK) provides critical support for organizations who write their own adapters, which is particularly important in highly-secure environments. SBE offers a connector SDK that allows companies to quickly create their own integrations to the digital thread. Its open architecture has been used to demonstrate numerous different engineering tools working together in an effective manner.
SBE-supplied adapters are SBE platform version dependent. As such they can be dynamically registered with any version of the SBE platform at any time. It is the SBE Connector SDK that provides this layer of abstraction between the SBE platform and the external Authoritative Source of Truth (ASoT). Once registered with SBE, a new connector can “attach” datasets with the SBE digital thread via a “channel.”[4]
SBE is cloud-native and is developed using a scalable container microservices architecture where every digital thread service runs in its own container and thus can be independently scaled as needed. Furthermore, SBE supports hybrid deployments where clusters can be split seamlessly between on-premises and commercial cloud nodes.
SBE’s publish-subscribe-apply refresh capability means that every adapter they provide is bi-directional. SBE can, for instance, publish a Cameo model into PLM, ALM, requirements management, and other tools. Using the SBE UI or APIs collections of objects from multiple systems can be modified and changes written out to the ASoTs, thus enabling an entirely new class of use cases where customers can have 3rd-party web apps drive custom digital thread apps using SBE as a backbone.
Summary
To support ever-changing, temporal product information and configurations, manual methods of requirements management to support digital threads must become semi-automatic allowing the revelation of knowledge to support insights and adjust requirements Rapidly and accurately. Solutions like the SBE Vision SDK help build and maintain digital threads, providing long term benefits, even in heterogeneous application environments.
SBE’s philosophy is to create plugins to every connected digital thread tool so that nobody has to leave their user interface to use SBE. Ontologies help SBE avoid the N2 point-to-point solution integration and plugin problem found in many solutions. An ontology builder is part of the SBE solution.
SBE’s task-specific dashboards, reporting, and analytics allows users to stay in their familiar UIs. SBE also provides integrations to many reporting and analytics and visualization platforms.
Early adopters have started using this technology, and CIMdata expects more to do so. Rapid product innovations occur in a PLM ecosystem, which also fosters process and application innovations. SBE Vision provides capabilities that other digital thread solution fail to offer—defining requirements in a neutral ontology, while offering many MBSE tool integrations, allowing digital threads that use a company’s current, favorite solutions and data.
If you are trying to achieve a digital thread, consider evaluating SBE’s solution.
