Patent Grant
8990770
The present invention generally relates to architectures for condition based health maintenance systems, and more particularly relates to architectures that may be flexibly reconfigured by a user to reflect the physical structure of an asset being monitored and how the asset is being monitored.
Increases in vehicle complexity and the accompanying increase in maintenance costs have led to industry wide investments into the area of condition based health management (CBM). These efforts have led to the development of industry or equipment specific process solutions. However, conventional CBM systems are generally rigidly configured requiring the user to live with cumbersome performance or pay significant modification costs.
Once the parameters of the complex system are measured, the measurement data is typically forwarded to more sophisticated devices and systems at an extraction level 30 of processing. At the extraction level 30, higher level data analysis and recording may occur such as the determination or derivation of trend and other symptom indicia.
Symptom indicia are further processed and communicated to an interpretation level 40 where an appropriately programmed computing device may diagnose, prognosticate default indications or track consumable usage and consumption. Raw material and other usage data may also be determined and tracked.
Data synthesized at the interpretation level 40 may then be compiled and organized by maintenance planning, analysis and coordination software applications at an action level 50 for reporting and other interactions with a variety of users at an interaction level 60.
Although processes required to implement a CBM system are becoming more widely known, the level of complexity of a CBM system remains high and the cost of developing these solutions is commensurately high. Attempts to produce an inexpensive common CBM solution that is independent from the design of the complex system that it is to monitor have been less than satisfying. This is so because the combination and permutations of the ways in which a complex system can fail and the symptoms by which the failures are manifested are highly dependent on the system design.
Accordingly, it is desirable to develop a health maintenance system architecture that is sufficiently flexible to support a range of complex systems. In addition, it is desirable to develop a health maintenance system that may be easily reconfigured by a user in real time, thus dispensing with prohibitive reprogramming costs and delays. Furthermore, other desirable features and characteristics of the present invention will become apparent from the subsequent detailed description of the invention and the appended claims, taken in conjunction with the accompanying drawings and this background of the invention.
A reconfigurable system is provided for monitoring the health of a complex system. The system may include, but is not limited to a computing node including a memory and a processor. The processor can be configured to receive a plurality of standardized executable application modules, each standardized executable application module containing instructions to perform one of a plurality of different standardized functions, receive a binary file comprising instructions, which when loaded into the memory by the processor, configure the standardized executable application modules and configure the memory by creating at least one data structure in the memory used by at least one of the plurality of standardized executable application modules.
A method is provided for configuring a system monitoring the health of a complex system. The method can include, but is not limited to receiving, by the processor, a plurality of standardized executable application modules, each standardized executable application module containing instructions to perform one of a plurality of different standardized functions, storing, by the processor, the plurality of standardized executable application modules in the memory, receiving, by the processor, a binary file comprising instructions, which when loaded into memory, configure the standardized executable application modules and configure the memory by creating at least one data structure in the memory used by at least one of the plurality of standardized executable application modules
A computing node is further provided. The computing node may include, but is not limited to a memory and a processor communicatively connected to the memory. The processor may be configured to receive a plurality of standardized executable application modules, each standardized executable application module containing instructions to perform one of a plurality of different standardized functions, receive a binary file comprising instructions to configure the standardized executable application modules and configure the memory by creating at least one data structure in the memory used by at least one of the plurality of standardized executable application modules.
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. 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.
Those of skill in the art will appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. Some of the embodiments and implementations are described below in terms of functional and/or logical block components (or modules) and various processing steps. However, it should be appreciated that such block components (or modules) may be realized by any number of hardware, software, and/or firmware components configured to perform the specified functions. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps are described herein generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention. For example, an embodiment of a system or a component may employ various integrated circuit components, e.g., memory elements, digital signal processing elements, logic elements, look-up tables, or the like, which may carry out a variety of functions under the control of one or more microprocessors or other control devices. In addition, those skilled in the art will appreciate that embodiments described herein are merely exemplary implementations.
The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a controller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. The word “exemplary” is used exclusively herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.
In this document, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual relationship or order between such entities or actions. Numerical ordinals such as “first,” “second,” “third,” etc. simply denote different singles of a plurality and do not imply any order or sequence unless specifically defined by the claim language. The sequence of the text in any of the claims does not imply that process steps must be performed in a temporal or logical order according to such sequence unless it is specifically defined by the language of the claim. The process steps may be interchanged in any order without departing from the scope of the invention as long as such an interchange does not contradict the claim language and is not logically nonsensical.
Furthermore, depending on the context, words such as “connect” or “coupled to” used in describing a relationship between different elements do not imply that a direct physical connection must be made between these elements. For example, two elements may be connected to each other physically, electronically, logically, or in any other manner, through one or more additional elements.
While at least one exemplary embodiment will be presented in the following 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 following detailed description will provide those skilled in the art with a convenient road map for implementing an exemplary embodiment of the invention.
In light of the plethora of complex systems that may be monitored by the embodiments being described herein below and the wide range of functionality that may be desired at any point in the complex system, the following description contains non-limiting examples of the subject matter being disclosed herein. A specific non-limiting example of a complex system that may complement the following exemplary embodiments may be the vehicle as described in co-owned, co-pending application Ser. No. 12/493,750 to David Goldstein.
For the sake of brevity and simplicity, the present example will be assumed to have only five different processing levels or “application layers.” An application layer (120-160) is a set of functions or services programmed into run-time software resident in one or more computing nodes sharing a particular hierarchical level and which is adapted to meet the needs of a user concerning a particular health management implementation. As non-limiting examples, an application layer may be an Equipment Health Manager (EHM) Layer 120, an Area Health Manager (AHM) Layer 130, a Vehicle Heath Manager (VHM) Layer 140, a Maintainer Layer 150, or an Enterprise Layer 160.
However, in equivalent embodiments discussed herein, the hierarchical structure 200 may have any number of levels of application layers 120-160. Application layers 120-160 may include any number of computing nodes, which are computing devices. The number of nodes is determined by the complexity of the complex system and the sophistication of the monitoring desired by the user. In some embodiments, multiple nodes 120′-160′ may be resident in one computing device. The computing nodes of the equipment based layers (EHM Layer 120, AHM Layer 130, VHM Layer 140, Maintainer layer 150 and Enterprise layer 160) may be also referred to as an EHM 120′, an AHM 130′, a VHM 140′, a maintainer node 150′ and an enterprise node 160′.
In the exemplary embodiments disclosed herein, an EHM 120′ is a computing device that provides an integrated view of the status of a single component of the computer system comprising the lowest level of the hierarchical structure 200. The EHM 120′ may have different nomenclature favored by others. For example, in equivalent embodiments, the EHM 120′ also be known as a Component Area Manager (CAM). A complex system may require a large number of EHMs 120′, each of which may include multiple times series generation sources such as sensors, transducers, Built-In-Test-Equipment (BITE) and the like. EHMs 120′ are preferably located in electronic proximity to a time series data generation source in order to detect symptomatic times series patterns when they occur.
An AHM 130′ is a computing device situated in the next higher hierarchical level of the hierarchical structure 200 and may receive and process message, command and data inputs received from a number of EHMs 120′ and other nodes 140′-160′. An AHM 130′ may report and receive commands and data from higher level or lower level components of the hierarchical structure 200. An AHM 130′ processes data and provides an integrated view of the health of a single sub-system of the complex system being monitored. The AHM 130′ may have different nomenclature favored by others. For example, in equivalent embodiments, the AHM 130′ also be known as a Sub-system Area Manager (SAM).
A VHM 140′ is a computing device situated in the next higher hierarchical level for the hierarchical structure 200 and may receive and process message, command and data inputs received from a number of EHMs 120′ and AHMs 130′. A VHM 140′ may report and receive commands and data from higher level components of the hierarchical structure 200, as well. A VHM 140′ processes data and provides an integrated view of the health of the entire complex system being monitored. The VHM 140′ may have different nomenclature favored by others. For example, in equivalent embodiments, the VHM 140′ also be known as a System Level Control Manager (SLCM).
A Maintainer Layer 150 contains one or more computing node 150′ that analyze data received from the EHMs 120′, AHMs 130′ and VHMs 140′ and supports local field maintenance activities. Non-limiting examples of a Maintainer Level computing system is the Windows® PC ground based station (PC-GBS) software produced by Intelligent Automation Corporation, a subsidiary of Honeywell International of Morristown, N.J.; or the US Army's Platform Soldier-Mission Readiness System (PS-MRS). The Maintainer Layer system may have different nomenclature favored by others. Node 150′ also receives data, commands and messages from higher level node 160′.
An Enterprise Layer 160 contains one or more computing nodes 160′ that analyze data received from the EHMs 120′, AHMs 130′, VHMs 140′ and the Maintainer Layer 150. The Enterprise Layer 160 supports the maintenance, logistics and operation of a multitude or fleet of assets. Non-limiting examples of an Enterprise Layer 160 computing system is the ZING™ system and the Predictive Trend Monitoring and Diagnostics System from Honeywell International. The Enterprise layer system 160′ may have different nomenclature favored by others.
In accordance with the precepts of the subject matter disclosed herein, each computing node 120′-160′ of each level of the hierarchical structure 200 may be individually and timely configured or reconfigured by the user by way of the data driven modeling tool 171. The data driven modeling tool 171 allows a user to directly alter the configuration data 180, which in turn provides specific direction and data to, and/or initiates, one or more standardized executable application modules (SEAMs) 221-223, 231-234, 241-247, 251-256 and 261-264 resident in each computing node 120′-160′ of the hierarchical structure 200 via the model driven GUI 170 (See
The number of standardized executable application modules 221-223, 231-234, 241-247, 251-256 and 261-264 is not limited and may be expanded beyond the number discussed herein. Similarly, the standardized executable application modules 221-223, 231-234, 241-247, 251-256 and 261-264 discussed herein may be combined into fewer modules or broken down into component modules as may be required without departing from the scope of the disclosure herein. The standardized executable application modules 221-223, 231-234, 241-247, 251-256 and 261-264 are a set of services, run-time software, firmware and knowledge management tools that are selectable from one or more re-use libraries 220-260 and are subsequently directed to meet the health management implementation needs of a user. Each standardized executable application module 221-223, 231-234, 241-247, 251-256 and 261-264 contains executable code comprising a set of logic steps defining standardized subroutines designed to carry out a basic function that may be directed and redirected at a later time to carry out a specific functionality.
There are 24 exemplary standardized executable application modules 221-223, 231-234, 241-247, 251-256 and 261-264 discussed herein that are broken down into five non-limiting, exemplary libraries 220, 230, 240, 250 and 260. The standardized executable applications 221-223, 231-234, 241-247, 251-256 and 261-264 are basic un-modifiable modular software objects that are directed to complete specific tasks via the configuration data 180 after the standardized executable software modules 221-223, 231-234, 241-247, 251-256 and 261-264 are populated within the hierarchical structure 200. The configuration data 180 is implemented in conjunction with an executable application 221-223, 231-234, 241-247, 251-256 and 261-264 via the delivery of a configuration file 185 containing the configuration data 180 to a node. Once configured, the standardized executable application modules 221-223, 231-234, 241-247, 251-256 and 261-264 within the node may then cooperatively perform a specific set of functions on data collected from the complex system. A non-limiting example of a specific set of functions may include a health monitoring algorithm.
As non-limiting examples, the Measure Library 220 may include an Acquire Module 221. The Acquire Module 221 functionality may provide a primary path for the input of data into a computing node 120′-160′ through a customized adapter 325 (illustrated in
The Measure Library 220 may include a Sense Module 223. The Sense Module 223 may provide a secondary path for the input of data into a computing node 120′-160′ through a system initiated request to read data from a physical I/O device (i.e., serial data ports, sensor I/O interfaces, etc.). The Sense Module 223, which then parses the data block and queues it for subsequent processing by another executable application 221-222, 231-234, 241-247, 251-256 and 261-264.
The Measure Library 220 may include a Decode Module 222. The Decode Module 222 may take the data queued by the Acquire Module 221 or Sense Module 223 and translate the data into a useable form (i.e., symptoms and/or variables) that other executable applications can process. The Decode Module 222 may also fill a circular buffer with the data blocks queued by an Acquire Module 221 to enable snapshot or data logging functions.
The Extract Library 230 may include an Evaluate Module 231. The Evaluate Module 231 may perform a periodic assessment of state variables of the complex system to trigger data collection, set inhibit conditions and detect complex system events based on real-time or near real-time data.
The Extract Library 230 may include a Record Module 234. The Record Module 234 may evaluate decoded symptoms and variables to determine when snapshot/data logger functions are to be executed. If a snapshot/data log function has been triggered, the Record Module 234 may create specific snapshot/data logs and send them to a dynamic data store (DDS) file. The DDS file is created in a memory of a computing node 120′-160′ by loading a binary file, herein referred to as DDS 350b, into a computing node 120′-160′ as discussed in further detail below. Snapshots may be triggered by another executable application 221-223, 231-233, 241-247, 251-256 and 261-264 or by an external system (not shown).
The Extract Library 230 may include an Analyze Module 232. The Analyze Module 232 may run one or more algorithms using the variable values and trend data that may have been assembled by a Trend Module 233 and subsequently stored in a DDS file to determine specific symptom states and/or provide estimates of unmeasured parameter values of interest.
The Interpret Library 240 may include an Allocate Module 241. The Allocate Module 241 may perform inhibit processing, cascade effect removal and time delay processing on a set of symptoms and then allocate the symptoms to the appropriate fault condition(s) that is specified for the monitored device or subsystem. The Allocate Module 241 may also update the state of each fault condition based on changes in the state of any particular symptom associated with a fault condition.
The Interpret Library 240 may include a Diagnose Module 242. The Diagnose Module 242 may orchestrate interaction between a system user, monitored assets and diagnostic reasoning to reduce the number of ambiguous failure modes for a given active fault condition until a maintenance procedure is identified that will resolve the root cause of the fault condition.
The Interpret Library 240 may include a Rank Module 243. The Rank Module 243 may rank order potential failure modes after diagnostic reasoning has been completed. The failure modes, related corrective actions (CA) and relevant test procedures associated with a particular active fault condition are ranked according to pre-defined criteria stored in a Static Data Store (SDS) 350a. A SDS is a static data storage location in a configuration file 185.
The Interpret Library 240 may include a Predict Module 244. The Predict Module 244 may run prognostic algorithms on trending data stored in the DDS file in order to determine potential future failures that may occur and provide a predictive time estimate.
The Interpret Library 240 may include a Consumption Monitoring Module 245. The Consumption Monitoring Module 245 may monitor consumption indicators and/or may run prognostic algorithms on trending data stored in the DDS file that are configured to track the consumption of perishable/life-limited supply material in the complex system and then predict when resupply will be needed. The consumption monitoring functionality may be invoked by a workflow service module 310, which is a component functionality of an internal callable interface 300 and will be discussed further below.
The Interpret Library 240 may include a Usage Monitoring Module 246. The Usage Monitoring Module 246 may monitor trend data stored in the DDS file to track the usage of a monitored device or subsystem in order to estimate the need for preventative maintenance and other maintenance operations. The usage monitoring functionality may be invoked by the workflow service 310, which is a component functionality of the internal callable interface 300.
The Interpret Library 240 may include a Summarize Module 247. The Summarize Module 247 may fuse health data received from all subsystems monitored by an application layer and its subordinate layers 120-160 into a hierarchical set of asset status reports. Such reports may indicate physical or functional availability for use. The asset status reports may be displayed in a series of graphics or data trees on the GUI 170 (illustrated in
The Act Library 250 may include a Schedule Module 251. The Schedule Module 251 schedules the optimal time in which required or recommended maintenance actions (MA) should be performed in accordance with predefined criteria. Data used to evaluate the timing include specified priorities and the availability of required assets such as maintenance personnel, parts, tools, specialized maintenance equipment and the device/subsystem itself. Schedule functionality may be invoked by the workflow service 310.
The Act Library 250 may include a Coordinate Module 252. The Coordinate Module 252 coordinates the execution of actions and the reporting of the results of those actions between application layers 120-160 and between layers and their monitored devices/subsystems. Exemplary, non-limiting actions include initiating the BITE or a snapshot function. Actions may be pushed into and results may be pulled out of the Coordinate Module 252 using a customized adapter 325a-d (illustrated in
The Act Library 250 may include a Report Module 253. The Report Module 253 may generate a specified data block to be sent to the next higher application in the hierarchy and/or to an external user. Report data may be pulled from the Report Module 253 by the customized adapter 325a-d. The Report Module 253 may generate data that includes a health status summary of the monitored asset.
The Act Library 250 may include a Track Module 254. The Track Module 254 may interact with the user to display actions for which the user is assigned and to allow work to be accomplished or reassigned.
The Act Library 250 may include a Forecast Module 255. The Forecast Module 255 may determine the need for materials, labor, facilities and other resources in order to support the optimization of logistic services. Forecast functionality may be invoked by the workflow service 310.
The Act Library 250 may include a Log Module 256. The Log Module 256 may maintain journals of selected data items and how the data items had been determined over a selected time period. Logging may be performed for any desired data item. Non-limiting examples include maintenance actions, reported faults, events and the like.
The Interact Library 260 may include a Render Module 262. The Render Module 262 may construct reports, tabularized data, structured data and HTML pages for display, export or delivery to the user.
The Interact Library 260 may include a Respond Module 261. The Respond Module 261 may render data for display to the user describing the overall health of the complex system and to support detailed views to allow “drill down” for display of summary evidence, recommended actions and dialogs. The rendering of display data may be initiated by the workflow service 310; but the data may be pulled from the Render Module 262 via the callable interface 300. The Respond Module 261 may also receive and process commands from the user then route the commands to the appropriate module in the appropriate node for execution and processing. The commands may be pushed into the Respond Module 261 via the callable interface 300.
The Interact Library 260 may include a Graph Module 263. The Graph Module 263 may provide graphical data for use by the Render Module 262 in the user displays on GUI 170 (illustrated in
The Interact Library 260 may include an Invoke Module 264. The Invoke Module 264 may retrieve documents to be displayed to a maintainer or interact with an external document server system (not shown) to cause externally managed documents to be imported and displayed.
To reiterate, each of the standardized executable application modules 221-223, 231-234, 241-247, 251-256 and 261-264 discussed above are never modified. The standardized executable application modules 221-223, 231-234, 241-247, 251-256 and 261-264 are loaded into any computing node 120′-160′ of the hierarchical system 200 and any number of standardized executable application modules may be loaded into a single node. Once installed, each standard executable application module 221-223, 231-234, 241-247, 251-256 and 261-264 may be initialized, directed and redirected by a user by changing the configuration data 180 resident in the database 190 to perform specific tasks in regard to its host computing device or platform.
Communication between standardized executable application modules 221-223, 231-234, 241-247, 251-256 and 261-264 within a node is facilitated by a callable interface 300. A callable interface 300 is resident in each computing node 120′-160′ of the hierarchical structure 200. The callable interface 300 may have several sub-modules 302-310 that may be co-resident in a single computing device of a computing node 120′-160′. Exemplary sub-modules of the callable interface 300 may include a framework executive 301 as a component of the callable interface 300, a workflow service 310, an error reporting service 302, a debugging service 303, a framework data accessor 304, a run-time shared data manager 305 and common utilities 306. Those of ordinary skill in the art will recognize that in equivalent embodiments a “module,” “a sub-module,” “a server,” or “a service” may comprise software, hardware, firmware or a combination thereof.
The framework executive 301 of a computing node provides functions that integrate the nodes within the hierarchical system 200. The framework executive 301 in conjunction with the configuration files 185 coordinate initialization of each node including the standardized executable application modules 221-223, 231-234, 241-247, 251-256 and 261-264 and the other service modules 301-310 allowing the execution of functions that are not triggered by the customized adapter 325 (illustrated in
Error reporting services 302 provide functions for reporting run-time errors in a node 120′-160′ within the hierarchical structure 200. The error reporting service 302 converts application errors into symptoms that are then processed as any other failure symptom, reports application errors to a debugging service 303 and reports application errors to a persistent data manager (not shown).
Debugging services 303 collects and reports debugging status of an executable application module 221-223, 231-234, 241-247, 251-256 and 261-264 during testing, integration, certification, or advanced maintenance services. This server may allow the user to set values for variables in the DDS file and to assert workflow events.
The framework data accessor 304 provides read access to the SDS 350a and read/write access to the DDS 350b (each stored in a memory 190) by the standardized executable application modules 221-223, 231-234, 241-247, 251-256 and 261-264 in a computing node 120′-160′. Write access to the SDS 350a is accomplished via the data modeling tool 171, which includes GUI 170 (illustrated in
The run-time shared data manager 305 manages all node in-memory run-time perishable data structures that are shared between standardized executable application modules 221-223, 231-234, 241-247, 251-256 and 261-264 that are not stored in the DDS file, but does not include cached static data. As non-limiting examples of perishable data structures may include I/O queues and circular buffers.
Common utilities 306 may include common message encoding/decoding, time-stamping and expression evaluation functions for use by the standardized executable application modules 221-223, 231-234, 241-247, 251-256 and 261-264 installed in a computing node 120′-160′.
The work flow service 310 is a standard set of logic instructions that enable a data-driven flow of tasks within a computing node to be executed by the various standardized executable application modules 221-223, 231-234, 241-247, 251-256 and 261-264 within the node. The workflow service 310 acts as a communication control point within the computing node where all communications related to program execution to or from one executable application module 221-223, 231-234, 241-247, 251-256 and 261-264 are directed through the node's workflow service 310. Stated differently, the workflow service 310 of a node 120′-160′ orchestrates the work flow sequence among the various standardized executable application modules 221-223, 231-234, 241-247, 251-256 and 261-264 that happen to reside in the node. In some embodiments the workflow service 310 may be a state machine.
For the sake of simplicity, the standardized executable application modules 221-223, 231-234, 241-247, 251-256 and 261-264 will be discussed below in terms of their respective libraries. The number of combinations and permutations of executable applications 221-223, 231-234, 241-247, 251-256 and 261-264 is large and renders a discussion using specific standardized executable application modules unnecessarily cumbersome.
At an EHM layer 120, there may be a number of EHM nodes 120′, each being operated by a particular host computing device that is coupled to one or more sensors and/or actuators (not shown) of a particular component of the complex system. As a non-limiting example, the component of the complex system may be a roller bearing that is monitored by a temperature sensor, a vibration sensor, a built-in-test, sensor and a tachometer, each sensor being communicatively coupled to the computing device (i.e. a node). As a non-limiting example, the host computing device of an EHM node 120′ of the complex system may be a computer driven component area manager (CAM) (i.e. a node). For a non-limiting example of a CAM that may be suitable for use as EHM node 120′, see co-owned, co-pending U.S. patent application Ser. No. 12/493,750 to Goldstein.
Each EHM node 120′ host computing device in this example is operated by a host software application 330. The host software application 330 may be a proprietary program, a custom designed program or an off-the-shelf program. In addition to operating the host device, the host software application also may support any and all of the standardized executable application modules 221-223, 231-234, 241-247, 251-256 and 261-264 via the framework services 301e by acting as a communication interface means between EHMs node 120′ and between EHM nodes 120′ and other nodes located in the higher levels.
The exemplary embodiment of
At an AHM level 130, there may be a number of AHM nodes 130′. Each AHM node 130′ is associated with a particular host computing device that may be coupled to one or more sensors and/or actuators of a particular component(s) or a subsystem of the complex system and are in operable communication with other AHM nodes 130′, with various EHM nodes 120′ and with higher level nodes (e.g., see 501, 502, 601 and 602 in
The exemplary AHM node 130′ of
Unlike the exemplary EHM node 120′, the exemplary AHM node 130′ may include a different communication interface means such as the customized adapter 325d. A customized adapter 325 is a set of services, run-time software, hardware and software tools that are not associated with any of the standardized executable application modules (221-223, 231-234, 241-247, 251-256 and 261-264). The customized adapters 325 are configured to bridge any communication or implementation gap between the hierarchical CBM system software and the computing device operating software, such as the host application software (not shown). Each computing node (120′-160′) may be operated by its own operating system, which is its host application software. For the sake of clarity,
In particular, the customized adapters 325 provide symmetric communication interfaces (e.g., communication protocols) between computing nodes and between computing nodes of different levels. The customized adapters 325a-d allow for the use of a common communication protocol throughout the hierarchical structure 200 from the lowest EHM layer 120 to the highest enterprise layer 160 as well as with the memory 190.
At a VHM Layer 140, there may be a number of VHM nodes 140′, each VHM node is associated with a particular host computing device that may be in operative communication with one or more sensors and/or actuators of a particular component(s) of the complex system via an EHM 120′ or to subsystems of the complex system and that are in operable communication via their respective AHMs 130′. As a non-limiting example, the VHM 140′ may be a computer driven System Level Control Manager (SLCM) (i.e., also a node). For non-limiting examples of a SLCM that may be suitable for use as a VHM node, see co-owned, co-pending patent application Ser. No. 12/493,750 to Goldstein.
In the exemplary hierarchical structure 200 there may be only one VHM 140′, which may be associated with any number of AHM 130′ and EHM 120′ nodes monitoring sub-systems of the complex system. In other embodiments, there may more than one VHM 140′ resident within the complex system. As a non-limiting example, the complex system may be a fleet of trucks with one VHM 140′ in each truck that communicates with several EHMs 120′ and with several AHMs 130′ in each truck. Each group of EHMs 120′ and AHMs 130′ in a truck may also be disposed in a hierarchical structure 200.
Like the exemplary AHM node 130′, an exemplary VHM node 140′ includes a customized adapter 325c. The customized adapter 325c is also configured to bridge any communication or implementation gap between the hierarchical system software and the computing device operating software operating within VHM 140′.
At the Maintainer (MNT) layer 150, there may be a number of MNT nodes 150′, each MNT node is associated with a particular host computing device that may be in operative communication with one or more sensors and/or actuators of a particular component(s) of the complex system via an EHM 120′, to subsystems of the complex system and that are in operable communication via their respective AHM 130′, and to the VHMs 140′. As a non-limiting example, the MNT node 150′ may be a laptop computer in wired or wireless communication with the communication system 9 of the hierarchical structure 200.
Like the exemplary AHM node 130′ and VHM node 140′, the MNT node 150′ includes a customized adapter 325b. The customized adapter is also configured to bridge any communication implementation gap between the hierarchical system software and the computing device operating software operating within the various nodes of the hierarchical structure 200.
At the Enterprise (ENT) layer 160, there may be a number of ENT nodes 160′, each ENT node is associated with a particular host computing device that may be in operative communication with one or more sensors and/or actuators of a particular component(s) of the complex system via an EHM 120′, to subsystems of the complex system and that are in operable communication via their respective AHM modules 130′ and the VHMs 140′, as well the MNT nodes 150′. As a non-limiting example, the ENT node 160′ may be a general purpose computer that is in wired or wireless communication with the communication system 9 of the hierarchical structure 200.
Like the exemplary AHM node 130′, VHM node 140′ and the MNT node 150′, the ENT node 160′ includes a customized adapter 325a. The customized adapter 325a is also configured to bridge any communication or implementation gap between the hierarchical system software and the host computing device software operating within the ENT node.
In various embodiments, none of the computing nodes 120′-160′ are able to communicate directly with one another. Hence, all computing nodes 120′-160′ communicate via the customized adapters 325. In other embodiments, most computing nodes 120′-160′ may communicate via the customized adapters 325. For example, an exception may be an EHM 120′, which may communicate via its host executive software 330.
Like the executable applications (21-223, 231-234, 241-247, 251-256 and 261-264, the operation of each of the customized adapters 325 is controlled by the workflow service 310 of its own node. The workflow service 310 will invoke one or more of the standardized executable application modules 221-223, 231-234, 241-247, 251-256 and 261-264 and services 302, 303, 306 to make data available to the customized adapter 325, which provides data from a node onto a data bus of the communication system 9 and pull data from the bus at the direction of one of the executable applications 221-223, 231-234, 241-247, 251-256 and 261-264. For example, the Acquire executable application module 221 or the Report executable application module 253 executes these communication functions.
The communication system 9 may be any suitable wired or wireless communications means known in the art or that may be developed in the future. Exemplary, non-limiting communications means includes a CAN bus, an Ethernet bus, a firewire bus, spacewire bus, an intranet, the Internet, a cellular telephone network, a packet switched telephone network, and the like.
The use of a universal input/output front end interface (not shown) may be included in each computing node (120′-160′) as a customized adapter 325 or in addition to a customized adapter 325. The use of a universal input/output (I/O) front end interface makes each node behind the interface agnostic to the communications system by which it is communicating. Examples of universal I/O interfaces may be found in co-owned application Ser. No. 12/750,341 and Ser. No. 12/768,448 to Fletcher and are examples of communication interface means.
The various computing nodes (120′-160′) of the hierarchical structure 200 may be populated using a number of methods known in the art, the discussion of which is outside the scope of this disclosure. However, exemplary methods include transferring and installing the pre-identified, pre-selected standardized executable applications to one or more data loaders of the complex system via a disk or other memory device such as a flash drive. Other methods include downloading and installing the executable applications directly from a remote computer over a wired or wireless network using the viewable reference model 181, the table generator 183 and the GUI 170.
The data modeling tool 171, table generator 183 and the GUI 170 may be driven by, or be a subsystem of any suitable Health Maintenance System (HMS) computer system known in the art. A non-limiting example of such an HMS system is the Knowledge Maintenance System (KMS) used by Honeywell International of Morristown. N.J. and is a non-limiting example of a model based configuration means. The data modeling tool 171 allows a subject matter expert to model their hierarchical system 200 as to inputs, outputs, interfaces, errors, etc. The table generator 183 then condenses the system model information into a compact dataset that at runtime configures or directs the functionality of the various standardized executable application modules 221-223, 231-234, 241-247, 251-256 and 261-264 of hierarchical system 200.
The GUI 170 renders a number of control screens to a user. The control screens are generated by the HMS system and provide an interface for the system user 210 to configure each standardized executable application module 221-223, 231-234, 241-247, 251-256 and 261-264 to perform specific monitoring, interpretation and reporting functions associated with the complex system (see e.g.,
In the exemplary screen shot of
The method begins by establishing a hierarchical structure 200 of computing nodes at process 1010. The hierarchical structure 200 of computing nodes is determined by the nature and construction of the complex system of concern, as well as the complexity of monitoring of the complex system that is required. As discussed above, in some embodiments there may be one or more computing nodes 120′-160′ associated with each component, with each sub-system and/or with the overall complex system. In addition, there may be a computing node 120′-160′ associated with a higher maintainer layer 150, as well as with a general enterprise layer 160. One computing node 120′-160′ may be physically and electronically different from another computing node on the same layer 120-160 or on a different level. In other embodiments, a computing node may be identical to all other computing nodes.
At process 1040, a standardized framework executive module 301 is created and defined with the desired framework services 302-310. The standardized framework service module 301 is populated to all of the hierarchical computing nodes 120′-160′.
At process 1020, the libraries 220-260 of standardized executable applications are developed and established. As discussed above, each standardized executable function 221-223, 231-234, 241-247, 251-256 and 261-264 is written to perform a standard class of functionality such as acquiring data, trending data and reporting data.
At process 1050, a system user 210 populates each computing node 120′-160′ with one or more of the standardized executable applications 221-223, 231-234, 241-247, 251-256 and 261-264 and the standardized framework executive module 301. The number and combination of standardized executable applications populated within in a particular computing node 120′-160′ is entirely within the discretion of the system designer based on the functionality or potential functionality desired. A standardized executable application 221-223, 231-234, 241-247, 251-256 and 261-264 may be populated or removed from a computing node 120′-160′ by any suitable means known in the art. Non-limiting examples of some means for populating a computing node 120′-160′ includes a maintenance load, a local data loader and loading via a network and communication system 9.
At process 1030, the complex system is modeled on the data modeling tool 171. Each computing node 120′-160′ is identified and associated with a particular component, sub-component and subsystem as may be desired to accomplish a particular level of monitoring. Each computing node 120′-160′ is assigned a particular set of standardized executable applications 221-223, 231-234, 241-247, 251-256 and 261-264 that will be required to accomplish the desired monitoring functionality of the computing node (see,
At process 1060, a plurality of configuration files 185 are created by a user 210. A configuration file 185 comprises a SDS 350a and a DDS 350b. Configuration files 185 contain a collection of editable data specific logic sequences that generate messages and data that are used by the workflow service 310 to respond to the receipt of data and messages from a standardized executable application module to perform a specific function. For example, a standardized executable application module X communicates to the workflow service 310 that it has completed a task. The workflow service 310 retrieves the next action from the configuration file and then commands the next standardized executable application module Y to execute its standardized function with specific data. In other words, a configuration file contains specific data values and programming relationships/functions between data values to enable/disable and to configure each standard executable application to accomplish a special purpose(s). In equivalent embodiments, the editable data specific logic sequences contained in a configuration file may be a collection of state machines.
Thus, the configuration files provide the information that allows the standardized executable application modules to operate and to interact with each other. Specifically this interaction is controlled via the workflow service which obtains all of its directives from the configuration files 185 to enable or disable functionality of the standardized executable application modules as well as provide processing of data within the node 120′-160′. The same standardized executable application modules may be used in all nodes because the configuration files 185 and the workflow service 310 direct the execution of the standardized executable application modules within a node and provides the ability to move functionality between nodes.
The configuration files 185 contain the definition of each node 120′-160′. This includes the information that a given node will process, how the node interacts with other nodes and special operations that are run within a given node. The configuration files contain the information to process data, generate signals, diagnose failures, predict failures, monitor usage, monitor consumption and otherwise support maintenance, operation and data analysis.
For example, the configuration files specify other node(s) that a node can interact with (see,
Hence, a computing node 120′-160′ populated with standardized executable applications 221-223, 231-234, 241-247, 251-256 and 261-264 becomes a special purpose computing node capable of performing a variety of specific tasks based on its population of executable applications and their subsequent direction by configuration files 185.
Should a system user 210 desire to add specific functions, delete specific functions or redefine specific functions for a particular computing node (120′-160′) in the hierarchical structure 200, the configuration file 185 for a particular executable application (221-223, 231-234, 241-247, 251-256 and 261-264) in a particular computing node (120′-160′) is modified within the KMS master database 180 as may be desired at process 1060 and then regenerated and installed at its associated computing node (120′-160′) at process 1070. Thus, specific functionality formerly resident in one computing node (120′-160′) may be added, deleted, modified or it may be moved to another computing node in any other hierarchical level.
For example, data “Trending” functionality being accomplished by an EHM 120′ associated with the temperature of a particular component may be shifted from the EHM 120′ to the VHM 140′ by adding the standardized “Trending” executable application to the VHM 140′ (or by enabling a dormant trending functionality already in place) and then configuring the trending executable application in the VHM 140′ to perform the operation. To complete the process, the trending functionality in the EHM 120′ may be changed to remove the temperature trending functionality or to disable the Trending executable application. Further, the temperature data from the component is redirected to the VHM 140′ via the communication system 9. As such, the data being trended at the EHM 120′ may be still acquired and analyzed at the EHM 120′ but then sent from the EHM to the VHM 140′ for trending.
The computing node 1100 illustrated in
In one embodiment, for example, the memory 1120 may store a series of variables in a variable table. The variables may correspond to, for example, any signal that is being transmitted into the current hierarchy layer, any intermediate or final calculated result of an evaluated or analyze expression, an constant value that is given as an input for an evaluate or an analyze expression is stored as a constant in the variables table. When an analyze expression produces an intermediate or final output that is an array of values rather than a single value, the output will be stored in the variable array table instead of in the variables table.
In one embodiment, for example, the DDS file 350b can define the location of each data structure used by a SEAM 1130 by associating a pointer with the data structures. The pointers used by the DDS file 350b may be autorelative, such that the location in the memory 1120 pointed to by the pointer is based upon a location of the pointer itself in the memory 1120 and an offset. Accordingly, the actual location in a memory of a data structures may differ from node to node based upon the location of the pointer to the data structures. By using autorelative pointers, the DDS file 350b for any given node may be reconfigured at any time without having to change the code for a SEAM 1130 since the location in memory 1120 of the data structures is controlled by the configuration file 185 rather than the code for a SEAM 1130 itself. The processor 1110, when attempting to access a data structure, can read the DDS file 350b to determine the memory location in memory 1120 of the data structure. The SDS 350a and DDS 350b both provide pointers to each unique data structure that is stored in the DDS 350b. The file pointers are in locations known by the SEAMs 221-223, 231-234, 241-247, 251-256 and 261-264, so the SEAMs 221-223, 231-234, 241-247, 251-256 and 261-264 are able retrieve the file pointer value and then the data stored in the data structure. The file pointer takes into account the varying structure of the data structures stored in the DDS 350b.
The DDS file 350b could also define a location of a data structure based upon a series of pointers. For example, the DDS file 350b may define a queue by associating a pointer with a location of the start of the queue and associating another pointer for the end of the queue. The DDS file 350b could also store a pointer pointing to the current or next position of the queue. The processor 1110, when attempting to access the queue, can read the DDS file 350b to determine the memory location of the current or next position in the queue.
In one embodiment, for example, the DDS file 350b also defines a size for the variables or other data structures. For example, the DDS file 350b could define a variable as having a byte length, two byte length, a word length or any arbitrary length in whole words. The DDS file 350b may also define the structure for one or more variable arrays. The variable arrays can also be, for example, one byte length, two byte length, word length or any arbitrary length in whole words.
As discussed above, the DDS file 350b may also define a property associated with a data structure. For example, the DDS file 350b may define a queue or a buffer as being circular. That is, when the last data entry in the queue or buffer is reached, as defined by the size of the respective queue or buffer, any subsequent data entry will save over the first entry in the queue or buffer. In one exemplary embodiment, the DDS file 350b associates a priority for two or more queues. As discussed in further detail below, the DDS file 350b may set up multiple queues upon which the workflow service 310 operates.
Another exemplary property which may be associated with a data structure is a default value. For example, in one embodiment, the DDS file 350b stores a default value for each variable and/or variable array. Accordingly, when the processor 1110 loads the DDS 350b to configure the node 1100, the processor 1110 stores the default value at the location in memory associated with each variable via the pointers. The DDS 350b also contains structures for storing series of data (snapshot buffers, Coordinate buffers, etc), queue structures for the runtime queues as well as fault conditions for detected problems and their associated information.
The DDS file 350b can also store one or more dynamic properties associated with the data structures. For example, a time stamp may be stored in the DDS file 350b indicating the time the data structure was last updated. If the data structure was, for example, a snapshot buffer, the DDS file 350b can store the time when the last snap shot was started and the time the last snap shot was completed in addition to pointers pointing to both the start and stop locations in memory.
As described above, there are 24 SEAMs 221-223, 231-234, 241-247, 251-256 and 261-264 disclosed herein. However, other SEAMs may be developed in the future with additional functionalities. As such, any discussion herein is intended to extend to any SEAMs that may be created in the future. However, in the interest of brevity and clarity of the following discussion, the number of SEAMs 221-223, 231-234, 241-247, 251-256 and 261-264 has been limited to an Acquire SEAM 221, a Decode SEAM 222, Evaluate SEAM 231, a Record SEAM 234, an Analyze SEAM 232, a Predict SEAM 244 and a Diagnose SEAM 242, as these SEAMs may be viewed as providing some basic functionality common to each SEAM resident in each computing node 120′-160′ of the hierarchy.
In addition to receiving any number of the SEAMs 221-223, 231-234, 241-247, 251-256 and 261-264, each computing node 120′-160′ also receives a configuration file 185 and a workflow service module 310. The configuration file 185 includes a DDS 350b and a SDS 350a. While the DDS 350b includes instructions for creating a number of queues, as discussed below, the DDS 350b can include instructions for creating any combination of the data structures discussed above.
As discussed above, the processor 1110 loads the DDS 350b into memory 1120 which is used to configure any SEAM 221-223, 231-234, 241-247, 251-256 and 261-264 loaded into the node 120 and configures the memory 1120 by setting up any variables, queues, buffers or any other data structures to be used by the loaded SEAMS. In the exemplary embodiment illustrated in
The DDS 350b illustrated in
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.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4047162 | Dorey et al. | Sep 1977 | A |
| 4296409 | Whitaker et al. | Oct 1981 | A |
| 4890284 | Murphy et al. | Dec 1989 | A |
| 5020135 | Kasparian et al. | May 1991 | A |
| 5086429 | Gray et al. | Feb 1992 | A |
| 5550736 | Hay et al. | Aug 1996 | A |
| 5754823 | Mudryk, Jr. et al. | May 1998 | A |
| 5881270 | Worthington et al. | Mar 1999 | A |
| 5884077 | Suzuki | Mar 1999 | A |
| 5941918 | Blosser | Aug 1999 | A |
| 6094609 | Arjomand | Jul 2000 | A |
| 6104803 | Weser et al. | Aug 2000 | A |
| 6128560 | Ishii | Oct 2000 | A |
| 6185613 | Lawson et al. | Feb 2001 | B1 |
| 6353896 | Holzmann et al. | Mar 2002 | B1 |
| 6401098 | Moulin | Jun 2002 | B1 |
| 6434455 | Snow et al. | Aug 2002 | B1 |
| 6438470 | Hiramatsu | Aug 2002 | B1 |
| 6493616 | Rossow et al. | Dec 2002 | B1 |
| 6615090 | Blevins et al. | Sep 2003 | B1 |
| 6624909 | Czyszczewski et al. | Sep 2003 | B1 |
| 6728611 | Kamiya | Apr 2004 | B2 |
| 6757897 | Shi et al. | Jun 2004 | B1 |
| 6766230 | Rizzoni et al. | Jul 2004 | B1 |
| 6789007 | Ellis et al. | Sep 2004 | B2 |
| 6823512 | Miller et al. | Nov 2004 | B1 |
| 6832141 | Skeen et al. | Dec 2004 | B2 |
| 6904483 | Koning et al. | Jun 2005 | B2 |
| 6910156 | Adam | Jun 2005 | B2 |
| 6928358 | Brooks et al. | Aug 2005 | B2 |
| 6937926 | Lipscomb et al. | Aug 2005 | B2 |
| 6950782 | Qiao et al. | Sep 2005 | B2 |
| 7065050 | Herbst | Jun 2006 | B1 |
| 7072879 | Soemo et al. | Jul 2006 | B2 |
| 7079984 | Eryurek et al. | Jul 2006 | B2 |
| 7124302 | Ginter et al. | Oct 2006 | B2 |
| 7142953 | Marshall et al. | Nov 2006 | B2 |
| 7188207 | Mitter | Mar 2007 | B2 |
| 7209817 | Abdel-Malek et al. | Apr 2007 | B2 |
| 7222800 | Wruck | May 2007 | B2 |
| 7237223 | Leu et al. | Jun 2007 | B2 |
| 7272475 | Gawlik et al. | Sep 2007 | B2 |
| 7295903 | Siebel et al. | Nov 2007 | B2 |
| 7319947 | Khaira et al. | Jan 2008 | B1 |
| 7349825 | Williams et al. | Mar 2008 | B1 |
| 7363420 | Lin et al. | Apr 2008 | B2 |
| 7379799 | Cleary et al. | May 2008 | B2 |
| 7379845 | Gorinevsky et al. | May 2008 | B2 |
| 7415606 | Tuvell et al. | Aug 2008 | B2 |
| 7444216 | Rogers et al. | Oct 2008 | B2 |
| 7447643 | Olson et al. | Nov 2008 | B1 |
| 7493482 | Ring et al. | Feb 2009 | B2 |
| 7522979 | Pillar | Apr 2009 | B2 |
| 7523133 | Mackie | Apr 2009 | B2 |
| 7593403 | Kalkunte et al. | Sep 2009 | B2 |
| 7596785 | Burkhardt et al. | Sep 2009 | B2 |
| 7606843 | Alexander et al. | Oct 2009 | B2 |
| 7617029 | Loda | Nov 2009 | B2 |
| 7710871 | Lavian et al. | May 2010 | B2 |
| 7757120 | Ogle et al. | Jul 2010 | B2 |
| 7761201 | Avery et al. | Jul 2010 | B2 |
| 7779039 | Weissman et al. | Aug 2010 | B2 |
| 7929562 | Petrovykh | Apr 2011 | B2 |
| 7950017 | Cain et al. | May 2011 | B1 |
| 7990857 | Jain et al. | Aug 2011 | B2 |
| 8054208 | Fletcher et al. | Nov 2011 | B2 |
| 8135995 | Ngai et al. | Mar 2012 | B2 |
| 8145444 | Bickford et al. | Mar 2012 | B1 |
| 8151141 | Bennett et al. | Apr 2012 | B1 |
| 8180594 | Stephan | May 2012 | B2 |
| 8191099 | Johnson et al. | May 2012 | B2 |
| 8214317 | Aguilar et al. | Jul 2012 | B2 |
| 8265980 | Ochs et al. | Sep 2012 | B2 |
| 8468601 | Bakhmutov | Jun 2013 | B1 |
| 8533536 | Yan et al. | Sep 2013 | B2 |
| 8615773 | Bishop et al. | Dec 2013 | B2 |
| 20020004694 | Mcleod et al. | Jan 2002 | A1 |
| 20020007237 | Phung et al. | Jan 2002 | A1 |
| 20020023118 | Peled et al. | Feb 2002 | A1 |
| 20020095597 | Norden et al. | Jul 2002 | A1 |
| 20020133651 | Wang et al. | Sep 2002 | A1 |
| 20040117791 | Prasad et al. | Jun 2004 | A1 |
| 20050038581 | Kapolka et al. | Feb 2005 | A1 |
| 20050060396 | Hirooka | Mar 2005 | A1 |
| 20050211072 | Lu et al. | Sep 2005 | A1 |
| 20050246719 | Oshins et al. | Nov 2005 | A1 |
| 20060095394 | Miller et al. | May 2006 | A1 |
| 20060200738 | Tarle et al. | Sep 2006 | A1 |
| 20070010923 | Rouyre | Jan 2007 | A1 |
| 20070022403 | Brandt et al. | Jan 2007 | A1 |
| 20070050719 | Lui et al. | Mar 2007 | A1 |
| 20070100520 | Shah et al. | May 2007 | A1 |
| 20070124189 | Stoughton et al. | May 2007 | A1 |
| 20070226540 | Konieczny | Sep 2007 | A1 |
| 20070256114 | Johnson et al. | Nov 2007 | A1 |
| 20080059621 | Raghavan et al. | Mar 2008 | A1 |
| 20080098351 | Weatherhead et al. | Apr 2008 | A1 |
| 20080119981 | Chen | May 2008 | A1 |
| 20080125877 | Miller et al. | May 2008 | A1 |
| 20080125933 | Williams et al. | May 2008 | A1 |
| 20080163172 | Rossmann et al. | Jul 2008 | A1 |
| 20080250118 | Ray | Oct 2008 | A1 |
| 20090094484 | Son et al. | Apr 2009 | A1 |
| 20090113088 | Illowsky et al. | Apr 2009 | A1 |
| 20090138139 | Tsai et al. | May 2009 | A1 |
| 20090138141 | Nwadiogbu et al. | May 2009 | A1 |
| 20090228519 | Purcell et al. | Sep 2009 | A1 |
| 20090249215 | Paek | Oct 2009 | A1 |
| 20090265055 | Gillies | Oct 2009 | A1 |
| 20090289756 | Raichle et al. | Nov 2009 | A1 |
| 20090295559 | Howell et al. | Dec 2009 | A1 |
| 20090300472 | Ambrosino et al. | Dec 2009 | A1 |
| 20100005470 | Simon et al. | Jan 2010 | A1 |
| 20100010702 | Gilbert | Jan 2010 | A1 |
| 20100042283 | Kell et al. | Feb 2010 | A1 |
| 20100043003 | Valdez et al. | Feb 2010 | A1 |
| 20100131241 | Dal Bello et al. | May 2010 | A1 |
| 20100138515 | Ruiz-Velasco et al. | Jun 2010 | A1 |
| 20100192005 | Das et al. | Jul 2010 | A1 |
| 20100217479 | Dahl et al. | Aug 2010 | A1 |
| 20100217638 | Dickson et al. | Aug 2010 | A1 |
| 20100229044 | Fountain et al. | Sep 2010 | A1 |
| 20100281119 | Durai | Nov 2010 | A1 |
| 20110010130 | Hadden et al. | Jan 2011 | A1 |
| 20110023079 | Schultz et al. | Jan 2011 | A1 |
| 20110060946 | Gupta et al. | Mar 2011 | A1 |
| 20110077817 | Sun et al. | Mar 2011 | A1 |
| 20110118905 | Mylaraswamy et al. | May 2011 | A1 |
| 20110191099 | Farmaner et al. | Aug 2011 | A1 |
| 20120023499 | Biran et al. | Jan 2012 | A1 |
| 20120079005 | Dent et al. | Mar 2012 | A1 |
| 20120150474 | Rentschler et al. | Jun 2012 | A1 |
| 20120151272 | Behrendt et al. | Jun 2012 | A1 |
| 20120158783 | Nice et al. | Jun 2012 | A1 |
| 20120198220 | Felke et al. | Aug 2012 | A1 |
| 20120254876 | Bishop et al. | Oct 2012 | A1 |
| 20120272099 | Keith, Jr. | Oct 2012 | A1 |
| 20120304164 | Felke et al. | Nov 2012 | A1 |
| 20130023203 | Kakaire | Jan 2013 | A1 |
| 20130073698 | Ling et al. | Mar 2013 | A1 |
| 20130097414 | Bishop et al. | Apr 2013 | A1 |
| 20130097459 | Bell et al. | Apr 2013 | A1 |
| 20130159790 | Likura et al. | Jun 2013 | A1 |
| 20130290794 | Murphy et al. | Oct 2013 | A1 |
| 20140201565 | Candea et al. | Jul 2014 | A1 |
| Number | Date | Country |
|---|---|---|
| 1933563 | Jun 2008 | EP |
| 2482159 | Aug 2012 | EP |
| 2527977 | Nov 2012 | EP |
| 2005025194 | Mar 2005 | WO |
| Entry |
|---|
| Bell, D. A., et al.: “Method for Performing Condition Based Data Acquisition in a Hierarchically Distributed Condition Based Maintenance System” filed Sep. 28, 2012 and assigned U.S. Appl. No. 13/630,906. |
| USPTO Office Action for U.S. Appl. No. 13/077,276 dated Feb. 8, 2013. |
| EP Search Report dated Feb. 7, 2013 for EP 12 187 309.5. |
| EP Office Action dated Feb. 19, 2013 for EP 12 187 309.5. |
| USPTO Notice of Allowance for U.S. Appl. No. 13/077,276 dated Apr. 12, 2013. |
| Fletcher, et al.; Re-Configurable Multipurpose Digital Interface, Filed with the USPTO on Apr. 27, 2010 and assigned U.S. Appl. No. 12/768,448. |
| Fletcher, et al.; Re-Configurable Multipurpose Analog Interface, Filed with the USPTO on Mar. 30, 2010 and assigned U.S. Appl. No. 12/750,341. |
| Goldstein, et al.; Vehicle System Monitoring and Communications Architecture, filed Jun. 29, 2009 and assigned U.S. Appl. No. 12/493,750. |
| Felke, et al.; Methods and Reconfigurable Systems to Optimize the Performance of a Condition Based Health Maintenance System, filed Jan. 28, 2011 and assigned U.S. Appl. No. 13/016,601. |
| Bishop, et al.; Systems and Methods for Coordinating Computing Functions to Accomplish a Task, filed Mar. 31, 2011 and assigned U.S. Appl. No. 13/077,276. |
| Bell, et al.; Methods and Systems for Distributed Diagnostic Reasoning, filed Oct. 14, 2011, and assigned U.S. Appl. No. 13/273,984. |
| Bishop, et al.; Systems and Methods for Augmenting the Functionality of a Monitoring Node without Recompiling, filed May 22, 2012 and assigned U.S. Appl. No. 13/477,735. |
| Bishop, D. L: Systems and Methods for Limiting User Customization of Task Workflow in a Condition Based Health Maintenance System, filed Aug. 10, 2012 and assigned U.S. Appl. No. 13/572,518. |
| USPTO Notice of Allowance for U.S. Appl. No. 13/077,276 dated Oct. 17, 2013. |
| Bishop D.L., et al; Systems and Methods for Coordinating Computing Functions to Accomplish a Task, filed Jun. 14, 2013, U.S. Appl. No. 13/918,584. |
| Coalition Solutions Integrated, Inc.—Products & Services; Program Management / Information Technology (IT); URL: http://coalitionsolutions.com/products2.html; retrieved from the internet on Dec. 7, 2010. |
| USPTO Office Action for U.S. Appl. No. 13/273,984 dated Nov. 4, 2013. |
| USPTO office action for U.S. Appl. No. 13/016,601 dated Nov. 8, 2013. |
| USPTO Notice of Allowance for U.S. Appl. No. 13/273,984 dated Dec. 23, 2013. |
| USPTO Notice of Allowance, Notification Date May 13, 2014; U.S. Appl. No. 13/477,735. |
| USPTO Notice of Allowance, Notification Date May 13, 2014; U.S. Appl. No. 13/572,518. |
| EP Search Report for Application No. EP 13 184 653.7 dated Feb. 25, 2014. |
| USPTO Office Action for U.S. Appl. No. 13/477,735 dated Mar. 17, 2014. |
| USPTO Office Action, Notification Date Sep. 25, 2014; U.S. Appl. No. 13/630,906. |
| USPTO Notice of Allowance and Fee(s) Due for U.S. Appl. No. 13/630,906 dated Jan. 20, 2015. |
| Number | Date | Country | |
|---|---|---|---|
| 20120304164 A1 | Nov 2012 | US |
