CAN BUS CLASS. EARLY OBD In the early 1980s, many new vehicles began to be equipped with computers known as electronic control units (ECUs) used to control.

CAN BUS CLASS

EARLY OBD In the early 1980s, many new vehicles began to be equipped with computers known as electronic control units (ECUs) used to control the engine, fuel, and emission control systems. As the complexity of these systems increased, manufacturers found it helpful to add some on-board diagnostics to the ECU software. These tests were often initiated by grounding a pin on the ECU. Faults were often output from the ECU using a series of voltage “blips” to indicate a particular fault “code” or number. The fault code generally referenced a circuit, sensor or a service procedure.

EARLY OBD These diagnostics were extremely helpful to manufacturers and technicians; but, there was no standardization of fault codes, tests or procedures among manufacturers or even within large manufacturers.

EARLY OBD Over time, CARB (California Air Resources Board) became aware of the on-board diagnostic capabilities of ECUs. They believed that on-board diagnostics could be used to help identify vehicles with emission- related malfunctions and help service technicians repair them. Based on this, CARB proposed and then adopted the first OBD requirements in April 1985 (1968 Title 13, California Code of Regulations).

OBD-1 OBD-I systems were required to contain various on-board tests to identify malfunctioning components and systems as well as a Malfunction Indicator Light (MIL) on the dashboard to notify the vehicle driver of an emission-related problem. These first-generation (OBD I) requirements applied to new light-duty vehicles beginning with the 1988 model year and continued to apply to some vehicles through the 1996 model year.

OBD-1 The OBD-I requirements were relatively simple as compared to today's requirements: Emission-related inputs to the ECU were required to be monitored for opens and shorts. The components requiring performance monitoring included the following: ECU ECU Fuel metering system Fuel metering system Ignition Ignition Exhaust Gas Recirculation (EGR) system (if equipped) Exhaust Gas Recirculation (EGR) system (if equipped)

OBD-1 A fault code was required to indicate the likely area of the malfunction and had to remain in memory for a period of time, e.g. 50 engine start/run cycles. The OBD I regulations represented a substantial step forward in helping technicians identify malfunctions and repair vehicles equipped with ECUs but, OBD-I systems were limited because they did not monitor all emission control system components. It remained difficult for technicians to identify and repair faults for unmonitored components. In addition, the OBD-I regulations did not contain requirements for manufacturers to standardize their systems In addition, the OBD-I regulations did not contain requirements for manufacturers to standardize their systems.

OBD II On November 1988, CARB proposed revisions to OBD-I systems. The goal of the new proposal was to monitor ALL of the emission-related components on-board the vehicle for proper performance.

OBD II After closely working with auto manufacturers, EPA and the SAE (Society of Automotive Engineers) CARB adopted these revisions as OBD-II regulations on September 12, 1992 (Section 1968.1 Title 13, California Code of Regulations.) The OBD-II regulations applied to all 1994 and subsequent model year gasoline, diesel and alternative-fuel passenger cars trucks up to 14,000 lb GVWR.

OBD II OBD-II regulations require monitoring the following: Catalyst system Engine misfire Evaporative emission control system Secondary air injection system Fuel system Oxygen sensors Exhaust Gas Recirculation system Positive crankcase ventilation system Engine cooling system Cold start emission reduction strategy Air Conditioning system Variable valve timing system Direct ozone reduction system Diesel particulate trap

OBD II In addition to these requirements, the OBD-II regulations included comprehensive component monitoring requirements. They specify that OBD-II systems must monitor any electronic powertrain component/system which either provides input to, or receives commands from the on-board computer for: - Malfunctions which can affect emissions during any reasonable in-use driving condition, or – Electronic powertrain components/systems used as part of the diagnostic strategy for any other monitored system or component.

OBD II The OBD-II regulation were revised again on April 25, 2002. The changes were so extensive that CARB created two new sections: – Section 1968.2, Title 13, California Code of Regulations (Modifications to Malfunction and Diagnostic Systems Requirements for 2004 and Subsequent Model-Year Passenger Cars, Light-Duty Trucks, and Medium Duty Vehicles and Engines), and – Section 1968.5, Title 13, California Code of Regulations (Enforcement of Malfunction and Diagnostic Systems Requirements for 2004 and Subsequent Model-Year Passenger Cars, Light-Duty Trucks, and Medium Duty Vehicles and Engines).

OBD II For 2005 and subsequent model year vehicles, the new regulations include: – Catalyst system monitoring for NOx conversion efficiency in addition to the current requirement for monitoring HC conversion efficiency, – Secondary air system monitoring for proper airflow during vehicle warm-up, when the system would normally operate, – More frequent monitoring of many components to ensure better detection of intermittent faults, – Monitoring for variable valve timing and/or variable cam timing systems, cold start emission reduction strategies, and direct ozone reduction systems. – Monitoring for diesel vehicles to address emissions resulting from catalyst system and particulate matter trap malfunctions.

OBD II For 2005 and subsequent model year vehicles, the new regulations also include: – New requirements to increase the amount of diagnostic information to assist repair technicians (PIDs, Freeze Frame, Mode $06, pending codes, monitor run enable/ready status) as well as to assist Inspection and Maintenance (I/M), or Smog Check, technicians (VIN, CALID = Software Upgrade Number, CVN = Calibration Verification Number), including provisions that restrict the area in which Diagnostic Link Connector may be placed. – J2284/ISO 15765-4 (CAN) will required 100% for 2008 MY and beyond vehicles.

STANDARDIZATION OBD-II regulations reference an continually updated series of SAE/ISO = International Organization for Standardization standards that specify exactly how certain OBD-II functions are to be implemented on the diagnostic communication link: – SAE J1930/ISO 15031-2 – Electrical/Electronic Systems Diagnostic Terms, Definitions, Abbreviations and Acronyms – SAE J1962/ISO 15031-3 – Diagnostic Connector – SAE J1978/ISO 15031-4 – OBD-II Scan Tool – SAE J1979/ISO 15031-5 – E/E Diagnostic Test Modes – SAE J2012/ISO 15031-6 – Diagnostic Trouble Codes – SAE J2186/ISO 15031-7 – E/E Data Link Security

Telematics The OBD-II system is capable of processing and storing a great amount of emission-related information. Adding a wireless connection and making this data available off board is not really a large technological issue. Cellular phones have already been used by vehicle manufacturers to gather OBD-II data from test vehicles. Similar technology is already available to consumers. The largest telematics provider, OnStar, incorporates this technology and offers in-vehicle services like navigation, emergency services, and real-time traffic information using cellular phone technology, Global Positioning System (GPS) technology, and vehicle data obtained from various vehicle modules. ATX Technologies currently offers similar customer services and can provide a large number of data processing services to OEM manufacturers.

Telematics CARB and EPA may consider using systems like these in the future to replace I/M emission tests. CARB has been testing a system that utilizes cellular phone technology to relay information that the OBD-II system had detected an emission-related fault. The state could then send a letter to the vehicle owne requiring that they promptly repair the vehicle. The concept, sometimes referred to as OBD-III, is intended to spare the consumer the cost and inconvenience of having to go to an I/M test station. This would identify the failure much sooner than the current biannual I/M inspection program. Eventually, CARB may consider plans to offer voluntary installation of OBD-III systems where participants would be exempt from I/M testing if they obtained timely repairs for OBD-II identified faults.

Telematics Wireless hardware like Bluetooth and 802.11 is gaining a foothold in vehicles. According to the ABI study, nearly 25% of the world's vehicles produced in 2008 will feature OEM-installed Bluetooth or 802.11 hardware. Bluetooth is a short-range protocol that would allow wireless connections between telephones, PDAs or diagnostic test equipment. Protocols based on 802.11, such as DSRC (Dedicated Short Range Communications), will fill the need for longer range, higher bandwidth applications that can link vehicles with roadside data access points.

Telematics Eventually, as easy, wireless internet access becomes more commonplace, every vehicle could become a just another "IP" address on the internet. This would make it possible to relay large amounts of vehicle data to a vehicle manufacturer's information center. Collecting and analyzing vehicle data goes beyond knowing when a vehicle already has experienced a failure. The ultimate goal would be to predict when a failure would occur and prevent it. The automotive industry refers to this as prognostics.

Telematics Analysis of real-time fault data can be of great benefit to a customer driving down the road. For example: The OBD-II system detects engine misfire at the same time as fuel pressure undergoes a temporary drop. The DTCs and flight recorder data is relayed back to a dealer information server as the MIL is illuminated. The data is analyzed, matched to a database of fault information, and the most probable cause of the failure is determined. An operator calls the driver, informs him as to the nature of the problem, and gives him directions to the nearest dealer service center. The data is also relayed to a service center with an analysis of the most likely repairs and component part numbers.

Telematics The service center orders the repair parts which arrive as the customer pulls in. A service technician repairs the vehicle and the customer is quickly on the road again. Although this scenario seems far-fetched, systems with some of these features are now in prototype vehicles, or are being installed on commercial fleet vehicles.

Telematics Vetronix has developed a second generation telematics system that interfaces directly with the many of the vehicle's electronic and on-board computer based systems using a bi- directional gateway module called a Telematics Control Unit. The Vetronix Mastertrak TM system, which targets commercial vehicle fleets, includes the on-board telematics control module, wireless communications, off-board database management on a server, and various customer business applications that use a standard internet browser.

Telematics

Telematics The National Highway Traffic Safety Administration is encouraging automakers to incorporate on-board crash event data recorders that record crash-related data. They are also promoting Automatic Crash Notification systems to provide early notification of the occurrence, nature, and location of a serious collision. Anti-lock brake systems, vehicle stability systems and climate control systems are becoming capable of providing data to a telematics unit. This kind of data, if available for OEM data analysis and for service providers, will be invaluable for improving vehicle designs, improving vehicle service, predicting impending component and system failures, scheduling maintenance, or simply finding out exactly how people use their vehicles on a daily basis.

Telematics The availability of large amounts of real-time vehicle data holds the possibility of changing the fundamental design of automotive diagnostics. As vehicles become more complex, many vehicle concerns are not caused by simple component failures, but by complex interactions between various vehicle systems. Telematics will allow access to this vehicle data. Future diagnostic systems will be able to collect and analyze data from many vehicles on the road, potentially, from the entire vehicle population an OEM has produced.

Telematics With no computing constraints, off board analysis of vehicle data by high- powered servers could potentially improve fault detection and isolation. Off-board processing and analysis of vehicle failure and repair data could allow for real-time calculation of component and system failure rates as well the ability to identify failure patterns by vehicle, model year, mileage, etc. Real-time data would also shorten the delay between the identification of fault patterns and the definition of the corrective action for vehicles in the manufacturing pipeline and in the field. Failure and repair data would allow diagnostic procedures to change over the life of the vehicle, based on feedback from the field. On new models, engineers could troubleshooting the root cause of a problem on a customer's vehicle remotely by making use of vehicle diagnostic data and functions available using wireless links or the Internet. This could reduce vehicle down-time and repair cost to the customer.

Telematics One of the concerns with the growth of telematics is who owns the data that a vehicle generates. On vehicles with factory-installed telematics systems, the OEM appears to have the best chance of acquiring and utilizing vehicle data. As the OEM and the vehicle exchange data, the vehicle data will get stored by an OEM server. This could provide a considerable benefit to the OEM. It is generally acknowledged that after the initial warranty period, 70 to 80% of vehicles are serviced by the aftermarket. The ability to get vehicle data from vehicles out of warranty provides a mechanism for a continuing the relationship between the customer and the OEM.

Telematics Another point of view is that the vehicle owner will be the one making the choices in the telematics market. Data and communication standardization makes it relatively easy for telematics companies and aftermarket service providers to enter the telematics business. The companies that serve the fundamental needs of the customer best will most likely emerge the winners in the telematics game. These companies may not necessarily be the OEMs. It's no surprise that companies like IBM and Microsoft are developing telematics applications of their own.

Telematics As vehicle quality and durability increases, and many consumers lease their vehicles, consumers have been increasingly trained to look at their automobiles as "maintenance-free". Telematics offers service providers, both OEM and aftermarket, an entirely new customer relationship tool. Instead of the customer notifying a shop about a problem or scheduled maintenance, the shop can notify the customer via email. Instead of going to a shop for a software update for an ECU, the telematics system can determine that a software update is required; the software will download itself, and update itself when the customer parks his vehicle for the night.

Telematics Wireless networks that use conventional cellular phone technology are commonplace. Wireless technologies are up and coming. OBD-II has brought a high degree of standardization to powertrain control modules which make it easier for software developers to write applications that run on OBD-II compliant vehicles. Because of this, the telematics market is expected to grow as OEMs and aftermarket service providers develop new on-board applications that provide improved customer service while the vehicle is in use and off-board applications to assist while the vehicle is being serviced. The possibilities are limited only by the imagination of the engineers and by the ability of the customer to derive value from these services.

Telematics Sensor-Equipped Trucks Help UPS Control Costs Telematics helps the delivery company determine a truck’s performance and condition, as well as identify ways drivers can make small adjustments that yield major results. Since 2008, UPS piloted the technology on 1,500 delivery trucks across the country, testing the equipment in various geographies and climates. In 2009, the company installed telematics in roughly 10,000 vehicles and plans to expand the program to another 10,000 in 2010. That makes nearly a quarter of the company's 95,000 delivery vehicles equipped with telematics. As part of the initiative, UPS is installing GPS tracking equipment as well as sensors in key areas, such as brakes and engine box, and on the exterior. These devices will help UPS track the location of its delivery trucks as well as identify ways in which drivers can make adjustments and improve their performance based on collected data. Two key areas the company plans to improve are idle time and route efficiency.

"Telematics isn't new to UPS. We've been using telematics for more than 20 years to improve the efficiency and safety of our tractor-trailer fleet," Donna Longino, a UPS spokesperson, said. "What is new is the proprietary information and sophisticated algorithms we developed to analyze the rich stream of data captured by more than 200 sensors on our delivery trucks." As drivers complete their routes the UPS telematics equipment captures streams of data via a 900 MHz radio and sends it in real-time to servers for analysis. At the end of the day, drivers return to their centers, and data is uploaded and sent to the UPS data center in Alpharetta, Ga. The telematics devices capture data on more than 200 elements, including speed, RPM, oil pressure, seat belt use, number of times the truck is placed in reverse, and idling time. 32 Telematics

Common Diagnostic Problems Diagnostic Problems Back To The Basics 30% of GM vehicles are repair by looking at TSB’s 80% of all Diagnostic Problems are: 20% Mechanical 20% Computer, Sensor, Outputs 25% Ignition 35% Air - Fuel

OBD II Connector Pin 1 = Discretionary Pin 2 = Communication Bus (+) Pin 3 = Discretionary Pin 4 = Chassis Ground Pin 5 = Signal Ground Pin 6 = Discretionary Pin 7 = ISO K Line Pin 8 = Discretionary Pin 9 = Discretionary Pin 10 = Communication Bus (-) Pin 11 = Discretionary Pin 12 = Discretionary Pin 13 = Discretionary Pin 14 = Discretionary Pin 15 = ISO L Line Pin 16 = Battery

Common Diagnostic Problems Diagnostic Problems Back To The Basics 30% of GM vehicles are repair by looking at TSB’s 80% of all Diagnostic Problems are: 20% Mechanical 20% Computer, Sensor, Outputs 25% Ignition 35% Air - Fuel

OBD II Connector Pin 1 = Discretionary Pin 2 = Communication Bus (+) Pin 3 = Discretionary Pin 4 = Chassis Ground Pin 5 = Signal Ground Pin 6 = Discretionary Pin 7 = ISO K Line Pin 8 = Discretionary Pin 9 = Discretionary Pin 10 = Communication Bus (-) Pin 11 = Discretionary Pin 12 = Discretionary Pin 13 = Discretionary Pin 14 = Discretionary Pin 15 = ISO L Line Pin 16 = Battery

Drive Cycle

OBD II Drive Cycles Are Designed To Test The System Under A Wide Range Of Operating Conditions Considered Typical Of Normal Vehicle Operation.

40 READINESS OBDII systems have up to 11 diagnostic monitors. Diagnostic monitors are periodic tests run on specific systems and components to ensure that they are performing within their prescribed range. OBDII systems must indicate whether or not the onboard diagnostic system has monitored each component or system. Components or systems that have been diagnosed are termed “ready”. This means they were tested, not that they passed the test. The purpose of recording readiness status is to allow technicians to determine if the vehicle’s OBDII system has tested the components and/or systems.

READINESS (Continued) Once a monitor has been set to “ready”, it will continue to indicate “ready” unless the vehicle’s battery is disconnected or codes are cleared, with a few exceptions. Normally, the readiness status of all components or systems will be “ready”. However, if the vehicle’s PCM (Powertrain Control Module (PCM is OBD II terminology for the powertrain computer) has lost power, or if DTCs have been recently cleared with a scan tool, all non-continuous components or systems will be set to “not ready”.

Non-Continuous Monitors The monitors listed below are termed non-continuous monitors: C 02 Sensor C O2 Sensor Heater C Catalyst C Evaporative System C EGR System C Secondary AIR System C Others if vehicle is so equipped (heated catalyst, and A/C system) Readiness is an issue only with these non-continuous monitors.

Enabling Criteria Non-continuous monitors can only run (test the system) when the vehicle conditions are appropriate for testing. These operating parameters are typically termed enabling criteria. As an example, the catalytic converter could not be tested when the vehicle was cold (the cat was not “lit”) or when the throttle was wide open (no converter can manage full enrichment emissions). The PCM could also not test the system if a major input signal was faulty, if the Mass Airflow (MAF) sensor or an O2S were faulty, the PCM would not be able to regulate fuel or evaluate the converter.

Typical Criteria for EVAP Monitor No DTCs set Barometric pressure exceeds 75 KPA (below roughly 14,000 feet At start-up, IAT & ECT is between 40º and 100º F ECT is not more than 12º greater than IAT Fuel tank level is between 25% and 75% The TPS is between 9% and 35% The EVAP purge solenoid is at 50% PWM (Pulse Width Modualted) within 65 seconds of run time Whenever these criteria are met the PCM will run the EVAP monitor

Oxygen Sensor Monitor The Oxygen Sensor (O2S) Monitor consists of two tests: Sensor amplitude test -- The PCM switches the air fuel ratio rich and lean to see that the O2S can produce a voltage at the low and high threshold, typically.2 and.8 volts. Sensor switch rate test – The PCM switches the air fuel ratio at a specified rate and watches the rate of change from the O2S above and below the rich lean threshold. It must typically switch in 50 to 100 milliseconds.

Oxygen Sensor Heater Monitor The Oxygen Sensor (O2S) Heater Monitor tests to be sure that the heater circuit is functional. Manufacturers perform this testing using several different methods. Typical tests include: Testing after a cold start and watching the time until O2S activity Monitoring current flow through the heater element Cycling the heater on and off and watching the change in current as resistance increases.

Catalyst Monitor The three-way catalytic converter is used to convert the primary exhaust pollutants (HC, CO and NOx) into carbon dioxide (CO2), water (H2O) and nitrogen. The cat monitor diagnoses the catalytic converter by comparing the signal between the upstream and downstream oxygen sensors. The catalyst must be 60% efficient to pass the test. Many early OBD II vehicles are now failing this test and setting a P0420 DTC.

Catalyst Monitor Passed The pre-cat O2S in red is switching normally. At the mid point of the recording the PCM begins the catalyst monitor by switching the A/F ratio at a steady and high frequency. The front O2S shows fine amplitude and switch rate. The post-cat O2S in blue is staying steady both before and after the test. This indicates that the converter is doing its job of using oxygen to oxidize hydrocarbons.

Catalyst Monitor Failed Again, during the mid-point of the recording, the PCM “feeds” the cat and watches the rear O2S response, in blue. The post-cat O2S response rate is almost identical to the front O2S. It is unable to oxidize the hydrocarbons. This recording is of a vehicle with 122,000 miles with a DTC P0420, Low Catalyst Efficiency. The previous slide showed the same vehicle with a new converter installed.

EGR Monitor The EGR system recirculates non-combustible exhaust gases back into the cylinder to dilute the incoming air/fuel charge. This cools the combustion chamber down and reduces Oxides of Nitrogen (NOx). The EGR system is monitored for high and low flow rates, sensor and output failures, and lack of correlation between PCM commands and indicated flow. The system monitor may use a MAP, DPFE, or an exhaust gas temperature sensor, or Long Term Fuel Trim (LTFT) to evaluate EGR flow.

Continuous Monitors Some of the vehicle components or systems are continuously tested by the vehicle’s OBDII system, while others are tested only under specific vehicle operating conditions. The continuously monitored components listed below are always ready: C Fuel System C Misfire C Comprehensive Components

Misfire Monitor Monitoring misfires and identifying offending cylinders is a requirement of OBDII. This is typically accomplished by monitoring crankshaft deceleration. If a cylinder does misfire fully or partially, the reduced force on the piston slows down the crankshaft. The monitor looks for a change in crankshaft speed as indicated by a change in the pulse width or frequency outputted by the crankshaft position sensor.

Fuel System Monitor Using feedback from the oxygen and other sensors, the PCM manages the fuel system to optimize engine combustion conditions. OBDII regulations require that the fuel system be continuously monitored. The MIL is illuminated if the fuel system cannot be controlled by the PCM. Criteria for setting the MIL varies by manufacturer but typically if LTFT is above + 20-25% or if it is below -20-25% a lean (+20) P0171 DTC, or rich (-20) P0172 DTC is set.

Comprehensive Components Monitor The on-board system must check for malfunctions in any electronic component or system that either provides input to, or receives commands from the PCM for emissions control. Sensor inputs are to be tested for functionality (is it working?) and rationality (do the readings make sense?).

Functional Checks Functional tests are performed between key on and key crank. The PCM sends a small current through components and monitors return. Example: Circuit Continuity – Problems with circuit continuity include any type of electrical circuit fault, (open circuit, short to voltage or ground) switch or sensor failures, (opens, internal shorts, shorts to ground or voltage) and PCM internal problems.

Rationality Checks The PCM tests sensors to be sure their signals make sense by comparing them with other inputs. Example -- the Throttle Position Sensor --If the engine speed is high, engine load indication is high and airflow is high, but the Throttle Position signal indicates a closed throttle condition, then the OBDII system must detect the fault and set an appropriate DTC.

How Monitors Become Ready The PCM sets a monitor to “ready” after an appropriate drive cycle has been performed within one key-on, engine-run, key-off cycle. The drive cycle that enables a monitor and sets readiness codes to “ready” varies for each individual monitor. This monitor specific drive cycle is frequently called a “trip”. Normal driving usually sets a monitor to ready in a couple days.

THIS GENERIC DRIVE CYCLE IS INTENDED TO ALLOW ALL THE MONITORS TO RUN

Getting Vehicles Ready If the driving habits of the vehicle owner or environmental conditions are such that an appropriate drive cycle has not been completed, the monitors will not be ready. As an example, the catalytic converter will generally only be monitored when the vehicle is fully warm, at highway speed, and under light load. A vehicle that never sees these conditions, this trip, will never be ready, since the cat monitor will never run.

Understanding Lab Scopes If you are not using a lab scope your efficiency is dropping every year as vehicles get harder to diagnose. Understanding how to use a Lab Scope today will build your efficiency and create less come backs from misdiagnosed repairs.

BASICS OF LAB SCOPES

Scope Essentials Digital Storage Oscilloscope (DSO) Voltmeter that captures voltage samples & displays them on a screen Voltage appears as a trace of light Trace moves up & down, displaying voltage Trace moves left to right, displaying time Digital Multimeters (DMM) take slower samples, displays them as a numeric value

Scope Essentials Samples are digitized & displayed on screen These digitized samples can be saved for future use or transferred to a computer

The Waveform Waveform – the line traced on the screen Scopes show voltage levels over a period of time (horizontal) Amplitude – difference between a signals lowest and highest value (0 – 5v) (vertical) Frequency – rate at which a signal repeats itself in one second, measured in Hertz

Waveform Shape Signature of the voltage signal When measuring sensors, each has it’s own unique shape

The Scope Screen Divided into small sections - Grids 8 x 10 grid Screen Voltage level between grids is adjustable Time base between grids is adjustable

Voltage & Time Divisions

Trigger Voltage level that the sampled signal must cross to start the horizontal sweep that draws the waveform across the screen If voltage level is 2v set trigger at 1v

Trigger & Slope Trigger sets the voltage level that the signal must cross to start a sweep Positive slope – triggers the sweep on a rising voltage Negative slope – triggers the sweep on a falling voltage

Glitch Intermittent malfunction in either a circuit or a component Sudden change in voltage

THROTTLE POSITION SENSORS

Good TPS Bad TPS

Good F.I. Bad F.I. (No Pintle Hump)

Good F.I. Bad F.I. (No inductive kick)

Good Fuel Inj Bad Fuel Injector

Good O 2 Sensors Bad O 2 Sensor

Oxygen Sensor Rise Time Notice the "lean to rich" reaction time for the O2 sensor is at 164ms, well above the allowed 100ms benchmark. A sensor can have a good reaction time in one direction and a poor reaction time in the other direction so both must be checked A new oxygen sensor can achieve around 25ms or less

What's Wrong With This Pattern

LAB SCOPE SIGNATURES

BAD GROUND

ALTERNATOR TESTING

Introduction to Control Area Network 85

CANBUS or CAN bus – Controller Area Network bus An automotive serial bus system developed to satisfy the following requirements:  Network multiple microcontrollers with 1 pair of wires.  Allow microcontrollers communicate with each other.  High speed, real-time communication.  Provide noise immunity in an electrically noisy environment.  Low cost 86 What is CAN?

Designed specifically for automotive applications Today - industrial automation / medical equipment 87 Who uses CAN?

First idea - The idea of CAN was first conceived by engineers at Robert Bosch Gmbh in Germany in the early 1980s. Early focus - develop a communication system between a number of ECUs (electronic control units). New standard - none of the communication protocols at that time met the specific requirements for speed and reliability so the engineers developed their own standard. 88 CANBUS History

CAN was created in 1984 by the Robert Bosch Corp. in anticipation of future advances in onboard electronics. The first production application was in 1992 on several Mercedes-Benz models. Today you will find it on all new vehicles. 89 CAN DIAGNOSTICS

1983 : First CANBUS project at Bosch 1986 : CAN protocol introduced 1987 : First CAN controller chips sold 1991 : CAN 2.0A specification published 1992 : Mercedes-Benz used CAN network 1993 : ISO 11898 standard – (International Standard) 1995 : ISO 11898 amendment Present : The majority of vehicles use CAN bus. 90 CANBUS Timeline

Class C is currently the fastest data bus rating. Class C systems can operate at speeds up to 1 megabits per second, which is up to 100 times faster than a typical Class B data bus. Many of the vehicles that are currently using a Class C data bus are operating at speeds of around 500 Kbps, which is fast enough for powertrain control modules, air bag modules, and fast-acting antilock brake and stability control systems. Even faster CAN systems are coming with "class D" ratings of over 1 megabytes per second. And some applications such as onboard entertainment systems require even higher speed audio and video streaming. 91 CAN DIAGNOSTICS

One thing to keep in mind about the CAN standard is that CAN as well as other protocols such as SAE J1939, GMLAN, OBD II, SAE J1587 and LIN have more to do with the way information is formatted, transmitted and received than how fast it is sent. This means the automotive engineers who design the onboard electronics for CAN-compliant vehicles are free to choose any operating speed they want (up to one megabits per second) as well as the type of bus conductor (one wire, twisted paired wires or a fiber optic cable). On most cars today, a high-speed data bus is needed to handle the volume of information going back and forth between all the onboard electronics. 92 CAN DIAGNOSTICS

In 1995, GM introduced its own "Class 2" data bus to handle communication between modules. The system ran at a speed of 10,400 bits per second (10.4 Kbps), which was more than adequate for vehicles a decade ago. In 2004, GM moved to their next generation data bus system which they called "GMLAN" (GM Local Area Network). Introduced on the Cadillac XLR and Saturn Ion, GMLAN added the capability to operate at two speeds on two separate buses: a low speed (33.33 Kbps) bus and a high speed (500 Kbps) bus. 93 CAN DIAGNOSTICS

The low speed side of the GMLAN (GM Local Area Network) system operates on a single wire bus to handle body-related control functions, while the high speed bus uses two wires to carry data between the powertrain, transmission and antilock brake modules. A "gateway" node connects the high speed bus and low speed bus, and allows information to be shared back and forth. For example, the radio (which is connected to the low speed bus) may adjust volume based on engine speed and vehicle speed (from the high speed bus) to offset road noise. 94 CAN DIAGNOSTICS

Mercedes also uses several different bus speeds on their vehicles. Depending on the application, there may be a high- speed 500 Kbps CAN-C bus for the powertrain, transmission and ABS modules, and a slower-speed 83 Kbps CAN-B bus for the body control functions. On some Mercedes cars, there may be as many as 30 modules on the CAN-B bus. Up to model year 2002, all communication between the CAN-C and CAN-B bus went through the electronic ignition switch (EIS) module. After 2002, a new "gateway" module handles the inter-bus communications as well as onboard diagnostics via a CAN-D bus. 95 CAN DIAGNOSTICS

96 CAN DIAGNOSTICS

If your eyes haven't glazed over yet, here's how data is sent and received in a CAN system. Every module (node) that is attached to the data bus network is capable of sending and receiving signals. Each module (node) has its own unique address on the network. This allows the module to receive the inputs and data it needs to function, while ignoring information intended for other modules that share the network. When a module transmits information over the network, the information is coded so all the other modules recognize where it came from. 97 CAN DIAGNOSTICS

Data is sent as a series of digital bits consisting of "0's" and "1's". If you looked at the data on a scope, you would see a square wave pattern that changes between a high and low voltage reading. The low voltage reading usually corresponds to the "0" while the high voltage reading corresponds to the "1". The actual voltage readings will vary depending on the application and protocols the vehicle manufacturer is using, but most operate in the 5 to 7 volts range. 98 CAN DIAGNOSTICS

The CAN standard requires a "base frame" format for the data. What this means is that for each distinct message sent or received by a module on the network, there is a beginning bit (called the "start of frame" or "start of message" bit), followed by an "identifier" code (an 11 bit code that tells what kind of data the message contains), followed by a priority code ("remote transmission request") that says how important the data is, followed by 0 to 8 bytes (one byte equals 8 bits) of actual data, followed by some more bits that verify the information (cyclic redundancy check), followed by some end of message bits and an "end-of-frame" bit. 99 CAN DIAGNOSTICS

Still with me? There's more! One of the tasks of any network system is to keep all the messages separated so they don't collide and garble one another. Usually the body control module or instrument cluster module is assigned the task of managing the network traffic. When it sees a message coming over the bus, it looks at the first bit in the data stream. If the bit is a "0", the message is given priority over the others. This is called a "dominant" message. If the first bit is a "1" it is given a lower priority (a "recessive" message). Thus, the highest priority messages always get through to their intended destinations but the low priority messages may be temporarily blocked until the traffic eases up. 100 CAN DIAGNOSTICS

101 CAN DIAGNOSTICS

CAN-compliant vehicles are just as vulnerable to electronic faults as older vehicles. Though CAN systems use fewer wires and fewer connectors to save weight and cost, they also use more modules and more complicated modules. Communication problems can occur if module connectors become corroded or loose, if wires become grounded, shorted or break, or system voltage is below specifications. Some modules may even forget their settings or locations if the battery is disconnected or goes dead. 102 CAN DIAGNOSTICS

On some Chrysler minivans, for example, the automatic climate control system will quit working if battery power is lost. This happens because the electric stepper motors that control the position of the blend doors forget their locations. The system has to be put into a "relearn" mode to re-establish all the motor locations and settings. 103 CAN DIAGNOSTICS

Various kinds of problems can occur on other CAN- equipped vehicles when the battery is disconnected or goes dead. The modules in the CAN system require a certain amount of voltage for their Keep Alive Memory settings. If this is lost, the module will forget these settings and may not function properly until it has time to relearn the lost data. 104 CAN DIAGNOSTICS

In some cases, this requires a special relearn procedure using a scan tool because the module can't do the relearn by itself. And on some vehicles, the module may go to sleep and not wake up until it is pinged by a scan tool or the main gateway module (usually the body control module). Relearning procedures typically require a factory scan tool or a professional level aftermarket scan tool. 105 CAN DIAGNOSTICS

CAN is a closed network – no need for security, sessions or logins. - no user interface requirements. Physical and Data Link layers in silicon. 106 CANBUS and the OSI Model

107 CANBUS Physical Layer Conventional multi-wire loomsCAN bus network  Physical medium – two wires terminated at both ends by resistors.  Differential signal - better noise immunity.  Benefits:  Reduced weight, Reduced cost  Fewer wires = Increased reliability vs.

108 Transmission Characteristics  Up to 1 Mbit/sec.  Common baud rates: 1 MHz, 500 KHz and 125 KHz  All nodes – same baud rate  Max length:120’ to 15000’ (rate dependent)

Each node – receiver & transmitter A sender of information transmits to all devices on the bus All nodes read message, then decide if it is relevant to them All nodes verify reception was error-free All nodes acknowledge reception 109 Message Oriented Transmission Protocol CAN bus

Each message has an ID, Data and overhead. Data –8 bytes max Overhead – start, end, CRC, ACK 110 Message Format

111 Example of Message Transaction

Arbitration – needed when multiple nodes try to transmit at the same time Only one transmitter is allowed to transmit at a time. A node waits for bus to become idle Nodes with more important messages continue transmitting 112 Bus Arbitration CAN bus © 2005 Microchip Technology Incorporated. All Rights Reserved.

Message importance is encoded in message ID. Lower value = More important As a node transmits each bit, it verifies that it sees the same bit value on the bus that it transmitted. A “0” on the bus wins over a “1” on the bus. Losing node stops transmitting, winner continues. 113 Bus Arbitration

Controller Area Network (CAN) electrical systems began to appear in new vehicles in 2003. Since then, more and more vehicles have been equipped with CAN systems, until 2008 when virtually all passenger cars and light trucks sold in the U.S. were CAN-equipped. 114 CAN DIAGNOSTICS

You need to know how CAN has made the electrical system in late model cars and trucks much more complicated than ever before. CAN allows various modules and systems to share data and interact in ways that where previously impossible. 115 CAN DIAGNOSTICS

So what exactly is CAN? It is a communication standard that allows the various modules and computers in a vehicle to talk to one another via a common "data bus" circuit in the wiring system. Think of it as a high speed party line that allows data and commands to zip back and forth from one module to another. 116 CAN DIAGNOSTICS

This allows the Powertrain Control Module (PCM), antilock brake/traction control/stability control system, electronic steering, electronic suspension, automatic climate control system, keyless entry system, lighting control modules and dozens of other systems and modules to all be interconnected electronically. 117 CAN DIAGNOSTICS

118 CAN DIAGNOSTICS

If you don't know the difference between a CAN data bus and a school bus, you're not alone. Many mechanics are not yet up to speed on CAN diagnostics. Troubleshooting a late model CAN car is really no different than troubleshooting any late model OBD II vehicles. 119 CAN DIAGNOSTICS

You will need a scan tool to read out fault codes and other sensor data, and you need a scan tool that is CAN compliant. That means it has the proper software and hardware to communicate with the vehicle at higher speeds. 120 CAN DIAGNOSTICS

121 CAN DIAGNOSTICS

New Product Report: June 11, 2013 The U-Scan unit plugs directly into your vehicle’s OBD II port. The unit allows your iPhone or Android phone to communicate with the OBD II system via a free app. The U-Scan unit uses Bluetooth to talk to your phone. U-Scan is compatible with all 1996 and newer cars and light trucks. CAN DIAGNOSTICS 122

ADVANCED SCAN TOOL DIAGNOSTICS For advanced scope diagnostics, you will want to learn how to access Mode 06 information on a scan tool (most tools that cost upwards of $200 can access Mode 06 today, but you have to know how to find it because it is not clearly marked. Mode 06 data is the raw hexadecimal code data the engine computer looks at when it runs system monitors. This is useful information to access when a vehicle is experiencing a no-code driveability problem, to verify whether or not a particular sensor or circuit is operating within its specified MIN and MAX values, and to verify a sensor or other component is working properly after it has been replaced. 123 CAN DIAGNOSTICS

Older scan tools (namely, most of those made before about 2006) lack the circuitry to talk to a CAN system. Some older scan tools have the right hardware, and can be upgraded with new software. But in most cases you will need a newer scan tool that is CAN-compliant to do onboard diagnostics. 124 CAN DIAGNOSTICS

Most inexpensive scan tools designed for the DIY market are on-e-way tools: they can read codes and data, but they cannot send commands to the vehicle that are necessary to run all kinds of system self-tests. That degree of sophistication is reserved for more expensive professional level scan tools or factory scan tools. In addition, the software in a typical DIY scan tool (even if it is CAN-compliant) can usually only access powertrain codes. It can't talk to the ABS system, climate control system, electronic steering or suspension systems, climate control system, airbag system or other onboard electronics. In other words, it is a very limited tool. 125 CAN DIAGNOSTICS

For advanced diagnostics that go beyond simply reading powertrain fault codes and sensor data, you need a professional level tool or a factory tool. The latter can be quite expensive, costing thousands of dollars -- plus annual software updates that can add hundreds more. So if you need advanced diagnostics, the only option for most motorists and DIYers is to take your vehicle to a repair shop that has the proper diagnostic equipment. 126 CAN DIAGNOSTICS

Like many current vehicles, information in a CAN- equipped vehicle is shared over a serial data bus. The bus is the circuit that carries all the electronic chatter between modules (nodes). The bus may have one wire or two. If it has two, the wires are usually twisted to cancel out electromagnetic interference. The speed at which the bus carries information will vary depending on the "class" rating of the bus as well as the protocol to which it conforms. 127 CAN DIAGNOSTICS

A data bus with a "Class A" speed rating is a relatively slow, low-speed circuit that typically carries less than 10 kilobits (10 Kbps) of information per second. A data bus that operates at Class A speeds is limited to simple command functions like operating power mirrors, power seats, power widows, power door locks, remote trunk releases and lights. 128 CAN DIAGNOSTICS

The kilobit is a multiple of the unit bit for digital information or computer storage. The prefix kilo- (symbol k) is defined in the International System of Units (SI) as a multiplier of 10 3 (1 thousand), and therefore, 1 kilobit= 10 3 bits = 1000 bits. The kilobit has the unit symbol kbit or kb. 129 KILOBIT

A data bus with a "Class B" rating, by comparison, may operate from 10 Kbps up to 125 Kbps, depending on the operating protocol (SAE J1850 or Europe's ISO 9141-2). This is fast enough to carry more complex information and time-sensitive data. Systems that may share a data bus with a Class B rating include electronic instrumentation, electronic transmission controls, security systems, and climate control. 130 CAN DIAGNOSTICS

131 CAN DIAGNOSTICS Tap test

CAN DIAGNOSTICS 132

133 CAN DIAGNOSTICS

134 CAN DIAGNOSTICS

135 CAN DIAGNOSTICS 100 millionths of a second wide

136 CAN DIAGNOSTICS

137 CAN DIAGNOSTICS When transmitting Make sure no weird noise or fuzziness in signals

138 CAN DIAGNOSTICS

139 CAN DIAGNOSTICS

140 CAN HACKING

SAE International is a global association of more than 138,000 engineers and related technical experts in the aerospace, automotive and commercial-vehicle industries. SAE International's core competencies are life-long learning and voluntary consensus standards development. SAE International's charitable arm is the SAE Foundation, which supports many programs, including A World In Motion® and the Collegiate Design Series. 141 SAE

This SAE Standard establishes the requirements for a Class B Data Communication Network Interface applicable to all On- and Off-Road Land-Based Vehicles. It defines a minimum set of data communication requirements such that the resulting network is cost effective for simple applications and flexible enough to use in complex applications. Taken in total, the requirements contained in this document specify a data communications network that satisfies the needs of automotive manufacturers. 142 SAE J1850

This specification describes two specific implementations of the network, based on media/Physical Layer differences. One Physical Layer is optimized for a data rate of 10.4 Kbps while the other Physical Layer is optimized for a data rate of 41.6 Kbps. The Physical Layer parameters are specified as they would be detected on the network media, not within any particular module or integrated circuit implementation. 143 SAE J1850

Although devices may be constructed that can be configured to operate in either of the two primary implementations defined herein, it is expected that most manufacturers will focus specifically on either the 10.4 Kbps implementation or the 41.6 Kbps implementation depending on their specific application and corporate philosophy toward network usage. However, low-volume users of network-interface devices are expected to find it more effective to use a generic interface capable of handling either of the primary implementations specified in this document. 144 SAE J1850

Vehicle OEMs have requested that 'high speed' versions of both SAE J1850 VPW and PWM be supported by SAE J2534-1 Pass-Thru Vehicle Interfaces. Therefore, the SAE J1850 document must be updated to detail the associated network requirements. 145 SAE J1850

SAE/ISO Diagnostic Specifications Vehicle diagnostic communication specifications have been written by the Society of Automotive Engineers (SAE) and by various International Standards Organization (ISO) workgroups. These standards are referenced by the California, Federal and European OBD regulations. US regulations reference SAE standards, European regulations reference equivalent ISO standards.

Types of Network Messages There are two types of network messages Diagnostic messages Normal Mode messages Normal Mode messages are used to share information between modules on the network during normal vehicle operation, e.g. instrument cluster sends fuel level info (percent fill) to PCM. Normal mode messages always use physical addressing.

Types of Network Messages Diagnostic Mode messages are used to communicate between a test tool and a module on the network. Diagnostic messages can use either physical addressing or functional addressing. Manufacturer-specific tools normally use physical addressing Generic OBD tools use functional addressing because the configuration of the network and network addresses do not have to be known for every specific vehicle

J1850 41.6 PWM J1850 41.6 PWM is used by Ford. Ford internally calls this protocol Standard Corporate Protocol (SCP) SCP is a true network protocol that incorporates bus arbitration. SCP is used for both vehicle network communication and diagnostic communication.

J1850 10.4 VPW J1850 10.4 VPW is used by General Motors. GM internally calls this protocol Class 2. Class 2 is a true network protocol that incorporates bus arbitration. Class 2 is used for both vehicle network communication and diagnostic communication.

ISO 9141 ISO 9141 is used by many Japanese manufacturers. ISO 9141 is not a network protocol, it can only be used for diagnostics. There is no bus arbitration. It can be used to connect one diagnostic tool to a vehicle control module. ISO 9141 is relatively slow – 10.4 Kbps

KWP 2000 KWP is used by many European manufacturers. It uses an enhanced set of diagnostic messages but retains the ISO 9141 physical layer. KWP is not a network protocol, it can only be used for diagnostics. There is no bus arbitration. It can be used to connect one diagnostic tool to one or more vehicle control modules. KWP is relatively slow – 10.4 Kbps

SAE/ISO Diagnostic Specifications Legislated diagnostics SAE J1930/ISO 15031-2 – Electrical/Electronic Systems Diagnostic Terms, Definitions, Abbreviations and Acronyms SAE J1962/ISO 15031-3 – Diagnostic Connector SAE J1978/ISO 15031-4 – OBD-II Scan Tool SAE J1979/ISO 15031-5 – E/E Diagnostic Test Modes SAE J2012/ISO 15031-6 – Diagnostic Trouble Codes SAE J2186/ISO 15031-7 – E/E Data Link Security Non legislated diagnostics SAE J2190/ISO 14229 – Enhanced E/E Diagnostic Test Modes

SAE/ISO Multiplex Specifications Legislated multiplex standards SAE J1850 (Class B Data Comm. Network Interface) ISO 9141-2 (K-Line) ISO 14230-4 (Keyword Protocol 2000) SAE J2284/ISO 15765-4 (CAN) J2534 – Recommended Practice for Pass-Thru Vehicle Programming

SAE J1930 – Terms and Acronyms J1930 attempts to limit the proliferation of terms, abbreviations and acronyms used in motor vehicle service literature. Examples Ford uses ECT (engine coolant temp sensor), GM uses CTS (coolant temp sensor), J1930 uses ECT Ford uses ISC (idle speed control), J1930 uses IAC (idle air control) Ford uses EEC-V, J1930 uses PCM (powertrain control module)

SAE J1930 – Terms and Acronyms J1930 describes a consistent methodology for naming components and systems. MODIFIERSBASE WORD What isWhereWhichWhat doesWhat Purpose?Is it?Temp?it sense?Is it? Sensor (most generic) TemperatureSensor CoolantTemperatureSensor EngineCoolantTemperatureSensor InstrumentationEngineCoolantTemperatureSensor (most specific) Least >>>>>Most

SAE J1962 – Data Link Connector J1962 describes the functional requirements for the vehicle and test tool data link connector (DLC): In-vehicle location/access Connector design Terminal assignments Electrical interface requirements

SAE J1962 – Data Link Connector The 16-pin DLC assignments are specified in SAE J1962/ISO 15031-3 Pin 1 - DiscretionaryPin 9 – Discretionary Pin 2 – Bus + J1850Pin 10 – Bus – J1850 Pin 3 – Discretionary Pin 11 – Discretionary Pin 4 – Chassis GroundPin 12 – Discretionary Pin 5 – Signal Ground Pin 13 - Discretionary Pin 6 – CAN HighPin 14 – CAN Low Pin 7 – K-Line ISO9141/KWP Pin 15 – L-Line ISO9141/KWP Pin 8 – Discretionary Pin 16 – Unswitched Battery +

SAE J1962 – Data Link Connector The general location of the DLC is specified in J1962, however, CARB and EPA regulations are more restrictive. CARB specifies that DLC must be on driver’s side of vehicle centerline, not on center console, or behind storage accessories. A covered DLC must have label (e.g. OBD) approved by CARB. Pin 16 must have < 20 Volts (not 24 or 42 V)

SAE J1978 – Generic Scan Tool J1978 defines the minimum functionality required by an “OBD-II Scan Tool” Automatic hands-off determination of the communication interface Displays status and results of on-board diagnostic evaluations Displays pending and confirmed DTCs Displays current data, freeze frame data, and vehicle information Clears DTCs, test results and freeze frame Provides a user manual/help facility

SAE J2012 – Diagnostic Trouble Codes J2012 defines a set of diagnostic trouble codes (DTCs) where industry uniformity has been achieved. DTCs consist of an alpha character followed by four characters Pxxxx is reserved for powertrain DTCs Bxxxx is reserved for body DTCs Cxxxx is reserved for chassis DTCs Uxxxx is reserved for network DTCs

SAE J2012 – Diagnostic Trouble Codes The second character designates whether the DTCs and a generic SAE DTC or a manufacturer- specific DTC. P0xxx, P2xxx, P3400, and U0xxx are generic DTCs P1xxx, P30xx, P3100, P32xx and P33xx are manufacturer-specific DTCs The remaining characters designate the system associated with the fault. The characters are hex and can range from 0 – F.

SAE J2012 – Diagnostic Trouble Codes The J2012 committee defines new DTCs on a quarterly basis, based on manufacturer requests. The J2012 committee assigns DTCs in a uniform manner using J1930 terminology. Sample output: P2632 – Fuel Pump B Control Circuit / Open P2633 – Fuel Pump B Control Circuit Low P2634 – Fuel Pump B Control Circuit High P2636 – Fuel Pump B Low Flow/Performance

SAE J2012 – Diagnostic Trouble Codes Sample input: P0A00 – Motor Electronics Coolant Temp Sensor Circuit P0A01 – Motor Electr. Coolant Temp Sensor Circuit Range / Performance P0A02 – Motor Electr. Coolant Temp Sensor Circuit Low P0A03 – Motor Electr. Coolant Temp Sensor Circuit High P0A04 – Motor Electr. Coolant Temp Sensor Circuit Intermittent / Erratic Sample network DTCs: U0001 – High Speed CAN Communication Bus U0101 – Lost Communication with TCM U0302 – Software Incompatibility with TCM U0402 – Invalid Data Received From TCM

SAE J2186 – Data Link Security J2186 defines a method to access secured vehicle controller functions. Three parameters control security access The “seed” (sent by controller) and “key” (sent by external device) The delay time (minimum delay time between attempts) The number of false access attempts

SAE J1979 – Diagnostic Test Modes SAE J1979/ISO 15031-5 defines standard diagnostic test modes. Diagnostic/emission critical control modules must implement these diagnostic test modes. They must be on the OBD data link or must use another module as a gateway. CARB defines engine and transmission control modules as emission-critical.

SAE J1979 – Diagnostic Test Modes Any other control module that performs a major OBD-II monitor or performs CCM monitoring for more than two components is considered to be diagnostic critical. If a diagnostic/emission critical control module is reprogrammable, it must respond with Mode $09 CALID and CVN. It must be able to be reprogrammed using a SAE J2534 interface.

SAE J1979 – Diagnostic Test Modes J1979 specifies a set of standard messages that can be used by scan tool to obtain OBD-II data from a vehicle. (Modes $01 to $09) Functional addressing is used instead of physical addressing for all messages because the test tool does not know which systems on the vehicle have the OBD information that is requested. Response times to messages are specified. Message lengths are specified.

SAE J1979 – Diagnostic Test Modes Messages must utilize a standard set of header bytes specified for each communication protocol. The remainder of the message (the data bytes) specify the type of message (test mode) and specific data that is being requested. Header byte definitions are specified on the next two slides.

SAE J1979 – Header Bytes

SAE J1979 – CAN Header Bytes

Ford Module Addresses ModulePhys Adr Func Adr Rec Adr Xmit Adr Func Rec Adr Func Xmit Adr (J1850) (J1850) (CAN) (CAN) (CAN) (CAN) PCM$10 $6A $7E0 $7E8 $7DF $7E8 ( Powertrain Control Module) TCM$18 $6A $7E1 $7E9 $7DF $7E9 (Transmission Control Module) ABS$28 $6A $7E2 $7EA $7DF non-OBD (Anti-lock Brake System) AHCM$0F $6A $7E3 $7EB $7DF non-OBD (Auxiliary Heater Control Module) TCCM$18 $6A $7E4 $7EC $7DF non-OBD (Transfer Case Control Module) AFCM$16 $6A $7E5 $7ED $7DF $7ED (Alternative Fuel Control Module) SPCM$11 $6A $7E6 $7EE $7DF $7EE (Secondary PCM)

Mode $01 – Retrieve Diagnostic Data Mode $01 provides diagnostic data, commonly called PIDs (Parameter ID) Service technicians can use the data to troubleshoot sensors, check OBD monitor completion, MIL status, etc. Test tool specifies the requested data by PID number ($00 through $FF) PIDs are defined in J1979 (number, units, conversion/scaling factor, acronym) PIDs must show “raw” values – not substituted values if a sensor fails

Mode $01 – Retrieve Diagnostic Data

PID $01 – I/M Readiness

PID $02 and $03

PIDs $04 - $11

PIDs $12 - $1B

PIDs $1C - $1E

PIDs $1F - $2B

PIDs $2C - $33

PIDs $34 - $3F

PID $41

PIDs $42 - $4E

Mode $02 – Freeze Frame Mode $02 stores Mode $01 PID data at the time a pending or confirmed DTC is stored. Fuel system and misfire DTCs have a higher priority and overwrite any existing data. Service technicians can use the data to understand the conditions at the time the malfunction occurred. Only one frame ($00) is required to be stored.

Mode $02 – Freeze Frame Freeze frame can be useful, however, there are some caveats. Freeze frame is stored when the DTC is stored, not when the problem began. For circuit faults, it usually takes 5 seconds to store a DTC. Misfire is evaluated every 1,000 revs. A misfire DTC may be stored 60-90 seconds after the misfire initially occurred, at substantially different rpm and load conditions.

Mode $02 – Freeze Frame The message format used to retrieve freeze frame is as follows:

Mode $03 – Retrieve emission-related DTCs Mode $03 reports confirmed, emission-related DTCs. Service technicians and I/M test stations use this mode to determine what malfunction turned on the MIL. Mode $03 reports “history” codes for 40 warm- ups after the MIL is extinguished.

Mode $03 – Retrieve emission-related DTCs The message format used to retrieve emission- related DTCs is as follows:

Mode $04 – Clear DTCs and Diagnostic Information Mode $04 clears/erases DTCs and resets diagnostic data at the time a pending or confirmed DTC was stored. Diagnostic data includes freeze frame, I/M readiness, monitor status, PIDs for MIL_DIST, WARM_UPS, CLR_DIST, Mode $06 data. Service technicians can use this mode to turn off the MIL after a repair and to validate a repair.

Mode $04 – Clear DTCs and Diagnostic Information The message format used to clear DTCs is as follows:

Mode $05 – Retrieve Oxygen Sensor Data Mode $05 provides test results for oxygen sensors. This mode is no longer used for CAN applications. All data is still available using Mode $06.

Mode $05 – Retrieve Oxygen Sensor Data The message format used to retrieve oxygen sensor data is as follows:

Mode $05 – Retrieve Oxygen Sensor Data

Mode $06 – Retrieve OBD test results and malfunction limits Mode $06 provides monitoring test values and malfunction limits for various OBD monitors. Service technicians can use the data to see which monitors failed and by how much, or to validate repairs. Parts manufacturers can use this data to ensure replacement part compatibility.

Mode $06 – Retrieve OBD test results and malfunction limits Mode $06 test values and limits are un-scaled, decimal numbers in J1850, ISO 9141-2 and ISO 1423-4. Manufacturers need to provide conversion factors for technicians to utilize this data. ISO 15765-4 messages provide units and scaling as part of the message. Generic scan tools will be able to convert these to engineering units

Mode $06 – Retrieve OBD test results and malfunction limits The message format used to retrieve OBD test results is as follows:

Mode $06 – Retrieve OBD test results and limits

Mode $06 – Retrieve OBD test results limits

Mode $06 – Retrieve OBD test results and malfunction limits Example of Mode $06: TestIDCompIDTest Value Min Max $10$11Cat monitor switch ratio 45 0 48 Bank 1 $10$21Cat monitor Switch ratio 42 0 48 Bank 2 Conversion: multiply by 0.0156 to get a value from 0 to 1.0 Bank 1 = 45 * 0.0156 = 0.702 Bank 2 = 42 * 0.0156 = 0.655 Threshold = 48 * 0.0156 = 0.749 This catalyst is about to fail. A normal 100K catalyst should have a 0 to 0.1 switch ratio!

Mode $07 – Retrieve pending DTCs Mode $07 reports pending, emission-related DTCs. Starting in the 2005 MY, all pending DTCs must be reported, not just continuous pending DTCs. Starting in the 2005 MY, a pending DTC must be reported if the last monitoring cycle had a malfunction. Service technicians can use pending codes for faster validation or a repair.

Mode $07 – Retrieve pending DTCs The message format used to retrieve pending, emission-related DTCs is as follows:

Mode $08 – Request on-board device control Mode $08 allows a service technician to invoke an on-board test mode. Only one test mode (Test ID $01) is currently defined. It allows a service or an I/M technician to seal the evaporative system for a pressure test. On Ford systems, this closes the canister vent solenoid for a 10 minute time duration.

Mode $08 – Request on-board device control The message format used to request on-board device control is as follows:

Mode $09 – Retrieve vehicle information Mode $09 allows a service tech or I/M test technician to obtain vehicle VIN, module calibration number (CALID), Calibration Verification Number (CVN). VIN is required for 2005 MY, the vehicle can only report one VIN. CALID is required for 2005 MY. A unique CALID is required for each emission- related calibration on the vehicle. A unique CALID is required even if only a bit if data changes.

Mode $09 – Retrieve vehicle information (continued) A CVN must be supplied for each CALID In 2005 MY, CVN must be calculated every driving cycle and stored in Keep Alive Memory so that it can be retrieved with the engine off or engine running. CVN must not be erased by Mode $04. CARB must approve CVN algorithm. Manufacturers must provide CALID and CVN information to facilitate I/M testing.

Mode $09 – Retrieve vehicle information (continued) In the 2005 MY, CARB required industry- standard counters that display how often OBD monitors run during real-world driving conditions as compared to a CARB-specified driving cycle. In-use performance counters will be required for catalyst, O2 sensor, EGR, secondary air, and evaporative system monitors.

Mode $09 – Retrieve vehicle information The message format used to retrieve vehicle information is as follows: Info Type $02 is VIN, $04 is CALID(s), $06 is CVN(s), $08 is in-use performance counters

Inspection/Maintenance Readiness Many I/M test facilities will soon (Jan 1, 2002) be using OBD-II diagnostic information in place of tailpipe emissions tests. They will check MIL lamp, MIL status bit (PID 01, Data A, bit 7) and OBD monitor readiness (PID 01). For 2005 MY, they may check VIN, CALIDs and CVNs

Inspection/Maintenance Readiness (continued) CALIDs ensure that the correct (not recalled) software is on the vehicle. CVNs ensure that the module software was not tampered with. MIL status must not indicate “MIL on” during bulb prove out unless the MIL is being commanded on by a confirmed DTC. Monitor readiness bits must be in Keep Alive Memory

Inspection/Maintenance Readiness (continued) I/M readiness status may be displayed to the customer using the MIL. After 15-20 seconds of MIL prove out, the MIL can blink for 5-10 seconds if the vehicle is not ready for I/M testing. 2005 MY, CARB required a scan tool communication validation of every production calibration using a J1699-3 tool.

SAE/ISO Diagnostic Specifications Non-legislated diagnostic messages are defined by SAE J2190 and ISO 14229 These are commonly referred to “manufacturer- specific” test modes. Manufacturers can use these messages to perform manufacturer-specific tests and obtain manufacturer-specific data from any control module. Almost all manufacturers provide this info to the Equipment and Tool Institute (ETI), the consortium of scan tool manufacturers.

SAE/ISO Diagnostic Specifications Common uses for these messages are: Obtain manufacturer-specific PIDs Initiate on-board self-test Obtain packets of PID data (rapid data) Control module outputs Reprogram flash memory Configure modules The J2190 messages are very similar to the J1979 messages in structure and content. Only physical addresses are used, responses are required.

J2190 – Mode $13 Mode $13 reports all DTCs (emission and non- emission, confirmed and pending.) Very similar to Mode $03

J2190 – Mode $14 Mode $14 clears all DTCs. Very similar to Mode $04

J2190 – Mode $22 Mode $22 is used to get PIDs. PID numbers, scaling and units are defined by manufacturer and are specific to their individual systems. Very similar to Mode $01

J2190 – Mode $23 Mode $23 is used to download data by direct memory address. Test tool gets raw data.

J2190 – Mode $2A Mode $2A is used to get a string of PIDs in one message; a “rapid packet”. Used with Mode $2C to define rapid packet.

J2190 – Mode $30 Mode $30 is used to directly control module outputs like shift solenoids, IAC, AIR pump, EGR, etc. (requires Mode $27 security access)

J2190 – Mode $31 Mode $31 is used to request an on-board test, based on test number. Test Number On-demand Self Test Mode $81Key On Engine Off (gas and diesel) $82Key on Engine Running (gas and diesel) $84Output Test Mode (gas and diesel) $88Key On Engine Running Glow Plug Test (diesel) $91Key On Engine Off Injector Buzz Test (diesel) $92Key On Engine Running Cylinder Contribution Test (diesel) $95Key On Engine Running Switch Test (diesel)

J2190 – Mode $36 Mode $36 is used for reprogramming. (requires Mode $27 security access and Mode $34 Download Entry request)

J2190 – Mode $3F Mode $3F is used to indicate that the test tool is still online and prevent a diagnostic session time- out.

J2190 – Mode $7F Mode $7F is used by the control module to respond to a test tool request.

J1979 Message Traffic Example Clear DTCs (Mode 04) TX MSG: J1850PWM 61 6A F1 04 RX MSG: J1850PWM 01 6B 10 44 Request PIDs (Mode 01) [PID $00 defines which PIDs are supported ] TX MSG: J1850PWM 61 6A F1 01 00 RX MSG: J1850PWM 01 6B 10 41 00 BF 9F B9 10 Request PID 04 (LOAD_PCT) TX MSG: J1850PWM 61 6A F1 01 04 RX MSG: J1850PWM 01 6B 10 41 04 00 [LOAD_PCT = 0%] Request PID 05 (ECT) TX MSG: J1850PWM 61 6A F1 01 05 RX MSG: J1850[PWM 01 6B 10 41 05 4A [ECT = 74 deg F] Request PID 11 (TP) TX MSG: J1850PWM 61 6A F1 01 11 RX MSG: J1850PWM 01 6B 10 41 11 32 [TP = 19%] Request PID 1C (OBD Type) TX MSG: J1850PWM 61 6A F1 01 1C RX MSG: J1850PWM 01 6B 10 41 1C 01 [OBD_TYPE = 1 = OBD-II]

J1979 Message Traffic Example Request Mode 09 info TX MSG: J1850PWM 61 6A F1 09 00 [request Mode 09 items supported] RX MSG: J1850PWM 01 6B 10 49 00 01 FC 00 00 00 TX MSG: J1850PWM 61 6A F1 09 01 RX MSG: J1850PWM 01 6B 10 49 01 05 [number of VIN messages = 5] TX MSG: J1850PWM 61 6A F1 09 02 [item 02 = VIN] RX MSG: J1850PWM 01 6B 10 49 02 01 00 00 00 31 RX MSG: J1850PWM 01 6B 10 49 02 02 46 54 59 52 RX MSG: J1850PWM 01 6B 10 49 02 03 34 34 45 37 RX MSG: J1850PWM 01 6B 10 49 02 04 32 54 41 33 RX MSG: J1850PWM 01 6B 10 49 02 05 31 39 37 38 [VIN = 1FTYR44E72TA31978] Request Pending DTCs (Mode 07) TX MSG: J1850PWM 61 6A F1 07 RX MSG: J1850PWM 01 6B 10 47 01 13 01 02 00 00 [Pending DTC P0113, P0102 detected]

J1979 Message Traffic Example Request Freeze Frame Support (Mode 02) [PID $00 defines which PIDs are supported ] TX MSG: J1850PWM 61 6A F1 02 00 00 RX MSG: J1850PWM 01 6B 10 42 00 00 7F 98 00 00 Request Freeze Frame PID 02 TX MSG: J1850PWM 61 6A F1 02 02 00 RX MSG: J1850PWM 01 6B 10 42 02 00 01 13 [DTC that stored frame = P0113] Request DTCs (mode 03) TX MSG: J1850PWM 61 6A F1 03 [No response to OBD request, no DTCs] Request DTCs (Mode 03) TX MSG: J1850PWM 61 6A F1 03 RX MSG: J1850PWM 01 6B 10 43 01 13 00 00 00 00 [Stored DTC P0113 detected]

A “0” (low voltage) on the bus by 1 node wins over a “1” (high voltage) on the bus. 233 Bus arbitration

234 Bus Arbitration Flowchart

Data Information – Frame Format SOF – Start of Frame Identifier – Tells the content of message and priority RTR – Remote Transmission Request IDE – Identifier extension (distinguishes between CAN standard,11 bit identifier, and CAN extended, 29 bit identifier.) DLC – Data Length Code Data – holds up to 8 bytes of data CRC – “Cyclic Redundant Check” sum ACK – Acknowledge EOF – End of Frame IFS – Intermission Frame Space. Minimum number of bits separating consecutive messages.

Data Information - Protocol Messages are distinguished by message identifiers. The identifier is unique to the network and defines the content & priority of the message.

Data Information – Protocol (con’t) When several messages access the bus at the same time, the one with the higher priority “wins”. The identifier with the lowest binary number has the highest priority. The priority are specified during system design and cannot be changed dynamically.

Data Information – Protocol (con’t) Access conflicts on the bus are resolved by a “wired and” mechanism, where the dominate state overwrites the recessive state. All “losers” automatically become receivers and they won’t try to send another message until the bus becomes available again.

If one or more errors are detected, the transmission is aborted. This prevents all other stations or nodes from accepting the message. Re-transmission is automatic. If errors continue, then the station or node may switch itself off to prevent the bus from being tied up. Error detection is done on two levels: Message level Bit level Data Information – Error detection

Message Level CRC = Cyclic Redundant Check sum Frame Check = compares message to fixed format and frame size ACK errors = if transmitter does not receive an ACK signal from the receivers Bit level Monitoring = The transmitter monitors the bus signal as it sends the message and compares the bit sent to the bit received. Bit Stuffing = After five consecutive equal bits, the transmitter inserts a stuff bit with a compliment value into the bit stream. The receivers remove this stuff bit. Data Information – Error detection (con’t)

Implementations Basic CAN Limited number of receive buffers and filters Can get bogged down quickly with multiple consecutive messages.

Implementation (con’t) Full CAN Has several message objects (usually 15) Can loose data if message objects are setup for multiple filters Can still get bogged down if too many messages are sent consecutively

Implementation (con’t) FIFO “First In First Out” receive buffer Fixes problem with multiple consecutive messages Cannot allow a high priority message to move to front. It has to wait its turn

Implementation (con’t) Enhanced Full Can Dedicated FIFO for each individual message object Very complicated to use Less common

Over 20 different chip manufacturers produce microcontrollers with on-chip CAN interfaces. Some more notable ones are: Cygnal Intel Motorola NEC Phillips Toshiba Manufacturers

CAN Controller Diagram

One of the features of CAN and other network systems is that modules can send and receive "ok" signals to let the main control module know if they are working or not. In theory, this makes diagnostics easier. On the other hand, it also means that one misbehaving module may generate enough noise to disrupt the entire network causing a complete shutdown of the vehicle! 247 CAN DIAGNOSTICS

When a serial bus communication problem occurs, it will usually set a "U" diagnostic trouble code (DTC) and turn on the Malfunction Indicator Lamp (MIL). Depending on the fault, the vehicle may or may not start, or it may only operate in a "limp-in" mode with limited capabilities. Loss of communication between the engine controller and transmission controller (code U1026 on a GM, for example) may put the transmission into a limp-in mode where it will only operate in one or two gears. 248 CAN DIAGNOSTICS

Loss of communication codes may indicate a wiring problem on the bus, or a fault with a module. Isolating the fault may require unplugging modules one at a time until the fault is found. Just remember that all modules on a bus network need three things to function properly: power, ground and a serial data connection. 249 CAN DIAGNOSTICS

When diagnosing bus or module communication problems, you usually start by checking for voltage at the module, then the ground connection, and finally the data line. If all three are good but the module isn't working, the module needs to be replaced. 250 CAN DIAGNOSTICS

On GM applications, a code U100 or U1255 means a general loss of communication on the data bus. With a Tech 2 scan tool, you can go to Diagnostic Circuit Check, then Message Monitor to see a list of active modules and compare it to the list of modules that are supposed to be on when the key is on. 251 CAN DIAGNOSTICS

To minimize the parasitic current drain on the battery when the vehicle is off, a "sleep" signal is sent to the modules on the network. Some may remain on for a short period of time after the ignition is switched off (air bag module, for example), and some may never go to sleep (anti-theft module and keyless entry receiver, for example) but most are put into a sleep mode to save battery power. If the sleep signal is never sent, or a module fails to recognize the sleep signal, it may remain active and pull power from the battery. Depending on the current draw, this may run down the battery if the vehicle sits for a period of time. 252 CAN DIAGNOSTICS

Diagnostic Trouble Code numbers are read by plugging a CAN- compliant code reader or scan tool into the vehicle diagnostic connector (usually located under the instrument panel near the steering column). The presence of a code will turn on the Check Engine Light. The light will remain on until the code has been erased. The code number does not tell you which part has failed. It only indicates a possible fault has been detected in the circuit, system or sensor described. Further testing is usually required to isolate the fault BEFORE repairs are made. For diagnostic charts and vehicle specific repair information, refer to a service manual, or the OEM technical website. 253 CAN DIAGNOSTICS

U0001 High Speed CAN Communication Bus U0002 High Speed CAN Communication Bus Performance U0003 High Speed CAN Communication Bus (+) open U0004 High Speed CAN Communication Bus (+) low U0005 High Speed CAN Communication Bus (+) high U0006 High Speed CAN Communication Bus (-) open U0007 High Speed CAN Communication Bus (-) low U0008 High Speed CAN Communication Bus (-) high U0009 High Speed CAN Communication Bus (-) shorted to Bus (+) U0010 Medium Speed CAN Communication Bus 254 CAN DIAGNOSTICS

U0011 Medium Speed CAN Communication Bus Performance U0012 Medium Speed CAN Communication Bus (+) open U0013 Medium Speed CAN Communication Bus (+) low U0014 Medium Speed CAN Communication Bus (+) high U0015 Medium Speed CAN Communication Bus (-) open U0016 Medium Speed CAN Communication Bus (-) low U0017 Medium Speed CAN Communication Bus (-) high U0018 Medium Speed CAN Communication Bus (-) shorted to Bus (+) U0019 Low Speed CAN Communication Bus U0020 Low Speed CAN Communication Bus Performance 255 CAN DIAGNOSTICS

U0021 Low Speed CAN Communication Bus (+) open U0022 Low Speed CAN Communication Bus (+) low U0023 Low Speed CAN Communication Bus (+) high U0024 Low Speed CAN Communication Bus (-) open U0025 Low Speed CAN Communication Bus (-) low U0026 Low Speed CAN Communication Bus (-) high U0027 Low Speed CAN Communication Bus (-) shorted to Bus (+) U0028 Vehicle Communication Bus A U0029 Vehicle Communication Bus A Performance U0030 Vehicle Communication Bus A (+) open 256 CAN DIAGNOSTICS

258 Before CAN

259 With CAN The solution to this problem was the connection of the control systems via a serial bus system. This bus had to fulfill some special requirements due to its usage in a vehicle. With the use of CAN, point-to-point wiring is replaced by one serial bus connecting all control systems. This is accomplished by adding some CAN-specific hardware to each control unit that provides the "rules" or the protocol for transmitting and receiving information via the bus.

The CAN bus CAN is a broadcast type of bus. This means that all nodes can "hear" all transmissions. There is no way to send a message to just a specific node; all nodes will invariably pick up all traffic. The CAN hardware, however, provides local filtering so that each node may react only on the “interesting” messages. 260

261 Basic Configuration

The physical layer uses differential transmission on a twisted pair wire. The bus uses Non-Return To Zero (NRZ) with bit-stuffing. The nodes are connected to the bus in a wired-and fashion: if just one node is driving the bus to a logical 0, then the whole bus is in that state regardless of the number of nodes transmitting a logical 1. Max. transfer rate of 1000 kilobits per second at a maximum bus length of 40 meters or 130 feet when using a twisted wire pair which is the most common bus medium used for CAN. Message length is short with a maximum of 8 data bytes per message and there is a low latency between transmission request and start of transmission. The messages are protected by a CRC type checksum 262 CAN Bus Overview

The bus access is handled via the advanced serial communications protocol Carrier Sense Multiple Access/Collision Detection with Non-Destructive Arbitration. This means that collision of messages is avoided by bitwise arbitration without loss of time. There is no explicit address in the messages, instead, each message carries a numeric value which controls its priority on the bus, and may also serve as an identification of the contents of the message. An elaborate error handling scheme that results in retransmitted messages when they are not properly received. There are effective means for isolating faults and removing faulty nodes from the bus. 263 CAN Bus Overview

264 Basic Bit Encoding

265 CAN Bus Characterstics

Bus Characteristics – Wired AND 266 Only if all nodes transmit recessive bits (ones), the Bus is in the recessive state. If any one node transmits a dominant bit (zero), the bus is in the dominant state. T is Transmitter, R is receiver. Note nodes can therefore check the line while transmitting. This is important particularly during arbitration.

267 Bus Access and Arbitration – CSMA/CD NDA CSMA/CD NDA – Carrier Sense Multiple Access/Collision avoidance by Non Destructive arbitration

268 Bus Transmission Speed Arbitration limits bus speed. Maximum speed = 2 x t pd tpd = propagation delay of electrical medium

Specifies how small packets of data may be transported from point A to point B using a shared communications medium. It (quite naturally) contains nothing on topics such as flow control Transportation of data larger than can fit in a 8-byte message node addresses establishment of communication, etc. 269 The Can Protocol

Higher layer protocols are used in order to Standardize startup procedures including bit rate setting distribute addresses among participating nodes or kinds of messages determine the layout of the messages provide routines for error handling at the system level. Some high layer protocols Device net CANKingdom CANopen 270 Higher layer protocols

The CAN standard defines four message types Data Frame – the predominantly used message type Remote Frame Error Frame Overload Frame The messages uses a clever scheme of bit-wise arbitration to control access to the bus, and each message is tagged with a priority. The CAN standard also defines an elaborate scheme for error handling and confinement. CAN may implemented using different physical layers, and there are also a number of different connector types in use. 271 The CAN Standard

Summary: "Hello everyone, here's some data labeled X, hope you like it!" The Data Frame is the most common message type. It comprises the following major parts (a few details are omitted for the sake of brevity): The Arbitration Field, which determines the priority of the message when two or more nodes are contending for the bus. The Arbitration Field contains: For CAN 2.0A, an 11-bit Identifier and one bit, the RTR bit, which is dominant for data frames. For CAN 2.0B, a 29-bit Identifier (which also contains two recessive bits: SRR and IDE) and the RTR bit. The Data Field, which contains zero to eight bytes of data. The CRC Field, which contains a 15-bit checksum calculated on most parts of the message. This checksum is used for error detection. An Acknowledgement Slot; any CAN controller that has been able to correctly receive the message sends an Acknowledgement bit at the end of each message. The transmitter checks for the presence of the Acknowledge bit and retransmits the message if no acknowledge was detected. 272 The Data Frame

CAN Data Frames CAN 2.0A (“standard CAN” 11-bit ID) Data Frame. 273  CAN 2.0B (“extended CAN” 29-bit ID) Data Frame. Note 1: It is worth noting that the presence of an Acknowledgement Bit on the bus does not mean that any of the intended addressees has received the message. The only thing we know is that one or more nodes on the bus has received it correctly Note 2: The Identifier in the Arbitration Field is not, despite of its name, necessarily identifying the contents of the message.

Summary: "Hello everyone, can somebody please produce the data labeled X?" The Remote Frame is just like the Data Frame, with two important differences: It is explicitly marked as a Remote Frame (the RTR bit in the Arbitration Field is recessive), and there is no Data Field. The intended purpose of the Remote Frame is to solicit the transmission of the corresponding Data Frame. If, say, node A transmits a Remote Frame with the Arbitration Field set to 234, then node B, if properly initialized, might respond with a Data Frame with the Arbitration Field also set to 234. Remote Frames can be used to implement a type of request-response type of bus traffic management. In practice, however, the Remote Frame is little used. It is also worth noting that the CAN standard does not prescribe the behaviour outlined here. Most CAN controllers can be programmed either to automatically respond to a Remote Frame, or to notify the local CPU instead. 274 The Remote Frame

Remote Frame (contd.) There's one catch with the Remote Frame: the Data Length Code must be set to the length of the expected response message. Otherwise the arbitration will not work. Sometimes it is claimed that the node responding to the Remote Frame is starting its transmission as soon as the identifier is recognized, thereby "filling up" the empty Remote Frame. This is not the case. A Remote Frame (2.0A type): 275

The Error Frame 276 Summary: (everyone, aloud) "OH DEAR, LET'S TRY AGAIN" Simply put, the Error Frame is a special message that violates the framing rules of a CAN message. It is transmitted when a node detects a fault and will cause all other nodes to detect a fault - so they will send Error Frames, too. The transmitter will then automatically try to retransmit the message. There is an elaborate scheme of error counters that ensures that a node can't destroy the bus traffic by repeatedly transmitting Error Frames. The Error Frame The Error Frame consists of an Error Flag, which is 6 bits of the same value (thus violating the bit-stuffing rule) and an Error Delimiter, which is 8 recessive bits. The Error Delimiter provides some space in which the other nodes on the bus can send their Error Flags when they detect the first Error Flag.

Summary: "I'm a very busy little 82526 device, could you please wait for a moment?" The Overload Frame is mentioned here just for completeness. It is very similar to the Error Frame with regard to the format and it is transmitted by a node that becomes too busy. The Overload Frame is not used very often, as today's CAN controllers are clever enough not to use it. In fact, the only controller that will generate Overload Frames is the now obsolete 82526 277 The Overload Frame

278 ISO Physical Layer One of the most common and cheapest implementations is to use a twisted wire pair. The bus lines are then called "CAN_H" and "CAN_L". The two bus lines CAN_H and CAN_L are driven by the nodes with a differential signal. The twisted wire pair is terminated by terminating resistors at each end of bus line, typically 120 ohms.

279 CAN and EMI Due to the differential nature of transmission CAN is insensitive to electromagnetic interference, because both bus lines are affected in the same way which leaves the differential signal unaffected. To reduce the sensitivity against electromagnetic interference even more, the bus lines can additionally be shielded. This also reduces the electromagnetic emission of the bus itself, especially at high baudrates.

280 Standardization Vehicle bus system applications can be separated in three different categories according to their real-time capabilities. Class A for a low speed bus with bit rates up to 10 kbps, e.g for body control applications, Class B for a low speed bus with bit rates from 10 kbps to 125 kbps, e.g. for dashboard and diagnostics, Class C for a high speed bus with bit rates from 125 kbps to 1 Mbps for real time applications like engine management, Gearbox, ABS etc. For the use of CAN in vehicles two standards have been defined for the bus interface: CAN High Speed according to ISO- IS 11898 for bit rates between 125 kbps and 1 Mbps CAN Low Speed according to ISO- IS 11519-2 for bit rates up to 125 kbps

281 Bus Levels according to ISO-IS 11898 These are the bus levels according to ISO-IS 11898. A recessive bit is represented by both CAN bus lines driven to a level of about 2.5 V so that the differential voltage between CAN_H and CAN_L is around 0 V. A dominant bit is represented by CAN_H going to about 3.5 V and CAN_L going to about 1.5 V. This results in a differential voltage for a dominant bit of about 2V.

A Basic CAN controller Cheap CAN controller – CPU could get overrun with messages even if it didn’t need them. 282

Full CAN Controller Hardware message filters sort & filter messages without interrupting CPU 283

284 CAN (SAE J1939) Example: Caterpillar 797

Caterpillar example 285

Caterpillar example 286

1) Concrete State Monitor & Control Ssytem 288 Other applications of CAN

2 ) MRI Cooling System 289 Other applications of CAN

3) Tram Energy Recycle System 290 Other applications of CAN

What to do if the CAN system on a 2004 or newer vehicle won't talk to your scan tool The first items you will need to verify are power and ground circuits for the DLC (Diagnostic Link Connector located under the instrument panel). You must first disable the vehicle so that it cranks but does not start. You will then perform a voltage drop check on the system ground. The use of a DLC breakout box (as shown below) is preferred for testing. 291 CAN Communication Problem

292 CAN Communication Problem

Attach one meter lead to Pin# 4 of the DLC and the other lead to battery negative with the engine cranking. Perform the same test on Pin# 5 of the DLC to battery negative as well. This is a good dynamic test that should show a voltage drop of.2 volts or less. The next test on the DLC will be to check Pin# 16 for battery voltage. You must always refer to service information to verify that you are testing the proper pins. 293 CAN Communication Problem

The next step is to check communication circuits. There are terminating resistors that are used to reduce electrical noise on these communication circuits. A review of the schematics that refer to vehicle communication for the vehicle you are working on is a valuable asset to properly diagnosing a communication issue. It is strongly recommended that a DLC breakout box be used for testing. The first test procedure is to check between Pins# 6 and #14 of the DLC with an ohmmeter. This resistance check should yield a resistance value of approximately 60 ohms. 294 CAN Communication Problem

The next test is to check voltage information on DLC pin# 6 and 14. Pin# 6 is normally denoted as CAN-H and Pin# 14 is normally denoted as CAN-L. The voltage information can be checked with a voltmeter or lab scope. If a voltmeter is used, it is important to note that a peak min-max function should be used with a time testing window of 1ms or less. 296 CAN Communication Problem

The voltmeter cannot tell you the quality of the signal being produced. A lab scope gives a visual picture of the electrical quality of the signal that is present. A sample CAN voltage pattern on a lab scope is shown below for reference. 298 CAN Communication Problem

CAN H will have a voltage range of 2.5 to 3.5 volts, where as CAN L will have a range of 2.5 to 1.5 volts. The wiring on the vehicle must be checked for shorts to ground, voltage, or opens. If wires are next to each other, it is also possible for wires to be shorted to each other. In many cases, frayed wiring has contributed to lack of communication on many of the vehicles tested. It is also important to be able to attempt communication with the vehicle on the generic as well as the enhanced side. 299 CAN Communication Problem

It is possible for it to communicate one way and not the other. When a vehicle is at the test facility, the communication attempt is made on the generic side. In closing, the breakout box provides a way to view the communication activity under dynamic conditions. You must always check all feeds, all grounds, and serial data to a module before any replacement is considered. 300 CAN Communication Problem

CAN BUS CLASS. EARLY OBD In the early 1980s, many new vehicles began to be equipped with computers known as electronic control units (ECUs) used to control.

Similar presentations

Presentation on theme: "CAN BUS CLASS. EARLY OBD In the early 1980s, many new vehicles began to be equipped with computers known as electronic control units (ECUs) used to control."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

CAN BUS CLASS. EARLY OBD In the early 1980s, many new vehicles began to be equipped with computers known as electronic control units (ECUs) used to control.

Similar presentations

Presentation on theme: "CAN BUS CLASS. EARLY OBD In the early 1980s, many new vehicles began to be equipped with computers known as electronic control units (ECUs) used to control."— Presentation transcript:

Similar presentations

About project

Feedback