 | ||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||
|
From Fault to Function: Diagnosing software or programming faultsPosted 4/4/2002By Craig Zuidema
Many European cars now use multiple computers to control dozens of functions. These computers are often linked by a serial data controller circuit, which is referred to as a controller area network (CAN). The CAN is used to reduce wiring complexity and the duplication of expensive sensors. Not only does the CAN transfer sensor data between control units, it may also transmit symptoms caused by faulty components or by faulty software programming from one control unit to another. Often, a faulty component will store a fault code only in the control unit to which it is directly connected. However, it is becoming more common for faults in one system to cause symptoms in other apparently unrelated systems. Diagnostic nightmares created by software faults in today's gizmo-laden cars are becoming more evident each day. Diagnostic technicians are familiar with service bulletin information directing them to reprogram/reflash a powertrain control module (PCM) via a scan tool to correct a driveability symptom. When no failure codes are registered and no failed components are identified, is there a diagnostic strategy to use or a characteristic set of symptoms displayed that will guide a technician to the presence of a software or programming fault? Example: A 2000 Mercedes-Benz E320 is brought to the shop with a complaint of no radio, CD changer, navigation, roadside assistance, voice control or telephone operation. The factory scan tool, a Star Diagnosis System (SDS), is connected to the car and a short test is performed. The SDS is able to communicate with the computers that control these functions but cannot communicate with the radio, CD changer, navigation, roadside assistance, voice control or phone. No other relevant codes are stored in any other control units. A pin-out test is performed on the unplugged connectors of the control units to test for powers and grounds. The pin-out is OK. The fiber-optic cables that connect these devices pass the optical cable tester parameters. It seems nothing is wrong. Upon reconnecting the control units, normal function is restored to all components. Retesting with the SDS machine shows no fault codes are set. What happened to restore the function to these devices? Was there a link that caused them all to fail at once? The components became functional because disconnecting the power to the control units caused them to default to their basic programming and erase the volatile memory's learned functions. Is one of these control units learning a function that causes it to fail? Is this function then communicated to the other devices, causing them to fail too? The tech calls the manufacturer's technical hotline and after consultation, discovers a programming upgrade will cure the problem. The hotline specialist sends an e-mail containing a reflash procedure for the car's telephone. The e-mail must be downloaded into a personal digital assistant (PDA). Using an adapter cable, the tech reprograms the phone, and this fixes all the affected systems on the car. The symptoms don't return. In this case, the software programming in the phone's control unit had allowed a learned function, such as programming of the phone book, to overwrite and inhibit normal functions of the phone. The inhibited functions created a data fault that eventually disabled all the components using the fiber-optic cable network in the vehicle! Good thing the manufacturer chose to separate the serial data network of the powertrain from the comfort/convenience systems control units, or the vehicle's driveability might have been affected. One of the strongest clues to diagnosing software or programming problems is evident when test readings at components for known good values fall within specs, but incorrect readings are displayed on a factory-equivalent scan tool. Many generic scan tools (GSTs) do not have the capability to access necessary elements in vehicle computers and cannot fully diagnose a software-specific problem. You say, “Wait a minute ... this was all supposed to be fixed by OBD-II!” This highlights the difference between OEM (or equivalent) scanners and GSTs. A GST will allow you to retrieve and clear fault codes in the vehicle's OBD PCM, and on some cars, that is all you will be able to do with it. Due to variations between manufacturers, you may not be able to perform “relearn, reprogramming or adaptation” procedures, or to communicate with body control, safety or convenience modules. There may be no service bulletin on the symptom your vehicle is experiencing. Some repairs may exceed the ability of even the most skilled, knowledgeable and patient technicians if they do not have access to technical support. Sometimes the only way to find out about the fix is to find someone else who has experienced the same symptom and repaired it correctly. The repair on some cars can seem very hard when the fix is soft.
|
|||||||||||||||||||||||||||||||||||
Copyright (c) 1996-2008. Automotive Service Association. All rights reserved.
 | ||||||||||||||||||||||||||||||||||||
This information is provided by IDENTIFIX®. IDENTIFIX® resources cut diagnostic time and provide repair solutions that increase the shop's bottom line. From Repair-Trac pattern failure quick fixes, to Diagram-Online wiring diagrams by fax, to the Repair Hotline staffed by 32 master techs who specialize in diagnosing complex problems by phone or fax, IDENTIFIX® helps techicians fix more cars in less time.
