卫星飞行软件是使卫星能够在其生命周期内执行预定义任务并控制与卫星相关的重要功能的软件
要使卫星成功执行其任务，它必须有能力在轨道上纠正其软件中发现的错误，同时将对任务操作的干扰降至最低
只有通过更新才能解决软件中的错误，在考虑在轨卫星时，最实用的更新方法是通过补丁
通过补丁，可以向卫星飞行软件添加新功能，更改软件中的现有功能或修复软件中发现的错误
然而，考虑到空间领域，在修补卫星飞行软件时，存在一些限制，例如系统的可用性、遥测/遥控带宽和专用于修补的可用内存
根据相关约束，必须考虑最小化补丁数据大小和寻找不同补丁方法的解决方案
本研究的目的是提供有关通过补丁修改卫星飞行软件的补丁技术和方法的信息
将分析使用飞行软件或引导加载程序进行修补过程的两种方法，以及两种不同的补丁数据生成技术
第一节.介绍飞行软件提供了卫星指挥、数据采集、存储和卫星运行所需的自主能力，从而控制所有子系统（电源、热、姿态和轨道控制、通信、有效载荷等）
由于飞行软件对卫星的运行至关重要，因此预计它在其整个生命周期内都能按预期正常运行
因此，应通过更新消除飞行软件中的错误，同时将对任务操作的干扰降至最低
当卫星在轨道上时，由于多种原因，可能需要修改飞行软件
这些可能是解决硬件问题，在任务期间提高软件功能，并修复在发射前被忽视的软件问题
一个典型的任务在其生命周期内可能需要大约15次修改，或者每年大约需要2次修改[1]
打补丁是卫星发射后修改软件的唯一实用方法，应在整个软件生命周期中仔细考虑，以及一般的软件维护[2]
修补程序作为次要更改应用，使大多数现有代码保持不变
务必尽量减少更改的代码量，以避免操作中断和给软件引入新错误的风险
在这种情况下，在生成补丁数据时会考虑不同的修补技术，以便最大限度地减少更改的代码量
在这项研究中，将解释为卫星飞行软件生成补丁数据而商定的补丁技术
在生成补丁数据后，在将补丁应用于飞行软件的范围内有不同的方法
在这项研究中，将解释通过飞行软件本身和引导加载程序软件将补丁应用于飞行软件的方法
将比较这两种方法并提供结果
最后，将分析提供安全和高质量飞行软件的修补活动，并评估软件维护活动以供将来研究
第二节.以前关于软件修补的研究第一代补丁是通过简单地获取原始可执行文件和更新的可执行文件之间的差异来执行的
这样，即使是很小的修改也可能导致所应用更改的内存地址之后的内存地址发生偏移
这将导致差异不必要地增加
这将导致修补过程在补丁大小方面效率低下
因此，开发了减小补丁大小的技术
先前的研究表明，使用两种常用方法来尽可能地减小贴片大小
第一种方法是为每个进程或模块保留额外的内存，将它们存储在“内存块”中
这种技术的主要思想是，只要更新后的代码适合其专用块，进程中的更改就不会移动以下内存块
第二种方法是在内存中专用于修补区域
如果代码被修改，则更改将放置在补丁区域中，并且旧的例程地址将替换为补丁区域 [2]、[3] 中新例程的地址
在补丁方面的另一个进展是补丁管理工具的开发
这些工具应该使修补更简单、更可靠
此外，可以使用工具自动生成补丁 [2]
此外，还有几项关于卫星任务期间应用的补丁以及应用这些补丁时吸取的经验教训的研究
获得的知识是新指南的基础，这些指南简化了软件修改并提高了可维护性
这些研究包含有关可能提高或可能不会提高可维护性的常见编码实践的信息
在编译和链接过程中要考虑的方面也是指南[1]，[4]的一部分
考虑到这项研究，可以看出，关于完整的修补过程以及如何修补卫星飞行软件的方法的研究并不多
出于这个原因，这项彻底的研究旨在为学术资源做出贡献
第三节.卫星飞行软件修补技术修补是通过仅修改原始可执行文件的一小部分来更新软件的过程，而不是更新整个可执行文件的传统方法
此过程的第一步称为补丁数据生成，是生成原始可执行文件和更新的可执行文件之间的差异
这种差异也称为补丁，用于“修补”可执行文件以添加功能或修复错误
A. 传统补丁数据生成要查找原始二进制映像和更新后的二进制映像之间的不同代码段，可以使用任何二进制比较工具
但是，如果没有补丁数据最小化技术，这些不同的代码片段可能太大而无法考虑用于修补，因为完整的系统更新可以更有效率
如果将新函数添加到源代码中，即使它是一个小函数或空函数，或者当现有函数更新时，位于 函数下方的函数也会更改
文本部分移位 [2]
这种情况如图 1 所示
图 1.在原始图像和更新图像中表示程序显示全部这种转变也影响了后面的部分
文本部分
此外，必须更新对以下过程的所有调用，因为指向这些过程的地址指针现在已更改
将所有这些差异结合起来，将更改大量代码
如此大规模的更新甚至不会被视为补丁
特别是考虑到卫星飞行软件修补的通信成本和应用时间，这种方法不合适，需要更先进、更合适的技术
B. 高级补丁数据生成要了解这些技术以便以有效的方式生成补丁数据，必须清楚地了解两个关键点
其中第一个是 ELF（可执行和可链接格式）是可执行文件、目标代码、共享库和核心转储的通用标准文件格式
ELF结构如图2所示
每个 ELF 文件由两部分组成;ELF 标头，包含有关二进制文件和文件数据的一般信息（文件类型、目标平台等）
此数据可以包括描述零个或多个段的程序标题表、描述零个或多个部分的节标题表以及程序标题表或节标题表 [5]–[7] 中的条目引用的数据
段包含运行时执行文件所需的信息，而段包含链接目标对象文件所需的所有信息
在这些部分中，我们将重点关注
文本和
数据部分
这
文本部分保存程序的“文本”或可执行指令
这
data 部分保存有助于程序内存映像的初始化数据
链接器还允许创建新部分
这种能力和这些部分的分类对于修补过程 [8]–[10] 很有用
图 2.ELF结构式显示全部第二个关键点是 GCC 中的强弱符号
GCC 允许开发人员定义弱符号和强符号
默认情况下，在没有任何注释的情况下，对象文件中的符号是强的
在链接过程中，不允许多次定义强符号，当有多个强符号定义时，这会导致定义错误，因为链接器不知道如何解析两个同名的符号
但是，二进制可执行文件中可以有一个同名的强符号和多个弱符号
在这种情况下，强符号会覆盖同名的弱符号，并在链接过程中选择强符号
GCC 的这种行为在定义库函数时尤其有用
借助此行为，二进制可执行文件可以覆盖先前定义的库函数，这对修补过程很有用[11]
为了利用 GCC 和 ELF 格式提供的这些功能，必须对默认的 GNU 链接器进行一些更改
这个新的链接器必须在原始部分的最底部创建一个新部分，同时仍然符合 ELF 格式
这个新部分称为补丁部分，如图 3 所示
本部分的目的是存储包含对代码的各种更改的修补程序
这可以通过使用 GCC 属性来实现
需要注意的是，必须非常小心地不要修改原始部分
因此，当添加的修改不影响图像的其余部分时，更改将最小化
图 3.添加了补丁部分显示全部添加修补程序部分后，还必须更新用于访问此修补程序区域的代码部分
因此，可以重定向到更新的功能
这是通过使用GCC [12]的“强弱符号”功能来实现的
原始函数符号将更改为弱符号，而 patch 部分中更新的函数将设置为具有强符号
因此，在代码的其余部分对该函数进行的所有过程调用都将重定向到更新后的函数，如图 4 所示
这种方法提供了最小的补丁数据大小，优化了整个补丁过程，因此本研究考虑了这种方法
图 4.更新映像中的过程表示形式显示全部第四节.卫星飞行软件修补方法在生成补丁数据并将其传输到卫星后，这些数据可以存储在两个单独的区域，提供两种不同的补丁方法
在补丁数据生成和传输之前，应选择所需的方法
此决定会影响生成的远程命令，因为这些远程命令存储修补程序数据的存储位置信息
A. 通过卫星飞行软件进行软件补丁这是由飞行软件完成修补的过程，导致软件自行修补
在此过程中特别使用了两种服务
第一个是内存管理服务，它负责数据加载和转储
该服务可以访问车载计算机上的所有内存区域，并提供使用某些远程命令 [13]、[14] 访问这些内存区域的能力
第二项服务是软件维护服务，负责更新和修补卫星飞行软件进程
当收到有关修补程序数据的远程命令时，此数据将写入相关的内存区域
此操作需要使用内存管理服务
此方法按以下顺序执行：在每次启动时，飞行软件都会从永久内存中读取并复制到 RAM 中的补丁区域
为了启动修补过程，地面站发送相应的远程命令，包括与补丁相关的数据
在加密检查之后，这些远程命令将被处理，并将补丁应用于RAM中分配的补丁区域中的飞行软件
因此，RAM中飞行软件的修补工作完成
为了完成修补过程，地面会发送飞行软件补丁请求远程命令
大小和 CRC（循环冗余校验）检查是在 RAM 区域中现已修补的飞行软件上执行的
这些检查成功后，修补后的映像将写入永久内存中的原始映像
为了完成该过程，将重新启动车载计算机
因此，飞行软件将被永久覆盖，此更新的映像现在将在每次启动时运行，直到下一个补丁请求
由于原始映像已更改，因此必须根据新的基础映像生成所有未来的修补程序数据
这些步骤可以在图 5 的流程图中看到
图 5.通过卫星飞行软件进行软件补丁显示全部B. 通过引导加载程序进行软件修补引导加载程序是系统引导时运行的第一个软件
它负责加载和启动飞行软件
此过程主要包括将飞行软件映像从永久内存复制到RAM，并在RAM中运行
引导加载程序有一个称为引导加载程序补丁区域的区域
此区域包含修补程序数据、修补程序数据大小、修补程序地址偏移量和修补映像的 CRC 值等信息
此区域能够存储多个补丁，所需的活动补丁选择存储在补丁配置地址中
引导加载程序补丁区域和补丁配置地址如图 6 所示
Fig. 6.Bootloader patch area schema显示全部此方法按以下顺序执行：在每次引导时，引导加载程序都会通过读取补丁配置地址来检查是否有可用的补丁
如果此地址指示选择了活动修补程序，则引导加载程序将启动修补过程
飞行软件映像从永久内存复制到 RAM，以便引导加载程序进行修改
然后，引导加载程序应用选定的修补程序
引导加载程序在RAM区域中对现已修补的飞行软件执行大小和CRC等检查
检查成功后，引导加载程序将继续加载此准备好的映像，并启动更新的飞行软件
使用这种方法，原始飞行软件保持不变
对于新的修补程序请求，必须根据此原始映像生成修补程序数据
这些步骤可以在图 7 的流程图中看到
图 7.通过引导加载程序进行软件补丁显示全部第五节.挑战在这项研究中，我们面临着许多挑战，尤其是在补丁数据生成过程中
我们面临的第一个挑战是最大限度地减少补丁数据
在这项研究的早期阶段，获得的补丁数据太大
我们通过使用 ELF 结构和 GCC 链接器的功能克服了这一挑战
第二个挑战是补丁数据生成的复杂性和管理
为了解决这个困难，我们开发了一个可以管理和生成补丁数据的工具
最后一个挑战是存储在补丁配置地址中的配置数据的重要性
即使此配置数据中的一个简单的错误也将是灾难性的
为了消除这种风险，我们实施了补丁配置检查和 CRC 检查
这些检查操作使我们能够检测补丁配置中的错误
第六节.结果与结论在这项研究中，描述了两种卫星飞行软件补丁管理方法
此外，还比较了传统方法和高级方法，以显示生成的补丁数据受到的影响
在极少数代码更改（例如单个变量的更改）中，两种方法生成的修补程序数据之间没有大小差异
但是，随着对代码的大量更改，传统方法生成的补丁数据的大小明显大于后一种方法生成的补丁数据的大小
较大的尺寸会导致补丁应用时间的不必要延长，从而影响系统停机时间
更新卫星飞行软件的第一个限制是尽量减少系统停机时间，以保持系统可用性[13]
此外，大尺寸的补丁意味着要向卫星发送大量遥控
特别是对于LEO（低地球轨道）卫星，与卫星通信的时间有限
LEO卫星有规律地进出通信锥体，如图8所示，在可以通信的地方
这进一步限制了更新飞行软件的时间[13]
还应考虑为补丁分配的内存量 [13]
由于内存量决定了最大适用的修补程序大小，因此它与第一个和第二个约束有关，可以一起考虑
考虑到这些限制因素，确定先进的方法效率更高
图 8.卫星通信锥体显示全部在表I中列出了两种技术的定量比较，以插入空虚拟函数
表一. 技术对比表在本研究中，飞行软件服务和引导加载程序软件完成的修补作为两种单独的修补方法包含在内
这些方法的比较如下：通过外部测试版软件服务完成的修补不会影响系统的启动时间，因为修补是在运行时完成的
在这方面，它是有利的，因为它不会增加系统的停机时间
通过飞行软件服务完成的修补不太难管理，因为只能应用一个补丁
因此，它在这方面是有利的
通过引导加载程序软件完成的修补不会影响原始映像
这提供了返回原始图像的机会，因此是有利的
通过引导加载程序软件完成的修补提供了在补丁区域中存储多个补丁和不同补丁应用的能力
表II给出了这些修补方法使用高级方法生成的1.3 MB飞行软件映像中36字节变化的补丁数据的时间效应
表II未考虑补丁数据生成、TC传输和图像CRC校验时间
表二. 方法比较表总之，这两种方法都有优点和缺点
两种方法都成功进行了修补
根据不同的系统需求，可以选择两种方法或单一方法进行修补
未来的活动将侧重于补丁管理工具的开发，以自动生成补丁数据作为软件维护的一部分，跟踪补丁的配置并生成指标，如必要的远程命令计数、补丁大小、估计的补丁应用时间等