Alarm Handling Guidelines

Equipment can have hardware issues and process conditions that may prevent operation and may trigger alarms or cause faults or trips. Where a fault notifies the controlling system but doesn’t take other action and where a trip immediately returns the device to its Failsafe state. Hardware issues and process conditions won’t necessarily cause a fault or trip.

Classification

• Hardware- Issues related to the physical device feedback (Failed to Activate/Blown Fuse/Lost Activation)
• Process- Conditions caused by operation of the device (High Pressure/High Temperature/No Flow)
• System- Configurable-Alarm Objects typically triggered by instruments and manifested as process issues

Action

• None
• Permissive- Prevent startup only and elevate alarm if start is attempted.
• Fault (1)- Alerts controlling system but takes no action. Default action for Hardware Issues
• Trip- Immediately switches device to oper mode and its failsafe state. Default for Process Conditions

Alarm Severity

• No Alarm
• Information- Default for Permissive action
• Warning- Default for Fault action
• Critical- Default for Trip action

Mode

• Maintenance- Overrides all action
• Operator- Faults act as trips
• Interlocked- Trips act as faults (deactivated status must be confirmed or its not interlocked)
• Program- Faults act as trips
• Owned- Action as described
• Acquired- Action as described

Devices

• CM- Action as described above
• Unit- Action as described but delegates the trip to the CMs
• Instr- Only has input faults as treated as faults
• EM- Pass through faults and trips; may be configured to hold, ignore or change task
• Phase- May ignore or fault
• Batch- Alarm and may hold recipe

(1)Faults only alert the controlling system but take no action of their own unless there is no controlling system in which case the fault has the same affect as a trip. Examples of a controlling system are: Operator, On/Off push button, Expression, CM Wrapper, EM. Of these the Operator, Push button and an Expressions are treated as “dumb” control systems and will cause the fault to be treated as a trip.

CM Hardware Issues

These are the fixed hardware issues. More may be configured with Alarms or programmed in the CM.

• I/O Fault
• Ignored I/O Fault – I/O faults may be ignored so this is treated as a different alarm for info only
• Invalid Feedback
• Blown Activate Fuse
• Failed to Begin Activate
• Failed to Activate
• Lost Activation
• Blown Deactivate Fuse
• Failed to Begin Deactivate
• Failed to Deactivate
• Lost Deactivation
• 3 Customs

CM Process Conditions

These are the fixed hardware issues. More may be configured with Alarms or programmed in the CM.

• E-Stop
• S-Stop
• Lost EM Communications (if acquired)
• EM Not Scanning (if acquired – indicates program bug)
• Interlocked
• ProcLowWarn
• ProcHighWarn
• ProcLowCritical
• ProcHighCritical
• 2 Custom Permissives
• 2 Custom Trips

Alarming

Due to not knowing how many alarms and having to program for every possibility it is not practical to create an alarm trigger in FTView because this would be in the 10s of thousands. However, every alarm is important and must be recognized by the alarm and event server (A&E) primarily for historical purposes. To accomplish this a few buffers are created in the controller to hold all active alarms and to act as a trigger for the A&E Server to alarm on.

Alarm Buffers

• Critical
• Warning
• Information

Each condition will be treated by the A&E Server as the buffer is designated for which the event is placed. Removing an event from the buffer will clear the alarm. Alarms are recognized by their owners via a reference data type that indicates the object type and its ID. Additionally each alarm will have a type and ID to recognize it has a hardware or process condition and which item its. Also each alarm event will have an age indicator to recognize which is the most recent.

Notes:

1. Modes
2. Manual Maint (future) – all faults, trips and permissive are overridden
3. Manual Oper – All faults, trips, perm. are still active and on fault will return to failsafe
4. Acquired – Faults default to defer, Trips goto failsafe but are configurable to take either action. On Failsafe also switch to manual mode. Change EM to always hold Active State so switching back to Auto will put CM back into desired state.
5. Auto-driven by Inputs (or expressions) – Critical Faults and Trips fail to Failsafe in manual mode.
6. Owned – CM Wrappers – Configurable to pass through Manual Mode or ignore. Pass through Faults and Trips. Treat same as other modes depending on what mode the Owner is in.
7. Interlocked – Ignore but confirm inactive state (if inactive state cannot be determined then treat as NOT interlocked.
8. May need option to ignore Faulted Interlocks so the EM can goto bypass.
9. Need Task Selection permissive to prevent task if it would cause a fault due to currently ignored CMs.
10. EM should ignore any CMs that are in manual mode on deactivating.
11. Each condition may have its own response.
12. Faults could force Manual to Failsafe state (off, on, last)
13. Problem with EM if deactivated then the EM lost control and can’t take necessary action to have a controlled stop. Such as if the failure was lost activation on a outlet valve from a pump. Closing the valve would deadhead the pump. Keeping the valve open allows the EM to do an orderly shutdown. But if the valve is put in manual then the EM cannot close the valve as it shuts down.

Alarm object

• X Desc
• Severity
• Action
• Override 1-shot
• OR1Shot Security
• Override Cont.
• ORCont Security
• Disabled
• Active
• WasActive
• Color – Primarily ForeColor but could be used as backColor
• When Last Occurred
• Number of Occurrences

Alarm problems with not faulting CM is that a CM may have multiple active alarms which become impossible to display in alarm summary and to manage in CM Faceplate as most recent active alarm.

Could do this:

• Fault all to manual and fail safe (problem: no way for EM to control)
• Trip always defers to higher level.
• If none higher or Critical trip then it will trip immediately

Returning a CM to auto will cause CM to return to state requested by EM.

• Override – Should it still give alarm? Yes
• Disable Alarm via Studio (also via Faceplate?)
• Should permissive throw alarm if CM is attempted to be started in manual (in auto)?

New Alarms

Instruments will strictly have limits without alarms or conditions other than value. Alarms will exist outside of the instruments and may be configured with various properties. These will be the only instrument alarms and are evaluated separately from the instruments and messaged independently to the EM for processing by the EM if necessary. Alarm triggers and arming will use the same Expression’s as with the EM. An alarm may be associated with as many CM and Units as necessary but will require increasing the size of an internal array in the Alarm UDT.

Alarm Properties:

AlarmExp

Expression use to trigger the alarm (If associated with value then an automatic DB will be applied)

Delay

Delay time before triggering alarm after trip (ms) (may use some class based settings such as the state of the object associated with the Alarm Expression. (This may not be necessary if the expression includes the delay but that could make the expression more complicated)

ArmExp

Expression used to Arm the Alarm (could be any accessible point including I/O)

ArmDelay

(This may not be necessary if the Expression includes a delay)

Refs

Array of Reference IDs (CM or Units) associated with this alarm.

Severity

Binary – If set then this is a Severe alarm for the associated Reference (off = warning)

UnitRcv

Binary – If set indicates this alarm is on the receiving side of the unit (off = sending size); Applies to Units references only.

ReqAck

Alarm must be Acknowledged to clear

ReqReset

Alarm must be Reset to clear

Message

Alarm message

MsgVar

Variable definition to include in the Alarm Message in the format {Message} – ({#})

Original Properties

InstrID

Instrument associated with alarm (required)

TripValue

Alarm Trip Value (optional)

DB

Alarm DeadBand (prevents alarm from going in/out too fast)

{This could default to ½% of FS}

AddSP

Add SP to Trip Value

SubSP

Subtract SP from Trip Value

UseTrip

Use Trip Value

LimitID

Alarm trip Limit (0-11) (optional)

Use Limit

Use Limit (after debounce timer with deadband)

UsePreLimit

Use Pre-Limit (immediate response but no deadband)

AlarmHigh

Alarm if Instr Value > TripValue or Limit is True; else,
Alarm if Instr Value < TripValue or Limit is False.

Delay

Delay time before triggering alarm after trip (ms)

CMID

Control Module associated with alarm (optional)

UnitID

Unit associated with alarm (optional)

Receive

For Units this is a Receive Alarm vs a Send Alarm

Alert

Alert CM/Unit if In Alarm

Trip

Trip CM/Unit if in Alarm

Message

Alarm Message

Format

Format of alarm message (ex: “{CM}-{Instr}-Failed ({Instr.Value})”)

ArmedAlways

Always Armed

ArmedAcq

Armed while Acquired

ArmedNotAcq

Armed while Not Acquired

ArmedActive

Armed while CM Active

ArmedInAct

Armed while CM is InActive

iArm

Arm Alarm while Active regardless of other settings

iDisarm

Disarm alarm while active regardless of other settings

ArmDelay

Delay time (ms) before arming alarm after arming trigger