WO1987003406A1

WO1987003406A1 - Supervisory control system having improved memory management

Info

Publication number: WO1987003406A1
Application number: PCT/US1986/002560
Authority: WO
Inventors: David Michael Martin, Jr.
Original assignee: SENSOR SCAN Inc
Current assignee: SENSOR SCAN Inc
Priority date: 1985-11-26
Filing date: 1986-11-26
Publication date: 1987-06-04
Anticipated expiration: 1988-05-26
Also published as: EP0247185A1

Abstract

An alarm system includes a plurality of slave controllers (11), each controlling a device such as a fire detector, window closure switch, temperature sensor, or alarm bell. The slave controllers (11) communicate through communication lines (12) and (13) with a master controller (10) which, for example, has the capability of polling the slave controllers (11) to determine their status or the status of the various devices they control.

Description

SUPERVISORY CONTROL SYSTEM HAVING IMPROVED MEMORY MANAGEMENT ^'"

BACKGROUND OF THE INVENTION

The invention relates to supervisory systems such as used with burglar or fire alarms or with remote sensors for sensing such parameters as humidity or tem¬ perature. A supervisory system is a system for monitor¬ ing and controlling the operation and function of a number of devices and/or sensors typically at a plural¬ ity of remote locations. The system includes a cen¬ tral, master controller, which is in communication with a plurality of slave controllers, at each of the remote locations. Each slave controller will monitor and con¬ trol one or more devices. For example, in a burglar alarm system a slave controller at a particular lo¬ cation may monitor a number of window and door closure sensors and operate an associated burglar alarm. In a fire alarm system, a slave controller monitors a number of fire or smoke detectors and makes an appropriate response when a detector is tripped. For example, the slave controller can respond by activating a tradition- al fire alarm bell or it can send a signal to a central station or activate a telephone autodialer for contact¬ ing the local fire department.

Systems operating on the same principle are also used to monitor environmental parameters such as temperature and humidity sometimes with associated alarms when the environmental parameters vary beyond tolerable limits.

Known supervisory systems including master and slave controllers are typically devised with a par- ticular installation site in mind. The number of slave controllers, fire detection units, alarm bells and the like are known in advance. The master controller typi¬ cally contains an EPROM, which is prepared for the par¬ ticular installation site and installed in the master controller.

Other more sophisticated supervisory systems are more easily programmable to accommodate the varying requirements at different installation sites. These systems require considerable random access memory to provide sufficient programming capability so that the system can accommodate a significant number of config¬ urations. Systems of this sort are generally large scale and expensive.

SUMMARY OF THE INVENTION The present invention provides a supervisory system which is extremely flexible in the number of configurations it can assume and which has a large ca¬ pacity for keeping track of events occurring in the system. Briefly, a system according to the invention includes a plurality of slave controllers, each con¬ trolling a device such as a fire detector, window clo¬ sure switch, temperature sensor, or alarm bell. The slave controllers communicate with a master controller which, for example, has the capability of polling the slave controllers to determine their status or the sta¬ tus of the various devices they control. The system achieves its flexibility in the manner in which the slave controllers, the devices, alarm conditions or other types of status conditions and other items of data are stored and managed in the random access memory of the master controller. The master controller in¬ cludes a processor which associates with each slave controller of the system a "hardware object," which comprises a portion of the random access memory and a plurality of procedures corresponding to the various tasks which the slave controllers can perform. The processor also associates one or more "reaction ob¬ jects" with each hardware object, a reaction object similarly comprising a portion of random access memory and a collection of procedures. The processor also defines a "system trouble class," which provides for the creation of "system trouble objects" (a. portion of random access memory and associated procedures) which are used to indicate a failure of communications be- tween the master and slave controllers. The master controller also includes a means for enunciating changes of status of the various devices in response to the procedures specified by the reaction objects. The means similarly enunciates changes of status of the system as a whole in response to the procedures of the system trouble objects.

Other "objects" may also be defined by the processor for keeping track of or responding to other types of conditions associated with the system. For conditions which are not always present, the processor defines an appropriate "class" of procedures for creat¬ ing and purging the "objects" as needed. With proper purging and compaction of the random access memory ac¬ cording to the invention, a comparatively small random access memory is needed, which is advantageous at the least in that it allows for cost effective fabrication of a system.

Other advantages and features of the in¬ vention will be evident from the remaining portions of the specification and the attached drawings.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is an overall block diagram showing a particular arrangement of master and slave control¬ lers in a supervisory system of the present invention. Figure 2 is a functional block diagram of a portion of the master controller showing a means for communicating with the slave controllers according to the invention.

Figure 3 is a functional block diagram of a slave controller.

Figure 4 is a block schematic diagram of an embodiment of the master controller showing digital circuitry and analog functional block.

Figure 5 is a schematic of an implementation of analog circuitry for the master controller.

Figure 6 is a schematic diagram of an imple¬ mentation of analog circuitry for the slave controller.

Figure 7 is a schematic diagram of an alarm bell supervision circuit for use with the analog implementation of Figure 6.

Figure 8 is a diagrammatic representation of one possible state of the object memory rising in a simple implementation of the present invention.

Figure 9 is a diagrammatic representation of the initial, nonfragmented state of the object memory of Figure 8.

Figure 10 is a diagrammatic representation of a fragmented memory in an idealized situation.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT A. System Overview

Figure 1 shows an overall view of an illus¬ trative configuration of a supervisory system. The system includes a master controller 10 and a plurality of slave controllers 11 which are connected in parallel to the master controller by communication line 12. In the present system the line 12 need consist of only a single pair of wires, sometimes referred to as a "twisted pair." In an actual installation in the field it may be convenient to bundle the twisted pair 12 with other lines for other purposes; however, for proper operation of the present invention only a single twist¬ ed pair is needed. As explained more fully below, the line 12 is used both to provide two-way communications between the master and slave controllers and to deliver DC power to the slave controllers for operation of the slaves them¬ selves and of any controlled devices. Thus, when line 12 is referred to as a communications line, "communica¬ tions" is used in the broad sense to encompass the com¬ munication of both power and information, and no limi- tation to only data communications is intended.

For proper operation of the system a single twisted pair 12 is sufficient to define a communica¬ tions loop and is all that is needed to define a mini¬ mal configuration of the present invention. However, for reasons explained below, a preferred embodiment also includes a return loop 13 consisting of a second pair of wires.

A feature of the present system is its great flexibility in the number of system configurations which can be accommodated. For purposes of illus¬ tration, Figure 1 shows one such configuration based upon a room having a fire alarm system, a burglar alarm system, and a system for monitoring the room tempera¬ ture. A configuration like this might be used, for example, in connection with a high-security air-conditioned room containing a mainframe computer, which for proper operation is to be maintained within fixed temperature limits.

As illustrated in Figure 1, the first two slave controllers are dedicated to the fire alarm sub¬ system. Slave No. 1 communicates with three fire de¬ tection units at three separate inputs. Suitable fire detection units for the use with the present system, such as smoke detectors or heat detectors, are commer- cially available. Slave No. 2 communicates with a fourth fire detection unit and a fire alarm bell, which is activated under command from the master controller 10 when one of the fire detection units has been tripped, as will be explained below. Slave Nos. 3-5 comprise the burglar alarm subsystem. Slave No. 3 is connected to a door closure switch for detecting when the door to the room has been opened. At a parallel input slave No. 3 is connected to a window closure switch for detecting when a window has been opened and in series to a window integrity switch, such as a strip of metallic tape adhered to the window pane, for de- tecting when the window has been broken. Slave No. 4 is connected to a person detector for determining the unauthorized presence of a person in the room. Suit¬ able person detectors may be provided by motion detec¬ tors or infrared detectors and are well known in the security art. Slave No. 5 communicates with a burglar alarm bell, which is activated upon command from the master controller 10 in response to an alarm condition sensed by one of the burglar detection units.

The fire detection units and burglar de- tection units are provided by binary switches; that is, they are either tripped or they are not tripped. The alarm bells are similarly controlled by binary relays, which are either open or closed. By contrast, slave No. 6 controls a temperature sensor, which is an analog unit monitoring continuous temperature and providing continuous temperature data to slave No. 6. As in¬ dicated in Figure 1, the master controller of the pre¬ sent system still has further capacity for supervising other slave controllers located either in the same room as slave controllers Nos. 1-6 or in other remote lo¬ cations.

Figure 1 is presented only by way of example, and no limitation of the invention to this particular configuration or any particular number of slave con- trollers is intended. As will be apparent below, the system can be configured in many ways—strictly as a burglar alarm system, as a fire alarm system, as a sys¬ tem for monitoring environmental parameters, or as any combination. In addition, the size of the system can vary over a wide range, for example, to monitor an in¬ dividual room or to monitor a number of independent offices.

The master controller 10 controls all data communication with the slaves. It provides a source of DC power for the slaves, and serves various other functions such as providing programming capability for tailoring the system for a particular configuration of slaves and devices, for providing alarm indicators, and for sensing for a break in the line 12.

The distinctive communication ability of the present system, whereby the system provides both data communications and a DC power source simultaneously over the same twisted pair, may be understood by refer¬ ence to Figure 2. The master controller includes a transmitting means 16 and a receiving means 17, both of which are connected to line 12 at terminals 18 for com- munications with the slaves.

The transmitting means provides a modulated DC voltage signal at the terminals 18. This signal can be thought of as comprised of an uninterrupted DC volt¬ age component for supplying DC power, on which is su- perimposed a varying component bearing the data. The uninterrupted DC component has a potential equal to the potential at the node 19. The potential at this point is equal to the potential of the master controller pow¬ er supply (nominally 12V) reduced by a predetermined voltage drop (about 2V in the illustrated embodiment) across voltage drop circuit 21. Although the master controller supply voltage is indicated as a 12V in Fig¬ ure 2, this is only a nominal value. In the illustrat¬ ed embodiment the actual value is closer to 14V, so that the uninterrupted DC component available on line 12 is roughly 12V.

The data component is generated by pulse-modulating the nominal 12V supply for the master controller. The modulation is accomplished by pulse modulator switch 22, which switches the voltage drop circuit in and out upon command from a processor unit (the microprocessor unit 23 seen in Figure 4). A data pulse from the processor unit is applied to power driv¬ er 26, which then applies a 24-volt control pulse to the pulse modulator switch 22. DC/DC converter 27, also under control of the processor, provides a 24-volt control source for power driver 26 and voltage drop circuit 21. In this manner, in response to a pulse train from the processor unit along line 21, the trans¬ mitting unit 16 supplies a voltage signal to the loop terminals 18 varying nominally between 12 and 14 volts. As will be explained below, at each slave controller the 12 to 14 volt modulation is demodulated and inter¬ preted as a data signal, and the remaining 12 volts sent out over the line to the slaves is available as a power source. From time to time the slave controllers will answer messages received from the master controller. In contrast to the voltage-modulated signal transmitted by the master controller, the slave controllers return a current-modulated signal. This signal is received by the receiving unit 17, demodulated, and sent to the master processor unit for interpretation. The receiv¬ ing unit 17 senses for changes in the current at the loop terminals 18. Current in the loop is applied across the primary side of the toroidal transformer 31. The current change across the primary side is felt as a voltage change across the secondary side. This voltage is applied to a limiter circuit 32 to avoid overdriving the subsequent circuits. From the limiter circuit the signal is applied to integrater and filter circuits which serve as a gain control and wave shaping circuit 33. The integrater and filter shapes the incoming signal approximately into a triangular waveform. The waveform is then applied to a phase lock loop 34, which serves as a frequency sampling circuit generating a pulsed signal which is then sent to the data input of the processor. Loop short sense circuit 36 senses a loss of voltage if the loop should be shorted out and sends a pulse to the nonmashable interrupt (NMI) part of the master controller processor to stop the^' data trans¬ mission. In the opposite situation of a break in the line 12, the loop return line 13 can be used to commu¬ nicate with slaves on the other side of the break from the terminals 18. In this situation, the loop return 13 is connected to the transmitting and receiving means 16 and 17 by loop return relay 37, which is energized on command from the master controller processor.

The communication function of the slave con¬ trollers is now described broadly with reference to Figure 3. The signal from the master controller is re¬ ceived at a slave controller at the terminals 41. The signal is applied to the receive detector 42 and also to a 5-volt regulator 43. Since 5 volts is substantially less than the minimum value of 10 to 12 volts of any signal coming in from the master controller, the regula¬ tor 43 has no difficulty filtering out any pulsation so as to provide a constant source. This source supplies power to the slave controller unit itself. At the termi¬ nals 41 a pair of coils 44 filters out the varying data component, if any, from the signal on the line and pro¬ vides the full uninterrupted DC component at terminals 46 for use as a power source.

The receive detector 43 includes a transform¬ er input 47 coupled to a comparator 48. The fluc¬ tuations of the modulated voltage signal off the line are transferred from the primary to the secondary side of the transformer, where they are compared with the reference voltage level of comparator 48, which thereby generates a pulse train in response to the incoming signal. This pulse train is applied to the input of a nonretriggerable monostable multivibrator (one-shot) 49. The leading edge of a pulse will trigger the one-shot 49, which provides a 13 microsecond output pulse for each input pulse. In this manner, any noise or other irregularity of the input signal will not be seen at the output of the one-shot 49. The pulse from one-shot 49 is applied straight into the data input of the on-board microprocessor unit (MPU) 50, which is a receive-timer input for looking at the pulses. The output signal from the nonretriggerable one-shot 49 is also applied to a retriggerable one-shot 51 having an output applied to the interrupt request (IRQ) line of MPU 50. A signal on the IRQ line alerts the MPU that a data signal is coming in so that the MPU will be pre¬ pared to count pulses. As long as a signal is coming in, the retriggerable one-shot 51 is held low, return- ing to high only at the end of an incoming pulse train. As will be explained in more detail below, each slave controller has its own address, which is set by the eight-position address select switch 52. The master controller, wishing to send a message to a par- ticular slave controller, will begin its transmission with the address of the target slave controller. The MPU 50 compares the incoming signal with the address specified by the address select 52 to determine if that slave controller has been called. If no match is found, the MPU of that slave controller does not re¬ spond.

The slave controllers transmit their messages to the master controller by modulating the current on the line 12 in response to a data signal from the on-board MPU. Specifically, a data signal from the MPU 31 is applied to a transmit driver 53, which functions as an on-off switch. Closure of the switch causes ex¬ tra current to be drawn off the line 12. When the switch opens, the current returns to normal. The mod¬ ulated line current is then demodulated at the master controller, as indicated above. Depending upon the frequency of the output data signal from MPU 51, interference or cross-talk with other slave controllers will sometimes occur. That is, the slave controllers will sometimes "see" each other and try to communicate. To avoid this pos- sibility, a "divide by 2" circuit 54 is inserted be¬ tween the data output of MPU 50 and the transmit driver 53.

As presently described, whether the transmit driver 53 ends up in a high or low state is dependent upon the final output of the "divide by 2" circuit at the end of a unit of transmission. To assure that the driver ends up in the off position, a driver hold-off circuit 56 is applied in parallel with the "divide by 2" circuit. The driver hold-off circuit assures that the divider always ends up in the off position, thereby assuring that the transmit driver itself will end up in the off position.

The slave controller includes digital input means 57 providing three input lines for connection to external two-state devices such as door closure switch¬ es, which are either in a tripped or untripped state. Digital output means 58 enables the slave to trip an external device such as an alarm bell or a central re¬ lay. Analog interface means 59 enables the slave to communicate with an external analog device such as a temperature or humidity sensor.

One of the features of the present system is its great flexibility in the number of configurations it can assume with comparatively small memory avail- able. This flexibility is achieved by programming the dynamical aspects of the system using an ob¬ ject-oriented approach. For a detailed exposition of an object-oriented language, reference is made to SMALLTALK-80, The Language and Its Implementation, by A. Goldberg and D. Robson, Addison-Wesley Publishing Co., Reading, Massachusetts (1983), the disclosure of which is incorporated herein by reference. For ease of exposition some of the elementary terminology of ob¬ ject-oriented architectures is now explained. The com¬ ponents of an object-oriented architecture are object, message, receiver, class, instance, instance variable and method. An object is a component of the system represented by some private memory and the set of op¬ erations which can be performed upon that memory. A message is the request for an object to carry out one of its operations. A receiver is the object to which a message is sent. A class is a description of a group of similar objects. An instance is an object described by a class. An instance variable is one element in object's private memory, and a method is a description of how to perform one of an object's operations. By Smalltalk-80 convention, a name describing an instance of a class is not capitalized, while a name describing a class is.

Some of the objects that we need to define to run a minimum configuration of this system are a FireZone class, a Trip class, a Hardware class, a BOC (bell output condition) class, a SysTrouble class and a Diagnostic class. These classes may or may not have instances. The Hardware class is responsible for im¬ plementing the functions having to do with communicat- ing to the slave controllers. The FireZone class is responsible for implementing reactions to the statuses acquired by the hardware objects. The Trip class cre¬ ates and purges trip instances as the status of a hard¬ ware object changes from a normal to an abnormal state and back. A BOC instance is created when a trip occurs at a FireZone indicating that an alarm condition should be annunciated. The Diagnostic and SysTrouble classes are used to detect trouble. SysTrouble is used to de¬ tect communications failure with a slave controller, while Diagnostic is used to detect trouble at the mas¬ ter controller such as a low battery or a short across a bell output. To enable the system to be configured and reconfigured in the field, the system includes a user interface. The user interface is a set of classes hav¬ ing to do with communication to a person. These class¬ es are as follows. Keypad class is used to react to someone pressing keys on the master controller's keypad. The LED class controls the state of the six LEDs on the master controller. The LCD class controls the sixteen-digit LCD on the master controller. The Sonalert class controls the sound of the audible Solalert output. The user class provides a logical link between all the elements of the user interface. The system operates by sending messages between the objects to communicate the state of the system. An example would be when the Diagnostic class (which de- tects local trouble conditions) sends the message "AC Power" to the LED class. This indicates to the LED class that the corresponding AC power LED on the master controller should be lit.

Figure 8 is a picture describing the rela- tionship between the metaclass, the set of classes, and the instances of the classes which may or may not exist in one possible configuration. B. Master Controller

Having described the system generally, a more detailed description is now given of the structure and operation of the master controller. Figures 4A and 4B taken together provide a circuit diagram of the digital circuitry for the operation of the master controller. The central component of the system is the microproces- sor unit (MPU) 23, which interfaces with the master controller memory, peripherals and other subassemblies as will be indicated below. MPU 23 communicates to other parts of the system along 15-byte address bus 61 and 8-byte data bus 62. The passage of data to or from data bus 62 is controlled by transceiver 63. When en¬ abled, the transceiver is in either a transmit mode, along the MPU to transmit data on the bus, or a receive mode, allowing the MPU to receive data from the bus. The mode of transceiver 63 is controlled by gate 64, which responds to an enable signal from the enable port

66 of the MPU and a read/write signal from the read/write port 67 of the MPU. In the present imple¬ mentation of the master controller the transceiver 63 is provided by a 74HC245 transceiver chip.

The system memory comprises random access memory (RAM) units 68 and 69 together providing 16K bytes of memory, and read-only memory (ROM) units 71 and 72 together providing 16K bytes of read-only memo¬ ry. In the present implementation the ROMs are provid¬ ed^"by 27C64EPROM chips and the RAMs are provided by 6264LP chips. Reading and writing into the RAMs and reading of the ROMs are enabled by the read/write port

67 of the MPU. The data on bus 62 are fed to latch 73, which provides the lower 8 bytes of address along ad¬ dress line 61. The upper seven address bytes are provided from address ports 74 on the MPU. Latch 73 is enable from the address select port 76 on the MPU.

Selection of a particular RAM or ROM is controlled by address select switches 77, which also select other subassemblies or functions being addressed by the MPU. Address select switches 77 may be provided by 74HC138 chips. The real time clock 78 controls all real time functions for the system. For example, the real time clock enables an operator or the MPU itself to keep track of the times at which alarm events occur or at which a false condition arises in the MPU. The real time clock may be provided by a MC146818A chip avail¬ able from Motorola Corporation. This chip includes a watchdog timer subroutine, which provides a handy safe¬ ty measure. The watchdog subroutine continually counts down, for example, from 100. When it gets to, say, 10, the MPU resets the chip to 100. If the MPU should lock up, so that it is incapable of resetting the subroutine at 10, the watchdog timer times out and provides a sig¬ nal for resetting the microprocessor.

Standby block 79 protects the system from unacceptable reductions in power. Lock 79 is respon¬ sive to the system nominal 12-volt supply. If the sys- tern voltage drops below 7 volts, the standby output communicates a signal to RAMs 68 and 69, real time clock 78, and reset circuit 81. Whenever a standby condition arises, the circuit 81 resets the MPU after the power comes back up. Reset circuit 81 resets not only the MPU itself, it also activates the real time clock reset 82. This circuit assures that the real time clock is not reset before the MPU. Real time clock reset 82 provides a delay so that the clock will reset more than three microseconds after the MPU. A limited amount of programming capability is provided through key pad 83 for adapting the master controller memory to the particular configuration of the system being installed or for modifying the config¬ uration at a later time. Depression of a key on a key pad causes the MPU to fire a tone timer or sonalert to let the user know that the key depression has been re¬ ceived. Key pad 83 communicates with MPU 23 through a conventional key pad encoder 84, which may be provided by a 74C922 chip. To aid in programming the master controller and to provide visual display of data to the user, the master controller includes a 1 by 14 liquid crystal display (LCD) 86. LCD 86 is coupled to data bus 62 for display of whatever data called for at the key pad 83. The master controller also includes a plural¬ ity of LEDs for alerting the user to various alarm con¬ ditions. LEDs 87 may also be used in conjunction with a conventional flasher unit 88 for providing a stronger warning or alert signal.

The function I/O 89 controls the LEDs and other subassemblies in the master controller and at the slave controllers. In particular function I/O 89 con¬ trols the power for the transmitting means 16, a trou¬ ble scan unit 91 for sensing trouble in burglar and fire alarm bell units, a battery charger for charging backup batteries, and the function I/O 89 also controls the ringing of an alarm bell at a remote location in response to an alarm condition. Function I/O 89 is provided by conventional 74HC374 bus interface chip. Trouble scan unit 91 is used for verifying the integrity of alarm circuits or other circuits form¬ ing part of the system. Trouble scan unit 91 receives a plurality of lines 92, for example, from trouble sense units 93 used for sensing "trouble," that is, a malfunctioning of an alarm bell circuit at a remote location. The lines 92 are in either a high or low state depending upon the condition of the trouble sense unit with which they communicate. Clock 91 notifies the MPU of a trouble condition. For example, if a com¬ parator circuit on a fire bell at a remote location should trigger, this will in turn trigger the appropri¬ ate sense input, which will then be communicated to the MPU, which will determine the trouble condition accord¬ ing to which function I/O line was triggered. The MPU will then react accordingly. Reference is now made to Figures 5A, B, C and

D, which taken together show an implementation of the analog circuitry for the master controller. Power con¬ trol for this circuit comes from the function I/O block 89 in Figure 4B. Control line 94 of Figure 4 corre- sponds to control line 96 of Figure 5. Power control line 96 feeds power driver 97. The signal along this line will normally be high when the system is in a standby mode. The high signal is fed to transistor 98, which serves as a pull up transistor. When power driv¬ er 97 is turned on, a low is sent to transistor 98. This in turn activates both charge pump circuit 99 and transistor 101. Charge pump circuit 99 corresponds to DC/DC converter 27 of Figure 2. It applies 24 volts to transistor 101 and to FET 102. FET 102 and diode string 103 comprise the voltage drop circuit 21 of Figure 2 and FET 104 comprises the pulse modulator switch 22 of Figure 2.

The receiving means of Figure 2 will now be described in more detail with reference to Figures 5A and C. Toroidal transformer 106 has roughly 10 turns on the primary side and 40 turns on the secondary side for a ratio of 1:4. Resistors 107 and 108 provide a half-voltage bias reference for this transformer. Di¬ odes 109 provide a limiter circuit for an essentially square wave that is picked off of the toroidal coil. The diodes 109 limit the peak-to-peak signal to plus or minus 0.6 volts. The signal along line 111 is then applied to integrating and filtering circuitry 112. The first stage 113 provides a passive integrater cir¬ cuit. Capacitor 114 and choke 116 following the pas¬ sive integrater prevents too big a signal from entering the second stage, which is an active integrater having characteristics for filtering out high frequencies. The signal coming from the integrating and filtering circuitry 112 is in the form of a triangle wave, which is acceptable to the subsequent phase lock loop. The phase lock loop may be provided by a XR211 chip. It is tuned to 17.5 KHz with a plus or minus 3 KHz lock-in range. The output from the phase lock loop along line 118 is a demodulated data signal, which is applied to the MPU. The implementation of the slave controllers is much simpler than that of the master controller. Figures 6A and 6B taken together show a suitable imple¬ mentation of the slave controller electronics. C. OBJECT MANAGEMENT ARCHITECTURE

Proper management of the system memory, in particular, the RAM spare keeping track of the many numbers of events which can occur in a configuration of any size, is necessary to achieve the advantages of the invention. To gain an understanding of the memory man¬ agement, it is instructive to consider the sequence of events that could take place when the system is first powered up.

At the outset the system's classes are stored in ROM, as the user is not given the capacity to add or delete classes. First, the classes are copied from their permanent storage in ROM into the object memory space in RAM. See Figure 9, which shows the classes which may be stored in ROM for a typical configuration. After these classes are moved into the object memory space (in RAM), they are initialized with specific da¬ ta. Initialization takes place by sending messages to these classes with arguments describing the initial state of the system.

To determine which object is to receive a particular message, a special notation is used referred to as a "goop." A goop is two bytes long, the high byte being designated "classID" and the low byte being designated the "instancelD." The classID of a goop indicates the class of an object, and the instancelD indicates to which instance of a class reference is being made. ClassID 0 is predefined as referring to the Metaclass, that is, the class describing all the other classes. There is only one Metaclass. An in¬ stance of the Metaclass is a class. For example, a goop consisting of classID 6 and instance ID 3 refers to the third instance of the sixth class. A goop con- sisting of classID 0 and instance ID 6 refers to the sixth instance of the Metaclass, which is the same as the sixth class. Now being able to specify the intended re¬ ceiver object of a particular message using the goop format, that object must be located in memory, and its associated message table must be examined to determine if the object can receive the message. Objects are located in memory by a routine called "findGoop." In the case of a message being sent to an instance of the Metaclass, the location of the class in memory is de- termined by using the classID times 2 as an index into the class object table. The word at this location in the class object table points directly to the receiver class in memory.

When the receiver of a message is an instance of a class, the findGoop routine first finds the in¬ stance's class in memory using the procedure described above. Then it searches through the class' data fields to find the particular instance. In the class' data field the existing instancelDs are associated in their corresponding memory addresses with the object memory space.

When a message is sent, it passes through a routine in the object memory engine referred to as "dolt." This routine is given a message selector, and an object to receive the message. The dolt routine calls upon findGoop, which locates the absolute memory location of the receiver object. Upon locating the object, the routine can determine from the object's structure which messages that object can understand. If it finds that message listed as one the receiver can understand, then it will pass control of the processor to the method associated with that message. The method then takes over and performs the requested operation. At the end of the method, control of the processor is passed to another routine called "unDoIt," which per¬ forms general housekeeping activities and returns to the original sender of the message. In order to keep track of the sequence of message sends as well as passing data between objects, two stacks have been implemented in the processing unit: a machine stack and an argument stack. The ma¬ chine stack is used for storing addresses of routines, context information such as the various registers of the processor, when the message was sent, and the goop of the receiver of the message. When a message is sent, the processor context return address and the goop. of the receiver of the message are all stored on the machine stack. The argument stack is used to communi¬ cate data. For example, first object desirous to send a second to a second object giving the second object some data, would push that data on the argument stack and call the dolt routine to pass control of the pro¬ cessor to one of the second object's methods. The sec¬ ond object upon having control directed to the appro¬ priate method would pull the necessary data from the argument stack.

Two mechanisms exist for specifying what is to take place when the receiver of a message does not understand or cannot accept the message that is being sent. In the first case, the dolt routine looks at the receiver's table of understood messages for a special entry called "super." If "super" exists in this table it provides a reference to an additional message table where the search for the original message can be con¬ tinued. This process continues until dolt has exhaust- ed the superclass chain.

Once control of the processor has been trans¬ ferred to a method of a particular object, the method performs its function and sometimes needs to leave an answer for the sender of the original message. As data are placed on the argument stack in sending a message, so are answers to a message placed on the argument stack. There is yet another process for causing an object to perform one of its methods in addition to sending that object a message. This process is called invocation. Every object in the system has one byte that determines that object's current method; this is part of the minimum data required to define an object. When an object is invoked, the .dolt routine determines from the current method variable which method in the vocabulary of methods available to the object will be executed. This process, in effect, gives the object self-control over which method it will execute. The object need not be told which to execute; it decides itself. When an object is created, the current method is initialized to zero, meaning the first method in the object's method table would be executed when that ob¬ ject is invoked. After the object has been invoked, and the corresponding method has been performed, the object usually decides whether to change the current method variable or leave it where it is. This mecha¬ nism is often used to handle dynamic functions, such as an object that needs to exist for a short while, but not for an extended duration. In that situation, the object will be created, then invoked, and when that object decides that it has done the work it needs to, it will allow the current method variable to increment and spill into another of its methods specifying that the object should purge itself.

In a non-class object the data fields are used for whatever storage is necessary to that object. For example, a fireZone object needs to know how long to ring a fire bell when a fire condition is detected. However, in a class object the data fields are used for a different purpose. They are totally dedicated to keeping track of the instances of a class. In addition to the minimum data that all objects must contain, a class contains an additional set of data in the follow¬ ing format: a byte indicating how many instances of that class currently exist in the system; a word in¬ dicating how large an instance of the class will be when it is created; and a word indicating the table of messages that the new instance of the class will under¬ stand.

For each instance of the class that exists, three bytes of extra storage are required in the class object. The first of these three bytes is the instancelD. The subsequent word is an absolute pointer to that instance in the Object memory space. As the number of instances in a class grow and shrink due to creation and purging of instances, so does the size of the class. When the number of instances of a class crosses a certain threshold (in the present implementa¬ tion the threshold is five), the class will expand it¬ self so that it can accommodate five more instances of that class. When instances are purged, the class will shrink in a similar fashion. Most classes respond to the message "new" by creating an instance of that class. As described be¬ fore, all classes contain data determining the length of its instances and the set of messages that its in¬ stances will be able to respond to. This is handled by the object memory routine called "new." As indicated before the amount of memory a new instance will require is stored in the class. The "new" routine will then ask the "allocate" routine to allocate that many bytes of memory. The "allocate" routine keeps track of free memory available using a pointer referred to as firstFreePtr. All of the memory space between firstFreePtr and the end of the memory space is con¬ sidered free. Assuming there is sufficient memory to accommodate the new instance, the "allocate" routine increments firstFreePtr by the size of the allocation request and returns control to the "new" routine. In addition to allocating the required memory, the allo¬ cate routine also answers a pointer to the beginning of a space large enough to accommodate the allocate re¬ quest.

When the "new" routine is called, it is told which class for which a new instance is desired and the instancelD of the new instance. These two bytes of data are stored in the first two bytes of the new memo¬ ry space just allocated. This becomes the new in¬ stance's header and is in goop format. The next two bytes determine the length of that instance. The cur¬ rent method of the new instance is always initialized to zero. The number of messages the instance can un¬ derstand is copied from the class' data field as is the pointer to the table of messages that this new instance understands.

At this point a new object has been created. The data fields of this new instance, if any, have not been initialized. Although this object now exists, a pointer to it must be generated so it can be referred - to by its header.

To generate a reference to this new instance, the number of "slots" capable of storing references to instances in the class is compared to a byte in the class indicating how many instances actually exist. If the number of slots that can hold references exceeds the number of existing instances of that class, then all we need to do is fill in one such free slot with a pointer to the new instance. This pointer consists of the instancelD and an absolute memory pointer to that object within the memory space given to the "new" rou¬ tine by the "allocate" routine.

If there is no data slot available to store this reference, then a new data slot must be created. This involves making the class object larger. Typical- ly, to grow a class it must be moved a different place in the object memory. This requires another call to the "allocate" routine (this time for the number of bytes required to store the new, larger class). After the space for the new class has been allocated, the old class is copied directly to the new space for the new class, except for the data length of the new class ob- ject, which is increased according to the number of new additional slots allocated in that class to store ref¬ erences to new instances.

Now that the new class is capable of storing the new reference to the new instance, the old class must be discarded. This is done by changing the old class' header to nonObjectPtr. NonObjectPtr comprises 2 bytes of zeros and indicates an object which no long¬ er exists. Changing an object's header to nonObjectPtr indicates to the object memory that this memory is now available and can be reclaimed when necessary. Now, we can store the reference to the new instance in the new slot of the new class.

All that remains to be done is to initialize the data fields of this instance if necessary. This is not. handled within the "new" routine and is a function of the particular method used that calls the "new" rou¬ tine. The class originally receiving the new message must decide whether any data in the new instance needs to be initialized. If so, the data to initialize this new instance is usually provided as arguments to the method corresponding to the new message. In other words, the data for this new instance is determined by some other part of the system.

When an object receives the message "purge," it executes the object memory routine of the same name. The first thing that happens in this routine is that the header of the object to be purged is changed to nonObjectPtr in the object memory space. Next, the reference to this instance must be removed from its class. The byte in the class indicating the number of actual instances is decremented by one, and the refer¬ ence in the class which is now obsolete is removed. This may involve scooting the list of existing instances so that there is always one contiguous chunk of references to existing instances in the class. The purge processing that follows is similar to that in the new routine. If the number of data fields allocated to hold references to instances of that class drops below a certain threshold then the class is shrunk.

As mentioned earlier, when an object is cre¬ ated, the object is always placed at the location in- dicated by firstFreePtr. The allocate routine does not know about purged objects. So, as objects are created and purged, the firstFreePtr keeps growing higher into the memory space until eventually it will hit the end of the memory space. In this case the request to allo- cate memory cannot be honored immediately, and more processing needs to take place. See Figure 10.

The allocate routine then calls an object memory routine called "compact." . The compact routine begins a search from the beginning of object memory to the end for the first nonObject. The compactor remem-. bers the address in memory of the first nonObject it finds and then continues to search through the object memory for the next object, skipping over other nonOb- jects which may exist between the first nonObject and the next object. If several nonObjects exist contigu¬ ously in the memory space, they are seen by the "com¬ pact" routine as one large nonObject. The next object in memory can readily be found because the nonObject's data length bytes are still accurate. The next object is then copied on top of the temporarily recorded non- Object. The last byte of this object's new location in the memory space then becomes the search point for the next nonObject in memory space, and the procedure is repeated indefinitely until it has run out of all ob- jects. All references to all objects are continually maintained and are during the "compact process.

FirstFreePtr then assumes the address of the first byte after the last byte in the last object. The memory is now said to be defragmented. One large block of objects in present between the beginning of memory and firstFreePtr, and one large block of free memory is present between firstFreePtr and the end of memory.

There is a certain set of messages that every object in the system understands. These messages do not have to be included as part of the object message table. These are called the system primitive or common messages. An example of such a common message is

"purge;" another such message is "at". When an object receives the "at" message, it expects one argument in¬ dicating which piece of its data should be fetched. It then returns this variable on the argument stack as the answer to the message.

Special processing takes place when a message is sent to an instance of a class which does not exist. The message selector and the instance that was to re¬ ceive the message are pushed on top of the argument stack. Then a special message called "indirect" is sent to the class of the instance where the message was originally sent. If the class understands this mes¬ sage, it typically responds with default conditions associated with the instance that does not exist. With this mechanism certain default conditions can be imple¬ mented without requiring that an object be created to describe the situation.

Another primitive function of the object mem¬ ory is a routine called "FEG, " which stands for "do For Each goop." FEG is a special mechanism that allows a message to be sent for each instance of a class in the system. One application of FEG is the- "invokeAll" mes¬ sage. When invokeAll is sent to a class, it uses FEG to individually invoke each instance of that class. Another application of FEG is the message

"purgeAll." When a class receives this messages, it uses FEG to purge each instance of that class. FEG operates by starting with the first instancelD (which is zero). For each instancelD it checks to see if an instance in the class exists and if so, sends the given message. Before the message is sent, the data neces- sary to maintain the state of FEG is recorded on the stack so that FEG can be re-entrant.

Having described the structures needed for management of the object memory, an example is now giv¬ en of some of the object interactions that take place in the system. The first introduction to occur is typ¬ ically the invoking of the Hardware class. This in turn will result in a FEG call to invoke each instance individually. Invoking a particular hardware instance results in executing some system primitive routines that interrogate the object's associated slave control¬ ler on the loop for its status. If there is a system trouble condition (no response to a request for status at a remote device), then an instance of SysTrouble is created, and the system goes on to the next instance of Hardware to scan it. However, if the status is suc¬ cessfully acquired, and the acquired status indicates an abnormal condition at the remote device, than an instance of Trip is created indicating the status caus¬ ing the trip. If the status shows as normal, no spe- cial processing takes place and the next instance of Hardware is invoked.

After all instances of Hardware have been invoked, the system typically invokes the FireZone class, which in turn invokes each fireZone instance. The fireZone sends a message to its associated hardware instance asking it for its status. If the status acquired from the hardware instance is abnormal, then the fireZone creates a new instance of BOC (Bell Output Condition). Otherwise, that fireZone instance has nothing unusual to report, and the next instance of fireZone is invoked.

After fireZone has been invoked, the system invokes the BOC class. This does not initially result in individually invoking each element of the class. The class itself determines if any instances exist. If there is an instance, the instance activates the fire bell through the master controller function I/O block. Then each instance of BOC is invoked using the invokeAll message. When an instance of BOC is invoked, it compares the current time of day against the amount of time that BOC should exist and, if the BOC is due to expire, it purges itself. On the next scan of the sys¬ tem, the BOC class will see there are no instances of BOC and will turn off the firebell at the master con¬ troller.

Next, the Trip class is invoked, which re- suits in individually invoking each trip instance.

Individual trip instances are used to affect a status LED at the master controller and to provide information for the user interface. Individual trips then incre¬ ment their own current method pointer so that on the next time through the system, unless the trip is recre¬ ated, it will purge itself.

A similar processing occurs for the SysTrouble class, which provides information to the user interface and to the system trouble LED. While the foregoing provides a full and com¬ plete description of an illustrative embodiment of the present invention, various modifications, alternate constructions and equivalents may be employed without departing from the true spirit and scope of the in- vention. For example, although the present invention arose in the context of fire and burglar alarm systems, it will now be appreciated by those skilled in the art, given the teachings of the present specification, that the principles of the invention may be applied to other supervisory systems as well. Thus, the above descrip¬ tion and illustrations are not to be construed as lim¬ iting the scope of the invention, which is defined by the appended claims.

Claims

WHAT IS CLAIMED IS:

1. A system for supervising a plurality of remote devices comprising: a plurality of slave controllers, each said controller being operatively associated with at least one said device; a master controller operatively associated with a master processor including a read/write memory, said master controller being in two-way communication with said slave controllers, said master processor defining: a hardware object for each said slave controller; at least one reaction object for each said hardware object; and a system trouble class responsive to said hardware objects for creating system trouble objects indicating a failure of communications between said master and slave controllers; said processor allocating a portion of said memory to each said defined and created object; and means responsive to said reaction objects for annunciating changes of status of said devices and re¬ sponsive to said system trouble objects for annunciating changes of status of the system, said means providing a signal indicative of said changes of status.