Patent Application
20180164760
The present disclosure generally relates to diagnostic systems, and more particularly relates to building models for diagnostic systems.
Complex systems, such as aircraft, automobiles, spacecraft or other complex machinery include numerous integrated systems. Diagnosing particular faults in the complex systems can be difficult due to the large number of components in each complex system as well as the complex interactions between the large number of components. In other words, a first system may be dependent upon multiple other systems in the complex system. Thus, a fault at the first system can be difficult to trace to root problems.
Health management applications are a useful tool for diagnosing faults in complex systems. When given an accurate model, health management applications can trace diagnostic trouble codes to specific root problems. However, health management applications require accurate models in order to perform their function.
In one embodiment, for example, a system for building a dependency diagnostic model of a complex system having a plurality of assemblies is provided. The system may include, but is not limited to, a processor, the processor configured to receive at least one function model corresponding to each assembly of the complex system, at least one health and condition indicator model corresponding to an output of the complex system, a program data dictionary, standard failure modes and propagation rules, determine interdependencies between the plurality of assemblies of the complex system and the output of the complex system based upon the at least one function model, the at least one health and condition indicator model and the program data dictionary, generate the diagnostic model based upon the determined interdependencies between assemblies of the complex system and the output of the complex system, and optimize the generated diagnostic model based upon the standard failure modes and the propagation rules.
In another embodiment, for example, a method for generating a dependency diagnostic model for a complex system having a plurality of assemblies is provided. The method may include, but is not limited to, receiving, by a processor, at least one function model corresponding to each assembly of the complex system, at least one health and condition indicator model corresponding to an output of the complex system, a program data dictionary, standard failure modes and propagation rules, determining, by the processor, interdependencies between the plurality of assemblies of the complex system and the output of the complex system based upon the at least one function model, the at least one health and condition indicator model and the program data dictionary, generating, by the processor, the dependency diagnostic model based upon the determined interdependencies between assemblies of the complex system and the output of the complex system, and optimizing, by the processor, the generated dependency diagnostic model based upon the standard failure modes and the propagation rules.
The detailed description will hereinafter be described in conjunction with the following drawing figures, wherein like numerals denote like elements, and wherein:
The following detailed description is merely exemplary in nature and is not intended to limit the invention or the application and uses of the invention. As used herein, the word “exemplary” means “serving as an example, instance, or illustration.” Thus, any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. All of the embodiments described herein are exemplary embodiments provided to enable persons skilled in the art to make or use the invention and not to limit the scope of the invention which is defined by the claims. Furthermore, there is no intention to be bound by any expressed or implied theory presented in the preceding technical field, background, brief summary, or the following detailed description.
As discussed in further detail below, a system for automatically building a dependency diagnostic model for a health management system is provided. Building a dependency diagnostic model is a critical step in the development of health management applications for complex systems such as aircraft, automobiles, other vehicles and facilities (manufacturing facilities, test facilities, factories, or the like), or the like.
The model builder 110 is communicatively coupled to at least one interface system 120. The interface systems 120 can include, but are not limited to, data communication interfaces, displays, diagnostic tools, diagnostic interfaces, user interfaces, computer-readable media readers (e.g., a CD reader, a DVD reader, a Blu-ray disk reader, a compact flash reader, a secure digital (SD) reader, or any other physical media reader) or any combination thereof.
The model building system 100 further includes at least one memory 130. The memory 130 may be located within the model builder 110, may be one or more remote memory units communicatively coupled to the processor 115 via one of the interface systems 120, or a combination thereof. The memory 130 stores computer-readable instructions for implementing the dependency diagnostic model building system 100, as discussed in further detail below.
The memory 130 stores one or more function models 140. Each component of a complex system may have its own function model. Complex systems 200 may have, tens, hundreds, thousands or more functional models. The function models 140 dictate the control of a component of a complex system 200 based upon one or more states or signals of the system. The signals and states may be data based (e.g., vehicle speed, temperature, GPS data, engine RPM), physically based (e.g., gear of the vehicle) or the like, or a combination thereof. For example, if the complex system 200 is an automobile, a control command to increase the engine speed of the vehicle may depending upon one or more states or signals including, but not limited to, the current engine speed, the current engine gear, a gradient of the surface the vehicle is traveling upon, and the like. The function model 140 illustrates how an element of the complex system (hereinafter referred to as an assembly of the complex system) performs a function, such as a command dictating the amount of fuel to inject into the engine, as well as the input (i.e., states and signals) necessary to execute the command. The function models 140, for example, may be Matlab Function models, Simulink models, Unified Modeling Language (UML) models, automotive open system architecture (AUTOSAR) models, or the like. As discussed in further detail below, the model builder 110 leverages the function models 140 to determine how various components of the complex systems are interdependent.
The memory 130 also stores health and condition indicator models 150 corresponding to output of a complex system. In an automotive setting, for example, health indicators may be diagnostic trouble codes (DTC) and condition indicators may be parameter identifiers (PIDs). In complex systems, trouble codes output by the complex system may correspond to the health indicators. Vehicles, for example, often include a readable interface where any triggered health indicator (i.e., a DTC) can be read by a technician. The health indicators indicate that there is a fault in one or more systems of the vehicle. In contrast, condition indicators, such as PIDs in an automotive setting, are codes used to request data from a complex system. When a health management system is coupled to the complex system via, for example, an interface system 120 such as a diagnostic interface, the health management system can request specific data from the vehicle defined by the condition indicators to aid in diagnosis. The health and condition indicator models stored in the memory 130 model each of the health and condition indicators. In other words, the health and condition indicator models define how each health indicator is triggered and how each condition indicator is determined. As discussed in further detail below, by knowing how each health indicator is triggered and how each condition indicator is determined, the health management system can better diagnose the complex system.
The memory 130 further includes a program data dictionary 160. The program data dictionary may include a list of variables corresponding to the same data point. As discussed above, each component of the complex system may have its own function model and its own fault model, which may have not been created by the same person. Accordingly, data points which are utilized by more than one component may have been called by different names in the each function and fault model. The processor 115 thus can utilize program data dictionary to correlate the differently named variables to one another.
The memory 130 further includes standard failure mode models 170. Different components of the complex system have different types of failures. A sensor, for example, may be expected to have an output within a certain range. One standard failure mode for the sensor may be an output outside of the range. Another standard failure mode may be the sensor not outputting data whatsoever. Likewise, components of the complex system dependent upon data from another component may have different responses to the different failure modes of an upstream component. In other words, an assembly of the complex system may have a different response to receiving sensor data which is out of a certain range than to not receiving data from the sensor whatsoever. The processor 115 can thus utilize these standard failure modes and the responses thereto, to narrow down which component of the complex system is at fault.
The memory 130 further includes propagation rules 180. The propagation rules codify how errors propagate through the complex system. For example, multiple diagnostic trouble codes could be output from the complex system. However, multiple codes may not necessarily equate to multiple component failures. Using the example mentioned above, a component having a failure due to not receiving a signal or receiving a signal out of a certain range from a sensor may trigger a first diagnostic trouble code. A power failure (e.g., a voltage out of range or a blown fuse), for example, of a system powering the sensor may cause the complex system to output a second diagnostic trouble code. Thus, although the first diagnostic code may indicate a problem with the sensor, the second diagnostic code indicates a problem upstream from the sensor. Accordingly, the processor can utilize the propagation rules to order a list of possible failure causes such that, for example, a technician analyzes the power system before the technician analyzes the sensor.
As illustrated in
Each assembly 205 and interface 210 may have one or more failure modes 225 causing one or more symptoms 230 which may be detectable either by a user of the complex system 200, by an assembly 205 of the complex system 200 or a combination thereof. The failure mode 225 of an assembly 205 generally follow the standard failure modes 170 for the type of assembly 205. For example, any sensor has at least one input (e.g., a power source, control signal, etc.) and at least one output (i.e., the output of the sensor). The standard failure modes for the sensor may include, for example, an input not being received, an input failing high, an input failing low, an output failing high, and output failing low, or no output. In other words, the failure mode 225 of an assembly 205 can vary depending upon whether an upstream assembly 205 has failed (i.e., a signal was not sent by another assembly 205 or a signal sent by another assembly 205 is out of range) or whether the particular assembly 205 itself has failed.
As illustrated in
As illustrated in
The processor 115 of the model building system 100 then processes each function model 140 and extracts from each function model 140 each input and each output to the assembly 205 associated with the function model 140 as well as the function(s) corresponding to the function model 140. (Step 320). As discussed above, the function models 140 may be models created in Matlab, Simulink, Unified Modeling Language (UML), automotive open system architecture (AUTOSAR), or the like. In Matlab, for example, the function model 140 may be a drawing which illustrates the function of the respective assembly 205 as well as the input and output of the respective assembly. In this example, the processor 115 may convert the Matlab based drawing into an XML file and parse the XML file in order to extract the function(s), input(s) and output(s) of each respective function model 140.
The processor 115 of the model building system 100 then processes each health and condition indicator model(s) 150 and extracts from each health and condition indicator model 150 each input and each output to the assembly 205 associated with the respective health or condition indicator 235. (Step 330). The health and condition indicator model(s) 150 may be models created in Matlab, Simulink, Unified Modeling Language (UML), automotive open system architecture (AUTOSAR), or the like. In Matlab, for example, the model may be a drawing which illustrates the function of the respective assembly 205 as well as the input and output of the respective assembly 205. In this example, the processor 115 may convert the Matlab based drawing into an XML file and parse the XML file in order to extract the function(s), input(s) and output(s) of each respective function model.
The processor 115 then builds a dependency diagnostic model based upon the data extracted from the function models 140, the health and condition indicator models 150, and the program data dictionary 160. (Step 340). The processor 115 builds the dependency diagnostic model by determining the interdependencies between the health and condition indicators 235 output by the complex system 200 and each assembly 205 of the complex system 200. As discussed above, when a health management system is coupled to a complex system 200, the health management system may receive any health indicators (such as DTCs) that have been generated and query the complex system 200 for condition indicators (such as PIDs). Accordingly, the processor 115 builds the dependency diagnostic model utilizing each health indicator and each condition indictor as entry point into the dependency diagnostic model. The processor 115, based upon the data extracted from the function models 140 and the health and condition indicator models 150 determines how each assembly 205 is linked to each health and condition indicator 235. As discussed above, each function model 140 and health and condition indicator model 150 includes an indication of every input and output corresponding to the model. The processor 115 traces through each model 140 and 150 to link each assembly 205 of the complex system 200 connected to the health or condition indicator 235 utilizing the program data dictionary 160 to account for any changes in the naming conventions used in any of the models 140 and 150. In other words, each health and condition indicator 235 in each health and condition indicator model 150 can be linked to the assemblies 205 responsible for generating the health and condition indicator 235 by tracing through the inputs and outputs of the assemblies 205 defined in the function models 140. For example, wheel speed sensors produce a signal reporting the speed that each wheel is spinning on a vehicle. An antilock brake system uses the reported values from the wheel speed sensors to determine if one or more wheels is locked (stopped from spinning) while braking is applied. If so, the antilock brake system automatically engages and disengages the brakes to keep the vehicle from skidding. Failure of one or more wheel speed sensors can render the antilock brake system unstable, disabling it from use, allowing the vehicle to skid. Accordingly, a condition indicator indicating an issue with, for example, an antilock brake system would be connected to the wheel speed sensor in dependency diagnostic model so that the issue with the antilock brake system could be easily diagnosed.
The result of the initially built dependency diagnostic model in Step 340 is a database which lists all monitored systems, and all possible propagation paths of failures in the complex system which result a health indicator being output by the complex system. In one embodiment, for example, the processor 115 may generate a database or tree type data structure for the generated model for each health and condition indicator 235 as the processor 115 traces through the function models 140 and the health and condition indicator models 150. However, the processor 115 may generate a data structure for the generated model in any manner which includes all monitored systems, their failure modes and all possible propagation paths of failures in the complex system.
The processor 115 may then optimize the generated model based upon the standard failure mode models 170 and propagation rules 180. (Step 350). The processor 115 can optimize the generated model by using the standard failure mode models 170 and propagation rules 180 to filter out dependency links that do not reflect the actual propagation of failure symptoms in the complex system 200.
In one embodiment, for example, the processor 115 determines the failure modes 225 for each assembly based upon an assembly type for each assembly. When the complex system is a vehicle, for example, the assembly types may include sensors, motors, valves, pumps, controllers, displays, radios, or the like. In one embodiment, for example, the processor 115 may determine the assembly type for each assembly 205 of the complex system 200 based upon a name of the assembly associated with each function model 140. For example, in an automatic environment, assembly names starting with the letter Y are typically sensors and assembly names starting with the letter A are typically valves.
The standard failure mode models 170 for the failure modes 225, as discussed above, include data on how each assembly 205 fails with respect to its own failures as well as the respective assembly's respond to being connected to another assembly 205 having a failure. Using the same example above, a wheel speed sensor which is coupled to an antilock brake system could fail due to a variety of reasons. For example, the sensor itself could fail, or one or more components downstream from the sensor, such as power systems, could completely fail or be outputting values out of range which is causing the wheel speed sensor to output a value out of range or not at all. The optimization in Step 350 correlates condition indicators with the failure modes 225 using the standard failure mode models 170 to simplify the diagnosis process. For example, suppose a power system connected to the wheel speed sensor, which is connected to the antilock brake system, is outputting a value out of range. This may cause an antilock braking system to output a health indicator indicating an error. The processor 115 based upon the function models, health and condition indicator models and program data dictionary may have generated a dependency diagnostic model in Step 340 may list dozens of systems and sub systems of the complex system which may be connected to perform the functions of the antilock brake system which could ultimately result in the identical health indicator being output by the complex system. By correlating one or more condition indicators, which a diagnostic system can request the value for from the complex system, indicating a value (i.e., output voltage) related to the power system with the standard failure modes of the antilock brake system, the wheel speed sensor and the underlying power system, the diagnosis process is dramatically simplified as many of the possible systems or subsystems which could be causing the same health indicator can be eliminated as suspects for causing the fault based upon the condition indicators and the fail modes.
As discussed above, the propagation rules 180 codify how errors propagate through the complex system. The errors may be categorized though the propagation rules. The propagation rules may define a category for each failure mode and each health indicator and the establish links therebetween as well as links to possible users complaints which do not result in a specific health indicator being output. If the category for a specific health indicator being output by a complex system cannot be matched with the same category for a failure mode of a specific system or subsystem, the specific system or subsystem can be eliminated as a possible cause of the health indicator.
As the propagation rules categorize the failure modes, customer complaints and health indicators, and the processor 115 establishes links therebetween as indicated by arrows 400, systems and subsystems of the complex system can easily be eliminated from causing a health indicator or a complaint. For example, as seen in
Accordingly, by optimizing the dependency diagnostic fault model to correlate the condition indicators with the failure modes and categorizing the failure modes, complaints and health indicators, the resulting optimized diagnostic fault model can be utilized to quickly and accurately diagnose a complex system, dramatically reducing the cost of maintenance for the complex system.
The optimized dependency diagnostic model includes listings of all Failure Modes in the System, their Corrective Actions and listings of all Health Indicators, Functions and Operator Complaints associated with each Failure Mode.
While at least one exemplary embodiment has been presented in the foregoing detailed description of the invention, it should be appreciated that a vast number of variations exist. It should also be appreciated that the exemplary embodiment or exemplary embodiments are only examples, and are not intended to limit the scope, applicability, or configuration of the invention in any way. Rather, the foregoing detailed description will provide those skilled in the art with a convenient road map for implementing an exemplary embodiment of the invention. It being understood that various changes may be made in the function and arrangement of elements described in an exemplary embodiment without departing from the scope of the invention as set forth in the appended claims.
This application claims the benefit of PCT application PCT/US16/18894, filed Feb. 22, 2016, which claims the benefit of U.S. provisional patent application Ser. No. 62/119,438, filed Feb. 23, 2015, the entire contents of which are incorporated by reference herein.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US2016/018894 | 2/22/2016 | WO | 00 |
| Number | Date | Country | |
|---|---|---|---|
| 62119438 | Feb 2015 | US |
