Really nice overview, thanks. I very much like MQTT's JSON object modeling when using a versatile platform like Node-RED that handles JSON natively, for me it's one of its biggest advantages.
Although I have minimal knowledge and experience in this field, I have very similar views as explained in this video. Now, I don't have a crystal ball to look into the future but what I firmly believe is that OPC is not the answer. The main reason I say this is my reading of history. At the time OPC UA was being worked on, Service Oriented Architecture was all the rage and hence in the Microsoft world at least we had WCF which promised a lot of things. However, fast forward to end of 2022, WCF is no longer supported but instead Microsoft is advocating for Google's gRPC. While I have not worked with gRPC much apart from doing some beginner tutorials, for me the reason why gRPC has got more traction is simplicity, which incidentally, from this video, is one of the strengths of MQTT. As to the point that lots of companies are behind a particular technology/architecture/tool, is not a good indicator of the eventual "winner". Case in point, SOA at the time had all the major Software vendors provide SDKs. I am not saying that MQTT will be the "winner" but the fact that it is simpler means that adoption in the real world is likely to be higher simply because as a developer I have enough domain/infrastructure complexity to deal with and I don't need to deal with more complex architectures. The fact that people used MQTT in a domain that it was not really designed for further reinforces this point in my view. Now I think that currently, the main value of OPC UA is the standardised information model. However, there again, although I have not really worked in that field, currently as it stands, the information models are too complex and need simplifying ( I don't know how but divide and conquer would help). Then how we encode, transport, process and present the data can be left open depending upon our needs.
Really well balanced breakdown John. Thanks for your contribution. Have your Blue Book on OPC UA on my shelf. It helped me a lot in understanding the various aspects.
My experience has shown me that your thesis of "we'll have to support both" is true for everything. One size fits all assumes something generic, whereas specific is sometimes required (example: water proof hiking shoes versus ballet slippers). In my view the way forward is knowing when and how to chose and use different tools as they're most appropriate. Not picking one approach, but a set of patterns.
Very interesting, thank you! I see that some companies and tool vendors are moving to OPC UA with MQTT to have the benefits from both worlds. From my experience this is a nice opportunity. OPC UA client / server for dedicated SCADA and automation principles locally in combination with OPC UA MQTT for low latency, low bandwith pubsub tech for IoT concepts. What is your opinion on this?
There are companion specifications that define just that. However adding additional mixes of transport and data models adds complexity. Solutions and tools need to support that variety.
Nice video John. I did not know about your Blue Book. I just saw it on Amazon and there is no Kindle version. Any chance it will be available for Kindle?
Excellent breakdown, John. FYI, I cut my teeth on OPC from your Blue Book. You are spot on: 'OPC tries to be everything'. And... 'Object modeling in MQTT is weak'... I absolutely agree with your thesis: you have to support both and information models are super important to the future. I want three things: 1. OPC Foundation to burn the technical debt in the UA standard (the being everything to everyone) 2. OPC foundation to re-write part 14 pub/sub 3. Leverage OPC UA Information and Object models with MQTT SPb. Thanks for the run-down!!!
Thanks Walker. Appreciate your thoughts. It's almost like the dems and repubs. All polarized. MQTT people won't admit its weaknesses. UA People won't admit its faults. Need everyone to work together to meld the best of both so we have a really good solution (never will be a perfect one).
