动态监视系统

动态监视系统（精选8篇）

动态监视系统 篇1

随着新一代通信导航监视技术的发展, 基于机载卫星定位系统的广播式自动相关监视 (automatic dependent surveillance-broadcast, 简称ADS-B) 技术得到了应用验证和推广, 为空中交通管理提供了更加精确和实时的监视手段。近年来在军民融合发展的背景下, 国内重要城市周边和机场建设了大量ADS-B地面站及配套监视系统, 运用空管技术面向低空飞行组织、城市安防、应急搜救、反恐处突提供飞行动态监视服务。传统的监视系统软件均采用“一站一用户”C/S结构, 难以实现数据组网与网络共享;同时所使用背景地图均为小比例尺地图, 难以满足低空管理者对精细地物信息的需求。

本文研究了ADS-B数据处理的技术方法, 设计了面向公共互联网的监视数据分发服务架构, 结合国家公共地理信息服务平台开发了面向WEB的低空飞行动态监视系统, 实现了低空态势信息的网络服务和共享, 为低空空域飞行监视与应急救援提供了有效手段。

1 ADS-B航迹数据处理

目前, 我国公共运输航空及低空管理对ADS-B地面站的规划, 主要采用EUROCONTROL制定的监视数据交换标准Category 021 ADS-B Messages作为数据传输处理标准。相比传统的雷达数据处理, ADS-B报文数据频率高, 数据量更大。

1.1 ADS-B航迹数据缓存设计

ADS-B报文数据经解析后获得航空器目标的飞行数据信息, 经计算机系统处理后形成航空器的航迹对象。为提升数据处理性能, 设计了多缓存模式实现数据处理和存储。ADS-B航迹数据处理需要的缓存分为航迹ID缓存、航迹轨迹缓存和航迹对象缓存三级, 并以<key, value> 键值对的方式存储航迹数据, 缓存数据结构如表1 所示。

航迹ID编码为采用“系统时间戳+ 应答机地址码” (yy MMdd HHssmm+6 位地址码) , 以保证航迹的唯一性;航迹轨迹存储基于时间标识的航空器空间位置序列;航迹对象用以记录飞行目标的实时状态信息, 航迹属性包括航迹ID、地址码、呼号、经度、纬度、高度、速度、航向、应答机编码等信息。

1.2 ADS-B航迹数据处理

1.2.1 航迹对象建立与维持更新

航迹处理模块收到ADS-B报文后, 将根据报文数据建立并维持更新对应飞行目标的航迹对象。航迹对象的建立与维持更新流程如图1 所示。

1.2.2 航迹过期清除

航迹目标在持续一段时间未收到对应飞行目标的ADS-B报文后, 则判断飞行目标已飞离可监视区域或已降落, 需对缓存中的航迹对象进行清除。航迹过期清除的方法为:定期遍历航迹轨迹缓存中的航迹轨迹对象, 判断航迹轨迹最后更新时间距系统当前时间是否超过预设阀值T;如果满足, 则需同时清除对应的航迹ID缓存、航迹轨迹缓存和航迹对象缓存数据。

1.2.3 航迹动态数据存储

为实现对飞行目标历史飞行轨迹的快速查询, 航迹动态数据存储采用数据库存储方式, 定期遍历航迹对象缓存中的全部航迹信息, 以数据记录的形式存储至航迹数据库中。

2 面向WEB的数据分发服务

2.1 基于Json的数据分发服务

Json是一种轻量级的新型数据交换格式, 它与XML一样都是一种可扩展标记语言, 在执行相同数据的交换处理时, 采用Json数据格式比XML数据流量更小, 可有效节省带宽。

ADS-B航迹数据分发采用Json数据格式, 根据浏览器请求动态封装数据报告后, 响应输出数据内容。提供实时飞行动态报告、定制飞行动态报告和历史飞行动态报告三类服务。航迹数据报告输出的数据格式如下:

2.2 面向WEB的数据服务架构

面向WEB的监视数据处理服务架构设计需综合考虑WEB用户多、并发访问压力大的特点, 同时保证服务运行的安全性和稳定性。本数据处理服务架构的设计采用多线程调度模式, 服务架构设计如图2 所示。

2.3 WEBGIS目标显示处理

为实现目标的可视化, 用户浏览器端采用基于WEBGIS富客户端数据处理显示。主要功能包括地图控制和航迹显示处理两部分。

(1) 地图显示控制, 基于WEBGIS服务, 提供地图服务切换、图层显示控制、放大、缩小、漫游、信息查询等功能, 同时提供地图点、线、面等元素的标绘功能。

(2) 航迹显示处理, 航迹显示处理流程如图3 所示。

3 系统实现

系统实现基于J2EE技术体系, 构建了面向低空的飞行动态监视系统。整体采用轻量级技术架构Spring MVC构建了集中式的数据处理, 实现了WEB模式的数据处理与服务, WEBGIS平台采用国家公共地理信息服务平台“天地图”, 可提供交通、卫星影像、地形及混合地图等多种地理信息服务。系统飞行动态监视界面如图4 所示。

4 结语

本文介绍了构建面向WEB的低空飞行动态监视系统的技术方法和实现途径, 并基于WEBGIS平台构建了原型系统。相比传统C/S模式软件, 本系统更适用于实现异地多站点ADS-B数据组网的数据中心平台建设, 以实现服务的网络化共享并减少设施的重复建设, 为低空飞行监视信息化提供了新的思路。

参考文献

[1]周雷, 辛晓娜, 陈川波.结合ADS-B的航管监视数据融合关键技术[J].计算机工程与应用, 2013, 49 (14) :231-235.

[2]Zhang Jun, Liu Wei, Zhu Yanbo.S t u d y o f A D S-B D a t a Evaluation[J].Chinese Journal of Aeronautics, 2011, 24:461-466.

[3]胡曼.基于ADS-B飞行航迹处理与滤波[D].成都:电子科技大学, 2009.

[4]韩敏, 冯浩.基于JSON的地理信息数据交换方法研究[J].测绘科学, 2010, 35 (1) :159-161.

[5]秦永平, 汪群山, 王晓芳.基于Web GIS的公共卫生预警预测系统设计与实现[J].计算机应用与软件, 2014, 31 (4) :94-97.

动态监视系统 篇2

高速公路监视系统数字化建设

数字化是高速公路监视系统的发展方向,基于高速公路监视系统的现状,主要介绍了在新建高速公路监视系统的`建设中采用数字化网络摄像机,高性能的传输网络,IP-SAN的存储技术,分析了原有模拟监视系统改造的几种方案,提出了升级改造的建议.

作 者：闫红利 YAN Hong-li  作者单位：山东高速信息工程有限公司,山东,济南,250108 刊 名：山东交通科技 英文刊名：SHANDONG JIAOTONG KEJI 年，卷(期)： “”(3) 分类号：U412.36 关键词：数字化网络摄像机   IP-SAN   骨干传输系统   网络编码器  

动态监视系统 篇3

1 系统运行现状

1.1 业务体系

国家层面分别设立国家海域动态监管中心、同步数据中心和网管中心,地方层面建立了11个省级、49个市级海域动态监管中心,部分省成立县级海域动态监管中心,从而形成国家、省、市三级业务机构体系[2,3];其中,独立监管中心有13家、挂靠在其他事业单位的有45家、与海域管理部门合署办公的有2家,有44家取得海洋测绘资质。在辽宁省、江苏省和海南省建立3个海域无人机遥感监测基地。通过引进和培养,全国从事海域动态监视监测工作的专业技术人员已达600余人。

1.2 系统功能

按照“需求主导、服务管理”的原则开发设计了一套可定制、模块化、接口灵活的平台软件,形成基本业务系统、视频监控系统、视频会议系统、公文传输系统、人员管理系统、专网管理系统、专网邮件系统、地方附加系统等8个应用子系统,目前系统具备监视监测、业务管理、决策支持、信息服务和视频会议五大功能。建立了连接国家、省、市、县四级海洋部门的专线网络,经不断升级和扩容,国家骨干网双线路运行、带宽30 M,省级网络带宽10~20 M,市级网络带宽4~10 M;专网已连接至海域管理部门、海域动态监管中心、海域执法机构,专线节点335个、无线节点228个,形成四级海洋部门之间的信息高速公路。省、市监管中心在重点海域建设了361个视频监控点,接入国家海域远程监控集成平台225个。

1.3 监测业务

国家层面每年对近岸海域开展1次高精度遥感监测和4次低精度遥感监测;利用无人机每年对区域用海规划开展1次遥感监测;每月开展1次海域使用疑点疑区监测。省、市监管中心定期开展重点用海项目现场监测,并编制项目海域动态监测报告,对部分已竣工验收的重点项目用海探索开展了后评估监测。河北省、江苏省、广东省等地对海岸线、海湾等开展了海域空间资源监测。

1.4 系统数据

通过海域权属数据整理工作,完成了《海域使用管理法》实施以来审批的6万余宗用海数据的整理录入,开展了2次沿海基础地理信息数据的更新及沿海11个省级海洋功能区划数据的标准化处理。采集了近岸海域高、中、低分辨率的遥感影像,现有1993年、2002年以及2007年以后多期低分辨率(30m)遥感和3期高分辨率遥感影像,影像数据已经超过2T。通过分级部署的专题数据库,实现对基础地理、遥感影像、功能区划、海域勘界、岸线修测、海域权属、现场监测等数据的集成管理,形成全国海域资源和海域使用状况“一张图”。

1.5 系统应用

各地利用基本业务系统有序开展了海域使用审批统一配号、海洋功能区划管理、区域用海规划管理、海域使用统计、海域使用金管理、围填海计划管理等业务。各级监管中心利用系统为海域管理部门项目用海审批和围填海竣工验收提供技术支持,对新申请项目从功能区划符合性、界址与面积准确性、管理岸线吻合性、用海权属唯一性等方面进行技术审查。辽宁省、福建省、海南省等地开展了填海项目竣工验收报告的技术检验复核。各地积极配合海域使用执法部门开展区域用海执法检查、涉嫌违规用海项目现场测量;并利用监测数据积极编制本地海域使用现状分析报告、海域使用统计分析报告、围填海监测报告、区域用海规划监测报告、海岸带变化遥感年际比对分析报告等辅助决策产品,为海域管理科学决策提供技术支撑。

2 存在的主要问题

2.1 标准制度体系待进一步完善

目前仅在系统建设期间制定了系统建设与管理意见、系统质量监督管理办法、系统数据管理办法、系统传输网络管理办法等管理制度以及系统总体实施方案及总体技术方案、海域使用卫星遥感动态监视监测技术规程(暂行)、海域使用地面监视监测技术规程(暂行)、海域使用动态监视监测数据库建设技术规程(暂行)等标准规范。随着海域动态监视监测业务体系的不断壮大和监视监测内容的不断深入,尤其是国家全面深化改革要求进一步加强事中事后监管,现有管理制度和标准规范已不能满足业务发展需要。

2.2 机构队伍建设待进一步加强

目前仅建立国家、省、市三级海域动态监测业务体系,由于县级海域动态监测机构尚未完全建立,监测业务难以深入到海域管理第一线,上下协同、决策会商、应急处置等不能延伸到基层海洋部门,县级海洋部门缺乏有效的技术支撑,难以形成整体的监管合力。部分节点由于人才引进困难,存在一人身兼多职现象,技术队伍力量较为薄弱,缺乏计算机、测绘、遥感和地理信息系统等专业技术人才。

2.3 职责定位待进一步明确

部分省、市对海域动态监视监测工作在海域管理中的地位和作用认识还不到位,对监管中心的职责定位不清晰。部分市级节点由于海域使用审批业务较少,监测主体业务不明确,对监管机构重视程度不足,缺乏开展监测工作的积极性。部分省市在沿海成立具有用海审批权限的开发区,但新成立的开发区海域动态监测机构缺失,在该区域的系统数据管理权限有待调整和明确,系统业务管理也存在一定的问题。

2.4 监测业务待进一步规范

目前监测手段仍相对薄弱,主要以遥感监测为主,现场监测数据较为缺乏;监测范围主要以近岸海域监测为主,对中远海的监测能力不足;监测内容较为单一,基本以围填海监测为主,对养殖用海等其他用海类型尚未开展有效监测。由于缺乏统一的监测技术规范,监测主体、监测内容、监测频次、工作流程等都未明确,各地监测内容和频次不一、监测报告格式多样,监测业务亟须规范。

2.5 系统数据待进一步补充

目前系统中海域资源环境本底数据匮乏,海域使用权属数据不够精确,海洋基础地理数据、公共用海数据不够全面,在一定程度上制约了海域综合管理的精细化水平;主要表现在由于历史原因用海权属尚未能全部纳入系统数据库,海洋基础地理、大陆海岸线变迁尚未实现常态化监测与更新,各类海洋调查获取的海域资源环境数据尚未得到有效利用等。此外,目前系统数据主要用于浏览和查询,基于系统数据的分析评价产品相对较少,辅助决策水平有待提高。

2.6 应用系统功能待进一步优化

现有软件系统总体架构模式相对滞后,应用系统未包含所有海域行政管理和海域动态监视监测业务,各业务模块较为独立、缺乏关联性,成果产品展示方式较为单一,缺乏多模式、立体化效果,与地方附加业务系统有待进一步整合。

3 发展趋势分析

3.1 业务体系建设

按照“建立全覆盖、立体化、高精度的海洋综合管控体系”要求,加快制定海域动态监视监测业务体系发展规划,科学制定系统中长期发展目标。推动省、市级监管中心机构建设,并全部取得海洋测绘资质。加快推进县级海域动态监管能力建设,成立县级海域动态监管中心,健全国家、省、市、县四级业务机构体系。进一步明确省、市、县三级监管中心职责和任务,理顺监测业务工作流程。加强系统业务培训和工作交流,尤其是加强遥感监测、专题图件制作、分析评价等方面的实践培训,不断提升技术队伍能力。

3.2 管理制度建设

制定系统运行相关管理办法和相关技术规程,规范工作内容及要求。出台《系统运行管理办法》《系统安全管理办法》《系统业务考核办法》等管理制度,以及《建设项目海域使用动态监视监测工作规范》《区域用海规划海域使用动态监测工作规范》《海域使用疑点疑区监测工作规范》《海域空间资源监测技术规程》等监测业务规范类文件,加强对监测业务和系统运维的指导。

3.3 监测业务拓展

在全面规范建设项目海域使用动态监测、区域用海规划监测、疑点疑区监测的基础上,深入开展海湾、海岸线等海域空间资源监测和海域海岸带整治修复项目监测。创新应用高分辨率卫星遥感、无人机遥感、无人船(艇)、激光雷达、一体化激光三维测量和水下潜标等监测手段,全面开展对中远海的监测,对我国管辖海域实现常态化监视监测,逐步建立全覆盖、立体化、高精度的海洋监控系统,实时掌握管辖海域的空间资源状况和使用现状。

3.4 应用系统优化

构建以项目用海管理为核心的应用系统平台,实现用海审批、监测、执法数据一体化管理。完善国家基本业务系统海域使用权管理、海域使用金管理、海域动态监视监测业务管理功能,利用系统对海域使用申请审批、海域使用金征缴等工作实现数字化、流程化管理。建立统一的海域管理信息发布平台,方便用海单位和相关个人查询项目用海确权信息及业务办理进展情况,为社会公众提供及时的海域管理信息服务。

3.5 数据体系建设

补充更新海域使用权属数据,收集整理公共用海数据、海洋资源环境数据、电子海图、海域海岛地名普查数据、涉海规划数据等相关资料,构建数据标准统一、内容全面、更新及时、共享服务完善的基础数据体系,开展数据资源规划和数据结构优化,实现海域基础数据与专题数据的一体化整合和统一管理,进一步夯实数据基础。

3.6 辅助决策支持

充分利用海域管理各类数据,全面开展海域使用现状、海域空间资源状况、海洋功能区划实施情况等分析评价工作,重点进行海域空间资源配置和承载力分析、海域资源发展潜力评估、海域资源经济社会效益分析、海域使用综合分析评价、海岸线变迁分析、重点海湾综合利用现状分析、围填海项目后评估分析、海洋产业用海需求分析等成果研究,为合理配置海域资源、优化涉海产业布局提供决策支持。协助海域管理部门开展项目用海申请的技术审查,在海域使用论证报告评审会召开前,重点做好论证报告宗海图件和功能区划符合性分析的校验工作;在填海项目竣工验收时复核项目竣工验收测量报告,及时为海域综合管理提供技术支撑。

3.7 联动监管机制

在海区、省市执法机构已全部接入海域动态专网的基础上,建立海域管理部门、动态监管中心和海洋执法机构间的联动监管机制,实现海域动态监测、权属数据、远程视频监控、违法用海案件查处等信息共享。各级监管中心应综合运用遥感监测、现场巡查、视频监控等手段,有效开展海域使用疑点疑区监测,做到随时发现、随时监测、随时报送至海域管理部门和执法部门;执法机构应将项目用海执法检查的照片、视频和违法用海项目的立案查处、行政处罚等结果信息录入系统,实现监测信息和执法信息的共享,提高海域综合管理效率。

3.8 系统安全建设

推进系统安全防护体系建设,全网按照国家级节点安全等级保护三级、省市节点安全等级保护不低于二级的要求,开展核心路由器设备、所有设备登陆双因子认证,增加入侵防御和安全接入网关,为各节点提供网络安全边界防护;加强网络安全管理,安装终端准入软件,严禁未登记的设备接入专网,严禁其他网络与海域专网私自互联。各地应根据设备的使用周期逐步开展网络、服务器、视频会议、视频监控和外业监测等硬件设备的升级改造,确保系统安全、稳定运行。

参考文献

[1]李谋胜.国家海域动态使用监视监测管理系统全面启动[J].海洋开发与管理,2007,24(3):179.

[2]赵建华,苗丰民,曹可,等.我国海域使用动态监视监测管理系统建设思路[J].海洋环境科学,2008,27(增2):90-93.

民航客机驾驶舱门监视系统简介 篇4

根据民航办发 (2008) 2号《关于民航客机加装机舱摄像监视系统有关事宜的通知》,

为了提高安全防范和应急处理能力, 保障飞行运输安全, 各航空公司已登记的按CCAR-121部运行的客机均要加装摄像监视系统, 文件颁发后新登记引进的按CCAR-121部运行的客机, 均须在投入运行前加装机舱摄像监视系统。

2功能和技术要求

2.1功能要求

机舱摄像监视系统是民航空防安全的配套部件, 主要功能是驾驶舱内的飞行机组成员可通过在机舱门附近安装的摄像头, 以视频方式监控机舱门附近的情况。

2.2技术要求

机舱摄像监视系统摄像头数量须满足驾驶舱门周围监视范围无死角;监视器的安装和操作须满足驾驶舱内飞行机组人员在不影响飞行操作并无需离开工作位置的前提下, 对驾驶舱门周围情况进行全方位观察;系统加装时须保证监视画面传输管线接口安装至起落架或机舱外其他部位 (即地面监视外接功能) , 以满足在外接显示器上可现实舱内监控画面。

3系统基本组成

3.1系统组成

驾驶舱门监视系统主要由1个监视器、1个控制板、3个摄像头、1个视频转换装置 (VSU) 组成, 系统架构见图1。

3.2视频转换装置

视频转换装置主要用来接受摄像头拍摄的图像并将其中一路传送至监视器。

3.3摄像头

摄像头安装于飞机前服务区天花板, 使用三个摄像头就能保证360°无死角覆盖驾驶舱门外区域。摄像头拍摄视频信号传送至视频转换装置。

3.4监视器

LCD监视器可安装于飞机驾驶舱顶部板, 便于机组人员在座位上观察。监视器接收来自视频转换装置的视频。监视器对比度、亮度等由控制板对应的旋钮调节。

3.5控制板

控制板可安装于飞机驾驶舱顶部板, 便于机组人员在座位上操作。控制板能选择监视器显示哪一个摄像头拍摄的视频, 调节监视器画面的亮度和对比度。控制板如图2所示。

3.5.1 ON/OFF/STBY开关

将开关拨动至ON位置, 系统开启, 并且默认显示左摄像头拍摄图像。

将开关拨动至OFF位置, 系统关闭。

将开关拨动至STBY位置, 仅关闭监视器。

3.5.2 CAMERA+/CAMERA-开关

通过拨动CAMERA+/CAMERA-在监视器上选择不同摄像头拍摄的图像。

3.5.3 BRT旋钮

通过调节控制板上BRT旋钮, 可以改变监视器显示亮度。

3.5.4 CONTRAST旋钮

通过调节控制板上CONTRAST旋钮, 可以改变监视器页面对比度。

4展望

此设计方案是实时模拟视频监控, 无视频存储及回放功能。后期可将模拟视频数字化并加装大容量存储器存储拍摄的视频, 并可以从外接视频接口导出查看。

5结束语

本文主要介绍了典型的民航客机驾驶舱门监视系统的组成及相关设备, 在设计民机驾驶舱门监视系统时, 我们应借鉴国际上典型的设计理念进行设计。

摘要：民航客机机组成员可驾驶舱门监视系统监控机舱门附近的情况。驾驶舱门监视系统由摄像头、监视器、视频装换装置和控制板组成。

动态监视系统 篇5

随着互联网和多媒体技术的发展,人们对于远程监视的需求也日益增加(如:矿区,煤田,医院等)。而在这些地方,人们对数字图像在质量、大小和应用上提出了更高的要求,本文结合JPEG2000图像标准和TCP/IP协议来进行的远程监视。由于采用JPEG2000静止图像作为媒体流,从而避免了类似H.263等流媒体,在网络环境恶劣的情况下,出现帧同步丢失而造成用户端的解码失败,而使得用户端不能实时的观察到相应监视点的情况。并且由于JPEG2000标准中加入了感兴趣区域(Region of Interest)压缩和无损压缩特征,这对于监视系统来说是非常重要的优点。系统框架如右图:

从图1中可以看出客户和监视点是多对多的关系,使得系统可以灵活的适应更种场合。

2 JPEG2000的原理和特征

JPEG2000标准与JPEG相比提供了许多新的特征,这些特征在实际的应用中,有着更丰富的选择。它包含有四种模式(顺序模式,渐进模式,无损模式和分层模式)。在编码端以最大的压缩质量(包括无失真压缩)和最大的图像分辨率压缩图像,它的最主要的特征如下:

(1)高压缩率:由于在离散子波变换算法中,图像数据可以转换成一系列更加有效存储像素模块的“子波”。因而,JPEG2000格式的图片压缩率比JPEG图片基础上再提高10%~30%,而且压缩后的图像显得更加细腻平滑,这一特征在互联网和遥感等图像传输领域有着广泛的应用。

(2)无损压缩和有损压缩:JPEG2000提供无损和有损两种压缩方式,无损压缩在许多领域是必须的,例如监视系统中发现异常时,要求清晰的再现监视场景的情况。再如图像档案中为了保存重要的信息无损的图像质量是必须的。

(3)感兴趣区域压缩:可以指定图片上感兴趣区域(Region of Interest),然后在压缩时对这些区域指定压缩质量,或在恢复时指定某些区域的解压缩要求。这是因为子波在空间和频率域上具有局域性,要完全恢复图像中的某个局部,并不需要所有编码都被精确保留,只要对应它的一部分编码没有误差就可以了。

JPEG2000主要是规定了一系列对连续色调、二值、灰度或彩色数字静止图像的无失真或有失真编解码方法[1]。JPEG2000的基本系统结构框图[3]如图2所示。

可见,JPEG2000改变了JPEG标准以DCT变换为核心的变换方法,采用了具有能量特性更为集中的小波变换以及率失真优化截取的内嵌码块编码算法(EBCOT)。

3 系统原理分析

监视系统采用JPEG2000格式图像数据作为的数据流,而当中的JPEG2000压缩编码采用小波变换为基础,且在系统中采用了JPEG2000中的感兴趣区域(ROI:regions of interest)特征。下面描述小波变换和ROI的原理。

3.1 小波变换原理

3.1.1 小波与小波变换——定义1

定义1设L2(R)是一个可测的、平方可积的一维函数矢量空间,R为实数集。小波是由满足的函数ψ(x)通过平移和缩放而产生的一个函数族ψa,b(x):

ψa,b(x)称作分析小波(Analyzing Wavelet)或连续小波,当且仅当母小波函数ψ(x)的Fourier变换ψ(ω)满足以下可容性(admissibility)条件:

这里,a被称作伸缩因子,b为平移因子。

3.1.2 小波与小波变换——定义2

定义2在定义1的基础上,函数f(x)在L2(R)上的连续小波变换定义如下:

小波变换的实质在于将L2(R)空间中的任意函数f(x)表示成为在ψa,b(x)的不同伸缩和平移因子上的投影的叠加,与Fourier变换不同的是,小波变换将一维时域函数映射到二维“时间-尺度”域上,因此f(x)在小波基上的展开具有多分辨率的特性。通过调整伸缩因子a和平移因子b,可以得到具有不同时频宽度的小波以匹配原始信号的不同位置,达到对信号的局部化分析。

相对于传统的DCT块变换,小波变换具有以下优点:

1)小波变换具有熵保持特性,能够有效地改变图像的能量分布,同时不损伤原始图像所包含的信息;

2)小波分解后大部分能量集中在低频子图的少量系数上;而大量的高频子图系数值普遍较小,且存在明显的相关性,有利于获得较高的编码效益;

3)小波变换作用于图像的整体,既能去除图像的全局相关性,又可将量化误差分散到整个图像内,避免了方块效应的产生;

4)多级分解后形成的不同分辨率和频率特性的子带信号,便于在失真编码中综合考虑视觉特性,同时有利于图像的渐进传输。

3.2 图像感兴趣区编码

在甚低比特率进行图像压缩时,往往会丢失一些细节信息,而其中有些细节信息是人们感兴趣的。例如人物头肩图像的视觉敏感区域,航空图像中携带重要信息的小目标区域,医学图像中病灶区域等等,这些区域可以统称为感兴趣区域(ROI:regions of interest)。

3.2.1 ROI图像编码

ROI图像编码就是要提高ROI系数的的编码优先级别,使ROI系数能优先传输,从而获得优于背景区域的压缩性能。通常采用两种途径改变ROI系数的优先级别。由于内嵌比特平面编码首先传输的是幅值最大的量化系数的位信息,所以一种方法是对ROI系数的幅度值进行比特平面提升(需要进行移位运算),再进行常规的比特平面编码。另一种是首先进行通常的比特平面编码(ROI系数必须独立编码),最后在码流组织时,优先传输ROI系数的比特流并分配更多的码率。

JPEG2000标准中采用的比特平面提升方法是完全提升方法(Max Shift),如图3(b)所示。编码器扫描所有的量化系数,找到一个s,使提升后的ROI系数的最小值大于背景区域系数的最大值。s要传送给解码端,解码后的系数若大于2s,则进行比特平面降低,因此这种方法无需传送ROI的坐标信息,解码器也无需计算ROI模板。

3.2.2 实验结果与分析

下面以标准测试图像Lena(512×512×8比特)为例,给出了实验结果。在编码之前,图像经过5级(9,7)小波分解。

在表1中,我们给出压缩比为8倍时(1.0bpp)不同提升比特平面s所对应的峰值信噪比PSNR比较。其中当s=0时,表示无ROI编码。实验结果表明,对图像ROI区域进行优先编码后,恢复图像的ROI信噪比能大幅度提高,但这是以背景部分信噪比降低为代价的。ROI的信噪比随s增大而相应提高,背景区及整体图像的信噪比则随s增大而逐渐降低。加权信噪比则和主观视觉基本保持一致,当ROI的比特平面提升1位时,感兴趣区信噪比明显提高,而背景部分的恢复质量下降,但基本不影响视觉效果,所以加权信噪比也明显提高;当s继续增大时,背景的恢复质量下降了近3dB,严重影响了主观视觉效果,所以加权信噪比也随之降低。图4所示为在甚低比特率0.1bpp压缩时的恢复图像比较,可以看出无ROI编码时(s=0),ROI和背景部分都有着严重的视觉失真,而ROI系数经过提升后能够保持良好的视觉质量。

4 系统软件结构

由于JPEG2000格式图像比JPEG格式图像在压缩率上大约有30%的提高且可以进行ROI的选择和渐进显示。而相对比于流媒体H.263等,由于JPEG2000采用帧内编码,所以不存在帧间同步的问题,例如在无线网络中,客户端接收数据由于网络环境的变化而出现较长时间的延时,如果采用H.263等就可能由于帧间失去同步,而造成解码的困难。而利用JPEG2000图像,在保证数据量小的情况下,也可以保证客户可以看到监视点的情况,只是此时的图像数据显示的速率可能会慢一些,而不会出现由于网络环境恶劣的情况下,不能观察到相应的监视场景。所以系统中采用JPEG2000格式作为相应的传输数据流,而没有采用流媒体H.263等的原因。

软件部分采用模块化设计,并充分的利用多线程(Multi Thread)和Intel CPU P4中的SSE2指令,利用SSE2指令对其中的JPEG2000的解码程序进行了相应的优化,使得解码的速率比用C语言的解码速率提高了7倍,这样就使得网络速率成为了最终的瓶颈。

软件结构包含有客户端和服务端,分别都采用多线程来实时的响应事件的请求。每个客户可以同时进行16路的监视,而服务端在理论上可以同时为无数的客户端服务,可实际的系统资源有限,要根据实际的情况来处理。

服务端单元采用COM技术封装了双线程来实现一个客户端的连接,来进行后台相应的服务处理,当中有相应的编码,解释请求控制字和传输。客户端单元同样也采用了多线程进行相应的服务请求,在界面上进行人机交互的请求,而在后台利用工作线程进行相应的处理。

程序流程如下:

当客户有ROI需求时,发出带有坐标的控制字到服务端,由服务端进行相应的命令解释,对相应的坐标区域进行相应的无损压缩后传输,而对于客户不关心的区域可以不处理,这样进一步减小了相应的网络所需的带宽了,可以提高服务端的系统资源利用。

渐进需求时,当网络环境恶劣时,由于使用TCP/IP协议会出现丢包率增加,对于服务端来说会反复的重传数据,而导致的就是使得客户端不能即时的看到监视场景的情况,所以在出现网络环境恶劣情况下,结合采用JPEG2000当中的分辨率渐进方法来进行相应的传输,进一步减少传输所需要的数据量,而使得客户可以实时的观察到相应的监视场景。

5 测试结果

图像数据源采用24倍压缩后进行硬件编码。经过实际的Internet网络实验,每次数据都取2小时的平均值,这样减少由于网络环境的因素影响。可得实验数据测得如下:

在局域网的测试中,利用1点对4点进行监视时,在320*240彩色的分辨率的情况下,可达到23.572frame/s基于上达到了监视系统的要求,而在实际的网络中,由于网络问题,存在一定的延时,但图像质量和ROI请求都满足监视系统的要求。

6 结论

本文提出了基于JPEG2000格式的监视系统,并充分利用了JPEG2000中的ROI特点,从实验结果看,效果可以满足大多数监视应用要求。整个系统已经通过了实际网络测试,完全达到项目要求。

参考文献

[1]JPEG2000Part I Final Committee Draft Version1.0,ISO/IEC JTC1/SC29/WG1N1646R,March2000.

[2]D.Taubman,“High Performance Scalable Image Compression with EBCOT,”[J]IEEE Trans.Image Processing,vol.9,no.7,pp.1158-1170,July2000.

[3]C.Christopoulos,A.Skodras,and T.Ebrahimi,“The JPEG2000Still Image Coding System:An Overview,”[J]IEEE Trans.Consumer Electronics,vol.46,no.4,pp.1103-1127,Nov.2000.

[4]D.Taubman,E.Ordentkich,M.Weinberger,and G.Seroussi,“Embedded Block Coding in JPEG2000,”[J]HPL-2001-35,HP Labs,Palo Alto,Feb.2001.

[5]D.Taubman,E.Ordentlich,M.Weinberger,G.Seroussi,I.Ueno,and F.Ono,“Embedded Block Coding in JPEG2000,”[J]IEEE Int.Conf.Image Processing,vol.2,pp.33-36,Sep.2000.

[6]李云松,“实时军事图像编码研究”,西安电子科技大学博士论文,2002.

[7]陈军,“高效图像内嵌编码技术研究”,西安电子科技大学博士论文,2002.

机械设备监视与诊断系统开发 篇6

本文讨论的机械设备监视与故障诊断系统建设应做到构架合理, 信息通信能力强, 采用的技术3~5年内不会被淘汰, 并有较好的更新换代能力。安全性能高, 抗灾性能强, 覆盖工商各项业务, 能够实现多部门业务审批。数据传输速度快, 能够实现异地数据存储与交换, 各项数据可以实现异地查询。

2 系统应具备的功能

1) 对被诊断的机械设备进行测量, 以获取当前运作状态的相关数据信息。

2) 对当前设备状态参数、设备周围环境与数据库中的各种典型情况或参数零界点的阀值进行匹配。

3) 如匹配结果为阳性, 系统可自动发出警报, 并将当时的设备各项参数、环境情况、故障点、故障时间等数据记录在服务器数据库中, 以备日后报表生成、数据分析、汇总统计等。

4) 全天候监视设备运作的同时可实现故障知识库的更新。尽可能将所有最新的检测技术更新到系统中, 以找出更多隐患并故障预警。这些系统或检测方法更新必须及时快速, 为此, 本系统必须能容易地进行二次开发。

3 系统设计

3.1 系统框架设计

本文设计的状态监视与故障诊断系统的框架是按照分层结构设计的。它们分别为:应用层、接口层、服务层、数据层。架构示意图如图1所示。

应用层:显示设备当前状态、采集现场数据信息、故障报警的程序与报警表现形式 (显示提示信息、发错声音或短信等) 、传输数据信息、辅助远程服务器的诊断中心 (针对客户端, 主要处理常见的故障) 、故障诊断 (针对服务器端) 、存储数据。

接口层:起承上启下的作用。接口本身也就是一个规则的集合, 它会集成下层的服务, 统一应用层向下层传输的数据格式, 主要工作是监视服务入口。

服务层:由设备运行监测服务、系统运行检测服务、软件运行监测服务、数据状态监测服务、网络运行监测服务、故障管理服务组成。

服务链机制:简单地说, 本系统是一个基于面向服务开发的系统, 而将服务逐个构建完成之后通过组装就形成了服务链。本文创新地将原本独立存在的各种监视服务, 依照需求中数据流的流程将服务串联起来, 组装成了一个状态监视服务链。这样一来, 状态监视任意一个环节突发故障了, 都能够沿着状态监视服务链追踪故障, 进行故障定位与成因分析, 保障了故障检测诊断顺利进行。

数据层:数据层是系统的要素层, 包括设备运行状态、系统状态、软件状态、数据到达状态、网络状态、故障管理等。

3.2 数据库设计原则

在系统的数据流确定, 框架与接口都设计完成之后就需要进行数据库设计以便之后的功能设计参考。

数据库是系统建立的基础, 设计良好的数据库是设计实现一个性能强大且具有良好健壮性系统的必备条件。在机械设备与故障诊断系统中, 设计数据库遵循了以下3个方面的原则:

1) 以关系模型为主体。虽然现在也出现了面向对象数据库的设计思想, 但是由于很难用于实践, 现行系统仍多以关系数据库为主。

2) 关系模式规范化。在关系数据库逻辑设计时, 我们要考虑如何构造一个适合于某一具体问题的数据模式。这就牵扯到数据库逻辑设计的工具———关系数据库的规范化理论。关系模式的规范化就是根据一个关系属性间不同的依赖情况来区分其为第一、第二、第三和第四范式, 然后用直观的描述将具有不合适性质的关系转换为更合适的形式, 关系模式规范化的过程是通过对关系模式的分解来实现的, 把低一级的关系模式分解为若干个高一级的关系模式。

具体地说, 按照以上的几个约定俗成的范式规则, 通过不断拆分的方法, 将某个复杂的二维表转化成若干个相对简单二维表。然后再对表与试题之间建立一个表只描述一个实体 (即一对一) 的关联。这就是规范化设计的过程。本系统中采用第三范式作为表的设计标准。

3) 数据库保持。由于本次系统设计是针对旧有系统的一次大改造, 但是本次客户的数据库却被多个系统同时使用, 因此本系统的数据库设计必须保证在不能破坏原有系统下开发。于是课题组规定:不得删除、修改现存数据库的结构。如果功能需要, 本次开发主要采用增加新的数据库来适应现行数据库。如果有数据需要, 可以预先设计一个暂存数据库, 将过渡性数据放在其中处理。

总之, 一定要保持原有数据库的所有数据结构, 使新系统上线后不会影响其他使用该数据库的系统。

3.3 故障诊断

1) 故障识别基本概念

故障识别是在故障信息监视和故障特征分析的条件实现的。

对这些当前设备状态参数和设备周围环境与数据库中的各种典型情况及参数零界点的阀值进行匹配。如匹配结果为阳性, 系统自动发出警报, 分析出故障可能的种类, 进而交由故障诊断部分分析出结论。

从故障识别与软件相结合以来, 国内外相关技术的发展非常快, 已建立了丰富的故障知识库, 并在理论和实践两个层面上不断完善了模式识别, 在个人电脑语言方面也进行了大量研究, 尤其是在某些未知原因的问题研究中采用了许多先进的理论和方法。

任何机械设备故障诊断技术的本质是侦测和读取机械设备在运转过程中的状态是否正常。根据经验和部件的设计指标、预测机械设备的可靠性, 以此实现机械设备故障的尽早发现, 并对其原因、部位、危险程度进行判定, 预测故障的发展趋势, 在此基础之上自动操作或通过向操作员发出警告以便管理者对故障进行正确处理。

故障诊断实施的具体方式要视诊断对象、诊断目标、操作员能力与仪器手段等具体情况而定。大型旋转机械在企业生产中具有绝对重要的地位, 通常均采用在线监视和精密诊断方式。

分散的远端客户端将工作参数传到WEB应用程序之后, 由WEB服务器统一处理 (仅汇总与记录) 、存储 (仅记录LOG所需信息) 和转发到实验室服务器。通过实验服务器的接受工作参数、调用功能函数, 然后由测控系统将传来的参数转化成控制信号并发布到子系统试验台 (类似一个仿真实验平台) , 就完成了由上至下的工作。

当实验台完成全部操作之后, 再反向地由测控系统运用数据采集功能, 向实验台采集实验数据并转发到服务器的数据库中, 经过相应的工作函数处理, 对工作数据进行分析、处理并形成以图像、参数数据为表现形式的实验结果。最后将实验结果经WEB服务器转发到网上, 供远程的客户端通过浏览网页的方式得以使用。

2) 故障诊断的专家系统

故障诊断专家系统是指通过各种探头之类的传感器设备, 收集机械设备的运行状态和环境信息, 而这些信息通过某些具备专家经验的规则诊断、推理之后, 可以最终找到一种或几种可能的故障及故障原因的所在, 最后由推理机器将结果呈现给用户, 由用户来证实。

专家系统是以故障诊断领域专家知识为基础, 使个人电脑能模拟人类专家的思维方式, 在专家知识库的依赖下模拟为具有专家水平的、具有解决本领域内复杂问题能力的人工智能。因此, 知识获取的基本任务就是为专家系统的知识库获取知识, 设计完备有效的知识库, 以满足解决该领域问题的需要。

4 结语

本文通过对系统实现设计的分析以及所使用的技术的优点分析, 介绍了专家系统的可实现性以及功能上的优点和可靠性。通过对现行设备监视模式与故障诊断方式的分析, 可学习前人在这类系统开发中取得的成果, 尤其是在故障诊断方面的知识。本文将前人研究的专家系统等较为成熟的诊断技术运用到本系统中, 解决了本系统在故障诊断算法中遇到的难题。

摘要：对基于WEB的监视与故障诊断系统的需求进行了详细分析。设计了系统的实施方案, 确定了结构模式。

关键词：状态监视,故障诊断,专家系统

参考文献

[1]张桂元, 贾燕枫.Struts开发入门与项目实践[M].北京:人民邮电出版社, 2005.

[2]阎宏.Java与模式[M].北京:电子工业出版社, 2002

[3]佚名.浅析Struts体系结构与工作原理 (图) [EB/OL].[2005-09-27].http://java.chinaitlab.com/Struts/36086.html

[4]孙卫琴.精通Struts:基于MVC的Java Web设计与开发[M]..北京:电子工业出版社, 2004.

动态监视系统 篇7

1 背景

某景区有一往复式索道，索道缆索用多个支架支撑，上站和下站落差很大，风速风向对索道车安全运行影响很大。该索道系统本身含有一个风速风向系统，但其只能监测上站风速风向数据，且数据不保存，无法传递信息到总控站。为保障运输安全，用户希望开发一个风速风向采集监视系统，实时采集索道关键支架区域的风速风向数据并能进行图形显示，其数据作为能否发车的主要依据，采集的风速风像数据保存在数据库。

2 系统架构

风速风向仪安装在支架上，统一编址, 通过无线方式连接上下站收发器。采集计算机放置在总控站，计算机COM口外接RS-232-RS-485转换器, 通过485总线连接上站收发器。采集程序采用周期轮询方式询问风速风向仪，获取其监测数据，然后通过udp协议发送给中心监视器并存储于数据库中。中心监视器通过图形化的界面显示风速风向数据，并能实时报警。远程监控端通过读取数据库中最新记录显示每个监测点的风速风向数据(可以有两种显示模式：表格式和图形式)。系统架构如图1所示。

串口接口参数：通讯速率9600波特，8位数据位，1位停止位，无校验位。

通讯协议：主机发送被采集风速风向仪地址码：Ax;被采集风速风向仪应答：4EXXXXEXXXX0A0D;

3 主要软件功能模块

1)采集服务器软件：采集服务器计算机通过RS-232转RS-485连接收发器，收发器再通过无线方式连接多台风速风向仪。采集服务器软件通过定时轮询读取风速风向仪的风速风向数据，读取后通过udp协议快速发给中心监视器计算机，并同时将读取的数据送往数据库服务器存储。

2)中心监视软件：中心监视器软件通过udp协议接收采集服务器发来的数据，并用图像化的界面实时显示每个风速风向仪的数据，并对超过警示的数据采用颜色和声音报警。

3)远程监视软件：远程监视器软件通过读取数据库中最新纪录，以图形化的界面显示每个风速风向仪的风速风向数据，并对超过警示的数据采用颜色和声音报警。

4 采集服务器软件

4.1 采集服务器软件分析

对采集服务器软件需求分析后，描绘系统的组成单元包括定时单元，串口发送单元，串口接收单元，协议编解码单元，显示单元，存储单元，参数配置单元，安全认证单元，采集控制单元等。

工作流程为：定时系统启动一次批采集，采集控制询问A1风速风向仪，等待其返回监测数据。等待时间为n毫秒, 若收到数据, 则解码写入接收缓存区尾部, 发送信号启动保存处理, 自己立即返回继续轮询下一个风速风向仪。若等待超时, 则修改特定标志, 继续轮询下一个风速风向仪, 直到完成本次轮询。同时, 存储单元在等待保存信号, 一旦收到该信号, 其从缓存队列头部取得数据保存到数据库。

4.2 采集服务器软件结构

如图2所示, 串口发送单元和串口接收单元合并为串口通讯单元, 可使用现有的SPCOMM组件。从工作过程分析，COM口发送、接收、采集数据存储等功能单元互不相关，为提高系统实时性和效率，采用多线程技术，存储功能同系统其他功能由不同线程完成。为了保证它们操作的正确次序(发--收--存)和对共享资源正确访问，必须采用线程同步技术。

4.3 SPCOMM串口通讯组件

Spcomm是一个Delphi串口组件，由Small-Pig Team开发，该组件封装了与串口通信相关的属性及事件，提供了对串口的相关操作，具有编程简单、通用性强、可移植性好等特点，是一个在Delphi软件开发中被广泛应用的串口通信组件。

4.4 多线程及线程同步技术

在本程序中，存储功能和COM通讯等工作在不同的线程，以提高实时性。PC机查询数据发送后，调度功能使用WaitForSingleObject函数进入等待状态，直到接收到有效数据事件内核对象变为已通知状态或等待超时。存储功能由另一个线程完成, 该线程平时处于等待状态，无限期等待二个事件中任一个发生, 一个是调度线程激发的数据保存事件, 当接收到数据后，调度线程将保存事件内核对象变为已通知状态后, 存储线程退出等待状态，从数据共享缓存队列, 从其头部取出数据, 调用存储过程将数据保存到数据库指定的表中。另一个是终止运行事件, 当主程序关闭时, 调度将终止事件内核对象变为已通知状态, 存储线程退出等待状态。

5 中心监视软件

中心监视软件使用多线程与采集服务器进行udp通信，使用绘图函数，将风速风向数据以图形化的方式显示。一台机器可以通过设置有选择的监视多个风速风向仪的数据，并根据报警参数设置实时报警。如果监测点较多，可以使用多台机器对不同地点的风速风向议进行监视，从而达到监视覆盖全网的目的。

5.1 udp代码举例

5.2 风速风向监视图

图3为风速风向监视图。

6 结束语

该系统已投入运行，现有8个采集点，每点采集时间为200ms，一个周期设为2s, 现系统工作正常。

摘要：该系统使用delphi7.0和SPCOMM组件开发一个风速风向多点采集软件, 使用c#开发监视软件, 其中采用了多线程、线程同步和udp协议传输技术以实现最大程度的实时性, 系统已投入使用。

关键词：SPCOMM,多线程,线程同步,C#

参考文献

[1]Robinson S.C#高级编程[M].北京:清华大学出版社, 2002.

[2]Richter J.Windows核心编程[M].北京:机械工业出版社, 2000.

串口监视过滤驱动及应用系统开发 篇8

1 系统综述及架构分析

1.1 系统综述

串口监视主要由串口过滤驱动程序及串行数据监视显示应用程序两部分组成。

WDM模型假定硬件设备可以有多个驱动程序，每个驱动程序都有自己管理设备的方法。WDM根据设备对象堆栈来完成驱动程序的分层。一个过滤器驱动程序，该驱动程序可位于功能驱动程序的上面或下面，它通过过滤流经它的IRP来修改设备的行为。

处于功能驱动程序之上的过滤器驱动程序称为上层过滤器;处于功能驱动程序之下的过滤器驱动程序称为下层过滤器。虽然这两种驱动程序本身用于不同的目的，但创建这两种驱动程序的机制完全相同。实际上，创建过滤器驱动程序就像创建任何其他WDM驱动程序一样，都有DriverEntry例程、AddDevice例程、一组派遣函数等。

上层过滤器驱动程序的用途是帮助支持这样的设备，这种设备的大多数方面都像其所属类的普通设备，但有一些附加功能。可以依靠一个通用的功能驱动程序来支持设备的普通行为。为了处理设备的附加功能，可以写一个上层过滤器驱动程序来干预IRP流。举一个例子，假设存在一个烤面包机设备的标准类，并且已经有人为其写了一个标准驱动程序。再假设特殊烤面包机有一个高级的面包片弹出特征，它可以把烤好的面包片弹到两英尺高的空中。而控制这个AWE特征的工作就是上层过滤器驱动程序的任务。

1.2 架构分析

串口过滤驱动程序：处于Windows串口驱动程序之上，其分析截取流经它的IRP所携带的串行口收发数据，并通过与应用程序交互将所截数据显示给用户查看，同时将数据向下层驱动发送以运行正常的串行操作，从而达到分析相关数据而不影响串口正常工作方式的串口监视的目的。

具体到本系统中串口过滤驱动程序就建立了一个串口过滤设备对象，其处于串口功能设备对象之上分析流经串口的所有数据，并将其保存起来。

与此同时，驱动程序还建立了一个数据交互设备对象，其主要用于完成与应用控制程序之间传递参数、读取数据等工作。

两个设备对象密切配合共同将流经串口的所有数据分析、传递给应用控制程序，以达到串口监视的功能。

串行数据监视显示应用程序：主要用于动态加载串口过滤驱动程序、发送串口号及交互事件、共享内存地址等必要参数，并开启监视线程接收串口过滤驱动程序的监视数据显示在用户终端上。程序使用VC6.0开发，运行独立稳定，交互性强。

下面的章节将分别具体分析系统两部分的原理实现及应用运行应用方法。

2 串口过滤驱动程序

2.1 开发方法及步骤

一旦最初的分析和设计完成，就要开始编写代码了。按照以下的步骤进行可以减少调试的时间。

(1)确定驱动程序需要哪些内核模式对象。

(2)确定驱动程序需要哪些上下文环境或者状态信息和这些信息的存储位置。

(3)首先编写DriverEntry和Unload例程，最初不要增加即插即用支持，这样允许通过控制面板手动地测试驱动程序的装载和卸载。

(4)添加处理IRP_MJ_CREATE和IRP_MJ_CLOSE的操作及一些不需要进行设备的访问例程。然后可以使用一个简单的WIN32程序调用CreateFile和CloseHandle来测试。

(5)添加寻找和分配驱动程序的硬件的代码，还有在驱动程序被卸载后的重新分配硬件的代码。如果硬件支持即插即用，这一步测试硬件和驱动程序的自动加载能力。

(6)添加处理IRP_MJ_XXX函数的派遣例程，最初的例程应该没有使用物理设备，后来新的代码应该使用简单的WIN32程序进行测试，例如ReadFile和WriteFile调用，或者其它支持的函数。

(7)最后完成Start I/O例程、ISR和DPC例程。现在可以使用真实的数据和硬件进行测试。

2.2 头文件编写及函数、变量、结构、常量的定义

头文件中首先定义了I/O控制代码，其主要用于DeviceIoControl API函数与驱动程序交互时的功能定义。

DeviceIoControl的Code参数是一个32位数值常量，如图1所示。

这些域的解释如下：

Device type (16位，CTL_CODE宏的第一个参数) 指出能实现这个控制操作的设备类型。

访问代码 (“A”占2位，CTL_CODE的第四个参数) 指出使用设备句柄发出这个控制操作时，应用程序必须具有的访问权限。

Function code (12位，CTL_CODE的第二个参数) 指出该代码描述的是哪一个控制操作。Microsoft保留了该域的前半部分，从0到2047的值。因此只能使用从2048到4095之间的值。

缓冲方式 (“M”占两位，CTL_CODE的第三个参数) 指出I/O管理器如何处理应用程序提供的输入输出缓冲区。

例如：在头文件中的

还有许多这样的功能代码共同完成了从应用程序到驱动程序的交互控制。

接下来在头文件中定义了一些结构，其他主要用于IRP传递时携带相关数据。

例如：在头文件中的

DEVICE_EXTENSION, *PDEVICE_EXTENSION;其主要用于设备对象的DeviceExtension (PVOID) , 该结构可用于保存每个设备实例的信息。I/O管理器为该结构分配空间, 但该结构的名字和内容完全由用户决定。程序中具体使用它来保存及获取过滤设备对象、绑定的设备对象。

IO_REQ, *PIO_REQ;其主要用于将截取的数据保存至此结构队列链表中，以方便应用程序来读取。

最后在头文件中声明了一些驱动例程，其用于完成驱动程序的全部工作。

例如：在头文件中的

DriverEntry是内核模式驱动程序主入口点, 一个驱动程序可以被多个类似的硬件使用，但驱动程序的某些全局初始化操作只能在第一次被装入时执行一次。而DriverEntry例程就是用于这个目的。后面的章节还将重点分析实现此例程。

2.3 驱动分析及实现

IRP是I/O request packet的缩写，即I/O请求包。驱动与驱动之间通过IRP进行通信。而使用驱动的应用层调用的CreatFile, ReadFile, WriteFile, DeviceIoControl等函数，说到底也是使用IRP和驱动进行通信。

一个IRP由两部分组成。首先是头部或者叫包的固定部分，是一个IRP结构。紧跟在这个头部之后的是I/O stack locations，这是一个IO_STACK_LOCATION结构的数组，这个数组中元素的个数是根据情况而定的，由IoAllocateIrp时的参数StackSize决定。而StackSize通常由IRP发往的目标DEVICE_OBJECT的+30 char StackSize决定。而这个StackSize是由设备对象连入所在的设备栈时，根据在设备栈中位置决定的。

一个驱动程序的应用层程序调用DeviceIoControl，让驱动程序完成一个任务。DeviceIoControl中会申请一个Irp，初始化，然后用这个Irp调用Io CallDriver发往设备栈的最高层。

IoCallDriver会根据Irp中的当前IO_STACK_LOCATION中的+00 byte MajorFunction，调用发往设备对象所属驱动中的相应函数。

因此驱动程序根据其要完成功能的不同可能需要处理几种类型的IRP，不同类型的IRP将对应不同的处理例程。在这里介绍本程序中发挥重要功能的IRP例程。

下面将分别分析实现它们。

2.3.1 DriverEntry驱动程序入口

每一个Win2000内核模式或者WDM驱动程序都有一个DriverEntry例程。这个例程初始化各个驱动程序的数据结构和准备其他驱动程序部分的运行环境。

在加载驱动程序的时候，I/O管理器调用DriverEntry例程。DriverEntry例程运行的IRQL是PASSIVE_LEVEL，这意味着它有权访问分页的存储器资源。

DriverEntry例程收到一个指向它自己的驱动程序对象指针，这个指针必须初始化。它也收到一个包含注册表中驱动程序的服务键的UNICODE_STRING结构。WDM驱动程序中很少使用这个注册名，内核模式的驱动程序依赖这个字符串去取出在系统注册表中存储的驱动程序特定的参数。这个注册的字符串的形式大概是HKEY_LOCAL_MACHINESystemCurrentControlSetServicesDriverName。

虽然WDM和内核模式的驱动程序有些不同，但大体上一个DriverEntry例程的执行步骤如下:

(1) DriverEntry例程查找它所控制的硬件，被分配的硬件标识在本驱动程序的控制之下。

(2)用指向其他驱动程序例程入口点的指针初始化来初始化驱动程序对象。

(3)如果驱动程序管理一个多功能的控制器，使用IoCreateController去创建一个控制器对象，然后初始化控制器的extension。

(4)使用IoCreateDevice去为每一个控制的物理或者逻辑设备创建一个设备对象，然后初始化设备extension。

(5)通过IoCreateSymbolicLink函数使这个设备可以被Win32子系统看见。

(6)将设备与一个中断对象联系起来，如果ISR需要使用DPC对象，就在这一步创建和初始化它们。

(7)重复第4步到第6步，直到完成这个驱动程序所有的物理的和逻辑的设备。

(8)如果成功DriverEntry例程应该返回STATUS_SUCCESS给I/O管理器。

Return value

STATUS_SUCCESS或者STATUS_XXX

如果DriverEntry例程因为某个原因而使初始化的过程失败，就应该释放任何占用的资源，返回合适的NTSTATUS失败代码给I/O管理器。

在本程序中，首先为驱动程序能处理IRP请求指定派遣函数，例如:

随后调后Add_IoControlDevice (DriverObject, RegistryPath) 用于创建一个与应用程序进行交互数据的设备对象。在Add_IoControlDevice中首先创建设备对象。

一旦硬件被识别和分配后，下一步是为每一个物理的或者逻辑的设备创建一个设备对象，大量的工作被IoCreateDevice函数作了，它的出口参数是设备对象的句柄，包括一个相应的设备extension。这个函数还连接新的设备对象到这个驱动程序对象管理的设备列表中。

IoCreateDevice的DeviceType参数是一个16-bit的值，这个值描述了被添加的设备的种类，微软保留了前一半范围给了定义，好的设备类型。剩下的32767个设备类型可以被定义，要小心定义不要与其他制造商的设备冲突。现在，微软预定义大约30种设备类型，这些预定义的类型值被赋予了象征性的名字，它的形式是FILE_DEVICE_XXX，例如，FILE_DEVICE_DVD。

实际代码如下：

接着再为设备命名，Windows中的设备可以有多个名字，被IoCreateDevice函数指定的名字是Windows执行部件识别设备的名字，这个内部的名字对于Win32用户模式的应用程序来说是隐藏的，为了暴露这个设备给Win32子系统、Win16子系统或者虚拟DOS环境，新的设备必须起一个符号连接名。

这两种名字分别在对象管理器名字空间的不同部分，对象管理器为所有的被操作系统管理的资源维持一个名字的目录，内部的设备名存储在目录树的Device下面，符号连接名则在DosDevices下面，当使用IoCreateDevice函数的时候，必须提供整个的Device名字，例如，“DeviceMinimal0”是一个适当的名字字符串。在C语言中必须使用双反斜线，因为单反斜线于一些字符合起来有时表示特殊的意义，例如，“n”，而双反斜线才表示一个反斜线字符，如图2所示。

内部的设备名和符号连接名遵循不同的命名习惯, 内部的设备名通常比较长且总是以基于0的数字作为结束。例如，FloppyDisk0或者FloppyDisk1。对于文件系统的符号连接名通常采用A到Z的模式。其他设备常是以基于1的数字作为结束，例如，LPT1或者LPT2。

使用IoCreateSymbolicLink创建一个符号连接名，这个函数序传递一个存在的设备名和一个新的符号连接名，它们都是UNICODE_STRING数据类型。

代码如下：

最后又定义了一个数据链接用于存储监视串口所得到的数据。

2.3.2 各类函数

如果观察发往设备的各种类型的请求，会发现大部分请求都是读写数据。然而应用程序有时候会需要设备执行IOCTL操作，应用程序使用标准Win32 API函数来执行这样的操作。在驱动程序一方，这个DeviceIoControl调用被转化成一个带有IRP_MJ_DEVICE_CONTROL功能码的IRP，通过IOCTL操作来完成应用程序与驱动程序之间的参数传递等数据交互。

具体到本驱动程序中，当其建立好数据交互设备对象ComSpy后，驱动程序处于等待运行中，其首先要得到预监视的串口号，以便建立对应的串口过滤设备对象来截取相关数据。而后其还要传递如触发信号对象句柄，用户内存地址一系列参数，用于数据交互。

首先应用控制程序调用DeviceIoControl API来向数据交互设备对象ComSpy发送参数，这个DeviceIoControl调用被转化成一个带有IRP_MJ_DEVICE_CONTROL功能码的IRP，在驱动程序中调用ComSpy_IoCtl I/O派遣函数来处理这个IRP。ComSpy_IoCtl函数通过if (DeviceObject->DeviceType==FILE_DEVICE_COMPORT)

这样的句语分析，此IRP是否是发给数据交互设备对象ComSpy，如果是则调用IOCtrl_IoCtl I/O处理函数来根据不同的控制码完成不同的操作。

在这里将对几个重要的控制码操作加以分析说明。

首先最重要的是要传递串口号以建立串口过滤设备对象，其功能码定义为：

即功能码IO_OPEN_COM, IOCTL请求缓冲策略为METHOD_BUFFERED。

IOCTL请求有4种缓冲策略，下面一一介绍。

(1)输入输出缓冲I/O (METHOD_BUFFERED)

(2)直接输入缓冲输出I/O (METHOD_IN_DIRECT)

(3)缓冲输入直接输出I/O (METHOD_OUT_DIRECT)

(4)上面3种方法都不是 (METHOD_NEITHER)

通常，驱动程序在访问用户数据时不应当将UserBuffer字段用作地址，即使当用户缓冲区被锁定时也是如此。这是由于在调用驱动程序时，在系统中可能看不到调用用户的地址空间。如果使用“直接”或“两者都不”方法，在创建MDL之后，驱动程序可以使用MmGetSystemAddressForMdl函数来获取有效的系统地址以访问用户缓冲区。

所以只要确定了传输方式后，就可以根据各自的位置来读取和写入数据，从而实现应用层和驱动的通信。

实际是这样，当IO_OPEN_COM控制到来时，驱动程序对象通过下面的代码：

至此一个由上至下的设备栈就建立起来了，以后对应串口所在的收发数据都用先经过其上的串口过滤设备对象，就可以提前分析相关数据后，再将数据传递给串口，这样即达到了串口监视的目地，又不影响正常的口串口工作。

IOCompletionI/O完成例程用于IRP_MJ_DEVICE_CONTROL功能码的IRP，不是发给数据交互设备对象ComSpy时的数据处理。这里主要用于监视串口驱动中的IOCTL_SERIAL_SET_BAUD_RATE及IOCTL_SERIAL_SET_LINE_CONTROL功能码, 前期用于截取串口波特率数据, 而后者用于截取串口奇偶校验、停止位、校验等数据。

代码如下：

其工作流程为：IO_REQ类型结构的一个数据链表结点，填充节点数据，将节点加入数据链表，设置信号变量为有信号以通知应用程序来读取数据。由于这一过程与读完成例程一样，因此将在读完成例程的分析中详细介绍其实现过程。

2.3.3 驱动程序解读派遣函数

当串口过滤设备对象被建立并开始工作后，驱动程序的大部分工作将主要集中的计算机串口出现收发数据时，此时驱动程序将处理IRP_MJ_READ、IRP_MJ_WRITE功能码IRP。由于读写数据只是在数据流向上有所不同，而处理方法上几乎完全一样，因此这里只详细分析绍读派遣函数实现方法。

首先函数依然分析IRP发给哪个设备对象。

如果发给ComSpy则调用IOCtrl_Read来取走链接中存放的监视到串口数据。这里先放一下，在后面来具体介绍其过程。

先重点分析一下驱动程序是如何取得串口数据并保存它们的。

p Ext= (PDEVICE_EXTENSION) DeviceObject->DeviceExtension;

取出当前设备对象的DeviceExtension数据结构，其中记录有下层设备对象指针。

取出当前IRP的堆栈单元指针，许多重要的IRP数据，参数都存放在其中。

IoCopyCurrentIrpStackLocationToNext (Irp) ;

将当前IRP的堆栈单元复制给下一个设备对象。

通常，需要知道发往低级驱动程序的I/O请求的结果。为了了解请求的结果，需要安装一个完成例程，即调用IoSetCompletionRoutine函数：当下层驱动完成此请求后会自动调用设置的ReadCompletion回调函数。工作流程如图3所示。

具体到本程序即可以这样理解，当串口过滤驱动的下层驱动即串口驱动完成读I/O请求后会自动调用ReadCompletion函数，并将已完成的IRP传递给它，这样就有机会在这个函数中截取想要的数据。

最后调用NtStatus=IoCallDriver (pExt->

TargetDeviceObject, Irp) ;

将当前IRP传递给下一层驱动即串口驱动，以便其得到并能处理这个请求。

而在ReadCompletion函数中是这样实现所需数据的截取的。首先生成分配了一个节点指针。

然后填充节点，代码如下：

在这里要说明IRP的IoStatus.Information;普通存放着本次接收到的数据的长度

将数据复制到节点数据指针所指向的内存块中，被截取的存放在Irp->AssociatedIrp.SystemBuffer中，这与指定的缓冲策略有关，即在建立串口过滤驱动时已指定了其缓冲策略，代码是:

将累计的数据长度内存地址复制给用户态地址，这里用到了影射核心内存到用户模式进程的相关知识。

KeSetEvent (gpEventObject, 0, FALSE) ;

这句是一个重要细节实现：这里使用了应用层与驱动层同步事件的处理方法;

原理：通过应用层创建事件，并将该事件传递给驱动层，同时应用层创建监控线程，等待驱动层发起事件，此为应用层驱动层共享事件。一但检测到事件，应用层即可执行某些操作。

具体到本程序，将调用KeSetEvent (gpEventObject, 0FALSE) ;设置共享事件为有信号时，应用层的监控线程将调用ReadFile (m_hDevice, lpBuffer, nSize, &dwRet, NULL) ;函数来读取刚刚存放到数据链表中的数据，ReadFile会向ComSpy调用IOCtrl_Read功能码IRP，这时流程就会来到本小节开头没有分析的那处调用即：

如果发给ComSpy，则调用IOCtrl_Read来取走链接中存放的监视到串口数据。

下面就具体分析是如何通过IOCtrl_Read调用来取出截获的已放入数据链表的数据的。

IOCtrl_Read代码如下：

取出当前IRP的堆栈单元指针及其所携带参数数据, 如:输出缓存区的长度等。

至此程序已完整的将一个从建立串口过滤对象、截取串口数据、向应用程序传递数据的过程呈现出来。回顾其流程可见图4。

2.3.4 ComSpy＿Unload驱动程序卸载例程

一旦驱动程序被加载，它将一直保持在系统中直到系统重新激活。Unicode例程使驱动程序可以被卸载。在DriverEntry例程中声明Unicode例程。I/O管理器将在驱动程序被自动或者手动卸载的时候调用Unicode例程。

虽然驱动程序的Unload例程不尽相同，但是它大都执行下列工作:

(1)对于一些硬件，设备的状态应该存储在注册表中。在下次DriverEntry例程执行的时候驱动程序可以恢复到最近的状态。例如，声卡驱动程序可能存储当前的音量设置信息。

(2)如果这个设备支持中断，Unload例程必须禁止它们和断开它们与中断对象的连接。一旦中断对象被删除，设备将不会产生任何中断请求。

(3)释放属于驱动程序的任何硬件。

(4)从Win32的名字空间移除符号连接名。这个动作可以调用IoDeleteSymbolicLink来实现。

(5)使用IoDeleteDevice移除设备对象。

(6)如果管理多部件的控制器，为每一个连接到控制器的设备重复步骤4和5，然后移除控制器对象本身，使用IoDeleteController函数。

(7)重复步骤4到6，移除所有的术语这个驱动程序的控制器和设备。

(8)释放驱动程序持有的任何缓冲池。

所以当不再需要监视串口数据，就应触发ComSpy_Unload来完成上述的工作。

其代码分析如下：

取出一个设备对象，在驱动程序创建不同的设备对象后，所有属于特定驱动程序的设备对象将水平地连接在一起，驱动程序对象的DeviceObject域将指向水平设备链中的第一个设备对象，而这个设备对象的NextDevice (PDEVICE_OBJECT) 指向属于同一个驱动程序的下一个设备对象。通过有效地循环提取就能取得驱动程序中的每一个设备对象，而后移除清理它们，在本程序中共建立了两个设备对象，一个是数据交互设备对象，一个是串口过滤设备对象。

因此分别取出这两个设备对象，移除清理它们。

2.4 串口过滤驱动程序

2.4.1 过滤驱动程序

前面只分析介绍了对本驱动程序来说相对主要的IRP派遣例程，而一个完整的驱动程序还需要处理很多其他相关的IRP，限于篇幅的原因就不一一详细分析，但需要说明是相对于一个真实物理的设备驱动程序来说，过滤驱动程序需完成的任务相对要小很多，一般的IRP请求它都是直接向下层驱动，直接发送由下层驱动完成。这一特点使其相对好理解，对于希望从应用程序开发过渡至设备驱动开发是一个很好的学习过程。

同时过滤驱动程序的应用也十分广泛，如：抗病毒、反黑客、文件加密、硬件设备工作监视等。因此对于应用软件开发人员非常值得学习研究。

本程序稍加改动即可监视计算机其他端口，如：并口等。

2.4.2 编译连接驱动程序

微软提供一个单一的编译器和连接器。无论这个工具被从命令行提示调用或者从集成开发环境调用﹐产生的二进制文件是一样的﹐Visual Studio仅仅是一个GUI接口的创建和编辑工具。点击Project菜单下的Settings选项﹐提供了一个方便的基于对话框的工具开关接口。

DDK提供一个Build工具﹐可以用来方便地创建设备驱动程序﹒使用适当的环境设定﹐也可以使用Visual Studio。确实﹐使用Visual Studio环境在开发阶段和在发行工程的时候使用Build是合适的。

使用Build来创建驱动程序的步骤如下﹕

(1)在源文件的路径下﹐创建一个名字为SOURCES的描述驱动程序组成的文件。

(2)在源文件的路径下﹐创建一个名字为MAKEFILE的仅仅有下面一行代码的文件﹕

这个根调用使用Build创建的任何驱动程序需要标准的makefile﹒不要添加源文件到这个makefile﹐而是添加到SOURCES文件中。

(3)使用文件管理器或者MKDIR命令为Build的产品建立路径树。

(4)在Win2000 DDK的程序组中选择调试创建环境或者自由创建环境。会有相应创建环境的命令窗口。

(5) 使用CD命令将当前路径转移到源文件路径。

(6) 运行Build实用程序创建驱动程序。

二进制输出被创建到适当平台的CHECKED或者FREE路径﹐任何屏幕上显示的错误也被写入到Build的日志文件中了。

Build操作被一系列关键词控制着，这些指定关键词产生的驱动程序的类型﹐组成产品的源文件和不同文件的路径。尽管这些关键词可以被命令行选项传递给Build﹐但是将它们放到SOURCES文件中会更有用。下面是SOURCES文件的一般规则﹕

(1) 文件名必须是SOURCES (没有扩展名) 。

(2) 文件内容的格式为﹕keyword=value。

(3)一个单一的BUILD命令可以通过在行尾使用一个反斜线符号 (“”) 扩展多行。

(4) Build关键词的值必须是纯文本。Build自己只作很少NMAKE宏的处理﹐不处理条件语句。

(5)确定在Build关键词和等于符号之间没有空格，等于符号后面的空格是允许的。

(6)注释行以“#”字符为开始﹒。

下面是一个最小的SOURCES文件的例子﹕

3 实现

串行数据监视显示应用程序使用MFC的单文档架构，主要用于动态加载串口过滤驱动程序、发送串口号及交互事件、共享内存地址等必要参数，并开启监视线程接收串口过滤驱动程序的监视数据显示在用户终端上。

基于单文档架构程序主要分用两部分，一部分主要用于动态加载卸载串口过滤驱动程序及传递清理驱动程序所需的重要参数。另一部分主要用于实时监视接收串口过滤驱动程序得到监视数据，并将其格式化后在显示在应用程序客户区。前者在MainFrm.cpp文件中实现，后者在SerialSpyView.cpp文件中实现，下面将分析实现这两部分。

3.1 动态加载卸载及参数传递

3.1.1 结构定义分析

在应用程序中一般会在.H头文件中声明一起将会使用的变量及结构，在本程序中尤为关注的是应用程序和驱动程序共同的一起变量及结构，一定要在应用程序中加以声明，如：I/O控制功能码等。

驱动程序定义如下：

前者定义了LIST_ENTRY entry;PVOID pData;而后者定义了DWORD Reserved1;DWORD Reserved2;DWORD Reserv ed3;同样的结构名却使用了两种不同的内部成员定义，这涉及了一种特殊数据大小对齐的处理方法。实际上就是用于使结构大小与原定义一致，驱动程序中LIST_ENTRY是一个结构成员，它的内部成员分别是两指针类型占8字节，而PVOID空指针占4字节，共计12字节，所以应用程序中使用了3个DWORD变量来代替正好也是12字节，这样做的原因是LIST_ENTRY entry是一种在内核驱动中常用的链表结构，如在应用程序中定义引用它就需要相应的头文件及库的支持，而在应用程序的实际使用中并没有直接使用它(PVOID pData同样也没有直接使用)，所以用这样一个非常实用的替代定义的方法来节省工作量及开发的复杂性。

3.1.2 驱动程序的动态加载卸载

在Windows下驱动程序的加载处理上述方式外，还可以在应用程序里用Service Api实现，驱动程序的动态加载。这时候的Start为3。

具体到本程序，其调用了InstallDevice来加载驱动程序，其代码分析如下：

首先将当前目录下的ComSpy.sys驱动程序复制到计算机系统目录下的Drivers目录中，Drivers目录存入着Windows大部分的设备驱动程序，这是通常的做法。

服务控制管理器：在系统启动的时候开始，是Win系统的一部分，它是一个远程过程调用(RPC)服务器。这也是Win服务系统的核心。

SCM维护着注册表中的服务数据库，位于：HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices。其下的子键就是安装的服务和驱动服务。每个子键的名称就是服务名，当安装的时候由服务安全程序的CreateService函数指定

CreatService函数顾名思义产生一个新的Service，即将驱动程序作为一个系统服务动态运行。其中参数hSCManager为指向service control manager database的句柄，由OpenSCManager返回。LpServiceName为Service的名字，lpDisplayName为Service显示用名，dwD?esiredAccess是访问权限。wServiceType指明SERVICE类型。dwStartType为Service启动方式，dwErrorControl说明当Service在启动中出错时采取什么动作。LpBinaryPathName指明Service本体程序的路径名。剩下的?五个参数一般可设为NULL。如函数调用成功则返回这个新Service的句柄，失败则返回NULL。

使用StartService用来启动服务即开始驱动程序。这个函数的原型：

StartService函数启动指定的Service。其中参数hService为指向Service的句柄，由OpenService返回。dwNumSe?rviceAr为启动服务所需的参数的个数。lpszServiceArgs为启动服务所需的参数。函数执行成功返回True, 失败返回False。

这里调用了OpenDevice函数，OpenDevice中使用了DeviceIoControl来与驱动程序进行数据交互。其代码分析如下：

在使用DeviceIoControl之前，首先要使用CreateFile打开该驱动设备，取得设备句柄。

CreateFile的原型为

CreateFile这个函数用处很多，这里用它“打开”设备驱动程序，得到设备的句柄。操作完成后用CloseHandle关闭设备句柄。

与普通文件名有所不同，设备驱动的“文件名” (常称为“设备路径”) 形式固定为“.DeviceName” (注意在C程序中该字符串写法为“.DeviceName”) ，DeviceName必须与设备驱动程序内定义的设备名称一致。

一般地，调用CreateFile获得设备句柄时，访问方式参数设置为0或GENERIC_READ|GENERIC_WRITE，共享方式参数设置为FILE_SHARE_READ|FILE_SHARE_WRITE，创建方式参数设置为OPEN_EXISTING，其他参数设置为0或NULL。DWORD dwReturn;

TCHAR szOutputBuffer[4];

将串口号字符串传递给驱动程序，这里要注意，Ansi型和Unicode型的使用问题，在驱动程序中所在函数变量都是针对Unicode型来处理，因此此处如传递的是非Unicode型数据，驱动需使用Ansi型转化函数处理后才能使用，代码也给出对应的示例码。

//传递的监视数据触发事件句柄。

//传递的用户地址用于记录一次读取操作的数据长度。

卸载时要执行加载的逆顺充, 即要先与驱动程序交互通信通知驱动程序清理一些交互参数所占内存等, 然后使用停止驱动程序API来卸载驱动程序。

具体代码分析如下：

上述函数在MainFrm.cpp中定义，而在SerialSpy.cpp即应用的初始化及退出时被调用，可进一步完善为在菜单中自定义加载及卸载。

3.2 实时接收显示监视数据

实时接收显示处理共分两部分;一部分是创建一个辅助线程接收数据并将数据输出应用程序的数据存储链表中;另一部分是使用了定时器消息在固定间隔时间内定时从数据存储链表中读取数据并显示。下面将分别介绍这两部分的分析实现。

3.2.1 实时接收数据

应用程序首先创建一个事件，然后将该事件句柄传给设备驱动程序，接着创建一个辅助线程，等待事件的有信号状态，自己则接着干其他事情。设备驱动程序获得该事件的句柄后，将它转换成能够使用的事件指针，并且把它寄存起来，以便后面使用。当条件具备后，设备驱动程序将事件设置为有信号状态，这样应用程序的辅助线程马上知道这个消息，于是进行相应的处理。当设备驱动程序不再使用这个事件时，应该解除该事件的指针。

其核心的实现函数就是辅助线程函数，它通过循环等待交互事件的信号状态来判断是否有数据。当有数据时，其调用ReadFile去主动读取。

其代码分析如下：

程序在这里等待两个事件中的任何一个发生，这两个事件一个p This->hEvent用于控制此线程的终止，另一个m_hCommEvent就是监视的与驱动程序交互的事件。

当交互事件为有信号，应用程序主动调用ReadFile从驱动程序数据存储链表中读取数据至lpBuffer。注意此时有可能一次性读取的是几个链表节点的数据，不要假定每次只读一个节点。

3.2.2 实时显示数据

系统使用了一个200毫秒的定时器消息来定时显示数据，因时间片间隔很小所以基本效果可以近似实时显示。

其代码如下：

其中的ShowTraceData函数根据数据类型的不同，如：参数类数据，正常数据包等不同，进行了不同的数据格式化后，再向客户区显示输出。如：正常数据要进行16进制数据显示转化等处理。

至此一个完整的串口监视系统已全部分析完成。

回顾其完整流程可见图5所示。

最后程序运行效果如图6。

4 结语

驱动程序是直接工作在各种硬件设备上的软件，其“驱动”这个名称也十分形象地指明了它的功能。正是通过驱动程序，各种硬件设备才能正常运行，达到既定的工作效果。

在计算机系统中，与外围硬件设备紧密相关的软件称为设备驱动程序。它是用来扩展操作系统功能的一类软件，通常工作于操作系统的核心层，直接操作硬件。设备驱动程序增强了操作系统的安全性和应用程序设计的灵活性。

摘要：讲述了串口监视过滤驱动的原理和工作流程, 列举出了相关的核心代码, 用流程图的方式描述了各个模块的逻辑实现。在开发中按照软件工程的流程, 从需求分析到概要设计, 从具体设计到编码, 以及调试测试, 利用软件工程的工具管理开发代码和文档。

关键词：WDM,串口监视,过滤驱动,串行通信

参考文献

[1]Programming the Microsoft Windwos Driver Model.微软出版社.

[2]翟洪涛.Windows2000驱动程序设计.

[3]刘春立.用VC开发Windows下的串口异步通信程序.计算机系统应用.

[4]柴锁柱, 刘金岭.用Visual C++6.0开发Windows环境下的串口异步通信程序.沧州师范专科学校学报.

[5]李阜, 陈小欧.Windows环境下的串口异步通信程序设计.电子技术应用

[6]李阜, 陈小欧.Windows环境的串口异步通信程序设计.计算机系统应用.

[7]黄硕.Windows环境下的串行异步通信程序设计.广东自动化与信息工程.

[8]陈曙光.利用通信控件开发Windows环境下的串口通信程序.淮北煤师院学报:自然科学版.