Hello,

I am working with OPC communications but I do not understand yet what is actually OPC and how it works. I thought it is a protocol, but looking for info in internet I saw that it is actually a kind of gateway which converts any protocol to windows data in order to make all the HMI understand the data wherever the info comes.

I have the following questions:

- How do OPC works?

- Where are physically the client and the server? In the PLC and in the HMI computer? Or both in the same computer?

- If the client is in the computer and the server in the PLC, if I want to start communications, should they communicate through Modbus for example? so what is OPC for?

- What is the native protocol?

- What is API?

I know there is kind of communication between client and server, but I don't know how do they communicate if OPC is not a protocol. they use others? A further explanation would be useful for me, because I'm used to see Modbus master\slave protocols and this is new for me.

Thank you very much in advance.

Regards,
Daniel

 

OPC is only open for those who pay for.

There is an old OPC that is based on:
http://en.wikipedia.org/wiki/Distributed_Component_Object_Model
And thus only work with MS Windows stuff.

And there is a new OPC based on web services and XML, Soap.
http://en.wikipedia.org/wiki/OPC_Unified_Architecture
Which can also work on non MS Windows systems.

In most cases with the old OPC both client and server run on the same Windows PC. The OPC server then communicates with the PLC/fieldbus with the protocol of the PLC/fieldbus. The HMI software in most cases is a fat Windows client that includes the OPC client and runs on the same Windows PC.

This is a Windows only solution.

 

In OPC, the OPC server has the low-level driver that talks the comm protocol of the field device.

The OPC server is not 'on' the PLC, the OPC server resides on a PC somewhere and the OPC server talks the PLC's protocol in order to fetch or send data to the PLC, which it then transfers to the OPC client.

The common field communications protocols are purchased by license from each OPC server's vendor. Some OPC servers have custom programming capability for a roll-your-own driver for field devices that don't use a widely available commercial protocol.

In the old pre-OPC days, each HMI or SCADA software vendor had to write their own 'driver' to talk to a field device. The burden of version updates, upgrades, etc distracted them from their core expertise. Now in the OPC era, the HMI/SCADA software is an OPC client which is relieved of the task of talking directly to the field device because the OPC server handles that task. The OPC server vendors take care of driver protocol updates and upgrades.

Most HMI-SCADA packages are OPC client, by option or natively.

OPC servers can reside on a Windows PC other than one with the OPC client; the client and server(s) will communicate over a properly configured Ethernet network.

The widely used old OPC was OPC-DA (data acquisition), A&E (alarms and events) and HDA (Historical data access). I suspect it was doomed to obsolescence because its acronyms made sense.

The new OPC is OPC-UA (unified architecture). Is that scary sounding, or what? What I want to know is will OPC-UA put a new K-cup in my Keurig coffee maker for me?

 

Hello,

First of all, thank you so much for the answers, they are helpful for my understanding.

I still have some questions about OPC, as following:

- The OPC server handles the communication with field devices. Then, it communicates with OPC client. How is the communication between OPC Client and OPC Server? Is it done by Modbus via ethernet or how? What is the difference of having the OPC server in the same computer than the client and having it in a different computer connected to another computer with the opc client? how do they communicate in both cases?

- I have been using Kepware as OPC simulator. I guess what it does is to simulate an OPC server in order to interchange signals with the OPC client. The addresses of modbus signals are, I guess, the signals that should come from field, but anyways are not used cause I simulate them and send it with OPC tags. What I do not understand is how it works because I have it in my laptopt and then I send it through ethernet to another computer with the OPC client. How do they communicate if OPC is not a protocol? If i use the kepware in the same computer than the opc client, it works also, but how do they communicate?

Thank you very much for your help

 

<i>"The OPC server is not 'on' the PLC, the OPC server resides on a PC somewhere and the OPC server talks the PLC's protocol in order to fetch or send data to the PLC, which it then transfers to the OPC client."</i>

Loytec has a PLC called a L-INX Automation Server. It is a PLC and has an OPC Server. Even the Loytec touch panel has an OPC Server.

 

I can understand that if I have the OPC server in a PC, then it will get the field data and convert it into OPC to give it to the OPC client which is in the same PC. But... how does the server gives the opc links to the opc client? Is the opc communications between client and server through some windows configuration??

Then... if I have the OPC server in a separate device such a PLC, like L-INX PLC you mentioned... how is it going to give the signals to the OPC client if it is in another device? The only way to send them is trhough a field protocol such us modbus tcp/ip for example.. I do not understand this part, how an OPC server which is in another device can communicate with an OPC client in a different device, they should always be in the same device.

Thank you so much for your time and patience.

Regards,
Daniel

 

Classic OPC, That is to say OPC DA, AE, and HDA, is based upon the Microsoft COM (Component Object Model) for local connections and DCOM (Distributed COM) for remote connections.

The OPC Specifications define the Object definitions for OPC, the methods, properties, and events that are used in OPC. These are all common between the client and server OPC applications.

 

Tossing my 2 cents in

Customers often ask YOU (aka: small device maker) to put OPC in your device. Unless you want to run embedded-Windows or Linux, this is both tough and pointless. It could add $500 or more to the cost of a simple field device!

If you have Modbus/TCP in your device, then EVERY OPC vendor in the known universe selling OPC software will have a Modbus/TCP-via-OPC driver. So if you have Modbus/TCP in the device, your device is indirectly OPC compatible!

Another thought, OPC messages are HUGE. For example, Modbus/TCP can move 16 digital status bits in 12 bytes of protocol! (ignoring TCP overhead). Moving 16 'objects' via OPC could be tens of thousands of bytes of XML or DCOM. Not a problem on a PC-to-PC corporate high-speed Ethernet network, but you probably don't want that bulk moving via cellular or wide-area-network to your field devices.

 

That is to say that OPC as an automation protocol is a silly idea that only came to be because it was the Microsoft way to do things.

A rational way to do those things is with something that will fit in a field device stack. And something that makes sense for automation in terms of functionality and purpose. With the power and resources you can have in an embedded device today there is really no reason to have a PC locked in as an intermediary.

In your example ModbusTCP _is_ an automation class solution because there is now the silicon to support it, it's based on _automation_ industry and Open standards, and it's not impractical to support it.

It may be that we could use something more that carries metadata, but it wouldn't be rocket science to to come up with something that fits the automation arena and could run very comfortably on affordable embedded platforms. Something without encumberment, something under the GPL or a BSD license perhaps.

Some fieldbus protocols have taken a shot at this but missed the general case and with their questionable quasi-open, members only BS, don't _ever_ stand to gain widespread trust or acceptance. Even when they have that shining example (Modbus/TCP) of how it's done. I didn't think it could happen with all the proprietary excess, but Modicon etal. achieved miraculous acceptance by simply putting the good of the industry first and letting it happen. We need an analog to achieve the connectivity that should come with the internet of things and let data sources connect as the market will expect them to.

Perhaps among all those who have previously attacked the problem in secret, someone has something that could be seen by anyone as a good thing and would become a standard if shown the light of day and made Open.

Regards
cww

 

Hi Curt. (my email's still as before)

There has been some work on standardizing Modbus layouts & XML forms to describe the layouts - take a look at http://www.sunspec.org/. It is a trade group defining Modbus mappings for solar/renewable devices, which I've been working with them for a few years now. They have a means to 'browse' a Modbus device by using a block organization similar to how DHCP packs options. So I could see a new Modbus device which combines an inverter, meter, and simple weather station & not even need to read a manual to understand the data.

They also have an XML schema to allow a host (or data logger) to auto-import a Modbus layout including scaling and units of measure. The goal is to allow a remote field logger (likely a small embedded Linux sized device) to be able to handle a brand new device (logging via Modbus and uploading via HTTP/REST) by being handed the XML defs for the new device.

It would be cool/helpful is OPC & SCADA servers could learn to import such XML, and vendors begin to provide them as part of their documentation.

 

The new OPC-UA specs come with profiles (incl. a "micro" and "nano" profiles) that can fit the embedded devices.

E.g. Flash of 240kB, and RAM of 35kB for the OPC server in a microcontroller.

Zbynek Zahradnik, OPC Labs, www.opclabs.com

 

Learn about OPC and other software technologies used in automation from the "Software for Automation: Architecture, Integration, and Security" book published by ISA:
https://www.isa.org/store/products/product-detail/?productId=116170

Cheers,
Jonas