Charm integrity error flooding alarms and events

Hi,

We are having 'multiple charm integrity error' looged in as an advise_alarm in alarms and events. It increases the number of alarms per day and so the archives are more. We plan to reduce these alarms. At the charm configured as 4-20mA Hart device, we have device alarm enabled. I suppose if we disable this we won't have any alarms for sure but that would mean a trade off not having necessary alarms for diagnosis of hart device. Any advise on if we have a recommendation on how we can remove unnecessary alarms and keep must alarms enabled from hart Device alarm configure? This wold eventually log less numbers and are genuine for the operator alerts. I tried an option to supress individual charm alarm from the condition summary detailed faceplate. But that would suppress the alarm which won't have any further logs again.any good recommendation for setting appropriate hart alarms and disabling from the alarm configure of hart properties if we are not using AMD or not planning to use AMS in near future? Also any pros and cons to the setting would really appreciate? This should not affect any of the module alarms. Also do we have a detail display or anyway to see the multiple alarm condition for integrity error

Thank

Deepika

7 Replies

  • What you're talking about is doing alarm rationalization. Are the alarms you are receiving really actionable? Alarm rationalization is a process that involves some time from Operations and other folks, but it results in happier operators who are less likely to make mistakes. My company does alarm rationalization, so feel free to contact me if this is something your plant wants to pursue.
    At most of the facilities I program, if HART alarms are causing nuisances, I just disable them (if they are not, I leave them in the default state). I make exceptions when their Maintenance folks will actually go look at the instruments.
    As far as seeing more detail, you will likely have to program something specific to the end device. There is probably an error code you can bring back via HART, and you'll need a table to decode that error. Unless you have a lot of that type of instrument, it isn't likely to be worth the time investment. The HART alarm should prompt Maintenance to go examine the field device.

    - Bryce H. Elliott, P.E.

  • In reply to Bryce Elliott:

    Zanjurne, are you able to post the details of the event message from Even Historian?

    When you state that you are seeing "multiple CHARM Integrity" events, then this would be the CIOC Hardware Alert, not a HART transmitter Device Alert. The Event Message will indicate if the Advise alarm is related to the CIOC Node or a HART device.

    The HART enabled CHARMS can report an integrity status issue based on the HART_ERRORs property settings of the CHARM. And this can propagate up tot he control modules that read the CHARM HART_Field_value. But you are indicating only that you are seeing CHARM integrity, not signal status issues.

    the condition summary should show the underlying conditions that trigger an alarm. But if this is fleeting, the conditions may be gone by the time to look at it.

    Masking the alert without understanding its root cause may lead to other issues that are more disruptive. I think you are wise to try to find the root cause.

    Are you using the Event Chronicle on the Pro Plus or an instance licensed on another node. The Pro Plus includes an Event Chronicle that you could use to redirect your device alerts to. Device alerts are typically assigned to Area_A, and can be assigned to a specific Plant Area. If you isolate the device alerts to a plant area, you can assign this to the Pro Plus event chronical and take it away from the main process Event Chronicle. This will relieve this Event Chronicle of al these event messages, and that can improve its responsiveness to PHV if there are thousands of these events per day. You can then use the Pro Plus event chronicle to continue monitoring and investigating the issue without suppressing it.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Thanks Bryce and Andre for the replies, was on holidays and back to business now.

    Very true cannot mask the alarms without knowing the real meaning usage of it. Currently the charm is configured as AI 4-20mA HART for all the HART type transmitters. We are not using any of the HART functionality available on device as well as in DeltaV. Alarm rationalization is one part executing a big project but currently the issue is A & E is flooded with 'Charm integrity error' which seems not relevant at a moment but again can be genuine if we use HART functionality to its capacity. Control Module is not configured to look at HART_Field_value instead looks at Field value PCT. I have attached the alarm summary, Condition summary snap for your reference along with examples to diagnostics few of the instrument would flag. This is mainly on the Ointig getting BAD due to Hardware Intig I suppose but you can comment on this with your best experience if it is wise to disable them until we use the AMS at later stage or leave the HART configuration to use diagnostics tool for reflecting the statuses. Or even disable few from its 'alarm config' button to remove maximum of them triggering the unnecessary ones. This will be only for the big hitters (probably 10-20 at max). One more thing is I cannot drill down into Condition alarm summary, anyway to check this please?

  • In reply to zanjurne.deepika:

    It's not obvious to me if you have had the DeltaV try to identify the HART devices. If you have, you should be able to use AMS to dig in and figure out what the core issue is for each. Regardless, you appear to have several different kinds of errors.
    "Primary Variable Inaccurate" is one I haven't seen before. Here is someone else who has had an issue with it: emersonexchange365.com/.../ai-charm-diagnostic---primary-variable-inaccurate
    "Device Malfunction" suggests an issue with the transmitter, although what is uncertain.
    "Not Communicating with Device" usually means that the transmitter isn't HART, but you have HART communications enabled.
    "Loop Current Saturated" means that you are outside the limits which have been set. I think the defaults are -3% to 103%. Anyway, you're sufficiently outside 4-20 mA that the system is complaining.
    The bottom line is that you'll have to deal with these one by one. There isn't a systemic solution. I would go figure out what's causing them and try to fix the issues before disabling them.

    - Bryce H. Elliott, P.E.

  • In reply to Bryce Elliott:

    Thanks for your inputs Bryce. A little bit of checks done on the system there on why "Loop current saturated" (appears in diag only when the transmitters are idle means no process running to sense the value), "Not Communicating with device" (are some of them non-HART as you said), is done. Also to "primary variable inaccurate" seems to me a HART parameters configuration issue (cannot be resolved at a moment as we are not using HART functionality. Sad thing is we don't have AMS manager on site and the other thing is we cannot check any extra information required on AMS Handheld 475 service is stopped by Emerson. Hence we cannot use 475 due to unavailability of upgrade utility files. So was checking how can we best try to minimize the nuisance ones without disabling the alarm or just disable it eventually.
  • In reply to zanjurne.deepika:

    Go ahead and install AMS. There are some things that can be done without having a license. It's limited, but it's better than nothing.
    The other thing would be to configure your I/O as not having HART functionality. Granted, you miss out on diagnostics, but you're back to straight 4-20 mA, and if you don't have the tools to use the diagnostics, the alarms are worse than useless. You can always re-enable HART later (requires a download, so try not to do it when communications loss would be bad).
    If you are getting a "loop current saturated" alarm when the process isn't running, then you might want to check the calibration and/or range on the transmitter. If your pressure transmitter is ranged 0-100 psig, and you are at 0 psig, you should be getting something very close to 4 mA, and it shouldn't be saturated.

    - Bryce H. Elliott, P.E.

  • In reply to Bryce Elliott:

    Many thanks Bryce for all the suggestions and guidance. Worth knowing. Using AMS would be an option to troubleshoot some sensible HART alerts for sure. For the high target hitters, we have currently re-configured HART configurations to normal 4-20 mA types. With this option the numbers go down but we would compromise on useful diagnostics info. Going stage by stage at a moment to investigate further.