全国高速公路电子不停车收费联网系统参与方间接口设计.doc
《全国高速公路电子不停车收费联网系统参与方间接口设计.doc》由会员分享,可在线阅读,更多相关《全国高速公路电子不停车收费联网系统参与方间接口设计.doc(89页珍藏版)》请在三一文库上搜索。
1、附件1全国高速公路电子不停车收费联网参与方间接口设计2014年5月目录一.概述11.1范围11.2参考资料1二.术语和定义、符号、缩略语12.1术语和定义12.1.1交易处理12.1.2参与方22.1.3清分方22.1.4本地清分方22.1.5国家级清分方22.1.6发行方22.1.7公路收费方22.1.8清分22.1.9清分日32.1.10清分目标日32.1.11结算32.1.12结算日32.1.13清算32.1.14收款方32.1.15付款方32.1.16消息42.2缩略语42.3XML符号及说明定义4三.体系结构53.1基本结构53.2角色转换6四.传输规则74.1传输方式74.2基本结
2、构74.2.1数据存储形式74.2.2数据结构定义84.2.3数据类型84.3消息头94.4消息体124.5消息文件的命名规则124.6传输控制134.6.1通用确认消息结构134.6.2通用重发请求消息结构154.6.3名单数据的版本控制164.7名单数据的有效期204.8参与方ID204.9卡ID及卡类型21五.交易处理215.1应用范围215.2确认消息结构225.2.1应用范围225.2.2消息头225.3原始交易消息225.3.1应用范围225.3.2消息头235.3.3消息内容245.3.4处理流程305.4记帐处理消息315.4.1应用范围315.4.2消息头315.4.3消息内
3、容325.4.4处理流程345.5争议交易处理消息355.5.1应用范围355.5.2消息头365.5.3消息内容375.5.4处理流程395.6异常交易退费消息405.6.1应用范围405.6.2消息头405.6.3消息内容415.6.4处理流程435.7交易处理过程435.8清分消息455.8.1应用范围455.8.2消息头465.8.3消息内容465.8.4处理流程505.9结算消息545.9.1应用范围545.9.2消息头555.9.3消息内容565.9.4处理流程585.10交易数据逻辑检查595.10.1与交易相关消息间的关系595.10.2检查原始交易和记帐处理615.10.3检
4、查清分结果615.10.4检查结算结果61六.用户状态及用户信息处理616.1用户状态名单消息626.1.1发送消息结构626.1.2确认消息结构656.1.3消息处理流程666.2请求重发状态名单消息666.2.1发送消息结构666.2.2确认消息结构676.3用户信息列表消息686.3.1发送消息结构686.3.2确认消息结构726.3.3消息处理流程726.3.4发行代理列表736.4请求重发用户信息列表消息736.4.1发送消息结构736.4.2确认消息结构74七.基础信息维护747.1服务类型消息747.1.1发送消息结构747.1.2确认消息结构777.2请求重发服务类型消息777
5、.2.1发送消息结构777.2.2确认消息结构777.3参与方信息消息787.3.1发送消息结构787.3.2确认消息结构827.3.3处理规则837.4请求重发参与方信息消息847.4.1发送消息结构847.4.2确认消息结构847.5消息处理流程84八.消息总结848.1消息列表858.2消息确认对应关系8685一. 概述1.1 范围本协议规定了收费公路联网结算管理中心(部中心)系统及各省(区、市)内电子收费系统中各参与方(如公路收费方、清分方和发行方)之间的数据传输接口及处理流程。部中心和各省(区、市)清分结算系统之间的数据交换需按本协议执行;各省(市)内参与方间的数据交换可以本协议为参
6、考自行设计。1.2 参考资料下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准,然而,鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件,其最新版本适用于本标准。 GB/T 206102006/ISO/TS 14904 :2002 道路运输与交通信息技术电子收费(EFC)参与方之间信息交互接口的规范高速公路区域联网不停车收费示范工程暂行技术要求中华人民共和国金融行业JR/T 0025-2005 中国金融集成电路(IC)卡规范中华人民共和国交通部收费公路联网收费技术要求2007
7、年10月版二. 术语和定义、符号、缩略语2.1 术语和定义2.1.1 交易处理 交易处理是公路收费交易从公路收费方到清分方,再到发行方的整个传输、记帐、争议处理、清分统计、结算划帐等各个过程的总和。 2.1.2 参与方参与到整个电子收费运营的单位或实体。2.1.3 清分方清分方又称清分服务方,负责在本系统多个发行方及公路收费方之间交换数据,包括交易信息及各种状态信息等。同时,协调各方完成电子收费业务,包括争议处理、清分及结算等。2.1.4 本地清分方本地清分方又称为本省(市)清分方,是负责该清分方所属省(市)内的交易进行清分的参与方。本地清分方直接与本省(市)内的发行方和公路收费方相连。2.1
8、.5 国家级清分方在全国负责对跨省(市)交易进行清分的参与方。国家级清分方仅直接与区域内各省(市)的清分方相连,不与各地的发行方和公路收费方直接相连。2.1.6 发行方发行方是负责将公路收费方提供的各种服务销售给用户的实体。2.1.7 公路收费方又称服务方,是直接为终端用户提供服务,并且通过服务获得商业收益的实体。具体到公路电子收费业务,服务方是向用户提供高速道路通行并收费通行费的实体。2.1.8 清分清分是清分方统计各参与方应收/付款金额并与相关参与方核对数据的操作,每日进行一次。即使清分当日无交易,也应按规则生成清分信息。国家级清分方负责对全国发生的跨省(市)交易进行清分,称为一级清分;本
9、地清分方负责对在本省(市)内产生的交易进行清分,称为二级清分。2.1.9 清分日 清分日是清分方执行清分业务的日期。2.1.10 清分目标日清分目标日是公路收费方希望交易规属的清分日期。清分方仅对清分目标日早于清分日的交易进行清分。2.1.11 结算结算是清分方按一定周期,根据每日清分结果统计各方应收/付款金额并发布划帐指令的操作。国家级清分方负责对全国发生的跨省(市)交易进行结算,称为一级结算;本地清分方负责对在本省(市)内产生的交易进行结算,称为二级结算。一级结算和二级结算的周期可以不同。2.1.12 结算日清分方执行结算业务的日期。2.1.13 清算清分与结算的统称。2.1.14 收款方
10、接收服务费的参与方,可以是清分方和公路收费方。由于收款方可能发生存在异常交易退费,所以在极端情况下收款金额可以为负数,表示净支付。2.1.15 付款方支付服务费的参与方,可以是清分方和发行方。由于收款方可能发生存在异常交易退费,向付款方返还部分服务费,所以在极端情况下付款金额可以为负数,表示付款方净收入。2.1.16 消息在电子收费系统中,在各参与方之间需经计算机系统收、发处理的各种数据信息的总称。2.2 缩略语本标准所用缩略语如下表。缩略语英文全称含义XMLeXtensible Markup Language一种简单的数据存储语言,使用一系列简单的标记描述数据。IDIdentity身份标识号
11、码,也叫帐号,是一个编码,具有唯一性。2.3 XML符号及说明定义本文中定义XML结构的Schema通过如下图形表示:所有XML节点定义均以方框套节名称定义,如上图中的RootElement及Item1到Item8。根据连接线可知各个节点的关系:Item1到Item8均为RootElement的子节点。如果一个节点必须出现且仅能出现一次,则其方框为实线,没有任何下标,如Item1到Item5。如果一个节点可以被省略,即其出现次数可以为0,则其方框为虚线,如Item6和Item7。Item6的虚框下无下标,说明Item6最多可以出现一次;Item7的虚框下有下标,指明其出现次数的上限(上图中定义
12、为无穷大)。Item8的下标说明其出现次数必须在4次到8次之间,否则不能通过XML合法性验证。两个图形说明子节点的出现规则。前者表示子节点按结构图从上到下的顺序出现。例如,RootElement的子节点必须按Item1、Item2、Item3的顺序出现,否则无法通过合法性验证。后者表示子节点的出现是选择关系。例如,Item3、Item4、Item5均为RootElement的子节点,但在任意一个XML文件中,只能出现这三者之一,不能同时出现。在说明中通过RootElement.Item1、RootElement.Item2的形式表示上下级节点之间的关系。三. 体系结构3.1 基本结构本体系结构
13、根据道路运输与交通信息技术电子收费(EFC)参与方之间信息交互接口的规范制定。联网电子收费体系结构为树型,在同一水平的两个参与方之间没有直接联系:l 省(市)清分方可以与本省(市)内的多个公路收费方和发行方相连。l 省(市)清分方通过区域清分方与其他省(市)清分方相连。l 本省(市)公路收费方与发行方通过本省(市)清分方相连。l 本省(市)公路收费方与发行方通过省(市)清分及区域清分方与其他省市的公路收费方与发行方相连。对于各省(市)的发行方和公路收费方而言,区域清分方和省(市)清分方组合在一起,成为系统清分结算的清分方,如下图:3.2 角色转换公路收费方是产生消息交易的参与方;发行方是从用户
14、帐户中按交易划拨服务费的参与方。由于省(市)清分方即向区域清分方提交其他地区用户在本省(市)产生的跨区交易,又为本省(市)用户在其他省(市)的跨区交易支付服务费,所以对区域清分方而言,各省(市)清分方即是公路收费方,又是发行方。因此,在后面对消息的说明中,除特别描述外,均以下图所示的简单结构阐述各消息的处理规则:四. 传输规则4.1 传输方式所有数据均通过中间件以文件方式传送。每个文件作为一个消息发送到接收方。接收方必须发送一个确认消息向发送方回应其接收消息的状态。4.2 基本结构4.2.1 数据存储形式所有传输的数据均采用XML存储,使用UTF-8编码,基本结构如下:所有消息,包括用于确认信
15、息的消息均使用以上基本结构。消息包含消息头Header和消息体Body。所有消息的消息头结构相同,仅使用的具体数值根据其不同应用有所区别。不同应用的消息体内部结构不同。Message节点作为整个消息文件的根节点,不得带有任何属性,如命名空间及SchemaLocation等,即消息必需为:.若未明确说明,所有整数类型的值均采用十进制,所有表示金额的节点均采用十进制并精确到分,如果123.45表示一百二十三元四角五分。所有数据结构以Schema形式定义。所有XML数据必需能够通过对应Schema的合法性验证。4.2.2 数据结构定义所有传输中的消息,均通过Schema定义文件结构。所有根据Sche
16、ma生成的XML文件,必需是合法的。Schema文件仅定义文件结构,不负责对数据的逻辑合法性进行验证。Schema定义中使用的标签名称(tag)与数据库定义使用的字段名没有必然关系。数据库定义时可以采用不同的名称表示Schema定义的内容。4.2.3 数据类型Schema中用于定义XML结构的部分数据类型说明见下表:XML数据类型说明示例Short2字节整数,以10进制表示Int4字节整数,以10进制表示Long8字节整数,以10进制表示Date日期YYYY-MM-DD,如2008-01-25DateTime时间,采用24小时表示法,以字符“T”作为日期与时间的分隔符,精确到秒 YYYY-MM
17、-DDTHH:mm:ss,如2008-01-25T15:33:46HexBinary在后文定义中简略为Hex(n),以16进制数字对的方式表示一串字节数组的内容,高位在前,低位在后。n为16进制数的位数,不足规定长度的,左补0。由于两位16进制数表示1个字节,所以,n必为偶数。如保存1字节内容为Hex(2),保存4字节内容为Hex(8)001a345f表示0x001a345f。若使用01a345f则在验证XML文件合法性时会产生错误,因为16进制数字串的长度是7,不是偶数长度。Decimal以10进制表示的浮点数如1340.56等String字符串,为表示长度,在后文定义时使用String(n
18、)进行表示。n为字符串最终存储的最大字节数。超过定义长度的部分将不被接收方处理。若省略n,表示不规定字符串长度。在消息定义中的BCD码通过HexBinary表示。本文中有关金额的单位,若未特别说明,均以“元”为单位。4.3 消息头消息头是所有消息均包含的第一个节点,表示消息的身份及用途,数据类型及意义如下:名称数据类型取值及说明VersionInt版本号,以10进制表示。从高到低前4位表示主版本号,中间3位表示次版本号,最后3位是修改号。如:1000000表示版本1.0.0MessageClassInt说明消息传输的机制MessageTypeInt说明消息的应用类型SenderIdHex(16
19、)发送方Id,在整个系统中唯一ReceiverIdHex(16)接收方Id,在整个系统中唯一MessageIdLong消息序号,从1开始递增,每次加1。消息序号由发送方维护。SenderId,ReceiverId及MessageId的组合,是一条消息在整个系统内的唯一身份标识。在一个消息从最初的发送方到最终接收方的传输过程中,Version、MessageClass和MessageType均不会改变。转发消息的参与方仅替换SenderId,ReceiverId及MessageId。例如,某公路收费方Id为1,其所在省(市)清分方Id为2,区域清分方Id为3,另一省(市)清分方Id为4,另一省(
20、市)的发行方Id为5,则公路收费方的交易消息包在逐级转发的过程中SenderId,ReceiverId和MessageId变化如下:传输阶段SenderIdReceiverId公路收费方到本省(市)清分方12本省(市)清分方到区域清分方23区域清分方到另一省(市)清分方34另一省(市)清分方到该省(市)发行方45在整个过程中,MessageId各个发送方自行控制。MessageClass以4字节整型表示。名称值说明请求Request1接收方需返回处理结果,可能包含大量数据请求应答Request Response2建议Advice3接收方需指明是否接受发送方的建议,返回信息简单建议应答Advic
21、e Response4通知Notification5接收方仅需指明接收是否正确通知应答Notification Response6MessageClass两两一组,每组中第一个值说明传输机制,该值加1即为第二个值,是对第一个值的确认操作。以上定义参考道路运输与交通信息技术电子收费(EFC)参与方之间信息交互接口的规范制定。以C#定义为:public enum MessageClassRequest = 1,RequestResponse,Advice,AdviceResponse,Notification,NotificationResponseMessageType以4字节整型表示。名称值服
22、务列表Servcie List1价目表Fare Products List2用户信息Customer Details3分账规则Apportionment Rules4对账总金额Reconciliation Totals5授权Authorization6交易Transaction7报告已发送Report Sent8密钥管理Key Management9状态名单Status List10设备状态Equipment Status11例外事件Event Exception12接受付费方式Payment Method Acceptance13参与方信息Operator List14区域联网保留15200
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 全国 高速公路 电子 停车 收费 联网 系统 参与 间接 设计
链接地址:https://www.31doc.com/p-2546997.html