Learning from MBSE’s past
It’s an open secret that development projects have become unduly challenging for many businesses and industries around the world. Producing innovation is not a trivial task and throwing in the complex supply chains that surround these advancements require does not make it any easier. But this story is neither new, nor unique. It even had a solution, well multiple solutions, over the greater half of the last century. That solution was systems engineering (SE) and then model-based systems engineering (MBSE), both were valuable but neither fully matched the struggles at hand for complex production integration and cross-domain engineering practices. Even without complete success, these solutions provide valuable information on how to create the future development processes, by looking at their weaknesses.
For a high-level understanding of what these legacy solutions entail, the first part of this series is a great starting point for the uninitiated. But a brief explanation is that it is a organizational process to identify and define requirements from early concept design to then engineer, optimize, and validate against over the course of development of use of a product. The goal is to coordinate each of the stakeholders early on to understand the product comprehensively (a system architecture) and provide the best results for the business and customers.
The evolution of systems engineering
The process for creating these architectures has changed over time, as systems have become more complex, with many more interconnected systems vying for importance. The first system architectures were defined by physical system drawings, where a component or subsystem is abstracted into its inputs and outputs. This provided some under-standing of how systems interconnect, but the physical format was difficult to revise or share – two key components of MBSE today. The next iteration of systems modeling came in the form of digital documents using Visio and PowerPoint. These digital documents functioned similarly to system drawings but provided access to greater detail, a means to revise the architecture more readily, and an opportunity to share the information quickly in a globalized value chain.
Another leap forward came with the introduction of Systems Modeling Language (SysML), enabling the digital representations of the system to be analyzed in the model. Previously, an interrogation would have required a separate tool to create and run the analytical models of the system. A critical part of SysML to an MBSE approach was that it established a standard method for analyzing the available information. But the most important part of SysML remains that it established a powerful dialogue within the systems engineering community about the need to use digital, model-based representation of system architectures that was traditionally done with the help of documents.
What to learn from the past
While SysML provided many benefits to the system modeling workflow over document-based methods, it was not without limitations. The language was built on the Unified Modeling Language (UML) from the world of software engineering, which was not known to engineers from many other disciplines, including system engineers. This left many inconsistencies in system architecture-driven development of the complex and interdependent systems of modern products. Many wanted to use this new way of representing their systems for development planning and optimization but sticking with SysML required sophisticated and oftentimes completely custom tools to provide the required capabilities.
To compensate for its limited native functionality, many customers, vendors, and competitors developed customizations that augmented the SysML framework with an MBSE methodology. While the custom extensions created internally for SysML users provided the modeling functionality, the customization negated the benefits of a standard language – interoperability. System architectures and models sometimes could not be exchanged between vendor-specific tools thus limiting model-based communication between multiple stakeholders. The communication problem only compounded when MBSE extended into the diverse supply chains of modern products. The modeling methodology was no longer open and connected, the architectures became isolated from the greater organization, and sharing information meant disconnecting from what was symbolic of a single source of truth for the product.
Is there a path forward?
The story for SysML does not end there, users including industry adopters, vendors, consultants and developers have continued to collaborate on creating a better version to overcome the challenges of the initial implementation. Learning from challenges and limitations from the past, companies like Siemens are working together on SysML v2 development which is significantly different than its predecessor, leaving the UML roots behind. The new implementation operates on an entirely new meta model to provide a litany of new capabilities to the system engineering process. SysML V2 development also addresses interoperability, thereby enhancing effective communication between stakeholders in a vendor-neutral description. SysML v2 brings model variability capabilities to enable model development that describes the overall product configurations in the system architectures. The common tools tacked on through 3rd party extensions are being integrated into the standardized language, making way for greater collaboration.
Siemens Xcelerator, the comprehensive and integrated portfolio of software and services from Siemens Digital Industries Software, helps companies of all sizes create and leverage a comprehensive digital twin that provides organizations with new insights, opportunities and levels of automation to drive innovation.
For more information on Siemens Digital Industries Software products and services, visit siemens.com/software or follow us on LinkedIn, Twitter, Facebook and Instagram. Siemens Digital Industries Software – Where today meets tomorrow.
