载，Linux中大多数设备驱动程序或文件系统都做成这样的模块。超级用户可以通过insmod和rmmod命令分别载入和卸载模块。核心也可在需要时，请求守护进程（kerneld）载入和卸载模块。这种方式可以减小核心代码的规模，使核心配置更为灵活，并且用户不必每次修改后都重新编译核心代码和启动系统。

一旦Linux模块载入核心后，就成为核心代码的一部分。它与其它核心代码的地位是相同的。当模块载入系统核心时，系统修改核心中的符号表，将新裁入模块提供的资源和符号加载核心符号表中，新载入的模块可以访问已载入的模块提供的资源为自己服务。

3.2 TCL/TK图形编程语言

本系统中的图形用户界面采用TCL/TK图形编程语言，使界面友好、形象、直观。TCL是Tool Control Language（工具控制语言）的缩写。TK是TCL“图形工具箱”的扩展，它提供各种标准的GUL接口，以利于迅速进行高级应用程序开发。

TCL/TK是一种解释执行的脚本语言，应用中通常将嵌入到C程序中。“小巧、易学、高效、跨平台执行”是TCL语言特点的集中体现。实际上，TCL不仅仅在开发小的应用程序上有其快速、可维护性强等优势，在大型应用系统方面，如操作系统及网络管理、测试系统、自控、仿真、可视化应用及计算机辅助设计等方面都有丰富的应用成果。

4 防危核实验原型的设计与实现

图3为以交通灯控制为模型的防危核系统体系结构。

由图3可以看出，整个系统由四个部分组成：防危核、模拟设备、设备控制器、命令文件。防危核作为RT-Linux的实时任务，与模拟设备、设备控制器间的通信采用RT-Linux提供的实时FIFO；而模拟设备和设备控制器间的通信使用Linux提供的非实时命名管道。下面仔细分析各模拟所提供的功能。2⑤⑥⑦sΔδΛΔωω·αγ∈βθθθ→→→→ττ 防危核模块的设计和实现

系统在运行时先通过命令insmod将防危核动态加载到Linux内核中，于是它便一直运行内核态。当不需要时再用命令rmmod手动卸载。这种方式下会对操作系统内核的基本功能产生任何影响，同时又可以保证demo系统的实时性。

    防危核分为主模块和命令检测模块。主模块负责接收设备控制器传来的设备命令和模拟设备发送的设备状态，然后根据命令参数的不同情况进行相应的处理。如果用户要求命令不需要通过防危核验证，则直接将命令发送到模拟设备；如果用户要求命令通过防危核验证，则主模块将调用命令检测模块进行命令的合法性检测，命令检测模块以函数形式存在并且按照交通灯的防危策略而设计。函数名为int SafetyDetect（DevState CurrentState,SourceCmdNewCom），函数返回值为命令判断结果。如果验证设备命令合法，则主模块将设备命令及返回值一起发送到模拟设备，模拟设备据此改变设备状态；如果验证设备操作命令非法，则主模块向设备控制器返回命令检测模块的返回值，设备当前的状态不改变。

为使防危核尽可能小并具有通用性和扩展性，将含有防危策略的命令检测模块以函数的形式存在于防危策略库中，当防危核需要防危处理时，便到访问策略库中调用此相关函数。若设备改变，则只需向策略库中添加或修改相应设备的防危策略。另外，防危核作为内核模块，采用内核模块的编写方式编写，模块中只能使用系统调用函数。

下面定义以交通灯为模型的防危系统的防危策略。

返回值=0；

/*表明经防危核验证为正确命令*/

返回值=1；

/*命令经防危核直接传送到模拟设备而未经过安全检测模块验证，模拟设备状态根据此值改变*/

返回值=2；

/*当前设备状态验证失败，失败原因不明。

措施：模拟设备保持当前状态不变*/

返回值=3；

/*同一个方向有多个信号灯同时开启。

措施：所有交通灯都关闭，然后在收到新的命令前设备执行缺省命令序列，此处由模拟设备接到“3”时直接处理*/

返回值=4；

/*四个方向同时为黄灯或绿灯。

措施：系统恢复到初始状态。在收到新的命令前设备执行缺省状态*/

反回值=5；

/*命令验证失败，失败原因不明，

措施：模拟设备保持当前状态不变*/

返回值=6；

/*信号灯保持当前状态的时间短于最短时间（<2s），

措施：模拟设备自动延迟（Sleep(Time)）显示此命令*/

返回值=7；

/*使同一个方向有多个信号灯同时开启的信号灯命令错误。

措施：不执行此命令，保持当前信号灯状态*/

返回值=8；

/*命令的执行将会使信号灯变化的顺序不正确。

措施：不执行此命令，保持当前信号灯状态*/

返回值=9；

/*四个方面同时为黄灯或绿灯的命令。

措施：不执行此命令，保持不前信号灯状态*/

4.2 模拟设备模块

防危核系统中以十字路口交通灯模拟外部设备。当经防危验证设备命令合法时，此模拟接受防危核传入的真实设备命令int RealCmd（），并向防危核返回设备当前最新状态。用图形方式形象、直观地显示设备本身的实时状态（交通灯颜色的变化）、模拟设备当前接收的命令和命令验证结果（合法或非法命令，对非法命令显示出错原因）。

该进程中设有三个线程，其中第一个线程专门用于读管道FIFO6（实时管道）获取防危核发送的控制命令，第二个线程读管道myfifo（非实时管道）获取命令控制器发送的设备控制命令，第三个线程用TCL/TK脚本语言实现模拟设备形象、美观的图形显示功能。当模拟设备启动后，自动进行初始化并调用缺省的交通灯控制命令序列完成基本操作，直以有来自设备控制和防危核的设备控制命令为止。若交通灯的显示时间超过一定时间，则强制设备执行缺省的设备状态。

4.3 设备控制器模块

模拟设备控制器作为一个进程独立运行，控制器先从命令文件中获取命令参数，然后根据命令的防危等级分别向模拟设备和防危核发送设备操作命令（包括正常的和不正常的操作命令）。命令中设置了时间控制参数，控制器按此时间间隔值发送设备命令。

4.4 设备命令文件

设备命令文件中存放了各种对交通灯的操作命令，包括正常和不正确命令。命令执行有三种防危等级可供选择：第一种，不通过防危核的命令，操作命令直接由设备控制器发送到模拟设备；第二种，通过防危核并验证其正确性的命令，此时防危核将调用防危策略库的相应防危策略验证命令，然后将验证结果发送到模拟设备；第三种，通过防危核但不验证设备操作的命令，命令被防危核直接送到模拟设备。设计三种等级命令的目的在于，比较是否使用防危核或是否进行命令验证在系统性能和防危性上的差异。

设备的命令格式为：char SourceCmd="Cmd east-light,Cmd north-light,Cmd west-light,Cmd south-light,int Time,bool Verifiedl,bool Verfied2"。操作命令要对十字路口的12盏交通灯进行操作控制。参数Time指本命令相对于前一条命令延迟多长时间发送。参数Verified1=0表示不经过防危核验证直接传送到设备的命令；Verified1=1表示要经过防危核验证。Verified2=0表示该命令直接发送到模拟设备不经过防危核的任何处理；Verified2=1表示该命令要通过防危核。

Struct Cmd

{

char first-light-color;

char second-light-color;

char third-light-color;

}

first-light-color,second-light-color,third-light-color表示每个方向三盏灯的颜色插入相应的颜色的图片。整个图形界面形象、美观。

5 实验系统的测试评价

根据防危核设计要求，从防危核的大小、对系统实时性的影响以及完备性三方面对本实验系统进行测试。

①防危核大小：防危核所编译后的目标文件为5KB，相对于RT-Linux内核源码是非常小的。

②时间开销：将防危核对控制命令验证所需时间进行了200次测试，得出其平均时间仅10μs左右，说明防危核对系统实时性影响非常小。

③完备性：将防危核对第二种控制命令各种情况的防危处理结果表明，防危核的验证结果完全正确。说明满足防危核完备性要求。

以上对防危核的测试结果表明，本控制模型完全满足防危核设计要求，防危核机制完全可以在实时操作系统中使用。

结语

根据防危核等相关理论并结合RT-Linux操作系统本身的特色，本文先从理论上分析了在RT-Linux中实现防危核的可行性，然后通过实际例子实现了基于RT-Linux的防危核，为防危核探索了一种新的实现途径。最后，通过对实验系统的测试进一步证明防危保障机制在实时操作系统中完全可行