ASCOM在选址望远镜远程控制中的可用性研究*

彭亚杰，季凯帆，梁 波，邓 辉，王 锋，刘立勇，姚永强

(1. 昆明理工大学云南省计算机技术应用重点实验室，云南 昆明 650500；2. 中国科学院国家天文台，北京 100012)

1 研究背景

根据现代地面光学/红外天文观测的要求，下一代天文站点一定是建立在晴夜多、大气宁静度好、气候干燥、城市干扰少的地点。这样基本上就是在海拔高、人烟稀少的荒凉高山或者高原地区。在我国境内，可能的候选点多数是在西藏、新疆或者云南的偏远地区。

天文台址的确定需要一个长期监测的过程。评价中国天文台址条件需要通过大量观测资料的积累分析，并与国际优秀台站进行比较，从而判定新的台址是否适合下一代大型望远镜的建设。在天文选址中面临的最大问题是野外候选站点条件太过偏僻和艰苦，如西藏阿里地区狮泉河南站候选点，虽然有最基本交通和通讯条件，但没有其他基础支撑设施，5 100 m的海拔以及恶劣的环境条件不适合选址工作人员长期工作和居住。但由于目前主要选址设备仍未脱离现场人工观测的方式，反而要求人员昼夜观测、长期留守、连续监测各种天文条件。这种矛盾极大地影响了观测数据的连续性和持久性，从而迫切需要对选址设备进行远程控制和状态监测。

选址仪器中最重要的是大气湍流测量仪器，例如DIMM、MASS、SCIDAR等[1]。这些设备都是基于几十厘米的小型商用望远镜作观测平台，在国际上，相关的选址仪器已经实现了自动化观测。比较著名的有CTIO天文台研制的设备，它从2000年开始投入使用，基本配置是Meade LX200 10″望远镜和ST5C SBIG CCD[2]。La Palma天文台2003年研制了一台基于Meade 12″望远镜的类似RoboDIMM[3]。2004年西班牙Calar Alto天文台研制了另外一种DIMM，使用Celestron的望远镜[4]作为基本平台。我国西部选址也使用Meade 系列地平式望远镜和Astro-Physics 赤道式望远镜等，但选址小望远镜的远程控制却一直没有进入实用化阶段。

国内选址望远镜远程控制所面临的困难主要体现在三个方面：一是在野外选址的初期，必须进行大量的人为的实时或者准实时的交互式控制、监测和修正及数据采集,难以实现完全通过软件脚本控制望远镜并切换各种观测模式的自主观测方式；二是选址站点都在野外，远离现有天文台或者其他基地。虽然站点具备一定的通讯条件，比如有线或者无线电话，但都不具备宽带网络条件，同时网络状态也非常不稳定，因此通常的基于宽带网络的远程桌面或者VNC等直接控制远端计算机屏幕操作的方式并不适用。网络带宽的限制成为系统实现的一个瓶颈；三是选址望远镜是通过一个串口和本地计算机相连接，并根据厂家制定的串口通讯协议进行望远镜的控制。望远镜后端的CCD也是通过USB或者串口和主机相连接，但通讯协议也是自定义的，没有通用的标准。这种设备的多样性也限制了系统的设计和实现。

本文针对这些问题，从观测模式的多样性、网络带宽有限性和设备控制通用性出发，使用标准化的ASCOM平台实现了小望远镜的远程控制系统原型。通过在有线电话拨号窄带网络上进行的实验，验证了利用ASCOM技术实现远程控制系统以及快速部署的技术路线的可行性，为实用化的设计打下了基础。

2 ASCOM介绍

在ASCOM出现以前，天文仪器控制有两种形式：一种是单一模式构架，另一种是可扩展构架。在单一模式下，所有的设备控制代码都集中在一个软件包中，也就是一套独立的系统。当有新的仪器出现时，几乎要重写软件才能控制仪器。当设备控制中出现问题时，也需要更新整个软件包。在这种构架下，仪器设备和控制软件之间是一对一的关系，这给新仪器的应用和新软件的开发带来了很多不便。可扩展的构架相比单一模式有了很大的进步，它在天文设备和软件之间加入了插件层，从而使得控制软件可以共享设备的代码。对于新的仪器，只需要开发相应的设备控制插件就可以控制仪器。当设备的控制中出现问题时，也只需要更新插件，而不需要将所有程序进行更新。这种构架下，仪器与软件之间是一对多的关系。

1998年初Bob Denny提出了ASCOM的概念并开发了相应的软件平台[5]。经过十多年的努力，ASCOM已经升级到了6.0版本。ASCOM在设备与软件之间引入了驱动层，一方面任何控制程序都可以通过ASCOM调用各种设备的驱动，另一方面对于新设备，只要增加相应的设备驱动就可以添加到ASCOM平台上供控制程序调用。ASCOM构架下控制软件与设备是多对多的关系。

ASCOM提供的设备驱动采用了微软公司组件对象模型(Component Object Model, COM)。组件对象模型工作在Windows操作系统下，它的应用程序编程接口(Application Programming Interface, API)由一套标准的符合相关ASCOM接口规范定义的属性和方法组成，有着固定的函数名称、访问参数和参数数据类型。由于ASCOM采用了组件对象模型，而组件对象模型支持多种开发语言、脚本语言和脚本工具的调用，使得ASCOM也可以支持多种语言的开发。从硬件上讲，虽然各种设备利用串行接口连接到计算机上，但控制软件并不直接和串口打交道，而是通过ASCOM调用设备驱动来操作设备。一方面，设备厂商只要提供符合ASCOM标准的驱动程序，就可以将自己的设备挂接到ASCOM平台；另一方面控制软件也只需要针对ASCOM进行操作，无需考虑不同厂家不同类型设备的特殊性。这样无论更新控制软件还是设备驱动，都是非常容易的事情。因此ASCOM具有开发语言独立性和设备厂商独立性两大特色。

随着ASCOM的发展，目前ASCOM支持包括望远镜(赤道仪)、CCD、圆顶、调焦、滤光片等主要天文设备，有非常多的天文设备厂商支持这一平台，也有越来越多的小型望远镜观测系统使用ASCOM。

3 望远镜控制系统原型设计

实现了一个基于ASCOM的选址望远镜远程控制系统原型，所用的开发环境为Windows.Net Framework 4.0，开发语言为C#，开发平台是Microsoft Visual Studio 2010，开发过程中测试所用的设备为ASCOM设备模拟器。

考虑到野外选址站点窄带网络的制约，采用了客户端-服务端结构，同时基于传输控制协议(Transmission Control Protocol, TCP)的ASCII命令(即ASCII Over TCP)进行通讯，使得一条命令对带宽的占用达到最小。客户端有两种形式，通过telnet的命令行和通过客户端界面控制，他们向服务端发送的命令是相同的。所有命令都由两部分组成，第一部分是命令类型，第二部分是命令的若干个参数，命令类型和各个参数之间用“|”分隔，具体的协议见表1。

表1 自定义的协议表

服务端与客户端的流程图如图1和图2。

图1 服务端流程图

Fig.1 Flowchart of the software at the Service End

服务端包括4个主要流程：

(1)选择设备：通过调用DriverHelper. Chooser对象选择可以远程控制的设备，并通过Choose()方法获得设备的ProgID。

(2)启动侦听并建立客户端连接：触发服务器的侦听事件，开启服务端的一个端口作为侦听端口。当接收到客户端发来连接请求时，记录客户端的IP地址、端口等客户端信息，并创建一个新的线程。

(3)响应请求：当侦听到客户端发来的数据后，对收到的数据进行分析。按照表1的协议形式，通过Split()函数解析由“|”字符拼接的命令与参数。

(4)操作设备：通过调用ASCOM的驱动中的标准应用程序编程接口，对设备进行操作。

图2 客户端流程图

Fig.2 Flowchart of the Client End

客户端也包括4个流程：

(1)连接服务器: 开启客户端后，向服务端发起连接。当服务端收到信息后，就可以通过传输控制协议建立连接。

(2)计时器：客户端界面上设置一个0.5 s的计时器，每0.5 s向服务端发送REFRESH命令，更新设备状态信息，如赤经、赤纬等。

(3)接收信息:连接建立后，客户端采用阻塞方式。当接收到服务端发送过来的数据后，触发相应的事件并响应。采用和服务端相同的方式解析接收的数据，并根据命令实现相应的操作，如更新客户端界面上的设备状态信息等。

(4)发送命令：在客户端界面上可以对望远镜和CCD进行多种操作。首先触发向服务端发送请求的事件，然后按照自定义协议，根据操作的不同生成相应的命令和参数并发送到服务器端。

4 系统的界面

整个系统控制软件包括服务端和客户端两部分。事实上，在服务端并不需要任何界面，但为了显示过程和调试方便，在服务端依然设计了一个界面，包括显示实时的恒星时、望远镜赤经、赤纬、方位角、地平高度、CCD上次曝光的时间、曝光时刻、图像尺寸等信息。同时在屏幕上显示客户端访问情况以及上次采集的CCD图像。图3是截取的一部分服务端界面。

图3 望远镜控制系统服务端屏幕截图

Fig.3 Screenshot of the Telescope Control System on the Service End

客户端连接服务器端后，在实时显示望远镜的各种状态的同时，可以对望远镜进行控制，包括输入赤经、赤纬进行望远镜的移动；望远镜跟踪的开启和关闭；望远镜的停靠(Park)和解除停靠(Unpark)。对于图像采集，可以输入CCD曝光时间和图像在服务端存放的地址及文件名。同时这个界面也支持直接的命令行输入方式，用于控制望远镜和CCD。

5 系统测试

初期的系统开发是在ASCOM提供的模拟器上进行的，为检验其在真实望远镜的使用情况，2011年10月13日，在国家天文台西部选址组的实验室中将本系统和真实的望远镜连接进行了整体系统测试。

图4 望远镜远程控制系统客户端界面

Fig.4 Screenshot of the Telescope Control System on the Client End

望远镜为西部选址正在使用的Meade LX200 ACF型地平式望远镜，配置Meade的ASCOM驱动软件。服务端计算机使用一台Lenovo Thinkpad X200s笔记本，操作系统为Windows 7。计算机一端通过USB和串口的转换器与望远镜相连，另外一端通过窄带的调制解调器通过办公室的有线电话拨号进入北京市电信并连入因特网，IP地址为电信公网临时分配的地址。客户端安装在实验室中的另外一台笔记本电脑上，通过无线路由器进入国家天文台局域网，然后接入因特网。这样就搭建了一个望远镜通过窄带拨号网络连入因特网，而观测者在国家天文台进行远程控制的模拟环境。

在实验过程中，成功地实现了望远镜改变指向、跟踪、停靠等功能。由于设备和时间限制，未进行和CCD的连接实验。但总体测试表明，利用ASCOM技术，完全可以实现一套选址望远镜用的远程控制系统，并实现快速部署。同时测试也表明，利用ASCOM作为底层技术，上层利用ASCII Over TCP方式，可以在小带宽(约9 600 bps)的情况下，不但可以有效地实现望远镜控制，而且望远镜状态的实时监测效果也是非常满意的。

6 未来工作

由于ASCOM支持多种设备，系统有非常好的可移植性。下一步，首先实现通过ASCOM对圆顶、滤光片、调焦等设备的驱动；其次，由于网络带宽的限制，目前采集的图像是存储在服务端的，未来将考虑通过压缩、抽样等方式在窄带网络上将图像传递到客户端，从而在对望远镜等设备状态获取的同时实现观测数据的远程监控；第三，在客户端实现各种控制的基础上，实验在服务端通过脚本方式控制望远镜，向自主观测方向发展。第四，本文实现的还是一个原型系统，实验未在真实的野外环境中进行。虽然从现有的情况分析，实验环境非常接近天文选址站点的实际情况，但把这个系统应用到野外进行测试是下一步必须进行的环节。

ASCOM是基于Windows操作系统的，虽然Windows本身的缺陷给利用它作为观测平台带来一些不稳定因素，但是Windows丰富的资源和易操作性，也给在这一平台上扩充更多的功能提供了便利。在Linux操作系统下，国际上这几年也发展了一个RTS2[6-7]望远镜远程控制标准，丽江的BOOTES-4就是国内第一架应用这种标准的自主望远镜。但这个标准使用的范围还不大，而且也不是专门为选址小望远镜开发的，支持的设备也不够丰富。然而对比ASCOM和RTS2两个标准，并进一步研究最适合天文选址小望远镜的远程控制的平台是非常有意义的工作，也是未来的目标。

[1] 刘立勇, 姚永强. 天文台址大气光学湍流探测技术[J]. 天文学进展, 2010, 28(4): 391-403.

Liu Liyong, Yao Yongqiang. Detection technology of atmospheric optical turbulence for astronomical site[J]. Progress in Astronomy, 2010, 28(4): 391-403.

[2] The RoboDIMM[EB/OL]. [2011-12-27]. http://www.ctio.noao.edu//telescopes/dimm/dimm.html.

[3] RoboDIMM—The ING’s New Seeing Monitor[EB/OL]. [2011-12-27]. http://www.ing.iac.es/PR/newsletter/news7/ins7.pdf.

[4] A new Robotic DIMM for Calar Alto Observatory[EB/OL]. [2011-12-27]. http://www.caha.es/newsletter/news04b/Aceituno/Newsletter.html.

[5] Standard for Astronomy[EB/OL].[2011-12-27]. http://www.ascom-standards.org/.

[6] Petr Kubánek, RTS2—The Remote Telescope System, Advances in Astronomy, Volume 2010, Article ID 902484, 9 pages (2010).

[7] Petr Kub′anekab, Martin Jel′nekb, John Frenchc, et al. The RTS2 protocol[C]// Bridger Alan, Radziwill Nicole M. Advanced Software and Control for Astronomy II. Proceedings of the SPIE, 2008, 7019: 70192S-70192S-12.