SySim ports (SySim)
A SySim Control Block typically has one more ports, which can be SysML Full Ports, Proxy Ports and Flow Ports, and standard UML ports. The behavior of a SySim Control Block usually involves reading the values of input ports, processing those values, and setting the values of output ports.
In a SySim Simulation Scenario, ports defined on a Block are shown on its associated SysML Block Property on the SySim Simulation Scenario's child Internal Block Diagram. When two ports on the Internal Block Diagram are connected it means that data flows from one port instance to the other port instance during the model execution.
SysML Ports
A SysML Full Port, Proxy Port or Flow Port that is involved in a SySim Simulation Scenario must have one of the following stereotypes applied: «SySim InputPort», «SySim OutputPort» or «SySim InputOutputPort». In addition, the SysML Full Port, Proxy Port or Flow Port's type must be stereotyped by the «SySim DataType» stereotype.
The «SySim InputPort», «SySim OutputPort» or «SySim InputOutputPort» stereotype determines how the Full Port, Proxy Port or Flow Port is used. The port direction specified in SysML does not have any effect and can be set differently, because there are situations where the conceptual direction expressed in SysML differs from the executable direction that needs to be provided for achieving the execution.
An output Full Port, Proxy Port or Flow Port can be connected to many input Full Ports, Proxy Ports and Flow Ports, but an input Full Port, Proxy Port or Flow Port can be connected to only one output Full Port, Proxy Port or Flow Port. When connecting two SysML Ports, their types must be compatible, but they do not have to be the same: the destination port's type must be assignable from the source port's type.
The SysML Full Port, Proxy Port or Flow Port's type must have the «SySim DataType» stereotype applied. Through the SySim PortDataType tag definition, which is applied by the «SySim InputPort», «SySim OutputPort» or «SySim InputOutputPort» stereotypes, you can override the Full Port, Proxy Port or Flow Port's type by specifying an alternative type to use, such as, a known type not modeled in SysML. If the type of a Full Port, Proxy Port or Flow Port is a Visual Basic primitive type, use the appropriate Value Type from the SySim Profile::SySim DataTypes package.
The SysML type associated with a Full Port, Proxy Port or Flow Port can be a SysML Value Type, a SysML Block, SysML Interface Block or a SysML Flow Specification. Flow Specifications can be used only with Flow Ports whose direction is inout. For a Flow Port whose direction is inout, SySim implements the Flow Port in a way that is consistent with the SysML Port/Conjugated Port/Flow Specification paradigm.
During the SySim model execution loop, Full Port, Proxy Port or Flow Port values are processed as follows:
• In the Time Advance Phase, the port buffer of an output (or input/output) port is written and the retained value is updated.
• In the Publish Phase, values in the output buffers are sent from the output (input/output) ports to the input (input/output) ports that are connected in the SySim Simulation Scenario. The ports receiving those values store the values in their input buffers without making them available to the owning block until the next Latch Phase of the SySim model execution loop executes.
• In the Latch Phase, the input buffer values are made available to the Block, which will be able to read and process those values in the next Advance Phase of the SySim model execution loop.
A «SySim InputOutputPort» stereotype has to be typed by a SysML Flow Specification. A SysML Flow Specification can have both in and out Flow Properties. A non-conjugated inout Flow Port carrying a Flow Specification can be connected with zero or more conjugated Flow Ports carrying the same Flow Specification type (it can also be connected with other input only Flow Ports). A non-conjugated port will publish the out components of its Flow Specification during the Publish Phase, effectively sending them to the connected conjugated Flow Ports (which will make them available to their owning Blocks at the subsequent Latch Phase); the conjugated Flow Ports will publish the in components of their Flow Specification during the Publish Phase, sending them to a non-conjugated connected Flow Port. During the subsequent Latch Phase, the non-conjugated Flow Ports will make the latched in components of the Flow Specification available to its owning Block, and its owning Block can handle them individually (there can be more than one). A non-conjugated port can optionally also update the in components of its Flow Specification; connected conjugated inout Flow Ports will ignore this data, but eventually a connected input Flow Port can still read all information conveyed by the Flow Specification (both the in and out components) and use it as necessary. In this case, because information provided by the in components is not unique (there may be several senders connected, that is, the conjugated Flow Ports), it is responsibility of the Block managing the non-conjugated Flow Port to collect the individual values, concentrate them into a single value and publish it for use by the connected input Flow Ports.
UML Standard Ports
In addition to working with SysML Full Ports, Proxy Ports and Flow Ports, a SySim model execution can interact with Standard Ports. When working with a Standard Port the following rules apply:
• When a Standard Port that is used in a SySim model execution, the «SySim InputPort» or «SySim OutputPort» stereotype must be applied to that Standard Port.
• When a Standard Port that is used in a SySim model execution, that Standard Port must be typed a Class; the Standard Port cannot be typed by a Data Type or Interface.
• When a Class types a Standard Port that is used in a SySim model execution, the «SySim PortClass» stereotype must be applied to that Class.
• A Class that types an input Standard Port must provide one or more Interfaces. A Class that types an output Standard Port must require one or more Interfaces. The Interfaces must not be implemented on the Class, implementation happens automatically. For provided Interfaces, the Operations defined on those Interfaces are used for the state machine that provides the Interface.
• The tagged value of the SySim PortDataType tag definition, which is applied to a Standard Port by the «SySim InputPort» or «SySim OutputPort» stereotype, must be blank.
• When working with SySim, Standard Ports cannot be connected to SySim Full Port, Proxy Port or Flow Ports.
SysML Ports typed by Interface Blocks
• When the SysML port is typed by an Interface Block, «SySim InputPort» should be applied to ports that receive signals, read interface block properties or receive remote calls for interface block operations. Similarly, «SySim OutputPort» should be applied to ports that send signals, write interface block properties or actuate calls on the remote block for interface block operations. Alternatively,«SySim InputOutputPort» can be specified for both ports in mixed scenarios, and one of the two connected ports must be conjugated while the other must be non-conjugated. Specifying «SySim InputOutputPort» enables to further refine direction of single features as explained below.
• If you are not setting the “Feature Direction” to anything on any interface property, reception or operation, then the behavior of the feature depends on the direction of the port, it behaves as “provided” (receives) if the port is not conjugated and “required” (sends) if the port is conjugated. Although, setting the “Feature Description” to “Provided” has no effect at all; setting the “Feature Direction” to “Required” works the other way round, that is, the feature behaves as “Required” if the port is not conjugated, and behaves as “Provided” if it is conjugated.
• The block having a port that ultimately “Provides” an operation (that is defined on the interface block) should declare an operation with the same signature, that will be called by the other side of the port connector. The block having a port that ultimately “Requires” an operation (that is defined on the interface block) can call such an operation with syntax similar to the following: <portname.operation name> (<parameter list>). This operation is executed on the other side of the port connector.
• The block having a port that ultimately “Provides” a reception (that is defined on the interface block) can use a “signal event” referencing the reception signal as a trigger on a state machine transition. The signal is sent by the other side of the port connector. The block having a port that ultimately “Requires” a reception (that is defined on the interface block) can send the reception signal through that port. This reception signal is sent as a trigger for the state machine transition on the other side of the port connector with a syntax similar to the following: send <Signal Token> (<Signal Parameters>) to <PortName>.
• The block having a port that ultimately “Provides” a property (that is defined on the interface block) can read that property into the port. This property can be written to the other side of the port connector. The block having a port that ultimately “Requires” a property (that is defined on the interface block) can read that property into the port. This property can be read by other side of the port connector.