M4M or Measure 4 Measure, ever since Shakespeare's play with the same name we know, people can be mistaken for one another. A Duke (like the beloved Java mascot) claims to be a monk, the head of a ...
M4M or Measure 4 Measure, ever since Shakespeare's play with the same name we know, people can be mistaken for one another. A Duke (like the beloved Java mascot) claims to be a monk, the head of a dead pirate is presented to be that of the young hero. So can important information like Units of Measurement be misinterpreted. While humans reading 10°C, 10 C or 10 Degree Celsius, each of those could be interpreted and understood well enough. For M2M communication, unless a program is provided with a large glossary of alternate terms, only ONE of these would be acceptable.
This is where the Unified Code for Units of Measurement (UCUM) among similar approaches like UnitsML, SensorML or a few others are vital for error-free M2M transactions, not just between sensors or measurement devices, but also and especially vehicles or distributed devices.
OSGi Measurement has been around for some time (R3) but never gained as much momentum, as many other bundles of OSGi did. Except for very few use cases in the Embedded or Automotive sector it is practically unused and based on statements by its contributors in the OSGi Alliance to be considered legacy with no plans continue development.
After a brief overview of common M2M errors from Gimli to Mars, This session provides an overview of OSGi Measurement, Eclipse OUMo, what they have in common and where the differences lie. Although most of today's OSGi containers are capable of dealing with units or measurement better and more reliable with UOMo, both can where necessary also exchange information and collaborate. E.g. if legacy devices and code cannot be easily replaced. For this We'll take a look at interoperability between different systems or with other unit technologies and languages like F#, Fantom, Python or Lua.