Development of ECU Application Layer Model: Data Dictionary and Simulink.Parameter

Development of ECU Application Layer Model: Data Dictionary and `Simulink.Signal` introduces the core object of the data dictionary (`.sldd`) in Model-Based Design (MBD), focusing on another core object, `Simulink.Parameter`.

`<code>Simulink.Parameter` is a core object class defined by the Simulink environment, playing a crucial role in the data dictionary throughout the lifecycle of model design, simulation, parameter management, and final product-level code generation. Understanding its essence, purpose, usage, and its relationship with code generation is essential for developing high-quality, maintainable, and industry-standard embedded software.`Without further ado, let's get to the point:`

1. `Simulink.Parameter` Object

1.1 Definition and Essence

Simulink.Parameter is essentially a metadata container or parameter object, which encapsulates the following key information in a unified entity:

Value: The actual value of the parameter (e.g., scalar 10.5, vector [1, 2, 3], matrix, etc.).
DataType: Precisely specifies the data type of the parameter (e.g., uint8, int16, boolean, or custom fixed-point type fixdt(1,16,8), etc.).
Storage Class: Defines how the parameter should be represented and stored in the generated embedded C code.
Other Attributes: Includes minimum value (Min), maximum value (Max), unit (Unit), description (Description), complexity (Complexity), and dimensions (Dimensions), etc.

In short, Simulink.Parameter is a strongly typed parameter entity with rich attributes and code generation intent declarations, which replaces the practice of directly using raw numerical values within the model or MATLAB base workspace, achieving centralized and standardized management of parameters. This means that parameters scattered across various corners of the model (such as gain values in Gain blocks, breakpoint data in Lookup Tables, constants in Stateflow, etc.) are defined centrally in the data dictionary, and modifying a parameter only requires updating it once in the data dictionary to take effect globally.

By enforcing the specification of attributes such as DataType, Min, Max, etc., in the object definition, it can prevent unexpected data type conversions or value out-of-bounds errors when using the same parameter in different locations in the model; and by using the Storage Class attribute, it explicitly specifies how the parameter is stored and accessed in the target embedded system. For example:

Parameters declared as Const or AUTOSAR.Constant will generate as const type in the code, typically placed in the ROM area.
Parameters declared as ExportedGlobal or AUTOSAR.Parameter will generate global variables (which may need volatile modifiers), allowing online adjustments during runtime through calibration tools (such as XCP/CCP).
Declaring as ImportedExtern indicates that the parameter is defined externally (e.g., in other C files), and will be declared as extern in the code.

1.2 Usage of Simulink.Parameter

1) Creating an Object (in the Data Dictionary):

Right-click on the Design Data node in the data dictionary -> Add -> Simulink Parameter, and name the object as shown in the following figure: Param1:

2) Configuring Attributes:

Set key attributes in the property pane on the right side of Model Explorer, as shown below:

3) Associating with Module Parameters:

In the Simulink model, double-click the module that needs parameter configuration (such as Gain, Constant, Lookup Table n-D, etc.) to open its parameter dialog box, taking Constant as an example.

In the corresponding parameter value field (such as the Constant Value field of the Constant module), enter the name of the Simulink.Parameter object defined in the data dictionary (Param1).

When the model is compiled or updated, Simulink will retrieve the Value property value of the Parameter object from the data dictionary and apply it to the module parameter. At the same time, the data type, dimensions, etc., of the module parameter will also be constrained by the corresponding attributes of the Parameter object.

2 Application of Simulink.Parameter in ECU Application Model Development

In ECU (Electronic Control Unit) application model development, Simulink.Parameter is mainly used to define parameters, such as concentrating the constant parameters used in the model (e.g., control thresholds, scaling factors, calibration values, etc.) in the Simulink.Parameter object for unified viewing, modification, and maintenance; and for parameters that need to be adjusted during actual ECU operation or later calibration stages, Simulink.Parameter can be configured as “tunable parameters” to achieve offline or online calibration with ECU calibration tools without recompiling the model. Common examples include:

PID Controller: Define Simulink.Parameter objects P_Gain, I_Gain, D_Gain, so that the gain values are encapsulated and defined with clear value ranges and data types, and in the generated code, they are global variables that can be adjusted at runtime through calibration tools.
Lookup Table Data: Define a Simulink.Parameter object EngineTorqueMap, set the Value to [1000, 2000, 3000; 50, 150, 250] (representing the RPM-throttle-torque mapping table),DataType set to single, and Dimensions set to [2, 3]. Associate it with the Table data parameter of the Lookup Table (2-D) module. This centrally manages the table data and its attributes.
Conversion Coefficients: Define Simulink.Parameter objects Param1 and Param2, as shown below:

Of course, there are other uses, which will not be detailed here.

Considering that Simulink.Signal and Simulink.Parameter are the two core objects of the ECU application layer model data dictionary, let’s briefly compare the two:

3. `Simulink.Signal` vs. `Simulink.Parameter` Differences and Relationships

Both allow for fine control of data attributes (whether signals or parameters), which is crucial for model quality, simulation accuracy, and efficient code generation. They are often used together in the same data dictionary to define the complete data interface and configuration of the model. The specifics are shown in the table below:

Feature	`<span><span>Simulink.Signal</span></span>`	`<span><span>Simulink.Parameter</span></span>`	Relationship
Core Representation	Data flowing on signal lines (dynamic)	Values of module parameters (static/configured)	Both are data objects used to manage data in Simulink models.
Stored Content	Metadata (describing signal attributes)	Value + Metadata (including specific values and descriptive attributes)	Both contain metadata describing data characteristics (`<span><span>DataType</span></span>`, `<span><span>Dimensions</span></span>`, `<span><span>Complexity</span></span>`, etc.).
Value Storage	Does not store specific values (stores initial value `<span><span>InitialValue</span></span>`)	Stores specific values (`<span><span>Value</span></span>` property)
Main Use	Defines signal attributes, bus elements, states, control code signal representations	Defines module parameter values, constants, tunable parameters, control code parameter representations	Both are used for precise control of data types, dimensions, and other attributes.
Target Object	Associated with signal lines (resolved by signal name)	Associated with module parameter dialog
Dynamic Nature	Represents data flow that may change during model execution	Represents typically fixed or runtime-tunable configurations/constants	`<span><span>Signal</span></span>` ‘s `<span><span>InitialValue</span></span>` is parameter-like; `<span><span>Parameter</span></span>` can be tunable.
Code Generation	Controls signal variable declarations (global variables, external variables, etc.)	Controls parameter representations (`<span><span>#define</span></span>`, `<span><span>const</span></span>`, global variables, etc.)	Both control representations and storage methods in generated code through `<span><span>Storage Class</span></span>` and other attributes.
Typical Examples	Sensor signals, control commands, state variables, bus elements	PID gains, physical constants, lookup table data, thresholds, sampling times

Considering that there are overlaps in the usage of both in practical applications, let's review the differences between the two based on the above table:

Signal is a descriptor of data flow (line), while Parameter is a container for configuration values (point).
Signal objects themselves do not store the real-time values flowing on the signal line during simulation; they only define the attributes of that signal. The values of the signal during simulation are determined by the module that generates it.
Parameter objects store the specific value of the parameter they represent (Value property), which will be directly used in the associated module parameters.
You select a signal line in the model and apply a Signal object; you enter the name of a Parameter object in the module’s parameter dialog to apply it.

Creating content is not easy, feel free to like, save, and follow for more!! (Qian Yixing changed name Automotive Electronics Engineering Circle) Automotive R&D exchange group, interested friends please add the group owner: prOmiseyes, note: company + position to join the group. Limited to automotive practitioners.

Series of articles on ECU application layer software models are continuously updated, teaching you application layer development from scratch:

Example 1 of building ECU application layer software model (qq.com)
How to automatically generate code for ECU application layer software model 2 (qq.com)
How to run ECU application layer software periodically 3 (qq.com)
Code generation configuration related to hardware for ECU application layer software model 4 (qq.com)
Data dictionary of ECU application layer software model DD 5 (qq.com)
Storage classes of data dictionary in ECU application layer software model 6 (qq.com)
Fixed-point implementation methods for ECU application layer software model 7 (qq.com)
Five fixed-point implementation methods for ECU application software model 8 (qq.com)
Custom storage classes for ECU application layer software model 9 (qq.com)
Summary of model generation code for ECU application layer software model 10 (qq.com)
CAN reception in ECU application layer model 11 (qq.com)

Data stream of CAN message reception in ECU application layer model 12
How to leverage AI in ECU software development? Application of Kimi in MBD development environment 13

Detailed explanation of unit test coverage CC, DC, and MCDC in ECU application layer software model 14
Application and Principles of Calibration and Observables in ECU Application Layer Model Development 15
Usage of for loop in ECU application layer model development 16

Usage of if-else in ECU application layer model development 17
Initialization function in ECU application layer model development 18

Counter in ECU application layer model development 19
Basics of Assignment module in ECU application layer model development 20
Application of Delay module in ECU application layer model development 21
ECU application layer model development: If-else vs. switch-case 22
Data dictionary of ECU application layer model development: Simulink.Signal 23
Data overflow handling in ECU application layer model development 24
Disasters caused by Delay in ECU application layer model development 25
Usage of Tapped Delay in ECU application layer model development 26
First-order low-pass filtering in ECU application layer model development 27

Development of ECU Application Layer Model: Data Dictionary and Simulink.Parameter

1. `<span><span>Simulink.Parameter</span></span>` Object

3. `<span><span>Simulink.Signal</span></span>` vs. `<span><span>Simulink.Parameter</span></span>` Differences and Relationships

Application and Principles of Calibration and Observables in ECU Application Layer Model Development 15

Usage of for loop in ECU application layer model development 16

Leave a Comment Cancel reply

Development of ECU Application Layer Model: Data Dictionary and <span><span>Simulink.Signal</span></span> introduces the core object of the data dictionary (<span><span>.sldd</span></span>) in Model-Based Design (MBD), focusing on another core object, <span><span>Simulink.Parameter</span></span>.

1. <span><span>Simulink.Parameter</span></span> Object

3. <span><span>Simulink.Signal</span></span> vs. <span><span>Simulink.Parameter</span></span> Differences and Relationships

Application and Principles of Calibration and Observables in ECU Application Layer Model Development 15

Usage of for loop in ECU application layer model development 16

Related posts

Leave a Comment Cancel reply

1. `<span><span>Simulink.Parameter</span></span>` Object

3. `<span><span>Simulink.Signal</span></span>` vs. `<span><span>Simulink.Parameter</span></span>` Differences and Relationships