Our research on the Control Plane

The Control Plane connects the hardware to the knowledge platform. Our design focuses on the autonomy of the nodes in contrast to traditional remote management systems based on SNMP, NETCONF, WBEM, etc. that do not make decisions on the device but in a management server.

As pointed out in the chapter about the Knowledge Plane, the Knowledge Agent is the only connector to the knowledge overlay. Between the managed entity (device) and the agent we put a Monitor-Analyze-Control-Plan (MAPE) loop.

We see the MAPE loop, as proposed by Jeffrey O. Kephart, David M. Chess in The Vision of Autonomic Computing (IEEE Computer, vol. 36, no. 1, pp. 41-50, January, 2003), as a good way to structure the tasks to be done to manage a node autonomously.

Therefore, we integrate it into the Autonomic Manager which is the instance of the platform running on a manageable node:

The Monitor is the component that collects information from the device. The data it gets is raw data without meta information. The data is passed to the analyzer.

The Analyzer interprets the data and adds semantics to them. This is done with the help of the before defined data representation hierarchy, so the models and the prototypes. The analyzer transforms information into knowledge.

The knowledge is then passed to the knowledge agent that stores and distributes it.

The Planner is contains the autonomous functionality of the device's management cycle. The planner decides autonomously which actions are to be performed on the device. It contains the advanced decision logic. As the planner acts upon the knowledge it gets from the knowledge agent it is like every other service with the difference that it is connected to the executor enabling it to put things into action. The planner typically performs tasks like changing the device's configuration and checking if it was successful or deciding if actions are to be done.

The Executor takes commands from the planner and reflects them onto the hardware.

The combination of the services, the knowledge plane and the autonomic managers allows distributed autonomic management and control.

Device Classes

As mentioned before we have devices with highly varying resources inside a house.

Full Functional Node

The before mentioned connection over a MAPE and a knowledge agent running on the device only works for Full Functional Nodes.

Reduced Functional Node

Devices providing less resources (esp. computing power, energy, network connectivity and storage) may run a reduced version of the agent, not allowing caching for instance, as well as a reduced or even no store. In the latter case the data can be stored on a foreign more powerful node. The Reduced Functional Nodes are connected via so-called Knowledge Bridges explained below.

Legacy Node

While the node classes above provide platform specific functionality, this last class does not. Nevertheless it is probably the most important class - at least at the beginning. Legacy Nodes are all remote controllable devices that have a proprietary interface.

As stated in the introduction, the manufacturers already connect their devices today with proprietary protocols. As we want to control everything inside a house this class of devices plays an important role. The Legacy Nodes are connected over a so-called Knowledge Proxy explained below.

Extending the Platform

Knowledge Bridge

A Knowledge Bridge connects Reduced Functional Nodes to the Autonomous Control and Management Platform (ACMP). While the standard Knowledge Agents communicate over XML, a protocol optimized for the specific domain of these nodes might fit better. Also it might be more convenient not to transmit all the protocol information all the time but to limit the message body to the necessary minimum.

This is where the Knowledge Bridge comes into play. It transforms the reduced Protocol of the resource limited domain (light ACMP in Fig. 10) to the xml based ACMP communication protocol.

The Bridge also adds missing but necessary information to the data packets (e.g. timestamps). It is important to note here that the nodes connected over the Bridge already feature autonomous behavior.

Knowledge Proxy

The Knowledge Proxy connects the Legacy Devices, talking a proprietary dialect, to the platform. As these devices normally do not provide autonomous behavior, in the way we described it above, the Proxy has to provide it substitutional for the connected device.

On the Knowledge Proxy a MAPE is running for each connected Legacy Device. This makes the control and management of this important device class transparent to the platform and opens up entirely new possibilities to the Legacy Devices.

The Proxy is an important step towards home automation in the near future. In the further future we expect more devices to be capable of running platform code themselves.

Currently we are working on a Proxy for SNMP and one for web services which are often found in remote controllable devices like power plugs.

2008-11-04_SEP_Enrique_Garcia.pdf

2009-08-21_BA_Rene_Brogatzki_Knowledge_Proxy_SNMP.pdf

2009-08-28_BA_Enrique_Garcia_MAPE.pdf