2. 中国科学院大学,北京 100049
2. University of Chinese Academy of Sciences, Beijing 100049, China
中法天文卫星(Space multi-band Variable Object Monitor,SVOM)项目将用于伽玛暴(Gamma-ray Burst,GRB)探测及余辉观测，对伽玛暴的研究涉及从恒星、星系到宇宙学等天体物理学中的多个领域，对解决相关天体物理学领域中的若干重大问题具有重要意义。
地面系统是中法天文卫星项目不可缺少的组成部分，用以完成卫星平台和载荷的科学运行规划、伽玛暴观测、计划编排、平台和载荷数据的处理以及各级科学数据产品的产生、备份和交付等任务。中法天文卫星地面系统的中方科学中心负责科学观测任务的规划、中方载荷的科学数据处理与产品生成等任务。
作为中方科学中心的一部分，中法天文卫星数据档案库(SVOM Science-data Archive,SSA)是中方载荷观测数据在科学中心共享与处理的技术基础与运行基础，是科学数据处理和高级科学数据产品生成的基本保障。中法天文卫星数据档案库支持对各类、各级别、各版本的中法天文卫星科学数据、工程数据、标定数据、辅助数据等的整编、转存和管理，保证数据的安全性与完整性，提供统一的数据存取管理平台，实现空间科学数据的统一归档、检索、提取、维护、分析与安全控制等功能。
中法天文卫星中方科学中心需满足对多个数据源(VHF数据、VT科学数据、GRM科学数据、GOS观测数据)的处理，需要地协同快速反应，为保障系统的可靠性，中法天文卫星中方科学中心将采取迭代开发的方式，与星上部分协同实现，包括不同版本的仿真模拟数据、载荷单机测试数据、载荷定标数据、载荷数据处理算法、高级数据产品等等。这都对中法天文卫星数据档案库的功能实现提出挑战。由于项目进行中数据的定义、中方科学中心其它组成部分将不断演化，档案库系统需要具有开放性、低耦合的特点。
由于中法天文卫星地面系统项目尚未正式展开，正处于预研阶段，建立了中法天文卫星数据档案库的原型系统，在初步分析未来完整中法天文卫星数据档案库需求的基础上，选择需要尽快攻关的技术方面，裁剪需求，以研究系统架构和技术探索为目的做好前期准备。本文第2节分析了中法天文卫星数据档案库的功能和性能需求，第3节设计了其基本组成，并实现了原型系统，第4节进行了本地运行验证，演示了设计的可行性，为未来完整的实际系统的实现确定了技术路线。
2 需求分析 2.1 概述
虽然数据档案库的目标是对中方科学数据产品的本地长期存储和管理，但为帮助用户理解整个系统的工作流程，以下简要介绍中法天文卫星数据从产生到存储的过程，以明确中法天文卫星数据档案库在整个系统中的位置和功能。如图 1，卫星产生的数据经过任务中心处理后成为L0级数据，再进入中方科学中心，由数据处理系统(Data Processing System,DP)处理后生成L1到L3级数据，最后放入数据档案库进行归档存储。数据处理系统从数据档案库获取数据进行多次数据再处理，用户从数据档案库获得各级数据产品。
|
| 图 1 中法天文卫星数据流图 Fig. 1 A flowchart of the SVOM mission |
由于资源和时间约束，原型系统的主要目的是概念验证，探索系统的基本操作流程，以及满足灵活可扩展等重要需求，而对于数据存储量等性能要求相对较低。
2.2 数据产品结构和数据量档案库中所定义的 “标准观测数据产品” 是以某次观测为单元的所有数据产品，包含辅助数据、定标数据、勤务数据、警报数据和各级科学数据。对同一天体源的各级科学产品包含 “轨数据” 和 “段数据”，段数据包含红蓝波段数据，档案库存储的标准数据产品结构如图 2，以下简称 “标准观测数据产品” 为 “观测” 或 “观测产品数据”。中法天文卫星观测数据产品包含相互关联的各级数据和定标数据，所以在数据产品入库和调出时必须保留数据对象的内部关联信息。
|
| 图 2 标准观测数据产品结构图 Fig. 2 The standard structure of an observational data product of the SVOM |
档案库存储的科学数据为0、1、2、3级数据产品。档案库需要存储卫星在设计寿命(3年)中产生的数据，分级如下：0级数据是卫星生成的X-Band数据；1级数据是在0级数据基础上，对仪器数据进行重建、分类、注解之后而形成的数据；2级数据是在对1级数据进行定标处理、去除仪器效应后形成的数据，并将精度由16位扩展到32位；3级数据是对2级数据进行分析与处理后得到的高层科学数据产品。考虑到今后科学需求、数据处理方法变更等不可预计因素、中间结果存储，存储数据总量估算需保留20%余量蔡洪波,SVOM科学应用中心数据分级及数据存储量估算V4.0。
原型系统只对可见光望远镜(VT)15天内生成的数据进行模拟和验证。按照卫星每轨(90 min)进行一次观测，有一半的时间能观测到源，每次曝光时间为100 s，以红蓝两个波段拍摄图像进行估算，在15天内可见光望远镜共产生4.6万张图。每张图的大小为32 MB，则原型系统的总数据量为1 026 GB。
以下章节除特别说明是 “正式档案库”，中法天文卫星数据档案库专指本原型系统。
2.3 用户角色和需求数据档案库涉及的用户角色包括科学家用户、数据处理系统和数据库管理员等几类。用户角色的需求分别为： (1)非注册科学家用户：查询、浏览各级各类的数据产品。
(2)注册科学家用户：注册登录、查询、浏览和下载数据产品。
(3)数据处理系统：将处理的数据产品放入观测产品数据归档存储；从档案库获取观测数据产品进行再处理。
(4)数据库管理员：对档案库进行升级和维护。
2.4 系统功能需求数据档案库原型系统需要提供的功能主要如下：
(1)数据产品入库：系统归档存储由数据处理系统处理过的数据产品文件。
(2)观测数据查询：系统根据用户给出的查找条件，检查合法性后对库内数据进行匹配查找。查找条件包括观测ID、赤道坐标、观测仪器、观测时间和观测目标名称等。
(3)细化查询：系统提供在第一次查询结果中再次筛选的功能。
(4)查询结果展示：系统将查询结果的基本信息展示给用户。
(5)购物车：系统提供购物车功能，使用户暂存和批量处理查询结果。
(6)下载和发送观测数据：系统提供将观测数据产品下载到用户计算机和发送到用户计算机上安装的数据处理系统的功能。
(7)用户管理系统：系统还需提供统一的用户管理功能，包括用户注册、登录、登出和重置密码。
(8)系统管理：系统提供数据备份和升级的功能。
2.5 系统非功能需求和性能需求未来正式数据档案库系统的各个子系统或模块需要部署到中法天文卫星中方科学中心数据档案库服务器上，另一部分需要部署到如前所述相关角色用户的个人计算机上。由于各类用户角色使用的计算机平台和操作系统均不确定，系统需要满足跨平台的要求。作为在中方科学中心研发早期就要投入使用的原型系统，本系统需要满足不断变化的数据产品结构，因此架构和开发方法都应该考虑后续可扩展的需求。
系统的性能需求有以下两点：一是存储4.6万张图(1 026 GB数据)；二是按照系统设计添加索引，在内存4 G，中央处理器双核2.5 GHz，安装Windows8操作系统的测试计算机上对观测ID关键字的查询操作的响应时间应小于1秒。
3 系统设计与实现 3.1 体系架构和开发策略本系统采用三层客户端/服务器模式(3-Tier Client-Server3-Tier C/S)实现。
传统的二层C/S体系结构是指将系统分为服务器和客户端两层。而三层体系结构，指的是在二层C/S模式的基础上添加一个“中间层”。中间层位于客户端和服务器之间，是一个用应用程序编程接口(Application Programming Interface,API)定义的软件层，具有强大的通讯能力和良好的可扩展性的分布式软件管理框架。三层C/S结构将应用功能分为表示层、功能层和数据层三部分[1]。其中表示层使用各种控件构造友好的用户界面；功能层封装所有的业务逻辑，包括事物处理和对数据库的访问操作等内容；数据层即数据库，负责数据存储。系统中将上述三层加载到硬件的方法如图 3。
|
| 图 3 3层C/S系统硬件结构图 Fig. 3 Illustration of the structure of the hardware system of the 3-Tier C/S architecture |
采用客户端/服务器模式的主要原因是它分离了服务器与客户端功能，前端的客户端可以呈现精细的用户界面，后端的服务器专注于数据的执行处理，系统高效、具有弹性。三层C/S结构在功能上进行了明确的分割，在逻辑上独立清晰，使得系统结构易于变更，能以比较小的代价增加客户端终端或转换为B/S结构；与传统的二层C/S结构相比，客户端与服务器的链接仅仅是简单的通讯协议，与数据库的交互均由服务器来完成，避免了客户端与数据库的直接相连，既减轻了客户端的负担，又降低了数据库与客户端相连的代价，提高了系统运行的效率；当数据访问逻辑发生变化时，仅需要修改中间层的程序，客户端的应用不必更新，大大减小了系统的维护代价。虽然三层C/S结构会造成软件架构纵向的复杂化和系统性能的降低，但对于数据档案库，牺牲部分性能来换取灵活性和易维护性，进而满足系统开放性和低耦合的需求是可以接受的。
选择JAVA语言开发整个系统，使用Eclipse Kepler Service Release2作为开发环境。客户端需要部署在用户计算机上的桌面程序，采用J2SE开发，在未来正式系统中还需要添加在手机等移动设备上使用的客户端，开发这部分客户端将采用J2ME，为了兼容J2SE和J2ME，服务器端使用J2EE框架。
系统采用JAVA而不是运行效率更高的C语言，和中法天文卫星科学中心软件系统采用的主要开发语言保持一致，有多方面的原因。空间天文科学应用软件系统的生命周期在10年量级，JAVA的跨平台特点使软件系统不受硬件系统变迁的影响，跨平台特性还有利于使用同样的基础代码开发移动端软件。再有，随着硬件的速度提高，现在存在的多数软件速度问题在几年后的部署阶段都可以得到解决。最后，运行速度的细致要求实际要在运行演练阶段才能确定，目标系统在项目研制后期可以根据实际需要局部优化。综上，科学中心研制是个系统工程，采用JAVA语言是考虑多种因素综合做出的决定，欧洲空间局的Herschel、GAIA等空间天文项目都采用JAVA编写应用系统也是出于这个原因Herschel Common Science System Software Project Management Plan FIRST/FSC/DOC/0116 v1.0。
3.2 系统组成和功能系统主要分为数据档案库服务器和客户端两部分，服务器和客户端使用超文本传输协议(HyperText Transfer Protocol,HTTP)通信。
服务器分为存储和功能两层，使用数据库和文件系统共同存储观测数据产品，并提供数据访问和数据产品入库接口；客户端即表示层，通过与功能层交互实现对数据库的访问，使用简单应用通讯协议 (Simple Application Messaging Protocol,SAMP)与数据处理系统交互。系统架构和外部交互关系如图 4。
|
| 图 4 中法天文卫星数据档案库系统结构及交互示意图 Fig. 4 A block diagram illustrating the architecture and interactions between different systems/tiers in the SSA |
下面分别介绍数据存储子系统、服务器接口子系统和客户端子系统的设计与实现。
> 3.3 数据存储子系统根据数据处理系统的数据产品结构说明文档进行数据存储方案设计齐晓峰,空间天文有效载荷数据处理基础系统数据产品结构说明文档V0.3。
3.3.1 确定存储方案检索访问是档案库运行最频繁的功能，保证检索访问的速度是档案库的基本需求，因此，选取了两种方案的查询速度进行测试并选择，一是相对成熟的赫歇尔数据访问层(Herschel Product Access Layer,PAL)[2] ，另一个是关系型数据库(PostgreSQL)附加文件系统。在赫歇尔项目中的应用显示，虽然面向对象数据库(Object-Oriented Database,OODB)能更好地适合面向对象开发，但是由于面向对象数据库的使用不如关系型数据库(Relational Database Management System,RDBMS)广泛，从长期来看，维护的人员成本、开发成本、技术风险方面面临巨大的压力，所以本原型只考虑了关系型数据库。
测试方案和结果如下。按照正式档案库系统存储数据条目上限，在测试计算机上使用两种存储方案构建模拟存储，并分别使用所有数据(select all from db)和单个关键字(select id=1 from db)进行检索，消耗的时间如表 1。从表中可以看出，数据库加文件系统的存储方案的表现要远远好于赫歇尔数据访问层方案。出于中法天文卫星项目对伽玛暴反应速度需求的考虑，选择关系型数据库(PostgreSQL)加文件系统存储方案。下面详细介绍这种存储方案。
| 查询条件 | 所有数据 | 观测ID |
| PAL Pool | 10.79s ± 0.35 | 69.02s ± 11.30 |
| PostgreSQL | 0.345s ± 0.153 | 0.012s ± 0.001s |
为了保证检索访问的速度，使用数据库表存储数据产品的元数据和观测组织信息；同时为了方便数据下载，采用文件系统存储观测数据产品。用户对于档案库数据的查询、浏览操作主要通过访问数据库表实现，而涉及数据产品本身的下载发送操作则需要通过对数据库表和文件系统联合操作完成。欧洲空间天文中心的天文卫星数据库也是采用这种存储结构。
文件系统中的数据产品存储采取树型结构，主要数据产品使用FITS(Flexible Image Transport System)格式存储，也还有其他的文件格式如XML(Extensible Markup Language)等。将逻辑上相对独立的数据产品存入单独的FITS文件中，比如层级数据、轨数据和段数据。这样做的好处是主要的文件产品易于用天文数据处理软件查看和处理，同时可以保留复杂观测数据对象的内部关联信息。使用唯一引用标识(Unique Reference Number,URN)区分数据产品，同时保留复杂数据对象的内部关联信息。
3.3.2 数据表 图 5是系统各数据产品的实体-关系图(Entity-Relationship,E-R)。由于篇幅的关系，图中省略了各数据产品的属性信息，主要展示各数据产品间的关系。
|
| 图 5 数据产品实体-关系图 Fig. 5 An E-R diagram of SVOM products |
首先按照实体-关系图将各实体和关系转换为相应的数据表：观测数据产品表、层级数据产品表、轨数据产品表、段数据产品表、红蓝波段和勤务数据产品表。此外还建立了用户信息管理表以及用于映射数据产品存储路径和数据库中存储的存储映射表。由于每个数据产品的引用标识都是唯一的，除用户信息表外，使用唯一引用标识作为所有数据表的主键(Primary key)；用户信息表的主键为用户邮箱。数据库中部分表的设计方案如表 2。
| 数据表名 | 库内定义名 | 存储信息 | 功能 |
| 观测数据产品表 | Observation_Product | 标准观测产品的所有元数据信息、URN和该观测产品包含层级数据产品的URN | 搜索和组织观测数据产品 |
| 层级数据产品表 | Level_Product | 层级数据产品的URN和其中含有的轨数据产品URN | 组织层级数据产品 |
| 轨数据产品表 | Orbit_Product | 轨数据产品的URN和其中含有的段数据产品URN | 组织轨数据产品 |
| 段数据产品表 | Segment_Product | 段产品的URN和其中包含的勤务数据、红蓝两个波段产品的URN | 组织段数据产品 |
| 存储映射表 | Urn_Dir_Maps | 所有数据产品的URN和文件系统路径 | URN与文件存储路径的映射 |
| 用户信息表 | User_Info | 注册用户的基本信息 | 用户管理 |
观测产品文件按照类型分类存储在文件系统中。文件系统目录包含XML格式的观测描述数据(Product Description)、GRB警报数据(Alert)、定标和标定数据(Calibration)、辅助数据(Auxiliary)和数据产品的负荷数据(Payload)子目录，各自存储不同类型的文件。为了提高访问速度也为了方便计数，各个数据类型子目录下还有一层子目录，每个子目录下存放100个文件。文件系统的物理结构如图 6。
|
| 图 6 文件系统存储结构图 Fig. 6 Illustration of the structure of the file system for data storage |
系统使用Tomcat作为网络应用服务器。
3.4.1 客户端可调用接口服务器为客户端提供的接口包括查询、下载、发送、注册、登录和密码重置。
图 7描述了客户端调用服务器接口的工作流程。如图所示，客户端向服务器端输入信息，根据需要进行的操作类型(如查询、用户登录、注册等)调用相应的服务器接口，获得服务器输出后将运行结果展示给用户。
|
| 图 7 服务器接口调用流程图 Fig. 7 A flowchart showing interface invocation of the server |
每个服务器接口由一个或几个小服务程序类实现。类中封装了接口的参数、操作和输出。系统通过在Tomcat上运行小服务程序的方式响应客户端的一般请求：在客户端通过HTTP协议发出请求后，服务器检查对应小服务程序的状态，将其加载并执行相应的过程作业，最后将执行结果的应答发送给客户端。使用在Tomcat上运行Servlet + JSP的方法实现重置密码功能：在客户端发出重置密码的请求后，服务器上的JSP引擎将JSP文件转换为小服务程序代码源文件，然后调用编译器进行编译，最后装载运行。表 3描述了服务器提供给客户端的各个接口。
| 接口功能 | 类名称 | 功能 | 参数 | 输出 |
| 查询 | QueryProductAction | 查询档案库内数据 | sql查询语句 | 查询结果文本 |
| 下载 | GetObsAction | 将观测移动到ftp下载区，生成ftp链接 | 下载观测的id，用户名，压缩格式 | ftp临时下载链接 |
| TmpProductDeleteAction | 删除ftp临时下载文件，在下载结束后调用 | 用户名 | 无 | |
| 发送 | VotableGenerateAction | 生成描述发送观测信息的xml文档 | 观测id，用户名，压缩类型 | xml文件的url |
| 用户管理 | UserManageAction | 处理登录和注册、找回密码请求 | 操作请求及相应用户信息 | 操作请求及相应用户信息 |
数据产品入库是服务器提供给数据处理系统的接口。该接口的数据源是经过数据处理系统流水线处理过的观测数据产品，包括level0、level1、level2、level3级科学数据和辅助数据、定标数据、警报数据、勤务数据。数据处理系统生成的某个观测的数据产品文件位于同一文件目录下，并包含描述数据产品结构的XML文件。
数据产品入库流程为：数据处理系统首先将观测数据产品上传到服务器，此后服务器解析数据产品结构XML文件，获得观测数据产品间的内部结构关联信息；同时遍历观测数据目录，对于每一个数据产品文件，读取元数据信息，和内部结构关联信息一起写入数据库表中，并根据数据产品类型将其归档到档案库文件系统中相应的数据类型目录下。
3.5 客户端子系统客户端子系统分为用户界面和功能逻辑两部分。用户界面采用JAVA SWING类库实现。按照职能划分，功能逻辑分为观测查询与展示、观测下载与发送和用户管理3个模块。以下介绍各个模块的设计与实现。
3.5.1 观测查询与展示观测查询分为基本查询和细致查询。基本查询是按照用户输入的查询条件进行查询，查询条件包括观测ID、观测ID列表、赤道坐标、仪器、观测时长和观测目标名称等。客户端获得用户输入后，使用正则表达式进行可靠性验证，如输入不符合规范，客户端给出用户提示信息并要求用户重新输入；如输入全部符合规范，客户端将所有的输入条件合成一条信息，向服务器发送查询请求。细致查询是用户对基本查询的结果进一步筛选的过程。
观测展示是指将查询到的结果呈现给用户，展示其基本信息如观测ID、赤经赤纬坐标、仪器和观测模式等。购物车也是观测展示的一部分，方便用户批量处理查询结果。客户端解析服务器发回的查询结果信息，以临时链表的形式维护管理。
3.5.2 观测下载与发送观测下载是指将服务器端的观测数据产品下载到用户本地。用户进行下载操作时，客户端整合各项参数信息向服务器发送下载请求，获得文件传输协议(File Transfer Protocol,FTP)下载链接；随后建立FTP链接，传输数据产品直至下载结束。
观测发送指的是客户端将服务器端的观测数据产品发送到本地安装的数据处理系统的过程，为了实现这项功能，客户端需要和数据处理系统通讯。客户端获取服务器生成的包含观测描述(VOTable格式)[3]的统一资源定位符(Uniform Resource Locator,URL)链接后，将其通过简单应用通讯协议[4]发送到数据处理系统；数据处理系统接收到简单应用通讯协议消息后自行与服务器连接并完成观测数据产品的下载。
3.5.3 用户管理用户管理包括登录登出、新用户注册和重置密码。客户端获得用户输入的各项信息，进行可靠性验证后，与服务器通讯完成操作，给出用户操作结果提示信息。客户端记录登录状态并显示。重置密码操作需要使用邮箱和浏览器完成，客户端向服务器发出密码重置请求后，用户的注册邮箱中将收到包含重置密码链接的邮件，用户需使用浏览器打开链接继续完成重置操作。
4 应用验证实现了一个能够运行的中法天文卫星档案库原型系统，并在本地搭建各项环境进行应用验证。测试环境包括Tomcat7.0服务器，中法天文卫星科学数据处理系统1.2版，PostgreSQL数据库9.0和通过网络访问的中法天文卫星中方载荷仿真器。完成了从仿真器生成数据，经过数据处理系统处理后存入档案库的过程，并测试了档案库的查询、下载和用户管理等功能，演示了中法天文卫星数据档案库的基本功能和工作流程，验证了设计方案的可行性。设计、完成的系统存储空间为1.5 TB，能够满足系统数据量的需求。在数据处理系统的基础系统投入运行后，将通过与中法天文卫星中方载荷仿真器、科学数据处理系统的对接。图 8~图 10为部分测试截图。
|
| 图 8 客户端查询界面 Fig. 8 A screenshot of the SSA client query interface (,the main client GUI; it contains the query panel and the user management panel) 图 8注：客户端主界面，包括查询界面和用户管理界面。上方是查询区，获得各查询条件的用户输入；下方是用户管理区，它出现在所有界面的底部以便于用户登录登出。主界面自上而下分别为：主查询面板、位置查询面板、仪器查询面板、时间查询面板和用户管理面板 |
|
| 图 9 客户端查询展示界面 Fig. 9 A screenshot of results of SSA client query 图 9注：图中展示的是对档案库 “id=002” 条件的查询结果，如图所示，由于档案库支持模糊查询，因此所有观测ID中包含002的观测都被查到了。查询界面中还包含对选择观测的下载、发送和加入购物车功能 |
|
| 图 10 客户端登录界面 Fig. 10 A screenshot of the SSA client login interface |
完成了一套中法天文卫星数据档案库原型系统，重点进行了需求分析、系统设计并实现了可运行的原型系统。原型系统的主要目的是概念验证，在系统架构和技术探索方面做好前期准备，为将来的正式系统探明技术路线。
中法天文卫星中方科学中心将采取迭代开发的方式，与星上部分协同实现，所以在项目早期就要将部分功能开发完成，以参与星上部分的研制与测试，数据产品的构成和内部格式随着卫星载荷的研制变化。为满足这个原型系统开放性和低耦合的需求，采用三层C/S系统结构作为系统架构，为将来进一步开发预留演进空间。
目前系统的本地开发工作已经基本结束，也通过了本地的应用验证。当前系统还存在鲁棒性不强，数据处理系统支持不完善的问题，将在接下来的工作中改进。下一步工作的主要内容是将原型系统服务器端部分部署到科学中心基础系统服务器上，并提供客户端供软件开发团队和科学家团队测试使用。
致谢：衷心感谢在成文过程中国家天文台信息与计算中心谌悦老师的指导。
| [1] | 梁树军, 程静, 李黄琦. 三层C/S结构的研究与应用[J]. 电脑开发与应用, 2005(2): 48-49+52. Liang Shujun, Cheng Jing, Li Huangqi. Research and application of 3-tier structure[J]. Computer Development & Applications, 2005(2): 48-49+52. |
| [2] | Li B, Liu D, Guest S, et al. Using Product Access Layer to hide the complexity of data storage from Herschel users[DB/OL]. 2012 [2014-9-21]. http://www.spaceops2012.org/proceedings/documents/id1291321-paper-003.pdf. |
| [3] | Ochsenbein F, Williams R, Davenhall C, et al. VOTable formate defination version 1.3 [DB/OL]. 2002[2014-09-21]. http://www.ivoa.net/documents/VOTable/. |
| [4] | Taylor M, Boch T, Fitzpatrick M, et al. Simple application message protocol version 1.3[DB/OL]. 2012[2014-09-21]. http://www.ivoa.net/documents/SAMP/. |