|
|
Rank: Newbie
Groups: Member
Joined: 10/21/2008
Posts: 2
Location: india
|
sometimes there is the interface which does not respond - and the tag values are flat (no change). only solution is to restart the interface. how does one handle such a situation - stale tags.
how to generate an alarm on this - heartbeat etc.
any proven solutions ?
|
|
|
|
|
|
|
|
Rank: Administration
Groups: Administration
Joined: 6/20/2008
Posts: 458
Location: Cheshire, United Kingdom.
|
Hi abraham,
Welcome.
I have experienced the same issues with OPC using DCOM, to date cannot explain why OPC does not resync from particular OPC clients once communication is broken despite the communication channel being re-established. It does happen but not often and would like the time to find out why...unless anyone else has uncovered the underlying problem?
Now I am an advocate of writing purpose built interfaces but there are currently alarming products out there to notify you based on conditions of your data.
RtAlerts is one from OSISoft.
TopView is another from Exele.
(There are others out there on the market...)
And of course you could right a simple interface yourself using PI-ODBC, PI-OLEDB, PI-SDK etc depends on the scale of your monitoring requirements.
Here is some PI-SDK code that might get you going: PI-SDK Check Pointsource
Personally, I have written a system to monitor a PI system for data quality that is capable to send out email, SMS & pager messages but I do enjoy creating new interfaces!
Depends how automated you want your system checks to be because you could just use the Stale & Bad tags plug in for PI-SMT.
 OSIsoft PI System SpecialistsPI consultancy on PI Systems, PISDK, AFSDK, OLEDB etc and PI custom developments. Well pretty much anything to do with PI!
|
|
|
Rank: Member
Groups: Member
Joined: 7/23/2008
Posts: 25
Location: Milan, Italy
|
Hi Abraham The OSIsoft standard solution for this would be to use the ISU (interface status utility). Setup is minimal and if I remember correctly, the tool is free. You can optionally set the value of the tags to something like "interface down".... or you could just use a watchdog tag and alarm it when it goes flat. Make sense? Doug www.definitconsulting.com
|
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/23/2008
Posts: 31
Location: Cheshire, UK
|
Hi Abraham,
There are three types of OPC interfaces in general use out there; OPC DA, OPC HDA and OPC AE. Typically I have found that most reasons for HDA and OPC AE generating stale tags is due to the issues with the data source systems e.g. people kill services which impact the OPC Servers and data stops being refreshed. Because the OPC Server is still up the OPC client is unaware of failure to refresh data, this being worst with OPC AE because whereas you can anticipate a change in a process variable within a given timscale you can't necessarily anticipate when an alarm condition will occur.
The approach we have taken is to use tools such as performance monitor to track what is happening on data source servers and alert us via email if abnormal conditions are seen. In addition to this, for interfaces where we are receiving changing data such as we would typically see with OPC HDA and OPC DA, we identify a data point that should be constantly changing and use performance equations to determine whether the value has changed between readings or if there has been no change in value for a specified period in time. The outputs of these equations are then used to trigger a watchdog which in turn triggers an email alert.
Of course you need to consider compression settings on the source data when working with these sort of solutions.
As for OPC DA issues, the ones that are most common are those resulting from incorrect settings either in the interface or in the tag configuration. I had one customer complaining that an interface wasn't working the other week even though it clearly showed itself as running - the issue turned out to be that the customer had created tags based upon ones set up for a different interface and hadn't reset the source location for the new tags or modified compression settings in line with the new interface.
In my experience OPC is generally robust, however as with all software the client is developed to respond to expected conditions from the server. Very infrequently the server may experience an issue that it can't deal with and doesn't respond in a way that the client is expecting. It is in such circumstances that the client can fail to re-sync - it imay not be aware it needs to. The source of the problem appears to be in the way the services are interacting. I saw this last week when an engineer took down an RSLinx server in a non standard way and pointed it at a different source; the interface responded correctly but couldn't return data until it had been restarted.
Hopefully these issues will disappear in the near future as OPC UA makes its debut.
Regards,
Burnikell1
|
|
|
Rank: Member
Groups: Member
Joined: 1/14/2010
Posts: 20
Location: UK
|
hi Adraham,
when you create the interface, do you create the IO-Rate tags to go with it?
if you do, you can create a calc tag which looks at the IO-Rate time stamp and the value it produces.
this is an example exdesc i use for this:
if (daysec('*')-(daysec(prevevent('IORATE-Tag', '*'))))>700 then "Failed" else if (day(prevevent('IORATE-Tag', '*')))=(day('*')) then "Healthy" else "Failed"
this basically looks at the interface tag and if the timestamp is older then 10 mins, then this will return a "Failed" state.
it works quite well
cheers
Pho
|
|
|
|
Guest
|
