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
Related
I have a question.
Does OPC UA solve the problem of communicating with for example with all type of PLCs ?
The problem is for us , PLCs are different, and we want to grab data from all !
Can OPC UA do anything in here to simplify the process ?
It doesn't solve it completely, but it comes close.
Some PLCs now have OPC UA built in, so you can communicate with those quite easily.
Other PLCs do not, but you can use an OPC UA server from either the vendor or a third party like Kepware to communicate with it.
But there will inevitably be some devices out there with no OPC UA option.
In summary though, if you're dealing with common PLCs, then yes OPC UA can help. To consume data all you need is an OPC UA client and you can make either direct connections or connections to another server and let the server worry about "native" communication with the PLC.
I'm trying to use a Wago 750-881 as a OPC UA Server, which I'm programming with Codesys v. 2.3.
My problem is how to make this happen? I have found a lot of info about OPC UA with Codesys v. 3.5, but not any information about Codesys v. 2.3.
Could please anyone help me?
Codesys v2.3 only has OPC-DA (Availability depends on PLC model and manufacturer. Even though OPC-UA may not always be available on a PLC with Codesys v3.5, check your vendor's documentation to check if is a optional).
There are Gateways (hardware and software) that allow "conversion" between OPC-DA and OPC-UA or between other protocols for OPC-UA, for example, if your PLC has Modbus-TCP/RTU. It is also possible to use another PLC, as Camile G. commented, but possibly the cost and development should be more complicated, depending on the case it may be worth migrating the entire system to a single PLC with Codesys v3.5 and OPC-UA.
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...
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.
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