Patent Application
20100162027
The present invention generally relates to health management and, more particularly, to a system and method of determining the capabilities of a system, such as a vehicle and/or one or more systems within the vehicle, using various health-related data.
Various systems, such as various types of vehicles and the systems and subsystems that comprise the vehicles, may be subject to potentially severe environmental conditions, shock, vibration, and normal component wear. These conditions, as well as others, may have deleterious effects on vehicle operability. These deleterious effects, if experienced during operation, could leave little time for corrective actions. Hence, most notably in the context of vehicles, health monitoring/management systems are increasingly being used. Vehicle health monitoring/management systems monitor various health-related characteristics of the vehicle. Such operational health characteristics may, in some instances, be further decomposed to the health characteristics of major operational systems and subsystems of the vehicle.
In addition to monitoring vehicle health status, it would be desirable to determine the potential effect that a potentially degraded system, subsystem, or component may have on the overall capabilities of the vehicle, and supply information of these potential effects so that a system may, if needed, reconfigure itself to accommodate such a degraded system, subsystem, or component. For example, if a fault degrades vehicle engine thrust to a point where the vehicle will be unable to successfully complete its mission, mitigating actions (such as abort or re-plan) may be needed to minimize the impact of the fault. Heretofore, such capabilities have not been implemented with adequate precision and/or without undue complexity.
Hence, there is a need for a system and method that determines, with adequate precision and without undue complexity, the potential effect(s) that a degraded system, subsystem, or component may have on the overall capabilities of a vehicle (or other system), and supply information of the potential effect(s) so that mitigating actions may be taken. The present invention addresses at least this need.
In one embodiment, and by way of example only, a method of determining a capability of a system includes representing a capability of the system as at least a lowest-level capability that is quantifiably impacted by one or more system faults, when present, and by no other capabilities of the system. The quantifiable impact of the one or more faults on the lowest-level capability is represented as a function of the one or more system faults on the lowest-level capability. A value of the capability of the system is computed from at least the one or more system faults that are present.
In another exemplary embodiment, method of determining a capability of a system includes representing a capability of the system as at least a lowest-level capability that is quantifiably impacted by one or more system parameters and by no other capabilities of the system. The quantifiable impact of the one or more system parameters on the lowest-level capability is represented as a function of the one or more system parameters on the lowest-level capability. A value of the capability of the system is computed from at least the one or more system parameters that are present.
In another exemplary embodiment, a method of determining capabilities of a system includes representing capabilities of the system as a directed acyclic graph that includes one or more higher-level capabilities and a constant capability. Each higher-level capability is quantifiably impacted by the constant capability or one or more other higher-level capability. A value of each higher-level capability is computed from the constant capability or the one or more other higher-level capabilities.
In yet a further exemplary embodiment, a vehicle health capabilities system includes a plurality of sensors and system health reasoner means. Each of the plurality of sensors is operable to sense a vehicle parameter and supply sensor data representative thereof. The system health capability reasoner means has capability data stored therein. The capability data are representative of a system capability that is represented as at least a lowest-level capability. The lowest-level capability is quantifiably impacted by one or more system faults and by no other capabilities of the system, and the quantifiable impact of the one or more faults on the lowest-level capability is represented as a function of the one or more system faults on the lowest-level capability. The system health capability reasoner means receives the sensor data, determines whether one or more of the system faults is present, determines the quantifiable impact of each fault that is present on the lowest-level capability, and computes a value of the capability of the system from at least the lowest-level capability.
Other desirable features and characteristics of the inventive health capability determination system and method will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and the preceding background.
The present invention will hereinafter be described in conjunction with the following drawing figures, wherein like numerals denote like elements, and
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. Furthermore, there is no intention to be bound by any theory presented in the preceding background or the following detailed description. In this regard, although this detailed description focuses mainly on use of the invention in vehicles, it will be appreciated that its use is not limited to such an end-use environment, but may be implemented in numerous and varied end-use environments, and with numerous and varied systems in numerous and varied end-use environments.
Referring to
Returning again to the description, the sensors 102 are each operable to sense a parameter and supply sensor data representative thereof. It will be appreciated that the number and type of sensors 102 may vary depending, for example, on the particular type of vehicle in which the system 100 is installed. Moreover, a plurality of the sensors 102 may be used to sense parameters in the same vehicle subsystem. For example, a plurality of the sensors 102 may be used to sense a plurality of parameters in one of a plurality of non-illustrated engines. No matter the particular number and type of sensors 102 used and the number and type of parameters that are sensed, each sensor 102 supplies sensor data representative of the sensed parameter to the processing subsystem 104.
The processing subsystem 104, which may also be referred to herein as a system health capability reasoner (SCHR), is coupled to receive the sensor data from each of the sensors 102. The processing subsystem 104 is configured to process the sensor data in a manner that allows of one or more capabilities of the vehicle 150 to be determined and, if needed, mitigating actions that should be implemented. More specifically, the processing subsystem 104 computes one or more capabilities of the vehicle 150 and, based on this computation, determines what mitigating actions, if any, should be implemented. To implement this functionality the processing subsystem 104 implements a plurality of modules. These modules, at least in the depicted embodiment, include a health classification module 106 and a capability and action reasoning module 108, each of which will be described in more detail further below.
Before describing the health classification module 106 and the capability and action reasoning module 108, it is noted that the processing subsystem 104 may be implemented, as needed or desired, using hardware, software, firmware, or various combinations thereof. In this regard, such hardware may include, for example, one or more general-purpose or application-specific programmable processors, suitable memory (separate from or integral to the processor(s)), and/or suitable input/output (I/O) devices. Moreover, the health classification module 106 and the capability and action reasoning module 108 will each be described in the context of implementing a plurality of functional modules or blocks. Similarly, each of these functional modules or blocks may, as needed or desired, be implemented using hardware, software, firmware, or various combinations thereof. Furthermore, the health classification module 106 and the capability and action reasoning module 108 may each implement functional modules or blocks in addition to those depicted in
Turning now to a description of the health classification module 106, it is seen that this module 106 implements at least a plurality of subsystem classifiers 112 (e.g., 112-1, 112-2, 112-3 . . . , 112-N) and a system level diagnostic reasoner 114. The subsystem classifiers 112 are each associated with a particular vehicle subsystem, and each receives sensor data supplied from one or more of the sensors 102. More specifically, each subsystem classifier 112 receives sensor data from the one or more sensors 102 that sense parameters associated with the same subsystem with which the subsystem classifier is associated. For example, if the first subsystem classifier 112-1 is associated with one or more engines, then it will receive sensor data from the one or more sensors 102 that sense engine-related parameters, if the second subsystem classifier 112-2 is associated with an avionics systems, then it will receive sensor data from the one or more sensors 102 that sense avionics system-related parameters, and so on. The subsystem classifiers 112, based on the sensor data each receives, and implementing any one of numerous known algorithms, determine and classify (e.g., compute) vehicle faults at the subsystem level.
The system level diagnostic reasoner 114 communicates with each of the subsystem classifiers 112. The system level diagnostic reasoner 114 determines and classifies vehicle faults at the system level. That is, the system level diagnostic reasoner 114 uses sensor data and/or classifier-supplied data associated with all of the subsystems and, implementing any one of numerous known algorithms, determines and classifies (e.g., computes) vehicle faults at the system level.
The computed vehicle subsystem faults and the computed vehicle system faults together constitute what is referred to herein as the computed system health data. The computed system health data not only indicate the presence of particular faults, but a computed value associated with a particular fault. For example, in the context of a vehicle, the computed health system data supplied by the health classification module 106 will not only indicate that a low tire pressure fault is present, but will additionally include the actual tire pressure value. It will be appreciated that the computed system health data may be used for various diagnostic and prognostic purposes, as is generally known in the art. In the SHCR 104, however, the computed system health data are also (or instead) used in the capability and action reasoning module 108, an embodiment of which will now be described.
The capability and action reasoning module 108 includes at least a capabilities computation module 116, a capabilities comparison module 118, and an action computation module 122. The capabilities computation module 116 receives, or at least selectively retrieves, the computed system health data from the health classification module 106. The capabilities computation module 116, based on these data, computes one or more capabilities of each of the various vehicle subsystems, at least some of which may impact overall vehicle mission or a particular aspect of the overall vehicle mission. The methodology that the capabilities computation module 116 implements to compute these capabilities will be described in more detail further below. The capabilities computed by the capabilities computation module 116 are supplied to, or selectively retrieved by, the capabilities comparison module 118.
The capabilities comparison module 118, using the computed capabilities supplied to or selectively retrieved from the capabilities computation module 116, compares the computed capabilities to one or more vehicle mission requirement values, preferably before, during, and after a particular mission. The capabilities comparison module 118, based on the comparison of the overall vehicle mission capability and the vehicle mission requirement value(s), determines if a corrective action should be initiated. If it is determined that a corrective action should be initiated, the action computation module 122 computes the particular mitigating action (or actions) that should be initiated. More specifically, the action computation module 122 computes the mitigating action(s) based on the computed capabilities and the vehicle mission requirement value(s). The capabilities comparison module 118 may also receive data representative of future vehicle mission requirements, and may compare the computed capabilities to the future vehicle mission requirements to determine which, if any, of the future vehicle mission capabilities may or may not be met.
As
The communications module 126, at least in the depicted embodiment, is in operable communication with the capabilities computation module 116, the capabilities comparison module 118, and the action computation module 122. The communications module 126 is configured to at least selectively transmit data representative of, for example, one or more of the computed capabilities, the determination of whether a corrective action should be initiated, and the computed mitigating action(s), to a remote location. In the context of this disclosure, the remote location may include one or more other systems on-board the vehicle 150, one or more systems disposed remotely from the vehicle 150, or combinations of both.
In addition to the above, the capability and action reasoning module 108 may also generate and supply appropriate commands to one or more display devices 120 (only one shown for clarity). The display device(s) 120, if included, provides visual feedback that is at least representative of one or more vehicle mission requirement values. The particular type of display device(s) 120 used and the particular display paradigm may vary. In one particular embodiment a color variation paradigm is used. For example, if a current vehicle mission requirement value is a vehicle speed of at least 500 km/hr, and the calculated vehicle speed capability is 1000 km/hr, then the display device 120 may be commanded to display a green color. If the calculated vehicle speed capability is below a first threshold value, such as 800 km/hr for example, then the display device 120 may be commanded to display a yellow color. If the calculated vehicle speed capability is below 500 km/hr (i.e., the current vehicle mission requirement), then the display device 120 may be commanded to display a red color. As with the variation in indicator paradigms, the particular colors and numbers of colors used may also vary. A description of various other display paradigms and various other types of information that may be displayed on the display device(s) 120 is provided further below.
Referring now to
As used herein, a higher-level capability is one that is quantifiably impacted by at least one other capability. A lowest-level capability is one that is not quantifiably impacted by any other capabilities. Rather, a lowest-level capability is one that is quantifiably impacted by a system fault (e.g., appropriate system health data) or system parameter (e.g., an operational parameter such as speed, fuel level, etc.). It will be appreciated that in some instances a lowest-level capability may not be impacted by a system fault or parameter. Such lowest-level capabilities are referred to herein as constant capabilities. It may thus be seen that in the directed acyclic graph 200 of
The directed acyclic graphs that comprise the capability data used in the capabilities computation module 116 may vary in structure from that depicted in
Before proceeding further, it was noted above that a lowest-level capability may also, in some instances, be a constant capability. That is, a capability that is not impacted by a system fault or parameter. For completeness, a constant capability 212 is also depicted in phantom in
A relatively simple, yet illustrative example of capability data 200 that may be used by the capabilities computation module 116 is depicted in
It will be appreciated that individual engine thrust capability 304-1, 304-2, 304-3 may be impacted by any one of numerous faults and/or parameters, or various combinations of these numerous faults and parameters. As such,
It was additionally noted above that the capabilities comparison module 118 compares the computed capabilities (e.g., the mission-related capabilities) to one or more vehicle mission requirement values and, based on this comparison, determines if a corrective action should be initiated. The manner in which this comparison is implemented may vary, but in one particular embodiment the computed capabilities are compared to appropriate vehicle mission requirement value data. These data may, at least in one embodiment, be stored in a table format. An example of one such table format is depicted in
The exemplary table 400 depicts vehicle mission requirement value data associated with two different operational phases of a vehicle. In this case, the vehicle is a UAV-type vehicle that is controlled to implement at least a Launch Phase and a Reentry Phase. The depicted table 400 includes time data 402, mission-related capability category data 404, lower level data 406, and upper level data 408. It will be appreciated that these particular data are merely exemplary of one particular embodiment and could be varied, as needed or desired. Similarly, the data values depicted in
The time data 402 indicates at what point in time, during vehicle operation, each operational phase is scheduled to commence. In the depicted embodiment the Launch Phase, as may be appreciated, commences at time zero (e.g., 00:00:00) and the Reentry Phase begins 1 hour and 50 minutes (e.g., 01:50:00) after commencement of the Launch Phase. The capability category data 404 include entries for each of the particular high-level/mission-related capabilities associated with each phase. In the depicted embodiment, two high-level/mission-related capabilities are associated with each phase. For the Launch Phase the two high-level/mission-related capabilities are Total Thrust and Avionics, and for the Reentry Phase the two high-level/mission-related capabilities are Thermal Heat Load and Avionics.
The lower level data 406 and upper level data 408 represent the minimum and maximum values, respectively, for each high-level/mission-related capability during each launch phase. For this particular example, there are only lower level data 406. As may be seen, the minimum total thrust value during the Launch Phase of the vehicle is 100,000 lbs, and the minimum number of operating avionics channels is one (1). During the Reentry Phase, the minimum Thermal Heat Load is 50 BTU/ft2, and the minimum number of operating avionics channels is again one (1).
In addition to or instead of a mission requirement table 400, some mission requirements may be represented as a logical combination of a plurality of capabilities. In such embodiments, the determination of whether the appropriate mission requirement is met is based on the logical outcome of the logical combination. An example of such an embodiment is depicted in
Though not depicted in
Before proceeding further it is noted that the capability data and the vehicle mission requirement value data may be stored in memory that forms part of the processing subsystem 104 or in memory external to the processing subsystem 104. Additionally, the capability data and vehicle mission requirement value data may be stored in shared memory (within or separate from the processing subsystem 104) or may be stored in separate memory.
Moreover, it was also previously noted that the processing subsystem 104 may command the display device(s) 120 depicted in
The processing subsystem 104 may also selectively command the display device(s) 120 to display the above-described mission requirement table(s) and, either automatically or in response to input from a user, selectively expand and collapse one or more of the displayed mission requirement tables based, for example on a particular mission phase. In some embodiments, the mission phase may be highlighted. When one or more mission requirements tables are displayed, the processing subsystem 104 may selectively command the display device(s) 120 to highlight any rows in the displayed mission requirement tables based in whether the particular capability is met or unmet.
In addition to the above, the processing subsystem 104 may selectively command the display device(s) 120 to display a plot of various vehicle/system requirements versus time (or mission phase) overlaid with actual vehicle/system capabilities, and/or display various vehicle/system requirements and capabilities using synoptic diagrams, and/or display at least portions of one or more directed acyclic graphs 200.
Having described the general structure and function of the vehicle health capabilities system 100, an exemplary process implemented by the system 100 for determining one or more mission-related capabilities of a vehicle is depicted in
Upon initiating the process 600, the processing subsystem 104, using the sensor data from the sensors 102, computes the system health data (602). Each of the lowest-level capabilities are then computed from the system health data (604) and, when appropriate, each of the higher-level capabilities are computed from the lowest-level capabilities (606). The values of each of the mission-related capabilities (whether higher-level or lowest-level capabilities) that were just computed are then compared to appropriate mission requirement values or supplied to appropriate combination logic (608). Based on this comparison (or logic combination), a determination is made as to whether one or more mitigating actions are needed (612). If so, then the mitigating actions are computed and implemented (614) and the process repeats. If no mitigating actions are needed, then the process repeats.
The system and method described herein provide for the determination of the potential effect(s) that a degraded system, subsystem, or component may have on the overall capabilities of a vehicle (or other system), and any mitigating actions that may need to be taken.
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 invention was made with Government support under F33615-00-D-3053 awarded by the Air Force Research Laboratory (AFRL). The Government has certain rights in this invention.
