## 4 Proof of Concept Implementation
### Comparison Mechanism  
In our study, we considered the systems architecting process. The CESAMES (Center of Excellence on Systems Architecture, Management, Economy, and Strategy) method for systems architecting [36]  
Figure 3: Tool implementation process. considers three different abstraction levels of a system: the operational level, the functional level, and the physical level. The project manager conducts a cross analysis of the activities of the different engineering disciplines and their possible dependencies. They define the purpose of the synchronization process. Then, they identify the activities for each discipline that will be considered in the consistency management process. The chosen activities deal with different concerns at the same level of abstraction. In this paper, the goal of the synchronization process is to ensure consistency at the physical level. Therefore, the project manager chooses the physical architecture models for the analysis (i.e, IBD in SysML), and they consider the physical architecture of the Modelica and Altarica models). Therefore, we guarantee that the entry models of the comparison process are defined at the same level of abstraction. The comparison process can be applicable in our scenario. We use NetworkX [37], which is \"a python 3 package for the creation, manipulation, and study of the structure, dynamics, and functions of complex networks\", as a query engine to demonstrate the comparison process. In the first step, we import the different graphs representing our abstracted models as shown in Listing 1, lines 3-8. Then, we can display the properties of graphs such as the type of graphs (e.g., digraph, multigraph, etc. ), number of nodes, and number of edges in a graph. In addition, we can verify graph isomorphism between abstracted models as represented in Listing 1, lines 10-14. ```
1 importnetworkasnx
2 importmaptipli.pyplotasplt
3g1=nx.MultiGraph()
4g1.name-Modelica_multigraph:
5g2=_name-Null_multigraph()
6g2=_read_gml('SysML_gnph_EMA.gml')
7g2=nx.read_gml('Modelic_graph_EMA.gml')
83=nx.read_gml('Modelic_graph_EMA.gml')
84
85#showgraphsproperties&verifysionparibism
9 print(nx.info(g1))
101#print(s1.has.isomptable(g1,g2)
11#print(s1.has.isomptable(g1,g2)
11#print(s1.has.isomptable(g1,g2)
11#print(s1.has.isomptable(s1,g2)
11#print(s1.has.isomptable(s1,g2)
11#print(somptable(s1,g2)
11#print(som



allows detecting the main correspondences between two graphs. For example, using lines 17-23 of Listing 1, we search for a common subgraph between SysML and Modelica graphs. Lines 26-48 of Listing 1 allow carrying out a consistency check between two abstracted models; i.e., we use Algorithm \"compose\" to return a new graph that composes the two abstracted models. The union shows the common subgraph between the two abstracted models and highlights the nodes and arcs that do not appear in both graphs. Finally, we can conclude the lists of additional nodes and edges in each model considering the common subgraph between every two graphs as shown in Listing 1, lines 51-54. Thereafter, a project manager analyzes the outputs of the comparison process and proposes the appropriate changes to apply in the abstracted models. ### Control and Representation

Within the control and representation layer of our demonstrator, inconsistencies can be managed. Then, the changes can be visualized using a general-purpose diagramming program labeled \"yEd\" [38]. Besides, this layer allows exchanging metadata information between various tools used to implement our methodology. We use the XMI format to exchange metadata between the QVTo language and the yEd tool. We use also the GraphML format to exchange the graph structure data between the yEd tool and the NetworkX language. ## Case Study

In this paper, an Electro-Mechanical Actuator (EMA) is used to better illustrate our methodology. The motivation behind using the EMA system as an example is due to the simplicity of developing the different separate models.