Instantiation fails when referencing a required mode in a property association.

[Etienne13]

In the following AADL model, OSATE fails instantiating the system implementation main.impl

package required_modes_instantiation
public
    system main
    end main;

    system implementation main.impl
    subcomponents
        proc: process proc.impl;
    properties
        Period => 1000 ms in modes (m1), 200 ms in modes (m2) applies to proc.t;    
    end main.impl;

    process proc
        modes
            m1: initial mode;
            m2: mode;
    end proc;

    process implementation proc.impl
    subcomponents
        t: thread t;    
    end proc.impl;

    thread t
        requires modes
            m1: initial mode;
            m2: mode;
    end t;

end required_modes_instantiation;

The reason seems to be that I reference required modes (m1 and m2) in the property association of property Period for thread subcomponent t. The property association is given in system implementation main.impl.

If I remove the keyword "requires" in thread type declaration t, the instantiation works fine.

Let me know if this is a bug or a miss-use of the language. Best regards, Etienne.

[AaronGreenhouse]

This works if the an explicit mode mapping is provided to the subcomponent:

    process implementation proc.impl
    subcomponents
        t: thread t in modes (m1 => m1, m2 => m2);  
    end proc.impl;

In this case a system is instantiated with 2 system operation modes (not 4, as if the modes of thread and the process were separate).

So it would seem the problem lies with interpreting the implicit mode mapping that should exist in the case of the original example.

[AaronGreenhouse]

I think that InstantiateModel.fillModesAndTransitions() needs to be updated to handle this. There is a section where it explicitly looks at ModeBinding objects.

[AaronGreenhouse]

Fixed fillModesAndTransitions(), but the original problem comes back when you have required modes that cannot be automatically mapped because their names do not match with the modes of the containing component. fillModesAndTransitions() generates an error marker in teh case, but that doesn't help farther down the line when the properties references to the mode. Need to have some error handling here as well.

[AaronGreenhouse]

Need tests for:

• Explicit mode mapping
• Implicit mode mapping
• Unmatched modes (errors)
• Control case: regular modes

For the ModeInstance in the ComponentInstance

• Check that the derived attribute is correct.
• Check that the parent attribute is correct

[AaronGreenhouse]

Properties are also a problem when we have this:

    thread tt
        requires modes
            x1: initial mode;
            x2: mode;
        properties
            Period => 1000 ms in modes (x1), 200 ms in modes (x2);  
    end tt;

and the component is not contained such that the containing component's mode match the required modes.

The problem isn't specific to the properties. The problem is that the required mode is not present in the system operation modes.

[lwrage]

I'm not sure that all required modes must be covered in the parent. What does the standard say? Conceptually we would simply have a mode in the subcomponent that is unreachable.

[AaronGreenhouse]

It's an error:

If the subcomponent’s component type has a requires modes clause and no mapping to a subcomponent mode identifier is specified, then for each such mode in the subcomponent there must be a mode with the same name in the containing component.

(emphasis added)

I fixed the instantiation process to do the implicit mapping described. The problem comes in when the mapping cannot be made because there isn't a name match. In this case, the generated system operation modes do not account for these "unmapped modes", and the property stuff gets messed up. It's possible other things that use "in modes" would also be messed up.

Best thing to do, I htink, is when you have a required mode that is missing a mapping, which can be detected by it being marked as derived, but not having a parent mode, it should be included in the system operation mode process like any normal mode.

[AaronGreenhouse]

Updated the system operation mode generation process. Unmapped nodes (those that are derived, but are missing a parent) are included in the set of modes for system operation modes. These prevents errors later during the instantiation process.

[AaronGreenhouse]

Need test cases for SOMs:

• Explicitly mapped modes
• Implicitly mapped modes
• Unmapped modes (erroneous)

Test that the correct SOMs exist.

Test that the properties work and have the correct SOMs attached to them.

[AaronGreenhouse]

JUnit tests added.