Expand the aadl_xml backend to include more details

[nvcyc]

OCARINA VERSION:

root@05f8f72842cc:~/opt/ocarina-build# ocarina --version
Ocarina v2017.1-501-g402cf43 (Working Copy from r402cf43f)
Copyright (c) 2003-2009 Telecom ParisTech, 2010-2021 ESA & ISAE
Build date: Feb 05 2021 00:06:31

DESCRIPTION:

The aadl_xml backend enables Ocarina to export an instantiated AADL model in XML format which is useful for external tools to consume for their needs. However, the output XML does not include everything in the model instance and hence reduces the usability of the backend. The issue was occasionally raised in the past (e.g., #156) but has not been addressed in the upstream. I believe expanding the existing aadl_xml backend can benefit those who want to use Ocarina as a compiler together with their own custom programs/tools. For this reason, I'd like to know if there exists any plan for enhancing the aadl_xml backend to include more details from the instantiated model.

SAMPLE FIX/WORKAROUND:

To facilitate the discussion and development for enhancing the usability of the aadl_xml backend, I'd like to start with proposing to include the following elements in the XML:

1. Typed property values Currently property values are presented without noting their types in XML. A correct representation of the property value types is vital to analyzing/using the model.

2. Connections Including connections completes the architectural description of the model instance and hence can greatly increase the usability of the output XML.

3. Flows Including flow information allows external tools to conduct further analysis outside of Ocarina.

Before delving into the design of the XML elements and the aadl_xml code, it will be good to get some feedback from you and see if there is any requirement and expectation for the aadl_xml backend.

[yoogx]

I have a need to implement 2. and planned to do so this month.

For 1., can you elaborate? You mean you want to generate the property type definition as well?

Support for flows is something I never test, since I barely need them.

[nvcyc]

For 1:

It is for property value assignment that's already included the current XML by aadl_xml. The issue is that the current aadl_xml places a property inside a <property> element with its value in a child element <property_value><value> without specifying its data type. This can cause confusion when, for example, distinguishing between an integer-typed property value and a string-typed property value. In this example, both will have XML elements presented as:

<property name="Name_of_Some_Property">
    <property_value>
        <value value="10"/>
    </property_value>
</property>

in which one can not tell if the value "10" is an integer or a string.

A better way to represent the value might be:

For an integer property:

<property name="Name_of_Some_Integer_Property">
    <property_value>
        <value type="IntegerLiteral" value="10"/>
    </property_value>
</property>

For a string property:

<property name="Name_of_Some_String_Property">
    <property_value>
        <value type="StringLiteral" value="10"/>
    </property_value>
</property>

And additionally for a list of integers:

<property name="Name_of_Some_List_Integer_Property">
    <property_value>
        <value type="ListValue">
            <value type="IntegerLiteral" value="1"/>
            <value type="IntegerLiteral" value="2"/>
        </value>
    </property_value>
</property>

For 2:

It's good to hear that you have a plan for adding connections in aadl_xml this month. I'm looking forward to this new feature!

For 3:

I agree that this is less appealing compared to the above two. We can come back for this later when the above two additions are resolved.

[yoogx]

For 1., see resources/runtime/aadl_xml, there is the XML Schema we should follow. Adding type as you propose is not a big deal. Note that I am not sure the current backend properly addresses lists or records. This was a proof of concept, no more

[nvcyc]

Thanks for pointing to the XML schema that I missed. By looking at the aadl_xml code, it indeed does not handle lists and records. Adding support for lists and then expanding to consider various property types seem to be a good starting port for 1.

[nvcyc]

I'm writing to give you an update for this issue:

1. I have finished implementing the support of nested lists and records in property values in aadl_xml.
2. I have also added port connections in addl_xml.

I will send them as two separate pull requests, one after another is merged as the later commits will depend on the former PL, so that it's easier for you to review the changes and we can have deeper discussion in the PL if necessary.

I will create the first PL once the current PL #292 in the queue is resolved.

[nvcyc]

Regarding connections in the XML, you have source (and destination) elements defined in XSD as follows:

https://github.com/OpenAADL/ocarina/blob/451e3b0df7dc2df1f494146d271efa2d822ae0ca/resources/runtime/aadl_xml/aadl.xsd#L162-L167

Can you elaborate a bit about what you expect to see in the component and feature attributes?

I expect that there should be an attribute (possibly named port_connection_reference that may correspond to your component here) that shows a port's identifier like port_1 or with its subcomponent's identifier if needed, such as sub_com_1.port_1.

[yoogx]

Sorry for the delay in answering this initial point. I am formalizing AADL in a separate project and got distracted on similar issues.

As you have seen in AADL, connection are of the form feature or component.feature

The idea was to capture this in two separate fields to avoid additional processing

• in the first case, component would be empty, feature will be the id of the feature
• in the second case; it would have the id of the component and the id of the feature

but since I am not doing anything of this XML file, feel free to propose whatever approach that would ease further processing

[nvcyc]

Thanks for your explanation. The PL #294 was implemented based on what you suggested.

[yoogx]

I think #294 closes this issue; can you please confirm? thanks for the patches!

[nvcyc]

Thanks! This issue should be considered being resolved with the merged patches.

[nvcyc]

Just realized that the connection type (e.g., bus access, port connection) is missing from the connection elements in XML. While checking the connection instances, it doesn't seem like the connection type information is properly stored in Associated_Type in a connection instance object:

https://github.com/OpenAADL/ocarina/blob/60cc1efec469354457d41e86365f9c078060128d/src/core/instance/ocarina-instances-components-connections.adb#L249-L252

Is it expected? If not and we are to make Associated_Type usable, what was the initial thought about Associated_Type here? Should we make Associated_Type store Ocarina.ME_AADL.Connection_Type?

[yoogx]

I am not sure Associated_Type has the semantics you expect. And since this code is 12 years old, it is likely to be a left-over of some design

We have an accessor that provides this mechanism, see

https://github.com/OpenAADL/ocarina/blob/a9b385bc2c11915a7c06ab184471197081cac08c/src/core/tree/ocarina-me_aadl-aadl_instances-entities.ads#L79

This function fetches the information in the declarative model though.