How and when the alarms&events are generated depends o=completely on the particular OPC server. SOME servers may base it on values of tags. And they may, or may not have OPC-Data Access part to them. But there are also OPC A&E servers that only provide OPC-A&E, and have no OPC Data Access part, and even don't have any "tags" to speak about, or data values to be compared to some limits.
In our Simulation server, which implements both OPC-DA and OPC-A&E, we have provided some pre-defined alarms that are generated automatically (and some that can be triggered externally). The purpose of the Simulation server is to allow the customer "see" the client component action, and for that we needed some alarms.
You should not limit your thinking to how the Simulation server works. Either you are developing a specific solution and therefore you do have information about how the target OPC server generates alarms, OR you are developing a generic solution that should not depend at all on the specifics of the target OPC-A&E server. But I cannot imagine why you would need to develop something that truly "knows" and is adopted to how our own Simulation server works.
In OPC-A&E, alarms cannot be "read". That is one of the things that actually makes this spec different from OPC Data Access. Alarms are asynchronous in nature, and the expected way to work with them is to subscribe to alarms coming from given sources or areas, i.e. a subset of the address space, and optionally specify a filter for their priorities and other characteristics. We have the SubscribeEvents method for this.
Besides this, I admit that there are ways to do something similar to "read". but you need to be careful to know what you are doing. Specifically, these extra "ways" to get info from OPC A&E server only work with so-called Condition events, for which the OPC servers keeps an internal state. They do NOT work with Simple or Tracking events, which are basically on-time occurences for which there is no state in the OPC-A&E server, and if your code was not "listening" at the time they occurred, they are gone forever.
With Condition events, you can also
- call RefreshEventSubscription. This is useful mainly upon startup of the program, when you want to extract the current state of these alarms from the server. They will come as event notification - you still need to call SubscribeEvents.
- obtain a state of a specific condition, by calling GetConditionState.
I hope this helps.
