There are a number of efforts afoot to come up with a systems metamodel for model-based systems engineering. The necessity for such a metamodel is gaining recognition in the system design world. At its heart, a systems metamodel is a map for guiding system designers from what we know to what we don’t. It is the framework into which we lay our information about the system under examination, revealing where we need additional clarity in order to fully understand that system and its ability to meet our needs. The systems metamodel shines a light on the adequacy of our knowledge of a given system and points us to what we need to know.
The systems metamodel is known by a variety of names. Some refer to it as an ontology, others as a schema. But whatever we may call it, the systems metamodel is a critical enabler for defining and describing a system.
While most of the systems metamodel efforts are seeking to construct or define the framework within which to norm the models that are to be built there, there is a better way than invention for establishing the systems metamodel. Systems, particularly complex systems, exist naturally and are structured on a framework that is common to all of them. By deriving the systems metamodel framework from this naturally occurring structure, systems designers can draw on the power of a proven framework.
The existence of a natural framework can easily be illustrated by looking at rational human behavior. (NOTE: Since we are looking for a framework for designed systems, we will look to intentionally designed or rational behavior, leaving aside for the moment the effects of pathology, inattention, or weakness that may lead to irrational behavior that disrupts the framework.)
We have all heard it said that if we want to understand what a person’s real values are we should look not to her articulation of those values but to her checkbook and calendar. In other words, our application of our resources through our behavior is driven by what we value. Further, our behavior is made possible by the way we create the mechanisms to aid us in performing it. We construct our lives to facilitate the behavior that brings our values to reality.
Our lives are a system driven by our values, realized by our behavior and performed by the mechanisms we create or employ to perform that behavior. For example, if I am committed to obtaining a Ph.D., I will obtain the necessary funding by creating a mechanism or mechanisms to do that. I may get a higher-paying job, use an inheritance, cash in my 401K or adopt some other mechanism so that I can pay my tuition. The value (get a Ph.D.) drives my behavior (pay the necessary tuition) using the mechanism (a higher paying job etc.).
The framework for this system is that the values drive the behavior which is performed by the mechanism. This describes how systems work. They are configured to behave in a way or ways that will achieve their purpose.
Systems metamodel foundation
If we change the nomenclature for values to “requirements,” and mechanisms become “components,” we have a simple foundation for a systems metamodel. Requirements are the basis of behavior which is allocated to the components to be performed by them. Viewed in reverse, components perform behavior which is based on the requirements. This can be illustrated simply as in Fig. 1.
This fundamental picture is the foundation of a systems metamodel that can be applied to any intentionally designed system where the system purpose is defined by a set of requirements that express the needs that drive the creation of the system. Using the systems metamodel to frame the design thinking, behavior can then be specified to satisfy the requirements, and a structure of components can be created to perform the behavior. If the requirements are right-—the subject of a validation process—and the components perform behavior which actually satisfies the requirements—demonstrated by a verification process—the designers can be assured that their system will meet the needs that are driving its creation.
Designing “real” systems in a complex and evolving world demands a more nuanced systems metamodel to account for their more detailed construction. Such a framework can and does exist without losing its fundamental grounding as a positive description of real-world systems structure. (See Fig. 2.)
Note that the fundamental structure of requirements (top), behavior (“function”- right) and components (left) remains intact and is simply elaborated to cover the needed nuance.
Real world grounding
The advantage here is that this systems metamodel is derived from reality and already exists. It does not require development or “inventing.” It is a positive rather than a normative statement of system structure. That is, it isn’t an artificially created description that is set up as a standard or mold into which system models must fit. It is rather a description of the system framework derived from reality to be used as a guide for modeling systems that work in real-world applications.
It is here!
Not only is this systems metamodel grounded in reality, but the nuanced version depicted in Fig. 2 has also been proven over and over again in practical application across more than 50 years. This is the systems metamodel that has been in use at Vitech for decades. It has framed the design of successful systems in contexts ranging from property and casualty insurance processes to missiles and airplanes to intelligence gathering and reporting. It is the foundation of the Vitech tools CORE and GENESYS. In the face of a grounded, proven systems metamodel, there is no need to reinvent what is already working. There is certainly no need to wait for its appearance on an uncertain timeline. It is here today and here to stay.
A few things seem to be missing:
– Desires come before requirements. Requirements are not given by the user directly. They emerge as part of the early system development. The stakeholders provide desires, but usually cannot articulate requirements until some system modeling as been done to provide information of about Performance, Effectiveness, Risk, Cost and Schedule, PERCS. Many system developments fail due to ill conceived requirements. NASP comes to mind.
– A system meta model should explicitly identify all stakeholders, what they do, how they do it and with what tools. Stakeholders are part of the system. Stakeholders, controllers and users, who ultimately control the development and usage of the system, should be explicitly identified. They manage, effect, control and manipulate the many components of system. They do this using software, tools and resources. Controllers and users of the system need to be trained to support the system.
– A system meta model should encompass risk quantification. Systematic risk reduction should direct system development. Risk can be defined as a product of uncertainty and sensitivity of various key performance parameters.
There are other issues but these are the first that come to mind.