第一章 消防报警系统概述

大家好，我是老张。干嵌入式消防这行快二十年了。今天咱们聊聊消防报警系统的基础。说实话，这个领域看着传统，但里面的门道真不少。我刚开始接触时也踩过不少坑，今天把这些经验分享给你们。

1.1 火灾报警系统的发展历程

火灾报警系统，说白了就是跟火抢时间的设备。最早的系统是什么样的？我给你们讲讲。

第一代：手动报警时代（19世纪末-20世纪初）

那时候哪有电子设备。就是墙上装个破玻璃罩，里面有个按钮。发现火灾了，砸碎玻璃，按下去。信号通过机械传动或者简单的电报线路传到消防站。嗯，就这么简单粗暴。我在一个老旧厂房改造项目里还见过这种古董，说实话，可靠性倒是不错。

第二代：多线制系统（20世纪50-70年代）

这个阶段开始用继电器和分立元件了。每个探测器单独拉一根线到主机。你想想看，一栋大楼几百个探测器，那线缆数量...我当年实习时跟着师傅布线，那叫一个头大。这种系统有个好处：故障隔离容易。坏处？成本高、施工难、维护更麻烦。

第三代：总线制系统（20世纪80-90年代）

这才是现代消防报警的雏形。用两根总线就能挂上百个探测器。每个设备有个独立地址，主机轮询访问。我记得第一次接触霍尼韦尔的NOTIFIER系统时，觉得这玩意儿太神奇了。两根线，搞定一切。后来我自己做嵌入式开发，就是受这个启发。

第四代：智能网络化系统（21世纪初至今）

现在呢？ARM处理器、嵌入式Linux、以太网、物联网...全都用上了。探测器本身就有MCU，能做信号处理、温度补偿、自诊断。主机之间还能联网，形成区域联动。我去年做的一个项目，整个园区32栋楼，全部通过光纤环网连接，响应时间不超过2秒。

1.2 系统组成与分类

一个完整的消防报警系统，我习惯把它分成三大部分：前端、传输、后端。咱们一个一个说。

前端设备

• 探测器：感烟、感温、感光、复合型。我特别提醒一下，选型时一定要注意环境因素。厨房里装感烟探测器？那等着天天误报吧。我曾经有个客户就这么干过，结果一个月误报27次，最后物业直接把报警器拆了。
• 手动报警按钮：就是那个红色的小盒子。国标要求每个防火分区至少一个。安装高度1.3-1.5米，这个尺寸我闭着眼都能说出来。
• 声光报警器：响的、闪的。分贝数有要求，室内不低于75dB，室外不低于100dB。我测试时习惯用声级计在房间最远端测，而不是贴着报警器测——那叫作弊。

传输部分

现在主流是二总线技术。两根线既供电又传数据。电压范围一般在24V左右，电流嘛，每个探测器静态电流不超过500μA。我设计电路时，习惯留30%的余量。为什么？因为线缆有压降，接插件有接触电阻，这些在实验室里测不出来，到了现场全暴露了。

后端主机

也就是火灾报警控制器。它负责供电、巡检、判断、联动。国标GB 4717对控制器有详细要求。我挑几个重点说说：

参数	要求	我的经验
主电容量	≥24小时连续工作	建议按36小时设计，留余量
备电时间	≥8小时	铅酸电池要定期维护，我吃过亏
回路容量	单回路≤200点	实际建议不超过160点，巡检周期有要求
报警响应时间	≤60秒	我设计的系统控制在10秒以内

1.3 国内外标准体系

做消防产品，标准就是命根子。国内主要看GB 4717系列，欧洲看EN 54，美国看UL 864。我简单对比一下：

GB 4717-2024《火灾报警控制器》

这是咱们自己的标准。2024年刚更新了版本。主要变化有：增加了物联网功能要求、提高了电磁兼容性指标、明确了数据存储要求。我参与过标准讨论会，说实话，咱们的标准现在跟国际接轨得不错，有些指标甚至更严。

EN 54《火灾探测和报警系统》

欧洲标准，分很多部分。EN 54-2是控制器，EN 54-7是感烟探测器，EN 54-11是手动报警按钮。欧洲标准有个特点：特别强调环境适应性。比如温度范围、湿度范围、盐雾测试，都比国标严。我有个产品同时过了GB和EN认证，说实话，EN的测试流程更繁琐，但确实能发现问题。

UL 864《火灾报警控制单元》

美国标准。UL认证在北美是强制性的。他们的特点是：文档要求极其严格。一份设计文档能写几百页。我当年帮一家深圳公司做UL认证，光修改文档就花了两个月。不过话说回来，文档写清楚了，后面生产、维护都省心。

1.4 嵌入式系统在消防中的应用

好了，终于说到咱们的老本行了。嵌入式系统在消防里无处不在。我给你们拆解一下：

探测器端的嵌入式设计

现在的智能探测器，里面都有一颗MCU。以感烟探测器为例：

// 典型的感烟探测器主循环伪代码
void main_loop(void)
{
    while(1)
    {
        adc_value = read_adc(CH_SMOKE);   // 读取烟雾浓度
        temp_value = read_adc(CH_TEMP);    // 读取温度
        
        // 温度补偿算法
        compensated = temp_compensate(adc_value, temp_value);
        
        // 判断是否报警
        if(compensated > ALARM_THRESHOLD)
        {
            if(confirm_alarm() == TRUE)    // 二次确认，防止误报
            {
                send_alarm(DEVICE_ADDR);
            }
        }
        
        // 自检
        if(check_self() == FAULT)
        {
            send_fault(DEVICE_ADDR);
        }
        
        delay_ms(500);  // 巡检周期500ms
    }
}

这段代码看着简单，但实际工程里要考虑的东西多了去了。比如：ADC采样要不要做均值滤波？温度补偿曲线怎么拟合？自检逻辑怎么覆盖所有故障模式？我第一版代码就栽在温度补偿上，夏天高温时老是误报，后来加了查表法才解决。

控制器端的嵌入式设计

控制器一般用ARM Cortex-M系列或者A系列。我习惯用STM32F4或者i.MX6。操作系统嘛，简单的用FreeRTOS，复杂的用嵌入式Linux。为什么？因为控制器要处理的事情太多了：

• 轮询所有探测器（实时性要求高）
• 处理报警逻辑（优先级最高）
• 管理联动设备（比如启动喷淋、关闭防火阀）
• 记录历史事件（要写Flash或者SD卡）
• 人机交互（触摸屏、按键、LED指示）
• 网络通信（CAN、以太网、4G）

通信协议的选择

消防系统内部的通信协议，我推荐用CAN总线或者RS-485。为什么不用以太网？因为消防系统要求高可靠性，以太网的交换机、路由器都是单点故障。而CAN总线是多主结构，一个节点坏了不影响其他节点。我做过一个对比测试：CAN总线在强电磁干扰下，误码率比以太网低两个数量级。

当然，现在也有用无线方案的。LoRa、NB-IoT都有应用。但说实话，我个人对无线消防还是持保留态度。电池供电、信号遮挡、同频干扰...这些问题在实验室里都能解决，到了现场就不好说了。我建议：能用有线尽量用有线，实在没办法再用无线，而且一定要做冗余设计。

本章小结

这一章咱们把消防报警系统的底子打了一遍。从发展历程到系统组成，从标准体系到嵌入式应用。说白了，消防报警系统就是一个高可靠性的实时控制系统。它的核心要求就三个字：不误报、不漏报、不延迟。

下一章我会详细讲探测器的工作原理和硬件设计。到时候咱们聊聊光电感烟探测器的光学迷宫怎么设计，离子感烟探测器为什么逐渐被淘汰，还有温度探测器的NTC选型技巧。这些都是实战经验，你们准备好笔记本。