Module for monitoring vehicle operation through onboard diagnostic port

[0002] NOT APPLICABLE

[0003] NOT APPLICABLE

[0004] NOT APPLICABLE

[0005] This invention relates to be on board recordation of operating data from a motor vehicle into a dedicated onboard diagnostic port memory module. More specifically, a “trip oriented” data recordation protocol is actuated during vehicle operation when the dedicated onboard diagnostic port memory module is connected to the onboard diagnostic port of the vehicle. The dedicated onboard diagnostic port memory module can be preprogrammed before placement to the vehicle as to certain critical data parameters to be monitored, placed in vehicle for monitoring over an extended period of time, and finally intelligently interrogated to discharge the recorded data. A detailed record of vehicle and driver operation of a vehicle can be generated from the recorded data.

[0006] Davis Instruments of Hayward, Calif. has pioneered the onboard recordation of data through a module known as “Drive Right.” This device requires custom installation on a vehicle by a skilled mechanic, including a device for monitoring driveshaft rotation and the like. Recordation of data includes counters indicating vehicle operation within certain speed bands and acceleration and deceleration parameters. Purchase and operation of the device requires a motivated buyer willing to pay the cost of the unit as well as to accept the inconvenience and additional expense of vehicle installation. This device finds its highest applicability with owners of “fleets” of automobiles.

[0007] So-called Onboard Diagnostic Ports are known and indeed required by The Environmental Protection Agency (EPA). The current device is known as Onboard Diagnostic Port II (hereinafter OBD II). The device is required to enable certain data to be sensed when the OBD II is monitored, and that data is specified by The Society of Automotive Engineers Vehicle Electrical Engineering Systems Diagnostic Standards Committee. The physical configuration of the OBD II output plug is specified (SAE J1962), containing a pin array which is to be electronically monitored. What is not mandated is the language of data transmission, and which pins are to emit the data. The OBD II mandated data to be sensed is contained in a voluminous catalog.

[0008] Surprisingly, there are four discrete “languages” (and corresponding pin arrays) now extant in which these OBD II ports now emit data. Those languages are SAE J1850 (GM, Ford), ISO, ISO 9141 (Chrysler and most foreign cars) and KWP 2000 (many 2001 and later foreign cars). For each of the so-called languages, the standard OBD II port has different pins emitting different information in different formats.

[0009] The OBD II ports are designed to be connected with standard diagnostic equipment in modern automobile repair shops. It is known to have diagnostic equipment which upon being plugged into the OBD II port, determines the “language” of a particular port, properly addresses the pin array, and finally receives and interprets for the mechanic the specified data required of the OBD II port. It is known that manufacturers have proprietary codes for correspondingly proprietary operating parameters and parts of specific vehicles. Further, it is common to load into standard diagnostic equipment the labels specified by the Diagnostic Standards Committee. When the standard diagnostic equipment detects the data required of the OBD II port, the standard diagnostic equipment gives that particular data a display label which corresponds to the data mandated by the Diagnostic Standards Committee.

[0010] OBD II ports are, in some circumstances, monitored by having a computer (for example a laptop or notebook computer) attached to the ports while the vehicle is operating. Typically, a mechanic makes the computer connection, and thereafter drives or runs the vehicle to collect the desired data. Either during operation or once the data is collected, the computer displays the collected data in a programmed format.

[0011] As any driver of a modern vehicle can attest, such vehicles have warning systems including malfunction indicator lamps. In the usual case the malfunction indicator lamps are generally uninformative. For example, a typical display of such a malfunction indicator lamps is “Check Engine.” Unfortunately, many of these lights are programmed so that they can be turned off only by a dealer. Often the lights are triggered by events that cannot be subsequently determined by the dealer when the light is reset. In short, these lights can be and often are a source of irritation. Even more important, sometimes the lights are activated by very routine automotive conditions, such as a dirty air filter. When such conditions occur, the driver must go to the dealer and pay a “diagnostic fee,” have the dealer correct the conditions (for example replace the dirty air filter), and finally retrieve the vehicle from the dealer. A simplification in the operation of such malfunction indicator lamps would be ideal.

[0012] The above enumeration of the background and the related problems to the background is specific to the invention disclosed. The reader will recognize that frequently invention can include recognition of the problem(s) to be solved. The background set forth above was selected after the preferred embodiment of this invention was developed.

[0013] An onboard diagnostic memory module is configured to plug into the OBD II port and has a real-time clock and power supply, a microprocessor powered from the OBD II port, microprocessor operating firmware, and an attached memory (currently 4 MB). In operation, the onboard diagnostic memory module is preprogrammed with data collection parameters through microprocessor firmware by connection to a PC having programming software for the module firmware. Thereafter, the onboard diagnostic memory module is moved into pin connection with the OBD II port of a vehicle. Data is recorded on a “trip” basis, preferably using starting of the engine to define the beginning of the trip and stopping of the engine to define the end of the trip. EPA-mandated operating parameters are monitored, including vehicle speed. From the monitored vehicle speed, hard and extreme acceleration and deceleration parameters, as well as distance traveled, is determined and logged on a trip basis. When loaded with a typical data set from connection to a vehicle, which can be up to 300 hours of trip operation (about one month of average vehicle operation), the onboard diagnostic memory module is unplugged from the vehicle and plugged into the RS 232 port of a PC. Alternatively, the vehicle installed onboard diagnostic memory module can be intelligently interrogated in a permanent position of installation in a vehicle. The intelligent interrogation occurs by interpretive software from an interrogating PC or palm sized personal digital assistant (PDA) to retrieve a trip-based and organized data set including hard and extreme acceleration and deceleration, velocity (in discrete bands), distance traveled, as well as the required EPA-mandated operating parameters. Telltale printouts can be generated highlighting operator habits (such as hard and extreme deceleration indicating that the driver is following too close), as well as the critical vehicle operating parameters. An extraordinary event log is maintained of densely recorded data based on (probable) accident parameters. Programming of the module can include resetting the malfunction indicator lamps of the vehicle. Installation of the module plugged to the OBD II port does not require vehicle modification.

[0014] The device is ideal for monitoring driver habits. The generated plots of vehicle speed bands with respect to time with overlying hard and extreme acceleration and deceleration parameters generates a unique telltale of driver habit including the “following too close.” Further, the module is capable of operating on a driver-assigned basis. For example, the driver can be required to connect the module to any vehicle he operates with the module faithfully recording the cumulative operating parameters of the particular vehicle(s), despite language changes at the OBD II ports.

[0015] Further, the device can be used to greatly facilitate repair. For example, where a vehicle owner complains of intermittent vehicle behavior, such as a vehicle stalling due to a sticking valve, the module can be plugged into the vehicle for a specific period of time while the vehicle undergoes normal operation by the operator. At the end of a preselected period of time, the module can be returned to a diagnosing PC, the problem determined, and the repair made. In determining the problem, the memory of the operator can be used to pinpoint the particular trip and the probable time of the intermittent malfunction. The mechanic can be directed to the particular data set containing the vehicle operating parameters to diagnose and repair the intermittent vehicle behavior.

[0016] The repair simplifications are manifold. For example, trip data sets can be correlated with the memory of the driver. The driver can then supplement the recorded information with his memory to fully reproduce the exact conditions under which a malfunction occurred. Further, where simple malfunction conditions exist, such as dirty air filters, they may be immediately identified and repaired by facilities having less than full vehicle repair capability. A dirty air filter may be replaced at the local gas station. Where a malfunction indicator light such as “Check Engine” is triggered by the dirty air filter, the vehicle operator can reset the malfunction indicator light using the programmed module.

[0017] Even more complicated repair scenarios are simplified. For example, when the operating data is downloaded to a PC, data coincident with a complicated malfunction can be isolated, and thereafter transmitted over the Internet to a diagnostic program specific to the vehicle involved. Thereafter, what is ordinarily a complicated diagnosis of vehicle malfunction can be rapidly reported to the mechanic or even to the vehicle operator. For example, for vehicles having custom parts with the OBD II port emitting custom codes, the codes can be sent over the Internet for diagnosis of the particular custom malfunction occurring.

[0018] Both the vehicle operator and the vehicle owner can benefit from the device. For example, where a company-owned vehicle is used by an operating employee required to submit expense reports, the combination of the trip-oriented data recordation (including time and trip mileage) with owner- and employee-generated information provides an uncontrovertable record of employee and vehicle operation. Further, where an accident occurs, the module can provide important corroboration to vehicle operating parameters which might otherwise be contested questions of fact related to the accident.

[0019] The PC can be interactive with the onboard diagnostic memory module. For example, if the operating firmware in the onboard diagnostic memory module contains a bug, correction can occur. Upon connection to the Internet, the PC can download a discrete program operable on a PC connected to the onboard diagnostic memory module. When the program is downloaded to the PC, it then runs to replace the firmware data set in the onboard diagnostic memory module to either remedy the malfunction or install and upgrade. Further, where enhanced operation of the onboard diagnostic port memory module is required for new vehicles, Internet firmware replacement can rapidly provide the required enhanced operation.

[0020] The organization of the collected data into “trip”-oriented data sets is particularly useful. In utilizing the system clock to time and date stamp the collected data with respect to a trip, the particularly useful organization of vehicle speed, acceleration and deceleration, and operating parameters can be collected. This organization, is extraordinarily useful, whether or not the module is removable from the vehicle. For example, provision may be made to download a permanently installed module using the infrared communication feature built into most hand held personal digital assistants (PDAs).

[0021] FIG. 1 is a picture of the driver console of an automobile showing an expanded view of the OBD II port, which port is typically under the dashboard near the steering column;

[0022] FIG. 2 is an illustration of the onboard diagnostic port being connected to a standard PC;

[0023] FIGS. 3A and 3B illustrate respectively the onboard diagnostic port memory module being connected to the onboard diagnostic port of an automobile and the connected onboard diagnostic port memory module with an illustrated firmware operated indicator lamp displayed from the module;

[0024] FIG. 4 is a schematic of the onboard diagnostic port memory module indicating the backup battery, clock, the memory, signal conditioner for reading the vehicle onboard diagnostic port, and finally the RS 232 driver for connection to a PC serial port;

[0025] FIGS. 5A-5E are wiring schematics of the onboard diagnostic port memory module used with this invention with:

[0026] FIG. 5A illustrating the microcontroller section;

[0027] FIG. 5B illustrating the physical interface to the vehicle for the PWM and VPW protocols;

[0028] FIG. 5C illustrating the physical interface to the vehicle for the ISO mode;

[0029] FIG. 5D illustrating the optional IrDA interface allowing the module to communicate with a personal digital assistant (PDA); and,

[0030] FIG. 5E illustrating the actual connection to the vehicle;

[0031] FIG. 6 is a firmware logic diagram of the firmware within the onboard diagnostic port memory module for recordation of data during vehicle operation;

[0032] FIG. 7 is a software logic diagram between the onboard diagnostic port memory module and a connected PC for both furnishing the module with settings and downloading data for analysis; and,

[0033] FIGS. 8A through 8H are representative plots and tables of the recorded data where:

[0034] FIG. 8A is a plot of speed against elapsed time indicating normal or conservative driving;

[0035] FIG. 8B is a plot of speed against elapsed time indicating abnormal, risk incurring driving with hard and extreme braking and accelerating;

[0036] FIG. 8C is a tabular presentation all of time, speed, engine speed, coolant temperature, engine load, and battery voltage useful in diagnosing engine operation;

[0037] FIG. 8D is a tabular presentation of elapsed time vs. speed from which acceleration and deceleration as well as distance traveled can be determined;

[0038] FIG. 8E is a graphical plot of coolant temperature vs. elapsed time for diagnosing engine temperature and thermostat operation;

[0039] FIG. 8F is a tabular plot of elapsed time, speed, engine speed, engine load, and coolant temperature;

[0040] FIG. 8G is a graphical plot of data triggering operation of an accident log wherein operating parameters are stored in a first in, last out stack for preserving data indicating a possible accident and,

[0041] FIG. 8H is a tabular presentation of the data triggering operation of the accident log.

[0042] Referring to FIG. 1, a driver console C is shown. An onboard diagnostic port 1 is typically configured under the dashboard adjacent to the steering column.

[0043] Referring to FIG. 2, aofn onboard diagnostic port memory module 10 has a 8 pin connector port 11 with a 9 pin connector 12 and power supply 13 for connection to the serial port of a PC 14. At PC 14 data can be conventionally printed, transmitted to the Internet, or otherwise processed. As will be understood, this invention also contemplates reading of data using IrDA ports.

[0044] Referring to FIGS. 3A and 3B, the onboard diagnostic port memory module 10 of this invention is illustrated as being plugged into OBD II port 1. In the plugged-in disposition, a firmware operated indicator light 2 can be used for indicating any number of selected functions including the presence of communication between the module 10 and the OBD II port.

[0045] Referring to FIG. 4, a schematic of onboard diagnostic port memory module 10 is illustrated. Three-volt battery 11 operates real-time clock 12 for the purpose of time stamping data. The time signal is given to CPU 13. When the module is connected to the OBD II port, signal conditioner 17 recognizes the particular language emitted by the vehicle and configures module 10 to receive data in the SAE J1850 (GM, Ford), ISO, ISO 9141 (Chrysler and most foreign cars) and KWP 2000 (many 2001 and later foreign cars) formats. Data is then channeled directly to memory 15.

[0046] Continuing with FIG. 4, programming and downloading of onboard diagnostic port memory module 10 occurs through PC serial port 20 connection and RS 232 driver 16. During programming, firmware within CPU 13 has parameters set for data recordation. During downloading, inquiry is made through the RS 232 driver for CPU 13 to download memory 15.

[0047] Having set forth in the general configuration of onboard diagnostic memory module 10, circuitry for use with this device can be understood with respect to FIGS. 5A through 5E.

[0048] There are five major sections to the design of the onboard diagnostic memory module 10 hardware. These are the Microcontroller Section shown in FIG. 5A, the PWM/VPW Physical Layer shown in FIG. 5B, the ISO Physical Layer shown in FIG. 5C, the Optional IrDA Interface shown in FIG. 5D, and the J1962 Interface shown in FIG. 5E.

[0049] As of this writing, the onboard diagnostic memory module design contains two printed circuit boards (PCBs), which are stacked on top of each other and connected via a single connector. The “top” board contains sections in FIGS. 5A, B, C, and D above, and the “bottom” board contains section in FIG. 5E.

[0050] At present, there are two variations of the onboard diagnostic memory module design: the “basic” version and the “advanced” version. The basic version runs on 5.0V and has a smaller serial flash memory while the advanced version runs on 3.3V and has a larger serial flash memory. Please refer to the schematics for each of the versions.

[0051] Bother versions (basic and advanced) support all four types of vehicle protocols using the same hardware: PWM, VPW, and the two variants of ISO. Each section will be described in the sections below.

[0052] The microcontroller section forms the heart of the design.

[0053] U8 is an ATMEL ATmega 16L microcontroller, with on board flash memory, SPI communications bus, and a UART. The microcontroller is supplied with an 8 MHz clock by crystal X2. The microcontroller is powered from 5.0V in the “basic” version of the product, and 3.3V in the “advanced” version.

[0054] U2 is an ATMEL serial flash memory chip where the trip log data is stored. The basic version of the onboard diagnostic memory module uses an AT45D011 1 mega-bit memory, while the advanced version uses an AT45DB041B 4 mega-bit part. The serial flash memory is powered from 5.0V in the basic version and 3.3V in the advanced version.

[0055] U5 is a Real Time Clock (RTC), which provides a non-volatile time source for the product. When no power is applied to the onboard diagnostic memory module, the RTC is powered from 3V battery BT1 (see J1962 Interface Section). When the onboard diagnostic memory module is powered, power to the RTC is supplied from either 5.0V (basic) or 3.3V (advanced). The clock communicates to the microcontroller (U8) via a two-wire communications bus.

[0056] U4 is a RS232 level shifter to provide communications with a PC. U4 has an integral charge pump to generate the proper voltage levels and operates from either 5.0V (basic) or 3.3V (advanced).

[0057] JP1 is a connector that provides the link to the PC when the onboard diagnostic memory module 10 is not plugged into the vehicle. There are three types of signals provided on this connector: a) external power, b) RS232 to PC, and c) SPI bus for development use. Note that diode D2 isolates the external power source from the vehicle power source if they are connected at the same time. The pin assignments are as follows:

[0058] The PWM/VPW Physical Layer (see FIG. 5B) provides the physical interface to the vehicle for the PWM and VPW protocols. Common parts are shared between the implementation of the two protocols in order to minimize cost and complexity.

[0059] U6A is an Operational Amplifier (Op Amp), which drives the J1850 Plus line for both the PWM and VPW modes. It is configured as a non-inverting amplifier with a gain of four (4) and the input on pin 3. Q1 is a NPN transistor and is used to provide a high current drive source.

[0060] The components R6, R8, C16, and R16 create a wave shaping network that drive the input of U6A (for the values of these components see the BOM for the basic and advanced models). The input of this network is the output of microcontroller U8 pin 14, PWM/VPW TXD. In the basic mode, this voltage is 5.0V when high and in the advanced model it is 3.3V when high. The output of the network (i.e. the input to U6 pin 3) is 2.0V in VPW mode and 1.25V in PWM mode, resulting in a signal on the J1850 Plus line of 8.0V in VPW mode and 5.0V in PWM mode.

[0061] Q2 is a NPN transistor that forms the drive for the J1850 Minus line. In PWM mode, Q2 is actively driven on and off in complement to Q1 thus creating a differential signal between the J1850 Plus and J1850 Minus lines. In VPW mode, Q2 is forced off, leaving the J1850 Minus line disconnected.

[0062] R7 and R14 form a bias network for PWM mode. If undriven or disconnected from the vehicle, the J1850 Plus line will be pulled low and the J1850 Minus line will be pulled high (5.0V).

[0063] R15, C17, and Q3 create a termination circuit for VPW mode. In VPW mode, Q3 is turned on thus enabling the termination. In PWM mode, Q3 is left off.

[0064] U6B and associated circuitry form a differential receiver for PWM mode. R18 provides approximately 10% hysteresis for noise immunity. Q4 provides a level shifter and inverter for the output signal that goes to the microcontroller U8 pin 16 (PWM/VPW RXD).

[0065] U6C and associated circuitry form a receiver for VPW mode. The reference value of 3.75V is used to compare against the VPW signal (which is nominally between 8V and 0V). R23 provides about 10% hysteresis for noise immunity, and Q5 creates a level shifter and inverter for the output signal, which is logically “OR'ed” with the signal from Q4 via an open collector configuration.

[0066] In PWM mode, Q5 is disabled (MODE3 forced low) and the signal to the microcontroller is derived from Q4. In VPW mode, Q4 is disabled (MODE2 forced low) and the signal to the microcontroller is derived from Q5.

[0067] The ISO Physical Layer (see FIG. 5C) provides the physical interface to the vehicle for the ISO mode.

[0068] Transistor Q6 (NPN) forms the drive for the ISO L line and Q7 forms the drive for the ISO K line.

[0069] U6D and associated circuitry form a receiver for ISO mode. The reference value of approximately 6.0V is used to compare against the ISO K signal (which is nominally between 12V and 0V). R36 provides about 10% hysteresis for noise immunity, and Q8 creates a level shifter and inverter for the output signal, which is connected to the microcontroller U8 pin 24.

[0070] JP2 is a socket (row of plated through holes), which provides the connection to the bottom board. The pin assignments are as follows:

[0071] The Optional IrDA Interface (see FIG. 5D) allows the onboard diagnostic memory module to communicate with a Personal Digital Assistant (PDA) using the wireless IrDA industry standard.

[0072] U10 is an “ENDEC” (Encoder/Decoder) chip that converts the serial data from the microcontroller U8 into a pulse train suitable for IrDA communication. U10 is supplied with a clock source equal to 16 times the serial baud rate from U8 pin 16, XCLK.

[0073] U11 is an IrDA transceiver that interfaces directly to the IR transmitter (LED D5) and the IR receiver (PIN diode D6).

[0074] If populated, both U10 and U11 are supplied from 3.3V in the advanced model, and 5.0V in the basic model.

[0075] The J1962 Interface (see FIG. 5E) is the actual connection to the vehicle and is located entirely on the bottom board.

[0076] P1 is the OBDII connector that interfaces with the vehicle:

[0077] Resistors R2 and R4 form a voltage divider network (18.0 Vin=2.56 Vout) that is used to sense the vehicle battery voltage by the microcontroller U8.

[0078] Diode D3 is used to isolate the vehicle power source from the external power source (if connected).

[0079] D4 is a Transient Voltage Suppressor (TVS) that is used to prevent voltage surges on the vehicle battery bus from damaging the onboard diagnostic memory module.

[0080] BT1 is a primary (non rechargeable) 3V battery cell that is used as the backup power for the RTC U5.

[0081] U1 is a 5V regulator used to power the onboard diagnostic memory module circuitry.

[0082] C38 is a 0.1 F “supercap” that is used to provide adequate hold up time when the onboard diagnostic memory module is unplugged from the vehicle. This is required so that the microcontroller has enough time to program the flash memory and perform an orderly shutdown before power is lost.

[0083] U13 is a 3.3V regulator that is only used in the advanced model. If the unit is a basic mode, R45 is installed instead of U13.

[0084] JP3 is the connector the top board that provides the following signals:

[0085] Referring to FIG. 6, a representative firmware logic diagram is illustrated. The reader will understand that the firmware can be upgraded from time to time by the expedient of having PC 14 Internet connected, downloading a program having a new firmware configuration from a web site, running the program in the PC to replacing the firmware in the unit. This type of protocol is preferred as inconsistencies in direct transfer of such a program from the web could interfere with the operation of the onboard diagnostic memory module. As of the writing of this application, the outlined firmware is preferred.

[0086] First, the onboard diagnostic port memory module is connected to the OBD II port of the host vehicle and detection of the connection made at 311. Sequentially, each protocol GM [VPW], Ford [PWM], ISO, and Advanced ISO [KWP] is tried at 312 from the onboard diagnostic port memory module to the automobile through the OBD II port 1. When the language of the vehicle is identified, both the pin array and the parameters necessary for reading data passing through the pin array are selected. Data is capable of being read and retained.

[0087] Second, onboard diagnostic port memory module 10 must determine the starting of the vehicle. In the protocol used here, where the engine has RPMs above 400, it is presumed that the vehicle is operating. Unfortunately, with at least some vehicles where constant interrogation is made for determining engine revolutions, battery failure can occur. Such battery failure results from the automobile computer being awakened, interrogating the engine for revolutions, and thereafter returning to the standby state. To avoid this effect, vehicle voltage is monitored. Where a starter motor is utilized, vehicle voltage change occurs. Only when vehicle voltage has changed by a predetermined amount, for example down two volts, is interrogation made of engine RPMs. The RPMs are chosen to be greater than those imposed by the starter motor but less than idling speed. Thus, vehicle voltage is detected at 314 and where voltage detection occurs, RPMs are measured at 315. This causes the storage of trip start data at 316.

[0088] Third, there is always the possibility of onboard diagnostic module 10 being disconnected from OBD II port 1, say where a driver chooses to have an unmonitored trip. In this case, tampered time 317 is recorded responsive to the drop in voltage caused by the disconnection. However, since engine revolutions will not be monitored in this instance, the data recorded will indicate onboard diagnostic module 10 disconnection from OBD II port 1.

[0089] Referring to FIG. 6, monitoring of vehicle speed occurs on a once-a-second basis at speed monitors 320. Thereafter, using previously recorded speeds, acceleration and deceleration is computed at 322. This data is temporarily stored at 324. Normal speed is recorded at 5-second intervals. Therefore, counter 325 asks each fifth speed count to be stored. Further, speed counts one through four are discarded during normal module operation at 326.

[0090] Returning to the calculation of acceleration and deceleration at 322, a probable accident log can be maintained. Specifically, and where deceleration has a threshold greater than certain preset limits, and the vehicle speed goes to zero, a log of these unusual events can be maintained. All vehicle events occurring within the previous 20 seconds are remembered in a stack. Data stored in this stack can be subsequently accessed.

[0091] It remains for the end of trip to be detected. Specifically, and at the end of each 5-second interval, engine speed is monitored at 327 to determine whether RPMs are above a certain preset limit, here shown as 400 RPMs. This speed is faster than that speed generated by the starter motor but less than the normal speed of the engine when it is idling. If engine speed in the preset amount (over 400 RPMs) is detected, the recordation cycle continues. If the speed is not detected, it is presumed that the trip is ended and the end-of-trip data is stored at 328.

[0092] Referring to FIG. 7, the software logic diagram is illustrated. The onboard diagnostic port memory module is schematically illustrated having data 410 and settings 411. A communication port 420 is shown communicating between onboard diagnostic module 10 and personal computer 14. Upon the initial connection to the PC, serial port identification 422 is determined. Thereafter, three discrete functions can be actuated with in onboard diagnostic module 10.

[0093] First, the onboard diagnostic module memory can be cleared at 425.

[0094] Second, the onboard diagnostic module memory can be downloaded at 426. This can include data viewing 427 of the trip log 428, activity log 429, the accident log 430, and the vehicle trouble log 431. Provision is made to store the accumulated data at 432 and to recover previously stored data at 433. Additionally, provision is made to label the onboard diagnostic module unit number, unit name, and particular vehicle utilized. For example, onboard diagnostic memory module 10 could be assigned to a particular driver, and that driver could have a choice of vehicles to operate. Each time the driver plugged onboard diagnostic memory module 10 into a vehicle to be operated, vehicle identity would be recorded at 440 along with the driver's identification.

[0095] Third, the onboard diagnostic port memory module can be configured at 450. Such configuration can include speed bands 451, deceleration or brake bands 452, acceleration bands 453, operational parameters 454, and finally the required time stamping clock setting at 455.

[0096] Referring to FIG. 8A, a plot of a car trip is presented. Elapsed time of the trip is plotted against vehicle speed. By way of example, deceleration or brake bands 452 and acceleration bands 453 can be chosen to be 0.28 gravity fields for hard braking and 0.48 gravity fields for extreme braking. Speed bands can likewise be selected. A typical selection could include 75 miles per hour and above [band I], 60 to 75 miles per hour [band II], 45 to 60 miles per hour [band III], and 0 to 45 miles per hour [band IV]. As can be seen in FIGS. 8A and 8B, such information can be graphically presented.

[0097] The particular utility of superimposing hard and extreme braking on the display data is apparent with respect to FIGS. 8B. Specifically, the data represented is commonly associated with the driving habit known as “following too close.” As can be seen in the plot, numerous braking incidents are recorded in the hard and extreme categories. Additionally, the drive is indicating abuse of the vehicle with rapid accelerations.

[0098] Referring to FIG. 8C, a data plot is shown listing elapsed time relative to speed, engine speed, cooling temperature, engine load, and battery voltage.

[0099] Referring to FIG. 8D, a plot of elapsed time vs. speed in miles per hour is illustrated. The reader will understand that from such data, both acceleration and deceleration as well as the distance traveled can be determined. In actual practice, speed traveled is frequently recorded. From the frequent recordings, accelerations and decelerations as well as distance traveled are computed, the former by differentiation and the latter by integration. Once this data is accumulated, intermediate velocity points can be discarded with the remaining velocity points being maintained in a table such as fat shown in FIG. 8D.

[0100] Referring to FIG. 8E, a plot of cooling temperature vs. time for a trip is illustrated. In this plot, possible malfunction of an automobile thermostat is illustrated.

[0101] Referring to FIG. 8F, a tabular plot of elapsed time, speed, engine speed, engine load, and cooling temperature is shown. It should be understood that through conventional manipulation of PC software, arrays of data can be presented in any desired format.

[0102] Referring to FIGS. 8G and 8H, and then triggering an “accident log” is respectively graphically and tabularly illustrated. It can be immediately seen that the event here is triggered by rapid deceleration. When such a profile is detected by the disclosed onboard diagnostic port memory module, all operating data is preserved in a dense format. Further, the operating data in its dense format is transferred to a first in, last out data stack having capacity in the usual case for between 30 and 32 such events. In this manner, the onboard diagnostic memory module can maintain for a substantial period of time operating vehicle profiles for accident situations. Thus, with the onboard diagnostic memory module of this invention, vehicle operating parameters that would be questions of controverted fact in the normal accident situations become unquestioned recorded data.

[0103] It is to be understood that the parameters for triggering an accident log recordation can be altered.