简介CITECT数据库说明.doc 是一份专为自动化与SCADA系统工程师、数据库管理员准备的技术文档系统梳理了CitectSCADA Reports内嵌历史数据库的平台架构与核心机制。文档从数据管理需求出发讲解其如何借助冗余SCADA连接器、自动数据回补和MS SQL Server 2005安全特性保证死机或停机时历史数据不丢失同时解析了逢变则存、每标签死区设置、100纳秒时间戳及OPC质量标记等高精度采集原理。针对实际应用文档还涵盖数据接口方式SQL Native Client、OLE-DB、ODBC、Web服务、主动ETL数据交换、磁盘空间计算及SQL安全审计等内容并给出了支持的SCADA系统CitectSCADA、InTouch、Fix32、IFix和企业数据库MS SQL、Oracle的兼容性说明。压缩包内含1个doc文档大小1.42MB内容组织清晰适合在选型评估、系统部署或运维排障时对照查阅。该资源已有311人学习下载可作为快速理解Citect历史数据库能力与配置要点的参考。1. 一套思考了很久的 Citect 历史库设计值得读SCADA 项目做到第七八年最怕的不是画面不好看而是老板突然要“过去三年 2 号线的温度趋势”结果历史库里全是压缩过的折线尖峰被抹平只能回一句“数据精度不够”。这份关于 CitectSCADA Reports 的数据库说明文档解决的正是这个问题。它不是讲怎么画画面而是讲一套把过程数据落进 SQL Server 的完整方案逢变则存、死区过滤、OPC 质量标记、主动 ETL以及真正可用的历史数据查询接口。无论你现在用的是 Citect 还是别的组态软件这套历史库的取舍逻辑——什么时候存、存多少、怎么保证不丢——都值得拿来对照自己的项目。2. 从 VTQ 到表结构历史数据不是简单存个值2.1 VTQ 四元组是历史库的基石文档里反复提到“每个变化的存储都带有时间标记精度可达 100 纳秒并且有一个 OPC 的质量标记”。这本质上就是工业历史库最常见的 VTQ 模型Value数值、Timestamp时间戳、Quality质量。Citect 的实时数据库还多一个 Tag 维度所以实际是四元组Tag、Value、Timestamp、Quality。这里容易被忽略的是“质量”字段。很多自写的历史存储只存数值和时间OPC 质量位一丢后面做数据分析时你根本分不清这 50 度是真实测量值还是设备断线后的保持值。Citect 的做法是把 OPC 状态和子状态一起存高字节存自定义子状态比如“手动置值”“初始化”“溢出”。我在项目里就吃过亏现场仪表断线后数值保持在 100如果历史库不记录质量位趋势上就是一条平直的 100 度直到事后查报警才暴露。所以如果你要自建历史表质量字段一定要留 INT别用 BIT。2.2 逢变则存和死区压缩的另一种思路文档里有一段很关键别的软件用“最佳线数据趋势曲线”做压缩Citect 用“逢变则存”。这不是说完全不压缩而是压缩策略变成了“变化才存”。对每个标签你定义一个死区比如温度死区 0.5 度那么只有当新值和上次存储值的差值超过 0.5 时才会触发一次新记录。这个机制的 SQL 层面的实现常见做法是在写入存储过程中做一次比较-- 伪代码Citect 标签写入历史表前判断死区 DECLARE last_value FLOAT SELECT last_value Value FROM dbo.TagHistory WHERE TagName tag AND RecordTime (SELECT MAX(RecordTime) FROM dbo.TagHistory WHERE TagName tag) IF ABS(new_value - last_value) deadband OR new_value IS NULL BEGIN INSERT INTO dbo.TagHistory (TagName, RecordTime, Value, Quality, Deadband) VALUES (tag, new_time, new_value, quality, deadband) END逻辑说明先取该标签最新一条记录的值和当前新值做差。差的绝对值大于等于死区才写入。这个判断必须放在写入端不能放在采集端否则网络抖动会造成采样延迟。死区一般取量程的 0.1%0.5%对于压力、流量这种波动频繁的点可以放大到 1%对于液位这种缓慢变化的点可以设 0.2%。参数说明deadband是每个标签独立配置的Citect 文档中“死区每个标签”就是这意思。设太大丢失真实波动设太小死区形同虚设建议先观察 24 小时变化率再定。2.3 历史表的结构设计建议文档说“数据直接存储到 SQL 服务器的表中”但没给建表语句。按 CitectSCADA Reports 的常见落库方式历史数据一般拆成“实时值表”和“报警表”实时值表按时间分表或者分分区。典型的表结构如下CREATE TABLE dbo.TagHistory ( TagName NVARCHAR(64) NOT NULL, RecordTime DATETIME2(7) NOT NULL, -- 对应 100ns 精度SQL Server 2005 用 DATETIME精度 3.33ms Value FLOAT NULL, Quality INT NOT NULL, -- OPC 质量位 SubStatus TINYINT NULL, -- 自定义子状态 CONSTRAINT PK_TagHistory PRIMARY KEY CLUSTERED (TagName, RecordTime) );注意SQL Server 2005 默认的 DATETIME 精度约 3.33 毫秒Citect 文档里的 100ns 是外部时标才能达到你用普通版 SQL 时RecordTime 精度会受数据库类型限制。后来项目里换到 SQL Server 2016我才用 DATETIME2(7) 真正把 100ns 精度落下来。如果是老系统建议用 DATETIME然后靠“同一标签同一毫秒只存最后一条”的规则去重不然索引膨胀很快。2.4 为什么用 SQL Server 而不是时序数据库文档成文时还是 SQL Server 2005 时代选择它的理由现在看来依然成立IT 部门熟悉报表工具现成安全审计方便。但代价是存储开销大——同样是 1 秒 5 万个变化用 SQL Server 表存储单条记录按 50 字节算一天就是 216GB所以文档才强调“磁盘空间计算器”和“逢变则存”的必要性。你现在如果接的是新项目可以选 TimescaleDB 或 InfluxDB 代替但 Citect 这套设计里的质量位和死区概念时序库也得自己实现。3. 采集写入与接口100ms 采样和每秒 10 万变化怎么撑住3.1 性能指标的工程含义文档给了三组硬性指标采集周期 100ms、精度 100ns、读取性能每秒 10 万变化双 CPU。这组数据说明 CitectSCADA Reports 不是简单跑一条 INSERT而是有专门写出队列。工程上拆解下来是三层缓冲采集层Citect 运行时按 100ms 周期把标签变化放进内存队列写入层独立线程批量把队列里的数据写进 SQL Server每批 5002000 行回补层网络或数据库故障时数据先落本地趋势文件恢复后自动回补。你自己做数据采集时最忌一条变化一条 INSERT。用 SQL Server 的 TVP表值参数批量写入速度能到每秒几万行-- 创建表类型 CREATE TYPE dbo.HistoryType AS TABLE ( TagName NVARCHAR(64), RecordTime DATETIME2(7), Value FLOAT, Quality INT ); -- 存储过程批量插入 CREATE PROCEDURE dbo.BulkInsertHistory history dbo.HistoryType READONLY AS BEGIN SET NOCOUNT ON; INSERT INTO dbo.TagHistory (TagName, RecordTime, Value, Quality) SELECT TagName, RecordTime, Value, Quality FROM history OPTION (RECOMPILE); END逻辑说明Citect 的报表服务在内部做的工作类似这个存储过程。READONLY表值参数避免逐行拼接 SQLOPTION (RECOMPILE)让优化器根据批大小选择索引连接方式避免因为参数数量差异导致执行计划走偏。性能参数参考普通 SSD SQL Server 2016单表 500 万行时这个存储过程每秒可处理 5 万行双 CPU 场景拼到 10 万行基本就接近文档指标了。若达不到一是把索引去掉二是把日志文件放到独立物理盘。3.2 OPC 和 API 接口的正确打开方式文档提到“开放的 OPC、API 标准”。实际接口有三种OPC DA、OPC HDA、SQL Native Client。CitectSCADA Reports 作为 OPC 客户端连接各 SCADA 系统时常见配置方式!-- Citect Reports 的 IO 设备连接串示意 -- OPCConnection Serveropcda://localhost/Citect.OPC.1/Server UpdateRate100/UpdateRate Deadband0.5/Deadband QualityModeInclude/QualityMode /OPCConnection参数说明UpdateRate100 毫秒对应文档的采样周期Deadband就是第 2 章的死区这里做双层过滤OPC 服务器先滤一遍SQL 写入时再滤一遍QualityMode设为 Include 是为了把 OPC 质量位完整带进历史表。3.3 磁盘空间计算器与历史表膨胀的四个参数文档里提到 Citect 提供磁盘空间计算器和性能计数器用来显示每秒钟发生的变化。这个计算器的核心公式是单日存储量 单条记录字节数 × 标签数 × 每小时变化次数 × 24我一般按经验值估算FLOAT 值 DATETIME INT 质量位 索引开销单条约 64 字节。如果有 5000 个标签每个标签每小时变化 300 次即每 12 秒变一次一天的数据量是-- 用 SQL 直接估算 SELECT 5000 AS TagCount, 300 AS ChangesPerHour, 64 AS BytesPerRecord, 24 AS HoursPerDay, 5000 * 300 * 64 * 24 / 1024.0 / 1024.0 AS StorageMB_PerDay;算出来约 2197MB/天一个月就是 66GB。这还没算死区过滤后的压缩效果。如果发现实际存储量远大于这个值优先检查两个点一是死区是否没配二是 SQL 日志文件是否没做自动收缩。4. 实时库同步和历史库复制的两套机制4.1 Citect 实时数据库的 NETBIOS 同步文档写得很明确CitectSCADA 之间的实时数据同步靠 NETBIOS 名定位映射两个数据库的内存。这意味着同一网段内的两个 Citect 服务器只要 NetBIOS 名字互相能解析配置好“冗余 I/O 设备”就能自动把实时值镜像过去。这里没有太多可优化的实操中唯一要注意的是防火墙要用 UDP 137/138 和 TCP 139同时保证两台机器处于同一广播域。但实时同步有个明显边界它只同步当前值不同步历史。如果你要做异地历史库合并就得靠下面这套 SQL Server 复制。4.2 基于 SQL Server 复制的事务同步文档里讲的“出版、分发、订阅”是 SQL Server 2005 的标准复制模型。Citect 历史库用事务复制来把主控中心的历史表增量分发到备份服务器。配置步骤我整理成了一份可操作清单在发布服务器主历史库上启用分发EXEC sp_adddistributor distributor NPRIMARY\SQL2005; EXEC sp_adddistributiondb database Ndistribution, data_folder ND:\ReplData;创建发布USE [CitectHistory]; EXEC sp_addpublication publication NTagHistory_Pub, sync_method Nnative; EXEC sp_addarticle publication NTagHistory_Pub, article NTagHistory, source_table NTagHistory, type Nlogbased;在订阅服务器上创建订阅USE [CitectHistory_Sub]; EXEC sp_addsubscription publication NTagHistory_Pub, subscriber NSECONDARY\SQL2005, destination_db NCitectHistory, subscription_type Npush;关键点说明复制的事务读取发生在发布库的事务日志中。如果你在发布库上做大批量删除比如清理 3 个月前的数据务必用bcp或者分批删除否则日志增长把分发数据库撑爆订阅端延迟会越来越大。4.3 回补机制网络断了之后怎么办文档里有一段描述“一旦连接到历史数据的网络失效虽然不能实时获得数据但在网络正常时历史数据会通过控制系统的趋势和报警系统回传而获得。”这句话透露了一个重要特性历史数据不会因为网络中断而丢失SCADA 本地会暂存。对于基于 SQL Server 复制的场景这个回补功能是内建的。只要分发数据库里的命令还没被清理网络恢复后订阅端会自动追平。但如果断网时间超过分发数据库的清理周期默认 72 小时你就需要手动补数据。常见做法是生成差异 CSV 再导入# 在故障期间的历史库上导出增量数据 bcp SELECT * FROM CitectHistory.dbo.TagHistory WHERE RecordTime 2025-01-01 00:00:00 queryout backfill.csv -S PRIMARY -U sa -P **** -c -t , # 在备份库上导入 bcp CitectHistory_Sub.dbo.TagHistory in backfill.csv -S SECONDARY -U sa -P **** -c -t ,注意回填前要先查目标库的最大时间戳避免重复。5. 用 T-SQL 从 Citect 历史库里挖出生产指标5.1 利用内置视图和函数做统计文档最后专门提到CitectSCADA Reports 提供表格、视图和用户函数用于求第一条、最后一条、最大值、最小值、平均值、总值以及开关次数和开关时间统计。这些统计能按时间区间或者变量值区间查询典型例子是“泵运行时长”。假设你有一台泵的启停信号标签PUMP_RUN0/1要统计每个班次8 小时它的运行占比标准做法是取PUMP_RUN从 0 变 1 和从 1 变 0 的时间差WITH Changes AS ( SELECT RecordTime, Value, LAG(Value) OVER (PARTITION BY TagName ORDER BY RecordTime) AS PrevValue FROM dbo.TagHistory WHERE TagName PUMP_RUN AND RecordTime BETWEEN shift_start AND shift_end ), Intervals AS ( SELECT RecordTime AS StartTime, LEAD(RecordTime) OVER (PARTITION BY TagName ORDER BY RecordTime) AS EndTime, Value FROM Changes WHERE (PrevValue IS NULL OR Value PrevValue) -- 只取变化点 ) SELECT SUM(DATEDIFF(SECOND, StartTime, EndTime)) AS RunSeconds FROM Intervals WHERE Value 1 AND EndTime IS NOT NULL;逻辑说明LAG函数找出每条记录的前一个值如果当前值与前值不同说明这是一次状态跳变。从这些跳变点里用LEAD取出下一次跳变时间作为结束时间那么“值为 1”的区间就代表泵运行时长。这个写法能直接避开“逢变则存”造成的时间间隔不均匀问题无论死区设多大统计结果都准确。注意如果你的历史表里没有只存变化点即没有死区过滤那LAG这步可以用WHERE DATEDIFF(SECOND, RecordTime, LAG(RecordTime)...) 0代替但性能会差很多。务必确认TagName RecordTime上有索引。5.2 使用 EXCEL 和 WEB 客户端直接查Citect 的“无限 Excel 客户机”是相对省成本的功能。只要装了 CitectSCADA Reports Server任何一台装 Office 的机器都能用 Excel 通过 ODBC 拉历史数据。连接串示例Driver{SQL Server};ServerPRIMARY;DatabaseCitectHistory;Trusted_Connectionyes;这时候你会发现Excel 里RecordTime显示的是 UTC 还是本地时间取决于 Citect 报表服务器写入时用的是哪个时区。如果项目跨时区建议在查询时显式转换SELECT TagName, DATEADD(HOUR, 8, RecordTime) AS BeijingTime, Value, Quality FROM OPENQUERY(SCADA_LINK, SELECT TagName, RecordTime, Value, Quality FROM CitectHistory.dbo.TagHistory) WHERE TagName REACTOR_TEMPOPENQUERY是为了让远程 SCADA 服务器执行过滤而不是把整表拉回本地能省大量网络带宽。5.3 一个实用技巧用质量位过滤“脏数据”最后说一个直接从文档里延伸的技巧。Citect 将 OPC 质量标记存储在历史表中质量位 1920xC0表示“好的非特定质量”其他值分别代表不确定或坏。很多人在做数据报表时直接对 Value 求平均结果把停表后的保持值也算了进去。正确做法是加一个质量过滤条件SELECT TagName, AVG(CASE WHEN Quality 192 THEN Value ELSE NULL END) AS Avg_Good FROM dbo.TagHistory WHERE RecordTime DATEADD(DAY, -1, GETDATE()) GROUP BY TagName;这样计算出的平均值只包含质量正常的样本。同样的逻辑也适用于最大值、最小值和累计值。配合第 2 章的死区设计你会得到一个既省空间又经得起审计的历史库。本文还有配套的精品资源点击获取