9.2 Flows
The purpose of providing the capability of specifying end-to-end flows is to support various forms of flow  analysis, such as end-to-end timing and latency, reliability, numerical error propagation, Quality of Service (QoS) and resource management based on operational flows. To support such analyses, relevant properties are provided for the end-to-end flow, the flow specifications of components, and the ports involved in the flow to be analyzed.  For example, to deal with end-to- end latency the end-to-end flow may have properties specifying its expected maximum latency and actual latency. In addition, ports on individual components may have flow specific properties, e.g., an in port property specifies the expected latency of data relative to its sensor sampling time or in terms of end-to-end latency from sensor to actuator to reflect the latency assumption embedded in its extrapolation algorithm.
End-to-end flows are represented by flow specification, flow implementation, and end-to-end flow declarations. 
A flow specification declaration in a component type specifies an externally visible flow through a component’s ports, port groups, or parameters.  The flow through a component is called a flow path. A flow originating in a component is called the flow source.  A flow ending in a component is called the flow sink
A flow implementation declaration in a component implementation specifies how a flow specification is realized in the implementation as a sequence of flows through subcomponents along connections from the flow specification in port to the flow specification out port.  This is illustrated in Figure 15.  The system type S1 is declared with three ports and two flow specifications.  These are the flows through system S1 that are externally visible.  In the example, both flows are flow paths, i.e., they flow through the system.  The ports identified by the flow specification do not have to have the same data type, nor do they have to be the same port type, i.e., one can be an event port and the other an event data port.  This allows flow specifications to be used to describe logical flows of information. 
The system implementation for system S1 is shown on the right of Figure 15.  It contains two process subcomponents P1 and P2.  Each has two ports and a flow path specification as part of its process type declaration.  The flow implementation of flow path F1 is shown in both graphical and textual form.  It starts with port pt1, as specified in the flow specification.  It then follows a sequence of connections and subcomponent flow specifications. Modeled in the figure as the sequence of connection C1, subcomponent flow specification P2.F5, connection C3, subcomponent flow specification P1.F7, connection C5. The flow implementation ends with port pt2, as specified in the flow specification for F1.
graphic
Figure 15 Flow Specification & Flow Implementation
An end-to-end flow is a logical flow through a sequence of system components, i.e., threads, devices and processors.  An end-to-end flow is specified by an end-to-end flow declaration.  End-to- end flow declarations are declared in component implementations, typically the flow implementation in the system hierarchy that is the root of all threads, processors, and devices involved in an end-to-end flow.  The subcomponent identified by the first subcomponent flow specification referenced in the end-to-end flow declaration contains the system component that is the starting point of the end-to-end flow.  Succeeding named subcomponent flow specifications contain additional system components.  In the example shown in Figure 15, the flow specification F7 of process P1 may have a flow implementation that includes flows through two threads which is not included in this view of the model.  The identified subcomponent of the final referenced subcomponent flow specification contains the last system component of the end-to-end flow. 
9.2.1 Flow Specifications
A flow specification declaration indicates that information logically flows from one of its incoming ports, parameters, or port groups to one of its outgoing ports, parameters, or port groups.  The ports can be event, event data, or data ports. A flow may start within the component, called a flow source.  A flow may end within the component, called a flow sink.  Or a flow may go through a component from one of its in or in out ports or parameters to one of its out or in out ports or parameters, called a flow path. In the case of port groups, there is a flow from a port group to its inverse. 
Multiple flow specifications can be defined involving the same ports. For example, data coming in through an in port group is processed and derived data from one of the port group’s contained ports is sent out through different out ports. 
Syntax
flow_spec ::=
   flow_source_spec
   | flow_sink_spec
   | flow_path_spec

flow_spec_refinement ::=
   flow_source_spec_refinement
   | flow_sink_spec_refinement
   | flow_path_spec_refinement

flow_source_spec ::=
    defining_flow_identifier : flow source flow_feature_identifier
   [ { { property_association }+ } ] ;

flow_sink_spec ::=
    defining_flow_identifier : flow sink flow_feature_identifier
   [ { { property_association }+ } ] ;

flow_path_spec ::=
    defining_flow_identifier : flow path source_flow_feature_identifier ->
                             sink_flow_feature_identifier
   [ { { property_association }+ } ] ;

flow_source_spec_refinement ::=
    defining_flow_identifier :
  refined to flow source { { property_association }+ } ;

flow_sink_spec_refinement ::=
    defining_flow_identifier :
  refined to flow sink { { property_association }+ } ;

flow_path_spec_refinement ::=
    defining_flow_identifier :
  refined to flow path { { property_association }+ } ;

flow_feature_identifier ::=
    port_identifier
    | parameter_identifier
    | port_group_identifier
    | port_group_identifier . port_identifier
Naming Rules
The defining flow identifier of a flow specification must be unique within the interface name space of the component type.
The flow feature identifier in a flow path must refer to a port, parameter, or port group in the component type, or to a port or port group contained in a port group in the component type.
The defining flow identifier of a flow specification refinement must refer to a flow specification or refinement in an ancestor component type.
Legality Rules
The direction declared for the destination of a flow path specification declaration must be compatible with the direction declared for the source as defined by the following rules:
    • If the source is a port or parameter, its direction must be must be an in or an in out.
    • If the destination is a port or parameter, its direction must be an out or an in out.
The direction declared for the destination port or parameter of a flow source specification declaration must be out or in out.
The direction declared for the source port or parameter of a flow source specification declaration must be in or in out.
Standard Properties
Latency: Time
Throughput: Data_Volume
NOTES:
These properties are examples of properties for latency and throughput analysis. Additional properties are also necessary on ports to fully support throughput analysis, such as arrival rate and data size. Appropriate properties for flow analysis may be defined by the tool vendor or user (see Section 10).
Semantics
A flow specification declaration represents a logical flow originating from within a component, flowing through a component, or ending within a component. 
In case of a flow through a component, the component may transform the input into a different form for output.  In case of data or event data port, the data type may change. Similarly the flow path may be between different port types and between ports, parameters and port groups. This permits end-to-end flows to be specified as logical information flows through a system despite the fact that the information is being manipulated and its representation changed.
Examples
process foo
features
   Initcmd: in event port
   Signal: in data port gps::signal_data;
   Result1: out data port gps::position.radial;
   Result2: out data port gps::position.cartesian;
   Status: out event port;
Flows
   -- two flows split from the same input 
   Flow1: flow path signal -> result1;
   Flow2: flow path signal -> result2;
   -- An input is consumed by process foo through its initcmd port
   Flow3: flow sink initcmd;
   -- An output is generated (produced) by process foo and made available
   -- through its port Status;
   Flow4: flow source Status;
end foo;
9.2.2 Flow Implementations
Component implementations must provide an implementation for each flow specification.  A flow implementation declaration identifies the flow through its subcomponents. In case of a flow source specification, it starts from the flow source of a subcomponent or from the component implementation itself and ends with the port named in the flow source specification.  In case of a flow sink specification, the flow implementation starts with the port named in the flow sink specification declaration and ends within the component implementation itself or with the flow sink of a subcomponent. In case of a flow path specification, the flow implementation starts with the source port and ends with the destination port.  Flow characteristics modeled by properties on the flow implementation are constrained by the property values in the flow specification.  Flow implementations can be declared to be mode-specific.
By declaring flow specifications explicitly we clearly specify the expectations of a component, for both the user of a component and the implementer of a component. Compliance with the specifications can be checked separately from both perspectives.
Syntax
flow_implementation ::=
    ( flow_source_implementation
    | flow_sink_implementation
    | flow_path_implementation )
    [ { { property_association }+ }
    [ in_modes_and_transitions ] ;

flow_source_implementation ::=
    flow_identifier : flow source
      { subcomponent_flow_identifier -> connection_identifier -> }*
      flow_feature_identifier

flow_sink_implementation ::=
    flow_identifier : flow sink
      flow_feature_identifier       
      { -> connection_identifier -> subcomponent_flow_identifier }*

flow_path_implementation ::=
    flow_identifier : flow path
      source_flow_feature_identifier       
      [ { -> connection_identifier -> subcomponent_flow_identifier }+
         -> connection_identifier ]
      -> sink_flow_feature_identifier

flow_implementation_refinement ::=
    flow_source_implementation_refinement
    | flow_sink_implementation_refinement
    | flow_path_implementation_refinement

flow_source_implementation_refinement ::=
    flow_identifier :
  refined to flow source
  ( { { property_association }+ } [ in_modes_and_transitions ]
  | in_modes_and_transitions
  ) ;

flow_sink_implementation_refinement ::=
    flow_identifier :
  refined to flow sink
  ( { { property_association }+ } [ in_modes_and_transitions ]
  | in_modes_and_transitions
  ) ;

flow_path_implementation_refinement ::=
    flow_identifier :
  refined to flow path
  ( { { property_association }+ } [ in_modes_and_transitions ]
  | in_modes_and_transitions
  ) ;

subcomponent_flow_identifier ::=
    subcomponent_identifier . flow_spec_identifier
Naming Rules
The flow identifier of a flow implementation must name a flow specification in the component type. Each flow implementation must be declared at most once in each component implementation.  For mode-specific flow implementations, as indicated by the in_modes_and_transitions subclause, a flow implementation name may appear more than once.
The flow feature identifier in a flow implementation must refer to a port, parameter, or port group in the component type, or to a port or port group contained in a port group in the component type.
The subcomponent flow identifier of a flow implementation must name a flow specification in the component type of the named subcomponent.
The connection identifier in a flow implementation must refer to a connection in the component implementation.
The defining flow identifier of a flow implementation refinement must refer to a flow implementation or refinement in an ancestor component implementation.
Legality Rules
The source of a connection named in a flow implementation declaration must be the same as the source flow feature of the flow implementation or as the destination of the directly preceding subcomponent flow specification. 
The destination of a connection named in a flow implementation declaration must be the same as the destination flow feature of the flow implementation or as the source of the directly succeeding subcomponent flow specification. 
If the component implementation provides mode-specific flow implementations, as indicated by the in modes statement, then there must be a flow implementation for each of the modes.
In case of a mode-specific flow implementation, the named connections and the subcomponents of the named flow specifications must be declared for the modes listed in the in modes statement.
In a complete specification, if a system, process, or thread group component implementation contains a flow implementation declaration, then the flow implementation must include flow specifications through named thread, processor, or device subcomponents.
If the category of the component type containing a flow specification declaration is thread or subprogram, and a component implementation of the component type does not contain subprogram calls, then the flow specification represents its implementation and an explicit flow implementation declaration is not required. 
Standard Properties
Latency: Time
Throughput: Data_Volume
NOTES:
These properties are examples of properties for latency and throughput analysis. Their values represent the values of the flow implementation, which must satisfy the constraints of the property values of the flow specification.  The semantics of the constraint are analysis specific.
Semantics
A flow implementation declaration represents the realization of a flow specification in the given component implementation.  A flow implementation may be declared to be mode-specific. 
A flow path implementation starts with the port named in the corresponding flow specification, passes through zero or more subcomponents, and ends with the port named in the corresponding flow specification (see Figure 15).  A flow source implementation ends with the port named in the corresponding flow specification.  A flow sink implementation starts with the port named in the corresponding flow specification. A flow path implementation may specify a flow that goes directly from a flow source to a flow destination without any connections in between.
A flow implementation within a thread may be modeled as flow through subprogram calls via their parameters. 
A flow through a component may transform the input into a different form for output.  In case of data or event data port, the data type may change. Similarly the flow path may be between different port types and between ports and port groups. This permits end-to-end flows to be specified as logical information flows through a system despite the fact that the information is being manipulated and its representation changed.
The optional in_modes_and_transitions subclause specifies what modes the flow implementation is part of.  The detailed semantics of this subclause are defined in Section 11.1.
Examples
-- process foo is declared in the previous section
process implementation foo.basic
subcomponents
   A: thread bar.basic;
   -- bar has a flow path fs1 from port p1 to p2
   -- bar has a flow source fs2 to p3
   C: thread baz.basic;
   B: thread baz.basic;  
   -- baz has a flow path fs1 from port p1 to p2
   -- baz has a flow sink fsink in port reset
connections
   conn1: data port signal -> A.p1;
   conn2: data port A.p2 -> B.p1;
   conn3: data port B.p2 -> result1;
   conn4: data port A.p2 -> C.p1;
   conn5: data port C.p2 -> result2;
   conn6: data port A.p3 -> status;
   connToThread: event port initcmd -> C.reset;
flows
   Flow1: flow path
            signal -> conn1 -> A.fs1 -> conn2 ->
            B.fs1 -> conn3 -> result2;
   Flow2: flow path
            signal -> conn1 -> A.fs1 -> conn4 ->
            C.fs1 -> conn5 -> result2;
   Flow3: flow sink initcmd -> connToThread -> C.fsink;
   -- a flow source may start in a subcomponent,
   -- i.e., the first named element is a flow source
   Flow4: flow source A.fs2 -> connect6 -> status;
end foo.basic;
9.2.3 End-To-End Flows
An end-to-end flow represents a logical flow of information from a source to a destination through a sequence of threads that process and possibly transform the information.  In a complete specification, the source and destination can be threads, devices, and processors.
Syntax
end_to_end_flow_spec ::=
    defining_end_to_end_flow_identifier : end to end flow
      start_subcomponent_flow_identifier 
      { -> connection_identifier
        -> flow_path_subcomponent_flow_identifier }*
      -> connection_identifier -> end_subcomponent_flow_identifier
    [ { ( property_association }+ } ]
    [ in_modes_and_transitions ] ;

end_to_end_flow_refinement ::=
    defining_end_to_end_identifier :
  refined to end to end flow
  ( { { property_association }+ } [ in_modes_and_transitions ]
  | in_modes_and_transitions
  ) ;
Naming Rules
The defining end-to-end flow identifier of an end-to-end flow declaration must be unique within the local name space of the component implementation containing the end-to-end flow declaration. For mode specific end-to-end flows, as indicated by the in_modes_and_transitions subclause, an end-to-end flow identifier may appear more than once.
The connection identifier in an end-to-end flow declaration must refer to a connection in the component implementation.
The subcomponent flow identifier of an end-to-end flow declaration must name a flow specification in the component type of the named subcomponent.
The defining identifier of an end-to-end flow refinement must refer to an end-to-end flow or refinement in an ancestor component implementation.
Legality Rules
The flow specifications identified by the flow_path_subcomponent_flow_identifier must be flow paths. 
The start_subcomponent_flow_identifier must refer to a flow path or a flow source. 
The end_subcomponent_flow_identifier must refer to a flow path or a flow sink. 
In case of a mode specific end-to-end flow declarations, the named connections and the subcomponents of the named flow specifications must be declared for the modes listed in the in modes statement.
Standard Properties
Expected_Latency: Time
Actual_Latency: Time
Expected_Throughput: Data_Volume
Actual_Throughput: Data_Volume
NOTES:
These properties are examples of properties for latency and throughput analysis. The expected property values represent constraints that must be satisfied by the actual property values of the end-to-end flow. The semantics of the constraint are analysis specific.
Semantics
An end-to-end flow represents a logical flow of information through a system instance.  The end-to- end flow is declared in a component implementation that is the common root of all components involved in the flow. The end-to-end flow starts with a subcomponent flow specification, followed by zero or more connections and subcomponent flow specificaitons, and ends with a connection and a subcomponent flow specification. The actual end-to-end flow starts from a device, processor, or thread, follows semantic connections to intermediate threads and ends with a thread, device or processor.  If the start or end point of an end-to-end flow is a thread, its contribution to the flow may be limited to a partial execution by specifying a flow implementation through a subset of its subprogram calls.
The optional in_modes_and_transitions subclause specifies what modes the end-to-end flow is part of.  The detailed semantics of this subclause are defined in Section 11.1.
Examples
-- process foo is declared in the previous section
process implementation foo.basic
subcomponents
   A: thread bar.basic;
   -- bar has a flow path fs1 from p1 to p2
   -- bar has a flow source fs2 to p3
   C: thread baz.basic;
   B: thread baz.basic;  
   -- baz has a flow path fs1
   -- baz has a flow sink fsink
connections
   conn1: data port signal -> A.p1;
   conn3: data port C.p2 -> result1;
   conn4: data port A.p2 -> C.p1;
   conn5: event port A.p3 -> Status;
   connToThread: event port initcmd -> C.reset;
flows
   Flow1: flow path
            signal -> conn1 -> A.fs1 -> conn4 ->
            C.fs1 -> conn3 -> result2;
   Flow3: flow sink initcmd -> connToThread -> C.fsink;
   -- a flow source may start in a subcomponent,
   -- i.e., the first named element is a flow source
   Flow4: flow source A.fs2 -> connect5 -> status;
   -- an end-to-end flow from a source to a sink
   ETE1: end to end flow
        A.fs2 -> conn4 -> C.fsink;
   -- an end-to-end flow where the end points are not sources or sinks
   ETE2: end to end flow
            A.fs1 -> conn4 -> C.fs1;
end foo.basic;