Testing system and method for fire alarm system

A system and method for testing fire detection and fire annunciation devices of a fire alarm system includes a central operations system, which provides a link between a control panel of the fire alarm system and a mobile computing device operated by a technician. During a walkthrough test, the on-site technician activates fire detection or fire annunciation devices of the fire alarm system and the activated devices signal the control panel and event data are generated. Event data from the control panel are sent to the central operations system to be stored. The central operations system sends the event data to a mobile computing device operated by the technician. The on-site technician is then able verify that the devices are physically sound, unaltered, working properly, and located in their assigned locations.

BACKGROUND OF THE INVENTION

Fire alarm systems are often installed within buildings such as commercial, residential, or governmental buildings. Examples include hospitals, warehouses, schools, malls and casinos, to list a few examples. These fire alarm systems typically include a control panel and fire detection devices and fire annunciation devices, which are installed throughout the buildings. Some examples of fire detection devices include smoke detectors, carbon monoxide detectors, temperature sensors, and/or pull stations. Some examples of fire annunciation devices include speakers/horns, bells/chimes, light emitting diode (LED) reader boards, and/or flashing lights (e.g., strobes). Additionally, some fire alarm systems may also include security devices such as surveillance cameras, access control readers, and door controllers, to list a few examples.

The fire detection devices monitor the buildings for indicators of fire. Upon detection of an indicator of fire, the device is activated and a signal is sent from the activated device to the fire control panel. Typically, the fire control panel activates audio and visible alarms of the fire annunciation devices of the fire alarm system and sends a signal to a fire department, central receiving station, local monitoring station, and/or other building alarm/notification systems.

Typically, the fire detection and fire annunciation devices are periodically tested (e.g., monthly, quarterly, or annually depending on local interpretation and enforcement of fire protection codes) to verify that the fire detection and fire annunciation devices are physically sound, unaltered, working properly, and located in their assigned locations. This testing of the fire detection and fire annunciation devices is often accomplished with a walkthrough test.

Historically, walkthrough tests were performed by a team of at least two technicians. The first technician walked through the building and manually activated each fire detection and fire annunciation device while the second technician remained at the control panel to verify that the control panel received a signal from the activated device. The technicians would typically communicate via two-way radios or mobile phones to coordinate the testing of each device. In some cases, the technicians might even have resorted to comparing hand written notes of the tested devices. After a group of fire detection and fire annunciation devices was tested, the technician at the panel reset the control panel while the other technician moved to the next fire detection or fire annunciation device.

Recently, single-person walkthrough systems have been proposed. In these systems, the technician connects a computer to the control panel and a first two-way radio. The technician then establishes a communications link with the first two-way radio using a second two-way radio and selecting the same radio frequency on both of the two-way radios. Alternatively, the technician may establish a communications link with cellular phones or a paging transmitter and pager.

During the walkthrough test, the technician places one of the fire detection or fire annunciation devices into an alarm condition. The control panel detects the alarm condition of the activated device and sends a message containing the location and/or address of the activated device to the computer. Next, the computer converts the message received from the control panel to an audio stream and sends the audio stream to the technician over the communications link. The technician hears the location and/or address of the activated device and verifies if the device is wired correctly. The testing process repeats with the next fire detection or fire annunciation device until all of the fire detection and fire annunciation devices of the alarm system have been verified.

SUMMARY OF THE INVENTION

In general, the present system and method are directed to a networked testing system that implements a cloud based infrastructure (e.g., central communications system) to enable communications between a control panel of a fire alarm system and a mobile computing device operated by an on-site technician.

The central communications system provides a link between the control panel of the fire alarm system and the mobile computing device operated by the on-site technician. The central communications system receives event data from the control panel and sends the event data to the mobile computing device in real-time. Illustrated by way of example, upon activation of a fire detection or fire annunciation device, the control panel receives a signal from the activated device. Event data are generated and sent to the central communications system. The event data are stored and/or logged by the central operations system and also sent to the mobile computing device in real-time. The on-site technician is able to view the event data and verify that the fire detection or fire annunciation device is physically sound, unaltered working properly, and in its assigned location. The technician then moves to test the next fire detection or fire annunciation device.

There are additional benefits that may be achieved in embodiments that are built according to the principles of the present invention. For example, one benefit of the present system is that event data are stored by the central operations system. This allows the on-site technician is able to review all panel activity and historical event data via their mobile computing device (whether manually activated or not). Further, the on-site technician can be made immediately aware of any unsolicited (or “real”) alarms if an event is displayed that the on-site technician did not activate. Furthermore, event data are accessible for reviewing and reporting purposes without any additional human intervention (other than activating the fire detection or fire annunciation device to go into alarm).

Additionally, because the event data are stored by the central operations system, if the mobile computing device temporarily loses communications with the central operations system, the mobile computing device is still able to access all of the event data when it gets back into communications range by buffering data by the central operations system.

Still another benefit can be that one or more remote technicians are able to monitor the alarms activated by the on-site technician and the progress of the on-site technician by accessing the event data stored by the central operations system. This enables the remote technician to be able watch for “real” alarms without being on-site with the on-site technician, for example.

It is also possible for two or more on-site technicians, each equipped with their own mobile computing device, to perform testing in parallel. While this does not reduce the manpower used for the walkthrough test, it does reduce the amount of time required to complete the test. Often, this reduced testing time is desirable in buildings where interruption and disruptions are undesirable (e.g., hospitals).

Another potential benefit of the present system is that the central operations system can record the unique device address of the activated device along with the activation, acknowledgement and restoral times detected by the control panel. While the fire detection or fire annunciation devices are manually activated by the on-site technician, the recorded event data are generated by the control panel. This ensures that test data cannot be manually entered, altered, or falsified.

In embodiments, smoke detectors, which require occasional cleaning, can be identified during the walkthrough test. Typically, an analog value is included as part of the event data on the mobile computing device. This analog value can be used to indicate that the device needs to be serviced or cleaned. Thus, these devices do not need to be reviewed separately or revisited as part of a cleaning cycle.

Yet another potential benefit is that the configuration is automated. For example, system startup of the testing computer automatically invokes the agent software of the testing computer, in one example. The agent software can automatically query the control panel for its operating parameters (such as e.g., device name, model number, serial number, software revision, and configuration) and automatically create a unique identifier for the control panel. The agent software then securely communicates the operating parameter information to the central operations system. Moreover, if the control panel is new to the system, the central operations system creates a new entry in the data storage system. If the control panel already exists in the records of the data storage system, the central operations system appends information to the existing record.

In general, according to one aspect, the invention features a method for testing a fire alarm system. The method includes a technician activating devices of the fire alarm system. The activated devices signal a control panel and event data from the control panel are sent to a central operations system. The method further includes sending the event data from the central operations system to a mobile computing device operated by the technician.

In embodiments, the central operations system receives event data from different control panels in response to testing different fire alarm systems at different facilities and in this way functions as a cloud-based system that handled handles information from many different customers and/or independent business entities. The received event data from the different control panels of different fire alarms systems are stored in a single data storage system of the central operations system.

Preferably, the central operations system sends device history data along with the event data to the mobile computing device operated by the technician. In response to a failed transmission of the event data to the mobile computing device, the central operations system buffers and then later resends the event data to the mobile computing device to deal with temporary communications link failure caused by loss of a wireless or cellular signal.

In examples, the technician can apply annotations to the received event data, the annotated event data being sent to the central operations system. Generally, the event data includes a physical address of the activated devices, a date and time of the activation, a fault state of the activated devices, the current analog value of the activated devices (if applicable), and/or a custom label/descriptor of the activated devices.

To facilitate connection to the proper control panel by the mobile computing device, coordinates of the mobile computing device are derived using cellular triangulation. Alternatively, a location can be determined with a reverse lookup using geographic information system (GIS) coordinates.

In more detail, after choosing the map application on the mobile computing device, the on-site technician is shown their current location and the location of panels in the specific area. Typically, filters or toolbars are provided to reduce the map view down to a local radius such as 1 mile or to expand the radius to 20 miles (or more). The panel location position is triangulated when using a temporary (or On Demand) cellular connection and then sent to the central operations system.

Alternatively, or in cases where a permanent connection (e.g., enterprise network) is in place, the panel address in the data storage system is used for a reverse lookup to produce the GIS coordinates, which provide a location of the mobile computing device.

Alternately, or in addition, a panel identifier (e.g., serial number) can be sent to the central operations system, the central operations system identifying a specific control panel and returning information of the identified control panel to the mobile computing device to enable the technician to verify the control panel associated with the panel identifier.

Typically, the devices include smoke detectors, carbon monoxide detectors, temperature sensors, annunciators, pull stations, speakers/horns, bell/chimes, light emitting diode (LED) reader boards, and/or strobes. Additionally, in future embodiments, the fire detection and fire annunciation devices could also include addressable sprinkler heads or addressable foam generator heads.

In one example, in response to receiving unsolicited device activations at the control panel, event data of the unsolicited device activations are sent to the central operations system and the central operations system sends the event data of the unsolicited device activations to the mobile computing device to warn the technician about possible emergencies.

In the preferred embodiment, the central operations system sends an aggregate history of all the devices of the fire alarm system to the mobile computing device in response to a report request from the mobile computing device.

In general, according to another aspect, the invention features a testing system for a fire alarm system comprising a control panel that receives signals from devices, including signals generated in response to activation of the devices by a technician during a test of the devices, and that generates event data based on the signals. The testing system includes a central operations system that receives the event data. The testing system further including a mobile computing device that is operated by the technician that receives the event data from the central operations system.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1Ais block diagram illustrating the relationship between a fire alarm system100, a facilities testing computer104, a central operations system118, and a mobile computing device110operated by the on-site technician108.

In a typical implementation, the fire alarm system100is located within a building50. The building could be residential, commercial or governmental. Examples include a hospital, warehouse, retail establishment, mall, school, or casino, to list a few examples.

In the illustrated example, the fire alarm system100includes a fire control panel (control panel)102and fire detection and fire annunciation devices109-1to109-n. The fire detection devices typically include smoke detectors, carbon monoxide detectors, temperature sensors, and/or pull stations, to list a few examples. Similarly, examples of the fire annunciation devices generally include speakers/horns, bells/chimes, light emitting diode (LED) reader boards and/or flashing lights (e.g., strobes). The fire detection and fire annunciation devices109-1to109-nand control panel102are connected to a safety and security wired and/or wireless network111of the building50, which supports data and/or analog communication between the devices109-1to109-nand the control panel102.

Additionally, in some embodiments, the fire alarm system100further includes security devices such as security cameras, door controllers, access control readers, or motion sensors. These security devices may or may not be tested during a walkthrough test.

While not shown in the illustrated example, the fire alarm system and the safety and security network are often divided into different zones. For example, each floor in an office building may be a separate zone of the system. These separate zones may be controlled with separate control panels and/or subpanels.

Returning to the illustrated example, a facilities testing computer (testing computer)104is connected to the control panel102. In a current implementation, the testing computer104is connected to the control panel102with an RS-232 cable106. Alternative embodiments, however, may utilize other cables such as a universal serial bus (USB) cable or Ethernet (IEEE 802.3) cable (e.g., Cat 5 or Cat 6), to list a few examples. Other embodiments of this connection may include wireless connections such as sub-Giga Hertz serial, Bluetooth or ZigBee, to list a few examples.

The testing computer104connects to a public network113(e.g., the Internet) over possibly a wireless communication link112. In a current implementation, the wireless communication link112is encrypted using standard SSL (Secure Sockets Layer) encryption methods with the option for additional encryption such as Advanced Encryption Standard (AES), in specific implementations. The data are routed through one or more cellular radio towers (e.g., reference numeral114) of a mobile broadband or cellular network. Typically, the radio tower uses GPRS (General Packet Radio Service), GSM (Global System for Mobile Communications), or a CDMA (Code Division Multiple Access) technology. In an alternative embodiment, the testing computer104may connect to the public network113via public and/or private wired data networks such as an enterprise network or Wi-Max or Wi-Fi network, for example.

The mobile computing device110is connected to the public network113over a wireless communication link116and operated by the on-site technician108. Similar to the testing computer104, the data on the public network113and en route to the mobile computing device110via the wireless communications link116, is preferably encrypted using SSL encryption. In a current embodiment, the mobile computing device110is a laptop computer, smart phone, tablet computer, or phablet computer (i.e., a mobile device that is typically larger than a smart phone, but smaller than a tablet), to list a few examples. In an alternative embodiment, the mobile computing device110may also connect to the public network113via public and/or private data networks.

While the illustrated example only shows a single on-site technician108, it is possible for two or more on-site technicians, each equipped with their own mobile computing device, to perform testing in parallel. While this does not reduce the manpower or costs needed to complete the walkthrough test, it can reduce the amount of time needed to complete the test, which may desirable in buildings where disruptions are undesirable (e.g., hospitals).

The central operations system118preferably includes a central operation system firewall120, an applications server122, and a data storage system124.

The central operation system firewall120is a software or hardware network security feature which filters incoming and outgoing network traffic to increase security for the central operations network126. The applications server122acts as the repository and portal to access event data generated by the control panel102and sent by the facilities testing computer104. While the fire detection or fire annunciation devices are manually activated by the on-site technician during the walkthrough test, all event data are generated by the control panel102. This ensures that test data cannot be manually entered, altered, or falsified.

Typically, the event data include the unique identifier for the fire alarm control panel102, a physical address of the activated devices (109-1,109-2. . .109-n), a date and time of the activation, a fault state of the activated devices, at least one analog and/or detected value by the activated devices such as a detected smoke level or detected ambient temperature, and/or custom labels of the activated devices. Additionally, acknowledgement and restoral times of the control panel are included in the event data.

In a current implementation, the analog and/or detected value is included as part of the event data on the mobile computing device to indicate that a device needs to be serviced or cleaned. This enables devices that require occasional cleaning to be identified during the walkthrough test.

The central operation system firewall120, applications server122, and data storage system124are connected via a central operations network126. The central operation network126is a data network such as an enterprise network, for example.

The illustrated embodiment further includes a remote technician130. This technician130is able to access the central operations system118with a remote workstation128. This remote technician130may support and/or monitor the progress of the on-site technician108. In an alternative embodiment, this remote workstation128is securely connected to the central operations network126using the public network113. Connectivity to the public network113is achieved in a variety of ways including, for example, cellular data networks, private and/or public hardwired or wireless networks as well as other options known in the art. The remote workstation128is typically a computing device such as a desk top PC, laptop, tablet, phablet or smart phone, to list a few examples.

FIG. 1Bis block diagram illustrating an alternative embodiment of the relationship between the fire alarm system100, the testing computer104, the central operations system118, and the mobile computing device110.

FIG. 1Bis nearly identical toFIG. 1A. In this embodiment, however, the testing computer104, radio tower114, and the wireless communication link112are removed. In this embodiment, a serial to Ethernet converter103connects to the control panel102a facilities network105of the building50. The serial to Ethernet converter103is similar to the testing computer104, but it provides a wired connection to connect to the public network113and central operations system118.

In the illustrated embodiment, the facilities network105includes a facilities firewall107between the facilities network105and the public network113. The facilities firewall107filters incoming and outgoing network traffic of the facilities network105.

In a typical implementation, secure communications leave the serial to Ethernet converter103, traverse the facilities network105, and pass through the facilities firewall107using conventional encryption methodologies and ports and does not require firewall modifications in order to operate effectively.

FIG. 2is a flowchart illustrating the installation and setup of the testing computer104at the fire control panel102.

In the first step202, the on-site technician108connects the testing computer104to the control panel102via the connection106. Next, in step204, the on-site technician108puts the control panel102into test mode. This step ensures that the on-site technician108is at the building50and involved with the testing. Generally, this step is related to code compliance. It ensures the technician is on site and enables access to the auto acknowledgement features of the agent software.

Generally, test mode silences and/or deactivates audio and visual alarms/warnings of the fire annunciation devices during the walkthrough test. Generally, the fire detection devices are still able to detect indicators of fire, but audio and visual warnings of the fire annunciation devices are silenced if the fire detection device is activated. Additionally, if the fire detection devices have built in audio or visual alarms, these alarms are also typically silenced/deactivated in test mode. This allows the fire detection devices to continue detecting fires, but prevents the intentionally activated devices from disrupting occupants of the building during the walkthrough test.

Next, the on-site technician108connects the testing computer104to the public network113in step206. In the next step208, system startup of the testing computer104automatically invokes the agent software of the testing computer104.

FIG. 3is a flowchart illustrating the initialization of the agent software of the testing computer104.

The agent software of the testing computer104establishes communication with the control panel102of the fire alarm system100in step302. Next, the agent software creates or accesses a unique identifier for the control panel102in step304. In the next step306, the agent software determines operating parameters (e.g., device name, model number, serial number, software revision, and configuration) of the control panel102.

The agent software then determines if the control panel102is in test mode in step308. If the control panel102is in test mode, then control features (e.g., silence, acknowledge, and reset) are enabled in step310. If the control panel102is not in test mode, then those control features are restricted in step312.

The agent software then configures the communications settings of the control panel102in step314. Next, in step316, the agent software opens a connection to the applications server122through the firewall120. The agent software sends a security key for authentication in step318.

If the security key is authenticated in step320, then the agent software registers the control panel102with the applications server122to enable an application (app) executing on the mobile computing device110to access information from the control panel in step324. Alternatively, if the security key is not authenticated in step320, then an error screen is displayed in step322.

FIG. 4is a flowchart illustrating the authentication of the agent software of the testing computer104and the appending of records of the data storage system124of the central operations system118.

In the first step402, the applications server122of the central operations system118receives the security key from the agent software of the testing computer104. The applications server122determines if the security key is valid in step404. If the security key is not valid, then the applications server122returns an error screen in step406. If the security key is valid, then the applications server122authenticates the testing computer104in step408.

After authenticating the testing computer, the applications server122receives the unique panel identifier (i.e., the panel identifier created or accessed in step304ofFIG. 3) from the testing computer104in step410. In the next step412, the applications server122determines if the panel identifier is new. That is, the applications server122determines whether records already exist in the data storage system124of the central operations system118.

If the panel identifier is new, then the applications server122creates a new record for the control panel in the data storage system124in step414. The applications server124then appends the record in the data storage system124in step416. Alternatively, if the panel identifier is not new, then the applications server122appends the existing record in the data storage system124in step416.

FIG. 5Ais a flowchart showing the initialization of the application (app), which is invoked by the on-site technician108operating the mobile computing device110.

In a first step502, the on-site technician108invokes the app on the mobile computing device110. The app connects the mobile computing device110to the applications server122and sends authentication data to the applications server122in steps504and506, respectively.

If the authentication data are not validated by the applications server122in step508, then an error screen is displayed in step510. If, however, the authentication data are validated by the applications server122, then coordinates of the mobile computing device are sent to the applications server122in step512. In a current implementation, the coordinates are positioning information obtained from a GPS receiver of the mobile computing device110.

In another embodiment, the coordinates are derived from mobile phone location tracking data. For example, location can be derived by cellular triangulation using a temporary (or On Demand) cellular connection.

In yet another alternative embodiment, a location can be determined via a reverse lookup using the control panel address in the data storage system can produce geographic information system (GIS) coordinates.

After sending the coordinates to the applications server122, the applications server sends a list of panels to the mobile computing device110which displays the control panels that are at (or near) the location of the coordinates in step514. In examples, the control panels are displayed as a selectable list. In other examples, the control panels are displayed in a map view (seeFIG. 5B). The on-site technician108then preferably selects a control panel from those in the list or in the map view for monitoring and control in step516. Next, in step518, the mobile computing device110sends a request to the applications server122to receive event data for the selected control panel.

The on-site technician is also able to set event filtering options in step520. The event filtering options allow to the on-site technician108to filter out unwanted event data. Additionally, the on-site technician108may select how event data are presented on the mobile computing device110. For example, the event data are presented chronologically, segregated by zones of the fire alarm system, and/or based on which fire detection or fire annunciation devices have been activated the most/least, to list a few examples, based on technician control.

FIG. 5Bis an example of a user interface700of the application (app), which is displayed on the mobile computing device110. The user interface700displays a map view including nearby control panels based on the coordinates of the mobile computing device110.

In a typical implementation, the location of the mobile computing device is shown on a map701as a point702. Additionally, a position error associated with the location of the mobile computing device is shown as a ring704.

The app provides a range toolbar (or filter)706that enables the on-site technician108to set a radius to select an area of interest. Any control panels within the selected area of interest are displayed on the map using push pins (e.g., reference numerals708and709). In the illustrated embodiment, the range toolbar706allows the on-site technician108to choose an area of interest of 1 mile, 5 miles, 10 miles, or 20 miles. Alternatively, in other embodiments, a user-entered area of interest could be implemented.

In a current embodiment, the push pins are color-coded to provide additional information about the status of the control panels. For example, a green push pin indicates that the control panel is operating properly. A yellow push pin indicates that the control panel has maintenance issues. Lastly, a red pushpin indicates a fire has been detected by one of the fire detection devices connected to the control panel.

Additionally, the current implementation also displays an ‘X’ (e.g., reference numerals710,711) within the push pins to indicate that the software agent has stopped communicating with the central operations system118. This provides real-time feedback to the on-site technician108that there is a problem with the connection to the central operations system118that may need to be resolved before testing can begin (or continue).

A setting toolbar712of the user interface700enables the on-site technician108to view activated alarms, view fire panel information, or display the map view, shows a panels grid, or logout of the app.

FIG. 5Cillustrates an example of how the on-site technician108is able to interact with the user interface701and view additional information of the control panel102on their mobile computing device110.

In the illustrated example, the on-site technician108touches the push pin708to get information about the control panel102. Touching the push pin708produces an on screen title bar714that includes the panel name716, status718, and a carat icon720. Selecting the carat icon720connects the mobile computing device110to the control panel details portion of the application, which enables the on-site technician108to view hardware configuration, software configuration, current status, historical data, and real-time event information of the control panel.

FIG. 6Ais an alternative embodiment of the initialization of the application (app). In this alternative embodiment, the on-site technician108uses a panel serial number to select the control panel rather than coordinates of the mobile computing device110.

In the illustrated flowchart, steps602through610are identical to steps502through510ofFIG. 5A.

In this illustrated embodiment, the control panel102is not determined (and selected) based on coordinates obtained from the mobile computing device110. Instead, the on-site technician108enters all (or part) of a panel serial number via the app in step612.

The serial number is sent to the applications server122of the central operation system118via the public network113in step614. Next, in step616, the mobile computing device110receives panel information (e.g., device name, device model, location, and customer ID associated with panel) that corresponds to the entered serial number, which information has been sent by the applications server122. The on-site technician108verifies that the received panel information matches the control panel and confirms the control panel selection in step618.

In the next step620, the app sends a request to the applications server122of the central operation system118to receive event data for the selected control panel. Similar to the embodiment described with respect toFIG. 5, the on-site technician is then able to set event filtering options in step622.

FIG. 6Billustrates an example in which the on-site technician108is able to search for control panels by entering a partial serial number of the control panel102.

In the illustrated example, steps602through610are identical to steps602through610inFIG. 6A. After completing steps602through610, the on-site technician108enters a partial serial number of the control panel via app in step630to search for control panels.

Next, the partial serial number is sent to the central operations system118via the public network113as described in step632. In step634, the mobile computing device110receives a list of control panels matching the partial serial number. Typically, the list of control panels includes more than one control panel. Accordingly, the more digits of the serial number that are entered by the on-site technician108, the shorter the received list will be (in step634).

The on-site technician108then selects a control panel from the received list and receives specific panel information that corresponds to the selected panel in step636. The on-site technician108verifies the details of the panel presented on their mobile computing device110in step638.

In the next step640, the on-site technician108determines if the selected panel is the correct control panel. In the case of a correct control panel, in step642, the app sends a request to the applications server122of the central operation system118to receive event data for the selected control panel. Similar to the embodiments described with respect toFIGS. 5 and 6A, the on-site technician108is then able to set event filtering options in step644.

In the case of an incorrect panel, the on-site technician108returns to step634and selects another panel to review. Additionally, while not shown in the illustrated example, the on-site technician108may return previous steps (e.g., to step630) to enter a full panel serial number.

FIG. 7is a sequence diagram900illustrating how the mobile computing device108, fire detection and fire annunciation devices109-1to109-n, control panel102, testing computer104, central operations system118(applications server122), and data storage system124interact during the test.

In a first example (labeled Device 1 Test), the on-site technician108activates one of the fire detection and fire annunciation devices109-1to109-nof the fire alarm system100. The activated device sends an electronic signal to the control panel102. The control panel generates event data, which are sent to the testing computer104. If the control panel102has the acknowledgement (ACK) feature enabled, then the testing computer104provides an immediate ACK to the control panel102to silence the local and remote sounders connected to the control panel102. The event data are then sent from the testing computer104to the applications server122of the central operations system118, which stores the event data in the data storage system124. The central operations system118then sends the event data and device history data to the mobile computing device110.

In the illustrated example, the on-site technician108reviews the event data and optionally applies annotations to the event data. These annotations typically include a pass or fail status, images, and/or voice and text messages, to list a few examples. For example, if the fire detection or fire annunciation device appears worn or damaged, the technician would annotate the event data with an image of the device. The annotated event data are then sent back to the central operations system118and stored in the data storage system124. This annotated device history may be accessed later by the on-site technician108, a remote technician130, or other users that are authorized to access the event data.

A second example (labeled Device 2 Test) illustrates a scenario in which the mobile computing device110temporarily loses communication with the central operations system118. In general, the testing process is similar to the previous example (i.e., Device Test 1). In this example, however, the mobile computing device110temporarily loses communication with the central operations system118. Because communication has been lost, the transmission of event data from central operations system118fails to reach the mobile computing device110. In the illustrated example, this is shown by the “X.” In a current implementation, if there is a failed transmission, the central operations system118buffers and attempts to resend the event data. This event data could be resent based on a request from the mobile computing device110or the central operations system118could attempt resend the event periodically until event data are received and acknowledged by the mobile computing device110.

The sequence diagram900further illustrates a report request from the on-site technician (labeled Report Request). Typically, reports are generated after the on-site technician108has completed the test of the entire fire alarm system100, but the on-site technician108(or a remote technician130) could request a report at any time before or during the test.

In the illustrated embodiment, the on-site technician108sends a report request to the central operations system118. The central operations system118queries the data storage system124to obtain an aggregate history for all of the fire detection and fire annunciation devices of the fire alarm system100. The aggregate history data are transferred to the mobile computing device110and reviewed by the on-site technician108. The on-site technician108may then add annotations to the aggregate history data and send the annotated aggregate history data to central operations system118.

Additionally, the sequence diagram900also illustrates how the system handles an unsolicited or “real” alarm (labeled Unsolicited Alarm). While the illustrated embodiment distinguishes “real” alarms from technician activated alarms, these differences are only for illustrative purposes. In a typical implementation, the control panel102does not distinguish between “real” and technician activated alarms.

Upon receiving a “real” alarm signal, the control panel102generates event data, which is sent to the testing computer104. The testing computer104sends the event data to the central operations system118, which records the event data in the data storage system124and immediately sends the event data to the mobile computing device110of the on-site technician108.

Upon receiving the event data for the unsolicited alarm, the on-site technician108is able to see and identify the unsolicited alarm. In the event that the unsolicited alarm represents a real emergency or threat to life and/or property, i.e., an actual fire, for example, the on-site technician generates an alarm condition command that is sent to the central operations system118. The central operations system118sends an alarm condition command to the testing computer104, which communicates the command to the control panel102. The control panel102is then able to activate the audio and visual alarms/warnings of the fire annunciation devices to warn the building occupants of the possible emergency.