Abstract:
A method and device are provided for initiating corrective actions for a terminal, such as an ATM. A method of initiating corrective actions for a terminal comprises, monitoring a fault status of a first component, detecting a fault status of the first component with a first trigger plug-in, activating a first action plug-in based upon the detected fault status of the first component, and recycling the first component.

Description:
BACKGROUND 
     Electronic terminals are well known by customers. For example, some electronic terminals may print or dispense items of value such as coupons, tickets, wagering slips, vouchers, checks, food stamps, money orders, or traveler&#39;s checks. Another common type of electronic terminal enables bank customers to engage in banking transactions without the assistance of a banking representative. These types of terminals are referred to as automated teller machines (“ATM”). 
     The types of transactions an ATM can perform are determined by the hardware and software capabilities of the specific machine. In particular, most ATMs enable customers to withdraw cash, deposit funds, transfer funds between accounts, and pay bills, without the assistance of a customer representative. For purposes of this disclosure, references to an ATM, an automated banking machine, or an automated transaction machine shall encompass any electronic terminal, which carries out customer transactions. 
     Automatic teller machines typically include a card reader, a personal identification pad, a vault, a cash dispenser, a receipt provider, and a central processing unit or computer. To begin a transaction, a user inserts an identification card into the card reader and enters his or her personal identification number (“PIN”) on the identification pad. The computer within the ATM verifies the accuracy of the PIN through an electronic network. If the user enters the correct PIN and the account is in good standing, the ATM completes the transaction(s) initiated by the user. 
     Like all computer controlled machines, ATMs may not function properly even though the user has inserted his or her identification card and provided the correct PIN. For example, the ATM may experience hardware problems if the cash dispenser or receipt provider were to become jammed or if the identification card reader were to become dirty. Additionally, some ATMs may experience software problems or faults, much like personal computers often do, that prevent users from initiating transactions. When problems or faults arise, the ATM may enter a stand-by mode that denies users access to the machine. Clearly, when in stand-by mode, ATMs become a source of frustration for operating organizations and the customers desiring to utilize the machines. 
     Traditionally, when an ATM experiences a problem or fault a bank representative places a telephone call or sends an electronic message to a remotely located terminal monitoring solution indicating that the ATM has experienced a technical problem. In-house technicians receive these incoming calls or messages and dispatch field technicians to each nonfunctional ATM. The field technicians travel to the faulty ATMs and conduct a series of diagnostic checks to identify the cause of the error signal. Once a technician determines the cause of the error signal, he or she initiates a corrective action to return the ATM to working order. 
     Sending field technicians to nonfunctional ATMs ensures that the ATMs will eventually be returned to working order; however, the process consumes time and resources. Consider that while an ATM is not working properly, customers must either search for another machine or wait for a technician to arrive at the inoperable machine, setup diagnostic equipment, attempt to solve the problem, and initiate a corrective action. Of course, the repair process consumes even more time when the technician must make multiple trips to the ATM in order to initiate a corrective action. For example, on the first trip the technician might be able to diagnose the problem; however, he or she may then have to travel back to the terminal monitoring solution to pick up the parts required to fix the ATM. Furthermore, organizations that own or rent ATMs also suffer during delays in operation caused by problems and faults. For instance, when an ATM at a bank experiences a fault, customers who can no longer use the ATM impose an increased load upon the bank tellers. Specifically, customers that would normally complete transactions at the ATM must now go inside the bank, wait in line with the other customers, and speak with a bank teller to complete the transactions. Likewise, when ATMs located within retail establishments experience faults, customers may not have access to cash, resulting in lost revenue for the store. Therefore, while field technicians may often resolve the problems experienced by ATMs the repair process places significant burdens on each involved party. 
     As the use of ATMs and other electronic terminals becomes more prolific, the number of problems and faults experienced by ATMs will also increase. Thus, ATMs may become a major expense and burden for organizations to service if each time faults or problems occur field technicians must travel to the ATM to diagnose and repair the problem. Therefore, it is desirable to improve the method with which ATM faults and problems are corrected. 
     SUMMARY 
     In order to address the above described needs, a method and device are provided for initiating corrective actions for a terminal, such as an ATM. In one embodiment, a method of initiating corrective actions for a terminal includes monitoring a fault status of a first component, detecting a fault status of the first component with a first trigger plug-in, activating a first action plug-in based upon the detected fault status of the first component, and recycling the first component. 
     In another embodiment, a terminal includes a first hardware component, a first software component, a memory, a first hardware component trigger plug-in programmed within the memory, the first hardware component trigger plug-in configured to generate a first hardware component trigger status in response to a detected fault condition of the first hardware component, a first hardware component action plug-in programmed within the memory, the first hardware component action plug-in programmed to control recycling of the first hardware component in response to a first hardware action plug-in invocation, a first software component trigger plug-in programmed within the memory, the first software component trigger plug-in programmed to generate a first software component trigger status in response to a detected fault condition of the first software component, a first software action plug-in programmed within the memory, the first software component action plug-in programmed to control a recycling of the first software component in response to a first software action plug-in invocation, and an incident reduction agent programmed within the memory, the incident reduction agent programmed to (i) recognize the first hardware component trigger status, (ii) issue the first hardware action plug-in invocation based upon the recognized first hardware component trigger status, (iii) recognize the first software component trigger status, and (iv) issue the first software action plug-in invocation based upon the recognized first software component trigger status. 
     In yet another embodiment, a method of operating a terminal includes generating a first hardware component trigger status in response to a detected fault condition of a first hardware component, recognizing the first hardware component trigger status, issuing a first hardware action plug-in invocation based upon the recognized first hardware component trigger status, recycling the first hardware component in response to the first hardware action plug-in invocation, generating a first software component trigger status in response to a detected fault condition of a first software component, recognizing the first software component trigger status, issuing a first software action plug-in invocation based upon the recognized first software component trigger status, and recycling the first software component in response to the first software action plug-in invocation. 
    
    
     
       DESCRIPTION OF THE FIGURES 
         FIG. 1  illustrates, in block diagram form, a terminal of the type disclosed herein; 
         FIG. 2  illustrates, in block diagram form, the terminal of  FIG. 1  electronically connected to a remote monitoring solution through a communications link; 
         FIG. 3  depicts a process flowchart illustrating the actions controlled by an incident reduction agent in an exemplary method for initiating corrective actions in a terminal as illustrated in  FIG. 1 ; 
         FIG. 4  depicts a process flowchart illustrating the actions controlled by a device action plug-in in the method for initiating corrective actions in a terminal as illustrated in  FIG. 3 ; and 
         FIG. 5  depicts a process flowchart illustrating the actions controlled by a software action plug-in in the method for initiating corrective actions in a terminal as illustrated in  FIG. 3 . 
     
    
    
     DETAILED DESCRIPTION 
     For the purposes of the present disclosure, an automatic teller machine (“ATM”) is described. It is understood, however, that the concepts disclosed herein can be applied to other types of electronic terminals, such as but not limited to, self checkout terminals, bill payment kiosks, and the like, in which a customer executes a series of steps to complete a transaction. 
     As illustrated in  FIG. 1 , a terminal  100 , provided in this embodiment as an ATM, includes a processor  102 , hardware components  104   1 - 104   n , and a memory  106 . The processor  102  may suitably be a general purpose computer processing circuit such as a microprocessor and its associated circuitry. The processor  102  is operable to carry out the operations attributed to it herein. 
     The illustrated hardware components  104   x  may include a currency dispenser, an envelope repository, an identification card unit, and a receipt provider. In alternative embodiments, other hardware, including other input/output (I/O) devices may be substituted and/or added to provide desired customer service functions. 
     The memory  106  includes software components  108   1 - 108   n , a diagnostic component  110 , a configuration file  112 , a log file  114 , an application event log  116 , an XFS Service Provider  118 , and a middleware component  119 . The software components  108   x  include program instructions which, when executed by the processor  102 , operate the hardware  104   x . The software components  108   x  may further include program instructions for establishing communications between the terminal  100  and other components in a network. 
     By way of example,  FIG. 2  depicts a network  120  wherein the terminal  100  is linked with a remote monitoring solution  122 . The various components within the network  120  may be linked by any desired form of electronic communication, both wired and wireless, such as the Internet, small area networks, and large area networks. The remote monitoring solution  122  is an organization which monitors and coordinates repair and maintenance of the terminal  100 . The remote monitoring solution  122  may include a plurality of personal computers configured to monitor the fault status of the terminal  100 . The remote monitoring solution  122  also monitors and coordinates repair and maintenance of terminals  124 ,  126 , and  128 . The terminals  124 ,  126 , and  128  may be configured to provide the same or different customer service functions as the terminal  100 . 
     Returning to  FIG. 1 , the diagnostic component  110  includes an incident reduction agent (“IRA”)  130 , software trigger plug-ins  132   1 - 132   n , hardware trigger plug-ins  134   1 - 134   n , device action plug-ins  136   1 - 136   n , software action plug-ins  138   1 - 138   n , and an error logging module  140 . These programs within the diagnostic component  110  are executed to detect and resolve problems with the hardware  104   x  and software components  108   x . 
     The IRA  130  acts as an interface between each of the programs stored in the diagnostic component  110 . In one embodiment, the IRA  130  is a Microsoft Windows Installer (“MSI”) file that installs a Java Runtime Environment. The install method utilized by the IRA  130  may also be implemented in other programming languages as may be required by the terminal  100 . Once installed, the IRA  130  may be configured to load automatically upon booting of the terminal  100 . The IRA  130  is preferably configured not to interfere substantially with the provision of customer services by the terminal  100 . 
     The software trigger plug-ins  132   x , hardware trigger plug-ins  134   x , device action plug-ins  136   x , and software action plug-ins  138   x  are programs stored in the diagnostic component  110  that either detect when a fault has occurred or issue a corrective action to remedy a fault. In one embodiment, each of the software trigger plug-ins  132   x , hardware trigger plug-ins  134   x , device action plug-ins  136   x , and software action plug-ins  138   x  are written in Microsoft Visual Basic.NET format and utilize XFS CEN 2.0-3.0 compatible system level events to determine if a fault has occurred. If desired, however, one or more of the software trigger plug-ins  132   x , hardware trigger plug-ins  134   x , device action plug-ins  136   x , and software action plug-ins  138   x  may be programmed in any other language. 
     The software trigger plug-ins  132   x  monitor the software components  108   x  for faults and errors. Each software trigger plug-in  132   x  in this embodiment is programmed to monitor a respective software component  108   x . The nature of the respective software component  108   x  may be adjusted for different applications. For example, a software component  108   x  may be the complete operating program for a particular hardware component or the software component  108   x  may be one of a number of subroutines within an operating program. Thus, the diagnostic component  110  may include, for example, a separate software trigger plug-in  132   x  for each operating program or for each subroutine within an operating program. Thus, different levels of monitoring activity are possible. 
     The hardware trigger plug-ins  134   x  monitor the hardware components  104   x  for faults and errors. In this embodiment, each hardware trigger plug-in  134   x  is programmed to monitor a specific assembly of hardware  134   x , which may include a currency dispenser, an envelope depositor, an identification card unit, a receipt provider, or any other hardware assembly associated with the terminal  100 . 
     The device action plug-ins  136   x  are programs that initiate corrective actions in the hardware components  104   x . Each device action plug-in  136   x  is programmed to issue a command to recycle the associated mechanical elements. The fault status of the associated hardware component  104   x  is also cleared in response to the execution of a device action plug-in  136   x . In this embodiment, the diagnostic component  110  includes separate device action plug-ins  136   x  for each hardware component  104   x  which may be a currency dispenser, an envelope depository, an identification card unit, or a receipt provider. 
     The software action plug-ins  138   x , when executed, cause an associated software component  108   x  to be rebooted. The process of stopping and restarting a software component  108   x  is herein referred to as “rebooting” the software component  108   x . Rebooting of software components is commonly performed when a software component is not operating as desired since many error or fault conditions do not require the software component to be reprogrammed; instead, simply stopping and then restarting the software component may clear the error or fault. 
     The software action plug-in  138   x  may be programmed to stop and restart the operating system of the terminal  100  whenever any software component  108   x  has experienced an error or fault rather than rebooting the faulted software component  108   x . The operating system of the terminal  100  is a program that coordinates the operation of each software component  108   x . Therefore, rebooting the operating system may cause every software component  108   x  to reboot. Operating systems that may be incorporated into the terminal  100  include any version of Microsoft Windows or Apple OS, and even propriety operating systems exclusive to terminal  100 . 
     The error logging module  140  is a program that is executed concurrently with the IRA  130 . The error logging module  140  is a configurable module, which records the details of each fault signal detected by the software trigger plug-ins  132   x  and the hardware trigger plug-ins  134   x  in the log file  114 . Recorded details may include the type of fault detected, the date and time the fault occurred, and other details as may be required by the remote monitoring solution  122 . 
     Referring still to  FIG. 1 , the application event log  116  is an electronic file that records each action attempted by the device action plug-ins  136   x  and the software action plug-in  138   x . Each entry in the application event log  116  may include the identity of the software trigger plug-in  132   x  or hardware trigger plug-in  134   x  that detected the fault, the identity of the faulty software component  108   x  or hardware component  104   x  the type of fault detected, the action taken by the device action plug-in  136   x  or the software action plug-in  138   x , the number of times a device action plug-in  136   x  has been activated in the current calendar day or other predefined period, and the time the fault occurred. Of course, other information may be included in other embodiments of an electronic terminal. 
     The configuration file  112  is a user configurable electronic file which determines the operating characteristics of the programs stored in the diagnostic component  110 . For example, the configuration file  112  may be programmed with command instructions which, when executed by the processor  102 , control which action plug-ins  104   x  are activated in response to a detected fault. In one embodiment, the configuration file  112  may be an extensible markup language (“XML”) file; however, the configuration file  112  may be implemented in any programming language utilized by the terminal  100 . 
     The XFS Service Provider  118  is a program stored in the diagnostic component  110  that permits programs developed by manufacturers other than the terminal  100  manufacturer to operate on the terminal  100 . Any or all of the hardware components  104   x  and the software components  108   x  may be configured to require invocation of the XFS Service Provider  118  for communication with the processor  102 . 
     The middleware  119  is a program stored in the memory  106  that is used to configure signals generated using the XFS Service Provider  118  to signals compatible with the IRA  130 . In this embodiment, the middleware  119  is Americas&#39; APTRA Edge middleware. 
     In one embodiment, the memory  106  includes command instructions which, when executed by the processor  102 , cause the procedure  150  of  FIG. 3  to be performed. When the terminal  100  is energized (block  152 ), the processor  102  executes the IRA  130  and the software trigger plug-ins  132   n  and the hardware trigger plug-ins  134   n  are initiated. In this embodiment, each of the software trigger plug-ins  132   x  and the hardware trigger plug-ins  134   x  may be individually enabled. Accordingly, at block  154 , each enabled software trigger plug-in  132   x  and hardware trigger plug-in  134   x  is initiated. 
     Once the IRA  130  initiates the software trigger plug-ins  132   x  and the hardware trigger plug-ins  134   x , the software trigger plug-ins  132   x  and the hardware trigger plug-ins  134   x  monitor the fault status of the hardware  104   N  and the software  108   N  either directly or through the XFS Service Provider  118 . The software trigger plug-ins  132   x  and the hardware trigger plug-ins  134   x  are event driven. Accordingly, when there is no fault event, the software trigger plug-ins  132   x  and the hardware trigger plug-ins  134   x  remain idle so as to conserve processing time of the processor  102 . 
     In the event of a fault, which in this example is in a component which communicates with the terminal  100  through the XFS Service Provider  118 , the XFS Service Provider  118  receives an error signal from the faulted software component  108   x  or hardware component  104   x . A coded message including the identity of the faulted software component  108   x  or hardware component  104   x  along with an M-Status and error pair indicating the severity of the fault is evaluated by each of the software trigger plug-ins  132   x  and the hardware trigger plug-ins  134   x . Specifically, the software trigger plug-ins  132   x  and the hardware trigger plug-ins parse the M-Status and error severity out of a vendor specific field of the XFS Service Provider  118  error event. 
     If the M-Status and severity of the error match one of the configured M-Status-severity pairs stored in the configuration file  112 , or if the vendor specific field is blank (block  156 ), a software trigger plug-in  132   x  or a hardware trigger plug-in  134   x  associated with the faulted component signals to the IRA  130  that a fault has occurred. The output of the software trigger plug-in  132   x  or hardware trigger plug-in  134   x  identifies the software component  108   x  or hardware component  104   x  that has faulted along with the specific fault detected. 
     In response, the IRA  130  initiates an IRA timer (block  158 ) and deactivates all of the software trigger plug-ins  132   x  and the hardware trigger plug-ins  134   x . Deactivation of the software trigger plug-ins  132   x  and the hardware trigger plug-ins  134   x  allows corrective action for the identified fault to be undertaken without interruption from other triggered events. The IRA  130  also invokes each of the software action plug-ins  138   x  and the device action plug-ins  136   x  (block  162 ). 
     Additionally, an entry is made in the log file  114  (block  164 ) that identifies the software component  108   x  or hardware component  104   x  that has faulted along with the specific fault detected. Additional information may also be recorded about each fault as dictated by the type of terminal  100  and the nature of the monitored component that is faulted. The log entry in this embodiment is controlled by the error logging module  140 . In alternative embodiments, the IRA  130  or a plug-in may control the logging function. 
     The IRA  130  then obtains the value of the IRA timer (block  166 ) and determines if the obtained value is greater than a predetermined threshold (block  168 ). In the event the IRA timer value exceeds the predetermined threshold, the process  150  continues at block  154 . The purpose of this comparison is to allow the remaining software triggers  132   x  and hardware triggers  134   x  to continue to function in the event the action plug-in associate with a particular trigger plug-in is not working. Thus, the threshold should be selected to allow the action plug-in events discussed below to be performed. 
     If the threshold has not been exceeded, the process pauses (block  170 ). Then, if a system reset has not been issued (block  172 ), the process continues to obtain a new value of the IRA timer (block  166 ) and proceeds to block  168 . If a system reset has been issued (block  172 ), then the process continues to block  154 . 
     The response of the software action plug-ins  138   x  and the device action plug-ins  136   x  once invoked (block  162 ) is discussed with reference to  FIGS. 4 and 5 . With initial reference to  FIG. 4 , each of the device action plug-ins  136   x  executes the procedure  180 . Initially, the IRA  130  determines if the device action plug-in  136   n  is enabled (block  182 ). If not, then the procedure  180  for that device action plug-in  136   x  ends (block  184 ). 
     If the device action plug-in  136   x  is enabled (block  182 ) then the device action plug-in  136   x  analyzes the output of the software trigger plug-in  132   x  or hardware trigger plug-in  134   x  (block  156 ). If the device action plug-in  136   x  is not associated with the faulted component identified in the output of the software trigger plug-in  132   x  or hardware trigger plug-in  134   x  (block  156 ), the procedure  180  for that device action plug-in  136   x  ends (block  184 ). Otherwise, the procedure  180  continues to block  188 . 
     At block  188 , the device action plug-in  136   x  determines if the total number of resets for the faulted device is less than a predetermined reset threshold. If not, then the procedure  180  ends (block  184 ). This reset threshold establishes the maximum number of times per day, or per other predetermined period, that a particular device may be reset. If this reset threshold is exceeded, then the faulted device is exhibiting a condition which should be further evaluated prior to returning the faulted device to service. 
     If the reset threshold is not exceeded (block  188 ), then a device action timer is initiated (block  190 ). The procedure  180  then follows two parallel activities. In one activity, the amount of time that is spent attempting to reset the faulted device is limited. Accordingly, the action timer value is obtained (block  192 ) and compared to a predetermined action threshold (block  194 ). If the action timer value exceeds the predetermined action threshold (block  194 ), then the procedure  180  ends (block  184 ). If the action timer value does not exceed the predetermined action threshold (block  194 ), then after a pause (block  196 ), this leg of the procedure  180  continues at block  192 . 
     The other parallel activity of the procedure  180  checks to ascertain whether or not the terminal  100  is in a supervisory mode or in use by a customer (block  198 ). Specifically, the terminal  100  may be placed in a service mode when a field technician is performing maintenance or trying to diagnose a problem or fault. When in service mode, the terminal  100  may provide a field technician access to the diagnostic component  110 , as an aide in repairing the terminal  100 . Thus, to avoid a loss of data and to permit the field technician to properly diagnose a problem or fault, the IRA  130  may be configured to initiate a delay repeatedly until the terminal  100  is no longer in service mode (block  200 ). An exemplary delay may be thirty seconds. 
     The IRA  130  may also initiate a delay if the terminal  100  is in use by a customer when a fault or error occurs. Since the procedure  180  will affect at least some of the devices associated with the terminal  100  during this leg of the procedure  180 , the IRA  130  may delay further actions in the procedure  180  to avoid a loss of customer data, and to minimize customer inconvenience. The procedure  180  continues to block  202  when the terminal  100  is no longer in use by a customer. 
     The device action plug-in  136   x  then generates commands to lock out one or more devices of the terminal  100  from normal operational control. In some instances, the entire terminal  100  may be disabled from providing services to customers. In other instances, only the faulted device may be disabled from providing services to customers. In any event, the status of the faulted device is set as not available for use. 
     The state of health flags for the faulted device are then reset or cleared (block  204 ). This does not change the status of the faulted device as not being available for use. Rather, resetting the health flags allows the faulted device to generate another fault indication as discussed below. The faulted device is then controlled to physically recycle the device (block  206 ). Physically recycling a device refers to sending a signal to a hardware component  104   n  that prepares the device for operation or eliminates mechanical failures. For example, if the receipt provider experiences a paper jam, receipt provider may be controlled to operate in a reverse direction for a period of time, and the operated in a forward direction for a period of time. Physically recycling the receipt provider may cause the receipt provider to expel a portion of paper that has caused the jam. 
     The status of the faulted device is then queried (block  208 ). The faulted device then, for example, performs a self test and the results of the self test are directed to the device action plug-in  136   x . If the self test generates a fault condition (block  210 ) the procedure  180  ends (block  184 ). If no fault condition is generated (block  210 ), then the faulted device has been corrected. Accordingly, the device action plug-in  136   x  resets the status of the faulted device and notifies the terminal  100  that the previously faulted device may be further queried (block  212 ). The procedure  180  then ends (block  184 ). 
     The procedure  180  may thus be terminated at various points. Termination from block  182  or block  186  does not change the operational status of the terminal  100  or any of the devices therein. Thus, the fault will not be corrected. The fault will also not be corrected if termination of the procedure  180  is initiated from either block  188 ,  194 , or directly from block  210 , although an attempt was made to correct the presently detected fault. If the procedure terminates from block  212 , the faulted device has been corrected. 
     With reference to  FIG. 5 , each of the software action plug-ins  138   x  executes the procedure  220  when invoked (block  162 ). Initially, the IRA  130  determines if the software action plug-in  138   x  is enabled (block  222 ). If not, then the procedure  220  for that software action plug-in  138   x  ends (block  224 ). 
     If the software action plug-in  138   x  is enabled (block  222 ) then the software action plug-in  138   x  analyzes the output of the software trigger plug-in  132   x  or hardware trigger plug-in  134   x  (block  226 ). If the software action plug-in  138   x  is not associated with the faulted component identified in the output of the software trigger plug-in  132   x  or hardware trigger plug-in  134   x  (block  226 ), the procedure  220  for that software action plug-in  138   x  ends (block  224 ). Otherwise, the procedure  220  continues to block  228 . If desired, a number of different software trigger plug-ins  132   x  may be associated with a single software action plug-in  138   x . 
     At block  228 , the software action plug-in  138   x  determines if the total number of reboots for the faulted software is less than a predetermined reboot threshold. If not, then the procedure  220  ends (block  224 ). This reboot threshold establishes the maximum number of times per day, or per other predetermined period, that a particular software component  108   x  may be reset. If this reboot threshold is exceeded, then the faulted software component  108   x  is exhibiting a condition which should be further evaluated prior to returning the faulted software component  108   x  to service. 
     If the reboot threshold is not exceeded (block  228 ), then the procedure  220  checks to ascertain whether or not the terminal  100  is in a service or supervisory mode (block  230 ). Specifically, the terminal  100  may be placed in a service mode when a field technician is performing maintenance or trying to diagnose a problem or fault. When in service mode, the terminal  100  may provide a field technician access to the diagnostic component  110 , as an aide in repairing the terminal  100 . Thus, to avoid a loss of data and to permit the field technician to properly diagnose a problem or fault, the IRA  130  may be configured to end (block  224 ) if the terminal is in service mode (block  230 ). 
     If the terminal  100  is not in service mode (block  230 ), the software action plug-in  138   x  generates commands to reboot the associated software component  108   x  (block  234 ). Once the software component  108   x  reboots, the software action plug-in  138   x  generates commands to verify the operating condition of the software component  108   x  (block  236 ). If the software component  108   x  is operating properly, the process  220  ends (block  224 ). If the software component  108   x  is not operating properly, then a log entry to the application event log is generated (block  238 ). The procedure  220  then ends (block  224 ). 
     The specific embodiment described above may be modified to provide a number of alternative functions. By way of example, in one alternative embodiment, the processor  102  selectively initiates the software trigger plug-ins  132   x  and the hardware trigger plug-ins  134   x . The timing and duration of initiation may be controlled by variables in the configuration file  112 . Thus, different trigger plug-ins may be operated at different periodicities. 
     Additionally, while in the embodiment described above all of the software action plug-ins  138   x  and the device action plug-ins  136   x  are invoked upon detection of a fault, in alternative embodiments, only a selected one or group of action plug-ins  138   x  and device action plug-ins  136   x  are invoked, depending upon the nature of the fault. 
     Additionally, different strategies may be invoked upon detection of a faulted component. For example, only certain types or severities of faults may result in pausing further trigger event. Moreover, in addition to logging fault events, reporting of the fault events and the corrective actions attempted may be transmitted over the network  120  to the remote monitoring solution. 
     The manner in which the forgoing procedures are implemented may also be varied. In one embodiment, the device action plug-ins  136   x  and the software action plug-ins  138   x  include nodes configurable through the configuration file  112 . For example, the device action plug-ins  136   x  and the software action plug-ins  138   x  may contain “max_actions,” and “action_timeout” nodes. The “max_actions” node may be used to determine the maximum number of recycle or reboot attempts that a device action plug-in  136   x  or software action plug-in  138   x  initiates in a calendar day or other predetermined period. 
     Additionally, device action plug-ins  136   x  and the software action plug-ins  138   x  may contain an “action_timeout” node which represents the maximum time in seconds that the respective device action plug-ins  136   x  and software action plug-ins  138   x  are allowed to attempt to recycle or reboot a hardware component  104   x  or software component  108   x  before the action is cancelled. The configuration file  112  is suitable to configure other nodes as required by the type of terminal  100  being monitored. 
     Similarly, the software action plug-ins  138   x  may include configurable nodes to ensure that that the terminal  100  only reboots in desired situations. Thus, a software action plug-in  138   x  may include a “boot_N” node that counts the number of times in a calendar day that the IRA  130  has activated the software action plug-in  138   x . 
     Additionally, the software action plug-in  138   x  may include a “max_Boot” node that limits the number of times the terminal  100  may be rebooted in a calendar day. The daily or other limit prevents the IRA  130  from continuously rebooting the terminal  100  in an attempt to clear a fault that cannot be cleared automatically by the IRA  130 . 
     Finally, the software action plug-in  138   x  may include a “trans” node that indicates when the terminal  100  is engaged in a user transaction or is in service mode. The node thus prevents the software action plug-in  138   x  from rebooting the terminal  100  when a user is engaged in a transaction or the terminal  100  is being serviced, thereby ensuring a reboot does not cause an erroneous transaction or a loss in data. The software action plug-in  138   x  may also contain other nodes as determined by the requirements of the terminal  100 . 
     While this invention has been described as having a preferred design, the subject invention can be further modified within the spirit and scope of this disclosure. This application is therefore intended to cover any variations, uses, or adaptations of the subject invention using its general principles. Further, this application is intended to cover such departures from the present disclosure as come within known or customary practice in the art to which this invention pertains and that fall within the limits of the appended claims.