Posted by Ozan Devlen On October - 9 - 2008
http://www.writely.org/can-and-lin-bus-systems.html
CAN & LIN Bus Systems
CAN - Controller Area Network
What is CAN?
CAN is a serial bus system especially suited for networking “intelligent” devices as well as sensors and actuators within a system or sub-system.
CAN (Controller Area Network) is a serial bus system, which was originally developed for automotive applications in the early 1980’s. The CAN protocol was internationally standardized in 1993 as ISO 11898-1 and comprises the data link layer of the seven layer ISO/OSI reference model. CAN, which is by now available from around 40 semiconductor manufacturers in hardware, provides two communication services: the sending of a message (data frame transmission) and the requesting of a message (remote transmission request, RTR). All other services such as error signaling, automatic re-transmission of erroneous frames are user-transparent, which means the CAN chip automatically performs these services.
The equivalent of the CAN protocol in human communication are e.g. the Latin characters. This means a CAN controller is comparable to a printer or a type writer. CAN users still have to define the language/grammar and the words/vocabulary to communicate.
CAN provides;
w a multi-master hierarchy, which allows building intelligent and redundant systems. If one network node is defect the network is still able to operate.
w broadcast communication. A sender of information transmits to all devices on the bus. All receiving devices read the message and then decide if it is relevant to them. This guarantees data integrity as all devices in the system use the same information.
w sophisticated error detecting mechanisms and re-transmission of faulty messages. This also guarantees data integrity.
CAN has the following properties;
w prioritization of messages
w guarantee of latency times
w configuration flexibility
w multicast reception with time synchronization
w system wide data consistency
w multimaster
w error detection and signalling
w automatic retransmission of corrupted messages as soon as the bus is idle again
w distinction between temporary errors and permanent failures of nodes and
autonomous switching off of defect nodes
History of CAN
In February of 1986, Robert Bosch GmbH introduced the serial bus system Controller Area Network (CAN ) at the Society of Automotive Engineers (SAE) congress. It was the hour of birth for one of the most successful network protocols ever.
Today, almost every new passenger car manufactured in Europe is equipped with at least one CAN network. Also used in other types of vehicles, from trains to ships, as well as in industrial controls, CAN is one of the most dominating bus protocols - maybe even the leading serial bus system worldwide.
From idea to the first chip
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 Schelling, 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.
Standartization and Conformity
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.
The time of the CAN pioneers
Although CAN was originally developed to be used in passenger cars, the first applications came from different market segments. Especially in northern Europe, CAN was already very popular in its early days. In Finland, the elevator manufacturer Kone used the CAN bus. The Swedish engineering office Kvaser suggested CAN to some textile machine manufacturers (Lindauer Dornier and Sulzer) and their suppliers as the communications protocol within the machine. In this connection, under the leadership of Lars-Berno Fredriksson, the companies founded the ‘CAN Textile User’s Group’.
By 1989, they had developed communication principles that helped to shape the development environment ‘CAN Kingdom’ in the early 1990s. Although CAN Kingdom is not an application layer with respect to the OSI reference model, it can be considered the ancestor of the CAN-based higher layer protocols.
In the Netherlands, Philips Medical Systems had joined the industrial CAN users by deciding to use CAN for the internal networking of their X-ray machines. The ‘Philips Message Specification’ (PMS), mainly developed by Tom Suters, represented the first application layer for CAN networks. Professor Dr. Konrad Etschberger from the University of Applied Science in Weingarten, Germany, had almost identical ideas. In the Steinbeis Transfer Center for Process Automation (STZP), which he was in charge of, he developed a similar protocol.
In spite of the fact that the first standardized higher layer protocols started to emerge, most of the CAN pioneers used a monolithic approach. Communication functions, network management and application code were one piece of software. Even though some users would have preferred a more modular approach, they still would have had the disadvantage of a proprietary solution. The necessary efforts for enhancing and maintaining a CAN higher layer protocol had been underestimated - which is still partly true today.
In the early 1990s, the time was right to found a user’s group to standardize the different solutions. In the early months of 1992, Holger Zeltwanger, at that time editor in chief of VMEbus magazine (publisher: Franzis), brought together users and manufacturers to establish a neutral platform for the technical enhancement of CAN as well as the marketing of the serial bus system.
In March of 1992, the ‘CAN in Automation’ (CiA) international users and manufacturers group was officially founded. The first technical publication, already released after only a few weeks, was about the physical layer: CiA recommended to only use CAN transceivers that comply to ISO 11898. By now the manufacturer-specific RS485 transceivers, which were quite commonly used in CAN networks at that time and were not always compatible, should have completely vanished.
One of the first tasks of the CiA was the specification of a CAN application layer. Using the existing material from Philips Medical Systems and STZP, along with the help of other CiA members, the ‘CAN Application Layer’ (CAL), also called the ‘Green Book’, was developed. While developing specifications using CAN, one of the main tasks of the CiA was to organize the exchange of information between the CAN experts and the ones who wanted to become more knowledgeable on CAN. Therefore, since 1994, an annual international CAN Conference (iCC) is held.
Another academic approach was pursued in the LAV, an agricultural vehicle association. Since the late 1980s, a CAN-based bus system for agricultural vehicles (LBS) was being developed. But before the work could be successfully completed, the international committee had decided in favor of a US solution, J1939 (ISO 11783). This application profile, which is also based on CAN, was defined by the committees of the SAE Truck and Bus Association. J1939 is a non-modular approach that is very easy to use, but it is also very inflexible.
Also for trucks the standardization of CAN has developed. The networking between truck and trailer has been standardized as ISO 11992. This protocol is based on J1939 and must be used in Europe as of 2006. The trend for automotive vehicles goes toward OSEK-COM and OSEK-NM, a communication protocol and a network management. Both have been submitted for international standardization. Automotive builders however have been using proprietary software solutions so far.
From theory to practice
Of course the semiconductor vendors who implemented CAN modules into their devices are mainly focused on the automotive industry. Since the mid 1990s, Infineon Technologies (formerly Siemens Semiconductors) and Motorola have shipped large quantities of CAN controllers to the European passenger car manufacturers and their suppliers. As a next wave, Far Eastern semiconductor vendors also offered CAN controllers since the late 1990s. NEC came out with their legendary CAN chip 72005 in 1994, but in this case that was too early - the device was a no-go.
Since 1992, Mercedes-Benz has been using CAN in their upper-class passenger cars. As a first step, the electronic control units taking care of the engine management were connected via CAN. In a second step, the control units needed for body electronics followed. Two physically separate CAN bus systems were implemented, connected via gateways. Other car manufacturers have followed the example of their peers from Stuttgart and now usually also implement two CAN networks in their passenger cars. Now BMW, Fiat, Renault, Saab, Volkswagen, and Volvo use CAN in their vehicles.
In the early 1990s, engineers at the US mechanical engineering company Cincinnati Milacron started a joint venture together with Allen-Bradley and Honeywell Microswitch regarding a control and communications project based on CAN. However, after a short while, important project members changed jobs and the joint venture fell apart. But Allen-Bradley and Honeywell continued the work separately. This led to the two higher layer protocols ‘DeviceNet’ and ‘Smart Distributed System’ (SDS), which are quite similar, at least in the lower communication layers. In early 1994, Allen-Bradley turned the DeviceNet specification over to the ‘Open DeviceNet Vendor Association’ (ODVA), which boosted the popularity of DeviceNet. Honeywell failed to go a similar way with SDS, which makes SDS look more like an internal solution by Honeywell Microswitch. DeviceNet was developed especially for factory automation and therefore presents itself as a direct opponent to protocols like Profibus-DP and Interbus. Providing off-the-shelf plug-and-play functionality, DeviceNet has become the leading bus system in this particular market segment in the US.
In Europe, several companies tried to use CAL. Although the CAL approach was academically correct and it was possible to use it in industrial applications, every user needed to design a new profile because CAL was a true application layer. CAL can be looked at as a necessary academic step to an application-independent CAN solution, but it never gained wide acceptance in the field.
Since 1993, within the scope of the Esprit project ASPIC, a European consortium lead by Bosch had been developing a prototype of what should become CANopen. It was a CAL-based profile for the internal networking of production cells. On the academic side, Professor Dr. Gerhard Gruhler from the University of Applied Science in Reutlingen (Germany) and Dr. Mohammed Farsi from the University of Newcastle (UK) participated in what was one of the most successful Esprit activities ever. After the completion of the project, the CANopen specification was handed over to the CiA for further development and maintenance. In 1995, the completely revised CANopen communications profile was released and within only five years became the most important standardized embedded network in Europe.
The first CANopen networks were used for internal machine communication, especially for drives. CANopen features very high flexibility and configurability. The higher layer protocol, which has been used in several very different application areas (industrial automation, maritime electronics, military vehicles, etc.) has in the meantime been internationally standardized as EN 50325-4.
CANopen is being used especially in Europe. Injection modling machines in Italy, wood saws and machines in Germany, cigarette machines in Great Britain, cranes in France, handling machines in Austria, and clock-manufacturing machines in Switzerland are just a few examples within industrial automation and machine building. In the United States CANopen is being recommended for fork lifts and is being used in letter sorting machines.
CANopen not only defines the application layer and a communication profile, but also a framework for programmable systems as well as different device, interface and application profiles. This is an important reason why whole industry segments (e.g. printing machines, maritime applications, medical systems) decided to use CANopen during the late 1990s.
With DeviceNet and CANopen, two standardized (EN 50325) application layers are now available, addressing different markets. DeviceNet is optimized for factory automation and CANopen is especially well suited for embedded networks in all kinds of machine controls. This has made proprietary application layers obsolete; the necessity to define application-specific application layers is history (except, perhaps, for some specialized high-volume embedded systems).
| w Start of the Bosch internal project to develop an in-vehicle network | |
| w Official introduction of CAN protocol | |
| w First CAN controller chips from Intel and Philips Semiconductors | |
| w Bosch’s CAN specification 2.0 published | |
| w CAN Kingdom CAN-based higher-layer protocol introduced by Kvaser | |
| w CAN in Automation (CiA) international users and manufacturers group established | |
| w CAN Application Layer (CAL) protocol published by CiA | |
| w First cars from Mercedes-Benz used CAN network | |
| w ISO 11898 standard published | |
| w 1st international CAN Conference (iCC) organized by CiA | |
| w DeviceNet protocol introduction by Allen-Bradley | |
| w ISO 11898 amendment (extended frame format) published | |
| w CANopen protocol published by CiA | |
| w Development of the time-triggered communication protocol for CAN (TTCAN) |
The Attributes of CAN
CAN is a serial bus system with multi-master capabilities, that is, all CAN nodes are able to transmit data and several CAN nodes can request the bus simultaneously. The serial bus system with real-time capabilities is the subject of the ISO 11898 international standard and covers the lowest two layers of the ISO/OSI reference model. In CAN networks there is no addressing of subscribers or stations in the conventional sense, but instead, prioritized messages are transmitted. A transmitter sends a message to all CAN nodes (broadcasting). Each node decides on the basis of the identifier received whether it should process the message or not. The identifier also determines the priority that the message enjoys in competition for bus access. The relative simplicity of the CAN protocol means that very little cost and effort need to be expended on personal training; the CAN chips interfaces make applications programming relatively simple. Introductory courses, function libraries, starter kits, host interfaces, I/O modules and tools are available from a variety of vendors permitting low-cost implementation of CAN networks. Low-cost controller chips implementing the CAN data link layer protocol in silicon and permitting simple connection to microcontrollers have been available since 1989. Today there are more than about 50 CAN protocol controller chips from more than 15 manufacturers announced, and available.
The use of CAN in most of European passenger cars and the decision by truck and off-road vehicle manufacturers for CAN led to the availability of CAN chips for more than 10 years. Other high volume markets, like domestic appliances and industrial control, also increase the CAN sales figures and guarantee the availability for the future. Up to spring 1997 there have been more than 50 million CAN nodes installed. One of the outstanding features of the CAN protocol is its high transmission reliability. The CAN controller registers a stations error and evaluates it statistically in order to take appropriate measures. These may extend to disconnecting the CAN node producing the errors.
Each CAN message can transmit from 0 to 8 bytes of user information. Of course, you can transmit longer data information by using segmentation. The maximum transmission rate is specified as 1 Mbit/s. This value applies to networks up to 40 m. For longer distances the data rate must be reduced:for distances up to 500 m a speed of 125 kbit/s is possible, and for transmissions up to 1 km a data rate of 50 kbit/s is permitted.
CAN 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 realtime 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).
The main CAN application fields include:
w Off-highway and off-road vehicles
w Aircraft and aerospace electronics
w Medical equipment and devices
CAN applications in Cars
The automotive industry uses CAN as the in-vehicle network (IVN) for the engine management, the body electronics like door and roof control, air conditioning, and lightning, as well as for the entertainment control. The majority of the European carmakers use CAN-based IVNs. The American and the Far East passenger car manufacturers have also started implementing CAN-based IVNs.
CAN networks used in engine management connect several electronic control units (ECUs). Most of the European automobile manufacturers have also installed CAN high-speed networks (e.g. 500 kbit/s) in their power-engine systems.
In addition, most of the European passenger cars are equipped with CAN-based multiplex systems connecting body electronic ECUs. These multiplex networks link door and roof control units as well as lighting control units and seat control units. They run at lower data-rates, e.g. 125 kbit/s. Many of them use fault-tolerant transceivers compliant with ISO 11898-3. In North America, single-wire CAN networks are also used in body electronics.
In some passenger cars implement a CAN-based diagnostic interface. This interface may be based on the ISO 15765 standard (Diagnostics on CAN) describing physical-layer, transport-layer, application-layer, and how to use the Keyword 2000 diagnostic services.
Another application of CAN-based networks in passenger cars is to connect infotainment devices. There are some proprietary solutions, but also the IDB-C network. The SAE defined the IDB-C application profile in the ITS Data Bus series of specifications (SAE J2366). IDB-C is based on high-speed CAN (29-bit identifiers) with a baud-rate of 250 kbit/s.
The different CAN-based IVNs are connected via gateways. In many system designs, the gateway functionality is implemented in the dashboard. The dashboard itself may equipped with a local CAN network connecting the different displays and instruments.
CAN-based in-vehicle networks
Controller Area Network (CAN) was originally developed for power-train applications. Nowadays, there are additional applications in cars that make use of this 20-years old network technology. In nearly all of the European cars, the chassis network and the body networks are based on CAN. Even in the information and entertainment applications, sometimes CAN networks are used to control the devices or to provide an interface to the information that is already available in other CAN-based in-vehicle networks.
Power-train networks
The shift from mechanical to primarily electronics- and-software-based vehicle innovations started with the introduction of networked power-train ECUs. In the beginning three network technologies competed: A-Bus, CAN, and VAN. The A-Bus invented by the Volkswagen group and the French VAN (Vehicle Area Network) did not survive. Nowadays, CAN is used in Europe, America, and Far East. Just a few car models are not equipped with CAN network connecting the power-train ECUs.
There are still new developments in power-train applications. Quieter engines, less fuel consumption, cleaner exhaust, and better driving dynamics are sometimes contrary demands that can only be met when closed-loop software is enhanced and CAN communication is optimized. An example of what can be achieved, is the power pack from Bosch used in the GL-class from Mercedes-Benz.
Active vehicle safety systems
Seatbelts and airbags are the most successful passive vehicle safety systems. No doubt, they have saved many lives. The success story of active vehicle safety systems started with the electronic stability program (ESP) introduced by Bosch after a car from Mercedes had not passed the so-called ‘elk’ test. Electronic stability control (ESC) is the product-neutral term. ESC systems can detect unstable driving situations and make an automatic correction to protect the driver from losing control. The system compares the driver’s intended course with the vehicle’s actual movement using a complex system of sensor that measure wheel speed, steering-wheel angle, yaw rate, and lateral acceleration. This information is made available by several ECUs and communicated via the already installed in-vehicle CAN networks. If the ECS detects that the driver is losing control, it uses a combination of anti-lock brake (ABS), electronic force distribution, and active yaw control to stabilize the vehicles and help keep it on the road. The actuator commands are communicated to the ECUs via CAN networks. Continental, a company that makes more than tires, is developing the ESCII system. It monitors active steering control functions and is part of Continental’s Total Safety concept.
Parking assistance
The next generation of semi-autonomous parking assistance systems, which will be introduced in the next years to mid-range cars, uses ultrasonic sensors mounted on the sides of the vehicle to measure parking space length and depth as a vehicle passes it. The system calculates the required steering and informs the driver visually or acoustically. In more advanced systems such as park steering control, the steering will be handled by the electronically controlled power steering. Of course, parking assistance systems need communication to other sub-systems, and CAN would be a natural choice.
Body electronics
Historically, the second CAN application in in-vehicle networking was connecting comfort electronics such as power-mirrors, power-windows, lightning units, seat controllers, etc. First introduced in premium cars, those functions are nowadays provided even in compact cars. Typically, these CAN networks run at lower bit-rates than the power-train communication systems. Some carmakers have chosen the fault-tolerant CAN physical layer (ISO 11898-3). However, there is a trend to move to the high-speed low-power CAN physical layer (ISO 11898-5). Some pessimists expect that the ISO 11898-3 low-speed transceiver may be discontinued some day.
The innovations in this body electronics will rely on CAN connectivity. Hella has developed adaptive headlamps. The first car that has made use of this technology is the E-class from Mercedes-Benz. Adaptive headlamps adjust to different driving and weather situations and thereby offer significant improvements to driving safety. The system from Hella provides five lighting functions: country, motorway, active bend lighting, fog and cornering. The country light illuminates the left-hand edge of the road brighter and over a grater range than the previous low beam. The motorway light switches on automatically from speed of 90 km/h. The cornering light function is used when driving slowly through bends. Some of these intelligent light functions require information from other ECUs. Those are made available through the CAN in-vehicle networks.
Challenges in automotive applications
CAN, the leading network in power-train and body electronic applications, is very well accepted by European carmakers and it is also becoming the leading network in America and the Far East. The big three - DaimlerChrysler, Ford, and General Motors - are heavily involved in CAN network developments. But still they are mainly using the slow J1850 network for body electronics. In Far East, Toyota has already implemented CAN and other Japanese and Korean carmakers will follow very soon.
Each year several million of CAN nodes in passenger cars are installed. Each day about 100,000 ABS units worldwide are produced, and nearly half of them are equipped with a CAN interface. Other electronic control units (ECU) provide CAN connectivity as well. Bosch’s ESP (Electronic Stability Program), an extension of ABS (antilock braking system) and ASR, is also mostly connected to the CAN-based in-vehicle network. While ABS and ASR prevent undesired slip longitudinally, ESP also reduces loss of lateral stability. In 1999, Bosch produced its one-millionth ESP unit, which first appeared on the Mercedes-Benz 1995 S-Class. Today, ESP units are installed on all Mercedes-Benz cars, from A-Class to S-Class. ESP is also installed in the Peugeot’s 607 and networked via CAN to the automatic gearbox and engine control units.
No more fumbling for car keys, that is only true for S-Class drivers and soon also for Cadillac buyers. In 1999, the world’s first keyless entry and ignition technology, called Keyless Go, was introduced for Mercedes-Benz S-Class models. Jointly developed by DaimlerChrysler and Siemens Automotive the Keyless Go control unit provides a CAN interface. Exiting the car is just as convenient as entering it: Pressing the start/stop button switches the engine off and locks the gear selector lever in the park position. The doors are looked briefly touching a button on the interior trim panel, or a button on the exterior door handle. The system alerts the driver to any problems, for example, if the key fob has been left in the car.
Higher Layer Protocols
The CAN protocol provides basic communication services. In any CAN network application, there is some additional functionality required. This may be implemented in software and, if it is separated from real application programs, is called higher-layer protocol. If open communication is required, the higher-layer protocol specification should be available publicly.
There are several standardized higher-layer protocols for CAN network applications. CiA supports all internationally standardized higher-layer protocols as well as “CAN Application Layer (CAL)”, CANKingdom, CANopen, and DeviceNet. They address different applications fields, and sometimes there may be a small overlapping of the fields.
Many higher-layer protocols allow object-oriented modeling of devices and network. They feature interoperability between devices, and when standardized device profiles are used even interchangeability of modules. Some higher-layer protocol definitions provide off-the-shelf plug-and-play capability.
However, more standardization leads to less communication flexibility meaning that is no longer possible to tailor communication to application requirements. Benefits of all standardized higher-layer protocols include off-the-shelf protocol stack implementations as well as configuration and analysis tools from different sources. Another important advantage of standardized protocols is the availability of independent conformance testing and certification as provided by ODVA for DeviceNet and by CiA for CANopen.
CAN-based Microcontrollers
The following devices have on-chip CAN controllers.
§ Atmel (8051 Family)
T89C51CC01, T89C51CC02
§ Atmel (ARM7/ARM9/Cortex-M3 Family)
AT91SAM7A1, AT91SAM7A2, AT91SAM7A3, AT91SAM7X128, AT91SAM7X256, AT91SAM7XC128, AT91SAM7XC256
§ Dallas Semiconductor (8051 Family)
DS80C390, DS80C400
§ Freescale Semiconductor (ARM7/ARM9/Cortex-M3 Family)
MAC7101, MAC7104, MAC7105, MAC7106, MAC7111, MAC7112, MAC7114, MAC7115, MAC7116, MAC7121, MAC7122, MAC7124, MAC7125, MAC7126, MAC7131, MAC7134, MAC7135, MAC7136, MAC7141, MAC7142, MAC7144
§ Infineon (8051 Family)
C505C-2R, C505CA-4E, C515C-8R / -8E, C515C-L
§ Infineon (C16x/ST10/XC16x Family)
C161CS, C161JC, C164CI, C164CL, C164CM, C167CR-16FM, C167CR-16RM, C167CR-4RM, C167CR-L25M, C167CR-LM, C167CS-32FM, C167CS-4RM, C167CS-LM, XC161CJ-16F, XC164CS-16F, XC167CI-16F, XC167CI-32F
§ NXP (founded by Philips) (8051 Family)
P80C591, P80C592, P80CE598, P83C591, P83C592, P83CE598
§ NXP (founded by Philips) (ARM7/ARM9/Cortex-M3 Family)
LPC2119, LPC2129, LPC2194, LPC2290, LPC2292, LPC2294, LPC2364, LPC2366, LPC2368, LPC2378
§ Sharp (ARM7/ARM9/Cortex-M3 Family)
LH75400, LH75401
§ Silicon Laboratories, Inc. (8051 Family)
C8051F040, C8051F041, C8051F042, C8051F043, C8051F044, C8051F045, C8051F046, C8051F047, C8051F060, C8051F061, C8051F062, C8051F063
§ STMicroelectronics (ARM7/ARM9/Cortex-M3 Family)
STR710FZ1, STR710FZ2, STR712FR0, STR712FR1, STR712FR2, STR730FZ1, STR730FZ2, STR731FV0, STR731FV1, STR731FV2, STR735FZ1, STR735FZ2, STR736FV0, STR736FV1, STR910FM32, STR910FW32, STR911FM42, STR911FM44, STR912FW42, STR912FW44
§ STMicroelectronics (C16x/ST10/XC16x Family)
ST10CT167, ST10F167, ST10F168, ST10F269, ST10F280, ST10R167
§ TI (ARM7/ARM9/Cortex-M3 Family)
TMS470R1A128, TMS470R1A256, TMS470R1A288, TMS470R1A384, TMS470R1A64, TMS470R1B1M, TMS470R1B512, TMS470R1B768
LIN - Local Interconnect Network
What is LIN?
LIN (Local Interconnect Network) is a new low cost serial communication system intended to be used for distributed electronic systems in vehicles, which complements the existing portfolio of automotive multiplex networks (see figure below).
LIN is a holistic communication concept for local interconnect networks in vehicles. The specification covers in addition to the definition of the protocol and the physical layer also the definition of interfaces for development tools and application software.
LIN enables a cost-effective communication for smart sensors and actuators where the bandwidth and versatility of CAN is not required. The communication is based on the SCI (UART) data format, a single-master/multiple-slave concept, a single-wire 12V bus, and a clock synchronization for nodes without stabilized time base.
Until today no automotive standard in low end multiplex communication has established. The LIN consortium has been developed to standardize a concept of a serial low cost communication concept in conjunction with a development environment, that enables the car manufacturers and their suppliers to create, implement, and handle complex hierarchical multiplex systems in a very cost competitive way.
The LIN standard will reduce the manifold of existing low-end SCI based multiplex solutions and will cut the cost of development, production, service, and logistics in vehicle electronics.
The LIN specification covers the transmission protocol, the transmission medium, the interfaces for development tools, and application software. LIN guarantees the interoperability of network nodes from the viewpoint of hardware and software, and a predictable EMC behavior.
This concept allows the implementation of a seamless chain of development and design tools and enhances the speed of development and the reliability of the network.
The key features of LIN are:
- Low cost single-wire implementation
- Enhanced ISO 9141, VBAT-Based
- Speed up to 20Kbit/s
- Acceptable speed for many applications (limited for EMI-reasons)
- Single Master / Multiple Slave Concept
- No arbitration necessary
- Low cost silicon implementation based on common UART/SCI interface hardware
- Almost any microcontroller has necessary hardware on chip
- Self synchronization in the slave nodes without crystal or ceramics resonator
- Significant cost reduction of hardware platform
- Guaranteed latency times for signal transmission
- Predictable systems possible
The LIN Concept
Features
LIN is a single-wire serial communications protocol based on the common SCI (UART) byte-word interface. UART interfaces as available as low cost silicon module on almost all micro-controller and can also be implemented as equivalent in software or pure state machine for ASICs. The medium access in a LIN network is controlled by a master node so that no arbi-tration or collision management in the slave nodes is required, thus giving a guarantee of the worst-case latency times for signal transmission.
A particular feature of LIN is the synchronization mechanism that allows the clock recovery by slave nodes without quartz or ceramics resonator. The specification of the line driver and receiver is following the ISO 9141 single-wire standard with some enhancements. The maximum transmission speed is 20 kbit/s, resulting from the requirements by electromagnetic compatibility (EMC) and clock synchronization.
A node in LIN networks does not make use of any information about the system configuration, except for the denomination of the master node. Nodes can be added to the LIN network without requiring hardware or software changes in other slave nodes. The size of a LIN network is typically under 12 nodes (though not restricted to this), resulting from the small number of 64 identifier and the relatively low transmission speed. The clock synchronization, the simplicity of UART communication, and the single-wire medium are the major factors for the cost efficiency of LIN.
Communication Concept
A LIN network comprises one master node and one or more slave nodes. All nodes include a slave communication task that is split in a transmit and a receive task, while the master node includes an additional master transmit task. The communication in an active LIN network is always initiated by the master task as illustrated in the figure below: the master sends out a message header which comprises the synchronization break, the synchronization byte, and the message identifier.
Exactly one slave task is activated upon reception and filtering of the identifier and starts the transmission of the message response. The response comprises two, four, or eight data bytes and one checksum byte. The header and the response part form one message frame.
LIN Message Frame
The identifier of a message denotes the content of a message but not the destination. This communication concept enables the exchange of data in various ways: from the master node (using its slave task) to one or more slave nodes, and from one slave node to the master node and/or other slave nodes. It is possible to communicate signals directly from slave to slave without the need for routing through the master node, or broadcasting messages from the master to all nodes in a network. The sequence of message frames is controlled by the master and may form cycles including branches.
Target Applications
Typical applications for the LIN bus are assembly units such as doors, steering wheel, seats, climate regulation, lighting, rain sensor, or alternator. In these units the cost sensitive nature of LIN enables the introduction of mechatronic elements such as smart sensors, actuators, or illumination. They can be easily connected to the car network and become accessible to all types of diagnostics and services.
The commonly used analog coding of signals will be replaced by digital signals, leading to an optimized wiring harness. It is exspected that LIN will create a strong market momentum in Europe, the U.S.A., and Japan.
LIN Specification
The LIN Standard encompasses the specification of the transmission protocol, the transmission medium, the interface between development tools, and the interfaces for software programming. LIN guarantees the interoperability of network nodes from the viewpoint of hardware and software, and a predictable EMC behavior.
The Specification package consists of three main parts:
The LIN Protocol Specification describes the Physical Layer and the Data Link Layer of LIN.
The LIN Configuration Language Description describes the format of the LIN configuration file, which is used to configure the complete network and serves as a common interface between the OEM and the suppliers of the different network nodes, as well as an input to development and analysis tools.
The LIN API describes the interface between the network and the Application Program.
This concept allows the implementation of a seamless chain of development and design tools and enhances the speed of development and the reliability of the network.
Scope of the LIN Specifications
References
1. http://www.semiconductors.bosch.de
2. CAN Specification 2.0B
3. http://www.can-cia.org
4. http://www.lin-subbus.org/
5. LIN Press Announcement, SAE Conference, 2000, Detroit USA
Appendix A
BOSCH
CAN Specification
Version 2.0
2588
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
