No description, website, or topics provided.
Shell
Clone or download
Pull request Compare This branch is 2 commits ahead of AMEE:gh-pages.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
_layouts
.rvmrc
AMEE_logo.gif
index.markdown
markup.sh
readme.markdown

readme.markdown

AMON v4.0 Beta

Copyright

Copyright (c) 2010-2012 AMEE UK Limited. and 2014 Mastodon C ltd

http://www.github.com/MastodonC/AMON

Abstract

AMON is a data format suitable for the description and exchange of metering/monitoring device data. AMON is available to be used, free of charge, by anyone who has a need to describe or exchange, in a computer readable format, metering or monitoring device data.

The AMON standard has been primarily developed by AMEE UK Limited and now adapted by Mastodon C Ltd with the assistance of a number of other parties in the metering/monitoring device industry. If you would like to participate in the further development of the AMON standard, please see the Contributing to AMON section.

AMEE has developed a storage platform for metering/monitoring device data and a RESTful, web-based API for storing and retrieving this data using the AMON data format. However, the use of AMON is not limited to this context, and a key aim of the AMON data format is to advocate an open way of describing and exchanging metering/monitoring data that is independent of any API or system. The use of AMON in metering/monitoring devices and/or other systems is encouraged.

Mastodon C has revised this format to allow the addition of programmes, projects and an expanded entity definition to allow for full management on metering and monitoring projects.

License

The AMON standard is licensed under a Creative Commons Attribution 2.0 UK: England & Wales License.

Table of Contents

Goals of AMON

The AMON data format has been developed with the following goals in mind:

  • To be suitable for the description and exchange of metering/monitoring device data;
  • To be human readable and self-documenting;
  • To be able to be widely supported;
  • To be bandwidth sensitive;
  • To be simple; and
  • To be extensible, easily supporting new data types.

To this end:

  • The data format defines a number of commonly used data fields for devices (such as the device name, its location etc.), and a number of commonly used data fields for device readings. This ensures that the data format is suitable for the description and exchange of metering/monitoring device data and is simple to use.
  • The data format uses JSON encoding [1]. This ensures that the data format balances the need to be human readable and self-documenting against the need to be bandwidth sensitive. Additionally, as most languages have library support for JSON encoding, AMON is able to be widely supported.
  • Finally, although the data format does define commonly used data fields for devices and device readings, it does not exclude the use of custom device data or reading data. These can be described and exchanged using the AMON data format without modification to the data format, ensuring that the format is extensible.

The AMON Data Format

The the full AMON data format is shown below. A full description of the format follows, along with examples of realistic AMON formatted data.

{

  "devices": [
    {
      "deviceId": required string ID,
      "entityId": required string ID,
      "parentId": optional string ID,
      "meteringPointId": optional string ID,
      "description": optional string,
      "privacy": required string, either "private" or "public",
      "location": {
        "name": optional string,
        "latitude": optional latitude in degrees,
        "longitude": optional longitude in degrees
      },
      "metadata": {
        optional JSON object
      },
      "readings": [
        {
          "type": required string,
          "unit": optional string,
          "resolution": optional number,
          "accuracy": optional number,
          "period": required string, either "INSTANT", "CUMULATIVE" or "PULSE",
          "min": optional number,
          "max": optional number,
          "correction": optional boolean,
          "correctedUnit": optional string,
          "correctionFactor": optional number,
          "correctionFactorBreakdown": optional string
        },
      ],
      "measurements": [
        {
          "type": required string, must match a defined reading type,
          "timestamp": required RFC 3339 string,
          "value": number, boolean or string, required unless "error" (below) is present,
          "error": string, required unless "value" (above) is present,
          "aggregated": optional boolean
        },
      ]
    }
  ],

  "entities": [
    {
      "entityId": required string ID,
      "projectId": required string ID,
      "deviceIds": [ optional array of string IDs, empty array permitted ],
    }
  ]
  
  "projects" [
    {
      "projectId": required string ID,
      "name": required string
    }

  "programmes" [
    {
      "programmeId": required string ID,
      "name": required string
    }

}

Data Format Description

The AMON data format describes metering/monitoring devices, their data, and their relationship with other entities in a JSON encoded [1] string with structure as shown above.

The AMON data format consists of three main sections:

  • devices: The "devices" section is used for representing physical or virtual metering/monitoring devices and their data;
  • entities: The "entities" section is used for representing real world or virtual entities that may relate to "devices" and/or "meteringPoints", such as businesses, properties, buildings, people, universities -- anything, really, that may have a 1:n relationship with "devices" and/or "meteringPoints".

Numbers

Where a number is defined in the data format, positive and negative integers and floating point numbers are acceptable. Numbers may be defined in either normal numeric or scientific notation. (It is left up to the implementation of devices/systems that use AMON regarding the precision of floating point numbers.)

Devices

In the AMON data format, the "devices" section is used to represent physical or virtual metering/monitoring devices and their data. This is done via three sub-sections. Firstly, a series of fields that define details about the physical or virtual device itself, such as a ID for the "device", if the device's data should be considered to be public or private, the location of the device, and optional metadata about the device. Secondly, a series of fields (the "readings" section) which defines what the device records measurements of -- so, for example, if a device monitors temperature and relative humidity, then the "readings" section would define this. Finally, a series of fields (the "measurements" section) which defines actual metering/monitoring data from the device.

All of the fields for the "devices" section of the AMON data format are discussed in more detail below.

  • deviceId: A ID for the "device". Required for a "device"; however, systems that implement the AMON data format may relax this requirement to make the field optional for AMON formatted messages that are requesting that a "device" be created.
  • parentId: A ID for the device's "parent". Presence of this value indicates this device is a sub-meter.
  • description: An optional textual description of the device. Commonly used for an in-house device ID and/or other useful identifier.
  • meteringPointId: An optional ID of a "meteringPoint", if this "device" is to be considered part of that "meteringPoint".
  • privacy: Should the information about this device and its data be considered private, or public? Optional -- systems that implement the AMON data format should assume a default of "private" if not specified.
  • location:
    • name: Optional textual description of the location of the "device".
    • latitude: Optional latitude of the "device".
    • longitude: Optional longitude of the "device".
  • metadata: An optional JSON object of metadata about the "device". This allows the AMON data format to handle any type of metadata relating to the "device".
  • readings: The "readings" section defines what type of readings the "device" validly produces. An array of zero or more sets of values.
    • type: A required string, defining a name for the type of "reading". A set of standard reading types is listed below; however, the AMON data format does not specify any requirement regarding reading types. While it is recommended that the standard reading types be used, users of the data format are free to define and use their own type definitions, as appropriate to their devices and data.
    • unit: Optional string, defining the unit for the "reading". Units must be a valid unit as defined by the JScience library. [3] [4]
    • resolution: Optional number, defining the number of seconds between each expected measurement.
    • accuracy: Optional number, defining the accuracy of the "reading".
    • period: Required string, defining the type of "reading". May be one of "INSTANT", "CUMULATIVE" or "PULSE". Systems that implement the AMON data format should assume a default of "INSTANT" if not supplied.
    • min: Optional number, defining the minimum valid value for the data.
    • max: Optional number, defining the maximum valid value for the data.
    • correction: Optional boolean, defining whether a correction factor has been applied to the data.
    • correctedUnit: Optional string, containing the corrected unit type.
    • correctionFactor: Optional number, defining the correction factor applied.
    • correctionFactorBreakdown: Optional string, defining the process for obtaining the correction factor.
  • measurements: The "measurements" section defines actual data measurements from the "device". An array of zero or more sets of values.
    • type: A required string, referencing a "reading" type that is defined for the "device". All data measurements supplied for a "device" must use a "reading" "type" that has been defined for the "device".
    • timestamp: RFC 3339 [2] string, required. The date/time that the "measurement" was produced.
    • value: Optional number, boolean or string, being the actual "measurement" value.
    • error: Optional string, describing an error condition if no "value" is present.
    • aggregated: Optional boolean, set to true if the measurement data being described/exchanged has been aggregated (i.e. is not individual raw data values, but has been aggregated to reduce the number of "measurement" items that need to be listed).

Entities

In the AMON data format, the "entities" section is used to represent physical or virtual entities which may have a relationship with a "device" or "meteringPoint".

All of the fields for the "entities" section of the AMON data format are discussed in more detail below.

  • entityId: A ID for the "entity". Required for an "entity"; however, systems that implement the AMON data format may relax this requirement to make the field optional for AMON formatted messages that are requesting than an "entity" be created.
  • projectId An ID for the project this entity belongs to.
  • deviceIds: An array of "device" IDs, representing the "devices" that belong to the "entity".
  • meteringPointIds: An array of "meteringPoint" IDs, representing the "meteringPoints" that belong to the "entity".

Projects

In the AMON data format the "projects" section is used as a way of grouping entities together. This allows for access control and as a way of comparing within and between projects as a part of data analysis.

  • name A name for the project that is unique through the system
  • projectId A unique identifier for the project.

Programmes

In the AMON data format the "programmes" section is used as a way of grouping projects together. This allows for access control and can help with broader data analysis.

  • name A name for the programme
  • programmeId an unique identifier for the programme.

Standard Reading Types

All "devices" in the AMON data format must, in order to be able to describe/exchange metering/monitoring data, define "readings", to which "measurements" can then be associated via the defined "type".

As mentioned above, the AMON data format does not specify any requirement regarding what "reading" "types" must be. However, the following table represents "types" that are commonly used in the metering/monitoring field. If a "type" exists in the following table, it is recommended that this be used when using the data format, as this will improve the ability to interchange AMON formatted data between different systems.

Each of the standard "types" below is listed with a proposed default "reading" "unit", which systems implementing AMON should use in the event that no unit is defined in a "device" "reading" section for that "type".

Type NameDefault UnitJSON Type
absoluteHumidity g/Kg Number
barometricPressure mbar Number
co2 ppm Number
currentSignal mA Number
electricityAmps Amps Number
electricityConsumption kWh Number
electricityExport kWh Number
electricityFrequency Hz Number
electricityGeneration kWh Number
electricityImport kWh Number
electricityKiloVoltAmpHours kVArh Number
electricityKiloWatts kW Number
electricityVolts V Number
electricityVoltAmps VA Number
electricityVoltAmpsReactive VAr Number
flowRateAir m^3/h Number
flowRateLiquid Ls^-1 Number
gasConsumption m^3, ft^3, kWh Number
heatConsumption kWh Number
heatExport kWh Number
heatGeneration kWh Number
heatImport kWh Number
heatTransferCoefficient W/m^2.K Number
liquidFlowRate Litres/5min Number
oilConsumption m^3, ft^3, kWh Number
powerFactor Number (0-1)
pulseCount Number
relativeHumidity %RH Number
relativeHumidity wm-2 Number
solarRadiation W/m^2 Number
status Number (0/1)
temperatureAir C Number
temperatureAmbient C Number
temperatureFluid C Number
temperatureGround C Number
temperatureRadiant C Number
temperatureSurface C Number
thermalEnergy kWhth Number
time millisecs Number
voltageSignal mV Number
waterConsumption L Number
windDirection degrees Number
windSpeed ms^-1 Number

Data Examples

Example 1 - Temperature readings

This example shows a "device", with ID "d46ec860-fc7d-012c-25a6-0017f2cd3574".

The device is associated with the entity with ID "50af27e0-e61a-11e1-aff1-0800200c9a66".

The "device" has a "location", and has been defined with one "reading".

Two "measurements" for the defined "reading" exist.

{
  "devices": [
    {
      "deviceId": "d46ec860-fc7d-012c-25a6-0017f2cd3574",
      "entityId": "50af27e0-e61a-11e1-aff1-0800200c9a66",
      "description": "Example 1 Device",
      "location": {
        "name": "kitchen"
      },
      "readings": [
        {
          "type": "temperature",
          "unit": "C",
          "accuracy": 0.01
        }
      ],
      "measurements": [
        {
          "type": "temperature",
          "timestamp": "2010-07-02T11:39:09Z",
          "value": 23.5
        },
        {
          "type": "temperature",
          "timestamp": "2010-07-02T11:44:09Z",
          "value": 23.8
        }
      ]
    }
  ]
}

Example 3 - Wind turbine measurements

This example shows two "devices", the first with ID "82621440-fc7f-012c-25a6-0017f2cd3574" and the second with ID "d1635430-0381-012d-25a8-0017f2cd3574".

The devices are associated with the entity with ID "50af27e0-e61a-11e1-aff1-0800200c9a66".

The first "device" has been defined with three different "readings", and one "measurements" for each of the defined "readings" exist.

The second "device" has been defined with one "reading", and one "measurements" for that "readings" exists.

{
  "devices": [
    {
      "deviceId": "82621440-fc7f-012c-25a6-0017f2cd3574",
      "entityId": "50af27e0-e61a-11e1-aff1-0800200c9a66",
      "description": "Example 3 Device #1",
      "readings": [
        {
          "type": "electricalInput"
        },
        {
          "type": "electricalOutput"
        },
        {
          "type": "electricalExport"
        }
      ],
      "measurements": [
        {
          "type": "electricalInput",
          "timestamp": "2010-07-02T11:39:09Z",
          "value": 0.6
        },
        {
          "type": "electricalOutput",
          "timestamp": "2010-07-02T11:39:09Z",
          "value": 4.5
        },
        {
          "type": "electricalExport",
          "timestamp": "2010-07-02T11:39:09Z",
          "value": 3.9
        }
      ]
    },
    {
      "deviceId": "d1635430-0381-012d-25a8-0017f2cd3574",
      "entityId": "50af27e0-e61a-11e1-aff1-0800200c9a66",
      "description": "Example 3 Device #2",
      "readings": [
        {
          "type": "windDirection"
        }
      ],
      "measurements": [
        {
          "type": "windDirection",
          "timestamp": "2010-07-02T11:39:09Z",
          "value": 243
        }
      ]
    }
  ]
}

Example 4 - Associating devices with an entity

This example shows an "entity", with ID "0636240-0381-012d-25a8-0017f2cd3574".

The entity is defined as being associated with two "devices", those with IDs "c1810810-0381-012d-25a8-0017f2cd3574" and "d46ec860-fc7d-012c-25a6-0017f2cd3574".

{
  "entities": [
    {
      "entityId": "90636240-0381-012d-25a8-0017f2cd3574",
      "description": "Example 4 Entity",
      "deviceIds": [
        "c1810810-0381-012d-25a8-0017f2cd3574",
        "d46ec860-fc7d-012c-25a6-0017f2cd3574"
      ],
    }
  ]
}

Example 5 - Non-numeric measurements

This example shows a "device", with ID "ed221bf0-d075-012d-287e-0017f2cd3574".

The device is associated with the entity with ID "50af27e0-e61a-11e1-aff1-0800200c9a66".

The "device" has been defined with one "reading", and two "measurements" for that "readings" exists. Note, however, that the "value" of the "measurements" in this case are boolean values.

{
  "devices": [
    {
      "deviceId": "ed221bf0-d075-012d-287e-0017f2cd3574",
      "entityId": "50af27e0-e61a-11e1-aff1-0800200c9a66",
      "description": "Example 5 Device",
      "readings": [
        {
          "type": "windowOpen"
        }
      ],
      "measurements": [
        {
          "type": "windowOpen",
          "timestamp": "2010-11-12T13:51:43Z",
          "value": true
        },
        {
          "type": "windowOpen",
          "timestamp": "2010-11-12T17:51:53Z",
          "value": false
        }
      ]
    }
  ]
}

References

  1. http://json.org/
  2. http://www.ietf.org/rfc/rfc3339.txt
  3. http://en.wikipedia.org/wiki/Universally_Unique_Identifier
  4. http://jscience.org/api/javax/measure/unit/SI.html
  5. http://jscience.org/api/javax/measure/unit/NonSI.html

Appendix

Revision History

  • Version 4.0: 2014-05-18 - Bruce Durling, Mastodon C
    • Remove metering points
    • Add programmes and projects
    • IDs may now be SHAs rather than UUIDs.
  • Version 3.1:
    • Updated standard reading types.
  • Version 3.0:
    • Changed Meters to Devices.
    • Added some new fields.
    • Updated standard reading types.
    • Removed 'description' property from entity.
  • Version 2.0: 2011-09-12 - Andrew Hill
    • https://github.com/AMEE/AMON/issues/1: Added the "description" field to "meters", "meteringPoints" and "entities".
    • https://github.com/AMEE/AMON/issues/2: Removed the "duration" reading type, as feedback suggested that this type is not relevant at all to metering/monitoring device manufacturers -- readings are always taken at an instant in time with only a single timestamp available for the reading.
    • Made a minor typo correcton to the revision history log.
  • Version 0.9: 2011-08-15 - Andrew Hill
    • Major update to the description of the AMON data format.
    • Major update to the layout of the document.
    • Removed text relating to AMEE's implementation of AMON that are not relevant to the data format.
    • Updated the specification for "meteringPoints" to allow them to be more general; "meteringPoints" are no longer confined to representing customer billing points.
  • Version 0.8: 2011-05-12 - Andrew Hill
    • Further clarification made between the AMON standard and the API.
    • Minor improvements to documentation of data format.
  • Version 0.7: 2010-11-26 - Paul Carey
    • Clarified relationship between the AMON standard and API.
    • Removed redundant reference to name in reading.
  • Version 05 - 0.6: 2010-11-12 - Paul Carey
    • Added string and boolean to measurement value types.
    • Removed now redundant Reserved Property Names.
    • Added Contributors section.
    • Added windowOpen type.
  • Version 0.4: 2010-08-16 - Paul Carey
    • Added location and error fields.
    • Formalised separation between format and API.
  • Version 0.1 - 0.3: 2010-07-02 - Paul Carey
    • Updated to reflect current usage and demands.
    • Modified based on itial feedback
    • Initial version created.

Contributing to AMON

Contributions to the AMON data format are welcome! If you would like to participate in the development of the AMON data format, please see the following:

Contributors