Hi,
If you were to relate each alarm (equipment module or control module alarm) to the batch which is currently running on the given equipment, how would you do it?
The requirement is to see the alarms related to the batch while the batch is running, not only after it is finished.
Istvan
You would like to filter alarms based on batch at runtime?
Typically, a batch is unit-centric and alarms for that unit during batch execution would capture the essence of what you need. If the batch alarm scope is beyond the unit, then the alarms should be echoed in the unit itself by creating modules in the unit that monitor the states of alarms outside the unit.
You can set priority on alarms dynamically through batch logic to distinguish when an alarm is batch-related, then filter the alarm control on priority for the unit, but again this is unit-centered.
In reply to Youssef.El-Bahtimy:
A unit-centric approach would not work for shared modules. Their position is, of course, fixed in the database to a unit, but they may be acquired and used by other units while running a batch.
In reply to István Orbán:
Good point. We have done implementations where shared modules have an 'owner' parameter that is written during the batch which dictates the unit and batch ID that owns them. What I was looking for is a way to have the alarm control filter based on that text. I don't think the alarm control can do that, however. If you use Process history view in real-time wtih proper filtering you can effectively get the result of seeing alarms filtered by batch.
We have also built Unit-support-modules which handle these types of conditons for each unit. These modules are configured to monitor alarm points in other units, and can be enabled conditionally based on whether the remote alarm point is 'owned' by the unit batch, as governed by the recipe configuration. The remote alarm is echoed in the unit but can be turned on and off conditionally.
Short answer is, I don't think there is a built-in way to do it.
Thanks for the input. The requirement would be to see the alarms under a batch from our PI historian. We have all kinds of filtering capability there.
For now, we are exploring three possibilities, one of them is what you have suggested. The problem with that is, that then all shared modules needs to be acquirable, even the measurements, which usually are not acquired.
The other two:
1. Putting the batch ID into the alarm message. %P1 is already a string parameter, because of other reasons, so we could theoretically just concatenate the batch ID into it.
2. Whenever a module’s owner ID changes, we could create a logevent entry with the new owner ID (which is, in our case, the name of the unit which acquired the module). Because of our naming convention, this only needs to be done on the equipment module level as the control module names always contain the name of their EM. Then, on the historian side we could create a live list of EMs and corresponding owners and append the owner to the alarms.
What do you think about these?
I have received information that we have a <MODULE NAME>/OWNERSHIP.CV parameter in each module.
Do you know anything about it? Does it change with acquisition or does it always show the unit name in which the module resides?
I have never heard of this parameter on a module, but I looked at it....it seems to be identical to the UNITNAME parameter (except on units where it is "/")
I don't see documentation about it either.
I think your first option of appending the batch ID to the alarm description would be the simplest and most effective way to get the association, but it really doesn't give you real-time alarm monitoring/filtering.
We have seen the OWNERSIP parameter mentioned in an SMS call: NG-0900-0597.