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

ICS35.240.60

V07

MH

中华人民共和国民用航空行业标准

MH/T0048.2—2015

民用机场共用旅客处理系统技术规范

第2部分：应用软件数据交换

Specificationofcommonusepassengerprocessingsystemsincivilaviationairports

Part2：Interfacebetweenapplications

2015-09-30发布2015-12-01实施

中国民用航空局发布

MH/T0048.2—2015

目次

前言................................................................................II

1范围..............................................................................1

2术语和定义........................................................................1

3数据交换接口通用标准..............................................................1

4数据交换接口消息处理规则.........................................................23

附录A（资料性附录）数据交换接口及消息处理示例.....................................32

I

MH/T0048.2—2015

前言

MH/T0048分为以下三个部分：

——第1部分：系统结构；

——第2部分：应用软件数据交换；

——第3部分：硬件设备数据交换。

本部分为MH/T0048的第2部分。

本部分按照GB/T1.1-2009给出的规则起草。

本部分由中国民用航空局人教司提出。

本部分由中国民用航空局航空器适航审定司批准立项。

本部分由中国民航科学技术研究院归口。

本部分起草单位：中国民航大学、中国民航信息网络股份有限公司。

本部分主要起草人：李建伏、孙皓、贺怀清、张博、惠康华、丁玎、徐涛、武佳、孙启玲、李斌。

MH

II

MH/T0048.2—2015

民用机场共用旅客处理系统技术规范

第2部分：应用软件数据交换

1范围

MH/T0048的本部分规定了共用旅客处理系统的应用软件与管理平台之间数据交换接口技术规范。

本部分适用于中国民用机场共用旅客处理系统的建设。

2术语和定义

2.1

共用旅客处理系统CUPPSCommonUsePassengerProcessingSystems

由国际航协定义，用于航空公司使用机场的终端设备的信息处理规范。

[MH/T0048.1-2014中的3.1]

2.2

CUPPS工作站CUPPSWorkstation

运行于CUPPS平台上的硬件和操作系统软件。硬件包括计算机、移动终端设备、智能手机、简易客

户终端等。

[MH/T0048.1-2014中的3.2]

2.3

CUPPS应用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获取逻辑设

MH备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会话消息需通过已选择的接口版本的校验。如果校验失败，则触发<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地址。

3.5会话原则

3.5.1会话流程

应用程序和平台之间的会话流程图如图2所示，主要包括以下几个步骤：

3

MH/T0048.2—2015

a)平台监听一个已知的节点和端口；

b)应用程序连接到平台的相应节点和端口。在连接时，应用程序向平台发出可用接口版本列表请

求，平台收到请求后返回可用接口列表；

c)应用程序向平台发送期望使用的接口版本。该接口版本经平台确认后，将用于后续会话消息的

验证；

d)平台验证应用程序的合法性，并返回验证结果。如果验证成功，则应在验证结果中包含令牌信

息。该令牌信息应用于所有后续通信以及验证设备连接。当平台连接关闭后，令牌失效，基于

此令牌的连接也应立即断开；

e)应用程序使用已定义消息集与平台进行通信。对于每个设备会话，应用程序在断开连接之前，

均应发送<deviceReleaseRequest>并获得平台对应的响应；

f)应用程序断开。当应用程序关闭时，应向平台发送<byeRequest>消息，获取<byeResponse>消

息后方可断开连接。

建立连接

重定向设置接口版本

认证

使用

断开连接

图2会话流程

基本的会话连接序列图原型参见附录A.1。

3.5.2消息处理流程

建立连接后,当接收端收到消息时，应判断消息流的合法性。

消息从接收到处理的流程见图3。处理流程如下：

a)接收端逐字节地读取消息头：如果接收端读取到无效字符，则接收端立即停止读取，发送

<sessionErrorEvent>的通知，并在该通知中包含信息eventType=“headerVersion”，随后

关闭连接。如果接收端读取的消息长度越界，则接收端发送<sessionErrorEvent>的通知，并

包含信息eventType=“headerLength”，随后关闭连接。如果读取消息头超时，则接收端发

送<sessionErrorEvent>的通知，并包含信息eventType=“headerTimeout”，随后关闭连接；

b)读取消息体：消息头中包含消息体的长度，如果在读取这个指定长度的消息体时超时，接收端

MH发送<sessionErrorEvent>的通知，其中包含信息eventType=”bodyTimeout”，随后关闭连接；

4

MH/T0048.2—2015

c)解析消息体：如果接收端无法使用选定的接口版本解析消息体，则接收端发送

<sessionErrorEvent>的通知，其中包含信息eventType=“bodyParseFailure”，随后关闭连接；

d)处理经过解析的信息。

sessionErrorEvent

headerVersion

sessionErrorEvent

读取消息头

headerLength

sessionErrorEvent

断开连接

headerTimeout

sessionErrorEvent

读取消息体

bodyTimeout

sessionErrorEvent

解析消息体

bodyParseFailure

处理消息

图3平台消息处理流程

3.5.3应用程序认证

一旦应用程序连接到平台并且选择好接口版本，则该应用程序应向平台请求认证。如果应用

程序未能通过认证，则平台应断开与该应用程序的连接。

应用程序认证分为两步：

a)应用程序向平台发送<authenticateRequest>消息请求认证；

b)平台记录应用程序的认证请求，回复<authenticateResponse>消息。该消息应包含以下信息：

1)设备令牌：用于后续设备交互操作；

2)平台参数：平台供应商ID和版本信息以用于日志记录；

3)支持的加密算法列表；

4)应用程序参数：局部存储、局部临时存储以及永久性全局存储地址；

5)工作站参数：工作站的名字、厂商信息、平台的配置信息、操作系统默认的打印机名称等；

6)设备分配列表(样品)；

7)特殊模式接口，ZI(IATAmessagesoftwaredevice，IATA信息设备)和ZL（logging

softwaredevice，日志设备）都是被指定的。

应用程序认证请求与回复的消息示例参见附录A.8。

3.5.4应用程序主动与平台断开连接

5

MH/T0048.2—2015

应用程序与平台端口断开连接之前，应向平台发送<byeRequest>消息以通知平台方应用程序

将要断开连接。平台端接收到<byeRequest>消息后，回复<byeResponse>消息，并等待应用程序断开连

接。附录A.6为与平台断开连接的示例。

应用程序发送<byeRequest>消息后，平台端将该应用程序设置为aSpg状态，不允许该应用程

序继续向平台发送其他消息。如果该应用程序在aSpg状态试图发送消息，平台记录

<sessionErrorEvent>事件。

平台接收<byeRequest>后，等待应用程序断开连接,且不能向应用程序发送其他消息。如果在

PltSockMaxIdleTime1)后，该应用程序仍未断开，平台应作相应日志记录，然后断开该连接。

3.5.5平台端发起的应用程序正常退出机制

本部分仅规范了应用程序的正常退出机制，应用程序的异常退出机制见本标准第1部分的

9.1.8。

平台端可通过发送特定的指令断开应用程序连接。断开连接的形式有两种，即请求方式与控

制方式)。

请求方式通过平台向应用程序发送指令停止应用程序。在接收到平台的停止指令后，应用程

序应关闭与设备的连接、记录日志、通知用户应用程序正在退出，并最终关闭与平台的连接。此过程应

在AppSpgTime2)时间内完成，如果需要更多的时间退出应用程序，最多可增加MaxSpgDegerTimes3)次延

迟退出的请求。

控制方式通过平台端执行指令停止应用程序。在这种情况下，应用程序被置为aSpg状态，如

果应用程序退出时长超过了AppSpgTime4)，应用程序将会进入aZom状态并被强制清除。

图4给出了平台端发起的应用程序正常退出的四种情况：

a)平台允许应用程序延迟退出，但应用程序不需要延迟的情况，分为：

1)步骤“1”，平台请求应用程序停止；

2)步骤“2”，应用程序回复可以退出。平台立即使分配给该应用程序的设备令牌失效；

3)步骤“3”，应用程序关闭与平台的连接，然后退出程序。

b)平台允许应用程序延迟退出，且应用程序需要延迟的情况，分为：

1)步骤“1”，平台请求应用程序停止。应用程序回复平台需要延迟退出。平台重置应用退

出计时器AppSpgTime5)；

2)步骤“2”，应用退出计时器超时，平台继续向应用程序发送停止请求。应用程序回复延

迟退出。平台重置应用退出计时器；

1)见表3。

2)见表3。

3)见表3。

4)见表3。

MH5)见表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—2015

3)步骤“3”，应用程序关闭平台的连接并且终止。

d)平台不允许应用程序延迟退出，但应用程序需要延迟的情况。分为：

1)步骤“1”，平台请求应用程序停止，并将应用程序置为aSpg状态，应用程序回复平台需

要延迟退出；

2)步骤“2”，平台关闭连接并且将应用程序置为aZom状态，然后断开与应用程序的连接并

释放相关的所有资源。

应用停止指令请求的消息示例参见附录A.7。

应用程序A平台

1ApplicationStopRequestcanDefer=“false”1

2applicationStopResponseresult=“OK”2

3[TCPclose]3

(c)

应用程序A平台

1ApplicationStopRequestcanDefer=“false”1

ApplicationStopResponseresult=“defer”

22

ApplicationStopRequestcanDefer=“false”

[TCPclose]

(d)

图4(续)

3.6平台令牌失效和设备会话失效

3.6.1应用程序在使用平台期间，应和平台保持连接。如果应用程序与平台的连接中断，与该连接相

对应的设备令牌应立即失效。如果应用程序使用<byeRequest>要求终止与平台的连接，则其设备令牌也

应失效。MH

8

MH/T0048.2—2015

3.6.2使用失效令牌的设备连接是无效的。失效的设备会话在PltSockMaxIdleTime6)内依然保持连接

状态。在此期间，不允许再往这个连接上发送消息。如果应用程序试图在无效会话上发送信息，则平台

认为该消息是非法消息并回复。

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版本消息头向发送方回复错误信息，并终止

该会话。

3.7.4消息头版本01定义最大消息长度，即PltMaxMsgSize7)字节(大约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.0100000013<CUPPS>body</CUPPS>

2.01...........................[消息头版本01]

3.00000013...................[消息体长度为19个字节]

4.<CUPPS>body</CUPPS>[消息体]

3.8流协议

6)见表3。

7)见表3。

9

MH/T0048.2—2015

3.8.1CUPPS连接使用简单标准流协议传输UTF8编码的XML信息。每个消息均以消息头开始，按字节

从流中读取。

3.8.2图5和图6分别为接口发送和接收消息状态机，消息读取端应按字节读取数据。消息接收的最

大时长为PltStreamAccumTime8)。

3.8.3当从连接中读取消息头时，接收方应按位读取，一旦碰上无效字符，则立即停止读取。

准备发送消息

计算长度前缀

发送消息头

传输

超时连接丢失

传输完成

发送消息体

传输

关闭连接超时连接丢失连接丢失

传输完成

图5消息发送状态机

MH8)见表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开始：<deviceAcquireRequest>完

的最大时<deviceAcquireRequest>消全被接收的时刻；结束：

长息的最大时长<deviceAcquireResponse>完全被

发送出去的时刻

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开始：平台接收到

的最大时<deviceLockRequest>消息的<deviceLockRequest>的时刻；

长最大时长结束：平台返回

<deviceLockResponse>的时刻

MaxDevStsTime获取设备平台处理5.0s开始：平台接收到

状态的最<deviceStatusRequest>消息<deviceStatusRequest>的时刻；结

大时长的最大时长束：平台返回

<deviceStatusResponse>的时刻

MH

12

MH/T0048.2—2015

表3(续)

参数定义功能描述建议值时间跨度

MaxDevUnlTime解锁设备的最大平台处理2.0s开始：平台接收到

时长<deviceUnlockRequest><deviceUnlockRequest>的时

消息的最大时长刻；结束：平台返回

<deviceUnlockResponse>的时

刻

MaxMessageID平台消息ID的最平台端发起消息的最大ID0xffffffff

大值值

MaxSpgDeferTimes推迟停止的最大应用程序推迟关闭的最大4次

次数次数

MinMessageID消息ID的最小值应用程序端发起消息的最0x00000001