简介：一份关于Hirschmann RS20交换机的归纳性技术说明文档，面向工业网络运维、自动化控制及现场调试工程师，解决设备上线前的应用程序部署、IP配置，以及运行中的状态监控与故障定位问题。文档来自新华控制工程有限公司现场经验，内容紧凑、步骤清晰。文件为1个PDF，压缩包大小712KB，便于快速查阅和打印。目前已有497人学习/下载。文档主要涵盖：HiDiscovery与Java环境的安装方法；通过HiDiscovery搜索网段内设备并完成IP地址、子网掩码、默认网关设置的具体流程；基于IE浏览器登录管理界面进行端口启用、自适应、流量控制、速率限制等内部参数调整；交换机本体自诊断信息导出方法，以及电源指示灯、环网管理（RM）、Fault综合故障等外部诊断信息；针对环网断线时RM功能失效的应急处置步骤。整体是一份难得的现场实操汇总，适合需要独立完成Hirschmann RS20交换机投运和排障的网络技术人员。
1. 拿到 RS20 后的第一件事：不是接网线，而是先找到它
管理型工业交换机有个特点：默认状态下它是“哑设备”，你既不知道它的 IP，它也不会主动告诉你自己在哪。Hirschmann RS20 这样的老牌环网交换机，开局第一步不是忙着接业务，而是用 HiDiscovery 这个专用工具把设备从网段里“捞”出来，再给它写一个能进管理界面的地址。这份资料正是围绕这个流程整理的，覆盖从 HiDiscovery 安装、IP 写入、端口配置到 Rate Limiter 参数设置，再到环网断线诊断的完整链路。
如果你是电厂、水处理或轨道交通这类现场的运维人员，手里刚拿到一台 RS20，或者需要把备件替换进现有环网，这份资源的价值就很直接：它把现场配置的每一步操作界面都截图归纳好了，照着做就能完成一台交换机的临时配置和故障判断。我拆这份文档时最大的感受是——它不像说明书那样罗列所有功能，而是只讲开局必须碰到的几个关键点，对现场人员来说反而更实用。
2. HiDiscovery 开局：给一台无 IP 交换机写地址的正确顺序
2.1 先装 HiDiscovery，再装 Java，顺序不能乱
RS20 支持通过 Web 界面管理，但前提是 PC 和交换机在同一网段，且你知道交换机的地址。问题在于，新交换机出厂默认 IP 通常是 192.168.10.1 这类固定地址，如果和现场网段冲突，直接连是连不上的。HiDiscovery 的作用就是解决这个“鸡生蛋”问题——它通过二层广播协议搜索网段内所有 Hirschmann 设备，不管交换机当前 IP 是什么，只要能收到广播帧就能发现。
安装上有个容易被忽略的细节：先装 HiDiscovery，再装 Java。这不是我随口说的，而是 Hirschmann 官方安装包的一个特性——HiDiscovery 的图形界面依赖 Java 运行时环境，如果先装 Java 再装 HiDiscovery，有时会因为版本关联问题导致启动时报错。常见做法是先安装 HiDiscovery 主程序，再根据安装向导提示安装捆绑的 Java 组件，装完重启一次 PC 再打开工具。
2.2 网卡选择：多网卡 PC 最容易在这里翻车
打开 HiDiscovery 后，界面顶部有个网卡下拉框，工具默认选中第一块网卡，但它不一定是连交换机的那块。我遇到过不少现场情况：工程师笔记本上同时开着无线和有线，无线连外网、有线接交换机，HiDiscovery 偏偏选中的是无线网卡，结果扫描半天一片空白。
正确的做法是手动点开下拉框，选择与交换机相连的那块有线网卡的 IP。文档里给的示例是 222.222.221.51 或 222.222.222.51，这说明它要求 PC 网卡 IP 与交换机目标 IP 在同一网段。选择网卡后，HiDiscovery 会基于该网卡所在网段做广播扫描，把该网段内所有 RS20 列出来。
这个地方有一个边界要注意：如果现场把交换机划分到了多个 VLAN，而 PC 所在 VLAN 与交换机管理 VLAN 不同，二层广播是跨不过 VLAN 的。此时需要先把 PC 网卡临时划到交换机管理 VLAN 的同网段，扫描完成后再改回来。
2.3 写入 IP 参数：名称、地址、掩码、网关一次填全
扫描到设备后，双击设备条目会弹出配置对话框，需要填写四样东西：
- 名称：设备编号，文档示例是
2DCS-C-1，现场建议按实际编号规则填写，方便后续在环网里识别设备。 - IP 地址：要给交换机分配的管理地址，文档示例是
222.222.221.201。 - 子网掩码：
255.255.255.0，这是 C 类地址的标准掩码。 - 缺省网关：文档里填的
0.0.0.0，表示不设置网关——因为这里做的是本网段管理，交换机不需要跨三层访问。
填完之后，先点“保存为缺省”，再点“OK”。这两个按钮的操作顺序是有讲究的：“保存为缺省”是让当前填写的参数成为交换机的启动配置，这样断电重启后不会丢；“OK”则是确认并下发。如果只点 OK 不点保存为缺省，参数在设备重启后可能会还原，这也是现场"配完第二天又连不上"的常见原因之一。
这里补充一个验证手段。写完后用命令行 ping 一下交换机的 IP，确认通不通：
ping 222.222.221.201 -t参数说明：-t是持续 ping，直到手动停止。如果通了，说明 IP 写入成功；如果不通，优先检查 PC 网卡 IP 是否与交换机在同一网段，然后检查 HiDiscovery 里选择的网卡是否正确。
ipconfig参数说明：确认 PC 当前网卡的 IP 段。执行后看 IPv4 地址那一行，确认它和 222.222.221.x 在同一个网段内。如果不一致，需要先手动改 PC 网卡地址，然后再做 ping 验证。
我一般在这个环节会多做一个动作：给 PC 网卡设置一个 222.222.221.x 段的临时地址，比如 222.222.221.88，避免自动获取地址造成网段漂移。等交换机配置完成后，再把 PC 网卡恢复正常配置。
3. Web 管理界面：登录凭据与 Port Configuration 逐项拆解
3.1 登录凭据是固定的：Admin / private
IP 地址写完并 ping 通后，下一步是通过浏览器进入交换机的管理界面。RS20 的管理页面是内嵌的 Web 服务器，直接用 IE 或兼容模式的浏览器输入交换机的 IP 即可。这里有一个历史包袱要提醒：文档里明确写着用 IE 浏览器，因为 RS20 的 Web 管理页面对现代 Chrome 或 Firefox 的兼容性并不好，有些 JS 组件在新版浏览器里会渲染异常，导致页面显示不全或按钮点不动。
登录时要注意页面下方的级别选择框，默认是Admin级别，用户名固定为Admin，密码固定为private。这个级别拥有完整的读写权限。实际现场遇到的坑有这两类：
- 密码被改过但没人记录——这种情况只能通过 Console 口恢复出厂配置，需要确认 RS20 前面板是否有 Console 口，部分型号需要通过串口线连接后做本地管理。
- 登录后界面语言选成了中文，导致菜单名和文档里的英文名对不上——文档截图是英文界面，如果选中文，找菜单会多费一些时间。建议统一保持 English。
3.2 Port Configuration：四个参数各自管什么
进入管理界面后，第一件事是找到Port Configuration（端口配置）页面。这个页面控制交换机每个物理端口的工作模式，四个参数的含义如下：
Port on：端口启用开关。现场常见做法是只开启实际使用的端口，未用端口全部关闭。这样做的目的不是为了省电，而是防止有人随意插入网线造成非预期流量进入环网。
Propagate Connection error：端口连接故障传播。这个参数理解起来有点绕，建议从使用场景入手：如果某个端口配置了此功能，当该端口连接的下游设备发生断线时，交换机会把这种故障状态传递出去，让其他交换机也能感知到这个链路异常。文档里提到“如所选端口发生未连通则在 Fault 灯亮”，意思是这个功能开启后，端口断线会让设备的 Fault 指示灯亮起。如果这个参数关闭，端口断线只是链路层的 Down，不会触发设备级故障指示。
Automatic Configuration：网口网速自适应，10Mbit/s 或 100Mbit/s。这个按字面意思理解就行，建议保持开启。如果现场存在双工不匹配的情况，可以把该端口强制设为 100M 全双工，但一般不推荐，因为自适应失败时基本都是线序或网线质量问题，先查线再改参数。
Flow Control：端口流量控制。这个参数在现场维护时容易被误解。它控制的是端口是否响应 PAUSE 帧——当接收端缓冲区满时，发送暂停帧让对端暂时停止发送数据。开启后可以降低丢包率，但如果连接的设备不支持流控，反而会造成无意义的等待。
按图设置这几个参数后，需要点击“Set”按钮提交。这里有个好习惯：设置完成后回到“System”或“Device”页面，确认配置已经保存为启动配置，否则设备重启后参数会回滚。
3.3 端口配置的典型场景：前 4 口与后 2 口的职责划分
RS20 这类工业交换机的端口通常分成两组：前几个端口用于接入现场设备，后两个端口用于环网级联。实际配置时，我一般会这样区分：
- 接入端口：关闭 Flow Control，开启 Automatic Configuration，开启 Propagate Connection error。
- 级联端口：开启 Flow Control，因为环网链路汇聚了多个接入端口的流量，需要流控来吸收突发帧。
这个配置不是绝对的，但方向是对的。现场最常见的问题是级联端口不开流控，导致环网在突发流量下频繁丢包，业务现象表现为上位机通讯间歇中断，但用 ping 测又很难复现。
4. Switching 与 Rate Limiter：光口 15000、网口 1500 的数学依据
4.1 Rate Limiter 的作用是限制广播风暴，不是限制带宽
进入Switching菜单下的Rate Limiter（速率限制器），这个页面控制的是每秒钟端口通过的最大数据包数量，单位是Pkt/s，不是带宽。很多第一次接触的人会把它当成带宽限制器来设置，这是一个明显的理解偏差。
Rate Limiter 的真实用途是限制广播帧（BC，Broadcast）和组播帧（MC，Multicast）的速率，防止某个端口下面接入的设备产生广播风暴时，把整个环网打垮。现场常见的配置是只限制广播包，组播包一般不限制——因为现场可能有硬实时通讯依赖组播。
文档给出的参数是：光口15000，网口1500。这两个数值不是随便填的，它们的含义是端口每秒钟最多允许通过的广播包个数。按网口 1500 Pkt/s 来算，如果每个广播包平均 256 字节，对应带宽大约是 3Mbps，已经足够承载正常的广播协议流量，同时又不会让广播风暴耗尽百兆端口带宽。
4.2 为什么光口和网口的限制值差 10 倍
光口 15000、网口 1500，这个 10 倍差距来自环网设计的带宽考量。RS20 的环网光口通常是百兆光口，负责环网链路的数据汇聚，一个环的多个接入端口流量都会经过光口转发，所以光口需要更大的广播包容忍度，否则环网自身的广播协议（比如环网自愈的 hello 报文）都可能被限制掉。
网口是接入端口，只面对一个终端设备或一台下级交换机，广播包数量正常情况下很少。把网口限制在 1500 Pkt/s，可以在终端设备异常时快速隔离广播风暴的影响范围，不至于让整台交换机的 CPU 被中断风暴拖死。
设置时选择Egress Limit，Pkt/s 类型选择BC，填入对应数值后点击“Set”。
我一般会在设置完成后做一个验证动作：用一台 PC 接在网口下，打一个持续的大流量广播包测试脚本，观察交换机的 CPU 占用率是否正常。RS20 的 Web 管理界面里可以用系统资源页面查看 CPU 使用率，如果广播包被成功限制，CPU 应该稳在较低水平。
4.3 容易被忽略的另一个 Rate Limiter 字段：Ingress Limit
文档里只按图设置了 Egress Limit，但 Rate Limiter 页面通常还有 Ingress Limit（入向限制）字段。现场经验是：如果只做 Egress 限制而不做 Ingress 限制，那么超过限制的广播帧仍然会进入交换机，只是不会从该端口转发出去。这样对端口下游的设备有保护作用，但交换机自身 CPU 仍然会因为大量广播帧的到达而产生开销。
如果现场广播风暴源头就是自己这台 RS20 的下挂设备，建议同时设置 Ingress 限制。需要注意，有些 RS20 固件版本里 Ingress 限制的单位是百分比而不是 Pkt/s，设置前先确认当前固件的计量单位，避免设置后速率限制值和预期不符。
5. 交换机诊断与报警：从指示灯到日志导出的排查路径
5.1 灯是现场最快的诊断手段，但读错了反而误判
RS20 前面板的指示灯是现场运维的第一诊断工具。文档里归纳了四类灯：
| 指示灯 | 状态 | 含义 |
|---|---|---|
| P（Power） | 绿色 | 双路电源供电正常 |
| P（Power） | 黄色 | 单路电源供电，需要排查是否另一路电源故障 |
| Standby | —— | 仅支持 Standby 功能的型号有效，本项目未使用 |
| RM（Ring Management） | 绿色 | 本机启用 RM 功能，且环网无物理断链 |
| RM（Ring Management） | 灭 | 本机未启用 RM 功能，或已启用但环网存在物理断链 |
| Fault | 红色 | 综合故障，如单路电源、光口断线等 |
实际现场容易误判的是 Fault 灯。Fault 灯亮并不一定代表这个交换机自身的业务故障——如果环网上一台交换机的光口断线，另一台启用 RM 的交换机的 Fault 灯也会联动亮起。所以看 Fault 灯时，要结合 RM 灯和光口 Link 灯一起判断，不能单灯定论。
5.2 自诊断信息导出：先导 Log file，再导 System information
当设备出现异常需要联系厂家分析时，需要把设备的自诊断信息导出。操作入口在Diagnostics菜单下的Report页面，分两步：
- Log file：记录设备运行日志，包括端口状态变化、环网切换事件、配置变更记录等。导出方式是在弹出的日志窗口里点“文件”→“另存为”，保存为文本文件。
- System information：记录设备当前的整体状态，包括固件版本、端口状态表、电源状态、温度等。同样的方式另存为文件。
导出的这两个文件就是厂家分析问题的原始材料。我建议现场每次设备故障后都做这个动作，然后把文件按“日期_设备名称_故障现象”的格式命名保存，方便后续比对不同时间点的设备状态。一个常见的问题是：Log file 弹出后，有些工程师直接在窗口里复制内容，但窗口显示的行数有限，复制不全。正确做法是通过“另存为”保存完整文件，不要直接在窗口里选。
5.3 外部诊断信息：LS 灯与 DA 灯的配合读法
文档里提到一个细节场景：环网结构的所有光口都处于连通状态（LS 灯绿色，DA 灯黄闪），但 RM 交换机的虚拟断点功能已失效。很多初次接触 RS20 的人看不懂这个现象，这里拆开讲一下。
LS（Link Status）灯是光口链路状态灯，绿色表示链路连通。DA（Data Activity）灯是数据活动灯，黄色闪烁表示有数据在光口上传输。正常情况下，RM=on 的交换机会把 #2 光口设置为虚拟断点（逻辑断开），所以环网从逻辑上是一根链而不是一个环，不会有环路风暴。
但如果环网物理链路全部连通，且所有光口的 DA 灯都在黄闪，说明数据在多个端口之间形成了环路转发，虚拟断点失效了。这种现象通常意味着 RM 交换机发生了异常，或者 RM 配置被改动过。文档给出的处理逻辑是：先做安全措施，然后断电处理，把 RM 转移到另一台交换机，再逐步上电验证。
6. 环网断线切换与 RM 的角色转移：一次完整的分步处理
6.1 环网断线时，RM 交换机的 #2 端口发生了什么
理解这个处理流程之前，必须先搞清 RM 在环网里的角色。RS20 组成环网结构时，环网内必须且只能有一台交换机开启 RM（Ring Management）=on。当环网物理链路全部连通时，这台 RM 交换机的 #2 光口处于虚拟断点状态，即逻辑上断开环，防止数据帧成环转发。
当环网中任意一个光口发生物理断线时，逻辑环路等于被物理打断。此时 RM 交换机检测到链路异常，会立即将 #2 端口从虚拟断点切换成实际连通模式，使整个环网重新恢复成一条完整的数据链路，业务通讯不中断。
这个自愈过程通常是毫秒级或百毫秒级，具体时间取决于环网内设备数量和固件版本。现场测试时，我一般会在业务主机上持续 ping 管理 IP 或 PLC 程序里监控链路心跳，然后逐个拔光口，记录业务中断时间。如果中断时间超过 1 秒，优先检查 RM 参数的配置状态。
6.2 虚拟断点失效后的处理流程，为什么是这个顺序
文档给出的处理流程是一个典型的“故障转移”操作，看起来步骤较多，但顺序有严格逻辑：
- 确认安全措施：环网设备断电前，必须确认不会影响正在运行的现场业务。这一步不能省。
- 将 RM=on 的交换机断电，同时将它的 RM 设置为 OFF。
- 在环网内另选一台交换机，断电，将其 RM 设置为 ON。
- 将新的 RM=on 交换机先上电，等待启动完成，确认网络运行正常。
- 将原 RM 交换机重新上电，观察网络是否正常，如果正常则执行日常监护，如果异常则立即更换。
为什么必须是“新的 RM 先上电，原 RM 后上电”？因为环网内同一时刻只能有一个虚拟断点。如果两台交换机同时 RM=on 并上电，环网内会出现两台设备各自维护虚拟断点的冲突状态，导致转发逻辑混乱，数据帧可能成环或丢包。所以新 RM 交换机必须先上电、先接管环网，等网络稳定后，原 RM 交换机才能作为普通设备重新接入环网。
这个顺序我在现场实践过。有一次在某项目上做环网备件更换，当时图省事，先把原 RM 交换机断电做了配置修改，然后又直接把另一台交换机改成 RM=on 后同时上电，结果环网出现广播风暴，上位机通讯直接断掉。后来严格按照“新的先上、旧的后来”的顺序执行，环网才恢复正常。从那以后，我每次操作 RS20 环网都会强制核对一遍 RM 的归属状态——开机前确认环网内只有一台 RM=on，做完任何断电操作后重新确认一遍。
6.3 验证方法：拔纤测试与日志核对
环网处理完成后，验证动作不能省。我一般会做下面几项验证：
第一步，拔纤测试。在网络业务主机上持续 ping 一个管理 IP，拔掉环网中某一台交换机的光口，观察 ping 中断时长。正常应该在 1 秒内恢复，如果超时说明自愈时间过长，需要检查 RM 交换机 #2 端口的虚拟断点配置。
ping 222.222.221.201 -t参数说明：持续 ping 目标设备，观察拔纤瞬间的丢包个数。丢包数除以每秒 ping 次数，就是自愈时间。我一般用 ping 间隔 200ms 的频率做测试，这样精度更高。
第二步，核对日志。在 RM 交换机上导出 Log file，搜索 Ring 或 RM 相关关键字，确认切换事件有记录。如果日志里没有切换记录，说明 RM 功能实际上没有生效，配置可能存在问题。
# 假设已将 Log file 导出为 log.txt，在 Linux 下用 grep 搜索关键字 grep -i "ring\|RM\|redundan" log.txt参数说明：-i忽略大小写，“ring”匹配环网相关事件，“RM”匹配环网管理事件，“redundan”匹配冗余切换事件。搜索到的记录里有时间戳和事件描述，逐条核对即可。
第三步，确认 RM 指示灯状态。上电完成后，观察 RM 交换机的 RM 灯是否绿色亮起，Fault 灯是否熄灭。RM 灯绿色表示虚拟断点已建立且环网无物理断链，Fault 灯灭表示无综合故障。
这套流程走完之后，环网才算真正恢复正常。从那次广播风暴之后，我养成了一个习惯：凡是经过断电操作或 RM 角色变更的设备，上电后 24 小时内强制每天核对一次 RM 状态和日志记录，确认无误后才算完成。工业现场的网络故障往往不会立刻暴露，而是潜伏一段时间后才显现，提前做一轮监护比事后抢修省心得多。希望这份拆解能帮你在现场少走几步弯路。
本文还有配套的精品资源，点击获取
