Milestone
- 3.0.0.0: SparkplugB Peer-2-peer Edge Node
- 9.9.9.9: Backlog
- 2.0.0.0: Example
- 2.0.0.0: Device
- 2.0.0.0: TLS
- 2.0.0.0: Protobufs full
- 3.0.0.0 Full Feature Product (FFP)
- 2.0.0.0 Standard Feature Product (SFP)
- 3.0.0.0: High Availability
- 2.0.0.0: Edge
- 3.0.0.0 Historical Values
Searches
Help
#31 Define how Store & Forward should be implemented (historical data)
Purpose of store & Forward:
Determine a way in which we can store and forward hystorical information to bridge any trendgaps / database gaps on SCADA side of the architecture.
When a EoN Node has lost its connection to a broker, any updated value which had to be published now gets stored in the local storage of the EoN node. Whenever the EoN node gets online again (after a succesful restored connection) the EON now will publish it's local hystorical data to the broker.
Any primary SCADA should also be able to consume these store & forward Values.
The implementation of this usecase can be achieved in multiple ways. We should determine the way which solves the usecase with the least effort and without deviating from sparkplug's specification.
I should read up in the spec on what it statesbon this point, but without having done so, I can think of these suggestions on how to achive the usecase. Some suggestions from my side; a file, filled with hystorical metrics can forwarded after reconnect by the EoN node.
The SCADA server can issue a command to ask for such a file from the EoN,which then replies with said anwser(s). The anwser can be a file of hystoric metrics or a payload with metrics marked as hystorical data. Maybe tere are even other possibilities on achieving this within the constraints of the sparkplug spec?
Diff:
A simple form of buffering (and thus Store & Forward) now implemented into v0.0.0.23 / v0.0.0.24
Ideas:
1st measure is RAM (via Array) storage, 2nd measure is "long-term" disk storage
Array (1) > Disk (2) > Send
1) Buffer every Change into an array for safe keeping.
2) If the Array is "full" we write the entire array contents to disk for sending
Then we can use the emptied array again to store new changes.
We could implement this feature into a separate FB and tie it in the EoN
maybe using Trend Storage then we easily graph it also
Trend API
It automatically saves as .sqlite and can be read using VisuTrendStorageAccess https://store.codesys.com/trend-api-example.html
and can be read back using you just use the trendstorageaccess lib
Sending:
There is a field "isHistorical". Basically send the payload as normal