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?
When PTC do IIoT, we (I’m an IIoT architect for PTC) have ThingWorx in the big black box on your diagram and don’t use OPC-UA between Kepware and ThingWorx. When we’re using Kepware for gathering data for other people’s modern, non-scada, IIoT platforms we typically either use message queues for Kepware to push data to them or they have some version of field agent to transport our data to their server.
@@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
Another consideration: MQTT is very lightweight and publishes values whether anyone in the business uses them or not, at the rate that the server (source) wants. OPC-UA has more overhead and all conceivable data is made browsable, but only the data that is actually needed (subscribed) is sent over the network. In some cases, it may be easier to modify the client to subscribe to additional data rather than modify the server (source) to publish additional data. MQTT is great in that new devices easily appear in its namespace. There are OPC-UA products being developed to catch up to MQTT's functionality: aggregating multiple servers into one namespace to act like a broker. This is separate from the Part14 addition, which is planned for Time Sensitive Networks, such as PLC loop control, among other applications.
It is extremely refreshing to find a video with GOOD video AND audio-quality on the topic of industrial automation. Well done sir, you have a new subscriber. Keep it up!
What do you mean by OPC is not report by exception? I think OPC UA supports report by exception, meaning only changes can be reported from OPC UA server to the OPC client that has susbcribed the data. Surely the proprietary communication below the OPC server e.g. Modbus can then be based on polling or with some intelligent protocol like DNP that can also be report by exception.
OPC foundation has been disguising its stadards as "Open". You said it right to the point. It is far from open. Its stadards are members ONLY, and are closed to the non-paying communities! The OPC standard is indeed heavy on resource consumption. Hence, its performance in terms of data exchange rate is always poor.
To play devils advocate, but transaction of opening a bank account and it showing up in your banking software actually (in many cases) means that someone will first create it, and then add it for you, or link it to your software account. Reason they would do this is (I assume) due to security procedures. It is not safe default to show new bank account in banking software. Which leads me to my question: how do you handle security when nodes need to "show up" automatically? Is there authentication? What do you do when authentication keys / certs needs to be updated / maintained? Great videos! Keep them coming :)
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.
There are some issues needed to discuss. Please consider that if we want here challenge on some middle ware like ignition, Iconics, for unified SCADA infrastructure or emerge using OPC UA as infrastructure for unified architecture. Your deduction were amazing and new to me but I think why many Automation pioneers like OPC foundation speak easily about OPC UA. Siemens invest on OPC UA over TSN recently. it means if Siemens considers Mindsphere as IIoT infrastructure it can speak about OPC UA over TSN as unified architecture. You are totally right about MES, ERP, WSM that are not embedded with OPC UA, and there is MW needed but please explain more on it. Classify exactly where we have OPC UA as our unified architecture and where it is difficult to speak. This is age of OPC UA TSN, PI International speak about Profinet over TSN, Ethercat believes Ethercat is more better than both, Now who is the real winner in the field. I am member of Digital Transformation group for steel factory and want to decide. Where I can write for you directly to discuss?
Quick question: why don't you have kepserver or whatever software you use as an OPC Server push data into an SQL sever and have the MES/ERP/WMS take the data out from SQL. Since these system does not have to be real time, SQL would be able to give them high volume time-stamp data. Interesting video. Appreciate how you visualize iiot in a user friendly manner.
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.
One question please. How do you bring pre internet era equipment connected to IIOT . For ex for large utlities companies some of the plants are 20-30 years legacy, some may not have PLC hooked, so what is the first step to bring them in IIOT network ?
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.
Thank you VERY MUCH for making this video, we have been fighting with opc.ua as a small company and found it to be very expensive and complicated your video shows the flow of digital exchange and control in a beautiful way.
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.
I was able to download the standards for free, by simply registering for a free account on the OPC foundation website. How much were you being charged for the specifications?
@@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.
Great video! I'm curious about what sort of standard data model that you would typically use. Here you've compared OPC UA and MQTT, however MQTT is a transport layer protocol and OPC UA is application layer including information/data model which provides the interoperability piece.
Thanks for the great videos. I enjoy every one of them. I have a question from this post: Why wouldn't AVEVA system platform work as the UNS? What's its weakness comparing to igntion ccoa\fs?
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.
Great Video. Should a factory ideally have only 1 OPC-UA server or multiple servers? (I assume only 1 which can handle 1000 of connections but not sure)
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)
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.
Is the big black box (Ignition is this example) what is sometimes referred to as the “unified namespace”? I also saw a video with a demo of mqtt and broker (on raspberry pi). Trying to get my head around total picture. Thanks for your great video’s!
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!
We are a year further now, and I don't see any decline in the use of OPC-UA. I think too often when you talk about opc-ua you relate it to stand alone devices (valves, sensor). But when we purchase a machine that has a thousand of data points, I actually specify OPC-UA. My added cost is only a 100euro for each PLC so what are we even talking about?! Especially combined with Ignition which is focusing heavily on OPC-UA it is extremely powerful. We Don't have tu use integrators anymore and this is where the real cost savings occur. We have a staff of three automation engineers that manage all scada and MES connectivity for 16 manufacturing sites. When we have smaller non production critical projects, we Don't even use PLC's anymore. We use remote I/O, IPC and write our own app to control the process. Often Modbus TCP can be used and implementation becomes a walk in the park. We have no MqTT anywhere. The reason is mostly because here in Europe at least, all of the Controllers, IPC's, machinebuilders etc come almost as standard with OPC-UA. Just my 2cts
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.
We still use OPC DA. I've tried to implement OPC-UA but people don't want to change. And I don't think anyone here has even heard of MQTT apart from me lol
This idea that new equipment just "shows up" on your network is extremely problematic from a security standpoint. One must assume that any new device in a plant must adhere to the security and privacy protocols of the organization first and foremost. Also, just what is all this data that is so important for the enterprise? I've been working in automation for over 20 years and the most important information is still the basic process parameters like flow, temperature, pressure...etc., all of which is already collected via ancient 4-20mA signals. Do you really need device serials numbers, manufacturing date, and other such information? In some situations I've seen engineers request data that rarely changes, like the Derivative component of a PID controller in a PLC. And yet I've also seen IT departments balk at the process data resolution needed for proper process analysis because it requires too much historian space to store. All of this leads me to conclude that the vast majority of this IIOT stuff is vast overkill and nearly completely unnecessary. Much of this has been available for decades via HART, which remains vastly underutilized.
I hope not, it's an awfully ugly and inefficient solution, design of service is frustrating, dev is heavier than lead, testing is painful, MQTT based solutions are so much better.
What is your companies IIoT strategy?
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?
When PTC do IIoT, we (I’m an IIoT architect for PTC) have ThingWorx in the big black box on your diagram and don’t use OPC-UA between Kepware and ThingWorx. When we’re using Kepware for gathering data for other people’s modern, non-scada, IIoT platforms we typically either use message queues for Kepware to push data to them or they have some version of field agent to transport our data to their server.
Hi Michael. I added your comment to our list of videos! Thank you.
Data reliability is a big issue with MQTT. It is really difficult to troubleshoot MQTT messages if you don't have any historical data.
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
Another consideration: MQTT is very lightweight and publishes values whether anyone in the business uses them or not, at the rate that the server (source) wants. OPC-UA has more overhead and all conceivable data is made browsable, but only the data that is actually needed (subscribed) is sent over the network. In some cases, it may be easier to modify the client to subscribe to additional data rather than modify the server (source) to publish additional data. MQTT is great in that new devices easily appear in its namespace. There are OPC-UA products being developed to catch up to MQTT's functionality: aggregating multiple servers into one namespace to act like a broker. This is separate from the Part14 addition, which is planned for Time Sensitive Networks, such as PLC loop control, among other applications.
Thank you Matthew. How you are doing well!
It is extremely refreshing to find a video with GOOD video AND audio-quality on the topic of industrial automation. Well done sir, you have a new subscriber. Keep it up!
Thank you JT!
What do you mean by OPC is not report by exception? I think OPC UA supports report by exception, meaning only changes can be reported from OPC UA server to the OPC client that has susbcribed the data. Surely the proprietary communication below the OPC server e.g. Modbus can then be based on polling or with some intelligent protocol like DNP that can also be report by exception.
OPC foundation has been disguising its stadards as "Open". You said it right to the point. It is far from open. Its stadards are members ONLY, and are closed to the non-paying communities!
The OPC standard is indeed heavy on resource consumption. Hence, its performance in terms of data exchange rate is always poor.
To play devils advocate, but transaction of opening a bank account and it showing up in your banking software actually (in many cases) means that someone will first create it, and then add it for you, or link it to your software account.
Reason they would do this is (I assume) due to security procedures. It is not safe default to show new bank account in banking software. Which leads me to my question: how do you handle security when nodes need to "show up" automatically? Is there authentication? What do you do when authentication keys / certs needs to be updated / maintained?
Great videos! Keep them coming :)
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.
There are some issues needed to discuss. Please consider that if we want here challenge on some middle ware like ignition, Iconics, for unified SCADA infrastructure or emerge using OPC UA as infrastructure for unified architecture. Your deduction were amazing and new to me but I think why many Automation pioneers like OPC foundation speak easily about OPC UA. Siemens invest on OPC UA over TSN recently. it means if Siemens considers Mindsphere as IIoT infrastructure it can speak about OPC UA over TSN as unified architecture. You are totally right about MES, ERP, WSM that are not embedded with OPC UA, and there is MW needed but please explain more on it. Classify exactly where we have OPC UA as our unified architecture and where it is difficult to speak. This is age of OPC UA TSN, PI International speak about Profinet over TSN, Ethercat believes Ethercat is more better than both, Now who is the real winner in the field. I am member of Digital Transformation group for steel factory and want to decide. Where I can write for you directly to discuss?
We added this to our video topic list!
Quick question: why don't you have kepserver or whatever software you use as an OPC Server push data into an SQL sever and have the MES/ERP/WMS take the data out from SQL. Since these system does not have to be real time, SQL would be able to give them high volume time-stamp data. Interesting video. Appreciate how you visualize iiot in a user friendly manner.
Scalability. We get this question all the time. Just because it works. Doesn't mean it will work at scale.
Can't Ignition talk OPC-UA so Kepware is redundant in this example? Is it because you need MQTT to have update by exception?
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.
One question please. How do you bring pre internet era equipment connected to IIOT . For ex for large utlities companies some of the plants are 20-30 years legacy, some may not have PLC hooked, so what is the first step to bring them in IIOT network ?
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.
Thank you VERY MUCH for making this video, we have been fighting with opc.ua as a small company and found it to be very expensive and complicated
your video shows the flow of digital exchange and control in a beautiful way.
We are glad that we can help!
What do you think of Crosser IoT Edge?
How security between 2 hardwares example for opc to mes and opc to plc? Firewall for example will it works once activate it? Tq
As far as I know, membership is not required for the use of OPC-UA technology or the creation of OPC-UA products. Am I missing something?
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
I was able to download the standards for free, by simply registering for a free account on the OPC foundation website. How much were you being charged for the specifications?
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.
Great video! I'm curious about what sort of standard data model that you would typically use. Here you've compared OPC UA and MQTT, however MQTT is a transport layer protocol and OPC UA is application layer including information/data model which provides the interoperability piece.
Great suggestion! We can use Ignition Edge SparkplugB to define our models. Or we use HighByte on the edge.
Thanks for the great videos. I enjoy every one of them. I have a question from this post: Why wouldn't AVEVA system platform work as the UNS? What's its weakness comparing to igntion
ccoa\fs?
Great question! Adding this to discord
Is there is any possible way to send stored procedures to plc via mqtt ?
Great question. Ignition Transaction groups will do this!
Shall you explain the term you used 'resource intensive'?
It uses a lot of resources "bandwidth" to transmit data.
You mentioned you don’t use Iconics. Out of curiosity, why?
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.
Great explanation. Is analytics a part of your business or do you just set it up to be used most efficiently?
Thanks for the question Grey! We have business intelligence professionals on staff that help our customers make sense of this data!
Great job, I thought your answer in the end is precisely the right answer
Thank you!
Isn’t OPC report by exception ?
Great Video. Should a factory ideally have only 1 OPC-UA server or multiple servers? (I assume only 1 which can handle 1000 of connections but not sure)
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.
Is the big black box (Ignition is this example) what is sometimes referred to as the “unified namespace”? I also saw a video with a demo of mqtt and broker (on raspberry pi).
Trying to get my head around total picture.
Thanks for your great video’s!
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!
We are a year further now, and I don't see any decline in the use of OPC-UA. I think too often when you talk about opc-ua you relate it to stand alone devices (valves, sensor). But when we purchase a machine that has a thousand of data points, I actually specify OPC-UA. My added cost is only a 100euro for each PLC so what are we even talking about?!
Especially combined with Ignition which is focusing heavily on OPC-UA it is extremely powerful.
We Don't have tu use integrators anymore and this is where the real cost savings occur. We have a staff of three automation engineers that manage all scada and MES connectivity for 16 manufacturing sites.
When we have smaller non production critical projects, we Don't even use PLC's anymore. We use remote I/O, IPC and write our own app to control the process. Often Modbus TCP can be used and implementation becomes a walk in the park.
We have no MqTT anywhere. The reason is mostly because here in Europe at least, all of the Controllers, IPC's, machinebuilders etc come almost as standard with OPC-UA.
Just my 2cts
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.
Nice intro for me. Once you said MQTT, I knew where you were going. Thanks.
Thank you Craig!
We still use OPC DA. I've tried to implement OPC-UA but people don't want to change. And I don't think anyone here has even heard of MQTT apart from me lol
Great video. I found it very useful.
Glad it was helpful!
Great video Walker. Could you please include REST API topics in you content ?
Thank you! Added this to our video list.
Great intro to OPC-UA, Thanks
Glad you like it!
do IIOT need plc?
PLC needs IIoT... every mfg has a PLC somewhere.
This idea that new equipment just "shows up" on your network is extremely problematic from a security standpoint. One must assume that any new device in a plant must adhere to the security and privacy protocols of the organization first and foremost.
Also, just what is all this data that is so important for the enterprise? I've been working in automation for over 20 years and the most important information is still the basic process parameters like flow, temperature, pressure...etc., all of which is already collected via ancient 4-20mA signals. Do you really need device serials numbers, manufacturing date, and other such information? In some situations I've seen engineers request data that rarely changes, like the Derivative component of a PID controller in a PLC. And yet I've also seen IT departments balk at the process data resolution needed for proper process analysis because it requires too much historian space to store. All of this leads me to conclude that the vast majority of this IIOT stuff is vast overkill and nearly completely unnecessary. Much of this has been available for decades via HART, which remains vastly underutilized.
Thanks for the question Mark! We responded in this video here: th-cam.com/video/GruN5S18-qI/w-d-xo.html
How are you doing Mark?
Great vid!
Thank you!
No
💯
OPC UA is
Incredibly resource intensively
Not very open ,just open for OPC club.
Not report by exception,instead, poll response
to the point！
Thank you!
I hope not, it's an awfully ugly and inefficient solution, design of service is frustrating, dev is heavier than lead, testing is painful, MQTT based solutions are so much better.
Thank you!