Bridging the Gap Between Systems Engineering and PLM

Bridging the Gap Between Systems Engineering and PLM

Systems thinking across the organization

Systems engineering, a formal application of “Systems Thinking”, has become critical to design of complex products. Although every engineer, in every engineering domain, practices some amount of systems engineering (e.g., electronic schematics) the relentless increase of product complexity has significantly elevated the role of systems engineers (SEs). This has some critical consequences for the rest of the enterprise, and we had better do something about it! Let me explain…

In the past, systems engineering relied on written specifications and/or drawings which were easy to share and understand but which, inadvertently, were relegated to the shelf once the subsequent key design decisions were made. The product then continued to evolve through detailed design, manufacturing and deployment (maintenance). Traceability between the product in the field and the original systems designs was lost or, more accurately, was never established.

Today, SEs are expected to manage complex systems that often extend beyond a single person’s ability to understand. These systems can no longer be managed by disconnected pieces of paper. In response, the systems engineering environment has evolved to Model Based Systems Engineering (MBSE), where paper is replaced with a digital model. Every detail of that model is digitally traceable to every detail of the product design, manufacture, and maintenance.  In turn, that traceability is transforming the role of systems engineering from the original hand-off environment to one where SEs and the system model literally participate in all aspects of the product design and lifecycle. But what does that broader SE’s participation and system model traceability mean exactly?

MBSE traceability gap

To start with, MBSE methodology is implemented via sophisticated modeling languages like SysML. SysML allows SEs to capture incredibly complex system models. These include detailed definitions of requirements, system functions, logical breakdown of the architecture, and an encapsulation of the target physical implementations. It also captures state machines, user activities, system behaviors, control and data flows, interfaces, etc. You get the idea. The resulting model is complex and all encompassing. That’s great for managing complexity on an abstract level (without detailed MCAD, ECAD, or software implementations), but is challenging in terms of exposing what is in the model to the rest of the organization.

To help others understand details of a system model, SEs are forced to generate simplified views of the model for the mechanical, electronic, electrical, and software engineering teams that are responsible for detailed implementation of the system. These views contain partial information extracted from the model: a list of requirements, a table of parameters, and a set of “hard copy” diagrams. That’s great for reducing abstraction of the system model, but it results in a gap between the system model that the SE sees and what the design teams see. The gap keeps both sides in the dark regarding changes implemented by either side since the system model and the detailed designs evolve constantly. So, how can we bridge the traceability gap between MBSE and the detailed MCAD, ECAD and software designs?

Traceability without any gaps is critical because as Aras’ CEO, Peter Schroer, likes to say, “it is all about keeping CEOs out of jail.” Imagine a catastrophic failure of a car breaking system—clearly a life-threatening situation. The immediate task is determining whether the failure is specific to that car model, a family of car models, or a platform of components regardless of the car model. It will be very difficult to do so without being able to trace back all the decisions and relationships that influenced creation of that specific configuration—a Digital Twin that is specific to that VIN. What’s in the vehicle you drive and how it behaves is unique because it is a super-set of how it was designed, where it was manufactured, what options were added by the dealer, how it was driven, and all the maintenance done to it since leaving the dealership (including over-the-air software updates). This has a lot to do with enabling the related Digital Thread which, in turn, facilitates virtual assembly of a Digital Twin. In other words, a Digital Twin (of a specific VIN) does not exist until: 1) a car has been built, and 2) Digital Twin was traversed for that VIN.

And that brings us right back to the gap previously discussed:

  • Bridging the gap between MBSE-generated data and the rest of design teams
  • Enabling SEs to interact more effectively with the domain-specific design teams
  • Maintaining a true Digital Thread between all design artifacts, abstractions, and requirements
  • Providing effective configuration control and change practices across the entire design and product lifecycle

But wait – does this not sound like the original premise of the PLM platforms?

The need for systems engineering within a PLM platform

Let’s be bold and re-imagine the role of PLM platforms in enabling traceability – a complete Digital Thread. With design of complex, multi-disciplinary products, there needs to be a core around which all engineering domains communicate and stay in sync—a common “product” model and a common configuration service that spans all design disciplines. This includes access to the system model that connects MBSE tools with PLM at an appropriate level of granularity. It also includes implementation of a core RFLP representation for the various design disciplines—Requirements (R), Functions (F), Logical elements (L), and Physical elements (P) also at an appropriate level of granularity. Finally, the implementation must allow simplified views of the system model, as related to a specific problem, without having to extract partial data in stand-alone files or static diagrams. This is the essence of a credible traceability.

In addition to core RFLP representations, abstractions such as system model variability and Product Line Engineering (PLE) need to be considered across all phases of a product design. System model variation management (the 150% system that account for all possible variants vs multiple 100% resolved system variants) provides a means for accurate digital thread navigation between the final product and the original design assumptions. PLE manages the engineering of a portfolio of products, thus maximizing reuse, controlling variability, minimizing manufacturing cost, and maximizing manufacturing efficiency. Together they help maintain control of product line diversity across the full lifecycle managed by a PLM platform

MBSE tools will never incorporate all of the concepts of PLM just as PLE will never incorporate all aspects of system model variability. Likewise, PLM will never replace some of the deep functionality in MBSE tools. But, PLM can provide a common set of systems engineering elements including configuration and change management across the lifecycle with traceability, to enable “systems thinking” across the entire organization.

A properly re-imagined role of a PLM system is crucial to connecting the increasingly important roles of SEs to the rest of the design organization. Centrally positioned system models in PLM allow it to act as a connective tissue between the various domain specific disciplines. Together they bridge the existing MBSE gap in a way that is credible and scalable.

  • Pawel, Is there an update on the progress of this string? With the addition of the Simulation Framework - RFLP MBSE SPDM V&V looks like the next step. Please advise.

  • Robin – great question and thanks for reading the blog! That bridge is a vision as far as working off-the shelf solutions are concerned. But it is a vision backed by a fair amount of work already done in terms of definition of use cases and flows. Take a look at this (somewhat self-serving Blush but rather meaningful) demo of things to come that is based on the existing technologies (OOTB commercially available tools that is) -

    This is only one PoC of how to bridge the gap but all of these type of integrations of course assume that the related APIs (for data, process, and services) are open (with a proper permission model). That concept of open and published APIs moving forward is very critical because otherwise the platforms themselves will become closed environments with limited ability to connect with the best of breed RM, SE, ALM, SDM, V&V solutions. And that integration is critical to the concept of a seamless digital thread across design content and intent (!) that persists throughout product lifecycle (design, manufacturing, deployment, maintenance). Pay attention to the tool and PLM platform vendors and how the inevitable market consolidation works for or against this openness. Should the conversation shift from open APIs to some sort of exchange formats – we will be heading in the wrong direction in my opinion.

    So in answer to your question, SysML is not the problem as far as what SEs (systems engineers) need to explore and define. But it is a problem if SysML itself is used as the only way that SEs can explain and guide the rest of design teams (MCAD, ECAD, software, etc.). These are two vastly different uses cases: what SEs do, and how others interact with what SEs did.

  • Pawel, I am not sure from your article whether this bridge exists or whether this is a view of the future. Interesting that you have highlighted that SysML is a language for systems engineers to talk to each other, not other discipline engineers. Maybe that's part of the problem?