Target Environments and Applications
About Target Environments
The code generator produces make or project files to build an executable program for a specific target environment. The generated make or project files are optional. If you prefer, you can build an executable program for the generated source files by using an existing target build environment, such as a third-party integrated development environment (IDE). Applications of generated code range from calling a few exported C or C++ functions on a development computer to generating a complete executable program that uses a custom build process for custom hardware, in an environment completely separate from the development computer running MATLAB® and Simulink®.
The code generator provides built-in system target files that generate, build, and execute code for specific target environments. These system target files offer varying degrees of support for interacting with the generated code to log data, tune parameters, and experiment with or without Simulink as the external interface to your generated code.
Types of Target Environments
Before you select a system target file, identify the target environment on which you expect to execute your generated code. Theses are the most common target environments.
The computer that runs MATLAB and Simulink. A development computer is a PC or UNIX®a environment that uses a non-real-time operating system, such as Microsoft® Windows® or Linux®b. Non-real-time (general purpose) operating systems are nondeterministic. For example, those operating systems might suspend code execution to run an operating system service and then, after providing the service, continue executing application code. Therefore, the executable for your generated code might run faster or slower than the sample rates that you specified in your model.
A different computer from the development computer. A real-time simulator can be a PC or UNIX environment that uses a real-time operating system (RTOS), such as:
The generated code runs in real time. Execution varies based on the behavior of the system hardware and RTOS.
You connect a real-time simulator to a development computer for data logging, interactive parameter tuning, and Monte Carlo batch execution studies.
A computer that you eventually disconnect from a development computer and run as a standalone computer as part of an electronics-based product. Embedded microprocessors range from high-end digital signal processors (DSPs) to process communication signals to inexpensive 8-bit fixed-point microcontrollers in mass production (for example, electronic parts produced in the millions of units). Embedded microprocessors can:
a UNIX is a registered trademark of The Open Group in the United States and other countries.
b Linux is a registered trademark of Linus Torvalds.
A target environment can:
Have single- or multiple-core CPUs
Be a standalone computer or communicate as part of a computer network
You can deploy different parts of a Simulink model on different target environments. For example, it is common to separate the component (algorithm or controller) portion of a model from the environment (or plant). Using Simulink to model an entire system (plant and controller) is often referred to as closed-loop simulation and can provide many benefits, such as early verification of a component.
This figure shows example target environments for code generated for a model.
Applications of Supported Target Environments
This table lists ways that you can apply code generation technology in the context of the different target environments.
|Acceleration||Techniques to speed up the execution of model simulation in the context of the MATLAB and Simulink environments. Accelerated simulations are especially useful when run time is long compared to the time associated with compilation and checking whether the target is up to date.|
|Rapid Simulation||Execute code generated for a model in non-real-time on the development computer, but outside the context of the MATLAB and Simulink environments.|
|Shared Object Libraries||Integrate components into a larger system. You provide generated source code and related dependencies for building a system in another environment or in a shared library to which other code can dynamically link.|
|Protect Models to Conceal Contents||Generate a protected model for use by a third-party vendor in another Simulink simulation environment.|
|Real-Time Rapid Prototyping||Generate, deploy, and tune code on a real-time simulator connected to the system hardware (for example, physical plant or vehicle) being controlled. Crucial for validating whether a component can control the physical system.|
|Shared Object Libraries||Integrate generated source code and dependencies for components into a larger system that is built in another environment. You can use shared library files for intellectual property protection.|
|Hardware-in-the-Loop (HIL) Simulation||Run a simulation that pairs physical hardware, such as a controller, with a virtual real-time implementation of physical components on a real-time target computer, including a plant, sensors, actuators, and the environment. Use HIL simulations to test and validate physical hardware and a controller algorithm by including the effects of component response in real time to realistic stimuli. Testing compares the HIL simulation results to system requirements. Validation compares HIL simulation results to user requirements. Often HIL simulations are referred to as closed-loop simulations due to the component response to the physical environment stimuli.|
|Code Generation||From a model, generate code that is optimized for speed, memory usage, simplicity, and compliance with industry standards and guidelines.|
|Software-in-the-Loop Simulation||Compile generated or external source code intended for production and execute the code as a separate process from the rest of the Simulink model on your development computer. Goals include initial source code testing and verification by comparing SIL and model simulation results or comparing SIL results to requirements by using back-to-back testing. Commonly used with external code integration, bit-accurate fixed-point math, and coverage analysis.|
|Processor-in-the-Loop Simulation||Cross-compile generated or external source code intended for production on a development computer, and then download and run the object code on a target processor or an equivalent instruction set simulator. Goals include verification by comparing PIL simulation results against model or SIL simulation results and collecting execution time profiling data. Commonly used with external code integration, bit-accurate fixed-point math, and coverage analysis.|
|Hardware-in-the-loop (HIL) Simulation||Run a simulation that pairs physical hardware, such as a controller, with a virtual real-time implementation of physical components on a real-time target computer, including a plant, sensors, actuators, and the environment. Use HIL simulations to test and validate physical hardware and a controller algorithm by including the effects of component response in real time to realistic stimuli. Testing compares the HIL simulation results to system requirements. Validation compares HIL simulation results to user requirements. Often HIL simulations are referred to as closed-loop simulations due to the component response to the physical environment stimuli.|