QGen

TASTE/QGen integration: a demo setup

Introduction

This article contains a simple demo workflow based on the Simulink models used in the UPMSat-2 Attitude Control System (ACS). The main objective of the demo is to illustrate the bindings between the architectural modelling in TASTE and the corresponding Simulink functional models.

The QGen toolset is used to generate C code taking the ACS Simulink model as the input. This demo is the result of the activities developed within the context of the European project AURORA (101004291) and reuses the work accomplished in the UPMSat-2 project.

Required tools

Apart from the TASTE Virtual Machine in its latest version (v10), you need to install:

• MatLab, version R2020b is recommended and used in this tutorial.
• Simulink.
• QGenc, version 21.0 or superior (22.0 is used in this tutorial).

NOTE: You can find the whole tutorial source code and models in this repository.

Overview of the Simulink models

This demo includes Simulink models used in the UPMSat-2 microsatellite. The control and aerospace engineers from the "Ignacio Da Riva" Institute at the Technical University of Madrid have implemented these models, which are publically available in this GitHub repository. The STRAST research group from UPM designed and implemented the onboard and ground segment software, including the integration of the autogenerated ACS sequential code into the onboard software using the appropriate Simulink toolset.

In essence, the UPMSat-2 ACS subsystem determines the satellite's attitude, that is, its orientation relative to the Earth's surface. To do so, the satellite is equipped with three magnetometers, each measuring all three axes, and three magnetic torquers (AKA magnetorquers), one per axes.

Simulation environment model for the ACS

The ACS_SIL.slx Simulink model contains blocks that simulate the satellite environment (Earth and Sun), the On-Board Computer (OBC), and relevant equipment for the ACS such as magnetometers and magnetorquers. The entire model was developed following a hierarchical structure. The following figure depicts the internals of the ACS_SIL/UPMSat_2/OBC/Nominal Attitude Control subsystem.

In brief, this subsystem is composed of two blocks:

• The Sensor block (red) on the left is in charge of the data acquisition, i.e.: reading five samples from the three magnetometers. These readings are sent as an array of 15 elements (5 samples × 3 readings/magnetometer) through the B_b_T output signal.
• On the right, the PWM block (red) controls the magnetorquers via Pulse Width Modulation (PWM). The actual command is read from the Control input signal.

The original model contained the Control block in the middle. This block implemented the actual control algorithm and is described in the next subsection. Since this demo includes the Control algorithm as part of the TASTE model, we had to replace the Control block with TCP/IP blocks. This way, the Sensor and PWM blocks shown above will communicate with our TASTE model by means of TCP/IP sockets.

ACS Control algorithm

The following figure shows the ACS (closed-loop) control algorithm implemented in Simulink. On the left side, there are five input signals that represent the MGMs readings (B_b_T) and configuration parameters; for example; Omega (input port 2) which specifies the setpoint (the desired angular velocity from the vehicle), or the MT_working (input port 6) array that specifies the working MGTs in the attitude control. On the right side, there is only one output signal that holds the values that control the actuators (MTTs) according to the input values.

General process

During the UPMSat-2 project, the ACS Simulink models have been integrated into the onboard software model following the next steps:

• C sequential code for the control algorithm is automatically generated from the dynamic Simulink model.
• Sequential code is embedded into the corresponding functional block in charge of the ACS.
• The code is uploaded to the onboard computer for testing using the Simulink HIL (Hardware-in-the-Loop) facilities to validate the ACS operation against the environmental model of the satellite attitude.

In this demo, we demonstrate the automation of these three steps using TASTE and QGen, increasing productivity and reducing the workload associated with them throughout the whole system life cycle.

Modelling workflow

Prepare the TASTE models

So far, we have seen an overview of the environment and control Simulink models. We have to create the TASTE project that (1) will contain the control algorithm and (2) communicate with the simulated environment. These two functional aspects suggest the following decomposition for the Interface View:

1. Simulated ACS HW: This TASTE Function is in charge of the communication with the simulated environment utilizing a TCP/IP socket. It will act as the server end of the communication and offer two Provided Interfaces (PI): Read_MGM to read the magnetometers, and Control MGT to send the magnetorquers commands.
2. ACS: This is a composite TASTE function that will implement the ACS algorithm; thereby, it is composed of:
   1. ACS Algorithm, this is a QGenC component that holds the control algorithm previously described. Therefore it offers the Step unprotected PI that receives the six input signals as input parameters and returns the Control signal through an output parameter.
   2. Measurer And Actuator, this is the active component and orchestrates the traditional control steps: read, control, actuate. This sequence is performed by the Tick cyclic PI.

TASTE IV for this demo

There is one execution flow activated every 2 seconds by the Tick PI from Measurer And Actuator:

1. Read the magnetometers invoking the Read_MGM interface,
2. pass these readings to the control algorithm invoking the Step interface, and
3. call the control MGT interface to send the command returned previously by the Step interface.

To fully define the Interface View of our model, we have to define the data types in ASN.1 used for these functions based on the Simulink models in/output parameters. The following listing shows the entire Data View:

 QGEN-TUTORIAL-DATAVIEW DEFINITIONS ::=
 BEGIN
     -------------------------
     -- Reusable data types --
     -------------------------
     T-Float  ::= REAL (-3.4e+38 .. 3.4e+38)
      
     -------------------------------------------
     -- Data types used for the ACS component --
     -------------------------------------------
     -- Input types:
     T-B-b-T      ::= SEQUENCE (SIZE(15)) OF T-Float
     T-Omega      ::= SEQUENCE (SIZE(3))  OF T-Float
     T-MT-Working ::= SEQUENCE (SIZE(3))  OF T-Float

     -- Output types:
     T-Control    ::= SEQUENCE (SIZE(3))  OF T-Float
 END 

Finally, the following table presents in detail the interfaces from all our TASTE functions:

Provided Interfaces (PI) detailed description

PI Name	PI Type	Parameters
		Name	Type	Direction
Read_MGM	Unprotected	BBT	T-B-b-T	OUT
Control_MGT	Unprotected	Control	T-Control	IN
Step	Unprotected	BBT	T-B-b-T	IN
		Omega	T-Float	IN
		K_PB	T-Float	IN
		K_PE	T-Float	IN
		M_M	T-Float	IN
		MT_Working	T-MT-Working	IN
		Control	T-Control	OUT
Tick	Cyclic	∅	∅	∅

Implement the TASTE functions

The next step is to implement all our TASTE functions defined previously. Since TASTE is a heterogeneous toolchain, it allows the implementation of a function in different programming and modelling languages. In this demo, we will show the C implementations of the Measurer_And_Actuator, and Simulated_ACS_HW; their Ada counterpart is available in the GitHub repository. Finally, the ACS_Algorithm is implemented as a QGenC function.

Simulated ACS Hardware

This function acts as a TCP/IP server to communicate with the simulated environment implemented in Simulink. The general data flow from all these functions is depicted in the figure below. In this figure, we can observe that the Simulated ACS Hardware is the functional element that abstracts the access to the Simulink environment. If the communication were achieved by serial ports, then we would have to implement our function accordingly. The whole function implementation is available on the GitHub repository.

NOTE: An alternative would be to integrate the simulated environment as a set of TASTE Functions. This way we wouldn't have to code the underlying communication aspects between the Simulink model and TASTE.

Measurer and Actuator

This is the only active object from the whole system, i.e.: it contains one thread. This function has to implement the control steps (Tick) invoking its Required Interfaces (RI). The following excerpt of code shows the implementation of the Tick function in C:

void measurer_and_actuator_PI_Tick(void) {
   // IN params:
   static asn1SccT_B_b_T bbt; 
   static asn1SccT_Omega omega = {
       .arr = {0.0, 0.0, 0.1}
   };
   static asn1SccT_Float k_pb = 2.0;
   static asn1SccT_Float k_pe = 8.0;
   static asn1SccT_Float m_m  = 15.0;
   static asn1SccT_MT_Working mt_working = {
       .arr = {1.0, 1.0, 1.0}
   };

   // OUT params:
   static asn1SccT_Control control;

   // Traditional control loop:
   measurer_and_actuator_RI_Read_MGM(&bbt);
   measurer_and_actuator_RI_Step(&bbt, &omega, &k_pb, &k_pe, &m_m, &mt_working, &control);
   measurer_and_actuator_RI_control_MGT(&control);
}

As you can see in the omega parameter, we have set the ACS algorithm to stabilize the vehicle spinning at 0.1 rad/second in the Z-axis.

ACS Algorithm

Among the other things, TASTE generates MatLab scripts for Simulink model provided interfaces (one per component). Currently, the metamodel is restricted to one PI per function and no RIs. 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 the Simulink model can be correctly bound to those in the TASTE interface model. To do it, follow the next steps:

1. Double left-click the ACS_Algorithm function, select QGenC in the Language drop menu from the Implementation tab.
2. Richt click the ACS_Algorithm function and select the option: Edit implementation. This will open MatLab in the corresponding working directory.
3. Load the autogenerated Simulink (.sl) model for the Step function. This model contains the wrapper (i.e.: input and output ports) regarding the configuration from the IV.
4. Open in another window the Control model shown in section ACS Control algorithm and copy this model (click Ctrl + c)
5. Inside the autogenerated Simulink wrapper from step 3:
   1. Create a subsystem named control, for instance, and click inside.
   2. Then, paste this model into the subsystem you have just created.
6. Reconnect inputs and outputs to the functional block in/outputs, and save the model.

NOTE: There is a mismatch between the ports (Double) and control algorithm types (Single), thus, you need to make the cast from Double to Single and vice versa

You should get a model similar to the following one, a set of wrappers connected to the actual control algorithm:

Execution of the Demo

The last step is to test this demo. To do so you first need to generate the code and binary; there are two alternatives:

• The first one is by the terminal or console. You have to run make in the root directory of your project.
• This is the easiest one. Click on the hammer symbol from the Qt Creator IDE (alternatively, type Ctrl + B).

We choose the first option. If successful, it is time to run our demo:

1. First, run the generated binary located in the work/binaries/ directory.
2. Since we are simulating the satellite platform in Simulink you need to start it by clicking on the play symbol.

At this point, the demo binary and the Simulink model should be running and connected employing TCP/IP sockets.

To visually inspect the correctness of the algorithm, have a look at the angular velocity scope. The setpoint established in the control loop was specified in the omega parameter (the second one) from the Tick PI. As you can see in the following figure, the angular velocity on the Z-axis is 0.1 rad/sec approx and 0 rad/sec on the X and Y-axis.

Angular velocity evolution (Simulink Scope)

---

© Copyright 2022, STRAST-UPM research group

This work was developed by the Real-Time Systems Group at the Technical University of Madrid (UPM)