Project 2 Adaptive Cruise Control

Aim:-

To develop a model for Adaptive cruise control as per the requirements and to meet the MOB guidelines check and code generations are made for the model using MATLAB/Simulink.

Objective:-

To Develop 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.

To change Configuration Parameters such as to enable “Support Floating Numbers” under Code Generation settings and 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.

To choose sample time for all signals as 0.01s.

Description:-

Adaptive Cruise Control:-

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.

Simulink Model Development Using Requirement:-

Requirement 1:-

As per requirement here Lead Vehicle is a vehicle which is driving in the road ahead of our drive vehicle.

Two input signals "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 "LeadVehicle_Speed".

As per the above statement the model is made and which as seen in image below.

Requirement 1– Lead Vehicle:

Speed data of the lead vehicle is critical in implementing the Adaptive Cruise Control algorithm.

As per the requirements the model is Developed and a subsystem is created as seen in image below

Requirement 2 – Drive Vehicle:

Here Drive Vehicle is the vehicle driven by the user & this is the vehicle which has ACC algorithm in it.

Like the Lead Vehicle, Drive Vehicle algorithm also has 2 input signals "CameraInput_DriveVehicle", "RadarInput_DriveVehicle" & one signal coming as an Input to this subsystem which is "Acceleration_Mode" totally three inputs into this requirement.

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 which are "DriveVehicle_Speed" & "LeadVehicle_Detected".

Signal "DriveVehicle_Speed" is summation of three input signals mentioned above which is modelled as below

"LeadVehicle_Detected" is renamed from Input Signal "RadarInput_DriveVehicle" by mere use of Signal Conversion block.

This represents the entire Model of Drive_Vehicle and subsystem is created as shown below

Requirement 3 – Adaptive Cruise Control Algorithm:

Adaptive Cruise Control feature has 3 major modes of operation such as 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 "Time_Gap", "Set_Speed", "Set_Gap", "CruiseSwitch", "SetSwitch".

Also, the output signals are "DriveVehicle_Speed" & "LeadVehicle_Detected" from requirement-2 is fed back as an input signal into this state machine block.

Additionally, output signal such as "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 "Acceleration_Mode" which governs the vehicular speed of the drive vehicle which automatically adjusts its speed & velocity to match the lead vehicle.

As per the above requirement a subsystem Adaptive_Criuse_Control_Algorithm is created as shown in below image

Inside the subsystem the stateflow chart is created and Model is seen as follows

Requirement 3a – ACC OFF MODE :-

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

As per the model requirement is developed which is as seen in below image

Requirement 3b – ACC STANDBY MODE:

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.

As per the model requirement is developed which is as seen in below image

Requirement 3c – ACC ON MODE:

This state will be activated when input signal "SetSwitch" is equal to "1". There are 6 sub states to this state logic which are LeadVehicle_Detected_Follow (Default), LeadVehicle_Not_Detected, LeadVehicle_Detected_Resume, LeadVehicle_Not_Detected_Resume, LeadVehicle_Speed_lessthan_Set_Speed and 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 (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 entire Stateflow Model is as seen below

Stateflow Diagram:-

Here the stateflow is set to C Code.

Simulink Model:-

The Entire model is as seen below image.

Here the Lead_Vehicle Subsystem act as the the vehicle which moves before our vehicle and its output is connected to Adaptive_Criuse_Control_Algorithm and the drive vehicle is the parameters from our vehicle based the input the Adaptive Cruise control logic develops and act accordingly.

The Output from the Adaptive_Cruise_Control_Algorithm is Accelation_Mode is fed as feedback to Drive_Vehicle thus inorder to maintain the speed as the vehicle which leads the way.

Requirement Tagging:-

Each Requirements are tagged to its respective subsystems and blocks and charts by using the link to selection in word which is shown below

Requirement tagging for the following block are done which are

Requirement 1 - Lead Vehicle for Lead_Vehicle Subsystem

Requirement 2 – Drive Vehicle for Drive_Vehicle Subsystem

Requirement 3 – Adaptive Cruise Control Algorithm for Adaptive_Cruise_Control_Algorithm Subsystem

Requirement 3a – ACC OFF MODE for State

Requirement 3b – ACC STANDBY MODE for state

Requirement 3c – ACC ON MODE for state

Requirement 3c (i) – LeadVehicle_Detected_Follow (ACC ON MODE) for state

Requirement 3c (ii) – LeadVehicle_Not_Detected (ACC ON MODE) for state

Requirement 3c (iii) – LeadVehicle_Detected_Resume (ACC ON MODE) for state

Requirement 3c (iv) - LeadVehicle_Not_Detected_Resume (ACC ON MODE) for state

Requirement 3c (v) - LeadVehicle_Speed_lessthan_Set_Speed (ACC ON MODE) for state

Requirement 3c (vi) - LeadVehicle_Speed_equal_Set_Speed (ACC ON MODE) for state

Thus the requirement tagging is done for each requirements given for the development of model.

SLDD Creation:-

A new sldd file is created by using Modelling>link to data dictionary>New

We have named the file as "acc.sldd"

Now the file is opened using Model explorer and data which is provided with data types and range as per the below Singals and calibration data list the signals are added.

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 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.

The data dictionary datas are developed which is as seen below as per the above mentioned datas.

Configuration Parameter Changes:-

The Configuration Parameter changes are made by following step Modelling>Model Setting

Solver Configuration Parameter:-

In below Image Under solver setting

As per the requirement given

The solver used is fixed step discrete solver and Fixed Step size i.e the sample time is set to 0.01.

Code Generation Configuration Parameter:-

Under Code Generation the System target file is set to ert.tlc which is Embedded Coder

And Under Interface<Software environment, support floating-point number to be enabled as seen below.

Model Advisor:-

Under Modelling<Model Advisor<System Selector

We have chosen the entire model for the model advisor check

In Model Advisor we have choosen Modelling standards for MAB is choosen and the advisor is run

The Model advisor is run and there is no error in the model.

By clicking on generate report the report for the advisor check is generated which is as seen below

Code Generation:-

Code generation to be done using embedded coder

Under App<Embedded C Code<Build

The C Code is build and is as shown below

Code:-

ert_main.c file code:-

/*
 * File: ert_main.c
 *
 * Code generated for Simulink model 'acc'.
 *
 * Model version                  : 1.85
 * Simulink Coder version         : 9.5 (R2021a) 14-Nov-2020
 * C/C++ source code generated on : Sat Apr  2 20:10:11 2022
 *
 * Target selection: ert.tlc
 * Embedded hardware selection: Intel->x86-64 (Windows64)
 * Code generation objectives: Unspecified
 * Validation result: Not run
 */

#include <stddef.h>
#include <stdio.h>              /* This ert_main.c example uses printf/fflush */
#include "acc.h"                       /* Model's header file */
#include "rtwtypes.h"

/*
 * Associating rt_OneStep with a real-time clock or interrupt service routine
 * is what makes the generated code "real-time".  The function rt_OneStep is
 * always associated with the base rate of the model.  Subrates are managed
 * by the base rate from inside the generated code.  Enabling/disabling
 * interrupts and floating point context switches are target specific.  This
 * example code indicates where these should take place relative to executing
 * the generated code step function.  Overrun behavior should be tailored to
 * your application needs.  This example simply sets an error status in the
 * real-time model and returns from rt_OneStep.
 */
void rt_OneStep(void);
void rt_OneStep(void)
{
  static boolean_T OverrunFlag = false;

  /* Disable interrupts here */

  /* Check for overrun */
  if (OverrunFlag) {
    rtmSetErrorStatus(acc_M, "Overrun");
    return;
  }

  OverrunFlag = true;

  /* Save FPU context here (if necessary) */
  /* Re-enable timer or interrupt here */
  /* Set model inputs here */

  /* Step the model */
  acc_step();

  /* Get model outputs here */

  /* Indicate task complete */
  OverrunFlag = false;

  /* Disable interrupts here */
  /* Restore FPU context here (if necessary) */
  /* Enable interrupts here */
}

/*
 * The example "main" function illustrates what is required by your
 * application code to initialize, execute, and terminate the generated code.
 * Attaching rt_OneStep to a real-time clock is target specific.  This example
 * illustrates how you do this relative to initializing the model.
 */
int_T main(int_T argc, const char *argv[])
{
  /* Unused arguments */
  (void)(argc);
  (void)(argv);

  /* Initialize model */
  acc_initialize();

  /* Attach rt_OneStep to a timer or interrupt service routine with
   * period 0.01 seconds (the model's base sample time) here.  The
   * call syntax for rt_OneStep is
   *
   *  rt_OneStep();
   */
  printf("Warning: The simulation will run forever. "
         "Generated ERT main won't simulate model step behavior. "
         "To change this behavior select the 'MAT-file logging' option.\n");
  fflush((NULL));
  while (rtmGetErrorStatus(acc_M) == (NULL)) {
    /*  Perform other application tasks here */
  }

  /* Disable rt_OneStep() here */

  /* Terminate model */
  acc_terminate();
  return 0;
}

/*
 * File trailer for generated code.
 *
 * [EOF]
 */

acc.c file code:-

/*
 * File: acc.c
 *
 * Code generated for Simulink model 'acc'.
 *
 * Model version                  : 1.85
 * Simulink Coder version         : 9.5 (R2021a) 14-Nov-2020
 * C/C++ source code generated on : Sat Apr  2 20:10:11 2022
 *
 * 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: '<S2>/ACC_Logic' */
#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 acc_IN_ACC_OFF_MODE            ((uint8_T)1U)
#define acc_IN_ACC_ON_MODE             ((uint8_T)2U)
#define acc_IN_ACC_STANDBY_MODE        ((uint8_T)3U)
#define acc_IN_LeadVehicle_Not_Detected ((uint8_T)3U)
#define acc_IN_NO_ACTIVE_CHILD         ((uint8_T)0U)

/* Exported data definition */

/* Definition for custom storage class: ExportToFile */
uint8_T Accelaration_Mode;             /* '<S1>/Unit Delay' */

/* Block states (default storage) */
DW_acc_T acc_DW;

/* External inputs (root inport signals with default storage) */
ExtU_acc_T acc_U;

/* External outputs (root outports fed by signals with default storage) */
ExtY_acc_T acc_Y;

/* Real-time model */
static RT_MODEL_acc_T acc_M_;
RT_MODEL_acc_T *const acc_M = &acc_M_;

/* Model step function */
void acc_step(void)
{
  /* local block i/o variables */
  uint8_T LeadVehicle_Speed;
  uint8_T DriveVehicle_Speed;
  uint8_T LeadVehicle_Detected;
  int32_T tmp;

  /* Outputs for Atomic SubSystem: '<Root>/Adaptive_Cruise_Control'
   *
   * Block description for '<Root>/Adaptive_Cruise_Control':
   *  Adaptive Cruise Control Contains the subsystem Adaptive Cruise control
   *  logic, Lead Vehicle and Drive Vehicle
   */
  /* Outputs for Atomic SubSystem: '<S1>/Lead_Vehicle' */
  /* Sum: '<S4>/Add' incorporates:
   *  Inport: '<Root>/CameraInput_LeadVehicle'
   *  Inport: '<Root>/RadarInput_LeadVehicle'
   */
  tmp = (int32_T)((uint32_T)CameraInput_LeadVehicle + RadarInput_LeadVehicle);
  if ((uint32_T)tmp > 255U) {
    tmp = 255;
  }

  /* Sum: '<S4>/Add' */
  LeadVehicle_Speed = (uint8_T)tmp;

  /* End of Outputs for SubSystem: '<S1>/Lead_Vehicle' */

  /* UnitDelay: '<S1>/Unit Delay' */
  Accelaration_Mode = acc_Y.Accelaration_Mode_e;

  /* Outputs for Atomic SubSystem: '<S1>/Drive_Vehicle' */
  /* Sum: '<S3>/Add' incorporates:
   *  Inport: '<Root>/CameraInput_DriveVehicle'
   */
  tmp = (int32_T)((uint32_T)CameraInput_DriveVehicle + Accelaration_Mode);
  if ((uint32_T)tmp > 255U) {
    tmp = 255;
  }

  /* Sum: '<S3>/Add1' incorporates:
   *  Inport: '<Root>/RadarInput_DriveVehicle'
   *  Sum: '<S3>/Add'
   */
  tmp = (int32_T)((uint32_T)tmp + RadarInput_DriveVehicle);
  if ((uint32_T)tmp > 255U) {
    tmp = 255;
  }

  /* Sum: '<S3>/Add1' */
  DriveVehicle_Speed = (uint8_T)tmp;

  /* SignalConversion: '<S3>/Signal Conversion' incorporates:
   *  Inport: '<Root>/RadarInput_DriveVehicle'
   */
  LeadVehicle_Detected = RadarInput_DriveVehicle;

  /* End of Outputs for SubSystem: '<S1>/Drive_Vehicle' */

  /* Outputs for Atomic SubSystem: '<S1>/Adaptive_Criuse_Control_Algorithm'
   *
   * Block description for '<S1>/Adaptive_Criuse_Control_Algorithm':
   *  This block contains acc chartflow
   */
  /* Chart: '<S2>/ACC_Logic' incorporates:
   *  Inport: '<Root>/CruiseSwitch'
   *  Inport: '<Root>/SetSwitch'
   *  Inport: '<Root>/Set_Gap'
   *  Inport: '<Root>/Set_Speed'
   *  Inport: '<Root>/Time_Gap'
   *  UnitDelay: '<S1>/Unit Delay'
   *
   * Block description for '<S2>/ACC_Logic':
   *  It carries the ACC logic stateflow
   */
  if (acc_DW.is_active_c3_acc == 0U) {
    acc_DW.is_active_c3_acc = 1U;
    acc_DW.is_c3_acc = acc_IN_ACC_OFF_MODE;
    acc_Y.Accelaration_Mode_e = 0U;
  } else {
    switch (acc_DW.is_c3_acc) {
     case acc_IN_ACC_OFF_MODE:
      acc_Y.Accelaration_Mode_e = 0U;
      if (acc_U.CruiseSwitch) {
        acc_DW.is_c3_acc = acc_IN_ACC_STANDBY_MODE;

Thus the C-Code is generated for the above model.

Result:-

The Model is created as per the requirements and those requirements are tagged and sldd file is created, Configuration parameters are made, Model advisor check for MAB guidelines and c code generations are made which is a part of Model based design is done for Adaptive Cruise Control.