One-Way Automation

Feedback to the "Open Letter to OPC Foundation from a Manufacturing End User"

Recently, the Open Letter to OPC Foundation from a Manufacturing End User was published on LinkedIn. The letter then was discussed in this YouTube video, with the participation of his author. 

As my company is an independent software development company with a specialization in OPC UA, I was touched by this letter and the video and wrote my thoughts in the comments section to the video. But for unknown to me reason it disappeared, and I decide to publish it here in my company's Blog section:

I am not sure, should I laugh here or cry. If so many difficulties in understanding of the OPC UA can be observed, you might be right that there is more to do by the OPC Foundation in delivering core principles of the OPC UA to the mass audience, the end-users particularly. Although OPC Foundation is busy organizing events and presentations, like recent OPC Days International, and there is a new initiative: OPC UAcademics (https://opcfoundation.org/resources/opcuacademic/), still a long way ahead to go I guess.

My company is an independent software development company, and a member of the OPC Foundation. But I am here not representing this organization, just my personal feedback.

I do have experience participating in the OPC UA Working Group, not PubSub though. From my experience, I can tell that representatives from any member company, be it as large as Microsoft or as small as my tiny company, have the same rights to bring ideas, write/edit specifications and participate in shaping this standard. I think almost any major industrial automation software and hardware vendor have a member in a Working Group they are interested in (there many groups there, for main parts and for companion specifications). And while it is in a draft, working document state, the specification (or rather some its part/edition) is reviewed by members of the User Group, everyone can evaluate, how will it work with their product which is either released product or just in design/prototype state. And then if there are concerns, or suggestions, or proposals to change/edit/propose a completely different version of the draft, all of them are discussed, and if makes sense and supported by the majority, accepted.

So I would say that specifications are created in a fair and democratic way, taking into account any member organization's needs.

In my strong opinion, not possible that one large corporation comes and starts to dictate course/adopt specifications to fit their product line, and block others.

Therefore, if you have a strong belief that SparkPlug is a much better and more efficient format than PubSub to convey data from OPC UA servers to the Clouds, I think you will be welcome to join and change the world of OPC UA. I cannot find Cirrus in the members' list, and not aware of their experience. To my knowledge, yes, Microsoft was among those who came with an initiative to add support for PubSub, and AMQP was considered as a protocol. I haven’t heard of Cirrus in this regard. BTW, AMQP is very similar to MQTT, and Rabbit MQ broker is open source, so I would say even if AMQP was chosen, it would not mean being locked to the single vendor of the broker.

In my opinion, the consequence of this way of creating the specification (democratic and open to all members) is why the specifications are so big and might look too wide, multiple parts, because they are designed to cover almost any use case members (and their customers) might encounter, now or in the foreseeable future. And part 14 PubSub was born as a result of this openness as I understand. Walker, maybe you know more than I know though.

And here is when we have so many OPC UA profiles and facets. And Matthew, you are right, it might be complicated and confusing, hard to understand.

Therefore, I would not recommend the end-users start reading specifications, understand all those profiles, facets, etc.

Let me ask you: do you use any USB device, like a mouse, or keyboard? Do you know, what version they support: 3.1, 3.0, Type-C, 2.0? And did you read USB specifications before connecting your mouse to your laptop? BTW, right now I did a search and found the one for USB 3.1, and it is 631 pages (including appendixes). Not going to read it, thank you! Usually, I just try to plug in USB, and 50% of the time I have to turn it around (which is not a big deal for me) and it works, and then I forgot about it. I think the same with OPC UA.

If you are on the OPC UA client-side like you have SCADA or HMI, or maybe software like our ogamma Visual Logger for OPC, you don't need to worry about what is in the server-side, what profile it conforms to, etc. Because usually all kinds of variations you can observe exist only on the server-side - some devices have too small resources and can have just one subscription, with only 10 monitored items (tags) or no support for subscriptions at all, only read. Or they can only allow 2 sessions to be opened at a time. But clients usually don't have all those limitations, they have no limits like I need at least 100 variables to read, cannot read just 3 or 99. If the server can offer you only 10 tags, no problem for the client.

BTW – the common misunderstanding of the OPC UA is that it does not report by exception, only with PubSub you can get the report by exception feature. Wrong – regular OPC UA data access subscriptions (without PubSub) provide you report by exception. And almost any OPC UA server supports it. And it is lightweight and performant – currently, I am running my application collecting data for 200,000 variables changing every second with no problem at all, in a regular workstation, with all 3 parts – server, client, and database in the same box.

Or another case: if you a Developer of some existing software, and want to add support for OPC UA (client or server, or both) - I would not say don't read the specs at all, I would say: go through (note: not read, just go over headlines and see what is the structure) the part 1, and part 4, but do not spend longer than 1 day. Why - because there are available OPC UA SDKs for most popular programming languages, open or close source, pick one, and they will save your time. No need to understand exactly the whole specs.

In my case, for our product, I did select OPC UA as the single protocol to collect industrial data from all kinds of sources, because, first, many PLCs support it built-in. Example - Siemens PLCs. And second, with available in-the-market wrappers, you can connect to a wide range of classic OPC servers. And with OPC UA Server for Modbus, you can connect to a wide range of legacy devices. So the reason for choosing OPC UA as a major protocol for our product – not having some special relations with OPC Foundation or Microsoft, but because it is universal.

I did have some connectivity issues with other OPC UA Servers (our customers’ as well vendors’ at OPC Workshops), but all these were implementation errors on our side, and once they were fixed, have no issues with connecting to any OPC UA Severs our customers have. Works just like a USB.

On the destination database side, we currently support regular MQTT among a whole bunch of other time-series databases, like InfluxDB, variations of SQL, Apache Kafka. In the roadmap - add support for more flexibility in the MQTT payload format: from current just decimal/numeric values to template-based JSON payload, as well as OPC UA PubSub JSON format and hopefully SparkPlug too.

So, Matthew, if you cannot find other solutions that support PubSub or SparkPlug, check out with us later.

Definitely, I see that OPC UA has a bright future. And I don’t think it will have this future on the expense / taking place of other protocols or standards like SparkPlug. Just like as Walker mentioned in one of his videos that multiple religions can co-exist in peace because in the end all of them about the same God.