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

ICS35.240.60V07MH中华人民共和国民用航空行业标准MH/T0048.2—2015民用机场共用旅客处理系统技术规范第2部分：应用软件数据交换SpecificationofcommonusepassengerprocessingsystemsincivilaviationairportsPart2：Interfacebetweenapplications2015-09-30发布2015-12-01实施中国民用航空局发布MH/T0048.2—2015I目次前言................................................................................II1范围..............................................................................12术语和定义........................................................................13数据交换接口通用标准..............................................................14数据交换接口消息处理规则.........................................................23附录A（资料性附录）数据交换接口及消息处理示例.....................................32MH/T0048.2—2015II前言MH/T0048分为以下三个部分：——第1部分：系统结构；——第2部分：应用软件数据交换；——第3部分：硬件设备数据交换。本部分为MH/T0048的第2部分。本部分按照GB/T1.1-2009给出的规则起草。本部分由中国民用航空局人教司提出。本部分由中国民用航空局航空器适航审定司批准立项。本部分由中国民航科学技术研究院归口。本部分起草单位：中国民航大学、中国民航信息网络股份有限公司。本部分主要起草人：李建伏、孙皓、贺怀清、张博、惠康华、丁玎、徐涛、武佳、孙启玲、李斌。MHMH/T0048.2—20151民用机场共用旅客处理系统技术规范第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。MH/T0048.2—20152图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。其中，所有的逻辑设备是通过一个多功能物理设MHMH/T0048.2—20153备来实现。注：应用程序通过设备的名称和接口访问设备，与设备所在位置无关，名称和接口都由环境变量指定。应用程序不能推理出平台组件的任何特定实现方法，以及设备与平台连接的任何特定物理实现方法。3.2接口状态CUPPS接口的不同状态如表1所示。在生产环境中，如果应用程序试图使用支持状态之外的接口，平台应记录相应的信息供管理员审查，并触发警报。表1CUPPS接口状态状态描述提出接口已经被提出，但是还没计划计划接口正在计划中开发接口处于实验性测试状态，不能在生产环境中使用支持接口处于正常的生产状态不建议接口仍然被支持，但不推荐使用。该接口即将进入过时状态。在生产过程中对该接口的任何使用，都将产生一个警告，且被平台记录下来废弃接口不再被支持。在生产中任何试图使用这种接口的行为都产生一个错误3.3接口版本3.3.1在每个单独的TCP(TransmissionControlProtocol传输控制协议)端口上的平台和设备端应同时支持多个版本的CUPPS接口。当应用程序连接到CUPPS平台后，首先应请求得到该平台支持的接口版本列表，然后从获取的接口版本列表中选择一个版本进行后续的会话。3.3.2会话消息需通过已选择的接口版本的校验。如果校验失败，则触发sessionErrorEvent消息，并立即关闭该会话。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所示，主要包括以下几个步骤：MH/T0048.2—20154a)平台监听一个已知的节点和端口；b)应用程序连接到平台的相应节点和端口。在连接时，应用程序向平台发出可用接口版本列表请求，平台收到请求后返回可用接口列表；c)应用程序向平台发送期望使用的接口版本。该接口版本经平台确认后，将用于后续会话消息的验证；d)平台验证应用程序的合法性，并返回验证结果。如果验证成功，则应在验证结果中包含令牌信息。该令牌信息应用于所有后续通信以及验证设备连接。当平台连接关闭后，令牌失效，基于此令牌的连接也应立即断开；e)应用程序使用已定义消息集与平台进行通信。对于每个设备会话，应用程序在断开连接之前，均应发送deviceReleaseRequest并获得平台对应的响应；f)应用程序断开。当应用程序关闭时，应向平台发送byeRequest消息，获取byeResponse消息后方可断开连接。建立连接设置接口版本认证使用断开连接重定向图2会话流程基本的会话连接序列图原型参见附录A.1。3.5.2消息处理流程3.5.2.1建立连接后,当接收端收到消息时，应判断消息流的合法性。3.5.2.2消息从接收到处理的流程见图3。处理流程如下：a)接收端逐字节地读取消息头：如果接收端读取到无效字符，则接收端立即停止读取，发送sessionErrorEvent的通知，并在该通知中包含信息eventType=“headerVersion”，随后关闭连接。如果接收端读取的消息长度越界，则接收端发送sessionErrorEvent的通知，并包含信息eventType=“headerLength”，随后关闭连接。如果读取消息头超时，则接收端发送sessionErrorEvent的通知，并包含信息eventType=“headerTimeout”，随后关闭连接；b)读取消息体：消息头中包含消息体的长度，如果在读取这个指定长度的消息体时超时，接收端发送sessionErrorEvent的通知，其中包含信息eventType=”bodyTimeout”，随后关闭连接；MHMH/T0048.2—20155c)解析消息体：如果接收端无法使用选定的接口版本解析消息体，则接收端发送sessionErrorEvent的通知，其中包含信息eventType=“bodyParseFailure”，随后关闭连接；d)处理经过解析的信息。sessionErrorEventheaderVersionsessionErrorEventheaderLengthsessionErrorEventheaderTimeoutsessionErrorEventbodyTimeoutsessionErrorEventbodyParseFailure读取消息头读取消息体解析消息体处理消息断开连接图3平台消息处理流程3.5.3应用程序认证3.5.3.1一旦应用程序连接到平台并且选择好接口版本，则该应用程序应向平台请求认证。如果应用程序未能通过认证，则平台应断开与该应用程序的连接。3.5.3.2应用程序认证分为两步：a)应用程序向平台发送authenticateRequest消息请求认证；b)平台记录应用程序的认证请求，回复authenticateResponse消息。该消息应包含以下信息：1)设备令牌：用于后续设备交互操作；2)平台参数：平台供应商ID和版本信息以用于日志记录；3)支持的加密算法列表；4)应用程序参数：局部存储、局部临时存储以及永久性全局存储地址；5)工作站参数：工作站的名字、厂商信息、平台的配置信息、操作系统默认的打印机名称等；6)设备分配列表(样品)；7)特殊模式接口，ZI(IATAmessagesoftwaredevice，IATA信息设备)和ZL（loggingsoftwaredevice，日志设备）都是被指定的。应用程序认证请求与回复的消息示例参见附录A.8。3.5.4应用程序主动与平台断开连接MH/T0048.2—201563.5.4.1应用程序与平台端口断开连接之前，应向平台发送byeRequest消息以通知平台方应用程序将要断开连接。平台端接收到byeRequest消息后，回复byeResponse消息，并等待应用程序断开连接。附录A.6为与平台断开连接的示例。3.5.4.2应用程序发送byeRequest消息后，平台端将该应用程序设置为aSpg状态，不允许该应用程序继续向平台发送其他消息。如果该应用程序在aSpg状态试图发送消息，平台记录sessionErrorEvent事件。3.5.4.3平台接收byeRequest后，等待应用程序断开连接,且不能向应用程序发送其他消息。如果在PltSockMaxIdleTime1)后，该应用程序仍未断开，平台应作相应日志记录，然后断开该连接。3.5.5平台端发起的应用程序正常退出机制3.5.5.1本部分仅规范了应用程序的正常退出机制，应用程序的异常退出机制见本标准第1部分的9.1.8。3.5.5.2平台端可通过发送特定的指令断开应用程序连接。断开连接的形式有两种，即请求方式与控制方式)。3.5.5.