Emerson Exchange 365

Hi Jitomit.

The value freezing is typical, as on comms loss the value is no longer updated. It is not possible to select a fail value for .CV values.

The appication you have should take account of the bad status of the parameter read and take appropriate measures to perform the correct action (possibly initiate a trip, possibly prevent a trip depending on application)

As an example , let’s assuming you have a non secure reference parameter reading a parameter of the SZ controller let’s call it PARAM1_NS . Then if you check the value of PARAM1_NS.ST, when bad it will have a value less than 128 (check books online for status values and sub-statuses)

Your CSLS should detect this value of .ST and use this to perform the action you require it to. Possibly trip/ possibly prevent a Trip. You may want to trip only following a certain period of bad status to prevent fleeting comms failure trips.

Note there is a settings on certain SIS function blocks to trip/not trip and trip after a time period on bad status detection. Please fully refer to books online.

Please note you should not be altering CSLS (SIS) logic unless you are competant to alter DeltaV safety instrumented system logic.

Being Safety system logic you really should determine what the safety function required is and ensure you do not compromise the safety function with any modifications. If you perform any modification, the safety instrumented function should be fully re-verified at the site from sensor to final element. Typically for a SIF loop already in operation your organisation should perform a management of change process, if any alteration are performed.

Hope this helps in some way.

In reply to IntuitiveNeil:

IntuitiveNeil has covered most of this well.

The Status parameter is an 8 bit word with the first two bits driving overall status or Quality States, four middle bits providing a substatus for the current status and the two least significant bits indicating limited or constant value.

00xxxxyy= BAD, Which means from 0 to 63. XXXX is a substatus, and will indicate further information about this BAD status.
01xxxxyy= Uncertain or Questionable, covering 64 to 127.
10xxxxyy= GOOD, and more specifically GOODNonCascade, values between 128 and 191.
11xxxxyy= GOODCascade, values above 192. Typically seen on signals between function blocks connected with Back Cal signals

From Books On Line, you can get a full description of the various substatuses for each Status. In general, if the status is BAD, the substatus does not change your response. The possible values you'll see depend on the source of the parameter. Two substatuses relate to communication: NoCommLUV and NoCommNUV. LUV is Last usable value, and NUV is No usable value. LUV is seen if a value is updating and then communication is lost. the last value is in the CV field, but is no longer updating. NUV is set if the value has never communicated or has not communicated since it was set to Out Of Service(OOS).

My approach is that with a BAD status, my response is the same, whether the signal is BAD because it is OOS, NoCommNUV, or NoCommLUV. The information might be useful during investigation of why is the value BAD, but once BAD, the logic must respond appropriately. Point is, the substatuses are not there to make your logic more complicated. You should respond to the Quality State in your application.

The other substatus are;
ConfigErr: For example, if a CALC block indicated an error, the OUT parameters would show BAD ConfigErr , depending on the expression.
NotConnected: An Input parameter of a block may indicate BAD NotConnected if it is not wired and thus get a status from the upstream parameter.
DeviceFailure: If the signal is a referenced to an output channel
SensorFailure: If the signal is from an Input channel

The status information is found under "Function block status information" in Books on Line.

Andre Dicaire