Project 2 Adaptive Cruise Control
PROJECT ADAPTIVE CRUISE CONTROL:
Theory:
Adaptive Cruise Control: Adaptive cruise control (ACC ) is a form of intelligent cruise control, also known as active cruise control, autonomous cruise control, smart cruise control, and radar cruise control. A radar sensor is installed on the car’s front grille, which can sense how close or far away the vehicle in front is. By sensing this distance, the car will “adapt” its cruise control speed to maintain a safe distance from the vehicle ahead.
Drivers can set the interval from the steering wheel at how close (or how far away) they want to be from the vehicle in front. ACC will apply the brakes in traffic relative to the set distance the driver specifies. Those who drive more defensively may want it on the farthest setting so the gap between cars in front is wider.
A radar sensor is usually at the core of the Adaptive Cruise Control. Installed at the front of the vehicle, the system permanently monitors the road ahead. As long as the road ahead is clear, the cruise control feature maintains the speed set by the driver. If the system spots a slower vehicle within its detection range, it gently reduces speed by releasing the accelerator or actively engaging the brake control system. If the vehicle ahead speeds up or changes lanes, the cruise control automatically accelerates to the driver’s desired speed.
Standard Adaptive Cruise Control can be activated from speeds of around 30 km/h (20 mph) upwards and supports the driver, primarily on cross-country journeys or on freeways. The cruise control stop & go variant is also active at speeds below 30 km/h (20 mph). It can maintain the set distance to the preceding vehicle even at very low speeds and can decelerate to a complete standstill. When the vehicle remains stopped longer, the driver needs only to reactivate the system, for example by briefly stepping on the gas pedal to return to cruise control mode. In this way, cruise control stop & go supports the driver even in heavy traffic and traffic jams.
Since Adaptive Cruise Control is a comfort and convenience system, brake interventions and vehicle acceleration only take place within defined limits. Even with Adaptive Cruise Control switched on, it remains the driver’s responsibility to monitor the speed and distance from the vehicle in front.
AIM: To develop an MBD-compliant Adaptive Cruise Control feature as per the provided requirement document using MATLAB Simulink
OBJECTIVE:
- Developing Adaptive Cruise Control feature as per the Requirement Document using MATLAB Simulink.
- Follow all the MBD-related processes: Requirement Tagging & Traceability, SLDD creation, Configuration Parameter changes, Model Advisor check & Code Generation.
- In Configuration Parameters: enable “Support Floating Numbers” under Code Generation settings.
- Use Embedded Coder to generate the code.
- If choosing code generation, the Storage class for input signals: ImportedExtern; the Storage class for output signal: Export to File; the Storage class for local signals: localizable; the Storage class for calibration signals: Const.
- Choose sample time for all signals as 0.01s
Steps to Develop MBD-compliant Adaptive cruise control model:
STEP 1: Design a model of Adaptive cruise control Simulink model
Based on the data from the requirement document, the following subsystems were designed.
Requirement 1– Lead Vehicle:
- Lead Vehicle is a vehicle that is driving in the road ahead of our drive vehicle. Two input signals (Signal Name: CameraInput_LeadVehicle & RadarInput_LeadVehicle).
- Ideally, sensor fusion techniques will be deployed to process & analyze data from camera & radar. For complexity reasons, let’s not adapt to any such algorithms.
- We can simply add both the radar & camera inputs & the corresponding output is read as Speed profile output (Signal Name: LeadVehicle_Speed).
- Speed data of the lead vehicle is critical in implementing the Adaptive Cruise Control algorithm.
Requirement 2 – Drive Vehicle:
- Drive Vehicle is the vehicle driven by the user & this is the vehicle that has the 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, for complexity reasons we are ignoring them.
- 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 the Signal Conversion block.
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 has to be 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).
- Also, 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) which governs the vehicular speed of the drive vehicle, and automatically adjusts its speed & velocity to match the lead vehicle.
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 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 input signal SetSwitch is equal to 1. There are 6 sub states 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
- LeadVehicle_Speed_equal_Set_Speed
Requirement 3c (i) – LeadVehicle_Detected_Follow (ACC ON MODE):
- This is the default sub state inside ACC 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 (i) – LeadVehicle_Detected_Follow (ACC ON MODE):
- This is the default sub state inside ACC 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)]
This subsystem is developed as control logic and is made using the concept of state flow. It takes 8 inputs and gives the acceleration mode as the final output.
Stateflow Symbols Pane.
STEP 2: Create an SLDD (Simulink data dictionary) containing all the input and output signals, calibration values, constants, etc.
Based on the Signals and calibration list
Signals & Calibration Data List:
|
Signal / Calibration Name |
Signal Type |
Data Type |
Dimension |
Min |
Max |
Initial Value |
Units |
|
CameraInput_LeadVehicle |
Input |
Uint8 |
1 |
0 |
255 |
- |
- |
|
RadarInput_LeadVehicle |
Input |
Uint8 |
1 |
0 |
255 |
- |
- |
|
CameraInput_DriveVehicle |
Input |
Uint8 |
1 |
0 |
255 |
- |
- |
|
RadarInput_DriveVehicle |
Input |
Uint8 |
1 |
0 |
255 |
- |
- |
|
Time_Gap |
Input |
Uint8 |
1 |
0 |
255 |
- |
- |
|
Set_Speed |
Input |
Uint8 |
1 |
0 |
255 |
- |
- |
|
Set_Gap |
Input |
Uint8 |
1 |
0 |
255 |
- |
- |
|
CruiseSwitch |
Input |
Boolean |
1 |
0 |
1 |
- |
- |
|
SetSwitch |
Input |
Boolean |
1 |
0 |
1 |
- |
- |
|
Acceleration_Mode |
Output |
Uint8 |
1 |
0 |
255 |
- |
- |
|
LeadVehicle_Speed |
Output |
Uint8 |
1 |
0 |
255 |
- |
- |
|
DriveVehicle_Speed |
Output |
Uint8 |
1 |
0 |
255 |
- |
- |
|
LeadVehicle_Detected |
Output |
Uint8 |
1 |
0 |
255 |
- |
- |
STEP 3: Signal resolving and Signal propagation.
- Name the imports and signals by method of signal resolving and propagation.
- A signal is resolved when it appears for the first time and the signal is then propagated then onwards
- Signal to resolve: Right Click on the signal > properties > enter a valid signal name and click on the SLDD suggestion > check the resolve signal box > OK
The resolved signal appears as label along with a symbol in blue.
Similarly the signal is propagated out to subsystems by following the same steps but selecting the show propogated signals.
- Signal propagation: Double click on the signal, add <>, and press enter.
- Or Click on the signal > properties > Check the "Show propagated signal" option > OK
- The resolved signal will be propagated
- Avoid signal overlapping by using the goto and from blocks
STEP 4: Requirement Tagging.
- Requirement tagging is the process of linking the model with a document or a file that explains the model requirements by just clicking on the name
- The word document with the requirement details is opened.
- Select the heading and highlight it
- Right Click on the subsystem that explains the highlighted portion > requirements > Link to selection in word
- We can now see in the requirement section that the subsystem is linked to the word document.
- If anyone clicks on the requirement tag, the word document containing its details will be opened.
STEP 5: Configuration parameter settings and code generation settings.
Go to model settings > Solver > select type: Fixed step ; solver: discrete (no continuous states) ;Fixed step size:0.01 > OK
Go to code generation > system target file: select ert.tlc >OK
STEP 6: Model Advisor Check
- Model advisor checks are done to check compliance of the model with different guidelines
- Run the model and check for any errors
- If the model is error-free, we can proceed with the advisor check
- Here we are just performing the model advisor check on MAB standards
- Go to model advisor > select the whole system >OK
- Model advisor > select "By task"
- Select "modeling standards for MAB
Click on generate report. The file name and the location where the generated file will be stored are displayed.
- Once the report is generated, the advisor results can be seen with the total number of the pass, fail, warnings and tasks.
- The errors must be eliminated to 0 numbers
- The warnings must be reduced to a maximum
- To correct a warning, select the folder for which the warning is shown > select subfolder with warning sign > The warning parameters and correction methods as shown here
- Follow the correction recommendation and click OK when done correcting
- Now the warning number can be seen reduced
STEP 6: CODE Generation.
- Once the warnings are reduced to the maximum, we can generate a C code for the model created
- Go to model explorer > open requirement 2 > set the parameters
- Go to APPS tab > Embedded Coder > Select the model name >Gerate code /Build
The code will be displayed and it's also saved in the selected directory
Result:
- The adaptive cruise control is modeled in Simulink as per the given requirements and MBD guidlines
- Performed requirement tagging on the requirement subsystem blocks
- Solver and code generators are configured
- SLDD file is created and linked to the model also the signals are resolved and propagated
- Model advisor report is generated and verified
- C-code for the model is generated and attached