![]() ![]() |
||||
|
||||
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
components 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.
![]() 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. |
||||
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 groups 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:
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; |
||||
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; |
||||
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; |
||||