Project 2-Highway Assistant-Lane Changing Assistant
AIM:
To develop an algorithm for one of the features of the Highway Lane Changing Assisstance, create a simulink data dictionary for the given file listed, developed the Model Advisor report and generate the C using autosar.
OBJECTIVES:
- This model must be developed in MATLAB Simulink per MBD guidelines.
- Code Generation Profile must be Autosar Coder.
- Simulink Data Dictionary must be created for the model & must be linked to the model.
- All the input & output signals must be mapped into the Autosar Editor.
- Model Advisor Report is mandatory & this will be followed by Code Generation.
OVERVIEW
The Highway Assistant supports the driver and takes over the longitudinal and lateral guidance of the vehicle in monotonous driving situations on highways. The partially automated function can automatically start, accelerate, brake as well as steer the vehicle to a certain extent. The driver has to permanently supervise the system and be ready to take over the complete control of the vehicle at any time.
Drivers are taught to assess surrounding traffic before changing lanes by checking their rearview and side mirrors and looking over each shoulder. However, even for those who follow this sequence of checks, the vehicle's blind spot – the area alongside and just behind the vehicle – is a constant source of danger and often the cause of serious accidents. Even vehicles approaching quickly from behind can pose a risk. To make changing lanes safer, this feature has been developed.
Basic Working Principle
Highway Assistant is a partially automated driving function for a speed range of up to 180 km/h (112 mph) on highways. It combines the radar-based longitudinal guidance of Adaptive Cruise Control (ACC) with the video-based lateral guidance of lane keeping support in one system. Highway Assistant can be supplemented by an automatic lane change initiated and monitored by the driver in a speed range of 60 – 130 km/h (35 – 80 mph).
The lane Change Assistant works by using two mid-range radar sensors that are concealed in the rear bumper – one on the left, one on the right. These two sensors monitor the area alongside and behind the car. Powerful control software collates the sensor information to create a complete picture of all traffic in the area behind the vehicle.Whenever another vehicle approaches at speed from behind or is already present in the blind spot, a signal such as a warning light in the side mirror alerts the driver to the hazard. Should the driver still activate the turn signal with the intention of changing lanes, the system issues an additional acoustic and/or haptic warning.
Calibration and Input Signal
Input Signals:
|
Name of the Signal |
Data Type |
Range |
|
Highway_Input_Signal |
uint8 |
0 - 255 |
|
Enable_Display |
uint8 |
0 – 255 |
|
Input_Switch |
uint8 |
0 – 255 |
|
Lane_Input_Signal |
uint8 |
0 - 255 |
Local Signals:
|
Name of the Signal |
Data Type |
Range |
|
Highway_Display_Mode_1 |
uint8 |
0 - 255 |
|
Highway_Display_Mode_2 |
uint8 |
0 – 255 |
|
Highway_Display_Mode_3 |
uint8 |
0 – 255 |
|
Highway_Display_Mode_4 |
uint8 |
0 – 255 |
|
Lane_Display_Mode_1 |
uint8 |
0 – 255 |
|
Lane_Display_Mode_2 |
uint8 |
0 – 255 |
|
Lane_Display_Mode_3 |
uint8 |
0 – 255 |
|
Lane_Display_Mode_4 |
uint8 |
0 – 255 |
Output Signals:
|
Name of the Signal |
Data Type |
Range |
|
Display_Mode_1 |
uint8 |
0 - 255 |
|
Display_Mode_2 |
uint8 |
0 – 255 |
|
Display_Mode_3 |
uint8 |
0 – 255 |
|
Display_Mode_4 |
uint8 |
0 - 255 |
PROCEDURE
Create a simulink data dictionary from the calibration and signal input
Requirement No 1 : [Highway_DisplayUnit]:
Inputs to this particular subsystem are “Highway_Input_Signal”, “Enable_Display”, “Input_Switch”. These three input signals, when assigned to a particular value will give output signals of specific value. The output signals are “Highway_Display_Mode_1”, “Highway_Display_Mode_2”, “Highway_Display_Mode_3”, “Highway_Display_Mode_4”. The requirement must be implemented in the form of a Stateflow logic.
|
Condition |
Action |
|
Highway_Input_Signal = 1 Enable_Display = off Input_Switch = on |
Highway_Display_Mode_1 = 232 Highway_Display_Mode_2 = 183 Highway_Display_Mode_3 = 41 Highway_Display_Mode_4 = 94 |
|
Highway_Input_Signal = 1 Enable_Display = on Input_Switch = on |
Highway_Display_Mode_1 = 213 Highway_Display_Mode_2 = 183 Highway_Display_Mode_3 = 9 Highway_Display_Mode_4 = 94 |
Requirement No 2 [Lane_DisplayUnit]:
Inputs to this particular subsystem are “Enable_Display”, “Input_Switch”, “Lane_Input_Signal”. These three input signals, when assigned to a particular value will give output signals of specific value. The output signals are “Lane_Display_Mode_1”, “Lane_Display_Mode_2”, “Lane_Display_Mode_3”, “Lane_Display_Mode_4”. The requirement must be implemented in the form of Stateflow logic.
|
Condition |
Action |
|
Lane_Input_Signal= 6 Enable_Display = off Input_Switch = on |
Lane_Display_Mode_1 = 132 Lane_Display_Mode_2 = 185 Lane_Display_Mode_3 = 54 Lane_Display_Mode_4 = 67 |
|
Lane_Input_Signal= 6 Enable_Display = on Input_Switch = on |
Lane_Display_Mode_1 = 127 Lane_Display_Mode_2 = 248 Lane_Display_Mode_3 = 186 Lane_Display_Mode_4 = 84 |
STATEFLOW
Lane_DisplayUnit
Requirement No 3:
Signals coming from both subsystems “Highway_Display_Mode_1” & “Lane_Display_Mode_1” are given as inputs to a switch block which will have input signal “Highway_Input_Signal” given as 2nd input to the switch block. Corresponding output from this particular switch block is output signal “Display_Mode_1”.
Signals coming from both subsystems “Highway_Display_Mode_2” & “Lane_Display_Mode_2” are given as inputs to a switch block which will have input signal “Highway_Input_Signal” given as 2nd input to the switch block. Corresponding output from this particular switch block is output signal “Display_Mode_2”.
Signals coming from both subsystems “Highway_Display_Mode_3” & “Lane_Display_Mode_3” are given as inputs to a switch block which will have input signal “Highway_Input_Signal” given as 2nd input to the switch block. Corresponding output from this particular switch block is output signal “Display_Mode_3”.
Signals coming from both subsystems “Highway_Display_Mode_4” & “Lane_Display_Mode_4” are given as inputs to a switch block which will have input signal “Highway_Input_Signal” given as 2nd input to the switch block. Corresponding output from this particular switch block is output signal “Display_Mode_4”.
SUBSYSTEM:
OVERALL MODEL:
Change the system target file
The system target file must be changed to autosar.tlc
AUTOSAR DICTIONARY
XML file:
In the datatype package provide the file name.
S-R Interface
The S-R Interface are SRif_Display_Mode_1, SRif_Display_Mode_2, SRif_Display_Mode_3, SRif_Display_Mode_4, SRif_Enable_Display, SRif_Highway_Input_Signal, SRif_Input_Switch, SRif_Lane_Input_Signal.
Input runnables
These are the input runnables used in the model. These are the receiver ports
Rp_Highway_Input_Signal, Rp_Enable_Display,Rp_Input_Switch, Rp_Lane_Input_Signal
Output runnables
Pp_Display_Mode_1, Pp_Display_Mode_2, Pp_Display_Mode_3, Pp_Display_Mode_4 are the sender ports used
Data Input runnables
The Data Input runnables is DE_Highway_Input_Signal are used.
PORT MAPPING
The input output port mapping will be displayed in the bottom of the window
MODEL ADVISOR
CODE GENERATION:
The code generation report is displayed. Instead of ert.tlc the autosar.tlc will be there in the system target file. In the ert_main.c the code will be generated. For autosar the autosar.c the code will be generated.
The similar code will be generated for autosar as my matlab does not support autosar. I have generated code in ert.tlc
/*
2 * File: ert_main.c
3 *
4 * Code generated for Simulink model 'High_lane'.
5 *
6 * Model version : 1.6
7 * Simulink Coder version : 9.1 (R2019a) 23-Nov-2018
8 * C/C++ source code generated on : Wed Sep 15 17:20:32 2021
9 *
10 * Target selection: ert.tlc
11 * Embedded hardware selection: Intel->x86-64 (Windows64)
12 * Code generation objectives: Unspecified
13 * Validation result: Not run
14 */
15
16 #include
17 #include /* This ert_main.c example uses printf/fflush */
18 #include "High_lane.h" /* Model's header file */
19 #include "rtwtypes.h"
20
21 /*
22 * Associating rt_OneStep with a real-time clock or interrupt service routine
23 * is what makes the generated code "real-time". The function rt_OneStep is
24 * always associated with the base rate of the model. Subrates are managed
25 * by the base rate from inside the generated code. Enabling/disabling
26 * interrupts and floating point context switches are target specific. This
27 * example code indicates where these should take place relative to executing
28 * the generated code step function. Overrun behavior should be tailored to
29 * your application needs. This example simply sets an error status in the
30 * real-time model and returns from rt_OneStep.
31 */
32 void rt_OneStep(void);
33 void rt_OneStep(void)
34 {
35 static boolean_T OverrunFlag = false;
36
37 /* Disable interrupts here */
38
39 /* Check for overrun */
40 if (OverrunFlag) {
41 rtmSetErrorStatus(High_lane_M, "Overrun");
42 return;
43 }
44
45 OverrunFlag = true;
46
47 /* Save FPU context here (if necessary) */
48 /* Re-enable timer or interrupt here */
49 /* Set model inputs here */
50
51 /* Step the model */
52 High_lane_step();
53
54 /* Get model outputs here */
55
56 /* Indicate task complete */
57 OverrunFlag = false;
58
59 /* Disable interrupts here */
60 /* Restore FPU context here (if necessary) */
61 /* Enable interrupts here */
62 }
63
64 /*
65 * The example "main" function illustrates what is required by your
66 * application code to initialize, execute, and terminate the generated code.
67 * Attaching rt_OneStep to a real-time clock is target specific. This example
68 * illustrates how you do this relative to initializing the model.
69 */
70 int_T main(int_T argc, const char *argv[])
71 {
72 /* Unused arguments */
73 (void)(argc);
74 (void)(argv);
75
76 /* Initialize model */
77 High_lane_initialize();
78
79 /* Attach rt_OneStep to a timer or interrupt service routine with
80 * period 0.2 seconds (the model's base sample time) here. The
81 * call syntax for rt_OneStep is
82 *
83 * rt_OneStep();
84 */
85 printf("Warning: The simulation will run forever. "
86 "Generated ERT main won't simulate model step behavior. "
87 "To change this behavior select the 'MAT-file logging' option.\n");
88 fflush((NULL));
89 while (rtmGetErrorStatus(High_lane_M) == (NULL)) {
90 /* Perform other application tasks here */
91 }
92
93 /* Disable rt_OneStep() here */
94
95 /* Terminate model */
96 High_lane_terminate();
97 return 0;
98 }
99
100 /*
101 * File trailer for generated code.
102 *
103 * [EOF]
104 */
105
RESULT:
Thus the Simulink Data Dictionary has been created for the calibration and signal data, an algorithm has been developed for one of the feature of Highway Lane Changing Assisstance. The Model Advisor report has been generated and C code are generated.