-Modern automation systems require both designtime and runtime integration of diverse engineering tools. Traditional integration approaches are based on repeating manual work, being time-consuming and error-prone. In this paper, applications of semantic integration, dealing with meaning of objects and their interfaces, is explained and shown on a real industrial use-case. Simulations are useful tools for process optimization or performance testing and the presented methodology makes their design for particular industrial plants flexible. The use-case shows that the design of simulation models for passive houses can be user-friendly and feasible even for non-experts as it is based on a graphical tool that enables to draw a passive house floor plan. Since neither this tool nor a universal simulation library, comprising atomic simulation blocks, were intended for simulation purposes, the presented methodology is a typical example of tool integration having heterogeneous data models. The goal of this paper is to propose an ontology-based formalization of knowledge representing structures of real industrial plants and simulation models. The paper also introduces the design of simulation models for passive houses from other engineering sources, which can be used by non-experts for simulation modeling. The practical usage is restricted by the fact that simulation parameters must be entered manually. The main contributions of the paper are the proposed structure of an automation ontology and a workflow of simulation model design that is not common in engineering disciplines.
Simulation models emerged as a very efficient way to optimize process operation. They can be used for performance testing of control algorithms or the whole industrial systems under both normal and extreme conditions, as well as for many other engineering tasks. Nevertheless, several issues dealing with simulation models have not been satisfactorily solved. The integration of simulation models and the cooperation with other engineering tools still remain problems as well as the high requirements on engineering knowledge and skills to create and configure them. Therefore, simulation models are usually designed and performed only by simulation experts.
HouseBuilder
Config.xml
file Plant ontology individuals
OWL Ontology Simulation model file
Simulation library file simulations. The presented approach is based on Semantic Web technologies. Knowledge about the tools under integration is stored in ontologies. Ontology-based querying and reasoning techniques are used to retrieve the information and derive new pieces of engineering knowledge. The proposed solution realizes an ontology-based middle-ware layer between the tools. A use-case project, dealing with a design of simulation models for passive houses, is described in this paper. It motivates the research, the examples from this domain are given, and in the final part, this use-case project is discussed and evaluated.
plant data in a machine-understandable way and to show the benefits of semantic integration of heterogeneous data models on a passive house model use-case.
and a universal simulation library “Bldsimlib” 1 comprising
generic simulation blocks for passive house simulation [
sources having heterogeneous data models that must be integrated involving meaning of data and interfaces. Floor plan of House Builder WPF software originally solves for visualizing passive house runtime data in a tool House
file without any modification for defining so-called plant ontology individuals, i.e. ontology-based representation of the passive house structure. Simulation blocks and their features are formalized in a so-called simulation ontology.
semantically create a simulation model for a passive house.
The remainder of this paper is structured as follows: the second section summarizes a related work. The third section formulates research issues that are addressed in the fourth section, summarizing a methodology for formalization of plant, simulation and other engineering knowledge in general, and in the fifth section, describing the use-case project and its results. The sixth section concludes and proposes further work topics.
diverse systems and tools, which is based on data meaning.
that is concerned with data transfers. Further explanation can
be found e.g. in [
The term ontology, originating from philosophy, is in
engineering defined in many ways [
niques such as DCOM, CORBA, J233 could be used [
The usage of ontologies in modeling and simulations is
introduced e.g. in [
ontologies: a domain ontology categorizing a knowledge including a problem vocabulary and its concepts are mapped onto a modeling ontology being used for the simulation model description. Our approach distinguishes between plant domain and simulation knowledge in a similar way.
in [
The methodology presented in this paper uses so-called
power bonds and signal bonds to classify a type of device
interconnection. These terms originate from a bond graph
theory, that is introduced e.g. in [
RI-1: Formalization of plant and simulation knowledge in general. As real plants have diverse structures and devices, there is a need for formalizing their description.
RI-2: Applications of the formalization for design of simulation model for a particular passive house. The particular use-case project integrates the two standalone engineering tools. A universal library Bldsimlib is implemented in MATLAB-Simulink6 and it comprises socalled generic simulation blocks. They approximate building elements, such as windows, walls, doors, or rooms. Usually, only simulation experts are able to create and perform the simulation model. We try to overcome this shortcoming by integrating the second tool, the graphical House Builder
is used to recognize a structure of the house. It is stored in a machine-understandable form and consequently, a simulation model is generated semi-automatically.
Domain of disturbances
Our approach is based on explicit distinction between plant, simulation, and other engineering knowledge. Plant knowledge is related to existing devices and elements, whereas simulation knowledge comprises features of available simulation blocks, e.g., their interfaces. We store plant knowledge in a so-called plant ontology, and simulation knowledge in a so-called simulation ontology. Further, we define supplemental ontologies such as a signal ontology.
Specification of fundamental domains and their relationships is introduced in Fig. 2. The upper left set represents a real plant domain. The figure depicts that real plants comprise devices, that are connected by two basic domainspecific terms: “signal bond” and “power bond”, that we use in compliance with bond graph theory to define the real device interconnections. We consider a measuring and control system as one domain, which interacts with the real plant domain via properties “measures” and “controls”. We explicitly define disturbances, i.e. factors that influence the real plant and that are usually not desired from a control point of view. For example, when controlling a temperature in a house, disturbances are the sun, humans, or opening and closing doors as they impact on the controlled variable. Simulation models are interconnected with a real plant via the relation “simulates”, expressing that some real plant device is approximated by the particular generic simulation block.
composition of power bonds for signal-oriented simulators, such as MATLAB-Simulink. Figure 3 depicts a description in the plant ontology and the corresponding schema in
of the bonds is realized while assembling the simulation model in Java code, performing series of SPARQL queries.
real plant and simulation, the relationship between these ontologies are realized via relations summarized in the previous paragraph. All of the ontologies and their relationships build a so-called automation ontology, being depicted in Fig. 4. The rectangular blocks represent ontology classes, whereas the rounded blocks are ontology individuals. For better readability, some individuals are omitted, but the fundamental ideas are covered by this figure. We can see the classes filled in blue color that represent an upper layer, shared within diverse automation systems. The plant ontology comprises real industrial plant devices, which are categorized into five classes. “Actuator” class involves controllable devices, “Passive Element” represents uncontrollable devices. “Disturbance” affects real plant, it defines boundary conditions and it is often non-measurable and random. “Measure point” defines sensors or softsensors that are software algorithms calculating a value from other variables. Blocks filled in yellow color depend on a type of a particular plant, in our case an example passive house classes are depicted (further classes were omitted for better readability). The simulation ontology comprises the description of available simulation libraries and final simulation models including their interfaces. Since industrial devices and tools usually requires information about not only the connections, but port numbers as well, the individuals of “Port” are depicted.
types. Last but not least, “Power Bond Decomposition” labels doubles of ports that decompose power bonds, i.e. they define signal routing in signal-oriented tools.
Although a structure of the automation ontology could seem complicated at first, it provides powerful support for diverse engineering tasks. Furthermore, it is not expected to be modified by hand in a general-purpose ontology editor, but either in specialized editors implemented for automation purposes or via specialized tools such that a user does not interact with this ontology at all. The latter case is used in the passive house use-case presented in this paper, as the plant ontology is created semi-automatically by the parser owl:Thing Plant Simulation
Port of a passive house floor plan. Although the description of simulation model blocks, i.e. a simulation ontology, a port ontology and a power bond ontology must be entered by humans, we are implementing a tool that supports this work and makes it easy and user-friendly.
Since simulation parameters, i.e. parameters required for the parametrization of simulation blocks, can differ from parameters of real plant devices in both count and scale, every generic simulation block has the parameters described in the simulation ontology. A special kind of parameters are initial conditions that are managed in a similar way as parameters in our approach. Known parameters of real plant devices are stored in a plant ontology. Nowadays, the translation of plant parameters to simulation parameters have not been satisfactorily solved in the presented prototype.
as semi-automatic, meaning that structural issues are solved automatically but the parameters are managed manually.
tic engine can semi-automatically assemble the simulation model for a particular plant. It finds all real plant devices (i.e. individuals of the plant ontology) and according to the ontology property “simulates”, a set of simulation candidates and their interfaces are retrieved for each plant device via
the research issue RI-2, i.e. to create a simulation model for a passive house, whose floor plan is drawn in House
selecting and interconnecting generic simulation blocks from a universal library Bldsimlib, implemented in MATLAB
and the universal simulation library have heterogeneous data models.
Figure 6 depicts a use-case passive house floor plan in
a simplified house, consisting of two rooms, walls and interior equipment. As it is very simplified, it enables to show our approach in a clear way and it does not pose any restriction in generality. An exemplary piece of the
House Builder config.xml file that gives information consequently used to create individuals of passive house ontology, i.e. the instances of rooms and walls are created and their interconnections are inserted as object ontology properties. The presented version of the algorithm supports rooms and walls only, but the functionality is planned to be extended for further elements support. Some elements must be recognized in a non-intuitive way, as House Builder does not express them. For example, there is no graphical element representing doors or windows, but there are so-called sensors measuring and visualizing position of sun-blinds or position of door. This is done by intended functionality of House Builder WPF oriented on passive houses, where windows are expected usually equipped with sun-blinds and furthermore, the floor plan need not to be absolutely exact in all details as it monitors the operation of the whole automation system of the house.
keywords creates plant ontology individuals. The parsing is done via Java code and creating individuals is realized by
While having the passive house representation in the plant ontology, that is a tool-independent representation of the object, the semantic engine generates the simulation model. The simulator-independent part of the engine is implemented in Java. It is called from supporting MATLAB script, where simulation blocks and signal interconnections are entered via MATLAB API using functions add_block and add_line. As we assume that there is available a simulation library comprising generic simulation blocks, the creating of models means selecting appropriate library blocks, entering them into a simulation model file, setting their name uniquely and interconnecting them according to the real plant structure. To run the simulation model, also simulation parameters must be added, but as this issue
Universal libraryfor environmental quantities modeling of residential buildings
Objectsin rooms Zones(rooms, exterior, ground) Interactionsbetween zonesand ventilation N_man NN__cwhoimldanHuman out K_activity human Heat sourceout heat (W) heat Universal source source Gascooker cooker Plant plant Bath/shower bathroom
out t (deg C) ROOM CO2 (ppm)
RH (%) p (kPa) bldsimlib_room
out t (deg C)
CO2 (ppm) EXTERIOR RH (%) p (kPa) sun wind bldsimlib_exterior
out t (deg C) Ground CO2 (ppm)
RH (%) p (kPa) bldsimlib_ground
Extender extender 12 Interaction 21
interaction 1 2 O/C Window 12 {0;1}ocwindow 1 Window 21 2 bldsimlib_window 1 2 Interior DOOR 21 {0;1} bldsimlib_door 12 WALLt (deg C21) bldsimlib_wal 1 Leakage 1 2 (ext) (ext) 2
leakage 12Leakage (simple)21 leakage_s 12 Exhaust fan 12
exhaust 1<0;1>Vveennttiillaattoorr 12 2 1<0;1>dDaammppeerr 21 2 Exhaust Outlet HVAC unit Source Inlet
hvac 1 Ext p_1 Blower door tester 1 p_2 p_3 blower_door_tester
Exhaust Source exceeds the size of this paper, we will address it in future work. The high-level overview of the used Bldsimlib library is depicted in Fig. 7. The emphasized generic simulation blocks are supported in the current version, i.e., simulation blocks of exterior, room, and wall are used in generated model.
The semi-automatically generated model of the passive house is depicted in Fig. 8. The upper left block represents an exterior, i.e., it defines borderline conditions for the simulated house. Simulation blocks in the central column represent rooms and the blocks in the right part of the figure approximate walls. The depicted simulation model does not export its outputs into a file or MATLAB Workspace and although it would be possible to set all variables as outputs automatically, we expect either the user of a simulation model would define the outputs or in the planned extended version, the outputs will be defined by ontology property “measures” as well as the inputs will be entered via ontology property “controls”. In this use-case simulation model, a limitation of the current implementation is apparent: The walls that separate two same areas are not merged into one wall. In other words, each room in the generated model has four walls, but they could be merged into two walls without changing the functionality - one wall to exterior and one to the other room. This issue could be solved on the level of the configuration file parser, but we consider this problem being general. As it occurs in many real-life systems, we plan to handle this situation on a plant ontology level. The problem exceeds this paper; it is planned for future work. Last but not least, the positions of blocks are done by a rectangular matrix and signal wires use auto-routing available in MATLAB; the positioning is planned to improve. out t (deg C)
CO2 (ppm) EXTERIOR RH (%) p (kPa) sun wind ext
out t (deg C) ROOM CO2 (ppm)
RH (%) p (kPa)
out t (deg C) ROOM CO2 (ppm)
RH (%) p (kPa) 12 WALL 1 2 t (deg C) wall107 12 WALL 1 2 t (deg C) wall103
This paper describes the usage of ontology-based representation of plant, simulation, and other engineering knowledge. The information is structured in order to generate simulation models semi-automatically and to support the designphase of automation system. The presented methodology is demonstrated on the real industrial use-case project dealing with the design of simulation model for a passive house. As the approach is oriented (but not limited) for signal-oriented simulators, such as MATLAB-Simulink, the attention is paid into decomposition of power bonds to the doubles of signal bonds, supported by such tools. The use-case illustrates generating simulation model structure from the floor plan created in the particular graphical tool. As the data models of available simulation library and floor plan configuration file have different structure, it is shown that the information is recognized in the parser and afterwards, plant ontology individuals are created. Consequently, the simulation model is created semi-automatically by the semantic engine that is general-purpose in terms of applicability on various types of industrial plants.
The proposed methodology guarantees avoiding structural errors, reduces manual and error-prone work, and saves development time and costs. The restriction of the presented methodology is a need for entering simulation parameters manually as well as some pieces of information are not covered in House Builder WPF, such as a topology of the HVAC system. In future work, we plan to extract the parameters from a so-called Passive House Planning Package (PHPP)7 that is the Excel script widely used in civil engineering to calculate and evaluate thermal and other properties of passive houses. Other future work issues are the support for simulation model input and output management, that will work not only on the simulation model and visualization level but as well on the run-time level. Further future work topics are a positioning of simulation blocks and signal wires to obtain better readability for humans, and automatic merging simulation blocks on the ontology level.
the Christian Doppler Laboratory for Software Engineering
sions and feedbacks. This work has been supported by the