Pc CAN card development

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.


This literature presents an overview of the concept of Controller Area Network (CAN) and CANopen protocol .It highlights the history of CAN and CANopen and helps us understand the difference between the them. The information presented here is mainly concerned with the advances of these protocols and how they have developed from being initially used in the automotive industry to being used in various automation sectors around the globe.This literature overviews various research papers,websites and journals ,to compare these two protocols in detail. Further work will be carried out using the CANopen protocol in order to understand and demonstrate the how powerful the CANopen protocol is and how it is implemented in the automation industry.

1. Introduction

Many times while designing networks, network engineers face problems like network routing, efficient network design, quality of service and unfamiliar settings. As a result Engineers started developing several bus networks in order to transmit and receive data in a fast and efficient manner. Today many network bus protocols like Profibus, Modbus, HART, Ethernet,etc are available in the market. Depending on the requirement and the application in demand any of these open protocols can be used so it is a matter of making the right selection for an application .CAN and CANopen are among these open vendor protocols which is governed by a non-profit organization known as the CAN in Automation (CiA) based in Nuremberg (Germany).

2. History Of CAN And CAN Open

Controller Area Network(CAN) was originally developed in February 1986, by Robert Bosch Gmbh and was introduced as ‘Automotive Serial Controller Area Network' at the SAE congress in Detroit, as the new bus system .Bosch engineers Uwe Kiencke, Siegfried Dais and Martin Litschel were the pioneers in introducing this multi-master network protocol. It was based on a non-destructive arbitration mechanism that grants bus access to the message with the highest priority, without causing any delays. This Automotive Serial CAN Protocol was introduced due to the fact that the cars required the extra wiring costs for increased number of distributed control system and also that none of the existent protocols could perform satisfactorily for the automotive engineers. One of CAN's first use was in interconnecting the ABS (Anti-Block System and Acceleration Skid Controls (ASC).For example in ASC, engine timing and carburetor control are required when slippage occurs and vice versa. It was first developed for the automotive industry, furthermore it developed widely for other automation sectors and today is used in the other large variety of embedded systems applications. The first hardware implementation of CAN protocol was produced by Intel Corporation in mid-1987 in the form of controller chip ,the 82526 which favored the FullCan concept as compared to BasicCAN implementation chosen by Philips 82C200 introduced by Phillips Semiconductors which shortly followed. The semiconductor vendors who implemented CAN modules into their devices were mainly focused on the automotive industry and since the mid-1990s,companies in the like of Infineon Technologies (formerly Siemens Semiconductors) and Motorola have manufactured and delivered large quantities of CAN controller chips to the European passenger car manufacturers and their suppliers.

In 1993, within the scope of the Esprit project ASPIC, a European consortium led by Bosch developed a prototype of what should become CANopen. It was a Controller Application Layer (CAL) based profile for the internal networking of production cells.In one of the most successful Esprit activities ever, academicians Dr. Gerhard Gruhler from the University of Applied Science in Reutlingen (Germany) and Dr. Mohammed Farsi from the University of Newcastle (UK) participated in this Espirit project. After the completion of the project, the CANopen specification was handed over to the CiA for further development and maintenance [20]. In 1995, the completely revised CANopen communications profile was released and by the year 2002 it was recognized as CENELEC EN 50325-4. After its release, it has found widely acceptance ratio, more especially in the European countries where CANopen is considered as the leading standard for the CAN based applications and solutions for the industries. CANopen protocol is a standardized protocol on one hand, but on the other side this protocol is still open for unlimited fields of applications. It is designed as the higher layer protocol. The CANopen protocol which is mainly based on the CAN had set up the communication between different manufacturers devices with the interchangeability of devices guarantee. This protocol defined the standard sets of applications for all kinds of distributed systems which are based on the basic CAN protocol.


1983: Bosch Starts an internal project to develop an in vehicle network.

1986: Introduction of the CAN protocol.

1987: First CAN controller chip from Intel and Phillips Semiconductors.

1991: Bosch CAN specification 2.0 published.

1991: CAN Kingdom CAN-based higher-layer protocol introduced by Kvaser

1992:CAN in Automation(CiA)international users and manufacturers group established.

1992: CAN Application layer (CAL) protocol published by CiA.

1992: First cars from Mercedes Benz used CAN network.

1993: ISO11898 standard published.

1994: 1st International CAN Conference (ICC) organized by CiA.

1994: DeviceNet protocol introduced by AllenBradley.

1995: ISO11898 amendment (extended frame format) published.

1995: CANopen protocol published by CiA.

2000: Development of the time-triggered communication protocol for CAN (TTCAN)[20]

3. CAN AND CANopen Protocol


CAN is a serial Bus system which is especially suited for networking several intelligent devices. It is a serial bus with multi-master capabilities i.e. at any point in time; several CAN nodes or devices try to transmit data.


CAN can be interpreted as being a two layer protocol in terms of the OSI/ISO 7-layer reference model. In other words CAN operates at the physical layer and the data link layer of the standard OSI Model,. The physical layer determines how the signal is transmitted. The International Standards Organization (ISO) defined a standard ISO11898 which incorporates the CAN specifications to meet some of the requirements namely ,the physical signaling, which includes bit encoding and decoding (Non-Return-to-Zero, NRZ) as well as bit timing and synchronization. Using the serial bus network mechanisms the existing CAN applications send messages over the network. In the CAN systems there is no need for central controller as every node is connected to the every other node in the network.

Following figure shows the block diagram of typical CAN network used for the CAN applications communication.

The Controller Area Network (CAN) features, includes mainly multi-master functionality and the ability to broadcast/multicast telegrams.CAN's multi-master communication capability ensures that each node equally communicates with every other node in the system and hence any node can send messages to every other node in the system. In case if any node/device fails, then other nodes/devices in the bus network takes up the responsibility to complete the communication so as to maintain a proper working system. If the bus is busy then the node which desires to send the message waits until the bus becomes available. Each message has its own unique identification number which is available to all the other nodes in the system. A node selects only the messages that are relevant to the system and ignores the rest. Initially the CAN protocol was designed for the short messages which are only 8 bytes long, and above that were not allowed. The defined protocol does not disturb the current communication, rather it only assign the priorities to all the messages to be delivered in order that the messages which are urgent are delivered first so as to avoid conflicts. The CAN protocol includes the robust error detection mechanisms and fault confinement mechanism which makes the system highly reliable. In the bus network when any node fails it is removed from the system without affecting the rest of the network as result more robustness is provide to the system[8]. The CAN system network works completely differently as compared to the other networks like USB or Ethernet, as in the CAN there is no central bus master; here every node has the same authority and functionality. The interface between the CAN serial bus and CAN application is provided by the CAN Controller, which converts the data provided by the application into a CAN frame which is then transmitted across the CAN serial bus. The Physical connection of the CAN controller to the CAN bus is done with the CAN transceiver that complies with ISO11898, for example Phillips 82C250, which is widely used for CAN implementation. The Controller transfers the serial input stream to the transceiver which converts it into the various differential signals. At the physical layer resulted differential signals are transmitted across the CAN serial bus by a two wire bus line CAN-High and CAN-Low with a common return in order to overcome the noise interruption issues by carrying signals of opposite polarity. The bus accessing priority is determined by the 11- bit identifier using a bit arbitration technique used in the CAN network. All the messages in the network are received by the CAN Controller that are transmitted on the bus .The Controller uses a filtering mechanism to decide and select the interfacing application relevant information in order to proceed to further information. The future of CAN is thus safe due to the low cost of its components, high data reliability and short reaction times, together with the huge user base.

To summarize the CAN protocol has the following properties

  • · message prioritization
  • · flexibility
  • · system wide consistency in data.
  • · error detection and its signaling
  • · latency time guarantee
  • · multimaster capability
  • · time synchronization and muticast reception.
  • · retransmitting corrupted messages automatically as soon as the bus is idle again.
  • · distinction between temporary errors in nodes and permanent failures of nodes and

automatic switching off of defective nodes.

CAN Open Standard And OSI Model


CANOpen network systems uses three layers of the OSI Model ie, the Physical Layer, Data Link Layer and Application Layer as compared to CAN which uses the layer 1 and 2 of the OSI model. Rests of layers are not needed for this fieldbus system. In CANopen network standards we need the topmost layer, that is the Application layer in OSI network model so as to use the higher level protocols which are necessary to define the way the CAN message gets frames 11-bit identifier and use of 8 data bytes.

The CANOpen Based automation applications require the application layer protocols and the profiles, communication system standardizing, administration of the system and functionality of the devices.

1) Application Layer: This layer provides a set of services and protocols which are useful to every device on the existing network application.

2) Communication profile: this profile provides the information to configure devices and communication data as well as defines how the data is actually communicated between devices.

3) Device profiles: Device profiles add device-specific behavior for devices (e.g. digital I/O, analog I/O, motion controllers, encoders, etc.)

To address this issues initially another standard was designed and implemented known as the CAN Application Layer System (CAL).

CAL (CAN Application Layer)

Philips Medical Systems developed the higher layer communication protocols which already exist for the CAN networks called as CAL (CAN Application Layer). It was adopted by CAN in Automation (CiA) to develop further and published in a series of standards.

CAL has the following four application layer services:

1. CAN-based Message Specification (CMS): CMS is based on the Manufacturing Message Specification (MMS) and it offers objects to design and specify how the functionality of any node in the network is accessed using the existing CAN interface.

2. Network Management (NMT): It offers services which are used for the network management such as to initialize nodes, to stop nodes, to start nodes, to detect nodes failure etc.

3. Distributor (DBT): It is used to dynamically distribute the CAN identifiers to the existing network nodes. This service is implemented by considering the Master-slave mechanism.

4. Layer Management (LMT): It provides the facility to change the application layer parameters such as change the node NMT-address, or changing bit-timing and baud-rate of the CAN interface.

All the network management services, message protocols are provided by the CAL standard, but it is failed to get the contents of the CMS objects or what kind of objects communicated rather than just defining what kind of objects. These issues were resolved with the introduction of CANopen.

CAN Open Overview

CANopen is a higher layer protocol build on the basis of CAL mechanism and also on CAN protocol. It works in the way that the available nodes can range from the simplex functionality to the complex functionality without affecting the interoperability issues between the nodes in the network .Device Object Dictionary (OD) is the main mechanism which in the consideration in the case of CANopen. In any CAN open device all bus traffic is conceptually divided into two classes i.e. Service data object (SDO) and Process data object(PDO). The communication in SDO involves configuration information of all devices, e.g. output polarity selection for a digital output module whereas the communication in PDO includes all information relating to the devices 'run-time' operation e.g. actual position of a drive unit.This Device Object Dictionary concept is not included into the CAL system; it is an implementation aspect of the CANopen standard . CANopen provides a mechanism whereby devices of different types are integrated together and communicate in a standard format thereby making different CAN devices interoperable with one another.

Transmitting Device Receiving Device

This Fig.4 describes different layers interactions and communication between them. On the application layer of CANopen, the devices on that layer exchanges the objects of communication and particular application. These objects are then accessible for processing by a 16-bit index and 18-bit sub-index. Using the configured and pre-defined identifiers such communication objects of the applications are then mapped to one or many CAN frames. Here the Physical layer specifies the bit level significance with bit timing.

4. Conclusion

CANopen is therefore to be concluded as an open protocol which not only has all the defined properties of CAN but also has an additional advantage in the usage of application layer of the OSI reference model. CANopen not does involve the use of a busmaster for exchanging data between nodes on the network it allows full broadcast/multicast features and a variety of communication modes designed to help keep bus loading minimal and predictable. Therefore, CANopen is well suited to to the concept of remote intelligence and is ideal for distributed control solutions. With reference to this literature review, I propose to develop a CAN card which communicates over the CAN open protocol serial bus, and act a master controller such that it can sent as well as receive information from any node that is connected over the bus. The card includes a CAN microcontroller chip in the form of Siemens C167CR-16RM, which forms the main controller, a transceiver eg.Phillips 82C250 which forms an interface between the CAN controller and a the serial Bus.

5. References

[1] CAN Specification Version 2.0,Part A, Robert Bosch GmbH, Stuttgart, Germany, 1991.

[2] Wolfhard Lawrenz, CAN System Engineering: From Theory to Practical Applications, Springer-Verlag, 1997, ISBN 0-387-94939-9.

[3] Daniel Mannisto, Mark Dawson, An Overview of Controller Area Network (CAN) Technology, mBus, 2003.

[4] Steve Corrigan, Introduction to the Controller Area Network (CAN) - Texas Instruments Application Report, SLOA101, 2002.

[5] ISO. International Standard ISO 11898: Road Vehicles - Interchange of digital information -Controller Area Network (CAN) for high speed communication, ISO 11898:1993[E], 1993.

[6] Karl Henrik Johansson, Martin Torngren, Lars Nielsen, Vehicle Applications of Controller Area Network, 2005.

[7] Stuart Robb, CAN Bit Timing Requirements - Motorola Semiconductor Application Note, AN1798, 1999.

[8] Lars-Berno Fredriksson, Controller Area Networks and the protocol CAN for machine control systems, Kvaser AB, P.O. Box 4076, S-511 04 Kinnahult, Sweden.

[9] Blagomir Donchev, Marin Hristov, Implementation of CAN Controller With Universidade Técnica de Lisboa, Avenida Rovisco Pais - 1096 Lisboa Codex - Portugal.

[10] Michael John Sebastian Smith, Application-Specific Integrated Circuits, Addison-Wesley Longman Publishing Co., Inc., 1997, ISBN 0-201-50022-1. FPGA Structures, 7th International Conference, CADSM, 2003.

[11] CAN-in-Automation, CAL, CAN Application Layer for Industrial Applications, CiA Draft Standard DS-201 to DS-207, Version 1.1, Feb 1996.

[12] CAN-in-Automation, CANopen, CAL-based Communication Profile for Industrial Systems, CiA DS-301, Version 4.0, June 16 1999.

[13] CAN-in-Automation, CANopen Device Profile for I/O Modules, CiA DSP-401, Version 1.4, Dec 1996.

[14] CAN-in-Automation, Framework for Programmable CANopen Devices, CiA DSP-302, Version 2.0, Nov 27 1998.

[15] CS5525/CS5526 16-bit / 20-bit multi-range ADC with 4-bit latch, data sheet, Crystal Semiconductor Corporation, Sep 1996.

[16]H.Boterenbrood, SPICAN CANopen I/O-system (for analog inputs), user documentation, Version 2.1, NIKHEF internal documentation, Jan 14 2000.

[17] CAN-in-Automation, CANopen Device Profile for Measuring Devices and Closed-Loop Controllers, CiA DSP-404, Revision 1.11, Nov 27 1997.

[18] Dr Mohammad Farsi and Mr Karl Ratcliff, CANopen: The Open Communications Solution, Department of Electrical and Electronic Engineering, The University of Newcastle Upon Tyne.

[19]M.Farsi and M.Barbosa,”CANopen Implementation:Application to industrial networks”,ISBN 0863802478, January 2000 ,Research Studio Press ltd.

[20]CAN history, CAN in Automation e.V., Kontumazgarten 3,DE-90429 Nuremberg

Website: http://www.can-cia.org/index.php?id=522

[21]Farsi.M ,Ratcliff.K,”An Introduction to CANopen and CANopen communication issues”CANopen Implementation (Digest No. 1997/384), IEE Colloquium on
Volume , Issue , 6 Oct 1997 Page(s):2/1 - 2/6

[22]M.Farsi,K.Ratcliff,”CANopen:CONFIGURE AND DEVICE TESTING”, Department of Electrical and Electronic Engineering, The University of Newcastle Upon Tyne.