Looking for any advice or recommendations on connecting ZeroMQ (a.k.a. ØMQ, 0MQ, or ZMQ) devices to Ignition… The current plan is to use independent Quasar OPC UA servers as a ZeroMQ to OPC UA bridge, but maybe there is a better way?
1 Like
I don't have advice for you, but I'm curious about the details.
Do you have no broker at all (the 0 in 0mq yeah?)? is Ignition the server and each device a client, or is Ignition the client and each device a server? What data is being exchanged and what devices do you have that support 0mq natively?
I am new to ZeroMQ, but yes, that is my understanding that there is no broker. Ignition is the client and each device a server. The application is particle physics. Data exchanged will include commands from Ignition to turn things on/off and setpoints. Data from devices will include status and measured values (voltages, currents, temperatures). All of the devices running ZeroMQ are custom electronics, produced by a variety of research institutions.
At that point you're basically just using 0mq as a transport/RPC layer, doing req/res or client/server pattern.
Building an OPC UA server seems like a reasonable approach to me 
Curse you, Mr. Nichols!!
Nerd sniped. Sigh.
This would make a very interesting module, particularly when tied into Event Streams.
Added to my to-do list.
When convenient, please share some device docs on the patterns they currently use.
2 Likes
I know you said you are new to ZMQ, but are the devices already configured for ZMQ? Are they acting as pub/sub sockets for data streaming and also support req/reply for commands?
In my opinion, if you're getting monitoring data from the devices and also need to control them, this would probably be the best pattern; pub/sub to continuously receiving sensor data, and req/reply for sending control commands where you could get acknowledgments back from the devices.
A few additional details that would help clarify what you are doing:
- What message format are the devices using? (json, protocol buffers, binary, etc.)
- Which transport are they configured for? (tcp, ipc, inproc?)
- Are all devices on the same subnet as Ignition, or distributed across different networks?
- Do the devices support both patterns, or are you limited to specific ZMQ socket types?
I know CERN has been using ZMQ for some time now, and there are slides from a talk in 2015, this is how they were using ZMQ at the time. https://indico.cern.ch/event/354137/contributions/1763290/subcontributions/153483/attachments/701686/963362/ZeroMQ-tCSC-Aram.pdf
If the devices are already publishing data via pub/sub without complex serialization, it might be easier to ingest that data directly into Ignition using the new event streaming feature using a ZMQ module. There are also ZMQ -> Kafka connectors that could be used to push into Kafka Event Streaming without the need for a new module.
1 Like
Hunter,
Thank you for your interest! I've been reading up on ZeroMQ... and I'm starting to panic. I am afraid that the freedom it provides in message formatting is a double-edged sword... with the sharp side turned on me. The lack of any built-in standardization would make it difficult, if not impossible, to create a universal ZMQ module.
You're suggestions about when to use pub/sub versus req/replay make a lot of sense, but I am afraid I will be at the mercy of the device developers. Considering that they come from different research institutions, I am not sure how much commonality in message format I will find between them. On the other hand, it is CERN's influence driving all of these devices toward ZeroMQ and some are already in use on other projects at CERN, so maybe there's hope...
I do not have answers to most of your questions, other than that they will be on the same subnet as Ignition. I appreciate your questions though, as they help me to know the sort of questions I should be asking of the device developers. If there is commonality between them, perhaps a ZMQ module specific to these devices is a possibility. I don't know anything about Kafka... yet. So I'll look into that. Thank you!
Yes, all you have is a mechanism or three for schlepping opaque binary payloads between systems.
How those are interpreted... that's what makes things interesting.
1 Like
Indeed. And inspiring. I have ideas™. Q4 shall be interesting.
** The Inductive Automation Forum only allows 2 links per post for new users and I have 10..
Something that could be helpful if you have not seen it yet is ØMQ - The Guide written mostly by the creator of ØMQ, Pieter Hintjens. I read this when I was learning about ZMQ. It has embedded examples for working with ØMQ with in a handful of languages.
Pieter Hintjens also has some record lectures on YouTube that he gave before he passed away. A Brief Introduction to ZeroMQ is a quick introduction to ØMQ sockets.
I did some digging through the CERN Document Server and using perplexity to find papers and I have some more insight into what could be your path forward. It looks like from How to Design & Implement a Modern Communication Middleware Based on Zeromq[^1], CERN decided to use the DEALER/ROUTER pattern and drop PUB/SUB because the device-property model required features that PUB/SUB couldn't provide: the ability to send initial values to specific clients when they subscribe, the capability for servers to reject subscription requests (needed for authorization), and no actual scalability/performance gains from PUB/SUB unless using multicast (which wasn't applicable for equipment control). They developed a custom in-house serialization library for RDA3 because third-party options like Google Protocol Buffers and MessagePack either required unnecessary code generation for their simple API or came with dependencies that would complicate platform portability. Wojciech Sliwinski[^2] might be someone to look into, he was on a lot of the papers that I found. Using ØMQ to Implement Communication Middleware[^3] is a great powerpoint on Wojciech's LinkedIn profile, but it makes me think they have connectors to get the data and build a queue of data before it is ingested into the control system.
Looking at the job postings on Wojciech's profile[^4], CERN uses Kafka[^7] and Apache Beam[^8], my guess would be for data ingestion. In your case, Ignition would replace Beam since that is a data processing platform. I would ask the device manufactures for the serialization that they use and if there are any 'standards' they follow. Fingers crossed they have to use safety critical standards and have good documentation for how data should be processed when leaving their black box.
Here is the link to my search on the CERN Document Server if you wanted to look at some of the other papers.[^5]
2 Likes