Conference PaperPDF Available

Multi-Paradigm Modelling For Model Based Systems Engineering: Extending The FTG + PM

Authors:
MULTI-PARADIGM MODELLING FOR MODEL BASED SYSTEMS ENGINEERING:
EXTENDING THE FTG+PM
Randy Paredis
Joeri Exelmans
Hans Vangheluwe
University of Antwerp Flanders Make
Middelheimlaan 1
Antwerp, BELGIUM
{randy.paredis, joeri.exelmans, hans.vangheluwe}@uantwerpen.be
ANNSIM’22, July 18 20, 2022, San Diego, CA, USA; ©2022 Society for Modeling & Simulation International (SCS)
ABSTRACT
Model Based Systems Engineering (MBSE) supports Cyber-Physical Systems (CPS) design, by experts
from various domains, through complex workflows, manipulating models in different formalisms, each with
their own methods, techniques and tools. We refer to often-used combinations of workflow and formalism
patterns as modelling paradigms. The Formalism Transformation Graph (FTG) and Process Model (PM)
are key components in Multi-Paradigm Modelling (MPM) based MBSE, which combines multiple mod-
elling paradigms. This paper extends the FT G+P M framework: a Process Trace (PT) records all start/end
events of engineering activities as well as all versions of all artifacts consumed/produced by them. A PT
results from the enactment of a PM. The artifacts and activities in the PT are “virtual”: though referred to
in a technology-agnostic manner, they are realized using various technologies. Adapters translate between
both, making the FTG+PM federated. An Automated Guided Vehicle (AGV) example is used.
Keywords: Formalism Transformation Graph and Process Model (FTG +PM), Model-Based Systems En-
gineering (MBSE), Multi-Paradigm Modelling (MPM)
1 INTRODUCTION
The technical systems we build, and in particular, Cyber-Physical Systems (CPS), are of an ever increasing
complexity. CPS emerge from the networking of multi-physical (mechanical, electrical, hydraulic, bio-
chemical, . . . ) and computational (control, signal processing, logical inference, planning, . . . ) processes,
often interacting with a highly uncertain environment, including human actors, in a socio-economic con-
text (Carreira, Amaral, and Vangheluwe 2020). It is the heterogeneity in views, components, abstractions
and their many inter-relationships, in combination with the many stakeholders from different domains, col-
laboratively designing such systems, that contribute to their complexity. It is the purpose of the Systems
Engineering (SYE) discipline to design, integrate, and manage such complex systems over their entire life
cycle (Kassiakoff et al. 2010). Starting from an initial set of goals, SYE carries out a number of activities
(human and/or automated) to achieve these goals. The combination of these activities is called the workflow
or life-cycle. It can be explicitly modelled in a workflow or process model (PM), in an appropriate modelling
language such as UML Activity Diagrams (Object Management Group 2017). Russell, Van Der Aalst, and
Ter Hofstede (2016) discuss a set of workflow patterns which are useful when designing a PM.
461
Authorized licensed use limited to: Universiteit Antwerpen. Downloaded on August 25,2022 at 08:05:45 UTC from IEEE Xplore. Restrictions apply.
Paredis, Exelmans and Vangheluwe
To help realize MPM, Mustafiz et al. (2012) introduced a framework for Model-Based Systems Engineering
in which a Process Model (PM) is combined with a Formalism Transformation Graph (FTG), a “map” of
all artifact types (also known as meta-models) and activity types (in the form of contracts) and how they are
related.
Despite its demonstrated advantages, we have noticed that the FTG+PM is incomplete to fully support
systems engineering. On the one hand, there is a need to record a trace of all artifact versions and activity
executions. This, to allow for repeatability, replicability and explainability (Plesser 2018). On the other
hand, there is a need for a uniform and technology-neutral way to represent and manipulate artifacts and
activities.
The remainder of this paper is structured as follows. Section 2 discusses some related work and section 3
introduces a Line-Following Robot system engineering example. Based on this example, section 4 intro-
duces the FTG+PM as well as proposed extensions, Process Trace and Storage/Service/RealWorldArtifact
and the mapping between them by means of adapters. Section 5 shows how the proposed extensions allow
for advanced queries. Finally, section 6 concludes the paper.
2 RELATED WORK
The Unified Modeling Language (UML) 2.0 defines so-called Activity Diagrams (Dumas and Ter Hofstede
2001). They capture the behaviour and process flow, and are similar to flowcharts (European Computer
Manufacturers Association et al. 1966). The Business Process Model and Notation (BPMN) standard is
used to describe workflows within (mostly) a business context (White 2004). These processes can easily be
mined and optimized to detect common (anti-)patterns, reduce bottlenecks and increase efficiency (van der
Aalst 2016). The Interaction Flow Modeling Language (IFML) is a similar graphical notation to describe
user interactions and front-end behaviour (Brambilla and Fraternali 2014). The aforementioned languages
are often used to describe and analyze Product Lifecycle Management (PLM) (Grieves 2006). Van Mierlo
et al. (2018) compare multiple workflow modelling tools/languages, including Activity Diagrams, BPMN
and FTG+PM.
Different models often provide different viewpoints (for specific stakeholders) on a system. These models
are often described in appropriate Domain-Specific Languages (DSLs). Karaduman et al. (2021) clarify the
use of viewpoints in FTG+PM. The “black box” combination, integration and interaction of heterogeneous
models is called model federation (Golra et al. 2016, Wagner et al. 2020, OpenMBEE Organisation 2011).
Instead of enlarging a single meta-model with new information, adapters are used to bridge the gap between
the multiple meta-models. Tools such as PAMELA (Guérin et al. 2021) and Syndeia (Bajaj et al. 2016)
support model federation.
Many definitions for megamodel exist (Hebig, Seibel, and Giese 2012). In essence, it is a collection of
related models. Salay et al. (2015) describe how such megamodels can be managed, and Favre and Nguyen
(2005) discusses how software (and thus system) evolution can be modelled. Maro (2020) performs a
literature study and some optimizations for traceability in software systems. It also discusses some tools and
techniques (including versioning) to obtain traceability. Hassane et al. (2019) introduce MAPLE-T, a tool
for process enactment with traceability support based on megamodels.
One advantage of an explicitly modelled workflow of system development becomes apparent when one tries
to recreate the system or even just to understand what decisions in the past led to the current realized system.
In scientific experimentation, the terms repeatability (the same team can produce the same results with the
exact same experimental setup), replicability (a different team can produce the same results with the exact
same experimental setup) and reproducibility (a different team can produce the same results with a different
462
Authorized licensed use limited to: Universiteit Antwerpen. Downloaded on August 25,2022 at 08:05:45 UTC from IEEE Xplore. Restrictions apply.
Paredis, Exelmans and Vangheluwe
experimental setup) are used (Hong 2021). Explicitly modelling and recording workflow clearly supports
repeatability and replicability in systems engineering projects.
In its 2035 vision for SYE, the International Council on Systems Engineering (INCOSE 2021) describes
the critical role Model-Based Systems Engineering (MBSE) plays in tackling increasing system complex-
ity, mainly when supported by toolchains (Ma et al. 2022). It also states the importance of integrated
analysis in a broad set of system domains. We believe that Multi-Paradigm Modelling (MPM) can help
realize INCOSE’s 2035 vision. MPM proposes to model every part and aspect of a system explicitly, at the
most appropriate level(s) of abstraction, using the most appropriate modelling formalism(s), while explicitly
modelling workflows (Mosterman and Vangheluwe 2002, Mosterman and Vangheluwe 2004, Amrani et al.
2021).
3 EXAMPLE USE-CASE: AUTOMATED GUIDED VEHICLE DIGITAL SHADOW
To illustrate the contributions of this paper, the proposed FTG+PM extensions will be applied to a simple
Automated Guided Vehicle (AGV) (i.e., a Line-Following Robot (LFR)) example that was first introduced
in (Paredis and Vangheluwe 2021). An AGV needs to be designed and realized whose goal is to follow a line
on the ground as closely as possible whilst moving swiftly, economically and safely. In the digital world,
a virtual (simulated) copy is created, acting on the same input from the environment as the real system.
The real and the simulated robot should follow the exact same trajectory. Through comparison of the two
trajectories, anomalies in the operation of the robot can be detected. Such a setup is called a Digital Shadow
(Kritzinger et al. 2018). Paredis and Vangheluwe (2021) includes an early version of an FTG+PM for an
AGV system, which was later adapted in (Paredis, Gomes, and Vangheluwe 2021).
The AGV is parametrized by its wheel radius rand distance between the wheels d. Its time-varying state is
captured by the robot’s velocity vand its heading ω. Ideally, the position (and heading) of the real and the
virtual AGV should be sufficiently close at all points in time, independent of the line to follow.
Figures 1a and 1b show traces of this system’s behaviour. The full green line represents the path to follow,
the blue, dotted line identifies the Digital Shadow simulated position and the red, dotted line depicts the
position of the realized robot. In trace1(Figure 1a), the realized system is unable to accurately follow the
line. This is because the model used in the simulation is used outside its validity range (Denil et al. 2017)
with respect to the real-world physics. trace2(Figure 1b) shows a better version produced after a few design
iterations. Such iterations in workflows are common in industry, and the purpose of this work is to explicitly
describe them.
Anecdotal evidence from industrial partners has shown that over 80% of the time spent goes into finding old
information (models, data, choices made) in the massive amount of historical information. In many cases,
it turns out the needed information was not even recorded. This is exacerbated in cases of collaboration
with multiple stakeholders (in different domains). Not explicitly tracking/storing all information about the
executed activities and the artifacts they manipulate will often result in a severe waste of time trying to
locate/re-create this information.
Despite its simplicity, the AGV use-case presented contains a large number of distinct processes and inter-
mediate results, making it good demonstrator for our research.
4 FORMALISM TRANSFORMATION GRAPH AND PROCESS MODEL (FTG+PM)
The FTG+PM was introduced to guide system developers in their (model based) system engineering efforts
(Mustafiz et al. 2012). Figures 5 (FTG) and 2 (PM) show a simplified version of an FTG+PM describing
463
Authorized licensed use limited to: Universiteit Antwerpen. Downloaded on August 25,2022 at 08:05:45 UTC from IEEE Xplore. Restrictions apply.
Paredis, Exelmans and Vangheluwe
(a) trace1(b) trace2
Figure 1: Behaviour (position) traces of the AGV realization (robot) and Digital Shadow (simulation).
the creation of an AGV. For simplicity, the Digital Shadow part was omitted in this paper and only the
system design and realization is shown.
4.1 Process Model
The Process Model (PM) is a workflow model, which precisely specifies a combination of activities (rep-
resented by rountangles) that are carried out to achieve the system engineering goal. These activities are
connected through control flow connections (represented by bold, blue arrows), which may split into con-
current activities and may subsequently be joined, denoting synchronization. Both split and join are repre-
sented by solid blue bars. Multiple control flow outputs of a single activity indicate choice. For example, the
sys_ana: System Analysis activity may result in a new version and loop back for another iteration, or ter-
minate the process (denoted by a solid blue circle with a line around it). Note the underlined instance:Type
notation, which will be further explained later. There is also data flow: each activity may use and/or produce
artifacts (represented by green arrows and rectangles). PM concrete visual syntax was originally based on
UML 2.0 activity diagrams, but was modified based on “physics of notation” principles presented in (Moody
2009), for improved clarity and consistency. Activities can be carried out by humans (identified with a grey
background) or automatically, for example by a computer (denoted by a gear icon and a yellow background).
Activities may be hierarchically de-/composed (represented by a sitemap icon in the activity rountangle).
Starting from the AGV requirements, the system is decomposed into three parts: a control algorithm
ctrl_alg: Algorithm, plant equations plant_eqs: Equations and a design sketch agv_dsg: Sketch. These three
artifacts are developed somewhat concurrently to result in the AGV model (agv_model: CBD) and the AGV
physical realization (agv: AGV). The deploy_sim: Deployment and Simulation hierarchical activity will re-
sult in a deployed system and a behaviour trace, on which some analysis may be done, potentially yielding
insights to be used as input in the development of a new version. Note that this is a representative workflow
for this system, but may evolve over time. Additionally, the developed framework/architecture may change
as well. Any implementation of the FTG+PM must support this kind of evolution (Meyers and Vangheluwe
2011).
464
Authorized licensed use limited to: Universiteit Antwerpen. Downloaded on August 25,2022 at 08:05:45 UTC from IEEE Xplore. Restrictions apply.
Paredis, Exelmans and Vangheluwe
requirements :
MarkDown
bom : Bill of
Material
components :
Hardware
3d_model : CAD
plant_model :
CBD ctrl_model :
CBD
param_guess :
Constants
agv : AGV
agv_model :
CBD
calib_model :
CBD
trace : Table
agv_dsg :
Sketch
plant_eqs :
Equations
ctrl_alg :
Algorithm
system_design :
MCD
new version
system_design
: System Design
cin1
cout
din
dout
cin2
system decomposition
: System Decomposition
agv eqs
cout
cin req dsg
ctrl
digitization
: Digitization
cin
cout
agv
binst
3d
component_gathering
: Component Gathering
cin
cout
agv
comp
dsg
bom
avg_asm
: Robot Assembly
cin
cout
binst comp
agv cnst
plant_mdl
: Plant Modelling
cin
cout
eqs
cbd
ctrl_mdl
: Controller Modelling
cin
cout
alg
cbd
cbd_comp
: CBD Composition
cin
cout
mdl
plant ctrl
calibration
: Calibration
cnst
mdl2
cout
cin
mdl1
deploy_sim
: Deployment and Simulation
cin
cout
agv
trace
mdl
sys
sys_ana
: System Analysis
cin
cout
req
trace
reqs
sys
cterm acc
deployed : Table
build_inst : Building
Instructions
accuracy :
Percentage
Legend:
typedArtifact: Type
activity
hierarchy
automation
data port
control flow port
control flow start
control flow end
split/join
Figure 2: PM of the full AGV system.
465
Authorized licensed use limited to: Universiteit Antwerpen. Downloaded on August 25,2022 at 08:05:45 UTC from IEEE Xplore. Restrictions apply.
Paredis, Exelmans and Vangheluwe
Note that each artifact and activity is identified with a name and a type (i.e., given by a Linguistic Type
Model, also known as a meta-model). By using introspection on this meta-model, the artifact’s structure can
be identified and navigated. Figure 3 shows a simplified Causal Block Diagram (CBD) (Gomes, Denil, and
Vangheluwe 2020) meta-model on the left and an example CBD instance model on the right. This instance
is artifact agv_model: CBD. Note the (OCL) constraints in the Class Diagram meta-model specifying that
all Block instances must have unique names. The CBD model instance conforms to the description given in
the meta-model. Such instances are also referred to as artifacts, for example in the PM.
INV: context CBD inv UName: self.block->forAll(b1,
b2 | b1 <> b2 implies b1.name <> b2.name)
Block
+ name: string
*
Port
*
Inport
*
Outport
1..*
CBD
target source
Signal
CBD: CD+CL
(a) A simplified CB D meta-model.
Ctrl
velocity
color
heading DD
phiLdot
velocity
steering phiRdot
🍀
x
y
color
offset
O
x
phiLdot
phiRdot heading
y
IC
IN1
delta_t
OUT1
0OUT1
DELTA_T OUT1
IC
IN1
delta_t
OUT1
OUT1
IN1
IN2 IN1
IN1
IN2
IN1
(b) A CB D instance model.
Figure 3: A CBD linguistic type model and instance model.
Similarly, activities also conform to a type model, which takes the form of an activity contract. This is
demonstrated in Figure 4. The green rectangles identify the types of artifacts that are expected to be con-
sumed/produced. Note that similarly, the control flow inputs/outputs may also define specific activities that
must precede/follow this activity.
4.2 Formalism Transformation Graph and Meta-Models
The Formalism Transformation Graph (FTG) is a hypergraph which summarizes the relationships between
the formalisms/languages used during the creation of the system and the types of activities used to realize
these relationships. Formalisms are denoted by rectangles, and activity contracts/transformations by roun-
tangles. Figure 5 shows the full FTG for the AGV use-case. As can be seen, there is a clear relationship
between the PM type names and the FTG transformations. Similarly, the artifact type names correspond
to the formalisms. Note that in current FT Gs, as the name indicates, the relationships are actually directed
transformations. If general (bi-directional) relationships are included, the term Formalism Relationship
Graph (FRG) would be more appropriate.
The FTG focuses on the formalism/language/linguistic type aspect of MPM. Note that the name in a node
of the FTG refers to a meta-model (linguistic type model) MM. As an addition to our earlier FTG definition,
we make explicit the need for these meta-models such that the syntax of the formalisms used is unambigu-
ously defined. These meta-models also determine how to Create/Read/Update/Delete instances/artifacts.
Note that navigation through instances is a special case of Read.
466
Authorized licensed use limited to: Universiteit Antwerpen. Downloaded on August 25,2022 at 08:05:45 UTC from IEEE Xplore. Restrictions apply.
Paredis, Exelmans and Vangheluwe
plant_mdl
: Plant Modelling
cin
cout
eqs
cbd
Plant Modelling
cin
cout
eqs
cbd
Equations
CBD
Figure 4: An activity (top) and
its contract (bottom)
MarkDown
MCD
Sketch
Equations Algorithm
Bill Of
Material
Hardware
CAD
Building
Instructions
CBD
Constants
AGV
Table
System
Design
System
Decomposition
Digitization
Component
Gathering
Robot
Assembly Callibration
Plant
Modelling
Controller
Modelling
CBD
Composition
System
Analysis
Deployment
and Simulation
Legend:
formalism
activity
hierarchy
automation
Figure 5: FTG of the full AGV system design.
4.3 Process Trace
Traceability, the ability to explore the provenance of artifacts, i.e., which artifacts were used in their con-
struction and through which activities, is crucial in SYE (Maro 2020). To support this, the FTG+PM is
extended with the ability to capture an execution of a process model, in the form of a Process Trace (PT).
A PT allows horizontal traceability (between MM, FTG, PM and PT) and vertical traceability (a slice
from a historical log of executed activities and (versions of) generated artifacts). Horizontal traceability or
typing/conformance is shown by using the same names and types in the MM, FTG, PM and PT. For di-
dactic purposes, this may be marked explicitly using grey, dotted arrows (not shown in this paper). Vertical
traceability appears when adding a PT to the FTG+PM. This PT contains all information about past exe-
cuted activities and (versions of) generated artifacts. A PT can be traced back to the PM it is an enactment
of. Furthermore, a PT model is append-only: added elements become immutable and as such provide an
archival record that can be analyzed/mined and will always give the same analysis results, even if the the
PM evolves (also in an append-only fashion). This satisfies our replicability/repeatability requirement. Part
of the PT for the AGV example is shown on the right in Figure 6.
The rountangles identify the start and end (events) of specific activities. Timestamps denote when these oc-
cur. Upon starting a new activity, artifacts are used and when finishing it, new ones are produced. These are
versioned artifacts (double bordered rectangle), and they are globally unique in the PT. When a workflow
iteration performs the same activity multiple times, each of these activities is marked with a unique times-
tamp and generates a new, versioned artifact (that provide traceability via ancestor links (yellow, striped
arrows in Figure 6)). In order to correctly reason about the full system process, all past artifact versions
must remain accessible and be immutable.
467
Authorized licensed use limited to: Universiteit Antwerpen. Downloaded on August 25,2022 at 08:05:45 UTC from IEEE Xplore. Restrictions apply.
Paredis, Exelmans and Vangheluwe
begin: system_design
port: cin1
end: system_design
port: cout
...
begin: plant_mdl
port: cin
end: plant_mdl
port: cout
plant_model :
CBD
ctrl_model :
CBD
plant_eqs :
Equations
ctrl_alg :
Algorithm
plant_mdl
: Plant Modelling
cin
cout
eqs
cbd
ctrl_mdl
: Controller Modelling
cin
cout
alg
cbd
requirements :
MarkDown
system_design
: System Design
cin1
cout
din
dout
cin2
...
system_design :
MCD
...
begin: ctrl_mdl
port: cin
end: ctrl_mdl
port: cout
...
begin: system_design
port: cin2
end: system_design
port: cout
...
begin: plant_mdl
port: cin
end: plant_mdl
port: cout
begin: ctrl_mdl
port: cin
end: ctrl_mdl
port: cout
...
requirements :
MarkDown
system_design :
MCD
plant_eqs :
Equations
requirements :
MarkDown
system_design :
MCD
plant_eqs :
Equations
requirements :
MarkDown
system_design :
MCD
plant_eqs :
Equations
ctrl_model :
CBD
plant_model :
CBD
ctrl_alg :
Algorithm
ctrl_model : CBD
plant_model :
CBD
requirements :
MarkDown
system_design :
MCD
plant_eqs :
Equations
ctrl_alg :
Algorithm
ctrl_model : CBD
plant_model :
CBD
system_design
plant_mdl
ctrl_mdl
system_design
plant_mdl
ctrl_mdl
Figure 6: Part of the AGV system design PM (left) and its corresponding PT (right).
The left of Figure 6 shows the PM for the system_design: System Design activity followed by the con-
current plant_mdl: Plant Modelling and ctrl_mdl: Controller Modelling activities, with their input and output
artifacts. It also contains the new version iteration (see also Figure 2 from which this is an excerpt). On
the right, the PT for these activities is shown. For readability, the relationship between start and end of
individual activities is denoted by vertical arrows. In the first iteration of the system design, the concurrent
activities are interleaved (begin followed by begin followed by end followed by end events), but, as can be
seen in a later iteration, they may also be sequential (begin followed by end followed by begin followed by
end events). This is a consequence of resource allocation and planning. All artifacts in the later iteration
have ancestors in the earlier iterations. This ancestry relationship is denoted by the horizontal dashed yellow
arrows pointing left.
4.4 Storage / Services / Real-World Artifacts
Another new extension to the FTG+PM framework is the ability to point to stored files for meta-models, ver-
sioned artifacts, service versions for executed activities, and physical locations for real-world artifacts (such
as a built robot). This will be referred to as (physical) Storage/Service/Real-World Artifacts (S/S /RWA).
Explicitly storing this information next to the PT allows a clear, permanent introspection of all required
components, such that the decisions made can be revisited and recalled later. These are also necessary in
order to fully support traceability, repeatability and replicability.
Figure 7 visualizes the PT and S/S/RWA. An orange cylinder denotes a concrete realized entity. The icon
inside specifies its kind (respectively: database/gears/cube icon for storage/service/real-world artifact). The
text inside the container specifies the object/service that is stored/provided at an external location. The
location is given along the arrow label.
Note that it actually does not matter how data is stored if one or more bi-directional adapters exist between
activity and artifact types in the PM on the one hand and service, storage and real-world artifact types in
the S/S/RWA on the other hand. For instance, a CBD model may be stored in a SIMULINK™ file. It
468
Authorized licensed use limited to: Universiteit Antwerpen. Downloaded on August 25,2022 at 08:05:45 UTC from IEEE Xplore. Restrictions apply.
Paredis, Exelmans and Vangheluwe
guess_v3: TXT
eqs_v3: LaTeX
plant_v3: MyCBD
digitalObject: Type
Figure 7: PT with storage annotation.
does not matter how it is stored, as an adapter will transform, when needed, from/to an artifact in the PT,
properly typed by a MM. An ODBA framework such as Ontop (Calvanese et al. 2015) hides the physical
structure of data sources such as federated (relational) databases and exposes (and adapts) the data using
an ontology (through SPARQL queries (World Wide Web Consortium 2013)). Figure 8 shows how adapter
contracts can be denoted. This way, it is also possible to have multiple adapters for a single versioned
artifact. The rountangles define the adapter specification (e.g., Table || CSV denotes that the adapter can
change CSV objects into instances of the Table meta-model as well as the other way around). The orange
cylinder notation is used to identify the kind of storage. This must match the actual storage annotation as
was given in Figure 7.
CSV
Excel
Table || CSV
Table || Excel
Table
SIMULINKTM
MyCBD
CBD || SIMULINKTM
CBD || MyCBD
CBD
Figure 8: Two adapter contracts for FTG types.
4.5 Properties of Interest
Qamar and Paredis (2012) define properties as “descriptors of an artifact”. They are attributes that con-
cern the artifact and are either described logically (e.g., the AGV’s wheels are nonholonomic) or numeri-
cally (e.g., the AGV uses 6 batteries). These properties may be computed (i.e., derived from other activi-
ties/artifacts) or specified (i.e., defined by a user). The properties of interest are specific system properties
that define the concerns of a specific stakeholder. In Figure 5, the sys_ana: System Analysis activity outputs
accuracy: Percentage, which is a computed property within the context of the AGV use-case. Based on this
value, the activity can decide whether to start the creation of a new version of the system, or to end the prod-
uct life-cycle. A final new extension to the FTG+PM framework is therefore the possibility to explicitly
describe properties of interest in a SYE workflow.
469
Authorized licensed use limited to: Universiteit Antwerpen. Downloaded on August 25,2022 at 08:05:45 UTC from IEEE Xplore. Restrictions apply.
Paredis, Exelmans and Vangheluwe
5 QUERYING
The previous sections set the stage for the main contribution of this paper. The use of a full
MM+FTG+PM+PT+S/S/RWA (or FTG+PM++ for short) enables querying over all the information con-
tained in it. Thanks to traceability between all the elements of the FTG+PM++, it is possible to find
complex, useful patterns, which can be navigated using queries. Six different kinds of traceability can be
identified, and are discussed below.
Traceability by linking experiments and system. Allows the identification of which experimentation
activities led to artifacts such as simulator output. Conversely, which artifacts were produced by a given
experiment. The complex workflows and architectures needed to fully describe experiments also need to be
modelled explicitly (Denil et al. 2017).
For instance, in order to select all activities that have a trace: Table as a result (and are therefore experiments
due to the contract/type of the experiment activity), the following query can be used: SELECT *FROM
ACTIVITIES AS ac WHERE trace:Table IN ac.results.
Traceability between instances and their (linguistic) types. Each (versioned) artifact has an explicit type
and therefore a precisely defined meta-model in the FTG+PM++. It is hence possible navigate a model,
based on its structure. For instance, agv_model is of type CBD, thus all Blocks in the CBD can be accessed.
From these Blocks, it is possible to access their ports, etc.
To obtain this metamodel, the following query might be used: SELECT m.metamodel FROM
ARTIFACT agv_model AS m.
Traceability across artifact versions, given context through a workflow model. For iterative workflows,
the PT keeps growing with each iteration. By explicitly ensuring all versions of each artifact are retained, it
is possible to navigate to past versions and ask questions about them. For instance, obtaining past controller
models of the AGV in order to identify the flaws/strengths of each controller version.
A past version of the ctrl_model might be obtained via querying SELECT m.versions FROM
ARTIFACT ctrl_model AS m.
Fine-grained traceability between artifact elements. Artifacts may have useful relationships between
them, which can only be identified at a low, artifact element, level. Keeping track of these relationships
ensures that the artifact element semantics can be meaningfully interpreted when asking questions. Figure 9
illustrates this through the relationship between an Excel column and the corresponding CBD signal from
which the column data was generated.
The logic in the figure can be written as SELECT *FROM ARTIFACTS AS art WHERE
art.metamodel CONFORMS TO trace:"time".
Traceability based on properties of interest. As discussed in section 4.5, certain properties may be com-
puted/derived from other properties in a SYE workflow. By making these relationships explicit, it is possible
to identify the origin/consequences of properties.
Assuming all rigid bodies used are marked as having the rigid property, they can be obtained using
SELECT *FROM ARTIFACTS AS art WHERE "rigid" IN art.properties.
Traceability between artifacts on different levels of detail. To evaluate a given property of interest,
multiple models may be used. Some may have less detail (possibly in a different formalism) than others,
but, when the property of interest is evaluated, the same result is obtained. If this is the case, the less
detailed model is called an abstraction of the more detailed one. Keeping track of properties of interest,
systems, and the different models that satisfy these properties, and under which conditions if useful for
model re-use. It also enables reasoning about accuracy/performance trade-offs.
470
Authorized licensed use limited to: Universiteit Antwerpen. Downloaded on August 25,2022 at 08:05:45 UTC from IEEE Xplore. Restrictions apply.
Paredis, Exelmans and Vangheluwe
CD + CL
DataPoint
+ time: timestamp
+ value: float
dataPoints
{ordered}
TimeSeries
Table
+ getCellValue(int, int): value
Block
+ name: string
*
Port
*
Inport
*
Outport
1..*
CBD
target source
Signal
timecol valuecol
TableColumn
1 1
*
contains
trace: Excel
https://msdl.uantwerpen.be/...
conforms to
trace : Table
conforms to
calib_model : CBD
begin: deploy_sim
port: cin
end: deploy_sim
port: cout
...
...
INV: context CBD inv UName: self.block->forAll(b1, b2 | b1 <> b2 implies b1.name <> b2.name)
context TimeSeries inv Sort: self.dataPoints = self.dataPoints->sortedBy(time)
Figure 9: Fine-grained traceability between an Excel file column and a CBD model signal.
6 CONCLUSION AND FUTURE WORK
This paper has shown how the FTG+PM can be used to aid Systems Engineering (SYE). We extended
the original framework with meta-models (MM), tracing information (PT) and Service/Storage/Real-World
Artifact (S/ S/RWA). By keeping track of all intermediate artifacts, including all past (historical) versions
thereof, the full process can be queried in order to extract useful information about the system. Furthermore,
the explicit nature of the FTG+PM++ automatically enables replicability of a system. The creation of the
full MM+FTG+PM+PT+S/S/RWA is therefore required in the context of SYE and its future, as outlined
in (INCOSE 2021). Note that the FTG+PM++ provides a framework in which architecture and view de-
/composition, as well as the collaboration between multiple stakeholders can be described. This explicit
description is future work.
We have built a prototype implementation of our framework using https://diagrams.net (formerly known as
https://draw.io) as a visual editing front-end and our Modelverse (Van Tendeloo and Vangheluwe 2017) as a
model management back-end. All images in this paper were produced using this prototype.
The FTG+PM++ can be used for a plethora of additional research, including (but not limited to) pro-
cess mining, safety analysis, system security, proof-of-validatity . . . Future work includes looking into these
methods and positioning the FTG+PM++ into these practices.
Some aspects such as activity resource (human or computer) allocation and planning (how activities will
be scheduled) are still missing from the FTG+PM++ framework. Furthermore, we plan to validate the
extension to the FTG framework presented in this paper by applying it to multiple use-cases. We expect
certain re-usable patterns to appear, possibly after automated process mining (van der Aalst 2016).
471
Authorized licensed use limited to: Universiteit Antwerpen. Downloaded on August 25,2022 at 08:05:45 UTC from IEEE Xplore. Restrictions apply.
Paredis, Exelmans and Vangheluwe
The FTG+PM++ formalism will be used to prescribe and trace all interactions with an evolving virtual
knowledge graph (currently, the ModelVerse), to eventually obtain a fully self-describing environment for
multi-paradigm modelling.
ACKNOWLEDGMENTS
This research was partially supported by Flanders Make, the strategic research center for the manufacturing
industry. The authors thank the anonymous reviewers for their constructive comments.
REFERENCES
Amrani, M., D. Blouin, R. Heinrich, A. Rensink, H. Vangheluwe, and A. Wortmann. 2021. “Multi-Paradigm
Modelling For Cyber–Physical Systems: A Descriptive Framework”. Software and Systems Model-
ing vol. 20 (3), pp. 611–639.
Bajaj, M., D. Zwemer, R. Yntema, A. Phung, A. Kumar, A. Dwivedi, and M. Waikar. 2016. “MBSE++
Foundations for Extended Model-Based Systems Engineering Across System Lifecycle”. In INCOSE
International Symposium, Volume 26, pp. 2429–2445. Edinburgh, UK, Wiley Online Library.
Brambilla, M., and P. Fraternali. 2014. Interaction Flow Modeling Language: Model-Driven UI Engineering
Of Web And Mobile Apps With IFML. Morgan Kaufmann.
Calvanese, D., B. Cogrel, E. Güzel Kalaycı, S. Komla-Ebri, R. Kontchakov, D. Lanti, M. Rezk, M. Muro,
and G. Xiao. 2015, 01. “OBDA With The Ontop Framework”. In Proceedings of the 23rd. Italian Sym-
posium on Database Systems. Gaeta, Italy.
Carreira, P., V. Amaral, and H. Vangheluwe. (Eds.) 2020. Foundations of Multi-Paradigm Modelling for
Cyber-Physical Systems. Springer International Publishing.
Denil, J., S. Klikovits, P. J. Mosterman, A. Vallecillo, and H. Vangheluwe. 2017, April. “The Experiment
Model and Validity Frame in M&S”. In Proceedings of the Symposium on Theory of Modeling and
Simulation (TMS/DEVS), TMS/DEVS ’17, part of the Spring Simulation Multi-Conference, pp. 1085
1096. Virginia Beach, VA, USA, SCS.
Dumas, M., and A. H. M. Ter Hofstede. 2001. “UML Activity Diagrams As A Workflow Specification
Language”. In International conference on the unified modeling language, pp. 76–90. Springer.
European Computer Manufacturers Association et al. 1966. “Standard ECMA-4: Flow Charts”. European
Computer Manufacturers Association.
Favre, J.-M., and T. Nguyen. 2005. “Towards A Megamodel To Model Software Evolution Through Trans-
formations”. Electronic Notes in Theoretical Computer Science vol. 127 (3), pp. 59–74.
Golra, F. R., A. Beugnard, F. Dagnat, S. Guerin, and C. Guychard. 2016. “Addressing Modularity For
Heterogeneous Multi-Model Systems Using Model Federation”. In Companion Proceedings of the 15th
International Conference on Modularity, pp. 206–211. Malaga, Spain.
Gomes, C., J. Denil, and H. Vangheluwe. 2020. Causal-Block Diagrams: A Family of Languages for Causal
Modelling of Cyber-Physical Systems, Chapter 4, pp. pp. 97–125. Springer International Publishing.
Grieves, M. 2006. “Product Lifecycle Management”. Nova Iorque, McGraw-Hill.
Guérin, S., G. Polet, C. Silva, J. Champeau, J.-C. Bach, S. Martínez, F. Dagnat, and A. Beugnard. 2021.
“PAMELA: An Annotation-Based Java Modeling Framework”. Science of Computer Programming vol.
210, pp. 102668.
472
Authorized licensed use limited to: Universiteit Antwerpen. Downloaded on August 25,2022 at 08:05:45 UTC from IEEE Xplore. Restrictions apply.
Paredis, Exelmans and Vangheluwe
Hassane, O., S. Mustafiz, F. Khendek, and M. Toeroe. 2019. “MAPLE-T: A Tool for Process Enactment
With Traceability Support”. In Proceedings of the 22nd International Conference on Model Driven
Engineering Languages and Systems (MODELS 19), pp. 759–763. Munich, Germany, IEEE.
Hebig, R., A. Seibel, and H. Giese. 2012. “On The Unification Of Megamodels”. Electronic Communica-
tions of the EASST vol. 42.
Hong, N. P. C. 2021. “Reproducibility Badging And Definitions: A Recommended Practice Of The National
Information Standards Organization”.
INCOSE 2021. “Systems Engineering Vision 2035”. Technical report, INCOSE.
Karaduman, B., S. Mustafiz, and M. Challenger. 2021. “FTG+PM For The Model-Driven Development Of
Wireless Sensor Network Based IoT Systems”. In 24th ACM/IEEE International Conference On Model-
Driven Engineering Languages And Systems Companion (MODELS-C 2021), pp. 308–318. Fukuoka,
Japan, IEEE; Assoc Comp Machinery; ACM SIGSOFT; IEEE Comp Soc; IEEE Tech Council Software
Engn.
Kassiakoff, A., W. N. Sweet, S. J. Seymour, and S. M. Biemer. 2010. Systems Engineering Principles And
Practice. second ed. John Wiley & Sons, Inc.
Kritzinger, W., M. Karner, G. Traar, J. Henjes, and W. Sihn. 2018. “Digital Twin in Manufacturing: A
Categorical Literature Review and Classification”. IFAC-PapersOnLine vol. 51 (11), pp. 1016–1022.
Ma, J., G. Wang, J. Lu, H. Vangheluwe, D. Kiritsis, and Y. Yan. 2022. “Systematic Literature Review Of
MBSE Tool-Chains”. Applied Sciences vol. 12 (7), pp. 3431/1 21.
Maro, S. 2020. Improving Software Traceability Tools And Processes. Ph. D. thesis, University of Gothen-
burg.
Meyers, B., and H. Vangheluwe. 2011. “A Framework For Evolution Of Modelling Languages”. Science of
Computer Programming vol. 76 (12), pp. 1223–1246.
Moody, D. 2009. “The "Physics" of Notations: Toward a Scientific Basis for Constructing Visual Notations
in Software Engineering”. IEEE transactions on software engineering vol. 35 (6), pp. 756 779.
Mosterman, P. J., and H. Vangheluwe. 2002. “Computer Automated Multi-Paradigm Modeling”. ACM
Transactions on Modeling and Computer Simulation (TOMACS) vol. 12 (4), pp. 1–7. Special Issue
Guest Editorial.
Mosterman, P. J., and H. Vangheluwe. 2004, September. “Computer Automated Multi-Paradigm Modeling:
An Introduction”. Simulation vol. 80 (9), pp. 433–450.
Mustafiz, S., J. Denil, L. Lúcio, and H. Vangheluwe. 2012. “The FTG+PM Framework For Multi-Paradigm
Modelling: An Automotive Case Study”. In Proceedings of the 6th International Workshop on Multi-
Paradigm Modeling, pp. 13–18. Munich, Germany, ACM.
Object Management Group 2017. “OMG® Unified Modeling Language® (OMG UML®) 2.5.1”.
OpenMBEE Organisation 2011. “OpenMBEE Homepage”. Online: https://www.openmbee.org/. Accessed:
28th of June 2022.
Paredis, R., C. Gomes, and H. Vangheluwe. 2021. “Towards A Family Of Digital Model/Shadow/Twin
Workflows And Architectures”. In Proceedings of the 2nd International Conference on Innovative Intel-
ligent Industrial Production and Logistics (IN4PL 2021), pp. 174–182. online, SCITEPRESS Science
and Technology Publications, Lda.
Paredis, R., and H. Vangheluwe. 2021. “Exploring A Digital Shadow Design Workflow By Means Of A Line
Following Robot Use-Case”. In Proceedings of the 2021 Annual Modeling and Simulation Conference
(ANNSIM). Fairfax, VA, USA.
473
Authorized licensed use limited to: Universiteit Antwerpen. Downloaded on August 25,2022 at 08:05:45 UTC from IEEE Xplore. Restrictions apply.
Paredis, Exelmans and Vangheluwe
Plesser, H. E. 2018. “Reproducibility Vs. Replicability: A Brief History Of A Confused Terminology”.
Frontiers in neuroinformatics vol. 11, pp. 76.
Qamar, A., and C. Paredis. 2012, 08. “Dependency Modeling And Model Management In Mechatronic
Design”. In Proceedings of the ASME Design Engineering Technical Conference, Volume 2. Chicago,
IL, USA.
Russell, N., W. M. Van Der Aalst, and A. H. M. Ter Hofstede. 2016. Workflow Patterns: The Definitive
Guide. MIT Press.
Salay, R., S. Kokaly, A. Di Sandro, and M. Chechik. 2015. “Enriching Megamodel Management With
Collection-Based Operators”. In 2015 ACM/IEEE 18th International Conference on Model Driven En-
gineering Languages and Systems (MODELS), pp. 236–245. Ottowa, Ontario, Canada, IEEE.
van der Aalst, W. 2016. Process Mining: Data Science In Action. Second ed. Springer.
Van Mierlo, S., Y. Van Tendeloo, I. Dávid, B. Meyers, A. Gebremichael, and H. Vangheluwe. 2018, April.
“A Multi-Paradigm Approach For Modelling Service Interactions In Model-Driven Engineering Pro-
cesses”. In Proceedings of the Spring Simulation Multiconference International Symposium on Model-
Driven Approaches for Simulation Engineering (Mod4Sim), edited by A. D’Ambrogio and U. Durak,
pp. 565–576. Alexandria, VA, USA.
Van Tendeloo, Y., and H. Vangheluwe. 2017, December. “The Modelverse: A Tool For Multi-Paradigm
Modelling And Simulation”. In Proceedings of the Winter Simulation Conference (WSC), WSC 2017,
pp. 944 955. Las Vegas, NV, USA, IEEE.
Wagner, D., S. Kim, A. Jimenez, M. Elaasar, N. Rouquette, and S. Jenkins. 2020. “CAESAR Model-Based
Approach To Harness Design”. In Proceedings of IEEE Aerospace Conference. Big Sky, MT, USA.
White, S. A. 2004. “Introduction To BPMN”. IBM Cooperation vol. 2.
World Wide Web Consortium 2013. “SPARQL 1.1 Overview”.
AUTHOR BIOGRAPHIES
RANDY PAREDIS is a PhD student in the Modelling, Simulation and Design Lab (MSDL) at the Uni-
versity of Antwerp. He explores a generic architecture and framework for model-based design of Digital
Twins. His email address is randy.paredis@uantwerpen.be.
JOERI EXELMANS is a Ph.D. student in the MSDL. His research interests are the engineering of hy-
brid languages, model versioning, and inconsistency management and traceability in complex engineering
workflows. His email address is joeri.exelmans@uantwerpen.be.
HANS VANGHELUWE is a Professor and head of the MSDL. He develops modelling and simulation
theory, methods, techniques and tools to increase system builders’ productivity. His email address is
hans.vangheluwe@uantwerpen.be.
474
Authorized licensed use limited to: Universiteit Antwerpen. Downloaded on August 25,2022 at 08:05:45 UTC from IEEE Xplore. Restrictions apply.
... Fig 1 shows the methodology to obtain the Multi-robot Warehouse. This is given as a Process Model (PM; a.k.a. a workflow model), following the extended Formalism Transformation Graph and Process Model (FTG+PM, [29], [30]) notation. The blue, bold arrows show the control flow between activities (rountangles). ...
... The robots are simple, nonholonomic differential-drive robots, as described in [32] and [30]. This implies there are two wheels driven by different motors, yet oriented on the same axis. ...
Chapter
Digital Models/Shadows/Twins/...have been given numerous definitions and descriptions in the literature. There is no consensus on terminology, nor a comprehensive description of workflows nor architectures. In this paper, we use the catch-all “Digital T” (pronounced “Digital Twinning”) to refer to all concepts, techniques, architectures, ...related to the “twinning” paradigm. In this paradigm, virtual instances, known as twins, of a System under Study (SuS) are continually updated with the SuS’s health, performance, and maintenance status, over its entire life-cycle. Digital T can be used for monitoring, analysis, optimization, and adaptation of complex engineered systems, in particular after these systems have been deployed. Digital T makes full use of both historical knowledge and of streaming data from sensors. Following Multi-Paradigm Modelling (MPM) principles, this paper proposes to explicitly model construction/use workflows as well as architectures and deployment of Digital T. Applying product family modelling allows for the de-/re-construction of the different Digital T variants in a principled, reproducible and partially automatable manner. Two small illustrative cases are discussed: a Line-Following Robot and an Incubator. These are representative for respectively an Automated Guided Vehicle and an Industrial Convection Oven, both important in an industrial context.KeywordsDigital modelDigital shadowDigital twinArchitectureWorkflowVariability modelling
Chapter
Co-simulation is an essential tool for the design of complex engineered systems. From early on in the life cycle of a system, models at different levels of abstraction and approximation are combined to make decisions about the system under design. Validity is typically described as creating a correct model to represent the actual system (under design) accurately. This is different to verification, which focuses on the proper implementation. In this paper, we relate different concepts of validity. We look at the techniques that the community produces to check the validity of the system. Afterwards, we look at the different threats to the validity of a (co-)simulation and look at some opportunities that arise when we explicitly reason on the validity of (co-)simulation models. Finally, we look at some tools that offer point solutions to some of the threats presented.
Article
Full-text available
Currently, the fundamental tenets of systems engineering are supported by a model-based approach to minimize risks and avoid design changes in late development stages. The models are used to formalize, analyze, design, optimize, and verify system development and artifacts, helping developers integrate engineering development across domains. Although model-based development is well established in specific domains, such as software, mechanical systems, and electrical systems, its role in integrated development from a system perspective is still a challenge for industry. The model-based systems engineering (MBSE) tool-chain is an emerging technique in the area of systems engineering and is expected to become a next-generation approach for supporting model integration across domains. This article presents a literature review to highlight the usage and state of the art to generally specify the current understanding of MBSE tool-chain concepts. Moreover, the results are used for identifying the usage, advantages, barriers, concerns, and trends of tool-chain development from an MBSE perspective.
Conference Paper
Full-text available
Digital Twins (DTs) (including Digital Shadows) are simulation models running in parallel with a real-world system while being fed the same input stimuli as that system. They can be used to analyze, optimize and adapt complicated engineered systems. This paper proposes a generic workflow to construct a Digital Shadow of a simple line-following robot using a Formalism Transformation Graph + Process Model (FTG+PM). Causal-Block Diagrams (CBD) were used to model both the physical dynamics and the control logic of the robot. The robot's logic is deployed using MicroPython, running on a LEGO Mindstorms EV3 kit. This study is to be used as a exemplar for future research on Digital Twin architectures and workflows.
Article
Full-text available
The complexity of cyber–physical systems ( CPSs ) is commonly addressed through complex workflows , involving models in a plethora of different formalisms , each with their own methods, techniques, and tools. Some workflow patterns , combined with particular types of formalisms and operations on models in these formalisms, are used successfully in engineering practice. To identify and reuse them, we refer to these combinations of workflow and formalism patterns as modelling paradigms . This paper proposes a unifying (Descriptive) Framework to describe these paradigms, as well as their combinations. This work is set in the context of Multi-Paradigm Modelling ( MPM), which is based on the principle to model every part and aspect of a system explicitly, at the most appropriate level(s) of abstraction, using the most appropriate modelling formalism(s) and workflows. The purpose of the Descriptive Framework presented in this paper is to serve as a basis to reason about these formalisms, workflows, and their combinations. One crucial part of the framework is the ability to capture the structural essence of a paradigm through the concept of a paradigmatic structure . This is illustrated informally by means of two example paradigms commonly used in CPS: Discrete Event Dynamic Systems and Synchronous Data Flow. The presented framework also identifies the need to establish whether a paradigm candidate follows, or qualifies as, a (given) paradigm. To illustrate the ability of the framework to support combining paradigms, the paper shows examples of both workflow and formalism combinations. The presented framework is intended as a basis for characterisation and classification of paradigms, as a starting point for a rigorous formalisation of the framework (allowing formal analyses), and as a foundation for MPM tool development.
Article
Full-text available
This article presents PAMELA, an annotation-based Java modeling framework. PAMELA provides a smooth integration between model and code and enables Java developers to handle software development both at conceptual level and at source-code level, without code transformation and/or generation, avoiding round-trip-related issues.
Book
Full-text available
This open access book coherently gathers well-founded information on the fundamentals of and formalisms for modelling cyber-physical systems (CPS). Highlighting the cross-disciplinary nature of CPS modelling, it also serves as a bridge for anyone entering CPS from related areas of computer science or engineering. Truly complex, engineered systems—known as cyber-physical systems—that integrate physical, software, and network aspects are now on the rise. However, there is no unifying theory nor systematic design methods, techniques or tools for these systems. Individual (mechanical, electrical, network or software) engineering disciplines only offer partial solutions. A technique known as Multi-Paradigm Modelling has recently emerged suggesting to model every part and aspect of a system explicitly, at the most appropriate level(s) of abstraction, using the most appropriate modelling formalism(s), and then weaving the results together to form a representation of the system. If properly applied, it enables, among other global aspects, performance analysis, exhaustive simulation, and verification. This book is the first systematic attempt to bring together these formalisms for anyone starting in the field of CPS who seeks solid modelling foundations and a comprehensive introduction to the distinct existing techniques that are multi-paradigmatic. Though chiefly intended for master and post-graduate level students in computer science and engineering, it can also be used as a reference text for practitioners.
Chapter
Full-text available
The description of a complex system in terms of constituent components and their interaction is one of the most natural and intuitive ways of decomposition. Causal Block Diagram (CBD) models combine subsystem blocks in a network of relationships between input signals and output signals. Popular modelling and simulation tools such as Matlab/Simulink® implement different variants from the family of Causal Block Diagram formalisms. This chapter gives an overview of modelling and simulation of systems with software and physical components using Causal Block Diagrams. It describes the syntax and - both declarative and operational - semantics of CBDs incrementally. Starting from simple algebraic models (no notion of time), we introduce, first a discrete notion of time (leading to discrete-time CBDs) and subsequently, a continuous notion of time (leading to continuous-time CBDs). Each new variant builds on the previous ones. Because of the heavy dependency of CBDs on numerical techniques, we give an intuitive introduction to this important field, pointing out main solutions as well as pitfalls.