=Paper=
{{Paper
|id=Vol-2019/commitmde_3
|storemode=property
|title=Modeling and Enactment Support for Early Detection of Inconsistencies in Engineering Processes
|pdfUrl=https://ceur-ws.org/Vol-2019/commitmde_3.pdf
|volume=Vol-2019
|authors=Istvan David,Bart Meyers,Ken Vanherpen,Yentl Van Tendeloo,Kristof Berx,Hans Vangheluwe
|dblpUrl=https://dblp.org/rec/conf/models/DavidMVTBV17
}}
==Modeling and Enactment Support for Early Detection of Inconsistencies in Engineering Processes==
https://ceur-ws.org/Vol-2019/commitmde_3.pdf
Modeling and Enactment Support
For Early Detection of Inconsistencies
In Engineering Processes
István Dávid∗† , Bart Meyers∗† , Ken Vanherpen∗† , Yentl Van Tendeloo∗ , Kristof Berx† , Hans Vangheluwe∗†‡
∗ University of Antwerp, Belgium
{istvan.david, bart.meyers, ken.vanherpen, yentl.vantendeloo, hans.vangheluwe}@uantwerp.be
† Flanders Make, Belgium
kristof.berx@flandersmake.be
‡ McGill University, Montréal, Canada
Abstract—Managing inconsistencies between models is a key the costs of resolving them are. Early detection of inconsisten-
challenge in engineering processes of complex systems. Early cies also provides more freedom in choosing the appropriate
detection of inconsistencies results in more efficient processes, resolution and tolerance techniques [3] [4].
because it can reduce the amount of re-execution of costly
engineering activities. To support the understanding of the origins and root causes
In this paper, we propose an approach for early inconsistency of inconsistencies, we reuse one of the main guidelines of
detection in engineering processes. In our approach, the engi- multi-paradigm modeling (MPM) [5] and we place the process
neering process is explicitly modeled, along with the important manipulating the models of the system into the center of our
characteristics and constraints of the system, imposed by the
work. Inconsistencies are defined, detected and analyzed with
requirements and system specifications. This information is then
used to enact the process and augment it with a run-time respect to the process.
consistency monitoring service. Inconsistencies are expressed as
a satisfiability problem of the constraints. Early detection of
inconsistencies is achieved by monitoring the constraints, that Inconsistencies
is, checking their satisfiability at specific points of the process.
Our approach is supported with a framework which includes a The presence of a process enables richer semantics to reason
visual process modeling tool, a process enactment engine and a
state-of-the-art symbolic solver for early inconsistency detection.
about the various types of inconsistencies. The traditional
interpretation of inconsistencies comes from the area of multi-
Index Terms—inconsistency management, process modeling, view modeling, where the notion of the process is not neces-
multi-paradigm modeling, cyber-physical systems, mechatronics sarily present, e.g. in [6]. In such settings, inconsistencies are
caused by multiple stakeholders modifying the system design
I. I NTRODUCTION in a parallel fashion and introducing discrepancies between the
views of the system, in specific attributes, values, properties.
Engineering complex heterogeneous systems requires a col- The strong notion of a process, however, allows to reason
laboration between stakeholders of various domains. These about more “stateful” types of inconsistencies, i.e. the ones
stakeholders have different views [1] on the system and that are caused by a sequence of modifications. Discrepancies
reason only about the system characteristics relevant to their are not necessarily introduced between various views, but
respective views. Some characteristics of the system, however, typically in constraints regarding the system, as the design
cannot be related to only one view or domain. Such cases decisions shape the system more and more specific.
result in overlaps between specific views and give rise to In our previous work [7], we proposed the foundations of
inconsistencies between those views. For example, selecting a formalism to reason about inconsistencies in the presence
a battery for an autonomous vehicle will have an impact to of a strongly typed process model, based on the F TG +P M
the mechanical view of the system (which reasons about the formalism [8]. The formalism enables modeling system char-
mass of the battery), and to the electrical view (which reasons acteristics as (ontological and linguistic) properties in conjunc-
about the capacity of the battery). tion with the engineering process. The process is analyzed and
As proposed by Finkelstein et al [2], instead of simply just various management patterns are applied to prevent potential
removing inconsistencies from the design, we need to think inconsistencies to occur. That is, the process is transformed
about “managing consistency”. One of the core activities of in a way that no inconsistency remain unnoticed when the
inconsistency management is the detection of inconsistencies. process is enacted. (Referred as Specification-time inconsis-
It is preferred that detection is achieved as early as possible, tency management in Figure 1.) In these cases, one typically
because the earlier the inconsistencies are detected, the lower addresses inconsistencies due to the parallel activities.
Figure 1: The main focus areas of our research, with the scope of the current paper (Run-time inconsistency management)
highlighted. For this, we revise the previously addressed formalism for Process modeling. Specification-time inconsistency
management is covered in [7]. Inconsistency resolution is a future work.
Scope of the paper supports (i) specification of the above mentioned aspects of the
In this paper, we focus on early detection of inconsistencies engineering process, and (ii) execution of the modeled process
during the enactment phase of the engineering processes, i.e. in a managed way, i.e. by monitoring the (in)consistency of
at run-time (Figure 1). Such scenarios necessitate more precise the modeling artifacts.
modeling of the properties of the system with respect to the The rest of the document is structured as follows. In
engineering process. To this end, we revise our original process Section II, we present a motivating example of the engineering
modeling formalism and introduce the notion of attributes of a complex heterogeneous system. Using the example,
(in models) and capabilities (in formalisms) in the F TG +P M. we propose a modeling formalism in Section III to capture
Additionally, we provide a state-of-the-art symbolic solver for various system characteristics and constraints, which serve
detecting inconsistencies in actual, real modeling artifacts. as (in)consistency rules for the process. In Section IV, we
The contributions are presented through an industry level present the enactment aspects of the previously specified
example of a complex mechatronic system, an automated process, including (i) the execution of the process additionally
guided vehicle (AGV), coming from one of our partners. supported with tool interoperability, and (ii) the monitoring
The core contribution of this paper is a methodology for and detection of inconsistencies. Finally, we conclude our
explicit modeling of the characteristic attributes of the system work by giving an overview on the state of the art in Section V
and allow defining constraints upon them to express inconsis- and by wrapping up the paper in Section VI.
tency rules in order to monitor the process for inconsistencies II. M OTIVATING EXAMPLE
at runtime. The process is augmented with consistency checks
during the enactment, which can be viewed as special activities To motivate our work, we use a case study of the design
of the process. These activities are not explicitly modeled and of an AGV. The goal of the AGV is to carry out a mission
do not carry relevant information from the engineering point of transporting a payload on a specific trajectory between
of view and therefore, they remain hidden. two locations. Being a complex mechatronic system, the
The explicit modeling of attributes and constraints means requirements of the AGV are refined into specifications by
that the information relevant to inconsistency management is stakeholders of the different involved domains, such as (i)
being conceptually “lifted” from the models containing those mechanical specifications: sufficient room on the vehicle to
attributes and constraints. (Although, they are still present in place payload; (ii) control specifications: following the defined
the models themselves.) This modeling step may be expensive trajectory with a given maximal tracking error; (iii) electrical
for larger processes, but it has to be done only once for a specifications: autonomous behavior, defined as the number of
process. Attributes and constraints operate on multiple meta- times that it needs to be able to perform the movement before
levels, which enables reasoning about capabilities of certain needing to recharge; (iv) product quality specifications: the
modeling formalisms. This, due to the strongly typed pro- previous specifications should be achieved at a minimal cost.
cess model, provides additional vital information regarding The design process needs to determine the sizing of the
potential inconsistencies along the process. This combination different components (motors, battery, platform) and tune
of modeling paradigms (i.e. multi-level, multi-abstraction, the controller. The process requires a collaboration between
process-oriented) is novel in the state-of-the-art. different stakeholders and their domain-specific engineering
To support our ideas, we provide a prototype tool1 , which tools, such as CAD tools for platform design, Simulink and
Virtual.Lab Motion for multi-body simulations, AMESim for
1 Available from: http://istvandavid.com/icm. multi-physical simulations during drivetrain design. The motor
and battery selection activities use databases maintained in Since Equation 3 holds for any mass, and consequently for
Excel files. Since these tools work with different modeling mB as well, it can be inferred that after selecting a battery
formalisms, reasoning over the consistency of the system as a (and thus filling in mB in this equation), the total mass will be
whole properties poses a complex problem. By explicitly mod- greater than 150, thus violating the constraint in Equation 2.
eling attributes and constraints of the system and associating Such an early detection of inconsistencies may save sig-
them with the engineering activities, the engineering process nificant costs in the specific engineering process, because it
can be augmented with automated consistency monitoring. reduces the amount of iterations over complex engineering
activities if the design is detected to be inconsistent. Early
Running example
detection of inconsistencies requires (i) reasoning over con-
The total mass of the AGV (mT ) is a sum of the mass of straints on different meta-levels; and (ii) efficient constraint
the battery (mB ), the mass of the motor (mM ) and the mass solving algorithms. In Section III, we provide a formalism for
of the platform (mP ): the former requirement, and in Section IV we discuss the latter
mT = mP + mM + mB . (1) requirement.
During the engineering process, and specifically: during the III. M ODELING SYSTEM CHARACTERISTICS
requirements analysis, constraints are applied on the attributes: In this section, we present a formalism (i.e. a language
with semantics) to model the engineering process and its
mT ≤ 150 [kg],
consistency constraints discussed in Section II. The formalism
mP ≤ 100 [kg], builds on the F TG +P M formalism [8], and its foundations have
(2)
mM ≤ 50 [kg], been presented in our previous work [7].
mB ≤ 10 [kg]. A. F TG +P M: A brief overview
These constraints must be respected throughout the whole pro- The F TG +P M formalism enables the usage of process mod-
cess, otherwise the model of the system becomes inconsistent. els (P M) in conjunction with the model of formalisms and the
Additionally, all the masses must be positive numbers, as transformations between those (the formalism-transformation
constrained by the laws of physics. graph - F TG). As shown in Figure 2, Formalisms and Trans-
formations serve as a type system to the Objects (models) and
mass > 0 [kg]. (3)
the Activities of the process, respectively.
Obviously, the notion of masses specific to the system, i.e. mT , The strong type system of the formalism fits well with the
mB , mM and mP , are of a different nature than the general problem sketched in Section II as it supports reasoning on
mass concept, as mass is not related to a specific part of the different meta-levels. To enable modeling the problem at hand,
system, but is more abstract. The concept of mass, in fact, we introduce new elements to the formalism. In the following,
can be viewed as type to the system-specific masses: mT , we elaborate on these new elements in greater details.
mB , mM and mP are all masses and therefore, a constraint As shown in Figure 2, the original F TG +P M metamodel is
on mass imposes a constraint on each system-specific mass. extended by a third typing relationship: between Capabilities
This means the constraint in Equation 3 must hold for each and Attributes. Furthermore, Constraints can be defined for
system-specific mass. both of these elements to capture consistent states of the mod-
els in the process. These added elements are the foundations to
Inconsistencies. An inconsistency can occur, for example, in the inconsistency monitoring approach we are about to present.
the following scenario. B. Attributes and capabilities
Step 1: A platform is selected with a mass of 100 kg. Attributes represent characteristic values of the system.
(mP = 100 [kg]) These values can be persisted in an object (of a model) and
Step 2: A motor is selected with a mass of 50 kg. (mM = queried directly; or can be derived by a complex query.
50 [kg])
Step 3: A battery is selected with a mass of 10 kg. (mB =
10 [kg]) Definition 1 (Attribute): An attribute is defined as a result of
a query over a model, which query is composed of (potentially
At this point, an inconsistency can be detected. Even though
multiple instances of) projection and aggregation operations.
the selected components satisfy their respective constraints
imposed in Equation 2, the total mass now becomes 160
kgs (due to Equation 1), which leads to a violation of a In the example in Section II, the mass of the platform (mP ),
constraint in Equation 2 and therefore: the design is considered the mass of the battery (mB ) and the mass of the motor (mM ),
inconsistent. are attributes that are directly persisted in a mechanical model,
Factoring in Equation 3, however, allows an earlier detection thus are directly queried from the mechanical model (each
of inconsistencies. Already in Step 2, Equation 1 can be by a respective projection); while the total mass (mT ) is an
rewritten as follows: aggregation of the previous three masses and is not necessarily
mT = 150 + mB . persisted in the model. (We assume the time required for
Figure 2: Excerpt from the extended F TG +P M metamodel used in our work.
executing the query being negligible compared to the length of Definition 4 (Consistent design): The design of the system
a real life engineering process.) After obtaining mB , mM and is considered to be consistent at a given point of the process
mP , mT is obtained as the sum aggregation of the former iff there are no violated constraints.
three attributes, as shown in Equation 1. Consequently, as
shown in Figure 2, attributes are situated on the P M side of The detection of the violated constraints is discussed in
the F TG +P M, i.e. on the instance level. Section IV.
As discussed in Section II, the concept of mass is differ-
ent from the concept of the masses specific to the system: D. Modeling the example
mT , mB , mM and mP are related to the notion of mass by After defining the core concepts, we use our prototype tool
a typing relationship. In our framework, we call these meta- to model the attributes, capabilities and constraints of the
attributes capabilities. engineering process. The tool provides a visual interface for
modeling. It was built on top of the Eclipse platform, imple-
Definition 2 (Capability): A capability of a formalism ex- mented using the Sirius framework [10], and it is available as
presses the ability of a model, corresponding to the formalism, an open-source software.
to reason about attributes a set of system characteristics. Attributes and their constraints
Figure 3 shows an excerpt from the full model of the
In the running example, Matlab is used for defining the (sim- example, with the attributes of the running example and their
plified) mechanical model of the AGV. The Matlab language, constraints modeled.
in this sense, is able to reason about masses. (Although, mass- Attributes are denoted by light red rectangles, and con-
like attributes are just ordinary data structures from Matlab’s straints by darker red rectangles. There are four attributes in
point of view.) the figure, one for each of the masses in Section II. Apart
from the totalMass, the three other masses are persisted in the
C. Constraints mechanicalModel, as shown by the prefix in the names of the
To make use of attributes and capabilities for consistency attributes. The total mass is not persisted in the mechanical
management purposes, constraints are imposed on these to model, but it is a result of an aggregation of the other three
define consistent states of the engineering process. masses (Equation 1). This equation is captured in the rightmost
constraint, as shown by the formula. The other four constraints
correspond to the four sub-equations of Equation 2.
Definition 3 (Constraint): A constraint defines the desired The header of the constraint contains its level of precision.
characteristics of the system, i.e. it is a selection of an interval In this example, all of the constraints are of level L3. As
over the domain of the previously obtained attribute. defined in our previous work [13], the level of precision
reflects what information a constraints carries:
In a typical engineering process, algebraic (Equation 1), arith- • L1: the fact of influence is known, its extent is not;
metical (Equations 2 and 3) and logical formulas are used as • L2: sensitivity information between two values is ex-
constraints. As shown in Figure 2, constraints can be applied pressed, e.g. by Forrester system dynamics [14];
on both the P M and the F TG side. • L3: the constraint can be expressed using an exact
mathematical relationship.
This means, that based on the typing relationship between the
mass capability and the system-specific masses mT , mP , mB ,
mM , Equation 2 can be unfolded as follows:
0 [kg] < mT ≤ 150 [kg],
0 [kg] < mP ≤ 100 [kg],
(4)
0 [kg] < mM ≤ 50 [kg],
0 [kg] < mB ≤ 10 [kg].
E. Properties
As presented in [15] and [16], ontologies can be efficient
enablers for inconsistency management in heterogeneous set-
tings. During the translation of requirements to view-specific
properties, each stakeholder keeps in mind certain domain
properties, i.e. ontological properties. For example, an electri-
cal engineer implicitly thinks about the capacity of the battery,
a mechanical engineer reasons about how a battery would fit
Figure 3: Attributes and constraints. the frame of the AGV. Due to overlap in requirements, some
ontological properties will be shared and/or will influence each
other such that the related view-specific properties will be
shared or influenced as well. Our framework allows defining
In this work, we assume L3 relationships, but our technique property satisfaction relationships in terms of attributes. The
can adapted to deal with lower levels of precision as well. satisfaction of a property can be inferred by checking the
single constraints imposed on the specific attributes.
Capabilities and their constraints
Figure 4 shows an excerpt from the full model of the
example, with the mass capability, its constraint, alongside
the related part of the F TG. Matlab is used as a formalism
for defining the mechanical model of the system and has a
capability of expressing mass. (That is, models being conform
to the Matlab formalism, can have attributes of type mass.)
Figure 4 shows how this aspect of the running example is
modeled, with Equation 3 captured in a similar fashion as the
other constraints were in Figure 3.
Figure 6: Excerpt from the example: the property validMass.
Figure 6 shows the property validMass. The satisfaction of
the property is evaluated from the totalMass attribute, using
the same constraint as the one shown in Figure 3 (i.e. the
constraint on attribute mT in Equation 4), while the bottom
right element, labeled with the name of the property, holds the
boolean value of the satisfaction relationship.
Figure 4: A capability and its constraint in the F TG. This notion of properties allows various scenarios aiding
inconsistency management, such as reusing domain knowl-
edge from existing domain ontologies [17], using ontological
The evaluation of such constraints, however, differs from reasoning [15] in conjunction with our techniques, and using
the ones shown in Figure 3, as the constraints on mass are contract-based design [18] [19] to aim co-design scenarios, i.e.
stemming from the universal laws of physics, while mT , mP , parallel branches of the engineering process.
mB , mM are specific to the system. To evaluate constraints
of capabilities, we use the following rule. F. Putting it all together: the process
Figure 5 shows the final model of the running example.
Definition 5 (Evaluation of capability constraints): Any In the middle, the yellow rectangles denote the activities of
constraint applied on a capability imposes a constraint on every the P M with control flows in between them denoting the
attribute typed by that capability. precedence relationship between the activities. On the right
Figure 5: The F TG +P M based process model with the capabilities (left) and the attributes (right).
side, the attributes and constraints are shown. Activities and background by our tool via the Matlab API, without requiring
attributes are linked by intents, which express the purpose of the user to submit any extra information for this.
the activity accessing a given attribute. The first three activities
access attributes in order to modify them, while the last activity IV. M ANAGING INCONSISTENCIES
attempts to resolve a constraint wrt totalMass. Other types of In this section, we briefly present how the enactment of
intents include: reading the value of an attribute, imposing a the previously modeled process (Section III) is carried out
constraint, locking/releasing an attribute in a parallel process while enforcing a consistent state across the models. Our
branch, etc. This latter step is built into the process as an custom process enactment engine with fully modeled execu-
actual engineering step, but as shown in Section IV, in case tion semantics is presented, as well the algorithm used for
of an inconsistency, the consistency monitoring service can detecting inconsistencies during the enactment of the process.
stop the process before this point. In our previous work [7] To facilitate the interplay in real engineering settings, we
we used read-modify pairs of intents to identify potential in- provide integration with multiple tools and frameworks, which
consistencies at the optimization phase. In this work, however, will be discussed briefly as well.
we leverage the notion of intents at run-time to narrow the
scope of the consistency checking algorithm, i.e. to consider A. Architecture
only the attributes which have been explicitly linked with an
activity using a modify intent. Figure 7 shows the architecture of the process enactment
On the left side, the F TG and the only associated capability engine. The engine is initialized by the Process model, defined
is shown. The typing relationships correspond to Figure 2: previously in Section III. An explicit Enactment model aug-
ments the Process model with the notion of tokens and activity
• the mechanical model in the P M is an Object and it is states (Figure 8), to be able to define the execution semantics.
typed by the Formalism Matlab in the F TG; Execution semantics are defined by explicitly modeled Trans-
• the Activities are typed by the transformation assign-
formation rules.
Mass;
• finally, the mass capability types all the masses on the
right side, but this relationship is not visualized in the
graphical view. (It is shown in a property view of the
tool, however.)
Masses are assigned to the design when the respective activi-
ties are executed. Conceptually, this assignment can be viewed
as a transformation of the model, and as such, the actual
transformation logic is captured in the transformation typing
the activities. In this case, assignMass holds the specification
of the transformation. The activities operate on models. To
check the consistency of the attributes, the attribute values Figure 7: Architectural overview of the enactment engine.
are obtained by querying the appropriate models, i.e. the ones
the specific attributes are persisted in. As Figure 5 shows,
the name of the attribute is prefixed with the name of the The architecture has been implemented on top of the Eclipse
model persisting the attribute. The first three attributes are all platform. The Eclipse Modeling Framework (EMF) [9] is used
persisted in the mechanicalModel, which is a Matlab type of a for modeling purposes, while the model transformations have
model. Using this information, the querying is executed in the been realized using the VIATRA framework [11].
Activities of the process, especially the automated ones, • When the actual work in the Activity is finished, the
often execute simulations and calculations over models on Activity becomes Done and the process can move on.
external storages by using external tools. For that, interop-
erability with a representative set of services is provided Transformation rules of the execution semantics
(External service integration). Our framework currently pro-
vides scripting support for Matlab/Simulink, and Amesim of Definition 6 (Marking of the process): By marking M of the
Siemens/LMS through its native API. Executable pieces of process we mean the function M : N → Z, where N denotes
Java code or Python scripts are supported and executed during the set of the Nodes of the process with an integer number
the appropriate phases of the enactment. Z of Tokens in it. A process is considered to be unmarked if
A vital contribution of the stack is the Consistency manager, there are no tokens present in it.
which features a symbolic solver for detecting inconsistencies.
For this purpose, the SymPy [12] framework for symbolic Initialization is a transformation which takes an unmarked
mathematics is used. In Section IV-C, the algorithm of the process and transforms it into a process with an initial mark-
solver is discussed in greater detail. ing, i.e. with one token in its initial node.
Finishing is a transformation which takes a process with a
B. Execution semantics
final marking (i.e. every token in the final node) and transforms
The execution semantics of the F TG +P M have been dis- it into an unmarked process.
cussed previously in [20]. Here, we give a brief overview and Fork is a transformation which takes exactly one token and
focus on the main specificities in our current framework. produces a token for each parallel branch starting from that
Since the core of enactment engine is fully modeled, the fork node. The input token is marked abstract (see Figure 8)
execution semantics are given by reactive live model trans- and kept (hidden) in the model, while the newly created tokens
formations. Figure 8 shows the metamodel of the enactment are defined as subtokens of the input token, so that they can
engine. A ProcessModel (i.e. a full F TG +P M) is given to the be identified once they have to be joined at the end of the
compiler which creates an instance of the elements shown parallel branches.
in green. During the enactment, a set of Tokens define the Join is a transformation which takes a token from each of its
marking of the process, i.e. the active Nodes at a given incoming parallel branches and joins those tokens. In a valid
moment. process model, the tokens to be joined must be the subtokens
of the same (now abstract) parent token. The join is achieved
by locating the parent token, placing it into the join node,
marking it as not abstract, and removing the subtokens.
Step is a transformation which moves a token from a node
to a consecutive node, while respecting the previous rules of
forking and joining.
C. Algorithm for early inconsistency detection
Early detection of inconsistencies requires computing the
satisfiability of the system of constraints at certain points of
the process. These computations are carried out on each Step
in the process, based on Algorithm 1.
Figure 8: Metamodel for the enactment (green) along with the
characteristic parts of the process metamodel.
Algorithm 1 Handling attribute modifications.
1: procedure S TEP(token, nextActivity)
2: token.currentActivity ← nextActivity . Move the token to the next
A Token also equips Activities of the process with additional activity
semantics regarding the state of their execution, modeled 3: for all i:Intent, a:Attribute: i(token.currentActivity, modify, a, v) do
4: U PDATE ATTRIBUTE VALUE(a, v) . Assign value v to attribute a
by ActivityState. This is required because the execution of 5: end for
Activities is not instantaneous. 6: end procedure
• When a Token is moved to a new Activity, the Activity
becomes Ready. The stakeholders and tools required to On each Step in the process, the token is moved to the next
execute the Activity can be notified, the required models activity (Line 2). As discussed in Section III-F, intents between
can be loaded into the tools. activities and attributes help identifying the cases when an
• When the actual work in the Activity begins, the Activity activity modifies the value of a property. For each of such
becomes Running. This state can last for longer periods, intents (Lines 3-5), the attribute is updated and the change
especially in resource-intensive simulations or manual is propagated through the whole system of constraints. This
modeling activities, which may take days or weeks. latter step is being taken care of by Algorithm 2.
Symbolic computation of constraints Execution of the example
We follow the process in Figure 5. During the execution,
The updates to the system of constraints require introducing
Equations 1 and 2 are maintained: whenever a value is
the new values of attributes and computing whether the con-
assigned to an attribute present in one of the equations, the
straints can be still satisfied later on in the process or not. Such
equations are simplified with that attribute. This means
a computation requires factoring in the potential impacts of the
• substituting the newly assigned value of the attribute to
future attribute changes (explicitly modeled in the process). To
execute these computations, we opted for the techniques of every occurrence of the attribute in every equation; and
• removing constraints without free attributes.
symbolic computation. Our main concern is the maintenance
of a system of constraints by gradually simplifying them Step 1: The platform mass is set to 100 kgs. Activity
as attributes get updated, to the point, where contradictions DesignPlatform is executed and the mass of the
appear in the equations, i.e. the set of potential solutions is platform is set in the mechanical model. Since the
empty, thus denoting an inconsistency in the system design. attribute is persisted in a Matlab model, the model
Alternative approaches include simulation of the process and is queried via the Matlab API for the value of the
abstract interpretation. platformMass variable. The consistency manager
Algorithm 2 shows the steps taken in our symbolic com- uses this information to update the constraints with.
putation approach. The algorithm is invoked by Algorithm 1 The related constraint of Equation 2 (0 [kg] <
with the name and the new value of the attribute to be updated mP ≤ 100 [kg]) is satisfied, and therefore the
passed along as parameters. In Phase 1 of the algorithm, system can be simplified with it:
the attribute-value assignment is translated to an equality mT = 100 + mM + mB [kg]
constraint and added to the system of constraints (Line 2). In
Phase 2, the algorithm propagates this change and attempts to
simplify every constraint. This is achieved by iterating through 0 [kg] < mT ≤ 150 [kg]
the system of constraints (Lines 3-4) and factoring equation 0 [kg] < mM ≤ 50 [kg]
constraints (Line 5-6) into the rest of the constraints by trying 0 [kg] < mB ≤ 10 [kg]
to solve (simplify) the constraint (Line 7).
We use the SymPy [12] symbolic mathematics library to Solving the constraints for mT results in a non-
solve/simplify the constraints, thus the semantics is provided empty set of solutions:
by the library. Constraints imposed by capabilities are calcu- 100 [kg] < mT ≤ 150 [kg]
lated based on Definition 5 and applied on attributes.
Finally, in case an empty set is produced as a set of potential No inconsistency is detected, the process proceeds.
solutions for a constraint, we interpret it as an inconsistency Step 2: The motor mass is set to 50 kgs. The SelectMotor
and notify the user about this fact. activity is executed which sets the mass of the
motor to 50 kgs.
Algorithm 2 Maintenance of the system of constraints. mT = 150 + mB [kg]
1: procedure U PDATE ATTRIBUTE VALUE(attribute, value)
Phase 1 – Impose a new constraint with equality
2: model.constraints ← Eq(attribute, value)
0 [kg] < mT ≤ 150 [kg]
Phase 2 – Propagation and simplification: substitute equality constraints into the 0 [kg] < mB ≤ 10 [kg]
rest of the constraints
3: for all constraint1 in model.constraints do At this point, Algorithm 2 detects the inconsistency
4: for all constraint2 in model.constraints do sketched in Section II. Solving the constraints for
5: if constraint2 is Eq then
6: constraint1 ← constraint2 mT results in an empty set of solutions:
7: solution = solve(constraint1) . Try to solve the constraint
8: if solution = ∅ then
9: notify inconsistency
10: end if
150 [kg] < mT ≤ 150 [kg]
11: end if
12: end for Since 0 < mB , it can be inferred, that after exe-
13: end for cuting the next activity of the process, mT > 150
14: end procedure
will hold, which violates the constraint on the total
mass. The process is halted and a notification is
When an inconsistency is detected, the process is halted and raised to the user to resolve the inconsistency.
cannot proceed until the inconsistency is not fixed. Resolving
inconsistencies is outside the scope of the paper. A simple V. R ELATED WORK
undo/redo functionality is provided by the framework, but Model inconsistency is one of the main challenges in
more detailed research have been carried out by other authors, any engineering setting where more than one stakeholder is
briefly discussed in Section V. present. Di Ruscio et al [21] identify the research directions,
challenges, and opportunities of collaborative MDSE and con- The efforts put into analyzing and optimizing a process model
clude, that inconsistency management is one of the main en- can be easily demolished by deviating from (and sometimes
ablers of efficient collaboration. This challenge is exacerbated even completely abandoning) the specification of the process.
in scenarios of engineering systems of a heterogeneous nature, Egyed et al [30] investigate the impact of single inconsistency
i.e. when the stakeholders come from different domains, work instances to the whole system by introducing the notion of
with different views on the system with their domain-specific change impact based scopes. Scopes are used to carry out
formalisms and tools. resolution steps on the required regions of the models and
Multiple authors point out, managing inconsistencies should thus enhancing the efficiency of the inconsistency management
be carried out with processes in mind as well. Persson et framework. Our formalism also supports the implementation
al [22] argue that consistency between the various views of of such scoping mechanisms, with the added potential of
cyber-physical system design as one of the main challenges enriching the definitions of scopes with semantic information.
in design of such complex systems. This is due to relations To implement our solver, we opted for the Python-based
between views, with respect to their semantic relations, process library SymPy. We briefly considered and researched two other
and operations which often overlap. Multi-paradigm modeling libraries as well. SymJava2 is a Java-porting of SymPy, but
[5] advocates using the most appropriate formalisms, on the with a limited set of capabilities, which would have prevented
most appropriate level of abstraction, while also factoring us from implementing the second algorithm shown in Sec-
in the processes manipulating the models. The framework tion IV-C. exp4j3 is a library for evaluating expressions and
presented in this paper, aims at the problem of inconsistencies functions in the real domain. Its main limitation is the inability
with the processes in the focus. of solving partial equations and inferring the (in)consistency
In our work, we opted for the F TG +P M formalism based on that.
for modeling processes. As compared to the widely used
BPMN2.0 [23] or BPEL [24] based process modeling frame- VI. C ONCLUSIONS
works (e.g. jBPM [25]), our formalism allows modeling details In this paper, we presented an approach for early detection
more relevant to engineering scenarios in MDE settings. Mod- of inconsistencies in complex engineering processes. The
els and transformations are first-class citizens in the F TG +P M, approach fits into a bigger inconsistency management frame-
which enables deeper understanding of inconsistencies and work, partially presented in our previous works [7][4][15].
more control over the enacted process. The approach relies on modeling the characteristics of the
Our methodology advocates making crucial attributes and system being developed, and using this information during
constraints of the system explicitly modeled. Qamar et al [26] the engineering phase to detect inconsistencies across the
use a similar approach for inconsistency management by various engineering models of the system. The approach is
making model dependencies explicit. As opposed to our ap- process-oriented in a sense that attributes and capabilities of
proach, the authors do not go as far as providing constraints the system’s models are modeled in conjunction with the
for inconsistency management purposes, but use dependency actual engineering process, which then gets enacted. The
links to notify stakeholders about possible inconsistencies enacted process is augmented with smart consistency checking
when dependent properties/attributes change. It is a task of algorithms, enforcing the consistent state of the design.
a stakeholder to verify the consistency of the models. In our As presented, factoring ontological knowledge into the
approach, this is carried out in an automated way. requirements of the system may shed light to additional
In the current paper, we do not focus on resolving incon- constraints viable for early detection of potential inconsistent
sistencies of the models, but we provide undo/redo actions states of the system design. The main advantage of our ap-
to revert to the latest consistent state. Eramo et al [27] proach is the support for such scenarios by uniformly handling
present an approach where each of the consistent alternatives instance- and meta-level constraints. As highlighted in the
are maintained throughout the process and pruned when a example, the advantages of such an early detection approach
decision is made and an alternative becomes infeasible. Such are visible already in very simplistic cases as the one above.
an approach can be viewed as a natural extension of our work, The gain realized in real engineering processes can obviously
especially of the solver presented in Section IV-C. Mens et be much higher, when the execution of resource and cost
al [28] propose expressing the steps of inconsistency detection demanding activities can be prevented by the early detection
and resolution as graph transformation rules. Critical pair of inconsistencies.
analysis is used to analyse potential dependencies between the The proposed the modeling formalism enables lifting infor-
detection and resolution of inconsistencies. The approach is mation relevant to inconsistency management purposes regard-
efficiently handles cyclic inconsistencies, which is paramount ing the given process. Explicit modeling of such information
in real system engineering scenarios and complements our is an enabler of improving the quality and efficiency of
work presented here. Almeida da Silva et al [29] investigate the the process once enacted. Although the thorough modeling
possibilities of managing deviations of enacted processes from requires significant efforts from the stakeholders, it is needed
their respective specifications. It is not the scope of our work,
but indeed, deviations from the specified process are big threat 2 https://github.com/yuemingl/SymJava
to the validity of any process-oriented engineering approach. 3 http://www.objecthunter.net/exp4j/
to be done only once, before the actual design of the system [8] L. Lúcio, S. Mustafiz, J. Denil, H. Vangheluwe, and M. Jukss,
commences. Such a front-loaded approach can be typically “FTG+PM: An Integrated Framework for Investigating Model Transfor-
mation Chains,” in SDL 2013: Model-Driven Dependability Engineering,
expected from companies on CMMI levels 3 and above [31]. vol. 7916 of LNCS, pp. 182–202, Springer, 2013.
As a consequence, our approach suits best the domain of [9] Eclipse Foundation, “Eclipse Modeling Framework (EMF) Website.”
complex heterogeneous systems, where the costs of dealing https://eclipse.org/modeling/emf/. Acc: 2017-08-17.
[10] Eclipse Foundation, “Sirius Website.” https://eclipse.org/sirius/. Acc:
with inconsistencies is often in a different order of magnitude 2017-07-07.
than the costs of modeling and optimizing the process. [11] G. Bergmann, I. Dávid, Á. Hegedüs, Á. Horváth, I. Ráth, Z. Ujhelyi, and
A limitation of the framework may be its scalability, both D. Varró, “VIATRA 3: A Reactive Model Transformation Platform,” in
Theory and Practice of Model Transformations, pp. 101–110, Springer,
from the user experience point of view (i.e. how efficient is 2015.
it to model larger processes), and from the tooling point of [12] SymPy Development Team, “SymPy Website.” http://www.sympy.org/.
view (i.e. how efficient is it to execute the optimization and Acc: 2017-08-17.
[13] I. Dávid, J. Denil, and H. Vangheluwe, “Towards Inconsistency Man-
monitoring of the enacted process). These concerns will be agement by Process-Oriented Dependency Modeling,” in Proc. of 9th
addressed in future work. Int. Workshop on Multi-Paradigm Modeling, pp. 32–41, 2015.
As a future work, we plan to combine the approach pre- [14] J. W. Forrester, Principles of Systems. Productivity Press, 1968.
[15] K. Vanherpen, J. Denil, I. Dávid, P. De Meulenaere, P. Mosterman,
sented in this paper with our previous work [7]. This will en- M. Törngren, A. Qamar, and H. Vangheluwe, “Ontological Reasoning
able explicit reasoning about the trade-off between managing for Consistency in the Design of Cyber-Physical Systems,” in CPSWeek
inconsistencies in the process optimization phase and during workshop proceedings, 2016.
[16] O. Kovalenko, E. Serral, M. Sabou, F. J. Ekaputra, D. Winkler, and
the enactment. Another direction in our research is to support S. Biffl, “Automating Cross-Disciplinary Defect Detection in Multi-
our approach with inconsistency resolution techniques. We Disciplinary Engineering Environments,” in Knowledge Engineering and
aim for developing a semi-automated selection of resolution Knowledge Management, pp. 238–249, Springer, 2014.
[17] S. Feldmann, K. Kernschmidt, and B. Vogel-Heuser, “Combining a
methods, which will require detailed cost models of the SysML-based Modeling Approach and Semantic Technologies for An-
process and all of its aspects. Finally, the current framework alyzing Change Influences in Manufacturing Plant Models,” Procedia
serves as an enabler for our future research on inconsistency {CIRP}, vol. 17, pp. 451 – 456, 2014.
[18] A. Sangiovanni-Vincentelli, W. Damm, and R. Passerone, “Taming
tolerance [4]. Dr. Frankenstein: Contract-Based Design for Cyber-Physical Systems,”
European Journal of Control, vol. 18, no. 3, pp. 217 – 238, 2012.
ACKNOWLEDGEMENTS [19] K. Vanherpen, J. Denil, P. De Meulenaere, and H. Vangheluwe, “On-
tological Reasoning as an Enabler of Contract-Based Co-design,” in
This work has been partially carried out within the frame- International Workshop on Design, Modeling, and Evaluation of Cyber
Physical Systems, pp. 101–115, Springer, Cham, 2016.
work of the Flanders Make project MBSE4Mechatronics (grant [20] Denil, Joachim, “Design, verification and deployment of software-
nr. 130013) of the agency for Innovation by Science and intensive systems: a multi-paradigm modelling approach,” University
Technology in Flanders (IWT-Vlaanderen). This work was Antwerp, 2013.
[21] D. Di Ruscio, M. Franzago, H. Muccini, and I. Malavolta, “Envisioning
partly funded with a PhD fellowship grant from the Research the future of collaborative model-driven software engineering,” in Pro-
Foundation - Flanders (FWO). ceedings of the 39th International Conference on Software Engineering
The authors would like to thank the valuable insights and Companion, pp. 219–221, IEEE Press, 2017.
[22] M. Persson, M. Törngren, A. Qamar, J. Westman, M. Biehl, S. Tri-
advices of Joachim Denil and Vera Farkas. pakis, H. Vangheluwe, and J. Denil, “A Characterization of Integrated
Multi-View Modeling in the Context of Embedded and Cyber-Physical
R EFERENCES Systems,” in EMSOFT, pp. 1–10, IEEE, 2013.
[23] Object Management Group (OMG), “BPMN 2.0 Specification.” http:
[1] International Organization for Standardization, “ISO/IEC/IEEE //www.bpmn.org/. Acc: 2017-08-17.
42010:2011, Systems and software engineering – Architecture [24] OASIS, “WS-BPEL 2.0 Specification.” http://docs.oasis-open.org/
description.” https://www.iso.org/standard/50508.html. Acc.: 2017-07- wsbpel/2.0/OS/wsbpel-v2.0-OS.html. Acc: 2017-08-17.
07. [25] RedHat, “jBPM Website.” https://www.jbpm.org. Acc: 2017-08-17.
[2] A. Finkelstein, “A foolish consistency: Technical challenges in con- [26] A. Qamar, C. J. Paredis, J. Wikander, and C. During, “Dependency
sistency management,” in Database and Expert Systems Applications, modeling and model management in mechatronic design,” Journal of
vol. 1873 of LNCS, pp. 1–5, Springer, 2000. Computing and Inf. Science in Engineering, vol. 12, no. 4, p. 041009,
[3] R. Van Der Straeten, “Inconsistency management in model-driven engi- 2012.
neering,” An Approach Using Description Logics (Ph. D. thesis), Vrije [27] R. Eramo, A. Pierantonio, and G. Rosa, “Approaching Collaborative
Universiteit Brussel, Brussels, Belgium, 2005. Modeling as an Uncertainty Reduction Process,” in COMMitMDE@
[4] I. Dávid, E. Syriani, C. Verbrugge, D. Buchs, D. Blouin, A. Cicchetti, MoDELS, pp. 27–34, 2016.
and K. Vanherpen, “Towards Inconsistency Tolerance by Quantification [28] T. Mens, R. Van Der Straeten, and M. D’Hondt, “Detecting and resolving
of Semantic Inconsistencies,” in COMMitMDE@ MoDELS, pp. 35–44, model inconsistencies using transformation dependency analysis,” in
2016. International Conference on Model Driven Engineering Languages and
[5] H. Vangheluwe, J. De Lara, and P. J. Mosterman, “An introduction to Systems, pp. 200–214, Springer Berlin Heidelberg, 2006.
multi-paradigm modelling and simulation,” in Proc. of the AIS’2002 [29] M. A. Almeida da Silva, R. Bendraou, X. Blanc, and M.-P. Gervais,
conf. (AI, Simulation and Planning in High Autonomy Systems), Lisboa, Early Deviation Detection in Modeling Activities of MDE Processes,
Portugal, pp. 9–20, 2002. pp. 303–317. Berlin, Heidelberg: Springer Berlin Heidelberg, 2010.
[6] J. Corley, E. Syriani, H. Ergin, and S. Van Mierlo, “Cloud-based [30] A. Egyed, “Automatically Detecting and Tracking Inconsistencies in
Multi-View Modeling Environments,” in Modern Software Engineering Software Design Models,” IEEE Trans. on Sw. Engineering, vol. 37,
Methodologies for Mobile and Cloud Environments, IGI Global, 2015. no. 2, pp. 188–204, 2011.
[7] I. Dávid, J. Denil, K. Gadeyne, and H. Vangheluwe, “Engineering [31] CMMI Product Team, “CMMI for Development, Version 1.3, Tech. Rep.
Process Transformation to Manage (In)consistency,” in Proceedings of CMU/SEI-2010-TR-033,” 2010.
the 1st International Workshop on Collaborative Modelling in MDE
(COMMitMDE 2016), pp. 7–16, http://ceur-ws.org/Vol-1717/, 2016.