Engineering Process Transformation to Manage (In)consistency István Dávid Joachim Denil University of Antwerp & Flanders’ Make, Belgium University of Antwerp & Flanders’ Make, Belgium istvan.david@uantwerpen.be joachim.denil@uantwerpen.be Klaas Gadeyne Hans Vangheluwe Flanders’ Make, Leuven, Belgium University of Antwerp & Flanders’ Make, Belgium klaas.gadeyne@flandersmake.be McGill University, Montréal, Canada hans.vangheluwe@uantwerpen.be ABSTRACT to linguistic structures and parameters. We argue that rea- Inconsistencies pose a severe issue to overcome in collabo- soning over explicitly modeled semantic properties suits the rative modeling scenarios, especially in settings with differ- problem of tackling inconsistencies better, as demonstrated ent domains involved. This is due to the significantly dif- by Herzig et al [20] and Vanherpen et al [32]. ferent formalisms employed that have overlapping semantic Finkelstein [16] hints that instead of just removing incon- domains. A pertinent example are today’s mechatronic and sistencies, one should manage them. This entails reasoning Cyber-Physical Systems. about the causes and sources of inconsistencies, their evolu- In this paper, we propose an approach for managing in- tion, interaction and impact on the overall design. We argue consistencies based on explicitly modeled linguistic and on- that this can be best achieved by investigating inconsisten- tological properties. We argue that to fully understand the cies in the context of (i) the design process of the virtual reasons of their occurrence and impact on the overall de- product, (ii) the modeling languages and transformations sign, inconsistencies should be investigated in the context of used in the process, and (iii) the ontological and linguistic the process they emerge in. For this purpose, we propose properties of the virtual product that are manipulated dur- a language for modeling processes in conjunction with the ing the design. Explicit modeling of these concerns, along properties of the engineered system. Characteristics of in- with the interactions between them, especially between the consistencies are identified in terms of process models and design activities and properties, enables better understand- properties. A method for optimal selection of management ing of how inconsistencies arise and ultimately, how they techniques is provided. We demonstrate our ideas on a case should be managed, i.e. prevented, or detected and subse- study of a real mechatronic system. quently resolved. In this paper we present an approach for inconsistency management in the context of engineering processes. Po- Keywords tential sources of inconsistencies are identified by consid- inconsistency management, model-based design, cyber- ering characteristics of the process model. Management of physical systems, design space exploration inconsistencies is achieved by selecting the appropriate tech- niques from a catalogue of management patterns and apply- ing them on the unmanaged process to achieve a managed 1. INTRODUCTION one. Typical patterns include re-ordering activities of a pro- Collaborative modeling scenarios are vulnerable to model cess, ensuring property checks around inconsistency-prone inconsistencies. This is a consequence of the multiple views regions and using design contracts [30]. Since the same type on the same virtual product that give rise to outdated and of inconsistency may be managed via different management incorrect data. The problem is exacerbated when different patterns, the selection of the most appropriate one should engineering domains are involved, as different engineering happen through quantified cost measures. This problem is domains use significantly different formalisms and paradigms translated to a constraint solving and optimization problem to model specific parts of the system. which finds the best process alternative while managing ev- Overlaps in the semantic domain of models have been ery potential source of inconsistencies. The concept is shown identified as the primary reason of model inconsistencies by in Figure 1. many authors [27, 21, 33]. For example, the safety property of a mechatronic product translates to different concepts in terms of its mechanical, electric and control simulation mod- els, and consequently, these concepts will overlap through the property of safety. A significant amount of research has been dedicated to solving semantic inconsistencies on the syntactic level (for example [2, 6]). These approaches, however, are prone to lose vital information during the approximation and ab- straction steps taken while translating semantic properties Figure 1: Conceptual overview of the approach. There are two typical use cases of our approach: (i) opti- mizing existing design processes by first augmenting them with language and property information and then solving the constraint satisfaction and optimization problem; and (ii) generating new processes from language and property information. Both cases are realistic in complex engineer- ing scenarios and their occurrence typically depends on the CMMI [9] level the engineering unit is situated on. Figure 2: Front and top view of the conceptual design. Contributions. The main contribution of this paper is an approach for managing inconsistencies in complex engineer- ing processes, that includes Simulink and Virtual.Lab Motion for multi-body simula- tions employed during controller design, AMESim for multi- A a formalism (i.e. a language and its semantics) for physical simulations during drivetrain desing. Motor and modeling processes in relation with the properties of battery selection activities use databases maintained in Ex- the engineered system; cel files. Since these tools work with different modeling for- B a method for detecting inconsistencies and identify- malisms, reasoning over the consistency of the system as a ing the most appropriate resolution technique based whole properties poses a complex problem to overcome. By on quantified cost measures; explicitly modeling linguistic and ontological properties and associating them with the engineering activities, patterns of C a prototype tool supporting our approach; and inconsistencies can be identified and handled. D a case study of a real mechatronic system. Running example As a running example, we use a segment of the process in the The rest of the paper is organized as follows. In Section 2, case study shown in Figure 3. The example highlights how we present a motivating case study of an automated guided inconsistencies can occur due to properties of the system vehicle. In Section 3 a formalism for modeling processes that interact with activities of an engineering process. with properties is presented. In Section 4 we characterize inconsistencies in terms of the previously presented formal- ism, identify typical inconsistency patterns, provide an ini- tial catalog for managing them and a method for selecting the most appropriate inconsistency management technique for single inconsistencies by multi-objective design space ex- ploration (DSE). Section 5 discusses the prototype tooling supporting our approach. Finally, related approaches are reviewed in Section 7, and Section 8 concludes our paper. 2. CASE STUDY We use a case study of the design of an automated guided vehicle (AGV) to motivate our work. The AGV is designed to transport payload on a specific trajectory between a set Figure 3: Running example. of locations. The drivetrain is fully electrical, using a bat- tery for energy storage and two electric motors driving two Initially, components of the system, such as the battery, wheels. Being a complex mechatronic system, the require- are selected based on approximations and domain exper- ments of the AGV are specified by stakeholders of the differ- tise. The mass of the initially selected battery is considered ent involved domains, such as (i) mechanical requirements: during the Mechanical design phase to identify the mass sufficient room on the vehicle to place payload; (ii) con- constraints on other parts of the system. After the mechan- trol requirements: following the defined trajectory with a ical design phase, the electrical model is designed in details. given maximal tracking error; (iii) electrical requirements: This includes identifying the required capacity of the bat- autonomous behavior, defined as the number of times that tery by Simulating the electrical model, in order to fulfill the it needs to be able to perform the movement before needing autonomy requirement. to recharge; (iv) product quality requirements: the previous Inconsistencies may arise when the Battery capacity prop- requirements should be achieved at a minimal cost. erty is changed, because the Battery mass property depends Figure 2 shows the conceptual geometric design of the on it: batteries with bigger capacity are typically heavier. AGV. The design team chose a circular platform, with two As the capacity is changed, the mass becomes inconsistent omniwheels in addition to the two driven wheels. with the capacity. Should the inconsistency get unnoticed, The design process needs to determine the sizing of the dif- the engineered system will fail to meet the requirements. ferent components (motors, battery, platform) and tune the There are two important specificities to this example that controller. This process is decomposed into multiple depen- motivate our work. dent design steps, such as motor selection, battery selec- First, inconsistencies occur due to the lack of explicitly tion, platform-, controller-, and drivetrain design. The pro- modeled information about how activities access system prop- cess requires an interplay between different domain-specific erties. The key in identifying the above inconsistency is the engineering tools, such as CAD tools for platform design, explicit modeling of the nature of interaction between activ- ities and properties, such as reading or modifying a property. In the following, we elaborate on the specific parts of this We refer to this information as intents of activities over (a process model. First, we briefly present the foundations of set of) properties. the Ftg+Pm formalism for typed processes; then we extend Second, state-of-the-art techniques typically reason about processes with costs; finally we discuss the property model inconsistencies in terms of linguistic model elements. The in details. dependency between the two properties is, however, not per- sisted in any of the engineering models as it is an inter- 3.1 Typed processes based on the FTG+PM domain relationship. To tackle this problem, we allow mod- By the process p ∈ P , we mean a 4-tuple (A, ∆c , O, ∆o ) eling ontological properties as well, and linking them to ac- consisting of tivities by intents. • a set of activities (A); • a set of directed control relations between activities 3. A FORMALISM FOR MODELING PRO- (δ c ∈ ∆c : A 7→ A); CESSES WITH SYSTEM PROPERTIES • a set of objects (O); To model engineering processes with sufficient semantics for managing inconsistencies, we propose a formalism that • a set of directed data flow relations between activities augments the process with the syntactic and semantic prop- and objects (δ o ∈ ∆o : A 7→ O); erties that depict specificities of the engineered system. We build our formalism on the Ftg+Pm [25] formalism, The control flow is a transitive relation, i.e. ∀a1 , a2 , a3 ∈ which enables the usage of process models (“Pm”) in con- A : δc (a1 , a2 ) ∧ δc (a2 , a3 ) ⇒ δc (a1 , a3 ), and the following junction with the model of languages and transformations notation is used a3 ∈ ∆+ c (a1 ). (the formalism-transformation graph - “Ftg”) used through- The language model consists of modeling languages and out the process. As shown in Figure 4, languages and trans- transformations, formally: LAN G = (L, T ), and serves as formations serve as a type system to the processes: objects a type system to processes, where languages type process of the process are instances of languages of the Ftg; and objects and transformations serve as specifications to activ- activities of the process realize transformations. Section 3.1 ities. In the case study, for example, the models of the me- provides a brief overview on Ftg+Pm . chanical design activity are typed by a CAD language, while the activity itself realizes the transformation(s) required to achieve the engineering goals during the mechanical design, such as dimensioning the platform of the AGV, and obtain- ing and executing a finite element simulation model. That is, modelM ech ∈ O, and typeOf (modelM ech ) = CAD, where CAD ∈ L; additionally, typeOf (aM echDesign ) ∈ T . Figure 4: Relationships between processes, languages and 3.2 Costs properties. We extend the definition of activities by their costs. For the sake of simplicity, we focus on costs constituting ratio scales, We extend the above formalism by allowing explicit model- i.e. for the cost c of activity a ∈ A the following holds: ing of properties in context of processes and languages. We assume activities of an engineering process have a mean- c(a) : a 7→ R+ . ingful purpose of enhancing the system. This purpose is ex- Costs serve as a basis for quantifying the differences be- pressed as the intent of an activity with respect to a property tween various process alternatives. In our current work, we or a set of properties. Furthermore, we extend the process approximate costs by the transition time required for single model by enabling specification of costs of single activities. activities. Non-linear processes, i.e. the ones with directed Modeling costs enables reasoning over the managed process loops, are typical in engineering scenarios. In these cases, candidates (as shown in Figure 1). the cost of a process is a non-deterministic value that can The type system plays an important role in the analy- be obtained by appropriate simulations. sis of complex process models. Typing process objects by languages and linking activities to transformations enables 3.3 The property model reasoning about the MDE aspects of an engineering process By a property model P ROP we mean a tuple (Π, R) con- with models and model transformations as first class arti- sisting of facts. Additionally, in deployed and enacted process mod- els, the language model serves as a basis for conformance • the set of linguistic and semantic properties Π; and and validity checks. For the sake of conciseness, we refer to • the set of influence relationships R between properties. the various elements of our formalism with slightly different terminology. In our terms, a process model P M consists of Properties of the running example in Figure 3 are the Battery mass and Battery capacity, while the dependency • a set of processes P (equivalent to the Pm part of an between those is a relationship with a direction and a level Ftg+Pm) that take of precision. In the following, we first elaborate on proper- ties (Section 3.3.1) and the influence relationships between • a language model LAN G as a type model (equivalent them (Section 3.3.2); then we relate properties to processes to the FTG part of an Ftg+Pm), and relate to by formalizing intents (Section 3.3.3); and finally, we provide a typing strategy for properties in terms of the Ftg+Pm for- • a property model P ROP . malism (Section 3.3.4). 3.3.1 Properties relationship. In the running example, the relationship be- Properties capture qualitative and quantitative characteris- tween the Battery mass and Battery capacity constitutes an tics of the modeled system. While linguistic properties rep- L2 relationship: increasing the capacity requires increasing resent values of various types, ontological properties capture the battery mass, although the exact relation cannot be pro- system characteristics in terms of satisfaction constraints. vided as batteries come in various architectures. The way properties are checked, also depends on their types. Checking a linguistic property means evaluating if the actual Acausal influence relationships value of the property is within a range of acceptance crite- Acausality provides compactness in terms of the notation of ria; checking an ontological property, on the other hand, relationships: it enables modeling of N-ary relationships in means evaluating if the property is satisfied or not. While a more convenient and readable fashion. Figure 6a shows the former check is typically achieved by well-defined opera- an N-ary influence relationship, depicting a simple law of tors over the algebraic structures of the type of the property physics: BatteryM ass + M otorM ass = T otalM ass. By (e.g. arithmetic operators over number values), the latter assigning value to two of the three properties, the third can type of checks typically involves simulations or model check- be automatically calculated. The same information can be ing tasks. captured in an acuasal way as presented in Figure 6b. For example, the battery mass property of the case study is a linguistic one (persisted in the CAD model), while safety and autonomy properties are semantic and can be checked by simulations or model checking techniques. Explicitly modeling properties and their relationships en- ables (i) reasoning over these specificities, and (ii) fosters communication of tacit knowledge, which is especially im- portant in the early phases of a multidisciplinary design pro- (a) Causal notation of an N-ary relationship. cess [32]. In our approach, ontological and linguistic prop- erties are treated uniformly. 3.3.2 Influence relationships Relationships between two properties are present if a change in one property potentially influences the other. In the case study, properties Battery capacity and Current drawn could (b) Acausal notation of the same N-ary relationship. be considered two properties with a relationship in between (Figure 5): a change in the Battery capacity will have an Figure 6: Causal and acausal notation of a relationship. impact to the Current drawn and vica versa. In our approach, we allow using acausal relationships, but translate them to the causal equivalent form when carrying out analyses. Formally, given an acausal influence relation- ship r of level λ over a set of properties Π0 , the causality assignment maps r = (∅, Π0 , λ) onto aSset of relationships R0 = h(Π00 , Π000 , λ)i, such that Π0 = Π00 Π000 . Figure 5: Influence relationship between properties. The causal equivalent can be unambiguously determined A relationship r is formally defined as r ∈ R = (Πji ⊆ only in symmetric N-ary relationships, meaning any M num- Π, Πn m ⊆ Π, λ), i.e. ber of the N properties determine the remaining N −M , e.g. the one in Figure 6. In this case the causal equivalent will • a set of influencer (input) properties Πji = {π i ..π j }, consisist of MN causal relationships. • a set of influencee (output) properties Πn m = {π m ..π n }, Change scope of properties • a level of precision λ ∈ {L1, L2, L3}. By a change scope of a property π we mean a subset of prop- erties χπ ⊆ Π potentially affected by a change in π. Given The three levels of precision are defined in our previous work two properties π1 and π2 directly linked by a relationship [10] and are as follows. r(Πji , Πn m , λ), the change set is defined as follows. • L1: the fact of influence is known, its extent is not; π2 ∈ χ(π1 ) ⇔ (π1 ∈ Πji ∧ π2 ∈ Πn m) • L2: sensitivity information between two values is That is, property π2 is in the change scope of property π1 iff known; π1 is an input property and π2 is an output property of an influence relationship. In the running example, the Battery • L3: the relationship can be expressed using an exact mass property is in the change scope of Battery capacity. mathematical relationship. The change scope is a reflexive and transitive relation, i.e. Figure 5 shows a pair of properties that mutually influence ∀π ∈ Π : π ∈ χ(π), each other, albeit on different levels of precision. A change in the Current drawn has an L3 influence R on the Battery capac- ∀π1 , π2 , π3 ∈ Π : π2 ∈ χ(π1 ) ∧ π3 ∈ χ(π2 ) ⇒ π3 ∈ χ(π1 ), ity as follows: BatteryCapacity ≥ CurrentDrawn(t)dt. The relationship in the other direction, however, cannot be respectively. We use the following notation for the transitive determined in such details and thus, only constitutes an L1 closure of the change scope: π3 ∈ χ+ (π1 ). 3.3.3 Intents 4.1 Formal characterization of unmanaged in- Intents capture the motivation of an activity with respect consistencies to a property or a relationship of properties, such as reading In the following, we identify cases when inconsistencies may and modifying a property. An intent i ∈ I is defined by the occur. We formalize this information in terms of pairs of ac- tuple (a, s, tI ), where tivities, the related properties and intents. Generally, incon- sistencies are introduced when an activity modifies a prop- • a ∈ A is an activity; erty that is accessed by another activity. A more formal S • s ∈ Π R is the subject of intent, i.e. a property or a definition can be given by distinguishing between activities relationship; situated in a sequential order and in parallel branches of a process. By sequential and parallel activities we mean • tI ∈ TI is the type of intent. ∀a1 , a2 ∈ A : seq(a1 , a2 ) ⇔ a2 ∈ ∆+ c (a1 ); We define four elementary intents for our approach: TI = ∀a1 , a2 ∈ A : par(a1 , a2 ) ⇔ a2 6∈ ∆+ + c (a1 ) ∧ a1 6∈ ∆c (a2 ), {read, modif y, check, contract}, the first two being the typ- ically occurring intents in standard engineering activities, respectively. That is, two activities are said to be sequential while the latter two are specific to activities related to in- iff one activity is transitively reachable from the other via consistency management. the control flow of the process. If no such relation exists (in As discussed in Section 2, the main rationale behind ex- any direction), the activities are said to be parallel. plicitly modeling intents is that they carry valuable infor- mation regarding inconsistencies in processes, which enables 4.1.1 Sequential case reasoning about the origin and the potential management of Given a pair of activities a1 , a2 ∈ A : seq(a1 , a2 ), property inconsistencies. The inconsistency in the running example is π is said to be exposed to a potential inconsistency due to possible to detect because of the exactly modeled pair of the insufficient inconsistency management in the following case. read-modify intents on properties that influence each other and activities that are control-dependent. In Section 4 we ∃(π 0 ∈ Π, i1 , i2 ∈ I) : i1 (a1 , π, t1 ) ∧ i2 (a2 , π 0 , t2 ) ∧ formally characterize inconsistencies in terms of processes, π ∈ χ+ (π 0 ) ∧ t1 = read ∧ t2 = modif y ⇒ ∃ ic(π) ∈ IC, properties and intents. where IC denotes the set of unmanaged inconsistencies. 3.3.4 Typing of the property model That is, property π is exposed to a potential inconsistency Intents relate properties to processes. In order to handle if activity a1 first accesses it with a read intent and subse- property models in a type-safe manner, however, properties quently activity a2 modif ies property π 0 , while property π and relationships have to be related to the type system de- is in the change scope of π 0 . The relation does not hold the fined by the language model as well. other way around, i.e. by first modifying and subsequently We handle elements of the property model as special pro- reading a property does not lead to inconsistencies. cess objects that activities interact with. That is, following As a consequence of the reflexivity of the change scope, the the definition of processes in Section 3.1: above definition applies on cases where the same property is [ being read and modified as well. ∀p ∈ P ∀s ∈ Π R : s ∈ O(p), 4.1.2 Parallel case ∀p ∈ P ∀i ∈ I : i ∈ ∆o (p). Given a pair of activities a1 , a2 ∈ A : par(a1 , a2 ), property Consequently, both properties and relationships are typed π is said to be exposed to a potential inconsistency in the by appropriate languages, e.g. OWL languages [4], for mod- following case. eling properties, or graphs, algebra and Forrester system dy- ∃(π 0 ∈ Π, i1 , i2 ∈ I) : i1 (a1 , π, t1 ) ∧ i2 (a2 , π 0 , t2 ) ∧ namics [17] for modeling relationships. Intents are typed by an intent language TI , i.e. π ∈ χ+ (π 0 ) ∧ t2 = modif y ⇒ ∃ ic(π) ∈ IC. ∀ TI = {i1 ..in } : TI ∈ LAN G. The definition is different from the one in the sequential case in not being specific about the type of intent i1 . This This means the language of intents in our approach can is because of the inconclusive ordering of a1 and a2 due to be aligned with the application domain of the problem at their parallel relation. Since the two activities may access hand. The intents used throughout this paper are rather the related properties in any order, the cases of potential general and capture only access-change information over sys- inconsistencies cannot be narrowed to a specific ordering of tem properties. read-modify intent pairs. That is, inconsistencies may arise if any of the two activities reads property π, while the other 4. MANAGING INCONSISTENCIES one modif ies π 0 . After presenting the process modeling formalism for rea- soning over inconsistencies in Section 3, we give a formal 4.2 Patterns of inconsistency management characterization of unmanaged cases that may lead to in- We use four typical inconsistency management patterns in consistencies. We associate inconsistencies with changes in our approach. This catalogue of patterns is, however, exten- properties that are shared among multiple activities. Rea- sible in the prototype tooling. soning over such cases is enabled by explicitly modeled in- tents of the activities over the properties. To manage incon- 4.2.1 Reordering and sequencing sistencies, we augment the original process with appropriate Reordering and sequencing aim to modify the control flow management patterns. in order to avoid inconsistencies. Given a sequential case, i.e. a1 , a2 ∈ A : seq(a1 , a2 ) ⇒ by model transformation based multi-objective design space π ∈ IC, the reordering strategy would swap a1 and a2 , i.e. exploration (DSE) as shown in Figure 7. seq(a1 , a2 ) → seq(a2 , a1 ), to utilize that the appropriate or- der of read-modify intents does not lead to inconsistencies, as shown in Section 4.1.1. In parallel cases, i.e. a1 , a2 ∈ A : par(a1 , a2 ) ⇒ π ∈ IC, the sequencing strategy would try every possible order of the activities and eventually select the one that leads to the most optimal process, i.e. par(a1 , a2 ) → seq(a1 , a2 ) ∨ seq(a2 , a1 ). Reordering and sequencing are easy-to-apply and inexpen- sive patterns as they do not require introducing additional management activities. Both patterns work well in simple cases; in more complex processes, however, both patterns tend to introduce other inconsistencies. Figure 7: Detailed overview of the DSE approach. 4.2.2 Property check The exploration mechanism takes the original unmanaged Property checking is used to ensure no inconsistencies are process and the property model as an input and produces an introduced on specific sections of the process. A special optimal managed process as a series of model transformations activity acheck is added to the process that accesses the un- applied on the original process. (The property model is left managed properties with a check intent. If the result of the intact as it reflects domain knowledge and as such, typically check is satisfactory, the process continues with the subse- should not be changed because of a single process.) The quent activities; in the case of a failed check, however, the exploration process is guided by mandatory constraints and process would fall back to the latest point where the incon- optimality objectives. sistency is not yet present and facilitate a re-iteration loop. The property check pattern is a typically expensive man- 4.3.1 Transformation rules agement pattern as it introduces directed loops in the design The purpose of using model transformations is twofold. We processes and therefore, makes processes inherently non- use them to augment the process with inconsistency man- deterministic. agement techniques, but also for rewriting the process into a better performing process. An example for the latter one is 4.2.3 Contracts parallelizing as many activities as possible. Of course, this In a contract-based approach [32], the stakeholders would will affect the applicable inconsistency management tech- agree on acceptance criteria of specific properties before ex- niques, and therefore, the execution and evaluation of these ecuting specific design activities. A special activity acontract transformations must be achieved in a coupled way. is added to the process to represent the contract negotia- tion phase. The activity accesses the unmanaged properties Management transformations with a contract intent. The contract is respected during the Transformation rules aiming to augment the process with activities, thus providing means to avoid inconsistencies. inconsistency management techniques, are derived from the inconsistency patterns (Section 4.1) and management pat- 4.2.4 Assumptions terns (Section 4.2). A transformation rule is defined as A less rigorous approach to contracts is also possible by mak- ∃ ic ∈ IC : ic(ω ⊆ P M ) ∧ ing an educated guess about the shared properties. In the parallel case: a1 , a2 ∈ A : par(a1 , a2 ) ⇒ π ∈ IC, one of @ m ∈ M : m(ic(ω ⊆ P M )) the parallel activities makes assumptions about the proper- → apply(m0 (ic(ω ⊆ P M ))), m0 ∈ M. ties that will be modified by the other activity. However, these assumptions need to be checked once the process re- That is, if an inconsistency pattern ic is detected on a sub- joins both branches. The benefit of the pattern is that only set ω of the process model P M , and there is no correspond- one of the branches has to be re-executed if the assumption ing management pattern m detected for the same subset of proves to be invalid, i.e. an inconsistency may occur. elements, then an appropriate management pattern m0 is applied to the inconsistency. 4.3 Process optimization Since multiple management patterns can be applied for the General transformations same type of inconsistency with varying benefits, we formal- The overall goal of our approach is to find better processes, ize the process rewriting problem as a constraint solving and with respect to a goal function, that create correct prod- optimization problem as follows. ucts. Apart from the transformations specific to inconsis- tency management, therefore, we also use transformations minimize cost(p) that manipulate the structure of processes, such as adding p and removing control flow between activities, arranging ac- subject to |IC| = 0, tivities into sequences or parallel branches, etc. There is v(p) = 1. no restriction on how far the exploration strategy can go in restructuring the process, as it is determined in the ex- where v(p) : p ∈ P 7→ B is the indicator function of the va- ploration phase by considering that every inconsistency has lidity (i.e. well-formedness) of a process p. We also demand to be managed. By making certain activities parallel, more a fully managed process (|IC| = 0). We solve the problem linguistic and semantic overlap exists at the same instant in the process and thus making the process more vulnerable to • matching the process model against the patterns of the inconsistencies. inconsistency catalogue; Note that certain applications of this pattern are not us- able. For example, the parallelization of a design activity • applying patterns of the inconsistency management cannot be parallelized with the subsequent simulation of the catalogue on the process; and created model. • selecting the best fitting management pattern based 4.3.2 Constraints and objectives on cost simulations. Constraints and objectives are used to guide the exploration process and evaluate the solution candidates. As defined previously, we constrain the set of solutions to processes that are valid and have no unmanaged inconsistencies. As the objective function, the cost of the process is used. Since the cost of non-linear processes (i.e. the ones featuring directed cyclic graphs) is not deterministic, simulations of various kinds can be used to obtain the cost, such as event queueing networks or discrete event simulations. 5. PROTOTYPE TOOL SUPPORT Figure 9: Conceptual overview of the core of the prototype. We support our approach with a prototype tool that al- lows (i) modeling processes with the aspects and semantics For design space exploration, the VIATRA-DSE framework presented in Section 3; and (ii) augmenting processes with [1] is used. The inconsistency and management catalogues, inconsistency management patterns, while identifying the as well as cost models are fully extensible, i.e. new incon- optimal managed process.1 sistency and management patterns can be formalized by the appropriate graph query and transformation languages, and 5.1 Process modeling costs can be evaluated using other approaches than the ones As a first step, the initial process has to be modeled along presented here. with the languages and properties. Our tool provides a graphical modeling environment for this purpose, implemented 5.2.1 Inconsistency catalogue using the Sirius framework [13]. Figure 8 presents an excerpt Patterns of inconsistencies are captured by graph queries from the process model of the case study, relevant for the over the input model. In our prototype tool, we use the running example discussed in Section 2. VIATRA Query Language (formerly EMF-IncQuery) [31] for this purpose. Listing 1 presents the inconsistency pattern matched on the running example. The pattern reflects the left-hand side (LHS) of the gen- eral transformation rule in Section 4.3.1. In Line 7, proper- ties p1 ∈ R+ (p2) and activities a2 ∈ ∆c (a1) accessing the two properties with the respective read and modify intents are identified. Subsequently, in Lines 8-9, the number of ap- plied inconsistency management patterns is determined. In case there is no management pattern applied (Line 10), the pattern is matched and the match set requires an inconsis- tency management pattern to be applied. 1 pattern u n m a n a g e d R e a d M o d i f y ( Figure 8: Excerpt from the process model of the case study. 2 a1 : Activity , p1 : Property , a2 : Activity , p2 : Property ) 3 { The Mechanical design activity is modeled as a manual one, 4 find r e a d M o d i f y S h a r e d P r o p e r t y ( a1 , p1 , a2 , p2 ); 5 checks == count find checkProperty ( a2 , _ , p2 ); executed by the mechanical engineer. During the activity, 6 contracts == count find contract (_ , a1 , p1 ); the Battery mass property is accessed with a read intent. 7 check ( checks + contracts ==0); The cost of the activity reflects the approximate time re- 8 } quired for executing it, i.e. 1.0 hour. Later in the process, Listing 1: The read-modify inconsistency pattern. the Simulate electrical model automated activity modifies the Battery capacity property which influences the Battery 5.2.2 Management catalogue mass, as a consequence of the latter one being in the change Management patterns are captured as model transforma- scope of the former one. It is the explicit modeling of intents tions over the model. In accordance with Section 4.3.1, what enables identifying the potential inconsistency. the LHS of the transformation rules consist of the previ- ously defined inconsistency patterns; while the right-hand 5.2 Management of inconsistencies side (RHS) defines how the specific inconsistency should be In the next phase the design space exploration is executed handled by using one of the management patterns described which includes in Section 4.2. Allowed LHS-RHS combinations are speci- 1 The tool is available under the EPL licence at https:// fied in terms of VIATRA Model Transformations [5], that github.com/david-istvan/icm. The detailed case study is enable directly reusing the previously defined graph queries available at https://github.com/david-istvan/agv. as the LHS. 5.2.3 Cost simulations As discussed in Section 3.2, cost of a process is not determin- istic in most cases. We support our approach by two types of cost simulations in the prototype tooling. In fixed iteration simulations, the loops of the design process are identified and simulated with a fixed amount of iterations resulting in a process cost as follows i=|A(p)| X ∀p ∈ P : c(p) = c(ai )n(ai ). 1 Loops are detected by a graph pattern matcher. If a loop is detected between two activities, the costs of activities in the loop are weighted by the number of iterations N and added to the sum cost. The parameter is to be set by a domain expert. In our experiments, we used 3–5 iterations as the typical values. In event queueing network (EQN) based stochastic simu- lations [18], the decision of re-iterating over a loop is sim- ulated with sampling from a probabilistic distribution. We Figure 10: Managed alternative of the process in Figure 8. carried out our early experiments using the SimEvents tool- box [26]. While stochastic simulations offer more precise processes (projects), at least partially, which is a typical con- results in terms of simulating the costs, they are also more cern in companies on CMMI levels 3 and above. [9] In order demanding in terms of computation power and time. to enhance the reusing of domain knowledge, techniques of 5.3 Results of the case study ontological reasoning will be investigated. In the following, we discuss the required extensions to the After exploring the space of alternative solutions and rank- current work in order to develop an inconsistency manage- ing them based on costs, the managed process is obtained. ment framework. Figure 10 presents a managed alternative to the running example in Figure 8. As an allow-and-resolve type incon- 6.1 Complex cost models and resources sistency technique, property checking is executed after the As the primary research direction, we will extend the for- location of the potential inconsistency. The manual Check- malism in Section 3 with more complex cost models and the BatteryMass activity accesses the potentially inconsistent notion of resources. In our current approach, cost is a one- property Battery mass with a check intent. Subsequently, a dimensional performance metric of the process, estimated decision node is added to the control flow to enable a back- from the development time. In real settings, however, differ- ward loop in case the check fails (NO) and to proceed if the ent types of costs may be used to capture the performance of check succeeds (OK ). The pattern also introduces a loop the process and thus providing a basis for optimization, e.g. that enables arbitrary re-iterations, which is the main con- queueing time, delay or processing volume [22]. By incorpo- tributor to the increased process cost. As opposed to this, rating the notion of resources, the optimization problem will an alternative reusing the technique of contract based design get extended by job scheduling aspects [3]. Resources pose would not require such loops, but the management activity additional constraints on process re-engineering in terms of itself would be more elaborate as the contract negotiation the feasibility of the process. phase requires stakeholders from multiple domains. The real challenge of applying inconsistency management 6.2 Advanced solution techniques patterns in an orchestrated way, so that their application The multi-objective nature of our DSE approach (Sec- does not give rise to new unmanaged inconsistencies, is tack- tion 4.3) scales well with introducing additional dimensions led by using a heuristic or exhaustive search through the to the underlying formalism discussed above. A known limi- state space. Applying our approach to the whole process of tation of DSE based approaches is, however, the potentially the case study resulted in a fully managed process with rea- missed global optimum of the input problem. We plan to sonable increase in costs. In our simulations, we measured address this limitation by translating the inconsistency man- up to 10% cost reduction while fully managing the process agement problem to more complex solution methods, such with two types of inconsistencies. as heuristic algorithms [23] and genetic algorithms [34] that have been successfully applied in resource constrained pro- 6. DISCUSSION cess optimization. The results described in this paper serve as the founda- tions to a comprehensive inconsistency management frame- 6.3 Tooling aspects work. The approach, in its current form tackles two impor- The current version of the prototype tool supports the tant problems in engineering practice. First, as presented in modeling phase of process engineering, but to achieve a com- the previous sections, combining the notion of processes with prehensive inconsistency management framework, the exe- inconsistencies sheds light on complex cases of inconsisten- cution phase (i.e. the design phase of the virtual product) cies that are otherwise not detectable nor manageable. Sec- has to be supported as well. For this purpose, the process ond, our approach enables expressing tacit domain knowl- model will be enacted by using model transformations to edge explicitly and thus making it reusable across different provide the operational semantics. The explicitly modeled formalisms/tools enable automated support for tool inter- ties. Egyed et al [14] investigates the impact of single incon- operability, with the potentially reusing integration frame- sistencies on the whole system by introducing the notion of works such as OSLC [29]. change impact based scopes. Scopes are used to carry out resolution steps on the required regions of the models and 7. RELATED WORK thus enhancing the efficiency of the inconsistency manage- ment framework. We carry out a similar scope detection and Inconsistency management is a well-studied topic in the management on the property model of our approach. Spe- domains of software engineering, mechatronic design and cific technical challenges of collaborative modeling have been cyber-physical systems, due to the typically multi-view and addressed by state-of-the-art techniques, such [11] for com- often multi-paradigm approach to system design. Persson paring and merging models and EMFStore [12] for model et al [27] identify consistency between the various views of persistence. These techniques can serve as an implementa- cyber-physical system design as one of the main challenges in tional basis for improving our tool. design of such complex systems. This is due to relations be- tween views, with respect to their semantic relations, process and operations which often overlap. Our technique embraces 8. CONCLUSIONS these ideas and addresses the problem of inconsistencies by In this paper we presented an approach for managing in- explicitly modeling semantic properties and relating them consistencies in complex engineering settings from a process- to engineering processes. oriented view. A modeling formalism has been provided to Other approaches also acknowledge the role of semantic reason about how inconsistencies arise in processes and how techniques in inconsistency management, and try to relate they impact the overall design. For this purpose, the no- semantic concepts to the linguistic concepts of modeling. tion of intents has been defined as the explicitly modeled Hehenberger et al [19] organize structural design elements relationship between activities of processes and properties and their relations into a domain ontology to identify incon- of the engineered system. We support the automated pro- sistencies. A limited set of semantic properties are expressed cess of inconsistency management by a prototype tool built with linguistic concepts which enables reasoning over seman- on Eclipse technologies. Finally, the approach has been eval- tic overlaps to a sufficient extent. Similarly, Chechik et al [8] uated over a case study of a real mechatronic system using introduce the notion of approximate properties: linguistic our prototype tool. properties expressed as graph patterns which are accurate enough to appropriately approximate a semantic property. Approximate properties suitable to implement smart lock- Acknowledgments ing mechanisms in collaborative model-based design as they The authors wish to thank András Szabolcs Nagy for his introduce a trade-off between the computational resources dedicated help with the VIATRA-DSE engine; Tamás Sz- to obtain or check a property, and the accuracy of the re- abó for his critical and constructive comments; and Kristof sults. As opposed to these, our approach makes semantic Berx for his insights on the case study. This work has been properties first-class artifacts and relates them to processes, partially carried out within the framework of the Flanders instead of linguistic model elements, which enables manage- Make project MBSE4Mechatronics (grant nr. 130013) of the ment of a richer class of inconsistencies. agency for Innovation by Science and Technology in Flan- Ontologies have been used for inconsistency management ders (IWT-Vlaanderen). by Kovalenko et al [24] to support automated detection of defects between domain-specific models. Similarly, Feld- mann et al [15] use the OWL language in conjunction with 9. REFERENCES a SysML-based approach to formally represent the design [1] H. Abdeen, D. Varró, H. Sahraoui, A. S. Nagy, of a production system and evaluate the compatibility of domain-specific models in a collaborative setting. These C. Debreceni, Á. Hegedüs, and Á. Horváth. approaches are complementary to ours: incorporating rela- Multi-objective optimization in rule-based design tionships between ontological properties for reasoning over space exploration. In Proceedings of the 29th inconsistencies is a planned extension to our work. ACM/IEEE Int. Conf. on Automated software As opposed to the above techniques, inconsistency man- engineering, pages 289–300. ACM, 2014. agement in collaborative modeling is more frequently ad- [2] C. Adourian and H. Vangheluwe. Consistency Between dressed on the linguistic level. Qamar et al [28] approach Geometric and Dynamic Views of a Mechanical inconsistency management by making inter- and intra-model System. In Proc. of the 2007 Summer Computer dependencies explicit. Dependencies are direct results of se- Simulation Conf., SCSC ’07, pages 31:1–31:6, San mantic overlaps and are used to notify stakeholders about Diego, 2007. Society for Computer Simulation Int. possible inconsistencies when dependent properties change. [3] C. Artigues, S. Demassey, and E. Neron. Our approach introduces an indirection between models and Resource-Constrained Project Scheduling: Models, properties by relating them to specific activities that dur- Algorithms, Extensions and Applications. ISTE, 2007. ing working over models also access properties with specific [4] S. Bechhofer. OWL: Web ontology language. In intents. Blanc et al [7] approach the detection of inconsis- Encyclopedia of Database Systems, pages 2008–2009. tencies from a model operation based point of view, where Springer, 2009. models are stored as sequences of change events and in- [5] G. Bergmann, I. Dávid, Á. Hegedüs, Á. Horváth, consistencies are expressed in terms of CRUD operations. I. Ráth, Z. Ujhelyi, and D. Varró. VIATRA 3: A Our approach generalizes this approach by introducing in- Reactive Model Transformation Platform. In Theory tents that are analogous with model operations, but they and Practice of Model Transformations, pages express change operations in terms of activities and proper- 101–110. Springer, 2015. [6] A. Bhave, B. Krogh, D. Garlan, and B. Schmerl. the Resource-Constrained Project Scheduling Problem: Multi-domain modeling of cyber-physical systems Classification and Computational Analysis, pages using architectural views. AVICPS 2010, page 43. 147–178. Springer US, Boston, MA, 1999. [7] X. Blanc, I. Mounier, A. Mougenot, and T. Mens. [24] O. Kovalenko, E. Serral, M. Sabou, F. J. Ekaputra, Detecting model inconsistency through D. Winkler, and S. Biffl. Automating Cross- operation-based model construction. In Software Disciplinary Defect Detection in Multi-Disciplinary Engineering, 2008. ICSE ’08. ACM/IEEE 30th Int. Engineering Environments. In Knowledge Engineering Conf. on, pages 511–520, May 2008. and Knowledge Management, pages 238–249. Springer, [8] M. Chechik, F. Dalpiaz, C. Debreceni, J. Horkoff, 2014. I. Ráth, R. Salay, and D. Varró. Property-Based [25] L. Lúcio, S. Mustafiz, J. Denil, H. Vangheluwe, and Methods for Collaborative Model Development. In M. Jukss. FTG+PM: An Integrated Framework for Proc. of 3rd Int. Workshop on The Globalization of Investigating Model Transformation Chains. In SDL Modeling Languages (GEMOC 2015), 2015. 2013: Model-Driven Dependability Engineering, [9] CMMI Product Team. CMMI for Development, volume 7916 of LNCS, pages 182–202. Springer, 2013. Version 1.3, Tech. Rep. CMU/SEI-2010-TR-033, 2010. [26] MathWorks Inc. SimEvents Website. mathworks.com/ [10] I. Dávid, J. Denil, and H. Vangheluwe. Towards products/simevents. Acc.: 2016-07-19. inconsistency management by process-oriented [27] M. Persson, M. Törngren, A. Qamar, J. Westman, dependency modeling. In Proc. of 9th Int. Workshop M. Biehl, S. Tripakis, H. Vangheluwe, and J. Denil. A on Multi-Paradigm Modeling, pages 32–41, 2015. Characterization of Integrated Multi-View Modeling [11] C. Debreceni, I. Ráth, D. Varró, X. De Carlos, in the Context of Embedded and Cyber-Physical X. Mendialdua, and S. Trujillo. Automated Model Systems. In EMSOFT, pages 1–10. IEEE, 2013. Merge by Design Space Exploration. In 19th Int. [28] A. Qamar, C. J. Paredis, J. Wikander, and C. During. Conf. on Fundamental Approaches to Software Dependency modeling and model management in Engineering, 2016. mechatronic design. Journal of Computing and Inf. [12] Eclipse Foundation. EMFStore Website. Science in Engineering, 12(4):041009, 2012. http://eclipse.org/emfstore/. Acc: 2016-07-19. [29] M. Saadatmand and A. Bucaioni. OSLC Tool [13] Eclipse Foundation. Sirius Website. Integration and Systems Engineering – The https://eclipse.org/sirius/. Accessed: 2016-07-19. Relationship between the Two Worlds. 2014 40th [14] A. Egyed. Automatically detecting and tracking EUROMICRO Conference on Software Engineering inconsistencies in software design models. Software and Advanced Applications, pages 93–101, Aug. 2014. Engineering, IEEE Trans. on, 37(2):188–204, 2011. [30] A. Sangiovanni-Vincentelli, W. Damm, and [15] S. Feldmann, K. Kernschmidt, and B. Vogel-Heuser. R. Passerone. Taming Dr. Frankenstein: Combining a SysML-based Modeling Approach and Contract-Based Design for Cyber-Physical Systems. Semantic Technologies for Analyzing Change European Journal of Control, 18(3):217 – 238, 2012. Influences in Manufacturing Plant Models. Procedia [31] Z. Ujhelyi, G. Bergmann, Á. Hegedüs, Á. Horváth, {CIRP}, 17:451 – 456, 2014. B. Izsó, I. Ráth, Z. Szatmári, and D. Varró. [16] A. Finkelstein. A foolish consistency: Technical EMF-IncQuery: An integrated development challenges in consistency management. In Database environment for live model queries. Science of and Expert Systems Applications, volume 1873 of Computer Programming, 98, Part 1:80 – 99, 2015. LNCS, pages 1–5. Springer, 2000. [32] K. Vanherpen, J. Denil, I. Dávid, P. De Meulenaere, [17] J. W. Forrester. Principles of Systems. Productivity P. Mosterman, M. Törngren, A. Qamar, and Press, 1968. H. Vangheluwe. Ontological Reasoning for Consistency [18] D. Gross, J. Shortle, J. Thompson, and C. Harris. in the Design of Cyber-Physical Systems. In CPSWeek Fundamentals of Queueing Theory. Wiley, 2011. workshop proceedings, 2016. [19] P. Hehenberger, A. Egyed, and K. Zeman. Consistency [33] R. Wagner, H. Giese, and U. Nickel. A plug-in for Checking of Mechatronic Design Models. In 30th flexible and incremental consistency management. Computers and Information in Engineering Conf., Proc. of the Int. Conf. on the UML, page 93, 2003. volume 3, pages 1141–1148. ASME, 2010. [34] M. B. Wall. A Genetic Algorithm for [20] S. J. Herzig and C. J. Paredis. Bayesian Reasoning Resource-constrained Scheduling. PhD thesis, Over Models. In 11th Workshop on Model Driven Cambridge, MA, USA, 1996. AAI0598050. Engineering, Verification and Validation MoDeVVa 2014, pages 69–78, 2014. [21] S. J. Herzig, A. Qamar, and C. J. Paredis. An approach to identifying inconsistencies in model-based systems engineering. Procedia Computer Science, 28:354–362, 2014. [22] Improvement Skills Consulting Ltd. Measuring Process Performance. https://ianjseath.files.wordpress. com/2009/04/measuring-processes.pdf, 2008. Acc.: 2016-07-19. [23] R. Kolisch and S. Hartmann. Heuristic Algorithms for