The Landscape of Pervasive & Mobile Computing Standards Sumi Helal Synthesis Lectures on Mobile and Pervasive Computing Preface
Download 0.57 Mb.
|
- Navigate this page:
- 9.5.1 Object-oriented perspective
- 9.5.2 Data-oriented perspective
- 9.5.3 Modular perspective
9.5 Dissecting DevicesDevices vary greatly in their physical shapes and forms as well as conceptually. People from various domains could hardly agree on a generic model that covers all devices, thus the standards we highlight here come from different research communities with different areas of concerns. It takes distinct perspectives to fully examine and analyze them. 9.5.1 Object-oriented perspectiveOne of the simplest ways to look at a device is to consider it an undividable object. Each device object has several internal properties and several methods to access them. Programming that follows the object-oriented paradigm is easy—an example is the ECHONET device specification. Each type of device is a class, with attributes and access rules specified in the document. Although object orientation is a straightforward idea, it’s a powerful concept that provides many mechanisms. 9.5.2 Data-oriented perspectiveIn a data-oriented perspective, we can model a device as a process consisting of inputs, a data processing method, and output. Input and output data can be a phenomenon, a measurement, or a command—the device is simply a process that converts data from one form to another. For example, an electrical heater takes a tcommand as its input, and creates a warmer environment (phenomenon) as the output. A collection of such linked processes forms a process chain that models a complex sensory system. SensorML is a typical example of this category. Originating from the remote-sensor community, which constantly works on data-intensive tasks such as geolocationing on a satellite image, SensorML specializes in modeling data processing. It supports customizable data types and lets users describe data processing methods with great efficiency. 9.5.3 Modular perspectiveIn a modular perspective, we dissect a device into several modules, each of which is conceptually a self-contained component that provides certain functions. For example, in the IEEE 1451 standard, a device consists of three blocks (modules): a transducer, a function, and a Network Capable Application Processor (NCAP). A slight variation to the modular perspective is the layered design that Device Kit uses. Three component layers divide a device’s responsibility: a device layer provides the interface to hardware, a transport layer parses messages, and a connection layer supports I/O to the hardware. The modular design’s benefit is that it provides a more organized and structured way to describe devices. Table 9.1. The key differences among the five standards
Also, similar devices can reuse modules easily. Table 9.1 summarizes the key differences among the five standards with respect to their encoding schemes, design perspectives, and device models. Table 9.2 shows additional comparisons based on other criteria. Table 9.2. Comparison of five standards based on key criteria
Despite their early starts, neither SensorML nor IEEE 1451 has become the de facto industry standard. This is largely due to the absence of device manufacturers’ involvement during the course of standardization. ECHONET, on the other hand, is endorsed by a small number of major manufacturers, but its impact has so far been confined to the Japanese domestic market. Therefore, although Device Kit and DDL are much younger, they stand a good chance to promote sensor standardization to this community. chapter 10 PERVASIVE APPLICATION STANDARDS – HEALTHCARE Continua: An Interoperable Personal Healthcare Ecosystem The healthcare industry must improve its delivery methods and reduce costs to address current and anticipated needs (see the “Healthcare Needs” sidebar). Various technologies could help by extending treatment and care beyond traditional clinical settings into personal and home settings. However, creating such a personal telehealth ecosystem will require interoperability. Device connectivity to enterprise services is currently very proprietary. In an effort to develop interoperability guidelines for the emerging personal telehealth ecosystem, we formed the Continua Health Alliance (www. continuaalliance.org), an international alliance of more than 133 companies. The guidelines will be based on a comprehensive set of industry standards, which will serve as a blueprint for integrating a product into the ecosystem.
Download 0.57 Mb. Share with your friends:
|