US20080222070A1 - Enhanced rule execution in expert systems - Google Patents
Enhanced rule execution in expert systems Download PDFInfo
- Publication number
- US20080222070A1 US20080222070A1 US11/684,165 US68416507A US2008222070A1 US 20080222070 A1 US20080222070 A1 US 20080222070A1 US 68416507 A US68416507 A US 68416507A US 2008222070 A1 US2008222070 A1 US 2008222070A1
- Authority
- US
- United States
- Prior art keywords
- data
- predefined rules
- rule
- rules
- extracted
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 claims abstract description 119
- 238000012545 processing Methods 0.000 claims abstract description 47
- 238000001514 detection method Methods 0.000 claims abstract description 44
- 238000007781 pre-processing Methods 0.000 claims abstract description 7
- 238000003384 imaging method Methods 0.000 claims description 35
- 238000013500 data storage Methods 0.000 claims description 27
- 230000008569 process Effects 0.000 claims description 22
- 230000009471 action Effects 0.000 claims description 10
- 238000013170 computed tomography imaging Methods 0.000 claims description 3
- 238000012285 ultrasound imaging Methods 0.000 claims description 3
- 238000002600 positron emission tomography Methods 0.000 claims description 2
- 238000002595 magnetic resonance imaging Methods 0.000 claims 1
- 238000009206 nuclear medicine Methods 0.000 claims 1
- 238000002059 diagnostic imaging Methods 0.000 description 33
- 230000003936 working memory Effects 0.000 description 19
- 230000014509 gene expression Effects 0.000 description 15
- 230000006870 function Effects 0.000 description 12
- 238000007620 mathematical function Methods 0.000 description 8
- 238000010586 diagram Methods 0.000 description 7
- 230000003287 optical effect Effects 0.000 description 7
- 239000000523 sample Substances 0.000 description 7
- 238000012360 testing method Methods 0.000 description 6
- 238000004422 calculation algorithm Methods 0.000 description 5
- 238000002591 computed tomography Methods 0.000 description 5
- 238000007689 inspection Methods 0.000 description 5
- 230000036541 health Effects 0.000 description 4
- 230000002708 enhancing effect Effects 0.000 description 3
- 230000015654 memory Effects 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 230000003292 diminished effect Effects 0.000 description 2
- 201000010099 disease Diseases 0.000 description 2
- 208000037265 diseases, disorders, signs and symptoms Diseases 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 239000007788 liquid Substances 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000009466 transformation Effects 0.000 description 2
- 238000002604 ultrasonography Methods 0.000 description 2
- 238000010521 absorption reaction Methods 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 210000003484 anatomy Anatomy 0.000 description 1
- 238000013473 artificial intelligence Methods 0.000 description 1
- 210000004556 brain Anatomy 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000011217 control strategy Methods 0.000 description 1
- 230000001066 destructive effect Effects 0.000 description 1
- 230000005672 electromagnetic field Effects 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 238000010304 firing Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000012634 optical imaging Methods 0.000 description 1
- 230000009897 systematic effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 238000012800 visualization Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/2257—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using expert systems
Definitions
- the invention relates generally to expert systems, and more particularly to rule-based systems.
- Rule-based artificial intelligence systems typically include a set of rules, one or more facts or data in a working memory, and an inference engine that applies the rules to the facts in the working memory. Further, an inference engine generally performs the steps of matching a collection of objects to a given rule, selecting a rule from a list of rules whose conditions are completely matched by the objects, and execution of the selected rule.
- inference engines typically match facts (data) against business rules, to infer conclusions, which then result in actions. Furthermore, during the execution of the selected rule step, the inference engine performs an existence test in connection with the conditions in the rule. Additionally, the inference engine performs a pattern matching step, which entails matching the new or existing facts against business rules. Unfortunately, the matching process in the inference engine is the most time consuming phase as each rule is compared against all objects.
- a method for fault detection includes extracting data based upon one or more predefined rules. Further, the method includes preprocessing the extracted data based on the predefined rules to generate one or more rule groups. The method also includes instantiating one or more inference engines based on the generated rule groups. Additionally, the method includes processing the extracted data by a corresponding inference engine based on the predefined rules to generate processed data.
- Computer-readable medium that afford functionality of the type defined by this method is also contemplated in conjunction with the present technique.
- a detection system includes an extractor module configured to extract data based upon one or more predefined rules.
- the detection system includes a processing module configured to compute data based on the predefined rules, evaluate a rule condition affinity of the predefined rules, and group the predefined rules based on the evaluated rule affinity to generate one or more rule groups.
- the detection system includes an interpreter module configured to interpret the extracted data based on the predefined rules to generate output data.
- a system in accordance with further aspects of the present technique, includes a data source, where the data source comprises an acquisition subsystem configured to acquire data, and a processing subsystem in operative association with the acquisition subsystem and configured to process the acquired data and generate log data. Furthermore, the system includes a data storage subsystem configured to store the log data. In addition, the system includes a detection subsystem in operative association with the data storage subsystem and configured to extract data based upon one or more predefined rules, preprocess the extracted data based on the predefined rules to generate one or more rule groups, instantiate one or more inference engines based on the generated rule groups, and process the extracted data by a corresponding inference engine based on the predefined rules to generate processed data.
- the data source comprises an acquisition subsystem configured to acquire data
- a processing subsystem in operative association with the acquisition subsystem and configured to process the acquired data and generate log data.
- the system includes a data storage subsystem configured to store the log data.
- the system includes a detection subsystem in operative association with the data
- FIG. 1 is a block diagram of an exemplary diagnostic system, in accordance with aspects of the present technique
- FIG. 2 is a block diagram of an imaging system in the diagnostic system of FIG. 1 , in accordance with aspects of the present technique;
- FIG. 3 is a block diagram of an exemplary rule-based system, in accordance with aspects of the present technique
- FIG. 4 is a block diagram of a portion of the exemplary rule-based system of FIG. 3 , in accordance with aspects of the present technique
- FIGS. 5A and 5B are flow charts illustrating an exemplary process for fault detection, in accordance with aspects of the present technique
- FIG. 6 is a flow chart illustrating an exemplary process of extracting data, in accordance with aspects of the present technique
- FIG. 7 is a flow chart illustrating an exemplary process of processing data, in accordance with aspects of the present technique.
- FIG. 8 is a diagrammatic illustration of a system log file, in accordance with aspects of the present technique.
- FIG. 9 is a diagrammatic illustration of predefined rules, in accordance with aspects of the present technique.
- FIG. 10 is a diagrammatic illustration of an information of interest table, in accordance with aspects of the present technique.
- FIG. 11 is a diagrammatic illustration of a predefined functions table, in accordance with aspects of the present technique.
- FIG. 12 is a diagrammatic illustration of an output data table, in accordance with aspects of the present technique.
- the system for detection may be configured to facilitate substantially faster execution of the rules in the inference engine of the rule-based system, thereby simplifying the workflow of the rule-based system and optimizing the performance of the rule-based system.
- FIG. 1 is a block diagram of an exemplary system 10 for use in diagnostic imaging in accordance with aspects of the present technique.
- the system 10 may be configured to acquire image data from a patient 12 via an image acquisition device 14 .
- the image acquisition device 14 may include a probe, where the probe may include an invasive probe, or a non-invasive or external probe, such as an external ultrasound probe, that is configured to aid in the acquisition of image data.
- image data may be acquired via one or more sensors (not shown) that may be disposed on the patient 12 .
- the sensors may include physiological sensors (not shown) such as electrocardiogram (ECG) sensors and/or positional sensors such as electromagnetic field sensors or inertial sensors. These sensors may be operationally coupled to a data acquisition device, such as an imaging system, via leads (not shown), for example.
- ECG electrocardiogram
- sensors may be operationally coupled to a data acquisition device, such as an imaging system, via leads (not shown), for example.
- the system 10 may also include an imaging system 18 that is in operative association with the image acquisition device 14 .
- the imaging system 18 may include a medical imaging system. It may he noted that although the present example illustrates the diagnostic system 10 as including one imaging system 18 , the diagnostic system 10 may include more than one imaging system.
- exemplary embodiments illustrated hereinafter are described in the context of a medical imaging system, other imaging systems and applications such as industrial imaging systems and non-destructive evaluation and inspection systems, such as pipeline inspection systems, liquid reactor inspection systems, are also contemplated. Additionally, the exemplary embodiments illustrated and described hereinafter may find application in multi-modality imaging systems that employ ultrasound imaging in conjunction with other imaging modalities, position-tracking systems or other sensor systems.
- a medical imaging system such as, but not limited to, an ultrasound imaging system, an optical imaging system, a computed tomography (CT) imaging system, a magnetic resonance (MR) imaging system, an X-ray imaging system, or a positron emission tomography (PET) imaging system
- CT computed tomography
- MR magnetic resonance
- PET positron emission tomography
- other imaging systems such as, but not limited to, a pipeline inspection system, a liquid reactor inspection system, or other imaging systems are also contemplated in accordance with aspects of the present technique.
- the medical imaging system 18 may also be configured to generate one or more log files.
- a log file may be representative of a file that lists actions that have occurred. More particularly, the log file may include functions and activities performed by the imaging system 18 , often in a time-associated format, for example. Furthermore, the log file may include data representative of events, errors, machine critical parameters, sensor outputs, or a combination thereof.
- log files generated by a medical imaging system such as the medical imaging system 18 , may include information indicative of a machine state. The machine state information may be employed to detect failures associated with the medical imaging system 18 .
- the log file may include machine-readable data.
- the image data acquired via the medical imaging system 18 may be stored in a database, for example. Additionally, the log files generated by the medical imaging system 18 may be communicated to a first storage 22 .
- the first storage 22 may include a data storage system.
- the data storage system 22 may be at a location that is physically remote from the location of the medical imaging system 18 . However, as will be appreciated, in certain embodiments, the data storage system 22 may be disposed in substantially close proximity to the medical imaging system 18 .
- the image data may be communicated to the data storage system 22 via a network 20 .
- the one or more log files may also be communicated to the data storage system 22 via the network 20 .
- other means of communication such as, but not limited to, the Internet, the intranet, or wireless communication may also be employed to transmit the log files from the medical imaging system 18 to the data storage system 22 .
- the log files may be transmitted to the data storage system 22 in real-time.
- the log files may be temporarily stored in a temporary storage and communicated to the data storage system 22 at a later time.
- the data storage system 22 may include a data acquisition subsystem 24 , where the data acquisition subsystem 24 may be configured to receive the log files transmitted from the medical imaging system 18 via the network 20 .
- the log files received by the data acquisition system 24 may be stored in a data repository 26 .
- the data repository 26 may include an archival site, a database, or an optical data storage article.
- the optical data storage article may be an optical storage medium, such as a compact disc (CD), a digital versatile disc (DVD), multi-layer structures, such as DVD-5 or DVD-9, multi-sided structures, such as DVD- 10 or DVD-18, a high definition digital versatile disc (HD-DVD), a Blu-ray disc, a near field optical storage disc, a holographic storage medium, or another like volumetric optical storage medium, such as, for example, two-photon or multi-photon absorption storage format.
- CD compact disc
- DVD digital versatile disc
- multi-layer structures such as DVD-5 or DVD-9
- multi-sided structures such as DVD- 10 or DVD-18
- HD-DVD high definition digital versatile disc
- Blu-ray disc a near field optical storage disc
- a holographic storage medium such as, for example, two-photon or multi-photon absorption storage format.
- the diagnostic system 10 may also include detection module 28 , where the detection module 28 may be configured to aid in proactive detection and predictive detection.
- the working of the detection module 28 will be explained in greater detail with reference to FIGS. 3-12 .
- the imaging system 40 may be configured to acquire image data from the patient 12 (see FIG. 1 ) via the image acquisition device 14 (see FIG. 1 ), as previously noted with reference to FIG. 1 .
- the medical imaging system 40 may include an acquisition subsystem 42 and a processing subsystem 44 .
- the acquisition subsystem 42 of the medical imaging system 40 may be configured to acquire image data representative of one or more anatomical regions of interest in the patient 12 via the image acquisition device 14 .
- the image data acquired from the patient 12 may then be processed by the processing subsystem 44 .
- the image data acquired and/or processed by the medical imaging system 40 may be employed to aid the clinician in identifying disease states, assessing need for treatment, determining suitable treatment options, and/or monitoring the effect of treatment on the disease states.
- the processing subsystem 44 may be further coupled to a local storage system, such as a local data repository 46 , where the local data repository 46 is configured to receive image data.
- the medical imaging system 18 may also be configured to generate one or more log files, where the data in the log files is representative of an event, an error, a machine state, machine critical parameters, sensor outputs, or a combination thereof.
- the processing subsystem 44 may be configured to generate the one or more log files.
- the medical imaging system 40 may include a display 48 and a user interface 50 .
- the display 48 and the user interface 50 may overlap.
- the display 48 and the user interface 50 may include a common area.
- the display 48 of the medical imaging system 40 may be configured to display an image generated by the medical imaging system 40 based on the image data acquired via the image acquisition device 14 .
- information of interest retrieved from the log files may be visualized on the display 48 , and will be described in greater detail with reference to FIGS. 3-12 .
- the user interface 50 of the medical imaging system 40 may include a human interface device (not shown) configured to facilitate the clinician in organizing and/or managing image data displayed on the display 48 .
- the human interface device may include a mouse-type device, a trackball, a joystick, a stylus, or a touch screen.
- other human interface devices such as, but not limited to, a touch screen, may also be employed.
- the user interface 50 may be configured to aid the clinician in manipulating and/or organizing the information displayed on the display 48 , and will be described in greater detail with reference to FIGS. 3-12 .
- FIG. 3 a block diagram 60 of one embodiment of a rule-based system 60 including the detection module 28 of FIG. 1 is depicted.
- reference numerals 62 , 64 and 66 are representative of a plurality of log files obtained from one or more data sources, such as imaging systems.
- the log files 62 , 64 and 66 respectively correspond to log files obtained from different imaging modalities.
- the log files 62 , 64 and 66 may be representative of log files generated by the single imaging modality but stored in different formats.
- the detection module 28 (see FIG. 1 ) of the diagnostic system 10 (see FIG. 1 ) is configured to aid in the analysis of the log file, for example. Accordingly, the one or more log files 62 , 64 , 66 may be processed by the detection module 28 .
- the detection module 28 may include an extractor module 70 , a processing module 72 , and an interpreter module 74 . Additionally, in certain embodiments, the detection module 28 may also include a formatter module 68 . The working of the formatter module 68 , the extractor module 70 , the processing module 72 , and the interpreter module 74 will be described in greater detail hereinafter.
- the formatter module 68 may be configured to format the data in the input files 62 , 64 , 66 . More particularly, the formatter module 68 may be configured to convert the data from a native format to a common format.
- the term native format is representative of a format that a system typically employs to log data.
- the term common format is indicative of a standard format that aids in simplifying the process of identifying and extracting parametric data points.
- the medical imaging system 18 may log the data into the input file 62 in a native format, where the native format may include a text format.
- the formatter module 68 may be configured to convert the native text format of the data in the input file 62 to a common format.
- the machine data in the input file 62 may be categorized into three types of common data format, namely, the parametric log format, the error event log format, and the system tracker log format. Accordingly, converting the format of the data in the input files to a common format simplifies the process of identifying and extracting information of interest from the log data downstream.
- the extractor module 70 may be configured to extract information of interest from the input log file, such as log file 62 , for example. More particularly, in accordance with exemplary aspects of the present technique, the extractor module 70 may be configured to extract information of interest from the log file 62 based upon one or more predefined rules.
- the predefined rules may be stored in a second storage 80 , in one embodiment.
- the second storage 80 may include a rules database that is configured to store the predefined rules.
- An example of a set of predefined rules that is stored in the rules database 80 will be described in greater detail with reference to FIG. 9 .
- the term “rule” may be used to refer to a predefined constraint that typically encompass any and all actions that should be taken within the scope of a problem. These rules may be collectively referred to a rule base, where the rule base may contain all of the knowledge associated with the rule-based system.
- the rules may be typically encoded into IF-THEN rules.
- a rule-based system may examine all the rule conditions (IF) and determine a subset, the conflict set, of the rules whose conditions are satisfied based on a working memory, where the working memory may include any data, assertions or initially known information. Subsequently, one of the rules chosen from the conflict set based on a conflict resolution strategy may be triggered. Following the triggering of a rule, any actions specified in the corresponding THEN clause may be carried out. These actions may modify the working memory, the rule-base, or execute any actions specified by the THEN clause.
- one form of the rule is a business rule.
- a business rule may be configured to define and/or constrain an aspect of a business. Further, the business rule may be specified in formats different from the IF-THEN format.
- the predefined rules may be representative of information associated with the status of a system, such as the medical imaging system 18 (see FIG. 1 ).
- the predefined rules may be employed to aid in detecting system status or health of the medical imaging system 18 .
- a predefined set of parameters may be associated with a given imaging modality, where the imaging modality may include an imaging system, such as, but not limited to, an ultrasound system, an X-ray system, a MR imaging system, a CT imaging system, or a combination thereof.
- the predefined rules may include a set of parameters associated with a CT imaging system, where the parameters may include a speed, a temperature, a pressure, number of disks, or percentage of disk usage.
- the predefined rules may also include one or more indicators, where the indicators may be associated with one or more parameters.
- an indicator associated with a temperature parameter may include an average of the temperature parameter recorded during a predetermined interval.
- the predefined rules may include one or more rules based on various combinations of the associated parameters and/or indicators.
- a set of rules may be defined for each of the imaging modalities, where the rules may include parameter-based rules and/or indicator-based rules.
- the predefined rules may also include other expressions to be extracted from the log file, where the expressions may be representative of error codes generated by the imaging system 18 , for example. It may be noted that the terms expressions to be extracted and tokens may be used interchangeably.
- the extractor module 70 may be configured to search data in the log file 62 for matching information of interest and extract the information of interest from the log file 62 .
- the information of interest to be extracted may include one or more parameters, one or more indicators, one or more error codes, or combinations thereof. Additionally, the information of interest may be employed to detect status and/or health of the medical imaging system 18 , for instance. The information of interest may also be used for predictive detection and/or proactive detection.
- the predefined rules may be stored in the rules database 80 , as previously noted.
- the extractor module 70 may be configured to query the rules database 80 to obtain the one or more predefined rules.
- the extractor module 70 may be configured to query the rules database 80 to obtain data associated with the information of interest to be extracted.
- data associated with the information of interest to be extracted may be stored in a separate file, such as the information of interest file (see FIG. 10 ).
- the information of interest file may be stored in the data storage system 22 , for instance.
- the extractor module 70 may be further configured to parse through the data in the log file 62 to extract the information of interest based upon the information of interest file and the predefined rules. Techniques, such as, but not limited to, standard file reading techniques, regular expression techniques, or transformation techniques may be employed by the extractor module 70 to parse through the log file 62 to extract the information of interest.
- the log file 62 may include a substantial amount of data.
- a log file may typically have a size in a range from about 100 kilobytes to about 100 megabytes.
- the extractor module 70 may thus be configured to parse through a large amount of data in the log file 62 and extract only the information of interest indicated in the information of interest file and the predefined rules.
- the extractor module 70 may search through the log file 62 for matches based on the information of interest to be extracted.
- the extractor module 70 may be configured to search for an exact match of the information of interest to be extracted. However, a near match of the information of interest may also be extracted from the log file 62 .
- the extractor module 70 may also be configured to apply proximity matching techniques to extract the information of interest from the log file 62 .
- the information of interest may be extracted based on the predefined rules.
- the extracted information of interest may be saved in the data storage system 22 (see FIG. 1 ).
- the extracted information of interest may be saved in an output file configured to only include the information of interest that has been extracted from the log file 62 .
- the information of interest to be extracted may include the parameters, indicators, and/or error codes listed in the predefined rules. Consequently, the extracted data may include information associated with the parameters, indicators, and/or error codes.
- the working of the extractor module 70 will be described in greater detail with reference to FIGS. 4-12 .
- the size of the data to be processed downstream is substantially reduced as non-pertinent information is filtered out from the log file based on the predefined rules. In other words, only relevant information of interest is extracted from the log file for further processing downstream, thereby enhancing the efficiency and speed of the rule-based system.
- the processing module 72 may be configured to process the extracted information of interest in light of the predefined rules stored in the rules database 80 .
- the processing module 72 may also be configured to process the log data stored in data storage system 22 , for example. The working of the processing module 72 will be described in greater detail with reference to FIG. 4 .
- the data processed by the processing module 72 may then be communicated to an interpreter module 74 .
- the interpreter module 74 may include an inference engine.
- an inference engine may be defined as a computer program that is configured to derive answers from a knowledge base.
- the inference engine 74 may be referred to as the “brain” that expert systems use to reason about the information in the knowledge base for the ultimate purpose of formulating new conclusions.
- the inference engine 74 may include a working memory 76 and a pattern matcher 78 .
- the working memory 76 may be defined as a workspace including a small set of data items representing the current state of knowledge of a system, such as the medical imaging system 18 (see FIG. 1 ), at any stage in the performance of a task, and where the knowledge of the system is transformed into a new set on the firing of a new rule.
- the working memory 76 may be configured to serve as a global database of symbols representing facts or assertions about a given problem.
- the inference engine 74 may be described as a form of finite state machine with a cycle consisting of three action states: match rules, select rules, and execute rules, where the rules may include the predefined rules obtained from the rules database 80 .
- match rules the inference engine 74 may be configured to find all of the rules that are satisfied by the current contents of the working memory 76 .
- the rules are generally in a condition-action form. Consequently, the conditions may be tested against the working memory 76 .
- the pattern matcher 78 may be utilized to test the conditions against the working memory 76 , in certain embodiments.
- the rule matchings that may be found are all candidates for execution and may be collectively referred to as a conflict set, as previously noted. It may be noted that a particular rule may appear several times in the conflict set if that rule matches different subsets of data items.
- the pair of a rule and a subset of matching data items may be generally referred to as an instantiation of the rule.
- the inference engine 74 may be configured to pass along the conflict set to the second state, select rules.
- the inference engine 74 may be configured to apply a selection strategy to determine which rules will actually be executed.
- the selection strategy may be hard-coded into the inference engine 74 or may be specified as part of the model.
- the selected instantiations may be passed over to the third state, execute rules.
- the inference engine 74 may be configured to execute or fire the selected rules with the data items associated with the rule instantiation as parameters.
- the inference engine 74 may then be configured to cycle back to the first state and start over again. This control mechanism is generally referred to as the recognize-act cycle. Also, the inference engine 74 may be configured to stop either on a given number of cycles, controlled by the operator, or on a quiescent state of the data when no rules match the data. Subsequently, the inference engine 74 may be configured to determine which rules are relevant to a given data configuration and choose which one to apply. The control strategy used to select rules is generally referred to as conflict resolution.
- the inference engine 74 may be configured to find all of the rules that are satisfied by the current contents of the working memory 76 by testing the conditions against the working memory 76 . Furthermore, the computation of the conflict set may result in a non-trivial problem, especially while handling a large volume of data and/or when the rules include complex calculations. More particularly, complex rules entail testing and retesting conditions for each rule against all the supplied facts, thereby resulting in a time-consuming and cumbersome process.
- the number of facts presented to the inference engine 74 to be tested against the conditions of each rule may be substantially reduced by pre-computing the facts outside the scope of the inference engine 74 , thereby dramatically improving the performance of the inference engine 74 .
- the processing module 72 may be configured to pre-process the extracted data in light of the predefined rules.
- the working of the processing module 72 may be better understood with reference to FIG. 4 .
- FIG. 4 one embodiment of a portion 90 of the rule-based system 60 of FIG. 3 is illustrated.
- Reference numeral 92 is representative of extracted data generated by the extractor module 70 (see FIG. 3 ).
- the processing module 72 may include a pre-computation module 96 , in one embodiment.
- the pre-computation module 96 may be configured to aid in enhancing the performance of the rule-based system 60 by pre-calculating any computations of the extracted data as specified by the predefined rules outside the scope of the inference engine 74 (see FIG. 3 ).
- the working of the pre-computation module 96 may be better understood with reference to the following example.
- a predefined rule may include a condition such as:
- B includes 100 or more facts in the working memory 76 (see FIG. 3 )
- use of the presently available techniques entails laborious computation of the average D of each of the 100 or more facts of B, thereby resulting in diminished performance of inference engine 74 in the rule-based system 60 .
- the computation of the average D may be performed outside the scope of the inference engine 74 .
- the average D of the 100 or more facts of B may be computed via the pre-computation module 96 . Subsequently, this pre-computed result D may be passed as a fact for the inference engine 74 for further processing.
- any calculations associated with the extracted data set defined in the predefined rules may be pre-computed outside the scope of the inference engine 74 and the pre-computed result may be passed as a fact to the inference engine 74 , thereby advantageously resulting in faster execution and substantially fewer memory allocations as the working memory 76 is now configured to operate with a substantially smaller number of facts representative of the extracted data.
- the complexity of the rule logic handled by the inference engine 74 is dramatically simplified as the inference engine 74 is now configured to work with indicators that are representative of the extracted data set.
- the extracted data may also be categorized into one or more rule groups based on a rule condition affinity. These rule groups may then be separately and simultaneously processed by a corresponding inference engine. More particularly, once the rule groups are -formed, the processing module 72 may be configured to instantiate a number of inference engines, where the number of instances of inference engines may be configured to correspond to the number of rule groups. This rule grouping based on the rule condition affinity may be better understood with the aid of the following example having the following set of business rules:
- parameters A, B, C and D may be defined as including:
- the processing module 72 may also include a rule grouping module 98 , in certain embodiments.
- the rule grouping module 98 may be configured to group the rules in the rules database 80 into one or more rule groups based on a rule condition affinity.
- rule execution in the inference engine involves an existence test in connection with the conditions in the rule. More particularly, the currently available techniques typically employ one inference engine.
- the single inference engine having the business rules R1, R2 and R3 respectively in the working memory performs the existence tests of rule condition “C” of R2 against all the facts of the other rules R1 and R3.
- this use of a single inference engine results in a degraded performance of the rule-based system as the rule condition “C” has to be checked against 1600 data points of A, B and D of rules R1 and R3.
- the degraded performance of such a system may be advantageously enhanced by grouping rules that have a rule condition affinity, in accordance with exemplary aspects of the present technique.
- the grouping of rules may be based on a number of data points or facts, number of rules, number of similar rule conditions, or a combination thereof.
- parameter “A” is common between rules R1 and R3. Accordingly, rules R1 and R3 may be grouped together in a first rule group, while rule R2 may be included in a second rule group.
- the processing module 72 may be configured to instantiate one or more inference engines depending on the number of rule groups.
- the processing module 72 may be configured to instantiate two instances of the inference engine, where a first inference engine may be configured to process the first rule group having rules R1 and R3, while the second rule group having rule R2 may be processed by a second inference engine. It may be noted that with this grouping of rules, the number of inference engines in the rule-based system may be substantially equivalent to the number of rule groups.
- performance of the rule-based system 60 may be dramatically enhanced as each of the inference engine is now configured to process a relatively smaller data set. Furthermore, the speed of the rule-based system 60 may be increased as the instances of the inference engines may be configured to run simultaneously.
- reference numeral 100 may be representative of a number of instances of inference engines in the rule-based system 60 .
- the illustrated example of FIG. 4 shows N instances of inference engines.
- a first inference engine is represented by reference numeral 102 , where the first inference engine 102 may be configured to have a first working memory 104 and a first pattern matcher 106 .
- a second inference engine 108 may include a second working memory 110 and a second pattern matcher 112 .
- Reference numeral 114 is generally indicative of an Nth inference engine, where the Nth inference engine 114 is shown as including an Nth working memory 116 and an Nth pattern matcher 118 .
- the first inference engine 102 and the second inference engine 108 may be instantiated by the processing module 72 .
- the first rule group having rules R1 and R3 may be processed via the first inference engine 102
- the second inference engine 108 may be utilized to process the second rule group having the rule R2.
- output data generated consequent to processing by a corresponding inference engine may be stored in a third storage, such as a data repository 82 .
- the output data may also be stored in the data storage system 22 .
- the detection module 28 may be configured to aid in the proactive and predictive detection of the health of a system, such as the medical imaging system 18 (see FIG. 1 ).
- the working of the detection module 28 may be better understood with reference to the exemplary logic depicted in FIGS. 5-12 .
- FIGS. 5A-5B flow charts of exemplary logic 130 for detection are illustrated. In accordance with exemplary aspects of the present technique, a method for processing data based on predefined rules is presented.
- the method starts at step 134 , where on receiving a log file, such as the input file 132 , a system log file configured to store relevant information associated with the input log file may be generated.
- the data storage system 22 may be configured to generate the system log file and store the relevant information associated with the input log file in the system log file.
- Step 134 may be better understood with reference to FIG. 8 .
- FIG. 8 an example 190 of a system log file, in accordance with aspects of the present technique, is depicted.
- the system log file 190 may be generated when the rule-based system receives a log file, such as input file 132 (see FIG. 5 ) for processing.
- the system log file 190 is depicted as including information associated with three log files, including a first log file (GeSysLog) 192 , a second log file (Err_event log) 194 and a third log file (LOG_TTT) 196 .
- the three log files 192 , 194 , 196 may be representative of log files generated by the same medical imaging system.
- the three log files 192 , 194 , 196 may represent log files generated by three different medical imaging systems, for example.
- Reference numeral 198 is representative of a name of the input log file, while an identification number of the input log file may be generally represented by reference numeral 200 . Additionally, a description of the input log file may be indicated by reference numeral 202 . Further, reference numeral 204 may be representative of a format of the input log file. In one embodiment, a Boolean expression “IS_COMMON_FORMAT” may be employed to indicate if the data in the input log file is in conformance with a common data format.
- the common data format may include a parametric log format, an error event log format, or a system tracker log format, as previously noted.
- a check may be carried out at step 136 to verify if the data in an input log file 132 is in a common format. If it is determined that the data in the input log file 132 is not in a common format, then the data may be converted to conform to a common format, as indicated by step 138 . However, if at decision block 136 it is verified that the data in the input log file 132 is in conformance with a common format, then step 138 may be skipped. Steps 136 - 138 may be better understood with reference to the system log file 190 of FIG. 8 .
- the data in the input log file 132 may be passed on for further processing downstream.
- the data in the input log file 132 may be converted to a common data format.
- the input log file 132 includes the Err_event log file 194 , it may be noted that the input log file 132 includes data that is in conformance with the common data format as indicated by the “IS_COMMON_FORMAT” expression 204 .
- the data in the log files 192 , 196 include data that is not in the common format as indicated by the “IS_COMMON_FORMAT” expression 204 . Accordingly, the data in the input log files 192 , 196 may be converted to the common data format as specified by a corresponding “COMMON_LOG_REF” expression 206 .
- the “COMMON_LOG_REF” has a value of “2” associated with both the GeSysLog file 192 and LOG_TTT file 196 , where “2” is representative of the identifier of the Err-event log file 194 . Accordingly, the data in the input log files 192 , 196 may be converted to data having a format substantially similar to the data in the Err_event log file 194 .
- the data in the input file 132 may be configured to be in a predefined common format.
- a check may be carried out, at step 136 , to verify if the data in the input log file 132 is in a common data format by checking the “IS_COMMON_FORMAT” expression 204 (see FIG. 8 ) of the system log file 190 . If the data is in conformance with the common data format, then the data may be passed on to the subsequent processing steps.
- the data in the input file 132 may be converted to a common data format indicated by the “COMMON_LOG_REF” expression 206 (see FIG. 8 ), at step 138 .
- the data in an input log file 132 may be parsed based upon one or more predefined rules.
- the present embodiment is described in terms of the data source including a previously stored file, such as a log file, it will be appreciated that step 140 may also be configured to process a real-time data stream. Additionally, the data in the input log file 132 may include machine-readable date, as previously noted.
- the data in the input log file 132 may be parsed based on one or more predefined rules.
- information of interest may be extracted from the input file 132 based upon the predefined rules.
- an information of interest file may be generated based on the predefined rules, where the information of interest file may be configured to include information associated with parameters to be extracted and/or indicators to be computed.
- the information of interest file may be stored in the data storage system 22 (see FIG. 1 ), in one embodiment.
- Step 140 that entails the extraction of the data in the input log file 132 may be better understood with reference to FIG. 6 .
- a flow chart of exemplary logic for performing step 140 (see FIG.
- step 140 includes extracting data from the input log file 132 based on the predefined rules is illustrated.
- the predefined rules are stored in the rules database 80 (see FIG. 3 ). Accordingly, step 140 may entail retrieval of the predefined rules from the rules database 80 , as depicted in step 152 . In other words, the rules database 80 may be queried to obtain the predefined rules.
- FIG. 9 An example 220 of predefined rules stored in the rules database 80 (see FIG. 3 ) for use in the diagnostic system 10 (see FIG. 1 ) is illustrated in FIG. 9 .
- the sample database 220 is shown as including six rules. More particularly, the sample rules database 220 is shown as including a first rule Rule1 222 , a second rule Rule2 224 , a third rule Rule3 226 , a fourth rule Rule4 228 , a fifth rule Rule5 230 , and a sixth rule Rule6 232 .
- Reference numeral 234 may be representative of a rule name, while an identifier associated with a corresponding rule may be indicated by reference numeral 236 .
- a description associated with a corresponding rule may generally be represented by reference numeral 238 .
- a source of the rule may be represented by reference numeral 240 .
- the source 240 may include the definition of the rule, in one embodiment.
- a type of system where the rule may find application may be represented by reference numeral 242 .
- Rule1 222 , Rule5 230 and Rule6 232 may find application in both the CT/HELIOS system and the CT/LIGHTSPEED system, while Rule2 224 , Rule3 226 and Rule4 228 may be applied to only the CT/HELIOS system.
- data may be extracted from the input file 132 based on the rules obtained from the rules database 80 . More particularly, information of interest may be extracted from the data in the input file 132 , where the information of interest may be deduced from the rules in the rules database 80 .
- the information of interest may include one or more parameters, one or more indicators, or combinations thereof, as previously noted.
- the information of interest may be obtained from the rules in the rules database 80 .
- information of interest may include parameters “A”, “B”, “C”, “D”, “H”, “I”, and “J” and indicators “E”, “F”, and “G”.
- a table may be generated to include the information of interest to be extracted from the input file 132 , where the information of interest is obtained from the predefined rules stored in the rules database 80 .
- An example table 250 of information of interest to be extracted from the input file 132 is illustrated in FIG. 10 . It may be noted that the information of interest table 250 may be stored in the data storage system 22 , in one embodiment. In the illustrated example, the information of interest table 250 is depicted as including ten (10) variables 252 , where the variables may include “A”, “B”, “C”, “D”, “E”, “F”, “G”, “H”, “I”, and “J” obtained from the rules 222 - 232 of FIG. 9 .
- variables 252 may be representative of parameters to be extracted from the input file 132 or indicators to be computed.
- reference numeral 254 is representative of names of the variables 252
- reference numeral 256 is representative of identifiers associated with the variables 252 .
- a description of the variables 252 may be generally represented by reference numeral 258 .
- reference numeral 260 may be indicative of a type of log file associated with the variables 252 .
- the type of log file may be represented by an expression LOG_TYPE_REF.
- LOG_TYPE_REF may be representative of a type of log file listed in the system log file 190 (see FIG. 8 ). For example, if a variable 252 , such as “A”, has a LOG_TYPE_REF 260 of “1”, then the variable “A” may be extracted from the GeSysLog file 192 (see FIG. 8 ) having an identifier of “1”.
- variable 252 such as “H”
- the variable “H” may be extracted from the LOG_TTT file 196 (see FIG. 8 ) having an identifier of “3”.
- reference numeral 262 may be indicative of a type of variable 252 .
- An expression PARAM_TYPE may be representative of the type of variable 252 . More particularly, a value in the “PARAM_TYPE” expression 262 may be employed to indicate if a given variable 252 is a parameter or an indicator.
- variables “A”, “B”, “C”, “D”, “H”, “I”, and “J” are depicted as being of a “PARAMETER” type. Accordingly, the variables “A”, “B”, “C”, “D”, “H”, “I”, and “J” may be directly extracted from the input file 132 .
- the variables “E”, “F”, and “G” are depicted as an “INDICATOR” type. Hence, these indicator variables “E”, “F”, and “G” may be computed based upon a corresponding description 258 .
- the variables “E”, “F”, and “G” may be computed as:
- FREQ_COUNT and MAX may be obtained from a predefined functions table, for example.
- An example 280 of a predefined functions table is illustrated in FIG. 11 .
- Reference numeral 282 , 284 , 286 , and 288 may be representative of mathematical functions, for example.
- reference numeral 282 is representative of a FREQ_COUNT function
- an AVERAGE function may be generally represented by reference numeral 284 .
- a MIN function may be depicted by reference numeral 286
- reference numeral 288 may be representative of a MAX function.
- reference numeral 290 is indicative of a name of the mathematical function, while an identifier associated with the mathematical function may be represented by reference numeral 292 . Additionally, a description associated with a given mathematical function may be represented by reference numeral 294 , while a corresponding function that may be called may generally be represented by reference numeral 296 . It may be noted that “FUNCTION_REF” 296 may include a name of an associated function that may be called.
- the present example of the predefined functions table 280 is illustrated as including mathematical functions, it may be noted that other expressions are also contemplated in conjunction with the present technique.
- reference numeral 264 may be indicative of a pre-processing function associated with a given indicator. More particularly, a “PREPROCESSOR_REF” value 264 may be associated with an indicator variable, such as indicator variables “E”, “F”, and “C”. In the present example, the indicator variable “E” is depicted as having a “PREPROCESSOR_REF” value of “1”, which is indicative of the mathematical function FREQ_COUNT 282 (see FIG. 11 ) having an identifier of “1” in the preprocessor table 280 (see FIG. 11 ).
- indicator variables “F” and “G” are depicted as having a “PREPROCESSOR_REF” value of “4”, which is representative of the mathematical function MAX 288 having an identifier of “4” in the preprocessor table 280 (see FIG. 11 ).
- reference numeral 266 is representative of a data type associated with the variable 252 .
- the indicators “E”, “F”, and “G” are associated with one or more parameter variables. Accordingly, parameters associated with a corresponding indicator may be represented by reference numeral 268 .
- the indicator “E” is shown as having an ASSOCIATED_PARAMS value of “3”, which is indicative of the third parameter “C” in the information of interest table 250 .
- the indicator “F” is configured to operate on the fourth parameter “D” in the information of interest table 250
- the indicator “G” is configured to operate on the first parameter “A” in the information of interest table 250 .
- information of interest may be extracted from the input file 132 based on the rules obtained from the rules database 80 , as previously described.
- the data associated with the information of interest may be obtained from an information of interest table, such as table 250 (see FIG. 10 ).
- table 250 In the example illustrated in the table 250 , variables “A”, “B”, “C”, “D”, “H”, “I”, and “J” may be directly extracted from the input file 132 .
- extracted data 158 may be generated, where the extracted data 158 may be representative of data extracted from the input file 132 based on the information of interest obtained from the information of interest table 250 .
- Techniques such as, but not limited to, standard file reading techniques, regular expression techniques, or transformation techniques may be employed by the extractor module 70 to parse through the log file 62 to extract the information of interest, as previously noted.
- the extracted data 158 (see FIG. 6 ) generated at step 156 (see FIG. 6 ) may be processed at step 142 .
- the processing step 142 may include a pre-computation step and a rule grouping step.
- Step 142 which entails the processing of the extracted data 158 , may be better understood with reference to FIG. 7 .
- a flow chart of exemplary logic for performing step 142 (see FIG. 5 ), where step 142 includes processing the extracted data 158 based on the predefined rules is illustrated.
- processing step 142 is described as processing the extracted data 158 , it may be noted that the processing step 142 may also be applied to the log data stored in the data storage system 22 (see FIG. 3 ), in accordance with aspects of the present technique.
- the predefined rules are stored in the rules database 80 (see FIG. 3 ). Accordingly, step 142 may entail retrieval of the predefined rules from the rules database 80 , as depicted in step 162 . In other words, the rules database 80 may be queried to obtain the predefined rules.
- a check may be carried out to verify if the rules include any indicator variables.
- the indicator variables are configured to apply a mathematical function, for example, on one or more parameter variables. Also, performing any computation of parameters outside the scope of an inference engine, such as the inference engine 74 (see FIG. 3 ), advantageously enhances the performance of the inference engine, as previously described. Accordingly, at step 164 , if it is determined that the predefined rules include one or more indicator variables, then the computations may be calculated at step 166 . Consequent to step 166 , pre-computed data 168 may be generated. However, at step 164 , if it is determined that the predefined rules do not include any indicator variables, then raw extracted 170 data may be communicated for further processing downstream.
- the processing step 142 may also include grouping the predefined rules based on a rule condition affinity, as previously noted. Accordingly, as depicted in FIG. 7 , the rules obtained from the rules database 80 may be evaluated to check for rule condition affinity, at step 172 . In other words, at step 172 , a check may be carried out to determine if the rules include any similar rule conditions. For example, referring now to FIG. 9 , a check may be carried out to determine if Rule1-Rule6 222 - 232 include any similar rule conditions. Further, referring to FIG. 10 , it may be noted that variables A-G are associated with the GeSysLog file 192 (see FIG. 8 ), while variables H-J are associated with the LOG_TTT file 196 (see FIG. 8 ).
- the predefined rules may be grouped together based on any similar rule conditions, at step 174 .
- the rules may be grouped based on the number of data points, the number of rules and the number of similar rule conditions, as previously noted.
- variables A-G are utilized in Rule1-Rule4 222 - 228 .
- Rule1 and Rule4 include a similar rule condition, the parameter “A”. Therefore, at step 174 , Rule1 and Rule4 may be grouped to form a first rule group. However, as Rule2 and Rule3 do not include any similar rule conditions, they may be grouped such that Rule2 is in a second rule group, while Rule3 is in a third rule group.
- Rule2 and Rule3 may be grouped together to form a second rule group.
- rules Rule1-Rule4 222 - 228 include 4 parameters, 3 indicators, and 4 rules. Accordingly, following steps 172 - 174 (see FIG. 7 ), three rule groups 176 , the first rule group, the second rule group, and the third rule group, may be generated in accordance with the present example.
- Rule5-Rule6 230 - 232 entail use of parameters H-J. Also, it may be noted that there is no rule condition affinity between Rule5 and Rule6. Accordingly, Rule5 and Rule6 may be processed as separate groups.
- raw extracted data 170 (see FIG. 7 ), pre-computed data 168 (see FIG. 7 ) and a number of rule groups 176 (see FIG. 7 ) may be generated.
- a number of inference engines may be instantiated based on the number of rule groups 176 generated. More particularly, the number of inference engines instantiated may be substantially equal to the number of rule groups 176 .
- the processing module 72 (see FIG. 3 ) may be configured to instantiate the inference engines.
- rules in each rule group may be processed by a corresponding inference engine, at step 146 .
- a corresponding inference engine For example, in the example presented hereinabove, subsequent to step 142 , three rule groups are generated. Accordingly, three instances of inference engines may be instantiated. Also, the first rule group including Rule1 and Rule4 may be processed via a first inference engine, while Rule2 in the second rule group may be processed by a second inference engine. Similarly, Rule3 in the third rule group may be processed via a third inference engine. Subsequent to step 146 output data 148 may be generated. In one embodiment, the output data 148 may be representative of a state of the system at the time of failure.
- the output data 148 may be indicative of a trigger for actions defined in the rules. Additionally, the output data 148 may also be representative of processed data for further processing. The output data 144 may then be stored in a output data file in the data storage system 22 , in one embodiment.
- FIG. 12 illustrates an example of an output data file 300 .
- Reference numeral 306 is representative of an identifier, while a parameter reference identifier may be generally represented by reference numeral 308 .
- reference numeral 310 may be indicative of a start time of an event associated with a variable, while an end time of the event may be represented by reference numeral 312 .
- a value associated with the variable may be represented by reference numeral 314 .
- a type of system generating the variable may be represented by reference numeral 316 .
- identifiers 1 - 9 are representative of extracted data, such as extracted data 158 (see FIG. 6 ). More particularly, as previously noted, based on the rules for the GeSysLog file 192 (see FIG. 8 ), the extractor module 7 , 0 (see FIG. 3 ) is configured to identify that parameters “A”, “B”, “C”, and “D” need to be extracted from the log file 132 , while the indicators “E”, “F” and “G” need to be computed. Accordingly, the extracted data that includes information associated with the parameters “A”, “B”, “C”, and “D” may be associated with identifiers 1 - 9 and stored in the output data file 300 .
- the extracted data represented by identifiers 1 - 9 may generally be represented by reference numeral 302 .
- the indicators “E”, “F” and “G” may be computed employing the pre-computation module 96 (see FIG. 4 ) and associated with identifiers 10 - 12 .
- the computed data such as pre-computed data 168 (see FIG. 7 ), may also be stored in the output data file 300 .
- the computed data represented by identifiers 10 - 12 may be represented by reference numeral 304 .
- the output data file 300 that includes the extracted data 302 and the computed data 304 may be stored in the data storage system 22 (see FIG. 3 ), in certain embodiments.
- computed data 304 associated with identifiers 10 - 12 may then be further processed by one or more inference engines, such as an inference engine set 100 (see FIG. 4 ). More particularly, the rules associated with the computed data may be grouped using the rule-grouping module 98 (see FIG. 4 ). Subsequently, each of the rule groups may be processed by a corresponding inference engine.
- user viewable representations of the output data 148 may be generated for visualization on a display, such as display 48 (see FIG. 2 ), at step 150 . More particularly, the user-viewable representations may be created to include representation of the output data 148 and the predefined rules. Alternatively, the user viewable representations of the output data 148 may be visualized on a second display (not shown), where the second display is different from the display 48 .
- demonstrations, and process steps may be implemented by suitable code on a processor-based system, such as a general-purpose or special-purpose computer. It should also be noted that different implementations of the present technique may perform some or all of the steps described herein in different orders or substantially concurrently, that is, in parallel. Furthermore, the functions may be implemented in a variety of programming languages, such as C++ or Java.
- Such code may be stored or adapted for storage on one or more tangible, machine readable media, such as on memory chips, local or remote hard disks, optical disks (that is, CDs or DVDs), or other media, which may be accessed by a processor-based system to execute the stored code.
- the tangible media may comprise paper or another suitable medium upon which the instructions are printed.
- the instructions can be electronically captured via 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.
- the method for detection based on predefined rules and the system for detection described hereinabove dramatically enhance the performance of the rule-based system, thereby simplifying procedural workflow of fault detection and enhancing speed of procedural time taken to detect and/or diagnose faults in machinery.
- the speed of the inference engine may be substantially enhanced.
- the rules are grouped based on rule condition affinity, the inference engine may be configured to facilitate substantially faster execution of the rules.
- the workflow may be simplified as one or more instances of inference engines are instantiated to separately and simultaneously process a corresponding rule group.
- the method and system presented hereinabove may be used for proactive detection and/or predictive detection of the health of the system. Consequently, the workflow of fault detection may be enhanced.
Abstract
Description
- The invention relates generally to expert systems, and more particularly to rule-based systems.
- Rule-based artificial intelligence systems typically include a set of rules, one or more facts or data in a working memory, and an inference engine that applies the rules to the facts in the working memory. Further, an inference engine generally performs the steps of matching a collection of objects to a given rule, selecting a rule from a list of rules whose conditions are completely matched by the objects, and execution of the selected rule.
- Currently available inference engines typically match facts (data) against business rules, to infer conclusions, which then result in actions. Furthermore, during the execution of the selected rule step, the inference engine performs an existence test in connection with the conditions in the rule. Additionally, the inference engine performs a pattern matching step, which entails matching the new or existing facts against business rules. Unfortunately, the matching process in the inference engine is the most time consuming phase as each rule is compared against all objects.
- A wide variety of techniques have been developed to aid in pattern matching step. For example, algorithms such as the linear algorithm, the Rete algorithm, and the treat and leaps algorithm are used for pattern matching by inference engines. These pattern matching algorithms are best suited for a small set of facts and an extremely large number of rules. Unfortunately, in case of the large set of the facts, use of the presently available techniques entails a substantial increase in resource requirements, which disadvantageously leads to diminished performance. More particularly, use of these techniques results in substantially high memory requirements. Additionally, the currently available techniques fail to respond to complex business rule conditions thereby resulting in a time-consuming and laborious process. Furthermore, the currently prevalent techniques are not scalable and hence result in additional setup costs.
- It may therefore be desirable to develop a robust technique and system for the systematic execution of rules in the rule-based system that advantageously facilitates substantially superior time performance of the rule-based systems. In particular, there is a need for faster execution of the rules in the inference engine of the rule-based system. Additionally, there is also a need for a system that may be configured to aid in simplifying the workflow of a rule-based system, thereby optimizing the performance of the rule-based system.
- In accordance with aspects of the present technique, a method for fault detection is presented. The method includes extracting data based upon one or more predefined rules. Further, the method includes preprocessing the extracted data based on the predefined rules to generate one or more rule groups. The method also includes instantiating one or more inference engines based on the generated rule groups. Additionally, the method includes processing the extracted data by a corresponding inference engine based on the predefined rules to generate processed data. Computer-readable medium that afford functionality of the type defined by this method is also contemplated in conjunction with the present technique.
- In accordance with further aspects of the present technique, a detection system is presented. The detection system includes an extractor module configured to extract data based upon one or more predefined rules. In addition, the detection system includes a processing module configured to compute data based on the predefined rules, evaluate a rule condition affinity of the predefined rules, and group the predefined rules based on the evaluated rule affinity to generate one or more rule groups. Furthermore, the detection system includes an interpreter module configured to interpret the extracted data based on the predefined rules to generate output data.
- In accordance with further aspects of the present technique, a system is presented. The system includes a data source, where the data source comprises an acquisition subsystem configured to acquire data, and a processing subsystem in operative association with the acquisition subsystem and configured to process the acquired data and generate log data. Furthermore, the system includes a data storage subsystem configured to store the log data. In addition, the system includes a detection subsystem in operative association with the data storage subsystem and configured to extract data based upon one or more predefined rules, preprocess the extracted data based on the predefined rules to generate one or more rule groups, instantiate one or more inference engines based on the generated rule groups, and process the extracted data by a corresponding inference engine based on the predefined rules to generate processed data.
- These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:
-
FIG. 1 is a block diagram of an exemplary diagnostic system, in accordance with aspects of the present technique; -
FIG. 2 is a block diagram of an imaging system in the diagnostic system ofFIG. 1 , in accordance with aspects of the present technique; -
FIG. 3 is a block diagram of an exemplary rule-based system, in accordance with aspects of the present technique; -
FIG. 4 is a block diagram of a portion of the exemplary rule-based system ofFIG. 3 , in accordance with aspects of the present technique; -
FIGS. 5A and 5B are flow charts illustrating an exemplary process for fault detection, in accordance with aspects of the present technique; -
FIG. 6 is a flow chart illustrating an exemplary process of extracting data, in accordance with aspects of the present technique; -
FIG. 7 is a flow chart illustrating an exemplary process of processing data, in accordance with aspects of the present technique; -
FIG. 8 is a diagrammatic illustration of a system log file, in accordance with aspects of the present technique; -
FIG. 9 is a diagrammatic illustration of predefined rules, in accordance with aspects of the present technique; -
FIG. 10 is a diagrammatic illustration of an information of interest table, in accordance with aspects of the present technique; -
FIG. 11 is a diagrammatic illustration of a predefined functions table, in accordance with aspects of the present technique; and -
FIG. 12 is a diagrammatic illustration of an output data table, in accordance with aspects of the present technique. - As will be described in detail hereinafter, a method for fault detection and a system for detection configured to optimize rule execution and simplify fault detection in a diagnostic imaging system, are presented. Employing the method and system described hereinafter, the system for detection may be configured to facilitate substantially faster execution of the rules in the inference engine of the rule-based system, thereby simplifying the workflow of the rule-based system and optimizing the performance of the rule-based system.
- Although, the exemplary embodiments illustrated hereinafter are described in the context of a medical imaging system, it will be appreciated that use of the diagnostic system in industrial applications are also contemplated in conjunction with the present technique.
-
FIG. 1 is a block diagram of anexemplary system 10 for use in diagnostic imaging in accordance with aspects of the present technique. Thesystem 10 may be configured to acquire image data from apatient 12 via animage acquisition device 14. In one embodiment, theimage acquisition device 14 may include a probe, where the probe may include an invasive probe, or a non-invasive or external probe, such as an external ultrasound probe, that is configured to aid in the acquisition of image data. Also, in certain other embodiments, image data may be acquired via one or more sensors (not shown) that may be disposed on thepatient 12. By way of example, the sensors may include physiological sensors (not shown) such as electrocardiogram (ECG) sensors and/or positional sensors such as electromagnetic field sensors or inertial sensors. These sensors may be operationally coupled to a data acquisition device, such as an imaging system, via leads (not shown), for example. - The
system 10 may also include animaging system 18 that is in operative association with theimage acquisition device 14. In a presently contemplated configuration, theimaging system 18 may include a medical imaging system. It may he noted that although the present example illustrates thediagnostic system 10 as including oneimaging system 18, thediagnostic system 10 may include more than one imaging system. - It may be noted that although the exemplary embodiments illustrated hereinafter are described in the context of a medical imaging system, other imaging systems and applications such as industrial imaging systems and non-destructive evaluation and inspection systems, such as pipeline inspection systems, liquid reactor inspection systems, are also contemplated. Additionally, the exemplary embodiments illustrated and described hereinafter may find application in multi-modality imaging systems that employ ultrasound imaging in conjunction with other imaging modalities, position-tracking systems or other sensor systems. Furthermore, it should be noted that although the exemplary embodiments illustrated hereinafter are described in the context of a medical imaging system, such as, but not limited to, an ultrasound imaging system, an optical imaging system, a computed tomography (CT) imaging system, a magnetic resonance (MR) imaging system, an X-ray imaging system, or a positron emission tomography (PET) imaging system, other imaging systems, such as, but not limited to, a pipeline inspection system, a liquid reactor inspection system, or other imaging systems are also contemplated in accordance with aspects of the present technique.
- In addition to acquiring image data, the
medical imaging system 18 may also be configured to generate one or more log files. As will be appreciated, a log file may be representative of a file that lists actions that have occurred. More particularly, the log file may include functions and activities performed by theimaging system 18, often in a time-associated format, for example. Furthermore, the log file may include data representative of events, errors, machine critical parameters, sensor outputs, or a combination thereof. For example, log files generated by a medical imaging system, such as themedical imaging system 18, may include information indicative of a machine state. The machine state information may be employed to detect failures associated with themedical imaging system 18. Also, the log file may include machine-readable data. - As will be appreciated, the image data acquired via the
medical imaging system 18 may be stored in a database, for example. Additionally, the log files generated by themedical imaging system 18 may be communicated to afirst storage 22. In a presently contemplated configuration, thefirst storage 22 may include a data storage system. Also, in one embodiment, thedata storage system 22 may be at a location that is physically remote from the location of themedical imaging system 18. However, as will be appreciated, in certain embodiments, thedata storage system 22 may be disposed in substantially close proximity to themedical imaging system 18. Moreover, in one embodiment, the image data may be communicated to thedata storage system 22 via anetwork 20. - Additionally, the one or more log files may also be communicated to the
data storage system 22 via thenetwork 20. It may be noted that other means of communication, such as, but not limited to, the Internet, the intranet, or wireless communication may also be employed to transmit the log files from themedical imaging system 18 to thedata storage system 22. Furthermore, in one embodiment, the log files may be transmitted to thedata storage system 22 in real-time. Alternatively, the log files may be temporarily stored in a temporary storage and communicated to thedata storage system 22 at a later time. - Further, the
data storage system 22 may include adata acquisition subsystem 24, where thedata acquisition subsystem 24 may be configured to receive the log files transmitted from themedical imaging system 18 via thenetwork 20. The log files received by thedata acquisition system 24 may be stored in adata repository 26. In one embodiment, thedata repository 26 may include an archival site, a database, or an optical data storage article. It may be noted that the optical data storage article may be an optical storage medium, such as a compact disc (CD), a digital versatile disc (DVD), multi-layer structures, such as DVD-5 or DVD-9, multi-sided structures, such as DVD-10 or DVD-18, a high definition digital versatile disc (HD-DVD), a Blu-ray disc, a near field optical storage disc, a holographic storage medium, or another like volumetric optical storage medium, such as, for example, two-photon or multi-photon absorption storage format. - In accordance with exemplary aspects of the present technique, the
diagnostic system 10 may also includedetection module 28, where thedetection module 28 may be configured to aid in proactive detection and predictive detection. The working of thedetection module 28 will be explained in greater detail with reference toFIGS. 3-12 . - Turning now to
FIG. 2 , a block diagram 40 of the imaging system 18 (seeFIG. 1 ) is illustrated. Theimaging system 40 may be configured to acquire image data from the patient 12 (seeFIG. 1 ) via the image acquisition device 14 (seeFIG. 1 ), as previously noted with reference toFIG. 1 . In a presently contemplated configuration, themedical imaging system 40 may include anacquisition subsystem 42 and aprocessing subsystem 44. Further, theacquisition subsystem 42 of themedical imaging system 40 may be configured to acquire image data representative of one or more anatomical regions of interest in thepatient 12 via theimage acquisition device 14. The image data acquired from the patient 12 may then be processed by theprocessing subsystem 44. - Additionally, the image data acquired and/or processed by the
medical imaging system 40 may be employed to aid the clinician in identifying disease states, assessing need for treatment, determining suitable treatment options, and/or monitoring the effect of treatment on the disease states. In certain embodiments, theprocessing subsystem 44 may be further coupled to a local storage system, such as alocal data repository 46, where thelocal data repository 46 is configured to receive image data. Furthermore, as previously noted, themedical imaging system 18 may also be configured to generate one or more log files, where the data in the log files is representative of an event, an error, a machine state, machine critical parameters, sensor outputs, or a combination thereof. In one embodiment, theprocessing subsystem 44 may be configured to generate the one or more log files. - Furthermore, as illustrated in
FIG. 2 , themedical imaging system 40 may include adisplay 48 and auser interface 50. However, in certain embodiments, such as in a touch screen, thedisplay 48 and theuser interface 50 may overlap. Also, in some embodiments, thedisplay 48 and theuser interface 50 may include a common area. In accordance with aspects of the present technique, thedisplay 48 of themedical imaging system 40 may be configured to display an image generated by themedical imaging system 40 based on the image data acquired via theimage acquisition device 14. Additionally, in accordance with further aspects of the present technique, information of interest retrieved from the log files may be visualized on thedisplay 48, and will be described in greater detail with reference toFIGS. 3-12 . - Further, the
user interface 50 of themedical imaging system 40 may include a human interface device (not shown) configured to facilitate the clinician in organizing and/or managing image data displayed on thedisplay 48. The human interface device may include a mouse-type device, a trackball, a joystick, a stylus, or a touch screen. However, as will be appreciated, other human interface devices, such as, but not limited to, a touch screen, may also be employed. Furthermore, in accordance with aspects of the present technique, theuser interface 50 may be configured to aid the clinician in manipulating and/or organizing the information displayed on thedisplay 48, and will be described in greater detail with reference toFIGS. 3-12 . - Referring now to
FIG. 3 , a block diagram 60 of one embodiment of a rule-basedsystem 60 including thedetection module 28 ofFIG. 1 is depicted. In the example illustrated inFIG. 3 ,reference numerals FIG. 1 ) in analyzing machine readable data generated by different data sources are also contemplated in conjunction with the present technique. - As previously noted with reference to
FIG. 1 , the detection module 28 (seeFIG. 1 ) of the diagnostic system 10 (seeFIG. 1 ) is configured to aid in the analysis of the log file, for example. Accordingly, the one or more log files 62, 64, 66 may be processed by thedetection module 28. In one embodiment, thedetection module 28 may include anextractor module 70, aprocessing module 72, and aninterpreter module 74. Additionally, in certain embodiments, thedetection module 28 may also include aformatter module 68. The working of theformatter module 68, theextractor module 70, theprocessing module 72, and theinterpreter module 74 will be described in greater detail hereinafter. - In accordance with aspects of the present technique, the
formatter module 68 may be configured to format the data in the input files 62, 64, 66. More particularly, theformatter module 68 may be configured to convert the data from a native format to a common format. The term native format is representative of a format that a system typically employs to log data. Also, the term common format is indicative of a standard format that aids in simplifying the process of identifying and extracting parametric data points. For example, themedical imaging system 18 may log the data into theinput file 62 in a native format, where the native format may include a text format. Theformatter module 68 may be configured to convert the native text format of the data in theinput file 62 to a common format. Further, in one embodiment, the machine data in theinput file 62 may be categorized into three types of common data format, namely, the parametric log format, the error event log format, and the system tracker log format. Accordingly, converting the format of the data in the input files to a common format simplifies the process of identifying and extracting information of interest from the log data downstream. - Additionally, in accordance with further aspects of the present technique, the
extractor module 70 may be configured to extract information of interest from the input log file, such aslog file 62, for example. More particularly, in accordance with exemplary aspects of the present technique, theextractor module 70 may be configured to extract information of interest from thelog file 62 based upon one or more predefined rules. - The predefined rules may be stored in a
second storage 80, in one embodiment. In a presently contemplated configuration, thesecond storage 80 may include a rules database that is configured to store the predefined rules. An example of a set of predefined rules that is stored in therules database 80 will be described in greater detail with reference toFIG. 9 . As used herein, the term “rule” may be used to refer to a predefined constraint that typically encompass any and all actions that should be taken within the scope of a problem. These rules may be collectively referred to a rule base, where the rule base may contain all of the knowledge associated with the rule-based system. The rules may be typically encoded into IF-THEN rules. As will be appreciated, a rule-based system may examine all the rule conditions (IF) and determine a subset, the conflict set, of the rules whose conditions are satisfied based on a working memory, where the working memory may include any data, assertions or initially known information. Subsequently, one of the rules chosen from the conflict set based on a conflict resolution strategy may be triggered. Following the triggering of a rule, any actions specified in the corresponding THEN clause may be carried out. These actions may modify the working memory, the rule-base, or execute any actions specified by the THEN clause. Moreover, one form of the rule is a business rule. A business rule may be configured to define and/or constrain an aspect of a business. Further, the business rule may be specified in formats different from the IF-THEN format. - Also, in accordance with aspects of the present technique, the predefined rules may be representative of information associated with the status of a system, such as the medical imaging system 18 (see
FIG. 1 ). For example, the predefined rules may be employed to aid in detecting system status or health of themedical imaging system 18. Also, a predefined set of parameters may be associated with a given imaging modality, where the imaging modality may include an imaging system, such as, but not limited to, an ultrasound system, an X-ray system, a MR imaging system, a CT imaging system, or a combination thereof. For example, the predefined rules may include a set of parameters associated with a CT imaging system, where the parameters may include a speed, a temperature, a pressure, number of disks, or percentage of disk usage. Additionally, the predefined rules may also include one or more indicators, where the indicators may be associated with one or more parameters. For example, an indicator associated with a temperature parameter may include an average of the temperature parameter recorded during a predetermined interval. Accordingly, for a given imaging modality, the predefined rules may include one or more rules based on various combinations of the associated parameters and/or indicators. Furthermore, a set of rules may be defined for each of the imaging modalities, where the rules may include parameter-based rules and/or indicator-based rules. Additionally, the predefined rules may also include other expressions to be extracted from the log file, where the expressions may be representative of error codes generated by theimaging system 18, for example. It may be noted that the terms expressions to be extracted and tokens may be used interchangeably. - As noted hereinabove, the
extractor module 70 may be configured to search data in thelog file 62 for matching information of interest and extract the information of interest from thelog file 62. In one embodiment, the information of interest to be extracted may include one or more parameters, one or more indicators, one or more error codes, or combinations thereof. Additionally, the information of interest may be employed to detect status and/or health of themedical imaging system 18, for instance. The information of interest may also be used for predictive detection and/or proactive detection. - Furthermore, the predefined rules may be stored in the
rules database 80, as previously noted. Theextractor module 70 may be configured to query therules database 80 to obtain the one or more predefined rules. In addition, theextractor module 70 may be configured to query therules database 80 to obtain data associated with the information of interest to be extracted. In a presently contemplated configuration, data associated with the information of interest to be extracted may be stored in a separate file, such as the information of interest file (seeFIG. 10 ). Also, in one embodiment, the information of interest file may be stored in thedata storage system 22, for instance. Theextractor module 70 may be further configured to parse through the data in thelog file 62 to extract the information of interest based upon the information of interest file and the predefined rules. Techniques, such as, but not limited to, standard file reading techniques, regular expression techniques, or transformation techniques may be employed by theextractor module 70 to parse through thelog file 62 to extract the information of interest. - As will be appreciated, the
log file 62 may include a substantial amount of data. For example, a log file may typically have a size in a range from about 100 kilobytes to about 100 megabytes. Theextractor module 70 may thus be configured to parse through a large amount of data in thelog file 62 and extract only the information of interest indicated in the information of interest file and the predefined rules. Theextractor module 70 may search through thelog file 62 for matches based on the information of interest to be extracted. In certain embodiments, theextractor module 70 may be configured to search for an exact match of the information of interest to be extracted. However, a near match of the information of interest may also be extracted from thelog file 62. Furthermore, theextractor module 70 may also be configured to apply proximity matching techniques to extract the information of interest from thelog file 62. - Subsequent to processing by the
extractor module 70, the information of interest may be extracted based on the predefined rules. According to aspects of the present technique, the extracted information of interest may be saved in the data storage system 22 (seeFIG. 1 ). Alternatively, the extracted information of interest may be saved in an output file configured to only include the information of interest that has been extracted from thelog file 62. As noted hereinabove, the information of interest to be extracted may include the parameters, indicators, and/or error codes listed in the predefined rules. Consequently, the extracted data may include information associated with the parameters, indicators, and/or error codes. The working of theextractor module 70 will be described in greater detail with reference toFIGS. 4-12 . - By implementing the
extractor module 70 as described hereinabove, the size of the data to be processed downstream is substantially reduced as non-pertinent information is filtered out from the log file based on the predefined rules. In other words, only relevant information of interest is extracted from the log file for further processing downstream, thereby enhancing the efficiency and speed of the rule-based system. - Furthermore, in accordance with exemplary aspects of the present technique, the
processing module 72 may be configured to process the extracted information of interest in light of the predefined rules stored in therules database 80. Although the working of theprocessing module 72 is described in terms of the extracted data, it may be noted that theprocessing module 72 may also be configured to process the log data stored indata storage system 22, for example. The working of theprocessing module 72 will be described in greater detail with reference toFIG. 4 . - The data processed by the
processing module 72 may then be communicated to aninterpreter module 74. In a presently contemplated embodiment, theinterpreter module 74 may include an inference engine. As will be appreciated, an inference engine may be defined as a computer program that is configured to derive answers from a knowledge base. Theinference engine 74 may be referred to as the “brain” that expert systems use to reason about the information in the knowledge base for the ultimate purpose of formulating new conclusions. - In one embodiment, the
inference engine 74 may include a workingmemory 76 and apattern matcher 78. The workingmemory 76 may be defined as a workspace including a small set of data items representing the current state of knowledge of a system, such as the medical imaging system 18 (seeFIG. 1 ), at any stage in the performance of a task, and where the knowledge of the system is transformed into a new set on the firing of a new rule. The workingmemory 76 may be configured to serve as a global database of symbols representing facts or assertions about a given problem. - Further, the
inference engine 74 may be described as a form of finite state machine with a cycle consisting of three action states: match rules, select rules, and execute rules, where the rules may include the predefined rules obtained from therules database 80. In the first state, match rules, theinference engine 74 may be configured to find all of the rules that are satisfied by the current contents of the workingmemory 76. Moreover, the rules are generally in a condition-action form. Consequently, the conditions may be tested against the workingmemory 76. The pattern matcher 78 may be utilized to test the conditions against the workingmemory 76, in certain embodiments. Also, the rule matchings that may be found are all candidates for execution and may be collectively referred to as a conflict set, as previously noted. It may be noted that a particular rule may appear several times in the conflict set if that rule matches different subsets of data items. The pair of a rule and a subset of matching data items may be generally referred to as an instantiation of the rule. - With continuing reference to
FIG. 3 , theinference engine 74 may be configured to pass along the conflict set to the second state, select rules. In the select rules state, theinference engine 74 may be configured to apply a selection strategy to determine which rules will actually be executed. The selection strategy may be hard-coded into theinference engine 74 or may be specified as part of the model. Finally, the selected instantiations may be passed over to the third state, execute rules. Theinference engine 74 may be configured to execute or fire the selected rules with the data items associated with the rule instantiation as parameters. - The
inference engine 74 may then be configured to cycle back to the first state and start over again. This control mechanism is generally referred to as the recognize-act cycle. Also, theinference engine 74 may be configured to stop either on a given number of cycles, controlled by the operator, or on a quiescent state of the data when no rules match the data. Subsequently, theinference engine 74 may be configured to determine which rules are relevant to a given data configuration and choose which one to apply. The control strategy used to select rules is generally referred to as conflict resolution. - As noted hereinabove, the
inference engine 74 may be configured to find all of the rules that are satisfied by the current contents of the workingmemory 76 by testing the conditions against the workingmemory 76. Furthermore, the computation of the conflict set may result in a non-trivial problem, especially while handling a large volume of data and/or when the rules include complex calculations. More particularly, complex rules entail testing and retesting conditions for each rule against all the supplied facts, thereby resulting in a time-consuming and cumbersome process. In accordance with exemplary aspects of the present technique, the number of facts presented to theinference engine 74 to be tested against the conditions of each rule may be substantially reduced by pre-computing the facts outside the scope of theinference engine 74, thereby dramatically improving the performance of theinference engine 74. - Accordingly, the
processing module 72 may be configured to pre-process the extracted data in light of the predefined rules. The working of theprocessing module 72 may be better understood with reference toFIG. 4 . Referring now toFIG. 4 , one embodiment of aportion 90 of the rule-basedsystem 60 ofFIG. 3 is illustrated.Reference numeral 92 is representative of extracted data generated by the extractor module 70 (seeFIG. 3 ). As depicted inFIG. 4 , theprocessing module 72 may include apre-computation module 96, in one embodiment. Thepre-computation module 96 may be configured to aid in enhancing the performance of the rule-basedsystem 60 by pre-calculating any computations of the extracted data as specified by the predefined rules outside the scope of the inference engine 74 (seeFIG. 3 ). The working of thepre-computation module 96 may be better understood with reference to the following example. For example, a predefined rule may include a condition such as: -
D>X units, -
where D=Average(B), (1) - If B includes 100 or more facts in the working memory 76 (see
FIG. 3 ), use of the presently available techniques entails laborious computation of the average D of each of the 100 or more facts of B, thereby resulting in diminished performance ofinference engine 74 in the rule-basedsystem 60. However, employing the technique presented hereinabove, the computation of the average D may be performed outside the scope of theinference engine 74. In other words, the average D of the 100 or more facts of B may be computed via thepre-computation module 96. Subsequently, this pre-computed result D may be passed as a fact for theinference engine 74 for further processing. - By implementing the
pre-computation module 96 as described hereinabove, any calculations associated with the extracted data set defined in the predefined rules may be pre-computed outside the scope of theinference engine 74 and the pre-computed result may be passed as a fact to theinference engine 74, thereby advantageously resulting in faster execution and substantially fewer memory allocations as the workingmemory 76 is now configured to operate with a substantially smaller number of facts representative of the extracted data. In addition, the complexity of the rule logic handled by theinference engine 74 is dramatically simplified as theinference engine 74 is now configured to work with indicators that are representative of the extracted data set. - Additionally, in accordance with further aspects of the present technique, the extracted data may also be categorized into one or more rule groups based on a rule condition affinity. These rule groups may then be separately and simultaneously processed by a corresponding inference engine. More particularly, once the rule groups are -formed, the
processing module 72 may be configured to instantiate a number of inference engines, where the number of instances of inference engines may be configured to correspond to the number of rule groups. This rule grouping based on the rule condition affinity may be better understood with the aid of the following example having the following set of business rules: - Rule1 (R1):
-
- when
-
A>X && B>Y - then
-
condition 1 (2) - Rule2 (R2):
-
- when
-
C>W - then
-
condition 2 (3) - Rule3 (R3):
-
- when
-
A>W && D>Y - then
-
condition 3 (4) - where parameters A, B, C and D may be defined as including:
-
A→500 data points -
B→100 data points -
C→500 data points -
D→1000 data points. (5) - In accordance with exemplary aspects of the present technique, the
processing module 72 may also include arule grouping module 98, in certain embodiments. Therule grouping module 98 may be configured to group the rules in therules database 80 into one or more rule groups based on a rule condition affinity. Employing the currently available techniques, rule execution in the inference engine involves an existence test in connection with the conditions in the rule. More particularly, the currently available techniques typically employ one inference engine. Hence, in the present example depicted in equations (2)-(5), the single inference engine having the business rules R1, R2 and R3 respectively in the working memory performs the existence tests of rule condition “C” of R2 against all the facts of the other rules R1 and R3. Unfortunately, this use of a single inference engine results in a degraded performance of the rule-based system as the rule condition “C” has to be checked against 1600 data points of A, B and D of rules R1 and R3. - The degraded performance of such a system may be advantageously enhanced by grouping rules that have a rule condition affinity, in accordance with exemplary aspects of the present technique. In one embodiment, the grouping of rules may be based on a number of data points or facts, number of rules, number of similar rule conditions, or a combination thereof. Using the example presented in equations (2)-(5), it may be noted that parameter “A” is common between rules R1 and R3. Accordingly, rules R1 and R3 may be grouped together in a first rule group, while rule R2 may be included in a second rule group.
- Subsequently, in accordance with exemplary aspects of the present technique, the
processing module 72 may be configured to instantiate one or more inference engines depending on the number of rule groups. In the present example, theprocessing module 72 may be configured to instantiate two instances of the inference engine, where a first inference engine may be configured to process the first rule group having rules R1 and R3, while the second rule group having rule R2 may be processed by a second inference engine. It may be noted that with this grouping of rules, the number of inference engines in the rule-based system may be substantially equivalent to the number of rule groups. - By implementing the
rule grouping module 98 as described hereinabove, performance of the rule-basedsystem 60 may be dramatically enhanced as each of the inference engine is now configured to process a relatively smaller data set. Furthermore, the speed of the rule-basedsystem 60 may be increased as the instances of the inference engines may be configured to run simultaneously. - With continuing reference to
FIG. 4 ,reference numeral 100 may be representative of a number of instances of inference engines in the rule-basedsystem 60. The illustrated example ofFIG. 4 shows N instances of inference engines. A first inference engine is represented byreference numeral 102, where thefirst inference engine 102 may be configured to have afirst working memory 104 and afirst pattern matcher 106. In a similar fashion, asecond inference engine 108 may include asecond working memory 110 and asecond pattern matcher 112.Reference numeral 114 is generally indicative of an Nth inference engine, where theNth inference engine 114 is shown as including anNth working memory 116 and anNth pattern matcher 118. - Here again, using the example illustrated in equations (2)-(5), it may be noted that only the
first inference engine 102 and thesecond inference engine 108 may be instantiated by theprocessing module 72. Subsequently, the first rule group having rules R1 and R3 may be processed via thefirst inference engine 102, while thesecond inference engine 108 may be utilized to process the second rule group having the rule R2. Furthermore, output data generated consequent to processing by a corresponding inference engine may be stored in a third storage, such as adata repository 82. However, the output data may also be stored in thedata storage system 22. - As previously noted, the detection module 28 (see
FIG. 1 ) may be configured to aid in the proactive and predictive detection of the health of a system, such as the medical imaging system 18 (seeFIG. 1 ). The working of the detection module 28 (seeFIG. 1 ) may be better understood with reference to the exemplary logic depicted inFIGS. 5-12 . Referring now toFIGS. 5A-5B , flow charts ofexemplary logic 130 for detection are illustrated. In accordance with exemplary aspects of the present technique, a method for processing data based on predefined rules is presented. - The method starts at
step 134, where on receiving a log file, such as theinput file 132, a system log file configured to store relevant information associated with the input log file may be generated. In one embodiment, thedata storage system 22 may be configured to generate the system log file and store the relevant information associated with the input log file in the system log file. Step 134 may be better understood with reference toFIG. 8 . Turning now toFIG. 8 , an example 190 of a system log file, in accordance with aspects of the present technique, is depicted. Thesystem log file 190 may be generated when the rule-based system receives a log file, such as input file 132 (seeFIG. 5 ) for processing. In the illustrated example, thesystem log file 190 is depicted as including information associated with three log files, including a first log file (GeSysLog) 192, a second log file (Err_event log) 194 and a third log file (LOG_TTT) 196. Further, in one embodiment, the threelog files log files -
Reference numeral 198 is representative of a name of the input log file, while an identification number of the input log file may be generally represented byreference numeral 200. Additionally, a description of the input log file may be indicated byreference numeral 202. Further,reference numeral 204 may be representative of a format of the input log file. In one embodiment, a Boolean expression “IS_COMMON_FORMAT” may be employed to indicate if the data in the input log file is in conformance with a common data format. The common data format may include a parametric log format, an error event log format, or a system tracker log format, as previously noted. - Further, in order to simplify the process of identifying and extracting parametric data points, it is desirable to convert the data in an input file to a common format, as previously noted. Accordingly, a check may be carried out at
step 136 to verify if the data in aninput log file 132 is in a common format. If it is determined that the data in theinput log file 132 is not in a common format, then the data may be converted to conform to a common format, as indicated bystep 138. However, if atdecision block 136 it is verified that the data in theinput log file 132 is in conformance with a common format, then step 138 may be skipped. Steps 136-138 may be better understood with reference to thesystem log file 190 ofFIG. 8 . - Referring again to
FIG. 8 , in accordance with aspects of the present technique, if the data in theinput log file 132 is in a common data format, then the data may be passed on for further processing downstream. However, if the data in theinput log file 132 is not in a common data format, then the data may be converted to a common data format. For example, referring to thesystem log file 190 inFIG. 8 , if theinput log file 132 includes theErr_event log file 194, it may be noted that theinput log file 132 includes data that is in conformance with the common data format as indicated by the “IS_COMMON_FORMAT”expression 204. However, in the illustrated example, if theinput log file 132 includes theGeSysLog file 192 and/or theLOG_TTT log file 196, it may be noted that the data in the log files 192, 196 include data that is not in the common format as indicated by the “IS_COMMON_FORMAT”expression 204. Accordingly, the data in the input log files 192, 196 may be converted to the common data format as specified by a corresponding “COMMON_LOG_REF”expression 206. In the present example, the “COMMON_LOG_REF” has a value of “2” associated with both theGeSysLog file 192 andLOG_TTT file 196, where “2” is representative of the identifier of the Err-event log file 194. Accordingly, the data in the input log files 192, 196 may be converted to data having a format substantially similar to the data in theErr_event log file 194. - With returning reference to
FIG. 5 , consequent to step 138, the data in theinput file 132 may be configured to be in a predefined common format. As described hereinabove, employing the system log file 190 (seeFIG. 8 ), a check may be carried out, atstep 136, to verify if the data in theinput log file 132 is in a common data format by checking the “IS_COMMON_FORMAT” expression 204 (seeFIG. 8 ) of thesystem log file 190. If the data is in conformance with the common data format, then the data may be passed on to the subsequent processing steps. However, if the data in theinput file 132 is not presented in a common data format, then the data in theinput file 132 may be converted to a common data format indicated by the “COMMON_LOG_REF” expression 206 (seeFIG. 8 ), atstep 138. - Subsequently, at
step 140, the data in aninput log file 132 may be parsed based upon one or more predefined rules. Although the present embodiment is described in terms of the data source including a previously stored file, such as a log file, it will be appreciated thatstep 140 may also be configured to process a real-time data stream. Additionally, the data in theinput log file 132 may include machine-readable date, as previously noted. - In accordance with exemplary aspects of the present technique, the data in the
input log file 132 may be parsed based on one or more predefined rules. In other words, information of interest may be extracted from theinput file 132 based upon the predefined rules. More particularly, an information of interest file may be generated based on the predefined rules, where the information of interest file may be configured to include information associated with parameters to be extracted and/or indicators to be computed. The information of interest file may be stored in the data storage system 22 (seeFIG. 1 ), in one embodiment. Step 140 that entails the extraction of the data in theinput log file 132 may be better understood with reference toFIG. 6 . A flow chart of exemplary logic for performing step 140 (seeFIG. 5 ), wherestep 140 includes extracting data from theinput log file 132 based on the predefined rules is illustrated. As previously noted, the predefined rules are stored in the rules database 80 (seeFIG. 3 ). Accordingly, step 140 may entail retrieval of the predefined rules from therules database 80, as depicted instep 152. In other words, therules database 80 may be queried to obtain the predefined rules. - An example 220 of predefined rules stored in the rules database 80 (see
FIG. 3 ) for use in the diagnostic system 10 (seeFIG. 1 ) is illustrated inFIG. 9 . In the illustrated example, thesample database 220 is shown as including six rules. More particularly, thesample rules database 220 is shown as including afirst rule Rule1 222, asecond rule Rule2 224, athird rule Rule3 226, afourth rule Rule4 228, afifth rule Rule5 230, and asixth rule Rule6 232.Reference numeral 234 may be representative of a rule name, while an identifier associated with a corresponding rule may be indicated byreference numeral 236. Furthermore, a description associated with a corresponding rule may generally be represented byreference numeral 238. In addition, a source of the rule may be represented byreference numeral 240. Thesource 240 may include the definition of the rule, in one embodiment. Also, a type of system where the rule may find application may be represented byreference numeral 242. In the present example,Rule1 222,Rule5 230 andRule6 232 may find application in both the CT/HELIOS system and the CT/LIGHTSPEED system, whileRule2 224,Rule3 226 andRule4 228 may be applied to only the CT/HELIOS system. - With returning reference to
FIG. 6 , data may be extracted from theinput file 132 based on the rules obtained from therules database 80. More particularly, information of interest may be extracted from the data in theinput file 132, where the information of interest may be deduced from the rules in therules database 80. The information of interest may include one or more parameters, one or more indicators, or combinations thereof, as previously noted. In accordance with aspects of the present technique, the information of interest may be obtained from the rules in therules database 80. For example, referring again toFIG. 9 , it may be inferred that information of interest may include parameters “A”, “B”, “C”, “D”, “H”, “I”, and “J” and indicators “E”, “F”, and “G”. - In accordance with aspects of the present technique, at
step 154, a table may be generated to include the information of interest to be extracted from theinput file 132, where the information of interest is obtained from the predefined rules stored in therules database 80. An example table 250 of information of interest to be extracted from theinput file 132 is illustrated inFIG. 10 . It may be noted that the information of interest table 250 may be stored in thedata storage system 22, in one embodiment. In the illustrated example, the information of interest table 250 is depicted as including ten (10)variables 252, where the variables may include “A”, “B”, “C”, “D”, “E”, “F”, “G”, “H”, “I”, and “J” obtained from the rules 222-232 ofFIG. 9 . It may be noted that thevariables 252 may be representative of parameters to be extracted from theinput file 132 or indicators to be computed. In addition,reference numeral 254 is representative of names of thevariables 252, whilereference numeral 256 is representative of identifiers associated with thevariables 252. Further, a description of thevariables 252 may be generally represented byreference numeral 258. - Moreover,
reference numeral 260 may be indicative of a type of log file associated with thevariables 252. The type of log file may be represented by an expression LOG_TYPE_REF. In other words, LOG_TYPE_REF may be representative of a type of log file listed in the system log file 190 (seeFIG. 8 ). For example, if a variable 252, such as “A”, has aLOG_TYPE_REF 260 of “1”, then the variable “A” may be extracted from the GeSysLog file 192 (seeFIG. 8 ) having an identifier of “1”. In a similar fashion, if a variable 252, such as “H”, has aLOG_TYPE_REF 260 of “3”, then the variable “H” may be extracted from the LOG_TTT file 196 (seeFIG. 8 ) having an identifier of “3”. - Furthermore,
reference numeral 262 may be indicative of a type ofvariable 252. An expression PARAM_TYPE may be representative of the type ofvariable 252. More particularly, a value in the “PARAM_TYPE”expression 262 may be employed to indicate if a givenvariable 252 is a parameter or an indicator. For example, in the illustrated example, variables “A”, “B”, “C”, “D”, “H”, “I”, and “J” are depicted as being of a “PARAMETER” type. Accordingly, the variables “A”, “B”, “C”, “D”, “H”, “I”, and “J” may be directly extracted from theinput file 132. Additionally, the variables “E”, “F”, and “G” are depicted as an “INDICATOR” type. Hence, these indicator variables “E”, “F”, and “G” may be computed based upon acorresponding description 258. In the present example, the variables “E”, “F”, and “G” may be computed as: -
E=FREQ_COUNT(C), (6) -
F=MAX(D), (7) -
and G=MAX(A). (8) - Information related to functions associated with the indicator variables “E”, “F”, and “G”, such as FREQ_COUNT and MAX may be obtained from a predefined functions table, for example. An example 280 of a predefined functions table is illustrated in
FIG. 11 .Reference numeral reference numeral 282 is representative of a FREQ_COUNT function, while an AVERAGE function may be generally represented byreference numeral 284. Similarly, a MIN function may be depicted byreference numeral 286, whilereference numeral 288 may be representative of a MAX function. - Furthermore,
reference numeral 290 is indicative of a name of the mathematical function, while an identifier associated with the mathematical function may be represented byreference numeral 292. Additionally, a description associated with a given mathematical function may be represented byreference numeral 294, while a corresponding function that may be called may generally be represented byreference numeral 296. It may be noted that “FUNCTION_REF” 296 may include a name of an associated function that may be called. Although, the present example of the predefined functions table 280 is illustrated as including mathematical functions, it may be noted that other expressions are also contemplated in conjunction with the present technique. - With returning reference to
FIG. 10 ,reference numeral 264 may be indicative of a pre-processing function associated with a given indicator. More particularly, a “PREPROCESSOR_REF”value 264 may be associated with an indicator variable, such as indicator variables “E”, “F”, and “C”. In the present example, the indicator variable “E” is depicted as having a “PREPROCESSOR_REF” value of “1”, which is indicative of the mathematical function FREQ_COUNT 282 (seeFIG. 11 ) having an identifier of “1” in the preprocessor table 280 (seeFIG. 11 ). In a similar fashion, the indicator variables “F” and “G” are depicted as having a “PREPROCESSOR_REF” value of “4”, which is representative of themathematical function MAX 288 having an identifier of “4” in the preprocessor table 280 (seeFIG. 11 ). - Additionally,
reference numeral 266 is representative of a data type associated with the variable 252. As previously noted, the indicators “E”, “F”, and “G” are associated with one or more parameter variables. Accordingly, parameters associated with a corresponding indicator may be represented byreference numeral 268. For example, the indicator “E” is shown as having an ASSOCIATED_PARAMS value of “3”, which is indicative of the third parameter “C” in the information of interest table 250. Similarly, the indicator “F” is configured to operate on the fourth parameter “D” in the information of interest table 250, while the indicator “G” is configured to operate on the first parameter “A” in the information of interest table 250. - Referring again to
FIG. 6 , and more particularly to step 156, information of interest may be extracted from theinput file 132 based on the rules obtained from therules database 80, as previously described. As described hereinabove, the data associated with the information of interest may be obtained from an information of interest table, such as table 250 (seeFIG. 10 ). In the example illustrated in the table 250, variables “A”, “B”, “C”, “D”, “H”, “I”, and “J” may be directly extracted from theinput file 132. Accordingly, consequent to step 156, extracteddata 158 may be generated, where the extracteddata 158 may be representative of data extracted from theinput file 132 based on the information of interest obtained from the information of interest table 250. Techniques, such as, but not limited to, standard file reading techniques, regular expression techniques, or transformation techniques may be employed by theextractor module 70 to parse through thelog file 62 to extract the information of interest, as previously noted. - With returning reference to
FIG. 5 , the extracted data 158 (seeFIG. 6 ) generated at step 156 (seeFIG. 6 ) may be processed atstep 142. As previously described with reference toFIG. 4 , theprocessing step 142 may include a pre-computation step and a rule grouping step.Step 142, which entails the processing of the extracteddata 158, may be better understood with reference toFIG. 7 . A flow chart of exemplary logic for performing step 142 (seeFIG. 5 ), wherestep 142 includes processing the extracteddata 158 based on the predefined rules is illustrated. Although theprocessing step 142 is described as processing the extracteddata 158, it may be noted that theprocessing step 142 may also be applied to the log data stored in the data storage system 22 (seeFIG. 3 ), in accordance with aspects of the present technique. As previously noted, the predefined rules are stored in the rules database 80 (seeFIG. 3 ). Accordingly, step 142 may entail retrieval of the predefined rules from therules database 80, as depicted instep 162. In other words, therules database 80 may be queried to obtain the predefined rules. - Subsequently, at
step 164, a check may be carried out to verify if the rules include any indicator variables. As previously noted, the indicator variables are configured to apply a mathematical function, for example, on one or more parameter variables. Also, performing any computation of parameters outside the scope of an inference engine, such as the inference engine 74 (seeFIG. 3 ), advantageously enhances the performance of the inference engine, as previously described. Accordingly, atstep 164, if it is determined that the predefined rules include one or more indicator variables, then the computations may be calculated atstep 166. Consequent to step 166,pre-computed data 168 may be generated. However, atstep 164, if it is determined that the predefined rules do not include any indicator variables, then raw extracted 170 data may be communicated for further processing downstream. - The
processing step 142 may also include grouping the predefined rules based on a rule condition affinity, as previously noted. Accordingly, as depicted inFIG. 7 , the rules obtained from therules database 80 may be evaluated to check for rule condition affinity, atstep 172. In other words, atstep 172, a check may be carried out to determine if the rules include any similar rule conditions. For example, referring now toFIG. 9 , a check may be carried out to determine if Rule1-Rule6 222-232 include any similar rule conditions. Further, referring toFIG. 10 , it may be noted that variables A-G are associated with the GeSysLog file 192 (seeFIG. 8 ), while variables H-J are associated with the LOG_TTT file 196 (seeFIG. 8 ). - Referring again to
FIG. 7 , followingstep 172, the predefined rules may be grouped together based on any similar rule conditions, atstep 174. The rules may be grouped based on the number of data points, the number of rules and the number of similar rule conditions, as previously noted. With returning reference toFIG. 9 , it may be noted that variables A-G are utilized in Rule1-Rule4 222-228. Further, Rule1 and Rule4 include a similar rule condition, the parameter “A”. Therefore, atstep 174, Rule1 and Rule4 may be grouped to form a first rule group. However, as Rule2 and Rule3 do not include any similar rule conditions, they may be grouped such that Rule2 is in a second rule group, while Rule3 is in a third rule group. Alternatively, if the data points associated with Rule2 and Rule3 include a substantially small number, then Rule2 and Rule3 may be grouped together to form a second rule group. In the present example, rules Rule1-Rule4 222-228 include 4 parameters, 3 indicators, and 4 rules. Accordingly, following steps 172-174 (seeFIG. 7 ), threerule groups 176, the first rule group, the second rule group, and the third rule group, may be generated in accordance with the present example. Similarly, Rule5-Rule6 230-232 entail use of parameters H-J. Also, it may be noted that there is no rule condition affinity between Rule5 and Rule6. Accordingly, Rule5 and Rule6 may be processed as separate groups. - Turning again to
FIG. 5 , consequent to theprocessing step 142 based on the obtained rules, raw extracted data 170 (seeFIG. 7 ), pre-computed data 168 (seeFIG. 7 ) and a number of rule groups 176 (seeFIG. 7 ) may be generated. In accordance with exemplary aspects of the present technique, atstep 144, a number of inference engines may be instantiated based on the number ofrule groups 176 generated. More particularly, the number of inference engines instantiated may be substantially equal to the number ofrule groups 176. In one embodiment, the processing module 72 (seeFIG. 3 ) may be configured to instantiate the inference engines. Following the instantiation of inference engines atstep 144, rules in each rule group may be processed by a corresponding inference engine, atstep 146. For example, in the example presented hereinabove, subsequent to step 142, three rule groups are generated. Accordingly, three instances of inference engines may be instantiated. Also, the first rule group including Rule1 and Rule4 may be processed via a first inference engine, while Rule2 in the second rule group may be processed by a second inference engine. Similarly, Rule3 in the third rule group may be processed via a third inference engine. Subsequent to step 146output data 148 may be generated. In one embodiment, theoutput data 148 may be representative of a state of the system at the time of failure. However, in certain other embodiments, theoutput data 148 may be indicative of a trigger for actions defined in the rules. Additionally, theoutput data 148 may also be representative of processed data for further processing. Theoutput data 144 may then be stored in a output data file in thedata storage system 22, in one embodiment. -
FIG. 12 illustrates an example of anoutput data file 300.Reference numeral 306 is representative of an identifier, while a parameter reference identifier may be generally represented byreference numeral 308. In addition,reference numeral 310 may be indicative of a start time of an event associated with a variable, while an end time of the event may be represented byreference numeral 312. Further, a value associated with the variable may be represented byreference numeral 314. Also, a type of system generating the variable may be represented byreference numeral 316. - In the example illustrated in
FIG. 12 , identifiers 1-9 are representative of extracted data, such as extracted data 158 (seeFIG. 6 ). More particularly, as previously noted, based on the rules for the GeSysLog file 192 (seeFIG. 8 ), theextractor module 7,0 (seeFIG. 3 ) is configured to identify that parameters “A”, “B”, “C”, and “D” need to be extracted from thelog file 132, while the indicators “E”, “F” and “G” need to be computed. Accordingly, the extracted data that includes information associated with the parameters “A”, “B”, “C”, and “D” may be associated with identifiers 1-9 and stored in the output data file 300. The extracted data represented by identifiers 1-9 may generally be represented byreference numeral 302. In a similar fashion, the indicators “E”, “F” and “G” may be computed employing the pre-computation module 96 (seeFIG. 4 ) and associated with identifiers 10-12. The computed data, such as pre-computed data 168 (seeFIG. 7 ), may also be stored in the output data file 300. The computed data represented by identifiers 10-12 may be represented byreference numeral 304. Subsequently, the output data file 300 that includes the extracteddata 302 and the computeddata 304 may be stored in the data storage system 22 (seeFIG. 3 ), in certain embodiments. - Furthermore, computed
data 304 associated with identifiers 10-12 may then be further processed by one or more inference engines, such as an inference engine set 100 (seeFIG. 4 ). More particularly, the rules associated with the computed data may be grouped using the rule-grouping module 98 (seeFIG. 4 ). Subsequently, each of the rule groups may be processed by a corresponding inference engine. - With returning reference to
FIG. 5 , following the generation ofoutput data 148, user viewable representations of theoutput data 148 may be generated for visualization on a display, such as display 48 (seeFIG. 2 ), atstep 150. More particularly, the user-viewable representations may be created to include representation of theoutput data 148 and the predefined rules. Alternatively, the user viewable representations of theoutput data 148 may be visualized on a second display (not shown), where the second display is different from thedisplay 48. - As will be appreciated by those of ordinary skill in the art, the foregoing example, demonstrations, and process steps may be implemented by suitable code on a processor-based system, such as a general-purpose or special-purpose computer. It should also be noted that different implementations of the present technique may perform some or all of the steps described herein in different orders or substantially concurrently, that is, in parallel. Furthermore, the functions may be implemented in a variety of programming languages, such as C++ or Java. Such code, as will be appreciated by those of ordinary skill in the art, may be stored or adapted for storage on one or more tangible, machine readable media, such as on memory chips, local or remote hard disks, optical disks (that is, CDs or DVDs), or other media, which may be accessed by a processor-based system to execute the stored code. Note that the tangible media may comprise paper or another suitable medium upon which the instructions are printed. For instance, the instructions can be electronically captured via 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.
- The method for detection based on predefined rules and the system for detection described hereinabove dramatically enhance the performance of the rule-based system, thereby simplifying procedural workflow of fault detection and enhancing speed of procedural time taken to detect and/or diagnose faults in machinery. Further, as the system is configured to apply any pre-processing techniques to the extracted data outside the scope of the inference engine, the speed of the inference engine may be substantially enhanced. Additionally, as the rules are grouped based on rule condition affinity, the inference engine may be configured to facilitate substantially faster execution of the rules. Also, the workflow may be simplified as one or more instances of inference engines are instantiated to separately and simultaneously process a corresponding rule group. Additionally, the method and system presented hereinabove may be used for proactive detection and/or predictive detection of the health of the system. Consequently, the workflow of fault detection may be enhanced.
- While only certain features of the invention have been illustrated and described herein, many modifications and changes will occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit of the invention.
Claims (26)
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/684,165 US7853546B2 (en) | 2007-03-09 | 2007-03-09 | Enhanced rule execution in expert systems |
DE102008013053A DE102008013053A1 (en) | 2007-03-09 | 2008-03-06 | Improved rule execution in expert systems |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/684,165 US7853546B2 (en) | 2007-03-09 | 2007-03-09 | Enhanced rule execution in expert systems |
Publications (2)
Publication Number | Publication Date |
---|---|
US20080222070A1 true US20080222070A1 (en) | 2008-09-11 |
US7853546B2 US7853546B2 (en) | 2010-12-14 |
Family
ID=39678208
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/684,165 Expired - Fee Related US7853546B2 (en) | 2007-03-09 | 2007-03-09 | Enhanced rule execution in expert systems |
Country Status (2)
Country | Link |
---|---|
US (1) | US7853546B2 (en) |
DE (1) | DE102008013053A1 (en) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090157586A1 (en) * | 2007-12-17 | 2009-06-18 | Honeywell International Inc. | Object oriented rule-based system and method |
US20100218082A1 (en) * | 2009-02-25 | 2010-08-26 | Anis Charfi | Method and system for expressing and enforcing non-functional concerns in business process management systems and workflow systems |
US20120137241A1 (en) * | 2010-11-29 | 2012-05-31 | Toshiba Medical Systems Corporation | Medical image diagnostic apparatus and operation information recording apparatus |
CN102640157A (en) * | 2010-11-29 | 2012-08-15 | 株式会社东芝 | Medical image diagnosis apparatus and operation information-storing apparatus |
US20150286932A1 (en) * | 2014-04-04 | 2015-10-08 | Ca, Inc. | Leveraging unique object references to enhance performance of rete-based rule engines |
US9761222B1 (en) * | 2014-06-11 | 2017-09-12 | Albert Scarasso | Intelligent conversational messaging |
US10726038B2 (en) * | 2017-05-24 | 2020-07-28 | MphasiS Limited | System and method for optimizing aggregation and analysis of data across multiple data sources |
US20210012891A1 (en) * | 2018-03-23 | 2021-01-14 | Koninklijke Philips N.V. | Self-correcting method for annotation of data pool using feedback mechanism |
US20220100738A1 (en) * | 2018-09-06 | 2022-03-31 | Optumsoft, Inc. | Automatic generation of an efficient rule set implementation |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2535373A (en) | 2013-09-30 | 2016-08-17 | Maximus Inc | Process tracking and defect detection |
US10395177B2 (en) | 2015-12-10 | 2019-08-27 | Microsoft Technology Licensing, Llc | Optimized execution order correlation with production listing order |
US11030697B2 (en) | 2017-02-10 | 2021-06-08 | Maximus, Inc. | Secure document exchange portal system with efficient user access |
Citations (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5179633A (en) * | 1990-06-29 | 1993-01-12 | Digital Equipment Corporation | Method and apparatus for efficiently implementing read-type procedural attachments in rete-like pattern matching environment |
US5263127A (en) * | 1991-06-28 | 1993-11-16 | Digital Equipment Corporation | Method for fast rule execution of expert systems |
US5276776A (en) * | 1990-04-27 | 1994-01-04 | International Business Machines Corporation | System and method for building a computer-based Rete pattern matching network |
US5408587A (en) * | 1991-08-28 | 1995-04-18 | International Business Machines Corporation | Expert system with a frame explanation system |
US5487135A (en) * | 1990-02-12 | 1996-01-23 | Hewlett-Packard Company | Rule acquisition in knowledge based systems |
US5615308A (en) * | 1990-05-21 | 1997-03-25 | Toyo Communication Equipment Co., Ltd. | Rule-based production system adapted for complex procedures flow |
US5644770A (en) * | 1990-09-28 | 1997-07-01 | Texas Instruments Incorporated | Coupling rules to an object-oriented program |
US5815638A (en) * | 1996-03-01 | 1998-09-29 | Client/Server Connection, Ltd. | Project estimator |
US5895575A (en) * | 1995-04-13 | 1999-04-20 | Teva Medical Ltd. | Whole blood and platelet leukocyte filtration apparatus |
US5899991A (en) * | 1997-05-12 | 1999-05-04 | Teleran Technologies, L.P. | Modeling technique for system access control and management |
US5899985A (en) * | 1994-09-05 | 1999-05-04 | Kabushiki Kaisha Toshiba | Inference method and inference system |
US6012640A (en) * | 1997-07-08 | 2000-01-11 | Intermec Ip Corporation | Rule based and fuzzy logic method and apparatus for processing reflectance signals from machine-readable symbols or images |
US6067637A (en) * | 1997-05-16 | 2000-05-23 | At&T Corp | Data reduction technique for rule based systems |
US6356885B2 (en) * | 1996-10-21 | 2002-03-12 | Nortel Networks Limited | Network model for alarm correlation |
US20040128120A1 (en) * | 1999-09-30 | 2004-07-01 | Coburn James D. | Simulation method and apparatus for use in enterprise controls |
US20050065753A1 (en) * | 2003-09-24 | 2005-03-24 | International Business Machines Corporation | Apparatus and method for monitoring system health based on fuzzy metric data ranges and fuzzy rules |
US20050071222A1 (en) * | 2003-09-30 | 2005-03-31 | Bigus Joseph P. | Method for computing price discounts in an e-commerce environment |
US6892195B2 (en) * | 2001-05-04 | 2005-05-10 | International Business Machines Corporation | System and method for configuring sell bids |
US6895575B2 (en) * | 2001-06-20 | 2005-05-17 | Sap Ag | Generic Java rule engine framework |
US6915308B1 (en) * | 2000-04-06 | 2005-07-05 | Claritech Corporation | Method and apparatus for information mining and filtering |
US20050166193A1 (en) * | 2003-12-05 | 2005-07-28 | The University Of North Carolina | Methods, systems, and computer program products for identifying computer program source code constructs |
US6968329B1 (en) * | 2001-09-26 | 2005-11-22 | Syniverse Brience, Llc | Event-driven and logic-based data transformation |
US20060143143A1 (en) * | 2002-12-21 | 2006-06-29 | Chan Hoi Y | System and method for externalized inferencing components |
US7506307B2 (en) * | 2003-10-24 | 2009-03-17 | Microsoft Corporation | Rules definition language |
US7506371B1 (en) * | 2004-01-22 | 2009-03-17 | Guardium, Inc. | System and methods for adaptive behavior based access control |
US20090226065A1 (en) * | 2004-10-09 | 2009-09-10 | Dongqing Chen | Sampling medical images for virtual histology |
US20090228299A1 (en) * | 2005-11-09 | 2009-09-10 | The Regents Of The University Of California | Methods and apparatus for context-sensitive telemedicine |
-
2007
- 2007-03-09 US US11/684,165 patent/US7853546B2/en not_active Expired - Fee Related
-
2008
- 2008-03-06 DE DE102008013053A patent/DE102008013053A1/en not_active Withdrawn
Patent Citations (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5487135A (en) * | 1990-02-12 | 1996-01-23 | Hewlett-Packard Company | Rule acquisition in knowledge based systems |
US5276776A (en) * | 1990-04-27 | 1994-01-04 | International Business Machines Corporation | System and method for building a computer-based Rete pattern matching network |
US5615308A (en) * | 1990-05-21 | 1997-03-25 | Toyo Communication Equipment Co., Ltd. | Rule-based production system adapted for complex procedures flow |
US5179633A (en) * | 1990-06-29 | 1993-01-12 | Digital Equipment Corporation | Method and apparatus for efficiently implementing read-type procedural attachments in rete-like pattern matching environment |
US5644770A (en) * | 1990-09-28 | 1997-07-01 | Texas Instruments Incorporated | Coupling rules to an object-oriented program |
US5263127A (en) * | 1991-06-28 | 1993-11-16 | Digital Equipment Corporation | Method for fast rule execution of expert systems |
US5408587A (en) * | 1991-08-28 | 1995-04-18 | International Business Machines Corporation | Expert system with a frame explanation system |
US5899985A (en) * | 1994-09-05 | 1999-05-04 | Kabushiki Kaisha Toshiba | Inference method and inference system |
US5895575A (en) * | 1995-04-13 | 1999-04-20 | Teva Medical Ltd. | Whole blood and platelet leukocyte filtration apparatus |
US5815638A (en) * | 1996-03-01 | 1998-09-29 | Client/Server Connection, Ltd. | Project estimator |
US6356885B2 (en) * | 1996-10-21 | 2002-03-12 | Nortel Networks Limited | Network model for alarm correlation |
US5899991A (en) * | 1997-05-12 | 1999-05-04 | Teleran Technologies, L.P. | Modeling technique for system access control and management |
US6067637A (en) * | 1997-05-16 | 2000-05-23 | At&T Corp | Data reduction technique for rule based systems |
US6012640A (en) * | 1997-07-08 | 2000-01-11 | Intermec Ip Corporation | Rule based and fuzzy logic method and apparatus for processing reflectance signals from machine-readable symbols or images |
US20040128120A1 (en) * | 1999-09-30 | 2004-07-01 | Coburn James D. | Simulation method and apparatus for use in enterprise controls |
US6862553B2 (en) * | 1999-09-30 | 2005-03-01 | Rockwell Automation Technologies, Inc. | Diagnostics method and apparatus for use with enterprise controls |
US6915308B1 (en) * | 2000-04-06 | 2005-07-05 | Claritech Corporation | Method and apparatus for information mining and filtering |
US6892195B2 (en) * | 2001-05-04 | 2005-05-10 | International Business Machines Corporation | System and method for configuring sell bids |
US6895575B2 (en) * | 2001-06-20 | 2005-05-17 | Sap Ag | Generic Java rule engine framework |
US6968329B1 (en) * | 2001-09-26 | 2005-11-22 | Syniverse Brience, Llc | Event-driven and logic-based data transformation |
US20060143143A1 (en) * | 2002-12-21 | 2006-06-29 | Chan Hoi Y | System and method for externalized inferencing components |
US20050065753A1 (en) * | 2003-09-24 | 2005-03-24 | International Business Machines Corporation | Apparatus and method for monitoring system health based on fuzzy metric data ranges and fuzzy rules |
US20050071222A1 (en) * | 2003-09-30 | 2005-03-31 | Bigus Joseph P. | Method for computing price discounts in an e-commerce environment |
US7506307B2 (en) * | 2003-10-24 | 2009-03-17 | Microsoft Corporation | Rules definition language |
US20050166193A1 (en) * | 2003-12-05 | 2005-07-28 | The University Of North Carolina | Methods, systems, and computer program products for identifying computer program source code constructs |
US7506371B1 (en) * | 2004-01-22 | 2009-03-17 | Guardium, Inc. | System and methods for adaptive behavior based access control |
US20090226065A1 (en) * | 2004-10-09 | 2009-09-10 | Dongqing Chen | Sampling medical images for virtual histology |
US20090228299A1 (en) * | 2005-11-09 | 2009-09-10 | The Regents Of The University Of California | Methods and apparatus for context-sensitive telemedicine |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8001070B2 (en) * | 2007-12-17 | 2011-08-16 | Honeywell International Inc. | Object oriented rule-based system and method |
US20090157586A1 (en) * | 2007-12-17 | 2009-06-18 | Honeywell International Inc. | Object oriented rule-based system and method |
US20100218082A1 (en) * | 2009-02-25 | 2010-08-26 | Anis Charfi | Method and system for expressing and enforcing non-functional concerns in business process management systems and workflow systems |
US20120137241A1 (en) * | 2010-11-29 | 2012-05-31 | Toshiba Medical Systems Corporation | Medical image diagnostic apparatus and operation information recording apparatus |
CN102640157A (en) * | 2010-11-29 | 2012-08-15 | 株式会社东芝 | Medical image diagnosis apparatus and operation information-storing apparatus |
US9965723B2 (en) * | 2014-04-04 | 2018-05-08 | Ca, Inc. | Leveraging unique object references to enhance performance of RETE-based rule engines |
US20150286932A1 (en) * | 2014-04-04 | 2015-10-08 | Ca, Inc. | Leveraging unique object references to enhance performance of rete-based rule engines |
US9761222B1 (en) * | 2014-06-11 | 2017-09-12 | Albert Scarasso | Intelligent conversational messaging |
US10726038B2 (en) * | 2017-05-24 | 2020-07-28 | MphasiS Limited | System and method for optimizing aggregation and analysis of data across multiple data sources |
US20210012891A1 (en) * | 2018-03-23 | 2021-01-14 | Koninklijke Philips N.V. | Self-correcting method for annotation of data pool using feedback mechanism |
US11967421B2 (en) * | 2018-03-23 | 2024-04-23 | Koninklijke Philips N.V. | Self-correcting method for annotation of data pool using feedback mechanism |
US20220100738A1 (en) * | 2018-09-06 | 2022-03-31 | Optumsoft, Inc. | Automatic generation of an efficient rule set implementation |
US11645271B2 (en) * | 2018-09-06 | 2023-05-09 | Optumsoft, Inc. | Automatic generation of an efficient rule set implementation |
Also Published As
Publication number | Publication date |
---|---|
DE102008013053A1 (en) | 2008-09-11 |
US7853546B2 (en) | 2010-12-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7853546B2 (en) | Enhanced rule execution in expert systems | |
US8046358B2 (en) | Context-based information retrieval | |
US20080221834A1 (en) | Method and system for enhanced fault detection workflow | |
Schlegel et al. | Towards a rigorous evaluation of XAI methods on time series | |
JP2007293489A (en) | Failure diagnostic device for facility equipment and failure diagnostic method for facility equipment | |
US9304991B2 (en) | Method and apparatus for using monitoring intent to match business processes or monitoring templates | |
US20110191128A1 (en) | Method and Apparatus for Creating a Monitoring Template for a Business Process | |
EP3918529A1 (en) | Associating a population descriptor with a trained model | |
KR102269286B1 (en) | the automatic monitoring system for annotation | |
Baader et al. | Using ontologies to query probabilistic numerical data | |
Al Qutaish et al. | An analysis of the design and definitions of halstead’s metrics | |
Shahbazi et al. | A new method for detecting various variants of GoF design patterns using conceptual signatures | |
Aleti et al. | E-APR: Mapping the effectiveness of automated program repair techniques | |
US20090089237A1 (en) | Method and system for remotely updating detection knowledge of systems | |
JP4920441B2 (en) | Analysis display device for static analysis results | |
Vesra | A study of various static and dynamic metrics for open source software | |
AU2009245507A1 (en) | Assisting failure diagnosis in a system using Bayesian Network | |
US20210318946A1 (en) | Generation of code coverage information during testing of a code sequence | |
JP2009099111A (en) | Rule inspection program, rule inspection method, and rule inspection device | |
Wang et al. | Implementation of an integrated real-time process surveillance and diagnostic system for nuclear power plants | |
US11055838B2 (en) | Systems and methods for detecting anomalies using image based modeling | |
Restat et al. | Towards a Holistic Data Preparation Tool. | |
Zillner et al. | Image metadata reasoning for improved clinical decision support | |
KR20190110871A (en) | Method and apparatus for simulating safety of automotive software to obtain a goal reliability index | |
JP2013171350A (en) | Device for measuring test coverage of diagram type program, and method therefor, and program |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: GENERAL ELECTRIC COMPANY, NEW YORK Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:DAMODHARAN, GOPINATH;REEL/FRAME:019208/0642 Effective date: 20070312 |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.) |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20181214 |