can protocol for vehicle

8/12/2019 Can Protocol for Vehicle

1/9

IMPEMENTATION OF CAN PROTOCOL FOR VEHICLE MONITORING

INTRODUCTION

CAN is an attractive alternative in the automotive and automation industries due to its ease in

use, low cost and provided reduction in wiring complexity. CAN stands for Controller Area

Network. It is a protocol which defines a set of rules of data transfer from one point to another

point. CAN protocol was developed for making sure data from one node gets transferred to

another node between two connection safely and securely without any data corruption and

without missing any of the data. CAN protocol was mainly intended for short length data transfer

like in automobiles. The main feature of the system includes monitoring of various vehicle

parameters such as Temperature, obstacle detection (for collision avoidance), Light sensor, Fuel

Level Detection and Alarming and speed controlling with display. The development of CAN

began when more and more electronic devices were implemented into modern motor

vehicles. Examples of such devices include temperature control if temperature goes to

beyond level user turning on the ac and active pressure control indicates for vehicle

safety point. The humidity sensors control internal level of humidity in the cabin effectively.


2/9

LITERATURE SURVEY

[4] Control Systems for Automotive Vehicle Fuel Economy: This paper is a review of current

research on applications of control systems and theory to achieve energy conservation in

automotive vehicles. The development of internal combustion engine control systems that

modulate fuel flow, air flow, ignition timing and duration, and exhaust gas recirculation is

discussed. The relative advantages of physical and empirical models for engine performance are

reviewed. Control strategies presented include optimized open-loop schedule type systems,

closed-loop feedback systems, and adaptive controllers. The development of power train and

hybrid vehicle control systems is presented, including controllers for both conventional

transmissions and those employing flywheel energy storage.

[1] CAN Specification-Version 2.0: The Controller Area Network (CAN) is a serial

communications protocol which efficiently supports distributed realtime control with a very high

level of security. Its domain of application ranges from high speed networks to low cost

multiplex wiring. n automotive electronics, engine control units, sensors, anti-skid-systems, etc.

are connected using CAN with bitrates up to 1 Mbit/s. At the same time it is cost effective to

build into vehicle body electronics, e.g. lamp clusters, electric windows etc. to replace the wiring

harness otherwise required. The intention of this specification is to achieve compatibility

between any two CAN implementations. Compatibility, however, has different aspects regarding

e.g. electrical features and the interpretation of data to be transferred. To achieve design

transparency and implementation flexibility CAN has been subdivided into different layers.

the (CAN-) object layer

the (CAN-) transfer layer

the physical layer


3/9

Each layer is described in detail in this paper

[2] Vehicle control system implementation Using CAN protocol: Present Automobiles are

being developed by more of electrical parts for efficient operation. Generally a vehicle was built

with an analog driver - vehicle interface for indicating various vehicle status like speed, fuellevel, Engine temperature etc.,

This paper presents the development and implementation of a digital driving system for a

semiautonomous vehicle to improve the driver vehicle interface. It uses a n ARM based data

acquisition system that uses ADC to bring all control data from analog to digital format and

visualize through LCD. The communication module used in this project is embedded networking

by CAN which has efficient data transfer. It also takes feedback of vehicle conditions like

Vehicle speed, Engine temperature etc., and controlled by main controller. Additionally this unit

equipped with GSM which communicates to the owner during emergency situations.

With rapidly changing computer and information technology and much of the technology finding

way into vehicles. They are undergoing dramatic changes in their capabilities and how they

interact with the drivers. Although some vehicles have provisions for deciding to either generate

warnings for the human driver or controlling the vehicle autonomously, they usually must make

these decisions in real time with only incomplete information. So, it is important that human

drivers still have some control over the vehicle. Advanced in-vehicle information systems

provide vehicles with different types and levels of intelligence to assist the driver. The

introduction into the vehicle design has allowed an almost symbiotic relationship between the

driver and vehicle by providing a sophisticated & intelligent driver-vehicle interface through an

intelligent information network. This paper discusses the development of such a control

framework for the vehicle which is called the digital-driving behavior, which consists of a joint

mechanism between the driver and vehicle for perception, decision making and control. Existing

and Proposed vehicle control system Fig shows the vehicle control of existing and proposed

system. A vehicle was generally built with an analog driver-vehicle interface for indicating

various parameters of vehicle status like temperature, pressure and speed etc. To improve the

driver-vehicle interface, an interactive digital system is designed. A microcontroller based data

acquisition system that uses ADC to bring all control data from analog to digital format is used.


4/9

Since the in-vehicle information systems are spread out all over the body of a practical vehicle, a

communication module that supports to implement a one stop control of the vehicle through the

master controller of the digital driving system.

[3] The ARM7TDMI-S processor is a member of the ARM family of general-purpose 32-bitmicroprocessors. The ARM family offers high performance for very low-power consumption

and gate count. The ARM architecture is based on Reduced Instruction Set Computer (RISC)

principles. The RISC instruction set, and related decode mechanism are much simpler than those

of Complex Instruction Set Computer (CISC) designs. This simplicity gives:

a high instruction throughput

anexcellent real-time interrupt response

a small, cost-effective, processor macro-cell.

The ARM7TDMI-S is a general purpose 32-bit microprocessor, which offers high performanceand very low power consumption. The ARM architecture is based on Reduced Instruction Set

Computer (RISC) principles, and the instruction set and related decode mechanism are much

simpler than those of microprogrammed Complex Instruction Set Computers. This simplicity

results in a high instruction throughput and impressive real-time interrupt response from a small

and cost-effective processor core.

Pipeline techniques are employed so that all parts of the processing and memory system scan

operate continuously. Typically, while one instruction is being executed, its successor is being

decoded, and a third instruction is being fetched from memory.

The ARM7TDMI-S processor also employs a unique architectural strategy known as THUMB,

which makes it ideally suited to high-volume applications with memory restrictions, or

applications where code density is an issue. The key idea behind THUMB is that of a super-

reduced instruction set. Essentially, the ARM7TDMI-S processor has two instruction sets:

The standard 32-bit ARM instruction set.

A 16-bit THUMB instruction set.

The THUMB sets 16-bit instruction length allows it to approach twice the density of standard

ARM code while retaining most of the ARMs performance advantage over atraditional 16-bit


5/9

processor using 16-bit registers. This is possible because THUMB code operates on the same 32-

bit register set as ARM code.

THUMB code is able to provide up to 65% of the code size of ARM, and 160% of the

performance of an equivalent ARM processor connected to a 16-bit memory system.

The ARM7TDMI-S processor is described in detail in the ARM7TDMI-S Datasheet that

can be found on official ARM website.


6/9

BLOCK DIAGRAM

PIC

Microcontroller

SLAVE 1 IR Obstacle Sensor

(MASTER)

ARM-7

Activate AC

LCD

DISPLAY

PIC

Microcontroller

SLAVE 2

Obstacle Alarm

Speed Indicator

Lights On

Fuel Alarm

Motor Speed Control

Temperature Sensor

Fuel Sensor

Light Sensor

Speed Sensor


7/9

Block Diagram Description

Literature Survey

Problem Statement

Algorithm of Implementation

Relevance of Project

Low-Cost, Lightweight NetworkCAN provides an inexpensive, durable network that helps multiple CAN devices communicate

with one another. An advantage to this is that electronic control units (ECUs) can have a single

CAN interface rather than analog and digital inputs to every device in the system. This decreasesoverall cost and weight in automobiles.

Broadcast CommunicationEach of the devices on the network has a CAN controller chip and is therefore intelligent. All

devices on the network see all transmitted messages. Each device can decide if a message is

relevant or if it should be filtered. This structure allows modifications to CAN networks withminimal impact. Additional non-transmitting nodes can be added without modification to the

network.

PriorityEvery message has a priority, so if two nodes try to send messages simultaneously, the one with

the higher priority gets transmitted and the one with the lower priority gets postponed. This

arbitration is non-destructive and results in non-interrupted transmission of the highest prioritymessage. This also allows networks to meet deterministic timing constraints.

Error CapabilitiesThe CAN specification includes a Cyclic Redundancy Code (CRC) to perform error checking on

each frame's contents. Frames with errors are disregarded by all nodes, and an error frame can

be transmitted to signal the error to the network. Global and local errors are differentiated by thecontroller, and if too many errors are detected, individual nodes can stop transmitting errors or

disconnect itself from the network completely.


8/9

Components Used

Pressure Sensor:

Temperature Sensor:

Speed Sensor:

Ultrasonic/IR Obstacle Sensor:

Fuel Float Sensors:

PIC microcontrollers (12F/16F)

ARM 7 Microcontroller:

DC Motor:

LCD Display


9/9

REFERENCES

1.http://esd.cs.ucr.edu/webres/can20.pdf

2.http://www.ijareeie.com/upload/june/56_Vehicle%20control.pdf

3.http://infocenter.arm.com/help/topic/com.arm.doc.ddi0234b/DDI0234.pdf4. http://dynamicsystems.asmedigitalcollection.asme.org/article.aspx?articleid=1403174

5. http://www.researchgate.net/publication/228626144_Humidity_sensors_a_review_of_

materials_and_mechanisms

6.http://coecsl.ece.illinois.edu/ge423/sensorprojects/gilliam%20-%20temp%20sensors.pdf

7. The 8051 Microcontroller, Kenneth J Ayala

8. C and the 8051, Thomas W. Schultz

9. http://www.arm.com/files/pdf/ARM_Microcontroller_Code_Size_%28full%29.pdf
http://esd.cs.ucr.edu/webres/can20.pdfhttp://esd.cs.ucr.edu/webres/can20.pdfhttp://esd.cs.ucr.edu/webres/can20.pdfhttp://www.ijareeie.com/upload/june/56_Vehicle%20control.pdfhttp://www.ijareeie.com/upload/june/56_Vehicle%20control.pdfhttp://www.ijareeie.com/upload/june/56_Vehicle%20control.pdfhttp://infocenter.arm.com/help/topic/com.arm.doc.ddi0234b/DDI0234.pdfhttp://infocenter.arm.com/help/topic/com.arm.doc.ddi0234b/DDI0234.pdfhttp://infocenter.arm.com/help/topic/com.arm.doc.ddi0234b/DDI0234.pdfhttp://coecsl.ece.illinois.edu/ge423/sensorprojects/gilliam%20-%20temp%20sensors.pdfhttp://coecsl.ece.illinois.edu/ge423/sensorprojects/gilliam%20-%20temp%20sensors.pdfhttp://coecsl.ece.illinois.edu/ge423/sensorprojects/gilliam%20-%20temp%20sensors.pdfhttp://www.arm.com/files/pdf/ARM_Microcontroller_Code_Size_%28full%29.pdfhttp://www.arm.com/files/pdf/ARM_Microcontroller_Code_Size_%28full%29.pdfhttp://www.arm.com/files/pdf/ARM_Microcontroller_Code_Size_%28full%29.pdfhttp://coecsl.ece.illinois.edu/ge423/sensorprojects/gilliam%20-%20temp%20sensors.pdfhttp://infocenter.arm.com/help/topic/com.arm.doc.ddi0234b/DDI0234.pdfhttp://www.ijareeie.com/upload/june/56_Vehicle%20control.pdfhttp://esd.cs.ucr.edu/webres/can20.pdf

can protocol for vehicle

Documents