3800字职称论文基于复制控制的软件安全性研究方法

论文类型：职称论文

论文字数：3800字

论点：软件,系统,事件

论文概述：

本文所描述的基于 COP 的动态软件安全性升级框架，为软件安全性的升级维护提供了一种可靠方便的方法。并在 Lego NXT 控制器上实现了相应的运行支撑和编程工具，通过一个产品分拣系统的安全

论文正文：

1 前言

导致软件失效的原因主要有两类，一类是程序的逻辑错误，如某个公式的代码描述错误；另一类是对软件在不同环境中运行没有正确设计。例如1996年6月4日，阿丽亚娜 5 型运载火箭的首航，原计划将运送 4 颗太阳风观察卫星到预定轨道，但因为软件引发的问题导致火箭在发射 39 秒后偏轨，从而激活了火箭的自我摧毁装置。阿丽亚娜 5 型火箭和其他卫星在瞬间灰飞烟灭。后来查明的事故原因是：代码重用。阿 5 型的发射系统代码直接重用了阿 4 型的相应代码，而阿 4 型的飞行条件和阿 5 型的飞行条件截然不同。此次事故损失 3.7 亿美元。在现代软件工程中，代码重用已经成为软件设计的基础方法之一，但是重用的代码的安全性需要有可靠的保障。
SCS 系统的控制软件一般会通过同其应用功能相关的传感器获取环境数据，然后控制执行器的行为。但是由于系统运行环境的复杂性，很多环境因素会导致系统进入危险状态，部分可能已经在控制软件设计的时候考虑到并加以处理。但是对软件安全性的研究表明，不论使用多么完善的软件开发模型，总是不可能在软件设计之初考虑到软件需要面对的所有可能出现的危险环境。因此，在软件维护阶段，能增量式地添加对环境因素的处理来提高整个系统的安全性而又不影响原有软件在应用方面的功能也是软件安全性研究的一个重要方面。因此，软件安全方面功能的开发可以采用软件开发模型中的增量模型(Incremental Model)，一步一步构建软件安全功能。如图 1 所示是一个采用增量模型的安全性增强的实际系统，由一个原始系统和一个停机系统组成。停机系统是作为原有系统安全功能
增强系统设计，其输入从原有系统上的传感器获得。原始系统根据其使用的传感器的数据控制执行器的行为，同时一个停机系统并行运行，当诊断发现需要停机时，停机系统能迅速停止执行器的运行。这里，停机系统就是作为同原有系统完全独立的一个增量设计然后同原有系统整合成一个新的系统。但是这类如停机系统的安全功能增强方法是以功能为中心的设计方法，增量同原有系统以及增量同增量之间都是完全独立的，新增的系统资源也不能被不同功能模块重复利用，这就带来一些资源如 传 感 器 等 的 极 大 浪 费 。
软件安全性(software safety)工作的出发点是系统安全性。一个单独的软件本身并不存在安全性问题，只有当软件和硬件相互作用，在不同的环境下运行才有可能导致人员的生命危险、或系统崩溃、或造成不可接受的资源损失时，才涉及到安全性问题。因此，Mc-Dermid认为，软件安全性只是软件在系统上下文中对系统安全性方面的贡献的描述。例如在航电软件中，飞机在飞行高度低于预警值时应该及时发出警示提醒飞行员。导致软件失效的原因主要有两类，一类是程序的逻辑错误，如某个公式的代码描述错误；另一类是对软件在不同环境中运行没有正确设计。例如1996年6月4日，阿丽亚娜 5 型运载火箭的首航，原计划将运送 4 颗太阳风观察卫星到预定轨道，但因为软件引发的问题导致火箭在发射 39 秒后偏轨，从而激活了火箭的自我摧毁装置。阿丽亚娜 5 型火箭和其他卫星在瞬间灰飞烟灭。后来查明的事故原因是：代码重用。阿 5 型的发射系统代码直接重用了阿 4 型的相应代码，而阿 4 型的飞行条件和阿 5 型的飞行条件截然不同。此次事故损失 3.7 亿美元。在现代软件工程中，代码重用已经成为软件设计的基础方法之一，但是重用的代码的安全性需要有可靠的保障。
我们认为，系统安全功能增强以新增的系统资源为中心可以很好的避免上述的问题。本文我们新增的系统资源是指用于检测软件运行的环境上下文的一系列传感器，因此，设计环境因素应该成为安全升级方法需要考虑的中心问题，COP 正是一种能准确直观地获取环境因素，并且提供支撑机制动态地根据环境上下文改变程序行为的编程方法。COP允许程序员通过实现一种称为 layer 的抽象程序行为集合及其内部的局部方法(partial method)来实现程序行为的改变。在 SCS 系统中，对于不改变执行器行为的程序行为切换，目前已经存在的 COP 的支撑机制如 ContextJ, EventCJ等都可以实现。但是对于控制软件安全性升级，危险状态的触发很有可能需要改变执行器的行为，例如停止马达的转动，在危险消除以后恢复执行器的原有执行状态。
从控制软件的角度来看，执行器是程序中的临界资源，软件的安全相关部分对其访问和修改会影响到应用相关部分原来的运行结果，而目前的 COP 支撑机制并没有对程序行为切换过程中临界资源的访问控制提供明确的支持。针对上面的问题，我们对 EventCJ 做了一定的改进，对于程序行为切换过程所影响的临界资源提供对其上下文保存和恢复的支持机制，并且在Lego NXT上实现了一个运行支撑机制。
本文第二部分介绍了一些相关工作，第三部分详细描述了我们的模型，第四部分详细介绍了我们的运行支撑机制，第五部分给出了一个相关的实验案例。.............

2 相关工作

软件的上下文正成为软件开发要面对的一个非常重要的问题，但是主流编程语言几乎没有提供准确地描述上下文的能力，COP 编程方法的出现很好的弥补了这一不足。COP 中任何计算访问信息都被视为上下文信息。......
COP 语言的一个设计问题就是对 layer 激活的控制，即什么时候、哪个 Layer 应该在程序执行过程的什么位置被激活或注销的问题。目前的研究提出主要有两类方法，一种采用的是一种称为块结构体(block-structured)的方法，如 ContextJ中的 with表达式。这种方法的特点是上下文环境的改变和对应行为的激活/注销是在程序的同一处或者同一个线程内进行的，同时在退出表达式块后即注销了对应的 Layer。另一种方法是针对 Appeltauer等人指出的很多 layer 的激活/注销是由外部事件所引发，而这类行为的激活不适宜采用块结构体的方法来实现。为此 Tetsuo 等人设计了 EventCJ，采用的是一种称为事件驱动的方法(Event-based ContextTransition)，这种方法可以分离上下文环境的变化检测与行为的激活。
目前大部分的 COP 语言采用的是块结构体的方法，这类方法多采用线程粒度的 layer 激活策略，虽然块语句可以很方便的表示在一个具体的方法调用中何时激活 layer，但是对于那些由程序执行过程中随时发生的外部事件(如进入某座建筑或者传感器数据发生变化)触发的上下文变化并不适用。
对于安全控制而言，危险状态是随机发生并且对其的响应处理需要非常及时，即任何线程的执行都有可能随时被打断。因此线程粒度的 layer 激活不适用于软件的安全性升级。
EventCJ 基于事件和由事件触发的 layer 切换规则来管理 layer 的激活。在 EventCJ 中，事件由类似AspectJ切点的方式定义，layer 切换规则由基于规则的描述语言定义。EventCJ 中事件的发生可以立即触发 layer 的切换发生，从而影响程序的执行流程，因此对于软件的安全控制是合适的，但是EventCJ 的不足之处在于，首先其事件的描述能力较弱，它只能描述程序中变量或函数的当前状态，对于状态的变化过程则无法直观地表达；其次EventCJ 虽然提供了 layer 切换规则描述，但是对于切换时 layer 的信息没有提供保存和恢复的功能，这对于我们前面提到的程序行为切换时临界资源的访问控制不能提供明确的支持。

3 安全升级模型

上面我们提到 EventCJ 的事件存在的描述能力不足，为此我们在其基础上进行了改进，定义了事件(event)和条件(condition)的概念。
事件. 在监测过程中瞬间发生的称为事件。例如监测过程中，光传感器采集数据一次称为事件。一个事件含有值属性和时间属性，其中值属性是指该事件附属的值，如光传感器采集一次数据这个事件，该事件的值属性就是采集到的数据值；时间属性是指该事件发生的时间信息，如上例，采集数据发生的时间就是该事件的时间属性。有了事件的概念，系统屏蔽了不同传感器数据类型造成的差异性，统一对接收到的事件做分析处理。
条件. 条件代表在执行的过程中能保持一段时间的信息，例如( x