Autonomic Control and Management in Heterogeneous Networks

Our environment is full of technical equipment. The amount of potential digital assistants grows every day. The capabilities of the sensors and actors in our environment are by far not exploited today as a common communication and interaction standard between all devices is missing.

If all devices would be connected to a common bus they could cooperate and perform tasks like serving more comfort to the user or saving energy more effectively. New applications arise by the possibility to distribute tasks. Devices with low resources can benefit from resources in the network. (Energy saving is such a scenario.)

We are currently working on a platform that brings connectivity and autonomous functionality into the home context.

The home context is more challenging than other environments as it contains very heterogeneous devices: we find everything between a simple switch button and a computer. Also the requirements on security as well as responsiveness are higher than in the natural computer environment as the user will not tolerate a blue screen when he wants to switch on the light or a virus that opens the front door…

For realizing autonomous control and management we are currently working on a four layered architecture:

• User Interface
• Service Plane
• Knowledge Plane
• Control Plane

User Interface

The User Interface is the part of our platform the end user interacts with. We try to keep our interface as logical, simple and mighty as possible.

We are currently developing a web based interface.

We decided to do so as there are many devices running a web browser like smart phones, television sets or other appliances we find inside a home. With the new Goolge Chrome we see that also the market sees this trend.

Also a web interface running on html contains build in markup features to easily design an interface.

Another advantage is that the interface can get served from central points so we only have to keep them up to date.

For devices with big display we develop an OpenLayer (so map) based approach. It seems a natural interface to place controllable objects on a map. For smaller displays we only show the interaction menus for the specific controllable objects that are close to the user.

We try to address the following three goals:

• Place users in control of the interface (user empowerment).
• Reduce the users' memory load.
• Make the user interface consistent.

So we provide a context sensitive user adaptive and especially intuitive interface to the new cooperative functionality.

Service Plane

The autonomic capabilities are realized in form of high level control services that run on nodes with sufficient resources inside the network. A service might for instance control the climate of a room or the energy consumption inside a house. A service might also take care that the music follows us through the house or even adapts to us and our mood outside, when we enter an autonomicity ready environment like a pub where the music might adopt to the guests.

The limit of possible services is the sky if our input variables really are all devices inside our environment and we can control every device. And this is what we are realizing with the platform.

Services are logically situated on top of the big abstraction layer "knowledge plane". It allows them to be running on appropriate nodes providing enough resources. This leads to new possibilities especially for domains with low resources as they can outsource control and management tasks.

Domains with enough resources also profit from our approach as it allows the migration of services as well as load balancing and other mechanisms that lead to more efficient usage of the resources. The resilience as an important factor not only for security critical services inside a home is also strongly improved.

Services communicate with the knowledge plane over the so-called knowledge agent. It provides a unified interface to the knowledge objects that represent the controllable playground for the services as they define their input and manipulation possibilities. The limitation of a unified interface gives the freedom of reusing already existing funcionality from other services inside the network. Plug and play of services becomes reality.

The availability of a unified information- and data model makes it easy to develop generic services that are able to control heaters of different manufacturers for instance as they all use the same model as base.

We envision enthusiastic home users to provide models of their hardware to our global model store so that other users can automatically profit if they possess such hardware. Providing a model will be as easy as sharing CD title information over CDDB today. Integrating a device someone already uploaded a model for will just be plug and run. An interesting challenge here is the convergence of different models.

We also envision an application store for home control and management services that can be provisioned by one click inside a home. Interesting challenges here are security ratings for instance.

Knowledge Plane

The Knowledge Plane is the core of the architecture. It contains the digital representation of the world. Every entity (device, service) that wants to profit from our new control and management architecture has to connect to the knowledge plane. This happens via the Knowledge Agent (KA).

The Knowledge Agent provides a unified interface that can handle Knowledge Objects. It provides only a limited amount of functions and mechanisms. This distinguishes it from many classical agent systems. We only want to provide the minimum amount of functionality inside the agent. This limitation is the base for the compatibility of all elements inside the platform as seen in Fig. 2.

The Knowledge Agent is the node's logical communication endpoint for everything concerning the knowledge overlay. If data from other nodes has to be retrieved this happens by requesting the data at the local agent. The agent will retrieve the data then and deliver it to the inquirer. The addressing of the data is done via XPath. The data exchange format is XML based. As container we use SOAP.

The platform supports subscriptions, publications (with data) and notifications (without data). This enables us to handle asynchronous as well as synchronous* (only limited as the platform is autonomic) interaction.

The Knowledge Agent is the entity that publishes the model of the local device (with its available services). It takes care of updating its local model as well as the information which remote data is available where.

The Knowledge Agent uses a Knowledge Store to store its (the node's) data. The Knowledge Store can be realized in different ways like a text file or a database as it fits best to the resources of the node.

The Knowledge Agents are addressed via their public keys. Automatic key verifications authenticate the communicating entities. The KAs also enforce the security policies. Transport security over encryption is also realized inside the Knowledge Agent.

The Knowledge agents organize themselves autonomously. Also the data replication takes place without user interaction.

Unified Data Representation

Another key of our architecture is the unified data representation. They are also XML based. We have a hierarchy of different abstraction layers of representations.

The uppermost layer contains the so-called models:

          model ::= (leaf | model)+ modelContext
        

Models contain the common denominator between objects of a class. A model could be a switch port or a generic router. Models can aggregate other models.

The next level is the prototype. A prototype is a specific device like Toaster XYZ. In contrast to the model it contains already data like the vendor string.

      prototype ::= (model' | leaf)+ objectContext
    

Both hierarchy class representatives above are stored globally on a server.

When a device is installed inside a house an instance of a prototype is instantiated. This is done automatically via the Knowledge Agent. Through the models the Knowledge Agent performs integrity checks (syntax) of the local information automatically.

The instanciated prototype is called object.

      object ::= (model~ | prototype~) objectContext
    

The contexts above contain access information etc. Additionally to the ones named we have a system context that contains information about the running ACMP as a whole.

The models already define the basic interaction possibilities of the device. This is important for services as they want to interact with the devices.

For a service it is enough to know the model it wants to interact with. The model might be "heater" and it might contain a field "desired temperature". As service author I only have to provide to my Knowledge Agent "Give me all heater.desired_temperature" and I can talk to all heaters inside a house.

Great abstraction...
developing applications for the ACMP gets almost easier as with the iPhone :)

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.