DB13∕T 5519.6-2022 軌道交通 AFC 系統(tǒng)線網(wǎng)技術(shù)要求 第6部分：數(shù)據(jù)傳輸

學(xué)兔兔標(biāo)準(zhǔn)下載ICS45.020CCSS7113河 北 省 地 方 標(biāo) 準(zhǔn)DB13/T5519.6—2022AFC6TechnicalrequirementsforAFCsystemnetworkofrailtransitPart6:Thedatatransfer2022-02-28發(fā)布 2022-03-31實施河北省場監(jiān)理局 發(fā)布DB13/T5519.6—2022目 次前言 II引言 III1范引文件 1語定義 1輸式 1IDB13/T5519.6—2022前 言本文按GB/T《標(biāo)化作則 第部分標(biāo)化件結(jié)和起規(guī)定起。請注意本文件的的某些內(nèi)容可能涉及專利。本文件的發(fā)布機構(gòu)不承擔(dān)識別專利的責(zé)任。DB13/T5519-2022《軌道交通AFC系統(tǒng)線網(wǎng)技術(shù)要求》分為7個部分：12——第3部分：讀寫器應(yīng)用；——第4部分：人機界面；——第5部分：票卡應(yīng)用標(biāo)準(zhǔn)；67本文件是DB13/T5519-2022的第6部分。本文件由石家莊市市場監(jiān)督管理局提出并歸口。本文件起草單位：石家莊市軌道交通集團有限責(zé)任公司、南京熊貓信息產(chǎn)業(yè)有限公司。IIDB13/T5519.6—2022引 言AFCAFC1AFC2AFC3AFC4AFC5AFC（）6AFC7AFCAFCIIIDB13/T5519.6—2022軌道交通AFC系統(tǒng)線網(wǎng)技術(shù)要求第6部分：數(shù)據(jù)傳輸范圍AFCAFC（）GB50157-2013 GB50381-2018 GB/T20907-2007 CJJ/T162-2011 本文件沒有需要界定的術(shù)語和定義。文件傳輸在AFC系統(tǒng)中各層級系統(tǒng)間文件傳輸主要通過FTP服務(wù)完成，應(yīng)滿足如下要求：FTPFTPFTPFTPFTPtmp實時報文傳輸在AFC系統(tǒng)中，實時性要求高的上行和下行的數(shù)據(jù)消息和聯(lián)機查詢請求及應(yīng)答消息應(yīng)以TCP/IP作為底層通信承載協(xié)議進行實時報文傳輸，主要提供ACC-LC-SC-SLE之間聯(lián)機報文交換功能。通訊機制本接口標(biāo)準(zhǔn)所定義的報文以TCP/IP作為底層通信承載協(xié)議，應(yīng)滿足：TCPSocketAFCSocket1DB13/T5519.6—2022LC/SCLCSCSC/SLESCSLE客戶端與服務(wù)器端通信鏈路的建立與響應(yīng)，應(yīng)滿足：客戶端與服務(wù)器端通信鏈路的鏈接方式具有單鏈路、長鏈路和異步工作模式的特性。單鏈路長鏈接接。ACCWebServiceXML通信鏈路建立以后，連接的雙方均可以連續(xù)向?qū)Ψ桨l(fā)送多條命令并接收應(yīng)答。報文傳輸方式見圖1。注：數(shù)據(jù)雙方采用A和B描述，表明A或B可以是通訊服務(wù)器或客戶端的任一方，體現(xiàn)了端與端協(xié)議對等的設(shè)計原則。圖1報文傳輸方式2DB13/T5519.6—2022為避免實時通信過程中跨層響應(yīng)的不確定性，應(yīng)采用相鄰層直接給出消息應(yīng)答(MACK)的機制，消息請求內(nèi)容的最終回復(fù)由最終接收方重啟一條消息請求報文。任何一端發(fā)出數(shù)據(jù)包后，若在時限內(nèi)沒有收到對方確認(rèn)的MACK應(yīng)答，則發(fā)送方應(yīng)在等待一定的時間間隔后需重復(fù)發(fā)出該數(shù)據(jù)包。重復(fù)發(fā)送對方?jīng)]有確認(rèn)的數(shù)據(jù)包示例見圖2。圖2重復(fù)發(fā)送對方?jīng)]有確認(rèn)的數(shù)據(jù)包示例數(shù)據(jù)包重復(fù)發(fā)出次數(shù)由實時通信參數(shù)RetryTimes設(shè)定，應(yīng)滿足：；（RetryTimes=334）數(shù)據(jù)。心跳與通信中斷的機制及參數(shù)設(shè)定，應(yīng)滿足：AlivePeriodTimeoutWithoutAnswerMaxIdlePeriodAmountMaxIdlePeriodAmountMaxInvalidMessageAmountMaxInvalidMessageAmount通用報文結(jié)構(gòu)定義所有報文字段數(shù)據(jù)類型的定義及取值范圍均參見《軌道交通AFC系統(tǒng)線網(wǎng)技術(shù)要求第7部分：數(shù)據(jù)接口》，報文格式應(yīng)滿足：8K3DB13/T5519.6—2022表1。表1實時報文格式結(jié)構(gòu)塊編號字段類型長度備注長度幀體長度TU162幀體包頭1數(shù)據(jù)塊包體2數(shù)據(jù)塊CRC值3消息驗證碼TU162包頭+包體的CRC校驗碼包頭格式見表2。表2包頭格式結(jié)構(gòu)塊編號字段名稱類型長度備注包頭結(jié)構(gòu)1MessageType消息類型碼TMessageType2參見《第九冊數(shù)據(jù)字典及編碼規(guī)則》之消息類型2ProtocalVersion協(xié)議版本號TU324定義為Const，由ACC發(fā)布新版時維護，協(xié)議應(yīng)用方直接填入該數(shù)字。新版本兼容老版本(僅限內(nèi)容變化)3SenderID發(fā)起方標(biāo)識碼TDeviceID4（應(yīng)答與請求一致），轉(zhuǎn)發(fā)時需修改為自身的ID4ReceiverID接收方標(biāo)識碼TDeviceID4（答與請求一致），轉(zhuǎn)發(fā)時需修改為接收方（相鄰層）的ID5SessionID會話流水號TU324會話的流水號應(yīng)答消息：內(nèi)容與請求消息相同6SessionFlagMap標(biāo)志位圖TU324Bit00～Bit01：請求應(yīng)答標(biāo)志（0：請求；1：應(yīng)答；2：MACK應(yīng)答；3：保留）Bit08：加密標(biāo)志（0：不加密；1：加密）,預(yù)留Bit09～Bit15：加密算法,預(yù)留Bit16：壓縮標(biāo)志（0：不壓縮；1：壓縮）,預(yù)留Bit17～Bit23：壓縮算法,預(yù)留Bit24～Bit31：預(yù)留檢查啟用字段,沒啟用字段填0.MACK當(dāng)應(yīng)答消息內(nèi)容僅包含應(yīng)答碼時，稱此應(yīng)答為MACK。MACK應(yīng)答的包體格式見表3。表3 MACK答包式結(jié)構(gòu)塊編號字段名稱類型長度備注Mack應(yīng)答包體1MACKCode應(yīng)答碼TMACK2參見《第九冊數(shù)據(jù)字典及編碼規(guī)則》報文接收方在接收到報文之后，應(yīng)進行以下幾個步驟的驗證：4DB13/T5519.6—2022CRCCRCCRC8,CRC16,CRC16FCRC32AFCCRCCRC16CRCCRC）CRCCRCCRCAFC系統(tǒng)各層級系統(tǒng)間的實時通信，應(yīng)包括：ACCLCLCLCSCACCLCSLESCSCLC通訊報文種類通訊報文列表見4。表4 通報列表報文類型編號（十六進制）報文名稱傳輸范圍及方向0x3000心跳包SLE→SC|SC→LC|LC→ACC0x3101車站模式狀態(tài)上傳SLE→SC|SC→LC|LC→ACC0x3102車站模式狀態(tài)廣播ACC→LC|LC→SC|SC→SLE0x3103車站模式控制指令A(yù)CC→LC|LC→SC|SC→SLE0x3104車站模式查詢ACC→LC|LC→SC|SC→SLE0x3105車站緊急模式控制命令A(yù)CC→LC|LC→SC|SC→SLE0x3201上傳客流統(tǒng)計信息SLE→SC|SC→LC|LC→ACC0x3301設(shè)備狀態(tài)信息上傳SLE→SC|SC→LCLCACC0x3302設(shè)備狀態(tài)信息查詢ACC—>LCLC→SC|SC→SLE0x3303參數(shù)版本上傳SLE->SC|SC->LC|LC→ACC0x3304參數(shù)版本查詢ACC→LC|LC→SC|SC→SLE0x3305設(shè)備軟件版本上傳SLE->SC|SC->LC0x3306設(shè)備軟件版本查詢LC→SC|SC→SLE0x3307設(shè)備交易數(shù)據(jù)索取Lcsc|SC→SLE0x3308設(shè)備控制指令LC→SC|SC→SLE0x3309TVM的錢箱和票箱數(shù)據(jù)上傳SLE→SC|SC→LC0x3310TVM的錢箱和票箱數(shù)據(jù)查詢LC→SC|SC→SLE0x3311BOM/AGM票箱數(shù)據(jù)上傳SLE→SC|SC→LC0x3312BOM/AGM票箱數(shù)據(jù)查詢LC→SC|SC→SLE0x3313時鐘強制同步指令A(yù)CC→LC|LC→SC|SC→SLE0x3314設(shè)備指定交易記錄索取SC→SLE0x3315設(shè)備操作日志上傳SLE→SC|SC→LC0x3316AVM錢箱數(shù)據(jù)上傳SLE→SC|SC→LC0x3317AVM錢箱數(shù)據(jù)查詢SLE→SC|SC→LC0x3401線路庫存調(diào)配申請SC→LC|LC→ACC0x3402庫存調(diào)配命令A(yù)CC→LC|LC→SC0x3403庫存快照SC→LC|LC→ACC0x3501FTP登陸申請SLE→SC|SC→LC|LC→ACC5DB13/T5519.6—2022表4通訊報文列表（續(xù)）報文類型編號（十六進制）報文名稱傳輸范圍及方向0x3502文件下載/上傳命令A(yù)CC→LC|LC→SC|SC→SLE0x3503FTP通訊信息ACC→LC|LC→SC|SC→SLE設(shè)備簽到流程設(shè)備重啟時、日始和網(wǎng)絡(luò)恢復(fù)時，設(shè)備均應(yīng)發(fā)起設(shè)備簽到。設(shè)備簽到流程，應(yīng)包括：SCACC級EOD參數(shù)、TP參數(shù)如果不能同步，則該設(shè)備須進入暫停服務(wù)，并發(fā)報警信息。其他參數(shù)不能同步時僅發(fā)報警信息。ACC-LCACC與LC之間采用通信中間件作為實時數(shù)據(jù)傳輸?shù)耐ǖ?。?yīng)在ACC連接方式應(yīng)由ACC與LC協(xié)商決定。ACC和LC之間的通信傳遞宜采用支持互聯(lián)互通的通信中間件標(biāo)準(zhǔn)。AC（QCQServe/ClentACCACC-LC消息隊列結(jié)構(gòu)示例圖見圖3。圖3 ACC-LC消隊構(gòu)示圖6DB13/T5519.6—2022ACC（MQ）QM_ACC330。。表5 構(gòu)的列器ID隊列管理器名稱隊列管理器描述0QM_ACC000ACC隊列管理器1QM_ACC0011號線隊列管理器2QM_ACC0022號線隊列管理器3QM_ACC[<N>]N號線隊列管理器為了保留日志不被覆蓋，應(yīng)選用線性日志。日志參數(shù)表見表6。表6 志數(shù)表命令對應(yīng)項含義值A(chǔ)ix下值的范圍[ll|lc]線性日志/循環(huán)日志llll或lc<LogPath>記錄路徑缺省/var/mqm/log<LogFileSize>記錄文件頁數(shù)64-65535，缺省值4096（16M）<LogPri>記錄主文件數(shù)2-510<LogSec>記錄輔助文件數(shù)1-509通道命名規(guī)則：QCH.LC.ACC.<線路編號>150015011502,1503通道配置舉例見表7。表7 道置例線路編號通道號用途一號線QCH.LC.ACC.01與線路一消息交互二號線QCH.LC.ACC.02與線路二消息交互三號線QCH.LC.ACC.03與線路三消息交互…ACC端的偵聽器命名規(guī)則如下：<LSR>.<協(xié)議名稱>.<ACC>.<偵聽端口號>ACC隊列管理器中偵聽器列表見表8。表8ACC隊列管理器中偵聽器列表ID偵聽器名稱偵聽端口號備注1LSR.TCP.ACC.15011501一號線偵聽器2LSR.TCP.ACC.15021502二號線偵聽器3LSR.TCP.ACC.15031503三號線偵聽器4LSR.TCP.ACC.[1500+<N>]15<ID>7DB13/T5519.6—2022隊列命名規(guī)則：LC.<隊列用途>.<隊列報文類型>由于ACC-LC間通過MQ傳輸?shù)南⒍紴閷崟r消息，類型應(yīng)采用MESSAGE表示。隊列命名規(guī)則字段見表9。9字段說明名稱前綴LC接收隊列/發(fā)送隊列接收隊列：RECV發(fā)送隊列：SEND隊列報文類型普通報文：MESSAGEMQ通過使用MQMD結(jié)構(gòu)，應(yīng)可訪問消息中的控制信息。消息描述符結(jié)構(gòu)見表10。表10消息描述符結(jié)構(gòu)字段設(shè)置值說明備注StrucIdMDbbStructureidentifierVersionMQMD_VERSION_2StructureversionnumberReportMQRO_NONEOptionsforreportmessagesMsgTypeMQMT_DATAGRAMMessagetypeExpiryMQEI_UNLIMITEDMessagelifetimeFeedbackMQFB_NONEFeedbackorreasoncodeEncodingMQENC_NATIVENumeric encodingofmessagedataCodedCharSetId<UserSpecific>Character identifierofmessagedataFormatMQGMO_CONVERTFormat name ofmessagedataPriority<UserSpecific>Messagepriority用戶自定義PersistenceMQPER_PERSISTENTMessageMsgIdDEFAULTMessageidentifierMQ自動生成CorrelId<UserSpecific>Correlationidentifier用戶自定義BackoutCountDEFAULTBackoutcounterReplyToQDEFAULTName of replyqueueReplyToQMgrMQACT_NONEName of replyqueuemanagerUserIdentifierDEFAULTUseridentifierAccountingTokenMQACT_NONEAccountingtoken8DB13/T5519.6—2022表10消息描述符結(jié)構(gòu)（續(xù)）字段設(shè)置值說明備注ApplIdentityData<UserSpecific>Applicationdatarelatingtoidentity用戶自定義PutApplTypeDEFAULTTypeofapplicationthatputthemessagePutApplNameDEFAULTNameofapplicationthatputthemessagePutDateDEFAULTDatewhenmessagewasputPutTimeDEFAULTTimewhenmessagewasputApplOriginDataDEFAULTApplicationdatarelatingtooriginGroupId<UserSpecific>Groupidentifier用戶自定義MsgSeqNumber<UserSpecific>Sequencenumberoflogicalmessagewithingroup用戶自定義OffsetDEFAULTOffsetofdatainphysicalmessagefromstartoflogicalmessageMsgFlags<UserSpecific>Messageflags用戶自定義OriginalLengthDEFAULTLengthoforiginalmessage注1：MDbb表示“MD”(帶兩個空格)，是StrucId字段的默認(rèn)常量MQ_STRUC_ID的值。注2：斜體字的值是宏變量MQMD_DEFAULT設(shè)定的默認(rèn)值。注3：“DEFAULT”用來表示字段由MQ自動設(shè)置。注4：<UserSpecific>表示按業(yè)務(wù)需求設(shè)置的字段。主要利用WebSphereMQ傳送實時通信報文實現(xiàn)，ACC與LC之間傳輸?shù)膶崟r報文結(jié)構(gòu)與線路內(nèi)的報文結(jié)構(gòu)一致。消息報文種類見表11。表11消息報文種類報文類型編號（十六進制）報文名稱傳輸范圍及方向0x3000心跳包LC→ACC0x3101車站模式狀態(tài)上傳LC→ACC0x3102車站模式狀態(tài)廣播ACC→LC0x3103車站模式控制指令A(yù)CC→LC0x3104車站模式查詢ACC→LC0x3105車站緊急模式控制命令A(yù)CC→LC0x3201上傳客流統(tǒng)計信息LC→ACC0x3301設(shè)備狀態(tài)信息上傳LCACC0x3302設(shè)備狀態(tài)信息查詢ACC—>LC0x3303參數(shù)版本上傳LC→ACC0x3304參數(shù)版本查詢ACC→LC0x3313時鐘強制同步指令A(yù)CC→LC0x3401線路庫存調(diào)配申請LC→ACC0x3402庫存調(diào)配命令A(yù)CC→LC0x3403庫存快照LC→ACC0x3501FTP登陸申請LC→ACC0x3502文件