应急照明控制器自检移交检查

围绕应急照明控制器的主备版本、自检计划、故障上报、消音复位和恢复闭环核验，避免把面板能报警误当成系统逻辑已经一致。

应急照明控制器最容易留下的假象，是“主机会报故障，面板也能消音，所以逻辑大概已经没问题”。真正会把麻烦拖到移交后的，往往不是完全没报警，而是主备控制器自检计划不一致、故障消除后状态没有恢复干净、平台和本地面板显示不同步，或者回路映射已经改过但控制器仍沿用旧逻辑。

这篇内容只处理 控制器自检逻辑一致性 这条线，不替代 应急照明切换模块验收不要只做一次断电试验 的主备切换动作，也不重复讲 应急照明端部强制恢复检查 的末端对象验证。它只回答一句话：这套控制器在计划自检、人工自检和故障恢复这三层逻辑上，到底是不是一套完整闭环。

如果你当前先要把“今天到底是哪台控制器、主备版本是不是同一版、计划任务和人工自检做到哪一步、消音复位和平台回写退到哪一步”统一成一条现场口径，先用 应急照明控制器自检移接口径单。先把这一轮逻辑边界锁住，再回写正式记录，现场会稳很多。

如果当前争议并不是控制器计划、人工自检和故障恢复逻辑，而是 某一只切换模块到底带哪条回路、主备切换怎么走、恢复回切和旁路清理做到哪一步，先用应急照明切换模块主备回切口径单。先把模块级边界锁清，再回来看控制器逻辑，会少很多假问题。

什么情况下必须先查控制器自检

• 同一系统里主机和备机近期改过参数、升级过版本或更换过控制板。
• 计划自检会报警，但人工触发结果和平台显示不一致。
• 故障已经消除，平台或面板仍长期挂状态。
• 交付前需要把值班逻辑讲清，但现场只能凭经验解释告警。

如果当前主要问题是主电切换和恢复回切，先去看切换模块页；如果问题是某一批末端灯具强启后回不到自动，先去看末端恢复页。

先把四个基础对象锁清

1. 主备控制器版本：主机、备机和上位平台的版本口径是否一致。
2. 自检计划：计划自检的时间、范围、周期和优先级是否一致。
3. 回路映射：控制器对象名、回路编号和现场标签是否已经同步到同一版本。
4. 故障类别：灯具故障、通信故障、电源故障和模块异常是不是按目标逻辑上报。

没有这四项的统一口径，后面的自检结果很容易变成“看上去都测过，但没人能解释为什么结果不一样”。

自检不要只测“会不会报”

先做计划自检核验

• 核对计划自检的时间表和触发范围，不要只看当天有没有自动跑过。
• 确认主机、备机和平台侧看到的是同一轮计划，不是各自保留旧计划。
• 若系统支持导出计划参数，优先导出留底，不要只拍几张界面图。

再做人工自检核验

• 人工触发时，同时看控制器、本地面板、平台和现场回路状态。
• 不只确认“报上来了”，还要确认报码对象、故障类型和恢复路径是否正确。
• 对关键分区至少抽查几个典型对象，不要只在最容易通过的区域做演示。

最后做故障恢复闭环

• 自检完成后，故障位、确认位、消音位和恢复状态都要回到正式值守口径。
• 如果消音后平台仍挂故障，或者本地恢复后平台未清，说明逻辑闭环并没完成。
• 恢复动作要看“状态有没有回去”，不只看“声音有没有停”。

它和切换模块、末端恢复怎么分开

• 这篇负责 系统逻辑是不是一致。
• 应急照明切换模块验收不要只做一次断电试验 负责 主备供电路径切得稳不稳。
• 应急照明端部强制恢复检查 负责 具体末端对象对不对、恢复干不干净。
• 应急照明月检抽测看板指南 负责 运维期问题会不会重复出现。

很多现场的问题不在“哪一条线没做”，而在把四条线混成一次笼统联调以后，谁也说不清当前到底证明了什么。

最容易出现的假闭环

• 主机改过参数，备机沿用旧版。
• 只测消音，不测复位和恢复。
• 平台上报码正常，就默认现场回路映射也正确。
• 回路或标签改过后，不同步更新控制器对象命名。
• 自检做完不留计划版本和人工触发证据，后续无法对比。

资料怎么留最稳

• 先用 应急照明控制器自检移接口径单 把当前控制器编号、版本基线、自检任务和恢复回归统一成一条可复制文本。
• 主记录再接 应急照明控制器自检逻辑记录。
• 涉及回路对象、图纸标签和现场命名不一致时，先用 图纸核对清单 收口，再继续联调。
• 若本轮同时做了切换模块或末端强启，应把证据分别挂到对应模板，不要混在同一条自检记录里。

关联页面

• 主备切换、恢复回切和模块编号问题，继续看 应急照明切换模块验收不要只做一次断电试验。
• 末端对象强启与自动恢复问题，继续看 应急照明端部强制恢复检查。
• 运维期趋势和重复异常，继续看 应急照明月检抽测看板指南。