嵌入式实时控制系统的编程模型探讨论文

嵌入式实时控制系统的编程模型探讨论文

1 引言

典型的嵌入式控制系统的设计和实现分别由控制工程师和软件工程师完成。控制工程师对系统行为和交互环境进行建模，导出控制逻辑，设计并优化控制模型，模拟验证其功能和性能;软件工程师将控制模型中的计算分解成不同的实时任务，并根据控制模型的时间约束、操作系统的调度机制和目标平台的性能，为任务指定优先级和任务周期。软件工程师需要反复尝试以确保实际执行时间满足设计需求。实验过程中如果某一任务错过了指定的deadline，需要重新指定任务优先级和周期，再次进行实验。除此之外，传统的编程模型(Bounded ExecutionTime，BET)模型不具有I/O 可组合性，即当向系统中添加新任务时，其他任务的完成时间会受到影响，其原因在于RTOS 和实时调度器为满足实时需求提供了很弱的保障。传统RTOS 和实时调度器无法保证任务完成时间的确定性，尽管可以通过反复的测试使系统具备足够的可信度，但方法本身存在缺陷，根本原因在于：

(1)编程模型中缺乏明确描述时间属性的语法;

(2)线程本身就具有不确定性;

(3)任务的wcet 时间难以准确度量，任务协作运行时难以确保时间属性，尤其是在多核系统中。

2 Timed SEFM模型概述

一个完整的Timed SEFM控制程序由服务、数据端口、任务、模块和模式等基本定义组成。

2.1 服务

服务是SEFM+操作系统模型中最基本的功能单元和调度单位。一个服务使用四元组) 表示，其中，sn 是全局唯一的服务名称;f 是一段内部没有同步点的代码，实现服务sn 所代表的功能;In 和Out 分别是一组输入和输出数据端口，如图1(a)所示。输入数据端口为服务提供运行所需的所有数据，输出数据端口用于存储对外可见的运行结果。服务是组成任务(Task)的基本元素，在不同任务中服务以不同的实例存在。

2.2 数据端口

数据端口是用于存储类型化数据(Typed Data)的结构，有三种数据端口：服务的输入数据端口(Input DataPorts，IDP)、服务的输出数据端口(Output Data Ports，ODP)和全局数据端口(Global Data Ports，GDP)。前两者与某服务绑定，用于实现该服务的数据输入输出;后者不与任何服务绑定，用于实现服务间松耦合的数据交换。

为避免不确定的竞争和同步，服务间的数据交换必须显式地进行：只能调用SEFM+内核功能Data TransferDriver(DTD)在数据端口之间进行数据交换(如图1(b)中带dtd 标记的连线所示)。即数据由DTD从GDP 或其他服务的ODP 导入到某服务的IDP;该服务运行结束时直接将结果写入其ODP，并由DTD 将ODP 中的数据传到指定的GDP 或其他服务的ODP。为保证数据的一致性和完整性，数据端口的访问受到严格的约束：(1)DTD 只能在有限的时间范围内以有限的权限访问服务的输入(服务开始前，只写)和输出(服务结束后，只读)数据端口;(2)服务在运行期间只能访问自己的IDP 和ODP

2.3 模块和模式

模块是描述控制逻辑的结构，该结构描述了任务间的交互方式和逻辑时间属性。在实时控制软件中，某些特定条件下一组任务可能需要替代另一组任务运行，Timed SEFM用模式切换(Mode Switch)来满足这样的设计需求。模块由一组模式组成，模式是一组任务的集合，任意时刻一个模块中只有一个模式处于活动状态，称为活动模式，只有活动模式中任务的服务实例能被调度运行。

一个模块用六元组，其中Mn 是全局唯一的模块名称;p 是模块获得执行流(即CPU时间)的周期;t 为该模块每个周期内获得的执行流时间，t 将被分派给当前活动模式中各个任务;Modes 为组成模块的模式列表;Nms 为模式切换周期(Mode Switch Period，MSP)相对于p 的倍数;switch 为模式切换函数，是用户编写的C 语言函数，该函数返回应当被激活的模式。为确保模式切换不影响系统中其他模块的运行并保证系统的时间确定性，模式切换只能在模式切换周期MSP 到来时发生，MSP 被指定为p 的Nms 倍，即系统将每Nms·p 时间间隔执行一次函数switch ，该函数将返回需要被激活的模式m(m Modes) ，若m  当前活动模式，则发生模式切换。

3 编译和运行支持

Timed SEFM 程序的功能部分和控制部分独立编译，功能部分由C 语言编译器编译，编译之后形成二进制代码和数据的集合，存储在一段连续的内存中。控制部分由Timed SEFM Compiler 进行编译，编译之后形成一系列触发器。

显示了Timed SEFM的编译和运行环境，除Memory Manager、Clock、Scheduler、Data Transfer Driver等基本功能之外SEFM+内核还提供了Naming Service和Trigger Manager 作为Timed SEFM程序的运行支持。Naming Service 建立了端口名到存储地址、服务名到函数入口地址的映射。Trigger Manager 负责触发器的创建、撤销、使有效(activate)和使无效(deactivate)。触发器分为定时触发器和条件触发器：定时触发器是用于定义在指定时间点做出指定动作的结构;条件触发器是用于定义满足指定条件时做出指定动作的结构。前者可指定的动作有：使一组触发器有效、使一组触发器无效、释放一个基本服务、在端口之间传递数据、创建一个定时触发器等;后者可指定的动作有：在端口之间传递数据、激活一个服务实例。

Timed SEFM控制程序编译后，每个模式对应一组触发器，指定了如下动作：在任务逻辑起始时间到来时将全局端口的数据传递到任务的输入数据端口并激活服务实例、服务运行结束时完成数据传递并激活指定的服务、在任务逻辑截止时间到来时将任务的输出端口数据传递到全局数据端口中。

4 结论

本文用三种方案实现了上述小车控制系统：

(1)在μCOS 上用传统的BET 模型实现;

(2)用现有的`LET 模型实现：将emachine 移植到μCOS 上，用Giotto 控制程序和μC 任务共同实现;

(3)用Timed SEFM实现。

表1显示了测得的SEFM+内核的几项重要性能指标，图10 显示了不同方案中，一段时间内任务每次提交运行结果的实际时间相对于设计时间的误差值。从实验结果可看出Timed SEFM具有相对较好的时间确定性。在传统的BET 模型中，任务提交执行结果的时间受实际调度过程和任务实际执行时间的影响，平均时间误差较小，但偶尔会产生较大的误差值;在Giotto 中，任务时间属性相对比较稳定，上下浮动值也比较小。但是，E machine 解释指令需要消耗一定的时间，引入了不可忽略的时间误差;在Timed SEFM中，提交任务执行结果的时间只受端口读写操作的影响，时间差值的上限为读写操作所耗的时间(即DT 和DT ′)，确定性相对较好。本文引入的Timed SEFM编程模型用LET 模型实现控制设计，明确描述任务的时间属性;用改进的SEFM模型实现功能设计，各功能单元显式地交互。较好地避免了不确定的竞争和同步的发生，使系统具有较好的时间确定性。