The invention relates generally to vehicle diagnostics and more particularly to a method of synchronizing diagnostic information among powertrain control modules.
Increasing awareness of the effects of vehicle exhaust emissions and the like has resulted in regulations to control these emissions. In particular, various federal and state on-board diagnostic regulations (e.g., OBDII) require that certain emission related systems on the vehicle be monitored, and that a vehicle operator be notified if the system is not functioning in a predetermined manner. Automotive vehicle electronics therefore include a programmed diagnostic data manager or similar service configured to receive reports from diagnostic algorithms/circuits concerning the operational status of various components or systems and to set/reset various standardized diagnostic trouble codes (DTC) and/or otherwise generate an alert (e.g., Malfunction Indicator Lamp—MIL). The intent of such diagnostics is to inform the operator when performance of a component and/or system has degraded to a level where emissions performance may be affected and to provide information (e.g., via the DTC) to facilitate remediation.
In one configuration, a typical automotive system may include an engine control module (ECM) provided to control the engine and a transmission control module (TCM) configured to control an automatic transmission. However, only one control module, typically the engine control module, is configured to illuminate or extinguish the MIL. Accordingly, when a control module other than the ECM wishes to illuminate (or extinguish) the MIL, one approach allows for the other control module(s) to directly request the ECM to illuminate the MIL. This request is typically made through the use of a single signal, commonly referred to as an MIL control signal (i.e., a flag where TRUE means illuminate and FALSE means extinguish). However, such an approach for controlling the MIL is inadequate in light of certain new diagnostic regulations that require maintaining the status of both so-called pending and confirmed faults. A confirmed fault will typically involve illumination of the MIL, while a pending fault is typically a fault that has not yet matured into a confirmed fault. Since the conventional MIL control approach only deals with confirmed faults, it is inadequate to communicate the status of pending faults between control modules, as would be required to meet the new, more precise diagnostic reporting requirements (i.e., in accordance with California Air Resources Board—CARB requirements).
There is therefore a need for a system and method for synchronizing diagnostic information among powertrain control modules that minimizes or eliminates one or more of the problems described above.
One advantage of the present invention is that it allow separate control modules to more comprehensively synchronize diagnostic data between and among them. In an automotive context, the present invention allows synchronizing of diagnostic data pertaining to CARB promulgated pending and confirmed fault status.
In a system having a primary control module, such as an engine control module (ECM) configured for connection to a malfunction indicator lamp (MIL) and a secondary control module, such as a transmission control module (TCM), both in communication with each other by virtue of a communications bus, a method is provided for synchronizing diagnostic data between the primary and secondary control modules. The method includes a number of steps. The first step involves providing a first diagnostic status record associated with the primary control module wherein the first status record contains first diagnostic data. The next step involves providing a second diagnostic status record associated with the secondary control module wherein the second status record contains second diagnostic data. The status records will each include a respective pending fault status field, a confirmed fault status field, and an MIL control status field. The next step of the method involves communicating an extended signal set from the secondary control module to the primary control module. The signal set includes a fault present signal, a diagnostic testing complete signal and an MIL request signal, which are generated in accordance with the second diagnostic status record. The next step involves synchronizing, at the primary control module, the first diagnostic status record with the second diagnostic status record based on the extended signal set. In aid of this synchronizing step, the primary control module includes logic configured to interpret the signal set so as to properly and reliably extract status information, and thus perform the synchronization. In a preferred embodiment, the method achieves synchronization of CARB promulgated pending and confirmed diagnostic fault status.
A corresponding systems is also presented.
Other features, aspects and advantages of the invention will become apparent from the detailed description along with the accompanying drawings
The present invention will now be described by way of example, with reference to the accompanying drawings.
Referring now to the drawings wherein like reference numerals are used to identify identical components in the various views,
Generally, the ECM 12 may include at least one microprocessor or other processing unit, associated memory devices such as read only memory (ROM) and random access memory (RAM), a timing clock, input devices for monitoring input from external analog and digital devices and controlling output devices. The ECM 12 is operable to monitor engine operating conditions and other inputs (e.g., operator inputs) using the plurality of sensors and input mechanisms, and control engine operations with the plurality of output systems and actuators, using pre-established algorithms and calibrations that integrate information from monitored conditions and inputs. The software algorithms and calibrations which are executed in the ECM 12 may generally comprise conventional strategies known to those of ordinary skill in the art. Overall, in response to the various inputs, the ECM 12 develops the necessary outputs to control the throttle valve position, fuel, spark, and other aspects, all as known in the art. The TCM 14 is also configured to include at least one microprocessor or other processing unit, associated memory devices such as read only memory (ROM) and random access memory (RAM), a timing clock, input devices for monitoring input from external analog and digital devices and controlling output devices, all in the furtherance of controlling the transmission.
In addition to the control of the engine, the ECM 12 is also configured to perform various diagnostics. As described in the Background, the ECM 12 may be configured to include a diagnostic data manager or the like, a higher level service arranged to manage the reports received from various lower level diagnostic routines/circuits and to set or reset diagnostic trouble code(s)/service codes, as well as illuminate or extinguish various alerts, all as known generally in the art. As shown in
Before proceeding, however, a general overview relating to on-board diagnostic conventions will be set forth to ensure consistency in understanding the detailed description that will follow. The California Air Resources Board (CARB) has promulgated various regulations concerning automotive diagnostics, as known to those of skill in the art. Consistent with these regulations, generally, a pending fault is a fault that has been logged during the latest driving cycle in which a diagnostic monitor/test has completed and recorded a test result. Likewise, a confirmed fault is generally taken to be a fault that has matured to a point where the Malfunction Indicator Lamp (MIL) is to be illuminated. A driving cycle is an interval that begins with the application of ignition to a subject control module, continues through normal operations, removal of ignition, and power-down of the control module and ends with a return to a reset state. There are two noteworthy types of faults. One type, a so-called Type A Fault, is a fault associated with a Type A diagnostic. Type A diagnostics are emissions-related diagnostics that will result in the MIL being illuminated immediately when a first failure of such diagnostic is reported (i.e., to a supervisory diagnostic data manager service or the like). Once the MIL is illuminated, the MIL will be extinguished only after three consecutive driving cycles reporting passing results. A so-called Type B fault is a fault associated with a Type B diagnostic. Type B diagnostics are emissions-related diagnostics that will result in the MIL being illuminated when such diagnostic reports (i.e., to a supervisory diagnostic data manager service or the like) the second one of two consecutive failures occurring on consecutive driving cycles (a first failure of the Type B diagnostic having already been reported during the first driving cycle but that did not result in the MIL being illuminated). Once the MIL is illuminated, the MIL will be extinguished only after three consecutive driving cycles reporting passing results. If a failure occurs on one driving cycle and the next driving cycle does not report any result for that diagnostic (i.e., does not report either a “pass” or a “fail”), then a third driving cycle will still count as being “consecutive” if the failure re-occurs. The only way to reset the two-driving-cycle count is to have a driving cycle in which the diagnostic reports a passing result.
With this background, a better understanding of the limitations of the conventional, single signal approach described in the Background may be had with reference to Table 1 below. Simply stated, a single control signal is not capable of synchronizing pending fault status between control modules. Table 1 shows the respective status of pending and confirmed faults as stored in a primary control module (CM1) and a secondary control module (CM2) using only the single MIL control signal. For frame of reference, the pending and confirmed fault status are shown in adjacent columns, as per CARB 1968.2/ISO 15031-5. In whole, Table 1 depicts the progression for a typical Type B fault as occurring on the secondary control module (CM2), and the inability of the conventional art to properly synchronize the status in the primary control module with the correct status in the secondary control module.
With continued reference to
With continued reference to
With continued reference to
In step 28, the method involves providing a first diagnostic status record in a primary control module and a second diagnostic status record in a secondary control module. In one embodiment, the primary control module may be the control module that is connected to or is otherwise capable of illuminating/extinguishing the MIL. The method proceeds to step 30.
In step 30, the method involves communicating a fault present signal, a diagnostic testing complete signal and an MIL requested signal (i.e., the set 26) from the secondary control module to the primary control module. The generation of these signals is in accordance with the definitions for each signal as described above. These signals carry the information that the logic in the primary control module needs to properly and reliably indicate the status of both pending and confirmed fault status. The method proceeds to step 32.
In step 32, the method involves synchronizing, at the primary control module, the diagnostic data stored in the first diagnostic status record with the data stored in the second diagnostic status record based on the communicated signal set 26. The manner in which these signals are interpreted will be described in greater detail in connection with the flowchart of
In step 34, the method involves reporting at least a portion of the diagnostic data stored in the first diagnostic status record, for example, to a higher-level supervisory diagnostic data manager service or the like. Such diagnostic data may also be made available for reporting to an external device (e.g., service tool).
In step 40, the primary control module that receives the signal set 26—the ECM 12 is the described embodiment—is configured to determine whether diagnostic testing in the secondary control module—the TCM—has been completed. The ECM 12 is configured to make this determination by examining the diagnostic testing complete signal 262, which if FALSE, causes the method to branch to step 42. In step 42, the method involves reporting (e.g., to the diagnostic data manager service) that diagnostic testing has not been completed. Then method then proceeds to step 60 (“END”). If, however, the diagnostic testing complete signal 262 is TRUE, then the method branches to step 44.
In step 44, the ECM 12 is configured to determine whether there is a fault present in the TCM. The ECM 12 is configured to make this determination by examining the fault present signal 261, which if FALSE causes the method to branch to step 46. In other words, a FALSE or NO in step 46 means that diagnostic testing has reported passing results. Accordingly, step 46 involves reporting (e.g., to a diagnostic data manager service or the like) passing results for the diagnostic testing in question. If, however, the fault present signal 261 is TRUE, this means that the diagnostic testing in the TCM 14 has produced a fault in some regard. The method then branches to step 48.
In step 48, the ECM 12 is configured to determine whether the MIL has been requested to be illuminated. The ECM 12 is configured to make this determination by examining the MIL request signal 263. If the MIL request signal 263 is TRUE (“YES”), then a confirmed fault can be presumed. The method branches to step 50. In step 50, the ECM 12 is configured to determine whether a Type B pending fault had been communicated to the ECM 12 from the TCM 14 in the previous driving cycle. It should be understood that if the MIL has been requested on the present driving cycle, then one of two situations must exist in the TCM 14: either (1) a first failure occurred for the present driving cycle for a Type A fault, which would result in the MIL request signal 263 being set (TRUE); or (2) a second consecutive failure occurred for the present driving cycle for a Type B fault, which would also result in the MIL request signal 263 being set (TRUE). To enable such logic to be performed, the ECM 12 is configured to keep track of whether a Type B pending fault was requested in the previous driving cycle. The ECM 12 may have a Type B fault counter or like facility to keep track of the needed history. If the ECM 12 determines that no Type B pending fault was requested by the TCM 14 in the previous driving cycle (“NO” branch in the flowchart), then the method branches to step 52. In step 52, the ECM 12 reports a Type A confirmed fault. However, if the ECM 12 determines that a Type B was in-fact requested in the previous driving cycle (“YES” branch in the flowchart), then the method branches to step 54. In step 54, the ECM 12 reports a Type B confirmed fault. In either case, the method proceeds to step 60 (“END”).
On the other hand, when the answer in step 48 is “NO”, the method branches to step 56. In step 56, the ECM 12 is configured to determine whether a Type B pending fault was requested in the previous driving cycle. As noted above, to enable performance of this step, the ECM 12 is configured to keep track of previously requested Type B pending fault requests from the TCM 14 using conventional approaches, such as described above. It should be appreciated that if a Type B pending fault request was made on the previous driving cycle, and the fault present signal 261 for current driving cycle indicates a fault present but yet no MIL request signal 263 has been asserted (i.e., TRUE), then the fault that is present must be for another, different Type B diagnostic, which would not accrue to the two-occurrence requirement needed to request MIL illumination. To circumvent continued reporting of a Type B pending fault (albeit originating with a different, failed Type B diagnostic), the method inhibits reporting of this for the present driving cycle. This is shown in the flowchart as a bypass. Thus, if the answer in step 56 is “YES”, then the method branches directly to step 60 (“END”). On the other hand, if the ECM 12 determines that no Type B pending fault was requested in the previous driving cycle (“NO” branch in the flowchart), then the method simply branches to step 58. In step 58, the method involves the ECM 12 reporting a Type B pending fault, which in this case is the first time for the Type B pending fault. This selective inhibiting of Type B pending fault reporting allows the diagnostic data manager service or like facility in the ECM 12, that is responsible for receiving and managing such reports, to continue executing its normal logic. In this embodiment, there is no need to modify the data manager to accommodate duplicative Type B pending fault reports. Finally, it should be understood that the diagnostic status record 22 is updated in accordance with the conclusions reached by the logic as described above for
Table 2 shows how the present invention provides for the accurate and reliable synchronization of diagnostic status information (i.e., pending, confirmed) between control modules for a Type B fault. Again, the primary control module CM1 corresponds to the ECM 12 in the described embodiment while the secondary control module CM2 corresponds to the TCM 14. The progression of events, on a per key-cycle basis, is the same as in Table 1. However, the pending and confirmed fault status in CM1 is perfectly synchronized with the pending and confirmed fault status in CM2.
Table 3 shows how the present invention provides for the accurate and reliable synchronization of diagnostic status information (i.e., pending, confirmed) between control modules for a Type A fault. Again, the primary control module CM1 corresponds to the ECM 12 in the described embodiment while the secondary control module CM2 corresponds to the TCM 14. The progression of events, on a per key-cycle basis, is the same as in Table 1, with the exception that only one failure of a Type A diagnostic is sufficient to illuminate the MIL. The pending and confirmed fault status in CM1 is perfectly synchronized with the pending and confirmed fault status in CM2.
The present invention provides an extended signal set 26 available for use between control modules that allows robust synchronization of diagnostic data, as described above.
It should be understood that the ECM 12 and the TCM 14 as described above include conventional processing apparatus known in the art, capable of executing pre-programmed instructions stored in an associated memory, all performing in accordance with the functionality described herein. That is, it is contemplated that the processes described herein will be programmed in a preferred embodiment, with the resulting software code being stored in the associated memory. Implementation of the invention, in software, in view of the foregoing enabling description, would require no more than routine application of programming skills by one of ordinary skill in the art. Such control modules may further be of the type having both ROM, RAM, a combination of non-volatile and volatile (modifiable) memory so that the software can be stored and yet allow storage and processing of dynamically produced data and/or signals.
While particular embodiments of the invention have been shown and described, numerous variations and alternate embodiments will occur to those skilled in the art. Accordingly, it is intended that the invention be limited only in terms of the appended claims.