企业官网建设流程全解析

简介：西门子PLC软冗余程序源码包，面向工业自动化领域工程师与PLC开发者，可解决关键设备单点故障引发的停机问题。压缩包共690个文件，大小2.51MB，内含dbf、mdx、dbt等数据库支撑文件，以及s7h、s7p、xml等西门子工程配置，便于剖析冗余系统数据交互与心跳维持机制，文件类型覆盖工程组态、数据库索引与运行锁存等场景。已有89人参与学习。透过源码可掌握S7-400H或S7-1500软冗余的组态方式、主备切换流程、错误处理与状态同步逻辑；涵盖冗余配置、故障转移、数据一致性、性能监控与日常维护等实践环节，并理解TIA Portal中如何实现冗余程序编程。该实例既能作为入门进阶教材，也可直接参考搭建高可用自动化系统，适用于过程控制与设备维护项目。

1. 西门子PLC软冗余解决什么问题：两台普通S7-300也能做主备切换

水处理泵站、电厂辅控、连续生产线，这类场合最怕的不是程序写错，而是PLC单站故障后整条工艺跟着停。砸钱上S7-400H纯冗余系统当然稳，但预算经常不允许。西门子PLC项目里还有一条更省的路：用两台普通S7-300 CPU，配合Siemens官方软冗余（Software Redundancy）包，在软件层做主备判定和数据同步，实现故障切换。标题里这份软冗余源码zip，就是这类工程最常见的参考程序。它不换控制器、不加专用冗余模块，只靠组态和程序把单CPU故障的停机风险压下去。适合正在做连续控制改造、有STEP7基础、不想动IO柜的工程师。

2. 软冗余不是硬冗余：S7-300软冗余的架构、切换时间与选型理由

2.1 软冗余与硬冗余的本质区别：软件判定、链路交接、秒级接管

S7-400H硬冗余是系统级冗余，靠专用同步模块和同步光纤，把两个CPU的过程映像、定时器和数据块做毫秒级同步，故障时几乎无扰切换。软冗余则是纯软件方案：两个独立运行的S7-300 CPU之间，通过一条普通通信链路（MPI、PROFIBUS或工业以太网）传递心跳和数据。主站在每个扫描周期把需要同步的数据区打包发出去，备站收不到主站心跳超过设定时间，就判定主站离线，然后激活自己那侧的DP总线，接管控制权。

这里最容易被误解的是切换速度。软冗余的切换是秒级而不是毫秒级，切换期间从站输出大概率会有一个短暂的保持或中断窗口，具体长短取决于监控间隔和看门狗时间设置。下表是我常用的一组对比：

所以软冗余的本质是"倒主备"，不是信号无扰冗余。工艺上必须能接受短时间输出波动，否则软冗余会变成一个让你更担心的黑匣子。

2.2 典型拓扑：两个S7-300 CPU、一条冗余连接和双通道DP从站

软冗余的标准拓扑并不复杂。两套S7-300站，CPU建议同型号同固件，各自带DP或PN口。两个CPU之间必须有独立的一条冗余连接，通常用工业以太网直连或MPI线，这条线专门走心跳和同步数据，不要和HMI、上位机共享交换机。

关键在于DP从站侧。软冗余要求关键IO挂在支持双口接入的DP从站上，也就是同一个从站同时接入CPU1和CPU2各自的两条DP总线。主站持有总线激活权时，从站和它通信；主站故障后备站激活自己的DP链路，接管同一批从站。这样IO点物理上只接一套设备，但逻辑上两个CPU都能访问。

最容易在这里翻车的做法，是把重要输出放到CPU本地机架或普通单口从站上。备站接管后根本无法访问这些IO，输出自然接管不了。我在早期项目里就因为这个，把切换逻辑调了两天，最后发现备站接管的DP链路上根本没有那个输出模块。

2.3 什么时候值得选软冗余：秒级中断可接受、预算有限、改造不动柜

选软冗余前，先问自己三个问题：故障切换时几十毫秒到几秒的输出中断，工艺能不能扛住？IO点数是不是集中在远程站且从站能改成双口接入？改造是不是不允许动IO柜和现场接线？三个答案都是肯定，那软冗余就是个高性价比方案。

典型场景比如ABB变频器与西门子PLC组成的传动柜，变频器通过DP总线挂在远程站下，PLC掉站后变频器可以保持自身频率继续运行几秒；再比如基于西门子PLC的大棚灌溉泵站，水泵和阀门是慢响应设备，切换期间短时失联影响不大。这些场合用软冗余，比直接上硬冗余省下大半控制器成本。

反过来，高速运动控制、需要精确位置保持的工艺、IO全部在本机架硬线的老设备，都不适合软冗余。前两种是切换时间扛不住，后一种是备站根本接不了IO。与其硬上，不如把钱花在备用机或工艺侧的安全联锁上。

3. 把软冗余源码例子跑起来：STEP7组态、冗余连接与同步区

3.1 拿到zip先别急着解压：确认项目版本、冗余包与授权

解压前先把zip内容列出来看一眼。老项目的源码包通常包含完整的STEP7项目文件夹和说明文档，但这里有个坑：西门子STEP7工程导出时可能被压缩成项目归档格式（.zip或.rar内部是归档结构），直接用解压工具解开后，双击项目文件不一定打得开，需要用STEP7自带的"恢复项目"功能先还原。

# 先列内容确认结构，不要直接拖出来 unzip -l Siemens软冗余例子.zip # 有校验文件就对一下，避免拿到损坏的包 sha256sum Siemens软冗余例子.zip

拿到包后先确认三件事：项目是STEP7 V5.x工程还是TIA Portal工程；源码里依赖的SoftRedundancy包版本是多少；两个CPU是不是同一系列同一固件。老例子大部分是STEP7 V5.5环境下的S7-300工程，因为软冗余包在V5.x用得最多。如果只有一个项目文件，没有对应的SoftRedundancy软件包，后面编译会报缺块错误。

3.2 同一个STEP7项目里组态两台S7-300站，关键IO要落在DP从站上

软冗余的前提是两台站必须在同一个STEP7项目里，只有这样才能在NetPro里建立两个CPU之间的冗余连接。单独建两个项目再拷贝，是走不通的。

组态步骤一般是：新建一个项目，插入两个SIMATIC 300站点，两个站分别配CPU和机架。两个CPU型号最好完全一致，DP接口版本和固件也要一致，备站和主站的硬件配置差异越少，切换逻辑越不容易出边界问题。我这里提一个容易踩的细节：CPU的MPI地址、DP地址和以太网IP都要在设计阶段定死，两台站即使不在同一网段，也必须保证有两台站都能独立访问的公共通道，也就是那根冗余连接。

组态时把从站挂到DP总线上，并给每个CPU建立各自的DP子网。主站侧总线上挂着从站，备站侧总线上也要挂同一批从站，两边从站的模块配置、槽位顺序、IO地址分配必须完全一致。这样两个CPU访问同一个物理从站时，程序里的地址才能对齐。IO规划上，关键输出和高频输入一定放在这个双口DP从站上，本地机架IO只放非关键信号。

3.3 NetPro中建立冗余连接：连接号是后面编程的钥匙

硬件组态完成后，切到NetPro视图，选中两个CPU，右键选择新连接，类型选软冗余连接。这一步执行完，NetPro会自动生成一条两个CPU之间的软冗余连接，同时分配一个连接号。这个连接号后面在OB100里调用CSS_300时要用，务必记录下来。

常见做法是给冗余连接单独分配一个网络，不跟普通MPI或以太网混在一起。我一般会把冗余连接放在CPU自带的第二个通信口上，这样即使现场过程网络广播风暴，冗余链路也不受影响。连接建立后，把从站在两条DP子网上都激活，编译保存，确认没有组态错误。

// NetPro里的冗余连接配置，会在项目后台生成连接相关信息 // 后续OB100初始化时会用到连接号SG，同一个站号在两台CPU里配置不同

3.4 同步区设置：把要同步的DB和M区标记成"冗余数据区"

软冗余不是把整个CPU内容都备份一份，而是只同步你在配置里指定的数据区。常见做法是在SoftRedundancy配置界面里，把需要同步的M区范围（例如M0.0到M255.7）和DB编号（例如DB100到DB150）填写进去。

同步区的设计原则是：只同步控制逻辑的中间状态、输出缓存、报警字和关键全局变量。不同步大数据量数组、配方表、累计流量这类只在主站快速变化的内容。原因有两个：一是同步数据量太大会拖慢冗余连接，导致主站心跳超时；二是备站拿到的可能是中间数据，切换后数据一致性反而变差。

这里常遇到的问题，是备站CPU里没有对应的DB块。主站程序运行中会自动创建DB，但备站如果一直跑在"备"状态，有些空DB可能没有被创建，导致同步报错。我在例子里验证过的做法是：把需要同步的DB在OB100初始化阶段就主动建好，不依赖运行时创建。

4. 例子里最关键的编程块：OB100初始化、FB101与三个必调参数

4.1 OB100里建立软冗余连接：CSS_300与初始化参数

软冗余的初始化组织块是OB100，只在CPU暖启动时执行一次。初始化要完成两件事：调用FC220（CSS_300）建立软冗余连接，调用FB101（RED_DP）激活DP冗余切换。下面的STL写法是SoftRedundancy例子里的经典结构：

// OB100: 暖启动只跑一次，软冗余连接在这里建立 // 注意两个CPU的站点号不同，连接号保持一致 CALL "CSS_300", "DB_CSS_PARAM" // FC220，建立软冗余连接 SG := 1 // 冗余连接号，与NetPro配置一致 SS := 1 // 本站站点号：CPU1填1，CPU2填2 DB_NO:= 100 // 连接参数DB块编号 CALL "RED_DP", "DB_RED_PARAM" // FB101，激活DP主站冗余

这段代码的关键是SG和SS两个参数。SG是冗余连接号，必须和NetPro里建立的软冗余连接对应，两个CPU填同一个值；SS是本站站点号，CPU1填1、CPU2填2，两站相反。每次扫描周期都要调用FB101，但FC220只在OB100里调用一次。

不要试图在OB1里再调用FC220去重新建立连接。软冗余连接一旦建立就持续运行，重复初始化会让两个CPU之间的连接状态错乱。我见过有同事因为备站一直报连接断开，就在OB1里反复调用FC220，结果把冗余连接彻底搞崩，最后复位CPU才恢复。

4.2 OB1里调用FB101：主站执行逻辑，备站只同步不输出

OB1每个扫描周期必须调用一次FB101，冗余管理器会返回本站是否持有输出控制权。把这个状态位读出来，用于主备逻辑分支。这里强调一件事：不要给FB101和CSS_300的调用加EN/ENO能流。有段时间我也习惯给每个块都带EN/ENO判断，但在软冗余调用里，一旦某个周期ENO被前面的逻辑清零，冗余管理器这个周期就没有被调用，备站会立刻判定主站失联，可能引发一次本不存在的切换。冗余调用必须无条件执行，放在OB1的最前面，且不允许被条件跳转跳过。

// OB1 起始段，每个周期无条件调用一次 CALL "RED_DP", "DB_RED_PARAM" // FB101，冗余管理器 DPG := 1 // DP主站接口号 MODE := 1 // 1=自动切换模式 // 读取本站是否持有控制权 L "DB_RED_PARAM".OUT_CTRL T #Is_Master

主站分支里放真正的控制逻辑，备站分支只做输入采集和中间变量刷新，输出保持安全值。备站必须以最新输入状态持续运行控制逻辑的纯计算部分，这样切换后输出才不是从旧状态跳变，而是从当前工艺状态继续。输出写指令只在#Is_Master为1时执行。

4.3 三个必调参数：监控间隔、切换延时与看门狗时间

软冗余的稳定性，基本由三个时间参数决定。下面这张表是我在多个项目里调过的经验值：

这三个值本质是一条时间轴：心跳间隔 < 故障确认延时 < 看门狗时间。最稳妥的做法是先按默认值跑起来，观察几个正常生产周期，再逐步把故障确认延时调大。我曾经把故障确认延时直接设成200ms，结果现场一个DP头氧化导致的偶发闪断就触发了切换，整个工艺停车。那次的教训是：软冗余的切换不是越灵敏越好，你要防的是主站真实故障，不是通信线上的一次抖动。

5. 软冗余常见故障排查：切换失败、输出抖动与误切换

5.1 备站始终接不了班：软冗余授权没装全

现象：备站状态一直显示"热备"但迟迟不接管，手动切换也不动作。

原因：SoftRedundancy软件包是带授权的。常见做法是在安装时把授权装到编程器上，但没有复制到两个CPU的存储卡里。没有授权的CPU调用FB101时会锁死，返回值停在某个错误码上，主备切换根本不会触发。

解决：用授权管理器把软冗余授权分别安装到两个CPU的存储卡里，注意不是只装一台。我在调试时会直接在OB1里把FB101的返回值传到一个监控变量上，每次切换失败先看返回码，再对着手册查原因，比拿万用表量信号可靠得多。

5.2 切换瞬间输出掉0，工艺直接停机

现象：断电模拟测试时，主站断电瞬间，现场阀门或变频器给定信号掉0，工艺联锁停机。

原因：备站接管DP总线需要时间。总线激活权交接期间，从站输出模块收到的是总线离线状态，如果模块配置成"故障置0"，输出就会掉0。再加上备站接管后第一个扫描周期才刷新输出缓存，这中间就出现了一个危险的输出窗口。

解决：在程序里加输出仲裁机制。输出值先写到冗余DB里的缓存区，只有确认本站持有控制权后的下一个扫描周期再送物理输出；同时把DP从站输出模块的故障响应配置成"保持上一值"。这样切换窗口内输出至少不会掉0。工艺侧再配合做短时允许波动，切换就相对平顺了。

5.3 CPU亮SF灯，FB101报错：两个站的同步区配置不一致

现象：CPU正常RUN，但SF灯常亮，诊断缓冲区显示软冗余调用报错。

原因：两个CPU的同步区配置不一致，最常见的是主站侧同步了DB200，备站侧没同步DB200，或者备站里根本没有这个DB。FB101在尝试同步不存在的块时报错，冗余连接被拉断。

解决：检查两个站的同步数据区配置，必须完全一致。备站侧把需要同步的DB都建好，哪怕不填数据也要建空壳。换个说法，这一步考验的是耐心：把主站侧同步区的DB列表导出来，对照备站逐个人工核对。我一般用变量表同时监视两个CPU的DB长度，不一致的地方一眼就能看出来。

5.4 一天切换好几次，明明DP站没故障：监控时间太短，把网络抖动当成主站离线

现象：生产正常时系统突然切换，切换后又正常，一天内反复多次，检查DP链路并没有真实故障。

原因：故障确认延时设置太短，冗余连接上一个通信超时脉冲就被判定为主站离线。常见诱因是冗余连接和HMI、上位机混用了同一个交换机，现场有人随手插拔网线，或广播报文引发瞬时拥塞。

解决：把故障确认延时调大，建议从当前值翻倍开始试；冗余连接单独走CPU的第二通信口直连，不经过交换机。这类问题最玄学，十个里面有八个是网络基础设施问题而不是软冗余程序问题。调整完参数后在现场运行一周再观察切换次数，确认没有反复。

5.5 切换后数据对不上：被同步块里有实时数据或局部状态

现象：强制切换成功，但备站接管后某些设定值、累计值变成旧数据或零值。

原因：同步区里包含了不适合同步的数据。比如系统时钟、PID积分项、累计流量这类变量，要么由各CPU独立计时，要么更新频率高于同步频率，备站拿到的映像本身就是滞后的。

解决：重新梳理同步区，把"只有主站运行时才有意义"的变量移出去。常见做法是给关键中间量建一个专门的同步DB，把需要保持一致的变量压缩进来，例如输出缓存、运行模式、手自动标志、报警字。累计量单独处理——主站在DB里累计并把累计值周期写入同步区，备站只读不写，切换后以这个值为基础继续累计。

6. 验证方法与实践技巧：停电模拟测试和强制切换压测

6.1 停电模拟测试是唯一能证明软冗余能用的手段

仿真和在线调试都验证不了软冗余，唯一有效的手段是停电模拟测试。在工艺允许的时间窗口里，直接断掉主站CPU电源，或者拔掉主站DP总线头，观察备站是否接管、输出是否抖动、报警是否正常触发。测试至少做三次：主站掉电、冗余连接中断、主站CPU故障停机，各测一组。如果条件允许，用Process SIMULATE通过OPC UA与西门子PLC建仿真环境，先把切换逻辑跑几十次再上真设备。

6.2 给切换加"手动/自动"选择，压测切换时间

我习惯在程序里加一个手动/自动切换选择位。自动模式用默认的监控判定；手动模式通过FC222断开主站侧冗余连接、FC223把备站接入，人为控制切换窗口。这样测试时不需要反复断电，直接强制切换，还能把切换时间压到工艺允许的下限。

做软冗余这些年，我最大的教训是：备站不报错、CPU不停机，不等于切换能成功。后来每次交付前都做至少三次断电测试，就是因为最早那次切换窗口输出没保持、备站同步DB少一块，都是启动阶段完全看不出来的问题。软冗余的"冗余"是软件兜底，不是硬件兜底，你的验证必须比故障更狠。希望帮到你。

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