This question is regarding OPC UA specification design for a industrial application. I am a beginner to OPC UA terminology and wondering what is the process of designing a OPC UA specification. I searched online for tutorials, tools and went through the standard textbook of OPC UA. I have got information in bits and parts but never a structured approach.
Questions
Do we have any open source tools that can used to design a OPC UA specification?
Do we have any standard document describing the process of designing a OPC UA specification
Any Small clue reasoning to a approach is much appreciated. Thank you
I think you're a little confused. You don't want to design an "OPC-UA specification"; these specifications already exist, are maintained by the OPC Foundation, and define what OPC-UA actually is.
More likely, you need to develop an application that conforms to or is compatible with OPC-UA in some way. In that case, we'll need to know what it is your application is doing (is it a client or server?) and what language you're planning to develop it in. From there you can determine whether or not you need open source or commercial tools to move forward.
Basic bulding blocks for information models are found within the UA companion specifications. A range of working groups develop these for various domains of interest. Standard semantic models are defined to provide interoperability.Look to OPC Foundation site. Provided a companion spec, you might as UA client imediately recognize the adresspace content of a servér you have never seen before. As UA you may provide data to some client you currently not know, but it might recognize the content anyway. And when you connect to another UA that complies with the same companion spec, you might recognize that content to with very little extra effort.
Related
In the opc foundation site says : "opc ua is platform independent."
I have looked the most used opc implementation products matrikon and kepserver.
When i look at these product documentation , both of require to work on windows based server.
I am stuck with that. Where is platform independency?
That's a choice those products made.
Don't confuse OPC UA for a product that implements OPC UA.
Ignition, for example, is cross platform, including its built-in OPC UA server and drivers.
Additionally to Kevin Herrons Answer, there are various open source stacks available, which support different platforms.
E.g. open62541 (https://www.open62541.org) supports Linux, Windows, OS X, and a lot of embedded platforms.
A more complete list of OPC UA implementations can be found here:
https://github.com/open62541/open62541/wiki/List-of-Open-Source-OPC-UA-Implementations
Of Course OPC UA is platform independent. Platform independency was the on major reason for moving from OPC classic to OPC UA.
here you are confusing with OPC UA standard and the product based on OPC UA.
OPC UA is platform independent and one main reason is that it has a complete, extensive and not linked to any platform documentation ... and free available to all.
I wrote a year ago my own client for Android
I'm wondering if for simply communicating with a PLC, like reading and writing tags, do I need all of the other heavy lifting that comes with an OPC-UA server?
I've tried writing a simple server in Python that talks to the PLC, but I get denied when requesting information from the PLC.
The Controllogix PLC I'm attempting to communicate with uses Ethernet/IP to communicate, so why doesn't a simple server/client script work? What is required exactly to communicate with an Allen Bradley PLC or PLC's in general?
There is quite a bit required to communicate with a PLC.
Each vendor has a driver, there are firmware compatibility considerations. Different protocols to think about.
OPC-UA makes it a bit more generic, but OPC-UA still has a set of things to work around when setting up communications.
Most of the OPC products I've worked with, needs to have their security adjusted to allow anonymous communication. It's generally bad practice to do this. (A network intrusion would be able to read/write to your automation layer) There is certificate signing and some encryption business that needs to be turned off if you're looking for simple communication. (Again, not a good practice but ok for learning)
After all that you have to have a notion of how your PLC is set up on your OPC server, there are channels, devices, namespaces etc. You'll point the OPC client to some opc.tcp://:
If you got this far you're almost done, I'm assuming your OPC server is running and has tags configured at this point. You can use your OPC-UA API to do a read. It can return just the value, or you can get an object back with tag health, timestamp, and a bunch of other data. Depends on the implementation. After that you can do subscriptions, writes...whatever else you need.
TLDR: OPC server not required, but may be the easiest method. Turn off security. (But turn it back on before exposing your control layer to the net)
I am also a little late to this conversation. If you are interested in coding your own solutions and don't want to use any of the commercially available standards, AdvancedHMI is a "mostly" open source solution written in VB.NET which is 100% free and provides communications to many different PLCs including the ControlLogix platform. Since I see you are programming in Python you may also be interested to know that the project does work under Mono on the Linux OS. I have used it to write gateways between EthernetIP and ModbusTCP and to pull data serially from OEM devices and push this data to a CLX PLC.
The forum is full of many helpful hints and is very active and supported.
Just trying to give you another option. DDE, NetDDE, FastDDE, OPC, DCOM, Suitelink.... These are all good, but mostly a pay to play adventure. As a programmer, it seems ridiculous to have to pay such an excessive amount of money just to talk to my hardware, IMHO. Sorry for the rant. Have Fun!
Update - Just wanted to also suggest the following open source project written in python:
https://github.com/dmroeder/pylogix
I have used this to write small programs for communicating with CompactLogix and ControlLogix. (Even to/from a RaspberryPi!)
Depends on several factors, if you want something simple to program you can opt for Modbus/TCP I think some AB PLC supports it without extra hardware.
However if you want something with more security for example for industrial use then OPC UA would be better choice but the programming has a complexity far higher than Modbus, even using the libraries of OPC Foundation or others. There is the option of using a commercial or free (if any) OPC UA server to save work, then you will need to program the client side only.
With Ethernet/IP it should also be possible, but the problem is that there is no clear specification and even different AB models talk different Ethernet/IP dialect ! , it is also far more complex to program than Modbus.
I am a little late to this discussion, but there are a couple commercial tools that make this a bit easier. The one that comes to mind for me when you say you are using python is Cogent's data hub. It is certainly not the cheapest tool out there, but they have already done all of the heavy lifting for PLC/PC communications & security.
If trying to read CLX data using Python, there are several open source implementations that will save you a lot of work. Such as this:
https://github.com/dmroeder/pylogix
If you use .NET and Visual Studio, you can use AdvancedHMI
to be able to read and write OPC Tags to ControlLogix platform is done via its communication Driver RSLinx. RSLinx acts as an OPC Server, it will need to be configured to communicate with the PLC and run on a networked PC on the same LAN. Several flavours of RSLinx are available (for WAN/VLAN also) but essentially this is the communications driver you need to talk to AB PLC's
I have an application whereby I need to read data from a PLC into a database and whereby I need to develop my own application to do this. I just need to read 5 values from the PLC and log it to a DB. I have a demo OPC server running and can access it via UA or DA.
After looking at many different approaches I settled on using an OPC server to connect to the PLC and then to write an OPC client to interface to the OPC server and then write the data to the DB from my app. My language of choice is C# with .Net and the only licence fee I am able to pay for is for the OPC server from my PLC vendor.
What I am however finding extremely frustrating is getting the right info on OPC to get started. I dont want to buy any stacks but would prefer an open source stack. The information seems very fragmented and all over the place. Most of the info about OPC seems to be hype about how easy it is to use etc.
The best post on Stackoverflow that I could find is: Noob guide to OPC: how to write a C# Hello World client? and some of the links are not active any more.
My question is therefore are there any good tutorials showing how to build and OPC client from scratch in .net and what is the best open source SDK to use without having to buy a vendor's stack?
Is DA also worth learning or should one stick with UA?
The big question is why is OPC so frustrating when its marketed as being so easy?
It would also be nice to have a nice high level guide on the theory that one needs to know to build a client. I do realize that with time its possible to eventually figure this from the resources available but with limited time to make sense of all the scattered resources a quicker guide would be helpful.
Stick with OPC UA.
Luckily for you, the OPC Foundation's C# reference implementation has the capabilities of both stack and SDK, whereas other language reference implementations are typically just stack functionality.
The code is available on GitHub: http://opcfoundation.github.io/UA-.NET/
If you're not a member of the foundation the code is available under GPL2.
As for your concerns about the ease of use and marketing... I assume it's because OPC UA is marketed towards end users, who will just be hooking up various OPC UA compliant applications, which is easy. As a developer I think its fair to say there's a little more assumed about your ability to figure things out... from code examples, the specifications, books that are available, etc...
I am entirely new to the OPC-UA world.
I need to establish a proof of concept of how to allow our ERP to communicate with PLCs. I am evaluating software that acts as an OPC-UA server (it is working). I found about Milo and got the code working in Eclipse. Looking at the examples, I got a toy program connected to the OPC-UA server and doing... something.
The basic plumbing works, but I can't figure out where to start with OPC-UA and Milo. I have not been able to find introductory material to help me make sense of it all.
Is there documentation about the architecture of OPC-UA and how Milo implements that? Is there a better way to go about it than looking at the examples to figure out how things should be done?
Documentation for Milo is one of the next major things to tackle now that we've got a release published to Maven central. Even once that documentation exists, though, it will assume some knowledge of OPC UA.
There's a somewhat expensive green book called "OPC Unified Architecture" available on Amazon. I haven't read it myself, but I've heard other people mentioned they have. It's probably a lot easier and cheaper than trying to learn OPC UA from the specifications.
edit: Seems there's a couple other cheaper alternatives now too.
The Milo project has a gitter channel and a mailing list you can ask questions on as well.
Please explain what is the Difference Between OPC UA and OPC DA ?
In which condition which one should be used, and if any example can be provided for both OPC UA and OPC DA, it would be helpful
OPC-UA is the successor to OPC-DA. It has many benefits, one of the most prominent being that it is platform agnostic. There are SDKs available in a multitude of languages and OPC-UA can be implemented on anything from a tiny embedded to device running Linux, to a desktop running Windows, or a server running the OS of your choice.
For any new development, given the choice, OPC-UA should be used. The only reason to use OPC-DA at this point in time is if you're connecting to a legacy product that only supports OPC-DA and cannot be replaced or upgraded.
OPC UA is not only for OPC-DA, but for all OPC Classic (DA, AE, HDA, etc).
OPC Classic uses DCOM communication for Client-Server connection.
DCOM is for Windows OS. And, DCOM and RPC ports are a headache for engineers.
So, OPC UA is new technology which does not rely on DCOM communication and is platform (OS) independent. OPC UA supports Linux as well.
A lot of OPC servers in the market are not ready for OPC UA. But I believe they are on the way.
OPC client application developers need to focus that your OPC client app supports for which OPCs? For which purpose, e.g. AE:alarm and event collection or DA:data access)
Every OPC knowledge are avaliable at https://opcfoundation.org/. You can download source codes and some component Dlls but you must be a member.
OPC UA is the Unified Architecture of OPC.
Specification doesn't says anything about platform, OS etc.
OPC DA, is older version of OPC specification. Where there was data modelling (not to a greater extent like OPC UA has). Only information which was transferred between server and client is VQT (Value Quality and Time).
Where as OPC UA has data and information Modelling, Along with VQT, there are many attributes/Properties which can be shared between server and client about a variable (in simple example, Say describing what this variable doing. Which is the conversion formula used, whether the variable is accessible by user or not! to name few).
OPC DA is completely OS Dependent. Where is OPC UA is independent of Operating system. Some using some of the OPC UA SDKs the Servers can be created on a platform where OS is not present
OPC DA communication medium is COM/DCOM. Where is OPC UA is about TCP/IP and/or HTTPS. it depends on SDK to support either both or any one of them.
these are some of the key differences.
Which one to use when:
My suggestion is, go with OPC UA irrespective of whether you have OPC DA servers or not. Because, there are some products in which with the Old OPC DA products data can still be collected with the new OPC UA based products.
OPC UA servers can be OS independent (it purely depends on type of SDK). In future if you want to migrate to any operating system then it will not be a ahead ache.
I hope this helped you to understand the difference.
OPC-UA being a successor for OPC-DA provides the improved specification for the connectivity protocol implementation on different platforms and languages. The performance of the protocol is dependent on the implementation and there are SDK's that are certified by the OPC foundation for popular programming languages like JAVA, C#...The goal of the OPC UA is Platform independence, improve the ability to expose complex data and complex system representation.
Some legacy devices and software's may not support OPC-UA but it would be a good decision to adopt to OPC-UA since wrapper are available to convert OPC-DA to UA with minor cost in performance.
For OPC-DA you can only use windows OS as a OPC Server. because DCOM protocol only supported by windows. On the other hand OPC-UA is cross platform even you can develop it a embedded devices.
In old DCS and industrial devices , you can not find any OPC-UA server so you have to use OPC-DA.
Because of DCOM, configuration of OPC-DA is too difficult and it can cause many strange problems