A brief overview of data keys in OnPing

OnPing uses several data stores at different levels of the system to keep data managed.

This brief note is to explain why pid is the only source of record for historical data.

It can be helpful to understand these data stores when referencing keys across OnPing. This will be a brief introduction to the stores involved in the data path through OnPing. It will concentrate on what happens when data goes from an end device through a lumberjack and on to our cloud system.

To start with, here is an example data flow diagram from an end device to the data stores.

The four OnPing applications in question are:

• modbus-driver
• rtu-client
• rtu-manager
• tachdb

The Modbus driver is the first point of entry for data in OnPing. This driver is used as an example; other sources might include MQTT, Control-Logix, or OPC.

At this level, Modbus registers and terminology are used. This is the only layer where the device driver info is used as part of the data store. In the case of Modbus, the sourceID will be a register and a register type.

As shown in the diagram, the data is sent from here to our rtu-client and then pushed to rtu-manager. At these levels, the main store is the pid, but the source ID is still available for parsing. The rtu-manager then sends the value to the tachdb historian. The only key available in the machine historian is the pid.

This is why, when using the api you must have some sort of routine to translate whatever identifier you want to use into the pid.