Recent discussions with Partners and OSIsoft folks has highlighted the opportunity to clarify the intended use of OMF types, which is the intended purpose of this blog post.
OMF and types
OSIsoft Message Format (OMF) provides a specification for how to format data as messages. To share and deliver these messages we need a way to represent it and move it. Currently there is support in the PI Server, Edge Data Store and OSIsoft Cloud Services to receive a JSON representation of OMF (sharing - i.e.: serialization) over https (deliver - i.e: protocol). There is the potential for other serialization and protocol support in the future...
This OMF payload is made up of three categories of messages:
To date there have been examples of types that suggest that a type can be used to represent an asset. For example:
"name": "Tank Pressure",
"description": "Tank Pressure in Pa"
"name": "Tank Temperature",
"description": "Tank Temperature in K"
Not so fast, be careful out there - intended use of types
However, the example above might not be ideal, and the intended use of types because:
- Types are meant to be atomic objects - more on this later
- If you don't send all properties in a type, you may get a default value added to the data stream - which might not be what you expected. See also, null-value support in the 1.1 version of the OMF specification
Types as atomic units
OMF types are intended to represent an atomic unit whereby the OMF application will send all properties as a data message for that type - unless you were updating that message but to keep it simple lets stick with new messages for now.
The following are examples of atomic type definitions:
- GPS coordinates - multi property types. It wouldn't make sense to send just latitude, so the type includes longitude and a data message would always include both properties
- Number and String - single property types. These type definitions are intended to support scenarios where data messages can be sent at different intervals, for example, due to data filtering an OMF application only needs to send an update for temperature and not status. Compare this to the TankMeasurement example above, where it would be expected that the OMF application send Pressure *and* Temperature in a data message.
The following screenshot represents the 3 types, containers of those types and data messages.
How do I define my asset, object or thing?
So, how does OMF enable the definition for a collection of atomic types to represent an asset, object, thing, spacecraft, ...?
Today the PI Server implementation of OMF enables this through the use of the predefined type __Link to join static types and containers together. Word on the street is that ideas are brewing to support this with Edge Data Store and OSIsoft Cloud Services.
To be fair, I have certainly thought about using types to represent assets, the horror!, however, hopefully this post provides some clarity on usage patterns for OMF around type messages.