SYSML21 — Initiating Owned Action Execution

We need to update the defaults for owned non-abstract Actions to ensure expected interpretations of when and how Actions will start when executing their parent (owning Action, Part, or Occurrence).

Background:

Modelers creating SysML would like good defaults to make modeling Action sequences simple, easy to declare, and easy to interpret. The main discussion stems around potential confusion in the case where some owned Actions have zero incoming successions (but are possibly expected to "start automatically").

In UML, Actions that did not require any incoming control or flow tokens would "start automatically" without requiring a control token. Essentially, they would not be blocked from starting by requiring them to wait for a control token. In SysMLv2, we no longer have control tokens and instead rely on Successions (HappensBefore connectors) to constrain the relative time ordering of behaviors. While it's clear (pending other RTF issues around end multiplicities) that the intent of a succession is to ensure that a target Occurrence occurs for every instance of a source Occurrence, it is less clear what would happen in the absense of any such succession.

Currently, the default multiplicity of Actions in SysML is inherited from KerML as [0..*]. As part of execution, there is some major question around whether there is any indication that such an action would occur at all with a lower bound multiplicity of zero. So, a model where the action does NOT execute is valid!

See attached for reference models. Consider the following textual models:
Explicit (All actions have successions from start)

action a0{
    action a1{
        out x1;
    }
    action a2{
        in x1;
    }
    first start then a1;
    first start then a2;
    flow from a1.x1 to a2.x1;
}

Implicit (No actions have incoming successions)

action a0{
    action a1{
        out x1;
    }
    action a2{
        in x1;
    }
    flow from a1.x1 to a2.x1;
}

Mixed (Some actions may have successions from starts but others do not)

action a0{
    action a1{
        out x1;
    }
    action a2{
        in x1;
    }
    first start then a1;
    flow from a1.x1 to a2.x1;
}

The open question is: when and how do actions 'a1' and 'a2' start in the context of 'a0' for these different models?