基于Windows平台的卫星嵌入式软件移植方法

徐凯 李绍前 王学良 邹玉龙 李光

（中国科学院微小卫星创新研究院 上海市 201303）

1 引言

星载嵌入式软件由于开发周期长，对外通信接口单一、硬件研制进度紧张等原因，限制了应用软件早期验证工作，在很大程度上影响了整星研制进度。王业流等人曾提出由于嵌入式软件调制比较困难，对硬件依赖比较大，通过移植嵌入式软件到PC 平台能方便地对软件进行测试及系统仿真[1]。李鑫等人也提出用软件仿真的方式来模拟各种硬件开发平台，使得开发者和学习者在模拟器环境中进行嵌入式操作系统的移植工作[2]。如果将卫星应用软件运行在Windows 系统中，可以灵活地为软件测试提供许多便利的接口和环境，加快应用软件开发进程，缩短软件开发周期。星载嵌入式CPU处理软件多采用C 语言编写，其强大的可移植性为应用软件移植到Windows 平台中提供了便利[3]。

以某卫星嵌入式应用软件为例，剥离与嵌入式系统相关的接口通信机制（例如：1553B 通信机制），改为适合Windows 应用软件处理的通信形式（例如网络接口UDP 协议），且保留应用软件处理的时序一致性，还原全应用层信息处理功能，全面验证卫星嵌入式应用软件信息处理正确性，为应用软件提供便利的验证手段，提高软件开发效率。图1 为软件移植过程分析。

2 软件移植参考要素

软件移植出于不同的应用目标，移植方法也有所不同。在软件移植前需要对移植的可行性进行分析，例如移植语言的可行性、操作系统的差异、软件体系架构、软件实现的目标等，从而在源代码和移植代码间寻找快速有效的移植方法。

2.1 移植语言

卫星嵌入式软件开发大多采用C 语言，在Windows 平台上进行软件移植也支持C 语言，为软件移植提供了便利条件。将嵌入式应用软件移植到Windows 系统中，通过构建嵌入式源代码的运行环境，将在嵌入式系统中编译的源代码直接在移植的软件环境中运行，源文件能够直接在Windows 环境中调用和编译运行。这样通过在Windows 平台上进行开发和调试后的源代码便可直接应用到嵌入式系统中。这里讨论的源代码指的是应用层源代码，不涉及嵌入式系统硬件接口和操作系统等源代码。

2.2 软件应用环境

软件应用环境涉及操作系统和开发环境等，需要对不同移植环境进行分析，找出运行环境的差异，从而寻求适应新的运行环境所采取的移植方法。

操作系统应选择应用广泛且比较成熟的UNIX、LINUX、Windows 系列操作系统，有利于移植软件在多种平台上运行。Windows 操作系统是使用最广泛的操作系统之一，移植软件在Win7 或Win10 系统中均可运行，且系统资源占用率较低，软件开发便利。

嵌入式系统软件运行基于的是实时操作系统，例如VxWorks操作系统，操作系统对于中断的响应时间有严格的要求，确保事件处理的实时性。而Windows 操作系统属于非实时操作系统，系统基于消息栈的处理机制，对于事件的处理时延无严格的控制，响应时间不确定，但随着高性能CPU 处理能力的提升，其响应时间完全可以满足一般嵌入式软件移植的需求。

图1：软件移植过程分析

为使移植软件能够直接对原嵌入式代码进行开发和调试，应用环境应能够适合C 语言开发，同时能够支持友好的应用界面，便于开发和调试。对于开发环境的选择，Windows 平台上的开发环境选择比较多，本文采用Microsoft Visual Studio 应用程序开发环境。

2.3 移植软件功能实现

移植软件功能实现是做软件移植工作所要达到的目标。

在软件移植过程中，将与嵌入式系统硬件相关的接口、通信机制、内存读取等进行适应性地剥离和更改，同时构建嵌入式源代码运行所需要的运行环境，例如线程、时频、信号量，对外通信接口等。在源代码功能能够准确运行的基础上，可以针对软件开发和调试的需要进行相应的界面开发、运行日志显示等等。

软件功能实现需要能够真实反映嵌入式应用层的信息处理流程、软件处理时序、算法，软件的运行和操作流程要求与原嵌入式系统操作流程保持一致，从而达到嵌入式应用软件功能验证的目的。

3 软件移植参考方法

不同平台的软件移植研究需要考虑两个方面，理论方面和实践方面。研究软件移植的理论，根据嵌入式系统特点分析影响软件移植效果的因素，分析移植软件架构，提高移植效率和质量，同时需不断尝试，寻求最佳移植方法[4-5]。将以某卫星嵌入式应用软件移植过程为例，介绍卫星嵌入式软件移植过程中需要考虑的要素。

在卫星嵌入式软件开发中，不同的开发人员所建立的软件架构会有很大的不同，在软件移植过程中所考虑的方法也会不同。本文参考一些卫星嵌入式软件的设计情况，提出软件移植方法。

3.1 内存操作

软件移植过程中首要考虑的问题就是内存。在嵌入式系统中，应用软件的数据缓存或存储大部分需要操作系统内部的内存单元，软件初始化时为软件运行中的各个事件预先分配内存，其内存管理采用在RAM 内对各类数据分配内存和进行存取操作等，对不同数据结构分配缓存，不同的数据类型缓存大小不同，软件对RAM 内相关数据的存取按内存地址进行操作。

在Windows 系统中，数据缓存最便利的方式是直接利用操作系统内存进行管理来为不同的数据类型分配缓存。由于目前的Windows 系统计算机通常内存至少4G～8G，而数据缓存大小一般在几十至百兆量级，不会过多占用系统内存资源，且操作方便，因而采用系统内存为其应用软件分配缓存是可行的。将系统内存通过数组定义的方式分配给应用软件使用，这样嵌入式软件对RAM 的内存地址操作方式也同样适用于数组，从而实现软件对数据缓存操作的一致性，不需要对软件运行中的内存操作部分代码做大量改动。只要分配好了内存，后面对数据的存储和读取方式就和嵌入式系统中一致了，均为对地址进行操作。

需要注意在数组定义前需要根据嵌入式系统中的内存地址确定不同数据类型所占用内存大小，分配的数组大小不能小于所占用的内存。

原嵌入式系统中内存分配举例：

Windows 系统中内存分配举例：

从上述例子中可以看出，原嵌入式系统中内存分配时为相应的数据类型分配了两个连续的内存地址0x87AC0000 和0x87DC0000，则对于变量RAM_SPP 的数据缓存大小为两个两个内存地址的差值N，即N=0x87DC0000-0x87AC0000=0xC0000 字节。而在Windows 系统中进行软件移植时，通过为相应的数据类型分配同样大小N 的unsigned char 型数组，其数组名称RAM_SPP 即为该段虚拟内存的地址，与原嵌入式系统地址名称相同，后续对内存的操作部分便完全相同。

3.2 对外接口通信

移植软件与原嵌入式软件最大的不同在于对外通信接口的差异。嵌入式系统可采用多种形式的对外通信接口，比较常见的接口形式有422 或1553B 总线等。底层硬件相关的通信接口并非本次软件移植研究的重点，移植软件的主要目标是对应用层的软件功能进行验证。为了便于对移植软件进行开发和调试，可以选用灵活的通信方式（例如UDP 网络通信），或者根据自身需求在Windows 平台上开发其它类型的应用通信接口，以便通过与其它系统进行互联来对软件功能进行全面的系统性验证。

软件移植过程中需要了解嵌入式软件架构及其通信流程，明确所要移植的应用软件与嵌入式系统底层通信机制之间的交互界面，移植过程涉及底层通信机制与移植后通信方式的转换。在嵌入式系统中，不同的通信方式，其转换过程也不同。与422 接口通信形式相比，1553B 通信接口的转换通常比较复杂。1553B 总线通信采用命令/响应机制，需要根据应用软件相应的通信过程，改为采用UDP 网络通信函数进行数据发送或在网络接收到相关数据时通过相应的接受函数处理。在应用软件中有效隔离底层通信机制，转化为应用软件的信息处理部分，同时要注意一些与底层通信机制有关的特性，例如1553B 通信机制中的双字节反序问题，通常应用软件需要先纠正后再进行后续的处理，而移植后的软件采用网络通信方式则不需要处理这个问题。

3.3 时频基准

时频基准一般包括1PPS、10MHz 等，1PPS 主要用于设备间实现秒级同步，10MHz 主要用于频率合成，为设备提供基准频率信号。对于嵌入式CPU 软件，为使应用软件运行能够与外部时间保持同步，软件采用1PPS 信号来保持软件工作步调与外部系统一致。在Windows 系统中，可以采用PCI 类型的接口板卡，用于接收外部输入的1PPS 信号，通过软件编程，转换为中断信号给应用软件使用，以此来使应用软件与外部设备保持时间同步。

对于嵌入式应用软件中需要采用时间同步的处理方式，则在1PPS 信号中断时进行相应的处理。有一些软件功能的处理周期可能并非1 秒，可能需要500ms 或100ms，甚至其它的处理周期。对于这类非1 秒软件处理周期的情况，可以通过Windows 系统中的定时器来对两个1PPS 同步信号之间的时间间隔进一步划分。一般来讲应用软件只要在秒级能够与外部系统保持一致，对于秒内由于Windows 系统定时器产生的不确定度是可以接受的。当然，如果一些系统对于秒内的时间同步精度也要求比较高，可利用硬件来对秒内时间间隔进行更精确划分，产生更精确的时间同步信号，并通过外置板卡接收后给应用软件使用。

3.4 软件时序

软件运行时序一般指的是软件关键处理过程间的先后顺序，前序处理过程可作为后序处理过程的输入条件。应用软件需要有秩序的运行，离不开时序的约束，嵌入式系统应用软件也不例外。因此软件移植最重要的目标就是要保持软件运行时序的一致性，否则软件时序混乱，无法实现软件原有的功能，对于星载软件的验证就失去意义，也失去了软件移植的价值。目前嵌入式软件还没有形成统一的架构，其运行时序实现方式也各不相同，各有其特有的时序设计。

嵌入式软件运行时序控制一般包括硬件控制、软件逻辑控制等。移植软件的时序控制需要与嵌入式应用软件的时序控制方式保持一致，时序控制与软件关键函数的调用方式密切相关，下面从几个方面进行举例：

3.4.1 硬件控制方式

（1）时频信号控制：一些软件处理过程是定时执行的，每秒执行一次或每500ms 执行一次，应用软件通过检测该中断信号执行相应的处理过程，处理完毕后可以继续执行下一处理过程。

（2）接口通信控制：应用软件包含若干种对外通信接口，完成其与外部系统设备间的信息交互功能。应用软件通过对外部通信过程中的各类信息进行处理，处理该类信息后继续下一处理过程，从而完成了软件处理时序控制。

3.4.2 软件逻辑控制方式

（1）外部信息控制：应用软件通过接收外部信息来控制内部程序的执行顺序，例如外部设备对1.5s 内每隔100ms 进行计数，循环计数范围为 1～15（N），应用软件每隔100ms 接收一次外部输入的计数值，这样通过相应的计数值来控制按照固定时间间隔执行的软件处理过程，从而控制了软件的运行流程。

如上述示例代码所示，当N 的数值为8～12 时，执行过程1，当N 的数值为1～3 时，执行过程2。

图2：某卫星移植软件模型

图3：射频建链控制结果

图4：自主导航轨道外推径向误差结果

（2）程序执行标志控制：通过应用软件内部设置的执行标志进行时序控制，上一个处理过程执行完毕后设置执行允许标志，下一个处理过程通过检测此标志来判断是否执行，从而控制了软件的运行流程。

如上述示例代码所示，当程序执行标志满足要求时才会执行该处理过程。

这里需要指出，上述多种时序控制方式不是单独作用的，而是相互结合在一起共同对整个应用软件进行时序约束，且保留嵌入式应用软件原有约束方式，从而保持了与嵌入式软件功能的一致性。

3.5 功能实现

在解决了内存读取、对外接口通信、时频基准、软件时序等问题之后，基本构成了应用软件的运行环境。软件功能要求真实还原星载嵌入式应用软件的时序约束和信息处理过程，应用软件在运行流程上与星载嵌入式软件完全相同。

嵌入式软件一般包含多个线程，移植后的软件需要还原其多线程处理过程，Windows 系统需要为每个线程模块提供单独的线程进行处理。多线程之间涉及到信息同步和交互，嵌入式系统中线程之间的信息采取互斥访问机制，例如采用SemTake()/SemGive()的方式，在Windows 系统中，可以采用CMutex 对象对共享数据进行互斥访问。

嵌入式软件处理过程中受到通信机制、中断方式等方式控制，软件移植过程需要对与其有关的相应处理部分进行更改。在嵌入式软件中线程函数里运行的处理函数如与其底层运行机制相关联，需要剥离这些函数中与底层运行机制耦合的部分。原代码通过底层通信消息来控制相应函数的执行，而移植后的环境由于剥离了底层通信机制，需要改为通过新的通信机制进行调用处理，例如需要通过定时信号或新的通信消息来触发。

移植软件与原嵌入式软件运行流程保持一致，对外的通信接口改为网络接口或其它便于测试的通信接口，因而对星载嵌入式软件的操作和控制流程同样适用于该移植软件，能够全面还原应用软件功能。

4 软件移植及测试验证

结合上述软件移植参考方法，对某卫星嵌入式CPU 软件进行了移植工作，移植软件具备原嵌入式软件应用层功能，同时通信接口更改为更为灵活的UDP 网络通信接口，便于对软件进行开发和调试，达到了辅助嵌入式软件开发和仿真验证的目的。同时，该移植软件支持与外部各系统部件互联互通，进行全系统联合运行，实现星载嵌入式系统功能，具有相同的系统操作和控制流程。

如图2 所示，该移植软件主要包含如下功能模块：

（1）综合信息处理模块，包含综合信息流处理和射频信号建链控制管理；

（2）自主导航处理模块；

（3）接口通信模块；

（4）时频处理模块；

（5）定时处理模块；

（6）内存管理模块。为便于对移植软件进行开发和调试，可添加相应的开发和调试接口，如软件应用界面、运行日志、阶段数据保存等。

4.1 软件运行

在移植软件测试时需采用与其相匹配的接口方式进行通信。

移植软件运行前需通过配置文件预先配置启动参数。参数配置完毕后，软件运行并加载相应的配置文件同时初始化相应参数，开启线程、定时器和接口通信端口，初始化完毕后，软件进入到正常运行状态。

软件正常运行后，按照星载软件的操作流程可以通过对外通信接口对应用软件进行状态设置，使软件处于正常射频信号收发控制状态或者是待机状态，不进行信号收发，也可以开启自主导航功能，输出卫星自主导航解算结果。

4.2 软件运行结果

4.2.1 信息处理结果

移植软件按照星载信息处理流程和时序约束进行处理，软件对于射频信号建链控制、自主导航信息处理、信息处理和转发等均满足星载嵌入式系统要求，软件数据缓存设置与嵌入式系统设计一致，软件处理过程满足系统间接口约束要求，能够与系统间其它设备联合运行。

4.2.2 射频信号建链控制结果

移植软件采用卫星射频信号建链控制算法，利用卫星星历、姿态、时间信息、建链规划表信息等解算出每个控制周期的射频信号建链控制消息，包含当前控制周期内信号收发终端的工作时间、收发方式、调制方式、信息速率、多普勒等信息，用于终端的双向捕获，建立通信信道，完成双向通信和测距。移植软件与信号收发终端的通信协议和通信流程匹配，能够实现原嵌入式系统的替代功能。

移植后的软件通过控制信号收发实现射频信号双向建链，建链控制结果如图3 所示，能够连续控制信号正常建链并输出测距结果。4.2.3 自主导航结果

自主导航功能除了采用原嵌入式软件相同的自主导航算法以外，在软件处理流程上也要求严格一致，同时实时接收并处理信号收发终端返回的测距结果，并参与到自主导航解算中。该移植软件实现了双星至多星之间自主导航结果的互联互通，解算结果误差均收敛到要求范围，表明移植软件能够支持原嵌入式系统自主导航功能。如图4 所示，移植软件自主导航模块的外推轨道与精密轨道误差结果符合设计要求，证明移植软件自主导航模块移植结果正确性。

5 结束语

软件移植的研究由来已久，大部分软件移植的目标是对已有软件功能的重复利用、功能扩展、运行环境的迁移等。本文所研究的软件移植的目标是在Windows 环境下运行嵌入式应用软件，以便在硬件环境受限的条件下对软件进行快速开发、调试和仿真验证。

本文对嵌入式软件移植过程进行了研究，对移植过程中需要考虑的问题进行了讨论，提出一些软件移植方法。在卫星嵌入式软件开发中，不同软件开发人员所建立的软件架构会有所不同，进行软件移植时所考虑的方法也会有所不同，本文所研究的内容可提供思路和参考，后续将继续对嵌入式软件移植过程进行深入研究。

采用该软件移植方法形成的基于Windows 平台的某卫星应用软件，能够支持对嵌入式软件的开发、调试和仿真验证工作，同时作为卫星仿真系统的重要组成部分，在整个系统中能够稳定运行，信息处理、信号建链控制、自主导航结果等应用软件功能满足要求，软件移植方法正确。