AADL Export and message definitions

Hi. I am experimenting with the “Export” feature to generate *.aadl files from my Tangram model. I am able to work with the exported files in an AADL modeling environment now, which is very nice!

I would like to ask if it is possible to extract the message definition through this export feature. For example, in my simple tutorial model of the UAS with three interfaces, the generated AADL produces the following:

package TPROMSG_OpenUxAS_cc_LMCP_cc_v3
public

data afrl_p_cmasi_p_AirVehicleConfiguration

end afrl_p_cmasi_p_AirVehicleConfiguration;
data afrl_p_cmasi_p_GimbalState

end afrl_p_cmasi_p_GimbalState;
data afrl_p_cmasi_p_AirVehicleState

end afrl_p_cmasi_p_AirVehicleState;

end TPROMSG_OpenUxAS_cc_LMCP_cc_v3;

With only these empty data declarations, I’m back to manually defining and integrating the message structures in C code. Is there any way to extract the definitions, i.e. message contents, of these into AADL? This would help me to complete the bridge between the system model and a software implementation.

Hi @john.macauley great question. The short immediate answer is that you cannot currently extract the message definition via AADL export. The way to extract the message definition currently is by going into the “FlexLang” portion of Tangram Pro. From the Dashboard view you can click “FlexLang” on the left hand side and the message definitions that are currently included in the product are provided. See LMCP Documentation? for more details. While not automated yet, when you see the message(s) definition, you can then copy paste to export that message definition. Side note, in the next version of the product, you will also be able to author your own Flex Message Definitions. However, automating the process of importing/exporting message definitions is definitely something we will include in future planning consideration. I do have a question though on whether you think it makes sense to export that message definition via AADL? From our thinking, AADL Data components are typically very lean. There isn’t any “content” to them, really, unless we’re talking about specific properties attached to the component definition. But, appreciate your thoughts and feedback on your view here. Also tagging @jon.mcgill and @john.weis for your thoughts on the above.