企业官网建设流程全解析

简介：这是一份围绕WinCC冗余服务器搭建的实验文档，面向需要配置西门子WinCC冗余系统的自动化技术人员和组态软件学习者。内容先给出实验设备清单及两台计算机的软件选件、计算机名、IP地址、登录用户名和密码等基础条件，然后以Server Master为主线，依次说明多用户项目新建、Alarm Logging内部变量与模拟量上限报警组态、Tag Logging归档设置、画面中I/O域和趋势窗口的创建、冗余激活与伙伴服务器指定、时钟同步，以及通过项目复制器将项目从主服务器复制到从服务器的详细过程；文档还记录了主从服务器激活、断开网络模拟故障、故障期间报警与归档数据保留，以及恢复后约10至15分钟同步完成的实验结果。资源包共1个doc文件，约687KB，步骤紧凑而完整。已有388人学习下载，既可作为WinCC冗余项目实施的参考，也能用于实验教学和自学排错。

1. WinCC 冗余服务器是什么：一套双机热备实验，解决停机丢数据问题

WinCC 冗余服务器是西门子 SCADA 体系里最常被问到的组态之一。说直白点，就是用两台装了 WinCC Server 的电脑一主一备，主站宕机时备站能顶上，报警和归档不丢。这个实验文档我拆过好几遍，它把完整的组态步骤、项目复制、断网切换验证都串起来了，适合正在做化工、水处理、产线监控的现场工程师——尤其是那种上位机停机会被生产点名批评的场景。先说结论：冗余不是两台机器同时干活，而是主备关系；切换也不是瞬间完成，断网后恢复需要 10 到 15 分钟做归档和报警同步。搞清楚这个时间窗口，你才不会被现场误判为「冗余失效」。

2. 冗余实验的软硬件准备：两台 WinCC 的选件、IP 与串口对拷

2.1 实验要准备什么：两台电脑、串口电缆、授权

这个实验的硬件门槛很低：两台 PC，加上一根串口电缆。但软件选件不能省，少了哪一个冗余选项都不会出现在菜单里。两台电脑都要装 WinCC RC（也就是 Runtime Client）、WinCC Server，以及 Options 下面的 Server、Redundancy、Basic Process Control 三个选件。注意，是两台都要装，不是只装主站。

我一般会先检查授权管理器里的状态。常见翻车点是：装了 Redundancy 选件但没激活授权，结果 WinCC Explorer 里根本看不到冗余相关的菜单。另一个坑是操作系统和 WinCC 版本不一致，比如一台 Windows Server 2016 一台 Windows 10，虽然能跑，但项目复制后从服务器的系统消息总报异常。最稳的做法是两台机器系统镜像一样、WinCC 补丁一致。

串口电缆用来做冗余通讯的串行链路。在某些网络故障场景里，TCP/IP 断了，冗余对还能靠串口维持心跳。实验里要确认串口能被 WinCC 识别——不必先配置，安装 Redundancy 选件后系统会自动带出串口参数。

2.2 实验条件表：把每台机器的身份定死

这个实验最关键的一步是先把两台计算机的身份固定下来。文档里给了一张条件表，我直接按表操作，避免后面项目复制时源和目标搞混。表里每项都得对上，尤其是计算机名不能带下划线、不能超过 15 个字符，Windows 默认的长主机名经常导致 WinCC 连接失败。

用户名和密码是文档实验环境里给的，实际生产项目千万别用这种弱口令。我当时用的是域账号加复杂密码，但在做项目复制时发现：从服务器打开复制过来的项目时，WinCC 会用你登录的 Windows 用户去连接项目数据库。如果两台机器的 Windows 账号不一致，复制完打开项目就会报「无法打开项目」——所以要么统一账号密码，要么在复制前把两边的本地用户都建好。

2.3 网络与串口的实际接线

接线看起来简单，但坑不少。文档只写了「一根串口电缆」——实际必须是交叉线（null modem），不是直连串口线。做实验时我吃过亏，拿了一根普通串口线，结果主备心跳一直建立不起来。确认方式很简单：打开串口调试工具互相发数据，通了再接 WinCC。

IP 地址建议把网段固定，不要走 DHCP。冗余切换时如果备站 IP 变了，主站根本找不到伙伴。我一般会把两台机器的防火墙先关掉调试，等冗余跑通了再逐条放行端口。WinCC 冗余需要 TCP 端口 135、445 以及动态 RPC 端口，防火墙策略写不好就会玄学断连。

3. Server Master 组态：从多用户项目到 Runtime 激活

3.1 新建多用户项目与内部变量 t1

在 wincc1 上打开 SIMATIC WinCC Explorer，选择「新建多用户项目」，项目类型选「多用户项目」而不是单用户。这个区别决定了能否启用 Server 功能。项目名称我习惯不带空格和中文，避免后续项目复制器路径歧义。

项目建好后，先把内部变量建出来。在「变量管理」里右键「内部变量」->「新建变量」，名字叫 t1，数据类型选浮点数（Float）。这个 t1 会贯穿整个实验：报警用、归档用、画面 I/O 域用、趋势窗口也用。用一个变量把整套冗余链路打通，是熟悉 WinCC 最有效率的方式。

-- 这里不是 SQL，只是用注释方式来展示变量思路 -- 变量名: t1 -- 数据类型: 浮点数 (Float) -- 初始值: 0.0 -- 作用: 触发模拟量报警、存储归档、画面显示

逻辑说明：这个变量纯粹是内部变量，不需要连 PLC，所以调试时不依赖现场信号，只要手动改值就能验证报警和归档。参数上注意数据类型选 Float，如果选了 Integer，模拟量上限报警的上下限设定会受整数限制，后面测边界值时不方便。

3.2 组态 Alarm Logging：模拟量上限报警与系统消息

报警记录是冗余的重点验证对象。打开 Alarm Logging，菜单栏 Tools -> Add Ins，这里要添加模拟量报警组件。常见做法是右键左侧结构树中的「Analog Alarm」-> New，新建一个模拟量报警对象，然后再右键变量 t1 -> New，把 t1 关联到报警上。

这个环节容易翻车的地方是：模拟量报警模板和变量没绑定。新建 Analog Alarm 后，要在报警属性的「Limit」页签里设置上限值，比如 100.0，并把变量选成 t1。如果只建模板没选变量，运行时永远不会触发报警。

生成系统消息那一步很多人会跳过，结果就是主备切换时看不到任何冗余状态消息。正确操作是 Tools -> WinCC-System Messages -> Create，这样会在报警记录里自动生成一套冗余专属消息，包括「Synchronization launched」「Synchronization finished」。后面验证同步全靠这些消息。

3.3 组态 Tag Logging：归档向导的用法

变量归档的组态用向导最稳。打开 Tag Logging，右键「Archives」->「Archives Wizard」，归档名称填 a1，然后把 t1 选进归档。归档周期我用的是默认值，采集周期 1 秒，存储周期 1 分钟。周期太密会导致归档文件暴涨，太疏则趋势曲线看不出变化。

归档名字不要乱填。a1 这个名字后面在趋势窗口里要直接引用，如果归档名和变量名不一致，趋势窗口选择数据源时会绕很多弯。我建议归档名和变量名保持同一个命名规律，比如变量 t1，归档 a1，一眼就能对上。

3.4 组态画面和激活 Runtime

画面组态就三步：I/O 域连 t1，报警消息窗口连 Alarm Logging，趋势窗口连变量 t1 和归档 a1。I/O 域只要把「对象属性 -> 连接 -> 变量」选成 t1，显示格式用小数。报警消息窗口用标准的 WinCC Alarm Control 控件，数据源选报警记录。趋势窗口用 WinCC Online Trend Control，右键属性把变量 t1 和归档 a1 都加进去。

做完画面别忘了在计算机属性里激活 Runtime。右键项目树里的「计算机」-> 属性，找到「Runtime」页签，把 Alarm Logging Runtime 和 Tag Logging Runtime 都勾上。这一步漏掉的典型症状是：运行时画面能开，但报警窗口空荡荡、趋势窗口不刷新，因为对应的服务根本没启动。

这里有个实操技巧：先在本机激活一次单机运行，确认 t1 手动改值后报警、归档、画面都正常，再做冗余。如果单机都跑不通，后面加冗余只会多一层干扰项。

4. 冗余激活与项目复制：冗余选项、时钟同步、Server Data

4.1 激活冗余：Redundancy 选项与 Partner Server

在 wincc1 上打开 WinCC Explorer，左侧结构树找到「冗余」节点。必须能看到这个节点，说明 Redundancy 选件装好了。右键激活冗余，然后在「Partner Server」里填 WINCC2。注意这里填的是计算机名，不是 IP。虽然文档里 IP 是 192.168.0.2，但 WinCC 冗余的伙伴识别靠 NetBIOS 名，填错名字会一直提示找不到伙伴。

激活冗余后，WinCC 会自动建立一对通讯连接。我通常会先停 30 秒再继续，让冗余服务真正把主备关系写入配置。此时打开系统消息，能看到主站进入「Master」状态，备站是「Standby」。如果看到的是「Unknown」或「Not synchronized」，多半是防火墙或串口线问题。

4.2 时钟同步：以主站为参考，每分钟校准一次

时钟同步是冗余实验里最容易被忽略、但影响极大的步骤。文档里要求启用 Time Synchronization，以 wincc1 的时钟为参考，每一分钟发送一次时钟。这个设置的作用是确保两台机器的系统时间偏差不超过一个很小的窗口，否则归档的时间戳会错乱。

配置路径在冗余节点的「Time Synchronization」页签。勾选启用，同步源选「Server」或「Master」，周期填 60 秒。我一般会把周期再缩短到 30 秒，特别是在做断网恢复实验前，保证重新同步后时间戳能准确对齐。注意同步的是系统时间，不是 WinCC 内部时钟，所以 Windows 时间服务最好也一起关掉，避免两个时钟源互相打架。

4.3 项目复制：项目复制器 Duplicate 的源与目标

项目组态完成后，要把主服务器上的整个项目复制到从服务器。操作路径是 WinCC -> Tools -> 项目复制器（Project Duplicator）。复制器里选择源——也就是 wincc1 上刚建好的多用户项目；目标——wincc2 的本地路径，可以是共享文件夹，也可以直接在 wincc2 上执行复制器再填写源路径。

点击 Duplicate 后，复制器会做几件事：复制项目文件、重建数据库、生成从服务器的运行库。这个过程可能持续几分钟，进度条走完提示「复制完成」才算结束。注意在复制过程中不要动两台机器的网络，我可以分享一个血泪经验：复制过程中 wincc2 的防火墙弹窗，我点了「阻止」，然后目标项目就缺了数据库文件，从服务器死活打不开。

复制完成后，去 wincc2 上用 WinCC Explorer 打开这个复制过来的项目。右键「冗余」，会看到 Server 变成了 WINCC2，伙伴服务器变成了 WINCC1。这相当于复制器自动识别了机器名并翻转了主备角色。到这里，冗余组态才算真正完成。

5. 冗余服务器常见问题与避坑：这 5 个坑我踩过

5.1 坑一：从服务器项目打开报「无法建立数据库连接」

现象：在 wincc2 上双击复制过来的项目，弹出数据库连接失败，项目加载到一半退出。

原因：项目复制器生成的数据库实例名关联了 wincc1 的机器名，复制到 wincc2 后数据库服务没绑定到新机器名；也可能是 SQL Server 的登录账号不匹配。

解决：在 wincc2 上打开 SQL Server Management Studio，确认 WinCC 项目数据库的登录账号包含 WINCC2\Siemens 这个用户（或你实际用的 Windows 账号）。如果没有，手动添加并赋予 db_owner 权限。还有一种非常离谱的情况：wincc2 上 SQL Server 服务没启动，直接改服务为自动并启动，项目就能开了。

5.2 坑二：模拟量报警上限设了 100，t1 到 120 还不报警

现象：运行时把 t1 改到 120，报警消息窗口毫无反应，但变量值显示正常。

原因：Analog Alarm 的变量绑定没做。很多人新建了 Analog Alarm 并设了 Limit 值，但忘了在报警配置里关联变量 t1；或者关联到了别的模板上，导致报警一直用默认变量，不监控 t1。

解决：回到 Alarm Logging，右键模拟量报警节点，确认每条报警的「Variable」是 t1。更稳的验证方式是：别用运行时改值，先停掉项目，直接在报警记录编辑器里把模拟量报警的触发值临时改成 1.0，然后激活项目把 t1 改成 2.0，报警必响。响了之后再把触发值改回 100，顺便验证了报警配置是活的。

5.3 坑三：断网恢复后归档时间戳差了几分钟

现象：主站和备站恢复同步后，趋势窗口里的曲线对不上，同一时刻的数据点时间差了两三分钟。

原因：时钟同步没配好。备站系统时间在断网期间走了自己的时钟，而 WinCC 归档用的是本地系统时间。如果同步周期太长，重新同步前的时间里已经写了一批错时间戳的归档。

解决：把 Time Synchronization 周期从一分钟改成 30 秒，并且同步源强制指定为主站。同时在断网实验前，手动把两台电脑系统时间校准到秒级。恢复网络后先等一次时钟同步消息出现，再观察曲线。从那以后，我每次做断网验证前都会用w32tm /stripchart /computer:wincc1看一下时间偏差。

5.4 坑四：项目复制完成后从服务器冗余节点是空的

现象：复制器提示完成，但在 wincc2 上打开项目，「冗余」节点下没有任何配置，没有 Partner Server。

原因：复制器复制的是项目文件，但冗余配置可能保存在主站注册表或专门的配置文件中，没有被 Duplicate 完整迁移。最常见的是复制前主站的冗余没有彻底激活，或者激活后没有等配置写入就立刻复制。

解决：在 wincc1 上先激活冗余，关闭 WinCC Explorer（确保配置落盘），再打开项目复制器做 Duplicate。复制完成后不要急于打开，去 wincc2 的项目目录下检查有没有Redundancy相关配置文件。如果确认缺失，我的习惯是重新复制一次，或者复制后在从服务器手动重新激活冗余——反正组态不重，缺什么补什么，不要硬查。

5.5 坑五：同步消息一直不结束，或者反复出现「Synchronization launched」

现象：恢复网络后，系统消息里同步启动、同步结束反复循环，归档和报警一直处于不一致状态。

原因：两台机器之间有持续的写入活动，比如趋势窗口强制刷新、外部程序周期写变量、或者归档记录还在不断生成新数据；另一种可能是两台机器的时间戳互相冲突，导致数据条目的排序错乱，WinCC 陷入同步—冲突—再同步的死循环。

解决：先暂停从服务器上的运行画面和趋势窗口访问，让两台机器处于「空闲」状态再做同步。如果是生产环境没法停，那就把同步窗口安排在工艺稳定时段。更底层的原因可能是项目里的归档段设置太碎，导致同步时要合并大量小文件。把归档段时长调整到 8 小时或 1 天，同步会顺很多。

6. 故障切换验证与同步技巧：断开网线 10 分钟，用归档曲线对账

6.1 激活顺序与系统消息解读

冗余组态完成的验收，从激活顺序开始讲。先激活主服务器 wincc1，等它运行到 Master 状态；再激活从服务器 wincc2。激活的瞬间，从服务器会去找主服务器建立伙伴关系，系统消息里会出现冗余连接建立、伙伴识别等条目。如果先激活从服务器再激活主服务器，虽然多数情况下也能建立冗余，但状态切换的日志会乱，不利于排查。

激活完两台机器后，等系统消息出现「Synchronization launched」和「Synchronization finished」，说明两台机器的数据和配置已经对齐。这里的同步是初始同步，时间取决于项目里归档和报警的数据量，我做过的最快几分钟，最慢半小时。不要看到同步没结束就以为配置错了，先等一轮完整的同步周期。

6.2 验证同步的两种方法：断网模拟与归档曲线对账

验证冗余是否真的有效，最直接的方法是断网。在主站运行时拔掉 wincc1 的网线或禁用网卡，模拟网络故障。此时 wincc2 会接管，变成 Master。在故障期间，手动把 t1 改成几个不同的值（比如 50、80、120），触发模拟量报警，并让趋势窗口记录下这些值的变化。再恢复网络，你会看到系统消息重新出现「Synchronization launched」，等待 10 到 15 分钟，同步完成会出现「Synchronization finished」。

同步结束后，对比两台机器的报警消息列表和归档曲线。我常用的法子是：在两台机器上打开同一个报警窗口，按时间排序对比条数；在趋势窗口里调出 a1 归档，看断网期间的曲线段是否完全重合。这里有个细节——趋势窗口默认只显示实时数据，要看历史归档，需要在趋势控件里把数据源切到归档段，否则你看到的只是当前内存数据。

我现在做这个实验时，一定会顺便写一个小脚本，自动把 t1 按 10 秒间隔在 0 到 150 之间循环赋值。这样即使我离开工位，归档里也会有连续的测试曲线。这个脚本用 WinCC 的全局脚本 C 语言就能写，不必依赖外部 PLC。从那以后，我每次做冗余验收都强制走一遍「断网—造数据—恢复—对账」的流程，把这个过程固化成自己的检查清单。同步完成后，别忘了把网线插回去再看一次趋势，这才是完整闭环。希望帮到你。

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