Data Modeling in the ASSERT process

Figure 1.1: Data Modeling with ASN.1

Figure 1.1 displays a high level view of how ASSERT integrates data modeling in the overall system modeling. The yellow blocks depict stages where manual labour is required, and the green ones depict machine-generated entities.

1. The process begins with manual specification of the data models for the messages exchanged between subsystems (AP Level containers). This is where details about types and constraints of message members are specified. To be usable from within the system (AADL [3], UML [4]) specifications, these message definitions are translated into (AADL/UML) data definitions. These definitions are in turn used by the users doing the system modeling - they are referenced during the high level design of the system, in order to create the overall system model (in AADL/LabASSERT or UML/Eclipse).
2. The actual functional modeling of subsystems is next - but before it begins, the exchanged messages' descriptions are read, and semantically equivalent definitions of the data messages are created for each modeling tool's language (e.g. Lustre [5] definitions for SCADE [6] modeling, Simulink [7] definitions for MATLAB/Simulink modeling, etc). This way, the teams building the individual subsystems know that their message representations are semantically equivalent and that no loss of information can occur at subsystem borders.
3. Functional modeling is then done for the individual subsystems. The modeling uses the data definitions as they were generated in step 2.
4. When functional modeling is completed, the modeling tools' code generators are put to use, and C code is generated. Modeling tools generate code in different ways; even though (thanks to step 2) the data structures of the generated code across different modeling tools are carrying semantically equivalent information, the actual code generated cannot interoperate as is; error-prone manual labour is required to ``glue'' the pieces together. This is the source of many problems<sup>2.3</sup>, which is why ASN.1 is used in ASSERT: by placing it as the center of a star formation amongst all modeling tools, the ``glue-ing'' can be done automatically.
5. The ASN.1 compiler is used to create encoders and decoders for the messages.
6. ``glue'' code is then generated, that maps (at runtime) the data from the data structures generated by the modeling tools to/from the data structures generated by the ASN.1 compiler.
7. Code from the ASN.1 compiler, code from the modeling tools and ``glue'' code are compiled together inside VM [2] Level containers.
8. The VM Level containers are executed on top of VM [8],[9].

The sections that follow elaborate on the steps of this process that relate to data modeling.