Project 2-Highway Assistant-Lane Changing Assistant
PROJECT 2- Highway Assistant – Lane Changing Assistant
I. Aim: To develop a Simulink model of one specific part of the logic of the Highway Assistant – Lane Changing Assistant algorithm in MATLAB as per the given requirements.
II. Theory:
Introduction to the Highway Assistant 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 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, and 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.
III. Data Dictionary:
A new data dictionary is created named "HA_LCA_dd.sldd"

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

But since we have to adapt Autosar Coder, we will change the storage class of all signals to auto.

Save the Data Dictionary.
IV. Configuration Settings:
We will update some configuration settings like solver and code generation prior to building the Simulink model.

Code Generation Profile was selected as Autosar Coder "autosar.tlc".

Save the Model.
V. Simulink Model (P2_HA_LCA.slx):


Requirement No 1 [Highway_DisplayUnit]:
Inputs to this particular subsystem are “Highway_Input_Signal”, “Enable_Display”, and “Input_Switch”. These three input signals, when assigned to a particular value will give output signals of a specific value. The output signals are “Highway_Display_Mode_1”, “Highway_Display_Mode_2”, “Highway_Display_Mode_3”, and “Highway_Display_Mode_4”. The requirement must be implemented in the form of a Stateflow logic.
Condition Action
Highway_Input_Signal = 1 Highway_Display_Mode_1 = 232
Enable_Display = off Highway_Display_Mode_2 = 183
Input_Switch = on Highway_Display_Mode_3 = 41
Highway_Display_Mode_4 = 94
Highway_Input_Signal = 1 Highway_Display_Mode_1 = 213
Enable_Display = on Highway_Display_Mode_2 = 183
Input_Switch = on 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”, and “Lane_Input_Signal”. These three input signals, when assigned to a particular value will give output signals of a specific value. The output signals are “Lane_Display_Mode_1”, “Lane_Display_Mode_2”, “Lane_Display_Mode_3”, and “Lane_Display_Mode_4”. The requirement must be implemented in the form of Stateflow logic.
Condition Action
Lane_Input_Signal= 6 Lane_Display_Mode_1 = 132
Enable_Display = off Lane_Display_Mode_2 = 185
Input_Switch = on Lane_Display_Mode_3 = 54
Lane_Display_Mode_4 = 67
Lane_Input_Signal= 6 Lane_Display_Mode_1 = 127
Enable_Display = on Lane_Display_Mode_2 = 248
Input_Switch = on Lane_Display_Mode_3 = 186
Lane_Display_Mode_4 = 84

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 the 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 the 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 the 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 the output signal “Display_Mode_4”.

Save the Model.
VI. Requirement Tagging:
For Tagging, we will open Requirement Editor first and then will add a new requirement set.

One by one will add all requirements and will link them to their respective subsystem.


NOTE: Instead of this we can also directly do the requirement tagging from the word document. Right-click the subsystem block->Requirements->Link to selection to word.

Requirement Tagging Report

Save the Model.
VII. AutoSAR Dictionary:
Setting XML options

Updating SR interface-
- For Input Signals- For the 4 inport signals in the model, SR Interfaces are prefixed SRIf_ & their corresponding Data elements are prefixed DE_.


- For Output signals - For the 4 outport signals in the model, SR Interfaces are prefixed SRIf_ & their corresponding Data elements are prefixed DE_.

Updating Receiver Ports- For the 4 inport signals in the model, runnable is created. Input runnable is prefixed Rp_.

Updating Sender Ports- For the 4 outport signals in the model, runnable is created. Output runnable is prefixed Pp_.

Runnable- Setting Timing Event and Init Event

Save the Model at each step so that no data gets lost.
VIII. AutoSAR Port Mapping:
Mapping Functions

Mapping Inports

Mapping Outports

Save the Model at each step so that no data gets lost.
IX. Model Advisor Report- MAB Guideline Check:
Modeling Tab->ModelAdvisor Check

X. Code Generation
AUTOSAR -> Quick Start




Code Generation Process starts.

The code is generated.

Note: We can also directly do Code Generation by clicking on Generate Code under the AUTOSAR tab, but we chose Quick Start so that we can check whether all configuration setting according to AUTOSAR is updated or not. If not, Quick Start will update them before generating code as we can see above.
XI. Result:
- This model is developed in MATLAB Simulink per MBD guidelines.
- Code Generation Profile was selected as Autosar Coder.
- Simulink Data Dictionary was created and linked to the model.
- All the input & output signals were mapped into the Autosar Editor.
- Model Advisor Report was generated, which was then followed by Code Generation.