3. 过程历史数据模型与命名规范

在 DeltaV 过程历史数据平台中，历史库并不是一张“大表”，而是由若干类数据模型共同支撑：连续量、离散量、批次量、事件、报警、参数以及模块路径。它们各自有不同的采集方式、存储结构和查询语义。如果建模阶段把连续量当成离散量处理，或者把报警和事件混为一谈，后续的趋势查询、批次追溯和 KPI 统计都会出现偏差。本节从“数据对象是什么、应该怎么建、实际怎么落地”三个层面展开。

一、连续量：以周期采样和死区压缩为核心

连续量指温度、压力、流量、液位、阀门开度等随时间连续变化的模拟量。DeltaV 中这类数据通常来自模拟输入通道、PID 回路输出或计算模块输出。建模时最关键的两个参数是采样周期和死区（Deadband）。

采样周期决定历史库写入频率。例如某反应器温度回路 PV 需要 1 秒级趋势用于控制分析，而储罐液位只需 30 秒级趋势用于库存统计。若统一按 1 秒采集，历史库体积会迅速膨胀。死区则用于抑制噪声：当 PV 变化量小于死区时，不写入新值，只保留时间戳。例如温度死区设为 0.5 ℃，压力死区设为 0.02 MPa，流量死区设为满量程的 0.5%。

实际配置时，在 DeltaV 的 History Collection 中为每个参数指定采集类型为“Continuous”，并设置采集周期与死区。历史库中存储的是“时间戳 + 值 + 质量码”，质量码用于标识数据是否有效、是否被手动替换。查询时通常按时间范围返回压缩后的趋势点，而不是原始点。

二、离散量：状态、持续时间与跳变沿

离散量指只有有限状态的信号，如泵的运行/停止、阀门的开/关、联锁的投入/切除。DeltaV 中离散量通常来自数字输入、离散输出或逻辑模块。建模时不能只记录“当前值”，还要记录状态持续时间和跳变沿。

例如某泵的运行信号 P101_RUN，历史库中应记录每次从 0 变 1 的起始时间、从 1 变 0 的结束时间，以及该状态持续了多久。这样后续才能统计“泵累计运行小时数”或“一天内启停次数”。如果只存瞬时值，这些统计就无法完成。

离散量的采集通常采用“变化时记录”（On Change）方式，即状态跳变时写入一条记录。对于需要计算持续时间的场景，查询时用相邻两条记录的时间差即可。需要注意的是，离散量也要设置质量码，用于区分“真实跳变”和“通信中断导致的无效值”。

三、批次量：以 Batch ID 为主键的上下文绑定

批次量是过程历史中较特殊的一类。它描述的是“某个批次在某个时间段内发生了什么”。DeltaV 中批次通常由 Batch Executive 或 Recipe 管理，历史库需要把批次 ID、配方名称、单元模块、阶段名称与时间范围绑定起来。

建模时，批次量不是单独存一个数值，而是建立批次上下文：Batch ID 作为主键，关联该批次内所有连续量、离散量和事件。例如批次 B20240612_001 在反应器 R101 中运行，配方为 POLY_A，阶段包括“进料”“升温”“保温”“出料”。历史查询时，用户输入 Batch ID，系统返回该批次内所有相关参数的趋势和事件。

实际落地时，需要在 DeltaV 中为批次模块配置历史采集，确保 Batch ID 能传递到每个参数记录中。否则后续只能按时间范围“猜”批次，无法精确追溯。

四、事件与报警：语义不同，建模方式也不同

事件和报警经常被混用，但在历史数据模型中它们有明确区别。事件是“系统中发生的动作或状态变化”，如操作员登录、配方下载、模块模式切换、批次开始/结束。报警是“过程变量越过报警限或触发报警条件”，如温度高报、压力低报、联锁动作。

事件建模通常记录：事件时间、事件类型、事件源（模块路径）、操作员、事件描述。报警建模则记录：报警时间、报警类型（HI/LO/DEV）、报警优先级、报警状态（激活/确认/清除）、报警限值、当前值。两者都需要与模块路径关联，才能定位到具体设备。

在 DeltaV 中，报警和事件通常由 Event Chronicle 或 Alarm History 采集。建模时要确保报警的“激活—确认—清除”三个状态都被记录，否则无法统计报警持续时间或操作员响应时间。

五、参数与模块路径：历史数据的“地址系统”

DeltaV 中每个可采集的数据点都对应一个参数，而参数又挂在模块路径下。模块路径类似文件系统路径，例如：

\\PLANT1\AREA1\R101\PID1\PV
\\PLANT1\AREA1\P101\DIN1\VALUE
\\PLANT1\AREA1\BATCH1\BATCH_ID

其中 PLANT1 是工厂节点，AREA1 是区域，R101 是单元模块，PID1 是控制模块，PV 是参数名。历史库中每条记录都应包含完整模块路径，否则同名参数在不同模块中会混淆。例如多个反应器都有 PID1\PV，只有路径才能区分。

建模时建议统一命名规范：模块名使用设备位号（R101、P101），参数名使用 DeltaV 标准参数（PV、SP、OP、VALUE），批次参数使用 BATCH_ID、RECIPE_NAME、PHASE_NAME。路径分隔符统一使用反斜杠，大小写保持一致。

六、建模落地：从命名规范到查询验证

把上述模型落到 DeltaV 工程中，建议按以下顺序推进。第一步，梳理需要采集的参数清单，按连续量、离散量、批次量、事件、报警分类。第二步，为每个参数确定模块路径，并检查路径是否唯一。第三步，在 History Collection 中配置采集类型、周期和死区。第四步，对批次量配置 Batch ID 传递。第五步，对报警和事件确认采集范围。

验证时，可以选取一个典型批次，查询该批次内 R101\PID1\PV 的趋势，检查是否覆盖“进料—升温—保温—出料”全过程；同时查询该批次关联的报警记录，确认报警时间与趋势变化是否对应。如果趋势中出现断点，检查质量码是否为 Bad；如果批次查询返回空，检查 Batch ID 是否写入历史库。

总结来看，DeltaV 过程历史数据模型的核心是“路径定位 + 类型决定采集方式 + 质量码保证可信”。连续量关注采样与死区，离散量关注跳变与持续时间，批次量关注上下文绑定，事件与报警关注语义区分，参数与模块路径关注唯一寻址。只有这些模型协同工作，历史库才能支撑趋势分析、批次追溯和报警统计等实际工程需求。