Anatoly Levenchuk's Runglish Blog

Below is draft of my text submitted to INCOSE INSIGHT special issue on Model Based Systems Engineering (due to publish 28 dec 2009).

Contemporary usage of word model is as vague as it is a common generalized “description.” When we write model-based systems engineering, it could also be read as description-based systems engineering. But isn’t any engineering description-based, with text, drawings, and formula descriptions? Why did we coin a new term to describe ordinary practice, and stress that this is the future of systems engineering?

I guess the new term would appear to reflect new types of models. However, MBSE is not about any descriptions usually associated with “models.” MBSE is not about simulations and emulations. MBSE is not about using Modelica, a non-proprietary, object-oriented, equation-based language to conveniently model complex physical systems containing mechanical, electrical, electronic, hydraulic, thermal, control, electric power or process-oriented subcomponents, nor finite element analysis models. Neither is MBSE about using complex multi-physics models in simulations of cyberphysics systems, where we simultaneously compute several different nature models. Nor is MBSE about Reference Process Models that we can see in ISO 15288 and other systems-engineering standards.

Model-based systems engineering is about generative models. I am using the term generative here in the same sense as Noam Chomsky’s “generative grammar”; this should not be confused with generative models from statistics. According to Chomsky, “When we speak of a grammar as generating a sentence with a certain structural description, we mean simply that the grammar assigns this structural description to the sentence” (Chomsky1965: 9). Models in MBSE generate system descriptions in the same sense that generative grammar generates sentences. Generative production systems use the same notion of generative grammars – to shape grammars used in a generative design domain. I suppose that such an approach is valid not only to shape languages of mechanical engineering but to all languages that systems engineers experience in interdisciplinary project.

In essence model-based systems engineering, as described by the Object Management Group, is about the use of metamodel layers (description of descriptions layers, language layers) to describe systems. Every layer of the model stack (model M0, metamodel M1, meta-meta-model M2, etc.) can be detailed and/or transformed to “generate” another description that addresses interest of one or more stakeholders, and eventually these comprehensive descriptions will be sufficient to the realization, integration, verification and validation of a system. A key characteristic of model-based systems engineering is the support of multiple viewpoints, that is, multiple methods of modeling to provide multiple views, or in other words, multiple groups of description that addresses different interests of appropriate stakeholders. Fifteen years ago it was not common to accent this multiple-view approach. Modeling was usually mono-modeling that provided one type of view every time, and providing links between relations and objects in different views was a big problem to engineers. The OMG’s Unified Modeling Language was a breakthrough that brought the paradigm of multiple viewpoints or views to mainstream software engineering. UML describes five types of diagram to enable the user to capture different aspects of software systems. Moreover UML is expandable in formal manner, and after a ten-year lag, systems engineering now has a means to provide these multiple viewpoints (ISO 42010) description in the form of SysML.

UML, along with the OMG’s Meta Object Facility (which provides interoperability for all UML-based models), is a core language of the OMG model driven architecture (MDA). The MDA community is rethinking their scope and approach from a software-centric to a system-centric view. Key features of MDA include multiple layers of abstraction (metamodeling) and multiple viewpoints with definite correspondence rules, provided by its metamodels. The main disadvantage of MDA is that it is bounded by UML. Why is UML a disadvantage? Because in a multidisciplinary project we cannot expect that all specialists speak UML or SysML, even if we extend it with domain-specific stereotypes.

Along those lines, the software-engineering community has started down another branch of the modeling movement related to the domain-specific-language (DSL) approach to modeling. Domain specific language provide a viewpoint for expert’s view to particular domain. The domain specific languages approach combines domain-specific metamodels and notation. This is different from the MDA approach, which prescribes MOF/UML-based metamodels and notations. Thus programmers should provide separate integrated development environments for each domain specific language, then experts can use such a suit of specialized integrated development environments to model their systems. A corollary is that all contemporary CAD suites can be regarded as integrated development environment suites for “programming” of engineering domain models in domain-specific languages such as piping and instrumentation diagram languages for modeling of hydraulic systems or 3-D graphical “language” for the modeling of spatial shapes. If we want to capture a facility model of a process plant we have a difficult choice between MDA/SysML modeling of hydraulic systems or modeling it with piping and instrumentation diagram notations. Domain specific languages for contemporary CADs wins hands down. Yet we need to combine all these incompatible domain-specific languages into one coherent facility model.

There exist two options to be consistent among the zoo of different domain specific languages: (1) ontology-based mapping of different DSL metamodels and, therefore, linking domain-specific models in a common data-centric model repository or (2) using a Language workbenches. The ontology-based mapping that is now used by all major CAD vendors uses different upper ontologies and domain taxonomies—for example, ISO 15926 for process industries; ISO 18629 for a process specification language, or ISO 16739 for building information modeling in construction industries. This is a viable option to cope with legacy systems that support “good old domain specific languages for engineering modeling.” It is a relatively fresh movement (started from 1994 work on Shell’s downstream data model ), originating from the data-modeling branch of software development. Now adopters of this approach are moving toward using the readily available semantic Web tools to perform data modeling and data integration, starting with experiments in logical reasoning for “executing” of ontology-based models. Today most ontologists (or data modelers) previously were programmers, software analysts, and database architects; in other words, this field is de facto now part of software engineering, not systems engineering.

Language workbenches are newly emerging integrated development environments that are especially devoted to multiple domain specific languages . Developing a language-independent interpreter/compiler and language-independent (graphical) editor is a challenging and complex task. But the prospects are attractive: every expert can get her own customized DSL and all these domain specific languages that addresses multiple stakeholders’ interests will work in concert with one another. Moreover, these distinct descriptions that provide separations of concerns can be used for different purposes and in different ways: they can be validated for consistency, transformed to output language suited for manufacturing tools, or transformed to executable simulation models.

This approach may prove superior to that of model-driven architecture with UML orSysML), because of the freedom of language choices with retaining of coherent model. Engineering-domain experts will get integrated development environments (editors, interpreters, repositories) for languages that they are accustomed to using (both the metamodel part of these languages and notational part), not stereotypes of UML with predefined UML semantics in predefined UML syntax. Language workbenches permit programmers to easily produce domain-specific integrated development environments while still providing a common repository for different domain-specific models that are produced by different experts in the different languages. You may think about language workbenches as “CAD for CAD” that preserve the freedom of an arbitrary domain language (metamodel+notation) choice. It is unlike UML modelers that permit a choice from UML-defined metamodels only and from UML stereotype notation only. Programmers will add languages to common language environment (viewpoints), and domain experts will develop model (views) with this languages. Everybody will be doing that she doing best.

Today, language workbenches are limited to the software community. Language workbenches first appeared in the form of integrated development environments for compiling multiple domain specific languages to Java or C#, not to “compile” multiple engineering domain specific languages to a facility model in contemporary CAD suites. So far, systems engineers have ignored the domain specific language and language workbench approaches. Systems engineers are just now using SysML to create consistent models instead of domain-specific languages—much like programmers a few years ago used Java only, not Java+DSLs.

Systems engineers may continue to lag behind the software community in adopting these new modeling approaches from software engineering. However, I believe they should overcome their resistance to change, and begin to experiment with these new technologies. This would result in SysML being merely the point of departure for model-based systems engineering, not the destination point.

References

Chomsky, N. 1965. Aspects of the theory of syntax. Cambridge, MA: MIT Press.
ISO 42010:2007/IEEE 1471:2000. Recommended practice for the creation, analysis, and maintenance of software-intensive system architectures. Geneva: ISO.
ISO/IEC 15288:2008 Systems and software engineering — System life cycle processes. Geneva: ISO.
ISO 15926-1:2004. Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities — Part 1: Overview and fundamental principles. Geneva, ISO.
ISO 18629-1:2004. Industrial automation systems and integration — Process specification language — Part 1: Overview and basic principles. Geneva: ISO.
ISO/PAS 16739:2005. Industry Foundation Classes, Release 2x, Platform Specification (IFC2x Platform). Geneva: ISO.