If you’re using a term that you cannot define adequately, then you should drop that term entirely; it cannot help you and will only create confusion later on. Find a better concept.
Read MoreHow a Document-Based Approach Differs from Model-Based
Part 2, Addressing the Differences
In a previous post I derived a definition of MBSE. The challenge that often comes up is, “Aren’t configuration controlled specification documents and requirements databases just another form of representation? Another form of model?” Indeed, they were the basis for models in the past, because in many cases the models resided only in the brains of the customers or designers. The only way to communicate those models were through human language and pictures, hence specifications. Nowadays specifications fail to fulfill modern systems engineering needs for a number of reasons.
First of all, specifications are not visual representations, but descriptive representations. The system is represented in words, with an occasional graphic to either clarify, or possibly confuse, the description. Descriptions rely on the underlying written language. Written language is inherently flexible in interpretation. Grammar is often flexible and dynamic, although more so in spoken language. The underlying information can easily be interpreted multiple ways, depending on the recipient. Additionally, there are no rules on how to describe a system using written language and only the most simplistic rules on the structure of a formal description.
In MBSE, the language is tightly controlled so the possibility of misinterpretation of the model is greatly reduced. Languages for MBSE, such as SysML, have specific rules for how to represent elements in the system and how language elements can interrelate. Furthermore, the graphics generally are coupled to the language, further reducing ambiguity.
Secondly, in written language the strategic information is merely described; the information has no form itself. A description of an element within the system might require many descriptive statements. An engineer can’t point to a single form of that element. At best, the engineer can point to a loose grouping of text that describes the element. Textual representations fail to give form to the information. In MBSE, the system elements and strategic information are individual entities in some type of repository or database. Those entities carry their characteristics with them. A repository of elements and information is what really makes MBSE “model based.”
For these two main reasons, legacy document-centric approaches to systems engineering simply do not meet the intent of modern model based approaches. Yet, let’s face it; textual requirements are not going away any time soon.
The Legacy Runs Deep
Systems engineers still will use textual requirements for the foreseeable future. It’s much easier to create a legal contract around a textual description than a graphical representation, even if the representation resides in a controlled database. It’s much easier to develop verification procedures and checklists around single textual statements than around pictures. Under MBSE the textual requirements get de-emphasized instead of being dropped completely.
Under MBSE, textual requirements should be derived from the content of the model. If the tools to create that model were chosen well, the syntax of the model should be well-formed and translate into textual representations fairly easily.
Summary
Documentation is inevitable, but under MBSE it changes from being the end goal of the systems engineer to being reports that describe the underlying system entities. The specifications and other documents report on the model rather than being the model. This is the essential difference between document-based systems engineering and MBSE.
Learn when the latest articles are posted – Join the vmcse.com mailing list
What is MBSE?
Part 1, Deriving a Definition
Every field of technology has its buzzwords and fads. Systems engineering is no different. The latest buzzword is Model-Based Systems Engineering, or MBSE for short. Is MBSE just a buzzword or real change in how systems engineers do their jobs? Not surprisingly, there are still systems engineers who don’t understand what MBSE is.
A key reason that some SEs still have a blank stare on their face whenever MBSE comes up is that many don’t understand what the term really means. They can expand the acronym, but still not have an understanding. For many systems engineers, MBSE exists only in contrast to legacy systems engineering, which was document based. A document based approach was what most experienced systems engineers learned on the job, and have used throughout their careers. Without a real understanding of MBSE, systems engineers will return to what they know: textual documents, PowerPoint and Visio graphics.
To move SE forward to a MBSE mindset, we need to resolve this issue of understanding; we need to define what MBSE really is. Let’s walk through a process of finding or deriving a definition for MBSE. Along the way we might learn a few things too.
Unfortunately, when you have a buzzword or phrase with vague terms in it, you really have no choice but to delve into the definitions of those terms. When in doubt about a definition, I first go to either a recognized authority, or the dictionary. In this case, we can look to INCOSE as a recognized authority. INCOSE’s SE Vision 2020 provides this definition of MBSE is:
“…the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases. MBSE is part of a long-term trend toward model-centric approaches adopted by other engineering disciplines, including mechanical, electrical and software. In particular, MBSE is expected to replace the document-centric approach that has been practiced by systems engineers in the past and to influence the future practice of systems engineering by being fully integrated into the definition of systems engineering processes.”
INCOSE also provides a definition of systems engineering:
“Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem: Operations, Cost & Schedule, Performance, Training & Support, Test, Disposal, Manufacturing.
Systems Engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.”
Unfortunately, these definitions don’t help very much. They essentially say only that MBSE is an application of modeling that supports the process of systems engineering. So, what is modeling, or a model for that matter? This time we can go to the dictionary. Merriam-Webster has many definitions for “model”, but these seem to be the most pertinent:
Model; noun:…3: structural design4: a usually miniature representation of something; also: a pattern of something to be made
…11: a description or analogy used to help visualize something (as an atom) that cannot be directly observed
12: a system of postulates, data, and inferences presented as a mathematical description of an entity or state of affairs; also: a computer simulation based on such a system
For our purposes, I’ll combine these and synthesize one big definition:
Model; noun: a representation, generally visual, serving as a pattern of some thing to be made, including information such as the structure, data, states, behavior and inferences about the thing
We have a pretty good idea of what a model is now; it is the representation of important information about a system. That information will be unique to the specific system based on the purpose of the system, unique technology, regulatory issues, and schedules, among other constraints. The information will serve to plan, organize, direct and control the lifecycle development of the system, with an emphasis on design and development in the case of systems engineering. We might even describe that information as strategic.
Still, there’s something missing.
Pinned to my office wall is a visual representation of a 10 step process to follow to perform systems architecture. It’s a visual representation of a pattern of steps, and it captures strategic information, but it’s still just a collection of pixels printed on a large sheet of paper. I can manipulate the pixels to adjust size, shape and color, but I can’t manipulate the strategic information. The information has no independent form.
The representation is just a means to visualizing the information. In order to manipulate the information underlying the representation, the information needs to have its own form. It needs to exist in a repository, and there needs to a single controlled copy of it. Furthermore, it needs to have a syntax and meaning to it so that engineers all interpret it the same way. The information needs to be “formalized,” which is supported by definitions in the Merriam Webster dictionary. (Reviewing the dictionary in this case is an exercise left for the reader.)
If we accept this derivation process, combining definitions of modeling with systems engineering, then our definition becomes
MBSE: the process of creating formalized representations, generally visual, that 1) serve as patterns for systems to be made and 2) capture strategic information about the systems, in order to realize those systems successfully.
Personally I think this is a better definition than INCOSE’s, but there is some pride in authorship.
The principles behind MBSE do change the way SEs approach the discipline. The approach radically shifts from writing descriptive documents to an exercise of managing critical information that describes the system patterns. Documentation is inevitable, but under MBSE it changes from being the end goal of the systems engineer to being reports that describe or visualize the underlying information architecture. The documents report on the model. The quality of the information in the model and its organization are the new goals of model based systems engineers.
The next time you need to explain what MBSE is, you have not only a better definition to use, but you should have a better understanding of how the definition came about. For that matter, if you want to challenge the definition, you now have a basis for creating your own.
The typical challenge to this definition is addressed in another post.
Learn when the latest articles in this series are posted – Join the vmcse.com mailing list