简介：《中国铁塔中兴力维综合监控FSU入网操作指引》面向中国铁塔及代维单位的动环监控运维、工程实施人员，聚焦综合监控前端设备FSU接入网管系统时缺乏统一流程的问题，可作为设备开通、配置核对与故障排查的参考。压缩包内为1个doc文档，约12.09MB，内容按入网流程组织，从账号基础信息、信号量字典表到资源信息配置逐项展开，并细化站点、铁塔、机房、FSU、蓄电池、开关电源、外市电、交流/低压及直流配电设备等对象。文档还覆盖空调、油机、摄像头、红外、烟感、温感、水浸、门磁等监控点，便于读者理解参数定义、资源录入和现场核对要点。已有5485人学习，适合需要掌握标准化FSU入网步骤、提升开通效率与运维规范性的技术人员查阅。
1. FSU 入网不是接线活，是给设备办“户口”
现场最常见的一幕：FSU 上电、网口灯闪、本地调试口能读到数据，运维在综合监控FSU 列表里按设备编码一搜，搜不到。设备是活的，系统里却等于不存在。
FSU 入网这件事，难的不是把线接对，而是把设备的“身份”建对。站址、塔桅、机房、FSU、末端设备各有一层编码，编码由上级派生；信号量字典表决定 FSU 传上来的每一个字节被翻译成什么物理量、什么单位、什么门限。这两件事没做对，通着电也上不了线，上了线也看不出问题。
这份操作指引把顺序固定下来了：账号与组织、字典表、资源建模、上线检测、告警闭环。适合动环运维、集成调试、以及要给别人交付站点的现场工程师照着走。
2. 账号与组织架构：三层继承关系没搭对，登录进去就是一片空白
权限问题永远是入网第一道坎，而且它的表现极具迷惑性——不是报错，是“我没权限”四个字都没有，直接给你一个空的资源树。很多人第一反应是系统出故障了，其实是组织结构没建好。
2.1 为什么组织结构必须先于人员建
这类动环监控系统的权限模型基本都是“组织节点 + 角色 + 数据域”的继承式结构。用户挂在某个组织节点下面，如果没有单独分配权限，就默认继承该节点的操作权限和数据权限。操作权限管的是“这个按钮能不能点”，数据权限管的是“能看到哪几个片区的站址”，两套东西是分开配的，混在一起谈很容易配错。
先把部门建出来，再把用户挂在部门下，最后按需微调，这条路是顺的。反过来先建账号、后补部门，账号就会短暂处在“无归属”状态，数据域悬空，登录后资源树为空。更麻烦的是这种悬空账号在后续派单时找不到责任人，工单会一直卡在待派工单里。
常见做法是：拿到入网计划表之后，先按片区和厂商两个维度把组织树画出来，再往里填人。运维侧按片区切，厂商侧按厂家切，两棵子树分开，不要混挂。厂商账号挂在运维节点下面，权限会顺着继承链扩散，后面想收都收不回来。
2.2 运维人员与厂商账号是两套建法
菜单路径上两者是同一条：系统管理 → 组织管理 → 新增部门 / 新增用户。但字段和权限来源完全不一样，混着建是踩坑的起点。
| 对比项 | 运维侧账号 | 厂商侧账号 |
|---|---|---|
| 建在哪个节点 | 运营方对应的片区组织节点下 | 厂商部门节点下 |
| 用户类型 | 内部运维人员 | 第三方供应商维护人员 |
| 关键字段 | 用户名、登录账号、用户类型 | 用户名称（填厂商联系人）、登录账号 |
| 权限来源 | 直接分配 + 节点继承 | 默认继承部门，也可单独收紧 |
| 数据域 | 按负责片区划定 | 按承接站点范围划定 |
| 生命周期 | 长期有效 | 项目周期，割接完成后回收 |
两个细节值得单独拎出来说。第一，登录账号是全系统唯一的，不是部门内唯一，厂商简称重复的时候很容易撞号，建议用“厂商简称_姓名拼音”这种可读格式，别用工号，半年后没人认得出这是谁。第二，厂商账号的“用户名称”字段填的是联系人姓名，不是登录名，这两个字段在很多系统里长得像但用途完全不同，填反了不影响登录，但会影响告警短信和工单通知的接收人。
新建运维人员的操作顺序是：定位到目标组织节点 → 新增用户 → 填用户名和登录账号 → 选用户类型 → 保存 → 进权限设置分配操作权限 → 进数据权限设置勾选可见站址范围。厂商账号多一步：先在运营方根节点下新增部门，部门类型选“部门”，部门名称写厂商全称，然后在这个部门下新增用户。
2.3 最小授权与继承效果的三分钟验证
厂商账号建完必须验证，而且不能只看“能登录”。我一般按下面四步走，三分钟能跑完：
- 用新账号登录，看左侧资源树展开后是不是只剩授权的片区，多出来一个片区就说明数据域配宽了。
- 随便点开一个有权限的站址，试着编辑一个非关键字段再改回去，能保存说明操作权限到位。
- 再点开一个明确没授权的站址，如果还能进去，说明数据权限是“全选”状态没生效。
- 找一个已产生的历史告警，看这个账号能不能查、能不能确认、能不能派单，这三件事权限通常是分开的。
提示：厂商账号不要给“删除资源”和“账号管理”这两项权限。删资源是不可逆的，账号管理等于给了对方扩权的口子，这两条在任何项目里都不该开口子。
权限继承还有个坑：修改部门权限不会自动刷新已登录用户的会话，对方得退出重登才生效。现场经常出现“我明明改了权限他还是能看”的争执，十有八九是会话缓存。
3. 信号量字典表与资源建模：编码是派生出来的，顺序错了只能删了重录
如果说账号是第一道坎，资源建模就是最容易返工的一段。原因很简单——编码是逐级派生的，不是随便填的。
3.1 字典表先对齐，否则数据上来也是“裸数据”
FSU 采集到的是原始值，一个通道对应一个数字或一个开关状态。系统要把它翻译成“1 号电池组单体电压 2.31V”“市电中断”，中间靠的就是信号量字典表。字典表里至少要有这几类信息：信号量标识、信号量名称、数据类型（模拟量还是开关量）、单位、告警门限、上报方式。
字典表没对齐的典型后果是数据能上来但全是 0，或者数值对但单位差一个量级。要做的事是拿厂商提供的点位表，和运营方下发的字典表逐条比对，输出一张差异表。差异主要出在四个地方：
- 缺失项：厂商有点位、字典表里没有，这类数据会被直接丢弃。
- 标识冲突：两个不同测点用了同一个信号量标识，后写的覆盖先写的。
- 量纲不一致：温度到底是 0.1℃ 还是 1℃，电压是 V 还是 mV，差 10 倍是常态。
- 极性相反：开关量里 0 表示报警还是 1 表示报警，两边说反了，平时一切正常，一告警全乱。
这张差异表比任何文档都值钱，谈判、整改、验收都靠它。血泪经验是：差异表一定要在设备到货前就确认完，等现场装完了再改，改的是两边的配置，工作量翻三倍。
3.2 站点到 FSU 的四级录入顺序
顺序是固定的：站址 → 塔桅 → 机房 → FSU → 末端设备。每一级的编码都包含上一级的编码段，所以顺序一乱，后面全得推倒。
| 层级 | 菜单路径 | 关键字段 | 自动生成 |
|---|---|---|---|
| 站址 | 网络监控 → 资源管理 → 站址信息 | 名称、类型、所属区域、基站状态 | 站址编码 |
| 塔桅 | 资源管理 → 塔桅管理 → 塔桅信息 | 名称（按站点+塔型自动生成，可改）、所属站址 | 塔桅编码 |
| 机房 | 资源管理 → 机房信息 | 名称、类型、等级、楼层、行数、列数、所属机楼 | 机房编码 |
| FSU | 动环监控 → 塔桅监控 | 名称（按机房自动生成，可改）、类型、所属机房、经纬度、厂家、长宽高、功率、接口数、详细地址 | 设备编码 |
| 末端设备 | 资源管理 → 各设备子菜单 | 名称、型号、所属机房、生产厂商、固定资产编号 | 设备编码 |
这里有个容易误判的点：名称字段大多标注了“自动生成、可修改”，看着很宽松，但编码一旦保存就改不了了。所以录入前必须先把设备信息采集表填完整，现场一边看一边填的，返工率接近百分之百。我见过一个站点因为塔桅类型选错，导致下面三个机房的编码全部带错误前缀，最后整棵树删掉重录，花了两个小时。
3.3 供配电与配套设备的录入要点
末端设备分三类，录入时的关注点完全不同。
电力类包括外市电引入、交流/低压配电设备、直流配电设备、变压器/调压器、智能电表。这一类的核心是容量和端口数：交流配电要填总容量、输出端口总数、空闲端口数、使用状态；直流配电要填总容量、熔丝已用数量和未用数量。这些字段不是给报表看的，是给后续容量预警用的，端口数填错，扩容提醒就永远不触发。
电源保障类包括蓄电池、开关电源、油机。蓄电池的关键字段是单组额定容量、单组蓄电池个数、单体电压等级——这三个直接决定单体电压曲线的解析方式，填错了后台算出来的后备时长全是错的。开关电源要关注整流模块总数、剩余槽位数、能否二次下电，其中“能否二次下电”关系到停电时的负荷分级策略，是必填项里最容易被跳过的一个。
环境安防类包括空调、温感、烟感、水浸、红外、门磁、门禁、摄像头。这一类字段相对简单，但数量最多，最容易漏录。漏录的表现是拓扑图上少设备，而不是报错。
3.4 可选设备到底录不录
外市电引入、变压器/调压器、门磁这几项在指引里标了“可选”，实际项目里最纠结。我的判断标准很直接：有没有独立的监控测点。有独立测点、有独立告警的设备就录，只是物理上存在但没有采集通道的不录，录了也是空壳，反而在拓扑图上占位、干扰排查。
门磁和门禁还有个二选一的问题。低等级站点只装门磁，高等级站点装门禁，两者都装的情况要么是分期建设遗留，要么是重复投资。录入时按实际安装情况录，不要按设计图纸录，图纸和现场对不上是常态。
4. 上线后的六项检测：图标变绿不等于设备在网
设备录完、FSU 配置下发之后，很多人看到列表里状态变绿就认为完工了。绿只是心跳通了，离“能用”还差六项检查。
4.1 OMC 检查与在线情况检查
OMC 侧是网管和 FSU 打交道的第一个关口，要确认四件事：FSU 是否完成注册、通信端口是否可达、心跳周期是否在约定范围内、软件版本是否在受控清单里。版本这一项经常被忽略，不同版本的 FSU 对同一张字典表的解析行为可能不同，混版本上线后会出现“同一型号设备数据格式不一样”的玄学问题。
在线情况检查不要只看状态图标，要看最后通信时间。判据通常是：最后通信时间在心跳周期的三倍以内算在线，超过就判离线。图标有缓存，字段不会骗人。我一般会挂一个定时巡检，专门看“离线超过 30 分钟的 FSU 数量”这条曲线，曲线抬头就意味着某片区域的传输或者供电出问题了。
4.2 地图定位与拓扑设备检查
地图定位检查的实质是经纬度校验。FSU 的经纬度如果偏出站址范围几百米甚至几公里，八成是两个原因：经度和纬度填反了，或者度分秒格式和十进制小数混用了。这两种错误在批量导入时特别常见，而且地图上看起来“有图钉”，不放大根本发现不了。
拓扑检查是从站址节点逐层展开：站址 → 机房 → FSU → 挂接的末端设备。拓扑里挂的设备数量必须和采集表逐条对上，少一个就说明那条设备要么没关联到 FSU，要么关联到了错误的机房。拓扑比列表好用，因为列表只告诉你设备存在，拓扑告诉你设备挂在哪。
4.3 实时视频与性能指标查询
摄像头要能在网管侧调出实时画面，这一步验的不只是通断，还有码流参数——分辨率、码率、帧率是否和平台侧配置匹配。出现过画面能出来但卡成幻灯片的情况，原因就是码率超出了链路带宽预算。
性能指标查询是拉曲线，看两件事：有没有断点，有没有毛刺。断点意味着采集周期内没收到数据，通常是通道配置缺失或者 FSU 侧通道未启用；毛刺意味着量纲或者极性配错了，比如温度在 25 和 250 之间反复跳，那就是 0.1℃ 被当成了 1℃。
4.4 告警监控与四个流转节点的卡点
告警监控要做的不是“看有没有告警”，是主动制造一个告警看它能不能走完全程。常见做法是断一路市电或者拔掉一路空开，观察网管侧是否在规定时间内产生对应告警。
告警产生之后要走四个流转节点，每个节点都有各自的卡点：
| 节点 | 作用 | 典型卡点 |
|---|---|---|
| 告警确定派单 | 人工确认告警有效性并触发派单 | 派单规则未配置，确认后无单可派 |
| 待派工单 | 已派发但未接收 | 责任片区未绑定，工单找不到归属 |
| 待办箱 | 当前处理人名下的待办事项 | 处理人账号停用或未绑定岗位 |
| 监控箱 | 全量告警的集中监控视图 | 数据域过滤导致部分告警不可见 |
| 综合查询 | 历史告警追溯与统计 | 时间范围和字段筛选条件设错 |
监控箱和综合查询经常被混为一谈。监控箱是“现在有什么”，综合查询是“过去发生过什么”，一个是实时视图一个是历史库，排查时用错地方会得出完全相反的结论。
5. 常见问题排查：入网现场最容易翻车的五个地方
下面这五条基本覆盖了入网阶段八成以上的故障，按“现象 → 原因 → 解决”写，遇到对得上的直接照做。
5.1 现象：FSU 显示在线，但所有测点都是 0 或无数据
原因有两个层面。表层原因是信号量字典表和 FSU 点位表没对齐，标识对不上，系统收到数据也匹配不到测点；深层原因是 FSU 侧对应通道压根没启用，采集模块在跑但没往上报。
解决顺序是先在 FSU 本地调试口读原始报文，确认通道有没有数据出来；有数据再拿报文里的标识去字典表里查，查不到就是字典表缺项，查得到但值异常就是量纲或极性配错。这一步不要跳过，直接从平台侧改配置是盲改。
5.2 现象：设备编码对不上，FSU 上报被系统拒收
原因是资源挂错了层级。设备编码是逐级派生的，末端设备必须挂在机房下，FSU 也必须挂在机房下。如果设备直接挂在站址下，生成出来的编码前缀和 FSU 上报的编码前缀不一致，系统认不出这是自己人。
解决方法是按“站址 → 塔桅 → 机房 → FSU → 设备”的顺序逐级核对挂接关系，重点看每一级的编码前缀是否连续。发现挂错的不要试图改编码，编码改不了，只能删了重录。所以录入阶段慢一点，比返工快得多。
5.3 现象：地图上 FSU 定位漂到隔壁站点甚至隔壁城市
原因是经纬度格式问题。经度和纬度填反是最常见的，其次是度分秒格式当成十进制小数直接粘进去。还有一种是采集人员用手机定位取的是 WGS84 坐标，平台侧按另一套坐标系渲染，两者差几百米属于正常偏差。
解决办法是统一用十进制的度为单位，录入前先做一张校验表，用脚本或者表格公式判断纬度是否落在合理区间（国内大致在 3 到 54 之间）、经度是否落在 73 到 136 之间，超出范围的一律打回。批量导入前跑一遍，能省掉大量事后排查。
5.4 现象：告警产生了，但派不出单
原因通常在配置侧：派单规则没配、责任片区没绑、处理人账号被停用或者没绑定岗位。这三者任意一个缺失，工单就会停在待派工单里不动。
排查方法是打开待派工单列表看失败原因字段，系统一般会写明是规则缺失还是人员缺失。补齐之后不要指望历史工单自动重派，需要手工重新触发一次。另外，厂商人员流动频繁，割接前务必核对一遍处理人清单，这个后悔药没有。
5.5 现象：割接后新旧数据打架，同一设备出现两条记录和重复告警
原因是新旧编码并存。割接窗口内只做了新资源录入，没有停用旧资源，同一台物理设备在系统里有两个身份，两边都在上报，告警自然翻倍。
解决办法是割接前先冻结旧编码，把旧设备的告警快照和编码清单存一份；窗口期内停采、改挂接、再启动采集，三步之间不要并行。割接完成后观察 24 小时，确认旧编码不再产生新数据，再做清理。
6. 告警穿越测试与割接：把“看起来正常”验成“真的正常”
前面所有步骤做完，系统看起来是正常的。但“看起来正常”和“真的正常”之间，隔着一次告警穿越测试。
穿越的意思是让一个告警从最末端一路穿到最上层：现场触发（断一路空开、拔掉市电、把温感探头捂热）→ FSU 本地产生告警并点亮指示灯 → FSU 把告警上报到平台 → 平台产生对应级别的告警记录 → 告警进入监控箱 → 按派单规则生成工单 → 处理人待办箱收到 → 处理人确认关闭 → 综合查询里能查到完整闭环记录。这七步里任何一步断了，前面的检查都白做。
我一般会挑三类告警各穿一次：一个电源类（市电中断）、一个环境类（温度越限）、一个安防类（门磁打开）。三类的上报路径不同，穿越结果能覆盖大部分链路问题。测试完成后把整个过程的时间戳记下来，从触发到平台产生告警的时延，就是这套系统的实际响应能力，验收时这就是硬指标。
割接是入网的最后一步，也是最容易出事的一步。要点只有三条：窗口期内停采，别边跑边改；改挂接关系前把旧编码和告警快照存一份，回滚靠它；恢复采集后盯满 24 小时，重点看告警数量和离线 FSU 数量有没有异常抬头。特别提醒里还有一条容易被忽略的——割接期间产生的告警如果没被确认，割接完成后会以历史告警的形式涌进待办箱，处理人会被淹没，提前通知一声比事后解释有用。
从那以后我每次带队做入网，告警穿越测试都强制走一遍七步，哪怕时间再紧也不跳。跳过的那次看着省了半天，后面排查花了三天。希望帮到你。
本文还有配套的精品资源，点击获取
