Is OPC UA the Future of IIoT? 

We do whatever the customer says they want and then spend the next few years dealing with their complaining that it sucks. Why? What does everyone else do?

@@Honest_Max We teach the solution in mastermind... Walker says this: If you quote Digital Transformation as a project I can guarantee 2 things: 1. You will fail 2. Your customer will pay too much 3. You will not be getting along when you are done. Does that sound familiar Max?

Thank you JT!

Hi Michael. I added your comment to our list of videos! Thank you.

We are glad that we can help!

Thank you Matthew. How you are doing well!

We will respond to this.

@@4.0Solutions can you please post link to video here when you do?

@@omairtariq7740 Yes I will do that. Please join the discord server too. It's a great place to discuss technical details. There are 657 professionals in there right now.

Why have to follow MQTT ?... there are millions of transactions happens in seconds for banking and other industry .... MQTT came into picture in the early days of IoT buzz word because that time the small wifi devices unable to handle heavy messages and other secure APis We just need to make the small devices communicate like computers which already we got

Thank you!

Great suggestion! We can use Ignition Edge SparkplugB to define our models. Or we use HighByte on the edge.

Nikola Radosavljević There’s a lot of people talking about the approach. With Kepware and ThingWorx it’s something like (it depends on the driver): 1/ you create a driver in Kepware and the tags are automatically generated 2/ Kepware uses a preshared Kepware to authenticate and connect to ThingWorx 3/ you go to ThingWorx to create your application and the tags are browsable/saveable/linkable but not doing anything by default apart from giving you options. For me it doesn’t have to be fully automatic, I just need some way to automate the creation of the configuration based on the device or it’s program. Some devices could have ~30k tags in them. Kepware/ThingWorx do this if the device and/or program support it e.g. Rockwell’s Logix and Siemens S7.

We did respond to this.

Great question! Adding this to discord

Thank you Craig!

Scalability. We get this question all the time. Just because it works. Doesn't mean it will work at scale.

You need to check the protocol the legacy hardware uses. Probably something like modbus rtu or profibus. You would need to have hardware which converts the protocol to opc ua. You can buy commercial solutions or build your own hardware/software to do the job. Keep in mind that I would need much more information to give proper advice.

Look into Edge Devices / Edge Gateways to convert this data to IIoT Data close to the edge of the network.

We added this to our video topic list!

Thanks for the question Grey! We have business intelligence professionals on staff that help our customers make sense of this data!

Yes you got it! The Unified Namespace is a really simple concept that sometimes takes years to click. We have created the Digital Factory Mastermind Program to help people Click!

Glad you like it!

Great question. Ignition Transaction groups will do this!

Ted, good question. We have many examples of using both an external OPC Server along with the native OPC Server that runs in Ignition. Kepserver is far superior at handling the overhead associated with poll/response architectures... while Ignition does have native machine drivers, they don't scale the way Kepserver or Top Server or Matrikon OPC can. In IIoT, you will be unifying many data sources together -- that sometimes means leveraging OPC externally and internally. Thanks again.

Glad it was helpful!

It uses a lot of resources "bandwidth" to transmit data.

Thank you! Added this to our video list.

I hate this answer, but it truly "depends". It depends on the factory (e.g., no of assets, no of apps, poll rate, app complexity) and compute resources. I've seen factories with infinitely many OPC-UA servers running on the edge in embedded devices and I've seen factories running just one OPC-UA server running on a large server. The easier way to think about it is in terms of the number of tags and segmentation. There exist implementations of Kepware's KepServerEx, a popular Windows-based OPC server, with millions of tags. This can easily satisfy an entire factory. Add in the redundancy module for a high-availability pair and this approach can be viable. However, for some factories, this approach does not work at all. Having one large OPC server for the entire plant creates complications for planned and unplanned downtime. It creates a systemic risk which many factories seek to minimize. A factory may not be able to tolerate any plant-wide downtime or maintenance windows. As a result, they may better off running a separate OPC server for a logical segment of the factory (e.g., line/cell, asset type, building, area). Cost, obviously, is a factor as well. In environments where its mostly data collection, I've gone with one instance of KepServerEx. This was 100+ devices and hundreds of thousands of tags. In environments where there was process supervision in addition to data collection, I've stood up multiple instances of KepServerEx. This is 10-30 devices and tens of thousands of tags. The later approach, in a more "closed-loop" environment where downtime is more disruptive, made server maintenance more practical. I like the approach of segmentation. It's always easier to take a line down than an entire plant down - planned or unplanned. I increasingly have grown wary of any big monolithic thing that everyone is scared to touch. It becomes an excuse not to maintain or change. This can impede innovation. To sum it up: Balance cost (e.g., licensing, compute) Balance risk (e.g., downtime, maintenance) Balance performance (e.g., qty servers, qty clients, qty tags, apps used)

@@jrs89 Excellent answer. It really does depend on the architecture.

Your factory will have as many OPC-UA servers as it has controllers/devices enabled with OPC-UA. It can be thousands, but with the propper architecture you can manage all of them through a (very strong) server acting as the client. This is what we do in our organisation.

Does this give you permission to install it on your hardware and sell it as an OEM though? 🤔

@@4.0Solutions open62541.org/ is an open-source SDK of OPC-UA, and is distributed royalty-free and can be incorporated into proprietary software. The Open62541 organization certified an instantiation of their SDK with the foundation, so it is legit. Best I can tell, Foundation membership (paid) allows other benefits, such as being able to help drive the direction of the specification and early access to them.

Thank you!

That's correct. The information provided in the video is incorrect. Also, Microsoft has standardized on OPC UA in its IIoT platform and normalizes all data to it at the Edge for easy analytics in the cloud and to avoid locking the customer into a proprietary data format. In our experience, OPC UA is both lightweight and performant. So again, I can't share the experience of Walker.

We will respond to this comment. Any time we have ever been incorrect (happens but it's rare) we make a video correcting our statements. But we still stand by what we said in this video.

@@4.0Solutions I think that this is a normal misunderstanding of what "open" actually means. When compared to proprietary (closed), open means that it is available by others and shared - it does not mean that everything is free as with open source. Even with open source which might be free, you have the license constraints which tell you what you can and can use it for.

Set that aside, it's still heavyweight and not the future of IIoT 🤷‍♂️ Sorry it doesn't scale.

:-D

Good question. There is a reason, I just don't remember it off the top of my head. It's also weird they've never actually reached out to work with us either... 🤷‍♂️ That's a good litmus test to separate those that get it vs those that don't.

Done! Thank you!

Just because people still don't get it and are still pushing OPC-UA (for an IIoT Infrastructure) doesn't mean we're wrong. Look at the growth and adoption of MQTT with Sparkplug b.

PLC needs IIoT... every mfg has a PLC somewhere.

Thanks for the question Mark! We responded in this video here: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-GruN5S18-qI.html

How are you doing Mark?

💯

Thank you!

Yes! LOL

Thank you!