全國高速公路電子不停車收費聯(lián)網(wǎng)系統(tǒng)參與方間接口設(shè)計

1、附件1全國高速公路電子不停車收費聯(lián)網(wǎng)參與方間接口設(shè)計2014年5月目錄一.概述11.1范圍11.2參考資料1二.術(shù)語和定義、符號、縮略語12.1術(shù)語和定義1交易處理1參與方2清分方2本地清分方2國家級清分方2發(fā)行方2公路收費方2清分2清分日3清分目標(biāo)日3結(jié)算3結(jié)算日3清算3收款方3付款方3消息42.2縮略語42.3XML符號及說明定義4三.體系結(jié)構(gòu)53.1基本結(jié)構(gòu)53.2角色轉(zhuǎn)換6四.傳輸規(guī)則74.1傳輸方式74.2基本結(jié)構(gòu)7數(shù)據(jù)存儲形式7數(shù)據(jù)結(jié)構(gòu)定義8數(shù)據(jù)類型84.3消息頭94.4消息體124.5消息文件的命名規(guī)則124.6傳輸控制13通用確認(rèn)消息結(jié)構(gòu)13通用重發(fā)請求消息結(jié)構(gòu)15名單數(shù)據(jù)的版

2、本控制164.7名單數(shù)據(jù)的有效期204.8參與方ID204.9卡ID及卡類型21五.交易處理215.1應(yīng)用范圍215.2確認(rèn)消息結(jié)構(gòu)22應(yīng)用范圍22消息頭225.3原始交易消息22應(yīng)用范圍22消息頭23消息內(nèi)容24處理流程305.4記帳處理消息31應(yīng)用范圍31消息頭31消息內(nèi)容32處理流程345.5爭議交易處理消息35應(yīng)用范圍35消息頭36消息內(nèi)容37處理流程395.6異常交易退費消息40應(yīng)用范圍40消息頭40消息內(nèi)容41處理流程435.7交易處理過程435.8清分消息45應(yīng)用范圍45消息頭46消息內(nèi)容46處理流程505.9結(jié)算消息54應(yīng)用范圍54消息頭55消息內(nèi)容56處理流程585.10交易

3、數(shù)據(jù)邏輯檢查59與交易相關(guān)消息間的關(guān)系59檢查原始交易和記帳處理61檢查清分結(jié)果61檢查結(jié)算結(jié)果61六.用戶狀態(tài)及用戶信息處理616.1用戶狀態(tài)名單消息62發(fā)送消息結(jié)構(gòu)62確認(rèn)消息結(jié)構(gòu)65消息處理流程666.2請求重發(fā)狀態(tài)名單消息66發(fā)送消息結(jié)構(gòu)66確認(rèn)消息結(jié)構(gòu)676.3用戶信息列表消息68發(fā)送消息結(jié)構(gòu)68確認(rèn)消息結(jié)構(gòu)72消息處理流程72發(fā)行代理列表736.4請求重發(fā)用戶信息列表消息73發(fā)送消息結(jié)構(gòu)73確認(rèn)消息結(jié)構(gòu)74七.基礎(chǔ)信息維護747.1服務(wù)類型消息74發(fā)送消息結(jié)構(gòu)74確認(rèn)消息結(jié)構(gòu)777.2請求重發(fā)服務(wù)類型消息77發(fā)送消息結(jié)構(gòu)77確認(rèn)消息結(jié)構(gòu)777.3參與方信息消息78發(fā)送消息結(jié)構(gòu)78確

4、認(rèn)消息結(jié)構(gòu)82處理規(guī)則837.4請求重發(fā)參與方信息消息84發(fā)送消息結(jié)構(gòu)84確認(rèn)消息結(jié)構(gòu)847.5消息處理流程84八.消息總結(jié)848.1消息列表858.2消息確認(rèn)對應(yīng)關(guān)系86一. 概述1.1 范圍本協(xié)議規(guī)定了收費公路聯(lián)網(wǎng)結(jié)算管理中心（部中心）系統(tǒng)及各?。▍^(qū)、市）內(nèi)電子收費系統(tǒng)中各參與方（如公路收費方、清分方和發(fā)行方）之間的數(shù)據(jù)傳輸接口及處理流程。部中心和各?。▍^(qū)、市）清分結(jié)算系統(tǒng)之間的數(shù)據(jù)交換需按本協(xié)議執(zhí)行；各?。ㄊ校﹥?nèi)參與方間的數(shù)據(jù)交換可以本協(xié)議為參考自行設(shè)計。1.2 參考資料下列文件中的條款通過本標(biāo)準(zhǔn)的引用而成為本標(biāo)準(zhǔn)的條款。凡是注日期的引用文件，其隨后所有的修改單（不包括勘誤的內(nèi)容）或修訂

5、版均不適用于本標(biāo)準(zhǔn)，然而，鼓勵根據(jù)本標(biāo)準(zhǔn)達成協(xié)議的各方研究是否可使用這些文件的最新版本。凡是不注日期的引用文件，其最新版本適用于本標(biāo)準(zhǔn)。 GB/T 206102006/ISO/TS 14904 ：2002 道路運輸與交通信息技術(shù)電子收費（EFC）參與方之間信息交互接口的規(guī)范高速公路區(qū)域聯(lián)網(wǎng)不停車收費示范工程暫行技術(shù)要求中華人民共和國金融行業(yè)JR/T 0025-2005 中國金融集成電路（IC）卡規(guī)范中華人民共和國交通部收費公路聯(lián)網(wǎng)收費技術(shù)要求2007年10月版二. 術(shù)語和定義、符號、縮略語2.1 術(shù)語和定義2.1.1 交易處理 交易處理是公路收費交易從公路收費方到清分方，再到發(fā)行方的整個傳輸、

6、記帳、爭議處理、清分統(tǒng)計、結(jié)算劃帳等各個過程的總和。 2.1.2 參與方參與到整個電子收費運營的單位或?qū)嶓w。2.1.3 清分方清分方又稱清分服務(wù)方，負(fù)責(zé)在本系統(tǒng)多個發(fā)行方及公路收費方之間交換數(shù)據(jù)，包括交易信息及各種狀態(tài)信息等。同時，協(xié)調(diào)各方完成電子收費業(yè)務(wù)，包括爭議處理、清分及結(jié)算等。2.1.4 本地清分方本地清分方又稱為本省（市）清分方，是負(fù)責(zé)該清分方所屬?。ㄊ校﹥?nèi)的交易進行清分的參與方。本地清分方直接與本?。ㄊ校﹥?nèi)的發(fā)行方和公路收費方相連。2.1.5 國家級清分方在全國負(fù)責(zé)對跨省（市）交易進行清分的參與方。國家級清分方僅直接與區(qū)域內(nèi)各?。ㄊ校┑那宸址较噙B，不與各地的發(fā)行方和公路收費方直接相

7、連。2.1.6 發(fā)行方發(fā)行方是負(fù)責(zé)將公路收費方提供的各種服務(wù)銷售給用戶的實體。2.1.7 公路收費方又稱服務(wù)方,是直接為終端用戶提供服務(wù)，并且通過服務(wù)獲得商業(yè)收益的實體。具體到公路電子收費業(yè)務(wù)，服務(wù)方是向用戶提供高速道路通行并收費通行費的實體。2.1.8 清分清分是清分方統(tǒng)計各參與方應(yīng)收/付款金額并與相關(guān)參與方核對數(shù)據(jù)的操作，每日進行一次。即使清分當(dāng)日無交易，也應(yīng)按規(guī)則生成清分信息。國家級清分方負(fù)責(zé)對全國發(fā)生的跨?。ㄊ校┙灰走M行清分，稱為一級清分；本地清分方負(fù)責(zé)對在本?。ㄊ校﹥?nèi)產(chǎn)生的交易進行清分，稱為二級清分。2.1.9 清分日 清分日是清分方執(zhí)行清分業(yè)務(wù)的日期。2.1.10 清分目標(biāo)日清分目

8、標(biāo)日是公路收費方希望交易規(guī)屬的清分日期。清分方僅對清分目標(biāo)日早于清分日的交易進行清分。2.1.11 結(jié)算結(jié)算是清分方按一定周期，根據(jù)每日清分結(jié)果統(tǒng)計各方應(yīng)收/付款金額并發(fā)布劃帳指令的操作。國家級清分方負(fù)責(zé)對全國發(fā)生的跨?。ㄊ校┙灰走M行結(jié)算，稱為一級結(jié)算；本地清分方負(fù)責(zé)對在本?。ㄊ校﹥?nèi)產(chǎn)生的交易進行結(jié)算，稱為二級結(jié)算。一級結(jié)算和二級結(jié)算的周期可以不同。2.1.12 結(jié)算日清分方執(zhí)行結(jié)算業(yè)務(wù)的日期。2.1.13 清算清分與結(jié)算的統(tǒng)稱。2.1.14 收款方接收服務(wù)費的參與方，可以是清分方和公路收費方。由于收款方可能發(fā)生存在異常交易退費，所以在極端情況下收款金額可以為負(fù)數(shù)，表示凈支付。2.1.15 付

9、款方支付服務(wù)費的參與方，可以是清分方和發(fā)行方。由于收款方可能發(fā)生存在異常交易退費，向付款方返還部分服務(wù)費，所以在極端情況下付款金額可以為負(fù)數(shù)，表示付款方凈收入。2.1.16 消息在電子收費系統(tǒng)中，在各參與方之間需經(jīng)計算機系統(tǒng)收、發(fā)處理的各種數(shù)據(jù)信息的總稱。2.2 縮略語本標(biāo)準(zhǔn)所用縮略語如下表。縮略語英文全稱含義XMLeXtensible Markup Language一種簡單的數(shù)據(jù)存儲語言，使用一系列簡單的標(biāo)記描述數(shù)據(jù)。IDIdentity身份標(biāo)識號碼，也叫帳號，是一個編碼，具有唯一性。2.3 XML符號及說明定義本文中定義XML結(jié)構(gòu)的Schema通過如下圖形表示：所有XML節(jié)點定義均以方框套

10、節(jié)名稱定義，如上圖中的RootElement及Item1到Item8。根據(jù)連接線可知各個節(jié)點的關(guān)系：Item1到Item8均為RootElement的子節(jié)點。如果一個節(jié)點必須出現(xiàn)且僅能出現(xiàn)一次，則其方框為實線，沒有任何下標(biāo)，如Item1到Item5。如果一個節(jié)點可以被省略，即其出現(xiàn)次數(shù)可以為0，則其方框為虛線，如Item6和Item7。Item6的虛框下無下標(biāo)，說明Item6最多可以出現(xiàn)一次；Item7的虛框下有下標(biāo)，指明其出現(xiàn)次數(shù)的上限（上圖中定義為無窮大）。Item8的下標(biāo)說明其出現(xiàn)次數(shù)必須在4次到8次之間，否則不能通過XML合法性驗證。兩個圖形說明子節(jié)點的出現(xiàn)規(guī)則。前者表示子節(jié)點按結(jié)構(gòu)圖

11、從上到下的順序出現(xiàn)。例如，RootElement的子節(jié)點必須按Item1、Item2、Item3的順序出現(xiàn)，否則無法通過合法性驗證。后者表示子節(jié)點的出現(xiàn)是選擇關(guān)系。例如，Item3、Item4、Item5均為RootElement的子節(jié)點，但在任意一個XML文件中，只能出現(xiàn)這三者之一，不能同時出現(xiàn)。在說明中通過RootElement.Item1、RootElement.Item2的形式表示上下級節(jié)點之間的關(guān)系。三. 體系結(jié)構(gòu)3.1 基本結(jié)構(gòu)本體系結(jié)構(gòu)根據(jù)道路運輸與交通信息技術(shù)電子收費（EFC）參與方之間信息交互接口的規(guī)范制定。聯(lián)網(wǎng)電子收費體系結(jié)構(gòu)為樹型，在同一水平的兩個參與方之間沒有直接聯(lián)系：

12、l ?。ㄊ校┣宸址娇梢耘c本?。ㄊ校﹥?nèi)的多個公路收費方和發(fā)行方相連。l ?。ㄊ校┣宸址酵ㄟ^區(qū)域清分方與其他?。ㄊ校┣宸址较噙B。l 本?。ㄊ校┕肥召M方與發(fā)行方通過本?。ㄊ校┣宸址较噙B。l 本?。ㄊ校┕肥召M方與發(fā)行方通過?。ㄊ校┣宸旨皡^(qū)域清分方與其他省市的公路收費方與發(fā)行方相連。對于各?。ㄊ校┑陌l(fā)行方和公路收費方而言，區(qū)域清分方和?。ㄊ校┣宸址浇M合在一起，成為系統(tǒng)清分結(jié)算的清分方，如下圖：3.2 角色轉(zhuǎn)換公路收費方是產(chǎn)生消息交易的參與方；發(fā)行方是從用戶帳戶中按交易劃撥服務(wù)費的參與方。由于?。ㄊ校┣宸址郊聪騾^(qū)域清分方提交其他地區(qū)用戶在本?。ㄊ校┊a(chǎn)生的跨區(qū)交易，又為本省（市）用戶在其他?。ㄊ校┑目鐓^(qū)

13、交易支付服務(wù)費，所以對區(qū)域清分方而言，各?。ㄊ校┣宸址郊词枪肥召M方，又是發(fā)行方。因此，在后面對消息的說明中，除特別描述外，均以下圖所示的簡單結(jié)構(gòu)闡述各消息的處理規(guī)則：四. 傳輸規(guī)則4.1 傳輸方式所有數(shù)據(jù)均通過中間件以文件方式傳送。每個文件作為一個消息發(fā)送到接收方。接收方必須發(fā)送一個確認(rèn)消息向發(fā)送方回應(yīng)其接收消息的狀態(tài)。4.2 基本結(jié)構(gòu)4.2.1 數(shù)據(jù)存儲形式所有傳輸?shù)臄?shù)據(jù)均采用XML存儲，使用UTF-8編碼，基本結(jié)構(gòu)如下：所有消息，包括用于確認(rèn)信息的消息均使用以上基本結(jié)構(gòu)。消息包含消息頭Header和消息體Body。所有消息的消息頭結(jié)構(gòu)相同，僅使用的具體數(shù)值根據(jù)其不同應(yīng)用有所區(qū)別。不同應(yīng)用

14、的消息體內(nèi)部結(jié)構(gòu)不同。Message節(jié)點作為整個消息文件的根節(jié)點，不得帶有任何屬性，如命名空間及SchemaLocation等，即消息必需為：<Message><Header>.</Header><Body>.</Body></Message>若未明確說明，所有整數(shù)類型的值均采用十進制，所有表示金額的節(jié)點均采用十進制并精確到分，如果123.45表示一百二十三元四角五分。所有數(shù)據(jù)結(jié)構(gòu)以Schema形式定義。所有XML數(shù)據(jù)必需能夠通過對應(yīng)Schema的合法性驗證。4.2.2 數(shù)據(jù)結(jié)構(gòu)定義所有傳輸中的消息，均通過Schema定義

15、文件結(jié)構(gòu)。所有根據(jù)Schema生成的XML文件，必需是合法的。Schema文件僅定義文件結(jié)構(gòu)，不負(fù)責(zé)對數(shù)據(jù)的邏輯合法性進行驗證。Schema定義中使用的標(biāo)簽名稱（tag）與數(shù)據(jù)庫定義使用的字段名沒有必然關(guān)系。數(shù)據(jù)庫定義時可以采用不同的名稱表示Schema定義的內(nèi)容。4.2.3 數(shù)據(jù)類型Schema中用于定義XML結(jié)構(gòu)的部分?jǐn)?shù)據(jù)類型說明見下表：XML數(shù)據(jù)類型說明示例Short2字節(jié)整數(shù)，以10進制表示Int4字節(jié)整數(shù)，以10進制表示Long8字節(jié)整數(shù)，以10進制表示Date日期YYYY-MM-DD，如2008-01-25DateTime時間，采用24小時表示法，以字符“T”作為日期與時間的分隔符

16、，精確到秒 YYYY-MM-DDTHH:mm:ss，如2008-01-25T15:33:46HexBinary在后文定義中簡略為Hex(n)，以16進制數(shù)字對的方式表示一串字節(jié)數(shù)組的內(nèi)容，高位在前，低位在后。n為16進制數(shù)的位數(shù)，不足規(guī)定長度的，左補0。由于兩位16進制數(shù)表示1個字節(jié)，所以，n必為偶數(shù)。如保存1字節(jié)內(nèi)容為Hex(2)，保存4字節(jié)內(nèi)容為Hex(8)001a345f表示0x001a345f。若使用01a345f則在驗證XML文件合法性時會產(chǎn)生錯誤，因為16進制數(shù)字串的長度是7，不是偶數(shù)長度。Decimal以10進制表示的浮點數(shù)如1340.56等String字符串，為表示長度，在后文

17、定義時使用String(n)進行表示。n為字符串最終存儲的最大字節(jié)數(shù)。超過定義長度的部分將不被接收方處理。若省略n，表示不規(guī)定字符串長度。在消息定義中的BCD碼通過HexBinary表示。本文中有關(guān)金額的單位，若未特別說明，均以“元”為單位。4.3 消息頭消息頭是所有消息均包含的第一個節(jié)點，表示消息的身份及用途，數(shù)據(jù)類型及意義如下：名稱數(shù)據(jù)類型取值及說明VersionInt版本號，以10進制表示。從高到低前4位表示主版本號，中間3位表示次版本號，最后3位是MessageClassInt說明消息傳輸?shù)臋C制MessageTypeInt說明消息的應(yīng)用類型SenderIdHex(16)發(fā)送方Id，在整

18、個系統(tǒng)中唯一ReceiverIdHex(16)接收方Id，在整個系統(tǒng)中唯一MessageIdLong消息序號，從1開始遞增，每次加1。消息序號由發(fā)送方維護。SenderId，ReceiverId及MessageId的組合，是一條消息在整個系統(tǒng)內(nèi)的唯一身份標(biāo)識。在一個消息從最初的發(fā)送方到最終接收方的傳輸過程中，Version、MessageClass和MessageType均不會改變。轉(zhuǎn)發(fā)消息的參與方僅替換SenderId，ReceiverId及MessageId。例如，某公路收費方Id為1，其所在?。ㄊ校┣宸址絀d為2，區(qū)域清分方Id為3，另一?。ㄊ校┣宸址絀d為4，另一?。ㄊ校┑陌l(fā)行方Id為

19、5，則公路收費方的交易消息包在逐級轉(zhuǎn)發(fā)的過程中SenderId，ReceiverId和MessageId變化如下：傳輸階段SenderIdReceiverId公路收費方到本省（市）清分方12本?。ㄊ校┣宸址降絽^(qū)域清分方23區(qū)域清分方到另一省（市）清分方34另一?。ㄊ校┣宸址降皆撌。ㄊ校┌l(fā)行方45在整個過程中，MessageId各個發(fā)送方自行控制。MessageClass以4字節(jié)整型表示。名稱值說明請求Request1接收方需返回處理結(jié)果，可能包含大量數(shù)據(jù)請求應(yīng)答Request Response2建議Advice3接收方需指明是否接受發(fā)送方的建議，返回信息簡單建議應(yīng)答Advice Respons

20、e4通知Notification5接收方僅需指明接收是否正確通知應(yīng)答Notification Response6MessageClass兩兩一組，每組中第一個值說明傳輸機制，該值加1即為第二個值，是對第一個值的確認(rèn)操作。以上定義參考道路運輸與交通信息技術(shù)電子收費（EFC）參與方之間信息交互接口的規(guī)范制定。以C#定義為：public enum MessageClassRequest = 1,RequestResponse,Advice,AdviceResponse,Notification,NotificationResponseMessageType以4字節(jié)整型表示。名稱值服務(wù)列表Servci

21、e List1價目表Fare Products List2用戶信息Customer Details3分賬規(guī)則Apportionment Rules4對賬總金額Reconciliation Totals5授權(quán)Authorization6交易Transaction7報告已發(fā)送Report Sent8密鑰管理Key Management9狀態(tài)名單Status List10設(shè)備狀態(tài)Equipment Status11例外事件Event Exception12接受付費方式Payment Method Acceptance13參與方信息Operator List14區(qū)域聯(lián)網(wǎng)保留1520000本地自定義20

22、001以上以上定義參與道路運輸與交通信息技術(shù)電子收費（EFC）參與方之間信息交互接口的規(guī)范制定。以C#定義為：public enum MessageClassServiceList = 1,FareProductsList,CustomerDetails,ApportionmentRules,ReconciliationTotals,Authorization,Transaction,ReportSent,KeyManagement,StatusList,EquipmentStatus,EventException,PaymentMethodAcceptance,OperatorList,Lo

23、calCustomized = 200014.4 消息體消息體包含一個可選屬性ContentType和多個內(nèi)容對象。消息頭中的MessageClass說明消息傳輸、應(yīng)答的方式；MessageType說明消息內(nèi)容所屬應(yīng)用分類；ContentType說明在MessageType確定的應(yīng)用中的具體分類。并不是所有消息體均有ContentType屬性。如果某MessageType下僅傳遞一種信息，則該類消息的消息體忽略ContentType屬性。4.5 消息文件的命名規(guī)則接收方為校驗文件在傳輸過程中的完整性，約定收發(fā)雙方以MD5算法對文件進行校驗。發(fā)送方生成文件后，將文件轉(zhuǎn)換成2進制流用于MD5計算。

24、計算所得結(jié)果為16字節(jié)2進制數(shù)據(jù)。命名規(guī)則為：SendereId +“_”+ ReceiverId +“_”+ MessageId +“_”+ MD5+文件擴展名。名稱文件名中字符串長度取值或說明SenderId1616進制數(shù)，不足左補0ReceiverId1616進制數(shù)，不足左補0MessageId不定10進制數(shù)MD53216進制數(shù)，不足左補0擴展名3不使用壓縮的原始數(shù)據(jù)文件，文件擴展名為“XML”,壓縮后的擴展名為“ZIP”壓縮算法為LZ77算法。每一個壓縮文件僅包含一個原始數(shù)據(jù)文件。壓縮文件與原始數(shù)據(jù)文件除擴展名不同外，文件名部分完全相同。4.6 傳輸控制發(fā)送方與接收方的數(shù)據(jù)傳輸采用一問

25、一答方式。發(fā)送方在規(guī)定時間內(nèi)未接收到接收方的應(yīng)答需通過自動重發(fā)、手動重發(fā)及文件導(dǎo)入/導(dǎo)出功能將數(shù)據(jù)傳送到接收方。重發(fā)消息、導(dǎo)出消息的MessageId保持不變。接收方向發(fā)送方發(fā)送的確認(rèn)消息不再等待對方回應(yīng)，因此也不必重發(fā)。超時時間以分鐘為單位，范圍為1至60，默認(rèn)值為10分鐘。默認(rèn)自動發(fā)送次數(shù)為3次（即自動重發(fā)2次）。若經(jīng)過自動重發(fā)后仍未得到接收方的回應(yīng)，則應(yīng)報警由人工處理。以上默認(rèn)值均應(yīng)可通過參數(shù)配置進行調(diào)整。4.6.1 通用確認(rèn)消息結(jié)構(gòu)4.6.1.1 應(yīng)用范圍接收方收到發(fā)送方的消息后，必需給予發(fā)送方回應(yīng)。不同的MessageClass，MessageType所使用的返回消息結(jié)構(gòu)不盡相同。但

26、如果消息結(jié)構(gòu)不正確（例如MessageClass值未定義）等無法通過校驗的情況發(fā)生時，接收方需通知發(fā)送方消息異常。此時需使用通用確認(rèn)消息結(jié)構(gòu)。另外，對某些消息的回應(yīng)相對簡單，也使用通用確認(rèn)消息結(jié)構(gòu)發(fā)送。各消息的詳細(xì)回應(yīng)說明請參與相關(guān)章節(jié)。4.6.1.2 消息頭名稱數(shù)據(jù)類型取值或說明MessageClassInt若所接收消息的MessageClass有效，使用與其對應(yīng)的Response值；否則使用所接收消息的MessageClass值MessageTypeInt使用所接收消息的MessageType4.6.1.3 消息內(nèi)容Body的ContentType屬性是可選的，在消息頭MessageCla

27、ss和MessageType的基礎(chǔ)上進一步指出響應(yīng)的是哪一類消息，與所回應(yīng)的消息的ContentType保持一致。Body各個子節(jié)點說明如下：名稱數(shù)據(jù)類型取值或說明MessageIdLong當(dāng)前消息所確認(rèn)的消息IdProcessTimeDateTime處理時間ResultShort執(zhí)行結(jié)果：1：消息已正常接收（用于Advice Response時含已接受建議）2：消息頭錯誤，如MessageClass或MessageType不符合定義，SenderId不存在等3：驗證未通過，即XML Schema驗證未通過、簽名誰未通過或MD5錯誤4：消息格式正確但內(nèi)容錯誤，包括數(shù)量不符，內(nèi)容重復(fù)等5：消息重

28、復(fù)6：消息正常接收，但不接受建議（僅用于Advice Response）7：消息版本錯誤820000：區(qū)域聯(lián)網(wǎng)保留20001以上：本地自定義DescriptionString(100)對返回結(jié)果的說明。例如對于結(jié)果4，在說明應(yīng)指出具體的錯誤原因。4.6.2 通用重發(fā)請求消息結(jié)構(gòu)4.6.2.1 應(yīng)用范圍應(yīng)用于數(shù)據(jù)接收方向數(shù)據(jù)發(fā)送方請求重發(fā)某些數(shù)據(jù)。4.6.2.2 消息頭名稱數(shù)據(jù)類型取值或說明MessageClassInt1，RequestMessageTypeInt請求重發(fā)的數(shù)據(jù)類型對應(yīng)的MessageType4.6.2.3 消息內(nèi)容通用重發(fā)請求消息中沒有更多的數(shù)據(jù)，其Body為空。4.6.3

29、名單數(shù)據(jù)的版本控制4.6.3.1 應(yīng)用范圍用戶狀態(tài)名單及基礎(chǔ)信息等所有經(jīng)常變動的數(shù)據(jù)。4.6.3.2 名單形式名單數(shù)據(jù)會隨著系統(tǒng)運行不斷更新。所有名單類數(shù)據(jù)的更新方式分為整體更新和增量更新兩類。整體更新是數(shù)據(jù)包包含系統(tǒng)當(dāng)前所有名單記錄，接收方通過刪除原有名單，直接使用接收到的新名單即可達到名單同步的目的。增量更新是發(fā)送方只告知接收方發(fā)生數(shù)據(jù)內(nèi)容改變的記錄，接收方根據(jù)增量內(nèi)容修改其現(xiàn)有名單從而達到數(shù)據(jù)同步。4.6.3.3 名單順序整體下發(fā)是靜態(tài)的。使用該方式可以保證發(fā)送方與接收方名單數(shù)據(jù)的同步，但每當(dāng)名單發(fā)生變化時都使用整體形式下發(fā)會降低系統(tǒng)效率，因為大部分名單數(shù)據(jù)在兩次下發(fā)之間是沒有變化的。增

30、量下發(fā)是動態(tài)的，相對整體下發(fā)數(shù)據(jù)量少，適合及時通知接收方名單的改變。通過以上兩種方式可以有效地同步發(fā)送方與接收方的名單數(shù)據(jù)，但這種方式對發(fā)送順序與接收順序要求十分嚴(yán)格。如果接收順序與發(fā)送順序不同，會使數(shù)據(jù)更新異常。大多數(shù)中間件均不能保證消息的發(fā)送順序與接收順序相同，所以在名單數(shù)據(jù)中，以版本號表示發(fā)送的先后順序。版本號從1開始，每次加1，增量名單和整體名單使用同一遞增序列。生成名單數(shù)據(jù)的參與方負(fù)責(zé)版本號。4.6.3.4 主動發(fā)送的版本處理4.6.3.4.1 處理規(guī)則發(fā)送方保證版本號逐一遞增。接收方校驗版本號，并根據(jù)版本號及名單形式執(zhí)行相應(yīng)處理。設(shè)接收方已處理的版本號為OldVer，剛剛接收的名單

31、版本號為NewVer，處理規(guī)則如下：1) 若NewVer <= OldVer，說明當(dāng)前使用的名單比接收到的名單版本更新，所以直接忽略接收到的名單。否則，轉(zhuǎn)至下一步。2) 如果新接收的名單是整體名單，則只要NewVer > OldVer則可直接處理接收到的名單，清除在第3步中臨時保存的版本小于等于NewVer的名單，完成后更新OldVer的值，即設(shè)置OldVer = NewVer。3) 如果新接收的名單是增量名單，則只有NewVer = OldVer + 1時方可立即處理，并更新OldVer的值后結(jié)束處理。否則臨時保存該名單直到合適的名單（NewVer = OldVer + 1的增量

32、名單或NewVer > OldVer的整體名單）到達。等待時間可設(shè)定。若等待一段時間后仍沒有合適的名單，則向發(fā)送方請求重發(fā)名單（如果以前已經(jīng)發(fā)送過整體名單請求重發(fā)消息且沒有收到回復(fù)則不發(fā)送）；之后收到的名單分別按第2或3步處理。4.6.3.4.2 示例以下是名單處理示例流程圖：上圖中未包含退出等待狀態(tài)，說明見下文示例?！疤幚砻麊巍卑ǖ牟僮饔校簂 根據(jù)名單更新本地數(shù)據(jù)庫；l 刪除臨時保存的版本號小于NewVer的名單；l 如果仍有臨時保存的名單中存在，版本連續(xù)且與NewVer相臨，則循環(huán)處理這些名單；l 更新OldVer值為最大已處理名單的版本號。處理完成后臨時保存的只有版本號大于Old

33、Ver + 1的名單。等待狀態(tài)中可以繼續(xù)接收消息并處理。舉例：當(dāng)前已處理的狀態(tài)名單版本為3，之后收到的版本順序為：6（增量）,7（增量），4（增量）,9（增量），8（整體）,10（回復(fù)請求重發(fā)的整體名單），5（增量）。處理過程為：l 收到版本為6的名單：臨時保存，進入等待狀態(tài)（假設(shè)等待時間結(jié)束為收到版本為9的名單之后）。l 收到版本為7的名單：臨時保存，保持原等待狀態(tài)。l 收到版本為4的名單：處理此名單，更新OldVer為4，因為臨時保存的名單顯示仍缺版本為5的名單，所以不改變等待狀態(tài)。等待時鐘重新計時（假設(shè)等待時間結(jié)束仍為收到版本為9的名單之后）。l 收到版本為9的名單：臨時保存，保持原等待

34、狀態(tài)。l 等待結(jié)束，說明通訊可能發(fā)生問題，為及時得到最新的名單，發(fā)送名單請求重發(fā)消息給發(fā)送方。l 收到版本為8的整體名單：處理此名單，更新OldVer為8，刪除臨時保存的版本為6和7的名單，不對這兩個名單進行處理。l 處理臨時保存的版本為9的名單，更新OldVer為9，退出等待狀態(tài)。l 收到版本為10的回復(fù)名單：處理此名單，更新OldVer為10。l 收到版本為5的名單：忽略。4.6.3.5 響應(yīng)請求重發(fā)的版本處理名單接收方可以向名單發(fā)送方請求發(fā)送當(dāng)前完整的名單信息。名單的發(fā)送方有兩類，一類是名單的產(chǎn)生方，即產(chǎn)生用戶狀態(tài)名單的發(fā)行方；另一類是名單的轉(zhuǎn)發(fā)方，即清分方。這兩類參與方在接收到請求重發(fā)

35、名單后，處理規(guī)則相同：l 被請求方接收到重發(fā)請求后，根據(jù)本地數(shù)據(jù)產(chǎn)生整體名單，并使用正在使用最新的版本號作為名單的版本號。l 接收方已處理的版本號為OldVer，剛剛接收的重發(fā)請求回應(yīng)名單版本號為NewVer，處理規(guī)則如下：l 若NewVer < OldVer，說明當(dāng)前使用的名單比接收到的名單版本更新，所以直接忽略接收到的名單。否則，因為重發(fā)請求回應(yīng)是整體名單，所以直接處理接收到的名單并更新OldVer，刪除所有臨時保存的名單。4.7 名單數(shù)據(jù)的有效期名單數(shù)據(jù)根據(jù)生效期應(yīng)能保存多個版本。4.8 參與方ID在消息交換中使用的發(fā)送方ID、接收方ID，以及消息中包含的公路收費方ID、發(fā)行方ID

36、及清分方ID均可以8字節(jié)整數(shù)存儲，在整個系統(tǒng)內(nèi)唯一。在XML中，參與方ID表現(xiàn)為16位長的16進制字符串，數(shù)據(jù)類型為HexBinary，不足16位左側(cè)補0。實際定義中，參與方ID為16位BCD碼。前4字節(jié)省內(nèi)自定義，對于跨省數(shù)據(jù)接口前4字節(jié)為99999999。第5個字節(jié)標(biāo)識區(qū)域中心或省級參與方ID，統(tǒng)一使用省級行政區(qū)劃代碼的壓縮BCD碼表示，如：11 北京，12 天津，13 河北。對于區(qū)域清分，使用約定代碼，如京津冀區(qū)域聯(lián)網(wǎng)電子收費清分中心的代碼是01。第6個字節(jié)為參與方類型：01為發(fā)行方，02為清分方，03為公路收費方，04為收費代理方。第7、8字節(jié)為機構(gòu)序號，從1開始。在XML中，參與方I

37、D表現(xiàn)為16位長的16進制字符串，數(shù)據(jù)類型為HexBinary，不足16位左側(cè)補0。相應(yīng)XML報文值十六進制顯示值見下表： 參與方代碼說明區(qū)域京津冀清分中心9999 9999 01 02 0001清分方北京首發(fā)路網(wǎng)9999 9999 11 03 0001公路收費方華北高速9999 9999 11 03 0002機場高速9999 9999 11 03 0003京通快速9999 9999 11 03 0004快通公司9999 9999 11 01 0001發(fā)行方北京清分中心9999 9999 1102 0001清分方天津天津路網(wǎng)9999 9999 12 03 0001公路收費方天津發(fā)行9999 9

38、999 12 01 0001發(fā)行方天津清分9999 9999 12 02 0001清分方河北河北路網(wǎng)9999 9999 13 03 0001公路收費方河北發(fā)行9999 9999 13 01 0001發(fā)行方河北清分9999 9999 13 02 0001清分方4.9 卡ID及卡類型卡ID在本系統(tǒng)中的唯一性表示為：網(wǎng)絡(luò)編碼 + 卡發(fā)行號。網(wǎng)絡(luò)編碼為4位BCD碼，IC卡發(fā)行號為16位BCD碼，電子標(biāo)簽發(fā)行號為12位BCD碼。在XML文件中，均以HexBinary表示。不足位數(shù)左側(cè)補0。五. 交易處理5.1 應(yīng)用范圍交易處理是公路收費交易從公路收費方到清分方（含本地清分方及區(qū)域清分方），再到發(fā)行方的整

39、個傳輸、記帳、爭議處理、清分統(tǒng)計、結(jié)算統(tǒng)計等各個過程的總和。本節(jié)說明在整個處理過程中使用的消息結(jié)構(gòu)及處理流程。所有交易消息的接收方均需通過通用確認(rèn)消息通知發(fā)送方消息接收結(jié)果。該確認(rèn)消息僅表示接收方是否正確收到交易消息包，不表示這些交易是否被正確記帳。除清分與結(jié)算外，其它數(shù)據(jù)在區(qū)域清分方及?。ㄊ校┣宸址街g僅為轉(zhuǎn)發(fā)關(guān)系。因此，為簡化描述，后文中若未明確說明，均以體系結(jié)構(gòu)中的簡單結(jié)構(gòu)對交易處理過程進行說明。5.2 確認(rèn)消息結(jié)構(gòu)5.2.1 應(yīng)用范圍接收方與發(fā)送方之間對交易消息、清分消息等消息的應(yīng)答均使用通用確認(rèn)消息結(jié)構(gòu)。確認(rèn)消息返回正確時僅表示正確接收，并不包含詳細(xì)的處理結(jié)果。若接收異常，通過確認(rèn)消

40、息中的Result和Description，可得到錯誤信息。5.2.2 消息頭名稱數(shù)據(jù)類型取值或說明MessageClassInt6，Notification ResponseMessageTypeInt5，Reconciliation Totals7，Transaction當(dāng)確認(rèn)交易記錄、爭議處理結(jié)果和異常交易退費時，MessageType為7；確認(rèn)記帳、清分、結(jié)算消息時，MessageType為5。具體確認(rèn)的是那一個子類的消息，由Body的ContentType說明。5.3 原始交易消息5.3.1 應(yīng)用范圍由公路收費方經(jīng)清分方發(fā)送給發(fā)行方的原始交易數(shù)據(jù)。消息發(fā)送方向如圖：上圖以公路收費方A

41、發(fā)送交易信息為例說明原始交易消息在系統(tǒng)內(nèi)的傳輸方向。黃底色的節(jié)點是消息的產(chǎn)生方。5.3.2 消息頭名稱數(shù)據(jù)類型取值或說明MessageClassInt5，NotificationMessageTypeInt7，Transaction5.3.3 消息內(nèi)容交易信息中，Body的各個子節(jié)點說明如下：名稱數(shù)據(jù)類型取值及說明ContentTypeInt1ClearTargetDateDate清分目標(biāo)日ServiceProviderIdHex(16)公路收費方Id，表示消息包中的交易是由哪個公路收費方產(chǎn)生的IssuerIdHex(16)發(fā)行方Id，表示產(chǎn)生交易記錄的電子介質(zhì)所屬的發(fā)行方MessageIdL

42、ong公路收費方生成的交易消息包IdCountInt本消息包含的交易記錄數(shù)量，大于1，小于1萬AmountDecimal交易總金額，大于等于0Transaction多條交易信息公路收費方按照電子介質(zhì)所屬的發(fā)行方，將原始交易分組打包，發(fā)送給清分方。清分方按交易包中指明的發(fā)行方將交易提交給對應(yīng)對發(fā)行方（含經(jīng)區(qū)域清分方轉(zhuǎn)發(fā)）處理。在同一個交易包中，不能包含屬于不同發(fā)行方發(fā)行的IC卡所產(chǎn)生的交易。同時，同一個交易包中，僅能包含同一清分目標(biāo)日的交易數(shù)據(jù)。在整個傳輸過程中，消息包的MessageId會發(fā)變化。為保證發(fā)行方能正確對應(yīng)公路收費方的原始交易包，公路收費方在生成原始交易消息時應(yīng)將該消息的Messa

43、geId值保存在Body的子節(jié)點MessageId中。即公路收費方生成的原始交易消息中，Header的子節(jié)點MessageId與Body的子節(jié)點MessageId的值相同。在其它傳輸階段，這兩個值可能不同。在整個傳輸過程中Body節(jié)點的MessageId保持不變。交易包中包含原始交易記錄。交易記錄的格式如下：交易記錄的屬性說明如下：名稱數(shù)據(jù)類型取值及說明TransIdInt是由公路收費方產(chǎn)生的該包內(nèi)順序Id，從1開始遞增。在公路收費方、清分方、發(fā)行方三方的交易通訊過程中均采用此Id表示包內(nèi)唯一的交易記錄。通過MessageId與TransId，可以在系統(tǒng)中唯一確定一條交易。TimeDateTi

44、me交易的發(fā)生時間，需參加TAC計算FeeDecimal交易的發(fā)生金額，以元為單位，大于等于0Service服務(wù)信息ICCardIC卡信息Validation與校驗相關(guān)的信息OBU參加交易的電子標(biāo)簽信息CustomizedDataString(500)特定發(fā)行方與公路收費方之間約定格式的交易信息CustomizedDate為特定參與方之間約定的格式，所以此處不定義長度，僅定義數(shù)據(jù)類型。為了給用戶提供完整的消費清單，即使消費金額為0，也應(yīng)將交易信息發(fā)送給發(fā)行方。服務(wù)信息Service的結(jié)構(gòu)如下：名稱數(shù)據(jù)類型取值及說明ServiceTypeShort交易的服務(wù)類型，取值見基礎(chǔ)信息維護Descrip

45、tionString(50)對交易的文字解釋。如：回龍觀北入至清河主線站出DetailString(500)交易詳細(xì)信息Description可以根據(jù)實際說明用戶消費的信息，但為了便于統(tǒng)計處理，本版本對如下幾類服務(wù)規(guī)定說明信息的格式，如有多個字段，以“”作為分隔符。類型格式高速公路開放式收費收費站名，如<Description>機場路天竺出京</Description>高速公路封閉式收費入口收費站名出口收費站名，如：<Description>西三旗八達嶺</Description>停車場收費停車場名停車時長，如<Description>

46、;首都機場T33天1小時34分</Description>。時間精確到分，如果不滿一天，則“天”省略，如果不滿1小時，則“天”和“小時”均可省略，最大單位為“天”，不必轉(zhuǎn)換為“年”、“月”、“周”Detail可以包含與交易相關(guān)的多個細(xì)節(jié)字段，每個字段以“|”分隔。不同的服務(wù)類型，Detail的格式不同。在本版本中，僅針對公路收費交易定義Detail的服務(wù)類型。Detail中各取值定義，引用自收費公路聯(lián)網(wǎng)收費技術(shù)要求。表示數(shù)值類型的數(shù)據(jù)，均為十進制表示。Detail字段結(jié)構(gòu)：名稱取值及說明收費車型1-一型車；2-二型車；3-三型車；4-四型車；5-五型車；6-六型車；710：自定義；

47、1120：用于計重收費貨車車型分類。其中，11-一型車；12-二型車；13-三型車；14-四型車；15-五型車；16-六型車；1720：自定義計重貨車車型；2150：自定義50255：保留給未來使用出口類型00-保留，02-封閉MTC出口，04-封閉ETC出口，05-MTC開放式，06-ETC開放式，070F自定義，10FF保留給未來使用出口路網(wǎng)號出口站/廣場號出口車道號出口時間YYYYMMDD HHMMSS入口類型00-保留，01-封閉MTC入口，03-封閉ETC入口，070F自定義，10FF保留給未來使用出口類型為MTC開放或ETC開放時省略入口信息入口路網(wǎng)號入口站/廣場號入口車道號入口時

48、間IC卡信息結(jié)構(gòu)如下：名稱數(shù)據(jù)類型取值及說明CardTypeShort卡類型，22為儲值卡，23記帳卡NetNoHex(4)網(wǎng)絡(luò)編碼，BCD碼CardIdHex(16)IC卡物理編號（發(fā)行號），BCD碼LicenseString(25)0015文件中記錄的車牌號PreBalanceDecimal交易前余額，以元為單位PostBalanceDecimal交易后余額，以元為單位清分方原則上不處理Validation和CustomizedData中的數(shù)據(jù)。Validation中的數(shù)據(jù)主要用于TAC計算，結(jié)構(gòu)如下：名稱數(shù)據(jù)類型取值及說明TACHex(8)交易時產(chǎn)生的TAC嗎，8位16進制數(shù)TransT

49、ypeHex(2)交易標(biāo)識，2位16進制數(shù)，PBOC定義，如06為傳統(tǒng)交易，09為復(fù)合交易TerminalNoHex(12)12位16進制數(shù)，即PSAM 號，PSAM 中0016文件中的終端機編號TerminalTransNoHex(8)8位16進制數(shù)，PSAM卡脫機交易序號，在MAC1計算過程中得到TAC的計算方法參見中華人民共和國金融行業(yè)JR/T 0025-2005 中國金融集成電路（IC）卡規(guī)范第1、2部分。TAC計算所需字段在該規(guī)范中定義與本消息結(jié)構(gòu)的關(guān)系為：名稱數(shù)據(jù)類型取值及說明交易金額Hex(8)8位16進制數(shù)，以分為單位，需根據(jù)Transaction.Fee轉(zhuǎn)換交易類型標(biāo)識Hex

50、(2)2位16進制數(shù)，取值為TransType終端機編號Hex(12)12位16進制數(shù)，取值為TerminalNo終端機交易序號Hex(8)8位16進制數(shù)，取值為TerminalTransNo，記帳卡不需此字段終端交易日期Hex(8)8位16進制數(shù)，BCD碼，YYYYMMDD，根據(jù)Transaction.Time轉(zhuǎn)換終端交易時間Hex(6)6位16進制數(shù)，BCD碼，HHMMSS，根據(jù)Transaction.Time轉(zhuǎn)換如果交易是通過ETC車道產(chǎn)生的，需附加電子標(biāo)簽信息，格式如下：名稱數(shù)據(jù)類型取值及說明NetNoHex(4)網(wǎng)絡(luò)編碼，BCD碼OBUIdHex(12)OBU物理編號（發(fā)行號），BC

51、D碼OBEStateHex(4)2字節(jié)的OBU狀態(tài)LicenseString(25)OBU中記錄的車牌號無論產(chǎn)生ETC交易的IC卡與OBU是否屬于同一發(fā)行方，均應(yīng)傳送OBU信息。5.3.4 處理流程公路收費方系統(tǒng)每隔一定時間就將所有未發(fā)送的交易放入一個原始交易消息中發(fā)送到清分方，而不是每一條交易使用一個原始交易消息（除非在時間段內(nèi)僅有一條交易需上傳）。這樣可以減少原始交易消息、記帳處理消息的數(shù)量，降低通訊負(fù)擔(dān)。同時，清分信息中包含的數(shù)據(jù)也較少，減輕處理壓力。每個交易包中包含至少一條交易記錄，最多不超過1萬條交易記錄。若在規(guī)定的時間內(nèi)累計超過1萬條未發(fā)送交易，需分別打包發(fā)送。即生成原始交易消息的

52、條件有兩個，若滿足其中之一就生成交易發(fā)送：1) 時間間隔到達且有未發(fā)送的交易；2) 時間間隔未到，但未發(fā)送交易已累計達1萬條。時間間隔默認(rèn)為10分鐘。公路收費方應(yīng)按照產(chǎn)生交易的發(fā)行方分別打包上傳，即每個交易數(shù)據(jù)包中僅能包含一個發(fā)行方用戶產(chǎn)生的交易。5.4 記帳處理消息5.4.1 應(yīng)用范圍記帳消息是由發(fā)行方處理公路收費方原始交易包的結(jié)果。對每一個收費方原始交易包，發(fā)行方均返回且僅返回一個記帳處理結(jié)果。消息發(fā)送方向如下圖：上圖以針對公路收費方A的交易的記帳處理消息為例說明記帳處理消息在系統(tǒng)內(nèi)的傳輸方向。黃底色的節(jié)點是消息的產(chǎn)生方。5.4.2 消息頭名稱數(shù)據(jù)類型取值或說明MessageClassIn

53、t5，NotificationMessageTypeInt5，Reconciliation Totals5.4.3 消息內(nèi)容記帳消息Body的各個子節(jié)點說明如下：名稱數(shù)據(jù)類型取值或說明ContentTypeInt始終為1，與原始交易消息相對應(yīng)ServiceProviderIdHex(16)公路收費方Id，指明當(dāng)前記帳消息針對的是哪一個公路收費方IssuerIdHex(16)發(fā)行方Id，說明記帳消息是哪一個發(fā)行方產(chǎn)生的MessageIdLong表示是針對哪一個公路收費方的交易包。取值為原始交易包消息體中MessageId的值ProcessTimeDateTime記帳時間CountInt本消息對應(yīng)的原始交易包中交易數(shù)量，大于0AmountDecimal確認(rèn)記帳總金額，大于等于0DisputedCountInt本消息包含的爭議交易數(shù)量，大于等于0DisputedRecord爭議交易明細(xì)記帳處理結(jié)果僅返回有爭議的交易記錄明