星载高可靠性嵌入式数据库系统的设计与实现

张东晨，李文新，贾露娟，夏加高

(兰州空间技术物理研究所，甘肃 兰州 730000)

0 引 言

随着国内航天技术的不断发展，在轨任务日趋复杂，航天器的有效载荷数量、种类以及任务形式越来越多样，对于卫星上分系统或单机的数据管理水平的要求也不断提高[1]。为了实现对数据的规范管理，同时缓解数据存取问题对总的星载计算机带来的压力，设计适用于星载嵌入系统的数据库势在必行。对于星载嵌入式系统来讲，由于其特殊的应用背景，与地面嵌入式设备中应用的数据库系统相比，对于可靠性的要求更高[2-4]。而在现有嵌入式数据库系统中，尚缺乏关于数据存储可靠性的设计与应用。为应对复杂的空间辐射环境、降低由存储器故障而引起的数据出错概率及其对整星的影响[5-6]，可靠性设计必不可少。

目前，星载存储器的可靠性设计大多采用三模冗余方法对数据进行容错纠错处理[7-8]，但这种方法占用内存资源过大，无法在星载嵌入式系统中高效运行。针对这一问题，文中提出将改进的应用于通讯领域的汉明码容错技术[9-11]与星载嵌入式数据库系统相结合，以有效地解决星载数据库应对空间单粒子效应时可靠性不足的问题。

1 传统嵌入式数据库体系结构

传统的嵌入式数据库系统如SQlite[12]、Empress、Berkeley DB等，其体系结构大体相同，主要由以下几个子系统[13]组成：应用API、数据连接层、SQL层、内核级API、数据库引擎、操作系统层和硬件存储介质层。体系结构如图1所示[14]。

图1 传统嵌入式数据库体系结构

与传统数据库相比，虽然嵌入式数据库已经省去了客户机/服务器运行模式带来的开销，但仅一个操作系统便足以占据整个星载嵌入式平台的内存。以高性能的BM3803星载嵌入式处理器[15]为例，其内存资源仅有4兆，即便是最小型的嵌入式操作系统，也无法正常运行。而已有的嵌入式数据库系统无一例外，均需要操作系统的支持，无法满足卫星嵌入式系统对于数据库产品的要求。

2 星载嵌入式数据库体系统的实现

与传统的基于操作系统的嵌入式数据库产品不同，星载嵌入式数据库系统是根据没有独立的服务器进程的UnQLite小型非关系型数据库改写而成，其通过将数据直接读取和写入扇区的方式，将具有多个集合的数据库文件存入统一的磁盘文件中。UnQLite嵌入式数据库的开源代码只提供了UNIX和Windows两个版本，但由于其需要的外部库和操作系统的支持极小，在经过相关的接口配置和冗余功能裁剪后，仅需要文件系统的支持即可完成对数据的存取管理。具有简单、灵活和高效的特点。

2.1 UnQLite嵌入式数据库的体系结构

UnQLite数据库采用的是分层设计的思想，其体系结构如图2所示，主要由以下几个模块组成：文件存储层、键/值存储层、通用存储引擎、底层存储引擎、虚拟文件系统和硬件存储介质。

UnQLite是一个标准的键/值存储数据库，类似于BerkeleyDB，在存储过程中，每一个键/值对都被视为简单的字节数组，其可以是ASCII字符串，二进制数组甚至是磁盘文件。虚拟文件系统层是设计新的数据库系统时最重要的一环，UnQLite使用抽象层与操作系统连接，每个操作系统都有自己的实现方式，并通过unqlite_vfs函数实现UnQLite内核和底层操作系统之间的资源调用。在星载数据库的实现过程中，如何选取合适的文件系统代替原有的操作系统尤为重要。

图2 UnQLite数据库体系结构

Unqlite_open函数中调用了5个函数：unqlite CoreInitialize(内核初始化)、SyMemBackend PoolAlloc(后台内存池分配)、SyZero(参数清零)、unqliteInit Database(初始化内存及事务管理)、SyMemBackend Release(后台内存指针释放)、SyMemBackendPoolFree(后台内存池释放)。

其中unqliteCoreInitialize又调用了5个函数：unqliteExportBuiltinVfs(外部虚拟文件系统指针)、unqlite_lib_config(Unqlite数据库参数配置)、SySetInit(键值集合结构体初始化)、unqliteExportMemKvStorage(内存键值存储所需函数指针)、unqliteExportDisk KvStorage(磁盘键值存储所需函数指针)。

为了适应星载硬件平台的内存需求，文中在省略操作系统带来的开销过程中，实现了外部虚拟文件系统函数指针所指向的函数，需要编写相应的接口函数，使得UnQLite数据库可以在没有操作系统的支持下仅依靠FatFs文件系统完成预定功能。完成UnQLite与FatFs的函数接口的具体方法为实现FatFs文件系统中的OS接口对象中的相关定义。其中OS接口对象是数据库引擎调用文件系统功能和资源的函数接口，数据库引擎通过OS接口对象与FatFs文件系统的应用层建立连接。它们包括：fatOpen、fatDelete、fatAccess、fatFullPathname、fatVfs_Mmap、fatVfs_Unmap、fatSleep、fatCurrentTime。其函数功能如表1所示。

2.2 星载嵌入式数据库的索引实现

(1)键/值存储模型。

该数据库使用键/值存储模型完成对数据的索引和存储[16-17]。与关系型数据库[18]不同，键/值存储模型适合存储不涉及过多关系的数据，同时能有效减少读写磁盘的次数，拥有更好的读写性能。数据库的键/值存储功能函数接口如表2所示。

表1 OS接口对象

表2 键/值存储函数接口

(2)游标迭代器。

游标提供了一种机制，可以通过该机制迭代数据库中的记录。使用游标同样可以搜索，获取，移动和删除数据库记录。在使用游标之前，必须首先使用unqlite_kv_cursor_init()分配新的游标句柄。这通常是应用程序发出的第一个UnQLite游标API调用，并且是使用游标的先决条件。完成后，必须调用unqlite_kv_cursor_release()以通过游标释放已经分配的资源，从而避免内存泄漏。如果需要迭代数据库中的记录，从第一个记录到最后一个记录，只需调用unqlite_kv_cursor_first_entry()并连续调用unqlite_kv_cursor_next_entry()，直到它返回UNQLITE_OK以外的值。与此同时，可以调用unqlite_kv_cursor_valid_entry()来检查光标是否指向有效记录(这将在有效时返回1，否则返回0)。还可以使用游标搜索记录并从那里开始迭代过程。

2.3 虚拟文件系统的接口配置

在文中所述的数据库实现过程中，选用FatFs文件系统替代已有的操作系统层。FatFs文件系统[19]的系统结构如图3所示。在该方案设计中，FatFs[20]的应用层即为改写后的UnQLite嵌入式数据库。FatFs模块与物理设备完全分离，其底层存储设备驱动控制模块需要在实现过程中根据具体的硬件平台进行设计。其平台独立、易于在各硬件平台间进行移植，且指令编译和程序代码占用内存空间很小，非常适合应用于硬件资源受限的星载嵌入式平台上。

图3 FatFs文件系统结构示意

FatFs总共有5个文件，分别是ff.c、ff.h、diskio.c、diskio.h、integer.h。通常情况下，ff.h和interger.h在移植到星载嵌入式平台的过程中不需要进行改动。移植工作主要更改的是diskio.c，配置工作主要更改ff.h和diskio.h。

在星载数据库系统的运行过程中，FatFs文件系统提供的功能主要包括：打开/创建文件、关闭一个打开的文件、从文件中读取数据、将数据写入文件、刷新缓存的数据等。其具体的函数功能如表3所示。

3 可靠性设计

与传统的汉明码在进行数据校验时应满足一定的位数要求不同，假设星载嵌入式数据库系统的汉明码原始数据信息位长为m位，校验位长度为r位，则汉明码在编码解码过程中只要满足以下条件即可。

2K-1≥m+r

(1)

(1)数据编码原理。

首先校验位必须设置在1，2，4，8，16等这些2的整数次幂位。由于UnQLite数据库的每个单元均由两个字节的地址组成，即每16位地址存储一条原始记录，但由于需要加入校验位，因此在写入数据时每8位地址存储一条原始记录，其余空间用以存储校验位信息。

其次，根据偶(奇)性测试的原理来确定校验位的内容。在确定校验位的内容前，先要对数据位进行分组。分组原理为：对所有位的序号位，即对表中1，2，3，4，5，6，7，8，9，10，11，12……位，进行二进制转换并设置为逆序。第一组数据是经过二进制转换后，数据位右边起第1位总是1的数，第二组数据是经过二进制转换后，数据位右边起第2位总是1的数，第三组数据是经过二进制转换后，数据位右边起第3位总是1的数，第四组数据是经过二进制转换后，数据位右边起第4位总是1的数。数据分组后，分别按照各组的顺序对各校验位进行填写，各位校验位顺序对应各组数据的偶(奇)性测试，若数组中“1”的个数为奇数，则填“1”，若数组中“1”的个数为偶数，则填写“0”。

表3 文件系统函数接口

其功能由汉明码写入函数hmfat_Write实现，在写入数据时按汉明码原理进行编码处理，创建两份文件。一份写入的是原始数据，一份写入的是编码后的数据。数据写入分组如表4所示，其中第1、2、4和第8位为校验位。

表4 数据写入分组

(2)数据解码原理。

初始化数据库系统后，调用hmfat_Read函数对数据库存储的数据进行解码输出，每次读取两个字节数据，即16位数据(其中包括8位原始数据位，4位校验位)。

首先对读取的两个字节数据进行偶(奇)性测试，检验写入的数据是否正确，如果正确，则剔除校验位，获取最终8位有效数据。偶性测试原理为：由于写入数据时进行了相应的编码处理，在校验位填写了适当的“0”或者“1”，确保每次校验过程中偶性测试都满足得到偶数个“1”。所以，在读取数据时，对各组数据再次进行偶性测试，如果发现某次这组数据未能得到偶数个“1”，则说明有对应数据位发生错误。对比四组分组数据的出错情况，即可找到出错数据的具体位置，进行“0”、“1”翻转即可。

4 实验验证

文中采用星载嵌入式系统中常用的BM3803嵌入式处理器搭载NAND FLASH存储器为硬件实验平台，但由于BM3803处理器暂时没有配套的显示器，所以文中采用以BM3803为平台的微振动数据采集系统作为星载嵌入式数据库的测试用例。通过对航天器地面测试平台的微振动数据的高频采集、存储和读取，来验证星载高可靠嵌入式数据库实现方案的可行性和正确性。其系统框图如图4所示。

该系统以625 Hz的采样高速频率进行微振动信号采集，然后将3路振动信号写入UnQLite数据库，以键-值格式文件存入FLASH芯片，检索数据库中的3路传感器数据(X,Y,Z)后，通过RS232串口通信将数据上传至PC上位机。其数据采集结果如表5所示。其中加速度值G由分层值经式2和式3计算得出。分层值即为记录在数据库中的原始数据。X为分层值，常数32 767为分层值满量程，V为电压值。

(2)

G=V*γ

(3)

图4 微振动系统采集系统框图

通道名称次数分层值(-32766～32767)G/mg人为造错(原始数据位1位出错)实际数据X1-82322.010否2.010X2-81001.980否1.980………………………………Y1-8725-2.130否-2.130Y2-8580-2.095是-2.095…………………………......Z151501.257否1.257Z256521.380否1.380………………………………

其中Z轴传感器约20秒微振动数据采集结果如图5所示。

图5 微振动数据测试结果

从Z轴微振动数据的检索测试结果来看，数据库进行高频存取后的数据与实际振动测量数据结果相同，在单个数据位出错的情况下，能自动检错并纠正错误信息，说明该微振动测量系统完成了对星载数据库系统的检索查询功能，实现了嵌入式数据库读和写操作，并且具备较高的数据存储可靠性。与其他实时多任务系统(uC/OS、linux、FreeRTOS)集成的嵌入式数据系统相比，基于UnQLite的星载嵌入式数据库与文件系统直接对接，系统结构更简单，对外部资源利用更为合理，可以满足卫星数据的存取要求。

5 结束语

虽然目前世界上主流的数据库产品很多，但还没有将其应用在航天器嵌入式系统上的案例，其主要原因在于星载嵌入式平台大多采用结构简单但可靠性高的处理器，此类处理器内存资源受限，无法直接运行已有的数据库产品。同时，在现有的数据库产品中，均缺乏对于提高数据存储可靠性的设计，这使得数据出错无法自动恢复，不适合在复杂的空间环境中应用。文中提出的高可靠性星载嵌入式数据库系统很好地解决了上述两个问题。该数据库接口配置规范简单，使其不受平台限制，极易在不同硬件间移植。经过反复的实验验证，该方案正确可行，同时为航天器数据管理这一领域的相关研究具有一定的参考价值。