Could someone give me the low down on what the benefits and/or disadvantages are between OPC UA and the third party vendors? To me it only makes sense to swap over to the new server since it is packaged through Ignition. I don’t have to check multiple websites for updates,bug fixes, etc. What are the “specs” for this server. If performance increases or it is more stable it’s an easy sell. Oh I save a little money too.
All of the above. The binary encoding (right IA?) allows for better performance, while built-in encryption adds security. The term OPC-UA is not Inductive Automation software, rather the standard their server is built off of. All the major vendors have or are planning on releasing OPC-DA (what you are used to) to OPC-UA wrappers, but you still have to deal with the crappy setup because of DCOM. Its a little easier with the wrapper, but also more costly. OPC-UA blows DA out of the water.
With current industrial software from most vendors, the OPC piece of the architecture connects the program you’re using (HMI, data logger, transaction manager, etc) with the driver that knows how to speak with the PLC (OPC server). For example, when you buy RSView from your Rockwell distributer, they’ll likely also sell you KepServer EX so that your visualization program can talk to the PLC. I think some versions of Wonderware InTouch have direct drivers included for some PLC models - in this case you wouldn’t need OPC. However, they’re not in the driver business so they need to speak OPC to communicate with hundreds of different model families - made possible via our friends at Kepware and Matrikon.
Ignition could include direct PLC drivers - that would eliminate the need for OPC. However, we chose to remain interoperable and implement a full OPC-UA server. This way, many other external future applications can communicate with us via the standards that the OPC Foundation publishes. Similarly, Ignition OPC client modules will be able to communicate with future 3rd party OPC servers as well as devices that will “speak OPC-UA” natively.
OPC-UA really shines compared to OPC-DA (most current OPC servers) when your client program is on a different computer than the OPC server. The standard is the matured result of 15+ years of experience - applying new Internet/networking technologies, security techniques, performance tricks, and lessons learned from past mistakes; the result of collaboration from key developers from all the major competing players. To my understanding, all the vendors have embraced OPC-UA. It’s just a matter of market timing - Ignition appears to be the first commercial product, but there is a lot of OPC-UA development going on.
As far as writing good drivers, adhering to the OPC spec is important, but there’s much more than that. The most important factor is stability. When it comes to performance, there’s a ton that can be done: How do you handle polling, stale data and deal with caching, batching your reads/writes together and doing array type operations, etc. We are very pleased with the performance and stability results we’ve achieved.
The 3rd party driver companies should stay well ahead of us in terms of supported devices for the foreseeable future. You can currently use their existing (OPC-DA) products with a “wrapper”. Hopefully they release solid OPC-UA servers sooner rather than later.
One significant current advantage of Ignition is that it’s the only cross platform OPC product in town. If you want to go completely non-Microsoft, you’re out of luck with anyone else. I hope other vendors jump on the bandwagon because this reliance on Windows with industrial software is ridiculous. It’s also free, and integrated, which never hurts.
Thanks for the input guys. I am not sure if our system is small or large compared to others, but 6000 subscriptions seems large. Also this does not include a “future” recipe system that could triple the throughput. If I had a 100 or so opc items across a couple of plc’s it would be different. Our current Kepware server is stable with 20 channels and 6000+ items. Before I make a conversion to a new server I need “facts”.
Nathan’s post sums it up well. I just thought I’d add my own perspective…
Putting aside OPC-UA for just a second, in my experience over the last 6 years or so of being dependent on OPC servers the most important criteria for choosing a server are performance, stability, troubleshooting facilities, and having the drivers you need and might need in the future.
I’ve seen how unreliable servers can wreak havoc. I’ve also been frustrated by servers that offer little to no troubleshooting facilities (no tracing, barely any device info, etc). Finally, I prefer servers that let you house all the drivers you need in one place, instead of running multiple servers. This last point isn’t a deal breaker, but it’s preferable.
Now, you bring up valid points about “single source”. It’s nice to only have to go to one place for help. I think that people have also been trained a bit to think that single source components must work better together than components mixed from different vendors. It could be true, but the entire goal of the OPC foundation is to help create a situation where it’s not true. The goal has always been “plug-and-play” compatibility between servers and clients. We fully support this goal, which is why we go to interoperability conferences, participate in the foundation, etc.
Without dragging this on too much, I just want to say that that I fully recommend that customers evaluate third party options thoroughly. I personally have a lot of respect for some of the other OPC server vendors’ products, and certainly would not recommend switching away solely for the “single source” benefits.
1 Like
Dear All,
Could we use OPC wrapper also for OPC AE for connection to OPC UA
Thanks
I don't think I understand the question, could you provide more information? The OPC-UA spec does include events, but Ignition currently doesn't use anything from that part of the spec...