非实时业务（精选9篇）
非实时业务 篇1
1 前言
随着广播电视数字化技术的迅速发展，人们除了对所接收到的声音、图像的品质越来越重视之外，对多样化服务的要求也越来越高。传统的FM和AM广播除了只能提供声音传输的业务外，无法提供多媒体资讯的业务。数字音频广播（DAB）技术采用了数字音频压缩编码和信道编码调制技术，使其不仅具有能够支持高速移动接收、支持单频网等特点，还能够在提供多路具有CD音质的立体声节目的同时，可以进行一些数据业务的传送，例如图片、文字信息和数据等。在地面数字音频广播（DAB）系统技术规范中，定义了实时音频业务和数据业务传输的方法，但对于基于文件下载模式的非实时数据音频业务并未描述。非实时数据音频业务作为数据业务的一种，是指在DAB数字音频广播系统中，采用MOT头模式封装及在主业务信道中采用包模式进行数字音频文件传输的广播推送业务。
非实时数据音频业务利用多媒体对象传输（MOT, Multimedia Object Tranfer）协议，在相关配置和管理信息的控制下，将文件数据打包封装，以数据包形式传输到用户的接收终端，实现数据节目的播放；接收终端将接收到的文件按照一定的配置管理信息自动存储在相应的文件专区中，由用户自主选择收听或收看，实现节目、数据的接收。
本文主要讨论了在现有DAB数字音频广播系统的主业务信道中进行非实时的数字音频文件传输的相关协议和方法。文章首先介绍了两种基于多媒体对象传输协议的数据业务在DAB系统中的传输方式，其次重点介绍了本文讨论的以包模式进行非实时数据音频文件传输的方法，并搭建了基于非实时数据音频文件传输的仿真平台，在高斯信道条件下对相关业务的传输性能进行了仿真研究。
2 基于MOT协议数据业务在DAB系统中传输方式
DAB的传输帧格式包含同步信道、快速信息信道和主业务信道三个部分。同步信道用于系统内的同步、信道估计和发射机识别等；快速信息信道除了用来发送相关的复用配置信息和业务信息外，还可以用于一些数据业务的传输，但其可提供的数据带宽较低，不适用于存储容量较大的数据和文件的传输；主业务信道可以用来传输实时音频业务和数据业务，在主业务信道的总容量中，可以留出任意的部分用于数据业务。
待传输的数据业务（音频文件、图片等）在经过MOT协议封装后，在DAB系统的主业务信道中通过两种方式进行传输：一种是附加在音频子信道内，以节目相关数据（PAD）的形式进行传输，另一种是独立在一个子信道中，以数据包（Packet）的形式进行传输，图1给出了基于MOT协议的数据业务在DAB中传输的框图。
2.1 节目相关数据（PAD）的形式
节目相关数据一般用来传输与音频节目有密切关系的数据，也可以用于一些其它数据业务的传输。PAD模式将要传输的数据文件附在DAB音频帧的后面与声音一起传输，DAB中允许PAD的最快速率为64kbps，此方式可以用来传输小量的图片或者文字。
PAD模式的传输数据结构如图2所示，包括X-PAD、SCF-CRC及F-PAD, 其中SCF-CRC为误码校验比特；F-PAD占用两个字节，固定位于每个音频帧的后面，用于定义X-PAD的类型和指示在X-PAD中是否存在内容指示符；X-PAD分为长格式和短格式，主要用于传输数据文件，在X-PAD内部的内容指示符用来定义待传输数据文件的长度和应用类型等。
2.2 数据包的形式
在DAB系统中，主业务信道可以分为若干个子信道，各子信道使用流模式或者包模式传输不同的业务或者业务分量。其中，流模式的一个子信道只传输一种业务，包模式则可以在一个子信道中传输一个或几个业务分量。包模式允许的子信道比特率为8kbps的倍数，在以包模式传输的子信道内可以增加附加的前向纠错编码机制以提高数据传输的误码保护级别。
本文讨论的是非实时数据音频业务采用数据包的传输方式。
3 基于包模式的非实时数据音频业务的传输
图3给出了非实时数据音频业务传输框图。非实时数据音频文件、与数据音频文件相关的业务配置信息及一些其它的增值业务文件通过MOT协议进行封装之后，在现有DAB系统中以数据业务的形式进行传输，即经过数据组封装后，以包模式进行传输。此外，包含非实时数字音频业务的配置参数，如各种业务配置信息、附加信道编码保护方式等等业务描述信息在DAB系统中的快速信息信道（FIC）中进行传输。
在DAB系统，音频业务使用可删除卷积码就可以实现可靠的传输，对于视频传输使用RS码与可删除卷积码级联的增强包模式解决方案，通过附加的RS码和卷积交织提高视频数据的传输鲁棒性，但这种解决方案的不足是在提高数据传输鲁棒性的同时，由于外码（RS码）的引入降低了系统的整体效率。对于数据业务，则需要更高级别的误码保护方案才能保证数据业务的可靠接收，本文采用LDPC码和可删除卷积码级联的信道编码方式，这种信道编码具有更高误码保护能力，并以LDPC码更高的编码增益来弥补因可删除卷积码码率提高带来的性能下降，在系统整体传输效率和数据传输鲁棒性之间取得了更好的平衡。
3.1 MOT协议
DAB中用于文件对象传输的协议是MOT文件传输协议。MOT协议经过多年来的发展和完善已经比较成熟，对于非实时数据音频广播业务而言，在文件传输的底层采用MOT协议作为基础传输协议，既可以借鉴MOT协议的成熟和完善的规范，也可以利用现有的一些支持MOT协议的芯片厂商的方案来简化开发。MOT分为头模式和目录模式，非实时数字音频广播业务具体使用MOT头模式。MOT封装的结构分为三部分：核心头信息、扩展头信息和数据体。如图4所示，下面依次介绍各部分的作用。
(1) 核心头信息 (headercore)
长度为7个字节，用于描述所传输数据体的大小和传输文件的类型、内容等信息，接收机可以根据此信息判断是否要将所接收到的数据解码。
(2）扩展头信息（header extension)
可选项，长度不固定，用于描述传输数据体的一些其它属性和控制信息，如数据体的有效起始时间、版本号及名称等。
(3）数据体（body)
长度不固定，数据体就是要传输的非实时数据音频文件等，能够支持不同格式的文件。
在下文中，我们将核心头信息和扩展头信息统称为头信息。为了传输容量较大的文件，非实时数据音频文件经过MOT封装后，需要再将其分割成若干个片段，其中，头信息与数据体分别进行分割，且头信息分割片段的大小可以和数据体分割片段的大小不一样，如：头信息的分割片段为x长度，数据体的分割片段为y长度，当头信息和数据组的最后一个分割片段的大小不足x或y时，不用补充额外的字节。分割后的片段再添上2个字节长度的分割头后，作为数据组的数据字段进行传输，如图5所示。包含头信息的片段必须在包含数据体的片段之前传输，且在数据体传输过程中可以不定时的插入包含头信息的片段。
3.2 数据组（datagroup)
数据组的结构如图5中的数据组级所示，包括数据组头，一个可选的会话头，一个数据字段和一个可选的CRC校验，其各部分的作用如下：
(1）数据组头
用于定义数据字段的类型、连续索引、重传索引及一些标志位。对于MOT头信息的片段，其数据字段的类型定义为3，而数据体片段的数据字段，其数据类型定义为4。
(2）会话头
在DAB系统中这一部分为可选项，但是在基于MOT协议的文件传输时，此部分是必须存在的，这是因为在会话头里定义了16比特长度的传输ID，用于表示某一确定的数据对象。
(3）数据字段
包含整数个字节，最大长度为8191字节，添加了分割头信息的MOT各片段在数据字段内传输，由于分割头信息的长度为2字节，所以MOT各片段的最大长度为8189字节。
(4) CRC校验
16比特长度，根据数组组头、会话头和数据字段计算得到的，虽然是可选的，但是建议使用。CRC的生成多项式为：G (x) =x16+x12+x5+1。
3.3 包传输（packet)
包由一个包头、一个包数据字段和一个包CRC组成，如图5包传输级所示，各部分的定义如下：
(1）包头
长度为3个字节，用于定义包的长度、连续性下标、首尾指示、包地址及有用数据字段长度。包的长度可以为24字节、48字节、72字节和96字节，包的长度越长，则传输效率越高。包由包地址进行区分，同一业务分量的包具有相同的地址且按照顺序传输，不同地址的包可以按照任意顺序在一个子信道内传输。
(2）包数据字段
包含整数个字节，用于传输上一级数据组的所有数据，当数据组的数据不能填满此数据字段时，需要用0进行填充。
(3) CRC校验
根据包头和包数据字段计算出来的16比特CRC校验字，其生成多项式也同样为：G (x) =x16+x12+x5+1。
3.4 非实时数据音频业务的配置信息、业务描述信息
在DAB系统中进行非实时数据音频业务传输，还需要一些业务配置信息和业务描述信息等。
业务配置信息可以由开发商根据所提供的业务特点及需求自己定义，用于描述传输的媒体文件的存储、管理及展现等信息，有些业务配置信息可能需要通过增加一些MOT参数来进行开展。
通过在快速信息信道中的快速信息组中增加一些描述，就可以在DAB系统中定义并标识出与非实时数据音频业务相关的业务描述信息，，比如在FIG 0/3中的DSCTy中增加一项用于描述非实时数据音频业务，在FIG 0/14中可以描述所增加的信道编码方案等。
4 非实时数据音频业务的传输性能研究
本节讨论了基于DAB系统的非实时数据音频文件在高斯信道下的传输性能。将非实时数据音频文件分别按照MOT协议及数据组的结构分别封装，其中数据组的数据字段的长度可以自己选择，数据字段越长，则传输效率越高。对已封装好的文件按照所确定的数据包长度在高斯信道环境下进行传输。在仿真中，选择的数据组的数据字段的长度分别为1024字节和8191节，信道编码方式采用LDPC码与可删除卷积码级联的信道编码方式，其中LDPC码的码字长度为3840，信息比特长度为3072，编码效率为4/5，此时数据包的长度可以选择24、48或者96字节，使得一个LDPC码中包含整数个数据包；卷积编码的码率为2/3，所以整个信道的编码效率为8/15，图6分别给出了在数据组长度为1024字节、数据包长度为24和96字节时系统的传输性能，其中红线表示viterb译码后的误码率曲线，蓝线表示l LDPC译码后的误码率曲线。在图6中，由图（a）和图（b）可以看出两种情况下，系统的传输性能基本相当，在信噪比约为-0.4dB时，LDPC解码后的误码率小于10-6。图7 (a）为数据包长度为24字节长度时，数据组的数据字段的长度为8191节时的传输性能图7 (b) 给出了包长固定为24字节，数据字段长度分别为1024字节和8191节时的传输性能对比图，由图可以看出，数据字段长度为1024字节的传输性能要略好于8191节的传输性能。
5 结束语
非实时数字音频广播业务和现有地面数字音频广播系统有着很好的兼容性，可以作为一个完整的系统运营，也可以作为一种特殊的数据业务在现有地面数字音频广播系统中兼容使用。通过基于文件下载模式的非实时数字音频业务可以突破传统广播服务必须实时收听的限制，利用和广播运营平台相结合的模式，可以有效地为客户提供定制化的服务内容，从内容到形式上都改变了传统广播“你播我听”的固有模式，为传统广播的发展带来了新的发展方向。
参考文献
[1]GY/T 214-2006 30MHz-3000MHz地面数字音频广播系统技术规范.
[2]Digital Audio Broadcasting Multimedia Object Transfer protocol.1999.
非实时业务 篇2
(试行)
(商业银行讨论稿3．0)第一章 总 则
第一条 为规范武汉电子支付系统(以下简称‚本系统‛)的业务处理，确保本系统高效、安全、稳定运行，加速资金周转，防范支付风险，依据《支付结算办法趴《湖北辖内支付密码系统业务管理办法》(暂行)及有关制度的规定，制定本办法。
第二条 本系统实时业务实行逐笔实时处理，定时批量净额轧差清算资金。
第三条 经中国人民银行武汉分行营业管理部(以下简称‚营管部‛)批准，通过本系统办理支付业务的银行、城市信用合作社、农村信用合作社、邮政储汇局(以下简称银行)以及系统运行者，适用本办法。
第四条 本系统参与者分为直接参与者和间接参与者。
直接参与者是指直接与本系统数据处理中心(以下简称 ‚DPC‛)连接并在中国人民银行开设清算账户的银行机构以及中国人民银行地市以上中心支行(库)。
间接参与者是指未在中国人民银行开设清算账户而委托直接参与者办理资金清算的银行和非银行金融机构以及中国人民银行县(市)支行(库)。第五条 清算账户是指本系统的直接参与者在中国人民银行开设的用于资金清算的存款账户。
第六条 本办法所规定的业务包括本系统实时支付业务以及本办法规定的其他业务。
本系统处理的银行发起的支付业务，其支付信息从发起行发起，经发起清算行、DPC、接收清算行，至接收行止。
发起行是向发起清算行提交支付业务的间接参与者。
发起清算行是向本系统提交支付信息并开设清算账户的直接参与者。
DPC是接收、转发支付信息，并进行资金清算的机构。
接收清算行是向接收行转发支付信息并开设清算账户的直接参与者。
接收行是从接收清算行接收支付信息的间接参与者。第七条 在通过本系统办理业务的代理关系中，发起行为接收行的代理行，接收行为发起行的被代理行。
第八条 支付信息由纸凭证转换为电子信息，或由电子信息转换为纸凭证，具有同等的支付效力。
支付信息由纸凭证转换为电子信息，电子信息产生支付效力，纸凭证失去支付效力；电子信息转换为纸凭证，纸凭证产生支付效力，电子信息失去支付效力。
第九条 营管部对本系统实时业务实行统一管理，对本系统的运行及其参与者进行管理和监督。第二章 业务处理原则
第十条 本系统处理的支付业务的收付款银行账户仅限于单位银行结算账户和个人银行结算账户。第十一条本系统业务分为对公业务和个人业务。
对公业务是指付款账户为单位银行结算账户的业务。
个人业务是指付款账户为个人银行结算账户的业务。第十二条本系统受理银行在受理业务时应按规定对票据和结算凭证进行审查。
第十三条个人结算账户通过本系统转账支付的款项，视同现金按规定由付款银行进行登记报备。
第十四条付款银行在办理单位银行结算账户通过本系统处理的支付业务时，必须确认收付款人签订的付款协议或付款人签发的支付密码的有效性。
第十五条付款银行在办理个人银行结算账户通过本系统处理的支付业务时，必须确认收付款人签订的付款协议的有效性或付款人的取款密码与存折、银行卡等介质同时有效并一致。
第十六条除办理依据付款协议付款的支付业务以外，单位银行结算账户的存款人在与开户银行必须约定使用支付密码办理各种支付结算业务后，方可通过本系统办理各种收、付款业务。在业务办理中，必须按规定使用支付密码。第十七条除办理依据付款协议付款的支付业务以外，个人银行结算账户的存款人可在开户银行允许的业务范围内，通过本系统办理各种收、付款业务。在业务办理中，必须将存折或银行卡等介质与取款密码同时使用。
个人银行结算账户的存款人也可比照单位银行结算账户存款人与开户银行约定使用支付密码，签订有关协议，通过本系统办理单位银行结算账户有关的支付结算业务。第十八条存款人与银行约定使用支付密码通过本系统办理业务的，必须对是否凭有效的支付密码作为银行办理支付的唯一依据
以及双方相应的责任义务予以明确约定。
第十九条银行在受理通过本系统处理的个人支付业务时，必须采用具有加密功能的密码键盘对客户密码进行加密处理，以保障个人密码的安全性。
第二十条支付业务信息在发起方与DPC，以及接收方与DPC之间传递，须符合营管部规定的信息格式，并按照规定编核本系统同城密寸甲。加编有本系统同城密寸甲的业务信息方为有效信息。
本系统同城密寸甲由营管部负责管理。
第二十一条 直接参与者通过本系统办理业务，应按规定支付费用、享有收益。
第二十二条 系统参与者受理本系统有关业务，应使用营管部规定的专用凭证和专用业务印章。专用凭证由营管部统一印制，各参与者应根据业务性质和管 理要求分别按重要空白凭证和普通凭证进行管理。第二十三条 营管部可根据防范风险和管理的需要，对直接参与者所能发起及接收的各类业务实施控制。
各直接参与者应可根据需要，对在本机构开设的存款账户所能办理的业务种类实行控制管理。
第二十四条 本系统运行工作日的起止时间由营管部统一规定。营管部根据需要可以调整运行工作日时间。
第三章 业务处理规定
第二十五条 本系统实时处理下列业务：
(一)同城实时贷记支付业务。包括转账支票委托付款业务、银行本票委托付款业务、直接贷记业务、委托收款划回业务、同城特约委托收款划回业务、个人贷记转账业务。(二)同城实时借记支付业务。包括转账支票委托收款业务、银行本票业务、个人借记转账业务。
(三)对公通存通兑业务。包括转账银行本票通存通兑业务、现金银行本票通兑业务、转账支票通存通兑业务、现金支票通兑业务、现金通存业务。
(四)个人通存通兑业务。个人转账业务通存通兑业务、个人现金业务通存业务、个人现金通兑业务。
(五)跨行委托汇兑业务。包括单位跨行委托汇兑业务和个人跨行委托汇兑业务。(六)实时贷记抹账业务。(七)营管部规定的其他业务。
第二十六条 营管部可根据管理需要对不同支付业务规定相应的交易金额限制，并通过DPC实施控制。
第二十七条 使用现金支票跨行支取现金的，单一账户每日累计支取现金不得超过3次，每次支取金额不得超过人民币10000元。
使用存折或银行卡跨行支取现金的，单一账户每日累计支取现金不得超过3次，每次支取金额不得超过人民币5000元。
第二十八条 通过本系统办理各类业务的凭证上的收款人名称、付款人名称应使用其法定名称，名称为单位名称的，也可使用规范化简称。
收付款人名称必须与对应账号相符一致。
第二十九条 通过本系统办理的票据业务，其业务发起时间应在票据提示付款期内。
第三十条通过本系统办理银行本票业务，其受理银行为票据的付款银行或代理付款银行。提示付款时，持票人为单位的，应按规定在票据背面‚持票人向银行提示付款签章‛处签章；个人持票人凭注明‚现金‛字样的银行本票向银行支取现金的，除应按规定在票据背面‚持票人向银行提示付款签章‛处签章外，还应在票据背面记载本人身份证件名称、号码及发证机关，并交验本人身份证件及其复印件。
第三十一条 通过本系统办理支票业务，可由出票人或持票人到银行办理。
转账支票的出票人到银行办理委托付款的，受理银行为付款银行或代理付款银行。
转账支票的持票人到付款银行办理提示付款的，应按规定在票据背面背书人签章栏签章；到收款银行、或收付款银行以外的其他银行办理委托收款的，应作委托收款背书。
现金支票的持票人到银行办理提示付款的，受理银行为付款银行或代理付款银行。持票人应在票据背面‚收款人签章‛处签章，持票人为个人的还应在票据背面记载本人身份证件名称、号码及发证机关，并交验本人身份证件及其复印件。
第三十二条 发起清算行与DPC、接收清算行与DPC之间发送和接收支付业务信息，应采取联机方式实时处理。出现联机中断的，应及时恢复，当日不能恢复的，必须在日终时采用磁介质方式与DPC核对当日已发生的所有业务。第三十三条 发起行(发起清算行)受理业务后应及时向本系统发送支付业务信息；DPC收到支付业务信息后，应及时转发；接收行(接收清算行)应及时处理并向DPC反馈处理结果。
交易(业务)失败的，DPC应及时向相关各参与者发送失败结果；交易(业务)成功的，DPC应及时向相关各参与者发送成功结果，并以此作为是否纳入清算的标志。
第三十四条 发起行(发起清算行)发起交易后未收到DPC回应结果的，可及时向DPC查询该笔业务的状态。
有查询回应结果的，根据其进行相应处理；无查询回应结果 的，受理银行应留下客户地址及联系方式，暂时留置相关凭证和 现金，向客户出具待处理交易滞留证明。是个人业务的，还应将 存折、银行卡退交客户。
客户应俟后凭待处理交易滞留证明到受理银行续办业务。
银行根据确定的交易结果，收回待处理交易滞留证明后，分 别情况进行处理。
第三十五条 银行在签发银行本票时必须由签发行编制支付密码并按要求记载在银行本票正面。支付密码的编码要素包括出票日期、金额、业务种类、凭证号码、签发行行号(代付款账号)。受理银行在受理银行本票时一律通过本系统或行内业务系统查 验银行本票上支付密码的有效性。银行本票的受理时间与本系统 银行本票业务受理时间一致。
第三十六条 参与者对有疑问或发生差错的支付业务，应在当日 至迟次日12：00前发出查询。查复行应在收到查询信息的当日至
迟次日12：00前予以查复。
查询查复行及系统各节点应建立查询查复登记簿，并对查询 查复信息进行配对管理。
第三十七条 付款银行认为受理银行末按规定对票据和结算凭证进行审查的，应自业务发生之日起三个运行工作日内，通过本系统向受理银行发出查询，明确告知其未按规定审查的详细情形，受理银行应及时查复。未按规定时间向受理银行发出查询的，视作付款银行对受理银行的审查无异议。
第三十八条 委托汇兑业务受理成功后，受理行对汇款人不再承 担查询责任。汇款人如有疑问或汇款出现异常情况，由汇款人开 户银行负责解决。
第三十九条 发起行对发起的实时支付业务不能撤销。第四十条发起行对因自身原因误发实时贷记支付业务的，可向 接收行发送实时贷记抹账业务请求。实时贷记抹账业务的发起必 须经过相应授权。接收行收到发起行的抹账请求后，应立即检查 是否打印收账通知、接收人账户资金情况，能够支付的，即时办 理抹账。否则，退回抹账请求，有关业务的处理由发起行与有关 当事人协商解决。
第四十一条 客户办理本系统有关业务不能成功时，受理银行应 将不能成功的业务理由或其他理由告知客户。
业务理由是指受理银行、收款银行、付款银行所作的拒绝理 由。
其他理由是指受理银行、收款银行、付款银行以及DPC因拒 绝理由以外的原因导致业务不能成功的理由。第四十二条 银行通过本系统对接收的有关业务做拒绝处理时，应按本办法规定的种类，作出与所拒绝业务相匹配的拒绝理由。对涉及票据的实时借记转账和通兑业务的拒绝理由即为该 票据的退票理由，由受理银行代付款银行以交易失败证明形式告 知客户。
第四十三条 本系统实时业务处理拒绝理由包括：(一)收款账号不存在(二)付款账号不存在(三)收款账号户名不符(四)付款账号户名不符(五)付款账户存款不足(六)支付密码错误(七)无此凭证号码(八)账户冻结
(九)已挂失／依法止付(十)银行本票金额不符(十一)银行本票出票日期不符(十二)取款密码错误(十三)磁条信息不符
(十四)收账通知已打印无法抹账
第四十四条 本系统实时业务处理不能成功的其他理由包(一)金额超限额(二)交易超时(三)接收行未注册
(四)账号与账户类型不符无法识别(五)交易币种不存在或未开通此币种交易(六)手续费计算错误
(七)收款账户未开通此类业务(八)付款账户未开通此类业务，(九)收款行未开通此类业务(十)付款行未开通此类业务(十一)受理行未开通此类业务
(十二)收款控制(收款银行被控制收款)(十三)付款控制(付款银行被控制付款)(十四)收款行系统故障(十五)付款行系统故障
第四十五条 通过本系统处理的各种业务凭证应按要求加盖‚武汉电子支付系统业务专用章‛。
第四十六条 发起行受理的单位存款人提交的非本行付款的借方票据和凭证，在通过本系统处理成功后应将对应票据和凭证通过同城票据交换专门场次表外提给付款银行。第四十七条 受理行受理的单位存款人提交的贷记业务凭证以及个人提交的借记和贷记凭证一律截留在业务发起(受理)银行，接收行根据接收的电子数据产生相应的业务凭证。第四十八条 由受理银行交给客户的本系统各种支付业务受理回执，不作资金已收妥的依据，仅用于向受理银行查询。
资金是否已收妥应以收款银行交给收款人的收账通知(凭证)或打印在存折上的贷方(收方)记录为准。
委托汇兑业务中，受理银行交给客户的汇兑凭证回执联作为付款人付款依据。
个人存折上交易结果的记录由其开户银行负责登记。
第四章 业务收费
第四十九条 本系统处理的各类业务的电子交易手续费一律由付款人支付。
银行本票业务的电子交易手续费由付款银行(出票银行)支付，实时贷记抹账业务的电子交易手续费由原交易的付款银行支付。
第五十条除现金存款电子交易手续费由客户直接向受理银行以现金方式支付外，其他业务的电子交易手续费一律以转账方式支付。
第五十一条 银行在受理个人业务时，应明确告知电子交易手续费收费标准和收取方式；开户银行在办理单位业务前，应与存款人书面约定电子交易手续费标准和收取方式。第五十二条 交易成功的，银行应即时收取电子交易手续费；交易失败的，不收取电子交易手续费。
第五十三条 银行代收的本系统电子交易手续费应专户存放，不随对应业务纳入当日轧差清算，并按规定定期与DPC及相关银行结箅。
第五章 资金清算
第五十四条 直接参与者应在其清算账户存有足够的资金，用于本机构及所属间接参与者支付业务的资金清算。
存款人应在银行存款账户中存有足够的资金，用于办理支付业务。
第五十五条 DPC对实时借记业务、实时贷记业务和通存通兑业务按收到的先后／顷序实时处理。
第五十六条 营管部根据有关规定或管理需要，可以对直接参与者的清算账户进行管理。
第五十七条 营管部可以根据需要设定或调整本系统每一工作日的轧差场次和轧差时间。
第五十八条 本系统依据当日交易成功的业务数据产生清算轧差净额，并于当日通过清算账户清算，清算账户禁止隔夜透支。
第六章 日终处理
第五十九条 日终处理时，DPC试算平衡后，应通知各直接参与者与DPC对帐。直接参与者可以从DPC下载当日有关账务信息并对账。
第六十条各直接参与者与DPC对账不符的，可向DPC申请下载账务明细信息进行核对。核对不符的，应以从DPC下载的账务明细信息为准进行账务调整。
第七章 纪律与责任
第六十一条 本系统的各参与者和运行者应遵守本办法以及其他相关规定，不得拖延支付，截留、挪用客户和他行资金；不得因清算账户头寸不足影响客户和他行资金使用；不得疏于系统管理，影响系统安全、稳定运行；不得泄露密寸甲和密钥，影响资金安全；不得有疑不查，查而不复；不得伪造、篡改支付业务，盗用资金。
第六十二条 参与者和运行者因工作差错延误支付业务的处理，影响客户和他行资金使用的，应按中国人民银行规定的同档次流动资金贷款利率计付赔偿金。
第六十三条 参与者违反规定故意拖延支付，截留挪用资金，影响客户和他行资金使用的，应按规定承担赔偿责任。第六十四条 参与者和运行者的工作人员在办理本系统支付业务中玩忽职守，或出现重大失误，造成资金损失的，应按规定承担行政责任，情节严重的，依法追究刑事责任；伪造、篡改支付业务盗用资金的，依法追究刑事责任。第六十五条 参与者未在规定的时间内发出和答复业务查询，造成资金延误的，应按规定承担赔偿责任。
第六十六条 受理银行未按规定进行票据和结算凭证审查，付款银行对。此已按规定查询的，受理银行应承担相应责任，否则，由付款银行承担相应责任。第六十七条 因实时贷记抹账业务产生的相关责任由发起该业务的直接参与者承担，与实时贷记抹账业务的接收行无关。
第六十八条 存款人不按规定通过本系统办理支付结算业务，影响资金使用或造成资金损失的，由其自行负责。第六十九条 存款人违反与银行的约定，开户银行应拒绝为其通过本系统办理业务，情节特别严重的，各银行应停止为其办理支付结算业务。
第七十条参与者和运行者应妥善保管密寸甲，严防泄露。因保管不善泄露密押，造成资金损失的，有关责任方应按规定承担赔偿责任。故意泄露密寸甲情节严重的，应依法追究刑事责任。
第七十一条 因不可抗力造成系统无法正常运行的，有关当事人均有及时排除障碍和采取补救措施的义务，但不承担赔付责任。
第八章 附 则
第七十二条 DPC联机存储支付信息的时间为30个运行工作日。
支付信息的脱机保存时间按照同类会计档案的时间保存。第七十三条 本办法由营管部负责解释、修改。第七十四条 本办法于2005年月 日起试行。
武汉电子支付系统借方凭证事后处理流程
一、原则
本系统实时处理的提出借方业务，在通过本系统处理成功后，应将业务对应的票据和凭证通过同城票据交换专门场次提给
二、发起行的处理
发起行当日受理的单位存款人提交的非本行付款的借方票据和凭证，通过本系统处理成功后，在电子业务对应的纸质票据和凭证上打印磁码，集中装入事后交换专用票据袋，随同次日一次清算送交人民银行电子结算中心。
三、电子结算中心的处理
电子结算中心在次日一次交换清分结束后，开设本系统事后票据交换专场。该场票据交换只将票据清分到各交换行，不做帐务处理。
事后票据清分结束后，票据应装入事后交换专用票据袋，随次日一次清算票据袋一起，于次日上午送交付款行。
四、付款行的处理
付款行收到本系统事后交换的借方票据和凭证，应与原电子交易核对，或按照各行相关事后监督规定执行。
武汉电子支付系统 实时业务处理手续
武汉电子支付系统项目组
2005年二月
第一部分实时贷记支付业务
一、转账支票委托付款业务
二、直接贷记支付业务
三、委托收款划回
四、同城特约委托收款划回等贷记支付业务
五、个人贷记转账业务第： 二部分实时借记支付业务
一、转账支票业务：
二、银行本票业务
三、个人借记转账业务 第三部分通存通兑业务
一、对公业务通存通兑
二、个人业务通存通兑 第四部分跨行委托汇兑
一、单位跨行委托汇兑
二、个人跨行委托汇兑 第五部分银行专用业务
一、实时贷记抹账第六部分差错和异常处理
一、差错的处理(一)密押错误的处理(二)行号错误的处理．
(三)重复发送的处理(四)接收人差错的处理(五)报文无法识别的处理
三、异常情况的处理
(一)联机异常的处理
(二)无回应结果的处理。(三)滞留业务的处理
(四)日终账务无法下载的处理
(五)DPC日终试算不平的处理．(六)支付业务信患核对不符的
(七)被拒绝业务的处理
第七部分业务收费 第八部分轧差清算 第九部分查询查复
第十部分 密押的使用和管理
第一部分实时贷记支付业务
一、转账支票委托付款业务(一)受理行(发起行、付款行)转账支票的出票人签发票据后，按规定填制进账单，并在‚通过武汉电子支付系统‛ 栏注明‚√‛后，直接到付款银行(开户银行)办理委托付款。
付款银行受理票据和进账单后，按规定进行凭证审查，审查通过的，银行前台操作员录入收付款凭证要素，检查付款帐户是否开通武汉电子支付系统业务，银行行内系统允许付款的，向收款行发起交易信息。
武汉支付系统数据处理中心(以下简称DPC)反馈交易成功信息的，同时在进账单第一、二联及票据上加盖‚武汉电子支付系统业务处理专用章‛，在票据上加盖‚转讫‛章，并将进账单
第一联(送票回执联)交客户，进账单第二、三联(贷方凭证和收账通知)截留在受理行。会计分录为：
借：XX科目一一付款人账户
贷：存放中央银行款项一一同城电子支付往账 DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明(代退票理由书)，注明交易失败原因，加盖‚武汉电子支付系统业务处理 专用章‛，连同票据和进账单退给原办理业务的客户，不作账务处理。
(二)接收行(收款行)收款银行接到贷方交易信息后，检查账号和户名的一致性，收款账户是否为银行结算账户，收款账户为单位银行结算账户的，还要检查该帐户是否开通武汉电子支付系统业务，并向DPC反馈检查结果，等待DPC反馈交易结果。DPC反馈交易成功结果的，打印武汉电子支付来账贷方补充凭证(两联)，并加盖‚转讫‛章。会计分录为：
借：存放中央银行款项一一同城电子支付来账
贷：XX科目一一收款人账户
(三)持票人持转账支票到付款银行提示付款，付款银行按规定对票据进行审查，并比照第一部分一(一)、(二)内容处理。
二、银行本票委托付款业务 7．受理行(发起行)银行本票的持票人按规定填制进账单，并在‚通过武汉电子支付系统‛ 栏注明‚√‛后，到付款银行办理提示付款。
受理银行受理票据和进账单后，按规定进行凭证审查，审查通过的，银行前台操作员录入收付款凭证要素，银行行内系统允许付款的，向收款行发起交易信息。
DPC反馈交易成功结果的，同时在进账单第一、二、三联及票据上加盖‚武汉电子支付系统业务处理专用章‛，并将进账单
第一联(送票回执联)交客户，进账单第二、三联(贷方凭证和收账通知)截留在受理行。会计分录为：
借：开出本票
贷：存放中央银行款项一一同城电子支付往账 DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明(代退票理由书)，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同票据和进账单退给原办理业务的客户，不作账务处理。也可另行处理。2．收款行(接收行)收款银行接到贷方交易信息后，检查账号和户名的一致性，收款账户是否为银行结算账户，并向DPC反馈检查结果，等待DPC反馈交易结果。
DPC反馈交易成功结果的，打印武汉电子支付来账贷方补充凭证(两联)，并加盖‚转讫‛章。会计分录为：
借：存放中央银行款项一一同城电子支付来账
贷：XX科目一一收款人账户
三、直接贷记业务(支款凭证)付款人(单位银行存款账户存款人)填制直接贷记支付凭证(单联式)到付款银行办理支付业务，其业务处理比照第一部分一(一)、(二)内容处理。
四、委托收款划回业务
(一)受理行(接收行、收款行)发出委托收款
收款人按规定填制托收凭证(电划)连同商业汇票等债权证明，提交给开户银行，银行按规定审查后，通过票据交换表外提给付款银行，或邮寄付款银行。(二)付款行(发起行)付款银行按规定进行付款审查。不能付款的，按规定进行处理。同意付款的，付款银行录入托收凭证要素，银行行内系统允许付款的，向收款行发起交易信息。
DPC反馈交易成功结果的，同时在托收凭证第三、四联及商业汇票等债权证明上加盖‚武汉电子支付系统业务处理专用章‛，在托收凭证第三联及商业汇票等债权证明上加盖‚转讫‛章。会
计分录为：
借：XX科目一一付款人账户
贷：存放中央银行款项一一同城电子支付往账 DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同委托收款凭证第三、四、五联及商业汇票等债权证明退还收款行，不作账务处理。(三)接收行(收款行、受理行)收款银行接到贷方交易信息后，检查账号和户名的一致性，收款账户是否为银行结算账户，收款账户为单位银行结算账户的，还要检查该帐户是否开通武汉电子支付系统业务，并向DPC反馈检查结果，等待DPC反馈交易结果。DPC反馈交易成功结果的，打印武汉电子支付来账贷方补充凭证(两联)，并加盖‚转讫‛章。会计分录为：
借：存放中央银行款项一一同城电子支付来账
贷：XX科目一一收款人账户
五、同城特约委托收款划回业务
(一)受理行(接收行、收款行)发出委托收款
收款人按规定填制特约委托收款凭证(电划)，提交给开户银行，银行按规定审查后，通过票据交换表外提给付款银行。
(二)付款行(发起行)付款银行按规定进行付款审查。不能付款的，按规定进行处理。同意付款的，付款银行录入特约委托收款凭证要素，检查付款帐户是否开通武汉电子支付系统业务，银行行内系统允许付款的，向收款行发起交易信息。
DPC反馈交易成功结果的，同时在特约委托收款凭证第三、四、五联上加盖‚武汉电子支付系统业务处理专用章‛，在特约委托收款凭证第三、五联上力口盖‚转讫‛章。会计分录为：
借：XX科目一一付款人账户
贷：存放中央银行款项一一同城电子支付往账 DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同委托收款凭证第三、四、五联退还收款行，不作账务处理。
(三)接收行(收款行、受理行)收款银行接到贷方交易信息后，检查账号和户名的一致性，收款账户是否为银行结算账户，收款账户为单位银行结算账户的，还要检查该帐户是否开通武汉电子支付系统业务，并向DPC反馈检查结果，等待DPC反馈交易结果。DPC反馈交易成功结果的，打印武汉电子支付来账贷方补充凭证(两联)，并加盖‚转讫‛章。会计分录为：
借：存放中央银行款项一一同城电子支付来账
贷：XX科目一一收款人账户 个人贷记转账业务
(一)受理行(发起行、付款行)个人付款人按规定填制个人跨行电子支付业务凭证，在业务类型‚转账‛栏注明‚√‛后，持付款账户对应的存折或银行卡到付款银行办理。
银行通过专用设备读取存折或银行卡中的账户信息，同时按规定进行凭证审查，审查通过的，银行前台操作员录入款凭证要素，客户通过专用设备输入取款密码，银行行内系统允许付款的，向收款行发起交易信息。
DPC反馈交易成功结果的，同时在个人跨行电子支付业务凭证上打印成功处理结果，并在第一、二联上加盖‚武汉电子支付系统业务处理专用章‛，在个人跨行电子支付业务凭证第一联上加盖‚转讫‛章。将个人跨行电子支付业务凭证第二联(回执联)连同存折或银行卡交客户，第一联截留在受理行。会计分录为：
借：XX科目一一付款人账户
贷：存放中央银行款项一一同城电子支付往账 DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，在个人跨行电子支付业务凭证处理结果栏注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，将个人跨行电子支付业务凭证连同存折或银行卡退给客户，第一联留存备查，不作账务处理。(二)接收行(收款行)收款银行接到贷方交易信息后，检查账号和户名的一致性，收款账户是否为银行结算账户，收款账户为单位银行结算账户的，还要检查该帐户是否开通武汉电子支付系统业务，并向DPC反馈检查结果，等待DPC反馈交易结果。DPC反馈交易成功结果的，打印武汉电子支付来账贷方补充凭证(两联)，并加盖‚转讫‛章。会计分录为：
借：存放中央银行款项一一同城电子支付来账
贷：XX科目一一收款人账户
第二部分实时借记支付业务
一、转账支票委托收款业务(一)受理行(发起行、收款行)转账支票的持票人按规定填制进账单，并在‚通过武汉电子支付系统‛ 栏注明‚√‛后，到收款银行(开户银行)办理委托收款。
收款银行受理票据和进账单后，按规定进行凭证审查，收款帐户是否开通武汉电子支付系统业务，审查通过的，银行前台操作员录入收付款凭证要素，向付款行发起交易信息。
DPC反馈交易成功结果的，同时在进账单第一联及票据上加盖‚武汉电子支付系统业务处理专用章‛，在进账单第二、三联上加盖‚转讫‛章，并将进账单第一(送票回执联)交客户，票据俟后通过专场票据交换表外提给付款银行。会计分录为：
借：存放中央银行款项一一同城电子支付往账
贷：XX科目一一收款人账户
DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明(代退票理由书)，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同票据和进账单退给原办理业务的客户，不作账务处理。(二)接收行(付款行)付款银行接到借方交易信息后，检查付款账户余额、支付密码的有效性及账号和户名的一致性，该帐户是否开通武汉电子支付系统业务，并向DPC反馈检查结果，等待DPC反馈交易结果。拒绝付款的，应将拒绝付款理由反馈给DPC。
DPC反馈交易成功结果的，打印武汉电子支付来账借方补充凭证，加盖‚转讫‛章。事后提入的借方凭证作附件。会计分录为：
借：XX科目一一收款人账户
贷：存放中央银行款项一一同城电子支付往账
二、银行本票业务
(一)受理行(发起行、收款行)银行本票的持票人按规定填制进账单，并在‚通过武汉电子支付系统‛ 栏注明‚√‛后，到收款银行(开户银行)办理提示付款。
收款银行受理票据和进账单后，按规定进行凭证审查，审查通过的，银行前台操作员录入收付款凭证要素，向付款行发起交易信息。
DPC反馈交易成功结果的，同时在进账单第一联及票据上加盖‚武汉电子支付系统业务处理专用章‛，在进账单第二、三联上加盖‚转讫‛章，并将进账单第一联(送票回执联)交客户，票据俟后通过专场票据交换表外提给付款银行。会计分录为：
借：存放中央银行款项一一同城电子支付往账
贷：XX科目一一收款人账户
DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明(代退票理由书)，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同票据和进账单退给原办理业务的客户，不作账务处理。(二)接收行(付款行)付款银行接到借方交易信息后，检查本票是否为本行签发、支付密码的有效性，并向DPC反馈检查结果，等待DPC反馈交易结果。拒绝付款的，应将拒绝付款理由反馈给DPC。DPC反馈交易成功结果的，打印武汉电子支付来账借方补充凭证，加盖‚转讫‛章。事后提入的借方凭证作附件。会计分录
三、个人借记转账业务 一同城电子支付来账
(一)受理行(发起行、收款行)个人付款人按规定填制个人跨行电子支付业务凭证，在业务类型‚转账‛栏注明‚√‛后，持付款账户对应的存折或银行卡到收款银行办理。
银行通过专用设备读取存折或银行卡中的账户信息，同时按规定进行凭证审查，审查通过的，银行前台操作员录入款凭证要素，客户通过专用设备输入取款密码，向付款行发起交易信息。
DPC反馈交易成功结果的，同时在个人跨行电子支付业务凭证上打印成功处理结果，并在第一、二联上力口盖‚武汉电子支付系统业务处理专用章‛，在个人跨行电子支付业务凭证第一联上加盖‚转讫‛章，并将个人跨行电子支付业务凭证第二联(回执联)连同存折或银行卡交客户。会计分录为：
借：存放中央银行款项一一同城电子支付往账
贷：XX科目一一收款人账户
DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，在个人跨行电子支付业务凭证处理结果栏注明‚交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，将个人跨行电子支付业务凭证连同存折或银行卡退给客户，第一联留存备查，不作账务处理。(二)接收行(付款行)付款银行接到借方交易信息后，检查付款账户余额、取款密码的有效性、磁条信息的有效性及账号和户名的一致性，并向DPC反馈检查结果，等待DPC反馈交易结果。拒绝付款的，应将拒绝付款理由反馈给DPC。
DPC反馈交易成功结果的，打印武汉电子支付来账借方补充凭证，加盖‚转讫‛章。会计分录为：
借：XX科目——付款人账户
贷： 存放中央银行款项一一同城电子支付来账
第三部分通存通兑业务
一、对公业务通存通兑业务(一)转账银行本票通存通兑业务 1．受理行(发起行)银行本票的持票人按规定填制进账单，并在‚通过武汉电子支付系统‛ 栏注明‚√‛后，到收款银行以外的银行办理提示付款。
受理银行受理票据和进账单后，按规定进行凭证审查，审查通过的，银行前台操作员录入收付款凭证要素，向收款行和付款行发起交易信息。
DPC反馈交易成功结果的，同时在进账单第一、二、三联及票据上加盖‚武汉电子支付系统业务处理专用章‛，并将进账单第一联(送票回执联)交客户，进账单第二、三联(贷方凭证和收账通知)截留在受理行。票据俟后通过专场票据交换表外提给付款银行。会计分录为：
借：存放中央银行款项一一同城电子支付往账
贷：存放中央银行款项一一同城电子支付往账 DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明(代退票理由书)，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同票据和进账单退给原办理业务的客户，不作账务处理。2．付款行(接收行)付款银行接到借方交易信息后，检查本票是否为本行签发、支付密码的有效性，并向DPC反馈检查结果，等待DPC反馈交易结果。拒绝付款的，应将拒绝付款理由反馈给DPC。DPC反馈交易成功结果的，打印武汉电子支付来账借方补充凭证，加盖‚转讫‛章。事后提入的借方凭证作附件。会计分录 借：开出本票
贷： 存放中央银行款项 同城电子支付来账 3．收款行(接收行)收款银行接到贷方交易信息后，检查账号和户名的一致性，收款账户是否为银行结算账户，并向DPC反馈检查结果，等待DPC反馈交易结果。
DPC反馈交易成功结果的，打印武汉电子支付来账贷方补充凭证(两联)，并加盖‚转讫‛章。会计分录为：
借：存放中央银行款项一一同城电子支付来账
贷：XX科目一一收款人账户(二)现金银行本票通兑
1．受理行(发起行、兑付行)银行本票的持票人持个人身份证件及现金银行本票到签发银行以外的银行办理兑付。受理银行受理票据后，按规定对客户身份、凭证进行审查，审查通过的，银行前台操作员录入收付款凭证要素，向付款行发起交易信息。
DPC反馈交易成功结果的，打印武汉电子支付往账借方补充凭证，在票据及武汉电子支付往账借方补充凭证上加盖‚武汉电子支付系统业务处理专用章‛和‚现金付讫‛章，现金清点无误后交客户，票据俟后通过专场票据交换表外提给付款银行。会计
借：存放中央银行款项一一同城电子支付往账
贷：现金
DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明(代退票理由书)，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同票据退给原办理业务的客户，不作账务处理。2．接收行(付款行)付款银行接到借方交易信息后，检查本票是否为本行签发、支付密码的有效性，并向DPC反馈检查结果，等待DPC反馈交易结果。拒绝付款的，应将拒绝付款理由反馈给DPC。DPC反馈交易成功结果的，打印武汉电子支付来账借方补充凭证，加盖‚转讫‛章。事后提入的借方凭证作附件。会计分录为： 借：开出本票
贷： 存放中央银行款项一一同城电子支付来账
受理银行受理票据后，按规定对客户身份、凭证进行审查，审查通过的，银行前台操作员录入收付款凭证要素，向付款行发起交易信息。
DPC反馈交易成功结果的，打印武汉电子支付往账借方补充凭证，在票据及武汉电子支付往账借方补充凭证上加盖‚武汉电子支付系统业务处理专用章‛和‚现金付讫‛章，现金清点无误后交客户，票据俟后通过专场票据交换表外提给付款银行。会计
借：存放中央银行款项一一同城电子支付往账
贷：现金
DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明(代退票理由书)，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同票据退给原办理业务的客户，不作账务处理。2．接收行(付款行)付款银行接到借方交易信息后，检查本票是否为本行签发、支付密码的有效性，并向DPC反馈检查结果，等待DPC反馈交易结果。拒绝付款的，应将拒绝付款理由反馈给DPC。DPC反馈交易成功结果的，打印武汉电子支付来账借方补充凭证，加盖‚转讫‛章。事后提入的借方凭证作附件。会计分录为：
借：开出本票
贷： 存放中央银行款项一一同城电子支付来账(三)转账支票通存通兑业务 1．受理行(发起行)转账支票的持票人按规定填制进账单，并在‚通过武汉电子支付系统‛ 栏注明‚√‛后，到收款银行或付款银行以外的银行办理委托收款。
受理银行受理票据和进账单后，按规定进行凭证审查，审查通过的，银行前台操作员录入收付款凭证要素，向收款行和付款行发起交易信息。
DPC反馈交易成功结果的，同时在进账单第一、二、三联及票据上加盖‚武汉电子支付系统业务处理专用章‛，并将进账单第一联(送票回执联)交客户，进账单第二、三联(贷方凭证和收账通知)截留在受理行。票据俟后通过专场票据交换表外提给付款银行。会计分录为：
借：存放中央银行款项一一同城电子支付往账
贷：存放中央银行款项一一同城电子支付往账 DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明(代退票理由书)，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同票据和进账单退给原办理业务的客户，不作账务处理。2．付款行(接收行)付款银行接到借方交易信息后，检查付款账户余额、支付密码的有效性及账号和户名的一致性，该账户是否开通武汉电子支付系统业务，并向DPC反馈检查结果，等待DPC反馈交易结果。拒绝付款的，应将拒绝付款理由反馈给DPC。DPC反馈交易成功结果的，打印武汉电子支付来账借方补充凭证，加盖‚转讫‛章，事后提入的借方凭证作附件。会计分录
借：XX科目一一付款人账户
贷： 存放中央银行款项 同城电子支付来账 3．收款行(接收行)收款银行接到贷方交易信息后，检查账号和户名的一致性，收款账户是否为银行结算账户，收款账户为单位银行结算账户的，还要检查该帐户是否开通武汉电子支付系统业务，并向DPC反馈检查结果，等待DPC反馈交易结果。DPC反馈交易成功结果的，打印武汉电子支付来账贷方补充凭证(两联)，并加盖‚转讫‛章。会计分录为：
借：存放中央银行款项一一同城电子支付来账
贷：XX科目一一收款人账户(四)现金支票通兑业务
1．受理行(发起行、兑付行)现金支票的持票人持现金支票到开户银行以外的银行办理兑付，持票人为个人的，还应提交个人身份证件。
受理银行受理票据后，按规定对客户身份、凭证进行审查，审查通过的，银行前台操作员录入收付款凭证要素，向付款行发起交易信息。
DPC反馈交易成功结果的，打印武汉电子支付往账借方补充凭证，在票据及武汉电子往账支付借方补充凭证上加盖‚武汉电子支付系统业务处理专用章‛和‚现金付讫‛章，现金清点无误后交客户，票据俟后通过专场票据交换表外提给付款银行。会计分录为：
借：存放中央银行款项
贷：现金 同城电子支付往账
DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明(代退票理由书)，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同票据退给原办理业务的客户，不作账务处理。2．接收行(付款行)付款银行接到借方交易信息后，检查付款账户余额、支付密码的有效性及账号和户名的一致性，该账户是否开通武汉电子支付系统业务，并向DPC反馈检查结果，等待DPC反馈交易结果。拒绝付款的，应将拒绝付款理由反馈给DPC。DPC反馈交易成功结果的，打印武汉电子支付来账借方补充凭证，加盖‚转讫‛章，事后提入的借方凭证作附件。会计分录
(五)现金通存业务 一同城电子支付来账
(一)受理行(发起行、付款行)存款人按规定填制现金缴款单，持现金到开户银行以外的银行办理现金缴存业务。
受理银行受理凭证和现金后，清点现金并按规定进行凭证审查，审查通过的，银行前台操作员录入收付款凭证要素，向收款行发起交易信息。
反馈交易成功结果的，同时在现金缴款单第二联上加盖 ‚武汉电子支付系统业务处理专用章‛，第一、二联上加盖‚现金收讫‛章，并将第一联交客户。会计分录为：
借：现金
贷：存放中央银行款项一一同城电子支付往账
反馈交易失败结果的，可视情况选择重新发起交易。无 法成功处理的，打印武汉电子支付系统交易失败证明，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同凭证和现金退给原办理业务的客户，不作账务处理。(二)接收行(收款行)收款银行接到贷方交易信息后，检查账号和户名的一致性、该帐户是否开通武汉电子支付系统业务，并向 反馈检查结果，等待 反馈交易结果。
反馈交易成功结果的，打印武汉电子支付来账贷方补充 凭证(两联)，并加盖‚转讫‛章。会计分录为：
借：存放中央银行款项一一同城电子支付来账
贷： 科目一一收款人账户
二、个人业务通存通兑(一)个人转账业务通存通兑 1．受理行(发起行)个人付款人按规定填制个人跨行电子支付业务凭证，在业务类型‚转账‛栏注明‚√‛后，持付款账户对应的存折或银行卡到收、付款银行以外的银行办理转账业务。
受理银行通过专用设备读取存折或银行卡中的账户信息，同时按规定进行凭证审查，审查通过的，银行前台操作员录入款凭证要素，客户通过专用设备输入取款密码，向收、付款行发起交易信息。
DPC反馈交易成功结果的，同时在个人跨行电子支付业务凭证第一、二联上加盖‚武汉电子支付系统业务处理专用章‛，将个人跨行电子支付业务凭证第二联(回执联)连同存折或银行卡交客户，第一联截留在受理行。会计分录为：
借：存放中央银行款项一一同城电子支付往账
贷：存放中央银行款项一一同城电子支付往账 DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，在个人跨行电子支付业务凭证处理结果栏注明‚交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，将个人跨行电子支付业务凭证连同存折或银行卡退给客户，第一联留存备查，不作账务处理。2．付款行(接收行)付款银行接到借方交易信息后，检查付款账户余额、取款密码的有效性、磁条信息的有效性及账号和户名的一致性，该账户是否为银行结算账户，并向 反馈检查结果，等待 反馈交易结果。拒绝付款的，应将拒绝付款理由反馈给。
反馈交易成功结果的，打印武汉电子支付来账借方补充 凭证，加盖‚转讫‛章。会计分录为：
借： 科目一一付款人账户
贷： 存放中央银行款项一一同城电子支付来账
收款行(接收行)收款银行接到贷方交易信息后，检查账号和户名的一致性，收款账户是否为银行结算账户，收款账户为单位银行结算账户的，还要检查该帐户是否开通武汉电子支付系统业务，并向反馈检查结果，等待 反馈交易结果。
反馈交易成功结果的，打印武汉电子支付来账贷方补充 凭证并加盖‚转讫‛章。会计分录为：
借：存放中央银行款项一一同城电子支付来账
贷： 科目一一收款人账户(二)个人现金通存业务
受理行(发起行、付款行)个人按规定填制个人跨行电子支付业务凭证(付款人栏空缺)，在业务类型‚存现‛栏注明‚√‛后，持收款账户对应的存折或银行卡到收款银行以外的银行办理存款业务。
受理银行通过专用设备读取存折或银行卡中的账户信息，同时按规定进行凭证审查，审查通过的，现金清点无误后，银行前台操作员录入款凭证要素，向收款行发起交易信息。
DPC反馈交易成功结果的，同时在个人跨行电子支付业务凭证第一、二联上加盖‚武汉电子支付系统业务处理专用章‛和‚现金收讫‛章，并将第二联交客户。会计分录为：
借：现金
贷：存放中央银行款项一一同城电子支付往账 DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，在个人跨行电子支付业务凭证处理结果栏注明‚交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同凭证和现金退给原办理业务的客户，第一联留存备查，不作账务处理。2．接收行(收款行)收款银行接到贷方交易信息后，检查磁条信息的有效性、账号和户名的一致性，收款账户是否为银行结算账户，并向DPC反馈检查结果，等待DPC反馈交易结果。
DPC反馈交易成功结果的，打印武汉电子支付来账贷方补充凭证，并加盖‚转讫‛章。会计分录为：
借：存放中央银行款项一一同城电子支付来账
贷：XX科目一一收款人账户(三)现金通兑
1．受理行(发起行、收款行)个人付款人按规定填制个人跨行电子支付业务凭证(收款人栏空缺)，在业务类型‚取现‛栏注明‚√‛后，持付款账户对应的存折或银行卡到付款银行以外的银行办理。
受理银行通过专用设备读取存折或银行卡中的账户信息，同时按规定进行凭证审查，审查通过的，银行前台操作员录入款凭证要素，客户通过专用设备输入取款密码，向付款行发起交易信息。
反馈交易成功结果的，同时在个人跨行电子支付业务凭 证第一、二联上力口盖‚武汉电子支付系统业务处理专用章‛和‚现金收讫‛章，并将清点无误的现金、个人跨行电子支付业务凭证第一联(回执联)连同存折或银行卡交客户，第二联截留在受理行。会计分录为：
借：存放中央银行款项
贷： 现金
同城电子支付往账 反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，在个人跨行电子支付业务凭证处理结果栏注明‚交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，将个人跨行电子支付业务凭证连同存折或银行卡退给客户，第一联留存备查，不作账务处理。(二)接收行(付款行)付款银行接到借方交易信息后，检查付款账户余额、取款密码的有效性、磁条信息的有效性及账号和户名的一致性，收款账户是否为银行结算账户，并向 反馈检查结果，等待 反馈交易结果。拒绝付款的，应将拒绝付款理由反馈给。
DPC反馈交易成功结果的，打印武汉电子支付来账借方补充凭证，加盖‚转讫‛章。会计分录为：
借：XX科目一一付款人账户
贷： 存放中央银行款项一一同城电子支付来账
第四部分跨行委托汇兑
一、单位跨行委托汇兑(一)发起行(受理行)单位存款人填制从付款银行领购的电汇凭证，到付款银行以外的其他银行，办理从指定账户发起的汇兑业务。
受理银行受理凭证后，按规定进行凭证审查，审查通过的，银行前台操作员录入收付款凭证要素，向付款行发起委托汇兑信，息。
DPC反馈交易成功结果的，同时在电汇凭证第一、二、三联上加盖‚武汉电子支付系统业务处理专用章‛，将电汇凭证第一联交客户，第三联截留在受理行，第二联俟后通过专场票据交换表外提给付款银行，不作账务处理。DPC反馈交易失败结果的，可视情况选择重新发起。无法成功处理的，打印武汉电子支付系统交易失败证明，注明失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同凭证退给客户，不作账务处理。(二)接收行(付款行、汇兑发起行)付款银行接到委托汇兑信息后，检查付款账户余额、支付密码的有效性及账号和户名的一致性，该帐户是否开通武汉电子支付系统业务，并向p卜反馈检查结果，等待／圹c反馈交易结果。付款行拒绝借记付款账户的，应将拒绝付款理由反馈给0／L。反馈成功信息的，打印武汉电子支付来账借方补充凭证，第一联作记账凭证，加盖‚转讫‛章，并与事后提入的借方凭证核对，第二联代发电依据。会计分录为：
借： 科目一一汇款人账户
贷： 联行往账
二、个人跨行委托汇兑(一)发起行(受理行)个人存款人持汇款账户对应的存折或银行卡到开户银行以外的其他银行，办理从指定账户发起的汇兑业务。
个人存款人在受理行购买并填制电汇凭证，连同存折或银行卡交受理银行。受理银行通过专用设备读取存折或银行卡中的账户信息，同时按规定进行凭证审查，审查通过的，银行前台操作员录入款凭证要素，客户通过专用设备输入取款密码，向付款行发起委托汇兑信息。
反馈交易成功结果的，同时在电汇凭证第一、二、三联上力口盖‚武汉电子支付系统业务处理专用章‛，将电汇凭证第一联交客户，第三联截留在受理行，第二联俟后通过专场票据交换表外提给付款银行，不作账务处理。DPC反馈交易失败结果的，可视情况选择重新发起。无法成功处理的，打印武汉电子支付系统交易失败证明，注明失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同凭证退给客户，不作账务处理。(二)接收行(付款行、汇兑发起行)付款银行接到委托汇兑信息后，检查付款账户余额、取款密码的有效性、磁条信息的有效性及账号和户名的一致性，该账户是否为银行结算账户，并向DPC反馈检查结果，等待DPC反馈交易结果。付款行拒绝借记付款人账户的，应将拒绝付款理由反馈给DPC。
DPC反馈交易成功结果的，打印武汉电子支付来账借方补充凭证第一联作记账凭证，加盖‚转讫‛章，并与事后提入的借方凭证核对，第二联代发电依据。会计分录为：
借：XX科目一一汇款人账户
贷： 联行往账
第五部分银行专用业务
一、实时贷记抹账业务
(一)发起行(收款行、原贷记业务发起行)发起行发现错发实时贷记交易时，在该笔业务进行轧差前，经行内授权，调出原错误贷记交易记录，向付款行(原交易收款行)发起交易信息。统可以重新发起。(二)行号错误的处理
业务实时监控方案 篇3
一、目标
本方案提供了一种基于数据库日志, 通过结合使用数据实时复制产品如Golden Gate、流处理产品如Stream和内存库如Timesten, 实现对业务受理数据进行及时监控的方法。主要目标是:
1、解决了数据获取的时效性问题。提供了一种基于数据库日志的实时数据获取方法, 数据处理与存储采用流技术与内存技术, 全过程不写磁盘, 在低生产系统开销的情况下提升整体数据获取跟分析的性能。2、实时与准实时数据应用能力。提供高效的实时统计、实时监控与准实时分析能力, 将数据应用的响应时间由传统的天级提升到分钟、小时级。3、辅助快速决策。实时与准实时的数据, 能提供了更广阔的应用场景, 如基于异常业务销售、办理波动, 迅速变更渠道资源如人员排班等工作, 又如库存变更与物流配送时间点合理安排, 提升厅店效率, 实现减员增效。最终实现将传统的业务分析从辅助决策长期目标向提供实时运营, 协助提高企业管控能力, 从而提升了企业数据信息的价值。
二、技术方案
本方案主要组成部分包括数据获取模块、数据处理模块、数据存储模块、数据应用模块、系统管理模块五个部分。各模块的功能具体说明如下:
1、数据获取模块。数据获取模块包括数据实时获取和数据实时加载两个子模块。当业务系统数据库因业务受理、业务回退等种种原因产生数据变动时, 数据获取子模块根据预定义需要监控的表, 通过数据复制产品实时捕获数据库相关变化LOG并转化成可识别的数据格式, 传递到流处理模块或内存库。数据加载子模块获取的数据按既定逻辑要求加载到数据存储模块, 过滤清洗掉与实时分析需求无关的数据, 降低数据存储的压力, 并保证目标系统与源系统的数据一致性。
2、数据存储模块。数据存储模块采用内存数据库作为存储介质, 对数据的进行集中存储与管理, 一方面避免了数据在处理过程中的大数据量交易数据落地写磁盘对分析性能的影响, 保障了处理过程的及时性;另一方面内存数据库也为外部频繁的数据实时读取、调用与分析提供了高效的响应能力。
3、数据处理模块。数据处理模块包括实时数据汇总与准实时数据分析两个子模块。实时数据汇总依托流处理的强大在线汇总能力, 获取并提交展示对及时性要求最高、逻辑相对简单的信息。准实时数据分析基于内存数据库, 按照既定的周期如每10分钟, 对加载的数据做轻度汇总, 并进一步的分析挖掘, 最终提交逻辑相对复杂的分析结果。
4、数据应用模块数据应用模块在获取数据处理模块的结果, 并构建各类业务场景, 如实时统计, 实时监控, 准实时分析等。实时统计面向业务量、收入等最核心的指标, 展示当前累计发展量, 尤其在短期促销时可更显性查看成果。实时监控通过监控波动率, 设定阀值门限等, 及时掌握收入风险、渠道交易异常、库存情况等, 用于管控风险。准实时分析不仅对业务数据做简单的汇总, 还可以通过设定多个维度, 实现更细致的分析, 如各渠道横向对比, 基于时间序列的纵向对比等。
5、系统管理模块。系统管理模块是系统稳定、高效运行的有效保障, 包括调度管理、负载均衡、异常控制等。调度管理具备任务管理、依赖管理、并发管理等功能, 按时间定时生成或者按照事件触发任务, 在满足系统能力或优先级要求时派发, 控制整个系统程序有条不紊执行。负载均衡主要对主机集群的管理, 将应用均衡分配到各主机节点, 充分发挥集群的性能, 以应对实时、准实时分析带来的高并发、高负荷分析与访问。异常控制则在系统出现异常时, 如设备故障、程序故障时, 提供临时解决方案, 确保系统的高可用性。
三、结语
非标准仓单质押业务 篇4
（一）什么是非标准仓单质押业务
非标准仓单质押业务商业银行向客户发放的，以仓储公司为货主出具的不可转让、不具有货权性质的仓库保管单、入库单（不包括标准仓单）为特定担保方式的授信业务。仓储质押担保项下可办理的授信业务主要包括短期贷款、商票贴现、开立银行承兑汇票、进口开证等短期授信业务。
（二）非标准仓单质押业务的特点
该业务有效解决了客户资金不足，担保不够与银行信用投放需要的矛盾，授信客户与商业银行签订《动产最高额质押合同》后，三方签订《仓储质押监管协议》，商业银行是仓储货物的质押权人，仓储公司代商业银行对仓储货物进行监管。客户可以得到用于经营周转所需的流动资金。
（三）非标准仓单质押业务的签发对象
是经工商行政管理机关（或主管机关）核准登记，实行独立核算的企、事业法人或其它经济组织。
（四）非标准仓单质押业务申请人应当具备在我行开立账户、资信状况良好、现金流量大、供销关系稳定等基本条件，具体条件如下：
1、在我行开立基本结算账户，销售收入归行率在50%以上。
2、无不良记录。
3、销售收入连续稳定。
4、有稳定的销售网络，销售渠道。
5、仓储公司与授信客户应是没有关联关系、相互独立、规模较大、管理正规、资信良好、拥有合法营业执照专业仓储法人企业。
（五）非标准仓单质押业务申请人申请非标准仓单质押业务时，除应符合我行流动资金贷款条件外，应同时向我行提供以下信息和资料：
1、仓储货物相应的购销合同及贸易背景情况。
2、仓储货物的市场行情与变现能力情况。
3、货物质量、数量与仓单、质检单，货物价值与质押率。
4、仓储公司的基本状况、资信状况、代位清偿能力；
（六）办理非标准仓单质押业务的出口信用证应满足以下条件：
1、商业银行是仓单项下的货物质押权人。
2、为明确各方的权利与义务，授信客户、仓储公司须与银行签订《仓储质押监管协议》。
3、银行工作人员须对照仓单亲自对质押货物进行清点，根据客户出具的《过户声明书》办理过户手续，并向仓储公司预留《质押物提货通知书》及有权签字样本。
4、质押货物应进行保险。
（七）非标准仓单质押业务额度、期限
1、非标准仓单质押业务金额授信金额不能超过保险金额的80%。
2、非标准仓单质押业务根据业务属于授信确定期限。
（八）非标准仓单质押业务发放
在借贷双方办理非标准仓单质押业务前要及时办妥授信发放手续。属于担保授信的，签订担保合同；需依法办理抵押、质押登记的要办理抵质押登记，并签订借款合同或有关协议，然后银行对企业实施授信，企业按合同约定使用授信额度。
（九）非标准仓单质押业务的还款
工业以太网非实时通信带宽的测量 篇5
关键词：调度,非实时带宽,瓶颈带宽
工业以太网EPA (Ethernet for Plant Automation) 为了满足通信的确定性, 采用的措施之一就是对处于同一微网段的设备通信进行确定性调度, 将网络中传输的数据分为实时数据和非实时数据, 即周期信息和非周期信息, 所有EPA设备的通信均按周期进行[1]。不同的应用需求对控制网络中这两类数据传输的带宽有不同的要求, 由此在工业以太网实时性性能测试标准中引入了非实时通信带宽这个测试指标。
工业以太网非实时通信带宽的测量, 就是看实际的测量结果是否满足某一应用对控制网络的需求, 同时它可以帮助网络管理人员了解整个网络的状态, 及时发现网络的瓶颈所在, 更重要的是可以给网络设计人员, 特别是网络协议的开发人员提供指导。带宽测量分为链路带宽测量、瓶颈带宽测量和剩余带宽测量[2], 这里的带宽测量属于瓶颈带宽测量。许多网络协议和应用需要知道瓶颈带宽以判断协议和应用的效率。
1 工业以太网的确定性和实时性
1.1 通信确定性与实时性
以太网由于采用CSMA/CD (载波侦听多路访问/冲突检测) 介质访问控制机制, 因此具有通信“不确定性”的特点, 不能满足工业应用中通信的实时性, 成为其应用于工业数据通信网络的主要障碍[3]。EPA是实时以太网的一种, 是应用于工业现场设备间通信的开放网络技术, 采用分段化系统结构和确定性通信调度控制策略, 能够适应工业现场特殊需要, 解决了以太网通信的不确定性的问题, 满足了系统的实时性要求。
1.2 确定性调度及时间同步
EPA系统中通讯调度规程处于协议栈链路层, 该规程规定在一个EPA子网段内, 所有EPA设备的时间均应同步, EPA设备的通信均按周期进行, 完成一个通信周期所需的时间T称为一个通信宏周期[4]。一个通信宏周期T分为2个阶段, 其中第1个阶段为周期报文传输阶段Tp, 第2个阶段为非周期报文传输阶段Tn, 如图1所示。
在周期报文传输阶段Tp, 每个EPA设备向网络上发送的报文是包含周期数据的报文。如需要按控制回路的控制周期传输的测量值、控制值或功能块输入、输出之间需要按周期更新数据。在非周期报文传输阶段Tn, 每个EPA设备向网络上发送的报文是包含非周期数据的报文。如程序的上下载数据、变量读写数据、事件通知、趋势报告等数据, 以及诸如ARP、RARP、HTTP、FTP、TFTP、ICMP、IGMP等应用数据。通过划分周期和非周期传输阶段, 网络保证了重要的实时数据有充足的时间进行发送。
1.3 调度组态
EPA组态软件是应用于EPA分布式控制网络的监控软件, 组态软件在自动监控系统中起着重要的作用[5]。EPA组态软件可以对参与调度的设备的相关参数进行设置, 也即设置总的通信宏周期、非实时通信时间和某一设备的周期发包起始时刻及相应的时间片。
2 非实时通信带宽的测试方法
2.1 非实时通信带宽
非实时通信带宽 (Non-RTE bandwidth) :指一条链路上, 能够用于传输非实时信息的带宽占总的带宽的百分比, 测试是需要给出总的链路带宽[6]。
根据前面对工业以太网通信确定性和实时性的介绍可知, 用于传输非实时信息的带宽占总的带宽的百分比即等于用于传输非实时数据的时间占总的数据传输时间的比值。而整个工业以太网的数据通信是按固定的通信周期T来进行的, 在一个周期内非周期数据通信的时间为Tn, 则非实时通信带宽B为
但测量中真正要解决的问题是总的带宽的测量, 也就是定义中提到的那个总的链路带宽。至于比值可以从组态软件中直接读出, 也可以测量得到, 但考虑到当以时间片的形式来组态设备时这一值不可精确测量, 故以从组态软件中读出这一值为依据。非实时通信带宽的测量就以链路的瓶颈带宽和组态软件设置好的时间比值为主要参考, 一般习惯把百分比的形式换算成实际的带宽值的形式, 便于分析比较。
2.2 非实时通信带宽的测量方法
结合实际的技术条件和测试对象, 提出了一种改进了的网络带宽测试算法。这种算法简单易行, 避免了繁琐算法难以实施以及测试工具和条件要求苛刻的缺陷, 用到的测试方法是基于包组或包群的测试方法。
这种基于包群的测试方法所利用的工具仅仅需要两台PC机以及一个高效的网络数据开发包, 基本原理就是向网络上某一条链路在一段连续的时间内注入达到网卡线速的流量, 以完全占据一条链路, 排除干扰流量的影响。然后在这一股流量中除掉最开始和结尾的部分, 在中间位置在利用连续接收到n个大小为p的数据包的时间差Δt求解网络上一条链路的瓶颈带宽b。
这种方法的可行之处在于工业以太网中的设备为嵌入式的, 考虑到其上运行的操作系统及协议栈, 其发包能力原不如PC。实际测量中PC上用的网络数据开发包为Winpcap, 由于和操作系统核心和网卡驱动结合紧密, 在小一段时间内 (1 ms以内) , 利用其缓存发包机制, 可以不受操作系统调度影响, 使网卡的发包速率达到极限。测量中之所以用到n个数据包而不是2个主要是考虑到测量工具开发包WinPcap自身在打印时间戳上会存在误差。
3 非实时通信带宽的测量实现
3.1 测量模型
本测试采用主动测量的方式, 控制台PC向测试代理PC发送包含测试开始、参数设置和终止信息的报文, 测试代理PC根据收到报文的不同而执行不同的操作。整个测试流程由控制台PC控制, 它同时负责测设代理PC发送给它的数据流的接收、处理和结果的显示, 测试软件运行于前台。测试代理PC上的软件运行于后台, 以提高数据发送的效率。
3.2 软件实现流程图
测试中控制台PC上的软件和测试代理PC上的软件的运行流程图, 如图3所示, 图中忽略了一部分细节, 主要给出了大致的框架。控制台PC有两个线程, 一个是主界面线程, 一个是工作者线程。主界面线程负责测试流程控制、参数设置和数据结果显示, 工作者线程完成对数据流的高速处理, 并把处理结果提交给主界面线程。
3.3 软件运行及测试结果
测试软件的运行界面, 如图4所示, 从软件界面可以很直观地解释软件的大致框架和操作流程。测试时首先设置好相关参数再开始测量, 测试可以实时暂停或终止, 测试参数可以实时的更改, 操作很是方便。测试代理的发现由控制台PC广播一规定好格式的报文来实现, 当收到这一报文后, 代理PC会将相关的信息发送给控制台PC, 以后两个PC间的通讯就可以不用广播的形式了。
实际测量中测试结果依不同的链路而不同, 上述测试结果反映的是某一条链路上只有一个交换机的情况。从图4中可以看到, 非实时通信带宽随着帧长的变化而变化, 这主要是由于网络互联设备是基于存储转发的, 不同帧长的数据流在链路的利用率上不同所致。也就是帧与帧之间会有一个时间间隔, 这一间隔随着帧长的增加而增加, 但由于存储转发, 作为一个帧所消耗的时间比帧长这一因素更大, 所以帧长较小的就没有充分的利用链路资源。
4 结束语
考虑到网络带宽的测量已经很成熟, 有很多种测量方法, 尽管没有一种绝对完善和精确的方法 [5,6,7,8]。文中重点不在网络带宽测量方法的突破上, 而在于根据工业以太网自身的特殊性, 重点介绍其测量的背景和测试方法的选择与改进。文中给出了非实时通信带宽的定义, 介绍了与之联系密切的确定性、实时性、通信调度、组态和测量用到的开发包Winpcap, 研究了非实时通信带宽的测量方法, 最后给出了测量模型、流程图、软件测试界面及结果。事实证明这种测量方法是可行的, 结果令人满意。
参考文献
[1]缪学勤.论六种实时以太网的通信协议[J].自动化仪表, 2005, 26 (4) :1-6.
[2]陈中林, 牛志升, 金跃辉, 等.网络限速条件下的瓶颈带宽测量新方法[J].计算机应用与软件, 2006, 23 (5) :99-101.
[3]宋亚亮, 王平, 范生凯.EPA通信协议栈设计中的关键技术研究[J].微计算机信息, 2008 (2) :39-40, 19.
[4]孙攀, 王平, 谢昊飞.以太网工厂自动化协议中确定性调度的研究与实现[J].计算机集成制造系统, 2007, 13 (3) :563-567.
[5]冯小华, 王彦邦.工业以太网EPA实时性能测试中递交时间的确定[J].电子科技, 2008, 21 (9) :54-58.
[6]楼正华.基于EPA的电机控制系统的开发[J].计算机网络, 2008 (4) :157-159.
[7]IEC.IEC61784-2:Digital Data Communications for Measurement and Control-Part2:Additional Profiles for ISO/IEC8802-3Based Communication Networks in Re-al-time Applications[S].USA:IEC, 2005.
电视实时路况视频业务及技术实现 篇6
数字视频技术在过去十年中获得了广泛应用, 数字视频广播、数字视频光盘、数码摄像机、远程教学、在线点播和视频会议等就是一些典型的例子。这些应用得以实现的关键就是数字视频压缩标准的制定, 它使得视频在获得了极高压缩比的同时又满足了人们对视频质量的要求[1]。
开展以电视机为接收终端, 向数字电视用户提供多路实时路况视频点播等电视交通导航服务的新业务研究与实现, 形成电视交通导航服务的业务体系、运营体系及相关技术支撑体系, 能够服务于广大电视用户, 带动信息内容产业、网络运营业、设备制造业等产业的发展。
1 基于电视平台的路况视频业务技术要求
基于电视平台的路况视频业务系统, 服务器端的系统主要由信息采集转码处理子系统、路况视频点播子系统、路况信息查询子系统及内容审查子系统等部分组成, 如图1所示。
用户使用实时路况视频业务要求在南方传媒所提供的双向机顶盒上展示前端信息以及所点播的交通视频内容。终端上交互工具是按键式遥控器。也就是说用户使用本系统, 最终是通过机顶盒和电视机作为业务终端。用户对系统操作的技术要求包括:
需要支持路况视频和其他路况信息关联使用。
需要支持实时的路况视频点播的功能 (整体延迟<3s) 。
需要支持选择多路视频同时点播的功能。
为了适应机顶盒的解码格式, 要求采用MPEG-2视频格式。
用户通过机顶盒和电视请求交通视频的应用场景如图2所示。
2 电视路况视频系统的技术实现
实现可运行的电视路况视频系统, 涉及到三方面的关键技术。其一是要在业务服务器上实现业务互动功能;其二是在视频服务器上实现视频格式转码以及多路视频合并功能;其三就是要实现DVB-C制式下的视频点播功能。
2.1 应用服务器技术
整个业务系统以应用服务器为核心, 由于南方传媒机顶盒支持基本的浏览器功能, 应用服务器软件采用典型的B/S模式的三层架构实现方式。B/S结构模式将系统架设在数据服务器、应用服务器、浏览器三个层次上, 数据服务器专门存放数据, 应用服务器提供各类服务组件来访问数据服务器和响应客户端的请求, 机顶盒上的浏览器端只显示结果和发出请求。这种模式的系统维护较为简单, 系统的修改和升级只需在应用服务器端进行即可。机顶盒上的浏览器软件相对计算机上的浏览器软件功能相对有限[2], 所以应用服务器软件要遵从机顶盒浏览器所支持的W3C规范, 如图3所示。
2.2 视频转码及合成技术
电视交通导航服务平台为电视机终端用户提供实时路况视频。在电视环境下, 要求支持四路视频同步播出。机顶盒的处理功能有限, 很难在机顶盒上对多路视频信号进行分屏显示。可行的技术方案是在视频服务器端, 对用户所选择的多路实时视频信号进行拼接处理, 整合为一路视频信号后下发到机顶盒再进行播放。
视频点播处理的功能模块采用实时视频流点播处理的方式。
从系统构成上看, 最终运行的系统之视频服务器应该是连接交通管理部门的交通管理视频服务器。本系统从交通管理部门获取的视频信号都是H.264格式。现在在电视服务平台上, 需要通过MPEG-2编码格式的TS视频流, 所以在视频服务器上需要实现高效率的转码。
在实现视频转码的同时, 本系统还要支持在用户选择查看多路的视频的情况下, 能够在视频服务器上实时完成多路视频合成为一路视频。这部分内容也是本文的技术重点。
H.264编码采用了基于宏块的视频压缩方法, H.264标准中的内部预测创造了一种从前面已编过码的一幅或多幅图像帧中预测新帧的模型。此模型是通过在参考帧中替换样本的方法做出来的 (运动补偿预测) 。其编码性能相对于MPEG-2有了大幅提高, 如图4所示。
由于H.264的编码效率更高, 现有参考文献很多都论述了从MPEG-2到H.264转码所涉及的优化方法和转换效率问题[3,4,5]。
MPEG-2的编码输入, 为H.264的解码输出的YUV数据。在多路视频合成的过程中, 需要对原始视频尺寸进行变换。
H.264解码过程在功能域有多个功能模块, 如运动补偿、帧间预测、帧内预测、反离散余弦变换、反量化、变长编码等。功能划分需要任务间的通信, 适合硬件实现, 数据流依次通过一组功能部件, 分别完成相应的计算, 但不太适合通用多处理器结构。而在数据域进行并行, 则有扩展性好, 易于软件实现的优点, 适合于通用的片上多处理器。本文在实现H.264解码过程中, 采用了数据域的并行加速。
MPEG-2编码采用帧间编码, H.264解码过程中保留的宏块关联信息可以加速的预测图像的比较, 计算出运动矢量, 由此运动矢量和参考帧生成原始图像的预测图像。而后, 将原始图像与预测像素差值所生成的差分图像数据进行DCT变换, 再经过量化器和比特流编码器生成输出的编码比特流。
2.3 视频点播技术
交通监控的视频格式兼容问题, 视频的转换问题, 视频点播处理的实时性能问题等。本项目需要确认交通视频的主要组成格式, 并确认通过视频转换的方式支持在南方传媒机顶盒上进行转换[6,7]。
目前的VOD系统的视频播出方案, 主要有两种方式, 一种是基于广电HFC网络广播方式下发视频信号的VOD, 另一种是基于IPTV模式点对点下发视频信号的VOD。本文采用基于广电HFC网络的VOD系统, 是面向传统广电网络架构的方案, 和原有的网络系统兼容。视频的下传采用HFC广播通道和DVB编码协议, 编码格式采用MPEG-2。其中IPQAM设备负责实现将视频流进行QAM调制和频率变换, 输出RF信号, 广播到用户对于的HFC网络中, 如图5所示。
我们对视频服务器点播功能的实现是基于D a r w i n S t r e a m i n gServer (简称DSS) 。DSS符合ISMA规范, 支持多种标准协议和格式。
每个DSS模块都必须提供一个Dispatch函数。Dispatch函数的格式如下所示:
void MyModuleDispatch (QTSS_Role inRole, QTSS_RoleParamPtr inParams) ;
在路况视频项目中, 我们对DSS进行了扩展, 以实现对MPEG-2 TS流的支持, 扩展实现RTSP协支持MPEG-2 TS流;并且使它能够通过UDP协议直接发送TS流。
使用扩展后的RTSP协议实现MPEG-2 TS流点播时, 与通常的RTSP交互过程相比, 在SETUP阶段有所不同。为了让RTSP协议能支持QAM传输, 需要对标准的RTSP协议做扩展, 即在SETUP阶段, 终端告诉服务器需要QAM传输, 服务器会为该终端分配传输资源, 并告诉终端相应的参数 (包括频点和节目号等) 。
为了实现MPEG-2 TS流通过Cable下发, 关键点是视频服务器能够采用UDP协议将TS流依特定速率发送到IPQAM设备。采用UDP协议把TS包发送到IPQAM设备, 实现相对比较简单, 假定TS包的大小是188字节的, 只要遵照一个UDP包不应大于以太网最大传输单元的原则, 将7个TS包打包成一个UDP包, 发送给IPQAM设备即可实现。
3 电视路况视频系统的性能测试
针对上述设计, 整个系统的性能消耗最关键的环节是视频转码和合成部分。我们对视频服务器的视频转码和合成部分进行了相关性能测试。
本文以惠普ML330 G6为测试平台, 对标准的测试序列进了转码和多路视频合成, 服务器的配置为双核至强2.26CPU, 4G内存, 250G硬盘。不同转码及视频合并的延时情况测试结果如表1所示。
在高清视频头的情况下, 视频转换和合成所需要的时间延迟明显大于标清情况。目前部署的视频摄像头, 还是以640×480分辨率的标清摄像头为主。
并且测试了通过IPQAM进行视频点播的功能。视频点播业务处理的时间延迟约为1s。图6是对四路视频进行合并后, 通过机顶盒在电视机上的显示效果。
测试结果显示, 本文所提出的技术实现方案, 能够很好满足实时路况视频业务需求。
4 结束语
电视实时路况视频业务能够通过电视平台为老百姓提供有效出行服务。本文重点研究了基于电视视频点播平台实现多路交通视频点播的技术难点, 针对难以在机顶盒终端上进行多路视频合成的问题, 设计了一种在服务器端快速实现视频转码和合成的算法, 该算法具有较低的复杂度和较短的时间消耗, 能够满足路况视频业务的实时性要求。本文提出的视频转码机制与视频点播方法计划应用于实际运营的系统中。
参考文献
[1]孟蕾.双向机顶盒的特色增值业务应用[J].有线电视技术, 2008.
[2]杨超.数字电视嵌入式浏览器的研究与实现.电子科技大学, 2005.
[3]肖友能, 薛向阳, 曾玮.视频转码技术回顾[J].通信学报, Vol 23, No.8, Aug.2002.
[4]柳羽中, 严肃, 陈启美.低复杂度的MPEG-2到H.264快速转码算法[J].计算机工程与应用, 2009, 45 (4) .
[5]LEI Zhi jun.Video transcoding techniques for wireless video communications[D].Ottawa:University of Ottawa, 2004.
[6]POON W F, LOK T, FENG J.Provision of continuous VCR functions in interactive broadcast VoD systems[J].IEEE Transition Broadcasting, 2005, 51 (4) :460-472.
非实时业务 篇7
气象信息系统中,气象数据是其核心和基本的组成部分[1],也是气象信息系统提供服务的主要内容,实时气象数据库系统的建设变得日益重要。
运用电子计算机对各种观测或探测手段所获取的大气状态和现象的资料进行加工和管理称之为气象资料处(Meteorological Data Processing ,MDP)。按时效不同,可把气象资料分为实时资料和非实时资料两种[2]。实时资料处理要求迅速、及时,主要通过电子计算机程序控制,把从资料传输系统接收的资料进行识别、分类、质量检查和编集,再按需要送往各个终端或天气预报用的电子计算机系统。非实时资料常采取事后收集加工的方式,没有严格的时限要求,因而可以加工得更加完善。本文重点研究实时气象资料,它对天气预报、数值预报、气候预测,灾害预防等各项实时气象业务尤为重要。因此各种实时观测资料从通信系统进行收集后,必须得到有效的存储管理,并提供方便、快捷的共享服务。
传统的基于进程的单一线程的资料处理只是在获得单类(单个)资料之后进行操作,任务完后才能使进程响应其他资料处理和用户操作,不能同时综合处理多种实时资料。各类别的资料往往需要安装配置各自对应的处理软硬件系统。资料处理效率低且自动化、集成化不高,耗费大量的时间,占用较多的网络和数据库资源,设备利用率低,不能很好地满足气象数据实时采集与处理要求。
基于多线程技术的实时与非确定时气象资料处理系统能够同时执行多项任务、 实现数据并行处理、 减少后台过程和前台界面的相互影响,使多任务并行执行成为可能。通过研究多线程技术和实时气象资料的特性,针对实时气象资料的特性和资料采集处理性能要求和气象业务需求,提出依据不同的实时气象资料的特点分别采取实时和非确定时的分析处理策略,通过多线程编程技术实现。经过实例结果分析,该方法在处理时间上和CPU使用率上比传统方式有明显改进。
1 处理策略研究
1.1 总体结构
实时资料处理系统与气象通信系统、气象业务平台紧密耦合。实时气象资料一般通过气象部门专用网实时获取,气象数据要为气象业务平台提供支持。资料处理软件运行在处理平台上,通过气象部门内网从资料服务器获得源文件,分析处理完成之后存储到专有数据库中,为气象业务平台提供数据支持。业务平台依靠数据支持为气象部门内部提供专业的服务和产品支持,同时也可通过Internet向外网中的公众提供气象共享信息服务。总体结构如图1所示。
1.2 处理策略与流程
实时气象资料的处理策略在本系统中至关重要,它会影响整个系统的数据处理的性能。根据实时气象资料生成的属性将其分为确定时实时资料和非确定时实时资料。确定时实时资料指的是生成、发布时间一般比较固定的资料,而非确定时实时资料的生成、发布时间就相对随机,这两类资料本文采用不同的处理策略。
确定时间生成发布资料获取时间范围确定。例如自动站报文每隔6分钟生成一次,城市短时天气预报每日发布6时、11时、17时预报各一次。处理这类资料是在规定延迟时间内定时启动程序调用相应线程进行实时处理。
非确定时间生成发布资料的获取的时间比较随机。一般取决于地域、季节、气候等外界因素,资料生成无固定时刻,例如预警信息。在处理这类资料时,系统按照预先设置间隔时间扫描文件。扫描时若有新的待处理资料则主程序给相应的处理程序分配一个线程进行处理。这类资料的处理是在一个相对随机的时间进行,因此称非确定时处理。
采取这样的策略:首先,提高系统的可用性,可以通过设置系统中定时模块满足在资料发布业务时效性规程改变情况下不影响系统的使用;其次,优化了系统资源分配,省略了定时发布资料在不必要时间段内的文件扫描,对于非确定时发布资料可以根据地域、季节、气候等特点设定某些资料的扫描频率。处理策略流程如图2所示。
2 多线程优化
2.1 单一线程的进程
应用程序启动时操作系统为程序分配内存及其他资源,内存和资源的物理分离叫做进程,是程序在计算机上的一次执行活动[3]。线程是进程内部的一条可执行路径,是CPU调度的单位,是进程的一个执行单元。每个进程应至少有一个线程,即主线程。
2.2 多线程的进程
一个进程中可以包含若干个线程,它们可以利用进程所拥有的资源。由于线程比进程更小,基本上不拥有系统资源,故对它的调度所付出的开销就会小得多,能更高效地提高系统内多个程序间并发执行的程度,从而显著提高系统资源的利用率和吞吐量[4]。
一个应用程序可以创建多个线程,多个不同的执行流,并同时运行这些线程。线程机制使系统具有多任务功能,用户可以同时运行多个程序,且每个程序中又可同时运行多个线程[5],这样多个线程并发的在同一进程中。多线程并行效率模型如图3所示。
2.3 .NET下多线程实现
从本质上和结构来说,.NET是一个多线程的环境。CRL内置支持多线程应用,任何 .NET框架下的语言,包括Visual C#在内,实现多线程时不再需要使用Win32API,可直接使用系统类提供的对象和方法。在VS2005中实现多线程非常方便,System.Threading命名空间提供一些使得可以进行多线程编程的类和接口,可以直接使用它建立多线程应用程序。
System.Threading.Thread类是创建并控制线程,其定义了多种方法,其中用Thread. Start()、Thread.Stop()、Thread.Resume()、Thread.Abort()、 Thread. Suspend()、Thread.Join()等方法操纵线程,还可通过Thread.Sleep()、Thread.isAlive()、Thread。
IsBackground()等方法设置线程状态。
System.Threading.Thread.Priority枚举了线程的优先级别,从而决定了线程能够得到多少CPU时间。高优先级的线程通常会比一般优先级的线程得到更多的CPU时间,如果不止一个高优先级的线程,操作系统将在这些线程之间循环分配CPU时间。C#中线程优先级从高到低分为Highest、Above、Normal、Normal、BelowNormal、Lowest 5级[6,7,8]。
3 气象资料处理
资料处理系统定时实时处理测报月报表(A报、B报)、SP和DG、城镇预报、短时天气预报这几类测报和预报产品,非确定时间实时处理预警信号、台风、自动站实时报文这几类测报产品。一般情况下,创建少数几个关键线程,用它来解决某个特定的问题[9] 。本系统创建了9个数据处理子线程,当程序启动时读取ini文件,完成数据库连接设置,定时初始化,资料扫描路径等初始化设置后,创建相应子程序线程。多线程处理流程如图4所示,具体步骤为:(1)应用程序启动后,读取INI初始化,如需更改设置,可在程序运行过程中更改设置,改变的信息写入INI。(2)初始化完毕后,系统创建资料处理线程。(3)线程进入while循环,确定时处理进入休眠—等待状态,非确定时处理线程扫描INI路径下文件进入间隔扫描—休眠状态。 (4)定时唤醒实时处理线程,扫描INI路径下文件。(5)有新文件,分别进入各自处理函数、分析解析文件、处理入库,更新日志,修改已处理文件名。(6)如无新文件,进入历史文件操作函数,处理符合条件的历史文件。(7)程序重复上述工作。(8)终止线程,程序结束。
4 实例与结果分析
气象资料种类繁多,资料格式复杂程度、数据量大小、处理精度差异很大。该系统处理的9类实时气象资料中,采取定时实时处理的几种报文结构复杂,资料处理占用时间和空间资源大,在实际业务中对系统的性能要求较高,特别是实时资料处理的时效性和专有处理设备的利用率两个指标比较重要,以下实例验证分别对这两个关键指标性能进行分析。
试验环境为: Windows XP Professional SP3,.NET Framework 2.0,CPU为Inter(R)Core(TM)2 Duo CPU E7400,内存3.5G,SuSe11企业版+Oracle10g IBM X3800 8866-1RC专用数据库服务器,100M局域网。
4.1 时间效率分析
随机选取某地区同一个站点A报、B报和城镇天气预报报文6个月的资料进行测试分析如表1所示。
该系统采用的多线程并行处理运行时间效率与传统的采用基于进程的单一线程处理对比如图5所示。可以看出:(1)对同一组资料处理,该方法较传统方式节省时间。(2)随着数据量的增加,数据量越大,该方法在时间效率性能越好。
4.2 CPU使用率分析
一个进程的所有线程可同时执行,Win32自动在一个进程的多个线程间进行切换。Windows操作系统能将可利用的 CPU时间分配给当前进程的各个线程[10]。使用同一组待处理数据资料,在进程启动之后100秒内,记录该进程在Windows任务管理器中CPU使用率的90次变化数据。将文中多线程
技术并行处理A报,B报和城镇预报与传统的基于进程的单一线程分别处理A报,B报和城镇预报时CPU使用效率作对比,如图6所示。可以看出:采用多文中方法后,CPU的使用效率有了显著提高。
5 结束语
气象资料的处理在气象业务信息化进程中十分重要,本文提出并实现的基于多线程技术的实时和非确定时气象资料处理比传统采用单一线程的进程处理具有较好的时间效率和CPU的利用率。产品已推广到地市一级的气象业务单位,有效地提高了业务过程的自动化、集成化分析处理性能,改善了业务流程的信息化水平,特别是在处理海量历史数据时性能更优。文中提出的针对实时资料生成特点采取定时实时处理或非确定时处理的策略,对其他行业海量实时数据的处理也具有参考和借鉴作用。
参考文献
[1]赵芳.气象数据库系统的建设[C].信息技术在气象领域应用开发,2006:191.
[2]刘旭,祖雪梅.对气象信息化资料重要性的探析[J].林业勘查设计,2010,3:29-30.
[3]Tobin Titus,Fabio Claudi Ferracchiati,Tejaswi Redkar,et al.C#Threading Handbook[M].New York:Apress,2004:3-13.
[4]Josepb Albabari,Ben Albabari.C#4.0IN A NUTSHELL The De-finitive Reference[M].Sebastopol:O'Reilly Media,Inc,2010:873-878.
[5]张能立,张彬.谈谈在.Net下的多线程编程[J].中国水运:理论版,2006,4(3):104-105.
[6]卜春芬.C#后台处理与多线程技术的应用[J].昆明学院学报,2010,32(3):82-85.
[7]欧阳志鹏,沈富可.基于改进线程池技术服务器程序的设计与实[J].计算机与数字工程,2005,33(10):133-135.
[8]Christian Nagel,Bill Evjen,Jay Glynn,等.C#高级编程[M].李铭,译.北京:清华大学出版社,2008:483-489.
[9]郭辉.多线程效率[J].计算机应用,2008,28(12):143.
非实时业务 篇8
面对电力系统分组化进程的加快,分组传送网(Packet Transport Network,PTN)以其面向连接的优势、统计复用的特点,得到了业界的广泛认可[1]。在电力系统中,继电保护和安全稳定控制等实时业务通常采用时分复用(Time Division Multiplexing,TDM)技术来构建传输通道,因此这类业务也称TDM业务。针对电力系统中PTN技术的应用研究包括:PTN承载TDM业务的传输时延研究[2,3];PTN承载TDM业务的时间同步测试和同步技术分析[4,5];PTN对保护倒换的支持能力[6,7]。
从前期的研究工作可以看出,PTN承载TDM业务的应用仍处于试验阶段,各方面的研究尚处于起步阶段。当前的研究成果没有对PTN承载电力系统实时性业务的关键问题做出系统描述。本文从业务时延、时间同步和保护倒换三个方面详细分析了电力系统应用PTN技术承载实时通信业务所需关注的问题,研究成果对实际工程具有参考价值。
1 TDM与PTN
1.1 PTN承载TDM原理
根据标准,TDM电路仿真分为结构化和非结构化两种类型[8]。电力通信PTN普遍采用后者,即SATo P(Structure Agnostic TDM over Packet)方式。这种类型的电路仿真不识别TDM帧内部结构,能够对数据净荷和同步定时信息进行透传,从而简化了繁复的信令识别过程。在SATo P方式下,网络源边缘路由器将TDM流切割成一定长度的数据帧,多个数据帧被封装成给定长度的分组,加上特殊的分组头部后发送到伪线(Pseudo-Wire,PW)上进行传输。穿越相应的PTN路径后,TDM分组在宿边缘路由器进行解封装和重建数据的过程。
1.2 PTN承载电力TDM业务的优势
传统的同步数字体系(Synchronous Digital Hierarchy,SDH)具备时延稳定、良好的横向兼容性、较强的自愈保护能力等优势,依然是当前电力继保系统的首选技术。但是,面对未来智能电网多业务、高带宽的需求,其容量小、信道时隙固定、带宽利用率低等缺点愈发明显。比较而言,PTN在承载电力TDM业务方面具有如下优势:
(1)10 GE/GE大带宽长距离传送,能够同时满足县调、地调和骨干网的需求,TDM业务的可达范围更广。
(2)TDM分组与数据分组统一调度,在保证业务质量的同时,提升了带宽利用率。
(3)PTN具有强大的操作、管理、维护(Operation Administration and Maintenance,OAM)机制。网络工作者可以通过网管系统实时监控TDM分组性能。例如,丢包监测、时延及抖动测量等。
(4)层次化、图形化的业务性能监测界面,使故障定位和诊断反应时间更加迅速。
2 业务时延
2.1 TDM业务重要性
在电力系统中,光纤通道传输继电保护信息主要采用的方式为线路纵联电流差动保护,简称“线路纵差保护”。该保护方式通过计算通信通道被保护线路各侧的电流差值来判别区内外故障,因此需要保证线路两侧电气量信息采集的同步,并满足一定的实时性和灵敏性。国内电力行业对继电保护信号的相关性能做了严格要求,传输纵联保护信息的数字式通道传输时间应不大于12 ms;点对点的数字式通道传输时间应不大于5 ms[9];用于继电保护的通信通道单向时延应不大于10 ms,且双向时延必须对称[10,11]。
2.2 单向时延
通常情况下,单向时延也称端到端时延,指业务从网络一端出发,穿越核心网到达另一端所产生的总延迟时间。在PTN网络中,TDM业务的端到端时延由源边缘路由器时延DS、链路时延DP、核心路由器时延DM和宿边缘路由器时延DT四部分组成,具体分析如下。
源边缘路由器时延DS包括数据帧等待封装的时间和源端用户转换侧时延DC。PTN采用了先到先服务非抢占式的队列调度机制,数据帧等待封装的时间可以表示为(N-i+1)·125 us。其中,i取正整数,N为数据帧封装个数,1个TDM帧在直连电路上的传输时间为125 us。
DP也称传播时延,指信号经光纤链路传输所产生的时延,一般为4.93 us/km。若传输距离为L,则DP取值为4.93L。
核心路由器时延DM包括路由器对分组的处理时延和排队时延两部分,如式(1)所示:
式中,RP为核心路由器转发速率,一般取1 GE或10 GE;TM(j)表示第M个节点的排队时延,该部分具有随机性。TDM业务帧按照以太网帧的封装格式,其头部共有46个字节,分别是26个字节的以太网头、12个字节的内外层标签和控制字以及8个可选字节,所以TDM分组尺寸为46+32N字节。
宿边缘路由器时延DT由分组等待解封装时延、抖动缓存时延和宿端用户转换侧时延DC组成。分组解封装时延可以表示为(i-1)·125 us,i取正整数;抖动缓存时延取抖动缓存阈值的一半。详细总结如表1所示。
2.3 随机时延
由表1可知,在标签交换路径确定的情况下,DS、DP和DT均可视为固定值,它们对TDM信号影响程度较小。随机时延分量TM(j)具有不确定性,是影响TDM信号同步精度的主要因素,也是PTN承载TDM业务时延问题的研究关键点。TM(j)由队列调度随机时延和泊松到达随机时延两部分组成。
图1显示了队列调度随机时延的产生原理。
在图1中,情景1表示TDM分组在t0时刻到达节点,此时节点内无其他分组占用缓冲区,TDM分组无需等待即可被转发,队列调度时延为0。情景2表示当TDM分组到达时,节点正在转发以太网分组或者前一时刻的TDM分组。当前的TDM分组必须等待缓冲区中前n-1个分组调度完毕后方可被转发,而这n-1个分组长度又各不相同。因此,缓冲区内队列长度的未知性导致了队列调度时延的随机性。
另一方面,TDM分组经过PTN网络设备的转发,其到达过程可近似等效为泊松分布[12],这种分布具有随机性。不同封装尺寸的TDM分组具有不同的泊松到达率。对于N的选择,可以通过数值仿真进行分析。
综上所述,TDM业务在电力通信网中占有重要的地位,在关注PTN数据通道时,必须充分考虑TDM业务的随机时延特性。
3 时间同步
电力系统纵差保护的时间同步方式分为全球定位系统GPS和线路往返时间测量两种类型。传统的SDH网络普遍采用GPS,该方式具有授时精度高、无需通道连接等特点。但是,电网故障分析要求各微机装置的时间信息不大于1 ms,相位测量和行波保护对时间精度的要求高达us级[13]。GPS在卫星失锁时,其误差可能达到几十甚至上百毫秒;另一方面,GPS采用微波传送时钟信号,容易受到天气、地形因素的干扰,一旦时钟信号中断,将给电网安全稳定运行带来严重后果。
出于以上考虑,PTN网络采用全新模式的1588v2时间同步技术,也称内同步。该模式不依赖外部时间设备,仅靠源宿两端互传带有时间信息(时间戳)的报文来计算同步时间差,进而通过该时间差调整电流值的时间偏移量。对于电路仿真业务,PTN需提供TDM业务时钟的透明传输,并保证收发两端业务时钟具有相同的、长期的频率准确度[1]。
在网络各节点处,封装有同步信息的报文会受到其它类型报文挤占服务器的影响,造成业务时钟和参考时钟不一致。针对这一问题,PTN采用自适应法来恢复定时。该方法通过统计TDM分组到达的时间间隔,动态调整宿端缓冲区尺寸。常用的时间间隔分布为负指数分布,这种分布可以利用排队论的方法进行分析,并通过计算队列长度来确定缓冲区尺寸。然而,负指数分布只是一种特例,业务到达时间间隔存在一般性,这会使分析难度大大增加。
4 保护倒换
从工作路径切换到保护路径,或者从主用设备切换到备用设备的过程称为保护倒换,它是保障电力系统可靠性的关键技术。为了保证业务的实时性,继电保护系统通常采用1+1和1∶1两种保护倒换方式。
在1+1保护倒换方式下,TDM业务采用源端双发和宿端选收的机制。当工作通道故障时,保护通道依然可以继续工作,从而保证了业务的连续性。这种机制虽然增加了额外的线路成本,但有效提升了线路可靠性。图2显示了1+1路径保护倒换原理。RA、RB表示纵差保护设备;PE为源、宿端路由器,它们是TDM分组的起始与终止节点;LSRn为PTN的中心节点。
在1∶1保护倒换方式下,TDM业务只在工作通道传送,此时的保护通道用来传送其他业务。一旦工作通道出现异常,保护通道立即停止当前传送任务,工作通道切换至保护通道,使得TDM业务得以继续传送。这种方式提高了通道利用率,但是在切换的过程中势必会造成TDM数据的丢失和延迟。图3显示了1∶1路径保护倒换原理。
文献[11]指出,传输继电保护信号的光纤通道保护倒换和恢复时间应小于50 ms。PTN能够实现50 ms的电信级保护倒换,并且支持1+1和1∶1两种方式。但是,TDM业务要求光纤通道双向路由的一致性,且支持双向倒换机制。这使得在配置标签交换路经时,必须考虑中心节点的承载能力和路径总节点数量。如果某中心节点出现拥塞,两种保护倒换方式均会失效。同样,如果节点数量过多,也会增大分组丢包的概率。所以,尽管PTN拥有良好的保护倒换机制,对于TDM业务的承载,仍然需要组网测试和网络仿真数据的支撑。
5 结束语
通过分析电力系统对TDM业务的要求以及PTN的原理,本文得出如下结论:
(1)PTN承载TDM业务存在随机时延,这种随机时延与中心节点入口侧队列长度有关。合理配置缓冲区长度和分组封装尺寸,能有效减低随机时延对TDM业务的影响程度。
(2)PTN1588v2时间同步技术在一定程度上提高了实时业务的可靠性,但是依然存在丢包和延迟的风险。通过调整缓冲区长度可以降低这种风险。
(3)PTN支持1+1和1∶1保护倒换机制。在实际应用中具体选择哪种方式,应综合考虑节点吞吐量和串联路径的节点数量。
非实时业务 篇9
数据库系统Lotus Notes,属于非关系数据库管理系统,是一种文档数据库,具有以下特点:
(1)基于文档组织模式。
(2)使用非结构化的数据元素。
(3)通过定时复制刷新数据。
(4)使用视图定位数据。
(5)通过全文检索访问数据。
关系数据库主要特征是支持关系数据模型(数据结构、关系操作、数据完整性)。关系模型具有以下特点:
(1)关系模型的概念单一,实体和实体之间的联系用关系来表示。
(2)以关系数学为基础。
(3)数据的物理存储和存取路径对用户不透明。
(4)关系数据库语言是非过程化的。
在实际工作中,二者各有所长。运用工作流机制、协同、通信、传递知识、进度、效率是办公信息系统的着重点,这也正是Lotus Notes数据库系统的优势所在,因此,Notes数据库是办公信息系统的首选。对大量原始数据进行多维汇总、处理加工、产生统计报表(产生原始文档)是管理信息系统的领域与专长,关系数据库能很好地满足这种需求。
随着文档一体化的发展,一般公文的归档管理都集成于办公信息系统中,因此部分档案信息数据以Lotus notes数据库形式存储。而对档案信息的全面管理必定要对数据的汇总、统计、处理,这部分工作涉及到的数据一般都是以关系数据库形式存储的。这时,将面临一个问题:有些数据既要参加数据流的运转,也要参加统计分析工作,两种数据库都需要这些数据。当然,采用数据的人工同步录入可以满足这一需求,但是增加了数据录入、校对工作量,这是不可取的,应选择科学、合理的方案,充分发挥计算机技术优势,自动同步Lotus Notes数据库与关系数据库。
2 解决方案
2.1 通过编程方法实现数据同步
用户通过同一个界面一次录入数据,通过软件将此数据同时写入Notes数据库和关系数据库中,并且控制两个操作同时成功,比如:操作1写入关系数据库,操作2写入Notes数据库,当操作以失败,写入事务回滚,同时取消操作1、2,反之亦然,只有操作1、操作2都成功时,才能成功地写入。操作1:利用Script写入关系数据库
经过以上操作,用户在录入界面输入的“全宗号”内容,同时写入了关系数据库和Notes数据库中,保证两个数据库中的内容一致。
2.2 利用Lotus内置的中间件DECS
DECS是Lotus公司开发的一种技术的名称,提供了一个从Domino应用到外部数据深层次集成、方便使用的、基于表单的接口。利用DECS,开发人员拥有了一个模板化的应用,使外部数据源变成Domino应用的一部分。
使用方法如下:
第一步:设置ODBC数据源。
第二步:调用DECS数据库。如果是第一次使用DECS,请查看服务器的DATA目录下是否有decsadm.nsf的数据库。如果有该数据库,请在服务器的控制台上输入Load DECS,如果没有该数据库,请在服务器的控制台上输入Load DECS,那么DECS任务会自动创建一个decsadm.nsf的数据库。
第三步:打开DECS数据库。任务启动后,打开服务器上的Decsadm.nsf数据库。
第四步:单击"Create Connection",创建一个连接。
第五步:打开连接表单,确认以下几项:
ODBC:连接的数据库
Data Source:数据源。
Username:能访问该数据源的用户名。
Password:能访问该数据源的用户密码。
Password encryption key:单击后对你填入的用户密码,在Notes中加密。
Selection Type:选择的类型是Table,还是View。
Owner:选择Table的拥有者。
Name:选择你要连接哪一个Table.
第六步:单击“Create Activity”,创建一个“动作”:系统提供了一个动作向导,单击“Create Activity”,系统打开表单后弹出一个动作向导,如果确定使用的话,单击“确定”,选择要导入到哪个Notes数据库;选择要导入到该数据库的哪个表单;选择使用哪个“连接”;选择到导入外部数据库的哪个Table和View。
第七步:确定NOTES数据库与关系数据库表之间的对应关系。
第八步:查看“Activities”导航,选定要激活哪个“动作”;单击“Start”,启动该动作。
2.3 选择LEI系列产品
LEI以前叫做NotesPump,是Domino与企业系统间工业级数据传输及同步的工具。它可以按照业务条件或业务需要,按计划或者一次性地完成数据的提取、转换、发布和同步。LEI实际上起的是一个中间服务器的作用,它使不同数据库通过它的connection及activity文档来实行数据交换,如图1。
使用方法:
(1)安装Domino/Notes Server、LEI?Server以及Notes客户端的安装,SQL Server2000的安装。
(2)在DOMINO中建立NOTES数据库,在SQL Server2000中建立同此Notes数据库具有相同域的数据库。
(3)配置两个“connection”用来连接数据库(一个连Notes,一个连SQL)。创建到Notes的连接直接点击“creat?connection”进行;建立与SQL的连接则需要在类型列表里选择“ODBC”,通过ODBC与SQL数据库连接。
(4)配置两个“activity”用来规定数据交换规则的,即两个数据库之间进行怎样的数据交换(一个是Notes到SQL,一个是SQL到Notes)。
以上配置通过后,在SQL的数据库里面分别进行数据的添加、删除、编辑,并分别用activity(dtns)进行数据交换,结果数据完全能保持一致。
3 比较
通过上面的讨论,对三种方案作一个简单的比较:
利用外部程序实现数据同步的方案,适用于需要同步的数据量比较少的小规模应用系统。它要求用户在系统分析阶段就要充分的考虑到可能选择的数据库系统,详细设计需要同步的数据项。这种方式开发的系统不需要额外的产品和复杂的配置,操作简单,但是系统开放性、可扩展性、可移植性比较差。
Domino Enterprise Connection Services(DECS),包含在Domino Server中,DECS提供了对企业数据的基于表单方式的实时访问,使这些数据看起来就象是Domino的内部数据一样,易于开发和维护。但是DECS支持同时连接的用户数量较少,其应用只能运行于Domino平台上,移植性差,并且需要Domino开发技术。
LEI全面支持企业系统,LEI支持与DB2/UDB、Oracle、Sybase、Microsoft SQL Server、ODBC、EDA/SQL、SAP R/3、J.D.Edwards OneWorld、PeopleSoft、Oracle Applications/Financials、Infinium、MQSeries及其他软件进行数据交换;快速应用开发,LEI的可视化映射界面支持以点击方式与Domino应用进行数据的传输及同步操作,不需要编程,实现对企业系统的高速访问;强大的企业级连通性,32位、多任务进程和多线程的执行方式增强了系统性能;提供了Lotus Domino应用与其他各类应用如ERP应用、交易处理(TP)系统、关系数据库之间的大规模数据发布。LEI作为独立产品,需要额外购买,并且安装、配置比较复杂,对管理人员要求比较高,对于小规模应用不是一种经济的选择。