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.