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.
|Given initial state and input, a set of tasks or instructions that efficiently produce the results that you want.
|Mechanisms that enable algorithm components to communicate and exchange information across component boundaries.
|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.
|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?
|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?
|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
|What type of code interface are you going to use (data or service)?
|Choose Code Interface for Code Generation
For a data code interface:
|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?
|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?
|Do you need to control the placement of data or functions in memory?
|Is there a requirement for elaboration and future considerations?
|Elaboration and future considerations
|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?
|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 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?
|Do you need to control placement of data or functions in memory?
|Are you required to apply the AUTOSAR standard? If yes, what aspects of the architecture involve AUTOSAR?
|Does your system need to meet other standards or guidelines?
|Standards and guidelines
|Support for Standards and Guidelines
Modeling Target Platform Environments
|Target platform interfacing
|Is the system decomposed into concurrent components to maximize parallelism? Which components?
|Clocks, clock, rates, and time-based scheduling
|Does the system need to handle initialization, reset, or terminate events during system startup or shutdown?
|Initialization, reset, termination
|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.