Main Content

Component Deployment

Simulink® provides capabilities for designing and deploying component models as generated code that behaves in a target platform environment the same way as the model during simulation. This figure shows the steps required for component deployment by using Simulink and Embedded Coder®.

Component model deployment

Identify requirementsAssess project requirements and identify the platform type for your deployment.
Create code interface definitionsCreate a specification that informs the code generator about interface code requirements for the target platform environment.
Develop component model Design a component model, associate the model with a platform definition, and generate and verify component code.
Deploy generated code

Deploy generated source code modules for integration with external application and platform source code.

Deploy generated source code modules or executable programs.

Deploy generated executable programs to run as standalone executable programs in a single-process environment or for integration with other applications in a multiprocessing environment.

Identify Requirements

Identify the requirements for your project. The requirements help you identify the type of platform deployment. Embedded Coder provides tools to deploy component models as generated code for function platform deployment or application platform deployment. The first consideration is which type of platform deployment meets scheduling and other needs of your project.

This figure shows a primary difference between the two types of platform deployment. Function platform deployment requires integration of generated function code with an external scheduler and other platform software. When you generate code for application platform deployment, the resulting code includes a built-in scheduler and can be built into a deployable executable program.

Comparison of platform types

Code that you generate for an application platform can run on a single-process or multiprocess architecture as part of a real-time or non-real-time application. 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.

This table lists requirements and conditions that apply to each platform type. Use the information in the table to identify the platform that best aligns with your application requirements.

Requirements and ConditionsPlatform Type
  • You generate C source code.

  • You deploy the C source code module generated for a component model.

  • You hand off the generated component code for integration with an external platform scheduler and other platform services.

  • The integrated code runs on a single-process architecture.

  • You generate C or C++ source code.

  • You deploy a generated executable program to run on a single- or multiprocess architecture as part of a real-time or non-real-time application.

  • The generated code for a model replicates the simulation scheduler and optimizes the scheduling code for single-tasking, rate-monotonic multitasking, or concurrent execution, depending on the model configuration.

  • For single-process architectures, the generated code is optimized for a specific target device.

  • You are deploying code to a single-process architecture for rapid prototyping, hardware-in-the-loop (HIL) simulation, or production code that runs as a complete, hard real-time application.

  • You are deploying code to a multiprocess architecture for an application that requires high throughput or distributed execution.


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

Create C Code Interface Definitions

For C code generation, code interface definitions inform the code generator about requirements for the appearance, placement, and behavior of component interface code. To generate component interface code that aligns with specific target platform requirements, you or someone in your organization must define a platform definition. Embedded Coder provides predefined platform definitions for generating application executable programs, which include scheduling support, and shared libraries. You can create definitions for function and application platforms.

After researching code interface requirements, you create code interface definitions by using the Embedded Coder Dictionary. Types of code definitions that you should create depends on your project requirements and deployment goal. You can create these types of definitions:

  • Memory sections

  • Storage classes

  • Function customization templates

The code generator uses the code definitions as a specification for producing interfaces that appear in the generated C code as:

  • Entry-point function prototypes for periodic or aperiodic execution functions

  • Entry-point function prototypes for initialize, reset, and terminate functions

  • Variable assignments

  • Get and set data access functions

For information about using the Embedded Coder Dictionary and Custom Storage Class Designer, see Code Interface Definitions.

Research for Code Interface Requirements

Research the required component interactions with your target platform. Identify sources of input and required output. Determine what the code for interfacing with other platform resources must look like and how it must behave. For example, does your model or generated code need to exchange data with platform software? If so, map inputs, outputs, and parameters to the external function interface. Typical function interfaces involve function arguments and return values, global variables, and access functions.

This list of questions can help you identify interface requirements that are relevant to component deployment.

  • What platform software will the component interact with? For example, does the platform software include an operating system? What platform middleware services are available?

  • Does the platform expect the component to handle startup or shutdown events?

  • Does the platform have naming requirements for entry-point functions that it calls to initiate component execution?

  • What are the names of the service functions that a component needs to call to use platform services?

  • What methods (semantics) do platform services use for handling concurrent access to data when communicating with components?

  • Does the platform expect component input and output 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 platform software use company-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.

  • Does the component need to exchange data by using shared memory? If yes, define and use memory sections.

  • Does the platform require that component code optimize memory usage when sending data?

  • Does the platform require access to variables that represent component parameters or signal data for tuning or measurement purposes? If so, how does the platform expect the data to be represented in component code? Does the data need to reside in a specific header file?

  • Does the platform architecture support single-processing only or multiprocessing as well?

  • Does the platform application code consist of multiple component source code modules developed independently and integrated manually with a platform function scheduler? Or, is the platform application code a generated executable program that runs a standalone executable program on the platform 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 application components and between application components and platform services.

Options for Code Definition Storage

Code interface definitions for a component model can reside within a model (model-owned) or in a Simulink data dictionary (standalone).

Comparison of model-owned and standalone code interface definitions

Model-Owned Code Interface Definitions

By default, Simulink associates a component model with model-owned code interface definitions. Model-owned code interface definitions apply to the owner component model only. You can customize these definitions. Use model-owned code interface definitions for models of smaller scope and that do not share interface requirements with other component models. To customize the default model-owned coder dictionary, on the Embedded Coder app toolstrip, click Code Interface > Embedded Coder Dictionary.

Standalone Code Interface Definitions

Standalone code interface definitions:

  • Reside within a Simulink data dictionary.

  • Are independent of the component. The model and dictionary that contains the definitions are separate entities.

  • Can be associated with multiple component models.

The separation of the model and code interface definitions enables you to:

  • Standardize code generated from models designed across your organization for a specific target platform.

  • Generate code that meets requirements of different target platforms from a model.

Because the dictionary that contains code interface definitions and the model are separate entities, the dictionary must be linked to the model. Depending on how you create the dictionary, the link might be set up automatically (see Deploy Code Generation Definitions). Once a component model is associated code interface definitions, you can map model interface elements to storage classes and function customization templates.

To create standalone code interface definitions, in the Model Explorer, click New > Create Embedded Coder Dictionary or in the Configuration Parameters dialog box, click the New button to the right of the External coder dictionary parameter.

Code Interface Definitions for Data Objects

To create code definitions for data objects that you store in the base workspace or in a Simulink data dictionary, use the Custom Storage Class designer to create a definition in a package. For these data objects, you apply code generation settings to the data object instead of applying them in the mapping of a model. When an item in a model uses the data object and its code generation settings, the code mapping for the item reflects the specification of the data object.

If you want to use the same code generation definition in model code mappings and in data objects, you do not need to store one copy of the definition in an Embedded Coder Dictionary and another copy in a package. Instead, store the definition in a package (by using the Custom Storage Class Designer). Then, configure one or more Embedded Coder Dictionaries to refer to the definition in the package. When you want to make changes to the definition, you make the changes in only one place, the package.

Develop Component Model

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

Workflow for developing a component model

To develop a component model for deployment, iterate through these steps until the generated code meets interface requirements.

Design modelDecompose 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 component code. Apply relevant component modeling guidelines.
Select output typeSelect 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.
Configure model deployment typesSpecify a deployment type (component or subcomponent) for each model in your component model hierarchy. Often, you can accept default deployment type settings.
Map model elements to code interface definitionsMap model elements to interface definitions that correspond to the selected output type. For example, for the C language, available interface definitions are defined in the Embedded Coder Dictionary associated with the model. The mappings serve as an interface configuration, informing the code generator about appearance, placement, and behavior requirements of the code for model elements.
Assess code generation readinessUse the Model Advisor to check whether the component 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 and verify codeGenerate code and confirm that the output meets the interface requirements.

Component modeling guidelines and tooling facilitate development of component models that you intend to deploy as:

  • C function source code modules that are integrated with a platform function scheduler and other platform 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 model to a function platform, you develop each component model 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 function platform deployments, the Component Deployment Guidelines for Embedded Coder Support Package provides guidelines and tools to help produce code that aligns with these aspects of the platform services:

  • Interface of generated callable entry-point functions

  • Interface of calls to service interface functions

  • 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 a target platform environment.

To start the design work for a component deployment project, partition the project into components and subcomponents. Also identify potential utilities.

Deployment TypeDescription
ComponentTop-level model that represents an application algorithm. The composition of a component can include subcomponents, such as reference models and subsystems that interact within the context of the parent component model. A component can be part of a system composition. From a component, the code generator can produce code that interacts with other platform environment software. The code generator produces component model code that you can deploy to run on an embedded system platform or integrate as part of an embedded system platform.
SubcomponentPart of an algorithm that is captured within a component model and runs as part of the model. You model a subcomponent as a reference model, subsystem, or linked subsystem. The parent component gains access to subcomponent code by using subcomponent entry points. Code generated for subcomponents is not accessible to the target platform environment. The code generated for a subcomponent is dependent on code for the parent component model. If a subcomponent uses shared data and runs in multiple execution contexts, the subcomponent code must use data transfer services prescribed by the target platform.

Reusable function that a program can call from a location in the code without knowing the target platform environment. You model a utility as a library subsystem that adheres to specific modeling constraints. The code generator uses the constraints to produce code that is free of platform context requirements. Include utilities in model compositions when you want to:

  • Generate code for a set of reusable components that models can share

  • Lock down the interface for a subsystem

  • Make a model the owner of its generated code

Simulation only componentA model, such as a plant model or test harness, used to simulate component models.

High-level requirements of a component model can include:

  • Startup and shutdown events

  • Periodic and aperiodic sample rates

  • Communication services that safely handle access to data, including data that is shared by tasks or threads that execute concurrently

  • Nonvolatile memory services

  • Time and delta time services

  • Programming interface customizations for accessing data

The deployment type of a model determines how the model constructs map to platform interfaces and the rules for peer interaction and scope for data and function accessibility for models in the hierarchy. For each model in the hierarchy, you select a deployment type based on the role of the model.

Choose and implement a modeling style and modeling patterns that align with how you intend to deploy the generated component code. Apply relevant component modeling guidelines. The Component Modeling Guidelines for Embedded Coder Support Package provides component modeling guidelines for function platform deployment. The guidelines help you design component models from which the code generator produces code that can integrate and interface with middleware and other component code that runs on your target platform. The guidelines identify model elements and model element code configurations for target platform execution, communication, 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 platform scheduler service calls.

  • Within the generated function code, calls to platform service functions align with the service programming interfaces.

  • The generated function code honors data communication methods that platform services use.

For more information, see Architecture and Component Design.

Select Output Type

When using the coder app, before you generate code for the loaded component model, you must select an output type. Available output types are listed in the toolstrip Output menu. For more information, see Select Output Type.

Configure Model Deployment Types

A model deployment type determines rules for peer interaction and scope for data and function accessibility for models in the model hierarchy. For each model in the hierarchy, you select a deployment type based on the role of the model.

Role of ModelDeployment Type
Publish execution, communication, and service code interfaces according to the specified output type so the component can interact with other components in the target platform environment.Component
Referenced by and runs as part of the parent component model. Execution and communication interfaces are accessible within the context of the parent component model only. Generated code is not accessible to the target platform environment.Subcomponent

In the Embedded Coder app toolstrip, the Deployment Type field shows the deployment type of the currently loaded model. You can use that field to change the deployment type. 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 Deployment Types for Model Hierarchy.

Map Model Elements to Code Interface Definitions

After you associate a component model with a platform definition, you can map model interface elements to storage classes and function customization templates by using the Code Mappings editor or code mappings programming interface. See:

Assess Code Generation Readiness

Verify that your component 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 are available in Embedded Coder and checks for function platform deployment are available as part of the Component Deployment Guidelines for Embedded Coder Support Package.

The Code Generation Advisor checks and configures 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

Generate code. To verify whether the 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.

For more information, see:

Deploy and Integrate Generated Code

After you generate and verify code, deploy it. The steps involved with deploying generated code depends on whether you are deploying to a function or application platform.

Platform TypeDeployment Goals
FunctionIntegrate generated source code module with other code that runs on the platform.
  • Run generated executable program on the platform as a standalone application.

  • Integrate generated executable program to run with other application code on the platform.

  • Customize generated source code to integrate with other application code that runs on the platform. In this case, you might use the generated example main as a starting point for developing a custom main program.

For an application platform, by default, the code generator produces an example application main function that you can customize. For function platform deployment, you must integrate your generated code with an external main program. You might choose to do the same for source code that you generated for an application platform. For an embedded system, the main function:

  • Defines function interfaces (function prototypes).

  • Includes files that declare external data.

  • Defines extern data.

  • Initializes data.

  • Calls simulated or actual hardware.

  • Calls algorithmic functions.

Integrate Generated Component Code with Platform Code

To integrate generated component code with a main function and other platform and application 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 sate values, local parameters, and time.

Design and configure the component model such that generated code aligns with the code interfaces of the target platform code. For example, if your platform code 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 platform environment that calls the entry-point functions must provide input signal data and, depending on your application, scheduling information. The generated algorithm calculates output data that the calling environment can use. The platform environment and the algorithm can exchange this data by using global variables or formal parameters (arguments). The set of input and output data and the 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 platform 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

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 the Generated Code Interface.

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 platform services.

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

Identify and Package Files for Deployment

For function platform deployment, after you review and, if necessary, refine the code interfaces generated for a component model, identify files required to build the integrated code. If you use an application build system outside of the Simulink environment, you can package the generated files and required support files that MathWorks® provides into a zip file by using the packNGo utility. That utility finds and packages the 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.

For more information about the packNGo, see Relocate or Share Generated Code and packNGo.

Build integrate Code Into an Executable Program

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

Related Topics