Engineers of complex industrial automation systems need engineering knowledge from both design-time and runtime engineering models to make the system more robust against normally hard to identify runtime failures. Design models usually do not exist in a machineunderstandable format suitable for automated failure detection at runtime. Thus domain and software experts are needed to integrate the fragmented views from these models. In this paper we propose an ontologybased engineering knowledge base to provide relevant design-time and runtime engineering knowledge in machine-understandable form to be able to better identify and respond to failures. We illustrate and evaluate the approach with models and data from a real-world case study in the area of industrial automation systems. Major result was that the integrated design-time and runtime engineering knowledge enables the e ective detection of runtime failures that are only detectable by combining runtime and design-time information.
Complex industrial automation systems need to be exible to adapt to changing business situations and to become more robust against relevant classes of failures. Production automation systems consist of components, for which a general design and behavior is de ned during the design phase, but much of the speci c design and behavior is de ned during implementation, deployment, and runtime with a range of con guration options. The educational process plant is used to simulate complex industrial batch processes (like re neries, breweries, or pharmaceutical plants). It consists of two tanks holding the process uids. The liquid level of the tanks are checked by several analog and digital sensors. The lower tanks also contains a pump which either transports the process uid into the upper tank, or is used to mix up the process uid in the lower tank. Also the lower tank contains a heater and a temperature sensor to heat the process uid to speci ed temperatures. Figure 1 shows on the left hand side an image of the real system, while the right hand side of the gure displays a simpli ed version of the underlying data model of the educational process plant. Additionally, some of the data models elements have been colored in the same color as their realworld representation in the image of the educational process plant in order to show the links between real-world system and underlying data model.
Engineers, who want to detect failures at runtime which can not be compassed
by analyzing singular sensor values or failures at sensor-less components (e.g.
broken actuators which are not monitored by a sensor), need information from
software models that re ect dependencies between components at design and
runtime, e.g., the workshop layout, recipes and production procedures. During
development design-time software models (representing electrical, mechanical,
and software engineering models), like data-oriented models (e.g., EER models or
P&ID1 (Piping and Instrumentation) diagrams [
Practitioners, especially designers and quality assurance (QA) personnel, want to make complex industrial automation systems (which like the educational process plant consist of components de ned by general design-time behavior, derived runtime con guration, and runtime speci c behavior enactment) more robust against normally hard to identify runtime failures. QA people could 1 Industrial standard for P&IDs: IEC 61346: Industrial systems, Installations and Equipment and Industrial Products Structuring Principles and Reference Designations bene t from more e ective and e cient tool support to check system correctness, by improving the visibility of the system defect symptoms (e.g., exceptions raised from assertions).
Challenges to detect and locate defects at runtime come from the di
erent focus points of models: e.g., components and their behavior are de ned at
design time, while con gurations may change at runtime and violate tacit
engineering assumptions in the design-time models. Without an integrated view
on relevant parts of both design-time and runtime models inconsistencies from
changes and their impact are harder to evaluate and resolve between design and
runtime. Better integrated engineering knowledge can improve the quality of
decisions for runtime changes to the system, e.g., better handling severe failures
with predictable recovery procedures, lower level of avoidable downtime, and
better visibility of risks before damage occurs. As shown in [
In this paper we present an approach to improve support for runtime decision making with an ontology: a domain-speci c engineering knowledge base (EKB) that provides a better integrated view on relevant engineering knowledge in typical design-time and runtime models, which were originally not designed for machine-understandable integration. The EKB can contain schemes on all levels and instances, data, and allows reasoning to evaluate rules that involve information from several models that would be fragmented without machineunderstandable integration. The major advantage of using an ontology for representing and querying the domain-speci c engineering knowledge is the fact that ontologies are well suited to model logical relationships between di erent variables in axioms which can be used later for the derivation of assertions based on measured runtime data. We illustrate and evaluate the ontology-based approach with two types of runtime failure (RTFs) from a real-world use case study in the area of industrial automation systems. Major result was that the integrated design-time and runtime engineering knowledge enables the e ective detection of normally hard to identify runtime failures.
In the remainder of the paper we survey relevant engineering models for their contributions and limitations to support runtime decision making; we describe a real-world case on runtime failure detection for collecting evidence to which extent richer and better integrated semantic knowledge can translate into better decision making. 2
Evolution of Engineering Models towards Runtime System Analysis and Adaptation Engineering models have evolved from means to structure complex domains and designs at design time towards model-driven approaches that bring domain information closer to implementation and runtime. However, systems that are designed for adaptation at runtime need more advanced approaches to provide relevant and accurate engineering knowledge to guide runtime system analysis and adaptation.
Structuring design complexity. Models are used on various levels in
software engineering: Data models like entity relationship (ER) diagrams originate
in the late 1970s [
Connecting design and implementation. There are tool providers, who
claim to support round trip engineering from design models to source code and
back. However, a stronger and more consistent integration between the design
models and the implementation phase artifacts comes from the Model-Driven
Architecture (MDA), Model-Driven Development (MDD) [
Connections between design, implementation, and runtime.
Traditional software engineering approaches mostly focus on the development phase
and see con guration management (CM) as a support task. However, CM is an
example model that is valuable at design time, implementation, deployment, and
runtime. Some approaches thus suggest including CM and application life cycle
management (ALM) into the MDD concept [
Runtime needs of distributed recon gurable software-intensive
systems. Ahluwalia et al. [
Feedback of runtime experience to design. An underlying trend is to
bring development activities closer to the runtime environments, i.e., using data
from the deployed system for engineering purposes (e.g., QoS parameters).
Additionally, we observe more intensive research activities [
Ontologies for connecting design-time and runtime data models.
An ontology is a representation vocabulary for a speci c domain or subject
matter, e.g., production automation. More precisely, it is not the vocabulary as such
that quali es as an ontology, but the (domain-speci c) concepts that the terms in
the vocabulary are intended to capture [
In this section, we introduce the Engineering Knowledge Base (EKB), a set of relevant information elements about components in machine-understandable
format using ontology syntax. Components can query the EKB at runtime to retrieve information for detecting normally hard to identify failures or implausibilities of the current system.
Figure 2 illustrates 3 major phases in the life cycle of complex industrial automation systems: 1. Design time: Models that describe the automation system layouts, the recipes of the manufactured products, etc. are transformed into executable program code and design-time con guration instructions. 2. In the Deployment phase, the executable program code is deployed into installable packages and the runtime con guration is derived from the designtime con guration. 3. At runtime the deployed program code for system operation gets installed to a set of components and the runtime con guration gets injected into these components.
This architecture has proven e ective for systems whose properties change seldom, since the e ort needed for transformation, deployment, and injection is considerable.
However, typical complex industrial automation systems also su er from failures, e.g., if some components fail or become unavailable. To support failure detection, the components need to be able to perform decisions at runtime, since a complete new iteration of model transformation, program code deployment, and con guration injection would take too long. A major challenge of runtime failure detection is to provide access to relevant design-time information that is usually stripped away during transformation for e ciency reasons. The Engineering Knowledge Base (EKB) provides a place for storing design-time information that seems valuable for supporting runtime failure detection of components, especially in the case of handling failures or unplanned situations (but not transformed into runtime code or con guration to limit their complexity).
Components can query the EKB at runtime with semantic web query languages like SPARQL4 (SPARQL Protocol and RDF Query Language) or SWRL5 (Semantic Web Rule Language), which provide to the components the full expressive power of ontologies, including the ability to derive new facts by reasoning. In addition, components can feed back interesting observations into the runtime information collection of the EKB and therefore help to improve the design-time models (e.g., by improving estimated process properties with analysis of actual runtime data) and/or check the information based on a certain set of assertions. Furthermore, valuable deployment information can also be stored in the EKB in order to support and enhance for further deployments.
Based on the design-time information, it is possible to de ne a set of runtime assertions in the EKB. These runtime assertions observe the runtime information fed back into the EKB and can notify a speci c role or system if the violation of an assertion has been detected. 4
In this section we describe two real-world failure use cases which could lead to equipment defects and/or waste of used production material. Especially failures which are hard to identify by traditional means can lead to subsequent equipment damage and decrease of process performance. Therefore the identi cation of such failures is of great importance. We will show that such failures can be identi ed by usage of the EKB. We will also see that the EKB can provide soft sensors by simple (and therefore easy to implement in PLC (programmable logic controller) programs) reasoning of process data. The runtime assertions will be given in pseudo code samples. The assertions can be evaluated periodically, as it would be in a traditional PLC environment, or in regard to certain events, like the
change of a sensor value. As long as all needed sensor inputs and PLC outputs are available and stable, the current system status is correctly mapped.
The model we use to demonstrate our failure use cases is an educational
process plant in the Odo-Struger-Laboratory6. Figure 3 shows the P&ID
(Piping and Instrumentation Diagram) of the tank model. It consists of two tanks,
T101 and T102, which are on di erent height levels. The upper tank (T102)
contains an ultrasonic level sensor (B101) which measures the distance of the liquid
surface to the upper tank closure, and a oat lever which represents a critical
low level of the liquid. The lower tank (T101) consists of three oat levers (a
critical upper level (B114), a lower level (B104), and a critical lower level lever
(B113)), a heater (E104), and a temperature sensor (S111). The two tanks are
connected by several pipes which are opened or closed by several valves (the
symbols marked with V). Valves are usually not equipped with sensors to
determine their current state, due to nancial reasons. The liquid transportation
from the lower to the upper tank is done by the pump P101, The actual ow
caused by the pump is measured by the ow meter (B102). Even as this process
plant is an educational model it represents a typical plant con guration in the
process industry. Listing 1 shows some of the EKB's triples de ning the tank
T101 with blabla. For a complete listing of the EKB's triples representing the
P&ID model elements please refer to [
Listing 1. Example of EKB triples representing P&ID model elements <Tank r d f : ID="T102"> <c o n t a i n s >
<F l o a t L e v e r r d f : r e s o u r c e="#LS 102"/> </c o n t a i n s > <c o n t a i n s >
<L e v e l S e n s o r r d f : r e s o u r c e="#LIC 102"/> </c o n t a i n s > <connected To>
<P i p e C o n n e c t o r r d f : r e s o u r c e="#PC B102 1"/> </connected To> <connected To>
<P i p e C o n n e c t o r r d f : r e s o u r c e="#PC B102 2"/> </connected To> <c a p a c i t y r d f : d a t a t y p e="xml:# f l o a t " >1000.0 </ c a p a c i t y > </Tank>
RTF-1: Undetected valve V101 failure in the pump pipe section. In this scenario the liquid in tank T101 shall be pumped into tank T102. Therefore valve V104 must be closed and the valves V109 and V101 must be opened. We now assume that one or both valves that should be open are defect and therefore unable to get into the open position. As the control has no means to control the position of the valves the pump P101 starts. Such a situation can lead to the destruction of the pump, as it is either pumping against the impregnable 6 The industrial automation systems laboratory of the Automation and Control Institute, Vienna University of Technology resistance of valve V101, or it will be soon out of water as valve V109 inhibits further water supply, which leads to destruction by for example rotary pumps.
To avoid such equipment failure it is common to use a ow meter (B102 in
Figure 4), which can be used compare the actual ow with the anticipated ow
value. If those two values di er too much the pump can be put into an emergency
shut down. But if the ow meter is defect or the ow meter is omitted for cost
reduction, the failure can not be detected anymore. Such failures can lead to
huge costs due to equipment loss, material waste, and additional down times
and should therefore be avoided. Engineering knowledge can be used to provide
a simple rule to check the functionality of the pump system. As the upper tank
T102 has a level sensor it can be checked if the liquid level of the upper tank is
rising if the pump is activated. A more correct model would additionally be able
to determine if the level rising is proportional to the actual pump power. Through
consequent usage of engineering knowledge such \soft sensors" (instead of a real
sensor the value has been calculated from the process model) can be created.
By comparison of the measured and calculated ow value the system can also
determine if the ow meter or the pump is behaving as expected. Listing 2 shows
this query in pseudo code. For a complete listing of the query in full SPARQL
syntax please refer to [
Listing 2. Pseudo code query for detecting failures of V101 w h i l e ( P101 . i s A c t i v e ( ) ) f o r ( B102 . g e t S e n s o r E v e n t ( ) as x ) f o r ( B102 . g e t S e n s o r E v e n t ( ) as y ) i f ( x . getTimestamp ( ) < y . getTimestamp ( ) ) i f ( NOT ( y . g e t L e v e l ( ) > x . g e t L e v e l ( ) ) )
<< r a i s e alarm >>
RTF-2: Leakage in valve V102 with subsequent material loss. Such a failure can lead to enormous costs due to material waste, lower quality end product (perhaps even to low to sell), and wasted production time. Especially the wasted production time is costly as process engineering processes (like re ning and chemical processes in general) usually need long times to be completed. Such failures are hard to detect by conventional alarming mechanisms, as traditional alarms are only issued if a process value reaches a critical threshold.
In this scenario we assume that valve V102 is leaky (Figure 5), which is why the process material in tank T102 is slowly petering out. In an ordinary control program would only wait for a longer time until the liquid threshold de ned in the program is attained. There is no way to detect the leakage by simple sensor or alarm processing, only well grounded personnel in the control room can detect such a failure in a traditional PLC system.
Listing 3. Pseudo code query for detecting leakage in valve V102 w h i l e (NOT ( P101 . i s A c t i v e ( ) ) ) i f ( V102 . i s C l o s e d ( ) ) f o r ( B102 . g e t S e n s o r E v e n t ( ) as x ) f o r ( B102 . g e t S e n s o r E v e n t ( ) as y ) i f ( x . getTimestamp ( ) < y . getTimestamp ( ) ) i f ( NOT ( y . g e t L e v e l ( ) == x . g e t L e v e l ( ) )
<< r a i s e alarm >> w h i l e ( P101 . i s A c t i v e ( ) ) i f ( V102 . i s C l o s e d ( ) AND V104 . i s C l o s e d ( ) ) i f ( V109 . isOpen ( ) AND V101 . isOpen ( ) ) f o r ( B102 . g e t S e n s o r E v e n t ( ) as x ) f o r ( B102 . g e t S e n s o r E v e n t ( ) as y ) i f ( x . getTimestamp ( ) < y . getTimestamp ( ) ) i f ( NOT ( y . g e t L e v e l ( ) = x . g e t L e v e l ( ) P101 . getPumpPower ( ) ) )
<< r a i s e alarm >>
Once again the usage of engineering knowledge leads to rules capable to detect this failure. The rst rule is, if the pump P101 is not pumping and valve V102 is closed, then the uid level of tank T102 has to be constant. If there is a leakage in the valve then the level would sink. Assuming that the ow meter B102 is working correct the second rule is, if the valves V102 and V104 are closed, and the valves V109 and V101 are open, and the pump P101 is pumping, then the uid level of tank T102 must rise proportional to the actual pump power.
The rst rule is capable of detecting a leakage in tank T102, but the second
rule can only state that some condition is violated. The solution to this problem
is rather easy and e cient. If the second rule res than stop pump P101 and
reevaluate rule one for leakage detection. Another bene t of this behavior is that
the material loss is limited to the content of tank T102 or stopped altogether.
Listing 3 shows this query in pseudo code. For a complete listing of the query
in full SPARQL syntax please refer to [
In this paper we described an ontology-based approach to provide relevant design-time and runtime engineering knowledge stored in a so called Engineering Knowledge Base (EKB). The EKB provides a better integrated view on relevant engineering knowledge contained in typical design-time and runtime models in machine-understandable form to support runtime failure detection. This approach is useful in the industrial automation domain, and can more generally be used for other (distributed) engineering systems. We illustrated our approach with two use cases of runtime failure detection from a real-world case study in the area complex industrial automation systems. The use cases identi ed the needs for a complex decision system for failures that are only detectable by combining sensor information with engineering knowledge and showed a feasible query based approach suitable for the task.
Major result of the evaluation of the proposed EKB approach was the possibility to de ne assertions in the EKB which are checked based on the runtime information input of the running components. This can be seen as external Quality Assurance (QA) without interfering with the original production system and therefore it has proven to be easier to enrich existing applications without the need to make changes to legacy systems (smoother migration path). Further, the quality of information presented to an operator is improved since all information both from design-time as well as from runtime is available, leading to more intelligent runtime analysis and decision support.
Further important practical issues are to investigate the e ort needed to import the data from the relevant models into the Engineering Knowledge Base and improving the performance of data access and reasoning at runtime. The use of assertions for checking QoS parameters like system throughput is open to further research too.
This work has been supported by the Christian Doppler Forschungsgesellschaft and the BMWFJ, Austria. This work has been partially funded by the Vienna University of Technology, in the Complex Systems Design and Engineering Lab.