Abstract
Industry 4.0 standards, such as AutomationML, are used to specify properties of mechatronic elements in terms of views, such as electrical and mechanical views of a motor engine. These views have to be integrated in order to obtain a complete model of the artifact. Currently, the integration requires user knowledge to manually identify elements in the views that refer to the same element in the integrated model. Existing approaches are not able to scale up to large models where a potentially large number of conflicts may exist across the different views of an element. To overcome this limitation, we developed Alligator, a deductive rule-based system able to identify conflicts between AutomationML documents. We define a Datalog-based representation of the AutomationML input documents, and a set of rules for identifying conflicts. A deductive engine is used to resolve the conflicts, to merge the input documents and produce an integrated AutomationML document. Our empirical evaluation of the quality of Alligator against a benchmark of AutomationML documents suggest that Alligator accurately identifies various types of conflicts between AutomationML documents, and thus helps increasing the scalability, efficiency, and coherence of models for Industry 4.0 manufacturing environments.
Access provided by Autonomous University of Puebla. Download conference paper PDF
Similar content being viewed by others
Keywords
1 Introduction
In the engineering and manufacturing domain, there is an atmosphere of departure to a new era of digitized production, where traditional industrial engineering methods are synergistically combined with IT and internet technologies, such as cyber-physical systems, sensor networks, big data analytics, and semantic data integration. In different regions, initiatives in these directions are known under different names, such as industrie du futur in France, industrial internet in the US or Industrie 4.0 in Germany. A core vision of these initiatives is to make manufacturing and production more flexible, efficient, and less error-prone by shifting more ‘intelligence’ to the edge. This shall be achieved by enabling sensors, devices, machines, and storage and transport equipments to directly communicate with each other. To realize this Industry 4.0 vision, a vast variety of areas related to manufacturing, security, and machine communication need to interoperate by aligning their information models using domain-specific standards.
The Automation Markup Language (AutomationML or AML) for exchanging plant engineering information as specified by IEC 62714 [4, 9, 17, 21] is one of the core standards of Industry 4.0. AutomationML can describe plant components and their sub-components from different perspectives, e.g., mechanical or electrical. A key challenge in such settings is intra-standard interoperability, i.e., the consistent integration of multiple pieces of information described in AutomationML. To overcome this challenge, we present Alligator, a deductive approach to integrate AutomationML specifications, and potentially similar document types.
We define an RDF-based representation of AutomationML input documents, aiming to resolve structural semantic inconsistencies, such as granularity of representations, schematic differences, and groupings and aggregations. Based on this semantic representation, we define a set of Datalog rules for identifying conflicts that generate structural semantic inconsistencies. A deductive engine is used to compute the conflicts from the Datalog representations. Conflict resolution is utilized to merge the input documents and produce an integrated AutomationML document.
By automatizing a crucial part of the engineering and modeling processes, Alligator addresses a key pillar of the Industry 4.0 vision. To the best of our knowledge, Alligator is the first comprehensive approach for automatically resolving the semantic ambiguity of AutomationML. As a result, the Alligator approach enhances scalability, efficiency, and coherence of models for Industry 4.0 manufacturing environments. Although our initial implementation and evaluation of the approach focuses on AutomationML, the approach is easily transferable to other Industry 4.0 standardization initiatives. We empirically evaluated the quality of Alligator against a benchmark of AutomationML documents. The evaluation results suggest that Alligator accurately identifies various types of conflicts between AutomationML documents.
In summary, this work makes the following contributions:
-
1.
Alligator, a deductive approach, that combines Deductive Database and Semantic Web technologies for the integration of Industry 4.0 Standards.
-
2.
A set of Datalog rules to characterize semantic heterogeneity types among AutomationML documents.
-
3.
An empirical evaluation that reveals the effectiveness of Alligator during the integration of AutomationML documents.
The remainder of this paper is structured as follows. Section 2 motivates the problem with a concrete example. Section 3 gives an overview on the background and introduces the terminology relevant to our approach. Section 4 presents the Alligator approach, which is evaluated in Sect. 6. Section 7 reviews related work. Section 8 concludes and gives an outlook to future work.
2 Motivating Example
A typical scenario in the mechatronic domain is data exchange between engineering tools during the modeling process. Engineering tools are utilized in different disciplines, such as mechanical and electrical engineering, or systems control. Figure 1 illustrates the results of an engineering modeling process where a motor engine is modeled from mechanical and electrical viewpoints. Mechanical engineers design the motor engine from the mechanical point of view, whereas electrical engineers model the electrical wiring topology inside the motor engine. AutomationML is utilized in both views to semantically describe the engine. However, because physical structures in these views are modeled with different properties, conflicts might arise when integrating these designs, thus inducing structural semantic inconsistencies.
Figure 2 details the mechanical and electrical views of the motor engine given in Fig. 1. The motor engine is identified as 0173-1#01-AKE162#012 DC Engine according to the eCl@ss product classification standardFootnote 1. This reference enables the semantic description of the mechatronic component by pointing to the standard definition of a motor engine in eCl@ss. The AML document Motor-Engine-Mec.aml (cf. Fig. 2a) specifies the motor in terms of its construction form as a DC Engine (mechanical view). The AML element RoleClassLib (lines 2–23) comprises two AML elements RoleClass. The first RoleClass (lines 4–14) contains AML attributes with references to eCl@ss that semantically describe the engine according to the standard definition of version, classification in the eCl@ss catalog, and the International Registration Data Identifier (IRDI). The second RoleClass (lines 15–20) is composed of an AML attribute that defines the construction form of the DC Engine; RefSemantic (line 18) refers to the eCl@ss standard definition of this AML attribute (0173-1#02-BAE069#007).
Figure 2b depicts an AML document that aims at defining the same engine from the electrical viewpoint. As in the mechanical view, the first RoleClass (lines 4–14) semantically describes the engine using eCl@ss, while the second RoleClass (lines 15–20) defines not the engine as a whole, but a data cable in the engine. The Attribute in line 16 specifies the data cable and includes the semantic reference to eCl@ss (line 18).
Albeit the structural definition in these views of the DC Engine differs in the AML documents, the specification of AutomationML and its eCl@ss integration [19] imply that both descriptions are semantically equivalent. On one hand, the references to eCl@ss indicate that the AML elements between lines 4 and 14 in the two views correspond to the same element in the real world. For example, the specification of AutomationML states that two RoleClass elements are semantically equivalent whenever they share the same eCl@ss references for the AML attributes eClassVersion, eClassClassification, and eClassIRDI [19]. However, these views describe different real-world objects, and they should not be defined using RoleClass elements in the mechanical and electrical views which are considered semantically identical according to AML. Therefore, these elements are in conflict. Accordingly, there are five pairs of conflicting AML elements in this simplified example; each pair of these needs to be merged into one AML element in case the two views are integrated.
Currently, this integration is performed manually by experts, negatively affecting engineering processes. We present Alligator, a deductive framework that exploits the features of logic programming and the RDF data model for representing AML documents, as well as for detecting conflicts whenever AML documents are integrated.
3 Background
AutomationML. AutomationML (Automation Markup Language, IEC 62714) is a standard to exchange information about engineering tools, such as mechanical plant engineering, electrical design, or robot control. AutomationML provides an XML Schema, incorporating three different standards for describing real plant components [20]. At the top level there is the CAEX (IEC 62424) format for plant topology, storing hierarchical object information, properties, and libraries [8]. Secondly, the geometry (mechanical drawings) and kinematics (physical properties, such as force, speed, or torsion) are implemented with COLLADA [3]. Finally, the logic (sequencing, behavior, and control information) is implemented with PLCopen XML (IEC 61131).
AutomationML is built upon four main CAEX concepts: RoleClassLibrary, SystemUnitClassLibrary, InterfaceClassLibrary, and InstanceHierarchy. RoleClassLibrary specifies vendor independent requirements for the specification of system equipment objects; a RoleClassLibrary may comprise several RoleClasses, which provide role descriptions of a given class. Such descriptions aim at representing a physical or logical object, e.g., a motor or a robot. The InterfaceClassLibrary defines a set of interfaces to describe a plant model. First, it can define relations between the objects of a plant topology. Secondly, it can reference external information, e.g., a 3D description of a motor. The InstanceHierarchy describes the plant topology, and defines specific equipment for actual projects. Further, Attributes are used to define properties, e.g., length or size, of AML objects, e.g., RoleClasses or Internal Elements. In this paper, we focus on modeling topology information by means of the CAEX format.
AutomationML. Biffl et al. [4] and Kovalenko and Euzenat [11] have characterized mappings to deal with semantic heterogeneity in the engineering domain, and specifically in AutomationML. The authors have identified the following types of semantic heterogeneity: (M1) Value processing same properties are not modeled equally, e.g., using different datatypes; (M2) Granularity same objects are modeled at different levels of detail; (M3) Schematic differences differences in the way how semantics is represented for the same object; (M4) Conditional mappings relations between entities exist only if certain conditions occur; (M5) Bidirectional mappings relations between entities have to be defined bidirectionally; (M6) Grouping and aggregation different semantic modeling criteria are applied to group elements for the same object; and (M7) Restrictions on values mandatory values for properties in the object that have to be handled in the mapping process. As a proof of concept, we focus on semantic heterogeneity types, such as granularity (M2), schematic differences (M3), and grouping and aggregation (M6). We selected these types because they present major semantic structural differences to describe similar objects. Additionally, they characterize semantic mappings between two AML elements that can be performed in two ways:
-
1.
Direct identification considers two elements to refer to the same entity if the same identifier is used.
-
2.
Indirect identification considers two elements to refer to the same entity if both refer to the same identity-providing elements from an external catalog, e.g., RoleClass or Attributes. For more complex structures as RoleClasses, it is assumed that if the combination of the eCl@ss IRDI, classification level, and version are equal, then the RoleClasses are considered to be the same.
AutomationML Vocabulary. Several approaches exist for adding semantics to the AutomationML language by means of ontologies [1, 2, 5, 6, 12, 15]. With the exception of the AutomationML ontologyFootnote 2, designed for the AutomationML Analyzer [16], none of the aforementioned ontologies covers all concepts given in the AutomationML schema. Additionally, they are not available on the web for consulting or querying. Crucial information for Alligator, such as the mapping with eCl@ass concepts, are not included in the AutomationML Analyzer vocabulary. Therefore, we have developed an RDFS vocabulary describing the main concepts of the AutomationML language.Footnote 3 Also, we have included concepts related to the integration with the eCl@ss standard.
4 Our Approach: Alligator
In this section, we present a formalization of AML documents, as well as the integration problems and proposed solution addressed by the Alligator approach. Finally, the architecture of Alligator is described in detail.
4.1 Alligator Representation of AML Documents
Definition 1
(Alligator Document). An Alligator document is a tuple \(\varGamma =\langle \theta , V, F\rangle \) such that \(\theta \) is a set of URIs that identify AML elements, V is a set of properties in the AML vocabulary and F is an RDF graph composed of triples in \(\theta \times V \times (\theta \cup L)\) where L is a set of literals.
An Alligator document \(\varGamma =\langle \theta , V, F\rangle \) can represent information from one or several AML documents \(D_i\), where \(\theta \) is the set of URIs that identify the AML elements in \(D_i\), and the RDF graph F describes the relationships between the AML elements in \(D_i\). In general, V can refer to different vocabularies, e.g., for other standards than AML such as OPC UA, but in this work, we focus on the AML vocabulary.
Example 1
Consider the RDF graph \(F_1\) in Fig. 3. This graph comprises RDF resources representing the AutomationML elements in the mechanical and electrical views shown in Fig. 2; the AutomationML RDF vocabulary is used to describe these resources. An Alligator document \(\varGamma _1=\langle \theta _1, V, F_1\rangle \) formally describes this RDF representation of the two views, where \(\theta _1\) is the set of the resources in \(F_1\), and V is the AutomationML RDF vocabulary.
Definition 2
(Ideal Alligator Document). Given an Alligator document \(\varGamma =\langle \theta , V, F\rangle \), there is an ideal Alligator document \(\varGamma ^*=\langle \theta ^*, V, F^*\rangle \) such that \(\varGamma ^*\) comprises only conflict-free AML elements. Additionally, there is a homomorphism \(\sigma :\theta \rightarrow \theta ^*\). The RDF ideal graph \(F^*\) is defined as follows:
Example 2
Consider the RDF graph in Fig. 4a. The Alligator document \(\varGamma ^*=\langle \theta ^*, V, F^*\rangle \) describes this RDF graph, where \(\theta \) is the set of RDF resources in the graph, V is the AutomationML RDF vocabulary, and \(F^*\) is this RDF graph. \(\varGamma ^*\) represents the ideal conflict-free Alligator document of \(\varGamma _1\). Figure 4b shows a homomorphism \(\sigma \) that maps two conflicting resources in the RDF graph in Fig. 3 to the same resource in Fig. 4a.
Definition 3
Consider an Alligator document \(\varGamma =\langle \theta , V, F\rangle \), an ideal conflict-free Alligator document \(\varGamma ^*=\langle \theta ^*, V, F^*\rangle \), and a homomorphism \(\sigma :\theta \rightarrow \theta ^*\). A set of conflicts in \(\varGamma \) with respect to \(\varGamma ^*\) and \(\sigma \), conflicts(\(\varGamma \mid \varGamma ^*,\sigma \)), corresponds to the set of AML element pairs \((E_i,E_j)\) in \(\theta \times \theta \) such that \(E_i\) and \(E_j\) are different but that \(\sigma \) maps to the same target AML element in \(\theta ^*\):
Example 3
Given Alligator documents \(\varGamma _1\) and \(\varGamma ^*\) from Examples 1 and 2, and the homomorphism \(\sigma \) in Fig. 4b. The set of conflicts(\(\varGamma _1 \mid \varGamma ^*, \sigma \)) corresponds to the set of pairs of RDF resources in the RDF graph of Fig. 3 that \(\sigma \) maps to the same resource in the ideal RDF graph (Fig. 4b).
4.2 Problem Definition and Proposed Solution
Given an Alligator document \(\varGamma =\langle \theta , V, F\rangle \), the AML Conflict Identification problem determines if a pair \((E_k,E_l)\) of AML elements in \(\theta \) is conflicting.
Definition 4
Consider an Alligator document \(\varGamma =\langle \theta , V, F\rangle \), an ideal conflict-free Alligator document \(\varGamma ^*=\langle \theta ^*, V, F^*\rangle \), and a homomorphism \(\sigma :\theta \rightarrow \theta ^*\). The AML Conflict Identification problem corresponds to the problem of deciding if \((E_k,E_l) \in \theta \times \theta \) belongs to conflicts(\(\varGamma \mid \varGamma ^*,\sigma \)).
Solving the AML Conflict Identification problem requires the existence of the ideal conflict-free AML document \(\varGamma ^*\) and the homomorphism \(\sigma \). However, in practice neither \(\varGamma ^*\) and \(\sigma \) is known, and Alligator computes an approximation of the problem. We use SC(\(\varGamma \)) to refer to the set of pairs \((E_k,E_l)\) that correspond to the solutions of this problem. Once a set SC(\(\varGamma \)) of conflicting AML elements in F is identified as the solution of the AML Conflict Identification problem, the problem of AML Conflict Resolution corresponds to the problem of creating an Alligator document where conflicts in SC(\(\varGamma \)) are solved.
Definition 5
Consider an Alligator document \(\varGamma =\langle \theta , V, F\rangle \) and a set SC(\(\varGamma \)) of pairs of conflicting AML elements in F. The problem of AML Conflict Resolution corresponds to the problem of creating an Alligator document \(\varGamma '=\langle \theta ', V, F'\rangle \) and a homomorphism \(\sigma ':\theta \rightarrow \theta '\), such that:
-
For each \((E_i,E_j)\) in SC(\(\varGamma \)), there is an AML element \(E_m\) in \(\theta '\) such that \(\sigma '(E_i)=\sigma '(E_j)=E_m\).
-
\(F'=\{(\sigma '(s), \; p, \; \sigma '(o)) \mid (s,\; p, \; o) \in F\}\).
\(\varGamma '\) represents the Alligator document where pairs of AML elements in SC(\(\varGamma \)) are represented as one RDF AML element.
We developed Alligator, an integration tool that relies on deductive database techniques for solving the problems of AML Conflict Identification and AML Conflict Resolution. Figure 5 depicts the architectural components of Alligator. Given a set of AML documents, the Alligator Data Model Creation component generates an Alligator document \(\varGamma =\langle \theta ,V,F\rangle \) that formally describes the union of these input AML documents. Additionally, a set of Datalog extensional facts (EDB) representing the triples in the RDF document F is created. The Deductive System Engine relies on the set of Datalog intentional rules (IDB) to compute the set SC(\(\varGamma \)) from the Datalog representation of \(\varGamma \). The set of Datalog intentional rules (IDB) defines different types of semantic heterogeneity that can occur among AML documents that correspond to views of the same mechatronic object definition. SC(\(\varGamma \)) is computed as the least minimal fixpoint of the Datalog rules in IDB and the facts in EDB. Further, SC(\(\varGamma \)) is utilized by the Integrated AML Document Creation component to solve the AML Conflict Resolution problem, and to produce an integrated AML document where RDF AML elements in SC(\(\varGamma \)) are integrated as one AML element.
4.3 Alligator Data Model and Deductive System Engine
Alligator represents AML documents as RDF graphs. AML documents are translated to RDF using Krextor [13], an XSLT-based framework for converting XML to RDF. The RDF AML vocabulary is used to describe AML elements and relations. Further, AML documents are modeled as facts in an extensional database (EDB) of a Datalog program P; for each type of AML element in the AutomationML standard exists an extensional Datalog predicate in P. Rules in the intensional database (IDB) of the Datalog program P characterize types of semantic heterogeneity. Intensional Datalog predicates represent conflicts that can exist between the different AML elements according to the types of semantic heterogeneity. The Alligator Deductive System Engine performs a bottom-up evaluation of P following a semi-naïve algorithm that stops when the least fixed-point is reached [7]. The intensional predicates inferred in the evaluation of P correspond to the pairs of conflicts in the set \(SC(\varGamma )\).
5 Alligator rule-based representation of AutomationML Semantic Heterogeneity
One of the key innovations of Alligator revolves on the use of a Datalog-rule approach to effectively solve types of semantic heterogeneity. We have developed a set of rules covering the main characteristics of AML. Regarding the attributes, it is possible to determine that, if two attributes refer to the same eCl@ss value, i.e., eCl@ss IRDI, it can be assumed that their semantic meaning is the same. In detail, the AML element refSemantic refers to the eCl@ss IRDI using CorrespondingAttributePath (cf. Fig. 2 line 18). Thereby, even if two attributes are defined with different names, e.g., Length and StrictLength, they can still be semantically equivalent whenever they are linked to the same IRDI reference. It is important to remark that these rules have been defined taking into account the AML vocabulary properties. Based on this, the rule in Listing 1 states when two attributes are semantically equivalent.
To determine that two RoleClasses are semantically equivalent according to their reference to eCl@ss, they have to contain the same version, classification, and IRDI. Based on these three conditions, Rule 2 (cf. Listing 2) defines two semantically equivalent RoleClasses.
Rule 2 relies on simpler rules such as Rule 3 (cf. Listing 3), which defines the equivalence of two eClassIRDI attributes. Similarly, we have defined rules to decide if two values of eClassVersion and eClassClassification are the same.
These three rules are only examples of the type of rules implemented in Alligator; the complete set of rules is given on GitHubFootnote 4.
6 Empirical Evaluation
We studied the effectiveness of Alligator in the solution of the problems of AML Conflict Identification and AML Conflict Resolution. In particular, we assessed the following research questions: (RQ1) Is Alligator able to identify pairs of conflicting AML elements in AML documents?; (RQ2) Does Alligator exhibit equal behavior whenever different types of semantic heterogeneity occur during the integration of AML documents? The experimental configuration to evaluate these research questions was as follows:
Testbeds. Testbeds were based on the semantic mapping types M2 (granularity), M3 (schematic differences), and M6 (grouping and aggregation), with ten testbeds for each of them, respectively. First, a seed (AML document) was manually created for each testbed according to the type of semantic mapping. Next, we automatically generated two AML documents derived from this seed containing a random number of conflicting AML elementsFootnote 5. The generation was performed following a uniform distribution. Testbeds corresponded to pairs of AML documents, and thirty testbeds were evaluated in the studyFootnote 6.
Gold Standard. To compile a Gold Standard, we relied on the generated testbeds. Formally, the Gold Standard corresponds to an ideal conflict-free Alligator document \(\varGamma ^*=\langle \theta ^*, V, F^*\rangle \), for each pair of the AML documents in the testbeds. The creation of the conflict-free document as well as the computation of the conflicting elements and different elements was performed manually.
Metrics. We measured the behavior of Alligator in terms of the following metrics:
-
(a)
Precision is the fraction of the conflicts identified by Alligator (i.e., \(SC(\varGamma )\)) that are conflicts in an AML document (i.e., conflicts(\(\varGamma \mid \varGamma ^*,\sigma \))).
$$\begin{aligned} Precision = \frac{|SC(\varGamma ) \cap conflicts (\varGamma \mid \varGamma ^*,\sigma )|}{|SC(\varGamma )|} \end{aligned}$$ -
(b)
Recall is the fraction of the conflicts in an AML document (i.e., conflicts(\(\varGamma \mid \varGamma ^*,\sigma \)) that are identified by Alligator (i.e., \(SC(\varGamma )\)).
$$\begin{aligned} Recall = \frac{|SC(\varGamma ) \cap conflicts (\varGamma \mid \varGamma ^*,\sigma )|}{| conflicts (\varGamma \mid \varGamma ^*,\sigma )|} \end{aligned}$$ -
(c)
F-measure is the harmonic mean of Precision and Recall.
Implementation. Experiments were run on a Windows 8 machine with an Intel I7-4710HQ 2.5 GHz CPU and 8 GB 1333 MHz DDR3 RAM. We implemented the Deductive System Engine as a meta-interpreter in Prolog that follows the semi-naïve bottom-up evaluation of Datalog programs [7]; we utilized SWI-Prolog version 7.2.3 and the Prolog Development Tool (PDTFootnote 7). An AML extraction module was developed as a part of Krextor to transform AML documents into RDF graphs. This module comprised a set of mapping rulesFootnote 8 that are executed in Krextor to create RDF graphs using the AML vocabulary. Further, the transformation of the RDF files into Datalog extensional predicates was implemented in Java 1.8. The Alligator framework, the testbed generator, and the testbeds evaluated in this experiment are publicly available on GitHubFootnote 9.
Size of the Integrated AML Documents. The goal of this evaluation was to analyze the size of the integrated AML documents with respect to conflicting and different elements. For each type of semantic heterogeneity and testbed of that type, we computed the number of conflicts solved by Alligator. Further, the number of different AML elements was measured; a different AML element corresponded to an element that appeared in one of the AML documents in the testbed, and was not conflicting with any other AML element. For example, the AML elements in line 15 of the two views in Figs. 2a and 2b are different elements. In consequence, both should be included in the integrated AML document. On the other hand, the AML elements in lines 2, 4, 6, 9, and 12 in both views are pair-wise conflicted AML elements, and each pair should be integrated into only one AML element. Figure 2 reports on the number of conflicted and different AML elements. We observed that a large number of AML elements in the integrated AML documents result from solving the Conflict Resolution problem; being the number of these AML elements at least 25 % of the total elements in the integrated documents. These results illustrated the complexity of the evaluated testbeds, and clearly showed the enhancement assessed by Alligator during the integration of AML documents.
Effectiveness of Alligator The goal of this experiment was to answer our research questions RQ1 and RQ2. Alligator was run on each of the 30 testbeds to create \(SC(\varGamma )\), and precision, recall, and F-measure were computed according to the Gold Standard (\(\textit{conflicts}(\varGamma \mid \varGamma ^*,\sigma )\)). Table 1 reports on the values of these metrics for each type of semantic heterogeneity, i.e., M2, M3, and M6. We observed that for these semantic heterogeneity types, the value for precision is 1.0, i.e., Alligator correctly detected all the conflicting elements in \(\textit{conflicts}(\varGamma \mid \varGamma ^*,\sigma )\). Further, recall and F-measure are also 1.0 in the testbeds of semantic heterogeneity M2. These results suggest that Alligator rules capture the knowledge required to accurately solve the AML Conflict Identification problem. For the semantic heterogeneity types M3 and M6, Alligator rules are not completely covering all possible conflicts generated between nested structures composed of conflicting AML elements. Thus, Alligator could not identify at most two conflicts in five out of 20 testbeds of type M3 and M6. These results allowed us to positively answer research questions RQ1 and RQ2.
7 Related Work
In the literature, many different approaches are proposed for integrating CAEX documents. In [18], a tool to map two CAEX files is presented. It allows to integrate the AutomationML documents, their respective descriptions, and the modified parts of one file into the other. Further, a mapping algorithm for CAEX files is presented. Nevertheless, the process of mapping is performed manually. Himmler [10] presents a framework to create standardized application interfaces in plant engineering based on AutomationML. The work provides a function-based based standardization framework for the plant engineering domain. Persson et al. [14] utilize an RDF-based approach to integrate robotized production information modeled with AutomationML. Kovalenko et al. [12] explore how AutomationML can be represented by means of Model-Driven Engineering and the Semantic Web. A small part of an AutomationML ontology is developed, based on the main concepts of the language. Also, the use of rules for consistency checking is proposed, using the Semantic Web Rule Language (SWRL), but no explicit definition of the role of Semantic Web technologies on the integration problem is presented. The AutomationML Analyzer [16] is an online tool to browse, query and analyse different AML data by means of Semantic Web technologies; a conceptual design to overcome integration problems in AML is described. All these approaches have the potential to solve specific integration problems for AML. However, they solve rather isolated problems, and a general method capable to automatically integrate AML information from different perspectives is not provided. Contrary, Alligator combines deductive databases and Semantic Web technologies to effectively integrate documents specified using Industry 4.0 Standards like AML.
8 Conclusions and Future Work
This paper presented Alligator, a deductive framework for the integration of AML documents. Alligator relies on Datalog and RDF to accurately represent the knowledge that characterizes different types of semantic heterogeneity in AML documents. The results of the empirical evaluation indicate that Alligator is able to effectively solve the problems of AML Conflict Identification and AML Conflict Resolution, and exhibits similar behavior for the three studied semantic heterogeneity types, i.e., granularity (M2), schematic (M3), and grouping (M6). In the future, we will empower the Alligator Deductive System Engine with the expressiveness of Datalog with negation and built-in predicates. Thus, Alligator will be able to represent other types of semantic heterogeneity in AML, e.g., value processing (M1) and conditional mappings (M4). Further, we plan to extend Alligator to integrate documents of other Industry 4.0 Standards, such as the OPC-UA machine-to-machine communication protocol.
Notes
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
References
Abele, L., Kleinsteuber, M., Hansen, T.: Resource monitoring in industrial production with knowledge-based models and rules. In: PIKM@CIKM, pp. 35–42. ACM (2011)
Abele, L., Legat, C., Grimm, S., Muller, A.W.: Ontology-based validation of plant models. In: INDIN, pp. 236–241. IEEE (2013)
Barnes, M., Finch, E.L.: COLLADA-Digital Asset Schema Release 1.5.0 specification. Khronos Group, Sony Computer Entertainment Inc (2008)
Biffl, S., Kovalenko, O., Lüder, A., Schmidt, N., Rosendahl, R.: Semantic mapping support in AutomationML. In: ETFA, pp. 1–4. IEEE (2014)
Björkelund, A., Bruyninckx, H., Malec, J., Nilsson, K., Nugues, P.: Knowledge for intelligent industrial robots. In: AAAI Spring Symposium: Designing Intelligent Robots, vol. SS-12-02. AAAI (2012)
Björkelund, A., Malec, J., Nilsson, K., Nugues, P.: Knowledge and skill representations for robotized production. In: Proceedings of the 18th IFAC Congress, Milan (2011)
Ceri, S., Gottlob, G., Tanca, L.: What you always wanted to know about datalog (and never dared to ask). IEEE Trans. Knowl. Data Eng. 1(1), 146–166 (1989)
Fedai, M., Epple, U., Drath, R., Fay, D.: A metamodel for generic data exchange between various CAE systems. In: 4th Mathmod Conference, vol. 24, pp. 1247–1256 (2003)
Henßen, R., Schleipen, M.: Interoperability between OPC UA and AutomationML. In: Procedia CIRP 25 8th International Conference on Digital Enterprise Technology DET (2014)
Himmler, F.: Function based engineering with automationml - towards better standardization and seamless process integration in plant engineering. In: 12 Int. Tagung Wirtschaftsinformatik, WI (2015)
Kovalenko, O., Euzenat, J.: Semantic matching of engineering data structures. In: Bill, S., Sabou, M. (eds.) Semantic Web for Intelligent Engineering Applications, Springer (2016)
Kovalenko, O., Wimmer, M., Sabou, M., Lüder, A., Ekaputra, F.J., Biffl, S.: Modeling automationml: semantic web technologies vs. model-driven engineering. In: 20th IEEE Conference on Emerging Technologies and Factory Automation, ETFA, pp. 1–4 (2015)
Lange, C.: Krextor - an extensible XML\(\rightarrow \)RDF extraction framework. In: Scripting and Development for the Semantic Web (SFSW), CEUR Workshop Proceedings, Aachen, vol. 449, May 2009
Persson, J., Gallois, A., Björkelund, A., Hafdell, L., Haage, M., Malec, J., Nilsson, K., Nugues, P.: A knowledge integration framework for robotics. In: 41st International Symposium on Robotics and ROBOTIK 2010 (2010)
Runde, S., Dibowski, H., Fay, A., Kabitzsch, K.: A semantic requirement ontology for the engineering of building automation systems by means of OWL. In: ETFA. IEEE (2009)
Sabou, M., Ekaputra, F., Kovalenko, O., Biffl, S.: Supporting the engineering of cyberphysical production systems with the automationml analyzer. In: 2016 1st International Workshop on Cyber-Physical Production Systems (CPPS), pp. 1–8. IEEE (2016)
Schleipen, M., Gutting, D., Sauerwein, F.: Domain dependant matching of MES knowledge and domain independent mapping of automationml models. In: 2012 IEEE 17th Conference on Emerging Technologies and Factory Automation (ETFA), pp. 1–7. IEEE (2012)
Schleipen, M., Okon, M.: The CAEX tool suite - user assistance for the use of standardized plant engineering data exchange. In: 15th IEEE International Conference on Emerging Technologies and Factory Automation, ETFA (2010)
Schmidt, N., Lüder, A.: AutomationML and eCl@ss integration (2015)
Schmidt, N., Lüder, A.: White paper: automation ML in a nutshell. Technical report (2015)
Schmidt, N., Lüder, A., Rosendahl, R., Ryashentseva, D., Foehr, M., Vollmar, J.: Surveying integration approaches for relevance in cyber physical production systems. In: ETFA, pp. 1–8. IEEE (2015)
Acknowledgements
This work has been supported by the German Federal Ministry of Education and Research (BMBF) in the context of the projects LUCID (grant no. 01IS14019C), SDI-X (no. 01IS15035C), and Industrial Data Space (no. 01IS15054).
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Rights and permissions
Copyright information
© 2016 Springer International Publishing AG
About this paper
Cite this paper
Grangel-González, I. et al. (2016). Alligator: A Deductive Approach for the Integration of Industry 4.0 Standards. In: Blomqvist, E., Ciancarini, P., Poggi, F., Vitali, F. (eds) Knowledge Engineering and Knowledge Management. EKAW 2016. Lecture Notes in Computer Science(), vol 10024. Springer, Cham. https://doi.org/10.1007/978-3-319-49004-5_18
Download citation
DOI: https://doi.org/10.1007/978-3-319-49004-5_18
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-319-49003-8
Online ISBN: 978-3-319-49004-5
eBook Packages: Computer ScienceComputer Science (R0)