1. Home
  2. Fundamentals
  3. Abnormal Condition Manager (ACM)

Abnormal Condition Manager (ACM)

About 

The Abnormal Condition Manager (ACM) is a separate logic module that monitors the status of all objects associated with an EM or CM.  When it detects an abnormal condition it signals the EM or CM to either fault, trip, prevent startup or just notify the operator.  It also activates an alarm for the alarm summary and feeds the event to the alarm historian.

The ACM will be scanned in its own task at a lower priority.  It will be responsible for checking on abnormal conditions for all objects.  Initially the condition monitoring will be specific to the object type but once triggered the handling will be universal for all conditions.  Each object should allow for several generic conditions that may be triggered by custom logic.  Also, each object should allow for redirect such that custom logic can provide the standard alarm condition logic for that type.  Ex: ACM_VFD would provide the logic for Failed to Activate, Failed to Deactivate, etc. [EM: Option Cm

Functions

  • Monitor Hardware Faults
  • Monitor Process Conditions
  • Monitor Route Integrity
  • Set Status of CMs and EMs in a EM
  • Build EM Notification Messages
  • Set EM’s Faulted, Tripped, Permissive and Info status tags
  • Activate Alarms for Alarm and Event Server
  • Manage FIFO for Historical Log
  • Provide faceplate interface to view active and inhibit conditions

Configuration

Each condition will not be configured because there can be literally 1000’s of conditions per EM and it is impossible to provide a means to configure, view and inhibit all of them via a list or other means.  Even if that were possible it would take too long to download the configurations and require too much memory in the processor to hold it.  Instead, default conditions will be configured for the EM classes for each abnormal condition group.  However, it may be required that certain objects of specific EMs behave differently than the default so exceptions may be configured from the default.  These records will be examined as pieces of information which will override the configured default behaviors.

Condition Configuration Exception Record

Item Type Type of Object (EM, CM, Instrument, etc.)
Item ID Item ID of specified type
Group ID Each condition is grouped (1-9)
Condition ID Each condition is given an ID unique to its category (1-99)
Object Index1 Each object is known to its EM by a positional index (1-99)
Action Action to take on condition (0=None, 1=Perm, 2=Trip, >2=Fault2)
Severity Alarm Severity (0=No Alarm, 1=Critical, 2=Warning, 3=Info)
Latch This condition must be reset to clear.
Inhibit Can be inhibited
Inhtibt1 Can be 1-shot Inhibited

1The object ID isn’t used here because it is easier to get the required information from the EM by its position. It will be crucial that the S88 Builder Studio maintain this index if the referenced object is moved or removed.

2Actions > 2 indicate a fault, since a fault allows the EM to continue running the fault number may be used by the EM to perform custom actions such as activate a specific task.  It may also be used externally be a unit procedure.

S88 Builder Studio Abnormal Condition Exception record

In S88 Builder Studio the AC Exception record will be a relation with control items.

Relation:

Relation Type EM..Condition, CM..Condition, Instr..Condition
Parent EM, CM, Instrument
Item Condition
Name Condition Name
Control Items
Severity
Action
Latch
Elevate
Horn
Notify
Notify ID
Inhabitable
Inhabitable 1-Shot
Disable
Advance Items
Subject

 

Management

As with the configuration download it is impossible to track the 100 of thousands of conditions with actual tags therefore each condition will create a record in an array of active conditions.  The active conditions will be merged with the current conditions so any latched ones will remain active.  This array will be used to set the EM interface tag and to build the most relevant indication message.  The array will also be used to manage the active alarms and to feed the historical manager.

A condition record will be used to track active conditions and is very similar to the Condition Configuration Record described above except the Group, Condition and Object IDs are merged into a unique key.

Condition Configuration Record

Key1 Abnormal Condition Unique Key (Syntax iiiitgccoo;

where i=item ID, t=object type, g=group, c=condition, o=object)

Action Action to take on condition (0=None, 1=Perm, 2=Trip, >2=Fault2)
Severity Alarm Severity (0=No Alarm, 1=Critical, 2=Warning, 3=Info)
Latch This condition must be reset to clear.

1This key is unique for all alarms.  This syntax allows up to 2147 items of 9 types with 100 conditions for up to 99 objects of 10 different groups for a total of 1.78 billion unique alarms.

2147483647

I I I I tg ccoo

Item ID and Object Type and Type ID come later

 

CondID TTGCCIIII T=Type, G=Group, C=Condition, I=ID

T x 10,000,000

+ G x  1,000,000

+ C x        10,000

+ ID

ObjectGUID

 

TTIIII T=Type, I=ID

T x 1000 + ID

CondID TGCC T=Item Type, G=Group, C=Condition

1,233 = Tx1000 + Gx100 + C

ObjectID IIIItiiii I=Item ID, t=Object Type, i=Object ID

999,919,999 = Ix100,000 tx10,000 + i

 

Add Inhibit option for instance vs pattern (i.e. Inhibit all like this)

 

 

This may sound like a lot of processing but fortunately this is only required for abnormal conditions which are infrequent so the extra processing time shouldn’t be a factor.

 

Faceplate

In the previous version all the conditions were consolidated into 1 condition of each type for all objects and listed on a tabbed window.  Then when a condition was active it was highlighted along with a message indicating the specific object that had the condition.  This also allowed each condition to be inhibited with a checkbox.  The problem with this approach is only 1 object of each condition could be alerted and when inhibiting a condition it affected all objects.

 

The new ACM is planned to display the messages for the 10 most recent and most severe conditions.  These messages will be maintained and read from the ACM structure.  The top most message will be sent to the EM as well.  The same means used to configure an abnormal condition will be used to inhibit them.  The faceplate can present a group of combo boxes where the user can dial up the condition to inhibit and then inhibit it.  This will create an inhibit record in the ACM.  The faceplate will also provide a paged list of inhibited conditions allowing them to un-inhibit it.

 

If needed a faceplate tab could be configured, as in previous version, to display all conditions for each group along with an indication if any object of a condition is active.  This could also be used to inhibit the condition entirely as before.

 

Scanning

The abnormal condition management was removed from the EM due to it taking a relatively long time to process in comparison to the actual EM.  Therefore, it doesn’t make any sense to scan it as frequently as the EM is scanned otherwise there would be no savings.

 

Idle Time

While idle the EM may still experience abnormal conditions that prevent it from starting such as interlocked CMs or full units.   It is imperative that the permissive be known at the moment an EM is evaluated to be started.  For example: The phase logic may choose an EM based on which is available.  Likewise, an EM will be triggered with the Alert Navigator if it’s not ready to start when a phase is running prior to starting but will trigger a fault if it’s not ready to start after receiving it’s start command.  While idle the ACM doesn’t need to be concerned with raising or latching any conditions so its processing time may be improved although it still must build the indication message for what is preventing startup.

Prior to starting the EM would force a scan on the ACM to insure it has a startup permissive.

 

Running Time

While running many EMs may be fine with waiting several seconds to recognize an abnormal conditions while others may need to know ASAP.  Also some conditions such as an overflowing tank or a deadheaded pump must be alerted immediately to prevent unsafe spillage and equipment damage.  While the CMs may account for some of this it is also important to handle it at the upper levels.

 

The ACM could be scanned continuously but on a lower priority in a different task so its time has no impact on the EMs.  This method is the easiest to implement but doesn’t allow for variable scan rates.  It also doesn’t allow for an EM to trigger a special scan of abnormal conditions such as would be done prior to starting to insure it has its start permissive.

 

The most common time for an abnormal condition is during a transitioning state so the EM could set a temporary boost signal to the ACM to scan continuously.  Then when the EM is at a static state it could remove the boost.

 

 

Actions

Permissive

A condition that prevents the EM from starting but once started has no affect.  Fault and Trip conditions also prevent startup in addition to their described functions.  A permissive condition does not raise an alarm unless there is an active start command.

 

Fault

A condition of the EM where an abnormal condition exists but the EM continues to run; however, it will likely be operating in a faulted mode such as recirculating.

 

Trip

A condition where the EM is forced to its fully held state, all CMs deactivated. The trip condition must be cleared before the EM may restart.

 

Groups

Each condition is classified in a group based on the object type and how it is used by the EM.  For Example the Acquired CMs will be in a different group then the Interlocked CMs.   Groups are defined for organizational purposes.

 

By default all conditions may be overridden (inhibited).  Each group also contains a customizable condition that may be setup using expressions.  The text in {curly brackets} will be replaced by the name of the object that caused the condition.

 

EM Groups

  1. System
  2. Acquired CMs
  3. Interlocked CMs
  4. Source Units
  5. Destination Units
  6. Instrument
  7. Dependent
  8. Spare
  9. Misc.

 

System

ID Condition Action Severity Latch Description
0 Custom N/A N/A N/A Custom condition configured by user via expressions.
1 Custom N/A N/A N/A Custom condition configured by user via expressions.
2 Not Idle Perm Info No An EM must be Idle and no other commands active before it will give a start permissive.
3 First Scan Trip None Yes On first scan any EMs that were running before the processor was stopped must be tripped since the CMs were also likely tripped.  Since this is a fleeting condition it must also be latched.  However, some EMs may be designed to not fail on loss of power.
4 Startup Timeout – {cm} Fault Warning No The EM has 3 stages to starting up and each one must be verified before starting the next.  If a valve fails to start it will likely fault and trip the EM before this condition but if not then this will eventually fault and alert the user to the condition. The resolution may be to hold and restart.
5 Shutdown Timeout – {cm} Fault Warning No On shutting down the EM a CM may not deactivate causing the shutdown to hang-up. This alarm alerts the operator to that condition.
6 Task Activate Timeout – {cm} Fault Warning No Same as Startup Timeout except it applies when switching to a new task.
7 Task Deactivate Timeout – {cm} Fault Warning No Same as Shutdown Timeout except it applies when leaving a previously activated task.
8 Invalid Parameters Trip Critical No The EM will be tripped if a set of parameters are entered that the system determines are invalid.
9 Approaching Max Operating Time None

 

Warning No Some EMs are given a maximum operating time to guard against spillage or blockage that may be preventing completion.  This is just a warning that the EM is about to fail.
10 Exceeded Max Operating Time Trip Critical No The maximum operating time has been exceeded. Restarting the EM will give an additional 20% of the total time to complete.
11 Provider {em} Not Ready None

 

None No If an EM is configured with a provider EM then it must be running before this EM may start and must continue or else this EM will be forced to hold.
12 Lost Communications Trip None Yes If any acquired CM controller used by this EM has a communication fault (from the watchdog) then it will trip the EM but won’t set the alarm since an alarm should already be present for this condition.
13 Tolerance Too Low Trip Info No Material Add EM undershot the tolerance so user must Abort/Retry/Ignore (Abort/Restart/Stop).
14 Tolerance Too High Trip Info No Material Add EM overshot the tolerance so user must Abort/Ignore (Abort/Stop).

Total possible System conditions = 15, 12 likely, 2 active

 

Acquired CMs

This group includes all CMs that are in the EM’s acquired list.  These conditions apply only to CMs in the active task unless all CMs are configured to acquire on startup. These conditions will be considered permissives for CMs in inactive tasks.

ID Condition Action Severity Latch Description
1 Custom N/A N/A N/A Custom condition configured by user via expressions.
2 Acq. CM {cm} is in Operator Mode Fault Warning

 

No A CM in operator mode cannot be controlled therefore it is an abnormal condition.
3 Acq. CM {cm} Hardware Fault/Trip Trip Critical No If any CM is faulted or tripped it will trip the EM.
4 Acq. CM {cm} Process Fault/Trip Trip Critical No If any CM is faulted or tripped it will trip the EM.
5 Acq. CM {cm} is Not Activated Trip Critical Yes The CM must remain in the state it was placed. Pulsing and Expression CMs are given 10s to activate.
6 Acq. CM {cm} is Not Deactivated Trip Critical Yes The CM must remain in the state it was placed. Pulsing and Expression CMs are given 10s to deactivate.
7 Cannot Acquire CM {cm} Perm None No EM will hold up waiting to acquire the CM which is un-acquirable at the moment.  This will trigger the Alert Navigator.
8 Acq. CM {cm} is Not Acquired Trip Critical No All acquired CMs must remain acquired at all times and the program doesn’t allow this but errors may.  This is immediate.
9 Acq. CM {cm} is Not Scanning Trip Critical Yes The CM logic is scanned more frequently when its active but due to program errors it may stop scanning all together so this protects the system under those circumstances.  This is latched because it is sometimes very fleeting.  This is suspended if a Communication Fault exists for the CM controller.

Total possible Acquire CM conditions = 480, 40 likely, 20 active

 

Interlocked CMs

This group includes all CMs that are in the EM’s interlock list.

ID Condition Action Severity Latch Description
1 Custom N/A N/A N/A Custom condition configured by user via expressions.
2 Cannot Interlock CM {cm} Perm None

 

No EM will hold up waiting to interlock the CM which is un-interlock able at the moment.  This will trigger the Alert Navigator.
3 I-Locked CM {cm} is Not Interlocked Trip Critical No All interlocked CMs must remain interlocked at all times and the program doesn’t allow this but errors may.  This is immediate.
4 I-Locked CM {cm} is Not Scanning Trip Critical Yes The CM logic is scanned more frequently when its active but due to program errors it may stop scanning all together so this protects the system under those circumstances.  This is latched because it is sometimes very fleeting.  This is suspended if a Communication Fault exists for the CM controller.

Total possible Interlock CM conditions = 720, 60 likely, 20 active

 

Source Units

Typically there is a source unit but there may also be many or no source units.  But always there will be only 1 active source, if any, and the reset inactive.  None of the conditions listed below apply to inactive units.

ID Condition Action Severity Latch Description
1 Custom N/A N/A N/A Custom condition configured by user via expressions.
2 Source Unit {unit} is Not Ready Perm None

 

No EMs will not be allowed to start if the source is empty or has other issues.
3 Source Unit {unit}Low Warning

{not implemented}

Perm Warning No This condition is just a warning that the Tank is almost empty  so no new EM’s may start but running ones may continue.  This is not much different than the Empty condition except it raises an alarm.
4 Source Unit {unit} Empty Alarm

{not implemented}

Trip Critical No If a critical Empty alarm was configured then it is assumed that the EM may not continue when triggered so this will trip .
5 Not Enough Material at Source {unit}

{not implemented}

Perm None No There won’t be enough material to complete the EM so this prevents it from starting.
6 Source Unit {unit} Level Not Falling

{not implemented}

Fault Warning No The level must continue to reduce if the EM type is Transfer or Material Add unless the unit is also the destination of a Transfer or Material Add EM.
7 Source {unit} Level Instr. Fault Trip* Critical Yes *This alarm is only active for Transfer class EMs since they depend on the source unit’s level.
8 Source Unit {unit} Faulted Fault Warning No This condition is an indication that the source unit has a fault condition but it may not affect this EM.

Total possible Source conditions = 15, 8 likely, 3 active

 

Destination Units

All EM’s must have at least 1 destination unit but there will only be 1 active unit. Most of the conditions apply only to the active unit but a few apply to all*.  None of the following alarms apply to process EMs since these don’t add or remove material.

ID Condition Action Severity Latch Description
1 Custom N/A N/A N/A Custom condition configured by user via expressions.
2 Dest. Unit {unit} is Not Ready Perm None

 

No EMs will not be allowed to start if the destination is full or has other issues.
3 Dest. Unit {unit} is Full Perm Warning No This condition is just a warning that the Tank is almost full so no new EM’s may start but running ones may continue.  This is not much different than the Full condition except it raises an alarm.
4 Dest. Unit {unit} is overflowing* Trip Critical No If a critical full alarm was configured then it is assumed that the EM may not continue when triggered so this will trip.  This also applies to any alternate destinations as this may be an indication that a CM failed to divert the flow to the designated unit.
5 Not Enough Capacity at Destination {unit}

{not implemented}

Perm None No There won’t be enough room in the destination to complete the EM so this prevents it from starting.
6 Dest. Unit {unit} Level Not Rising

{not implemented}

Fault Warning No The level must continue to rise if the EM type is Transfer or Material Add unless the unit is also the source of a Transfer or Material Add EM.
7 Dest. Unit {unit} Level Instr. Fault Trip* Critical Yes *This alarm is only active for Transfer class EMs since they depend on the destination unit’s level.
8 Dest. Unit {unit} Faulted Fault Warning No This condition is an indication that the source unit has a fault condition but it may not affect this EM.

Total possible Destination conditions = 25, 8 likely, 3 active

 

Instruments

EM’s may reference an End Of Condition instrument to be monitored for the target condition to complete the EM.  This only applies to Material Add EMs.

ID Condition Action Severity Latch Description
1 Custom N/A N/A N/A Custom condition configured by user via expressions.
2 Instr. {instr} Faulted Trip Critical

 

Yes IF the EOC instrument fails then it cannot detect End of Control so it must trip the EM. This may be a fleeting situation and difficult to trouble shoot so best to latch.
3 Instr. {instr} Low Warning Alarm Fault Info No A low warning alarm indicates the instrument is falling too low so the EM should take corrective action.
4 Instr. {instr} Low Critical Alarm Trip Critical No The instrument value has reached a critical point and the EM must stop.
5 Instr. {instr} High Warning Alarm Fault Info No A high warning alarm indicates the instrument is rising too high so the EM should take corrective action.
6 Instr. {instr} High Critical Alarm Trip Critical No The instrument value has reached a critical point and the EM must stop.
7 Instr. {instr} Unavailable Perm None No EM will not be able to start if the instrument it needs is in use by another EM or for any other reason.

Total possible Instrument conditions = 15, 7 likely, 2 active

 

 

CM Groups

 

  1. System
  2. Hardware
  3. Process

 

By default all conditions are overridable (inhabitable).  Each group also contains a customizable condition that may be setup using expressions.  The text in {curly brackets} will be replaced by the name of the object that caused the condition.

System

ID Condition Action Severity Latch Description
1 Custom N/A N/A N/A Custom condition configured by CM Overhead
2 Custom Perm Info No Custom condition configured by CM Overhead
3 Custom Custom condition configured by CM Overhead
4 First Scan Trip None Yes First Scan after processor Restart
5 E-Stop Fault Warning No Emergency Stop Active
6 S-Stop Fault Warning No Software Stop Active
7 Lost Power Fault Warning No Control Power was lost
8 Lost Communications Fault Warning No Communications with EM was lost

Total possible System conditions = 15, 12 likely, 2 active

 

Hardware

This group includes all CMs that are in the EM’s interlock list.

ID Condition Action Severity Latch Description
1 Custom N/A N/A N/A Custom condition set by CM class logic
2 Custom N/A N/A N/A Custom condition set by CM class logic
3 Custom N/A N/A N/A Custom condition set by CM class logic
4 I/O Fault Perm None

 

No An I/O module or channel is reporting a fault
5 Invalid Feedback Trip Critical No Feedback inputs do not agree with CM status
6 Blown Activation Fuse Trip Critical Yes The CM logic is scanned more frequently when its active but due to program errors it may stop scanning all together so this protects the system under those circumstances.  This is latched because it is sometimes very fleeting.  This is suspended if a Communication Fault exists for the CM controller.
7 Failed to Begin Activation
8 Failed to Activate
9 Lost Activation
10 Blown Deactivate Fuse
11 Failed to Begin Deactivation
12 Failed to Deactivate
13 Lost Deactivation
14 No Power Air, Volts, Current, Disconnect
15 Fault Overload, Drive Fault

Total possible Interlock CM conditions = 720, 60 likely, 20 active

 

Process

Typically there is a source unit but there may also be many or no source units.  But always there will be only 1 active source, if any, and the reset inactive.  None of the conditions listed below apply to inactive units.

ID Condition Action Severity Latch Description
1 Custom N/A N/A N/A Custom condition configured by user via expressions.
2 Custom Perm None

 

No EMs will not be allowed to start if the source is empty or has other issues.
3 Custom Perm Warning No This condition is just a warning that the Tank is almost empty  so no new EM’s may start but running ones may continue.  This is not much different than the Empty condition except it raises an alarm.
4 EM Not Scanning

 

Trip Critical No EM is not scanning this CM when acquired
5 Interlocked Perm None No CM is interlocked by EM
6 Process Low Warning

 

Fault Warning No Notification received that a low process condition warning was triggered
7 Process Low Critical Trip* Critical Yes *This alarm is only active for Transfer class EMs since they depend on the source unit’s level.
8 Process High Warning Fault Warning No This condition is an indication that the source unit has a fault condition but it may not affect this EM.
9 Process High Critical
10 Alarm Alarm Input, VFD Alarm (ex: High Current)
11 Owned Tripped
12 Owned Faulted
13 Owned Not Ready
14 Owned Unavailable
15 Instr Fault

Total possible Source conditions = 15, 8 likely, 3 active

 

Instrument Groups

The instruments only have 1 group because it has so few of alarms

 

ID Condition Action Severity Latch Description
0 Custom N/A N/A N/A Custom condition configured by user via expressions.
1 Custom N/A N/A

 

N/A Custom condition configured by user via expressions.
2 Analog Module/Channel Fault N/A Critical Yes Analog Channel or Module is faulted
3 Wire Break

 

N/A Critical No Analog Channel Wire Break Detected
4 Under Range N/A Critical No Analog Channel is below measured range
5 Over Range

 

N/A Critical No Analog Channel is above measure range
6 Digital Module Fault N/A Critical Digital Input Module Fault
7 Above EU Max N/A Warning No Analog Value is above Engineering Unit Max
8 Below EU Min N/A Warning Analog Value is below Engineering Unit Min
9 Bad Quality N/A Critical Yes Analog / Digital inputs do not agree
10 Spare
11 Process High Critical N/A Critical Configured Process Alarm is Critically High
12 Process Low Critical N/A Critical Configured Process Alarm is Critically Low
13 Process High Warning N/A Warning Configured Process Alarm is High
14 Process Low Warning N/A Warning Configured Process Alarm is Low

 

 

Vessel Groups

The Vessels only have 1 group because it has so few of alarms

 

ID Condition Action Severity Latch Description
0 Custom N/A N/A N/A Custom condition configured by user via expressions.
1 Receive Custom N/A N/A

 

N/A Custom condition configured by user via expressions.
4 Process Receive Warning N/A Warning Configured Process Alarm is High
5 Process Receive Critical N/A Critical Configured Process Alarm is Critically High
6 Spare
7 Send Custom Custom Condition Configured by User
6 Process Send Warning N/A Warning Configured Process Alarm is Low
9 Process Send Critical N/A Critical Configured Process Alarm is Critically Low

 

 

Alarms

Configurable process alarms are also managed by the ACM.  The alarms just trigger the condition but it is up to the ACM to recognize the condition, format the condition message and add it to the Historical Logs

 

Condition Handling

Each scan all conditions will monitored and added to an Active Conditions list. The Active Conditions list will be merged with the Current Conditions list to create a new Current Conditions and an Incoming Conditions and an Outgoing Conditions. The Incoming and Outgoing Conditions lists will be used to manage the Alarms and Historical Logging.

 

Total possible conditions = 1270

Likely conditions = 135

Most Likely active conditions = 50

Realistic active conditions under abnormal conditions < 10

 

  • Active Conditions – {temporary} acmActConds[100]
  • Incoming Conditions – {temporary} acmInConds[20]
  • Outgoing Conditions – {temporary} acmOutConds[20]
  • Current Conditions – ACM.Crnt[20]

 

Due to the amount of memory each condition takes to record, and to the unlikely event that very many conditions will exist simultaneously, only 20 conditions will be tracked at a time.  The ACM will track the most relevant condition message based on action and severity, it will also set the interface tags such as Trip or Fault regardless of if the condition is tracked.  However, only the 1st 20 conditions will be tracked and viewable in the EM-ACM tab, the summary and the historical log.

 

PROBLEM: CANNOT STORE TEXT WITH EACH CONDITION BECAUSE IT IS WAY TOO MUCH MEMORY TO STORE IN ARRAY WHICH IS LIMITED TO 2MB.

 

Instead I could store the EM ID and Object Type and Object ID which could be used to build the message.  Then build and store the messages into the Historical Logging and Alarm And Event Server.  And the top 10 condition messages.

That is a lot of extra work and would be nice if I could just keep the messages intact. Maybe I could reduce the message size or maybe only allow 20 active alarms instead of 100.

 

When should the EM name be appended to the alarm message?  Initially I don’t want it because when its displayed in the EM faceplate or phase then it’s unnecessary.  Only when it’s displayed in the Unit, which prefixes the messages anyway, or displayed in the alarm which is a separate area, is it required.  So that reduces it to 32 characters leaving 16 for the EM name to make it 48.

 

So a maximum of 20 abnormal conditions of 48 characters may be allowed at any given time.  What happens if there are more?  The active conditions could still be more thus still tripping the EM.  The probability that the EM is still operating with 20 conditions is not possible and with that many conditions it is not practical to evaluate so it’s just information overload.  Therefore, after that point it will no longer record any conditions but it will still set the appropriate EM Trip and/or Fault or Perm conditions.

 

The EM general message should only show the generic message like “1 or more CMs are in manual mode”.  The ACM tab would show each individual CM that is in manual mode up to 20.  If there are more than 20 then the HMI could display … in the last area to indicate that but again this couldn’t be that important.   As long as the EM trips that is the important thing.  The historical log cannot work because there will be no information to detect incoming or outgoing for those conditions.  The Alarm & Event server also wouldn’t work since it works on the same principle but not a FIFO.

 

Condition Messages

A condition message will be in the following format: uuu…uuu.eee…eee: ccc…ccc { } ccc…ccc

Where: u = Unit Name        (16 chars)                                   16c    +      16c    +    32c + 16c   = 80 char.

e = EM Name         (16 chars)

c = Condition Text (32 chars)

{ } = Object Name   (16 chars)

 

The EM’s ACM will store only the ccc…ccc {} ccc…ccc part of the message.  The unit or phase will append the EM name to the message as a prefix followed by a colon (:).   The Alarm and Event summary and historical log will prefix the message with both the Unit name and EM name separated by a period (.).   Each name adds 16 characters to the original message which is limited to 32 characters (48 counting the object name).

 

Configuration

 

 

Process Conditions

Each process condition holds its own Condition state and therefore needs to set or clear the alarm as it is scanned.

Each condition may have a trigger expression or maybe triggered externally by custom logic

 

 

Exceptions

 

Create a table similar to the Security table where exceptions to the AC can be created on any object at any level.

 

 

Abnormal Condition Propagation

A new idea for abnormal condition propagation is to convert all abnormal conditions into 1 of a set of standard conditions and then send those up the chain.

 

Currently each level of hardware and process controls has its own abnormal condition (AC) monitoring for specific conditions.  For example: an instrument checks for extreme high and sets the appropriate condition.  The vessel containing that instrument also checks the instrument for extreme high and sets its own condition.  Finally, the EM containing the vessel or instrument monitor for its extreme high and sets its own condition.

 

While this method allows for a very fine level of control it doesn’t inherit or take advantage of configuration at the lower level for the upper level.

 

A different approach would be to allow the condition to be configured at the lower level and propagate up.  For example:  The tank overflow condition could be configured as a trip high condition in the instrument.  This trip condition could be monitored by the vessel containing the level which would cause it to remove its clear to receive (CTR).  The vessel wouldn’t know why its tripping but only that the instrument its monitoring for level had a trip high.  Any EM would also trip because the destination vessel is not CTR.

 

Question: How does the EM report why it tripped?

  1. Since it tripped due to the vessel it will look to the vessel for an explanation.  So the vessel would have to record the instruments AC message and set it as its own message along with the instruments name.  The EM then displays the vessel’s message as its own along with the vessel name.  CMs overridden could also adopt the Vessel message as why they are overridden.
  2. The EM could be tripped not due to the vessel CTR but due to the vessel Level overflowing so in this case the EM is looking through the vessel at its level instrument and monitors its Trip High condition directly and therefore reads the instruments Message as its own.  The problem with this method is that it would only stop the EM from sending material to the vessel.  However, CMs should also be tripped in case they are being controlled indirectly.

Option 1 above Question: If any high trip on the vessel’s instruments causes the vessel to remove its CTR should the vessel also replace the CTR as a High Trip, High Fault, High Perm?  Should the various instrument High Trip/Fault actions and severity be configurable such that a vessel could ignore or override the action?  The problem with overriding the actions is that they are all combined so the vessel has no way of knowing why the level tripped unless it examines the level limits but that is still an assumption. Examining the level limits defeats the whole propagation purpose.  Leaving it up to the lower level also has another issue in that it may be desired to trip 1 higher level EM but not another.  If the higher objects cannot override the condition then they all trip.  One way to get around this is to not set the trip condition on the lower object and then on the 1 higher object that needs to trip just define a direct condition but then again which should be done.

Updated on December 6, 2018

Related Articles

Password Protected