Difference between revisions of "QGen"

Jump to: navigation, search
m (1 revision imported)
Line 5: Line 5:
This document contains a simple demo workflow illustrating the bindings between architectural modelling in TASTE and corresponding functional models from Simulink and code from QGen.
This document contains a simple demo workflow illustrating the bindings between architectural modelling in TASTE and corresponding functional models from Simulink and code from QGen.
NB! The generated code and project file require either GNAT GPL 2015 (not available for linux 32bit that is used on the TASTE VM) or GNAT Pro starting the version 7.3. QGenc version 2.1 is required to generate the code.
''QGenc version 2.1 is required to generate the code.''
== Modelling workflow ==
== Modelling workflow ==

Latest revision as of 10:18, 8 June 2021

TASTE/QGen integration -- a demo setup


This document contains a simple demo workflow illustrating the bindings between architectural modelling in TASTE and corresponding functional models from Simulink and code from QGen.


QGenc version 2.1 is required to generate the code.

Modelling workflow

The demonstration model represents design of a PID controller with signal filtering for motor control. We assume that functional design is done already by the control engineer by the time the software design activity starts. Both the "plant" (Figure 1.1) -- motor and its environment -- and the controller (Figure 1.2)are validated using Simulink models.

caption Plant model for the motor control demonstrator (Simulink)
caption Controller model for the motor control demonstrator (Simulink)

Architecturally we divide the system into three parts:

  • PID -- the controller functionality
  • Plant -- the plant IO and
  • Scheduler -- takes care of periodic execution of other modules and data exchange between them.

The fourth component found in the model -- the Monitor -- is included only for testing purposes. It allows to observe the execution of other modules and compare the function outputs. We have also included two copies of both PID and plant to compare execution of code generated from the same model in C and Ada.

caption Interface view (Taste)

The interface view determines the components of the model as follows:

  • Scheduler is handwritten code (Ada) controlling the execution of the other modules.
  • Both of the PID functions use an identical Simulink model (one named Controller4_C.mdl, the other Controller4_Ada.mdl). The model is of a standard PID with inputs SV, PV and output MV.
  • The Plant represents the interface with the environment. In final implementation this component shall implement the IO interfaces. For simulation purposes we have replaced the actual IO with test vectors generated from Simulink simulations The component simply counts it's execution steps and returns a simulation vector value for the current step from a constant which is a 4000x3 matrix.

After completing the component specifications one has to decide the packaging and deployment of the components and determine the communication mechanism. This is done using the deployment view. In current case we have chosen to run all the components on the same node:

caption Deployment view (Taste)

Now the models are ready for code generation

Model conditioning and code generation

Preparing the TASTE model

To use QGen in TASTE the source language of a function must be set accordingly.

caption Language specification in TASTE

This is the only QGen-specific step in the TASTE editors the rest of the required information is derived from InterfaceView and DataView specifications.

The next step ist o generate the code skeletons either from the menu of Interface View Editor or from the command line in demo_controller4 folder:

demo_controller4$ taste-generate-skeletons

Editing the Simulink model and generating decoration file for QGen

Among the other things taste-generate-skeletons generates matlab scripts for Simulink model interfaces (one per component). These scripts create a model for each component (if it does not exist) and a port for each interface parameter from the Interface View.

As for this demo the Simulink models for components already exist the ports simply need to be reconnected to make sure that the interfaces of Simulink model can be correctly bound to those in the TASTE interface model.

  • Open Matlab and load Controller4_Ada.mdl from the root folder of the demo. Opening the model allows the interfacing script to find it. Otherwise a new empty model is generated in the pid_ada folder.
  • Go to the folder pid_ada (the folder is created by taste-generate-skeletons, if there was error in the previous step it may not exist)
  • Run the script named pid_ada_script.m
  • Go back to the demo root folder and open Controller4_Ada.mdl
  • Reconnect inputs and outputs to the functional blocks, save the model and check that simulation still works
  • Run the script export_decoration_file that is located in the share folder bundled with QGen (add it to Matlab path)
>> export_decoration_file ('Controller4_Ada')

Clear the Matlab workspace and repeat all the steps with Controller4_C.mdl. Workspace cleanup is important as the data type definitions are genrated diffrently for C and Ada code generation as the type information is made available for QGen through Bus and AliasTypes in Simulink the workspace content is different.

Running the build script and executing the result

When the last part is finished successfully, it is time to go back to TASTE and run the generated build-script.

demo_controller4$ ./build-script.sh

The script starts by executing QGen for each model according to the language specification from TASTE interface vies. As a result C code is generated for one PID component and Ada code for the other.

When the build-script has finished, two executables should be found in binary/binaries folder. Run the x86_partition in one terminal and GUI-monitor in another terminal.

x86_partition displays the execution results also in the terminal, but for a graphical representation, use the GUI part. The variables of the GUI are A_SV, A_PV, A_MV, corresponding to the IO of the Ada PID and C_SV, C_PV, C_MV, corresponding to the IO of the C PID.

caption Execution results