o What is your primary use case for collecting A&C data?
We use the A&C data for troubleshooting, root case analyses and continuous improvements and alarm reduction!
o How do you collect A&C data today?
We use OPC-AE interface, PI EMDV Batch (Event Chronicle), PI-UFL
o How is their A&C data stored in PI?
Preferrably as a string in one PI-Tag per data source.
o What sort of alarm data do you have? I.e. instantaneous alarms, acknowledgements, alarms with a start and stop time?
All of above.
o What is the preferable way to create Alarms and Conditions within PI (i.e. PI Tags, Event Frames, etc.)
Both, depending on Use Case. Should be selectable based on filter criteria.
o What is your best estimate for how many alarms/events should be created in a year? 80.000.000 per data source.
o What do you use to consume A&C data? How do you utilize A&C data afterwards?
o How do you visualize A&C data?

What is your primary use case for collecting A&C data?
We use the A&C data for troubleshooting, root case analyses and continous improvements!

o How do you collect A&C data today?
We use the OPC AE Interface.

o How is their A&C data stored in PI?
We are currently investigating if we can store it in event frames.

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

o What is the preferable way to create Alarms and Conditions within PI (i.e. PI Tags, Event Frames, etc.)
Preferably it has to be stored in a relational database, maybe as Event frames. I think if the adapter can create event frames would be the best!

o What is your best estimate for how many alarms/events should be created in a year?
We have 10.000.000 events per year and rising!

o What do you use to consume A&C data? How do you utilize A&C data afterwards?
We use it when a failure occurs in our plants for trouble shooting and root cause analyses. We also plan to use it as reports!

o How do you visualize A&C data?
We are trying out PI Vision Events list but are not really satisfied with the performance and flexibility.
Also reports can be created in Power BI using the integrator for BI.

OPC UA A&E is a must as this is used in control systems to capture batch exceptions which then need to be captured and reported using RtReports.

Customers are telling me that in pharma, they've reached the inflection point where vendors are only offering OPC UA. Before when vendors' UA server was a wrapper, they could always get to alarms with OPC A&E. That's no longer the case, and they now must access this data from OPC UA Alarms and Conditions or they aren't going to get it.

This is vital for operations as alarm history is required in pharma manufacturing and we've historically had products to get this data.

OPC UA Alarm and Events retrieval is an important feature that i would like to see in PI, there are different business partner that invested resources to update the shoo floor equipment to allow OPC UA connection, so i consider the unavailability of A&C a gap of the OSiPi system.

Alarms and Events data from automation systems become more and more important to store for long term. This demand comes from the need to optimize processes through data analytics and data modeling tools. Ideally this Alarm & Condition data is store in the same data repository as trend data.
Moving from OPC Classic to OPC UA is key as we have systems that are not providing the OPC Classic interface. When the PI connector is not supporting the Alarm capturing, we'll need to setup other systems that does provide the OPC UA Alarms & Conditions and long time storage capabilities.

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.

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, ...

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.

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

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

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!
 
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

Important for Rail industry, so yes

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

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