一种低耦合可移植的嵌入式主控软件架构设计

赵兴祥，赵 涛，唐 瑜，黄 华，彭 湖

（重庆金美通信有限责任公司，重庆400030）

1 引 言

嵌入式系统因其的裁剪性强、可靠性高、实时性好、能耗低等特性，被广泛应用在电子、通信、医疗等各行业中。随着互联网、5G、物联网等技术的快速发展，嵌入式系统呈现出了系统化、生活化、网络化、精简化等发展趋势[1]。在此背景下，稳定、易扩展、兼容性好的嵌入式软件架构是高水准嵌入式软件设计的可靠保障，也是嵌入式产品的性能及稳定性的重要决定因素。现有研究大多集中于此，但并不完善，例如：文献[2]中提出的软件架构，通过线程管理、备份硬件唤醒、通信协议设计等手段增强软件的可靠性和稳定性，但在移植性、扩展性方面的设计还不充分；文献[3]中通过扩展Bios 设计提高嵌入式系统的可靠性，但没有在扩展性、兼容性方向做出设计；文献[4]设计并实现了基于通信中间件的综合化信号与信息处理机软件架构RCSSystem，采用直接数据包通信方式取代了CORBA 中间件的远程函数调用，通过总线互连，增强系统的稳定性和可靠性，但架构复杂，与硬件、驱动层耦合性大；文献[5]中给出了基于多任务的实时处理架构设计方法，但仍存在硬件耦合性大的问题。

针对嵌入式系统耦合高、扩展性不足的现状，在此设计一种低耦合、可移植、易扩展、支持热插拔的嵌入式设备主控软件架构。

2 软件架构设计

2.1 总体架构设计

结合 SOA（Service Oriented Architecture）思想及分层思想，将软件定义为服务，服务之间通过轻量化通信中间件进行整合[6]，各服务以插件的方式独立运行于系统中，可以根据需求动态加载或卸载各功能模块，以满足用户业务、服务及性能的扩展性要求。软件总体结构如图1。

图1 软件总体架构图

结合嵌入式系统平台，核心管理服务、通信中间件及硬件抽象层构成了服务的基础，形成物理层、MAC 层、网络层以及安全等多种类的标准接口服务组件，其详细架构如图2 所示。

图2 软件架构图

2.2 核心管理服务

核心管理服务是整个架构的基础服务，作为独立进程，主要用来实现整个软件框架的模块（组件）管理和消息（类似参数）管理。

2.2.1 模块管理

模块管理负责对各服务模块的加载/卸载过程及服务组件状态等进行管理与监控，对外提供模块注册注销、模块状态查询及状态主动汇报等标准接口。模块管理的运作机制如图3 所示。

图3 模块管理服务结构图

当某个服务启动时，先调用注册接口向模块管理注册。模块管理将该服务加入管理链表后，开始启动监控机制。监控方式可以是由服务程序主动状态汇报，也可以是模块管理周期地查询状态。服务需要退出时，要先调用注销接口脱离模块管理。

2.2.2 消息管理

参数管理是参数（状态及配置参数）的集合，包含参数的定义与操作。消息管理对消息的订阅、发布、可靠性保证等进行管控，与参数具体含义无关。参数管理配合消息管理，实现配置消息的检查、存储与初始化。

服务完成注册后，向消息管理模块订阅该服务启动及运行过程中所需的全部参数。消息管理将该服务所订阅的参数记录到参数订阅列表，并通过参数管理模块获取参数值后，发给消费者服务程序。如果某个参数值被修改，参数管理依据参数订阅列表分发给各服务模块。消息管理的体制如图4。

图4 消息管理服务结构图

路由拓扑、信道质量等实时且不需要保存的信息，由提供者主动发布，消息管理按需分发给服务消费者。

这一设计的思想是：参数管理只需关注初始化配置参数，设备状态信息无需初始化，由供方服务主动发布；设备新增的参数，只需信息提供方、需求方自行订阅分发即可，核心管理模块无需做任何更改。

2.3 通信中间件

本架构中，服务间通信均通过通信中间件来实现。借鉴SCA 思想，通信中间件类似CORBA（Common Object Request Broker Architecture）的对象请求代理ORB。中间件以库文件的形式集成到服务软件中，通过宏定义选择编译，可广泛移植于不同操作系统平台。一般情况下，作为独立的线程运行在各个调用服务中，在没有操作系统的CPU 上，中间件可以是一个接口封装。

通信中间件的功能包括：

1）自动完成通信目标的查询及信息可靠传输；

2）为宿主程序提供同步、异步消息传输保障；

3）记录各个模块的通讯地址而无需每次发送消息重复查询服务。

通信中间件的工作流程如图5。

图5 通信中间件工作流程图

假设有服务A、B，在相互不知道对方是否存在的情况下，服务A 需要向服务B 发送业务时，服务A 向通信中间件发起试探，并从中间件获得服务B的通信接口信息，随后，即可向服务B 发起业务。通信的可靠性由通信中间件来保障。服务B 向服务A发起业务时，也是相同的操作。

通信中间件对外提供的接口如图6 所示。

图6 通信中间件结构图

消息中间件的创建由服务调用发起，服务需为通信中间件提供接收消息的回调函数。消息中间件的同步发送接口会阻塞服务进程，异步发送接口要求服务提供回调函数。

2.4 平台基础服务

平台基础服务包括日志服务及调试打印服务两个基本服务和系统资源抽象服务。

(1) 日志服务

日志记录了包括各服务启动、异常现场、系统资源使用情况等重要信息[7]。日志服务的数据在内存中汇聚，周期性更新并保存到flash 上。

日志服务对外提供日志输入与日志显示两种标准接口。外部程序按照接口要求调用获得日志服务。日志服务的构建如图7 所示。

图7 日志服务结构图

(2) 网络调试打印服务

网络调试服务提供基于优先级的、支持本地/远端信息输出的服务[8]，结构如图8 所示。

图8 网络调试打印服务结构图

调用print_config 标准接口启动调试打印服务，并配置优先级、输出目标IP 等参数。通过xPrint 接口打印自定义的输出格式数据。

(3) 系统资源抽象服务

服务对平台IPC（Inter-Process Communication）、信号、串口等系统资源进行抽象化，将其封装成标准的服务接口，无差别地为其他服务（包括通信中间件）提供支持。

2.5 公共应用服务

公共应用服务是指一般嵌入式通信设备均需要的一般服务，如人机交互服务、网络管理服务、软件维护服务、测试支撑服务等。

架构支持 LED 显示屏、WEB、控制台命令（Shell）等多手段的人机交互方式，形成标准的接口对外提供调用服务。类似于以操作为对象，对外提供不同的网络管理服务接口，为上层应用或服务提供网络管控手段。

软件维护服务主要是指软件升级，涉及的场景共有三种，归纳于图9 中。

图9 软件维护的三个场景

网络中有服务器时，设备与服务器中的软件进行版本检测对比，不是最新版本则从服务器下载最新的软件进行升级。没有服务器时，设备之间自主进行软件版本匹配，如果设备之间软件版本不一致则从最新版本设备中下载新程序进行更新升级。

架构中的测试支撑服务是一个集中处理可测试性的接入窗口服务。设备软硬件可测试性主要由具体的硬件、软件模块提供支撑。

硬件可测试性支撑服务需要做到：提供各项硬件测试、检测的执行过程，并返回测试结果的自动测试功能；提供自动跳转参数以满足性能指标的自动校准功能。软件可测试服务，指的是提供各项测试的测试用例、测试指令输入口及执行测试用例功能。

测试支撑服务整体结构如图10 所示。其具备的功能包括：

①支持测试指令、校准指令输入；

②支持调试指令输入；

③具备测试、校准操作执行过程集合。

该服务对外提供输入接口，可按照既定输入规范，对软硬件模块进行状态更改、控制及故障定位等进行测试与调试。

图10 测试支撑服务结构图

3 平台适应性分析

本设计选用的软件架构，适用于Linux 系统下ARM、PowerPC、X86 等平台的嵌入式设备开发。核心管理服务在开发过程中，考虑程序移植性，支持多平台的编码设计，以宏定义的方式，针对不同的硬件平台进行编译选择。考虑Linux 的内核态和用户态特性，在内核态中，通过自定义标准函数指针的形式，对外提供注册注销以及数据发送接口，其他软件模块动态注册时提供其数据接收接口；应用态模块间通过套接字进行模块间的数据传输。

本架构下的服务，应用态下以.so 文件存在，内核态下以.ko 文件形式存在。核心管理程序根据用户需求，动态调用、加载相应服务程序；用户结束服务后，杀死或卸载对应的服务，减轻CPU 的负载压力。依据Linux 系统可剪裁的特性，可根据嵌入式设备不同的应用需求，调整Linux 系统的实时性、抢占式参数，对架构中各模块的优先级进行设置，提高架构在各平台下不同应用场景的适配性。

4 结束语

结合嵌入式系统的应用背景，针对嵌入式设备可热插拔、按需扩展、广泛移植应用的需求，设计了可通用的主控软件架构。该软件架构基于SOA 思想进行设计，具有松耦合、易扩展、可移植、平台无关等多个特点，已在多个项目和设备上实际应用，软件的耦合性、扩展性、移植性均得到充分验证，也可较好地适用于SCA、SDN 等技术的应用环境，具有良好的实用性和应用前景。