Add docs about TargetLink
Change-Id: I027ec3815c741022d3860820e8ac8c521506c1c8
BIN
docs/images/target_link/action_name.png
Normal file
After ![]() (image error) Size: 1.8 KiB |
BIN
docs/images/target_link/autosar_name.jpg
Normal file
After ![]() (image error) Size: 116 KiB |
BIN
docs/images/target_link/bus_inport.png
Normal file
After ![]() (image error) Size: 173 KiB |
BIN
docs/images/target_link/bus_inport_member.png
Normal file
After ![]() (image error) Size: 134 KiB |
BIN
docs/images/target_link/bus_outport.png
Normal file
After ![]() (image error) Size: 184 KiB |
BIN
docs/images/target_link/bus_outport_member.png
Normal file
After ![]() (image error) Size: 147 KiB |
BIN
docs/images/target_link/bus_parameters.png
Normal file
After ![]() (image error) Size: 199 KiB |
BIN
docs/images/target_link/condition_name.png
Normal file
After ![]() (image error) Size: 2.0 KiB |
BIN
docs/images/target_link/device_name.png
Normal file
After ![]() (image error) Size: 1.7 KiB |
BIN
docs/images/target_link/did_table.PNG
Normal file
After (image error) Size: 12 KiB |
BIN
docs/images/target_link/enum_constant.PNG
Normal file
After (image error) Size: 95 KiB |
BIN
docs/images/target_link/enum_constant_cal.PNG
Normal file
After (image error) Size: 115 KiB |
BIN
docs/images/target_link/enum_constant_const.PNG
Normal file
After (image error) Size: 115 KiB |
BIN
docs/images/target_link/enum_constant_var.PNG
Normal file
After (image error) Size: 117 KiB |
BIN
docs/images/target_link/enum_inport.PNG
Normal file
After (image error) Size: 69 KiB |
BIN
docs/images/target_link/example_name.png
Normal file
After ![]() (image error) Size: 2.0 KiB |
BIN
docs/images/target_link/fid_table.PNG
Normal file
After (image error) Size: 23 KiB |
BIN
docs/images/target_link/function_block.jpg
Normal file
After ![]() (image error) Size: 73 KiB |
BIN
docs/images/target_link/function_block.png
Normal file
After ![]() (image error) Size: 31 KiB |
BIN
docs/images/target_link/nvm_block_example.PNG
Normal file
After (image error) Size: 56 KiB |
BIN
docs/images/target_link/nvm_concept.jpg
Normal file
After ![]() (image error) Size: 55 KiB |
BIN
docs/images/target_link/propertyman.png
Normal file
After ![]() (image error) Size: 11 KiB |
BIN
docs/images/target_link/propertyman_2.png
Normal file
After ![]() (image error) Size: 64 KiB |
BIN
docs/images/target_link/sf_double.png
Normal file
After ![]() (image error) Size: 330 KiB |
BIN
docs/images/target_link/sf_inherit.png
Normal file
After ![]() (image error) Size: 135 KiB |
BIN
docs/images/target_link/stateflow_wiki.png
Normal file
After ![]() (image error) Size: 11 KiB |
BIN
docs/images/target_link/structure.png
Normal file
After ![]() (image error) Size: 6.0 KiB |
BIN
docs/images/target_link/tab_idx_edit_index_calc.jpg
Normal file
After ![]() (image error) Size: 43 KiB |
BIN
docs/images/target_link/tab_idx_edit_lib_ref.jpg
Normal file
After ![]() (image error) Size: 16 KiB |
BIN
docs/images/target_link/tab_idx_function.jpg
Normal file
After ![]() (image error) Size: 9.5 KiB |
BIN
docs/images/target_link/tab_idx_output_format.jpg
Normal file
After ![]() (image error) Size: 16 KiB |
BIN
docs/images/target_link/tab_idx_output_type.jpg
Normal file
After ![]() (image error) Size: 10 KiB |
BIN
docs/images/target_link/tab_idx_remove_var.jpg
Normal file
After ![]() (image error) Size: 21 KiB |
BIN
docs/images/target_link/tab_idx_search_method.jpg
Normal file
After ![]() (image error) Size: 12 KiB |
BIN
docs/images/target_link/tab_int_settings.jpg
Normal file
After ![]() (image error) Size: 9.4 KiB |
BIN
docs/images/target_link/tab_intp_edit_intp_calc.jpg
Normal file
After ![]() (image error) Size: 85 KiB |
BIN
docs/images/target_link/tab_intp_edit_lib_ref.jpg
Normal file
After ![]() (image error) Size: 13 KiB |
BIN
docs/images/target_link/tab_intp_function.jpg
Normal file
After ![]() (image error) Size: 8.0 KiB |
BIN
docs/images/target_link/tab_intp_remove_var.jpg
Normal file
After ![]() (image error) Size: 17 KiB |
BIN
docs/images/target_link/tab_intp_theory.jpg
Normal file
After ![]() (image error) Size: 50 KiB |
BIN
docs/images/target_link/variable_cal_constant.jpg
Normal file
After ![]() (image error) Size: 98 KiB |
BIN
docs/images/target_link/variable_cal_map.jpg
Normal file
After ![]() (image error) Size: 40 KiB |
BIN
docs/images/target_link/variable_cal_mergeable.jpg
Normal file
After ![]() (image error) Size: 219 KiB |
BIN
docs/images/target_link/variable_cal_mergeable_example.jpg
Normal file
After ![]() (image error) Size: 98 KiB |
BIN
docs/images/target_link/variable_cal_pre_look_up.jpg
Normal file
After ![]() (image error) Size: 71 KiB |
BIN
docs/images/target_link/variable_cal_table.jpg
Normal file
After ![]() (image error) Size: 112 KiB |
BIN
docs/images/target_link/variable_classes.PNG
Normal file
After (image error) Size: 16 KiB |
BIN
docs/images/target_link/variable_default.jpg
Normal file
After ![]() (image error) Size: 80 KiB |
BIN
docs/images/target_link/variable_default_constant.jpg
Normal file
After ![]() (image error) Size: 104 KiB |
BIN
docs/images/target_link/variable_description.jpg
Normal file
After ![]() (image error) Size: 83 KiB |
BIN
docs/images/target_link/variable_external_constant.jpg
Normal file
After ![]() (image error) Size: 52 KiB |
BIN
docs/images/target_link/variable_inport.jpg
Normal file
After ![]() (image error) Size: 54 KiB |
BIN
docs/images/target_link/variable_measureable.jpg
Normal file
After ![]() (image error) Size: 81 KiB |
BIN
docs/images/target_link/variable_measureable_masked.jpg
Normal file
After ![]() (image error) Size: 180 KiB |
BIN
docs/images/target_link/variable_measureable_min_max.jpg
Normal file
After ![]() (image error) Size: 99 KiB |
BIN
docs/images/target_link/variable_outport.jpg
Normal file
After ![]() (image error) Size: 104 KiB |
BIN
docs/images/target_link/variable_properties.jpg
Normal file
After ![]() (image error) Size: 91 KiB |
BIN
docs/images/target_link/variable_unique_constant.jpg
Normal file
After ![]() (image error) Size: 51 KiB |
BIN
docs/images/target_link/variable_vc_const.jpg
Normal file
After ![]() (image error) Size: 54 KiB |
@ -108,7 +108,7 @@ The powertrain_build wrapper has many options, we'll explain them in detail here
|
||||
system to powertrain_build. Once powertrain_build is officially in use, all source code should
|
||||
already have been converted.
|
||||
|
||||
`--codegen` Runs TargetLink to generate C source code from the Matlab models.
|
||||
`--codegen` Runs [TargetLink](target_link/target_link.md) to generate C source code from the Matlab models.
|
||||
This should be done before changes are submitted for review. If the generated
|
||||
code is missing, the build system will reject your changes.
|
||||
|
||||
|
@ -112,6 +112,8 @@ chapters.
|
||||
- Out ports which are reset when disabling a subsystem, which are used in subsystems under a pre-processor block.
|
||||
- Solution of TargetLink limitation is refactoring of models.
|
||||
|
||||
For more information about the TargetLink setup see [this page](target_link/target_link.md).
|
||||
|
||||
### powertrain_build dependencies
|
||||
|
||||
Python module dependency visualization from pydeps,
|
||||
|
@ -16,6 +16,15 @@ The basic code introduction is placed in [powertrain_build General Code Introduc
|
||||
|
||||
Information on how to deploy powertrain_build can be found [here](./powertrain_build_deployment.md).
|
||||
|
||||
## powertrain_build and Code Generators
|
||||
|
||||
powertrain_build collects code generated from Simulink models in Matlab.
|
||||
powertrain_build was based on working with TargetLink but also supports Embedded Coder (if set up correctly).
|
||||
powertrain_builds contains code for generating code from Simulink models,
|
||||
which can be found in *powertrain_build/matlab_scripts* folder.
|
||||
|
||||
For more information about the TargetLink setup see [this page](target_link/target_link.md).
|
||||
|
||||
## powertrain_build Development
|
||||
|
||||
If you want to develop powertrain_build, you can run it directly from the Git repositories.
|
||||
|
32
docs/target_link/custom_code_block.md
Normal file
@ -0,0 +1,32 @@
|
||||
# TargetLink Custom Code Blocks
|
||||
|
||||
-------------------------------
|
||||
|
||||
[TOC]
|
||||
|
||||
## The Custom Code Block
|
||||
|
||||
The custom code block enables to easily insert custom written snippets of c code.
|
||||
|
||||
Make sure to use a proper code review, as it is easy to cause underflow and overflow errors.
|
||||
The usage of Polyspace Code Prover is advised.
|
||||
|
||||
It could also be an idea to run Polyspace bugfinder.
|
||||
|
||||
### Sharing the C Code
|
||||
|
||||
By deploying the generated c code from the custom code blocks to a common folder,
|
||||
it can be shared between simulink models (similarily to [shared TargetLink functions](./functions.md)).
|
||||
|
||||
### Read the Manual
|
||||
|
||||
There are some docs in the TargetLink documentation DSPace docs under: Custom Code Blocks.
|
||||
|
||||
Also, there is a demo model, in the MATLAB Command Window, enter `tl_demos custom_blocks`.
|
||||
|
||||
### Header Files
|
||||
|
||||
Include Statements in Custom Code blocks should not be used, but replaced by "AddFile" blocks.
|
||||
|
||||
This complies to MISRA rule 19.1.
|
||||
Include directives which says that only preprocessor directives or comments may be placed before include directives.
|
277
docs/target_link/diagnostics.md
Normal file
@ -0,0 +1,277 @@
|
||||
# Diagnostics
|
||||
|
||||
-------------
|
||||
|
||||
[TOC]
|
||||
|
||||
powertrain-build has two ways of handling diagnostics, depending on the use case.
|
||||
|
||||
The code for finding the diagnostics blocks can be seen in
|
||||
[parseCoreIdentifiers.m](https://opendev.org/volvocars/powertrain-build/src/branch/master/powertrain_build/matlab_scripts/CodeGen/parseCoreIdentifiers.m)
|
||||
and
|
||||
[parseDIDs.m](https://opendev.org/volvocars/powertrain-build/src/branch/master/powertrain_build/matlab_scripts/CodeGen/parseDIDs.m).
|
||||
|
||||
## Basics
|
||||
|
||||
All functions that are asking the core permission to run need to have an ID – this is called a Function ID.
|
||||
Permission to run can be withheld as a function of errors in the system, this is called Inhibition.
|
||||
The relationship of which functions should be stopped for which faults (which are reported using an Event ID) is possible to calibrate.
|
||||
Fail safes (Reconfigurations) use the same method/mechanism, but instead of stopping when an error is detected, they are activated.
|
||||
|
||||
### DTCs
|
||||
|
||||
An event ID is used for storing an event (Diagnostic Trouble Code (DTC)) in the Diagnostic Event Manager (DEM).
|
||||
An event can be a detected fault, system not working according to specification or a placeholder where we might want to store additional information at the occurrence of the event.
|
||||
The Stored events are DTCs when read with a tester.
|
||||
|
||||
### DIDs
|
||||
|
||||
DID is short for Data Identifier and is part of the Unified Diagnostic Services (UDS) protocol,
|
||||
where it represents data items within an electronic control module (ECM) of a car.
|
||||
DIDs can include things like sensor readings, actuator positions, and diagnostic trouble codes (DTCs).
|
||||
DIDs are used to access and manipulate these data items through the UDS protocol, which allows for communication between diagnostic tools and the vehicle’s onboard computer.
|
||||
|
||||
## Using CSV Files
|
||||
|
||||
These files are generally stored in *\<repo-root\>/ConfigDocuments* but
|
||||
can also be stored in *\<repo-root\>/Projects/\<PROJECT_NAME\>/ConfigDocuments*, however,
|
||||
an update in *\<repo-root\>/Projects/\<PROJECT_NAME\>/ProjectCfg.json* is required for the latter.
|
||||
|
||||
### How to Define a Function ID Name
|
||||
|
||||
* Add the FiD (Function Identifier) in the sheet *CoreIdNameDefinition_FunctionIDs.csv*.
|
||||
* Enter in which projects this FiD is to be defined in the project columns.
|
||||
* All FiDs shall have the prefix *VcFi*, and all Fail safes shall have the prefix *VcFiFs*.
|
||||
* If a used FiD is not configured in the core, the project will not compile.
|
||||
|
||||

|
||||
|
||||
### How to Add a Failsafe/Permission in a Model
|
||||
|
||||
This requires a special setup.
|
||||
The block needs to be named "FiM_GetFunctionPermission" in order for powertrain-build to pick it up.
|
||||
To handle this functionality it is currently recommended that this block uses a
|
||||
[custom code block](./custom_code_block.md) to handle the functionality,
|
||||
depending on the target.
|
||||
|
||||
A named constant is typically the input to this block.
|
||||
|
||||
### How to Define an Event ID Name
|
||||
|
||||
* Add the Event Id in the sheet *CoreIdNameDefinition_EventIDs.csv*.
|
||||
* Enter in which projects these EvIds shall be defined in the project columns.
|
||||
* All Event IDs shall have the prefix *VcEv*.
|
||||
* If a used Event ID is not configured in the core, the project will not compile.
|
||||
|
||||
The structure of this csv file is the same as the one for Function IDs.
|
||||
|
||||
### How to Add Event Reporting in a Model
|
||||
|
||||
This requires a special setup.
|
||||
There are typically one block per event type.
|
||||
For example "Dem_SetEventStatus – Pre-Failed" block for reporting faults,
|
||||
"Dem_SetEventStatus – Pre-Passed" block for reporting test passed.
|
||||
"Dem_SetEventStatus – Failed" and "Dem_SetEventStatus - Passed" are also possible.
|
||||
|
||||
To handle this functionality it is currently recommended that this block uses a
|
||||
[custom code block](./custom_code_block.md) to handle the functionality,
|
||||
depending on the target.
|
||||
|
||||
A named constant is typically the input to these blocks.
|
||||
|
||||
### How to Define a DID
|
||||
|
||||
powertrain-build can read a few DID files depending on the use case and the data type of the DIDs.
|
||||
Parsed DID files include *DIDIds_Float32.csv*, *DIDIds_FullRange_Float32.csv*, *DIDIds_FullRange_UInt32.csv* and *DIDIds_UInt32.csv*.
|
||||
|
||||

|
||||
|
||||
### How to Add a DID in a Model
|
||||
|
||||
This requires a special setup.
|
||||
In order to get powertrain-build to collect DIDs,
|
||||
create a new mask called "DID", it can contain a simple inport followed by an outport block.
|
||||
|
||||
### Generated DID Files
|
||||
|
||||
In terms of DIDs, powertrain-build will generate two sets C code.
|
||||
The first set, named *VcDidDefinitions.c/h*, defines the DIDs in a struct and maps them to their hex IDs.
|
||||
The second set, named *VcDIDApi.c/h*, defines the functions for retrieving the DIDs.
|
||||
|
||||
## Using YAML Files
|
||||
|
||||
### How to Define an Event ID Name (YAML)
|
||||
|
||||
Regarding Simulink blocks, the setup is the same as with [CSV files](#how-to-add-event-reporting-in-a-model).
|
||||
|
||||
Additionally, metadata for DTCs need to be added to a DTC configuration file (*ConfigDocuments/DTCs.yaml*).
|
||||
|
||||
The content of the file should be a yaml dictionary mapping DTCs to their corresponding hex value (event ID).
|
||||
|
||||
Example of a DTC definition file:
|
||||
|
||||
```yaml
|
||||
{
|
||||
"VcModelDtcOne": 0x123ABC,
|
||||
"VcModelDtcTwo": 0xABC123,
|
||||
"VcModelDtcThree": 0xFFFFFF
|
||||
}
|
||||
```
|
||||
|
||||
powertrain-build will generate two files, *VcCoreSupplierAbstraction.c/h*.
|
||||
|
||||
The header file maps the function e.g. `Dem_SetEventStatus(EventName, EventStatus)` (from a custom code block)
|
||||
to a macro `VcCoreSupplierAbstraction_##EventName##_SetEventStatus(EventStatus)`.
|
||||
|
||||
The source file will contain all required DTC functions which in turn call the functions available in the target.
|
||||
|
||||
Example of *VcCoreSupplierAbstraction.h*:
|
||||
|
||||
```c
|
||||
#ifndef VCCORESUPPLIERABSTRACTION_H
|
||||
#define VCCORESUPPLIERABSTRACTION_H
|
||||
|
||||
/* Core API Supplier Abstraction */
|
||||
|
||||
#include "tl_types.h"
|
||||
#include "Rte_LVC.h"
|
||||
|
||||
/* enum EventStatus {passed=0, failed=1, prepassed=2, prefailed=3} */
|
||||
#define Dem_SetEventStatus(EventName, EventStatus) VcCoreSupplierAbstraction_##EventName##_SetEventStatus(EventStatus)
|
||||
|
||||
#include "PREDECL_CODE_ASIL_D_START.h"
|
||||
UInt8 VcCoreSupplierAbstraction_VcModelDtcOne_SetEventStatus(UInt8 EventStatus);
|
||||
UInt8 VcCoreSupplierAbstraction_VcModelDtcTwo_SetEventStatus(UInt8 EventStatus);
|
||||
UInt8 VcCoreSupplierAbstraction_VcModelDtcThree_SetEventStatus(UInt8 EventStatus);
|
||||
#include "PREDECL_CODE_ASIL_D_END.h"
|
||||
|
||||
#endif /* VCCORESUPPLIERABSTRACTION_H */
|
||||
```
|
||||
|
||||
Example of *VcCoreSupplierAbstraction.c*:
|
||||
|
||||
```c
|
||||
#include "VcCoreSupplierAbstraction.h"
|
||||
|
||||
#include "CVC_CODE_ASIL_D_START.h"
|
||||
UInt8 VcCoreSupplierAbstraction_VcModelDtcOne_SetEventStatus(UInt8 EventStatus)
|
||||
{
|
||||
Rte_Call_DTC_123ABC_VcModelDtcOne_SetEventStatus(EventStatus);
|
||||
return 0;
|
||||
}
|
||||
|
||||
UInt8 VcCoreSupplierAbstraction_VcModelDtcTwo_SetEventStatus(UInt8 EventStatus)
|
||||
{
|
||||
Rte_Call_DTC_ABC123_VcModelDtcTwo_SetEventStatus(EventStatus);
|
||||
return 0;
|
||||
}
|
||||
|
||||
UInt8 VcCoreSupplierAbstraction_VcModelDtcThree_SetEventStatus(UInt8 EventStatus)
|
||||
{
|
||||
Rte_Call_DTC_FFFFFF_VcModelDtcThree_SetEventStatus(EventStatus);
|
||||
return 0;
|
||||
}
|
||||
|
||||
#include "CVC_CODE_ASIL_D_END.h"
|
||||
```
|
||||
|
||||
**NOTE:** each of the *Rte_Call_DTC_\** functions must be present in the target.
|
||||
|
||||
### How to Define a DID (YAML)
|
||||
|
||||
Regarding Simulink blocks, the setup is the same as with [CSV files](#how-to-add-a-did-in-a-model).
|
||||
|
||||
Additionally, metadata for DIDs need to be added to a DID configuration file (*ConfigDocuments/DIDs.yaml*).
|
||||
Add the name of the file to the projects *ProjectCfg.json* file,
|
||||
by adding a new element `"didDefFile": "DIDs.yaml"` in the *ProjectInfo* section.
|
||||
|
||||
There are six available function calls for each DID.
|
||||
|
||||
* Read data function.
|
||||
* Min and max read data functions.
|
||||
* Condition check function.
|
||||
* Min and max condition check functions.
|
||||
|
||||
The metadata for each DID includes an ID and which of above functions should be generated or not including their respective data types.
|
||||
Note that the same ID cannot be used for a function type more than once, as this would generate the same function call (overwrite).
|
||||
There is one function type per DID function call, read_data, read_data_min, read_data_max, condition_check, condition_check_min and condition_check_max. The "nr_of_bytes" key is optional.
|
||||
|
||||
Example of a DID definition file:
|
||||
|
||||
```yaml
|
||||
{
|
||||
"dummy_did_one": {
|
||||
"id": "DA00",
|
||||
"data_type": "uint8",
|
||||
"nr_of_bytes": 1,
|
||||
"function_type": "read_data"
|
||||
},
|
||||
"dummy_did_two": {
|
||||
"id": "DA00",
|
||||
"data_type": "Dcm_NegativeResponseCodeType",
|
||||
"function_type": "condition_check"
|
||||
},
|
||||
"dummy_did_three": {
|
||||
"id": "DA01",
|
||||
"data_type": "uint8",
|
||||
"function_type": "read_data_max"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
powertrain-build will generate two files, *VcDIDAPI.c/h*.
|
||||
It contains the generated functions for each DID,
|
||||
based on the data from the DID definition file as well as the unit configuration json file.
|
||||
|
||||
Example of *VcDIDAPI.h*:
|
||||
|
||||
```c
|
||||
#ifndef VCDIDAPI_H
|
||||
#define VCDIDAPI_H
|
||||
|
||||
#include "tl_basetypes.h"
|
||||
#include "Rte_LVC.h"
|
||||
|
||||
#include "PREDECL_DISP_ASIL_D_START.h"
|
||||
extern CVC_DISP_ASIL_D Bool dummy_did_one;
|
||||
extern CVC_DISP_ASIL_D Bool dummy_did_two;
|
||||
extern CVC_DISP_ASIL_D Bool dummy_did_three;
|
||||
#include "PREDECL_DISP_ASIL_D_END.h"
|
||||
|
||||
#include "PREDECL_CODE_ASIL_D_START.h"
|
||||
void DID_DA00_Runnable_ReadData(uint8 *Data);
|
||||
void DID_DA00_Runnable_ConditionCheckRead(Dcm_NegativeResponseCodeType *ErrorCode);
|
||||
void DID_DA01_Runnable_MAX_ReadData(uint8 *Data);
|
||||
#include "PREDECL_CODE_ASIL_D_END.h"
|
||||
|
||||
#endif /* VCDIDAPI_H */
|
||||
```
|
||||
|
||||
Example of *VcDIDAPI.c*:
|
||||
|
||||
```c
|
||||
#include "VcDIDAPI.h"
|
||||
|
||||
#include "CVC_CODE_ASIL_D_START.h"
|
||||
void DID_DA00_Runnable_ReadData(uint8 *Data)
|
||||
{
|
||||
memcpy(Data, &dummy_did_one, 1);
|
||||
}
|
||||
void DID_DA00_Runnable_ConditionCheckRead(Dcm_NegativeResponseCodeType *ErrorCode)
|
||||
{
|
||||
memcpy(ErrorCode, &dummy_did_two, sizeof(Dcm_NegativeResponseCodeType));
|
||||
}
|
||||
void DID_DA01_Runnable_MAX_ReadData(uint8 *Data);
|
||||
{
|
||||
memcpy(Data, &dummy_did_three, sizeof(uint8));
|
||||
}
|
||||
#include "CVC_CODE_ASIL_D_END.h"
|
||||
```
|
||||
|
||||
**NOTE:** these functions must be present in the target.
|
||||
|
||||
## Notes
|
||||
|
||||
See [generateYamlInterfaceFile](../project_config.md#generateYamlInterfaceFile),
|
||||
which makes powertrain-build read different files and generates different versions of the files
|
||||
*VcDIDApi.c/h* and *VcCoreSupplierAbstraction.h*.
|
316
docs/target_link/enumerations.md
Normal file
@ -0,0 +1,316 @@
|
||||
# TargetLink Enumerations
|
||||
|
||||
-------------------------
|
||||
|
||||
[TOC]
|
||||
|
||||
As of TargetLink version 4.3, there is support for using enumerations in Simulink models and generated code.
|
||||
This section describes how to use this new feature.
|
||||
|
||||
## Defining an Enumeration
|
||||
|
||||
All enumerations must be defined as Matlab classes, inheriting from the _Simulink.IntEnumType_ class.
|
||||
These files should be placed in the same folder, e.g. _Models/Common/VcEnumDefinitions_.
|
||||
This makes them easy to find and keep unique.
|
||||
Unique enumeration definitions are required.
|
||||
The name of the enumeration must match the name of the file.
|
||||
|
||||
Matlab enumeration template:
|
||||
|
||||
```matlab
|
||||
classdef SomeEnumName < Simulink.IntEnumType
|
||||
%SOMEENUMNAME SomeEnumName enumeration
|
||||
|
||||
enumeration
|
||||
MemberOne(0)
|
||||
MemberTwo(1)
|
||||
MemberThree(2)
|
||||
end
|
||||
|
||||
methods (Static)
|
||||
function retVal = getDescription()
|
||||
retVal = 'SomeEnumName';
|
||||
end
|
||||
function retVal = getDefaultValue()
|
||||
retVal = SomeEnumName.MemberOne;
|
||||
end
|
||||
function retVal = getDataScope()
|
||||
retVal = 'Exported';
|
||||
end
|
||||
function retVal = addClassNameToEnumNames()
|
||||
retVal = true;
|
||||
end
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
## Using an Enumeration
|
||||
|
||||
When the enumeration is defined, it can be used in, for example, an inport or a constant block.
|
||||
Many TargetLink blocks accept enumeration type inputs, such as _TL\_MultiPortSwitch_ and _TL\_RelationalOperator_.
|
||||
|
||||
To get the enumeration in the code, the data type _IMPLICIT\_ENUM_ must be chosen in the _Type_ field,
|
||||
in the TargetLink block.
|
||||
Additionally, the name of the enumeration must be specified in the _Unit_ field in the TargetLink block,
|
||||
together with the prefix "-,$".
|
||||
For example, "-,$DtElecThermSt".
|
||||
Signals must specify the quantity "\_Enm\_" in the name, e.g. _sVcModelName\_Enm\_Dummy_.
|
||||
|
||||
### In- and Out-ports
|
||||
|
||||

|
||||
|
||||
### Constants
|
||||
|
||||
This sections provides examples for constants with different variable classes.
|
||||
|
||||
#### Default
|
||||
|
||||
This class only works on constants on the top most layer of the model.
|
||||
|
||||

|
||||
|
||||
#### CVC_VAR
|
||||
|
||||
This class generates the same code as the default class does.
|
||||
There is no need for a name as the code produces pure string values.
|
||||
|
||||

|
||||
|
||||
A CVC_VAR constant compared with an input of the same enumeration:
|
||||
|
||||
```c
|
||||
/* Relational: VcModelName/VcModelName/6_ControllerRequestForSecondRowWhenNotFourZoneCont
|
||||
rol/Relational Operator2 */
|
||||
SModelName10___ional_Operator2 = CLIMACFGFORNROFTSETG_NROFTSETG2 ==
|
||||
sVcModelNameTwo_Enm_CatcCfgForNrOfTSetg;
|
||||
```
|
||||
|
||||
#### CVC_CONST
|
||||
|
||||
This class generates a constant.
|
||||
The constant values does not come from the Matlab workspace, it does not exist in any \_par.m file.
|
||||
Instead, it is loaded in the memory as a Simulink class after running _Init\_PyBuild.m_.
|
||||
|
||||

|
||||
|
||||
A CVC_CONST constant compared with an input of the same enumeration:
|
||||
|
||||
```c
|
||||
if (cEnm_ClimaCfgForNrOfTSetg1_NrOfTSetg1 == sVcModelNameTwo_Enm_CatcCfgForNrOfTSetg) {
|
||||
/* Switch: VcModelName/VcModelName/6_ControllerRequestForSecondRowWhenNotFourZoneCo
|
||||
ntrol/Switch5
|
||||
# combined # Switch: VcModelName/VcModelName/7_ManualOverrideOfActuatorRequest/S
|
||||
witch1 */
|
||||
SModelName11_Switch1 = SModelName9_Switch2[0];
|
||||
}
|
||||
```
|
||||
|
||||
Definition:
|
||||
|
||||
```c
|
||||
CVC_CONST ClimaCfgForNrOfTSetg cEnm_ClimaCfgForNrOfTSetg1_NrOfTSetg1 =
|
||||
CLIMACFGFORNROFTSETG_NROFTSETG1; /*
|
||||
Unit: -,$ClimaCfgForNrOfTSetg
|
||||
MIN/MAX: 0 .. 0 */
|
||||
```
|
||||
|
||||
#### CVC_CAL
|
||||
|
||||
This class generates a calibratable constant.
|
||||
|
||||

|
||||
|
||||
A CVC_CAL constant compared with an input of the same enumeration:
|
||||
|
||||
```c
|
||||
/* Relational: VcModelName/VcModelName/6_ControllerRequestForSecondRowWhenNotFourZoneCont
|
||||
rol/Relational Operator1 */
|
||||
SModelName10___ional_Operator1 = sVcModelNameTwo_Enm_CatcCfgForNrOfTSetg ==
|
||||
cVcModelName_Enm_ClimaCfgForNrOfTSetg1_NrOfTSetg3;
|
||||
}
|
||||
```
|
||||
|
||||
Definition:
|
||||
|
||||
```c
|
||||
CVC_CAL ClimaCfgForNrOfTSetg cVcModelName_Enm_ClimaCfgForNrOfTSetg1_NrOfTSetg3 =
|
||||
CLIMACFGFORNROFTSETG_NROFTSETG3; /* Unit: -,$ClimaCfgForNrOfTSetg */
|
||||
```
|
||||
|
||||
Note that the block name in this example starts with "Enm_".
|
||||
|
||||
## Generated Files
|
||||
|
||||
This section describes what happens when TargetLink generates source files.
|
||||
|
||||
### Code
|
||||
|
||||
When TargetLink generates code, it creates a new file, e.g. _udt\_ModelName.h_,
|
||||
where it defines all enumerations which the model uses.
|
||||
The text values of the enumeration members are used in the code.
|
||||
|
||||
Code snippets:
|
||||
|
||||
udt\_ModelName.h
|
||||
|
||||
``` c
|
||||
/**************************************************************************************************\
|
||||
***
|
||||
*** Simulink model : VcModelName_OPortMvd
|
||||
*** TargetLink subsystem : VcModelName_OPortMvd/VcModelName
|
||||
*** Codefile : udt_ModelName.h
|
||||
***
|
||||
*** Generation date: 2020-11-30 16:10:50
|
||||
***
|
||||
*** TargetLink version : 4.3p3 from 16-Oct-2018
|
||||
*** Code generator version : Build Id 4.3.0.27 from 2018-09-24 17:55:03
|
||||
\**************************************************************************************************/
|
||||
|
||||
#ifndef UDT_MODELNAME_H
|
||||
#define UDT_MODELNAME_H
|
||||
|
||||
#include "tl_basetypes.h"
|
||||
|
||||
typedef enum DtElecThermSt_tag {
|
||||
DTELECTHERMST_DTELECCOOLG = 0,
|
||||
DTELECTHERMST_DTELECPASCOOLG = 1,
|
||||
DTELECTHERMST_DTELECHEATG = 2,
|
||||
DTELECTHERMST_DTELECPASHEATG = 3,
|
||||
DTELECTHERMST_DTELECACTVHEATG = 4,
|
||||
DTELECTHERMST_DTELECPASACTVHEATG = 5,
|
||||
DTELECTHERMST_DEGAS = 6,
|
||||
DTELECTHERMST_FAILSAFE = 7
|
||||
} DtElecThermSt; /* Description: Enumeration type derived from Simulink type DtElecThermSt */
|
||||
```
|
||||
|
||||
VcModelName.h
|
||||
|
||||
``` c
|
||||
/**************************************************************************************************\
|
||||
CVC_EXT: CVC external interface input variables | Width: N.A.
|
||||
\**************************************************************************************************/
|
||||
CVC_EXT DtElecThermSt sVcModelNameThree_Enm_DtElecThermSt; /*
|
||||
Unit: -,$DtElecThermSt
|
||||
Description: Electric drive coolant circuit thermal status: 'DtElecPasCoolg', 'DtElecPasHeatg', '
|
||||
DtElecPasActvHeatg', 'DtElecPas' */
|
||||
CVC_EXT HvBattThermSt sVcModelNameThree_Enm_HvBattThermSt; /*
|
||||
Unit: -,$HvBattThermSt
|
||||
Description: HV battery coolant circuit thermal status: 'HvBattOff', 'HvBattActvHeatgFromClima',
|
||||
'HvBattBal', 'HvBattActvCoolg', 'HvBattPasCoolg', 'HvBattPasActvCoolg', 'HvBattPasHeatg', 'HvBatt
|
||||
PasActvHeatgFromClima', 'HvBattPasActvHeatgFromDtElec', 'HvBattPasActvHeatgFromDtElecAndClima' */
|
||||
```
|
||||
|
||||
VcModelName.c
|
||||
|
||||
```c
|
||||
/* Multiport switch: VcModelName/VcModelName/8_VlvCtrl/81_V1RadiatorBypassValveControl/
|
||||
MultiportSwitch3 */
|
||||
switch (sVcModelNameThree_Enm_DtElecThermSt) {
|
||||
case DTELECTHERMST_DTELECPASHEATG: {
|
||||
SModelName115_MultiportSwitch3 = 1;
|
||||
break;
|
||||
}
|
||||
case DTELECTHERMST_DTELECPASACTVHEATG: {
|
||||
SModelName115_MultiportSwitch3 = 1;
|
||||
break;
|
||||
}
|
||||
default: {
|
||||
SModelName115_MultiportSwitch3 = 0;
|
||||
break;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### A2L Files
|
||||
|
||||
The unit A2L-files are updated automatically with enumeration definitions.
|
||||
|
||||
### JSON Configuration Files
|
||||
|
||||
The data type of each enumeration type signal will be the name of the corresponding enumeration.
|
||||
Note that the data type is set to _IMPLICIT\_ENUM_ in the TargetLink block.
|
||||
|
||||
The default value of the enumeration will be inserted into the configuration file,
|
||||
based on the return value of _getDefaultValue()_ in the enumeration definition m-file.
|
||||
|
||||
## powertrain-build
|
||||
|
||||
When powertrain-build builds a project, see [Detailed build options](../powertrain_build.md#detailed-build-options),
|
||||
it will parse all _udt\_VcModel.h_ and json configuration files
|
||||
in order to get information about used enumerations in the project.
|
||||
|
||||
This information is used to:
|
||||
|
||||
1. Make sure that the same model does not define the same enumeration twice.
|
||||
1. This is probably unnecessary. Two enumerations with the same name cannot exist in Simulink at the same time.
|
||||
1. Make sure that two (or more) models does not define the same enumeration differently.
|
||||
1. This can occur if an enumeration definition is updated without updating generated files
|
||||
based on the old definition.
|
||||
1. Define missing enumeration type signals in _VcDummy\_spm.c/h_.
|
||||
|
||||
Interface enumerations are also compared with the parsed project enumerations to make sure they are defined correctly.
|
||||
|
||||
### Old default value extraction
|
||||
|
||||
Below method was used before the default values were inserted into the json configuration file, during code generation.
|
||||
It will stay as a fall back for a while, until all model-configuration files have been updated with the default value.
|
||||
|
||||
To be able to extract the default values for each enumeration powertrain-build must know the path to the common enumeration class folder.
|
||||
The path is set with the key "enumDefDir" in the _ProjectCfg.json_ file.
|
||||
|
||||
```json
|
||||
{
|
||||
"ConfigFileVersion": "0.2.1",
|
||||
"BaseConfig" : "../../../ConfigDocuments/BaseConfig.json",
|
||||
"ProjectInfo" : {
|
||||
"yamlInterface": true,
|
||||
"projConfig" : "Dummy",
|
||||
"a2LFileName": "SPM.a2l",
|
||||
"ecuSupplier" : "Dummy",
|
||||
"ecuType" : "",
|
||||
"unitCfgDeliveryDir": "./output/UnitCfgs",
|
||||
"configDir": "ConfigDocuments",
|
||||
"prjCodeswitches": "Codeswitch_Setup*.csv",
|
||||
"commonSrcDir": "../../../Models/Common/pybuild_src",
|
||||
"prjUnitSrcDir": "../../../Models/*/Vc*/pybuild_src",
|
||||
"prjUnitCfgDir": "../../../Models/*/Vc*/pybuild_cfg",
|
||||
"prjUnitMdlDir": "../../../Models/*/Vc*",
|
||||
"enumDefDir": "../../../Models/Common/VcEnumDefinitions"
|
||||
.
|
||||
.
|
||||
.
|
||||
```
|
||||
|
||||
## Requirements
|
||||
|
||||
* Enumerations must be defined as Matlab classes, inheriting from the _Simulink.IntEnumType_ class.
|
||||
* Enumeration class files must have the same name as the enumeration it defines.
|
||||
* Enumeration class files must be placed in a common folder.
|
||||
* Enumerations are uniquely defined.
|
||||
* To get the enumeration in the code, the data type _IMPLICIT\_ENUM_ must be selected in the TargetLink block.
|
||||
* The name of the enumeration must be specified in the _Unit_ field in the TargetLink block, prefixed with "-,$".
|
||||
* Signals must specify the quantity "\_Enm\_" in the name.
|
||||
* Interface enumerations must be defined in the _interface\_data\_types.yml_ file, located in the _conf.local_ project folder.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
When TargetLink generates the A2L-file, it must know the underlying data type to use.
|
||||
The underlying data type is calculated based on the number of enumeration members and their values.
|
||||
When powertrain-build parses the enumeration it does not know about the underlying data type.
|
||||
Therefore, it must calculate the underlying data type too. This is done in a separate function.
|
||||
|
||||
The underlying data type calculations are based on how the compiler would choose a fitting data type,
|
||||
given an enumeration. The smallest underlying data type which can be chosen is an 8 bit integer, two bytes.
|
||||
Some compilers may perform optimization using only one byte. If the software compiles enumerations using one byte,
|
||||
while the A2L-files states they are two bytes, what will happen when calibrating the software?
|
||||
|
||||
What is the underlying data type of enumerations entering an app?
|
||||
CS software homepage (based on ARXML from a database?) seems to specify signed 8 bit integers.
|
||||
Can this cause issues?
|
||||
|
||||
## Summary
|
||||
|
||||
* If one of the functions for calculating the underlying data type is changed, the other must be changed too.
|
||||
* Potential software calibration issues, A2L versus compile sofware enumeration sizes.
|
||||
* Actual data types of enumerations entering an app?
|
88
docs/target_link/function_block.md
Normal file
@ -0,0 +1,88 @@
|
||||
# TargetLink Function Blocks
|
||||
|
||||
-----------------------------
|
||||
|
||||
[TOC]
|
||||
|
||||
## Why
|
||||
|
||||
To insert a function block in a subsystem will insert a function call in the C code generated from the model.
|
||||
This will reduce the complexity numbers, increase testability and protect against memory problems if there is an interrupt and the function needs to be saved temporary to the memory.
|
||||
|
||||
## How
|
||||
|
||||
### Insert FUNCTION Block
|
||||
|
||||
Insert a green FUNCTION block in the subsystem.
|
||||
Double click the green block and set "Step function name" to `$N_$B` and "Init function name" to `INIT_$N_$B`.
|
||||
|
||||

|
||||
|
||||
## Important Aspects in the Model
|
||||
|
||||
There are two important aspects that need attention.
|
||||
|
||||
### Signal Feedback
|
||||
|
||||
When using feedback from a subfunction block to another subfunction of function in the model,
|
||||
it is important to use the unit delay block when one uses function blocks.
|
||||
Strangely one also needs a rename block after, since the unit delay block in this case can not have a readable signal configuration.
|
||||
|
||||
### Model Output Signals
|
||||
|
||||
Model output signals, prefix starting with *sVc* and *yVc*, needs to have copies that are local readables,
|
||||
prefix *rVc* and *xVc*, otherwise they will be removed by the current code optimization.
|
||||
|
||||
## Code Example
|
||||
|
||||
``` c
|
||||
Void VcModelName(Void)
|
||||
{
|
||||
/* SLStaticLocalInit: Default storage class for static local variables with initvalue | Width: 8
|
||||
*/
|
||||
static Bool X_SModelName2_UnitDelay1 = 0;
|
||||
|
||||
/* call of function: VcModelName/VcModelName/2_SignalCalc */
|
||||
VcModelName_2_SignalCalc();
|
||||
|
||||
/* VcModelName/VcModelName/RenameSignal/InPort */
|
||||
xVcModelName_B_ConvEffCmplt = X_SModelName2_UnitDelay1;
|
||||
|
||||
/* call of function: VcModelName/VcModelName/1_Entry */
|
||||
VcModelName_1_Entry();
|
||||
|
||||
/* call of function: VcModelName/VcModelName/3_Evaluation */
|
||||
VcModelName_3_Evaluation();
|
||||
|
||||
/* TargetLink outport: VcModelName/sVcModelName_rt_CnvnMeasd1 */
|
||||
sVcModelName_m_NoxUs = SModelName44_Switch;
|
||||
|
||||
/* call of function: VcModelName/VcModelName/4_Judgement */
|
||||
VcModelName_4_Judgement();
|
||||
|
||||
}
|
||||
#include "MemMap_CVC_STOP.h"
|
||||
|
||||
|
||||
/**************************************************************************************************\
|
||||
*** FUNCTION:
|
||||
*** VcModelName_1_Entry
|
||||
***
|
||||
*** DESCRIPTION:
|
||||
***
|
||||
***
|
||||
*** PARAMETERS:
|
||||
*** Type Name Description
|
||||
*** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
***
|
||||
*** RETURNS:
|
||||
*** Void
|
||||
***
|
||||
*** SETTINGS:
|
||||
***
|
||||
\**************************************************************************************************/
|
||||
#include "MemMap_CVC_START.h"
|
||||
|
||||
Void VcModelName_1_Entry(Void)
|
||||
{
|
||||
```
|
262
docs/target_link/functions.md
Normal file
@ -0,0 +1,262 @@
|
||||
# TargetLink Look-up and Pre-lookup Functions
|
||||
|
||||
---------------------------------------------
|
||||
|
||||
[TOC]
|
||||
|
||||
Some of the model blocks generates specific c-functions.
|
||||
Examples of this are the lockup and the pre-lockup blocks as well as shared-libray blocks (custom code generation units).
|
||||
The functions were generated once as c/h-files at one given time and are now called when used by the model functions.
|
||||
The files are located under `Models/Common/pybuild_src`.
|
||||
The look-up table uses a table index function and a table interpolation function.
|
||||
TargetLink offers different Look-up tables in the TL library (tllib).
|
||||
|
||||
## Settings for Table Index Functions
|
||||
|
||||
The table index function have a number of settings defining the input and output variable types,
|
||||
the type of search mechanism for finding the index and output configuration.
|
||||
All of these settings define a specific c-function.
|
||||
|
||||
Examples of the settings and their meaning are given below.
|
||||
|
||||
### Table Index Search Methods (excerpt from the dSPACE Help)
|
||||
|
||||
* Linear search, start low.
|
||||
`A linear search is implemented from the lowest end of the abscissa. The algorithm will go through the abscissa entries until a value higher than the input value is found. This search is simple and fast if the table is not too large.`
|
||||
* Linear search, start high.
|
||||
`A linear search is implemented from the highest end of the abscissa. The algorithm will go through the abscissa entries until a value lower than the input value is found. This search is simple and fast if the table is not too large.`
|
||||
* Local search.
|
||||
`The search starts at the index where the previous table value was found. Local searches can be slightly slower than linear searches due to the more complex code. This is recommended when the table inputs are smooth and do not change abruptly.`
|
||||
* Binary search.
|
||||
`The search area is divided into two halves, depending on whether the input value is in the upper or lower part. The iterations are repeated until the adjacent entries of the specified input value are found. This search is fast, especially in large tables, but the code is more complex.`
|
||||
|
||||

|
||||
|
||||
If the input data varies little or the change is smooth in relation to how often the function is calculated the `Local Search` is preferable.
|
||||
E.g. temperatures, torques etc.
|
||||
|
||||
### Output Configurations
|
||||
|
||||
* Output only the index.
|
||||
`Only the index signal is written to the block output. The block output is a scalar integer value in the range of the data type selected.`
|
||||
* Separate output for index and fraction.
|
||||
`Both the index and the fraction are written to the block output as separate signals. The block output is a vector with two elements, where the first element is the index and the second element is the fraction.`
|
||||
|
||||
**Warning:** If the option `Output only the index` is chosen, only the table indices are output which will limit the resolution.
|
||||
This may not be wanted if e.g. the output shall be use in an interpolation map afterwards.
|
||||
The calculation resource is though reduced.
|
||||
|
||||

|
||||
|
||||
### Variable Type Definitions
|
||||
|
||||
Different variable data types are defined in the dSPACE data dictionary.
|
||||
The most commonly used are `Float32, Unit32, Int32, UInt16, Int16, UInt8, Int8, Bool`.
|
||||
The breakpoint type as well as the output type can be defined in the table index function.
|
||||
The input type is also influencing the table index function.
|
||||
|
||||

|
||||
|
||||
**All the above settings decide the logic in the table index function.**
|
||||
|
||||
## Settings for Table Interpolation Functions
|
||||
|
||||
The interpolation function also have the same settings defining the input and output variable types as for table index functions
|
||||
but it is also possible to define if interpolation shall be applied or not as well as dimension.
|
||||
All of these settings define a specific c-function.
|
||||
Examples of the settings and their meaning are given below.
|
||||
|
||||
### Activating Interpolation
|
||||
|
||||
The interpolation function is called only if interpolation is applied.
|
||||
If deactivated, only an array in the code containing the indices is necessary.
|
||||
|
||||
### Dimension of the Interpolation Table
|
||||
|
||||
Defines the dimension of the table. 1D or 2D are supported.
|
||||
|
||||
### Distances Between Table Entries Less Than Half of Implemented Range
|
||||
|
||||
Targetlink provides the possibility to save memory if you can assure that the distance between the table entries are within the scaling range.
|
||||
If the option is deactivated the targetlink will execute the interpolation calculation in double width of the operands, to avoid data loss.
|
||||
|
||||
**WARNING: Activate with extreme care! When this is chosen, be aware that that calibration can change the table entries thereby causing e.g. an overflow.**
|
||||
|
||||
```txt
|
||||
Example
|
||||
The difference between two Int16 numbers can be greater than the maximum number
|
||||
which can be represented in Int16.
|
||||
30000-(-30000)=60000 > 32767
|
||||
```
|
||||
|
||||

|
||||
|
||||
## Creation of New Index and Interpolation Tables
|
||||
|
||||
Due to the different settings available there exists many table functions.
|
||||
If a suitable table function is found it is re-used.
|
||||
|
||||
A table function is re-used if:
|
||||
|
||||
* Input/output data types are identical.
|
||||
* The search algorithms are identical.
|
||||
* Interpolation Using Prelookup blocks.
|
||||
* Interpolation is on/off for all tables.
|
||||
* The number of dimensions is identical.
|
||||
* The distances between table entries less than half of implemented range checkbox is selected in the tables concerned.
|
||||
* PreLook-Up Index Search blocks.
|
||||
* breakpoint data (e.g. data type).
|
||||
* The output configuration is identical.
|
||||
|
||||
If any of the above conditions are different another table function is needed.
|
||||
For many settings there already exists a generated table function.
|
||||
They are allocated under `Models/Common/pybuild_src` but if a new setting is detected the c-code for the new function needs to be generated.
|
||||
|
||||
In TargetLink 4.3 and onwards some of the operations needed in the index and interpolation tables have been integrated in TargetLink´s `Fixed Point Library`.
|
||||
For example `DIV` (division), `MUL` (multiplication), `SHL` (shift left <<) or `SHR`(shift right >>).
|
||||
The division/multiplication operations exist for all possible input and output data types.
|
||||
|
||||
As a result, if a new index or interpolation function is needed the functions are created using the Targetlink's fixed point library.
|
||||
|
||||
As the implementation of the new library would affect the different build scripts,
|
||||
it has been decided to continue with the old structure ofthe index and interpolation functions and not use the fixed point library.
|
||||
This though requires some manual editing of a newly created functions.
|
||||
|
||||
### Basics on Index Search and Interpolation
|
||||
|
||||
The index search outputs a fraction apart from the index, if chosen.
|
||||
|
||||
**fraction:** f = (x - x[i])/(x[i+1] - x[i])
|
||||
|
||||
which is then used by the interpolation block.
|
||||
|
||||
**interpolation:** z = z[i] + f*(z[i+1] - z[i])
|
||||
|
||||
**Note:** x[i] represents the table indices, x the input value for the index search and z[i] the interpolation values with z as the output.
|
||||
|
||||
The above formulas are easily recognized in the c-code of the functions.
|
||||
|
||||
### Steps for Adding a New Table Function
|
||||
|
||||
A couple of steps are necessary when including a new index/interpolation function.
|
||||
During code generation TargetLink automatically creates the c/h-files for the function.
|
||||
It also includes the new function automatically in the models c-file.
|
||||
|
||||
The following steps are though necessary in order to edit and include the new table function:
|
||||
|
||||
* Include the header file of the table function in the project configurations common files `Projects\<your project>`.
|
||||
* Update the c-file of the table function acccordingly, see below.
|
||||
* Add the new files to the repository `Models/Common/pybuild_src/(Tab...)` together with your commit.
|
||||
|
||||
## Editing the Created C Code Files
|
||||
|
||||
To give some insight in the necessary steps two examples are given on how to edit an index table function and an interpolation function.
|
||||
|
||||
### Editing a New Table Index Function
|
||||
|
||||
In this case, it is the following function:
|
||||
|
||||

|
||||
|
||||
In the example the input `x` and the table indices `x_table` are UInt32, the output though shall be UInt8.
|
||||
|
||||
**1. The reference to the fixed point library shall be removed in the c-file.**
|
||||
|
||||

|
||||
|
||||
**2. Correction of the fraction calculation. The formula above for calculation of the fraction is implemented in the code as below (left side).**
|
||||
|
||||

|
||||
|
||||
The naming of the libray functions gives a hint of what it does e.g. `C__U64SHLU32C6_LT32` is a left shift operation `SHL` of a UInt32 input, producing an UInt64 output.
|
||||
|
||||
The input is (x-x_table[0]), refer to (x - x[i]) in the fraction formula.
|
||||
The usage of left shift and type casting to double width is needed to be sure to avoid a data loss when subtracting.
|
||||
See [above](#distances-between-table-entries-less-than-half-of-implemented-range).
|
||||
|
||||
**Step-by-step:**
|
||||
|
||||
Converting the numerator part of the fraction formula:
|
||||
|
||||
```c
|
||||
(UInt32) (x - x_table[0]) : Declaring that the input is UInt32
|
||||
|
||||
(UInt64) (UInt32) (x - x_table[0]) : Type casting to UInt64 (to avoid data loss)
|
||||
|
||||
((UInt64) (UInt32) (x - x_table[0])) << 8 : Left shift 8 bits
|
||||
```
|
||||
|
||||
The second library function that is used is `C__U8DIVU64U32` i.e. dividing `DIV` a UInt64 operator with UInt32 operator producing an UInt8 output.
|
||||
The fraction which is defined as irx[1] shall be output as UInt8 according to the function call in this case.
|
||||
|
||||
Declaring the denominator:
|
||||
|
||||
```c
|
||||
(UInt32) (x_table[1] - x_table[0]) : Declaring that the denominator is UInt32
|
||||
```
|
||||
|
||||
Calculation of the fraction (irx[1]):
|
||||
|
||||
Performing the division:
|
||||
|
||||
```c
|
||||
(((UInt64) (UInt32) (x - x_table[0])) << 8) / ((UInt32) (x_table[1] - x_table[0]))
|
||||
```
|
||||
|
||||
Assuring no data loss (using double width, UInt64):
|
||||
|
||||
```c
|
||||
((UInt64)(((UInt64) (UInt32) (x - x_table[0]) << 8)) / ((UInt32) (x_table[1] - x_table[0])))
|
||||
```
|
||||
|
||||
Type casting to Uint8:
|
||||
|
||||
```c
|
||||
irx[1] = (UInt8) ((UInt64)(((UInt64) (UInt32) (x - x_table[0]) << 8)) / ((UInt32) (x_table[1] - x_table[0])))
|
||||
```
|
||||
|
||||
**Removal of unused static variables.**
|
||||
|
||||
The fixed library functions needs to create some local variabels that are not needed when the calculation is performed in one step.
|
||||
|
||||

|
||||
|
||||
### Editing a New Interpolation Function
|
||||
|
||||
In this example we look into a 2D look-up table.
|
||||
In order to calculate the output in this case, three subsequent interpolations needs to be performed.
|
||||
See the below picture (excerpt from dSpace Help).
|
||||
|
||||

|
||||
|
||||
The example funtion is
|
||||
|
||||

|
||||
|
||||
It has two UInt8 input axis `irx[2]` and `iry[2]` and an UInt32 output.
|
||||
As seen above, three interpolations are needed in the function considering the inclination of the x- and y-curve using
|
||||
a multiplication function `C__U64MULU32U16`for two UInt32 variables with an UInt64 output (using double width to avoid data loss).
|
||||
|
||||
In the fixed point library, Targetlinks needs to use a multiplication `C__U64MULU32U16`and shift right `C__U32SHRU64C6_LT32` to solve the interpolation.
|
||||
The steps are the same as in the above example:
|
||||
|
||||
**1. The reference to the fixed point library shall be removed in the c-file.**
|
||||
|
||||

|
||||
|
||||
**2. Correction of the interpolation calculation.**
|
||||
|
||||

|
||||
|
||||
**3. Removal of unused static variables.**
|
||||
|
||||

|
||||
|
||||
## dSpace Help topics for deep dive
|
||||
|
||||
In the dSpace Help there is more in-depth information. Please search for the text below and you will find the topics.
|
||||
|
||||
* Basics on Applying Output Calculation Methods (Lookup Methods).
|
||||
* Basics on Applying Input Evaluation Methods (Search Methods).
|
||||
* Table Function Names (Prelookup Block).
|
||||
* Table Function Names (Interpolation Using Prelookup Block).
|
182
docs/target_link/naming_convention.md
Normal file
@ -0,0 +1,182 @@
|
||||
# Naming convention
|
||||
|
||||
-------------------
|
||||
|
||||
[TOC]
|
||||
|
||||
`<Type><Module>_<Quantity>_<Description>`
|
||||
|
||||
## Type
|
||||
|
||||
Type is indicated by the first letter, like in **s**VcEc_D_EngState.
|
||||
|
||||
* **y** = global bool (model interface to suroundings).
|
||||
* **x** = local bool (internal model signals).
|
||||
* **s** = global variable, non bool (float, uint ...).
|
||||
* **r** = local variable non bool.
|
||||
* **c** = constant.
|
||||
* **t** = table.
|
||||
* **m** = map.
|
||||
|
||||
## Prefix Two
|
||||
|
||||
For example s**Vc**Ec_D_EngState.
|
||||
Original meaning was **V**ehicle **C**ontrol.
|
||||
In Volvo Cars, it is today used to signify that the signal is defined by VCC.
|
||||
|
||||
## Module
|
||||
|
||||
For example sVc**Ec**_D_EngState.
|
||||
Shows the signal origin.
|
||||
Insignal from supplier software partition uses **Ec** (Engine control), **Di** (Driver interface), **Bc** (Brake control).
|
||||
Outsignal use the model name, for example *VcDeScl* will have out signals named *sVc**DeScl**\_X\_\**.
|
||||
|
||||
## Quantity
|
||||
|
||||
See table. You can find the allowed abbreviations in the file SPM_Units.xls in the ConfigDocuments folder in your project.
|
||||
|
||||
| Abbreviation | Meaning | Standard Unit |
|
||||
|--------------|------------------------------------------|-----------------------|
|
||||
| a | Acceleration | m/s2 |
|
||||
| ad | Deriv of Acc | m/s3 |
|
||||
| an | Angle | CA, deg, rad |
|
||||
| and | Angle/s | CA/s, deg/s, rad/s |
|
||||
| Ar | Area | m2, mm2 |
|
||||
| B | Boolean, flag 0/1 | - |
|
||||
| D | Discrete (enumeration type) | - |
|
||||
| E | Energy | J, kJ, kWh, mWh, Wh |
|
||||
| ef | Efficiency | - |
|
||||
| Enm | Enumeration (string type, implicit enum) | - |
|
||||
| Eta | Viscosity Dynamic | mPa s, Pa s |
|
||||
| F | Force | N |
|
||||
| fac | Factor | - |
|
||||
| Fd | Force Rate | N/s |
|
||||
| fq | Frequency | Hz |
|
||||
| Gear | Gear | - |
|
||||
| I | Current | A, mA, uA |
|
||||
| Id | Current Rate | A/s |
|
||||
| J | Inertia | kgm2 |
|
||||
| L | Distance, Length | m, km, mm |
|
||||
| lam | lambda | - |
|
||||
| lk | Distance, Length | m, km |
|
||||
| m | Mass | g, kg, mg, mg/stk |
|
||||
| m | Mass per Revolution | g/rev |
|
||||
| md | Massflow | g/s, kg/h, kg/s, mg/s |
|
||||
| mu | Viscosity Kinematic | cSt, m2/s |
|
||||
| n | Revolution Speed Number | rpm, krpm, rps |
|
||||
| nd | Revolution Acceleration | rpm/s |
|
||||
| p | Pressure | bar, hPa, kPa, MPa |
|
||||
| pd | Pressure Rate | kPa/s |
|
||||
| Pw | Power | W, kW |
|
||||
| Pwd | Power Rate | kW/s |
|
||||
| Q | Flow | l/h, l/min, l/s, m3/h |
|
||||
| q | Quantity | mg, mg/stk |
|
||||
| Qd | Heat Change | |
|
||||
| Qf | Quality Flag | - |
|
||||
| R | Electrical Resistance | mOhm, Ohm |
|
||||
| rho | Density | - |
|
||||
| rt | Ratio | - |
|
||||
| rtd | Change of Ratio | 1/s |
|
||||
| t | Time | s, min, ms, ns, us |
|
||||
| tc | Time Constant | s |
|
||||
| Te | Temperature | deg C, K |
|
||||
| Ted | Temperature Change | deg C/s |
|
||||
| Tq | Torque | Nm |
|
||||
| Tqd | Torque Rate | Nm/s2 |
|
||||
| Tqi | Accumulated Torque Over Time | Nms |
|
||||
| ts | Sample Time | s |
|
||||
| U | Voltage | V |
|
||||
| v | Velocity | km/h, m/s, mph |
|
||||
| vi | Accumulated Speed Fault Over Time | m/s s |
|
||||
| vol | Volume | cm3, l |
|
||||
| w | Angular Velocity | rad/s |
|
||||
| wd | Angular Velocity Rate | rad/s2 |
|
||||
| X | Share | % |
|
||||
| xb | Burned Fraction | - |
|
||||
| Xd | Change of Share | %/s |
|
||||
| Xi | Accumulated Percentage Over Time | %s |
|
||||
| Z | Non Standard Quantity | any |
|
||||
| Z | Concentration | ppm |
|
||||
| Zd | Non Standard Quantity Change | any |
|
||||
|
||||
## Description
|
||||
|
||||
It can be useful to look at the AUTOSAR name conventions, that might be the only useful from Autosar.
|
||||
An AUTOSAR name consists of four parts, see table.
|
||||
|
||||

|
||||
|
||||
### Structure
|
||||
|
||||

|
||||
|
||||
Example:
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
The subfunction of a model shall be seen as a ”Device”,
|
||||
e.g. EgrMonr for the Egr Flow monitor, EgrClrMonr for the Egr Cooler monitor etc.
|
||||
If the model does not have sub functions, the Device can be chosen according to the standard.
|
||||
|
||||

|
||||
|
||||
Usually quantity and position.
|
||||
|
||||
* MFlw – Mass Flow.
|
||||
* VolFlw – Volume Flow.
|
||||
* P – Pressure.
|
||||
* T – Temperature.
|
||||
* Lam – Lambda.
|
||||
* Tq – Torque.
|
||||
* Ag – Angle.
|
||||
* Ar – Area.
|
||||
* Pos – Position.
|
||||
* Pwr – Power.
|
||||
* Ti – Time.
|
||||
* U – Volatge.
|
||||
* I – Electric Current.
|
||||
* Rat – Ratio (duty cycle ratio).
|
||||
|
||||
There are more, see AUTOSAR.
|
||||
|
||||
For example PAmb (Ambient pressure), TIntk (Temperature in the Intake), TDs (Temp Downstream) and MFlwUs (Mass Flow Upstream).
|
||||
|
||||

|
||||
|
||||
Calculated Signals.
|
||||
|
||||
* Sp – Setpoint: Base mappning (MR also uses ”Req” – Requested).
|
||||
* Tar – Target: Limited Setpoint values.
|
||||
* Est – Estimated: An estimation of a value. E.g. rVcAesObd_T_SupChrgrMonrTDsEst.
|
||||
* Raw – Raw – Unprocessed sensor data.
|
||||
|
||||
Replacement Values.
|
||||
|
||||
* Rvlu – Replacement value.
|
||||
|
||||
Running Conditions.
|
||||
|
||||
The limits for determening running conditions shall use the following naming: [Hi/Lo/Min/Max]EnaLim.
|
||||
E.g. *EgrMonrAmbPMinEnaLim*, *SupChrgrMonrPDrpLoEnaLim* [Super Charger Pressure Drop Low Enable Limit].
|
||||
Boolean result from the limits shall use the Condition ”Enable” – ”Ena”.
|
||||
E.g. *EgrMonrAmbPMinEna*, *SupChrgrMonrPDrpLoEna*.
|
||||
|
||||
Test Values.
|
||||
|
||||
The test values shall use the following naming: [Hi/Lo/Min/Max]TstVlu.
|
||||
E.g. *EgrMonrArMinTstVal* [Egr Monitor Area Min Test Value],
|
||||
*SupChrgrMonrPTstVal* [Super Charger Pressure Test Value].
|
||||
|
||||
The completion of a test value calculation shall be named: [Hi/Lo/Min/Max]TstVluCmplt.
|
||||
E.g. *EgrMonrArMinTstValCmpl* [Egr Monitor Area Min Test Value Complete],
|
||||
*SupChrgrMonrPTstValCmpl* [Super Charger Pressure Test Value Complete].
|
||||
|
||||
Error/Ok information faults shall be called "Errors", short name is "Err".
|
||||
Passed shall be called Ok (Ok).
|
||||
Determening faults conditions: "Error Threshold", i.e. the condition shall be [Hi/Lo/Min/Max]ErrThd.
|
||||
E.g. *EgrMonrArErrThd*, *BoostMonrPHiErrThd*.
|
||||
|
||||
Monitor Error Flag - \*Err, e.g. *EgrMonrArErr*.
|
||||
Monitor Pass Flag – \*Ok, e.g. *EgrMonrArOk* [Egr Area Ok], *VVTMonrPosnMaxOk* [VVT Position Max Ok].
|
298
docs/target_link/non_volatile_memory.md
Normal file
@ -0,0 +1,298 @@
|
||||
# Overview NVM
|
||||
|
||||
--------------
|
||||
|
||||
[TOC]
|
||||
|
||||
Non-volatile memory (NVM) is used when data needs to be stored long-term persistently.
|
||||
Examples of NVM variables are different types of adaption values for actuators/sensors or specific functions,
|
||||
e.g. for monitoring purposes which need to follow the behavior of the software/functionality over the lifecycle of the vehicle.
|
||||
|
||||
There are different concepts for storing NVM variables.
|
||||
One way is to save the data to random-access memory (RAM) during the execution of the application software and
|
||||
then during the afterun (end of the driving cycle), save this RAM-mirror to a specific area in the flash memory.
|
||||
Another way is to allocate a specific area, which is supplied over the vehicle battery, in RAM to which the parameters are allocated.
|
||||
|
||||
At initialization this area is then read back into RAM-mirror and made available to the application software.
|
||||
|
||||
## NVM Simulink Block
|
||||
|
||||
To utilize NVM in powertrain_build, a special Simulink block needs to be created,
|
||||
which should be able to read, write and reset the NVM-parameter.
|
||||
|
||||
The block should contain a combination of *TL\_DataStore\** and *TL\_UnitDelay* blocks.
|
||||
|
||||
The code for finding these blocks can be seen in *powertrain-build/matlab\_scripts/parseNVM.m*.
|
||||
|
||||
These blocks must use the *CVC\_DISP\_NVM\** variable class.
|
||||
|
||||
There is one class for normal NVM handling and one for persistent data.
|
||||
|
||||

|
||||
|
||||
## NVM Handling in powertrain-build
|
||||
|
||||
powertrain-build collects the NVM blocks from the models.
|
||||
The NVM variables are matched against a specific json file, called *Projects/\<PROJECT\_NAME\>/conf.local/nvm_structs.json*.
|
||||
This list is updated automatically after running the powertrain-build "build" command.
|
||||
However, the generated file needs to manually be moved to the *conf.local* folder.
|
||||
|
||||
The NVM-area is divided into six structs.
|
||||
|
||||

|
||||
|
||||
powertrain-build currently assumes that the order of these variables needs to be kept inbetween iterations of the software.
|
||||
Therefore, powertrain-build automatically adds new parameters at the end of the relevant NVM struct.
|
||||
If a parameter needs to be removed, it is replaced by a dummy parameter.
|
||||
This assures that the backward compatibility always is meet.
|
||||
|
||||
Below is an example of the contents of a *nvm_structs.json* file.
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"name": "NVM_LIST_CRITICAL2",
|
||||
"allowed_datatypes": [
|
||||
"NotApplicable"
|
||||
],
|
||||
"size": 16,
|
||||
"instanceName": "nvm_list_critical2",
|
||||
"default_datatype": "UInt16",
|
||||
"includeStop": "",
|
||||
"includeStart": "",
|
||||
"persistent": false,
|
||||
"signals": [
|
||||
{
|
||||
"type": "UInt16",
|
||||
"x_size": 1,
|
||||
"name": "sVcModelName_D_DummyOne",
|
||||
"y_size": 1
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"name": "NVM_LIST_CRITICAL1",
|
||||
"allowed_datatypes": [
|
||||
"NotApplicable"
|
||||
],
|
||||
"size": 16,
|
||||
"instanceName": "nvm_list_critical1",
|
||||
"default_datatype": "UInt16",
|
||||
"includeStop": "",
|
||||
"includeStart": "",
|
||||
"persistent": false,
|
||||
"signals": [
|
||||
{
|
||||
"type": "UInt16",
|
||||
"x_size": 1,
|
||||
"name": "sVcModelName_D_DummyTwo",
|
||||
"y_size": 1
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"name": "NVM_LIST_8",
|
||||
"allowed_datatypes": [
|
||||
"Bool",
|
||||
"UInt8",
|
||||
"Int8"
|
||||
],
|
||||
"size": 130,
|
||||
"instanceName": "nvm_list_8",
|
||||
"default_datatype": "UInt8",
|
||||
"includeStop": "",
|
||||
"includeStart": "",
|
||||
"persistent": false,
|
||||
"signals": [
|
||||
{
|
||||
"type": "UInt8",
|
||||
"x_size": 1,
|
||||
"name": "Pos_8bit_0",
|
||||
"y_size": 1
|
||||
},
|
||||
{
|
||||
"type": "UInt8",
|
||||
"x_size": 1,
|
||||
"name": "sVcModelName_D_DummyThree",
|
||||
"y_size": 1
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"name": "NVM_LIST_16",
|
||||
"allowed_datatypes": [
|
||||
"UInt16",
|
||||
"Int16"
|
||||
],
|
||||
"size": 768,
|
||||
"instanceName": "nvm_list_16",
|
||||
"default_datatype": "UInt16",
|
||||
"includeStop": "",
|
||||
"includeStart": "",
|
||||
"persistent": false,
|
||||
"signals": [
|
||||
{
|
||||
"type": "UInt16",
|
||||
"x_size": 7,
|
||||
"name": "sVcModelName_D_DummyFour",
|
||||
"y_size": 1
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"name": "NVM_LIST_32",
|
||||
"allowed_datatypes": [
|
||||
"Float32",
|
||||
"UInt32",
|
||||
"Int32"
|
||||
],
|
||||
"size": 896,
|
||||
"instanceName": "nvm_list_32",
|
||||
"default_datatype": "UInt32",
|
||||
"includeStop": "",
|
||||
"includeStart": "",
|
||||
"persistent": false,
|
||||
"signals": [
|
||||
{
|
||||
"type": "UInt32",
|
||||
"x_size": 9,
|
||||
"name": "sVcModelName_D_DummyFive",
|
||||
"y_size": 1
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"name": "NVM_LIST_8_PER",
|
||||
"allowed_datatypes": [
|
||||
"Bool",
|
||||
"UInt8",
|
||||
"Int8"
|
||||
],
|
||||
"size": 40,
|
||||
"instanceName": "nvm_list_8_per",
|
||||
"default_datatype": "UInt8",
|
||||
"includeStop": "",
|
||||
"includeStart": "",
|
||||
"persistent": true,
|
||||
"signals": [
|
||||
{
|
||||
"name": "sVcModelName_D_DummySix",
|
||||
"type": "Bool",
|
||||
"x_size": 1,
|
||||
"y_size": 1
|
||||
},
|
||||
{
|
||||
"name": "sVcModelName_D_DummySeven",
|
||||
"type": "Bool",
|
||||
"x_size": 1,
|
||||
"y_size": 1
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"name": "NVM_LIST_16_PER",
|
||||
"allowed_datatypes": [
|
||||
"UInt16",
|
||||
"Int16"
|
||||
],
|
||||
"size": 119,
|
||||
"instanceName": "nvm_list_16_per",
|
||||
"default_datatype": "UInt16",
|
||||
"includeStop": "",
|
||||
"includeStart": "",
|
||||
"persistent": true,
|
||||
"signals": [
|
||||
{
|
||||
"name": "sVcModelName_D_DummyEight",
|
||||
"type": "UInt16",
|
||||
"x_size": 1,
|
||||
"y_size": 1
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"name": "NVM_LIST_32_PER",
|
||||
"allowed_datatypes": [
|
||||
"Float32",
|
||||
"UInt32",
|
||||
"Int32"
|
||||
],
|
||||
"size": 112,
|
||||
"instanceName": "nvm_list_32_per",
|
||||
"default_datatype": "UInt32",
|
||||
"includeStop": "",
|
||||
"includeStart": "",
|
||||
"persistent": true,
|
||||
"signals": [
|
||||
{
|
||||
"name": "sVcModelName_D_DummyNine",
|
||||
"type": "UInt32",
|
||||
"x_size": 1,
|
||||
"y_size": 1
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
### Critical NVM Parameters
|
||||
|
||||
If there is a possibility to write an NVM parameter directly to flash.
|
||||
This is useful e.g. for safety critical parameters that shall not be lost if a reset occurs.
|
||||
Two specific NVM struct areas called *nvm\_list\_critical1/2* can be added.
|
||||
These areas are non-persistent and holds all the datatypes (4,2,1 bytes).
|
||||
The two areas are needed two give higher integraty of the writing/read of the parameters.
|
||||
|
||||
### Generated Files
|
||||
|
||||
powertrain-build generates C code definings structs for each area.
|
||||
See small examples below.
|
||||
|
||||
*vcc\_nvm\_struct.h*
|
||||
|
||||
```c
|
||||
/*
|
||||
* vcc_nvm_struct.h - struct for NVM signals
|
||||
*/
|
||||
|
||||
#ifndef VCC_NVM_STRUCT_H
|
||||
#define VCC_NVM_STRUCT_H
|
||||
|
||||
#include "tl_basetypes.h"
|
||||
#include "CVC_NVM_START.h"
|
||||
struct NVM_LIST_8 {
|
||||
UInt8 unused[130];
|
||||
}; /* 0 bytes used of 130 */
|
||||
#include "CVC_NVM_END.h"
|
||||
|
||||
#include "CVC_NVM_START.h"
|
||||
struct NVM_LIST_32 {
|
||||
Float32 _sVcModelName_D_DummyOne;
|
||||
UInt32 unused[895];
|
||||
}; /* 4 bytes used of 3584 */
|
||||
#include "CVC_NVM_END.h"
|
||||
|
||||
#include "PREDECL_START.h"
|
||||
extern struct NVM_LIST_8 nvm_list_8;
|
||||
extern struct NVM_LIST_32 nvm_list_32;
|
||||
#include "PREDECL_END.h"
|
||||
|
||||
|
||||
#define sVcModelName_D_DummyOne nvm_list_32._sVcModelName_D_DummyOne
|
||||
|
||||
#endif /* VCC_NVM_STRUCT_H */
|
||||
```
|
||||
|
||||
*vcc\_nvm\_struct.c*
|
||||
|
||||
```c
|
||||
#include "vcc_nvm_struct.h"
|
||||
|
||||
#include "CVC_NVM_START.h"
|
||||
struct NVM_LIST_8 nvm_list_8;
|
||||
#include "CVC_NVM_END.h"
|
||||
|
||||
#include "CVC_NVM_START.h"
|
||||
struct NVM_LIST_32 nvm_list_32;
|
||||
#include "CVC_NVM_END.h"
|
||||
```
|
30
docs/target_link/state_flow.md
Normal file
@ -0,0 +1,30 @@
|
||||
# TargetLink Configuration of State Flow
|
||||
|
||||
-----------------------------------------
|
||||
|
||||
[TOC]
|
||||
|
||||
## TargetLink Configuration of Ports in State Flow
|
||||
|
||||
If ports and locals are not properly configured in State Flow, the signals may end up as Float64, which is not a native data type.
|
||||
Do not choose data type double, this will result in Float64 as data type.
|
||||
|
||||

|
||||
|
||||
Do not choose "Inherit: Same as Simulink" either as this may also result in Float64.
|
||||
It is best to choose single as Datatype for inputs or boolean for logical signals.
|
||||
|
||||

|
||||
|
||||
The above configurations can also be done in the *TargetLink Property Manager*.
|
||||
In the property manager, TL classes can also be set, see below.
|
||||
The TargetLink properties can be configured by choosing *TargetLink -> Property Manager* in the menu.
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
A properly configured outport is marked by blue in the picture below.
|
||||
The outport marked by red can cause the undesired behavior.
|
||||
|
||||

|
262
docs/target_link/struct_signalling.md
Normal file
@ -0,0 +1,262 @@
|
||||
# TargetLink Struct In- and Out-port Signals
|
||||
|
||||
--------------------------------------------
|
||||
|
||||
[TOC]
|
||||
|
||||
## Before You Start
|
||||
|
||||
External struct support was recently added,
|
||||
your repository might be in a state were some structs are still in the old format.
|
||||
|
||||
### Inports and Outports Must Match
|
||||
|
||||
The name of the generated struct is the same as the name of the _TL\_BusInport_/_TL\_BusOutport_ block.
|
||||
Therefore, the developer should change the producer and the consumer of a struct at the same time.
|
||||
By doing that, powertrain-build can verify that the structs look the same.
|
||||
If a struct were to change in size but keep the name, powertrain-build will catch that.
|
||||
|
||||
## Definings Struct Signals
|
||||
|
||||
This section describes how to create struct signals.
|
||||
|
||||
Easiest way to work with and share structs is to create buses and storing them in _.mat_ files,
|
||||
which can be loaded where needed in the _\_par.m_ files.
|
||||
Bus _.mat_ files should be stored in a shared folder, such as _Models/Common/VcBusDefinitions_.
|
||||
This is very similar to how to work with shared enumerations, see [TargetLink Enumerations](./enumerations.md).
|
||||
|
||||
### Outports
|
||||
|
||||
To create an outgoing signal one must use the TL block _TL\_BusOutport_.
|
||||
The name of the generated struct will be the same as the block name, so name the block appropriately.
|
||||
Preferably, the block name should be the same as the _.mat_ file defining the bus signal.
|
||||
|
||||
The insignal to this block must come from a _Bus Creator_,
|
||||
where the name of the struct outport signal will be the same as the insignal.
|
||||
Each struct member will get the same name as the signals entering the bus creator.
|
||||
|
||||
To link to a loaded bus object, right click on the bus creator and click "Block Parameters (BusCreator)".
|
||||
Select "Bus: \<object name\>" as the data type.
|
||||
Expand the data type options (click "\>\>") and make sure mode is set to "Bus object" and then input the name of the bus.
|
||||
It is possible to browse loaded bus objects by clicking the "Edit" button.
|
||||
|
||||

|
||||
|
||||
For the bus, it is important to select the class _CVC\_DISP_ (like normal outports), data type _IMPLICIT\_STRUCT_,
|
||||
name macro _$L_.
|
||||
|
||||

|
||||
|
||||
For the members, it is important to select the class _CVC\_DISP_, otherwise they won't show up in the A2L-file,
|
||||
and name macro _$L_.
|
||||
|
||||

|
||||
|
||||
A2L extract:
|
||||
|
||||
```A2L
|
||||
/begin MEASUREMENT
|
||||
sVcCcHvcBustest_Bus_TestSignal.Te_BusSignal1 /* Name */
|
||||
"" /* LongIdentifier */
|
||||
FLOAT32_IEEE /* Datatype */
|
||||
VOID_SCALING /* Conversion */
|
||||
1 /* Resolution */
|
||||
0 /* Accuracy */
|
||||
-3.402823466e38 /* LowerLimit */
|
||||
3.402823466e38 /* UpperLimit */
|
||||
READ_WRITE
|
||||
/begin IF_DATA ASAP1B_ADDRESS
|
||||
KP_BLOB 0x00000000
|
||||
/end IF_DATA
|
||||
/end MEASUREMENT
|
||||
```
|
||||
|
||||
JSON config file extract:
|
||||
|
||||
```json
|
||||
"outports": {
|
||||
"sVcCcHvcBustest_Bus_TestSignal.Te_BusSignal1": {
|
||||
"handle": "VcCcHvcBustest/VcCcHvcBustest/Subsystem/VcCcHvcBustest/Bus Outport",
|
||||
"name": "sVcCcHvcBustest_Bus_TestSignal.Te_BusSignal1",
|
||||
"configs": "((ALWAYS_ACTIVE))",
|
||||
"description": "",
|
||||
"type": "Float32",
|
||||
"unit": "",
|
||||
"offset": "-",
|
||||
"lsb": "-",
|
||||
"min": "-",
|
||||
"max": "-",
|
||||
"class": "CVC_DISP",
|
||||
"width": 1
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
C source code extract:
|
||||
|
||||
```c
|
||||
/**************************************************************************************************\
|
||||
CVC_DISP: CVC global observable variables in RAM | Width: N.A.
|
||||
\**************************************************************************************************/
|
||||
CVC_DISP struct sVcCcHvcBustest_Bus_SomeOutBus sVcCcHvcBustest_Bus_TestSignal = {
|
||||
0.F, /* Te_BusSignal1 */
|
||||
0.F /* Te_BusSignal2 */
|
||||
};
|
||||
|
||||
void RESTART_VcCcHvcBustest(void)
|
||||
{
|
||||
sVcCcHvcBustest_Bus_TestSignal.Te_BusSignal1 = 0.F;
|
||||
sVcCcHvcBustest_Bus_TestSignal.Te_BusSignal2 = 0.F;
|
||||
}
|
||||
```
|
||||
|
||||
C header code extract:
|
||||
|
||||
```c
|
||||
/*------------------------------------------------------------------------------------------------*\
|
||||
TYPEDEFS
|
||||
\*------------------------------------------------------------------------------------------------*/
|
||||
struct sVcCcHvcBustest_Bus_SomeOutBus {
|
||||
Float32 Te_BusSignal1;
|
||||
Float32 Te_BusSignal2;
|
||||
}; /* Description: bus outport struct */
|
||||
|
||||
/**************************************************************************************************\
|
||||
CVC_DISP: CVC global observable variables in RAM | Width: N.A.
|
||||
\**************************************************************************************************/
|
||||
extern CVC_DISP struct sVcCcHvcBustest_Bus_SomeOutBus sVcCcHvcBustest_Bus_TestSignal;
|
||||
```
|
||||
|
||||
### Inports
|
||||
|
||||
To create an incoming signal one must use the TL block _TL\_BusInport_.
|
||||
The insignal to this block can either come from a _Bus Creator_ or a constant block located on the outermost layer,
|
||||
preferably referencing a bus object.
|
||||
|
||||
To link to a loaded bus object, right click on the bus creator/constant block and click "Block Parameters (\<block type\>)".
|
||||
Select "Bus: \<object name\>" as the data type.
|
||||
Expand the data type options (click "\>\>") and make sure mode is set to "Bus object" and then input the name of the bus.
|
||||
It is possible to browse loaded bus objects by clicking the "Edit" button, see image in the "Outports" chapter.
|
||||
|
||||
The name of the struct inport signal will be the same as the insignal or bus object, respectively.
|
||||
|
||||
For the bus, it is important to select the class _CVC\_EXT_ (like normal inports), data type _IMPLICIT\_STRUCT_,
|
||||
name macro _$L_.
|
||||
|
||||

|
||||
|
||||
For the members, it is important to select the class _CVC\_DISP_, otherwise they won't show up in the A2L-file,
|
||||
and name macro _$L_.
|
||||
|
||||

|
||||
|
||||
A2L extract:
|
||||
|
||||
```A2L
|
||||
/begin MEASUREMENT
|
||||
sVcCcHvcBustest_Bus_TestSignal.Te_BusSignal1 /* Name */
|
||||
"" /* LongIdentifier */
|
||||
FLOAT32_IEEE /* Datatype */
|
||||
VOID_SCALING /* Conversion */
|
||||
1 /* Resolution */
|
||||
0 /* Accuracy */
|
||||
-3.402823466e38 /* LowerLimit */
|
||||
3.402823466e38 /* UpperLimit */
|
||||
READ_WRITE
|
||||
/begin IF_DATA ASAP1B_ADDRESS
|
||||
KP_BLOB 0x00000000
|
||||
/end IF_DATA
|
||||
/end MEASUREMENT
|
||||
```
|
||||
|
||||
JSON config file extract:
|
||||
|
||||
```json
|
||||
"inports": {
|
||||
"sVcCcHvcBustest_Bus_TestSignal.Te_BusSignal1": {
|
||||
"handle": "VcCcHvcBusReceive/VcCcHvcBusReceive/Subsystem/VcCcHvcBusReceive/Bus Inport",
|
||||
"name": "sVcCcHvcBustest_Bus_TestSignal.Te_BusSignal1",
|
||||
"configs": "((ALWAYS_ACTIVE))",
|
||||
"description": "",
|
||||
"type": "Float32",
|
||||
"unit": "",
|
||||
"offset": "-",
|
||||
"lsb": "-",
|
||||
"min": "-",
|
||||
"max": "-",
|
||||
"class": "CVC_DISP",
|
||||
"width": 1
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
C source code extract:
|
||||
|
||||
```c
|
||||
void VcCcHvcBusReceive(void)
|
||||
{
|
||||
/* TargetLink outport: VcCcHvcBusReceive/Out1
|
||||
# combined # Sum: VcCcHvcBusReceive/VcCcHvcBusReceive/Sum */
|
||||
sVcCcHvcBusReceive_Te_templateSignal = sVcCcHvcBustest_Bus_TestSignal.Te_BusSignal1 +
|
||||
sVcCcHvcBustest_Bus_TestSignal.Te_BusSignal2;
|
||||
|
||||
/* Gain: VcCcHvcBusReceive/Gain1
|
||||
VcCcHvcBusReceive/Gain1: folded operation multiplication to constant value 0.1 */
|
||||
rVcCcHvcBusReceive_Z_Version = 0.1F;
|
||||
}
|
||||
```
|
||||
|
||||
C header code extract:
|
||||
|
||||
```c
|
||||
#include "udt_CcHvcBusRe.h"
|
||||
|
||||
|
||||
/**************************************************************************************************\
|
||||
CVC_EXT: CVC external interface input variables | Width: N.A.
|
||||
\**************************************************************************************************/
|
||||
CVC_EXT struct sVcCcHvcBustest_Bus_SomeInBus sVcCcHvcBustest_Bus_TestSignal;
|
||||
```
|
||||
|
||||
In this case, the struct is generated in additional header file.
|
||||
Where "udt" stands for "user defined types".
|
||||
|
||||
Example file, _udt\_CcHvcBusRe.h_:
|
||||
|
||||
```c
|
||||
/**************************************************************************************************\
|
||||
***
|
||||
*** Simulink model : VcCcHvcBusReceive_OPortMvd
|
||||
*** TargetLink subsystem : VcCcHvcBusReceive_OPortMvd/VcCcHvcBusReceive
|
||||
*** Codefile : udt_CcHvcBusRe.h
|
||||
***
|
||||
*** Generation date: 2021-03-22 10:48:56
|
||||
***
|
||||
*** TargetLink version : 4.3p3 from 16-Oct-2018
|
||||
*** Code generator version : Build Id 4.3.0.27 from 2018-09-24 17:55:03
|
||||
\**************************************************************************************************/
|
||||
|
||||
#ifndef UDT_CCHVCBUSRE_H
|
||||
#define UDT_CCHVCBUSRE_H
|
||||
|
||||
|
||||
#include "tl_basetypes.h"
|
||||
|
||||
|
||||
|
||||
struct sVcCcHvcBustest_Bus_SomeInBus {
|
||||
Float32 Te_BusSignal1;
|
||||
Float32 Te_BusSignal2;
|
||||
}; /* Description: bus inport struct */
|
||||
|
||||
#endif /* UDT_CCHVCBUSRE_H */
|
||||
/*------------------------------------------------------------------------------------------------*\
|
||||
END OF FILE
|
||||
\*------------------------------------------------------------------------------------------------*/
|
||||
```
|
||||
|
||||
## The Common Header File
|
||||
|
||||
powertrain-build will generate a file named _VcStructs.h_, which defines all the busses/structs used in the project.
|
||||
|
||||
This file can be included if you for instance use a custom _VcDummy\_spm.c_ file.
|
23
docs/target_link/target_link.md
Normal file
@ -0,0 +1,23 @@
|
||||
# TargetLink
|
||||
|
||||
------------
|
||||
|
||||
TargetLink is powertrain-builds code generator of choice.
|
||||
Embedded Coder works too if set up similarily, e.g. using varible classes.
|
||||
|
||||
## Using TargetLink
|
||||
|
||||
* [Naming Convention](naming_convention.md)
|
||||
* [Configuration of State Flow](./state_flow.md)
|
||||
* [Variable Classes](./variable_classes.md)
|
||||
* [Enumeration Class Variables](./enumerations.md)
|
||||
* [Function Blocks in Subsystems](./function_block.md)
|
||||
* [Struct In-/Out-signals](./struct_signalling.md)
|
||||
* [Editing a New LookUp or PreLookup Function](./functions.md)
|
||||
* [Using Custom Code Blocks](./custom_code_block.md)
|
||||
* [Non Volatile Memory](./non_volatile_memory.md)
|
||||
* [Diagnostics](./diagnostics.md)
|
||||
|
||||
## Product Information
|
||||
|
||||
<https://www.dspace.com/shared/TargetLink/files/public/TL_Style_Guide-Modular_distributed_development.pdf>
|
249
docs/target_link/variable_classes.md
Normal file
@ -0,0 +1,249 @@
|
||||
# TargetLink Variable Classes
|
||||
|
||||
-----------------------------
|
||||
|
||||
[TOC]
|
||||
|
||||
## General
|
||||
|
||||
The only variable classes to be used are CVC classes and the class `default`.
|
||||
The classes are defined in the TargetLink data dictionary (.dd) file.
|
||||
A list of the variable classes used by function developers beside `default` is given here.
|
||||
The ASIL variable classes are used if the parameters shall be allocated to a specific monitored memory area.
|
||||
|
||||

|
||||
|
||||
All variable classes are defined in TL DataDictionary.
|
||||
|
||||
## ASIL Classes
|
||||
|
||||
**NOTE:** Make sure to note the names of these classes (see image above).
|
||||
Instead of the more simple name ["CVC_CAL"](#calibration-constants),
|
||||
the ASIL A version of "CVC_CAL" would be "ASIL_A/CVC_CAL_ASIL_A".
|
||||
|
||||
Models using ASIL level variables should also mark its function calls as ASIL classed.
|
||||
This is done by modifying the "FUNCTION" TargtLink block.
|
||||
|
||||

|
||||
|
||||
TargetLink FUNCTION block with ASIL level.
|
||||
|
||||
Additionally, in order to get the correct ASIL level in the `config\_VcModelName.json` file,
|
||||
the name of the model needs to be added to the struct "dependability_model_asil_class" in
|
||||
`ConfigDocuments/matlab\_script\_config/CodeGen\_config.json`.
|
||||
|
||||
**NOTE:** The `Init function class` is generally not ASIL classified.
|
||||
When we generate code, we only generate the main and restart (force box ticked) function calls.
|
||||
These need to be ASIL classified.
|
||||
Meaning the `Term function class` probably does not have to be ASIL classified either.
|
||||
|
||||
## CVC Classes
|
||||
|
||||
The variable unit must coincide with the abbreviation in the variable name.
|
||||
See [naming convention](naming_convention.md).
|
||||
|
||||

|
||||
|
||||
The macro `$L` uses the output line name in the variable name and the macro `$N` uses the model name,
|
||||
so this variable will be named *rVcScrMdl_Z_ScrConcNoUs*.
|
||||
|
||||
All blocks with a CVC class output should have a filled in "Description".
|
||||
If the variable is a calibration constant then if possible, determined "Max" and "Min" values should be set.
|
||||
For local readables this is optional.
|
||||
|
||||

|
||||
|
||||
Example of a CVC class variable with filled in description and Max/Min values.
|
||||
|
||||
## default Class
|
||||
|
||||
The `default` class should be used for all operations where a specific variable name in the code is unnecessary.
|
||||
|
||||
* The output line from a default class block should not have a line name.
|
||||
If a name must be visible for the documentation the name should have the ending `_DOC`.
|
||||
* The output name should be `$S_$B`.
|
||||
* "Min", "Max", "Unit" and "Description" should be empty.
|
||||
|
||||

|
||||
|
||||
The Max, Min, Unit and Description fields should be empty and the name should be `$S_$B` for default class variables.
|
||||
|
||||
## External Signals
|
||||
|
||||
### General Info
|
||||
|
||||
The output variable name from all external out- and in-port blocks should be `$L`.
|
||||
|
||||
### Inport Blocks
|
||||
|
||||
The class should be `CVC_EXT` for all external inports.
|
||||
The output line name from an inport block should be the complete variable name.
|
||||
|
||||

|
||||
|
||||
Example of an inport with correct class, name and output line name.
|
||||
|
||||
### Outport Blocks
|
||||
|
||||
The class should be `CVC_DISP` for all external outports.
|
||||
The input signal name to all external outports should be a long variable name propagated from an output line from a target link block
|
||||
which has the output name `$S_$B` and the class `default`.
|
||||
|
||||

|
||||
|
||||
This figure shows a correct implementation of a input signal to an outport block.
|
||||
|
||||
### External Variables
|
||||
|
||||
The properties for all external variables has to be filled in the interface description.
|
||||
Although they are defines in the TargtLink models, the interface description is used to communicate with other consumers/senders.
|
||||
|
||||
## Constants
|
||||
|
||||
### Default Constants
|
||||
|
||||
If a constant is non-adjustable by calibration and needs no name for documentation,
|
||||
a numeric value should be entered in the "Constant" dialog and the variable class should be `default`.
|
||||
|
||||

|
||||
|
||||
Example of a `default` class constant.
|
||||
|
||||
### Unique Constants
|
||||
|
||||
If a constant should have a specific name and be used only once, the class should be `CVC_CONST`.
|
||||
The block name should be `Vc_` + short name, e.g. `Vc_B_Init`.
|
||||
The "output name" should be `c$B` and the output line name from the constant block should be empty.
|
||||
If a name must be visible for documentation the line name should have the ending `_DOC`.
|
||||
The constant value should come from a variable in workspace and must coincide with the output name.
|
||||
For constants the Matlab workspace variable should be declared in *VcModelName_par.m*.
|
||||
|
||||

|
||||
|
||||
Example of a unique constant.
|
||||
The constant value is from the workspace variable `Vc.D_TosModeFailSafe` defined in *VcModelName_par.m* and
|
||||
the variable name is `c$B` which gives the variable name `cVc_ D_TosModeFailSafe`.
|
||||
|
||||
### External Constants
|
||||
|
||||
If a constant with a specific name should be used more than once the class should be `CVC_CONST_EXT`.
|
||||
The variable must also be declared in the model *VcConst.mdl*.
|
||||
For an example of how this is done see figures below.
|
||||
The constant value should come from a variable in workspace and must coincide with the output name.
|
||||
For constants, the Matlab workspace variable should be declared in *VcModelName_par.m*.
|
||||
|
||||

|
||||
|
||||
Example of an external constant.
|
||||
|
||||

|
||||
|
||||
The external constant variable is implemented in a "TL_DataStoreMemory" – block in the model *VcConst.mdl*.
|
||||
|
||||
## Calibration parameters
|
||||
|
||||
### Calibration Constants
|
||||
|
||||
The output name of a calibration constant should be `c$N_$B`. The "output" type should be of class `CVC_CAL`.
|
||||
The output line should not have a visible name.
|
||||
The constant value should come from a variable in workspace and must coincide with the output name.
|
||||
|
||||

|
||||
|
||||
Example of a calibration constant.
|
||||
|
||||
### Calibration Tables and Maps
|
||||
|
||||
All calibration lookup tables and maps should have a pre lookup block connected to their in-/out-ports.
|
||||
|
||||
* If possible the "VCC_Map_1D" should be used for lookup tables and "VCC_Map_2D" for lookup maps.
|
||||
* For these blocks the lookup block name under the mask should be equal to mask name.
|
||||
* All input value variables to booth the lookup and pre lookup blocks should coincide with the table/map names.
|
||||
* The "breakpoint data" in the pre lookup block and the "table" in the lookup block should independently be one of the classes `CVC_CAL`.
|
||||
|
||||
### Calibration Tables
|
||||
|
||||
* The pre lookup block name should be mask name + `_x`.
|
||||
|
||||

|
||||
|
||||
Example of the correct block names in a "VCC_Map_1D" block with the mask name `rt_CreepPedCmp`.
|
||||
|
||||
If the same pre lookup block is connected to more than one lookup map is allowed to ignore the rule above.
|
||||
But the pre lookup name must be similar to the lookup map name and have the correct ending.
|
||||
|
||||

|
||||
|
||||
Example of when the same prelookup block is connected to multiple lookup tables.
|
||||
|
||||
The length of the "breakpoint data" vector in the pre lookup block must be equal to the number of columns in the table matrix.
|
||||
The "breakpoint" name in the pre lookup and the "table" name in the lookup table should be `t$N_$B`.
|
||||
|
||||
### Calibration Maps
|
||||
|
||||
The two pre lookup block names should be mask name + `_r` and mask name + `_c`.
|
||||
|
||||

|
||||
|
||||
Example of the correct block names in a "VCC_Lookup2D" block with the mask name `rt_TiGear2`.
|
||||
|
||||
If the same pre lookup block is connected to more than one lookup map is allowed to ignore the rule above.
|
||||
But the pre lookup name must be similar to the lookup map name and have the correct ending.
|
||||
|
||||
* The length of the "breakpoint data" vector in the pre lookup block "mask name_c" must be equal to the number of columns in the table matrix.
|
||||
* The length of the "breakpoint data" vector in the pre lookup block "mask name_r" must be equal to the number of rows in the map matrix.
|
||||
* The "breakpoint" name in the pre lookup and the "table" name in the lookup table should be `m$N_$B`.
|
||||
|
||||
## Mergeable Calibration Variables
|
||||
|
||||
If a calibration variable should be used in more than one block, the variable must be have the class `CVC_CAL_MERGEABLE`.
|
||||
The rules for mergeable calibration variables are the same as for normal calibration variables except in the following areas.
|
||||
All blocks in a subsystem must have a unique name.
|
||||
If it is necessary to use the same mergeable variable twice in the same subsystem the block names for these blocks should be hidden.
|
||||
Instead, the name should be entered in the "block annotation", which can be found in the right-click menu under "block properties".
|
||||
In this case it is no longer possible to us the macro `$B` for the variable name, instead this part of the name should be entered manually.
|
||||
|
||||

|
||||
|
||||
Example when the same mergeable variable is used twice in the same subsystem.
|
||||
In this case the block name is hidden and instead the name is entered in the "block annotation".
|
||||
Since `$B` cannot be used the entered variable name is `c$N_M_ScrExhaustMol`.
|
||||
|
||||

|
||||
|
||||
Example of Mergable table.
|
||||
|
||||
## Measurable Variables
|
||||
|
||||
### General About Measurable Variables
|
||||
|
||||
All non-external measure variables should have one of the classes `CVC_DISP`.
|
||||
The output line name from a block with a measurable variable should be the short variable name.
|
||||
The output name should be `x$N_$L` for all variables with type "Bool" (abbreviation "B") and `r$N_$L` for all other types.
|
||||
|
||||

|
||||
|
||||
This figure shows the short output line name from a block with a CVC_DISP class output variable (red markings).
|
||||
The output variable name starts with an "x" since the type is "Bool" (green markings).
|
||||
|
||||
### Measuring Output Variable from Masked Blocks
|
||||
|
||||
When measuring the output variable from a masked block it is important to remember that the variable is defined under the mask.
|
||||
The line name can therefore not be entered on the output line from the masked block.
|
||||
It must be entered on the output line under the mask and be propagated on the output line from the masked block.
|
||||
|
||||

|
||||
|
||||
### Max and Min Settings for Measurable Variables
|
||||
|
||||
The use of "Max" and "Min" settings in blocks with class `CVC_DISP` is optional.
|
||||
If "Max" and/or "Min" values are used then care must be taken.
|
||||
"Max"/"Min" blocks lets you specify constrained range limits, which the code Generator assumes will never be exceeded (code optimization).
|
||||
This leading range information is propagated through the model and can influence subsequent blocks.
|
||||
This means that the code generator will remove "Max"/"Min" blocks in the signal chain if
|
||||
they have the same value or a value outside of the set range of the processes signals.
|
||||
|
||||

|
||||
|
||||
Example of "MinMax" block removed from the generated code,
|
||||
because some signals had the same value ("8000") as signal in one of the min block inport.
|