Model mapping and code generation

Figure 2.2: From ASN.1 to modeling tool definitions
  

0.56

As shown in section 1.3, the ASSERT process begins with ASN.1 data modeling of the messages exchanged between interfaces and the use of asn2aadlPlus and/or asn2uml. After these tools generate the AADL/UML definitions of the exchanged messages (based on the ASN.1 grammar that described the message contents), the remainder of the system modeling can take place, using the generated data definitions. This system modeling process, will eventually be concluded; at that point functional modeling of the individual building blocks (APLCs) must take place.

The functional modeling of the APLCs requires modeling-tool specific data models. The specification of these models has to be done in the modeling languages of their respective tools. Data models in ASN.1 must therefore be translated to their equivalent representations for each modeling tool (in the modeling language used by each tool - e.g. Lustre [5], SDL [13], etc).

The reason for this step becomes clear if we consider that possibly different teams will be performing the functional modeling of each building block (AP-Level container). This stage can introduce inconsistencies unless the teams working on the two sides of an interface have semantically equivalent representations of the messages exchanged, otherwise unpredictable side effects will take place at the communication borders during runtime. The teams might be using different modeling technologies, so we need a way to guarantee semantic coherency between the different message representations used by each team.

asn2dataModel solves this problem, by reading the ASN.1 grammar that describes the exchanged messages, and generating the appropriate modeling-tool-specific definitions of the messages. It is invoked by each team developing a subsystem, to generate the desired data models in the modeling language that the team uses.