Hi -
We have a project where a client has stated they would provide a AVEVA PI Connector to interface with our system. Our system would be running Ignition Edge.
I assume Store and Forward would require a database connection to be established?
Is there a potential issue here with double compression of data (ie. Edge Historian is doing compression / filtering and then PI is applying this as well)?
If we don't use Store and Forward, the I assume we could just use the AVEVA OPC-UA connector, but then this bypasses the "store and forward" capability of Ignition's Historian, right?
Essentially I'd prefer to go through the Ignition software rather than connect the client system to the PLC directly.
Thanks Kevin,
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).
Correct, Store and Forward is not involved, but this is your best option. The PI connector is an OPC UA client, it connects to Ignition's OPC UA server and subscribes to the data.
This option is basically irrelevant because PI is not a database you can tell Edge to store history in.
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.)
Thanks for the tips and additional info.
I am in a similar situation with similar amounts of tags. The connection is not critical so something like a 15s data loss is not a problem.
