《消防实时系统的 QoS 技术研究.pdf》由会员分享，可在线阅读，更多相关《消防实时系统的 QoS 技术研究.pdf（6页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、消防实时系统的 QoS 技术研究 The Study of QoS Based on Real-time Fire-Alarm and Control System 李斌兵 武警工程学院基础部计算机教研室 孙文海 陕西省武警消防总队西安支队 Li,Binbing Sun,Wenhai 摘要：摘要：本文以一个典型实时应用为背景，从时间方面、可靠性方面、安全方面等系统分析它的 QoS 需求，从而定义了多维 QoS 参数，在已有 QoS 结构的基础上建立了实时系统的 QoS 层次模型。关键词：实时系统 QoS 消防指挥系统 ABSTRACT:This paper Systematically res
2、earches the QoS requirement in a background of a typical real-time application and then specifies muli-dimension QoS parameter from the respact of timeliness,reliability,security and throughput.Finally,develops the QoS framework.KEYWORDS:KEYWORDS:real-time system QoS Fire-alarm and control system 中图
3、分类号：TP393 文献标识码：A中图分类号：TP393 文献标识码：A 1 引言引言 随着网络技术与信息技术的迅速发展和计算机应用的日益普及与深入，服务质量 QoS（Quality of Service）概念与技术在通信网络领域已取得了重要的研究成果，使得网络环境能适应各类应用的优质服务需求。从基于服务（Service-Based）的系统设计思想出发，分布实时计算平台也同样存在服务质量问题，例如，对分布实时应用而言，非常重要的时间、可靠性、安全性等方面的非功能需求，可以看作是实时应用提出的应用服务质量（QoS）需求，也就是说，基于 QoS 的资源管理技术也可适用于实时和分布计算系统，而服务的
4、提供者则是操作系统本身。因此，有必要从应用出发，分析研究基于 QoS 的多维资源管理技术。对于军事分布实时应用，具有实时、可靠、安全的 QoS 需求，除此之外，具体应用还可能有特殊的 QoS 要求，这就形成了多维 QoS。为此，必须深入分析并科学定义多维的 QoS 参数集。在此基础上，才能设计和开发用户定义 QoS 的工具和应用描述 QoS 的接口。2 应用背景应用背景 武警部队消防实时指挥系统设于部队指挥中心内，它采用各值勤点集中接警，统一处理的方式。一方面，由接警专用交换机接口接受电话报警；另一方面，在重点监控目标有自动报警系统与计算机远程通信网相连，可实时接受报警信号。位于-1-各支队的
5、受警机与指挥中心局域网构成远程通讯网络，实时接收总队向支队发布的出动命令。系统的结构图如图一所示：?火灾探 测设备 报警控制 计算机 报警数据实时图像DDNISDN接报警视频服务器 排队机接收机报警数据地理信 息数据 库 实时数 据显示 火警终端(出动方案 生成）图像监控 设备 语音指挥中心局域网服务器计算机 监控 数据流 控制信号 数据库设备 火灾联动 图一 消防自动报警系统结构图 3 过程分析过程分析 将消防自动报警系统的实施过程划分为三个阶段，第一阶段从各监控点的探测器（智能探测器，烟温复合探测器等）或其他设备得到数据流，探测器接口由内置CPU 实时采集数据、处理数据，此阶段与环境交互密
6、切，且现场周围是一个无法预知的动态环境，第二阶段探测器要每时每刻将其对外界的感应信号转换成数据送往控制器，控制器也要每时每刻对该数据进行记录、运算等处理，并参照多种火灾数据曲线进行判断数据是否满足触发动作的环境条件，第二阶段是由第一阶段提供的事件驱动的，控制器对监测到的事件做出及时的反应，根据温度、气体成分等变化判断是否符合报警的条件，如果符合则通过网络链路将有关数据送给指挥中心的计算机，该计算机按一定周期对各监控点的数据进行实时判断，根据接警的级别，显示火灾报警的位置和状态并作有关决策判断的进一步处理。第三阶段是音、视频数据处理阶段，指挥中心根据第二阶段得到的数据，决定是否启动现场网络摄像机
7、系统进行实时图像传送。为了不遗漏火情，第一阶段应按照一定的周期循环往复的进行处理；第二阶段应根据第一阶段的采集信息进行灾情级别的判断，由监控程序调用相应的辅助决策程序，根据火情级别不同，辅助决策的处理内容也不相同，由于火情发生的数量与火情的严重程度都是不可预知的，所以此阶段启动的处理任务数和处理时间段也是不可预测的，当火灾的级别高于某一指定值时，还应启动音、视频处理任务，从而进入第三阶段即多媒体数据处理。综上所述，指挥中心的计算机按照周期依次对多个重点目标进行轮巡监测，即使在某一周期内，某个监控目标没有满足时间限，也必须处理下一周期，对下一个目标进行处理，以上应用模式构成-2-了分布式实时应用
8、。4 QoS 需求分析需求分析?时间方面：上述每一阶段的划分是一个粗粒度的，每一阶段都有截至期的限制。一个周期任务在第一阶段包括数据采集、计算、通过网络将计算结果送到服务器上作进一步处理，从数据采集到最后处理完成允许的延迟时间不能超过某一上限。第二阶段是由第一阶段提供的事件驱动的，指挥中心计算机对监测到的事件做出及时的反应，这一阶段也有时间限制。第三阶段是多媒体数据处理阶段，指挥中心根据第二阶段得到的报警级别，如果决定启动现场的数字摄像机等设备进行实时图像传送，则进入连续媒体数据传送阶段。第二个阶段的处理依赖第一阶段数据的采集，第三阶段依赖于第二阶段的判别，对于第三阶段实际上需要服务器支持具有
9、一定质量指标的连续媒体的应用。?可靠性方面：系统要求较高的容错性，传统的可靠性衡量指标有：失效率、平均失效时间、失效间隔时间、平均修复时间以及故障覆盖率等统计性指标，在实际消防系统中通常采用可靠性措施作为可靠性 QoS，如备份个数、主动/被动复制等。?数据的 QoS 特征 上述每一阶段的任务都要与环境交互，例如，在第一阶段传感器要不停检测周围环境的温度、湿度、烟雾浓度等，且这些数据量是随机的，动态的。第二阶段和第三阶段要与网络环境交互，在网络中传输的数据是受负载大小和延迟限制的，由于第一阶段数据量大小不易确定，因此，上述三阶段的数据 QoS 特征均具有动态性和随机性。?安全方面 数据在网络传输
10、过程中要进行加密，防止泄密，要进行认证和访问控制，需要安全日志等。?容量方面的 QoS 例如对于火场图像实时传输，实际是多媒体软实时应用，包含音频、视频等数据，这类数据的录制、访问、传送与播放过程，会产生很大的数据量，因此所需的存储容量大。音频的取样频率、量化比特、通道数、压缩编码方法、视频的帧频或图象格式、色彩深度、分辨率、压缩编码方法，都是与容量有关的 QoS 参数。?同步方面的 QoS 在处理连续媒体数据时，不仅需要保持同一媒体内的时间连续性，而且通常需要维持不同媒体间的同步关系。可定义相关视频流与音频流之间的时态关系，定义所允许的最大时间偏差值。?服务级别 IETF 定义了一个完整的集
11、成服务结构和一个 QoS 框架结构，集成服务的 QoS内容包括四个级别的 QoS：-3-?尽力而为(best effort)：不对延迟做任何保证；?可控的延迟：提供几个级别的延迟供应用选择；?可预测的延迟：提供一个概率的延迟上界；?保证的延迟：提供一个绝对保证的延迟上界；这四个级别实际表示了 QoS 协商或重协商时要求的 QoS 被重视的程度。对于一些定量描述的 QoS 需求，服务级别进一步定性描述这些需求。例如消防指挥系统中的地理信息处理及辅助决策部分只需尽力而为的服务级别；而火场实时图像传输时要求流的实时传输、消防自动报警系统中三阶段信息传输、处理和计算，需要保证的延迟服务级别；以上从应用
12、角度出发给出的QoS需求描述是一种粗略的、非精确的自然描述方法，实际上按照国际上许多研究小组（包括IETF的工作小组），例如，英国曼彻斯特大学的研究小组在QoS-A工程中提出的对QoS的处理方式，应遵循对QoS进行分层，按用户需求和应用进行分维的方法。所以上述对于QoS的需求分析应该进一步分层、分维量化为具体的QoS参数，QoS可出现在操作系统层，中间件层，乃至应用层，特别是随着实时应用的丰富，与应用相关的QoS参数也层出不穷；QoS从网络通信QoS扩展到端到端的QoS，与QoS密切相关的资源管理就从网络资源扩展到端系统的资源2，即操作系统所管理的本地资源。各层QoS之间的映射，QoS到端系统
13、资源和网络资源的映射，也就随之产生。利用多维 QoS 的概念，消防实时应用的服务质量是一个多维空间，每个 QoS 参数是构成这个空间的一维。例如，时间类 QoS 参数，表现为上述三阶段的时间截止期限制；可靠类 QoS 参数，主要指数据传输的可靠性，表现为失效率、平均失效时间等；安全类 QoS 参数，表现为加密级别 0、1、2、3 等分别对应密钥长度=0（不加密）、56、64、128 等；容量类的 QoS 参数，表现为连续媒体传输过程中的祯速率，例如，5fps,10fps,25fps,30fps 等，声频采样率，例如，8kHz，16kHz，24kHz 等。5 消防实时系统消防实时系统 QoS 框
14、架框架 指挥中心采用 linux 系统作为网络操作系统，网内各微机和中队受警机全部以中文 windows 98 为操作系统平台。自动报警接收机和服务器采用客户/服务器模式，通过 socket 进行通信，构成了分布实时系统。运行在服务器上的实时监控程序作为一个软实时应用程序，需要有 QoS 的支持。此外，上述消防实时应用还具有安全性和可靠性方面的需求，经过分析，建立基于消防指挥系统的 QoS 框架，满足 QoS支持。目前，对于分布式实时系统应该采用分层体系结构这一点已被人们普遍接受。如果将端到端的QoS管理观点映射到分布式多媒体系统的分层体系结构上，就形成了层次化QoS管理观点1。端系统可分为三
15、层，即应用层，系统层，网络层，针对消防实时应用系统，应用层包含连续媒体应用程序和实时报警程序，二者都具有一定 -4-的QoS需求。分布实时资源管理层应根据QoS需求，将应用层QoS参数映射成系统层QoS参数，在调度服务、容错管理和安全等方面提供QoS的支持。端系统下的实时资源管理层是管理单机环境下的实时资源，采用具体的调度策略来支持QoS以及进程间的通信机制来保障调度策略的实施。此外，对于容错和安全方面的需求则映射为具体的实现机制，如双机热备、加密算法等，见下图二。分布实时应用程序应用 程 序接口 API连续 媒 体服务自动 报 警服务分布实时资源管理层调度服务容错管理安全服务端系统下实时资源
16、管理层调度 策 略实时 IPC 支持加密、访问控制带实时扩展的操作系统和网络硬件支持系统Client/server 体制 下 的计算机有线/无线 网 络通 信 设备其 他 辅助设备网络通信服务网管服务TCP/IP服务其它?图二 系统资源管理模型 6 结束语结束语 本文以武警消防部队指挥自动化系统建设为背景，试图抽取实时应用的共性QoS 来简化消防实时系统的设计与开发，建立了提供 QoS 需求的系统资源管理模型。限于篇幅，本文的后续工作，改造现有操作系统内核，提供 QoS 保证的技术不在讨论之列。参考文献 1、A Quality of Service Architecture,Andrew T.
17、Campbell,doctor thesis of Computing Department of Lancaster University，Jan.1996 2、A Resource Allocation Model for QoS Management,Ragunathan Rajkumar,1999,http:/www.cmu.edu 作者简介：李斌兵（1966.9-），女，汉族，硕士毕业于西北工业大学计算机科学系，研究生导师，副教授，现从事计算机应用、军事地理信息方面的教学与研究。Tel:029-8552217 li Binbing,Department of Computer Science,Engineering Collage of the Armed Police Force,Xian,710086 Sun Wenhai,branch of salvage corps of public security of yangling demon.zone Sun Wenhai,branch of salvage corps of public security of yangling demon.zone 通信地址：西安消防支队 孙文海 收 tel:13909238073 -5-e-mail:-6-