WO2000016060A1

WO2000016060A1 - Method and system for diagnosing complex distributed systems, preferably implemented in vehicles

Info

Publication number: WO2000016060A1
Application number: PCT/SE1999/001544
Authority: WO
Inventors: Matts Lindgren
Original assignee: Mecel Ab
Priority date: 1998-09-10
Filing date: 1999-09-06
Publication date: 2000-03-23
Also published as: SE9803088L; DE19983537T1; SE511967C2; SE9803088D0

Abstract

The invention relates to a method and a system for diagnosis of faults in distributed systems, preferably but not exclusively for distributed electrical systems in vehicles. The distributed system is systematically documented in its entirety in a database (61) as a number of mutually autonomous user functions (70a-70d), each of which entails a functionality of value perceivable by the user. These user functions are documented in a chain of subfunctions, whereby several subfunctions can occur is several user functions, which user functions are then termed overlapping function domains. In accordance with the invention this documentation is used for troubleshooting to exclude non-defective subfunctions from further troubleshooting in defective user functions. By comparing defective user functions with non-defective user functions, systematic and preferably computer-aided troubleshooting can rapidly be implemented.

Description

METHOD AND SYSTEM FOR DIAGNOSING COMPLEX DISTRIBUTED SYSTEMS, PREFERABLY IMPLEMENTED IN VEHICLES

The present invention relates to a method of diagnosing complex distributed systems, in accordance with what is given in greater detail in the introduction of claim 1 , and a system for the execution of the method in accordance with what is given in greater detail in the introduction of claim 9

STATE OF THE ART In the diagnosis of composite systems, different techniques have been developed to facilitate troubleshooting for the repairer in charge For motor vehicles, an extensive amount of work is spent developing and distributing workshop handbooks for each individual model of vehicle, and these models of vehicle can often be fitted with different subsystems, and there too the subsystems in the models vary from year to year This means that the scope of the information which the car repairer can consult easily becomes extremely extensive, and this produces a deterrent effect In these workshop handbooks there are often troubleshooting tips involving different defective functionalities having a number of different causes for the fault given in a list, whereby the causes for the fault may be listed in descending order of probability This probability for the fault can be a calculated or empirically established susceptibility to breakdown To a large extent, however, initial troubleshooting takes place based on the previous experience of the repairer himself

As the systems become more and more complicated, special diagnostic equipment is developed This may be unique to the system to be diagnosed A more universal way is to use a single diagnostic instrument for connecting up to the vehicle via a diagnosis outlet common to all diagnosable subsystems Different symptoms of faults can then be diagnosed internally in the vehicle using automatic, repeated diagnostic routines which check different functionalities in the vehicle When these functionalities are found to be defective, fault codes are formed which are stored in a memory in the system and can later be read off using a diagnostic instrument during servicing Fault codes from the system can also be read off by causing signal lamps to be activated in a "message function", for example causing a "check engine" lamp to flash in a signalling sequence indicating a unique, fixed code for the type of fault in question Through PCT/SE96/01244, for example, a diagnostic system for vehicles' engine control systems is known whereby different concepts for handling of these fault codes are mentioned. For example, when a fault code is formed, all diagnostic routines which "may be affected by the defective functionality" are blocked, and at the same time the diagnostic routines which may affect the defective functionality are re-prioritised for immediate diagnosis. Only the basic fault which has caused later functionalities to display faulty behaviour is saved, which reduces the number of so-called resultant fault indications. The subsystems forming part of the diagnosed system configuration and their diagnostic routines are described in a checklist in which all interdependent diagnostic routines are given.

The system indicated in PCT/SE96/01244 may to a certain extent reduce the number of fault codes generated, and be a helpful contribution to identification of the basic fault, but it is practically impossible to implement diagnostic routines covering all types of fault cases in a distributed system.

OBJECT OF THE INVENTION

The object of the invention is to facilitate diagnosis of complex systems with defective functionality, either in conjunction with the service garage receiving a fault report from the driver of the vehicle or when the repairer performs troubleshooting in the vehicle.

A further aim is, with the aid of other functionalities with subfunctions in common with the defective function, to be able to eliminate correctly-functioning subfunctions from the troubleshooting, thus reducing the time taken on troubleshooting. The invention also allows primary troubleshooting of a user functionality to be performed dynamically during operation by the driver of the vehicle, whereby the driver of the vehicle can be in contact with the service workshop by means of wireless communication, and under guidance can confirm or deny full functionality of other user functions with overlapping subfunctionalities.

Yet another aim is to provide a complement to troubleshooting in systems in which fault codes are also generated and stored in systems during operation.

Through the vehicle's system being described based on functions perceivable by the driver, the vehicle user's perception of the behaviour of the system can be simply used to restrict troubleshooting to a minimum By vehicle user is meant a driver, a passenger, a service mechanic about to service the vehicle, or a person in authority intending to check that that vehicle has the correct functionality

SUMMARY OF THE INVENTION

The method in accordance with the invention is denoted by the characterising part of claim 1, and the system for implementing the method in accordance with the invention is denoted by the distinguishing section of patent requirement 9

Through use of the method in accordance with the invention and the system, one can rapidly restrict the area within which one should perform troubleshooting The systematic descπption of the system in a number of autonomous user functions, including a number of subfunctions, facilitates simple, computer-aided isolation of the faults to probable defective functions in particularly complex systems constructed using multiplex technology

Other characteristic features and advantages of the invention can be seen from the characteπsing parts of the other claims and the subsequent description of embodiments The description of the embodiments refers to figures indicated in the following list of figures

LIST OF FIGURES

Figure 1 shows a first user function described in the form of a chain with subfunctions Figure 2 shows a second user function described in the form of a chain with subfunctions,

Figure 3 shows a third user function described in the form of a chain with subfunctions Figure 4 shows in tabular form the principles of a systematic form of documentation of functionalities in composite systems, Figure 5 shows a documentation of subfunctionalities with the relevant fault probability and description of subfunction,

Figure 6 shows an overview of a system for performing diagnosis of a composite system in accordance with the invention, Figure 7 shows in greater detail certain sections of a system for diagnosing a composite system in accordance with the invention, Figure 8 shows an alternative method of visualising a function chain and Figure 9 shows a stylistic function chain in accordance with figure 8.

DESCRIPTION OF EMBODIMENTS

The invention is based on the vehicle systems being systematically described as a number of autonomous user functions, the most characteristic feature of which is that they provide a function perceivable by the vehicle user. A perceivable function such as this can also be termed an "out-function". This user function is always something in which the user sees value or a benefit, and which the user considers it meaningful to make demands of.

Each user function identified consists of a logical chain of internal functions or subfunctions which, starting from a root function and proceeding via a number of subfunctions, finally produce a percievable functionality. How the subfunctions are implemented on a purely practical level is of no consequence at all from the point of view of the user. Different user functions can have one or more subfunctions in common.

These subfunctions then become overlapping functions, and these overlapping functions are systematically used to facilitate troubleshooting in accordance with the invention.

In the following section, 3 examples of documented user functions will be described.

1st User Function: Show Speed

Figure 1 shows an example of a first documented user function, the functionality of which is perceivable by the vehicle user. This case describes the user function "show speed". The user function "show speed" is in turn divided up into a chain of subfunctions 10-20. Whether the correct speed is shown on the vehicle's speedometer can in newer types of instrument panel depend on there not being sufficient voltage in the battery 10. In older systems the speed indicator could be affected by a mechanism driven by a wire, but this mechanical type is not shown here.

The battery 10 supplies voltage to a sensor 12 via a power supply cable 1 1, and depending on how quickly a cogged wheel moves past the sensor 12, a pulsed output signal is received on a line 13, whereby the pulsed output signal has a frequency dependent upon the current speed. A speed sensor 12 can for example be mounted on the outgoing axle of a gearbox, or alternatively on a wheel axle of a non-driving wheel on the vehicle. The signal generated by the sensor 12 is led to a calculation or conversion unit 15 via line 13 and connections 14, in which calculation unit the signal is converted to a suitable unit 16 for the speed signal This speed-signal unit 16 could preferably be emitted on a serial data bus 17, for example a CAN bus or similar, whereby this speed signal can be made available to several subsystems in the vehicle Use of a speed sensor which emits a speed signal on a seπal bus reduces the need for duplication of speed indicators for different types of system which all require a speed signal

The value 16 of the speed signal on bus 17 can be read off using an instrument panel node via input terminals 18 In the instrument panel node, the speed signal is fed to a dπver 19 which drives the speedometer's actuator 20, with the relevant indicator

Through the indicated subdivision of the user function "show speed" into several subfunctions, a logical interconnection of different subfunctions is attained

From the physical point of view, the subfunctions can be implemented in different components For example, battery 10 and power supply 11 can be included in the electrical system using a unique cable 11 for power supply to the sensor This power supply can also include a fuse between battery 10 and cable 11 Sensor 12 can also be equipped with a unique cable 13 for the pulsed output signal, whereby the output signal is led to an engine node containing the moments 14-16 By engine node is meant primarily a control device set up on or near to the engine unit, which control device primarily controls engine functions, but also includes means of converting or calculating a speed signal The engine node's connections 14 lead the pulsed signal to a CPU which converts the continually pulsed signal to a unit 16, for example km/h or mph

The communication bus 17 can be a speed bus which transfers global data between different temporally critical functions in the vehicle needing rapid updating to maintain the required response in the system In another alternative the communication bus 17 can be divided up into a first high-speed bus, which via a gateway transfers the speed signal to a low-speed bus On the low-speed bus there are typically arranged non-temporally critical systems which mutually transfer global information An instrument panel is one such non-temporally critical system, whereby data only needs to be updated a few times a second The instrument panel node can contain moments 18-20, whereby connections 18 to the instrument panel node lead the speed signal to the driver and the indicator on the instrument panel __

2nd User Function Cruise control

Figure 2 shows a second documented user function perceivable by the vehicle user In this case the user function is restricted to the cruise control function, which takes as its starting point the speed signal for the regulation of the engine starter, dependent on whether cruise control is activated

In the same way as for the user function "show speed", battery 10 supplies voltage to the sensor 12 via the power supply cable 11, and a pulsed output signal from the sensor is led via line 13 to a calculation or conversion unit 15 via connections 14 In the calculation unit the signal is converted to a suitable unit 16 for the speed signal for further distribution of this speed value on a serial data bus. Subfunctions 10-17 are thus overlapping subfunctions in the two user functions "show speed" and "cruise control" The thus converted unit for the speed signal is led via bus 17 to the cruise control device's physical control unit via input terminals 21. In the cruise control device's control unit a number of checks are performed before the function "apply cruise control" in the cruise control device is activated In a first stage 22 a check is carried out that the cruise control device is turned on, which is a condition for the cruise control function being activatable In a second stage 23 a check is carried out as to whether the vehicle user has registered a suitable theoretical speed. Registration of a suitable theoretical speed normally takes place by the vehicle user pressing a "set speed" button on the cruise control regulator, resulting in the current vehicle speed being read into a memory containing the theoretical value for the cruise control's target speed for the vehicle In a third stage 24 a check is made that the cruise control function has not been deactivated Deactivation can take place either through the brake pedal or the clutch pedal having been affected during the time cruise control tries to keep to the registered target speed In a fourth stage 25 a check is made as to whether "resume" has been activated The "resume" function means that the most recently stored theoretical speed shall be resumed In the fifth stage a comparison takes place between the fixed target speed and the vehicle's current speed Thus if the cruise control function has been turned on (stage 22) and a target speed has been registered (stage 23), the speed regulation is automatically activated provided deactivation has not taken place (stage 24)

Speed regulation takes place by affecting the throttle lever, usually in the form of a throttle in a petrol engine with indirect injection, in stage 27, and this throttle regulation occurs in proportion to the difference between the target speed and the current vehicle speed

3rd User Function Show Engine Temp

Figure 3 shows a third documented user function In this case the user function "show engine temp " is described. In a way corresponding to that used for the user function "show speed" this user function is based on a battery 10 applying voltage via a line 41 to a sensor 42 necessary for temperature measurement The sensor 42 can in a conventional way be set up in the engine's cooling system, whereby the temperature of the coolant water is detected.

The signal generated by sensor 42 is led via line 43 and connections 44 to a calculation or conversion unit 15', in which calculation unit the signal is converted to an appropriate unit 45 for the temperature signal This value for the temperature signal 45 is best emitted on a serial data bus 17, for example a CAN bus or similar

The value 45 for the temperature signal on bus 17 can be read off using an instrument panel via inputs 18 In the instrument panel node the temperature signal is fed to a driver 19 which drives an actuator 50 for a temperature meter, with its indicator

In the same way as for the user function "show speed", the battery 10 supplies voltage to the appropriate sensor using separate power supply cables 11 For the adaptation of the units for the property measured, the conversion is best carried out in the same node (15 or 15'), and the converted value for the quantity measured is emitted on the same communication bus 17 to the instrument panel node's connections 18 and driver 19 The subfunctions 10, 17, 18, 19 and perhaps 15' from the user function "show temp " are thus subfunctions overlapping with the user function "show speed" Method of documentation for the user functions

Figure 4 shows an example of the form of systematic documentation of user functions In the form of a two-dimensional matrix, each individual function such as "show speed"/ "cruise control" can indicate which types of subfunction or internal function taken together provide the current user function The method means that all subfunctions included in the documentation are necessary for achieving a complete user function which is self-contained and autonomous This documentation is performed for all functionalities which the user can verify The result of this documentational method means that subfunctions which are common to more than one user function will be part of the descπption of each affected user function It is appropπate to name these mutual subfunctions overlapping subfunctions or overlapping function domains

Each individual internal function has a specific place in the matrix, and this place is indicated by the position in the horizontal and vertical planes In position 23, i e position 2 in the vertical plane and position 3 in the horizontal plane, in accordance with the figure it can be indicated that a subfunction constitutes subfunction number 3 in the current user function

What this subfunction constitutes physically can be taken from a separate list, see figure 5, where posιtιon/# 23 indicates that the subfunction is a physical sensor of the type AB2 The list can also include an established error factor, here MTBF 10000 (Mean Time Between Failures), and in addition its physical location in the vehicle

By using documentation of user functions in accordance with figure 4, rapid sorting of other user functions with the most subfunctions in common can be implemented in a laptop or desktop computer Descriptions of what the respective subfunctionahty corresponds to, as well as its likelihood of breakdown, can likewise be stored in the computer memories, for access in connection with assistance in the event of troubleshooting

Types of documentational method other than the matrix form complete with table, as shown, can also be used The essential thing is that all user functionalities are documented throughout as mutually autonomous user functionalities, whereby, however, one or more subfunctions can be common to these user functions Diagnostic system

Figure 6 shows an overview of the components necessary in a diagnostic system in accordance with the invention. All documented user functions for the vehicle in question are stored in the database 61. Access to these documented user functions is controlled by a selection function 62, which can be controlled via a laptop or desktop computer searching for special user functions.

Linking up the diagnostic system to the vehicle can take place via wireless communication 64-66a-66b or via a physical linkable diagnostic interface, 63-65a-65b.

An advantage of wireless communication is that the user of the vehicle can connect up to the service workshop or the database 61 during operation of the vehicle, and preferably in conjunction with the user perceiving a defective functionality in the vehicle. In the service workshop a repairer or customer reception officer can be placed in connection with the vehicle user via a terminal 60, 60a, 60b.

Through use of a structured search technique led by the customer reception officer, a defective user function can be identified from amongst those stored in the database 21. Figure 7 shows more clearly what is required for identification. In database 61 there is a complete compilation of user functions for a number of models of car - car Nl, car N2 etc. - showing where the respective models of car can occur in a number of variants - type 1, type 2 etc. Each specific variant has its own full list of documented user functions, preferably corresponding to the technique of documentation shown in figure 4 Selection of the correct list of user functions takes place via an administrative function in the database.

In the selection function 62 can be found the support necessary for the diagnosis. In a first stage 62b, assisted identification of defective user functionality is initiated. This is implemented through use of an appropriate search technique, whereby the user or the repairer/customer reception officer gradually restricts the search to specific user functions. For example, gradual restriction can take place through an interactive question procedure with different menus at a more and more detailed level. In a first menu a question can be posed as to whether the user function relates to an area such as lighting, engine, air-conditioning or similar. In underlying menus, questions concerning more and more detailed user functionalities can then be posed. Identification of a defective user functionality can take place through the repairer/customer reception officer going through question menus on terminal 60a whilst the end user assists with answering the questions Another alternative can be that the user is in the vehicle and goes through the question menus with the repairer/customer reception officer by means of wireless voice contact A third alternative can be that the user himself answers questions put to the user automatically via a wireless contact at automated service assistance The questions can be presented to the user/driver using speech via the vehicle's speaker system or visually on a screen in the vehicle

After the user has identified and confirmed the defective user function, a comparison 62c is automatically initiated between the identified defective user function and other documented user functions In order quickly to be able to exclude as many subfunctions as possible from the troubleshooting, those user functions are prioritised which have the most or a predetermined proportion of common subfunctions in the comparison in stage 62d The user/driver is then asked whether the other user function, with which the defective user function is being compared, is also defective If the user/driver then answers that the other user function is working, then the subfunctions which are common to the defective and the compared user function are excluded from further troubleshooting in stage 62e The comparison with other user functions is carried out as long as there are other user functions which have some subfunction in common with the defective user function which has not been excluded from the troubleshooting in stage 62e

In certain implementations subfunctions which are not common can also be eliminated if upon checking one finds that the compared user function does not have full functionality either If the system has a singular fault, then the fault can be found in the common subfunctions There is, however, a certain πsk that the system is affected by several faults, which means that an exclusion of the subfunctions can be less desirable

By means of this procedure, troubleshooting can gradually reduce the number of subfunctions with which there can potentially be a fault It is not usually possible to achieve reduction to just one subfunction, but instead a small number of subfunctions remain as probable causes of the fault With the aim of more rapidly achieving a reduction of subfunctions different methods of optimisation can be used, whereby one selects the comparative user function in accordance with a predetermined proportion of common subfunctions For example, comparative user functions can be selected whereb> these comparative user functions must have as near as possible to half of the remaining and not yet eliminated subfunctions Furthermore, at each iterative stage one can be forced to ensure that as clearly differentiated subfunctions as possible are selected for the comparative user function in the subsequent stage

In certain systems a very large number of user functions can have the majority of the subfunctions in common with each other. If one selects different user functions for successive comparisons with the same common subfunctions, one risks attaining an effective reduction of probably defective subfunctions

Diagnosis case 1

Troubleshooting in accordance with the invention of a user function corresponding to the one shown in figures 1 and 2 is described below It can be assumed that the vehicle user notices that the cruise control function is not working

At customer reception at a service workshop the customer reception officer can by questioning the vehicle user identify that the "cruise control" function, figure 2, is the defective function A subsequent comparison with other user functions takes place, whereby for example "show speed" in accordance with figure 1 can be another user function which has been identified by the diagnostic system as having the most subfunctions in common The diagnostic system then follows this up by asking, for example via the screen 60a, whether this other user function, I e "show speed", is also displaying defective functionality If the user/driver then replies that this other user function works without any defects, then the diagnostic system can reduce the number of probable defective subfunctions, i e exclude the subfunctions 10-17 In this case the diagnostic system can then recommend that the probable defective subfunction is to be found in one of the subfunctions 21-27

Diagnosis case 2 Troubleshooting, in accordance with the invention, of another user function corresponding to the one shown in figure 3 is described below One can assume that the vehicle driver notices that the speedometer displays too low a speed

At customer reception the defective user function is identified, i e the user function "show speed "/figure 1 A subsequent comparison then takes place, for example with the user function "cruise control "/figure 2, the user function with the most subfunctions in common The diagnostic system then follows this up by asking, for example via screen 60a, whether this other user function, i e "cruise control", is also displaying defective functionality If the user/driver then replies that this other user function is working without any defects, then the diagnostic system can reduce the number of probable defective subfunctions, 1 e exclude the subfunctions 10-17 In this case, the diagnostic system can then recommend that the probable subfunction is to be found in one of the subfunctions 18-20 In a continued comparison with further user functions, a further user function is identified, "show engine temp'Vfigure 3, which has subfunctions in common with the subfunctions 18-20

The diagnostic system then follows this up by asking, for example via screen 60a, whether this other user function, I e "show engine temp ", is also displaying defective functionality, i e the pointer is not in the middle of a certain area of the temperature indication field after 5 minutes of engine operation In the user/driver then replies that the pointer is in the middle of the temperature indication field, then the diagnostic system can reduce the number of probable defective subfunctions, i e exclude the subfunctions 18- 19 In this case the diagnostic system can recommend that the probable defective subfunction is to be found in subfunction 20, l e the indicating instrument itself

Another defective user function

In the event that another defective user function should be identified during diagnosis, the subfunctions common to the first and the second defective user functions can be identified as probably defective In certain cases, certain user functions can be defective without the vehicle user noticing it In an implementation of the diagnostic method in accordance with the invention in vehicles where diagnosis can take place by wireless means to a service workshop during operation of the vehicle, a request can simply be made that non-activated functions be activated to check their functionality

Further comparisons with other user functions are then performed with priority given to the user functions with the greatest number of subfunctions in common with those previously identified as the ones most likely to be defective

Method in accordance with the invention combined with fault probability and/or own diagnosis Of the subfunctions remaining following elimination in accordance with the invention of probably non-defective subfunctions, these remaining subfunctions can be prioritised as probably defective, dependent on the calculated or tested fault probability for the respective subfunctionality. This fault probability can be stored for each individual subfunctionality in the lists corresponding to the one shown in figure 5, whereby the fault probability is given as MTBF (Mean Time Between Failures).

In the event that certain subfunctions have their own diagnosis, prioritisation of the subfunctions with a fault code indicating defective function can be applied.

If use is made of a global database 61 facilitating access to all service workshops and/or vehicles, the fault probability value in the database can be updated depending on what measures have finally been necessitated to rectify the defective function.

Alternative description of a user function

Figure 8 shows an alternative description of a user function implemented in another environment. The user function illustrated in figure 8 is "show speed", which is displayed on instrument Al . For determining and displaying the speed, two distributed nodes are used - an ABS control device, CPUl, and an instrument panel node, CPU2. CPUl receives its power supply from a battery via fuse cabling and a contact, corresponding to BAT-F1-W1-K1, and CPU2 receives its power supply in a corresponding manner via BAT-F2-W2-K4. The respective nodes, CPUl and CPU2, contain software Cl and C2, which handles conversion of quantities.

In the ABS control device CPUl, measurement of the vehicle's speed is made using a sensor SI. The signal is received via cabling W3 and contact K2. Conversion of the sensor Si's output signal to an appropriate magnitude of speed then takes place in the software C 1. This magnitude of speed is subsequently emitted via the contact/interface K3 as a data message on the communication bus W4. The instrument node CPU2 reads off the data message on bus W4 which carries this magnitude of speed signal. The software C2 in the node CPU2 subsequently converts the magnitude of the speed signal to an appropriate output signal which is sent via the contact K5 to a pointer Al . In figure 8 the common function domain is encircled with broad lines The physical nodes CPUl and CPU2 are ringed with finer lines, whereby the nodes' contact points with other system cabling is shown by contacts K1-K5

In the node CPUl, for example, there can be subfunctions not included in the function domain "show speed" An example of such a function is brake-pressure monitoring, for which a pressure sensor S 11 monitors the pressure in the brake system Via a contact K22 the pressure sensor's signal is transferred to a conversion function CIO, which converts the output signal from the sensor to a suitable size In a corresponding manner there can also be nodes CPU3 which do not constitute part of the function domain for "show speed" At a service it is a good idea to visualise the current system in the vehicle on a computer screen, as in figure 8 The subfunctions included in the function domain can be marked by greater intensity or choice of signalling colours Surrounding nodes subfunctions and cabling can then be indicated subtly, which gives a better picture of the composition of the system, at the same time as the function domain examined is illustrated in its entirety

Figure 9 shows how the system in figure 8 can be documented in chains from root functions, FI, SI and F2, up to the final "output function" Al, which shows symptoms of faulty behaviour perceivable by the vehicle user This type of structured documentation is highly appropriate for computerised identification of overlapping function domains

Troubleshooting for basic cause

After eliminating subfunctions not likely to be defective, a number of internal functions remain as more or less probably defective To identify the basic cause of the fault symptom, the diagnostic system can identify the remaining internal functions situated furthest away from the output function These remaining internal functions situated furthest away from the output function are allotted a higher probability of fault relative to internal functions situated closer to the output function Furthest away does not refer to the physical distance, but instead the internal functions with the most intervening internal functions

The invention can be modified in a number of ways within the definitions of the enclosed patent claims For example, the systematic documentation of user functions can be carried out in a way other than a matrix arrangement as in figure 4 Any other form can be implemented provided it is suitable for computer-aided comparison between user functions with the aim of finding common subfunctions.

User functions corresponding to those shown in figures 1-3 can be documented in a manner other than the one shown. A user function can have several root functions, i.e. a subfunction can actually be affected by more than one previous subfunction, which produces a user function branching out like a tree from the perceivable functionality. The user functions must, however, be described as directed sequential subfunctions, directed from at least one root to a so-called output function, i.e. a function perceivable by the vehicle user.

The interactive question procedure can be implemented in PC format on a personal computer 60, 60a, 60b, for example in the Windows environment, whereby a customer reception officer/repairer goes through a number of question menus controlled by the current set-up of user functions for the vehicle in question.

The question procedure can also take place in the vehicle, whereby questions for identification of defective user functions and questions about other user functions with which the defective user function is being compared with can be presented via loudspeakers or via screens in the vehicle.

Claims

PATENT CLAIMS

1 Method of diagnosing faults in distributed systems, preferably but not exclusively for distributed electrical systems in vehicles, whereby different user functions in the system have at least one mutual, overlapping internal function or subfunction c haract eri s ed by

- the vehicle's functionalities being documented as a number of self-contained and mutually autonomous user functions, whereby the respective user function is made up of a functionality perceivable by the vehicle user, and whereby each user function consists of a number of internal functions linked in a chain from at least one root function to a final perceivable functionality, which internal functions taken together provide the desired user function,

- in the event of a symptom noticed by the vehicle user, at least one first user function being identified as being logically linked to the symptom,

- other user functions being identified which have at least one internal function in common with the user function which is logically linked to the symptom, and these other user functions being checked with regard to functionality,

- and all internal functions in the first user function which is logically linked to the symptom being eliminated as potential causes of the fault, if these internal functions are common to internal functions from other checked user functions with full functionality

2 Method in accordance with claim 1 ch arac t e ri s e d b y all internal functions in the first user function which is logically linked to the symptom being eliminated as potential causes of the symptom if these internal functions are not common to internal functions from other checked user functions without full functionality

3 Method in accordance with claim l or 2 c h aract e ri s e d b y the first user function which is logically linked to the symptom being checked against other user functions in an iterative process, whereby other user functions not previously checked are selected for checking, dependent on a predetermined proportion of mutual internal functions amongst the remaining internal functions which have not been eliminated from the first user function

4 Method in accordance with claim 3 charact eri s e d b y the fact that where other user functions not previously checked are selected for checking, this depends on as near as possible half of the number of internal functions not yet having been eliminated from the first user function

5 Method in accordance with claim 3 c haract e ri s e d by all internal functions in the first user function which is logically linked to the symptom being identified as recommended potential causes of the symptom, preferably through allocation of a higher fault probability, if these internal functions are common to internal functions from other checked user functions without full functionality

6 Method in accordance with claim 3 charact eri s e d b y the first user function which is logically linked to a symptom being checked against other user functions in an iterative process, whereby other user functions not previously checked are selected for checking, dependent on the most internal functions in common with the internal functions which have been identified as recommended potential causes of the symptom, preferably identified by means of higher fault probability

7 Method in accordance with claim 3 c hara ct eri s e d by the vehicle's functionalities being systematically and completely documented as a number of self- contained and mutually autonomous user functions, whereby each user function is documented in the form of a list of all internal functions and subfunctions arranged in sequential order in the list from at least one root to only one final user functionality perceivable by the vehicle user, whereby an activation flow or data flow for attaining the functionality perceivable by the vehicle user runs in the same sequential order between the internal functions

8 Method in accordance with claim 4 or 5 c haract eri s e d by the remaining internal functions situated furthest from the output function being identified from amongst the remaining internal functions or subfunctions which have not been eliminated following checking against functioning and symptom-free user functions, and these remaining internal functions situated furthest from the output function being allocated a higher probability as the cause of the symptom relative to internal functions situated nearer to the output function

9 Method in accordance with claim 5 or 8 ch ar act e ri s e d b y the remaining internal functions or subfunctions which have not been eliminated following checking against functioning and symptom-free user functions being allocated a statistically determined probability as the cause of the symptom dependent on susceptibility to breakdown determined by means of testing and/or fault mode analysis

10 Method in accordance with claim 5, 8 or 9 ch aract e ri se d by the internal functions which have been identified as defective by means of own diagnosis being prioritised as most likely to break down, these internal functions having been selected from the remaining internal functions or subfunctions which have not been eliminated following checking against functioning and symptom-free user functions, whereby this defectiveness in the system has been stored as a fault code belonging to the current internal information

11 System for diagnosis of faults in distributed systems, preferably but not exclusively for distributed electrical systems in vehicles, whereby different user functions in the system have at least one overlapping internal function or subfunction charact e ri s e d by

- the vehicle's functionalities being documented in a database (21) as a number of mutually autonomous user functions (70a-70d), whereby the user function is made up of a functionality perceivable by the vehicle user, and whereby each user function consists of a number of internal functions linked in a chain from at least one root function to a final perceivable functionality, which internal functions taken together provide the desired user function, - means (62b), in the event of a symptom noticed by the vehicle user, of identifying at least a first user function in the database which is logically linked to the symptom,

- means (62c) of identifying other user functions in the database which have at least one internal function in common with the user function which is logically linked to the symptom, and these other user functions being checked with regard to functionality, - and means (62e) of eliminating all internal functions as potential causes of the fault in the first user function which is logically linked to the symptom if these internal functions are common to internal functions from other checked user functions with full functionality

12. System in accordance with claim 11 c h aract eri s e d b y the system including means of summarising fault probabilities for respective internal functions, and these probabilities having been applied to internal functions, as well as means of presentation and an order of priority of internal functions as a descending order of and less probable causes of the symptom

13 System in accordance with claim 11 or 12 ch aract eri s e d by the database being global, and via means of selection (62) permitting access to the database via a troubleshooting terminal (60, 60a, 60b) or directly via the vehicle (67)