Software Deployment Concepts
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
Programming interface customizations for accessing data
For more information about developing component models for deployment, see:
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.
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|
|Application algorithm 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.
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)
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.
Embedded system applications typically interact with middleware that consists of these services.
|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.
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|
||Communicates with other functions directly by using memory that the platform manages.|
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.
The arrows indicate the direction of function interface calls. The platform function
scheduler calls component entry-point functions:
component calls platform services to read input, write output, transfer data between
callable functions, and get time values.