Aggregates and unions of types

[reteprelief]

When modeling communication there are situations where data of multiple types is communicated between tasks. Similarly, data from multiple sources may be aggregated and sent as a single message. AADL has support in several forms for that. 1) union of types on data types (currently not interpreted by OSATE) 2) subset matching on feature groups (currently not supported in OSATE) 3) aggregate data type on ports (missing directly supported subset matching) In the following I am copying several emails on this topic from a recent question by Roger Champagne.

[reteprelief]

From Peter: Data_Model annex has information about union types. Data_Representation => union; Base_Type => (classifier (Base_Types::Integer), classifier(mypack::mydatatype));

Currently there is not consistency checking for that. Brian will send you a code snippet for implementing some checking. You can also use Resolute to write a checker.

[reteprelief]

from Roger: I just tried the solution Peter proposed today, and it unfortunately does not work. If I have a single message (e.g. one Data component) on one end of a connection between systems, and a Union data type on the other, where one of the alternatives is the same Data as the other end, I get type mismatch error. Perhaps the fact that I am working with Data implementations? I don't see how to set properties otherwise. I also tried putting a Union on both ends (with just one type on one end), then I get a different error (incompatible classifiers or something along those lines).

I updated my archive:

https://drive.google.com/open?id=0B1DoYRvDRVLhMWZ1NHdiTTl3Y2M

[reteprelief]

From Brian Larson: I suggested using properties of ports to specify what kinds of messages are sent or received.

This is different from the data types of ports.

Unfortunately, this requires you to write your own plug-in to fetch, and compare lists of enumeration identifiers.

Following Alexey's AFDX example, I used virtual buses to represent publish-subscribe services of a medical application platform. However, the data types on both ends matched. I don't think virtual buses will do what you want.

Let me be as clear as possible:
I'm not suggesting properties of data types for data ports.
I'm suggesting properties (lists of enumeration labels) of ports themselves.

You can then use the property enumeration to choose the from the Data_Model::Data_Representation=>union data type list of strings of Data_Model::Element_Names, which would then indicate the Data_Model::Base_Type of the message.

[reteprelief]

A couple of notes from my perspective.

As Peter mentioned, it would be interesting to present in the model not only low level connections described in ARINC-710 specs but also abstract connections between systems. For example, to have a separate port for each message type (may be combined into feature groups) and to attach a data type to each port. Then connection bindings can be used to map the logical port connections to physical ones, which are usually represented by BUSes.

If these logical connections are implementation specific, then it may be make sense to have virtual buses for each message type as a part of AADL library that describe reusable model components for various implementations using ARINC-710 protocol.

[reteprelief]

From 2015 errata slides:

Issue Transfer of data from multiple sources as single message

AADL V1 specification Feature group with property indicating intended transfer as single message Flexibility of switching between aggregate and individual message transfer AADL V2 Outer component with port that has a data component with subcomponents Users explicitly connect an inner port to the data subcomponent of the outer port Manual change of model to change transmission protocol Desirable Treat the issue as a protocol issue!! Bind collection of connections to an appropriate virtual bus (protocol)

[rchampag]

Thanks to all for your precious help. As it seems to be the simplest solution, I will go with individual ports for each message for now, and group these ports into feature groups as soon as OSATE supports subset matching on feature groups. This solution, I believe, also simplifies the upcoming steps in our project, and does not require us to write new analysis tools for now. I will post back here once I have a working model available on Google drive.