Deploy Generated Software

Simulink^® provides capabilities for designing top models and deploying them as generated code that behaves in a target execution environment like the model behaves during simulation. This figure and the following table shows the steps required for software deployment by using Simulink and Embedded Coder^®.

Workflow for model-based software deployment

Step	Goal
Identify requirements	Assess project deployment requirements and determine whether your objective is to deploy an application or component for your project.
Create code interface configuration (C only)	Create a configuration that informs the code generator how to customize generated code so that modelers can meet target environment interfacing requirements.
Develop deployable code	Design a top model, attach an Embedded Coder Dictionary that defines a code interface configuration (C only) to the model, select an output type, map model elements to code interfaces, and generate and verify that the code generator produces required interface code.
Deploy generated code	Deploy application code that runs as a standalone executable program in a single-process or multiprocess target environment. Deploy component source code modules for integration with an external main program, other target environment software, and other components.

Identify Requirements

Identify the requirements for your project. The requirements help you determine whether to deploy your top model as an application or component. This figure shows how scheduling and processing architecture differ between the deployment objectives.

Comparison of deployment objectives.

You will need to decide which of these deployment objectives meets scheduling and other target environment needs of your project. For application deployment, generated code includes an example main program that applies a single-tasking, rate-monotonic scheduling (RMS), or concurrent scheduling scheme. This scheme is configured for the model and determines how entry-point functions are assigned to tasks. For executing the algorithm code, you can use the generated scheduling and data transfer code as is, change it, or replace it. Meanwhile, component deployment requires integration of generated function code with an external function scheduler and other target environment software.

Code that you generate for application deployment can run on a single-process or multiprocess architecture as part of a real-time or non-real-time application, while code for component deployment can only run on a single-process architecture. For a single-process architecture, the generated code is optimized for a specific target device and meets hard real-time requirements. Multiprocess deployment addresses requirements of high-throughput and distributed execution applications.

For a list of requirements and conditions that apply to each deployment objective, see Software Deployment Objectives and Deployment Types. Use that information to identify the deployment type that best aligns with your project requirements.

For more information about assessing project requirements, see Map Embedded System Architecture to Simulink Modeling Environment.

Create C Code Interface Configuration

After researching C code interface requirements, you create a code interface configuration by using the Embedded Coder Dictionary. You can create data and service code interface configurations, as Code Interfaces and Code Interface Specification and Code Interface Configurations describe. The interfaces that you create as part of a code interface configuration depend on your project requirements and deployment objective.

For details about creating code interface configurations, see Code Interface Definitions.

Research for Code Interface Requirements

Before you can define a custom code interface configuration that aligns with specific target environment requirements, you need to gather requirements. Research the required application or component interactions with your target environment software. Identify sources of input and required output. Determine what the code for interfacing with other target environment resources must look like and how it must behave. For example, does your model or generated code need to exchange data with target environment services? If so, map inputs, outputs, and parameters to corresponding service interfaces. Typical service interfaces involve function arguments and return values, global variables, and access functions.

The following questions can help you identify interface requirements that are relevant to application or component deployment. Answers that you gather serve as input when defining a code interface configuration.

Category	Questions
Target environment services	Does the target environment use standard platform middleware, such as AUTOSAR or DDS? For information about AUTOSAR or DDS, see AUTOSAR Blockset and DDS Blockset. What target environment software will the deployed code interact with? For example, does the target environment include an operating system? What target services are available? A code interface configuration defines interfaces for the services that you identify. Does the target software expect the deployed code to handle startup or shutdown events? If so, the code interface configuration should define interfaces for initialize and terminate functions. Does the target software have naming requirements for entry-point functions that it calls to initiate execution of deployed code? If so, the code interface configuration should specify function names or function naming rules that align with the requirements. What are the names of the functions that the deployed code needs to call to use target services? The code interface configuration should specify function naming rules that align with the requirements.
Data communication	What data communication methods do target services use for handling concurrent access to data when communicating with deployed code (direct access, outside execution, or during execution)? The code interface configuration should define interfaces that use data communication methods that align with those used by the target environment services.
Data types	Does the target environment expect the input and output of deployed code to be represented as arrays, structures, or enumerated types? In the Simulink environment, you can represent these types as vectors, buses, and `IntEnum`, respectively. Is fixed-point support required? If you use the Simulink fixed-point interface, you can scale and specify offsets. Does the target environment software use organization-specific data types? If yes and you have Embedded Coder software, create alias types to represent those types. The code generator uses the alias types in the code that it produces. For example, once defined, you can specify an alias type in a function prototype, for a temporary variable, or for block output.
Memory usage and latency	Does the deployed code need to access shared memory? If yes, define and use memory sections in the code interface configuration. Do you need to deploy code that minimizes latency or optimizes memory usage when sending, receiving or sharing data? Does the target environment require that deployed code optimize memory usage when sending data? Define and map model elements to code interfaces that use data communication methods that align with the requirements.
Parameter tuning and data measurement	Does the target environment require access to variables that represent parameters for tuning or data for measurement purposes? If so, how does the target environment expect the data to be represented in the deployed code? Does the data need to reside in a specific header file? Define the interface to align with the requirements.
Deployment objective	Does the generated code running in the target environment consist of multiple deployed source code modules developed independently and integrated manually with a target function scheduler? Or, is the code a generated executable program that runs standalone on the target device (single-processing) or as a collection of executable programs that run concurrently in a multiprocessing architecture?

For some projects, these requirements are captured in an interface control document (ICD). An ICD provides the details about the interfaces between deployed units of code and target environment services.

Decide on a Type of Interface Configuration and Storage

Decide whether you are creating a data or service interface configuration and whether the configuration will be model-owned or shared.

Goal	Data Interface	In R2022b: Service Interface	Model-Owned with Data Interface	Shared
Code interfacing for application deployment.	X		X
Code interfacing for component deployment	X	X	X
Enable mapping of model elements to storage classes and specific property settings (for example, to support legacy models).	X		X
Customize interface code to include built-in safeguards for maintaining data coherence for outside-execution or during-execution data communication.		X
Customize code for data transfers between functions outside of (before and after) function execution.		X
Support accessing time values in tasks.		X
Enable mapping of model elements to complete interface abstractions.		X
For models of smaller scope or that do not share code interface requirements with other models.			X
Enable multiple models to attach the same shared Embedded Coder Dictionary and use the same code interface configuration defined in that dictionary.				X
Standardize interface code generated from models designed across and organization for a specific target environment.				X
Enable code generation from a model that meets requirements of different target environments.				X

To customize the default model-owned dictionary, on the Embedded Coder app toolstrip, click Code Interface > Embedded Coder Dictionary (Model).

To create a shared Embedded Coder Dictionary, in the Model Explorer, click New > Create Embedded Coder Dictionary or in the Embedded Coder app, click Code Interface > Set up shared Embedded Coder Dictionary.

For more information see Code Interfaces and Code Interface Specification, Code Interface Configurations, Choose Code Interface for Code Generation.

Develop Deployable Code

This figure shows the steps for developing a top model that you intend to deploy as generated code.

Workflow for developing deployable code.

To deploy code from a top model, design your top model by decomposing the algorithm into subcomponents and identify relevant utilities. Choose and implement a modeling style and modeling patterns that align with how you intend to deploy the generated code. Apply relevant modeling guidelines.

When you are ready to generate code, complete this one-time code generation setup. You can optionally use a model template to create a model that is automatically configured according to this setup.

If relevant, attach a shared Embedded Coder Dictionary to the model. This step is required when you are deploying a component that uses a service code interface. This step is not relevant when you are deploying C++ code.
Select an output type for code generation. Depending on the deployment goals for a model, an output type specifies one or a combination of the system target file to apply, programming language of the output, or platform middleware, such as AUTOSAR or DDS. For information about AUTOSAR or DDS, see AUTOSAR Blockset and DDS Blockset.

Check whether the deployment type displayed in the Embedded Coder toolstrip aligns with your expectations. Typically, you can accept default deployment type settings.

Deployment Objective	Deployment Type Setting
C application deployment	`Automatic`. The code generator produces deployable application or component code based on the model contents and configuration. For example,for an export-function model that is configured with a data interface, the code generator produces deployable component code. The code generator automatically configures reference models as subcomponents.
C component deployment	`Component`. The code generator automatically configures reference models as subcomponents.
C++ code generation	Not applicable.

Then, iterate through these steps:

Map model elements to code interfaces. For example, for the C language, available code interfaces are defined in the model Embedded Coder Dictionary. The mappings inform the code generator about appearance, placement, and behavior requirements of the code for model elements.
Use the Model Advisor to check whether the model is ready for code generation. Use the Code Generation Advisor to check and configure a model for code generation application objectives, such as traceability or debugging.
Generate code and confirm that the output meets the code interface requirements.
If necessary, adjust your model design and repeat steps 1 to 3.

Modeling guidelines and tooling facilitate development of top models that you intend to deploy as:

C function source code modules that are integrated with a target environment function scheduler and other target services that run in a single-processing environment.
Standalone executable program that replicates the simulation scheduler and optimizes scheduling code for single-tasking, rate-monotonic multitasking, or concurrent execution, depending on the model configuration. The executable program runs as a single-process or multiprocess application. Code for a single-process application is intended to run on a specific target device.

When deploying a component, you develop each component in isolation. Then, you or someone else in your organization integrates the generated function code into a complete application program at the source code level.

For models that you deploy as components that use a data interface, see the Component Deployment Guidelines for Embedded Coder Support Package, which provides guidelines and tools to help produce code that aligns with these aspects of target platform services:

Interface of generated callable entry-point functions
Interface of calls to platform services
Data communication methods

Design Model

You can design models for code generation where the code generator uses code interface mappings to produce code that aligns with target service requirements.

To start the design work for a deployment project, partition the project as an application or into components. For each application or component identify subcomponents and potential utilities.

High-level code interface requirements of an application or component model can include:

Responses to startup and shutdown events
Scheduling of periodic and aperiodic rates
Communication service interfaces that safely handle access to data, including data that is shared by tasks or threads that execute concurrently
Nonvolatile memory service interfaces
Timer service interfaces
Programming interface customizations for accessing data

The deployment type of a model determines how the model constructs map to interfaces for services provided by the target environment and the rules for peer interaction and scope for data and function accessibility for models in the hierarchy. Each model in the hierarchy gets associated with a deployment type based on the role of the model. For component deployment with a service interface configuration, the code generator sets the deployment type to Component. Otherwise, the code generator sets it to Automatic. In either case, for incremental development, you can change the setting to Subcomponent.

Choose and implement a modeling style and modeling patterns that align with how you intend to deploy the generated code. Apply relevant modeling guidelines. For information on modeling styles, see Periodic and Aperiodic Function Interfaces. For information on modeling guidelines, see Standards, Guidelines, and Block Usage.

The Component Deployment Guidelines for Embedded Coder Support Package provides component modeling guidelines for deployment components that use a data interface. The guidelines help you design component models from which the code generator produces code that can integrate and interface with platform services and other component code that runs on a target platform. The guidelines identify model elements and model element code configurations for execution and other service requirements. When you design and configure a component based on the component modeling guidelines:

The code generator produces a collection of callable entry-point functions that align with target scheduler service calls.
Within the generated function code, calls to target platform service functions align with the target service programming interfaces.
The generated function code honors data communication methods that target platform services use.

For more information, see Architecture and Component Design.

Attach Dictionary

If you choose to use a shared Embedded Coder Dictionary, you must attach the dictionary to your model. When you are deploying a component that uses a service code interface, the code generator requires use of a shared Embedded Coder Dictionary. Embedded Coder Dictionaries are not relevant when you are deploying C++ code.

To attach an Embedded Coder Dictionary to a model, in the Embedded Coder app, click Code Interface > Set up shared Embedded Coder Dictionary. In the dialog box that appears, click Open, browse and select a dictionary (SLDD) file that contains the code interface configuration, and click OK. Alternatively, you can create a coder dictionary and attach it to the model.

For more information about creating and attaching Embedded Coder Dictionaries, see Embedded Coder Dictionary.

Select Output Type

When using the Embedded Coder app, before you generate code for a loaded model, you must select an output type. Available output types are listed in the toolstrip Output menu. For more information, see Code Generation Output.

Check Deployment Types

For C code generation configurations, in the Embedded Coder app toolstrip, the Deployment Type field shows the deployment type of the currently loaded model. Typically, you do not need to adjust the deployment type setting. The code generator sets the deployment type based on the model style and code interface configuration. For models configured with a data interface configuration, the code generator sets the field to Automatic. If you want to generate code for a subcomponent of a model, you can change the setting to Subcomponent.

If the code generator determines that you are deploying a component that uses a service code interface, for models in the component model hierarchy, you can configure the deployment types. By default, the code generator sets the deployment type of the loaded model to Component and models referenced by that model to Subcomponent. For each model in the model hierarchy, you can select a deployment type based on the role of the model.

Role of Model	Deployment Type
Publish code interfaces according to the code interface configuration associated with the model. Code generated from the model can interact with target environment software directly.	Component
Referenced by and runs as part of a parent component model. Execution and communication interfaces are accessible within the context of the parent model only. Generated code is not accessible to target environment software.	Subcomponent

To review or set the deployment types for models throughout the model hierarchy, from the Deployment Type menu, select Set Up Deployment Type for Model Hierarchy. For more information, see Configure C Code Deployment Types for Model Hierarchy.

Map Model Elements to Code Interfaces

In the Embedded Coder app, use the Code Mappings editor to map model interface elements to code interface elements. Alternatively, you can use the code mappings programming interface. The code interface elements to which you can map model elements depend on the type of code interface configuration that is associated with the model (data or service). For C code generation, available code interface elements are defined in an Embedded Coder Dictionary that is associated with the model.

For more information, see:

Assess Code Generation Readiness

Verify that your model is ready for code generation by using the Model Advisor and Code Generation Advisor. The Model Advisor checks to assess readiness to generate code. General Embedded Coder checks and checks for component deployment of models configured with a service interface configuration are available in Simulink Check™. Checks for component deployment of models configured with a data interface configuration are available as part of the Component Deployment Guidelines for Embedded Coder Support Package.

The Code Generation Advisor checks your model for code generation application objectives such as traceability or debugging.

For information about using Model Advisor, see:

For information about using the Code Generation Advisor, see Configure Model for Code Generation Objectives by Using Code Generation Advisor.

Generate and Verify Code

You have different options for generating code depending on whether you are generating code for an application or component model. For an application model, by default, the code generator produces source code for algorithms represented in your model and a main function that handles function scheduling. Then, the code generator compiles and links the generated code into an executable program. Alternatively, you can generate source code and suppress compiling and linking by selecting model configuration parameter Generate code only and customizing the process for producing an executable program.

For a component model, you can generate source code and suppress compilation and linking or you can generate a component model library. The code generator produces build artifacts, including a header file services.h, in folder codeGenerationFolder/modelBuildFolder/services, and a MAT-file buildInfo.mat, in folder codeGenerationFolder/modelBuildFolder/services/lib. The services.h file, which you can rename in the Embedded Coder Dictionary, specifies function prototypes for target platform services. The buildInfo.mat file stores an RTW.BuildInfo object that contains information for compiling the generated code and producing a library. By default, the code generator produces source code and does not perform compilation and linking. To generate a library, clear model configuration parameter Generate code only. If you configure a component model for library generation or to run as a software-in-the-loop (SIL) or processor -in-the-loop (PIL) simulation, the code generator builds a component model library according to the model toolchain configuration. SIL or PIL simulations verify the code that the library contains.

When you generate source code without compiling and linking, you can build an executable program for an application or a component model library outside of the MATLAB^® environment by using a CMake workflow. You can create a:

CMake configuration (CMakeLists.txt) file by using the codebuild function
ZIP file for transferring files to another development environment by setting model configuration parameter Package code and artifacts and using the packNGo function

For an example, see Deploy Component Algorithm as Component Model Library by Using CMake.

To verify whether the generated code aligns with code interface requirements, use the code view pane in the coder app and the generated Code Interface Report. Several other tools are available for other types of verification, such as profiling code execution, testing for numeric equivalence between simulations and code execution, and checking for unintended functionality.

To explore verification of code generated from component models, you can use the test harness example models provided in Deploy Export-Function Component Configured for C Service Interface Code Generation and Deploy Single-Rate, Rate-Based Component Configured for C Service Interface Code Generation.

For more information, see:

Deploy Generated Code

After you generate and verify code, deploy it. How you deploy the generated code depends on whether you are deploying an application or component.

Deployment Type	Deployment Goals
Application	Run generated executable program in the target environment as a standalone application. Integrate generated executable program to run with other code in the target environment. Customize generated source code to integrate with other code that runs in the target environment. In this case, you might use the generated example `main` as a starting point for developing a custom `main` program.
Component	Integrate generated component source code or component model library with other code that runs in the target environment.

Application Deployment Workflow Options

For application deployment, by default, the code generator compiles and links generated source code into an executable program that you can download to a target execution environment to run. If you choose to configure the code generator to produce source code without compiling and linking, you can:

Customize or replace the generated main function. You must take care to align the code interfaces with the interfaces generated for the model algorithm code.
Produce an executable program by using the codebuild command to compile and link the generated code.

See Manage Build Process Folders, Approaches for Building Code Generated from Simulink Models, and Compile Code in Another Development Environment.

Component Deployment Workflow Options

For component deployment, you have multiple workflow options. In each case, you must integrate your generated code with an external main program that handles function scheduling.

You can:

Integrate generated source code with an external main function and other target environment source code and build an executable program.
Link a generated component model library with an external main function and other target environment code to create an executable program.
Use the codebuild command to build a component model library from generated source code. Then, within or outside of the MATLAB environment, link the library with an external main function and other target environment code to create an executable program.

See Manage Build Process Folders, Configure CMake Build Process, Approaches for Building Code Generated from Simulink Models, and Compile Code in Another Development Environment.

Integrate Generated Component Code with Target Environment Code

For an embedded system, the main function:

Defines function interfaces (function prototypes).
Includes files that declare external data.
Defines extern data.
Initializes data.
Uses simulated or actual hardware.
Calls algorithmic functions.

To integrate generated component code with a main function and other target environment code, you must:

Match the data and function interfaces of the generated code with other interfaces of existing system code.
Connect input data.
Connect output data.
Access other data, such as block state values, local parameters, and time.

Design and configure the component model such that generated code aligns with the code interfaces of the target environment. For example, if your target environment software defines a global variable for storing output data and the generated code reads that data as input, you can configure the corresponding inport so that the generated code interacts with the existing variable. The target environment software that calls the entry-point functions must provide input signal data and, depending on your application, scheduling information. Also, suppose that the generated algorithm calculates output data that the calling environment can use. The target environment software and the algorithm can exchange this data by using global variables or formal parameters (arguments). The set of input and output data and data access mechanisms constitute the interfaces of the entry-point functions.

When you understand the code interfaces and how to control them, you can:

Generate code that can be called by other component code and target services.
Write code that calls the generated code.
Generate reusable (reentrant) code that you can call multiple times in a single application.
Integrate the generated code with other, external code in your application.

In a model, root-level inports and outports represent the primary inputs and outputs of the component algorithm. By default, the code generator aggregates this input and output data into standard structures.

For examples, see Configure Generated Code According to Interface Control Document Specifications and Integrate External Application Code with Code Generated from PID Controller.

For more information, see Deployment, Integration, and Supported Hardware.

Review Generated Interface Code

Confirm that the code generator produces expected interface code by reviewing the Code Interface Report. The report describes the generated code interface, including interface information for:

Each component model entry-point function (function name, prototype, timing information, arguments, return value, and header file)
Each model root-level inport and root-level outport (block name, code identifier, data type, scaling information, and dimensions)
Tunable parameters that are associated with the model (data store source, code identifier, data type, scaling information, and dimensions)
Global data stores and data stores with non-Auto storage that are associated with the model

For models configured for component deployment with service interfaces, the report includes information for:

Each periodic and aperiodic callable entry-point function (prototype, header file, simulation rate, and service call prototypes)
Initialize and terminate callable entry-point functions (prototype and header file)
Each type of service (function prototypes, data communication method, function names, data types, dimensions, and header file)

Configure the code generator to produce a Code Interface Report as part of the generated HTML report.

For more information about the report, see Analyze Generated Data Code Interface Report.

Get Meta Information About Generated Code

By default, the code generator creates a code descriptor file (codedescriptor.dmr) in the build folder. That file contains meta information about the generated code, including:

Data interfaces (inports, outports, parameters, data stores, and internal data)
Function interfaces (initialize, output, update, and terminate)
Execution information for the data and function interfaces, such as timing requirements
Model hierarchy information and information for referenced models

You can use the code descriptor programming interface to get access to the contents of the code descriptor file and use the results to confirm that generated interfaces meet integration requirements. You can also use the programming interface to provide input to tools that generate interfaces for target platform services.

For more information, see Get Code Description of Generated Code and coder.codedescriptor.CodeDescriptor class.

Identify and Package Files for Deployment

For component deployment, after you review and, if necessary, refine the code interfaces generated for a model, identify files required to build the integrated code. You can generate code for a component model and compile a component model library for deployment by clearing model configuration parameter Generate code only and initiating a model build. If code for the component model is already generated, you can build a component model library by using the codebuild command with the path codeGenerationFolder/modelBuildFolder/services/lib. You can link the generated component model library with a main function and other target environment code to create an executable program.

When you generate source code without compiling and linking, you can build a component model library outside of the MATLAB environment by using a CMake workflow. You can create a:

CMake configuration (CMakeLists.txt) file by using the codebuild function. See Configure CMake Build Process.
ZIP file by setting model configuration parameter Package code and artifacts and using the packNGo function. The packNGo utility finds and packages files that you need to build an executable image. Then, you can relocate the ZIP file to another development environment, such as a dedicated application build system. See Relocate or Share Generated Code.

Build Integrated Code Into Executable Program

Embedded Coder provides extensive capabilities for customizing the build process. For example:

Choose between a CMake, toolchain, or template makefile approach. See Approaches for Building Code Generated from Simulink Models.
Compile a component model library that you can link with a main function and other target environment code to create an executable program. See Deploy Component Algorithm as Component Model Library by Using CMake.
Control compiler optimizations. See Control Compiler Optimizations.
Reduce build time by building referenced models in parallel. See Reduce Build Time for Referenced Models by Using Parallel Builds.
Customize build processing that occurs after code generation to include third-party tools. See Customize Post-Code-Generation Build Processing.
Compile code in another development environment. See Compile Code in Another Development Environment.