Process Standby Containers
A process standby container allows you to identify paths, or trains, within a PFS diagram that operate in a standby redundancy configuration. Each train in the container consists of a single starting block and a single ending block, with additional blocks between them; one or more of the trains in the container are active while one or more trains are dormant (i.e., standby or quiescent). The dormant trains are available to become active under specified circumstances. The standby container can also be configured to represent a switch that must be triggered in order to transfer the activity to the standby train (and then back to the original active train, if the standby train later fails or if the original active train is set to be reactivated after repair). Therefore, the standby container can also have an assigned switch that describes the reliability characteristics for the switch (i.e., the probability that the switch will function properly when it is needed) and any maintenance activities that apply to the switch.
To configure a process standby container, in addition to the common block properties, you will need to specify the following:
- Operation
- The Switch field allows you to create or select a switch resource, which defines the standby container as a switch that is necessary to transfer the activity from active to standby trains. The switch resource includes information on the reliability of the switch itself and of the switch action, any restarts and any maintenance tasks that apply to the switch.
- Throughput
- Units allows you to specify the units used for measuring input/output (mass) and time. For example, you might measure throughput in terms of kilograms per hour.
- Maximum output defines, for each connected path, a maximum amount of output that can be sent to the path.
- Demand allocation
per input type allows you to specify, for each
flow type, how input is accepted into the container and,
by extension, into the Start block of each train within
the container. This setting applies if there are multiple
incoming paths of that flow type entering the container
and the amount of input that they deliver exceeds the
container's capacity as limited by train and/or downstream
capacities. If all input can be handled by the container,
the selection here is ignored. To understand the demand
allocation types, consider a block with a capacity of
10 units, receiving inputs A - 5 units, B - 3 units and
C - 2 units. Now assume that downstream issues have limited
the block’s capacity to 5 units.
- If Allocate according to connection priorities is selected, the input will be allocated according to the priorities specified for each connection (i.e., all input will be taken from the highest priority connector until its capacity is reached, then all input will be taken from the next highest priority connector and so on, until the block’s capacity is filled). When this option is selected, you will be able to set priorities by selecting each connector that carries input to the block and using the commands at Process Flow > Selection > Input Priority. The input priority for each connector is shown at the end of the connector caption. In our example, if path A has the top priority, then input will be accepted only from A, because the 5 units it provides fill the block’s capacity. However, if B has the top priority, followed by A, then 3 units will be accepted from B and the remaining 2 units to fill the block’s capacity will be accepted from A.
- If Weighted allocation across paths is selected, the amount of input refused when the block’s capacity is filled will be weighted according to the capacity of each incoming path. The software calculates the total capacity of all paths and then determines the percentage of the total capacity represented by each path. An equal percentage of each path’s capacity will be refused, thereby maintaining the weights of the paths. In our example, the block’s capacity has decreased by 50%, so 50% of each path’s input will be refused. The following amounts will be accepted: A – 2.5 units, B – 1.5 units and C - 1 unit.
- If Allocate equal share to all paths is selected, an equal amount of input will be refused from each of the paths when the block’s capacity is filled. In our example, the block’s capacity has decreased by 5 units, so 5/3 = 1.67 units will be refused from each path. The following amounts will be accepted: A – 3.33 units, B – 1.33 units and C – 0.33 units.
- Allocation per
input type allows you to specify, for each flow
type, how output is routed from the Start block of each
train within the container if there are multiple outgoing
paths of that flow type exiting the Start block. If there
are multiple active trains, this setting also dictates
how the flow type is allocated among them.
- If Allocate according to connection priorities is selected, the output will be allocated according to the priorities specified for each connection (i.e., all output will go to the highest priority connector until its capacity is reached, then all output will go to the next highest priority connector and so on). When this option is selected, you will be able to set priorities by selecting each connector that carries output from the block and using the commands at Process Flow > Selection > Output Priority. The output priority for each connector is shown at the beginning of the connector caption.
- If Weighted++ is selected, the allocation will be weighted according to the maximum output specified for each path (in the section directly below). The software calculates the total capacity of all possible paths and determines the percentage of the total capacity represented by each path, then sends that percentage of the "stream" to each path. Once this allocation is calculated, if a particular path is unable to handle what is allocated to it due to restrictions downstream, that path will handle only as much throughput as the restriction allows. The throughput of the other paths will be adjusted using the maximum output for all the throughput that is left beyond the restricted path.
- If Equal++ is selected, an equal share of output will be allocated to each of the paths as long as the equally allocated output is equal to or less than the total throughput. If the total throughput is greater than what can be achieved by equal allocation, then the system will allocate as much as possible using equal allocation across all the paths, then try to allocate what is left equally into the paths that still have capacity left. This is repeated until all paths have reached maximum capacity or the total throughput has been allocated across the paths.
- If Weighted allocation across paths is selected, the allocation will be weighted according to the maximum output specified for each path (in the section directly below). The software calculates the total capacity of all possible paths and determines the percentage of the total capacity represented by each path, then sends that percentage of the "stream" to each path. Once this allocation is calculated, if a particular path is unable to handle what is allocated to it due to restrictions downstream, that path will handle only as much throughput as the restriction allows. The throughput for the other paths is not changed.
- If Allocate equal share to all paths is selected, an equal share of output will be allocated to each of the paths. If a given path's capacity is reduced, all other paths will be reduced accordingly. For example, in extreme cases, this can lead to zero throughput for all paths if any one path's flow is reduced to zero.
- Demand allocation per output type allows you to specify, for each flow type, how input is accepted into the End block of each train within the container if there are multiple incoming paths of that flow type entering the End block. If there are multiple active trains, this setting also dictates how the flow type is allocated among them. The available demand allocation types are defined above.
- Allocation per output type allows you to specify, for each flow type, how output is routed from the End block of each train within the container and, by extension, from the container itself if there are multiple outgoing paths of that flow type exiting the container. The available allocation types are defined above.