Fundamentals ❯ The Cyber-Physical Interface

Building a real-world smart space requires the utilization of a large number of sensors, actuators, and other devices that are either developed in-house or obtained commercially-off-the-shelf (COTS). Utilizing such a diverse collection of devices obtained from multiple sources, each adhering to different protocols and/or standards, can easily lead to a chaotic situation. Operating these devices in a collaborative and coherent manner is a challenging task. From our early experience in real-life deployments, we found that learning the operational details of devices to specifically integrate them into a single system is a Herculean task and can easily account for a large portion of the development time and budget. The most time-consuming and error-prone task proves to be the connection phase, which requires linking the numerous and heterogeneous devices into cyberspace. Utilizing the I/O ports of computers and linking the devices directly through them is nonscalable and inappropriate—after all, the traditional computer was created for different types of input equipment, certainly not sensors and random devices! But even if connection is not an issue, traditional integration requires hardwiring the device operational logic into the application. While this approach might seem straightforward, it introduces a number of problems.

First, hardwiring device operations into applications implies that whenever devices are added or removed from the space, one must revisit all existing applications to ensure that nothing is broken due to the current modification to the space. This would impose a huge amount of time and effort, which is extremely susceptible to errors.

Second, even if an element has been previously integrated, there are no guarantees the integration effort is reusable and the integration procedure is replicable. Through our real-life deployment of the Gator Tech Smart House, an assistive environment for the elderly, we discovered what was missing and have innovated an approach that calls for a special, embedded computer designed from the ground up for the main purpose of: (1) physically connecting and (2) autonomically integrating sensors and devices into cyberspace (be it a space computer, the network, or even the cloud).

We call such a tiny computer the Atlas sensor integration platform. The two main differences between Atlas and other sensor platforms (also known as sensor nodes, such as the Berkeley mote) can be summarized as follows: (a) sensor nodes have very limited types and numbers of sensors embedded onboard, whereas Atlas connects to external sensors, actuators, and in general much larger and more general types of sensors and devices, and (b) the goal in sensor nodes is to program them to sense through onboard sensors and to communicate data and control with other sensor nodes, whereas the goal of Atlas is autonomic integration and externalization of the sensor or device to an outside cyberspace where programming is enabled and done.

Active Projects:

• The Atlas Sensor Integration Platform
• The Atlas Pervasive Computing Middleware

The Atlas Sensor Integration Platform

The Atlas sensor integration platform aims to create a fundamental building block for cyber-physical interfaces. In a nutshell, it is a universal logical and physical connector of devices into cyberspace. In another nutshell, it is an “IoTer” of devices, or the maker of an Internet of Things device (devices, in this case). Physically, Atlas is a combination of hardware and firmware. Together, these components allow virtually any kind of sensor, actuator, or other device to be integrated into the Internet of Things, all of which can be queried or controlled through an automatically generated interface specific to that device. This facilitates the development of applications that use the devices by utilizing the generated device interfaces. Effectively, the sensors or devices are externalized by Atlas into the application space where they can be utilized and programmed. Each Atlas node is a modular hardware device composed of stackable, swappable layers, with each layer providing specific functionality.

The modular design and easy, reliable quick-connect system allow users to change node configurations on the fly. A basic Atlas node configuration consists of three layers (as shown above): (1) the Processing Layer, which hosts a microcontroller responsible for the main operation of the node, (2) the Communication Layer, which handles the network transportation for each node, and the (3) Device Interface Layer, which connects the various sensors, actuators and other devices to the Atlas platform through a variety of interfaces. The Atlas processing layer is Atmel based. Atlas communication options include Ethernet, Wi-Fi and ZigBee. Device interface layer includes support for serial communication, Analog, Digital, GPIO and actuator interfaces such as switches and DC servos.

Two fully assembled (stacked) Atlas sensor integration platforms are shown above. A Wi-Fi Atlas node is shown in the left hand side. To the right, an ethernet node is shown.

The Atlas Pervasive Computing Middleware

Based on the Atlas sensor integration platform, we developed a reference architecture for a middleware to enable pervasive computing and the development of smart spaces. The architecture (shown in the figure below) consists of four layers: (1) a Physical Layer, which includes the devices, sensors, and actuators, (2) a sensor integration Platform Layer consisting of only Atlas nodes, (3) a Services Layer, consisting of software representations of each element in the Physical Layer, and (4) the Application Layer, containing applications as direct service composition over basic device services (in layer 3). The Application Layer also includes sentience abstraction managers for events, phenomena clouds, activities, and data streams.

The Atlas middleware is a service-oriented platform that can convert the various sensors and actuators in a pervasive computing environment into software services. It is responsible for obtaining this service representation from connected devices, and for managing the services in such a way that applications are easily able to obtain and use the services and associated knowledge. Two layers of the Atlas architecture, the Services Layer and the Application Layer, comprise the majority of the middleware. In our implementation, the Services Layer is built on top of the Open Services Gateway Initiative reference architecture (OSGi), which is a Java-based framework that provides a runtime environment for dynamic, transient service modules known as bundles. The Atlas middleware holds the registry of the software service representation of all sensors and actuators in the space. The layer provides the service discovery, composition, and invocation mechanisms for applications to locate and make use of particular sensors or actuators.

Each sensor or actuator is represented in the Atlas middleware as an individual OSGi service bundle. Applications and services are also written as bundles. The lifecycle management and the discovery service capabilities allow the middleware to manage the dynamic environments where devices come and go, administer dependencies between bundles, enable the composition and activation of more complex applications and services, and allow applications to find and use other existing services.

The Atlas middleware consists of a number of essential components (which are also bundles): a Network Manager that handles the arrival and departure of nodes in the network, a Configuration Manager that manages the configuration settings of each node and enables remote configuration, and a Bundle Repository that stores and manages all the supported sensor and actuator bundles. Features of these three common services are accessible to the user through a web configuration and administration tool.

People

Dr. Sumi Helal
Raja Bose
Steven Pickles
James Russo
Chao Chen
Steve Vander Ploeg
Jeffery King
Choonhwa Lee

Open Source & Downloads

Parts of the Atlas Pervasive Computing Middleware are open source and can be downloaded from: http://www.cise.ufl.edu/~helal/opensource/atlas.pdf

Publications

• Sumi Helal, "Programming Pervasive Spaces," the Standards and Emerging Technologies Department, IEEE Pervasive Computing magazine, Sumi Helal, Dept. Editor, Volume 4, Number 1, January-March 2005. (pdf)

• C. Chen, R. Bose, A. Helal, “Atlas: An Open Model for Automatic Integration and Tele-programming of Smart Objects,” in Proceedings of the 3rd International Workshop on Design and Integration Principles for Smart Objects (DIPSO 2009). In conjunction with Ubicomp 2009, Orlando, Florida.

• J. King, R. Bose, H. Yang, S. Pickles and A. Helal, “Atlas – A Service-Oriented Sensor Platform,” Proceedings of the first IEEE International Workshop on Practical Issues in Building Sensor Network Applications (SenseApp 2006). Tampa, Florida, November 2006. (pdf)

• R. Bose, J. King, H. El-zabadani, S. Pickles, and A. Helal, "Building Plug-and-Play Smart Homes Using the Atlas Platform," Proceedings of the 4th International Conference on Smart Homes and Health Telematic (ICOST), Belfast, the Northern Islands, June 2006. (pdf)