Advanced Communication Protocols In Automobiles - Seminar Report

  INTRODUCTION

The last decade has seen a resurgence of advanced technologies being implemented in automobiles. Functions that were considered highly complex and difficult to be implemented are not only being provided but various other facilities are also being built on those very functions. Everything from engine control to multimedia and infotainment services are implemented in today’s automobiles. This has been due largely to the strides made by the electronics as well as the communications industry. The emergence of the concept of providing the customer with all possible services has led to an explosion of implementation of high-end electronics, each providing a facility of its own. When so many devices are being embedded in a car, there also has to be a mechanism that should regulate the way in which data transfer takes place. It is the objective of this paper to provide an insight into most of the communication protocols that are being used, as well as technologies that are under development in the automobile industry of today.

           The modern-day automobile was not built in a day. It took years and thousands of patents to build it. This has been an industry that has seen rapid growth in terms of its technical as well as its aesthetic aspects. The car building effort has also been receptive to growth in other industries recently, most prominent among them the electronics industry. Until a decade ago, the automobile industry suffered from a conservative approach towards computer-controlled processes. However, rapid strides made by the electronics industry made it possible to to manufacture smarter devices.

With the necessity of wiring the electronic devices together comes the issue of data management. This task is accomplished by a set of rules known as protocols. These protocols govern the way in which data is communicated from one electronic device to the other. Examples of such protocols are x-by-wire, MOST, CAN, TTCAN, SAE J1850, and Bluetooth. A noted exception here is Bluetooth, which is a wireless protocol.

The advantage of using these protocols is that the task of communication between the devices is centralized (i.e. the task is handled by a central control unit). Thus, all the devices are networked together. The implementation of these networks not only solves the problems of traditional wiring systems, it also provides scalability; it leaves open opportunities for adding new components in the future without any major changes to the network. To implement these networks in the safety critical systems of a car will take some time, because a failure of these networks might result in loss of human life, a matter of very grave concern. Such networks are, however, already in use in many places in a car, such as multimedia, doors, seat adjustments, and trunk release.

LITERATURE SURVEY 

RISC Features

The ARM architecture includes the following RISC features:

• Load/store architecture.
• No support for misaligned memory accesses (now supported in ARMv6 cores, with some exceptions related to load/store multiple word instructions).
• Uniform 16 × 32-bit register file.
• Fixed instruction width of 32 bits to ease decoding and pipelining, at the cost of decreased code density. Later, "the Thumb instruction set" increased code density.
• Mostly single-cycle execution.
• Conditional execution of most instructions, reducing branch overhead and compensating for the lack of a branch predictor.
• Arithmetic instructions alter condition codes only when desired.
• 32-bit barrel shifter which can be used without performance penalty with most arithmetic instructions and address calculations.
• Powerful indexed addressing modes.
• A link register for fast leaf function calls.
• Simple, but fast, 2-priority-level interrupt subsystem with switched register banks.

 Comparison of RISC and CISC processors

Sr.No.	R.I.S.C.	C.I.S.C.
1.	RISC stands for Reduced Instruction Set Computer.	CISC stands for Complex Instruction Set Computer.
2.	It executes simple instruction sets in a Single cycle per instruction sets.	It process arithmetic, logic & complex data sets using fewer register.
3.	It performs operations slowly as compare to CISC.	It performs operations faster than RISC.
4.	RISC is costly than CISC	CISC is cheaper
5.	Very few processors are based on RISC architecture.	Most of processors are based on the CISC architecture.

 ARM Processor

ARM is one of the most licensed and thus widespread processor cores in the world. Used especially in portable devices due to low power consumption and reasonable performance (MIPS / watt). Several interesting extensions available or in development like Thumb instruction set and Jazelle Java machine. Extension enables simpler and significantly cheaper realization of processor system. Instructions take only half of memory than with 32-bit instruction set without significant decrease in performance or increase in code size. Extension is made instruction decoder at the processor pipeline.

    ARM Features

1.      It has 2-bit architecture but also supports 16-bit or 8-bit data types.

2.      ARM is programmable as little endian or big endian data.

3.      ARM provides the advantage of using a CISC in terms of functionality, along with the advantage of an RISC in terms of faster program implementation as well as reduced instruction set.

4.      ARM7 and ARM9 microprocessors have combination of RISC and CISC features.

5.      ARM7 has Princeton memory architecture and ARM9 has Harvard architecture.

6.      Arm debug and trace tools quickly debug real-time software, and trace instruction execution.

7.      ARM permits programming by and additional instruction set designed for 16-bit operations.

8.      ARM uses an Intelligent Energy Manager (IEM) Technology.

9.      ARM processors use the AHB (AMBA Advanced High Performance Bus) interface.

Modes of Operation

• User (usr): Normal program execution state

• FIQ (fiq): Data transfer state (fast irq, DMA-type transfer)

• IRQ (iqr): Used for general interrupt services

• Supervisor (svc): Protected mode for operating system support

• Abort mode (abt): Selected when data or instruction fetch is aborted

• System (sys): Operating system ‘privilege’-mode for user

Register Set

• Register structure depends on mode of operation

• 16 pieces of 32-bit integer registers R0 - R15 are available in ARM-mode ( user)

• R0 - R12 are general purpose registers

• R13 is Stack Pointer (SP)

• R14 is subroutine Link Register

• Holds the value of R15 when BL-instruction is executed

• R15 is Program Counter (PC)

• Bits 1 and 0 are zeroes in ARM-state (32-bit addressing)

• R16 is state register (CPSR, Current Program Status Register)

Protocols

Protocol may refer to: Standards in information automation

Protocol is a formal description of digital message formats and the rules for exchanging those messages in or between computing systems and in telecommunications. Protocols may include signaling, authentication and error detection and correction capabilities. A protocol describes the syntax, semantics, and synchronization of communication and may be implemented in hardware or software, or both. The protocols in human communication are rules about appearance, speaking, listening and understanding. These rules, also called protocols of conversation, represent different layers of communication. They work together to help people communicate successfully. The need for protocols also applies to computing systems. Network engineers have written rules for communication that must be strictly followed for successful host-to-host communication. These rules apply to different layers of sophistication such as which physical connections to use, how hosts listen, how to interrupt, how to terminate communications, which language to use and many others. These rules, or protocols, that work together to ensure successful communication are grouped into what is known as a protocol suite or family. Some of the best known protocol suites include: IPX/SPX, X.25, AX.25, AppleTalk and TCP/IP.

Protocol Design

The design of the protocol software belongs to the discipline of 'concurrent systems design'. Communicating systems operate in parallel. The programming tools and techniques for dealing with parallel processes are collectively called concurrent programming. Concurrent programming has traditionally been a topic in operating systems theory texts. A mathematical approach to the study of concurrency and communication is referred to as Communicating Sequential Processes. Concurrency can also be modeled using finite state machines like Mealy- and Moore Machines.This kind of design can be a bit of a challenge to say the least, so it is important to keep things simple. For the Internet protocols, in particular and in retrospect, this meant a basis for protocol design was needed to allow decomposition of protocols into much simpler, cooperating protocols. Systems do not use a single protocol to handle a transmission. Instead they use a set of cooperating protocols, sometimes called a protocol family or protocol suite. To cooperate the protocols have to communicate with each other, so some kind of conceptual framework is needed to make this communication possible. Also note that software is needed to implement both the 'transfer-mechanism' and a protocol (no protocol, no communication). In programming languages the association of identifiers to a value is termed a definition. Program text is structured using block constructs and definitions can be local to a block. The localized association of an identifier to a value established by a definition is termed a binding and the region of program text in which a binding is effective is known as its scope. The computational state is kept using two components: the environment, used as a record of identifier bindings, and the store, which is used as a record of the effects of assignments. 

In communications, message values are transferred using transmission media. By analogy, the equivalent of a store would be a collection of transmission media, instead of a collection of memory locations. A valid assignment in a protocol (as an analogon of programming language) could be Ethernet:=‘message’, meaning a message is to be broadcast on the local ethernet. On a transmission medium there can be many receivers. For instance a Mac-address identifies an ether network card on the transmission medium (the 'ether'). In our imaginary protocol, the assignment ethernet [Mac-address]:=message value could therefore make sense. Programming like this would require knowledge about the hardware, like the details of the Ethernet frame format, network access policy, and frame error handling. Such a protocol is called a low-level protocol. The Internet Protocol specifies higher level abstractions like IP addressing, datagram format, and the concept of unreliable, connectionless delivery, and is therefore called a high-level protocol.

Strictly adhering to a layered model, a practice known as strict layering, is not always the best approach to networking. Strict layering can have a serious impact on the performance of the implementation, so there is at least a trade-off between simplicity and performance. Another, perhaps more important point can be shown by considering the fact that some of the protocols in the Internet Protocol Suite cannot be expressed using the TCP/IP model, in other words some of the protocols behave in ways not described by the model. To improve on the model, an offending protocol could, perhaps be split up into two protocols, at the cost of one or two extra layers, but there is a hidden caveat, because the model is also used to provide a conceptual view on the suite for the intended users. There is a trade-off to be made here between preciseness for the designer and clarity for the intended user. 

Protocol Development

For communication to take place, protocols have to be agreed upon. Recall that in digital computing systems, the rules can be expressed by algorithms and data structures, raising the opportunity of hardware independency. Expressing the algorithms in a portable programming language, makes the protocol software operating system independent. The source code could be considered a protocol specification. This form of specification however is not suitable for the parties involved. For one thing, this would enforce a source on all parties and for another, proprietary software producers would not accept this. By describing the software interfaces of the modules on paper and agreeing on the interfaces, implementers are free to do it their way. This is referred to as source independency. By specifying the algorithms on paper, development continues to become a standard. It should be noted though that in some cases protocol standards are not sufficient to gain wide-spread acceptance i.e. sometimes the source code needs to be disclosed enforced by law or the government.

Protocol Testing

In general, protocol testers or protocol analyzers work by capturing the information exchanged between a device under test (DUT) and a reference device known to operate properly. In the example of a manufacturer producing a new keyboard for a personal computer, the DUT would be the keyboard and the reference device, the PC. Protocol testing is an essential step towards commercialization of standards-based products. It helps to ensure that products from different manufacturers will interoperate.

Conventional Networking in Automotives

CAN Protocol

The Bosch CAN specification (version 2.0) was submitted for international standardization in the early 1990s. After several political disputes, especially involving the ‘Vehicle Area Network’ (VAN) developed by some major French car manufacturers, the ISO standard 11898 for CAN was published in November of 1993. In addition to the CAN protocol, it also defined a physical layer for baud rates up to 1 Mbit/s. In parallel, a fault-tolerant way of data transmission via CAN was standardized in ISO 11519-2. In 1995, the ISO 11898 standard was extended by an addendum describing the 29-bit CAN identifier. Unfortunately, all published CAN specifications and standardizations contained errors or were incomplete. To avoid incompatible CAN implementations, Bosch made sure (and still does) that all CAN chips comply with the Bosch CAN reference model. Furthermore, the University of Applied Science in Braunschweig/Wolfenbüttel, Germany, has been conducting CAN conformity testing for several years, lead by Prof. Lawrenz. The test patterns used are based on the internationally standardized test specification ISO 16845. Revised CAN specifications have been standardized. ISO 11898-1 describes the ‘CAN data link layer’, ISO 11898-2 defines the ‘Non-fault-tolerant’ CAN physical layer’, and ISO 11898-3 specifies the ‘Fault-tolerant CAN physical layer’. ISO standards 11992 (truck and trailer interface) and 11783 (agriculture and forestry machines) both define CAN-based application profiles based on the US-protocol J1939, however they are not compatible.

CAN Architecture

The CAN protocol is based on the principle of broadcast transmission technique. It is basically a communication technique in which data to be transmitted on a network is sent to all the nodes including the one to which the data is intended. The nodes look inside the data packet to see if the message was meant for them. If not they simply discard the packet. The node to which the data was intended then downloads the data and processes it . Some of the features that have made CAN so popular are speed, data length, and event-triggered mechanism. The speed of data transmission in a CAN network can go up to 1 Mbps. This is very helpful in real-time control systems that can afford very low latency. Thus, due to the high speed offered by CAN, low latency and, hence, time-efficient control can be achieved. CAN frames are also short in length, owing to which there is minimal delay in the reception of messages. CAN is basically an event-triggered mechanism. This means that the transmission of data is prompted only when a specific event occurs. For example, data transmission might take place when a button is pressed or a lever pulled. Owing to this property, the bandwidth available is made maximum use of because of the minimum load put on the bus system. The combination of high speed and short message length results, therefore, in a low delay, owing to which CAN can be implemented in control systems that have a very low tolerance for delays. The addressing system is based on message identifiers rather than physical addresses for nodes. Every CAN message has a unique identifier that assigns a priority to the respective message based on the binary value of the identifier. A lower binary value is assigned a higher priority and vice versa. Any node wishing to transmit sends the message to the CAN controller, which in turn broadcasts the message. All the other nodes then get ready to receive and the nodes that have no use for the message discard the message.

A basic CAN protocol consists of three layers: physical layer, data-link layer, and application layer. The data-link layer (DLL) is implemented in an electronic component known as the CAN-controller. Several semiconductor manufacturers, such as Intel, Motorola, and Philips, make it. The CAN controller consists of the following: CPU interface logic (CIL), which handles the data transfer on the bus; bit stream processor (BSP), which handles the streaming of data between buffer and bus line; error management logic ( EML), which is involved with error management; bit timing logic (BTL), which is responsible for the synchronization of bit streams; transceiver control logic ( TCL), which handles error detection and correction, transmission, and reception of the data and arbitration; and message buffer memory (MBM ), which is used to store messages for future transmission. Recently, a variation of the CAN protocol, called the CANopen, has been developed. There are many ways in which CAN can be implemented in automobiles. For our case, we shall consider the various ways in which the Jaguar Car Company has implemented CAN in its XK8 sports car. The applications in this car are the engine control module (ECM), antilock braking system (ABS), transmission control module ( TCM ), instruments and driver information module ( INST ), J-gate illumination module (JGM ), and inter suspension data transfer system. Data access points are specially ear-marked from where data has to be collected. Appropriate sensors are wired to these data access points, which are in turn wired to microprocessors that perform adequate data processing. The data is then placed on the CAN bus along with the medium access control mechanism. The data is then sent to the CAN controller for control mechanisms to be implemented. In a more generalized manner, CAN can be used to network body control modules and infotainment networks. Details cannot be released as these are proprietary technologies.

CAN in Automotives

In automobiles, the dash boards has many measuring units, such as Pressure gauge, Temperature gauge with numerous cables for inter-connection, which leads to cable complexity, the physical length of cables and other defects in communication.

To overcome those problems, the CAN Protocol based multiplexed system is proven for the reliability and real-time performance of the data transmitted on CAN bus is appropriate to all Vehicular Automotive applications. CAN provides the cost-effective communication network of in-vehicle electronics as an alternative to the expensive and cumbersome wiring looms. CAN conform to the open systems intercommunication model which is defined in terms of physical layers. A message transmitted in CAN has an identifier, or arbitration, which is unique to the network system and serves two purposes: a priority assignment for the transmission and message filter upon reception. In other words, it controls both bus arbitration and message addressing. CAN is a broadcast communication with priority-based access to the medium. Its communication protocol has become a data transmission standard in automotive applications. This protocol implements a priority-based bus with a carrier sense multiple access with collision avoidance (CSMA/CA) to control access to the bus. Nowadays, CAN is widely used not only for vehicles but for diverse areas of different industrial applications such as agricultural machinery, medical instrumentation, elevator controls, fairground rides, public transportation systems, industrial automation, home automation, real-time remote control, etc. It is standardized as ISO 11898 for high-speed applications (1Mbps) and ISO 11519-2 for low-speed applications (125Kbps).

            A modern automobile may have as many as 70 electronic control units (ECU) for various subsystems. Typically the biggest processor is the engine control unit, which is also referred to as "ECU" in the context of automobiles; others are used for transmission, airbags, antilock braking, cruise control, audio systems, windows, doors, mirror adjustment, etc. Some of these form independent subsystems, but communications among others are essential. A subsystem may need to control actuators or receive feedback from sensors. The CAN standard was devised to fill this need. The CAN bus may be used in vehicles to connect engine control unit and transmission, or (on a different bus) to connect the door locks, climate control, seat control, etc. Today the CAN bus is also used as a field bus in general automation environments, primarily due to the low cost of some CAN Controllers and processors. Bosch holds patents on the technology, and manufacturers of CAN-compatible microprocessors pay license fees to Bosch, which are normally passed on to the customer in the price of the chip. Manufacturers of products with custom ASICs or FPGAs containing CAN-compatible modules may need to pay a fee for the CAN Protocol License.

CAN is a multi-master broadcast serial bus standard for connecting electronic control units (ECUs). Each node is able to send and receive messages, but not simultaneously. A message consists primarily of an ID — usually chosen to identify the message-type or sender — and up to eight data bytes. It is transmitted serially onto the bus. This signal pattern is encoded in NRZ and is sensed by all nodes. The devices that are connected by a CAN network are typically sensors, actuators, and other control devices. These devices are not connected directly to the bus, but through a host processor and a CAN controller. If the bus is free, any node may begin to transmit. If two or more nodes begin sending messages at the same time, the message with the more dominant ID (which has more dominant bits, i.e., zeroes) will overwrite other nodes' less dominant IDs, so that eventually (after this arbitration on the ID) only the dominant message remains and is received by all nodes.

 System Features and Design

System Architecture 

·         Host processor

• The host processor decides what received messages mean and which messages it wants to transmit itself.
• Sensors, actuators and control devices can be connected to the host processor.
• CAN controller (hardware with a synchronous clock).
• Receiving: the CAN controller stores received bits serially from the bus until an entire message is available, which can then be fetched by the host processor (usually after the CAN controller has triggered an interrupt).
• Sending: the host processor stores its transmit messages to a CAN controller, which transmits the bits serially onto the bus.
• Transceiver (possibly integrated into the CAN controller)
• Receiving: it adapts signal levels from the bus to levels that the CAN controller expects and has protective circuitry that protects the CAN controller.
• Sending: it converts the transmit-bit signal received from the CAN controller into a signal that is sent onto the bus.

Bit rates up to 1 Mbit/s are possible at network lengths below 40 m. Decreasing the bit rate allows longer network distances (e.g., 500 m at 125 Kbit/s). The CAN data link layer protocol is standardized in ISO 11898-1 (2003). This standard describes mainly the data link layer — composed of the logical link control (LLC) sub layer and the media access control (MAC) sub layer — and some aspects of the physical layer of the OSI reference model. All the other protocol layers are the network designer's choice.

Data transmission

CAN features an automatic 'arbitration free' transmission. A CAN message that is transmitted with highest priority will 'win' the arbitration, and the node transmitting the lower priority message will sense this and back off and wait. This is achieved by CAN transmitting data through a binary model of "dominant" bits and "recessive" bits where dominant is a logical 0 and recessive is a logical 1. This means open collector, or 'wired or' physical implementation of the bus (but since dominant is 0 this is sometimes referred to as wired-AND). If one node transmits a dominant bit and another node transmits a recessive bit then the dominant bit "wins" (a logical AND between the two). So, if you are transmitting a recessive bit, and someone sends a dominant bit, you see a dominant bit, and you know there was a collision. (All other collisions are invisible.) A dominant bit is asserted by creating a voltage across the wires while a recessive bit is simply not asserted on the bus. If any node sets a voltage difference, all nodes will see it. Thus there is no delay to the higher priority messages, and the node transmitting the lower priority message automatically attempts to re-transmit 6 bit clocks after the end of the dominant message. When used with a differential bus, a Carrier Sense Multiple Access/Bitwise Arbitration (CSMA/BA) scheme is often implemented: if two or more devices start transmitting at the same time, there is a priority based arbitration scheme to decide which one will be granted permission to continue transmitting. The CAN solution to this is prioritized arbitration (and for the dominant message delay free), making CAN very suitable for real time prioritized communications systems.

During arbitration, each transmitting node monitors the bus state and compares the received bit with the transmitted bit. If a dominant bit is received when a recessive bit is transmitted then the node stops transmitting (i.e., it lost arbitration). Arbitration is performed during the transmission of the identifier field. Each node starting to transmit at the same time sends an ID with dominant as binary 0, starting from the high bit. As soon as their ID is a larger number (lower priority) they'll be sending 1 (recessive) and see 0 (dominant), so they back off. At the end of ID transmission, all nodes but one have backed off, and the highest priority message gets through unimpeded. For example, consider an 11-bit ID CAN network, with two nodes with ID's of 15 (binary representation, 00000001111) and 16 (binary representation 00000010000). If these two nodes transmit at the same time, each will transmit the first 6 zeros of their ID with no arbitration decision being made. When the 7th bit is transmitted, the node with the ID of 16 transmit 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 will realize that it lost its arbitration, and allow the node with ID of 15 to continue its transmission. This ensures that the node with the lower bit value will always win the arbitration. The ID with the smaller number will win the right to use.

Bit timing

Each node in a CAN network has its own clock, and no clock is sent during data transmission. Synchronization is done by dividing each bit of the frame into a number of segments: Synchronization, Propagation, Phase 1 and Phase 2. The Length of each phase segment can be adjusted based on network and node conditions. The sample point falls between Phase Buffer Segment 1 and Phase Buffer Segment 2, which helps facilitate continuous synchronization. Continuous synchronization in turn enables the receiver to be able to properly read the messages.

Layers

Based on levels of abstraction, the structure of the CAN protocol can be described in terms of the following layers:

• Application Layer
• Object Layer
• Message Filtering
• Message and Status Handling
• Transfer Layer
  The Transfer Layer represents the kernel of the CAN protocol. It presents messages received to the object layer and accepts messages to be transmitted from the object layer. The transfer layer is responsible for bit timing and synchronization, message framing, arbitration, acknowledgment, error detection and signaling, and fault confinement. It performs:
• Fault Confinement
• Error Detection
• Message Validation
• Acknowledgment
• Arbitration
• Message Framing
• Transfer Rate and Timing
• Information Routing
• Physical Layer
  The physical layer defines how the signals are actually transmitted. Tasks include:
• Signal Level and Bit Representation
• Transmission Medium

Frames

A CAN network can be configured to work with two different message (or "frame") formats: the standard or base frame format (or CAN 2.0 A), and the extended frame format (or CAN 2.0 B). The only difference between the two formats is that the “CAN base frame” supports a length of 11 bits for the identifier, and the “CAN extended frame” supports a length of 29 bits for the identifier, made up of the 11-bit identifier (“base identifier”) and an 18-bit extension (“identifier extension”). The distinction between CAN base frame format and CAN extended frame format is made by using the IDE bit, which is transmitted as dominant in case of an 11-bit frame, and transmitted as recessive in case of a 29-bit frame. CAN controllers that support extended frame format messages are also able to send and receive messages in CAN base frame format. All frames begin with a start-of-frame (SOF) bit that denotes the start of the frame transmission.

CAN has four frame types:

• Data frame: a frame containing node data for transmission
• Remote frame: a frame requesting the transmission of a specific identifier
• Error frame: a frame transmitted by any node detecting an error
• Overload frame: a frame to inject a delay between data and/or remote frame

Data frame

The data frame is the only frame for actual data transmission. There are two message formats:

• Base frame format: with 11 identifier bits
• Extended frame format: with 29 identifier bits

The CAN standard requires the implementation must accept the base frame format and may accept the extended frame format, but must tolerate the extended frame format.

The two identifier fields (A & B) combine to form a 29-bit identifier.

* It is physically possible for a value between 9-15 to be transmitted in the 4-bit DLC, although the data is still limited to 8 bytes. Certain controllers allow the transmission and/or reception of a DLC greater than 8, but the actual data length is always limited to 8 bytes.

 

Remote frame

• Generally data transmission is performed on an autonomous basis with the data source node (e.g. a sensor) sending out a Data Frame. It is also possible, however, for a destination node to request the data from the source by sending a Remote Frame.
• There are 2 differences between a Data Frame and a Remote Frame. Firstly the RTR-bit is transmitted as a dominant bit in the Data Frame and secondly in the Remote Frame there is no Data Field.

RTR = 0 ; DOMINANT in data frame

RTR = 1 ; RECESSIVE in remote frame

In the very unlikely event of a Data Frame and a Remote Frame with the same identifier being transmitted at the same time, the Data Frame wins arbitration due to the dominant RTR bit following the identifier. In this way, the node that transmitted the Remote Frame receives the desired data immediately.

 Error frame

Error frame consists of two different fields .The first field is given by the superposition of ERROR FLAGS (6-12 dominant/recessive bits) contributed from different stations. The following second field is the ERROR DELIMITER (8 recessive bits).

 

Overload frame

The overload frame contains the two bit fields Overload Flag and Overload Delimiter. There are two kinds of overload conditions that can lead to the transmission of an overload flag:

1. The internal conditions of a receiver, which requires a delay of the next data frame or remote frame.
2. Detection of a dominant bit during intermission.

The start of an overload frame due to case 1 is only allowed to be started at the first bit time of an expected intermission, whereas overload frames due to case 2 start one bit after detecting the dominant bit. Overload Flag consists of six dominant bits. The overall form corresponds to that of the active error flag. The overload flag’s form destroys the fixed form of the intermission field. As a consequence, all other stations also detect an overload condition and on their part start transmission of an overload flag. Overload Delimiter consists of eight recessive bits. The overload delimiter is of the same form as the error delimiter.

 Interframe spacing

Data frames and remote frames are separated from preceding frames by a bit field called interframe space. Overload frames and error frames are not preceded by an interframe space and multiple overload frames are not separated by an interframe space. Interframe space contains the bit fields intermission and bus idle and, for error passive stations, which have been transmitter of the previous message, suspend transmission. Interframe space consists of at least three consecutive recessive (1) bits.

Detecting and signaling errors

Unlike other bus systems, the CAN protocol does not use acknowledgement messages but instead signals errors immediately as they occur. For error detection the CAN protocol implements three mechanisms at the message level (data link layer: OSI layer 2):

• Cyclic Redundancy Check (CRC): The CRC safeguards the information in the frame by adding a frame check sequence (FCS) at the transmission end. At the receiver this FCS is re-computed and tested against the received FCS. If they do not match, there has been a CRC error.
• Frame check: This mechanism verifies the structure of the transmitted frame by checking the bit fields against the fixed format and the frame size. Errors detected by frame checks are designated "format errors".
• ACK errors: Receivers of a message acknowledge the received frames. If the transmitter does not receive an acknowledgement an ACK error is indicated.

The CAN protocol also implements two mechanisms for error detection at the bit level (physical layer: OSI layer 1):

• Monitoring: The ability of the transmitter to detect errors is based on the monitoring of bus signals. Each station that transmits also observes the bus level and thus detects differences between the bit sent and the bit received. This permits reliable detection of global errors and errors local to the transmitter.
• Bit stuffing: The coding of the individual bits is tested at bit level. The bit representation used by CAN is "Non Return to Zero (NRZ)" coding. The synchronization edges are generated by means of bit stuffing. That means after five consecutive equal bits the transmitter inserts a stuff bit into the bit stream. This stuff bit has a complementary value, which is removed by the receivers.

If one or more errors are discovered by at least one station using the above mechanisms, the current transmission is aborted by sending an "error frame". This prevents other stations from accepting the message and thus ensures the consistency of data throughout the network. After transmission of an erroneous message that has been aborted, the sender automatically re-attempts transmission (automatic re-transmission). Nodes may again compete for bus access.
However effective and efficient the method described may be, in the event of a defective station it might lead to all messages (including correct ones) being aborted. If no measures for self-monitoring were taken, the bus system would be blocked by this. The CAN protocol therefore provides a mechanism to distinguish sporadic errors from permanent errors and local failures at the station. This is done by statistical assessment of station error situations with the aim of recognizing a station's own defects and possibly entering an operation mode in which the rest of the CAN network is not negatively affected. This may continue as far as the station switching itself off to prevent other nodes' messages erroneously from being recognized as incorrect.

Principles of data exchange

CAN is based on the “broadcast communication mechanism”, which is based on a message-oriented transmission protocol. It defines message contents rather than stations and station addresses. Every message has a message identifier, which is unique within the whole network since it defines content and also the priority of the message. This is important when several stations compete for bus access (bus arbitration).As a result of the content-oriented addressing scheme a high degree of system and configuration flexibility is achieved. It is easy to add stations to an existing CAN network without making any hardware or software modifications to the present stations as long as the new stations are purely receivers. This allows for a modular concept and also permits the reception of multiple data and the synchronization of distributed processes. Also, data transmission is not based on the availability of specific types of stations, which allows simple servicing and upgrading of the network.

Real-time data transmission

In real-time processing the urgency of messages to be exchanged over the network can differ greatly: a rapidly changing dimension, e.g. engine load, has to be transmitted more frequently and therefore with less delays than other dimensions, e.g. engine temperature.
The priority, at which a message is transmitted compared to another less urgent message, is specified by the identifier of each message. The priorities are laid down during system design in the form of corresponding binary values and cannot be changed dynamically. The identifier with the lowest binary number has the highest priority. Bus access conflicts are resolved by bit-wise arbitration of the identifiers involved by each station observing the bus level bit for bit. This happens in accordance with the wired-and-mechanism, by which the dominant state overwrites the recessive state. All those stations (nodes) with recessive transmission and dominant observation lose the competition for bus access. All those "losers" automatically become receivers of the message with the highest priority and do not re-attempt transmission until the bus is available again. Transmission requests are handled in order of their importance for the system as a whole. This proves especially advantageous in overload situations. Since bus access is prioritized on the basis of the messages, it is possible to guarantee low individual latency times in real-time systems. 

Applications

 The Controller Area Network (CAN) serial bus system is used in a broad range of embedded as well as automation control systems. It usually links two or more micro-controller-based physical devices. Many industries have adopted the CAN bus standard, and gained a lot in reliability and flexibility. For some applications, the cost and speed to deploy or reconfigure a communication network is critical such as a factory floor for instance. A CAN bus can be laid out, then equipments can be added thanks to the plug and play capability of CAN with Higher Layer Protocols

CAN in cars and truck engine control

1) Networking controllers for engine timing, transmission, chassis and brakes.

2)Networking components of chassis electronics and electronics which make the vehicle more  

    comfortable.

CAN in maritime applications

1) In maritime electronics CAN networks are used in boats, ships and vessels as embedded  

     network in sub-systems and as integration network connecting several subsystems. Dedicated

     maritime devices with CAN connectivity exist, marine sub-systems with CAN interface as

     well as entirely CAN-based ship automation systems. Ship automation systems may comprise

      several physical CAN networks.

2) A second category of maritime application is fishing industry as well as recreational boat. In

     such application we can find GPS, radar, sonar, fish finder, control dashboard, display plus

     various safety sensors.

CAN in avionics system network

1) CAN is used as a backbone network in aircrafts for flight state sensors, navigation systems and research PCs driving displays installed in the cockpit.

2) Within the aircraft CAN networks are used to analyze in-flight data or together with a voice/video installation to analyze crew assistance provided by the cockpit interfaces.

3) CAN is also used in aerospace applications, e.g. in engine control systems such as fuel systems, pumps and linear actuators.

CAN in medical equipments

1) CAN is used as embedded network in medial devices such as in X-ray machines. Complete operating rooms are equipped with a CAN network that manages all functions.

2)CAN is deployed by the leader in hospital beds connecting the control panels the various motors, the scale. A hospital bed includes 5 to 10 CAN nodes in new generation of beds to be introduced in 2004 in the marketplace.

3) X-ray collimator, X-ray generator and patient table from a market leader use CAN.

4) In addition, complete hospital control systems with voltage control, indication and control units, multi cube power meters and digital I/O, and visualization software are networked via CAN.

CAN in environment research

1) The scientist of the Max-Planck-Institute (MPI) faced a difficult task of measuring and collecting data when they wanted to implement the project “bio diversity”. The project was started in the spring of 2003 in the valley of the Saale-river near Jena, on the grounds equivalent to 13 soccer pitches they planted over 400 meadow allotments and sowed 495 different mixtures of meadow plants

2) Due to the spacious extent a decentralized measuring system was chosen; all communication is done via CANopen. In four independent CAN networks with an overall length of 4,500 m were installed a total of 220 soil temperature sensors, 110 soil water voltage sensors, 25 pressure sensors, 22 sensors for air temperature and humidity as well as 22 surface temperature sensors. Furthermore 25 pumps were needed to regulate the water content of the soil.

Conclusion

Implementation of advanced communication protocols in the automotive and industrial long distance areas will much sophisticated and provides data monitoring with improved efficiency as much as other communication protocols. Proposed system will also overcome existing protocols that don’t support multi-masters and text based communication. In the same way it will be vital in sending information at low baud-rated even at higher distances with good error detection techniques along with efficient management.