Documentation Center

  • Trial Software
  • Product Updates

Testing the Generated Code

This example shows how to validate generated code by using system-level S-functions or running code in an external environment.

Time: 45 minutes

Goals

Understand...

  • Different methods available for testing generated code

  • How to test generated code in Simulink®

  • How to test generated code outside of Simulink

Task: Open the model.Task: Open the model.

Validation Methods for Generated Code

Simulink supports multiple system testing methods for validating the behavior of generated code.

Windows® run-time executable - Generate a Microsoft® Windows® based executable and run the executable from the command prompt.

  • Pros: Easy to create, can use C debugger to evaluate code

  • Cons: Partial emulation of target hardware

Software-in-the-loop (SIL) testing - Use an S-function wrapper to include the generated code back into the Simulink model.

  • Pros: Easy to create, allows you to reuse the Simulink test environment, can use C debugger to evaluate code

  • Cons: Partial emulation of target hardware

Processor in the loop (PIL) testing - Run a non-real-time cosimulation with Simulink executing a portion of the model (e.g. Plant Model), and the target processor running a portion of the model (e.g. Controller). Code is downloaded to the target processor, and processor-in-the-loop handles the communication of signals between Simulink and the target during cosimulation.

  • Pros: Allows you to reuse the Simulink test environment, can use C debugger with the simulation, actual processor is used

  • Cons: Requires additional steps to set up test environment, processor does not run in real time

On-target rapid prototyping - Run generated code on the target processor as part of the full system.

  • Pros: Can determine actual hardware constraints, allows testing of component within the full system, processor runs in real time

  • Cons: Requires hardware, requires additional steps to set up test environment

External Mode - Run generated code on the target processor as part of the full system.

  • Pros: Can determine actual hardware constraints, allows testing of component within the full system

  • Cons: Requires hardware, requires additional steps to set up test environment

Reusing Test Data: Test Vector Import/Export

In this example, the same test data has been used by previous modules. While the unit under test was in Simulink this was easy to achieve. The test data can be reused outside of the Simulink environment. To accomplish this task:

  • Save the Simulink data into a file.

  • Format the data in a way that the system code can access.

  • Read the data file as part of the system code procedures.

Likewise, the test environment can be reused provided that the data from the external environment is saved in a format that MATLAB® can read. In this example, the file hardwareInputs.c contains the output data from the Signal Builder block in the test harness model.

Testing via Software-in-the-Loop (Model Block SIL)

Creating the Model Block and Configuring it for SIL

Simulink can generate code from a Model block, wrap it into an S-Function, and bring the resultant S-Function back into the model for Software-in-the-loop testing.

Task: Open the test harness model.Task: Open the test harness model.

The test harness uses a Model block to access the model we want to run software-in-the-loop test on.

  1. Right-click on the Model block and select Block Parameters (ModelReference)

  2. In the Model name field, enter the name of the model to be tested like in the dialog view below.

  3. In the Simulation mode field, select Software-in-the-loop (SIL) like in the following dialog view:

After you create the Model block and configure it for SIL operation, the block will have a (SIL) tag attached to it:

Configuring the Model Block model for SIL

Next, you need to configure several settings in the Model block model.

Task: Open the Model block model.Task: Open the Model block model.

  1. Open the Model Explorer and navigate to the Model block model.

  2. Click Configuration in the Model Hierarchy pane.

  3. Click Hardware Implementation in the Contents pane.

  4. Select Generic in the Device vendor field and 32-bit x86 compatible in the Device type field.

We are now ready to start the simulation.

Running the Model Block SIL

The test harness model is reused with a modification; the Model block has been configured for SIL as you did in the previous steps.

Task: Open the test harness.Task: Open the test harness.

Task: Run the test harness.Task: Run the test harness.

Again, the results from running the generated code are the same as the simulation results.

Configuring the System for Testing via Test Vector Import/Export

This module extends the integration example in Integrating the Generated Code into the External Environment. In this case example_main.c has simulated hardware I/O.

The augmented example_main.c file now has the following order of execution:

  1. Initialize data (one time) while < endTime

  2. Read simulated hardware inputs

  3. PI_cnrl_1

  4. PI_ctrl_2

  5. Pos_Command_Arbitration

  6. Write simulated hardware outputs end while

Task: View example_main.c.Task: View example_main.c.

The input test data is supplied by two functions, plant and hardwareInputs.

Plant.c - Code generated from the plant section of the test harness. Simulates the throttle body response to throttle commands.

void Plant(void)

HardwareInputs.c - Provides the pos_req signal and adds noise from the Input_Signal_Scaling subsystems into the plant feedback signal.

void hardwareInputs(void)

Data logging is provided by the hand-coded function WriteDataForEval.c. The function is executed once the test is complete. The test data is written to the file PCG_Eval_ExternSimData.m. You can load the MATLAB program into the MATLAB environment and compare it to the simulated data.

To enable these additional files add them to the Code Generation > Custom Code > Include list of additional: > Source files dialog.

Testing via Test Vector Import/Export (Eclipse™ Environment)

Before building an executable in the Eclipse™ environment, regenerate the code without the S-function interface.

Task: Build C code for integration.Task: Build C code for integration.

Instructions on how to install and use Eclipse™ and GCC appear in Installing and Using Cygwin™ and Eclipse™.

To install the files for this module automatically, do the following:

Task: Automatically set up the build directory.Task: Automatically set up the build directory.

To manually install the files, do the following:

  1. Create a build directory (Eclipse_Build_P6).

  2. Unzip the file rtwdemo_PCG_Eval_P6.zip into your build directory.

  3. Delete the files, rtwdemo_PCG_Eval_P6.c, ert_main.c and rt_logging.c which are replaced by example_main.c.

Running the control code in Eclipse™ generates the file eclipseData.m. This file was generated by the file writeDataForEval.c. You can compare the data from the Eclipse™ run and the standard test harness by loading the data and then running the plot routine.

Was this topic helpful?