1st Place - Process innovations: Diagnostic Design Concept

Project details

And today? “The control switch ‘talks’ with the power window motor via an internal local network, and the motor checks for the right terminal connection status, in other words to determine whether it is allowed to move the window at all. The service technicians may spend a lot of time before they find out that the lifting mechanism isn’t working due to a missing variable in the motor.” Adam sums it up: “Moving from discovering a symptom to determining its cause is becoming an increasingly complex process.” Recognizing the need for improvement, Daimler researchers formed the Diagnostic Design Concept (D2C) project team in 2004.

The research prize the D2C project team won last December also confirms that it takes this kind of close cooperation to come up with viable ideas that can be consistently translated into improved product quality. This is a project that deals with more than just issues related to research and development. It’s an undertaking whose impact spreads to aftersales and even to the Mercedes-Benz service centers, where accurately identifying the cause of a fault immediately benefits the customer.

Adam remembers how things were back in 2004: “At that time, the biggest problem our team identified was the great difficulty in clearly distinguishing how the function of each electronic component affected all the others.” Essentially, Adam explains, the search for faults in the workshop relies above all on empirical knowledge in the form of an extensive collection of case studies in which certain symptoms from prior cases encountered in everyday practice can ultimately be attributed to a concrete instance of a component’s malfunction. This accumulated experience-based knowledge, in combination with the technician’s reliable intuition, are the most important guides in this situation. The comprehensiveness of this knowledge base’s catalogue of faults varies from case to case. The process is far from being a systematic search for faults, however. Or, as Adam sums it up: “The service technician in the workshop can never have the systematic knowledge of the developer — who knows all 200 input values of his components like the back of his hand and can therefore attribute a symptom to a specific component malfunction.”

For the D2C team, this was the problem that gave the project its direction: faults must be tracked down systematically. And that can be done only if the prerequisites are already established at the stage where a new function of a vehicle is established — during vehicle development. That means specifying the needed components, a process that also simultaneously defines the network of symptoms and causes.

At that time, the notion of taking diagnostic issues into account in this fashion as early as the vehicle development stage was a completely new idea. Previously, engineers from aftersales who assembled the diagnostic tools and materials for the workshops only started their work shortly before the launch of series production. The “diagnosticians” made contact with their colleagues from development sporadically rather than systematically — whenever some unclear question emerged, for instance.

The D2C project engineers recognized two critical deficiencies in this successive process. Should someone from diagnostics documentation discover that identical fault reports or a single fault code is generated by defects in two different components, it would be far too late to remedy this inadequate diagnostic precision by means of, for example, simple modification of the control software. By this point the software would have passed all quality checks, and no supervisor would want to unnecessarily jeopardize the software’s status of market readiness by once again revising the source code. As for the second point, Adam points out: “In discussions with the colleagues in development, we recognized quite quickly that they already had what we needed for systematic and function-oriented diagnostics — namely FMEA methodology.”

FMEA (Failure Mode and Effects Analysis) is based on a tremendous wealth of documentation. Following fixed formal rules, this documentation is used to systematically check how a certain part malfunction impacts a component and the overall system in which the component is imbedded. The investigation moves from the cause of the malfunction to the symptoms or effects that result from it. In the FMEA the component developer immediately recognizes whether a little problem can have a major impact or whether the defect is only marginally noticeable or, in the best case, doesn’t result in a loss of function.

The development engineers essentially use this tool to verify how good and how robust the designs, or specifications, of components and the overall system are. If a diagnostician also now verifies the FMEA by following the pathways exactly in the opposite direction, from the symptom to the cause of the malfunction, he finds out precisely which data and information he needs in the workshop in order to clearly attribute this symptom to a defective part. “We included the testing specification as an additional analysis level in the FMEA,” explains Adam, adding: “For the first time we precisely know the diagnostic coverage, that is to say the effectiveness of our service testing unit, because we can automatically evaluate the diagnostic specification.” That is very advantageous, particularly when it comes to safety-related systems.

One hundred percent diagnostic coverage is not useful in the case of every fault or malfunction, however: it doesn’t pay to invest too much in diagnostics for cheap replacement parts. When the fault is still uncertain, it's better to simply replace two parts of this quality. Also, if there are different degrees of probability for a malfunction or failure when a symptom can be caused by different faults, the pragmatic approach is a good bet. If you know that a symptom is caused in 99 of 100 cases by a defective pump, and in one case by a bad control unit, a good option is to just replace the pump instead of conducting another 30 minutes of diagnostic procedures.

It's amazing how the voluminous diagnostic knowledge that the D2C team has generated in the various pilot projects — which encompass components and functions in the powertrain and in the vehicle’s interior and exterior — remains pleasantly concealed in the background. In the workshop, this mass of knowledge is essentially reduced to a simple color coding system. Ralph Ricker of the D2C team demonstrates this by using the example of a fault in a power trunk lid.

For the symptom “trunk lid fails to open completely,” the engineers have refined the diagnostic software in the workshop testing unit in a manner that ensures that the principle behind the process is clear. After the diagnostic equipment is plugged into the vehicle and a symptom is selected, all of the components that, if defective, could be the cause of the symptom appear on the monitor. In the background, the diagnostic computer checks the vehicle, reading all the fault codes, or byte fields, that are relevant to this case and can point the way to the defective component, using a process of elimination to arrive at the cause of the problem.

In the end, the results are reduced to three signal colors. All of the involved components that are properly functioning and free of faults are lit in green. Components that are functioning flawlessly in terms of technology but, due to a specific vehicle situation — for example, an open door — are blocking the function in question appear in yellow. Lit with a bright red light are defective components that must be replaced in order to remedy the malfunction.

“Our goal,” Ricker concludes, “was to visualize the technological knowledge behind the diagnosis of functions in a way that ensures that the problem can be found at a single glance in the workshop.” And this will soon be the case. With the new-generation “XENTRY” software for the Mercedes-Benz workshop testing unit, the “dragnet” for irksome faults will be applied for the first time in everyday use.