FOR COST/PRICE

Monitoring system with particular application to monitoring a cash-basis operation

5694323

Abstract

The invention enables an operation to be monitored directly by a single person at a monitoring site. Certain predefined activities at one or more operating sites are automatically monitored. Information regarding these activities is conveyed to the monitoring site as directed by the person doing the monitoring. The information collected at the monitoring site is used to describe the status of the operation at a given time or the change in status of the operation over a period of time, and to verify information about the conduct of the operation supplied by third parties to the person monitoring the operation. The operation can be conducted at any number of operating sites and the operating sites can be separated by any distance. The monitoring site can be, and frequently is, geographically remote from the operating sites. Further, the monitoring site can be mobile, without affecting the monitoring capabilities of the invention. The invention is useful in monitoring a variety of commercial operations such as, for example, a chain of restaurants or multiplicity of car washes. Further, the invention is particularly useful in monitoring commercial operations that operate on a cash-basis or that are conducted primarily on a self-serve basis such as, for example, laundromats or arcades. However, the invention can be used to monitor any type of operation.


Claims

We claim:

1. A system for automatically monitoring the conduct a cash-basis operation that takes place at an operating site, comprising:

means for automatically determining the amount of cash that should have been deposited in at least one machine located at the operating site during a specified period of time;

means for maintaining information regarding the amount of cash collected from each of the at least one machines during the specified period of time; and

means for comparing the amount of cash collected to the amount of cash that should have been deposited.

2. A system as in claim 1, wherein the determining means further comprises means for sensing each activation of each of the at least one machines during the specified period of time.

3. A system as in claim 1, further comprising means for uniquely identifying each of the at least one machines, so that the means for determining, maintaining and comparing enable comparison of the amount of cash collected to the amount of cash that should have been deposited for each of the at least one machines.

4. A system as in claim 3, further comprising means for identifying the type of each of the at least one machines, so that the means for determining, maintaining and comparing enable comparison of the amount of cash collected to the amount of cash that should have been deposited for each type of machine.

5. A system as in claim 1 further comprising means for monitoring the operation of one or more machines at the operating site.

6. A system as in claim 5, wherein the machine operation monitoring means further comprises means for sensing an opening or closing of a service door on each of the one or more machines.

7. A system as in claim 5, wherein the machine operation monitoring means further comprises means for monitoring each repair made to one or more of the machines.

8. A system as in claim 7, wherein the repair monitoring means further comprises:

means for recording the date of the repair;

means for recording the name of the person who performed the repair; and

means for recording a description of the repair.

9. A system as in claim 5, wherein the machine operation monitoring means further comprises means for determining when one of the machines is out of order.

10. A system as in claim 9, wherein the out-of-order machine determining means further comprises means for sensing each activation of each of the one or more machines.

11. A system as in claim 9, wherein the out-of-order machine determining means further comprises means for monitoring an out-of-order switch located on each of the one or more machines.

12. A system as in claim 9, wherein the machine operation monitoring means further comprises:

means for determining the date that a machine becomes out of order;

means for determining the time of day that a machine becomes out of order;

means for determining the operating site at which each out-of-order machine is located; and

means for determining identifying information regarding each out-of-order machine.

13. A system for managing the operation of a plurality of laundromats, comprising:

means for remotely monitoring from a monitoring site a first set of predefined aspects of the operation of the plurality of laundromats; and

means for remotely controlling from the monitoring site a second set of predefined aspects of the operation of the plurality of laundromats.

14. A system as in claim 13, wherein the remote monitoring means further comprises:

means for monitoring cash receipts at each laundromat; and

means for monitoring the operation of one or more machines at each laundromat.

15. A system as in claim 13, wherein:

one or more machines includes a display; and

the remote controlling means further comprises means for controlling the contents of the display.

16. A system as in claim 13, wherein

the remote controlling means further comprises means for establishing an activation price of one or more machines at each laundromat.

17. A system as in claim 16, wherein the price establishing means further comprises means for establishing different prices for different time periods during the day.

18. A system as in claim 13, wherein:

a plurality of machines are located at each laundromat; and

the remote controlling means further comprises means for testing the operation of one or more machines at each laundromat.

19. A system as in claim 18, wherein the remote controlling means further comprises means for placing a machine out of service when the machine does not perform acceptably well during the testing.

20. A system for acquiring data regarding the operation of a cash-basis operation that takes place at an operating site, comprising:

means for automatically acquiring data regarding cash receipts at the cash-basis operation;

means for automatically acquiring data regarding the operation of one or more machines at the cash-basis operation; and

means for automatically transferring the acquired data from the operating site to a remote monitoring site for use in monitoring the cash-basis operation.

21. A system as in claim 20, wherein the data is acquired automatically at each of a plurality of predetermined times according to a single instruction by a user.

22. A system as in claim 21, wherein the data can also be acquired automatically a single time at the instruction of a user, the data acquisition beginning immediately after the user instruction.

23. A system for monitoring from a monitoring site the conduct of a cash-basis operation that takes place at an operating site, comprising:

means for automatically determining, for a machine at the operating site, the amount of cash that should have been deposited in the machine during a specified period of time; and

means for monitoring the operation of a machine at the operating site.

24. A system as in claim 23, wherein the operation takes place at a plurality of operating sites.

25. A system as in claim 23, wherein the monitoring site is geographically remote from the operating site.

26. A system as in claim 23, wherein the determining means further comprises means for sensing each activation of the machine during the specified period of time.

27. A system as in claim 23, wherein the monitoring means further comprises means for sensing openings or closings of a service door on the machine.

28. A system as in claim 23, wherein the operation is a self-service operation.

29. A system for monitoring the conduct of an operation that takes place at an operating site, a plurality of devices to be monitored being located at the operating site, comprising:

a plurality of sensors, at least one sensor being mounted on each device, each sensor adapted to acquire data regarding the operation of the device on which the sensor is mounted;

a plurality of internal control units, at least one internal control unit being mounted on each device, each internal control unit adapted to receive data from at least one sensor;

a site controller unit located at the operating site;

a plurality of communications devices for transferring data between each of the internal control units and the site controller unit;

a main controller unit located at a monitoring site; and

a communications device for transferring data between the site controller unit and the main controller unit.

30. A system as in claim 29, further comprising means for monitoring communications between the main controller unit and the site controller unit and communications between the site controller unit and the internal control units.

31. A system as in claim 29, wherein the monitoring site is geographically remote from the operating site, the system further comprising means for synchronizing the time of day at the location of the monitoring site to the time of day at the location of the operating site.

32. A system as in claim 29, wherein the communications device for transferring data between the site controller unit and the main controller unit comprises:

a modem; and

a telephone line.

33. A system as in claim 29, wherein the plurality of communications devices for transferring data between each of the internal control units and the site controller unit comprises a second plurality of communications devices, one of the second plurality of communications devices transferring data between the site controller unit and one of the internal control units, each of the remainder of the second plurality of communications devices transferring data between a pair of internal control units, such that less than all of the internal control units are directly connected to the site controller unit by a communications device.

34. A system as in claim 29, wherein the communication monitoring means further comprises:

means for detecting communication conditions, the types of communication conditions including a successful communication, a communication problem and a communication error; and

means for recording communication conditions.

35. A system as in claim 34, wherein the communication condition detecting means further comprises:

means for determining the type of a detected communication condition;

means for determining the date of occurrence of a detected communication condition;

means for determining the time of day of a detected communication condition;

means for identifying the operating site with which a detected communication condition is associated;

means for identifying the device with which a detected communication condition is associated;

means for obtaining a description of a detected communication condition; and

means for determining, if a communication condition is a communication error or communication problem, when the communication condition has been corrected.

36. A method for automatically monitoring the conduct a cash-basis operation that takes place at an operating site, comprising:

automatically determining the amount of cash that should have been deposited in at least one machine located at the operating site during a specified period of time;

maintaining information regarding the amount of cash collected from each of the at least one machines during the specified period of time; and

comparing the amount of cash collected to the amount of cash that should have been deposited.


Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to monitoring the conduct of an operation. The monitoring is typically done remotely and frequently encompasses an operation that is conducted at a multiplicity of geographically separate sites. In particular, the invention relates to monitoring the conduct of a commercial operation and, most particularly, to monitoring the conduct of a cash-basis commercial operation.

2. Related Art

The proprietor of a commercial operation must continually monitor that operation to, for example, verify that all receipts and payments are accounted for properly, ensure that all equipment associated with the operation is working properly, and confirm that each employee is present during assigned working hours. Such monitoring can be very time consuming, particularly where the commercial operation encompasses activity at a large number of sites or at two or more sites that are relatively distant from each other. Thus, a proprietor may not have the time or the inclination, or it may be prohibitively costly, to monitor the commercial operation firsthand. Often, an employee manager or managers are hired to oversee operations at one or more sites. However, the efficacy of the proprietor's monitoring of the operation is then subject to the honesty or competence of the managers, so such a solution is not optimal. Thus, a proprietor is frequently faced with a choice among limiting the expansion of the operation, spending large amounts of time monitoring the operation, or accepting the risks associated with hiring other people to monitor the operation.

Monitoring is even more difficult for a cash-basis commercial operation or for a commercial operation that is conducted primarily on a self-serve basis. Businesses having both of these characteristics, such as laundromats or arcades, are particularly difficult commercial operations to monitor. Frequently, such commercial operations have, at most, a single employee manager to oversee activity at each site. Further, maintenance and other periodic activities may be performed by a traveling employee who is not assigned to work regularly at any particular location. The potential for employee abuse (e.g., stealing cash from the machines, absenteeism) in such situations is great.

Some self-serve cash-basis commercial operations have incorporated the use of a debit card system. In a debit card system, the machines to be operated ("operating machines") are equipped with card readers and are activated using debit cards rather than money. A debit card machine accepts money and issues a debit card which is coded to indicate a cash allowance equal to the amount of money input into the debit card machine. To use a machine, a debit card is inserted into the card reader which checks to determine whether an adequate cash allowance is coded onto the debit card and, if so, deducts an appropriate amount from that cash allowance as payment for activating the machine. While this affords some monitoring over cash collections, the system can still be subverted and the system does not provide information about aspects of the operation other than cash collections.

Some machines for coin-operated laundromats have included a sensing device within the machine that senses and stores information regarding a machine's operation. The information is then read from the sensing device by a hand-held device using an infrared beam. The information is stored in the hand-held device which is then taken back to a monitoring site. The information is transferred from the hand-held device to a computer where the information is stored. The information can then be processed by the computer to provide information regarding operation of the machines at the laundromat. While this system does enable, to some degree, automatic acquisition of information regarding laundromat operation, it does not overcome the problems that necessitate having an employee perform the direct monitoring of the operation. Since employee monitoring is still required, this system does not overcome the problems associated with direct monitoring by an employee rather than the proprietor.

Currently, for coin-operated laundromats, there is no effective system for monitoring cash collections. One method that has been used is to compare the energy usage for the laundromat over a given period of time with an estimated expected energy usage based upon the cash collections for that period of time. Another method for monitoring cash collections is simply to compare the cash collections for an operating site to the cash collections for other comparable operating sites and/or to the historic cash collection data for the operating site. However, neither of these methods are sufficiently accurate, they do not provide information regarding individual machines, and they do not enable monitoring of aspects of the operation other than cash collection.

As mentioned above, another problem with monitoring a commercial operation is ensuring that all equipment associated with the operation is working. Performance of required repairs should also be monitored. Previously, there was no way to know that a machine at an operating site was not operating properly unless the proprietor or an employee visited the site (or was present on a daily basis at the site) and observed that the machine was not operating properly. Moreover, the person observing the inoperative machine often does not have the tools or parts to effect a repair. Consequently, a machine may remain inoperative for an extended period of time until a repair is made. Further, previously, repairs to machines have been tracked using a log book that is filled out manually each time that a repair is made. Such recording is tedious, requiring the manual entry of detailed information regarding the repair. Additionally, the manual recording may not be done consistently, causing the repair record to be incomplete. As a result, machines having chronic problems may not be identified. Moreover, the number of entries can easily become large and may not be organized in a way that allows easy analysis of the repair history of the machines.

It is desirable for a proprietor to be able to monitor a commercial operation (such as a coin-operated laundromat) directly, regardless of the number of sites at which the commercial operation is conducted or the geographical separation of multiple sites. It is also desirable for the site from which the commercial operation is monitored to be mobile, capable of being located at any distance from the sites at which the commercial operation is conducted, thereby enhancing the flexibility of the monitoring. Finally, it is desirable that such a system be capable of monitoring cash collections for the operation, providing information from which the operating condition of the machines associated with the operation can be deduced, and providing at least some information regarding the performance of employees hired to assist in conducting the operation.

SUMMARY OF THE INVENTION

According to the invention, an operation conducted at one or more operating sites can be monitored directly by a single person at a monitoring site. Certain predefined activities at one or more operating sites are automatically monitored. Information regarding these activities is communicated to the monitoring site. The information collected at the monitoring site is used to describe the status of the operation at a given time or the change in status of the operation over a period of time, and to verify information about the conduct of the operation supplied by third parties to the person monitoring the operation.

The operation can be conducted at any number of operating sites and the operating sites can be separated by any distance. The monitoring site can be, and frequently is, geographically remote from the operating sites. Further, the monitoring site can be mobile without affecting the monitoring capabilities of the invention.

The invention is useful in monitoring a variety of commercial operations such as, for example, a chain of restaurants or a multiplicity of car washes. Further, the invention is particularly useful in monitoring commercial operations that operate on a cash-basis or that are conducted primarily on a self-serve basis such as, for example, laundromats or arcades. However, the invention can be used to monitor any type of operation.

When used to monitor a cash-basis operation, a monitoring system according to the invention can be used to monitor the income that should have been received by the operation for particular periods of time. This information can be compared to the actual collections for those periods of time. Significant discrepancies may indicate a problem in the conduct of the operation (e.g., employee or customer stealing) that needs to be addressed. The monitoring system can also be used to monitor the performance of machines associated with the operation so that, for example, high maintenance machines can be identified. The monitoring system also provides information from which at least some aspects of employee performance can be monitored. For instance, the monitoring system provides information from which the proprietor can determine whether a repair person has attempted scheduled repairs and, as noted above, the cash collection information can be used to determine if an employee is stealing from the proprietor. An important aspect of the invention is that all of this information is made easily accessible so that the proprietor can quickly ascertain information regarding whatever particular aspect of the operation is of interest. Another important aspect of the invention is that the invention provides up-to-date information regarding the system operation, enabling the proprietor to immediately identify problems with the operation.

In one embodiment, the invention automatically monitors the operation of one or more laundromats, each of which include a multiplicity of machines. The invention monitors cash receipts at the laundromats and monitors the operation of one or more of the machines at each of the laundromats. The invention is particularly useful for monitoring a multiplicity of laundromats or for monitoring laundromats that are geographically remote from a monitoring site.

The cash receipts monitoring can include determining the amount of cash that should have been deposited in particular machines during a specified period of time. This can be accomplished by, for example, sensing each activation of the machines during the specified period of time. The cash receipts monitoring can also include maintaining information regarding the amount of cash collected from the machines during the specified period of time. The amount of cash collected can be compared to the amount of cash that should have been deposited so that any discrepancies can be identified.

The machine operation monitoring can include sensing openings or closings of a service door on particular machines. The machine operation monitoring can also include monitoring whether particular machines are out of order or not. The out-of-order machine monitoring can be accomplished by sensing and monitoring activations of the machines or by monitoring an out-of-order switch located on the machines. The machine operation monitoring can also include monitoring repairs made to machines. Such monitoring can include, for example, recording the date of each repair, recording the name of the person who performed the repair, and recording a description of the repair.

In another embodiment of the invention for automatically monitoring the operation of one or more laundromats that each include a multiplicity of machines, the invention senses activations of particular machines, openings and closings of a cash vault of particular machines, and openings and closings of a service door or doors of particular machines. As above, in this embodiment, the invention may also be capable of determining whether a machine is out of order or not. Additionally, in a further particular embodiment, the invention monitors a monitoring mechanism included with particular machines that has the capability of monitoring the operation of those machines to obtain information regarding predefined characteristics of those machines. Such predefined characteristics may include, for example, machine malfunctions, identity of repair personnel working on the machine, information regarding the manner in which the machine has been operated, and the price or prices being charged for operation of the machine.

In another embodiment, the invention automatically manages the operation of one or more laundromats by remotely monitoring a first set of predefined aspects of the operation of the laundromats and remotely controlling a second set of predefined aspects of the operation of the laundromats. The remote monitoring can include monitoring cash receipts from machines at the laundromats and monitoring the operation of the machines. The remote controlling can include establishing a price of operation of the machines (or different prices for different time periods during the day), testing the operation of the machines, placing machines out of service when the machines do not perform acceptably well during the testing, and controlling the contents of displays associated with the machines.

In yet another embodiment, the invention automatically acquires data regarding the expected cash receipts at each of one or more laundromats and data regarding the operation of one or more machines at each of the one or more laundromats. The invention includes an option that enables the data to be obtained automatically at each of a multiplicity of predetermined times.

In still another embodiment, the invention monitors, from a monitoring site, the conduct of a cash-basis operation that takes place at one or more operating sites, each of which include a multiplicity of machines. The invention determines, for each of one or more machines at the operating site, the amount of cash that should have been deposited in the machine during a specified period of time and monitors the operation of one or more machines at each operating site. The invention is particularly useful for monitoring a multiplicity of operating sites (especially where each operating site is geographically separated from any other operating site) or for monitoring operating sites that are geographically remote from the monitoring site.

In still another embodiment, the invention monitors the conduct of an operation that takes place at one or more operating sites, each of which include a multiplicity of devices to be monitored. The invention includes: i) a multiplicity of sensors; ii), a multiplicity of internal control units; iii) a multiplicity of site controller units; iv) a first multiplicity of communications devices for transferring data between each of the internal control units and a corresponding one of the site controller units; v) a main controller unit; and vi) a second multiplicity of communications devices for transferring data between each of the site controller units and the main controller unit. At least one sensor is mounted on each machine or device and is adapted to acquire data regarding the operation of the machine or device. At least one internal control unit is mounted on each machine or device and is adapted to receive data from the at least one sensor. At least one site controller unit is located at each laundromat or operating site. Like the immediately previous embodiment of the invention, this embodiment is particularly useful for monitoring a multiplicity of operating sites (especially where each operating site is geographically separated from any other operating site) or for monitoring operating sites that are geographically remote from the monitoring site. The invention is also particular useful in monitoring a commercial operation, especially where the operation is a cash-basis or self-service operation.

In this embodiment, the invention may further include a mechanism for monitoring communications between the main controller unit and the site controller unit and communications between the site controller unit and the internal control unit. This communication monitoring mechanism can include a mechanism for detecting communication conditions (communication conditions including successful communications, communication problems and communication errors) and a mechanism for recording communication conditions.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A and 1B are a simplified representation of a system according to an embodiment of the invention.

FIG. 1C is a block diagram of a monitoring system according to the invention.

FIG. 2 is a block diagram of a main controller unit for use with a monitoring system according to the invention such as the monitoring system of FIG. 1C.

FIG. 3 is a block diagram of a site controller unit for use with a monitoring system according to the invention such as the monitoring system of FIG. 1C.

FIGS. 4A and 4B are block diagrams of internal control units for use with a monitoring system according to the invention such as the monitoring system of FIG. 1C.

FIG. 5 illustrates a Main window of an application program of a monitoring system according to the invention.

FIG. 6 illustrates a Site Status window of an application program of a monitoring system according to the invention.

FIG. 7 illustrates a Site Status Event Information window of an application program of a monitoring system according to the invention.

FIG. 8 illustrates a Site Status Event Options window of an application program of a monitoring system according to the invention.

FIG. 9 illustrates a Site Information window of an application program of a monitoring system according to the invention.

FIG. 10 illustrates a Attendants window of an application program of a monitoring system according to the invention.

FIG. 11 illustrates a Machine Information window of an application program of a monitoring system according to the invention.

FIG. 12 illustrates a Machine Types window of an application program of a monitoring system according to the invention.

FIG. 13A illustrates a Machine Activation Fee Discounts window of an application program of a monitoring System according to the invention.

FIG. 13B illustrates a Correct Machine Activation Fee Discounts window of an application program of a monitoring system according to the invention.

FIG. 14A illustrates a Site Special Operations window of an application program of a monitoring system according to the invention.

FIG. 14B illustrates a Download Site Configuration window of an application program of a monitoring system according to the invention.

FIG. 14C illustrates a Change Password window of an application program of a monitoring system according to the invention.

FIG. 14D illustrates a Get Version Number Of Site's Software window of an application program of a monitoring system according to the invention.

FIG. 14E illustrates a Get Version Report Of Site's ICUs window of an application program of a monitoring system according to the invention.

FIG. 14F illustrates a Download Updated Site Software window of an application program of a monitoring system according to the invention.

FIG. 15 illustrates a Data Collection Parameters window of an application program of a monitoring system according to the invention.

FIG. 16 illustrates a User List window of an application program of a monitoring system according to the invention.

FIG. 17 illustrates a Business Information window of an application program of a monitoring system according to the invention.

FIG. 18 illustrates a Manual Data Acquisition window of an application program of a monitoring system according to the invention.

FIG. 19 illustrates a Collection Entry window of an application program of a monitoring system according to the invention.

FIG. 20 illustrates a Reports window of an application program of a monitoring system according to the invention.

FIG. 21 illustrates a Save Report File As window of an application program of a monitoring system according to the invention.

FIG. 22 illustrates a Report Export Options window of an application program of a monitoring system according to the invention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

According to the invention, the activities associated with an operation can be monitored directly by a single person at a monitoring site. The operation can be spread over a number of geographically separate operating sites. The monitoring site can be geographically remote from the operating sites and can even be mobile.

At each operating site, certain predefined activities are automatically monitored. Information regarding these activities is communicated to the monitoring site. This information can be used to describe the status of the operation at a given time or the change in status of the operation over a period of time. This information can also be used to verify that the operation is being properly conducted by third parties working at each operating site.

The invention can be used to monitor any type of operation. However, as will be apparent from the description below, the invention is particularly useful in monitoring a variety of commercial operations such as, for example, a chain of restaurants or a multiplicity of car washes. Further, the invention is especially useful in monitoring commercial operations that operate on a cash-basis or that are conducted primarily on a self-serve basis such as, for example, laundromats or arcades.

For example, a system according to one embodiment of the invention, shown in FIGS. 1A and 1B, is used to monitor operations at a multiplicity of laundromats, e.g., laundromats 151 and 152 (FIG. 1A). The laundromats can be located anywhere and, typically, are located at sites (operating sites) that are geographically remote from each other and from the site (monitoring site) at which an owner or manager (proprietor) monitors the operations. The system monitors machines, e.g., machines 156, 157 and 158 (FIG. 1B), that are located at each laundromat, such as washing machines, dryers, snack vending machines, soda vending machines, bag vending machines, detergent machines, extractors, money changers and bar code readers. The system can also control aspects of the operation such as automatic door locks, a heating, ventilation and cooling (HVAC) system and lights. Generally, any number of laundromats and any number of machines at each laundromat can be monitored. For example, in one embodiment, up to 200 laundromats can be monitored and, in another embodiment, up to 512 machines at each laundromat can be monitored. The system can be used to monitor many aspects of laundromat operation; however, of particular importance, the system enables the proprietor to monitor cash collections from the laundromats (i.e., identify the amount of cash that should have been collected and compare that amount to the amount that was reported as collected) and monitor performance of each machine in the laundromat (i.e., identify defects or malfunctions in the operation of a machine, as well as monitor the amount of time spent on repairing a machine).

In one embodiment of the invention, shown in FIG. 1A, a system includes a main computer 153 at the monitoring site that communicates with a site computer at each laundromat, e.g., site computers 154 and 155 at laundromats 151 and 152, respectively, via a telephone line. The proprietor uses the main computer 153 to acquire data from the site computers, e.g., site computers 154 and 155, and to issue commands to the site computers to control operations at each laundromat, e.g., laundromats 151 and 152. Each of the site computers, e.g. site computer 155 (FIG. 1B), in turn, communicates with a microcontroller (ICU) installed on each machine, e.g., ICUs 159, 160 and 161 on machines 156, 157 and 158, respectively, at the corresponding laundromat. The microcontrollers are configured to acquire information about the operation of the corresponding machine and to issue commands regarding operation of that machine. In the embodiment shown in FIG. 1B, the microcontrollers are configured to communicate with computers installed on each of the machines, e.g., computers 162, 163 and 164 on machines 156, 157 and 158, respectively. However, as will be clear from the discussion below, not all machines monitored by the invention include such computers.

FIG. 1C is a simplified block diagram of a monitoring system 100 according to the invention. The monitoring system 100 is used to monitor operations at a multiplicity of operating sites, e.g., operating sites 111, 112 and 113, from a monitoring site 101. In FIG. 1C, for simplicity, only three operating sites are shown; however the system 100 can be used to monitor any number of operating sites. Each of the operating sites can be, for instance, a coin-operated laundromat. A multiplicity of machines are located at each of the operating sites, e.g., machines 131a, 131b and 131c, machines 132a, 132b and 132c, and machines 133a, 133b and 133c at operating site 111.

In FIG. 1C, for simplicity, the machines at operating sites 112 and 113 are not shown, nor are all of the machines at operating site 111 shown. If each operating site is a laundromat, the machines can be, for instance, various types of washers and dryers, as well as snack machines, detergent machines and soda machines.

The monitoring system 100 includes a main controller unit (MCU) 102, a multiplicity of site controller units (SCUs), e.g., SCUs 121, 122 and 123, designated generally as SCU.sub.1 through SCU.sub.m, and a multiplicity of internal control units (ICUs), e.g., ICUs 141a, 141b, 141c, 142a, 143b, 142c, 143a, 142b and 143c, designated generally as ICU.sub.1 through ICU.sub.pn. The MCU 102 is located at the monitoring site 101. Each SCU is located at a corresponding one of the operating sites, e.g., SCU 121 is located at operating site 111. Each ICU is located at one of the operating sites and is associated with a corresponding one of the machines located at that operating site, e.g., ICU 141a is associated with machine 131a at site 111.

In the monitoring system 100, the MCU 102 is connected to each SCU, SCU.sub.1 through SCU.sub.m, by a communication line, e.g., MCU 102 is connected to SCUs 121, 122 and 123 by communication lines 103, 104 and 105, respectively. The communication lines 103, 104 and 105 can be, for example, conventional telephone lines (see, e.g., phone lines 165 in FIG. 1A). In another embodiment, communication between the MCU 102 and SCU.sub.1 through SCU.sub.m is implemented using a wireless cellular telephone. Use of telephone lines to connect the MCU 102 to SCU.sub.1 through SCU.sub.m enables the MCU 102 to be located at any desired monitoring site. Further, the MCU 102 can be moved easily from one monitoring site to another monitoring site. Additionally, the MCU 102 can be located at a mobile monitoring site such as an airplane or boat.

Each SCU, SCU.sub.1 through SCU.sub.m, is connected by one or more communication lines to the ICUs at that operating site. In one embodiment of the invention, one or more sets ("strings") of ICUs are connected serially to each SCU (see, e.g., communication lines 166, 167 and 168 connecting ICUs 159, 160 and 161, respectively, in FIG. 1B). In monitoring system 100, SCU.sub.1 (SCU 121), located at operating site 111, is connected serially to each of p strings of ICUs. Each string includes n ICUs. Generally, according to the invention, each string can include any number of ICUs and any number of strings of ICUs can be connected to an SCU. In one embodiment of the invention, up to 16 strings can be connected to each SCU 121 and each string can include up to 32 ICUs. In another embodiment, each string can include up to 128 ICUs.

In the monitoring system 100, the SCU 121 is connected to the ICUs 141a, 142a and 143a, i.e., the first ICU in particular strings of ICUs, by communication lines 124, 125 and 126, respectively. Each ICU that is first in a string of ICUs is then connected to the next ICU in the string by a communication line, e.g., ICUs 141a, 142a and 143a are connected to ICUs 141b, 142b and 143b, respectively, by communication lines 134a, 135a, 135a, respectively. These ICUs are, in turn, connected to the next ICU in the string by another communication line, e.g., ICUs 141b, 142b and 143b by communication lines 134b, 135b, 135b, respectively, to subsequent ICUs (not shown). All ICUs in the string are connected in a series in this manner until the last ICU in each string, e.g., ICUs 141c, 142c, 143c, is connected to the previous ICU by a communication line, e.g., communication lines 134c, 135c, 136c, respectively. Each of the communication lines 124, 125, 126, 134a, 134b, 134c, 135a, 135b, 135c, 136a, 136b, 136c can be, for example, conventional six conductor electrical cables.

Connecting the ICUs serially to the SCU, as described above, is particularly advantageous when a monitoring system according to the invention is used to monitor the operation of one or more laundromats. This is because the machines in a laundromat are typically arranged in rows, either along a wall or in aisles on a floor. It is easier to assemble a monitoring system according to the invention by connecting one communication line between the SCU and the ICU on the first machine in a row and an additional communication line between each pair of ICUs of adjacent machines, then it is to connect a communication line directly from the SCU to the ICU on each machine. However, if one of the communication lines in a string of ICUs malfunctions or is disconnected, communication is lost between the SCU and each ICU in the chain after the defective communication line.

Each ICU monitors information regarding operation of the machine associated with the ICU. The operational information can be monitored automatically by the system or only upon the request of a user of the system (as explained in more detail below). Some machines ("smart machines") include a microprocessor which monitors information regarding the operation of the machine. For those machines, the ICU communicates with the machine's microprocessor to obtain information regarding operation of the machine. Other machines (electromechanical or "dumb machines"), do not include a microprocessor: for those machines, the ICU monitors sensors installed on the machine to obtain information regarding operation of the machine. All information obtained regarding machine operation is identified with the time and date at which the described event occurred.

For dumb machines, information can only be deduced by activation of one or more of the sensors. In one embodiment, when a monitoring system according to the invention is used to monitor operation of one or more laundromats, the sensors on dumb machines sense: 1) opening and closing of the cash vault of a machine, 2) opening and closing of the service door or doors of a machine, and 3) activation of a machine. From this sensed information, the monitoring system can determine the amount of cash that should be in the machine based upon the number of activations of the machine after the cash vault was last closed (i.e., after the cash was last removed). The monitoring system also provides information that is useful in monitoring cash collections from the machine (e.g., when and for how long the cash vault is accessed) and service activity (e.g., when and for how long the service door is open) on the machine. Additionally, the monitoring system also monitors a switch that indicates whether the machine is out of order. This switch is activated manually at the operating site. The existence of an out-of-order machine can also be deduced by observing that monitored activations decrease to zero for a period of time.

For smart machines, the information that can be obtained regarding the operation of the machine is limited only by the capabilities of the machine's microprocessor. For example, in addition to all of the above information that can be obtained from the dumb machines, the smart machines may also be able to report: i) whether the machine has malfunctioned and, if so, which part; ii) identifying information regarding the mechanic or mechanics who have worked on a malfunctioning machine (this information is initially input to the smart machine by the mechanic or mechanic) iii) information regarding the manner in which the machine has been operated (e.g., for washing machines, the type of wash cycle and the temperature of the water); and iv) the prices being charged for operation of the machine (which may be dependent on the time of day and on the manner in which the machine is operated).

Monitoring information as described above is useful for a number of reasons. The monitoring of cash collections and the capacity to organize the cash collections in a variety of ways (e.g., by particular machine, by machine type or other groups of machines, by operating site, by calendar period), described in more detail below, eases accounting for income received from conduct of the operation. Monitoring of cash collections can also be useful in identifying characteristics of the operation (e.g., the location of heavily used machines within a laundromat can be identified). The monitoring of service information results in a repair record being automatically kept for each machine, thereby enabling chronically poor performing machines to be identified easily. Additionally, monitoring of service information provides the proprietor with information that can indicate whether or not a repair person has attempted scheduled repairs. Further, information regarding out-of-order machines can be used to more productively schedule repair activities (e.g., if the monitoring system indicates that no machines are out of order at an operating site, the repair person need not visit that operating site).

The monitoring capabilities of the monitoring system according to the invention provide a number of important advantages over previous monitoring methods. All of the information regarding conduct of the operation is made easily accessible so that the proprietor can quickly ascertain information regarding whatever particular aspect of the operation is of interest. The invention also provides completely up-to-date information regarding the system operation, enabling the proprietor to immediately identify problems with the operation. Additionally, any type of machine, made by any manufacturer of any model, can be monitored by the monitoring system of the invention. Moreover, all of the monitoring information can be obtained remotely at the monitoring site, without need for someone actually visit the operating sites.

For smart machines, the ICU can also communicate instructions to the machine regarding operation of the machine. The instructions that can be communicated are limited only by the capabilities of the machine's microprocessor. For example, the price of operating the machine may be specified or modified. Moreover, according to the invention, different prices may be specified for different times of day, enabling promotions such as "happy hours" to be implemented remotely. The ICU may also be used to perform diagnostic tests on the machine or components of the machine. The ICU may be used to place a machine out of service or put the machine back into service. If the machine has an associated display, the contents of the display can be controlled. If equipped with a printing mechanism, the machine can be controlled to print and dispense coupons or custom messages. Like monitoring of operational information, the instructions to the smart machines can be sent automatically by the system or only upon the request of a user of the system (as explained in more detail below).

The capacity to send instructions to smart machines also provides a number of advantages. Instructions regarding machine operation can be implemented easily and instantaneously. The instructions can be implemented from the monitoring site so that it is not necessary for someone to physically go to the operating site. Moreover, instructions can be implemented simultaneously for many or all of the machines at an operating site; instructions need not be entered in each machine separately. Additionally, instructions can be sent to any type of machine, made by any manufacturer of any model.

In order for a system according to the invention to be able to communicate with a smart machine's microprocessor, the smart machine must include a communications device that implements the same communications protocol that is implemented by the ICU mounted on the smart machine. This protocol is explained in more detail below. Without implementation of this communication protocol, a smart machine can only be treated as a dumb machine by the monitoring system.

FIG. 2 is a simplified block diagram of an MCU 200 for use with a monitoring system according to the invention, e.g., monitoring system 100 (FIG. 1C). The MCU 200 includes a memory 201, a modem 202, a display 203, a microprocessor 204 and a user interface device 205. The components of the MCU 200 can be embodied in, for example, a computer such as a desktop or notebook computer. Embodiment of the MCU in a notebook computer is particularly advantageous for enabling the MCU to be moved to various locations thereby making the monitoring site mobile.

The microprocessor 204 controls operation of the MCU 200. The microprocessor 204 can be, for example, a 386DX microprocessor running at 33 megahertz. Other later processors in the x86 series can also be used. Generally, any suitable microprocessor can be used that is compatible with an operating system and application program used to implement the invention.

The memory 201 can include, for example, a random access memory (RAM), a read only memory (ROM), and a floppy or hard disk storage device. The memory 201 is used for storing software used to control the operation of the MCU 200, such as software for controlling operation of the microprocessor 204, modem 202, display 203 and user interface device 205, and application software (described in more detail below) used to implement various characteristics of the monitoring system. The memory 204 also stores the data (described in more detail below) collected from the ICUs after that data is downloaded from the SCUs. Generally, the memory 204 must include sufficient RAM and permanent storage capacity to accommodate the above-described software. Illustratively, a RAM having 4-8 megabytes of storage capacity and a hard disk having 340-540 megabytes of storage capacity are adequate for executing and storing programs for use in controlling operation of the system according to the invention.

The display 203 can be, for example, a computer monitor and/or a printer. The display 203 is used to display data obtained by the monitoring system according to the invention or to display choices for effecting control of the monitoring system, as described in more detail below.

The user interface device 205 can be, for example, a conventional computer keyboard, conventional mouse, conventional trackball, or some combination of those. The user interface device 205 enables a user to input and display data describing the status of the operation being monitored and to effect control of the monitoring system.

The MCU 200 communicates with each SCU through a communication line (e.g., communication line 103, 104 or 105 in FIG. 1C) that is connected to the modem 202 of the MCU 200. Communication from the MCU to the SCU includes, for example, instructions regarding data collection from, and operation of, particular machines (as explained in more detail below) at the operating site. Communication from the SCU to the MCU includes, for example, data from each machine regarding operation of the machine (as explained in more detail below). As described above, the communication line between the SCU and MCU is, in one embodiment, a conventional telephone line. In such an embodiment, the modem 202 is a conventional modem for use in sending and receiving data over telephone lines. The modem 202 is, in one embodiment, a 2400 baud external modem. However, modems having other data transmission rates greater than 2400 baud can also be used. Communication between the MCU and SCU is governed by a standard ZMODEM protocol.

FIG. 3 is a simplified block diagram of an SCU 300 for use with a monitoring system according to the invention, e.g., monitoring system 100 (FIG. 1C). As described above, an SCU such as SCU 300 is located at each operating site of the operation being monitored. The SCU 300 includes a real time clock 301, a microprocessor 302, a communications device 303, a modem 304, an input/output (I/O) device 305, a video interface device 306 and a memory 307, all of which are encased in a housing.

The communication line between the SCU 300 and the MCU is connected to the modem 304 of the SCU 300. Before allowing communication with the MCU, the SCU 300 must receive an appropriate password (i.e., a password that matches one of the passwords stored in the memory 307) from the MCU. In the embodiment in which the communication line is a conventional telephone line, the modem 304 is a conventional modem for use in sending and receiving data over telephone lines. The modem 304 is, in one embodiment, a 2400 baud modem. However, modems having other data transmission rates greater than 2400 baud can also be used.

Information (e.g., data and instructions as described above) is transferred between the modem 304 and the microprocessor 302. The microprocessor 302 controls the flow of information through the SCU 300 and performs any calculations and processing operations necessary for operation of the SCU 300. The microprocessor 302 can be, for example, a 286 processor or any later processor in the x86 series. However, any suitable microprocessor can be used.

The real time clock 301 is conventional and communicates with the microprocessor 302. The real time clock 301 keeps track of the time of day and date at the operational site at which the SCU 300 is located. Each time that the MCU begins a communication with the SCU 300 (i.e., after each occasion when a proper password is received by the MCU), the MCU checks the real time clock 301 to ascertain the time and date at the operating site and synchronizes the time and date at the monitoring site (i.e., the location of the MCU) to that at the operating site. This is particularly desirable when the monitoring site and the operating site are in different time zones, since much of the information transferred back and forth between the MCU and SCU is associated with a particular date and time.

The microprocessor 302 also communicates with the memory 307. The memory 307 includes a hard disk storage device, a read-only memory (ROM) and a random access memory (RAM). The memory 307 is used for storing software used to control the operation of the SCU 300, such as operating system software for controlling operation of the microprocessor 302, communications software (described in more detail below) for controlling operation of the communications device 303, communications software for controlling operation of the I/O device 305, and communications software for controlling operation of the video interface device 306. The memory 307 also stores software which controls the acquisition of data from the ICUs regarding operation of the machine and sending of commands to the ICUs to control operation of the machine. Additionally, the memory 307 stores information regarding the configuration of machines at the site and the operating status (e.g., out of order) of machines, as well as data collected from the ICUs regarding operation of the machines at the operating site.

The microprocessor 302 also communicates with the communications device 303. The communications device 303 enables communication between the SCU 300 and each of the ICUs at the operational site at which the SCU 300 is located. Communications from the SCU to each ICU includes, for example, instructions regarding data collection from the machine associated with the ICU, operation of the machine and sensor or machine microprocessor testing (as appropriate). Communication from each ICU to the SCU includes, for example, data regarding operation of the machine or the status of the sensors or machine microprocessor. As shown in FIGS. 1C and 3 (and explained in more detail above with respect to FIG. 1C), the SCU 300 is connected to p strings of ICUs, each of which are interconnected in a daisy-chain fashion. Generally, the communications device 303 is conventional; however, the communications device 303 must be capable of multi-drawing (i.e., communicating with multiple devices in a chain).

In one embodiment, the communications device 303 is a standard RS-485 communications board commercially available from, for instance, Quatech in Akron, Ohio. The following parameters may be set for communication over the RS-485: Baud Rate is set to 4800 bps, Parity is set to "None", Data Bits is set to 8, and Stop Bits is set to 1.

As mentioned above, the memory 307 is used for, among other things, storing a communications protocol (SCU-ICU protocol) for governing communication between the SCU 300 and the ICUs. (A similar protocol is stored in a memory in a microcontroller of each ICU; see microcontroller 402 in ICUs 400 and 450 of FIGS. 4A, and 4B, respectively, below.) In one embodiment of the invention, the SCU-ICU protocol is a packet protocol, i.e., information is passed between the SCU 300 and the ICUs in packets that can vary in size. Thus, only as much information as is necessary is passed during each communication between the SCU and an ICU, increasing the efficiency and speed of the communication. Each packet of information includes information that indicates the size of the packet. Further, since the ICUs are connected serially in a daisy-chain fashion, each packet of information includes an address indicating the destination of the information (i.e., SCU or particular ICU) to ensure that the information is received by the proper device. Details of a particular embodiment of the SCU-ICU protocol for enabling communication between the SCU and ICU are given immediately below.

All communications between an SCU and the corresponding ICU's are initiated by the SCU. All commands sent from the SCU ("SCU commands") are two bytes in length. The first byte specifies the address of the ICU to which the command is directed. (Note that the SCU may send a command to all ICUs on a string by using the Command Broadcast option described below.) The second byte contains the actual information to be transmitted to the ICU.

The bits of the first byte of an SCU command have the format given below in TABLE 1:

                  TABLE 1
    ______________________________________
    SCU-ICU Protocol, Byte #1 of SCU Command
    7      6            5     4-0
    ______________________________________
    0      0            CB    Device Address
    ______________________________________


Bit 7 is zero, indicating that the command is an SCU command. Bit 6 is also zero, indicating that the byte is the first byte of an SCU command. Bit 5 ("CB") is used to turn the Command Broadcast option on or off: "1" indicates that the command is to be sent to all ICUs on the string. The address of the ICU to which the command is to be sent is designated by bits 0 through 4 ("Device Address"). (Note that 32 unique addresses can be formed with these bits, corresponding to the limitation of 32 ICUs on each string.) The ICU address is specified by an application program, as described below, that controls operation of the monitoring system according to the invention. The bits of the second byte of an SCU command have the format given below in TABLE 2:

                  TABLE 2
    ______________________________________
    SCU-ICU Protocol, Byte #2 of SCU Command
    7            6     5-0
    ______________________________________
    0            1     Command Code
    ______________________________________


Bit 7 is 0 since this is an SCU command. Bit 6 is 1, indicating that the byte is the second byte of an SCU command. Bits 0 through 5 ("Command Code") are used to specify a particular command to the ICU.

TABLE 3 is a table of commands (in hexadecimal notation) that are legal according to this embodiment of the SCU-ICU protocol. Each of these commands is discussed in more detail below.

                  TABLE 3
    ______________________________________
    SCU-ICU Protocol, SCU Command Codes
    Code (H)         Description
    ______________________________________
    00               Send Data
    01               Clear Counters
    02               Go Active
    03               Go Inactive
    04               Perform Self Test
    05               Reset
    06               Repeat Last Data
    07               Send Firmware Version
    08               Not Defined
    09               Not Defined
    OA-3F            Not Defined
    ______________________________________


The "Send Data" command is used by the SCU to periodically interrogate each ICU for new events (e.g., new information regarding operation of the machine on which the ICU is mounted). The length of time between interrogations is a parameter that can be established by the user of the system. Illustratively, the time between interrogations can be approximately one minute; given the typical rapidity with which events occur regarding operation of machines monitored by the system, this is a length of time that generally enables accurate capture of those events. Each ICU responds to receipt of the "Send Data" command by transmitting a command ("ICU command") back to the SCU. The ICU command includes from one to five bytes depending on the command being sent.

Each ICU command includes at one byte specifying the ICU status. The bit format of the first byte of an ICU command is shown in TABLE 4.

                  TABLE 4
    ______________________________________
    SCU-ICU Protocol, Byte #1 of ICU Command
    7            6-5     4-0
    ______________________________________
    1            STAT    Device Address
    ______________________________________


Bit 7 is 1, indicating that the command is an ICU command. Bits 5 and 6 ("STAT") are used to indicate the ICU status. Bits 0 through 4 are used to specify the address of the ICU sending the command. TABLE 5 is a table of possible values of STAT.

                  TABLE 5
    ______________________________________
    SCU-ICU Protocol, ICU Status Bits
    STAT               Description
    ______________________________________
    00                 No New Data
    01                 Data Available
    10                 ICU Fault
    11                 Power Up
    ______________________________________


If the ICU has no new data to send to the SCU (i.e., no additional data since the last interrogation by the SCU), then the STAT field indicates "No New Data" (STAT=00) and the ICU response consists of this byte only.

If the ICU has new data to transmit (i.e., additional data since the last interrogation by the SCU), then the STAT field indicates "Data Available" (STAT=01) and additional response bytes are necessary. The first three of these bytes are used to transmit information regarding the sensors being monitored by the ICU. The bit format of these three bytes is given in TABLE 6.

                  TABLE 6
    ______________________________________
    SCU-ICU Protocol, Bytes # 2, 3, 4 of ICU Command
    7    6       5         4-3     2       1-0
    ______________________________________
    1    DAT     Sen0/2/4  Sen0/2/4
                                   Sen1/3/5
                                           Sen1/3/5
                 Level     Count   Level   Count
    ______________________________________


Bit 7 is 1, indicating an ICU command. Bit 6 ("DAT") is used to indicate whether an additional byte follows the current byte: "1" indicates that an additional byte will follow the present byte and "0" indicates there is no additional byte. Bit 5 is used to indicate the logical status of sensor 0, 2 or 4 (sensors 0, 2 and 4 are reported on sequential bytes, i.e., sensor 0 is reported in byte #2, sensor 2 in byte #3 and sensor 4 in byte #4): "0" means CLOSED and "1" means OPEN. Bits 3 and 4 are used to indicate the number of sensor cycles (CLOSED-OPEN-CLOSED) that have occurred since the last SCU interrogation for sensor 0, 2 or 4 (again, sensors 0, 2 and 4 are reported on sequential bytes). Bit 2 is used to indicate the logical status of sensor 1, 3 or 5 (sensors 1, 3 and 5 are reported on sequential bytes, i.e., sensor 1 is reported in byte #2, sensor 3 in byte #3 and sensor 5 in byte #4): "0" means CLOSED and "1" means OPEN. Bits 0 and 1 are used to indicate the number of sensor cycles (CLOSED-OPEN-CLOSED) that have occurred since the last SCU interrogation for sensor 1, 3 or 5 (again, sensors 1, 3 and 5 are reported on sequential bytes). TABLE 7 indicates the sensor assignments according to one embodiment of the invention.

                  TABLE 7
    ______________________________________
    SCU-ICU Protocol, Sensor Assignments
    Sensor #         Descriptions
    ______________________________________
    0                Front Service Door
    1                Cash Vault Door
    2                Machine Activator
                     (e.g., Coin Mechanism)
    3                Top Service Door
    4                Unassigned
    5                Unassigned
    ______________________________________


A count of up to 3 cycles can be transmitted by each ICU command. Cycles in excess of 3 ("excess cycles") are not counted for each sensor except the Machine Activator sensor. For the Machine Activator sensor, the number of cycles counted are stored in a memory of the ICU. The number of cycles counted is decremented by up to three cycles, as appropriate, by each ICU command; thus, excess cycles are not ignored, but rather are transmitted with a subsequent ICU command. Failure to count excess cycles for other sensors generally is not a limitation, since those sensors monitor activities for which more than three cycles is extremely unlikely to occur during the period between SCU interrogations.

An ICU command can also include a fifth byte that is used to transmit information regarding the operational status of the machine being monitored by the ICU, i.e., whether the machine is out of order or not. The bit format of this fifth byte of an ICU command is given in TABLE 8.

                  TABLE 8
    ______________________________________
    SCU-ICU Protocol, Byte #5 of ICU Command
    7      6              4-1      0
    ______________________________________
    1      DAT            Not Used OOO
    ______________________________________


Bit 7 is 1, indicating an ICU command. Bit 6 ("DAT") is used to indicate whether an additional byte follows the current byte, as described above with respect to TABLE 6. Bits 1 through 4 are not used and are set equal to zero to indicate that they are inactive. Bit 0 ("OOO") is used to indicate the logical status of the "Out-of-Order" switch on the machine: "1" indicates that the "Out-of-Order" switch is active, i.e., the machine is out of order.

If the ICU is experiencing a fault, then the STAT field of the first ICU command byte indicates "ICU Fault" (STAT=10) and an error byte is inserted between the first byte of the ICU command and the additional response bytes. The bit format of the error byte is given in TABLE 9.

                  TABLE 9
    ______________________________________
    SCU-ICU Protocol, Error Byte of ICU Command
    7            6      5-0
    ______________________________________
    1            DAT    Faulty Sensor Bits
    ______________________________________


Bit 7 is 1, indicating an ICU command. Bit 6 ("DAT") is used to indicate whether an additional byte follows the current byte, as described above with respect to TABLE 6. Bits 0 through 5 are used to indicate the existence of faulty sensors (bit 0 corresponds to sensor 0, bit 1 corresponds to sensor 1, etc.): "1" indicates a faulty sensor.

If power to the ICU has been lost and recovered since the last interrogation by the ICU, then the STAT field of the first ICU command byte indicates "Power Up" (STAT=11). The ICU command also includes three additional bytes reporting the status of each sensor. If another data event (i.e., ICU fault or sensor cycle) has occurred between the "Power Up" condition and the SCU interrogation, then that data event takes precedence and is reported to the SCU.

As indicated in TABLE 3 above, the SCU can send commands other than the "Send Data" command.

The "Clear Counters" command is used to instruct the ICU to reset the ICU's sensor CYCLE counters. The ICU acknowledges receipt of this command by echoing the command back to the SCU.

The "Go Active" command is used to instruct the ICU to exit the "Inactive" mode (see "Go Inactive" command below) and begin scanning the sensors again. The ICU acknowledges receipt of this command by echoing the command back to the SCU.

The "Go Inactive" command is used to instruct the ICU to cease scanning the sensors. The ICU acknowledges receipt of this command by echoing the command back to the SCU. This command may be issued, for example, to stop acquisition of data from the sensors when one or more sensors are defective. When issued to the ICU of a smart machine, this command is used to disable the smart machine so that the smart machine can not be used.

The "Perform Self Test" command is used to instruct the ICU to perform the Built in Test (BIT), a program for testing operation of the ICU that is stored in the EEPROM that is part of the microcontroller 402. The ICU acknowledges receipt of this command by echoing the command back to the SCU. If the BIT fails, then the ICU reports an ICU Fault (STAT=10) in response to the next SCU interrogation.

The "Reset" command causes the ICU to perform a "hard reset" of all components of the ICU. For an ICU that is used with a smart machine (see ICU 450 in FIG. 4B below), the "Reset" command also resets the microprocessor of the smart machine (see smart machine CPU 410 in FIG. 4B below). Since this is a hardware reset, the ICU does not echo back the command to the SCU or respond in any other way if the "hard reset" is successful. However, if the ICU fails to execute the "hard reset", the ICU will echo back the command to the SCU.

The "Repeat Last Data" command is used to request the ICU to re-transmit the last data packet (stored in a memory of the ICU) previously sent by the ICU. The ICU re-transmits the data packet immediately upon receiving the "Repeat Last Data" command and does not wait for the next SCU "Send Data" command from the SCU. This is done to avoid sending additional data obtained since the first "Send Data" command.

The "Send Firmware Version" command is used to get the version number of the ICU's current firmware. The ICU responds with a command having a bit format as shown in TABLE 10.

                  TABLE 10
    ______________________________________
    SCU-ICU Protocol, ICU Firmware Version Command
    7            6     5-0
    ______________________________________
    1            0     Firmware Version
    ______________________________________


Bit 7 is 1, indicating an ICU command. Bit 6, similar to the "DAT" bit described above with respect to TABLE 6, is always zero, indicating that no additional byte will follow. Bits 0 through 5 are used to indicate the version number of the ICU firmware: the version number is expressed as 1.xx, where "xx" is the number represented by bits 0 through 5.

As indicated above, the ICU response to many SCU commands is to echo back the command to the SCU. However, if an SCU command has been broadcasted to all ICUs on a string (i.e., the Command Broadcast bit is turned on), the ICUs do not echo back the command in order to prevent the data contention that would otherwise result.

Returning to FIG. 3, the I/O device 305 and the video interface device 306 are provided to enable a user interface device (console 308) to communicate on-site with the SCU 300. The I/O device 305 and the video interface device 306 are both conventional. In one embodiment, the I/O device 305 is a serial RS-232 interface available commercially from IBM in Armonk, N.Y. The video interface device 306 can be, for example, a monochrome video card interface such as is widely commercially available.

The housing of the SCU 300 is provided with interface connections that allow connection of the console 308. Typically, the console 308 includes both a monitor and a keyboard. Generally, the console 308 is portable and does not remain connected to the SCU 300.

The capability of connecting the console 308 allows a technician to perform diagnostic tests on the SCU 300 or any of the ICUs to verify proper operation or diagnose problems. This is particularly useful, for example, because it allows the technician, after replacement of a defective sensor or ICU, to verify proper operation of the sensor or ICU. Software for enabling the diagnostic tests to be performed is stored in the memory 307. The diagnostic tests can include, for example, testing a sensor to determine if the sensor is good or bad, testing the ICU firmware (described below) to verify proper operation, testing the integrity of the connection between a sensor and the firmware, and testing proper operation of the auxiliary power supply.

Though not shown in FIG. 3, an SCU can also be equipped with a card reader and corresponding circuitry within the SCU for accepting input information from the card reader. Such a card reader can be used, for example, as a time clock for employees working at the operating site. The card reader could also be used with conventional debit cards to allow customers to use the debit cards to activate the machines. Or, the card reader can be used with promotional cards, recording machine usage by a customer and awarding free machine usage based upon the paid machine usage or at random for a particular visit by a particular customer.

Though also not shown in FIG. 3, an SCU can also be equipped with a controller and associated circuitry that automatically operates equipment at the operating site such as automatic door locks, HVAC system and lights.

It is to be understood that the SCU can perform many more types of control and monitoring functions not discussed herein. Generally, the SCU can perform any such functions that can be implemented with computer control.

FIGS. 4A and 4B are simplified block diagrams of ICUs 400 and 450, respectively, for use with a monitoring system according to the invention, e.g., monitoring system 100 (FIG. 1C). The ICU 400 is for use with dumb machines (i.e., machines that do not include a microprocessor) and the ICU 450 is for smart machines (i.e., machines that do include a microprocessor). One of the ICUs 400 or 450 is mounted, in any convenient manner, on each machine that is to be monitored.

FIG. 4A is a simplified block diagram of an ICU 400 for use with a dumb machine that is monitored by the monitoring system according to the invention. ICU 400 includes a sensor interface device 401, a microcontroller 402, a communications device 403, an addressing unit 404, a microcontroller supervisor 405, a backup power source 406, and an output interface 408.

Each of n terminals on the sensor interface 401 of the ICU 400 are electrically connected to a corresponding one of a multiplicity of sensors 407 mounted on the machine to be monitored. In one embodiment, an electrically conductive twisted pair of wires is used to make connection between each sensor and the corresponding sensor interface terminal. The wires are bundled together and the connection between the wire bundle and the sensor interface is made using a male/female connector pair. This configuration makes it easy to replace and reconnect the sensor interface 401 if the interface becomes defective.

According to one embodiment of the invention, up to 6 sensors can be monitored. Various types of sensors can be used as the sensors 407: electrical, mechanical, optical and magnetic. For example, an electrical sensor available as Part No. PADP-110220-10-600 from Persyst, Inc. of Tustin, Calif. can be used with the invention. A magnetic sensor available as Model No. 1034-N from Sentrol, Inc. in Portland, Ore. can also be used with the invention. A mechanical sensor available as E13-50H from Cherry Electrical Products in Waukegan, Ill. can also be used with the invention.

Preferably, the sensors used with the invention are single pole, dual throw sensors, i.e., sensors which generate an electrical signal requiring power in either the "off" or "on" position. It is desirable to use such a sensor with the invention because, unlike a single throw switch, it is possible to detect that the sensor has been disconnected or is malfunctioning as opposed to simply not activated.

Information from the sensors 407 is transferred from the sensor interface 401 to the microcontroller 402. The microcontroller 402 controls all functions of the ICU 400. The microcontroller 402 operates according to firmware, i.e., the microcontroller 402 includes an electrically erasable programmable read only memory (EEPROM) that is programmed with the instructions for operating the microcontroller 402. For example, the firmware can test the sensor interface 401 or sensors 407 to verify proper operation, test proper functioning of the power supplies, and test correct operation of the firmware. As explained in more detail below, the firmware can be revised according to instructions received from by the ICU from the MCU. The microcontroller 402 can be, for example, one of the microcontrollers from the 8051 family of microcontrollers, such as the 89C51 or 89D52 microcontroller. However, any suitable microcontroller can be used.

The microcontroller supervisor 405 monitors the power supply to the microcontroller 402. When power is interrupted, the microcontroller supervisor 405 causes the backup power 406 (implemented using a PADP adapter or a super capacitor) resident on the ICU 400 to begin supplying power to the microcontroller 402 so that the ICU 400 will continue to function. The microcontroller supervisor 405 is conventional; any of a number of commercially available microcontroller supervisors can be used.

The addressing unit 404 supplies information to the microcontroller 402 that uniquely identifies the ICU 400 to enable information transferred between the ICU 400 and the SCU to be addressed. This is necessary to ensure proper attribution of information transferred along the string of ICUs of which ICU 400 is part. The address stored by the addressing unit 404 is specified using DIP switches. In the embodiment in which up to 32 ICUs can be included in each string, ICU 400 has an address within the range 0 to 31. The addressing unit 404 is a conventional 8-position DIP switch. Any of a number of commercially available 8-position DIP switches can be used.

The microcontroller 402 also communicates with the communications device 403. The communications device 403 enables communication between the ICU 400 and the SCU at the operating site. The communications device 403 must be capable of performing the same communications functions as the communications device 303 of the SCU 300 (FIG. 3). In one embodiment, the communications device 403 is, like the communications device 303, an RS-485 communications board. However, generally, the communications device 403 need not necessarily be the same as the communications device 303.

The microcontroller 402 also communicates with the output interface 408. The output interface 408 enables the ICU 450 to control an output device or devices associated with a smart machine. The output interface 408 can be used to, for example, control a relay to disconnect or connect power to the machine to place the machine out of service or in service, respectively. The output interface 408 can also be used to control a display or a printing mechanism associated with the machine. The output interface 408 is a conventional device driver or drivers, e.g., a relay driver, display driver, printer driver, as necessary for control of the output device or devices being used.

FIG. 4B is a simplified block diagram of an ICU 450 for use with a smart machine that is monitored by the monitoring system according to the invention. The ICU 450 is similar to the ICU 400 and similar components are denoted by the same numbers in FIGS. 4A and 4B. However, to enable communication with the microprocessor 410 of a smart machine, the ICU 450 also includes a second communications device 409.

The second communications device 409 enables the ICU 450 to obtain from the smart machine microprocessor 410 information regarding aspects of the operation of the smart machine. This information is in addition to the information obtained by the sensors 407, i.e., in addition to the information that is obtained by the ICU 400 for a dumb machine. Additionally, the second communications device 409 enables the ICU 450 to transmit instructions to the smart machine microprocessor 410 to control aspects of the operation of the smart machine. In one embodiment of the invention, the second communications device 409 is implemented as both a RS-232 and a Direct Link. The user can switch between the two implementations of the second communications device 409 using conventional jumper blocks. The following parameters may be set for communication over the second communications device 409: Baud Rate is set to 4800 bps, Parity is set to "None", Data Bits is set to 8, and Stop Bits is set to 1. The second communications device 409 is connected to a corresponding communications device on the smart machine with a 6 pin RJ-11 connector. The pinout for the RJ-11 connector is shown in TABLE 11 below.

                  TABLE 11
    ______________________________________
    ICU-Machine Protocol, Interface Pinout
    Pin #   Pin Name       Description
    ______________________________________
    1       TXD            ICU Transmit Data Line
    2       RXD            ICU Receive Data Line
    3       GPI            ICU General Purpose
                           Input Line
    4       GPO            ICU General Purpose
                           Output Line
    5       GND            Common Ground
    6       NC             Not Connected
    ______________________________________


A communications protocol (ICU-machine protocol) stored in the EEPROM of the microcontroller 402 and in a memory located in the smart machine governs the communication between the ICU 450 and the smart machine's microprocessor. In order for the smart machine microprocessor to communicate with the ICU 450, the microprocessor must implement this ICU-machine protocol; otherwise, the smart machine is treated like a dumb machine. However, any machine that does implement the ICU-machine protocol can communicate with the monitoring system according to the invention regardless of the manufacturer or model of the machine. Like the SCU-ICU protocol described above with respect to FIG. 3, the ICU-machine protocol governing communication between a smart machine microprocessor and the ICU 450 is a packet protocol. Further, the SCU-ICU protocol should work in Full-Duplex fashion. Details of one embodiment of the ICU-machine protocol for enabling communication between the ICU 450 and the microprocessor of a smart machine is given immediately below.

The ICU-machine protocol is an "Echo" type handshake protocol, i.e., any information byte transmitted by one device (either the smart machine microprocessor or the ICU) is echoed back (acknowledged) by the other device. Generally, information bytes transmitted according to the ICU-machine protocol conform to the bit format shown in TABLE 12.

                  TABLE 12
    ______________________________________
    ICU-Machine Protocol, Information Byte Format
    7              6         5-0
    ______________________________________
    SM/ICU*        DAT/CMD*  DATA
    ______________________________________


Bit 7 ("SM/ICU*") indicates whether the information byte originates with the machine ("1") or the ICU ("0"). For communication from the ICU to the smart machine, bit 6 ("DAT/CMD*") indicates whether the information byte is a data byte ("1") or a command byte ("0"). For communication from the smart machine to the ICU, bit 6 indicates whether another information byte follows the current information byte ("1") or not ("0"). Bits 0 through 5 contain the actual information to be communicated, either data or a command.

The commands include a set of Universal Commands and a set of Manufacturer-Specific Commands. Preferably, the smart machine supports the Universal Command set though, strictly speaking, this is not necessary. If a Universal Command is not supported, then, instead of echoing the command, as would normally happen, the smart machine sends an information byte including the "Command Not Supported" command (see TABLE 13). The Manufacturer-Specific Commands enable implementation of commands that are specific to machines made by a particular manufacturer. These commands enable additional functionality to be added to the ICU-machine protocol easily.

TABLE 13 is a table of Universal Commands (in hexadecimal notation) according to one embodiment of the ICU-Machine protocol. These commands are discussed in more detail below.

                  TABLE 13
    ______________________________________
    ICU-Machine Protocol Commands
    Command  Description     Code     Origin
    ______________________________________
    SMFGID   Send Manufacturer ID
                             00H      ICU
             Code
    SMMODEL  Send Machine Model #
                             01H      ICU
    SSMVER   Send SM Firmware
                             02H      ICU
             Version
    SICUVER  Send ICU Firmware
                             03H      SM
             Version
    ACTPREQ  Activate Permission
                             04H      SM
             Request
    GOFF     Go inactive (pause
                             05H      ICU
             cycle)
    GON      Go active (continue
                             06H      ICU
             cycle)
    SRES     Perform a Soft Reset
                             07H      ICU
    HRES     Perform a Hard Reset
                             08H      ICU
    HELLO    Alive check     09H      ICU
    RCVPR    Receive Price Update
                             0AH      ICU
    SNDPR    Send Prices     0BH      ICU
    NEVENT   New Event       0CH      SM
    SNDLEV   Send SM Sensors level
                             0DH      ICU
             Info
    SNDSEN   Send ICU Sensors Info
                             0EH      SM
    SSMFLT   Send SM Fault   0FH      ICU
             Registers
    SICUFLT  Send ICU Fault  10H      SM
             Register
    PSELFT   Perform Self Test
                             11H
    DSCNT    Activate Price  12H      ICU
             Discount
    DSCLEV   Report discount level
                             13H      ICU
    SNDSTAT  Send Machine Status
                             14H      ICU
    MFGCMD   Following is a  15H      ICU
             manufacturer specific
             command structure
             Not Defined     16H-3DH
    KILL     Abort Current Command
                             3EH      ICU
    NSP      Command not supported
                             3FH      SM
    ______________________________________


The "Send Manufacturer ID" (SMFGID) command is used by the ICU to request information identifying the manufacturer of the machine with which the ICU is associated. The machine responds with a first information byte that echoes the command (bit 7 is changed, of course, to reflect that the machine is now sending the information byte, rather than the ICU) and a second information byte that indicates the manufacturer of the machine. This second information byte conforms to the bit format given in TABLE 14.

                  TABLE 14
    ______________________________________
    ICU-Machine Protocol, Manufacturer Data Byte
    7            6     5-0
    ______________________________________
    1            1     Manufacturer Code
    ______________________________________


Bits 6 and 7 conform to the format given above with respect to TABLE 12. Bits 0 through 5 ("Manufacturer Code") are used to represent the manufacturer name. In one embodiment of the invention, the bits specifying the Manufacturer Code conform to the hexadecimal designations given below in TABLE 15.

                  TABLE 15
    ______________________________________
    ICU-Machine Protocol, Manufacturer Data Bits
    Code (H)            Manufacturer
    ______________________________________
    00                  Wascomat
    01                  GE
    02                  Maytag
    03                  Whirlpool
    04                  Dexter
    05                  Unimac
    06                  Speed Queen
    07                  Huebtch
    08                  Ipso
    09                  Milnor
    0A                  Primus
    0B                  American
    0C-3E               Undefined
    3F                  Wrong Mfg.
    ______________________________________


Upon receipt of the second information byte from the machine, as described above, the ICU echoes back that byte to the machine.

The "Send Machine Model Code" (SMODEL) command is used by the ICU to request information identifying the model of the machine with which the ICU is associated. After echoing the command, the machine responds with a second information byte that indicates the machine model. This second information byte conforms to the bit format given in TABLE 16.

                  TABLE 16
    ______________________________________
    ICU-Machine Protocol, Model Data Byte
    7            6     5-0
    ______________________________________
    1            0     Manufacturer Model
    ______________________________________


Bits 6 and 7 conform to the format given above with respect to TABLE 12. Bits 0 through 5 ("Manufacturer Model") are used to represent the model name. The bits specifying the Manufacturer Model conform to a list (similar to the list of TABLE 15 above) specified by each manufacturer. Up to 64 different models can be specified. The ICU echoes back the second information byte.

The "Send SM Firmware Version" (SSMVER) command is used by the ICU to request information identifying the version of the firmware implemented in the machine. After echoing the command, the machine responds with second and third information bytes that indicate the firmware version. The second and third information bytes conform to the bit format given in TABLE 17 and TABLE 18, respectively.

                  TABLE 17
    ______________________________________
    ICU-Machine Protocol, Byte #1 of Machine Firmware Data
    7            6     5-0
    ______________________________________
    1            1     Version # Prefix
    ______________________________________


TABLE 18 ______________________________________ ICU-Machine Protocol, Byte #2 of Machine Firmware Data 7 6 5-0 ______________________________________ 1 1 Version # Suffix ______________________________________


Bits 6 and 7 conform to the format given above with respect to TABLE 12. Bits 0 through 5 ("Version # Prefix" or "Version # Suffix") are used to represent the prefix or suffix of the firmware version number. For example, to report that Version 1.01 is implemented, byte 2 is C1H and byte 3 is C1H (in hexadecimal notation). To report that Version 3.31 is implemented, byte 2 is C3H and byte 3 is DFH (in hexadecimal notation). Note that, due to the number of bits allocated for representation of the version number, the maximum version number that can be represented is Version 63.63. The ICU echoes back the second and third information bytes.

The "Send ICU Firmware Version" (SICUVER) command is used by the machine to request information identifying the versions of the firmware implemented in the ICU. After echoing the command, the ICU responds with second and third information bytes that indicate the firmware version. The second and third information bytes conform to the bit format given in TABLE 19 and TABLE 20, respectively.

                  TABLE 19
    ______________________________________
    ICU-Machine Protocol, Byte #1 of ICU Firmware Data
    7            6     5-0
    ______________________________________
    0            1     Version # Prefix
    ______________________________________


TABLE 20 ______________________________________ ICU-Machine Protocol, Byte #2 of ICU Firmware Data 7 6 5-0 ______________________________________ 0 1 Version # Suffix ______________________________________


Bits 6 and 7 conform to the format given above with respect to TABLE 12. Bits 0 through 5 ("Version # Prefix" or "Version # Suffix") are used to represent the prefix or suffix of the firmware version number. For example, to report that Version 1.01 is implemented, byte 2 is 41H and byte 3 is 41H (in hexadecimal notation). To report that Version 3.31 is implemented, byte 2 is 43H and byte 3 is 5FH (in hexadecimal notation). Again, the maximum version number that can be represented is Version 63.63. The machine echoes back the second and third information bytes. The "Activation Permission Request" (ACTPREQ) command is used by the machine to ask the ICU permission to begin an operating cycle after the appropriate payment has been received. This command is used to ensure that the rest of the monitoring system is operating properly before allowing a machine to begin an operating cycle. After echoing the command, the ICU responds with a second information byte that indicates whether or not the operating cycle is allowed to begin. This second information byte conforms to the bit format given in TABLE 21.

                  TABLE 21
    ______________________________________
    ICU-Machine Protocol, Activation Permission Data Byte
    7      6             5-1      0
    ______________________________________
    0      1             Not Used PER*
    ______________________________________


Bits 6 and 7 conform to the format given above with respect to TABLE 12. Bits 1 through 5 are not used and are set equal to to indicate that they are inactive. Bit 0 (PER*) indicates whether permission to activate the machine is granted ("0") or not granted ("1"). The machine echoes back the second information byte.

The "Inactive" (GOFF) command is used by the ICU to instruct the machine to immediately enter non-operational mode. After receiving an "Inactive" command, the machine cannot issue an "Activation Permission Request" command or perform operating cycles until the machine receives a "Go Active" command (see below). The machine acknowledges receipt of the command by echoing the command back to the ICU.

The "Go Active" (GON) command is used by the ICU to instruct the machine to enter operational mode. The "Go Active" command is used in conjunction with the "Inactive" command, i.e., after the "Inactive" command, and instructs the machine to commence normal operation. The machine acknowledges receipt of the command by echoing the command back to the ICU.

The "Soft RESET" (SRES) command is used by the ICU to instruct the machine to perform a Soft Reset; i.e., to jump to the first address ("base address") used by the software implemented by the machine microprocessor. The machine echoes the command, then waits an appropriate amount of time (e.g., 4 milliseconds) before jumping to the base address so that the echo can be transmitted before the reset.

The "Hardware RESET" (HRES) command is used by the ICU to instruct the machine to perform a Hardware Reset; i.e., toggle the actual CPU RESET line of the machine microprocessor. The machine echoes the command, then, as above, waits an appropriate amount of time (e.g., 4 milliseconds) before executing the reset

The "Hello" (HELLO) command is used by the ICU to confirm the existence of communication with the machine. Normally, the machine informs the ICU of new events (e.g., machine activations) on a regular basis. However, in some circumstances, the machine may not have any events to report (e.g., a long period with no activations). To verify that there is no problem with the communication between the ICU and machine, and that the lack of communication is only due to an unusual absence of events to report, the ICU issues the "Hello" command. The machine acknowledges receipt of the command by echoing the command back to the ICU.

The "Receive Price Updates" (RCVPR) command is used by the ICU to update the machine prices for different types of operational cycles. The ICU transmits a series of command bytes according to the structure shown in TABLE 22.

                  TABLE 22
    ______________________________________
    ICU-Machine Protocol, Transmit Prices Data Bytes
    Command Byte #
                 7     6        5-0    Price
    ______________________________________
    1            0     0        001010 Command
    2            0     1        0000BB 1
    3            0     1        AAAAAA 1
    4            0     1        0000BB 2
    5            0     1        AAAAAA 2
    *            *     *        *      *
    2*n          0     1        0000BB n
    2*n + 1      0     1        AAAAAA n
    ______________________________________


The first byte of each series is the "Receive Price Updates" (RCVPR) command. The remaining bytes ("price bytes") are used to specify prices for each of n operational cycles. The price bytes are transmitted in groups of two, each group of two corresponding to one of the operational cycles. The sequence of operational cycles is established according to specifications established by the manufacturer of the machine. Groups of price bytes need only be sent up to the last operational cycle for which a price is being established. Bit 7 of each price byte is 0, indicating the information is sent from the ICU to the machine. Bit 6 of each price byte is 1, indicating that the information is data. Bits 1 through 5 in each pair of price bytes are used to represent a price in increments of 5 cents. Though 12 bits are available for specifying a price, only the least significant 8 bits are used, i.e., the two least significant bits ("BB") of the first byte of the pair and all six bits ("AAAAAA") of the second byte of the pair.

Since only 8 bits are used, the maximum price that can be specified is $12.75. For example, a price of $3.50, represented in hexadecimal notation as 46 and in binary notation as 01000110, is transmitted as "01" in bits 0 and 1 of the first byte and "000110" in bits 0 through 5 of the second byte. The machine echoes back each of the price bytes.

The "Send Cycle Prices" (SNDPR) command is used by the ICU to request the machine prices for different types of operational cycles. The ICU issues the "Send Cycle Prices" command. The machine echoes the command, then sends a series of price bytes (bytes 2 through 2*n+1) according to the structure shown above in TABLE 22. The ICU echoes back each of the price bytes transmitted by the machine.

The "New Event Report" (NEVENT) command is used by the machine to report to the ICU any time an event (i.e., change in a sensor) has occurred. After sending the "New Event Report" command, the machine sends two additional information bytes that indicate the type of event being reported. The second and third information bytes conform to the bit format given in TABLE 23 and TABLE 24, respectively.

                  TABLE 23
    ______________________________________
    ICU-Machine Protocol, Byte #1 of New Event Report Data
    7    6      5-4      3       2      1     0
    ______________________________________
    1    1      Not Used Service #2
                                 Not Used
                                        Vault Service #1
    ______________________________________


TABLE 24 ______________________________________ ICU-Machine Protocol, Byte #2 of New Event Report Data 7 6 5 4-0 ______________________________________ 1 1 Activation Cycle Type ______________________________________


Bits 6 and 7 conform to the format given above with respect to TABLE 12. Bits 2 and 5 of the second information byte are not used and are set equal to 0. Bits 0, 1, and 3 of the second information byte, and bit 5 of the third information byte indicate whether the corresponding sensor has been activated, i.e., the sensors for service door #1, the cash vault door, service door #2, and the machine activation mechanism, respectively. A "1" in a sensor bit location indicates that the sensor has been activated, while a "0" means the sensor has been inactive. For example, if Service #1 is "1," it means that service door #1 is open. A "1" in Activation means that the machine commenced a cycle (wash, dry, etc.). Bits 0 through 4 of the third information byte are used to indicate the type of cycle, e.g., cold wash, warm wash, permanent press, etc. Up to 32 different types of cycles can be specified (one may be used to indicate whether the machine is out of order).

The "Send SM Sensors Info" (SNDLEV) command is used by the ICU to inquire from the machine as to whether an event has occurred. After echoing the command, the machine responds with second and third information bytes that indicate the type of event being reported. The second and third information bytes conform to the bit format given in TABLE 23 and TABLE 24, respectively (discussed above). The cycle type started is encoded as indicated above. The ICU echoes back the second, third and fourth information bytes.

The "Send ICU Sensors Info" (SNDSEN) command is used by the machine to request information regarding sensors (e.g., sensors 407) monitored by the ICU. After echoing the command, the ICU responds with second, third and fourth information bytes that indicate the state of the sensors being monitored by the ICU. The second, third and fourth information bytes conform to the bit format given in TABLE 25, TABLE 26, and TABLE 27, respectively.

                  TABLE 25
    ______________________________________
    ICU-Machine Protocol, Byte #1 of Sensor Data
    7   6       5        4-3      2      1-0
    ______________________________________
    0   1       Sensor #1
                         Sensor #1
                                  Sensor #2
                                         Sensor #2
                Level    Count    Level  Count
    ______________________________________


TABLE 26 ______________________________________ ICU-Machine Protocol, Byte #2 of Sensor Data 7 6 5 4-3 2 1-0 ______________________________________ 0 1 Sensor #3 Sensor #3 Sensor #4 Sensor #4 Level Count Level Count ______________________________________

TABLE 27 ______________________________________ ICU-Machine Protocol, Byte #3 of Sensor Data 7 6 5 4-3 2 1-0 ______________________________________ 0 1 Sensor #5 Sensor #5 Sensor #6 Sensor #6 Level Count Level Count ______________________________________


Bits 6 and 7 conform to the format given above with respect to TABLE 12. Bits 2 and 5 of each of the second, third, and fourth information bytes indicate whether a sensor is active: "0" means INACTIVE and "1" means ACTIVE. Bits 3 and 4, and bits 0 and 1 are each used to indicate the number of sensor cycles (CLOSED-OPEN-CLOSED) that have occurred since the last machine interrogation. These counters are necessary in case the machine requests this information infrequently enough for complete sensor cycles to occur. Generally, the counters will increase to a maximum of 3 and will remain there until read by the machine. The sensor for sensing machine activations will continue to count above 3 activations; the excess activations are reported as explained above. The counters are reset after each time that the "Send ICU Sensors Info" command is issued. In this embodiment, the ICU can monitor up to 6 sensors. The machine echoes back the second, third and fourth information bytes.

The "Send SM Fault Registers" (SSMFLT) command is used by the ICU to ascertain the state of the fault registers of the machine. After echoing the command, the machine responds with second and third information bytes that indicate the state of the machine fault registers. The second and third information bytes conform to the bit format given in TABLE 28 and TABLE 29, respectively.

                  TABLE 28
    ______________________________________
    ICU-Machine Protocol, Byte #1 of Fault Registers Data
    7   6       5      4      3    2      1    0
    ______________________________________
    1   1       SEN6   SEN5   SEN4 SEN3   SEN2 SEN1
    ______________________________________


TABLE 29 ______________________________________ ICU-Machine Protocol, Byte #2 of Fault Registers Data 7 6 5 4 3 2 1 0 ______________________________________ 1 1 SEN12 SEN11 SEN10 SEN9 SEN8 SEN7 ______________________________________


Bits 6 and 7 conform to the format given above with respect to TABLE 12. Bit 0 through 5 of each of the second and third information bytes indicate whether a particular sensor is faulty or not: "1" indicates a fault and "0" indicates no fault. The machine resets the bits 0 through 5 after responding to the "Send SM Fault Registers" command. The sensors are defined as shown in TABLE 30 ("TBD" refers to undefined sensors). Other sensor definitions can be used.

                  TABLE 30
    ______________________________________
    ICU-Machine Protocol, Machine Sensor Definition
    Sensor #           Description
    ______________________________________
    SEN1               Water Pump
    SEN2               Water Valve
    SEN3               Heating Element
    SEN4               TBD
    SEN5               TBD
    SEN6               TBD
    SEN7               TBD
    SEN8               TBD
    SEN9               TBD
    SEN10              TBD
    SEN11              TBD
    SEN12              TBD
    ______________________________________


The ICU echoes back the second and third information bytes.

The "Send ICU Fault Registers" (SICUFLT) command is used by the machine to obtain information regarding malfunctioning of the sensors monitored by the ICU. After echoing the command, the ICU responds with a second information byte that indicates which, if any, of the ICU sensors are malfunctioning. The second information byte conforms to the bit format given in TABLE 31.

                  TABLE 31
    ______________________________________
    ICU-Machine Protocol, Faulty Sensor Data
    7   6       5      4      3    2      1    0
    ______________________________________
    0   1       SEN6   SEN5   SEN4 SEN3   SEN2 SEN1
    ______________________________________


Bits 6 and 7 conform to the format given above with respect to TABLE 12. Bits 0 through 5 of the second information byte indicate whether a particular sensor is faulty or not: "1" indicates a fault and "0" indicates no fault. The ICU resets the bits 0 through 5 after responding to the "Send ICU Fault Registers" command. The sensors are defined in any manner that is appropriate for the particular machine being monitored. For example, for smart machines that do not themselves monitor any of the sensors associated with monitoring of dumb machines, bits 0 through 5 are defined to correspond to appropriate ones of those sensors. Other sensor definitions can be used. After the ICU responds with the second information byte, the machine echoes back the second information byte.

The "Perform Self Test" (PSELFT) command is used by the ICU to instruct the machine to perform a self test. After echoing the command, the machine responds with second, third, and fourth information bytes. The second information byte indicates the results of the self test and conforms to the bit format given in TABLE 32.

                  TABLE 32
    ______________________________________
    ICU-Machine Protocol, Byte #2 of Machine Self Test Data
    7       6           5-3      2-0
    ______________________________________
    1       1           Not Used Result Code
    ______________________________________


TABLE 33 ______________________________________ ICU-Machine Protocol, Machine Test Result Codes Result Code Description ______________________________________ 000 Pass 001 TBD 010 TBD 011 TBD 100 TBD 101 TBD 110 TBD 111 Fail ______________________________________


The third and fourth bytes indicate the state of the machine fault registers, as discussed above, and conform to the bit format given in TABLES 30 and 31. The ICU echoes back the second, third and fourth information bytes.

The "Activate Price Discount" (DSCNT) command is used by the ICU to instruct the machine to activate one of three different price discounts or use the regular price. The ICU sends the "Activate Price Discount" command, followed by a second information byte having the bit format shown in TABLE 34.

                  TABLE 34
    ______________________________________
    ICU-Machine Protocol, Price Discount Data Byte
    7      6           5-2      1-0
    ______________________________________
    0      1           Not Used Discount Code
    ______________________________________


The "Discount Code" bits are interpreted as indicated in TABLE 35.

                  TABLE 35
    ______________________________________
    ICU-Machine Protocol, Discount Codes
    Discount Code     Description
    ______________________________________
    00                Regular Price Discount
    01                Price Discount 1
    10                Price Discount 2
    11                Price Discount 3
    ______________________________________


The machine responds by echoing back the two information bytes sent by the ICU.

The "Report Price Discount" (DSCNT) command is used by the ICU to retrieve the current price discount from the machine. After echoing the command, the machine responds with a second information byte that indicates the discount in effect. The second information byte conforms to the bit format given in TABLE 34 and the Discount Codes in TABLE 35. The ICU echoes back the second information byte.

The "Send Machine Status" (SNDSTAT) command is used by the ICU to retrieve the current machine status (i.e. operating, idle, etc.) from the machine. After echoing the command, the machine responds with a second information byte that indicates the machine status. The second information byte conforms to the bit format given in TABLE 36.

                  TABLE 36
    ______________________________________
    ICU-Machine Protocol, Machine Status Byte
    7       6           5        4-0
    ______________________________________
    1       1           Operating
                                 Cycle Type
    ______________________________________


Bits 6 and 7 conform to the format given above with respect to TABLE 12. Bit 5 indicates whether the machine is in the middle of an operating cycle or not: "1" means that the machine is in the middle of a cycle and "0" means that the machine is off. Bits 0 through 4 ("Cycle Type") indicate the type of machine cycle as discussed above. The ICU echoes back the second information byte.

The "Manufacturer Specific" (MFGCMD) command is used by the ICU to issue manufacturer-specific commands not included in the Universal Command Set. The capability to issue manufacturer-specific commands allows new features to be added to the monitoring system of the invention as such features become available, without the need to modify the ICU-machine protocol. After sending the "Manufacturer Specific" command, the ICU sends a second information byte that identifies the particular manufacturer to whom the command pertains. The second information byte conforms to the bit format given in TABLE 37.

                  TABLE 37
    ______________________________________
    ICU-Machine Protocol, Manufacturer Identification Byte
    7            6     5-0
    ______________________________________
    0            1     Manufacturer Code
    ______________________________________


The "Manufacturer Code" bits are interpreted as indicated in TABLE 15 above.

Following the second information byte, the ICU sends additional command bytes corresponding to the manufacturer-specific command. The bit format of these bytes is specified to convey desired information in a manner similar to that of the information bytes described above. The particular bit format depends upon the particular manufacturer-specific command.

The "Abort Current" (KILL) command is used by the ICU when the machine has responded to a previously sent command by echoing back an incorrect command. The "Abort Current" command instructs the machine to ignore the previously sent command. The machine responds by echoing back the command.

The "Not Supported" (NSP) command is returned by the machine after receiving a command from the ICU that is not supported or understood by the machine. The ICU echoes back the "Not Supported" command.

As mentioned above, the MCU of a system according to the invention (e.g., MCU 102 of FIG. 1C or MCU 200 of FIG. 2) can be embodied as a computer. When embodied as a computer, the MCU can be controlled by one or more computer programs. In one embodiment of the invention, the MCU is an IBM-compatible computer using the Windows 3.1 operating system (other versions of Windows can also be used) available from Microsoft of Redmond, Wash. An application computer program (described in more detail below) that is compatible with the Windows 3.1 operating system is used to implement various aspects of the invention. A database is used to store information describing the operation being monitored. As will be apparent from the description below, the application program uses menus, mouse and keyboard functions, and file and print windows that are similar to those implemented by Windows 3.1. Below, aspects of the invention are described as implemented in a Windows 3.1 applications program that operates in conjunction with a relational database to effect monitoring of an operation. However, it is to be understood that this description is only illustrative and that, generally, the invention can be implemented on any type of computer using any operating system with an application program and database that achieve the same monitoring capabilities.

The application program enables control of many aspects of a monitoring system according to the invention. The application program controls communication between the monitoring site and the operating sites, i.e., retrieval of information regarding operations at the operating sites and sending of instructions to the operating sites. In addition, the application program controls processing of the information retrieved from the operating site and stores information regarding the operations at the operating sites. The application program also generates reports regarding operations at the operating sites.

Generally, the application program accepts input from the user interface device of the MCU, e.g., user interface device 205 of MCU 200 (FIG. 2), interprets the type of input, and engages in an appropriate action. For example, the user input may be an instruction to update information describing the operation (i.e., update information in the relational database) such as the amount of money collected from particular machines or a description of the types of machines located at an operating site. The application program interprets the instruction to determine which information needs to be updated, then updates the relational database as appropriate. In another example, the user input is an instruction to produce a report regarding a particular aspect of the operation being monitored. The application program determines the type of report to be generated, and generates the report using the appropriate information from the relational database. Additionally, the application program can engage in an action other than as a result of an instruction provided by the user. For example, as explained below, the user can specify that data is to be automatically acquired from an operating site at a particular time. The application program monitors an internal clock in the MCU and, when the designated time arrives, the application program issues an instruction to the SCU at the operating site to begin transferring data to the MCU that has been acquired from the ICUs on the machines. The application program then uses the acquired data to update the appropriate portions of the relational database.

In one embodiment of the invention, the application program is accessed by selecting a predefined icon in the Program Manager window of Windows 3.1. In the following description, reference is sometimes made to selecting an icon, an option or an entry. In such a context, generally, "selecting" refers to clicking a mouse, pressing the "Tab" key or "Enter" key on a keyboard, or performing any other predefined user input operation when an item on the display (such as a menu option, an icon or an entry in a list) is highlighted. An item is highlighted by moving a cursor to the appropriate location on the display, as is well known. The cursor can be moved from item to item or field to field by using a mouse or the "Tab" key or cursor keys on a keyboard.

At this point, the user is prompted for login information: user name and user password. More than one user can be logged into the application program at one time. Associated with each user name is a password and a security level that define the type of access that a particular user can have to the application program. In one embodiment of the invention, described in more detail below, the application program has three security levels: System Administrator, General User and Data Entry User. The System Administrator has access to all aspects of the application program and is typically the owner of the business for which the monitoring system according to the invention is being used. General Users have more limited access to the program and may be, for example, a manager of one or more of the operating sites. Data Entry Users have the most limited access to the program. The multiple security levels are an important deterrent to teaming up by people other than the business owner to manipulate the monitoring system to enable stealing from the operation or other undesirable conduct.

After the user name and password are correctly entered, the MCU display shows a Main window 500, as shown in FIG. 5. The Main window 500 is divided into four sections which provide a quick overview of the state of the monitoring system. The Current User section 510 displays the user name of the person who is currently using the application program. The System Health section 520 indicates whether or not any problems with operation of the monitoring system have been detected (as explained in more detail below). If no problems have been detected, "OK" will appear in the System Health section 520. If errors have been detected, "Errors, see Site Status" will appear, as shown in FIG. 5. The Data Acquisition Mode section 530 indicates whether or not data is being retrieved automatically from each operating site. If data is being retrieved automatically, "Automatic" will appear in the Data Acquisition Mode section 530. If data is not being retrieved automatically, "Manual" will appear. The Date and Time section 540 indicates the current date and time.

The Main window 500 also includes a menu bar 550 located at the top of the Main window 500. The menu bar 550 includes a System menu 551, a Reports| option 552, an Acquire Data| option 553 and a Collection Entry| option 554 and a Help option 555. Each of these choices in the menu bar 550 are described in more detail below.

The System menu 551 includes seven options (not shown): Site Status, Site Information, Data Collection Parameters, User List, Business Information, Logout and Exit. Each of these options is described in more detail below.

The first option in the System Menu 551 is Site Status. Choosing Site Status causes a Site Status window 600 to be displayed, as shown in FIG. 6. The Site Status window 600 is divided into two sections: the Site Status Log 610 and the Out of Order Machines list 620. The Site Status Log 610 shows a record of all successful communications, communication problems and communication errors ("communication conditions") resulting from attempted communications between the MCU and an SCU or between an SCU and an ICU. The Out of Order Machines list 620 is a list of all machines that are currently out of order.

The Site Status Log 610 provides a detailed account of the communications between components of a monitoring system according to the invention. The Site Status Log 610 includes an entry for each communication condition. Each entry includes information in each of seven columns.

In the first column 611, one of three logos appears, indicating the type of communication condition described by the entry. The first logo, a red stop sign, indicates a communication error. Communication errors include: the malfunction of a service door sensor, cash vault sensor, or machine activation sensor; the failure of the ICU to respond to an SCU interrogation; and the failure of the MCU to connect to an SCU via the telephone line. The second logo, a yellow circle with an exclamation point, indicates a communication problem. A communication problem occurs when there is a discrepancy between the data sent by a machine and the data received by the SCU or the MCU. This differs from a communication error in which the machine simply fails to transmit requested data. The third logo, a blue circle with an exclamation point, indicates the occurrence of a benign event. Benign events include MCU login and logout, MCU data acquisition from the SCU, SCU data transfer to the MCU, MCU download of information to the SCU, manual shutdown of the SCU at the operating site, and manual start-up of the SCU at the operating site.

The microcontroller 402 enables communication conditions to be recognized. The application program instructs the software stored in the memory 307 of the SCU 300 to obtain information from the microcontroller 402 regarding the communication conditions. The obtained information is sent by the SCU to the MCU (i.e., to the application program) for use in the Site Status window 600.

The second column 612 (designated by the header "Date") indicates the date that the communication condition first occurred.

The third column 613 (designated by the header "Time") indicates the time that the communication condition first occurred.

The fourth column 614 (designated by the header "Site") indicates the operating site with which the communication condition is associated.

The fifth column 615 (designated by the header "Unit") indicates the number of the machine (or "unit") with which the communication condition is associated.

The sixth column 616 (designated by the header "Event") gives a description of the communication condition. This description corresponds to one of the particular types of successful communications, communications problems, and communications errors described above with respect to the logos displayed in the first column.

The seventh column 617 (designated by the header "Cleared") indicates that a communication error or communication problem has been cleared (i.e., corrected). The application program recognizes that a communication error or communication problem has been cleared if the communication error or communication problem does not occur during the next attempt of the type of communication that gave rise to the problem or error. No entry ever appears in the seventh column 617 for a successful communication.

For example, the ICU of a machine may fail to respond to an inquiry from the SCU. The first time this occurs, an entry would be added to the Site Status Log 610 including a red stop sign logo, the date and time of occurrence, the operating site and unit number associated with the attempted communication, and a description of the communication problem. Nothing, however, would appear at that time in the Cleared column of that entry. Each subsequent occurrence of a failure of that particular ICU to respond to an inquiry from that particular SCU would not result in the generation of an additional entry in the Site Status Log 610. When the ICU finally does respond to an inquiry from the SCU, an "