OVERVIEW
CAN was originally developed by the German company, Robert Bosch, for use in cars, to provide a cost-effective communications bus for in-car electronics and as alternative to expensive, cumbersome and unreliable wiring looms and connectors. The car industry continues to use CAN for an increasing number of applications, but because of its proven reliability and robustness, CAN is now also being used in many other control applications. Intra-vehicular communication:
A typical vehicle has a large number of electronic control systems
The growth of automotive electronics is a result of:Customers wish for better comfort and better safety.Government requirements for improved emission controlReduced fuel consumption
Some of such control systemsEngine timingGearbox and carburetor throttle controlAnti-block systems (ABS)Acceleration skid control (ASC)
The complexity of the functions implemented by these electronic control systems necessitates communication between them.In addition, a number of systems are being developed which will cover more than one device. For exampleASC requires the interplay of the engine timing and carburetor control in order to reduce torque when drive wheel slippage occurs.In the electronic gearbox control, the ease of gear changing can be improved by a brief adjustment to ignition timing
How do we connect these control devices?
With conventional systems, data is exchanged by means of dedicated signal lines.
But this is becoming increasingly difficult and expensive as control functions become ever more complex.
In the case of complex control systems in particular, the number of connections cannot be increased much further.
Solution: Use Field bus networks for connecting the control devices
FIELD BUS NETWORKS
Field buses are communication technologies and products used in vehicular, automation and process control industries.
Proprietary Field busesProprietary Field buses are an intellectual property of a particular company or body.
Open Field busesFor a Field bus to be Open, it must satisfy the following criteria.The full Field bus Specification must be published and available at a reasonable price. Critical ASIC components must be available, also at a reasonable price. Well defined validation process, open to all of the Field bus users.
Field bus Advantages:
I.Reduces the complexity of the control system in terms of hardware outlay.
II.Resulting in the reduced complexity of the control system, project design engineering is made simpler, more efficient and conversely less expensive.
III.By selecting a recognized and well established system, this will make the Fieldbus equipment in you plant or plants interchangeable between suppliers.
IV.The need to be concerned about connections, compatibility and other potential problems is eradicated.
What constitutes a Field bus?The specification of a Field bus should ideally cover all of the seven layers of the OSI model as shown below,.
FEATURES OF CANCAN features are as follows:-
CAN is a robust protocol – essential for automotive applicationsSO 11898 and SAE/J2411 are open standardsWell documented and fully supported worldwideChoice of three CAN physical layer optionsHigh-speed (HS)for high data ratesFault-tolerant (FT)for additional robustnessSingle-wire (SW)for minimum wiringAny node can access the bus when the bus is quiet.Non- destructive bit-wise arbitration to allow 100% use of bandwidth without loss of data.Variable message priority based on 11-bit (or 29 bit) packet identifier.Peer- to-Peer and multi-cast receptionAutomatic error detection, signaling and retries.Data packets 8 bytes long
BENEFITS OF CAN
Can is a fast serial Bus that designed to provide An efficientReliable and Very economical link between sensors & actuatorsCan uses a twisted pair cables to communicate at speed up to 1 Mbit/s up to 40 devices.Originally CAN is developed to simplify the wiring in automobiles.CAN field buses are now used in machine and factory automation products as well.
CAN History
In the early 1980s, engineers at Bosch were evaluating existing serial bus systems regarding their possible use in passenger cars. Because none of the available network protocols were able to fulfill the requirements of the automotive engineers, Uwe Kiencke started the development of a new serial bus system in 1983.
The new bus protocol was mainly supposed to add new functionality – the reduction of wiring harnesses was just a by-product, but not the driving force behind the development of CAN. Engineers from Mercedes-Benz got involved early on in the specification phase of the new serial bus system, and so did Intel as the potential main semiconductor vendor. Professor Dr. Wolfhard Lawrenz from the University of Applied Science in Braunschweig-Wolfenbüttel, Germany, who had been hired as a consultant, gave the new network protocol the name ‘Controller Area Network’. Professor Dr. Horst Wettstein from the University of Karlsruhe also provided academic assistance. In February of 1986, CAN was born: at the SAE congress in Detroit, the new bus system developed by Bosch was introduced as ‘Automotive Serial Controller Area Network’. Uwe Kiencke, Siegfried Dais and Martin Litschel introduced the multi-master network protocol. It was based on a non-destructive arbitration mechanism, which would grant bus access to the message with the highest priority without any delays.
There was no central bus master. Furthermore, the fathers of CAN – the individuals mentioned above plus Bosch employees Wolfgang Borst, Wolfgang Botzenhard, Otto Karl, Helmut Schilling, and Jan Unruh – had implemented several error detection mechanisms. The error handling also included the automatic disconnection of faulty bus nodes in order to keep up the communication between the remaining nodes. The transmitted messages were not identified by the node address of the transmitter or the receiver of the message (as in almost all other bus systems), but rather by their content. The identifier representing the content of the message also had the function of specifying the priority of the message within the system.
A lot of presentations and publications describing this innovative communication protocol followed, until in mid 1987 – two months ahead of schedule – Intel delivered the first CAN controller chip, the 82526.
It was the very first hardware implementation of the CAN protocol. In only four years, an idea had become reality. Shortly thereafter, Philips Semiconductors introduced the 82C200. These two earliest ancestors of the CAN controllers were quite different concerning acceptance filtering and message handling. On one hand, the FullCAN concept favored by Intel required less CPU load from the connected micro-controller than the BasicCAN implementation chosen by Philips. On the other hand, the FullCAN device was limited regarding the number of messages that could be received. The BasicCAN controller also required less silicon. In today’s CAN controllers, the ‘grandchildren’, very often different concepts of acceptance filtering and message handling have been implemented in the same module, making the misleading terms BasicCAN and FullCAN obsolete.
IMPLEMENTATION OF CAN
Communication is identical for all implementations of CAN. However, there are two principal hardware implementations. The two implementations are known as Basic CAN and Full CAN.
Basic CAN In Basic CAN configurations there is a tight link between the CAN controller and the associated microcontroller. The microcontroller, which will have other system related functions to administer, will be interrupted to deal with every CAN message.
Full CANFull CAN devices contain additional hardware to provide a message "server" that automatically receives and transmits CAN messages without interrupting the associated microcontroller. Full CAN devices carry out extensive acceptance filtering on incoming messages, service simultaneous requests, and generally reduce the load on the microcontroller.
Network SizesThe number of nodes that can exist on a single network is, theoretically, limited only by the number of available identifiers. However, the drive capabilities of currently available devices impose greater restrictions. Depending on the device types, up to 32 or 64 nodes per network is normal, but at least one manufacturer now provides devices that will allow networks of 110 nodes.
HOW CAN WORKS ?
Principle
Data messages transmitted from any node on a CAN bus do not contain addresses of either the transmitting node, or of any intended receiving node.Instead, the content of the message (e.g. Revolutions per Minute, Hopper Full, X-ray Dosage, etc.) is labeled by an identifier that is unique throughout the network. All other nodes on the network receive the message and each performs an acceptance test on the identifier to determine if the message, and thus its content, is relevant to that particular node. If the message is relevant, it will be processed; otherwise it is ignored. The unique identifier also determines the priority of the message. The lower the numerical value of the identifier, the higher the priority. In situations where two or more nodes attempt to transmit at the same time, a non-destructive arbitration technique guarantees that messages are sent in order of priority and that no messages are lost.
Bit encodingCAN use Non Return to Zero (NRZ) encoding (with bit-stuffing) for data communication on a differential two wire bus. The use of NRZ encoding ensures compact messages with a minimum number of transitions and high resilience to external disturbance.
The physical busThe two wire bus is usually a twisted pair (shielded or unshielded). Flat pair (telephone type) cable also performs well but generates more noise itself, and may be more susceptible to external sources of noise.
The CAN protocol is an international standard defined in the ISO 11898. Beside the CAN protocol itself the conformance test for the CAN protocol is defined in the ISO 16845, which guarantees the interchangeability of the CAN chips.
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. 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.
Message formats
CAN distinguishes four message formats: data, remote, error, and overload frames. Here we limit the discussion to the data frame. A data frame begins with the start-of-frame (SOF) bit. It is followed by an eleven-bit identifier and the remote transmission request (RTR) bit. The identifier and the RTR bit form the arbitration field. The control field consists of six bits and indicates how many bytes of data follow in the data field. The data field can be zero to eight bytes. The data field is followed by the cyclic redundancy checksum (CRC) field, which enables the receiver to check if the received bit sequence was corrupted. The two-bit acknowledgment (ACK) field is used by the transmitter to receive an acknowledgment of a valid frame from any receiver.
The end of a message frame is signalled through a seven-bit end-offrame (EOF). There is also an extended data frame with a twenty-nine-bit identifier (instead of eleven bits).The CAN protocol was internationally standardized in 1993 as ISO 11898-1. The development of CAN was mainly motivated by the need for new functionality, but it also reduced the need for wiring. The use of CAN in the automotive industry has caused mass production of CAN controllers. Today, CAN controllers are integrated on many microcontrollers and available at a low cost.
CAN ARCHITECTURE
Any node can access the bus when the bus is quiet
Non-destructive bit-wise arbitration to allow 100% use of the bandwidth without loss of data
Variable message priority based on 11-bit (or 29 bit) packet identifier
Peer-to-peer and multi-cast reception
Automatic error detection, signalling and retries
Data packets 8 bytes long
ERROR HANDLING PERFORMANCE OF CAN
Error detection and error handling are important for the performance of CAN. Because of complementary error detection mechanisms, the probability of having an undetected error is very small. Error detection is done in five different Vehicle Applications of Controller Area Network 7 ways in CAN: bit monitoring and bit stuffing, as well as frame check, ACK check, and CRC. Bit monitoring simply means that each transmitter monitors the bus level, and signals a bit error if the level does not agree with the transmitted signal. (Bit monitoring is not done during the arbitration phase.)
After having transmitted five identical bits, a node will always transmit the opposite bit. This extra bit is neglected by the receiver. The procedure is called bit stuffing, and it can be used to detect errors. The frame check consists of checking that the fixed bits of the frame have the values they are supposed to have, e.g., EOF consists of seven recessive bits. During the ACK in the message frame, all receivers are supposed to send a dominant level. If the transmitter, which transmits a recessive level, does not detect the dominant level, then an error is signalled by the ACK check mechanism.
Finally, the CRC is that every receiver calculates a checksum based on the message and compares it with the CRC field of the message. Every receiver node obviously tries to detect errors within each message. If an error is detected, it leads to an immediate and automatic retransmission of the incorrect message. In comparison to other network protocols, this mechanism leads to high data integrity and a short error recovery time. CAN thus provides elaborate procedure for error handling, including retransmission and reinitialization. The procedures have to be studied carefully for each application to ensure that the automated error handling is in line with the system requirements.
APPLICATIONS
CAN networks can be used as an embedded communication system for microcontrollers as well as an open communication system for intelligent devices. The CAN serial bus system, originally developed for use in automobiles, is increasingly being used in industrial field bus systems, the similarities are remarkable. In both cases some of the major requirements are: low cost, the ability to function in a difficult electrical environment, a high degree of real-time capability and ease of use.Some users, for example in the field of medical engineering, opted for CAN because they have to meet particularly stringent safety requirements.
Similar problems are faced by manufacturers of other equipment with very high safety or reliability requirements (e. g. robots, lifts and transportation systems). CAN controllers and interface chips are physically small. They are available as low-cost, off-the-shelf components. They will operate at high, real-time speeds, and in harsh environments. All these properties have led to CAN also being used in a wide range of applications other than the car industry. The benefits of reduced cost and improved reliability that the car industry gains by using CAN are now available to manufacturers of a wide range of products.
For example:
• Marine control and navigation systems
•Elevator control systems
• Agricultural machinery
• Production line control systems
• Machine tools
• large optical telescopes
• Photo copiers
• Medical systems
• Paper making and processing machinery
VEHICLE APPLICATIONS OF CAN
The Controller Area Network (CAN) is a serial bus communications protocol developed by Bosch in the early 1980s. It defines a standard for efficient and reliable communication between sensor, actuator, controller, and other nodes in real-time applications. CAN is the de facto standard in a large variety of networked embedded control systems.
The early CAN development was mainly supported by the vehicle industry: CAN is found in a variety of passenger cars, trucks, boats, spacecraft, and other types of vehicles. The protocol is also widely used today in industrial automation and other areas of networked embedded control, with applications in diverse products such as production machinery, medical equipment, building automation, weaving machines & wheelchairs.In the automotive industry, embedded control has grown from stand-alone systems to highly integrated and networked control systems. By networking electro-mechanical subsystems, it becomes possible to modularize functionalities and hardware, which facilitates reuse and adds capabilities. Fig. 1 shows an example of an electronic control unit (ECU) mounted on a diesel engine of a Scania truck. The ECU handles the control of engine, turbofan, etc. but also the CAN communication. Combining networks and mechatronic modules makes it possible to reduce both the cabling and the number. The work of K. H. Johansson was partially supported by the European Commission through the ARTIST2 Network of Excellence on Embedded Systems Design, by the Swedish Research Council, and by the Swedish Foundation for Strategic Research through an Individual Grant for the Advancement of Research Leaders.
The work of M. T¨orngren was partially supported by the European Commission through ARTIST2 and by the Swedish Foundation for Strategic Research through the project SAVE of connectors, which facilitates production and increases reliability. Introducing networks in vehicles also makes it possible to more efficiently carry out diagnostics and to coordinate the operation of the separate subsystems.
Heavy Vehicles
Most existing vehicle model libraries are designed primarily for cars. Heavy vehicles have a number of sub-systems which are not present in passenger cars. Particularly the engine/transmission system includes de-vices like an exhaust brake and possibly a retarder. Further, the cooling system also has a more prominent role than in cars, and coolant is often used both by the engine and the transmission.
Signalling Bus
A key issue in an architecture which contains both physical plant and controller models is the handling of electrical signals. The controllers need to exchange data among themselves and they need to exchange signals with sensors and actuators. For our applications the actual signalling behaviour is not that important, an ideal communications model is sufficient. For the communication between a plant and its controller, standard library in-ports and out-ports are used. The communication between the controllers was a tougher case. Two implementations of the same controller may not have the same signalling needs, thus it must be possible to change the set of signals sent between control units. Separate input and output ports for all links between control units in the vehicle would create an un-decipherable graphical mess. Some type of signalling bus is needed. Both the standard library bus connectors and the type of bus used in the vehicle modelling architecture proposal by Tiller Etal were evaluated. We did not find enough information about the inter-controller communication in the Tiller paper to implement that system. Our main problem was to find a way of having compatible connectors in all controllers, without modifying the code of every controller when a signal was added to the bus. The standard library bus does not solve that problem, since it requires all signals to be declared in the connector. Eventually we chose a simpler solution based on a common connector called ”CAN” with a replace-able variable, called ”protocol”, which contains all the signals. The protocol variable can easily be redeclared into a type which contains exactly the signals broad-cast on the bus in a particular model. Different implementations of the CAN connector are used for different signal buses in the vehicle.
Most of our control units are implemented through external function calls, thus the drawback of having no convenient graphical way of converting a signal from inport/ outport to bus format is minor.
