BlockSim 8: State Change Triggers - Revision history

Lisa Hacker: Redirected page to State Change Triggers

2012-08-02T03:10:14Z

Redirected page to State Change Triggers

← Older revision		Revision as of 03:10, 2 August 2012
Line 1:		Line 1:
	==State Change Triggers ==		#REDIRECT [[State Change Triggers]]
	~~=== Description ===~~


	*Standard blocks can have state change triggers enabled by checking "Enable State Change Triggers (SCT)" property in a standard block/event properties.
	*When a block has state change triggers enabled, it can be set to start each simulation in an OFF state. In this case, unless some event turns the block ON, the block will remain down for the entire simulation.
	*The user can turn a block ON that is in an OFF state by adding state change trigger: If any item from these associated maintenance group(s) GOES DOWN then ACTIVATE this block; or if any item from these associated maintenance group(s) IS RESTORED then ACTIVATE this block.
	*The user can turn a block OFF that is in an ON state by adding state change trigger: If any item from these associated maintenance group(s) GOES DOWN then DEACTIVATE this block; or if any item from these associated maintenance group(s) IS RESTORED then DEACTIVATE this block.
	*This feature allows to mimic standby containers in COLD standby. However, blocks do not have to be in a parallel configuration so additional flexibility is allowed from traditional containers. In addition, maintenance groups can be associated with subdiagram blocks so that complex standby configurations can be modeled.
	*State change triggesr also allow modeling dependent shut downs.
	*Upon restoration of a Block, the user must select between one of the following State Upon Repair choices: Always On, Always Off, Default On Unless SCT Overridden, Default Off Unless SCT Overridden

	~~=== Assumptions ===~~

	*A block cannot trigger events on itself. For example if Block 1 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 associated with downing events of block 1, directly. The necessary for this restriction is that, OFF_Events triggers other events will have circular references problem. For example, four blocks A, B, C and D are in parallel. Block A belongs to MG A and initally it is ON. Block B belongs to MG B and its intial 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 OFF_Event of Block D can turn Block B ON, and On_Event of Block B will turn Block C OFF, and OFF_Event of Block C will turn Block D ON, then there is a circular references problem. Thus we assume that OFF_Events cannot trigger other events.
	*Blocks activated when they where OFF, cannot trigger events. This is to avoid circular references.
	*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
	*Maintenances while block is off: Maintenances 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 putting 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 have event trigger enable, it will be actived when Block B fails and it will be deactived 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, requst from Block C at 40 will cancel the request from Block B at 30. Thus finally only requst from Block C will be considered. Thus Block A will be turned OFF at 70 when it is done with repair.

	~~=== [http://www.reliawiki.org/index.php?title=Category:BlockSim_Examples&action=edit&redlink=1 State Change Trigger Examples~~] ~~===~~

Dingzhou Cao at 22:17, 25 July 2011

2011-07-25T22:17:00Z

← Older revision		Revision as of 22:17, 25 July 2011
Line 25:		Line 25:
	*If there are multiple triggering requests putting 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 have event trigger enable, it will be actived when Block B fails and it will be deactived 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, requst from Block C at 40 will cancel the request from Block B at 30. Thus finally only requst from Block C will be considered. Thus Block A will be turned OFF at 70 when it is done with repair.		*If there are multiple triggering requests putting 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 have event trigger enable, it will be actived when Block B fails and it will be deactived 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, requst from Block C at 40 will cancel the request from Block B at 30. Thus finally only requst from Block C will be considered. Thus Block A will be turned OFF at 70 when it is done with repair.

	=== [http://www.reliawiki.org/index.php?title=Category:BlockSim_Examples&action=edit&redlink=1 Examples] ===		=== [http://www.reliawiki.org/index.php?title=Category:BlockSim_Examples&action=edit&redlink=1 State Change Trigger Examples] ===

Dingzhou Cao at 22:16, 25 July 2011

2011-07-25T22:16:42Z

← Older revision		Revision as of 22:16, 25 July 2011
Line 25:		Line 25:
	*If there are multiple triggering requests putting 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 have event trigger enable, it will be actived when Block B fails and it will be deactived 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, requst from Block C at 40 will cancel the request from Block B at 30. Thus finally only requst from Block C will be considered. Thus Block A will be turned OFF at 70 when it is done with repair.		*If there are multiple triggering requests putting 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 have event trigger enable, it will be actived when Block B fails and it will be deactived 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, requst from Block C at 40 will cancel the request from Block B at 30. Thus finally only requst from Block C will be considered. Thus Block A will be turned OFF at 70 when it is done with repair.

	=== ~~Examples ===~~		=== [http://www.reliawiki.org/index.php?title=Category:BlockSim_Examples&action=edit&redlink=1 Examples] ===
	~~Examples for state change trigger can be found here:~~

	http://www.reliawiki.org/index.php?title=Category:BlockSim_Examples&action=edit&redlink=1

Dingzhou Cao: /* Examples */

2011-07-25T22:11:58Z

Examples

← Older revision		Revision as of 22:11, 25 July 2011
Line 26:		Line 26:

	=== Examples ===		=== Examples ===
	Examples for state ~~triggers~~ can be found here:		Examples for state change trigger can be found here:

	http://www.reliawiki.org/index.php?title=Category:BlockSim_Examples&action=edit&redlink=1		http://www.reliawiki.org/index.php?title=Category:BlockSim_Examples&action=edit&redlink=1

Dingzhou Cao: /* State Change Triggers */

2011-07-25T22:11:38Z

State Change Triggers

← Older revision		Revision as of 22:11, 25 July 2011
Line 24:		Line 24:
	*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.		*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 putting 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 have event trigger enable, it will be actived when Block B fails and it will be deactived 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, requst from Block C at 40 will cancel the request from Block B at 30. Thus finally only requst from Block C will be considered. Thus Block A will be turned OFF at 70 when it is done with repair.		*If there are multiple triggering requests putting 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 have event trigger enable, it will be actived when Block B fails and it will be deactived 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, requst from Block C at 40 will cancel the request from Block B at 30. Thus finally only requst from Block C will be considered. Thus Block A will be turned OFF at 70 when it is done with repair.

			=== Examples ===
			Examples for state triggers can be found here:

			http://www.reliawiki.org/index.php?title=Category:BlockSim_Examples&action=edit&redlink=1

Dingzhou Cao: /* Description */

2011-07-25T22:08:37Z

Description

← Older revision		Revision as of 22:08, 25 July 2011
Line 10:		Line 10:
	*State change triggesr also allow modeling dependent shut downs.		*State change triggesr also allow modeling dependent shut downs.
	*Upon restoration of a Block, the user must select between one of the following State Upon Repair choices: Always On, Always Off, Default On Unless SCT Overridden, Default Off Unless SCT Overridden		*Upon restoration of a Block, the user must select between one of the following State Upon Repair choices: Always On, Always Off, Default On Unless SCT Overridden, Default Off Unless SCT Overridden

			=== Assumptions ===

			*A block cannot trigger events on itself. For example if Block 1 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 associated with downing events of block 1, directly. The necessary for this restriction is that, OFF_Events triggers other events will have circular references problem. For example, four blocks A, B, C and D are in parallel. Block A belongs to MG A and initally it is ON. Block B belongs to MG B and its intial 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 OFF_Event of Block D can turn Block B ON, and On_Event of Block B will turn Block C OFF, and OFF_Event of Block C will turn Block D ON, then there is a circular references problem. Thus we assume that OFF_Events cannot trigger other events.
			*Blocks activated when they where OFF, cannot trigger events. This is to avoid circular references.
			*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
			*Maintenances while block is off: Maintenances 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 putting 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 have event trigger enable, it will be actived when Block B fails and it will be deactived 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, requst from Block C at 40 will cancel the request from Block B at 30. Thus finally only requst from Block C will be considered. Thus Block A will be turned OFF at 70 when it is done with repair.

Dingzhou Cao: /* Description */

2011-07-25T22:07:01Z

Description

← Older revision		Revision as of 22:07, 25 July 2011
Line 1:		Line 1:
	==State Change Triggers ==		==State Change Triggers ==
	=== Description ===		=== Description ===


	*Standard blocks can have state change triggers enabled by checking "Enable State Change Triggers (SCT)" property in a standard block/event properties.		*Standard blocks can have state change triggers enabled by checking "Enable State Change Triggers (SCT)" property in a standard block/event properties.
	*When a block has state change triggers enabled, it can be set to start each simulation in an OFF state. In this case, unless some event turns the block ON, the block will remain down for the entire simulation.		*When a block has state change triggers enabled, it can be set to start each simulation in an OFF state. In this case, unless some event turns the block ON, the block will remain down for the entire simulation.
	*The user can turn a block ON that is in an OFF state by ~~associating a maintenance group with the options "Activate when an~~ item ~~in the~~ maintenance group ~~goes down"~~ or ~~"Activate when an~~ item ~~in the~~ maintenance group ~~is restored"~~		*The user can turn a block ON that is in an OFF state by adding state change trigger: If any item from these associated maintenance group(s) GOES DOWN then ACTIVATE this block; or if any item from these associated maintenance group(s) IS RESTORED then ACTIVATE this block.
	*The user can turn a block OFF that is in an ON state by ~~associating a maintenance group with the options "Deactivate when an~~ item ~~in the~~ maintenance group ~~goes down"~~ or ~~"Deactivate when an~~ item ~~in the~~ maintenance group ~~is restored"~~		*The user can turn a block OFF that is in an ON state by adding state change trigger: If any item from these associated maintenance group(s) GOES DOWN then DEACTIVATE this block; or if any item from these associated maintenance group(s) IS RESTORED then DEACTIVATE this block.
	*This feature allows to mimic standby containers in COLD standby. However, blocks do not have to be in a parallel configuration so additional flexibility is allowed from traditional containers. In addition, maintenance groups can be associated with subdiagram blocks so that complex standby configurations can be modeled.		*This feature allows to mimic standby containers in COLD standby. However, blocks do not have to be in a parallel configuration so additional flexibility is allowed from traditional containers. In addition, maintenance groups can be associated with subdiagram blocks so that complex standby configurations can be modeled.
	*State change triggesr also allow modeling dependent shut downs.		*State change triggesr also allow modeling dependent shut downs.
	*Upon restoration of a Block, the user must select between one of the following State Upon Repair choices: Always On, Always Off, Default On Unless SCT Overridden, Default Off Unless SCT Overridden		*Upon restoration of a Block, the user must select between one of the following State Upon Repair choices: Always On, Always Off, Default On Unless SCT Overridden, Default Off Unless SCT Overridden

Dingzhou Cao: /* Description */

2011-07-25T22:00:11Z

Description

← Older revision		Revision as of 22:00, 25 July 2011
Line 1:		Line 1:
	==State Change Triggers ==		==State Change Triggers ==
	=== Description ===		=== Description ===

			*Standard blocks can have state change triggers enabled by checking "Enable State Change Triggers (SCT)" property in a standard block/event properties.
			*When a block has state change triggers enabled, it can be set to start each simulation in an OFF state. In this case, unless some event turns the block ON, the block will remain down for the entire simulation.
			*The user can turn a block ON that is in an OFF state by associating a maintenance group with the options "Activate when an item in the maintenance group goes down" or "Activate when an item in the maintenance group is restored"
			*The user can turn a block OFF that is in an ON state by associating a maintenance group with the options "Deactivate when an item in the maintenance group goes down" or "Deactivate when an item in the maintenance group is restored"
			*This feature allows to mimic standby containers in COLD standby. However, blocks do not have to be in a parallel configuration so additional flexibility is allowed from traditional containers. In addition, maintenance groups can be associated with subdiagram blocks so that complex standby configurations can be modeled.
			*State change triggesr also allow modeling dependent shut downs.
			*Upon restoration of a Block, the user must select between one of the following State Upon Repair choices: Always On, Always Off, Default On Unless SCT Overridden, Default Off Unless SCT Overridden

Dingzhou Cao: /* State Change Triggers */

2011-07-25T21:59:44Z

State Change Triggers

← Older revision		Revision as of 21:59, 25 July 2011
Line 1:		Line 1:
	==State Change Triggers ==		==State Change Triggers ==
			=== Description ===

Dingzhou Cao: Created page with '==State Change Triggers =='

2011-07-25T21:59:22Z

Created page with '==State Change Triggers =='

New page

==State Change Triggers ==