拓冰网站定制 
简介这是一份围绕WinCC冗余服务器配置的实战型实验文档适合从事工业现场监控、需要搭建高可用西门子WinCC系统的自动化工程师与技术支持人员。文档完整呈现了两台电脑通过串口电缆组成冗余系统的实验条件详细记录Server Master主服务器的组态过程包括多用户项目创建、Alarm Logging模拟量上限报警配置、变量归档与画面组态、冗余激活及局域网时钟同步并说明了使用项目复制器生成Server Data及从服务器端打开复制项目的衔接流程。内容以操作步骤为主线结合故障模拟来验证冗余切换和数据同步便于读者复现实验或在真实项目中迁移使用。资源为单个doc文档仅1个文件约687KB适合随时随地查阅已有386人学习浏览对希望快速入门WinCC冗余配置的读者具有参考价值。1. 冗余服务器到底是什么以及在什么场景下能真正救场在连续生产的现场一台 WinCC 服务器一旦宕机丢失的不只是一段画面可能是伴随生产异常产生的报警记录和趋势数据。WinCC 冗余服务器就是为了避免这种单点故障两台装有 WinCC Server 和 Redundancy 选件的电脑一台作为 Master一台作为 Standby通过串口电缆或专用网络保持连接。正常情况下 Standby 处于热备状态主服务器故障时自动切换恢复后再把故障期间的报警和归档补回从站。这次实验完整走了一遍 WinCC 冗余服务器的配置从组建多用户项目、配置报警和归档到激活冗余、项目复制、断网切换和同步验证把每一步的关键参数和容易忽略的点拆开来说。适合正在做双服务器冗余方案选型的自动化工程师也适合已经配置完但对同步机制还不放心的维护人员。2. 从单站到冗余项目组态与报警归档配置2.1 多用户项目冗余的起点是“两台服务器都认识同一个项目”冗余实验的第一步不是直接装 Redundancy 选件而是把 WinCC 项目建为多用户项目。单用户项目没法挂从服务器之后的项目复制器也复制不出“服务器对”。新建项目时选择多用户项目服务器类型保留为 Server。两台实验机的参数如下表生产环境同样适用只是 IP 要按控制网规划角色计算机名IP 地址用户名密码Server MasterWINCC1192.168.0.1Siemens123456Server StandbyWINCC2192.168.0.2Siemens123456注意看两台机器的用户名、密码完全一致。WinCC 运行时服务之间通讯要用同一组 Windows 账户否则后续同步建立不起来。IP 固定不要用 DHCP。我在几个项目上见过两台服务器都接到办公网结果 IP 冲突导致同步断开后面排查了很久。建议先确认两台机器能互 ping 再进入下一步:: 检查从服务器是否能访问主服务器 ping 192.168.0.1 -n 2 :: 检查主服务器是否能访问从服务器 ping 192.168.0.2 -n 2-n 2表示只发两个回显请求能通即可。如果不同先查网卡和防火墙是否关闭了 ICMP 回显再确认两块网卡是否真在同一个广播域里。2.2 变量和 Alarm Logging报警信息是一点一点组出来的在主服务器 WINCC1 上新建一个内部变量例如 t1数据类型选浮点数 32 位。冗余同步的报警测试依赖这个变量手动改它的值来制造报警比外接真实 PLC 信号简单得多。接着打开 Alarm Logging在 Tools 菜单下打开 Add Ins创建模拟量报警。具体是右键 Analog Alarm 后选择 New再右键 t1 变量下的条目去定义报警属性。“模拟量上限报警”的含义是当 t1 超过阈值时产生一条上限报警。阈值设多大取决于你要测试的记录粒度。我一般先设成 90然后在画面里用 I/O 域把 t1 从 30 改到 95报警就会出现好控制。再用 VBS 脚本验证变量能不能正常读写 WinCC 全局脚本中读取变量 t1 的值并弹出显示 Dim tag Set tag HMIRuntime.Tags(t1) tag.Read MsgBox t1 tag.ValueHMIRuntime.Tags(t1)是 WinCC 运行系统的变量对象Read触发一次读取tag.Value返回当前值。如果弹出正常说明变量组态没问题如果提示类型不匹配看看变量类型和脚本里是否一致。别忘了生成系统消息在 Alarm Logging 菜单 Tools - WinCC-System Messages - Create。这些系统消息不是普通报警而是 WinCC 自身运行状态的入口后面判断冗余建立和同步是否完成全靠它们。2.3 Tag Logging归档名先规划好不然同步很头痛Tag Logging 解决的是趋势问题。打开 Tag Logging 后右键 Archives用 Archives Wizard 创建归档a1再选择变量t1。归档名字别看是小事同步和趋势组态都依赖它。归档名建议用字母加数字不要用中文不要带空格。举个例子用Process1这样的名字后面在趋势窗口里按归档名找变量会很直接。如果用了中文某些旧版本 WinCC 的归档路径会出现乱码冗余复制时甚至可能中止。创建完成后要确认采集周期和归档周期。默认 1 秒采集一次实验里够用生产环境下要按信号的实时性要求来调整否则归档文件会涨得很快同步时间也会被拉长。2.4 画面与运行系统把报警和趋势暴露给操作员实验里创建画面放三个元素一个 I/O 域连着变量 t1用来改值和观察一个报警消息窗口用来显示报警一个趋势窗口连接变量 t1 和归档 a1用来确认归档曲线在故障切换期间有没有断点。最后在计算机属性里勾选 “Alarm Logging Runtime” 和 “Tag Logging Runtime”。这一步容易漏漏了之后画面上不报错但报警消息窗口和趋势窗口都是空的。建议先只激活主服务器跑一遍画面确认报警能出、趋势能画再进入下一步的冗余配置不要等到做故障切换时才倒回来查基础功能。3. 冗余激活、时间同步与项目复制的顺序不能乱3.1 三个选件的作用不是一回事实验条件里列出两台电脑都装有 WinCC RC、WinCC Server 和 Redundancy 选件还有 Options-Basic Process Control。这些选件的分工是WinCC RC 负责客户端和组态界面Options-Server 把单站变成服务器Options-Redundancy 提供双机冗余Options-Basic Process Control 则是面向过程控制库的扩展和冗余没有强依赖。冗余实验的关键是前三个缺一个都不行。选件是否必须作用WinCC RC是组态和运行环境Options-Server是启用服务器角色Options-Redundancy是提供双机同步与切换Options-Basic Process Control否过程控制扩展画面库如果你在 Windows 上装了 WinCC 但没有 Options-Redundancy 的授权Redundancy 项根本不会出现在项目管理器里。装完选件后建议先用授权管理器查一遍确认四个选项都已激活避免最后激活运行系统时提示缺少选件导致整个项目启动失败。3.2 Redundancy 项激活后先看伙伴服务器是否配对在主服务器项目里右键 Redundancy 项激活冗余Partner Server 选择 WINCC2。这里的“激活冗余”不是启动运行而是让工程项目具备冗余特性。组态完成后两台机器的角色会按当前项目所在的位置自动判断在 WINCC1 上打开项目本地是 Server Master伙伴是 Standby复制到 WINCC2 上打开角色互换。有一个容易踩的坑Partner Server 名称要和计算机名完全一致而且要区分大小写。如果 WINCC2 的计算机名后来改过必须在 Redundancy 项里重新选择否则项目复制过去后从服务器找不到伙伴服务器系统消息里会一直报连接失败。3.3 时间同步一分钟的偏差会在故障切换时放大两机时间不同步最直接的影响是归档对齐不上。主服务器故障期间的报警和趋势曲线在恢复同步后要按时间戳合并到从服务器时间基准不一致同步结果就存在偏差。实验里在 Redundancy 项选择 Time Synchronization以计算机 WINCC1 的时钟为参考每分钟发送一次时钟。这个周期不长实验环境可用生产环境建议直接用公司内部 NTP 服务器避免外部公共时间源不可达时两台服务器各自漂移。手动校时可以用 Windows 自带命令来验证:: 以 WINCC1 为时间源立即同步本机时钟 net time \\WINCC1 /set /yesnet time从指定计算机获取当前时间/set表示立即用该时间设置本机/yes跳过确认提示。如果这个命令提示拒绝访问检查当前登录用户是否有权限这也是冗余服务器之间正常工作的前提之一。两个机器的 Windows 账户权限不对等经常成为同步失败的隐藏原因。3.4 项目复制器从主服务器到从服务器的唯一标准路径在主服务器的 WinCC Explorer 里打开 WinCC 工具菜单下的项目复制器。源选主服务器的项目目标是从服务器的项目目录地址。注意目标项目不能处于打开状态而且 WINCC2 上最好还没创建同名项目否则复制器会提示目标已存在。按 Duplicate 后等待提示复制完成。这个提示不是随意的它包含项目名、目标路径和复制结果。复制完成后去 WINCC2 打开复制过来的项目Redundancy 项里的 Server 会自动变成 WINCC2伙伴服务器变成 WINCC1。这一条就是判断复制是否成功的最直观信号如果 Server 还显示 WINCC1说明打开的项目不对或者复制器选错了目标路径。项目复制器是唯一推荐的做法不要手动拷贝整个项目文件那样会丢失服务器角色和冗余配置项。4. 故障切换与数据同步的实测把断网、恢复和 15 分钟等待还原出来4.1 先主后从的启动顺序激活冗余时要先激活主服务器 WINCC1等运行系统完全起来后再激活从服务器 WINCC2。在 WinCC 报警记录的系统消息窗口里能看到冗余建立的消息这表明两台服务器的握手已完成。先激活从服务器不是不行但主服务器会反复尝试连接伙伴系统消息里会出现大量网络超时条目。实验环境无所谓生产环境最好不要这样做因为反复重连会增加不必要的磁盘和网络 IO也可能干扰正在运行中的控制画面。4.2 模拟网络故障拔网线、禁网卡或者拉交换机电源实验原文是“断开其中一台的网络”。常见做法是拔掉 WINCC1 的网线或者禁用主服务器的网卡。禁用网卡比拔线更干净还能避免网口松动引起的误判。用 PowerShell 在管理员权限下执行# 禁用主服务器网卡模拟网络故障 Disable-NetAdapter -Name 以太网 -Confirm:$false Start-Sleep -Seconds 120 # 120 秒后恢复网络 Enable-NetAdapter -Name 以太网 -Confirm:$falseDisable-NetAdapter会立即断开指定网卡-Confirm:$false跳过二次确认Start-Sleep控制故障持续 120 秒之后再恢复。这一段脚本对 WINCC1 执行就模拟了主服务器在冗余网络里“消失”两分钟。如果你的网卡名不叫“以太网”先执行Get-NetAdapter查看实际名称再替换到脚本里。4.3 故障期间的报警与归档行为在 WINCC1 断网的 2 分钟内在主服务器画面上继续把 t1 从 30 改到 95触发上限报警。此时要记录报警产生的大致时间点。注意一个关键现象这个动作是在已经失联的主服务器上做的所以这笔报警和历史数据暂时只会记录在主服务器本地从服务器 WINCC2 虽然接管了画面显示但还没有这笔数据。如果想让测试更可控可以在Start-Sleep期间用脚本自动改写 t1避免人工操作跟不上脚本恢复时间。这就是冗余同步的核心价值数据并没有丢只是暂时游离在主服务器侧等待网络恢复后补回从站。4.4 恢复网络后的同步日志与系统消息解读重新启用网卡后两台机器重新建立连接此时系统消息窗口会依次出现两条关键信息系统消息文本含义Synchronization launched冗余数据同步开始网络恢复后自动触发Synchronization finished同步完成主从归档一致Synchronization launched 出现时不要继续做任何写变量操作更不要关掉任何一台服务器。同步过程要基于归档文件做块级复制耗时取决于变量数量、归档文件大小和网络带宽。实验里等了 10-15 分钟才算完我的经验是如果只测两个变量10 分钟属于正常范围如果变量上千即使走千兆网也可能要 30-60 分钟尤其是归档文件长时间未拆包时。4.5 验证最终一致性报警、归档一个都不能少同步完成后在两台机器上分别打开报警消息窗口和趋势窗口对比故障期间的记录。趋势窗口特别值得放大看故障时间段的曲线在从站上恢复后应该是连续的没有空洞。另外用 PowerShell 查看两台机器当前时间Get-Date Get-Date -ComputerName WINCC1这两行分别取本机WINCC2时间和主服务器时间。如果误差超过你配置的时间同步周期说明时间同步没生效归档时间戳会对不齐需要重新检查 Time Synchronization 设置以及 Windows 时间服务的启动类型。5. 冗余同步的边界与调优从实验环境到生产现场的改动5.1 串口电缆不是生产环境的长久之计实验里用一根串口电缆连接两台机器速度和稳定性都有限。生产环境一般把冗余独立成一个以太网网段两台服务器各加一张网卡用网线直连或通过交换机互连分配一个独立地址段。例如实验网段 192.168.0.x冗余网段设置为 10.10.10.1 和 10.10.10.2覆盖完控制网再覆盖冗余网。这样办公网瘫痪时冗余同步数据也能走独立通道反过来大数据量的归档同步也不会干扰过程控制网上的实时通讯。5.2 缩短同步时间比想象中更需要做归档规划同步时间长多半不是网络慢而是归档文件又大又碎。如果项目里变量数量多同步时间可能从 15 分钟拉到 1 小时以上。常见做法是把高频快速归档和低频过程归档分开建不要所有变量挤在一个归档里同时把趋势窗口加载的归档范围缩小避免启动时一次性读入整段历史数据。还有一点容易被忽略WinCC 服务器本身的内存和页面文件大小。同步过程对磁盘 IO 压力很大磁盘读写慢比网络带宽更容易成为瓶颈条件允许时给两台服务器都配上 SSD。5.3 用脚本监控冗余状态把验证变成习惯与其每次故障都去翻 WinCC 系统消息不如让日志主动记录网络的连通性。下面脚本可以在 WINCC2 上定时检测主服务器访问状态并把结果写入日志文件# 检查主服务器 WINCC1 是否可访问结果追加到日志 $result Test-Connection -ComputerName WINCC1 -Count 1 -Quiet {0} - Ping {1} : {2} -f (Get-Date), WINCC1, ($(if ($result) { OK } else { FAIL })) | Out-File C:\Logs\redundancy_check.log -AppendTest-Connection是 PowerShell 的 ping 封装-Count 1只发一个回显请求-Quiet返回布尔值。脚本放到 Windows 计划任务里每分钟跑一次故障发生的时间点就能和 WinCC 系统消息互相对照。如果你还想连从服务器服务状态一起看可以在脚本里追加Get-Service过滤 WinCC 相关服务名再把服务名和 Status 一起写入日志。这样即使 WinCC 画面上没有人在盯日志也能长期记录冗余健康状态故障切换实验才有可追溯的验证依据。本文还有配套的精品资源点击获取 WinCC冗余服务器配置实战：从组态到故障切换同步验证
简介这是一份围绕WinCC冗余服务器配置的实战型实验文档适合从事工业现场监控、需要搭建高可用西门子WinCC系统的自动化工程师与技术支持人员。文档完整呈现了两台电脑通过串口电缆组成冗余系统的实验条件详细记录Server Master主服务器的组态过程包括多用户项目创建、Alarm Logging模拟量上限报警配置、变量归档与画面组态、冗余激活及局域网时钟同步并说明了使用项目复制器生成Server Data及从服务器端打开复制项目的衔接流程。内容以操作步骤为主线结合故障模拟来验证冗余切换和数据同步便于读者复现实验或在真实项目中迁移使用。资源为单个doc文档仅1个文件约687KB适合随时随地查阅已有386人学习浏览对希望快速入门WinCC冗余配置的读者具有参考价值。1. 冗余服务器到底是什么以及在什么场景下能真正救场在连续生产的现场一台 WinCC 服务器一旦宕机丢失的不只是一段画面可能是伴随生产异常产生的报警记录和趋势数据。WinCC 冗余服务器就是为了避免这种单点故障两台装有 WinCC Server 和 Redundancy 选件的电脑一台作为 Master一台作为 Standby通过串口电缆或专用网络保持连接。正常情况下 Standby 处于热备状态主服务器故障时自动切换恢复后再把故障期间的报警和归档补回从站。这次实验完整走了一遍 WinCC 冗余服务器的配置从组建多用户项目、配置报警和归档到激活冗余、项目复制、断网切换和同步验证把每一步的关键参数和容易忽略的点拆开来说。适合正在做双服务器冗余方案选型的自动化工程师也适合已经配置完但对同步机制还不放心的维护人员。2. 从单站到冗余项目组态与报警归档配置2.1 多用户项目冗余的起点是“两台服务器都认识同一个项目”冗余实验的第一步不是直接装 Redundancy 选件而是把 WinCC 项目建为多用户项目。单用户项目没法挂从服务器之后的项目复制器也复制不出“服务器对”。新建项目时选择多用户项目服务器类型保留为 Server。两台实验机的参数如下表生产环境同样适用只是 IP 要按控制网规划角色计算机名IP 地址用户名密码Server MasterWINCC1192.168.0.1Siemens123456Server StandbyWINCC2192.168.0.2Siemens123456注意看两台机器的用户名、密码完全一致。WinCC 运行时服务之间通讯要用同一组 Windows 账户否则后续同步建立不起来。IP 固定不要用 DHCP。我在几个项目上见过两台服务器都接到办公网结果 IP 冲突导致同步断开后面排查了很久。建议先确认两台机器能互 ping 再进入下一步:: 检查从服务器是否能访问主服务器 ping 192.168.0.1 -n 2 :: 检查主服务器是否能访问从服务器 ping 192.168.0.2 -n 2-n 2表示只发两个回显请求能通即可。如果不同先查网卡和防火墙是否关闭了 ICMP 回显再确认两块网卡是否真在同一个广播域里。2.2 变量和 Alarm Logging报警信息是一点一点组出来的在主服务器 WINCC1 上新建一个内部变量例如 t1数据类型选浮点数 32 位。冗余同步的报警测试依赖这个变量手动改它的值来制造报警比外接真实 PLC 信号简单得多。接着打开 Alarm Logging在 Tools 菜单下打开 Add Ins创建模拟量报警。具体是右键 Analog Alarm 后选择 New再右键 t1 变量下的条目去定义报警属性。“模拟量上限报警”的含义是当 t1 超过阈值时产生一条上限报警。阈值设多大取决于你要测试的记录粒度。我一般先设成 90然后在画面里用 I/O 域把 t1 从 30 改到 95报警就会出现好控制。再用 VBS 脚本验证变量能不能正常读写 WinCC 全局脚本中读取变量 t1 的值并弹出显示 Dim tag Set tag HMIRuntime.Tags(t1) tag.Read MsgBox t1 tag.ValueHMIRuntime.Tags(t1)是 WinCC 运行系统的变量对象Read触发一次读取tag.Value返回当前值。如果弹出正常说明变量组态没问题如果提示类型不匹配看看变量类型和脚本里是否一致。别忘了生成系统消息在 Alarm Logging 菜单 Tools - WinCC-System Messages - Create。这些系统消息不是普通报警而是 WinCC 自身运行状态的入口后面判断冗余建立和同步是否完成全靠它们。2.3 Tag Logging归档名先规划好不然同步很头痛Tag Logging 解决的是趋势问题。打开 Tag Logging 后右键 Archives用 Archives Wizard 创建归档a1再选择变量t1。归档名字别看是小事同步和趋势组态都依赖它。归档名建议用字母加数字不要用中文不要带空格。举个例子用Process1这样的名字后面在趋势窗口里按归档名找变量会很直接。如果用了中文某些旧版本 WinCC 的归档路径会出现乱码冗余复制时甚至可能中止。创建完成后要确认采集周期和归档周期。默认 1 秒采集一次实验里够用生产环境下要按信号的实时性要求来调整否则归档文件会涨得很快同步时间也会被拉长。2.4 画面与运行系统把报警和趋势暴露给操作员实验里创建画面放三个元素一个 I/O 域连着变量 t1用来改值和观察一个报警消息窗口用来显示报警一个趋势窗口连接变量 t1 和归档 a1用来确认归档曲线在故障切换期间有没有断点。最后在计算机属性里勾选 “Alarm Logging Runtime” 和 “Tag Logging Runtime”。这一步容易漏漏了之后画面上不报错但报警消息窗口和趋势窗口都是空的。建议先只激活主服务器跑一遍画面确认报警能出、趋势能画再进入下一步的冗余配置不要等到做故障切换时才倒回来查基础功能。3. 冗余激活、时间同步与项目复制的顺序不能乱3.1 三个选件的作用不是一回事实验条件里列出两台电脑都装有 WinCC RC、WinCC Server 和 Redundancy 选件还有 Options-Basic Process Control。这些选件的分工是WinCC RC 负责客户端和组态界面Options-Server 把单站变成服务器Options-Redundancy 提供双机冗余Options-Basic Process Control 则是面向过程控制库的扩展和冗余没有强依赖。冗余实验的关键是前三个缺一个都不行。选件是否必须作用WinCC RC是组态和运行环境Options-Server是启用服务器角色Options-Redundancy是提供双机同步与切换Options-Basic Process Control否过程控制扩展画面库如果你在 Windows 上装了 WinCC 但没有 Options-Redundancy 的授权Redundancy 项根本不会出现在项目管理器里。装完选件后建议先用授权管理器查一遍确认四个选项都已激活避免最后激活运行系统时提示缺少选件导致整个项目启动失败。3.2 Redundancy 项激活后先看伙伴服务器是否配对在主服务器项目里右键 Redundancy 项激活冗余Partner Server 选择 WINCC2。这里的“激活冗余”不是启动运行而是让工程项目具备冗余特性。组态完成后两台机器的角色会按当前项目所在的位置自动判断在 WINCC1 上打开项目本地是 Server Master伙伴是 Standby复制到 WINCC2 上打开角色互换。有一个容易踩的坑Partner Server 名称要和计算机名完全一致而且要区分大小写。如果 WINCC2 的计算机名后来改过必须在 Redundancy 项里重新选择否则项目复制过去后从服务器找不到伙伴服务器系统消息里会一直报连接失败。3.3 时间同步一分钟的偏差会在故障切换时放大两机时间不同步最直接的影响是归档对齐不上。主服务器故障期间的报警和趋势曲线在恢复同步后要按时间戳合并到从服务器时间基准不一致同步结果就存在偏差。实验里在 Redundancy 项选择 Time Synchronization以计算机 WINCC1 的时钟为参考每分钟发送一次时钟。这个周期不长实验环境可用生产环境建议直接用公司内部 NTP 服务器避免外部公共时间源不可达时两台服务器各自漂移。手动校时可以用 Windows 自带命令来验证:: 以 WINCC1 为时间源立即同步本机时钟 net time \\WINCC1 /set /yesnet time从指定计算机获取当前时间/set表示立即用该时间设置本机/yes跳过确认提示。如果这个命令提示拒绝访问检查当前登录用户是否有权限这也是冗余服务器之间正常工作的前提之一。两个机器的 Windows 账户权限不对等经常成为同步失败的隐藏原因。3.4 项目复制器从主服务器到从服务器的唯一标准路径在主服务器的 WinCC Explorer 里打开 WinCC 工具菜单下的项目复制器。源选主服务器的项目目标是从服务器的项目目录地址。注意目标项目不能处于打开状态而且 WINCC2 上最好还没创建同名项目否则复制器会提示目标已存在。按 Duplicate 后等待提示复制完成。这个提示不是随意的它包含项目名、目标路径和复制结果。复制完成后去 WINCC2 打开复制过来的项目Redundancy 项里的 Server 会自动变成 WINCC2伙伴服务器变成 WINCC1。这一条就是判断复制是否成功的最直观信号如果 Server 还显示 WINCC1说明打开的项目不对或者复制器选错了目标路径。项目复制器是唯一推荐的做法不要手动拷贝整个项目文件那样会丢失服务器角色和冗余配置项。4. 故障切换与数据同步的实测把断网、恢复和 15 分钟等待还原出来4.1 先主后从的启动顺序激活冗余时要先激活主服务器 WINCC1等运行系统完全起来后再激活从服务器 WINCC2。在 WinCC 报警记录的系统消息窗口里能看到冗余建立的消息这表明两台服务器的握手已完成。先激活从服务器不是不行但主服务器会反复尝试连接伙伴系统消息里会出现大量网络超时条目。实验环境无所谓生产环境最好不要这样做因为反复重连会增加不必要的磁盘和网络 IO也可能干扰正在运行中的控制画面。4.2 模拟网络故障拔网线、禁网卡或者拉交换机电源实验原文是“断开其中一台的网络”。常见做法是拔掉 WINCC1 的网线或者禁用主服务器的网卡。禁用网卡比拔线更干净还能避免网口松动引起的误判。用 PowerShell 在管理员权限下执行# 禁用主服务器网卡模拟网络故障 Disable-NetAdapter -Name 以太网 -Confirm:$false Start-Sleep -Seconds 120 # 120 秒后恢复网络 Enable-NetAdapter -Name 以太网 -Confirm:$falseDisable-NetAdapter会立即断开指定网卡-Confirm:$false跳过二次确认Start-Sleep控制故障持续 120 秒之后再恢复。这一段脚本对 WINCC1 执行就模拟了主服务器在冗余网络里“消失”两分钟。如果你的网卡名不叫“以太网”先执行Get-NetAdapter查看实际名称再替换到脚本里。4.3 故障期间的报警与归档行为在 WINCC1 断网的 2 分钟内在主服务器画面上继续把 t1 从 30 改到 95触发上限报警。此时要记录报警产生的大致时间点。注意一个关键现象这个动作是在已经失联的主服务器上做的所以这笔报警和历史数据暂时只会记录在主服务器本地从服务器 WINCC2 虽然接管了画面显示但还没有这笔数据。如果想让测试更可控可以在Start-Sleep期间用脚本自动改写 t1避免人工操作跟不上脚本恢复时间。这就是冗余同步的核心价值数据并没有丢只是暂时游离在主服务器侧等待网络恢复后补回从站。4.4 恢复网络后的同步日志与系统消息解读重新启用网卡后两台机器重新建立连接此时系统消息窗口会依次出现两条关键信息系统消息文本含义Synchronization launched冗余数据同步开始网络恢复后自动触发Synchronization finished同步完成主从归档一致Synchronization launched 出现时不要继续做任何写变量操作更不要关掉任何一台服务器。同步过程要基于归档文件做块级复制耗时取决于变量数量、归档文件大小和网络带宽。实验里等了 10-15 分钟才算完我的经验是如果只测两个变量10 分钟属于正常范围如果变量上千即使走千兆网也可能要 30-60 分钟尤其是归档文件长时间未拆包时。4.5 验证最终一致性报警、归档一个都不能少同步完成后在两台机器上分别打开报警消息窗口和趋势窗口对比故障期间的记录。趋势窗口特别值得放大看故障时间段的曲线在从站上恢复后应该是连续的没有空洞。另外用 PowerShell 查看两台机器当前时间Get-Date Get-Date -ComputerName WINCC1这两行分别取本机WINCC2时间和主服务器时间。如果误差超过你配置的时间同步周期说明时间同步没生效归档时间戳会对不齐需要重新检查 Time Synchronization 设置以及 Windows 时间服务的启动类型。5. 冗余同步的边界与调优从实验环境到生产现场的改动5.1 串口电缆不是生产环境的长久之计实验里用一根串口电缆连接两台机器速度和稳定性都有限。生产环境一般把冗余独立成一个以太网网段两台服务器各加一张网卡用网线直连或通过交换机互连分配一个独立地址段。例如实验网段 192.168.0.x冗余网段设置为 10.10.10.1 和 10.10.10.2覆盖完控制网再覆盖冗余网。这样办公网瘫痪时冗余同步数据也能走独立通道反过来大数据量的归档同步也不会干扰过程控制网上的实时通讯。5.2 缩短同步时间比想象中更需要做归档规划同步时间长多半不是网络慢而是归档文件又大又碎。如果项目里变量数量多同步时间可能从 15 分钟拉到 1 小时以上。常见做法是把高频快速归档和低频过程归档分开建不要所有变量挤在一个归档里同时把趋势窗口加载的归档范围缩小避免启动时一次性读入整段历史数据。还有一点容易被忽略WinCC 服务器本身的内存和页面文件大小。同步过程对磁盘 IO 压力很大磁盘读写慢比网络带宽更容易成为瓶颈条件允许时给两台服务器都配上 SSD。5.3 用脚本监控冗余状态把验证变成习惯与其每次故障都去翻 WinCC 系统消息不如让日志主动记录网络的连通性。下面脚本可以在 WINCC2 上定时检测主服务器访问状态并把结果写入日志文件# 检查主服务器 WINCC1 是否可访问结果追加到日志 $result Test-Connection -ComputerName WINCC1 -Count 1 -Quiet {0} - Ping {1} : {2} -f (Get-Date), WINCC1, ($(if ($result) { OK } else { FAIL })) | Out-File C:\Logs\redundancy_check.log -AppendTest-Connection是 PowerShell 的 ping 封装-Count 1只发一个回显请求-Quiet返回布尔值。脚本放到 Windows 计划任务里每分钟跑一次故障发生的时间点就能和 WinCC 系统消息互相对照。如果你还想连从服务器服务状态一起看可以在脚本里追加Get-Service过滤 WinCC 相关服务名再把服务名和 Status 一起写入日志。这样即使 WinCC 画面上没有人在盯日志也能长期记录冗余健康状态故障切换实验才有可追溯的验证依据。本文还有配套的精品资源点击获取