A sub process flow (also called a sub flow for short) is a separate process flow that begins running when it is triggered by another activity or event in a different process flow. Think of sub flows as chunks of self-contained logic that will get executed when they are triggered by certain events in the simulation model or general process flow. If you are familiar with programming terms, you could think of a sub flow as a function or a subroutine.
Sub flows can cut down on the need to create a certain block of process flow activities in multiple places throughout your process flows. You could use sub flows to perform calculations or to simulate more complex procedures that are triggered by specific activities or events in the main process flow. A sub flow could run a simple calculation to dynamically determine a processor's processing time. Or a sub flow could contain a task sequence that will be used by several different task executers at certain points during a simulation run.
For example, perhaps you want to simulate an assembly line of some sort. When items come off an assembly line they will need to go through a set of quality assurance procedures after which the item will either pass or fail. You could simulate this using a sub flow that is triggered once a token gets to a particular activity in the process flow.
The following list explains how sub flows work from beginning to end:
As was mentioned in the previous activity, sub flows are usually triggered when a token enters a Run Sub Flow or Create Tokens activity on the main process flow. Which activity you should use will probably depend on your purpose in using a sub flow. There are two key differences between these two activities, as explained in the following table:
Should the parent token wait or not? | Do I want the child token to be sent to a Start activity or something else? | |
---|---|---|
Run Sub Flow | Use a Run Sub Flow activity if you want the parent token to wait until the child token has completed the sub flow before it is released to the next activity in the main process flow. | Run Sub Flow activities can only send child tokens to a Start activity. |
Create Tokens | Use the Create Tokens activity if you want the parent token to create a child token and then immediately get released to the next activity in the main process flow. | Create Tokens activities can send tokens to any activity in a sub flow. |
The following image shows an example of a simple internal sub flow during a simulation run:
An internal sub flow is a sub flow inside of an existing process flow. Internal sub flows are basically an independent block of activities that begin with a Start activity and end with a Finish activity. Therefore, to create an internal sub flow, simply create a block of activities that begin with a Start activity. After creating the block of activities, link it to the main process flow. See Linking to Sub Flows for more information.
The following image shows an example of an external sub flow during a simulation run:
An external sub flow is a separate process flow that was assigned the Sub Flow type when it was first created. It will have its own separate window and will be listed as a separate process flow in the Toolbox.
To create an external sub flow:
If you are linking to sub flow from a Create Tokens
activity, you can use the sampler button
next to the Destination property to select the activity (in the
sub flow) where you want to create a child token.
To link to a sub flow from a Run Sub Flow activity:
Some properties on fixed resources have menu options (picklists) that can initiate a sub flows. For example, the Send to Port property has a menu option that allows you to reference a sub flow. You could possibly use this sub flow to implement logic that will determine which output port should receive a flow item.
You could also use a picklist to reference a task sequence sub flow. For example, you can change a processor's settings so that it will use a task executer during its setup time or processing time. If you need a task executer to complete a more complex series of tasks during setup, processing, or transportation, you could create a task sequence on a process flow. Then, you could use the select ProcessFlow: Use Task Sequence Sub Flow on the processor's setup, processing, or transportation properties to initiate that task sequence.
A Start activity may be connected to multiple Finish activities, as shown in the example sub flow in the following image:
In that same vein, multiple Start activities may share the same Finish activity. Technically, each Start activity would be the beginning of a different sub flow. The following image shows an example of this kind of sub flow:
Before reading this section, make sure that you understand the definitions of parent token and child token, as explained in the section about How Sub Flows Work.
One of the advantages of using sub flows it that it will allow you to create links between the labels on parent and child tokens. You can possibly set a child token to update the labels on the parent token (and vice versa) during a simulation run. Ultimately, the relationship you build between the labels on parent and child tokens will have a big impact on the logic of your process flows. For that reason, you should think carefully about the logical relationship you want the parent token on the main process flow to have with the child token(s) on the sub flows:
The Label Access rules and strategies are explained in more detail on the Create Tokens activities reference page. Pay particular attention to the Create As and Label Access properties and the subsequent properties listed there.
Once a parent/child relationship has been created, the parent token will display the number of children it has in the process flow view by default. You can change these settings on the Process Flow Properties page if needed. See Changing Process Flow Visuals for more information.
If you click on a child token, the Quick Properties will display all of the labels owned by the child token as well as any labels from the parent token that the child has access to, as shown in the example in the following image:
If a label is not accessible to the child, it will not display in this list.
The following table explains the meaning of the symbols on these labels:
Symbol | Meaning |
---|---|
(P) | The label is owned by the parent |
(PP) | The label is owned by the parent's parent (grandparent), and so forth. |
+ | When it is next to the P, it means that the child token has the ability to write (set) the label. |
For example, in the example from the image above:
To access a parent token, enter the following in a property field:
token.parent
Child tokens can be accessed by rank through the parent using the command:
token.children[1]
To get the # of children the parent has:
token.children.length