since 2015 OPC-UA version 1.0.3 is released and since last year version 1.0.4.
What version of OPC-UA does Ignition 7.9.12 support?
Is there a change to 8.x.x, regarding the supported OPC-UA versions?
The reason for my question is, that we have a device - once the OPC-UA connection is established successfully - the connection will not reestablished after the device is rebooted. The reaction from a consultant was, Ignition does not support at least OPC-UA version 1.0.3, what causes that problem.
It is stranger: auto reconnect fails only on default port 4840. When a port is used, that differs from 4840, it is working.
Now I check, if that problem is caused by that Ignition version or by the OPC-UA device.
In Ignition 7.9.12, the server is something like 1.01 or maybe 1.02, the client supports 1.03.
In Ignition 8.0 both the server and client support 1.03.
If you can get a Wireshark capture of the traffic between Ignition and this device, starting before it’s restarted and continuing after while Ignition tries to reconnect, it would help troubleshoot.
Does that mean all features of OPC UA version 1.03 are supported by Ignition’s OPC UA server? The specification is huge , our faces turn blue while reading them, let alone understanding them and using them! Wish they had kept it simple! More specifically does it implement the following specs fully?
Part 3: Address Space Model (**)
Part 4: Services
Part 5: Information Model
Part 8: Data Access
Part 9: Alarms and Conditions (*)
Part 11: Historical Access (*)
To the best of my knowledge the (*) specs are not supported and (**) is partially supported. What features of address space models are used in the OPC UA server of Ignition? Perhaps UDT’s could have been modeled in OPC address space but they aren’t. Does it mean it just uses DA model ? It will be a great help to know how the address space is modeled , what information model is used and what services are supported in the OPC UA server of Ignition.
As you suspected, Alarms and Conditions and Historical Access are not implemented at all. Only basic information modeling is done. We don't have any custom ObjectTypes, VariableTypes, or DataTypes in the address space. Everything is just regular base types.
Thanks a lot for the reply Kevin. I think the OPC foundation has really complicated the whole spec, they could have kept it simple.They should have restricted to DA like address space with services approach in stead of COM/DCOM approach which would have been easier to adopt and more light weight! I don’t think any one can ever implement a server with the full spec! Even if its done, who will build such a complex address space for their plants! It will become an IT project! Things should be kept simple for them to succeed.
It’s complex for sure, but I don’t agree that it should have been done differently. OPC UA’s modeling capabilities are one of its biggest strengths. The servers that are embedded in PLCs are already starting to use modeling (custom DataTypes mostly) with great success. Some PLCs like the Siemens S7-1500 allow you to built custom VariableType and ObjectTypes for your projects as well.
In the bigger picture, these modeling capabilities allow for the existence of the growing number of OPC UA companion specs that standardize how any PLC, machine, or server should model its address space in the context of a given industry or spec, e.g. AutoID, PackML, CNC Machines, IEC 61850, etc… (see here for a handful of them that are now available online).
It’s a longterm play but I think the complexity will pay off. Ignition doesn’t take advantage of much of this because it already has its own complex tag system that makes doing any kind of modeling in our OPC UA server an unnecessary duplication of effort.
But at least they could have written the specs in an understandable way such as concepts of classes and inheritance etc which is understood by all properly. Here they have vague concepts like nodes and relations and what not and we have to flip the pages back and forth to understand what they are talking about! Any way, I think that’s the way specs are written, no one can understand them properly, they are generic and abstract concepts, subject to interpretation, understood only to the authors!
Any ways, I hope I can understand the OPC UA implementation supported by Ignition by reading thru the scripting functions and trial and error. It will be nice to have a webinar on it or at least IU course on it so that we can use it to build our modules with it properly.
Does the kepware and milo and prosys and Siemens etc opc ua servers also implement Ignition Opc ua like DA features only or They are more detailed implementations? The complexity of the opc standard defeats the purpose of Its openness and interoperability . Few people are minting money in training on the standard and selling their sdk! Wish a simplified version could have been released by the foundation keeping the advanced and compatibility with Futuristic standards separate ! This makes the server bulky ! It’s high time all scada vendors and equipment vendors came out with a light weight and small foot print standard for interoperability and it can fit on embedded devices. OPC name itself is a misnomer! It doesn’t convey right meaning !
Indeed embedded devices are very powerful these days . Today’s mobile processor is more powerful than laptops and desktops 5 year ago ! I am glad that you are up beat about OPC Standard .