Automatically constructing diagnostic fault models from vehicle engineering documents

Abstract

Systems and methods for system information for integrated communication and / or electrical systems to provide a mapping of diagnostic trouble codes generated by two systems. A unified mapping is generated using the design outputs of the two systems. When the systems generate a set of diagnostic trouble codes, the unified mapping is applied by a troubleshooting tool to direct a maintenance person to a failure mode and root cause. This result can be applied to a troubleshooting tool for vehicle systems.

Description

Background Technology

[0001] Automotive technicians investigate potential vehicle malfunctions by obtaining Diagnostic Trouble Codes (DTCs) from vehicles. However, with the increasing complexity of vehicle systems, the number of DTCs generated within these systems has grown to thousands. Historically, generating manual repair plans for each of these thousands of potentially generated DTCs has been cumbersome and impractical. New and alternative methods for handling DTCs are needed. Summary of the Invention

[0002] The inventors have recognized, among other things, the particular problem to be addressed is the need for new and / or alternative systems and methods for troubleshooting using Diagnostic Trouble Codes (DTCs) in the context of vehicles and / or automobiles. In some examples, system design documents generated during the design process, such as those by Original Equipment Manufacturers (OEMs), are used to construct chains of relationships linking components, system designs, and risk-related documents to build troubleshooting tools. These chains are then used to construct the troubleshooting tools. OEMs typically use quality system documents used to monitor overall system design performance to generate tools that facilitate the investigation of DTCs in individual vehicles.

[0003] A first illustrative and non-limiting example takes the form of a method for providing troubleshooting tools for identifying and resolving system failures in a system having communication and electrical networks, comprising: creating in a processor a first mapping of communication system (CS) components, CS messages exchanged by the CS components, and CS signals carried by the messages; wherein at least one CS component is an electronic control unit (ECU), and at least one CS component is a communication bus coupling the ECU to additional CS components, further wherein the first mapping defines multiple CS symptoms and CS failure modes associated with the CS components, and for each CS message, an indication of the source CS component that generates the CS message, a receiving CS component that receives the CS message, and each path CS component that the CS message will traverse as it is transmitted from the source CS component to the receiving CS component; for the first mapping, the processor generates multiple relational chains connecting each symptom to the source CS component and the receiving CS component, and identifies each path CS component linking the source CS component to the receiving CS component; creating a CS mapping of multiple CS diagnostic fault codes (DTCs) to the relational chains. The processor creates a second mapping of electrical system (ES) components, connections between ES components, ES signals generated by ES components and received by ECUs, ES failure modes, ES symptoms, and ES corrective actions for resolving ES failure modes and their resulting ES symptoms. For the second mapping, the processor generates multiple links that associate multiple ES DTCs with individual ES symptoms and ES failure modes, and identifies which ECU will receive each ES DTC. The processor aligns the component names of the first mapping with the second mapping. The processor generates a unified mapping of ESDTCs and CS DTCs to ES symptoms, CS symptoms, ES components, and CS components. The processor also configures troubleshooting tools to perform the following: receiving reported error code sets; using the unified mapping, identifying at least one system failure and associating the system failure with one or more identified system components; and reporting to the user one or more identified system components that the user can operate on to resolve the system failure.

[0004] Additionally or alternatively, the step of the processor generating multiple relational chains includes matching information from the first mapping with data from the system's failure mode and impact analysis documents.

[0005] Additionally or alternatively, the method further includes updating the failure mode and impact analysis document; updating at least one of the plurality of relation chains in response to updating the failure mode and impact analysis document; and regenerating the unified mapping in response to updating at least one of the plurality of relation chains.

[0006] Additionally or alternatively, the step of the processor generating multiple links includes matching information from the second mapping with data from the system's failure mode and impact analysis document.

[0007] Additionally or alternatively, the method further includes updating the Failure Mode and Effects Analysis (FMEA) document; updating at least one of the plurality of links in response to updating the FMEA document; and regenerating the unified mapping in response to updating at least one of the plurality of links.

[0008] Alternatively or additionally, the CS message is a digital message, and the ES signal is an analog signal.

[0009] Additionally or alternatively, the step of identifying at least one system failure includes identifying a first system failure, determining a subset of received error codes that are not associated with the first system failure, and identifying a second system failure associated with the subset of received error codes.

[0010] Additionally or alternatively, the step of identifying at least one system failure includes identifying a list of potential system failures, determining tests to be performed on the system, said tests being helpful in prioritizing the list of potential system failures, and recommending the performance of said tests.

[0011] Additionally or alternatively, at least one DTC from CS or ES is associated with the test result.

[0012] Another illustrative, non-limiting example takes the form of a system troubleshooting tool, comprising: a processor and a memory storing a unified mapping of linked electrical subsystem (ES) components and communication subsystem (CS) components, connections between ES components, connections between CS components, fault modes associated with the ES and CS components, and diagnostic fault codes (DTCs), the unified mapping having been generated using a first mapping including CS components, CS fault modes, CS symptoms, and CS DTCs, and a second mapping including ES components, ES fault modes, ES symptoms, and ES DTCs; wherein the processor is configured to: receive a set of DTCs; reference the unified mapping using the DTC set; and identify and report component faults associated with the DTC set to the user.

[0013] Additionally or alternatively, the processor is further configured to receive input component failure modes, and in response, to identify which DTCs are associated with the input component failure modes within the DTC set.

[0014] Additionally or alternatively, the processor is further configured to: analyze the DTC set; determine whether any DTC is unrelated to the input component failure mode; and if one or more DTCs in the DTC set are unrelated to the input component failure mode, identify at least one additional possible failure of any DTC unrelated to the identified failure.

[0015] Additionally or alternatively, a unified mapping is generated using the System Failure Mode and Effects Analysis (FMEA) document by linking the DTCs of each of the CS and ES components to the failure modes identified in the FMEA document.

[0016] Additionally or alternatively, the processor is further configured to identify and report component failures associated with the DTC set to the user by: identifying a first component failure associated with a first subset of the DTC set; identifying a second subset of the DTC set that is not associated with the first component failure; and identifying a second component failure associated with the second subset of the DTC set.

[0017] Additionally or alternatively, the processor is further configured to identify and report component failures associated with the DTC set to the user by: identifying a list of potential failures based on the DTC set; determining tests to be performed on the system, which will help prioritize the list of potential failures; and recommending the performance of the tests. Additionally or alternatively, at least one test DTC from the CS or ES is associated with a test result, and the processor is configured to add the at least one test DTC to the DTC set in response to the test result.

[0018] Additionally or alternatively, the system in any of the aforementioned examples is a means of transportation.

[0019] Further examples could take the form of troubleshooting methods or troubleshooting tools, wherein, depending on the system and method described, the tool is generated using only one of the ES or CS described above, with or without consideration of other mechanical or electrical components of the underlying system.

[0020] Another illustrative, non-limiting example takes the form of a method for managing troubleshooting tools for vehicles, including: updating a fault tree analysis or fault mode and effect analysis of the vehicle by adding or modifying at least one of the fault modes or effects, and in response, updating the troubleshooting tools to take into account the added or modified fault modes or effects.

[0021] This overview is intended to introduce the subject matter of this patent application. It is not intended to provide an exclusive or exhaustive explanation. The detailed description is included to provide further information about this application. Attached Figure Description

[0022] In the accompanying drawings, which are not necessarily drawn to scale, similar numbers may describe similar components in different views. Similar numbers with different letter suffixes may represent different instances of similar components. The accompanying drawings generally illustrate the various embodiments discussed in this document by way of example rather than limitation.

[0023] Figure 1The various components of the vehicle control system are shown in boxes.

[0024] Figure 2 An illustrative engine system is shown;

[0025] Figure 3 It is a diagram illustrating the mapping of communication systems;

[0026] Figure 4 The diagram illustrates a method for generating relationship chains for a communication system;

[0027] Figure 5 It is a chart illustrating failure mode analysis;

[0028] Figure 6 The diagram illustrates a method for generating diagnostic links for electrical systems;

[0029] Figure 7 The diagram illustrates a method for generating a unified mapping for communication and electrical systems operating together;

[0030] Figure 8-10 The diagram illustrates the troubleshooting methods; and

[0031] Figure 11 The system to be analyzed is illustrated in the figure. Detailed Implementation

[0032] Figure 1Various components of a vehicle control system are shown in boxes. The vehicle may be, for example, but not limited to, a car, truck, train, airplane, or ship. An exemplary system includes a telematics unit 10, which interfaces with several illustrative vehicle subsystems. An ambient monitoring subsystem (SMS) is shown at 20 and may include additional subsystems, such as, for example, but not limited to, cameras, LIDAR, and / or radar systems. If desired, the SMS may further include subsystems for driver assistance and / or autonomous control of the vehicle. A powertrain subsystem is shown at 30 and may include, for example, but not limited to, additional subsystems for monitoring and controlling actions related to fuel, airflow, engine, and / or transmission. Powertrain subsystem 30 may incorporate an internal combustion engine (diesel, gasoline, or other fuel), an electric motor, a hybrid combustion / electric system, or any other power generation system. A chassis system is shown at 40 and may include, for example, but not limited to, additional subsystems such as stability control, tire monitoring, steering, braking control, etc. As shown at 50, a passenger cabin subsystem may be included, and this may include, for example, but not limited to, infotainment, heating, ventilation and air conditioning (HVAC), comfort, and passenger restraint subsystems. In some examples, each subsystem may have its own controller, such as by providing an electronic control unit (ECU) in the form of a microcontroller, microprocessor, or state machine, along with associated memory for storing data and machine-readable instruction sets in, for example, any suitable non-transitory medium, and other circuitry as required, such as, for example, logic or signal processing circuitry. For some subsystems, the ECU may be referred to as an engine control unit.

[0033] The telematics unit 10 may include a microprocessor or microcontroller, or other control circuitry (such as a state machine), various logic circuits, and memory for storing operating instruction sets and various data, as further detailed below. The telematics unit 10 may be operatively linked to an onboard diagnostic (OBD) port, through which an external diagnostic computer can be plugged to download information from the system. Such a port may be a standardized or non-standard interconnect, such as using various OBD standards, USB, Ethernet, other electrical, optical coupling, or any other suitable coupling. In addition to physical port 12, some systems may use wireless connectivity (Bluetooth, WiFi, cellular 4G or 5G, etc.).

[0034] The interactions between these various boxes 10, 20, 30, 40, and 50 can occur via wired or wireless connections, for example, using one or more buses, and can include a range of different signal types. One solution in transportation is to use a Controller Area Network (CAN) bus architecture. In the example, each CAN bus node includes a central processing unit, a CAN controller, and a CAN transceiver as defined by ISO 11898 and its various sub-parts. The overall system and each subsystem can be designed and / or defined according to one or more electrical drawings of the electrical components and their connections, and according to one or more communication drawings of the transmitters and receivers of the signals and the lines or links between them. Several components can participate in each of the "communication" and "electrical" networks and drawings. Some discussion may help distinguish between the two different drawings and their contents.

[0035] A communication map (or mapping) defines the path of signals whose primary function is to transmit information and commands, while essentially providing or consuming no power. Connections and signals in a communication map can be digital in nature, for example, defined by packets, each packet consisting of multiple digital zeros and ones transmitted along a bus or other communication connection. Connections to the bus or other interconnected components in a communication map use high-impedance inputs to limit current consumption in the communication lines or bus. Signals can include a digital representation of data or commands within the communication system. A typical communication packet can include a preamble, data, and a checksum, where the preamble identifies, for example, the packet's source, data type, and length; the data contains digitized information or commands; and the checksum is present for error checking using known methods.

[0036] Electrical mapping defines the paths and signals between components, where connected paths and signals typically transmit power and responsively generate real-world actions (e.g., actuator movement to close a valve) or outputs that can be recognized by the user (screen illumination, the emission of audible signals). Electrical systems can also acquire real-world observations and / or parameters within the system, such as sensing temperature, pressure, humidity, chemicals, location, state, etc., to generate signals representing the observations. In these contexts, electrical systems are used to generate outputs or acquire observations that are then reported to nodes in a communication system, where the observations can be sent to other nodes in the system via messages conveyed by the communication system.

[0037] As a specific example, one can consider a temperature sensor and an ECU coupled to it. The ECU can be a node on a CAN bus. The temperature sensor receives a power signal from a power source and is therefore part of the electrical map. The temperature sensor can obtain a temperature measurement and send an analog output to the ECU. The ECU can convert the analog output from the temperature sensor into a digital signal and transmit the temperature measurement to other nodes in the system via the CAN bus. In this configuration, the temperature sensor will reside only in the electrical map because it consumes power and its output is an electrical output that is received and digitized locally by the ECU. The ECU will be in the electrical map (firstly because it receives the electrical signal from the temperature sensor, and secondly because it consumes power in itself), and also exists in the communication map because it is coupled to the CAN bus and transmits the converted digital temperature measurement to other parts of the system.

[0038] This invention is not limited to the CAN bus architecture, and its use has been described for illustrative purposes. Examples may include more than one communication architecture, standard, or type, such as via a CAN bus with a coupling selection subsystem, while one or more additional components include connections using, for example, Ethernet. For example, a digital camera may be coupled to one or more ECUs via Ethernet. When the digital camera transmits the digitized signals it captures on the Ethernet, it will be part of a communication mapping, and when it receives power to perform its image capture activities, it will be part of an electrical mapping. Wireless connectivity, such as Bluetooth, WiFi, and / or cellular transmission capabilities, may also be included.

[0039] In context, when an error occurs, a vehicle system can generate multiple Diagnostic Trouble Codes (DTCs). DTCs related to electrical systems differ from those in communication systems. DTCs in communication systems will be at least one layer away from those in electrical systems. For example, DTCs in communication systems are generally related to a lack of information. Assuming a system has two ECU nodes—ECU-A and ECU-B—a DTC in the communication system generated by ECU-B might be "missing message from ECU-A" or "checksum failure of a message from ECU-A." DTCs generated in the communication system help identify which node or connection in the communication system is faulty. However, troubleshooting is limited because the root cause of a DTC cannot be determined solely from the communication system.

[0040] DCTs issued within an electrical system will present observations of what is happening or not happening within that system. For example, an electrical system DTC might simply be an observation that an actuator is not responding to an open or close command. If a communication system error is the actual fault, numerous electrical DTCs may be generated without any indication of the true source of the problem. For instance, in a communication system error event, dozens of actuators might be linked to electrical system DTCs. Methods and systems that enable better triangulation of actual errors are desired. In this context, integrating DTCs and other data from both the electrical and communication systems would be useful.

[0041] Figure 2 An illustrative engine and associated airflow system are shown, and it can be... Figure 1 This is one of the subsystems within box 30. The overall system is shown at 100, where the engine at 110 has multiple cylinders 112. Air entering engine 110 is received by an air filter and (optionally) monitored by a mass airflow (MAF) sensor 114. The incoming air then flows to compressor 122, which compresses the air to increased pressure to improve engine power and efficiency. Air passes through throttle valve 144 to the intake manifold of engine 110. Compressor 122 is shown as part of turbocharger 120, which also includes a turbine 124 placed in the exhaust gas flow exiting engine 110. Turbine 124 uses exhaust pressure to rotate compressor 122. Waste gas valve (WG) 142 is provided to bypass turbine 124 by directing exhaust gas to exhaust system 116, thereby allowing regulation of the speed of turbine 124 (and thus compressor 122). Exhaust system 116 may include exhaust treatment equipment and one or more sensors to detect the composition of the exhaust gas. The exhaust gas recirculation (EGR) valve is shown at 130 and can be used to return exhaust gas to the engine input, which helps reduce certain emissions.

[0042] The airflow ECU is shown at 150 and indicated as a microcontroller. The airflow ECU 150 monitors and controls the operation of the various components shown, including controlling associated valves and actuators, and obtaining readings from multiple sensors in the system. For example, some sensors will detect conditions in the airflow (temperature, pressure, mass flow rate, presence of contaminants, etc.), and other sensors can be placed to observe whether the various actuators are actually operating. Furthermore, the connections shown may include control wiring. For example, the connection to WG 142 may include an electronic connection to control the actuators that open and close the valves of WG 142. More than one ECU may be present. For example, some systems may have a dedicated microcontroller for the turbocharger 120.

[0043] ECU 150 can be viewed as being connected to engine 110, MAF sensor 114, exhaust system 116, turbocharger 120, EGR 130, RCV 140, WG 142, and CAC 144. The connections shown would be part of the electrical diagram, while the airflow ECU 150 is also a node on the communication diagram, for example, coupled to the CAN bus in sequence.

[0044] As can be understood, signals traveling back and forth within the system can suffer from various potential failures. For example, returning to WG142, when the airflow ECU 150 generates a control signal instructing WG 142 to open, the airflow ECU 150 can observe whether the sensors associated with WG 142 indicate a change in actuator position. The airflow ECU 150 can use a model of the system airflow to characterize anticipated changes in other operating characteristics, such as intake manifold air pressure or exhaust system 116 pressure / temperature, thereby providing the ability to determine whether a requested change in the position of WG 142 results in a desired or anticipated change in operating characteristics. If the airflow ECU 150 does not receive a signal indicating that a change in the position of WG 142 has been directly observed, or does not observe the anticipated effect of such an anticipated change, the airflow ECU 150 may generate one or more DTCs. This could be due to actuator failure, lack of a signal to the actuator, failure of the sensor associated with the actuator to accurately detect actuation or other changes, or failure to send or receive a signal from the sensor. Each such failure may be the result of a different underlying cause. The airflow ECU 150 will generate one or more DTCs. Due to DTC and Figure 2 The components shown are related, including the operation of those components and their connection to the airflow ECU 150; therefore, the DTC will be an electrical DTC. Any errors observed during communication when the airflow ECU 150 communicates with other nodes in the communication system will appear as a communication DTC.

[0045] For maintenance purposes, each ECU in a vehicle generates DTCs (Distributed Trace Control Items) that are recorded over time by each subsystem. During maintenance, these DTCs can be downloaded by technicians using a repair tool plugged into the vehicle's OBD port or via over-the-air transmission. Historically, technicians would refer to manuals containing descriptions of DTCs along with possible symptoms and causes, and would then use intuition and the manual to identify possible root causes. Such manuals would contain instructions for handling each DTC. As systems in vehicles become more complex, even more DTCs are generated—modern vehicles are capable of generating thousands of DTCs. Furthermore, a single vehicle malfunction can trigger a "cascade" of two, three, or even dozens of DTCs. Manually generating repair plans for these DTC combinations introduces further complexity. Even with electronic manuals, DTC code lookup and manual-based instruction preparation have become impractical. New and alternative methods are expected.

[0046] Figure 3 This is a diagram illustrating a communication system mapping. The mapping in this example identifies multiple messages that can be sent within the communication system, listed at 200. Each message originates from source 210 and is sent from source 210 along one or more paths 230 to one or more receivers 220. As shown, each message contains content illustratively shown as one or more “signals” 240. Thus, for example, communication message 202 could originate from a first ECU (source So_1) reflecting a measurement result or multiple measurements from one or more sensors operatively linked to the first ECU. At least in the CAN bus example, message M_1 could be received by each of several other nodes in the system and could include a signal used by several receiver 220 nodes, or more than one signal used by more than one other node. As an example, a vehicle system could include a temperature sensor to capture ambient temperature, and the sensor’s output would be routed to the first ECU (So_1) and then distributed in a message to second and third receiver ECUs (R_1, R_2). For example, the ambient temperature signal could be received by a passenger compartment HVAC ECU and an engine airflow ECU. Each path can be identical, or it can comprise different segments of the CAN bus, or there can be paths on each of two different buses, or a message can traverse one path 230 wirelessly and another path 230 via a wired connection. In a given system, using various paths 230 and multiple distinct signals 240, thousands of messages can be defined in the communication map between dozens or more sources 210 and receivers 220.

[0047] Figure 4The diagram illustrates a method for generating relational chains for a communication system. As shown, this method will primarily execute in a processor or computer environment, where human input is used as needed to format data input into a processor-available format. To make the communication system mapping available in a broader, unified mapping, some of the sample methods and systems use methods such as... Figure 4 The method shown constructs the relational chain. A communication system design is obtained at 250, including, for example... Figure 3 The mapping is shown in the diagram. Additionally, obtain communication system documentation, including a list of failure modes and symptoms for each failure mode. Failure mode and symptom documentation can be standard documentation associated with the design of modern vehicles or other systems. For example, the system's failure modes and symptoms can be obtained from Failure Mode and Effects Analysis (FMEA) or other design / risk documents, which are generated as part of most modern quality systems. Figure 5 The document shows an illustrative, simplified FMEA worksheet.

[0048] Next, as indicated at 260, relationship chains are generated. Each relationship chain includes multiple elements linking symptom 262 to message source 264, message receiver 266, and message path 268. Symptom 262 is extracted from, for example, a system FMEA or other failure mode document. Then, by matching one or more of the message identifier, message name, or signals in the message, data is retrieved from... Figure 3 The message signal knowledge obtained from the mapping is used to link these, as reflected in the communication mapping.

[0049] Next, the method includes mapping DTC data to a relational chain encompassing symptom 262, source 264, receiver 266, and path 268, as indicated at 280. In step 280, the DTC list of the underlying system is obtained and integrated. For example, DTC data can be linked by matching symptom 262 with DTC description information. For example, in box 280, human input can be used to associate symptoms with DTCs to the necessary extent. As with several examples in this paper, a system documentation built from scratch using a consistent language for both DTCs and symptom descriptions can reduce or eliminate the need for human input.

[0050] Fault Tree Analysis (FTA) can also be used to populate FMEA or as an additional quality system tool. FTA is a top-down quality system analysis that begins with (generally) undesirable high-level system states. The potential causes of these undesirable system states are then listed in the tree, typically using Boolean logic to identify combinations of low-level system failures that could lead to high-level system failures. FTA can be useful in helping to establish chains of relationships within communication systems, and later in the analysis below, to link communication system failures with electrical system failures. The use of FTA will be discussed further below.

[0051] Figure 5 This is a diagrammatic FMEA. Component 300 can be laid out in an FMEA format such as a spreadsheet or any other suitable format. As desired, component 300 can be further organized according to subsystems or subassemblies. Each component 300 is linked to one or more failure modes 310 and one or more effects 320. The FMEA can be generated in separate sections of communication systems and electrical systems.

[0052] For the communication system FMEA, the first ECU can be component 300 and can have fault modes such as loss of connection, loss of power, etc. Each such fault mode can manifest as one or more distinct effects 320, such as inability to confirm communication or generate output communication.

[0053] For an electrical system FMEA, the valve can be component 300 and can have failure modes 310, such as inability to open and inability to close. Failure modes can be defined more specifically, such as inability to open due to scaling, inability to open due to damaged fins, etc. Each failure mode 310 can manifest as one or more distinct effects 320, such as loss of power (causing user complaints) or increased emissions (potentially causing emission sensors to display out-of-range readings).

[0054] It can be noted that two different failure modes may result in the same effect, as illustrated in rows 1 and 3 of the figure. A single failure mode may also result in more than one effect. Various other overlaps may occur. Each effect 320 can represent an event or an irregularity in the system. Figure 4 The "symptoms" marked in the text can each be associated with an impact of 320.

[0055] Figure 5 The charts in this document omit several columns that might be included in an FMEA document, such as the likelihood, severity, and / or detectability rating for each line, as well as any mitigations and the impact of such mitigations. For example, not all effects are readily observable, and therefore, in some FMEA documents, a further assessment of detectability may be conducted for each line. FMEA documents can be used in various ways, including, but not limited to, design, design verification, risk assessment, component qualification, continuous improvement, and / or reliability monitoring. For example, field events (failures in actual use) can be monitored for occurrence rates to identify trends, and these can be compared to likelihood ratings to determine whether the system is performing as expected, as reflected in the FMEA and other quality system documents.

[0056] FMEA documentation is built from the bottom up, starting with components and then being applied more broadly throughout the system. In practice, FMEAs are typically used as a reference document in response to reported field events. Field events can be collected and referenced to the FMEA to determine whether a reported field event was known and whether possible events have been documented in the FMEA. Furthermore, trend data will be constructed from the FMEA and / or other risk assessment processes. However, FMEAs are generally not integrated into the process of determining what caused the field event.

[0057] When unexpected failures or other events are observed, they can be added to the FMEA. Corrective and preventative actions (CAPA) can be initiated in response to observed discrepancies between actual performance and the FMEA. While the FMEA is not the only procedure upon which decisions about reliability trends and / or CAPA are made, it is typically reviewed and updated as part of these and other quality system procedures.

[0058] Some examples in this article use FMEA in novel and differentiated ways. In certain examples, FMEA and / or other design documents are used to construct or generate troubleshooting tools. In some examples, the resulting troubleshooting tools and unified mappings discussed in this article may also be updated as the FMEA is updated over time.

[0059] Figure 6 The illustration depicts a method for generating diagnostic links for an electrical system. The method, as shown, will primarily be executed in a processor or computer environment, where human input is used as needed to format data input into a format available to the processor. This set of links is generated starting with an electrical system design 350, which, in this example, includes a set of components in the electrical system (e.g., controllers such as ECUs, sensors, actuators, buses (including CAN buses), and associated leads for such components, wiring harnesses with connectors and associated leads, and links defined at the connector and wire levels). For example, the electrical system design may include wiring harness design artifacts in a vehicle.

[0060] This data is built into an electrical model of some or all of the electrical networks of a vehicle or other system. The electrical model uses FMEA to correlate standard symptoms and failure modes. Corrective actions and / or failure modes for each symptom are then linked to the symptom. Such corrective actions can often be defined directly based on the failure mode. For example, the symptom of a fault to be actuated might be associated with a failure mode of "loss of electrical connection to control signals," which would be corrected by restoring the lost electrical connection, such as by replacing cables or ensuring cable connectors are properly secured. For example, a corrective action could be defined as replacing or repairing a component that has failed.

[0061] Then, at point 360, this dataset is built into an electrical system link set. Each link connects fault mode 362 to symptom 364, and thus to electrical system DTC 366. An ECU (or other controller) 368 is used to observe and store DTCs for each link. Electrical system links 360 can be incorporated into a system-level set of electrical DTCs, which is then parsed to associate each DTC 362 with the fault mode and symptom 364. Such parsing can be performed using text identifiers to automate a large portion of the analysis.

[0062] Figure 7 The diagram illustrates a method for generating a unified mapping for communication and electrical systems operating together. The method, as shown, will primarily execute in a processor or computer environment, where human input is used as needed to format data input into a processor-available format. Here, the unified mapping is generated at 410, which will come from... Figure 4 The communication system (CS) relationship chain 400 and from Figure 6 The electrical system (ES) link 402 is taken as input. A text parser can be used to generate a uniform mapping 410 to resolve uncertainties, with or without human input. The text parser can be configured to identify matching languages ​​between component names in each system. If the CS and ES systems use a consistent language to describe components, the text parser can automatically perform box 410; if there are differences between the systems, human input can be used as needed to resolve uncertainties.

[0063] The resulting unified map 410 may include multiple associations as shown at 420. For each DTC 420, a list of associated symptoms 424 and failure modes 426 is identified in the unified map. In this example, each of the ES and CS DTCs is accounted for in the unified map. If it is desired to handle errors from such DTCs separately from the unified map approach, one or more DTCs from CS or ES can be omitted from the unified map. In the unified map, each failure mode 426 may also be mapped to an affected component.

[0064] This unified mapping at 410 contrasts with existing techniques. In existing techniques, expert input is used to generate corrective action plans for each DTC. This existing DTC solution is a top-down approach, which is known to require a large amount of expert input and result in significant redundancy. By instead forming a bottom-up unified mapping 410, expert input can be reduced to those inputs necessary to complete the mapping, such as confirming or resolving uncertainties arising from the textual parsing of symptom, impact, and / or component names.

[0065] For illustrative purposes, the examples shown in the preceding figures focus on combined communication and electrical system design articles and DTC information. The invention should be understood to be applied more broadly than this particular set of examples.

[0066] In another example, one or more FTA structures can also be integrated. An FTA can observe high-level faults, such as communication system faults, and then use Boolean logic to link to connection groups of lower-level faults. Thus, for example, an FTA can be used to link DTCs associated with a specific fault mode at the communication system level to one or more electrical system fault modes that contribute to or directly cause the identified communication system fault mode.

[0067] Figure 8 The illustration depicts a troubleshooting method. In this example, one or more DTCs are input into troubleshooting tool 510 at point 500. Troubleshooting tool 510 may take the form of a computer storing instructions in the form of a program that accepts a list of DTCs as input and then refers to... Figure 7 The generated unified map 520 is shown in the figure. Using the input list of DTCs, the multiple associations, symptoms 526, and failure modes 528 shown at 522 of DTC 524 are then marked by the troubleshooting tool. The troubleshooting tool 510 can then identify one or more failure modes 530.

[0068] If all entered DTCs point to one (or more) failure modes associated with a single component, that single component and / or failure mode can be identified in box 530. More frequently, multiple potential failure modes can be identified in box 530. The troubleshooting tool can be configured to present multiple potential failure modes and / or associated components in a priority list. In another example, the priority list can be determined by first presenting those failure modes or components associated with the most DTCs. In yet another example, the design engineering document used to generate the unified map can have additional information integrated into the unified map, specifically the probability and / or severity level of a given impact and / or failure mode. For example, if the troubleshooting tool identifies several potential failure modes, the potential failure modes associated with the highest probability of occurrence can be prioritized according to the FMEA. Alternatively, the potential failure modes associated with the highest severity level can be prioritized. Additional criteria can be used to rate potential failure modes based on the cost of troubleshooting, testing, inspecting, and / or repairing each such mode, such as by first presenting the easiest or cheapest failure mode for repair. If more than one potential failure mode is identified, other combinations of factors can be used to generate a priority list.

[0069] In some examples, the tool can also generate a list of tests—whether diagnostic or functional—to be performed, providing additional information to reduce the list of candidate failure modes. The results of such tests can be considered “potential DTC” observations; that is, the test results can be incorporated into the DTC operations in the integration above, thus producing a unified mapping. Criteria for determining which tests to perform can be used, such as the cost of performing the tests and the likelihood that they will advance troubleshooting analysis.

[0070] One approach to using tests as potential DTCs is to receive a set of information (DTCs) from the system being analyzed. Troubleshooting tools can identify the tests to be performed, which will resolve one or more received DTCs to confirm or refute the existence of a specific failure mode. This is achieved by including one or more ES links or CS relationship chains with potential DTCs, along with associated ES links or CS relationship chains. Figure 4 Alternatively, the link set or chain set developed in section 6 can be used to build "potential DTCs" into the overall architecture. Once the test is executed, it can be used to add to the DTC list. For example, if the test has a binary result ("A" or "not A"), the test result can be added as a new DTC, where the first DTC is for result "A" and the second DTC is for result "not A". In response to this test, the newly added DTC can then be used to help prioritize potential failure modes as described above.

[0071] Figure 9Another troubleshooting method is illustrated. In some examples, the method can be performed by a computer storing instructions in the form of a program for performing the illustrative steps shown. In this example, at 600, a unified map is generated by obtaining an engineering artifact 610 of one or more systems or subsystems, such as a vehicle or other complex system. In some examples, two or more partially overlapping systems having at least one common element can be grouped together in the unified map. In some examples, two or more design layers forming a set of components for a system or subsystem can be grouped together in the unified map. The engineering artifact 602 can come from design specifications, quality system documentation, and / or error code knowledge. For example, the engineering artifact 610 may include documentation of communication 612 between specific components, and a layout 614 of such components. Communication 612 can occur between nodes and communication lines within the system, including any available bus lines. Valves or actuators may also be electrically linked to control units, such as ECUs or other controllers, and these electrical connections may also be part of the layout 614. Furthermore, layout 614 can define the mechanical interactions between components, including, for example, determining the association of mechanical interactions between one component and another within an air handling system (with valves and sensors, such as in an engine). Error code 616 generated by system components can also be used as an artifact 610. A DTC is an example of an error code 616 that can be considered an artifact 610. Failure mode 618 is another artifact to be obtained.

[0072] Then, a unified mapping at 600 locations will be generated using methods such as those described above. For example, data from each engineered artifact source can be aligned using a text parser, such as by matching text, part numbers, etc., and / or expert knowledge, to develop associations between individual components, assemblies, subassemblies, and / or systems notified by communication 612 and layout 614 data, to define failure modes and symptoms associated with such components and their communication-based and layout-based interactions. Finally, error codes 616 in the system can be matched with associations by linking error codes, symptoms, and failure modes.

[0073] The unified map 600 can then be made available to the troubleshooting tool 630. The troubleshooting tool 630 can take the form of a general-purpose or special-purpose computer storing a set of instructions for performing the steps illustrated. In some examples, the unified map 600 can be maintained at a central server, and the troubleshooting tool 630 can access the central server to operate. In other examples, the unified map 600 can be rolled out to the troubleshooting tool 630, for example, via download or software update. In either case, the unified map 600 can be maintained in a manner that allows for occasional (in response to events) or periodic (at known intervals) updates, thus keeping the troubleshooting tool 630 up-to-date. Then, at 640, a user, such as a maintenance technician, can enter one or more error codes into the troubleshooting tool 630, and the troubleshooting tool 630 responds by identifying one or more fault modes 650 and transmitting one or more fault modes to the user. As desired, corrective actions can be transmitted along with the fault modes to allow the user to take appropriate corrective actions.

[0074] Another example is the use of troubleshooting tools in online and / or predictive or preventative maintenance modes. Here, the "input" element at 640 can be performed by a monitored system, such as a vehicle, which can remotely upload error codes when they occur or during periodic or incidental uploads. Troubleshooting tool 630 can be maintained as a centralized tool for a distributed system cluster and can identify one or more failure modes 650. In a remote context, the identified failure mode can be used to trigger immediate maintenance as needed. In this context, a system "failure" may not necessarily cripple the system; the identified "failure" may simply be a need for maintenance. If immediate maintenance is not required, the remote server can instead issue communications to schedule or add the required maintenance to a work order to address the failure mode. In yet another example, the remote system can send a message to a specific vehicle in the queue indicating the existence of one or more failure modes, but which do not require immediate maintenance, and DTCs associated with such known failure modes can be ignored.

[0075] accomplish Figure 9Examples can be obtained of first and second mappings for system components, such as communication mappings and layout mappings for system components. First and second mappings can include fault modes, error codes, and components (and their interactions). More than two mappings can be integrated. The unified mapping at 600 can integrate two input mappings using, for example, alignment of component "names". "Name" in this context can include part numbers, or all or part of a component name (such as, for example, "Airflow ECU", "LIDAR Controller", "HVAC Controller", etc.). For systems designed with a unified mapping 600 as a planned feature, naming conventions can be adopted from the outset to ensure simple and automated alignment of component names. If diverse system inputs are used, such as subsystems from different manufacturers, expert input can be used to confirm name alignment.

[0076] Error codes 640 can be entered into troubleshooting tool 630, which uses a unified mapping 610 to identify one or more failure modes 650. Based on the identified failure mode 650, a system failure can be identified and linked to one or more system components. Corrective actions linked to the identified failure mode 650 can then be performed, such as by replacing, repairing, or otherwise maintaining (e.g., cleaning) the identified one or more system components. A system "failure" may not necessarily render it inoperable; the identified "failure" may simply be a matter of maintenance.

[0077] Figure 10 Another illustrative method is shown. Here, a unified mapping 700 is used to enable a troubleshooting tool 710. The troubleshooting tool 710 may take the form of a computer that stores instructions in the form of a program that accept input fault modes and / or a list of DTCs as input. In this example, the troubleshooting tool 710 is configured to receive input fault modes 720. Input fault modes 720 may be identified in any suitable manner, such as whether a particular fault mode has been observed externally (e.g., but not limited to, component failures that can be visually observed, or using methods such as...). Figure 8 (or the fault mode identified by the method shown in 9). Troubleshooting tool 710 can then generate a list of linked DTCs 730 associated with the fault mode. For example, as shown, such a process can be used to then remove linked DTCs from the maintenance request, where the remaining DTCs are identified at 740 and re-entered into troubleshooting tool 710, thereby allowing the identification of additional fault modes.

[0078] Figure 11An illustrative system with communication and electrical subsystems is shown. The system, as illustrated, uses bus 800 as the backbone of the communication subsystem, and each of ECU_1 810 and ECU_2 820 is communicatively coupled to bus 800. Each of 800, 810, and 820 will be part of the CS drawing. ECU_1 810 is coupled to multiple components E_1_1 812 and E_1_2 814, which may be, for example, sensors, actuators, or other components. Similarly, ECU_2 820 is coupled to multiple components E_2_1 822 and E_2_2 824. Therefore, each of 810, 812, 814, 820, 822, and 824 will be part of the ES drawing.

[0079] If one of the electrical system components (such as E_1_1 812) malfunctions, this can generate multiple ES DTCs. The component itself and its associated ECU may generate DTCs. ES DTCs related to errors in E_1_1 812 are typically captured and stored at ECU_1. However, in an integrated system, assuming, for example, E_1_1 is a sensor whose output can be used elsewhere in the system, such as by ECU_2 820 when a command is issued to E_2_1 822. A lack of readable or correct readings at E_1_1 812 may prevent ECU_1 from communicating with ECU_2 via bus 800, creating a CS DTC due to the lack of expected communication. Additionally, in the absence of updated data to E_2_1 822, additional ES DTCs may be generated and stored in ECU_2 820. At this point, a fault in E_1_2 814 has already caused ES DTCs to be generated and stored in both ECU_1 810 and ECU_2 820, as well as one or more CS DTCs. In existing technology, technicians reviewing DTCs during maintenance follow-up will need to analyze DTCs individually to determine which ones were caused by which faults and where they were caused.

[0080] In contrast, for this invention, the underlying system quality documentation, including FMEA (or FTA), can be used to determine whether and how the ES DTC stored at ECU_2 reflects problems occurring in different subsystems elsewhere in the overall system. Specifically, in response to a failure to receive data from another component E_1_1 812 in another subsystem, the FMEA will record that the affected component E_2_1 822 may generate an error code. This invention will also allow CSDTCs generated in the above scenario to be easily identified as being related to the same underlying problem as the ES DTC, without requiring a technician to have knowledge of the overall system architecture. As a result, enhanced real-world technical impact is demonstrated.

[0081] Figure 11The examples in this paper are greatly simplified. In a typical system such as a car, there may be as many as ten or more ECUs coupled to the bus 800, each with dozens or more ES components coupled to each ECU. By constructing a unified mapping using the relationship chains and mappings described in this paper, and by simply building troubleshooting tools using existing quality system documentation, the complexity of the results can be handled serially.

[0082] Each of these non-restrictive examples can exist independently or can be combined with one or more other examples in various permutations or combinations.

[0083] The above detailed description includes reference to the accompanying drawings, which form part of the detailed description. The drawings illustrate specific embodiments by way of illustration. These embodiments are also referred to herein as “examples.” Such examples may include elements other than those shown or described. However, the inventors also contemplate that only those elements shown or described are provided as examples. Furthermore, the inventors contemplate examples of any combination or arrangement of those elements (or one or more aspects thereof) used, relative to a particular example (or one or more aspects thereof), or relative to other examples (or one or more aspects thereof) shown or described herein.

[0084] In this document, as is common in patent documents, the terms “a” or “an” are used to include one or more, independent of any other instances or uses of “at least one” or “one or more”. Furthermore, in the claims, the terms “first,” “second,” and “third,” etc., are used merely as labels and are not intended to impose numerical requirements on their objects.

[0085] The method examples described herein may be implemented, at least in part, by a machine or computer. Some examples may include computer-readable or machine-readable media encoded with instructions operable to configure an electronic device to perform the methods described in the examples above. Implementations of such methods may include code, such as microcode, assembly language code, high-level language code, etc. Such code may include computer-readable instructions for performing various methods. This code may form part of a computer program product. Additionally, in the examples, the code may be tangibly stored on one or more volatile, non-transitory, or non-volatile tangible computer-readable media, such as during execution or at other times. Examples of such tangible computer-readable media may include, but are not limited to, hard disks, removable disks or optical discs, magnetic tape cassettes, memory cards or sticks, random access memory (RAM), read-only memory (ROM), and the like.

[0086] The above description is intended to be illustrative and not restrictive. For example, the above examples (or one or more aspects thereof) may be used in combination with each other. Other embodiments may be used by those skilled in the art upon review of the above description. The abstract is provided to comply with 37C.FR §1.72(b) to allow the reader to quickly determine the nature of the technical disclosure. It is submitted on the understanding that it will not be used to interpret or limit the scope or meaning of the claims.

[0087] Furthermore, in the detailed description above, various features may be grouped together to simplify this disclosure. This should not be construed as implying that any disclosed feature not claimed is necessary for any claim. Rather, the subject matter of innovation may lie in fewer than all features of a particular disclosed embodiment. Therefore, the following claims are thus incorporated into the detailed description as examples or embodiments, wherein each claim is an independent, separate embodiment, and it is contemplated that such embodiments may be combined with each other in various combinations or arrangements. The scope of protection should be determined with reference to the appended claims together with the full scope of their equivalents.

Claims

1. A method for providing troubleshooting tools for identifying and resolving system failures in systems having communication networks and electrical networks, comprising: A first mapping is created in the processor of CS components, CS messages exchanged by the CS components, and CS signals carried by the CS messages; At least one of the CS components is an ECU, and at least one CS component is a communication bus that couples the ECU to the additional CS components. Further, the first mapping defines a plurality of CS symptoms and CS failure modes associated with the CS components, and for each CS message, an indication of the source CS component that generates the CS message, the receiving CS component that receives the CS message, and each path CS component that the CS message will pass through as it is transmitted from the source CS component to the receiving CS component. The CS is the communication system, and the ECU is the electronic control unit. For the first mapping, the processor generates multiple relational chains that connect each symptom to a source CS component and a receiver CS component, and identifies each path CS component that links the source CS component to the receiver CS component; Multiple CS DTCs are mapped to the relationship chain, where DTCs are diagnostic fault codes. The processor creates ES components, connections between the ES components, ES signals generated by the ES components and received by the ECU, and a second mapping of ES fault modes, ES symptoms, and ES correction actions for resolving the ES fault modes and the resulting ES symptoms, wherein the ES is the electrical system. For the second mapping, the processor generates multiple links that associate multiple ES DTCs with individual ES symptoms and ES failure modes, and identifies which ECU will observe and store each ES DTC. Align the component names of the first mapping with those of the second mapping; The processor generates a unified mapping from ES DTCs and CS DTCs to ES symptoms, CS symptoms, ES components, and CS components; and Configure the troubleshooting tool to perform the following: The error code set received in the report; Using the unified mapping, at least one system failure is identified and the system failure is associated with one or more identified system components; as well as Report to the user one or more identified system components that the user can operate to resolve the system malfunction.

2. The method of claim 1, wherein the step of the processor generating the plurality of relationship chains includes matching information from the first mapping with data from the failure mode and impact analysis document of the system.

3. The method according to claim 2, further comprising: Update the aforementioned failure mode and impact analysis document; In response to updating the failure mode and impact analysis document, at least one of the plurality of relationship chains is updated; as well as In response to updating at least one of the plurality of relation chains, a unified mapping is regenerated.

4. The method of claim 1, wherein the step of the processor generating the plurality of links includes matching information from the second mapping with data from a failure mode and impact analysis document of the system.

5. The method of claim 4, further comprising: Update the aforementioned failure mode and impact analysis document; In response to updating the Failure Mode and Effects Analysis document, at least one of the plurality of links is updated; as well as In response to updating at least one of the plurality of links, a unified mapping is regenerated.

6. The method according to any one of claims 1-5, wherein the system is a means of transportation.

7. The method according to any one of claims 1-5, wherein the CS message is a digital message and the ES signal is an analog signal.

8. The method according to any one of claims 1-5, wherein the step of identifying at least one system failure includes identifying a first system failure, determining a subset of the received error code set that is not associated with the first system failure, and identifying a second system failure associated with said subset of the received error code set.

9. The method according to any one of claims 1-5, wherein the step of identifying at least one system failure includes identifying a list of potential system failures, determining tests to be performed on the system that will help prioritize the list of potential system failures, and recommending the performance of the tests.

10. The method of claim 9, wherein at least one DTC from CS or ES is associated with the result of the test.

11. A troubleshooting tool for a system, comprising: The processor and memory, the memory storing a unified mapping of linking ES components and CS components, connections between the ES components, connections between the CS components, fault modes associated with the ES components and the CS components, and DTCs, the unified mapping being generated using a first mapping including CS components, CS fault modes, CS symptoms, and CS DTCs, and a second mapping including ES components, ES fault modes, ES symptoms, and ES DTCs, where ES refers to the electrical subsystem, CS refers to the communication subsystem, and DTC refers to diagnostic fault codes; The processor is configured as follows: Receive DTC set; Use the DTC set to reference the unified mapping; and Identify and report component failures associated with the DTC set to the user.

12. The troubleshooting tool of claim 11, wherein the processor is further configured to receive an input component failure mode, and in response thereto, identify which DTCs are associated with the input component failure mode within the DTC set.

13. The troubleshooting tool of claim 12, wherein the processor is further configured to: Analyze the DTC set; Determine if any DTCs are unrelated to the input component failure mode; and If one or more DTCs in the DTC set are not related to the input component failure mode, then identify at least one additional possible failure of any DTC that is not related to the identified failure.

14. The troubleshooting tool according to any one of claims 11-13, wherein the unified mapping is generated using the FMEA document, i.e., Failure Mode and Effects Analysis, by linking the DTCs of each of the CS component and the ES component to the failure modes identified in the system FMEA document.

15. The troubleshooting tool according to any one of claims 11-13, wherein the processor is further configured to identify and report component failures related to the DTC set to the user in such a way that: Identify the first component failure associated with a first subset of the DTC set; A second subset of the DTC set that is not associated with the failure of the first component; as well as Identify the second component failure associated with the second subset of the DTC set.

16. The troubleshooting tool according to any one of claims 11-13, wherein the processor is further configured to identify and report component failures related to the DTC set to the user in such a way that: The potential fault list is identified based on the DTC set; Determining the tests to be performed on the system will help prioritize the list of potential failures; and The test described is recommended.

17. The troubleshooting tool of claim 16, wherein at least one test DTC from CS or ES is associated with the result of the test, and the processor is configured to add the at least one test DTC to the DTC set in response to the result of the test.

18. The troubleshooting tool according to any one of claims 11-13, wherein the system is a vehicle.

Images