Emerson Exchange 365

• Not Answered

Adding multiple alarms from singe integer

Hello I was hoping for some guidance on the following problem. 

We have a device that we are reading alarms from. Currently there is a 16 bit going into a BFO block and each bit represents an alarm status.

Unfortunately when our machine goes into alarm or crashes there are multiple faults coming in at once and we are looking to track these just to get an idea of if something is starting to fail in a particular way. We have 6 of these set up within the same control module and would ideally like to keep it all together if possible. 

Somethings we have tried are using the log event triggered by each bit but we hit the max number of blocks in a control module. The issue I keep coming across is logging each event when there are multiple coming in at once in the same block. I am still learning quite a bit with DeltaV so I may just be missing some other way to accomplish this.  

• advanced alarming

LBDeltaV

• 7 Feb 2023 9:42 AM
• Cancel

1 Reply

• Andre Dicaire

  

  • 7 Feb 2023 6:28 PM

  My first challenge is whether these statuses are actually alarms. I would look at the device and decide on what types of alarms I should create. A maintenance alarm? An Out of Spec Alarm? There may be multiple status that trigger each alarm, but from the Operator's perspective, he gets a few alarms, with appropriate privileges and manage the status in the module rather than push all bits to alarms at the console.
  
  When an alarm happens, the underlying status(es) are available to help guide his response. So you coulud use a BFI block to consolidate the statuses that drive each alarm. The BFI provides a FO indicator that would indicate the First bit to come true. The BFI word can be used to set animation in a Detail display, along with a Named set to provide string descriptions, or set the strings in the detail display.
  
  If you have a single device that is generating 96 possible alarms, that does not sound like good Alarm System Design.
  
  If you want to log an event when a BIT goes active, you could use a CALC block with IF statements to evaluate the BFO out values when ever you see a change in the incoming integer. Off the top of my head, you could do a bitwise exclusive OR to determine which bits have changed, and then use this to determine which if statements to enter to set a log event on a positive or negative transition. Compare the current Integer value to the Last and if it is 0, not change, then skip all the log events. The exclusive OR result would indicate which bit changed and then using this In register inside the IF statement to determine if a Positive or Negative change message is needed.
  
  If the Log Event messages are generic, you could use a composite (BIT2 is True, BIt2 is False). But if you want each bit to have a unique text string, maybe use embedded block and set strings as needed.
  
  If you add a BFI block to generate a First Out trigger, and use that as your alarm bit, you will get a focused alarm condition for a set of statuses that require similar response. Avoid a mess of alarms but still provide granularity on information. The Alarm Message can be customized with the %P1, %P2 references which can be string parameters. In your Bit evaluation, you can use the BFI First in value to set the string parameter(s) to the bit description, so the Alarm always shows the FO bit. Other bits would appear in the event chronicle and your detail display would provide full scope of the device status.
  
  Fewer blocks, fewer separate alarms.
  
  
  Maybe you meant Status when you said Alarm. My point is you should be very cautious and minimalist in your alarm system. The alarm means it must be actionable, and there must be time to act to prevent a consequence. Otherwise, it is really an alert or status for the Operator to consider as needed, maybe as a result of a valid alarm. If it is an alarm, then Log Event is not the mechanism.

  Andre Dicaire

  • Cancel