Software Component Models in Simulink

R2026b

Software component models enable you to represent software as an element of a system in Simulink^®, with explicitly defined boundaries, interfaces, and run-time behaviors. Unlike traditional Simulink models, which focus primarily on algorithm behavior and signal flow, software component models also describe how components interact and execute at run time.

When you configure a Simulink model as a software component, the model establishes an explicit component boundary that separates:

• Algorithmic behavior, implemented using Simulink blocks inside the component

• Communication and execution behavior, defined using interfaces and quality of service (QoS) properties

This separation enables you to focus on algorithm design while defining interaction behavior in a consistent, reusable way. You can validate software components in isolation, reuse them across different system compositions, and integrate them into software architecture models in System Composer™ for system-level simulation and code generation.

To get started, install the Software Component Designer for Simulink support package. For more information, see Install Software Component Designer for Simulink Support Package.

Define Component Interactions Using Interfaces

Software component models interact with other components through ports that are typed by interfaces, rather than direct signal connections. Interfaces define the data or services exchanged between components and establish the communication contract between connected components. In Simulink, software components support two primary interface types: send-receive and client-server.

• Send-receive interfaces enable data‑oriented communication, where sender components write data and receiver components read data through input and output ports. You can configure data exchange to provide the latest value or to queue multiple values so that the component preserves unread data. Component execution can be periodic, or data arrival can trigger it, enabling both time-driven and event-driven designs.

• Client-server interfaces enable function‑oriented communication, where a client component requests a function provided by a server component. This interaction models service-oriented behavior such as control operations, request-response workflows, and access to shared or distributed functionality. Client-server communication supports synchronous and asynchronous execution, allowing client components to wait for a response or continue execution while the server processes the request.

In addition to defining interaction patterns, software component models also capture how communication and execution behave at run time through QoS properties.

Model Communication and Execution Behavior with Quality of Service Properties

Quality of service (QoS) properties define how software components communicate and execute at run time. By assigning QoS properties to component ports, you specify behavioral semantics—such as how components exchange data or when functions execute—independent of any specific middleware or software platform.

QoS properties refine the interaction patterns defined by component interfaces. For send-receive interfaces, they specify whether receivers read the latest value or queued data, and how data arrival triggers execution. For client-server interfaces, they specify whether callers wait for a response or continue while the server processes the request. Defining QoS properties early in the design process enables you to validate run-time behavior through simulation before integrating components into a complete software architecture. For details on configuring QoS properties, see Configure Communication and Execution Behavior of Software Components.

Validate Component Behavior Through Simulation

Before integrating software components into a complete software architecture, you can validate communication and execution behavior using simulation with a mock run-time environment (RTE). A test harness provides a lightweight simulation environment that enables you to test a software component independently of the full system. The harness includes mock components that emulate interactions with other components through the same interfaces that you define on the component under test. To validate component behaviors using test harnesses, you need Simulink Test™ and System Composer. For more information, see Validate Component Behaviors Using Architecture Test Harnesses (System Composer).

During simulation, the mock RTE enforces the communication and execution behavior that the QoS properties specify, enabling you to observe how the component behaves under different interaction scenarios.

Simulation with a test harness enables you to:

• Validate component interactions through defined interfaces

• Observe execution and scheduling behavior

• Verify that communication and execution behavior matches your design intent

• Evaluate error handling and communication scenarios

After validating individual component behavior through simulation, you can integrate software components into a software architecture model to verify system‑level interactions, communication, and execution behavior.