Inconsistency management in heterogeneous engineering data in intralogistics based on coupled metamodels

1 Challenges in ensuring model consistency during the development of intralogistics systems

Intralogistics systems (ILS) play a vital role in ensuring the successful satisfaction of customer demands within production companies. The term intralogistics system refers to the internal material flow system of a company or factory, such as the transportation of goods during the production process [1]. Rapidly changing product portfolios, demand fluctuations, and alterations in supply chains require high flexibility of these systems, which means, e.g., re-assembling conveyor units to realize different material flow layouts according to changing requirements and capabilities for the adaption to different types of handling units. At the same time, they must satisfy throughput demands while being highly reliable [2]. Thus, developing successful ILS is a challenging task that incorporates experts from various engineering domains, e.g., mechanical engineering, electrical engineering, software development, or simulation engineering. Every expert works with domain-specific development tools, i.e., software tools that generate highly diverse model files. Contradictions between the information described in these models (subsequently referred to as inconsistencies) might be difficult to discover during the ILS development phase, but they can cause significant delays during the assembly, commissioning, and operation of the system. It is thus necessary to identify inconsistencies in the different models before the physical product is generated, which is a challenging task [3].

Recently, a study has been conducted to identify domain-specific views on ILS and the main causes of model inconsistencies in practice [4]. In the study, experts involved in different stages of the development process have assessed current practices and challenges in ILS development. The study results show that model inconsistencies occurring in the design phase are mostly caused by insufficient communications between stakeholders, especially when changing system requirements. Thus, improving the efficiency of data exchange between disciplines is highly demanded. In addition, the study reveals that most inconsistencies among model data are assessed manually, and no generic checking process exists in reality. Therefore, the quality and reliability of the results depend heavily on human experience and are oftentimes difficult to guarantee.

To overcome the challenges mentioned above, this paper addresses the following research question: How can discipline-specific models, which are created during the development of ILS, be automatically linked to detect potential information inconsistencies within and between these models? To answer this question, the approach is derived using insights from previously conducted expert interviews [4], takes formalized domain knowledge into account, and is evaluated using a prototypical implementation and a lab-sized use case. Contradictions between the different engineering views are automatically discovered by comparing the overlapping information contained in their models. To this end, the domain-specific formulation of model data is transformed so that a cross-discipline comparison can be executed.

As part of a production system, the ILS development poses similar challenges, requirements, and boundary conditions as the development of the general production systems. For example, both developments are interdisciplinary, requiring the participation and collaboration of different stakeholders who express different views of the system with discipline-specific models. In addition, both pursue small batch sizes to realize customized production in loosely coupled, discrete processes. Moreover, compared to other sub-systems in factory automation, ILS exhibit a high degree of modularity in both hardware and software, which results in clearly defined interfaces and high reusability [5], and is reflected, e.g., in the mechanical layout as well as in the control software. Meanwhile, the domain knowledge that needs to be considered to identify inconsistencies is relatively limited. These characteristics make ILS a good starting point for investigating the inconsistency management approach in the production domain.

The remainder of the paper is structured as follows: Section 2 elaborates on five requirements for identifying model inconsistencies during ILS development, followed by the introduction of preliminaries and relevant research in this area in Section 3. In Section 4, the proposed concept is described in detail, which is prototypically implemented and evaluated in Section 5 with three concrete inconsistency cases to assess the fulfillment of the requirements. In the end, a summary and an outlook on future research directions are provided in Section 6.

2 Requirements for identifying model information inconsistencies in intralogistics systems

Due to the challenges in keeping the information in different development models consistent during the design of ILS, the following requirements need to be fulfilled by a systematic and comprehensive inconsistency management approach.

Firstly, as mentioned above, during the development of ILS, engineers with different professional backgrounds are involved, who model the same system from discipline-specific perspectives using different modeling tools (software) [6]. For example, simulation engineers use simulation tools to forecast the dynamic performance of a logistics system, while automation engineers develop the Programmable Logic Controller (PLC) code to control different actuators and to implement the desired process control. Therefore, the resulting heterogeneity of the applied engineering models that express discipline-specific views on the system should be handled by the inconsistency management approach (R1: heterogeneous models).

Second, during the development phases, different types of inconsistencies may occur within and across engineering models. Due to the high time pressure, engineers may introduce inconsistencies within one model when changes are performed on short notice at a late stage of the development workflow or when copy-paste-modify is used to speed up the development process [7]. Additional inconsistencies result from overlapping model information, meaning that the same information about the system under development is contained in two different models [6]. These can be equivalent information, that is, when two values within two different models need to be the same, or the values may be dependent on each other [8]. Since developers from different disciplines work with their discipline-specific modeling tools, they are not always aware of these content-wise overlaps. Both types of inconsistencies are potential sources of errors during the integration of system functionalities and, thus, need to be detected by an inconsistency management approach as early as possible (R2: various types of inconsistencies).

For identifying different inconsistency types within, but especially across different development models, the content-wise overlap and dependencies between the different discipline-specific models need to be made explicit. However, due to the diversity and discipline-specific nature of the engineering models created, it is a time-consuming task to define relations among model information manually and, thus, not feasible to repeat for each specific ILS. Moreover, due to changing requirements during the development of a specific ILS, the respective models are updated frequently, which would require updating the relations. Therefore, automatic and dynamic coupling of project-specific models is essential to improve the efficiency of the inconsistency management approach (R3: automatic model coupling).

Based on the pre-study [4], most inconsistencies are assessed by experienced engineers in their respective disciplines. Thus, the accuracy of the checking results relies heavily on engineers’ experience, including their awareness and understanding of standards and guidelines. This is called domain knowledge in the following. Therefore, to check the conformance of model information with domain knowledge, supplementary information from these sources should also be incorporated. Formalized domain knowledge also serves as a basis for defining reusable inconsistency queries, since some of them are caused by a lack of experience or awareness of domain standards (R4: knowledge formalization).

Ensuring the industrial applicability of the approach can be considered from three perspectives: reusability, extensibility, and tool support. First, to reduce the efforts of adapting the concept to industrial applications, most parts of the concept should be reusable. Besides, considering the increasing complexity of ILS and the diversity of modeling tools applied in engineering activities, the concept and resulting prototypical implementation should be extensible to further integrate models from other disciplines. In addition, engineers involved in the ILS development should be assisted with tool support to define and identify multi-types of model inconsistencies (R5: industrial applicability).

3 Preliminaries and state of the art in model inconsistency management

Subsection 3.1 provides a brief overview of Model-based Engineering (MBE) and Semantic Web Technologies (SWT). Next, apart from the underlying approaches (V-SUMM, SUMM), Subsection 3.2 focuses on the current state-of-the-art in model inconsistency management approaches in the domain of factory automation (discrete processes), limited to linked model approaches that follow the similar principle to V-SUMM.

4 Concept for automatic inconsistency identification based on coupled metamodels

The concept aims to automatically identify inconsistencies within and between development models applied in the intralogistics domain and to support engineers in resolving the identified issues. The developed concept is depicted in Figure 1 and consists of two main parts: a client module (CM) for information extraction and user interaction and an inconsistency checking module (ICM) for information modeling, storage, and inconsistency query.

Figure 1:

Overview of the concept for automatic inconsistency checking of model data in ILS.

The ICM contains a database to store the extracted model information, their metamodels, known dependencies between (meta-)model elements, and formalized knowledge from the intralogistics domain, which should be considered to identify inconsistencies. Since the database contains not only model-related data but also formalized knowledge embedded in metamodels and domain standards, it is called the knowledge base in the following. Based on the concept of model coupling proposed by Vogel-Heuser et al., this knowledge base is composed of three layers [17]. The elements at the lowest layer refer to real-world objects, which can be electrical or mechanical hardware or software in a system. The middle layer stores the information extracted from project-specific models (also called model instances). At the top layer, metamodels are interconnected to represent model-related knowledge. In addition, knowledge from selected intralogistics domain standards, together with domain experts’ knowledge, is formalized as a complement to model knowledge (metamodels). The arrows in the knowledge base refer to the relationships between multisource data. Moreover, the IM also contains a reasoner to generate different types of data relations (see “derived links” in Figure 1) and a query engine to identify potential contradictions among model information. The CM mainly serves as an interface between engineers and ICM. It includes a user interface allowing engineers to upload models and self-defined consistency rules, trigger the checking process and get access to the inconsistency checking results.

Overall, the inconsistency identification process can be divided into four steps: First, domain knowledge is formalized, and the metamodels of the selected engineering models are imported into the ICM together with their dependencies (Preparation). After preparing the reusable part of the ICM, project-specific models should be uniformly formalized so that they can be integrated into the knowledge base (Preprocessing). Subsequently, the reasoner and query engine in the IM link these model instances automatically and check the inconsistencies with predefined and project-specific queries (Inconsistency checking). Finally, the query results are supplemented with additional information and presented to the engineers via the user interface in the CM (Postprocessing). Following these steps, details of the concept are provided in the following.

Preparation: In the preparation phase, metamodels of the selected engineering models, user-defined consistency rules, relevant industry standards, and guidelines applied in the intralogistics domain are utilized as the inputs. With these inputs, a reusable upper structure (model knowledge layer) is constructed in the knowledge base, which is the core part of the ICM. To improve the extensibility and general applicability of the approach, the V-SUMM concept is applied, which utilizes coupled metamodels to achieve automatic model linking. Thus, dependencies among metamodels in this layer are manually defined (see “defined mappings” in Figure 1) and imported into a link repository in the ICM. The links “L” can be expressed as 3-tuple:

In Eq. (1), MM represents a set of metamodels that are imported into the ICM. MM _i , MM _j are the i-nd and j-nd metamodels in the set where i, j = 1, …, m and i ≠ j. LT refers to a set of link types, which is defined based on the classification of model dependencies [11], and LT _k is the k-nd type of link, k = 1, …, n. In addition, a rule repository containing rules for automatically deriving links between model instances is prepared and integrated into the CM. The rules are constructed based on the first-order logic (FOL), which can be expressed as:

L ₁, L ₂, …, L _t are the relations that were pre-saved in the link repository, and L _new is the inferred relation between elements in the model instances (entities). e _x , e _y refer to the entities to be linked, which are extracted from the model data. v _i are the variables that represent entities in the model data.

Preprocessing: Before checking the model inconsistency, heterogeneous model data should be preprocessed to gain a uniform format so that they can be merged into the knowledge base. The information extraction process is performed by the CM. In the CM, a representation model is developed for each selected engineering discipline (view). The extracted model data needed for consistency checking is written into respective representation models and each of which entails the information for one engineering view. For example, the representation model for the mechanical view contains information about the position, geometric dimensions, name, and assignment to an assembly of each part. Once the checking process is started, data from uploaded engineering models is parsed based on the representation models and transformed into RDF. In addition, self-defined consistency rules are also transformed by the CM in this step. All the processed data is sent together to the ICM.

Inconsistency checking: This process is performed by ICM and can be divided into two sub-steps: model merging and inconsistency querying. In the first step, uniformly formatted model data from the CM is merged into the knowledge base. Relying on the unique identification number assigned to each model during preprocessing, model instances are mapped to the corresponding metamodels. Until now, model data is still independent in the knowledge base. To generate relations between inter-model information, metamodel links, and the FOL-rules are utilized. Based on these two repositories (link- and rule-repository), an SWT-reasoner looks through all the model data and couples the cross-domain model elements automatically (see “derived links” in Figure 1) according to the FOL-rules.

After inserting the links between model instances, the knowledge base is prepared for inconsistency querying. In the query repository, some queries are pre-saved based on domain knowledge, such as searching for the reference velocity of conveyors based on their classification. In addition, user-defined inconsistencies, which are created based on project specifications or engineers’ expertise, are also imported. In each query statement, starting from the source model information, the target information is searched along the generated model links, and the mathematical relations between the source and target model data are also explicitly defined (see Eq. (3) in Section 5.3).

Postprocessing: When inconsistencies are detected by the query engine, the results are then completed with additional information to assist engineers in resolving conflicts among models. The processed checking results include not only information about conflicting model information but also warning messages for engineers that are previously supplemented to each query.

After the four steps described above, heterogeneous model data are automatically extracted and connected. Different types of model inconsistencies are checked based on the formalized model and domain knowledge, and the results are presented to the engineers.

5 Evaluation using a prototypical implementation

In this section, the proposed approach is prototypically implemented and evaluated with three representative inconsistency cases coming from an industrial use case.

5.1 Prototypical implementation

To evaluate the concept described in Section 4, a prototypical tool shown in Figure 2 is developed. As mentioned in Section 4, the tool also consists of two modules.

Figure 2:

Prototypical implementation of the concept.

The CM is written in the Java programming language and includes a graphical user interface (GUI). The representation models in the CM contain Java classes that need to be filled with extracted model data. Subsequently, they are transformed into RDF files using Apache Jena,^[1] which is a Java framework for SWT. In addition, users can define their own consistency rules with the modeling tool Eclipse Papyrus.^[2] To ensure that these rules correctly address model properties defined in the representation models, Papyrus model files with UML profiles are provided. Through the provided Papyrus model, user-defined rules are generated in UML format, which are further transformed into the form of JavaScript Object Notation (JSON) and sent to ICM together with extracted model information.

On the other hand, the ICM is composed of three repositories and a knowledge base. To provide a uniform format for representing heterogeneous engineering data and to infer potential information relations, SWT are applied. The knowledge base is modeled in OWL, which is an SWT language that is designed to process and integrate heterogenous information and supports relation reasoning. Thus, the knowledge is understandable for humans and also interpretable for machines. The link repository stores the links between elements at the metamodel level in a CSV file. Based on the predefined links and the model data received from the CM, a knowledge base is generated in OWL. To automatically couple the model instances, inference rules based on the FOL (see Eq. (2)) are defined and saved in a rule repository using the Semantic Web Rule Language (SWRL). In addition, in the query repository, the explicit relations between model elements are formalized in SPARQL, which is a semantic web query language. Once the checking process is triggered via the user interface, the query engine contained in the open-source Python packet Owlready2 [18] queries through the knowledge base to detect potential inconsistencies. The synchronization of data and processes between the two modules is achieved by using RESTful web services.

5.2 Description of the use case

During the operation phase of ILS, individual logistics components may break down, e.g., due to aging. In the worst case, the broken component must be replaced by a new, comparable one if the original component type is out of production or has delivery delays [7]. Figure 3 shows a minimal example of ILS consisting of four belt conveyors built in a line. Although this use case is a minimal, lab-sized example, it is sufficient to represent the identified challenges, such as domain-specific models with different exchange formats modeled by different stakeholders and containing overlapping information about the system under development. In the considered scenario, belt conveyor 3 is broken and must be replaced by new hardware with similar functionality. In the new conveyor, a different drive is installed, requiring an update of the ILS’s control software, and the mechanical conveyor parts have minor geometrical differences compared to the old components. Accordingly, during the preparation of the exchange, the model data needs to be updated. For example, the mechanical engineer imports the new conveyor’s 3D model provided by its manufacturer into the 3D model of the entire system, while the automation engineer updates the configuration of the function block parameters. Meanwhile, to generate new process-related key performance indicators, e.g., the system’s availability factor, a process simulation engineer re-simulates the transportation process with new simulation parameters of conveyor 3, such as the transportation time. If these model-related changes are not performed in time, or communicational problems between teams occur, conflicts among cross-domain engineering data may be caused.

Figure 3:

Use case replacement of a broken conveyor and the relevant engineering models.

The goal of this evaluation is to cover relevant engineering disciplines involved in the development of ILS without focusing too much on specific modeling tools from individual vendors. According to the pre-study [4], mechanical design, software development, material flow design, and project data analysis are the most relevant disciplines involved in ILS development. Thus, the following representative modeling tools are selected during the prototypical implementation: in the field of mechanical engineering, FreeCAD is selected (Model No. 1), to simulate the dynamic material flows, JaamSim is selected (Model No. 2), including generated system parameters (e.g., breakdown time, maintenance time) that are documented in a JaamSim report (Model No. 3) to check the fulfillment of project-specific requirements. The requirements list (Model No. 4) is stored in table format using Excel and a predefined template. For control software development, a TwinCAT export (Model No. 5) is generated, which contains all the control parameters and code to automate the transportation process. Each selected model targets a sub-aspect of the considered ILS, while there are information overlaps and dependencies between the models that may lead to errors during the design process, as highlighted in [4].

5.3 Potential inconsistencies

For evaluation purposes, three inconsistency cases are derived and simplified from the previously conducted expert interviews [4], which address different parts of the proposed concept. In this sense, they can be considered representative and serve as a first proof-of-concept evaluation.

5.3.1 Inconsistency case 1 (IC1): intra-model inconsistency (different heights of two adjacent conveyors)

When belt conveyor 3 is exchanged, its different interfaces need to be considered regarding consistency. Some geometrical conflicts of its mechanical interface can be detected directly by the FreeCAD tool, e.g., the spatial overlap of two objects. However, some inconsistencies still need to be checked based on domain knowledge. A simple example is the positions of the two adjacent conveyors on the z-axis (see Figure 3), which need to be identical to ensure a fluent and stable transportation process. In the use case, after updating the 3D model of conveyor 3 in FreeCAD, its height value is compared with the height values of its neighboring conveyors (conveyors 2 and 4) to avoid this inconsistency.

Since no metamodel is officially provided by the FreeCAD tool, a metamodel is developed during the implementation, which includes 24 classes representing the basic structure and information of a FreeCAD model. In the “geometry” class of the metamodel, three positions and three directions are defined as its attributes. In this case, the equivalence relations are utilized, which define whether two linked elements should be the same [11]. Thus, the link at the metamodel level is defined as “z_position – equivalentTo – z_position”. In the rule repository, the inference rule to identify which conveyors are adjacent is derived from the material flow information contained in the simulation model. Based on this rule, the reasoner automatically generates the “has_neighbor” relations among different conveyors. Based on this predefined link and the inferred relations, the query engine compares the z-position of all adjacent conveyors and detects an inconsistency if they are not equal. Additionally, tolerance of the height difference is also given according to domain knowledge and stored in the query repository.

5.3.2 Inconsistency case 2 (IC2): inter-model inconsistency (conveyor velocity)

To assess the fulfillment of R1 (heterogeneous models), this inconsistency case is utilized. When changing the configuration of conveyor 3 regarding its geometrical data and control software, engineers in the process simulation domain also need to recalculate the transportation time of a workpiece on each conveyor according to the system throughput time. In the JaamSim model, the transport time of a workpiece on conveyor 3 (t _conveyor3, unit: s) is simulated. Moreover, the function block of conveyor 3 is replaced in the control program, including an update of the target rotational speed of the drive (v _rotation) on conveyor 3. The parameter v _rotation is converted to the linear target velocity of the conveyor (v _conveyor3, unit: m/s) in the control software. Overall, the parameters t _conveyor3 from JaamSim and v _rotation from TwinCAT are connected via the conveyor length (l _conveyor3, unit: mm) defined in the 3D FreeCAD model as follows:

(3) v conveyor 3 = l conveyor 3 t conveyor 3 * 1000

Since this inconsistency case includes relations among three different engineering models, more details are provided here. As shown in Figure 4, three classes from three different metamodels are involved in this inconsistency case: “component” in FreeCAD, “simulationItem” in JaamSim, and “FunctionBlock” in TwinCAT. The metamodel link is defined between three attributes from these classes, which are “length”, “transportationTime” and “velocity” respectively. Two types of links are applied in this case, which are correspondence and satisfaction respectively. The correspondence links (“correspondTo”) focus more on convention-based model relations by which the mathematical relations among values of model attributes are built, whereas the satisfaction links (“satisfiedBy”) depict the conformance of model elements with domain standards, guidelines, or project-specific requirements [11]. As denoted in Figure 4, links between corresponding parameter values extracted from concrete models are derived automatically, and their explicit relations (i.e., Eq. (3)) are saved in the query.

Figure 4:

Relations between multi-level elements in inconsistency case 2.

To further check the conformance of the calculated conveyor velocity with domain-specific knowledge, the taxonomy of continuous conveyors from guideline VDI 4440 is integrated into the knowledge base, including the usual maximum conveying speed for belt conveyors indicated by domain experts. This domain knowledge is additional information beyond the model knowledge to identify additional inconsistencies. The system component “Belt conveyor 3” is automatically classified as a “Belt conveyor” in the taxonomy based on the analysis of string similarity. To further couple the “maximum velocity” of the belt conveyor and the velocity of conveyor 3 (v _conveyor3), the following FOL rule is formulated in Eq. (4) and saved in the rule repository:

(4) (4) Is _ a ( conveyor, Beltconveyor ) ∧ h a s _ parameter ( conveyor, velocity _ conveyor ) ∧ has _ max _ velocity ( Beltconveyor, velocity_ max ) ⇒ satisfied _ by ( velocity _ max , velocity _ conveyor )

By reasoning on this FOL rule, all the velocities of conveyors in a system can be linked to the corresponding velocity limits based on the conveyor type. Thus, the v _conveyor3 coming from TwinCAT is coupled with the velocity of belt conveyors in the taxonomy, and their consistency can be checked after performing a query. The materials for implementing inconsistency case 2, including an excerpt of the used metamodels, model instances in tool-specific formats, FOL rules, links on metamodel-level, SPARQL queries, as well as the checking results, are available online.^[3]

5.3.3 Inconsistency case 3 (IC3): user-defined inter-model inconsistency (MTBF, MTTF)

According to the conducted pre-study [4], many inconsistencies in real ILS development are caused by requirement changes. In most cases, engineers need to manually look up specific parameters within their models that are affected by a changed requirement, which is time-intensive and error-prone. This IC3 addresses this challenge by defining consistency rules to realize automatic inconsistency checking during requirement changes. A typical requirement is the availability of the ILS, which represents the relationship between the total expected downtime and the total theoretical usable operating time. To ensure the economic efficiency of a plant and quantitatively forecast the probability of failure, two values are commonly applied, which are:

MTBF (mean time between failures) = 1 λ = expected value of the failure-free time between failures (λ – failure rate)

MTTR (mean time to repair) = 1 μ = expected value of the failure time (μ – repair rate)

With these two values above, the availability of the system (A) can be calculated by the following equation [19]:

(5) A = MTBF MTBF + MTTR .

The availability of ILS is a project-specific value and is determined by custom requirements. As a result, when the logistics planner changes the required system availability, the model that provides these two values (MTBF, MTTR) should also be adjusted accordingly.

To forecast the availability of the four-conveyor-ILS described in Section 5.2, MTBF and MTTR are defined in the JaamSim, and their simulated values are documented in the JaamSim report. On the other hand, requirements targeting quantitative system parameters are specified in an Excel file with predefined value ranges. Since MTTR and MTBF are not pre-integrated parameters in the JaamSim but are simulation parameters self-defined at specific measuring points, their consistency rule cannot be prepared. Therefore, the framework is also developed to support user-defined inconsistency queries. In the prototypical implementation, the lowest boundaries of these parameters are specified in a requirement list. A consistency rule (i.e., “the simulated MTBF and MTTR values should not be lower than the required minimum values.”) is defined manually with the graphical modeling tool provided by Papyrus. The generated rule file in the form of UML is uploaded together with the two models (i.e., JaamSim report and requirement list) via the user interface. Checking results are shown in Figure 5.

Figure 5:

Checking results of inconsistency case 3.

5.3.4 Implementation results

To evaluate the concept, inconsistency cases described above are intentionally added to the respective models. After loading the corresponding models and user-defined consistency rule (IC3), all these three types of inconsistencies are successfully detected. Figure 5 shows a screenshot of the graphical user interface with the checking results for IC3. The left part of the interface lists all the model files uploaded by engineers, and the right part displays the checking results. In the result table, the first two columns show the internal number and rule file name, respectively, and the next four columns describe the affected engineering views, model types, and model elements. In the last column, a message that helps relevant engineers to resolve this inconsistency is provided.

6 Summary and outlook

This paper proposes a concept to automatically identify multiple types of model inconsistencies that emerge during the multidisciplinary development of ILS. Compared to the basic V-SUMM approach [14], consistency rules and links are extended to describe complex relations (including mathematical relations) between heterogeneous engineering models. Besides, domain knowledge is considered, and a third “system” layer is built to support checking various types of inconsistencies. Compared to the manual checking process, inconsistencies that are often easy to be overlooked can be defined as rules and queries, which ensures more reliable and user-independent checking results. In addition, engineers do not need to look up, compare and transform the parameters in different models, which significantly reduces human effort when dealing with more complex models in reality. Compared to other inconsistency management approaches developed for the production system development, the basic structure derived from the V-SUMM can realize automatic linking of model instances with pre-coupled metamodels, which cannot be addressed by, e.g., the work of Feldmann et al. [8]. Moreover, using V-SUMM, a so-called combined view (knowledge base), including the domain knowledge from all involved disciplines, is generated. For each modeled element, this knowledge base includes information about that element from all involved disciplines. Thus, to avoid inconsistencies caused by sequential, multiple modeling of an element in different views, information about the element already contained in the knowledge base is automatically displayed to engineers from different disciplines. Thereby, it is possible to generate discipline-specific models partially based on already entered information, which will be addressed in the future. In addition, different from the previous studies based on V-SUMM, which mainly focus on models in software development, the concept is able to detect inconsistencies among different models coming from multidisciplinary modeling tools. Furthermore, domain- and discipline-specific knowledge is also formalized in the knowledge base, which extends the scope of model inconsistencies that can be detected. The developed user interface enables engineers to check self-defined model inconsistencies according to the changing system requirements, which promotes the industrial applicability of the approach. By defining links between the metamodels and rules to be checked, a new potential source of errors is introduced, in the worst case leading to misidentified or overlooked inconsistencies. Nevertheless, automatic identification of parts of the included inconsistencies is a benefit compared to the so far completely manual inconsistency checking approach.

Some limitations still exist within the scope of the paper. First, validation of the proposed approach is limited to relatively simple inconsistency cases at the level of proof-of-concept. Additionally, the potential risks of misidentified or overlooked inconsistencies are still open. In the future evaluation, a real industrial use case will be selected, including the application of real models and inconsistencies without simplification. The checking process and results will be evaluated by domain experts who have deep insights and experience in the intralogistics domain. Since no generic inconsistency-checking process exists in reality [4], the proposed approach will be assessed by these experts through a comparison with their current inconsistency-checking approaches.

In future work, the approach will be first applied to other ILS to further prove its generality. In addition, model consistency of other industrial production plants that include not only logistics systems will be tested with the proposed concept, accompanied by the incorporation of extensive engineering models and domain knowledge. Due to the similar characteristics of intralogistics systems and production systems in general, it is expected that the approach can be transferred to further parts of the production systems. For this purpose, additional model interfaces will be created in the CM to widely support modeling tools applied in the development phase, and the checking results will be intuitively presented to engineers in a graphical format. Meanwhile, knowledge not only from the logistics domain but also from other sub-parts of the production systems should be formally described and incorporated. Since defining links and rules still requires much manual work, future focus will be put on utilizing available information, such as unique equipment identifiers, which are used company-wide by some companies in practice, for linking models from different disciplines and, thus, reducing the manual activities involved. Furthermore, the scalability of the approach will be evaluated in the future to ensure, e.g., no cross effects will be caused by the coupling of additional model information. In addition, to investigate the impact of model changes, a future extension of the ICM is planned to allow versioning of the models uploaded to the knowledge base in order to identify inconsistencies resulting from model updates.