王连国,朱 岩,马 苗,饶家宁,梁耀明,王 蔚
(1. 中国科学院 国家空间科学中心 复杂航天系统电子信息技术重点实验室, 北京 100190; 2. 中国科学院大学, 北京 100049)
围绕行星科学领域进行太阳系内的地外天体探测活动,尤其是通过巡视器(rover)开展行星表面巡视探测,具有重大科学意义,国际上的主要航天组织规划了一系列行星巡视探测计划[1]。
行星巡视探测器与地球轨道探测器有许多不同之处。首先是资源约束极其苛刻,重量、体积、能源、数据量都有严格要求。其次是探测器与地面的通信机会有限且时间间隔较长,必须在长时间没有监控的情况下运行和进行科学探测。因此,除了需要自主导航,还应对探测器的工作状态进行自主监测,能够在一定范围内自主决定要进行的任务,并能对出现的一些故障进行在轨自主定位、诊断和修复或重构[2]。
对于有效载荷,一是要实现轻小型化,低功耗,提高有效数据比重,降低数据冗余;二是要具备一定的自主任务执行能力,减少对地面控制的依赖,高效地完成科学探测任务;三是要具有健康管理能力,对出现异常的设备,采取修复或隔离措施。
美国国家航空航天局(National Aeronautics and Space Administration, NASA)和欧洲航天局(European Space Agency, ESA)的深空探测研究起步早,技术先进,探测器可提供较多能源,具有高性能的计算能力[3-5]。在自主探测方面,进行了深入的研究和应用,具有自主任务规划、智能目标选取、科学现象在轨发现能力[6-8]。
国内方面,受技术基础和工程约束限制,探测器可提供的资源有限,故在“嫦娥三号”探测器中,采用一种与NASA及ESA的有效载荷控制方式不同的方案,首次实现载荷数管与多载荷电子学紧耦合轻小型一体化设计。“嫦娥五号”探测器的有效载荷也是采用这种电子学一体化设计。仅使用一台载荷数管设备(载荷电控箱)完成有效载荷的管理,最大限度地实现了系统资源共享和信息综合处理。存在的问题是:各电子学单元直接挂接到CPU的数据总线、地址总线、控制线上,这种方式在载荷电控箱集成前,各载荷单独调试和试验时,需要公用部分CPU的配合,需要的地检资源多。同时由于所有有效载荷电子学共用CPU总线,也会产生相互影响和时序竞争。另外,在载荷运行控制方面,主要依靠地面上注立即指令和延时指令,自主能力较弱。
本文针对行星巡视探测需求和存在的问题,采取了新型有效载荷集中式控制方法。一是采用新型的载荷电子学和载荷数管集成一体化架构,将集成在机箱内的各电子学单元之间接口串行化,目的是在各电子学板功能集成的前提下,降低接口耦合度。二是采用立即指令、事件表和工作模式表等控制方式,可自主控制各载荷工作。三是采取基于预设规则的监控措施和故障影响最小化的隔离方法,能够依据预设的规则监控载荷的工作状态,自主对故障载荷采取恢复和隔离措施而不影响整个有效载荷系统自主探测过程。
本文的集中式控制方法在我国首次火星探测任务中进行了应用,用于对火星车有效载荷进行控制。本方法有以下优点:①实现了有效载荷功能和资源复用,既提高了系统功能密度,解决了系统重量、体积和功耗严重不足的问题,又优化了各电子学间的接口;②具备较强的自主控制载荷进行科学探测的能力,能够适应深空探测通信延迟大、无实时测控的特点。
通过对行星巡视探测任务进行需求分析,距离遥远的探测任务,并不需要高性能的处理能力,但对重量、功耗、数据量等约束苛刻。故本文提出了中等处理性能、低功耗、低成本的载荷电子学和载荷数管一体化集成化方案,系统架构如图1所示。公用部分,即载荷数管,是高度集成的计算机与数据处理单元、电源单元。计算机与数据处理单元的原理框图见图2,CPU采用AT697F,运行频率64 MHz,现场可编程门阵列(Field Programmable Gate Array, FPGA)集成了1553B控制器、NAND FLASH存储控制、科学数据处理、命令/状态处理、OC指令发送、模拟量采集等功能。各载荷电子学完成各载荷探测仪器的控制,公用部分集中完成整个有效载荷系统的数据管理,包括转发各载荷命令,组织各载荷遥测参数,采集各载荷的科学数据,对载荷数据进行压缩、组包、存储等。
图1 新型集成一体化载荷数管体系结构Fig.1 Novel integrated architecture of payload OBDH
公用部分与载荷电子学之间的控制接口使用双向RS422方式,数据接口使用单向RS422方式,都是点对点连接,采用标准通用异步收发传输器(Universal Asynchronous Receiver/Transmitter, UART)协议,控制接口比特率115 200 bit/s,数据接口比特率1 Mbit/s。通过分析目前和未来一些深空探测任务的需求,控制接口比特率115 200 bit/s可满足需求,受对地通信限制,载荷产生的数据量不能太大,故载荷的数据率不高,1 Mbit/s可满足载荷数据传输需求。
该体系结构有以下创新点:
1)内部控制接口和数据接口都使用点对点串口。该接口方式简单,占用资源少,成本低,方便各电子学单元独立调试和测试,容易进行故障检测、隔离。
2)设计了适合深空探测应用的控制接口。该控制接口用于向载荷电子学发送串行数据指令,获取载荷的工作状态参数。采用RS422主从式半双工接口方式,为减少接口信号数量,使用同一对差分线,分时进行发送和接收。采用主从式通信方式,公用部分为主机,各载荷电子学为从机,采用主动应答式的握手协议。为保证通信可靠性,制定了完备的通信协议,包括响应时间、超时时间、字节间距、重传机制、错误状态等。
针对深空探测对地通信能力弱和延迟大的特点,优化设计了数据指令,缩短指令长度,统一各载荷的指令格式,对指令应答码和应答遥测数据格式也进行了统一,如图3所示。地面注入时,载荷单条指令的有效部分仅为4 B,即载荷编号、命令类型、命令参数高低字节。其优点是:便于在轨自主按工作模式表执行指令,便于进行在轨健康管理;大大减少数据注入指令长度。
图2 计算机与数据处理单元原理框图Fig.2 Functional block diagram of computer and data process unit
图3 控制接口数据格式Fig.3 Data format of control interface
1.2.1 软件控制模型
本文借鉴了ESA的Rosetta探测器软件[9]和NASA的火星探测漫游者(Mars Exploration Rover,MER)软件[10],在面向对象模型分析、分层次自主运行、正常运行任务与异常处理配合等方面的设计思想。软件基于实时嵌入式操作系统VxWorks设计,NASA的MER和火星科学实验室(Mars Science Laboratory,MSL)任务也都使用VxWorks操作系统。
软件的主要任务是进行总线通信管理、载荷遥测遥控管理、载荷运行管理、载荷健康管理、数据采集及存储管理等。设计的软件控制模型见图4,由五个模块组成:数据注入模块、决策模块、执行模块、在线监控模块、报告模块。
数据注入模块负责解析地面应用系统上行的数据注入。数据注入分为三种,见图5。第一种是没有时间标签的立即指令,软件收到后立即执行;第二种是由带有绝对时间标签的指令组成的事件表,软件根据各指令的时间标签执行;第三种是由指令和等待时间组成的工作模式表,软件执行指令,并等待相应的等待时间后再执行下一条指令。工作模式表由立即指令或事件表中的指令启动。
决策模块负责查询事件表和立即指令表,判断是否有事件需要执行,对于需要执行的事件交由执行模块来处理,并删除异常事件和已执行事件。对于立即指令,则立即执行。
执行模块负责具体的事件执行任务,对于低级指令直接执行,对于高级指令则依据工作模式表拆分为多个低级指令来执行。
在线监控模块负责监视各载荷的运行情况,当出现异常情况时采取一定的措施对载荷进行控制。
报告模块负责汇总整理有效载荷系统的运行情况。
图4 软件控制模型Fig.4 Software control model
图5 数据指令类型Fig.5 Data instruction type
1.2.2 基于事件表的控制方式
事件表由带有绝对时间标签的指令组成,每一条指令称为一个事件。事件表用于使用绝对时间控制指令执行的情况。软件的决策模块对事件表中的所有事件判断是否执行的依据为时间标签。
定义Ts为系统当前时间,Te为事件指定的执行时间码:若Te>Ts+2 s,表明时间未到达,不对该事件做任何操作,继续保留在事件表中;若Ts-2 s≤Te≤Ts+2 s,表明到达事件的执行时间,交由执行模块处理,并将其从事件表中删除;若Te 传统的做法是将事件表设计为一个无序的数组,即不按事件所指定的时间码来排序,这样经过多次添加删除事件后,数组中已使用的元素位置并不连续。 记数组容量为N,添加一个事件的时间复杂度为O(N),删除一个事件的时间复杂度为O(1)。由于数组中的事件无序,决策算法需要依次对所有事件进行查询判断,查询事件表的时间复杂度则为O(N)。 本文使用基于优先级队列的堆排序(heap sort),将事件表设计为最小堆的数据结构,最小堆是一棵完全二叉树,特点为每个节点的值都小于它的子节点的值,因此根节点的值即为整个堆的最小值。由于嵌入式软件内存资源有限,不适合动态分配空间,所以使用数组而非链表来实现最小堆结构。为了保持最小堆的特性,插入任一节点、删除根节点的时候都要对堆的其他节点进行调整。对于有N个节点的最小堆来说,树的高度为lgN,因此插入一个节点、删除根节点的复杂度为O(lgN),获取最小节点(即根节点)的复杂度为O(1)。 决策算法只需获取事件表中时间码最小的事件(即根节点),因此,查询事件表的时间复杂度为O(1)。对事件表的删除操作都是删除距当前事件表中时间码最近的事件,即最小堆的根节点,因此,删除一个事件的时间复杂度为O(1)。 两种数据结构的性能对比如表1所示。 表1 两种数据结构性能比较 对本文设计的软件,查询最近事件的频率远远高于插入新事件以及删除最近事件的频率,因此采用最小堆算法效率更高。 1.2.3 基于工作模式表的控制方式 对于深空探测,通信能力有限,如地球与火星的环回通信时间约8~42 min,每天只有几次通信机会,地面规划人员需规划下一个火星日的工作计划并上注,探测器自主按工作计划运行,而无地面人员干预[5]。 本文的工作模式表即工作计划,工作模式表中指令执行时刻是相对时间的,如果工作计划不变,可重复调用之前的工作模式表。 1)工作模式表设计 软件支持10个模式表(模式表0,模式表1,…,模式表9),每个模式表的容量为128个指令。将模式表设置为两种优先级,其中模式表0为高优先级,模式表1~9为低优先级,同一优先级的模式表可同时执行。 每个模式表中可以包含多个载荷的指令,也可以只包含单个载荷的指令。对于等待延时指令,其动作内容为3 B的等待时间,以100 ms为单位。 2)模式表控制过程 对模式表的控制作为一个单独的任务,100 ms调度一次。图6是模式表调度任务的控制流程,图7是单个模式表的处理流程。 图6 自主运行任务控制流程Fig.6 Flowchart of autonomous control task 图7 工作模式表运行流程Fig.7 Flowchart of work modeTable 3)执行时间分析 模式表任务每次调度最多执行模式表中的一条动作,在不考虑模式表1~9运行过程中被模式表0打断的情况下: ①若两条指令之间没有等待动作,则它们之间的时间间隔为100 ms; ②若两条指令间有1条等待动作,则它们的时间间隔为该等待动作所指定的时间; ③若两条指令间有连续N条等待动作,则它们之间的时间间隔为T1+T2+…+TN-0.1×(N-1) s,Ti为等待动作指定的时间; ④模式表存储。模式表存储在NAND FLASH中的载荷工作模式表存储区,每个模式表单独占用FLASH中的1块数据空间(约为2 MB),每个模式表存储三份。FLASH存储器采用多种保护措施,包括使用(12,8)汉明码进行存储器使用信息保护,使用RS(256,252)编译码对存储数据进行保护[11]。 系统上电时,从FLASH中读取模式表,放入SRAM模式表运行区。模式表在SRAM中也存储三份,采取三取二冗余设计。 系统复位时,首先校验SRAM模式表运行区是否有效,若无效,则从FLASH中读取该模式表;若有效,则不必再从FLASH中读取。 可通过数据注入指令修改在SRAM运行的模式表区内容。可以每个模式表单独注入,也可以整个模式表一起修改,还可以修改模式表中的单个动作。需要将更新的模式表存储时,则存储到FLASH中。 健康管理的原则为:①监测系统设备状态,而不是事件状态,恢复的是系统设备状态。②监测点离故障点越近越好,即在软件的最底层监测并执行动作。这也是NASA的火星科学实验室(Mars Science Laboratory, MSL)探测器软件采取的原则[12]。另外,对于所有监控,启动一次异常处理之后,自动禁止监控。各项监控可通过注入指令使能、禁止。监控阈值可通过注入指令修改。采取的健康管理策略见表2。 表2(续) 本文提出的集成一体化架构,将载荷电子学和公用控制部分集成到一起,用高集成度、高性能的公用控制部分(载荷数管)实现载荷集中控制。各电路板为6U尺寸,公用部分的电源单元在一块电路板上实现主备份冗余,计算机与数据处理单元有2块板,组成主备份冗余。通过采取轻小型化措施,公用部分仅重3 kg,功耗6 W。 控制软件基于VxWorks操作系统,软件任务设计见表3。 表3 软件任务设计 其中,1553B总线通信任务、RS422通信任务、自主运行任务和主任务是周期性调度任务。使用操作系统的getUserTime()函数(获取当前系统时间码,时间码分辨率为1 ms)记录各个任务每次调度的时间,得到各个任务的实际调度周期。图8给出了周期性任务的设计调度周期和实际调度周期最小、最大值。从图中可以看出,优先级高的1553B总线通信任务、RS422通信任务、自主运行任务,实际调度周期和设计调度周期相差很小。图中的任务实际调度周期是软件多次运行的统计结果,1553B总线通信任务调度23 670次,RS422通信任务调度47 349次,自主运行任务调度9469次,主任务调度47 314次。 各任务运行时间的测试方法是使用FPGA内的时间码标签寄存器,分辨率为20 μs。各任务执行时间如图9所示,除数据压缩任务外,其他有实时性要求的任务运行时间很短。FLASH管理任务与读、写、擦除动作相关,运行时间不一,此处未列出。 图8 周期性任务设计和运行情况Fig.8 Periodic task design and running result 图9 任务运行时间Fig.9 Running time of task 使用getUserTime()函数记录事件表和工作模式表中各指令的执行时刻,得出各指令执行时刻的抖动情况。图10为事件表中指令执行时刻抖动情况,该结果为由64条指令组成的事件表在不同负荷下运行结果,最大偏差小于40 ms,优于误差2 s的指标要求。图11为工作模式表中指令执行时刻抖动情况,该结果为9个模式表(模式表1~9)并行运行时的结果,最大偏差为3 ms,远优于误差2 s的指标要求。 图10 事件表指令执行时刻抖动情况Fig.10 Jitter of eventTable instruction executing time 图11 工作模式表指令执行时刻抖动情况Fig.11 Jitter of work modeTable instruction executing time 我国首次火星探测任务已进入研制阶段,火星车巡视探测科学任务着眼于火星局部地区,开展高精度科学探测。本文的集中式载荷控制方法在火星车有效载荷系统中进行了应用。将各载荷专用的电子学和公用的载荷数管集成到载荷控制器机箱中,由公用部分统一提供二次电源,统一进行各载荷的运行控制和数据获取,统一提供与探测器平台接口。 地面应用系统科学家将规划好的下一火星日工作计划(即载荷工作模式表)上传至火星探测器平台,平台数管将载荷工作模式表转发给载荷数管。当日探测时,载荷数管根据载荷工作模式表自主控制各载荷进行科学探测,并存储科学数据。在探测工作结束后,将科学数据发送至平台数管存储,平台数管在通信弧段将数据下行地面。 该集中式载荷控制方法经过了初样阶段有效载荷系统联试和探测器整器测试,整个有效载荷系统运行良好,验证了该方法的有效性。该方法具有简捷、高效、可靠、功耗低、成本低的优点,适合行星巡视探测类任务对载荷进行管理。 本文根据行星巡视探测任务对载荷轻小型化和自主探测能力的需求,提出一种集中式载荷控制方法。硬件平台采用新型的载荷电子学与载荷数管集成一体化设计,在结构、功能集成的基础上,尽可能降低接口的耦合度,以方便各单机调试和试验。软件采用基于事件表和工作模式表的控制方式自主控制载荷工作,可在一个工作模式表中规划多个载荷的探测动作,也可在不同的模式表中分别规划载荷的探测动作,多个模式表可同时运行,具有较高的灵活性。同时采取了一系列健康管理措施,能够在长时间无人干预的情况下,保证载荷设备安全,并隔离故障载荷或恢复故障载荷的工作流程。该方法经过了实际工程验证,可满足实际工程任务需要,具有很好的工程借鉴意义。1.3 健康管理
2 实现结果及分析
3 应用情况
4 结论