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:
- Modes
- Manual Maint (future) – all faults, trips and permissive are overridden
- Manual Oper – All faults, trips, perm. are still active and on fault will return to failsafe
- 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.
- Auto-driven by Inputs (or expressions) – Critical Faults and Trips fail to Failsafe in manual mode.
- 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.
- Interlocked – Ignore but confirm inactive state (if inactive state cannot be determined then treat as NOT interlocked.
- May need option to ignore Faulted Interlocks so the EM can goto bypass.
- Need Task Selection permissive to prevent task if it would cause a fault due to currently ignored CMs.
- EM should ignore any CMs that are in manual mode on deactivating.
- Each condition may have its own response.
- Faults could force Manual to Failsafe state (off, on, last)
- 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