Monday, October 4, 2010

In this post I will report about my experiences and studies about vehicle electronics.

Last edited on jun 27, 2012

CAVEATS: I found that the generally available informations about this subject on the internet is quite poor and not very clear. While I am trying to do my best in verifying, errors and mistakes could be present.
Please feel free to add your critics and comments.

This is going to be a long term project, so this page will be improved over time.

Cars are complex
Cars are getting complex. Car electronics is really sophisticated, and current cars have dozens of control units for managing devices, sensors, and actions.

ECUs: Elecronic Control Units
The Control Units talk on local vehicle networks, which are similar to a common computer LAN, but based on different protocols.
ECUs, Engine Control Units, were the first to be connected to vehicles network, soon followed by others ECUs (generic Electronic Control Units).
To reduce the amount of signal wires among the many electric components of a modern car, digital communication protocols were introduced, and digital electronic interfaces between every electric device and the communication infrastructure.
The most important ECU is the Engine Control Unit.
Here is a non-exaustive list of Engine Control Unit manufacturers for cars: BOSCH (example: EDC16), MAGNETI MARELLI (example: 95160), SAGEM (example: 95080), SIEMENS (example: TMS374).

Here is a PDF file from the chinese company UIF Technology (a supplier of car electronics and diagnostic devices) with pictures of many Engine Control Units.

STANDARDS: a terrible headache
There are many standards defining protocols, signals, diagnostics.
Here is a probably incomplete and maybe wrong list
SAE and ISO are the most common standard and documents frameworks, but there are many othersSAE is the Society of Automotive Engineers.
SAE defines Communications Standard utilized in On-and Off-Road Land-Based Vehicles. In this schema 3 classes of communicating devices are explained:

CLASS A: up to 10Kbit/sec, multipurpose, asynchronous, used for non-realtime, smart sensors, wire reduction.
CLASS B: in the range 10Kbit/sec up to 125Kbit/sec, used for intermodule data transfer and non-realtime control. SAE J1850 is a CLASS B protocol, currently used for low-cost connectivity between nodes like instrumentation and diagnostic devices.
CLASS C: critical, high speed, realtime communications between device. For these needs, hi-speed CAN is currently used (up to 1Mbit/sec), but there are also faster alternatives, like Flexray (up to 10Mbit/sec, firstly implemented in BMW X7 X6 in 2008 see here).

SAE J1850 describes two different protocols: a low speed single wire VPW (Variable Pulse Width) protocol running at 10.4Kbit/sec and a faster two wire differential PWM (Pulse Width Modulation) protocol running at 41.6Kbit/sec. This is NOT CAN nor is it compatible with CAN.
VPW is classically used by GM (General Motors) vehicles.
PWM is classically used by Ford vehicles.

ISO_9141-2 is not a signaling protocol, but a diagnostic interface to check vehicle component functionality. It is a serial interface that runs at 9.6Kbit/sec. It is often available in OBD-2 connector.

ISO_11992 is a CAN bus used in trucks for communications between the tractor and the trailers.

SAE_J1939 is a set of specification based on an underlying CAN infrastructure, working with 29bit identifiers and usually with a bit rate of 250kbit/sec. This is normally used in trucks and industrial vehicles. It is a prerequisite for the FMS (see forward) system to work. An introduction to SAE_J1939 by Marcus Junger can be found on Vector site here. Other J1939 infos are on can-cia.org,. See also here, and here.
According to wikipedia, SAE_J1939 supersedes SAE_J1708 and SAE_J1587.

Vehicle Networks
Actually there are many vehicle networks, eventually based on different standards, different criticality, different protocols, and different communication speeds. Currently these networks are converging to the CAN standard, but there are many others. Since CAN is now the de-facto standard for vehicle networking, sometimes it is also identified as VDB (Vehicle Data Bus).
Despite its popularity, CAN bus is not the only network inside any modern vehicle, and in a single vehicle there are usually different networks (multiple CAN networks and NON-CAN networks).

CAN
CAN stands for Controller Area Network. It was originally developed by Bosch, starting in 1983. CAN is used in many automation environments and not only in automotive industry.

In a CAN bus all the communicating devices are connected to the same two wires, labeled CAN-High and CAN-Low. All the devices must use the bus at the same speed. At each end, the two wires are connected with a 120 ohm termination resistor. It is not required to have a common ground signal among the communicating devices. Bus maximum length is dependent from the operational speed, and at 1Mbit/sec is about 40m. Vehicle network bus speeds are usually below 500Kbit/sec. High speed bus vehicle implementation often adopt twisted pair wires.
In a normal situation, the two wires carry a two-level signal, perfectly specular, and whenever one is high the other is low. Here are two nice pictures (source: picoauto.com ) representing oscilloscope reading of the two wires of a CAN bus. The second image allow a clear understanding of the specular nature of the signals.

From these pictures, the different logical values of the signals can be read, and here each signal has a span of about 1V. In the upper picture, a full CAN packet transfer is visible. The overall packet transfer time is about 200ms (320-120).

Actual CAN bus voltages are not usually this neat.
Here is an actual example (this too from picoauto) (Voltage references seem nonsensical in this picture).

The CAN Protocol
Currently there are two main version of the CAN protocol
Standard CAN: 2.0A with 11bits identifiers
Extended CAN: 2.0B with 29bits identifiers
CAN is defined in ISO_11519 and ISO_11898.

ISO 11898-2 defines the high speed CAN, up to 1Mbit/sec

ISO 11898-2 high speed

ISO 11898-2 is the most used physical layer standard for CAN networks. It describes the bus access unit (implemented as CAN high-speed transceiver) functions as well as some medium-dependent interface features.
In this standard the data rate is defined up to 1 Mbit/s with a theoretically possible bus length of 40 m at 1 Mbit/s. The high-speed standard specifies a two-wire differential bus whereby the number of nodes is limited by the electrical busload. The characteristic line impedance is 120 Ohm, the common mode voltage ranges from -2 V on CAN_L to +7 V on CAN_H. The nominal specific propagation delay of the two-wire bus line is specified at 5 ns/m. All these figures are valid only for a 1 Mbit/s transfer rate and a maximum network length of 40 m.
In order to achieve physical compatibility all nodes in the network must use the same or a similar bit-timing. For automotive applications the SAE published the SAE J2284 specification. For industrial and other non-automotive applications the system designer may use the CiA 102 recommendation. This specification defines the bit-timing for rates of 10 kbit/s to 1 Mbit/s. It also provides recommendations for bus lines and for connectors and pin assignment.

An alternative form of bus interfacing and arrangement of bus lines is specified in ISO 11898-3 (fault-tolerant CAN). This standard is mainly used for body electronics in the automotive industry. Since for this specification a short network was assumed, the problem of signal reflection is not as important as for long bus lines. This makes the use of an open bus line possible.
This means low bus drivers can be used for networks with very low power consumption and the bus topology is no longer limited to a linear structure. It is possible to transmit data asymmetrically over just one bus line in case of an electrical failure of one of the bus lines.
ISO 11898-3 defines data rates up to 125 kbit/s with the maximum bus length depending on the data rate used and the busload. Up to 32 nodes per network are specified. The common mode voltage ranges between -2 V and +7 V. The power supply is defined at 5 V.
Transceiver chips, which support this standard, are available from several companies. The fault-tolerant transceivers support the complete error management including the detection of bus errors and automatic switching to asymmetrical signal transmission.

The preceding two quotes of text about CAN physical layer specifications are taken from here (fetched on dec 4 2010): http://www.can-cia.org/index.php?id=517
Also there are other physical layer standards.

The following section is shamelessly copied from Staffan Nilsson web page
(with some corrections)

-----------------------ISO 11898-2 voltage levels (CAN High Speed)

Signal

recessive state

dominant state

unit

min

nominal

max

min

nominal

max

CAN-High

2.0

2.5

3.0

2.75

3.5

4.5

Volt

CAN-Low

2.0

2.5

3.0

0.5

1.5

2.25

Volt

Note that for the recessive state, nominal voltage for the two wires is the same. This decreases the power drawn from the nodes through the termination resistors. These resistors are 120ohm and are located on each end of the wires. Some people have played with using central termination resistors (that is, putting them in one place on the bus). This is not recommended, since that configuration will not prevent reflection problems.

ISO 11519 voltage levels (CAN Low Speed)

Signal

recessive state

dominant state

unit

min

nominal

max

min

nominal

max

CAN-High

1.6

1.75

1.9

3.85

4.0

5.0

Volt

CAN-Low

3.1

3.25

3.4

0

1.0

1.15

Volt

ISO 11519 does not require termination resistors. They are not necessary because the limited bit rates (maximum 125 kB/s) makes the bus insensitive to reflections. The voltage level on the CAN bus is recessive when the bus is idle.

Bus lengths
The maximum bus length for a CAN network depends on the bit rate used. It is required that the wave front of the bit signal has time to travel to the most remote node and back again before the bit is sampled. This means that if the bus length is near the maximum for the bit rate used, one should
choose the sampling point with utmost care - one the other hand, one should always do that!Below is a table of different bus lengths and the corresponding maximum bit rates.

Bus length (metres)

Maximum bit rate (bit/s)

40

1 Mbit/s

100

500 kbit/s

200

250 kpit/s

500

125 kbit/s

6 km

10 kbit/s

Cables
According to the ISO 11898 standard, the impedance of the cable shall be 120 +- 12 ohms. It should be twisted pair, shielded or unshielded. Work is in progress on the single-wire standard SAE J2411.

-----------------------

CAN frames
Here are some informations about CAN data frames
the following picture is from http://www.jcelectronica.com/articles/CAN%20bus%20tutorial_2.htm
The Standard and Extended frames are shown, and the different address field length can be seen.

CAN reliability
CAN bus communications are usually very reliable, quite insensitive to external interferences (since external interferences affect similarly both wires, the difference between the voltages remains unchanged), and to single control unit fault. The devices can often work even in case of bus being severely miswired (one cable shorted to ground or to vcc). No need of a common ground also increases robustness. This reliability is among the properties that made it the current standard in difficult environments, with wide temperature ranges, and very varying environmental situations.

Detecting CAN
Since there are many wires, it is not easy to identify the proper ones.
0.CAN signals are usually not present if the key is not turned to power the dashboard. (It is normally not needed that the engine is powered).
1.CAN wires are usually twisted.
2.Checking CAN signal presence without the use of an oscilloscope: A simple test to see if the bus is operating correctly is to use a multimeter and measure the voltage between the two wires. In "perfect" situations, if the bus is active and working it will show a steady 2.5V or 0,5V (in absence of signal changes), or a quick alternance between 0,5 and 2,5V. If not working it will be 0V as one of the CAN controllers on the network is pulling the bus low (known as Bus Off).
3. Operating with a two channels oscilloscope, and using the subtract function between the two signals CAN-H and CAN-L, you should get a constant (because the two signals have opposite phases). Oscilloscope can also help in detecting the speed of the CAN bus signals. (will add details here).
4. An indirect CAN presence indicator could be testing for proper termination. Proper termination of a CAN bus can be easily tested with a multimeter: when the bus is not used, a resistance of 60ohm should be measured between the two cables (the two 120 ohms terminators in parallel at each side give a global resistance of 120/2=60 ohms).
5. As a useful tool for CAN detection check the Würth CANfinderdevice.
6. CAN signals could not be present where they should be (i.e. in the OBD2 connector) if a proper setting is not performed on the gateway device.

Interfacing with CAN
In term of circuitry, every device connecting to CAN bus usually interfaces via a CAN Controller, which in turn acceses the bus via a CAN line driver (actually a transceiver).

The CAN controller actually speaks with the device in some way (for example via a serial RS232 interface) and on the other Many manufacturers produce CAN line driver integrated circuits, for example Dallas Semiconductors/MAXIM MAX13050 or Microchip MCP2551.or Philips PCA82C250. or Philips/NXP TJA1054

The following picture shows a generic CAN bus with some devices connected. Proper bus termination should be present at each bus end to damp electric signal reflection (echos). Also it is important to minimize length of the connection between the bus and the transceiver of each connected device (for minimizing undesired echo effects).

Modules are sets of ECUs
In a vehicle, a Module usually identifies a set of two or more Electronic Control Units.
Engine control being the first and most critical, the corresponding Control Units are the most complex. Engine Control Unit (ECU) is supported by Transmission Control Unit (TCU) and the two are sometimes referred as Powertrain Control Module (PCM). Transmission Control Unit, among other things, takes care of gear shift.

User related Electronic Control Units are often referred as a whole with the term Body Control Module or BCM .

Different Networks
The different criticality of the signaling among the vehicle electronic devices, created a push for insulating the networks of different modules, for security needs, but also due to different equipment interfaces being at different speeds.
These different networks are grouped in 3 main classes:

Some of these vehicle networks can also be non-CAN. There are other standards used in vehicle networks, like LIN (used for low cost, low speed, non critical use, see also here), FlexRay (used for high speed, critical needs, in BMW SUVs), MOST (Media Oriented System Transport) for multimedia and infotainment.

Bus Separation

Engine Control, Airbag, Braking subsystem, Speed control and ABS, are the most safety-critical systems, require high speed, and therefore are usually kept separated from less critical systems.

The separation between the different CAN buses allow much more resilience of the critical systems in the case a noncritical control unit fails (the car engine still starts if you have a problem in the cd-player or in the cabin lights).

Gateways between different networks
In most vehicles, many CAN networks are there, operating at different speed, and that there are gateways allowing data being transferred among the different buses.
The presence of these gateways allow filtered transfer of information, along with eventual speed change. A gateway could act as a firewall allowing only the propagation of specific packets. Gateways are actually electronic devices connected to more than one bus, and can be programmed to allow packet filtering.
There is a interesting specification called Pass-Through SAE J2534-1 which is designed to allow a sort of common protocol (!!vendor and brand independent!!) for traversing in-between bus gateways (CAN and not CAN). This standard should be supported on all vehicles manufactured after 2004. Pass-through specification is targeted to reprogramming and re-flashing of individual electronic control units, but allows also read and write I/O, and periodic messages definition. There is also a set of defined APIs (Application to Program Interfaces) thru which the dialogue can be implemented.

"This SAE Recommended Practice provides the framework to allow reprogramming software applications from all vehicle manufacturers the flexibility to work with multiple vehicle data link interface tools from multiple tool suppliers. This system enables each vehicle manufacturer to control the programming sequence for electronic control units (ECU's) in their vehicles, but allows a single set of programming hardware and vehicle interface to be used to program modules for all vehicle manufacturers. This document does not limit the hardware possibilities for the connection between the PC used for the software application and the tool (e.g., RS-232, RS-485, USB, Ethernet...). Tool suppliers are free to choose the hardware interface appropriate for their tool. The goal of this document is to ensure that reprogramming software from any vehicle manufacturer is compatible with hardware supplied by any tool manufacturer. The U.S. Environmental Protection Agency (EPA) and the California Air Resources Board (ARB) have proposed requirements for reprogramming vehicles for all manufacturers by the aftermarket repair industry. This document is intended to meet those proposed requirements for 2004 model year vehicles. Additional requirements for the 2005 model year may require revision of this document, most notably the inclusion of SAE J1939 for some heavy-duty vehicles. This document will be reviewed for possible revision after those regulations are finalized and requirements are better understood. Possible revisions include SAE J1939 specific software and an alternate vehicle connector, but the basic hardware of an SAE J2534 interface device is expected to remain unchanged."

Such a device is indeed a firewall with sophisticated packet content filtering and rewriting capacity.
Here is a document describing a CAN gateway device in a Volkswagen Golf car
The following two paragraphs are taken from http://www.my-gti.com/2296

The role of the Gateway (also known as the Data bus diagnostic interface J533) is the exchange of data between the CAN data bus systems (‘powertrain CAN data bus’, ‘convenience CAN data bus’ and ‘infotainment CAN data bus’) and the conversion of diagnostic data from CAN data bus systems to K-cable and vice versa so the data can be used by vehicle diagnosis, testing and information systems like the dealer VAS tools and Vagcom/VCDS.

For various reasons including power drain issues with third generation head units or the addition of new unsupported modules the CAN bus gateway must be upgraded to a newer revision. This guide covers the replacement of the CAN bus gateway in a 2005 MY06 Volkswagen Golf GTI. The upgrade replaces the 1K0 907 530 E (1K0907530E) with a 1K0 907 530 AA (1K0907530AA).

This gateway in Volkswagen terms is called "Data bus diagnostic interface J533". It is used in many car models from this vendor. I found an Audi technical document (from Audi A5 owners group website Audi_A5_-_Networking_en_2.pdf) describing the 4 different version of this gateway component (differences are in terms of its interfaces), for different car models. It is connected to many different buses (different CANs, LIN, MOST). The document states that the "transport mode" can be activated on demand. I guess that this transport mode could allow flow of information between the different buses thru the gateway itself (that in this mode acts somewhat like a router).
Check also this webpage about J533 gateway.

OBD: On Board Diagnostic
Due to the progressive diffusion of electronic devices in the vehicle industry, also diagnostic procedures started to rely on querying these different pieces of electronics, for troubleshooting, and parameter tuning.
The On Board Diagnostic (OBD) standards define how these diagnosis can be performed. Each Control Unit has a set of Diagnostic Trouble Codes (DTC) that can help in identifying its status or eventual failures.
Actual diagnosis is performed by a technician connecting a probing device to a specific plug inside the vehicle, and performing analysis.
In many vehicles, the OBD connector (currently usually compliant to OBD-2 standard) is within reach from the driver seat, and allows access to at least one of the vehicle CAN buses.

Over the years, many different versions of the OBD standard appeared, and the most current one is labeled OBD-2 or OBD-II, which uses a female 16-pin (2x8) SAE J1962 connector on the vehicle. Here is the pinout of its female connector (from wikipedia).

Specific gateway configurations could be needed so to allow specific Electronic Control Units traffic (filtering) to be available on the OBD-2 CAN interface. Also, depending on the manufacturer and model, CAN bus availability on the OBD-2 connector could require a specific configuration elsewhere (maybe jumpers in the circuit breaker panel).
Being present in many vehicles, the OBD-2 connector usually allows access to many diagnostic signals. Sometimes more than one CAN bus is made available on the connector, on different pins.

Some "rules" about the OBD-2 connector
(info from http://www.auterraweb.com/obdiipinout.html and http://www.obd-ii.de/tech_conn.html )
If pin 5,6,14,16 are connected, the pins 6 and 14 are CAN-HI/LOW (ISO_15765-4 / SAE_J2284), while pin 5 is ground and pin 16 is 12Vcc
If pins 5,7,16 and optionally 15 are connected, the connector supports access to ISO_9141-2 (aka KWP): pin 5 is ground, pin 16 is 12Vcc, pin 7 is ISO-data (aka ISO_K-line), as well as optional pin 15 which is older ISO_9141-2 (aka ISO_L-line).
If pins 2,5,16 are connected, the connector supports access to VPW_J1850: pin 5 is ground, pin 16 is 12Vcc, and pin 2 is VPW-data

If pins 2,5,10,16 are connected, the connector supports access to PWM_J1850: pin 5 is ground, pin 16 is 12Vcc, and pin 2 and 10 are PWM-data

Connector Pins 1,3,8,9,11,12,13 (if connected) are used differently from different vehicle manufacturers, and the OBD-2 standard does not define their role.

Accessing CAN bus in cars
When CAN bus is not available in the OBD2 plug or it is not feasible to connect to that plug, or if the gateway is not "publishing" the CAN signals on the OBD2 port, the bus can be accessed simply connecting to its wires.
But a disclaimer is needed:
In most cases, car manufacturers are not disclosing the specifications of their diagnostic systems and there are no easy approaches that are consistant across the different brands. Even if you are able to access CAN signals, it will not an easy task to decode and understand the meaning of the data packets. Here is a guide (prepared by uk company Racelogic) in finding the right wires in different vehicles. Devices like the aforementioned Würth canfinder can also be useful.

An unshielded two-wire line (1) and (2) with a cross section of 0.35 mm² or 0.5 mm² is used for CAN bus wiring.
The colour codes of the CAN bus wiring are:Powertrain CAN high wire Orange/blackConvenience CAN high wire Orange/greenInfotainment CAN high Orange/violet
CAN low wire, (all) Orange/brown

For Peugeot (/PSA and probably for cytroen) cars, check this site: http://peugeot.mainspot.net/ where you can find accurate information and Complete Wiring diagram for Peugeot307, along with information about BSI (Body Control: Built-in System Interface)

This FMS (Fleet Management System) standard is very important for allowing access to specific truck information like the tachometer and odometer, which are needed to be read in the devices to control the driver activity (digital tachographs). FMS requires a SAE J1939 CAN 29-bit 250kbit/sec underlying standard.

For european digital tachographs, check http://www.dtco.vdo.com
In order to be compliant with FMS standard, truck manufacturers implement a specific gateway ECU which reads the informations required by the standard from all the suitable places and thru all the required standard, complying with internal vehicle-brand-specific protocols, and makes all these informations available thru a specific CAN bus to which the tachometer device is connected.
In this way, an FMS compliant digital tachometer devices can be easily connected to any FMS compliant truck.

Different connection cables

(this section needs work and it is partially outdated by what I wrote in the OBD-2 connector section)

A number of different ready made cables exist to access car diagnostics, usually via the aforementioned ODB-2 connector
here is a list of their names, but I am far from understanding their differences

K-LINE and L-LINE (ISO 9141-2) (to be explained: i need to study)
ISO 14230-4 (also known as KWP)

PWM CAN
HS-CAN (iso 15765)

VAG-COM is not a cable, but a product by Ross-Tech. It is a diagnostic windows software for Volkswagen/Audi. Some cables to be used with this software are labeled VAG-COM

ELM 32x are integrated circuits, (here is elm327 description), sold by elmelectronics.com and based on Microchip Technology Inc. raw devices. These ELM chips act as generic ODB2 decoders and are able to identify and decode many of the different signals available on the ODB2 plug, converting them to RS232, suitable for connection to a PC. Many different PC diagnostic software are capable of interfacing with car electronics via an ELM based adaptor, like this

(To Be fixed)

Arduino and CAN
It is possible to interface an Arduino 2009 board with CAN bus, via a specific CAN shield
I successfully used SkPang Arduino CAN-Bus Shield, to connect to an Audi A6 (2003) and I was able (using the provided sample application) to successfully read RPM (revolutions per minute) data from the engine using a polling mechanism.

This shield uses a MCP2515 CAN controller and a MCP2551 CAN line driver.

Here is a typical configuration of MCP2551

We are currently working on improving the code provided with the shield so to have more sophisticated functions.

MPGuino
This project is targeted to build a fuel measurement computer, with an Arduino like device, analyzing the impulses to the fuel injectors, and having tables for calculating the specific fuel injected basing on impulse duration. The signals have to be directly read/taken from the main engine ECU connections to the fuel injectors. Data appears extremely accurate. Here is the link: http://ecomodder.com/wiki/index.php/MPGuino

Teltonika FM4200
This is a device specifically designed to interface with FMS CAN interface in trucks.
I am also testing this device, which uses a NXP LPC2368 microcontroller which is (incidentally) the same uc used by the mbed project. Here is some info about the microcontroller which includes a CAN controller (but not a CAN transceiver). The FM4200 circuits utilizes a Texas Instruments SN65HVD234D 3.3V CAN transceiver. I will write more about this device, as soon as I will have performed more thoroughful tests.

General References and links
The great CAN-CIA site: http://www.can-cia.org/ which is probably the best and more reliable reference site available.
The CAN dictionary: contains a definition of most of the acronyms and abbreviations.

Software
FreeDiag: http://freediag.sourceforge.net/
FiatECUScan is a software for analyzing Italian made cars (fiat/alfa/lancia branded). Comes in free version and in paid version, with different features. http://fiatecuscan.net. Here is a list of the vehicles supported by current version of FiatECUScan.

FAQ: Q&A
Here are some questions I received by email and the answers I sent.

Q: Is it possible to read value of XXX connecting to the can bus of my car?
A:As quick answer I would just say that it is not possible.

But this impossibility is normally not due to physical reasons. Each ECU manufacturer uses its own set of rules & codes to craft data packets on their vehicles networks. These informations and data formats are not readily available, and there are no shared rules followed by different manufacturers.

Fm4200 is designed to be able to decode FMS CAN, which is a standard data format representation accepted and shared by all industrial vehicles (trucks). The target is to allow tachometer interconnect with vehicle dashboard.

Tachometers are devices that in many countries MUST be installed on trucks so to monitor driver behavior and work activities. Since there are many tachometer devices, which are built and installed by many countries certified suppliers, a standard was needed, so FMS was born. Non-professional access to tachometer data connection is generally prohibited.

Thru car databus reverse engineering techniques, mostly based on trial and error and/or leaked informations, it is theoretically possible to map some of the CAN data packets to their meanings. Generally read only approach is safe. But problems could arise when vehicle software maintenance is performed, because data packet meaning could change, and current manufacturers are not expected to openly disclose these details.

Write access to the drivetrain and engine bus is to be considered critical and is generally explicitely forbidden or strongly not recommended.

For sure it could be great if all the data was understandable and accessible, but there are important security implications if people irresponsibly tamper with these things. Vehicle security, insurance coverage and road safety could be impacted.

So, be careful and play always on the safe side.My suggestion is to NEVER connect untrusted devices, unknown or potentially unreliable closed source software to critical systems.

83 comments:

Hello Mr. Marco Gaurdigli. First off I'd like to thank you for the detailed and interesting article. I already have an Arduino board and I'm considering buying a SkPang Arduino CAN-Bus shield. Initially I'm interested in reading RPM data. I know there are cheaper ways to read RPM, like from magnetic disturbance in 12v signal but it's not as precise as reading the CAN. Also, learning how CAN works may be really useful for future projects. My concern is that I need to read RPM from different vehicles without having to implement a new code to each car. Is it possible? Regards, Marco Correa

I agree with you that best way to read RPM data is from vehicle digital body bus. On which car models are you working?

I personally tested SkPang Arduino CAN-shield on on an Audi A6 car and it works exactly like is shown in the video in its website. It went smooth at first try, showing RPM and engine temperature.

We tried it also on the Volkswagen Fox, Mercedes E270which are cars we have access to, and are equally equipped with OBD-2 connector, but on these cars nothing is output. The device turns on, power is present, displays works, but it fails to communicate with ECU, and does not read anything. We tried to tune the arduino code, and also studied carefully the MC Microchip library, but without results.

Our current hypothesis is that CAN bus could not be available by default on OBD-2 pin 6/14 of these cars.

We are going to test this hypothesis with the aid of an oscilloscope. I ordered a Rigol scope from DXExtreme, but after 2 months I am still waiting for it. (It seems that it is stuck in the customs somewhere and we are trying to release it).

Thanks for your reply. Actually, I'm not working on any cars now. But when I start my project it should be able to work on virtually any car compliant to ODB2.I'm not used to ODB2 and I've just begun to learn it.I didn't get why it doesn't work on VW Fox, which I guess is assembled here in Brasil.I'm also interested in that scope. I regularly buy many stuffs in Deal Extreme and it usually doesn't take that long to arrive.

Sukkin from SKPang just replied me. He told me that he sent you an email yesterday in which he asks you to get a CAN-Bus analyser to look at the signals. He also said that he doesn't have access to VW Fox and Mercedes E270 and that they might now be fully ODB2 compliant.

Yes, Mr. Sukkin sent me some hints, and definitely I will try them as soon as possible. I am back from a trip in the Balkans, and will leave on monday for Prague. Please do not expect immediate feedbacks.

Hello Marco!You have compiled lots of CAN related useful information here. Congratulations! :)Do you know if it is possible to read other protocols besides trucks' FMS (e.g. Mitsubishi's or OBD2), using FM4200?Thanks in advance and best regards,Helder Alves

To my knowledge the Teltonika FM 4200 device is able to connect to FMS compliant truck can-bus.

In my opinion, other diagnostics coming from OBD-2 interface (whatever the protocol or pin) can be collected thru it, but an interconnecting interface is needed, so to bring specific information on one of the FM4200 analog or digital input ports.

One of my colleagues in Latvia is working directly with a Teltonika guy who designs the firmware, so I could direct to him a more specific question from you, if needed. Let me know something more about your design.

Hello Marco.I am currently trying to trace the cause of a 00470 code on a 2005 Jetta. I thought that the VW/Audi gateway, the same as the one pictured in your article may have been at fault. I looked at the data on the Comfort System bus and both high and low looked OK, ie. there was no short in either line. This does not have directional headlights. I read on IATN that these could be an issue.I replaced the gateway today. I bought one from the dealer, but was unable to longcode it. I believe that it was because it has a trouble code. Data Bus Fault, I think it was.I checked the three power and two grounds at the gateway. I am using a Launch scanner which seems to be capable at doing the long code. I used a Vision II to look at the data signals. The CAN signals don't look very strong at the DLC as they do on the comfort system bus wires. I lost communication to the Launch at one point but it returned soon after so I was able to print out the Long Code data.I am lucky that the place where I work is allowing me extra time to solve this.The initial complaint was battery drain. I believe that the comfort system was not allowed to go to sleep. I also have an issue with the alarm horn which I found is drawing some current but I so far haven't been able to inplug it since it and it's protective housing is riveted to the body above the right inner fender liner behind the shock tower.So. I thought that perhaps you could give me some direction in how to diagnose this not just for this one time but for other times I might run into similar problems.Your's truly. Larry.

However, that has lead me onto my next problem. When connected to my car (2003 Citroen Saxo VTR) I dont recieve any data across the can-bus. I get to the screen 'Can init ok' and then can get no further. I have tried modifying the program quite a few times only to get the same result.

Alex,Unfortunately I am not able to help you with a direct hint. You should check with an oscilloscope or with a CAN analyzer if there are the CAN signals on your SAXO OBD2 socket. It can be that CAN packets are absent unless some signal is injected in the car electronics via some Citroen tool. Re-read my notes about gateway devices. Try to get an oscilloscope or a CAN bus analyzer and check if you have CAN data on your OBD2 port.

Hi Marco, I first apologize for not being into programming at all when I'm asking you the following: Do you think it would be technically possible to convert Canbus data to MIDI data thru the Skpang CB Shield and specific programming? Imagine a live stream of data where a single and identified event running non the Can is translated into a mapped MIDI event such CC or MIDI Note etc.. I know it might sound silly but i'll tell you this would be of great interest for some multimedia project i'm working on with the Plymouth UNI. As i can get from your discussion these opportunities are actually locked to the step of intercepting CB data.. I'm i right? Considering the Arduino abilities for MIDI do you think that a specific programming for the conversion would be a major effort? Thank you for your article a for your attention. Regards. Diego

If I get it right, what you are asking is to traduce the reading of some variables accessible thru CAN bus in MIDI data. Of course this can be done, but we need to figure out

1) what to read 2) how to perform translation 3) maybe how to "detect" specific events and perform predefined MIDI sound sequences.

As an example, you could read the data from the engine route per minutes, and also the temperature of the engine oil, or the speed in km/hr. You could then build some translation functions between a variable reading and a corresponding MIDI output. You could generate sound of changing peak creating a correspondance between sound peak and engine RPMs. Or you could have brake lights generate some sound, and maybe have a music "beat" in time with windscreen wipers speed.Such a thing would not be easy to debug. And also would be a little risky.

Feasibility and security issues nonwithstanding, I guess that you can find easier and funnier ways to generate music from reality readings performed by sensors connected to an Arduino.

Your Arduino MIDI music box could easily read ligh, sound, temperature, humidity, vibrations, compass heading and if you desire even your kitchen sink water level, without having to mess with CAN reading.

hi Marco, Thank you for your prompt answer. I Got your point. The purpose of my project is to build an "augmented reality" UI experience on the vehicle, performing basically the same thing is done when you, for example, choose the Mac OsX to play a sound when a window is opened or the light level of the screen is increased etc.. Imagine that when you close the side window of the car or turn the starting key etc.. With this idea in mind any possible event running on the CAN-bus could be useful if not necessary. What i'm looking for is a shield/software tool allowing the Arduino to perform the CAN-bus to MIDI translation on a flexible mapping basis. I'm thinking about a tool where a common user is able on a friendly sw interface to route a specific CANbus event/signal to whatever MIDI event/channel he wants. So the example you did: "brake lights generate a sound or play a sample" it perfectly fits the point but this "relation" has to be mapped by the user without operating on the deeper lever of the arduino but on a specific mapping sw interface, so that the system is flexible and can grow as you recognize new logical relations between a car event and a distinctive sound event. I dunno if it's clear maybe it needs some more explanation. Sadly, I'm not even that much aware of typical arduino capabilities.. I do agree that readings could be performed by arduino sensors but i've got too many applications in mind that are strictly related to CANbus data. Sorry for my poor tech competences.. Could you possibly point me to someone who could be interested in help me further with this? thanks a lot..

My opinion is that Arduino is not a sufficiently powerful platform to take care of efficient event to sound translation, neither it is able to directly drive a good audio output suited for your project.Arduino and CANshield could work as an interface to CAN, and maybe re-route on a bluetooth channel the data you are interested in, towards another application, maybe on a tablet or on a smartphone, that could perform sound mapping, drive an interface, a screen and so on.

I suggest you to think and clarify your ideas as much as possible, before trying the implementation.

Work to describe your project in a few lines, without too many technical terms, stating what you want to do, and which could be usage target.

It is not a problem if you are not into hacking or programming, if you know what you want and how to explain it.

The skpang arduino shield demo code doesn't setup and filters or masks on the mcp2515. On many german cars the canbus on the diag port get tons of traffic as soon as the key is turned on...

I glanced at the code in the sk-pang example and it looks like it would not properly handle a bus with lot's of messages already on it.

It seems like VW's diagnostic gateway keeps the obd2 port somewhat quiet compared to the car I tested on (2010 BMW). Hence the demo code worked on my vw, but not on my bmw... even though both are the same 500k 11-bit canbus and the commands and ID's ARE correct.

It would be best to set a mask and filter in the mcp2515 (which, sk-pang stripped those functions out of the mcp2515 library they modded, so you would need to re-add them) to only allow messages from 7E8 (which the ecu will reply on) and then it will work on many more cars...

Then there is the issue of 29bit vs 11bit. The sk-pang code assumes 11-bit id's are used... a 2010 honda for example uses 29bit id's and would need the code adjusted accordingly. An auto-detect function would be pretty easy.

No problem... I've used the mcp2515 with AVRs for a while... I do obd requests much differently than skpang does.

Basically I have 6-7 PID's that I ,by using a hardware timer triggered function, request at different intervals. for example, RPM would be requested 5 times per second, but I only request coolant temp once every 2 seconds. I then use an actual pin triggered interrupt handler (because the filters only allow obd responses) to parse each PID reply as it comes in. The interrupt is triggered when a message from 7E8(on 11-bit) passes the filters, then I just do a switch case on the PID response to parse it and save the updated variable to the globals for those sensor values. This way I can run whatever code I want in the main loop and canbus hums along in the background without missing a beat (and without halting the rest of my program to wait for an obd reply)

The receive interrupt from the mcp2515 also works nicely to wake the AVR from sleep mode when canbus activity starts up...

Hi Marco Could you help me with this please?I have an audi A6 2400cc model 2004, engine code BDV.

I have an engine failure , somotime ..when engine hot , doesnt start.

I wanted to retrieve the DTC butThe vag diagnostic does not comunicate with the ECM.I checked continuity from the vag connector to the ECM connector , found one wire going to the ECM. the second one does not .

I am in the process of sourcing LED lighting for automotive aftermarket applications. I see that many European applications require Canbus technology or the use of a load resistor to eliminate hyperflashing or burnt out bulb indications. Can Canbus bulbs be used in non Canbus vehicle applications with out adverse effects?

@DebrajWow! Your project is great! Bravo!I would suggest you to publish on your page a diagram showing all the connections, and also the future extensions you are planning, like the datalogging features on sdcard.Keep me informed!

Great article. I'm considering an arduino based project to make an alternative multifunction display for my Peugeot 307 2003 to show speed, rpm, etc however I was of the understanding that Peugeot uses VAN and not CAN protocol - any ideas either way?Thanks, Trevor.

No, unfortunately I do not know the codes you are asking. I also think that they will be different, also within the same brand, depending of the specific ECU model and firmware used, which is different from model and model, and also changing over time.

You can perform tests with an analyzer, and connect it in the right place to be sure to access the right bus at proper speed.

I am just trying to read the basic can messages via obd2 or I can directly tap the can-h and can-l (eventually want to do that) of my 2007 VW Passat which does have CAN. I have an Arduino uno r3 and the can-bus shield mounted on it. Every time I mounted the shield on my uno my serial monitor would freeze up. I tried it again without the reset pin attached and it doesn't freeze anymore but I still don't get what I want.

1)I read somewhere that you need to attach the reset of the can-bus to 5v. Is that true?

I can't read anything from my obd2. Should I be running a specific program on my arduino? I tried the analogserialread and the serialcallresponseascii (which seems like the best option) and nothing gives me anything to work with.

When I try and run the joystick demo with the fixed digitalwrite(up, high) etc... I don't get any serial response when I move the joystick in any direction...I tried changing the pins to the A1, A2, etc and that didn't work either.

I replaced my atmega microcontroller that's on my uno because I thought I heard that short out when I tried to attach the simple 5v, gnd, canh, canl on the shield...Still nothing...

I just need some direction as this is my first arduino/microcontroller experience.

Rob, as a first test, I would suggest you to power your arduino and shield with a independent power supply, and not using USB as a power source. Maybe your problem is related to insufficient available power.

I am very new to CAN-bus and have very little programming experience. I am trying to use sparkfun's CANbus shield along with the arduino uno micro controller to read the diagnostics(RPM, speed, etc)of my Toyota corolla. Do you have any suggestions to how I should go about doing this or where I should start because I am beyond lost on the subject.

Hello Mr. Marco Gaurdigli.do you know if it is possible to use CAN-BUS shield to make communication between arduino uno. and plc(programmable logic control )for automation .If you take in your account my own plc has can-bus capapilty already.

@SKYyes, it should be possible, crossing the gateway device, but every car requires specific packets to be injected to "open the door".

A polish company called Quasar Electronics produces and sells a interfacing box that is able to read several data from a set of supported vehicles. Depending on what you need, your car might be supported.

Thanks for the quick response. Waiting for activation from Quasar Electronics.

My car is Seat-Leon (my2012)

have the information received from the "comfort bus".Is it enough to send diagnostic port this code?comfort bus is 100kbits.diagnostic canbus 500kbits.What should be the speed?also,for example;"open door" command is data-frame or remote-frame?

Hi, Marco. Thank you for the article, i found it very interesting. I'm interested in making device that will "sniff" obd2 traffic & send modified packages to another can receiver. is it possible to do it with CAN-BUS Shield for arduino from skpang? I assume i will possibly need two of them to use as a gateway, but was not sure if it can establish fully functional can line of communication.

The article is awesome and it gave lots of clarity to me, as I am new to this field.

I have two specific questions I would like to clarify.

1. I am trying to use Teltonika FM4200 device to read the CAN data. But as I understood from this article, I might need another device to decode the data. Is this right? Since Teltonika does not tell anything about it in their manual.

2. I have a Suzuki WagonR car. When I checked the OBD II port I found only 5, 7 and 16 are connected. From this, can I confirm that this vehicle does not use CAN?

Thanks for the information in article and hope I could get some answer.

@Andrey Smirnov, sorry for late reply. Yes it is technically possible, and yes, if you need to perform can to can translation, you will need two serial interconnected arduinos, each with a can shield. Depending on the speed, and of your translation function computational requirements, it can be you would not be fast enough to keep on with the packet rate.

1) Teltonika FM4200 offers a CAN bus interface capable of reading FMS packets over CAN. FMS is a CAN based standard that was developed for trucks. CAN is a network layer specification, like ethernet. You do not assume that every packet flowing on a network is obeying the same set of rules (i.e. protocol).Translation devices (like aforementioned QuasarElectronic's) allow translations from vehicle-proprietary-protocols-over-CAN to FMS-over-CAN, so that you can use FMS/CAN compliant devices (like Teltonika FM4200) to identify and process them.

2) The fact CAN bus is not terminated in your OBD2 port does not mean your vehicle does not use CAN.

Hallo Marco, I bothered you years ago with some question on possible CANbus to MIDi conversion. The idea restarted to gain our interest. We prepared a basic note to explain it. The scheme is simple CANbus>OBDShield>Arduino>MIDIShield>PC+DAW software for sound generation. We are now looking for someone to seriously try to do the thing for us. Could you help me? How could I send you our note? Would you point me to someone skilled on this matter? Thank you for your kind attention. have a nice day. Diego

@DiegoSend me via email the note you prepared, as well as some description about the features you would like to build. I will check then reply to you privately. Also add a brief description of you and let me know where you are based.

Hello Marco, congrats for yr interesting site. You have explored a lot in car electronics.

Maybe you can help me with this Project: I need to quantify fuel consupmtion in real time (by sampling) of my Mercedes Diesel car. It has a Electronic Disel System control unit (EDS N39) part # 012 545 45 32. I want to know if the output signals of this unit are pulses or continuous. I can send you many connecting diagrams but don´t have the internal circuit of the unit.

Nice article. I have a couple of questions about the J1850 PWM bus as used by Ford in the early 2000's:With the PCM module removed and the vehicle is probed with an ohmmeter from the PCM or DLC connector, whatshould the resistance D+ to D- be, and what about each wire to ground and /or bat+. I can find lots of information on the web about CAN wiring but not much about Ford wiring or SCP bus termination..

Hello.I am trying to access a Citroen C4 BSI via the obd interface.I would like to know what is the difference between the pins :3,14 (CAN I/S 250 KB/s)and 3,8 (DIAG ON CAN 500 KB/s)?And which ones to use for that purpose ?

Hello Marco,I see you are quite aware of automotive electronics and would like to ask if you know any website where is described in detail the design and operation of the engine electronic control module? I have a problem with an module Magneti Marelli IAW 8P for Peugeot 306 and I need to understand in more detail the way it works. I searched in the Internet but could not find enough comprehensive information. I would be grateful if you could help me and congratulations for the nice article!Alex

HiDear marcoI have Kia pride year Before 1996 and ECU Siemens 1.3i ( Fenix5) included 20pin diagnostic connector under hoodI need how to connect to this model for see live data and sensor parameter ? please help me Thank you and Best Regards

HiDear marcoI have Kia pride year Before 1996 and ECU Siemens 1.3i ( Fenix5) included 20pin diagnostic connector under hoodI need how to connect to this model for see live data and sensor parameter ? please help me Thank you and Best Regards

I removed the car radio from a Fiat Grande Punto and I want to keep it on while it is on the workbench. I provided 12v and ground, but unfortunately after some minutes it goes off. The connector has two pins labeled "CAN A" and "CAN B", may be the radio sense the engine or the ECU on that bus. Can be feasible to sniff CAN-BUS packets from the car radio connector and then play them back to the radio on the workbench?

Everything is aimed to keep the radio on for a sufficient time, because the message "RADIO BLOCKED / WAIT" is displayed, and I had to wait for the "ENTER CODE" message. And no, the radio was not stolen! It was blocked probably due of a faulty contact.

Hi,I built the Alfa GT engine of Alfa Romeo 156 2.4 JTD 20V, complete with ECU.The Alfa 156 no CAN line for cdashboard ie. body.(I do not work rev counter and temperature)Is there an interface that turned these two parameters in the CAN signal?Thanks

Hi, Is there a way to snoop a working Car CANBus, find packets I'm interested in. Then on my engine swap project pump CANBus packets to the ECU telling him everything is working fine and run the engine correctly...

More specifically, I putting a 2015 Subaru FB25 engine in my VW Vanagon camper bus.. I removed a bunch of unneeded controllers such as VDC. But the ECU goes into limp mode without the VDC and I want to correct this..

Hi When ELM circuit is connected to a vihicle then its vulnerable forshorts and over Current.

Lets say you got a Vihicle with OBD 2 PORT DATA LINES are SHORTED toPOSITIVE or to GROUND.. then if you connect the elm to this car thenoutput transistors or elm chip could get fried..becuase of OverCurrent Flow..???

Please tell me What kind of simple circuit we might need to protectELM Circuit from Over current Shorts..? Thanks in Advance.

You have put together a great resource of information in a well-organized page. I've been interested in cars for many years and have used OBDI and OBDII tools extensively. The arduino developments sounds promising and seem to offer more potential than the limited scope of the typical BT OBD adaptors that are so common.

Thanks for spending so much time on this so the rest of us have a nice reference site!

hi Marcoi had seen your information and its very useful to me.but this is my project making a gear shift indicator.so i just the information for 1.engine speed and 2.vehicle speed depending on that i can proceed so i purchased can bus shield from dx.com and they said they had done the shield based on sk pang so i have seen the ino file but it all the other stuff likw lcd and gps but can u please help me.... but i just want the information on how to retrieve the correct information?

@vijayHi Vijay. Unfortunately I am not working anymore on vehicle electronics these days, so I am not able to give you a satisfying answer. Consider this: whatever digital signal appears in the OBD2 port comes from a specific gateway device which has the main task of selectively allowing authorized diagnostic operations thru specific brand-dependent diagnostic equipment. To my knowledge each brand has very proprietary diagnostic equipment, and even in the same brand, different firmware on the gateway device generate different behaviours.Probably the best cross-brand tools to read OBD port signals are the ELM Electronics https://www.elmelectronics.com/ chips which are used in many diagnostic devices (but beware because there are a lot of fake devices not using the original chips). Specifically ELM has a CAN only chip (ELM329) which allows state-of-the-art can protocol decoding from can signals on OBD2 port and is able to interpret several CAN based protocols like FMS J1939. I am in no way affiliated to Elm Electronics.

Hi Marco, I have a problem with the BSI of my fiat stilo 1.9 jtd 115hp. I found a used one, functioning I hope, and would like to swap the eeprom that contains the code of my car in order not to change the whole lot.The problem is that I can't find the datasheet of this magneti marelli bsi, so don't have a clue about which IC I have to swap. Is it the 14 pins CAN interface or an 8pin ic ? Please I really need this if you can help, it would be very much appreciated. I'm italian and live in france.Best regardsErwin Di Benedettoerwinwizzy@gmail.com

@erwin: I am not an expert in car security, but I think your approach is not going to work. Firmware compatibility matrix is to be respected. You can maybe swap a board between components with same release and versions, but there are probably checks in the code to protect the systems from unauthorized tampering. Also the mismatch would probably become evident if and when your car is checked thru an authorized diagnostic tool. I also do not understand the problem you want to solve by swapping firmware chips. Datasheet is for chips or electronic components. You need to consider firmware levels, which is something different being software not hardware. Good luck and play safe. @mgua

Hi I was wondering if you know the answer to my query. If you broadcast a id and message into the canbus which is the same as what is coming from one of the vehicles ecu's but is different, what happens? I have a arduino canbus sheild on an vw. It is broadcasting into the canbus "change up a gear now". It is sending "id 440 message 5 00 A1 0 0 0 " at the right time. Will it clash with the vehicles original gear shifter ecu? I had it programmed to only broadcast it once which failed sometimes so i programmed it to do it 3 times. It works but sometimes the gearbox ecu recognises something is wrong and puts the car into safe mode and will not change gear untill i restart everything.So emulating another ecu to get a result i want is working but eventually the vehicle is recognising im fooling it.How should one approach this correctly to avoid message clashes and tripping fault conditions in the canbus system?

@anonymous What you are doing is injecting spoofed commands in your car drivetrain can bus. This is extremely dangerous, and you should not do it. Doing so would bring the software state within the car controller out of sync with real state. The embedded software has many embedded security procedures and multiple checks, but can not deal with cospicuous inconsistencies. These potentially dangerous situations are probably logged somewhere and reported to factory lab.Try to put yourself in the place of the main ecu: it receives an "official" gear set, consults a number of tables with data coming from many other sensors, and adjusts engine injection parameters accordingly. Before proceeding with parameter setting, it could also post a query to the originating controller asking for confirmation, and get an answer.Injecting fake informations in this control loop would bring the main software in unknown and uncharted territories, and decisions would be probably taken according to "anomalous condition" rules, which are to be used in emergency, and far from being efficiency or performance optimized. Do not joke with safety. Be smart. Be responsible.@mgua

I understand however I thought about all that and proceeded carefully. All I am really doing is sending it the same commands that comes from the gearshifter when you control the gear lever manually. So if the gear shift algorithms are not happy to act my wishes it does not change gear anyway. Upon testing (not on a road!) This is confirmed. If the canbus id copy trick causes clashing and cant be made to work then i may have to give up the canbus write commands and connect something up to the sensors of the actuall gear shift sensors instead and emulate them. That way it really is ecactly the same as manually shifting it.This is simply trying to create my own shift pattern. Vw did a terrible job of the original shift map and it wears out the clutch packs!

I understand that, in CAN protocol , you send request to car,and your car will response data.Do you know about CAN contactless ?

I bought a CAN Contactless from Gps4net. CAN bus data output is the same data in my car.Whent I connect device CAN contactless to ELM327, I cannot read data from car, i think because CAN Contactless cannot trans request to the car(no physical wire connections).Do you have any solution to read data without send request to the car?