摘要
针对星载综合射频开放式系统架构,为了在软件综合层面上实现波形应用软件与具体平台的解耦,设计并实现了一种基于软件通信架构(Software Communication Architecture, SCA)的软件平台及其环境工具。通过解决星载平台软件的分布式通信、系统重构等技术问题,实现了功能、应用和波形的组件化与动态重构。该软件平台能够满足星载领域信号、信息处理的强实时、高可用的应用需求,有效提升了综合射频系统软件开发质量和集成联试的效率。
0 引言
随着卫星技术的不断发展,星载系统的功能需求日益复杂多样化,传统硬件固定的设计方式已无法满足灵活性和可扩展性的要求。因此,软件定义成为一种被广泛采用的解决方案,以实现星载系统的动态配置和部署。本文旨在设计与实现一种星载系统软件定义平台,该平台能够提供灵活的功能部署、资源管理和故障恢复能力,以满足不同任务和应用场景的需求。
本文首先介绍了星载系统面临的挑战和需求,包括对灵活性、可扩展性和可靠性的要求。然后,对软件定义的概念和优势进行了阐述,包括通过软件定义实现功能的灵活配置、动态调整和冗余备份等特点。接下来,本文提出了一种基于软件通信架构(Software Communication Architecture, SCA)的星载系统软件定义平台设计方案。该平台采用模块化、开放式架构,利用通用的硬件平台实现不同的功能应用,降低系统的体积、重量和功耗。
在设计和实现过程中,本文特别关注软件定义卫星通信载荷平台的两个关键技术问题:通信中间件和系统重构。通过研究和设计高性能、灵活性和可靠性的通信中间件,以实现节点间可靠的数据和控制信息传递。同时,系统重构将系统组件化并提供动态配置和管理能力,以适应不同任务和场景需求。
本文的设计和实现旨在为星载系统提供一种可靠、灵活且高效的软件定义平台,以满足不断变化的任务需求,并为未来的星载系统研究和应用提供有价值的参考。
1 系统架构
1.1 硬件环境
典型的星载综合射频系统硬件架构包括射频前端、功放、收发处理机和管控机组成,如下图所示:
1.2 总体设计
软件定义卫星载荷系统软件架构图如图所示:
软件定义卫星通信载荷软件系统包括嵌入式操作系统、DSP操作系统、星载系统构件化运行环境和星载应用。可重构FPGA上构件的运行管理功能由DSP模块通过总线接口控制。嵌入式操作系统和DSP操作系统分别运行在主控模块和信号处理模块上。
星载系统构件化运行环境以一组开放的API和服务形式,为应用软件提供底层软、硬件的抽象接口。从系统运行管理角度,它实现资源调度、算法加/卸载、运行配置管理、系统资源状态监控等功能。从构件化应用角度,它提供端口连接与断开、应用与构件描述文件的解析、构件定义接口的调用、应用系统管理等功能。构件化运行环境通过对构件接口和通信的约束,实现构件级的生命周期管理,包括在线更新、迁移和功能重构等。
1.2.1 构件化集成部署运行环境
集成部署运行管理框架是构件化运行环境的核心功能部件,为应用软件设计者提供对底层软件和硬件的高层次抽象,提供域管理服务、设备管理服务、应用管理服务、日志服务等功能。
系统资源状态监控服务实时显示系统中的所有节点信息,包括CPU占有率、内存使用率、操作系统核心资源使用情况,以及设备信息、进程信息、应用信息和构件部署情况等。
轻量级分布式通信中间件屏蔽底层通信机制,提供统一消息格式和硬件访问接口,支持同步、异步、单向、双向通信等方式。它为软件提供标准化的C++/C接口通信操作,CPU构件和DSP构件可以使用中间件进行连接和数据交换。
轻量级通信中间件采用面向对象互操作和面向连接的IPC中间件。面向对象互操作中间件基于ReORB进行改造,用于框架内部通信和构件部署。面向连接的IPC中间件基于ReIPC,具有灵活、高性能的进程间通信机制、轻量级协议、透明的消息传递机制,支持多种连接介质,独立于硬件和操作系统,提供丰富的辅助工具如命名服务和发布/订阅模型扩展,以满足复杂系统的通信需求,提升系统的可靠性和性能。
1.2.2 构件化集成部署配套工具
应用集成开发工具与开发环境的工程管理模块相结合,可辅助应用组件的开发过程。它们提供代码编辑、调试、构建和测试等功能,简化了开发流程,提高了效率。运行配置管理工具用于配置系统运行参数和组件的部署重构策略,实现灵活的系统配置。系统资源状态监控工具与资源状态监控服务连接,获取系统资源状态,并通过图形化界面展示。它们实时监测系统的CPU、内存、磁盘等资源使用情况,提供性能指标和警报,助于优化系统性能。这些工具的综合应用增强了应用开发和管理的效能,帮助用户实时监控和管理系统资源,提升星载系统的质量和用户体验。
2 主要技术问题与解决途径
2.1 通信中间件
2.1.1 基于轻量级IPC中间件的通信
2.1.1.1 基于ReIPC通信中间件
通信中间件主要解决基于C/C++语言的构件的通信问题。基于ReIPC通信中间件对ReIPC进行改造,提供高吞吐量低延时的点对点通信。ReIPC中间件架构图:
ReIPC中间件的基本用法如下:
-
加载核心程序:在锐华操作系统启动后调用reipc_init()函数加载ReIPC核心程序。
-
建立物理连接:根据通信需求选择合适的通信介质(如TCP、以太网卡、共享内存),调用相应的初始化函数进行物理连接的建立,并为该连接命名。
-
创建逻辑连接:在物理连接建立后,调用mklink()函数创建逻辑连接,并为该连接命名。
-
应用程序通信:使用reipc_open()函数创建通信节点(endpoint),通过该节点进行通信操作。可以使用reipc_send()函数向对端发送数据,使用reipc_receive()函数接收对端发送的数据。
-
IPC通信信号(Signals):定义信号(Signals)的结构体,并使用reipc_alloc()函数为信号数据包分配内存,填充数据后发送。
-
搜寻通讯节点(Hunt):使用reipc_api_hunt()函数搜寻对端节点,获取对端的SPID。
-
发送数据(Send):使用reipc_send()函数向对端发送数据。
-
接收数据(Receive):使用reipc_receive()函数接收对端发送的数据。
-
监控对端节点(Attach):使用reipc_attach()函数监控对端节点的状态,当对端关闭时会收到一个指定的Signal。
2.1.1.2 基于ReIPC通信协议的FPGA通信
FPGA与FPGA、FPGA与DSP、FPGA与CPU之间的通信可以通过基于映射表的通信规范来进行。在系统部署完成后,通信端口映射表将在域内广播,并由FPGA本地进行维护。核心框架会依据配置和注册信息,维护该映射表,确保逻辑名称和逻辑标识与唯一的物理端口信息对应。系统通信有两种方式:一是基于分布式中间件,适用于支持操作系统的处理单元;二是基于映射表,适用于不支持操作系统的处理单元如FPGA。用户只需关注通信两端的逻辑ID,无需关注实际的物理端口。逻辑ID与物理端口的映射表将在应用部署完成后生成。
2.1.1.3 ReIPC底层通信协议
锐华ReIPC中间件提供了一种用于层级快速增长的异构系统中的进程间通信的解决方案。这些异构系统混合了不同的操作系统、CPU、微控制器DSP以及传输媒介,如共享内存、RapidIO、千兆以太网或网络协议栈。在这种体系结构中,一个CPU上的通信终端通常采用与本地平台相关的特定IPC机制,这种机制很少适用于运行其他操作系统的平台。传统的分布式IPC方法,如TCP/IP,运行成本高,而且TCP/IP协议栈可能不适用于小型系统如DSP。
为了解决这个问题,锐华ReIPC提供了一种单一的IPC机制,适用于整个分布式异构混搭系统中的本地通信和远程通信。它允许不同平台之间进行无缝通信,并提供高效的消息传递机制。通过使用ReIPC,系统可以避免在不同平台之间进行复杂的通信适配和转换。它提供了低延迟、高带宽的通信能力,满足系统组件对大流量承载能力的性能需求。
ReIPC还支持多种通信介质,包括共享内存、RapidIO、千兆以太网和网络协议栈,使其能够适应各种连接方式。它可以灵活地扩展到大型系统,并支持任意拓扑结构,使分布式系统能够实现平台间的相互独立连接。
总之,锐华ReIPC中间件为层级快速增长的异构系统提供了一种高效的进程间通信解决方案,满足了系统组件对大流量承载能力的性能需求,同时兼容不同操作系统、CPU和传输媒介,为分布式系统的通信提供了便利和灵活性。其体系结构如图所示。
锐华ReIPC协议栈包括两个层级:链路处理(LH)层和连接管理(CM)层。LH层对应OSI模型的会话层,负责实现IPC功能,包括通过名称查找通信终端的命名服务和异步通知通信终端关闭的链接监控。CM层对应OSI模型的传输层,实现了可靠有序传输任意大小消息的机制,并根据不同的传输媒介使用不同的CM协议。
LH层负责解析远程通信终端的名称,并建立和删除远程通信终端的本地代理。它还提供了通信终端OS标识(OS IDs)的转换机制,用于源端到目的端系统之间的通信。此外,LH层处理本地操作系统与应用程序之间通过ReIPC消息服务进行的交互。LH层由一个通用的OS无关协议模块和一个与特定操作系统交互的OS适配层组成。
CM层为LH层提供可靠的传输机制。对于非可靠传输媒介(如以太网),CM层必须实现流控和重传机制以应对丢包情况,并提供对端监控机制,从而增加了复杂性。而对于可靠传输媒介(如共享内存和RapidIO),CM层可以简化处理。
通过以上两个层级的结合,锐华ReIPC协议栈能够提供高效可靠的进程间通信解决方案,适应不同传输媒介和异构系统的需求。
2.1.2 基于对象互操作通信中间件的通信
miniReORB是一个轻量级CORBA通信中间件,它是在ReORB的基础上进行了轻量化改造而形成的。miniReORB具备支持多通道通信的能力,这意味着它可以在分布式系统中通过多个通道进行高效的进程间通信。通过这种改进,miniReORB提供了一种更灵活、更高效的CORBA通信解决方案,适用于资源受限的环境或对性能要求较高的应用场景。
2.2 系统重构
2.2.1 系统重构概述
系统根据不同的资源和任务情况,使用不同的映射或配置方式,通过应用部署蓝图实现系统重构。导致系统发生配置和重构的因素包括任务规划改变工作模式、部分硬件或软件故障以及系统更新、测试和维护。
无论是哪种系统重构,都需要对系统配置和重构过程进行清晰的定义,以便在系统运行的任何阶段都能明确系统所处的状态。同时,在对系统进行重构时,需要综合考虑冗余、空闲资源、运行模式、任务优先级、降级配置等因素的限制,对重构的条件、动作和约束进行规范。预先定义系统各种工作模式的配置状态以及各配置状态之间的转换条件,并对各种策略进行仿真和覆盖性测试。
系统重构的定义依赖于重构规则,重构规则由一系列指令和数据信息构成的重构操作列表组成,描述了系统重构的处理准则。重构规则包括重构时资源的选择原则和故障时的优先级策略等,是整个系统资源分配策略的核心。在重构规则的约束下,软件蓝图、硬件蓝图和应用部署蓝图有机结合,使系统重构能够适应承载各种不同功能组件,将功能模式所需的软件能力映射到具体的硬件模块上运行,从而实现不同的任务模式。
重构规则可分为两种类型:标准重构规则和故障重构规则。标准重构规则适用于正常功能软件重构,针对所有软件组件,从系统硬件CPU、DSP和FPGA模块中选择目标处理器进行部署。故障重构规则适用于系统硬件CPU、DSP和FPGA模块发生故障时,重新选择部署软件构件的目标处理器。
系统重构的标准规则包括以下要点:模块必须处于加电且正常工作状态;处理器类型需符合软件模块要求;处理器当前的处理能力和内存要满足软件构件的需求;模块当前的通信接口速率要满足软件构件的要求;优先选择负载较轻的模块;优先选择编号较小的模块;若仍然没有可用资源,则返回加载失败信息并报告失败原因。这些规则确保了系统重构过程中的资源选择和配置满足要求,从而保证系统的稳定性和性能。
系统重构的故障规则包括以下要点:只选择加电且正常工作的模块;处理器类型必须符合软件模块要求;处理器当前的处理能力和内存要满足软件构件的需求;模块当前的通信接口速率要满足软件构件的要求;优先选择备份模块;优先选择与故障模块型号相同的模块;若仍然没有可用资源,则返回加载失败信息并报告失败原因。这些规则确保了故障时软件构件的迁移和重新部署满足要求,从而维护了系统的可靠性和连续性。
以上是系统重构的基本概念和重构规则的描述。通过清晰的系统配置和重构设计,结合不同的资源和任务情况,可以有效实现系统的重构和优化。
2.2.2 系统重构流程
管控机运行系统中,综合管控软件和框架管理软件集成配合完成系统功能模式的重构,包括规划、故障和维护重构。
2.2.2.1 规划重构
规划重构是在工作模式改变时进行的重构,也可以称为"工作模式切换"。系统综合管控软件承担两个主要任务:一是接收上层指令,发起功能重构并指定框架管理软件的重构工作模式;二是收集重构节点的硬件设备状态,并将设备状态信息发送给框架管理软件作为重构方案制定的参考。框架管理软件根据重构模式指令,检索和验证存储设备中相应的软件蓝图,结合硬件设备状态信息,按照重构规则分析资源是否满足软件重构部署的需求,并控制完成功能重构。在系统运行期间,综合管控软件可以查询系统中蓝图的部署情况,而框架管理软件需要向综合管控软件报告重构完成情况和相关日志信息。
2.2.2.2 维护重构
为提高软件部署效率,系统在维护和测试阶段需要具备加载(替换)软件蓝图中单个软件构件的能力。维护重构是在系统进行更新、测试和维护时发生的重构,它不会改变现有的工作模式和部署状态,也可以称为"工作模式的更新"。维护重构通常由测试控制台发起,控制台将需要重构的构件代码和维护重构指令发送给框架管理软件。框架管理软件根据指令,在当前系统正在运行的功能模式中找到需要维护和测试的软件构件,并替换相应的构件。然后,框架管理软件重新建立构件间的逻辑连接,按照蓝图实现故障重构。通过这种方式,系统能够在维护和测试阶段高效地加载和替换单个软件构件,以保证系统的稳定性和功能的完整性。
3 结论
本研究针对星载射频综合一体化软件设计,深入探讨了其中的关键技术问题。重点讨论了通信中间件和系统重构的技术原理及其实现方法。通过采用开放式软件架构和符合SCA规范的软件平台,成功构建了一个标准、开放、可互操作的波形运行环境。该环境具备波形移植、重构和加载卸载管理的能力,可支持异构平台之间的无缝集成。已经在多个项目中应用的软件平台有效提升了综合射频系统软件开发质量和集成效率。通过本研究,为星载射频综合一体化软件设计提供了有益的技术参考和实践经验。