Models in Engineering
About values when modeling during engineering activities
Introduction
Scope
This article deals with different values that models should bring to the different engineering analysis such as the system analysis.
It revisits the different values expressed in model based engineering manifesto during the 19th International Federation for Systems Research (IFSR) Conversation [1].
Acknowledgement
Special thanks for their contribution to this article to:
- Samuel Boutin, especially during the discussions around his french white paper [2] on the same topic.
- Remy Fannader, for his insights on modeling semantics.
If you are interested in discussing these different values, please contact me.
Definitions
Model: a semantically closed abstraction of a system or a complete description of a system from a particular perspective. (from ISO/IEC/IEEE 24765:2010)
System: combination of interacting system elements organized to achieve one or more goals (adapted from ISO/IEC/IEEE 15288:2015 Systems and software engineering — System life cycle processes)
Requirement: 1. A condition or capability needed by a user to achieve a goal. 2. A condition or capability that must be met or possessed by a system or system element to satisfy an agreement, standard, specification, or other formally imposed documents 3. A documented representation of a condition or capability as in (1) or (2) (adapted from ISO/IEC/IEEE 24765:2017 Systems and software engineering — Vocabulary)
Function: transformation of inputs to outputs, by means of some mechanisms, and subject to certain controls, that is identified by a function name. (from IEEE Std 1320.1–1998 (R2004) IEEE Standard for Functional Modeling Language — Syntax and Semantics for IDEF0.2.1.53)
Flow: output produced by a function and consumed by another function. It can be functional (information) or physical (flow of energy, particles…) (adapted from Systems Opportunities and Requirements, 2012, Alain Faisandier)
Diagram: (model) view that displays a set of (model) elements graphically
Element: object or phenomena (adapted from Modeling Primitives as Music Keys, Remy Fannader)
Attribute: characteristics of elements that belong to them and make them recognisable (adapted from Modeling Primitives as Music Keys, Remy Fannader)
Hierarchy: consequential concept of simultaneous multiple containment of one element by many containing elements (adapted from Systems Thinking, Systems Practice, Checkland, P. 1999)
Synthesis
To deal with the challenges of increasing system complexity, interdependency and breakdown of document-based methods, the model based engineering manifesto expressed from the 19th International Federation for Systems Research (IFSR) Conversation [1] identifies the following different values for a model based engineering such as the model-based systems engineering:
- Information over Artifacts
- Integration over Independance
- Expressiveness with rigor over flexibility
- Model usage over Model creation
To address the new challenges of accelerating the decision-making process in a Volatile, Uncertain, Complex and Ambiguous environment and enabling knowledge-based engineering, model-based engineering need to evolve to the following new values:
- Knowledge over Artifacts
- Engineering language over Modeling language
- Explicit hierarchy over Implicit relationship
- Semantics over Graphics
Values statement
#1. Knowledge over Artifacts
The value of a model lies in the knowledge it brings to support the decision-making process of an engineering analysis, not in the artifacts it could generate.
This value was expressed in [1] as “Information over artifacts”:
[…] engineering practices focus on the generation of artifacts to codify and communicate design information. These artifacts often collect and present that design information relative to specific stakeholder groups and concerns, leading to the same information being reused and repackaged across many artifacts. In a model-based engineering paradigm information can be easily assembled in a variety of forms, for a variety of purposes easily. As a result, the engineering job and our engineering processes must focus less on the generation of those artifacts, but on the information needed to generate any artifact for any stakeholder viewpoint.
Rather than valuing the information, we need nowadays to value the knowledge that is expressed through the different modeling elements, their relationships, their attributes and their values:
- Types of elements, attributes and relationships represent the information of a model;
- The values of the attributes of elements / relationships represent the data of the model;
- How the information and the data of the model are combined together to create new information and/or new data represents the knowledge expressed by the model.
This combination was expressed by Remy Fannader in its system perspective applied to Enterprise Architecture:
Perspectives combining data and information views can be used to map out the links between business intelligence and users’ needs on the one hand, models of managed information on the second hand.
Where the links between business intelligence and user’s needs is the knowledge expressed by the enterprise architecture model about how adequate the business intelligence is with users’ needs.
Another example of this combination is the knowledge behind the configuration of the right alarm level of Manufacturing Execution System [MES] that supervises an industrial system effectiveness.
This effectiveness can be modeled as an Overall Equipment Effectiveness [OEE] as shown in the diagram below:
Where:
- Red model elements represent the industrial system attributes (its qualities)
- Blue model elements represent the relationships between these attributes (their constraints)
Introducing data coming from the real industrial system over the time allow us to characterize the dynamic of this effectiveness (range, distribution) thanks to the interpretation of the model by a simulation engine:
Thus allowing us to define the range of OEE outside of which the system will consider as being inefficient, leading the MES to raise an alert.
This range will be a new attribute of the MES whose values are derived from the knowledge of the industrial system dynamics expressed by the combination of the information of the OEE constraints and the data coming from the industrial system.
#2. Engineering language over Modeling language
To bring an engineering knowledge in the decision-making process, the model needs to be understandable by any engineering people in a non ambiguous manner. Thus model requires an engineering language, not a modeling language.
This engineering language must not only be focused on one engineering domain (such as object oriented modeling languages were initially focused on software engineering domain), but should be able to support all the engineering domains. This statement was also expressed in [1] as “Integration over independance”:
Engineering practice relies on decomposition and separation of concerns to produce designs that meet complex challenges. This is typically accomplished by dividing the engineering job by domain or subsystem requiring the disintegrated groups to come together periodically at milestones to reintegrate design information. The model-based engineering approach, on the other hand, allows for design information to remain integrated over a project life cycle. Design information from different model-based domains can be related, allowing the collective, integrated design to be continually consistent.
This engineering language must be based on a subset of the natural language in the way that the translation between the model visualization and this subset is not ambiguous. This statement was also expressed in [1] as “Expressivness with rigor over flexibility”:
The model-based engineering requires the linguistic features of semantics and syntax to ensure that interpretation is not ambiguous and unpredictable, while still providing sufficient freedom to cornpletely define design. This, we describe as a duality of rigor and expressiveness, enabling complete and consistent use of modeled engineering design.
The advantage of this approach was mentioned by Dov Dori in the forewords of his book “Model-Based Systems Engineering with OPM and SysML”:
OPM […] represents the system simultaneously in formal graphics and natural language. […] The advantage of this approach lies in appreciating the human limitation to the understanding of the complexity. As systems become more complex, the primary barrier to success is the ability of the human designers and analysts to understand the complexity of the interrelationships.
As an example, let see how a system “OnStar System” and its main function “To rescue driver” can be defined in two different modelling languages :
- Object Process Language [OPL] supporting Object Process Methodolody [OPM] from ISO/PAS 19450:2015.
- System Modeling Language [SysML] from ISO/IEC 19514:2017.
Using OPL, this results in the following diagram and definition:
Using SysML, this can result in the following diagram, depending on the SysML element you choose to model a function:
To find the definition of this diagram in natural language, the UML Superstructure Specification needs also to be considered in addition to the SysML Specification for the relationship between a “boundary” and a “use case”, because SysML use case diagrams rely on UML ones:
- “OnStar System” is a boundary
- “Driver Rescuing” is a use case
- “Driver Rescuing” applies to the boundary
Please compare these two definitions sets (OPL and SysML) with the following definitions that most engineers would express naturally:
- “Driver Rescuing” is the main function of the system “OnStar System”
- The system “OnStar System” realizes the main function “Driver Rescuing”
Which could be decomposed into the following steps:
- “OnStar System” is a system
- “Driver Rescuing” is a main function
- “OnStar System” realizes “Driver Rescuing”
#3. Explicit hierarchy over Implicit relationship
To understand the complexity of the interrelationships inside a system, model needs to be structured through explicit hierarchies between elements, not implicit relationships between them.
These hierarchies allow to decrease the complexity level of the interrelationships, starting from the most complex one (the system as a whole) down to the simpliest one (the simpliest system element or flow to consider).
Each of these hierarchies are related to a perspective on the system. For example :
- The “Requirement Breakdown Structure” [RBS] is the explicit hierarchy related to the requirements perspective on the system.
- The “Functional Breakdown Structure” [FBS] is the explicit hierarchy related to the functional perpective on the system.
They are also related to each other through other hierarchies that combines them to ensure the consistency at the most complex level. Following the last example, the functions expressed in “Functional Breakdown Structure” are specified by requirements expressed in “Requirement Breakdown Structure”. The resulting hierarchy ensures the consistency of the functional analysis of the system as a whole.
Same situation when the hierarchies between flows and interfaces are considering. For example between RBS, FBS and FeBS where functional elements [Fe] are also specified by requirements and by the functions they are responsible for.
#4. Semantics over Graphics
To support an engineering analysis in a consistent and efficient manner, vizualisation of model elements requires generative diagrams based on semantics, and not static diagrams based on graphics.
Modeling tools allow the user to build manually its model by drawing graphical elements like boxes and arrows in different diagrams, making the consistency between them very hard to maintain over the time.
Moreover, the only way to generate a new diagram with a subset of these elements is to select them manually from a browser or a tree or an already existing diagram, and arrange them graphically into a new diagram, which is time consuming and not efficient.
To be more efficient and to ensure the consistency between the different diagrams and their elements, the diagrams must be generated based on a query expressed in an engineering language.
For example, considering the following functional chain made of 3 different functions F1, F2, F3:
This representation could be generated thanks to a query like “show chain F1, F2, F3”.
Changing the representation from a chain to a sequence should be available through a query like “show sequence F1, F2, F3” and should give such answer:
Adding a new flow “d” from the function F3 to F1 should modify both representations without applying explicitly specific filtering commands:
