一个基于COP的控制软件安全性增强方法

陈智勇，徐 锋，余 萍

1.南京大学 软件新技术国家重点实验室，南京 2100462.南京大学 计算机科学与技术系，南京 210046

一个基于COP的控制软件安全性增强方法

陈智勇1，2，徐 锋1，2，余 萍1，2

1.南京大学 软件新技术国家重点实验室，南京 210046
2.南京大学 计算机科学与技术系，南京 210046

1 前言

安全性关键系统（Safety-Critical System，SCS）[1]泛指具有潜在破坏力的一类系统，这类系统的失效会造成设备的损毁甚至是人员的伤亡。此类系统中，软件是系统的一个重要安全因子，软件的失效导致SCS的运行错误从而造成巨大的损失。软件安全性（software safety）工作的出发点是系统安全性。一个单独的软件本身并不存在安全性问题，只有当软件和硬件相互作用，在不同的环境下运行才有可能导致人员的生命危险、或系统崩溃、或造成不可接受的资源损失时，才涉及到安全性问题。因此，Mc-Dermid[2]认为，软件安全性只是软件在系统上下文中对系统安全性方面的贡献的描述。例如在航电软件中，飞机在飞行高度低于预警值时应该及时发出警示提醒飞行员。导致软件失效的原因主要有两类，一类是程序的逻辑错误，如某个公式的代码描述错误；另一类是对软件在不同环境中运行没有正确设计。例如1996年6月4日，阿丽亚娜5型运载火箭的首航，原计划将运送4颗太阳风观察卫星到预定轨道，但因为软件引发的问题导致火箭在发射39 s后偏轨，从而激活了火箭的自我摧毁装置。阿丽亚娜5型火箭和其他卫星在瞬间灰飞烟灭。后来查明的事故原因是：代码重用。阿5型的发射系统代码直接重用了阿4型的相应代码，而阿4型的飞行条件和阿5型的飞行条件截然不同。此次事故损失3.7亿美元。在现代软件工程中，代码重用已经成为软件设计的基础方法之一，但是重用的代码的安全性需要有可靠的保障。

SCS系统的控制软件一般会通过同其应用功能相关的传感器获取环境数据，然后控制执行器的行为。但是由于系统运行环境的复杂性，很多环境因素会导致系统进入危险状态，部分可能已经在控制软件设计的时候考虑到并加以处理。但是对软件安全性的研究表明，不论使用多么完善的软件开发模型，总是不可能在软件设计之初考虑到软件需要面对的所有可能出现的危险环境。因此，在软件维护阶段，能增量式地添加对环境因素的处理来提高整个系统的安全性而又不影响原有软件在应用方面的功能也是软件安全性研究的一个重要方面。因此，软件安全方面功能的开发可以采用软件开发模型中的增量模型（Incremental Model），一步一步构建软件安全功能。如图1所示是一个采用增量模型的安全性增强的实际系统，由一个原始系统和一个停机系统组成[3]。停机系统是作为原有系统安全功能增强系统设计，其输入从原有系统上的传感器获得。原始系统根据其使用的传感器的数据控制执行器的行为，同时一个停机系统并行运行，当诊断发现需要停机时，停机系统能迅速停止执行器的运行。这里，停机系统就是作为同原有系统完全独立的一个增量设计然后同原有系统整合成一个新的系统。但是这类如停机系统的安全功能增强方法是以功能为中心的设计方法，增量同原有系统以及增量同增量之间都是完全独立的，新增的系统资源也不能被不同功能模块重复利用，这就带来一些资源如传感器等的极大浪费。

图1 停机系统

系统安全功能增强以新增的系统资源为中心可以很好地避免上述的问题。本文新增的系统资源是指用于检测软件运行的环境上下文的一系列传感器，因此，设计环境因素应该成为安全升级方法需要考虑的中心问题，COP正是一种能准确直观地获取环境因素，并且提供支撑机制动态地根据环境上下文改变程序行为[4]的编程方法。COP允许程序员通过实现一种称为layer的抽象程序行为集合及其内部的局部方法（partial method）来实现程序行为的改变。在SCS系统中，对于不改变执行器行为的程序行为切换，目前已经存在的COP的支撑机制如ContextJ[5]，EventCJ[6]等都可以实现。但是对于控制软件安全性升级，危险状态的触发很有可能需要改变执行器的行为，例如停止马达的转动，在危险消除以后恢复执行器的原有执行状态。从控制软件的角度来看，执行器是程序中的临界资源，软件的安全相关部分对其访问和修改会影响到应用相关部分原来的运行结果，而目前的COP支撑机制并没有对程序行为切换过程中临界资源的访问控制提供明确的支持。针对上面的问题，对EventCJ做了一定的改进，对于程序行为切换过程所影响的临界资源提供对其上下文保存和恢复的支持机制，并且在Lego NXT上实现了一个运行支撑机制。

2 相关工作

软件的上下文正成为软件开发要面对的一个非常重要的问题，但是主流编程语言几乎没有提供准确地描述上下文的能力，COP编程方法的出现很好地弥补了这一不足。COP中任何计算访问信息都被视为上下文信息。任何一种COP的方法都应该包含以下一些属性[7]：

（1）行为变量（Behavioral variations）：行为变量表示那些能替代或者改变软件基本行为的行为集合。

（2）行为层（Layers）：行为层是那些相关的上下文依赖行为变量的集合。

（3）动态行为变量激活（Activation）：COP编程方法中行为变量能在运行时刻被激活从而影响系统的行为的机制。

（4）上下文（Context）：所有可计算的和可获取的信息都可以成为行为变量所依赖的上下文。

（5）作用域（Scoping）：精确控制激活或注销Layer的作用域，同一个行为变量在同一时刻可能在不同的作用域中分别被激活或注销。

COP语言的一个设计问题就是对layer激活的控制，即什么时候、哪个Layer应该在程序执行过程的什么位置被激活或注销的问题。目前的研究提出主要有两类方法，一种采用的是称为块结构体[6]（block-structured）的方法，如ContextJ[5]中的with表达式。这种方法的特点是上下文环境的改变和对应行为的激活/注销是在程序的同一处或者同一个线程内进行的，同时在退出表达式块后即注销了对应的Layer。另一种方法是针对Appeltauer[5]等人指出的很多layer的激活/注销是由外部事件所引发，而这类行为的激活不适宜采用块结构体的方法来实现。为此Tetsuo等人设计了EventCJ[6]，采用的是一种称为事件驱动的方法（Event-based Context Transition），这种方法可以分离上下文环境的变化检测与行为的激活。

目前大部分的COP语言采用的是块结构体的方法，这类方法多采用线程粒度的layer激活策略，虽然块语句可以很方便地表示在一个具体的方法调用中何时激活layer，但是对于那些由程序执行过程中随时发生的外部事件（如进入某座建筑或者传感器数据发生变化）触发的上下文变化并不适用。对于安全控制而言，危险状态是随机发生并且对其的响应处理需要非常及时，即任何线程的执行都有可能随时被打断。因此线程粒度的layer激活不适用于软件的安全性升级。

EventCJ基于事件和由事件触发的layer切换规则来管理layer的激活。在EventCJ中，事件由类似AspectJ[8]切点的方式定义，layer切换规则由基于规则的描述语言定义。EventCJ中事件的发生可以立即触发layer的切换发生，从而影响程序的执行流程，因此对于软件的安全控制是合适的，但是EventCJ的不足之处在于，首先其事件的描述能力较弱，它只能描述程序中变量或函数的当前状态[9]，对于状态的变化过程则无法直观地表达；其次EventCJ虽然提供了layer切换规则描述，但是对于切换时layer的信息没有提供保存和恢复的功能，这对于前面提到的程序行为切换时临界资源的访问控制不能提供明确的支持。

3 安全升级模型

上面提到EventCJ的事件存在的描述能力不足，为此在其基础上进行了改进，定义了事件（event）和条件（condition）的概念。

事件：在监测过程中瞬间发生的称为事件。例如监测过程中，光传感器采集数据一次称为事件。一个事件含有值属性和时间属性，其中值属性是指该事件附属的值，如光传感器采集一次数据这个事件，该事件的值属性就是采集到的数据值；时间属性是指该事件发生的时间信息，如上例，采集数据发生的时间就是该事件的时间属性。有了事件的概念，系统屏蔽了不同传感器数据类型造成的差异性，统一对接收到的事件做分析处理。

条件：条件代表在执行的过程中能保持一段时间的信息，例如（x＜1）是一个条件，因为这个状态只要x不超过1就能一直保持。

Condition和Event有如下的语法关系：

事件start（c）当条件c从false变为true时产生，end（c）当条件c从true变为false时产生。有了条件和事件的概念，就可以结合传感器获取到的上下文信息，描述系统的安全状态，然后根据状态转换触发的事件决定Layer的激活。例如有表示车辆和前方障碍物距离的变量d，小车当前的状态S={d＞10}，可以定义Layer激活事件E={end（S）}。通过使用Event和Condition可以精确地描述系统的当前状态以及状态的变化过程。

3.1 Layer定义

Layer是上下文相关行为集合的抽象概念，每个layer都至少有一个partial method用来定义同具体的上下文相关联的行为。同ContextJ一样，本文在Layer中也定义一系列的partial methods。但是所不同的是，首先在Layer中可以定义activate/deactivate对，分别表示layer被激活和注销时执行的动作；其次还可以定义save/restore对，表示对Layer现场信息的操作，下面会详细介绍。

3.2 Layer激活

Layer激活表示程序的执行流程转换到被激活的layer的域中，Layer转换的语法如下：

Layer的切换默认是不保存被切换的Layer的信息的，但是如前面所述，Layer的信息在某些情况下显得非常重要。供前缀和后缀修饰save和restore。save前缀表示保存Operator左侧的Layer的信息；restore后缀则表示激活Operator右侧的Layer以前首先执行信息恢复操作。

下面是一个简单的例子说明：

这条转换规则表示当RiskEvent发生时，如果NormalNavi已经激活则注销NormalNavi并且激活RiskNavi；否则仅激活RiskNavi。下面考虑当危险状态撤销后，系统回复正常状态需要载入注销前的一些信息如速度，方向等信息，上面的简单例子改写如下：

NormalNavi切换到RiskNavi时保存Layer的信息；相对应地，RiskNavi切换到NormalNavi时载入Layer信息。

4 运行支撑机制

为了说明安全升级模型的应用在Lejos上实现了一个运行支撑机制，结构如图2所示。Lejos是基于乐高机器人（Lego NXT）的一个Java程序开发/运行环境[8]。乐高机器人包括一个可编程的类似CPU的控制器，一系列传感器和马达等执行器。Lego NXT有丰富的附加组件如传感器支持，并且其拥有Lejos这样一个成熟的Java开发环境，可以较好地模拟现实中的SCS系统。运行支撑机制包括了一个上下文描述语言及其解析器的实现和layer的定义激活策略。

图2 运行支撑机制结构图

context information collector是根据定义的上下文信息收集脚本生成的，并作为原有工程的一部分同原程序一起编译生成新的可执行文件。为此，实现了一个将上下文描述语言转换为Java语言的编译器原型。编译器包装成一个Eclipse plugin。系统维护人员在使用过程中，对一个包含规约描述脚本的Java Project，按照规约描述语言生成一个新的Project并且编译链接替代原先的Project。Event Recognizer和Checker则是具体设备无关的组件，前者是对输入的传感器数据产生对应的事件，后者则是对事件验证是否触发layer的激活条件。

4.1 上下文信息描述语言

一个上下文信息可以用一个向量＜J，S＞表示，其中J表示在Java程序中对应的表示变量，S表示对应的传感器。默认一个传感器一次采集的数据可以在Java中找到对应的数据类型来表示，例如光传感器采集的光强度值可以用一个Integer类型来表示。传感器S包括属性向量＜N，P，G，S＞，分别表示传感器名称，传感器端口，获取数据方法和属性设置。属性的设置一般包括采样频率、数据的过滤方式等。

上下文信息收集作为一个单独的线程运行，可以根据指定的频率采集传感器信息，数据发送到事件处理器，事件处理器和信息收集线程通过Java提供的管道流PipeInput-Stream，PipeOutputStream通信。

事件处理器需要随时判定定义的事件是否发生。设想上下文信息收集线程不断把监测的传感器数据或者监控的函数的调用情况发送到事件处理器，一旦收到传来的信息，处理器就需要验证。事件处理器在运行过程中维护一张保存所有监控信息当前值的表，当收到信息时就更新该表，然后验证所有定义的事件和条件的真值。

因为条件是定义在监控变量上的一个布尔表达式，所以可以直接根据存储在表中的监控变量的值来判断条件是否成立。事件的评估则要复杂一些，考虑如下事件start（c），不仅需要知道条件c的当前值，而且还需要知道c的更新以前的最后一个值。事件end（c）亦如此。传感器数据的update事件的监测可以通过按照一定周期返回值获得，然而程序执行信息，startM和endM则可以采用面向方面的编程方法（Aspect-Oriented Programming），通过设置切点的方法获取。

4.2 Layer激活

设计了一个管理所有被激活的layer的优先级队列，并且该队列是线程安全的。系统反馈线程在队列为空时处于wait状态，当Checker发出control activation信号，附带activation序号，并且把一个layer放入激活队列后，唤醒反馈线程。反馈线程的工作流程是，它首先从队首取一个layer，读取其padding标志位，该标志位表示这个layer是否需要在条件满足期间保持对反馈线程的占有，不允许其他layer执行反馈动作。如果padding被置位，则反馈线程会等待直到Checker发出的新的activation信号，否则反馈线程执行完后取队列的下一个layer执行。线程执行一个layer前，如果layer的onSave标志被置位，则先调用save方法；执行完成后，检查onRestore标志位，如果被置位则执行restore方法，完成后退出。每个Layer都有一个用于保存Layer信息的表，在本文的实现中采用Java的HashMap实现。暴露两个调用的接口：

顾名思义，save是将一个object按照key指定的键名保存到hash表中，restore按照key从hash表中取出。系统会自动为每一个Layer生成一个唯一的key，可以通过getKey方法获得。

5 实验系统

在上面的运行支撑机制上，实现了一个保持距离安全的实验系统，给出了具体的规约脚本，用来展示本文的安全升级模型在具体系统中的使用。如图3所示，在Lejos上有一个正确运行的零件分拣系统SPS-Lejos。SPS-Lejos能够根据颜色传感器对放入的零件颜色的感知，移动轨道上的零件回收盒到相应位置，然后机械臂将零件弹入对应颜色的回收盒中。

图3 SPS-Lejos系统

假设SPS-Lejos对于系统的安全性方面有了新的要求如下：新添加一个用于测距的传感器，用于控制移动部件和轨道障碍物的距离，如果小于阈值则停止马达转动，当障碍物消除后继续转动马达到预设角度。下面展示了本文模型对这一问题的解决方案。

5.1 上下文信息提取

上下文信息定义脚本pedl.xml定义了两个导出的初级事件：ev_previous_light，ev_current_light。两者均对应NXT中光传感器：LightSensor的数据变化，对应的是Decision Module中的变量：Controller.previous_light，Controller.current_ light。不同的是两者获取数据前传感器的设置不同，下面表示了ev_current_light的定义。每次S2端口的LightSensor监控数据发生变化，就触发事件ev_current_light。

在这里，信息采集是作为一个单独的线程一直处在运行状态的，必然会给系统带来额外的开销，为了能动态地控制负载，在setting标签中设置了period参数控制数据采集的时间间隔。

5.2 验证安全条件

安全条件是根据光传感器的数据变化来描述的，当前后两个传感器数值差超过一定值时表示传感器同前方障碍物的距离达到安全距离阈值。传感器的数值可以直接通过value操作符从事件中获取，安全条件描述如下所示，定义了两个监控变量：current_light，previous_light，每次事件ev_current_light和ev_previous_light发生，验证器就会重新计算两个监控变量及其差值：

5.3 Layer激活

定义如下两个事件：SafeToRisky，RiskyToSafe。它们的含义如前所述，在实际中的意义分别是障碍物距离从安全距离和危险距离之间的相互变化的瞬间。

当SafeToRisky事件被触发，下面的转换规则触发。如果SafeControl处于激活状态，则会首先调用SafeControl中的restore代码块，一般执行的是保存SafeControl中的现场信息，然后执行deactivate代码块，一般断开对设备的占用，最后调用RiskControl中的activate代码块。

RiskyToSafe事件被触发时的执行流程类似，它们的转换规则如下所示：

5.4 实验结果

在安全升级前，当轨道上有障碍物如图3中的小人时，移动的零件回收盒会直接撞倒障碍物；对原有系统的代码应用开发的Eclipse插件转换得到了有COP运行支撑机制的安全增强系统的新系统，能够在轨道出现障碍物时，暂停分拣系统的工作，当障碍物移除时，零件收集盒能够移动至预先指定的位置而不会因为中途被打断出错，说明了对于系统在layer激活前后上下文信息的保存是有效的，实验结果表明本文的安全规约对系统的安全性起到了预期的增强作用。通过多次实验发现，起初从系统距离达到安全阈值到作出响应有0.5～1.0 s的时延，由于本文采用的是Jvm下的多线程机制干预程序的正常运行，将Layer激活部分的线程优先级设为最高可以有效地降低因线程调度带来的时延，提高系统的响应性。

6 总结

本文所描述的基于COP的动态软件安全性升级框架，为软件安全性的升级维护提供了一种可靠方便的方法。认为软件的后期维护同样需要可靠的安全性升级模式，COP的思想较好地契合了增量式安全升级的要求，但是当前的COP运行支撑机制又不能很好地满足需求，因此提出了本文前面描述的方法，可以很好地满足后期维护动态升级安全性的需求。在经典的ECA（Event-Condition-Action）模型基础上，改进了Action部分在实际应用中的局限性，提供了一个以Layer上下文保存为核心的运行支撑机制并且实现了一个基于NXT的原型系统，编写了安全规约描述脚本语言的编译器及其Eclipse插件工具。

目前本文的模型只适用于那些对超时不敏感执行器任务，即执行器可以被打断而不对最后的执行效果造成影响，对于那些要求在某段时间内完成的任务并不适用，未来将针对这一类执行器完善本文的模型。

[1]IsaksenU，BowenJ P，NissankeN.System andsoftware safety in critical systems，RUCS Technical Report RUCS/97/ TR/062/A[R].Berks，UK：Department of Computer Science，University of Reading，1997.

[2]McDermid J.Software safety：where's the evidence[C]//Proceedings of the 6th Australian Workshop on Industrial Experience with Safety Critical Systems and Software.[S.l.]：Australian Computer Society，2001.

[3]Kalinsky D.Architecture of safety-critical systems[J].Embedded Systems Programming，2005：14-25.

[4]Hirschfeld R，Costanza P，Nierstrasz O.Context-oriented programming[J].Journal of Object Technology，2008，7：125-151.

[5]Appeltauer M，Hirschfeld R，Haupt M，et al.ContextJ：contextoriented programming with Java[J].Computer Software，2011.

[6]Kamina T，Aotani T，Masuhara H.EventCJ：a context-oriented programming language with declarative event-based context transition[C]//Proceedings of the 10th International Conference on Aspect-oriented Software Development.New York：ACM，2011：253-264.

[7]Costanza P，Hirschfeld R.Language constructs for contextoriented programming：an overview of ContextL[C]//Dynamic Languages Symposium（DLS）'05.New York：ACM Press，2005.

[8]Allan C.Adding trace matching with free variables to AspectJ[C]// OOPSLA'05.New York：ACM，2005.

[9]Kamina T，Aotani T，Masuhara H.Designing event-based context transition in context-oriented programming[C]//COP'10. New York：ACM，2010.

CHEN Zhiyong1，2,XU Feng1，2,YU Ping1，2

1.State Key Lab for Novel Software Technology,Nanjing University,Nanjing 210046,China
2.Department of Computer Science&Technology,Nanjing University,Nanjing 210046,China

Control software is the core of safety-critical systems,its correctness is crucial to the system safety.However,as systems are facing increasingly complex context environment,which cannot be considered all,system safety is facing new challenges. So it is very important to enhance software safety via an environment-centered,incremental method when maintaining the software.Context-oriented programming is a programming technique which treats software context as a central notion.Current operating mechanisms for COP treat context explicitly,and it provides mechanisms to dynamically adapt behavior in reaction to changes in context.However,some behavior adaptions may interrupt the system actuator's running state,and affect system's results.There still don't have an effective approach to deal with such problems.According to existing COP language,it proposes a control software safety enhancement model based on software context saving and restoring,also,it provides the corresponding runtime support mechanism and programming tools.It shows a parts picking system safety enhancement case to satisfy the model's correctness.

software safety;Context-Oriented Programming（COP）;programming model

控制软件往往是安全攸关系统的核心，其正确性对系统安全起着至关重要的作用。然而由于系统面对的环境因素越来越复杂，软件设计之初不可能考虑到所有可能面对的环境变化因素，系统的安全性面临新的挑战。因此在软件维护阶段，以环境变化为中心，增量式地增强软件的安全性显得非常重要。面向上下文编程方法（Context-Oriented Programming，COP）正是一种以软件运行上下文环境为中心的编程方法。现有的支撑COP思想的运行机制可以使得系统根据精确的上下文信息动态地调整系统的行为，但是有些上下文引发的系统行为调整会导致系统执行器的现有运行被打断，对于这类影响系统执行器行为的上下文，现有的COP运行机制还没有提供有效处理方法。根据现有的COP方法，给出了一个基于软件上下文保存与恢复的控制软件安全性增强的编程模型，并在Lego NXT控制器上实现了相应的运行支撑和编程工具，通过一个产品分拣系统的安全性增强实例，初步验证了该编程模型的合理性。

软件安全性；面向上下文编程（COP）；编程模型

A

TP391

10.3778/j.issn.1002-8331.1208-0522

CHEN Zhiyong,XU Feng,YU Ping.COP based approach to control software safety enhancement.Computer Engineering and Applications,2013,49（5）：64-69.

国家重点基础研究发展规划（973）（No.2009CB320702）；国家自然科学基金（No.61021062，No.61073030）。

陈智勇（1988—），男，硕士研究生，主要研究领域为可信计算；徐锋（1975—），男，博士，博士生导师，主要研究领域为可信计算、系统安全、软件可靠性技术等。E-mail：zychen.nju@gmail.com

2012-09-07

2012-10-16

1002-8331（2013）05-0064-06

CNKI出版日期：2012-10-31 http://www.cnki.net/kcms/detail/11.2127.TP.20121031.1000.020.html