Systems and methods for a hybrid diagnostic approach of real time diagnosis of electronic systems

[0002] This nonprovisional application claims the benefit of U.S. Provisional Application No. 60/154,016, filed Sep. 15, 1999, incorporated herein by reference in its entirety.

[0003] 1. Field of Invention

[0004] This invention relates to diagnosing systems. In particular, this invention relates to systems and methods for diagnosing systems using a hybrid diagnostics technique.

[0005] 2. Description of Related Art

[0006] Current electronic systems, such as printers and photocopiers, run until a failure occurs. Upon occurrence of one or more failures in the machine, a dedicated sensor in the machine will display an error message on, for example, a user interface indicating a monitored component has failed. This error message contains general information pertaining to the failed monitored component. Based on the content of this error message, a user can either attempt to perform a repair themselves or contact, for example, a customer service engineer to initiate a service call on the machine.

[0007] The above systems work well for sensed components. However, the above systems are incapable of determining which component has failed if the failed component is not a monitored component. Additionally, the above systems recognize failures after they occur and are not capable of dynamically diagnosing failures, or potential failures, in real time. Accordingly, service time is increased, service costs increased and machine down-time increased, all of which lead to customer dissatisfaction.

[0008] This invention provides systems and methods that use a combination of qualitative model based reasoning and quantitative analysis techniques in a hybrid diagnostic scheme for diagnosing and/or predicting the status of one or more components in electronic system(s). The quantitative schemes are based on analysis of machine data received from, for example, traditional monitoring devices. This hybrid diagnostic scheme allows for diagnosis and prediction down to the individual component level, with little or no additional sensors beyond those required for normal operation of the machine. This hybrid technology allows an electronic system the ability to self-diagnose itself, for example, in operation as customer jobs are being run, in an effort to, for example, reduce service costs, increase machine up-time and improve customer satisfaction. Alternatively, the systems and methods of this invention can be used at any stage of the manufacturing process or life of the machine to aid in diagnosing failures down to, for example, the individual component level, which may or may not be a directly monitored component.

[0009] The systems and methods of this invention combine a qualitative discrete event systems diagnostic methodology in conjunction with quantitative analysis methodologies to achieve a hybrid diagnostic scheme that can perform real-time failure diagnosis and prediction.

[0010] This invention separately provides systems and methods that use a combination of qualitative model based reasoning and quantitative analysis in a hybrid diagnostic scheme to diagnose document processing systems such as printers, photocopiers, scanners, facsimile machines, or the like.

[0011] The diagnostic systems and methods of this invention enable the design and production of intelligent self-diagnosing machines. Specifically, the diagnostic systems and methods of this invention monitor and track signal changes in one or more machine components. This monitoring can occur in real-time or at some other predetermined or user selected interval. The monitoring may also occur in the normal operational mode of the device or, in a special diagnostic mode.

[0012] The systems and methods of this invention utilize a diagnosis methodology that monitors the operation of one or more systems by looking at “events” occurring in a system, such as, for example, commands, control signals, sensor readings, high to low signal transitions, test results, fault flags, counters, parameter changes, and the like. Based on the occurrence of these events, the diagnosis system can generate estimates of the state of the system, and from the state estimates infer the current operational status of the system, such as a fault.

[0013] Since the diagnostics systems and methods of this invention are based on a hybrid approach to diagnosis, the diagnostics system are capable of coping with multiple sources of diagnostic information and assessing the state of the machine based on one or more monitored signal changes and additional information, derived from, for example, one or more virtual sensors. Thus, the diagnostic system is not limited to the number of sensors and/or virtual sensor inputs. The use of virtual sensors in the systems and methods of this invention supplement machine sensors and aid in enabling unique component level diagnosis of a machine while reducing or eliminating the need for installation of additional sensors.

[0014] Thus, the diagnosis system is capable of dynamic tracking of one or more systems and the ability to reason with multiple sources of information, such as sensors, virtual sensors and indicators. Furthermore, the diagnostic system is capable of identifying a machine's status, for example, a failure, a suspected failure, or a predicted failure at least down to the failed component, such as a field replaceable unit or a customer replaceable unit.

[0015] In particular, at least one of a system controller, system sensor and virtual sensor forward information from one or more systems, or, additionally, sub-systems, to an event generator. The event generator compiles the information from the one or more systems, controllers sensors, and/or virtual sensors, and generates an “event” based on the received information. This “event” is then forwarded to a diagnosis system. The diagnosis system, analyzing the events, can then estimate the state of the system, for example, based on a finite state machine model of the one or more components in the system, a constraint based model of the system, a rule based system, or the like. The estimated state, which reflects the status of the system, such as, for example, normal status, a failure mode, or predicted failure mode, can then be output to one or more output devices. Furthermore, information pertaining to the system status can be forwarded to at least one or more of a user, a system operator, service and customer support entities, an autonomous repair agent, a collocated or remote destination, or a distributed network, such as that described in co-pending Attorney Docket No. 103244, incorporated herein by reference in its entirety.

[0016] Thus, the hybrid diagnosis systems and methods of this invention are capable of providing a “front-end” to, for example, a diagnostic server, which can in turn determine an appropriate action for the transmission of specific data types directly or indirectly to one or more of a customer, autonomous repair agent, service provider and/or part/consumable supplier, and/or notify the appropriate assistance, repair, parts and/or suppliers to provide the system(s) which is predicted to fail, or has failed, the appropriate information or parts to repair or service the machine.

[0017] These and other features and advantages of this invention are described in or are apparent from the following detailed description of the preferred embodiments.

[0018] The preferred embodiments of this invention will be described in detail, with reference to the following figures, wherein:

[0019] FIG. 1 is a functional block diagram showing a first embodiment of the diagnostic system according to this invention;

[0020] FIG. 2 illustrates a functional block diagram showing a second embodiment of the diagnostic system according to this invention;

[0021] FIG. 3 illustrates a functional block diagram showing a third embodiment of the diagnostic system according to this invention;

[0022] FIG. 4 illustrates an exemplary work flow diagram for developing a diagnostic system according to this invention;

[0023] FIG. 5 illustrates an exemplary monitored system according to this invention;

[0024] FIG. 6 illustrates a detailed functional block diagram of the exemplary monitored system in FIG. 5;

[0025] FIG. 7 illustrates an exemplary work flow diagram for the exemplary monitored system shown in FIG. 6;

[0026] FIG. 8 illustrates an exemplary output of the event generator system for the exemplary system in FIG. 6;

[0027] FIG. 9 illustrates an exemplary work flow diagram for the design of the classifier for the exemplary system shown in FIG. 6;

[0028] FIG. 10 illustrates an exemplary work flow diagram of the operation of the classifier for the exemplary system shown in FIG. 6;

[0029] FIG. 11 illustrates part of an exemplary diagnostic system for the exemplary system in FIG. 6; and

[0030] FIG. 12 is a flowchart outlining a first exemplary embodiment of the method for diagnosing systems according to this invention.

[0031] The systems and methods of this invention, through use of a hybrid diagnostic methodology, are capable of acquiring and processing the necessary data to determine the operational status of one or more components in a machine, such as a printer, photocopier, or any other system for which the acquisition of status data pertaining to the system is required. Therefore, the systems and methods of this invention are capable of providing a “front-end” that allows the acquisition, processing and routing of a variety of status data types between a plurality of end-users, service/part suppliers and/or one or more diagnostic servers and secondary information resources to effectively predict, diagnose, repair, schedule, and/or ship service and/or parts to the one or more systems being monitored.

[0032] FIG. 1 illustrates a systems overview of the hybrid diagnostic system 1 according to this invention. In this exemplary embodiment, the system 5 which is being monitored, is separate from the diagnostic system. However, it is to be appreciated that the various components described in conjunction with the systems and methods of this invention can be located anywhere, including within the actual device or system being monitored, on a dedicated diagnostic device which is connected to the system 5, via, for example, one or more wired or wireless links, such as a network, the Internet, an intranet, or any other known or later developed link that is capable of transferring information between the connected components, or any combination thereof. The hybrid diagnostic system 1 comprises a system controller 20, one or more system sensors 30, one or more virtual sensors 100, an event generator 200, a diagnostic system 300 and an output device 400.

[0033] The system controller 20, the system sensors 30 and/or the virtual sensors 100 collect and forward information pertaining to the status of the system 5 to the event generator 200. Specifically, the system controller 200 forwards data such as commands issued by, for example, system and subsystem controllers, not shown, actuator signals, set-point signals, scheduling and timing data, job information, machine operational mode, or the like, to the event generator 200. The control commands may be issued as part of a real-time operation of the system, or may be special commands issued in a specific test mode or diagnostic mode. Additionally, the system sensors 30 forward data, including control data such as signal changes in response to control commands and/or test commands, process control data, or the like, monitoring data, such as outputs of special diagnostic sensors and counters, signal changes in response to failures, wear information, fault information, status information, or the like, and environmental/operational condition data such as temperature information, humidity information, or the like, to the event generator 200. The sensor signals may be analog or digital, and may be generated as part of the normal operation of the system, or may be in response to special commands issued in specific test modes or diagnostic modes.

[0034] The virtual sensor(s) 100 provide diagnostic information to the event generator by analytical means, i.e., by a quantitative and/or a qualitative processing of actual system information. The virtual sensors supplement the information provided by the one or more of the system controller 20 and the system sensor 30. In particular, the one or more virtual sensors 100 aid in refining the diagnosis that can be performed using the data obtained from the system controller 20 and the system sensor 30, to, for example, provide fault isolation to particular components within the system 5, that may or may not be directly monitored. In other words, the virtual sensors “fill in the gaps” to supplement the information provided by the “hardwired” system sensors. A variety of different choices are available for the virtual sensor 100. The simplest example of a virtual sensor 100 is a counter. For example, counters are very frequently used in print engines for diagnostic purposes. Alternatively, the virtual sensor can be based on a threshold analysis design. For threshold analysis, a signal from the system 5 is compared against a predetermined value to determine if the value has exceeded an upper or lower limit. This comparative information can then be analyzed to provide useful diagnostic information pertaining to the state of the system 5. Alternatively, the virtual sensor 100 can be based on a signature analysis model. Here, any relevant system signals and/or data, such as a ground current, a sensor signal, an actuator signal, or the like, is subject to signature analysis so that the features containing useful diagnostic information can be extracted. Additionally, the virtual sensor technology 100 can be based on a statistical analysis of the data obtained from the system 5. For example, mean and variance analysis, statistical estimates, and the like are often useful diagnostic indicators. Alternatively, the virtual sensor may be based on trend analysis, timing analysis, and rate analysis. Alternatively, the virtual sensor may be a based on computational techniques such as linear algebra, differential calculus, qualitative calculus, logical equations, topological analysis, and the like.

[0035] Finally, the virtual sensor 100 can be based on image quality analysis techniques such as those described in co-pending Attorney Docket Nos. 103059, 104707, 104708, 104709, 104710, 104759 and 104728, all of which are incorporated herein by reference in their entirety. In this instance, the output image from, for example, a printer or photocopier, is subjected to image quality analysis and/or defect recognition analysis. The resulting metrics from this analysis can then be forwarded to the event generator 200 to aid in determining the system 5 status. As with the sensor signals, the virtual sensor signals may be generated as part of the normal operation of the system, or may be in response to special commands issued in specific test modes or diagnostic modes.

[0036] The event generator 200 acquires and analyzes the one or more types of data arriving from the system controller 20, the system sensor 30 and the virtual sensor 100. The event generator 200 is capable of operating continuously, or for predetermined time sequences, to collect, and optionally store data obtained from the various sensors, virtual sensors, and/or controllers. The event generator translates this data into a format recognizable by the diagnostic system 300. For example, this translation may involve discretization of the analog data received from the one or more sensors to qualitative values. Alternatively, this translation may involve translating machine signals into discrete event sequences for example, by detecting specific signal transitions such as a transition from a high to low, on to off, or the like.

[0037] Alternatively, the event generator may forward the results of specific system tests, such as appropriately formatted pass or fail values to the diagnosis system 300. Finally, the event generator 200 may translate the results of virtual sensor analysis into a qualitative format for the diagnosis system 300. The data forwarded by the event generator may be un-timed, or time-stamped data depending on the nature and the requirements of the diagnostic system 300. Thus, the event generator 200 translates the data from one or more of the sensors, virtual sensors, and controllers into discrete events that corresponding to the operation of the system 5. In order to forward these events in the appropriate sequence to the diagnosis system, the signal transitions of interest, for example, the various commands and sensor changes, and their order of occurrence, the test sequences, and the ordering of the virtual sensor outputs are predefined in, for example, a table which is referenced upon the inception of a diagnostic run. This table, for example, contains a list of “events” that are recognized by the diagnosis system 300.

[0038] The diagnostic system 300 then analyzes the discrete events determined by the event generator 200 and estimates a state of the system 5 based on these events. This estimated state reflects the status of the system, such as, for example, normal status, a failure mode or a predicted failure mode. The diagnostic system is based on qualitative reasoning schemes such as model based reasoning, discrete event systems diagnostic technology, constraint programming, bayesian networks, causal networks, neural networks, expert systems, and the like. In particular, the discrete event systems based diagnostic engine can be designed and built as discussed in “Diagnosibility of Discrete Event System,” IEEE, 1995, and “Failure Diagnosis Using Discrete Event Models,” IEEE, 1996, both by M. Sampath et. al., incorporated herein by reference in their entirety. The output of the diagnostic system, for example, the failure mode, can then be output to an output device 400, such as a user interface, a collocated or remote monitoring site or user interface, a service technician, a parts supplier, a web page, an e-mail address, or the like. Alternatively, or in addition, the output of the diagnostic system may be passed on to a repair planning module 500 which decides the appropriate repair action corresponding to the failure. The repair action may be one or more, or a combination of, customer repair, placement of a service call, and/or autonomous repair carried out by, for example, an autonomous repair agent. The output of the repair planning module 500 may, for instance, be a “Replace Part” message to the customer, or it may involve running an automated set-up procedure. Once the repair action is determined, the output of the repair planning system is routed to the appropriate recipient as described in Attorney Docket No. 103244.

[0039] FIG. 2 illustrates a block diagram of a hybrid diagnostic system with a number of specific examples of virtual sensor technologies. Specifically, the hybrid diagnostic system comprises the diagnostic system 300, the event generator 200, one or more virtual sensors 100, the system 5, and one or more sets of data streams from the system 5 to the virtual sensors 100, such as analog data stream 1050 and digital data stream 1060. The virtual sensors 100 can be one or more, or a combination of, a signature analysis module 1005, a statistical analysis module 1010, a threshold analysis module 1015, a rate analysis module 1020, a quantitative state estimator module 1025, a control sequence monitoring module 1030, a threshold analysis module 1035, an event counter module 1040 and a timer module 1045.

[0040] The signature analysis module 1005 analyzes signals received from the analog signal stream 1050 and can, for example, compare sensed signals to stored signal signatures, or compute predetermined parameters of the signal. The signature analysis may take place either on the raw signals received from the analog stream 1050, or, for example, a set of pre-determined feature variables extracted from the raw signals. The statistical analysis module 1010 receives one or more analog signals from the analog data stream 1050 and determines, based on a statistical analysis, characteristics of the data stream(s) such as means, variances, whiteness measures, or the like. The threshold analysis module 1015 derives status information based on a comparison of received data to threshold values. The rate analysis sensor 1020 monitors the rate of change, such as an increase/decrease of the value of one or more system variables. The quantitative state estimation module 1025 can be based on, for example, the analytical redundancy based schemes such as Luenberger observers, robust observers, Kalman filters, fault detection filters, parity space approaches, parameter estimation techniques, or the like. The control sequence monitor sensor 1030 monitors system control commands, and determines, for example, out of sequence commands, or missing commands. The threshold analysis sensor 1035 derives status information based on a comparison of received data to threshold values. The event counter sensor 1040 counts system events and the timer sensor 1045 monitors and analyses the timing of events in the system 5.

[0041] FIG. 3 shows another example of a diagnostic system according to this invention. This illustrative embodiment comprises the system 5, one or more sensors system sensors 30, a virtual sensor, here a state estimator 100, a feedback controller 95 the event generator 200 and the diagnostic engine 300. In particular, this embodiment illustrates the interaction of a closed loop control system with statistical state estimation based virtual sensors, such as for example, Kalman filters.

[0042] FIG. 4 is an exemplary flow diagram illustrating the development of the system models and diagnostic system according to this invention. Specifically, component models, controller models and one or more fault symptom tables are compiled to generate a system model. The component models capture both normal and failure modes of the system components. The controller module captures the various sequences of control commands that are issued as part of the normal operation of the system, or, alternatively, during a special testing or a diagnostic mode of operation. It is noted that the controller model is optional and it may not be necessary to explicitly model the controller, depending on the design and the implementation of the diagnostic system. The fault symptom table lists the outputs of the sensors and virtual sensors used by the diagnostic system for the various failure modes as well as the normal mode of operation of the system. This system model is then used, along with a listing of diagnostic requirements, to generate the diagnostic inference engine. The diagnostic requirements specify the resolution with which failures are to be diagnosed, such as for example, if each failure is to be uniquely diagnosed, or if it sufficient to determine if one of a class of failures has occurred. In particular, in the case of the discrete event systems diagnostic approach, the generation of the system model and the diagnostic engine are done according to the algorithms discussed in “Diagnosibility of Discrete Event System,” IEEE, 1995, and “Failure Diagnosis Using Discrete Event Models,” IEEE, 1996, both by M. Sampath, et. al., and incorporated herein by reference in their entirety. It is also noted that the diagnostic engine may be directly synthesized from the component models, the controller model and the fault symptom tables, without the intermediate phase of generating the system model.

[0043] FIGS. 5-11 illustrate how the systems according to this invention work in an exemplary simple electronic system. Specifically, the exemplary electronic system is a printer, or, a photocopier, and the subsystem that is diagnosed is a paper feed assembly in the printer or photocopier.

[0044] In particular, FIG. 5 illustrates an exemplary functional block diagram of the paper feed system having an embedded diagnostic system. In this case, the control commands issued by the system controller are the commands to turn a feed motor that drives the various paper feed system components, an elevator motor that raises the stack of paper in the paper tray, and an acquisition solenoid that controls the feeding of paper, on and off. The sensors in the system are a wait station sensor, that detects the arrival of the paper, and a stack height sensor that checks the height of the paper in the paper trays. Two kinds are virtual sensors are used in this system. One, a feature extraction and discriminant analysis based virtual sensor, and two, a set of counter sensors. One counter keeps track of the stack height sensor readings over consecutive paper feeds and the other counter keeps track of the number of sheets fed. The failures diagnosed include stalled motors, broken and degraded solenoids, damaged feed rolls, and out-of-paper situations.

[0045] FIG. 6 illustrates in greater detail, the diagnostic system of FIG. 5. As discussed previously in relation to FIG. 5, the printing system 10 includes a paper feeder subsystem 20, a paper feeder system controller 30, and paper feeder system sensors 40. Additionally, the diagnostics portion of the system 10 comprises a virtual sensor system 100, an event generator system 200, a diagnostics system 300 and an output device 400, all interconnected by links 50.

[0046] The links 50 can be a wired or wireless link or any other known or later developed element(s) that is capable of supplying electronic data to and from the connected elements.

[0047] The virtual sensor system 100 comprises a data collection device 110, a feature extraction device 120, a discriminate analysis device 130, a peak current detection circuit 140, a power spectral amplitude determination circuit 150, a classifier circuit 160, a sheet feed counter 170 and a stack height sensor counter 180.

[0048] The event generator system 200 comprises a control data translator circuit 210, a sensor data translator circuit 220, a virtual sensor translator circuit 230 and an event sequencer circuit 240. The diagnosis system 300 comprises a controller 310, an I/O controller 320, a state estimator 330, and a system status information assembler 340.

[0049] As previously discussed, information from the paper feed system controllers 30, the paper feed system sensors 40, and virtual sensors 100 is forwarded to the event generator system 200. Thus, information from which “events” can be directly correlated is forwarded directly to the event generator system 200.

[0050] Information from the sensors 40, and additionally the ground return current, which is an aggregate of the current drawn by all of the paper feed system components is forwarded to the virtual sensor device 100, in order to generate additional system “events” that may or may not be directly detectable by the system controller and sensors. The data collection device 110 tracks and stores this information. With the acquired data, and for a more advanced determination of system status, the sheet feed counter 170, the stack height sensor counter 180, the feature extraction device 120 and the discriminant analysis device 130 are used to extract information pertaining to the system status that is not readily available from one or more of the system controller 20 and the system sensor 30. The stack height counter 180 keeps track of the stack height sensor readings over consecutive paper feeds and the sheet feed counter 170 keeps track of the number of sheets fed by monitoring a wait station sensor over consecutive feeds.

[0051] Illustratively, the feature extraction device 110 comprises the peak current detection circuit 130 and the power spectral amplitude determination circuit 140. However, it is to be appreciated that alternative features such as power spectral frequencies, results of vibration signal analysis, time-frequency signals, and the like, can be used in place of or in conjunction with the peak current detection circuit 130 and the power spectral amplitude determination circuit 140 without affecting the operation of the virtual sensor system 100. In this illustrative example, the peak current detection circuit 140 monitors and stores, for example, the peak current drawn by the paper feed system components. Additionally, the power spectral amplitude determination circuit 150 monitors and assembles the power spectral amplitudes of the ground current drawn by the paper feed system components. Once the desired feature(s) are extracted, the features are passed to the discriminant analysis device 130.

[0052] As discussed above, the peak current and power spectral amplitude are chosen, by way of illustration, due to the ease of computing these features, and the ease of mapping the features to the corresponding failure modes of the system. However, any such mapping must account for the statistical variations in the feature values that occur during operation of the system. Therefore, it is preferable that multivariate discriminate analysis be performed in the discriminate analysis device 130. A discussion of multivariate analysis can be found in “An Introduction to Multivariate Statistical Analysis,” Second Edition, by T. W. Anderson, 1984, and “Multivariate Statistical Methods” by D. Morrison, 1976, each of which are incorporated herein by reference in their entirety.

[0053] The discriminant analysis device 120 typically comprises a classifier circuit. In this illustrative example, the classifier is chosen to be a quadratic classifier 160. However, the discriminant analysis device may be based on any of the known multivariate analysis techniques. Specifically, a number of alternative algorithms exist for the design of the classifier, that differ in the classification algorithm, and can be also used in conjunction with the systems and methods of this invention without affecting its operational characteristics. For example, see “Pattern Classification and Scene Analysis” by R. Duda, 1973, incorporated herein by reference in its entirety, and also “An Introduction to Multivariate Statistical Analysis,” and “Multivariate Statistical Methods”, cited above. Examples include but are not limited to linear classifiers, logistic regression, principal component analysis, Bayes classifiers and the like.

[0054] The quadratic classifier 160 operates based on classifier parameters, which include, for example, the total number of clusters, their corresponding identification numbers, the means and covariance matrices of the clusters and a parametric constant for each cluster. In general, the discriminant analysis device 130 analyzes the data assembled by the feature extraction device 120, and classifies the set of features into any one of the given clusters, based on the distance of the given sample set of features, from the region, or cluster, formed by each group in the multi-dimensional space spanned by the feature variables. The sample point is then classified into the cluster with the closest proximity. In the case of the virtual sensor system 100, the clusters correspond to the different status, e.g., failure, modes. The cluster name or number is the output of the virtual sensor system 100. This cluster is then translated into an “event” by the event generator system 200.

[0055] The event generator system 200 translates the various information received from system sensors, controllers, and virtual sensors and converts this information into discrete events, or occurrences, that can be recognized by the diagnosis system 300. In particular, the control data translator circuit 210 receives data from one or more of the system controllers, the sensor data translator circuit 220 receives data from the one or more system sensors 30 and the virtual sensor data translator circuit 230 receives data from the one or more virtual sensors such as 100. The event generator system 100 compares this information to, for example, a look-up table for translation of the data into “discrete event” data. The event sequencer circuit 240 sequences the various events and passes them in the right order to the diagnostic system 300.

[0056] The diagnosis system 300 interprets the discrete events forwarded from the event generator system 200 to generate a corresponding machine status information. The diagnosis system is based on qualitative models of the system, where the qualitative information is provided via the “events.” The diagnosis system is based on one or more of a number of different technologies such as discrete event systems diagnostic technology, model based reasoning , bayesian inferencing, constraint based programming, neural networks, and causal networks. Typically, two approaches may be followed for the design and implementation of the diagnostic system 300. In the first approach, one or more of component models, controller models and fault system tables are used, in conjunction with diagnostic requirements, to generate a diagnostic inference engine, which is then stored in the memory of the diagnostic system 300, such as, for example, a look-up table, or a rule based system. At the time of the actual diagnosis, the inferencing is simply done by updating the state of the inference engine based on “events” generated by the event generator system 200. Alternately, either the complete system model, or the component models and the fault symptom tables, may be stored in the memory of the diagnostic system 300, and the diagnostic computation performed on-line as “events” are received from the event generator system 200. In other words, the diagnostic inference engine may be incrementally generated during the diagnostic process.

[0057] The status information output from the diagnosis system can indicate, for example, if the machine is operating normally, i.e., there is no fault, or, if certain failures have occurred, or if some failures are suspected to have occurred, or if failures are predicted to occur. Having determined the current state of the system, the system status information assembler 340 assembles an appropriate message, which is transferred via link 50, to the output device 400.

[0058] The output device 400 can be a local output display module, such as a user interface, for displaying the status information or failure information output by the diagnosis system 300. The output device 400, for example, can be a user interface that displays a high level status indicator and a failure list. The high level indicator, which can be appropriately colored, or aurally enhanced, specifies the current machine status. For example, the status may be normal, suspected failure, or determined failure. The failure list displays the failures, both suspected and certain, in, for example, separate categories on a user interface. Alternately, the output device 400 may be a remote display module with the recipients of the diagnostic information and the communication channels as described in Attorney Docket No. 103244.

[0059] FIG. 7 illustrates an exemplary flow diagram associated with the system in FIG. 6. Control begins in step S10 where the print and/or copy job is commenced. Next, in step S20, the feeder system control commands and sensor signal changes are acquired. Additionally, in step S50, the ground return line current samples are acquired. Then, in step S30, the control and/or sensor signals are analyzed to obtain events such as those specified in the exemplary event generator system output, in exemplary FIG. 8. Meanwhile, in step S60, the virtual sensor illustratively extracts peak current and power spectral amplitude features, from the ground return line current samples. Then, in step S70, the extracted features are classified into one of a predetermined number of clusters using, for example, the specified classifier parameters and output classifier numbers.

[0060] In step S40, the event generator combines the control and/or sensor events with the classifier output in an order specified by the diagnostics system specification. These events are then passed to the diagnosis system in step S80. Next, in step S90, the state of the system is determined by the diagnosis system based on the events. Then, in step S100, the status information, or failures, determined by the diagnosis system are output.

[0061] FIG. 8 illustrates an exemplary output of the event generator system for the exemplary paper feeder assembly. In particular, the event generator table comprises event numbers and/or event names that are forwarded to the diagnosis system 300 for estimating the state of the paper feeder system. Once the state of the machine is determined by the state estimator 360, as previously discussed, the system status information assembler 340 forwards the appropriate status information to the output device 400 or to the repair planning module 500.

[0062] FIGS. 9 and 10 illustrate exemplary operations of the quadratic classifier circuit 160. For example, in the case of the exemplary paper feed system, in FIG. 9, in an off-line design phase of the classifier, for each cluster or group, i.e., the normal mode and each failure mode, a number of sheet feeds on the printer and/or copier are run and features pertaining to these sheet feeds acquired. Then, for a chosen class of classifier structure, i.e., quadratic, linear, or the like, the classifier parameters are determined using statistical tools.

[0063] FIG. 10 illustrates how a cluster is determined, during the on-line operation of a classifier, once the off-line design, or, training phase is completed. In particular, the distance of the feature vectors from each cluster is computed using the classifier parameters computed in the off-line design phase. Then, the closest cluster is output to the event generator system 200.

[0064] FIG. 11 illustrates a part of an exemplary diagnostic system for the exemplary system of FIG. 6. The diagnostic system, in this example, is shown as a rule based system. The diagnostic inference engine is referred to as the diagnoser.

[0065] FIG. 12 illustrates and exemplary flowchart outlining one exemplary embodiment for diagnosing a system according to this invention. Control begins in step S1000 and continues to step S1100. In step S1100, one or more system sensors/controllers are monitored, and optionally, the data collected from the sensors stored. Next, in step S1200, or in parallel with step S1100, one or more virtual sensors are monitored, and optionally, the data collected from the sensors stored. Then, in step S1300, the collected data is translated into event data based on, for example, event sequence tables. Control then continues to step S1400.

[0066] In step S1400, the event data is analyzed to estimate the state of the system. Next, in step S1500, information pertaining to the failure status of the system is output. Control then continues to step S1600 where the control sequence ends.

[0067] As shown in FIGS. 1-11, the diagnostic and failure prediction system is preferably implemented either on a single program general purpose computer or separate programmed general purpose computer. However, the diagnostic and failure prediction system can also be implemented on a special purpose computer, a programmed microprocessor or microcontroller and peripheral integrated circuit element(s), an ASIC, or other integrated circuit, a digital signal processor, a hardwired electronic or logic circuit such as a discrete element circuit, a programmable logic device such as a PLD, PLA, FPGA, PAL, or the like. In general, any device, capable of implementing a finite state machine that is in turn capable of implementing the flowcharts and workflow diagrams shown in FIGS. 12 can be used to implement the diagnostic and failure prediction system.

[0068] Furthermore, the disclosed method may be readily implemented in software using object or object-oriented software development environments that provide portable source code that can be used on a variety of computer or workstation hardware platforms. Alternatively, the disclosed search system may be implemented partially or fully in hardware using standard logic circuits or a VLSI design. Whether software or hardware is used to implement the systems and methods in accordance with this invention is dependent on the speed and/or efficiency requirements of the system, the particular function, and the particular software or hardware systems or microprocessor or microcomputer systems being utilized. The diagnostic and failure prediction systems and methods described above, however, can be readily implemented in hardware or software using any known or later-developed systems or structures, devices and/or software by those skilled in the applicable art without undue experimentation from the functional description provided herein together with a general knowledge of the computer arts.

[0069] Moreover, the disclosed methods may be readily implemented as software executed on a programmed general purpose computer, a special purpose computer, a microprocessor, or the like. In this case, the methods and systems of this invention can be implemented as a routine embedded on a personal computer such as a Java® or CGI script, as a resource residing on a server or workstation, as a routine embedded in a dedicated diagnostic and failure prediction system, or the like. The diagnostic and failure prediction system can also be implemented by physically incorporating the system and method into a software and/or hardware system, such as the hardware and software systems of a workstation or dedicated diagnostic system.

[0070] It is, therefore, apparent that there has been provided, in accordance with the present invention, systems and methods for diagnosis and failure prediction of electronic systems. While this invention has described in conjunction with preferred embodiments thereof, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art. Accordingly, Applicants intend to embrace all such alternatives, modifications and variations that follow in the spirit and scope of this invention.