EP1583039B1

EP1583039B1 - Vehicle and method for a vehicle

Info

Publication number: EP1583039B1
Application number: EP05101655.8A
Authority: EP
Inventors: Tomas Furendal; Johan LINDSTRÖM; Mikael Edstam
Original assignee: Scania CV AB
Current assignee: Scania CV AB
Priority date: 2004-03-30
Filing date: 2005-03-03
Publication date: 2018-07-04
Anticipated expiration: 2025-03-03
Also published as: KR20140044343A; SE0400828D0; KR101476806B1; BRPI0501073A; KR20120112299A; KR20060045045A; NO332046B1; BRPI0501073B1; NO20051499D0; KR101379942B1; EP1583039A1; NO20051499L; SE526826C2; SE0400828L; KR20130073921A

Description

Technical field

The present invention relates to an apparatus, a method and a computer program for maintenance of a motor vehicle comprising a communication bus.

Description of the prior art

In order to increase the efficiency and flexibility, the transportation technology has developed towards an increased use of network solutions for controlling various kinds of units and processes in the vehicles. For instance, the Controller Area Network (CAN) standard specifies a widely used means of accomplishing such a network in trucks, busses and other vehicles. Moreover, a bus tool called Keyword 2000 renders it possible to interconnect different CANs to form a joint network (a Keyword 2000 network). Thus, the joint network may include multiple CANs, which are operated and controlled simultaneously.
So-called on-board diagnostic (OBD) systems may be used to perform tests whether a specific control unit connected to a CAN is operating properly. An on-board diagnostic facility, such as a dashboard mounted video display, may provide access to information generated by the OBD system.
There might be a number of vehicle control units arranged on each CAN and being controlled by the network. It is well known to have vehicle component modules arranged to control various vehicle components such as lights, brakes and automatic transmission. Usually the vehicle component modules are programmable so that the functions of the vehicle may be slightly amended depending on the demands of the buyer. In the vehicle modules fault codes are usually stored, which fault codes indicate when any vehicle component has operated erroneously.
Due to the complexity of modern vehicles and the large number of functions available to the consumers the vehicle module codes become very extensive. When the vehicles are at service it may be possible to connect a computer to the vehicle and retrieve information from the vehicle modules. This information may include the earlier mentioned fault codes as well as the vehicle module codes. However, the extensive vehicle module codes make it cumbersome for service personnel to get an overview of how the vehicle is intended to function.
During the lifetime of a vehicle it is common that the owner modifies the vehicle in some way as well as repairs the vehicle. If the vehicle is modified or repaired in such a way that a control module is replaced with a non-standard control module it becomes difficult for service personnel to repair the vehicle in the future as the technical manual no longer is in accordance with the vehicle.
In the US patent 6,434,455 a logistic service system is described which incorporates a reprogrammable vehicle module. In the vehicle module fault codes are stored which indicate when the vehicle component has operated erroneously. According to the US patent 6,434,455 the vehicle may be connected to a service computer and in turn to a central server. The service computer may read information from the vehicle and send it to the central server. In the central server service information may also be saved. This service information may be retrieved next time the vehicle is at a workshop to be able to track the history of the vehicle. Said US patent is, however, silent on the problems with the difficulties for service personnel to read the vehicle module codes and also on the problems with tracking modifications made on the vehicle.
In "Exact configuration onboard", DaimlerChrysler AG. ERA conference 1999, Coventry, p. 5.2.1 ff, the problem with documentation of different models of a vehicle is described. According to the document this problem is solved by storing product documentation on the vehicle itself. The product documentation may include modifications made to the vehicle as well as information on service performed on the vehicle.
DE 197 28 083 A1 in turn describes a system for vehicle data communication comprising a vehicle data transmission bus to which electrical control devices of the vehicle are connected. A communication module is connected to the data bus and constitutes an autonomous interface for the transmission of data between an external communications post and one or more of the control devices. A transmission path that comprises the data bus and a wireless transmission section is thus formed for external access to read/download vehicle data from/to the vehicle control devices. The integrated communication module together with the data bus connection of the control devices aims at providing a communication system of high capacity and enabling that specific data need only be stored in one place (control device) to be accessible both internally by the other control devices as well as externally through the wirelessly connected communication stations for e.g. vehicle manufacturing and service purposes, road toll data collecting, vehicle pool related data collecting and for enabling remote vehicle control. One embodiment comprises that vehicle control data also can be inputted to the control devices through the communication system from the external stations e.g. for the purpose of setting vehicle speed reference values either for vehicle internal speed control or for remote controlled distance regulation to surrounding vehicles.
Furthermore, the prior art does not describe how the product documentation or technical information should be stored to facilitate any reprogramming of the vehicle in case any control unit is replaced with a non-standard control unit.
Thus, there is a need for a vehicle and a method for such a vehicle that solves at least one of the problems indicated above.

Summary of the invention

The present invention aims at providing an apparatus, a method and a computer program that solves at least one of the problems indicated above. This is achieved with an apparatus, a computer program or a method according to the appended independent claims.
Further objects and advantages are evident from the dependent claims.
An apparatus for maintenance of a motor vehicle, is provided, which motor vehicle comprises at least one controllable vehicle component, a data bus, a memory connected to the data bus for storing a vehicle specification file, and at least one programmable electronic control unit arranged to control at least one of the controllable vehicle components. Each electronic control unit is connected to the data bus and is programmed with a respective parameter set, the apparatus comprises an apparatus connector for connection of the apparatus to the data bus of the motor vehicle. The apparatus is characterised in that the apparatus comprises a parameter setting module for deriving the parameter set from the vehicle specification file. When the apparatus is connected to the data bus through the apparatus connector and on receipt of a programming command, it is arranged to read the vehicle specification file from the memory, to derive the parameter set from the vehicle specification file using the programming module and to program the electronic control unit with the derived parameter set through the data bus.
A vehicle to be serviced by an apparatus according to the present invention comprises a number of electronic control units which control different electrical functions in a vehicle. The vehicle specification file is stored in at least one electronic control unit but may also be stored in more than one place in the vehicle. The vehicle specification file comprises information about the electronic control units in the vehicle, technical information on the vehicle and product specifications for the functions of the vehicle.
An apparatus according to the present invention provides a robust solution for maintenance of the vehicle. By having a vehicle specification file from which it is possible to derive the parameter sets used to program the ECU:s it is easily overviewed by a service man who is going to work with the vehicle. Furthermore, by having a parameter setting module for deriving the parameters of the vehicle it is only a matter of updating the parameter setting module to be able to use new electronic control units that have hit the market after release of the vehicle. In summary, an apparatus according to the invention provides freedom for modifying the motor vehicle.
The apparatus may be arranged to read information from each one of the electronic control units connected to the data bus through the apparatus connector. This provides a possibility to recreate at least a part of the vehicle specification file in case the vehicle specification file should be corrupted.
The information from the electronic control units may comprise an identification number from each electronic control unit. This information may be used to electronically control that the electronic control units are the same as are specified by the vehicle specification file.
The apparatus may also comprise a communication connector for connection of the apparatus to a central server. This may be used to provide updates of the parameter setting module to the apparatus.
The apparatus may be arranged to read the vehicle specification file from the memory through the apparatus connector and the data bus and to send the vehicle specification file as an e-mail through the communication connector to a central server, on a command from a user. The sending of the vehicle specification file as an e-mail is an effective, fast and reliable way to provide the vehicle specification file to a central server.
The parameter setting module may be implemented with a computer program within the apparatus, wherein the apparatus is arranged to receive an update to the parameter setting module through the communication connector and wherein the apparatus is arranged to implement the update to the parameter setting module. As an alternative to implement the parameter setting module as a computer program it is of course also possible to implement the parameter setting module as hard-wired electronics. The implementation in the form of a computer program provides, however, a much more flexible solution.
By arranging the apparatus to receive updates through the communication connector it is uncomplicated to update the parameter setting module.
The vehicle specification file may further comprise at least one of the types of information from the group comprising, information on the dimensions of the vehicle, information on the chassis of the vehicle, information on the engine of the vehicle, information on the length of cables in the vehicle, information on the arrangement of the cables in the vehicle, the arrangement of the cables, information on electrical components in the vehicle, and information on updates of the vehicle. The list above is not exhaustive but other types of information may be included in the vehicle specification file.
The apparatus may comprise a user input device for input of information from a user. The user input device may be an ordinary keyboard but the input device may also be any other form of input device as known to a man skilled in the art, e.g. a microphone, a digitiser board or a touch screen.
The apparatus comprises a graphical user interface which is arranged to control a display connected to the apparatus. The display may of course be any kind of display known to a man skilled in the art.
After having left the factory different construction errors may be found on vehicles of a certain series. Such construction errors are usually corrected by calling in the vehicles of the series with a so called campaign alert. It is however often the case that the owners of the vehicles take no notice of the campaign alert. Thus, many vehicles are not modified in the necessary way. Therefore, there is a need for an apparatus that takes care of this problem. To this end the apparatus may be arranged to receive through the communication connector, alert modifications to be made on a vehicle type and an alert identifier identifying such vehicles. When connected to a vehicle, the apparatus is arranged to read the vehicle specification file from the vehicle, to compare the alert identifier with the identifier in the vehicle specification file, to compare the alert modifications with the vehicle specification file if the identifiers correspond to each other for identifying modifications still remaining to be performed, and to output a notification to a user on such modifications to be performed. With such an apparatus the problem with uncorrected construction errors is diminished as most vehicles are serviced regularly and as the construction errors then may be corrected at those instances.
When the vehicle is at service at a workshop the staff at the workshop may get information on the vehicle from the vehicle specification file. This might be very valuable in order to be able to correct any problems with the vehicle as the information in the vehicle specification file may give guidance to whether there have been made any modifications to the vehicle. If modifications have been made at a non-licensed workshop it is probable that the vehicle specification file has not been updated. Thus, the modification may be detected through the discrepancy between the vehicle specification file and the status of the physical vehicle. If , for example, an electronic control unit (ECU) has been replaced with a non-standard ECU this may be detected by comparing the information in the vehicle specification file with the actual ECU arranged on the vehicle.
When any modifications are made to the vehicle at a licensed workshop the vehicle specification file is modified accordingly.
Even though only one version of the vehicle specification file is stored in the vehicle as described above it is possible to have two versions stored in the vehicle at two different places. This has the advantage that if the vehicle specification file is corrupted in any way, it is more likely that the correct information may be recreated. For such storage of the vehicle specification file the apparatus may be arranged in such a way that it, when connected to a vehicle, reads the vehicle specification file from two different memories connected to the data bus of the vehicle, and compares the vehicle specification files to determine whether any one of the vehicle specification files has been changed and outputs a signal indicating any discrepancy between the vehicle specification files on the display.
The apparatus may further be arranged to control at least one check sum of each one of the vehicle specification files in order to control which vehicle specification file is correct, in case there is a discrepancy between the vehicle specification files. This allows the apparatus to check which one of the vehicle specification files is correct. Each vehicle specification file may have more than one check sum. This makes it possible to control parts of the vehicle specification file and further makes it possible to combine a correct part of the first version of the vehicle specification file with a correct part of the second version of the vehicle specification file.
The apparatus may further be arranged to retrieve information on the mileage of the vehicle from the vehicle specification file, to use the mileage of the vehicle and the programming module to provide information on the service rules and to output the service rules on the display. An apparatus arranged in this way may automatically provide the service rules on the display and make it easy for a service man to get information on what has to be done on the vehicle. Alternatively the mileage may be provided to the apparatus as an input through the input device.
According to a second aspect of the present invention a computer-readable memory media on which a computer program for maintenance of a motor vehicle is stored, which motor vehicle comprises at least one controllable vehicle component, a data bus, a memory connected to the data bus for storing a vehicle specification file comprising information about electronic control units (3), and at least one programmable electronic control unit arranged to control at least one of the controllable vehicle components, wherein each electronic control unit is connected to the data bus and is programmed with a respective parameter set. The computer program comprises instructions which when run on a computer allows the computer to communicate with the data bus of the motor vehicle. The computer program is characterised in that the program also comprises a programming module for deriving the parameter set from the vehicle specification file, and that the program, on receipt of a programming command, makes the computer send signals, for reading the vehicle specification file from the memory, through the data bus, to derive the parameter set from the vehicle specification file using the programming module and to program the electronic control unit with the derived parameter set by sending them through the data bus. Such a computer program may be implemented on a standard computer to implement the apparatus according to the invention.
The features described above in relation to the apparatus according to the invention may, where applicable, also be implemented in a computer program according to the invention with the same advantages as described in relation to the apparatus.
According to a third aspect of the present invention a method is provided for maintenance of a motor vehicle comprising at least one controllable vehicle component, a data bus, a memory connected to the data bus for storing a vehicle specification file comprising information about electronic control units (3), and at least one programmable electronic control unit arranged to control at least one of the controllable vehicle components, wherein each electronic control unit is connected to the data bus and is programmed with a respective parameter set. The method is characterised in that it comprises the steps of providing a parameter setting module for deriving the parameter set from the vehicle specification file, reading the vehicle specification file from the memory through the data bus of the motor vehicle, deriving the parameter set from the vehicle specification file using the parameter setting module, and programming of the electronic control unit with the derived parameter set through the data bus. This method is preferably implemented using an apparatus as described above.
The features described above in relation to the apparatus according to the invention may, where applicable, also be implemented in a method according to the invention with the same advantages as described in relation to the apparatus.
In prior art vehicles the ECU:s are programmed with a large number of codes in order to achieve the desired functions. According to the present invention the vehicle specification file describes the vehicle in a high level language. The vehicle specification file is then transformed into codes for programming the ECU:s. By having the vehicle defined in a high level language in the vehicle specification file it is much easier for service personnel to read and modify the vehicle specification file.
It goes without saying that the above aspects of the invention may be combined in the same embodiment. In the following, preferred embodiments of the invention will be described with reference to the drawings.

Short description of the drawings

Fig 1 shows a motor vehicle according to an embodiment of the present invention.
Fig 2 shows a principal layout of the buses in the vehicle in fig 1.
Fig 3 shows schematically the vehicle specification file according to an embodiment of the present invention.
Fig 4 shows a flow diagram over a consistency check of the vehicle according to an embodiment of the present invention.
Fig 5 displays the function of the program modules when reading the vehicle specification file from the vehicle.
Fig 6 displays the function of the program modules when programming spare parts.
Fig 7 displays the function of the program modules for the display of information from the UFC-block.
Fig 8 displays the function of the program modules for displaying cablelists.
Fig 9 shows the process steps for investigating a need for a modification due to a campaign.
Fig 10 shows the process steps performed when servicing the vehicle.

Detailed description of the invention

In the following description of preferred embodiments of the present invention, reference will be made to the figures in which similar components have been designated with the same reference numerals.
In fig 1 a motor vehicle 1 according to an embodiment of the present invention is shown. In fig 1 the motor vehicle is shown as a truck but the motor vehicle may also be any other kind of motor vehicle. The motor vehicle comprises a number of controllable vehicle components 2, wherein each one of the vehicle components 2 is controlled by a programmable electronic control unit (ECU) 3. The electronic control units (ECU:s) are all connected to a data bus 4. In fig 1 all ECU:s are connected to a common data bus 4, but as will be described below it is possible to have the ECU:s grouped and each group of ECU:s connected to a respective data bus. The number of groups and data buses may be any number. The vehicle components 2 may for example be the tail lamp 13 or the head light 14 of the motor vehicle 1. Other possible components that may be controlled by an ECU are the gearbox, the climate control device, the power windows etc.. Also shown in fig 1 is a vehicle connector 5 which is connected to the data bus 4 and which is connectable to an apparatus 6 for maintenance of the motor vehicle 1. Connected to the data bus 4 is also a central electronic control unit (CECU) 7 which comprises a memory 8 for storing a vehicle specification file. Also shown in fig 1 is the apparatus 6 for maintenance of the motor vehicle 1 and a central server 21 to which the apparatus 6 for maintenance is connected through a communication connector 18. The connection to a central server 21 makes it possible to send data relating to the motor vehicle 1 to the central server 21 and to send data relating to the vehicle 1 from the central server 21 to the motor vehicle. The connection between the vehicle connector 5 and the apparatus 6 as well as the connection between the apparatus 6 and the central server 21 may be wireless. The wireless connections may be provided in any way known to a person skilled in the art.
In fig 2 a principal layout of a data network 12 in a motor vehicle 1 is shown. The data network comprises a first data bus 9, a second data bus 10, and a third data bus 11, wherein all three buses 9, 10, 11, are connected to a central electronic control unit (CECU) 7, which in turn is connected to a vehicle connector 5 arranged on the vehicle for connection of an apparatus 6 for maintenance to the data buses 9, 10, 11. A memory 8 is arranged within the CECU 7 in which various data may be saved. According to the invention a vehicle specification file is saved in the memory 8.

The apparatus for maintenance of the motor vehicle

The principal layout of the apparatus 6 for maintenance of the motor vehicle is shown in fig 1. The apparatus 6 comprises an apparatus connector 17 for connection of the apparatus 6 to the vehicle connector 5 on the vehicle. The apparatus 6 comprises a number of modules 23, 24 which are implemented by computer programs within the apparatus. A display 16 is connected to the apparatus for display of information to the service personnel using the apparatus 6. The apparatus 6 for maintenance further comprises a communication connector 18 for connection of the apparatus 6 to a network such as the internet or any other network. The apparatus 6 may communicate with a central server through the communication connector 18. The apparatus 6 also comprises an input device 19, such as a keyboard for input of information from the service person using the apparatus 6.
The apparatus 6 for maintenance is provided with an input 20 for a dongle 22 used to provide access to the modules of the apparatus, which modules may be implemented by computer programs. Access to the apparatus may be permitted at different authorisation levels, depending on the code comprised within the dongle 22. The coding system used in the dongle and the apparatus may be any of the coding systems known to a person skilled in the art. The coding of the dongle may be implemented in hardware or software.
When a service person inputs his personal dongle into the apparatus 6 the apparatus 6 reads the code of the dongle and permits access for the service person to an authorisation level corresponding to the code of the dongle. A first level of authorisation may for example authorise a service person only to read information from the motor vehicle, while a second level of authorisation may authorise a service person to change a limited amount of data in the motor vehicle. Finally, a third level of authorisation may authorise a service person to change all possible information in the motor vehicle.
Naturally, there may be any number of authorisation levels for access to the apparatus.

The vehicle specification file

The vehicle specification file 25 is shown schematically in fig 3 and is divided into a number of blocks for programming reasons. Each block in the vehicle specification file has its own checksum, its own identification and information on the version, so that each block may be handled separately.
Apart from the information common for all blocks as mentioned above, the head 26 of the vehicle specification file 25 also comprises pointers to the other blocks within the vehicle specification file 25 so that all blocks may be easily accessed. The head also comprises an identification name, that identifies the vehicle specification file 25, and a version number. If, in the future, further blocks are included into the vehicle specification file 25, the version number is updated. Furthermore, the head comprises a digital fingerprint that has information on who created the vehicle specification file 25 and when it was created by writing the date, identification on the application that created the vehicle specification file 25, the version of the application and the serial number of a USB-key that is used for authorisation purposes.
Also included in the vehicle specification file 25 is an ECU-block 27, an FPC-block 28, an XPC-block 29, UFC-block 30, a CABL-block 31 and a version-block 32, which will now be explained in more detail in turn.
The ECU-block 27 comprises a list over the ECU:s of the vehicle. This list includes the address of each ECU, an identification number for each ECU, function parameters describing possible functions for each ECU, the part number of each ECU, configuration checksum and adjustment values. In each ECU a vehicle identification number (VIN) is programmed. With the data in the ECU block and the VIN it is possible to see if the ECU:s are properly programmed. If an ECU is moved from one vehicle to another, this may be detected as the VIN in the ECU is incorrect. If an ECU is programmed with a non-compatible program this may also be detected as the checksum becomes incorrect. Furthermore, if an ECU has disappeared or is non-working relevant information on the ECU may be collected from the ECU-block. When an ECU is replaced with a new one it may easily be replaced and programmed using the information from the vehicle specification file 25.
The FPC-block 28 comprises a product specification of the vehicle. This product specification contains information on which type of vehicle it is and comprises the functional product characteristics of the vehicle. It is used during the production of the vehicle and is abstract in that it does not comprise article numbers on the parts but has information on the vehicle from a functional perspective. Examples of such functional product characteristics is the wheel base of the vehicle, the wheel configuration, i.e. the number of wheels on each axle and their size, the size of the fuel tank, the type of gear box and the colour of the vehicle. Due to the design of the FPC-block 28 the values of the different functional product characteristics cannot be saved in the FPC-block 28. In the FPC-block 28 only codes are saved which represents different values. The main task for the FPC-block 28 is to serve as in data when programming spare parts or when adjusting the ECU:s. Programming of a spare ECU means a full configuration of all configurable functions in an ECU. In a normal vehicle about 1000 parameters in ECU:s are configured from about 100 functional product characteristics. The conversion of the functional product characteristics to the programming parameters is made by the apparatus for programming the vehicle.
The XPC-block 29 comprises information relating to the vehicle, which information cannot be contained within the FPC-block 28, i.e. values for the different product characteristics. Thus, information on values corresponding to the different codes in the FPC-block 28 is stored in the XPC-block 29. The XPC-block 29 may be used to store different new information when demands for the storage of new information arises. The information in the XPC-block 29 may be used in programming of spare ECU:s. Examples on the information in the XPC-block 29 is information on the gear ratio of the final drive and the volumes of the left and right fuel tanks. Apart from information that may be used for programming a spare ECU the XPC-block 29 may also comprise information of administrative character.
The UFC-block 30 comprises information on the functions experienced by the user of the vehicle, such as the function of an automatic gearbox, the function of the ventilation system and the function of the cruise control. The UFC-block 30 also comprises the information on implementations of each one of the functions for the vehicle. By information on implementation is meant information on how ECU:s are programmed in order to provide the functions. When the vehicle is connected to the apparatus for maintenance the information in the UFC-block 30 is displayed to the service technician. Comprised within the UFC-block 30 is all electric system functions and information on their implementation in the vehicle. This individualised information makes fault-tracing easier. The information in the UFC-block 30 is only references to the information in the form of graphical pictures and describing text that is implemented in the apparatus for maintenance.
The CABL-block 31 comprises all the information on the cables of the vehicle. This information includes data on the lengths of the cables and how they are connected. As in the case with the UFC-block 30 this is an individualised amount of information in the form of a list over the cables that are incorporated in the vehicle. The information in the CABL-block 31 together with information in the apparatus for maintenance provides a maintenance technician with sufficient information for a fast and reliable fault-tracing.
The version-block 32 contains information on the modifications made on the vehicle. This information is valuable to have as this makes it possible to control the original specifications of the vehicle. When the vehicle is rebuilt at a licensed workshop a new version-block 32 is created which indicates what has been made on the vehicle together with a new fingerprint with information on which application that was used to update the version-block 32, information on the version of the application, the date of the update and the serial number of the USB-key.
Finally, the vehicle specification file 25 also comprises a campaign-block 33, which is similar to the version-block 32 but which comprises information over performed campaigns that are to be conducted instead of rebuilds. The information in the campaign-block 33 indicates which modifications that has been made on a vehicle.

Updating of the vehicle specification file

There are a number of reasons for updating the vehicle specification file 25. One such reason may be the failure of one of the ECU:s. In case the type of ECU that has failed is out of stock it has to be replaced by another one which is compatible with the old one. However, it is often the case that the parameter sets used to program the ECU differs between different ECU:s. Thus, when replacing the failed ECU with a new compatible ECU the parameter set has to be updated. However, in order to be able to replace the ECU with a new ECU, the new ECU has to be supported by the parameter setting module in the apparatus for maintenance. Such support is provided by the parameter setting module, which comprises information on a large number of different ECU:s and how their parameter sets should be arranged to provide different functions.
In some cases a new version of the ECU supports more functions than the original version of the ECU. In such a case the parameters are set so that the original functions are achieved. Alternatively, if the hardware permits new functions to be implemented this may also be done.
As a first example the replacement of a broken ECU 3 controlling an automatic gearbox will be described. When the motor vehicle is at the workshop it will be connected to the apparatus 6 for maintenance of the motor vehicle 1. The apparatus will read the vehicle specification file 25 from the motor vehicle and identify the identification numbers of all ECU:s 3 in the vehicle from the vehicle specification file 25. The identification numbers will be displayed on the display connected to the apparatus for maintenance.
It is possible to identify the broken ECU 3 in a number of different ways known to a person skilled in the art. This may for example be accomplished by comparing a fault description, provided by a user of the motor vehicle, with different fault scenarios. If the ECU 3 itself is not responding, this may also be an indication on that the ECU 3 is broken. Furthermore, a broken ECU 3 may be identified by fault codes that may be registered with a fault detection system separate from the network 12 of ECU:s 3 or integrated with that network 12.
When the ECU 3 that is to be replaced has been identified the service person using the apparatus 6 for maintenance may choose that ECU 3 in the apparatus 6 using the input device 19 and the display. After having chosen a specific ECU 3 the apparatus 6 may suggest a replacement ECU 3 that may be used in place of the broken ECU 3 and may also display information describing the functions of the ECU 3 on the display. After having replaced the ECU 3 the service person may input information, through the input device 19 to the apparatus 6, that the ECU 3 has been replaced. Then updating of the parameter set for the replaced ECU 3 may commence. Thus, the apparatus 6 for maintenance derives a new parameter set using the vehicle specification file 25 from the motor vehicle 1 together with information on the ECU 3. The derived parameter set is then transferred from the apparatus 6 for maintenance to the motor vehicle 1.
As a second example of when an updating of the vehicle specification file 25 is necessary, the modification of the motor vehicle will be described. Firstly the owner of the motor vehicle 1 modifies the motor vehicle 1 by adding a second rear axle. After modification of the motor vehicle 1 it may be connected to the apparatus 6 for maintenance, which reads the vehicle specification file 25 from the memory 8 of the central ECU 7. The apparatus for maintenance then updates the version block of the specification file. There are two alternatives for updating of the vehicle specification file 25. According to a first alternative for small and frequent rebuilds the vehicle specification file 25 is read from the vehicle and is sent to a reconfiguration data base. This results in a display of a list of possible rebuilds which are shown to the person who is going to rebuild the vehicle. After having rebuilt the vehicle and programmed the necessary ECU:s the updated vehicle specification file 25 is saved in the vehicle again. According to a second alternative the vehicle specification file 25 is sent to a service central with a request for a specific rebuild of a vehicle. At the service central a new vehicle specification file 25 is provided, which is sent back to the person modifying the vehicle in order to save it into the vehicle.

Service of the vehicle

The vehicle specification file 25 is also very valuable when servicing the motor vehicle 1. When the motor vehicle 1 is at service at a workshop the person responsible for the service connects the apparatus 6 for maintenance of the vehicle to the motor vehicle 1. The apparatus 1 reads the vehicle specification file 25 from the memory 8 of the central ECU 7 in step 1001 in fig 10. The mileage of the vehicle is either entered into the apparatus 6 by the service man with the input device or is automatically read from the motor vehicle 1 apparatus in step 1002. The mileage may be stored in the memory 8 of the central ECU 7. From the version block of the vehicle specification file 25 the apparatus 6 extracts in step 1003 information on service that has been performed on the motor vehicle 1 and an identification number identifying the person that has performed the service on the motor vehicle 1. The apparatus 6 determines in step 1004 the service that is to be performed on the motor vehicle 1 based on the identification number and the mileage of the motor vehicle 1. The apparatus 6 then compares the service that is to be done with the service that has already been performed on the motor vehicle 1 and display the discrepancy on the display 16 in step 1005. After the service has been performed the vehicle specification file 25 is updated and stored in the memory 8 in step 1006.

Campaign alert

After a motor vehicle 1 has been sold, different construction errors may be discovered on a series of motor vehicles 1. Such construction errors are often corrected during so called campaigns, when the owners of the vehicles in a specific series of motor vehicles are alerted about the necessity to correct construction errors. It is often the case that only a minority of the owners go to the workshops with their motor vehicles 1 after having got such a campaign alert. According to an embodiment of the present invention the execution of such campaigns are checked when the motor vehicle 1 is at a work shop for service or repair.
Accordingly, when the motor vehicle for some reason is connected to the apparatus 6 it is checked whether the operations defined in different campaigns have been executed. In more detail the vehicle specification file 25 is read from the memory 8 of the central ECU 7 and is compared with the information regarding the campaign related to the motor vehicle 1.
In fig 9 the process of investigating a need for a modification due to a campaign is shown. In a first step 901 the campaign block is read from the vehicle 1. In a second step 902 the campaign block is compared with information on all campaigns that have been issued in order to determine which campaigns that have not been executed for the vehicle. In a third step 903 it is displayed on the display 16 which campaigns are still to be executed on the vehicle. The information on campaigns is received by the apparatus 6 from the central server 21.

Consistency check

In order to check that the electrical system of the vehicle consists of properly programmed ECU:s a consistency check may be performed. The consistency check comprises a number of steps that will be explained below in connection with the flow diagram in fig 4.
Under some circumstances the motor vehicle 1 may be subject to different conditions, during which there is a risk that the vehicle specification file 25 is corrupted. This means that it is not possible to be certain about the contents of the vehicle specification file 25. According to an embodiment of the present invention this problem may be diminished by providing two copies of the vehicle specification file 25 within the vehicle, saved at different locations. The first version of the vehicle specification file 25 may be saved in the memory 8 of the central ECU 7. The second version of the vehicle specification file 25 may be saved in any one of the other ECU:s.
In a first step 401 the vehicle specification file 25 is retrieved from the central ECU 7 as well as the other ECU in which the vehicle specification file 25 is saved. The consistency of the two versions of the vehicle specification files may be checked by comparing them. Thus, if there is a discrepancy between the two different versions of the vehicle specification file 25 one may determine that at least one of them is incorrect. If this is the case the checksums of the vehicle specification file 25 are checked. As the vehicle specification file 25 has one checksum for each block it is possible to check each block separately.
It is of course possible to do the control of the checksums before the comparison of the vehicle specification files 25, but as the vehicle specification file 25 has no checksum for all blocks such an operation will take more time.
In case that both versions of the vehicle specification file 25 are corrupted the apparatus 6 may be arranged to retrieve some information from each one of the ECU:s in order to recreate at least some of the vehicle specification file 25. Thus, blocks having a correct checksum may be retrieved from one of the vehicle specification files 25 while the other blocks may be retrieved from the other vehicle specification file 25 under the provision that they have correct checksums. The information read from each one of the ECU:s may for example be an identification number of the ECU:s.
In a second step 402 it is controlled whether it is possible to connect to all ECU:s that are defined in the vehicle specification file 25. If an ECU is missing there are reasons to believe that it does not function in other ways either.
In a third step 403 it is checked whether all ECU:s have the same vehicle identification number as the vehicle specification file 25. In case any of the ECU:s has a different vehicle identification number it is probable that it origins from another vehicle. Thus it probably has to be reprogrammed in order to function properly. In case the vehicle identification number is missing it is probable that a spare ECU has been inserted without having been programmed. This fact is displayed to the person servicing the vehicle.
In a fourth step 404 it is checked whether the ECU:s have the article numbers that are defined in the vehicle specification file 25. There is only a small probability that the vehicle identification number is correct but that the article number is incorrect. However, the main reason for having the article numbers saved in the vehicle specification file 25 is to be able to easily order the correct components when they have to be replaced.
In a fifth step 405 a control of a checksum is performed. Based on the parameters of the ECU:s that are programmed, a checksum is created which is saved under the respective ECU:s. This checksum is correct only if the ECU:s have been programmed with an authorised apparatus for maintenance.
Even though the steps in the flow diagram have been described in a certain order it is obvious for a man skilled in the art that the steps may be performed in an arbitrary order.

Forwarding of the vehicle specification file

There are situations where a service man cannot repair the motor vehicle on his own. For such and other situations the apparatus 6 may comprise a communication connector 18 which is connected to the Internet. The apparatus may then be connected to a central server 21 through the communication connector 18.
Apart from sending information from the apparatus to the central server 21, information may also be sent in the opposite direction. An example of such transmission is when the computer program in the apparatus has to be updated. The reason for such an update may be that new versions of ECU:s 3 have been released or that new functions have been implemented into the motor vehicles 1. Updates to the program may be sent from the central server 21, via the Internet, through the communication connector 18 to the apparatus 6.
When there is a reason for the service man to forward some information to the central server 21 he may do it through the communication connector 18. As an example the vehicle specification file 25 may be forwarded in an e-mail to the central server 21.
As described above the vehicle specification file 25 is read from the vehicle with an apparatus . The apparatus is controlled by a number of program modules. The function of these different program modules will be described in the following.
In fig 5 the reading of the vehicle specification file is shown. A first program module 503 provides for the reading of the vehicle specification file 505 from the vehicle 501. In order to be able to read the vehicle specification file from the vehicle 501 the first program module 503 has to be provided with an electronic key 502. A second program module 504 has an electronic library which is used to interpret the vehicle specification file and to display a readable version to the operator of the computer,
In fig 6 programming of spare parts is displayed. A first program module 602 reads the vehicle specification file denoted 603 from the vehicle 601. A second program module denoted 604 converts the vehicle specification file 603 to a readable format. The first program module 602 also reads the identification for the new ECU from the vehicle 601 and sends it to a third program module denoted 605. The third program module 605 is in contact with a database denoted 606. With the information on the identity of the ECU, the vehicle specification file and the database 606 the third program module 605 derives program data to be used for programming the ECU.
In fig 7 the display of information from the UFC-block 30 is displayed. The UFC-block 30 of the vehicle specification file 704 is read by a first program module 701 and is sent to a second program module 702, which by using a database 703 provides text and graphics to the operator of the computer.
In fig 8 the process for displaying cable lists is shown. A first program module 801 is used to read the CABL-block 31 from the vehicle specification file 802. The CABL-block 31 is sent to a second program module 803 which uses a database 804 to collect text and graphics connected to the CABL-block 31. A graphical representation is then shown to the operator of the computer.
Even though the use of an electronic key is not described in connection with fig 6 to 8 it is obvious for a man skilled in the art that such an electronic key may be used also in those cases.
The present invention is not limited by the above described preferred embodiments. The present invention is limited only by the appended claims as defined below.
The motor vehicle 1 may for example have less than the six wheels shown on the motor vehicle 1 depicted in fig 1.
Even though the storage of two copies of the vehicle specification file 25 only was described in relation to the description of the consistency check, a man skilled in the art realises that this approach may be used also in the other examples described above.

Claims

Apparatus (6) for maintenance of a motor vehicle comprising at least one controllable vehicle component (2), a data bus (4), a memory (8) connected to the data bus (4) for storing a vehicle specification file (25) comprising information about electronic control units (3) of the motor vehicle, and at least one programmable electronic control unit (3) arranged to control at least one of the controllable vehicle components (2), wherein each electronic control unit (3) is connected to the data bus (4) and is programmed with a respective parameter set, which apparatus (6) comprises an apparatus connector (17) for connection of the apparatus (6) to the data bus (4) of the motor vehicle (1), characterized in that the apparatus (6) comprises a parameter setting module for deriving the parameter set from the vehicle specification file (25), and that the apparatus (6), when connected to the data bus through the apparatus connector and on receipt of a programming command, is arranged to read the vehicle specification file (25) from the memory (8), to derive the parameter set from the vehicle specification file (25) using the programming module and to program the electronic control unit with the derived parameter set through the data bus.
Apparatus according to claim 1, wherein the apparatus (6) is arranged to read information from each one of the electronic control units (3) connected to the data bus (4) through the apparatus connector (28).
Apparatus according to claim 2, wherein the information from the electronic control units (3) comprises an identification number from each electronic control unit (3).
Apparatus according to any one of claims 1 to 4, wherein the apparatus (6) comprises a communication connector (18) for connection of the apparatus to a central server (21).
Apparatus according to claim 4, wherein the apparatus, on a command from a user, is arranged to read the vehicle specification file (25) from the memory (8) through the apparatus connector (17) and the data bus (4) and to send the vehicle specification file (25) as an e-mail through the communication connector (18) to a central server (21).
Apparatus according to claim 4 or 5, wherein the parameter setting module is implemented with a computer program within the apparatus and wherein the apparatus is arranged to receive an update to the parameter setting module (23) through the communication connector (18) and wherein the apparatus (6) is arranged to implement the update to the parameter setting module (23).
Apparatus according to any one of the preceding claims, wherein the vehicle specification file (25) further comprises at least one of the types of information from the group comprising, information on the dimensions of the vehicle, information on the chassis of the vehicle, information on the engine of the vehicle, information on the length of cables in the vehicle, information on the arrangement of the cables in the vehicle, the arrangement of the cables, information on electrical components in the vehicle, and information on updates of the vehicle.
Apparatus according to any one of the preceding claims, wherein the apparatus (6) comprises a user input device (19) for input of information from a user.
Apparatus according to any one of the preceding claims, wherein the apparatus comprises a graphical user interface (24) which is arranged to control a display (16) connected to the apparatus (6).
Apparatus according to claim 9, wherein the apparatus (6) is arranged to receive through the communication connector (18), alert modifications to be made on a vehicle type and an alert identifier identifying such vehicles, on connection to a motor vehicle (1), to read the vehicle specification file (25) from the motor vehicle (1), to compare the alert identifier with the identifier in the vehicle specification file (25), to compare the alert modifications with the vehicle specification file (25) if the identifiers correspond to each other for identifying modifications still remaining to be performed, and to output a notification to a user on such modifications to be performed.
Apparatus according to claim 9 or 10, which when it is connected to a vehicle is arranged to read the vehicle specification file (25) from two different memories connected to the data bus of the vehicle, and which compares the vehicle specification files (25) to determine whether any one of the vehicle specification files (25) has been changed and outputs a signal indicating any discrepancy between the vehicle specification files (25) on the display (16).
Apparatus according to claim 11, wherein the apparatus, in case there is a discrepancy between the vehicle specification files (25), further is arranged to control a check sum of each one of the vehicle specification files (25) in order to control which vehicle specification file (25) is correct.
Apparatus according to any one of claim 9 to 12, which further is arranged to retrieve information on the mileage of the vehicle from the vehicle specification file (25), to use the mileage of the vehicle and the programming module to provide information on the service rules and to output the service rules on the display (16).
Computer-readable memory media on which a computer program for maintenance of a motor vehicle (1) is stored, which motor vehicle (1) comprises at least one controllable vehicle component (2), a data bus (4), a memory (8) connected to the data bus (4) for storing a vehicle specification file (25) comprising information about electronic control units (3) of the motor vehicle, and at least one programmable electronic control unit arranged to control at least one of the controllable vehicle components (2), wherein the at least one electronic control unit (3) is connected to the data bus (4) and is programmed with a respective parameter set, characterized in that the computer program comprises instructions which when run on a computer of an apparatus (6) allows the computer to communicate with the data bus (4) of the motor vehicle (1), the program also comprises a programming module for deriving the parameter set from the vehicle specification file (25), and that the computer program, on receipt of a programming command, makes the computer send signals, for reading the vehicle specification file (25) from the memory (8), through the data bus (4), to derive the parameter set from the vehicle specification file (25) using the parameter setting module (23) and to program the electronic control unit (3) with the derived parameter set by sending them through the data bus (4).
Computer-readable memory media according to claim 14, wherein the program, on a command from a user, makes the computer read the vehicle specification file (25) from the memory (8) through the data bus (4) and to send the vehicle specification file (25) as an e-mail to a central server (21).
Computer-readable memory media according to claim 14 or 15, wherein the computer is arranged by the program to receive an update to the parameter setting module (23) from a central server (21) and wherein the computer is arranged to implement the update to the parameter setting module (23).
Computer-readable memory media according to claim 14, 15 or 16, wherein the vehicle specification file (25) further comprises at least one of the types of information from the group comprising, information on the dimensions of the vehicle, information on the chassis of the vehicle, information on the engine of the vehicle, information on the length of cables in the vehicle, information on the arrangement of the cables in the vehicle, the arrangement of the cables, information on electrical components in the vehicle, and information on updates of the vehicle.
Computer-readable memory media according to claim 14, 15, 16 or 17, wherein the computer is arranged by the computer program to output signals to control a display (16) connected to the computer.
Computer-readable memory media according to claim 18, wherein the computer (6) is arranged by the program, to receive alert modifications to be made on a vehicle type and an alert identifier identifying such vehicles, on connection of the computer to a vehicle, to read the vehicle specification file (25) from the vehicle, to compare the alert identifier with the identifier in the vehicle specification file (25), to compare the alert modifications with the vehicle specification file (25) if the identifiers correspond to each other for identifying modifications still remaining to be performed, and to output a signal for notification of a user on such modifications to be performed.
Computer-readable memory media according to claim 18 or 19, which when it is connected to a motor vehicle (1) is arranged to read the vehicle specification file (25) from two different memories connected to the data bus (4) of the motor vehicle (4), and which compares the vehicle specification files (25) to determine whether any one of the vehicle specification files (25) has been changed and outputs a signal indicating any discrepancy between the vehicle specification files (25) on the display (16).
Computer-readable memory media according to claim 20, wherein the computer, in case there is a discrepancy between the vehicle specification files (25), further is arranged by the computer program, to control a check sum of each one of the vehicle specification files (25) in order to control which vehicle specification file (25) is correct.
Computer-readable memory media according to any one of claim 18 to 21, wherein the computer (6) is arranged, by the computer program, to retrieve information on the mileage of the motor vehicle (1) from the vehicle specification file (25), to use the mileage of the motor vehicle (1) and the programming module (23) to provide information on the service rules and to output the service rules as a signal to a display (16).
Method for maintenance of a motor vehicle comprising at least one controllable vehicle component (2), a data bus (4), a memory (8) connected to the data bus (4) for storing a vehicle specification file (25) comprising information about electronic control units (3) of the motor vehicle, and at least one programmable electronic control unit (3) arranged to control at least one of the controllable vehicle components (2), wherein the at least one electronic control unit (3) is connected to the data bus (4) and is programmed with a respective parameter set, characterized in that the method comprises the steps of providing a parameter setting module (23) for deriving the parameter set from the vehicle specification file (25), reading the vehicle specification file (25) from the memory through the data bus (4) of the motor vehicle (1), deriving the parameter set from the vehicle specification file (25) using the parameter setting module (23), and programming of the electronic control unit (3) with the derived parameter set through the data bus (4, which method comprises the step of connecting an apparatus (6) to the data bus of the motor vehicle (1), and wherein the deriving of the parameter set from the vehicle specification file (25) is performed in the apparatus (6).