兰天，郭坚，张红军，董振辉，韦涌泉

北京空间飞行器总体设计部，北京 100094

1 引言

对星上时间进行有效管理是保证航天器安全、可靠运行的必要条件。星上时间管理通常包括时间恢复、时间校准、时间维护、时间分发、时间获取等几个部分[1-6]。

时间恢复是在星载计算机异常切机、复位后，能够让星上时间延续切机、复位前的状态，并尽可能保证时间精度。时间校准是通过直接授时、集中校时、均匀校时等手段，保证天地时统和航天器器间时统，修正航天器守时误差。时间维护是根据任务需要选择高稳晶振，控制航天器时钟漂移，提升守时精度。时间分发是以秒脉冲、时间广播等手段，为航天器中各时间用户提供高精度时间。时间获取是为星载计算机的程控、自主管理、自主健康等功能提供可靠、精确的判据。

航天软件是具备强实时性特点的中断驱动型嵌入式软件。在航天软件中准确获取星上时间的主要挑战是中断抢占、中断嵌套造成的数据竞争。为保证星上时间获取准确性，首先要有效识别需要获取星上时间的应用场景，对相应场景中不同优先级的中断间数据竞争进行有效的检测和识别[7-13]。在此基础上，合理设计中断服务程序[14-15]和相应的星上时间获取方法[17-18]，以预防因数据竞争造成星上时间获取异常。

航天器大多选择82C54作为计时芯片，并将其配置为秒定时器使用[16]。在星载计算机软件中维护一个含有秒部与毫秒部的星上时间，配合82C54一起完成航天器的时间维护。随着航天器的功能、性能需求的演进，82C54定时器产生的秒中断往往不再是航天器中优先级最高的中断。秒中断与其他中断间时序的不确定性可能导致出现中断抢占和中断嵌套，造成获取到的星时与实际星时差1s的问题。为了解决这一问题，前人在硬件措施[17]和软件措施[18]上均进行了有益的探索。

本文首先对以往工程实践中的4种软件实现的星上时间获取方法进行了分析，明确其适用和不适用的数据竞争场景。然后，针对工程应用中遇到的处理器自动清除中断未决寄存器，导致现有星上时间获取方法无法适用的问题，提出了一种不依赖中断状态的星上时间获取方法。

2 星上时间获取方法比较研究

2.1 通过82C54维护星上时间的过程

航天器的星上时间通常由数据管理分系统或综合电子分系统的星载计算机维护。在星载计算机软件中维护一个有秒部和毫秒部的时间，同时采用82C54定时器芯片进行秒计时，即将82C54定时器产生中断的周期定为1 s。

在初始化时，对82C54进行定时周期配置，82C54芯片自动开始倒数时间，当倒计时到1时，82C54芯片输出一个宽度为1个时钟周期的中断信号，并重新加载计数值，开始下一轮秒计时，如图1所示。星载计算机软件响应中断进入秒中断服务程序后，对软件维护的星上时间进行加1 s的操作。在任意时刻，软件可通过软件维护的星上时间和82C54内的毫秒计时，计算得到准确的星上时间。

在星载计算机软件中，星上时间获取问题的关键在于：

1)82C54计时动作与软件维护秒值的动作相互独立，82C54在产生秒中断后随即开始下一秒的计时，不会等待软件。

2)软件获取星上时间的动作与软件维护秒值的动作之间存在对星上时间秒部的数据竞争。在中断抢占、中断嵌套等工况下获取星上时间，有可能出现秒中断服务程序与星上时间获取动作两者之间相互抢占的情况。此时，会出现星上时间秒部的数据完整性问题和星上时间秒部与毫秒部的数据匹配性问题。

针对星上时间秒部的数据完整性问题，可将软件维护秒值的动作、星上时间获取函数中计算当前星时的操作封装为原子操作，通过关中断保证数据完整性。

针对星上时间秒部与毫秒部的数据匹配性问题，需综合考虑比秒中断优先级更高的中断数量、高优先级中断中获取星上时间的时机、操作系统是否允许中断嵌套等因素，合理设计星上时间获取方法，准确判断秒中断服务程序中是否维护过秒值，根据判断结果决定是否对获取到的时间进行加1 s修正。

2.2 现有4种星上时间获取方法适用性研究

在现有航天器中，获取星上时间的常见方法有4种[18]，针对这4种方法在不同中断场景下的适用性进行了分析。

2.2.1 方法1

不关中断，取2次82C54计数，根据计数值是否发生翻转判断是否存在数据竞争。方法1的星上时间获取函数具体步骤如下：

1)第1次从82C54取毫秒值。

2)取软件中保存的星时。

3)第2次从82C54取毫秒值。

4)比较2次从82C54取的毫秒值。若第2次取的毫秒值小于第一次取到的值，则认为在取时间过程中发生过82C54定时中断。重新读取软件中保存的星时，用新读到的星时和第2次取到的82C54毫秒值一起计算出当前星时，此时该时间已经是在秒中断服务程序中维护过的时间。

方法1适用于在比秒中断优先级低的中断、任务中获取星上时间，但不适用于在比秒中断高的中断中获取星上时间。

如图2所示，在T1时刻中断A发生，在中断A的中断服务程序执行过程中，在T2时刻取星上时间时，发生秒中断。由于中断A的优先级高于秒中断，秒中断需要等到T3时刻才能维护软件中的星时。在这种工况下，方法1中第2次取到的软件星时是和实际星上时间之间有1 s误差的时间。

图2 单个高优先级中断抢占秒中断Fig.2 The second interrupt preempted by a single high-priority interrupt

2.2.2 方法2

关中断，取2次82C54计数，根据计数值是否翻转判断是否存在数据竞争。方法2的星上时间获取函数具体步骤如下：

1)关中断。

2)第1次从82C54取毫秒值。

3)取软件中保存的星时。

4)第2次从82C54取毫秒值。

5)比较2次从82C54取的毫秒值。若第2次取的毫秒值小于第一次取到的值，则认为在取时间过程中产生了82C54定时中断，但由于处于关中断状态，该中断暂未被响应。此时，在取到的软件星时基础上加1 s，然后使用修正后软件星时和第2次从82C54取到的毫秒值一起计算出当前星时。

6)开中断。

方法2适用于在比秒中断优先级低的中断、任务中获取星上时间，也部分适用于在比秒中断优先级高的中断中获取星上时间。将方法2用于在比秒中断优先级高的中断中获取星上时间时，只适用于单个高优先级中断嵌套秒中断，且进入高优先级中断后马上取星上时间的场景。

如图3所示，中断A优先级高于中断B，中断B优先级高于秒中断。在中断A执行过程中，秒中断于T1时刻发生；由于中断优先级，秒中断需要等待到T3时刻才能维护软件中的星上时间。若在中断B中，于T2时刻需获取星上时间，此时采用方法2，根据从82C54中2次取到的毫秒值大小无法检测到秒中断嵌套，软件无法决定是否在取到的软件星时基础上进行加1 s的操作。

图3 多个高优先级中断抢占秒中断Fig.3 The second interrupt preempted by multiple high-priority interrupts

2.2.3 方法3

关中断，通过读处理器中断状态，判断是否嵌套了秒中断。方法3的星上时间获取函数具体步骤如下：

1)关中断。

2)第1次从82C54取毫秒值。

3)取软件中保存的星时。

4)读处理器中断状态，判断是否嵌套了秒中断。若嵌套了秒中断，则再次从82C54取毫秒值，依据该毫秒值和加1 s后的软件星时，计算得到当前的星上时间。

5)开中断。

方法3通过判断处理器中断状态，检测秒中断是否被抢占或嵌套，克服了方法1、方法2中判断82C54计数值翻转在某些场景可能存在的漏判问题。但是，该方法和方法1、方法2一样，只适用于不允许中断嵌套的场景。在允许中断嵌套的场景，该方法无法判断秒中断被嵌套时是否维护过软件星时。

如图4所示，中断A优先级高于秒中断，在秒中断开始执行后，中断A打断秒中断。中断A在T2时刻需要获取星时，此时采用方法3，通过处理器中断状态寄存器检测到秒中断被嵌套时，并不能确定秒中断是否维护过时间。若秒中断在T3时刻维护时间，则通过方法3可以获得正确的星上时间；若秒中断在T1时刻维护时间，则通过方法3获得的星上时间比实际时间多1 s。

图4 高优先级中断嵌套秒中断Fig.4 A high-priority interrupt nested within a second interrupt

2.2.4 方法4

关中断，通过读处理器中断状态判断是否嵌套了秒中断，通过维护时间标识判断秒中断内是否已经对星上时间进行加1 s的操作。

在前期工程实践中，针对方法1、方法2、方法3都不能在中断嵌套场景下准确获取星上时间的问题，项目组提出了一种高可靠的星载软件时间管理方法[18]。

方法4涉及时间获取函数、秒中断服务程序、高优先级任务等3个模块。该方法通过一个“秒中断维护星上时间”的全局标识来识别秒中断被嵌套时是否已维护过星上时间。

在秒中断服务程序中，具体步骤如下：

1)设置“秒中断维护星上时间”标识为“未维护”。

2)关中断。

3)设置“秒中断维护星上时间”标识为“已维护”。

4)维护软件中保存的星上时间。

5)开中断。

在秒中断之后的第1个高优先级任务中，将“秒中断维护星上时间”标识设置为“未维护”。

在时间获取函数中，根据中断状态寄存器和“秒中断维护星上时间”标识一起判断是否在获取时间时进行加1s操作，具体步骤如下：

1)关中断。

2)获取软件中的星时和82C54中的计数值，根据这2个值得到当前的星上时间。

3)读处理器的中断状态寄存器，检查是否有秒中断。若没有秒中断，则维持上一步计算得到的星上时间不变；若有秒中断，则进一步检查“秒中断维护星上时间”标识。若“秒中断维护星上时间”标识为“已维护”，则维持之前计算的星上时间不变；若“秒中断维护星上时间”标识为“未维护”，则在之前计算的星时基础上加1 s，作为当前的星上时间。

4)开中断。

通过上述操作，方法4克服了方法3无法适应中断嵌套场景的问题。

针对4种方法的适用场景进行比较，如表1所示。

表1 星上时间获取方法适用性比较

从表1可见，上述方法的适用场景如下：

1)方法1仅适用于在优先级比秒中断低的任务、中断中使用；

2)方法2在方法1基础上，增加了在禁止中断嵌套的前提下，单个高优先级中断抢占秒中断，且在进入高优先级中断后马上获取星上时间的支持；

3)方法3在方法2的基础上，增加了在禁止中断嵌套的前提下，多个高优先级中断抢占秒中断时，在任意高优先级中断里获取星上时间的支持；

4)方法4在方法3的基础上，增加了允许中断嵌套的场景下，在任意高优先级中断里获取星上时间的支持。

可见，方法4是现有方法中适用范围最广的一种星上时间获取方法。某新型处理器进入中断后，处理器会自动清除相应的中断状态，且该清除动作无法通过软件进行配置。这使得采用方法4获取星上时间时，无法在高优先级中断中检测出是否嵌套了秒中断，进而无法获取准确的星上时间。因此，针对现有星上时间获取方法与处理器中断状态清除机制不匹配的问题，提出了一种不依赖中断状态的星上时间获取方法。

3 不依赖中断状态的星时获取方法

现有星上时间获取方法判断是否应进行加1 s操作时，进行了两方面判断：一是是否发生了秒中断嵌套，二是是否在被嵌套的秒中断过程中维护过星上时间。

首先，通过82C54内计数值判断是否发生秒中断嵌套。分析了“秒中断维护星上时间”标识值的变化与82C54计数值之间的关系，如图5所示。

从图5中可见，T1时刻为秒中断发生时刻;T2时刻为秒中断服务程序内关中断后将“秒中断维护星上时间”标识的值从“未维护”变为“已维护”的时刻;T3为在高优先级任务中将“秒中断维护星上时间”标识的值设为“未维护”的时刻。

图5 星上时间维护标识值变化与82C54计数值之间的关系Fig.5 The relationship between the change of onboard-time modifying mark and the 82C54 counter

设在任意时刻都可能获取星上时间，在从T1到T2的时间段内获取星上时间时，需要在星上时间获取函数中进行加1 s的操作；在T2时刻之后，直到下一次秒中断产生之前，获取星上时间时不需进行加1 s的操作。

T2时刻是一个不固定的值，其大小与在秒中断发生后(T1时刻之后)，所有比秒中断优先级更高的中断服务程序的总执行时间有关。因此，需要一个辅助判据来确定当前处于T2时刻之前还是之后。

该辅助判据可通过“秒中断维护星上时间”标识实现。在T1时刻到T3时刻之间，可通过“秒中断维护星上时间”标识的值来判断是处于T2时刻之前还是之后。

但是，T3时刻同样是一个不固定的值。在上章所述的方法4中，T3时刻取决于秒中断服务程序之后高优先任务第1次开始运行的时间。

秒中断信号在T1时刻产生，82C54计数值也在T1时刻发生翻转。在T1时刻到T3时刻之间，82C54计数值呈单调递减趋势，换算成的时间呈单调递增趋势。可通过选取一个合适的时间阈值来判断是否处于T3时刻之前，该时间阈值应在T2时刻的理论最大值到T3时刻的理论最小值之间。

T2时刻的理论最小值是T1时刻，T2时刻的理论最大值可通过分析软件中所有优先级比秒中断高的中断服务程序的最高出现频率和最大执行时间得到。T3时刻的理论最小值是T2时刻，T3时刻的理论最大值应在下次秒中断来临时刻之前。

通过调研现有星上软件设计情况，使用82C54计时的相邻两次秒中断的间隔有下述2类：

1)软件不需要产生秒脉冲信号。软件在授时、校时导致毫秒部变化时，仅将变化累积在软件维护的星上时间上，不调整82C54定时器的加载值。在该设计状态下，相邻两次秒中断间隔时间为1 s。

2)软件需要产生秒脉冲信号。在发生授时、校时导致毫秒部变化时，软件需要重置一次82C54加载值，以保证下次秒中断产生时刻与秒脉冲对齐。为避免相邻两次秒中断间隔过短，软件会调整加载进82C54的毫秒值，将相邻两次秒中断的间隔时间限制在500 ms～1.5 s之间。

可见，应保证在T2时刻出现理论最大值的情况下，T3时刻的理论最大值小于500 ms。

通过静态分析和单元测试，获得了比秒中断优先级高的中断服务程序的最大执行时间，在该时间基础上考虑设计余量，将T2时刻的理论最大值计为100 ms。

在软件中引入节拍计数Ctimes以控制T2时刻与T3时刻间的时间间隔，即在秒中断服务程序中将Ctimes的值清零；在每次运行高优先任务时将Ctimes的计数加1，之后检测到该计数≥阈值N且“秒中断维护星上时间”标识的值为“已维护”时，将“秒中断维护星上时间”标识的值修改为“未维护”。设高优先级任务的周期为Ttask，T3时刻的实际值满足下式：

(T1+N×Ttask)≤T3≤

(T2max+(N+1)×Ttask)

(1)

在本项目中，Ttask为100 ms，N值为2，结合上述T2max为100 ms，可知T3时刻的范围是(T1+200 ms)到(T1+400 ms)，满足T3时刻的理论最大值应小于500 ms的约束条件。

在上述分析基础上，选择门限值150 ms，作为判断软件是否处于T2时刻到T3时刻之间的判据，并根据上述分析的结论重新设计了秒中断服务程序和星上时间获取函数。

秒中断服务程序流程如图6所示。在秒中断服务程序中维护星上时间秒值，将该过程封装成原子操作，过程中关中断。

图6 秒中断服务程序流程Fig.6 Flow of second interrupt service procedure

星上时间获取函数流程如图7所示。星上时间获取步骤如下：

图7 星上时间获取函数流程Fig.7 Flow of onboard time acquisition procedure

1)关中断。

2)获取软件中的星时和82C54中的计数值，根据这两个值得到当前的星上时间。

3)根据82C54计数值换算的毫秒值，判断当前是否存在因中断抢占、中断嵌套导致秒中断产生后未维护星上时间的可能。

若82C54毫秒值大于150 ms，认为不存在可能，维持之前计算的星上时间不变；若82C54毫秒值不大于150 ms，认为存在可能，进一步检查“秒中断维护星上时间”标识。

4)在82C54毫秒值不大于150 ms时，若“秒中断维护星上时间”标识为“已维护”，则维持之前计算的星上时间不变；若“秒中断维护星上时间”标识为“未维护”，则在之前计算的星时基础上加1 s，作为当前的星上时间。

5)开中断。

从上述步骤可见，和本文1.2节中提到的4种方法一样，该方法的复杂度保持在O(1)级别，计算复杂度相当。对5种方法的代码实现进行了比较，本节所提方法的代码规模与方法4相近。

针对该方法在各种中断嵌套场景下的工作情况进行了分析：

1)高优先级中断发生在两次秒中断之间，高优先级中任意时刻获取星上时间。此时又可细分为2种情况，一是高优先级中断发生在T2时刻到150 ms之间，即上一次秒中断刚结束；二是高优先级中断发生在150 ms到下次秒中断来临之间。

若高优先级中断发生在T2时刻到150 ms之间，此时“秒中断维护星上时间”标识的状态已在秒中断里被改写为“已维护”，因此不会进行加1 s操作。

若高优先级中断发生在150 ms到下次秒中断来临之间，此时82C54毫秒值大于150 ms，因此不会进行加1 s操作。在高优先级中断发生在两次秒中断之间时，该方法能够准确获得星上时间。

2)高优先级中断先发生，高优先级中断处理过程中，秒中断发生，高优先级中断中任意时刻获取星上时间。

此时，82C54毫秒值在图5中的T1时刻到T2时刻，满足不大于150 ms的条件；同时，“秒中断维护星上时间”标识在上一个秒中断后的T3时刻被设为“未维护”，此时星上时间获取函数中会进行加1 s操作。秒中断在高优先级中断处理过程中发生的场景下，该方法能够正确获取星上时间。

3)秒中断先发生，高优先级中断在秒中断维护星上时间之前嵌套秒中断，在高优先级中断中任意时刻获取时间。

此时，82C54毫秒值在图5中的T1时刻到T2时刻，满足不大于150 ms的条件；同时，“秒中断维护星上时间”标识在上一个秒中断后的T3时刻被设为“未维护”，此时星上时间获取函数中会进行加1 s操作。该方法能够正确获取星上时间。

4)秒中断先发生，高优先级中断在秒中断维护星上时间之后嵌套秒中断，在高优先级中断中任意时刻获取时间。

此时，“秒中断维护星上时间”标识的状态已在秒中断里被改写为“已维护”，因此不会进行加1 s操作。该方法能够正确获取星上时间。

4 试验验证

为验证星上时间获取方法功能正确性，通过修改秒中断服务程序的方式，模拟高优先级中断嵌套秒中断的工况，测试用秒中断服务程序如图8所示。

在试验中将前文分析的各种场景，归结为在秒中断服务程序中关中断前发生中断嵌套并取星上时间(测试点1)和在秒中断服务程序中开中断后发生中断嵌套并取星上时间(测试点2)2种情况。

在测试点1、2，直接调用本文提出的星上时间获取方法，获取星上时间并保存在特定RAM区内。在软件任务队列中添加测试信息输出任务，该任务从RAM区读出待输出的测试数据，将其组织成特定格式，通过1553B总线消息输出测试数据，并通过1553B总线监视设备进行监视，如图9、图10所示。

图10 星上时间获取方法测试记录Fig.10 Test record of onboard time acquisition method

从图9中可见，RT18是该航天器1553B总线网络中的一个空闲RT地址，软件将其用作测试，通过向该RT的不同子地址发送定制内容的测试消息，实现对软件内部状态的灵活监视。

发往RT18子地址6的测试消息类型为BC-RT消息，消息含32个数据字。星上时间占用的6个字节中，第1～4字节为秒部，第5、6字节为毫秒部，高字节在前，低字节在后。在测试点1、2采集的星上时间被放置在测试消息中的固定位置，第1～6字节(从1开始计数)为图8中测试点1获取的星上时间，即模拟在秒中断发生后，秒中断服务程序还未维护星上时间时被高优先级中断嵌套，在高优先级中断中获取的星上时间。在第17～22字节打印了图8中测试点2获取的星上时间，即模拟在秒中断发生后，秒中断服务程序完成对星上时间维护后被高优先级中断嵌套，在高优先级中断中获取的星上时间。格式与测试点1一致。

图8 测试用秒中断服务程序Fig.8 Second interrupt service procedure for verification

从图9中可见，用本文提出的星上时间获取方法在测试点1、2获取的星上时间一致，没有相差1 s的问题，说明该方法能够正确识别出是否发生中断嵌套及发生中断嵌套时秒中断服务程序是否维护过星上时间。

图9 通过1553B消息监视在2个测试点获取的时间Fig.9 Monitoring the onboard time acquired at two test points by 1553B message

在秒中断服务程序维护时间前获取星上时间时，该方法能够正确对取到的时间进行修正；在秒中断服务程序维护时间后获取星上时间时，该方法不会进行误修正。

针对时间获取功能的稳定性进行了长时间拷机测试，通过总线监视的过滤功能检索出相关测试记录，对星上时间获取稳定性进行验证，如图10所示。通过上述测试，验证了该星上时间获取方法在秒中断被嵌套时，能够稳定、正确地获取星上时间。

5 结论

针对现有适用于中断嵌套场景的星上时间获取方法，存在对处理器中断状态的依赖，导致无法在新项目中移植使用的问题，提出了一种不依赖中断状态的航天器星上时间获取方法。

该方法在现有星上时间获取方法基础上[18]，调整了对秒中断嵌套的判定方法。将依据处理器中断状态判断是否存在秒中断嵌套，变为依据82C54中毫秒计数值判断是否存在秒中断嵌套，进而依据“秒中断维护星上时间”标识判断是否需要对当前星上时间进行加1 s修正。

修改后的方法不依赖硬件处理器的中断状态，具有良好的可移植性。该方法已在火星探测器的多台星载计算机上得到成功应用，可为后续航天器软件设计提供参考。