双星定位系统是我国自主开发的定位导航系统，它的用户手持终端对实时性要求高，考虑到价格以及开发周期的因素，用户机系统软件的开发选用了具有国内自主知识产权的DeltaOS.
DeltaOS有专门的集成开发环境LambdaIDE，能够方便地编辑代码、构建、下载、调试和移植。本系统的系统软件在DeltaCORE内核上构建，选择采用C语言编写，来提高软件的执行效率和可读性；图形界面基于DeltaGUI设计，采用C++编写，以缩短开发周期。该系统软件设计的重点在于稳定性和可靠性，关键和难点在于实时性的保证。作为一个完善的系统，软件功能的可扩展性也是必不可少的。本文从总体设计入手，针对性地解决了以上问题。
1 系统功能
双星用户机是一个定位和通信终端，它除了必须完成定位、通信功能外，还需要有友善的人机交互界面以及测试设备接口。嵌入式系统和外设之间的关系如图1所示。
嵌入式系统的硬件平台是通用性的平台，算法实现和设备各部分的协调控制都由嵌入式软件来实现。软件部分需要完成的具体功能有：界面输入输出控制、入站数据段打包、入站信息加密、入站帧打包、出站帧拆包、出站信息解密和提供测试接口。
2 提高系统的实时性
2.1 任务划分的优化
在设计一个较为复杂的多任务应用时，进行的合理的任务划分对系统的运行效率、实时性和吞吐量影响极大。任务分解过细会引起任务频繁切换的开销增加，而任务分解不够彻底会造成原本可以并行的操作只能按顺序串行完成，从而减少了系统的吞吐量。
在将一个软件系统分解成并行任务时，主要需考虑的是系统功能的异步性。分析数据流图中的变换，确定哪些变换可以并行，哪些变换在本质上是顺序的，通过这种方法，划分出任务：一个变换对应一个任务，或者一个任务包括几个变换。一个变换是应该成为一个独立的任务，还是应该和其他变换一起组成一个任务，本软件中遵循了H-Gomma原则[1]，即：
①I/O依赖性原则
②时间关键性原则
③大计算量原则
④功能内聚
⑤时间内聚
⑥周期性原则
本系统的软件分为应用软件和系统软件两大部份。应用软件部分位于系统软件上层，它完成图形界面的输入及显示功能。应用软件部分具有处理时间长、实时性要求不高和不存在并行性的特点，因此作为一个GUI任务并且赋予最低优先级。系统软件需要完成所有出入站信息处理，处理过程复杂，实时性要求高，顺序处理显然不能满足要求，因此必须进行任务划分优化。
图2为入站信息处理的数据流图，图3位出站信息处理的数据流图。
根据I/O依赖性原则，直接和I/O设备打交道的功能都应该成为独立的任务，因为它的运行速度受制于与它交互的I/O设备的速度。在入站流程中，向IC卡发指令、接收IC卡响应信息和送入站数据帧至基带均存在I/O操作，应该独立划分为一个任务。同理，出站信息处理过程中的主通道数据读取、次通道数据读取、向IC卡发指令和接收IC卡响应信息分别划分为独立的任务。
图2 入站信息处理数据流图
图3 出站信息处理数据流图
根据功能内聚原则，功能紧密相关的变换组成一个任务，它们共享资源或相同事件的驱动。定位数据段打包和通信数据段打包具有相似功能，它们均由有效输入的指令触发，可以合并为一个数据段打包任务，针对不同类别的请求使用不同的功能模块来处理。这样，当系统需要增加新的功能时只需在该任务中增加相应的处理模块即可，可扩展性得到了保证。
根据时间内聚原则，同一时间内完成的功能，即使这些功能不相关也可组成一个任务。数据段的打包在输入指令解释完成之后立即被处理，在时间上具有连续性，合并成一个任务可以减少任务间通信开销，有利于提高系统实时性。
主通道数据帧拆包、次通道数据帧拆包和入站数据帧打包的运算量大，适合作为独立的任务。然而，主通道和次通道出站数据帧格式相同，完全可以共用一个任务：出站帧数据拆包。
虽然加密指令打包和解密指令打包分别处于入站信息处理流程和出站信息处理流程，但是它们同属IC卡指令打包，具有很强的功能内聚性，合并为一个任务共用IC卡驱动。
任务重新划分如图4所示。优化之后，不但系统软件实时性和可扩展性得到增强，而且由于充分的代码重用，代码尺寸减小，节省存储空间。
图4 优化后的出入站任务划分和数据流图
2.2 中断优化
任务的切换是由操作系统来调度的，操作系统的干预会浪费CPU时间。特别是对于时间关键性很强任务，例如基带主通道数据读取、次通道数据读取、向IC卡发指令、接收IC卡相应信息任务，频繁的任务调度会使系统的效率低下。因此，这些处理直接由中断服务子程序来完成。
虽然中断服务响应速度快，但是当一个中断服务执行时，其它同优先级或较低优先级的中断以及任意优先级的任务均得不到执行。因此如果中断服务所占用的时间过长，同样会降低系统的实时性。
为了提高系统的实时性，本系统软件在中断处理上主要做了以下两方面的优化：
①中断优先级设置的优化，将触发频率高的中断和重要的中断设为高优先级来保证其及时响应。
②关中断时间应该尽可能地小，ISRs只完成一些必要的操作，如：输入数据、输出数据或将控制信息传递给任务，对中断的进一步处理通过任务来完成[2]。
3 可靠性保证和可扩展性的提高
对于任何软件来说，可靠性都是至关重要的。软件的可靠性在任务内是容易做到，通常问题都是出在任务间的接口之上。接口设计也关系到软件可扩展性能。在多任务操作系统中，任务间的接口是通过同步和通信机制来实现的，因此同步和通信机制必须认真选取。
DeltaCORE提供了消息队列（message queue）、信号量（semaphore）、异步信号（signal）、事件（event）这四种通信和同步机制。其中，消息队列和事件机制可以同时实现通信和同步，信号量机制可以实现同步和互斥，异步信号（又叫软中断机制）可以实现同步。
为了满足系统通信和同步的需要，可以采用两种方案：第一种方案是信号量等同步机制实现同步，用全局数组或其他的共享数据结构来实现各任务间的通信，如图5；另一种是采用消息队列来同时实现通信和同步，如图6。
对比两种方案，各有优缺点：方案一实时性强，但存在可重入性问题；方案二实现简单而且可靠，但是消息队列机制通信的实时性相对较弱。本系统中出站信息的突发性强，如果采用方案一，则可能导致第二个通道的数据失效或者第一个通道的数据被覆盖；如果采用方案二虽然数据的处理延时稍大，但是数据能够完整存储到消息队列中不被损坏。此外，利用消息队列为任务提供唯一的入口，能简化接口设计和方便功能扩展。因此，本文采用消息队列方案，其实现方法如下：
每个任务都对应一个消息队列，任务只处理与之相对应的消息队列中的消息。对于发送方（task1），当它需要将发送缓冲区buffer中的数据交给task2处理时，只须将buffer中的数据发送到与task2对应的消息队列Q2中就行了。
ret = delta_message_queue_send ( Queue_id[ 2 ], buffer, size );
其中Queue_id[2]为消息队列Q2的ID，size为消息大小（单位字节）。
对于接收方（task2），将接收消息函数的等待时间参数设为永久等待，达到当消息队列为空时阻塞任务的目的。task2的代码如下：
delta_task task1()
{
delta_status_code ret;
…… // 定义其他局部变量
while(1)
{
ret = delta_message_queue_receive(
Queue_id[ 2 ], /*消息队列ID*/
RecBuff, /*指向接收缓冲区的指针*/
&size,/*接收消息的尺寸(单位字节)*/
DELTA_DEFAULT_OPTIONS, /*属性集*/
DELTA_NO_TIMEOUT /*等待时间*/
);
…… //完成task1功能的代码
}
}
通过这种方式，任务与任务之间、任务与中断之间的通信和同步都得以实现。任务的状态转换如图7：
4 致命错误的防止和解决
DeltaOS不提供内存保护机制，因此程序设计中要特别注意防止非法修改内存[3]，否则会有意想不到的事情发生。通常这种异常是由两种情况引起的：一种是数组越界或使用指针不当；另一种是任务栈溢出。为避免以上情况发生，数组和任务栈的大小必须设置恰当，修改数组元素的时候要保证下标是在合法范围内的，使用指针要特别小心。不过，DeltaOS提供了异常处理机制，用户可以编写自己的扩展例程，当出现致命错误的时候实行一定的挽救措施，比如复位程序整个系统软件或者重新起动指定任务。
DeltaOS是一个强实时性的操作系统，通过优化任务划分、有效的利用中断机制满足了系统的强实时要求。利用本文提出的通信和同步方案，实现了任务的标准化接口，方便地进行了多次功能扩展，并且显示了它可靠性强的优点。 |
