Link DO Module (Audible Horn) to Area Critical Priority Alarms

Is it possible to use the area active alarm and alarm priority to trigger an audible alarm in DV 14.3?  Reading books online and testing some options in Live I can read the active alarm "DLSYS.Read("AREA_A/ALARMS[1].F_NALM")" and the alarm priority "DLSYS.Read("AREA_A/ALARMS[1].F_PRI")", however I have not found any documentation indicating I can get AREA level alarm information within a control module.  I assume this information can be written from the graphics back to a module, however there is concern on how reliable / deterministic this approach would be.  Are there any options I have overlooked or documentation someone can point me towards to provide a solution?  We do not want to go down the path of building a control module that has all of the alarm conditions for each of the 10+ oven units as this will become a maintenance issue and time sink for any changes.  That is why we would like to link the triggering of the audible alarm directly to the "critical" (> priority 11) for the area.  We have taken this approach in our ABB system, but haven't figured it out in DeltaV.  Any help or guidance is appreciated.

  • The Area does not exist in the controller, so no way to access this from a module. However, Units do exist. So if you have your modules in a unit (not directly sitting in the area), you can use unit/ALARMS.PRI and unit/ALARMS.NALM in a control module.
  • Unfortunately not the answer you want to hear, but maybe a workaround?! Sorry.

    A few years ago I had the same issue with 4 new burner systems. I wasn´t able to use AREA-parameters inside the control modules too. But we had one operator station for each burner systems (AREA1 was assigned to OS1, AREA2 to OS2, ...). So I used the actual alarm priority of the OS to activate the horn.

    On another site with different - centraly operated - plants we separted SIS- and BPCS- alarms to different horns with different sounds. Therefore we used a DeltaV Operate graphics-IFIX background scheduler script in 2010 in v10.3.1 and it works realy fine up to now in v14.LTS. Of course it´s not executed "extremly fast" but for this reason this is okay for us.

    Stefan Müllner
    Senior Plant Engineer - Automation & Systems

    METADYNEA AUSTRIA GmbH

  • Unfortunately not the answer you want to hear, but maybe a workaround?! Sorry.

    A few years ago I had the same issue with 4 new burner systems. I wasn´t able to use AREA-parameters inside the control modules too. But we had one operator station for each burner systems (AREA1 was assigned to OS1, AREA2 to OS2, ...). So I used the actual alarm priority of the OS to activate the horn.

    On another site with different - centraly operated - plants we separted SIS- and BPCS- alarms to different horns with different sounds. Therefore we used a DeltaV Operate graphics-IFIX background scheduler script in 2010 in v10.3.1 and it works realy fine up to now in v14.LTS. Of course it´s not executed "extremly fast" but for this reason this is okay for us.

    Stefan Müllner
    Senior Plant Engineer - Automation & Systems

    METADYNEA AUSTRIA GmbH

  • Unfortunately not the answer you want to hear, but maybe a workaround?! Sorry.

    A few years ago I had the same issue with 4 new burner systems. I wasn´t able to use AREA-parameters inside the control modules too. But we had one operator station for each burner systems (AREA1 was assigned to OS1, AREA2 to OS2, ...). So I used the actual alarm priority of the OS to activate the horn.

    On another site with different - centraly operated - plants we separted SIS- and BPCS- alarms to different horns with different sounds. Therefore we used a DeltaV Operate graphics-IFIX background scheduler script in 2010 in v10.3.1 and it works realy fine up to now in v14.LTS. Of course it´s not executed "extremly fast" but for this reason this is okay for us.

    Stefan Müllner
    Senior Plant Engineer - Automation & Systems

    METADYNEA AUSTRIA GmbH

  • In reply to Stefan Muellner:

    Stefan thanks for the reply. Sorry for the delayed response, I wanted to test this out before replying. Finally got to test this out and we are having an issue with scheduling that prevented me from testing what you described. For some reason when we enable scheduling and set the FixBackgroundServer task to run as a service we start having connectivity issues to our ProPlus. We tried rebooting the ProPlus and it wouldn't even launch any of the DeltaV services after a reboot. Disabling scheduling fixed all of the ProPlus issues. I still need to open a Guardian case to work through the scheduling issue, but it's dropped to a lower priority for now.

    The solution we settle on with help from our Impact Partner is using the workstation/horn.cv parameter, which is available at the control module level as a diagnostic parameter. Since we have two dedicated workstations in this area this approach will work. The only limitations we found is the HORN.CV latches in the highest priority alarm it has seen, and doesn't clear the value when individually acknowledging alarms from the alarm banner. The operators have to use the silence button to reset the HORN.CV back to 0. In our case this will work for what we need, but definitely not as elegant as having direct access at the control module level to the AREA priority and NALM parameters like you can do from the graphics.
  • In reply to Jesse Delanoy:

    strange thing, your scheduler issue - sorry for digging it out...

    You are right. The workstation/horn solution is not as elegant as you are searching for. In addition it is further not possible to write directly on the parameter out of the control module. So for such needs I wrote a script, in our case again in a scheduler, that watches a parameter in the control module and executes the "silence horn"-action on each operator station.

    Stefan Müllner
    Senior Plant Engineer - Automation & Systems

    METADYNEA AUSTRIA GmbH

  • In reply to Jesse Delanoy:

    Rereading the question, you are wanting to generate an Area level HORN signal rather than an Operator span of control HORN Signal. The Operator Station drives the HORN based on THISUSER/ALARMS[1], which does not give you the granularity you seek for the Audible alarms you want to generate per Area.

    The suggestion by Istvan to use a Unit module provides a controller based mechanism for alarm groupings, however, after testing, the Unit/Alarms or EquipModule/Alarms parameters only return alarm information on their own alarms.  The contained module alarms do not roll up into these /Alarms parameters.  I thought they did, but after some testing, this is not the case.  I have an EM with modules beneath assigned as private.  Modules in alarm do not show up in the EM/ALARMS [1] parameter or the em/ALARMS parameter.  I created a Unit with a Phase and a contained module and forced a alarm condition.  The Module Alarm does not show in the UNIT/ALARMS parameter.

    The console U$ unit references will show the contained module alarms in its ALARMS[1] parameter, allowing for Unit level groupings of alarms within the plant area and to silence alarms by Unit groupings, but this is console resident information from the alarm system.  

    My original post stated the Unit/Alarms could be used in the control module to view the highest priority alarm by Unit to drive the DO horn.  I decided to remove that rather then create a new post.  I figure someone could read that post and not realize a subsequent post was created.  

    Anyway, the Module level /ALARMS parameter can be used in a control module to see the highest priority alarm and its Acknowledge state.  One would need to explicitly read all modules and determine the highest priority via an expression.  

    The HORN parameter reflects the total span of control of the console.  To know the alarm priority by UNIT, the U$ syntax could be used in a script, but a write to the controller would be needed.  Such writes will cause a record in the EJournal and an Upload record in the Powerup folder of the Pro Plus.  To avoid records in the Ejournal, the DO module(s) could be in a separate, unassigned Plant Area.   The Upload records are accumulated in the module's PWR file and can be discarded periodically.  

    Sorry for the misdirection on the controller based alarm information.  

    Andre Dicaire