X射线天文学的观测多以空间观测为主，20世纪70年代以来，国外已经陆续发射了多颗X射线天文卫星。中国在2017年7月15日发射了以X射线天体源观测为主的硬X射线调制望远镜卫星^[1]。这些卫星的数据分析软件和观测数据大多是公开的。后续的爱因斯坦探针卫星(Einstein Probe, EP)和中法太空望远镜项目(Space Variable Objects Monitor, SVOM)已经处于工程阶段，增强型X射线时变与偏振天文台(enhanced X-ray Timing and Polarimetry Mission, eXTP)也处于规划阶段。这些X射线天文卫星的发射必将对卫星数据分析方法及软件带来一定的挑战。

作为载荷硬件和科学分析的桥梁，数据分析软件的开发必不可少。数据分析过程是通过观测数据反推入射信息，而观测数据经过仪器的响应，不能直接表征入射信息。数据分析软件的目的是产生正确的能谱、光变以及响应等。在这基础上，用户才能利用这些信息反推天体源的入射信息，进而推断发生的物理过程。总之，数据分析软件与科学产出息息相关，是保障科学产出的必要条件。

卫星发布的分析软件一般是专用于该卫星数据分析的软件，另外还有通用的数据分析软件。通用软件主要针对天文数据格式的处理(ftools^[2])，以及能谱、光变处理(如Xspec和powspec^[3])。美国国家航空航天局(National Aeronautics and Space Administration, NASA)提供的HEAsoft软件包集成了通用软件及一系列卫星的专用软件。这样卫星数据分析软件需要重点设计卫星载荷的数据处理过程，使通用软件能够识别和处理数据处理的结果。本文主要介绍硬X射线调制望远镜卫星数据分析软件的需求、分析过程及底层设计，希望为后续卫星的软件设计和开发提供借鉴。

硬X射线调制望远镜卫星有3个主载荷，分别为高能X射线望远镜^[4]、中能X射线望远镜和低能X射线望远镜，它们均集成了多个单体探测器，且单体之间有差异。卫星下传数据经过地面处理^[5]后分别生成各载荷的文件目录，这些文件包括轨道、姿态、事例、温度、工作状态参数等，数据分析软件是对这些文件进行处理，产生物理结果的软件。本软件主要适用于X射线源的定点观测，这是硬X射线调制望远镜卫星主要的观测模式，部分模块也可以适用于扫描模式，并对短时爆发有一定的处理能力。

1 分析软件的需求

空间天文卫星的数据格式一般是FITS(Flexible Image Transport System)^[6]，分析此格式的数据需要借助通用的分析工具或者自己开发工具。这一特点使得用户分析软件必须给出标准的数据筛选条件，以避免用户对基础数据的分析，而这种基础分析大多基于可视化界面，同时也必须给出符合通用数据分析工具的FITS格式数据，比如能谱格式及关键字定义均需要符合Xspec的调用。

天文数据分析工具已经有几十年的历史，培养了一大批用户。硬X射线调制望远镜卫星数据分析工具开发早期，我们制定了运行需要遵从HEAsoft形式的原则，能够兼容HEAsoft工具的策略。但是需要注意的是，HEAsoft早期一大部分代码是基于Fortran和Perl语言开发的，移植性比较差。随后一些卫星专用软件采用C语言开发，移植性和可读性也比较差。当然，HEAsoft也提供了大量优秀的代码，比如硬X射线调制望远镜卫星分析软件采用了FITS文件读写库cfitsio。

天文分析工具的运行单元称为任务(task)，每个任务的输入及输出如图 1，其输入及输出一般是FITS格式数据，另外还有一个参数文件(pfile)用于程序运行中的参数控制。需要指出的是，任务的运行存在两个问题：(1)任务之间主要采用数据文件相连，频繁地读写FITS文件数据，处理效率大打折扣; (2)参数文件的使用也带来另一个问题，当多个相同进程读取同一参数文件时，可能导致运行出错。集群计算(云计算)情况下，用户不得不设置多个参数文件路径，使得不同进程读取不同的参数文件，然而对于提交同一计算机上的并行程序却无能为力。

X射线天文软件一般运行于Linux或者Mac OS X等操作系统，硬盘及内存使用与数据文件大小和运行中的非线性计算有关，要求不高。编译系统一般可以基于HEAsoft提供的hmake脚本完成。另外，数据分析软件需要与标定数据库(Calibration Database, CALDB)配合使用。标定数据库主要存放与载荷、标定相关的数据文件，分析软件需要建立接口与标定数据库相连。这样，硬X射线调制望远镜卫星需要继承HEAsoft的运行方式，包括数据格式、运行模式等。但是我们也希望改变HEAsoft的一些缺点，比如改变面向过程的编程方式，避免重复读写文件。

2 数据分析流程

卫星下传的数据经过一系列处理，最终以单次观测数据进行组织(观测号)，数据分析的基本单元是观测号，硬X射线调制望远镜卫星发布未标定、未筛选的数据作为数据分析的输入。

数据分析软件一般遵从图 2的分析步骤，整个流程分为3步：(1)数据标定，包括增益修正、噪声扣除和事例重建等; (2)数据筛选，利用工程数据提取载荷正常工作的时间及源观测时间，并扣除地球遮挡时间，然后利用事例等级及提取的好时间对标定的事例数据进行筛选，产生经过标定并筛选后的数据文件; (3)高级产品提取，提取筛选后数据文件中的能道及时间信息，并根据时间、指向等信息产生能谱的响应文件。

硬X射线调制望远镜卫星数据分析过程中还要识别和扣除一部分损坏的像素，对数据进行必要的修正，并计算一些重要的参量，特别是能谱文件中的曝光时间，这是因为能谱拟合中它作为参数用于计算源的流量。

相比其他卫星，硬X射线调制望远镜卫星的3个载荷均采用多单体探测器的集成方案增大接收面积。但是由于制造工艺以及在轨探测器温度的差异，这些探测器往往不能看作全同的。这些差异在数据上主要表现为好时间和增益不同，而后者可以通过增益修正改变。好时间的不同给探测器能谱、响应和光变合并带来麻烦。对于能谱，不同能道上的计数可以直接合并，但是总曝光时间并非是单体曝光的累加，而是按单体的权重累加。比如硬X射线调制望远镜卫星的高能探测器由18个NaI探测器组成，权重因子可以简单设置为1/18，响应也按单体给出，然后各个单体的响应按权重累加。光变需要提供4列：时间(Time)、计数(Counts)、计数误差(Error)和该时间段(Binsize)中的曝光比例(Fracexp)。如果需要做死时间/指向修正，需要先按单体计算，得到修正因子及每个时间段的曝光比例，然后计算单体修正后的计数及误差，最后计数累计，曝光比例按权重合并，误差按误差传递给出。

3 分析软件的设计

硬X射线调制望远镜卫星为天文卫星，数据格式遵从天文数据格式FITS，分析遵从天文数据分析的特点，并可以兼容HEAsoft工具。

硬X射线调制望远镜卫星有3个主要载荷，它们均采集光子事例，观测限制条件比较一致，步骤也基本相同。每个载荷单独开发，整个项目费时费力。如果能够找到它们之间的相同点和不同点，并设计一种架构进行逐层次开发，将有巨大的优势。当然，这3个载荷的不同设计，也决定了数据处理不同，比如中能X射线望远镜和低能X射线望远镜有事例重建，而高能X射线望远镜无需重建。即使是同一载荷，不同单体间的差异也需要考虑。

硬X射线调制望远镜卫星分析软件的架构如图 3。架构是分层设计的，整个软件系统公共的功能放到第一层(公共层，图 3中CommonLIB层)，这些功能包括任务的输入输出控制，CALDB接口，FITS文件的通用操作，坏像素识别类，以及与时间、能谱、光变相关的功能等。后续以载荷进行层次结构划分，越靠后各层逐步考虑模块的具体实现功能(载荷层)，并将本层的公共部分(图 3中Payload及Libs)和特殊部分(图 3中Modules)分开，公共部分包括载荷事例、视场、探测器的定义等，特殊部分包括增益修正、死时间修正等功能类。最后一层或者多层实现软件的流程功能。

架构使用C++语言开发，采用面向对象的编程形式，这是本软件与以前软件开发的不同之一。采用面向对象编程的一个重要考虑是底层算法、类和接口等比较容易被本软件以及其他软件调用。这种设计提高了软件开发的质量，降低了软件开发的工作量。

设计中，我们重点考虑事例流的非线性操作及多单体探测器的处理问题。硬X射线调制望远镜卫星的载荷差异比较大，这使得分析方法迥异，数据处理架构需要解决这个问题。本设计通过对象与流程分开操作的方式解决此问题，特别是将流程放大以满足差异化。设计没有将软件的流程看作类的一部分，而是将流程看作主结构，在流程内对类进行实例化。这样的好处是灵活，即流程可以变化，多个流程可以整合为一个主流程。这对硬X射线调制望远镜卫星3种载荷的差异化及非线性操作非常有利，比如高能载荷在事例流上存在尖峰，软件必须积累一定的数据才能识别并扣除，在接下来的分析中则无需考虑此因素，因此将这部分特殊功能放在某一流程中实现。

图 3中管线工具可以通过调用多个任务完成分析，也可以基于公共层和载荷层直接编写代码实现。用户可以不必关注这种多单体探测结构，而只需关注载荷公共的运行时间即可; 用户可以不使用参数文件，进而避免并行计算存在的问题; 不必将流程分为多个子流程，每个子流程开发为一个工具，仅提供一个主流程即可，这样可以避免频繁读取FITS文件; 用户也无需在编译上依赖HEAsoft，可以开发为独立软件。特别说明的是，这种方法对空间环境、爆发现象的研究特别有利。

另外针对多探测器结构，硬X射线调制望远镜卫星分析软件将各个单体单独处理。硬X射线调制望远镜卫星采用多个好时间扩大描述整个载荷的时间信息。单体分开的处理方案以及时间描述方案会造成处理效率下降，但是这种设计对多单体却是适用的。

软件提供的公共层不仅供硬X射线调制望远镜卫星的3个载荷使用，还可以移植到其他卫星平台，如爱因斯坦探针卫星的后随X射线望远镜(Followed X-ray Telescope, FXT)载荷的数据分析软件直接使用了硬X射线调制望远镜卫星的部分接口及算法。另外软件的设计架构也用于后随X射线望远镜数据分析软件的开发。软件架构的层次性结构立足于全面思考问题，着眼于提高软件开发质量和降低软件工作量，以系统逻辑性代替重复的软件开发，以脑力代替体力。另外，架构也充分考虑载荷的差异性，载荷层突出载荷的特点，而过程层则考虑流程，特别是非线性操作，这种设计可以囊括更多载荷。

4 硬X射线调制望远镜卫星数据分析软件的实现

硬X射线调制望远镜卫星数据分析软件包括高能X射线望远镜、中能X射线望远镜和低能X射线望远镜数据处理软件，每个载荷按分析流程分为标定模块、筛选模块以及提取高级数据产品模块。图 4是硬X射线调制望远镜卫星数据分析软件的各个模块及分析流程。这些模块与天文通用工具ftools的运行方式一致，输入输出均遵从HEAsoft特点。

硬X射线调制望远镜卫星分析软件适用于定点观测，对于爆发数据的分析(主要针对高能X射线望远镜载荷数据)不太适用，如短时间观测，软件因本底难以估计进而将这些时间舍弃。其他一些与观测无关的分析，分析软件几乎无能无力，因为它提供的工具有非常强的目的性，通用性就变差，这也是卫星分析软件存在的共性问题。事实上，数据分析软件不仅仅为用户提供分析卫星数据的工具，还可以基于硬X射线调制望远镜卫星分析软件提供的接口、算法及类等编写自己的程序。硬X射线调制望远镜卫星分析软件提供的库包括：(1)与数据格式相关的类和特定格式文件类，如事例、电压、温度等文件的读写类，能谱、光变类等; (2)与输入输出相关类，如获取运行参数、输出日志信息等; (3)与标定数据库相关类; (4)一些特定的接口类，如死时间、视场、探测器单体描述类等; (5)特定功能类，如对公共文件(轨道、姿态等)操作类，与时间相关类等。这些类基本满足FITS文件的读写，特别是事例文件的读写，以及对事例的过滤，产生高级数据产品等。

硬X射线调制望远镜卫星分析软件还提供了各个载荷的管线处理模块，这些模块不是简单地将各个任务串联执行，而是大量调用软件架构提供的接口、算法及功能类，使用一个流程将标定、筛选及提取高级数据产品整合。如获取一个光子事例，增益修正后，判断光子信息是否符合所选择的条件，如果符合则记录光子的时间及能道信息，最后分别产生光变及能谱等。这种设计将多个流程整合为一个流程，避免任务之间频繁地读写FITS数据。用户可以借鉴此种方案开发程序，同时摆脱对参数文件的依赖。

5 总结

空间X射线天文卫星的数据分析软件设计大多参考HEAsoft软件包，并在能谱、时变分析上基于HEAsoft提供的通用分析工具进行数据分析。用户习惯了这种软件的运行方式及数据处理方式。天文卫星一般采用FITS数据格式，多数通用软件也以FITS格式为主。这使得卫星专用的数据分析软件需要遵从天文数据格式，遵从天文数据分析的特点，并可以兼容HEAsoft。硬X射线调制望远镜卫星数据分析软件同样遵循这种设计，使用时，本软件提供的工具与HEAsoft提供的工具在运行方式上并无差别，与多数专用卫星的流程保持一致。

但是硬X射线调制望远镜卫星的设计有独特之处，底层软件架构采用层次化结构。公共层提供的基础库可以为3个载荷服务，载荷层针对公共和专用部分的数据处理，过程层主要完成数据处理的流程。特别说明的是，硬X射线调制望远镜卫星提供的公共层也可以应用于其他卫星的软件开发。该架构采用面向对象的设计语言C++开发，有优良的扩展性和继承性。硬X射线调制望远镜卫星数据分析软件不仅提供了一系列工具用于数据分析，还提供了一套底层库供用户开发更高效的程序代码。总之，采用面向对象的设计模式，不同卫星间公共层的移植性以及接口、算法和类的可调用性是硬X射线调制望远镜卫星分析软件设计的亮点，相比较而言，HEAsoft采用面向过程的设计模式和语言，底层库难以调用，用户多以直接调用工具(ftools)为主。

目前硬X射线调制望远镜卫星数据分析软件已经得到国内外用户的广泛使用，其代码及使用说明可以通过官网(http://hxmtweb.ihep.ac.cn/software.jhtml)获得。用户基于此已经发布大量文章(https://ui.adsabs.harvard.edu/public-libraries/R_dGKc_6RSyswz9mVTsUuA)。架构及部分公共接口也已经用于爱因斯坦探针卫星的后随X射线望远镜数据软件开发，效果比较理想。