Data processing: vehicles – navigation – and relative location – Vehicle control – guidance – operation – or indication – With indicator or control of power plant
Reexamination Certificate
2001-02-20
2002-10-15
Wolfe, Willis R. (Department: 3747)
Data processing: vehicles, navigation, and relative location
Vehicle control, guidance, operation, or indication
With indicator or control of power plant
C701S029000, C701S115000, C702S085000
Reexamination Certificate
active
06466861
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention relates to electronic engine control systems, and more particularly to systems and methods for the calibration of such engine controlled systems.
Since the late 1980's, most internal combustion engines have included an electronic control module, or ECM. The ECM controls the electronic components of the engine, such as fuel injectors, egr valve, air intake, etc. In the early years of the ECM, the module utilized specific unchangeable programs for controlling the operation of the engine.
In recent years, the ECMs have become field-programmable. This feature enables product enhancements to be made in existing ECMs at a greatly reduced cost. In a typical application, one generic control module can be programmed for many different applications, e.g., different engine ratings or different engine applications. These changes can be made without any alterations to the physical configuration of the module.
The field-programmable ECM is the last element in a chain of calibration and application software development. This chain is depicted in FIG.
1
. At the beginning of the chain is a development tool
10
, which is typically a personal computer. A designer uses the development tool to create application software and application-specific calibration information for an ECM
20
. Each ECM includes a memory for storing a number of programs
20
a
-
20
z
for control of the ECM and control of the various electronic engine components. The applications and calibration information, or sub-files, are usually developed in conjunction with the creation of a new or modified engine or fuel system ratings. For example, in the case of new engine torque requirements, an engine developer creates new torque curve data and, through the development tool
10
, ultimately programs the ECM
20
with the new data. In the typical case, the development tool uses a configuration file to determine how to change data in the ECM
20
. The configuration file contains information about each item in the ECM that can be monitored or calibrated and provides information that defines the compatibility situation for these items in the calibration.
Once an engine developer or software engineer creates the sub-files, the data is uploaded to a main frame computer
12
in an engine manufacturing plant or design facility. At the main frame computer
12
, the sub-files generated from a number of development tools
10
are integrated and authorization levels are set for specific sub-files.
Ultimately, the sub-files initially generated at the development tool
10
are distributed via communication lines
13
to other various locations, such as engineering, service, manufacturing and end-customer sites. Each of these independent sites has a service computer
14
that receives the new downloaded information. Synthesis and calibration of similar software in the service computer
14
performs a number of data checks to verify the file information. The calibration assembler within the service computer then attaches calibration-loading instructions for an associated service/calibration tool
16
. Typically, this information is downloaded to the service tool
16
through an RS232 connection
15
with the service computer
14
.
The service tool
16
is the final link to updating the calibration information for the ECM
20
. In a typical circumstance, the service/calibration tool
16
communicates with the ECM
20
by way of a data link
17
. Typically, this data link uses an SAE J1708 interface standard and a unique handshake protocol.
The service/calibration tool
16
includes code or software programs
16
a
stored in memory. This software can be resident within the tool and activated/loaded when needed, or it can be dynamically loaded as required from a PC. This component of the service tool includes code for all of the update and calibration functions accomplished by the tool
16
. For instance, the code can include software for updating engine ignition data, cruise control attributes, etc. or for providing software control enhancements to the ECM. Since every ECM does not require every enhancement or calibratable function, the service tool
16
only dynamically loads calibration code from the module
16
a
that is necessary under the circumstances. This dynamic loading feature can be accomplished automatically when the service tool
16
is linked to the ECM, based upon the calibratable ECM data. Alternatively, the technician can selectively load the code, depending upon selected calibrations to be made.
As a further alternative, rather than dynamically loading the code, the subject code can be resident within the ECM, but inactive. In this case, the dynamic loading function performed by the service tool entails sending a signal to the ECM to “activate” the specific code or calibration information.
While the calibration chain shown in
FIG. 1
has significantly improved engine design and development, there is always room for improvement. One problem arises where new engine models or variations of engine models are developed and introduced to the marketplace. Typically each new engine requires a new engine calibration. In prior systems, the service tool
16
must have complete compatibility with the particular ECM
20
. In the case of a new engine, the new ECM is often unrecognizable to the existing service tool
16
, which ultimately prevents the technician from calibrating or upgrading the engine control.
With these prior systems, the first action taken by the service tool when it interfaces with an ECM is to read an application identifier stored within the ECM. This application ID carries information as to the calibration of the particular engine—e.g., engine type, etc. Next, the tool reads from the ECM information relating to the version level of the calibration. If the specific service tool supports the particular version level of the subject ECM, the calibration can be changed and updated. However, if the version level in the ECM is different than that supported by the tool, the tool is inhibited from accessing the calibration at all. Thus, with these prior systems, absolute compatibility is required between the service tool and the engine and ECM to be calibrated or updated.
This problem can arise where the new ECM incorporates a small change in an existing calibration feature. In addition, difficulties occur when the new ECM has a feature added to the standard calibration.
In either case, the existing service tool can be prevented from working with the calibration for the new ECM. What is needed is a service tool and ECM relationship that is more akin to physical maintenance of an engine. In other words, an engine mechanic can be faced with a brand new engine design and still be able to use standard tools to service virtually every feature of the engine. The only aspect of the new engine that may not be directly serviceable by the mechanic is a brand new, unfamiliar feature. Even in that instance, there may be certain aspects of the new physical engine feature that can be adjusted or maintained by the mechanic.
This same circumstance does not inhere in the software end of the engine. The limitations that presently exist between the service tool and the ECM do not allow the electronic calibration world to emulate the physical component world. There is therefor a need for a service tool and ECM interface protocol that overcomes the compatibility barriers present with systems of the prior art.
SUMMARY OF THE INVENTION
These problems with the engine evaluation, upgrade or calibration chain are addressed by aspects of the present invention that emulate the physical world. More particularly, the invention resides in a recognition that features of an engine control module can be divided into specific features and general features. These features may be manipulated, upgraded, read/written or calibrated by the service tool. For example, a general feature may be the engine cruise control, while the specific feature corresponds to a particular type of cruise control system.
In accorda
Barnes & Thornburg
Cummins Inc.
Wolfe Willis R.
LandOfFree
Dynamic service tool for an engine control module does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Dynamic service tool for an engine control module, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Dynamic service tool for an engine control module will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2921308