The description of the Testcase says:

an operation or is called in synchronous manner through the port pp

However the corresponding Activity Diagram in Figure 9.20 doesn't show the "via pp" string, that would signify that this port is to be used for the call.

The notation for the Pins is wrong: They are shown as filled squares, which would mean, that they are referring to streaming Parameters.

Also there are errors in the Class-Diagram Figure 9.18

• The usage on the left is missing the guillemets around «use»
• The dependency on the right should be an InterfaceRealization
• Reception Start and Operation P() should be shown in separate compartments
• The ports are listed in the compartment for attributes. While this is allowed, it is unusual. It would be better to show the ports as squares. At least the conjugated port should show a "~" (this is not defined for attributes, but when a port is shown as attribute, it should also use the port's notation).

Update Figures 9.18 and 9.20

Both diagrams should be updated as indicated in the issue, except that:

• The tooling used for the diagram in Figure 9.18 does not put receptions and operations in different compartments. Receptions and operations also appear together on other class diagrams in Clause 9. Nevertheless, it is still clear what is being specified as a reception and what is being specified as an operation. Therefore, it is not worth manually correcting Figure 9.18 in a way that would be inconsistent with other existing diagrams, or trying to update all diagrams where this occurs.

• In general, the overview class diagrams for test cases in Clause 9 do not show ports at all. These are only shown on the internal structure diagrams. Therefore, it is sufficient to simply remove the port declarations from Figure 9.18, since they are shown on Figure 9.19.

Subclause 6.2 Changes to Adopted OMG Specifications of the Precise Semantics for UML State Machines (PSSM) Beta 1 specification document (ptc/17-04-04) states:

The PSSM syntax is a subset of the UML 2.5.1 abstract syntax metamodel, and the required functionality formalized in PSSM is taken from that specified in UML 2.5.1. However, PSSM is also semantically based on fUML and PSCS. But the current versions of these standards, fUML 1.2.1 and PSCS 1.0 are based on UML 2.4. In order to avoid inconsistency, particularly given the sweeping reorganization of the UML abstract syntax metamodel adopted in UML 2.5, the fUML and PSCS syntax and semantics models have been migrated to UML 2.5.1 for use with PSSM, but with no change to their functionality. In addition, the fUML and PSCS models have been updated to use an approach for identifying and constraining their syntax subsets that is consistent with that used in PSSM.

In adopting this specification, the PSCS RTF was directed to update the PSCS specification consistent with the migration of fUML syntax and semantics models top UML 2.5.1. Since the adoption of PSSM, PSCS 1.1 has been approved as the current version of PSCS, so the PSCS 1.2 RTF now needs to carry out the migration of PSCS 1.1 to UML 2.5.1 for PSCS 1.2.

Migrate PSCS to UML 2.5.1

Migrating PSCS to UML 2.5.1 and adopting the new approach for identifying and constraining their syntax subsets (but with no change to PCSC functionality), requires the following updates to the PSCS specification document:

• Remove subclause 2.2 on conformance levels.
• Update the normative references to UML 2.5.1 and fUML 1.4 and remove any references to the infrastructure/superstructure separation..
• Update subclause 6.1 Changes to Adopted Specifications to remove the reference to UML 2.4.1..
• Update Clause 7 Abstract Syntax to reflect the UML 2.5.1 package structure and the new approach for specifying the PSCS abstract syntax subset.
• Update Clause 8 Semantics to reflect the UML 2.5.1 package structure.

The normative syntax and semantics XMI also need to be updated to reflect the new approach for specifying the abstract syntax subset and for the UML 2.5 reorganization.

The term "behavior proxyport" isn't in SysML, but is used in Annex B many times. Ports can't be both behavioral and proxy. Informally, both kinds of port "stand in" for other objects, but behavior ports stand in for the owning object, while proxy ports stand in for internal parts. I think the Annex is referring to behavior ports, at least I recall Clause 11.2.2.3 (Block with Multiple Behavior ProxyPorts) is. The error seems to be causing some of the SysMLers to think the annex applies to proxy ports.

Annex B is correct

Annex B does in fact apply specifically to ProxyPorts, and only to ProxyPorts. And it also only applies to ProxyPorts with isBehavior = true, that is, "behavior" ProxyPorts. Note that, in UML, a behavior Port does not actually have its own behavior, but has its behavior handled by the classifier behavior of its owning object, rather than via a delegation connector. (See the definition of Port::isBehavior and the corresponding semantics specification in subclause 9.3.12 of the UML 2.4.1 specification or subclause 11.3.3.1 of the UML 2.5.1 specification.)

Further, SysML does in fact allow behavior ProxyPorts. According to he SysML 1.4 specification (on which the Annex is based), subclause 9.3.2.12 (emphasis added),

Completely specified proxy ports must be connected to internal parts or be behavioral, to enable the owning block or connected internal parts to handle or initiate any interactions through the port.

"Being behaviorial" is interpreted here as meaning isBehavior = true. This is as opposed to FullPorts, which "cannot be behavioral (isBehavior = false)" according to constraint [3] of subclause 9.3.2.8 of the SysML 1.4 specification.

There for, the Annex is essentially correct in discussing "behavior ProxyPorts". The SysML 1.4 specification actually uses the term "behavioral port", but the more proper term according the UML specification is really "behavior port".

Figure 9.66 was exported with tool focus which looks odd in the specification document. In addition, this figure looks hard to read due to the small font size.

Figure 9.66 includes user tool focus and is hard to read

The resolution consists in replacing Figure 9.66 by the one provided in the proposed resolution

CS_OpaqueExpressionEvaluation is a specialization of the absract Evaluation (see section 8.4.2.1 in [fUML 1.4]) class. It provides the capability to execute the behavior (see section 8.6.16.5 in [UML 2.5.1]) associated with an opaque expression.

Signature of the evaluate operation is incorrect. Indeed, the signature specifies that a Value is always returned while in the implementation of that operation clearly state that null can be returned. This implies the operation signature should be updated to be:

evalute() : Value [0..1]

CS_OpaqueExpressionEvaluation evaluate operation return parameter has invalid multiplicities

The resolution consists in updating the operation signature as well as the diagram showing this signature.

In PSCS 1.0, when an Operation is dispatched to a behavior Port, it is ignored, because fUML 1.2 does not support CallEvents. However, PSSM allows StateMachines to have CallEvents on Triggers, and it should be possible to dispatch an Operation call through a behavior Port, as a CallEventOccurrence to be handled by a classifierBehavior that is a StateMachine.

Behavior Ports should be able to handle CallEventOccurrences

Note: The technical changes proposed to PSCS are dependent on issues resolved for fUML 1.3:

FUML13-16: Support for synchronous call of operations on active objects.
FUML13-1: SendSignalAction completion semantics.
­FUML13-60: Simplification to resolution of issue FUML13-1.

It also relies on the resolution specified for PSCS11-6. This resolution introduces the possibility to have any event occurrence associable with an interaction point.

Proposal: Enabling the possibility to dispatch an operation call on a behavior port requires to allow the creation of an execution when the dispatched operation arrives at a CS_InteractionPoint which is a manifestation of a behavior Port. The created execution must be a CS_CallEventExecution (a specialization of CallEventExecution – see FUML13-16). This latter is an execution that describes the production and the sending of a CS_EventOccurrence wrapping a CallEventOccurrence. The target of the sending is the owner of the interaction point which is the manifestation of the behavior port. The CS_EventOccurrence that is added to the event pool of the active object references this interaction point. This enables the classifier behavior that may accept this event occurrence to declare a trigger that identifies a Port from which the event occurrence might be accepted.

The introduction of such changes require to update both AcceptCallActionActivation (see FUML13-16) and CS_SendSignalActionActivation. Hence, a CS_AcceptCallActionActivation must be provided in order to enable a CallEventOccurrence to be unwrapped in the case a CS_Eventoccurrence is accepted. In the case of CS_SendSignalActionActivation, only an update to the doAction operation is required. This update enables the possibility to wrap the SignalEventOccurrence to a CS_EventOccurrence, to initialize this latter with the Port and the direction to which the event occurrence shall be propagated and to make this event occurrence responsible for the effective sending to the target. The sending will occur using specific operations sendInTo and sendOutTo provided by CS_EventOccurrence.

As CS_EventOccurrence is an active object (it specializes EventOccurrence – see FUML13-1 and FUML13-60). In order to specialize the classifier behavior inherited from EventOccurrence the doSend operation must be overridden in CS_EventOccurrence. The behavior specified for this operation enables to account for the direction and the port through which the event occurrence must be forwarded.

The EventOccurrence class was introduced in fUML 1.2, with SignalEventOccurrence as a subclass. However, PSCS 1.0 only allows a SignalInstance to be associated with the InteractionPoint of the port through which it was sent. This should be changed to allow any EventOccurrence to be associated with an InteractionPoint, so that other types of EventOcurrences may be identified as sent through ports (which is necessary to properly handle them on Triggers with port references).

Any EventOccurrence should be associatable as an interaction point.

Note: The technical changes proposed to PSCS are dependent on issues resolved for fUML 1.3:

­FUML13-23: Enable any kind of event occurrence to be exchanged between active objects.

­FUML13-25: Enable EventOccurrence and its subclasses to provide operations to define trigger matching as well as data extractions semantics.

Proposal: In order to introduce the possibility to send any EventOccurrence through ports and connectors in PSCS, four different groups of changes shall be performed:

1. Classes CS_Object, CS_InteractionPoint and CS_Reference contribute to the event based communications propagation mechanism limited to SignalInstance. These classes must have their send(…), sendIn(…) and sendOut(…) operation signatures and specifications changed to make sure it is allowed to propagate EventOccurrence (cf. section 8.4.3.2.3 in fUML 1.2.1) instead of CS_SignalInstance. These changes directly rely on those proposed in resolution FUML13-23.
2. In PSCS 1.0 only signal instances where intended to be propagated through ports and connectors, hence an extension to SignalInstance was provided. This extension (i.e., CS_SignalInstance) captures the port through which a signal instance was received. The problem here is that this information is not specific to signal instances but general to any kind of event occurrence that might be propagated along ports and connectors. Hence, CS_SignalInstance shall be removed and replaced by CS_EventOccurrence, which must reference an EventOccurrence (i.e., the event occurrence actually propagated) and a CS_InteractionPoint (i.e., the port instance through which the propagated event occurrence has arrived). CS_EventOccurrence must also override operations getParameterValues and match inherited from EventOccurrence.
3. The above two groups of changes imply modifications of the specifications of both CS_AcceptEventActionActivation and CS_SendSignalActionActivation. The changes to CS_AcceptEventActionActivation consist in:
   • Removing the match operation that does not need to be overridden since its specification was changed in FUML13-25 to rely on the matchAny operation provided in EventOccurrence.
   • Overriding the accept operation in order to make sure that if a CS_eventOccurrence is received then the event occurrence that is finally accepted is the wrapped event occurrence.
     The changes to CS_SendSignalActionActivation consist in:
   • Removing the doActionDefault operation which does not need to exist since it does not change the semantics provided by SendSignalActionActivation doAction operation and CS_SignalInstance is removed from the PSCS semantic model.
   • Updating the definition of the doAction operation in order to account for the usage of EventOccurrence instead of SignalInstance or CS_SignalInstance.
4. In FUML13-25, the implementation of ReadIsClassifiedObjectAction doAction operation has changed. Type checking semantics now relies on operations instanceOf and checkAllParents which are both provided by the Value class. This change implies that it is not anymore required for PSCS to provide an extension to ReadIsClassifiedObjectAction. Indeed operations (checkAllParents, isDescendant and realizesInterface) provided in this extension must be moved to CS_Object (which is a kind of Value) to ensure specific type checking semantics related to interfaces is preserved. Since CS_ReadIsClassifierObjectActionActivation does not add semantics to ReadIsClassifierObjectActionActivation it must be removed from the PSCS semantic model.

PSCS updates the semantics for ClearStructuralFeatureValueAction, so that, "when a StructuralFeature is cleared, any links representing an instance of a Connector in which the StructuralFeature is involved are destroyed" (see 8.2.2.2.2 CS_ClearStructuralFeatureActionActivation).

However, there is no similar update to the semantics for RemoveStructuralFeatureValueAction. So, if a single value is removed from a StructuralFeature, it is possible that this value will still have links to it that are instances of Connectors from within the composite. This violates the semantics of Connectors, whose instances are only supposed to link values within properties of the containing composite object.

Recommendation: Add a CS_RemoveStructuralFeatureValueActionActivation to destroy relevant connector links to a value when the value is removed from a structural feature.

RemoveStructuralFeatureValueAction should destroy constructor links

As suggested in the issue description, PSCS is required to provide an extension to the semantics defined by fUML for RemoveStructuralFeatureValueAction (see section 8.6.3.2.12 in [fUML 1.2.1]). The defined extension will be in charge, when a value is removed from a feature value, to destroy all links (i.e., instances of connectors) in which the removed value is involved.

In order to capture the new semantics, CS_RemoveStructuralFeatureValueActionActivation visitor is required to be included in the PSCS semantic model. This visitor class must be defined as a specialization of RemoveStructuralFeatureValueActionActivation. It overrides the doAction operation of its superclass. The doAction operation captures the exact same semantics than the one defined in fUML however it add the possibility to propagate the impact of the removed value(s) to the relevant connectors. This propagation is ensured in getLinkToDestroy and propagateDestructionToLinks which respectively find the connectors instances to destroy and perform the actual destruction.

As a side adjustment, CS_ExecutionFactory instantiateVisitor operation is updated to enable the creation of a CS_RemoveStructuralFeatureValueActionActivation.

CS_SendSignalActionActivation has to retrieve the context object, in order to determine how to propagate the signal instance. This is done with the following statement :
Object_ executionContext = this.group.activityExecution.context;

This statement does not cover all possible cases. The correct statement is :
Object_ executionContext = this.getActivityExecution().context ;

Problem with acces to the context object CS_SendSignalActionActivation

Agreed. The usage of statement this.group.activityExecution.context prevents to return the activity execution to which the group may indirectly belong.

The term "behavior proxyport" isn't in SysML, but is used in Annex B many times. Ports can't be both behavioral and proxy. Informally, both kinds of port "stand in" for other objects, but behavior ports stand in for the owning object, while proxy ports stand in for internal parts. I think the Annex is referring to behavior ports, at least I recall Clause 11.2.2.3 (Block with Multiple Behavior ProxyPorts) is. The error seems to be causing some of the SysMLers to think the annex applies to proxy ports.

Incorrect SysML term used in SysML annex

Consensus could not be reached during the RTF due to lack of time. We proposed to defer the issue for the next RTF.

ad-13-11-08.xmi - parse error on line 19, xsi namespace not defined (SysML Semantics)
ad-13-11-09.xmi - parse error on line 2248, xsi namespace not defined (SysML test suites)

Remove xsi:nil

The indicated files have several cases in which xsi:nil=true is used to indicates empty values. These should all be removed.

In addition, the SysML Test Suite XMI contains XMI extensions that are Ecore specific. While these can be ignored by a non-Ecore tool, they are really not appropriate for a clean XMI file (even if it is just informative) and should be removed.

Machine readable files are currently not in canonical XMI format. They shall be.

Regenerate normative XMI files

Agreed, all the normative XMI files should be in canonical XMI format. It is less important that the informative XMI files be in canonical XMI, except for the Generic Association model, which may actually be used be user models conforming to PSCS.

In test case 11.2.2.3:
b0.b1.p1_1.fp1 = b3 ;
b0.b1.fp1 = b3 ;
=> Shall have the same effect at runtime, but currently don’t have

In addition, according to SysML 1.4, assertions in test case 11.2.2.3 are wrong.
It shall propagate in all cases.
Currently says:
b0.b1.p1_1.fp1 = b3 ;
AssertTrue("Value successfully propagated to b0.b2_1.p2", b0.b2_1.p2.fp2 == b3) ;
AssertTrue("Value NOT propagated to b0.b2_2.p2", ! (b0.b2_2.p2.fp2 == b3)) ;
b0.b1.fp1 = b4 ;
// Multiple matching flow properties. Shall not propagate.
AssertTrue("Value NOT propagated to b0.b2_1.p2", !(b0.b2_1.p2.fp2 == b4)) ;
AssertTrue("Value NOT propagated to b0.b2_2.p2", !(b0.b2_2.p2.fp2 == b4)) ;

Should say:
b0.b1.p1_1.fp1 = b3 ;
AssertTrue("Value successfully propagated to b0.b2_1.p2", b0.b2_1.p2.fp2 == b3) ;
AssertTrue("Value SUCCESSFULLY propagated to b0.b2_2.p2", b0.b2_2.p2.fp2 == b3) ;
b0.b1.fp1 = b4 ;
AssertTrue("Value SUCCESSFULLY propagated to b0.b2_1.p2", b0.b2_1.p2.fp2 == b4) ;
AssertTrue("Value SUCCESSFULLY propagated to b0.b2_2.p2", b0.b2_2.p2.fp2 == b4) ;

Also, the rule for « multiple matching flow properties » is not correctly implemented.

=> Changes are required in the extended execution model

Changes required in the SysML test suite and the semantics

11.2.2.3 is actually B.2.2.3.
The extended execution model does not correctly implement SysML execution semantics.
Indeed, a behavior proxy port is a proxy to the owning block. In terms of instances and objects in the locus, a port object (represented by a SysML_InteractionPoint) and the object owning the SysML_InteractionPoint are the same object. Modifying property values either by accessing a property by navigation from an object, or from an interaction point of thsi object, should have the same effect. This is not currently the case, as was reflected by the assertions in the test case B.2.2.3.
The specific (and invalid) semantics were implemented in operations SysML_InteractionPoint::setFeatureValue and SysML::setFeatureValueOnInteractionPoint. These two operations can be removed. Note that SysML_InteractionPoint::setFeatureValue was the only operation of SysML_InteractionPoint, which means that this class is not really required anymore. However, other kinds of SysML ports (i.e., not behavior proxy ports) may require particular semantics. In order to ease possible future extension (that would address the other kinds of ports), the class can be kept.
An other error in the currently implemented semantics is related to the case where there are multiple matching flow properties for propagation of a value assigned to a source flow property. The current semantics does not distinguish the case where multiple potential target flow properties belong to multiple objects or to a single objects. If there is one matching flow property per target object, there is no conflict and the propagation shall happen on each object. The body of SysML_Object::doPropagation shall be updated to reflect this.

The specification shall clarrify if passing the test suite is a necessary or sufficient condition to demonstrate conformance with the specification

Add text to clause 2 (conformance)

In the clause 2 (conformance), add “Semantic Conformance. A conforming execution tool must provide execution semantics for a conforming model consistent with the semantics specified in clause Semantics of this document. Passing all the tests of the test suites in clause 9 are sufficient to demonstrate conformance with the semantics specified in clause 8.”

In Section 2.2, Second bullet, the text mentions « 2 new semantic variation points » but there are actually 3 semantic variation points.

Update the text to say "three" instead of "two"

In clause 2.2, second bullet, replace "two" by "three" in the sentence:

"In addition, this specification introduces two new semantic variation points and corresponding default strategies for them:"