Inconsistent handling of access connections between components

[rinsley]

Regarding access connections, the AS5506C standard (page 184) states "The category of the source and the destination of a access connection declaration must be the same, i.e., they must both be data, bus, virtual bus, subprogram, or subprogram group, or their respective access feature."

A plain reading of this would imply that it is okay for "both" ends of a connection to be, for example, a bus. So, something like this should be legal:

system Sys
end Sys;

system implementation Sys.impl
    subcomponents
        Bus1: bus;
        Bus2: bus;
    connections
        Connection1: bus access Bus1 -> Bus2;
end Sys.impl;

And the AADL text editor does not give any errors regarding this. However, if you instantiate this, you get an error on the instance model:

Connection source and destination are components: Sys_impl_Instance.Bus1 => Sys_impl_Instance.Bus2

Also, the connection does not seem to actually be present in the instance model.

If this kind of connection is not okay, I would expect the text editor to give an error, and also a clearer wording in the standard. On the other hand, if it is okay, I would expect it to instantiate without errors.

[lwrage]

The error message is bogus. Correction: No, it's not.

[AaronGreenhouse]

I've created a more elaborate example:

package Example
public
    system Sys1
    features
        B1: provides bus access;
        D1: provides data access;
        S1: provides subprogram access;
        SG1: provides subprogram group access;
        VB1: provides virtual bus access;   
    end Sys1;

    system implementation Sys1.impl
    subcomponents
        Bus1: bus;
        Bus2: bus;

        Data1: data;
        Data2: data;

        Sub1: subprogram;
        Sub2: subprogram;

        SubG1: subprogram group;
        SubG2: subprogram group;

        VBus1: virtual bus;
        VBus2: virtual bus;

        SubSystem: system Sys2.impl;

    connections
        -- internal connections
        c1: bus access Bus1 -> Bus2;
        c2: data access Data1 -> Data2;
        c3: subprogram access Sub1 -> Sub2;
        c4: subprogram group access SubG1 -> SubG2;
        c5: virtual bus access VBus1 -> VBus2;

        -- inward connections
        cc1: bus access Bus2 -> SubSystem.B1;
        cc2: data access Data2 -> SubSystem.D1;
        cc3: subprogram access Sub2 -> SubSystem.S1;
        cc4: subprogram group access SubG2 -> SubSystem.SG1;
        cc5: virtual bus access VBus2 -> SubSystem.VB1;

        -- external connections
        p1: bus access Bus1 -> B1;
        p2: data access Data1 -> D1;
        p3: subprogram access Sub1 -> S1;
        p4: subprogram group access SubG1 -> SG1;
        p5: virtual bus access VBus1 -> VB1;
    end Sys1.impl;

    system Sys2
    features
        B1: requires bus access;
        D1: requires data access;
        S1: requires subprogram access;
        SG1: requires subprogram group access;
        VB1: requires virtual bus access;   
    end Sys2;

    system implementation Sys2.impl
    end Sys2.impl;

    system Sys3
    end Sys3;

    system implementation Sys3.impl
    subcomponents
        s1: system Sys1.impl;
        s2: system Sys2.impl;

    connections
        ccc1: bus access s1.B1 -> s2.B1;
        ccc2: data access s1.D1 -> s2.D1;
        ccc3: subprogram access s1.S1 -> s2.S1;
        ccc4: subprogram group access s1.SG1 -> s2.SG1;
        ccc5: virtual bus access s1.VB1 -> s2.VB1;
    end Sys3.impl;
end Example;

The connections between subcomponents and features are okay, but the connections between subcomponents are flagged with errors and do not get generated in the instance model.

[AaronGreenhouse]

The more I look at this in the spec, the more I think this is not a bug.

• The cited rule doesn't say anything about subcomponents. It only says the category of the endpoints must be the same.
• The examples and discussion in the text make never talk about connecting subcomponents. Examples are always from a subcomponent to a "requires feature".

On the other hand:

• The syntax clearly allows this
• Nothing explicitly says you cannot do this.

On the third hand:

• Connecting subcomponents this way is clearly meaningless.

If anything, this is a bug in the AADL Spec.

[AaronGreenhouse]

I've e-mailed Peter to get his input here.

I think this should be marked as not an error, and we should simply add test cases to make sure that connecting data, bus, etc. subcomponents together this way is flagged as an error.

[lwrage]

That a bus can have a bus access feature is a recent change to the spec. Before that it was allowed to connect a bus to another bus (at least we used that in examples). Such connections are still allowed for backward compatibility. Data to data doesn't seem to make sense. Subprogram to subprogram may make sense, though.

[reteprelief]

We always had requires bus access on buses. A requires access ultimately gets connected to a bus. In 2.2 we allowed provides access to be declared on a bus. In this case the access connection ends at the provides access rather than the bus itself. In other words, originally the bus had an implicit provides access. Is it legal to connect two buses to each other via an access connection without a requires access feature? In the course examples on buses we always have a requires bus access on one end - even when we connect two buses. The standard talks about one end being requires access (3) - but not as a legality rule.

[AaronGreenhouse]

Oh, I see, he is using version AS5506C, and I have been looking at AS5506B.

[AaronGreenhouse]

Right, so the question remains, is it intended that two bus/data/subprogram subcomponents can be directly connected together with an access connection? Seems to me like the answer is no and that the connection is supposed to be made through requires and provides access features.

What is the correct action to take here? We should be able to detect direct connection of subcomponents in the validator and flag an error on the AADL source .

[AaronGreenhouse]

FYI, there is a similar issue with parameter connections:

thread implementation T1.impl
subcomponents
    Data1: data;
    Data2: data;
    connections
    -- this should be bad: subcomponent to subcomponent
    bad1: parameter Data2 -> Data1;
end T1.impl;

The syntax allows this connection, but in this case, the legality rule (L2) actually disallows this connectin. However, OSATE does not flag this as an error.

[AaronGreenhouse]

I've updated the validator to check that a connection is not between two subcomponents.

Going to add tests now.

[lwrage]

Peter is correct, it's requires bus access to bus; not bus to bus. The following combinations should be allowed:

1. provides X access and requires X access
2. X and requires X access

for X being one of bus, data, virtual bus, subprogram, subprogram group.

X and X is never legal.

[AaronGreenhouse]

Added JUnit tests