Increasing product complexities make Systems Thinking and Digital Transformation two of the central initiatives for most manufacturers. This is a complex issue summarised in a recent CIMdata webinar, How Electrification is Transforming PLM Strategies. The challenge is in the practical details of the implementation best practices. Aras has worked with industry thought leaders for several years. Here are few “golden nuggets” gleaned from established best practices and how they relate to state-of-the-art product lifecycle management (PLM) platforms.

System Models versus System Views

System models defined using Model Based Systems Engineering (MBSE) tools are key to managing complex products. They allow users to explore system behaviors by capturing design intent using design abstractions often referred to as Requirements-Functional-Logical-Physical (RFLP). This is critical because it allows non-system engineers to understand the why of the design as they define or navigate product implementation details. Unfortunately, MBSE tools create yet another expertise and data silo. That’s where the concept of system views becomes critical.

System views are intelligent selective windows into the system model. They are used outside the MBSE environment but with traceability to the original MBSE data models. They convey only what the user of the system model needs in a form that is understandable and in the context of the tools used by that user. For example,

• Information needed to build a simulation model at the desired fidelity 
• Information needed to identify a specific future product variant to understand which requirements are relevant or if aspects of the variant have been previously captured in other system models
• Information needed to identify functionality to be implemented as embedded software in an Application Lifecycle Management (ALM) environment

Best practice requires detailed definition of these system views, how the user will visualise them, and how to make them agnostic to the specific MBSE authoring tools. This is often an afterthought instead of part of the initial MBSE strategy and its integration with a PLM managed digital thread.

The variety of Digital Threads

The concept of the digital thread is key to achieving full product lifecycle traceability—allowing a user to track a product and its digital assets from concept through design, manufacturing, quality, and service. Ideally, this includes traceability between requirements, system models, simulation studies, detailed designs, variant configurations, change history, etc.—in the context of specific revisions and release states. The system-centric approach outlined above requires expansion of the digital thread beyond the BOM-centric (Bill of Materials) focus of the legacy PLM solutions. In a BOM-centric world the digital thread is continuous.  In the system-centric world however the digital thread is fragmented because MBSE, simulation, and various detailed design domains (mechanical, electronic, electrical, and software) are disconnected and remain so until their results are combined in a manufacturing BOM representing a particular product variant. To further complicate the situation, up-front systems engineering — sometimes referred to as the big SE — is distinctly separate from the system engineering in the individual domains — sometimes referred to as the small SE. That fact is often not accounted for in digital transformation of engineering. The key is to identify the diversity of the existing and potential partial digital threads, document their existence, and include standard traceability to the overall system model in each of them. This includes digital threads that extend to partners and suppliers. In the future, that relationship to the single system model can be used as a connective tissue that provides traceability between these various disconnected digital threads. 

Best practice requires recognising the existence of multiple digital threads and ensuring that each relates to a common denominator of the overall system model; and do so in a tool-agnostic fashion using the same instance of the PLM platform. The recent trend towards moving PLM to the cloud makes this much easier to accomplish.

The essence of a Digital Twin

The concept of a digital twin is firmly rooted in the fact that digital transformation of an engineering environment inadvertently leads to a virtual replica of the physical asset, with one the identical twin of the other. The benefits are huge and include lowering the cost of training, troubleshooting, interpreting IoT data, and more. But for one to truly replicate the other (virtual vs physical) several things must be accounted for:

• The physical asset must exist and be identified by a unique S/N (serial number)
• The virtual twin must reflect the exact configuration of the physical twin S/N including its manufacturing history, effectiveness, field maintenance, upgrades, etc.
• The virtual twin must be traceable to all aspects of the design intent and history discussed above through all partial digital threads

The implication is that a digital model without a corresponding physical asset is just a model of what the future product may look like. At best it’s the approximation of what the digital twin will be once the physical asset is manufactured. Best practice requires differentiating the concepts of a digital model that is not part of a digital twin from the one that is. This allows creating the right expectations and success criteria of the digital transformation journey.

To summarise, managing increasing product complexity requires transitioning from BOM-centric to system-centric thinking. That will have a significant impact on your engineering digital transformation journey. To be effective, the vision and strategy to get you there require careful evaluation of the best practices relevant to your organisation.