2025-11 - SysML v2 Pilot Implementation

This is an incremental update to the 2025-10 release. It corresponds to Eclipse plugin version 0.54.0.

Language Features

1. Control function evaluation. Invocations of the functions ControlFunctions::collect and ControlFunctions::select can now be evaluated, which also allows the evaluation of collect expressions (seq.{...}) and select expressions (seq.?{...}). Per the specification, these functions are also model-level evaluable, but, unfortunately, a problem with the current specification of the model-level evaluablity of body expressions (see KERML11-178) prevents them from be used in useful cases in model-level expressions.
   [PR #718]

Model Libraries

None.

Backward Incompatibilities

1. Name resolution. Previously, in certain cases a qualified name used as a redefinition target resolved inconsistently in the Eclipse Xtext editor and Jupyter. For example, in the model below, in Eclipse, x::y initially resolved to B::x::y in the outline tree view, but was re-resolved to A::x::y before validation. In Jupyter, it always resolved to B::x::y, which resulted in a validation error, due to B::x::y redefining itself.

   item def A {
       item x { 
           attribute y;
       }
   }
   
   item def B :> A {
       item x :>> x {
   	    attribute :>> x::y;
       }
   }
   

   The name resolution algorithm has now been updated so that x::y always resolves to A::x::y, in both Eclipse and Jupyter, with no validation error.
   [PR #717]

2. Model-level evaluable functions. The following functions had previously been implemented as model-level evaluable, but they are not specified as model-level evaluable in the specification. Conformant with the specification, they are now longer model-level evaluable, though they can still be used and evaluated in non-model-level evaluable expressions.

   • NumericalFunctions::prod
   • NumericalFunctions::sum
   • SequenceFunctions::excludes
   • SequenceFunctions::includes
   • SequenceFunctions::isEmpty
   • SequenceFunctions::notEmpty
   • SequenceFunctions::size
   • StringFunctions::Length
   • StringFunctions::Substring

   [PR #718]

Jupyter

None.

Visualization (PlantUML)

None.

Technical Updates

1. Library KPARs. The Maven build has been updated so that the each of the libraries under sysml.library is packaged into a KerML Package Archive (KPAR) file, using a Maven plugin for the Sysand librarian tool. The generated KPAR files are place in the sysml.library/output directory (not committed to the repository). On a release build, the KPAR files are automatically attached as artifacts to the GitHub release.
   [PR #713]

Bug Fixes

1. getDirectedUsage. Fixed the implementation of Definition::getDirectedUsage.
   [PR #712]
2. Item usages. Removed the incorrect validation requiring item usages to be typed by only item definitions.
   [PR #715]
3. Constant end features. Corrected the KerML grammar to allow const on end features.
   [PR #716]
4. Name resolution. Corrected inconsistency in the resolution of qualified names used as redefinition targets.
   [PR #717]

2025-10 - SysML v2 Pilot Implementation

This is an incremental update to the 2025-09.1 release. It corresponds to Eclipse plugin version 0.53.0.

Language Features

Bug fixes.

Model Libraries

None.

Backward Incompatibilities

1. Usage typing. KerML allows a feature to by typed by any other kind of type, including another feature. However, in SysML, a usage can only be typed by a definition (or a KerML classifier). Previously, the validation for this was not properly implemented for reference usages and usages with a user-defined keyword but no regular kind keyword. This has now been corrected, but, as a result, some models that previously validated may now produce errors.

   For example, the following model will now produce the indicated error, where there was no error before:

   attribute def A;
   attribute a;
   ref x : a, A; // ERROR: A usage must be typed by definitions.
   

   [PR #707]

2. Protected name visibility. Members of a type that are declared protected are supposed to be visible in specializations of the type but not otherwise outside the type's namespace. Previously, this was implemented correctly for qualified names, but a protected member could still be accessed using a feature chain. This has now been corrected, but, as a result, some models that previously parsed may not produce errors.

   For example, in the following model, the name b previously resolved in the feature chain p.b, but it will now produce a name resolution error:

   part p {
       public attribute a;
       protected attribute b;
       private attribute c;
   }
   
   alias a1 for p::a; // No error
   alias b1 for p::b; // Name resolution error
   alias c1 for p::c; // Name resolution error
   
   attribute a2 redefines p.a; // No error
   attribute b2 redefines p.b; // Name resolution error (previously no error)
   attribute b3 redefines p.c; // Name resolution error
   

   [PR #709]

Jupyter

1. JupyterLab 4.x. The Jupyter deployment has been updated for JupyterLab 4.x, the latest major revision available. Previous versions of JupyterLab and Jupyter Classic Notebook are no longer supported. (The Jupyter kernel for SysML v2 should still run with older versions, but keyword highlighting in the browser will not work.)
   [PR #696]

Visualization (PlantUML)

Bug fix.

Technical Updates

None.

Bug Fixes

1. Usage typing. Corrected the validation disallowing a usage to be typed by another usage in SysML.
   [PR #707]
2. Default multiplicities. Fixed the adding of a default multiplicity to a usage with a nested alias declaraion.
   [PR #708]
3. Protected name visibility. Fixed the incorrect visibility of protected names used in feature chains.
   [PR #709]
4. Transition visualization (PlantUML). Fixed a possible null pointer exception when a state model is loaded from the repository.
   [PR #710]

2025-09.1 - SysML v2 Pilot Implementation

This release is the same as the 2025-09 release, except for one additional bug fix (to correct a bug introduced in the 2025-09 release). It corresponds to Eclipse plugin version 0.52.1.

The release notes for 2025-09 are repeated below for convenience, along with the additional bug fix at the end.

Language Features

Bug fixes.

Model Libraries

None.

Backward Incompatibilities

1. Name Resolution. Name resolution has been corrected for certain cases of redefinition. For example, consider the following model:

   part def A {
       ref f;
   }
   
   part def B specializes A {
       ref redefines f {
             ref g;
       }
   }
   
   part def C specializes A, B {
       ref subsets f {
             ref redefines g; // ERROR: Couldn't resolve reference to Feature 'g'.
       }
   }
   

   Previously, this model generated the indicated error, because the name resolution algorithm traversed specializations in order, stopping if it found a resolution for the name. But, if the order of the specialized types was changed from A, B to B, A, then the error would go away. Now the redefinition for g resolves correctly regardless of the order of the specialization of A and B.
   [PR #686]

Jupyter

None.

Visualization (PlantUML)

Bug fix.

Technical Updates

None.

Bug Fixes

1. RootPackageTest. Corrected the KerML Xpect RootPackageTest so it is properly included in the test suite.
   [PR #685]
2. Name resolution. Fixed an anomaly in the resolution of the name of a redefined feature due to certain forms of diamond specialization.
   [PR #686]
3. Transition trigger visualization (PlantUML). Corrected the visualization of triggers on state transitions.
   [PR #689]
4. Individual definitions. Fixed the implicit specialization of individual definitions declared as anything more specific than an occurrence definition.
   [PR #693]
5. Semantic metadata. Fixed computation of the base type of an application of semantic metadata.
   [PR #701]
6. Feature typing. Fixed a bug in the computation of feature types resulting from changes in PR #701.
   [PR #705]

2025-09 - SysML v2 Pilot Implementation

This is an incremental update to the 2025-07 release. It corresponds to Eclipse plugin version 0.52.0.

Language Features

Bug fixes.

Model Libraries

None.

Backward Incompatibilities

1. Name Resolution. Name resolution has been corrected for certain cases of redefinition. For example, consider the following model:

   part def A {
       ref f;
   }
   
   part def B specializes A {
       ref redefines f {
             ref g;
       }
   }
   
   part def C specializes A, B {
       ref subsets f {
             ref redefines g; // ERROR: Couldn't resolve reference to Feature 'g'.
       }
   }
   

   Previously, this model generated the indicated error, because the name resolution algorithm traversed specializations in order, stopping if it found a resolution for the name. But, if the order of the specialized types was changed from A, B to B, A, then the error would go away. Now the redefinition for g resolves correctly regardless of the order of the specialization of A and B.
   [PR #686]

Jupyter

None.

Visualization (PlantUML)

Bug fix.

Technical Updates

None.

Bug Fixes

1. RootPackageTest. Corrected the KerML Xpect RootPackageTest so it is properly included in the test suite.
   [PR #685]
2. Name resolution. Fixed an anomaly in the resolution of the name of a redefined feature due to certain forms of diamond specialization.
   [PR #686]
3. Transition trigger visualization (PlantUML). Corrected the visualization of triggers on state transitions.
   [PR #689]
4. Individual definitions. Fixed the implicit specialization of individual definitions declared as anything more specific than an occurrence definition.
   [PR #693]
5. Semantic metadata. Fixed computation of the base type of an application of semantic metadata.
   [PR #701]

2025-07 - SysML v2 Pilot Implementation

This is an incremental update to the 2025-06 release. It corresponds to Eclipse plugin version 0.51.0.

Language Features

Bug fixes.

Model Libraries

Kernel Semantic Library

1. Name collisions. The following models were updated to avoid name collisions due to diamond inheritance:

   • FeatureReferencingPerformances
   • Objects
   • Observation
   • Occurrences
   • Transfers

   [PR #679]

2. Transfers. The features transfers and messageTransfers are now steps instead of flows. As a result, these features no longer have spurious implied subsettings of flowTransfers.
   [PR #682]

3. Transition performances. In the TransitionPerformance model, in TransitionPerformance::accept, the nested redefinition of receive was removed and replaced with a binding connector. This allows the receive parameter of the accepter in a SysML TransitionUsage to be redefined and bound.
   [PR #683]

Kernel Function Library

1. Name collisions. The VectorFunctions model was updated to avoid name collisions due to diamond inheritance.
   [PR #679]

Systems Library

1. Trade studies. The TradeStudies model for TradeStudyObjectives has been updated to avoid validation errors when the objective of a TradeStudy is redefined as intended, to give it a concrete type such as MinimizeObjective or MaximizeObjective.
   [PR #676]

2. Name collisions. The following models were updated to avoid name collisions due to diamond inheritance:

   • Actions
   • Connections
   • Flows
   • Items
   • Metadata
   • Parts
   • Ports
   • SysML
   • Views

   [PR #679]

3. Flows. The flow definition Message and the flow usage messages no longer have owned end features. As a result, messages no longer has a spurious implied subsetting of flows.
   [PR #682]

4. Assignments. In the Actions model, in Action::assignments, a nested owned parameter target was added. This ensures that the parameters redefined by an ActionUsage are target and replacementValues, in that order.
   [PR #683]

Geometry Domain Library

1. Name collisions. The following models were updated to avoid name collisions due to diamond inheritance:

   • ShapeItems
   • SpatialItems

   [PR #679]

Quantities and Units Domain Library

1. Name collisions. The following models were updated to avoid name collisions due to diamond inheritance:
   • SI
   • USCustomaryUnits

Requirement Derivation Domain Library

1. Name collisions. The DerivationConnections model was updated to avoid name collisions due to diamond inheritance.

Backward Incompatibilities

1. Subjects and objectives. Previously, if a requirement definition/usage or case definition/usage was parsed without an owned subject and/or objective, then a subject or objective element was physically inserted into the parse tree by the relevant adapter. Starting with this release, these insertions are no longer being done, which is more conformant with the SysML specification. However, the previous insertion of subjects meant that the validation checks for the subject being the first parameter were satisfied even if the subject was not declared explicitly and there were additional parameters. This is no longer necessarily the case.

   For example, the following requirement definition would previously have not produced an error, but now results in a "Subject must be first parameter" validation error.

   requirement def R {
       // Error: Subject must be first parameter.
       in x;
   }
   

   In particular, stakeholders and actors are kinds of parameters, so a subject must always be explicitly declared if stakeholders and/or actors are also declared.

   concern c {
       subject; // Required to avoid error.
       stakeholder s;
   }
   use case uc {
       subject; // Required to avoid error.
       actor a;
   }
   

   Note that this is the case even when specializing a supertype with an inheritable subject:

   use case uc1 {
       subject subj;
   }
   use case uc2 :> uc1 {
       subject subj; // Implied redefinition of uc1::subj.
       actor a;
   }
   use case uc3 :> uc, uc1 {
       subject; // Required to avoid "Only one subject is allowed" error.
   }
   

   [PR #677]

2. Validation. Existing models may now get distinguishibility warnings that were not previously generated. For example, the following model previously did not cause a warning, but now it does as indicated.

   part def Vehicle {
       part wheels [2..*] : Wheel;
   }
   part def Car :> Vehicle {
       part :>> wheels [3..4];
   }
   part def Truck :> Vehicle {
       part :>> wheels [4..18];
   }
   part def SUV :> Car, Truck; // Warning: Duplicate of inherited member name 'wheel'
   

   The warning can be removed by redefining both Vehicle::wheels and Truck::wheels within SUV:

   part def SUV :> Car, Truck {
       part :>> Car::wheels, Truck::wheels;
   }
   

   [PR #679]

3. Spatial items. The item definition SpatialItems::SpatialItem from the Geometry Model Library redefines the feature localClock so that it is typed by Time::Clock from the Quantities and Units Domain Library. However, localClock is also redefined in Occurrences::Occurrence::suboccurrences, which is indirectly specialized by Items::Item::subitems. As a result, declaring a subitem that is a SpatialItem within another SpatialItem now results in a warning.

   item def SpacialItemWithSubitem :> SpatialItem {
       // Warning: Duplicate of inherited name 'localClock' from SpatialItem, suboccurrences
       item aSubItem : SpatialItem; // implied subsetting of subitems
   }
   

   In order to avoid having to further redefine localClock within every such subitem declaration, additional features have been added to SpatialItem:

   • subSpatialItems – Subset this for subitems that are SpatialItems.
   • subSpatialParts – Subset this for subparts that are SpatialItems.
   • componentParts – Subset this for component items that are parts (instead of subsetting componentItems).

   item def SpacialItemWithSubSpacialItems :> SpatialItem {
       item aSubSpaitalItem :> subSpatialItem;
       part aSubSpaitalPart :> subSpatialPart;
   }
   item def SpacitalItemWithComponents :> SpatialItem {
       item aComponentItem :> componentItems; // Per specification
       part aComponentPart :> componentParts;
   }
   

   [PR #679]

4. Messages. The end features source and target of Mssages::Message and Messages::messages are now inherited and are no longer occurrence usages. This means that they cannot be used as the referenced occurrences in an event occurrence usage. However, this is appropriate, because the referenced events for a message should instead be sourceEvent and targetEvent which are still occurrence usages.
   [PR #682]

5. Binary connectors/connections. Correction of the validateConnectorBinarySpecialization check may result both in cases in which a previously valid connector/connection declaration becomes invalid or a previously invalid declaration becomes valid.
   [PR #682]

Issue Resolutions

The KerML 1.1 ans SysML 2.1 RTFs have not yet approved any issue resolutions. However, this release includes proactive resolutions to the following issues to correct library models, largely to avoid validation errors that have now been identified due to corrections in validation checking.

KerML

• KERML11-76 Library models have inherited member name collisions
• KERML11-78 Transfers::transfers and Transfers::flowTransfers subset each other
• KERML11-79 TransitionPerformance::accept is incorrect

SysML

• SYSML21-318 Diamond inheritance problem with TradeStudy
• SYSML21-322 Library models have inherited member name collisions
• SYSML21-324 Flows::messages and Flows::flows subset each other
• SYSML21-327 AssignmentAction parameters get reordered

Jupyter

None.

Visualization (PlantUML)

None.

Technical Updates

None.

Bug Fixes

1. Conditional succession. Fixed the setting of the source of a shorthand conditional succession.
   [PR #678]
2. isDistinguishableFrom. Corrected the implementation of the Membership::isDistinguishableFrom operation.
   [PR #680]
3. Implied binding connectors. Corrected the insertion of implied binding connectors during XMI or JSON export.
   [PR #681]
4. Binary connector validation. Corrected the implementation of the check of the constraint validateConnectorBinarySpecialization to properly handle redefined features when counting connector ends.
   [PR #682]
5. Parameters and end features. Fixed the computation of the parameters and end features of a type, particularly as used in determining the implied redefinitions of these features.
   [PR #683]

2025-06 - SysML v2 Pilot Implementation

This is an incremental update to the 2025-04 release. It corresponds to Eclipse plugin version 0.50.0.

Language Features

Bug fixes.

Model Libraries

Bug fixes.

Backward Incompatibilities

None.

Issue Resolutions

None.

Jupyter

None.

Visualization (PlantUML)

Bug fix.

Technical Updates

1. Continuous integration builds. Removed configuration for Travis CI builds.
   [PR #653]
2. .gitignore files. Updated .gitignore files in xtend-gen folders.
   [PR #654]
3. Eclipse 2025-03. Updated the Eclipse development platform to Version 2025-03 and Java 21.
   [PR #655]
4. Transformaton code. Added annotations to the transformation code in the adapter classes to show where the semantic constraints from the KerML and SysML v2 specifications are satisfied.
   [PR #665]
5. Repository save utility. Updated the default project name used by the repository save utility if no name is explicitly given.
   [PR #670]

Bug Fixes

1. Metamodel files. Corrected the .uml and .ecore metamodel files to be consistent with the normative Beta 4 abstract syntax.
   [PR #657]
2. isCompatibleWith operation. Corrected a non-conformance of the Pilot Implementation with the KerML Specification on the computation of the Feature::isCompatibleWith operation.
   [PR #658]
3. canAccess operation. Fixed a bug in the implementation of FeatureUtil.canAccess for checking accessibility when the subsetting feature has no featuring types.
   [PR #659]
4. Library models. Made small corrections to the KerML Semantic Library model Occurrences and the SysML Analysis Domain Library model TradeStudies.
   [PR #660]
5. XMI serialization. Fixed the serialization of isConstant for end usages and isAbstract for variation definitions and usages.
   [PR #661]
6. Visualization. Fixed a bug that crashed the visualization of a case with a nested action.
   [PR #667]
7. Semantic transformations. Fixed various semantic transformation bugs in the adapter classes.
   [PR #668] [PR #669]
8. Substates. Fixed a bug that caused States::State::substates to inherit two this features (resulting in any state usage that is a substate also inheriting them).
   [PR #671]

2025-04 - SysML v2 Pilot Implementation

This is an incremental update to the 2025-02 release. It corresponds to Eclipse plugin version 0.49.0.

Language Features

1. Control node bodies. In the SysML abstract syntax, control nodes (i.e., fork, join, decide and merge nodes) are kinds of action usages that are typed by ControlActions from the Systems Model Library. The abstract syntax allows control nodes to have any sort of owned members that other kinds of action usages can. However, the textual notation syntax previously allowed only annotations to be declared in the body of a control node. This has now been corrected to allow control nodes to have regular action bodies.

   In particular, with this change, it is possible to declare control nodes with parameters, enabling the modeling of flows through them. For example:

   action def A {
       action a1 {
           out x1;
       }
       then j1;
   
       action a2 {
           out x2;
       }
       then j1;
   
       flow a1.x1 to j1.x1;
       flow a2.x2 to j1.x2;
   
       join j1 {
           in x1;
           in x2;
           out y = (x1, x2);
       }
       then a3;
   
       flow j1.y to a3.y;
   
       action a3 {
           in y;
       }
   }
   

   Note that it is still necessary to have successions (or succession flows) into and out of control nodes in order to get the proper "control" semantics.
   [PR #642]

2. Constructor expression evaluation. The model-level evaluation of a constructor expression has been implemented to simply return the result parameter of the expression. This works, because a constructor expression is parsed as an expression whose instantiated type is instantiated by its result parameter, with argument expressions bound to appropriate features of the instantiatedType.

   For example, given the following:

   part def P {
      attribute a;
      attribute b;
   }
   part p = new P(1,2);
   attribute p_a = p.a;
   attribute p_b = p.b;
   

   the feature p evaluates to the result parameter of the constructor expression, which is a usage of P with its attributes bound to the argument expressions. Therefore, p_a evaluates to the literal integer 1 and p_b evaluates to the literal integer 2.
   [PR #645]

Model Libraries

None.

Backward Incompatibilities

None.

Issue Resolutions

This release includes implementation of resolutions to the issues listed below.

KerML

The resolution for the following issues was approved on KerML FTF2 Ballot 7. It was previously implemented, except for the model-level evaluation of constructor expressions.

• KERML_-224 Corrections to Ballot 5 resolutions

SysML

The resolution for the following issue was approved on SysML v2 FTF2 Ballot 7. (This resolution should have been implemented in the 2025-02 release, but it was missed.)

• SYSML2_-262 Flows cannot connect control nodes

The resolution for the following issue, approved on SysML v2 FTF2 Ballot 9, had already been previously implemented.

• SYSML2_-803 Correction to the resolution of SYSML2_-510

Jupyter

1. %projects command. The magic command %projects has been added to list the name and identifier of all projects in the repository.
   [PR #616]

2. %load command. The magic command %load has been added to load models from a project in the repository.

   %load [--id=<PROJECT ID>] [--name=<NAME>] [--branchid=<BRANCH ID>] [--branch=<BRANCH_NAME>] [<NAME>]
   
   Download previously published models from a project in the repository. (Use %projects to view repository contents.)
   Named elements of the downloaded models may then be referenced by models in the notebook.
   <NAME> is the full name of the project.
   If <PROJECT ID> is given, then the project with that UUID is loaded. In this case, the <NAME> must not be given.
   If <BRANCH NAME> or <BRANCH ID> is given, then the model is loaded from this branch of the project.
   If no <BRANCH NAME> or <BRANCH ID> is given, the default branch is used.
   If <BRANCH ID> is given, then a <BRANCH NAME> must not be given.
   

   [PR #616]

3. %publish command. Previously, the %publish command in Jupyter always created a new project on the API server, posting all elements of a model in the one and only commit on the "main" branch. The command has been updated to post incremental changes based to a specified project based on the delta between the remotely stored models and their local models. (Currently this usually means that the new commit completely replaces the content of the model – since re-parsing a model in Jupyter creates entirely new element UUIDs – but it is at least possible to publish multiple versions of a model in multiple commits to a single project in the repository.)

   Note. Previously, a model was published by default including values for all derived properties. The default is now to publish without derived property values (which greatly reduces the size of the published model). To include derived property values, use the -d option.

   %publish [-d] [--project=<PROJECT NAME>] [--branch=<BRANCH NAME>] <NAME>
   
   Publish the model elements rooted in <NAME> to the repository. <NAME> must be fully qualified.
   Use the -d flag to include derived properties.
   If <PROJECT NAME> is given, it is used as the name of the project to create or update.
   If <PROJECT NAME> is not given, the (simple) name of the model element is used.
       If no project exits with the given name, then a new project with that name is created.
       Otherwise, the existing project is updated with a new commit.
   If <BRANCH NAME> is given, then the model is written to this branch of the project.
   If <BRANCH NAME> is not given, the default branch is used.
   

   [PR #633]

4. %repo command. The magic command %repo has been added to allow the repository API base path to be changed.

   %repo [<BASE PATH>]
   
   Set the API base path for the repository accessed by the %projects, %publish and %load commands.
   <BASE PATH> is a URL (possibly including port number), such as: https://my.domain.com/sysml_repo:9000.
   If <BASE PATH> is not given, the current repository base path is printed.
   If <BASE PATH> is given, the repository base path is set to this.
   

   [PR #644]

Visualization (PlantUML)

1. Shorthand notations. Visualization has been updated to render short hand graphical notations, when possible, for event occurrence, perform action, exhibit state and include use case usages.
   [PR #647]

Technical Updates

1. SysMLv2 menu. A SysMLv2 submenu has been added to the popup menu for projects, with the following options:

   • Generate Library Index: Moved under SysMLv2 menu.
   • Pull model from API: Download models from a repository and save in .sysmlx files. This requires that .settings/org.omg.sysml.remote.properties exists with the following contents:

     base.url=repository url
     remote.projectId=project id
     remote.branchId=branch id
     

     (remote.branchId is optional; if not provided, the default branch is used)

   [PR #616]

2. Jupyter magic commands. The implementation of magic commands for Jupyter has been extended to allow external users to define and register additional commands that can reuse the state of the Jupyter kernel without needing to recompile the existing codebase.
   [PR #649]

3. Continuous integration builds. The running of continuous integration builds has been switched from Travis CI to GitHub Actions.
   [PR #650]

Bug Fixes

1. new keyword. Fixes highlighting of the new keyword in Jupyter.
   [PR #643]
2. Rendering of «variant». Removes the rendering of «variant» for an enumeration definition in PlantUML.
   [PR #646]
3. Operation isCompatibleWith. Adds a Boolean return type to the Feature::isCompatibleWith operation.
   [PR #648]
4. XMI generation. Corrects a possible exception when generating XMI for a model when implied relationships are included.
   [PR #651]

2025-02 - SysML v2 Pilot Implementation

This is an incremental update to the 2024-12 release. It corresponds to Eclipse plugin version 0.48.0.

Language Features

KerML

1. Global scope notation. The qualified name notation has been extended to allow it to optionally have the global scope qualifier $ as its initial segment, as in $::A::B::C. Resolution of the remainder of such a qualified name then begins in global scope, rather than in the local scope in which the qualified name is parsed.
   [PR #635]

2. Variable features. Variable features are features of occurrences whose values may vary over time. This is specified semantically by making the domain of a variable feature (i.e., its featuring type) the snapshots of its owning type, rather the owning type itself. Therefore, a variable feature can have different values on different snapshots of an occurrence, effectively "varying over time". The multiplicity of a variable feature is relative to each snapshot, rather than to the life of the occurrence.

   A variable feature is notated in the concrete syntax using the new keyword var.

   // An instance of a Vehicle is a Life by default.
   struct Vehicle {
       // This feature has a single value for the Vehicle's life.
       //  It is not a feature of its timeslices or snapshots.
       feature id : VehicleId [1];
   
       // This feature can have a different single value on each snapshot of a Vehicle.
       var mileage : Distance [1];
   }
   

   A feature that is specified as variable can, nevertheless, be further specified as constant using the keyword const (instead of var), meaning that it does not actually change its value over the duration of its featuring occurrence (this replaces the previous concept of readonly). This can be useful for asserting that a feature has values that are the same over only some of the time an occurrence exists, even though it could potentially vary at other times.

   struct Vehicle {
       feature id : VehicleId [1];
       var mileage : Distance [1];
   
       portion parked :> timeSlices [*] {
           // When a Vehicle is parked, its mileage does not change.
           const :>> mileage;
       }
   }
   

   The end features of an association structure may also be declared as constant features by placing the keyword const before the keyword end. Whether or not an end feature is declared as constant, its value cannot change for the lifetime of an instance of the owning association structure. However, a constant end feature may subset or redefine a variable feature, while a regular end feature cannot.

   struct AssetOwnershipRecord {
       var feature owner : LegalEntity [1];
       var feature ownedAsset : Asset [1];
   }
   assoc struct AssetOwnershipRelationship specializes AssetOwnershipRecord {
       const end feature redefines owner;
       const end feature redefines ownedAsset;
   }
   

   [PR #637]

3. Constructor expressions. Previously, an invocation expression where the invoked type was not a function acted as a constructor for an instance of the invoked type. Instead, a new constructor expression has now been introduced to do instance construction.

   The concrete syntax for a constructor expression is similar to that of an invocation expression, but preceded by the keyword new.

   class Member {
       feature firstName : String;
       feature lastName : String;
       feature memberNumber : Integer;
       feature sponsor : Member[0..1];
   }
   feature thisMember = new Member("Jane", "Doe", 1234, null);
   feature nextMember = new Member(
       firstName = "John", lastName = "Doe", sponsor = thisMember,
       memberNumber = thisMember.memberNumber + 1);
   

   [PR #638]

4. Flows. What were previously called item flows are now just called flows. There is no change to the concrete syntax, but there are corresponding changes in the Kernel Semantic Library (see below).
   [PR #639]

SysML

1. Send and accept actions. The expressiveness of send action textual notation syntax has been improved. In particular, send action notation of the following form is allowed, in which all parameters are bound in the send action body:

   send{
    inpayload =payloadExpression;
    insender =senderExpression;
    inreceiver =receiverExperssion;
}

   as well as the following mixed forms

   sendpayloadExpression {
    insender =senderExpression;
    inreceiver =receiverExperssion;
}

   and

   sendpayloadExpressionviasenderExpression{
    inreceiver =receiverExperssion;
}

   Further, instead of using feature values, values can also be provided for the nested parameters by using either flows or binding connections outside the send action usage. In addition, in the form

   actionactionNamesend viapayloadExpressiontoreceiverExpression;

   the payload parameter is also implicitly redefined, but it can still be referred to by name (e.g., actionName.payload), for use as the target of a flow or binding connection.

   There is also a similar update to the syntax for accept action usages. The current syntax is

   accepttriggerDeclarationviareceiverExpression;

   It is now also possible to redefine the receiver parameter (but not the triggerDeclaration, which declares an output parameter) in the body of the accept action usage, so it can be given a value using an explicit binding or flow. The proposed notation has the form:

   accepttriggerDeclaration{
    inreceiver =receiverExpression;
}

   [PR #626]

2. Global scope notation. Global scope notation (as described above for KerML) is also available in SysML. This can be particularly useful for accessing a library package that would otherwise be hidden be a local package with the same name. For example, in the following model, the use of the global scope notation means that Requirements::FunctionalRequirementCheck resolves to the appropriate element of the library package Requirements, which would otherwise be hidden by the containing Requirements package.

   package UserModel {
       package Requirements {
           requirement`**`r1 : $::Requirements::FunctionalRequirementCheck;
           ...
       }
   }
   

   [PR #635]

3. Variable features. In SysML, it is already expected that features of occurrences can change over time, particularly for structural occurrences like items and parts. For example, if a Vehicle is modeled as having an engine with multiplicity 1..1, then the expectation is that any individual Vehicle as exactly one engine at any point in time, but may have different engines over time. Therefore, a feature of an occurrence definition or usage in SysML is automatically able to vary in time, except for the following kinds of features, which, instead, have values relative to the entire duration of the featuring occurrence:

   • Time slices and snapshots, because they represent specific portions of the duration of their featuring occurrences.
   • Bindings, because they reflect relationships that can hold across time.
   • Successions, because they determine ordering of occurrences across time.
   • Composite subactions, because their values and ordering across time are determined by succession relationships and other control constructs.

   Since whether a feature may time vary is determined automatically, there is no keyword in SysML corresponding to var in KerML. However, a feature that would otherwise be allowed to vary in time may be declared to nevertheless have a constant value using the constant keyword (which replaces the previous readonly keyword). Such a feature must have the same value over the entire duration of a featuring occurrence.

   occurrence def Flight {
       ref part aircraft : Aircraft;
   }
   occurrence def ApprovedFlight :> Flight {
       // This redefines the aircraft feature so it is constant for
       // an entire ApprovedFlight.
       constant ref part approvedAircraft redefines aircraft;
   }
   

   The constant keyword cannot be used on an end feature in SysML. However, any end feature that is automatically variable is also automatically constant.

   [PR #637]

4. Constructor expressions. Constructor expressions (see description above under KerML) can also be used in SysML.
   [PR #638]

5. Flows. What were previously called flow connection definitions, flow connection usages and succession flow connection usages are now called flow definitions, flow usages and succession flow usages, respectively. There is no change to the concrete syntax, but there are corresponding changes in the Systems Library (see below).
   [PR #639]

6. Time slices and snapshots. Time slices and snaphots are no longer required to be typed (implicitly or explicitly) by their individual definition. This avoids anomalies due to unexpected inheritance.
   [PR #640]

Model Libraries

1. All libraries. The .project.json and .meta.json files in each of the library model directories have been updated to reflect the Beta 3 version of the specification, so that, when the directories are compressed as Zip archives, they produce valid KerML Project Archive (.kpar) files. (These .kpar files where submitted to OMG as normative artifacts with the KerML 1.0 and SysML 2.0 Beta 3 specifications, but the files are not themselves included in the SysML 2 Pilot Implementation repository.)
   [PR #641]
2. _Kernel Semant...

2024-12 - SysML v2 Pilot Implementation

This is an incremental update to the 2024-11 release. It corresponds to Eclipse plugin version 0.47.0.

New Features

KerML

1. Cross subsetting. A cross feature of an end feature is specified using a new cross subsetting relationship between an end feature and its cross feature. The cross multiplicity of an end feature refers to the multiplicity of its cross feature, rather than the multiplicity of the end feature itself, which is always 1..1. The cross ordering and uniqueness of end features similarly refer to those of their cross feature.

   Cross subsetting is identified by the crosses keyword or the equivalent symbol =>. For example,

   struct LegalEntity {
       feature assetsOwned [*] ordered : Asset;
   }
   struct Asset {
       feature owningEntities [1..*] : LegalEntity;
   }
   assoc AssetOwnership {
       end owner : LegalEntity crosses ownedAsset.owningEntities;
       end ownedAsset : Asset crosses owner.assetsOwned;
   }
   

   With the specified cross subsetting, creating an AssetOwnership link between a LegalEntity and an Asset means that the Asset must be one of the aassetsOwned by the LegalEntity and that the LegalEntity must be one of the owningEntities of the Asset. As shown above, the target of a cross subsetting relationship must be a feature chain in which the first feature is the other association end and the second feature is the cross feature for that end.

   Cross feature multiplicity effectively constrains the number of instances of an association. It applies to each set of instances (links) of the association that have the same (single) values for each of the other ends. For a binary association, this is the same as the number of values resulting from "navigating" across the association from an instance of one related type to instances of the other related type. Cross feature uniqueness and ordering apply to the instances navigated to, preventing duplication among them and ordering them to form a sequence.

   If an end instead has an owned cross feature, the cross subsetting is implicit. The cross multiplicity, ordering and non-uniqueness can then be declared directly on an end feature, with a notation that makes it clear that these are properties of the cross feature, not the end feature itself:

   assoc AssetOwnership {
       end [1..*] feature owner : LegalEntity;
       end [*] ordered feature ownedAsset : Asset;
   }
   

   If no cross feature is given for an end, then its cross multiplicity is effectively 0..* by default.

   Connector ends declared in the body of a connector may have cross features, specified using cross subsetting, as for association ends. The cross feature for the connector end further constrains any inherited cross feature(s). In the more common shorthand notation for connectors, the cross multiplicity (but not ordering or non-uniqueness) can be given at the before of the end's related feature (previously this was given after the related feature):

   struct WheelAssembly {
       composite feature halfAxles[2] : Axle;
       composite feature wheels[2] : Wheel;
       // Connects each one of the halfAxles to a different one of the wheels.
       connector from [1] halfAxles to [1] wheels;
   }
   

   [PR #608]

SysML

1. Cross subsetting. The crosses keyword can also be used in SysML, with the same meaning as in KerML.

   part def LegalEntity {
       ref part assetsOwned [*] ordered : Asset;
   }
   part def Asset {
       ref part owningEntities [1..*] : LegalEntity;
   }
   connection def AssetOwnership {
       end part owner : LegalEntity crosses ownedAsset.owningEntities;
       end part ownedAsset : Asset crosses owner.assetsOwned;
   }
   

   The notation for owned cross features is also similar:

   connection def AssetOwnership {
       end [1..*] part owner : LegalEntity;
       end [*] ordered part ownedAsset : Asset;
   }
   

   As is the shorthand notation for connection usages (including interface usages):

   part WheelAssembly {
       part halfAxles[2] : Axle;
       part wheels[2] : Wheel;
       // Connects each one of the halfAxles to a different one of the wheels.
       connect [1] halfAxles to [1] wheels;
   }
   

   In addition, for SysML, end features always have a default multiplicity of 1..1, even for kinds of usages that would otherwise not have that default if they were not ends.
   [PR #608]
2. Transfers across interfaces. The semantic library models for ports and interfaces have been updated to formalize the semantics for the automatic targeting of a transfer outgoing from a port at one end of an interface to a port at another end of the interface. That is, if an send action is used to initiate a transfer via a port, then, if that port is at one end of a binary interface, that transfer will automatically target the port at the other end of the interface, and the transfer can then be accepted via that target port. However, a transfer can only have one target, so, if a port is connected to an interface with more than two ends, or to multiple interfaces, the transfer will be targeted to exactly one of the possible target ports across all other interface ends.

   part def DistributedSystem {
       item def Request;
       item def Response;
   
       part client {
           port clientPort;
           action clientBehavior {
               send Request() via clientPort;
               then accept Response via clientPort;
           }
       }
   
       part server {
           port serverPort;
           action serverBehavior {
               accept Request via serverPort;
               then send Response() via serverPort;
           }
       }
   
       // Transfers from the clientPort automatically target the serverPort
       // and vice versa.
       interface client.clientPort to server.serverPort;
   }
   

   [PR #610]

Backward Incompatibilities

1. Reserved words. New KerML and SysML keyword: crosses
2. Flow connections. Flow connection usages are no longer kinds of structural connection usages (which are kinds of part usages). This has no effect on the concrete syntax or behavioral semantics of flows. But it means that, in the abstract syntax, flow connection usages will no longer appear in the list of ownedParts of a Definition or the nestedParts of a Usage. However, they do still appear in the lists of ownedConnections/nestedConnections (since they are still kinds of KerML connectors). Semantically, composite flows are also no longer subparts of a containing Item or Part, but they remain as subactions of a containing Action. The model library elements related to flow connections have been move out of the library package Connections to the new package FlowConnections.
   [PR #607]
3. Cross features. Formerly, cross multiplicities were specified directly on end features, even though this meant they had a different semantics than multiplicities on regular features. With the introduction of cross features, the multiplicity of end features is now required to be 1..1 (like participant properties in SysML v1). Giving an end feature a multiplicity other than 1..1 currently results in a warning, but this will become an error in the future. However, multiplicities in the old position on connector or connection ends in the shorthand notation will result in syntax errors. In either case, the multiplicity should be moved to the position of a cross multiplicity (as shown above).
   [PR #608]
4. Structure/behavior validation. Validations have been added such that a KerML structure cannot specialize a behavior, and vice versa. In SysML, kinds of structures include definitions of items, parts, ports, metadata, renderings and connections (but not flows). Kinds of behaviors include definitions of actions, states, constraints, requirements, cases, views and flows.
   [PR #609]
5. Feature chain expressions. The target of the implied subsetting of the result of a feature chain expression has been updated to be the feature chain of the expression rather than just the final target feature. This has no affect on end-user models.
   [PR #611]
6. Index expressions. Index expressions are now parsed to a new IndexExpression metaclass in the abstract syntax. This has no affect on end-user models.
   [PR #611]
7. Annotations. The abstract syntax for annotations has been revised so that an annotation relationship must be owned be either its annotated element or its annotating element. These were already the only possibilities when parsing from the textual notation.
   [PR #611]
8. Transitions. Transitions in a state model whose source is not a state usage (for example, if the source is the entry action) are now semantically considered to be decision transactions, that is, they have the same semantics as conditional successions in action models. It is therefore now a validation error to have an accepter on such a transition.
   [PR #612]
9. Inheritence. The Beta 2.4 KerML Specification includes a complete specification of the computation of the inherited memberships of a type, and the implementation has now been updated to conform to this. The update resolves certain anomalies in the case of "diamond inheritence" in which a feature could be unexpectedly inherited multiple times, or in which what was inherited depended on the ordering of specializations. Note, however, that the handling of inheritance for name resolution is separate from this computation, and some anomalies still exist when resolving names.
   [PR #613]

Issue Resolutions

This release includes implementation of resolutions to the issues listed below.

KerML

Resolut...

2024-11 - SysML v2 Pilot Implementation

This is an incremental update to the 2024-09 release (there was no 2024-10 release). It corresponds to Eclipse plugin version 0.46.0.

New Features

1. Terminate actions. A terminate action is used to terminate the performance of some other action. It has the form

   actionnameterminateexpression;

   The action part is optional. The expression evaluates to the action to be terminated. The terminated action ends its performance no later than the completion of the terminate action. If the expression is omitted, the default is the immediately containing action of the terminate action.

   action outerAction {
       in action a;
       action term_a terminate a; // terminates a
       then terminate; // terminates outerAction
   } 
   

   A terminate action usage may also be used to terminate a non-action occurrence (such as a part). In this case, the lifetime of the terminated occurrence must end no later than the completion of the terminate action. That is, the terminate action usage effectively "destroys" the terminated occurrence.

   part container {
       part component : Component[0..1];
       action act {
           assign component := Component(); // Create component
           then terminate component; // Destroy component
       }
   }
   

   [PR #597]

Backward Incompatibilities

1. Reserved words. New SysML keyword: terminate

Issue Resolutions

1. SysML Metamodel. The SysML concrete syntax, abstract syntax and model library have been updated consistent with the resolution of the following SysML v2 FTF issue.

   • SYSML2_-44 Transformation of UML4SysML::ActivityFinalNode is not specified yet

     [PR #597]

   The resolution to the following issue had already been substantially implemented, but the implementation has been further updated consistent with the final resolution.

   • SYSML2_-222 TransitionUsage source and target properties do not support feature chains

     [PR #602]

Jupyter

None.

Visualization (PlantUML)

Bug fix.

Technical Updates

1. Caching. Added clearing of the cached effectiveName and effectiveShortName of elements.

   [PR #595]

Bug Fixes

1. Port conjugation. Fixes the setting of the source and conjugatedType fields of a PortConjugation.

   [PR #596]

2. Transition usage. Fixes the parsing of the source of a transition usage when it is a feature chain.

   [PR #600]

3. Transition usage rendering (PlantUML). Fixes the rendering of transition usages to resolve its succession end features correctly.

   [PR #601}

4. Binding connections. Fixes the implicit subsetting of binding connections as usages in SysML models.

   [PR #603]