View source for Example Demonstrating the State Upon Repair Option for SCT

<noinclude>{{Banner BlockSim Examples}}</noinclude>
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. 

[[Image:State Change Trigger Example Case 1.png|center|450px| Behavior of system in Case 1]]

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.
[[Image:State Change Trigger Example Case 2.png|center|450px| Behavior of system in Case 2]]

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.
[[Image:State Change Trigger Example Case 3.png|center|450px|| Behavior of system in Case 3]]
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."