I/O卡技术

I/O卡技术（共3篇）

I/O卡技术 篇1

0 引言

我们知道C++对象是“存活”在RAM中的，由于RAM的易失性[1]，程序需要将对象存入磁盘中，将来需要时再把对象读入内存加以恢复，这样一来就好像对象一直“活”着一样，因此对象的持久化是C++中的一个非常重要的操作。

许多程序员可能有这样的误区，利用下面的代码：saveClassName();className=readClassName();p=new className;不就轻松实现对象的保存和恢复了吗?

需要指出的是，在C++中，是通过new A而非new“A”（或className=“A”,new className）实例化A的对象。换句话说，试图利用下面的代码className=readClassName（）;p=new className；来达到通过类的字符串名称动态创建对象的做法是根本行不通的，因为p=new className根本无法通过编译！[2]

由此我们得出对象的持久化需要的两个条件：

(1)获取对象所属类的名称的能力；

(2)能根据类的字符串名字动态创建对象的能力。

这两种能力的获得目前有两种解决方案：

一是由C++编译器（compiler）提供———例如Borland C++4.5:

二是由程序员自己加上去。

本文是通过第二种方法模拟实现对象的持久化机制，从而深入探讨了对象I/O技术的实现机制。

本文结构如下，首先描述了对象持久化的实现，其次对实现进行了验证，最后是论文进行总结。

1 对象持久化的实现

为了说明问题而又不失一般性，我们假定有三个类，分别是Object,A和B，其中A和B都派生于Object，类的定义如下：

为了让对象具备持久化的两个条件，需要依次为对象添加如下信息。

1.1 为每个类增加对象创建函数CreatObject，如表2所示。

1.2 增加类的识别信息（类名称或ID等）以及继承信息，由于这部分信息比较多，可以将其整合到一个结构体Struct ClassInfo中。ClassInfo中保存有两个链表：

类的继承链表和程序中所有类的类型信息链表。类的识别能力就由这两个链表来完成。换句话说，我们希望在main函数执行之前内存中就存在如图1所示的两个链表。其中类的继承链表是由Struct ClassInfo的带参构造函数完成的（在VC++中，结构体也可以有构造函数），而类的类型信息链表则是由ClassInfoInit类完成的。Struct ClassInfo和ClassInfoInit的定义如表3所示。注意，链表的创建是在它们的构造函数中完成的。

最后一步，将类型信息作为类的静态的成员变量添加进来，并为每个类实例化静态的初始化类，目的是在main函数执行之前得到图1所示的两个链表。

在这要强调一下static关键字的作用：

(1)如果类的成员变量被Static关键字所修饰，则这该属性不是为类中的每个对象分别拥有，而是共用，其引用形式不是对象成员变量，而是类成员变量，即不需要市里实例化对象就可以使用。成员函数也与此相仿[3]。

(2)如果对象（包括作为类成员的对象），如initObject、ObjectInfo等，被说明为Static，则这些对象是在main函数执行之前就已经存在了，换句话说，这些对象的构造函数是在main函数调用之前就已经被调用了。因此在main函数执行之前，内存中就已经存在着图1所示的链表就可以理解了。

我们添加的RTTI信息能否有效的支持对象的持久化可以由试验来验证。

2 试验

该试验主要验证了对象持久化必须具备的两个能力，即动态创建对象能力和获取对象所属类的能力。试验的环境如下：操作系统Windows XP sp2,IDE环境是VC++6.0 SP6。如需要全部源代码可与作者联系（hehh6@henu.edu.cn）。

通过对象增加的RTTI信息（增加的静态成员变量），获取对象所属类的能力自然具备。

动态创建对象能力实际上就是根据类的字符串名称来实例化对象的能力，在图1所示链表的支持下，该功能可以非常轻松的实现。

思路如下：通过ClassInfo：:pFirstClass查找类名匹配的ClassInfo，利用ClassInfo中的pCreateObject指针实例化对象,为方便起见,可为程序增加查找函数

3 结束语

本文在手动添加的RTTI信息的支持下实现了对象的持久化，从中读者可以深入了解对象持久化的的实现机制。

在商业的编译器VC++中其实现持久化是通过一个神秘的宏，当将该宏展开后，VC++实现持久化的的思路和本文大同小异，只是更精巧[4]。

参考文献

[1]Stanley B.Lippman.Inside The C++Object Model(深度探索C++对象模型)[M].侯捷,译.武汉:华中科技大学出版社,2001.

[2]葛磊.The Object's Permanence Technology and Its Realization in MFC[J].开封大学学报,2006,20(1).

[3]钱能.C++程序设计教程[M].第二版.北京:清华大学出版社,2005:418-419.

[4]侯捷.深入浅出MFC[M].武汉:华中科技大学出版社.

I/O卡技术 篇2

Python提供了必要的函数和方法进行默认情况下的文件基本操作。你可以用file对象做大部分的文件操作。

open函数

你必须先用Python内置的open()函数打开一个文件，创建一个file对象，相关的辅助方法才可以调用它进行读写。

语法：

file bject = open(file_name [, access_mode][, buffering])

各个参数的细节如下：

file_name：file_name变量是一个包含了你要访问的文件名称的字符串值。

access_mode：access_mode决定了打开文件的模式：只读，写入，追加等。所有可取值见如下的完全列表。这个参数是非强制的，默认文件访问模式为只读(r)。

buffering:如果buffering的值被设为0，就不会有寄存。如果buffering的值取1，访问文件时会寄存行。如果将buffering的值设为大于1的整数，表明了这就是的寄存区的缓冲大小。如果取负值，寄存区的缓冲大小则为系统默认。

不同模式打开文件的完全列表：

I/O卡技术 篇3

甘肃特殊的地形、地貌及地质条件, 决定了甘肃省高速公路隧道比例高, 建设条件多样, 环境复杂。为提高甘肃省高速公路隧道监控系统的运营效能和安全保障水平, 并重点对隧道通风、照明、消防报警、安全监管、交通监控等系统进行改造, 确保所有设备运转正常。

项目方案论证阶段建设、设计、运营维护等单位对隧道现有机电系统进行详细的调研, 实现全省隧道监控系统三级联网监控架构 (见图1) 。本论述仅以巉柳高速公路白虎山、赵家楞杆、新庄岭、土家湾等隧道的升级改造为例来说明。

2 远程I/O技术PLC区域集中控制方案设计论证

在隧道监控系统中, 区域控制器 (PLC) 是核心设备, 是隧道内环境检测、通风照明控制、消防联动的数据收集处理单元和控制指令执行单元, PLC控制子系统几乎涉及到隧道机电的各个系统, 对其技术性能可靠性和稳定性比其它设备有更高的要求, 而且PLC区域控制子系统与隧道视频监控子系统共同构成隧道监控系统中造价最大的部分。出于合理安排建设资金, 充分发挥系统功能的考虑, 我们联合运营维护单位、PLC设备厂商有关技术人员, 经专项论证和实验室模拟试验, 提出基于远程I/O技术PLC区域集中控制方案, 该系统利用主控PLC+远程I/O模块光纤组网, 实现隧道内被控设备分布式接入, 区域集中控制功能, 在满足隧道智能联动控制需求的前提下, 较目前分布式PLC区域控制系统节省近40%的建设费用。

该方案的设计思想是将分布式PLC控制系统中隧道内的PLC从站利用远程I/O模块代替, 隧道内设备所有接线端子均达到IP67。数据处理和存储均由变电所内的主控PLC执行, 通过加强主控PLC配置的方式解决数据处理能力的问题。隧道变电所中的主控PLC通过PROFINET 总线控制远端I/O, 远端的下位机I/O设备通过总线耦合器光电转换光缆传输, 实现主控PLC对远端的I/O进行控制, 满足对隧道中的设备进行实时准确控制的功能, 该系统有如下特点:

(1) 通信速率快:远程I/O系统可以直接接入以太网网络, 通信速率至少达100M。

(2) 通信距离远:远程I/O系统可以通过以太网连入光纤环网, 基于光纤传输的特点, I/O系统的控制效率基本上不受距离的影响。

(3) 性价比高:远程I/O系统省去了洞内现场CPU设备, 较大的节省了经费, 又不影响监控系统的正常运行。

(4) 稳定方便:远程I/O系统由变电所内主控PLC控制, 节省PLC编程环节, 也利于后期故障维护。

基于上述诸多优势, 本项目基于远程I/O技术的PLC区域集中控制系统得到项目评审专家的一致认可, 并被誉为隧道PLC控制系统分散检测、集中控制的优选方案。

3 系统实施阶段

本项目经过为期半年的前期设计和论证, 于2011年6月进入实施阶段。针对项目施工图设计, 进行更加详细的联合设计, 最终确定使用菲尼克斯的PLC及远程I/O。

隧道项目共设计使用30台PLC, 6台触摸屏设备, 通过上述30套菲尼克斯PLC设备进行控制隧道中的所有可控设备, 主要有:通风、照明、交通诱导、消防、火灾、视频监控平台、超速预警、异常事件检测等系统。

其中对监控系统的架构、设计思想进行分析, 针对实际情况进行了详细的方案分析, 网络图架构见图2所示, 同时实现三级监控的架构思想 (站级、所级、局级) 。如图1隧道三级监控架构图。

隧道内部的PLC环网采用双环冗余的架构, 4条隧道 (白虎山、赵家楞杆、新庄岭、土家湾) 共5处配电室, 在配电室内部架设1套主控PLC, 在隧道内部上、下行各设置3套远端I/O设备, 组织有序的收集隧道内的检测设备信号, 控制各种可控设备。白虎山隧道1号配电室设置主控PLC, 赵家楞杆隧道2号配电室设置主控PLC, 新庄岭隧道3号、4号配电室设置主控PLC各1台;土家湾隧道5号、6号配电室设置主控PLC各1台, 在主控PLC对应的上、下行每个隧道部署3套远端I/O设备, 每个配电室的主控PLC与远端I/O设备通过交换机光纤冗余环网进行实时通信, 对远端I/O采集到的终端设备反馈信息进行集中管理;下面简要介绍远端I/O设备的部署、软件控制编程的部署情况。

3.1 I/O硬件设备部署情况

T/O硬件设备部署情况见图2。

3.2 软件控制编程部署

PLC监控软件的站级部署情况如图3所示, 在监控室部署上位软件、服务器软件数据库、OPC Server, 在配电室部署下位软件, 通过下位软件进行对现场设备的实时控制及反馈。

通过数据的锁定实现三级控制监控业务的开展, 同时可以看出业务数据与登录帐户数据的分离;即可实现不同级别人员的控制与监控。如图3上、下位软件架构。

PLC程序编写采用T型图进行逻辑编写, 根据详细的二次接线图, 实现对现场设备车道指示灯、风机、交通信号灯、风速风向、CO/VI、亮度检测仪、照明等设备的实时控制及状态反馈。

下位机PLC开发软件功能介绍:PLC I/O点变量声明、PLC程序梯形图编写, 通过T型图的逻辑实现对现场设备的控制。OPC (OLE for processing control) 的主要功能是采用开放式的通讯协议, 使用c/s模式架构, 通过OPC将组态中的数据经过OPC Client与数据库进行交互, 实现上位机、下位机的数据变量的数据同步。

上位监控软件部署:

通过隧道群导航图, 软件可以换到不同的隧道界面, 进行不同功能的人机界面的需求控制。图4隧道中设备界面显示。

切换全部设备视图界面, 可以监视到隧道中的各种设备的运行状态以及控制状态。

4 联合调试、运营阶段

经过半年时间的集中施工, 系统的软硬件均已部署完成, 联合调试阶段主要内容包括:在上位机监控软件上运行设计制定的不同工况交通组织预案, 现场各PLC远程I/O执行效率、设备动作响应及信号反馈效率、软件界面与设备状态;该远程I/O区域集中控制系统各项功能参数均达到设计预期, 目前设备运营已经步入正轨, 全部设备运行正常。

5 结束语

基于远程I/O技术的公路隧道PLC区域集中控制系统是我省高速公路管理单位、设计单位、维护单位以及相关设备厂商依托本次改造项目隧道机电控制系统进行的科研试点, 整体架构和调试效果得到了相关检测验收单位和专家的认可。该项目的设计和实施为高速公路中、长隧道监控系统分布式接入、区域集中控制技术提供了可供参考的技术方案;在后期的运行维护中, 该系统的节能、免维护优势将进一步显现。

摘要：截止2012年2月甘肃省运营中的高速公路已突破2400km, 共有隧道59处 (单洞109座) 。为了加强隧道内照明、通风、消防等系统的有效联动控制, 为了充分发挥系统功能, 提出基于远程I/O技术PLC集中控制, 该系统利用主控PLC远程I/O光纤组网, 实现隧道内设备接入, 满足隧道智能联动控制需求, 较分布式PLC区域控制系统节省近40%的建设费用;该系统目前已顺利实施完成, 功能可靠、稳定, 节能和免维护效果逐步显现。

关键词：高速公路监控系统,隧道监控系统联动,集中控制,I/O,PLC控制器

参考文献

[1]GB/T23828-2009.高速公路LED可变信息标志[S].北京:人民交通出版社, 2009.

[2]GTGF80/2-2004.公路工程质量检验评定标准[S].北京:人民交通出版社, 2004.