Map Embedded System Architecture to Simulink Modeling Environment
Map elements of your system architecture to elements of the Simulink® modeling environment. Consider these aspects of the model design.
Modeling Algorithms | Given initial state and input, a set of tasks or instructions that efficiently produce the results that you want. |
Modeling Interfaces | Mechanisms that enable algorithm components to communicate and exchange information across component boundaries. |
Modeling Systems | Collection of algorithm components that achieve a higher-level, domain-specific goal or result. Components often share resources. |
Modeling Target Platform Environments | Framework that handles scheduling of system algorithm resources and execution. |
The following sections map questions to consider regarding an embedded system architecture to corresponding modeling capabilities and links to related information. Use the information as a guide for mapping your architecture details to the Simulink modeling environment. Designing a model architecture with your specific embedded system architecture in mind can help you avoid rework and future conversion and maintenance costs.
Modeling Algorithms
Architecture Considerations | Modeling Considerations | Related Information |
---|---|---|
What is the system domain? | Product prerequisites (based on domains of components) | |
Does the system involve physical domains, such as mechanical, electrical, or hydraulic domains? | Physical systems | |
Are you deploying an application or component? | Modeling styles and code interfaces | Software Deployment Objectives and Deployment Types |
What aspects of your algorithm can you represent with blocks provided by MathWorks® products? What blocks do you need to create? | Block usage, creation, and customization | |
Do you want to import existing external MATLAB®, C, or C++ code into a model for inclusion in your generated code? | External code import | External Code Import |
Does the architecture include state machine components? | Event-driven system | Model Finite State Machines by Using Stateflow Charts (Stateflow) |
Do you want to apply modeling guidelines that are relevant to code generation intent? Do models and generated code need to comply with industry standards? | Standards and modeling guidelines | Standards, Guidelines, and Block Usage |
Is there a need to standardize code that the code generator produces from multiple models? | Custom code interface configurations |
Modeling Interfaces
Architecture Considerations | Modeling Considerations | Related Information |
---|---|---|
Do you want the code generator to generate algorithm entry-point functions that execute periodically or aperiodically? | Rate-based or export-function modeling style | Periodic and Aperiodic Function Interfaces |
What type of code interface are you going to use (data or service)? | Code interfaces | Choose Code Interface for Code Generation |
For a data code interface:
| Data representation | |
| Input, service code interface | |
| Output, service code interface | |
| Functions and function calls | |
For a data code interface, can you benefit from setting up default code generation configurations for categories of data and functions? | Data code interface | |
Do you need to export functions that are invoked by controlling logic that is outside the model? | Function export | |
Will internal functions exchange data? | Service code interface | |
Do you need to access target environment timer data? | Service code interface | |
Does the system monitor signals or log data (for example, for calibration)? | C API and ASAP2 data exchange interfaces | |
Do you need to replace code generated for functions or operators, for example, to optimize the code for specific hardware? | Code replacement | |
Do you need to control the placement of data or functions in memory? | Memory sections | Control Data and Function Placement in Memory by Inserting Pragmas |
Is there a requirement for elaboration and future considerations? | Elaboration and future considerations |
Modeling Systems
Architecture Considerations | Modeling Considerations | Related Information |
---|---|---|
| Componentization |
|
| Model referencing | |
Are you modeling a client-server architecture? | Simulink Function and Caller blocks | |
Is relevant legacy or custom code available that you can include in a component model? | Code import | External Code Import |
Can you apply a reference architecture or reference components? | Model and project templates | |
Do you need to export functions that are invoked by controlling logic that is outside a model? | Export-function models | Export-Function Models Overview |
Is there a need to package the source code for a component as a shared object library to simplify distribution or sharing? | Shared object libraries (dynamic link libraries) | Package Generated Code as Shared Libraries |
Can you reuse functions? | Function reuse | |
| Shared data | |
Do you need to control placement of data or functions in memory? | Memory sections | Control Data and Function Placement in Memory by Inserting Pragmas |
Are you required to apply the AUTOSAR standard? If yes, what aspects of the architecture involve AUTOSAR? | AUTOSAR | AUTOSAR Blockset |
Does your system need to meet other standards or guidelines? | Standards and guidelines | Support for Standards and Guidelines |
Modeling Target Platform Environments
Architecture Considerations | Modeling Considerations | Related Information |
---|---|---|
| Target platform interfacing | |
Is the system decomposed into concurrent components to maximize parallelism? Which components? | Concurrency | |
| Clocks, clock, rates, and time-based scheduling | |
| Event-based scheduling | |
Does the system need to handle initialization, reset, or terminate events during system startup or shutdown? | Initialization, reset, termination | |
| Task execution | |
| Processing platforms | |
| Kernel, operating system |
For multicore scenarios, the code generator assumes that:
Target hardware includes two or more cores.
System initialization occurs on one core.
Services assign tasks to a core statically. Tasks do not switch between cores.
Tasks can communicate within and across cores during run time.
This figure illustrates these assumptions. The tasks in the figure represent instances of entry-point functions running in a multi-core target platform environment.