The CAN Man Can

http://www.thecanmancan.com
RSS

CAN-Engine Programmable Embedded Controller

Posted by admin on June 16th, 2009 No Comments

The CAN-EngineTM (CANE) is a high performance, low cost, C/C++ programmable embedded controller with CAN support. It is intended for networking, automotive, industrial process control, high-speed data acquisition, and especially ideal for OEM applications.

A Controller Area Network (CAN) controller (SJA1000, 20 MHz clock) can be installed along with on-board CAN transceiver. Supported baud rates range from 300 bps to 1 Mbps, and interrupt-driven buffering software allows reliable, efficient delivery and receipt of packets over the CAN network. CAN control egisters on the SJA1000 are accessible in software.

A Fast Ethernet Module can also be installed to provide 100M BaseT network connectivity. This Ethernet module has a hardware LSI TCP/IP stack. It implements TCP/IP, UDP, ICMP and ARP in hardware, supporting internet protocol DLC and MAC. The hardware Ethernet module releases internet connectivity and protocol processing from the host processor, which represents a huge improvement over software-based TCP/IP stacks. The resulting system can easily handle transmissions in the 100KB/s+ range in real world applications. It supports 4 independent stack connections simultaneously at a 4Mbps protocol processing speed. Software libraries and demo project are available for Ethernet connectivity.

A 16-bit parallel ADC (AD7655, 0-5V) supports ultra high-speed (1 MHz conversion rate) analog signal acquisition. The AD7655 contains two low noise, high bandwidth track-and-hold amplifiers that allow simultaneous sampling on two channels. Each track-and hold amplifier has a multiplexer in front to provide a total of 4 channels analog inputs. The 16-bit parallel ADC requires only two CPU I/O operations (one start, one read) to complete a 16-bit ADC reading. With on-board precision 2.5V reference, the ADC accepts 0-5V analog inputs at 16-bit resolution of 0-65,535.

The CANE supports up to 2 GB mass storage CompactFlash cards with Windows compatible FAT filesystem support, allowing user easily transfer large amounts of data to or from a PC.

The CANE features fast execution times through 16-bit ACTF Flash (256 KW) and battery-backed SRAM (256 KW). It also includes 3 timers, PWMs, 20+ PIOs, 512-byte serial EEPROM, two RS232 ports, 3 timer/counters, and a watchdog timer. The three 16-bit timers can be used to count or time external events, up to 10 MHz, or to generate non-repetitive or variable-duty-cycle waveforms as PWM outputs. The PIO pins are multifunctional and user programmable. A real time clock (DS1337, Dallas) is available.

The CANE can be powered by regulated 5V DC or unregulated 9-12V DC with installing a 5V regulator. The CANE works with TERN expansion boards including the P52, P100 and MotionC.

For more information log on to:
http://www.tern.com/portal/content.asp?contentid=909&gclid=CNKX8OGVj5sCFeFL5QodFFEnpw

Posted in CAN, Controller Area Network, Physical Layer

Vehicle Applications of Controller Area Network

Posted by admin on May 26th, 2009 No Comments

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, and 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, turbo, fan, etc. but also the CAN communication. Combining networks and mechatronic modules makes it possible to reduce both the cabling and the number 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.

For more information log on to:
http://www.md.kth.se/RTC/Papers/VehicleApplicationsCan2005.pdf

Posted in CAN, Controller Area Network, Vehicles

EMI/ESD Protection Solutions for the CAN Bus

Posted by admin on May 26th, 2009 No Comments

The Controller Area Network (CAN) is a serial communication protocol designed for providing reliable high−speed data transmission in harsh environments. CAN system designers are being challenged to meet stringent Electromagnetic Interference (EMI) and Electrostatic Discharge (ESD) standards and increase reliability, while reducing the size and cost of their products. This document provides guidelines to select a CAN bus protection circuit that can prevent conducted and radiated EMI and ESD noise problems. The attributes of several practical CAN bus protection circuits will be analyzed using discrete filters, common mode chokes and Transient Voltage Suppression (TVS) devices. 

Bus protection circuits are used to supplement the noise immunity level of CAN transceivers. Many of the second generation CAN transceivers meet the minimum transient overvoltage test levels; however, higher immunity levels can be easily achieved by adding external EMI/ESD protection circuits. The CAN bus protection circuits improve the reliability of the CAN module, without significantly adding to the cost and complexity of the transceiver circuit. 

Control systems can be implemented using either a centralized or a distributed architecture. A centralized control system typically consists of a single, relatively complex control unit that is used to perform multiple tasks and monitor several sensors. In contrast, a distributed control system consists of many controllers that perform a specialized task. The sensors, actuators and motors in a centralized system require point to point wiring in order to exchange information with the control unit, while a distributed system requires only a few wires to connect all of the control units. Also, each control unit in a distributed system, such as the CAN bus can be implemented with a low cost microprocessor. 

For more information log on to:
http://www.onsemi.com/pub_link/Collateral/NUP2105L-APP.PDF

 

Posted in CAN, Controller Area Network, Isolation, Transceiver

A CAN Physical Layer Discussion

Posted by admin on May 26th, 2009 No Comments

Many network protocols are described using the seven layer Open System Interconnection (OSI) model. The Controller Area Network (CAN) protocol defines the Data Link Layer and part of the Physical Layer in the OSI model. The remaining physical layer (and all of the higher layers) are not defined by the CAN specification. These other layers can either be defined by the system designer, or they can be implemented using existing non-proprietary Higher Layer Protocols (HLPs) and physical layers. 

The Data Link Layer is defined by the CAN specification. The Logical Link Control (LLC) manages the overload control and notification, message filtering and recovery management functions.  The Medium Access Control (MAC) performs the data encapsulation/decapsulation, error detection and control, bit stuffing/destuffing and the serialization and deserialization functions. 

The Physical Medium Attachment (PMA) and Medium Dependent Interface (MDI) are the two parts of the physical layer which are not defined by CAN.  The Physical Signaling (PS) portion of the physical layer is defined by the CAN specification.  The system designer can choose any driver/receiver and transport medium as long as the PS requirements are met. 

The International Standards Organization (ISO) has defined a standard which incorporates the CAN specification as well as the physical layer. The standard, ISO-11898, was originally created for high-speed in-vehicle communications using CAN. ISO-11898 specifies the physical layer to ensure compatibility between CAN transceivers. 

A CAN controller typically implements the entire CAN specification in hardware. The PMA is not defined by CAN, however, it is defined by ISO-11898. This document discusses the MCP2551 CAN transceiver and how it fits in with the ISO-11898 specification.

For more information log on to:
http://ww1.microchip.com/downloads/en/AppNotes/00228a.pdf 


Posted in CAN, Controller Area Network, Isolation, Physical Layer, Transceiver

Protecting your CAN bus with digital isolation techniques

Posted by admin on May 26th, 2009 No Comments

Serial communication buses transmit data over physical networks like RS-232, RS-485 and the controller-area network (CAN). The buses are used in such applications as industrial process control, power supply regulation and point-to-point communications between computers.

Each of the interconnected systems usually has its own power supply, and the systems are often separated by long distances. Because of this, galvanic isolation is typically required to ensure physical safety, as well as to break up ground loops, protect the system from high-voltage transients and reduce signal distortion.

Transformers, coupling capacitors, optocouplers-and now, ADI’s iCouplers-are typical means of providing galvanic isolation, which blocks current from flowing between two points while allowing data to pass unimpeded.

Isolation is used to protect against high voltages or currents caused by line surges or ground loops, which can occur in any system that has many ground paths. System grounds that are separated by long cables will not be at the same potential, so ground current will flow between the two systems. Without isolation, this current could introduce noise, degrade measurements or even destroy system components.

Currents that are inductively coupled into the long cables found in industrial environments by motors switching on and off, electrostatic discharge or nearby lightning strikes can cause rapid changes in ground potential, often as large as hundreds, or thousands, of volts. When this occurs, the logic-level switching signal expected by the remote system would be superimposed on a high voltage with respect to its local ground. Without isolation, this voltage could corrupt the signal or damage the system. Referring all devices connected to the bus to a single ground will protect the system against this destructive energy, and isolating the devices will prevent ground loops and electrical surges.

To completely isolate the system, all signal lines and power supplies must be isolated. An isolated dc/dc converter can provide power supply isolation, while the iCoupler digital isolator provides the signal isolation.

For more information log on to:
http://www.embedded.com/columns/technicalinsights/172301714?_requestid=8466 

Posted in CAN, Controller Area Network, Isolation, Transceiver

CAN for Critical Embedded Automotive Networks

Posted by admin on May 18th, 2009 No Comments

Over the past decade, electronic systems have gradually replaced mechanical ones in cars and trucks. The forces driving this replacement have mainly included environmental demands that require advanced electronic engine and driveline control in addition to reduction of wire-harness size. In the mid-1980s, Bosch and Intel developed a serial network protocol, called controller area network (CAN), and implemented this in silicon chips for supporting hardware. The CAN protocol transfers information between electronic control units (ECUs) in vehicles. In the early 1990s, Mercedes was the first company to introduce CAN in standard cars. Since then, the CAN protocol has proved to be an inexpensive, robust solution for automotive control networks and is now well established and used in all types of vehicles.

So far, however, only non-safety-critical systems, with few exceptions, use CAN. Now, the automotive industry intends to use network technologies for safety-critical tasks such as steer-by-wire and brake-by-wire, often summarized as X-by-wire. It is a common opinion among controller network specialists that such systems should be time-triggered rather than event-triggered and that ECU access to the communication bus must be supervised and controlled by specific entities, called bus guardians. Because CAN does not offer support for time-triggered message transfer or for bus guardians, the industry has looked at other protocols such as the time-triggered protocol (TTP) and FlexRay.

However, a better solution might be to use CAN as a base and then add missing facilities as needed. This technique, in contrast to traditional layered communication services, would lead to a more flexible architecture in which the communication would be integrated into the control system. Then the vast practical experience gained from using the CAN protocol for more than a decade in different environments and applications could be leveraged to provide better services.

Download the article (PDF) at http://www.scribd.com/doc/10760318/can-for-critical-embedded-automotive-networks-micro-ieee?autodown=pdf

You will need to sign up at the scribd.com web site in order to get the document, but they promise they won’t pester you with junk e-mails…;-)

Posted in CAN, Controller Area Network, J1939

Other J1939 Based Protocols

Posted by admin on May 11th, 2009 No Comments

Per definition, SAE J1939 provides serial data communications between microprocessor systems (also called Electronic Control Units – ECU) in any kind of heavy duty vehicles. The messages exchanged between these units can be data such as vehicle road speed, torque control message from the transmission to the engine, oil temperature, and many more.

SAE J1939 and its companion documents have quickly become the accepted industry standard of choice for off-highway machines. It was all too natural that organizations and manufacturers in the agricultural, military and marine industries, rather than re-inventing the wheel, adopted the proven combination of physical layer, Controller Area Network (CAN), and J1939 as the higher layer protocol for vehicles. However, it is in the specific nature of agricultural and military as well as marine applications that slight modifications, including a name change, were necessary.

These “new” protocols are:

  • ISO 11783 (a.k.a. ISOBUS) – Agricultural Industry
  • MilCAN – Military Applications
  • NMEA 2000 – Marine Applications

 ISO 11783 (ISOBUS) 

ISO 11783, a.k.a. ISOBUS, is a CAN (Controller Area Network) Higher Layer Protocol based on the SAE J1939 standard for forestry and agricultural vehicles. ISO 11783 was a joint development by manufacturers in the agricultural and forestry industry to address the increasing needs for electronic control in the machinery/vehicles they produce.

ISO 11783 consists of the following parts, under the general title Tractors and machinery for agriculture and forestry – Serial control and communications data network:

  • Part 1: General standard for mobile data communication
  • Part 2: Physical layer
  • Part 3: Data link layer
  • Part 4: Network layer
  • Part 5: Network management
  • Part 6: Virtual terminal
  • Part 7: Implement messages applications layer
  • Part 8: Power train messages
  • Part 9: Tractor ECU
  • Part 10: Task controller and management information system data interchange
  • Part 11: Mobile data element dictionary
  • Part 12: Diagnostic
  • Part 13: File Server

The ISO 11783 standards can be purchased through the International Organization for Standardization, ISO. Note: The price tags for each document are extraordinary.

The standard is managed by the ISOBUS group in VDMA (http://www.isobus.net). Note: The web site lacks the substance to be taken seriously. The bulk of the little information that exists is based on marketing material and most documents are in German. Technical information is virtually non-existent.

MilCAN

According to the official web site (http://www.milcan.org) : “MilCAN has been defined by a group of interested companies and government bodies associated with the specification, manufacture and test of military vehicles. The MilCAN working group was formed in 1999 as a sub-group of the International High Speed Data Bus – Users Group (IHSDB-UG) when a need was recognised to standardise the implementation of CANbus within the military vehicles community. The mission statement of this newly formed group was ‘To develop, for various application classes in all military vehicles, a common interface implementation specification based on CANbus’.”

Describing the MilCAN standard is not an easy task and the only reason it found its way onto this web site is due to the fact that it is partly based on J1939. It seems that the creators of the protocol tried to satisfy the protective demands of every European member (in this case especially the Germans and Brits) on one side and American companies on the other. One can only appreciate that the circle of members was not extended any further. MilCAN is an inconsistent mixture of CUP, a protocol developed by the German Army (Bundeswehr), SAE J1939, representing the American side, and CANopen, representing the European side.

As a resullt, there are two variants of MilCAN, MilCAN A and MilCAN B. MilCAN A is based on the 29-bit CAN identifier according to SAE J1939, the major difference being that MilCAN A supports deterministic data transfer and accommodates both, synchronous and asynchronous,  data. MilCAN B, on the other hand, is based on the 11-bit CAN identifier and can, at least officially, make use of devices that have been designed for CANopen. Also officially, it should be possible to mix J1939 devices with MilCAN devices on the same bus. 

NMEA 2000

Of all the SAE J1939 derivatives, NMEA 2000 seems to be the only consequent and straight-forward adaptation of J1939.  While taking advantage of a proven and ingeniously designed protocol, NMEA 2000 defines only its own messages.

NMEA 2000 is used for marine data networks providing communication between marine specific electronic devices such as depth finders, chartplotters, navigation instruments, engines, tank level sensors, and GPS receivers.

It has been defined and is controlled by the US based National Marine Electronics Association (NMEA). Information on their official web site (http://www.nmea.org) is somewhat sparse. Another web site, http://www.jackrabbitmarine.com, however, provides in-depth information.

NMEA 2000 is a modernized version and replacement of an older standard, NMEA 0183. It has a significantly higher data rate (250k bits/second vs. 4.8k bits/second for NMEA 0183). It also uses a binary message format as opposed to the ASCII serial communications protocol used by NMEA 0183. Another distinction between the two protocols is that NMEA 2000 is a multiple-talker, multiple-listener data network whereas NMEA 0183 is a single-talker, multiple-listener serial communications protocol.

For further technical information on the SAE J1939 standard log on to http://www.copperhillmedia.com/J1939Book.html.
 

Posted in CAN, ISOBUS, J1939, NMEA 2000

The Foreseeable Death of POWERLINK Version 2

Posted by admin on May 11th, 2009 No Comments

Industrial Networking with CAN and CANopen is currently under increased pressure by Ethernet-based technologies such as EtherCAT, Ethernet/IP, ProfiNet, Modbus/TCP, and others. These technologies provide higher speed, greater bandwidth, and almost unlimited physical network length. One of the contestants in the war for market shares was POWERLINK, a fieldbus technology introduced by B&R – a company in Austria – and maintained by the Ethernet-Powerlink Standardization Group (EPSG).

I never considered POWERLINK a strong candidate to survive the fierce marketing war between the numerous Ethernet-based fieldbus protocols. After all, the battle for market shares is a mere marketing issue and I always had the feeling the promoters of POWERLINK didn’t get the picture. Just to name one example, the “Publications” section of the ESPG web site (http://www.ethernet-powerlink.org) includes documents titled “Selbstentwickelte Spulmaschine”, or “Standardisierung der Netzwerktechnik für Kraftwerk-Leitsysteme” – not very effective to promote the technology world-wide. Note, the web site http://www.ethernet-powerlink.com (.com instead of .org) is hosted by B&R, shamelessly promoting their products based on POWERLINK V1. Also, just for kicks, check out web sites like http://www.powerlink.org or http://www.epsg.org.

The downfall of POWERLINK as a major world-wide standard, however, is ironically the business policy of B&R – the inventor of the technology. Until this day, B&R has consistently refused to comply with POWERLINK Version 2, the standard based on Version 1 and developed by the EPSG (including B&R). As I had mentioned in an earlier entry on this web site (http://www.thecanmancan.com/?p=7) B&R has great success selling their devices based on POWERLINK V1 and I personally believe, they never had any intentions to make the switch to Version 2. I also heard through the grapevine that one of the larger EPSG member companies is leaving the sinking ship and will “defect” to the EtherCAT side (Sorry, can’t release the source of the information or the name of the company – just take my word for it. If you have objections or different information, please feel free to leave a comment).

Last, but not least, let me point to yet another of my entries on this web site: http://www.thecanmancan.com/?p=90. The Online survey mentioned in this entry revealed a very low interest (7% of 160 responses) for POWERLINK and, still, my bet for the North-American market is with EtherCAT (56%)  and Ethernet/IP (19%).

Posted in CAN, CANopen, EtherCAT, Ethernet/IP, Powerlink

Introduction to J1939

Posted by admin on April 29th, 2009 No Comments

J1939 is a higher-layer protocol based on Controller Area Network (CAN). It provides serial data communications between microprocessor systems (also called Electronic Control Units – ECU) in any kind of heavy duty vehicles.

The main advantages of using CAN as a field-bus technology are reduced wiring (CAN requires only two wires between nodes), extremely reliable communication, easy implementation and improved maintenance and service capabilities, which consequently not only produce better vehicle performance, but also help to reduce production costs.

  • J1939-based protocols are used in:
  • Diesel power-train applications
  • In-Vehicle networks for trucks and buses
  • Agriculture and forestry machinery (ISO 11783)
  • Truck-Trailer connections
  • Military vehicles (MiLCAN)
  • Fleet management systems
  • Recreational vehicles
  • Marine navigation systems (NMEA2000)

The protocol features of J1939 are based on two older SAE (Society of Automotive Engineers) specifications:

1. SAE J1708
SAE J1708 specifies on the physical layer of the communication link. It uses RS485 as an electrical layer operating at 9600 baud. (Note: Unlike RS232/485 there are no message collisions under CAN). Messages under J1708 start with a Message Identification Character, followed by the data information and a checksum. The message length is 21 characters (or less) and each data character is 10 bits long. Each character starts with a start bit of low polarity.

2. SAE J1587
SAE J1587 is a joint SAE/TMS “Recommended Practices for Electronic Data Exchange Between Microcomputer Systems in Heavy-Duty Vehicle Applications”. It regulates the communication and standardized data exchange between ECUs based on J1708 networks.

Note: The situation regarding documents/literature on J1708 and J1587 is as dire as with J1939.

The J1939 specification is described by a number of SAE documents, the SAE J1939 Standards Collection:

J1939
Recommended Practice for a Serial Control and Communications Vehicle Network*

J1939-01
Recommended Practice for Control And Communications Network for On-Highway Equipment

J1939-02
 Agricultural and Forestry Off-Road Machinery Control and Communication Network**

J1939-11
Physical Layer – 250k bits/s, Twisted Shielded Pair

J1939-13
Off-Board Diagnostics Connector

J1939-15
Reduced Physical Layer, 250k bits/sec, Un-Shielded Twisted Pair (UTP)

J1939-21
Data Link Layer

J1939-31
Network Layer

J1939-71
Vehicle Application Layer

J1939-73
Application Layer – Diagnostics

J1939-74
Application – Configurable Messaging

J1939-75
Application Layer – Generator Sets and Industrial

J1939-81
Network Management

For an extended overview log on to http://www.copperhillmedia.com/cannewsletter/j1939standardscollection.html

Posted in CAN, J1939

Automotive CANtroller

Posted by admin on April 28th, 2009 1 Comment

This universal microcontroller board was designed, in the first instance, for use by students studying automotive technologies, but it can also be used for other applications, of course. The heart of this board is an Atmel AT90CAN32 with a fast RISC core.

In collaboration with the Timloto o.s. Foundation in the Netherlands, Elektor designed a special controller PCB, which will be used in schools in several countries for teaching students about automotive technologies. Particular attention was paid to issues such as universal design, cost, connection options, expandability and the availability of free development software for various platforms.

The full article plus schematics can be ordered and downloaded at http://www.elektor-usa.com/magazines/2009/april/automotive-cantroller.879015.lynkx?tab=5

Posted in CAN
« Older Entries

Powered by WordPress | Log in | Entries (RSS) | Comments (RSS) | ilookgood! theme by iwritealot!