Static XML data for abstract M2M protocols

Abstract protocols are usually a good option when transporting information from a device to another without much complication. Simplicity, flexibility and quick adoption are the main strengths of abstract protocols and abstract data schemas. These strengths have doubtless led JSON, Soap, HTTP and Modbus to a priviledged place within the Automation Industry.

However, abstract protocols lack a certain degree of interoperability in some situations; additional application layers on top of the existing protocols. In a common peer-to-peer application, both peers have to share a given convention in order to understand what is communicating each other. An actuator may be waiting for an alert sent from multiple sensors. Thus, our actuator must know how alerts are coded into the incoming communication frames. In this example both ends (sensors and actuator) are specialized nodes. Each one concentrates into running a simple task (sensing alerts and hearing them) so programming the data-coding convention into the actuator is the simplest way to let it know about incoming alerts.

However, more capable devices, like coordinators, masters, gateways or data concentrators usually need to decode data received from many nodes so hard-coding data conventions into these devices (as opposite to incorporating these conventions into the communication frames themselves) is not a good idea. These devices are not specialized ones; since they may accept a variable amount of data types, another approach must be considered.

For those high-end devices needing complete information about the data being exchanged, it would be possible to maintain local or remote repositories of device descriptions. Since XML is an extended language with numerous parsers for any programming language, why re-inventing the wheel. The following example is a first attempt to create static device definitions to complement SWAP in high-end devices. For the Dual Temperature and Humidity mote:

<?xml version="1.0"?>
<device>
  <manufacturer>panStamp</manufacturer>
  <product>Dual Temperature/Humidity sensor</product>
  <pwrdownmode>true</pwrdownmode>
  <registers>
    <reg id="11">
      <endpoint type="analog" dir="input">
        <description>voltage supply</description>
      </endpoint>
    </reg>
    <reg id="12">
      <endpoint type="analog" dir="input">
        <description>humidity</description>
        <position>0</position>
        <size>1</size>
      </endpoint>
      <endpoint type="analog" dir="input">
        <description>temperature</description>
        <position>1</position>
        <size>1</size>
      </endpoint>
    </reg>
  </registers>
</device>

The above schema mainly consists of registers and endpoints. Registers are SWAP's natural data containers whilst endpoints are what really matter to end-user applications. Thus, registers are divided into one or multiple endpoints in a simple way. In the above example, register with ID=11 has only one associated endpoint (voltage supply) so this endpoint will take its value from the complete register. On the other hand, register with ID=12 consists of two endpoints. "Humidity" takes the first byte (position = 0, size = 1) from the register value. "Temperature" takes the second byte (position = 0, size = 1).

Finally, device definition files like the above one would be indexed by their product code, which uniquely identifies manufacturer and product type over the air.

I may still add some additional fields to the above schema but this will be pretty much the system used by SWAPdmt, panTastic and any other high-end device or application wanting to identify wireless motes and their resources.