ADAPTIVE CRUISE CONTROL
MAIN PROJECT – ADAPTIVE CRUISE CONTROL (ACC)
AIM -
1. Developing Adaptive Cruise Control feature as per the Requirement Document using MATLAB Simulink.
2. Follow all the MBD-related processes: Requirement Tagging & Traceability, SLDD creation, Configuration Parameter changes, Model Advisor check & Code Generation.
3. In Configuration Parameters: enable “Support Floating Numbers” under Code Generation settings.
4. Use Embedded Coder to generate the code.
5 If choosing code generation, Storage class for Input signals: ImportedExtern; Storage class for Output signal: Export to File; Storage class for local signals: localizable; Storage class for calibration signals: Const.
6. Choose sample time for all signals as 0.01s
GENERAL OVERVIEW:
Adaptive Cruise Control Feature for passenger cars allows the host vehicle to adapt to the speed in line with the flow of traffic. Driving in heavy traffic or keeping a safe distance to the preceding vehicle calls for a high level of concentration. The Adaptive Cruise Control feature can reduce the stress on the driver by automatically controlling the vehicle speed & maintaining a predefined minimum distance to the preceding vehicle. As a consequence, the driver enjoys more comfort & can concentrate on the road a little better.
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 stops & 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 stops & goes 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.
PROCEDURE:
We will develop a model as per the requirements given in the problem statement. The requirements are mentioned below.
Requirement 1– Lead Vehicle:
- A 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 cameras & 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.
We follow the steps provided in the Requirement 1 list and the below subsystem can be created.
The subsystem will be created as shown below.
We use the 'goto' and 'from' blocks to collect the output data of each of the subsystems created.
Requirement 2 – Drive Vehicle:
- Drive Vehicle is the vehicle driven by the user & this is the vehicle that has 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 Signal Conversion block.
We follow the steps provided in the Requirement 2 list and the below subsystem can be created.
The subsystem will be created as shown below.
We give feedback of the output of the adaptive cruise control output to the above subsystem by using a unit delay 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) that governs the vehicular speed of the drive vehicle which automatically adjusts its speed & velocity to match the lead vehicle.
The below image shows us the inputs given to the state flow logic and the output obtained.
The subsystem for the same is created as shown below. The 'from' blocks act as inputs to this subsystem which carries the output data from the previous subsystems.
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 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 the 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)
The below image shows us the states mentioned above, inside the 'ACC_ON_MODE' state logic. The details are clearly shown in the image below.
Combining all the requirements into a model, we get the following.
Requirement Tagging and Traceability -
We create a word document consisting of the requirements given above.
Now we follow the mentioned steps to link the document to our model. We right-click on the required subsystem while the corresponding requirement is selected in the word document. We select the 'Link to the word document', then right-click again to find the selected text with which we can tag the subsystem. This will ensure the traceability of the requirements.
The below image shows the 'Requirement 1 - Lead Vehicle' tagged to its subsystem.
The below image shows the 'Requirement 2 - Drive Vehicle' tagged to its subsystem.
The below image shows the 'Requirement 3 - Adaptive Cruise Control Algorithm' tagged to its subsystem.
The below image shows the 'Requirement 3a - ACC OFF MODE state logic' tagged to its subsystem.
The below image shows the 'Requirement 3b - ACC STANDBY MODE state logic' tagged to its subsystem.
The below image shows the 'Requirement 3c - ACC ON MODE state logic' tagged to its subsystem.
The below image shows the 'Requirement 3c(i) - LeadVehicle_Detected_Follow (ACC ON MODE)' tagged to its subsystem.
The below image shows the 'Requirement 3c (ii) – LeadVehicle_Not_Detected (ACC ON MODE)' tagged to its subsystem.
The below image shows the 'Requirement 3c (iii) – LeadVehicle_Detected_Resume (ACC ON MODE)' tagged to its subsystem.
The below image shows the 'Requirement 3c (iv) - LeadVehicle_Not_Detected_Resume (ACC ON MODE)' tagged to its subsystem.
The below image shows the 'Requirement 3c (v) - LeadVehicle_Speed_lessthan_Set_Speed (ACC ON MODE)' tagged to its subsystem.
The below image shows the 'Requirement 3c (vi) - LeadVehicle_Speed_equal_Set_Speed (ACC ON MODE)' tagged to its subsystem.
SLDD CREATIONS
We use the details given in the table to create our data dictionary for the input signals.
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 |
- |
- |
The SLDD created is shown below. The sample time for each of the signals is changed to 0.01 seconds. The storage types of each of these signals are changed from 'auto' to the mentioned storage class for the input and output signals.
MODEL ADVISOR REPORT
We check for the modeling standards for MAB as shown below. A total of 116 have been passed and 25 warnings will be looked into and there are no elements that are failing the MAB guidelines.
A report can be generated for the above checks and can be saved in the desired path. A screenshot of the report is shown below.
GENERATING THE CODE -
We first change the model format from grt. tlc to ert. tlc as shown below.
The configuration parameter settings are shown below. The language will be set to C and the target file like mentioned above will be set to ert. tlc.
The solver settings will be changed from variable step to fixed-step for the code generation and the sampling time will be set to 0.01 seconds as shown below.
Now we go to the 'APPS' tab and click on the 'build' option to generate a code and the model.
The code generated is shown below.
/*
* File: ACC.c
*
* Code generated for Simulink model 'ACC'.
*
* Model version : 1.83
* Simulink Coder version : 9.3 (R2020a) 18-Nov-2019
* C/C++ source code generated on : Mon Oct 25 00:30:34 2021
*
* Target selection: ert.tlc
* Embedded hardware selection: Intel->x86-64 (Windows64)
* Code generation objectives: Unspecified
* Validation result: Not run
*/
#include "ACC.h"
#include "ACC_private.h"
/* Named constants for Chart: '/Chart' */
#define ACC_IN_LeadVehicle_Not_Detected ((uint8_T)3U)
#define ACC_IN_NO_ACTIVE_CHILD ((uint8_T)0U)
#define ACC_IN_OFF_Mode ((uint8_T)1U)
#define ACC_IN_ON_Mode ((uint8_T)2U)
#define ACC_IN_STANDBY_Mode ((uint8_T)3U)
#define IN_LeadVehicle_Detected_Follow ((uint8_T)1U)
#define IN_LeadVehicle_Detected_Resume ((uint8_T)2U)
#define IN_LeadVehicle_Not_Detected_Res ((uint8_T)4U)
#define IN_LeadVehicle_Speed_equal_Set_ ((uint8_T)5U)
#define IN_LeadVehicle_Speed_lessthan_S ((uint8_T)6U)
/* Block states (default storage) */
DW_ACC_T ACC_DW;
/* Real-time model */
RT_MODEL_ACC_T ACC_M_;
RT_MODEL_ACC_T *const ACC_M = &ACC_M_;
/* Forward declaration for local functions */
static void ACC_ON_Mode(void);
real_T rt_roundd_snf(real_T u)
{
real_T y;
if (fabs(u) < 4.503599627370496E+15) {
if (u >= 0.5) {
y = floor(u + 0.5);
} else if (u > -0.5) {
y = u * 0.0;
} else {
y = ceil(u - 0.5);
}
} else {
y = u;
}
return y;
}
/* Function for Chart: '/Chart' */
static void ACC_ON_Mode(void)
{
int32_T tmp;
int32_T tmp_0;
uint8_T tmp_1;
uint8_T tmp_2;
/* Inport: '/SetSwitch' incorporates:
* Inport: '/Set_Gap'
* Inport: '/Set_Speed'
* Inport: '/Time_Gap'
*/
if (!SetSwitch) {
We can now use this code to generate a SIL block and we can conduct SIL testing to obtain the results and check the working of the logic and the code. We can write up test case scenarios and run the MIL and SIL testing to verify the model and validate the results.
CONCLUSION -
The simulation will be run for a total of 10 seconds. We can see that the model runs successfully and there are no errors obtained, so we can conclude that the model is built and created as per the requirements given in the objectives.
The link to the model along with the sldd, slmx, and the model advisory report is given below.