Recent Control & Safety Systems Discussions
Similar Posts
How to handle PVBAD and MODULE ALARMS effectively?
Control Using Wireless Devices – Namur’s Interest
Module-Based Automation in NAMUR NE 148
Trouble Reading RPM with and I.S. DI NAMUR CHARM
How to handle large data in deltaV and achieve query function?
Share

PVBad handling in DeltaV, SIS and with NAMUR Enabled

Dear Experts.

I recognised that there is 4 second delay timer for deltaV before flagging PVBad when NAMUR is enabled. As this can affect our Trip abatement program which takes into account PVBad as evidence of spurious alarm to avoid trips from other alarms while PVBad is detected, understanding status handling is very important.

So I have some questions regarding this.

---BPCS----

1. with NAMUR enabled

Before PVBad is flagged for 4 second, how are other alarm parameters(LL, Lo, Hi, HH) are treated? Are they ignored or are some of them also activated?

2. without NAMUR enabled

how is PVBad is flagged? does it have 4second dealy as NAMUR ones?

And before PVBad is flagged for 4 second, how are other alarm parameters(LL, Lo, Hi, HH) are treated? Are they ignored or are some of them also activated?

--- SIS---- Same question as above.

1. with NAMUR enabled

Before PVBad is flagged for 4 second, how are other alarm parameters(LL, Lo, Hi, HH) are treated? Are they ignored or are some of them also activated?

2. without NAMUR enabled

how is PVBad is flagged? does it have 4second dealy as NAMUR ones?

And before PVBad is flagged for 4 second, how are other alarm parameters(LL, Lo, Hi, HH) are treated? Are they ignored or are some of them also activated?

Thanks in advance for any inputs.

Junggyu Yu

9 Replies

  • Tadeu Batista
    Hello Junggyu,

    First you mention NAMUR enabled and NAMUR Disabled, which led me to think this was a Discrete Input, but then you mentioned LL, L, H and HH alarms, could you please explain a little bit more the test you have performed, which platform have you used, Traditional vs Electronic Marshalling IO subsystem, which field devices, or which elements have you used to generate the fault state?

    Thank You!
  • Jonas Berge

    In reply to Tadeu Batista:

    In this case NAMUR must specifically refer to the NAMUR NE43 recommendation "Standardization of the Signal Level for the Failure Information of Digital Transmitters" which refers to what happens to a 4-20 mA signal when the transmitter detects a sensor failure. Basically this recommendation says that the transmitters measures from 3.8-20.5 mA to give some margin beyond 4-20 mA, and most importantly it says in case of sensor failure the signal shall go below 3.6 mA or above 21 mA. Before NE43 every device vendor and system vendor used different signal levels like 0 mA, 3.5 mA, 21 mA, or 22 mA etc. so there was no clear telling of the health of the transmitter from the current signal. NE43 also defines the 4 s timer to avoid spurious trips.

    This should not be confused with NAMUR NA1 for proximity switches (now IEC60947-5-6)

    There are now some 180 NAMUR recommendations. Many of these are very important in the process industries.
    www.namur.net/.../current-nena.html

    For instance:
    NE107 for flagging device status digitally
    NE175-177 for NAMUR Open Architecture for Industrie 4.0 / Digital Transformation / IIoT
    NE168 for Ethernet in field instruments (Ethernet-APL)
    NE124 for wireless sensor networks
    NE105 for intelligent device integration
  • Tadeu Batista

    In reply to Jonas Berge:

    Here's what BOL says:

    The first thing is to make sure the device is compliant to the NAMUR standard (NE43 in this case), otherwise, it's not going to work.

    Second step is make sure the Over and Under range are properly configured

    IMHO, it would only make sense to enable NAMUR for Analog devices, and is because for HART Devices, the system allow for other diagnostics to take place

    Regarding the process alarms, it will follow the variable, not so much the status, for example, if the NAMUR is enabled, unless you somehow customize the alarm annunciation, you'll have LL, L or H, HH, while a HART Analog device that is configure to change the status of the variable, holding last value, will most likely present BAD Status alert only.

    Hope that helps.

  • Andre Dicaire
    Jonas response details the reason NAMUR43 came about, as a means to require suppliers to be consistent. Enabling NAMUR limits means the Signal will be be flagged with a BAD status. Many devices can be configured to drive a maximum or minimum value upon sensor failure. By having NAMUR enabled, this fault signal would trigger this bad status on the channel, and this would allow downstream blocks like PID to shed to manual rather than integrate the output on a BAD, false signal. The PID has this capability built in based on the signal status.

    This is different than a wire break, where current would fall to 0 mA, or a Short circuit that would drive 23 mA.

    The Under and Over range limits can be used to set the signal status to Low or Hi limited status. The AI block can be configured to treat LImited as BAD and have similar effect as NAMUR. The 4 second delay on NAMUR avoids some spurious limited signals from affecting signal status.

    And as Tadeu mentions, HART enabled devices add an other level of signal status based on the HART Status byte, which can indicate if the transmitter is reporting things like PV Saturated or is Limited because the device has been placed out of service.

    When the channel status is flagged BAD, the AI block reflects this in the BLOCK_ERR parameter. From there the module can flag this as a PVBAD alarm. Your module level process alarms for LL, LO, HI and HH are based on the value of the signal, not the status. In the case of a failed sensor, and the transmitter driving 21 mA, the Namur enabled would set signal status to BAD, and the HI and HH alarms would be set if enabled. ( the transmitter could drive 3.6 mA. The choice would be based on how the Loop would impact the process via its output moving due to Proportional action, and you would want the output to move toward a safe position. If the PID block is not set to shed to manual, the Output will integrate based on the loop direction and you want the failure signal to drive to safe conditions.)

    In this case, you have three alarms on the sensor failure: PVBAD, HI and HH. These are in one module and could be consolidated to one instance in the Alarm Banner, or three instances depending on the settings for the Alarm Banner. How you configure your alarms, their priorities and any conditional or dynamic alarming will dictate the alarm behavior. NAMUR will not affect the alarms, but can ensure the status is set to BAD and your control sheds mode accordingly.

    If your process can normally move past the configured 4-20 mA range, and you don't want the PV to go to BAD Status when this happens, then do not enable NAMUR and use the Range limit parameters that set Hi or Low limited status. Then you can decide within your control module how to handle the limited status.

    Andre Dicaire

  • Junggyu Yu

    In reply to Tadeu Batista:

    Hi Tadeu

    I wanted to see how the signals are handled within 4second before NAMUR flags PVBad alarms in Series 2, 8 Channel AI, Hart, card.
  • Junggyu Yu

    In reply to Tadeu Batista:

    As long as I can adjuste OVERRANGE_PCT and UNDERRANGE_PCT to flag PVBad with mA values I want to setup, I can avoid NAMUR protocol which wasn't considered our Trip abatement program.

    Also as you mentioned, status flaggning and alarm status from the value are independent, so I found that PVBad and LL alarm were flagged at the same time when I open the loop without delay when NAMUR is not enabled.
  • Junggyu Yu

    In reply to Andre Dicaire:

    Thanks for the detail input.

    To make the design of trip abatment program work in my plant, I wanted to know PVBad set up and NAMUR option. So far with the information from experts, it seems like that I don't need to use NAMUR as OVERRANGE,PCT and UNDERRANGE,PCT can asjust x mA to flag PVBad. And because the design take into account 1 or 2 second delay for PVBad trip, it seems better not to use NAMUR option which can also casue additional 4 seond further delay.
  • Andre Dicaire

    In reply to Junggyu Yu:

    Under and Over range limits will set the PV status to Questionable, not BAD. I believe a range limit will set the channel to indicate Limited. The AI block can be configured to set the signal Questionable if Limited and the PID can be set to treat it as BAD if Questionable. I don't think the limits will cause the modules PVBAD alarm to be set if this is evaluating the AI/BAD_ACTIVE.

    The PVBAD alarm can be triggered from different parameters, but is likely triggered from the AI block's /BAD_ACTIVE parameter. This parameter is set based on the Bad Mask and the presence of a matching Block_Err. The Input Failure/PVBad block error bit is set when the AI Block sees the Input channel status go BAD.

    A transmitter failure or open circuit will result in 0 mA, or a wiring fault that shorts the field wires would drive about 23 mA, and both of these will set BAD Status on the channel and cause the Input Failure/Bad PV bit to be set. But on a sensor failure, the transmitter sends a valid high or low signal. If NAMUR is not enabled, I don't think you will get the Input Failure/PVBad condition on BLOCL_ERR. You will get your High or Low alarms, and you can mitigate PID control windup by promoting Limited status to Questionable and Bad.

    If the transmitter is HART enabled, the HART_Errors can set the channel BAD, which will set the PVBAD alarm without NAMUR enabled.

    I would expect that for a transmitter that is configured to drive a fault value on sensor failure, NAMUR would be enabled so that the channel can treat this extreme value as a BAD PV. For transmitters with processes that can exceed the 4-20 mA range set on the signal, the signal might reach the Namur limit under normal operation and you might not want to use this feature on those signals. If you disable Namur, you PVBAD alarm may only set on channel, transmitter or wire failures were the signal is 0 or 23 mA. Limited status is not the same as BAD status.

    Andre Dicaire

  • Junggyu Yu

    In reply to Andre Dicaire:

    Hi Andre

    So in that case, to fit configuration for the purpose, if I choose Bad if Limited option in STATUS_OPTS, can I flag the AI channer as PVBad according to UNDERRANGE_PCT and OVERRANGE_PCT?

    Remy Yu

This is the official online community site of the Emerson Global Users Exchange, a forum for the free exchange of non-proprietary information among the global user community of all Emerson Automation Solution's products and services. Our goal is to improve the efficiency and use of automation systems and solutions employed at members’ facilities by sharing our knowledge, experiences, and application information.

User Groups | World Areas | Community Guidelines | Legal Information | Privacy Policy | Contact Community Manager

Website translation provided by Website Translator

© 2015-2022 Emerson Global Users Exchange. All rights reserved.