GB 26875.5-2011Remote-monitoring system of urban fire protection - Part 5: Functional requirements for receiving software (English PDF)

Foreword

This document complies with the provisions of GB/T 1.1-2020 "Standardization Work Guidelines Part 1: Structure and Drafting Rules of Standardization Documents".

Drafting.

This document is Part 5 of GB (/T) 26875 "Urban Fire Remote Monitoring Systems". GB (/T) 26875 has the following published...

part.

---Part 1: General Technical Requirements;

---Part 2: Functional Requirements for Communication Service Software;

---Part 3: Alarm Transmission Network Communication Protocol;

---Part 4: Basic Data Items;

---Part 5: Software Functional Requirements;

---Part 6: Functional Requirements for Information Management Software;

---Part 7: Functional Requirements for Fire Protection Facility Maintenance and Management Software;

---Part 8: Monitoring Center External Data Exchange Protocol;

---Part 9: User Information Transmission Device;

---Part 10: Requirements for fire protection facility information collection devices and interfaces.

This document replaces GB/T 26875.5-2011 "Urban Fire Remote Monitoring System Part 5: Functional Requirements for Acceptance Software", and is consistent with...

Compared with GB/T 26875.5-2011, apart from structural adjustments and editorial changes, the main technical changes are as follows.

a) The scope has been changed (see Chapter 1, Chapter 1 of the 2011 edition);

b) The term "fire alarm information terminal" has been removed, as has the "functional requirements for the fire alarm information terminal receiving software" (see the 2011 version).

3.1, 5.3);

c) Delete the "Basic Requirements" section and incorporate its content into Chapters 4 and 5 (see 4.3, 4.5, 5.2, Chapter 4 in the 2011 edition);

d) The confirmation prompt function for the processing software has been modified (see 4.2, 5.1.5 of the 2011 version);

e) Requirements for the video information display interface and the associated operations between different interfaces have been added (see 4.3 and 4.6);

f) The software now includes functions for managing seat allocation for unaccepted information, accepting information on behalf of others, and transferring and pushing information (see 4.4);

g) Requirements for the display, query, monitoring, and processing of fire safety management information of networked units have been added (see 4.10);

h) Increased requirements for the display, querying, and processing of video surveillance information [see 4.11, 4.14c)];

i) Additional requirements have been added for information that requires manual processing by personnel (see 4.12);

j) The acceptance requirements for different types of received information have been changed (see 4.14~4.17, 5.2.4~5.2.7 of the 2011 version);

k) The requirements for information confirmation and record archiving have been changed, and the function of linking information records and audio/video records during the acceptance process has been added (see...).

4.15 (5.2.5 in the 2011 version);

l) The requirement to support manually sent commands has been changed (see 4.18, 5.2.8 of the 2011 version);

m) Added the ability to query information on fire protection facility inspections, emergency plans, fire protection facility maintenance, fire drills, and fire safety training.

Display and alarm requirements (see 4.19~4.21);

n) Added query, statistical, and analysis functions for multi-dimensional combinations of acceptance information (see 4.22);

o) Added functions for entering, editing, querying, and distributing notification messages (see 4.23);

p) The word "Test Methods" was changed to "Conformity Assessment" and the content was changed (see Chapter 5, Chapter 6 of the 2011 edition).

Please note that some content in this document may involve patents. The issuing organization of this document assumes no responsibility for identifying patents.

This document was proposed by the National Fire and Rescue Administration.

This document is under the jurisdiction of the National Fire Protection Standardization Technical Committee (SAC/TC113).

Introduction

Urban fire remote monitoring systems, as an important component of "smart city" and "smart fire protection" construction, play a crucial role in improving the completeness of building fire protection facilities.

It has played a positive role in improving the fire safety rate, enabling timely identification and rapid response to initial fires, and enhancing the fire safety management level of social units.

With the deepening of a new round of technological revolution and industrial transformation, a large number of new technologies, systems, and business models with higher security are emerging, and the Internet of Things (IoT) is becoming increasingly important.

High-tech technologies such as the Internet, cloud computing, big data, and artificial intelligence have been deeply integrated and applied in the fire protection field, and urban fire remote monitoring systems are keeping pace with the times.

The demand, through technological iteration, plays a vital role in reducing fire safety risks, and empowers the transformation and upgrading of fire protection work. In order to adapt to the information age...

The development of information technology will promote the implementation of the main responsibilities of social entities, enhance the social fire safety governance capabilities and urban risk monitoring and early warning capabilities, and improve the system.

GB (/T) 26875 "Urban Fire Remote Monitoring System" is ordered. GB (/T) 26875 is planned to consist of ten parts.

---Part 1: General Technical Requirements. The purpose is to specify the architecture and composition of urban fire remote monitoring systems and to clarify system functions.

Requirements related to energy, performance, and safety.

---Part 2: Functional Requirements for Communication Service Software. The purpose is to specify the functional requirements of the application support platform in the urban fire remote monitoring system.

The functions implemented by the messaging service software.

---Part 3: Communication Protocol between User Information Transmission Device and Application Support Platform. The purpose is to specify the communication protocol between the user information transmission device and the application support platform.

Transmission protocols between application support platforms.

---Part 4: Basic Data Items. The purpose is to define the basic data items included in an urban fire remote monitoring system.

---Part 5: Software Functional Requirements. The purpose is to specify the manual requirements for the support platform used in urban fire remote monitoring systems.

The functions implemented by the agent handling software.

---Part 6: Functional Requirements for Information Management Software. The purpose is to specify the functional requirements of the supporting platform used in urban fire remote monitoring systems.

The functions implemented by information management software.

---Part 7: Functional Requirements for the Maintenance Unit's Application Platform. The purpose is to specify the maintenance requirements for the urban fire remote monitoring system.

The functions implemented by the application platform of the nursing unit.

---Part 8: System External Data Exchange Protocol. The purpose is to define the data exchange protocol between the urban fire remote monitoring system and external information systems.

Data exchange protocol between them.

---Part 9: User Information Transmission Devices. The purpose is to specify the user information transmission devices in urban fire remote monitoring systems.

Functional and performance technical requirements.

---Part 10: Requirements for Fire Protection Facility Information Acquisition Devices and Interfaces. The purpose is to specify the requirements for fire protection facilities in urban fire remote monitoring systems.

Requirements for facility information collection devices and interfaces.

Urban fire remote monitoring system Part 5: Software Functional Requirements

1 Scope

This document specifies the functional requirements for the reception software used by human reception agents in the application support platform of the urban fire remote monitoring system.

And conformity assessment.

This document applies to the manual reception seats used by the application support platform in the urban fire remote monitoring system (hereinafter referred to as the "System").

The design, development and testing of software (hereinafter referred to as "software").

4 Functional Requirements

4.1 After the software starts running or after logging in, it should automatically enter the processing state.

4.2 The software should have operation confirmation prompts for parameter configuration, shift handover, on-duty/off-duty status switching, and exit.

4.3 The software interface should be displayed in Chinese and should include text, geographic, and video information. It should also display, but is not limited to, text, geographic, and video information.

The following information.

a) Information not accepted;

b) Date and time information;

c) Software version information;

d) Information on the receptionist and reception staff;

e) Information on whether the person handling the transaction is present or absent;

f) Communication connection status information.

In the above information, a) should not be covered.

4.4 When two or more agents are simultaneously online processing information, the software should have functions for assigning unprocessed information to designated seats and for handling information on behalf of others.

It can transfer and push information functions.

4.5 There should be instructions on the acceptance process during information processing, and alarm prompts should be given for any violations.

4.6 The display interfaces for text information, geographic information, and video information should have associated operation functions. Newly received letters should be displayed on the text information interface.

When processing information, the geographic information display interface and video information display interface should automatically switch to the corresponding geographic location and video interface; in the geographic...

When performing a location operation on the text information display interface, the relevant location information should be able to be extracted into the text information display interface.

4.7 The software should be able to record and query the time of arrival and departure of service personnel, the handover time of service personnel, and the duty log, and should have operational functionality.

Log viewing functionality. The runtime log should include, but is not limited to, software startup and exit times, parameter configuration modification times and content, and software errors.

The system displays the time and content of notifications, as well as the time and status information of changes in communication connection status.

4.8 The software shall have a time synchronization function, and the time synchronization deviation shall comply with the provisions of GB/T 26875.1.

4.9 The software should be able to receive, display, process, and query the operational status information of fire protection facilities of networked units.

4.10 The software should be able to display and query fire safety management information of networked units, and be able to dynamically manage the fire safety management information of networked units.

Information is monitored and processed.

4.11 For systems that connect to networked units' video surveillance information, the software should be able to display and query the networked unit's video surveillance information and support access via the network.

The video surveillance information in the unit's fire control room enables the monitoring of personnel on duty. For information obtained through the system or this software using video...

The following information identified through frequency information analysis should meet the corresponding requirements.

a) Fire alarm information. The software processes the received fire alarm information from the fire protection facilities accordingly.

b) Fire safety management anomaly information. The software processes received information regarding fire facility malfunctions and anomalies, such as...

Personnel absent from their posts, damaging, misappropriating, or dismantling or disabling fire-fighting facilities without authorization, burying, enclosing, or obstructing fire hydrants, or occupying fire compartments.

Distance, occupation, blockage, or closure of evacuation routes, safety exits, fire truck access routes, etc.

4.12 The software should be able to display, process, and query alarm information identified by the software, as well as information pushed by various platforms within the system to the application support platform.

Other information processed manually by personnel, and the processing results can be tracked and recorded.

4.13 Upon receiving various types of information, the software should be able to drive the acoustic devices and display interface to emit sound signals and display prompts.

The alerts should be differentiated according to the priority (urgency) of the received information, with fire alarm information being the highest priority and its corresponding audible signal...

The audio signal and display prompts should be clearly distinguishable from other information, and their display and processing should take priority. The audio signal should be manually cancelable; when a new message is received, the audio should be canceled.

The signal should be able to restart. After the information is received, the corresponding audio signal and display prompt should be automatically cleared.

4.14 When receiving information on the operational status of fire protection facilities from networked units, the software should be able to analyze the real-time status and historical data of the fire protection facilities.

The analysis provides auxiliary judgment and processing functions through information classification, upgrading or downgrading of information levels, and displays, but is not limited to, the following.

a) Information received time, user name, address, contact person's name, telephone number, organization information, type of fire protection system or component, actual Information such as current state and historical state;

b) The geographical location information of the networked unit, the location information of fire protection facilities, and the location information of components within the building;

c) When a fire alarm is triggered in the networked unit and video surveillance information is connected, the user's video surveillance information should be automatically displayed.

4.15 The software should be able to confirm alarm information from fire protection facilities (such as fire alarms, combustible gas detection alarms, electrical fire monitoring alarms, etc.).

And record archiving; alarm response records for fire protection facilities during testing or maintenance should be able to be compared with actual alarm response records.

Records should be differentiated; information occurring during the information processing and confirmation process should be recorded, and should be able to be linked to voice call records occurring during the information confirmation process.

Audio and video recordings. one acceptance record can be associated with multiple audio and video records.

4.16 The software should be able to send confirmed information to the fire communication command system or other alarm response system of the networked unit's location through the application support platform.

The recognized fire alarm information should include, but is not limited to.

a) Name, address, and geographical location of the unit connected to the alarm network;

b) Contact person's name and phone number;

c) Building name;

d) Detailed location of the building where the alarm point is located;

e) Information of the personnel handling the application.

The software should be able to receive, display, and record confirmation times and personnel information returned by the fire communication command system or other alarm response systems;

An alert should be issued when communication fails.

4.17 The software should be able to process information such as fire protection facility malfunctions and anomalies in the following ways.

a) Pre-set processing. It can automatically process or push information to relevant departments or networked units based on pre-set conditions;

b) Timeout processing. For information that has not been processed by networked units or relevant departments within the specified time limit, remind the receiving personnel to process it.

The software should be able to query the above processing results.

Note. Information on fire protection facility malfunctions and abnormalities can be found in GB 25506 and GB/T 26875.10.

4.18 The software should support manual transmission of the following test commands to networked units.

a) Inspection order to test the online status of user information transmission devices;

b) Inspection order. to test the on-duty status of personnel in the fire control room of the networked unit.

The software should be able to issue an alert when a test fails, and should be able to record, display, and query the test results.

4.19 The software should have the function of querying and displaying fire protection facility inspection information and emergency plans of networked units. For units that fail to conduct inspections as required...

For networked units, the software should be able to issue corresponding alarm messages to remind the personnel in charge to handle the situation.

4.20 If the system connects to the network of units' fire protection facility maintenance information, the software should have the function of querying the network of units' fire protection facility maintenance information.

The software should provide inquiry and display functions. For networked units whose maintenance of fire protection facilities is about to expire or who have failed to perform maintenance on schedule, the software should issue corresponding alarm signals.

The message will be sent to the relevant personnel for processing.

4.21 If the system connects to networked units for fire drills and fire safety training information, the software should have the function of providing information on networked units' fire drills and fire safety training.

The software should include functions for querying and displaying training information. For networked units that are about to conduct or have failed to conduct fire drills or fire safety training on schedule, the software should provide...

Issue corresponding alarm information to remind the personnel in charge to handle the situation.

4.22 The software should have the functions of querying, statistically analyzing, and combining multi-dimensional information received, enabling the analysis of fire protection facilities, buildings, networked units, and areas.

Data and risk analysis from different dimensions, including domain, fire protection facility manufacturers, fire protection facility maintenance companies, and networked units, covering fire safety.

And visual presentation.

4.23 The software should have functions for entering, editing, querying, displaying, and distributing notification messages, and should be able to send messages automatically or manually in real time.

Enables batch and single-point distribution of notification messages.

5 Conformity Assessment

5.1 The user documentation for the software shall comply with the provisions of 5.2 in GB/T 25000.51-2016.

5.2 Conduct a conformity assessment of the software according to the requirements of Chapter 7 of GB/T 25000.51-2016, and verify whether the software's functions comply with Chapter 4.

The provisions of the chapter.