Project 2-Highway Assistant-Lane Changing Assistant
PROJECT : Highway Assistant-Lane Changing Assistant
AIM :
Develop model as per given requirement and generate AUTOSAR software complier code.
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 |
STEPS:
DATA DICTIONARY :
Create a Data Divtionary file by modelling - Link to Data Dictionary -Add new - Give the name for HighwaySLDD file.create all input output signals into dictionary.As per the question select data parameters.
If you see it here , we can edit and save all parameters under one file.No need to change parameters every time you open the model next time.Once you save all parameters for variable in SLDD it will be saved until you use the file for model.

Reqirement 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 |


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

MAIN MODEL :
Make a simulink model file as per question requirement1,2 and 3.


SIGNAL Resolve and Propagation :
- In signal properties you can resolve and propagate the signal.
- If the signal is the first type to appear in system you have to resolve at othervise propagate it.
- Signal resolve and propagation is most important for code generation.
- You can propagate the signal direclty on double click on signal and type only.Signals will propagate directly.


REQUREMENT TAGGING :
- Requirement tagging is nothing but linking your requirement document to the model subsystem which is related to that requirement .
- It is given advantage to understand the model when someone new is handling this file .
- We done requirement tagging by right clicking on subsystem under requirement parameter you can tag the requirement
- First you have to select the requirement in the requirement document to tag with related subsystem . Also , the file has to be saved in the same directory.


Model Configuration for AUTOSAR Code generation & Solver Settings
- There are mainly two settings we have to do which are solver setting and code generation setting .
- For code generation we can only use a fixed step solver .
- As per requirement we change the solver setting to fix step discrete and fixed step size as Auto or 0.01.
- For AUTOsar code generation in system target file will always autosar.tlc which is autosar component designer coder . Which generates Autosar compile code .


here we select AUTOSAR system target file to generate autosar code. To map Simulink model element to AUTOSAR Software componenet element.
- Open a model for which AUTOSAR system target file autosar.tlc is selected.
- Create or open a mapped view of the AUTOSAR model.In the model window, do one of the following:
- from the APPS tab, open the AUTOSAR components Designer app. Click the perspective control in the lower-right corner and select code. The following code mapping autosar software component window will open at the bottom left corner.
AUTOSAR DICTIONARY :
Here we add XML Options,server receiver interface,sender ports,receiver ports, and runnable one by one.

XML OPTIONS :
Here we edited the XML options to create a data file for code generation.

S-R INTERFACE :
Here before creating ' inports; and 'outports'. the interfaces were created in order to map the inports and outport,interfaces were Prefic SRIf_ & their corresponding Data elements were Prefix DE _ .


RECEIVER PORTS :
Here inports were created and input runnable were prefix Rp_ .

SENDER PORTS :
Here outports were created and output runnable were prefix Pp_ .

RUNNABLE :
Here runnable were created , one for initializing and other for time event,event was also created as Init event and TimingEvent.

PORT MAPPING :
The code mappings editor provides in canvas access to AUTOSAR mapping information,with batch editing,element filtering,easy navigation to model elements and AUTOSAR properties , and model element traceability.
Navigate the Code Mappings editor tabs to perform these actions :
- Map a Simulink entry - point function to an AUTOSAR runnable .
- Map a Simulink inport or outport to an AUTOSAR receiver or sender port and a sender - receiver data element , with a specific data access mode .
- Map a Simulink model workspace parameter to an AUTOSAR component parameter .
- Map a Simulink data store to an AUTOSAR variable .
- Map a Simulink block signal or state to an AUTOSAR variable .
- Map a Simulink data transfer line to an AUTOSAR inter - runnable variable ( IRV ) .
- Map a Simulink function caller to an AUTOSAR client port and a client - server operation .
- Use the Filter contents field ( where available ) to selectively display some elements , while omitting others , in the current view .
- After mapping model elements , click the Validate button to validate the AUTOSAR component configuration . If errors are reported , address them and then retry validation.
Here we select runnables for initializing and time events.

Here mapping of inports was done with the corresponding data elements.

Here mappingof outports was done with the corresponding data elements.

Here we check our mapping to see if there are any bugs.if mapping has bugs,we can solve them immediately.

MAAB Guidelines Check ( Model Advisor) :
- Under modelling tab there is model advisor tab to check model with standard guidelines.

- Tab on that tab this window will open to slect model.
- After slecting the model , the model advisor checked for the model first.
- Then in the task option we have to select modelling standard for MAAB.Then we have to select which guideline we have to check.
- Then run advisor check for selected checked guidelines.
- If some error occur you can check for that inder the MAAB tab.
- There are also some warnings.If it's greater than the requirement solves the warning and check again fot that warning.
- You can check for individual error and warning also.
- If you are searching for a particular block in a system.You can click on report on any block it will take you to that block.
- After checking all models with standards guidelines, you can generate a model advisor report.
- If you click on any label highlighted in the report it will go directly to that particular model or signal.

QUICK START :
If we missed out the configuration properties and also , we have to take care of all updating the signal name appropriately for that we will list out and quick start over here so it will list out and show any mistake apart from that this is an automated procedure to convert your model into a generated code to bypass the manual mapping.


Here we got out AUTOSAR compile code for AUTOSAR software component.
CONCLUSION :
The code generation for model - based development is very easy compared to writing millions of codes . It will possible with right solver and code generation setting and mainly due to model adviser check for standard MAAB guidelines . Hence , we can conclude that with proper settings and standard guidelines it will be very easy to build a code for the model . It will be cost efficient and a time saving method of design and development of model . It will be possible due to MATLAB . There is a lot of software for the same in the modelling environment but for better understanding and ease of use we can always prefer MATLAB .
AUTOSAR CODE :