Distributed diagnostic architecture for vehicles

Abstract

The present disclosure relates to a distributed diagnostic architecture for a vehicle. The diagnostic architecture includes multiple application functions hosted on a vehicle central computing platform (CCP), multiple remote input / output concentrator modules (RIOs) provided at various locations within the vehicle, and a vehicle diagnostic manager (VDM). The application functions are configured to control the vehicle functions. The application functions are further configured to perform diagnostic fault monitoring for strategic or system-level faults of the associated vehicle functions and to send strategic fault data related to the associated vehicle functions to the VDM. The RIOs are connected to I / O devices in the vehicle. The RIOs are configured to perform diagnostic fault monitoring for physical-level or component-level faults of the associated I / O devices and to send physical fault data related to the associated I / O devices to the VDM. The VDM is configured to aggregate the received strategic and physical fault data and maintain a central fault record of the strategic and physical faults.

Description

[Technical field]

[0001] Aspects of the present disclosure relate to a distributed diagnostic system for a vehicle, particularly, but not exclusively, a distributed diagnostic system for a vehicle such as an automobile. Aspects of the present disclosure relate to a diagnostic architecture and a vehicle including the diagnostic architecture. [Background technology]

[0002] Modern vehicles, such as automobiles, typically include multiple application functions for controlling various functions of the vehicle. For example, within the vehicle's body domain, a seat application function may be provided for controlling the operation of the vehicle's seats, and a door application function may be provided for controlling the operation of the vehicle's doors.

[0003] In a traditional electronic architecture, the various application functions of a vehicle are hosted in many separate electronic control units (ECUs) distributed throughout the vehicle, with each ECU also hosting drivers for input / output (I / O) devices related to a particular application function. For example, continuing with the body domain example, a vehicle may include left front, right front, left rear, and right rear seat ECUs (each hosting seat application functions and I / O drivers for a respective seat in the vehicle), and left front, right front, left rear, and right rear door ECUs (each hosting door application functions and I / O drivers for a respective door in the vehicle).

[0004] Using this traditional electrical architecture, faults are relatively easy to identify, triage, and log because ECUs distributed throughout the vehicle host both application functions and drivers for I / O devices such as sensors and actuators associated with those application functions. Thus, ECUs can perform diagnostic tests or fault monitors related to both physical or component-level faults (failures related to I / O devices and the vehicle's communication channels) and strategic or system-level faults (higher level faults related to the availability, performance, or health of the vehicle's application functions). This failure data can then be used to detect physical and strategic faults, which can be triaged to classify the detected faults as either causal faults (i.e., root cause faults that require direct remedial action) or consequential faults (i.e., faults that are caused or detected as a result of a root cause failure and may not require direct remedial action).

[0005] The electrical architecture described above results in a vehicle requiring a large number of separate ECUs and a complex wiring harness. To reduce the number of ECUs and the complexity of the vehicle's wiring harness, it may be desirable to move at least some of the vehicle's application functions from the dedicated ECUs to a central function hosting system or central computing platform that can, for example, control a variety of different functions for various subsystems of the vehicle. Moving the vehicle's application functions away from the dedicated ECUs is referred to as functional partitioning. In this case, drivers for I / O devices may still be distributed throughout the vehicle. For example, I / O drivers may be hosted on multiple remote input / output concentrator modules or RIOs, each of which may host and facilitate communication with drivers for I / O devices for multiple different subsystems. Summary of the Invention [Problem to be solved by the invention]

[0006] However, moving application functions from the ECUs where the drivers for the I / O devices associated with those application functions are hosted creates challenges in identifying, triaging, and recording failures. In particular, because the application functions are separated from the hardware where the I / O drivers reside, neither the application functions nor the RIO have access to all the physical and strategic failure data required to effectively triage detected failures in order to identify cause and effect failures.

[0007] The present invention has been devised to alleviate or overcome at least some of the problems set forth above. [Means for solving the problem]

[0008] According to one aspect of the present invention, there is provided a distributed diagnostic architecture for a vehicle, the diagnostic architecture comprising a plurality of application functions hosted on a central compute platform (CCP) of a vehicle, a plurality of remote input / output concentrator modules (RIOs) installed at different locations in the vehicle, and a vehicle diagnostics manager (VDM), each application function configured to control an associated function of the vehicle, perform diagnostic fault monitoring for strategic or system level faults of the associated vehicle function, and periodically transmit output of the strategic fault monitor to the VDM, each RIO is connected to one or more associated I / O devices of the vehicle, and is configured to perform diagnostic fault monitoring for physical or component level faults of the associated I / O devices, and periodically transmit output of the physical fault monitor to the VDM, the VDM being configured to aggregate received fault monitor output data, detect strategic and physical faults in response to the received fault monitor output data, and maintain a central fault record of strategic and physical faults.

[0009] A CCP is understood to be a central computing system comprised of at least one processor module and at least one memory module used to host software applications or application functions for controlling the operation of various different vehicle subsystems. A VDM and central fault record may also be hosted on the CCP along with the application functions. A RIO is also understood to be a control module connected and configured to facilitate communication with I / O devices of one or more vehicle subsystems, including I / O devices associated with application functions hosted on the CCP.

[0010] It will also be appreciated that the outputs of the tactical and physical fault monitors are raw fault monitor output data, for example in the form of pass / fail data indicating whether a particular fault condition has been detected, which is in contrast to a confirmed diagnostic trouble code (DTC) that may then be generated in response to the outputs of the tactical and physical fault monitors.

[0011] The period at which the outputs of the tactical and physical fault monitors are sent from the application functions and RIOs to the VDM can be based on the periodicity of the individual fault monitors, for example, pass / fail data can be sent from the application functions and RIOs to the VDM upon generation or after a predetermined number of fault monitoring cycles.

[0012] The diagnostic architecture is distributed because the application functions that control the vehicle's functions and generate strategic fault data are separated from the RIOs that interface with the vehicle's I / O devices and generate physical fault data. However, by configuring the VDM to receive strategic fault data from the application functions and physical fault data from the RIOs, the diagnostic architecture of the present invention allows the VDM to aggregate all the fault data necessary to detect and triage physical and strategic faults and maintain a record of faults for the entire vehicle.

[0013] Additionally, by sending all pass / fail data related to strategic and physical failures to the VDM, the level of failure data available to the VDM can be maximized. Thus, the VDM can detect degraded states of components and vehicle functions and even predict the occurrence of a specific failure before a DTC is generated for that failure. The VDM can also triage, classify, and record failures before a DTC is generated for all failures related to a specific cause failure.

[0014] In this manner, the diagnostic architecture of the present invention enables efficient detection and recording of faults in a vehicle, with at least some application functionality being hosted on a central computing platform.

[0015] The VDM can be configured to generate DTCs for detected strategic and physical faults in response to the received fault monitor output data and store the generated DTCs in a central fault record. Generating confirmed DTCs in the VDM allows the application functions and RIOs to omit the fault qualification logic required to generate confirmed DTCs, reducing the complexity of the application functions and RIOs.

[0016] The VDM can be configured to triage detected strategic and physical failures to classify the detected failures as either causal or consequential failures. By identifying detected failures as either causal or consequential failures, unnecessary reporting of consequential failures that do not require their own separate remedial action can be avoided, thereby simplifying the process of identifying root causes and appropriate remedial actions following detection of multiple failures.

[0017] Triaging the detected faults may include triaging the fault monitor output data received from the application functions and the RIO to classify the detected faults as either causal or consequential faults. Triaging the detected faults based on the received fault monitor output data allows the VDM to triage the faults and identify the causal faults before DTCs are generated for all faults associated with a particular causal fault. Additionally, because the fault monitor output data received from the application functions and the RIO contains more information than subsequently generated DTCs, triaging the faults based on the raw fault monitor output data allows for more detailed and accurate triage of the faults than would be possible based solely on DTCs.

[0018] The central fault record can be maintained in a central fault memory system associated with the VDM. The central fault memory system can include a primary fault memory and a user-defined secondary fault memory. The VDM can be configured to store a record of the causal fault in the primary fault memory and a record of the consequence fault in the user-defined secondary fault memory. The primary fault memory is understood to be a digital storage configured to be accessed by a diagnostic client (e.g., an on-board or off-board tester) connected to the vehicle's diagnostic system using a standard diagnostic protocol interface (e.g., the Unified Diagnostics Services (UDS) protocol interface defined by ISO (International Organization for Standardization)). In contrast, the user-defined secondary fault memory is a digital storage configured to be accessible only by manufacturer-approved diagnostic clients or only upon receipt of a specific request defined by the vehicle's manufacturer.

[0019] By storing a record of causal faults in a primary fault memory and a record of consequence faults in a user-defined secondary fault memory, a complete record of all detected faults is maintained (and accessible to the vehicle manufacturer), while ensuring that causal faults are only reported when diagnostic data is requested by a diagnostic client using the standard UDS protocol interface.

[0020] The central fault memory system may also be hosted on the CCP along with the application functions and the VDM.

[0021] The RIO and application functions can be configured to detect physical and strategic faults, determine an appropriate fault response upon detection of a physical or strategic fault, and initiate the determined fault response. In this manner, the RIO and application functions can initiate an appropriate fault response in response to detected physical and strategic faults, independent of the VDM, and without waiting for confirmed DTCs to be generated in association with those faults.

[0022] In this case, the RIOs and application functions may be provided with fault detection logic to distinguish between physical and strategic faults and to determine appropriate fault responses, however, because the VDM contains the fault qualification logic necessary to generate confirmed DTCs and is configured to maintain a central fault record of strategic and physical faults, it is not necessary to provide individual RIOs and application functions with the DTC qualification logic necessary to generate confirmed DTCs.

[0023] The VDM can be configured to maintain a keep alive interface with the RIO, and the RIO can be configured to begin maintaining a local fault record of the physical fault upon detecting an interruption of the keep alive interface. Because physical fault data is typically recorded in a central fault record maintained by the VDM, the RIO need not maintain a local fault record of the physical fault as long as the keep alive interface is validly received. However, initiating maintenance of a local fault record of the physical fault in response to an interruption of the keep alive interface can ensure that a record of the physical fault is maintained even if communication between the RIO and the VDM is interrupted, for example, due to a fault in the vehicle's wire harness.

[0024] Local fault records are preferably maintained in a user-defined secondary fault memory in the individual RIO, rather than in a primary fault memory. Local fault records may include the output of a physical fault monitor, since the RIO does not have the DTC qualification logic required to generate a confirmed DTC.

[0025] According to another aspect of the present invention, there is provided a distributed diagnostic architecture for a vehicle, the diagnostic architecture comprising a plurality of application functions hosted on a Central Computing Platform (CCP) of a vehicle, a plurality of Remote Input / Output Concentrator Modules (RIOs) installed at different locations within the vehicle, and a Vehicle Diagnostic Manager (VDM), each application function configured to control an associated function of the vehicle, perform diagnostic fault monitoring, detect strategic or system level faults of the associated vehicle function, and report detected strategic faults to the VDM, each RIO connected to one or more associated I / O devices of the vehicle and configured to perform diagnostic fault monitoring, detect physical or component level faults of the associated I / O devices, and report detected physical faults to the VDM, the VDM configured to aggregate received notifications of strategic and physical faults and maintain a central fault record of the strategic and physical faults.

[0026] The VDM and central fault record may be hosted at the CCP along with the application functions.

[0027] By configuring the VDM to receive failure notifications of detected strategic and physical failures from the application functions and the RIO, the diagnostic architecture of the present invention allows the VDM to aggregate all the necessary failure data to triage physical and strategic failures and maintain a record of failures throughout the vehicle. Furthermore, by only forwarding confirmed failure notifications from the application functions and the RIO to the VDM, signal traffic over the vehicle's communication network can be minimized. In this manner, the diagnostic architecture of the present invention allows for efficient detection and recording of failures in vehicles where at least some application functions are hosted on a central computing platform.

[0028] The application functions and RIOs can be configured to generate DTCs for detected strategic and physical faults and to send the generated DTCs to the VDM for storage in a central fault record. By generating DTCs in the application functions and RIOs and reporting the generated DTCs to the VDM, the VDM does not need access to the output information of the individual fault monitors (based on which the DTCs are generated), thereby reducing the amount of communication required between the application functions and RIOs and the VDM.

[0029] Application functions and the RIO can be configured to report detected faults to the VDM using an event-driven communication interface. Faults can be reported to the VDM upon confirmation, for example, in response to a change in the DTC status byte.

[0030] The RIO may be configured to maintain a fault record for physical faults and the application function may be configured to maintain a fault record for strategic faults. For the avoidance of doubt, it is understood that the RIO may maintain a physical fault record continuously, as well as in response to interruptions in communication with the VDM. The physical and strategic fault records maintained by the RIO and application function may include DTCs and / or fault monitor output information (e.g., pass / fail information) from individual fault monitors executed by the RIO and application function.

[0031] A record of the physical failure may be maintained in a user-defined secondary failure memory of the RIO, and a record of the strategic failure may be maintained in a user-defined secondary failure memory associated with the application function. Storing records of the physical and strategic failures in user-defined secondary failure memories associated with the RIO and the application can facilitate retrospective failure analysis.

[0032] The VDM can be configured to triage the detected strategic and physical faults to classify the detected faults as either cause or effect faults. Because DTCs for strategic and physical faults are generated and sent to the VDM by the application functions and the RIO, triaging the detected faults may include triaging DTCs received from the application functions and the RIO, in which case the VDM may not require access to the raw output of the fault monitors executed by the application functions and the RIO.

[0033] The central failure record may be maintained in a central failure memory system associated with the VDM. The central failure memory system may include a primary failure memory and a user-defined secondary failure memory. The VDM may be configured to store records of causal failures in the primary failure memory and to store records of consequence failures in the user-defined secondary failure memory.

[0034] The RIO and application functions can be configured to determine an appropriate fault response upon detection of a physical or strategic fault and to initiate the determined fault response.

[0035] According to a further aspect of the present invention, there is provided a distributed diagnostic architecture for a vehicle. The diagnostic architecture includes a plurality of application functions, each configured to control a vehicle function. At least some of the application functions may be hosted on a Central Computing Platform (CCP) of the vehicle. Alternatively, or in addition, at least some of the application functions may be hosted on one or more Remote Input / Output Concentrator Modules (RIOs) or Electronic Control Units (ECUs). I / O drivers of the application functions may be hosted on the RIOs or ECUs.

[0036] The application function can be configured to perform diagnostic fault monitoring related to strategic or system level faults of the associated vehicle function and to transmit strategic fault data related to the associated vehicle function to a Vehicle Diagnostic Manager (VDM). The strategic fault data can be transmitted in the form of pass / fail data or confirmed diagnostic trouble codes (DTCs). The strategic fault data can be transmitted as it is generated or continuously using an event driver interface.

[0037] The RIO or ECU can be configured to perform diagnostic fault monitoring for physical or component level failures of associated I / O devices and send physical fault data associated with the associated I / O devices to the VDM. The physical fault data can be sent in the form of pass / fail data or acknowledged DTCs. The physical fault data can be sent as it is generated or continuously using the event driver interface.

[0038] The VDM can be configured to aggregate the received tactical and physical failure data and maintain a central failure record of tactical and physical failures. In particular, the VDM can be configured to triage detected failures and manage cause failure records and effect failure records.

[0039] Within the scope of this application, it is expressly intended that the various aspects, embodiments, examples and alternatives described in the preceding paragraphs, claims, and / or the following description and drawings, in particular their individual features, may be applied independently or in any combination. That is, all embodiments and / or features of any embodiment may be combined in any manner and / or combination, except where such features are incompatible. The applicants reserve the right to modify the originally filed claims or to submit new claims accordingly (including the right to amend the originally filed claims to depend on and / or incorporate features of other claims, even if not in the original claims).

[0040] One or more embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings. [Brief description of the drawings]

[0041] [Figure 1] FIG. 1 shows a schematic diagram of a road vehicle including a distributed diagnostic system according to one possible embodiment of the invention. [Diagram 2] FIG. 2 illustrates a schematic of a selection of vehicle subsystems. [Diagram 3] FIG. 3 shows a schematic of a portion of a vehicle diagnostic system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0042] Figure 1 illustrates diagrammatically a road vehicle 1 including a distributed diagnostic system 2 according to one possible embodiment of the present invention. As is typical in modern road vehicles, the vehicle 1 illustrated in Figure 1 is comprised of a number of subsystems 3 configured to implement a variety of different vehicle functions, some of which are illustrated in Figure 2. The vehicle's subsystems 3 include, for example, a left front seat 3a, a right front seat 3b, a left rear seat 3c, a right rear seat 3d, a left front door 3e, a right front door 3f, a left rear door 3g, a right rear door 3h, a windshield wiper system 3i, a lighting system 3j, and an alarm system 3k (among many other subsystems not illustrated in Figure 2).

[0043] Each subsystem 3 includes various I / O devices 5, such as sensors and actuators, required to implement vehicle functions, some of which are shown in Fig. 3. For example, each seat subsystem 3a, 3b, 3c, 3d includes (among other sensors and actuators not shown in Fig. 3) a height control motor 5a configured to adjust the seat height, a height position sensor 5b configured to monitor the seat height, a headrest control motor 5c configured to adjust the position of the headrest, and a headrest position sensor 5d configured to monitor the position of the headrest. Additionally, each door subsystem 3e, 3f, 3g, 3h includes (among other sensors and actuators not shown in Fig. 3) a window control motor 5e and a window position sensor 5f, and the front door subsystems 3e, 3f include a mirror control motor 5g and a mirror position sensor 5h, respectively.

[0044] The vehicle 1 includes several software applications or application functions 10 configured to control the operation of various subsystems 3 of the vehicle to implement the functions of the vehicle 1, some of which are shown in FIG. 3. For example, the vehicle 1 includes a seat application function group including a seat control function 10a for controlling the height of each seat using a height control motor, and a seat comfort function 10b for controlling the headrest position of each seat using a headrest control motor. Furthermore, the vehicle 1 includes a door application function group including a window control function 10c for controlling the position of each door window using a window control motor, and a mirror control function 10d for controlling the position of the left and right front door mirrors using a mirror control motor. The vehicle 1 also includes (among many other application functions not shown in FIG. 3) a wiper control function 10e for controlling a windshield wiper system 3i, a lighting control 10f function for controlling a lighting system 3j, and an alarm function 10g for controlling an alarm system 3k.

[0045] In a traditional electrical architecture, each seat and each door of a vehicle would require one or more local ECUs to control vehicle functions such as adjusting seat height or opening and closing windows, with each ECU hosting one or more location-specific application functions and I / O drivers for sensors and actuators related to the locally hosted application functions. For example, the left front seat 3a might include a left front seat ECU that hosts the sensors and actuator drivers for the left front seat along with seat control and seat comfort functions for the left front seat. Similar ECUs would be required for the remaining seats and each door.

[0046] However, in the electrical architecture shown in FIG. 3, application functions 10 for controlling vehicle functions relating to the seats 3a-d, doors 3e-h, wiper system 3i, lighting system 3j and alarm system 3k are moved from the local ECUs to a central function hosting system or central computing platform (CCP) 15, thereby eliminating the need to provide a separate ECU for each seat and each door of the vehicle 1.

[0047] Because the application functions 10 are centrally hosted on the CCP 15, each application function 10 is able to control its particular function for multiple subsystems located in different zones of the vehicle 1, thereby reducing the number of application functions 10 required in the vehicle 1. For example, a single seat control function 10a hosted on the CCP 15 can control the height of each seat 3a-d in the vehicle 1, and a single window control function 10c hosted on the CCP 15 can control the window position of each door 3e-h in the vehicle 1.

[0048] It will be understood that vehicle 1 includes numerous other application functions in addition to those shown in Figure 3. Some of these additional application functions may be hosted on CCP 15. However, other application functions may be hosted in a variety of locations, such as, for example, a conventional ECU or a remote input / output concentrator module (RIO) (described in more detail below).

[0049] 3, CCP 15 also hosts a Vehicle Diagnostic Manager (VDM) 20, which provides various vehicle diagnostic monitoring services for vehicle 1. In particular, VDM 20 is configured to create, store and manage a central, vehicle-wide record of detected faults and to report detected faults to diagnostic clients, such as on-board and off-board testers, in a central fault memory system 21 also located at CCP 15, as described in more detail below.

[0050] As mentioned above, the application functions 10a-d for controlling vehicle functions associated with the seats and doors are centrally hosted on the CCP 15 of the vehicle 1. However, the I / O devices required to implement these vehicle functions (i.e. the sensors and actuators 5a-h associated with the vehicle seats 3a-d and vehicle doors 3e-h) require local controllers that are closer to the I / O devices than the CCP 15. For this reason, the vehicle is equipped with four remote input / output concentrator devices (RIOs) 30, one for each major zone of the vehicle, as shown in Figure 3, each of which hosts and facilitates communication with drivers 31 for the I / O devices 5 associated with multiple different application functions 10.

[0051] In particular, vehicle 1 includes a left front RIO 30a that hosts and communicates with drivers for sensors and actuators for left front seat 3a and left front door 3e, a right front RIO 30b that hosts and communicates with drivers for sensors and actuators for right front seat 3b and right front door 3f, a left rear RIO 30c that hosts and communicates with drivers for sensors and actuators for left rear seat 3c and left rear door 3g, and a right rear RIO 30d that hosts and communicates with drivers for sensors and actuators for right rear seat 3d and right rear door 3h. Drivers for I / O devices for wiper system 3i, lighting system 3j, and alarm system 3k may also be hosted on one or more of the RIOs 30 described above.

[0052] It will be understood that vehicle 1 may also include various other RIOs 30 and / or local ECUs, in addition to the four RIOs shown in FIG. 3, which may host and communicate with drivers for other I / O devices not shown in FIG. 3.

[0053] The RIOs 30 are connected to their respective I / O devices 5 via CAN or LIN links. The RIOs 30 are also connected to the CCP 15 via a vehicle backbone link or wiring harness 40. The backbone link or wiring harness 40 may provide, for example, an Ethernet or FlexRay link between the RIOs 30 and the CCP 15. Through the backbone link or wiring harness 40, the RIOs 30 may communicate with the application functions 10, for example, to receive command signals from the application functions 10 and to send output data from their associated I / O devices 5 to the application functions 10.

[0054] 3, in addition to the I / O and COM drivers 31, each RIO 30 includes a diagnostic server 32. The diagnostic server 32 of each RIO 30 is configured to perform diagnostic tests or fault monitors for physical faults, which are faults associated with the I / O device 5 and the communication channel associated with that RIO 30. In particular, the diagnostic server 32 of a RIO 30 includes device driver level fault debounce logic configured to generate pass / fail data for specific physical faults. The physical pass / fail data can be generated, for example, by comparing actuator currents and sensor outputs to device specific threshold levels.

[0055] For example, the diagnostic server 32 of the left front RIO 30a may be configured to compare the motor circuit current of the height control motor 5a of the left front seat 3a to a low threshold level to check for an open circuit fault condition and to a high threshold level to check for a short circuit fault condition. As long as the motor circuit current is between the low and high thresholds, both the open circuit fault monitor and the short circuit fault monitor will generate pass data. However, if the motor circuit current falls below the lower threshold, the open circuit fault monitor will generate fail data. Similarly, if the motor circuit current exceeds the high threshold, the short circuit fault monitor will generate fail data.

[0056] Additionally, RIO 30 includes basic fault detection logic configured to detect a physical fault, for example, when fault data is generated by a particular physical fault monitor for a predefined period or number of monitoring cycles. RIO 30 is also configured to determine and initiate an appropriate fault response upon detection of a physical fault, for example, disabling an associated driver 31 until the fault is repaired. However, RIO 30 does not require DTC qualification logic to generate confirmed physical DTCs because RIO 30 is not required to generate confirmed DTCs for physical faults of associated I / O devices 5 and communication channels.

[0057] The RIO 30 is configured to transmit all pass / fail data generated by the physical fault monitors to the VDM 20 via the vehicle backbone link or wire harness 40. For example, if the motor circuit current of the height control motor 5a of the left front seat 3a is between a low threshold and a high threshold, pass data is transmitted from the left front RIO 30a to the VDM for both the open circuit fault monitor and the short circuit fault monitor. However, if the motor circuit current falls below the low threshold, fault data is transmitted to the VDM for the open circuit fault monitor; if the motor circuit current exceeds the high threshold, fault data is transmitted to the VDM for the short circuit fault monitor.

[0058] 3, the CCP 15 also includes a diagnostic server 24. Each of the application functions 10 hosted on the CCP 15 is configured to run diagnostic tests or fault monitors for strategic faults (high-level faults related to the availability, performance, or health of the application function) using the common diagnostic server 24. In other embodiments, each application function 10 or group of application functions may have its own dedicated diagnostic server for running its respective strategic fault monitors.

[0059] The diagnostic server or servers 24 of the application functions 10 include application function level fault debounce logic configured to generate pass / fail data for certain strategic faults. The strategic pass / fail data may be generated depending on, for example, the availability and / or reliability of signals received from the RIO 30 and / or other application functions. For example, the diagnostic server 24 may execute a front left seat position control fault monitor configured to generate pass data while the height control motor 5a and height position sensor 5b of the left front seat 3a are functioning properly, and generate fail data if data from the height control motor 5a or height position sensor 5b is unavailable or unreliable.

[0060] Additionally, the application function 10 includes basic fault detection logic configured to detect strategic faults, for example, when fault data is generated by a particular strategic fault monitor over a predefined period or number of monitoring cycles. Application function 10 is also configured to determine and initiate an appropriate fault response upon detection of a strategic fault, such as disabling a particular vehicle function, but does not require DTC qualification logic to generate a confirmed physical DTC, because application function 10 is not required to generate a confirmed DTC for a strategic fault of the associated vehicle function.

[0061] The application function 10 is also configured to transmit all pass / fail data generated by the strategic fault monitors to the VDM 20 via the service bus 25 of the CCP 15 .

[0062] The frequency of communication of the physical pass / fail data from the RIOs 30 and the strategic pass / fail data from the application functions 10 to the VDM 20 is based on the periodicity of the individual fault monitors. For example, the RIOs 30 and application functions 10 may each be configured to transmit pass / fail data as it is generated. In some cases, pass / fail data may be transmitted every 100 ms, although other communication frequencies are possible and different communication frequencies may be used by different RIOs 30 and application functions 10.

[0063] The VDM 20 is configured to aggregate and triage strategic and physical pass / fail data received from the application functions 10 and the RIO 30 in order to detect strategic and physical failures and classify the detected failures as either causal failures (root cause failures that require direct remedial action) or consequential failures (failures that are caused or detected as a result of a root cause failure and may not require direct remedial action). The VDM 20 is further configured to maintain a record of causal failures in a primary fault memory portion 22 of the central fault memory system 21 (from which the fault data is available to any diagnostic client connected to the vehicle's diagnostic system 2 using a standard UDS protocol interface) and to maintain a record of consequential failures in a user-defined secondary fault memory portion 23 of the central fault memory system 21 (which is only available upon receipt of a manufacturer-defined request).

[0064] For example, in the above case where the height control motor 5a of the left front seat 3a fails, the VDM 20 may receive strategic pass / fail data from the seat control application function 10a indicating that height adjustment is unavailable for the left front seat 3a along with physical pass / fail data from the left front RIO 30a indicating that the height control motor 5a of the left front seat 3a has failed. In this case, the VDM 20 may be able to triage these two detected failures and determine that the root cause of the multiple detected failures is the failure of the height control motor 5a of the left front seat 3a. In this case, the failure of the height control motor 5a is recorded in the primary fault memory 22 of the central fault memory system 21, while the unavailable height adjustment of the left front seat 3a is recorded in the user-defined secondary fault memory 23 of the central fault memory system 21.

[0065] The above example is a very simple example involving only a single cause failure and a single effect failure, however, it will be appreciated that larger groups of related failures involving multiple root cause failures and / or multiple associated effect failures may also be triaged in a similar manner.

[0066] The VDM 20 also includes DTC qualification logic configured to generate confirmed DTCs along with snapshot and extended data record information of detected strategic and physical faults in parallel with the above-mentioned triage process, dependent on strategic and physical pass / fail information received from the application function 10 and the RIO 30. The VDM 20 is further configured to store the generated DTCs along with status byte data confirming the state of the DTC and associated snapshot and extended data record information in either the cause fault record 22 or the result fault record 23 (depending on the outcome of the above-mentioned triage process).

[0067] Once one or more DTCs have been recorded in the central fault memory system 21, the VDM 20 can make the recorded DTCs available to diagnostic clients, such as on-board and off-board testers. For example, if a diagnostic client, such as a third-party off-board or on-board tester 26, is connected to the diagnostic system 2 of the vehicle 1 using a standard UDS protocol interface, the VDM 20 will report the causal fault record, including the DTCs for all causal faults, to the diagnostic client. However, the resulting fault record will not be reported unless a manufacturer-defined request is received by the VDM 20.

[0068] It is generally not necessary for the RIO 30 to maintain a local record of physical faults, since the VDM 20 can maintain a record of both strategic and physical faults during normal operation of the vehicle 1. However, to ensure that a complete record of physical faults is maintained, the RIO 30 is configured to record physical fault data in the event that communication between the RIO 30 and the VDM 20 is interrupted (e.g., due to a failure of the vehicle's wiring harness 40).

[0069] In particular, the VDM 20 is configured to maintain a keep alive interface with the RIO 30 via the vehicle's wire harness 40. As long as the keep alive information is validly received by the RIO 30, the RIO 30 is configured to transmit pass / fail data generated by the physical fault monitors to the VDM 20 without maintaining a local record of the physical fault. However, upon detecting an interruption in the keep alive interface, the RIO 30 is configured to begin maintaining a local physical fault record in a user-defined secondary fault memory 33 associated with the individual RIO 30. Because the RIO 30 does not have the fault qualification logic necessary to generate a confirmed DTC, the local fault record may only record the pass / fail results of the physical fault monitors.

[0070] Because the VDM 20 is configured to receive failure data regarding strategic failures from the application function 10 and failure data regarding physical failures from the RIO 30, the diagnostic architecture of the present invention enables the VDM 20 to aggregate all the failure data necessary to detect and triage physical and strategic failures and maintain a record of failures for the entire vehicle.

[0071] Additionally, because the VDM 20 has access to all pass / fail data generated by the tactical and physical fault monitors in the above embodiments, the VDM 20 can detect degraded conditions of components and vehicle functions, predict the occurrence of certain faults, and triage faults before DTCs are generated for those faults. However, transmitting all pass / fail data generated by the tactical and physical fault monitors to the VDM 20 would generate high signal traffic on the CCP's service bus 25 and the vehicle's wire harness 40. Thus, in alternative embodiments of the present invention described below, the frequency of communication of fault data to the VDM 20 is reduced.

[0072] An alternative embodiment employs a similar system architecture as described above and is illustrated in Figures 2 and 3. In particular, the alternative diagnostic system includes a similar arrangement of application functions 10 hosted on a CCP 15 configured to control the operation of various subsystems 3, including, among others, a left front seat 3a, a right front seat 3b, a left rear seat 3c, a right rear seat 3d, a left front door 3e, a right front door 3f, a left rear door 3g, and a right rear door 3h of the vehicle. Additionally, the alternative diagnostic system also includes a similar arrangement of remote input / output concentrator devices (RIOs) 30a, 30b, 30c, 30d that host drivers 31 for and facilitate communication with I / O devices 5 associated with the above subsystems 3. Additionally, the alternative diagnostic system also includes a similar Vehicle Diagnostic Manager (VDM 20) hosted on the CCP 15 (which is configured to create, store and manage a central vehicle-wide record of detected faults in a Central Fault Memory System 21 also located on the CCP).

[0073] As in the first embodiment described, application function 10 and RIO 30 are configured to execute tactical and physical fault monitors to detect tactical and physical faults in associated vehicle functions, I / O devices, and communication channels, respectively, and to determine and initiate appropriate fault responses independent of VDM 20. However, the manner in which fault data is communicated from application function 10 and RIO 30 to VDM 20 differs, as will be explained in more detail below.

[0074] In particular, in this alternative embodiment, the application functions 10 each include fault qualification logic for generating confirmed DTCs for strategic faults of the associated vehicle function. The application functions 10 are further configured to maintain fault records of the strategic faults in a user-defined secondary fault memory associated with the application function. Similarly, the RIOs 30 each include fault qualification logic for generating confirmed DTCs for physical faults of their associated I / O devices and communication channels. The RIOs 30 are further configured to continually maintain fault records of the physical faults in their respective user-defined secondary fault memories. This is in contrast to the first embodiment, in which the application functions 10 do not maintain their own records of strategic faults, and the RIOs 30 maintain their own records of physical faults only in response to a detected interruption in communication with the VDM 20.

[0075] Also, in this alternative embodiment, application function 10 and RIO 30 are configured to send locally generated DTCs for detected strategic and physical faults to VDM 20 for triage and recording in the central fault memory system only upon confirmation of a DTC, e.g., in response to a change in the DTC status byte. This is in contrast to the first embodiment, in which application function 10 and RIO 30 continuously send raw pass / fail data generated by the strategic and physical fault monitors, respectively, to VDM 20.

[0076] As in the first described embodiment, the VDM 20 is configured to triage the detected failures to classify them as either causal or consequential failures. The VDM 20 is also configured to maintain a record of causal failures in a primary failure memory portion 22 of the central failure memory system 21 and a record of consequential failures in a user-defined secondary failure memory portion 23 of the central failure memory system 21. However, because the VDM 20 is configured to receive DTCs of the detected strategic and physical failures from the application functions 10 and the RIOs 30 rather than raw pass / fail data, the fault triage process performed by the VDM 20 may be based on the received DTCs (instead of raw pass / fail data as in the first described embodiment).

[0077] The above description relates to two possible embodiments of the present invention. However, it will be appreciated that many modifications can be made to the above examples without departing from the scope of the present invention as defined in the appended claims.

Claims

1. 1. A distributed diagnostic architecture for a vehicle, the diagnostic architecture comprising: A plurality of application functions hosted on a central computing platform (CCP) of the vehicle; A plurality of remote input / output concentrator modules (RIOs) installed at different locations within the vehicle; Vehicle Diagnostic Manager (VDM) Including, Each application function is Controlling relevant functions of the vehicle; performing a diagnostic fault monitor for a strategic fault as a fault of the associated vehicle function; and Periodically transmitting the output of the strategic fault monitor to the VDM as pass / fail data or diagnostic trouble codes (DTCs). It is configured as follows: Each RIO is connected to one or more associated I / O devices of the vehicle; and Executing a diagnostic fault monitor for physical faults as failures of the associated I / O device; Periodically transmitting the output of the physical fault monitor to the VDM as pass / fail data or diagnostic trouble codes (DTCs). It is configured as follows: The VDM is Aggregate the received fault monitor output data, Identifying strategic and physical faults according to the received fault monitor output data; Maintain a central failure record of strategic and physical failures It is configured as follows: The VDM is further configured to triage the detected strategic and physical failures to classify the detected failures as either causal failures that require direct repair action or consequence failures that may not require direct repair action as a result of the causal failure. Distributed diagnostic architecture.

2. 2. The distributed diagnostic architecture of claim 1, wherein the VDM is configured to generate diagnostic trouble codes (DTCs) for detected strategic and physical faults in response to received fault monitor output data and to store the generated DTCs in the central fault record.

3. 2. The distributed diagnostic architecture of claim 1, wherein the triaging of detected faults comprises triaging fault monitor output data received from the application functions and RIOs to classify detected faults as either cause faults or effect faults.

4. 4. The distributed diagnostic architecture of claim 1 or 3, wherein the central fault record is maintained in a central fault memory system associated with the VDM, the central fault memory system being comprised of a primary fault memory and a user-defined secondary fault memory, and the VDM is configured to store a record of cause failures in the primary fault memory and to store a record of effect failures in the user-defined secondary fault memory.

5. The distributed diagnostic architecture of any one of claims 1 to 4, wherein the RIO and application functions are configured to detect physical and strategic faults, determine an appropriate fault response upon detection of a physical or strategic fault, and initiate the determined fault response.

6. 6. The distributed diagnostic architecture of claim 1, wherein the VDM is configured to maintain a keep-alive interface with the RIO, the RIO being configured to begin maintaining a local fault record of a physical fault upon detecting an interruption of the keep-alive interface.

7. A vehicle comprising the distributed diagnostic architecture of any one of claims 1 to 6.

8. 1. A distributed diagnostic architecture for a vehicle, the diagnostic architecture comprising: A plurality of application functions hosted on a central computing platform (CCP) of the vehicle; A plurality of remote input / output concentrator modules (RIOs) installed at different locations within the vehicle; Vehicle Diagnostic Manager (VDM) Including, Each application function is Controlling relevant functions of the vehicle; Executing a diagnostic fault monitor to detect a strategic fault as a fault in the associated vehicle function; Reporting detected strategic faults to the VDM It is configured as follows: Each RIO is connected to one or more associated I / O devices of the vehicle; and Executing a diagnostic fault monitor to detect a physical fault as a failure of the associated I / O device; Reporting detected physical faults to the VDM It is configured as follows: The VDM is Aggregating received strategic and physical failure notifications; Maintain a central fault record of said strategic and physical faults It is configured as follows: The VDM is further configured to triage the detected strategic and physical failures to classify the detected failures as either causal failures that require direct repair action or consequence failures that may not require direct repair action as a result of the causal failure. Distributed diagnostic architecture.

9. 9. The distributed diagnostic architecture of claim 8, wherein the application functions and RIO are configured to generate diagnostic trouble codes (DTCs) for detected strategic and physical faults and transmit the generated DTCs to the VDM for storage in the central fault record.

10. 10. The distributed diagnostic architecture of claim 8 or 9, wherein the application functions and RIOs are configured to report detected faults to the VDM using an event-driven communication interface.

11. The distributed diagnostic architecture of any one of claims 8 to 10, wherein the RIO is configured to maintain a fault record of physical faults and the application function is configured to maintain a fault record of strategic faults.

12. The distributed diagnostic architecture of claim 11 , wherein the physical fault records are maintained in a user-defined secondary fault memory of the RIO and the strategic fault records are maintained in a user-defined secondary fault memory associated with the application function.

13. 9. The distributed diagnostic architecture of claim 8, wherein the central failure record is maintained in a central failure memory system associated with the VDM, the central failure memory system being comprised of a primary failure memory and a user-defined secondary failure memory, and the VDM is configured to store a record of causal failures in the primary failure memory and to store a record of consequence failures in the user-defined secondary failure memory.

14. The distributed diagnostic architecture of any one of claims 8 to 13, wherein the RIO and application functions are configured to determine an appropriate fault response upon detection of a physical or strategic fault and to initiate the determined fault response.

15. A vehicle comprising the distributed diagnostic architecture of any one of claims 8 to 14.

Images