Hi!
We are doing a project in which we have some Endress+Hauser fieldbus instruments supporting NE-107 alarming. Unfortunately, we are using DeltaV 11.3 and this does not support it. We are using a functionality described in books online under: Configuration/Modules/Access Intelligent Field Device Diagnostic Data to read the recommended action code from the resource block of the instrument in a control module and using a huge nested if/then/else structure to convert the code to a string an then raise an alarm having that string as message:
'^/FF_ALARM.CV' := FALSE;
'^/REC_ACT_MSG.CV' := "";
IF '^/REC_ACT_READ.CV' = 162 THEN
'^/FF_ALARM.CV' := TRUE;
'^/REC_ACT_MSG.CV' := "1. Tighten HF cable connection 2. Check sensor 3. Change HF cable" ;
ELSE
IF '^/REC_ACT_READ.CV' = 112 THEN
'^/REC_ACT_MSG.CV' := "Clean sensor";
ENDIF;
(*Add further conditions as needed.*)
This is not a very nice solution. Anyway, we are going to switch to DeltaV 12 as soon as it is released.
My question is: what is new in DeltaV 12 regarding this? I was informed that it has NE-107 support, but noone can provide me any details how to achieve this functionality with it.
The goal is to generate DeltaV alarms from FF diagnostic messages.
Istvan
My understanding is that NE107 conditions are intended for maintenance level activities, and that Emerson is incorportating these via AMS and the device DD from the manufacturer. I don't beleive the NE107 conditions will be any different in DeltaV v12.
If the device alert condition affects the integrity of the variables it provides, the status of these signals should either go questionable or BAD. In the case of BAD, the DeltaV Module should indicate BAD_PV and the appropriate control block responses should occur, based on signal status. If you are also creating an FF_ALARM, you are creating duplicate alarms and contributing to alarm flooding problems.
One thing we've learned in DeltaV with PlantWeb alerts is that elevating device conditions to alarms to operators is not a good thing. Since you are processing this logic in the control module, your "device health" alarms will be handled by the system as Process Alarms in the alarm filters and event chonicles, and will not be seen on the DeltaV Maintenance station alarm lists, which only see Device alarms.
The NE107 conditions should be seen in the AMS device Manager based on the device's DD, or DTM. Version 12 AMS supports the DTM's for FF and HART devices. There is an optional add on to v11.5 AMS for FF DTM's. If this device only shows the NE107 in a DTM, this would address your maintenance needs to view the data, and save creating this added code in your control modules and avoid nuisance alarms in your Operator alarm lists.
Comment on your code. You should only parse the diagnostic data by exception. If it does not change, skip the expression. Also, using a Named Set is much more efficient for the expression and for communication to the workstation, where you'll want to read the text. You can create a device specific Named set/composite block and resuse this for each device instance.
Andre Dicaire
In reply to Andre Dicaire:
Thanks for the tips.
The problem with namesets is that the text can be maximum 48 characters long and the index of entries can only go up to 250.
The code itself is very many times bigger than 250. This would need to be somehow mapped to the range 0-250 (by another nameset or some kind of lookup).
The text can get very long (more than 100 characters in most cases). We would need to heavily truncate it.
Andre, the code runs indeed only when the code changes (it is started by another action block which monitors whether the code changes).
The thing about nuisance alarms is completely true, especially since these will all be generated from control modules. Anyway, these FF_ALARMs will all have the same priority, so we can have an alarm list filtered on them.
In reply to István Orbán:
Istvan,
Your latest comments also concern me. The DeltaV controller is intended to do control, not text manipulation. What you are doing really does not belong in the controller. It belongs in AMS. You are effectively translating the DD or DTM information into the control module, and this will consume CPU and memory as well as create additional communication loads at levels that are likely not tested for within the product development/test cycle.
If you have one of these devices, you likely will not see any issues. But if one turns to 10, then turns to 100 devices, the impact on controller performance could be significant. If you have MX or SX controllers, you will have extra memory and communication bandwidth, but you may also have more modules, more devices. Hmm.
If the E&H device has a DTM or DD, I would highly recommend you save yourself this pain and trouble and use AMS for its intended purpose. You should at least bench mark this solution to understand how it will impact your controller before deploying multiple instances of this approach.
A compromise would be to evaluate the diagnostic parameter for specific conditions that require proactive notification of the operator, and only deal with these few (and there should be few). The balance of conditions should be dealt with by maintenance with AMS. In my experience, the Operator needs an actionable notification, with details left to those assigned to resolving the issue. More than 250 different conditions? Not the direction I would go...
Andre, thank you for the advice.
Yes, I am aware that this is not good practice and that it will generate some controller load. But since the if/then/else expression only gets executed when the recommended action code changes, the load will not come very often.
There are around 100 different codes per instrument, the only problem is that they are not sequential: they are scattered in the range 0-1000, this is why mapping to the 0-250 interval allowed by namesets would also pose a problem.