Main Content

Software Component Modeling

Software modeling refers to modeling, simulating, and generating code for algorithms that run in software frameworks. Simulink® provides a range of modeling abstractions, semantics, and configuration capabilities that help you create algorithm models that leverage the scheduling, communication, time, memory, diagnostic, and multicore support for these frameworks. For example, when designing a model, you can:

  • Partition the design for run-time scheduling.

  • Design software component data interfaces.

  • Represent run-time services such as diagnostic and memory services.

  • Configure the model for concurrent execution on multicore systems.

  • Create test harnesses and simulate model compositions.

  • Integrate with standard middleware software, such as AUTOSAR and DDS.

  • Represent complex power-cycle and mode-transition logic.

By using model reference, variant, and data management capabilities, you can design software components for reuse within an application and across software frameworks.

When you use Simulink with Simulink code generation and verification and testing products, you can specify, elaborate, test, and validate software components. You can:

  • Model your system in Simulink.

  • Simulate the system behavior in a run-time environment.

  • Use Simulink Coder™ or Embedded Coder® to generate code from your algorithm model for rapid prototyping or production, respectively.

  • Call generated entry-point functions for initiating run-time execution and controlling initialization, resets, and shutdowns.

  • Use code-sharing capabilities to deploy and integrate generated function-level source code, shared libraries, and application executable programs.

See Modeling Guidelines for application-specific guidelines for model architecture, design, and configuration.

Create Models of Software Components

When you design the functionality of each component in the composition, it is useful to distinguish between the algorithms that are internal to the component and the interaction of the component with the run-time environment. The algorithm of each software component can be implemented in a Simulink model, which is referenced as a Model block in the composition in Simulink or as a software component in the composition in System Composer™. The model can be used in multiple instances in your design and used for both simulation and code generation.

Within a model representing software component, you can further componentize your design. See Component-Based Modeling Guidelines. In your componentization, you can use subsystems to establish a hierarchical block diagram and to keep functionally related blocks together. For more information about subsystems, see Create Subsystems. You can also use model references to define a set of blocks once and use it repeatedly. Using model references instead of subsystems offers several advantages. For example, model references allow you to do modular development, during which you can develop a referenced model independently from the models that use it. Using model references also allows model protection, using multiple references of the same model, incremental Simulink loading and code generation. For more information, see Model Reference Basics.

Three Model blocks display the name of the referenced model (sldemo_mdlref_counter) on their block icons.

You can create your own custom library of blocks using the instances of blocks from built-in Simulink libraries or from the blocks or components you create. You can create custom blocks using legacy code or other custom code. See Extend Modeling Functionality with Custom Blocks. Using custom libraries is helpful for providing frequently used and seldom changed modeling utilities and for reusing components in a model or in multiple models. To learn more, see Create Custom Library.

Simulink Library Browser window showing contents of "My Library".

To schedule and control the execution of your software component models, you can design each model as either an export-function model or a rate-based model. An export-function model can generate code for independent functions that can be integrated with an external environment and scheduler. See Export-Function Models Overview. With a rate-based model, Simulink schedules function execution based on sample times. Export-function models provide flexible entry points and customization support, which makes them useful for generating production code. For more information, see Create an Export-Function Model and Create A Rate-Based Model.

Function-Call Subsystem block connected to ports.Model block with periodic event and other ports.

When you design the interfaces of your components, an Inport block used in a component represents inputs to the component. A signal or a message arriving at an input port on a component flows out of the associated Inport block in that component. Similarly, an Outport block is used to represent the output.

Simulink model of a mechanical system, and same blocks brought inside a subsystem.

Buses are composite signals that contain elements that retain their separate identities, which allows you to extract them from the composite signal. For models that include buses composed of many bus elements, consider using In Bus Element and Out Bus Element blocks. You can customize data interfaces to your components by defining and using custom bus types. See Create Nonvirtual Buses.

Simulink model with multiple output signals being formed into a bus signal.

You can configure your components to call services, such as memory and input/output services, from other components or from the run-time environment, as in a distributed service architecture. Use Function Caller blocks together with function ports for this purpose. See Call Simulink Functions in Other Models Using Function Ports.

You configure your components to run as concurrent systems on multicore processor and multiprocessor systems when they are deployed. This configuration can improve performance or enhance scalability of an embedded system. See Concepts in Multicore Programming and Multicore Programming with Simulink.

To represent an area of RAM used by a component model, you can use a data store. A data store is a repository from which you can read and to which you can write data without connecting input or output signals to the store, analogous to a global variable in a program. Use Data Store Read and Data Store Write blocks to access data stores. See Model Global Data by Creating Data Stores and Determine Where to Store Variables and Objects for Simulink Models.

Simulink canvas with Data Store Memory block and Data Store Read and Write blocks connected to other blocks in model.

Create Model of Run-Time Environment

Once you create models of your software components, you can test your design by creating a model to emulate or mock the run-time environment in which the components will be deployed.

Use messages to model communication between Simulink components for the purpose of system integration.

You can use message-based communication instead of signals for component communication when modeling systems in which centralized architectures are replaced with distributed architectures. A message is a useful modeling artifact that combines events with related data. You can send and receive messages from the root input and output ports of a model and generate C/C++ code to connect to a middleware or an operating system communication programming interface.

For more information, see Simulink Messages Overview.

Simulink model with message Inport and Outport blocks. Outside model, a bar labeled "Middleware" is connected by arrows to the Inport and Outport blocks.

Use Simulink functions to represent callable services such as input and output, memory, diagnostics, and hardware peripherals. See Simulink Functions Overview.

Simulink Function block connected to Inport and Outport blocks.

To schedule the execution of your software components, you can use the Schedule Editor, a Stateflow® chart, or other scheduling blocks such as Function-Call Generator. See Test Export-Function Model Simulation Using Function-Call Generators, Test Export-Function Model Simulation Using Stateflow Chart, and Test Export-Function Model Simulation Using Schedule Editor. For rate-based models, you can use the Simulink built-in scheduler, which schedules tasks based on sample time. For export-function models, you need to schedule execution with explicit calls. See Create Partitions.

If you have both export-function and rate-based components, you can use period function-call event ports for the rate-based components. You can also schedule them with the Schedule Editor.

You can use event functions to implement startup, shutdown, and mode transition behavior of your system. See Using Initialize, Reinitialize, Reset, and Terminate Functions.

Test System by Simulating Composition Model

Once you have built a model of the run-time environment around your software components, you can simulate the model to test and refine your design.

You can observe how the system behaves during simulation and view and analyze any resulting data using the Simulation Data Inspector. See Investigate Signal Values. You can also use the Sequence Viewer to visualize the flow of messages and function calls.

You can experiment with different parameter values or variant configurations as you test your system. See Tune and Experiment with Block Parameter Values and What Are Variants and When to Use Them.

If you have a Simulink Test™ license, you can automatically create a test harness model to test your system.

Integrate Components into Software Architectures

Once you create models in Simulink to represent your software components, you can integrate the components into a software architecture model in System Composer. Add software components to your software architecture model, then link the Simulink models to those components. You can use both export-function and rate-based models. Define and create interfaces between components to build the composition. You can then use System Composer to view, analyze, and simulate the composition to help you further refine your design. See Author Software Architectures (System Composer).

Software architecture with a component linked to an Export-Function model.

Design Software Architectures

Before you design the software components themselves, designing the overall architecture of the system in which the components operate can be useful. You can model the high-level behavior of your system by creating a software architecture model in System Composer. See Design Software Architectures (System Composer).

Using System Composer, you can define component interfaces, author functions for your components, analyze your design, and simulate the composition before fully implementing the functionality of your components. See Author and Extend Functions for Software Architectures (System Composer).

System Composer canvas with software architecture model comprising 4 components, each with multiple ports and connnections.

Generate Code for Software Components

When you are ready to generate code for the software component, use Embedded Coder to prepare the model for code generation and generate C code. The code that you generate from a model includes entry-point functions, which are called from application code. These functions include an initialization function, an execution function, and, optionally, terminate and reset functions. The functions exchange data with your application code through a data interface that you control. To customize the data interface of the generated code, use the Embedded Coder Dictionary and Code Mappings editor. To test generated code, you can run software-in-the-loop (SIL) and processor-in-the-loop (PIL) simulations. A SIL simulation compiles and runs the generated code on your development computer. A PIL simulation cross-compiles source code on your development computer. The PIL simulation then downloads and runs the object code on a target processor or an equivalent instruction set simulator.

To get started, see Generate Code by Using the Quick Start Tool (Embedded Coder) and Component Deployment Guidelines for Embedded Coder Support Package.