This part stipulates the appearance characteristics of models and modules
4.1. Background color convention
| Module |
Background color |
Simulink setting value |
| Atomic Unit/Subsystem |
green |
Green |
| Inport |
green |
Green |
| Outport |
red |
Red |
| Standardized amount |
gray |
Gray |
| Monitor variable |
gray |
Gray |
| Constant |
gray |
Gray |
| Reference public functions |
yellow |
Yellow |
4.2. Data types allowed in the model
Simulink supports all built-in numeric MATLAB® data types except int64 and uint64.
| Name |
Description |
| Inherit: Inherit from Parent value |
Use data type of Settings/Parent value. |
| Inherit: Inherit via back propagation |
Use data type of the driving block. |
| double |
Double-precision floating point |
| single |
Single-precision floating point |
| int8 |
Signed 8-bit integer |
| uint8 |
Unsigned 8-bit integer |
| int16 |
Signed 16-bit integer |
| uint16 |
Unsigned 16-bit integer |
| int32 |
Signed 32-bit integer |
| uint32 |
Unsigned 32-bit integer |
| boolean |
Boolean (1 = true; 0 = false) |
| fixdt(1,16) |
fixed point fixdt(1,16). |
| fixdt(1,16,0) |
fixed point fixdt(1,16,0). |
| fixdt(1,16,2^0,0)) |
fixed point fixdt(1,16,2^0,0). |
| Enum: |
enumerated data type |
| Bus: |
bus object |
4.3. Model comments
The key algorithm in the model must be annotated. The annotation must be written in the annotation area. The annotation text does not affect the simulation and code generation. The annotation must follow the following principles:
• Framed
• Shaded
• English
• Font size: Arial, regular, 10
Localized language should only be used in areas with description and annotation properties, such as the descriptive fields of modules.
4.4. Model organization
The hierarchical structure of the model is helpful to improve the readability and maintainability of the model. Generally, when modeling a logic system, the following modules are used when dividing the hierarchy:
• Subsystem
• Atomic Subsystem
•
All levels in the Stateflow model should correspond to the functions and structures of the control system. It also guarantees readability and good workflow, can be tested and verified, and can generate code.
When modeling, it is recommended to divide the hierarchy in the following ways:
• Top layer
• Trigger layer (not required)
• Structure layer
• Data layer The
top layer is the outermost layer that reflects the overall appearance of the model, including the overall model input and input and output variable definition and logic control section. The trigger layer indicates the trigger timing of each sub-module, and if necessary, set its priority and express it in comments. The structural layer mainly displays the logical framework of the model operation, which is a further functional division. It is recommended that each subsystem module be set as an atomic subsystem. The data layer is composed of "basic modules", which is the bottom layer of the model and is used to represent the data transmission sequence and data operation process.
Each model is created in a library manner and uses hierarchical management to facilitate subsequent version update management. Generally consists of three levels:
• The first level: integrated modules, named: xxxx_yyyy (module abbreviation
name_project code abbreviation) • Second level: functional subsystem, naming: xxxx_zzzz (module abbreviation name_subsystem function abbreviation)
• The third level: subdivide the subsystem, naming: according to the characteristics and functions of the subsystem
• The fourth level: increase the level as needed