Project 2 Adaptive Cruise Control
Adaptive Cruise Control
Adaptive cruise control (ACC) is a system designed to help vehicles maintain a safe following distance and stay within the speed limit. ACC functions by sensory technology installed within vehicles such as cameras, lasers, and radar equipment, which creates an idea of how close one car is to another, or other objects on the roadway. For this reason, ACC is the basis for future car intelligence. Advantage of ACC include an increase in road safety, as cars with this technology will keep the adequate spacing between them and other vehicles. These space-mindful features will also help prevent accidents that result from an obstructed view or close following distance. Similarly, ACC will help maximize traffic flow because of its spatial awareness. As a driver, you don't have to worry about your speed, and instead, you can focus on what is going on around you.
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 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, 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.
Objective of Main Project:
- 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, 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.
- Choose sample time for all signals as 0.01s
The requirement document is attacted to know how the model is created using the specified inputs and outputs as well as the conditions. The requirement tagging is also done for the model so that you can open the document directly from the model file by right clicking on the subsystem --->requirements--->the first option where the requirement for each system is tagged.
The adaptive cruise control over view is shown below:
To the left are the inputs and to the right is the output. The output of our model is the accelecration_mode. The logic is all implemented in the block (subsystem) placed between the inputs and the outputs.
The adaptive cruise control has three subsystems to implement the logic. The subsystems are lead vehicle, drive vehicle and the ACC algorithm implemented in a subsystem seperately from the drive vehicle. To the left are the inputs and to the right is the outputs for each subsystem. All the inputs from the drive vehicle and the lead vehicle are given as input to the third subsystem which is shown below.
Now the model is built as per the requirements mentioned below:
LEAD VEHICLE:
- Lead Vehicle is a vehicle which is driving in the road ahead of our drive vehicle.
- 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.
Requirement 1– Lead Vehicle:
- Two input signals from lead vehicle is considered (Signal Name: CameraInput_LeadVehicle & RadarInput_LeadVehicle).
- 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.
DRIVE VEHICLE:
- Drive Vehicle is the vehicle driven by the user & this is the vehicle which has ACC algorithm in it.
- So this is basically the vehicle you implement the logic considering the data inputs set for the lead vehicle mentioned above.
- When the signal is repeated twice it is taken as input with either a dealy or signal conversion to avoid the algebric error of the model.
Requirement 2 – Drive Vehicle:
- Like the Lead Vehicle, 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 summation of three input signals mentioned above & LeadVehicle_Detected is renamed from Input Signal RadarInput_DriveVehicle by mere use of 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 is fed back as an input signal into this state machine block.
- Additionally, 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 which automatically adjusts its speed & velocity to match the lead vehicle.
To build this subsystem we need to implement the logic to the chart block.
Three state machines are used : ACC_ON, ACC_OFF, and ACC_STANDBY. The logic are used to transist from one state to another.
Inputs:
- Time_Gap
- Set_Speed
- Set_Gap
- CruiseSwitch
- SetSwitch).
- DriveVehicle_Speed
- LeadVehicle_Detected
- LeadVehicle_Speed
Output:
- Acceleration_Mode
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
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)]
All the above mentioned logic is shown below as stateflow. The same file is attached below for reference.
Requirement tagging:
Once the subsystem is created and named, the requirement tagging is done. Usually the requirement document is a word file and the rule is to keep both the word document and the '.slx model in the same folder. This is because if the document and the model are not inside the same folder then the requirement tagging can not be done and will show error.
1. Open the word file highlight the Requirement section that needs to be tagged. Only one requirement can be tagged per subsystem to avoid confusion.
2. Rename the subsystem. Right click on the subsystem ---->requirements--->link to selection on word. And the block turns yellow. The same steps are carried out for Requirement-2 and requirement-3 tagging. Once the tagging is done all the blocks when viewing the requirment turns orange and it opens the document linked with the block.
Once the requirement tagging is done the tracibility file is created for linking the external documents with matlab/simulink model.
Ater creating the models the model will throw an output error if we simulate it as such. This is because all the parameters specified in the model are not defined. To define these inputs and outputs you need to create a sldd file.
SIMULINK DATA DICTIONARY:
In model based designing the most important part is creating a sldd file. This is actually similar to how we declare variables in model and base workspace. But the workspace only provide declarations. Unlike initialisation in workspace we can define data related parameters in sldd file and save it. This can be transfered to another model by having the model file and sldd file under the same path directory.
How to access sldd?
To create a sldd for first time or access previously stored files go to modelling--->link to data dictionary, a pop up will be appear as shown below.
click on External data tab the message displayed above appears. To create a new sldd file use New option or click on browse to access previously created files. When either of these steps are completed the file name is displayed below, disable the model access to base workspace and procedd with the confirmation button. By doing this it links the model and the data dictionary.
In general the model explorer will be opened. We can also see that there is external data name on the model hierarchy box with a different icon. This is where we are going to create out sldd file for different types of inputs.
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 data specified above is filled in the corresponding columns as shown below.
Access sldd: click on modelling tab--->design dropdown---->link to data dictionary.
The properties window will pop-up, external data--->new--->name the file--->save--->add path
uncheck the 'enable model access to base workspace'.
This opens the model explorer and provides a space to create these variables for the model.
The sldd file is attached below for reference. Each data differ based on type property their behavioural output. To add inputs in the model explorer on the tool strip click on the icons highlighted below or select Add and from the drop down select the required input. The main point to be noted is to check for the values of resolution, storage class. The resolution reduces the complex calculation errors when prioritized. In case we have to multiply different decimal pointed numbers when having high resolution helps to reduce the error in the answer and gives precise values after decimal point. On the other hand the storage class plays a vital role in code generation, since the file format given there will be used to group those files under the same class and object, when this is not specified properly the model may through an error/ warning or the accuracy of the model itself will be reduced. For complex modelling it is always advised to have resolution and storage class.
Case-i : Input data,data type- uint8.
As shown below the name is typed and the values are filled in the respective column. The storage class for the input signals are ImportedExtern. After giving the required inputs select apply, else the changes might not be saved.
The same goes for all the remaining signals.
Case-ii: Ouput signal
The same steps are followed as discussed in the case-i but when the signal is an output signal it needs to be associated with the header and the definition file. Any names can be given to the header file and the extension should be "filename.h". Similarly for the definition file it is "filename.c". By doing this all the signals and the variables will be grouped under the given file names and easy to access or it might not be classified properly and model might throw an error.
header and definition file :
By doing this we have defined our sldd for the model. Now the model can have their block names and signal names along with the values fed to it by signal resolving and propagation.
Signal Resolving:
Resolving a signal is to ensure that the signal is present in the model and included in the sldd file so that it contains all the values when propogated to other blocks and subsystems.
- Right click on the required signal---->give signal name --->check 'signal name must resolve to simulink signal object' and apply the changes to your model.
you will get the symbol and the signal name on the line as shown below. This process is called signal resolving.
Resolving a signal needs to be done whenever the signal appears for the first time in the model. All the input signals are resolved as shown above.
An error message may pop up or the block will remain in red color highlighted outline when the inputs are not mentioned in the sldd file.
Signal Propagation:
Once the signal is resolved the same value needs to be carried or preserved through out the model when the same input is given to different system, so to carry the signal as the same propagation is used.
To do propagation : right click on signal line--->properties---->check on 'show propagated signals'--->ok.
The propagated signals are shown below :
All the signal names in the angluar brackets<> are propagated signals.
All the signals that are first resolved are then propogated in the model based designing.
Configuration paramters required to be changed for the model as shown below to generate the c code using the embedded coder.
By default grt.tlc will be present as the target file change it to ert.tlc file as shown below
The toolchain is choosen based one the requirement either auto or specific compiler to build the code.
After the changes are made the model is saved and runned.
MODEL ADVISOR CHECK:
This is done to know if the model is built correctly or not. This have certain guidelines for our models and checks if those are satisfied . Once the advisor check is cleared your model is ready for code generation.
go to Modelling tab--->model advisor (the pop-up shown below appears.)
Once the system is selected the next window opens:
The modelling standards under the "by task" option is checked and the model runs for the selected checks. A report similar the one shown below is generated. The report is attached below for reference. Here only the start page is shown.
Once the report is generated without any fail in the model we can start to build our code for the model. After the model is simulated without any error go to apps--->embedded c coder click on build.
The tool strip appears with the build option and your code is generated. Only one snap is attached below. Refer the document for the generated c-code using embedded coder.
C-code for the model:
/*
* File: adaptive_cruise_ctrl.c
*
* Code generated for Simulink model 'adaptive_cruise_ctrl'.
*
* Model version : 1.17
* Simulink Coder version : 9.5 (R2021a) 14-Nov-2020
* C/C++ source code generated on : Sat Jan 15 20:49:42 2022
*
* Target selection: ert.tlc
* Embedded hardware selection: Intel->x86-64 (Windows64)
* Code generation objectives: Unspecified
* Validation result: Not run
*/
#include "adaptive_cruise_ctrl.h"
#include "adaptive_cruise_ctrl_private.h"
/* Named constants for Chart: '<S2>/Chart' */
#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)
#define ada_IN_LeadVehicle_Not_Detected ((uint8_T)3U)
#define adaptive_c_IN_ACC_STANDBY_MODE_ ((uint8_T)3U)
#define adaptive_cru_IN_NO_ACTIVE_CHILD ((uint8_T)0U)
#define adaptive_cruis_IN_ACC_OFF_MODE_ ((uint8_T)1U)
#define adaptive_cruise__IN_ACC_ON_MODE ((uint8_T)2U)
/* Block states (default storage) */
DW_adaptive_cruise_ctrl_T adaptive_cruise_ctrl_DW;
/* External outputs (root outports fed by signals with default storage) */
ExtY_adaptive_cruise_ctrl_T adaptive_cruise_ctrl_Y;
/* Real-time model */
static RT_MODEL_adaptive_cruise_ctrl_T adaptive_cruise_ctrl_M_;
RT_MODEL_adaptive_cruise_ctrl_T *const adaptive_cruise_ctrl_M =
&adaptive_cruise_ctrl_M_;
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;
}
/* Model step function */
void adaptive_cruise_ctrl_step(void)
{
int32_T tmp;
uint8_T tmp_0;
/* Sum: '<S4>/Add' incorporates:
* Inport: '<Root>/CameraInput_LeadVehicle'
* Inport: '<Root>/RadarInput_LeadVehicle'
*/
LeadVehicle_Speed = (uint8_T)((uint32_T)CameraInput_LeadVehicle +
RadarInput_LeadVehicle);
/* Delay: '<S1>/Delay' */
Acceleration_Mode = adaptive_cruise_ctrl_Y.Acceleration_Mode_p;
/* Sum: '<S3>/Add' incorporates:
* Inport: '<Root>/CameraInput_DriveVehicle'
* Inport: '<Root>/RadarInput_DriveVehicle'
*/
DriveVehicle_Speed = (uint8_T)((uint32_T)(uint8_T)((uint32_T)
CameraInput_DriveVehicle + RadarInput_DriveVehicle) + Acceleration_Mode);
/* SignalConversion: '<S3>/Signal Conversion' incorporates:
* Inport: '<Root>/RadarInput_DriveVehicle'
*/
LeadVehicle_Detected = RadarInput_DriveVehicle;
/* Chart: '<S2>/Chart' incorporates:
* Delay: '<S1>/Delay'
* Inport: '<Root>/CruiseSwitch'
* Inport: '<Root>/SetSwitch'
* Inport: '<Root>/Set_Gap'
* Inport: '<Root>/Set_Speed'
* Inport: '<Root>/Time_Gap'
*/
if (adaptive_cruise_ctrl_DW.is_active_c3_adaptive_cruise_ct == 0U) {
adaptive_cruise_ctrl_DW.is_active_c3_adaptive_cruise_ct = 1U;
adaptive_cruise_ctrl_DW.is_c3_adaptive_cruise_ctrl =
adaptive_cruis_IN_ACC_OFF_MODE_;
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 0U;
} else {
switch (adaptive_cruise_ctrl_DW.is_c3_adaptive_cruise_ctrl) {
case adaptive_cruis_IN_ACC_OFF_MODE_:
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 0U;
if (Set_Gap == 1) {
adaptive_cruise_ctrl_DW.is_c3_adaptive_cruise_ctrl =
adaptive_c_IN_ACC_STANDBY_MODE_;
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 1U;
}
break;
case adaptive_cruise__IN_ACC_ON_MODE:
if (Set_Gap == 0) {
adaptive_cruise_ctrl_DW.is_ACC_ON_MODE = adaptive_cru_IN_NO_ACTIVE_CHILD;
adaptive_cruise_ctrl_DW.is_c3_adaptive_cruise_ctrl =
adaptive_cruis_IN_ACC_OFF_MODE_;
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 0U;
} else if (!SetSwitch) {
adaptive_cruise_ctrl_DW.is_ACC_ON_MODE = adaptive_cru_IN_NO_ACTIVE_CHILD;
adaptive_cruise_ctrl_DW.is_c3_adaptive_cruise_ctrl =
adaptive_c_IN_ACC_STANDBY_MODE_;
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 1U;
} else {
switch (adaptive_cruise_ctrl_DW.is_ACC_ON_MODE) {
case IN_LeadVehicle_Detected_Follow:
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 2U;
if (LeadVehicle_Detected == 0) {
adaptive_cruise_ctrl_DW.is_ACC_ON_MODE =
ada_IN_LeadVehicle_Not_Detected;
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 1U;
} else if (((LeadVehicle_Detected == 1) && (LeadVehicle_Speed <
Set_Speed)) || (Time_Gap < (int32_T)CruiseSwitch)) {
adaptive_cruise_ctrl_DW.is_ACC_ON_MODE =
IN_LeadVehicle_Speed_lessthan_S;
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 4U;
}
break;
case IN_LeadVehicle_Detected_Resume:
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 3U;
if ((DriveVehicle_Speed == Set_Speed) && (LeadVehicle_Speed >=
Set_Speed) && (Time_Gap >= (int32_T)CruiseSwitch)) {
adaptive_cruise_ctrl_DW.is_ACC_ON_MODE =
IN_LeadVehicle_Detected_Follow;
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 2U;
} else if (LeadVehicle_Detected == 0) {
adaptive_cruise_ctrl_DW.is_ACC_ON_MODE =
IN_LeadVehicle_Not_Detected_Res;
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 1U;
} else if ((DriveVehicle_Speed < Set_Speed) && (LeadVehicle_Speed >
DriveVehicle_Speed) && (Time_Gap >= (int32_T)CruiseSwitch))
{
adaptive_cruise_ctrl_DW.is_ACC_ON_MODE =
IN_LeadVehicle_Speed_equal_Set_;
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 5U;
}
break;
case ada_IN_LeadVehicle_Not_Detected:
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 1U;
if ((LeadVehicle_Detected == 1) && (DriveVehicle_Speed == Set_Speed) &&
(LeadVehicle_Speed >= Set_Speed) && (Time_Gap >= (int32_T)
CruiseSwitch)) {
adaptive_cruise_ctrl_DW.is_ACC_ON_MODE =
IN_LeadVehicle_Detected_Follow;
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 2U;
} else if (((LeadVehicle_Detected == 1) && (LeadVehicle_Speed <
Set_Speed)) || (Time_Gap < (int32_T)CruiseSwitch)) {
adaptive_cruise_ctrl_DW.is_ACC_ON_MODE =
IN_LeadVehicle_Speed_lessthan_S;
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 4U;
}
break;
case IN_LeadVehicle_Not_Detected_Res:
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 1U;
break;
case IN_LeadVehicle_Speed_equal_Set_:
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 5U;
if ((LeadVehicle_Detected == 0) || (DriveVehicle_Speed <= Set_Speed))
{
adaptive_cruise_ctrl_DW.is_ACC_ON_MODE =
IN_LeadVehicle_Not_Detected_Res;
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 1U;
} else if (((DriveVehicle_Speed < Set_Speed) && (LeadVehicle_Speed >
DriveVehicle_Speed)) || (Time_Gap >= (int32_T)
CruiseSwitch)) {
adaptive_cruise_ctrl_DW.is_ACC_ON_MODE =
IN_LeadVehicle_Detected_Resume;
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 3U;
} else if (((LeadVehicle_Speed < Set_Speed) && (LeadVehicle_Speed <
DriveVehicle_Speed)) || (0.75 * (real_T)CruiseSwitch ==
Time_Gap)) {
adaptive_cruise_ctrl_DW.is_ACC_ON_MODE =
IN_LeadVehicle_Speed_lessthan_S;
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 4U;
}
break;
default:
/* case IN_LeadVehicle_Speed_lessthan_Set_Speed: */
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 4U;
if ((LeadVehicle_Detected == 0) && (DriveVehicle_Speed == Set_Speed))
{
adaptive_cruise_ctrl_DW.is_ACC_ON_MODE =
ada_IN_LeadVehicle_Not_Detected;
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 1U;
} else {
tmp = (int32_T)rt_roundd_snf((real_T)LeadVehicle_Speed * 1.25);
if (tmp < 256) {
tmp_0 = (uint8_T)tmp;
} else {
tmp_0 = MAX_uint8_T;
}
if ((tmp_0 >= DriveVehicle_Speed) && ((int32_T)rt_roundd_snf((real_T)
LeadVehicle_Speed * 0.75) <= DriveVehicle_Speed) &&
(DriveVehicle_Speed < Set_Speed) && (Time_Gap <= 1.25 * (real_T)
CruiseSwitch) && (Time_Gap >= 0.75 * (real_T)CruiseSwitch)) {
adaptive_cruise_ctrl_DW.is_ACC_ON_MODE =
IN_LeadVehicle_Speed_equal_Set_;
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 5U;
}
}
break;
}
}
break;
default:
/* case IN_ACC_STANDBY_MODE_: */
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 1U;
if (Set_Gap == 0) {
adaptive_cruise_ctrl_DW.is_c3_adaptive_cruise_ctrl =
adaptive_cruis_IN_ACC_OFF_MODE_;
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 0U;
} else if (SetSwitch) {
adaptive_cruise_ctrl_DW.is_c3_adaptive_cruise_ctrl =
adaptive_cruise__IN_ACC_ON_MODE;
adaptive_cruise_ctrl_DW.is_ACC_ON_MODE = IN_LeadVehicle_Detected_Follow;
adaptive_cruise_ctrl_Y.Acceleration_Mode_p = 2U;
}
break;
}
}
/* End of Chart: '<S2>/Chart' */
}
/* Model initialize function */
void adaptive_cruise_ctrl_initialize(void)
{
/* (no initialization code required) */
}
/* Model terminate function */
void adaptive_cruise_ctrl_terminate(void)
{
/* (no terminate code required) */
}
/*
* File trailer for generated code.
*
* [EOF]
*/
The code is generated for the model along with the header and definition files we created using the sldd.
Conclusion: Thus the model is read and built according to the requirement document. Model simulated without any errors and the code is built for the model from the embedded coder and displayed.