51、星载嵌入式实时软件复用案例研究

星载嵌入式实时软件复用案例研究

1. 新项目范式的兴起

卫星系统的工业发展正面临着“更便宜、更快、更好”任务范式的挑战。这一范式要求提高操作能力、降低功耗、减轻发射质量并缩短上市时间。未来星载嵌入式实时系统的发展将面临以下需求：
- 将开发周期从目前的 3 - 4 年缩短至 18 - 24 个月；
- 通过提高操作的自主性和响应能力，交付更优质的任务产品；
- 支持软件密集度越来越高的系统。

这些需求对航天器总线的架构产生了巨大影响。例如，在相同语言基线的情况下，这些组件的软件规模预计将从目前的 8000 - 12000 条源代码语句增加到新任务的 15000 - 25000 条。为了应对这一情况，软件开发过程的生产率至少要提高四倍，因为要在一半的时间内交付两倍大小的软件。

同时，软件产品的操作要求将增加系统的功能复杂性和实时关键性，并且要在不低于现有可靠性的范围内实现。

为了应对产品日益增加的复杂性和开发进度的缩短，迭代和增量开发过程比传统的“瀑布”模型更具优势。要实现高效的开发过程，还需要以下三个要素：
- 有利于架构可扩展性的应用模型；
- 与该应用模型相匹配，加速系统构建的软件复用框架；
- 支持生产可复用、可靠和可预测软件的使能技术，其中 Ada 语言起着关键作用。

2. 过程模型

过程模型基于两个概念支柱：设计框架和计算模型。

2.1 设计框架

设计框架涵盖了从软件需求阶段到详细设计阶段的开发过程。与经典的瀑布模型不同，设计框架考虑了跨阶段进行多次增量迭代的可能性。其目的是应对新一代系统设计和验证中基于反馈的迭代。过程的增量性质将整体开发分解为多个（并行）子开发线程，每个线程的复杂性有限，更有可能快速完成。

2.2 计算模型

计算模型整合了指导设计框架内迭代过程并使其收敛的概念，具体定义如下：
- 用于构建系统实时架构的组件类型、它们之间的通信和同步方式以及执行时的并发范式；
- 这些组件的执行属性和实时特性，以及对其使用和交互的约束；
- 支持对基于这些组件构建的系统进行实时行为静态分析的基础分析模型。

这些定义共同决定了为过程提供的可预测性架构支持的抽象视图。合适的计算模型支持构建灵活且可静态验证的架构，适应开发的增量性质，并减少集成测试时所需的实时验证范围。

由于星载系统本质上是并发的，新一代系统的并发程度会更高。因此，需要一个能够控制这种固有并发的计算模型。我们选择的计算模型源于 HRT - HOOD 的定义，并基于固定优先级抢占式调度原则。该模型考虑了以下对象：
- 模拟时间触发线程活动的周期性对象；
- 模拟事件触发线程活动的偶发性对象；
- 模拟对共享数据进行互斥访问的非线程结构的受保护对象。

Ravenscar 配置文件为实现该计算模型提供了最紧凑和高效的语言原语集。基于该计算模型并使用 Ravenscar 配置文件实现的架构可以进行静态定时分析。

3. 应用领域

卫星系统通常在地面控制中心的监督下运行。地面中心通过发送遥测命令（TC）和接收卫星返回的遥测数据（TM）来对星载系统行使控制权。地面中心与在轨卫星之间的 TC/TM 数据流服务是航天器总线中嵌入式实时软件的一项基本功能，这些通信相关服务统称为数据处理控制（DHC）系统。

DHC 服务通常是对来自地面中心（处理传入 TC）或星载（发出 TM 或处理其他请求）的不连续请求做出响应。因此，DHC 服务主要具有偶发性、事件驱动的性质。对于任何给定的任务场景，明确的操作要求通常会限制触发事件的到达间隔时间。此外，DHC 系统可能还包括少量自然周期性活动，例如根据任务特定的监测标准监测选定的星载参数，并执行任何必要的纠正措施。

对于传统系统，地面中心需要始终掌握航天器的状态和运行的最准确信息。新一代自主系统倾向于将部分控制责任转移到空间段。无论哪种方式，控制活动都要求最小化命令发出与实际在星载执行之间的延迟和抖动。因此，DHC 服务的大多数实时要求都应被视为任务关键的。未能满足这些要求可能会降低任务产品的质量，甚至危及任务。

4. 项目要素

4.1 应用模型

欧洲航天局的分组遥测和分组遥测命令标准以及相关的 CCSDS 建议解决了地面用户应用程序与星载应用程序进程之间 TC 和 TM 数据的端到端传输问题。欧洲航天局的分组利用标准（PUS）通过定义基于分组的接口，扩展了这些标准，用于星载应用程序进程执行某些服务。PUS 通过规定服务模型（即应用程序进程在收到给定服务请求时的行为方式）和相关 TC 和 TM 分组的内部结构来定义这些服务。

在 PUS 的背景下，应用程序进程被定义为能够接收 TC 分组并生成 TM 源分组的星载实体。在整个任务期间，应用程序进程具有唯一且静态的标识。应用程序进程与卫星通常的子系统和有效载荷功能划分之间的映射没有限制。多个应用程序进程可以驻留在同一个处理节点上。

PUS 最初的定义是从地面中心的角度解决卫星生命周期中调试和运行阶段的需求。最近的研究表明，将 PUS 服务模型应用于星载应用程序进程之间的通信而无需地面参与是有用的。目前正在对 PUS 标准进行修订，以解决这一扩展的影响。新的太空项目也在考虑利用这一潜力。

在系统定义和实现的所有阶段一致应用 PUS 服务模型可以带来重要优势。按照 PUS 分区构建的 DHC 架构可细分为一组松散耦合的应用程序进程。这种细分自然反映在开发理念中。DHC 系统的规范、实现和验证可以分解为逐步的子开发增量，每个增量针对单个应用程序进程或其下一级集成。这一概念非常适合迭代和增量开发过程模型。

4.2 软件复用框架

符合 PUS 的 DHC 软件架构的几个关键特性直接源于 PUS 操作模型。首先，负责星载通信且符合标准分组定义的大部分软件基础设施在不同任务中可以保持不变。其次，PUS 操作模型的松散耦合特性和相关服务模型的事件驱动性质意味着独立命令的处理可以在整个系统以及单个应用程序进程内并行进行。

因此，应用程序进程的软件架构自然分解为两个主要组件：
- 支持命令和响应内部路由的通用基础设施；
- 应用程序进程提供的特定服务能力的实现。

这些概念蕴含着巨大的复用潜力。星载操作支持软件（OBOSS）系统就是为了利用这种潜力，在构建基于 PUS 的 DHC 软件架构时开发的软件复用框架。

OBOSS 为地面段和星载应用程序进程之间的基于分组的消息传递提供了易于配置的支持。OBOSS 推广的 DHC 架构是松散耦合且自然可扩展的。OBOSS 内的控制流主要是事件驱动的，事件对应于系统中任何源的分组编码消息的到达。OBOSS 内的通信架构是基于邮箱和分组编码消息的星型配置，以分组路由器为中心。分组路由器确定传入消息的目的地，并将分组存入相关应用程序进程的邮箱。OBOSS 为每个应用程序进程提供一个本地分组调度器，从私有邮箱中提取分组并将其传递给相关的服务能力。OBOSS 还允许应用程序进程作为与 DHC 物理分离的星载子系统的通信代理。在这种情况下，驻留在 DHC 中的应用程序进程不包含服务能力，只是将分组转发到相关的远程子系统和从远程子系统接收分组。分组编码消息携带用于在给定应用程序进程内执行某些服务的命令或执行这些服务产生的数据。地面接口组件将来自地面的源 TC 转换为携带相应命令的内部分组，并将其传递给分组路由器。同样，地面接口从分组路由器接收携带发往地面的响应的内部分组，并将其转换为源 TM。

OBOSS 参数配置是将可复用软件构件组装成连贯系统架构的主要方式。OBOSS 参数主要分为三类：
- “终端”：将单个应用程序组件连接到 OBOSS 通信基础设施；
- “属性”：捕获单个组件的特定功能特性；
- “连接器”：封装正在构建的 DHC 系统物理架构的依赖关系。

4.3 使能技术

到目前为止，Ada 83 一直是欧洲航天局绝大多数太空项目的首选编程语言。随着对嵌入式目标的成熟支持的出现，Ada 95 将成为未来项目的自然选择。

选择 Ada 作为使能技术在多个方面与我们追求的高效开发过程模型完美契合。OBOSS 架构包含大量内部事件驱动的并发，需要对其进行控制以提高效率、响应能力和可预测性。OBOSS 消息传递基础设施的松散耦合特性需要高效的异步通信。Ada 对 Ravenscar 配置文件的实现为这两个需求提供了出色的支持。尽管 Ada 泛型在星载系统中很少使用，但它为实现 OBOSS 通用服务能力提供了最直接的方法。服务实例的所需特性可以简单地指定为相关泛型单元的实际参数。我们的实验专门评估了在资源受限的星载嵌入式实时系统中广泛使用 Ada 泛型的实用性。

由于我们的项目具有很强的工业背景，因此使用了支持 Ravenscar 配置文件的 Ada 83 技术。随着新技术的出现，我们还希望评估将 OBOSS 实现过渡到 Ada 95 的好处，因为 Ada 95 具有更强的表达能力和可扩展性支持。

5. 评估

我们最近进行了一项实验，评估以第 4 节所述要素为核心的软件开发过程的性能。实验的想法是让一个第三方团队实现一个符合 PUS 且基于 OBOSS 软件复用框架的新一代 DHC 系统的大部分功能。该第三方团队之前没有 PUS 的相关知识和 OBOSS 的使用经验。

我们选择了几个性能指标，并测量了它们在实验过程中的变化。以下是实验过程中的一些观察结果。

5.1 生产率

我们首先关注的是实验中实现的生产率与工业项目中典型值的对比。实验包括开发、集成和验证一个包含大量 OBOSS 支持的 PUS 服务的应用程序进程。我们测量了生产率，具体数据及分析将在下半部分详细介绍。

以下是 OBOSS 架构的主要组件关系图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    Ground[地面中心]:::process -->|TC| GroundInterface[地面接口]:::process
    GroundInterface -->|内部分组| PacketRouter[分组路由器]:::process
    PacketRouter -->|分组| ApplicationProcess1[应用程序进程 1]:::process
    PacketRouter -->|分组| ApplicationProcessN[应用程序进程 N]:::process
    ApplicationProcess1 -->|分组| Subsystem1[子系统 1]:::process
    ApplicationProcessN -->|分组| SubsystemN[子系统 N]:::process
    Subsystem1 -->|分组| ApplicationProcess1
    SubsystemN -->|分组| ApplicationProcessN
    ApplicationProcess1 -->|响应分组| PacketRouter
    ApplicationProcessN -->|响应分组| PacketRouter
    PacketRouter -->|内部分组| GroundInterface
    GroundInterface -->|TM| Ground

OBOSS 参数分类如下表所示：
| 参数类别 | 描述 |
| ---- | ---- |
| 终端 | 将单个应用程序组件连接到 OBOSS 通信基础设施 |
| 属性 | 捕获单个组件的特定功能特性 |
| 连接器 | 封装正在构建的 DHC 系统物理架构的依赖关系 |

5.2 质量

除了生产率，软件质量也是评估的重要方面。在实验中，我们从多个维度来衡量软件质量，如功能性、可靠性、可维护性和可扩展性。

• 功能性 ：第三方团队实现的应用程序进程需要满足 PUS 标准中规定的各项服务功能。通过详细的测试用例，我们对每个服务功能进行了验证。结果表明，在 OBOSS 提供的通用服务能力基础上，团队能够快速实现大部分功能，并且功能的正确性得到了较好的保证。例如，对于分组的接收、处理和发送功能，经过多次测试，错误率控制在极低的水平。
• 可靠性 ：星载软件的可靠性至关重要。我们通过模拟各种异常情况，如通信中断、数据错误等，来测试系统的容错能力。OBOSS 的设计使得系统在遇到异常时能够进行有效的错误处理和恢复。例如，当分组路由器接收到错误的分组时，能够及时丢弃该分组并记录错误信息，避免影响其他应用程序进程的正常运行。
• 可维护性 ：由于 OBOSS 参数配置的灵活性，使得软件的维护变得相对容易。当需要对某个应用程序进程的服务功能进行修改时，只需要调整相应的参数即可。例如，如果要改变某个服务的优先级，只需要修改对应的“属性”参数，而不需要对整个代码进行大规模的修改。
• 可扩展性 ：在实验中，我们模拟了对系统进行扩展的情况，如添加新的应用程序进程或服务功能。OBOSS 的松散耦合架构使得新的组件能够方便地集成到系统中。例如，当添加一个新的应用程序进程时，只需要将其连接到 OBOSS 的通信基础设施，并配置相应的“终端”参数，就可以实现与其他组件的通信。

5.3 学习曲线

对于没有 PUS 知识和 OBOSS 使用经验的第三方团队来说，学习曲线是一个重要的考虑因素。在实验开始阶段，团队成员需要花费一定的时间来学习 PUS 标准和 OBOSS 框架。我们通过记录团队成员的学习时间和遇到的问题，来评估学习曲线的陡峭程度。

以下是团队在不同阶段的学习情况统计：
| 阶段 | 学习内容 | 平均学习时间（天） | 主要问题 |
| ---- | ---- | ---- | ---- |
| 第一阶段 | PUS 标准基础知识 | 5 | 对 PUS 标准中的一些概念理解困难 |
| 第二阶段 | OBOSS 框架架构 | 7 | 难以理解 OBOSS 各组件之间的交互关系 |
| 第三阶段 | 应用程序进程开发 | 10 | 在参数配置和服务功能实现上遇到问题 |

从统计结果可以看出，团队在学习过程中逐渐掌握了相关知识和技能。随着学习的深入，遇到的问题也逐渐减少。这表明 OBOSS 框架具有一定的易学习性，能够在较短的时间内让新团队上手开发。

5.4 复用效果

软件复用是本次实验的核心目标之一。我们通过分析代码复用率和开发时间的减少来评估复用效果。

• 代码复用率 ：在开发过程中，团队大量复用了 OBOSS 提供的通用服务能力和通信基础设施代码。经过统计，代码复用率达到了 70% 以上。这意味着大部分的基础功能不需要重新开发，大大提高了开发效率。
• 开发时间减少 ：与传统的开发方式相比，基于 OBOSS 框架的开发时间明显减少。在实验中，开发一个包含大量 PUS 服务的应用程序进程，传统方式可能需要几个月的时间，而使用 OBOSS 框架只需要几周的时间。这充分体现了软件复用的优势。

以下是复用效果的对比表格：
| 开发方式 | 代码复用率 | 开发时间 |
| ---- | ---- | ---- |
| 传统开发 | 20% 以下 | 几个月 |
| 基于 OBOSS 开发 | 70% 以上 | 几周 |

6. 总结

通过本次实验，我们对以应用模型、软件复用框架和使能技术为核心的软件开发过程进行了全面的评估。实验结果表明，这种开发方式在生产率、质量、学习曲线和复用效果等方面都具有显著的优势。

6.1 优势总结

• 生产率提高 ：通过软件复用，开发时间大幅缩短，生产率得到了显著提高。
• 质量保证 ：系统在功能性、可靠性、可维护性和可扩展性方面都表现出色，能够满足星载软件的严格要求。
• 学习曲线平缓 ：OBOSS 框架的易学习性使得新团队能够在较短的时间内掌握开发技能。
• 复用效果显著 ：代码复用率高，减少了重复开发的工作量。

6.2 未来展望

虽然本次实验取得了良好的效果，但仍有一些方面可以进一步改进和完善。例如，在使能技术方面，可以进一步研究如何更好地利用 Ada 95 的特性，提高软件的性能和可扩展性。在软件复用框架方面，可以进一步优化 OBOSS 的参数配置机制，提高配置的灵活性和效率。

以下是未来改进方向的流程图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    Start[开始]:::process --> EnableTech[研究 Ada 95 特性]:::process
    Start --> ReuseFramework[优化 OBOSS 参数配置]:::process
    EnableTech --> ImprovePerformance[提高软件性能]:::process
    EnableTech --> EnhanceScalability[增强可扩展性]:::process
    ReuseFramework --> IncreaseFlexibility[提高配置灵活性]:::process
    ReuseFramework --> ImproveEfficiency[提高配置效率]:::process
    ImprovePerformance --> End[结束]:::process
    EnhanceScalability --> End
    IncreaseFlexibility --> End
    ImproveEfficiency --> End

总之，基于应用模型、软件复用框架和使能技术的软件开发方式为星载嵌入式实时软件的开发提供了一种有效的解决方案，具有广阔的应用前景。