简介：《Infovision iWork-Safety 安全生产管理平台 配置手册》面向安全生产平台实施、运维与系统管理员，帮助读者理解平台功能边界并完成日常配置操作。手册以PDF单文件交付，压缩包约20.05MB，内含1个PDF，内容按产品版本整理，便于随查随用和归档留存。已有6830人学习，说明其在同类平台资料中具有一定参考价值。正文共八章，从概述、登录、区域管理延伸到设备、报警、视频与报表管理，并在附录汇总常见问题、故障排除和技术支持信息；开篇还说明说明、注意、危险三类符号约定，提醒操作风险。读者可据此梳理平台模块关系、核对配置项与操作路径，并借助附录定位异常处理思路，适合作为项目实施、交付验收和日常运维的案头参考，也可用于团队内部培训与知识沉淀。

1. 安全生产管理平台的配置手册，真正该先看的是前三章

接手一套已经装好的安全生产管理平台，最尴尬的不是不会用，而是不知道从哪一页开始翻。某厂区的安全主管就踩过这个坑：设备全通了，实时预览也有画面，可到月底查录像，发现计划压根没下发到摄像头，事件联动列表里空空如也。回头翻那份 Infovision iWork-Safety 配置手册才明白，问题源头都在前几章的建树顺序上。这份手册是平台 V1.1 版本的配置指南，按登录环境、区域管理、用户与角色、视频监控、事件联动、动环监控、人员发卡八块内容组织，每一步都标了前置条件。它适合正在做厂区、园区、楼宇安防落地的实施人员和运维，也适合要把平台交接出去的技术负责人——它不是拿来通读的，是拿来对着现场一条条核对的。

2. 登录环境与区域树：平台能不能用，第一公里就定了

2.1 浏览器与运行环境：ActiveX 这一关绕不过去

运行环境在手册里只占了半页，最容易被跳过，但它决定后面所有操作能不能做。平台的控制、预览、回放依赖浏览器里的 ActiveX 控件和本地解码插件，这套东西只在 IE 内核下工作；换成常见的新版浏览器，登录页也许打得开，进到实时预览就是一块黑屏，或者反复弹“请安装插件”。我一般先把浏览器配置做完，再谈别的，顺序反了会白白浪费半天排查。

手册第 2.1 节给的是最低配置，实际按并发路数和预览窗口数往上加。下面这张表是我在现场常用的核对项，右边的“落地建议”是踩过坑之后补的：

设置 IE 的顺序有讲究，乱点一通往往越点越乱：

1. 打开 Internet 选项，把平台访问地址加入“受信任的站点”，注意取消“对该区域中的所有站点要求服务器验证”的勾选。
2. 进入“自定义级别”，把 ActiveX 控件相关的几项从“禁用”改成“启用”或“提示”，特别是自动提示、下载未签名控件、运行未标记为安全的控件这几条。
3. 如果客户端和平台不在同一个网段，把“保护模式”相关开关关掉，否则跨网段访问会被静默拦截。
4. 保存后彻底关闭浏览器进程再重开，只关标签页不生效。
5. 首次登录会提示安装预览插件，装完再刷新一次页面。

提示：插件装完仍然黑屏，先看浏览器地址栏下方有没有被拦截的提示条，再确认客户端的 hosts 或 DNS 有没有把平台域名解析到旧地址。

2.2 区域树是平台的骨架，场景选择决定你看到什么

区域在手册第 3 章，看起来只是一个树形列表，实际是整个平台的组织维度：编码设备、监控点、报警输入、门禁点、动环传感器，最后都要挂到某个区域上；事件规则、录像计划、权限分配也都按区域生效。区域建错了，后面所有配置都要返工，这是血泪经验。

手册把这件事拆成场景选择、添加单个区域、批量添加区域、快速添加楼栋单元、导入和导出六个小节，顺序其实就是在告诉你：先定场景，再建树。场景是一个业务维度的容器，厂区安全和楼宇管理下的区域树是两套东西，不能互相挂。同一个物理楼栋，如果在两个场景里都建了一遍，设备只会挂在其中一边，另一边的预览页就是空的。

添加单个区域的参数不多，但每一项都会影响后续：

命名这件事值得单独说一句。现场负责人报故障时说的是“三号厂房二层东侧”，如果你的区域树是“区域1、区域2、区域3”，每次都要靠猜。我一般要求区域名称直接对齐现场的叫法，哪怕长一点，检索的时候能省下大量沟通成本。

2.3 批量建区域与楼栋单元：模板字段和一份校验脚本

区域数量一多，逐个点就不现实了。手册给了两条路：批量添加区域和快速添加楼栋单元。前者走 Excel 模板导入，后者是按楼栋、单元、楼层的规律批量生成，适合住宅或标准厂房的重复结构。快速生成能省事，但生成出来的命名规则是固定的，如果现场对命名有要求，还是老老实实走模板导入。

导入模板的列一般包含区域名称、上级区域、区域类型、排序号这几项，上级区域必须填已经存在的父级名称，根节点留空。这里最容易翻车的地方是模板被 Excel 改过：前导零被吃掉、列名多了一个空格、合并单元格导致空行。手册里没写校验规则，但导入失败时给的报错往往只说“第 N 行数据有误”，不告诉你错在哪。

我一般会在导入前跑一遍自检，提前把父子关系、重名、层级深度这几类问题挑出来：

import pandas as pd # 读取区域导入模板；dtype=str 防止区域名里的数字被转成浮点 df = pd.read_excel("area_import.xlsx", dtype=str).fillna("") df.columns = [c.strip() for c in df.columns] # 去掉列名里的空格 names = df["区域名称"].tolist() parents = df["上级区域"].tolist() name_set = set(n for n in names if n) errors = [] # 1. 重名检查：同名区域在树上无法定位 dups = [n for n in set(names) if names.count(n) > 1] for d in dups: errors.append(f"重名区域：{d}") # 2. 父级存在性检查：父级必须在本表内或已存在于平台 for i, (n, p) in enumerate(zip(names, parents), start=2): if p and p not in name_set: errors.append(f"第{i}行：父级“{p}”不在本表内，需确认平台是否已存在") # 3. 环路检查：A 的父是 B，B 的父又是 A parent_map = {n: p for n, p in zip(names, parents) if n} for n in parent_map: seen, cur = set(), n while cur and cur in parent_map: if cur in seen: errors.append(f"存在环路：{n}") break seen.add(cur) cur = parent_map[cur] # 4. 层级深度：超过 5 层的树在前端展开时会很难用 def depth(n): d, cur = 1, n while parent_map.get(cur): cur = parent_map[cur] d += 1 return d for n in parent_map: if depth(n) > 5: errors.append(f"层级过深（{depth(n)} 层）：{n}") print("\n".join(errors) if errors else f"校验通过，共 {len(names)} 个区域")

这段脚本做四件事：重名检查、父级存在性、环路检测、层级深度。参数上唯一要注意的是dtype=str，Excel 里像“0101”这种编号很容易被读成数字 101，导入后和现场的编码对不上。父级存在性那一条只能查表内，跨表引用平台已有区域的情况脚本看不出来，导入后要抽查几个深层节点确认树形结构正确。

2.4 导出区域做基线，跨环境迁移少返工

手册第 3.6 节的导出功能很多人当摆设，其实它是最好的后悔药。区域树建到一半发现命名规则要改，或者要在测试环境和生产环境之间搬结构，靠手工重建基本等于重来。每次大改之前导出一份，改坏了直接导回去覆盖，比一条条删快得多。

导出文件同时也是交付文档的一部分。项目验收时把区域树导出成表，附在施工记录后面，后面接手的人一眼就能看出这棵树是怎么设计的。跨环境迁移时注意两点：一是两个平台的场景类型要一致，否则导入后区域会落到默认场景；二是区域下的设备不会跟着走，只搬结构不搬数据。

3. 用户角色与设备接入：六种协议怎么选才不返工

3.1 角色、用户组、用户：三层模型别建反

手册第 4 章讲用户与角色，顺序是先角色、再用户组、最后用户，这个顺序不是随便排的。角色决定能做什么，用户组决定在哪个范围内做，用户是具体的人。三者的关系建反了，后面权限就会互相打架，表现出来是“明明给了权限还是看不到设备”。

角色是权限集合，核心是勾选菜单和操作项。这里有一个容易被忽略的点：角色里的菜单权限和区域权限是两套东西，角色给的是功能可见性，区域给的是数据范围。一个角色可以看实时预览，但如果这个人所在的用户组没有绑定某个区域，那个区域下的监控点他就是看不到。用户组就是干这个的——把区域和角色绑在一起，组里的人自动继承。

批量导入用户和导入域用户是两个场景。手册第 4.4 节走 Excel 模板，第 4.5 节走域认证。现场如果有统一的域环境，优先用域用户，账号生命周期跟着域走，离职停用一次就够；没有域环境才用本地账号，但本地账号的密码策略要提前定好，否则导入时一批人卡在密码复杂度上。

重置密码这一节在手册里只有几行，实际操作中要注意：重置后如果勾了“下次登录修改”，用户首次登录会被强制跳转，有些老版本客户端在这个跳转上会卡住，现场最好当场让用户登一次确认。

3.2 六种设备接入协议的适用边界

手册第 5.2 节把设备接入拆成六种方式：IP 地址直连、EHome 类主动注册协议、GB/T 28181 标准协议、ISUP 类私有协议、云平台扫码接入、主动注册到平台。这个分类本质上是按“谁先发起连接”和“走不走标准”两个维度切的，选错协议不会报错，但会在某个环节卡住，比如跨网段加不上、加了之后没有云台、或者录像回放拉不下来。

选型的判断顺序我一般是这样：先看设备和平台之间有没有固定的可达网络，有就走 IP 直连，这是功能最全的一条路；没有固定 IP 或者中间隔着 NAT，就走主动注册类协议；如果是多厂商混布或者要和上级平台级联，只能走 GB/T 28181，这时候要在动手前把设备 ID 编码规则定下来，中途改 ID 等于所有设备重接一遍。

ISUP 类私有协议和 GB/T 28181 有一个实质差别：前者通常带一条设备管理通道，能远程改设备参数、推升级包；后者只保证视音频和控制信令，设备本身的配置还得单独登进去改。现场设备量大、又分散在不同楼栋的时候，这条管理通道值不少人工。

3.3 批量导入设备前的端口探测与监控点挂区域

设备一台台加是新手做法，手册第 5.2.6 节给了批量导入。模板里的列一般包括设备名称、IP、端口、用户名、密码、协议类型，导入前最该做的是把所有设备的端口先探一遍，因为批量导入是“一把梭”，中间有不通的不会停下来等你，导完只给你一个成功数量，剩下哪些失败得自己找。

#!/usr/bin/env bash # 批量探测设备端口可达性；devices.csv 格式：名称,IP,端口 while IFS=, read -r name ip port; do # 跳过表头和空行 [ -z "$ip" ] && continue [ "$ip" = "ip" ] && continue # 2 秒超时，避免个别离线设备把整个循环拖住 if timeout 2 bash -c "echo > /dev/tcp/$ip/$port" 2>/dev/null; then echo "OK $name $ip:$port" else echo "FAIL $name $ip:$port" fi done < devices.csv

这段脚本用的是 bash 内置的/dev/tcp，不需要额外装 nc 或 telnet 客户端，在大多数 Linux 跳板机上能直接跑。参数上就一个timeout 2，值别设太大，几十台设备串行探测，每台等十秒就是一整段时间；也别设太小，跨网段首次握手有时候要一秒多。实际用的时候分两轮：第一轮探设备的管理端口，确认设备在线；第二轮探流媒体端口，确认平台侧能拉到流。两轮都过再导入，返工率会低很多。

导入完成不等于能用。手册第 5.2.7 节专门讲了把监控点添加到区域，这一步是把设备下的通道挂到区域树上，没挂的话设备在列表里能看到，但实时预览的区域视图里是空的。批量导入后要按区域抽查，特别是楼层多、通道多的项目，漏挂几个通道很难靠肉眼发现。

3.4 权限是叠出来的：菜单权限与区域权限

权限这件事在现场最常听到的抱怨是“我都给他管理员角色了，怎么还是看不到”。角色给的是功能，区域给的是数据，两者是乘法不是加法：功能有、数据没有，结果是空列表；功能没有、数据有，结果是进不去页面。

实操里我一般按岗位切角色，不按人切。值班员、班长、安全主管、系统管理员，四个角色基本能覆盖一个厂区。区域权限挂在用户组上，一个人换岗只改用户组归属，不动角色，避免角色数量爆炸。手册第 4.6 节的重置密码和批量导入都建立在这个结构上，如果角色设计得乱七八糟，后面每加一个人都要重新想一遍权限，那才是真的累。

还有一个细节：跨场景的区域不能互挂。厂区安全场景下建的区域，在楼宇场景的用户组里选不到，这是设计如此，不是 bug。遇到“选不到区域”的反馈，先问一句是不是在另一个场景里建的。

4. 录像、抓图与事件联动：把存储和报警真正跑通

4.1 先算存储账：设备存储与中心存储的取舍

手册第 5.3 节先把存储拆成设备存储和中心存储两条路，这个拆分很关键，因为两者的带宽模型完全不同。设备存储是把录像写在摄像头自带的存储卡或硬盘里，平台只做索引和回放调度，几乎不占平台带宽；中心存储是码流从设备一路推到平台的存储服务器，占的是平台侧的下行带宽和磁盘。

算账的公式不复杂，单路每小时容量约等于码率乘以 3600 再除以 8，换算成 GB 再除以 1024。我一般直接写个小脚本批量算，避免手算出错：

# 存储容量估算：按码率、路数、天数计算所需磁盘 def storage_gb(bitrate_mbps, channels, days, hours_per_day=24): # 单路每小时 GB = Mbps * 3600 / 8 / 1024 per_channel_hour = bitrate_mbps * 3600 / 8 / 1024 return per_channel_hour * hours_per_day * days * channels # 200 路 2Mbps 主码流，存 30 天 raw = storage_gb(2, 200, 30) # 实际要留 10%~15% 余量给索引、抓图和磁盘格式化损耗 print(f"裸容量 {raw:.0f} GB，规划容量 {raw * 1.15:.0f} GB")

结果大概是每路每天 21 GB 量级，200 路 30 天在 120 TB 以上。这个数字一出来，很多项目就会重新考虑：主力存储放中心，次要点位放设备本地，或者把非关键通道的码率降下来。

手册第 5.3.4 节的录像回传是两者的折中：平时录像写设备本地，闲时或指定时段把录像回传到中心。这条路省带宽，但要注意回传任务本身也占带宽，别把回传时段安排在业务高峰。

4.2 录像计划的三层结构：模板、计划、回传

录像计划在手册里被拆成配置录像计划、配置录像回传、配置录像计划模板三节，背后是一个三层结构，理解了这个结构就不会配错。模板是时间段的抽象，比如“工作日 8 点到 18 点连续录、其余时间移动侦测录”；计划是把模板绑定到具体监控点；回传是给中心存储加一条搬运规则。

配置顺序建议从模板开始。手册第 5.3.5 节的计划模板可以复用，一个厂区通常三五个模板就够：全天连续、工作日白天连续、夜间移动侦测、重点区域全天加备份。模板建好之后再给监控点批量绑，比一个个点进去配要快一个数量级。

这里有一个很隐蔽的坑：模板改了之后，已经绑定该模板的监控点不一定自动生效，部分版本需要重新下发。所以模板的调整要放在批量绑定之前做，绑完再改模板，很容易出现“一部分通道是新计划、一部分是旧计划”的混合状态，查录像时表现为某些时段有、某些时段没有。

注意：录像计划生效依赖设备时间与平台时间一致。设备时间和平台差几分钟，回放时按时间轴检索就会错位，严重的时候整段录像检索不到。

4.3 抓图计划与图片存储服务器

抓图是录像的补充，手册第 5.4 节单独给了图片存储服务器的配置和抓图计划。抓图的价值在于快速检索——查一个事件，翻录像是分钟级，翻图片是秒级。抓图计划同样有模板机制，配置逻辑和录像计划一致。

图片存储服务器要单独配，别和录像存储混在一个盘上。图片是小文件高频写入，和录像的大文件顺序写混在一起，磁盘的 IO 模式会被打乱，表现出来是两边都变慢。我一般给图片单独划一个卷，容量按抓图频率估算，移动侦测触发的抓图量波动很大，余量要留足。

抓图计划的时间段和录像计划最好对齐，否则查事件的时候会出现“有图无录像”或者“有录像无图”的断档，追溯起来很别扭。

4.4 事件规则的四要素与布撤防时间窗

事件联动是手册第 6 章的重点，也是整套平台里最容易配了不生效的部分。一条事件规则拆开看是四个要素：事件源、触发条件、联动动作、生效时间。四个要素缺一个，规则就是死的。

事件源是设备、监控点或者报警输入。触发条件包括移动侦测、越界、区域入侵、设备离线、传感器越限这些。联动动作可以叠加：录像、抓图、上墙、邮件通知、声光报警、开关量输出。生效时间靠布防计划模板控制，手册第 6.4 节专门讲了模板，第 6.6 节讲了设备布防。

四要素里最容易漏的是生效时间。规则配完不测试，默认以为全天生效，实际模板只覆盖了工作日的某个时段，周末的入侵事件一条都不触发。我一般的做法是配完规则立刻做一次触发测试，把时间调到当前，故意触发一次，看联动动作有没有执行，确认后再改回正常时间窗。

手册第 6.5 节给了两种配置方式：按模板设置和自定义设置。模板适合标准场景，比如“所有周界监控点，夜间移动侦测触发录像加上墙”；自定义适合有特殊逻辑的点位，比如“某个危化品仓库，只要传感器越限就联动声光报警并抓图”。自定义规则的优先级高于模板，同一事件被多条规则命中时，要确认优先级顺序符合预期，否则会出现联动动作被覆盖的情况。

5. 避坑与排查：五条血泪经验，每条都能省半天

5.1 预览黑屏但设备在线

现象：设备列表里状态是在线，实时预览窗口一片黑，偶尔弹一下“加载中”就没了，控制台里能看到平台和设备之间的心跳正常。

原因：平台服务器到设备的管理通道通了，但流媒体服务器到设备的取流通道没通。这两个方向经常走不同的网卡或不同的网段，心跳走管理网，取流走业务网，只测一边就会得出“网络没问题”的错误结论。

解决：在流媒体服务器上单独测一次到设备的取流端口，不通就查路由和防火墙策略。多网卡服务器还要确认平台配置里绑定的是哪张网卡，绑错了就是心跳正常、取流失败。

5.2 录像计划配了但查不到录像

现象：计划在平台界面上显示已下发，监控点也绑了模板，回放时时间轴上却是一段空白，或者只有零星的几段。

原因：按出现频率排，依次是设备本地没有存储介质、设备时间和平台时间不一致、计划没有真正下发到设备、存储盘满了开始循环覆盖。这四个原因的表现都是“没录像”，但排查路径完全不同。

解决：先登设备的管理页面看本地存储状态和时间，再看平台侧的录像计划下发记录，最后查存储服务器的磁盘水位。这一步不要跳，直接去改平台配置，很可能改了半天发现是存储卡没插。

5.3 区域删不掉或者设备挂不上区域

现象：删除区域时提示失败，或者把设备往某个区域上挂的时候，目标区域在下拉列表里根本选不到。

原因：区域下面还有子区域或设备没解绑，删除被拦截；选不到的情况多半是跨场景，当前操作在厂区安全场景下，目标区域建在楼宇场景里。

解决：删之前先在区域详情里看清下级节点和挂载资源，从叶子往上删。挂不上的先确认场景是否一致，再确认当前账号对该区域有没有操作权限。

5.4 事件规则配完不触发

现象：规则列表里有这条规则，状态是启用，现场触发了一次移动侦测，联动动作一个都没执行。

原因：布防计划模板的时间窗没覆盖当前时刻，或者设备本身没布防，或者规则优先级被另一条更宽泛的规则覆盖了。

解决：分三步查——先看模板时间窗，再看设备布撤防状态，最后看规则优先级。手册第 6.7 节的事件查询可以帮上忙，触发后先去事件列表里看有没有记录，有记录说明事件上来了、是联动没执行；没记录说明事件压根没上来，问题在设备和布防，不在规则。

5.5 批量导入用户失败但报错很笼统

现象：导入模板填好了，点导入提示“部分数据导入失败”，不说是哪一行、什么原因。

原因：模板被 Excel 动过是最常见的，列名多了空格、单元格被设成文本或数字格式、密码列被自动转换。其次是密码复杂度不满足策略，或者所属用户组名称和平台里的对不上。

解决：导入前把模板另存为纯数据格式，逐列确认列名和平台要求完全一致；密码列统一设成文本格式；用户组名称先导出平台现有的对照一遍。导入失败的行先单独提出来重导，别整批重来。

6. 动环监控的联调验收：用一张表把平台交付出去

动环监控在手册第 7 章，位置靠后，很多人做到这一步已经疲了，草草加几台主机就收工。但动环恰恰是验收时最容易被打回的部分，因为它涉及传感器、开关量、空调控制这些跨专业的设备，出问题不像摄像头那么直观。

我的做法是把动环和事件联动放在一起联调。先按手册 7.2 节加动环主机，再把传感器、报警输入、开关量输出分别挂到区域上——这三类资源的挂载入口是分开的，少挂一类，后面的事件规则就少一个事件源。手册 7.3 节的开关管理和监控点 OSD 是显示层的事，配置完在环境监测页面上要能看到实时数值，看不到就先查主机的采集周期和传感器的地址配置。

联调的核心是走一遍完整的“越限到动作”链路：给温湿度传感器一个人为的越限值，看环境监测页面是否告警、事件列表是否产生记录、联动动作是否执行、开关量输出是否真的动作。这四步里任何一步断了，前面的配置都等于白做。

下面这张表是我交付前必过的验收清单，每一项都要有明确的通过标准：

这套联调我吃过一次亏。当时赶工期，动环主机加完看页面有数字就签字了，结果一个月后现场反馈高温告警从来没响过。回头查发现传感器挂上了，但事件规则里根本没引用这个事件源，规则倒是配了，配的是另一个区域的设备。从那以后我每次交付前都强制走一遍“人为触发—看记录—看动作”这条链路，不管页面显示得多正常，不触发一次不算数。

进阶一点的用法是把动环和视频联动起来：传感器越限时，除了声光报警，同时把对应区域的摄像头画面推到电视墙上。手册第 6 章的事件规则支持多动作叠加，配置时把监控点作为联动对象加进去就行。这个组合在机房、配电房、危化品仓库这类无人值守场景里价值很高，告警响起来的时候人不用先找画面。

希望帮到你。

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