Browse Prior Art Database

On demand maintenance of computer devices

IP.com Disclosure Number: IPCOM000033278D
Original Publication Date: 2004-Dec-03
Included in the Prior Art Database: 2004-Dec-03
Document File: 1 page(s) / 36K

Publishing Venue

IBM

Abstract

Automatic systems are replacing humans in many activities because of the fact they are cheaper, more reliable and available 7 days per week and 24 hours per day. ATM, automatic payment systems, electronic ticket machines are just some examples of those systems. Nevertheless, they need maintenance over time in order to guarantee their availability full time and high quality of service. Event-based monitoring systems are being used to inform operators about critical problems, if detected: missing cash, printer out of paper, and the like. In such cases, human intervention is required to recover the abnormal condition. There are also other maintenance activities, usually scheduled on time basis, which are being performed to prevent degradation of system quality (i.e. change the keyboard every year, substitute relays of the actuation system of a lift every six months, or change filters of an automatic coffee machine once a month). This last type of maintenance bases on usage statistics of the automatic system, which in some situations may be very unreliable because of external factors. In fact, if there is a peak (or a lack) of usage in a given time frame the system may miss (or receive useless) maintenance, leading to a quality of service degradation (or increased cost of ownership).

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 100% of the total text.

Page 1 of 1

On demand maintenance of computer devices

The main idea is to have a counter inside the persistent memory of the device (usually a flash RAM), which is increased every time the device runs a working cycle.

    A monitoring system (like an IBM Tivoli Monitoring resource model, or an embedded monitoring subsystem) may access that counter through an API of the driver and compare the cycle counter with a threshold. If the threshold is exceeded the system requests an intervention to replace (or maintain) the device subject to usury.

    Let's think about an ATM, which includes for sure a keyboard. Many users use the keyboard to make their transactions. Each of the key onto the keyboard is being used different times, and there are usually keys used much more than others
(i.e. the "enter" key). The keyboard's driver may store the number of times each key has been pressed, and when the maximum of that occurrences exceeds the number of times, for which the specifications guarantee reliability, the system can request a keyboard substitution.

    The above example concerns an input system, but the mechanism may apply also to output devices. In fact, if an electronic system that drives a lift uses relays to activate engines, it may have a counter for each relay to count the number of its activations.

1