Semantic Data Integration: Tools and Architectures

Abstract

This chapter is focused on the technical aspects of semantic data inte-gration that provides solutions for bridging semantic gaps between common project-level concepts and the local tool concepts as identified in the Engineering Knowledge Base (EKB). Based on the elicitation of use case requirements from automation systems engineering, the chapter identifies required capabilities an EKB software architecture has to consider. The chapter describes four EKB software architecture variants and their components, and discusses identified drawbacks and advantages regarding the utilization of ontologies. A benchmark is defined to evaluate the efficiency of the EKB software architecture variants in the context of selected quality attributes, like performance and scalability. Main results suggest that architectures relying on a relational database still outperform traditional ontology storages while NoSQL databases outperforms for query execution. In large-scale systems engineering projects, like power plants, steel mills, or car manufactures, the seamless cooperation and data exchange of expert knowledge from various engineering domains and organizations is a crucial success factor (Biffl et al. 2009a). This environment consists of a wide range of engineering systems and tools that differ in the underlying technical platforms and the used data models. Each domain or organization usually prefers using their own well-known models, from now on referred as local tool models. In order to successfully develop projects, it is essential to integrate important knowledge of different domain experts. However, these experts usually prefer using their well-known local tool models. In addition, they want to access data from other tools within their local data repre-sentation approach (Moser and Biffl 2012). The standardization of data interchange is one of the most promising approaches (Wiesner et al. 2011) to enable efficient data integration that allows experts to continue using their familiar data models and formats. This approach is based on agreeing on a minimal common model for data exchange that represents the common concepts shared among different disciplines on project level. Chapter 2 presented main use cases with typical process steps during the engineering phase within the life cycle of production systems. Selected scenarios focused on the capability to interact appropriately within a multidisciplinary engineering network while pointing out the need for a common vocabulary over all engineering disciplines involved in an engineering organization. The described challenges in the context of engineering data integration referred to a consistent production system plant model in order to support quality-assured parallel engi-neering, and the ability to access and analyze integrated data, e.g., for project progress and project quality reports. Versioning of exchanged information helps to improve change management and team collaboration over the course of the engi-neering project. As part of an efficient data management it is essential for process observations, project monitoring, and control across engineering disciplines (Moser et al. 2011b). As a common baseline it can be concluded that it is necessary to clearly dis-tinguish between local concepts of engineering tools and common concepts (Moser and Biffl 2010) (i.e., data sets representing heterogeneous but semantically corre-sponding local data elements) at project level. Consequently, interoperability between heterogeneous engineering environments is only supported if the semantic gap between local tool concepts and common project-level concepts can be prop-erly bridged. The Engineering Knowledge Base (EKB) (Moser and Biffl 2010) (see Chap. 4) provides the means for semantic integration of the heterogeneous models of each discipline using ontologies, and thus facilitates seamless communication, interaction, and data exchange. Semantic technologies are capable of linking cor-responding local concepts of engineering tools with each other via common project-level concepts representing the data integration needs of engineering dis-ciplines at their interfaces. 182 R. Mordinyi et al.