FSU入网操作指引：动环监控资源编码、点表核对与告警穿越

简介：《中国铁塔中兴力维综合监控FSU入网操作指引》面向铁塔及动环监控运维人员、系统集成与网管建设人员，围绕综合监控前端设备（FSU）接入动环监控系统的标准化流程，解决设备入网配置项多、数据字典与资源信息关联复杂等问题，适合作为现场开通与排错参考。文档按账号基础信息、信号量字典表、资源信息配置展开，覆盖站点、铁塔、机房、FSU、蓄电池、开关电源、外市电接入及交直流配电、空调、油机、摄像头、红外、烟感、温感、水浸、门磁等对象，并呼应精细管理、智能控制与共享运营的建设目标。压缩包仅含1个doc文件，约12.09MB，便于随查随用。已有5485人学习，可帮助读者理清FSU入网步骤、字段填写与资源关联关系，形成可执行的接入清单。

1. 一台 FSU 上线返工三次之后：这份入网指引到底管什么

去年冬天跟的一个站，设备半小时就装完了，录入折腾了两天。综合监控FSU 明明在线，平台上蓄电池单体电压就是不刷新，值班同事以为设备坏了，让厂家二次上站，最后发现是信号量字典表用的还是上一版，点号和现场实采的 AI 量根本对不上。这属于典型的“设备没问题、数据没落地”，也是动环监控入网最常见的翻车方式。

这份《FSU 入网操作指引》（V0.2 试行版）管的就是这件事：把账号开通、组织与权限、信号量字典表、站址到设备的资源录入、OMC 与在线检查、告警穿越、割接收尾这一整条链路固定成标准动作。它适合三类人——负责批量上线的集成实施人员、给厂家做验收的运维岗、以及刚接手动环、第一次独立跟站的人。它不是产品手册，更像一份“顺序错了就得二次上站”的作业规程，下面按我实际复现的节奏拆开。

2. 五层资源模型的先后顺序：站址、铁塔、机房、FSU、设备为什么一级都不能跳

2.1 五层资源模型和自动编码的生成链条

动环监控这条链路，前端是 FSU，负责把机房里的模拟量、开关量采上来；中间是接入与收敛层；上层是综合监控平台，负责呈现、告警和派单。FSU 本身不产生业务价值，它的价值全在“挂在什么地方”——平台靠一条设备编码，把一路遥测值定位到某个站址、某个机房里的某台设备上。编码对不上，数据就是一堆没有归属的浮点数。

平台里的资源是一条严格的父子链，方向是站址 → 铁塔 → 机房 → FSU → 挂接设备。这条链决定了自动命名和自动编码的生成逻辑，也决定了下级记录的必填外键：

看清这张表就知道顺序为什么不能反：FSU 的名称默认由所属机房生成，机房编码由站址和机房类型拼出来，铁塔名称由站址加铁塔类型拼出来。上级没建，下级要么选不到外键，要么只能先挂个空壳，等机房建完再回来改。改一次不致命，改十次就是事故。

2.2 六个阶段：从账号到告警穿越的完整链条

整份指引拆开看是六个阶段，每个阶段都有明确的产出物，缺一个后面就得回头补。

第一段是账号与组织。先在组织树上建厂家部门，再建运维人员账号和厂家维护账号，产出是“谁能登、能看哪个区域、能动哪些设备”。

第二段是信号量字典表确认。把平台下发的字典表和现场 FSU 的实采点表逐点对齐，产出是一份点号、类型、单位、门限全部一致的映射关系。这一步必须在设备上站之前完成，因为点表是 FSU 配置文件的输入。

第三段是站址、铁塔、机房三级资源录入，产出是三个自动生成的编码，这三个编码要带到现场。

第四段是 FSU 本体录入，经纬度、厂家、尺寸、功率、接口数，产出是 FSU 设备编码。

第五段是挂接设备录入，蓄电池、开关电源、外市电、交直流配电、变压器、空调、油机、摄像头、红外、烟感、温感、水浸、门磁、门禁、智能电表，一共十四类，产出是每台设备的独立编码。

第六段是检测与验收，OMC 检查、FSU 在线、地图定位、拓扑、实时视频、性能指标、设备告警，最后跑一遍告警穿越测试。

提示：第三、四、五段可以在平台上先建好再上站，但编码必须在设备上站前就确定下来并写进 FSU 配置文件，否则现场配完还得回来对齐。

2.3 返工代价：编码不是自增 ID，是现场配置的一部分

很多人把平台上的资源删掉重建当作家常便饭，觉得重新点几下鼠标而已。在动环这套体系里，这个动作的代价比想象中大。

设备编码是 FSU 配置文件的一部分。现场调试时，厂家工具里填的是站址编码、机房编码、设备编码，FSU 采到数据后按编码打标签往上送。平台上把机房删了重建，编码变了，现场那份配置就成了孤儿，数据要么被丢弃，要么落到一个已经不存在的父节点下面，平台侧表现为“设备在线但无数据”。

历史数据是按编码归档的。删除重建之后，新旧编码之间的性能曲线断成两截，查历史负荷、查某次停电前后的电池电压走势，中间那段就是空的，事后想补也补不回来。工单和告警记录同理，派单记录关联的是旧编码，你点进去看到的是一个已删除的设备。

真实的二次上站成本，是车费、工时、协调开门、厂家配合，再加上一次排期。一个站多花半天，一批站就是几周。所以我在做批量上线时，宁可前期在表格上多花两小时，也不在平台上做删除重建。

2.4 上站前我一般准备的三份基础表

第一份是设备清单，对应《FSU 监控设备信息采集表》，按机房把现场实际存在的设备逐条列出来，标注哪些是必录、哪些是可选。这份表是第五段录入的唯一依据，现场没有的东西不要预先建，建了就是空挂，后面统计设备在线率会一直拖后腿。

第二份是点表。平台字典表导出一份，厂家配置工具导出一份，两份放在一起做交叉核对。我的习惯是先核对点号，再核对点类型，最后核对单位和门限，顺序不能反，因为点号不对后面全是白忙。

第三份是编码预留表。站址编码、机房编码、FSU 设备编码先在小表里列好，现场调试直接照着填。这份表看着土，但它是唯一能防止“现场填错一位数字”的手段，尤其是在同时开多个站的时候。

3. 账号、权限与信号量字典表：把点表对上，比装设备更花时间

3.1 运维人员、厂家账号与部门权限的继承规则

账号配置走的是“系统管理 → 组织管理”，两个动作：新增部门和新增用户。

运维人员账号建在运营方自己的组织节点下，关键字段是用户名、登录账号、用户类型，然后单独设操作权限。这里有个容易被忽略的点：用户类型决定了这个人能看到哪些菜单，操作权限决定他能改哪些数据，两者是叠加关系，不是替代关系。新人入职只配了用户类型没配操作权限，表现就是“能登录、点进去全是灰的”。

厂家账号要先建部门。在组织树里建一个厂家部门，部门类型选“部门”，然后把操作权限和数据权限分配到这个部门上。厂家联系人作为用户挂在部门下面，用户类型选“第三方供应商维护人员”。关键在于：如果不给这个用户单独分配权限，它默认继承部门权限。所以我一般把权限配在部门这一层，人员只做挂接。这样做的好处是人员流动时不用逐条清理，人走了账号停用，部门权限还在，换个人挂上去就行。

注意：给厂家账号的数据权限要按区域划，不要图省事给全量。全量数据权限意味着对方能看到所有站址的设备清单和告警，这属于越界。

3.2 信号量字典表：点号就是这套系统的映射依据

字典表在附件里，是一份 Excel，名字里带版本号和日期。它的作用是把“协议地址”翻译成“业务含义”。FSU 从设备上读到的是寄存器地址、线圈地址、对象标识，平台需要知道 0x0A 这个地址代表的是“1 号电池组单体 3 电压”还是“市电 A 相电压”，这个翻译关系全部写在字典表里。

字典表的常见字段和踩坑点：

蓄电池这块尤其要注意单体电压等级。一组 48V 电池，用 2V 单体是 24 节，用 12V 单体是 4 节，采集模块的通道数和点表条目数完全不同。字典表按 2V 配、现场装的是 12V 电池组，结果就是后 20 个点全是空值，看起来像采集模块坏了。

3.3 用脚本核对点表与现场实采点

人工对两张表，几十个点还行，上千个点必然出错。我一般写个小脚本做交叉核对，输出三个清单：平台有现场没有、现场有平台没有、类型或单位对不上。

# point_audit.py —— 平台字典表与现场实采点表交叉核对 # 用法: python point_audit.py 字典表.csv 现场点表.csv import csv import sys # 两张表列名不同，这里做映射，按实际表头改这三组常量 KEY_DICT, KEY_REAL = "点号", "point_no" TYPE_DICT, TYPE_REAL = "点类型", "type" # AI/DI/AO/DO，统一转大写比对 UNIT_DICT, UNIT_REAL = "单位", "unit" def load(path, key): """把点表读成 {点号: 整行字典}，点号去空格并转大写""" data = {} with open(path, newline="", encoding="utf-8-sig") as f: for row in csv.DictReader(f): k = (row.get(key) or "").strip().upper() if k: data[k] = {kk: (vv or "").strip() for kk, vv in row.items()} return data def main(dict_path, real_path): plat = load(dict_path, KEY_DICT) real = load(real_path, KEY_REAL) only_plat = sorted(set(plat) - set(real)) # 平台定义了，现场没采：多是厂家漏配 only_real = sorted(set(real) - set(plat)) # 现场采了，平台没定义：数据会被丢弃 type_diff = sorted(k for k in set(plat) & set(real) if plat[k][TYPE_DICT].upper() != real[k][TYPE_REAL].upper()) unit_diff = sorted(k for k in set(plat) & set(real) if plat[k][UNIT_DICT] != real[k][UNIT_REAL]) print(f"字典表点数={len(plat)} 现场点数={len(real)}") print(f"[仅平台有] {len(only_plat)} 条: {only_plat[:20]}") print(f"[仅现场有] {len(only_real)} 条: {only_real[:20]}") print(f"[类型不一致] {len(type_diff)} 条: {type_diff[:20]}") print(f"[单位不一致] {len(unit_diff)} 条: {unit_diff[:20]}") # 有任何不一致就返回非零，方便挂到上线检查脚本里当门禁 return 1 if (only_plat or only_real or type_diff or unit_diff) else 0 if __name__ == "__main__": sys.exit(main(sys.argv[1], sys.argv[2]))

这段代码的逻辑很直白：先把两张表都读成以点号为键的字典，再做集合运算。only_plat是平台有而现场没有采的点，通常是厂家配置工具里漏勾了通道；only_real是现场采了但平台没定义的点，这类数据送到平台会被直接丢弃，不会报错，属于最难查的一种。type_diff抓的是遥测配成遥信这类错误，unit_diff抓的是单位或变比不一致。

三个常量按实际表头改就行，KEY_*是点号列名，TYPE_*是类型列名，UNIT_*是单位列名。编码用utf-8-sig是为了兼容 Excel 导出的带 BOM 的 CSV。返回非零退出码是我自己的习惯，这样可以把脚本串进上线前的自动检查里，任何一项不一致就直接阻断，不靠人眼看。

3.4 字典表版本管理的三条硬规矩

第一条，版本号必须和文件名绑定。字典表文件名里带版本和日期，我在设备清单和验收记录里都写同一个版本号，出现问题能立刻定位到是哪一版。

第二条，字典表变更必须走变更记录。加一个点、改一个门限都记一笔，写清改了哪条、为什么改、影响哪些已上线的站。没有变更记录的字典表，三个月后没人说得清某个门限是谁改的。

第三条，平台侧和现场侧的字典表必须同源。现场配置工具从平台字典表导出，不允许厂家自己另起一份。这条说起来简单，做起来最容易破防，因为厂家往往有自己的一套点表模板，图省事直接拿来用，结果就是点号全对、含义全错。

4. 十四类设备录入实操：从蓄电池单体电压到门禁的字段清单

4.1 站址、铁塔、机房三级：先把命名和编码定下来

站址是整条链的根，菜单在“网络监控 → 资源管理 → 站址信息”。关键字段是名称、类型、所属区域、基站状态，保存后系统自动生成站址编码。所属区域这个字段直接决定了后续的数据权限归属，填错了运维人员在自己的区域里就看不到这个站。

铁塔信息在“资源管理 → 铁塔管理 → 铁塔信息”，字段是铁塔名称和所属站址。铁塔名称会根据站址和铁塔类型自动拼出来，可以改，但我不建议改，因为改了之后和站址的对应关系在列表里就不直观了。保存后生成铁塔编码。

机房信息在“资源管理 → 机房信息”，字段多一些：名称、类型、等级、楼层、列数、行数、编码、铁塔名称、机楼名称。机房编码根据站址和机房类型自动生成。这里有个细节，列数和行数是给机架布局用的，填错了不影响监控，但影响后续的巡检路径和容量统计，所以能填准就填准。

提示：一个站址下可能有多个机房，机房类型要区分清楚，因为不同类型机房的编码规则不同，混填会导致编码重复。

4.2 FSU 本体：经纬度和接口数是最容易埋坑的两个字段

FSU 录入在“动环监控 → 铁塔监控”。字段包含名称、类型、所属铁塔、经度、纬度、厂家信息、长宽高、功率、接口数、详细地址。名称根据机房自动生成，可以修改，保存后生成设备编码。

经纬度是最容易出问题的一项。常见错误有三种：填成度分秒格式、直接抄站址中心点、复制上一个站忘了改。第一种会导致地图定位偏移几百米到几公里，后两种会导致多个 FSU 叠在一个坐标上。地图定位这个功能在排障时很有用，坐标不准等于没有。

接口数决定了这台 FSU 能带多少路设备。蓄电池单体采集占一路、开关电源一路、空调一路、环境量一路，录少了不影响当前运行，但后续扩容时平台会按接口数做校验，超了就加不上去。功率和尺寸是给机房容量统计用的，我一般要求现场按铭牌填，不按经验估。

4.3 电源类设备：蓄电池和开关电源的字段最密

蓄电池在“资源管理 → 蓄电池”，字段包括名称、类型、型号、生产厂商、单组额定容量、单组蓄电池个数、单体电压等级、是否漏液、电池支撑部位是否有沉重坍塌变形、外观有无变形、连接铜排有无腐蚀、状态、固定资产编号。名称根据机房自动生成，保存后生成设备编码。

这一串字段看着像巡检表，其实是告警策略的输入。单体电压等级决定了单体采集的通道数和告警门限，单组个数决定了组电压的计算基准。外观类的几个字段只有在首次录入时填，后续靠巡检更新，但首次录入不填，这批数据就永远是空的。

开关电源字段同样密：类型、设备数、整流模块型号、高效整流模块总数、普通整流模块总数、监控模块型号、剩余槽位数、防雷模块指示是否正常、额定输出电压、能否二次下电、告警指示灯状态、模块功能是否正常、监控显示屏是否正常、固定资产编号。其中“能否二次下电”直接决定告警级别怎么配——能二次下电的站点，一次下电告警可以定成重要，不能二次下电的，一次下电就得定成紧急，因为没有退路。

交流/低压配电设备的字段是型号、总容量、输出端口总数、空闲端口数、使用状态、生产厂商。直流配电设备是型号、总容量、熔丝已使用数量、未使用熔丝数量、生产厂家、品牌。这两类设备的核心是容量和端口占用，做扩容评估时全靠这两个数。

4.4 环境安防类：空调、油机、烟感、水浸、门禁

空调字段简单：名称、型号、类型、生产厂商、状态。但类型要区分清楚，是普通单冷、还是带来电自启的，还是双机切换的，因为后两种在断电恢复后的行为完全不同，值班判断时要看这个。

油机看油位和启动电池电压两路，油位是模拟量，启动电池电压也是模拟量，这两个点如果没配进字典表，油机基本上等于没监控。

烟感、温感、水浸、红外、门磁、门禁这几类都是开关量为主。烟感和温感通常共用一路环境采集，水浸和门磁各占一路。门禁比门磁复杂，多了刷卡记录和开门权限，接入时要注意它上报的是事件不是状态，点表配置方式不一样。摄像头的字段主要是类型、厂家、IP 和通道号，实时视频检测在验收阶段要单独过一遍。

智能电表是可选但强烈建议录的一类，它给的是分项能耗，没有它，站点的用电分析就只能靠估算。

4.5 录入数据的批量预校验

十四类设备、几十个字段，靠人眼查必填项和关联关系不现实。我一般把平台导出的资源表拉到本地跑一遍校验，重点查四件事：必填为空、经纬度越界、机房不存在于站址下、一个机房挂了多台在用 FSU。

# res_check.py —— 资源导入前的批量预校验 import pandas as pd SITE = pd.read_excel("资源导入模板.xlsx", sheet_name="站址") ROOM = pd.read_excel("资源导入模板.xlsx", sheet_name="机房") FSU = pd.read_excel("资源导入模板.xlsx", sheet_name="FSU") def check_required(df, cols, name): """必填列不允许为空，返回带行号的清单方便回填""" miss = df[df[cols].isna().any(axis=1)] if not miss.empty: print(f"[{name}] 必填缺失 {len(miss)} 行: {list(miss.index[:10])}") check_required(SITE, ["站址名称", "所属区域", "基站状态"], "站址") check_required(ROOM, ["机房名称", "所属站址", "机房类型"], "机房") check_required(FSU, ["FSU名称", "所属机房", "经度", "纬度", "厂家"], "FSU") # 经纬度通用范围校验，超出必然填错格式 bad_geo = FSU[(FSU["经度"].abs() > 180) | (FSU["纬度"].abs() > 90)] print(f"[FSU] 经纬度越界 {len(bad_geo)} 行") # 外键：机房的所属站址必须在站址表里 orphan_room = ROOM[~ROOM["所属站址"].isin(SITE["站址名称"])] print(f"[机房] 站址不存在 {len(orphan_room)} 行: {orphan_room['机房名称'].tolist()[:10]}") # 外键：FSU 的所属机房必须在机房表里 orphan_fsu = FSU[~FSU["所属机房"].isin(ROOM["机房名称"])] print(f"[FSU] 机房不存在 {len(orphan_fsu)} 行: {orphan_fsu['FSU名称'].tolist()[:10]}") # 一个机房正常只挂一台在用 FSU，多台要人工确认是不是双机或历史遗留 dup = FSU.groupby("所属机房").size() print(f"[FSU] 单机房多台: {dup[dup > 1].to_dict()}")

逻辑分四步：先做必填校验，把空值行号打出来，方便回表格里补；再做经纬度的通用范围校验，abs(经度)>180或abs(纬度)>90必然是格式填错；然后做外键校验，机房挂的站址、FSU 挂的机房必须真实存在，这一步抓的就是“先建下级后建上级”留下的孤儿记录；最后做一对多检查，一个机房正常只挂一台在用 FSU，出现多台要么是双机热备，要么是旧设备没拆干净，必须人工确认。

sheet_name按实际模板改，列名同理。这个脚本我在导入前必跑一遍，比导进去再一条条改省事得多。

5. 五个高频翻车现场：编码、点号、经纬度、派单和割接

上面几章讲的是“应该怎么做”，这一章讲的是“实际会怎么坏”。下面五条都是我在跟站过程中反复遇到的，按“现象 → 原因 → 解决”记下来。

5.1 设备在线、数据全零或不刷新

现象：平台显示 FSU 在线，拓扑能展开，但某台设备的所有遥测值长期是 0 或者停在某个固定值，点进去看采集时间是新的。

原因：九成是字典表里的点号和现场实采点对不上。FSU 采到的数据按点号打标签上传，平台按字典表翻译，点号错一位，数据就落到一个没人看的点上，或者被平台当成未定义点直接丢弃。另一种可能是点类型配错了，遥测配成遥信，数值就只剩 0 和 1。

解决：用 3.3 的脚本做一次全量交叉核对，重点看“仅现场有”这一栏。如果是类型问题，改字典表后必须重新下发 FSU 配置，光改平台侧没用。核对完之后把这一次的字典表版本记进验收记录，后面再出问题直接比对版本。

5.2 设备编码重复或出现孤儿设备

现象：平台上同一台设备出现两条记录，或者点某台设备进去，父节点显示为空；统计报表里设备总数比实际多。

原因：资源录入的顺序反了。先建了设备后建机房，机房建成后设备的外键没更新；或者机房删掉重建，编码变了，原来挂在上面的设备成了孤儿。还有一种情况是两个人同时录同一个站，各自建了一遍。

解决：先跑一遍孤儿检查。下面这段 SQL 是思路，表名按各自平台的实际命名替换：

-- 找出挂在不存在机房下的 FSU（孤儿记录） SELECT f.fsu_code, f.fsu_name, f.room_code FROM res_fsu f LEFT JOIN res_room r ON r.room_code = f.room_code WHERE r.room_code IS NULL; -- 找出同一机房下多台在用 FSU，人工确认是否双机 SELECT room_code, COUNT(*) AS cnt FROM res_fsu WHERE status = '在用' GROUP BY room_code HAVING COUNT(*) > 1;

第一条查的是孤儿 FSU，LEFT JOIN之后右表主键为空的就是挂不上父节点的记录。第二条查一对多，status字段按平台实际枚举值改。处理方式上，孤儿记录能改外键就改，不能改的走停用而不是删除，因为删除会连带清掉历史告警关联。

5.3 地图上 FSU 定位漂移几百米甚至跑到另一个站

现象：地图上的 FSU 点位和实际站址不重合，有的几个站点叠在一个坐标上。

原因：经纬度填了度分秒格式，比如把 116°23′45″ 直接写成 116.2345，实际差出去一大截；或者图省事抄了站址中心点，所有 FSU 都落在同一点；再或者批量录入时复制上一行忘了改。

解决：把 FSU 层的经纬度和站址层的经纬度做差值比对，差值超过阈值的逐条核对。修正时统一用十进制度，保留六位小数。地图定位不是花架子，现场排障时值班先看地图确认是哪台 FSU，坐标不准这一步就废了。

5.4 告警能上平台，但派不出单

现象：设备告警在监控界面上能看到，颜色、声音都正常，但待派工单里空空如也，工单流程走不起来。

原因：告警穿越测试没做。平台上的告警分两段，前一段是采集和呈现，后一段是派单规则、责任区域、值班班组。前一段通了不代表后一段通。常见的是告警等级没有对应到派单策略，或者设备所属区域没有绑定责任班组。

解决：按告警穿越测试的路径走一遍完整闭环——构造一个真实告警、确认平台收到、确认进入待派工单、确认派到具体人、确认处理完能闭环归档。这条路径必须每个告警等级都走一次，只测最高等级是不够的，因为低等级告警往往走的是另一套派单规则。

5.5 割接窗口内的告警暴涨

现象：FSU 割接上线的那一个小时，平台上冒出几百条告警，值班同事直接被淹没，真正的故障混在里面找不到。

原因：新设备接入瞬间，所有点从无到有，平台按门限逐条判断，本来就处于告警态的点会集中上报一次。加上割接前没有把站点挂维护态，这些告警全部走了正常派单流程。

解决：割接前把站点置为维护状态，告警照收但不派单；割接后逐台设备确认数据正常，再退出维护态。退出之后观察一个完整的上报周期，确认没有残留的抖动告警。割接窗口尽量避开用电高峰和雷雨时段，这个不是玄学，是真的会影响告警判断。

注意：这五条里，只有第 5 条能在割接窗口内补救，前四条都得在上站前解决。所以我把核对脚本放在了流程的最前面，而不是验收阶段。

6. 验收收尾技巧：告警穿越矩阵与割接窗口清单

验收这一步，我不看“平台上有多少设备”，只看“告警能不能走完整个流程”。做法是列一张告警穿越矩阵，横轴是告警等级（紧急、重要、次要），纵轴是设备类型（开关电源、蓄电池、空调、水浸、门禁、视频），每个交叉格都要有一条真实的测试记录。

跑完矩阵，再做一遍割接窗口清单：站点挂维护态、字典表版本锁定、编码表与现场配置比对、备用通信通道确认、值班联系人到位。这五项里我最看重第一项和第三项，前者防止告警风暴，后者防止上完线发现编码填错。

有个习惯我一直保留：每次割接结束、退出维护态之后，不立刻走人，而是盯十五分钟告警流，看有没有反复抖动的那种。抖动告警最消耗值班的信任，一次两次还能忍，一个站天天抖，后面真出事就没人看了。

从那以后我每次做批量上线，都强制走一遍“点表核对 → 编码预留 → 割接维护态”这三步，哪怕项目再急也不跳。急的时候跳过去的步骤，后面都会以二次上站的形式还回来。希望帮到你。

本文还有配套的精品资源，点击获取