企业官网建设流程全解析

简介：这份文档面向工业自动化工程师、SCADA系统集成人员及过程控制相关专业学习者，系统讲解具备Web功能的第四代SCADA系统。内容围绕WEBSCADA的技术内核展开，涵盖Internet技术、面向对象技术、DNA神经元技术的融合思路，并重点介绍美国爱克新仪器公司Action Web SCADA系统的整体架构，包括WebViewI/O信号转换器、WVC16接口控制模块等硬件产品，以及OPC与WebOPC软件基础、脚本语言扩展、仪表虚拟化等关键知识点。文档还梳理了远程访问、多途径报警、多用户协同监控、用户参与设计、与PLC/DCS无缝对接等八项优势，并给出WebViewI/O高精度输入输出、智能电源、WVC16内置Web服务器与Email报警等硬件特性说明。资源包共1个doc文件，约4.54MB，结构完整、图文并茂，适合作为选型参考或技术入门读物。目前已有309人学习，可帮助读者快速建立对Web SCADA体系结构、通信机制与部署方式的整体认知。

1. 从一份老文档说起：WEBscada系统到底解决了什么现场问题

如果你在工业自动化现场待过，大概率遇到过这种场景：一台关键设备报警了，值班人员不在中控室，等发现的时候已经停机半小时。传统 SCADA 的痛点就在这——数据被锁在专用网络和专用客户端里，人必须坐在那台机器前面才能看到。WEBscada 系统要解决的核心问题，就是把 SCADA 从"专用客户端"里解放出来，让数据通过标准 Web 浏览器就能访问。

这份《WEBscada系统.doc》文档覆盖了两条技术路线：一条是美国 Action Instruments 公司的 Action Web SCADA 产品体系，走的是 WebView I/O 信号转换器加 WVC16 通信控制器的硬件路线；另一条是华工电气 HG 2002 系统，走的是 COM 组件加 XML Web Services 的软件路线。两条路线解决的是同一个问题——让采集和监控的数据开放出来，被更多管理系统、控制系统和使用者访问。适合正在做 SCADA 改造、需要把实时数据接入上层管理平台的工程师，也适合想理解 Web 技术与工业控制如何结合的从业者。

2. WebOPC 与 XML Web 服务：两条技术路线的选型逻辑

2.1 OPC 到 WebOPC 的演进路径

文档里反复提到一个关键概念：OPC。这是 Microsoft、Intellution、Fisher-Rosemount 等五家自动化软件厂商联合制定的标准，基于 OLE 技术，专门为过程控制设计。它的核心价值在于提供了一种标准途径，从数据源（服务器）提取数据并传输到应用程序（客户端）。OPC 规范定义了一个工业标准接口，使得 COM 技术适用于过程控制和制造自动化领域，具有语言无关性、代码重用性、易于集成性等优点。

但传统 OPC 有个硬伤：它依赖 COM/DCOM 对象模型，客户端必须安装过程软件或其他客户端软件。这在局域网内没问题，一旦要跨网络、跨平台访问就非常麻烦。DCOM 在处理异构平台之间的互操作性上遇到了很大困难，配置复杂、端口管理麻烦，现场调试经常翻车。

WebOPC 是 OPC 技术的最新发展方向。它为用户提供了更廉价和方便访问过程数据的方式——真正的瘦客户端解决方案，可以直接通过普通 Web 浏览器访问数据，不需要安装过程软件或其他客户端软件。有了 WebOPC，过程数据可以存储在全企业通用数据库中，被有权限的用户和程序访问；可以用 HTML 页面制作工具来制作监控画面，JAVA 动态效果可以对过程进行仿真模拟。

与传统 HMI/组态软件不同的是，WebOPC 提供了真正透明的 I/O 层，可以被包括远程在内的普通浏览器所访问，从而提供了远程组态、远程监控、远程维护的功能。常见做法是：在原有 OPC Server 基础上加一层 Web 服务封装，把 OPC 数据项映射为 HTTP 可访问的资源。

2.2 XML Web Services 在 SCADA 中的实现方式

文档中另一条路线是华工电气 HG 2002 系统采用的 XML Web Services 方案。这套方案的核心思路是：用 COM 技术进行系统构建，三层客户/服务逻辑结构分为客户层、服务层（商业逻辑）和数据源，实现 Internet 服务功能，处理即时信息查询和实时控制。

为什么选 XML Web Services 而不是普通 Web 服务？文档给出了明确理由：普通的 Web 服务在客户提交请求后，服务器返回包含处理结果及相关额外内容的完整页面，需要整个页面刷新，使得实时信息更新难以实现。常用解决办法是开发 ActiveX 控件处理内容更新，但缺点是需要在客户端下载控件后才能实现服务功能，不满足"瘦"客户的要求。

XML Web Services 的基本结构包括三个主要部分：消息交换、Web 服务描述和服务描述的发布与发现。服务建立在一个消息传递机制基础之上，通常采用 SOAP 协议。SOAP 建立于现有 Internet 基础之上，采用 HTTP 协议发送 XML 格式的消息，包括三个部分：封套（envelope）定义消息内容和处理的框架；一套编码规则用来表达定义数据类型的实例以及表达远程过程调用和响应的协定。

Web 服务使用 WSDL 作为底层的服务描述。WSDL 是一种 XML 文档格式，将 Web 服务作为一系列基于消息的终端操作进行描述，这些消息包含面向文档或者面向过程调用的消息。通常包括服务接口定义和服务实现定义。服务接口定义是一种抽象的可复用的服务定义，可以被不同的服务实现定义所实例化和引用。服务实现定义描述了特定的服务接口如何被给定的服务提供商所实现，同时提供服务定位，使得请求对象可以发现服务。

发布服务描述有两种方式：直接发布和通过 UDDI 注册。直接发布是指服务提供商直接将服务描述发送到请求对象，可以通过 Email、FTP 或者光盘发布。UDDI 计划为描述服务、发现商业实体和集成商业服务创建了一个平台独立的开放式架构，同时又是当前可操作的注册中心。

2.3 实时刷新的实现：定时器加 XML 解析

Web 服务是一个无连接的网络服务。为了实现实时数据的刷新，客户端设置定时器，不断发出请求。服务器响应后返回 XML 结果，有效数据包含在 SOAP 的 Envelope 正文部分，客户端分析 XML 文档，根据内容对具体的控件进行刷新，避免了整个页面的刷新。

这个机制听起来简单，但实际配置时有几个关键参数需要关注。定时器间隔决定了数据刷新频率，太短会增加服务器负担，太长则实时性不够。常见做法是根据被监控量的变化速率来定：温度、压力这类慢变量 5 到 10 秒一次足够；电量、脉冲量这类快变量可能需要 1 到 2 秒。XML 解析部分要注意命名空间的处理，不同厂商的 SOAP 实现可能在命名空间前缀上有差异，解析代码要能兼容。

系统 Web 服务还提供实时图形的绘制功能。基于 VML 协议，可以利用 XML 格式数据绘制图形。当前系统可以动态显示电量、模拟量、脉冲量等的实时曲线图形。设备状态也可以通过 ActiveX 控件或者网页图形进行动画显示。在通过 Internet 进行实时控制时，需要对命令进行身份识别，验证信息包含在包的 header 部分。服务器通过解析登录信息对授权部分提供服务，使用数字签名可以保证服务安全性。

3. Action Web SCADA 硬件层拆解：WebView I/O 与 WVC16 怎么配

3.1 WebView I/O 信号转换器的关键参数

Action Web SCADA 的硬件基础是 WebView I/O 系列信号转换器。文档给出的核心参数值得仔细看：输入和输出精度 0.015%，高稳定性满量程的 100ppm。这两个数字在工业信号转换器里属于什么水平？普通信号隔离器的精度通常在 0.1% 左右，0.015% 意味着精度提升了一个数量级。100ppm 的稳定性意味着在满量程范围内，温度漂移和长期漂移控制在百万分之一百以内。

WV 系列支持多种信号输入：交流、直流的电压/电流、热电偶、热电阻、频率、桥路、可变电阻，并且在输入、输出、电源间互相隔离。这个隔离特性在现场非常关键——工业现场地电位差、电磁干扰是常态，没有隔离的信号转换器轻则数据跳动，重则烧毁通道。

"智能电源"功能是另一个亮点：在轻负载时能降低输入电源的供给。对于大量使用变送器的现场，这个功能可以显著降低整体功耗和发热。WV 系列产品可以通过标准的浏览器在企业内部互联网上直接访问传感器数据，用户也可以在异地通过远程浏览器进行组态、维护和查看过程信号。更进一步的是，当错误发生或超过上下限时，这些模块能发出 Email 电子邮件进行通知。

WebView I/O 系列最重要的一个优点是：它同时也是独立的信号转换器，不必通过以太网联接也能进行组态和维护。它可以通过 DIP 开关和按钮进行标定。当用户需要升级到企业控制互联网时，仅需在旁边简单地安装 WebView 的通讯接口 WVC16，然后把它连接到以太网，就完成升级可以运行了。这个设计思路很务实——先解决信号转换的基本需求，Web 功能作为可选的升级路径。

3.2 WVC16 通信控制器的组网配置

WVC16 是 I/O 服务器接口控制模块，每个控制模块可以支持 32 个 I/O 模块。控制器包括 WEB 页服务器和 Email 服务器，同时也是以太网的接口。WVC16 内设有存储器，可以存储信号转换器的历史数据、Web 页面和所有 Email 信息。

组网配置的关键步骤：

第一步：物理连接。WVC16 通过一个标准的 RJ45 接口与 10BaseT 网络连接。WV 系列信号转换器内置红外通讯联接器，通过壳体旁边的小孔与接口控制模块进行通讯，不需要运行任何程序，WVC16 模块会完成所有的连接工作。这个红外通讯的设计避免了复杂的接线，现场安装时只需要把 WV 模块卡在 DIN 导轨上，WVC16 靠近即可建立通讯。

第二步：IP 地址分配。可以通过附带的软件通过 RS232 口对 WVC16 分配 IP 地址。这一步是很多现场调试容易卡住的地方——RS232 线序要对，串口参数要匹配。常见配置是 9600 波特率、8 数据位、1 停止位、无校验。分配完 IP 后，建议先用 ping 测试网络连通性，再打开浏览器访问 WVC16 的内置 Web 页面。

第三步：浏览器访问与组态。WVC16 实际上会把一个 JAVA 小程序下载到客户机上。这个小程序提供了访问信号转换器的数据，包含以下信息：模块简要组态信息、模块组态编辑器、诊断/警告状态、报警设定和状态、建立和编辑 Email 和地址簿、过程变化查看。注意 JAVA 小程序需要客户端安装 JRE 运行环境，这是早期 Web SCADA 方案的一个依赖，现在看可能有些过时，但在当时是标准做法。

第四步：报警与 Email 配置。WVC16 内置 Email 服务器，可以配置报警触发条件。当信号超过设定的上下限时，模块自动发送 Email 通知。配置时需要填写 SMTP 服务器地址、发件人地址、收件人地址列表。文档提到 WVC16 内置 AM-186 微处理器，当断电时数据也会被保存，这个特性保证了报警配置和历史数据不会因为临时断电而丢失。

3.3 网络架构：以太网替代现场总线的理由

文档对网络架构的论述值得单独拎出来。Action Web SCADA 系统网络的特点就是可与通用的以太网络产品集成，组网容易，维护成本低。用以太网取代现场总线是实现管控一体化网络的必经之路。

传统 PLC/DCS、现场总线等控制方式存在几个问题：传感器数据经由各自的 CPU 和驱动程序，传输速率低，开发和维护都相当困难；控制器与控制器不能自主通讯；所有控制器独立地运行，实现数据交换需要高成本的专用硬件和软件支持；不同的控制系统很难实现数据的共用，更无法实现系统的联动；专用的现场总线设备昂贵，并且利用率低。

而以太网产品经多年的发展，技术已相当成熟并且费用低廉。用以太网卡、路由器等产品来代替现场总线的通讯设备，不仅大大降低了组网设备的费用，同时也极大地降低了开发、维护和运行成本。管控一体化更使企业内众多不同控制网络连成一个整体，可以对企业网络设备有效地分布，并且共享带宽。

另一个特点是能够与无线以太网相结合。与兼容 TCP/IP 协议的无线以太网相连，可以使 Action Web SCADA 系统对多种过程的生产、分配能源等进行管理。无线通讯系统主要适用于点分散、距离较远、范围较大的城市集中供热、供气、供水及排水、供电，以及油气田、煤矿的开采、运输和分配；也同样适合于移动目标的数据采集，如焦化厂的推焦车、拦焦车和消火车，港口集装箱搬运机械等。与地理信息系统 GIS、全球定位系统 GPS 相连，更可以使 Web SCADA 系统得到更广泛的应用。

4. 避坑与排查：WEBscada 落地时最容易翻车的五个地方

4.1 浏览器访问 WVC16 页面空白或 JAVA 小程序不加载

现象：用浏览器打开 WVC16 的 IP 地址，页面能显示框架但数据区域空白，或者提示 JAVA 小程序加载失败。

原因：客户端没有安装 JRE，或者 JRE 版本与 WVC16 内置的 JAVA 小程序不兼容。早期方案通常依赖特定版本的 JRE，新版本可能移除了某些 API。

解决：确认客户端安装了文档要求的 JRE 版本。如果找不到对应版本，可以尝试在浏览器安全设置中降低 JAVA 权限要求。长期方案是考虑用现代 Web 技术重写前端，把 JAVA 小程序替换为 HTML5 页面加 WebSocket 或轮询。

4.2 OPC 客户端连接 DCOM 配置失败

现象：OPC 客户端连接远程 OPC Server 时提示"拒绝访问"或"接口未知"。

原因：DCOM 配置不正确。Windows 防火墙阻止了 DCOM 通信，或者 DCOM 身份验证级别、启动权限没有正确设置。

解决：在 OPC Server 所在机器上运行 dcomcnfg，找到 OPC 相关的 COM 组件，设置身份验证级别为"无"或"连接"，配置启动和访问权限允许远程用户。防火墙需要开放 DCOM 使用的动态端口范围，或者配置固定端口。这个配置过程在不同 Windows 版本上差异很大，是现场调试最常见的翻车点。

4.3 XML Web 服务返回数据但客户端解析失败

现象：服务端日志显示请求已处理并返回了 XML，但客户端解析时报错或数据为空。

原因：命名空间不匹配。不同厂商的 SOAP 实现可能在命名空间前缀、编码方式上有差异。另外，XML 中的特殊字符（如 &、<、>）如果没有正确转义，也会导致解析失败。

解决：先用 SOAP UI 或 Postman 直接调用服务，查看原始返回内容。确认命名空间 URI 与 WSDL 中定义的一致。解析代码中使用标准的 XML 解析库，不要用字符串截取的方式提取数据。对于特殊字符，确保服务端在生成 XML 时进行了正确的实体转义。

4.4 实时数据刷新延迟大或页面卡顿

现象：监控页面数据更新明显滞后，或者浏览器占用 CPU 很高。

原因：定时器间隔设置过短，导致请求堆积；或者每次刷新都重新请求整个页面而不是只更新数据部分。

解决：根据被监控量的实际变化速率调整定时器间隔。慢变量 5 到 10 秒，快变量 1 到 2 秒。确保客户端只解析 XML 中的有效数据部分并更新对应控件，避免整页刷新。如果数据点很多，考虑分批请求或使用增量更新机制。

4.5 WVC16 与 WV 模块红外通讯不稳定

现象：WVC16 偶尔丢失某个 WV 模块的数据，重新插拔后恢复。

原因：红外通讯对安装位置敏感。WV 模块与 WVC16 的距离、角度偏差都可能导致通讯中断。DIN 导轨上的模块排列过于密集时，红外窗口可能被遮挡。

解决：确保 WV 模块与 WVC16 之间的红外窗口对齐，距离在有效范围内。模块之间留出适当间隙。如果现场振动较大，考虑用导轨固定件加固。对于关键测点，可以在组态中设置通讯超时报警，及时发现中断。

5. 从 HG 2002 看 SCADA 与 MIS 的数据级集成技巧

5.1 三层架构的数据流设计

HG 2002 系统的架构值得细看。系统基于组件构造，分为五个子系统：数据库系统用于保存参数设置和历史数据；图元系统绘制和创建图库和 ActiveX 控件；图形系统形成在线的一次接线分层机理，跟踪系统的参数变化和动作行为；报表系统用于处理历史数据和参数数据，包括查询、显示、打印、数据转储、删除和恢复等功能；主应用系统包括数据采集模块、显示模块、数据库管理模块、报警模块和实时控制模块等；设备驱动系统负责 OPC 服务器对设备进行数据采集和控制；网络服务模块包括局域网通信系统和 Web 服务系统。

系统采用标准的数据交换模型，基于 XML 的 CIM 可以实现异构系统的互操作性。这个设计思路在长输管道网络控制系统中也有体现：整体解决方案分为三层，最上层为管理信息系统平台，中间层是组态软件和仿真、检测软件，最底层为控制终端。MIS 系统、SCADA 系统、仿真系统相结合，成为集自动化控制、仿真模拟及信息管理于一体的统一平台。

MIS 系统可以根据业务需要调用仿真系统进行运算后的仿真结果，MIS 系统接收并保存从在线仿真系统中提取的实时数据进行统计和分析，MIS 系统提取并保存 SCADA 系统中的生产实时数据进行统计和分析，为管理信息系统提供数据基础、业务管理需要和决策支持；仿真系统提取 SCADA 系统生产实时数据作为仿真、预测、检测等仿真操作的数据基础。

5.2 组态软件的核心功能模块拆解

文档对组态软件的功能模块做了清晰拆解，基本功能模块包括：应用程序管理器实现应用程序的建立、管理、存档等工作；图形界面开发程序实现应用程序图形界面的编辑、变量管理、动画连接的控制；图形界面运行程序是工程执行的用户主界面，是监控工作人机交互的用户接口；实时数据库系统组态和运行程序实现设备数据的输入输出、实时数据的存储、历史数据的维护；I/O 扫描及驱动程序实现控制终端与应用程序数据的交互；数据开放性接口主要实现应用程序的数据开放性，是第三方应用程序以标准的方式访问系统数据。

专用功能模块包括：长输管道站控模块用于长输管道站级控制系统的定制开发；长输管道中心控制模块用于长输管道控制中心级控制系统的定制开发；长输管道图库及开发工具针对长输管道工程控制设备的专用图库及工具；分布式体系模块实现了软件架构对 TCP/IP、串口网络的支持。

从这些模块可以看出，组态软件的核心价值在于"组态"二字——用配置代替编程。但配置的灵活性是有边界的。当现场需求超出组态软件预置的功能模块时，就需要通过脚本语言或第三方程序接口来扩展。文档提到 Web SCADA 系统通过脚本语言扩充功能，从而实现复杂的系统要求。脚本语言一开始是以特殊命令的形式出现的，各种软件通过其特有的命令语言实现附加功能。随着技术的发展和微软技术在工业界的推广，脚本语言不再只是一个软件概念，它可以集成到智能化仪表中，以实现特定的功能。在有些现场，智能化仪表可以不依赖 PC 而独立工作。

5.3 仿真系统与 SCADA 的数据联动

长输管道网络控制系统中，仿真软件与 SCADA 的联动是一个值得关注的实践。天然气管道仿真软件用天然气管道系统模型对真实或假想的管道系统进行模拟，并借助专家经验知识、统计数据等对模拟结果进行分析研究，为系统的设计和管理提供支持。系统具有如下功能：可以模拟管道和设备的运行操作；可以预测诸如爆管、设备故障或其他的事故时所采取的不同的控制策略。系统通过计算流体在管网中不同时间的压力、流量、密度、温度以及其他的参数变化规律来进行模拟仿真，通过打印报告和图表的方式输出结果。

管网结构的描述采用组态式管道建模技术。任意一个输气管网由节点和枝组成，节点代表管子或其他设备的连接处，枝则代表管网中的元件，元件是连接于节点之间的输气设备，它可以有管道、调节阀、压缩机、外部接口等多种形式。管网的相互连接关系可以用元件-节点关联矩阵来描述。这种组态式管道建模技术根据用户的输入能清晰地描述复杂的站内结构和完整地描述复杂的管网结构，为仿真软件的不断升级在管道模型方面奠定了基础。

动态仿真采用特征线模型。在含有惯性因子的等温特征线模型的基础上，将能量方程有机地加入到特征线模型中，实现了温度的动态模拟，考虑了温度与其它参数之间的相互影响。这个模型的选择是有讲究的——惯性因子引入改善了模拟时步的局限性，能量方程的加入使得温度动态模拟成为可能。对于长输管道这种大惯性系统，温度对流体特性的影响不可忽略，这个模型比单纯的等温模型更接近实际。

5.4 一个可复现的验证方法

如果你想验证一份 Web SCADA 方案是否真的能落地，我一般会走这个流程：

第一步：确认数据采集层。用 OPC 客户端工具连接 OPC Server，确认能读到实时数据。如果是 Modbus 设备，先用 Modbus Poll 确认寄存器映射正确。

第二步：验证 Web 服务接口。用 Postman 或 curl 调用 Web 服务，确认返回的 XML 结构符合 WSDL 定义。重点检查命名空间、数据类型、时间戳格式。

第三步：测试浏览器兼容性。用目标浏览器打开监控页面，检查 JAVA 小程序或 ActiveX 控件是否正常加载。如果依赖特定插件，确认插件版本和安装流程。

第四步：模拟报警场景。人为触发一个报警条件，确认 Email 通知能正常发出，报警记录能正确存储。

第五步：压力测试。用脚本模拟多个客户端同时请求，观察服务器响应时间和资源占用。如果响应时间明显上升，需要调整定时器间隔或增加服务器资源。

从那以后我每次接手 SCADA 改造项目，都强制走一遍这个验证流程，尤其是第二步和第四步——Web 服务接口和报警链路是最容易在演示时翻车的地方。希望帮到你。

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