Component Verification in Target Environment

After you generate production code for a component design, you need to integrate, compile, link, and deploy the code as a complete application on the embedded system. One approach is to manually integrate the code into an existing software framework that consists of an operating system, device drivers, and support utilities. The algorithm can include externally written legacy or custom code.

An easier approach to verifying a component in a target environment is to use processor-in-the-loop (PIL) simulation. For information about PIL simulations, see SIL and PIL Simulations.

Goals of Component Verification

Assuming that you have generated production source code and integrated required externally written code, such as drivers and a scheduler, you can verify that the integrated software operates as expected by testing it in the target environment. During testing, you can achieve either of the following goals, depending on whether you export code that is strictly ANSI^® C/C++ or mixes ANSI C/C++ with code optimized for a target environment.

Goal	Type of Code Export
Maximize code portability and configurability	ANSI C/C++
Simplify integration and maximize use of processor resources and code efficiency	Mixed code

Regardless of your goal, you must integrate required external drivers and scheduling software. To achieve real-time execution, you must integrate the real-time scheduling software.

To maximize code portability and configurability, limit the application code to ANSI/ISO^® C or C++ code only, as the following figure shows.

To simplify code integration and maximize code efficiency for a target environment, use Embedded Coder^® features for:

• Controlling code interfaces

• Exporting subsystems

• Including target-specific code, including compiler optimizations

The following figure shows a mix of ANSI C/C++ code with code that is optimized for a target environment.

Run Component Tests

The workflow for running software component tests in the target environment is:

1. Integrate external code, for example, for device drivers and a scheduler, with the generated C or C++ code for your component model. For more information, see S-Functions and Code Generation. For more specific references that depend on your verification goals, see the following table.

   For	See
   ANSI C/C++ code integration	Integrate C Functions Using Legacy Code Tool.
   Mixed code integration	Generate Component Source Code for Export to External Code Base and open the SimulinkFunctions model. openExample('SimulinkFunctions') Configure Generated C Function Interface for Model Entry-Point Functions, Interactively Configure C++ Interface, and open the ConfigurationInterface model. openExample('ConfigurationInterface') What Is Code Replacement?, What Is Code Replacement Customization?, and example Optimize Generated Code by Developing and Using Code Replacement Libraries - Simulink

2. Simulate the integrated component model.

3. Generate code for the integrated component model.

4. Connect to data interfaces for the generated C code data structures. See Write External Code to Access Generated C API Code and Generate ASAP2 and CDF Calibration Files.

5. Customize and control the build process, if required. See Customize Post-Code-Generation Build Processing, and open the BuildInfoModel model.

   openExample('BuildInfoModel')

6. Create a zip file that contains generated code files, static files, and dependent data to build the generated code in an environment other than your host computer. See Relocate or Share Generated Code, and open the BuildInfoModel model.

   openExample('BuildInfoModel')