The emergence of software-intensive systems connecting physical devices to network-based applications involves new design challenges. As an example, exible manufacturing systems composed of multiple networked devices in interaction with the physical world, are subject to imprecision and to unpredictable breakdowns. Applications and control software are therefore highly complex, and must operate in heterogeneous and rapidly changing environments. To address these issues, we describe an approach using models at runtime for e ciently monitoring and adapting the software controlling mechatronic devices. We consider a decentralized system, in which each device is represented as an agent. Each agent maintains a model integrating a representation of itself, of its environment and of the agent society, and uses this model to detect inconsistencies, to envision possible future states and to create explanations based on past states. In this paper, we focus on presenting our model and highlighting the results, bene ts and challenges arising from using models at run-time with networked physical devices.
The emergence of software-intensive systems connecting physical devices to
networkbased applications o ers new exciting possibilities. Among them, exible
manufacturing systems providing a faster, more e cient response to market changes
are envisioned [
To address these issues, we proposed an approach in which agents use
models for e ciently monitoring and adapting the software controlling mechatronic
devices. Each agent manages a model integrating a representation of itself, of its
environment and of the agent society, and enabling it to detect inconsistencies,
to envision possible future states and to create explanations based on past states.
In recent works [
This paper is structured as follows. Section 2 introduces some background and example about distributed intelligent control of a exible manufacturing system. Section 3 details the world model of an automation agent, forming the central piece of our approach. Section 4 discusses our results and lessons learned. Section 5 discussed related work and section 6 concludes with a summary. 2
As an example for monitoring and adapting software in interaction with networked physical devices, our current studies focuses on exible manufacturing systems. In this paper, we use the example of a pallet transport system, located in the Odo-Struder-Laboratory4. Due to their role to connect di erent parts of the system and to carry and route materials between them, transportation systems are in most cases seen as a key element, but the increasing need for more exibility signi cantly complicates the control of these systems.
Overview of the Pallet Transfer System The pallet transfer system (Fig. 1) consists of software-controlled manufacturing components: transport components such as conveyor belts (dark green lines) and diverters (yellow circles); and assembly machines (colored rectangles with round corners). Product parts are transported on pallets (colored rectangles; colors represent the target machines). Each pallet carries an RFID tag providing information on its destinations, which diverters can access through RFID readers (rectangles on conveyors). Figure 2 4 Industrial automation systems laboratory of the Automation and Control Institute,
Vienna University of Technology
Decision Making Low-Level Interface World
Model Repository
(a) Mechatronic component (diverter)
(b) Architecture of the automation agent (a) depicts the mechatronic component realizing a diverter. It is mainly composed of a switch (directing a pallet), sensors (detecting the presence of a pallet) and blockers (preventing a pallet from moving).
Architecture of an Automation Agent In order to support the design of
distributed intelligent control software for manufacturing systems, we introduced
a generic architecture for automation agents in [17]. The architecture is depicted
on Fig. 2 (b), and consists of two software layers, in addition to the
mechatronic component. The low-level control (LLC) layer is in charge of controlling
the hardware. The high-level control (HLC) layer is in charge of diagnostics, of
coordination with other agents and of self-adaption based on the representation
of the world. In the case of the diverter, a \diverter agent" contains a LLC layer
responsible for moving the switch depending on the destination of on incoming
pallets, and a HLC layer responsible for , e.g, rede ning routes in response to
disturbances at other components or validating sensor readings with information
from other agents. Distinguishing LLC and HLC within each automation agent
is fundamental for devices in interaction with the physical world. In our
architecture, the LLC is responsible for performing all necessary operations in real-time,
while the HLC is only responsible for non-functional monitoring and
adaptation, which might require longer computation time and interactions with others
agents or even with human operators. To enforce this layering while enabling
efcient adaptation, we base our LLC on the IEC 61499 standard, enhanced with
programmable recon gurations capabilities [
Figure 2 (b) also depicts more precisely the four main modules composing the inner architecture of the HLC. The world model repository contains a world model, i.e., a symbolic representation of the world of the agent. The low-level interface enables the HLC to monitor and to adapt the LLC. It especially provides facilities for receiving event noti cations about the current operations of the LLC and for requesting recon guration in the LLC. The communication manager provides facilities for managing the communication with other agents. The decision-making component is in charge of coordinating the reasoning about states of the world and deciding what to do (e.g., communicate with other machines, request an operation from the LLC, issue noti cations to an operator). Event noti cations generated by the LLC, by communication with other agents or by the world model trigger the decision-making procedures. 3
The world model plays a central role in the architecture of an automation agent. In this section, we describe its content and illustrate it using the example of the diverter agent. 3.1
Properties The world model has to provide two key properties. Firstly it should integrate information about di erent views of the world, which are sometimes overlapping.
Situation Model
Diverter connectsTo Conveyor hasInside Pallet hasOn SenderAgent
RoutingAgent sendsTo ReceiverAgent
It must integrate information about the state of its environment (the physical world in which it is evolving), about the agent society (the other agents with which it is interacting, their roles and tasks), and about its own internal structure and processes. Clearly, this is related to re ection, so the representation of the agent itself is a key element of the world model [17].
Secondly and most importantly, the world model must support a exible synchronization with the real world. In particular, it is in general not possible to assume that the model provides a complete and up-to-date view on the real world. We must cope with partial and scarce observations, and we use models to compensate for the lack of direct information with assumptions about what the state of the world should be. As a consequence, the model must be validated and revised anytime new information is received. More precisely, it should provide three key features: { The detection of inconsistencies between the current world model and new information (received from LLC or other agents). In a real world setting, inconsistencies may arise both from inaccuracy of the model on the one side, and from imprecision of the information sources on the other side. { The derivation of possible future states of the world and their relevant characteristics (answering \what-if" questions). It should be possible to de ne expectations about the future state of the world, and to plan meaningful observations accordingly. It should also be possible to envision multiple possibilities about the future in order to be prepared for adaptation. { The derivation of explanations from past states of the world (answering \why" questions). Although all information about the world may not be accessible, models can be used to explain current observations with assumption about past states of the world which could not be observed directly. In some casesw, this can trigger additional observation to con rm assumptions. This is particularly useful for diagnosis, when root causes for failures can be identi ed from reasoning on the world model. 3.2
Elements of the World Model The world model consists of two parts. Figures 3 and 4 illustrate the world model for the diverter agent example.
The situation model (Fig. 3) holds knowledge about the agent situation. The situation of an agent consists both of its own characteristics and its relations to other entities in the world. The domain models (top) are models of the type of entities in the domain of the agent. They de nes relevant classes of entities as well as relations between entities. For our example, we de ne that a diverter is connected to conveyors and can have a pallet located inside. Such concepts and relations can be extracted from existing models, such as the one presented in [12]. The facts (bottom) express the current knowledge about the world. Facts are expressed using the vocabulary de ned by the models. They represent an abstraction of some meaningful aspects of the world, which can be used for realizing high-level control tasks. For our example, facts express that D1 is a diverter, which is connected to conveyors C12, C25 and C33.
The activity model (Fig. 4) contains knowledge about the activities of the
agent, i.e., the events and processes occurring in the world in which the agent is
participating (as actor or observer). The classi cation of activities (top) models
the types of activities in which the agent can be involved. Types are de ned
formally using description logic formulas and are organized hierarchically based
on the subsumption relationship [
The expectations and observations (bottom) model the activities that are
expected and observed by the agent. Expectations and observations are de ned
by the speci cation of a type (based on the classi cation of activity types) and
timing, expressed using time intervals [
Runtime Synchronization The world model, and in particular the model of expectations and observations about activities, is synchronized incrementally, whenever new information is received from the LLC or from other agents. It is thus constantly evolving at runtime to re ect the current knowledge about the world as well as the current expectations that could be derived from this knowledge. Conversely, the changes in the model can be re ected in the underlying software, especially thanks to the LLC recon guration abilities.
Figure 5 depicts the general work ow for updating the model: 1. Integration. Whenever new information about the world is available, it is integrated in the world model by expressing the related type of activity and timing. 2. Identi cation. Forming a new observation requires identifying how it relates to existing expectations in the model. A matching is performed using the type and timing information. In case no expectation can be identi ed, an anomaly is reported. 3. Propagation. The addition of a new observation may trigger the creation of new expectations, Propagation occurs by considering dependencies beanomaly
Observation Activity Type + Timing LLC notification Agent message 2. identification 1. integration 3. propagation Derived
Expectations inconsistency delayed observation
Monitoring Task 4. scheduling
Action Task 5. activation Communication behavior
LLC feature We used the automation agent architecture and the world model as a basis for designing exible manufacturing systems. In this section, we summarize our results by giving an overview of tasks involving the world model at runtime. We then discuss some important points and lessons learned. We designed the automation agent architecture and its world model to be generic and to apply to di erent classes of problems. Indeed, we could address several issues in a exible manufacturing system using the model described in the previous section.
Detection of anomalies When interacting with the physical world, we are constantly faced with anomalies, disturbances and failures. Detecting anomalies before they cause more critical disturbances and failures is a de nite advantage. Using its world model, an automation agent is able to detect anomalies which would otherwise be unnoticed by classical control software. For instance, we showed in [18] how an automation agent models its expectation about the completion of a transport task, and monitors relevant sensors to verify it. In case the sensor reading does not occur as expected, an anomaly is raised, indicating that a pallet is possibly stuck, or that the sensor in not working properly. Such a mechanism also bene ts from the decentralized approach, enabling scalability and direct detection close to the relevant hardware.
Online diagnostics To enable the robust operation of a exible manufacturing
system, diagnostics and fault-recovery mechanisms are needed. The presented
world model is especially helpful for the identi cations of causes for a failures,
and supports searching for explanations when an anomaly is observed [11]. This
mechanism relies on de ning expectations that could lead to the observation,
and trying to verify them. Several directions can be exploited for verifying an
expectation, for instance self-testing (e.g., trying to detect if a pallet was stuck
by moving the switch to release it) and cooperation with other agents (e.g.,
asking a neighboring agent whether it detected a pallet which seems lost).
Runtime recon guration One of the most advanced features of a exible
manufacturing system is runtime recon guration, which is especially helpful to
address challenges posed by an heterogeneous and continuously changing
environment. As an example, in a pallet transport system, a destination may become
unreachable due to the unexpected breakdown of a component. In order to keep
the system running, we have studied solutions based on local recon guration,
enabling conveyor belts to run in the opposite direction and intersections to
modify their routing behavior. This requires a profound recon guration of the
low-level control software, which our architecture allows. As presented in [
Lessons Learned Besides the presented bene ts, we can point out some lessons learned. They underline some important issues about the usage of models at runtime with networked physical devices, such as the ones encountered in a exible manufacturing system. We identify three main challenges: Challenge 1: Modeling dynamic aspects of the world. For dealing with a physical system, modeling dynamics is very important. A static view, even if regularly updated, is insu cient, as relevant information may not be accessible or integrated it in a timely manner. Modeling dynamic aspects enable to obtain information from reasoning rather than from direct observation. Models and formal methods for managing time, time dependencies [21] as well as time imprecision are required.
Challenge 2: Synchronizing models incrementally. Physical devices operate under time constraints, and real-time execution is often incompatible with expensive model-based representation and reasoning. In order to cope with time constraints, we adopted an approach in which a fast LLC is fully responsible for performing all the functional operations of the system, while the slower HLC only performs complementary tasks to adapt and improve the behavior of the system. We found this approach suitable, but it also brings new challenges in terms of how the world model can re ect the reality while having only intermittent access to information from the world, and how it can synchronize to the real-world. Incremental synchronization of a model at runtime is essential [19].
Challenge 3: Integrating models in evolving systems. Working with networked physical devices requires the management of fragmented models over distributed agents. Moreover, large-scale systems require components to evolve independently. Ontologies are a general solution for interoperability [13], but are often unsuitable at runtime, since processing is overly complex. Considering that the system is rarely open, we consider just-in-time modelbased generation of adapters and ad-hoc classi ers as more e cient, while ontologies provide a suitable abstraction for designers at design time. 5
Model-driven engineering in gradually taking up in manufacturing systems [16]. However, these e orts mostly focus on models at design time, and do not seek to address issues regarding exibility and robustness at runtime.
Previous works on using models at runtime are therefore highly relevant to
our work. The general approach of using reasoning on a model to recon gure a
component-based system was already described by Oreizy et al. [14]. More recent
e ort have been focusing on modeling variability and adaptation in this approach
in a generic way [
In this paper, we presented an approach in which automation agents use models for e ciently monitoring and adapting the software controlling mechatronic devices. Each agent manages a model integrating a representation of itself, of its environment and of the agent society, and enabling it to detect inconsistencies, to envision possible future states and to create explanations based on past states. We detailed the generic architecture and the model we use for representing the world of an agent. This model features a static part, called the situation model, and a dynamic part, called the activity model. One essential feature of our approach lies in the incremental synchronization of the activity model using information from low-level control software and from other agents.
As a further contribution of this paper, we presented results and lessons learned in this work. We have showed that the proposed approach using a model at runtime is the basis for monitoring and adapting control software in a exible manufacturing systems. It provides signi cant improvement in terms of exibility, robustness and performance. However, we point out that this approach raises new challenges regarding modeling dynamic aspects of the world, synchronizing models incrementally, and integrating models in evolving systems. Although our work partially addresses this challenges, further research in these directions is needed. 11. Merdan, M., Vallee, M., Lepuschitz, W., Zoitl, A.: Monitoring and diagnostics of industrial systems using automation agents. International Journal of Production Research Special Issue on Multi-agent and Holonic Techniques for Manufacturing Systems: Technologies and Applications, IN PRESS (2011) 12. Merdan, M., Koppensteiner, G., Hegny, I., Favre-Bulle, B.: Application of an ontology in a transport domain. In: IEEE International Conference on Industrial Technology (IEEE-ICIT 2008). Sichuan University, Chengdu, China (2008), http://dx.doi.org/10.1109/ICIT.2008.4608572 13. Obitko, M., Vrba, P., Mark, V., Radakovic, M.: Semantics in industrial distributed systems. In: IFAC (2006) 14. Oreizy, P., Gorlick, M.M., Taylor, R.N., Heimhigner, D., Johnson, G., Medvidovic, N., Quilici, A., Rosenblum, D.S., Wolf, A.L.: An architecture-based approach to self-adaptive software. IEEE Intelligent Systems and Their Applications 14(3), 054{62 (1999), http://dx.doi.org/10.1109/5254.769885 15. Pechoucek, M., Mar k, V.: Industrial deployment of multi-agent technologies: review and selected case studies. Autonomous Agents and Multi-Agent Systems 17(3), 397{431 (Dec 2008), http://dx.doi.org/10.1007/s10458-008-9050-0 16. Strasser, T., Rooker, M., Hegny, I., Wenger, M., Zoitl, A., Ferrarini, L., Dede, A., Colla, M.: A research roadmap for model-driven design of embedded systems for automation components. In: 7th IEEE International Conference onIndustrial Informatics (INDIN 2009). pp. 564 {569 (jun 2009) 17. Vallee, M., Kaindl, H., Merdan, M., Lepuschitz, W., Arnautovic, E., Vrba, P.: An automation agent architecture with a re ective world model in manufacturing systems. In: IEEE International Conference on Systems, Man, and Cybernetics (SMC09). San Antonio, Texas, USA. (2009), http://dx.doi.org/10.1109/ICSMC.2009.5346161 18. Vallee, M., Merdan, M., Vrba, P.: Detection of anomalies in a transport system using automation agents with a re ective world model. In: Proceedings of the IEEE International Conference on Industrial Technologies (IEEE-ICIT 2010). pp. 489 { 494. Vin~a del Mar-Valparaso, Chile (2010), http://dx.doi.org/10.1109/ICIT.2010.5472751 19. Vogel, T., Neumann, S., Hildebrandt, S., Giese, H., Becker, B.: Incremental model synchronization for e cient run-time monitoring. In: Fourth International Workshop on Models@run.time (2009), http://ceur-ws.org/Vol-509/paper 8.pdf 20. Zhang, J., Cheng, B.H.C.: Model-based development of dynamically adaptive software. In: International Conference on Software Engineering (ICSE'06). China (2006), http://dx.doi.org/10.1145/1134285.1134337 21. Zhang, J., Cheng, B., , Goldsby, H.: Amoeba-rt: Run-time veri cation of adaptive software. In: Second International Workshop on Models@run.time (2007) 22. Zoitl, A.: Real-Time Execution for IEC 61499. No. ISBN: 978193439-4274, ISAo3neidaA, USA (2009)