Simple Monitoring and Action Profile (sMAP) - Data Schema and API for Resource Monitors
We have become increasingly confronted with a large number of devices monitoring the physical environment. Today, these devices present disparate interfaces and tend to be part of integrated "stovepipe" solutions. The goal of this project is to break open that stovepipe and finish bringing the Internet architecture to this class of devices.
For the purpose of our discussion, measuring or sensing is sampling an instantaneous physical quantity (such as temperature or light), while metering is the accumulation or integration of a continuous stream of measurements (for instance, electric energy or fluid flow). A concrete, useful first step is to present a set of schema and protocols which allow the interchange of metering and measuring data.
For the impatient, here is a link to the sMAP Portal, which allows users to inspect several different live sMAP feeds.
The SmapHowto page explains how to write a sMAP feed, and save the data.
Architecture
Our architecture is built on classic web technologies such as HTTP, and the object interchange format is JSON. We are able to uniformly represent a number of types sensors and meters, and provide consistent interfaces to access their data, configuration, and historical profiles.
- HTTP/RESTful API
- Data Schema
- Object Transport Layer
- "Middlebox" Layer
- Report Transport Layer
sMAP Fundamental Terminology
In order to develop an effective set of resources and schema to represent sensor and meter data, we've come up with a few terms to describe how meters and sensors are typically deployed; they're glossed below.
| Term | Description | Examples |
| sensing | sampling an instantaneous physical quantity. | temperature, flow, current, power |
| metering | determining the integral of some physical quantity over time. | heat flow, energy |
| measurement point | Refers to a single physical point of instrumentation. | A current transformer measuring a single phase, flow meter, temperature sensor, light sensor |
| measurement channel | Measurement devices often derive multiple values from a single instrumentation point. | Electric meters: current, RMS power, reactive power, etc. |
sMAP Definition
sMAP defines a data representation and a method of accessing the data over HTTP. The sections below cover the basic architecture and link to more detailed articles on each topic.
HTTP/RESTful API
The highest level interface a sensor or meter exposes is a REST-ful API over HTTP. This API defines a sets of HTTP resources which allow a user to sample a sensor or read a meter, view configuration and calibration information, or set up periodic reporting. The objects used by these resource are defined by JSON schema.
Data Schema
Data are encapsulated in JSON objects defined by a set of data schemas. This set of JSON schemas are defined to be both general and expressive, and enables resource monitors of different classes interoperate.
Object Transport Layer
The objects used by the HTTP API and reporting interface are represented as instances of JSON schema. This is a relatively concise format that can also be automatically translated to other formats such as an XML Document Type Definition. However, some parts of JSON notation, such as the frequent use of key-value pairs and strings can be difficult or impossible to efficiently implement on microcontrollers. Therefore, we define a packed binary representation of JSON documents which can be easily packed using c structures. Along with code generation tools, this becomes an optional transport layer for JSON objects, and clients are required to either support the decompression or use a decompressing proxy.
"Middlebox" Layer
HTTP allows arbitrary proxies or middleboxes to be interposed between the true endpoints of an HTTP session. This functionality is very valuable when dealing with resource-constrained devices, and is of great practical use to implementors. As in other applications of HTTP, these middleboxes may provide a number of services:
- load balancing between a number of equivalent sensors
- caching or rate limiting of requests
- object compression, decompression, or translation (see below)
- HTTP header size reduction
- security offload (IPSec proxy)
Report Transport Layer
A common task is configuring periodic meter readings and sending them to some other endpoint. Our meter API supports this, and provides a two methods of transporting the data to an endpoint.
- HTTP: periodic reports are POST'ed to a location identified when the report is configured.
- UDP: the reports are sent in a UDP datagram to an endpoint identified when the report was configured. Reports using this protocol must use the packed (binary) object representation.
The report destination is identified by URI when the periodic report is configured, and a transmission error (an ICMP Unreachable message or other fault) may cause the report destination to be removed from the set of active reports.
Case Studies
In order to make sure sMAP is flexible enough for our needs, we've been experimenting with building sMAP portals for different kinds of sensors and meters. Here are a few short examples.
Historical
Related Standards and Working Groups
- 6lowapp
- Zigbee Smart Energy Profile
- Google PowerMeter
- Compact Application Profile
