State Change Triggers

This article also appears in the System Analysis Reference book.

Consider a case where you have two generators, and one (A) is primary while the other (B) is standby. If A fails, you will turn B on. When A is repaired, it then becomes the standby. State change triggers (SCT) allow you to simulate this case. You can specify events that will activate and/or deactivate the block during simulation. The figure below shows the options for state change triggers in the Block Properties window.

Once you have enabled state change triggers for a block, there are several options.

• Initial state allows you to specify the initial state for the block, either ON or OFF.
• State upon repair allows you to specify the state of the block after its repair. There are four choices: Always ON, Always OFF, Default ON unless SCT Overridden and Default OFF unless SCT Overridden. In the Assumptions sections, we will explain what these choices mean and illustrate them using an example.
• Add a state change trigger allows you to add a state change trigger to the block.

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. Note that the current block does not need to be part of the specified maintenance group(s) to use this functionality.

The State Change Trigger window is shown in the figure below:

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. For example, four blocks A, B, C and D are in parallel. Block A belongs to MG A and initially it is ON. Block B belongs to MG B and its initial status is also ON. Block C belongs to MG C and its initial status is OFF. Block D belongs to MG D and its initial status is ON. A failure of Block A will turn OFF Block B. Then Block B will turn Block C ON and finally C will turn OFF Block D. However, if an OFF event for Block D will turn Block B ON, and an ON event for Block B will turn Block C OFF, and an OFF event for Block C will turn Block D ON, then there is a circular reference problem.
• 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: The state of a block (on/off) will be determined at the beginning of each phase based on the "Initial state" setting of the block for that phase.
• 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.

Example: State Upon Repair

Consider an example in which there are two generators. A is the primary generator and B is a standby. If A fails, B is turned ON. Further assume that A fails every 10 hours and gets repaired in 3 hours. B fails every 20 hours and cannot be repaired. State change triggers can be used to model this example.

Case 1

• Block A belongs to Maintenance Group A. In "Enable state change triggers(SCT)," "Initial State" is ON and "State upon repair" is "Always ON." A state change trigger is added to Block A: If B goes down, then activate this block.
• Block B belongs to Maintenance Group B. In "Enable state change triggers(SCT)," "Initial State" is OFF and "State upon repair" is "Always ON." A state change trigger is added to Block B: If A goes down, then activate this block.

We run one simulation with an end time of 20 hours. The system event log plot is shown in the figure below.

From the figure, we can see that Block A fails at 10 hours and Block B is activated at the same time. At 13 hours, Block A is restored and according to the "State upon repair" setting, it is ON. In this case, from 13 hours to 20 hours, both generators are running. Perhaps we feel that it is not economical to run both generators at the same time; if one is running, we should set the other one as standby. Thus after Block A is repaired, we would prefer for it to stay as a standby. This leads to Case 2 next.

Case 2

Everything is the same as in Case 1 except for two changes, as follows:

• The "State upon repair" for the state change trigger on Block A is changed from "Always ON" to "Always OFF."
• Block B fails every 2 hours and never get repaired.

We run one simulation with an end time of 20 hours. The system event log plot is shown in the figure below.

From the plot above, we can see that, as we expected, Block A will become a standby after its repair at 13 hours. However, another problem arises. In Case 1, Block B fails every 20 hours. In this case, it fails every 2 hours. Thus, before A is repaired, Block B fails at 12 hours. However, Block A is down at 12 hours, thus cannot be activated by failure of Block B. Due to this, the failure of Block B brings the system down all the way to the end of the simulation. This is not desirable. In Case 3, we address this.

Case 3

Everything is the same as in Case 2 except for the following change:

• The "State upon repair" for the state change trigger on Block A is changed to "Default OFF unless SCT overridden".

We run one simulation with an end time of 20 hours. The system event log plot is shown in the figure below.

From the plot above, we can see that at 12 hours, when Block B fails, it tries to activate Block A. However, at this time, Block A is down for repair. At 13 hours, the repair on Block A is finished and, according to the "State upon repair" setting, the block's state upon repair is overridden by the trigger sent by Block B at 12 hours. Thus Block A is ON after its repair. This is the kind of scenario we expected.

The option "Default ON unless SCT overridden" is similar to "Default OFF unless SCT overridden"; it means that the default state upon repair for a block is ON. However, it can be overridden by a trigger to change the state upon repair to "OFF."

More State Change Trigger Examples

Using SCT for Standby Rotation

See it in action...

More application examples are available! See also:

• Default OFF Unless SCT Overridden
• Default ON Unless SCT Overridden

This example illustrates the use of state change triggers in BlockSim (Version 8 and above) by using a simple standby configuration. Note that this example could also be done using the standby container functionality in BlockSim.

More specifically, the following settings are illustrated:

1. State Upon Repair: Default OFF unless SCT overridden
2. Activate a block if any item from these associated maintenance group(s) goes down
   

Problem Statement

Assume three devices A, B and C in a standby redundancy (or only one unit is needed for system operation). The system begins with device A working. When device A fails, B is turned on and repair actions are initiated on A. When B fails, C is turned on and so forth.

BlockSim Solution

The BlockSim model of this system is shown in the figure below.

• The failure distributions of all three blocks follow a Weibull distribution with Beta = 1.5 and Eta = 1,000 hours.
• The repair distributions of the three blocks follow a Weibull distribution with Beta = 1.5 and Eta = 100 hours.
• After repair, the blocks are "as good as new."

There are three maintenance groups, 2_A, 2_B and 2_C, set as follows:

• Block A belongs to maintenance group 2_A.
  • It has a state change trigger.
    • The initial state is ON and the state upon repair is "Default OFF unless SCT overridden."
    • If any item from maintenance group 2_C goes down, then activate this block.

• Block B belongs to maintenance group 2_B.
  • It has a state change trigger.
    • The initial state is OFF and the state upon repair is "Default OFF unless SCT overridden."
    • If any item from maintenance group 2_A goes down, then activate this block.

• Block C belongs to maintenance group 2_C.
  • It has a state change trigger.
    • The initial state is OFF and the state upon repair is "Default OFF unless SCT overridden."
    • If any item from maintenance group 2_B goes down, then activate this block.

• All blocks A, B and C are as good as new after repair.

System Events

The system event log for a single run through the simulation algorithm is shown in the Block Up/Down plot below, and is as follows:

1. At 73 hours, Block A fails and activates Block B.
2. At 183 hours, Block B fails and activates Block C.
3. At 215 hours, Block B is done with repair. At this time, Block C is operating, so according to the settings, Block B is standby.
4. At 238 hours, Block A is done with repair. At this time, Block C is operating. Thus Block A is standby.
5. At 349 hours, Block C fails and activates Block A.
6. At 396 hours, Block A fails and activates Block B.
7. At 398 hours, Block C is done with repair. At this time, Block B is operating. Thus Block C is standby.
8. At 432 hours, Block A is done with repair. At this time, Block B is operating. Thus Block A is standby.
9. At 506 hours, Block B fails and activates Block C.
10. At 515 hours, Block B is done with repair and stays standby because Block C is operating.
11. At 536 hours, Block C fails and activates Block A.
12. At 560 hours, Block A fails and activates Block B.
13. At 575 hours, Block B fails and makes a request to activate Block C. However, Block C is under repair at the time. Thus when Block C is done with repair at 606 hours, the OFF setting is overridden and it is operating immediately.
14. At 661 hours, Block C fails and makes a request to activate Block A. However, Block A is under repair at the time. Thus when Block A is done with repair at 699 hours, the OFF setting is overridden and it is operating immediately.
15. Block B and Block C are done with repair at 682 hours and at 746 hours respectively. However, at these two time points, Block A is operating. Thus they are both standby upon repair according to the settings.

Using SCT to Analyze Tire Maintenance

Consider a car with four regular tires (RF, LF, RR, LR) and a spare tire (SP). Assume that each tire can fail based on two failure modes, wear and puncture, and:

• The wear failure mode follows a Weibull distribution with Beta = 1.5, Eta = 600 hours.
• The puncture failure mode follows an exponential distribution with a mean of 2 months.
• Regardless of the failure mode, the repair duration (of both wear and puncture) follows a Weibull distribution with Beta = 1.5,Eta = 100 hours.
• If the tire fails due to wear, the tire is replaced with a new one (wear is repaired as-good-as-new).
• If the tire fails due to a puncture, it is patched up and placed back into service (repaired as-bad-as-old).
• When a primary tire (RF, LF, RR or LR) fails, it is replaced with the spare (SP) until that tire is restored. Once restored, the tire is put back in its original position and the spare is removed and put back for later use.

The purpose of this example is to illustrate the following options in State Change Triggers (SCT):

1. State Upon Repair: Always ON, Always OFF
2. Activate a block if any item from these associated maintenance group(s) goes down
3. Deactivate a block if any item from these associated maintenance group(s) is restored
4. Deactivate a block if any item from these associated maintenance group(s) goes down
5. Activate a block if any item from these associated maintenance group(s) is restored

BlockSim Solution

• To model this system, six diagrams are created: Car, Tire_LF, Tire_LR, Tire_RF, Tire_RR and Tire_SP with Car being the main diagram. Create the diagrams as follows:

1. First create diagram Tire_LF with two blocks in series. Block Wear_LF represents the Wear failure mode and Puncture_LF represents the Puncture failure mode for Tire_LF respectively.
   1. Block Wear_LF belongs to maintenance group "Wear_LF" and Block Puncture_LF belongs to maintenance group "Puncture_LF."
   2. Block Wear_LF has state change triggers; its initial state is ON, and the state upon repair is "Always ON." If any item from maintenance group "Puncture_LF" goes down, deactivate this block and if any item from maintenance group "Puncture_LF" is restored, activate this block.
   3. Block Puncture_LF has state change triggers; its initial state is ON, and the state upon repair is "Always ON." If any item from maintenance group "Wear_LF" goes down, deactivate this block and if any item from maintenance group "Wear_LF" is restored, activate this block.
      
2. Create the other three diagrams (Tire_LR, Tire_RF and Tire_RR) following the same logic.
3. In diagram Tire_SP, there are two blocks in series. Block Wear_SP represents the Wear failure mode and Puncture_SP represents the Puncture failure mode for the spare tire. Block Wear_SP belongs to maintenance group "Wear_SP" and Block Puncture_SP belongs to maintenance group "Puncture_SP."
   1. Block Wear_SP has state change triggers; its initial state is OFF, and the state upon repair is "Always OFF." If any item from maintenance group "Puncture_SP" goes down, deactivate this block and if any item from maintenance group "Puncture_SP" is restored, activate this block. If any item from maintenance group "Main Tires" goes down, activate this block and if any item from the maintenance group "Main Tires" is restored, deactivate this block. 
   2. Block Puncture_SP has state change triggers; its initial state is OFF, and the state upon repair is "Always OFF." If any item from maintenance group "Wear_SP" goes down, deactivate this block and if any item from maintenance group "Wear_SP" is restored, activate this block. If any item from maintenance group "Main Tires" goes down, activate this block and if any item from the maintenance group "Main Tires" is restored, deactivate this block.
      
4. In the diagram Car, there are five subdiagram blocks Tire_LF, Tire_LR, Tire_RF, Tire_RR and Tire_SP (each referencing/pointing to the diagram with the same names).
   1. In diagram Car, subdiagram blocks Tire_LF, Tire_LR, Tire_RF and Tire_RR belong to maintenance group "Main Tires."

Blocks Up/Down Plot

The system event log is shown in the figure below and is as follows (only blocks with failures are plotted):

1. At 46 hours, Block Wear_LR fails and brings down subdiagram Tire_LR. At the same time, it turns Block Puncture_LR OFF. Subdiagram Tire_LR goes down and activates Block Wear_SP and Puncture_SP, and subdiagram Spare is turned ON, too.
   
2. At 184 hours, Block Wear_LR is done with repair. According to the settings, it is always ON upon repair (is restored). The restoration of Block Wear_LR activates Block Puncture_LR and thus subdiagram Tire_LR is ON. The restoration of subdiagram Tire_LR deactivates Block Wear_SP and Puncture_SP, and subdiagram Tire_SP is turned OFF, too.
   
3. At 375 hours, Block Wear_RF fails and brings down subdiagram Tire_RF. At the same time, it turns Block Puncture_RF OFF. Subdiagram Tire_RF goes down and activates Block Wear_SP and Puncture_SP, and subdiagram Tire_SP is turned ON, too.
   
4. At 445 hours, Block Wear_RF is done with repair. According to the settings, it is always ON upon repair. The restoration of Block Wear_RF activates Block Puncture_RF and thus subdiagram Tire_RF is ON. The restoration of subdiagram Tire_RF deactivates Block Wear_SP and Puncture_SP, and subdiagram Tire_SP is turned OFF, too.
   
5. At 536 hours, Block Wear_LR fails again and brings down subdiagram Tire_LR. At the same time, it turns Block Puncture_LR OFF. Subdiagram Tire_LR goes down and activates Block Wear_SP and Puncture_SP, and the subdiagram Tire_SP is turned ON, too.
6. At 572 hours, Block Puncture_SP fails and brings down subdiagram Tire_SP. At the same time, it turns Block Wear_SP OFF. Subdiagram Tire_LR is already down at this time. Thus the system is down.
7. At 602 hours, Block Wear_LR is done with repair. According to the settings, it is always ON upon repair. The restoration of Block Wear_LR activates Block Puncture_LR and thus subdiagram Tire_LR is ON. The restoration of subdiagram Tire_LR should deactivate Block Wear_SP and Puncture_SP. However, Wear_SP is already OFF and Puncture_SP is already down at this time, thus nothing happens. The system is ON at this time due to the restoration of subdiagram Tire_LR.
8. At 617 hours, Block Puncture_SP is done with repair. According to the settings, it is always OFF upon repair.
9. At 686 hours, Block Puncture_LR fails and brings down subdiagram Tire_LR. At the same time, it turns Block Wear_LR OFF. Subdiagram Tire_LR goes down and activates Block Wear_SP and Puncture_SP, and the subdiagram Tire_SP is turned ON, too.
10. At 718 hours, Block Puncture_LR is done with repair. According to the settings, it is always ON upon repair. The restoration of Block Puncture_LR actives Block Wear_LR and thus subdiagram Tire_LR is ON. The restoration of subdiagram Tire_LR deactivates Block Wear_SP and Puncture_SP, and the subdiagram Tire_SP is turned OFF, too.

Using SCT to Model Standby with Delay

The purpose of this example is to illustrate how to model standby with delay using State Change Triggers (SCT).

Problem Statement

Three devices A, B and C are in parallel. 2 out of 3 are required to perform the task. Initially A and B are working and C is in standby status. If A or B fails, C will replace the failed one with some delay. After the failed device is restored, it will become a standby device. For example, if A fails, with 10 hours delay C will become active and replace A. After A is restored, it will become a standby device for B and C.

BlockSim Solution

The BlockSim modeling of this system is shown in the figure below.

In order to model the delay, three extra blocks AA, BB and CC are added to the diagram. Each of them fails every 10 hours (normal distribution with mean 10 hours and standard deviation 0.0000001 hours). They operate even if the system is down and repair durations for them are 0 (immediate repair). Block AA(BB/CC) belongs to maintenance group AA(BB/CC). They all have state change triggers. The initial state for each is OFF and the state upon repair is "Always OFF." If Block A (B/C) goes down, then activate Block AA (BB/CC).

Block A fails every 100 hours. It belongs to maintenance group A. It has state change triggers. The initial state is ON; the state upon repair is "Default OFF unless SCT overridden." If Block BB or Block CC goes down, Block A is activated.

Block B fails every 200 hours. It belongs to maintenance group B. It has state change triggers. The initial state is ON; the state upon repair is "Default OFF unless SCT overridden." If Block AA or Block CC goes down, Block B is activated.

Block C fails every 300 hours. It belongs to maintenance group C. It has state change triggers. The initial state is OFF; the state upon repair is "Default OFF unless SCT overridden." If Block BB or Block AA goes down, Block C is activated.

The repair duration for Blocks A, B and C is 30 hours.

Block Up/Down Plot

The system event log is shown in the figure below and is as follows:

1. At 100 hours, Block A fails and activates Block AA.
2. At 110 hours, Block AA fails and activates Block C.
3. At 230 hours, Block B fails and activates Block BB.
4. At 240 hours, Block BB fails and activates Block A.
5. At 340 hours, Block A fails and activates Block AA.
6. At 350 hours, Block AA fails and activates Block B.
7. ...

Using SCT to Model Two Standby Devices

The purpose of this example is to illustrate how to use state change triggers (SCT) to model a system with two standby devices.

Problem Statement

Assume that there are four devices A, B, C and D in the system. The system begins with A and B as active devices and C and D as standby devices. At least 2 out of the 4 devices have to be in active status to assure that the system is working. If one of the active device fails, one of standby devices will be activated. After the active device is restored, it will become a standby device. For example, when A fails, C or D will be activated. After A finishes repair, it will become a standby device.

BlockSim Solution

It is easy to model this system with standby containers. However, standby containers have some limitations in other applications. Here we want to model this system with SCT. It is not possible to model this system directly with SCT, so we present an alternative solution which can approximate this system.

The logic is as follows: We will activate all standby devices whenever an active device fails. After activating all standby devices, we will check how many devices are in active status. If there are more than 2 devices in active status, we will deactivate some of them to assure that there are exactly two devices in active status at every moment. The drawback of this solution is that it will activate and deactivate the devices more times than we expected. For example, if A and B are active, then when A fails, it will activate C and D. After activating C and D it will detect that there are three devices in active status, so it will deactivate one of the three active devices: B, C or D. As we can see, it has the chance to deactivate B instead of C, which is not what we expected. If there is extra cost related to activation, this solution is not a good option.

In order to detect that there are more than two devices in active status, we have four subdiagram blocks: ABC, ABD, ACD and BCD. ABC contains mirror blocks A, B and C in series. The RBDs for the main diagram and subdiagram are as shown in the figures below.

Mirror group A includes Block A in the main diagram, Block A in subdiagram ABC, Block A in subdiagram ABD and Block A in subdiagram ACD.

Mirror group B includes Block B in the main diagram, Block B in subdiagram ABC, Block B in subdiagram ABD and Block B in subdiagram BCD.

Mirror group C includes Block C in the main diagram, Block C in subdiagram ABC, Block C in subdiagram BCD and Block C in subdiagram ACD.

Mirror group A includes Block D in the main diagram, Block D in subdiagram ABD, Block D in subdiagram ACD and Block D in subdiagram BCD.

All four blocks (A, B, C and D) follow a Weibull distribution with Beta = 1.5 and Eta = 100 hours for reliability and have CM with duration = 100 hours.

Block A belongs to maintenance group A. It has SCT with initial state ON and state upon repair "Default OFF unless SCT overridden." If any item from maintenance group B, C and D goes down, Block A is activated. If any item from maintenance group ABC is restored, we will deactivate Block A.

Block B belongs to maintenance group B. It has SCT with initial state ON and state upon repair "Default OFF unless SCT overridden." If any item from maintenance group A, C and D goes down, Block B is activated. If any item from maintenance group ABD is restored, we will deactivate Block B.

Block C belongs to maintenance group C. It has SCT with initial state OFF and state upon repair "Default OFF unless SCT overridden." If any item from maintenance group A, B and D goes down, Block C is activated. If any item from maintenance group ACD is restored, we will deactivate Block C.

Block D belongs to maintenance group D. It has SCT with initial state OFF and state upon repair "Default OFF unless SCT overridden." If any item from maintenance group A, B and C goes down, Block D is activated. If any item from maintenance group BCD is restored, we will deactivate Block D.

Subdiagram block ABC belongs to maintenance group ABC. The other three subdiagram blocks each belong to the maintenance group with the corresponding name.

System Events

The system event log for a single run through the simulation algorithm (simulation seed: 9)is shown in the Block Up/Down plot below, and is as follows:

1. At 26 hours, Block A fails. Block C and D are activated. However, there are three blocks in active status, thus Block D is deactivated immediately. 
2. At 126 hours, Block A finishes its repair. According to the settings, Block A is OFF as a standby device.
3. At 224 hours, Block C fails. Blocks A and D are activated. However, there are three blocks (A, B, and D) in active status, thus Block B is deactivated immediately. NOTICE: B should not be deactivated here, however we cannot control this. This is the drawback of this solution. If there is extra cost related to activation and deactivation, we are wasting resources by deactivating Block B. 
4. At 243 hours, Block A fails and activates Block B. 
5. At 248 hours, Block B fails and this failure tries to activate Blocks A and C. However, Blocks A and C are down at this time. This trigger event is on hold for Blocks A and C. After Block A and C finish their repair at 324 hours and 343 hours respectively, they are ON immediately.
6. At 343 hours, Block A finishes its repair. There is a trigger event on hold due to the failure of Block B at 248 hours. Block A is ON upon repair. At this time, there are three blocks in active status (Blocks A, C and D), thus Block C is deactivated immediately. This is another instance of wasting resources. The ideal case would be for Block A to be deactivated at this time.
7. At 408 hours, Block A fails and activates Blocks B and C. Since there are three blocks in active status, Block D is deactivated immediately to assure that only two blocks are in active status.