Vehicle platform-portable controller

[0002] The present invention relates to on-board vehicle controllers. More specifically, the present invention relates to an on-board vehicle control method and apparatus that is able to transfer data between electronic devices such as remote development, diagnostic, and software tools and on-board vehicle controllers.

[0003] An area in the auto industry seeing tremendous change from past practices is the area of control and communication in automotive vehicles. The creation of relatively inexpensive microprocessors and the digital revolution have put the power of advanced electronics and communications into the hands of automotive engineers. Controllers, microprocessors, and other electronic devices control and monitor various systems in a vehicle such as the transmission, the internal combustion engine, braking systems, and other related systems. The information stored on the controllers in the vehicle must be accessed by remote electronic devices such as development, diagnostic, and software tools (“tools”) during testing and programming. The tools are used to monitor and modify vehicle process variables and other vehicle data during testing and maintenance activities. The vehicle process variables and data indicate if the on-board electronic systems of the vehicle are functioning correctly and also control certain vehicle functions.

[0004] Vehicle controllers storing various vehicle process variables and data may be required to interface with a myriad of tools having numerous communication protocols. The communication protocols may vary from tool to tool as a function of manufacturer, and from vehicle controller to vehicle controller as a function of vehicle makes, models, or model years. Conventional vehicle controllers have limited communication flexibility and are only capable of communicating with a limited amount of tools under a specific communications protocol. In certain testing situations, more than one tool may be required for diagnostic testing of an automotive vehicle, and a vehicle controller will be required to communicate under numerous communications protocols to the tools. Presently, special external hardware and custom-made instrumentation is connected to a vehicle controller to trigger special logic embedded in the vehicle controller, generating a complex memory overlay process to allow tools to have access to the memory of the vehicle controller. This additional custom-made instrumentation may be unreliable, expensive, and difficult to maintain.

[0005] Furthermore, a number of present tools and vehicle controllers are rigidly pre-programmed for the types and amount of data that may be transferred between them. Accordingly, because of the limited flexibility of present day tools and vehicle controllers, there is a need for a dynamic adaptable method and apparatus to transfer information between a tool and a vehicle controller.

[0006] In accordance with the present invention, an on-board vehicle controller includes a processor/communication protocol independent method and apparatus to simultaneously support the concurrent use of multiple tools to monitor the state of memory locations in the vehicle controller at multiple transmission rates. The vehicle controller includes software to interface with remote development, diagnostic, and software tools having multiple communications protocols. The vehicle controller includes communications specific hardware and software that is able to receive and transmit information over a plurality of standard communication protocols such as IES-CAN, GMLAN, KWP2000, J1850, and J1939. The communication link specific software is contained in a first datalink/network layer that interfaces to a second applications layer which is functionally independent of the communications protocol.

[0007] The vehicle controller of the present invention allows tools to request periodic memory transfer from the vehicle controller memory at rates between 1 and 65,535 ms, but any technically feasible data transfer rate is considered within the scope of this invention. The actual data rates are multiples of the rate at which the method or algorithm of the vehicle controller is tasked and are calculated during a data request by a tool. The method of the present vehicle controller supports up to 255 simultaneous tools, allowing more than one tool to share a specific piece of transmitted information if the requested transfer rate and memory location is identical to that of another tool.

[0008] The vehicle controller of the present invention has many potential advantages over traditional external hardware-based systems, including reduced cost, reduced down time due to instrumentation hardware issues, increased development productivity due to simplification of the instrumentation and communication systems, and a more easily maintained system, as compared to present systems. In addition, the method of the present invention will reduce start-up time and costs associated with developing a new vehicle controller by eliminating the necessity to maintain several sets of external instrumentation hardware and software.

[0009] The various advantages of the present invention will become apparent to one skilled in the art upon reading the following specification and by reference to the drawings in which:

[0010] FIG. 1 is a diagrammatic drawing of a vehicle incorporating the vehicle controller of the present invention;

[0011] FIG. 2 is a block diagram of a vehicle controller illustrating the data request table of the present invention;

[0012] FIG. 3 is a diagrammatic drawing of the communications architecture of the vehicle controller of the present invention; and

[0013] FIGS. 4-12 are flowcharts of the methods/routines used by the vehicle controller of the present invention to transfer data between a remote tool and a vehicle controller.

[0014] Referring to FIG. 1, a vehicle 10 is shown including a plurality of on-board vehicle controllers 12. The term on-board is defined as being located in a substantially permanent manner on or within the vehicle 10. The vehicle controllers 12 may include engine control modules, transmission control modules, brake system control modules, instrument control modules, and any other on-board vehicle controller. The vehicle controllers 12 communicate via a communications network 14. The communications network may comprise any known vehicle communications system such as IES-CAN, GMLAN, KWP2000, J1850, CCD, or J1939, but is not limited to such. Remote development, diagnostic, and other software tools 16 may interface with the communications network 14 to access vehicle process variables and data in the memory of the vehicle controllers 12. The variables and data are used by the tools 16 to test the vehicle 10 electronic systems, diagnose problems, and/or adjust vehicle parameters.

[0015] FIG. 2 is a block diagram of the vehicle controller 12 used in the present invention. The vehicle controller 12 includes a power interface 18, clock input 20, an input/output interface 22 having analog and digital capabilities, and a communications interface 24 to transfer data over the communications protocols/networks previously described in this application. The vehicle controller 12 in the preferred embodiment may communicate, via communications interface 24, over multiple communications networks simultaneously to transfer data to multiple tools.

[0016] The vehicle controller 12 further includes ROM 26 and RAM 28. The ROM 26 includes the basic operating system of the vehicle controller 12 and any other data and parameters which generally require permanent storage in the vehicle controller 12. The function of the RAM 28 includes the manipulation and storage of vehicle process variables and other vehicle data. The operating system of the vehicle controller 12 determines the specific memory locations of vehicle process variables and data in the RAM 28. FIG. 2 also illustrates a data request table (“DRT”) 25 built by the vehicle controller 12 in the RAM 28. The DRT 25 is built in response to a data request from a tool 16 to transmit vehicle process variables or data from the vehicle controller 12 to the tool 16. The DRT 25 includes the tool ID, the message ID, the addresses of specific variables in RAM 28, data lengths associated with each variable, and a transfer rate to transmit the variable to the tool 12 that performed a data request. The DRT 25 will be further described in the specification with reference to the methods of the present invention.

[0017] FIG. 3 is a diagrammatic drawing of the preferred embodiment of the vehicle controller 12 communication architecture of the present invention. The communication interface 24 of the vehicle controller 12 of the present invention includes specific communications hardware such as the J1850 communications interface 30 and the J1939 communications interface 32 shown in FIG. 3, but is not limited to such. In the communications architecture of the vehicle controller 12, communications specific hardware and software is included in a first datalink/network layer 29. The first layer 29 handles all of the communication link specific message processing for the previously mentioned vehicle networks, including interfacing with the hardware and receiving, transmitting, filtering, and buffering of all messages between the vehicle controller 12 and tools 16. Incoming requests from a tool 12 are reformatted into generic form by a virtual input system (“VIOS”) 33 and made available to a second communication layer 31 for processing. The VIOS 33 enables the second communication layer 31 to be communication protocol non-specific. This is one of the major advantages of the vehicle controller 12 of the present invention since the second layer 31 data is generic and may be used with multiple communication protocols and their associated hardware and software. The first layer 31 formats each response to a communication link in use and handles the transmit process via the communication hardware.

[0018] The second communications layer 31 forms the core portion of the method and apparatus of the present invention. As discussed previously, the second layer 31 receives tool 16 requests, via the VIOS 33, located in the first layer 29. The information transferred by the VIOS 33 to the second layer 31 is not specific to a particular communications protocol, allowing the data generated and received by the second layer 31 to be used with multiple communications protocols after it has been processed by the VIOS 33. The second layer 31 processes each incoming tool 16 request and generates a response that is sent back to the first layer 29.

[0019] The DRT 25 is built in the RAM 28 in response to a tool 16 request for a transfer of vehicle controller 12 process variables and/or data from the RAM 28 to the tool 16. The tool 16 knows the memory locations of the vehicle process variables and data in the RAM 28 because the operating system of the vehicle controller 12 it is communicating with defines these memory locations. The vehicle controller 12 operating system will place specific vehicle process variables and data in specific fixed memory locations in RAM 28. The tool 16 includes a table of operating systems identifying the memory location of each vehicle process variable in RAM 28 for each vehicle controller 12 operating system.

[0020] A tool 16 request to schedule the periodic transmission of a memory location contains request status, tool device ID, message ID of periodic message (MID), memory location of requested data in message, data byte count, and transmit rate. Each tool 16 uses this information to decode periodic messages received from the vehicle controller 12 to extract the data from the correct message. The vehicle controller 12 uses this information to determine how to configure the DRT 25 to transmit the data requested by the tool 16. The DRT 25 is dynamic and may be readily modified by a single tool 16 or multiple tools 16. The vehicle controller 12 combines all identical requests from a plurality of tools 16 to allow maximum use of the communication link bandwidth and CPU time. The tool 16 arbitration logic is contained within the vehicle controller 12 and not an external tool 16, allowing the vehicle controller 12 of the present invention to communicate with multiple tools 16 over multiple communication protocols/links.

[0021] FIGS. 4-12 are flowcharts of the methods and routines used by the vehicle controller 12 of the present invention to transfer data to a remote tool 16. FIG. 4 is a broad overview of the method/routine of the present invention. At block 40, the second layer or application layer 31 monitors the communication network 14 for data requests from the first layer 29. Continuing to block 42, the second layer 31 processes requests from the first layer 29 generated by the remote tool 16. At block 44, the application layer builds the DRT 25 and generates the periodic responses to the tool or tools 16. The routine of FIG. 4 ends at block 46.

[0022] FIG. 5 is a more detailed description of the block 44 of FIG. 4 that processes requests from the first layer 29. Starting at block 50, the routine checks if there are any data requests from the first layer 29. If there are no data requests from the first layer 29, the routine will end at block 60. If there are data requests from the first layer 29, then the routine will continue to block 52 where it determines if it should schedule DRT 25 requests. If yes, the routine continues to block 54 to process a schedule of DRT 25 requests. The routine of block 54 builds DRT 25 response messages if the DRT 25 is enabled and contains valid data. If the routine does not schedule a DRT 25 request, the routine at block 56 determines if it should clear the DRT 25 request. If no, the routine ends at block 60. If yes, the routine clears the DRT 25 request at block 58.

[0023] FIG. 6 is a more detailed description of the block 54 of FIG. 5. Starting at block 70, the routine checks if the requested start address in the DRT 25 request is in a valid memory range. If no, a response flag is set as unsuccessful at block 72 and sent to the first layer 29 at block 74, with the routine ending at block 76. If the start address is in a valid range, then the routine checks if the requested byte count is less than the maximum allowed at block 76. If the requested byte count is greater than the maximum allowed, then the routine will continue to block 74. If the byte count is less than the maximum allowed, then the actual data transfer rate between the vehicle controller 12 and the tool 16 will be set at block 78. Continuing to blocks 80 and 82, the routine will check for duplicate requests from a plurality of tools 16. If a duplicate request is not present, then a new entry will be added to the DRT 25 at block 84. If a duplicate request is present, then the status flag will be set as successful at block 86 and a response will be sent to the first layer 29 at block 74 with the routine ending at block 76. If a duplicate request is not present, then a new DRT 25 entry will be added at block 84 and the routine will continue to block 86 where the response status flag will be set as successful.

[0024] FIG. 7 is a more detailed description of the block 80 of FIG. 6. Starting at block 90, the routine compares a schedule DRT 25 request to each existing DRT 25 entry. Continuing to block 92, the routine compares the transmit rate and address range of an existing DRT 25 entry with the new request. If the new request does not match an existing DRT 25 entry, then a duplicate request flag will be set as no at block 94. If the new request does match an existing DRT 25 entry, then the flags and variables listed in block 96 will be assigned values as shown in block 96, and the routine will end at block 98.

[0025] FIG. 8 is a more detailed description of the block 84 of FIG. 6. Starting at block 100, the routine determines if there is room in the DRT 25 for an additional DRT 25 entry. If no, the response status flag is set as unsuccessful at block 102 and the routine continues to block 104 where it ends. If there is room in the DRT 25 for an additional entry, then the flags and variables are assigned values as shown in block 106.

[0026] FIG. 9 is a more detailed description of the block 58 of FIG. 5. The routine at block 110 clears all DRT 25 entries that are used only by the tool 16 that is requesting the clear and ends at block 112.

[0027] FIG. 10 is a more detailed description of the block 42 of FIG. 4. Starting at block 120, the DRT 25 timers are updated and the DRT 25 messages are built at block 122 with the routine ending at block 124.

[0028] FIG. 11 is a more detailed description of the block 120 of FIG. 10. Starting at block 130, the DRT 25 timer is set equal to the DRT 25 timer+DRT 25 transmit rate/reference task rate. Block 132 sets the fastest rate that data will be scheduled to be sent to the tool 16. At block 134, flag and variable values are assigned as shown. Continuing to block 136, the routine sends a response to the first layer 29 with the routine ending at block 138.

[0029] FIG. 12 is a flowchart of the operation of the VIOS 33 layer.

[0030] Starting at block 140, the routine determines if there is a new request from the hardware to the VIOS 33. If there is not a new request, then the routine continues to block 144. If there is a new request received from hardware, then the routine at block 142 converts communication protocol/link specific data from received message to general second layer 31 formats and makes the data available to the second layer 31. Block 144 determines if there is a new response from the second layer 31. If there is no new response from the second layer 31, the routine ends at block 148. If there is a response from the second layer 31, the routine continues to block 146 where the data from the second layer 31 is converted to a communication protocol/link specific format and communicated to hardware.

[0031] While this invention has been described in terms of some specific embodiments, it will be appreciated that other forms can readily be adapted by one skilled in the art. Accordingly, the scope of this invention is to be considered limited only by the following claims.