currently we are having a large project that will have many systems to be interfaced together. OPC being proposed for this purpose. I would like to clarify the following:

1 - if anybody have experience on using OPC and what are the adv & disadv.
2 - what are the things to be focused on when selecting OPC as an interface media.
3 - what are the maintenance considerations for OPC.
4 - any detailed specs requirements that have to be requested for such application. for best performance.

appriciate yr help

regards

 

There is nothing in my experience that matches OPC's breadth of support among different automation suppliers.

Having said that, there are some things you need to know.

First, it is based on Microsoft's COM technology which is being abandoned with the .NET products. Using OPC with .NET is not for the casual programmer.

Since it is based on COM, you are saddled with DCOM for network applications. DCOM returns three error codes for hundreds of problems. This is not an issue for a qualified programmer setting up a fixed installation, but it can be maddening for anyone trying to develop applications for wider use.

Finally, I hope you will have better experience with tech support for vendor's OPC products than I have.

I don't mean to discourage you. It is, by default, the way to go if you need to marry different automation products, but be realistic. Allow for plenty of development time and make sure the programmers you use document everything they learn fully.

Good luck & have fun,

Michal Casterline

 

I have used OPC on three grass root projects and it has gone well.

Advantage is tag.parameter (PI101.pv) and a industry standard, disadvantage is can not do group call typicaly as can with Modbus. Not everyone implements the standard get references.

Make sure that all third party control systems have OPC interface before going down the road. If the interface has not been out for a couple of years relize the risk!!!

Maintenance is easier that Modbus as it is tag.parameter do not have to keep offline Modbus maps up to date.

Industry standard.

If you have any questions please email me.

THX,

Randy

 

Hi,

some remarks below.

On June 24, 2003, Michal Casterline wrote:
> First, it is based on Microsoft's COM technology which is being abandoned
> with the .NET products. Using OPC with .NET is not for the casual
> programmer. <

I am not with Microsoft, I am not paid by them in any way, but the above statement is not right!

Microsoft has stopped the further development of DCOM as a technology. It did not stop to support it as runtime, i.e. OPC products based on the DCOM OPC specs can be used also in the future. Ok, I hear you telling maybe Microsoft will stop supporting DCOM as runtime in the future... Yes, this is a possibility, but there are much more products using DCOM beside OPC...

Using OPC with .NET is not for the casual programmer.

This statement is right and has been seen also by OPC Foundation.

Therefore it has started an effort to develop a .NET wrapper for OPC DA, i.e. the existing OPC DA object model is exposed in the .NET world.

The code will be released this year.

OPC XML-DA would be another alternative for .NET. By using the WSDL and Web Services Tool implementing of a OPC client is easy. To support mixed OPC XML-DA and OPC DCOM DA application XML DA/DCOM/DA wrappers will be available.

Regards,

Frank Iwanitz

 

OPC will give you lots of connectivity. You will have plenty of hardware and software to chose from to do virtually any task.

Use hardware such as controllers with software tools that automatically generates the OPC connections. I mean e.g. when you build your control strategy in the engineering tool (e.g. using function block diagram language) the tool should automatically update the OPC server with all the tags (for the blocks) you created and all the parameters. This will give you a "single integrated database", i.e. you only configure a tag once, in all other applications you just point and click. This is in contrast to hardware that is first configured in one tool, but then uses separate "generic OPC servers" e.g. PLC with Modbus communication and a generic Modbus OPC server, requires you to manually configure that OPC server with communication settings such as port, parity, speed, and timeout etc. Then for every parameter you need to configure memory register and scaling, etc. Sure, generic OPC is a whole lot better than traditional device drivers, but the ideal is configuration tools which also setups the OPC automatically. This is how we (Smar) do it in SYSTEM302.

Use OPC for visualization etc. not for closed loop control

OPC provides great connectivity, but not interoperability. Every device still has a different way of saying the loop is in manual or that the device is healthy.

A system supporting OPC may not be able to do what you want. OPC can be implemented in many different ways. Many DCS have OPC but still have proprietary operator interface software. E.g. you cannot take a DCS and opt from some HMI software of your choice instead. Typically these systems only permit you to use OPC with software they or a partner don't make themselves. The big deal with OPC is that YOU can select what software you want.

Make sure all clients and servers you use are conformance tested

OPC (DCOM based version) is not firewall friendly. Outside the control domain you may wish to use HTML+HTTP instead to disseminate data throughout the enterprise. Use a web application that takes OPC data and present it as a web page. There are some nifty applications that can transport OPC across the Internet and turn it back into OPC in the other end.

Use not only OPC-DA, but also OPC-HDA and OPC-A&E as well.

For critical applications use redundant OPC servers on separate networks and make sure the client stations have a switchover mechanism.

If by any chance you are planning to use OPC with FOUNDATION Fieldbus, please take a look at chapter 7 of the book: "Fieldbuses for Process
Control: Engineering, Operation, and Maintenance" (buy online in hardcopy or
download immediately in softcopy) which is on this topic. It focuses on the semantics issues of OPC. If your email does not support this hyperlink feature correctly, please copy the URL and paste it into your Internet browser. Mind the line wrap, make sure to get the complete path all the way to the 3036: http://www.isa.org/Template.cfm?Section=Shop_ISA&Template=/Ecommerce/Product Display.cfm&ProductID=3036

Jonas