1. AVEVA二次开发全景认知

AVEVA 工业软件体系并不是单一产品，而是一组围绕“现场数据采集—实时监控—信息建模—历史存储—分析优化”构建的产品家族。理解二次开发，第一步不是急着写脚本，而是先看清每个产品在系统中的位置、它对外暴露的扩展接口，以及哪些需求应该落在哪一层实现。选错扩展层，往往会导致后期维护困难、性能下降，甚至架构返工。

产品家族与扩展能力边界

从工程视角看，AVEVA 常用产品可以按职责划分为几个层次。InTouch 位于可视化与操作层，负责画面、报警、趋势和操作交互，其扩展能力主要体现在 QuickScript（应用脚本、窗口脚本、条件脚本）、ActiveX/.NET 控件嵌入、以及通过 OPC/DA、SuiteLink 与外部程序交换数据。System Platform（含 Application Server 与 InTouch OMI）位于信息建模与集成层，核心是对象模板、实例化模型和 Galaxy 数据库，扩展手段包括 Automation 脚本、.NET 脚本、对象模板自定义属性、以及通过 OPC UA/DA 与外部系统集成。Historian 位于历史数据层，负责高压缩比的过程数据存储与检索，扩展主要通过 AVEVA Historian Client、SQL 查询、存储过程以及 OLE DB/ODBC 接口实现。PI System（PI Data Archive、PI AF、PI Vision）则偏向企业级实时数据基础设施，扩展依赖 PI SDK、AF SDK、PI Web API 和 Asset Framework 建模。

需要特别强调的是“边界”二字。InTouch 脚本适合处理画面级逻辑和轻量数据转换，但不适合承担大规模计算或长期数据治理；System Platform 的 Automation 脚本适合对象级逻辑与模型联动，但不应把复杂业务算法全部塞进对象脚本；Historian 与 PI System 擅长存储和检索，不适合做实时控制逻辑。二次开发的第一原则是：把逻辑放在最合适、最靠近数据源或最靠近使用者的那一层。

典型二次开发场景

在实际工程中，二次开发需求通常集中在以下几类场景。第一类是画面与交互增强：例如在 InTouch 中嵌入自定义 .NET 控件，实现设备状态的三维展示或动态工艺流程图；或通过 QuickScript 调用外部 DLL，完成批次号自动生成与校验。第二类是数据集成与转换：例如把 System Platform 中的对象属性通过 OPC UA 发布给 MES，或把 Historian 中的历史数据按班次汇总后写入关系数据库。第三类是模型自动化：例如根据 Excel 设备清单批量创建 System Platform 对象实例，或通过 AF SDK 自动构建 PI AF 资产层级。第四类是报警与事件处理：例如在报警产生时自动发送邮件、写入工单系统，或根据报警等级触发不同的处置流程。第五类是报表与绩效分析：例如基于 Historian SQL 查询生成 OEE 报表，或通过 PI Web API 在 Web 端展示实时 KPI。

这些场景的共同点是：它们都不是产品自带功能的简单使用，而是需要把 AVEVA 产品作为“平台”，在其上编写代码、配置接口、定义数据模型，最终形成贴合企业实际业务流程的扩展能力。

工程价值与实施判断

二次开发的工程价值可以归纳为三点：连接——打通 AVEVA 产品与企业其他系统之间的数据孤岛；适配——让标准产品适配企业特有的工艺、组织和管理流程；提效——把重复性人工操作转化为自动化逻辑，降低操作员和工程师的日常负担。

但并非所有需求都值得二次开发。一个实用的判断方法是：先问“标准产品是否已经提供配置级能力”，再问“扩展逻辑是否稳定、长期需要”，最后问“维护成本是否可控”。如果只是临时性、一次性的数据导出，用 Historian Client 或 Excel 插件可能比写代码更合适；如果逻辑频繁变化且涉及多系统协同，则应考虑在 System Platform 或 PI AF 层建立可复用的模型与接口。

本章的核心结论是：AVEVA 二次开发的全景认知，本质上是“分层认知 + 边界判断 + 场景匹配”。只有先看清产品家族各自的能力边界，才能在具体项目中做出正确的扩展层选择，避免把逻辑放错位置而导致的架构问题。