2. AVEVA PI System数据模型与接口基础
在动手设计任何一条接口之前，必须先弄清楚数据在PI System里“长什么样、放在哪里、怎么被引用”。PI System并不是一个单一数据库，而是一组协同工作的组件：PI Data Archive负责存储带时间戳的原始时序数据，PI Asset Framework（AF）负责把这些数据组织成有业务含义的资产模型，PI Interfaces与PI Connectors负责把外部系统的数据采集进来，PI Web API则把上述内容以REST方式暴露给上层应用。接口设计的本质，就是在这四层之间建立正确的映射关系。
一、PI Data Archive：以“点”为最小存储单元
PI Data Archive的核心对象是PI Point（点），它是时序数据的最小存储单元。每个点由一组属性定义，其中最关键的是：Point Name（点名），全局唯一，是接口写入和读取时的寻址依据；Point Type（点类型），如Float32、Float64、Int32、Digital、String、Timestamp，决定可存储的数据种类；Engineering Units（工程单位），如℃、kPa、m³/h；Zero与Span，用于定义量程和百分量换算；Compression/Exception/Compression Deviation，控制数据压缩与例外报告行为；Location1~5，常用于记录接口号、设备号、单元号等定位信息；InstrumentTag，通常保存外部系统的原始位号，是接口映射的关键字段。
点本身没有层级，只有名字。这意味着如果只依赖Data Archive，成千上万个点会形成一张扁平的清单。因此实际工程中必须借助命名规范和Location字段来“人为分层”，例如用 SITE01.AREA02.UNIT03.FIC101.PV 这样的点名表达位置与测点类型。接口设计时，点名一旦确定就应视为契约，后续AF、Web API、报表都依赖它，随意改名会导致整条链路断裂。
二、PI Asset Framework：把点组织成资产
AF在Data Archive之上引入业务语义，其核心概念是Element（元素）、Attribute（属性）、Template（模板）与Hierarchy（层级）。Element代表一个真实对象，如一台泵、一个反应釜、一条产线；Attribute是元素的特征，如温度、压力、运行状态；Template是一组预定义的Attribute集合，用于批量创建同类元素；Hierarchy则通过父子关系把元素组织成树，例如“企业→厂区→装置→单元→设备”。
Attribute的数据来源有三种典型形式：PI Point Data Reference，直接绑定到某个PI点；Formula，由其他Attribute计算得出，如效率=输出/输入；Static，保存固定值如设备型号。此外还有Table Lookup、String Builder等。接口设计中最常见的做法是：采集层写入PI点，AF层通过PI Point Data Reference把点挂到对应Attribute上，从而让上层应用按“设备.属性”而不是“点名”来访问数据。
模板的价值在于复用。假设有20台同型号泵，只需定义一个Pump_Template，包含Suction_Pressure、Discharge_Pressure、Flow、Running_Status等Attribute，然后基于模板实例化20个Element，每个实例只需指定各自的点名映射。这样接口新增一台泵时，工作量从“建几十个点并逐个配置”缩减为“实例化一个元素并填映射表”。
三、PI Interfaces与PI Connectors：数据进入系统的两条路径
PI Interface是传统采集组件，通常以Windows服务形式运行在接口节点上，通过UniInt框架与特定协议插件（如OPC DA、Modbus、SNMP）通信，把外部数据写入Data Archive。它的配置以.bat启动文件和.ini参数文件为主，需要手工维护点映射、扫描周期、异常报告等。灵活但运维成本高。
PI Connector是较新的采集方式，强调自动发现与自动建点。以OPC UA Connector为例，连接数据源后可浏览地址空间，自动创建PI点并建立AF元素，减少人工映射。它更适合数据源结构清晰、点位数量大的场景。选择Interface还是Connector，直接影响后续AF模型的自动化程度和运维方式，是接口架构阶段必须明确的决策点。
四、PI Web API：面向应用的统一访问入口
PI Web API把Data Archive、AF、事件框架等能力封装为RESTful接口，典型资源路径包括/piwebapi/dataservers、/piwebapi/assetdatabases、/piwebapi/elements、/piwebapi/streams/{webId}/recorded等。上层应用不再直接连Data Archive，而是通过Web API按WebID访问元素和属性。这意味着AF模型的规范性直接决定Web API调用的简洁程度：模型清晰，一次/streams/{webId}/recorded就能取到某设备某属性的历史数据；模型混乱，则调用方需要自己拼点名、做关联。
五、四层关系如何决定接口设计
把上述组件串起来看，接口设计实际上要回答四个问题：数据从哪来（Interface还是Connector）、存成什么点（PointType、EU、压缩参数）、挂到哪个元素属性（AF模板与映射）、怎么被消费（Web API路径与WebID）。这四个问题层层依赖：点类型选错，AF公式无法计算；模板设计不合理，Web API调用会变得冗长；命名不规范，接口维护时无法快速定位。
一个常见的教学示例是：某装置有3台循环泵，每台需采集出口压力、流量、运行状态。若采用Interface方式，需在Data Archive建9个点，命名如SITE01.AREA02.UNIT03.PUMP01.DISCH_PV；在AF中定义Pump_Template，包含Discharge_Pressure、Flow、Running_Status三个Attribute，并分别绑定对应点；实例化3个Element，路径为SITE01\AREA02\UNIT03\PUMP01等。上层应用通过Web API访问/streams/{webId}/recorded即可取到任意泵任意属性的历史数据。若改用OPC UA Connector，则连接后可自动发现这9个变量并建点，AF元素也可由Connector自动创建，人工只需校验模板映射是否正确。
理解这四层对象及其关系，是后续所有接口配置、AF建模、Web API集成工作的共同基础。点决定数据能不能存，模板决定数据好不好用，层级决定数据能不能被快速找到，而Web API决定数据能不能被方便地消费。