Our application has an embedded PC with Ignition Edge with Panel and IIoT modules basically acting as an HMI. There is a local PLC controlling the application. It is a turn-key solution that could be purchased and deployed onto a client site.
A client wants to interface with us to collect data into their SCADA and site Historian for long term data archival. So I was thinking we either could:
a) Enable the Store and Forward capability of the Edge Historian
b) Ignore the local Historian and just push the live data over OPC-UA (as I understand this does not forward the Historian data, correct)?
c) Expose the PLC to the client's network and collect data directly from there, but this is not the preferred method for security and communications overhead reasons (since Ignition is also polling the PLC).
FWIW, when configured correctly, an OPC UA connection/session can also have some of the desired behaviors of a "store and forward" system as well.
It's largely up to the client. It needs to create sessions and subscriptions with lifetimes longer than the longest expected downtime. It needs to create monitored items with queue sizes large enough to accommodate value changes for as long as the connection might be down, or as much as is reasonable. The client needs to be programmed to resume sessions upon reconnecting, or transfer subscriptions to a new session after creating one.
This isn't meant to handle the kind of use case where it's days or weeks at a time between connections, but it's certainly enough to preserve sequence of event data in between connection losses.
Further optimization note: Make sure that PI subscribes via Ignition to your PLC tags at the same pace as the Ignition application itself. That's required for the drivers to combine the traffic into shared requests. (For PLC target addresses that overlap between Ignition and PI.)
What about using MQTT to a client supplied MQTT broker to support data buffering?
We have the IIoT module and Edge IIoT description implies that store and forward should work here. Am I misunderstanding the this capability?
Sorry for not mentioning this initially, it slipped my mind here and I am still a relative newcomer to Ignition.
For S&F capabilities with MQTT, the client's device/PC subscribing/consuming the data being pushed by your Edge device will need to support Sparkplug B and have the Primary Host ID set, and your Edge device will need to also monitor/subscribe to that Host ID. Plus, it will probably take some testing to be sure it works well together.
Thanks for the clarification Michael. We may end up using MQTT as an alternative if the S&F functionality is important. Are there any general throughput constraints or limits using MQTT vs. OPC-UA to be aware of?
I haven't hit any limits, but we've also been doing small skids with tag counts < 1000. We're only pushing data every 5 seconds as well, so very small load, but nothing has issues. On your S&F for MQTT though, you'll need to configure if you want it to store in memory or to disk, and the S&F will work a bit differently. Unless things have changed, because there's no verification of data received by the subscribers, there's timeouts you can tweak for MQTT communications. So if a link is severed/lost, you may lose that timeout period worth of data (maybe like 15 seconds if your timeout is 15 seconds). This is because if the server loses its connection, the MQTT broker waits for the timeout period before publishing the last will and testament message which is usually just OFFLINE to the host ID topic. In that time, your Edge client is still pushing data to MQTT because it thinks the server is still online until ti gets that OFFLINE message. (If you're not familiar with MQTT, definitely read up on it, and Sparkplug B is essentially a "protocol" developed on top of standard MQTT to deal with issues like this.)