WO2007117370A1

WO2007117370A1 - In-vehicle diagnostic system with built-in browser capabilities

Info

Publication number: WO2007117370A1
Application number: PCT/US2007/005239
Authority: WO
Inventors: Robert Hoevenaar; Dale Trsar; Sunil Reddy
Original assignee: Snap-On Incorporated
Priority date: 2006-03-31
Filing date: 2007-03-01
Publication date: 2007-10-18
Also published as: EP2002402A1

Abstract

A system and method for vehicle diagnosis. In a vehicle having one or more control units (CUs) therein, at least one of the CUs is configured with an Internet Protocol (IP) address and has a web server therein for communicating with a device via a network. The device exchanges information with such a configured CU in a browseable form.

Description

IN-VEHICLE DIAGNOSTIC SYSTEM WITH BUILT-IN BROWSER

CAPABILITIES

TECHNICAL FIELD

[0001] The disclosure relates generally to automotive systems. More specifically, the disclosure relates to methods of and systems for vehicle diagnosis.

BACKGROUND ART

[0002] In current vehicle diagnosis, electronic control units (ECUs) in a vehicle use either proprietary or standard data communication protocols in order to transmit a serial data stream encoded with diagnostic information to an external device. The information communicated using conventional standard data communication protocols cannot be displayed or interpreted directly in a browser or a browser-like environment. Therefore, the data stream received by an external device needs to be interpreted first by the external device. In addition, in order to communicate such diagnostic information to personnel who are involved in the diagnosis, the interpreted diagnostic information needs to be presented in a form that is understandable to such personnel. For example, the diagnostic information may be displayed in a browser or a browser-like environment in which the diagnosis personnel may review and comprehend the information. Furthermore, to carry out the diagnosis, the personnel may then instruct, via the external device, ECUs in the vehicle to conduct further actions for diagnosis purposes.

[0003] Fig. 1 (Prior Art) depicts a block diagram of such a conventional scheme of vehicle diagnosis. An ECU 110 in a vehicle 105 may communicate with an external device 120 via a network 115. The information communicated between the vehicle 105 and the external device is currently not browser standard compliant. That is, such information cannot be readily intercepted by a browser standard compliant device and directly presented in an understandable form. The external device 120 comprises various components in order to carry out vehicle diagnosis. The external device 120 comprises a first communication unit 125, a diagnosis control unit 140, a data interpretation unit 130, and a second communication unit 170. To interpret information from the vehicle 105, the data conversion unit 130 may interpret the information from the vehicle based on one or more standard data communication protocols 160-a, ..., 160-b stored in the external device 120. Such interpreted diagnostic information is then forwarded to the diagnosis control unit 140, which then determines, based on both the interpreted diagnostic information, appropriate actions. Such a determination is made according to some diagnosis strategy, retrieved from a diagnosis strategy database 150. Each of the diagnosis strategies, 150-a, ..., 150-b, may correspond to some components in the vehicle and may be associated with an ECU that is responsible for controlling these components.

[0004] Although the diagnosis control unit 140 may process diagnosis information in a form that may or may not be different from the protocol employed by the ECUs in the vehicles, diagnostic information from an ECU has to be communicated to a human operator via the external device in a protocol that is understandable to the human operator. That is, prior to the diagnosis information from the ECU being communicated to a human operator, such information has to be interpreted and converted, by the data conversion unit 130, into a data form that can be presented, e.g., on a display screen 180, so that the human operator may effectively review the diagnostic information. Since the diagnosis information is not interpreted until it reaches an outside external device, any external device that communicates with the ECU 110 has to have the capability of interpreting the diagnostic information from the ECU. Furthermore, to carry out the diagnosis tasks, an external diagnosis device has to also store therein information associated with diagnosis strategies.

SUMMARY OF THE TEACHING

[0005] A system and methods for vehicle diagnosis are disclosed. In a vehicle having one or more control units (CUs) therein, at least one of the CUs is configured with an Internet Protocol (IP) address and has a web server therein for communicating with a device via a network. The device exchanges information with such a configured CU in a browseable form. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The invention claimed and/or described herein is described in terms of exemplary embodiments. These exemplary embodiments are described in detail with reference to the drawings. These embodiments are non-limiting exemplary embodiments, in which like reference numerals represent similar structures throughout the several views of the drawings, and wherein:

[0007] Fig. 1 (Prior Art) depicts a block diagram of a conventional scheme of vehicle diagnosis;

[0008] Fig. 2 depicts an exemplary configuration for vehicle diagnosis, according to an embodiment of the present teachings;

[0009] Fig. 3 depicts an exemplary configuration for vehicle diagnosis, according to a different embodiment of the present teachings;

[0010] Figs. 4 depicts an exemplary configuration for vehicle diagnosis, according to another embodiment of the present teachings;

[0011] Fig. 5 depicts an exemplary configuration for vehicle diagnosis, according to another different embodiment of the present teachings;

[0012] Fig. 6 shows a block diagram in which different parties communicate via a network based on an interoperable browser platform, according to an embodiment of the present teachings;

[0013] Fig. 7(a) shows a protocol hierarchy 700 in a master ECU, according to an embodiment of the present teaching;

[0014] Fig. 7(b) shows an exemplary alternative arrangement of protocol hierarchies in an ECU which has a vehicle diagnosis application included therein, according to an embodiment of the present teaching;

[0015] Fig. 7(c) shows another exemplary arrangement, according to an embodiment of the present teaching;

[0016] Fig. 8(a) depicts an exemplary internal structure of an electronic control unit

(ECU), according to an embodiment of the present teachings;

[0017] Fig. 8(b) depicts an exemplary structure of a central control unit with diagnostic strategy stored therein, according to an embodiment of the present teachings; and [0018] Fig. 9 depicts an exemplary arrangement of a central control unit and an information manager, according to an embodiment of the present teachings.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0019] Fig. 2 depicts an exemplary configuration 200 for vehicle diagnosis, according to an embodiment of the present teachings. In this embodiment, there comprises a vehicle 250, having therein one or more electronic control units (ECUs), e.g., ECU 1 260-a, ECU 2 260-b, ..., ECU M 260-c, an external device 210, and network 1 220. The external device may be operated by an operator 205. The external device may be a computer, a laptop, a hand held device, or any small devices such as a Palm Pilot and a cellular phone. The external device 210 may be used to communicate with the vehicle 250 via the network 220. The external device 210 may be deployed with a browser or an application that performs substantially browsing functions based on browsing techniques that comply with commonly known browser standard(s). Such a browser or browser-like application may be launched to communicate with the vehicle via the network 220. The network 220 may correspond to the Internet, a virtual private network, a wireless network, a local area network (LAN), a wide range network (WAN), a proprietary network, a public switched telephone network (PSTN), or any combination thereof.

[0020] The ECUs within the vehicle 250 may communicate with each other via a different network 280. The network 280 may be a local network with a scope that may or may not be limited to be within the vehicle 250. The network 280 may correspond to a wired network, a wireless network, or a combination thereof. One or more ECUs may have stored therein diagnosis strategies 270 (only one such ECU is shown). An ECU having diagnosis strategies stored therein may store both diagnosis strategies for itself and diagnosis strategies associated with other ECUs. For example, in Fig. 2, the ECU 1 260-a stores a plurality of diagnosis strategies 270-a, 270-b, ..., 270-c. There may be only one diagnosis strategy (e.g., diagnosis strategy 270-a) that is associated with the ECU 260-a. Other diagnosis strategies are stored for other ECUs (e.g., diagnosis strategy 270-b may be for ECU 260-b, ..., and diagnosis strategy 270-c may be for ECU 260-c). [0021] Each ECU may be used for controlling a part of the vehicle 250 and each such part may include one or more components. For example, an ECU may be an engine control unit configured to control a plurality of components of the engine of the vehicle 250 (e.g., starter of the engine, transmission of the engine, etc.). A different ECU may correspond to a control unit for the seats in the vehicle, including both the seats and the electronic circuits that control the movement and heating of the seats. An ECU may control each of the components within the part with which the ECU is associated. Such control may include obtaining information from or associated with a component such as the product number of the component or a default operating parameter used by the component. An ECU may also control a component by instructing the component to perform a specified operation with specified operational parameters and/or acquire the status of the component after a specified operation.

[0022] A diagnosis strategy associated with an ECU may be used to determine a procedure or a sequence of acts/tests to be performed in order to diagnose the vehicle. Such a diagnosis strategy may be represented as a tree with a plurality of levels, each of which may have more than one branch. Diagnosis of a particular part of the vehicle may be carried out by following the branches of such a diagnostic tree (or strategy) associated with that part of the vehicle. Each branch point of the diagnosis tree may correspond to instruction(s) to perform a specific diagnosis act or test. For example, if the engine of the vehicle 250 does not start, a diagnosis strategy associated with an ECU responsible for controlling the engine of the vehicle may be followed to obtain a guide as to acts or tests to be performed on what engine components and in what sequence in order to narrow down the source of the problem (or reach a diagnosis).

[0023] In some embodiments, the diagnosis strategy for an ECU may or may not be stored in that ECU. In such situations, the ECU that stores diagnosis strategies for other ECUs (e.g., as a master ECU) may act on behalf of the ECUs that do not store their diagnosis strategy therewith (e.g., as a slave ECU) in carrying out diagnosis tasks. For instance, a master ECU may interact with the external browser 210 to receive instructions as to which part of the vehicle is to be tested, access an appropriate diagnosis strategy for a slave ECU that controls the part to be tested, analyze the diagnosis strategy to determine a sequence of acts/tests to be performed based on the retrieved diagnosis strategy, instruct the slave ECU via internal network 280, to perform the acts/tests and/or obtain information related to components of the part.

[0024] In addition, the master ECU may communicate, on behalf of the slave ECU₅ with the external device 210 via the network 220. For example, a slave ECU may control, following an instruction from the master ECU, a component of the vehicle to perform an operation (e.g., ignition of the engine) and then receive status information from the component. When such status information is sent from the slave ECU to the master ECU₅ the master ECU may transform the status information into browsable form and then forward the received status information to the external device 210 via network 220. That is, a master ECU may be configured to be able to interpret both information in compliance with the browser standard and information that does not comply with the browser standard and perform necessary transformations of information into different forms.

[0025] Communication between a master ECU and the external device is carried out according to a browser standard. That is, the information from a master ECU is browsable on the external device. In some embodiments, communication among ECUs within the vehicle may comply with some proprietary format or some standard other than a browser standard. In this case, a master ECU may carry out necessary transformation^) for information received from a slave ECU to derive transformed information that is in a browsable form prior to forwarding it to the external device. Ih other embodiments, communication among ECUs internal to the vehicle may comply with the browser standard. In this case, no transformation may be needed. When the external device 210 receives information from an ECU via network 220, the external device 210 may directly display the received information in a browser without needing to transform it. Conversely, the external device may communicate with an ECU (e.g., a master ECU) in a form compatible with the browser standard.

[0026] In operation, an operator 205 may use external device 210 to communicate with vehicle 250 in order to diagnose vehicle 250. The external device 210 may carry out such interactions with the vehicle via, e.g., a browser interface, based on which the operator 205 may send information to, e.g., a master ECU in the vehicle to instruct it to test a certain part of the vehicle or obtain information from a part of the vehicle. If a slave ECU is responsible for controlling the part concerned, the master ECU may retrieve or access the diagnosis strategy stored therewith and instruct that slave ECU to perform what is requested according to the diagnosis strategy. If the part concerned is under the control of the master ECU, the master ECU acts according to the diagnosis strategy for its own part. [0027] Fig. 3 depicts an exemplary configuration 300 for vehicle diagnosis, according to a different embodiment of the present teachings. In this exemplary embodiment, each of the plurality of ECUs, 360-a, 360-b, ..., 360-c, within a vehicle 350 stores a corresponding diagnosis strategy. As illustrated, ECU 1 360-a stores a diagnosis strategy 370-a to be used in diagnosing a part of the vehicle under the control of ECU 1 360-a. ECU 2 360-b stores a diagnosis strategy 370-b to be used in diagnosing a different part of the vehicle that is under the control of ECU 1 360-b. ECU M 360-c stores a diagnosis strategy 370-c to be used in diagnosing another part of the vehicle that is under the control of ECU 1 360-c. [0028] As shown in embodiment 300, ECUs communicate with each other via an internal network 380, which can be wired, wireless, or a combination thereof. Such communication may be conducted according to either a known browser standard or a standard that is proprietary or non-browser compliant. At least one of the ECUs is capable of communicating with an external device 310 via an external network 320. Similar to the embodiment 200, network 320, like network 220, can be any form of network and external device 310 can be any one of the mentioned devices. In this embodiment, if an ECU is not capable of directly communicating with the external device 310, this ECU may be considered as a slave ECU and may indirectly communicate with the external device through another ECU that may be considered as a master ECU. A master ECU may be capable of processing both information that complies with a browser standard and information that does not comply with the browser standard and performing transformations between them. [0029] When instructed in a diagnosis process, either directly from the external device or indirectly from a master ECU, each ECU in embodiment 300 is capable of accessing the diagnosis strategy stored therein and acting accordingly to carry out diagnosis tasks. For example, each ECU is capable of controlling a component under its control to perform an operation and/or obtain information associated with a component including status information after an operation. In addition, each ECU is capable of forwarding information either directly to the external device 310 or indirectly through a master ECU, which subsequently transforms the information, if needed, into browsable form and then forwards the browsable information to the external device 310.

[0030] Fig. 4 depicts an exemplary configuration 400 for vehicle diagnosis, according to another embodiment of the present teachings. In this embodiment, all ECUs, 440-a, 440- b, ..., 440-c, in a vehicle 430 communicate with an external device 410 through a central control unit (CCU) 450. The internal communication in vehicle 430 is via a network 460 which can be a wired network, a wireless network, or a combination thereof. The CCU 450 stores diagnosis strategies, 470-a, 470-b, ..., 470-c, for corresponding ECUs 440-a, 440-b, .^'.., 440-c. CCU 450 is also responsible for providing an interface between the external device 410 and the ECUs and facilitating communications between the two via network 420. In addition, the CCU is capable of analyzing a diagnosis strategy determined according to information from the external device 410 and instructing accordingly an appropriate ECU to carry out certain acts.

[0031] In this embodiment, the CCU 450 is not an ECU or is not capable of controlling a component in the vehicle for diagnosis purposes. In some embodiments, communication between ECUs and CCU 450 complies with browser standard. In this case, the ECUs are configured to be able to perform transformations between signals from components in the vehicle and the information to be forwarded to the CCU 450. In other embodiments, ECUs operate on information in a non-browsable form. In this case, CCU 450 is configured to be able to interpret both non-browsable information and browsable information and perform necessary transformations between the two.

[0032] The arrangement, as shown in Fig. 4, of having a separate CCU 450 may facilitate easier reconfiguration or upgrade of diagnosis strategies. For example, the CCU 450 with diagnosis strategies stored therein may be implemented independent of the ECUs as a plug-in to the vehicle 430. If either the diagnosis strategies stored in the CCU 450 or any other parts of the CCU 450 are modified (e.g., the processing scheme of the CCU 450), the existing CCU 450 in vehicle 430 with the out-of-date parts may be easily replaced by unplugging the existing CCU 450 and then re-plugging it with a new plug-in corresponding to an updated CCU without having to unnecessarily replace any functions related to ECUs as would be required if diagnosis strategies were stored with their corresponding ECUs. [0033] Fig. 5 depicts an exemplary configuration 500 for vehicle diagnosis, according to another different embodiment of the present teachings. In this embodiment, an information manager 570 is provided, which is separate from a CCU 560 and which manages storage and access of diagnosis strategies 580-a, 580-b, ..., 580-c associated with all the ECUs 540-a, 540-b, ..., 540-c in a vehicle 530. The information manager may also manage the storage and access of other types of information such as different standards in which data from ECUs or associated components may be encoded. The information manager 570 communicates with the CCU 560 via network 550, which can be a wired network, a wireless network, or a combination thereof. The CCU 560 in this embodiment may function in a similar manner as the CCU 450 in embodiment 400 except that CCU 560 no longer has diagnosis strategies or other information stored therewith and needs to retrieve such diagnosis strategies and other information via the information manager 570 when needed. [0034] The arrangement, as shown in Fig. 5, of having a separate CCU 560 and the separate information manager 570 may further allow the flexibility of easy upgrade of any diagnosis strategy. For example, the information manager 570 with diagnosis strategies stored therein may be implemented as a plug-in to the vehicle 530. When new diagnosis strategies or new data standards come to the market, they may be sold in the form of a plug- in with an information manager (possibly updated) and the new diagnosis strategies implemented therein. An existing plug-in in vehicle 530 corresponding to an information manager with out-of-date diagnosis strategies stored therein may be easily replaced by unplugging the existing and re-plugging the new. This arrangement further provides the flexibility of easy upgrade of diagnosis strategies when no other processing needs to be changed without having to unnecessarily replace the entire CCU (as in embodiment 400). In some embodiments, to provide more flexible upgrade of a sub-group of diagnosis strategies, more than one information manager, each having a sub-group of diagnosis strategies stored therein, may also be provided. Each of such information managers may be individually called, by the CCU 560, to access diagnosis strategies stored therewith. This arrangement makes it possible to replace an information manager for upgrading the diagnosis strategies stored therein without having to replacing other information managers with un-changed diagnosis strategies. [0035] Fig. 6 shows a high level block diagram depicting an exemplary operational scheme 600 in which different parties relevant to vehicle diagnosis communicate via a network based on an interoperable browser platform, according to an embodiment of the present teachings. In this exemplary operational scheme 600, there comprises a vehicle 660, a repair shop computer system 605, a manufacturer web service system 645, one or more vehicle part suppliers, supplier 1 625, ... supplier K 635. These parties may be in communication with each other via a network 650 for issues related to diagnosis and repair thereafter of vehicle 660. Vehicle 660 may correspond to any one of the vehicle configurations as shown in Figs. 2-5. For example, vehicle 660 may include a plurality of ECUs 670-a, 670-b, ..., 670-c, that communicate with each other and/or with a CCU 665 via an internal local area network 680.

[0036] In operation, for example, a person having problems with vehicle 660 may communicate with the repair shop 605 to seek help. Such communication is through the network 650 with information transmitted in a form in compliance with a browser standard. To respond to a request for help from the vehicle 660, the repair shop 605 may seek further information from the vehicle. For instance, the repair shop may request information related to the type of vehicle (e.g., year and maker of the vehicle) and any information associated with the vehicle (e.g., age, mileage, gas level, last oil change date, etc.). The repair shop 605 may access a repair history database 610 for any repair/maintenance information, if any, related to the vehicle. The repair shop may also request person(s) in the vehicle to provide information related to the maintenance history of the vehicle. The person in the vehicle may in turn connect to a home computer/device to access a home database for the requested maintenance history 620 and submit such information to the repair shop. In some situations, the repair shop 605 may also contact the manufacturer web service 645 to acquire information related to the vehicle that may be useful for diagnosing the vehicle's problem. The repair shop 605 may then act, according to either the problems reported or information received, to instruct the vehicle to perform certain operations/testing/reporting, m some embodiments, the repair shop 605 may also communicate with one or more parts suppliers, e.g., suppliers 625, ..., 635 to, e.g., seek information related to certain parts used in the vehicle for diagnosis purposes or looking for replacement alternatives. [0037] Communications among different parties may be conducted at different physical locations via a browser interface and information exchanged during such a process may be directly displayed in a browser or a browser-like environment. Communications among these parties may also be conducted via more than one network (not shown in Fig. 6). For example, the vehicle 660 may be physically in the repair shop so that the vehicle communicates with the repair shop computer 605 via, e.g., a local area network, which can be either a wired or wireless network. The vehicle may also communicate with the repair shop via a wide area network such as the Internet. For example, when the vehicle is on the road and malfunctions, a driver may contact the repair shop to seek diagnosis remotely via a network. The repair shop may communicate with the manufacturer web service 645 via a wide area network such as the Internet.

[0038] In this exemplary scheme, multiple parties residing possibly at different locations may or may not share a common browser or a browser-like environment. In some embodiments, different grouping of such parties may share a same browser or a browser-like interface. When a common interface is shared among different parties, all sharing parties may see the same information displayed in a browser. When no common interface is shared, multiple parties may use other means to exchange information needed. For example, in the vehicle, a person may have more than one window open on their screen; each may be used to communicate with a certain group of parties. Information displayed in a first window may be cut and pasted into a second window in order to share that information with the parties connected to the second window. Such information may also be placed in a communication channel between the two windows such as a mail system and any information in the channel may then be shared.

[0039] Fig. 7(a) shows a protocol hierarchy 700 in a master ECU, according to an embodiment of the present teaching. The protocol hierarchy 700 comprises at least two hierarchies, a first hierarchy 710 and a second hierarchy 720. The first hierarchy 710 includes protocols that enable the master ECU to communicate data internal to the underlying in-vehicle network to outside of the vehicle using standard web interfaces (e.g., web server or web browser) via a network 705. The first hierarchy 710 includes, for example, a dynamic node configuration layer, a name server, a web server, a transport layer, and a physical layer. [0040] The second hierarchy 720 includes protocols that enable the master ECU to communicate with various vehicle components based on industry or proprietary standard protocols via a local area network (LAN) 715. Such vehicle components may be grouped into different networks, each of which may adopt a different protocol. For example, the second hierarchy may include an engine network, a transmission network, a sensor and control network, a dashboard network, etc. Depending on which component that the master ECU may need to communicate with, an appropriate protocol suitable for that component may be used. For instance, to communicate with a component in the engine of a vehicle, the master ECU may need to use a different protocol, defined in the Engine network, compared with a protocol used to communicate with a component in a break of the vehicle, defined in the Brakes Network.

[0041] A master ECU is capable of serving as a web server, which may dynamically acquire an Internet address (IP address) whenever it is activated. The master ECU may also be configured to set up a firewall for the in-vehicle network, between the network 705 and the master ECU, to prevent, e.g., malicious attackers from using the diagnostic facility to interfere with the operation of the vehicle or compromise its security. In addition, the master ECU may be configured to have a high level driver that implements an application-specific protocol for responding a request received from the web server. Upon receiving such a request, the driver may parse and decode the protocol data unit (PDU) and spawn different local tasks according to the request. When those local tasks complete requested operations, results yielded from the operations may be sent to the master ECU, which may then format such results based on Internet protocol or browser standard and return such formatted result to the web server.

[0042] A dynamic node configuration (DNC) server may be included in the first hierarchy 710 to maintain a list of active nodes within the vehicle, where each node is an ECU or any device in the vehicle. Such nodes may be web capable (e.g., an ECU with an IP address) or web incapable (e.g., an ECU that has no IP address and interfaces with only vehicle components). More than one web capable node that may exist in a vehicle. For example, there may be multiple devices in a vehicle that have an IP address and capable of communicate with outside or with each other via network 705 or LAN 7.15. Each of such nodes may have some distinct designated use. For example, some may be designated to the radio in the vehicle, some may be designated to a DVD player in the vehicle, and some may be designated to a wireless phone in the vehicle.

[0043] Each may be active (e,g,, being turned on) or inactive (e.g., being turned off).

An inactive node may become active by adding the node to the list of active node stored in the DNC server, which may be responsible for dynamically adding and deleting such nodes upon request. For example, when a node is to be added to the list, the node may immediately begin broadcasting a configuration request to the DNC server running on the master ECU. Such operation may be performed in compliance with the Dynamic Host Configuration Protocol (DHCP), a widely used standard protocol in the computer industry. The requesting node may then automatically acquire the network configuration. In a master ECU, specialized network configuration may be implemented. For example, a simplified protocol may be adopted to allow a slave ECU (Internet incapable) to acquire certain types of network configuration data.

[0044] A master ECU may serve as a host for the in-vehicle network, because the nodes themselves may not run protocol stacks. When a web browser needs to access a node inside of a vehicle, the web browser communicates with the web server in the master ECU. This web server may interpret the actions requested by the browser and accordingly conduct communication in the in-vehicle network to carry out the requested operations. The master ECU may also serve as a host for, e.g., external analog and digital I/O and external peripherals interfaced on low-overhead chip-to-chip networks.

[0045] Fig. 7(b) shows an exemplary alternative arrangement of protocol hierarchies in an ECU 730 which has a vehicle diagnosis application 745 included therein, according to an embodiment of the present teaching. In this exemplary alternative arrangement, an ECU 730 has a vehicle diagnosis application 745 running thereon and interfacing with a first hierarchy 740 and a second hierarchy 750. The vehicle diagnosis application 745 has diagnosis strategies embedded therein. The first hierarchy 740 includes layered protocols and languages, through which the vehicle diagnosis application 745 can communicate with other ECUs and/or outside of the vehicle via a network 735. The second hierarchy 750 includes various industry and/or proprietary standard protocols, through which the vehicle diagnosis application may communicate with different ECUs and/or vehicle components via network 735 and/or a LAN 755. [0046] Fig. 7(c) shows another exemplary arrangement, according to an embodiment of the present teaching. In this exemplary arrangement, an ECU 760 communicates with a vehicle diagnosis system 790 via either an in-vehicle network LAN 780 or a network 755. The ECU 760 includes a first hierarchy 765, having a stack of protocols and languages making the ECU web capable, and a second hierarchy 770, having protocols suitable for one or more in-vehicle devices/components, enabling the ECU to communicate with other ECUs and/or vehicle components. The diagnostic system 790 in Fig. 7(c) is an independent device/component in the vehicle and has its own stack of protocols and languages that make the diagnostic system Internet capable.

[0047] ^" The diagnostic system 790 may interface with ECU 760 via either one of the networks 780 and 775. The diagnostic system 790 may also communicate with outside of the vehicle (e.g., another web server in a vehicle repair shop) via network 755. To perform diagnostic tasks, the diagnostic system may have diagnosis strategies stored therein. Upon receiving a request from, e.g., a web browser, the web server in the diagnostic system may interpret the request and spawn into different sub-tasks, to be sent to one or more ECUs through the network 780. Requests for the sub- tasks may be web browser standard compliant so that the web server in the first hierarchy 765 may interpret the requests and send appropriate instructions, utilizing the protocols stored in the second hierarchy 770, to other ECUs and/or vehicle components to perform the requested operations.

[0048] Results obtained from vehicle components are received via the second hierarchy 770 and sent to the diagnostic system via the first hierarchy. Such results are then subsequently sent, in a web browser compliant form, by the web server in the diagnostic system, to the external world via network 775.

[0049] Fig. 8(a) depicts an exemplary internal structure 801 of an ECU with diagnosis strategies stored therein, according to an embodiment of the present teachings. As discussed earlier, an ECU with diagnosis strategies stored therein is capable of analyzing the diagnosis strategies and acting accordingly. An ECU that stores diagnosis strategies associated with other (slave) ECUs may act on behalf of the other ECUs (e.g., as a master ECU) to communicate with an external device and may instruct accordingly a slave ECU to control component(s) associated therewith to gather information or perform an operation. The exemplary ECU 801, as shown in Fig. 8(a), comprises a diagnosis strategy database 814, a diagnosis strategy (DS) manager 813, a DS retrieval unit 812, an analyzing unit 805, a strategy decision unit 811, a data collection unit 808-a, a component control unit 808-b, a data conversion unit 809, a data standard database 818, a display screen generator 806, a screen database 807, a first communication unit 804 responsible for communicating with an external device, and a second communication unit 815 responsible for communicating with other ECUs in a vehicle.

[0050] The first communication unit 804 may be used to optionally generate a GUI interface (not shown) that allows a person in a vehicle to interact with the system in a browser or browser-like environment. Such a GUI interface may be shared among several ECUs. For example, the ECU 801 may act as a master ECU and communicate with the outside world on behalf of all ECUs through this GUI unit. The first communication unit SOl may accept inputs from both the outside world (e.g., 802-a from an external device via an external network) and the internal world (e.g., input 802-b from other ECUs). The first communication unit 804 may also send output 803 to the outside world.

[0051] Upon receiving an external input 802-a, the first communication unit 804 may forward the input to the analyzing unit 805. The analyzing unit 805 may control, according to the analyzed result, the DS retrieval unit 812 to access a certain diagnosis strategy via the DS manager 813 from the DS database 814. The retrieved diagnosis strategy may then be forwarded to the strategy decision unit 811, where the retrieved diagnosis strategy is processed and appropriate action may then be taken by the strategy decision unit 811. For example, the strategy decision unit 811 may decide to acquire certain information from a target component and accordingly send an instruction to the data collection unit 808-a. The strategy decision unit 811 may also determine, based on retrieved diagnosis strategy, to control a target component to perform a certain operation as part of the diagnosis, hi this case, the strategy decision unit 811 may invoke the component control unit 808-b to act accordingly. The data collection unit 808-a or the component control unit 808-b that is invoked may determine which of the ECUs in the vehicle is associated with the target component and take appropriate control actions.

[0052] If the ECU 801 is a master ECU and the target component is not associated with the master ECU, the invoked unit (i.e., 808-a or 808-b) may send an instruction 816 through the second communication unit 815 (via an internal network) to a (slave) ECU associated with the target component to instruct the slave ECU to perform the act (i.e., either acquiring information from the component associated therewith or controlling the target component to perform the operation requested). Alternatively, if the target component is associated with the master ECU, the invoked unit (the data collection unit 808-a or the component control unit 808-b) may then send a control signal 816 through the second communication unit 815 directly to its associated component.

[0053] When the second communication unit 815 receives information 817, as a response to the request made from the target component, the information 817 is either directly from the target component (e.g., when the target component is associated with the master ECU) or from another ECU (indirectly from the target component). Such received information may be coded according to a proprietary standard or a non-browsable data standard and may be transformed or converted, by the data conversion unit 809, to produce corresponding information in a browsable form. Such transformed information is forwarded to the display screen generator 806, which may then utilize such browsable information to produce display screen(s), which may comprise information indicating the underlying diagnosis strategy used and information acquired during the diagnosis, all may be displayed in a browser or browser-like environment and can be viewed in a browser or browser-like environment.

[0054] The generated screen configuration is determined from the screen database

807. Such generated screen(s) may then be sent to the first communication unit 804, which may then forward the screen(s) to the outside world or an external device. Optionally, the first communication unit 804 may also display the generated screen internally in the vehicle when such display facility is made available. The browsable information may also be forwarded to the strategy decision unit 811 so that diagnosis strategy retrieved may be analyzed in light of the information received from the target component to further determine the next act to be performed according to the retrieved diagnosis strategy. [0055] The DS manager 813 may be optionally configured to download diagnosis strategies upon receiving an instruction from the first communication unit 804. Such an instruction may be initiated by a person within the vehicle (e.g., via a GUI interface) or by an external device that communicates with the first communication unit from outside of the vehicle (e.g., a repair shop computer system). When such an instruction is received, the DS manager 813 may independently communicate with a source from where diagnosis strategies are stored (e.g., a manufacturer web site) and can be downloaded. The downloaded diagnosis strategy may be used to replace or upgrade the corresponding data in the diagnosis strategy database 814.

[0056] Fig. 8(b) depicts an exemplary structure of a central control unit (CCU) 820 as described in embodiment 400, according to an embodiment of the present teachings. The CCU 820 comprises an internal communication unit 830 through which the CCU is capable of communicating with both one or more ECUs 810-a, 810-b, ..., 810-c via an internal network (not shown), and a communication interface 850 through which the CCU is capable of communicating with an external device via an external network (not shown). The CCU 820 further includes a diagnosis strategy database 855, where diagnosis strategies 855-a, ..., 855-b associated with the ECUs are stored, a data standard database 825, where one or more data standards 825-a, 825-b, ..., 825-c to be used to perform data conversions are stored, and a screen database 875, where different screens corresponding to different diagnosis situations are stored. The CCU 820 also includes a diagnosis control unit 860, a data collection unit 835, a component control unit 840, a data conversion unit 845, and a screen generation unit 870.

[0057] In operation, when the CCU receives input from an external device via the communication interface 850, the diagnosis control unit 860 may accordingly access diagnosis strategies from database 855 and analyze the diagnosis strategies. Based on the diagnosis strategies, the diagnosis control unit 860 may accordingly inform the data control unit 835 to collect information associated with some components in the vehicle. The diagnosis control unit 860 may also inform the component control unit 840 to control certain components to perform some operations. Upon receiving an instruction from the diagnosis control unit 860, the data collection unit 835 may issue a command, through the internal communication unit 830, to an appropriate ECU to collect information from a component that is under the control of the ECU. For example, information to be collected may be a serial number of a component, the operational parameter of a component, or a current status of a component.

[0058] The ECU may gather the requested information from the component and return the information to the data collection unit 835. In some embodiments, such collected information may be coded in a form that is not browsable. In such situations, the returned information may be forwarded to the data conversion unit 845 and transformed into a browsable form. Such transformation may be performed based on an original data standard in which the returned information is encoded and a browser data standard. Both the original data standard and the browser data standard may be retrieved from the data standard database 825. For example, the data conversion unit 845 may access both a proprietary data standard and a browser data standard from database 825. In some embodiments, the collected information in non-browsable form may also be forwarded directly from the internal communication unit 830 to the data conversion unit 845. The converted data is further forwarded to the screen generation unit 870, where appropriate screens displaying the collected information in browsable form may be generated based on diagnosis strategy information from the diagnosis control unit 860 and the collected information. Such screens are then sent to an external device via the communication interface 850. [0059] Similarly, when the component control unit 840 receives an instruction from the diagnosis control unit 860, the component control unit 840 may issue a command and send the command, through the internal communication unit 830, to an appropriate ECU to control a specific component to perform some defined operations. The ECU may subsequently control the component to perform the specified operation(s). The ECU may also receive a feedback signal from the component indicating an operational status as a return response to the operation request. Such operational status information may then be sent to the internal communication unit and forwarded either directly to the data conversion unit or relayed to the data conversion unit through the component control unit 840. The data conversion unit 870 may then transform the status information from a non-browsable form to a browsable form, which can then be used, by the screen generation unit 870, to generate screens.

[0060] The CCU 820 is configured to store, access, and utilize diagnosis strategies associated with a plurality of ECUs to perform vehicle diagnosis tasks. Fig. 9 depicts an exemplary arrangement of a CCU 950 and an information manager 920 as described in embodiment 500, according to an embodiment of the present teachings. As discussed above, the CCU as described in embodiment 500 does not store diagnosis strategies. Such a CCU may communicate with an information manager 920 that is designated to manage information to be used to facilitate vehicle diagnosis. Such information may include diagnosis strategies DS 1 930-a, ..., DS M 930-b associated with ECUl 910-a, ECU 2 910-b, ..., ECU M 910-c and/or one or. more data standards 925-a, 925-b, ..., 925-c in which data from different components or ECUs may be encoded.

[0061] In this exemplary embodiment, the information manager 920 comprises an information access controller 945, a standard information access module 935, a diagnosis strategy (DS) access module 940, a data standard database 925, and a diagnosis strategy database 930. The information manager 920 communicates with the CCU 950 through the information access controller 945 via an internal network (e.g., the internal network 550 in Fig. 5). The information manager 920 may receive a request from the CCU 950 for information. Depending on whether a request for information is for a diagnosis strategy or for a data standard, the information access controller 945 invokes either the standard information access module 935 or the DS access module 940 to retrieve the requested information. When the information access controller 945 receives the retrieved information from an appropriate information access module, it forwards the retrieved information to the CCU 950 as a response to the information request.

[0062] The exemplary CCU 950 comprises a communication interface 960 responsible for external communication (e.g., with an external device via an external network), an internal communication unit 955 responsible for communications with the, ECUs and the information manager 920, a diagnosis control unit 980, a data collection unit 965, a component control unit 970, a data conversion unit 975, and a screen generation unit 985. The diagnosis control unit 980 receives information from the communication interface 960 (e.g., instructions from an external device). As a response to the received information, the diagnosis control unit 980 may determine which diagnosis strategy is needed and obtain the diagnosis strategy, via an optional DS access unit 990, from the information manager 920. Based on the retrieved diagnosis strategy, the diagnosis control unit 980 may, according to an analysis of the diagnosis strategy, collect information from certain vehicle components or control certain vehicle components to perform certain operations.

[0063] To collect information from a vehicle component, the diagnosis control unit

980 may invoke the data collection unit 965 to communicate with an appropriate ECU that controls the vehicle component via the internal communication unit 955. Information to be collected may include a serial number of the product, version infonnation of the component, or a current operational status/information of the component. Information to be gathered may be stored in the ECU associated with the component or stored in the component. For instance, the ECU may have information related to the product such as a serial number or version number. Operational status information may be stored in the component itself, e.g., a malfunction operational status may arise and be stored in the component when a fault occurred during operation of the component.

[0064] Information to be gathered may be returned to the CCU 950 from an ECU associated with a component in question via the internal communication unit 955. The returned information may be coded according to some non-browsable encoding standard. That is, such information received may not be browsed directly and may need to be transformed to generate a browsable form of the information. This may be achieved by the data conversion unit 975. When the internal communication unit 955 receives the information from an ECU, it may, in some embodiments, send the received information to the data collection unit 965 first, which then determines whether a transformation is needed prior to forwarding the information to the data conversion unit 975 for transformation. In some embodiments, the information received by the internal communication unit may be sent directly to the data conversion unit 975 for transformation. In this case, the internal communication unit 955 may be configured to have the capability to determine when such transformation is needed.

[0065] hi order to perform data transformation, the data conversion unit 975 may access, via an optional standard access unit 995, appropriate standard(s) from the information manager 920. For example, to convert information encoded in a proprietary form to a browsable form, both the proprietary information related to how data is encoded and a browser standard (e.g., html) may be accessed and used in the transformation. Upon receiving the information collected from the component in its browsable form, the diagnosis control unit 980 may then send such information to the screen generation unit 985 that may subsequently access a screen database to determine an appropriate browsable screen to generate. Such a browsable screen is then sent, via the communication interface 960, to an external device. [0066] The diagnosis control unit 980 may also invoke, according to diagnosis strategy, an ECU to control a target component to perform a certain operation and return information (e.g., status after the operation) pertinent to the operation performed. In this case, the diagnosis control unit 980 may invoke the component control unit 970, which may subsequently generate an appropriate instruction and send the instruction to an ECU associated with the target component via the internal communication unit 955. When the ECU receives the instruction, it may then control the target component to perform the instructed operation and act^Laccordingly to receive the requested return information from the target component and forward the return information to the internal communication unit 955 as a response.

[0067] In some embodiments, when the return information is received by the internal communication unit 955, it is forwarded to the component control unit 970, which may subsequently determine whether to perform data conversion prior to forwarding the return information to the data conversion unit 975. In some embodiments, the internal communication unit 955 may be configured to have the capability to make such a determination and forward the return information directly to the data conversion unit 975. Similar to the data collection situation discussed above, the transformed return information may then be used to generate browsable screen(s) by the screen generation unit 985 and such generated screens may then be sent to an external device and be displayed in a browser on the external device.

[0068] While the invention has been described with reference to .the certain illustrated embodiments, the words that have been used herein are words of description, rather than words of limitation. Changes may be made, within the purview of the appended claims, without departing from the scope and spirit of the invention in its aspects. Although the invention has been described herein with reference to particular structures, acts, and materials, the invention is not to be limited to the particulars disclosed, but rather can be embodied in a wide variety of forms, some of which may be quite different from those of the disclosed embodiments, and extends to all equivalent structures, acts, and, materials, such as are within the scope of the appended claims.

Claims

WE CLAIM:

1. A vehicle diagnostic system, comprising:

one or more control units (CUs) of a vehicle, at least one of the CUs being configured with an Internet Protocol (D?) address and having a web server therein for communicating with a device via a first network, wherein

the at least one of the CUs exchanges information with the device in a browseable form.

2. The system according to claim 1, wherein the CUs are in communication with each other via a second network.

3. The system according to claim 2, wherein the second network is one of a wireless network, a local area network, and a combination thereof.

4. The system according to claim 1, wherein the first network is one of:

the internet;

a wireless network;

a wide area network;

a proprietary network;

a virtual private network;

a public switched telephone network; and

any combination thereof.

5. The system according to claim 1, wherein one or more CUs are associated with one or more components of the vehicle.

6. The system according to claim 5, wherein one or more CUs are configured for controlling an associated component, including obtaining information associated with the component, directing the component to perform an operation, forwarding the information of the component, or a combination thereof.

7. The system according to claim 6, wherein each of the one or more CUs:

has stored therein diagnostic strategy for the associated one or more components; and

is capable of controlling an associated component based on diagnostic strategy thereof and/or in accordance with a signal received from the device via the first network. ■

8. The system according to claim 1, wherein at least one of the CUs having stored therein the diagnostic strategy is configured for directing other CUs to control their associated one or more components based on the diagnostic strategy and/or a signal received from the device via the first network.

9. The system according to claim 1, wherein the device resides outside of the vehicle.

10. The system according to claim 9, wherein the at least one of the CUs has stored therein a diagnostic strategy capable of being used in diagnosing one or more components of the vehicle.

11. The system according to claim 1, wherein the communication between the device and the at least one of the CUs is for diagnosis of the vehicle.

12. The system according to claim 11, wherein the device is configured for:

transmitting a first signal to a CU to obtain information of an associated component and/or to instruct the CU to control a component operation;

receiving a second signal from the CU; and

displaying the second signal, where the received second signal includes information of the component or diagnostic strategy thereof, and/or information relating to the component operation.

13. A vehicle diagnostic system, comprising:

at least one control unit (CU) of a vehicle;

a central control unit (CCU) in the vehicle configured for communicating both with the at least one CU via a first network and with a device via a second network, wherein

the CCU is further configured with an Internet Protocol (IP) address and having a web server therein for communicating with the device via the second network, and

the CCU exchanges information with the device in a browseable form.

14. The system according to claim 13, wherein the CCU is further configured having diagnostic strategy stored therein. .

15. The system according to claim 13, wherein the CCU accesses diagnostic strategy to be used in diagnosing the vehicle through a data manager via the first network.

16. The system according to claim 15, wherein the diagnostic strategy is stored in the data manager.

17. The system according to claim 15, wherein the data manager retrieves the diagnostic strategy from one of a local storage and a remote storage.

.

18. The system according to claim 13, wherein each CU is associated with one or more components in the vehicle.

19. The system according to claim 18, wherein each CU is configured for controlling an associated component, including obtaining information associated with the component, directing the component to perform an operation, forwarding the information of the component, or a combination thereof.

20. The system according to claim 19, wherein each CU controls an associated component in response to a control signal received from the CCU.

21. The system according to claim 20, wherein the CCU sends the control signal based on at least one of the diagnostic strategy and/or the communication with the device.

22. The system according to claim 13, wherein the CCU is configured for:

sending a first signal to a CU;

receiving a second signal from a CU; and

transmitting the second signal to the device.

23. The system according to claim 13, wherein the first network is one of a wireless network, a local area network, and a combination thereof.

24. The system according to claim 13, wherein the second network is one of:

the internet;

a wireless network;

a wide area network;

a proprietary network;

a virtual private network;

a public switched telephone network; and

any combination thereof.

25. The system according to claim 13, wherein the device resides outside of the vehicle.

26. The system according to claim 24, wherein the device is configured for communicating with the CCU via an Internet browser interface.

27. The system according to claim 13, wherein the device is capable of performing at least one of: transmitting a first signal to the CCU to obtain information of an associated component and/or to instruct the CCU to control the component to perform an operation;

receiving a second signal from the CCU; and

displaying the second signal, where the received second signal includes information of the associated component or diagnostic strategy thereof, and/or information relating to the operation performed by the associated component.

28. A vehicle diagnostic system, comprising:

a device configured for communicating with one or more control units (CUs) of a vehicle via a first network, wherein

at least one of the CUs is configured with an Internet Protocol (EP) address and has a web server therein for communicating with the device via the first network, and

29. A vehicle diagnostic system, comprising:

a device configured for communicating with a central control unit (CCU) via a first network, wherein

the CCU communicates with at least one CU via a second network,

the CCU and the at least one CU reside within the vehicle,

the CCU is configured with an Internet Protocol (IP) address and has a web server therein for communicating with the device via the first network, and

the CCU exchanges information with the device in a browseable form.