Project 2 Adaptive Cruise Control

Project

Adaptive Cruise Control

Aim:

• To develop the Adaptive Cruise Control feature as per the Requirement Document using MATLAB Simulink.
• To follow all the MBD-related processes such as Requirement Tagging & Traceability, SLDD creation, Configuration Parameter changes, Model Advisor check & Code Generation.

Adaptive cruise control:

The main reason behind cruise control technology is to make drivers relax behind the wheel. Because of this, their driving experience becomes safer, thrilling and also saves fuel consumption. By monitoring other vehicles and objects on the road, adaptive cruise control enables a safe and comfortable driving experience. It helps the driver keep a steady vehicle speed at a given moment. The driver can set their preference regarding certain factors, such as the distance to the car in front, and driving mode. Together with information about speed limits, road curvature, accident data, and more, these choices influence the automatically selected speed. As less expensive sensors reached the market, adaptive cruise control is steadily becoming a standard feature in new vehicles today.

In slow-moving traffic, it automatically stops or starts vehicle movement under driver supervision. The car will brake and accelerate on its own while maintaining a safe distance from the vehicle in front. Intelligent cruise control can automatically adjust the set speed to the newly detected speed limit when the driver is passing a speed limit sign. This is done by fusing camera observation and map data to provide reliable speed restriction information.

Radar-based systems work by placing radar-based sensors on or around plastic fascia to detect your vehicle's surroundings. Each radar sensor works together to create a comprehensive picture of the vehicle's proximity to other cars or potentially hazardous objects. This type of sensor can look different depending on the design and model of the car.

ACC uses sensory data to predict the actions of neighboring vehicles. This means that your car might slow down to brake for another vehicle suddenly switching lanes and, in doing so, promotes passenger safety.

Creation of Simulink Data Dictionary file (SLDD):

A Simulink Data Dictionary (SLDD) file is created that contains input, output signals, and calibration parameters used in the model. SLDD file is created by clicking on Modeling, then ‘Model Properties’, then ‘External Data’, and specifying a file name for the Data Dictionary.

Signals & Calibration Data List:

Link to the data dictionary, and add a NeDatata Dictionary

Go to Model Advisor Tool and in Design data Add the required Signals as per the given data

Fig 1: Data Dictionary file in Model Explorer

Creation of Adaptive Cruise Control Model:

Requires Blocks:

• Subsystem
• Input
• Outport

Fig 2: Adaptive Cruise Control Model(Required ScreenShots)

Fig 3: Lead_Vehicle, Drive_Vehicle, and ACC_Algorithm subsystems present inside Adaptive_Cruise Control Subsystem.

(Required ScreenShots)

Requirement 1– Lead Vehicle:

• Lead Vehicle is a vehicle that is driving on the road ahead of our drive vehicle. The subsystem Lead_Vehicle contains two input signals (Signal Name: CameraInput_LeadVehicle & RadarInput_LeadVehicle).
• Ideally sensor fusion techniques will be deployed to process & analyze data from cameras & radar. For complexity reasons, in this model, such algorithms are not used.
• The speed profile output (Signal Name: LeadVehicle_Speed) is obtained by adding both the radar input and camera inputs (Signal Name: CameraInput_LeadVehicle & RadarInput_LeadVehicle).
• Speed data of the lead vehicle is critical in implementing the Adaptive Cruise Control algorithm.

Fig 4: Lead_Vehicle Subsystem(Required ScreenShots)

Requirement 2 – Drive Vehicle:

• Drive Vehicle is the vehicle driven by the user & this is the vehicle that has an ACC algorithm in it.
• Like the Lead Vehicle, the Drive Vehicle algorithm also has 2 input signals (Signal Name: CameraInput_DriveVehicle, RadarInput_DriveVehicle) & one signal coming as an Input to this subsystem (Signal Name: Acceleration_Mode) – three inputs into this requirement in total.
• Like the above requirement, sensor fusion techniques will also be deployed here, but for complexity reasons, they are not used in this model.
• Two output signals come from this subsystem (Signal Name: DriveVehicle_Speed & LeadVehicle_Detected).
• Signal DriveVehicle_Speed is the summation of three input signals mentioned above & LeadVehicle_Detected is renamed from Input Signal RadarInput_DriveVehicle by mere use of Signal Conversion block.

Fig 5: Drive_Vehicle Subsystem(Required ScreenShots)

Requirement 3 – Adaptive Cruise Control Algorithm:

• Adaptive Cruise Control feature has 3 major modes of operation: OFF Mode, STANDBY Mode & ON Mode. This particular requirement is implemented as state machine logic in Simulink.
• The input signals to this state machine system are (Signal Name: Time_Gap, Set_Speed, Set_Gap, CruiseSwitch, SetSwitch).
• The output signals (Signal Name: DriveVehicle_Speed & LeadVehicle_Detected) from requirement-2 are fed back as an input signal into this state machine block.
• Additionally, the output signal (Signal Name: LeadVehicle_Speed) from requirement-1 is given as an input signal to this state machine block as well.
• Output from this subsystem is a signal (Signal Name: Acceleration_Mode) that governs the vehicular speed of the drive vehicle and automatically adjusts its speed & velocity to match the lead vehicle.

Fig 6: State machine chart ACC_Logic in ACC_Algorithm subsystem for Requirement 3(Required ScreenShots)

Requirement 3a – ACC OFF MODE state logic:

• This is the default state inside state machine logic. Output signal Acceleration_Mode is at value 0 in this state.
• This state is governed by the input signal CruiseSwitch.
• If CruiseSwitch is equal to 1, state ACC STANDBY mode will get activated. If CruiseSwitch is equal to 0, state ACC OFF mode will get activated, from either ACC ON mode or ACC STANDBY mode.

Requirement 3b – ACC STANDBY MODE state logic:

• This is the second activated state inside state machine logic. Output signal Acceleration_Mode is at value 1 in this state.
• This state is governed by both input signals CruiseSwitch & SetSwitch.
• If CruiseSwitch is equal to 1, state ACC STANDBY mode will get activated. If CruiseSwitch is equal to 0, state ACC OFF mode will get activated, from either ACC ON mode or ACC STANDBY mode
• If SetSwitch is equal to 1, state ACC ON mode will get activated. If SetSwitch is equal to 0, state ACC STANDBY mode will get activated.

Requirement 3c – ACC ON MODE state logic:

This state will be activated when the input signal SetSwitch is equal to 1. There are sub-state sales to this state logic: They are:

• LeadVehicle_Detected_Follow (Default)
• LeadVehicle_Not_Detected
• LeadVehicle_Detected_Resume
• LeadVehicle_Not_Detected_Resume
• LeadVehicle_Speed_lessthan_Set_Speed

Requirement 3c (i) – LeadVehicle_Detected_Follow (ACC ON MODE):

• This is the default substate inside the Athe CC ON MODE state. Output signal Acceleration_Mode is equal to 2.
• Condition to transit from LeadVehicle_Detected_Follow to LeadVehicle_Not_Detected; Input signal condition LeadVehicle_Detected == 0.
• Condition to transit from LeadVehicle_Detected_Follow to LeadVehicle_Speed_lessthan_Set_Speed; Input Signals condition (LeadVehicle_Detected == 1) && (LeadVehicle_Speed < Set_Speed) || (Time_Gap < Set_Gap)

Requirement 3c (ii) – LeadVehicle_Not_Detected (ACC ON MODE):

• Output signal Acceleration_Mode is equal to 1.
• Condition to transit from LeadVehicle_Not_Detected to LeadVehicle_Detected_Follow; Input signals condition [(LeadVehicle_Detected==1) && (DriveVehicle_Speed == Set_Speed) && (LeadVehicle_Speed >= Set_Speed) && (Time_Gap >= Set_Gap)]
• Condition to transit from LeadVehicle_Not_Detected to LeadVehicle_Speed_lessthan_Set_Speed; Input signals condition [(LeadVehicle_Detected == 1) && (LeadVehicle_Speed < Set_Speed) || (Time_Gap < Set_Gap)]

Requirement 3c (iii) – LeadVehicle_Detected_Resume (ACC ON MODE):

• Output signal Acceleration_Mode is equal to 3.
• Condition to transit from LeadVehicle_Detected_Resume to LeadVehicle_Detected_Follow; Input signals condition [(DriveVehicle_Speed == Set_Speed) && (LeadVehicle_Speed >= Set_Speed) && (Time_Gap >= Set_Gap)]
• Condition to transit from LeadVehicle_Detected_Resume to LeadVehicle_Not_Detected_Resume; Input signal condition LeadVehicle_Detected==0.
• Condition to transit from LeadVehicle_Detected_Resume to LeadVehicle_Speed_equal_Set_Speed; Input Signal condition [(DriveVehicle_Speed < Set_Speed) && (LeadVehicle_Speed > DriveVehicle_Speed) && (Time_Gap >= Set_Gap)]

Requirement 3c (iv) - LeadVehicle_Not_Detected_Resume (ACC ON MODE):

• Output signal Acceleration_Mode is equal to 1.

Requirement 3c (v) - LeadVehicle_Speed_lessthan_Set_Speed (ACC ON MODE):

• Output signal Acceleration_Mode is equal to 4.
• Condition to transit from LeadVehicle_Speed_lessthan_Set_Speed to LeadVehicle_Not_Detected; Input signal condition [(LeadVehicle_Detected == 0) && (DriveVehicle_Speed == Set_Speed)]
• Condition to transit from LeadVehicle_Speed_lessthan_Set_Speed to LeadVehicle_Speed_equal_Set_Speed; Input signals condition [((LeadVehicle_Speed*1.25>=DriveVehicle_Speed) && (LeadVehicle_Speed * 0.75<=DriveVehicle_Speed)) && (DriveVehicle_Speed < Set_Speed) && ((Time_Gap<=1.25*Set_Gap) && (Time_Gap >=0.75*Set_Gap))]

Requirement 3c (vi) - LeadVehicle_Speed_equal_Set_Speed (ACC ON MODE):

• Output signal Acceleration_Mode is equal to 5.
• Condition to transit from LeadVehicle_Speed_equal_Set_Speed to LeadVehicle_Not_Detected_Resume; Input signal conditions is [(LeadVehicle_Detected == 0) || (DriveVehicle_Speed <= Set_Speed)]
• Condition to transit from LeadVehicle_Speed_equal_Set_Speed to LeadVehicle_Detected_Resume; Input signal conditions [(DriveVehicle_Speed < Set_Speed) && (LeadVehicle_Speed > DriveVehicle_Speed) || (Time_Gap >= Set_Gap)]
• Condition to transit from LeadVehicle_Speed_equal_Set_Speed to LeadVehicle_Speed_lessthan_Set_Speed; Input signals conditions [(LeadVehicle_Speed<Set_Speed) && (LeadVehicle_Speed<DriveVehicle_Speed) || (Time_Gap == 0.75*Set_Gap)]

Fig 7: ACC_Logic chart in ACC_Algorithm subsystem(Required ScreenShots)

Addition of Symbol Panes:

Requirement Tagging of Simulink Model:

The requirements ‘Requirement 1’, ‘Requirement 2’, and ‘Requirement 3’ as provided in the Requirements Word document are tagged to their corresponding subsystem in the Simulink Model.

The steps involved in tagging a requirement in the Simulink model are to first highlight the requirement stated in the Word document, then right-click on the subsystem in the model that has to be tagged, then select ‘Requirements’ and then ‘Link to Selection in Word’

Fig 8: Highlighting the requirement to be tagged in the requirement Word document.

Fig 9: Tagging ‘Lead_Vehicle’ subsystem to its requirement in Word document

MAAB Guidelines Check-in Model Advisor:

A check is performed using the ‘Model Advisor’ tool in Simulink to see whether the developed model meets the modeling standards for MAAB.

Change solver setting and add C code

Code generating Setting

Go to the Model Advisor tool for Taking Various test

Generation Of Report

Fig 10: Model Advisor Report for MAAB guidelines check.

Generation of C – Code from the model:

Using the embedded coder tool in MATLAB, C code is generated for the model.

Fig 11: C code generation using embedded coder in MATLAB.

C-Code: