OPC Server robustness

  • Thread starter (TECO) David Bergeron
  • Start date
T

Thread Starter

(TECO) David Bergeron

I would like the opinions of those on the list regarding the following OPC server issue. As far as I understand it, if an OPC client is connected to an OPC server and that client crashes or isn't shut down properly, the connection remains open in the OPC server. You can imagine tens of clients connected to one or more OPC servers crashing over time. Wouldn't these open connections load down the OPC server and eventually overflow the buffer? The OPC server stability becomes dependent on the clients which may or may not be stable.

In addition, OPC servers cannot be properly shut down if clients are connected. Just one crashed client and the OPC server doesn't let you shut it down properly. Or maybe the OPC server needs to be shut down and there is a client somewhere on the network that is still connected.

I think there are some serious robustness & fault tolerance issues that need to be addressed with OPC before I feel comfortable using it for industrial automation. One problem I see is that OPC is based on a Micrsoft spec (i.e., COM & DCOM) and is therefore dependent on Microsoft and their specialty is not in industrial automation. That's what scares me. Was the COM & DCOM spec written for use in industrial automation or was it created for use in office and home applications?

I welcome your comments.


David Bergeron, P.E.
TECO
504-833-6381
www.thompson-equipment.com
 
D

Darryl L. Palmer

DCOM does handle dead clients and servers. A client is supposed to transmit an "alive" message, if one is not recieved by the server-side OR, OXID Resolver, in 6 minutes then it is supposed to do the cleanup. COM/DCOM is not a proprietary protocol, anyone can get the info on it along with COMSOURCE, a UNIX based implementation of it, from the Open Group http://www.opengroup.org/comsource/.

Microsoft is not too interested in making COM/DCOM realtime, if your are interested in that look at DeviceCOM, but I think that is proprietary.

Darryl Palmer
Cleveland State University
 
R
> I think there are some serious robustness & fault tolerance issues
> that need to be addressed with OPC before I feel comfortable using
> it for industrial automation. One problem I see is that OPC is
> based on a Micrsoft spec (i.e., COM & DCOM) and is therefore
> dependent on Microsoft and their specialty is not in industrial
> automation. That's what scares me. Was the COM & DCOM
> spec written for use in industrial automation or was it created for
> use in office and home applications?

I have not understood this either. Certinaly there is an 'independent' OPC org, and I gather DCOM is supposed to be open. But then they say that of Word. I have only ever seen this stuff on MS platforms, but then I have only seen PROFIBUS on MS, and that is not MS code. If this OPC lark really is locked into MS code then it does seem a risky investment, especially with MS being so far away from 64-bit systems, and apparently they now
only support x86 platforms, just at a time when a whole host of interesting new options come to light.

I have just come out of the telecomms sector, and everybody is head over heels for CORBA there. It is allready in very widespread use, which speaks
volumes, phone companies pride themselves on thier low downtimes yet their systems cope with enourmous volumes of (soft) real time data. AFAIK CORBA is an open standard, and you do not seem to have to pay and arm and a leg to get at it (unlike some OPEN protocols;-) ). Certinaly it seems to be compatible on just about every type of platform, and myWindows based C++ Builder package includes support as standard.

So I wondered if anybody is trying to create a real open standard, based on the proven CORBA model?
 
M

Mark Hensley

Hi David

Your concern would be valid except that the COM manager will eventually clean up for these failed OPC clients. It can take a while but eventually you will see the client connections and the items removed from the OPC server. You are correct that during the time the OPC server still has these connections it may continue to acquire data for the active items.

As for the as the amount of time goes, I think 12 minutes rings a bell but I am not sure. Also you will see that not all connections are removed at the same time. In the end however things will clean up.

As far as the OPC server not allowing you to shutdown that is proper behavior. Now some servers will allow you to go ahead anyway. In these cases the OPC server has the option of informing the OPC client about the shutdown. Your example is exactly why the server tells you about the connections, you wouldn't want to cut someone off from their data source in another building or state for that matter without a little warning.

The issue here is not really one of COM and OPC but perhaps stable OPC client software. The quality or worthiness of a software component to an industrial task is not solely the responsibility of the underlying operating system. If the vendor tries hard enough you can write good software on top of a Microsoft system. It is the job and goal of the OPC Foundation(www.OPCfoundation.org) to provide that extra step of insuring the that needs of the industrial process and control markets are covered while using these new technologies from Microsoft.

Hope this helps.

Mark Hensley
President
KEPware Inc.
81 Bridge St.
Yarmouth Maine 04096
PH:207-846-5881
FAX:207-846-5947
WWW: http://www.OPCSource.com
 
G
David,

OPC is built on COM/DCOM. If a client crashes, then DCOM will recognize this fact and clean up the connections the client held on its behalf. In
the worst case, this may take up to 6 minutes. However, the resources that were allocated for that client in the server will be released.

Version 2.0 of the OPC Data Access specification provides a connection point mechanism whereby the server can request that any connected clients
disconnect. Thus, if there is a need to shut down the server, then there is a way of executing a graceful shutdown.

As for COM/DCOM. The specification was developed for deploying scalable component based architectures. It is now a robust, mature technology that is absolutely suitable for deployment on the factory floor. I wouldn't
recommend using it for high speed closed loop control. However, it is very applicable to typical plant floor integration solutions.

Best regards,
Gord Ellis

==============================================
Gord Ellis, P. Eng.
Northern Dynamic Inc.
J103-155 Frobisher Drive
Waterloo, Ontario
Canada N2V 2E1
Tel/Fax: (519) 725-2071/2072
web: www.nordyn.com
 
W

Warren Postma

> I would like the opinions of those on the list regarding the following
> OPC server issue. As far as I understand it, if an OPC client is
> connected to an OPC server and that client crashes or isn't shut

This appears to be a failure in general of all out of process COM servers. There is no standard way to handle detecting and removing crashed remote clients, or even clients on the same machine as the OPC server.

> In addition, OPC servers cannot be properly shut down if clients are
> connected. Just one crashed client and the OPC server doesn't let
> you shut it down properly. Or maybe the OPC server needs to be
> shut down and there is a client somewhere on the network that is
> still connected.

This should be possible to add to OPC if the OPC guys are still working on their next spec. I have written several COM servers and have added this feature. The server can destroy all interfaces and quit, but this will cause a crash in all the clients, unless the clients were programmed to listen for disconnect events. I don't think this feature exists in OPC.

> I think there are some serious robustness & fault tolerance issues
> that need to be addressed with OPC before I feel comfortable using
> it for industrial automation. One problem I see is that OPC is
> based on a Micrsoft spec (i.e., COM & DCOM) and is therefore
> dependent on Microsoft and their specialty is not in industrial
> automation. That's what scares me. Was the COM & DCOM
> spec written for use in industrial automation or was it created for
> use in office and home applications?

Hmm. Has there been any attempt to build an OPC-like portable data-transfer system based on SOAP, XML-RPC, TCP-IP sockets + some open data format or
open protocol?


Warren
 
M

Michael Johnson

1. As far as I understand it, if an OPC client is connected to an OPC server and that client crashes or isn't shut down properly, the connection remains open in the OPC server.

I think this is true to a point. We have used Rockwell's RSLinx as an OPC server talking to WonderWare's OPCLink as a Client/server. RSLinx and OPClink are sitting on a NT server while WonderWare Factory Suite is running on 15 NT
workstations. I have found that if a work station crashes ( for some reason ) OPC link will have that channel still open. But if OPClink crashes RSLinx does not leave that channel open. I think Rockwell has resolved that issue.

2. You can imagine tens of clients connected to one or more OPC servers crashing over time. Wouldn't these open connections load down the OPC server and eventually overflow the buffer?

No, I do not think this is a problem. It seems like once a connection is made and all the requested data (tags) are found it maintains a fixed amount of buffer. This overload issue is not an issue.

3. In addition, OPC servers cannot be properly shut down if clients are connected. Just one crashed client and the OPC server doesn't let
you shut it down properly. Or maybe the OPC server needs to be shut down and there is a client somewhere on the network that is still connected.

RSLinx will let you properly shut them down even thou clients are still active.

4. One problem I see is that OPC is based on a Microsoft spec (i.e., COM & DCOM) and is therefore dependent on Microsoft and their specialty is not in industrial automation. That's what scares me. Was the COM & DCOM spec written for use in industrial automation or was it created for use in office and home applications?

You are right OPC is based on Microsoft technology, however the OPC foundation is made of industrial automation leaders ( for a complete list see http://www.opcfoundation.org/OPC-MEM/memb.asp ). You got Fisher-Rosemount, GE Fanuc, Honeywell, Intellution, OMRON, Rockwell, Schneider, Siemens, Foxboro, Yokogawa, etc. These are people who understand the needs of industrial automation. All these people are doing is applying an networking data accessing technology used in Windows to their products in order to give the end user a better means of sending and
receiving data at a high speed in a reliable manner ( something that Microsoft has mastered ) in an industrial environment ( who is better to
do this than the people on the OPC Foundation member list ).
 
M

Marcel Richters

> OPC is built on COM/DCOM. If a client crashes, then DCOM will recognize
> this fact and clean up the connections the client held on its behalf. In
> the worst case, this may take up to 6 minutes. However, the resources
that were allocated for that client in the server will be released.
>

But what will happen on the client side when the server goes offline and comes up online after 1 hr ???? We have a problem with that.
We are using the Aspen IP21 database which is connected to a Siemens WinCC station. The connection is made by CIMIO for OPC. The CIMIO interface acts as an OPC-client while WinCC has its 'build in' OPC server running. The problem occurs when WinCC is taken out of 'runtime' (to make a change to a graphic for example). The OPC-link is broken will not be restored (after WinCC is back in ' runtime') until the Cimio server is rebooted. Any suggestions of what the problem is ?

Thanks in advance,
Marcel Richters
 
M

Mattias Wallinius

There are resolutions to all of it.

1. There is a timeout between the Server and client for 6 minutes afetr which the COM connection is released. The client also normally registers a callback in the server and if the cleint crashes the server will get error messages when calling the callback and therby will know that the client is no longer alive.

2. Depend on implementation but normally this will only cause small memory leak and would not hit performance.

3. COM(DCOM) is the best implementation of component technology so far for industrial apllications. The technology is also developed with specs that could apply to any industrial application. The alternatives are even worse.

/Mattias Wallinius, Sr System Engineer
Tetra Pak Converting Technologies AB
Ruben Rausings gata
S-221 86 Lund, Sweden
email: [email protected]
phone:+4646361248
fax: +4646362504
 
G
Marcel,

This is not a problem with OPC per se. It is more an issue with the client side implementation of CIMIO. The OPC standard states that well designed OPC clients should handle a situation where the connection to the server is "broken" (as should any distributed application). In this case, the client could periodically attempt to re-establish the connection. Based on your
statements below, one could infer that CIMIO does not behave in this manner, thus requiring an application restart to "get connected" again.

Gord...

==============================================
Gord Ellis, P. Eng.
Northern Dynamic Inc.
J103-155 Frobisher Drive
Waterloo, Ontario
Canada N2V 2E1
Tel/Fax: (519) 725-2071/2072
web: www.nordyn.com
 
There's alot of reasons why this could happen.

A) The client has no retry logic (e.g. it'll only work if the server is up when it starts)

B) The client never detects the DCOM connection went away. This is a common problem for clients that are configured to update Unsolicited (e.g.
through Server Events.) Even if DCOM cleans up the connection no event gets fired on the client, since the client is waiting for events it'll never
figure out that the event object is gone. A typical solution is to have at least one point that is polled (e.g. a heartbeat), that way when DCOM cleans up the connection when the client tries to exercise the servers handle it will get an error.

Does CIMIo mark the points unavailable, generate an alarm, log a message or give any indication that the connection is gone?

C) Ideally if the server and client are OPCDA 2.0 compatible, the server would fire the disconnect event to the client and the client would
disconnect. This is an "optional" interface so it need not be implemented on either end. Even if it is implemented it doesn't help you with the
network disconnects, etc.


Pete
 
I
Marcel,

It sounds like the client has not detected that the server is down. The OPC DA 2.0 spec. recommends that well behaved clients periodically check that the server is alive. There is a function which the client can call on
the server to accomplish this.

The checking of the server status is important where the client uses the OPC data call-back notification mechanism, because the server is calling into the client. OTHOH, if the client is polling the server periodically then the client will know when the server is down, because the next polling operation will fail.

HTH,

Ian

Ian Pepper
Chief Technology Officer
Automsoft International Ltd
27 Upper Fitzwilliam St
Dublin 2
IRELAND

Ph: +353-1-632 8610
Fax: +353-1-632 8669
 
> Hmm. Has there been any attempt to build an OPC-like portable data-transfer
> system based on SOAP, XML-RPC, TCP-IP sockets + some open data format or open protocol?

My understanding is that Microsoft is looking at abandoning the current implementation of DCOM and is going to use SOAP as the transport. DCOM is
inherently dangerous since a poorly writtent client or server can crash each other. Intrisync (sp?) makes a replacement for DCOM that provide
reliability in a network architecture. The demonstrations I've seen of it are impressive. Conversely, "yanking the cable" on Microsoft's DCOM is usually disasterous for the client or server. OPC Client vendors spend a huge amount of time creating threads to watch other threads to watch other threads to try to detect network problems.

There's also some info on the OPC Foundation's website.
http://www.opcfoundation.org/ASKOPC/ASKOPC-A/ASKOPC-44.asp
 
D

David Bergeron

>Conversely, "yanking the cable" on Microsoft's DCOM is usually disasterous for the client or server. <

True, I've seen DCOM clients freeze for up to six minutes searching for a node that is no longer online.


David Bergeron, P.E.
TECO
504-833-6381
www.thompson-equipment.com
 
I
Anthony,

Yes it's straightforward but you do have to rewrite a lot of code (i.e. replace the DDE client code with OPC client code) to do so. If you are using a SCADA package which doesn't support OPC (such as Wonderware) then there are some products in the marketplace which 'convert' a DDE based server into an OPC server (notably from Merz and Matrikon).

Ian
 
S

Shiepe,Jeff,CLEVELAND,Engineering

Hi Anthony,

I did this conversion using a SLC5/04, RSLinx and Wonderware. The first thing you have to do is download OPCLink from Wonderware's site. There are specifics in setting up OPCLink to communicate with RSLinx, and hopefully you are a Comprehensive Support subscriber to Wonderware because all the gooey details are spelled out for you in Tech Note 159. Probably the most work you will have to do is to go into your tag database in your WW app and edit all the tagnames to include a prefix; i=integer, d=discrete, r=real,
etc. In other words, if your tag address is N7:0, it will need to be changed to iN7:0. The Tech note is really comprehensive so I hope you can get your hands on it.

Hope I've helped.

Jeff Shiepe
Nestle USA, LJ Minor
 
Top