Full article begins on Page 2
The chaos of diverse physical systems can be transformed into an orderly and uniform set of software interfaces that bridge to high-speed networks. Internet-based applications benefit from access to real-world status and control information that has, until recently, been locked away in isolated devices. That's led to a significant increase in embedded devices within these applications.
But to reap the real-world benefits, designers must overcome the incredible amount of diversity in how these systems are accessed and how they behave. One solution is to create an embedded device gateway that sits between the software application and the devices. This gateway can transform a set of diverse physical systems into a uniform set of software interfaces. It creates an embedded architecture that gives networking capability to the smallest embedded microcontrollers.
Gateways that give access to embedded devices should provide a controlled environment to these devices. The problems encountered in creating this environment resemble those that crop up with any distributed system—but also include resource-related restrictions. This article discusses the general architectural components of an embedded device gateway and introduces the major design challenges. By addressing the points presented here, a robust system can be built that extends the reach of client software into the real world.
The device gateway must bridge between high-speed networks with fault-tolerant, packet-routing protocols and low speed, compact networks for embedded-device networks.
The device gateway's task is to provide access to devices. Basic device capabilities include self-description, data security, automatic configuration, and others.
An embedded device gateway provides a subscription service to device clients. Clients will receive periodic updates for specific variable values.
Concurrency issues can be seen from several usage scenarios, such as client-to-client device looking.
Solving the Problems
Several requirements must be met to deliver the device state to clients with the gateway. One involves making device variables available to multiple clients. Another is to eliminate the need for network clients to poll.
Glossary of terms and conditions.
Full article begins on Page 2
The chaos of diverse physical systems can be transformed into an orderly and uniform set of software interfaces that bridge to high-speed networks. Internet-based applications benefit from access to real-world status and control information that has, until recently, been locked away in isolated devices.
This has led to a significant increase in embedded devices within these applications. But to reap the real-world benefits, a major hurdle must be overcome.
Designers dealing with such systems face an incredible amount of diversity in how they're accessed and how they behave. One solution is to create a component that sits between the software application and the devices. This component is an embedded device gateway that can transform the chaos of diverse physical systems into an orderly and uniform set of software interfaces.
What's really important is that gateways intended to give access to embedded devices should provide a controlled environment for these devices. The problems encountered in creating this environment are the same as with any distributed system, but they also include resource-related restrictions. Even so, designers can build a robust system that extends the reach of client software into the real world.
A device gateway system supplies an embedded architecture that gives networking capability to the smallest of embedded microcontrollers. On a more detailed level, a gateway is an intermediary "bridge" or "broker" between lightweight narrow-bandwidth device networks (RS-232, RS-485, modem, wireless, power line) and broadband heavyweight networks, including intranets and the Internet. In addition to a protocol translation function, a gateway for device networking should provide management, configuration, security, network services, and flow control to the devices. This gateway must also be as reliable and cost-effective as the devices for which it is serving. To facilitate this reliability, the gateway will need to be placed on an embedded platform. Compared to a traditional set-top box, desktop, or server environment, creating an embedded gateway platform can greatly reduce the gateway's total system cost.
A device gateway's fundamental architecture is a system that creates internal representations of each device on a subnetwork and then exports these representations to the various client protocols. Each client interface connecting to the gateway (HTTP, SNMP, SOAP) is basically object oriented. So, the translation from a device object representation to these interfaces is usually straightforward. The software running on this embedded platform must be designed to gracefully handle resource constraints and communications faults in the client application and device subnetwork channels. Because network throughput on the subnetwork side is usually much lower than the broadband side, a gateway must be designed to either optimize traffic to the device, limit transactions from the client, or both.PROTOCOL BRIDGING, MANAGEMENT, AND TRANSLATION The gateway must be able to bridge high-speed networks and protocols that support fault-tolerance and packet-routing strategies (which are appropriate for the Internet or a WAN) and the relatively low-speed, compact, and efficient networks for embedded device networks. To this end, the gateway can manage the device subnetwork to gain the most efficient use of its protocol and transport. It can also provide interoperability between embedded devices by translating between the new, existing, and legacy protocols they might use. All of these features have particular value for low-cost, resource-limited embedded devices.
Implementing protocol bridging should bring all of the devices on the various subnetworks to a single-device object model. This common abstraction is important so the higher-level services can manipulate the devices and supply services to them. While this sounds straightforward, several problems crop up in reaching this goal.
First, the protocols designers wish to adapt to differ greatly from each other. These differences often have ramifications in how the gateway should use them. For example, a low-bandwidth RF link connecting a battery-operated device must be used sparingly. Consequently, devices on this subnetwork aren't always available because they go to sleep. They may also be more likely to enter and leave the logical network.
On the other hand, some implementations of RS-485 subnetworks are fast, but they're implemented as master/slave systems. The master/slave characteristic of their media-access mechanism means that the gateway must implement some type of polling to offer a subscription service to the client.
Another challenge when bridging various protocols to a common device abstraction is that the solution may require that some state be maintained for devices while connected. This means that resource handling in terms of threads and buffers can be extensive.
The problem is similar to an HTTP server as multiple client requests need to be handled. But the device gateway must accept requests that ultimately deal with many devices on their own slower subnetworks. As a result, either the current device state needs to be always ready at the gateway, or a system of queuing client requests while they're forwarded to devices must be implemented. Combining the two systems works well. First, any regular property updates are available by establishing a subscription. Second, any asynchronous request from a client to a device can also be a service. By providing a subscription service to a device, even if it must be polled, the device gateway can more effectively manage traffic on the subnetworks.WHERE DOES ALL THE COMPLEXITY COME FROM? Why is so much technology necessary to solve such a simple problem? Once a client program can access a device, the job seems mostly done. But the device's subnetworks have very different characteristics than a traditional LAN. The basic philosophical issue is that the resource-limited device isn't a reasonable "citizen" of the Internet. There are many expectations of Internet-based hosts, and these devices fail to meet these expectations. Namely, they present problems in the areas of security, management, and maintenance. Also, the severe bandwidth limitations and large number of embedded devices require the networking infrastructure to handle flow-control issues.
That means the architecture of a device-networking gateway must decouple the devices from the clients to control the interactions between them. Therefore, the problems this system addresses are the same issues present in any distributed system: coherency, synchronization, communication, and error handling.At the bottom of Figure 1, there are devices connected to various subnetworks. The device gateway is tasked with providing access to devices. This means considering how the devices will be presented to the world, the basic set of capabilities they offer, and how the gateway can reconcile any discrepancies between these. Several basic capabilities are associated with each device participating in the architecture. These capabilities are directly implemented by the device resident software or synthesized by the device gateway on behalf of the device.
- Self description
- Events for availability changes
- Immunity to outside load
- Data security
- Automatic configuration
- Concurrency control (multiple client applications must have controlled interactions with device)
- Announce and respond to capability queries
- Not affected by changes to data/services access means (Internet host modifications must not break device applications)
If the devices are described in terms of standardized schema, such as one of the XML-Schema descriptions of a SOAP-based device, the applications can manipulate them based on the abstract data type. For example, a control for temperature can be applied to many device types, like HVAC, an oven, or a hot tub. The schema is essentially a set of contracts that specify the mechanical and behavioral implementation of an embedded device. Knowing that the device has implemented a certain predefined schema means the methods and properties of the application are known as well as what the device will do when the methods and properties are manipulated. This knowledge, based on a design-by-contract implementation, is the cornerstone of automating device interaction.
To incorporate a device into any component architecture, designers will want to encapsulate the device into an object. This object consists of a set of variables associated with the device, as well as all functions and procedures available for interaction with the device. Imagine the object as a virtual control panel. For instance, a thermostat would likely have a variable for the current temperature and a procedure for setting a new desired temperature. If every device is accessible through some object interface, a single program can list the entire available status of a device without "knowing" what it is. If all thermostats have the same device-object variables and functions, then a single program can provide access to the thermostat control regardless of the manufacturer or communications link.
Designers might wonder what this really means to the device gateway. There's a major trend toward creating standard device definitions, which include how the device is manipulated and how the device behaves as part of a system. Like most standardization processes, there's a potential to throw in everything in terms of requirements. This means the device gateway can provide the common, standardized device definitions and behaviors to the network clients. But it will inevitably have many devices and subnetworks that fall short of the idealized set of capabilities.
The device gateway must fill in all the gaps. For example, a UPnP bridge will likely have to be associated with a set of device-descriptive XML files and serve them to clients requesting information about the device's status. In addition, the loosely specified subscription system will likely not be suited for bandwidth-limited subnetwork buses.
Therefore, the gateway may need to create device proxies that provide a representation to the network that devices can't provide on their own. This proxy layer within the gateway lets small, embedded devices participate in popular networking strategies like UPnP and Jini.VARIABLE SUBSCRIPTIONS A useful feature of an embedded device gateway is providing a subscription service to device clients. These clients are interested in receiving periodic updates for specific variable values (Fig. 2). The clients of subscriptions may be running programs awaiting notifications on a socket interface, or executables that need to be executed when a value changes. For instance, the gateway's ability to launch an arbitrary executable based on subscriptions to value changes is very powerful in alarm and data-collection scenarios. The subscription service has two general subscription types:
- Changed-based updates: Notify when the value has changed, but no more frequently than rate X.
- Time-based updates: Notify with the current value at rate X regardless of whether a change occurs.
The second type is useful for logging sampled data because the client knows that the system is working, but the value remains unchanged. However, the first subscription type is more efficient and can be paired with a subscription to the device status if system integrity must be monitored along with the variable value.
There are several cases where the gateway software must keep track of the subscriptions and initiate polling of the device to provide this subscription callback service. In some situations, the communications channel won't support asynchronous notification. An example is when the bus is master/slave in terms of media access, so the gateway must initiate a scheduled transaction with the device. Another case is when the device would swamp the subnet bus with notifications, but the client only has interest in relatively infrequent updates. Here, it would be more efficient to either poll the device at the reduced rate or use some device-resident means of flow control to prevent unneeded updates.
Given a slow subnetwork, there's relatively little bandwidth to support interactions with devices. Consider how device subnetworks on power-line carriers often support baud rates under 9600. Low-cost RF has similar speed limitations but also affects a device, which may be battery operated, in terms of power consumption.
If the client application is interactive, the bandwidth-management algorithms should be implemented in both directions. When a user can very quickly modify input values to the device, the resulting input may be delivered through a LAN much faster than they can be forwarded through the device subnet. Here, the delivery policy should be unambiguous and probably configurable. In some cases, like having a desired temperature for a chiller, any values waiting to be sent by the gateway may be discarded when a new value arrives from the client. The user wants to set the system to the current desired value. In another scenario, like a remote-control vehicle, a sequence of desired positions should all be delivered in the correct order.
Because the device-management interface has the same capabilities as a device, the subscription service is implemented to establish a device or subnet watchdog. A subscription to a device is set up, but no client actually cares about the value. Instead, the value is discarded. Yet a handler is installed when the information is unavailable. Thus, the gateway may be configured to send an e-mail or pager notification when a device can't be reached for a given length of time.CONCURRENCY CONTROL The concurrency issues handled by a device gateway can be seen from several usage scenarios, such as client-to-client device locking. Imagine two client programs manipulating the same embedded device. In the absence of concurrency control, either client can interfere with the other's ability to effectively control a remote device. Given that the purpose of this technology is accessibility through the Internet, great distances may separate the clients. Fortunately, this problem is effectively the same as when two processes share a resource in an operating system. So, the solutions are pretty well understood. In most cases, one of the clients will have greater authority with regards to the device and should have unrestricted access. In this case, a management interface to the gateway is needed to facilitate setting up and maintaining the access control privileges.SOLVING THE PROBLEMS At this point, it's beneficial to take a closer look at the challenges associated with delivering the device state to clients with an embedded device gateway. The requirements for this aspect of the design are:
- Make device variables available to multiple clients.
- Create a system to allow controlled access to the device subnet bandwidth.
- Eliminate the need for network clients to poll, even if the device is on a polled subnetwork.
- Make the above possible without unbounded system resource demands at the device gateway.
Three main components are used to create the underlying device access handler:
- Timed-event list: This module manages a list of events that may be one-shot or periodic. The nodes on the list are ordered in time so each node has a field representing the amount of time to wait after the previous node is activated. A thread takes a node off the list, sleeps for the period of time specified by the node's delay field, then places the work description onto the Ready Queue. The periodic timed-event nodes get immediately placed back into the timed-event list when the work description is queued up.
- Ready queue. This is a queue of events currently ready to be processed.
- A thread pool. This group of threads block waiting for something to be placed into the ready queue. Each thread will take a node off, process it, then either destroy it, if it was one-shot, or leave it alone if it is on the timed-event list as periodic.
When several clients are interested in the state changes of a given variable, the rate of each client subscription is logged in the subscription list. If the variable is on a device, which must be polled, a node is created in the poll list. This node is part of a timed-event list and is set to run at the minimum rate that satisfies all subscribed clients. If a client drops a subscription request, the poll rate is recalculated. This system is much more efficient in its use of subnetwork bandwidth than honoring requests for each individual client. On the LAN or WAN connection between the client and the gateway, this system reduces traffic because the variable updates are supplied only when a state change occurs.
To provide higher throughput when the device subnet is relatively fast, the thread pool may be made larger or smaller during run time, as needed. This structure is set up so the gateway services that interact with resources enforcing serialization are serialized by data structures rather than rely on operating-system resources. An alternative approach that spawns many threads to act as handlers for each transaction wastes resources handling the contention created when the threads try to access the subnet. This system also uses very little memory to hold Device State because only direct requests for a particular variable and subscriptions result in storage demands.SERVICE INDIRECTION ISSUES In future applications, the networking infrastructure will increasingly play the role of service provider. Designers could augment sprinkler controllers with weather forecast information to conserve water. If rain is only a day away, the lawn can hold out. The data format and means of access the embedded controller uses must remain static for the life of the product to guarantee continued operation. If a server goes down, the product feature also goes down. This is particularly important with respect to a denial of service attack on the source of the weather information. A device gateway is an indirection point that can maintain consistent format and access to devices in need of consistency.GLOSSARY Device Object: A logically related set of functions, variables, and attributes implemented by embedded firmware on a product and made available for remote access through a network.HTTP or HyperText Transfer Protocol: Used by the Web, this protocol defines how messages are formatted and transmitted and what actions Web servers and browsers should take in response to various commands. Jini: Sun Microsystems' software for simplifying the connection and sharing of network devices like disk drives and printers.Schema: The type of a device object. The definition includes both the names and types of individual functions, variables, and events, plus the behavior of the device.SGML or Standard Generalized Markup Language: System for organizing and tagging the elements of a document that was developed and standardized by the ISO (International Organization for Standards).SNMP or Simple Network Management Protocol: A set of protocols aimed at managing complex networks.SOAP or Simple Object Access Protocol: Provides a platform-independent means for applications to communicate with each other over the Internet.UPnP or Universal Plug and Play: An architecture for achieving compatibility among the products (software, peripherals, and networking equipment) of the more than 400 vendors that belong to the Universal Plug and Play Forum.Variable Subscription: When an application needs to be notified about device condition changes or when periodic status is required, the application makes a subscription to one or more variables on the device. The device gateway is responsible for providing these updates even if the device must be polled in order to detect condition changes. XML or Extensible Markup Language: A pared-down version of SGML designed particularly for Web documents.