Support Alarms and Conditions

We are undergoing a PI implementation, so I don't have high familiarity with it yet. I want to be able to collect event data in PI so we can have high(ish)-resolution timestamping of events without scanning a bunch of alarm tags at the high(ish) frequency.

How do you collect A&C data today? In an on-system historian (Yokogawa Exaquantum).

How is your A&C data stored in PI? I'm not sure yet since we have not implemented it. In the system historian, it is string data by default. We have to build "calculations" to convert it to boolean/enum data if we want that. We don't do that, but for fixed-number-of-states data it would be fine.

What sort of alarm data do you have? I.e. instantaneous alarms, acknowledgements, alarms with a start and stop time? All of the above, plus operator messages and system status events.

What is the preferable way to create Alarms and Conditions within PI (i.e. PI Tags, Event Frames, etc.) PI tags for sure. I'm not sure what "event frames" are yet, but if it's like some SOE systems I've seen, where an event triggers (fast) storage of some other data during a window around the event, that might be useful.

What is your best estimate for how many alarms/events should be created in a year? We are working to get it down, but a 7-8 figure amount is not out of the question.

What do you use to consume A&C data? How do you utilize A&C data afterwards? Not sure, as I'm not yet familiar with the PI tools. Tabular reporting with filtering is the obvious display vehicle, but being able to overlay event data onto trends would be useful as well.

How do you visualize A&C data? See above.

• How do you collect A&C data today? Through RDBMS (SQL DB), boolean alarm tags or bitted integer tags.

• How is your A&C data stored in PI? As pipe (|) separated string tags or boolean tags.

• What sort of alarm data do you have? I.e. instantaneous alarms, acknowledgements, alarms with a start and stop time? All of the above.

• What is the preferable way to create Alarms and Conditions within PI (i.e. PI Tags, Event Frames, etc.) Ideally a new type of PI point that can account for multiple attributes and values. If possible, also include possibility to have dynamic alarms (If 10 OPC UA tags are spanned for active alarms for example.)

• What is your best estimate for how many alarms/events should be created in a year? Millions.

• What do you use to consume A&C data? How do you utilize A&C data afterwards? RtReports, PI Vision displays (Custom symbols) and 3rd part OEE systems. Also other report systems use our alarms.

• How do you visualize A&C data? RtReports, PI Datalink, PI Vision displays and other 3rd party dashboards.

• How do you collect A&C data today? We side step side step A/E and A/C and bring in alarms via rdbms or by collecting plc/controller data then leveraging analytics to create event frames.

• How is your A&C data stored in PI? Alarm/Condition/Process data is preferentially stored as Event Frames.

• What sort of alarm data do you have? I.e. instantaneous alarms, acknowledgements, alarms with a start and stop time? All of the above.

• What is the preferable way to create Alarms and Conditions within PI (i.e. PI Tags, Event Frames, etc.) Event Frames.

• What is your best estimate for how many alarms/events should be created in a year? 100K.

• What do you use to consume A&C data? How do you utilize A&C data afterwards? MES, Discoverant, Simca Batch.

• How do you visualize A&C data? Vision, Datalink, external applications.

As a mining company, I want to centralize my alarms and events coming from multiple system to establish integrated remote operations center.

Currently we use ProcessVue by MAC Solutions for Alarm Management, visualisation and analysis. We are about to trial their OPC UA client with Siemens T3000 to collect A&C as the current means of integration is not supported. The missing component in a lot of these products is the ability to trend the process variable easily along with the alarm digital state. At this time we don't store alarms in PI, only certain boolean variables such as HH or LL

• How do you collect A&C data today?

  • We use middleware to convert A&C to OPC A&E

• How is your A&C data stored in PI?

  • In a PI tag as a string value combing different attributes into a single event

• What sort of alarm data do you have? I.e. instantaneous alarms, acknowledgements, alarms with a start and stop time?

  • All events from the source system like alarms system events diagnostic events and audit trail.

• What is the preferable way to create Alarms and Conditions within PI (i.e. PI Tags, Event Frames, etc.)

  • I do not know but currently we only have 1 issue and that is reporting events that have date time attributes. These are converted into text and are not easy to report in RtReports. It is not seen as time date anymore causing issues in converting this value to a time zone incl daylight saving time and sorting on this data.

• What is your best estimate for how many alarms/events should be created in a year?

  • I cannot answer this because it is depending on the scope of the system

• What do you use to consume A&C data? How do you utilize A&C data afterwards?

  • Data is used in RtReports and also for adhoc analysis with differnt tools.

• How do you visualize A&C data?

  • Today we only visualize using PIVISION but these are results of events and not the events.

An upgrade from a Read-Only to a Read-Write solution would also be useful.

At the moment alarms and conditions are dependent how a user/administrator configures it in the PI System, most of the time based on tags and analytics. The adapter should allow to connect to OPC UA A&C and create Eventframes. The User/Administrator should be able to choose A&C attributes as EF attributes, as well as the primary referenced Element. If feasible, it should also be possible to configure the A&C as an subeventframe (e.g. subeventframe of a batch-eventframe).

Speaking from process industry point of view (food, chemicals, pharma)

-Alarms and Conditions are important to identify discrete events in time, imo this is just as important as the continuous data streams from metrology sensors. OPC UA adapters should be carrying all the features that the OPC UA A&C server is featuring.

-A&C can represent: Process alarms, warnings, events. But also operator actions and audit trails. I often miss the capability to represent this kind of data in a out of the box / native way(without bespoke development) in PI Vision for example.
-Right now we often need to connect to Relational databases to read A&E data, but that is not that evident since a lot of vendors don't give visibility into their data model, or have concerns regarding security and performance degradation of a RDBMS connection.
-Another backside is that we end up (from this relational database from the source) with a lot of string text in the PI data archive, but there is no relation anymore between the events. eg there is no inherent relation anymore between an event representing an alarm that has come up and gone away/acknowledged, except for the text or some alarm ID in the string.

-Also representation of A&E data is often via a custom solution. It would be great to have some configurable A&E element in PI Vision to represent alarms. I think way back there was something like the PI Alarm Viewer.
PS
--> obviously PI Event Frames can be used to configure and represent A&C, but:
-we often just want a reflection of the A&E data from the source systems.
-often this is just not realistic to create EF triggers for each possible source alarm

In Pharma industry, my company utilizes Alarms and Conditions (for OPC UA) and Alarms and Events (for OPC DA) for audit trail logs for different equipment. We currently utilize multiple 3rd party vendors to collect these data. I am quite interested to utilize PI adapters, connectors or interfaces to move these data into PI, so that we have single data historian for all our data. I am quite interested to see what the PI Engineers/Developers come up with.

Hi! We are about to do a pilot with alarms and events to let them be stored into event frames! I heared it was a new product from OSI regarding this issue! We want to be involved in a Beta test. We use Siemens WinCC and ABB 800 xA DCS systems. //Magnus Holmbom, Vattenfall Vattenkraft AB

we also use WinCC and other scada systems. about what to collect/ not collect, there should be same filtering possible like in the scada system itself, so i want the possibility to filter on every attribute the scada system offers. Naming for event frame should also be possible. E.g. Asset_Alarmtext or Alarmtext_Messageclass,... The eventframes should be built without using PI Tags (Tagrefference). The behaviour of the end of eventframe (end eventframe when alarm is gone or with quitting) should be configurable in the connector

Important for Rail industry, so yes

Hi!   Currently we are using OPC AE and storing the events in Event Frames. When we move to use OPC UA we need to start to work with Alarms & Conditions instead!   Also i want a way to native create Event Frames within the Connector for OPC UA.   //Magnus

hi we are using WinCC and other System as SCADA. Today we import the Alarm Data to an Pi Tag with the format String. The different colums from the scada system we sepaerate with a pipe symbol. For history this is fine. But in case of reporting and analytics this is very bad. I would be happy if there is an oportunity or a speicial pi point format for alarms. The nessary coloums are: - Alarm ID - TimeStamp - Location - Messagetext - Duration - Status (Start, End) - Class

Hi What is the status regarding this function? We want to collect Alarms and Conditions from Siemens 840Dsl_828D_OPCUA This is critical for discrete manufacturing

Any news or update regarding this, this is a must when going OPC-UA. Could you share any viable workarounds this would be apprichiated.

We would appreciate if there would be a possibility to choose between Event Frame storage and PI Tag storage, or even both at the same time.

For the moment we work with the OPC A&E interrface to get alarms out of Siemens WinCC, but that is not very fexible. So the OPC UA connector should have at least the same functionality, preferable more like eventframes for alarms, one PI tag for all the messages, ...

Seconding Yusuf Cördük's comment, it would be great to have the option to choose between EF storage and PI tag storage for the Alarms and Conditions. Our end users prefer to have the Alarms data as strings in PI tags.