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. In pursuit of this, we are considering several alternative proposals for updating the defaults for Actions and Successions between Actions. 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

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

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

Mixed

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

To address these concerns, we have the following proposals:
1. Require every action to be the target of a succession. This is precise but can significantly clutter the diagram as indicated in the example above that required adding a succession from the start node to a2.

2. Introduce an execution rule that states that any action that is not the target of a succession will begin execution after the start of the containing action. This simplifies the diagram and is consistent with SysML v1 activity diagrams (including activity diagrams with streaming flows).

3. Leave as is. This requires modelers to declare a succession from start to the first action, or adding the multiplicity of such actions as [1..1] or [1..*] explicitly.

4. Formalize the default semantics without an execution rule as follows: “The default multiplicity of an action is [1..*]. This would mean that an action has no incoming succession it would start after a0 starts, The default multiplicity can still be overridden with 0..* if it is desired to start.

5. If and only if there are no successions from start, then any concrete actions that have no incoming successions, have default multiplicity 1..1 (or 1..*?). Conversely, if there are any successions from start, then the default multiplicity remains [0..*] and actions will not execute by default unless they are the target of a succession.

We will need to discuss and propose a specific solution regarding what we update in the specification itself. The goal is to standardize as much of the otherwise non-normative "execution rules" as possible.

A binary ConnectionDefinition must directly or indirectly specialize the ConnectionDefinition
Connections::BinaryConnection from the Systems Model Library.
ownedEndFeature->size() = 2 implies
specializesFromLibrary('Connections::BinaryConnections')

should be

specializesFromLibrary('Connections::BinaryConnection')

Tables 25 and 34 in clauses 7.26.5 and 9.2.20.1 respectively have inconsistent descriptions of standard views. Table 34 is the authoritative source for the standard view definitions. The first column of Table 25 will need to be updated to be consistent with Table 34.

Clause 9.3.5 describes icon metadata, with the objectives to attach icons to model elements in a graphical/tabular view,
There are two issues here
(1) It is not practical too attach an icon to each individual usage, it is expected that assigning such a metdata to a semantic metadata would imply the icons also on elements referring to the semantic metadata. For example, if a semantic metadata defined for "assembly", any definition or usage "tagged" as assembly is expected to have this icon. The current specification does not address this practical issue.

(2) The graphical notation representative tables anf BNF do not cover how an icon is represented in case an icon is defined

In 8.3.20.2 AssertConstraintUsage, in the OCL for the constraint validateAssertConstraintUsageReference, the invocation referencedFeaure() should be referencedFeature().

In 8.4.1 Semantics Overview, the tables contain the following errors.

1. Table 31. Implied Definition Subclassification Relationships
   • For checkMetadataDefinitionSpecialization, Views::MetadataItem should be Metadata::MetadataItem.
2. Table 32. Implied Usage Subsetting Relationships
   • For checkAttributeUsageSpecialization, Attributes::attributes should be Attributes::attributeValues.
   • checkEventOccurrenceSpecializaton should be checkEventOccurrenceUsageSpecialization.
   • For checkTransitionUsageSpecialization, Actions::transitions should be Actions::transitionActions.
3. Table 33. Other Implied Relationships
   • checkRequirementUsageObjectiveSpecialization should be checkRequirementUsageObjectiveRedefinition.

In 8.3.17.15 SendActionUsage, in the OCL for the constraint checkSendActionUsageSubactionSpecialization, the reference to Actions::Action::acceptSubactions should be Actions::Action::sendSubactions.

In 8.3.17.5 AssignmentActionUsage, under "Constraints":

1. In the OCL for constraints checkAssignmentActionUsageAccessedFeatureRedefinition, checkAssignmentActionUsageReferentRedefinition and checkAssignmentActionUsageStartingAtRedefiinition, the terms targetParameter->first() should be targetParameter.ownedFeature->first().
2. In the OCL for constraints checkAssignmentActionUsageAccessedFeatureRedefinition and checkAssignmentActionUsageStartingAtRedefiinition, references to redefines should be redefinesFromLibrary.

The doc descriptions of MergeAction, DecisionAction, JoinAction and ForkAction use "succession connector". This should be replaced with "succession connection" (4 times).

In Table 15 of the Representative Notation Tables, the row labeled Accept and Send Action Flow includes a model fragment that uses a combination of a succession and a binding connection to connect to the input payload parameter of a send action and from the output payload parameter of an accept action. This issue recommends adding another example of a common pattern that replaces the succession and the binding connection with a succession flow.

includes the the keyword

an occurrence isage

should be

usage is

PrefixMetadataMember : OwningMembership =
'#' ownedRelatedEleemnt = PrefixMetadataUsage

Element is not spelled correctly

PrefixMetadataMember : OwningMembership =
'#' ownedRelatedEleemnt = PrefixMetadataUsage

Element is not spelled correctly

PackageMember : OwningMembership
MemberPrefix
( ownedRelatedElement += DefinitionElement

there is no equal sign here

The current specification presents two issues with compartment definitions:
• The same elements may appear in multiple compartments, even when a more specific compartment is defined (e.g., action and perform action).
• Because keywords are hidden, compartment element keywords cannot be clearly distinguished (for example, perform action looks the same as action).

To address these issues, the following adjustments are proposed. Specific compartments should explicitly exclude overlapping contents:

actions-compartment-contents (page 227)
• exclude perform-actions-compartment-contents (page 227)
use-cases-compartment-contents (page 255)
• exclude include-use-cases-compartment-contents (page 255)
states-compartment-contents (page 238)
• exclude exhibit-states-compartment-contents (page 239)
constraints-compartment-contents (page 243)
• exclude require-constraints-compartment-contents (page 246)
• exclude assume-constraints-compartment-contents (page 246)
• exclude assert-constraints-compartment-contents (page 244)
requirements-compartment-contents (page 246)
• exclude satisfy-requirements-compartment-contents (page 247)
• exclude verifies-compartment-contents (page 253)

Currently, the usage appearance in the ‘parameters’ compartment is defined in the “8.2.3.17 Actions Graphical Notation” chapter as follows:

parameters-compartment-element = el-prefix? FeatureDirection UsageDeclaration ValueOrFlowPart? DefinitionBodyItem*

This is not consistent with other compartments that represent elements which can declare a direction (it includes only the ‘direction’ modifier but omits others), such as items, parts, and attributes:

items-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp
parts-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp
attributes-compartment-element = el-prefix? UsagePrefix usage-cp

To ensure consistency, it should be aligned with these definitions, as shown below:

parameters-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp

Currently, the usage appearance in end compartment are declared in “8.2.3.14 Interfaces Graphical Notation” chapter like that:

ends-compartment-element = QualifiedName (’:’ QualifiedName)?

It is not consistent with all other compartments, e.g. parts, ports:

parts-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp
ports-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp

It should be aligned with those with one simple modification that skips the ‘end’ prefix declaration:

ends-compartment-element = el-prefix? BasicUsagePrefix UsageExtensionKeyword* usage-cp

On page 630 and 634 in the table under the section for ScalarQuantityValue Operations on the 3rd row, 1st column, the text is:

fs1+fs2

for the Description:

Addition of a bound and a free scalar quantity returns a bound scalar quantity.

Text should be:

bs1+fs2

In the section for /stakeholderParameter within 8.3.21.8 RequirementsDefinition:

"The parameters of this RequirementDefinition that represent stakeholders for th requirement"

"the" missing the "e" at the end of the sentence.

Standard library `ISQMechanics.sysml` contains a declaration of torque as a scalar quantity to represent torque magnitude, but the related torque vector quantity is missing.

A torque vector quantity and associated coordinate frame should be added using the same pattern as for other vector quantities.

Note: This issue was flagged in "SysML v2 Release" Google Group at https://groups.google.com/g/sysml-v2-release/c/w7ZbFZ9d-e0/m/yTF8oyb6AwAJ .

In the Systems Library model Actions, the action definition AssignmentAction has two parameters, target and replacementValues, in that order. The action usage assignmentActions, which is defined by AssignmentAction, redefines the target parameter, but inherits replacementValues.

The action usage Action::assignments is also defined by AssignmentAction and it subsets assignmentActions. This means that it has two parameters from AssignmentAction and two parameters from assignmentActions as potentially inheritable members. However, assignmentActions::target redefines AssignmentAction::target so the latter is not inherited. And assignmentActions::replacementValues is the same as AssignmentAction::replacementValues, so the former is not inherited again.

The result of this is that the inherited parameters of Action::assignments are AssignmentAction::replacementValues and assignmentActions::target in that order. That is, the parameters of assignments have effectively switched their order relative to how they are defined in AssignmentActions. This is a problem, because an AssignmentActionUsage has an implied specialization of assignments, and it is parsed assuming the parameters inherited from assignments are in the same order as in AssignmentAction.

There are errors in the example model that need to be corrected to align with the latest release.
This includes the following errors on pg 662.
From: variation part transmission:TransmissionChoices;
To: part transmission:TransmissionChoices;

From: variation part sunroof:Sunroof;
To: variation part sunroof:Sunroof [0..1];

It is also recommended to add the subset of the part vehicleFamily to model a specific vehicle configuration.

In the Systems Library model Flows, the flow usage flows explicitly subsets messages. However, messages is also a flow usage, and it has owned end features. So, according to the constraint checkFlowUsageFlowSpecialization, messages is required to subset flows. This means messages and flows subset each other and are, therefore, semantically equivalent. As a result, all message flow usages with implied subsetting of messages end up having the same semantics as non-message flow usages with implied subsetting of flows.

In 8.3.21.7 RequirementConstraintMembership, the constraint validateRequirementConstraintMembershipIsComposite requires that the ownedConstraint of a RequirementConstraintMembership be composite. However, consider the following:

part p {
    constraint c;
}
requirement r {
    subject :> p;
    require p.c;
}

In this case, the constraint c is composite in p, but the required constraint referencing p.c is composite in r. Further, checkConstraintUsageCheckedConstraintSpecialization requires that c subset Part::checkedConstraints, which indirectly specializes Object::ownedPerformances, and, therefore, so does the required constraint referencing p.c. But checkConstraintUsageRequirementConstraintSpecialization requires the required constraint to specialize RequirementCheck::constraints, which (as a composite constraint usage) indirectly specializes Performance::subperformances. Thus, the required constraint inherits from both ownedPerformances and subperformances, which is inconsistent (in particular, this is bound differently in the two features).

The following library models include the declaration of types that have inherited members with the same name, because of diamond inheritance of redefined features.

Systems Library

• Actions
• Flows
• Interfaces
• Items
• Metadata
• Ports
• SysML
• VerificationCases
• Views

Analysis Domain Library

• AnalysisTooling

Cause and Effect Domain Library

• CauseAndEffect

Geometry Domain Library

• ShapeItems

Metadata Domain Library

• ImageMetadata
• ModelingMetadata
• ParametersOfInterestMetadata
• RiskMetadata

Quantities and Units Domain Library

• SI
• USCustomaryUnits

Requirement Derivation Domain Library

• RequirementDerivation

The analysis case definition TradeStudy from the Analysis Domain Library model TradeStudies.sysml is intended to be used by redefining the objective tradeStudyObjective to use a concrete specialization of TradeStudyObjective, e.g., MinimizeObjective or MaximizeObjective. For example:

analysis tradeStudy : TradeStudy {
    objective minimize :>> tradeStudyObjective : MinimizeObjective;
    ...
}

However, MinimizeObjective and MaximizeObjective redefine the parameters from TradeStudyObjective, and TradeStudy::tradeStudyObjective also redefines the first three of these parameters (selectedAlternative, alternatives and eval). But this means that both sets of redefinitions are inherited by the objective minimize in the analysis case usage above, which is semantically inconsistent. Currently, the only way to avoid this is for the modeler to include nested redefinitions of selectedAlternative, alternatives and eval when redefining tradeStudyObjective, which is inconvenient and unintended.

There should be a Constants Domain Library that capture all mathematical and CODATA Fundamental Physical Constants as published on https://pml.nist.gov/cuu/Constants/, in particular from the ASCII list of all constants at https://pml.nist.gov/cuu/Constants/Table/allascii.txt. Each constant should include a specification of whether its real number value is exact or not and, if not, what the uncertainty is.

The definition of 'pi' provided in TrigFunctions::pi (KerML) also includes an invariant that specifies PI to 20 significant digits.

However, in SI.sysml where we define 'degree', the conversion factor is listed as:

attribute <'°'> degree : AngularMeasureUnit { :>> unitConversion: ConversionByConvention { :>> referenceUnit = rad; :>> conversionFactor = 1.745329E-02; :>> isExact = false; } } // conversionFactor should become pi/180

It appears that this was intended to be a "TODO" that was never addressed!

Having the conversion factor from degrees to radians only listed to "single precision" will be a severe problem for many engineering applications. We should instead depend on the actual "pi/180" expression as stated in the trailing comment

As part of the Users WG in coordination with Execution WG, we have determined that successions from the "start" of a state or the "entryAction" of the state can cause confusion for many users. As such, we want to "deprecate" this usage in favor of requiring an explicit state transition from "start" to the first subState.

We will need to update all of our relevant graphical and textual examples shown in the spec to demonstrate this preferred approach and remove the previous approach.

Models using successions from "start" or "entryAction" will remain valid but will not be the preferred method. We will want to indicate that support for such may be removed in some future version, subject to a discussion around what the deprecation policy should be.

The textual notation production AnnotatingMember in 8.2.2.4.1 Annotations is used in the special syntax for EnumerationBody to allow the bodies of EnumerationDefinitions included AnnotatingElements as members. However, AnnotatingMember does not include the MemberPrefix that allows for visibility to be specified for a normal DefinitionMember. This means that AnnotatingElements in EnumerationBodies cannot currently have any visibility other than public, even though there is no such restriction in the abstract syntax.

According to the specification, items can own actions and parts can perform actions.

However, the feature "ownedActions" is owned by the library element Part and not Item. The feature "performedActions" is also owned by Part which is correct.

In the following sentence, the word "enumerationDefinition" should be "EnumerationDefinition".

"However, other than when nested in an EnumerationDefinition, an EnumerationUsage is semantically just an AttributeUsage that is required to be typed by exactly one EnumerationDefinition (syntactically enforced by the 1..1 multiplicity of EnumerationUsage::enumerationDefinition, see 8.3.8 )."

It's likely that OrderedContainer is supposed to specialized Container, such that orderedContent can redefine content.

abstract part def Container

part def OrderedContainer

When discussing verdicts "The result of the validation case is a verdict..." should this be "The result of the verification case is a verdict..."?

Currently the BNF requires a separate flow symbol for every flow that transpires over a connection (or an interface).
It is requested to also support a more compact notation, that each flow symbol can represent multiple flow usages specified in a comma separated list.

In SysML section 7.17.9 (BETA 4) - Assignment Action Usages, the code comment in the textual example is inconsistent with the language in the English.

The English says:
"An AssignmentAction sets a referent feature of a target occurrence to a new assigned value."

But the code comment says:

action def UpdateVehiclePosition {
in part sim : Simulation;
in attribute deltaT : TimeDurationValue;
// The target of the assignment below is "sim".
// The referent feature chain is "vehicle.position".
assign sim.vehicle.position :=
sim.vehicle.position + sim.vehicle.velocity * deltaT;
// After the above assignment "sim.vehicle.position" has the
// value of the result of the assigned value expression,
// evaluated at the time of the assignment.
}

The comment should probably identify "position" as the referent (not "vehicle.position" ! ) and "sim.vehicle" as the target, since "vehicle" features "position" ("sim" does NOT feature "position" and therefore "sim" cannot be the target).

Consistent with the 'var' feature being featured by "vehicle" and not "sim", I would expect "sim.vehicle" to declare the occurrence for the purposes of the assignment. Otherwise, using "sim" as the occurrence would require more complex semantics involving the 'var' behavior of an intermediate occurrence as part of the assignment action, which is unnecessary.

Due to the problem identified in KERML11-72, a state usage that is a substate may end up inheriting two different redefinitions of Occurrence::Occurrence::this, but both with the name this, resulting in a violation of the constraint validateNamespaceDistinguishibility.

1. The library usage Actions::Action::subactions specializes all of Actions::Action, Actions::actions and Performance::Performance::subperformances.
2. subactions has a nested redefinition of this, which is resolved as a reference to Occurrences::Occurrence::this that is inheritable from Action.
3. subperformances also redefines Occurrences::Occurrence::this and the redefined feature Performances::Performance::subperformances::this is also inheritable by subactions. However, it is not actually inherited because it is overridden by the direct redefinition of Occurrences::Occurrence::this in subactions.
4. The library usage States::StateAction::subactions redefines Actions::Action::subactions. It does not have a nested redefinition of this.
5. Among other things, StateAction::subactions also has an implied specialization of subperformances. However, since subaction is already a subtype of subperformances, this implied specialization can be considered redundant and not included. But, according to KerML specification subclause 8.4.2 (Semantic Constraints and Implied Relationships), a tool is not required to exclude such an implied specialization, so the specialization of subperformances could be included.
6. If the implied specialization of subperformances is included, then subperformances::this will be inherited by StateAction::subactions in addition to Action::subactions::this.
7. The usage StateAction::substates specializes StateAction::subactions, and every state usage that is a substate is required to specialize StateActions::substates. As a result, if StateAction::subactions gets two this features, these will be inherited by every substate.

Currently it is not possible to use action control nodes (Fork/Join/Decision/Merge) as sources/targets of a transition in a state definition or usage.

The constraint checkActionUsageSubactionSpecialization checks that the operation isSubactionUsage is true before requiring that an ActionUsage specialize Actions::Action::subactions. The operation isSubactionUsage not only checks the ActionUsage is composite and has an owningType that is an ActionDefinition or ActionUsage, but also ensures that the ActionUsage is not an entry or exit action. Various subclasses of ActionUsage have semantic constraints that require more specific specializations of subactions but do not include the condition that the usage is not an entry or exit action:

• checkCalculationUsageSubcalculationSpecialization
• checkRequirementUsageSubrequirementSpecialization
• checkCaseUsageSubcaseSpecialization
• checkAnalysisCaseUsageSubAnalysisCaseSpecialization
• checkVerificationCaseUsageSubVerificationCaseSpecialization
• checkUseCaseUsageSubUseCaseSpecialization

The semantic constraint checkRequirementUsageObjectiveRedefinition requires that

A RequirementUsage whose owningFeatureMembership is a ObjectiveMembership must redefine the objectiveRequirement of each CaseDefinition or CaseUsage that is specialized by the owningType of the RequirementUsage.

But this doesn't handle the case in which the owningType may be specialized by a feature chain whose featureTarget is a CaseUsage.

Performed By Compartment is empty needs to be removed or filled

Actions::AcceptAction descriptions differ between Standard and Standard Library

Actions::DecisionAction descriptions are different are different than in their library files

action-def-name-compartment =
'«' DefinitionPrefix 'action' 'def' '»'
definition-name-with-alias<

don't think the ending < should be there

Actions::DecisionTransitionAction has different descriptions

"has a single guard" in standard vs "has a guard" in standard file

Actions::acceptActions descriptions are different between Standard and Standard Library File

acceptActions is the base feature for all SendActionUsages.

vs

acceptActions is the base feature for standalone AcceptActionUsages

Actions::TerminateAction documentation is not coordinated between section 9.2.10.2.24 and the library files

Actions::SendAction descriptions not the same as
in the Library file

Actions::AcceptMessageAction has different descriptions than
is in the library

Actions::MergeAction descriptions are different than in the system library file

Verified
Requirements
Compartment

is empty need to be filled or removed

confirm state-actions-compartment is "states" not "state actions"

viewpointConformance is not defined in the standard library
should be stubbed out...

abstract view def View :> Part {
...
viewpoint viewpointSatisfactions : ViewpointCheck[0..*] :> viewpointChecks, checkedConstraints
satisfy requirement viewpointConformance by that

}

Compartment in Table 13 says "allocated"...

allocations-compartment has the marker called "allocations"

I think one of these need to be changed

in interfaces.sysml

end port source: Port :>> BinaryConnection::source;
end port target: Port :>> BinaryConnection::target;

but 9.2.7.2.1 BinaryInterface has

source : Port [0..*]

target : Port

so one of these sources is wrong

Don't think we need

validateObjectiveMembershipIsComposite

it is composite in the metamodel

Cases can be used "in its own right"... there needs to be a graphical notation for Cases

the standard alludes to

validatePortDefinitionNestedUsagesNotComposite requires that all nestedUsages of the
PortDefinition that are not PortUsages are referential (non-composite).

but no OCL definition of
validatePortDefinitionNestedUsagesNotComposite
is in the standard

the standard alludes to

validatePortDefinitionNestedUsagesNotComposite requires that all nestedUsages of the
PortDefinition that are not PortUsages are referential (non-composite).

but no OCL definition of
validatePortDefinitionNestedUsagesNotComposite
is in the standard

checkPartUsageStakeholderSpecialization
wording should be
If a PartUsage is owned via a StakeholderMembership, then it must directly or indirectly specialize Requirements::RequirementCheck::stakeholders.

i.e. remove the word "either"

/conjugatedPortDefinition : ConjugatedPortDefinition [0..1]

The that is conjugate to this PortDefinition.

should be

The ConjugatedPortDefinition that is conjugate to this PortDefinition.

checkPartUsageStakeholderSpecialization
wording should be
If a PartUsage is owned via a StakeholderMembership, then it must directly or indirectly specialize Requirements::RequirementCheck::stakeholders.

i.e. remove the word "either"

An item may have attributes (see 7.7 ), states (see 7.18 ), and nested item usages

I agree items should be able to have states (e.g. Document has states "underReview", "Reviewed")...

but
exhibitedStates : StateAction [0..*]

ownedStates : StateAction [0..*]

are in Parts (not in Item) ... is this wrong??

An item may have attributes (see 7.7 ), states (see 7.18 ), and nested item usages

I agree items should be able to have states (e.g. Document has states "underReview", "Reviewed")...

but
exhibitedStates : StateAction [0..*]

ownedStates : StateAction [0..*]

are in Parts (not in Item) ... is this wrong??

validateUsageVariationMembership is missing a OCL statement

checkItemUsageSubitemSpecialization should have description

An ItemUsage that is composite and has an owningType that is an ItemDefinition or ItemUsage must specialize the System model Library ItemUsage Items::Item::subitems

should sunroof be multiplicity 0..1? for optional?... or is this another way to show optional (but not stated in the standard)..

sunroof does not have any variants... that simply means model is not yet concrete?

Change ItemUsage is a ItemUsage to ItemUsage is an OccurenceUsage

on a EnumerationDefinition we want isVariation=true and readonly (should not be allowed to be changed

Subclause 7.27 shows a metadata node attached to a usage with a dotted connector. This is not supported by the GBNF. metadata-feature-annotation-node defined in subclause 8.2.3.27 should be included with the annotation-node production in subclause 8.2.3.4.

Graphical BNF does not allow a metadata compartment.

Decision/MergeNodes are (indirectly) typed by KerML:Decision/MergePerformance (via specialization of Actions::Action::decisions/merges), which KerML Clause 9.2.9.1 (Control Performances Overview) requires:

Successions going out of Steps typed by DecisionPerformance or its specializations must:
• ...
• be included in a Feature of its featuringBehavior that unions (see 7.3.2.7) all the outgoing Successions, and is bound to the outgoingHBLink of the Step (see 7.3.4.6 on feature chaining).

Successions coming into Steps typed by MergePerformance or its specializations must:
• ...
• subset a Feature of its featuringBehavior that unions all the incoming Successions, and is bound to the incomingHBLink of the Step.

while constraints in 8.3.16.7 (DecisionNode) and 8.3.16.13 (MergeNode) say

checkDecisionNodeOutgoingSuccessionSpecialization
All outgoing Successions from a DecisionNode must subset the inherited outgoingHBLink feature of the DecisionNode.
sourceConnector->selectByKind(Succession)-> forAll(subsetsChain(this,
resolveGlobal("ControlPerformances::MergePerformance::outgoingHBLink")))

checkMergeNodeIncomingSuccessionSpecialization
All incoming Successions to a MergeNode must subset the inherited incomingHBLink feature of the MergeNode.
targetConnector->selectByKind(Succession)-> forAll(subsetsChain(this,
resolveGlobal("ControlPerformances::MergePerformance::incomingHBLink")))

with similar text in 7.16.1 (Actions Overview), under Sequencing of Actions, 7.16.3 (Control Nodes), and 8.4.12.4 (Control Nodes) under Decision / Merge Nodes. These constraints allow outgoing/incomingHBLink to have values that are not identified by outgoing/incoming successions when none of the successions is traversed. The KerML pattern above introduces a feature unioning the successions and binding it to a chain through decision/merge to outgoing/incomingHBLink, ensuring the HB links are identified by the successions. See Annex A.3.7 (Timing for behaviors, Decisions and merges) for an example, at the end of the model to be executed (first code listing), under "Decision and merge timing constraints".

The OCL for the constraint checkDecisionNodeOutgoingSuccessionSpecialization references the library element ControlPerformances::MergePerformance::outgoingHBLink, but the correct qualified name is ControlPerformances::DecisionPerformance::outgoingHBLink

The notation tables show various permutations of send/receive actions with various parameter options. They are all shown against a single simple textual example. It is unclear what is the purpose of rationale each permutation.
Graphical Examples need to align with corresponding text examples.

In the description and OCL for the constraint checkViewpointDefinitionSpecialization, Views::Viewpoint should be replaced with Views::ViewpointCheck. In the description and OCL for the constraint checkViewpointUsageSpecialization, Views::viewpoints should be replaced with Views::viewpointChecks.

The namingFeature of a RenderingUsage that is a viewRendering (i.e., owned via a ViewRenderingMembership) should be the referencedRendering of the owning ViewRenderingMembership.

The constraint checkRequirementUsageSubrequirementSpecialization requires that a composite RequirementUsage whose ownedType is a RequirementDefinition or RequirementUsage specialize RequirementCheck::subrequirements. However, RequirementCheck::subrequirements subsets RequirementCheck::constraints, which is the set of required constraints of the requirement. So it doesn't make sense for a RequirementUsage to specialize subrequirements if it is owned as an assumed constraint.

The constraint checkIncludeUseCaseSpecialization should be named checkIncludeUseCaseUsageSpecialization.

In 8.2.2.17.4 Send and Accept Action Usages, the payload parameter of an AcceptActionUsage is parsed as being owned by a ParameterMembership. This requires that the parameter have the direction in (see 8.3.4.6.4). However, the payload parameter of the base library definition Actions::Action has the direction inout. While it is valid to redefine an inout parameter with an in parameter, it is generally the output payload value that is desired from an accept action. Therefore, the payload parameter of an AcceptActionUsage should also have direction inout.

The graphical notation for allocating a flow to a connection, that is consistent with textual notation, is missing.

This should be added.

1. The GBNF production for a transition is wrong, it does not account for nodes which are not states (e.g. control nodes)

2. The production for states actions compartment is incorrect, the compartment name is currently named "states" while it should be named "state actions".

It is possible to define flow usage in several ways.

One - use the simple/nice notation where syntactic sugar hides the underlying complexity:

   flow of SomeItemDefinition from firstEndCon to secondEndCon;

Second- use full available detailed notation allowing precise definition of the characteristics of the payload

   flow {
      :>>payload: SomeItemDef; //note more characteristics for payload can be modeled here - especially useful when flows are inherited
      end ::> firstEndCon;
      end ::> secondEndCon;
   }

Sometimes the second, detailed way is the only way to define characteristics of the payload in the more complex cases (especially when the flows are inherited/specialized in the hierarcy).

Now the problem is that two different models are created for these two cases. PayloadFeature is created for the first/nice/short case while simple ReferenceUsage is created for the full/complete case.

It seems that PayloadFeature (meta)type is mostly a syntactic marker. So perhaps it would be possible to get rid of it entirely and make the two cases equivalent from the abstract syntax/model standpoint?

This non-uniformity causes several technical problems down the line.

• It does not allow to have other kind of features (for example ReferenceUsage in SysML) as item features on Flows. ReferenceUsage is not inherited from PayloadFeature
• PayloadFlow::payloadFeature derived property returns only owned flow payload feature, but in practice actual (owned or inherited) one should be returned.

The second problem could perhaps be solved by e.g. changing the definition of the payloadFeature property in the abstract syntax to be the feature that specializes `Transfer::payload`, whether or not it is owned or inherited, and whether or not it is a PayloadFeature. The derivation would not be as simple as the current one, but it would be a reasonable suggestion.

In current implementation each FlowUsage owned by PartUsage subsets (automatically) 3 features:

1. FlowUsage::flows
2. PartUsage::subparts
3. ActionUsage::ownedActions

This could be optimized for the sake of model size. Maybe it would be better idea to introduce

    Part::Part::ownedFlows :> ownedActions, subparts, flows

and define something like CheckFlowConnectionSubFlowSpecialization constraint?

Clause 8.3.16.5 (AssignmentActionUsage), Description, says:

An AssignmentActionUsage is an ActionUsage that is defined, directly or indirectly, by the ActionDefinition AssignmentAction from the Systems Model Library. It specifies that the value of the referent Feature, relative to the target given by the result of the targetArgument Expression, should be set to the result of the valueExpression.

but does not require the model to specify when the expression is evaluated (or its owner, AFAICT).

in the graphical notation for states the compartment name is
"exhibit states" ... yet in the example in
table 17

there is exhibits and exhibitedBy

is this a mistake?

1. The perform-actions-swimlanes production does not appear to be used anywhere.
2. The swimlane production only appears to support vertical swimlanes. i.e., with the action flow displayed below the head rather than to the right of it. Horizontal swimlanes should also be supported.
3. There is no production for the <<performer>> keyword in the head of a swimlane. The appropriate production appears to be Usage-name-compartment (which is missing, as was noted in SYSML21-251), but this name should probably be changed to be more specific to this usage, e.g., swimlane-name-compartment or performer-name-compartment to be consistent with the names of other similar productions.
4. The note "Note. All swimlanes are attached to each other on vertical edges and aligned along the top and bottom horizontal edges." in 8.2.3.17 does not appear to be followed by the examples of swimlanes that appear in Table 15.
5. The swimlanes production have squared (right-angled) corners, but rounded corners appear in the examples in Table 15.

There is no rule that maps a property typed by a Signal. It should be mapped to an item usage.

The SysML v1 stereotype Stakeholder is applied to Classifiers. Therefore, it could also be other model elements than Class which represent stakeholders. The usage of Actor is quite common.

Actors are mapped to PartDefinition. Therefore, Stakeholders should also be mapped to PartDefinition which makes it more consistent. Stakeholders and Actors are different concepts, but there seems to be no reason to map them differently to parts and items.

If permitted, the transformation must also enable the mapping of SysML stereotypes that extend specialized metaclasses. For example, Satisfy based on Realization or Block based on Activity.

Although deprecated, FlowSpecifications are still part of SysML v1 and there should be a defined mapping for the element.

Although deprecated, FlowPorts are still part of SysML v1 and there should be a defined mapping for the element.

The mapping of a ProfileApplication is not covered by the transformation.

ConnectorProperty is deprecated but still part of SysML v1.7. So, the transformation should provide a mapping for it.

Unfortunately, a small error has crept into the resolution of SYSML2_-203.

The mapping class InitialStateMembership_Mapping should be named InitialStateSubactionMembership_Mapping and the general mapping of the mapping class should be GenericToSubactionMembership_Mapping.

Accordingly, change InitialStateMembership_Mapping in Helper::stateOwnedRelationship() to InitialStateSubactionMembership_Mapping.

An object flow with a guard is mapped to a conditional succession and a succession flow. Conditional succession targets the succession flow. Both have the decision node as the source element. However, only one succession outgoing decision node can be taken.

Change the mapping to:

first sourceNode if guardCondition.result then objectFlow {
  constraint guardCondition {
    bind result = guardCondition.result;
    calc guardCondition {
      language "English"
      /*
       * guard says ok
       */
    }
}
flow objectFlow from sourceNode to targetNode;
first source then target;

The source and target of the flow succession are parameters (the target elements of the corresponding SysML v1 ObjectNodes). The source and target of the succession are the owner of the object nodes. Exceptional cases are control nodes.

The pins of a CallBehaviorAction are not mapped. Although the parameters of the action usage are inherited from the action definition, the pins must be mapped since they can have different names than the behavior parameters, different types, etc.

An ObjectFlow is mapped to a succession flow including the specification of the payload: "...of <type>".

The type of the flowing objects cannot be precisely determined (for example, if the source of the object flow is a merge node). Additionally, the ObjectFlow in SysML v1 also has no relationship to the type of the flowing objects.

Currently, ActivityParameterNodes are not mapped to v2. Instead, only the Parameter of the Activity is mapped to a parameter of the ActionDefinition. However, it is not possible to connect the parameter by a succession flow with a parameter of an action usage, for example.

Instead, map an ActivityParameterNode to an ActionUsage with corresponding input and output parameters and bind the ActionDefinition parameter with the corresponding ActionUsage parameter. For example:

action def {
  in inputParameter: Integer;
  bind inputParameter = __inputParameter.outbound;
  action __inputParameter {
    in ref outbound;
    out ref inbound: Integer;
  }
}