本篇完成什么按批次关联工艺曲线与累计量用一组数字算出公辅单耗并说明清洗过程记录能够证明什么。一批产品从夜班跨到早班蒸汽表按零点出日报灌装产量却按工单结算。把两列直接相除就会把不同时间窗口的数据算成“本批单耗”。先定义批次开始和结束再选择同一边界内的产量与消耗。本文用 Rapid SCADA v6 的通道和归档作为数据基础。批次台账、资源分摊和质量判定需要业务记录与统计实现本文的数字是算例不提供清洗工艺处方或食品安全达标判定。1. 通道和批次记录各存什么数据建议内容作用工艺实时通道温度、压力、流量、阀位、设备状态及质量监视和曲线追溯公辅累计通道蒸汽累计、水累计、电量累计区间消耗计算批次主记录批次ID、工单、产品、设备、开始/结束时间定义统计边界产量/质检记录总产量、合格产量、复检与修订版本确定单耗分母和质量来源清洗步骤记录回路、步骤、开始/结束、参数与配方版本还原实际过程批次ID不是从画面标题推断出来的。开始、结束和切换事件来自已约定的PLC/生产系统接口并具有去重身份。重复收到“批次结束”不应重复创建一份消耗。工段可以按糖化、发酵、清洗、灌装组织对象和编号但同一物理温度或公辅表计不应被多份复制通道各自统计。共享资源用分摊规则处理不能为让画面整齐就重复计量。2. 确认批次边界后再取归档以批次 B001 为例开始时间22:00次日02:00结束。业务统计窗口是这4小时而不是某一天的00:00到24:00。为每个计量点取得边界附近符合规则的累计示值并记录实际采样时间。如果边界没有有效点是取设备冻结值、使用允许误差内的邻近点还是估算需要明确规则不能把前一小时的旧值无说明地当成批次起点。源数据使用 UTC 保存时批次业务时间先按约定时区转换。跨零点不应该被拆成两个不完整批次除非项目本身要求按班次另外分摊。3. 用同一批次的数据计算单耗假设该批次蒸汽累计起止值为1200.0和1224.0 t合格产品80.0 t总产量82.0 t本批已计量蒸汽消耗 1224.0 - 1200.0 24.0 t 按合格产量计算单耗 24.0 / 80.0 0.300 t/t 按总产量计算单耗 24.0 / 82.0 ≈ 0.293 t/t两个结果都能算出但指标名称和用途不同。报表必须写出分母不把它们都叫“本批蒸汽单耗”。合格产量为0或尚未终结时应显示不可计算/暂结状态不输出0单耗。累计表跨批次清零、换表或倍率变化时按计量段拆分不能简单用期末减期初得到负数后取绝对值。历史补回或质检修订后重算同一批次并保留版本。4. 用两张业务表把 B001 算到可重复查询为了让读者能从数据得到结果下面给出一个完整的 SQLite 示例。它使用独立业务表不是 Rapid SCADA 的内置归档表名。生产中先用目标归档服务/API读取并保留源记录再按经过验证的规则写入业务库批次与产量来自相应生产记录。不要直接修改平台归档文件。batch定义统计边界与合格产量meter保存指定计量点累计值、质量及计量段。segment在换表、倍率变化或确认清零时切换不能只按自然日生成。主键(meter_id,ts)防止同一读数重复插入但有修订冲突时还要由上游版本规则决定保留哪条。保存以下内容为batch.sql在支持窗口函数的 SQLite 3.25及以上执行sqlite3 :memory: batch.sql。窗口函数语法可查 SQLite 官方文档。CREATETABLEbatch(idTEXTPRIMARYKEY,start_sINTEGERNOTNULL,end_sINTEGERNOTNULL,good_tREALNOTNULLCHECK(good_t0),CHECK(end_sstart_s));CREATETABLEmeter(meter_idTEXTNOTNULL,tsINTEGERNOTNULL,value_tREALNOTNULL,goodINTEGERNOTNULLCHECK(goodIN(0,1)),segmentTEXTNOTNULL,PRIMARYKEY(meter_id,ts));-- 固定 UTC 时刻对应北京时间 2026-01-01 22:00 至次日 02:00。INSERTINTObatchVALUES(B001,1767276000,1767290400,80.0);INSERTINTOmeterVALUES(steam-main,1767275940,1199.8,1,meter-A-v1),(steam-main,1767276000,1200.0,1,meter-A-v1),(steam-main,1767283200,1212.0,1,meter-A-v1),(steam-main,1767290400,1224.0,1,meter-A-v1);CREATEVIEWbatch_resultASWITHchosenAS(SELECTb.*,m.ts,m.value_t,m.good,m.segment,row_number()OVER(PARTITIONBYb.idORDERBYm.ts)ASn,lag(m.value_t)OVER(PARTITIONBYb.idORDERBYm.ts)ASprevFROMbatch bJOINmeter mONm.meter_idsteam-mainANDm.tsBETWEENb.start_sANDb.end_s),checkedAS(SELECTid,max(start_s)ASt0,max(end_s)ASt1,max(good_t)ASgood_t,min(ts)ASfirst_ts,max(ts)ASlast_ts,count(*)ASpoints,count(DISTINCTsegment)ASsegments,min(good)ASall_good,sum(CASEWHENn1ANDvalue_tprevTHEN1ELSE0END)ASfalls,max(CASEWHENtsstart_sTHENvalue_tEND)ASv0,max(CASEWHENtsend_sTHENvalue_tEND)ASv1FROMchosenGROUPBYid),validatedAS(SELECT*,CASEWHENfirst_tst0ANDlast_tst1ANDpoints2ANDall_good1ANDsegments1ANDfalls0THEN1ELSE0ENDASvalidFROMchecked)SELECTb.id,CASEWHENv.valid1THENv.v1-v.v0ENDASsteam_t,CASEWHENv.valid1ANDb.good_t0THEN(v.v1-v.v0)/b.good_tENDASunit_t_t,CASEWHENv.validISNOT1THENREVIEWWHENb.good_t0THENNO_DENOMINATORELSEREADYENDASstateFROMbatch bLEFTJOINvalidated vONv.idb.id;SELECTid,steam_t,round(unit_t_t,3)ASunit_t_t,stateFROMbatch_result;应输出B001|24.0|0.3|READY。示例用UTC秒数固定了北京时间22:00–次日02:00的四小时窗口零点中间读数1212参与单调性检查不会将批次切成两天。开始前一分钟的1199.8也不会被误取为起点。这条查询有意采用严格边界首尾都必须有有效的、属于同一计量段的读数窗口内不能出现坏质量或累计下降。缺任意一项便返回REVIEW同时把消耗和单耗留空分母为0则返回NO_DENOMINATOR。没有读数的批次也保留一行待核结果不从报表里消失。严格边界并不要求所有现场都刚好在整秒采到冻结值。实际项目可使用设备冻结接口或经确认的邻近点/插值策略但必须记录真实源时间、偏差、算法和质量。不能伪造一个“恰好等于批次开始”的测量时间让SQL检查表面通过。用四次故障注入看查询是否会给假数在独立测试库逐项修改后重查batch_result每次恢复初始样本再测试下一项注入预期删除开始时间1767276000的读数REVIEW不是拿前一分钟替代将中间读数1212改为1190检出累计下降REVIEW中间读数质量设为0REVIEW不能删除坏点后照常报合格中间读数计量段改为meter-B-v1REVIEW先处理换表或清零分段合格产量改为0仍可保留24 t消耗单耗为空两个边界示值恢复得很高不能反证中途一定没有清零。脚本只能检查已保存读数和分段元数据如果上游丢掉了复位事件算法无法凭空恢复需补采事件或人工确认并保留“证据不足”。重复结束事件和质检晚到怎样避免重复累计本例结果是查询视图同一个B001查十次仍是24 t不会累加成240 t。批次结束接口应按批次ID和来源事件身份幂等落库历史修订按同一业务键重算。报表发布版本再单独保存不能每次刷新都创建新“消耗事实”。例如在上面脚本之后建立版本快照CREATETABLEbatch_report(batch_idTEXTNOTNULL,revisionINTEGERNOTNULL,steam_tREAL,good_tREALNOTNULL,unit_t_tREAL,stateTEXTNOTNULL,source_revisionTEXTNOTNULL,PRIMARYKEY(batch_id,revision));INSERTINTObatch_reportSELECTr.id,1,r.steam_t,b.good_t,r.unit_t_t,r.state,demo-source-v1FROMbatch_result rJOINbatch bONb.idr.id;SELECT*FROMbatch_report;若同一版本再插入主键应拒绝重复由业务层读取已有快照并比较来源不能通过另起一条消耗绕过去。质检修订时更新经过授权的生产记录重新计算后发布revision2保留revision1的分母和结果列表使用最新有效版本审计仍可查看旧版。以上SQL已在本地SQLite内存库执行并测试缺边界、坏质量、累计下降、计量段变化、无数据和零分母。这里验证的是统计与幂等的数据结构不代表已经接入真实生产系统或完成质量放行。5. 共享公辅不能自动归给某一罐如果一块蒸汽总表同时供两条生产线它只证明两条线在该时间窗内合计消耗。没有分项表或经确认的分摊依据就不能把总表差值分别写成两条线各自的实测消耗。可以选择分项计量或定义按运行时间、有效产量等分摊的业务方法。采用分摊时保存权重、覆盖对象、算法版本并标明“分摊值”。若按60%和40%分摊24 t则结果14.4 t与9.6 t两者之和应仍为24 t。公辅表计的实际时间边界、计量点和数据质量与分摊方法一起保留避免把统计估算展示成直接仪表测量。6. CIP 记录应还原步骤与时间清洗页面显示一次“温度已达到”不能证明整个要求时段都满足条件。过程记录至少关联回路、步骤、配方版本、开始/结束时间、相关参数及其有效质量。若项目要求某条件连续满足指定时间统计应按真实时间区间核验并对中断、无效采样、步骤跳转和人工干预留痕。具体温度、浓度、流速和持续时间由经过确认的工艺要求提供本文不给统一参数。SCADA 曲线和记录用于追溯清洗合格与产品放行仍需对应的质量流程。把图表上的一条线改成绿色不会补齐缺失的过程证据。7. 一次验收应覆盖这些异常测试检查结果B001跨零点仍按同一批次22:00–02:00统计蒸汽差值24 t、合格产量80 t单耗0.300 t/t原始读数可查共享24 t按60/40分摊14.49.624明确标识分摊结束事件重复不重复增加批次消耗累计量中途清零分段重算或待核不产生负消耗质检结果晚到暂结转终结有修订时间和版本CIP关键步骤数据缺失标记证据不完整不自动判合格排障先看批次ID、时间窗和表计覆盖范围再看累计量质量和分母来源。只有这些口径一致工段曲线、批次报表与公辅单耗才能互相核对。官网Rapid SCADA 中文站