Software Deployment Concepts

Component Models

A component model is a top-level model that represents an application algorithm. From a component model, the code generator produces code that has a well-defined programming interface for interacting with other platform environment software. Embedded Coder^® software produces component model code that you can deploy to run on or integrate as part of an embedded system platform.

A component model:

Is a construct that you can design and configure such that the code generated for the component aligns with platform requirements.
Publishes its interface to interact with other platform environment software.
Can include subcomponents, such as reference models and subsystems, that interact within the context of the parent component model.
Can be part of a system composition.

High-level requirements of component models can include:

Startup and shutdown events
Periodic and aperiodic execution
Communication services that safely handle access to data, including data that is shared by tasks or threads that execute concurrently
Nonvolatile memory service
Timer services
Programming interface customizations for accessing data

For more information about developing component models for deployment, see:

Platforms

A platform is the environment consisting of the device and software on which your deployed software runs. As this figure shows, the software might include a real-time operating system (RTOS), middleware, and other component code.

Platform parts

Target platforms for embedded system applications vary in complexity. A platform consists of a combination of the parts listed in this table.

Parts of Platform Environment	Examples
Device	Development computer Rapid-prototyping board Microprocessor Microcontroller FPGA ASIC
Processor cores	Single Multiple
Processing	Single Multiple
Operating system	General-purpose operating system Real-time operating system (RTOS) None (bare metal)
Scheduling	Periodic, single-tasking Periodic, multitasking Asynchronous Initialize, reset, terminate
Middleware	Scheduling support Communication Data management Authentication Other services or capabilities not offered by operating system
Application algorithm code	Generated from a model External code

To ensure an optimized and accurate model design and to accurately configure the model for code generation, you or someone else contributing to your project must identify the parts, characteristics, and requirements for your application to interface with the target platform.

Platform Specifications

A platform specification informs the code generator about platform requirements, such as:

How to name function entry points (callable functions)
Names of service functions that your application can call
Data communication methods, which define an interface contract between platform services and generated code

You make the code generator aware of the platform requirements by using a combination of:

Modeling elements in your component model
Code interface definitions (storage classes and function customization templates) in an Embedded Coder Dictionary
Code interface configurations in your component model code mappings

This figure shows the relationship between:

Platform requirements (the input to the component deployment process)
Platform specification (how you use Simulink^® and Embedded Coder tooling to communicate the platform requirements to the code generator)
Platform integration and execution (what you do with the code generator output)

Relationship between platform requirements, platform specifications, and platform integration and execution

Platform Middleware

Platform middleware is a collection of services that supplements tasks performed by an operating system to support the execution of applications. For example, a platform schedules generated application code by using scheduling and data transfer services.

If you design and configure a component model according to recommended guidelines, the code generator produces code that aligns with integration requirements of a specific platform. To generate and deploy such code, you must consider platform middleware requirements as you design the component model and define and configure code interfaces.

The middleware of a platform can consist of these types of services:

Scheduling and task execution services
Communication services, including support for device driver, send-receive, client-server, and message-trigger communication
Optional services, such as timer, data transfer, nonvolatile memory, parameter tuning, and measurement services

This figure shows layers of platform middleware services for a platform.

Layers of platform middleware

Embedded system applications typically interact with middleware that consists of these services.

Service	Description
Scheduling	Selects a task to execute based on a sample time (period/offset) or an event and execution order. Goals of the service include maximizing throughput, minimizing wait time, minimizing latency, maximizing fairness, and meeting deadlines.
Data receive	Receives input data from another component or from nonvolatile memory.
Data send	Sends output data to other components or to nonvolatile memory.
Data transfer	Handles sharing of data between callable functions. The service takes complete ownership of this data including the setting of initial values.
Nonvolatile memory	Reads data from and writes data to nonvolatile memory.
Timer	Implements aspects of time, such as timer resolution, absolute time, and elapsed time (function step size).
Parameter tuning	Enables access to and the ability to change parameter values while an application executes.
Measurement	Enables access to and the ability tp read signal data while an application executes.

To interact with a service, a component model must include specific model elements that represent an interface to the service. In some cases, you might also need to configure the model elements in a specific way. For example, you can represent the interface for data receive service by using a root-level inport that is configured with a storage class.

The modeling guidelines that are provided in the Component Deployment Guidelines for Embedded Coder Support Package describe how to represent interfaces for the different services in component models intended for function platform deployment.

Platform Service Data Communication Methods

When designing a component model, for some platform services, you must consider data communication methods that the platform services use. Data communication methods are direct-access, outside-execution, and during-execution. These methods coordinate the communication of data for tasks, including concurrent access to data. The direct-access method specifies that a component accesses data directly from memory provided by the platform services. This figure shows differences between the outside-execution and during-execution communication methods.

Comparison of outside-execution and during-execution communication methods

For each data communication method, this table describes the platform service behavior and the expected corresponding behavior of generated code that uses a service that applies the data communication method.

Data Communication Method	Platform Service Behavior	Generated Code Behavior
Direct access	Provides generated functions that have direct access to data that is stored in platform memory. Memory is persistent for the duration of a power cycle. Assumes that generated functions do not access a memory buffer concurrently. Does not apply data concurrency safeguards. Maximizes performance.	Communicates with other functions directly by using memory that the platform manages.
Outside execution	Applies data concurrency safeguards. Communicates data to other functions outside (before and after) function execution. Favors memory optimizations over data freshness.	Communicates with other functions indirectly. Interacts with memory provided by the platform.
During execution	Applies data concurrency safeguards. Communicates data to other functions immediately during function execution. Favors data freshness over memory usage.	Communicates with other functions indirectly. Interacts with platform services by using its local memory.

Design your component model and configure model data elements based on the data communication methods that the platform services apply.

Component Platform Interfaces

Design a component model such that the code generator produces code that is prepared to integrate and interface with middleware and other component code that runs on your target platform. For example, for function platform deployment, modeling guidelines provided in the Component Deployment Guidelines for Embedded Coder Support Package identify model elements and model element configurations for target platform execution, communication, and other service requirements. When you design and configure a component based on the 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.

This figure shows the interaction between a component and platform services in a platform execution environment.

Component platform interfaces

The arrows indicate the direction of function interface calls. The platform function scheduler calls component entry-point functions: Initialize, F1, F2, and Terminate. The component calls platform services to read input, write output, transfer data between callable functions, and get time values.