Inconsistencies pose a severe issue to overcome in collaborative modeling scenarios, especially in settings with di erent domains involved. This is due to the signi cantly different formalisms employed that have overlapping semantic domains. A pertinent example are today's mechatronic and Cyber-Physical Systems. In this paper, we propose an approach for managing inconsistencies based on explicitly modeled linguistic and ontological properties. We argue that to fully understand the reasons of their occurrence and impact on the overall design, inconsistencies should be investigated in the context of the process they emerge in. For this purpose, we propose a language for modeling processes in conjunction with the properties of the engineered system. Characteristics of inconsistencies are identi ed in terms of process models and properties. A method for optimal selection of management techniques is provided. We demonstrate our ideas on a case study of a real mechatronic system.
Collaborative modeling scenarios are vulnerable to model inconsistencies. This is a consequence of the multiple views on the same virtual product that give rise to outdated and incorrect data. The problem is exacerbated when di erent engineering domains are involved, as di erent engineering domains use signi cantly di erent formalisms and paradigms to model speci c parts of the system.
Overlaps in the semantic domain of models have been
identi ed as the primary reason of model inconsistencies by
many authors [
A signi cant amount of research has been dedicated to
solving semantic inconsistencies on the syntactic level (for
example [
Finkelstein [
In this paper we present an approach for inconsistency
management in the context of engineering processes.
Potential sources of inconsistencies are identi ed by
considering characteristics of the process model. Management of
inconsistencies is achieved by selecting the appropriate
techniques from a catalogue of management patterns and
applying them on the unmanaged process to achieve a managed
one. Typical patterns include re-ordering activities of a
process, ensuring property checks around inconsistency-prone
regions and using design contracts [
A a formalism (i.e. a language and its semantics) for modeling processes in relation with the properties of the engineered system; B a method for detecting inconsistencies and identifying the most appropriate resolution technique based on quanti ed cost measures; C a prototype tool supporting our approach; and D a case study of a real mechatronic system.
The rest of the paper is organized as follows. In Section 2, we present a motivating case study of an automated guided vehicle. In Section 3 a formalism for modeling processes with properties is presented. In Section 4 we characterize inconsistencies in terms of the previously presented formalism, identify typical inconsistency patterns, provide an initial catalog for managing them and a method for selecting the most appropriate inconsistency management technique for single inconsistencies by multi-objective design space exploration (DSE). Section 5 discusses the prototype tooling supporting our approach. Finally, related approaches are reviewed in Section 7, and Section 8 concludes our paper.
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 speci c trajectory between a set of locations. The drivetrain is fully electrical, using a battery for energy storage and two electric motors driving two wheels. Being a complex mechatronic system, the requirements of the AGV are speci ed by stakeholders of the di erent involved domains, such as (i) mechanical requirements: su cient room on the vehicle to place payload; (ii) control requirements: following the de ned trajectory with a given maximal tracking error; (iii) electrical requirements: autonomous behavior, de ned as the number of times that it needs to be able to perform the movement before needing to recharge; (iv) product quality requirements: the previous requirements should be achieved at a minimal cost.
Figure 2 shows the conceptual geometric design of the AGV. The design team chose a circular platform, with two omniwheels in addition to the two driven wheels. The design process needs to determine the sizing of the different components (motors, battery, platform) and tune the controller. This process is decomposed into multiple dependent design steps, such as motor selection, battery selection, platform-, controller-, and drivetrain design. The process requires an interplay between di erent domain-speci c engineering tools, such as CAD tools for platform design, Simulink and Virtual.Lab Motion for multi-body simulations employed during controller design, AMESim for multiphysical simulations during drivetrain desing. Motor and battery selection activities use databases maintained in Excel les. Since these tools work with di erent modeling formalisms, reasoning over the consistency of the system as a whole properties poses a complex problem to overcome. By explicitly modeling linguistic and ontological properties and associating them with the engineering activities, patterns of inconsistencies can be identi ed and handled.
As a running example, we use a segment of the process in the case study shown in Figure 3. The example highlights how inconsistencies can occur due to properties of the system that interact with activities of an engineering process.
Initially, components of the system, such as the battery, are selected based on approximations and domain expertise. The mass of the initially selected battery is considered during the Mechanical design phase to identify the mass constraints on other parts of the system. After the mechanical design phase, the electrical model is designed in details. This includes identifying the required capacity of the battery by Simulating the electrical model, in order to ful ll the autonomy requirement.
Inconsistencies may arise when the Battery capacity property is changed, because the Battery mass property depends on it: batteries with bigger capacity are typically heavier. As the capacity is changed, the mass becomes inconsistent with the capacity. Should the inconsistency get unnoticed, the engineered system will fail to meet the requirements.
There are two important speci cities to this example that motivate our work.
First, inconsistencies occur due to the lack of explicitly modeled information about how activities access system properties. The key in identifying the above inconsistency is the explicit modeling of the nature of interaction between activities and properties, such as reading or modifying a property. We refer to this information as intents of activities over (a set of) properties.
Second, state-of-the-art techniques typically reason about inconsistencies in terms of linguistic model elements. The dependency between the two properties is, however, not persisted in any of the engineering models as it is an interdomain relationship. To tackle this problem, we allow modeling ontological properties as well, and linking them to activities by intents.
To model engineering processes with su cient semantics for managing inconsistencies, we propose a formalism that augments the process with the syntactic and semantic properties that depict speci cities of the engineered system.
We build our formalism on the Ftg+Pm [
We extend the above formalism by allowing explicit modeling of properties in context of processes and languages. We assume activities of an engineering process have a meaningful purpose of enhancing the system. This purpose is expressed as the intent of an activity with respect to a property or a set of properties. Furthermore, we extend the process model by enabling speci cation of costs of single activities. Modeling costs enables reasoning over the managed process candidates (as shown in Figure 1).
The type system plays an important role in the analysis of complex process models. Typing process objects by languages and linking activities to transformations enables reasoning about the MDE aspects of an engineering process with models and model transformations as rst class artifacts. Additionally, in deployed and enacted process models, the language model serves as a basis for conformance and validity checks. For the sake of conciseness, we refer to the various elements of our formalism with slightly di erent terminology. In our terms, a process model P M consists of a set of processes P (equivalent to the Pm part of an Ftg+Pm) that take a language model LAN G as a type model (equivalent to the FTG part of an Ftg+Pm), and relate to a property model P ROP .
In the following, we elaborate on the speci c parts of this process model. First, we brie y present the foundations of the Ftg+Pm formalism for typed processes; then we extend processes with costs; nally we discuss the property model in details. 3.1
By the process p 2 P , we mean a 4-tuple (A; c; O; o) consisting of a set of activities (A); a set of directed control relations between activities ( c 2 c : A 7! A); a set of objects (O); a set of directed data ow relations between activities and objects ( o 2 o : A 7! O); The control ow is a transitive relation, i.e. 8a1; a2; a3 2 A : c(a1; a2) ^ c(a2; a3) ) c(a1; a3), and the following notation is used a3 2 c+(a1).
The language model consists of modeling languages and transformations, formally: LAN G = (L; T ), and serves as a type system to processes, where languages type process objects and transformations serve as speci cations to activities. In the case study, for example, the models of the mechanical 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 obtaining and executing a nite element simulation model. That is, modelMech 2 O, and typeOf (modelMech) = CAD, where CAD 2 L; additionally, typeOf (aMechDesign) 2 T . 3.2
We extend the de nition of activities by their costs. For the sake of simplicity, we focus on costs constituting ratio scales, i.e. for the cost c of activity a 2 A the following holds: c(a) : a 7! R+:
Costs serve as a basis for quantifying the di erences between various process alternatives. In our current work, we approximate costs by the transition time required for single activities. Non-linear processes, i.e. the ones with directed loops, are typical in engineering scenarios. In these cases, the cost of a process is a non-deterministic value that can be obtained by appropriate simulations. 3.3
By a property model P ROP we mean a tuple ( ; R) consisting of the set of linguistic and semantic properties ; and the set of in uence relationships R between properties.
Properties of the running example in Figure 3 are the Battery mass and Battery capacity, while the dependency between those is a relationship with a direction and a level of precision. In the following, we rst elaborate on properties (Section 3.3.1) and the in uence relationships between them (Section 3.3.2); then we relate properties to processes by formalizing intents (Section 3.3.3); and nally, we provide a typing strategy for properties in terms of the Ftg+Pm formalism (Section 3.3.4). Properties capture qualitative and quantitative characteristics of the modeled system. While linguistic properties represent values of various types, ontological properties capture system characteristics in terms of satisfaction constraints. The way properties are checked, also depends on their types. Checking a linguistic property means evaluating if the actual value of the property is within a range of acceptance criteria; checking an ontological property, on the other hand, means evaluating if the property is satis ed or not. While the former check is typically achieved by well-de ned operators over the algebraic structures of the type of the property (e.g. arithmetic operators over number values), the latter type of checks typically involves simulations or model checking tasks.
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
enables (i) reasoning over these speci cities, and (ii) fosters
communication of tacit knowledge, which is especially
important in the early phases of a multidisciplinary design
process [
Relationships between two properties are present if a change in one property potentially in uences the other. In the case study, properties Battery capacity and Current drawn could be considered two properties with a relationship in between (Figure 5): a change in the Battery capacity will have an impact to the Current drawn and vica versa. A relationship r is formally de ned as r 2 R = ( ij ; nm ; ), i.e.
a set of in uencer (input) properties ij = f i:: j g, a set of in uencee (output) properties nm = f m:: ng, a level of precision
2 fL1; L2; L3g.
The three levels of precision are de ned in our previous work
[
L1: the fact of in uence is known, its extent is not; L2: sensitivity information between two values is known; L3: the relationship can be expressed using an exact mathematical relationship.
Figure 5 shows a pair of properties that mutually in uence each other, albeit on di erent levels of precision. A change in the Current drawn has an L3 in uence on the Battery capacity as follows: BatteryCapacity R CurrentDrawn(t)dt. The relationship in the other direction, however, cannot be determined in such details and thus, only constitutes an L1 relationship. In the running example, the relationship between the Battery mass and Battery capacity constitutes an L2 relationship: increasing the capacity requires increasing the battery mass, although the exact relation cannot be provided as batteries come in various architectures.
Acausality provides compactness in terms of the notation of relationships: it enables modeling of N-ary relationships in a more convenient and readable fashion. Figure 6a shows an N-ary in uence relationship, depicting a simple law of physics: BatteryM ass + M otorM ass = T otalM ass. By assigning value to two of the three properties, the third can be automatically calculated. The same information can be captured in an acuasal way as presented in Figure 6b.
(a) Causal notation of an N-ary relationship.
(b) Acausal notation of the same N-ary relationship. In our approach, we allow using acausal relationships, but translate them to the causal equivalent form when carrying out analyses. Formally, given an acausal in uence relationship r of level over a set of properties 0, the causality assignment maps r = (;; 0; ) onto a set of relationships R0 = h( 00; 000; )i; such that 0 = 00 S 000:
The causal equivalent can be unambiguously determined only in symmetric N-ary relationships, meaning any M number of the N properties determine the remaining N M , e.g. the one in Figure 6. In this case the causal equivalent will consisist of MN causal relationships.
By a change scope of a property we mean a subset of properties potentially a ected by a change in . Given two properties 1 and 2 directly linked by a relationship r( ij ; nm; ), the change set is de ned as follows. j 2 2 ( 1) , ( 1 2 i ^ 2 2 nm) That is, property 2 is in the change scope of property 1 i 1 is an input property and 2 is an output property of an in uence relationship. In the running example, the Battery mass property is in the change scope of Battery capacity.
The change scope is a re exive and transitive relation, i.e. respectively. We use the following notation for the transitive closure of the change scope: 3 2 +( 1). Intents capture the motivation of an activity with respect to a property or a relationship of properties, such as reading and modifying a property. An intent i 2 I is de ned by the tuple (a; s; tI ), where
We de ne four elementary intents for our approach: TI = fread; modif y; check; contractg, the rst two being the typically occurring intents in standard engineering activities, while the latter two are speci c to activities related to inconsistency management.
As discussed in Section 2, the main rationale behind explicitly modeling intents is that they carry valuable information regarding inconsistencies in processes, which enables reasoning about the origin and the potential management of inconsistencies. The inconsistency in the running example is possible to detect because of the exactly modeled pair of the read-modify intents on properties that in uence each other and activities that are control-dependent. In Section 4 we formally characterize inconsistencies in terms of processes, properties and intents. 3.3.4
Intents relate properties to processes. In order to handle property models in a type-safe manner, however, properties and relationships have to be related to the type system dened by the language model as well.
We handle elements of the property model as special process objects that activities interact with. That is, following the de nition of processes in Section 3.1: 8p 2 P 8s 2
[ R : s 2 O(p);
8p 2 P 8i 2 I : i 2
o(p):
Consequently, both properties and relationships are typed
by appropriate languages, e.g. OWL languages [
Intents are typed by an intent language TI , i.e.
8 TI = fi1::ing : TI 2 LAN G: This means the language of intents in our approach can be aligned with the application domain of the problem at hand. The intents used throughout this paper are rather general and capture only access-change information over system properties.
After presenting the process modeling formalism for reasoning over inconsistencies in Section 3, we give a formal characterization of unmanaged cases that may lead to inconsistencies. We associate inconsistencies with changes in properties that are shared among multiple activities. Reasoning over such cases is enabled by explicitly modeled intents of the activities over the properties. To manage inconsistencies, we augment the original process with appropriate management patterns.
In the following, we identify cases when inconsistencies may occur. We formalize this information in terms of pairs of activities, the related properties and intents. Generally, inconsistencies are introduced when an activity modi es a property that is accessed by another activity. A more formal de nition can be given by distinguishing between activities situated in a sequential order and in parallel branches of a process. By sequential and parallel activities we mean 8a1; a2 2 A : seq(a1; a2) , a2 2 8a1; a2 2 A : par(a1; a2) , a2 62 c+(a1); c+(a1) ^ a1 62 c+(a2); respectively. That is, two activities are said to be sequential i one activity is transitively reachable from the other via the control ow of the process. If no such relation exists (in any direction), the activities are said to be parallel. 4.1.1
Given a pair of activities a1; a2 2 A : seq(a1; a2), property is said to be exposed to a potential inconsistency due to insu cient inconsistency management in the following case. where IC denotes the set of unmanaged inconsistencies. That is, property is exposed to a potential inconsistency if activity a1 rst accesses it with a read intent and subsequently activity a2 modif ies property 0, while property is in the change scope of 0. The relation does not hold the other way around, i.e. by rst modifying and subsequently reading a property does not lead to inconsistencies.
As a consequence of the re exivity of the change scope, the above de nition applies on cases where the same property is being read and modi ed as well. The de nition is di erent from the one in the sequential case in not being speci c about the type of intent i1. This is because of the inconclusive ordering of a1 and a2 due to their parallel relation. Since the two activities may access the related properties in any order, the cases of potential inconsistencies cannot be narrowed to a speci c ordering of read-modify intent pairs. That is, inconsistencies may arise if any of the two activities reads property , while the other one modif ies 0.
We use four typical inconsistency management patterns in our approach. This catalogue of patterns is, however, extensible in the prototype tooling. 4.2.1
Reordering and sequencing aim to modify the control ow in order to avoid inconsistencies.
Given a sequential case, i.e. a1; a2 2 A : seq(a1; a2) ) 2 IC, the reordering strategy would swap a1 and a2, i.e. seq(a1; a2) ! seq(a2; a1), to utilize that the appropriate order of read-modify intents does not lead to inconsistencies, as shown in Section 4.1.1.
In parallel cases, i.e. a1; a2 2 A : par(a1; a2) ) 2 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 inexpensive 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. 4.2.2
Property checking is used to ensure no inconsistencies are introduced on speci c sections of the process. A special activity acheck is added to the process that accesses the unmanaged properties with a check intent. If the result of the check is satisfactory, the process continues with the subsequent activities; in the case of a failed check, however, the process would fall back to the latest point where the inconsistency is not yet present and facilitate a re-iteration loop.
The property check pattern is a typically expensive management pattern as it introduces directed loops in the design processes and therefore, makes processes inherently nondeterministic. 4.2.3
In a contract-based approach [
A less rigorous approach to contracts is also possible by making an educated guess about the shared properties. In the parallel case: a1; a2 2 A : par(a1; a2) ) 2 IC, one of the parallel activities makes assumptions about the properties that will be modi ed by the other activity. However, these assumptions need to be checked once the process rejoins both branches. The bene t of the pattern is that only one of the branches has to be re-executed if the assumption proves to be invalid, i.e. an inconsistency may occur. 4.3
Since multiple management patterns can be applied for the same type of inconsistency with varying bene ts, we formalize the process rewriting problem as a constraint solving and optimization problem as follows.
minimize
p subject to cost(p) jICj = 0; v(p) = 1: where v(p) : p 2 P 7! B is the indicator function of the validity (i.e. well-formedness) of a process p. We also demand a fully managed process (jICj = 0). We solve the problem by model transformation based multi-objective design space exploration (DSE) as shown in Figure 7. The exploration mechanism takes the original unmanaged process and the property model as an input and produces an optimal managed process as a series of model transformations applied on the original process. (The property model is left intact as it re ects domain knowledge and as such, typically should not be changed because of a single process.) The exploration process is guided by mandatory constraints and optimality objectives. The purpose of using model transformations is twofold. We use them to augment the process with inconsistency management techniques, but also for rewriting the process into a better performing process. An example for the latter one is parallelizing as many activities as possible. Of course, this will a ect the applicable inconsistency management techniques, and therefore, the execution and evaluation of these transformations must be achieved in a coupled way.
Transformation rules aiming to augment the process with inconsistency management techniques, are derived from the inconsistency patterns (Section 4.1) and management patterns (Section 4.2). A transformation rule is de ned as 9 ic 2 IC : ic(!
P M ) ^
P M )) ! apply(m0(ic(!
P M ))); m0 2 M: That is, if an inconsistency pattern ic is detected on a subset ! of the process model P M , and there is no corresponding management pattern m detected for the same subset of elements, then an appropriate management pattern m0 is applied to the inconsistency.
The overall goal of our approach is to nd better processes, with respect to a goal function, that create correct products. Apart from the transformations speci c to inconsistency management, therefore, we also use transformations that manipulate the structure of processes, such as adding and removing control ow between activities, arranging activities into sequences or parallel branches, etc. There is no restriction on how far the exploration strategy can go in restructuring the process, as it is determined in the exploration phase by considering that every inconsistency has to be managed. By making certain activities parallel, more linguistic and semantic overlap exists at the same instant in the process and thus making the process more vulnerable to inconsistencies.
Note that certain applications of this pattern are not usable. For example, the parallelization of a design activity cannot be parallelized with the subsequent simulation of the created model. 4.3.2
Constraints and objectives are used to guide the exploration process and evaluate the solution candidates. As de ned 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.
We support our approach with a prototype tool that allows (i) modeling processes with the aspects and semantics presented in Section 3; and (ii) augmenting processes with inconsistency management patterns, while identifying the optimal managed process.1 5.1
As a rst step, the initial process has to be modeled along
with the languages and properties. Our tool provides a
graphical modeling environment for this purpose, implemented
using the Sirius framework [
In the next phase the design space exploration is executed
which includes
1The tool is available under the EPL licence at https://
github.com/david-istvan/icm. The detailed case study is
available at https://github.com/david-istvan/agv.
matching the process model against the patterns of the
inconsistency catalogue;
applying patterns of the inconsistency management
catalogue on the process; and
selecting the best tting management pattern based
on cost simulations.
For design space exploration, the VIATRA-DSE framework
[
Patterns of inconsistencies are captured by graph queries
over the input model. In our prototype tool, we use the
VIATRA Query Language (formerly EMF-IncQuery) [
The pattern re ects the left-hand side (LHS) of the general transformation rule in Section 4.3.1. In Line 7, properties p1 2 R+(p2) and activities a2 2 c(a1) accessing the two properties with the respective read and modify intents are identi ed. Subsequently, in Lines 8-9, the number of applied 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 inconsistency management pattern to be applied. 1 pattern unmanagedReadModify ( 2 a1: Activity , p1: Property , a2: Activity , p2 : Property ) 3 { 4 find readModifySharedProperty (a1 , p1 , a2 , p2 ); 5 checks == count find checkProperty (a2 , _, p2 ); 6 contracts == count find contract (_ , a1 , p1 ); 7 check ( checks + contracts ==0); 8 }
Listing 1: The read-modify inconsistency pattern. 5.2.2
Management patterns are captured as model
transformations over the model. In accordance with Section 4.3.1,
the LHS of the transformation rules consist of the
previously de ned inconsistency patterns; while the right-hand
side (RHS) de nes how the speci c inconsistency should be
handled by using one of the management patterns described
in Section 4.2. Allowed LHS-RHS combinations are
specied in terms of VIATRA Model Transformations [
As discussed in Section 3.2, cost of a process is not deterministic in most cases. We support our approach by two types of cost simulations in the prototype tooling. In xed iteration simulations, the loops of the design process are identi ed and simulated with a xed amount of iterations resulting in a process cost as follows 8p 2 P : c(p) =
c(ai)n(ai): i=jA(p)j
X 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
simulations [
After exploring the space of alternative solutions and ranking them based on costs, the managed process is obtained. Figure 10 presents a managed alternative to the running example in Figure 8. As an allow-and-resolve type inconsistency technique, property checking is executed after the location of the potential inconsistency. The manual CheckBatteryMass activity accesses the potentially inconsistent property Battery mass with a check intent. Subsequently, a decision node is added to the control ow to enable a backward loop in case the check fails (NO) and to proceed if the check succeeds (OK ). The pattern also introduces a loop that enables arbitrary re-iterations, which is the main contributor to the increased process cost. As opposed to this, an alternative reusing the technique of contract based design would not require such loops, but the management activity itself would be more elaborate as the contract negotiation phase requires stakeholders from multiple domains.
The real challenge of applying inconsistency management patterns in an orchestrated way, so that their application does not give rise to new unmanaged inconsistencies, is tackled by using a heuristic or exhaustive search through the state space. Applying our approach to the whole process of the case study resulted in a fully managed process with reasonable increase in costs. In our simulations, we measured up to 10% cost reduction while fully managing the process with two types of inconsistencies.
The results described in this paper serve as the
foundations to a comprehensive inconsistency management
framework. The approach, in its current form tackles two
important problems in engineering practice. First, as presented in
the previous sections, combining the notion of processes with
inconsistencies sheds light on complex cases of
inconsistencies that are otherwise not detectable nor manageable.
Second, our approach enables expressing tacit domain
knowledge explicitly and thus making it reusable across di erent
processes (projects), at least partially, which is a typical
concern in companies on CMMI levels 3 and above. [
In the following, we discuss the required extensions to the current work in order to develop an inconsistency management framework. 6.1
As the primary research direction, we will extend the
formalism in Section 3 with more complex cost models and the
notion of resources. In our current approach, cost is a
onedimensional performance metric of the process, estimated
from the development time. In real settings, however, di
erent types of costs may be used to capture the performance of
the process and thus providing a basis for optimization, e.g.
queueing time, delay or processing volume [
The multi-objective nature of our DSE approach
(Section 4.3) scales well with introducing additional dimensions
to the underlying formalism discussed above. A known
limitation of DSE based approaches is, however, the potentially
missed global optimum of the input problem. We plan to
address this limitation by translating the inconsistency
management problem to more complex solution methods, such
as heuristic algorithms [
The current version of the prototype tool supports the
modeling phase of process engineering, but to achieve a
comprehensive inconsistency management framework, the
execution phase (i.e. the design phase of the virtual product)
has to be supported as well. For this purpose, the process
model will be enacted by using model transformations to
provide the operational semantics. The explicitly modeled
formalisms/tools enable automated support for tool
interoperability, with the potentially reusing integration
frameworks such as OSLC [
Inconsistency management is a well-studied topic in the
domains of software engineering, mechatronic design and
cyber-physical systems, due to the typically multi-view and
often multi-paradigm approach to system design. Persson
et al [
Other approaches also acknowledge the role of semantic
techniques in inconsistency management, and try to relate
semantic concepts to the linguistic concepts of modeling.
Hehenberger et al [
Ontologies have been used for inconsistency management
by Kovalenko et al [
As opposed to the above techniques, inconsistency
management in collaborative modeling is more frequently
addressed on the linguistic level. Qamar et al [
In this paper we presented an approach for managing inconsistencies in complex engineering settings from a processoriented view. A modeling formalism has been provided to reason about how inconsistencies arise in processes and how they impact the overall design. For this purpose, the notion of intents has been de ned as the explicitly modeled relationship between activities of processes and properties of the engineered system. We support the automated process of inconsistency management by a prototype tool built on Eclipse technologies. Finally, the approach has been evaluated over a case study of a real mechatronic system using our prototype tool.
The authors wish to thank Andras Szabolcs Nagy for his dedicated help with the VIATRA-DSE engine; Tamas Szabo for his critical and constructive comments; and Kristof Berx for his insights on the case study. This work has been partially carried out within the framework of the Flanders Make project MBSE4Mechatronics (grant nr. 130013) of the agency for Innovation by Science and Technology in Flanders (IWT-Vlaanderen). 9.