mantically heterogeneous engineering tool data models. In this paper, we adapt the ... In typical complex automation systems engineering projects, such as the ...
Semantic Tool Interoperability for Engineering Manufacturing Systems Thomas Moser and Stefan Biffl Christian Doppler Laboratory: Software Engineering Integration for Flexible Automation Systems Vienna University of Technology, Favoritenstr. 9/188, Austria {thomas.moser, stefan.biffl}@tuwien.ac.at Abstract Manufacturing systems engineering projects depend on contributions from several engineering disciplines. These contributions consist of complex artifacts like mechanical, electrical, and software components and plans. While the software tools are strong in supporting each individual engineering discipline, there is very little work on engineering processes automation across semantically heterogeneous engineering tool data models. In this paper, we adapt the Engineering Knowledge Base (EKB) concept, a semantic model, which extends the Global-as-View concept and explicitly models common engineering concepts and mappings using machineunderstandable syntax, for the engineering of manufacturing systems. We evaluate the concept based on a realworld use case for data exchange between software tools involved in the engineering of a manufacturing system software simulator. Major result is that the EKB concept sufficiently supports the semantic interoperability of tools to enable the automation of engineering processes.
1. Introduction In typical complex automation systems engineering projects, such as the engineering of manufacturing plants, a range of engineering disciplines needs to cooperate. While some engineering processes model contributions of engineers from different disciplines as a sequence of steps, in practice the engineers tend to concurrently update their artifacts, like documents and plans originating from different tools in the engineering process, to address new requirements and defect reports [3]. In multi-disciplinary engineering projects for manufacturing systems, there exist common concepts, such as customer orders or signals, on team level. However, the models in the engineering disciplines and their specific tools often use a range of terms and/or modeling structures to describe a given common concept, leading to semantically heterogeneous models [20]. Unfortunately, most engineering tools assume homogeneous data models, where concepts with similar meaning have also syntactically similar encoding. Therefore, these tools are
hard to seamlessly integrate into an engineering environment on team level. In this paper, we extend the Global-as-View concept [16, 21], which maps the data elements relevant for supporting specific engineering tasks in local tool data models to the respective elements in a common project/domain data model. Thus, typical engineering process steps such as version management of data models across tool boundaries can be automated as long as the relevant data elements can be linked to common engineering concepts. However, these common engineering concepts are only implicitly modeled and not available in machine-understandable form to enable process automation. We therefore introduce the Engineering Knowledge Base (EKB) concept, a layered semantic model, which builds on the Global-as-View concept and explicitly models the engineering concepts and mappings using machine-understandable syntax. Using these explicit models, the EKB can help automate time-consuming and error-prone process steps such as data exchange between proprietary and heterogeneous engineering tools. We evaluate the concept based on a real-world use case for data exchange between tools involved in the engineering of a manufacturing system software simulator, the so-called SAW (Simulation of Assembly Workshops) tool [12, 13], by comparing the original Global-as-View concept and the extended EKB concept using key indicators such as modeling effort, Quality Assurance (QA) efficiency, and support for engineering process automation. Data exchange between different manufacturing layers seems to be a good starting point in the broad scope of engineering model elements: it is important to synchronize data elements between manufacturing layers to cope with unplanned or erroneous behavior without interrupting the originally planned process. Major result is that the EKB concept supports semantic tool interoperability well enough to facilitate the automation of engineering processes by providing automated derivation of data transformation instructions and support for QA across tool boundaries. The remainder of this paper is structured as follows: Section 2 summarizes related work on automation systems engineering, on semantic integration of tool data models, and on the Global-as-View concept. Section 3
identifies the research issue and method. Section 4 describes the solution approach, while Section 5 presents the evaluation. Finally, section 6 concludes the paper and identifies further research work.
2. Related Work This section summarizes related work on automation systems engineering, on semantic integration of tool data models, and on the Global-as-View concept, a foundation for this work. 2.1. Automation Systems Engineering Automation systems (AS), such as complex industrial automation plants for manufacturing, depend on distributed software to control the system behavior. The behavior of AS must be testable and predictable to meet safety and quality standards. In automation systems engineering (ASE) software engineering depends on specification data and plans from a wide range of other engineering aspects in the overall engineering process, e.g., physical plant design, mechanical and electrical engineering, and production process planning. This expert knowledge is embodied in domain-specific standards, terminologies, people, processes, methods, models, and software. The weak semantic integration of the expert knowledge across domain boundaries of engineering aspects makes changes late in the engineering process risky [2]. Thus the traditional ASE process follows a strongly sequential procedure and suffers from a lack of systematic feedback to earlier steps, low engineering process automation, and weak quality management across domain boundaries, which leads to development delays and risks for system operation [10, 11]. One of the most prominent problems in current industrial development and research approaches is the lack of model integration between the engineering disciplines [3, 20]. Different and partly overlapping terminologies are used in the different disciplines, which often hampers understanding. E.g., in software engineering, the word “version” usually refers to the change of a piece of software over time. In mechanical engineering, however, a “version” is a new product that is the result of a complex design and development process, such as the new version of a car [9]. An example for a typical manufacturing system is the SAW (Simulation of Assembly Workshops) software simulator [12, 13]. This research assembly workshop of SAW is based on a miniature model situated at the Odo Struger lab of the Automation Control Institute (ACIN)1 at the Vienna University of Technology. The software simulator builds up the assemble line based on a production system simulation kit from Rockwell Automation International Research, situated in Prague [22]. SAW is used to create assembly lines out of agents like docking 1 http://www.acin.tuwien.ac.at/
stations, machines, conveyor belts, crossings and sensors was enhanced with further intelligence to simulate more complex behaviors, e.g., sorting machines and waiting loops, which are needed to simulate the production of more complex products consisting of parts where the assembly sequence is important. The focus of the SAW project lies on the engineering process of the described simulator. Therefore, the whole engineering process beginning on the business layer down to the technical workshop execution layer is represented. 2.2. Semantic Integration of Tool Data Models The problem of reconciling (data) schema heterogeneity has been a subject of research for decades, but solutions are few. The fundamental reason that makes semantic heterogeneity so hard to address is the independent origin of data sets using varying structures to represent the same (or overlapping) concepts [1, 5]. From a practical perspective, one of the reasons why schema heterogeneity is difficult and time consuming is that the solution requires both domain and technical expertise: a domain expert who understands the domain meaning of all schemas being reconciled and technical experts for writing transformations. Resolving schema heterogeneity is inherently a heuristic, human-assisted process. Unless there are very strong formal constraints on allowed schema differences, one should not hope for a completely automated solution. Therefore, the goal is to reduce the time it takes human experts to create a mapping between a pair of schemas, and enable them to focus on the hardest and most ambiguous parts of the mapping [19]. Semantic integration is defined as the solving of problems originating from the intent to share data across disparate and semantically heterogeneous data [8]. These problems include the matching of ontologies or schemas, the detection of duplicate entries, the reconciliation of inconsistencies, and the modeling of complex relations in different data sources [18]. One of the most important and most actively studied problems in semantic integration is establishing semantic correspondences (also called mappings) between vocabularies of different data sources [6]. The use of ontologies as a solution option to semantic integration and interoperability problems has been studied over the last 10 years. Noy [17] identified three major dimensions of the application of ontologies for supporting semantic integration: the task of finding mappings (semi-)automatically, the declarative formal representation of these mappings, and reasoning using these mappings. Ontologies allow modeling the common domain-specific view, tool-specific views, and the mappings between these views in one data model. A good starting point for semantic integration is both the analysis of the interfaces or export artifacts of the involved engineering tools, as well as the identification and analysis of available standards in the problem domain (e.g., AutomationML for the automation engineer-
ing domain). AutomationML2 (Automation Markup Language) is a neutral data format based on XML for the storage and exchange of plant engineering information, which is provided as an open standard [7]. A goal of AutomationML is to interconnect the heterogeneous tool landscape of modern engineering tools in their different disciplines, e.g., mechanical plant engineering, electrical design. AutomationML describes real plant components as objects encapsulating different aspects. An object can consist of sub-objects, and can itself be part of a bigger composition. An object can describe a screw, a claw, a robot, or a complete manufacturing cell in different levels of detail. The result of this analysis typically is a set of overlapping engineering concepts used in the engineering process. While this has proven to be true for well-established and long-running projects, the overlapping engineering concepts may not yet be known or elicited for projects in novel domains. In order to support future engineering projects, the knowledge regarding existing engineering projects should be used to derive guidelines to support similar future engineering projects. 2.3. Global-as-View Concept for Data Integration Global-as-View [21] is an information integration concept, which specifies relations of a global data schema as views on related local schemata. One specific implementation of the Global-as-View concept is the Engineering Database (EDB) The EDB [16] consists of (a) the data integration approach to align semantically heterogeneous tool-specific data models to a common domain model, (b) the version management approach based on data integration, and (c) the architecture and prototypical realization of tool support for data integration and version management. The EDB uses a so-called Virtual Common Data Model (VCDM) for modeling the exchanged information. The initial and implicit VCDM consists of all common engineering concepts that are used in an interface between two engineering disciplines. These common engineering concepts can be elicited from the current engineering process as these concepts can readily be found, e.g., in lists that engineers exchange as part of the process. Essentially, the VCDM is a project-wide data model of common engineering concepts for a selected scope of the automation system, e.g., a manufacturing plant. An important characteristic is that the VCDM is built bottom-up from the information that the engineering tools share on project level. Therefore, the VCDM can be built incrementally and contains only the data elements necessary for version management. One of the most powerful features is the ability to go back in the history of the EDB until its creation and simply retrieve the "historic" data or reset the EDB to an earlier state. Unlike local tools or data bases, the reset/revert/undo/rollback operations of the EDB can be 2 http://www.automationml.org/
performed any time later, even after a complete server restart, as the EDB stores the complete change history.
3. Research Issue and Method In ASE projects several engineering disciplines contribute artifacts that get updated concurrently and contain data elements, which need to be synchronized with the content of corresponding data elements in data models of other tools. While a common understanding among engineers in a project on engineering domain concepts can be achieved, the tool data models are often semantically heterogeneous and therefore hard to synchronize automatically. From this challenge we derive the following key research issue. RI: Effectiveness and efficiency of the extended EKB approach. We propose to extend the Global-AsView Engineering Database (EDB) concept [16] with semantic integration approaches to the needs of ASE projects with semantically heterogeneous engineering artifacts, resulting in the Engineering Knowledge Base (EKB) concept. Expected benefits of the EKB concept for the engineering of manufacturing systems are (a) engineering process automation based on the machineunderstandable model information and (b) the capability to perform ontology-based reasoning. We compare the capabilities of the extended EKB approach to the original Global-As-View EDB approach to evaluate concrete improvements of the new approach. We also investigate for relevant engineering process steps to which extent these process steps can be automated even if the tools involved use a variety of data structures and terminologies to express common concepts that define relevant inputs and outputs of the engineering step. We evaluate the EKB concept based on a real-world use case for data exchange between engineering tools involved in the engineering of a manufacturing system software simulator. For distributed engineering in heterogeneous environments, typically a set of different models is used along the engineering chain. In order to ensure validity and consistency of the overall engineering process, it is important to ensure that required data fields can be enforced during the whole lifecycle of the engineering chain, in this case between customer orders in an ERP system and concrete derived work orders in a manufacturing software simulation tool. We focus on these so-called common engineering concepts, since these concepts typically are the topics engineers coming from different engineering disciplines need to talk about as foundation for their effective cooperation. For illustration of the EKB approach we use the order, a basic design element of manufacturing automation systems that translates to specific customer orders and work orders. While every tool involved in the design process works with orders, the tool-specific data formats of orders differ greatly. Typical data analyses to be per-
formed are questions such as whether there exist any incomplete chains, such as unaddressed customer orders or work orders without links to a specific customer, between customer orders and work orders.
4. Solution Approach In this paper, we describe a generic approach for semantic integration in manufacturing automation systems engineering (see Figure 1) with a focus on providing links between data structures of engineering tools and systems to support the exchange of information between these engineering tools and thus making systems engineering more efficient and flexible. This approach, the Engineering Knowledge Base (EKB), is an ontologybased data modeling approach which supports explicit modeling of existing knowledge in machine-understandable syntax. We successfully applied the EKB approach both in general automation systems engineering, such as the engineering of large hydro power plants [14], and in software engineering, where we used the approach to integrate open-source software project data and calculate project metrics [4]. In this work, we adapt the EKB framework to the engineering of complex manufacturing automation systems and compare the usage of the EKB framework with the usage of the Global-asView [21] concept, implemented in the Engineering Database (EDB) [16]. The top part of Figure 1 illustrates the use case scenario with the EKB framework for engineering a manufacturing system. In this example, there are two types of tools that support engineers coming from two different domains, namely business tools such as an ERP system on the left hand side, and the SAW simulator on the right hand side. These tools contain local data sources, which produce and/or consume data with heterogeneous data structures. The EKB is used to facilitate the efficient data exchange between these tools and data sources by providing an explicit and machine-understandable representation of the so-called Virtual Common Data Model (VCDM). Based on this data exchange, more complex engineering process tasks like performing analyses across tools can be supported. The numbered tags in Figure 1 represent the process steps and major components of the EKB framework and are explained in detail in the following. 1. Extraction of Tool Data. As first step, the data elements contained in a particular tool need to be extracted make them available to the EKB framework. For this step the application program interfaces (APIs) or data export interfaces of engineering tools can be used. The exported data then is parsed and transformed into a generally readable format consisting of key-value pairs for each data attribute. 2. Storage of Extracted Tool Data. The extracted and transformed key-value pairs are stored using a Java Content Repository (JCR) implementation, the so-called
Engineering Data Base (EDB). For data storage, a tree structure is used, and additional functionality like versioning or roll-back is provided. 3a. Description of Tool Knowledge. For an integration scenario the tool ontologies define the engineeringtool-specific, proprietary view on the information exchanged (e.g., a list of customer orders). The data description includes the format of the information, but can also describe the meaning or the use of the specific view on the existing information, since there can exist multiple views for the same information. The most important part of this description is the definition of the exchanged information, i.e., the definition of the data structures provided and/or consumed by a tool. 3b. Description of Domain Knowledge. The domain ontology contains the relevant shared knowledge between stakeholders in the particular application domain (in our case the manufacturing automation domain) and hence represents the collaborative view on the information exchanged in an integration scenario. In addition, the domain ontology is the place to model standardized domain-specific information (e.g., domain standards, such as AutomationML, or the description of concepts used throughout an application scenario such as the application domain independent description of business orders or machines in the context of manufacturing automation systems). The proprietary information of the engineering tools, which is defined in the tool ontologies, is mapped to the more general information of the domain ontology in order to allow the interoperability with other engineering tools. In contrast to a common data schema, the knowledge stored in the domain ontology is defined on a more general domain level compared to the knowledge stored in the tool ontologies. 4. Mapping between Tool and Domain Knowledge. Each data structure segment described in the tool ontology is mapped to either exactly one particular corresponding domain concept or domain concept attribute described in the domain ontology, or to e.g., all inherited sub-concepts of a target concept. In addition, the granularity of the mapped elements does not need to be similar, e.g., a concept can be mapped to the attribute of another concept, or vice versa. This defines the semantic context of the information contained in the segment and allows detecting semantically similar information of other engineering tools. 5. Use of the EKB. The mapping of concepts described in the tool ontologies to common concepts described in the domain ontology allows the creation of data transformation instructions. These transformation instructions are the foundation to transform data structures between two engineering tools, because the engineering tools may label or format their data structures in different ways. Other possible usage scenarios of the EKB are the derivation of new facts using ontologybased reasoning, e.g., for defect detection across tool boundaries.
Figure 1. EKB for Manufacturing Automation Systems Engineering (adapted from [14]). Due to the mappings between tool ontologies and domain ontology data structures that are semantically equal can be identified, because they are either aligned to the same domain concept or belong to the same tree segment in the concept tree described in the domain ontology. The transformation instructions can be defined in XML syntax and consist of at least one input and output data structure segment. The segments contain a unique ID and instructions, how the input segment is transformed to an output segment. There is a set of basic transformations that can be combined to more complex transformations, like changing the name of a segment, converting the format using converters, merging or splitting a set of input segments or querying external services for transformation [15]. Based on these transformations, more complex applications can be implemented, which use the integrated data of the VCDM to perform advanced tasks like tracing of artifacts, consistency checking across tool boundaries, change impact analyses, or notification of stakeholders in case of changes.
5. Evaluation This section presents the evaluation of the EKB concept. First, the use case describing data exchange between engineering tools is pictured for both the EDB (an implementation of the Global-as-View concept) and the EDB/EKB approach (an ontology-based implementation). Then, the results of the comparison of the EDB and the EKB approaches are presented.
5.1. Data Exchange Between Engineering Tools To cooperate the engineers have to exchange relevant parts of the data structures (i.e., information required in another tool should become available as soon as it has been saved in the original tool) in their tools with each other with the goal of a consistent overall view on certain aspects in the project, e.g., when producing a specification for a subcontractor. Currently, every role uses organization-, domain-, and tool-specific data formats and terms, thus the data exchange takes considerable expert knowledge on the receiving end to make sense of the incoming data, typically a large PDF document or tool-specific import file [14]. EDB Approach. The exchange of data structures originating from different engineering tools using a common repository such as the EDB requires a set of prerequisites. Either, all participating tools need to agree on a common data schema used for the data structure exchange. All exchanged information is then structured according to this schema. While this is even hard for tools originating from the same engineering domain, it becomes nearly impossible for tools originating from different and typically heterogeneous domains. In addition, changes to one or more of the engineering tools regularly require an update of the common schema, which then needs to be forwarded to the other engineering tools, which use this schema. So the major functionality of the common repository is to store all information, while at the same time providing point-to-point integration between all participating tools using converters for each possible combination of the tools.
Once set up and configured properly, this data exchange method has a low delay, i.e., information made available by an engineering tool is quickly available for all other partner engineering tools. However, the configuration of this approach requires high effort, since converters need to be written for all needed pairs of n engi2 neering tools, with O(n ) required converters. In addition, the common repository is inflexible and fragile in case of changes to single engineering tools, since converters need to be adapted or rewritten in this case.
Figure 2. Translation between Business and Workshop Configuration Knowledge. EKB Approach. A first step in using the EKB framework is the identification of common concepts used in the participating engineering tools. These common concepts are then described in the Domain Knowledge Base (DKB), illustrated in Figure 2. As a next step, the proprietary tool-specific knowledge is mapped to the more general knowledge stored in the DKB. Based on these mappings, the EKB framework semi-automatically generates transformation instructions for transforming data structures between tool-specific formats. This semiautomated generation exploits the mappings stored in the EKB and makes initial suggestions for transformations to be reviewed by a human expert. The human expert then can revise the suggested transformations, change them, or add new or more complex transformation rules manually. Since for each of the n participating engineering tools a single transformation instruction is required, the number of overall needed transformation instructions is only O(n). While the EKB framework requires similar or at most slightly higher effort for setup and configuration compared to the common repository approach (EDB), new benefits come from using ontologies for storing the engineering knowledge. The ontologies enable the semiautomated generation of the required converters, both initially and when engineering tools evolve. The number of required converters is also smaller with O(n) converters for n engineering tools. Further, once set up, the delay of the data exchange method is similar to the delay using the common-repository-based approach. Figure 2 illustrates two different engineering-toolspecific terminologies of the SAW production automa-
tion system regarding orders. The business knowledge uses the concept ClientPurchase as a local terminology, while in the workshop configuration knowledge the concept WorkTask is used as a local terminology. As shown in Figure 2, both concepts are mapped to the corresponding domain concepts, CustomerOrder and WorkOrder respectively. In addition, the attribute Date of ClientPurchase is mapped to the attribute DueDate of WorkOrder, while the attribute Client of WorkTask is mapped to the attribute CustomerID of CustomerOrder. Further, in the Domain Knowledge Base the concepts CustomerOrder and WorkOrder are linked by their common attribute, Product and ProductID respectively. Using these mappings, we can identify work tasks which belong to a specific client purchase and identify the corresponding client purchase for a specific work task, without the need to establish a direct link or mapping between the two local terminologies. 5.2. Comparison of EDB and EKB concepts This section describes the evaluation of the EDB and the EKB concepts in detail. First, the results of the evaluation are summarized per evaluation criteria (see Table 1), then each evaluation criterion is described in detail. Modeling effort. The comparison of both approaches shows that the overall integration effort is similar for both approaches in case of small number of systems to be integrated and slightly higher for the EKB approach in case of larger systems. The higher effort comes from the need to manage the domain model, since additional mappings between the tool ontology and the domain model are needed. The effort to create the tool ontology or the tool interface description is similar since in both approaches the conducted Tool Experts has to cope with the same problem of finding the right information describing the tool interfaces with its semantics. The EKB approach has the advantage that in case of adaptation the knowledge already gathered is explicitly given and can be reused in further discussions compared to the traditional approach where this knowledge exists implicitly only. In case of reconfiguration issues the EKB process has proven to be more efficient than the EDB approach since once the knowledge has been externalized, it can be reused with little extra effort. Furthermore, in case of the traditional approach each Tool Expert has to be contacted for any kind of changes resulting in timeconsuming discussions and delays. In case of the EKB approach, the domain expert is needed in major changes only, where the mapping of the tool ontology to the domain ontology has to be altered as well. In case of minor changes, affecting the characteristics of single engineering tools only, the Tool Experts are needed. Additionally, performing changes, like structure modifications, based on documents is more difficult and time consuming than with ontologies that deal with classes.
Table 1. Comparison of Global-as-View Database (EDB) and Knowledge Base (EKB) approaches.
Modeling Effort
Engineering Database (EDB) Tool knowledge is either implicitly available or described in human-readable documents by tool experts.
No explicit domain knowledge used. Low Quality Assurance (QA) Efficiency
Domain knowledge is incrementally externalized as a machine-readable ontology by the Domain Expert. High
Individual tools provide model checking functionality for their models
Individual tools provide model checking functionality for their models
Manual checks of documents and models needed for cross tool QA.
Ontology-based reasoning allows quickly locating inconsistent knowledge across tool boundaries. High
Low Support for Engineering Process Automation
Engineering Knowledge Base (EKB) Tool knowledge is externalized in a machine-readable ontology by tool experts.
Domain expert coordinates the generation of transformation instructions with the 2 affected tool experts: O(n ).
Automated derivation of transformation instructions based on the explicit description of tool and domain knowledge: O(n).
Manual checks of documents and system configuration needed for cross tool QA.
Ontology-based reasoning allows quickly locating inconsistent knowledge across tool boundaries.
Changes can be performed much faster and can be done during the discussion concerning the integration project as well. The duration of the EDB approach tends to be higher due to error-prone mainly manual process steps resulting in additional efforts to discuss error sources and possible solutions. The proposed EKB approach reports errors or missing information immediately due to in-time consistency and completeness checks based on ontology reasoning. In case of describing systems, parallel processing is possible in both approaches. Quality Assurance (QA) Efficiency. Since the EDB approach primarily focuses on model checking functionalities of single engineering tools and therefore requires manual validity checks for cross tool QA, it is therefore more time consuming and error-prone. This also results in the fact that missing or incorrect information is often detected in a later engineering process step. The EKB approach uses ontology-based reasoning. This allows performing consistency and completeness checks across tool boundaries in-time automatically, resulting in a lower failure rate and in-time notification of the Tool Expert about missing/incorrect information. Support for Engineering Process Automation. In case of the EDB approach the effort for generating transformation instructions is higher than with the EKB approach because the derivation of those instructions has to be done manually. The EKB process step is performed automatically using ontology-based reasoning for deriv-
ing transformation instructions based on the explicitly captured knowledge. In addition, the EKB approach supports the user while entering the data with consistency and completeness checks.
6. Conclusion Manufacturing systems engineering projects depend on contributions from several engineering disciplines. Typically, the software tools for each individual engineering discipline provide relevant local tool features; however, these tools provide only little support for engineering process steps across semantically heterogeneous data models. In this paper we adapted the Engineering Knowledge Base (EKB) concept to the manufacturing automation systems domain. The EKB is a layered semantic model using ontologies, which builds on the Global-as-View concept [16, 21] and explicitly models the engineering concepts and mappings using machine-understandable syntax. We evaluated the EKB concept based on a real-world use case for data exchange between engineering tools involved in the engineering of a manufacturing system software simulator. Major results of the comparison of the ontology-based EKB approach to the database EDB implementation were: (a) Effort was similar. The EKB uses an explicit representation of the domain knowledge; therefore effort
is needed for the creation of this domain ontology. The effort to create the tool ontology or the tool interface description is similar since in both approaches the conducted Tool Experts has to cope with the same problem of finding the right information describing the tool interfaces with its semantics. In case of reconfiguration issues the EKB process has proven to be more efficient than the EDB approach since once the knowledge has been externalized, it can be reused with little extra effort. (b) Stronger QA and process automation. The explicit and machine-understandable knowledge representation of the EKB allows performing consistency and completeness checks across tool boundaries in-time automatically, resulting in a lower failure rate and in-time notification of the Tool Expert about missing/incorrect information. In case of the EDB approach the effort for generating transformation instructions is higher than with the EKB approach because the derivation of those instructions has to be done manually. The EKB process step is performed automatically using ontology based reasoning for deriving transformation instructions based on the explicitly captured knowledge. Future Work. Further research will include the enrichment of run-time information collected from the automation systems with design time engineering information. In addition, usability studies with involved expert roles will be performed in order to ensure the usefulness of the EKB approach with practitioners.
[6]
[7]
[8] [9]
[10] [11] [12]
[13]
[14]
[15]
Acknowledgements This work has been supported by the Christian Doppler Forschungsgesellschaft and the BMWFJ, Austria. The authors also want to thank the domain experts at their industry partners for their support and feedback.
[16]
References [17] [1]
[2]
[3]
[4]
[5]
Bergamaschi, S., Castano, S., and Vincini, M.: ‘Semantic integration of semistructured and structured data sources’, SIGMOD Rec., 1999, 28, (1), pp. 54-59 Biffl, S., Schatten, A., and Zoitl, A.: ‘Integration of Heterogeneous Engineering Environments for the Automation Systems Lifecycle’. Proc. IEEE Industrial Informatics (IndIn) Conference, 2009, pp. 576-581 Biffl, S., Sunindyo, W.D., and Moser, T.: ‘Bridging Semantic Gaps Between Stakeholders in the Production Automation Domain with Ontology Areas’. Proc. 21st Intl Conf on Sw Eng and Knowl Eng, 2009, pp. 233-239 Biffl, S., Sunindyo, W.D., and Moser, T.: ‘Semantic Integration of Heterogeneous Data Sources for Monitoring Frequent-Release Software Projects’. Proc. 4th Intl Conf on Complex, Int and Sw Int Sys, 2010, pp. 360-367 Doan, A., and Halevy, A.: ‘Semantic integration research in the database community: A brief survey’, AI Magazine, 2005, 26, (1), pp. 83-94
[18] [19]
[20]
[21]
[22]
Doan, A., Noy, N.F., and Halevy, A.Y.: ‘Introduction to the special issue on semantic integration’, SIGMOD Rec., 2004, 33, (4), pp. 11-13 Drath, R., Lüder, A., Peschke, J., and Hundt, L.: ‘AutomationML-the glue for seamless automation engineering’. Proc. IEEE Intl Conf on Emerging Technologies and Factory Automation (ETFA 08), 2008, pp. 616-623 Halevy, A.: ‘Why your data won't mix’, Queue, 2005, 3, (8), pp. 50-58 Lastra, J.L.M., and Delamer, I.M.: ‘Ontologies for Production Automation’: ‘Advances in Web Semantics I: (Springer, 2009), pp. 276-289 Lüder, A.: ‘Formaler Steuerungsentwurf mit modularen diskreten Verhaltensmodellen’. PhD, 2000 Medeia-Consortium: ‘Medeia: Requirements Analysis and Technology Review’, Medeia consortium, 2008 Merdan, M., Moser, T., Wahyudin, D., and Biffl, S.: ‘Performance Evaluation of Workflow Scheduling Strategies Considering Transportation Times and Conveyor Failures’. Proc. Intl Conf on Industrial Engineering and Engineering Management (IEEM), 2008, pp. 389-394 Merdan, M., Moser, T., Wahyudin, D., and Biffl, S.: ‘Simulation of Workflow Scheduling Strategies Using the MAST Test Management System’. Proc. 10th Intl Conf on Ctrl, Aut, Robo & Vision, 2008, pp. 1172-1177 Moser, T., Biffl, S., Sunindyo, W.D., and Winkler, D.: ‘Integrating Production Automation Expert Knowledge Across Engineering Stakeholder Domains’. Proc. 4th Intl Conf on Complex, Int and Sw Int Sys, 2010, pp. 352-359 Moser, T., Schimper, K., Mordinyi, R., and Anjomshoaa, A.: ‘SAMOA - A Semi-automated Ontology Alignment Method for Systems Integration in Safety-critical Environments’. Proc. 2nd IEEE Intl Workshop on Ontology Alignment and Visualization, 2009, pp. 724-729 Moser, T., Waltersdorfer, F., Zoitl, A., and Biffl, S.: ‘Version Management and Conflict Detection Across Heterogeneous Engineering Data Models’. Proc. 8th Intl Conf on Industrial Inf, 2010, accepted for publication Noy, N.F.: ‘Semantic integration: a survey of ontologybased approaches’, SIGMOD., 2004, 33, (4), pp. 65-70 Noy, N.F., Doan, A.H., and Halevy, A.Y.: ‘Semantic Integration’, AI Magazine, 2005, 26, (1), pp. 7-10 Rahm, E., and Bernstein, P.A.: ‘A survey of approaches to automatic schema matching’, VLDB Journal, 2001, 10, (4), pp. 334-350 Schäfer, W., and Wehrheim, H.: ‘The Challenges of Building Advanced Mechatronic Systems’. Proc. 2007 Future of Software Engineering, 2007, pp. 72-84 Ullman, J.D.: ‘Information integration using logical views’, Theoretical Computer Science, 2000, 239, (2), pp. 189-210 Vrba, P.: ‘MAST: manufacturing agent simulation tool’. Proc. IEEE Intl Conf on Emerging Technologies and Factory Automation, (ETFA '03), 2003, pp. 282-287
