Implementing model-based systems engineering in any organization is a journey. It is not something that can be done by bringing home some concepts from an exciting conference and announcing their implementation. It is rather a deliberate process of defining a desired state, mapping the steps to get there and gathering the tools to carry you through the steps. In other words, it is much like undertaking a physical journey.
If we are to undertake a journey of any significance, we need a clear destination. Yogi Berra has often been quoted as saying, “If you don’t know where you’re going, you’ll end up someplace else.” So it is with this journey. We must know where is it that we want to go on our journey to implementing MBSE.
First and foremost, we want solutions to our engineering problems. We want a reasonable assurance that we have identified the best way to meet our stakeholders’ needs.
To accomplish that, we need the ability to see the entire problem and the solution spaces. In order to have the best and most robust view, we need to enrich our model by connecting our systems-level engineering to the design information from the traditional engineering disciplines. Their tools and analytic models provide critical information that can illuminate problem understanding and design choices.
To get that robust picture, we must include connected and concurrent engineering on our destination postcard. “Connected” so that the information flows seamlessly between the disciplines and the model, and “concurrent” so that the various disciplines do not have to stop their solution seeking to pass the baton to another, separate development cycle. Instead, the design advances at a deliberate pace across the entire system.
Do we have a map?
In order to plan our journey, we need a map. The map lays out the design landscape, allowing us to navigate without missing landmarks. To be reliable, the map needs to be published for all on the journey to see. It needs to be proven by others who have used it successfully to make the journey. And it needs to be robust enough to include all of the aspects of the terrain so that we can be confident of when we have arrived at our destination.
In the systems design world, our map is a systems metamodel. It provides the guide to how we arrange the elements, relationships and attributes that make up the system model so that we do not end up with unexplained gaps and disconnects. By following the system metamodel map, we have a place for everything and end up with everything in its place.
In accord with its name, the systems metamodel must be capable of producing a system-level picture. The model that it frames conveys more than any set of discrete drawings could. Google Maps is not a disjoint set of digitalized maps, but is instead a connected model of information that helps us transit from start to end. So it is with good MBSE.
Just as we could not follow a set of snapshots from waypoint to waypoint along a journey in lieu of a map, we cannot expect to use a disjoint set of diagrams to guide us in the journey to MBSE. Those drawings cannot and do not create a usable model of our system. There are too many disconnects and gaps. They cannot, therefore, be an acceptable substitute for a systems metamodel map.
Is our model declared, proven, and robust?
In order to arrive at the model capable of being the basis of our systems engineering, that model must be the result of a journey across a declared, proven and robust systems metamodel. It is declared (published) so that all travelers along this way can see, use and comment on it. It is proven so that we are not left to wonder whether, if we follow it, we are likely to reach our destination. And, finally, it is robust enough to provide for all the information we will need to describe our system.
What is the provenance of our model?
In order to judge the quality of the systems metamodel map we are using, we should look to its pedigree. How was it developed? How long has it been around? Just as the ancient mariners scrambled to map the known world, systems engineers have worked to find their way in our world. Some are just now coming to the realization that a comprehensive, coherent map is necessary to the journey. Others have been mapping, learning, and revising for decades. In either case, there is a realization that we cannot make the trip to MBSE as an ad hoc journey from diagram to diagram.
The figure below shows the historical journey to a systems metamodel. It begins with the work of TRW engineers like Jim Long in the 1960s and flows through Vitech’s development of CORE™ and GENESYS™. Lately, others have begun to look at this as well.
The historical journey to a systems metamodel.
Along the way, it is helpful to collect the experiences of those seasoned travelers who have walked the path before us. The experience and knowledge gained on the journey along with the maps those travelers have drawn make the efforts of the long-time map-makers a valuable resource. Some of the maps have been evolving for decades. Based on the wisdom of experience, they offer the reliability of the test of time.
What are the characteristics of the tools we’ll use?
Once we have a good map, we are ready to consider what tools we will use to navigate. Just as the modern GPS tools record our progress along the map that they have internalized, the best MBSE tool must have the system metamodel embedded as its resident model-making map. This allows the traveler on the implementation journey to use that tool to move along a path tailored to their needs without fear of becoming lost or of not reaching the destination. Just as a GPS navigation tool offers navigation advice to identify landmarks and caution of hazards and wrong turns, the robust MBSE tool will prompt and guide, offering suggestions and choices without controlling or constraining the traveler.
Finding a tool suitable for the implementation journey means placing a tall order. As we begin the journey to MBSE implementation, we are looking for a tool that is grounded in a declared, proven, and robust systems metamodel map. This map should be embedded in the tool so that the tool can not only track our progress along the way but also prompt and suggest efficient routes across the terrain.
It should be based in experience and tested over time, developing a track record of success. It must incorporate input from the surrounding technical disciplines with information valuable to the design decisions along our way.
This is a daunting challenge, but the good news is that such a tool exists. It comes with a declared, proven systems metamodel to show the way. It has an open, robust API to provide for connected, concurrent engineering. It has a track record of success, proving its ability to fully implement the power of MBSE. It is backed by decades of systems engineering knowledge and experience, and engineers who stand ready to show the new traveler the way. That tool is Vitech’s GENESYS. With it, the journey to MBSE implementation can begin now.
