Prior to selecting the modeling guidelines to adopt for your project, it is important that you consider various aspects of your project and models, such as:
The model base development that utilizes simulation is suitable for developing a safe product. However, this does not mean that a system is safe simply because the design can be simulated. While high quality control and functions is necessary, the process definition and development environment being used is equally important. The foundation for a safe system is determined at the start of the project, long before development begins.
The version of MATLAB® and Simulink® that is used at each development stage is determined at the start of the project. That version must be used by everyone during that development stage.
Different MATLAB versions can be used for different stages in the development process. For example, you can generate and verify the code in R2017b and then use Simulink Design Verifier™ to develop test cases R2020a.
It is necessary to regularly check the bug report published by MathWorks®, which are available on the MathWorks website at https://www.mathworks.com/support/bugreports. Depending on the bug, a version change may be required; a decision that can be reversed if necessary. During this evaluation, it is important to consider risk from both:
Malfunctions that result from a bug
Result from upgrading the version
It is necessary to always have a process that allows adaptation to the latest version and to appropriately evaluate and judge what is the safest option.
MATLAB and Simulink settings shall adhere to the project. It is important that Simulink settings that affect appearance are applied consistently across the project.
Options to be unified include:
Simulink environment settings:
New model standard font settings (block, line, annotation)
Mask (Edit mask):
Icons and Ports
(Block) Sorted execution order
(Signals and ports) Wide Non-scalar Lines
(Signals and ports) Port data types
There are many blocks in Simulink, however, not all are suitable for all aspects of a project. For example, only some blocks are suitable for generating production-quality code. Or, depending on the block, a function using a combination of basic blocks can be represented by using one block. Usable blocks and design should be defined and limited to the requirements and specifications of the project.
Significantly limiting the number of available blocks can cause adverse effects, such decreased readability due to variation within the descriptions for the same function, decreased code efficiency, and increased user libraries.
You must register custom blocks in the project’s user library.
See guideline db_0143: Usable block types in model hierarchy for defining usable blocks
It is important to consider how you are using optimization options and configuration parameters for your project.
Optimization options significantly affect generated code. Closely evaluate and apply the optimization options with regards to how they impact the security and safety considerations for your project or product.
As an example of how optimization parameters can impact a process:
For embedded automotive products, it is critical that processing time is fast and RAM/ROM requirement are minimal. To accommodate these requirements, optimization parameters are applied on the Conditional Input Branch Execution pane. These optimization parameters improve the computation rate by executing only where the condition holds during execution of the conditional branch by using the Switch block.
In contrast, for the aviation industry, the Conditional Input Branch Execution pane is disabled because stabilizing the execution speed is key. Calculation on both sides is preferred in order to maintain a stable computation time, even if calculation is needed only on the side where the condition holds.
Consider these configuration parameters:
Hardware Implementation Settings
Describes model system hardware characteristics, including products and test hardware configuration setup for simulation and code generation. Configure these parameters so they are compatible with the microcomputer that the project uses. Unintended utility functions can be inserted if signed integer division rounding is undefined.
Model Reference Settings
Specified when using model references. Refers to options to include other models in this model, options to include this model in another model, and build options of simulation and code generation targets.
Simulation Target Setting
High-Integrity Configuration Settings
Code Generation Configuration Settings
For additional information the about the code generation configuration settings, see the Code Generation modeling guidelines.