52、航空航天软件的开发与应用：OBOSS框架与飞行控制软件的实践探索

原创于 2025-07-24 10:34:30 发布 · 662 阅读

27 ·

CC 4.0 BY-SA版权

文章标签：

#OBOSS框架 # 飞行控制软件 # 航空航天软件开发

航空航天软件的开发与应用：OBOSS框架与飞行控制软件的实践探索

1. OBOSS框架实验分析

在航空航天软件的开发中，OBOSS框架的应用受到了广泛关注。本次实验聚焦于该框架在软件开发过程中的表现，特别是在软件生产率、内存大小需求、CPU负载需求和任务密度等方面。

1.1 软件生产率

实验以团队每小时交付的新源Ada语句数量来衡量生产率，且排除了实验系统中未改变的定制软件部分。这是因为OBOSS框架占实验系统总大小的70%以上，团队在实验期间难以完全掌握该框架，所以不能将其视为真正“交付”的部分。即便如此，实验仍观察到生产率显著提高，主要归因于以下两个因素：
- 增量过程减轻了团队的负担。
- 采用OBOSS架构框架减少了设计和集成工作。

实验生产率与传统开发和近期商业项目的生产率对比情况如下：
软件生产率对比

1.2 内存大小需求

OBOSS重用框架对系统内存大小需求产生了影响。代码大小的膨胀是重用计划不可避免的“弊端”，在本次实验中也不例外。以下是基于OBOSS的实验系统与功能可比的传统DHC实现的代码大小对比：
| 组件 | 传统DHC（16位CISC） | OBOSS - 基于DHC（32位RISC） |
| ---- | ---- | ---- |
| Ada运行时 | 4,308 | 73,404 |
| 内核服务 | 21,470 | 53,313 |
| 通信服务 | 6,492 | 76,112 |
| 应用层 | 18,788 | 79,028 |
| 总计 | 51,058 | 281,856 |
| 膨胀率（归一化） | 1.00 | 1.84 |

传统DHC考虑的是16位CISC空间处理器的代码分解，而OBOSS - 基于DHC是在新一代RISC空间处理器上的实验实现。实验将观察到的大小增加归一化到从16位CISC到32位RISC的“自然”膨胀率（通常约为3.0）。

1.3 CPU负载需求

OBOSS重用框架对系统CPU负载预算也有影响。由于传统DHC基于固定循环调度，而OBOSS采用抢占式调度，因此确定等效负载场景较为困难。实验考虑了“最坏情况”负载和“实际”负载，并与OBOSS - 基于系统的最坏情况静态分析和实际执行结果进行对比。以下是归一化CPU功率比（估计为32位RISC比16位CISC高6倍）后的结果：
| CPU负载 | 传统DHC（16位CISC） | OBOSS - 基于DHC（32位RISC） | 膨胀率（归一化） |
| ---- | ---- | ---- | ---- |
| 最坏情况 | 26.70 | 8.23 | 1.85 |
| 实际 | 7.01 | 7.54 | 6.45 |

1.4 任务密度

在OBOSS实现中采用Ravenscar配置文件自然提高了系统的任务密度。虽然计算模型的表达能力和语义内容确保了对并发的完全控制，但明确OBOSS - 基于系统产生的任务数量界限至关重要。相关定义如下：
| 符号 | 含义 |
| ---- | ---- |
| TP | 总任务数量 |
| CF | 通信框架组件 |
| AC | 应用程序接口组件 |
| SF | 服务框架描述符 |
| AS | 应用程序服务描述符 |

总任务数量TP(m)的计算公式为：
[TP(m) = CF + AC + SF × AS × Im]
其中：
[SF =
\begin{bmatrix}
3 & 2 & 2 & 1 & 1 & 1 & 0 \
4 & 2 & 3 & 1 & 1 & 1 & 1
\end{bmatrix}
]
[CF =
\begin{bmatrix}
3 \
7
\end{bmatrix}
]
[AC = m ×
\begin{bmatrix}
1 \
2
\end{bmatrix}
]
[AS =
\begin{bmatrix}
e_{1,1} & \cdots & e_{1,m} \
\vdots & \ddots & \vdots \
e_{6,1} & \cdots & e_{6,m} \
n_1 & \cdots & n_m
\end{bmatrix}
]
其中，(e_{i,j})表示应用程序(AP_j)是否嵌入服务(i)（1表示嵌入，0表示未嵌入），(n_j)是应用程序(AP_j)使用的数据包存储数量，(Im)是([m × 1])的单位矩阵。

通过该公式可以轻松确定符合PUS的OBOSS - 基于DHC系统的任务数量下限和上限。下限在系统由一个不嵌入PUS服务的应用程序组成时取得，上限在系统中每个应用程序都嵌入OBOSS支持的所有PUS服务时取得。

2. 飞行控制软件的开发

飞行控制软件的开发面临着诸多挑战，特别是在软件架构和设计方面。以下将介绍飞行控制软件的应用领域以及相关的设计概念和方法。

2.1 飞行控制应用领域概述

飞行控制软件主要应用于飞行控制系统（FCS）和飞行控制计算机（FCC）中。典型的飞行控制系统架构包括飞行员输入、传感器、数据总线、执行器和飞行控制计算机等部分，如下图所示：

飞行控制计算机的硬件架构通常包含共享内存、多个应用处理器和I/O处理器，示例如下：
飞行控制计算机硬件架构

飞行控制律是飞行控制软件的核心，其简化框图展示了基本组件、数据流程以及输入输出关系，如下图所示：
飞行控制律简化框图

飞行控制律的主要输入包括飞行员操纵装置、气流角度、速率和加速度、空气数据以及配置数据等。

飞行控制计算机中的软件包含多种功能，具体如下：
- 输入/输出（I/O），支持多种I/O通道。
- 空气数据计算。
- 控制律软件。
- 冗余管理。
- 内置测试软件。
- 其他“FCC系统服务”，如硬件初始化、中断处理、看门狗和自检服务、定时和同步服务、处理器间通信服务以及地面和飞行测试支持软件。

控制律软件又可进一步细分为以下组件：
- 从外部环境输入控制律数据。
- 控制律计算。
- 向外部环境输出控制律数据。
- 控制律测试支持。
- 帧调度器，根据定时要求调度控制律活动。

2.2 设计概念和方法

为应对飞行控制软件的复杂性，采用了多种设计概念和方法，即“COLAda方法”，具体包括：
- 平台独立的控制律软件 ：目标是使控制律软件能够在不同硬件平台和运行时环境中运行。为此，需要在设计和实现过程中采取以下方法：
- 识别软件中与环境相关的部分，并将其与独立于环境的核心部分隔离。
- 设计适用于所有预期环境的通用软件架构。
- 使用Ada语言编写控制律软件，避免使用语言的实现依赖特性。

COLAda软件可运行的五种运行时环境如下：
COLAda运行时环境

面向对象技术 ：利用面向对象的特性，提高软件的可维护性和可扩展性。
可重用组件 ：开发可重用的组件，减少重复开发工作。
设计模式 ：应用设计模式，优化软件结构。
多处理器目标的软件设计 ：针对多处理器目标进行软件设计，提高系统性能。

综上所述，OBOSS框架在提高软件生产率方面表现出色，但也带来了内存和CPU负载增加等成本。飞行控制软件的开发则需要综合运用多种设计概念和方法，以满足其复杂性和安全性要求。在实际应用中，需要根据具体项目需求权衡利弊，选择合适的技术和方法。

3. OBOSS框架与飞行控制软件的综合分析

3.1 OBOSS框架的优势与挑战

OBOSS框架在软件生产率方面展现出了显著的优势。通过增量过程和采用OBOSS架构框架，团队的开发效率得到了大幅提升，新源Ada语句的交付量相比传统开发和近期商业项目有了明显增长。然而，该框架也带来了一些挑战。

从成本角度来看，内存大小和CPU负载的增加是不可忽视的问题。内存大小膨胀率达到了1.84（归一化后），最坏情况下CPU负载的膨胀率也达到了1.85（归一化后）。对于资源受限的机载嵌入式系统来说，这些成本可能会对项目产生一定的影响。

从技术掌握角度来看，OBOSS框架包含了大量的定制软件，占实验系统总大小的70%以上。团队需要花费一定的时间来掌握其内部结构和操作，这对于项目的进度和资源分配提出了挑战。

3.2 飞行控制软件设计的关键要点

飞行控制软件的设计需要综合考虑多个方面的因素，以确保软件的安全性、可靠性和性能。

平台独立性 ：实现平台独立的控制律软件是飞行控制软件设计的重要目标之一。通过隔离环境依赖部分、设计通用架构和使用无实现依赖特性的Ada语言，可以使软件在不同的硬件平台和运行时环境中运行，提高了软件的可移植性和复用性。
多方面技术结合 ：采用面向对象技术、可重用组件、设计模式和多处理器目标的软件设计等方法，可以提高软件的可维护性、可扩展性和性能。例如，面向对象技术可以使软件的结构更加清晰，可重用组件可以减少重复开发工作，设计模式可以优化软件的设计，多处理器目标的软件设计可以充分利用硬件资源。

4. 技术应用与未来展望

4.1 技术应用建议

在实际项目中，对于OBOSS框架和飞行控制软件的开发，可以参考以下应用建议：
- OBOSS框架应用
- 评估成本效益 ：在决定是否采用OBOSS框架时，需要综合考虑软件生产率的提升和内存、CPU负载等成本的增加。根据项目的具体需求和资源限制，权衡利弊，做出合理的决策。
- 提前规划学习曲线 ：由于OBOSS框架的复杂性，团队需要提前规划学习时间，确保在项目实施过程中能够尽快掌握其技术要点。可以通过培训、技术交流等方式，提高团队的技术水平。
- 飞行控制软件开发
- 严格遵循设计原则 ：在开发飞行控制软件时，要严格遵循平台独立、面向对象、可重用等设计原则，确保软件的质量和性能。
- 加强测试和验证 ：飞行控制软件属于安全关键软件，需要加强测试和验证工作，确保软件的安全性和可靠性。可以采用多种测试方法，如单元测试、集成测试、系统测试等，对软件进行全面的测试。

4.2 未来展望

随着航空航天技术的不断发展，软件在飞行系统中的作用将越来越重要。未来，OBOSS框架和飞行控制软件可能会朝着以下方向发展：

智能化 ：引入人工智能和机器学习技术，使软件能够自动适应不同的飞行环境和任务需求，提高飞行系统的智能化水平。
集成化 ：将更多的功能集成到软件中，实现飞行系统的一体化控制和管理，提高系统的整体性能和可靠性。
安全性提升 ：不断加强软件的安全性设计和验证，采用更加先进的安全技术，如加密技术、容错技术等，确保飞行系统的安全运行。

以下是一个简单的mermaid流程图，展示了飞行控制软件开发的主要流程：

graph LR
    A[需求分析] --> B[设计阶段]
    B --> C[编码实现]
    C --> D[测试验证]
    D --> E[部署应用]
    E --> F[维护升级]

综上所述，OBOSS框架和飞行控制软件在航空航天领域具有重要的应用价值。通过合理应用相关技术和方法，权衡成本效益，加强测试和验证，可以提高软件的质量和性能，为航空航天事业的发展做出贡献。同时，随着技术的不断进步，我们也期待这些软件技术能够在未来取得更大的突破和发展。

总结

本文对OBOSS框架和飞行控制软件进行了详细的分析和探讨。OBOSS框架在提高软件生产率方面具有显著优势，但也带来了一些成本和技术掌握方面的挑战。飞行控制软件的设计需要综合考虑平台独立性、多方面技术结合等关键要点，以确保软件的安全性、可靠性和性能。在实际应用中，需要根据具体项目需求权衡利弊，选择合适的技术和方法。未来，随着航空航天技术的发展，这些软件技术有望朝着智能化、集成化和安全性提升的方向发展。

技术类型	优势	挑战	应对策略
OBOSS框架	提高软件生产率	内存和CPU负载增加，技术掌握难度大	评估成本效益，提前规划学习曲线
飞行控制软件	可移植性和复用性高，性能和可维护性好	设计复杂，安全性要求高	严格遵循设计原则，加强测试和验证