In the past couple of years, we've been doing most of our PLC programming work on Unity-Pro.

This is great for object oriented control algortihms & complex problem solving. We're still apprehensive to move on to OPC for the PLC-SCADA linkage and this is because most of our team has been raised on the common Modbus protocol typically over Ethernet/RS-485.

Now that we are using structured/derived variables in the PLC program, I feel that using elementary addressed variables in the SCADA application is a little dated! Now can you people who have experience with OPC or have migrated from I/O servers tell me whether it is worthwhile to make the switch?

With my limited understanding of it, OPC is perhaps just another I/O server, What is so big about OPC that it is progressing to being something of a profession in its own right?

OPC provides an abstraction layer between client applications and data sources (PLC, DCS, any system which contains data and provides some interface to obtain the data - also allows for control). This means that customers are no longer dependent on client applications providing proprietary connectivity for every data source you want to communicate with. It also means that you can have multiple client applications which can us the same communications path to the data sources, minimizing network traffic and simplifying the end user's configuration efforts.

Many client vendors have adopted OPC so that they can concentrate on adding additional value to the higher-end features of their products, knowing that other vendors will provide the necessary OPC connectivity to the underlying data sources.

There are many OPC servers available for multiple vendors for many protocols/interfaces. Most (if not all) are "try before you buy" - so you should be able to easily download and see if the product meets your needs before investing any money. I would encourage you to look for OPC products that have been tested for OPC compliance and that have attended OPC interoperability workshops to ensure the best experience with OPC technology.

Tony provides a good overview for you. I have no experience with the software that you are currently using, but keep in mind that generally speaking adding that layer of abstraction usually has a negative impact on data throughput. This may or may not affect your final decisions. If you are doing simple monitoring of slow changing signals such as temperatures, it may not matter. If your system needs to trap fast-changing electrical data, you might need to do something else.

I don't have experience with Unity Pro either. However, OPC is not only an open standard for which you have a lot of alternatives available and, hopefully, will not become obsolete soon, but also, from configuration point of view, very straightforward to use. You can use the actual symbol or alias address instead of the absolute or physical address, or you can still use the absolute address and assign a meaningful name to it in the client side. In any case, you are making the program easier to maintain and troubleshoot. Moreover, it is manufacturer independent, so you can use the same client application with PLC of different manufacturers with little or no changes. Only issue is the Windows firewall setup, but even this configuration is now done automatically during installation for several OPC suppliers. In conclusion, I would recommend you go for it.

As per my experience we have used OPC server where we had different interface in PLC and SCADA which are not compatible with each other,
When we say OPC to PLC communicatio it is definately the IOserver nothing else
but When we say OPC-SCADA it is not IOserver exactly i.e much advanced method of Software to software communication thad DDE or FastDDE or SuitLink.

From a user side, OPC is easier to deal with than a bunch of proprietary drivers. The first generation of OPC was tag based and had different standards for real-time data (OPC-DA), historical data (OPC-HDA), and alarms-events data (OPC-AE). The next generation OPC-UA (universal Access) seems to be just ramping up but merges all 3 earlier standards. It provides much more structure for the data so you can have a whole tree of data under a single tag similar to the way an object hierarchy works. It is also not based on DCOM anymore, which is great. The biggest problem I saw as a user of the first generation of OPC was getting data across domains. Often, we had to bypass security by either opening up all the DCOM security settings or we had to install a 3rd party tunneler product when moving data between one domain and another.

Thanks fellas... I'm enlightened.

Since the time I first asked this question... I've learnt more and to summarize in simple terms... There are 2 major advantages..

1. Applications in PLC can use unlocated variables which is a big help in scad app development. A single set of PLC symbols can be directly exported/dynamically linked to SCADA. A change in the variables set in PLC dynamically updates that in SCADA.

2. More importantly.. OPC is NEEDED for structured data. Directly addressed variables will prove very cumbersome and use up a lot of address space as well, if structured variables are "located" by assigning address. Whole new possibilities open up when you use object oriented methodology in PLC work. This is where opc shines. By means of browsing through the variable's object path, tags can be assigned reliably and far more intuitively. As complexity increases object-oriented methods become indispensable and so would OPC

I would like to highlight two advantages of adopting OPC standard based technology (i.e. so heavily embraced by the industry):
1) You are paving the way for your organisation to get rid of any specific vendor lock-in when it comes to data communication.
2) While your plant passes through next stages of maturity, you are opening doors for a list of possible future applications getting data from same OPC interface may be to conserve energy, compliance, plant throughput, asset utilization etc etc.

In reading through the comments, I hear repeatedly that OPC is an open standard. In my experience, OPC requires that a Microsoft-based system must be used somewhere, and that OPC does not work without it. In other words, it is not "open", or am I missing something? Openness requires platform and OS independence.

To follow up with what others have stated here already- OPC is a non vendor specific platform on which to exchange process data from disparate sources.
Also, and to address H. Peter Hombach- OPC servers will indeed operate on a Linux platform. Further, with the advent of OPC- UA I would expect more people to use Linux than do now. I feel that Linux, and the whole idea of being vendor neutral are what make OPC very attractive.
From a practical standpoint, I was recently involved in a machine retrofit in which the customer wanted to re-use the existing PLC. My components did not could not communicate to the PLC due to its age, but by using an OPC server, we were able to pass data from the machine to the customer's data warehouse by bypassing the PLC altogether.