Remote diagnosis of vehicles

Abstract

 A central processor resource (100) communicates wirelessly with at least one vehicle (180) via a communication means (182) adapted to receiving information about a functional status of the vehicle (180) from a data gathering means (184). The vehicle (180) sends to the processor resource (100) a diagnosis request (DR) which includes a fault report. On the basis of the fault report, the processor resource (100) determines a fault diagnosis by using a diagnosis engine (110). The processor resource (100) checks whether a current vehicle-specific configuration file (CF) of a prevailing configuration of the vehicle (180) is stored in a connected data storage space (120). If the stored configuration file (CF) is found to be current, it is read out from the data storage space (120) to serve as a basis for the diagnosis engine (110) to determine the fault diagnosis. Otherwise a request (CFR) for a vehicle-specific configuration file (CF) is sent to the vehicle (180). In response to receiving a vehicle-specific configuration file (CF), the file (CF) is read in as a basis for the diagnosis engine (110) to determine the fault diagnosis.

Description

BACKGROUND TO THE INVENTION AND PRIOR ART

[0001] The present invention relates generally to solutions for fault diagnosis of vehicles. In particular, the invention relates to a system according to the preamble of claim 1 and a method according to the preamble of claim 8. The invention relates also to a computer programme according to claim 15 and a computer-readable medium according to claim 16.

[0002] It is generally preferred to minimise the time which a motor vehicle spends at workshops for servicing or repairs. This applies in particular to commercial vehicles, e.g. trucks and buses, for which a maximum degree of effective utilisation is desired. There are therefore various current solutions for remotely identifying and, wherever possible, remedying faults which occur on vehicles. Even if a fault cannot be remedied locally, it is most commonly advantageous if it can be identified before the vehicle reaches the workshop or before a repairer reaches the vehicle. This makes it possible to prepare for the repair, leading to minimisation of outage time.

[0003] GB 2 366 407 describes a system for remote diagnosis of faults in a vehicle, whereby a two-way connection is set up between the vehicle and a central server. The vehicle uses said connection to convey details of its type and its current fault state, whereupon the server returns a description of possible causes and/or guidance information relating to continued fault identification. The server has access to a database of historical fault data for the specific vehicle, enabling it to "learn" to diagnose the vehicle increasingly effectively.

PROBLEMS ASSOCIATED WITH PRIOR ART

[0004] Before a proper fault diagnosis can be established, however, significant amounts of data need to be transmitted from the vehicle to the central server. Inter alia the server needs to be provided with full details of the vehicle's current configuration, i.e. what components are incorporated in the vehicle and what functions they are programmed to be able to perform. What is also normally necessary is a relatively comprehensive step-by-step exchange of questions and answers between server and vehicle until all the particulars relevant for the diagnosis have been conveyed to the server.

SUMMARY OF THE INVENTION

[0005] The object of the present invention is to propose a solution which alleviates the above problem and thereby makes more effective remote diagnosis of a motor vehicle possible.

[0006] According to an aspect of the invention, the object is achieved by the system described in the introduction whereby the central processor resource is connected to a data storage space which contains for example a database. The central processor resource is also configured to check whether a current configuration file specific to the vehicle, or corresponding data describing a prevailing configuration of the vehicle, is stored in the data storage space. If the data storage space is found to contain a current configuration file, the central processor resource is configured to read it out from the data storage space to serve as a basis for the diagnosis engine to determine the fault diagnosis. If on the contrary the data storage space is found not to contain a current vehicle-specific configuration file, the central processor resource is configured to send to the vehicle a request for a configuration file specific to it. In response to receiving from the vehicle a configuration file specific to it, the central processor resource is configured to read it in, to serve as a basis for the diagnosis engine to determine the fault diagnosis.

[0007] This system is advantageous in avoiding unnecessary provision of data describing the vehicle's configuration. As today's commercial vehicles are typically very complex as regards possible equipment alternatives and choice of software-implemented functions, a relatively large amount of data is needed to properly describe the configuration of a particular vehicle. Moreover, providing said data may involve a comprehensive dialogue procedure between a central processor resource and the respective vehicle. Minimising the provision of configuration data thus saves both data traffic costs and time.

[0008] According to an embodiment of this aspect of the invention, the vehicle-specific configuration file is regarded as describing a current configuration of the vehicle if it is associated with a timestamp indicating a file age which is less than a first predetermined value. By simple comparison between current time and the timestamp value it is thus possible to decide whether the configuration file may be deemed up to date or not.

[0009] According to another embodiment of this aspect of the invention, the vehicle-specific configuration file is regarded as describing a current configuration of the vehicle if a history stored for said file in conjunction with the central processor resource indicates that the vehicle's configuration has changed less frequently than a second predetermined value. If this condition is fulfilled, further investigation of the configuration file may be avoided, saving a considerable amount of time and resources. This investigation may of course be combined dynamically with the aforesaid age check so that the configuration file is regarded as current if the time since the latest recorded change to the configuration file is shorter than a historical average interval between two consecutive updates of the file.

[0010] According to a further embodiment of this aspect of the invention, the vehicle-specific configuration file is associated with a checksum. The diagnosis request transmitted from the vehicle to the central processor resource further includes the checksum associated with the vehicle-specific configuration file. To this end, the central processor resource comprises a comparator configured to compare the checksum received via diagnosis requests with a checksum calculated in the central processor resource for a configuration file for the vehicle stored in the data storage space. If the checksum received corresponds to the calculated checksum, the data storage space is regarded as containing a current configuration file for the vehicle, so no further provision of data is required. The checksum is based on the content of the configuration file in such a way that a match between two checksums very probably indicates that the respective configuration files are also identical. The conclusion from this comparison may therefore be drawn with a high degree of safety.

[0011] It is also preferred that the central processor resource be configured to calculate a checksum for a configuration file received for storage in the data storage space, and then to store the calculated checksum in the data storage space in association with the configuration file received. The stored checksum is subsequently read out from the data storage space for comparison with a checksum received via a diagnosis request. The amount of time spent receiving a diagnosis request from a vehicle is thus appreciably minimised.

[0012] According to yet another embodiment of this aspect of the invention, the vehicle-specific configuration file is associated with a checksum. The vehicle is here supposed to have a local processing unit configured to receive an order message from the central processor resource. The order message is in response to a diagnosis request from the vehicle and includes a checksum associated with a vehicle-specific configuration file which is stored in the data storage space connected to the central processor resource. The local processing unit is also supposed to be configured to compare the checksum received from the central processor resource with a checksum calculated locally in the vehicle for a current configuration file for the vehicle. The data storage space is found to contain a current configuration file if the checksum received by the vehicle corresponds to the checksum calculated locally in the vehicle. As above, unnecessary provision of configuration data can thus be avoided while at the same time it is possible to verify with a high degree of safety that a previously transmitted configuration file describes a current configuration of the vehicle.

[0013] According to a yet further embodiment of this aspect of the invention, the vehicle-specific configuration file is associated with a checksum. The vehicle is further supposed to have a local processing unit configured to calculate a new local checksum for said file. To this end, the vehicle is assumed to be adapted to transmitting said new local checksum and a diagnosis request to the central processor resource. The central processor resource comprises a comparator configured to compare said new locally calculated checksum with a stored previously received locally calculated checksum for a configuration file stored in the data storage space. The data storage space is here found to contain a current configuration file if said new locally calculated checksum corresponds to said previously received said locally calculated checksum.

[0014] Alternatively, the aforesaid comparator may be situated in the vehicle so that the comparison is instead done in the vehicle and the calculation of the checksums takes place in the central processor resource. This reduces the vehicle's computing burden.

[0015] According to another aspect of the invention, the object is achieved by the method described in the introduction which comprises checking whether a current vehicle-specific configuration file describing a prevailing configuration of the vehicle is stored in a data storage space connected to the central processor resource. If the data storage space is found to contain a current configuration file, the method comprises reading it out from the data storage space to serve as a basis for the diagnosis engine to determine the fault diagnosis. If on the contrary the data storage space is found not to contain a current vehicle-specific configuration file, the central processor resource sends to the vehicle a request for such a file. In response to receiving a vehicle-specific configuration file from the vehicle, the diagnosis engine reads it in, to serve as a basis for determining the fault diagnosis. The advantages of this method and of its preferred embodiments are indicated by the above discussion pertaining to the proposed system.

[0016] According to a further aspect of the invention, the object is achieved by a computer programme which can be directly downloaded to the internal memory of a computer and comprises software for controlling the steps according to the method proposed above when said programme is run on a computer.

[0017] According to a further aspect of the invention, the object is achieved by a computer-readable medium which has stored on it a programme adapted to enabling a computer to control the steps according to the method proposed above.

BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The present invention is explained below in more detail on the basis of embodiments described by way of examples with reference to the attached drawings.

Figure 1

is a schematic diagram of a preferred remote diagnosis system, and

Figure 2

is a flowchart illustrating the general method according to the invention.

DESCRIPTION OF EMBODIMENTS OF THE INVENTION

[0019] We refer initially to Figure 1 depicting an embodiment of a system according to the invention. The system comprises a central processor resource 100 and a data storage space 120 and is adapted to remote-diagnosing a vehicle 180.

[0020] The central processor resource 100 is configured to communicate wirelessly with at least one vehicle 180 via a communication means 182 located in the vehicle. The communication means 182 is itself adapted to receiving information about a functional status of the vehicle 180 from a data gathering means 184 located in the vehicle. Thus the communication means 182 handles inter alia fault signals and fault reports from ECUs (electronic control units) located in the vehicle. The vehicle 180 is configured to generate, and by means of the communication means 182 send to the central processor resource 100, a diagnosis request DR. The diagnosis request DR will include a fault report describing a functional status of the vehicle 180 and may for example be transmitted to the central processor resource 100 via a base station 160 and one or more communication networks 150, e.g. Internet.

[0021] On the basis of the fault report the central processor resource 100 is configured to use a diagnosis engine to determine a fault diagnosis for the vehicle 180. With the object of making the diagnosis process more effective, the central processor resource 100 is connected to a data storage space 120 which for example contains a database. The central processor resource 100 is further configured to check whether a current vehicle-specific configuration file CF describing a prevailing configuration of the vehicle 180 is stored in the data storage space 120.

[0022] If the data storage space 120 is found to contain a current configuration file CF, the central processor resource 100 is adapted to reading it out from the data storage space 120 to the diagnosis engine 110 to serve as a basis for determining the fault diagnosis for the vehicle 180. If the data storage space 120 is found not to contain a current vehicle-specific configuration file CF, the central processor resource 100 is adapted instead to sending to the vehicle 180 a request CFR for such a file. In response to receiving a vehicle-specific configuration file CF from the vehicle 180, the central processor resource 100 is further adapted to reading it into the diagnosis engine 110 to serve as a basis for determining the fault diagnosis.

[0023] According to an embodiment of the invention, the vehicle-specific configuration file CF is regarded as describing a current configuration of the vehicle 180 if it is associated with a timestamp which indicates its age at less than a first predetermined value, e.g. a week, a month, a half-year or a year, depending on vehicle type and/or model, equipment and, where applicable, a dynamic parameter such as a configuration history. According to another embodiment of the invention, the vehicle-specific configuration file CF is regarded as describing a current configuration of the vehicle 180 if a history H stored in conjunction with the central processor resource 100 for the file indicates that the configuration of the vehicle 180 has changed less frequently than a second predetermined value. The history H is stored with advantage in a database 130 which may either be accommodated in the same storage space as, or be stored separately from, the data storage space 120.

[0024] According to embodiments of the invention, with the object of achieving increased reliability in assessing whether a configuration file CF stored for a particular vehicle 180 in the data storage space 120 describes a current configuration (i.e. whether the file properly indicates the units with which the vehicle is equipped and which software and versions thereof have been loaded to control them), the file is associated with a checksum calculated, for example, by so-called hashing. The checksum may be calculated locally in the vehicle 180 and be designated #_v, or be calculated centrally in the central processor resource 100 and be designated #_c.

[0025] For example, diagnosis requests DR transmitted from the vehicle 180 to the central processor resource 100 may include the checksum #_v associated with the vehicle-specific configuration file CF. In this case the central processor resource 100 comprises a comparator 140 configured to compare the checksum #_v received via diagnosis requests DR with a checksum #_c calculated in the central processor resource for a configuration file CF for the vehicle 180 which is stored in the data storage space 120. The data storage space 120 is here found to contain a current configuration file CF if the checksum #_v received corresponds to the centrally calculated checksum #_c.

[0026] For reasons of effectiveness it may be advantageous to arrive at the centrally calculated checksum #_c beforehand, i.e. for the central processor resource 100 to be configured to calculate for a configuration file CF received a checksum #_c with a view to the file being stored in the data storage space 120. The central processor resource 100 stores the calculated checksum #_c in the data storage space 120 in association with the configuration file CF received, either at a shared location or with suitable linking. The central processor resource 100 is further adapted to reading the checksum #_c out from the data storage space 120 for comparison with a checksum #_v received via a diagnosis request DR. Valuable computing time is thus saved at the time of the comparison.

[0027] As an alternative to the above, the comparison between the checksums may instead be performed in the vehicle 180. In this case the vehicle 180 is supposed to have a local processing unit 186 configured to receive an order message OM from the central processor resource 100. The order message OM is sent to the vehicle 180 in response to a diagnosis request DR from it. The order message OM includes a checksum #_c associated with a vehicle-specific configuration file CF for the vehicle 180 which is stored in the data storage space 120. The local processing unit 186 is adapted to comparing the checksum #_c received from the central processor resource 100 with a checksum #_v calculated locally in the vehicle 180 for a current configuration file CF for the vehicle.

[0028] As above, the data storage space 120 is found to contain a current configuration file CF if the checksum #_c received in the vehicle 180 corresponds to the checksum #_v calculated locally in the vehicle.

[0029] According to the invention there is of course no need for the comparison of the checksums to be performed at the same location as that where the respective checksums #_c and #_v are calculated.

[0030] Thus the local processing unit 186 of the vehicle 180 may for example be configured to calculate a new local checksum #_v for a current configuration file CF for the vehicle 180. In this case the vehicle 180 is further configured to be able to transmit the new local checksum #_v to the central processor resource 100, e.g. via the communication means 182, advantageously at the same time as transmitting a diagnosis request DR. The new locally calculated checksum #_v is compared with a stored previously received locally calculated checksum #_v for a configuration file CF stored in the data storage space 120. The data storage space 120 is found to contain a current configuration file CF if the new locally calculated checksum #_v corresponds to the previously received said locally calculated checksum #_v.

[0031] As a further alternative, the allocation of work between the vehicle 180 and the central processor resource 100 may be reversed so that a similar comparator is located in the vehicle 180 and the calculation of checksums #_c is performed in the central processor resource 100.

[0032] It is preferable that the central processor resource 100 be configured to function in accordance with the instructions contained in software which is executed in the processor resource 100. It is therefore advantageous if the central processor resource 100 includes, or is in some other way linked to, a memory module M containing software which, when executed in the central processor resource 100, causes the procedure described above to be performed.

[0033] To summarise, the general method according to the invention will now be described with reference to the flowchart in Figure 2.

[0034] A first step 210 checks whether a diagnosis request DR from a vehicle has been received. The diagnosis request DR will include a fault report describing a functional status of the vehicle concerned. If such a diagnosis request DR has been received, a step 220 follows, otherwise the procedure loops back and comes to a halt at step 210. Step 220 checks whether a current vehicle-specific configuration file describing a prevailing configuration of the vehicle is stored in an accessible data storage space. If such is the case, a step 230 reads said configuration file CF out from the data storage space to serve as a basis for a diagnosis engine. A subsequent step 240 determines a fault diagnosis for the vehicle on the basis of the configuration file CF and the fault report received.

[0035] If at step 220 it turns out that the data storage space does not contain a current vehicle-specific configuration file for the vehicle, a step 250 follows whereby the vehicle is sent a request for a vehicle-specific configuration file CF. A step 260 then checks whether such a file has been received. The procedure loops to step 250 until such a configuration file CF is received. Receipt of the configuration file CF is followed by a step 270 which reads the configuration file CF received into the diagnosis engine to serve in conjunction with the fault report as a basis for determining the fault diagnosis, which takes place at step 240.

[0036] When the fault diagnosis has been established at step 240, the procedure loops back to step 210.

[0037] The method steps described with reference to Figure 2 may be controlled by means of programmed computer apparatus. In addition, although the embodiments of the invention described above with reference to the diagrams comprise a computer and processes conducted in a computer, the invention extends to computer programmes, especially computer programmes on or in a carrier suited to practically implementing the invention. The programme may be in the form of source code, object code, a code intermediate between source and object code, e.g. in partly compiled form, or in any other form suitable for use in implementing the process according to the invention. The carrier may be any entity or device capable of carrying a programme. For example, the carrier may comprise a storage medium such as a flash memory, an ROM (read only memory), e.g. a CD (compact disc) or semiconductor ROM, EPROM (electrically programmable ROM), EEPROM (erasable EPROM) or a magnetic recording medium, e.g. a floppy disc or a hard disc. The carrier may also be a transmitting carrier such as an electrical or optical signal which can be conveyed by an electrical or optical cable or via radio or in some other way. Where the programme is in the form of a signal which can be conveyed directly by cable or some other device or means, the carrier may take the form of such a cable, device or means. Alternatively the carrier may be an integrated circuit in which the programme is embedded and which is adapted to conducting, or to being used in conducting, the relevant processes.

[0038] The invention is not restricted to the embodiments described with reference to the diagrams but may be varied freely within the scope of the claims set out below.

Claims

1. A system for diagnosis of vehicles (180), comprising
a central processor resource (100) configured to communicate wirelessly with at least one vehicle (180) via a communication means (182) located in the vehicle and adapted to receiving information about a functional status of the vehicle (180) from a data gathering means (184) located in the vehicle (180),
said at least one vehicle (180) being configured to generate and send to the central processor resource (100) by means of said communication means (182) a diagnosis request (DR) which includes a fault report describing a functional status of the vehicle (180), and
the central processor resource (100) being configured to determining on the basis of the fault report a fault diagnosis for the vehicle (180) by using a diagnosis engine (110), characterised in that the central processor resource (100) is connected to a data storage space (120) and is further configured
to check whether a current vehicle-specific configuration file (CF) describing a prevailing configuration of the vehicle (180) is stored in the data storage space (120),
if the data storage space (120) is found to contain a current configuration file (CF), to read it out from the data storage space (120) to serve as a basis for the diagnosis engine (110) to determine the fault diagnosis,
if the data storage space (120) is found not to contain a current vehicle-specific configuration file (CF),
to send to the vehicle (180) a request (CFR) for a vehicle-specific configuration file (CF), and
to respond to receiving a vehicle-specific configuration file (CF) from the vehicle (180) by reading it in, to serve as a basis for the diagnosis engine (110) to determine the fault diagnosis.

2. The system according to claim 1, whereby the vehicle-specific configuration file (CF) is regarded as describing a current configuration of the vehicle (180) if it is associated with a timestamp which indicates its age as less than a first predetermined value.

3. The system according to claim 2, whereby the vehicle-specific configuration file (CF) is regarded as describing a current configuration of the vehicle (180) if a history (H) stored for said file in conjunction with the central processor resource (100) indicates that the configuration file of the vehicle (180) has changed less frequently than a second predetermined value.

4. The system according to any one of the foregoing claims, whereby the vehicle-specific configuration file (CF) is associated with a checksum (#_v #_c), said diagnosis request (DR) transmitted from the vehicle (180) to the central processor resource (100) includes the checksum (#_v) associated with the vehicle-specific configuration file (CF), and the central processor resource (100) comprises
a comparator (140) configured to compare the checksum (#_v) received via diagnosis requests (DR) with a checksum (#_c) calculated in the central processor resource (100) for a configuration file (CF) for the vehicle (180) which is stored in the data storage space (120), and
whereby the data storage space (120) is found to contain a current configuration file (CF) if the checksum (#_v) received corresponds to the calculated checksum (#_c).

5. The system according to claim 4, whereby the central processor resource (100) is configured
to calculate a checksum (#_c) for a configuration file (CF) received with a view to storing it in the data storage space (120),
to store the calculated checksum (#_c) in the data storage space (120) in association with the configuration file (CF) received, and
to read the stored checksum (#_c) out from the data storage space (120) for comparison with a checksum (#_v) received via a diagnosis request (DR).

6. The system according to any one of claims 1 to 3, whereby the vehicle-specific configuration file (CF) is associated with a checksum (#_v #_c) and the vehicle (180) is supposed to have a local processing unit (186) configured
to receive from the central processor resource (100) an order message (OM) which is sent in response to a diagnosis request (DR) from the vehicle (180) and includes a checksum (#_c) associated with a vehicle-specific configuration file (CF) for the vehicle (180) which is stored in the data storage space (120) connected to the central processor resource (100), and
to compare the checksum (#_c) received from the central processor resource (100) with a checksum (#_v) calculated locally in the vehicle (180) for a current configuration file (CF) for the vehicle (180), and
the data storage space (120) is found to contain a current configuration file (CF) if said checksum (#_c) received in the vehicle (180) corresponds to said locally calculated checksum (#_v).

7. The system according to any one of claims 1 to 3, whereby the vehicle-specific configuration file (CF) is associated with a checksum (#_v #_c),
the vehicle (180) being supposed to have a local processing unit (186) configured to calculate a new local checksum (#_v) for said file (CF), and being adapted to transmitting to the central processor resource (100) said new local checksum (#_v) and a diagnosis request (DR),
the central processor resource (100) comprising a comparator (140) configured to compare said new locally calculated checksum (#_v) with a stored locally calculated checksum (#_v) received previously for a configuration file (CF) stored in the data storage space (120), and
whereby the data storage space (120) is found to contain a current configuration file (CF) if said new locally calculated checksum (#_v) corresponds to said previously received said locally calculated checksum (#_v).

8. A method for diagnosis of vehicles (180), comprising
conveying to a central processor resource (100) from a vehicle (180) a diagnosis request (DR) which includes a fault report describing a functional status of the vehicle (180),
on the basis of the fault report, determining a fault diagnosis for the vehicle (180) by means of a diagnosis engine (110) in the central processor resource (100),
characterised in that the method comprises
checking whether a current vehicle-specific configuration file (CF) describing a prevailing configuration of the vehicle (180) is stored in a data storage space (120) connected to the central processor resource (100),
if the data storage space (120) is found to contain a current configuration file (CF), reading it out from the data storage space (120) to serve as a basis for the diagnosis engine (110) to determine the fault diagnosis,
if the data storage space (120) is found not to contain a current vehicle-specific configuration file (CF),
sending from the central processor resource (100) to the vehicle (180) a request (CFR) for a vehicle-specific configuration file (CF), and
responding to receiving a vehicle-specific configuration file (CF) from the vehicle (180) by reading it in, to serve as a basis for the diagnosis engine (110) to determine the fault diagnosis.

9. The method according to claim 8, whereby the vehicle-specific configuration file (CF) is regarded as describing a current configuration of the vehicle (180) if it is associated with a timestamp indicating its age as less than a first predetermined value.

10. The method according to claim 9, whereby the vehicle-specific configuration file (CF) is regarded as describing a current configuration of the vehicle (180) if a history (H) stored for said file in conjunction with the central processor resource (100) indicates that the configuration of the vehicle (180) has changed less frequently than a second predetermined value.

11. The method according to any one of the claims 8 to 10, whereby the vehicle-specific configuration file (CF) is associated with a checksum (#_v #_c), said diagnosis request (DR) transmitted from the vehicle (180) to the central processor resource (100) includes the checksum (#_v) associated with the vehicle-specific configuration file (CF), and the method comprises
comparing the checksum (#_v) received via diagnosis requests (DR) with a checksum (#_c) calculated in the central processor resource (100) for a configuration file (CF) for the vehicle (180) which is stored in the data storage space (120), and
whereby the data storage space (120) is found to contain a current configuration file (CF) if the checksum (#_v) received from the vehicle (180) corresponds to the calculated checksum (#_c).

12. The method according to claim 11, comprising
calculating in the central processor resource (100) a checksum (#_c) for a configuration file (CF) received, with a view to storing it in the data storage space (120),
storing the calculated checksum (#_c) in the data storage space (120) in association with the configuration file (CF) received, and
reading the stored checksum (#_c) out from the data storage space (120) for comparison with a checksum (#_v) received via a diagnosis request (DR).

13. The method according to any one of claims 8 to 10, whereby the vehicle-specific configuration file (CF) is associated with a checksum (#_v #_c) and the method comprises
in response to a diagnosis request (DR) received, transmitting from the central processor resource (100) to the vehicle (180) a checksum (#_c) associated with a vehicle-specific configuration file (CF) for the vehicle (180) which is stored in the data storage space (120),
comparing in the vehicle (180) the checksum (#_c) received from the central processor resource (100) with a checksum (#_v) calculated locally for a current configuration file (CF) for the vehicle (180), and
whereby the data storage space (120) is found to contain a current configuration file (CF) if the checksum (#_c) received in the vehicle (180) corresponds to the locally calculated checksum (#_v).

14. The method according to any one of claims 8 to 10, whereby the vehicle-specific configuration file (CF) is associated with a checksum (#_v #_c) and the method comprises
transmitting a diagnosis request (DR) from the vehicle (180) to the central processor resource (100),
calculating in the vehicle (180) a new local checksum (#_v) for said file (CF), and
transmitting said new locally calculated checksum (#_v) from the vehicle (180) to the central processor resource (100), and
comparing in the central processor resource (100) said new locally calculated checksum (#_v) with a stored previously received locally calculated checksum (#_v) for a configuration file (CF) stored in the data storage space (120), and
whereby the data storage space (120) is found to contain a current configuration file (CF) if said new locally calculated checksum (#_v) corresponds to said previously received said locally calculated checksum (#_v).

15. A computer programme which can be directly downloaded to the internal memory (M) of a computer, comprising software for controlling the steps according to any one of claims 8 to 14 when said programme is run on the computer.

16. A computer-readable medium (M) which has stored on it a programme adapted to enabling a computer to control the steps according to any one of claims 8 to 14.

Drawing