Access subcomponents of port data in flow paths

[lwrage]

The following was filed as issue osate/osate2#2285 by @jslu1. I'm moving it here because it's really about the AADL language.

Errors with Nested Dot Notation for Flow Path Declaration

When creating an internal flow path between an in-port and an out-port, it is not easy to create a nested dot notation in the flow path declaration that describe that this particular flow path includes only the specific data element typed to the interfaces.

For example, if input_1 is typed to a data implementation (data X.impl) that has 2 subcomponents (data A.impl and data B) and the implementation of data A.impl includes subcomponents (data C and data D), it is currently not possible to create a nested dot notation to represent a flow path that is only specific to data C to represent it going from input_1 to output_1. The code shown below would be the ideal nested dot notation that should annotated in the type declaration of the component but it currently results in an error.

Flows F1: flow path input_1.X.A.C -> output_1.Y;

Will there be a future tool update to facilitate nested dot notations for the data structures and its sub-structures? The issue was seen when using OSATE v2.6.

[jjhugues]

Discussion with Lutz, This change could be done, but it is unclear which existing analysis can make usage of that refinement

• [ ] Suggestion to postpone to v3

[jjhugues]

Document work around with intermediate subprogram here

[lwrage]

Use case

Assume we have data implementation with data subcomponents that aggregate data received at a port.

data implementation D.i
  subcompoents
    x: data DX;
    y: data DY;
end DT.i;

Take a component that receives the data on port p and outputs the value of x at port px and the value of y at port py.

abstract A
  features
    p: in data port D.i;
    px: out data port DX;
    py: out data port DY;
end A;

In AADL2 we cannot write a flow specification for these data flows.

If we model the data via a feature group, instead, the flows can be specified. However, in this case we lose the aggregate data port semantics.

As a workaround this can be modeled by introducing an additional subcomponent and using connections to split the aggregate data.

package Issue54
public

    data DX
    end DX;

    data DY
    end DY;

    data D
    end D;

    data implementation D.i
        subcomponents
            x: data DX;
            y: data DY;
    end D.i;

    thread TX
        features
            dx_out: out data port DX;
            dx_in: in data port DX;
    end TX;

    thread TY
        features
            dy_out: out data port DY;
            dy_in: in data port DY;
    end TY;

    process Producer
        features
            d_out: out data port D.i;
    end Producer;

    process implementation Producer.i
        subcomponents
            tx: thread TX;
            ty: thread TY;
        connections
            cx: port tx.dx_out -> d_out.x;
            cy: port ty.dy_out -> d_out.y;
    end Producer.i;

    process Splitter
        features
            d_in: in data port D.i;
            dx_out: out data port DX;
            dy_out: out data port DY;
        flows
-- The following flow specifications are invalid
--          fx: flow path d_in.x -> dx_out;
--          fy: flow path d_in.y -> dY_out;
            fx: flow path d_in -> dx_out;
            fy: flow path d_in -> dY_out;
    end Splitter;

-- workaround using a subcomponent  
    process implementation Splitter.i
        subcomponents
            h: abstract Helper;
        connections
            -- split data using connections cx1 and cx2
            -- (Note: Instantiation of this type of connections 
            --  is not supported in OSATE.)
            cx1: port d_in.x -> h.dx_in;
            cy1: port d_in.y -> h.dy_in;
            cx2: port h.dx_out -> dx_out;
            cy2: port h.dy_out -> dy_out;
        flows
            fx: flow path d_in -> cx1 -> h.fdx -> cx2 -> dx_out;
            fy: flow path d_in -> cy1 -> h.fdy -> cy2 -> dy_out;
    end Splitter.i;

    abstract Helper
        features
            dx_in: in data port DX;
            dy_in: in data port DY;
            dx_out: out data port DX;
            dy_out: out data port DY;
        flows
            fdx: flow path dx_in -> dx_out;
            fdy: flow path dy_in -> dy_out;
    end Helper;

end Issue54;

[jjhugues]

[ ] Postpone to v3, where we could consider conversions between data implementation and feature groups