OnPing makes use of several data stores at different levels of the system in order 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 place the data gets in OnPing. This driver is being used as an example, other sources might be mqtt, control-logix or opc.
At this level the modbus registers and terminology are used. This is the only layer that the device driver info is used as part of the data store. In the case of modbus the sourceID will be a register and register type.
As shown in the diagram the data is sent to our rtu-client from here and then pushed to rtu-manager. At these levels the main store is the pid, but the source ID is still available to parse against. 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.
