3. AVEVA平台数据采集架构

AVEVA工业数据采集与可视化平台并不是一个“把PLC数据读上来再画个图”的单体软件，而是一条从现场设备到业务应用的分层数据链路。理解这条链路的关键，是把它拆成四个职责清晰的功能层：采集层、传输层、存储层、服务层。每一层解决一个特定问题，层与层之间通过明确定义的接口交接数据。分层的目的不是增加复杂度，而是让“设备接入”“网络传输”“数据持久化”“数据消费”这四类差异极大的问题各自独立演进——现场换了一台仪表，只需改采集层；历史库扩容，只需动存储层；上层要新增一个报表，只需在服务层加一个接口。

下面按数据自下而上的流动顺序，逐层说明各层“负责什么、不负责什么、关键对象是什么”。

采集层：把物理信号变成有语义的标签值

采集层直接面对现场设备，是整条链路的起点。它的核心任务不是“读一个数”，而是把设备的原始信号转换为带有工程语义的标签（Tag）值。所谓工程语义，至少包含四件事：标签名、工程单位、时间戳、数据质量码。一个只带数值、没有时间戳和质量码的采集结果，在后续环节几乎无法使用。

采集层要处理的对象类型差异很大：PLC（如西门子S7、罗克韦尔ControlLogix）通常通过以太网走OPC UA或原生驱动；DCS往往通过OPC DA/UA网关暴露数据；智能仪表可能走Modbus RTU/TCP；电力、水处理等场景还常见IEC 104、DL/T 645等规约。AVEVA的采集组件（如AVEVA Edge、AVEVA OASyS/Historian采集接口、OPC UA客户端）通常以“通道—设备—标签组”三级结构组织这些连接：一个通道对应一种协议和一条物理链路，通道下挂多个设备，设备下挂若干标签。

采集层还需要处理两个容易被忽视的问题。其一是扫描周期与死区：不是所有标签都需要100ms采集，温度这类缓变量可以设1s甚至更长周期，并设置死区（如变化超过0.5℃才上报），否则会产生大量无意义数据。其二是质量码：当通信中断或设备返回异常时，采集层必须把该标签标记为“坏质量”，而不是继续沿用旧值。下游看到坏质量码，才知道这段时间的数据不可信。

传输层：在采集与存储之间可靠搬运数据

传输层解决的是“采集到的数据如何可靠、有序地到达存储层”。它不改变数据语义，只负责搬运，但搬运方式直接决定了系统的实时性和可靠性。工业现场常见的传输方式有三类：

• OPC UA / OPC DA：适合采集层与上层在同一网络内、需要订阅式实时数据的场景，支持数据变化通知。
• 消息中间件（如MQTT、Kafka）：适合跨网段、跨厂区、需要削峰填谷的场景。采集端作为发布者，存储层作为订阅者，网络抖动时消息可缓存重发。
• 专有采集协议：部分AVEVA Historian采集接口使用自有传输协议，与Historian存储紧密耦合，部署简单但灵活性较低。

传输层的关键设计参数是批量大小与发送间隔。例如，若采集层每秒产生2000个标签变化，逐条发送会产生2000次网络往返；按500条一批、每200ms发送一次，则每秒只需10次传输，网络开销大幅下降，但会引入最多200ms的额外延迟。这个权衡需要根据业务对实时性的要求来确定：用于报警联锁的数据应走低延迟通道，用于趋势分析的数据可以接受批量延迟。

传输层还必须考虑断线续传。当网络中断时，采集端应把数据缓存在本地队列中，恢复后按时间顺序补发，避免历史数据出现空洞。这是工业数据采集与普通IT数据采集的重要区别。

存储层：让数据“存得下、查得快、留得住”

存储层是整条链路的数据归宿，通常由实时库和历史库两部分组成，二者职责不同。

实时库（内存库）保存每个标签的当前值、时间戳和质量码，供服务层快速读取。它的特点是容量小、访问快，通常只保留最新值，不承担历史查询。AVEVA平台中，实时值通常由采集服务或专门的实时数据服务维护。

历史库负责长期存储。工业历史数据有两个鲜明特点：写多读少（每秒写入大量标签值，查询相对较少）和按时间范围查询（几乎不按主键查单条）。因此历史库通常采用列式或时间序列存储结构，并配合旋转门压缩（Swinging Door）等有损压缩算法。例如，一个模拟量标签若每秒采集一次，一天产生86400个点；采用旋转门压缩后，若该标签变化平缓，可能只保留几百个点，而趋势曲线在视觉上几乎无差别。压缩精度由“偏差死区”参数控制，死区越大，压缩率越高，但细节丢失越多。

存储层还需要定义数据保留策略：原始高精度数据保留多久（如3个月），压缩后的历史数据保留多久（如3年），过期数据是删除还是归档。这些策略直接影响磁盘容量规划。

服务层：把数据变成可用的接口与视图

服务层是数据对外消费的出口，它不直接接触设备，也不直接管理存储文件，而是把存储层中的数据包装成上层应用可用的形式。服务层通常提供以下几类能力：

• 实时数据服务：按标签名读取当前值，支持批量读取和订阅推送。
• 历史数据服务：按标签名和时间范围查询历史值，支持原始值、插值、聚合（如每小时平均值、最大值）。
• 报警与事件服务：根据标签值和质量码判断报警条件，产生报警记录并推送给客户端。
• 元数据服务：提供标签的工程单位、描述、所属设备等信息，供可视化界面显示。

服务层的接口形式通常是REST API、OPC UA方法调用或专有SDK。以历史查询为例，一个典型请求需要指定：标签名列表、起始时间、结束时间、查询模式（原始/插值/聚合）、聚合周期。返回结果中每条记录都应包含时间戳、值和质量码，服务层不应丢弃质量码。

四层之间的边界与协作

把四层放在一起看，可以总结出几条清晰的边界规则。第一，采集层不存储：它只产生标签值，不负责历史保存，因此采集服务的重启不会导致历史数据丢失（前提是传输层有缓存）。第二，传输层不解释数据：它只搬运字节或消息，不关心标签的工程单位，因此传输层可以独立替换而不影响采集和存储。第三，存储层不对外提供业务接口：它只负责持久化和按时间范围检索，报警判断、单位换算等逻辑属于服务层。第四，服务层不直接访问设备：所有数据都来自存储层，这保证了上层应用的稳定性——设备短暂离线不会导致可视化界面报错，只会显示坏质量码。

在实际项目中，这四层可能部署在同一台服务器上（小型项目），也可能分布在现场采集机、厂级历史服务器、集团云平台等多个节点上。无论物理部署如何变化，功能划分保持不变。理解这一点，才能在面对“数据为什么没上来”“历史曲线为什么有断点”“报警为什么延迟”这类问题时，快速定位到应该检查哪一层。

最后需要强调，四层划分不是AVEVA平台独有的概念，而是工业数据采集系统的通用架构模式。AVEVA的价值在于把这四层做成了可配置、可组合的产品组件，让工程师不必从零实现每一层。但配置之前，必须先清楚每一层“应该做什么、不应该做什么”，否则很容易把采集服务当数据库用、把历史库当实时库用，最终导致系统在数据量增长后迅速劣化。