4.2 Standard Ports, Flow Ports & Interfaces

4.2 Standard Ports, Flow Ports & Interfaces

Quick Summary: In SysML, ports define interaction points located on the boundary of a block or part. They allow internal subsystems to interact with each other and with the external environment without exposing internal implementation details. Under foundational SysML specifications (v1.2), the language defines two distinct port categories: standard ports (which model service invocations and operations typed by interfaces using ball-and-socket notation) and flow ports (which model the transmission of matter, energy, and data, indicated by small squares with directional arrows).

Modularity and encapsulation are essential engineering principles for complex system design. If internal parts connected directly to the internal variables or functions of other parts, any modification to a subsystem would trigger cascading redesigns across the entire system. SysML enforces structural encapsulation through ports. By mediating all interactions through dedicated perimeter gates, ports allow engineers to swap out, upgrade, or reconfigure internal components provided the boundary port contracts remain preserved.

---

The Role of Ports in System Architecture

A port is a structural feature of a classifier that specifies a distinct interaction point between that classifier and its environment or between the classifier and its internal parts:

• Perimeter Placement: Graphically rendered as a small square resting directly on the boundary line of a block (on a BDD) or a part usage (on an IBD).
• Encapsulation Boundary: Shielding internal structures so that external components only interact with the port rather than reaching inside the component.
• Interface Contracts: A port declares what capabilities, operations, or flow items it provides to other entities, and what it requires from them.

---

Standard Ports vs. Flow Ports in SysML 1.2

The OCSMP Model User exam tests the foundational SysML 1.2 modeling constructs, which distinguish sharply between two port types based on the nature of the interaction:

1. Standard Ports (Behavioral / Service-Oriented):

   • Derived directly from UML 2.
   • Intended for client-server invocations, behavioral service requests, and synchronous or asynchronous function calls.
   • Does not have directional arrows inside the port square.
   • Typed by one or more interfaces.
   • SysML 1.2 calls standard ports "another name for UML 2 ports" and says they are typically used for peer-to-peer synchronous request/reply services.

2. Flow Ports (Item Transfer / Physical & Informational Flows):

   • Introduced specifically by SysML to address physical and continuous engineering domains.
   • Intended for transferring matter (e.g., fuel, hydraulic fluid), energy (e.g., electrical current, heat), or data (e.g., telemetry packets, raw bitstreams).
   • Features an internal directional arrow showing the allowable direction of item movement.
   • Typed by a «valueType», «block», «signal», or «flowSpecification».
   • SysML 1.2 says flow ports "are intended to be used for asynchronous, broadcast, or send-and-forget interactions."

---

Standard Ports: Service Invocations and Interfaces

A standard port models a software or behavioral interface where one component requests a service and another executes it. Standard ports are typed by Interfaces.

Provided vs. Required Interface Notation

To specify the role of a standard port, SysML uses the canonical "ball-and-socket" notation:

1. Provided Interface ("Ball" or "Lollipop" -O):

   • Represented by a solid line extending from the port square terminating in a full circle (ball).
   • Semantics: The owning block implements and provides the operations declared in the interface. Other blocks can call these operations.
   • Example: A PowerDistributionUnit provides an IPowerControl interface with operations like turnOnChannel() and readVoltage().

2. Required Interface ("Socket" -():

   • Represented by a solid line extending from the port square terminating in a half-circle (cup or socket).
   • Semantics: The owning block demands or depends upon the operations declared in the interface to perform its duties. It expects an external block to supply this functionality.
   • Example: A FlightComputer requires an IPowerControl interface to command power states.

3. Ball-and-Socket Assembly (-O)-):

   • When two parts with complementary provided and required interfaces are connected, the ball fits neatly inside the socket.
   • This visually depicts a verified service binding between client and server.

+--------------------+                  +--------------------+
|  flightComputer    |                  |  powerDistributor  |
|     [Part]         |                  |      [Part]        |
|               [ ]-(====================)-[ ]               |
|             socket (Req)             ball (Prov)           |
+--------------------+                  +--------------------+

---

Flow Ports: Transferring Matter, Energy, and Data

While software components often communicate via operation calls, physical and hardware engineering requires modeling fluids, currents, forces, and signals. SysML flow ports provide this capability.

Directional Semantics and Visual Notations

A flow port is rendered as a small square on the block perimeter containing an arrowhead that indicates the permitted direction of flow:

---

Atomic Flow Ports vs. Non-Atomic Flow Ports

Flow ports are divided into two distinct structural variants based on how they are typed:

1. Atomic Flow Ports

• Definition: A flow port that transfers a single, indivisible kind of flow item.
• Typing Classifiers: Typed directly by a «valueType», a «block», or a «signal».
  • Example typed by value type: voltage : Volts (direction in).
  • Example typed by block: coolant : LiquidNitrogen (direction inout).
  • Example typed by signal: abortCommand : EmergencyAbortSignal (direction in).
• Arrowhead Rule: Must show an internal direction arrow (in, out, or inout).
• Exam Constraint: An atomic flow port cannot be typed by a «flowSpecification».

2. Non-Atomic Flow Ports

• Definition: A flow port that transmits a complex bundle or collection of distinct flow items across a single interface channel.
• Typing Classifier: Typed exclusively by a «flowSpecification».
• Symbol: SysML 1.2 draws a non-atomic flow port with two open arrowheads facing away from each other (< >) inside the square, because the direction of each item is declared by the flow properties of the typing flow specification.
• Exam Constraint: A non-atomic flow port can never be typed by a simple value type or block.

---

Flow Specifications and Conjugate Flow Ports

A Flow Specification is a specialized classifier stereotyped as «flowSpecification» defined on a BDD. It acts as an interface definition for non-atomic flow ports.

Anatomy of a Flow Specification

Inside a «flowSpecification» box on a BDD, flow properties are listed within the compartment labeled flowProperties. A flow specification may own only flow properties; it cannot own operations or receptions. Each property declares:

• A direction (in, out, or inout)
• A property name
• A typing classifier

+-----------------------------------------------+
|             «flowSpecification»               |
|                 AvionicsBus                   |
+-----------------------------------------------+
| flowProperties                                |
|   in flightCommands : CommandPacket           |
|   out telemetryData : TelemetryPacket         |
|   inout busClock : Frequency                  |
+-----------------------------------------------+

Conjugation and the Tilde (~) Operator

When two components communicate across a bus typed by AvionicsBus, they cannot both have identical in and out ports. If both sides declared out telemetryData, they would transmit toward each other with no receiver, resulting in an interface mismatch.

To solve this cleanly without forcing the modeler to create two mirrored flow specifications, SysML introduces conjugate flow ports:

• Notation: Indicated by prefixing the flow specification name with a tilde (~), such as ~AvionicsBus.
• Older Notation: SysML 1.2 also describes a conjugated flow port drawn as a black-filled square with white text; its notation table marks that filled form as deprecated in favor of the ~ prefix. In a flow ports compartment, a conjugated port can be marked {conjugated}.
• Compartment Form: A block may list its ports in compartments instead of drawing squares: flow ports entries use the form in | out | inout portName : portType (e.g., in ac : ACVoltage), and standard ports entries use portName : InterfaceName (e.g., p1 : ITransCmd).

The Inviolable Rule of Conjugation

When a flow port is conjugated (~), the directions of all flow properties declared inside the typing flow specification are inverted:

$$\text{in} \longrightarrow \text{out} \qquad \text{and} \qquad \text{out} \longrightarrow \text{in}$$ $$\text{inout} \longrightarrow \text{inout} \quad (\text{remains completely unchanged})$$

Applying conjugation to AvionicsBus produces:

• out flightCommands : CommandPacket (inverted from in)
• in telemetryData : TelemetryPacket (inverted from out)
• inout busClock : Frequency (remains inout)

This guarantees that the regular port and the conjugated port fit together in perfect harmony.

---

Comprehensive Port Comparison Tables

Table 1: Standard Ports vs. Flow Ports

Table 2: Atomic Flow Ports vs. Non-Atomic Flow Ports

---

Worked Engineering Scenario: Hybrid Spacecraft Power and Thermal Bus

Consider an earth-observation satellite architecture containing two primary parts:

1. PowerDistributionUnit (PDU):

   • Atomic Flow Port solarIn: Type DirectCurrent, direction in (arrow pointing inward). Receives raw electrical power from solar panels.
   • Atomic Flow Port mainBusOut: Type DirectCurrent, direction out (arrow pointing outward). Delivers regulated 28V DC power to internal electronics.
   • Standard Port pduDiagnostics: Decorated with a solid ball representing the provided interface IPowerTelemetry with operations getVoltage() and getTemperature().

2. FlightComputer (OBC):

   • Atomic Flow Port powerIn: Type DirectCurrent, direction in (arrow pointing inward). Connected to PDU.mainBusOut.
   • Standard Port diagClient: Decorated with an open socket representing the required interface IPowerTelemetry. Connected to PDU.pduDiagnostics in a ball-and-socket assembly.
   • Non-Atomic Flow Port payloadBus: Typed by ~PayloadDataBus (conjugated). Connected to the payload camera's dataBus port (typed by regular PayloadDataBus). Telemetry flows into the OBC, while instrument commands flow out.

---

Common Exam Traps & Pitfalls

• Trap 1: Ball-and-Socket Inversion: Remember: Ball = Provided (the block implements the functions), Socket = Required (the block needs the functions). An exam question will often describe a sensor reporting data and ask whether it exposes a ball or socket; if the sensor implements the read operation, its port displays a ball.
• Trap 2: Adding Arrows to Standard Ports: Standard ports never have directional arrows inside their squares. If a diagram shows a port with an internal arrow, it is a flow port, not a standard port.
• Trap 3: Typing Atomic Flow Ports with Flow Specifications: An atomic flow port can only be typed by a single block, signal, or value type. If an option claims an atomic flow port is typed by a «flowSpecification», it is invalid.
• Trap 4: Inverting inout Properties During Conjugation: When conjugating a flow specification with ~, candidates often mistakenly think inout properties invert or disappear. inout properties remain completely unchanged as inout.
• Trap 5: Flow Ports Calling Operations: Flow ports transmit data, physical matter, or energy; they do not invoke software operations or services. Service invocations belong exclusively to standard ports.