AMON is a data format, developed by AMEE, suitable for the description and exchange of metering and monitoring device data by anyone who has a need to describe or exchange, in a computer readable format, metering or monitoring device data.

You can find the full details of AMON at http://amee.github.com/AMON/.

However, AMON is not the only standard in the field of metering & monitoring device data exchange. One prominent alternative is the combination of Sensor Model Language (SensorML) and Observations & Measurements [XML Implementation] (O&M), from the Open Geospatial Consortium (OGC). But what are the differences between the two standards?

Development of AMON is open;
SensorML/O&M is closed (unless you pay)

AMEE welcomes everyone to participate in the future development of the AMON data format. Development is directed entirely by open and free membership to a mailing list – that is, anyone with an interest in the AMON data format can participate in discussions about changes and improvements to the standard.

SensorML/O&M are developed under a non-open model. To have voting rights on changes to the standard, a Technical Membership to OGC is required. For a commercial company in the US with annual turnover of less than USD$10m, this will cost USD$11,000 pa.

AMON is truly open

The AMON data format standard is published under the Creative Commons Attribution license. This means that, if you elect to use AMON in your own systems, but for whatever reason decide that you need modify AMON to work in a completely different way to the way the rest of the community wants it to, you are free to do so. You are empowered to make your own derivative version of AMON, and no one can stop you or charge you for doing so.

Similarly, the Creative Commons license means that you are free to use the data format in a commercial business, and AMEE cannot charge you for the use of that standard – even if you don’t want to purchase any commercial services from AMEE (or, indeed, if you were purchasing services from AMEE, but decide that you no longer want to).

AMON is a fresh take

Both the AMON data format and SensorML/O&M can be used to solve the same problem – finding a common way of formatting device, metering and monitoring device data for interchange over the Internet. However, AMON is a fresh take on solving this issue, based on modern programming practice and ideas. In particular:

• AMON uses JSON, a modern, more lightweight approach to data formatting than the older XML approach used by SensorML/O&M;
• AMON is faster to get up and running with – just 5 pages of documentation compared with 180 for SensorML and another 76 for O&M;
• AMON is recently developed for use with modern metering and monitoring device data, while the SensorML standard, for example, was last updated in 2007.

AMON is actively being used

The AMON data format is being used in current projects. For example, AMEE is working in partnership with the Energy Savings Trust and the Technology Strategy Board in the UK, where AMON is used as the primary means of exchanging metering and monitoring data for the Retrofit for the Future project, involving hundreds properties, each of which is fitted out with a wide range of devices, monitoring power & gas use, temperature, relative humidity, PV panels, ground heat pumps, door and window sensors, etc.

AMON is just about the interchange of data

The AMON data format is purely concerned with the fast and efficient interchange of data about devices and the data they produce, while the SensorML/O&M standards include additions around the areas of data sampling and processes. While some application will require specific, “heavy weight” functionality like this, for many applications, these features simply add a layer of difficulty to getting what should be a simple job – transferring data between systems.

AMON is extensible

All device objects in the AMON data format can be extended with metadata, and there are no restrictions on what types of data can be represented. So, no matter what data you need to represent in AMON, it’s possible to do so, even if you need to represent something that isn’t part of the core definition.

Of course, because the development of the AMON data format is an open process, you can suggest the your data requirements as something to be considered for a future version as well.