We’re working on an architecture for a SCADA system that ends in the PLC being the only single point of failure. Naturally we will be using an Ignition Edge local client fallback setup with a central Ignition Gateway.
Requirements:
Store and Forward on PLC tags (and so obviously history on those tags)
Failure of the central gateway or connection to the gateway will maintain machine control and result in no data loss after the connection is re-established.
Failure of the Ignition Edge gateway will maintain machine control and result in no data loss after the connection is re-established.
The tricky part is requirement 3. We don’t want a hardware failure of a Edge node to be the reason a system can’t log data or interact with the rest of the SCADA system.
The solution so far:
Add the PLC as a device on the central gateway and the edge gateway
In the central gateway, create a local tag provider for the direct device tags
In the central gateway, create a remote tag provider for the device tags coming from the edge gateway
Both tag structures in 2&3 match.
Create a 3 tag structure of purely expression tags that references the preferred tag provider based on edge gateway connection status.
This solves the machine operation needs of requirements 2 and 3. The trick is then store and forward.
You could store history on both providers (from items 2&3 above); but then there’s no way (that I know of) to synthesize the history after an edge node comes back online.
You could do history on the expression tags, but then you would lose all store and forward, at least as I understand it. If I’m wrong please tell me.
Anyone helpful ideas on how to solve this one would be greatly appreciated. Thanks!
We have a project on the back burner here that I’ll need to figure this same sort of thing out for. I didn’t do much detailed planning, but from memory we were going to:
Configure Edge with tags and tag history for the PLC tags. Write the fallback application to use those tags.
Have Edge export the tags to the main Ignition server, so we can take advantage of the store and forward for tag history there.
Configure a second set of tags on the main Ignition server, and use those tags for projects running on the main server. If these projects need historical data, we can point them at the history coming from the Edge server. The tags on the main Ignition server would not have history enabled.
The PLCs that I’m planning to use make it simple to log data to an onboard SD card in CSV format. In the event that my Edge Panel goes down, I’ll be able to backfill the history tables using this CSV data, if I truely care about what was happening at the time. I think.
I realize that this means my comms will be effectively doubled to the PLC. I was hoping I could use scan class settings to limit this traffic to just what is needed for the Edge logging in the background, unless the fallback project is running on the Edge client.
I haven’t really had much time to think this setup through, so I’m not sure if something similar will work for you. Or if this setup will actually work for us…
That’s a quite similar setup to what I’ve envisioned. The local PLC/SD method won’t work in this application, we need it to be nearly seem-less and very “industrial strength” for the good conscience of our customer. But I agree that what you’ve suggested would work.
You hinted at back filling history tables with CSV data. Is that a straightforward and/or supported process? If so, wouldn’t you just want to log history at the central gateway and use that as the back fill if your edge node went down? I would have called this the solution before, but I didn’t think manipulating the tag history data (even to add in missing data) was simple/possible.
Yeah, SD card stuff wouldn’t be seamless, but IMHO, it would be pretty industrial strength (assuming the SD card doesn’t fail). The SD card would be on the PLC running the process. No comm links to fail there
Full disclosure: I’ve never backfilled data into the history tables before. But, looking around the forums and the docs, I came across the system.tag.storeTagHistory scripting function
You can provide your own timestamp to go with the data. This will cause ignition to store the history in the proper tables for easy use by something like an EasyChart.
I hadn’t really considered just logging history on both the Edge install and the main server. I guess I was worried about the traffic levels needed, but I never did any testing to warrant the concern. I’m guessing it would probably be easier to work with another tag history source to backfill than a CSV file. Not sure how I’d go about doing that off the top of my head, however…
