- Email: [email protected]
A distributed energy management and security system
Journal of Microcomputer Applications (1987) 10, 29-39
A distributed system
energy management
and security
H. T. Mouftah, R. Kun and D. Hoffer Department of Electrical Engineering, Queen’s University, Kingston, Ontario, Canada, K7L 3N6 A multi-microprocessor-based energy management and security system is presented. A number of I-bit microprocessors (MC 14500) controlling the energy consumption and security system in different locations are connected in a star configuration to an 8-bit general purpose microprocessor (MC 6800). The system proved to be flexible, reliable and cost effective. The system hardware and software is analysed and described. An example of a system interface for an air flow heating system is presented.
1.
Introduction
Today’s dwindling and expensive energy resources make it necessary to maximize the efficiency of energy use. With the advent of microprocessors the possibility of a flexible and intelligent energy and security management system becomes feasible. Several energy management and security systems are already available on the market. These systems are expensive, have expensive interfaces to the outside world and do not have the capability to interface to an outside smart instrument. The primary objective of this study is to design a low cost security and energy management system. The low cost of microprocessor hardware led to the choice of a distributed multi-microprocessor system. The technique of distributed processing is often implemented by configuring processors in some sort of hierarchical arrangement. In our case, a star configuration, a fairly standard type of grouping was chosen (Figure 1). This configuration consists of a central processor that controls a number of remote processors. These in turn control small sub-systems of their own. In this particular system, the function of each remote processor is to maintain the status quo of its own sub-system of actuators and sensors, and to inform the central processor of the status of the actuators based on instructions received from the central processor. The central processor is implemented with a Motorola MC 6800 microprocessor while each remote is designed around the Motorola l-bit MC 14500 microprocessor known as the Industrial Control Unit (ICU). A number of inexpensive real world interfaces have been constructed (Chan, Hoffer & Kormos, 1982) however only one example of energy management system is presented.
2.
Interprocessor communication
The l-bit microcomputer is not easy to adapt to a UART (universal asynchronous receiver/transmitter) and so interprocessor communication has been implemented in software by both the central and remote processors. Each bit of data is transmitted with its own start bit. This would be very inefficient for long transmissions, but since each 29 0745-7138/87/010029 + I 1 $03.00/O
0 1987 Academic Press Inc. (London) Limited
30
H. T. Mouftah et al. Device 1
Remote processor n
I’
,--
--__ ___---
-ii
Central processor
Device 1 De2c
( De?
2f
Remote proc2essor processor 1
Figure 1.
Distributed
processing
system-star
configuration
central-remote transaction requires an exchange of about 50 bits of information, the method is found to be acceptable. A 5 ms bit length is chosen to test the software and hardware, but this may be reduced somewhat within the constraints of the modem. With a 5 ms bit length an errorless transaction takes approximately 0.6 s. The communication sequence is designed so that the master processor is responsible for error detection. Error correction is achieved by retransmission. The communication sequence is as follows: (1) The transmit line from the master is normally high. (2) The master pulls the line low for four bit times. number and waits for an echo. (31 The master sends a remote identification The remote recognizes its code and echoes the code in acknowledgement. (4) The master compares the received code and the transmitted code. (5) The remote, without prompt, sends the state of its sensors. Each data bit is sent (6) twice in succession. After the master has received all the data, successive bits are compared to check for errors. The double bits are then reduced to a single bit. by the master and echoed by the (71 The required device status is then transmitted remote. The echoed data is then compared with the transmitted data for errors. If errors are found anywhere during the transaction, the sequence is repeated. If (8) no errors are detected, the next remote processor is then serviced.
3.
Central
processor
software
The description of this software will be broken down into three areas: data base, data base access and remote processor servicing. Before these areas are described in detail, an overview of the software will be presented.
Distributed energy management
31
The data base is the common link between the two main sections of software. The remote servicing software uses information in the data base while the data base access software allows the operator to change this information. The central processor continuously services the remote processors unless the operator wishes to make a change to the data base. Upon entry of the required log on code at the terminal, the central processor, on recognition of the valid code, halts service to the remotes and turns its attention to the operator. After the operator has made the desired changes and has logged off, the central processor resumes service to the remotes using the updated information stored in the data base. This flow of events is illustrated in Figure 2. 3.1
Data base
The data base stores the following information about each remote processor: the state of the remote (is it in service or not?), the number of devices it controls, and the on-off times for each device. It is designed to be flexible enough to add many remote processor and device records at any time, and to be able to specify many daily operating periods per device. Stored in the first location of each remote file is the ASCII character ‘ACK’ or ‘NAK’. This character lets the accessing software know whether or not the remote is in service. The rest of the file is occupied by device records. A device record consists of: one byte for the device identification number; two bytes for an ON time; two bytes for an OFF time; a total of five bytes per record. The number of device records per remote has been arbitrarily set to 30. Since any number of records can be allocated to a particular device, that device can have more then one daily operating period.
f
,
Get record
-
-
t
Go to begin of data base A
Service operator
I
-
Figure 2.
System software
overview.
32
H. T. Mouftah et al.
After completing a successful log-on, the user is presented with a list of data base manipulation commands which, for brevity, are not described in this paper. 3.2
Remote processor servicing
The remote servicing software can be subdivided into two groups: the ‘communication software’ and the ‘decision making software’. The ‘communication software’ uses two groups of routines, the transmit group and the receive group. These represent the core routines used to implement the protocol. All other routines use these routines to perform the required functions. The transmit and receive routines are responsible for sending and receiving all data in the form required by the protocol. All incoming or outgoing data is temporarily stored in a four byte data buffer called DATA. In both the transmit and receive routines the data is handled in eight bit blocks, in order to make the data processing more ‘byte-oriented’ and hence simpler. The ‘decision-making’ software involves obtaining the time from the real time clock and then using the data base to decide which devices connected to which remotes should be on at a given time. Since more than one ON-OFF time pair may be specified for a given device, all records must be examined before a decision can be made as to whether the device should be ON or OFF. Each record is checked in succession until one dictates that the device should on ON. Once this is found the appropriate bit in the data word is set to 1 (one) and then the next device is processed. If none of the records in the file specifies a device to be ON then it is assumed to be OFF and the bit is set to 0 (zero). When comparing a set of ON-OFF times with the real time to determine whether the device is on or off, there are two possible cases to consider. The first case is when the ON time is less than the OFF time, in other words a device that is on during the day. For example, turn on the lights at 08:OOhours and turn them off at 17:OO(5:OOp.m.). For the device to be set to ON, the real time must be greater than the ON time AND less than the OFF time. The second case occurs when the ON time is less than the OFF time, in other words a device that is left on over midnight. For example, turr Y the burglar alarm at 17:00 and turn it off at 08:OO.In this case the real time must be less than the OFF time OR greater than the ON time in order for the device to be set to ON. Since these two cases must be handled separately, a decision is made as to which case exists. The flow chart showing the sequence of events for the decision-making process is shown in Figures 3 and 4. The operator log on servicing routine is also included in the decision-making software. When the system is initialized the MC 6850 asynchronous communication interface adapter (ACIA) is set up to interrupt the processor each time a key is depressed on the central processor terminal. The interrupt service routine stores the last four characters entered in a log on buffer. After each remote has been serviced this log on buffer is compared with the proper log on code to determine whether or not the operator desires access to the data base. If the log on is valid then control is transferred to the data base access software, otherwise input from the terminal is ignored and the next remote is serviced. If a successful log on occurs, then the central processor will stop updating the remote processors and begin executing the software that allows the user to modify the system. Since remote processor updating will not resume until the operator has logged off, these system modifications should be made at times when the effects of delaying updates to the remote processors will be small.
Energy management and security system
33
Find another record for device
Figure 3.
4.
Real-time
Control word assembly.
clock
The real-time clock is built around a National Semiconductor clock chip (MM 53 11) driven by a crystal-based 60 Hz reference. The multiplexed BCD output from this chip is fed to four BCD-to-seven-segment decoder/drivers and to four latches. Each seven segment decoder drives a separate LED display when enabled by a demultiplex strobe from the clock. Each digit of the BCD data is also loaded into a separate latch by the corresponding clock strobe. The latches are accessible to the MC 6821 peripheral interface adapter (PIA) through tri-state buffers and could be read individually using a decoder to select only one of the four gates at a time. A byte-oriented representation of the real-time is then created in software in the central processor. During a real-time read the latches are disabled by a control line from the PIA so that the time does not change while a read is in progress.
34
H. T. Mouftah ef al.
Figure 4.
Time comparing
algorithm.
The real-time clock can also be externally adjusted from the central processor’s terminal keyboard by using an opto-isolator, a switch to enable the input for the fast-set function on the clock chip.
5.
Remote processor implementation
The remote processor controls various peripheral devices located throughout a building. In our particular case the remote processor is based on the Motorola MC 14500B CMOS series IC. It is a one data bit wide processing unit. Due to its architecture and instruction set it is a decision-oriented machine. Unlike other microprocessing units today, it contains no program counter, interrupt vector capability, nor stack counter. These components are implemented externally to the MC 14500. However, it has its own built in oscillator, four flag lines capable of putting out a pulse via software and a single bit wide accumulator. There are four flag lines going into the instruction register. The instruction register then, is a four bit wide device producing an instruction set for the MC 14500 containing 16 different instructions. Figure 5 is a block diagram of a typical system operation. The design configuration had the system flow changing as the clock goes from high to low and vice versa. When
Energy management and security system
35
instructions
Figure 5.
General block diagram of the remote processor.
the clock is high, the memory supplies the MC 14500’s instruction register with the appropriate 4 bit wide instruction. On the lower part of the clock cycle, the MC 14500 ignores any data presented to the pins of the instruction register. Instead, the memory supplies an address to the pins of an input demultiplexer or an output multiplexer/latch. Further circuitry is used to ensure the data line is an input or output depending upon the relevant MC 14500 instruction. Through software, the remote processor is intended to incorporate a fair degree of control. The following is an example of this control ability. The remote processor can keep the temperature in a building fixed at 20°C during the day. Upon receiving instructions from the central computer the remote can change the temperature to 15°C and keep it fixed at this level. Thus the remote operates as a separate entity and will change its control function at the central computer’s request. The ICU has what is basically two modes of operation. The first mode is the independent mode. In this case, the TCU makes decisions based solely upon the information it receives from its sensors. Action is taken by the ICU independent of the MC 6800-based central processor. The second mode is what is referred to as the dependent mode. In this case, the ICU acts as a relay between the MC 6800 and the output attached to the ICU. For example, the lighting system is dependent upon the MC 6800 for control. While the ICU is the instrument which turns the lights on or off, the central processor-because it has the real time clock-is the device which determines when the lights should be turned on or off. The software for the independent mode is fairly straightforward to implement. This is due to not having to write any software to receive and take action on any messages from the central processor. Figure 6 is a flow diagram of the ICU in the independent mode. Due to the hardware design of the ICU, execution of the NOPF (no operation) causes system execution to jump back to the origin (location 0000). The program flow is a simple top to bottom loop. The dependent mode of operation requires a great deal more software than the
36
H. T. Mouftah, R. Kun and D. Hoffer
t Check device no. 1
Take Corrective
set off alarm
Figure 6.
The independent mode of operation of the remote processor.
independent mode. This is due, in part, to the requirements involved in communicating with the central processor. Figure 7 is a flow diagram of the dependent mode of operation. An important aspect of the program for the dependent mode is the. software block used to receive and decode any incoming data. The ICU is set up so that upon execution of a special instruction, a flip flop pulls the reset pin high and holds it high until a zero bit (a start bit) comes in. Each time data from the central processor has to be received, this block of software is executed.
Energy management and security system
37
Send back stata of devices
Receive, echo, execute command
Figure 7.
6.
Energy
The dependent
management
mode of operation
for the remote processor.
example
To illustrate the energy savings that this system can provide consider the following system. Most industrial or commercial building complexes are billed for their peak electrical energy consumed during the day. Thus, if all the buildings’ heating/cooling systems were duty cycled in such a manner as to reduce the peak energy consumed, then considerable savings would be realized.
38
H. T. Mouftah et al.
1
Cold deck
I -
Fresh air
/
y C”,” water
Figure 8.
Return fan
al .L$ G
Hot deck
f-\
Supply fan )
11 -
II”1
water
The air flow heating
system example.
To understand the duty cycling with respect to an airflow system, the simplified representation of an air flow system (Figure 8) should be examined. In a typical building, the supply fan and return fan will operate continuously during the day while analogue controllers adjust the heat via the pneumatically controlled dampers and the circulation pumps. Having the pumps and fans operating throughout the day is expensive. By evaluating the thermodynamics of the building and assessing the outside environmental effects, an efficient air flow strategy can be determined. For example, say the outside temperature is 5°C then to achieve a desired inside temperature of 20°C it may be necessary to run the return fan for 20 minutes every hour. In order to keep the air fresh, it may be necessary to run the supply fan for 10 minutes every hour. Thus this illustrative system uses one half hour of fan time as opposed to two hours of fan time in the previous situation with both fans running continuously.
7.
Conclusions
A multi-microprocessor-based energy management and security system has been presented. Although the implementation of the system could have been easier if an 8-bit single chip microcomputer was used in the design of the remote processor, the system proved to be flexible, reliable and cost effective. The system can have direct applications in data logging systems. In large applications there could be remote processor areas that require more frequent attention than others. This could be accomplished by assigning priorities to the remotes, thereby ensuring that all areas are monitored only as frequently as required.
Energy management and security system
39
Acknowledgements The authors would like to thank Alan Chan, Alan Smith and Terry Kitzul for their help in develop;ing the software. This work was carried out at Queen’s University and was partially supported by the Natural Science and Engineering Research Council of Canada and Queen’s University Research Award.
References Chan, A., Hoffer, D. & Kormos, T. 1982. Energy Management and Security Systems: An M6800 Microprocessing Unit Controlling an Array of l-Bit Microprocessors, Project Report, Department of Electrical Engineering, Queen’s University at Kingston, April. H. T. Mouftah received the BSc degree in electrical engineering, and the MSc degree in computer science from the University of Alexandria, Alexandria, Egypt, in 1969 and 1972 respectively; and the PhD degree in electrical engineering from Lava1 University, Quebec, Canada, in 1975. After a year of postdoctoral fellow at the University of Toronto, he was a senior digital systems engineer and then chief engineer at Adaptive Microelectronics Ltd., Thornhill, Ontario from 1976 to 1977. From 1977 to 1979 he worked with the Data System Planning Department at Bell-Northern Research, Ottawa, Canada. In 1979 he joined the Department of Electrical Engineering, Queen’s University at Kingston, Ontario, Canada, where he is presently an associate professor. He has consulted for government and industry and holds a number of patents and published a large number of technical articles in the areas of computer communications, digital systems and multiple-valued logic. Randy Km received his BSc in Electrical Engineering from Queen’s University in Canada in I98 1 where part of the research described in this paper was performed as part of the undergraduate program. Mr Kun subsequently joined Bell-Northern Research Ltd. working on digital switching products and is currently completing a Masters degree in Systems Engineering at Carleton University in Canada. David Ho&r received his BSc in electrical engineering from Queen’s University at Kingston, Ontario, Canada in 1981, after which he joined Norpak Corp. as a design engineer. In 1983 he joined Telesat Canada. There his responsibilities include the monitoring of spacecraft integration and test at the Kennedy Space Center prior to the shuttle launch of Telesat’s communication satellites. His other duties include the design and test of Telesat’s Getaway Special Experiments (small self-contained scientific packages that are flown on the shuttle).
A distributed system
energy management
and security
H. T. Mouftah, R. Kun and D. Hoffer Department of Electrical Engineering, Queen’s University, Kingston, Ontario, Canada, K7L 3N6 A multi-microprocessor-based energy management and security system is presented. A number of I-bit microprocessors (MC 14500) controlling the energy consumption and security system in different locations are connected in a star configuration to an 8-bit general purpose microprocessor (MC 6800). The system proved to be flexible, reliable and cost effective. The system hardware and software is analysed and described. An example of a system interface for an air flow heating system is presented.
1.
Introduction
Today’s dwindling and expensive energy resources make it necessary to maximize the efficiency of energy use. With the advent of microprocessors the possibility of a flexible and intelligent energy and security management system becomes feasible. Several energy management and security systems are already available on the market. These systems are expensive, have expensive interfaces to the outside world and do not have the capability to interface to an outside smart instrument. The primary objective of this study is to design a low cost security and energy management system. The low cost of microprocessor hardware led to the choice of a distributed multi-microprocessor system. The technique of distributed processing is often implemented by configuring processors in some sort of hierarchical arrangement. In our case, a star configuration, a fairly standard type of grouping was chosen (Figure 1). This configuration consists of a central processor that controls a number of remote processors. These in turn control small sub-systems of their own. In this particular system, the function of each remote processor is to maintain the status quo of its own sub-system of actuators and sensors, and to inform the central processor of the status of the actuators based on instructions received from the central processor. The central processor is implemented with a Motorola MC 6800 microprocessor while each remote is designed around the Motorola l-bit MC 14500 microprocessor known as the Industrial Control Unit (ICU). A number of inexpensive real world interfaces have been constructed (Chan, Hoffer & Kormos, 1982) however only one example of energy management system is presented.
2.
Interprocessor communication
The l-bit microcomputer is not easy to adapt to a UART (universal asynchronous receiver/transmitter) and so interprocessor communication has been implemented in software by both the central and remote processors. Each bit of data is transmitted with its own start bit. This would be very inefficient for long transmissions, but since each 29 0745-7138/87/010029 + I 1 $03.00/O
0 1987 Academic Press Inc. (London) Limited
30
H. T. Mouftah et al. Device 1
Remote processor n
I’
,--
--__ ___---
-ii
Central processor
Device 1 De2c
( De?
2f
Remote proc2essor processor 1
Figure 1.
Distributed
processing
system-star
configuration
central-remote transaction requires an exchange of about 50 bits of information, the method is found to be acceptable. A 5 ms bit length is chosen to test the software and hardware, but this may be reduced somewhat within the constraints of the modem. With a 5 ms bit length an errorless transaction takes approximately 0.6 s. The communication sequence is designed so that the master processor is responsible for error detection. Error correction is achieved by retransmission. The communication sequence is as follows: (1) The transmit line from the master is normally high. (2) The master pulls the line low for four bit times. number and waits for an echo. (31 The master sends a remote identification The remote recognizes its code and echoes the code in acknowledgement. (4) The master compares the received code and the transmitted code. (5) The remote, without prompt, sends the state of its sensors. Each data bit is sent (6) twice in succession. After the master has received all the data, successive bits are compared to check for errors. The double bits are then reduced to a single bit. by the master and echoed by the (71 The required device status is then transmitted remote. The echoed data is then compared with the transmitted data for errors. If errors are found anywhere during the transaction, the sequence is repeated. If (8) no errors are detected, the next remote processor is then serviced.
3.
Central
processor
software
The description of this software will be broken down into three areas: data base, data base access and remote processor servicing. Before these areas are described in detail, an overview of the software will be presented.
Distributed energy management
31
The data base is the common link between the two main sections of software. The remote servicing software uses information in the data base while the data base access software allows the operator to change this information. The central processor continuously services the remote processors unless the operator wishes to make a change to the data base. Upon entry of the required log on code at the terminal, the central processor, on recognition of the valid code, halts service to the remotes and turns its attention to the operator. After the operator has made the desired changes and has logged off, the central processor resumes service to the remotes using the updated information stored in the data base. This flow of events is illustrated in Figure 2. 3.1
Data base
The data base stores the following information about each remote processor: the state of the remote (is it in service or not?), the number of devices it controls, and the on-off times for each device. It is designed to be flexible enough to add many remote processor and device records at any time, and to be able to specify many daily operating periods per device. Stored in the first location of each remote file is the ASCII character ‘ACK’ or ‘NAK’. This character lets the accessing software know whether or not the remote is in service. The rest of the file is occupied by device records. A device record consists of: one byte for the device identification number; two bytes for an ON time; two bytes for an OFF time; a total of five bytes per record. The number of device records per remote has been arbitrarily set to 30. Since any number of records can be allocated to a particular device, that device can have more then one daily operating period.
f
,
Get record
-
-
t
Go to begin of data base A
Service operator
I
-
Figure 2.
System software
overview.
32
H. T. Mouftah et al.
After completing a successful log-on, the user is presented with a list of data base manipulation commands which, for brevity, are not described in this paper. 3.2
Remote processor servicing
The remote servicing software can be subdivided into two groups: the ‘communication software’ and the ‘decision making software’. The ‘communication software’ uses two groups of routines, the transmit group and the receive group. These represent the core routines used to implement the protocol. All other routines use these routines to perform the required functions. The transmit and receive routines are responsible for sending and receiving all data in the form required by the protocol. All incoming or outgoing data is temporarily stored in a four byte data buffer called DATA. In both the transmit and receive routines the data is handled in eight bit blocks, in order to make the data processing more ‘byte-oriented’ and hence simpler. The ‘decision-making’ software involves obtaining the time from the real time clock and then using the data base to decide which devices connected to which remotes should be on at a given time. Since more than one ON-OFF time pair may be specified for a given device, all records must be examined before a decision can be made as to whether the device should be ON or OFF. Each record is checked in succession until one dictates that the device should on ON. Once this is found the appropriate bit in the data word is set to 1 (one) and then the next device is processed. If none of the records in the file specifies a device to be ON then it is assumed to be OFF and the bit is set to 0 (zero). When comparing a set of ON-OFF times with the real time to determine whether the device is on or off, there are two possible cases to consider. The first case is when the ON time is less than the OFF time, in other words a device that is on during the day. For example, turn on the lights at 08:OOhours and turn them off at 17:OO(5:OOp.m.). For the device to be set to ON, the real time must be greater than the ON time AND less than the OFF time. The second case occurs when the ON time is less than the OFF time, in other words a device that is left on over midnight. For example, turr Y the burglar alarm at 17:00 and turn it off at 08:OO.In this case the real time must be less than the OFF time OR greater than the ON time in order for the device to be set to ON. Since these two cases must be handled separately, a decision is made as to which case exists. The flow chart showing the sequence of events for the decision-making process is shown in Figures 3 and 4. The operator log on servicing routine is also included in the decision-making software. When the system is initialized the MC 6850 asynchronous communication interface adapter (ACIA) is set up to interrupt the processor each time a key is depressed on the central processor terminal. The interrupt service routine stores the last four characters entered in a log on buffer. After each remote has been serviced this log on buffer is compared with the proper log on code to determine whether or not the operator desires access to the data base. If the log on is valid then control is transferred to the data base access software, otherwise input from the terminal is ignored and the next remote is serviced. If a successful log on occurs, then the central processor will stop updating the remote processors and begin executing the software that allows the user to modify the system. Since remote processor updating will not resume until the operator has logged off, these system modifications should be made at times when the effects of delaying updates to the remote processors will be small.
Energy management and security system
33
Find another record for device
Figure 3.
4.
Real-time
Control word assembly.
clock
The real-time clock is built around a National Semiconductor clock chip (MM 53 11) driven by a crystal-based 60 Hz reference. The multiplexed BCD output from this chip is fed to four BCD-to-seven-segment decoder/drivers and to four latches. Each seven segment decoder drives a separate LED display when enabled by a demultiplex strobe from the clock. Each digit of the BCD data is also loaded into a separate latch by the corresponding clock strobe. The latches are accessible to the MC 6821 peripheral interface adapter (PIA) through tri-state buffers and could be read individually using a decoder to select only one of the four gates at a time. A byte-oriented representation of the real-time is then created in software in the central processor. During a real-time read the latches are disabled by a control line from the PIA so that the time does not change while a read is in progress.
34
H. T. Mouftah ef al.
Figure 4.
Time comparing
algorithm.
The real-time clock can also be externally adjusted from the central processor’s terminal keyboard by using an opto-isolator, a switch to enable the input for the fast-set function on the clock chip.
5.
Remote processor implementation
The remote processor controls various peripheral devices located throughout a building. In our particular case the remote processor is based on the Motorola MC 14500B CMOS series IC. It is a one data bit wide processing unit. Due to its architecture and instruction set it is a decision-oriented machine. Unlike other microprocessing units today, it contains no program counter, interrupt vector capability, nor stack counter. These components are implemented externally to the MC 14500. However, it has its own built in oscillator, four flag lines capable of putting out a pulse via software and a single bit wide accumulator. There are four flag lines going into the instruction register. The instruction register then, is a four bit wide device producing an instruction set for the MC 14500 containing 16 different instructions. Figure 5 is a block diagram of a typical system operation. The design configuration had the system flow changing as the clock goes from high to low and vice versa. When
Energy management and security system
35
instructions
Figure 5.
General block diagram of the remote processor.
the clock is high, the memory supplies the MC 14500’s instruction register with the appropriate 4 bit wide instruction. On the lower part of the clock cycle, the MC 14500 ignores any data presented to the pins of the instruction register. Instead, the memory supplies an address to the pins of an input demultiplexer or an output multiplexer/latch. Further circuitry is used to ensure the data line is an input or output depending upon the relevant MC 14500 instruction. Through software, the remote processor is intended to incorporate a fair degree of control. The following is an example of this control ability. The remote processor can keep the temperature in a building fixed at 20°C during the day. Upon receiving instructions from the central computer the remote can change the temperature to 15°C and keep it fixed at this level. Thus the remote operates as a separate entity and will change its control function at the central computer’s request. The ICU has what is basically two modes of operation. The first mode is the independent mode. In this case, the TCU makes decisions based solely upon the information it receives from its sensors. Action is taken by the ICU independent of the MC 6800-based central processor. The second mode is what is referred to as the dependent mode. In this case, the ICU acts as a relay between the MC 6800 and the output attached to the ICU. For example, the lighting system is dependent upon the MC 6800 for control. While the ICU is the instrument which turns the lights on or off, the central processor-because it has the real time clock-is the device which determines when the lights should be turned on or off. The software for the independent mode is fairly straightforward to implement. This is due to not having to write any software to receive and take action on any messages from the central processor. Figure 6 is a flow diagram of the ICU in the independent mode. Due to the hardware design of the ICU, execution of the NOPF (no operation) causes system execution to jump back to the origin (location 0000). The program flow is a simple top to bottom loop. The dependent mode of operation requires a great deal more software than the
36
H. T. Mouftah, R. Kun and D. Hoffer
t Check device no. 1
Take Corrective
set off alarm
Figure 6.
The independent mode of operation of the remote processor.
independent mode. This is due, in part, to the requirements involved in communicating with the central processor. Figure 7 is a flow diagram of the dependent mode of operation. An important aspect of the program for the dependent mode is the. software block used to receive and decode any incoming data. The ICU is set up so that upon execution of a special instruction, a flip flop pulls the reset pin high and holds it high until a zero bit (a start bit) comes in. Each time data from the central processor has to be received, this block of software is executed.
Energy management and security system
37
Send back stata of devices
Receive, echo, execute command
Figure 7.
6.
Energy
The dependent
management
mode of operation
for the remote processor.
example
To illustrate the energy savings that this system can provide consider the following system. Most industrial or commercial building complexes are billed for their peak electrical energy consumed during the day. Thus, if all the buildings’ heating/cooling systems were duty cycled in such a manner as to reduce the peak energy consumed, then considerable savings would be realized.
38
H. T. Mouftah et al.
1
Cold deck
I -
Fresh air
/
y C”,” water
Figure 8.
Return fan
al .L$ G
Hot deck
f-\
Supply fan )
11 -
II”1
water
The air flow heating
system example.
To understand the duty cycling with respect to an airflow system, the simplified representation of an air flow system (Figure 8) should be examined. In a typical building, the supply fan and return fan will operate continuously during the day while analogue controllers adjust the heat via the pneumatically controlled dampers and the circulation pumps. Having the pumps and fans operating throughout the day is expensive. By evaluating the thermodynamics of the building and assessing the outside environmental effects, an efficient air flow strategy can be determined. For example, say the outside temperature is 5°C then to achieve a desired inside temperature of 20°C it may be necessary to run the return fan for 20 minutes every hour. In order to keep the air fresh, it may be necessary to run the supply fan for 10 minutes every hour. Thus this illustrative system uses one half hour of fan time as opposed to two hours of fan time in the previous situation with both fans running continuously.
7.
Conclusions
A multi-microprocessor-based energy management and security system has been presented. Although the implementation of the system could have been easier if an 8-bit single chip microcomputer was used in the design of the remote processor, the system proved to be flexible, reliable and cost effective. The system can have direct applications in data logging systems. In large applications there could be remote processor areas that require more frequent attention than others. This could be accomplished by assigning priorities to the remotes, thereby ensuring that all areas are monitored only as frequently as required.
Energy management and security system
39
Acknowledgements The authors would like to thank Alan Chan, Alan Smith and Terry Kitzul for their help in develop;ing the software. This work was carried out at Queen’s University and was partially supported by the Natural Science and Engineering Research Council of Canada and Queen’s University Research Award.
References Chan, A., Hoffer, D. & Kormos, T. 1982. Energy Management and Security Systems: An M6800 Microprocessing Unit Controlling an Array of l-Bit Microprocessors, Project Report, Department of Electrical Engineering, Queen’s University at Kingston, April. H. T. Mouftah received the BSc degree in electrical engineering, and the MSc degree in computer science from the University of Alexandria, Alexandria, Egypt, in 1969 and 1972 respectively; and the PhD degree in electrical engineering from Lava1 University, Quebec, Canada, in 1975. After a year of postdoctoral fellow at the University of Toronto, he was a senior digital systems engineer and then chief engineer at Adaptive Microelectronics Ltd., Thornhill, Ontario from 1976 to 1977. From 1977 to 1979 he worked with the Data System Planning Department at Bell-Northern Research, Ottawa, Canada. In 1979 he joined the Department of Electrical Engineering, Queen’s University at Kingston, Ontario, Canada, where he is presently an associate professor. He has consulted for government and industry and holds a number of patents and published a large number of technical articles in the areas of computer communications, digital systems and multiple-valued logic. Randy Km received his BSc in Electrical Engineering from Queen’s University in Canada in I98 1 where part of the research described in this paper was performed as part of the undergraduate program. Mr Kun subsequently joined Bell-Northern Research Ltd. working on digital switching products and is currently completing a Masters degree in Systems Engineering at Carleton University in Canada. David Ho&r received his BSc in electrical engineering from Queen’s University at Kingston, Ontario, Canada in 1981, after which he joined Norpak Corp. as a design engineer. In 1983 he joined Telesat Canada. There his responsibilities include the monitoring of spacecraft integration and test at the Kennedy Space Center prior to the shuttle launch of Telesat’s communication satellites. His other duties include the design and test of Telesat’s Getaway Special Experiments (small self-contained scientific packages that are flown on the shuttle).