I would not be able to get this perspective anywhere else. I especially liked what you did at the end in providing a path for OPC UA to be improved. They really need to strip it down, really strip it down. I was not aware that in some cases with implementation that you would have to make a choice between "this" and "that" part of the spec. Really interesting. When I first read about Companion Specifications, I became completely confused and got a headache. But my experience in programming allowed me to come to the conclusion that it's just a really fancy "Typedef" statement from "C". It's like over-complicating JSON. In my opinion, it's just a big-ass data structure. I would not even call it a model. That's how I was able to wrap my head around it. Thanks again for another informative video. Learned lots as usual!

The most impressive explanation I have ever seen. Thank you so much.

It’s not just a mess, it’s a F$@king mess. Hahahaha love the transparency 👍

Thank you for the clear picture of our limitations & what we should look at to be more open-minded in automation for Industry 4.0

Awesome as usual! Can't wait for the next vid! Need more green! More Soylent green!

Well done!

Amazing explanation

If I4.0 is about extreme connectivity, then OPC has no fit into I4.0. It would be like having a cell network that has a different type of communication for every single carrier and they each had to have their own tower and their own FCC licensed bands.

You da man. thanks

3:30 not mincing words haha

beaucoup ... beaucoup ... beaucoup ... beaucoup dollars // great video overview that was fun to watch as well

Hi I would know in order to replace a Honeywell FSC Unit with Siemens, would it be rational to migrate the Program too or should I start from scratch and throw the FSC away?

What is the most used standard for transfering files between OT-networks? Not signals och datavalues just files such as flatfiles etc.

Very helpful Video! Im very happy to havé fou d your Channel!

I think a way to simplify understanding of why OPC might not be fit for IoT is because it relied on a system (OLE) that had a big supposition at its core, namely: it assumed the communication was happening only inside the computer, via the paths in the motherboard, so it could assume with high reliability that the data would be transmitted, and transmitted properly, whereas in IoT data flow is not always that reliable, as it flows through many other mediums. Let me know your thoughts on this.

So is OPC UA its own communication protocol like PROFINET, Ethernet/IP, MODBUS TCP Etc? Or what isit?

Thank you for calling it out for what it is! I don't trust people that sugar-coat anything! I don't understand why these foundation members focus so much on their product not playing well with other products, thinking it gives them a leg-up. Why not spend more time improving your product so we integrators use THEIR products because it does play so well with others. How can they NOT see that this actually limits their client base? This is why people that love Allen-Bradley stick with Allen-Bradley and people that love Siemens stick with Siemens products.......... . How about increasing your sales by winning more customers by building better product. Exercise some common sense.

So what are other options besides Kepware OPC UA that allow you to keep your servers in house?

What is CNC?

Jeff who ?

Opc going to be failed Soon It's already failed