10.1    Flow Specifications

(1)   A flow specification declaration indicates that information logically flows from one of its incoming ports, parameters, or feature groups to one of its outgoing ports, parameters, or feature groups, or to and from data components via data access.  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. A flow may also follow read or write access to data components.  In the case of feature groups, there is a flow from a feature group to its inverse. 

(2)   Multiple flow specifications can be defined involving the same features. For example, data coming in through an in feature group is processed and derived data from one of the feature 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 out_flow_feature_identifier 
        [ { { property_association }+ } ] 
        [ in_modes ] ;
 
flow_sink_spec ::= 
    defining_flow_identifier : flow sink in_flow_feature_identifier 
        [ { { property_association }+ } ] 
        [ in_modes ] ;
 
flow_path_spec ::= 
    defining_flow_identifier : flow path in_flow_feature_identifier -> 
                             out_flow_feature_identifier 
        [ { { property_association }+ } ] 
        [ in_modes ] ;
 
flow_source_spec_refinement ::= 
    defining_flow_identifier : 
        refined to flow source 
        ( ( { { property_association }+ } [ in_modes_and_transitions ] ) |
          in_modes_and_transitions ) ;
 
flow_sink_spec_refinement ::= 
    defining_flow_identifier : 
        refined to flow sink 
         ( ( { { property_association }+ } [ in_modes_and_Transitions ] ) |
          in_modes_and_transitions ) ;
 
flow_path_spec_refinement ::= 
    defining_flow_identifier : 
        refined to flow path 
         ( ( { { property_association }+ } [ in_modes_and_transitions ] ) |
          in_modes_and_transitions ) ;
 
flow_feature_identifier ::=
    feature_identifier 
    | feature_group_identifier
    | feature_group_identifier . feature_identifier
    | feature_group_identifier . feature_group_identifier

Naming Rules

(N1)     The defining flow identifier of a flow specification must be unique within the interface name space of the component type.

(N2)     The flow feature identifier in a flow path must refer to a port, parameter, data access feature, or feature group in the component type, or to a port, data access feature, or feature group contained in a feature group in the component type.

(N3)     The defining flow identifier of a flow specification refinement must refer to a flow specification or refinement in an ancestor component type.

Legality Rules

(L1)      The direction declared for the out_flow of a flow path specification declaration must be compatible with the direction declared for the in_flow as defined by the following rules:

(L2)      If the in_flow is a port or parameter, its direction must be must be an in or an in out.

(L3)      If the out_flow is a port or parameter, its direction must be an out or an in out.

(L4)      If the in_flow is a data access, its access right must be must be Read_Only or Read_Write.

(L5)      If the out_flow is a data access, its direction must be Write_Only or Read_Write.

(L6)      If the in_flow is a feature group then it must contain at least one port or data access that satisfies the above rule, or it must have an empty set of ports.

(L7)      If the out_flow is a feature group then it must contain at least one port or data access that satisfies the above rule, or it must have an empty set of ports.

(L8)      The direction declared for the out flow of a flow source specification declaration must be the same as for out flows in flow paths.

(L9)      The direction declared for the in_flow of a flow sink specification declaration must be the same as for in_flow of flow paths.

(L10)   If the flow specification refers to a feature group then the feature group must contain at least one port, data access, or parameter that satisfies the above rules, or the feature group must have an empty list of features.

Standard Properties

Latency: Time_Range

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

Semantics

(3)   A flow specification declaration represents a logical flow originating from within a component, flowing through a component, or ending within a component. 

(4)   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, e.g., an event port and a data port, and between ports, parameters, data access features, and feature 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

package gps

public

   data signal_data

   end signal_data;

  

   data commands

   end commands ;

 

   data position

   end position;

 

   data implementation position.radial

   end position.radial;

 

   data implementation position.cartesian

   end position.cartesian;

end gps;

 

package FlowExample

public

with  GPSLib;

process foo

features

   Initcmd: in event port;  

   Signal: in data port GPSLib::signal_data;

   Result1: out data port GPSLib::position.radial;

   Result2: out data port GPSLib::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;

thread bar

features

     p1 : in data port GPSLib::signal_data;

     p2 : out data port GPSLib::position.radial;

     p3 : out event port;

     reset : in event port;

flows

     fs1 : flow path p1 -> p2;

     fs2 : flow source p3;

end bar;

 

thread implementation bar.basic

end bar.basic;

 

thread baz

features

     p1 : in data port GPSLib::position.radial;

     p2 : out data port GPSLib::position.cartesian;

     reset : in event port;

flows

     fs1 : flow path p1 -> p2;

     fsink : flow sink reset;

end baz;

 

thread implementation baz.basic

end baz.basic;

end FlowExample;