9.1.1 ECHONET
Originally initiated in Japan in 1998, the Energy Conservation and Homecare Network (ECHONET) standard specifies an open system architecture that enables the integration of a variety of home appliances and sensors from multiple vendors (www.echonet.gr.jp/ english/8_kikaku/index.htm). It supports energy consumption monitoring and management and allows for networked applications and services that can access and control home appliances. To describe the interface of these devices, ECHONET provides a device specification that explicitly defines their properties and access methods. Therefore, to get a device approved and incorporated into the home network, vendors must create the same interface as specified in the standard to earn an ECHONET certification. ECHONET appliances are available primarily in the Japanese market.
9.1.2 IEEE 1451
The IEEE standard for smart transducer interfaces (IEEE 1451) describes a set of open and network-neutral interfaces for connecting sensors and actuators to communication networks and processors (http://ieee1451.nist.gov). The standard uses TEDS (Transducer Electronic Data Sheet) to specify information such as transducer identification, calibration, correction data, and measurement range; TEDS typically resides in the embedded memory of a transducer, such as an electrically eras
able programmable read-only memory (Eeprom). IEEE 1451’s objective is to create a standardized interface that sensor or actuator manufacturers can follow to create cost-effective sensors and actuators that interface with a variety of networks, systems, and instruments.
9.1.3 SensorML
The Sensor Model Language (SensorML) is a product of the sensor web enablement activity, a research initiative in the geospatial community that mostly uses remote sensors and sensor systems, such as satellites and radar stations (www.opengeospatial.org/standards/sensorml). Many of the tasks for these devices involve complex data modeling and processing—for example, determining geolocations from radar images. This activity requires complicated algorithms that involve triangulation and projection, which can pose quite a challenge for researchers attempting to integrate complicated sensor systems into a “sensor web,” an information infrastructure in which sensors are accessible as Web services. To address this issue, SensorML provides a generic model of measurement and postmeasurement transformation, shielding its internal complexity from programmers by defining a uniform process interface. SensorML could be seen as the sensor standard most useful for sensor data interpretation and preprocessing to bridge the gap between low-level, hard-to-use data and higher abstractions.
9.1.4 Device Kit
The Device Kit is an OSGi-based technology that lets applications interface with hardware devices by using Java (www.eclipse.org/ohf/components/ soda/index.php). Specifically, it provides programmers with an abstract and generic model so that application development for future devices is possible even when hardware-specific information is unknown. A key feature in the Device Kit is the XML-based Device Kit Markup Language (DKML), which models a device from the device, transport, and connection layers.
9.1.5 DDL
The University of Florida is developing a Device Description Language (DDL) to support automatic device integration, including sensors and actuators, with intelligent environments (www.icta.ufl. edu/atalas/programmers_manual.htm). Unlike the Device Kit, DDL assumes devices have no networking capabilities and are connected to applications via sensor platforms, such as Motes9.1 and Atlas9.2 platforms. Thus, DDL follows a cross-layer design and only focuses on device interfacing. Device Kit and DDL are currently two independent proposals to the Service Oriented Device Architecture (SODA) Alliance (www. sensorplatform.org/soda). We covered SODA in this department in vol. 5, no. 3, 2006, pp. 94–103.
9.2 From plaintext to markup language
A standard is an explicit set of specifications, yet the way they’re presented isn’t standardized. Many things jump to mind when people bring up the word “standard:” a document written in some natural language, a set of formally defined procedures, a piece of computer software, and so on. All these options are actually employed in the real practice of defining sensor standards—for example, as part of the ECHONET standard, the ECHONET device object specification lists several classes, each one representing a device used in the home network. Each class’s properties and methods are explained in plain English, with their types and value ranges explicitly specified in a way similar to a Java API document. The IEEE 1451 standard, on the other hand, uses a more succinct Interface Definition Language (IDL) to specify operation syntax, which reads like pseudo code and is programming-language-independent. Although computer programs can’t read either natural language or pseudo code, XML provides the additional machine readability. Thus, it’s the common encoding basis for SensorML, Device Kit, and DDL. This class of standards provides XML schemas to define language syntax, together with verbal descriptions that explain the semantics. For Device Kit and DDL, open source language processors are available as supporting tools.
Although readability of sensor standards is largely enhanced by markup languages, it isn’t the only issue of concern. Succinctness and scalability are equally important. A more succinct standard, for example, often leads to higher comprehensibility and an easier learning curve. Natural language is powerful and flexible, but without proper writing skills, it risks being verbose or ambiguous. Pseudo code is rather compact and tight, but the world lacks a standard of pseudocode syntax. XML achieves a good balance between succinctness and accuracy by providing a well-formed and standardized language structure. It’s also easily extendible by adding semantic constraints.
The ECHONET device specification is essentially a dictionary of devices, but maintaining such a repository by listing each and every member certainly isn’t scalable. What if the repository expands? What if the device interface changes due to hardware upgrade? Each scenario would lead to modifications of the standard itself, which jeopardizes its stability. IDL-and XML-based standards, on the other hand, are more scalable—they’ve never attempted to standardize a specific device. By providing a generalized description tool, they let users freely define or modify any device and establish or expand their own device repositories.
Share with your friends: |