Project 2-Highway Assistant-Lane Changing Assistant
Highway Assistant – Lane Changing Assistant
Introduction to the Feature:
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.
Problem Statement:
To develop one specific requirement of Highway Assistant – Lane Changing Assistant algorithm. Please note that the whole Highway Assistant – Lane Changing Assistant is a very huge algorithm & only one small part of the logic is implemented here. Idea is to familiarize with concepts of Autosar Software Component Development in MATLAB Environment by following the Model Based Development guidelines. The Project must be done keeping in mind the following processes & steps.
- 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.
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 |

Here the data dictionary has been created and all the data are stored as per the requirement. One thing should be noted here, as this model code generation would be performed on the basis of AUTOSAR, that's why the storage class has been defined as the 'Auto'. If the storage class would be defined on the basis of the signal property, the compiler will through an error during code generation.
The prepared model:

This model is subdivided into three major parts. Three subsystems are performing three different algorithms related to each other. All three are described as follows.
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 |

As per the requirement three input signals, Highway_Input_Signal, Enable_Display, and Input_Switch are going inside the subsystem and the four output signals coming out from the subsystem are Highway_Display_Mode_1, Highway_Display_Mode_2, Highway_Display_Mode_3, Highway_Display_Mode_4. All the signals of input as well as output are resolved from the starting point. Here the use of GoTo and From blocks are for using the same signals for the different subsystems as well. Inside the Requirement_1 subsystem, a Stateflow algorithm has been implemented.


Two conditions are stated in the two state block and the corresponding conditions have been put inside the square bracket. Here the use of '==' is to compare the values and the sign '&&' is used for whether both operands are true. Three dots after '&&' to break the line.
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 |

As per the requirement, three input signals, Lane_Input_Signal, Enable_Display, and Input_Switch are going inside the subsystem and the four output signals coming out from the subsystem are Lane_Display_Mode_1, Lane_Display_Mode_2, Lane_Display_Mode_3, Lane_Display_Mode_4. All the signals of input as well as output are resolved from the starting point. Here by using GoTo block the input signals Enable_Display and Input_Switch are fed to the subsystem. Inside the Requirement_1 subsystem, a Stateflow algorithm has been implemented.


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”.

All the input signals are used in each switch block by using From Block. For different Highway_Display_Mode and Lane_Display_Mode different Display_Mode output values are coming out. Here in all switch blocks, the condition is the Highway_Input_Signal value. If the Highway_Input_Signal value is matched with the Highway_Display_Mode then the corresponding Display data will come out as set in the data dictionary.
AUTOSAR Port Mapping and data dictionary:
- How to create AUTOSAR dictionary:
To open the AUTOSAR Dictionary, we need to follow the following process:
- First, we have to open the Simulink model.
- Before adding the AUTOSAR dictionary, we should specify the code generation file from the model settings.
- Inside the model settings, there is a tab as name 'Code Generation'.
- Here we have to select the target file as 'Autosar.tlc'.
- Next, click on the App tab, at the top of the Simulink window.
- From the drop-down option, we will find out the 'Autosar Component' in the Code Generation.
- When we click on the 'Autosar Component', a tab will be opened, and several details have to be checked. If it's according to the requirement, then we have to click on 'Next'.
- Usually, it is default and there does not have necessity to change any particular options.
- The subsets are Set Component and Set Interface, and then we have to click on Finish.
- Finally 'AUTOSAR SW Component' will appear at the bottom under the Simulink window.
- By clicking on this option, AUTOSAR dictionary will be opened.
- Here, by clicking on the configure autosar data dictionary, we will go to the dictionary configuration and as per necessity, we can configure all the parameters.
- XML File settings:

- Interface and corresponding Data Elements

All the interface ports' names will be edited by 'SRIf_' and Data Elements by 'DE_' as the prefix.
- Runnable

- Receiver Port

All the Receiver ports' names will be edited by Rp_ as the prefix.
- Sender Port

All the sender ports' names will be edited by Pp_ as the prefix.
Model Advisor Report as per MAAB Guidelines:

The model has been checked as per the MAAB(MathWorks Automotive Advisory Board) guidelines where 144 signals were recognized to check and from these 118 signals were passed and 26 signals came out as warnings. The generated report image is as follows.
Code Generation:
- To generate code in the AUTOSAR environment, the code generation settings and solver settings will be as follows.
Code Generation: System target file: Autosar. tlc
Solver Settings: Discrete-time step
- Generated Code :



Attached Files:
1. Simulink Model of Lane Changing Assistant feature(.slx)
2. Data dictionary of the respective model(.sldd)
3. AUTOSAR generated coder files(in ZIP format)
4. Model Advisor Report(.pdf)(https://drive.google.com/file/d/1mKYMIFu_c1oMWaEdXN7VDREAkBaMwsbX/view?usp=sharing) [File size is too big to upload].