Tech Note

Title:               Looping & Branching Transform
Date:              March 13, 2007
Written by:     Peter Bosch
Number:        TN-016
Version:         1.0

The structure of loops and branches in the Modeler and SOM (Simulation Object Model) is significantly different from the structure required by the control system to execute synchronized and non-synchronized loops and branches. This Tech Note describes the transformation algorithm that is used, and the PFC (Procedure Function Chart) topology that is generated.

A simple recipe snippet from the modeler may look like that in figure 1. It shows two synchronized branches, the first comprised of the two “Branch1-L1,L2” steps each with two destinations (targets) chosen based on “pH<7” or “pH≥7”, and the second consisting of the “Branch2-L2” branches which branch on “TRUE”.

representative modeler recipe snippet

Figure 1 : Representative Modeler Recipe Snippet

This is represented, loosely, as shown in figure 2.

analytical notation for branches

Figure 2 : Analytical Notation for Branches

Each transformation considers one set of synchronized branches and labels at a time. We would consider BR1_A & BR1_B branching to L1_X & L1_Y, or to L2_X & L2_Y. In figure 3, we show two representations, side by side, of a three-branch, two-condition branch, and then describe the algorithm employed in its transformation.

Note that the Label Synchrony Step and Label Synchrony Transition set the stage for allowing a label to be used in both a synchronous and an asynchronous role. The Branch Synchrony Transition and Branch Synchrony Step set the stage for allowing branch fall-through. So while these four node types are not strictly necessary, they are present as hooks for future features. Furthermore, they are eliminated in graph reduction, so there is no impact to using them save that of a minor performance cost.

three branch, two condition synch branch

Figure 3 : Three-branch, two-condition SyncBranch

The algorithm employed is as follows:

- Remove Branches’ links to successors.

- Remove Labels’ links to predecessors.

Force all branches’ and labels’ IsNullNode=true (this can/should be moved up into the modeler.)

Each Branch Scenario Record (BSR) contains:

            a.) Source task (branch)

            b.) Target task (label)

            c.) Condition

            d.) Master source task

            e.) Master target task

Establish navigational dictionaries. (Nodes, keyed to some characteristics of the BSRs they participate in.)

Synchronized Branches

For each BSR {

Start with cursor at the source task.

1.) If the source task does not have a BST & BSS, create both and bind source task to BST and BST to BSS – store the BSS keyed to the source task.

Advance the cursor to the BSS.

2.) If there is no ABS keyed to the master task then create the ABT and ABS, bind them together and key the ABS to the master task.

3.) Bind the branch’s BSS to the master’s ABT, and advance the cursor to the ABS.

4.) Create a composite key from the master source task guid as a string, concatenated with the condition string. This is called the source composite key and identifies a single-condition path (one branch) from a set of synchronized branches. If there is no ACT for this key, create an ACT (with the condition specified), bind the ABS to it, and store it, keyed by the source composite key.

Advance the cursor to the ACT.

5.) If there is no ALS keyed to the target master task, then create an ALS and an ALT, bind the ALS to the ALT. Then store the ALS and ALT keyed to the target master task.

6.) Bind the ACT to the ALS.

Advance the cursor to the ALT.

7.) If there is no LSS keyed to the target task, create an LSS and LST, bind them together and to the target task. Store the LSS under the target task’s guid.

8.) Bind the ALT to the LSS.

}

Unsynchronized branches

Bind the source to the target through a CT.

Post Transformation

After the transformation is done, null step reduction is done, and all transitions and any remaining null steps undergo cosmetic renaming.