Project 2 Adaptive Cruise Control

Aim:

1. Developing Adaptive Cruise Control feature as per the Requirement Document using MATLAB Simulink.
2. Following all the MBD related processes: Requirement Tagging & Traceability, SLDD creation, Configuration Parameter changes, Model Advisor check & Code Generation.
3. In Configuration Parameters: enabling “Support Floating Numbers” under Code Generation settings.
4. Use Embedded Coder to generate the code.
5. When 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. Choosing sample time for all signals as 0.01s

Procedure:

As per the Requirement document, implemented the Adaptive Cruise Control feature.

Requirement 1 – Lead vehicle:

• To detect the lead vehicle speed, simply added both the radar & camera inputs & the corresponding output is read as Speed profile output.

The requirements are fuilfilled using the input & output blocks and the Add block. It is now created as a sub-system. Name the subsystem as Requirement 1. Name the input Signals as CameraInput_LeadVehicle & RadarInput_LeadVehicle and the output signal as LeadVehicle_Speed. Right click on all the blocks then clcik on format and then click on show block name and then finally click ON.

Requirement 2 – Drive Vehicle:

To regulate the "Drive Vehicle speed, as per the Requirement Document added Cameralnput. Radarinput & Acceleration Mode feedback from ACC Algorithm.

• To detect the Lead vehicle. Radarinput is converted using "Signal Conversion Block

• To avoid the algebraic error "Unit delay block is used for the Acceleration Mode feedback.

the requirement is modeled exactly. We have also used the blocks (Add block, Signal conversion block) and signal names(CameraInput_DriveVehicle, RadarInput_DriveVehicle & Acceleration_Mode) suggested in the requirement.

The input and output blocks are used to create the input & output ports for the subsystem. Subsystem is renamed as Requirement 2. Right click on all the blocks then clcik on format and then click on show block name and then finally click ON.

Requirement 3 – Adaptive Cruise Control Algorithm:

We are asked to model this ACC algorithm as a stateflow model. Use the Chart block form simulink to create a stateflow process. The inport & outport blocks and the chart block is used to create this requirement. Right click on all the blocks then clcik on format and then click on show block name and then finally click ON and name the subsystem as Requirement 3

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

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

• This is the default substate 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)]</em"></set_speed)

3. Requirement Tagging and Tracebility report

all the requirements are tagged for better understandability, anyone who is reviewing the model or who is trying to update the model can get a clear idea of what logic is used in the system. from the requirement manager, we can see what are all are tagged and the description.

4. Creating SLDD:

all the inputs, outputs, calibration parameters are saved in SLDD so while simulation the model takes all the values and its parameters from the Simulink Data Dictionary.

5. Signal Resolution for inputs and outputs

the inputs and output signals are resolved so the signals will take the values from sldd and pass them to the logical blocks. Otherwise, it may take some junk values if it is unresolved

6. Model Update.

The model update is done by Ctrl-D. this is done to check for any static errors. If no errors are coming the model is working fine without any errors.

7. Simulation

The model is simulated too for checking for errors and warnings

8. Configuration Parameter Update

Various configuration parameters are updated as per the code generation the solver type should be fixed for code generation

9. Model Advisory Report

By running the model advisor tool, we can see commonly made modelling errors.

10. Code generation

Build a model for generating code

Click Modeling ---> Model settings ---> Coverage ---> Check enable coverage analysis, matlab files, c/c++ s-functions, select MCDC under structural coverage level, check signal range, signal size, saturation on integar flow under other matrics ---> apply.

Click code generation ---> system target file as ert.tlc (embedded coder) ---> ok

Click solver ---> select fixed type as solver selection type and discrete as solver ---> give 0.01 as fixed step size ---> apply ---> ok.

Right click on the logic ---> C/C++ code --> Build this system ---> Generate code

Code