FAST 观测管理系统设计与原型实现＊

吴碧羽，朱 明，岳友岭

(1.贵州大学 计算机科学与技术学院，贵州 贵阳 550025;2.中国科学院 国家天文台，北京 100012)

位于贵州省南部喀斯特洼地的500 m 口径球面望远镜(FAST)是“十一五”国家重大科技基础设施项目之一，预计2016 年9 月建成并投入使用。FAST 是具有中国独立自主知识产权以及当今世界口径最大、最灵敏的单天线射电望远镜［1］。FAST的主要科学目标，包括中性氢、脉冲星、分子谱线、VLBI 和地外文明搜索。FAST 作为一个多学科研究平台，将极大地提升我国在天文学和其他基础学科的研究能力［1，2］。

为了控制望远镜进行科学目标的观测，FAST设计了一套望远镜控制系统［3］，它是望远镜能否有效运行的关键。观测用户要顺利地使用望远镜，还需要观测管理系统与控制系统进行配合才能完成观测任务。观测管理系统负责从全部观测中调度一个经过优化的观测序列到控制系统去执行，提高了望远镜的观测效率，且用户通过系统可实时监控整个观测过程。本文提出了基于原型迭代开发的研究方法，开发FAST 观测管理系统。系统设计主要包括业务流程分析、关键数据和功能设计，原型系统实现的服务包括全部观测的集成、观测序列的调度优化和观测过程的监控。

1 FAST 观测管理系统概述

FAST 望远镜主要由4 套子系统组成，包括反射面系统、接收机系统、馈源支撑系统和测量与控制系统。望远镜控制系统框架［3］如图1 所示，总控系统通过向各子系统分发指令、获取设备运行状态，将各子系统有机地组织起来，保证了异构子系统的协调运行。而观测管理系统(Observation Management System，OMS)为用户提供了一个观测接口，它通过总控系统屏蔽了各子系统的异构性。OMS 系统通过向总控发送观测指令、获取状态，来完成用户提交的观测。用户通过系统监视观测任务的执行过程，获取望远镜的运动轨迹、观测数据和各子系统运行状态等实时信息。

图1 FAST 望远镜控制系统框架

OMS 系统的设计须考虑以下几点需求:

(1)系统需设计一个观测规划文件来描述用户的观测内容，并负责将用户级别的观测内容翻译成总控系统识别的观测指令流。

(2)FAST 将来会开放给全世界天文科学家使用［4］，系统应管理和调度所有观测任务，尽量保证所有的观测任务顺利完成。系统还应考虑调度的优化，提高望远镜的观测效率。

(3)由于FAST 能够进行多种科学任务观测，观测模式多种多样，系统应实现基本的观测模式［5］，且观测模式、观测规划文件的设计应能灵活扩展以支持复杂的观测模式。

(4)系统需显示观测过程的各类信息，包括观测指令执行状态、天线运动轨迹、各子系统运行状态、观测数据等。

OMS 系统的开发首先是对复杂需求进行业务流程分析，识别和设计关键数据和功能模块，然后快速开发原型系统，通过迭代开发原型，来不断验证、修改业务流程及关键设计。业务建模可清晰体现OMS 系统所提供的业务和服务，是系统可用性的关键。关键模块的设计和能否适应未来复杂的需求密切相关，是系统可拓展性的关键。用户和原型的直接交互，可评价系统设计是否正确。基于原型验证设计的研发方法，保证获得正确的系统设计，降低未来完整系统开发的风险。

下面对OMS 系统的业务流程分析、关键设计和原型实现及效果进行详细叙述。

2 业务流程分析

为正确提取OMS 系统业务，基于FAST 观测场景的设计来分析系统的业务流程。场景描述了人完成一件事的活动过程。而FAST 观测场景描述了观测用户为完成一个观测任务和OMS 系统的交互过程，体现了系统所提供的服务。基于场景的设计，提供了一种提高软件可用性的有效途径［6］。

2.1 FAST 观测场景

借鉴国内外望远镜的观测流程，将FAST 的观测流程设计为准备观测和执行观测两个场景:

(1)准备观测:观测用户根据FAST 的观测特点，针对提出的科学研究目标，制定详细的观测规划和观测脚本。

(2)执行观测:用户可以从制定的观测脚本中选择一个开始执行观测，也可从系统预选的观测序列中选择一个观测单元。起初，用户会看到接收机和后端等设备的配置结果，天线向目标源方向移动，之后，望远镜按照用户预设的观测模式进行观测并记录数据。观测期间，用户可看到天线运动轨迹、各设备运行状态、观测执行日志和观测数据等实时信息。用户通过这些信息，判断此次观测是否达到预期，必要时可终止观测。

2.2 业务流程分析

OMS 系统业务流程如图2 所示，有业务角色、实体、活动和流程四种元素［7］。用户、总控系统是业务角色;观测单元、观测规划文件等是实体，为系统使用和处理的数据;圆圈代表系统活动，为系统功能。准备观测、动态调度、观测执行和状态显示是系统的四个流程，右侧的三个流程对应了执行观测场景。每个流程，由一组活动和外部接口执行一组活动来操作数据，体现了系统可提供的服务。具体如下:

图2 OMS 系统业务流程

(1)准备观测:用户通过观测规划制定工具，向系统提交观测规划文件，并触发系统解析观测规划文件，即提取对观测调度和望远镜执行相关的信息存入观测单元数据库。

(2)动态调度:用户启动系统，连接调试望远镜，系统展示台址气象信息、各个设备状态信息给用户，信息来自总控系统。系统动态调度并优化一个当前可观测的序列，或者用户搜索特定的观测序列，系统将观测序列结果展示给用户。

(3)执行观测:用户从观测序列中或者观测脚本中选择一个观测，系统开始执行观测，观测翻译负责解析观测内容并形成指令流。然后总控交互模块负责将指令流向总控系统输出，望远镜开始执行指令并产生天线位置轨迹。总控系统实时反馈指令执行情况和天线位置给总控交互模块，然后系统会显示天线位置信息、指令执行状态等观测日志信息。在执行期间，系统会记录错误日志，包括指令错误等，用户可停止观测，同样地，还是通过总控系统控制望远镜停止当前观测。

(4)设备显示:执行期间，总控系统不断反馈各个设备运行状态和观测数据，系统会实时显示和记录设备状态信息和观测数据。

3 关键设计

在实现图2 所有的业务需求过程中，观测规划文件、观测调度策略和观测翻译及指令缓存内容是设计的关键之处，下面对这三块关键设计进行了详细分析。

3.1 观测规划文件

观测规划文件(Science Program，SP)描述了科学研究目标的详细观测内容，主要是要观测的源列表和每个源的观测策略。观测策略描述了源的位置、何时观测、观测条件、观测时间和观测模式等信息，观测条件代表观测调度信息，其余是望远镜执行信息。OMS 系统每次调度若干源进行观测，一次调度的内容叫做最小调度块(Minimum Schedule Block，MSB［4］)，一个源的执行叫做观测(Observation，Obs)。一个MSB 包含若干个Obs，Obs 记录源的执行信息，MSB 记录所有源的调度信息，故一个SP 可用一组MSB 描述。

采用拓展标记语言XML 来标记SP 文档，XML是一种成熟的文档标记语言，可自定义数据标签［8］，且XML 文档是树状结构，树的深度和广度可灵活扩展，这些保证了XML 能标记未来复杂的观测模式。用XML 设计的SP 结构如图3 所示，根结点ScienceProgram 代表整个SP，它包含基本信息和一组MSB。SP 基本信息有:标题、项目优先级、项目负责人、项目编号等。

图3 观测规划文件结构

每个MSB 包含基本信息、台址质量(SiteQuality)和一组Obs。MSB 基本信息有标题、观测次数、剩余次数、优先级等。SiteQuality 描述气象观测条件信息，包含风速、湿度等，调度时要考虑这些因素。每个Obs 记录执行信息，包含标题、观测时间、设备配置、目标源和观测模式。设备配置包括接收机、中频和后端的配置信息。目标源记录源位置信息。观测模式记录天线跟踪源的轨迹信息。用户基于此结构，根据观测特点可定制MSB 与Obs 的个数和内容。

3.2 观测调度策略

由于观测目标位置在天空随时间变化，需定时调度观测序列，为此采用时间片的轮转观测，即每2 h 系统选择一个MSB 进行观测，时间片大小借鉴了国外JCMT 等著名望远镜的经验，MSB 的观测时间等于时间片的长度。每次选择一个最佳MSB 序列是调度策略的关键。为了保证观测质量，系统应调度在中天附近、距离太阳和月亮等强源较远的若干源。为了有效利用观测时间，应尽量调度离上一次观测位置较近的若干源。为保证高优先级科学目标的尽早观测，还应考虑项目优先级。许多观测要求较好的台址气象质量，系统应调度在当前气象下可观测的若干源。

原型系统的调度策略优先考虑了气象质量、项目优先级和中天远近观测条件，主要思路:

(1)把未观测完的项目按优先级递增排序;

(2)找到符合当前气象条件的未观测的MSB序列，并按MSB 的优先级递增排序;

(3)根据Obs 的源位置排除不在FAST 天区的MSB 序列;

(4)按离中天远近进行递增排序，即得到观测序列。

未来完整的OMS 系统应考虑全部调度因素的影响，提出了基于权重法的调度策略，该策略有待完善，主要思路:对每个调度因素赋一个权重wi(0 ＜wi＜1，∑wi=1)，计算每个调度块加权累加值，v=∑wi× vi，其中vi是每个因素的量值，然后按v 递减排序即可得到观测序列，选择v 最大的MSB 进行观测。权重法策略的关键是W 向量的取值，W 可由调度经验丰富的天文专家确定，也可通过FAST 未来的调度轨迹作为训练测试集、反复构建合适的神经网络来训练W 向量，使v 成为一个有效的调度指标。

3.3 观测翻译与指令缓存

为了降低用户编写观测脚本的难度，OMS 系统为用户设计了一组基本观测命令，命令标识符是易懂的英文单词，屏蔽了底层难懂的望远镜机器指令。基本命令包括配置设备configure、跟踪观测track、中星仪式扫描观测transit 和数据记录record。configure 用来配置观测要使用的设备，包括接收机、后端等。track 要求天线跟踪源进行观测。transit 要求观测过程中天线指向固定。track 和transit 是基本观测模式。record 命令用来记录观测数据。为了降低系统和望远镜间的耦合，望远镜连接调试命令也使用用户级命令。

MSB 中Obs 记录了望远镜执行信息，系统需将树状内容翻译成总控系统识别的内容。另外，用户也可使用观测脚本进行观测，为了统一两种不同的观测形式，系统执行MSB 中的Obs 内容时，先将Obs 翻译成观测脚本，然后执行观测脚本，逐行解释命令成总控指令流。比如，总控的基本指令有望远镜指向指令(PX)等，track 命令会根据跟踪模式被解析成一系列PX 指令流。

OMS 系统和总控系统的交互采用基于TCP/IP协议的socket 通信，通信模式是，OMS 系统有指令流就主动向总控发送。而总控一次只执行一条指令，OMS 系统端的指令发送频率过高会导致总控端的指令不可控堆积，产生无法预料的后果。系统应以一定的频率发送指令，并需要一个指令队列缓存所有的解析指令。同一个时刻若干MSB 和调试命令的执行必须串行化，故指令缓存是一个独占资源，同一个时刻，仅有一个MSB 或调试命令在写指令缓存。指令缓存设计如图4 所示。对指令队列添加锁机制以实现数据同步，当执行一个调试命令或MSB 观测时，就产生一个写线程负责解析指令流，获得写锁的线程才可写队列。读指令负责从队列取数据，往总控发指令流。

图4 指令缓存设计

4 原型实现

FAST 和总控系统目前正在建设中，原型将国家天文台4.5m 射电望远镜作为测试平台，并以4.5 m 天线控制器指令集作为总控指令集。原型实现了transit、track 基本观测模式和OMS 系统所有业务。为保证快速开发，原型的实现采用Python语言，它能缩减编码工作量和开发周期。python 是一种“胶水”语言［9］，有很多应用开发包，能很好地支撑原型开发的技术需求。

4.1 架构设计

原型系统采用经典的MVC 架构设计，MVC 是一种表现层设计模式，它将数据显示、控制逻辑、数据处理强制分离，形成了视图(View)、控制器(Controller)、模型(Model)3 个核心层次，提高了软件的可靠性和可扩展性［10］。原型界面是基于事件驱动的，用户点击界面上的按钮，可促发界面更新，MVC 模式恰好能很好地满足这个需求。

原型系统架构如图5 所示。View 实现了和界面有关的内容。结合系统业务流程，原型设计了观测调度界面、观测执行界面和设备状态界面。观测调度界面主要包含MSB 查询等，观测执行界面主要包含望远镜的连接调试等，设备状态界面显示运行参数，比如接收机系统。

View 负责接受用户的输入，响应用户的操作，通过调用相应的Controller 处理用户请求。由Controller 来实现业务逻辑，它解析View 输入的参数、处理业务过程，并从Model 获取或修改数据。Model 层是数据库和外部数据的接口，它提供数据获取和修改方法，返回的数据通过Controller 更新View。基于数据库的安全考虑，Model 中设计了持久化层，防止应用程序直接操纵数据库。外部数据接口有4.5 m 天线控制系统接口和总控系统状态模拟器。天线控制器用来反馈指令执行结果和天线运动轨迹。状态模拟器用来模拟观测过程中各个设备的运行状态，目的是测试OMS 系统业务流程的完整性。

图5 原型系统架构

4.2 运行效果

观测调度界面如图6 所示，它是原型运行时的主界面。左侧显示了望远镜的台址气象条件和当前UTC 和LST 时间，右侧Calibration 区域为系统的校准接口，Notes 区域是用户制定观测规划文件时对MSB 的观测说明。用户在中间的MSB Search Window 输入查询条件搜索指定的MSB。底层Query Result 中显示了系统预先调度或者用户搜索的观测序列，包括观测项目、MSB 和Observation 三个列表，列表内容来自观测规划文件，其中，观测项目用来描述观测规划文件的基本信息。

图6 观测调度界面

目前，OMS 原型系统在4.5 m 望远镜上可长时间正常运行，并正确执行观测任务，得到了天文观测用户的认可。图7 是原型系统控制望远镜扫描银道面得到的连续谱观测数据，扫描时间是一天。图中左侧观测到的最强源是太阳，右侧从上到下观测到的源依次是仙后座A-Cas A、天鹅座XCyg X、天鹅座A-Cyg A、月亮-moon 和银心-GC。

5 总结

图7 银道面观测数据

本文通过观测场景分析了OMS 系统的业务流程，并采用XML、缓存等技术设计了FAST 观测规划文件、观测调度策略和观测翻译与指令缓存三大关键模块。最后采用python 和MVC 架构快速构建了一个原型，原型在4.5 m 望远镜上的长时间运行、观测执行的正确性，充分验证了设计的可行性、正确性，为完整系统的开发提供借鉴。原型若应用在未来FAST 望远镜上，其业务流程、观测调度策略和指令缓存的设计仍需完善。未来将继续改善并扩充设计，使得FAST 望远镜能进行复杂的科学观测研究，提高FAST 的科学产出能力。

［1］南仁东.500 m 球反射面射电望远镜FAST［J］.中国科学G 辑，2005，35(5):449－466.

［2］中国科学院国家天文台，中国科学院基础科学局.中国天文科学大型装置的研制与应用——500 米口径球面射电望远镜(FAST)［J］.中国科学院院刊，2009，24(6):670－673.

［3］邓小超.大型望远镜异构控制系统的研究［D］.合肥:中国科学技术大学，2012.

［4］黄梦林.FAST 观测项目管理系统框架设计［J］.贵州大学学报:自然科学版，2014，31(1):88－91.

［5］钱磊，岳友岭.FAST 基本观测模式［R］.北京:中国科学院国家天文台，2010.

［6］王丹力，华庆一，戴国忠，等.以用户为中心的场景设计方法研究［J］.计算机学报，2005，28(6):1043－1047.

［7］艾萍，施展.业务建模技术综述［J］.计算机应用与软件，2012，29(7):127－132.

［8］潘海兰，吴翠红，葛晓敏，等.XML 及其在MVC 模式中的应用［J］.计算机技术与发展，2010，20(2):202－205.

［9］周伟，宗杰.Python 开发技术详解［M］.北京:机械工业出版社，2009:179－180.

［10］刘宁，陆荣国，缪万胜，等.MVC 体系架构从模式到框架的持续抽象进化［J］.计算机工程，2008，34(4):107－110.