2026-01 - SysML v2 Pilot Implementation

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

Language Features

1. Trig function evaluation. The library functions from the TrigFunctions package are now implemented for non-model-level evaluation.
   [PR #731]

Model Libraries

None.

Backward Incompatibilities

There are no backward incompatibilities in the textual notation representation of the model. However, the in-memory EMF and serialized XMI representations have the following incompatibilities.
[PR #734]

1. Getters and setters. The following getter and setter methods previously had special handwritten implementations, but now function as just regular getters and setters. This means that it is now the responsibility of the constructor of a model to ensure that the corresponding abstract syntax properties have values consistent with various validation constraints. For example, the isEnd property of the ownedMemberFeature of an EndFeatureMembership will no longer be automatically be true, but must be explicitly set to true to meet the validateEndFeatureMembershipIsEnd constraint. (For the textual notation, this is mostly by post-processing after Xtext parsing.)

   • CommentImpl.setBody
   • ElementImpl.setDeclaredName and setDeclaredShortName
   • FeatureImpl.isDirection and isEnd
   • FlowUsage.isAbstract
   • LiteralString.setValue
   • Membership.setMemberName and setMemberShortName
   • PortUsageImpl.isComposite
   • RequirementDefinition.setReqId
   • RequirementUsage.setReqId
   • TextualRepresentation.setLanguage and setBody
   • UsagImpl.isComposite

2. Default value overriding. The overriding of metaproperty default values is now implemented by setting the property to the appropriate default value in the constructor for a metaclass Impl, rather than by overriding the getter for the property. It is now possible to subsequently change the value from the default, even if this would violate a validation constraint. For example, when an AttributeUsage is created, the default value for isComposite is false, but it is possible to use the setIsComposite method to set this to true, even though this would violate the validateAttributeUsageIsReferential constraint.

3. Validation. The following validation constraints were previously not being checked, since they were automatically satisfied due to getter overrides. Since these getter overrides have now been removed, checks have been implemented for all the constraints.

   KerML

   • validateEndFeatureMembership
   • validateParameterMembership
   • validateCollectExpressionOperator
   • validateFeatureChainExpressionOperator
   • validateIndexExpressionOperator
   • validateSelectExpressionOperator
   • validateFlowEndIsEnd

   SysML

   • validateUsageIsReferential
   • validateReferenceUsageIsReferential
   • validateAttributeUsageIsReferential
   • validateEnumerationDefinitionIsVariation
   • validateEventOccurrenceUsageIsReference
   • validatePortUsageIsReference

4. XMI serialization. The default for the Feature::isComposite property is false. Since XMI is usually serialized without including properties that have their default value, this means that isComposite=false should not be serialized. However, this previously was being serialized in the case of SysML usages that were required to be referential (i.e., always have isComposite=false). It is no longer being serialized in these cases. This effects the following elements:

   • AttributeUsage
   • BindingConnectorAsUsage
   • EventOccurrenceUsage
   • ExhibitStateUsage
   • IncludeUseCaseUsage
   • PerformActionUsage
   • ReferenceUsage
   • SuccessionAsUsage

   Note. This affects the XMI serialization of the standard library models.

Jupyter

None.

Visualization (PlantUML)

Bug fix.

Technical Updates

1. Eclipse environment. The Eclipse environment required for Pilot Implementation development has been updated to the 2025-12 release (Java 21).
   [PR #732]
2. EMF metamodel implementation. A number of updates have been made to remove handwritten code from EMF-generated Java Impl classes and to make the abstract syntax implementation more strictly conformant to the KerML and SysML specifications. This should have no effect on user modeling using the textual notation. However, there are some functional changes in the direct programmatic access to the abstract syntax representation of a model (see the items under "Backwards Incompatiblities" above).
   [PR #734]

Bug Fixes

1. getImportedMembership. Fixed an infinite recursion caused by a circular recursive import when calling getImportedMembership.
   [PR #729]
2. Inherited connections (PlantUML). Corrected the rendering of nested inherited connections with SHOWINHERITED style.
   [PR #730]
3. getLocale. Fixed the unescaping of the locale of a comment.
   [PR #735]

2025-12 - SysML v2 Pilot Implementation

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

Language Features

1. Library function evaluation. The following additional library functions are now implemented for non-model-level evaluation:

   • All SequnceFunctions
   • All CollectionFunctions
   • All ControlFunctions
   • DataFunctions::max and min

   In addition, model-level evaluable equality operators (== and !=) now work on Collections.
   [PR #727]

Model Libraries

None.

Backward Incompatibilities

None.

Jupyter

None.

Visualization (PlantUML)

None.

Technical Updates

1. BNF Extractor Tool. A BNF Extractor tool is now available in the directory tool-support/bnf-grammar. This tool extracts the normative BNF for the KerML textual notation and SysML textual and graphical notations from the corresponding specification documents. It then generates consolidated grammar files in text or HTML format. For details, see the README.adoc file in the bnf-grammar directory.
   [PR #720]

Bug Fixes

1. getEnumeratedValue and getVariant. Fixed the implementation of the EnumerationDefinition operations getEnumeratedValue and getVariant.
   [PR #723]
2. Actors and stakeholders. Fixed the implicit redefinition of actor and stakeholder parameters.
   [PR #724]
3. objects and subobjects. Corrected the implicit specialization of Objects::objects and Objects::Object::subobjects in certain cases for port usages and occurrence usages.
   [PR #725]

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