Hello, I am working on a project where the end user would like to host two ignition systems on separate subnets, where the systems are connected over a One-Way outbound network diode. The idea would be to maintain a system that has monitoring only capabilities outside of their network hardened Scada network, so ideally, tags and data can move out to the external system, but data does not go back in. Is there an ideal protocol to use to implement a system like this. My thoughts were to use the store and forwarding system, since it uses web sockets, but maybe MQTT may be another option. If anyone has encountered an architecture like this, I am all ears.
The only practical protocol is UDP, with scripted sockets. Anything using TCP (all ordinary protocols) requires bidirectional traffic.
Data diodes involving software like Ignition that uses standard protocols and essentially does not have support for the concept is always going to require a custom solution or extra hardware/software.
I've heard of these guys, which can make OPC UA data available over a data diode: OPC UA Application Connector | Owl Cyber Defense
You have their hardware + software running on either side. On one side they are an OPC UA Client, subscribed to data in the Ignition OPC UA Server. This data is pushed over the diode one way, to another application of theirs that receives it, and acts as an OPC UA Server, that another Ignition application can connect to as OPC UA Client.
The magic sauce they provide is the diode hardware, presumably proprietary protocol for pushing data over the diode, and the software on each side that can produce or consume it.
2 Likes
That's similar to what I am looking for. Is it possible to connect two Ignition gateways over OPC-UA? How would this work to configure tags to begin populating databases on the external side of the diode?
Of course. Though to be clear: that's not actually what's happening if you use a diode.
It would look just like any other OPC UA connection to any other server. You get nothing for free. Bring in the OPC tags and build something with them.
1 Like
From what you mentioned earlier, the diode would host a client that would transmit the tags and data across the networks to make it accessible. So it would be similar to referencing a standard OPC client?
Thank you for the help. This gives me confidence in the architecture we are trying to build out.
Not sure what you mean by this.
From my understanding, the architecture would be
ignition opcua server -> opcua client (data diode) ------ internal transmission ---> opcua client (data diode) ---> Igntion opcua server
Thanks Kevin
I would think an alternative would also be MQTT as long as the diode can emulate a broker similar to OPC-UA in that data gets published from Ignition to the internal side of the diode which then sends it over to the external side where it also acts like a broker and Ignition on that side subscribes to the topics to get the data. I have a feeling a lot of this depends on protocol support by the diode vendor.
Yeah, that same vendor I linked to has an MQTT adapter as well.
I don't think Sparkplug would work, but generic MQTT should?
My worry with Sparkplug is that you really need the birth message to initialize the values, so you'd either have to do a rebirth every so often, or just use generic MQTT and realize that values could not exist until they're witnessed at least once by the external client.
I am pretty sure there are elements of Sparkplug that fundamentally require bi-directional communication between Edge nodes and Primary Host, e.g. birth and death payloads published by Primary Host that the Edge nodes need to be able to receive.
I thought using the primary host ID was optional. Even then, the internal/safe side of the diode could just have a static "ONLINE" state published that looks like it's from the primary host causing all transmission modules to send their birth, LWT, and data to the internal "broker" which forwards them to the external broker for it to process/republish to the actual MQTT engine.
Here's the page on MQTT. Looks like they do support SparkplugB.
https://owlcyberdefense.com/wp-content/uploads/2020/07/19-OWL-0105-Data-Sheet-Redesign-MQTT-V3.pdf
Yeah seems you can opt out of configuring primary host on the edges and opt the primary out of any scenario that would normally require a rebirth (missing or out of order sequences etc).