State Change Triggers

State change triggers (SCT) allow you to specify the starting state of a block (i.e., off or on) and its state upon repair, then specify events that will activate and/or deactivate the block during simulation. This allows you to model a cold standby configuration (i.e., one where the component cannot fail when in standby) without using a standby container, which may be useful if you are using a parallel or complex configuration, as blocks can be connected only in series in standby containers. State change triggers are available for standard blocks in simulation RBDs and for events in simulation fault trees.

The State Change Trigger window is where you specify the events that will activate and/or deactivate the block. It is accessed from the Block Properties window by clicking the Add icon in the Add a state change trigger field or the Edit icon for an existing state change trigger.

The state change trigger can either activate or deactivate the block when items in specified maintenance groups go down or are restored. To define the state change trigger, specify the triggering event (i.e., an item goes down or an item is restored), the state change (i.e., the block is activated or deactivated) and the maintenance group(s) in which the triggering event must happen in order to trigger the state change.

The current block does not need to be part of the specified maintenance group(s) to use this functionality.

Tip: Blocks that have state change triggers enabled have a diamond at the lower right corner of the block. You can change the size and color of the indicator via the relevant Block Corner Indicators page of the Diagram Style window.  

State Change Trigger Assumptions

  • A block cannot trigger events on itself. For example, if Block 1 is the only block that belongs to MG 1 and Block 1 is set to be turned ON or OFF based on MG 1, this trigger is ignored.
  • OFF events cannot trigger other events. This means that things cannot be turned OFF in cascade. For example, if Block 1 going down turns OFF Block 2 and Block 2 going down turns OFF Block 3, a failure by Block 1 will not turn OFF Block 3. Block 3 would have to be directly associated with downing events of Block 1 for this to happen. The reason for this restriction is that allowing OFF events to trigger other events can cause circular reference problems.
  • Upon restoration states:
    • Always ON: Upon restoration, the block will always be on.
    • Always OFF: Upon restoration, the block will always be off.
    • Default ON unless SCT overridden: Upon restoration, the block will be on unless a request is made to turn this block off while the block is down and the request is still applicable at the time of restoration. For example, assume Block A's state upon repair is ON unless SCT overridden. If a failure of Block B triggers a request to turn Block A off but Block A is down, when the maintenance for Block A is completed, Block A will be turned off if Block B is still down.
    • Default OFF unless SCT overridden: Upon restoration, the block will be off unless a request is made to turn this block on while the block is down and the request is still applicable at the time of restoration.
  • Maintenance while block is off: Maintenance tasks will be performed. At the end of the maintenance, "upon restoration" rules will be checked to determine the state of the block.
  • Assumptions for phases: In Versions 10 and earlier, the state of a block (on/off) was determined at the beginning of each phase based on the "Initial state" setting of the block for that phase. Starting in Version 11, the state of the block transfers across phases instead of resetting based on initial settings.
  • If there are multiple triggering requests put on a block when it is down, only the latest one is considered. The latest request will cancel all requests before it. For example, Block A fails at 20 and is down until 70. Block B fails at 30 and Block C fails at 40. Block A has state change triggers enabled such that it will be activated when Block B fails and it will be deactivated when Block C fails. Thus from 20 to 70, at 30, Block B will put a request on Block A to turn it ON and at 40, Block C will put another request to turn it OFF. In this case, according to our assumption, the request from Block C at 40 will cancel the request from Block B at 30. In the end, only the request from Block C will be considered. Thus, Block A will be turned OFF at 70 when it is done with repair.

Related Topics and Links