AUTOMATIC FUEL FIRE CONTROLLER

REPORT SUBMITTED
IN FULFILLMENT OF
SUMMER
INTERNSHIP
PROJECT

BACHELOR OF
TECHNOLOGY
ELECTRONICS AND
COMMUNICATION
ENGINEERING
BY
AYUSH
SRIVASTAVA
BE16EC026
(1612231030)

Shri Ramswaroop Memorial group of Professional Colleges

LUCKNOW

PROJECT GUIDE AT VE COMMERCIAL VEHICLES LTD.

COMPILED BY GUIDED BY SUPERVISED BY

AYUSH GURKIRAT SINGH BIJENDRA KUMAR

SRIVASTAVA
 ABSTRACT

We are living in technology driven environment. Autonomous or manual vehicles

have the potential to transfer travel behavior. However existing analysis have
ignored strategic interaction with other road users. This report identifies
outstanding safety and research for the School buses.
A safety system for vehicle comprises
 Sensor for detecting angles.
 Sensor for detecting crash.
 Sensor for detecting rate of flow of fuel.
Vehicles after toppling or meeting with an accident catches fire in 6% of the
cases which lead to risk of person’s life. To avoid such damage during accidents,
AUTOMATIC FUEL FIRE CONTROLLER is made.
SUMMARY:

 Accidents have become very common nowadays. In most of the cases the
accidents are so severe that the vehicles catches fire and it can damage the
person’s life.
 Automatic fire fuel controller is a microcontroller device that is being made to
avoid such conditions.
 In this case the fuel flow is automatically cut off when there is a crash or a
scenario of leakage.
 A RESET switch is provided in case of fuel leakage or in case of a crash. The
driver can press the reset switch to restart the flow of fuel.
 All the messages are transmitted through CAN communication.
TABLE OF CONTENTS:

1. Methodology
2. PIC Microcontroller
 2.1. Architecture
 2.2. Structure
 2.3. Pin Diagram

3. Automatic fire fuel controller (AF2C)

 3.1. Objective
 3.2. Block Diagram

4. Crash Sensor (SMI130)

 4.1. Block Diagram
 4.2. Accelerometer
 4.3. Gyroscope
 4.4. Pin Diagram

5. CAN (Controller Access Network)

 5.1. Data Transmission
 5.2. J1939 Protocol
 5.3. Wiring Topology

6. Acknowledgement
7. References
 1. Methodology

This project is carried out in cooperation with VE Commercial Vehicles ltd. This is
divided into several steps:

 Literature survey of Crash sensor , Angle sensors and the rate of Fuel flow
 Development of micro-controller with sensors with the help of CAN sensor
 Proof of Concept
 Validation of the project carried out
 Post Processing & Review the Results
 Implementation of the project.
2 .PIC-MICROCONTROLLER

2.1 Architecture
PIC16F877A Features

PIC16F877A –Simplified Features

CPU 8-bit PIC
Number of Pins 40
Operating Voltage (V) 2 to 5.5 V
Number of I/O pins 33
ADC Module 8ch, 10-bit
Timer Module 8-bit(2), 16-bit(1)
Comparators 2
DAC Module Nil
Communication Peripherals UART(1), SPI(1), I2C(1), MSSP(SPI/I2C)
External Oscillator Up to 20Mhz
Internal Oscillator Nil
Program Memory Type Flash
Program Memory (KB) 14KB
CPU Speed (MIPS) 5 MIPS
RAM Bytes 368

Data EEPROM 256 bytes

PIC stands for Peripheral interface controller.

2.2 STRUCTURE:-
2.3 PIN DIAGRAM:-
PIC16F877A Pin Configuration

Pin
Pin Name Description
Number
MCLR is used during programming, mostly connected
1 MCLR/Vpp
to programmer like PicKit
2 RA0/AN0 Analog pin 0 or 0th pin of PORTA
3 RA1/AN1 Analog pin 1 or 1st pin of PORTA
4 RA2/AN2/ Vref- Analog pin 2 or 2nd pin of PORTA
5 RA3/AN3/ Vref+ Analog pin 3 or 3rd pin of PORTA
6 RA4/T0CKI/C1out 4th pin of PORTA
7 RA5/AN4/SS/C2out Analog pin 4 or 5th pin of PORTA
8 RE0/RD/AN5 Analog pin 5 or 0th pin of PORTE
9 RE1/WR/AN6 Analog pin 6 or 1st pin of PORTE
10 RE2/CS/AN7 7th pin of PORTE
11 VDD Ground pin of MCU
12 VSS Positive pin of MCU (+5V)
13 OSC1/CLKI External Oscillator/clock input pin
14 OSC2/CLKO External Oscillator/clock output pin
15 RC0/T1OSO/T1CKI 0th pin of PORT C
16 RC1/T1OSI/CCP2 1st pin of POCTC or Timer/PWM pin
17 RC2/CCP1 2nd pin of POCTC or Timer/PWM pin
18 RC3/SCK/SCL 3rd pin of POCTC
19 RD0/PSP0 0th pin of POCTD
20 RD1/PSPI 1st pin of POCTD
21 RD2/PSP2 2nd pin of POCTD
22 RD3/PSP3 3rd pin of POCTD
23 RC4/SDI/SDA 4th pin of POCTC or Serial Data in pin
24 RC5/SDO 5th pin of POCTC or Serial Data Out pin
25 RC6/TX/CK 6th pin of POCTC or Transmitter pin of Microcontroller
26 RC7/Rx/DT 7th pin of POCTC or Receiver pin of Microcontroller
27 RD4/PSP4 4th pin of POCTD
28 RD5/PSP5 5th pin of POCTD
29 RD6/PSP6 6th pin of POCTD
30 RD7/PSP7 7th pin of POCTD
31 VSS Positive pin of MCU (+5V)
32 VDD Ground pin of MCU
33 RB0/INT 0th pin of POCTB or External Interrupt pin
34 RB1 1st pin of POCTB
35 RB2 2nd pin of POCTB
36 RB3/PGM 3rd pin of POCTB or connected to programmer
37 RB4 4th pin of POCTB
38 RB5 5th pin of POCTB
39 RB6/PGC 6th pin of POCTB or connected to programmer
40 RB7/PGD 7th pin of POCTB or connected to programmer
3. AF2C:

3.1 OBJECTIVE:-

To enhance vehicle and customer safety in case of fire, Accident\Toppling &water

mixing through a controller.
Few important points to be looked:-
 All the information must be sent through CAN messages.
 Main sensors which are used in the controller are CRASH, ANGLE, FUEL FLOW
sensors.
 ANGLE sensor activates the sensor when the angle of the vehicle made with the
road increases more than 65 degrees.
 CRASH sensor activates when there is a possibility of crash.
 The fuel flowing in the fuel line is in mg per sec. It is compared with the flow rate
of fuel which is given by CAN messages.
If the fuel flowing rate is greater than the fuel rate through CAN messages then there is
possibility of leakage in the fuel.
If the fuel flowing rate is less than fuel rate through CAN messages then there is
possibility of choke in the engine.
 We use NC (normally closed) valve instead of NO (normally open).
In case of NO we see that the valve is always opened even when the engine is off, this
may lead to malfunctioning of the valve and can even block the transmission of fuel in
the engine. Therefore, we use NC instead of NO.
 The CRASH sensor we require must have a high range of values so that it
can be activated quickly.
 SMI130 of BOSCH sensor can be used exactly for the same.
 FDAS (Fire Detection Alarming System) is used to detect the any smoke, fire
in the vehicle.
 We will use DTC (Diagnostic Trouble Codes).
 If there is a case of water in fuel, a sensor is used to detect the same and a
warning is given to the driver.
Even if the driver continues to drive after the warning, the vehicle will
automatically come to a halt after few moments/kilometers. If the place is not
resourceful enough to provide proper maintenance to the vehicle, the driver
can press the override button so that the driver can take the vehicle to a
particular Service Centre for the maintenance of the vehicle.
3.2 BLOCK DIGRAM:

RESET SWITCH

RPM (CAN)

APU (CAN)

WIF (CAN)
TO
FDAS AF2C Controller FUEL
SHUT
CRASH SENSOR OFF
SOLENOID
FUEL FLOW RATE
METER

ANGLE SENSOR

FEED PUMP INPUT

12 OR 24 VOLT
GROUND
IGNITION SUPPLY

STRUCTURE OF AUTOMATIC FUEL FIRE CONTROLLER

ADVANTAGES:-

 In case of fire& vehicle accident vehicle goes in fuel shut off mode. Saves from
fire spread which ensures the vehicle and passenger safety.
 Avoid system failure due to water fuel fixing by stopping fuel discharge.

4. CRASH SENSORS (SMI130)

The SMI130 is a combined triaxial accelerometer (ACC) and triaxial gyroscope (GYR)
for no safety related applications, e.g. for in-dash navigation in the passenger
compartment. Within one package, the SMI130 offers the detection of acceleration and
angular rate for the x-, y- and z axis. The digital standard serial peripheral interface
(SPI) of the SMI130 allows for bi-directional data transmission.

Working Principle of the Sensing Elements (MEMS)

The inertial sensor SMI130 is based upon a combined two-chip stacked concept:
Accelerometer and gyroscope both consist of a separated evaluation ASIC and a micro-
mechanical sensing element (MEMS). The SMI130 combines both stacked sensors
side-by-side within a standard LGA package.
4.1.BLOCK DIAGRAM:

4.2. Accelerometer
The accelerometer offers temperature and acceleration data for all three spatial
dimensions. For the latter, the differential capacitance change (C) of the corresponding
sensing element is detected. These signals correspond to the voltage (V) entering the
hybrid algorithmic analog-digital converter (ADC), translating the formerly analog signals
into digital serial bit streams at a rate of 400 kHz. Then, the detected signal is translated
into a data word of max. 16 bits and enters the digital signal processor (DSP).
Within the DSP (see Figure 2-4), the data is corrected for the analog-digital conversion,
gained and offset corrected. A low-pass filter engine provides an adjustable data
bandwidth. Here, the sampling rate is directly connected with the selected bandwidth.
The low-pass engine can be bypassed so that unfiltered data is accessible.

4.3. Gyroscope

The signal path of the gyroscope is sketched in Figure 2-5. For proper data acquisition,
five blocks are necessary for each rate axis, i.e., the drive, the (MEMS) sensor, the
detection, the controller & demodulator and the digital signal processor (DSP). In
addition, a temperature signal is provided by the temperature sensor.
The drive is a closed-loop system that actively moves each sensor element at ~25 kHz.
The block ‘Detection’ corresponds to the analog part of the SMI130. The differential
capacitance change (C) of each sensing element corresponds to the rate data of the
respective sensing axis. The latter corresponds to the voltage (V) entering the 25 kHz
filter which is confirm to the drive frequency. The 1-bit ADC Converter translates the
signal into a digital serial bit stream at a rate of 400 kHz.
This bit stream is fed into both the common mode controller and the demodulator. The
first back couples to ‘C/V’ in order to negate mass deviation of the sensor element. The
latter demodulates the 25 kHz data signal which then enters the DSP.
In the DSP, the signal is both fed into the quadrature correction and offset shifted.
Afterwards, it is fine gained and low pass filtered before being accessible via e.g. SPI.
The block ‘Quad. Corr.’ back-couples onto distinctive pads on the sensing element to
compensate for possible deviations from the oscillation axis.

The SMI130 has two distinct power supply pins:

• VDD is the main power supply for the internal blocks.
• VDDIO is a separate power supply pin mainly used for the supply of the interface.

The SMI130 provides a power-on reset (POR) generator. It resets the logic part and the
register values after powering on VDD and VDDIO.

1. After POR, all settings are reset to the default values.

2. In the case that VDD < 1.8 V or VDDIO < 1V for longer than 1 ms, a safe POR (see
below) is required. Else, the device may end up in an undefined state.
4.4PIN DIAGRAM:
5. CAN (Controller Access Network):
A Controller Area Network (CAN bus) is a robust vehicle bus standard designed to
allow microcontrollers and devices to communicate with each other in applications
without a host computer. It is a message-based protocol, designed originally for
multiplex electrical wiring within automobiles to save on copper, but is also be used in
many other contexts.
CAN bus is one of five protocols used in the on-board diagnostics (OBD)-II vehicle
diagnostics standard. The OBD-II standard has been mandatory for all cars and light
trucks sold in the United States since 1996. The EOBD standard has been mandatory
for all petrol vehicles sold in the European Union since 2001 and all diesel vehicles
since 2004.

5.1. DATA TRANSMISSION:

CAN data transmission uses a lossless bitwise arbitration method of contention

resolution. This arbitration method requires all nodes on the CAN network to be
synchronized to sample every bit on the CAN network at the same time. This is why
some call CAN synchronous. Unfortunately the term synchronous is imprecise since the
data are transmitted without a clock signal in an asynchronous format.
The CAN specifications use the terms "dominant" bits and "recessive" bits where
dominant is a logical 0 (actively driven to a voltage by the transmitter) and recessive is a
logical 1 (passively returned to a voltage by a resistor). The idle state is represented by
the recessive level (Logical 1). If one node transmits a dominant bit and another node
transmits a recessive bit then there is a collision and the dominant bit "wins". This
means there is no delay to the higher-priority message, and the node transmitting the
lower priority message automatically attempts to re-transmit six bit clocks after the end
of the dominant message. This makes CAN very suitable as a real-time prioritized
communications system.
The exact voltages for a logical 0 or 1 depend on the physical layer used, but the basic
principle of CAN requires that each node listen to the data on the CAN network
including the transmitting node(s) itself (themselves). If a logical 1 is transmitted by all
transmitting nodes at the same time, then a logical 1 is seen by all of the nodes,
including both the transmitting node(s) and receiving node(s). If a logical 0 is transmitted
by all transmitting node(s) at the same time, then a logical 0 is seen by all nodes. If a
logical 0 is being transmitted by one or more nodes, and a logical 1 is being transmitted
by one or more nodes, then a logical 0 is seen by all nodes including the node(s)
transmitting the logical 1. When a node transmits a logical 1 but sees a logical 0, it
realizes that there is a contention and it quits transmitting. By using this process, any
node that transmits a logical 1 when another node transmits a logical 0 "drops out" or
loses the arbitration.

For example, consider an 11-bit ID CAN network, with two nodes with IDs of 15 (binary
representation, 00000001111) and 16 (binary representation, 00000010000). If these
two nodes transmit at the same time, each will first transmit the start bit then transmit
the first six zeros of their ID with no arbitration decision being made.
When the 7th ID bit is transmitted, the node with the ID of 16 transmits a 1 (recessive)
for its ID, and the node with the ID of 15 transmits a 0 (dominant) for its ID. When this
happens, the node with the ID of 16 knows it transmitted a 1, but sees a 0 and realizes
that there is a collision and it lost arbitration. Node 16 stops transmitting which allows
the node with ID of 15 to continue its transmission without any loss of data. The node
with the lowest ID will always win the arbitration, and therefore has the highest priority.

5.2. J1939 PROTOCOL:

J1939 is a set of standards defined by SAE. They are used in heavy-duty vehicles such
as trucks and buses, mobile hydraulics, etc. In many ways, J1939 is similar to the older
J1708 and J1587 standards, but J1939 is built on CAN.
The physical layer (J1939/11) describes the electrical interface to the bus. The data link
layer (J1939/21) describes the rules for constructing a message, accessing the bus, and
detecting transmission errors.

 Higher-layer protocol built on CAN

 Used in heavy-duty vehicles
 The speed is nearly always 250 Kbit/s or 500 Kbit/s
 J1939 uses the 29-bit identifier defined within the CAN 2.0B protocol shown in
Figure 1. The identifier is used slightly different in a message with a destination
address (”PDU 1”) compared to a message intended for broadcast (”PDU 2”).
 PDU stands for Protocol Data Unit (i.e. Message Format).
 The SOF, SRR, and IDE bits are defined by the CAN standard and will be
ignored here. The RTR bit (remote request bit) is always set to zero in J1939.
 The 29-bit identifier used in J1939 is structured in the following way.

The first three bits of the identifier are used for controlling a message’s priority during
the arbitration process. A value of 0 has the highest priority. Higher priority values are
typically given to high-speed control messages, for example, the torque control
message from the transmission to the engine. Messages containing data that is not time
critical, like the vehicle road speed, are given lower priority values.

The next bit of the identifier is reserved for future use and should be set to 0 for
transmitted messages.
The next bit in the identifier is the data page selector. This bit expands the number of
possible Parameter Groups that can be represented by the identifier.

The PDU format (PF) determines whether the message can be transmitted with a
destination address or if the message is always transmitted as a broadcast message.

The interpretation of the PDU specific (PS) field changes based on the PF value:

 If the PF is between 0 and 239, the message is addressable (PDU1) and the
PS field contains the destination address.
 If the PF is between 240 and 255, the message can only be broadcast
(PDU2) and the PS field contains a Group Extension.

The Group extension expands the number of possible broadcast Parameter Groups that
can be represented by the identifier.

5.3. Wiring Topology – Physical Layer (J1939/1x)

The J1939 network is intended to be a single, linear, shielded twisted pair of wires
running around the vehicle to each ECU. A short stub is permitted between the ECU
and the “bus”. This simplifies routing the main bus wiring by not requiring the main bus
to connect directly to each ECU. The linear bus is necessary at a data rate of 250 Kbps
in order to minimize electrical signal reflections. The termination resistor at each end of
the bus also reduces reflections.
The J1939 network may actually be composed of multiple segments, with an in-line
device known as a bridge present between them. These segments do not need to be
directly compatible with each other. For instance, the segments may run at different
data rates or use a different physical medium. The main function of the bridge is to
provide electrical isolation between segments. In the event of a break on the wire
between the tractor and trailer, the main J1939 segment on the tractor will continue to
function. The bridge can also selectively filter which messages need to be stored and
forwarded from one segment to another.
 ACKNOWLEDGEMENT

I would like to express my gratitude to my project guide Mr. Gurkirat

Singh (Junior Manager, CVD-Electrical, VECV) for his valuable guidance,
constant encouragement and for sharing his vast pool of knowledge.
I would like to thank my mentor Mr. Bijendra Kumar (Senior Manager,
VECV) for his painstaking efforts and support that he had provided me
during this project. He has always been benevolent and affable towards me
throughout my project tenure.
I would like to thank the entire team of Electrical Department, VECV, for
constantly showering their knowledge throughout this project which has
helped me to gain valuable knowledge in this domain.
I would like to thank my parents and my colleague for their constant support and
love.
 REFERENCES

https://en.wikipedia.org/wiki/CAN_bus
https://www.edgefx.in/pic-microcontroller-architecture-and-applications/
https://www.kvaser.com/about-can/higher-layer-protocols/j1939-introduction/
 https://en.wikipedia.org/wiki/SAE_J1939