Condition-based maintenance system and method

Abstract

A maintenance system has an input device and logic to receive and store data indicative of a CBM element, CBM sub-element, a failure mode related to the CBM sub-element, a failure effect, and a failure consequence, via the input device. The logic further displays the received data to a display device in response to a first user input and displays a plurality of logical selectable input boxes corresponding to condition-based maintenance (CBM) queries that may be selected in relation to the failure mode.

Description

CROSS REFERENCE

This application claims priority to U.S. Provisional Application No. 60/813,856, entitled “Condition-Based Maintenance System and Method,” filed on Jun. 15, 2006, which is incorporated herein by reference.

BACKGROUND

Large entities, e.g., large corporations and/or the government, typically have large fleets of vehicles and/or other equipment in use. Managing large fleets of vehicles and/or equipment necessarily requires identification of what maintenance to do in order to ensure that the vehicles and/or equipment are ready for use when needed.

SUMMARY

A maintenance system in accordance with an embodiment of the present disclosure comprises an input device and logic configured to receive and store data indicative of a condition-based maintenance (CBM) element, a failure mode related to the CBM element, a CBM sub-element, and a failure effect, via the input device. The logic is further configured to display the received data to a display device in response to a first user input and display a plurality of logical selectable input boxes corresponding to CBM queries that may be selected in relation to the failure mode.

A maintenance method in accordance with an embodiment of the present disclosure comprises the steps of a maintenance method, comprising the steps of: receiving data indicative of a CBM element analysis type or a function/functional failure analysis type from a user and displaying a reverse engineering graphical user interface (GUI) or a function/functional failure GUI based upon the data received.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention can be better understood with reference to the following drawings. The elements of the drawings are not necessarily to scale relative to each other, emphasis instead being placed upon clearly illustrating the principles of the disclosure. Furthermore, like reference numerals designate corresponding parts throughout the several views.

FIG. 1 is a block diagram illustrating a condition-based maintenance (CBM) team in accordance with an exemplary embodiment of the present disclosure.

FIG. 2 is a block diagram illustrating the CBM system of FIG. 1.

FIG. 3 illustrates an exemplary CBM entrance Graphical User Interface (GUI) of the CBM System of FIG. 2.

FIG. 4A depicts an exemplary CBM Main Menu GUI of the CBM system of FIG. 2.

FIG. 4B depicts an exemplary CBM Analysis Selection Box GUI of the CBM system of FIG. 2.

FIG. 5A depicts an exemplary CBM Element Analysis Information Worksheet GUI of the CBM system of FIG. 2.

FIG. 5B depicts an exemplary Function/Functional Failure Analysis Information Worksheet GUI of the CBM system of FIG. 2.

FIG. 6 depicts an exemplary CBM Analysis GUI of the CBM system of FIG. 2.

FIG. 7 depicts an exemplary Evaluation of Current Failure Management Strategy GUI of the CBM system of FIG. 2

FIG. 8 depicts a List of CBM Techniques GUI of the CBM system of FIG. 2.

FIG. 9 depicts an Evaluation of CBM Method GUI of the CBM system of FIG. 2.

FIG. 10 is a flowchart depicting exemplary architecture and functionality of the CBM logic depicted in FIG. 2.

DETAILED DESCRIPTION

Embodiments of the present disclosure generally pertain to systems and methods for identifying and analyzing condition-based maintenance that may be technically appropriate and safe/cost effective. Such a system enables a user to identify and analyze existing data in an organization, e.g., data from operating procedures, past identified failure modes, and/or other maintenance schedules or the like, to determine failure modes and analyze whether condition-based maintenance may be appropriate for addressing those failure modes. Such a system is hereinafter referred to as a “Condition-Based Maintenance” system (CBM System).

The CBM system has a CBM GUI that captures data provided by a plurality of team members, hereinafter referred to as a “CBM team,” corresponding to a technical scope of work. The CBM system stores the captured data, and the CBM team uses the captured data in an analysis to determine the appropriate condition-based maintenance, if any, for managing the identified failure mode. In this regard, the most technically appropriate and safe/cost effective course may be to employ an automatic detector or to have an individual perform a task for determining whether a potential failure condition exists.

Note that the term “Condition-Based Maintenance” refers to maintenance that is performed “on the condition” that a potential failure condition has been detected, e.g., an increase in vibration, increase in heat, and these phenomena can be detected using sophisticated monitoring devices or the human senses. For example, in the aerospace field, a vibration detector may be placed at or near a bearing in an airplane to determine if its vibration levels have increased above an acceptable threshold. If the vibration has increased above the threshold, the detector provides the evidence necessary to indicate that maintenance is required.

As described hereinabove, the present system is for one that has reliability-centered maintenance (RCM) data, e.g., failure modes and effects analysis data along with consequence assessment and task analysis, but if that data is deficient or nonexistent, then one can use the described process to identify where condition-based maintenance is technically appropriate, and safe/cost effective.

FIG. 1 illustrates a condition-based maintenance (CBM) system 100 in accordance with an exemplary embodiment of the present disclosure. The CBM system 100 comprises a CBM device 107 and a visual device 110.

In one embodiment, the CBM device 107 is a computing device, e.g., a personal computer or a laptop computer. Furthermore, the visual device 110 is preferably a projection screen, which is described further herein.

A facilitator 101 controls the CBM system 100. The facilitator 101 requests data corresponding to the scope of a particular CBM analysis, which is described in more detail hereafter, and a CBM team comprising a plurality of team members 102-106 preferably communicates data corresponding to the requests of the facilitator 101. The number of team members 102-106 is merely an exemplary number and other numbers of team members are possible in other embodiments.

As the facilitator 101 queries the CBM team members 102-106, the team members 102-106 provide information corresponding to the queries of the facilitator 101. The facilitator 101 enters data corresponding to such information provided from the team members 102-106 into the CBM device 107.

Furthermore, as the facilitator 101 enters the data into the CBM system 100, the CBM device 107 communicates the entered data to the visual device 110. Such process is described in more detail hereafter. The facilitator 101 and the team members 102-106 are hereinafter referred to as the “CBM team.”

The facilitator 101 is an individual knowledgeable and well versed in the CBM process. However, the facilitator 101 may not be knowledgeable in the technical scope of the area that is being analyzed by the CBM team.

The team members 102-106 comprise a group of individuals who are experts in a particular technical area that has been selected for a CBM analysis. For example, if the scope of the analysis pertains to the aerospace industry, the team members 102-106 may comprise a system engineer, a mechanic, a maintenance person, a person responsible for technical publications, a maintenance test pilot, an instructor pilot, a crew member, and/or an original equipment manufacturer (OEM). Such a CBM team comprising the members 102-106 provides a knowledge base relative to the technical area that is being analyzed under the CBM process.

Note that during the course of a CBM analysis, there may be data identified that the team members 102-106 are unable to provide. In such a scenario, the CBM system 100 retains information corresponding to the data for a complete analysis, so that such data may be sought from other sources, e.g., other experts not on the team, subsequent to the current CBM system session.

Prior to initiating the CBM analysis via the CBM device 107, the facilitator 101 preferably compiles an operating context, described herein with reference to FIG. 2. Such an operating context orients the CBM team, stimulates brainstorming activities, outlines system characteristics and operating expectations in the system's environment, and serves as a baseline source of information and reference for future use, for example, in auditing and/or reporting.

To further narrow the analysis subject matter to an area that can be analyzed, the facilitator 101, alone, or in conjunction with the team members 102-106 may identify a scope of the CBM analysis related to the operating context. Thus, if the operating context centers on the flight control system of a helicopter, such an analysis can be broken down into two exemplary areas that may need separate CBM analyses in order to fully explore the maintenance related to the area. For example, the flight control system may comprise cockpit flight controls to the upper flight control actuators and swashplates to the rotor blades as distinct areas to address. Therefore, the scope of a particular CBM analysis might be aimed at the cockpit flight controls to the upper flight control actuators only.

Prior to assembling the CBM team, the facilitator compiles the operating context related to the scope of the analysis that is to be performed by the CBM team. When the CBM team assembles, the team members 102-106 identify a plurality of CBM elements corresponding to the operating context. A “CBM Element” may refer to a task that was taken from an organization's maintenance schedules that may be identified for the particular operating context. For example, if the scope of the CBM analysis is the power train system of an aircraft, the CBM element identified may be a continuous maintenance schedule. CBM sub-elements of the CBM element, i.e., particular checks that may be performed continuously, may be a check for a particular malfunction, e.g., a ramp and cabin check every thirty minutes during flight to check for vibration.

Once a CBM element has been identified, the team members 102-106 then identify sub-elements and then the failure modes corresponding to the identified CBM sub-elements. As the team members 102-106 identify the failure modes associated with the scope of the CBM analysis, the facilitator 101 enters data to the CBM system 100 indicative of the information provided by the CBM team.

Note that the failure modes correspond to a particular CBM sub-element. For instance, in the example provided, the CBM element is a ramp and cabin check every thirty minutes during flight to check for excessive vibration, the CBM sub-element is feeling the roof of a helicopter in the area of the synchronizing shaft hanger bearing for evidence of excessive vibration, and the failure mode may be any synchronizing shaft hanger bearing wears due to normal use. In this regard, the ramp and cabin check every thirty minutes would be a condition-based maintenance schedule for managing such an issue. Thus, the failure modes identify what may cause the condition related to the CBM element described hereinabove.

After each corresponding failure mode is identified, the CBM team identifies a corresponding failure effect. In this regard, the team members 102-106 provide information relating to the effects of each of the modes, and the facilitator 101 enters data indicative of such effects into the CBM device 107. Such information is displayed on the visual device 110 during the CBM process.

The visual device 110 may be, for example, a projection screen. As described herein, the CBM device 107 is configured to receive the described data. Furthermore, the device 107 is configured to display the data to the facilitator 101. In addition, however, the data is displayed to the visual device 110 while the facilitator is entering the data. The device 107 is further configured to increase the size of a data entry text box, discussed further herein, when the facilitator 101 is entering the data or while the CBM team is discussing the data that is to be entered. By allowing the text box to be enlarged, each team member 102-106 is able to visually capture the changes that are being made on a corresponding GUI, which facilitates the CBM process.

The failure effects provided by the team members 102-106 preferably comprise information regarding, for example, a description of the failure process from the occurrence of the failure mode and how it manifests, how the failure mode affects safety and/or environmental integrity, operational capability and mission readiness, what must be done to repair the failure, physical evidence by which failure can be recognized, specific operating restrictions, secondary damage that may be caused by the failure and impact of loss of function.

Furthermore, the effects of the failure modes for each operating phase can be provided. In the context of aircraft, the effects of the failure mode while the aircraft is on the ground, at take-off, in-flight, landing, and/or hovering, might be described. This information is also entered into the CBM device 107 by the facilitator 101 and displayed to the visual device 110.

Once failure modes and effects have been established for each identified CBM sub-element, the CBM team analyzes each failure mode to determine failure consequences. A failure consequence refers to how a failure mode matters to an organization. For example, the loss of one redundant hydraulic system in an aircraft might have operational consequences because it causes the aircraft, due to operating procedures, to terminate the flight.

In one embodiment, the CBM system 100 further comprises an action item recipient device 109. The recipient device 109 is communicatively coupled, via a network 108, to the CBM device 107, which is described further herein.

During the course of the CBM analysis, the CBM team may determine that additional information is needed to complete the CBM analysis. As will be described further herein, during the CBM analysis, the team may identify a particular potential failure condition; however, the CBM team may not necessarily be able to identify, for example, the potential failure condition point (“P”) or the functional failure point (“F”) so that a P-F interval can be calculated for the potential failure condition. In this regard, an individual who is not a member of the CBM team may need to be consulted regarding the P or the F.

In such a case, the CBM device 107 may generate an electronic notification to be delivered to a recipient (not shown) that details an “action item,” e.g., calculation or determination of a P or F. The CBM device 107 transfers the electronic notification of the action item to the recipient device 109, and the recipient can view the notification. The recipient may then respond, also via the network 108, to the CBM device 107. This is described further with reference to FIG. 6A.

FIG. 2 depicts an exemplary CBM device 107 of the present disclosure. The exemplary CBM device 107 generally comprises a processing unit 204, an output device 224, an input device 208, a display device 210, and a projection device 212.

The CBM device 107 further comprises CBM logic 214 and a CBM database 216, which can be software, hardware, or a combination thereof. In the exemplary CBM device 107, CBM logic 214 and CBM database 216 are shown as stored in memory 202.

The processing unit 204 may be a digital processor or other type of circuitry configured to run the CBM logic 214 by processing and executing the instructions of the CBM logic 214. The processing unit 204 communicates to and drives the other elements within the CBM device 107 via a local interface 206, which can include one or more buses. Furthermore, an input device 208, for example, a keyboard, a switch, a mouse, and/or other type of interface, can be used to input data from a user of the CBM device 107, for example, the facilitator 101, (FIG. 1), and display device 210 can be used to output data to the facilitator 101 (FIG. 1). In addition, an output device 224, for example, a universal serial bus (USB) port or other type network device connects the device 107 with the network 108 for communication with other network devices (not shown).

The CBM device 107 may further comprise a projection device 212 can be connected to the local interface 206, such as one or more buses. The projection device 212 may capture information that the facilitator 101 enters into the CBM device 107 via the input device 208 and display such captured data to the visual device 110.

In the exemplary CBM device 107 of FIG. 2, the CBM logic 214 and the CBM database 216 are shown, as indicated hereinabove, as being implemented in software and stored in memory 202. However, the CBM logic 214 and the CBM database 216 may be implemented in hardware, software, or a combination of hardware and software in other embodiments.

An exemplary input device 208 may include, but is not limited to, a keyboard device, serial port, scanner, camera, microphone, or local access network connection. An exemplary display device 210 may include, but is not limited to, a video display.

As noted herein, CBM logic 214 and the CBM database 216 are shown in FIG. 2 as software stored in memory 202. When stored in memory 202, the CBM logic 214 and the CBM database 216 can be stored and transported on any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this document, a “computer-readable medium” can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. Note that the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via for instance optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory.

As described hereinabove with reference to FIG. 1, the facilitator 101 prepares an operating context to direct the CBM analysis. Such an operating context 218 is stored in the CBM database 214 in memory 202. As discussed hereinabove, an “operating context” is preferably an in-depth description of a system under analysis and other attributes regarding a CBM analysis that the CBM team uses to begin its CBM analysis.

The CBM Database 216 further stores CBM technique data 223, information worksheet data 220, analysis data 221, and reports 222. The information worksheet data 220 is data that is entered into the Information Worksheet graphical user interface (GUI) described with reference to FIGS. 5A and B. Such information includes a description of CBM elements, failure modes, failure effects, and consequences (FIG. 5A) or such information includes a description of functions, functional failures, failure modes, failure effects and consequences (FIG. 5B).

The analysis data 221 is data that is entered into the CBM Analysis GUI described with reference to FIG. 6. Such information includes responses provided by the CBM team members 102-106 to questions posed on the CBM Analysis GUI.

The CBM technique data 223 refers to data indicative of processes or tasks that may be employed to determine whether a potential failure condition exists in need of maintenance, repair or otherwise. As an example, CBM techniques such as frequency analysis or broadband analysis may be employed to determine if there are threshold vibration levels that indicate a maintenance need. As another example, a heat strip or thermography may be employed to determine if there are temperature levels that indicate a maintenance need.

An exemplary entrance GUI 300 is depicted in FIG. 3. The exemplary CBM entrance GUI 300 comprises a “Condition-Based Maintenance” title 301 for identifying the CBM logic 214 and an “Enter” pushbutton 302. When 302 is selected by the user, e.g., a facilitator 101 (FIG. 1), the CBM logic 214 displays the CBM Main GUI 3800 depicted in FIG. 4A.

From the CBM Main GUI 3800 the user may begin a new analysis or select an existing analysis to modify or complete. If the user desires to begin a new analysis, the CBM Main GUI 3800 comprises an “Enter New Analysis” section 3802. The “Enter New Analysis” section 3802 comprises a new analysis name text field 3843 and an “Add” pushbutton 3844.

If the user desires to create a new CBM analysis, the user enters in an analysis identifier, i.e., any text selected by the user to identify the analysis, in the text box 3843 and selects the “Add” pushbutton 3844. Thereafter, any pushbutton 3812-3817, when selected, will display corresponding GUIs in which the user may enter new information related to the identifier.

When the user selects the “Add” pushbutton 3844, the CBM logic 214 displays an “Analysis Selection Box” GUI 51 such as is depicted in FIG. 4B. GUI 51 comprises an “Analysis Name” text box 3833 and a “Date Entered” text box 3835 that displays the identifier entered in text box 3843 (FIG. 4A) and the current date, respectively. In addition, GUI 51 comprises a “CBM Analysis Type” pull-down box 3834 and an “Enter” pushbutton 3836. The pull-down box 3834, when selected, gives the user options as to the type of analysis that the user desires to perform.

On one hand, the user may desire to identify CBM elements, as described hereinabove, and determine one or more failure modes associated with CBM sub-elements of a CBM element, hereinafter referred to as a “CBM Element Analysis.” For example, the CBM element identified may be an entity's continuous maintenance schedule, and a CBM sub-element of that schedule may be a task, e.g., checking for vibration of a bearing. Notably, a task within the continuous maintenance schedule may be to check a bearing for vibration. In this regard, the user identifies an opportunity from which a failure mode can be determined. Once the failure mode is determined, the user proceeds with the logic 214 to perform a CBM analysis, which is described further herein. The CBM analysis performed allows the user to identify whether or not a condition-based maintenance task is technically appropriate/cost effective.

On the other hand, the user may desire to identify functions and functional failures and perform an analysis to determine failure modes from the identified functions and functional failures, hereinafter referred to as a “Function/Functional Failure CBM Analysis.” Once the failure mode is determined from the functions and functional failures identified, the user proceeds with the logic 214 to perform a CBM analysis, which is described further herein. The CBM analysis performed allows the user to identify whether or not a condition-based maintenance task is technically appropriate/cost effective.

Thus, the “CBM Analysis Type” pull-down box 3834 (FIG. 4B) may display two options, when selected, including a CBM Element Analysis option and a Function/Functional Failure Analysis option.

When the user selects the “Enter” pushbutton 3836, the logic 214 re-displays the GUI 3800 depicted in FIG. 4A

If the user desires to revisit an existing CBM analysis, the user selects, via the input device 208, one of the analyses links 3804-3806 previously created with the CBM logic 214, e.g., “Upper Rotating Controls,” “Fuel,” or Hydraulics and PTU.” If the user selects an existing analysis link 3804-3806, the CBM logic 21-4 accesses any information stored as operating context data 218, CBM technique data 223, information worksheet data 220, analysis data 221, or reports 222, in the database 216. Thus, if the user thereafter selects one of a plurality of pushbuttons 3812-3819, the CBM logic 214 retrieves information stored in the database 216 corresponding to the selected analysis in accordance with the analysis identifier.

The “Analysis Details” pushbutton 3812, when selected, displays a menu (not shown) that enables access to portions of the Analysis Data 221. For example, the menu may provide analysis date, validation dates, the names and contact information of the CBM team, names and contact information of the validation team members, executive summary information, miscellaneous notes, and facilitator pre-analysis notes. The CBM Main GUI 3800 may be customized depending upon the technical area under analysis and/or how the CBM system 100 will be used.

The “Operating Context” pushbutton 3813, when selected, displays data indicative of the operating context data 218 (FIG. 2). Such data includes, but is not limited to, the scope of the analysis, the operating environment, e.g., desert or shipboard operations, theory of operation, list of current maintenance, and operating context concerns.

When the user selects the “Information Worksheet” pushbutton 3819, the logic 214 displays the “CBM Element Analysis Information Worksheet” GUI 500 or the “Function/Functional Failure Information Worksheet” GUI 2000, depending upon which CBM analysis type the user selected, with reference to FIG. 4B. In this regard, if the user selected a CBM Element Analysis type, the logic 214 displays GUI 500 depicted in FIG. 5A. Alternatively, if the user selected a Function/Functional Failure Analysis type, the logic 214 displays GUI 2000 depicted in FIG. 5B.

FIG. 5A allows a user to perform a CBM element analysis, as described hereinabove. The GUI 500 is used during the identification of each CBM element, CBM sub-element, failure mode, failure effect, and consequences associated with the failure mode. Note that the GUI 500 is for exemplary purposes only, and other GUIs in other embodiments of the CBM device 107 may be used to capture such data described.

In this regard, the facilitator 101 (FIG. 1) selects the Information Worksheet pushbutton 3819, and the CBM logic 214 displays to the display device 210 (FIG. 2) and correspondingly to visual device 110 (FIG. 1), the GUI 500. The GUI 500 is used in order to identify each CBM element, CBM sub-element, failure mode, failure effect and failure consequence by the CBM team during the CBM analysis.

The CBM Element Analysis information worksheet GUI 500 comprises a “CBM Element” pull-down box 432 and a corresponding CBM sub-element text box 550. The pull-down box 432, when selected, lists a number of options from which the user can select a CBM element, e.g., a 400 hour maintenance schedule or a continuous maintenance schedule. Other examples that may be in pull-down box 432 may be preflight, daily, 40-HR, 350-HR, 700-HR, special inspection, or corrosion inspection.

Note that the database 216 may be pre-populated with a plurality of CBM sub-elements associated with the CBM element selected, e.g., check vibration levels or check temperature, and the logic 214 may display in the text box 550 the first of the plurality. The user may then traverse the plurality using navigational pushbuttons 538-541. When the pushbutton 538 is selected, the CBM logic 214 (FIG. 2) displays data indicative of the first CBM sub-element of a plurality of CBM elements to the box 550. Further, when the button 541 is selected, the CBM logic 214 (FIG. 2) displays data indicative of the last CBM element. Buttons 539 and 540, when selected, incrementally scroll bi-directionally through the plurality of CBM sub-elements. Text box 542 shows the total number of records through which the user can scroll.

In addition, the GUI 500 comprises an “Add” pushbutton 512, and when selected, enables the user to enter data in the text box 550 corresponding to a new CBM sub-element. Such data entered into the text box 550 preferably describes an opportunity from which a failure mode can be reverse engineered in order to identify whether or not a condition-based maintenance task is technically appropriate/cost effective. These opportunities may be identified in an organization's existing documents, procedures or the like, e.g., in operating procedures, past identified failure modes, or by existing technology utilized in the particular equipment.

An identifier corresponding to the displayed CBM element description in pull-down 432 is displayed in box 723. Further, text box 542 displays the number of CBM elements in the plurality available for analysis.

Note that the pull-down box 432 enables the user to select the type of source for the CBM element. For example, the CBM element may be an Integrated Reliability-Centered Maintenance System flight manual (IRCMS FM), preflight procedures, daily procedures, 40-HR maintenance schedules, 350-HR phase maintenance schedules, 700-HR phase maintenance schedules, special inspection, current sensor, other, and/or additional. Notably, however, the CBM elements and the CBM sub-elements are identified from existing organizational documents, procedures, or the like. The failure modes are then reverse engineered from the CBM sub-elements.

As an example, a user may select as the CBM element “Other” from pull down menu 432. Other may mean that one of the CBM team has identified a CBM element for analysis for condition-based maintenance. The CBM element may be “ramp and cabin check every 30 minutes during flight to check for excessive vibration.”

The user associates with the selected CBM element one or more sub-elements by entering descriptive data in text box 550 and selecting the “Add” pushbutton 512. Thus, associated with the selected CBM element from the pull down menu 432 is the sub-element that the logic 214 identifies with a CBM sub-element identifier, e.g., “O-1-A,” as shown in text box 721. Note that, as described hereinabove, a CBM sub-element is an opportunity from which a failure mode can be reverse engineered in order to identify whether or not a condition-based maintenance task is technically appropriate and safe/cost effective.

As additional information is added regarding new CBM elements and CBM sub-elements obtained from one of the many sources in the pull down menu 432 and the text box 550, respectively, the CBM logic 214 stores such newly added information in information worksheet data 220 in the CBM database 216.

The CBM team identifies a plurality of failure modes and failure effects associated with each CBM sub-element. Thus, the CBM Element Analysis information worksheet GUI 500 further comprises a “Failure Mode Analysis” section 511 comprising failure mode editable text box 520 and a failure effect editable text box 522 for entering information defining a failure mode and a failure effect associated with the CBM sub-element currently displayed in text box 550.

As an example, a failure mode may be that “any synchronizing shaft bearing wears due to normal use,” and the user enters such information in box 520. An exemplary effect is “over time, bearing develops play that causes high-frequency vibration and is detectable by the crew,” which the user enters in box 522. Additional effects may be that the “pilot lands as soon as possible, the aviation unit maintenance (AVUM) replaces the bearing, and there is downtime to repair of one to two days.”

Buttons 555-558 behave substantially similar to those buttons 538-541 described hereinabove. Additionally, the facilitator 101 may select the “Add” pushbutton 534 and enter text in the failure mode text box 520 information corresponding to an additional failure mode identified by the CBM team during the analysis.

Furthermore, the CBM logic 214 associates each failure mode and effect identified, for example in box 520 and 522 with a unique identifier, such as “O-1-A-1.” Thus, the GUI 500 further comprises a text box 514 for displaying such unique identifier associated with the failure mode and effect corresponding to box 520 and 522. For example, boxes 723 and 721 exhibit the strings “O-1” and “O-1-A,” respectively, which identify the CBM element in pull-down box 432 and the CBM sub-element in text box 550, respectively.

Associated with each failure mode text box 520 and failure effect text box 522 are check boxes 516 and 518 associated with a “PL” pushbutton 599, also referred to herein as a “parking lot” and a “MR” pushbutton 598, also referred to herein as “mode remarks,” respectively. When the pushbutton 599 is selected, the logic 214 displays a window (not shown) having a text box (not shown) in which the user enters data indicative of issues that may need to be addressed related to the CBM analysis ongoing. If the user enters data in the text box, the logic 214 displays in check box 516 an identifier, e.g., a “check” symbol, to indicate that there are issues to be addressed.

Note that parking lot information may identify that there needs to be some action taken with respect to the identified failure mode in text box 520 before the CBM analysis can be performed on the failure mode. The parking lot data is described further herein.

When the pushbutton 598 is selected, the logic 214 displays a window (not shown) having a text box (not shown) in which the user enters data indicative of failure mode remarks from the user related to the CBM analysis ongoing. If the user enters data in the text box, the logic 214 displays in check box 518 an identifier, e.g., a “check” symbol, to indicate that there are remarks related to the failure mode.

The section 511 further comprises a “Current Failure Management Strategy” pushbutton 799 and an “Evaluation of Current Failure Management Strategy” pushbutton 798. The user selects pushbutton 799, for each failure mode identified, and the logic 214 displays a text box (not shown) in which the user enters data indicative of the current failure management strategy. When the user closes the text box, the logic 214 saves to memory as analysis data 221. In addition, the pushbutton 798, when selected, displays an “Evaluation of Current Failure Management Strategy” GUI 50 depicted in FIG. 7.

With reference to FIG. 7, GUI 50 comprises a plurality of check boxes 30-34. During the analysis, the user may evaluate the current failure management strategy identified via pushbutton 799. In this regard, if the mission must be aborted, the user checks check box 30 and if the mission may be aborted, the user selects check box 31. Further, if the mission can be completed but maintenance must be performed before the next flight, the user selects check box 32 and if the maintenance can be deferred until a part is received, the user selects check box 33. The GUI 50 may further have an editable check box 88 in which the user can enter a customized evaluation and the logic 214 automatically selects check box 34.

GUI 500 further comprises the pull down boxes 725 and 726 that enable a user to select what system and component the failure mode is associated with.

The GUI 500 further comprises check boxes 730-734 for indicating the consequences associated with the failure mode. In this regard, the “Safety” check box 730, if selected, would indicate safety consequences, the “Environmental” check box 731, if selected, would indicate environmental consequences, the “Operational” check box 732, if selected, would indicate operational consequences, the “Secondary Damage” check box 733, if selected, would indicate secondary damage consequences, and the “Non-Operational” check box 734, if selected, would indicate non-operational consequences.

In addition, the GUI 500 further comprises pull down boxes 595 and 596. If it is possible to detect evidence of the impending failure of the failure mode described in text box 520, the user selects yes from the pull down box 595. If not, the user selects no, and the logic 214 deactivates pull-down box 596 and a “Perform CBM Analysis” pushbutton 597. In this regard, if it is not possible to detect a potential failure condition, then a CBM analysis is not technically appropriate. Further, if it is possible to detect a potential failure condition but it is not practical to perform a CBM analysis, the user selects no from the pull-down box 596, and the logic 214 deactivates the pushbutton 597, because a CBM analysis is not practical.

The GUI 500 further comprises a push button 597. When push button 597 is selected, the logic 214 displays a GUI 600 as illustrated in FIG. 6. Further, the “Close” pushbutton 852, when selected, closes GUI 500.

If evidence of impending failure can be detected, and a CBM analysis is practical, the user may select the “Perform CBM Analysis” pushbutton 597. When pushbutton 597 is selected, the logic 214 displays the “CBM Analysis” GUI 600 depicted in FIG. 6, which is described further herein.

As described hereinabove, the user selects whether to perform a CBM Element Analysis type or a Function/Functional Failure Analysis type when the user generates the current analysis, as described with reference to FIGS. 4A and 4B. Logic 214 displays FIG. 5A, if the user selects a CBM Element Analysis, as described hereinabove. However, if the user selects a Function/Functional Failure Analysis type, the logic 214 displays GUI 2000 depicted in FIG. 5B.

GUI 2000 is similar to GUI 500, however, the user identifies functions and functional failures and corresponding failure modes as opposed to identifying CBM elements and CBM sub-elements and corresponding failure modes. In this regard, GUI 2000 comprises text boxes 811 and 812 in which the user may enter data indicative of functions and associated functional failures. In addition, the user navigates a plurality of functions and functional failures via the navigation buttons 10-13 and 16-19. Further, the total number of records is indicated in boxes 15 and 20. The logic 214 displays in text boxes 837 and 827 identifiers associated with each function and functional failure, respectively. In addition, the user may add functions and functional failures by selecting “Add” pushbuttons 2001 and 802, respectively.

The GUI 2000 further comprises the “Failure Mode Analysis” section 511 for identifying failure modes associated with the function/functional failure pairs identified as described hereinabove. In this regard, section 511 is substantially similar to that as described with reference to FIG. 5A. Notably, in both GUI 500 and GUI 2000 the user is identifying failure modes. In GUI 500, the user identifies failure modes by reverse-engineering CBM sub-elements whereas in GUI 2000 the user identifies failure modes by first identifying particular functions and functional failures.

From GUI 500 or from GUI 2000, the user selects the pushbutton 597, and the logic 214 displays GUI 600 depicted in FIG. 6. GUI 600 performs the CBM analysis, as described hereinabove.

The GUI 600 receives information for performing the analysis for each identified failure mode to determine whether there is a device or procedure for monitoring the potential failure condition of a failure mode that could be used in a condition-based maintenance task that is technically appropriate and safe/cost effective.

The GUI 600 displays the identifier corresponding to the failure mode under analysis in box 680. Further, the user can scroll through the failure modes using the navigation buttons 681-684, and the total number of records through which the user can scroll is indicated in text box 685. The logic 214 displays the failure mode description in a text box 606.

The GUI 600 further comprises check boxes 931-933 associated with the priority to the failure mode described in text box 606 and the associated possible CBM task. If priority is high, the user checks the “High” check box 931, if priority is medium, the user checks the “Medium” check box 932, and if priority is low, the user selects the “Low” check box 933.

The GUI 600 further comprises a CBM analysis box 986, and the CBM team answers questions provided on the GUI to perform the CBM analysis. The GUI 600 comprises a text box 610 for identifying a potential failure condition associated with the failure mode identified in text box 606. For example, the failure mode “O-1-A-1” may be “any synchronizing shaft hangar bearing wears due to normal use.” A potential failure condition for that failure mode may be “detection of increased vibration via a vibration monitoring device,” which the user would describe in box 610. Notably, there may be more than one potential failure condition for each failure mode.

Thus, the user may select the “Add” button 914 in order to add additional potential failure conditions. Further, a text box 915 exhibits a potential failure condition identifier, e.g., “O-1-A-1-a,” and check boxes 612 and 613 may be selected by logic 214 if the user selects pushbuttons 672 and 673, respectively, and adds additional data related to the potential failure condition. These buttons behave similar to pushbuttons 598 and 599 described with reference to FIG. 5A. Further, the user can scroll through a plurality of potential failure conditions using the navigation buttons 916-919, and the logic 214 displays an identifier in a text box 915 identifying the currently displayed potential failure condition. Further, the total number of records is displayed in text box 920.

GUI 600 further comprises “What is P?” pull-down box 663 and “What is F?” pull-down box 664, in which the user may identify the potential failure condition and the functional failure point associated with the described potential failure condition in text box 610. The GUI further comprises a text box 665 for entering a P-F interval, and a plurality of pull downs 666-670 for receiving information on whether the P-F interval is reasonably consistent, if it is practical to monitor at intervals of less than the P-F, if it is long enough to manage the consequence of failure, if the task is effective, and if the entity currently possesses the CBM capability, respectively.

Note that each of the pull-down boxes may provide options, e.g., “Yes,” “No,” or “TBD.” If the user selects a “TBD” option from one of the plurality of pull-down boxes 666-670, then the CBM logic 214 automatically checks one of the plurality of check boxes 905-911 to identify what needs to be done in response to a selected “TBD.” Further, a user may select a “TBD” or enter text corresponding to a “P,” “F,” or “P-F” in pull-down boxes 663-665.

In this regard, if a “P,” “F,” or “P-F” requires further research to be identified, i.e., the user selects “TBD” in pull-down boxes 663-665, the CBM logic 214 automatically checks boxes 902, 903, or 904, respectively. If the consistency of the P-F interval needs to be determined, the logic 214 selects check box 905, if the practicality of monitoring less than the P-F needs to be determined, the logic 214 selects box 906, and if one needs to determine whether the P-F interval is long enough to manage the consequences of failure, the logic 214 selects box 907. Additionally, if the applicability and effectiveness of the CBM task needs to be determined, the logic 214 selects box 910 and if one needs to determine the capabilities of the entity with respect to CBM, e.g., whether the entity has the appropriate equipment, procedures, and/or know-how, then the logic 214 selects check box 911.

Finally, if during the course of the CBM analysis information received in the GUI 600 indicates that CBM is not possible, the logic 214 can display a check in check box 926. In this regard, if one of the queries corresponding to pull-down boxes 666-669 is “NO,” the logic 214 automatically selects check box 926. The user may also at any time manually select check box 926 to indicate that CBM is not possible.

The GUI 600 further comprises an “Evaluation of CBM Method” pushbutton 1000, a “CBM Techniques” pushbutton 1001, and a “Send Action Item” pushbutton 912.

If the user selects the “Evaluation of CBM Method” pushbutton 1000, the logic 214 displays an “Evaluation of CBM Method” GUI 38 such as is depicted in FIG. 8. With reference to FIG. 8, GUI 38 comprises a plurality of check boxes 35-37 associated with one or more evaluation statements. If the user determines that CBM might provide longer use of the component because it would only be replaced upon evidence of need, the user selects the check box 35. If the user determines that several flights can be made before maintenance is required, the user selects check box 36. Additionally, a text box 89 is editable, and the user can enter data indicative of a configurable evaluation. If the user enters data describing an evaluation in text box 89, the logic 214 selects check box 37.

If the user selects the “CBM Techniques” pushbutton 1001, the logic 214 displays a “List of CBM Techniques” GUI 39 such as is depicted in FIG. 8. Note that the CBM techniques listed are those that an organization may desire to explore in a CBM analysis. The techniques identified in GUI 39 may be configured specific to the organization and stored as CBM technique data 223 (FIG. 2).

The user may then select one or more of the techniques listed in GUI 39. Each technique may be a link, and the selected technique may be incorporated into the CBM analysis and possible resulting CBM task. For example, the user may select “Frequency Analysis” to identify it as a possible CBM technique to be used with the current potential failure condition.

If the CBM analysis in GUI 600 is completed successfully, the logic 214 can store proposed CBM task data and associated interval data as analysis data 221. Such proposed CBM task data and interval data may be entered in corresponding text fields (not shown) and retrieved and displayed in corresponding GUIs (not shown) for use by an organization.

The “Send Action Item” pushbutton 912, when selected, preferably enables the user to communicate any item identified as “TBD,” as described hereinabove, to a recipient, as described with reference to FIG. 1. In this regard, when the pushbutton 912 is selected, logic 214 displays a text box (not shown) requesting at least one email address for a recipient. The logic 214 generates a form (not shown) that will have its own uniform resource locator (URL) that will be embedded into an email which will be sent to the recipient. For example, the user may desire to send a request for calculation of a P-F interval to an engineer. When the user sends the email, the device 107 transmits the email to the recipient via the output device 224.

The form at the URL will comprise various text fields that need to be filled out by the recipient. Upon receipt of the email, the recipient can select the link (not shown) associated with the URL, and the recipient device 109 will display the form. The user then fills out the various text fields on the form and selects a save pushbutton (not shown), and the recipient's device 109 sends the notification that a reply is posted.

Via the display device 210, the user can view the information entered by the recipient. Further, if the user desires, the user can accept or reject the changes proposed by the recipient. In one embodiment, the form (not shown) associated with each modification, change, or addition a check box that, when selected, accepts or rejects the modification, change, or addition. When the user selects the save pushbutton, the logic 214 will then save the changes to the database 216.

In another embodiment, the logic 214 may generate an Excel™ spreadsheet when the “Send Action Item” pushbutton 912 is selected. The spreadsheet preferably comprises applicable data request(s) that will be sent manually, e.g., email via Outlook™, to the intended recipient. After the recipient makes the necessary changes, the Excel™ spreadsheet will be sent back to the user. The Excel™ spreadsheet can then be opened and data that is not needed to be extracted may be removed. After saving this Excel™ spreadsheet, it may be imported into the system via the logic 214.

FIG. 10 is a flowchart depicting exemplary architecture and functionality of the CBM logic 214 (FIG. 2) as described hereinabove. In performing the CBM analysis, the logic 214 receives data indicative of whether the analysis requested is to be a CBM Element Analysis type or a Function/Functional Failure Analysis type, as indicated in step 3000.

If the user selects a CBM Element Analysis type, the logic 214 displays the GUI 500 (FIG. 5A) for receiving data indicative of CBM elements and querying the user in order to reverse engineer the failure modes that may be associated with the identified CBM sub-element, as indicated in step 3002. If the user selects a Function/Functional Failure Analysis type, the logic 214 displays a GUI 2000 (FIG. 5B) for receiving data indicative of functions and functional failures and querying the user in order to determine failure modes that may be associated with the identified functions and functional failures in step 3001. In addition, the logic 214 receives data indicative of failure effects and failure consequences to determine failure effects and failure consequences for each failure mode identified in steps 3001 or 3002, as indicated in step 3003.

If a potential failure condition is detectable in step 3004 and a CBM analysis is successfully completed in step 3006, then the logic 214 allows the user to document CBM tasks at associated intervals and issue internal notification via the CBM Analysis GUI 600 (FIG. 6), as indicated in step 3007. If a potential failure condition is not detectable or not applicable and effective, then CBM Analysis is not appropriate, as indicated in step 3005.

Claims

1. A maintenance system, comprising:

an input device; and

logic configured to receive and store data indicative of a CBM element, CBM sub-element, a failure mode related to the CBM sub-element, a failure effect, and a failure consequence, via the input device, the logic further configured to display the received data to a display device in response to a first user input and display a plurality of logical selectable input boxes corresponding to condition-based maintenance (CBM) queries that may be selected in relation to the failure mode.

2. The maintenance system of claim 1, wherein the logic is further configured to display a plurality of analysis types to the user.

3. The maintenance system of claim 2, wherein at least one analysis type is a condition-based maintenance analysis type.

4. The maintenance system of claim 2, wherein at least one analysis type is a function/functional failure analysis type.

5. The maintenance system of claim 2, wherein the logic is further configured to display a GUI comprising a CBM element text field based upon an input from the user.

6. The maintenance system of claim 2, wherein the logic is further configured to display a GUI comprising a function text field based upon an input from the user.

7. The maintenance system of claim 1, wherein the logic is further configured to identify a plurality of CBM techniques associated with the failure mode.

8. The maintenance system of claim 1, wherein the logic is further configured to transmit a notification based upon at least one input in the input boxes.

9. The maintenance system of claim 1, wherein the logic is further configured to transmit the notification via email.

10. The maintenance system of claim 1, wherein the logic is further configured to display at least one evaluation method for selection by the user identifying a current CBM method.

11. A maintenance system comprising:

a display device;

logic configured to receive data indicative of a CBM sub-element and a failure mode, the logic further configured to display to the display device a CBM analysis graphical user interface if a user provides an input indicating that the failure mode is detectable and provides an input that a CBM analysis is practical.

12. A maintenance method, comprising the steps of:

receiving data indicative of a CBM element analysis type or a functional/functional failure analysis type from a user; and

displaying a reverse engineering graphical user interface (GUI) or a function/functional failure GUI based upon the data received.

13. The maintenance method of claim 12, further comprising the step of receiving data identifying a failure mode associated with a CBM sub-element or a function/functional failure.

14. The maintenance method of claim 13, further comprising the step of performing a CBM analysis on the identified failure mode.

15. The maintenance method of claim 14, further comprising the steps of:

determining a current maintenance strategy for the failure mode; and

receiving evaluation data of the current maintenance strategy.

16. The maintenance method of claim 14, further comprising the steps of:

identifying whether CBM analysis is possible; and

transmitting a notification to a recipient based upon the identifying step.