(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;