The following text assumes that the reader is familiar with Jini. If you are not sure about that, you should have a look at our short Introduction to Jini.
The following design illustrates how Jini technology can be integrated into an EIB system. It's our aim to combine both systems such that
Regarding our second goal EIB devices will be able to use services of the Djinn and - vice versa - Jini-capable devices will have access to the EIB system. Needless to say, that for the user's point of view, he/she will have the look and feel of a homogenous federation of devices. In order to use services provided by an EIB device these services have to be equipped with certain properties, that
Hence, there are two major issues that have to be discussed: first it is important to know which information must be provided by each Jini-enabled EIB device to allow future clients efficient search mechanisms, second it is important how this information can be represented and stored (as de-scribed later in the section Implementation). At the moment we discovered two major pieces of information important for each fieldbus device, namely the functionality of the device and the location of the device together with the site where the device has been installed. The first term stands for the services a device can offer and requires no further explanation. We admit that the other term holds two entities, they are tightly connected and can be bundled into one piece of information. However, why do we need data about the device as well as the exact location within the site? Two simple samples may answer this question:
In our opinion the major different pieces of information are best kept in different data models, i.e., two separate trees, one representing the functionality the other one characterizing the location.
The main idea behind our EIB/Jini system architecture is to combine all logical parts of the EIB system into one agent, frankly called EIB-Agent. Each EIB-Agent consists of three parts.
Djinn
Communication Module (DC) responsible
 |
to find a lookup service (via the discovery protocol), |
|
to announce the domain's services at the lookup service (via the join protocol) and |
|
to search for services the domain wants to use (via the lookup protocol). |
EIB
Communication Module (EC) liable for the nitty-gritty fieldbus communication.
Jini
Control Module (JC) acting as common control between DC and EC. The JC
|
configures the devices via the EC and |
|
registers them at the Djinn via the DC |
Once an EIB-Agent has been installed requests originating from the Djinn are subjected to the appro-priate DC and forwarded by his JC to the EC. Requests coming from the EIB are subjected to the cor-responding EC, handled by his JC and finally directed by the DC to the desired Jini-device. Since dif-ferent Jini-capable EIB-devices may communicate through their EIB-Agents, the further configuration of the EIB system (and if desired even the communication between "pure" EIB-devices) may be proc-essed this way. Besides, communication between EIB-devices of different technologies (twisted pail, powerline) may be done by their EIB-Agents. Hence low cost (software) gateways (e.g. twisted pair to powerline) are conceivable.
Consider once more a building equipped with EIB devices and a Jini-enabled garage light. A typical EIB-Agent would be able to handle the lights of a certain room (LightAgent), another one would be able to control the heating of the room or even the whole building (HeatingAgent). Once installed the JCs will activate the related DCs, that in turn use Jini's protocols to register and join the Djinn. If a person enters the building, the light in the according room will be activated and the heating is turned on (latter of course only if it is too cold in the room).
Responsible for these actions are the DCs of the different EIB-Agents. Incoming requests are passed through the corresponding JCs (perhaps with some additional security checks) to the ECs, that finally contact the fieldbus devices.
Because Jini is based on Java, an object oriented solution for our data representation seems natural. Jini offers two different ways to locate interesting services. One way is to search for a certain class or its derivates, the other one uses additional classes (entries) to provide information about certain fea-tures. According to our data model our solution uses both mechanisms to provide clients an easy way to connect to the desired EIB-Agents. The functionality (describing the services an EIB-Agent can offer) is best represented by different Java method signatures that can be called by clients. While it would be possible to describe functionality in other ways (e.g. by a string representation), it seems natural to map services directly to their function calls with the description of the needed arguments to call the service.
As presented in the last section we use a functionality tree to group all possible services of EIB devices. Derived from an abstract top level EIB device, each class of devices is inserted into the functionality tree by extending a parent class which offers some similar services and adding additional methods for special unique services.While it could be desirable to allow a new device to extend more than one parent and thereby inherit-ing operations of different classes (e.g. a dimmable and blinking light could extend a dimmer and a winker class) this is prevented by the simple inheritance model of Java. Nevertheless this drawback is more than outweighted with the advantage of using the functionality tree directly in Jini for the class base search.
When clients look for a certain kind of functionality they just specify the desired class and the lookup service returns all objects that implement the needed service (and probably much more, as all derived classes are automatically selected as well). Keep in mind, that when functionality is represented with the help of interfaces (thereby allowing multiple inheritance), it cannot be guaranteed that the returned objects really implement the desired service and that might result in class cast exceptions.In our approach such problems can never occur, since the functionality is represented by the type of the class the agent is member of! However we admit, that it is obvious that in order to be able to use this model on an industrial level, manufactures of EIB-Agents have to agree upon a common function-ality tree. Nevertheless it is easy to use common structure describing languages (like XML) to build this functionality tree and then convert this information into Java classes automatically!
To refine a search for a specific service Jini offers additional classes (so called entries) that provide information about certain features. We use these entries for storing the address information - conform to our data model - now building up a second hierarchical tree, called the location tree. Again, this data structure has several advantages: for instance, consider a group of EIB devices spread over a cou-ple of different places. It would be inappropriate to equip the EIB-Agent with different entries repre-senting each room. Much better is to equip it with one single entry representing the whole group of rooms. Typical location trees consist of a common root (e.g. the building) divided into some major regions that are further divided into several minor regions. The address itself is represented as a string attribute of each location class. This way the location tree can easily be used in the entry based search during Jini lookup process.
