Classifications

• • G—PHYSICS
  • G07—CHECKING-DEVICES
  • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
  • G07C5/00—Registering or indicating the working of vehicles
  • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
  • H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications

Definitions

• the disclosure relates generally to automotive systems. More specifically, the disclosure relates to methods of and systems for vehicle diagnosis.
• ECUs electronic control units
• ECUs electronic control units
• 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.
• 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.
• the personnel may then instruct, via the external device, ECUs in the vehicle to conduct further actions for diagnosis purposes.
• Fig. 1 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.
• 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.
• 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.
• 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.
• a system and methods for vehicle diagnosis are disclosed.
• 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.
• IP Internet Protocol
• the device exchanges information with such a configured CU in a browseable form.
• FIG. 1 depicts a block diagram of a conventional scheme of vehicle diagnosis
• FIG. 2 depicts an exemplary configuration for vehicle diagnosis, according to an embodiment of the present teachings
• FIG. 3 depicts an exemplary configuration for vehicle diagnosis, according to a different embodiment of the present teachings
• FIG. 4 depicts an exemplary configuration for vehicle diagnosis, according to another embodiment of the present teachings.
• FIG. 5 depicts an exemplary configuration for vehicle diagnosis, according to another different embodiment of the present teachings.
• 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
• Fig. 7(a) shows a protocol hierarchy 700 in a master ECU, according to an embodiment of the present teaching
• 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
• FIG. 7(c) shows another exemplary arrangement, according to an embodiment of the present teaching
• FIG. 8(a) depicts an exemplary internal structure of an electronic control unit
• 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.
• Fig. 2 depicts an exemplary configuration 200 for vehicle diagnosis, according to an embodiment of the present teachings.
• 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.
• 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.
• the ECU 1 260-a stores a plurality of diagnosis strategies 270-a, 270-b, ..., 270-c.
• diagnosis strategy 270-a 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).
• diagnosis strategy 270-b may be for ECU 260-b, ...
• diagnosis strategy 270-c may be for ECU 260-c.
• Each ECU may be used for controlling a part of the vehicle 250 and each such part may include one or more components.
• 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.
• 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.
• 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.
• 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).
• the diagnosis strategy for an ECU may or may not be stored in that ECU.
• the ECU that stores diagnosis strategies for other ECUs e.g., as a master ECU
• 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.
• the master ECU may communicate, on behalf of the slave ECU 5 with the external device 210 via the network 220.
• 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.
• 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.
• 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.
• 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.
• communication among ECUs within the vehicle may comply with some proprietary format or some standard other than a browser standard.
• 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.
• communication among ECUs internal to the vehicle may comply with the browser standard. In this case, no transformation may be needed.
• 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.
• an ECU e.g., a master ECU
• 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.
• 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.
• the master ECU acts according to the diagnosis strategy for its own part.
• each of the plurality of ECUs, 360-a, 360-b, ..., 360-c, within a vehicle 350 stores a corresponding diagnosis strategy.
• 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.
• 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.
• each ECU in embodiment 300 is capable of accessing the diagnosis strategy stored therein and acting accordingly to carry out diagnosis tasks.
• 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.
• 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.
• Fig. 4 depicts an exemplary configuration 400 for vehicle diagnosis, according to another embodiment of the present teachings.
• 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.
• 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.
• the CCU 450 is not an ECU or is not capable of controlling a component in the vehicle for diagnosis purposes.
• communication between ECUs and CCU 450 complies with browser standard.
• 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.
• ECUs operate on information in a non-browsable form.
• CCU 450 is configured to be able to interpret both non-browsable information and browsable information and perform necessary transformations between the two.
• the arrangement, as shown in Fig. 4, of having a separate CCU 450 may facilitate easier reconfiguration or upgrade of diagnosis strategies.
• the CCU 450 with diagnosis strategies stored therein may be implemented independent of the ECUs as a plug-in to the vehicle 430.
• Fig. 5 depicts an exemplary configuration 500 for vehicle diagnosis, according to another different embodiment of the present teachings.
• 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.
• 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.
• the information manager 570 with diagnosis strategies stored therein may be implemented as a plug-in to the vehicle 530.
• 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).
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• parts suppliers e.g., suppliers 625, ..., 635
• 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).
• 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.
• a wide area network such as the Internet.
• the repair shop may communicate with the manufacturer web service 645 via a wide area network such as the Internet.
• multiple parties residing possibly at different locations may or may not share a common browser or a browser-like environment.
• different grouping of such parties may share a same browser or a browser-like interface.
• all sharing parties may see the same information displayed in a browser.
• no common interface may be shared, multiple parties may use other means to exchange information needed.
• 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.
• 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.
• 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.
• vehicle components may be grouped into different networks, each of which may adopt a different protocol.
• the second hierarchy may include an engine network, a transmission network, a sensor and control network, a dashboard network, etc.
• 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.
• 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.
• 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.
• PDU protocol data unit
• 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.
• 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.
• DHCP Dynamic Host Configuration Protocol
• 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.
• a master ECU may serve as a host for the in-vehicle network, because the nodes themselves may not run protocol stacks.
• 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.
• 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.
• 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.
• Fig. 7(c) shows another exemplary arrangement, according to an embodiment of the present teaching.
• 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.
• 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.
• the diagnostic system may have diagnosis strategies stored therein.
• 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.
• 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.
• 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.
• 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.
• a diagnosis strategy database 814 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.
• DS diagnosis strategy
• 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.
• 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.
• 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.
• 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.
• the invoked unit i.e., 808-a or 808-b
• the invoked unit 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).
• the invoked unit may then send a control signal 816 through the second communication unit 815 directly to its associated component.
• 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.
• the generated screen configuration is determined from the screen database
• 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.
• 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.
• 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).
• 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.
• 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.
• 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.
• the ECU may gather the requested information from the component and return the information to the data collection unit 835.
• collected information may be coded in a form that is not browsable.
• 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.
• the data conversion unit 845 may access both a proprietary data standard and a browser data standard from database 825.
• 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.
• 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.
• 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.
• 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.
• 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.
• the information access controller 945 invokes either the standard information access module 935 or the DS access module 940 to retrieve the requested information.
• 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.
• 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.
• the diagnosis control unit To collect information from a vehicle component, the diagnosis control unit
• 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.
• 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.
• 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.
• the internal communication unit 955 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.
• the information received by the internal communication unit may be sent directly to the data conversion unit 975 for transformation.
• the internal communication unit 955 may be configured to have the capability to determine when such transformation is needed.
• 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.
• 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.
• 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.
• 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.
• the ECU may then control the target component to perform the instructed operation and act L accordingly to receive the requested return information from the target component and forward the return information to the internal communication unit 955 as a response.
• the return information 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.
• 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.

Landscapes

• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Small-Scale Networks (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=38196550

Family Applications (1)

Country Status (2)

Families Citing this family (7)

Citations (1)

Family Cites Families (5)

• 2007
  • 2007-03-01 EP EP07751969A patent/EP2002402A1/de not_active Ceased
  • 2007-03-01 WO PCT/US2007/005239 patent/WO2007117370A1/en not_active Ceased

Patent Citations (1)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events