Data processing: vehicles – navigation – and relative location – Vehicle control – guidance – operation – or indication – Vehicle diagnosis or maintenance indication
Reexamination Certificate
2003-12-05
2004-09-28
Camby, Richard M. (Department: 3661)
Data processing: vehicles, navigation, and relative location
Vehicle control, guidance, operation, or indication
Vehicle diagnosis or maintenance indication
C701S036000
Reexamination Certificate
active
06799101
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention is directed generally to a programming method for an electrically erasable and programmable memory employed in an electronic control unit (“ECU”), especially an ECU of the type used in road vehicles.
In road vehicles equipped with electronically controlled or regulated devices, such as electronic anti-lock brake control, it is common practice to design the microprocessors in the electronic control devices as mask-programmed microprocessors.
Since the advent of the 1-chip microprocessor, which contains an integrated flash electrically erasable and programmable read-only memory (“flash EEPROM”), it has also become possible to use the flash EEPROM area as a program memory for the microprocessor. At first, this capability was exploited mainly for prototype development. Besides prototypes, it has also become common practice in series production to use flash EEPROM memories as program and data memories for the microprocessor.
Currently, both mask-programmed and flash EEPROM-programmed microprocessors are being provided, each for a particular ECU type, the latest valid software version being used as a basis for such ECU type. However, because most software control programs are continuously being improved, the next-higher (later) software version developed is used in the next production series. In other words, the new software version is contained in the program memories of next-higher series-produced units.
As a result of this series-oriented approach, newly developed software versions are not loaded into ECUs of older series, whether they are mask-programmed or flash EEPROM-programmed.
In contrast, it has long been common practice in software engineering, especially for commercially available general data processing programs, to update existing programs, or in other words to overwrite them with a new updated program version, which can be run then. For safety reasons, however, this practice of simply overwriting an old memory state by a new, updated memory state is not recommended for use in control devices used in road vehicles without taking appropriate safety precautions.
Desirably, a given program is permitted to be loaded into only a fully specified ECU compatible with such program. With a newly updated memory state, however, the ECU might not be recognized as compatible. An anti-lock brake system (“ABS”) brake-control program is a good example for two reasons: first, by its nature it does not function in a gearbox control unit; second, it might trigger therein erroneous responses that under certain circumstances might negatively affect the vehicle.
Fundamental compatibility between ECU and control program is not the only consideration, however—vehicle type compatibility is also a consideration. For example, it is not recommended to simply overwrite an old ABS control program developed for a specific vehicle type with a newly developed, up-to-date ABS control program that has not been released for that vehicle type.
With newer generations of microprocessors, the use of the flash EEPROM as a program memory, in the case of 1-chip microprocessors, for example, has become steadily more cost-effective. Furthermore, larger flash EEPROM memories are now available.
Inspired by these developments, the vehicle manufacturers are becoming increasingly interested in the capability to update an equipment unit purchased from one controller manufacturer with a new program version.
EP 0 836 739 B1 describes a method for updating a flash EPROM memory (4) of an electronic apparatus (5) via a personal computer (1) connected to the electronic apparatus. Into the memory area (2) of the personal computer there is loaded, among other information, the reprogramming code (3) for the flash EPROM device (4). Furthermore, as part of memory area (2), a random access memory (RAM (6)) is provided in which an executable program code is stored. After communication is established between the personal computer and the electronic apparatus, the executable program is loaded into a random access memory (RAM (7)) provided in the electronic apparatus (5) and is activated after correct transfer has been verified. Using the activated executable program, the reprogramming code (3) is loaded into the flash EPROM (4) of the electronic apparatus, and the updating process is completed by RESET of the personal computer. No verification measures are provided for identification of the electronic apparatus.
A conventional diagnostic unit of the type used in motor vehicle shops for many types of electrical and electronic maintenance tasks can also be used for programming. For this purpose, the connecting cable of the diagnostic unit is connected to the vehicle via a diagnostic connector mounted thereon, after which the diagnostic unit can communicate through the client/server principle with an ECU installed in the vehicle, the diagnostic unit being the client and the ECU being the server, while communication between the two takes place according to a stipulated diagnostic protocol, such as, for example, the Keyword Protocol 2000 according to International Organization for Standardization (“ISO”) standard 14230 (“KWP2000 protocol”).
Conventional diagnostic units also offer the capability to transfer data or programs into the ECU by means of a download process. Accordingly, reprogramming of an ECU equipped with a flash EEPROM is possible in principle by using the diagnostic unit.
For this purpose, for example, there takes place between the diagnostic unit and the ECU a dialog, in which, for example, a key code based on a random number is generated by the diagnostic unit and then checked by both units for logical consistency. If logical consistency is found, the download process (corresponding to transfer into the ECU and programming of the flash EEPROM) is initiated by the diagnostic unit and handled in a further dialog with the ECU.
In this process, the access authorization for downloading takes place during the key code dialog. The dialog, however, provides merely for a check as to whether the diagnostic unit and the ECU fit together in terms of their logical structure in the manner provided by the vehicle manufacturer in the diagnostic unit for the ECUs used in the manufacturer's vehicles.
The ensuing download process takes place with, for example, “memorymap.hex” (
1
), which is discussed in greater detail hereinafter, but which does not contain any information about the ECU itself.
Downloading of a new program by the foregoing process in no way includes a check, derived from the content of the reprogramming code, of suitability of the ECU for the new program. Thus, in itself, it does not offer any kind of protection against misprogramming.
By introducing further steps into the download process, it will be possible to obtain further information, such as the ECU part number. This can be accomplished, for example, either by an operator on the basis of the rating plate of the ECU, or by the diagnostic unit through queries to the ECU. From this information, an operator or the diagnostic unit itself will be able to check whether the ECU is that scheduled for programming. Accordingly, a suitability check can in principle be performed by the operator or the diagnostic unit.
This method, however, has two disadvantages: first, the suitability check is not mandatory; second, the check, on the basis of the ECU part number, for example, can be accomplished only by a comparison with information that is not a direct part of the reprogramming code. Consequently, diverse error sources are created, such as operator error or incorrect instructions for the diagnostic unit. These disadvantages might impair the safety of the process with regard to misprogramming, especially in the case of widespread use in automobile shops.
Accordingly, it is desired to provide a safe method for reprogramming an electrically erasable and programmable memory provided in an ECU that avoids the disadvantages associated with prior art methods.
SUMMARY OF THE INVENTION
Generally speaking, in accordance with the pres
Hawig Heinrich
Ulken Ulfert
Camby Richard M.
Kramer Levin Naftalis & Frankel LLP
WABCO GmbH & Co. OHG
LandOfFree
Method for programming flash EEPROMS in... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method for programming flash EEPROMS in..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for programming flash EEPROMS in... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3248323