• 633.34 KB
  • 46页

MH 0048.2-2015 民用机场共用旅客处理系统技术规范 第2部分:应用软件数据交换

  • 46页
  • 当前文档由用户上传发布,收益归属用户
  1. 1、本文档共5页,可阅读全部内容。
  2. 2、本文档内容版权归属内容提供方,所产生的收益全部归内容提供方所有。如果您对本文有版权争议,可选择认领,认领后既往收益都归您。
  3. 3、本文档由用户上传,本站不保证质量和数量令人满意,可能有诸多瑕疵,付费之前,请仔细先通过免费阅读内容等途径辨别内容交易风险。如存在严重挂羊头卖狗肉之情形,可联系本站下载客服投诉处理。
  4. 文档侵权举报电话:19940600175。
'ICS35.240.60V07MH中华人民共和国民用航空行业标准MH/T0048.2—2015民用机场共用旅客处理系统技术规范第2部分:应用软件数据交换SpecificationofcommonusepassengerprocessingsystemsincivilaviationairportsPart2:Interfacebetweenapplications2015-09-30发布2015-12-01实施中国民用航空局发布 MH/T0048.2—2015目次前言................................................................................II1范围..............................................................................12术语和定义........................................................................13数据交换接口通用标准..............................................................14数据交换接口消息处理规则.........................................................23附录A(资料性附录)数据交换接口及消息处理示例.....................................32I MH/T0048.2—2015前言MH/T0048分为以下三个部分:——第1部分:系统结构;——第2部分:应用软件数据交换;——第3部分:硬件设备数据交换。本部分为MH/T0048的第2部分。本部分按照GB/T1.1-2009给出的规则起草。本部分由中国民用航空局人教司提出。本部分由中国民用航空局航空器适航审定司批准立项。本部分由中国民航科学技术研究院归口。本部分起草单位:中国民航大学、中国民航信息网络股份有限公司。本部分主要起草人:李建伏、孙皓、贺怀清、张博、惠康华、丁玎、徐涛、武佳、孙启玲、李斌。II MH/T0048.2—2015民用机场共用旅客处理系统技术规范第2部分:应用软件数据交换1范围MH/T0048的本部分规定了共用旅客处理系统的应用软件与管理平台之间数据交换接口技术规范。本部分适用于中国民用机场共用旅客处理系统的建设。2术语和定义2.1共用旅客处理系统CUPPSCommonUsePassengerProcessingSystems由国际航协定义,用于航空公司使用机场的终端设备的信息处理规范。[MH/T0048.1-2014中的3.1]2.2CUPPS工作站CUPPSWorkstation运行于CUPPS平台上的硬件和操作系统软件。硬件包括计算机、移动终端设备、智能手机、简易客户终端等。[MH/T0048.1-2014中的3.2]2.3CUPPS应用CUPPSApplication运行在CUPPS平台上,使用CUPPS平台接口的应用程序。[MH/T0048.1-2014中的3.3]3数据交换接口通用标准3.1平台架构平台管理所有连接到平台的请求,并为这些连接提供标准接口来访问机场资源和其他系统。平台可使用多种体系架构,见图1。1 MH/T0048.2—2015图1平台架构平台架构由以下组成,应用程序1使用设备1和2,应用程序2使用设备1,应用程序3使用设备3:——(a)实现架构:表示在该平台上应用程序通过一个节点(节点1)连接到所有设备,每个逻辑设备由一个独立的物理设备实现;——(b)实现架构:表示在该平台上应用程序通过两个节点(节点1和2)连接到设备,节点1提供了物理设备1的逻辑接口。节点2为一个多功能物理设备提供逻辑接口;——(c)实现架构:表示在该平台上,应用程序首先连接到节点1,该节点提供了一个逻辑分配机制,使应用程序可重定向到其他节点。当应用程序1连接到平台上的节点1获取逻辑设备1和2时,该平台分别将应用程序1重定向到节点2和3;当应用2连接到平台上的节点1获取逻辑设备2时,该平台将应用2重定向到节点3;当应用3连接到平台上的节点1获取逻辑设备3,该平台将应用程序3重定向到节点4。其中,所有的逻辑设备是通过一个多功能物理设2 MH/T0048.2—2015备来实现。注:应用程序通过设备的名称和接口访问设备,与设备所在位置无关,名称和接口都由环境变量指定。应用程序不能推理出平台组件的任何特定实现方法,以及设备与平台连接的任何特定物理实现方法。3.2接口状态CUPPS接口的不同状态如表1所示。在生产环境中,如果应用程序试图使用支持状态之外的接口,平台应记录相应的信息供管理员审查,并触发警报。表1CUPPS接口状态状态描述提出接口已经被提出,但是还没计划计划接口正在计划中开发接口处于实验性测试状态,不能在生产环境中使用支持接口处于正常的生产状态接口仍然被支持,但不推荐使用。该接口即将进入过时状态。在生产过程中对该接口的任何使用,都将产不建议生一个警告,且被平台记录下来废弃接口不再被支持。在生产中任何试图使用这种接口的行为都产生一个错误3.3接口版本3.3.1在每个单独的TCP(TransmissionControlProtocol传输控制协议)端口上的平台和设备端应同时支持多个版本的CUPPS接口。当应用程序连接到CUPPS平台后,首先应请求得到该平台支持的接口版本列表,然后从获取的接口版本列表中选择一个版本进行后续的会话。3.3.2会话消息需通过已选择的接口版本的校验。如果校验失败,则触发消息,并立即关闭该会话。3.3.3如果应用程序在版本列表中没有找到支持的接口,应用程序应做以下处理:a)记录错误;b)发送一个错误事件;c)通知终端用户。终端用户根据提示信息,咨询相应的技术支持人员。所有的CUPPS接口都遵守一套通用的基本规则。所有CUPPS接口应使用TCP套接字,消息交换内容应符合已定义XSD(XMLSchemasDefinition,XML结构定义)的W3C(WorldWideWebConsortium,万维网联盟)XML(ExtensibleMarkupLanguage,可扩展标记语言)消息格式。3.4平台主机名和端口应用程序通过TCP/IP(InternetProtocol,网络间通信协议)连接服务器,服务器应向应用程序提供对应的服务器主机名和端口。应用程序根据CUPPSPN与CUPPSPP环境变量确定平台的主机名和端口。考虑到生产和测试环境的灵活性,可使用IP地址127.0.0.1。3.5会话原则3.5.1会话流程应用程序和平台之间的会话流程图如图2所示,主要包括以下几个步骤:3 MH/T0048.2—2015a)平台监听一个已知的节点和端口;b)应用程序连接到平台的相应节点和端口。在连接时,应用程序向平台发出可用接口版本列表请求,平台收到请求后返回可用接口列表;c)应用程序向平台发送期望使用的接口版本。该接口版本经平台确认后,将用于后续会话消息的验证;d)平台验证应用程序的合法性,并返回验证结果。如果验证成功,则应在验证结果中包含令牌信息。该令牌信息应用于所有后续通信以及验证设备连接。当平台连接关闭后,令牌失效,基于此令牌的连接也应立即断开;e)应用程序使用已定义消息集与平台进行通信。对于每个设备会话,应用程序在断开连接之前,均应发送并获得平台对应的响应;f)应用程序断开。当应用程序关闭时,应向平台发送消息,获取消息后方可断开连接。建立连接重定向设置接口版本认证使用断开连接图2会话流程基本的会话连接序列图原型参见附录A.1。3.5.2消息处理流程3.5.2.1建立连接后,当接收端收到消息时,应判断消息流的合法性。3.5.2.2消息从接收到处理的流程见图3。处理流程如下:a)接收端逐字节地读取消息头:如果接收端读取到无效字符,则接收端立即停止读取,发送的通知,并在该通知中包含信息eventType=“headerVersion”,随后关闭连接。如果接收端读取的消息长度越界,则接收端发送的通知,并包含信息eventType=“headerLength”,随后关闭连接。如果读取消息头超时,则接收端发送的通知,并包含信息eventType=“headerTimeout”,随后关闭连接;b)读取消息体:消息头中包含消息体的长度,如果在读取这个指定长度的消息体时超时,接收端发送的通知,其中包含信息eventType=”bodyTimeout”,随后关闭连接;4 MH/T0048.2—2015c)解析消息体:如果接收端无法使用选定的接口版本解析消息体,则接收端发送的通知,其中包含信息eventType=“bodyParseFailure”,随后关闭连接;d)处理经过解析的信息。sessionErrorEventheaderVersionsessionErrorEvent读取消息头headerLengthsessionErrorEvent断开连接headerTimeoutsessionErrorEvent读取消息体bodyTimeoutsessionErrorEvent解析消息体bodyParseFailure处理消息图3平台消息处理流程3.5.3应用程序认证3.5.3.1一旦应用程序连接到平台并且选择好接口版本,则该应用程序应向平台请求认证。如果应用程序未能通过认证,则平台应断开与该应用程序的连接。3.5.3.2应用程序认证分为两步:a)应用程序向平台发送消息请求认证;b)平台记录应用程序的认证请求,回复消息。该消息应包含以下信息:1)设备令牌:用于后续设备交互操作;2)平台参数:平台供应商ID和版本信息以用于日志记录;3)支持的加密算法列表;4)应用程序参数:局部存储、局部临时存储以及永久性全局存储地址;5)工作站参数:工作站的名字、厂商信息、平台的配置信息、操作系统默认的打印机名称等;6)设备分配列表(样品);7)特殊模式接口,ZI(IATAmessagesoftwaredevice,IATA信息设备)和ZL(loggingsoftwaredevice,日志设备)都是被指定的。应用程序认证请求与回复的消息示例参见附录A.8。3.5.4应用程序主动与平台断开连接5 MH/T0048.2—20153.5.4.1应用程序与平台端口断开连接之前,应向平台发送消息以通知平台方应用程序将要断开连接。平台端接收到消息后,回复消息,并等待应用程序断开连接。附录A.6为与平台断开连接的示例。3.5.4.2应用程序发送消息后,平台端将该应用程序设置为aSpg状态,不允许该应用程序继续向平台发送其他消息。如果该应用程序在aSpg状态试图发送消息,平台记录事件。3.5.4.3平台接收后,等待应用程序断开连接,且不能向应用程序发送其他消息。如果在1)PltSockMaxIdleTime后,该应用程序仍未断开,平台应作相应日志记录,然后断开该连接。3.5.5平台端发起的应用程序正常退出机制3.5.5.1本部分仅规范了应用程序的正常退出机制,应用程序的异常退出机制见本标准第1部分的9.1.8。3.5.5.2平台端可通过发送特定的指令断开应用程序连接。断开连接的形式有两种,即请求方式与控)制方式。3.5.5.3请求方式通过平台向应用程序发送指令停止应用程序。在接收到平台的停止指令后,应用程序应关闭与设备的连接、记录日志、通知用户应用程序正在退出,并最终关闭与平台的连接。此过程应2)3)在AppSpgTime时间内完成,如果需要更多的时间退出应用程序,最多可增加MaxSpgDegerTimes次延迟退出的请求。3.5.5.4控制方式通过平台端执行指令停止应用程序。在这种情况下,应用程序被置为aSpg状态,如4)果应用程序退出时长超过了AppSpgTime,应用程序将会进入aZom状态并被强制清除。图4给出了平台端发起的应用程序正常退出的四种情况:a)平台允许应用程序延迟退出,但应用程序不需要延迟的情况,分为:1)步骤“1”,平台请求应用程序停止;2)步骤“2”,应用程序回复可以退出。平台立即使分配给该应用程序的设备令牌失效;3)步骤“3”,应用程序关闭与平台的连接,然后退出程序。b)平台允许应用程序延迟退出,且应用程序需要延迟的情况,分为:1)步骤“1”,平台请求应用程序停止。应用程序回复平台需要延迟退出。平台重置应用退5)出计时器AppSpgTime;2)步骤“2”,应用退出计时器超时,平台继续向应用程序发送停止请求。应用程序回复延迟退出。平台重置应用退出计时器;1)见表3。2)见表3。3)见表3。4)见表3。5)见表3。6 MH/T0048.2—2015图4应用程序退出场景3)步骤“3”,应用退出计时器超时,平台端将应用程序置为aSpg状态。该应用程序回复需要延迟退出时间,但是平台已不允许应用程序延时,所以平台忽略了这一请求;4)步骤“4”,应用程序尚未终止与平台的连接,平台最后一次发送停止请求,并忽略所有来自应用程序的消息;5)步骤“5”,应用退出计时器超时。平台将应用程序的状态改为aZom,强行断开连接并释放与该应用程序有关的所有资源。c)平台不允许应用程序延迟退出,且应用程序也不需要延迟的情况。分为:1)步骤“1”,平台请求应用程序停止,并将应用程序置为aSpg状态;2)步骤“2”,应用程序回复可以退出。平台立即将分配给应用程序的设备令牌失效;7 MH/T0048.2—20153)步骤“3”,应用程序关闭平台的连接并且终止。d)平台不允许应用程序延迟退出,但应用程序需要延迟的情况。分为:1)步骤“1”,平台请求应用程序停止,并将应用程序置为aSpg状态,应用程序回复平台需要延迟退出;2)步骤“2”,平台关闭连接并且将应用程序置为aZom状态,然后断开与应用程序的连接并释放相关的所有资源。应用停止指令请求的消息示例参见附录A.7。应用程序A平台1ApplicationStopRequestcanDefer=“false”12applicationStopResponseresult=“OK”233[TCPclose](c)应用程序A平台1ApplicationStopRequestcanDefer=“false”1ApplicationStopResponseresult=“defer”22ApplicationStopRequestcanDefer=“false”[TCPclose](d)图4(续)3.6平台令牌失效和设备会话失效3.6.1应用程序在使用平台期间,应和平台保持连接。如果应用程序与平台的连接中断,与该连接相对应的设备令牌应立即失效。如果应用程序使用要求终止与平台的连接,则其设备令牌也应失效。8 MH/T0048.2—20156)3.6.2使用失效令牌的设备连接是无效的。失效的设备会话在PltSockMaxIdleTime内依然保持连接状态。在此期间,不允许再往这个连接上发送消息。如果应用程序试图在无效会话上发送信息,则平台认为该消息是非法消息并回复。3.7消息头3.7.1CUPPS信息交互协议提供多个版本的消息头。消息头遵循vvllllllll[xxx]的基本格式,每一位为[A~Z,0~9]对应的ASCII字符,其中:——vv为用2个字节表示的消息头版本;——llllllll为一个8个字节长的数据表示消息体长度,数据的内容可用大写或小写字母表示,即0123abcd和0123ABCD是一样的;——[xxx]为消息头版本对应的扩展数据。表2为消息头格式。表2平台消息头格式版本状态备注01支持的2个字节消息头版本,后跟8字节的长度信息。3.7.2从会话连接尝试读取信息时,消息头的长度指定了应读取的字节数。当写入会话连接时,长度信息应按照对应版本规定的规则进行计算。3.7.3如果接收方接收到不支持的消息头版本,应使用01版本消息头向发送方回复错误信息,并终止该会话。7)3.7.4消息头版本01定义最大消息长度,即PltMaxMsgSize字节(大约16MB)。由于会话使用8字节字段的消息长度,前两个字节的长度都被置为0。示例:消息头版本01错误样例如下:1.01FF00003F<消息体长度FF00003F越界,最大支持FFFFFF/>2.01........[消息头版本]3.00......[00是可用的,FF会导致超过PltMaxMsgSize错误]4.00003F[消息体的长度信息]3.7.5使用版本01时,读取或写入连接时应遵循以下规则:——当往连接中写数据时,长度信息为所有消息体字节数,消息体使用UTF8编码方式;——当从连接读取数据时,应按消息头中定义的消息体长度信息读取指定长度数据。消息体使用UTF8编码方式。示例:消息头版本01正确样例如下:1.0100000013body2.01...........................[消息头版本01]3.00000013...................[消息体长度为19个字节]4.body[消息体]3.8流协议6)见表3。7)见表3。9 MH/T0048.2—20153.8.1CUPPS连接使用简单标准流协议传输UTF8编码的XML信息。每个消息均以消息头开始,按字节从流中读取。3.8.2图5和图6分别为接口发送和接收消息状态机,消息读取端应按字节读取数据。消息接收的最8)大时长为PltStreamAccumTime。3.8.3当从连接中读取消息头时,接收方应按位读取,一旦碰上无效字符,则立即停止读取。准备发送消息计算长度前缀发送消息头传输超时连接丢失传输完成发送消息体传输关闭连接超时连接丢失连接丢失传输完成图5消息发送状态机8)见表3。10 MH/T0048.2—2015图6消息接收状态机3.8.4应用程序和平台之间的交互消息应使用先进先出的顺序原则处理,包含应用程序断开请求的流消息应按其在流中出现的顺序处理。3.8.5平台与应用之间的消息交互方式分为两种:请求/应答与通知。在请求/应答方式下,请求需要应答确认。交互支持同时发送多个请求。请求消息包含messageID属性,应答消息的messageID与请求信息的messageID一致。5.1.5详细规定了messageID的定义与生成规则。在通知方式下,消息从发送端传输到接收端,无需回应。3.9接口消息里的二进制数据接口交互消息中的二进制数据应使用Base64方式进行编码、传输。3.10平台参数应用程序在启动之前应设置的平台参数见表3。表3平台参数参数定义功能描述建议值时间跨度AppAthTime应用程序平台认证应用程序的最大时5.0s开始:平台接收到来自应用程序的认证时长长完整认证请求;结束:平台开始发送对应用程序认证响应AppSpgTime应用程序从收到平台关闭指示后关闭45.0s开始:平台命令应用程序关闭的时停止所需程序所需的最大时长刻;结束:应用程序关闭完成的时时长刻11 MH/T0048.2—2015表3(续)参数定义功能描述建议值时间跨度AppStgTime应用启动平台启动应用程序所消耗的30.0s开始:终端用户点击应用程序对应时长最大时长,包含运行环境的准菜单项的时刻;结束:应用程序启备和应用程序本身启动的时动的时刻长AppStpTime应用已停平台在应用程序退出后,进行30.0s开始:应用程序终止的时刻;结束:止时长清理操作的最大时长平台清理完成的时刻DevAcqMaxTime请求设备处理30.0s开始:完的最大时消全被接收的时刻;结束:长息的最大时长完全被发送出去的时刻DevLkdTime锁定设备设备被锁定的最大时长,超过60.0s开始:设备进入dLkd的时刻;结束:时长这个时间设备将进入dStd状当前时刻态DevNormTime读设备读读设备的一个特定参数。如果5.0s开始:最后一个读设备的消息被发取时长不间断读取信息的设备在送到应用程序的时刻;结束:当前DevNormTime定义的时间内读时刻取到多个数据值可用,则平台只将最后读取到的数据发送给应用DevPollMaxFreq设备最大平台允许应用程序轮询设备5.0s查询时长状态的最大频率。过多轮询会导致平台回复pollingTooFast消息DevSpgTime设备停止设备停止所需的最大时长。如30.0s开始:设备进入dSpg状态的时刻;时长果设备停止超时,则进入dZom结束:当前时刻状态DevStgTime设备启动正常启动设备所需的最大时60.0s开始:设备进入dSpg状态的时刻;时长长。如果设备启动超时,则从结束:当前时刻dStg状态进入dZom状态。MaxDevLockTime锁定设备平台处理5.0s开始:平台接收到的最大时消息的的时刻;长最大时长结束:平台返回的时刻MaxDevStsTime获取设备平台处理5.0s开始:平台接收到状态的最消息的时刻;结大时长的最大时长束:平台返回的时刻12 MH/T0048.2—2015表3(续)参数定义功能描述建议值时间跨度MaxDevUnlTime解锁设备的最大平台处理2.0s开始:平台接收到时长的时消息的最大时长刻;结束:平台返回的时刻MaxMessageID平台消息ID的最平台端发起消息的最大ID0xffffffff大值值MaxSpgDeferTimes推迟停止的最大应用程序推迟关闭的最大4次次数次数MinMessageID消息ID的最小值应用程序端发起消息的最0x00000001小ID值MinPlatformMsgID平台消息ID最小平台端发起消息的最小ID0xffff0000值值MsgIDListLen消息ID清单的长最近发送或接收消息ID值255条度的最小条数PGSMin全局永久存储的平台为每个航空公司提供1GB最小值的全局存储空间的最小值PLSMin本地永久存储的平台为每个航空公司提供1GB最小值的本地存储空间的最小值PNSMin网络存储最小值平台为每个航空公司提供1GB的持久网络存储空间的最小值PltAltMaxDlvTime传递警告消息的平台向所有工作站发送警600.0s最大时长报消息的最大时长PltAppStrMin平台应用程序存平台为每个航空公司应用5GB储最小值程序提供的存储空间的最小值PltLogMinStr存储平台日志文平台为每个航空公司提供5天件的最小时长日志存储时间的最小值PltMaxMsgSize最大消息长度接口消息的最大长度0x00ffffff字节PltMsgHdrSize消息头大小消息头的字节数可变的PltRepGran报告时间间隔平台报告基于时间的活动60.0s开始:平台上一次报告的时刻;的时间间隔结束:当前时刻13 MH/T0048.2—2015表3(续)参数定义功能描述建议值时间跨度PltSockMaxIdleTime连接最大空闲时间PltSockMaxIdleTime用于以下两种情600.0s开始:a)连接建立况:(a)连接建立之后,未接收到任何后未接收到任何字字符之前的时间段;(b)客户端发送符前,(b)客户端发或送指令准备结或束会话之后,关闭连接之前的时间段之后,关闭连接之前;结束:当前时刻PltStreamAccumTime消息流接收时间平台与应用之间,同一消息的字节发60.0s开始:从连接缓冲送之间,允许的最长空闲时间。当接区中读取到第一个收端获取到任一字节时,字节;结束:当前PltStreamAccumTime计时器复位。当时刻接收端接收缓冲区被清空时,PltStreamAccumTime计时器启动。当PltStreamAccumTime计时器超时,则给对方发送消息PltStreamOutMsgs最大重复消息数量同一个连接支持的重叠消息的最大值5条PltStreamOutMsgsZLZL设备最大重复消ZL设备的连接中支持的重叠消息的最20条息数量大值。对于ZL设备,应用程序可在收到logWriteResponse消息之前,继续发送logWriteRequest。当累积到PltStreamOutMsgsZL个未收到回复的请求时,应用程序应暂停发送logWriteRequestPRMaxResponseTime打印的最大响应时PR设备处理消息的最120.0s间大时长。如果在这段时间过后还没有开始打印,则平台端取消此次打印任务TSMin最小临时存储空间应用程序临时存储空间的最小值1GBUsrAthTime用户认证时间认证终端用户的最大时长10.0s开始:接收到认证消息第一个字节的时刻;结束:当前时刻UsrAthTries用户认证次数工作站连续尝试登陆均失败的最大次3次数14 MH/T0048.2—2015表3(续)参数定义功能描述建议值时间跨度UsrSpgTime用户停止时间用户对象退出的最大时长。一旦超时,工30.0s开始:用户开始退出作站将进入uZom状态,在随后的清理结结束:用户对象清除的时束后,应为下一个用户登陆做好准备刻UsrSsTime用户屏保时间用户在工作中运行屏幕保护程序的最大600.0s开始:用户在工作站上最时长.一旦超时,用户从uSs状态进入后一个活动的时刻uSpg状态结束:当前时刻UsrToTime用户超时时间用户的最大空闲时间。一旦超时,用户从600.0s开始:用户在工作站上最uStd状态进入uSs状态后活动的时刻,如键盘输入、鼠标操作、设备使用等;结束:当前时刻WsAltTime工作站警告超工作站解除警告信息的最大时长600.0s开始:工作站进入wAlt的时时间时刻;结束:当前时刻WsSpgTime工作站停止时工作站退出的最大时长。一旦超时,工作30.0s开始:工作站进入wSpg的间站从wSpg状态进入wZom状态时刻;结束:当前时刻对于与时间相关的参数,平台和应用程序应允许运行时间偏差在±1%之间。3.11设备锁定与解锁3.11.1令牌锁与连接锁3.11.1.1令牌锁的锁定机制基于令牌,连接锁的锁定机制基于连接。对于连接锁,一旦一个连接成功锁定设备,则其他任何连接均不能锁定该设备。而对于令牌锁,使用同样令牌的不同连接可同时锁定设备。3.11.1.2采用连接锁时,设备的锁定状态从开始,到对应的结束。采用令牌锁时,设备的锁定状态从第一个开始,到成功锁定的最后一个结束。3.11.1.3图7为两种锁机制的示例,其中有两个应用程序连接A与B,均希望使用设备BC1。该图给出了应用程序与平台之间的交互,在交互开始之前,应用程序与平台均已成功建立连接。15 MH/T0048.2—2015应用程序A应用程序B平台deviceLockRequestbyDeviceToken=ABC111deviceLockResponseOKdeviceLockRequestbyDeviceToken=BBC122deviceLockResponsedeviceLockeddeviceLockRequestbyConnectionBC133deviceLockResponsedeviceLockeddeviceLockRequestbyDeviceToken=BBC144deviceLockResponsedeviceLockeddeviceLockRequestbyDeviceToken=ABC155deviceLockResponseOK用户扫描条码6notifydataAvailableBC16notifydataAvailableBC1readerReadRequestBC177readerReadResponseOK{data}readerReadRequestBC188readerReadResponseOK{}deviceUnlockRequestBC199deviceUnlockResponseOK用户扫描条码1010notifydataAvailableBC1deviceLockRequestbyDeviceToken=ABC11111deviceLockResponseOK-deviceAlreadyLockeddeviceUnlockRequestBC11212deviceUnlockResponseOKdeviceLockRequestbyConnectionBC11313deviceLockResponseOKdeviceLockRequestbyConnectionBC11414deviceLockResponsedeviceLocked图7令牌锁与连接锁锁定示例3.11.1.4图7中应用程序与平台之间的交互步骤如下所示。在每个步骤之后,记录设备持有的锁状态,其中“*”代表连接锁,“t=x”代表令牌为x的令牌锁:a)步骤“1”,应用程序A使用设备令牌A获得设备BC1的锁定。其中:16 MH/T0048.2—20151)A={BC1t=A};2)B={};b)步骤“2”,应用程序A试图使用令牌B锁定设备。因为这个设备已经使用令牌A锁定,所以平台拒绝的该锁定请求。其中:1)A={BC1t=A};2)B={};c)步骤“3”,应用程序B试图使用连接锁锁定设备。但因为这个设备已经使用令牌A锁定,所以平台拒绝了该请求。其中:1)A={BC1t=A};2)B={};d)步骤“4”,应用程序B试图使用令牌B锁定设备。因为这个设备已经使用令牌A锁定,所以平台拒绝了该请求。其中:1)A={BC1t=A};2)B={};e)步骤“5”,应用程序B试图使用令牌A锁定设备。因为设备已经被令牌A锁定,而且使用的同样的令牌,平台允许该锁定请求。现在应用程序A和B共享设备BC1的锁。其中:1)A={BC1t=A};2)B={BC1t=A};f)步骤“6”,用户使用读设备BC1扫描条码。设备已经被令牌锁定,所有与此设备保持令牌锁的连接,都会收到有可用数据的通知。其中:1)A={BC1t=A};2)B={BC1t=A};g)步骤“7”,应用程序A试图从BC1读取数据。当数据返回到应用程序A时,平台清除BC1的数据。其中:1)A={BC1t=A};2)B={BC1t=A};h)步骤“8”,应用程序B试图从BC1读取数据。因为在步骤“7”中应用程序A的读取请求后已经清除了数据,所以返回结果中,并不包含读取到的数据;i)步骤“9”,应用程序A释放它对BC1的锁。其中:1)A={};2)B={BC1t=A};j)步骤“10”,用户使用读设备BC1扫描条码。设备已经被令牌锁锁定。所有与此设备保持令牌锁连接,都会收到有可用数据的通知,而此时只有应用程序B。其中:1)A={};2)B={BC1t=A};k)步骤“11”,应用程序B试图使用令牌A锁定BC1。因为应用程序B已经用令牌A锁定BC1,所以平台回复提示应用程序已经锁定该设备。其中:1)A={};2)B={BC1t=A};l)步骤“12”,应用程序B对BC1解锁。其中:1)A={};2)B={};m)步骤“13”,应用程序A使用连接锁锁定设备。其中:17 MH/T0048.2—20151)A={BC1*};2)B={};n)步骤“14”,应用程序B试图使用连接锁锁定BC1。因为应用程序A连接已经使用连接锁锁定该设备,所以平台拒绝了该请求。其中:1)A={BC1*};2)B={}。3.11.2设备锁定超时9)一旦应用程序锁定设备,平台为应用程序启动一个时长为DevLkdTime的计时器。如果定时器超时,设备连接仍没有I/O(Input/Output,输入输出)交互,则该应用程序对设备的锁定超时,平台立即向所有获得该设备连接的应用程序发送消息。锁定超时的示例参见附录A.2。3.11.3子设备锁定规则子设备锁定规则只适用于标准模式。当父设备被锁定时,从属于该父设备的子设备也被锁定。子设备锁定的示例参见图8~图12。其中应用程序A和B与平台通信,每个应用程序都要使用BG1设备或它的子设备BC1和DD1。假定所有图中每个应用程序和平台已成功连接到设备。应用程序A应用程序B平台11deviceAcquireRequestBG1deviceAcquireResponseBG122deviceAcquireRequestBC1deviceAcquireResponseBC133deviceAcquireRequestDD1deviceAcquireResponseDD14deviceAcquireRequestBC14deviceAcquireResponseBC15deviceAcquireRequestDD15deviceAcquireResponseDD1图8子设备锁定示例(1)9)见表3。18 MH/T0048.2—2015应用程序A应用程序B平台66deviceLockRequestBG1deviceLockResponseOK7deviceLockRequestBC17devicLockResponsedeviceLockeddeviceLockRequestBC188deviceLockResponseOKdeviceLockRequestDD199deviceLockResponseOK图9子设备锁定示例(2)应用程序A应用程序B平台10用户扫描条码10NotifydataAvaliableBC111readerReadRequestBC111readerReadResponseOK[data]readerCloseRequestBC11212readerCloseResponseOKdeviceUnlockRequestBC11313deviceUnlockResponseOKdeviceLockRequestBC11414deviceLockResponsedeviceLocked图10子设备锁定示例(3)19 MH/T0048.2—2015应用程序A应用程序B平台deviceUnlockRequestBG11515deviceUnlockResponseOKdeviceLockRequestBC11616deviceLockResponseOKdeviceLockRequestBG11717deviceLockResponsedeviceLockeddeviceUnlockRequestBC11818deviceUnlockResponseOKdeviceLockRequestBG11919deviceLockResponseOK图11子设备锁定示例(4)应用程序A应用程序B平台deviceLockRequestBG12020deviceLockResponseOK-deviceAlreadyLocked21deviceAcquireRequestDD121deviceLockResponseOK-deviceAlreadyLockeddeviceLockRequestBC12222deviceLockResponseOK图12子设备锁定示例(5)每个步骤如下所示:注:{}内为应用程序已经获取的锁,其中“*”代表显性锁,即设备被明确锁定;没有“*”代表隐性锁,即设备没有被明确锁定,但其父设备被锁定了。a)步骤“1”~“3”,应用程序A获得与设备BG1、BC1和DD1的连接。其中:1)A={};2)B={};b)步骤“4”~“5”,应用程序B获得与设备BC1、DD1的连接。其中:1)A={};2)B={};c)步骤“6”,应用程序A锁定设备BG1。因为BG1包含子设备,应用程序A的也会隐式地锁定其子设备DD1和BC1。其中:20 MH/T0048.2—20151)A={BG1*,BC1,DD1};2)B={}d)步骤“7”,应用程序B试图锁定BG1的子设备BC1。因为应用程序A已锁定了BG1及其子设备DD1和BC1,所以该锁定请求被拒绝。其中:1)A={BG1*,BC1,DD1};2)B={};e)步骤“8”~“9”,应用程序A显式地锁定BG1的子设备BC1和DD1。因为应用程序A已锁定BG1,因此该锁定请求不会出现错误。其中:1)A={BG1*,BC1*,DD1*};2)B={};f)步骤“10”,用户使用BG设备扫描条码。应用程序A持有BC1的锁,平台通过BC1的连接发送数据可用通知。其中:1)A={BG1*,BC1*,DD1*};2)B={};g)步骤“11”,应用程序A从平台读取条码数据。其中:1)A={BG1*,BC1*,DD1*};2)B={};h)步骤“12”,应用程序A关闭BC1的输入。应用程序A保持BG1及其所有子设备的锁定。其中:1)A={BG1*,BC1*,DD1*};2)B={};i)步骤“13”,应用程序A解锁BC1。因为应用程序A仍然持有BG1的锁,平台继续锁定BG1及其所有子设备。其中:1)A={BG1*,BC1,DD1*};2)B={};j)步骤“14”,应用程序B试图锁定BC1。因为应用程序A持有BG1和其所有子设备的锁,因此平台拒绝了该请求。其中:1)A={BG1*,BC1,DD1*};2)B={};k)步骤“15”,应用程序A解锁BG1。平台释放了BG1的锁,但是仍然保持对BG1子设备DD1的锁。在步骤(8-9),应用程序A显式锁定了BC1和DD1,但是在步骤“13”显式解锁了BC1。因此,应用程序A只持有一个DD1的锁。其中:1)A={DD1*};2)B={};l)步骤“16”,应用程序B试图锁定BC1,子设备BC1与父设备BG1均没有被锁定,因此平台通过了锁定申请。其中:1)A={DD1*};2)B={BC1*};m)步骤“17”,应用程序A试图锁定BG1。因为应用程序B拥有一个BG1子设备的锁,因此平台拒绝本次锁定尝试。其中:1)A={DD1*};2)B={BC1*};n)步骤“18”,应用程序B解锁BC1。其中:1)A={DD1*};21 MH/T0048.2—20152)B={};o)步骤“19”,应用程序A试图锁定BG1。因为BG1未锁定,而子设备已经被应用程序A锁定,与锁定BG1不冲突,所以平台准许了该请求。其中:1)A={BG1*,BC1,DD1*};2)B={};p)步骤“20”,应用程序A试图锁定BG1。因为应用程序A已经拥有一个BG1的显性锁,因此平台向应用程序A返回已经拥有锁定的通知。其中:1)A={BG1*,BC1,DD1*};2)B={};q)步骤“21”,应用程序A试图锁定DD1。因为应用程序A已经拥有一个DD1的显性锁,因此平台向应用程序A返回已经拥有锁定的通知。其中:1)A={BG1*,BC1,DD1*};2)B={};r)步骤“22”,应用程序A试图锁定BC1。因为应用程序A已经拥有一个BC1的隐性锁,因此平台并没有返回一个错误的通知,而返回了一个成功的结果。同步骤“8”~“9”的结果相同。其中:1)A={BG1*,BC1*,DD1*};2)B={}。3.12令牌3.12.1总则令牌由16个可打印的ASCII字符组成。令牌一般用于验证,作为密钥使用,可由平台或应用程序生成。在CUPPS交互消息中,令牌存储于节点。3.12.2平台生成令牌3.12.2.1本文件对平台生成令牌的方式不予规定,但平台生成的令牌应满足接口中关于节点的定义。3.12.2.2平台端定义的令牌应保证对所有应用程序的连接是唯一的且作为消息的一个属性提供给应用程序。3.12.3应用生成令牌3.12.3.1本文件对应用生成令牌的方式不予规定,但生成的令牌应满足接口中关于接口的定义。3.12.3.2应用生成的令牌分别为:——事件令牌:用于应用程序对事件的订阅。应用程序在发送消息时包含事件令牌属性。如果其他应用程序使用该令牌发送消息来订阅,则当该应用程序发生特定事件时,所有订阅过的应用程序都会收到平台对该事件的通知;如有一个特定的应用程序注册所有应用程序的事件,则这个特定的应用程序就可收到所有应用程序所发生的事件的通知;——安全令牌:用于获取日志。当应用程序使用ZL设备进行写操作时,应先发送包含安全令牌的消息,然后再往ZL设备进行写操作。如果应用程序要重新获取以前的日志信息,则应提供相应的令牌。22 MH/T0048.2—2015注:安全令牌是为了实现读写机制,写日志一方提供令牌,而读取日志的一方应提供一致的令牌。3.12.4设备查询应用程序应先通过消息获得设备令牌,才可使用平台进行设备查询服务。应用程序可根据条件查询相应的设备信息,表4给出了可用的查询条件。设备查询的示例见附录A.9。表4查询条件条件描述设备类型仅限于指定的设备类型附近设备仅限于附近的特定节点。该信息基于系统配置设备名称仅限于指定的设备名称3.12.5异常处理当开发人员捕获到运行时的异常时,应将其通过消息报告给系统管理员或其他人员进行处理,消息包含此异常信息,例如发生异常的用户、工作站、设备名称、应用程序名称等。消息的exceptionSource属性描述了异常是发生在平台还是在应用程序,arg属性提供具体的异常类型,例如空指针异常,主机连接异常等。消息正文提供发生异常时具体的异常信息。4数据交换接口消息处理规则4.1消息处理规则4.1.1平台端发送的请求和通知平台端可向应用程序发送消息和通知。示例参见附录A.3。示例1为平台向应用程序发送的通知,通知内容为设备有可读数据;示例2为平台向应用程序发送的通知,通知内容为设备的状态已改变。4.1.2非法消息处理4.1.2.1非法消息的判定可在消息交互的发送方,也可在接收方。消息交互需遵循特定的顺序,违反顺序的消息即为非法消息。当应用程序或平台发送非法消息时,产生事件消息。当接收端检查到非法消息时,使用Base64编码该非法消息,发送事件消息给接收端,并立即断开连接。4.1.2.2应用程序与平台交互时,如果应用程序与设备连接产生非法消息,则相关的设备令牌将失效,连接断开,应用程序需重新建立设备连接并重新进行设备的初始化操作。4.1.2.3在非法消息的回复中,应包含合法消息名称的完整列表。示例参见附录A.10。4.1.3连接Keep-Alive设置应用程序和平台之间的所有连接,应使用TCP层的Keep-Alive机制。示例为一个使用Keep-Alive的C语言示例。其他类型的语言,也应提供相似的调用,可根据实际的编程语言进行设置。示例:setsockopt()函数Keep-Alive设置//Settheoptiontoonintoptval=1;setsockopt(sock,SOL_SOCKET,SO_KEEPALIVE,&optval,sizeof(optval));23 MH/T0048.2—20154.1.4流错误和解析错误应用程序应确保传输到平台的消息是合法的XML消息。应用程序和平台通信时错误流的处理流程见图13。图13流错误示例在图13中:——在Time(0)之前,应用程序向平台发送一个消息。在这个示例中,该消息是一个设备命令;——在Time(0),平台确认接收到的消息是否完整,即是否产生了流错误。如果发生流错误,则返回应用程序流错误消息,关闭连接。应用程序应根据需要重新建立连接;——在Time(1),平台使用应用程序已经选择的接口版本对接收的消息进行解析。如果发生XML解析错误,则给应用程序返回一个XML解析错误消息,并关闭连接。应用程序应根据需要重新建立连接;——在Time(2),没有发生流错误或XML解析错误。如果检测到一个设备事件,应将该设备事件的通知实时发送给应用程序。4.1.5messageID处理逻辑在应用程序与平台的交互中,请求与应答消息的messageID应一致。针对每个连接,平台和应用都10)应保留最近发送或接收的消息清单,这个清单的长度为MsgIDListLen。应用程序发起消息的messageID10)见表3。24 MH/T0048.2—201511)12)13)范围为MinMessageID至MinPlatformMsgID。平台端发起消息的messageID范围为MinPlatformMsgID14)至MaxMessageID。发送消息的messageID取值为上一条发送消息的ID值加1。当应用程序发起的messageID到达15)16)17)MinPlatformMsgID-1时,重置为MinMessageID。当平台发起的messageID到达MaxMessageID时,重18)置为MinPlatformMsgID。应用程序和平台之间的每个连接都使用自己的messageID顺序。一个连接上的messageID与其它连接的messageID无关。处理messageID的流程见图14。响应,是OK接收消息响应,否非法通知,是重复消息类型与消息ID是否在列表中通知,否OK请求,是重复请求,否ID是否在合法范围No越界内是Ok图14messageID的处理流程在图14中:——如果消息为响应消息,则messageID应已在最近处理的messageID列表里,其中:如果在列表中找到该messageID,则该消息可继续做处理;如果在列表中没找到该messageID,则发送一个,由消息的接收方断开连接;——如果消息为通知,则messageID应不在该列表中,其中:11)见表3。12)见表3。13)见表3。14)见表3。15)见表3。16)见表3。17)见表3。18)见表3。25 MH/T0048.2—2015如果在列表中找到该messageID,则发送一个,由消息的接收方断开连接;如果在列表中没有找到该messageID,则该消息可继续做处理;——如果该消息为请求,则messageID应不在该列表中。其中:如果在列表中找到该messageID,则发送一个,由消息的接收方断开连接;如果messageID不在该列表中,则检查messageID是否在有效范围内。如果该messageID在有效范围之外,则发送一个,由消息的接收方断开连接。发送方的messageID值应为上一次messageID值加1。4.2接口状态机4.2.1状态机的状态接口状态机的四种状态见图15,分别为:——启动状态,表示应用程序和平台之间接口实例的启动。在启动阶段,平台可重定向与应用程序的连接。因此,该图给出了绕过设备和平台使用直接进入退出状态的一条连接;——设备使用状态,表示与设备相关的接口正在被使用;——平台使用状态,表示与设备无关的接口正在被使用;——退出状态,表示一个接口实例退出。图15接口状态机4.2.2启动状态4.2.2.1接口状态机的启动状态见图16。在接口实例启动时,应用程序设置接口版本并进行平台认证。26 MH/T0048.2—2015图16接口状态机的启动状态4.2.2.2接口启动时,进入接口版本选择状态。应用程序在该状态内,确认选择适当的接口版本,随后发送或者消息。4.2.2.3一旦设置接口版本,该连接应被认证。如果该连接与平台的管理部分(例如:非设备相关的功能)进行通信,则发送消息。如果该连接与设备进行通信,则发送消息。4.2.2.4当应用程序接收到消息时,首先解析该消息判断是否包含redirect元素。如果包含,则该状态机将立即进入重定向状态。4.2.3设备使用状态及模式4.2.3.1设备使用状态接口状态机的设备使用状态见图17。一旦应用程序获得设备连接,应先设置接口模式来管理与设备之间的通信,然后设备进入相应的模式。图17接口状态机的设备使用状态4.2.3.2模式4.2.3.2.1标准模式标准模式管理读设备、打印设备。读设备状态见图18。接口首先进入未锁定状态。应用程序应先锁定该设备,才能进行与该设备的交互。如果应用程序从设备读取数据,应先锁定该设备。当结束使用设备时,应解锁并释放这个设备。打印设备状态见图19。接口等待应用程序发送消息来进行各种操作。27 MH/T0048.2—2015图18读设备状态图19打印设备状态4.2.3.2.2AEA模式AEA(AssociationofEuropeanAirlines)模式见图20。在AEA模式状态下,平台端等待应用程序发送消息来进行各种操作。当应用程序发送时,退出AEA模式状态。图20AEA模式4.2.3.2.3特殊设备模式特殊设备模式见图21,包括:——日志设备ZL;——IATA(InternationalAirTransportAssociation,国际航空运输协会)消息设备ZI。特殊设备模式不支持锁定。试图锁定或解锁特殊设备会产生消息。28 MH/T0048.2—2015ZL设备ZI设备图21特殊设备模式ZL设备为应用程序提供日志记录接口。应用程序可使用该设备进行打开、关闭、读写等操作。图22为ZL设备的接口状态机。应用程序操作设备之前应发送打开ZL设备。当应用程序完成对设备的操作时,使用关闭该设备。图22ZL设备ZI设备为应用程序和平台之间交换IATA定义的或应用程序需要向平台发送的消息提供了一个标准接口,例如旅客信息报文及安检报文。平台可将应用程序发来的消息转发给机场端的特定系统,例如应用程序可通过ZI设备,将BSM(BaggageSourceMessage,行李报文信息)报文发送给平台端,平台端将BSM报文转发给行李分拣系统。本标准不规定平台与机场端特定系统的交互标准。图23给出了用于ZI设备的接口状态机。平台端等待应用程序发送消息进行各种操作。图23ZI设备4.2.3.2.4其他模式其他模式与读设备模式类似,见图24。接口首先进入未锁定状态。应用程序应锁定该设备后,才能进行进一步与该设备的交互。29 MH/T0048.2—2015图24其他模式4.2.4平台使用状态平台启动时等待事件到来,事件触发时,接口状态机进入平台使用状态(见图25)。根据事件内容的不同,平台使用状态包括以下状态:——警报状态:管理订阅事件的发布,可向工作站发送警报信息;——通知状态:表示平台向应用程序发送特定的通知;——平台引导应用程序退出状态:表示平台端发起的应用程序处于退出状态;——应用程序退出状态:表示应用程序端发起的应用程序处于退出状态。图25接口状态机-平台使用30 MH/T0048.2—20154.2.5退出状态19)20)退出状态表示连接被关闭。如果连接在一段时间AppSpgTime(平台连接)或者DevSpgTime(设备连接)内没有被关闭,该连接将被平台关闭。19)见表3。20)见表3。31 MH/T0048.2—2015AA附录A(资料性附录)数据交换接口及消息处理示例A.1会话连接序列图图A.1为一个基本的会话连接序列图原型。图中:a)在时间“0”时,应用程序连接到平台;b)在时间“1”时,应用程序向平台发送消息,平台在接收到该消息后返回消息。在此过程中,任何流错误都将导致会话中断,任何解析错误都会引起XML(ExteileMarkuLaguage,扩展性标识语言)解析错误流程处理;c)在时间“2”时,应用程序向平台发送消息请求可用接口版本,该消息包含接口版本。该平台通过确认版本的选择;d)在时间“3”时,应用程序和平台根据需要进行消息交互。交互的第一条消息应是身份认证。对于平台的连接,应用程序使用进行身份认证,并获取设备令牌。对于设备的连接,应用程序使用包含令牌信息的进行认证,并建立到设备的逻辑连接;e)在时间“4”,应用程序通过发送通知平台即将终止会话。与应用程序相关联的设备令牌立即失效。平台回复确认。平台会保持会话连接打开,并等待应用程序断开会话连接;f)在时间“5”,应用程序关闭TCP连接。应用程序平台TCPConnect00interfaceLevelsAvailableRequest11interfaceLevelsAvailableResponseinterfaceLevelRequest22interfaceLevelResponse3...平台使用...3byeRequest44byeResponseTCPDisconnect55图A.1平台会话序列原型32 MH/T0048.2—2015A.2锁定超时图A.2为一个锁定超时的示例。应用程序A应用程序B应用程序C平台1deviceLockRequest1deviceLockResponse22DevLkdTime3deviceLockExpiredEvent3deviceLockExpiredEventdeviceLockExpiredEvent图A.2锁定超时在图A.2中:——步骤“1”之前,假设三个应用程序A、B和C已成功获取设备连接;——步骤“1”,应用程序C锁定设备;21)——步骤“2”,经过时长DevLkdTime,应用程序C与该设备的连接没有活动;——步骤“3”,平台通知所有已获得该设备连接的应用程序,包括应用程序C;——步骤“3”之后,所有已获取设备连接的应用程序,即应用程序A、B和C,都可尝试锁定设备或经允许后使用该设备。A.3平台端向应用程序发送通知示例1和示例2为平台向应用程序发送通知的例子,其中示例1中通知内容为设备有可读数据,示例2中通知内容为设备的状态已改变。示例1:21)自表3。33 MH/T0048.2—2015示例2:A.4应用程序向平台请求可用接口版本列表示例1为应用程序向平台请求可用接口版本列表。示例2为平台响应应用程序请求的回复。示例1:示例2:34 MH/T0048.2—2015A.5应用程序选择接口版本示例1为一个应用程序选择接口版本01.03的例子,示例2为平台确认接口版本请求的一个例子。示例1:示例2:A.6与平台断开连接示例1为与平台断开连接的请求消息,示例2为与平台断开连接的回复消息消息。示例1:示例2:35 MH/T0048.2—2015A.7应用退出策略示例1为,示例2为。示例1:示例2:A.8应用程序认证示例1以汉莎航空公司为例,消息中包含多个应用程序的应用程序列表并包含了01.02版本的LHABC以及02.03版本的LHABD应用。示例2为认证回复。示例1:36 MH/T0048.2—2015示例2:37 MH/T0048.2—201538 MH/T0048.2—201540 MH/T0048.2—2015A.9设备查询示例1为消息的一个例子,示例2为消息的一个例子。示例1:示例2:A.10非法消息示例为一个非法消息的例子,expectedMessageNameList属性包含所有合法的消息名称。示例:PD94bWwgdmVyc2lvbj0iMS4wIj8+DQo8Y3VwcHMgeG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSIgeG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgbWVzc2FnZU5hbWU9ImF1dGhlbnRpY2F0ZVJlcXVlc3QiIG1lc3NhZ2VJRD0iNCIgeG1sbnM9Imh0dHA6Ly93d3cuY3VwcHMuYWVyby9jdXBwcy8wMS4wMyI+DQogIDxhdXRoZW50aWNhdGVSZXF1ZXN0IGFpcmxpbmU9IkxIIiBldmVudFRva2VuPSJBM0c2Q0o4TDNKOU0xRExIIiBwbGF0Zm9ybURlZmluZWRQYXJhbWV0ZXI9IkFCS0Q3OERGM0s6MjUzMzQ7YXNkPSI+DQogICAgPGFwcGxpY2F0aW9uTGlzdD4NCiAgICAgIDxhcHBsaWNhdGlvbiBhcHBsaWNhdGlvbk5hbWU9IkxIQUJDIiBhcHBsaWNhdGlvblZlcnNpb249IjAxLjAyIiAvPg0KICAgICAgPGFwcGxpY2F0aW9uIGFwcGxpY2F0aW9uTmFt42 MH/T0048.2—2015ZT0iTEhBQkQiIGFwcGxpY2F0aW9uVmVyc2lvbj0iMDIuMDMiIGFwcGxpY2F0aW9uRGF0YT0icHJpbnRlciBpbnRlcmZhY2UiIC8+DQogICAgPC9hcHBsaWNhdGlvbkxpc3Q+DQogIDwvYXV0aGVudGljYXRlUmVxdWVzdD4NCjwvY3VwcHM+_________________________________43'

您可能关注的文档