It’s interesting how something as basic as the definition of a “model” can range so much in the systems engineering community. Many of us could spend hours debating whether a drawing is a model. I discuss this in “Drawings Do Not Equal Models.”
SEBOK defines a model as “a simplified representation of a system at some particular point in time or space intended to promote understanding of the real system. As an abstraction of a system, it offers insight about one or more of the system’s aspects, such as its function, structure, properties, performance, behavior, or cost.” – Representing Systems with Models
We also can continue to see that the SEBOK describes a model as: “In the context of systems engineering, a model that represents a system and its environment is of particular importance to the system engineer who must specify, design, analyze, and verify systems, as well as share information with other stakeholders.” – What is a Model?
So by these definitions, it is clear that a model is essential to systems engineers and yes, a drawing is a model, but is it the type of model we we are referencing when we are discussing model-based systems engineering (MBSE)? What do these definitions really mean to us as systems engineers?
As a systems engineering doing Model-Based Systems Engineering, I need a model to:
(1) Have a way to describe the system and its environment as simply as possible to make it understandable in words and in pictures.
(2) Be verifiable through computable representations.
A model becomes a tool for us to describe the system to the stakeholders, by answering the questions: What?, Why?, Where?, When?, How?, and How Much, etc. Ultimately, we need to be able to create a specification that can be used to buy or build the system and demonstrate to the owners and users of the system that it meets their needs.
In a recent discussion with Dr. Kathy Laskey from George Mason University (GMU), she recommended looking at the work of Dr. Leo Obrst. Dr. Obrst discusses the range of models from weak semantics to strong semantics in “The Ontology Spectrum and Semantic Models.” On the right is Dr. Obrst’s “Range of Models” graph. Over the years, we’ve moved towards stronger semantics. Our goal needs to remain moving from weak to strong semantics. Our language must help us do this. The Lifecycle Modeling Language (LML) was developed to meet this goal of stronger semantics by defining both ontology and a set of diagrams needed to express key parts of the ontology. LML, in addition to the three mandatory diagrams (Action, Asset, and Spider) recommends using common visualizations for all the entities defined by this ontology, including Cost, Risk, and Time. The figure below (from my October 2016 NDIA SE Division Conference presentation on “What is a Model? Understanding the First Word in MBSE”) shows my attempt to show the languages and modeling spectrum in the same way that Dr. Obrst shows the range of models.
Innoslate helps develop logically consistent models by adhering to those standards. Innoslate® uses the LML standard for those visualizations, as well as the SysML and IDEF0 standards for those visualizations. The difference between using Innoslate and a drawing tool comes from Innoslate’s generation of the picture from the data. So when you create an Action Diagram you automatically get the equivalent SysML (Activity, Sequence, Use Case, etc.) and IDEF0 diagrams, thus reducing the time and cost of developing these different visualizations.
The LML is a specification that can be used to buy or build the system and demonstrate to the owners and users of the system that it meets their needs. Innoslate and LML give systems engineers a way to describe the system and its environment as simply as possible to make it understandable in words and in pictures through computable representations.