Change propagation analysis for system modeling using semantic web technology

Change propagation analysis for system modeling using semantic web technology Change propagation analysis for system modeling using semantic web technology Change propagation analysis for system modeling using semantic web technology Change propagation analysis for system modeling using semantic web technology Change propagation analysis for system modeling using semantic web technology Change propagation analysis for system modeling using semantic web technology

Advanced Engineering Informatics 35 (2018) 17–29 Contents lists available at ScienceDirect Advanced Engineering Informatics journal homepage: www.elsevier.com/locate/aei Full length article Change propagation analysis for system modeling using Semantic Web technology T ⁎ Haoqi Wanga, , Vincent Thomsonb, Chengtong Tanga a b School of Mechanical Engineering, Beijing Institute of Technology, China Department of Mechanical Engineering, McGill University, Canada A R T I C L E I N F O A B S T R A C T Keywords: Model-based systems engineering System modeling language Engineering change management Change propagation analysis Ontology Semantic Web technology Change propagation potentially affects many aspects of a SysML-based system model during the iterative process of Model-Based Systems Engineering (MBSE) However, few authors have addressed the implication of engineering change and its impact To address having a successful change process, this article analyzes and explicitly represents different scenarios of how a system model is changed from a formal perspective, i.e., how a system model should be changed, and how model elements should be added, deleted or modified in response to design changes A workflow is introduced to guide the change process taking change propagation into account Second, change impact relationships among requirements, behaviors, and structures of the system model are formalized by an ontology to make the semantics both human-understandable and machine-readable Reasoning rules are defined as well in order to improve automation of the change process Finally, an experiment using a water distiller system showed that the identification of change impact information could help designers complete the change in less time and with higher quality Introduction Systems modeling of contemporary products using model-based systems engineering (MBSE) is an iterative process involving representations of multiple views, e.g., requirements, behaviors, and structures The systems modeling language (SysML) is a key enabler in MBSE approaches for creating a system model [1] During the modeling process, system design evolves through many modifications until it is feasible Accordingly, the SysML-based system model, which produces the primary artifacts from a system design, has to be modified frequently A single design change may lead to unexpected effects on other model elements For example, an added requirement to the original system design of a water distiller causes changes to the distiller behavior, decomposition structure and internal structure that are tedious to make [2] So, Engineering Change Management (ECM) of the system model plays a pivotal role for a successful implementation of MBSE As one of the ECM methods, the SysML-based methodology can evaluate change situations arising from system design by representing requirements, behaviors, structures and their relationships in a consistent way [3] However, few authors have addressed the implication of engineering change and its impact or the implication of different approaches to design implementation, such as, technology, modularization and make-or-buy [4] Although allocation relationships in ⁎ SysML are able to enhance the traceability of a system model [5], they are insufficient for specifically describing how change is propagated to impacted model artifacts In practice, it is always time consuming for designers to identify and change impacted model elements manually One reason is that requirements and scenarios are not always fully defined, and thus, design changes require considerable analysis in order to decide upon feasible approaches As a consequence, in order to keep the system model compatible with design changes, designers have to spend most of their time finding which model elements should be changed given how changes are propagated throughout the design and which types of changes should be executed for specific model elements For instance, in order to change the initial system design of a water distiller, more than 60 model elements were required to be added, deleted or modified [2] Accordingly, limited to a formal perspective, not an engineering perspective where changes to detailed design parameters, such as the dimension, weight, and material of components, are taken into account, this paper addresses an approach that should be used for MBSE modeling when reasoning about change propagation To determine this approach we focus on three questions: (1) How can the approach help designers to understand what needs to be changed in the systems modeling process? Corresponding author E-mail addresses: Haoqi.wang@mail.mcgill.ca (H Wang), vince.thomson@mcgill.ca (V Thomson), tangcht@bit.edu.cn (C Tang) https://doi.org/10.1016/j.aei.2017.11.004 Received May 2017; Received in revised form 25 November 2017; Accepted 29 November 2017 1474-0346/ © 2017 Elsevier Ltd All rights reserved Advanced Engineering Informatics 35 (2018) 17–29 H Wang et al (2) If a change happens in a specific SysML diagram, how can the approach help designers know how other related diagrams need to be changed? (3) What procedures can be automated when modifying system engineering models due to change propagation? Table Change impact analysis of a SysML-based system model Approach In order to answer these questions, first, this paper categorizes different scenarios of the SysML modeling change process into three subclasses and establishes a change propagation model Second, the Web Ontology Language (OWL) is used to formalize the change propagation information, based on which reasoning rules are defined to help designers to understand which SysML diagrams and model elements need to be changed, and then, guides them through the tedious process of manually changing SysML models Third, possible automation of the process is investigated Matrix-based approach [9–12] Inconsistency and incompatibility contrast approach [13–16] Analyzing the change workflow [17] Specifying the change situations of system functions, behaviors, and structures [18] In change stage Impact analysis Implementation Yes Yes No No Yes Yes Partially done Partially done Two such studies partially involve change implementation [17,18] Lin et al [17] proposed a workflow to combine change request management with model-driven engineering for industrial automation software In the technical review phase, affected model elements of the change requirements were identified, and a change solution was proposed In the impact analysis phase, processes that guide designers to change SysML models were provided However, several limitations still exist First, the method for identifying impacted model elements is only available for restricted situations where the impact of complex changes to requirements, behaviors, and structures cannot be fully represented by SysML cross-cutting relationships alone In SysML, a cross-cutting relationship is a kind of mapping relationship which can be established between any two model elements There are two types of mapping relationships, ① the intra-domain relationships, i.e., the links between elements within a given domain, and ② the inter-domain relationships, i.e., the links between elements across two domains [5] A cross-cutting relationship is the latter, i.e., an inter-domain relationship Second, besides the existing system model, two more SysML-based models should be created to represent impacted model elements and the corresponding change solution For a system model with large SysML diagrams, this is obviously time-consuming Jiang et al [18] established a function-behavior-structure model of product design history to predict the effect of function change on the final product structures More importantly, what should be changed during the system design is clearly defined However, in contrast with SysML, the function-behavior-structure model covers only partial information of a system model For example, for the structure layer of the function-behavior-structure model, only assembly relationships are described The items, such as signals, energy or data, which flow across different components, are not specified Based on the above analysis, this paper emphasizes the need to improve the SysML model change process itself For enabling designers to understand which SysML diagrams and model elements should be changed, scenarios for each change type and their change propagation information should be specified and formalized Research background 2.1 Previous work about change impact analysis for the system model Existing research on the impact of change on the system model in MBSE can be divided into two classifications One is comprehensive research on using the analytic capability of matrix-based representations The second is research on predicting the change propagation risk by checking the inconsistency and incompatibility of the changed system model The first classification focuses on establishing a Design Structure Matrix (DSM) or a Multiple Domain Matrix based on SysML diagrams, and then, using these matrixes to predict the impact of change [6–12] Matrix-based representations offer magnificent analytic criteria to achieve system understanding [10] Clarkson et al [6] developed a Change Propagation Method using numeric DSMs for the first time Hamraz et al [7] extended the Change Propagation Method by introducing Function-Behavior-Structure models Hamraz et al [8] further detailed the ontology of the Function-Behavior-Structure linkage method to provide a uniform framework for developing models Waldman and Sangal [9] were the first to construct a DSM that unites the various views of SysML models Maisenbacher et al [10] illustrated the translation of SysML diagrams with network structures to their matrix representation as a DSM or Multiple Domain Matrix, so as to identify indirect dependencies in a system model Nonsiri et al [11] proposed a method for identifying the propagation path of changed requirements by integrating a SysML model with a higher order DSM Fei et al [12] developed a matrix-based method to analyze change propagation between components of a product based on functional and structural SysML models The second classification mainly studies checking the inconsistency and incompatibility of changed system designs to predict change propagation risk [13–16] By considering mechanical, software and electrical⧹electronic incompatibility of changed mechatronic systems, an interdisciplinary SysML-based approach, called SysML4Mechatronics, for analyzing change influences was proposed by Kernschmidt and Vogel-Heuser [13] Feldmann et al [14] formalized the incompatible information of the change influences of mechatronic manufacturing systems by integrating systems modeling with semantic technologies Kernschmidt et al [15] extended SysML-based incompatibility checking to the entire system lifecycle Nejati et al [16] suggested how to automatically find out the impact of changes to requirements based on a system design expressed by SysML models through computing reachability through inter-block data flow and intra-block data as well as control flow dependencies However, as listed in Table 1, change impact analysis of a SysMLbased system model, only a few of the works have investigated the change process itself when an engineering change happens, i.e., how the design or system model should be modified, and which model elements should be added or deleted in response to design changes 2.2 Semantic Web technology With regard to the many information representation technologies, Semantic Web technology [19] is being accepted by an increasing number of industries due to its strong semantic and logic expression capabilities Semantic Web technology provides the foundation for the representation of an ontology, which defines specific vocabularies of domain concepts and their semantic relationships [20] According to Zhang et al [23], “the World Wide Web Consortium has contributed much towards standardizing the specification necessary for Semantic Web technology” by introducing the Resource Description Framework (RDF) and the RDF Schema [21] In order to enhance knowledge representation, the World Wide Web Consortium finalized the OWL [22] by extending the expressive power of the Resource Description Framework and the RDF Schema However, there are many semantic relations that cannot be specified explicitly by the OWL ontology 18 Advanced Engineering Informatics 35 (2018) 17–29 H Wang et al Repository SysML based system model Design change process Reasoned impacted elements Changed IBD & BDD System structures Analyze and change the IBD & BDD IB IBD Impacted blocks, ports, interfaces, connectors, partAssociation relationships and their change types are identified Impacted blocks BDD Allocated to Changed Activity Diagram System behaviors Analyze and change the Activity Diagram A i i Diagram Activity Impacted actions, input pins, output pins, item flows and their change types are identified Impacted actions Satisfied by Trace to Changed Requirement Diagram System function requirements Analyze and change the Requirement Diagram Requirement Diagram Impacted function requirements and their change types are identified Original changed FR Fig System model change process showing the proposed approach how the system model should be changed, and which model elements should be added, deleted or modified in response to design changes, such that the designer is guided to change the system model without needing to search for impacted SysML models manually The proposed approach integrates system models with Semantic Web technologies as shown in Fig First, general change scenarios of the SysML model are analyzed and categorized, and a process for changing the system model according to change propagation is established Second, the change propagation information is formalized using the OWL ontology Third, by using predefined SWRL rules, impacted SysML elements can be identified especially in the reasoning process [23] The Semantic Web Rule Language (SWRL) [24] is an OWL-based rule language and it enables users to write rules in regard to OWL concepts so as to give more influential referring capabilities than OWL alone In this paper, OWL is used to formalize concept elements and their semantic relationships for change propagation information SWRL rules are defined to determine impacted model elements that should be changed Approach Fig describes an overview of a general system model change process Different kinds of operations are classified in four rounded rectangles with dotted lines From left to right, first, data from different views, such as functional requirements, behaviors and structures are put into a repository in order to manage the system model Second, different SysML diagrams, like the Requirement Diagram, Activity Diagram, Block Definition Diagram (BDD) and Internal Block Diagram (IBD), are applied to represent the model Third, if the current design does not perform as expected, for example, a new requirement is needed or an existing component should be replaced, the system model is changed as necessary to develop a feasible solution For example, with the change of some functional requirements, impacted behaviors and structures in the system model are changed After the design change process, the result is a set of updated SysML diagrams Fourth, during the change process, how the modeling elements are impacted by the original change is identified in specific diagrams and how to implement the changes is the set of objectives (shaded in Fig 1) for the proposed approach For example, when new actions are added to an activity diagram for realizing a new functional requirement, impacted elements such as actions, output pins, input pins and object flows that need to be deleted, added or modified accordingly in the diagram are identified automatically The proposed approach is expected to infer 3.1 General change scenarios of SysML modeling What deserves illustration before analyzing different change scenarios is that changes in this paper are regarded as indispensable adjustments implemented on SysML diagrams in order to satisfy design change demands rather than changes that occur due to unexpected errors such as using a satisfy relationship to connect a requirement with its derived requirement or creating an output pin for an input flow In the first place, based on design change demands, model artifacts that should be changed directly are specified Changes implemented on any one of these are categorized into three subclasses: addition, deletion or modification Addition The act of adding a model artifact means creating, drawing and putting it into a changed diagram, in which case if the new artifact has relationships with other artifacts, more changes are required For instance, when a new block is created and added to a BDD as a part of an assembly, a composition association should be added as well between the new block and the block representing the assembly As depicted in Fig 3, one of four scenarios occurs when a new model artifact is added Because SysML is a graphical representation language, the added artifact is either a node, e.g., a function, a 19 Advanced Engineering Informatics 35 (2018) 17–29 H Wang et al × General change scenarios of the SysML model are analyzed A process for changing the system model considering change propagation is established Section 3.1 and 3.2 Formal representation of the change propagation model is defined using the OWL ontology × × SSection ti 33.3 3 × Rules for inferring impacted SysML elements are defined Unchanged node Deleted node Unchanged edge Deleted edge Fig Deletion of a model artifact Section 3.4 or edge in a specific diagram When a node is deleted, edges connecting the node with other nodes should also be deleted However, an edge can be deleted without changing related nodes Fig exhibits three kinds of deletion actions An edge is deleted alone in the first scenario A node is deleted by removing its related edge in the second scenario In the third scenario, a node is deleted followed by removing two edges, by which the deleted node is connected to the other two nodes Modification The rearrangement and property change of model artifacts are taken into account as two sub-categories of modification actions: the layout modification and the property modification Fig shows layout modifications where a node is moved to a new place in scenario and where the edge of the modified node is further rearranged in scenario Modifying the property of a node or edge is a property modification, as depicted in scenarios and in Fig For example, items that flow between two blocks can be modified to change material requirements The change can be in part properties to increase performance, or in the service of a standard port to update a software program If a new modeling element is added into a SysML diagram, the layout of the diagram has to be changed For example, the location and size of a new block, which represents a new component, should be modified to ameliorate the readability of the changed diagram Fig Integrate MBSE approach with Semantic Web technology to identify impacted SysML elements requirement or a component, or an edge, e.g., an hierarchical relationship between two components that bridges two nodes So, for simplicity, only two nodes and one edge are used to represent the original diagram Diagrams with more model artifacts can be analyzed by combing the four scenarios As for the first scenario in Fig 3, an independent node is added having no relationship with other artifacts For instance, a shutdown action indicating the termination of all of the actions of a particular activity is a kind of independent node in the activity diagram In the second scenario, an edge is added for linking two nodes A new node with a corresponding edge is added in the third change scenario In the last scenario, a new node is inserted between two nodes when two new edges are added and the original edge is deleted In addition, the complexity of the four addition scenarios increases from the first to the last due to the growing number of impacted artifacts Deletion The act of deleting a model artifact means removing a node Complexity 4 Unchanged node Added node Unchanged edge Added edge Fig Addition of a new model artifact Unchanged node Modified node (property) ( Unchanged edge Modified edge (layout) Modified node (layout) Modified edge (property) Fig Modification of a model artifact 20 Advanced Engineering Informatics 35 (2018) 17–29 H Wang et al in an IBD A process is illustrated in Fig that describes how to change different SysML diagrams in general, according to pre-specified change scenarios when changes are propagated First, the change type is determined Second, the change scenario is selected Third, according to the specific change type and scenario, nodes and edges in the SysML diagram are added, deleted or modified Last, if a change is completed, impacted model artifacts in another SysML diagram are identified through cross-cutting relationships; else, a new round of change procedures for changing the same diagram begins again One of the dominant steps in the SysML diagram change process is the identification of impacted model artifacts in other SysML diagrams using cross-cutting relationships, which is shown in the bottom, shaded textbox in Fig For instance, if a requirement in a specific requirement diagram is deleted, its impacted actions, blocks and related pins, flows, connectors, etc are identified by the ≪trace≫, ≪allocate≫, ≪satisfy≫ and ≪depend≫ relationships in the activity diagram, and the corresponding IBD and BDD are identified and removed as well Fig exhibits this identification and removal process First, by the trace relationship, the activity and its pin and flow in the corresponding activity diagram are identified and deleted Then, based on three allocation relationships, the identified block and part association in the BDD diagram, and the block, port, and connector in the IBD are deleted In addition, impacted model artifacts and modification scenarios can be identified in a similar way Table SysML diagrams, nodes and edges used in a system model Diagram type Nodes Edges Requirement diagrams Requirements Activity diagrams BDDs Actions, pins, parameters Blocks Containment links, derive links Control flows, object flows IBDs Blocks, ports Part associations, generalization links Connectors 3.2 Process for changing the system model with change propagation After specifying different scenarios of how the system model is changed in MBSE, the following section illustrates how a change affects other model artifacts, and then, establishes a workflow to guide the change process taking change propagation into account An original design change is said to propagate when it is reflected in different model artifacts For example, a deleted system functional requirement can result in the deletion of corresponding artifacts that represent system behaviors or structures Change propagation can be recognized by combining the cross-cutting relationships of SysML with the different change scenarios in Section 3.1 In this paper, a SysML requirement diagram is used for expressing system requirements and their relationships; system behavior is modeled by a SysML activity diagram; a SysML BDD and an IBD are used for capturing system structure In different SysML diagrams, the nodes and edges that need to be changed are not regarded in the same way Partial SysML model elements are provided in Table in a requirement diagram where requirements are considered as nodes that are related by containment links and drive links In an activity diagram, actions are defined as nodes, which are connected by flows between their input and output pins In a BDD, nodes are defined as blocks related by part associations and generalization links In an IBD, nodes are items that are exchanged between block ports by connectors In addition, cross-cutting relationships can document mappings among SysML diagrams [2], and those used in the change process of the system model are displayed in Fig A functional requirement in a requirement diagram is satisfied by a block in a BDD and is traced to an activity or action in an activity diagram Actions are allocated to a block in a BDD that executes these actions A pin and connector of an action in an activity diagram are allocated to a port and a connector of a block in an IBD A block in a BDD has a dependency relationship with a block 3.3 Ontology for change propagation information Based on the specification of change scenarios that use a system model and a change process for documenting change propagation, this section formalizes the change propagation information using the OWL ontology 3.3.1 Basic SysML-based system model ontology The basic concept elements of a SysML-based model and element semantic relationships are created first SysML model artifacts include the SysMLDiagram, SysMLNode and SysMLEdge classes As shown in Fig 9, the elements are further categorized according to a SysML specification For example, SysMLEdge that bridges two SysML nodes is classified into the IntraDiagramEdge and InterDiagramEdge classes The IntraDiagramEdge class means edges in the same diagram, whereas the InterDiagramEdge class stands for edges between two different kinds of diagrams BDD, IBD, ActivityDiagram, and RequiementDiagram are subclasses of the SysMLDiagram Trace Requirement Diagram Satisfy BDD Activity Diagram Allocate Depend Allocate IBD Fig Uses of cross-cutting relationships 21 Allocate Advanced Engineering Informatics 35 (2018) 17–29 H Wang et al Determine the change type [type==addition] [type==modification] [type==deletion] [1] Add an independe nt node [2] Add an edge [3] Add a node with an edge Determine the modification scenario Determine the deletion scenario Determine the addition scenario [4] [1] Insert a node Delete an edge [2] Delete a node with an edge [3] Delete a node with two edges [1] Modify the layout of a node [2] Modify the layout of an edge [3] Modify a property of a node [4] Modify a property of an edge [No] Is the change compelte? [Yes] Identify impacted model artifacts in other SysML diagrams using cross-cutting relationships Change another diagram Fig Change process of SysML diagrams Fig A deleted requirement and its propagation identification using cross-cutting relationships Trace × × Requirement Diagram Satisfy Activity Diagram Allocate Allocate Allocate × × BDD Depend × Deleted nodes IBD × × × Deleted edges relationships are described in this section Changed SysML model artifacts are classified into the ChangedNode and ChangedEdge classes as described in Fig 11 Instances of changed model elements can be existing SysML nodes and edges that are documented in the basic SysML-based system model ontology They are associated with specific SysML diagrams by “hasChangedNode” and “hasChangedEdge” object properties, and they are associated with changed nodes or edges by the “belongTo” property Furthermore, the “propagateTo” object property associates a changed model artifact with the original artifact Furthermore, attributes of the change propagation information ontology are represented by data properties, which associate objects with different data types Some of these attributes are illustrated in Fig 12 Besides hierarchical model artifacts, there are other semantic relationships among the artifact concepts, like ‘‘hasRequirement”, “hasBlock”, “allocate” and ‘‘satisfy”, etc According to Zhang et al [23],”semantic relationships are usually defined as object properties of the ontology by means of which retrieval and tracking from one artifact to another artifact within a diagram or between two different diagrams become possible.” Fig 10 exhibits partial semantic relationships among model artifacts 3.3.2 Change propagation information ontology Basic SysML-based system model ontology provides the foundation for the representation of change propagation information Concept elements about SysML change process information and their semantic 22 Advanced Engineering Informatics 35 (2018) 17–29 H Wang et al owl: subClassOf Requirement ActivityDiagram SysMLDiagram Block BDD owl: subClassOf propagateTo objectProperty A ti Action SysMLNode SysMLNode Connector Block OWL: Thing Pin ChangedNode ContainmentLink hasChangedNode ObjectFlow IntraDiagram Edge OWL: Thing DriveLink Generalization AllocateEdge InterDiagram Edge Action belongTo belongTo belongTo IBD Requirement SysMLEdge belongTo Pin RequirementDiagram hasChangedEdge impactDiagram PartAssociation DependentEdge SysMLEdge ChangedEdge SatisfyEdge DriveLink TraceEdge Connector PartAssociation Fig A partial SysML model artifacts hierarchy ObjectFlow owl: subClassOf contain objectProperty propagateTo SysMLDiagram belongTo belongTo belongTo belongTo Fig 11 Some changed SysML model artifacts and their semantic relationships Requirement hasRequirement trace Requirement Diagram BDD hasBlock satisfy owl: subClassOf objectProperty dataProperty datatype isChangedDiagram Boolean isImpactedDiagram Enumeration hasAddScenario Enumeration hasDeleteScenario SysMLNode hasNode Block hasAction SysMLDiagram hasEdge ActivityDiagram Action allocate hasPin partOf SysMLDiagram Pin hasObjectFlow Port hasPort IBD hasConnector hasModifyScenario hasNode SysMLEdge Boolean SysMLNode Connector SysMLEdge ObjectFlow InterDiagramEdge Enumeration hasEdge isImpactedNode allocate Boolean isChangedNode isImpactedEdge isChangedEdge Boolean Boolean Fig 10 Some semantic relationships among SysML model artifacts Boolean Fig 12 Some attributes of changed SysML model artifacts For example, the “hasAddScenario” data property connects a SysML diagram with different additional scenarios as illustrated in Fig by the enumeration, {“add_1”, ”add_2”, “add_3”, “add_4”}; the “isChangedNode” property of a node is “True” when the node in a specific SysML diagram is changed, whereas the “isImpactedNode” property of a node is “True” when the node should be changed due to change propagation The data properties of are exhibited in Table Table Data properties of the change propagation information ontology Data property Domain Range hasAddScenario hasDeleteScenario hasModifyScenario SysMLDiagram SysMLDiagram SysMLDiagram isChangedDiagram isImpactedDiagram isChangedNode isImpactedNode isChangedEdge isImpactedNode shouldBeAdded shouldBeDeleted shouldBeModified SysMLDiagram SysMLDiagram SysMLNode SysMLNode SysMLEdge SysMLEdge {add_1, add_2, add_3, add_4} {delete_1, delete_2, delete_3} {modify_1, modify_2, modify_3, modify_4} Boolean Boolean Boolean Boolean Boolean Boolean Boolean Boolean Boolean 3.4 SWRL rules for inferring impacted model elements The ontology defined above can provide the concept knowledge model for change propagation information of the system model in MBSE In this section, SWRL is used to define rules that can be added to the inference engine for assisting the ontology to complete the reasoning and retrieval of change propagation information Compared to research by Zhang et al [23], inverse relations, mutual exclusion relations, domains and ranges are defined in the same way However, Zhang et al [23] use OWL and SWRL to represent the semantics of design rationale information, such as design issue, solution, argument and artifact In contrast, this paper focuses on change of the propagation information of SysML based system models, such as requirements, behaviors, structures, changed modeling elements and impacted modeling elements First, according to Zhang et al [23], “in addition to part of the builtin OWL relations and properties, the semantics of the user-defined relations and properties need to be explicitly defined by axiom rules”, such as inverse, transitive and disjoint axioms For example, domains and ranges of classes and properties of the ontology are restricted 23 Advanced Engineering Informatics 35 (2018) 17–29 H Wang et al Table Some SWRL rules defined in the change propagation information ontology Rule Description trace(? r,? a) ∧ satisfy(? b,? r) → allocate(? a,? b) contain(? x,? y) ∧ isChangedNode(? x,“true”) → isImpactedNode(? y,“true”) satisfy(? b,? r) ∧ isChangedNode(? r,“true”) → isImpactedNode(? b,“true”) satisfy(? b,? r) ∧ isChangedNode(? r,“true”) ∧ isImpactedNode(? b,“true”) → propagateTo(? r,? b) hasAction(? x,? a) ∧ hasBlock(? y,? b) ∧ allocate(? a,? b) ∧ isChangedNode(? x,“true”) ∧isChangeDiagram(? x,“true”) → isImpactedDiagram(? b,“true”) hasEdge(? d,? e) ∧ hasDeleteScenario(? d,delete1) → shouldBeDeleted(? e,“true”) hasNode(? d,? n) ∧ withEdge(? n,? e) ∧ shouldBeModified(? n,“true”) → shouldBeModified(? e,“true”) Traceability is complemented by semantic relationships A changed requirement impacts its sub-requirements A model element is impacted by a changed and related model element Change is propagated from a changed model element to an impacted model element A diagram is changed due to changes of model elements in other diagrams Change type of a model element is tested by the change scenario in its SysML diagram A model element should be changed when there is a changed and related model element “propagateTo” and “impactedBy” properties are used to represent the semantic relationships when a change is propagated from a model element to another model element where a model element is impacted by a changed one So, the two object properties are mutually inverse and can be defined as: are given in Table In addition, the rules are constructed from three perspectives (1) Reinforcing the semantics of the SysML cross-cutting relationships (2) Improving the semantic relationships from changed model elements to impacted model elements (3) Identifying the change type and scenario of model elements that reflect change propagation propagateTo(? x,? y) = impactedBy(? y,? x) InterDiagramEdge and IntraDiagramEdge classes are distinct from each other where a SysML edge crosses two diagrams or is within a diagram, respectively Therefore, relationships between the two classes can be defined as: Demonstration 4.1 Design of a water distiller system and problems when changing it InterDiagramEdge(? x) ∧IntraDiagramEdge(? x) = Φ The design of a water distiller system is used in this section to demonstrate the proposed approach The International Council on Systems Engineering (INCOSE) originally developed the example for the initial evaluation of SysML The MBSE method used for specifying the system includes six iterative steps [2]: (1) organize the model, (2) capture requirements, (3) analyze model behavior, (4) analyze model structure, (5) analyze performance of the current design, and (6) change the design based on change demands After the first four steps, the initial system model is created by SysML, as displayed in Fig 13 In step (5), a problem is recognized after analyzing the performance of the current design: The boiler will overflow because there is no place for all the water used for condensing the steam to go Therefore, the design is not feasible and requires change In step (6), the system requirement (Distiller Requirement), behavior (Distill Water), decomposition structure (Distiller Breakdown) and internal structure (Distiller Internal Structure) are changed to address the initial design according to the change demand, i.e., provide enough space to store water so that the system does not overflow However, during the change process, designers have to determine manually which model elements should be changed and what impact change propagation has on other model elements in related diagrams Fig 14 exhibits changed SysML diagrams, change types and the number of added, deleted and modified elements in step (6) In a practical change case, although the initial demand is just to add a new requirement in the requirement diagram, its impact is huge, which makes the work long and tedious As a result, it is hard for a designer not to make mistakes like forgetting to delete a model element impacted by a change or adding model elements in an irrelevant diagram Second, according to existing relationships, new relationships are able to be reasoned through a set of rules When certain conditions are satisfied, a new relationship can be derived by automatic reference For instance, the following shows some of the existing relationships: • hasNode(? d,? n): The instance d of the SysMLDiagram class has an instance n in the SysMLNode class; • hasDeleteScenario(? d,“delete2”): The deletion scenario of the SysML diagram d is “delete_2” • isChangedNode(? n,“true”): The instance n of SysMLNode class is a changed node; The change type of a node can be addition, deletion or modification The “shouldBeDeleted” property is employed to test whether a node should be removed from a specific diagram In order to become a deleted node, two conditions should be satisfied: • The node should be a changed node • The diagram in which the node is deleted should contain a certain deletion scenario Therefore, the shouldBeDeleted(? n,“true”) relation can be defined as: hasNode(? d,? n) ∧hasDeleteScenario(? d,“delete2”) → shouldBeDeleted(? n,“true”) As a deleted node must be a changed node, a new rule is obtained and can be defined as: 4.2 Using the ontology and rules to improve the change process shouldBeDeleted(? n,“true”) → isChangedNode(? n,“true”) In order to improve the efficiency of the change process, information about the system model is documented in the change propagation ontology, and rules are executed to help modelers identify impacted model elements with change types Protégé (http://protege.stanford.edu) and the Drools rule engine that supports the execution of SWRL rules in Protégé are used for Last, a change propagation rule library is established so as to execute semantic reasoning These rules are formalized through SWRL and added into the inference engine, such as the Drools Some example rules 24 Advanced Engineering Informatics 35 (2018) 17–29 H Wang et al Fig 13 Initial system model and relationships among diagrams [2] Number of changed elements Drools rule engine Addition Deletion Modification 16 15 OWL+SWRL->Drools Protégé ontology editor 11 10 9 Change propagation ontology Distiller Requirement (Req) Distiller Internal Structure (IBD) rules (SWRL) Distill Water (Act) Drools->OWL Distiller Breakdown (BDD) Fig 15 Reasoning framework using the Protégé and Drools rule engine Changed SysML Diagram (Boiler) Based on Section 3.2, the change type is an addition and the addition scenario is “add_2”, which is created as properties of the corresponding model elements Second, the impact of the requirement change is specified and identified through running the reasoning engine The result (Table 5) conveys that the impacted diagram is the Distill Water activity diagram, and the impacted elements are the Condense Steam, Heat Water and Boil Water actions, their pins and the object flow between them The next step is to change the activity diagram In order to meet new requirement S6.0, an action called Divert Feed should be added The change process includes deleting object flow between the Heat Water and Boil Water actions, inserting the new action, adding corresponding pins and new object flows, and modifying their layout Therefore, three types of change are involved The change scenarios are “delete_1”, “modify_1”, “modify_2” and “add_2” Rules are executed The result in Table shows that the impacted diagrams are the Distiller Breakdown Structure BDD and Distill Internal Structure IBD In the BDD, the distiller block is impacted; in the IBD, the “shouldBeDeleted” property of Fig 14 Changed model elements in each SysML diagram modeling the ontology and processing the reasoning Fig 15 conveys a graphical view of the reasoning framework, illustrating the relationships between the change propagation information ontology and the rules Information of the SysML-based system model is documented as individuals, properties and axioms of the OWL ontology by the Protégé ontology editor (Fig 16) Corresponding SWRL rules and appropriate OWL knowledge are transferred to the Drools rule engine, which runs, and then, passes the inferred knowledge back to Protégé Distiller system requirements are changed first A new requirement named S6.0 (Provide Space) should be added in the requirement diagram It is derived from requirement S2.0 (Heat Exchanger) and S3.0 25 Advanced Engineering Informatics 35 (2018) 17–29 H Wang et al Fig 16 Partial ontology of the distiller system requirements In the same way, the BDD and IBD can be changed with the help of the reasoning capability Due to the paper’s limited space, the detailed change is not discussed The identified impacted elements and change types are listed in Table However, the shouldBeAdded properties that are in italics in Table are identified manually not automatically, because there is no way to extract semantic information from uncreated model elements The reason is that, for the system to identify a necessary addition, any added scenario due to changed model elements would have to be specified in advance For instance, when a block representing a new component is added in a specific IBD, the addition of input or output pins needs to be identified based on the semantics of the scenario; therefore, the addition of the new component cannot be identified automatically Table Partially identified impact from the requirement change Reasoned property Domain Range isChangedDiagram isImpactedDiaram impactDiagram propagateTo propagateTo propagateTo shouldBeModified shouldBeModified Distiller_System_Requirements Distill_ Water Distiller_System_Requirements S6.0 (requirement) S6.0 (requirement) S6.0 (requirement) S6.0 (requirement) derive_S2.0 (deriveLink) true true Distill_ Water Condense_Steam Heat_Water Boil_Water true true interface main2: H2O between the condenser and evaporator blocks is “true” due to the change propagated from the deletion in the activity diagram, and the impacted blocks “shouldBeMmodified The change process enables designers to understand that adding a new requirement, S6.0 Provide Space in the requirement diagram, requires adding a new action named Divert Feed and deleting the corresponding flow in the activity diagram, such as the H2O stream between the Heat Water action and the Boil Water action 4.3 Discussion In the design of the water distiller system, SysML diagrams, model elements, changed information, their semantic relations and properties are explicitly represented and documented based on the ontology More significantly, according to the general process of changing the system Table Some identified impacts from the change behavior Reasoned property Domain Range isChangedDiagram isImpactedDiagram impactDiagram propagateTo shouldBeModified isImpactedDiaram impactDiagram propagateTo shouldBeDeleted propagateTo propagateTo shouldBeModifed shouldBeModified Distill_Water Distiller_Decomposition_Structure Distill_Water (activity diagram) Heat_Water (action) evaporator (block) Distill_Internal_Structure Distill_Water (activity diagram) of2 (object flow) main2: H2O (interface) Heat_Water (action) Heat_Water (action) distiller (block) condenser (block) true true Distiller_Breakdown_Structure distiller (block) true true Distill_Internal_Structure main2: H2O true condenser (block) evaporator (block) true true 26 Advanced Engineering Informatics 35 (2018) 17–29 H Wang et al Table Some identified impacts on the system structure Reasoned property Domain Range isChangedDiagram isImpactedDiaram ImpactedDiaram shouldBeAdded shouldBeAdded shouldBeAdded shoudlBeModified shoudlBeModified shoudlBeModified Distiller_Decomposition_Structure Distill_Internal_Structure Distiller_Decomposition_Structure Tee_Fitting (block) compose_feed (PartAssociation) compose_splitter (PartAssociation) Tee_Fitting compose_feed compose_splitter true true Distill_Internal_Structure true true true true true true quality Although model deletions and modifications due to change can be automatically determined, additions cannot be identified since it is impossible to extract semantic information from uncreated model elements Moreover, the time taken to create ontology instances and execute SWRL rules during the change process was not considered In addition, although the identification of the impact of change propagation can be automated during the change process, designers criticize the intensive manual work required for building the ontology In reality, they are unwilling to spend so much time to re-enter information into an existing SysML-based system model Therefore, how to automatically translate the information from SysML models into semantic relationships in ontologies is a challenge that should be resolved in future work model and rules for change propagation, impacted SysML diagrams, model elements, and change types can be identified To assess the practical usability of the proposed method, four students were asked to participate in an experiment about the change process (step (6)) of the initial distiller system design The participants were introduced to the distiller example and SysML through presentations where the task was explained They were then asked to complete the change task without intervention from the authors The experiment was set up as follows: (1) Selecting the tool: The SysML modeling tool Papyrus [25] was used It is an industrial-grade open source MBSE tool and provides a complete support for SysML (2) Specifying the problem and task: The initial SysML model of the distiller system was provided, as displayed in Fig 13 The problem with the current design, change demand and task was explained clearly to every participant (3) Selecting the assessment criteria: Change completion time and quality were the evaluation criteria However, change completion time was a coarse criterion because different students worked with different efficiency So, change quality was used as another criterion, where the higher quality change process was the one with a higher number of changed elements compared to the number of elements that could be changed (Fig 14) (4) Grouping the participants: Participants were divided into two groups, A and B Students in group A were required to change the SysML model using the SysML modeling tool, whereas group B changed the model using the modeling tool and the identified change propagation information that was provided by an Excel document Conclusions and future work In the iterative process of MBSE, the SysML-based system model needs to be modified frequently to meet changing demands To implement a change process effectively, it is necessary to understand the impact of change and to account for propagation effects However, it is tedious for designers to identify and change impacted model elements manually Few studies have investigated the change process itself in order to understand what design elements need to be changed and how to automate the change process This paper addresses the use of its proposed change process and workflow by answering three questions: (1) How can the approach help designers to understand what needs to be changed in the systems modeling process? This article has explicitly described different scenarios of how the system model undergoes a change and how other model elements are impacted A workflow was introduced to guide the change process (2) If a change happens in a specific SysML diagram, how can the approach help designers know how other related diagrams need to be changed? The change propagation information was formalized by an ontology to make the semantics of the change process to be human-understandable and machine-readable (3) What procedures could be automated when modifying system engineering models due to change propagation? SWRL rules were defined based on an ontology for determining impacted model elements due to the original change An approach was given that could be used to automate finding the changes and modifying the appropriate SysML diagrams, as illustrated in Figs and The time taken and required model elements changed by both groups were used to evaluate the change impact inference approach They are plotted in Fig 17, where black bars show the number of required changed model elements in each SysML diagram (Fig 14), white bars convey the number of changed model elements, and the bars with transverse lines describe the time used by each participant Additionally, the efficiency of change is calculated using Eq (1) where Ni denotes the number of changed elements in a specific diagram, and T is the time used to complete the change n ⎛ ⎞ EoC = ⎜∑ Ni ⎟ ⎝ i= ⎠ T (1) Fig 17 shows that the time taken by the two members of Group B (113 and 119 min) is lower than that for the members of Group A (155 and 150 min) Moreover, the efficiency of change of Group B, 0.546, is 43% higher than that of Group A, 0.381 Although students in Group B were given the change propagation information, a few of the changes in the system structure were overlooked due to carelessness, which could have been avoided Nevertheless, the results of the study confirm that when using the change impact inference approach, modelers can change the system model in less time and with higher An experiment using a change to the design of a water distiller system suggested that the approach was helpful However, two limitations still remain Limitation 1: The scope is limited to a formal perspective, i.e., how the system model should be changed, and which model elements should be added, deleted or modified in response to design changes Changes to particular design parameters like weight and length are not taken 27 20 100 16 14 1211 10 50 EoC 30 16 27 10 0.407 140 29 150 140 27 20 100 1616 12 10 10 50 4 Req A Act ct IBD BDD Time (a) Group A-participant Act ct IBD BDD Time Req A (b) Group A-participant EoC 30 16 28 11 0.522 113 150 29 28 113 20 100 16 16 12 11 10 Number of changed elements 4 50 EoC 30 14 28 12 0.571 119 150 29 28 119 20 100 16 10 14 Time taken (minutes) 26 Number of changed elements 155 150 29 Time taken (minutes) 30 Time taken (minutes) Number of changed elements Number of changed elements 14 26 11 0.355 155 EoC Time taken (minutes) Advanced Engineering Informatics 35 (2018) 17–29 H Wang et al 1212 50 4 44 Req q Actt IBD BDD D Time (c) Group B-participant Req Act Act IBD BDD Time (d) Group B-participant Fig 17 Time taken and number of changed elements by the two groups References into account Limitation 2: The semantics of an added element can only be identified manually Otherwise, added elements would need to be determined in advance which is not feasible Three opportunities for further research are suggested One direction would be to automate the translation from the SysML model into ontologies The second one is to use the identified change information to help sequence the change process, avoiding unnecessary rework Another direction for further work would be to estimate system complexity based on the change effort between different solutions [1] J.A Estefan, Survey of model-based systems engineering (MBSE) methodologies, Incose MBSE Focus Group 25 (8) (2007) 1–12 [2] S Friedenthal, A Moore, R Steiner, A Practical Guide to SysML, Elsevier Science, St Louis, 2011, pp 393–427 [3] I Ullah, D Tang, L Yin, Engineering product and process design changes: a literature overview, Proc CIRP 56 (2016) 25–33, http://dx.doi.org/10.1016/j.procir 2016.10.010 [4] B Hamraz, N.H.M Caldwell, P.J Clarkson, A holistic categorization framework for literature on engineering change management, Syst Eng 16 (4) (2013) 473–505, http://dx.doi.org/10.1002/sys.21244 [5] D Lenny, C 12: Allocation: Cross-cutting Relationships, SysML Distilled – A Brief Guide to the Systems Modeling Language, Addison-Wesley Professional Publisher, Boston, 2013 [6] P.J Clarkson, C Simons, C Eckert, Predicting change propagation in complex design, J Mech Des 126 (5) (2004) 788–797, http://dx.doi.org/10.1115/1.1765117 [7] B Hamraz, N.H.M Caldwell, P.J Clarkson, A multidomain engineering change propagation model to support uncertainty reduction and risk management in design, J Mech Des 134(10) (2012) 1–14 (Paper No 100905) 10.1115/1.4007397 [8] B Hamraz, N.H.M Caldwell, T.W Ridgman, et al., FBS Linkage ontology and Acknowledgment This work is funded by the International Graduate Exchange Program of the Beijing Institute of Technology 28 Advanced Engineering Informatics 35 (2018) 17–29 H Wang et al [9] [10] [11] [12] [13] [14] [15] [16] technique to support engineering change management, Res Eng Des 26 (1) (2015) 3–35, http://dx.doi.org/10.1007/s00163-014-0181-9 F Waldman, N Sangal, Uniting systems modeling approaches with DSMs, in: DSM 2008: Proceedings of the 10th International DSM Conference, Stockholm, Sweden, 2008 S Maisenbacher, K Kernschmidt, D Kasperek, et al., Using DSM and MDM methodologies to analyze structural SysML models, in: Industrial Engineering and Engineering Management (IEEM), 2013 IEEE International Conference, IEEE, 2013, pp 351–355 10.1109/IEEM.2013.6962432 S Nonsiri, E Coatanea, M Bakhouya, et al., Model-based approach for change propagation analysis in requirements, in: Systems Conference (SysCon), 2013 IEEE International, IEEE, 2013, pp 497–503 10.1109/SysCon.2013.6549928 G Fei, J Gao, O Owodunni, et al., A method for engineering design change analysis using system modelling and knowledge management techniques, Int J Comput Integr Manuf 24 (6) (2011) 535–555, http://dx.doi.org/10.1080/0951192X.2011 562544 K Kernschmidt, B Vogel-Heuser, An interdisciplinary SysML based modeling approach for analyzing change influences in production plants to support the engineering, in: Automation Science and Engineering (CASE), 2013 IEEE International Conference, IEEE, 2013, pp 1113–1118 10.1109/CoASE.2013.6654030 S Feldmann, K Kernschmidt, B Vogel-Heuser, Combining a SysML-based modeling approach and semantic technologies for analyzing change influences in manufacturing plant models, Proc CIRP 17 (2014) 451–456, http://dx.doi.org/10.1016/ j.procir.2014.01.140 K Kernschmidt, F Behncke, N Chucholowski, et al., An integrated approach to analyze change-situations in the development of production systems, Proc CIRP 17 (2014) 148–153, http://dx.doi.org/10.1016/j.procir.2014.01.081 S Nejati, M Sabetzadeh, C Arora, et al., Automated change impact analysis [17] [18] [19] [20] [21] [22] [23] [24] [25] 29 between SysML models of requirements and design, in: Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering, ACM, 2016, pp 242–253 10.1145/2950290.2950293 H.Y Lin, S Sierla, N Papakonstantinou, et al., Change request management in model-driven engineering of industrial automation software, in: 2015, Industrial Informatics (INDIN), 2015 IEEE 13th International Conference, 2015, pp 1186–1191 10.1109/INDIN.2015.7281904 S Jiang, J Li, Z Mao, Research on the propagation path of function change in product conceptual design, Adv Mech Eng (10) (2016) 1–15, http://dx.doi.org/ 10.1177/1687814016675998 G Antonio, V Harmelen, A Semantic Web Primer, The MIT Press, Massachusetts, 2004 T.R Gruber, A translation approach to portable ontology specifications, Knowl Acquis (2) (1993) 199–220 B McBride, The resource description framework (RDF) and its vocabulary description language RDFS, in: Handbook on Ontologies, Springer Berlin Heidelberg Publisher, 2004, pp 51–65 K Michael, W Chris, L Deborah, Owl Web Ontology Language Guide, W3C Recommendation, W3C (February 2004), 2004 Available: < https://www.w3.org/ TR/owl-guide/ > Y Zhang, X Luo, J Li, et al., A semantic representation model for design rationale of products, Adv Eng Infor 27 (1) (2013) 13–26, http://dx.doi.org/10.1016/j.aei 2012.10.005 I Horrocks, P.F Patel-Schneider, H Boley, et al., SWRL: A Semantic Web Rule Language Combining OWL and RuleML, W3C Member Submission, 21, 2004 (Paper No 79) Papyrus Web Page Available at: < http://www.eclipse.org/modeling/mdt/ papyrus/ > ... for change propagation information Based on the specification of change scenarios that use a system model and a change process for documenting change propagation, this section formalizes the change. .. scenarios for each change type and their change propagation information should be specified and formalized Research background 2.1 Previous work about change impact analysis for the system model... the SysML modeling change process into three subclasses and establishes a change propagation model Second, the Web Ontology Language (OWL) is used to formalize the change propagation information,