1. 从一次产线改造聊起：为什么S1和S2模式总让人犯迷糊
前阵子帮朋友处理一条包装产线的改造，现场用的是S7-1500R冗余系统，挂了一堆PN IO设备。调试的时候遇到个挺典型的问题：一台新的远程IO站，在普通S7-1500上跑得好好的，换到冗余系统上就死活连不上，诊断缓冲区里报的是"系统冗余不可用"之类的信息。折腾了半天才发现，问题出在这台IO设备只支持S1模式，而冗余CPU默认期望的是S2模式连接。
这个坑其实很多做自动化的朋友都踩过。S7-1500R/H这套冗余系统，和普通S7-1500在PN IO设备的连接机制上，有一个非常关键但容易被忽略的差异，就是S1模式和S2模式的区别。你如果只是照着普通1500的经验去配冗余系统，大概率会在某个环节卡住。
先把概念说清楚。所谓S1模式，指的是一个PN IO设备只与冗余系统中的一个CPU建立应用关系，也就是单连接；S2模式则是IO设备同时与冗余系统中的两个CPU都建立应用关系，形成双连接。这个差异直接决定了当冗余系统发生主备切换时，IO设备能不能无缝地继续通信。
这篇文章我打算把S1和S2这两种模式在S7-1500R/H上的表现彻底讲透，包括它们各自的连接机制、组态时的具体操作、实际项目里怎么选、以及调试中那些文档里不会写的坑。不管你是刚接触冗余系统的新手，还是已经用过几年1500但没深究过冗余细节的老手，应该都能从里面找到有用的东西。
2. S1与S2的连接机制：从底层看两种模式到底差在哪
2.1 冗余系统的基本架构决定了连接方式
要理解S1和S2，得先搞清楚S7-1500R/H的冗余架构。这套系统由两个CPU组成，一个做主，一个做备，两者通过冗余同步链路（通常是光纤）保持数据同步。对外部来说，这两个CPU在PN网络上呈现的是同一个设备名称，但各自有独立的IP地址。
普通S7-1500只有一个CPU，PN IO设备跟它建立一条AR（Application Relation，应用关系）就完事了。但冗余系统有两个CPU，IO设备到底跟谁建立AR、建立几条AR，这就是S1和S2的分水岭。
在S1模式下，IO设备只跟当前的主CPU建立一条AR。备用CPU虽然也在网络上，但IO设备并不与它建立应用关系。当主CPU故障、备CPU接管时，IO设备需要重新建立与新的主CPU的AR，这个过程中通信会短暂中断。
S2模式下，IO设备同时与两个CPU各建立一条AR，也就是两条应用关系并行存在。主CPU负责实际的IO数据交换，备CPU也保持着AR但处于待命状态。一旦发生切换，备CPU直接接管已有的AR，IO设备几乎感觉不到中断。
2.2 用生活场景类比两种模式
打个比方。S1模式就像你只存了一个医生的电话，这个医生休假了，你得重新找另一个医生、重新挂号、重新描述病情，中间必然有等待。S2模式则是你同时挂了两个医生的号，两个医生都了解你的病情，一个临时有事，另一个立刻接手，你几乎不用重新排队。
这个类比虽然简化了，但核心意思到位：S2模式的冗余切换时间远短于S1模式，因为省去了重新建立AR的过程。
2.3 切换时间的量化差异
根据实际项目中的观察，S2模式下的冗余切换，IO通信中断时间通常在几十毫秒级别，具体取决于IO设备的看门狗设置和网络负载。而S1模式下，由于需要重新建立AR，中断时间可能达到几百毫秒甚至更长，具体取决于IO设备的响应速度和网络状况。
这个差异在普通逻辑控制场景下可能无所谓，但在运动控制、高速联锁、或者对连续性要求极高的过程中，几百毫秒的中断可能就是事故。所以选S1还是S2，本质上是在设备兼容性和切换性能之间做权衡。
2.4 哪些设备支持S2
这里有个很现实的问题：不是所有PN IO设备都支持S2模式。S2模式要求IO设备具备同时处理两条AR的能力，这对设备的固件和硬件都有要求。一般来说，较新的、定位中高端的ET200系列设备（比如ET200SP、ET200MP的部分接口模块）支持S2，而一些老设备、第三方设备、或者低端设备可能只支持S1。
在组态的时候，如果给一个只支持S1的设备强行配置S2连接，TIA Portal会报错或者给出警告。反过来，如果设备支持S2但你只配了S1，系统能跑，但你就放弃了冗余切换的性能优势。
3. 在TIA Portal里组态S1和S2的实际操作
3.1 设备视图中的关键设置项
在TIA Portal里配置S7-1500R/H的PN IO设备时，S1/S2的选择藏在设备属性的一个不太起眼的地方。选中IO设备，进入"属性"选项卡，找到"常规"下面的"冗余"或者"PROFINET接口"相关设置，里面会有一个关于"系统冗余"的选项。
具体路径大致是：设备视图 → 选中IO设备 → 属性 → 常规 → PROFINET接口 → 高级选项 → 冗余。在这里你可以看到"支持系统冗余"的勾选项，以及S1/S2模式的选择。
需要注意的是，这个选项的可用性取决于你选的IO设备型号。如果设备本身不支持S2，这个下拉框里可能只有S1可选，或者干脆是灰的。
3.2 组态步骤的完整流程
我一般按这个顺序来操作：
- 先在硬件目录里把S7-1500R/H的冗余站组好，两个CPU的型号、固件版本要一致。
- 添加PN IO设备，分配设备名称和IP地址。这里有个细节：IO设备的IP地址是跟设备名称绑定的，在冗余系统里，设备名称的分配要特别注意，两个CPU都要能解析到同一个设备名称。
- 进入IO设备的属性，找到冗余相关设置，选择S1或S2模式。
- 编译项目，检查是否有关于冗余兼容性的警告或错误。
- 下载组态到冗余CPU，观察IO设备的连接状态。
3.3 设备名称分配在冗余系统中的特殊性
这一步是很多人容易翻车的地方。在普通S7-1500系统里，IO设备的名称分配很直接，CPU能找到就行。但在冗余系统里，两个CPU都需要能通过这个名字找到IO设备。如果名称分配不一致，或者只给主CPU分配了名称，切换后备用CPU就找不到设备了。
实际操作中，我建议用TIA Portal的"分配设备名称"功能，在线状态下确保两个CPU都能看到并正确识别IO设备。有时候需要分别对两个CPU执行名称分配操作，或者使用支持冗余名称分配的工具。
3.4 编译时的冗余检查
TIA Portal在编译冗余项目时，会做一系列检查。如果IO设备配置了S2但设备实际不支持，编译会报错。如果配置了S1，编译通常能过，但可能会有提示说"该设备不支持系统冗余"之类的信息。
我的习惯是每次编译后都仔细看一遍编译输出，不要只看有没有红色错误，黄色的警告信息里往往藏着关键线索。特别是关于"系统冗余"的警告，一定要搞清楚原因再下载。
4. 实际项目中S1和S2的选型逻辑
4.1 什么场景必须用S2
如果你的系统对切换时间有严格要求，比如：
- 过程控制中的连续调节回路，中断会导致产品质量波动
- 运动控制轴，中断可能导致位置丢失或机械冲击
- 安全相关的联锁，虽然安全功能通常走PROFIsafe，但底层通信中断也会影响安全响应时间
- 高速数据采集，中断会导致数据丢失
这些场景下，只要IO设备支持S2，就应该优先用S2。
4.2 什么场景S1可以接受
反过来，如果是一些对切换时间不敏感的场景：
- 普通的开关量采集，几百毫秒的中断不影响逻辑判断
- 慢速的温度、压力监测
- 非关键的辅助设备监控
- 只支持S1的老设备或第三方设备
这些情况下用S1完全没问题，没必要为了S2去换设备。
4.3 混合使用的情况
实际项目里经常是混合的：一部分关键设备用S2，一部分辅助设备用S1。这完全可行，TIA Portal允许在同一个冗余系统里混用S1和S2设备。但要注意，S1设备在切换时会有中断，如果你的逻辑里对这些设备的信号有连续性要求，需要在程序里做相应的处理，比如加延时、做信号保持等。
4.4 一个选型对照表
| 考量维度 | S1模式 | S2模式 |
|---|---|---|
| 连接数量 | 单连接，仅主CPU | 双连接，主备CPU各一条 |
| 切换中断时间 | 较长，需重建AR | 极短，AR直接接管 |
| 设备兼容性 | 几乎所有PN IO设备 | 需设备固件支持 |
| 组态复杂度 | 简单 | 稍复杂，需确认设备能力 |
| 网络负载 | 较低 | 较高，双倍AR维护 |
| 适用场景 | 非关键、慢速、老设备 | 关键、高速、连续过程 |
5. 调试中那些文档不会告诉你的坑
5.1 设备名称分配不一致导致切换失败
这是我遇到最多的坑。现象是：系统正常运行时一切正常，一旦手动切换主备CPU，部分IO设备就掉线，诊断显示"找不到设备名称"或"AR建立失败"。
原因通常是设备名称只分配给了主CPU，备用CPU没有正确解析。解决方法是重新执行设备名称分配，确保两个CPU都能识别。有时候需要在两个CPU上分别执行分配操作，或者使用TIA Portal的"在线访问"功能，分别连接两个CPU确认设备名称。
5.2 固件版本不匹配引发的S2连接问题
S2模式对IO设备的固件版本有要求。我遇到过一台ET200SP，硬件支持S2，但固件版本较老，组态时选了S2，下载后设备就是连不上。升级固件后问题解决。
所以选S2之前，一定要确认IO设备的固件版本是否满足要求。这个信息在TIA Portal的设备属性里能看到，也可以查设备手册。如果固件版本不够，要么升级固件，要么退回S1。
5.3 网络拓扑对S2连接的影响
S2模式要求IO设备能同时与两个CPU通信，这对网络拓扑有要求。如果IO设备只连接在一个CPU的端口上，通过冗余同步链路间接与另一个CPU通信，S2可能无法正常工作。
推荐的做法是使用支持冗余的交换机，或者将IO设备通过两个独立的物理路径分别连接到两个CPU。具体怎么接，取决于你的网络架构和交换机能力。有些项目里用环网，有些用双星型，各有优劣。
5.4 看门狗时间设置与切换时间的配合
IO设备的看门狗时间决定了它能容忍多长的通信中断。如果看门狗时间设得太短，S1模式下的切换中断可能导致设备直接掉线；设得太长，又会影响故障检测的实时性。
我的经验是：S1模式下，看门狗时间至少设为预期切换时间的2-3倍；S2模式下可以适当缩短，因为中断本身就很短。具体数值要在实际系统中测试调整，没有万能公式。
5.5 诊断缓冲区里的关键信息
调试冗余系统时，诊断缓冲区是最好的朋友。切换失败、AR建立失败、设备掉线，这些事件都会在诊断缓冲区里留下记录。关键是要学会看时间戳和事件顺序，往往能定位到问题的根源。
比如，如果看到"AR建立请求"和"AR建立失败"交替出现，可能是设备名称或IP配置有问题。如果看到"看门狗超时"，那就是通信中断时间超过了设备容忍度。
6. 从S1迁移到S2的实操建议
6.1 迁移前的评估清单
如果你现在用的是S1，想升级到S2，先做这几件事：
- 确认所有IO设备是否支持S2，查手册或问供应商
- 确认设备固件版本是否满足S2要求
- 评估网络拓扑是否支持双连接
- 确认冗余CPU的固件版本支持S2
- 备份当前项目，包括硬件组态和程序
6.2 迁移步骤
迁移本身不复杂，但要有条理：
- 在TIA Portal里打开项目，逐个检查IO设备的冗余设置
- 将支持S2的设备改为S2模式
- 编译项目，处理所有警告和错误
- 下载组态，先下载到主CPU，再同步到备CPU
- 在线观察IO设备连接状态，确认两条AR都建立成功
- 执行手动切换测试，验证切换过程中IO通信是否连续
6.3 迁移后的验证方法
迁移完成后，一定要做切换测试。方法很简单：在冗余CPU上执行手动主备切换，同时监控IO设备的通信状态和关键过程变量。
我通常会用TIA Portal的在线趋势功能，记录切换前后的几个关键变量，看是否有跳变或中断。如果变量曲线平滑过渡，说明S2工作正常。如果有明显断点，就要回去查原因。
6.4 回退方案
任何变更都要有回退方案。如果S2迁移后出现问题，能快速切回S1。所以迁移前备份项目是必须的，另外最好在停机窗口内操作，避免影响生产。
7. 几个容易被忽略的细节补充
7.1 S2模式下的网络负载
S2模式下，每个IO设备要维护两条AR，这意味着网络上的通信量会增加。虽然PROFINET的带宽通常够用，但在设备数量多、通信周期短的大型系统里，还是要关注网络负载。可以用交换机的端口统计功能或者网络分析工具看看实际负载情况。
7.2 冗余CPU的固件版本一致性
两个冗余CPU的固件版本必须一致，这是基本要求。但很多人不知道的是，固件版本还会影响S2的支持能力。较老的固件可能对S2的支持不完善，建议使用较新的、经过验证的固件版本。
7.3 IO设备的GSD文件版本
第三方IO设备需要通过GSD文件集成到TIA Portal。GSD文件的版本会影响设备支持的冗余模式。如果GSD文件较老，可能只支持S1。遇到这种情况，去设备厂商官网找最新GSD文件更新。
7.4 系统冗余与介质冗余的区别
这两个概念容易混淆。系统冗余指的是CPU层面的冗余，即S7-1500R/H的主备架构。介质冗余指的是网络层面的冗余，比如环网。S1/S2模式是系统冗余范畴的概念，跟介质冗余不是一回事。但两者会相互影响，比如环网中断时，S2设备的双连接可能提供额外的通信路径保障。
7.5 实际项目中的经验数值
根据我参与过的几个项目，分享一些经验数值供参考：
- S2模式下，ET200SP的切换中断时间通常在20-50ms
- S1模式下，同样的设备切换中断时间可能在200-500ms
- 看门狗时间设置：S2建议100-300ms，S1建议500-1000ms
- 大型系统（50+ IO设备）中，S2模式对网络负载的增加大约在10-20%
这些数值不是绝对的，跟具体设备、网络架构、通信周期都有关系，但可以作为一个起点。
8. 写在最后的一些个人体会
搞冗余系统这些年，我最大的体会是：冗余不是万能的，配置不当的冗余可能比不冗余还糟糕。S1和S2的选择只是其中一个环节，但恰恰是很多问题的根源。
我的建议是，在项目设计阶段就把S1/S2的问题考虑进去，不要等到调试时才发现设备不支持或者切换有问题。选型时多问一句"这个设备支持S2吗"，组态时多看一眼冗余设置，调试时多做一次切换测试，能省下后面大量的排查时间。
另外，不要迷信文档。文档告诉你的是"应该怎样"，但现场情况千变万化。我遇到过设备手册说支持S2但实际不行的，也遇到过文档没提但实际能用的。最终还是要以实测为准。
最后说个小事。有一次调试，S2怎么都配不通，查了半天发现是网线的问题——一根劣质网线导致其中一个CPU的通信不稳定，AR时断时续。换线之后一切正常。所以有时候问题不在配置，而在最基础的物理层。排查的时候别忘了从最简单的可能性开始。
