Project 1 (Mini Project on Vehicle Direction Detection

AIM:

To develop the model of vehicle direction by using the matlab.

OBJECTIVE:

• The objective of this project is to create a MBD complaint MATLAB Simulink model for a vehicle direction dectection as per the requirement specified.
• Tag the requirements to the simulink model;Requirement 1 & Requirement 2 are tagged to their corressponding subsystems.
• Creation of Data Dictionary for the simulink model,Perform Model-In Loop (MIL) test and Software-In loop (SIL)test.

Task:

• The input to the system are the Steering Wheel angular input given as yaw rate (Signal name:SteeringWheel_YawDegreeInput)
• and a input signal from camera (Signal name:CameraInput_RoadSign),Which confirms the occurence of a road sign.
• A camera reads the road sign & stores into its memory unique values for left turn,right turn & straight drive.Depending on the direction the vehicle takes,a final indication is given to the driver-if he is driving in the recommended direction or not.
• The output of the system is a boolean value(Signal Name:Vehicle_Direction_Indicator)which specifies whether the vehicle is turning right,left or going straight.

DEVELOPMENT OF THE SIMULINK MODEL:

The main subsytem 'Vehicle_Direction'along with inputs 'Steering Wheel_YawDegreeInput','CameraInput_Roadsign'and output signal 'Vehicle_Direction_Indicator' is shown below.

Fig 1:'Vehicle_Direction'subsystem

The main Subsystem'Vehicle_Direction ' further divided in to two more subsystems whcih are 'Requirement1' and 'Requirement2' as shown blow:

Figure 2:'Requirement1' and 'Requirement2' subsystems

Requirement-1:

• In the 'Requirement1' subsystems the steering wheel yaw degree (Signal name:SteeringWheel_YawDegreeInput)is fed as input to the subsystem and this value is compared against 3 angular values,one each for left Turn,right Turn & straight drive(Calibration values:Right_Turn_AngularLimit,Left_Turn_AngularLimit,Straight_Drive_Steering_Angle)to say which specifc direction the steering wheel is turning towards.
• The input signal 'SteeringWheel_YawDegreeInput' is compared against three angular values using the relational operator '==',one each for left turn,right turn & straight drive.(Calibration Values: Right_Turn_AngularLimit, Left_turn_AngularLimit, Straight_Drive_Steering_Angle) to say which specific direction the steering wheel is turning towards.In this case, The output of the relational opertor'==' is equal to 1 only when the 'SteeringWheel_YawDegreeInput' matches the calibration value angular limit specified in Right_Turn_AngularLimit,Left_Turn_AngularLimit,or Staright_Drive_Steering_Angle.
• Three Switch blocks are used to implement an if-else logic.The output from each relational operator is given as a condition input (input2) to each Switch block.the Switch will pass input1 (Calibration value) when the condition (input2~=0)condition is satisfied,else input3(Output from the next switch block )is passes as output.
• The signal'Vehicle_Turn_Status' obtained at the output of the first switch will be a calibration angular value (Right_Turn_AngularLimit OR Left_Turn_AngularLimit,OR Straight_Drive_Steering_Angle).if none of the conditions get satisfied,zero is passed as the output from the last switch.The signal 'Vehicle_Turn_Status' is fed to the output of subsystem 'Requirement1'.

Figure 3:'Requirement-1' subsystem

Requirement-2:

In 'Requirement2' subsystem,the local signal 'Vehicle_Turn_Status'fed from 'Requirement1' subsystem is taken as input and is compared against calibration values (RightTurn_Roadsign.LeftTurn_RoadSign,Straight_RoadSign)using the relational operator'=='.

The boolean value obtained at the output of the relational operator is compared against boolean input signal from camera (Signal Name: CameraInput_Roadsign),which confirms the occurence of a road sign using 'AND'operator.

The boolean output signal obtained from each of the three 'AND'blocks are fed to the ouport 'VehicleDirection_indicator'to indicate the vehicle direction.the outport 'Vehicle_Direction_Indicator'will be a three dimensional signal having three boolean elements,with the first element to indicate 'Right Turn',second element to indicate 'Left Turn' and third element to indicate 'Straight Drive'.

FIGURE: 4 'Reqiurement2' subsystem

Requirement Tagging of simulink Model:

The requirements 'Requirement-1' and Requirement-2 as provided in the Requirements word document are tagged to their corressponding subsystem in the Simulink Model.

The steps involved in tagging a requirement in the Simulink model is to first highlight the requirement statement in the Word document,then Right click on the subsystem in the model that has to be tagged,then select 'Requirements' and then 'Link to selection in Word'.

FIGURE 5: Highlighting the requirement to be tagged in requirement Word document.

FIGURE:6 Tagging 'Requirement1' Subsystem to its requirements in Word document.

Creation of Simulink Data Dictionary file(SLDD):

A Simulink Data Dictionary (SLDD) file is created that contains input,output sognals and calibration parameters used in the model .SLDD file is created by clicking on Modeling,then 'Model Properties',then 'External Data' and specifying a file name for the data Dictionary.

FIGURE:7 Simulink Data Dictionary Dialog box.

signals & calibration Data list:

Signals & Calibration Data List:

Signal / Calibration Name	Signal Type	Data Type	Dimension	Min	Max	Initial Value	Units
SteeringWheel_YawDegreeInput	Input	Int16	1	-180	180	-	Deg
CameraInput_RoadSign	Input	Boolean	1	0	1	-	-
Vehicle_Turn_Status	Local	Int16	1	-180	180	-	Deg
Right_Turn_AngularLimit	Calibration	Int16	[1 1]	-180	180	30	Deg
Left_Turn_AngularLimit	Calibration	Int16	[1 1]	-180	180	-120	Deg
Straight_Drive_Steering_Angle	Calibration	Int16	[1 1]	-180	180	0	Deg
RightTurn_RoadSign	Calibration	Int16	[1 1]	-180	180	30
LeftTurn_RoadSign	Calibration	Int16	[1 1]	-180	180	-120
Straight_RoadSign	Calibration	Int16	[1 1]	-180	180	0
Vehicle_Direction_Indicator	Output	Boolean	1	0	1	-	-

FIGURE: 9 Simulink Data Dictionary Input,output and calibration parameters in Model Explorer.

MAB Guidelines Check in Model Advisor :

A check is performed using the 'Model Advisor' Tool in simulink to see whether developed model meets the modelling standards for MAAB.

FIGURE:10 MAB Guidelines Check in Model Advisor.

Generated report should be showned below

FIGURE:11 generated report for vehicle_direction.

Hardness Test :

The Hardness Test of Model-In-Loop and Software-In-Loop can be created by right clicking the subsystem-created the Test for Vehicle_Direction.It is perform to validate our model whether it is gives our expected output with respect to the actual input.

Figure:12 Hardness Test creation for model.

Select the Sources and Sinks as the Signal builder and outport in the basic properties.

FIGURE:13 Basic Properties of the Test Hardness.

set the advanced properties to the Model-In-Loop Test ,In this setting Normal will represents the Model-In-Loop Test.

FIGURE:14 Selection of Model-In-Loop Test.

vehicle should be running in one directionSignal builder test cases with the step form as a Time. all our signs of right turn,left turn,straight drive as a boolean form because it is either ON or OFF.negative degree represents the left turn ,positive degree should be right turn and straight is 0.

FIGURE:15 Test Cases of Right Turn,Left Turn and straight drive.

Imported signal builder should be in step form.The actual values are given as the input in the Model-In-Loop test.

Figure:16 Test cases of sign direction.

The hardness test created import the test cases in the signal builder and connect the scope through the mux and subtract block is used to get the difference of the actual and expected signs.

Figure:17 Model-In-Loop Test.

The Actual test cases are running with the simulaiton time of 4sec and check the results.When the vehicle direction is right side in around 1 sec and then left turn on the 1 to 2 seconds and going straight drive in 2 to 3 seocnds finally ends with 4 seconds.

FIGURE:18 Actual value.

Actual Value vs expected value:

The difference of the actual and expected should be zero our actual direction is matches with the expected sdirection.

FIGURE:19 plot of actual vs expected.

The Model-In-Loop test convert the model in to C-code after the software loop test.create the software in loop test and checking the actual and expected directions codes can be created.The code should be in C-code.when going for the SIL test first fo all we have set our subsystem into atomic subsytem.

Figure:20 changed to atomic subsystem(which is used to set the sample time).

FIGURE:21 Software In Loop Test.

same testing procedure to check the test cases are created by using the signal builder and perform the SIL test.

Results:

Both the MIL(MODEL-IN-LOOP)and SIL(SOFTWARE-IN-LOOP) are same test cases so the actual direction is same as the direction given in the MIL.

ACTUAL VS EXPECTED :due to difference of the signal we can get the zero so our actual matches the expected.

By runnig the simulation of the SIL C-code has been created in the saperate folder

FIGURE:22 folder of C-Code.

The C-Code in the Hardware in loop and tranfered to the ECU of the vehicle.The c-code is created based on the if-else condition because of using the switch(i.e.switch is running under the if-else condition).

CODE FOR VEHICLE DIRECTION:

/*
 * File: Vehicle_Direction0.c
 *
 * Code generated for Simulink model 'Vehicle_Direction0'.
 *
 * Model version                  : 1.11
 * Simulink Coder version         : 9.3 (R2020a) 18-Nov-2019
 * C/C++ source code generated on : Sat Jun 25 14:25:45 2022
 *
 * Target selection: ert.tlc
 * Embedded hardware selection: Intel->x86-64 (Windows64)
 * Code generation objectives: Unspecified
 * Validation result: Not run
 */

#include "Vehicle_Direction0.h"
#include "Vehicle_Direction0_private.h"

/* Exported data definition */

/* Definition for custom storage class: ExportToFile */
boolean_T Vehicle_Direction_Indicator[3];/* '/Signal_Conversion' */

/* Const memory section */
/* Definition for custom storage class: Const */
const int16_T LeftTurn_RoadSign = -120;/* Referenced by: '/Constant1' */
const int16_T Left_Turn_AngularLimit = -120;/* Referenced by: '/Constant2' */
const int16_T RightTurn_RoadSign = 30; /* Referenced by: '/Constant' */
const int16_T Right_Turn_AngularLimit = 30;/* Referenced by: '/Constant' */
const int16_T Straight_Drive_Steering_Angle = 0;/* Referenced by: '/Constant1' */
const int16_T Straight_RoadSign = 0;   /* Referenced by: '/Constant2' */

/* Real-time model */
RT_MODEL_Vehicle_Direction0_T Vehicle_Direction0_M_;
RT_MODEL_Vehicle_Direction0_T *const Vehicle_Direction0_M =
  &Vehicle_Direction0_M_;

/* Model step function */
void Vehicle_Direction0_step(void)
{
  /* local block i/o variables */
  int16_T Vehicle_Turn_Status;

  /* Outputs for Atomic SubSystem: '/Vehicle_Direction' */
  /* Switch: '/Switch1' incorporates:
   *  Constant: '/Constant'
   *  Constant: '/Constant2'
   *  Constant: '/Constant'
   *  Constant: '/Constant'
   *  Inport: '/SteeringWheel_YawDegreeInput'
   *  RelationalOperator: '/Compare'
   *  RelationalOperator: '/Compare'
   *  Switch: '/Switch'
   */
  if (SteeringWheel_YawDegreeInput > 0) {
    Vehicle_Turn_Status = Right_Turn_AngularLimit;
  } else if (SteeringWheel_YawDegreeInput == 0) {
    /* Switch: '/Switch' incorporates:
     *  Constant: '/Constant1'
     */
    Vehicle_Turn_Status = Straight_Drive_Steering_Angle;
  } else {
    Vehicle_Turn_Status = Left_Turn_AngularLimit;
  }

  /* End of Switch: '/Switch1' */

  /* SignalConversion: '/Signal_Conversion' incorporates:
   *  Constant: '/Constant'
   *  Constant: '/Constant1'
   *  Constant: '/Constant2'
   *  Inport: '/CameraInput_RoadSign'
   *  Logic: '/Logical Operator'
   *  Logic: '/Logical Operator1'
   *  Logic: '/Logical Operator2'
   *  RelationalOperator: '/Equal'
   *  RelationalOperator: '/Equal1'
   *  RelationalOperator: '/Equal2'
   */
  Vehicle_Direction_Indicator[0] = ((Vehicle_Turn_Status == RightTurn_RoadSign) &&
    CameraInput_RoadSign);
  Vehicle_Direction_Indicator[1] = ((Vehicle_Turn_Status == LeftTurn_RoadSign) &&
    CameraInput_RoadSign);
  Vehicle_Direction_Indicator[2] = ((Vehicle_Turn_Status == Straight_RoadSign) &&
    CameraInput_RoadSign);

  /* End of Outputs for SubSystem: '/Vehicle_Direction' */
}

/* Model initialize function */
void Vehicle_Direction0_initialize(void)
{
  /* (no initialization code required) */
}

/* Model terminate function */
void Vehicle_Direction0_terminate(void)
{
  /* (no terminate code required) */
}

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

CODE OF MAIN:

/*
 * File: ert_main.c
 *
 * Code generated for Simulink model 'Vehicle_Direction0'.
 *
 * Model version                  : 1.11
 * Simulink Coder version         : 9.3 (R2020a) 18-Nov-2019
 * C/C++ source code generated on : Sat Jun 25 14:25:45 2022
 *
 * Target selection: ert.tlc
 * Embedded hardware selection: Intel->x86-64 (Windows64)
 * Code generation objectives: Unspecified
 * Validation result: Not run
 */

#include 
#include               /* This ert_main.c example uses printf/fflush */
#include "Vehicle_Direction0.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(Vehicle_Direction0_M, "Overrun");
    return;
  }

  OverrunFlag = true;

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

  /* Step the model */
  Vehicle_Direction0_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 */
  Vehicle_Direction0_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(Vehicle_Direction0_M) == (NULL)) {
    /*  Perform other application tasks here */
  }

  /* Disable rt_OneStep() here */

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

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

CODE FOR DATA TYPE:

/*
 * File: Vehicle_Direction0_ca.c
 *
 * Abstract: Tests assumptions in the generated code.
 */

#include "Vehicle_Direction0_ca.h"

CA_HWImpl_TestResults CA_Vehicle_Direction0_HWRes;
CA_PWS_TestResults CA_Vehicle_Direction0_PWSRes;
const CA_HWImpl CA_Vehicle_Direction0_ExpHW = {
  8,                                   /* BitPerChar */
  16,                                  /* BitPerShort */
  32,                                  /* BitPerInt */
  32,                                  /* BitPerLong */
  64,                                  /* BitPerLongLong */
  32,                                  /* BitPerFloat */
  64,                                  /* BitPerDouble */
  64,                                  /* BitPerPointer */
  64,                                  /* BitPerSizeT */
  64,                                  /* BitPerPtrDiffT */
  CA_LITTLE_ENDIAN,                    /* Endianess */
  CA_ZERO,                             /* IntDivRoundTo */
  1,                                   /* ShiftRightIntArith */
  0,                                   /* LongLongMode */
  0,                                   /* PortableWordSizes */
  "Intel->x86-64 (Windows64)",         /* HWDeviceType */
  0,                                   /* MemoryAtStartup */
  0,                                   /* DenormalFlushToZero */
  0                                    /* DenormalAsZero */
};

CA_HWImpl CA_Vehicle_Direction0_ActHW;
void Vehicle_Direction0_caRunTests(void)
{
  /* verify hardware implementation */
  caVerifyPortableWordSizes(&CA_Vehicle_Direction0_ActHW,
    &CA_Vehicle_Direction0_ExpHW, &CA_Vehicle_Direction0_PWSRes);
  caVerifyHWImpl(&CA_Vehicle_Direction0_ActHW, &CA_Vehicle_Direction0_ExpHW,
                 &CA_Vehicle_Direction0_HWRes);
}

CONCLUSION:

The vehicle direction model has been developed successfully by using the matlab.