## 4 Proof of Concept Implementation
### Comparison Mechanism
For instance, the angle sensor is defined as classes in the Modelica and Altarica models but it is specified via a connection in SysML model. Figure 8: Comparing Modelica and Altarica abstracted models to SysML abstracted model (Red nodes = common nodes, grey nodes = different nodes, blue edges = Modelica or Altarica specific edges, and green edges = SysML specific edges): (**a**) SysML/Modelica comparison and (**b**) SysML/Altarica comparison. * **The omission of essential elements in system design** The inconsistency can result from human errors, miscommunication between designers, or misunderstood assumptions that can lead to a misconception of the system elements. For instance, the angle sensor is replaced by a connection in SysML model. This connection defines the motor position which can cause miscommunication between engineers since the angle sensor gives the ECU unit feedback on the measured angle at the bsNA output. Then, the project manager suggests a list of changes to be performed in various abstracted models (i.e., the changes will be conducted on elements represented in red shown in Figure 7). #### 5.2.3. Concretization

The updated graphs are implemented in the Eclipse platform as discussed in Section 4 to update entry models using model transformation techniques. The updated graphs are exported from yEd tool to Elipse platform using the XMI format. Then, the project manager implements a code that executes the transformation rules (i.e., indirect transformation rules). Thereafter, they obtain three textual XMI files that represent the updated models based on the concepts of each language. Then, each engineer collects the appropriate XMI file that corresponds to their language and imports it into their proper tool. For example, the systems engineer retrieves an XMI file of their SysML model that contains the corrections proposed by the project manager. They import the XMI file in the Magicdraw tool (SysML tool). As a result, they obtains the IBD model represented in Figure 4:0 In this paper, we only represent the IBD updated model (Figure 9) to illustrate the implementation of the concretization process for saving space. ## 6 Discussion

In this section, we will conduct a discussion of the main contributions of our method compared to the methods of literature. The first improvement of our approach compared to the integration approach and the model federative approach is to be able to support specific modeling language for each domain. The existing model transformation approaches are criticized since there is an epistemic gap between pragmatic models (e.g., SysML) and formal models (e.g., Modelica and Altarica). This make the transformation not fully automatic from pragmatic models to formal ones. Furthermore, implied explicit knowledge in target models can lead to disappointing results where the source models are blurred and overloaded and the generated formal models are incomplete and uselessly complex. Also, the method proposed by [PERSON] et al. [9] did not ensure consistency management since the method considers orienting relations encoded in the transformation rules. The method allowed a SysML

Figure 4:1 SysML_IBD updated model. model to be transformed into Modelica and EPLAN (i.e., to capture the hydraulic schematics) models. However, a change in Modelica or EPLAN models cannot automatically be detected and transformed back into SysML model since the transformation rules consider unidirectional model transformation. To solve that, our approach consists on transforming all our domain-specific models into a common and understandable formalism that reduces the number and complexity of transformation rules used. The inconsistency management approach relies on either proof-theoretic concepts, rule definitions, or synchronization process based on model transformations. The methodology proposed by [PERSON] et al. [25] faces the challenge of having to transform between different formal systems (i.e., models).