Main Content

Map System Architecture to Simulink Modeling Environment

When designing models for rapid-prototyping deployment, think about these design factors.

Modeling Algorithms (Embedded Coder)Given initial state and input, a set of tasks or instructions that efficiently produce a correct result that you want.
Modeling Interfaces (Embedded Coder)Mechanisms that enable algorithm components to communicate and exchange information across component boundaries.
Modeling Systems (Embedded Coder)Collection of algorithm components that achieve a higher-level, domain-specific goal or result. Components often share resources.
Modeling Target Platform Environments (Embedded Coder)Framework that handles scheduling of system algorithm resources and execution.

Consider the following questions concerning modeling capabilities. Use the information listed with the questions as a guide as you design models. Designing a model with a specific run-time execution environment in mind can help you avoid rework and future conversion and maintenance costs.

Modeling Algorithms

Architecture ConsiderationsModeling ConsiderationsRelated 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
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

Use Products and Blocks Supported for Code Generation

Does the architecture include state machine components?Event-driven system

Model Finite State Machines by Using Stateflow Charts (Stateflow)

Modeling Interfaces

Architecture ConsiderationsModeling ConsiderationsRelated Information
  • What data must you represent in the generated code?

  • How do you need to represent input and output—data type, dimension, complexity?

  • How will the data change?

Data representation
Where and how is data pulled into the system and pulled within the system?Input

Comparison of Signal Loading Techniques

  • Where and how is data pushed within the system and out of the system?

  • What external triggers are needed?

  • What functions do you need to define for each component?

  • What is the prototype for each entry-point function?

Functions and function calls

Configure Generated C Function Interface for Model Entry-Point Functions

Do you need to export functions that are invoked by controlling logic that is outside the model?Function export
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
Is there a requirement for elaboration and future considerations?Elaboration and future considerations

Define Interfaces of Model Components

Modeling Systems

Architecture ConsiderationsModeling ConsiderationsRelated Information
  • What is the scope of the system? Controller? External environment or plant? Test harness?

  • How is the system partitioned into algorithm components (chunks of logic)?

  • Which components can you represent in Simulink®?

  • Can you design components for reuse? What is the motivation for reuse (for example, division of labor or plug-n-play)?

  • Do aspects of the system require unit testing?

  • Is a team of people collaborating on the project?

  • Do you need to protect intellectual property?

Model referencing
Are you modeling a client-server architecture?Simulink Function and Caller blocks
Is relevant legacy or custom code available?External code integrationChoose an External Code Integration Workflow (Embedded Coder)
Can you apply a reference architecture or reference components?Model and project templates
Can you reuse functions?Function reuse
  • Do components need to share access to global data?

  • Within the system, do state changes occur? In each case, how does the result get communicated?

  • Are there identifier (naming) issues to consider?

Shared data

Modeling Run-Time Environments

Architecture ConsiderationsModeling ConsiderationsRelated Information
  • What level of control over run-time interfacing does your application require?

  • How much of your system can you represent in a model?

Runtime interfacing
Is the system partitioned into concurrent components to maximize parallelism? Which components?Concurrency

Multicore Processor Targets

  • Are components driven by an external clock?

  • What clock rates do system components use?

  • Do components use a single rate or multiple rates?

Clocks and clock rates

Define Interfaces of Model Components

  • Are components in the system driven by clocks?

  • What clock rates do system components use?

  • Do components use a single rate or multiple rates?

  • What are the priorities of system tasks and functions?

Time-based scheduling
  • Are components in the system driven by events (interrupts)?

  • What are the priorities of system tasks and functions?

Event-based scheduling
Does the system need to handle initialization, reset, or terminate events?Initialization, reset, termination
  • Is the system a single-tasking or multitasking system?

  • Are components required to execute in real time?

  • What are the execution order dependencies (sequencing) between components?

  • What are the time constraints for task and function execution?

Task execution
  • If you know the processing platform, what is it?

  • Will the system run on a single-core or multicore processor?

  • Is the system a distributed system?

  • Is the processing platform hybrid or heterogeneous?

  • Does the architecture employ symmetric or asymmetric multiprocessing? If asymmetric, how is the platform software partitioned across CPUs?

Processing platformsMulticore Processor Targets