Artifact: Observation Model

Main Description

In order to be able to monitor the system and the constraints that it has to adhere to, a specialised infrastructure has to be defined. This infrastructure is captured in the observation model. It ususally consists of monitors or observers that acquire data about the state of a specific agent, a group of agents, or parts of the system and check whether the specified constraints hold. Additionally, it contains controllers that react to the violation of these constraints in order to restore the constraint in question. This distinction is detailed in Observer/Controller Architecture and can be found in other kinds of operationalised feedback loops such as the MAPE cycle.

The observation model can be related to the agent architecture—in case the constraints can be observed on the agent level—or to the system architecture—in case the constraints need more global data to be observed. This corresponds to the different varieties of the Observer/Controller Architecture, in which the Observer and the Controller respectively can be located at different levels of the system. In many cases, several observer/controllers on different levels of the system are required to handle different constraints.

Apart from determining the level on which the monitoring infrastructure has to be located, the observation model also has to describe the interaction between the agents and the monitors, as well as the interaction between the monitors and the controllers that react to constraint violations.

Brief Outline

The observation model should contain at least two things:

A structural view of the observer, the controller, and their association to the agent or other parts of the system. This can be depicted in a UML Class Diagram.
A description of the interaction between the observer and the agents as well as the controllers, e.g., as a UML Sequence Diagram

The structural view can also contain specialised classes, such as models the observer creates from data gathered.

The observation model contains a number of vital design choices. If all agents are implemented by the development team, it might be possible to integrate the monitoring infrastructure with the agents. If, however, a blackbox view of the agents is necessary, e.g., because the system is open and agents provided by many vendors interact with each other, it might only be possible to observe the agents externally, i.e., with data provided by them voluntarily. In such a case, the formation of models of the agents is necessary, as well as a process to update them continuously.