Will a MDPlus controller buffer events / alarms to memory during a system wide network outage

Hi there,

We have an upcoming maintenance activity in the planning that may cause a temporary network outage across the deltav switch network. 

We are aware of operational consequences e.g. running batches, controller to controller communications, trend capture, etc. 

One question we are not sure on is: What, if any, buffering of information takes place inside MDPlus controllers during a network outage. 

We have looked to BOI and so far we are not finding an answer.  Any input from the Exchange on this one?

Presume there are varables if any buffering takes place, e.g. how many events the controller is processing and available memory, comes to mind.

Any 'features' to bear in mind? e.g. When the network comes back online the time stamp in the event log is the time the event happened, or is it the time the event entered the log ? 


Thanks.

2 Replies

  • The DeltaV controllers will buffer events only. When communications to the destination node is restored, the event will be sent to the node with the time stamp at which time the event occurred.

    Buffering is wide but shallow. What I mean is that every event source such as an alarm or log event is buffered, one event deep. If a new event is generated for the same alarm, the latest event will be buffered and the previous event will be lost. When this happens, the controller adds an additional message for that event indicating "Some Records were lost" for that event source (i.e. that alarm).

    Example. After a loss of communications, a controller experiences a HI alarm. This event is buffered in the controller with its time stamp. after several minutes, the alarm clears, creating a new event indicating the Alarm is now Inactive/Unacknowledged. Several minutes later a new alarm on a different module becomes active. there are no further changes to these alarms for some time until communications is restored.
    Result: The first alarm will record an event that it is Inactive/Unacknowledged, using the time stamp when this happened. A second message will be logged for this alarm indicating that some records were lost. The second alarm will record it is Active/Unacknowledged with the time stamp when this occurred. Because no subsequent event occurred on this alarm, there is no loss of data and the "Records Lost" message is not generated.

    You do not know how many records are lost on the first alarm, but you do know that the was at least one lost record. Also, the Event Journal will have logged ACN events indicating loss of communication with that controller, so there is a record of the window where events were lost.

    Since the events and alarms are time-stamped in the controller, they are always stored with the time of the event, not when it is stored in the database.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Thanks Andre, clear and informative reply. Appreciated.