10.3    End-To-End Flows

(1)   An end-to-end flow represents a logical flow of data and control from a source to a destination through a sequence of threads that process and possibly transform the data.  In a complete AADL specification, the source and destination can be threads, data components, devices, and processors. In an incomplete AADL specification, the source and destination are the leaf nodes in the component hierarchy, which may be thread groups, processes, or systems.  If the AADL specification includes subprogram calls, the end to end flow follows the semantic connections between threads, processors, and devices, and the parameter connections within threads.

Syntax

end_to_end_flow_spec ::= 
    defining_end_to_end_flow_identifier : end to end flow
      start_subcomponent_flow_or_etef_identifier  
      { -> connection_identifier 
        -> flow_path_subcomponent_flow_or_etef_identifier }+ 
    [ { ( property_association }+ } ]
    [ in_modes_and_transitions ] ;
 
end_to_end_flow_spec_refinement ::= 
    defining_end_to_end_identifier : 
        refined to end to end flow 
        ( { { property_association }+ } [ in_modes_and_transitions ] 
        | in_modes_and_transitions 
        ) ;
 
subcomponent_flow_or_etef_identifier ::=
     subcomponent_flow_identifier | end_to_end_flow_identifier

Naming Rules

(N1)     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.

(N2)     The connection identifier in an end-to-end flow declaration must refer to a connection in the component implementation.

(N3)     The subcomponent flow identifier of an end-to-end flow declaration must name an optional flow specification in the component type of the named subcomponent or to a data component in the form of a data subcomponent, provides data access, or requires data access.

(N4)     The end-to-end flow identifier referenced in an end-to-end flow declaration must name an end-to-end flow in the name space of the same component implementation.

(N5)     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

(L1)      The flow specifications identified by the flow_path_subcomponent_flow_identifier must be flow paths, if present. 

(L2)      The start_subcomponent_flow_identifier must refer to a flow path or a flow source, or to a data component. 

(L3)      The end_subcomponent_flow_identifier must refer to a flow path or a flow sink, or to a data component. 

(L4)      If an end-to-end flow is referenced in an end-to-end flow declaration, then its first and last subcomponent flow must name the same port as the preceding or succeeding connection.

(L5)      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

Actual_Latency: Time_Range

 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

(2)   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 declared end-to-end flow starts with a subcomponent flow specification, followed by zero or more connections and subcomponent flow specifications, and ends with a connection and a subcomponent flow specification. The end-to-end flow can involve active components such as threads, thread groups, processes, systems, processors, and devices, as well as passive components in the form of a data component.

(3)   An end-to-end flow may refer to subcomponents without identifying a flow specification.  In this case, the flow specification (a) refers to an unnamed flow specification from the destination port of the preceding connection and the source port of the succeeding connection if the subcomponent has no declared flow specification, or (b) represents a separate end-to-end flow for each of the flow specifications of the subcomponent.

(4)   An end-to-end flow may be specified as a composition of other end-to-end flows, where the last element of the predecessor end-to-end flow is connected with the first element of the successor end-to-end flow.

(5)   The corresponding end-to-end flow instance is determined by expanding the flow specifications through their flow implementations.  The resulting end-to-end flow instance starts from a device, processor, data component, or thread that is the leaf of the component hierarchy of the first subcomponent, follows semantic connections to intermediate threads and ends with a thread, data component, device, or processor.  For incomplete models or flow implementations  the components involved in the end-to-end flow instance may be thread groups, processes, or systems.

(6)   If the first subcomponent flow specification is a flow path, then the end-to-end flow instance starts with the first component of the flow path expanded through its flow implementation. Similarly, if the last subcomponent flow specification is a flow path, then the end-to-end flow instance ends with the last component of the flow path expanded through its flow implementation.

(7)   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 12.

Examples

-- This is an AADL fragment

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

   B: thread baz.basic;

   -- baz has a flow path fs1

   -- baz has a flow sink fsink

connections

   conn1: port signal -> A.p1;

   conn2: port A.p2 -> result1;

   conn3: port B.p2 -> result2;

   conn4: port A.p2 -> B.p1;

   conn5: port A.p3 -> Status;

   conn6: port A.p3 -> B.reset;

   connToThread: port initcmd -> A.reset;

flows

   Flow1: flow path

            signal -> conn1 -> A.fs1 -> conn2 -> result1;

   Flow3: flow sink initcmd -> connToThread -> B.fsink;

   -- a flow source may start in a subcomponent,

   -- i.e., the first named element is a flow source

   Flow4: flow source A.fs2 -> conn5 -> status;

   -- an end-to-end flow from a source to a sink

   ETE1: end to end flow

           A.fs2 -> conn6 -> B.fsink;

   -- an end-to-end flow where the end points are not sources or sinks

   ETE2: end to end flow

            A.fs1 -> conn4 -> B.fs1;

end foo.basic;