Design of Remote Fire Alarm System Based on GSM*

DUAN Qichang & MAO Li

(Rockwell Laboratory, Chongqing University, No.174, Shazheng Street, Shapingba District, Chongqing, 400044, China)
Abstract: This paper has analyzed the situation of existent fire alarm systems and has proposed a new method of connecting local fire alarm controllers to build a much larger and more powerful system, with GSM (Global System for Mobile Communications) as the communication medium. All these local fire alarm controllers, which work as slave stations, and a central monitor, which works as a master station, are incorporated in the GSM network. Information is transmitted between the master station and slave stations through SMS (Short Message Service). The general structure of the system is presented in this paper. It is a threehierarchy model and it consists of three subsystems: detecting and controlling subsystem, communication subsystem and central monitor subsystem. The function of each subsystem is explained and the hardware and software details of the communication subsystem are described. Keywords: fire alarm; remote supervision; GSM; SMS

1 Introduction
With the rapid urbanization and the emergence of more and more skyscrapers, fire occurs frequently, which not only causes large economic losses, but also endangers peoples lives. To avoid fire disasters, many kinds of fire alarm systems have been explored. At present, most of the conventional fire alarm systems work separately, without connection with each other. A typical one consists of a MCU as its core, some sensors and control devices. The MCU analyzes the data output by sensors and when it determines there is a fire, it alarms by sound or light and output specified commands to the control devices. Also a more advanced kind of fire alarm system has been proposed recently. In this kind of fire alarm system, local fire alarm controllers are connected by field bus, such as RS485, CAN, etc, so they can exchange information with each other. This kind of system provides the possibility of remote monitor and control, hierarchical management and communication services, etc. But all these field buses have a limited maximum cable length. For example, the maximum cable length for RS485 specification is 1 200 m. As for CAN, when data rate is below 10 kbps, the maximum cable length is 6.7 kilometers; when data rate is up to 1 Mbps, the cable length cannot exceed 40 m. So this kind of system can only be used in small-sized or medium-sized areas where local fire alarm controls are not very far apart, such as a floor, a single building, or several nearby buildings. However, in large-sized areas, as a campus, a district with many buildings or even a city, there is no appropriate method of network connection yet. This paper has advanced an innovative GSM-based fire alarm system. All the local fire alarm controllers and a central monitor are linked wirelessly in the GSM network and information is transmitted through SMS. This paper is structured as follows: in the next section, the general structure of the GSM-based fire alarm system is presented and the function of each subsystem is explained; and then the hardware and software details of one of its subsystems the communication subsystem are described.

2 General Structure
The block diagram of the GSM-based fire alarm system is shown in Fig.1. The whole system comprises three subsystems: detecting and controlling subsystem, communication subsystem and central monitor subsystem, each in different hierarchy. 2.1 Detecting and Controlling Subsystem The detecting and controlling subsystem is almost the same as that of the conventional distributed fire alarm systems. As shown in Figure 1, the detecting and controlling subsystem is composed of many nodes (node 1 to node n in Fig.1) and a central MCU (MCU 1 in Figure 1). The nodes all have the same structure as node 1. Each node includes three parts: a MCU, sensors and control devices. The sensors can be fog sensors, temperature sensors and relative humidity sensors, etc. Sensors sample the environmental variables and pass the parameters to the MCU in each node. The control devices include valves and taps, etc. They are started and stopped by signals output by the MCU in each node. It should be pointed out that the MCU in each node doesnt have intelligence, i.e. it doesnt analyze parameters or determine whether a fire has occurred. Its the central MCU (i.e. MCU 1 in Figure 1) that has the intelligence. These nodes are set in a relatively small area, for example, one in each room. Since these nodes are not very far apart, they are connected by RS485, together with MCU 1. MCU 1 works as the master station, and each node has a unique slave address on the bus. MCU 1 polls parameters from each node and makes a comprehensive analysis to determine whether there is a fire or not. If a fire occurs, it will
*

Supported by Postgraduate Innovation Foundation of Chongqing University, China, under Grant No. 200504Y1B0090114

241

command corresponding nodes to give off alarm signals, such as sound or light, and start the valves or taps. This subsystem is in the lowest hierarchy of the three-hierarchy model. The accuracy and real time processing can be guaranteed by RS485 bus.

Fig.1 General structure of the GSM-based fire alarm system 2.2 Communication Subsystem Communication subsystem is the key subsystem. It has two interfaces. As is shown in Figure 1, one interface is used for the connection between MCU 1 and MCU 2, and the other one is used for the connection between MCU 2 and GSM network. When MCU 1 has detected that a fire occurs, it not only sends commands to its subordinate nodes, but also sends information, including the place of the fire, the parameters of its surrounding environment and the actions that have been taken, etc, to MCU 2. Then MCU 2 can send a short message containing the information to the central monitor through the GSM interface. Also MCU 2 will receive commands from the central monitor and tell MCU 1 what to do. The main function of MCU 2 is communication: communicating with MCU 1 and communicating with the central monitor, thats why we call this subsystem communication subsystem. This subsystem is in the middle hierarchy of the whole system. It is the intermediate between the lower hierarchy and the higher hierarchy, providing the services of communication and remote supervision. It enables the remote central monitor to have a full mastery of every local area at any time and store all the data in a central database for future review, so the management efficiency is improved greatly. Large area coverage, convenient maintenance and high management performance are what this subsystem focuses on. The requirement of high real-time performance is not as strict as that of the detecting and controlling subsystem. Delay of several minutes is tolerable. Based on these features of this subsystem, GSM network is chosen as the communication media between local area controllers and the central monitor. Data is transferred through SMS, a unique feature of GSM. SMS is a bidirectional service for short alphanumeric (up to 140 bytes) messages. Messages are transported in a store-and-forward fashion. For point-to-point SMS, a message can be sent to another subscriber to the service, and an acknowledgement of receipt is provided to the sender. SMS can also be used in a cell-broadcast mode, for sending messages such as traffic updates or news updates. The interface between MCU 2 and MCU 1 is RS232, because it is cost-effective and very easy to use. In addition, its date rate (19200bps) can fulfill the demand. This subsystem is the emphasis of this paper. Its hardware and software details are described in section 3. 2.3 Central Monitor Subsystem Central monitor subsystem is in the highest hierarchy of the whole system. It primarily consists of an industrial computer, a HMI (Human Machine Interface) and a GSM interface. This subsystem gathers information from local fire alarm controllers. There are two modes of gathering: one is that the central monitor inquires and the local controllers inquired respond; the other one is that local fire alarm controllers send unsolicited information to the central monitor in an emergency. Both modes are useful in practical applications. 242

The former one is used in general situations and the latter one is mainly used when emergency occurs. Each local controller is identified by its MSISDN (Mobile Station ISDN) number. The mapping relation between numbers and places is stored in a database in the industrial computer. The program running on the industrial computer will process further the data received through the GSM interface, doing complicated analysis, classifying and storing them in different databases and presenting their tendency in plots. The administrator can not only observe the details of each local area, but also send commands to it via the HMI and GSM interface.

3 Design Details of Communication Subsystem

The design details of all the three subsystems cannot be described in this single paper. This paper only focuses on how to design the communication subsystem. 3.1 Hardware Design 3.1.1 Brief introduction of TC35i In order to be connected to GSM network, the subsystem needs a GSM engine. In this solution TC35i, a GSM engine manufactured by Siemens Corporation, is adopted. TC35i operates in the GSM 900MHz and GSM 1800MHz frequency bands. Designed to easily provide radio connection and data transmission it integrates seamlessly with a wide range of GSM application platform. The complete RF part is incorporated and the GSM protocol runs autonomously on a GSM baseband processor. The GSM engine uses a single 40-pin ZIF connector that connects to the cellular device application. The ZIF connector establishes the application interface for control data, audio signals and power supply lines. 3.1.2 Overview of the hardware structure The overview of the hardware structure is shown in Fig.2.

Fig.2 Overview of hardware structure

Fig.3 Details of interface circuit between W77E58 and TC35i

W77E58 is a fast 8051 compatible microcontroller, containing 32 KB multiple-time programmable ROM, 256 bytes scratch-pad RAM and 1 KB on-chip XRAM. It has two enhanced full duplex serial ports: serial port 0 and serial port 1. The serial port 0 is for the interface to the detecting and controlling subsystem, and is directly connected to MAX232, a multi-channel RS232 driver/receiver. The serial port 1 is for the interface to GSM engine, and is directly connected to the interface circuit as shown in Figure 2. The interface circuit establishes the connection between the MCU and TC35i for data transfer. It is explained in detail in the next section A SIM card (Subscriber Identification Module) is necessary in any GSM application. TC35i provides an integrated SIM interface compatible with the ISO 7816 IC Card standard. This is wired to an external SIM car holder with 6 pins (CCGND, CCCLK, CCVCC, CCIO, CCRST, CCIN). Since short message is used for data transfer, the MCU needs to process a large amount of character strings. The 256 bytes scratchpad RAM and 1 KB on-chip XRAM are far from enough, so an external 32 KB SRAM HY62256 is extended in this subsystem. It is accessed via 16-bit address bus and 8-bit data bus. AT24C02 provides 2048 bits of serial EEPROM organized as 256 words of 8 bits each, and is accessed via IIC bus, a kind of 2wire serial interface, using only 2 I/O pins of the MCU. Unchanged or seldom changed configuration parameters are stored in AT24C02. 3.1.3 Interface circuit between MCU and TC35i Only 4 pins of W77E58 are used for communication with TC35i: 243

(1)Serial Port 1: including 2 pins RXD1 and TXD1. TXD1 sends data to TC35i and RXD1 receives data from TC35i. (2) INT1: external interrupt pin. A high-to-low transition on this pin indicates URCs (Unsolicited Result Codes) from TC35i or an incoming call. (3) I/O1: an output pin. The output signal on this pin switches on TC35i. Also 4 corresponding pins of TC35i are used: RXD0 and TXD0: RXD0 sends data to MCU and TXD0 receives data from MCU. The signal direction of RXD0 is output, while TXD0 input, totally contrary to that of MCU. RING: When a voice call comes in the RING line goes low for 1 second and high for another 4 seconds. Every 5 seconds the ring string is generated and sent over the RXD0 line. All types of URCs also cause the RING line to go low, however for 1 second only[1]. IGT: To switch on TC35i, after the VBAT+ line has reached 3.0V, the IGT signal needs to hold high impedance state for at least 10ms, and then be driven to ground level for at least 100ms, and then high impedance state again. Details of the interface circuit are shown in Figure 3. The high-level voltage of I/O pins of W77E58 should be in the range 4.5V to 5V and low-level voltage 0V when the MCU is provided with a power supply of 5V. However, as for the TXD0, RXD0 and RING lines of TC35i, the significant levels are 2.65V for high data bit and 0V for low data bit. So its necessary to convert voltage levels between 2.65V and 5V. One 74LS07 chip, which contains 8 channels of open collector drivers, is used as a simple and effective solution to this problem. The minimal value of the highlevel input voltage of 74LS07 can be as low as 2V and the high-level output voltage depends on the voltage to which the pull-up resistor is connected. When the TXD1 pin of W77E58 outputs 5V, the TXD0 line of TC35i actually receives a signal of about 2.7V because the pull-up connector is connected to 2.7V. In the same way, when the RXD0 line or RING line of TC35i outputs 2.65V, the RXD1 pin or INT1 pin of W77E58 actually receives signals of about 5V. The ignition circuit for TC35i comprises a transistor with its collector open. When I/O1 outputs 0V, no current flows from or to the collector, so the IGT signal is set in high impedance state. When I/O1 outputs 5V, the transistor enters into saturation state and the IGT signal is driven to ground level. In order to turn on TC35i using the IGT signal, pull down I/O1 pin for 10 ms, then up for 100 ms, and then low again after the power-on-reset of W77E58. 3.2 Software Design The software part of this subsystem mainly handles two tasks: (1) MCU receives a data frame encapsulated in a short message sent by central monitor, subtracts additional frame headers, extracts useful data (i.e. command word), and sends it to the detecting and controlling subsystem. (2) MCU receives status word from the detecting and controlling subsystem, adds frame headers to it, encapsulates the frame in a short message and sends it to central monitor. In this section, several questions are discussed: the way data is transferred between MCU and TC35i, the format of the data frame and the transmission protocol. 3.2.1 Data transfer between MCU and TC35i MCU sends AT commands to control TC35i via its serial port. Several AT commands used for configuring TC35i and for sending and receiving short messages are listed below. Their parameters and responses are described in TC35i AT Command Set [2]. (1) AT: testing connection with TC35i. (2) ATE0: disabling command echo. (3) AT^SSYNC: configuring the behavior of SYNC pin of TC35i. (4) AT+CNMI: setting new SMS message indications. (5) AT+CPMS: selecting preferred SMS message storage. (6) AT^SMGO: setting SMS overflow presentation mode. (7) AT+CMGR: reading SMS message. (8) AT+CMGS: sending SMS message. (9) AT+CMGD: deleting SMS message. AT^SMSO: switching off TC35i. There are two ways of sending and receiving SMS messages: by text mode and by PDU (Protocol Description Unit) mode. The 244

PDU string contains not only the message, but also a lot of meta-information about the sender, its SMS service center, the time stamp of service center, and the length of user data etc, whereas in text mode, the additional information is not contained. In this application, PDU mode is adopted. Roughly speaking, it includes two parts: the PDU header and the user data (called as TP-User-Data). The particular format of PDU mode and the explanation of each field are explained in GSM 03.40 (ETS 300 536) every character is represented by 7 bits, and thus 160 characters can be represented by 140 bytes. 3.2.2 Format of data frame The status word from lower hierarchy and command word from higher hierarchy both need two levels of encapsulation, as Fig.4 shows. The status word and command work are encapsulated in a data frame, and the data frame is encapsulated in a short message TPDU.
[3]

. User data can be

encoded in three schemes: default alphabet, 8 bit data and UCS2. In this application, default alphabet encoding scheme is used, in which

Fig.4 Two levels of data encapsulation

Fig.5 Data frame format

The data frame is divided into two parts, a header followed by user data. The header carries the expected identification and control information. Figure 5 shows the data frame format. The frame header has a fixed length of 8 bytes. Each integer value in the range 0 to 255 is converted into hexadecimal numbers containing one or two ASCII characters (e.g. integer 100 is represented by two ASCII characters 0x36 and 0x34; integer 1 is represented by one ASCII character 0x31). Sequence Number: This field gives an integer representation of an identification number of the short message being submitted. It possesses values in the range 0 to 255. The value is incremented by 1 for each message being submitted. However, in the case where no acknowledgement is received in response to a message, the program will re-submit the message but use the same sequence number value. Acknowledgement Number: When a message is received, the receiver will acknowledge it by sending a message to the sender, in which this field carries the same value as the sequence number of the message received. ACK: The Acknowledgement Number field is valid only when the ACK field is set to 1. CheckSum: It contains an 8-bit integer checksum used to verify the integrity of the data. It is the sum of every byte in the frame, excluding this field itself. Only when the value computed by the receiver equals the value computed by the sender, a message will be considered valid. Type: It indicates the type of the message being submitted so that the receiver can perform different tasks according to it. For example, value I in this field means this message contains inquiry information, while value S means status information. User Data: As discussed before, since default alphabet encoding scheme is used, the data frame can carry up to 160 characters. So the length of the user data should be in the rage 0 to 152 bytes. 3.2.3 Transmission protocol SMS provides unreliable delivery service. Sometimes short messages will be lost, and sometimes a short message sent earlier than another will be received at a later time. In order to reduce these disadvantages to the greatest extent possible, we developed a transmission protocol, which is called as acknowledgement with retransmission. The protocol requires a receiver to send back an acknowledgement as it receives a short message. The sender keeps a record of each short message it sends and waits for an acknowledgement. The sender also starts a timer when it sends a short message and retransmits it if the timer expires before an acknowledgement arrives. 245

High delays may cause premature retransmission, so both messages and the acknowledgements can be duplicated. The protocol detects duplicate messages by assigning each short message a sequence number (see Sequence Number field in the section above). So short messages with the same sequence number received within a specified short period of time are considered as duplicate messages and only one of them will be handled and others will be discarded. To avoid confusion caused by delayed or duplicated acknowledgements, it is required that a sequence number be sent back in Acknowledgement Number field, so the receiver can correctly associate acknowledgements with short messages. If a short message is acknowledged more than once within a specified short period of time, the duplicate acknowledgements will be discarded. Acknowledgement can be sent either in a short message containing user data or in a short message only containing the frame header, without any user data. If no acknowledgement arrives within the maximum retransmission times permitted, the program will generate an error report and give up retransmission. It will try again after a relatively long period of time.

4 Conclusion
An innovative and effective GSM-based fire alarm system is proposed in this paper, which takes full advantage of GSM network and its unique SMS service. This three-hierarchy model provides more powerful functions of remote supervision and efficient information management than any traditional fire alarm systems. The design details of its communication subsystem are described. The same conception can also be used in other remote supervisory systems.
References [1] [2] [3] [4] [5] [6] [7] Siemens Mobile, TC35i Hardware Interface Description, Version 00.03, DocId TC35i_HD_V00.03 (2003) Siemens Mobile, TC35i AT Command Set, Version 00.01, DocID TC35i_ATC_V00.01(2003) ETSI TC-SMG, ETS 300 536: GSM 03.40 version 4.13.0 (1996) Wang Jun, Xu Fang. An overview of network technology of fire detection and alarm systems. Electric and Intelligent Building, 2004(5) ISO/WD 7240-18, Fire Detection and Fire Alarm Systems-Par 18: Routing Equipments, 2002 uC/OS-II and ARM Processors Application Note, Jean J Labrosse, Micrium, 2004 Zhang Guiming. Research and design of remote control and alarm system based on GSM/SMS. Journal of Sichuan Normal Univeristy (Natual Science), 2004(27) [8] Kan K K H, Chan S K C. A dual-channel location estimation system for providing location services based on the GPS and GSM networks. Advanced Information Networking and Applications, 2003. 17th International Conference, Mar 27-29, 2003 [9] Micro-controller based vehicle tracing system via use of GPS and GSM. Okatan A, Salih A, eds. Recent Advances in Space Technologies, 2004. International Conference Proceedings of Nov 20-22, 2003

246