Building middleware for instrumented environments is not the focus of our research. It is, however, an interesting step on the way. When we started building our instumented environments, we were faceing the decision whether to use an existing software infrastructure or to build our own. We opted for the latter. These are our results so far.
The current focus of our middleware is device management, e.g. device classification, orchestration and communication. We have a stable, working prototype (the device manager) on which we investigate general principles that could also be applied to other resource management tasks, e.g. service lookup and management. The goal is to provide an API which allows application developers to easily use devices in the room without having to worry about hardware, network or driver details.
The task of classifying devices and designing a taxonomy for them is rather difficult. Especially when taking all possible future (and obviously yet unknown) devices into consideration. We decided not to try this, but to take a more pragmatic approach instead. Devices in FLUIDUM are not classified in a hierarchie or taxonomy, but instead described by a list of their properties. Properties might include for instance in the case of a digital camera the capability to take a high resolution photo and the capability to provide a low resolution video stream. We currently have a description of 13 such properties that cover all current devices in our instrumented environments. If a device with a new property needs to be included, the list of properties can easily be extended. So even a "flux compensator" or a Star Trek transporter can be included in our system. To make things even more pragmatic, these properties are not just implemented to provide a description of themselves; they are fully remotely accessible objects. If we know about the property of a device, we can access it.
Our current prototype uses a central server, the device manager. Both devices and applications register with this device manager which serves as a match maker between them and keeps the applications updated on changes in the devices currently registerd. Furthermore, we have a proxy server which registers as an application to the device manager and is capable to answer questions such as "Which devices can take photos?"
The device manager is running as a command line process on our linux cluster. It prints out all important information, which is not necessarily well suited for debugging or exploring the currently connected devices. To fill this gap, we implemented a GUI, the device manager monitor. This monitor application connects to the device manager, displays all available devices and enables the user to browse the devices' parameters, properties, interface, and implementation. It also offers some simple tools to directly access and use the devices.
A short research video is presenting the device manager and its monitor gui. If you are interested in a demonstration, you can download this movie here.
Some research questions concerning the device manager still need to be solved. We are aware of the fact, that a centralized architecture presents a potential bottleneck and will not scale very well. Although the device manager is running stable without restart for months at a time (i.e. until the computer is rebooted), there is always the chance of a network problem or hardware failure. A second, decentralized version of the device manager (using the same infrastructure and codebase) using peer to peer networks is currently built. A homogenous approach using a centralized server as default and a peer to peer network as fallback solution in case of a failure and automatically repairing and switching back to the central approach will also be investigated. Other issues include device lease, time stamps, device locking, priority handling and authentication/security.
The work described on this page is part of the PhD thesis of Christoph Endres. For feedback or comments, please send email to [email protected].