Monitoring system with particular application to monitoring a cash-basis operation5694323Abstract 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: Description BACKGROUND OF THE INVENTION
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
______________________________________
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
______________________________________
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
______________________________________
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
______________________________________
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
______________________________________
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
______________________________________
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 " | ||||||
