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 time- and event-based scheduling.
Design software component data interfaces.
Represent call to target platform 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 target 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 function 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 a composition, it is useful to distinguish between the algorithms that are internal to the component and the interaction of the component with target environment software. 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 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, and incremental Simulink loading and code generation. For more information, see Model Reference Basics.
You can create your own custom library of blocks by using the instances of blocks from built-in Simulink libraries or from the blocks or components you create. You can create custom blocks by 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.
To schedule and control the execution of your software component models, you can design each model as an export-function model or a rate-based model. For an export-function model, the code generator produces code for independent callable functions you can integrate with target environment software and a scheduler. See Export-Function Models Overview. With a rate-based model, Simulink schedules function execution based on sample times. The code generator produces a callable function for each rate represented in the model. 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.
When you design the interfaces of your components, use In Bus Element or Inport blocks to represent component inputs. A signal or a message arriving at an input port on a component flows out of the associated inport in that component. Similarly, use Out Bus Element or Outport blocks to represent component outputs.
To reduce visual complexity in a model, you can combine signals into buses that are composite signals. Buses contain elements that retain their separate identities, which allows you to extract them from the composite signal. When you group signals into a bus you can decide whether they affect simulation and code generation.
A virtual composite signal simplifies the visual appearance of a model by combining two or more signal lines into one line. It does not group the signals in any functional sense and, therefore, does not affect simulation or code generation. By accessing elements directly, virtual composite signals execute faster than nonvirtual composite signals in simulations and generated code.
A nonvirtual composite signal visually and functionally groups signals, affecting both simulation and code generation.
For more information, see Choose Among Composite Interfaces.
For models that include buses composed of many bus elements, consider using In Bus Element and Out Bus Element blocks. These blocks reduce signal line complexity and combine the functionality of Inport and Outport blocks with the ability to choose which elements of a bus to input and output. You can customize data interfaces to your components by defining and using custom bus types. See Create Nonvirtual Buses.
You can configure your components to call platform services, such data sender and receiver and timer services, custom services, such as device drivers, and other component code, or other target environment software, as in a distributed service architecture. Use function call subsystems and function caller blocks together with function ports for this purpose. See Call Simulink Functions in Other Models Using Function Ports.
You can 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.
Create Model of Target Environment
Once you create models of your software components, you can test your design by creating a model to emulate or mock the target 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.
Use Simulink functions to represent callable services such as input and output, memory, diagnostics, and hardware peripherals. See Simulink Functions Overview.
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 periodic 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 target 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 resulting data by 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.
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 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).
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).
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, execution functions, 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 Embedded Coder Fundamentals (Embedded Coder).