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

In 8.3.17.5 AssignmentActionUsage, under "Constraints":

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

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).