1. 引言
EAST (Experimental Advanced Superconducting Tokamak)是中国自主设计、建造，并成功投入实验运行的世界首台全超导托卡马克[1]。技术诊断系统负责采集超导线圈、支撑结构、馈线等关键部件的温度、电阻、电压等数据，为装置运行安全提供支撑[2]。随着监测通道数量和采样频率不断增加，传统归档系统在数据一致性、检索效率及可扩展性方面已难以满足需求，亟需构建高效、稳定的归档方案。针对大规模实验装置产生的时序数据，业界已有多种开源时序数据库(TSDB)方案，如InfluxDB、Prometheus、TimescaleDB等。这些系统在工业监控领域性能优异，但与EPICS控制框架兼容性较差。考虑到EAST技术诊断系统基于EPICS架构，本文选取其生态中的两种典型归档组件——Archive Appliance (AA)与RDB Archive Engine (AE)进行对比研究。二者均能直接对接IOC层PV数据流，具有代表性与工程实用性。通过softIOC生成模拟诊断数据，分别基于AA和AE实现归档，并利用Phoebus客户端对其历史数据查询性能与系统资源占用进行评估，以验证两种方案在EAST主机诊断数据归档中的适用性。
2. EPICS架构
EPICS全称为“Experimental Physics and Industrial Control System”，是上世纪90年代初由美国洛斯阿拉莫斯国家实验室(LANL)和阿贡国家实验室(ANL)等联合开发的大型控制软件系统，许多大型科学研究工程项目都开始采用，比如中科院高能物理研究所的加速器控制系统，同步辐射实验室的同步辐射光源装置等[3] [4]。
EPICS软件结构分为四层：驱动层负责与底层硬件设备进行交互，该层将各类控制设备(如PLC、AD/DA、采集卡等)统一封装为标准接口，向上提供数据读写功能。数据处理层是EPICS的核心逻辑层，通过各种记录类型(如ai、ao、bi、bo、calc等)定义PV的处理方式和属性。IOC层是EPICS系统的执行核心，负责加载数据库文件、初始化驱动模块并运行数据处理逻辑[5] [6]。每个IOC运行一个独立的控制进程，管理本地PV并与外部系统通信。通信与客户端层作为最上层负责实现IOC与客户端之间的数据通信和交互，主要基于Channel Access协议，是系统的人机交互接口。关于IOC软件结构见图1。
Figure 1. IOC software architecture
图1. IOC软件结构
3. EAST技术诊断数据的需求分析
(1) EAST技术诊断数据如果直接存储为原始格式(例如二进制流、PLC内部寄存器值)，后续的归档、查询、显示都会因为不同设备、不同系统之间的存储数据格式和访问方式差异很大导致复杂化。因此，需要将底层的多种EAST诊断数据类型转化为一种统一的数据类型进行存储，方便后续对数据的管理。
(2) 连续变化类信号(如温度、电阻)通常变化平缓，需要完整记录其变化趋势，用于分析热负荷、材料应力等，突变类信号(如超导线圈失超探测、电流快速上升)可能在极短时间内发生剧烈变化，若采用固定周期采样，可能错过关键瞬间。因此，需要采用基于变化采样和周期采样策略。
(3) 数据存储采用传统关系型数据库直接存储技术诊断数据，不仅磁盘空间消耗巨大，而且容易因数据表过大而导致写入与访问性能显著下降。在实验分析过程中，科研人员通常需要根据数据变量名称与时间范围快速检索历史数据。若数据集中存放在单一数据库表或少量文件中，查询往往需要长时间的扫描，就会导致数据检索速度慢，系统响应时间长[5]。因此，在数据存储方面需要采用数据压缩和分区存储策略。
(4) 多用户同时访问诊断数据监控界面时，系统响应速度明显下降，部分用户可能出现数据无法加载或超时的情况。此外，现有的数据展示方式分散、界面功能单一，缺乏统一的可视化管理平台。因此，系统迫切需要建立一个统一的数据展示平台，以满足多用户并发访问的需求。
4. EAST技术诊断数据归档方案的设计与实现
在设计EAST技术诊断数据存储方案时，需要全面梳理数据从产生、转换、传输直至存储的完整流程，并结合数据流向图如图2明确诊断系统中以过程变量(PV)为核心的存储需求。同时，应对EAST技术诊断数据的特性进行深入分析，并针对当前数据存储中存在的问题提出相应的解决策略。鉴于EAST主机诊断系统尚未全面开放实时数据接口，因此在实验阶段采用softIOC生成模拟PV信号进行验证。模拟信号设计尽量贴近真实诊断环境：包括缓慢变化的温度信号、周期性波动的流量信号以及突变型的电压失超信号等，以覆盖典型的运行工况特征。通过这种方式，可以在不依赖真实硬件的前提下，对归档系统的采样稳定性、数据完整性及查询性能进行定量测试。这种基于模拟环境的方案既降低了实验风险，又为后续接入EAST实机信号提供了验证基础与参数参考。基于AA和AE的整体设计如图3和图4。
Figure 2. EAST technology diagnostic data flow diagram
图2. EAST技术诊断数据流向图
Figure 3. AA archiving overall logic diagram
图3. AA归档整体逻辑图
Figure 4. Archive Engine archiving principle diagram
图4. Archive Engine归档原理图
4.1. 基于Archiver Appliance (AA)归档方案的设计与实现
本方案采用EPICS社区广泛使用的Archiver Appliance (AA)作为核心归档引擎[7] [8]。AA采用B/S架构，通过将WAR包部署于Tomcat服务器即可提供完整的归档服务。编译Archiver Appliance源码包将其部署在Tomcat上，执行脚本single_machine_ install.sh利用mysql-connector-java.jar将AA与MySQL连接，配置环境变量并设置短、中、长期存储位置export ARCHAPPL_SHORT_TERM_FOLDER=/usr/local/Archiver/store/STS、export ARCHAPPL_MEDIUM_TERM_FOLDER=/usr/local/Archiver/store/MTS、export ARCHAPPL_LONG_TERM_FOLDER=/usr/local/Archiver/store/LTS，运行修改好的 sampleStartup.sh 脚本，./sampleStartup.sh start/stop/restart，启动Archiver Appliance。
Figure 5. Main interface of the AA management platform
图5. AA管理平台主页
Figure 6. Comparison of historical trends of multiple PVs
图6. 多PV对比历史曲线图
AA采用三级数据分层存储策略，分别为shortTerm、mediumTerm和longTerm。Engine 模块将采集到的PV数据以.pb文件格式写入shortTerm路径，由ETL模块根据时间策略定期迁移至mediumTerm和longTerm，实现数据的高效管理与按需读取，提升了系统的响应效率与存储可扩展性。打开浏览器访问http://localhost:17665/mgmt/ui/index.html (如果AA不在本机需要将localhost替换为AA所在主机的IP)获取AA的归档和查询界面，如图5和图6所示，在界面中进行诊断数据PV的归档、采样策略、历史数据检索等操作。
在AA管理平台中，用户可以对已归档的PV执行多种管理操作[9] [10]。“修改归档参数”功能，可以调整PV的采样方式(如Monitor或Scan)、采样周期以及是否由其他PV控制归档条件；“暂停归档”用于临时停止某个PV的数据采集与存储，适用于调试或暂时无需记录数据的场景；“恢复归档”功能，使被暂停的PV再次开始归档；“删除PV”功能可以将其从系统中移除，虽然PV被移除，但其历史归档文件仍会保存在存储路径中；“数据合并”用于将PV的多个历史.pb数据文件进行整合，以提升检索性能；此外，系统还支持“重命名PV”，可在不影响数据的基础上对PV名称进行逻辑调整，方便后续统一管理与识别。
为实现历史数据的可视化检索与趋势展示，需在Phoebus客户端中配置Retrieval接口地址。在setting.ini文件里配置URL：pbraw://localhost:17668/retrieval用于指示客户端通过PB RAW协议从本机运行的Archiver Appliance中提取历史数据，是历史查询功能正常工作的前提条件之一。Phoebus与Archiver Appliance成功连接，如图7。
Figure 7. Phoebus retrieval interface based on the Archiver Appliance
图7. 基于Archiver Appliance的Phoebus检索图
4.2. 基于Phoebus Archive Engine (AE)归档方案的设计与实现
(1) 在MySQL里创建archive数据库和密码为$archive的archive用户，在archive数据库里创建归档PV所用的表，参考Phoebus里的MySQL.dbd文件[11]。
./archive-engine.sh -list列出数据库中已注册的归档引擎实例
./archive-engine.sh -engine Demo -export Demo.xml导出Demo实例配置文件Demo.xml进行修改
./archive-engine.sh -engine Demo -import Demo.xml -port 4812 -replace_engine重新导入Demo.xml并替代原始文件(设置引擎监听的端口号为4812)
./archive-engine.sh -engine Demo-port 4812启动归档引擎加载Demo实例，如果不指定.ini数据库配置文件，就默认加载内置的.ini配置文件，通过archive用户名和密码与archive数据库连接，内置的.ini文件连接数据库配置为：
org.csstudio.trends.databrowser3/urls=jdbc:mysql://localhost/archive|RDB*xnds://localhost/archive/cgi/ArchiveDataServer.cgi
org.csstudio.trends.databrowser3/archives=jdbc:mysql://localhost/archive|RDB*xnds://localhost/archive/cgi/ArchiveDataServer.cgi
./phoebus.sh启动Phoebus，如果不用-setting参数指定加载.ini文件，也会默认加载内置.ini文件使得Phoebus客户端与MySQL连接。
(2) 在PostgreSQL里创建tsarch数据库、密码为$archive的archive用户、密码为$tsarch的tsarch用户，在tsarch数据库里创建归档PV所用的表，参考Phoebus里的setup.sql文件[12]。(Archive Engine用tsarch用户连接tsarch数据库，Phoebus用archive用户连接tsarch数据库)授予用户archive当前数据库中public schema下所有表的所有权限。
psql -U postgres
CREATE USER archive WITH PASSWORD '$archive';
\q
psql -U postgres -d tsarch
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO archive;
使用-settings参数将Archive Engine与tsarch数据库连接并向其导入Demo.xml，然后重新运行Archive Engine加载Demo实例，则成功实现归档。使用python3 create_settings_template.py命令编译此.py脚本文件生成settings_template.ini文件，在.ini文件添加Phoebus连接tsarch数据库的语句：
org.csstudio.trends.databrowser3/urls=jdbc：postgresql：//localhost：5432/tsarch|RDB
org.csstudio.trends.databrowser3/archives=jdbc：postgresql：//localhost：5432/tsarch|RDB
./phoebus.sh -settings settings_template.ini启动Phoebus并加载.ini文件后成功与PostgreSQL里的tsarch数据库连接，如图8。
Figure 8. Phoebus retrieval interface based on the Archive Engine
图8. 基于Archive Engine的Phoebus检索图
5. 两种归档方案性能对比分析
针对EAST主机诊断数据特点并结合表1中实验结果来看，采用基于Archive Appliance的归档方案相较于采用RDB Archive Engine的归档方案更能满足EAST技术诊断数据的存储需求。
Table 1. Experimental results and comparison
表1. 实验结果及对比
对比维度 |
Archive Appliance (AA) |
Archive Engine (AE) |
单个PV最大采样率 |
1000 Hz |
<1000 Hz |
最大可归档PV数量 |
上万级别 |
上千级别 |
查询方式 |
高效的HTTP REST接口 |
依赖SQL查询 |
查询性能(1 Hz，1天数据) |
<0.5秒 |
1~2秒 |
系统架构 |
模块化、多线程、分布式，可灵活调配CPU、内存和磁盘资源 |
架构简单，缺乏扩展性，存在资源瓶颈 |
适用场景 |
大规模实验装置，需高频采样、大规模并发归档与查询 |
小型实验室或单点部署，归档规模有限 |
6. 总结
本文实现了一个具备软IOC模拟、双归档方案写入、Phoebus客户端展示的完整实验框架，为EAST主机诊断数据归档系统的实际部署提供了基础。未来将尝试接入真实硬件信号，进一步验证系统稳定性与数据一致性。
NOTES
*通讯作者。