Project 2 - Development of TFT Cluster Speedometer Software Component
Develop the Simulink model based on the given requirements and also create SLDD file and link the same to the model.
Perform the complete V and V workflow for the obtained model
Ans:
Development of TFT Cluster Speedometer Software Component
Cluster Instrument receives the signals from other ECU via CAN bus interface. It also receives commands from the driver via steering wheel buttons. The signals are then processed by the Cluster ECU, after which the Cluster ECU may send the vehicle information to the LCD or light the LEDs and so forth, according to the results. Therefore, the Cluster ECU can be viewed as a carrier of the information flow.
Requirements:
1.1 Calculating TFT Display Speed
|
Average Vehicle Speed would be displayed only if its between 2 kmph & 250 kmph. Any value outside this range will be discarded by its lower limit & upper limit |
|
When Average Vehicle Speed is < 2 kmph, DisplaySpeed = 2 kmph |
|
When Average Vehicle Speed is in between 2 kmph & 250 kmph, DisplaySpeed = Average Vehicle Speed |
|
When Average Vehicle Speed is > 250 kmph, DisplaySpeed = 250 kmph |
1.2 Main Data Filtering
|
Main Data Filtering subsystem will be activated for every 10th millisecond |
||||||
|
DisplaySpeed1 (t) = ((DisplaySpeed (t) x 0.65)/ Main Filter Speed Value) 0.05 |
1.3 Auxiliary Data Filtering
|
Auxiliary Data Filtering subsystem will be activated for every 10th millisecond |
|||||||
|
DisplaySpeed_Filter (t) = ((DisplaySpeed1 (t) x 0.78)/ Auxillary Filter Speed Value) - 0.03 |
1.4 TFT Speed Output
|
If |(DisplaySpeedFilter - DisplaySpeed)| > 1.5 |
|
{ |
|
Vehicle Speed Display = DisplaySpeed |
|
} |
|
else |
|
{ |
|
Vehicle Speed Display = DisplaySpeed Filter |
|
} |
SLDD Creation:
A data dictionary file is created. All the signals such as input, output and the local signals are added in the Simulink data dictionary.
The following image shows signals in the Sldd file.
Requirement Tagging:
Requirement tagging is done using the Requirement Manager app. At first the app is launched within the Matlab environment. Then we open the requirement editor and add new requirement set using the plus button in the top ribbon.
After the requirement set added, we can add requirements to that particular set. Here, we have created a set and added the four requirements to that set. A file with extension slreqx is generated after the requirement set is added.
Then, each requirement is linked with the subsystem of the model where it is implemented. The subsystem in the simulink model is selected first, then in the requirement editor window particular requirement is linked with the ‘Add Link’ on the top
JMAAB Checks:
Then the model is check for JMAAB compliance. The model advisor tool is loaded and JMAAB checks were selected. Then checks were run and a report is generated.
Simulink Design Verifier:
In the Simulink design verifier, we check the model for any design errors that may slipped through from the previous checks(i.e. jmaab). The design verifier tool is loaded from the App section.
Now we check for design errors by clicking green play button at the top. After few seconds the detection is completed and a report is also generated. Here is the summary of the verifier-
SLDV Test Generation report:
In the next step, test geneartion is done in the Design verifier tool. The test generation coverage is set to MCDC and other settings were left at default value.
By clicking the run button the tests were generated and a html report is also created.
Model in Loop test + coverage:
Before going in to Model in loop testing the few configuration setting settings were taken care of such as Enabling coverage and setting Coverage metrics to MCDC.
Now to test the model first we need a test harness. The test harness can be created by right clicking on the top level subsystem and selecting ‘Test Harness ’ from the context menu. This opens a dialogue box, where we can select the input and output of the component or model under test. Here we have selected signal builder for input and to workspace block for the output. The figure below shows the dialogue box parameters used-
Now, test cases were written for the model. They are written in a spreadsheet and then imported to the signal builder in test harness. A screenshot of the test cases is shown below-
This data is then imported to the signal builder using the import form file option. Both the calculated output and the model output is send to workspace using ‘To Workspace’ block. These two workspace variables will be compared after the test.
So,the final model of the harness looks like the fig. below-
he model is then run for the total time of 1 sec with fixed step(discrete) solver with sample time of 0.01 sec. The output from test is then compared with the calculated value using the data inspector tool.
After we have run the model, the here is the comparison graph-
Software in Loop Test:
The software in loop (SIL) test is also performed by making another test harness. In SIL, we actually test code of the model instead of the simulink blocks.
The test harness creation is same as of MIL , but with two more steps.
-
First, the top model is made atomic subsystem (from the subsystem parameters dialog box).
-
Then, we open the test harness dialog as before, input the same parameters and additionally we go to advanced section and select Software in loop .
- After that similar steps were followed as MIL to make the final harness for the SIL test.
Code Generation:
To generate C- code for the model, we can use the Embedded Coder app within Matlab. But, first we have to adjust the code generation settings in the model configurator. The target file is st to ert.tlc which represents embedded real time coder.
