Automation

Just like any other process, the ASSERT process can be viewed as a "black box", operating on a number of inputs and producing a single output: the compiled, executable parts of the system.

These are the inputs required for the actual compilation of the system:

• The ASN.1 grammar describing the messages exchanged between APLCs (over Provided and Required Interfaces)
• The overall system model's Interface view (in AADL [3])
• The overall system model's Concurrency view (in AADL [3])
• The functional models for the APLCs of this system (SCADE, MATLAB/Simulink, ObjectGeode, etc)

Due to the complex build process required, a central "orchestrator" is necessary: automated logic that takes care of all the details of performing each individual step in the ASSERT process. The Data Modeling Toolchain includes the assert-builder...

Usage: assert-builder.py <options>
Where <options> are:

-f, --fast
        Skip waiting for ENTER between stages

-n, --nokalva
        Use OSS Nokalva for ASN.1 compiler (if missing, asn1Scc is used)

-o, --output <outputDir>
        Directory with generated sources and code

-a, --asn <asn1Grammar.asn>
        ASN.1 grammar with the messages sent between subsystems

-i, --interfaceView <i_view.aadl>
        The interface view in AADL

-c, --concurrencyView <c_view.aadl>
        The concurrency view in AADL (as generated by the VT)

-S, --subSCADE name:<zipFile>
        a zip file with the SCADE generated C code for a subsystem
        with the AADL name of the subsystem before the ':'

-M, --subSIMULINK name:<zipFile>
        a zip file with the SIMULINK/ERT generated C code for a subsystem
        with the AADL name of the subsystem before the ':'

-C, --subC name:<zipFile>
        a zip file with the C code for a subsystem
        with the AADL name of the subsystem before the ':'

-A, --subAda name:<zipFile>
        a zip file with the Ada code for a subsystem
        with the AADL name of the subsystem before the ':'

-G, --subOG name:file1.pr<,file2.pr,...>
        ObjectGeode PR files for a subsystem
        with the AADL name of the subsystem before the ':'

For example, when the script is used to create ASSERT's PFS Pilot Project, it is invoked like this:

bash$ assert-builder.py \
        --fast \
        -o output/ \
        -a newPackages/D_view.asn1 \
        -i newPackages/MSU_Thread.aadl \
        -c newPackages/MSU_Thread_conc.aadl \
        -G newPackages/MSU_Threads_Basic.pr \
        -G newPackages/MSU_Threads_Control.pr \
        -G newPackages/MSU_Threads_Cyclic.pr \
        -S newPackages/ScadeBlock.zip

Figure 4.1: Integration in the UML modeling tool

Figure 4.2: Selecting the inputs

The "orchestrator" completely takes care of the following:

• Translating the ASN.1 grammar into AADL DATA definitions (asn2aadlPlus)
• Creating the modeling tool-specific type definitions (asn2dataModel)
• Creating the appropriate "glue" for each APLC, after parsing the system model (aadl2glueC)
• Creating the ASN.1 encoders/decoders (invoking asn1Scc or Nokalva to generate the source code, via the ASN.1 Grammar)
• Unpacking the .zip files containing the code for the subsystems and invoking the directly supported modeling tool code generators (ObjectGeode)
• Invoking Ocarina to generate the VM
• Compiling (via gnatmake) the VM sources (Ada)
• Compiling (via gcc) the ASN.1 encoders/decoders
• Compiling (via gcc) the source code for the SCADE/MATLAB/etc synchronous models
• Compiling (via gcc) the source code for the ObjectGeode/C/Ada/etc asynchronous models
• Auto-resolving the (possibly) conflicting symbols that might appear in the object files
• Linking it all together into a working executable (or executables, if the deployment so dictates)

Needless to say, this automation immensely helps the - otherwise very tedious and error prone - integration phase of ASSERT projects. Also note that parts of this process are directly available through online gateways [10].