0% found this document useful (0 votes)
14 views

Relation Between Data Transfer Rate and Bus Length

Uploaded by

Sameer Rijal
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
14 views

Relation Between Data Transfer Rate and Bus Length

Uploaded by

Sameer Rijal
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 9

Relation between data transfer rate and bus length

The faster the bus, the more data it can move within a given amount of time.

The motherboard's bus transfers data between parts. The term "bus speed" refers to how
quickly the system bus can move data from one computer component to the other. The faster
the bus, the more data it can move within a given amount of time.

The system's "Front Side Bus" connects the CPU to the computer's "Northbridge," which
handles communication between the computer's RAM and the processor. This is the fastest part
of the bus and handles the automobile system

The Controller Area Network (CAN)


The Controller Area Network (CAN) is another type of serial communications protocol that was
developed within the automotive industry to allow a number of electronic units on a single
vehicle to share essential control data. A vehicle nowadays uses many microcontrollers for
autonomous control systems. Each microcontroller system is referred to as an electronic control
unit (ECU) and these include the engine management ECU, an anti-braking system (ABS) ECU,
a dashboard ECU, active suspension and the radio/CD player, for example. Each of these ECUs
manages its own control strategies, but they all need to access information relevant to their own
operation, for example drawn from engine speed, throttle position, brake pedal position and
engine temperature. However, an automotive vehicle generates a high level of electromagnetic
interference and a wide temperature and humidity range; this is a hostile environment for any
signal and indeed for any electronic device. Moreover, very high reliability is essential as
vehicles are safety-critical systems.

The types of control data that need sharing along the bus can vary. For example, the dashboard
ECU will need to access data including engine speed, engine temperature, vehicle speed
and diagnostic information, which will be predominantly provided by sensors attached to the
engine management and gearbox ECUs, as well as door open/closed data from the door ECUs.
Furthermore, if this vehicle is to implement an automatic door lock strategy once a threshold
vehicle speed has been achieved, then the door lock ECUs will need to access vehicle speed data
from the CAN bus.
The need for CAN

A vehicle contains a network of electronic devices that share data and information with one
another.

A spark-ignition engine, for instance, requires a spark to initiate the combustion chamber.
Timing is important here. To ensure this occurs accurately, it “communicates” with the vehicle’s
engine control unit, which chooses the ideal time for the ignition to provide the power and fuel
efficiency.

Another example of communication between devices includes that of an automobile’s


transmission-control unit. It automatically changes a vehicle’s gear in relation to its speed by
using data from the engine control unit and various sensors in the system. Every electronic
device has an ECU/MCU (electronic/microcontroller control unit) with its own set of rules to
share and transfer information.

However, for two or more devices to interact, they must be equipped with hardware and software
to properly communicate. Before CAN was used in vehicles, each electronic device was
connected to another via wires (or, more specifically, point-to-point wiring). This worked
effectively enough when the functions were basic. But one of the major problems for automotive
engineers as electronics advanced was linking the ECUs of different devices so that real-time
information could be exchanged. The CAN protocol was designed to address this problem.

The protocol set rules by which electronic devices can exchange information with one another
over a common serial bus. It reduced the wiring connections and the overall complexity of the
system.
The standard technology of the time — asynchronous transmitter/receiver — was unable to
support multi-domain communication. A domain is a group of electronic devices that have
similar requirements to work properly in the system. For example, a CD/DVD player, GPS, and
monitors and displays form a single domain. Similarly, the dashboard, air-conditioning system

(or climate control), wipers, lights, and door locks form another domain.
The electronic devices in a vehicle can be classified under different domains and CAN facilitates
multi-domain communication, which is a great help to auto engineers.

A vehicle’s multi-domain communication, supported by the CAN protocol.

How is the CAN protocol implemented?


The CAN protocol is a set of rules for transmitting and receiving messages in a network of
electronic devices. It defines how data is transferred from one device to another in a network.
Interestingly, CAN was developed with a specific focus on the auto industry but its architecture
and advantages have led several other industries (such as the railway, aircraft, and medical
sectors) to adopt the protocol as well.

Benefits

 Low cost: Since a CAN serial bus uses two wires (with high-volume and low-cost
production), it offers a good price-to-performance ratio.

 Reliable: CAN offers excellent error-detection and error-handling mechanisms,


which provides highly reliable transmission. It’s also largely immune to
electromagnetic interference.

 Flexible: CAN nodes are not limited by the protocol and can be easily connected or
disconnected.

 Fast: CAN supports a data rate of 1 MBit/s @ 40m bus length.

 Multi-master communication: Any node can access the bus

 Fault confinement: Faulty nodes do not disturb the communication.

 Broadcast capabilities: Messages can be sent to one /many/all nodes.

 Standardized: ISO has standardized the CAN protocol via ISO-DIS 11898 (for
high-speed applications) and ISO-DIS 11519-2 (for low-speed applications). The
CAN protocol is also standardized by industry organizations, such as the SAE-
Society of Automotive Engineers.

CAN as a CSMA protocol


CSMA is a carrier sense, multiple-access protocol in which node verifies the absence of traffic
before transmitting on a shared medium such as electrical bus. In CSMA each node on a bus
wait for a specific time before sending the message. Once this wait period is over every node has
equal opportunity to send the message. Based on pre-programmed priority of each message in
identifier field i.e. highest priority identifier wins the bus access. It is implemented on the
physical layer of OSI model. Let us understand CSMA with an example. In a discussion every
person gets an equal opportunity to voice their thoughts however when a person is talking others
keep quiet and listens and waits for their chance to speak (carrier sense). But if two or more

people start speaking at the same time then they detect the fact and quit speaking (collision
detection).

Carrier Sense Multiple Access/ Collision Detection (CSMA/CD)


Carrier sense multiple access with collision detection (CSMA/CD), is a network multiple access
method in which carrier sensing is used, but nodes attempt to avoid collisions by transmitting
only when the channel is sensed to be `idle`. When they do transmit, nodes transmit their packet
data in its entirety.

collision detection in which a transmitting station detects collisions by sensing transmissions


from other stations while it is transmitting a frame. When this collision condition is detected, the
station stops transmitting that frame, transmits a jam signal, and then waits for a random time
interval before trying to resend the frame

The following procedure is used to initiate a transmission. The procedure is complete when the
frame is transmitted successfully or a collision is detected during transmission.

1. Is a frame ready for transmission? If not, wait for a frame.


2. Is medium idle? If not, wait until it becomes ready
3. Start transmitting and monitor for collision during transmission.
4. Did a collision occur? If so, go to collision detected procedure.
5. Reset retransmission counters and complete frame transmission
Standard frame

Standard CAN Frame Format fields

depicts standard CAN frame structure. Following table-1 describes fields used in standard CAN
frame format. It uses 11 bit identifier.

Fields Description

Start of Frame bit. It marks start of message. It is used to synchronize nodes on the CAN
SOF bus.

It is 11 bit (binary) in size. It establishes priority of message. Lower the value, higher is
Identifier the priority.

It stands for Remote Transmission Request bit. This field is dominant when node requires
information from another remote node. All the nodes receive request and all the nodes
receive reply. Specific node processes the request based on identifier and transmits the
RTR reply.

Stands for Identifier Extension bit. It indicates standard CAN frame is being transmitted
IDE with no extension.

r0 It is reserved for future use.

Stands for Data length code. It is 4 bits in size. It indicates number of bytes to be
DLC transmitted over the CAN bus.
Data It contains upto 64 bits of application data.

It is used for error detection. It is 16 bits in size. It holds checksum for application data
CRC preceding to it.

It is 2 bits in size. It contains first bit as ack bit and second bit as delimiter. Each node
uses this to show integrity of its data. Node receiving correct message overwrites this bit
in original received message with dominate bit as mentioned above to indicate error free
message has been transmitted. The node receiving erroneous message leaves this bit as
recessive. Moreover it discards the message and hence prompts the sending node to re-
ACK transmit the message after re-arbitration process.

EOF Stands for End of Frame. It is 7 bits in size. It marks end of CAN frame or message.

stands for Interframe space. It is 7 bits in size. It contains time required by controller to
IFS move correctly received frame to its proper position in message buffer area.

Extended CAN Frame format fields

Figure-2 depicts extended CAN frame structure. Following table-2 describes fields used in
extended CAN frame format. It uses 29 bit identifier.

Fields Description

It stands for Substitute Remote Request. This bit replaces RTR bit of standard CAN message
SRR location as placeholder in this extended CAN format.
It functions as recessive bit in identifier extension. It indicates that more identifier bits are
IDE followed. 18 bit extension follows IDE.

r1 It is additional reserved bit for future use

Arbitration
It is a mechanism which resolves the conflict when two or more nodes try to send the message at

the same time. In this technique whenever the bus is free any unit can transmit a message. If two
or more units starts transmitting at the same time access to the bus is conflicted, but this problem
can be solved by arbitration using identifier. During arbitration every transmitter compares the
value of transmitted bit with bit value on the bus. If the bit value is same, the node continues to
send the bits. But at any time if transmitted bit value is different from bus value the dominant bit
overwrites the recessive bits.

 High Speed CAN offers baud rates from 40 Kbit/s to 1 Mbit/sec, depending on cable
length. This is the most popular standard for the physical layer, since it allows for simple
cable connection between devices. This is the physical standard used in the DeviceNet
and CANopen specifications. High speed CAN networks are terminated with
120 ohm resistors on each end of the network.

 Low Speed/Fault Tolerant CAN offers baud rates from 40 Kbit/s to 125 Kbits/sec. This
standard allows CAN bus communication to continue in case of a wiring failure on the
CAN bus lines. In low speed/fault tolerant CAN networks, each device has its own
termination.

CAN Nodes Allocation


Nd1 – Controls all rear lighting loads
Nd2 – Controls electric windows
Nd3 – Controls the windscreen wipers.
Nd4 – Controls all front lighting loads

You might also like