Within the Action element dialog, there is an option to Handle action internally:
This option is only available if the Action is being modeled as a system.
Even if the Action is being modeled as a system, the checkbox is defaulted off.
This checkbox controls how Actions that are defined as systems handle action triggers. If the box is checked, the Action triggers are automatically routed to internal Action components and the OK and Failed triggers become available (for handling responses from internal elements).
In order to handle an action internally, the triggering of the parent’s action must automatically trigger a child action element or element(s). You can then implement as much logic as you desire (using any available GoldSim elements) to determine whether the internal (child) action is completed successfully or fails, but it must result in either a single event or condition that indicates success or a single event or condition that indicates failure. These “single events or conditions” must then be connected to the OK and Failed triggers inside the parent.
In this example, the Solenoid and Starter_Motor Actions are children of a Starter Action. The Solenoid is automatically triggered by the parent. It then triggers the Starter-Motor to act. If either the Solenoid fails or the Starter_Motor fails, the Car_Fails_to_Start event is triggered. If the Starter_Motor completes its action, the Car_Started event is triggered. The Car_Started event triggers the parent's OK trigger. The Car_Fails_to_Start event triggers the parent's Failed trigger.
To facilitate this, a special trigger type is available within the Action trigger when the Action element being triggered is the child of another action element, and the Parent element’s Handle action internally option has been checked:
The Auto Action trigger automatically fires when the parent Action element is triggered. With this trigger type, the trigger expression cannot be edited.
In some cases, you may want the parent Action element to not only trigger internal child Action elements, but other kinds of elements inside the parent Action (e.g., a Discrete Change or a Triggered Event). To facilitate this, GoldSim provides a special locally available property that can be referenced inside Action elements that are defined to be handling events internally.
Note:
Locally available properties derive their name from the fact
that they may only be available in “local” parts of your model (e.g., within a
particular element, or within a particular input field for an element).
In particular, an event called ActionEvent is available inside the parent Action, and this can be used to trigger elements inside the parent whenever the parent is triggered. It would be used as follows:
In this case, the child element inside the parent would automatically be triggered when the parent was triggered.
As pointed out above, when handling an action internally, internal calculations within the parent must result in either a single event or condition that indicates success or a single event or condition that indicates failure. These “single events or conditions” must then be connected to the OK and Failed triggers in the parent.
Note: The OK and
Failed triggers of the parent can only be linked to outputs from child
elements within it.
Warning: The parent element
requires exactly one response from the children for each triggering event, as it
cannot distinguish between multiple event triggers. Therefore, the
modeler should not construct logic whereby one parent’s action trigger could
lead to the generation of multiple OK or multiple Failed events, as this could
lead to unintended model behavior.
If the ‘OK’ trigger is fired, and the parent element has no unrepaired failure modes, the parent element will successfully complete its action and emit an ActionOK event. However, if the ‘OK’ trigger becomes true, and the parent has unrepaired failure modes, the parent element will emit an ActionFailed event.
If the ‘Failed’ trigger is fired, the parent has not successfully completed its action, and an ActionFailed event will be emitted regardless of whether or not the parent element has unrepaired failure modes.
Like the Action button, the LED’s in the bottom corner of the ‘OK’ and ‘Failed’ buttons will light once triggers are specified, and the triggers can be viewed by mousing over the two buttons.
When handling Actions internally, and both the parent and the child Actions have delays, the following sequence is used when the parent’s Action is triggered:
•The child is triggered, and its Action delay begins.
•When the child’s delay is completed, an ActionOK or Action Failed event is issued by the child, and this is transmitted to the Handle action internally triggers of the parent Action element
•The parent delay then begins, and when it completes, the parent issues an ActionOK or ActionFailed event.
Learn more about:
Modeling a Reliability Element as a System with Child Elements