第1章消防报警系统概述

一、消防报警系统概述：系统组成、工作原理、行业标准与规范

各位同学，大家好。今天咱们开始第一讲。

做消防报警嵌入式开发，第一件事不是写代码，而是搞清楚你面对的是个什么东西。我见过不少新手，上来就啃芯片手册、调通信协议，结果连系统怎么工作的都没弄明白——嗯，这样很容易走弯路。

这一章，我就带你把消防报警系统的全貌看清楚。说白了，就是三件事：系统由什么组成、怎么工作、要遵守哪些规矩。

一个典型的消防报警系统，从嵌入式视角看，可以拆成四个层次。我习惯把它们叫作「感知层、控制层、通信层、显示层」。

这里我要特别强调一下感知层。你在项目中会发现，烟感探头采集到的原始信号，噪声非常大。我曾经在一个项目里，因为没做滑动平均滤波，结果系统在装修粉尘环境下疯狂误报——那叫一个惨。所以，传感器数据进MCU的第一件事，就是做软件滤波。

核心观点：消防报警系统的嵌入式固件，本质上是「实时采集 → 逻辑判断 → 可靠通信 → 准确显示」的闭环。任何一个环节出问题，后果都很严重。

系统的工作流程，其实就是一个状态机。我画过很多次这张图，今天用文字给你描述一下。

正常监视状态：MCU循环扫描回路上的每个探测器，读取AD值，判断是否超过预设阈值。这个循环周期，我一般控制在200ms以内。
预报警判断：当某个探测器连续3次（可配置）采样值超过阈值，进入预报警。这时候不会立即联动，而是启动确认计时器——说白了，就是再给你一次机会，防止误报。
确认报警：确认计时器超时后，如果依然超标，系统正式进入报警状态。这时候，MCU要做三件事：本地声光报警、上传报警信息到主机、启动联动逻辑（比如切非、启动排烟机）。
联动输出：根据预设的联动公式，控制输出模块动作。这里要注意，联动逻辑不能写死，必须支持现场编程。我见过有的厂家把联动逻辑硬编码在固件里，结果项目验收时改一次逻辑就要烧一次芯片——太痛苦了。

避坑指南：我曾经在一个项目中，把报警确认时间设成了5秒。结果消防验收时，检测人员用烟枪一吹，5秒后才报警，直接被判定不合格。后来我改成了2秒，并且把这个参数做成可配置项。记住：确认时间、灵敏度、联动延时，这些参数一定要留出配置接口。

做消防嵌入式开发，和做消费电子最大的区别是什么？

答案是：你的代码必须符合国标。消费电子出bug，最多重启一下；消防系统出bug，那是要出人命的。

国内消防报警系统主要遵循以下标准，我建议你把这些标准的PDF下载下来，放在手边常翻翻。

这里我重点说一下GB 4717-2005里和嵌入式固件直接相关的几条：

响应时间：从探测器报警到控制器显示，时间不能超过10秒。这意味着你的通信协议、数据处理、显示刷新，整个链路必须在10秒内完成。我一般给自己定的目标是5秒以内。
故障处理：当探测器发生故障（比如短路、断路），控制器必须在100秒内报出故障。所以你的固件里必须有定时巡检机制，我通常用1秒一次的巡检周期。
存储容量：控制器必须能存储至少1000条历史记录。这意味着你的Flash管理算法要靠谱，不能写几次就坏块了。

警告：千万不要以为标准只是参考。消防产品必须通过CCC认证（中国强制性产品认证），认证过程中会逐条测试标准里的指标。如果你的固件不满足，认证直接不通过。我见过一个团队，因为「故障上报时间」差了2秒，整个项目延期了3个月。

做了十几年消防报警嵌入式开发，我最大的体会是：这个行业，稳比快重要，可靠比花哨重要。

你想想看，一个消防报警系统，可能几年都不会触发一次真正的火灾。但一旦触发，它必须100%正确动作。所以，你的代码里不能有「大概率没问题」这种想法。每一个边界条件、每一种异常情况，都要考虑到。

我建议你在开始写代码之前，先花一周时间把GB标准通读一遍。把标准里对固件的硬性要求列成一张表，然后对照着去设计你的架构。这样做出来的产品，至少不会在认证环节翻车。

下一章，我会带你深入嵌入式固件的分层架构设计。咱们聊聊怎么把代码组织得既清晰又可靠。