System and method for retrieving and displaying vehicle control unit data

A system and method for retrieving and displaying data from an onboard memory of an electronic control unit in a vehicle is disclosed. The electronic control unit includes at least one parameter identifier that defines an address for a first data structure. The first data structure includes information on the amount and location of the data in the nonvolatile memory, as well as a version document number corresponding to a version document stored in a scan tool. The scan tool can access the parameter identifier and onboard data by the entry of an identifier number. The retrieved data is inserted into the version document for display.

BACKGROUND OF INVENTION

The present invention relates to data stored onboard a vehicle's electronic control unit, and more particularly to a system and method for retrieving, converting and formatting data from the electronic control unit in the vehicle.

The software employed onboard vehicles' electronic control units (ECU) is becoming more capable and complex, and the amount of data being processed is increasing dramatically. Some of this data is stored in nonvolatile memory—also called keep alive memory (KAM)—which can be retrieved and processed at a later time. The ability to efficiently obtain and process this ECU data from the nonvolatile memory may facilitate the verification of the quality of the design, manufacturing and calibration of various electronic control systems. This ECU data may be particularly useful during development testing. This ECU data may also be used to obtain operator driving habits, detect degraded components, and assist in solving service concerns in the field. Consequently, storing data in nonvolatile memory onboard the ECU and retrieval of this data is a very sought-after function.

An example of such a desirable use is the storing and retrieval of data related to a transmission adaptive pressure table. This data may be employed by engineering and testing personnel to determine the quality of the design, manufacturing and calibration of the pressure control system on developmental and durability test vehicles. Other examples of desirable uses for data stored in ECU nonvolatile memory relate to parametric data—also called flight recorder data. Such parametric data may include electronic throttle control data and transmission fault data. This data may be later retrieved and employed to help solve service concerns in the field.

While retrieving this ECU data may be desirable, this increases the complexity of the onboard software needed to store this data, increases the size requirements of the onboard memory, and increases the load on the data communication network. Thus, locating and retrieving the data is a more complex and time-consuming process than is desirable. Moreover, different vehicle models and different model year vehicles may not even store the data for a particular vehicle function in the same format or locations. This further increases the complexity and time taken to retrieve the data since one must find out where the data is stored before being able to retrieve it.

Since the amount of data to be stored in the onboard memory of the vehicle is large and increasing as newer vehicles and systems are produced, much of the data is stored as raw data. That is, it is not formatted or labeled for ease of use by vehicle developers or service technicians since doing so would further increase the amount of information stored in onboard memory and increase the amount of data that would have to be transferred through the data communications network when retrieving the data.

Thus, it is desirable to have an ECU data retrieval and formatting system and process that can operate in a generic manner across different vehicle lines and model years to easily allow one to retrieve the onboard data for a particular vehicle function and have that data presented in a user-friendly format. Moreover it is desirable that such a system and process can accomplish these functions while minimizing both the onboard memory requirements and the load (bandwidth required) on the data communication network.

SUMMARY OF INVENTION

According to an aspect of the invention, there is provided a method of retrieving and displaying data from an onboard memory of an electronic control unit of a vehicle, the method comprising the steps of: communicating an identifier number from a scan tool to the electronic control unit, wherein the identifier number is associated with a vehicle component or a vehicle function; communicating, from the electronic control unit to the scan tool, a memory address for a first data structure from a parameter identifier corresponding to the identifier number; communicating, from the electronic control unit to the scan tool, an amount, formats and locations of data in the onboard memory; communicating, from the electronic control unit to the scan tool, a version document number; retrieving the data from the onboard memory to the scan tool; storing a version document corresponding to the version document number in the scan tool; inserting the retrieved data from the onboard memory in the version document; and displaying the version document with the retrieved data inserted therein.

According to another aspect of the invention, there is provided a system for retrieving and displaying data from a vehicle. The system may include an electronic control unit and a scan tool. The electronic control unit is located in the vehicle and has nonvolatile memory including a parameter identifier with a changeable memory address stored therein that is accessible via an identifier number associated with a vehicle component or function, and a first data structure beginning at the memory address that includes amount, location, and version document number information. The scan tool includes a device for selectively communicating with the electronic control unit, and also includes a mass storage device with a version document stored therein corresponding to the version document number information stored in the nonvolatile memory of the electronic control unit, and a display capable of displaying the version document with data retrieved from the vehicle inserted therein.

According to yet another aspect of the invention, there is provided an electronic control system for use in a vehicle including a data communication network and an electronic control unit. The data communication network is adapted to selectively communicate with a scan tool. The electronic control unit includes a controller operatively engaging the data communication network to receive and transmit data thereon, and nonvolatile memory in communication with the controller. The nonvolatile memory includes a parameter identifier having a memory address for accessing a first data structure, wherein the first data structure includes a first member indicative of an amount of data, a second member indicative of a vehicle function to which the data relates, and a third member indicative of a corresponding external document for inserting the data therein and displaying the external document. The first data structure may also include a fourth member indicating a location of a second data structure containing formatting information for the data and a fifth member indicating a location of a third data structure containing memory address information for the data.

An advantage of an embodiment of the present invention is that a single generic process can be employed to quickly and easily retrieve and present the data in a usable format across multiple vehicle lines and model years. Even variations in amount, types, formats, attributes, conversions, and locations of the stored data are easily accommodated by this single process.

Another advantage of an embodiment of the present invention is that the data is presented in a readily usable format while minimizing the on-board memory requirements for the vehicle. Moreover, in minimizing the on-board memory requirements, the amount of data flowing over the data communication network when retrieving the data is reduced.

A further advantage of an embodiment of the present invention is that one can retrieve the data without knowing exactly where the data is located in the onboard memory, the format of the data, or the amount of data. Thus, even if the ECU is updated, one may readily retrieve the desired data in a usable format without knowing how the updates changed the structure or location of the data stored in the onboard memory.

DETAILED DESCRIPTION

FIGS. 1-2illustrate a vehicle, indicated generally at20, in communication with a scan tool, indicated generally at22. The vehicle20includes an engine24and transmission26connected to a driveline28. The engine may be in communication with and partially controlled by an electronic control unit (ECU)30, and the transmission in communication with and partially controlled by a transmission control unit (TCU)32. The two units30,32may be in communication with one another through a data communication network34. The data communication network34may have a vehicle connector36through which one may access the data in the ECU30and/or TCU32.

As an alternative or in addition to the vehicle connector36, the data communication network34may include a wireless transmitter38through which the data may be accessed. With the more widespread use of telematics in modern vehicles, the wireless transceiver38may be employed to allow one to perform remote diagnostics and prognostics. Such systems may include, for example, satellite systems (not shown) or mobile phone networks (not shown).

In addition, while the ECU30and TCU32are shown separately, they may be integrated into a single control unit, if so desired. Moreover, the vehicle20may include other control units that are in communication with or integrated with the ECU30and TCU32, and the system and method of the present invention may be employed with any or all of these control units, if so desired.

The ECU30includes input/output ports40for communicating with various vehicle sensors (not shown), switches (not shown), actuators (not shown), other control units, etc. Since the devices with which an ECU30may communicate are known to those skilled in the art, they will not be discussed further herein. The ECU30may also include a controller42having a central processing unit (CPU)44, read only memory (ROM)46, random access memory (RAM)48, and onboard nonvolatile memory50, also known as keep alive memory (KAM). Stored within the onboard nonvolatile memory50are a series of parameter identifiers (PID)52, each associated with particular types of vehicle components, subsystems, and/or vehicle functions. The PID52will be discussed in more detail below relative toFIG. 3.

The scan tool22may be in the form of a stand alone unit, a laptop computer, part of a computer system connected through a network (not shown), or some other electronic processor and display system. The scan tool22may include a display, such as a monitor54or printer (not shown), an input device, such as a keyboard56, and a scan tool processor58. When the term display is used herein, this includes any typical form of presenting the data in a human readable form, such as, for example, with a computer monitor, a paper printout, etc. The scan tool processor58may include a tool controller60having a central processing unit (CPU)62, read only memory (ROM)64, random access memory (RAM)66, and a mass storage device, such as an optical or magnetic disk drive68. The scan tool22also includes a tool connector70for connecting to the vehicle connector36. Alternatively, or in addition, the scan tool22may include or be in communication with a wireless transceiver72that can transfer data with the wireless transceiver38on the vehicle20.

FIG. 3is a data structure layout for locating and retrieving data stored in the onboard nonvolatile memory50of the vehicle electronic control unit30. As discussed above, a series of parameter identifiers (PID)52, each associated with particular types of vehicle components, subsystems, and/or vehicle functions are stored within the onboard nonvolatile memory50.FIG. 3illustrates the data structure layout for one PID52, with each PID having the same type of data structure layout.

The first PID52is associated with an identifier number74. Each PID52will be associated with its own unique identifier number74. The identifier number74is the same for all vehicle applications. That is, a service technician (or vehicle developer, etc., as the case may be) will enter into the scan tool22one particular identifier number74when desiring to obtain data relating to, for example, a transmission adaptive pressure table data. That same identifier number74will be employed to request adaptive pressure table data across most—and preferably all—vehicle lines for a given vehicle manufacturer. The second PID is associated with a different identifier number that a service technician will enter into the scan tool22when desiring to obtain data relating to, for example, electronic throttle control freeze frame data. Accordingly, each type of component, subsystem, and/or function for which retrievable data is stored with have its own unique identifier number. The particular data contained in the PID52, however, may vary from vehicle application to vehicle application.

The data contained in each PID52is an address of a memory location for a first data structure76in the nonvolatile memory50of the ECU30. This first data structure76contains five members, with each being a thirty-two bit unsigned number. A first member78is the number of data items, parameters or tables to be retrieved. A second member80is the component or function type that the data items relate to. For example, electronic transmission adaptive pressure table data or electronic throttle control freeze frame data. A third member82indicates the particular version of the external documentation associated with the particular component or function type. The external documentation will be discussed below relative toFIGS. 6 and 7.

A fourth member84is a starting address memory location for a second data structure86. The second data structure86contains three members, with each element of each member being an eight bit unsigned number. This second data structure86provides data format information for each data item, parameter or table. The dimensions of the second data structure86are determined by the number of data items, parameters or tables to be retrieved, which is found in the first member78of the first data structure76. A first member88of the second data structure86indicates the data language of the data items, parameters or tables. A second member90of the second data structure86indicates the number of columns for the corresponding data item, parameter or table, while a third member92of the second data structure86indicates the number of rows for the corresponding data item, parameter or table.

A fifth member94of the first data structure76is an address memory location for a third data structure96. The third data structure96contains one member98, with each element of this member98being a thirty-two bit unsigned number. This one member98contains the starting memory address for each data item, parameter or table, with the data located at each memory address corresponding to the type indicated in the second data structure86. The dimension of the third data structure96is determined by the number of data items, parameters or tables to be retrieved, which is found in the first member78of the first data structure76.

Thus, with an identifier number74that stays the same from vehicle application to vehicle application, a technician can readily extract the desired data for a particular component or function, while the PID52and data structures76,86,96allow for flexibility in arranging, storing, and even changing the location and format of the actual data stored in the non-volatile memory50for that particular component or function.

FIG. 4shows a specific example of the data structure layout as discussed relative toFIG. 3. The service technician, through the scan tool22(show inFIGS. 1 and 2), will input the identifier number74′ for the particular type of component or function data desired. The identifier number74′ may be, for example $1930, when desiring to obtain electronic transmission adaptive pressure table data. This particular identifier number74′ of $1930, then, is preferably the same number that the service technician will enter for any vehicle across all vehicle lines of a particular manufacturer when desiring to obtain electronic transmission adaptive pressure table data. The data value of the PID52′ corresponding to that identifier number74′, for example 003FB8A4, which is an address for a memory location, will then be read. While the identifier number74′ will be the same across vehicle lines, the address in the PID52′ may vary from vehicle line to vehicle line. This keeps the process simple and efficient for the service technician, while still providing maximum flexibility for computer programmers to make updates to the ECU30and vary location, amount and formatting of the data that is stored in the nonvolatile memory50.

After receiving the address of the memory location from the PID52′, the scan tool22performs direct memory requests to obtain the first four members of the first data structure76′. The first member78′ may have a value of, for example, twenty seven, which indicates that there are twenty seven data items, parameters or tables associated with the transmission adaptive pressure table data. The second member80′ may be, for example, three, which corresponds to the particular type of function to which the data applies. The third member82′ may be, for example, two, which means that the data retrieved will correspond to and can be presented correctly in an external version document number two associated with transmission adaptive pressure tables. The fourth member84′ may be, for example, 006039C, which is a pointer indicating the starting memory address for the second data structure86′. Again, this provides flexibility to the programmers for determining where to store data in the nonvolatile memory50while being transparent to the service technician.

The first member88′ of the second data structure86′ includes integer values corresponding to the data language of the data items, parameters or tables. For example, an integer value of one may be used to indicate the data of the corresponding item, parameter or table is a signed eight bit item, an integer value of two may be used to indicate that the data of the corresponding item, parameter or table is a signed sixteen bit item, an integer value of 3 may be used to indicate that the data of the corresponding item, parameter or tale is an unsigned eight bit item, etc. The number of integer values to read in the first member88′ will be twenty seven, which is known since the first member78′ of the first data structure76′ has already been retrieved. The second and third members90′,92′ provide information relating to the format of the data. The second member90′ indicates the number of columns for each data item, parameter or table—for example, five or seven columns of data. The third member92′ indicates the number of rows for each data item, parameter or table—for example, seven or one.

With the format for each data item, parameter or table now known, the locations are now needed. The fifth member94′ of the first data structure76′, may be, for example 003FB180, which is a pointer indicating the starting memory address for the third data structure96′. The one member98′ has twenty seven pointers indicating the starting memory addresses for each of the data items, parameters or tables in the nonvolatile memory50. The scan tool22now has all of the information needed to retrieve the onboard data relating to the transmission adaptive pressure tables.

FIG. 5shows an example of the onboard data stored in the nonvolatile memory50of the ECU30that is retrievable by employing the data structure layout ofFIG. 4. The scan tool22(shown inFIGS. 1 and 2), having retrieved all of the information relating to the amount, type, format, and location of the data, performs direct memory requests to retrieve the actual raw data itself. The first table102(table number00) has a starting memory address of 003FB370 and has thirty five raw data items, each being in a signed sixteen bit format. The second table104(table number01) has a starting memory address of 003FB3B8 and has thirty five raw data items, each being in a signed sixteen bit format. The third table106(table number02) has forty nine raw data items, each being in a signed eight bit format. The retrieval of the raw data continues through the twenty seventh table108(table number26) that has seven raw data items, each being in a signed eight bit format. The scan tool22now has the raw data, but it is not at this point in a user friendly format for the service technician.

FIG. 6shows a sample version document114stored in a disk drive68of the scan tool22. For the example illustrated inFIGS. 4 and 5, this would be version two of the external document relating to electronic transmission adaptive pressure table data. The particular version document114will be formatted and have labels that correspond to the type, order and formatting of the data stored onboard the vehicle for the vehicle component or function of interest. Thus, for each vehicle component and function, and for each situation where different information is collected for the particular component or function, a different version document will be employed. The scan tool22will be able to match the retrieved onboard data with the correct version document by looking at the second and third members80,82of the first data structure76(shown inFIGS. 3 and 4).

The version document114may include, for example, a heading116that provides the service technician with the type of component and/or function to which the data applies, as well as the component type and version number of the document. A first block of text118includes a name or description of the type of data contained in the first table, as well as preferably useful information, such as any conversion factor, the applicable units, precision, and names for the row and column (axis information). An insertion location120is provided for inserting the data from the first table (table number00) in its converted and formatted condition. A second block of text122includes the name of the type of data in the second table and other needed information, with a second insertion location124for inserting data from the second table (table number01). A third block of text126includes the name of the type of data in the third table and other needed information, with a third insertion location128for inserting data from the third table (table number02). Of course, the version document114repeats this format down to the twenty seventh block of text130that defines the twenty seventh table (table number26) of converted and formatted data132that will be inserted thereafter.

One will note that all of this information relating to the version document114is stored off-board in the scan tool22. This significantly reduces the amount of data that must be stored onboard the vehicle and also the amount of data that must be transferred from the vehicle to the scan tool, while still allowing the data to be presented in a user friendly format. Even so, it is still relatively easy to assure that the data is presented properly and in an easily usable format since, when the amount, formatting, etc. of the onboard data changes, the PID and document version can be easily changed to accommodate this. Moreover, if the particular scan tool being employed does not recognize the document version number, it can have a default backup display format where the data will just be output in the raw data format employed in the prior vehicle data retrieval systems.

FIG. 7shows the version document ofFIG. 6after the stored on-board data ofFIG. 5is retrieved and converted employing the process of the present invention. This shows how the retrieved data would be shown on the display54of the scan tool22, or alternatively printed out for the service technician to view. All of the data is now retrieved and shown in a user friendly format. The heading116assures the technician that the information for the desired component or function was retrieved. The blocks of text118,122,126,130provide the service technician with the context for the converted data that is displayed in the respective tables of converted data140,142,144,146. Thus, the service technician has a user friendly presentation of the data retrieved from the vehicle.

FIGS. 8A-8Care a flow chart illustrating a method of retrieving, converting and formatting data from a vehicle electronic control unit as applied to the system ofFIGS. 1-7. The scan tool22is connected to the data communication network34via the vehicle connector36, block200. As an alternative, this connection may be made wirelessly, as discussed above relative toFIGS. 1 and 2.

A service technician enters the identifier number74into the scan tool22to retrieve the PID52associated with the desired vehicle component and/or function type, block202. The memory address in that PID52is retrieved from the ECU30, block204, which provides the location of the first data structure. The data of the first member78of the first data structure76is retrieved, block206, indicating the number of data items, parameters or tables stored in the nonvolatile memory50associated with the vehicle component and/or function type of interest. The data of the second member80of the first data structure76is retrieved, block208, providing the type of vehicle function associated with this data. The data of the third member82of the first data structure76is retrieved, step210, providing the version number of the external document associated with this data.

A memory address of the second data structure86is obtained by retrieving the fourth member84of the first data structure76, block212. The dimensions of this second data structure86are known from the first member78of the first data structure76. The data of the first, second and third members88,90,92of the second data structure86are retrieved, block214. The format, including the language type and dimensions, of each raw data item is now known. A memory address of the third data structure96is obtained by retrieving the fifth member94of the first data structure76, block216. The dimensions of this third data structure96are also known from the first member78of the first data structure76. The memory addresses of the raw data contained in the one member98of the third data structure96are retrieved, block218. Now, in addition to the amount, type and format, the location for each raw data item is known.

The raw data is now retrieved from the nonvolatile memory50by the scan tool22, block220. A check is made to determine if the scan tool22has the correct version document corresponding to this data, block222. If not, then the scan tool22displays the raw data, block223. If the correct version document114is present, the raw data is converted to match the format, units, precision, etc. for the version document114into which it will be placed, block224. The particular version document114into which the data will be inserted is known from the second and third members80,82of the first data structure76. The converted data is inserted into the version document114, block226, and the version document114with the converted data is shown on the display54(or printed), block228. If the service technician wishes to access and display onboard data associated with a different vehicle component or function, block230, then a new identifier number can be entered in the scan tool22. If the retrieval of onboard data is complete, then the tool connector70is disconnected from the vehicle, block232.

As one can readily see from the description of the system and process described above, this system and process can handle variations in the stored data, which may include, for example, multiple and changing addresses, multiple and changing data types, multiple and changing data sizes and formats, multiple and changing data conversions, which includes names of data, units of measurement, precision, conversion factors, etc. All of these variations can be handled while providing a simple, user friendly way for a service technician to retrieve and view the onboard data. Moreover, the system and process significantly reduces the amount of data that must be stored onboard the vehicle and transmitted through its data communications network.