As the practice of Model-Based Systems Engineering (MBSE) is advancing, the focus is shifting from the implementation of new tools such as SysML authoring tools to the integration of these tools in the larger systems development process. Increasing numbers of integration solutions are being offered. The purpose of this multi-part blog series is to lay out some of the considerations engineering organizations might use to compare these solutions and identify the right one for their purposes.
Figure 1 Objectives of MBSE
The core principle of MBSE is that the system can be described by a single unified digital model. From this single source of truth, all the views, artifacts and documents required for system development can be generated (Figure 1) and they must necessarily be consistent. As the system evolves, fresh documents, etc., can be generated at need. The model can be validated and the system verified against requirements on a near-continuous basis and something approaching “agile systems engineering” can be implemented.
The challenge, of course, is that organizations use a wide variety of software tools and data repositories to create and store systems data. In the cyberphysical domain, this can include PLM, CAD, ALM, architecture, requirements, simulation, test and project management software tools, among others. In each of these tools, we have models, by which we mean data elements connected by semantic relationships. The goal is to bring together these models in a useful fashion to achieve the MBSE vision of a single digital model.
Objectives of Integration
Any modeling effort should begin with intention, asking the question, “what do we intend to achieve with this integration?”. Part of the confusion in this area is that different approaches support different objectives. While these objectives are not entirely exclusive, new MBSE adopters should consider their priorities in evaluating integration solutions.
Integration to Support Collaboration
Project teams include many people, usually representing multiple disciplines and responsibilities. An integration solution can allow all these team members to access the information they need when it resides in another area or domain. It allows them to use this data in their own work; it may also allow them to comment upon, or even change this information.
Integration to Support Definition
The ability to define what the system is at any moment in time becomes problematic when the data resides in multiple models in multiple tools. An integration solution can specify that definition and enable the documentation of that system in a form such as a Technical Data Package. The phrase Digital Thread is often used to capture this concept.
Integration to Support Simulation
Simulating a system frequently requires combining multiple analysis and simulation models with inputs from design models, quality and field performance to adequately predict system behavior. An integration solution can pipeline the outputs of one model to the inputs of another and add a framework for design of experiments or optimization to more efficiently explore the system design space.
Integration to Support Workflow
The DevOps concept in software development has spawned suites of tools dedicated to facilitating, or even automating, the transfer of new code from requirements specification all the way to deployment. Similar concepts can apply to all of the objectives above, where the integration solution enables the continuous verification, validation and documentation of the system.
Evaluation Criteria for Integration Solutions (IS): Objectives
In this blog series, I will start to develop a list of criteria that organizations might use to evaluate or differentiate between integration solutions.
In subsequent posts in this blog series, I will provide additional discussion and tables for other issues that organizations might consider in evaluating integration solutions, including technical approaches and non-functional requirements. In later parts, I will use our Syndeia interoperability platform as an example to demonstrate how an evaluation might look.