1、ICS 35.240.60 V 07 MH 中华人民共和国民用航空行业标准 MH/T 0048.22015 民用机场共用旅客处理系统技术规范 第 2部分：应用软件数据交换 Specification of common use passenger processing systems in civil aviation airportsPart 2： Interface between applications 2015 - 09 - 30发布 2015 - 12 - 01实施中国民用航空局 发布MH/T 0048.22015 I 目 次 前言 . . II 1 范围 . . 1 2 术语和定
2、义 . . 1 3 数据交换 接口通用标准 . . 1 4 数据交换 接口消息处理规则 . . 23 附录 A（资料性附录） 数据交换接口及消息处理示例 . 32 MH/T 0048.22015 II 前 言 MH/T 0048分为以下三个部分： 第 1 部分：系统结构； 第 2 部分：应用软件数据交换； 第 3 部分：硬件设备数据交换。 本部分为MH/T 0048的第2部分。 本部分按照GB/T 1.1-2009给出的规则起草。 本部分由中国民用航空局人教司提出。 本部分由中国民用航空局航空器适航审定司批准立项。 本部分由中国民航科学技术研究院归口。 本部分起草单位：中国民航大学、中国民航信
3、息网络股份有限公司。 本部分主要起草人：李建伏、孙皓、贺怀清、张博、惠康华、丁玎、徐涛、武佳、孙启玲、李斌。 MHMH/T 0048.22015 1 民用机场共用旅客处理系统技术规范 第 2部分：应用软件数据交换 1 范围 MH/T 0048的本部分规定了共用旅客处理系统的应用软件与管理平台之间数据交换接口技术规范。 本部分适用于中国民用机场共用旅客处理系统的建设。 2 术语和定义 2.1 共用旅客处理系统 CUPPS Common Use Passenger Processing Systems 由国际航协定义，用于航空公司使用机场的终端设备的信息处理规范。 MH/T 0048.1-2014
4、中的3.1 2.2 CUPPS工作站 CUPPS Workstation 运行于CUPPS平台上的硬件和操作系统软件。硬件包括计算机、移动终端设备、智能手机、简易客户终端等。 MH/T0048.1-2014中的3.2 2.3 CUPPS应用 CUPPS Application 运行在CUPPS平台上，使用CUPPS平台接口的应用程序。 MH/T 0048.1-2014中的3.3 3 数据交换接口通用标准 3.1 平台架构 平台管理所有连接到平台的请求，并为这些连接提供标准接口来访问机场资源和其他系统。 平台可使用多种体系架构，见图1。 MH/T 0048.22015 2 图1 平台架构 平台架
5、构由以下组成，应用程序1使用设备1和2，应用程序2使用设备1，应用程序3使用设备3： (a)实现架构：表示在该平台上应用程序通过一个节点(节点 1)连接到所有设备，每个逻辑设备由一个独立的物理设备实现； (b)实现架构：表示在该平台上应用程序通过两个节点(节点 1 和2)连接到设备，节点 1 提供了物理设备 1 的逻辑接口。节点 2 为一个多功能物理设备提供逻辑接口； (c)实现架构：表示在该平台上，应用程序首先连接到节点 1，该节点提供了一个逻辑分配机制，使应用程序可重定向到其他节点。当应用程序 1 连接到平台上的节点 1 获取逻辑设备 1和 2 时，该平台分别将应用程序 1重定向到节点 2
6、 和3；当应用 2 连接到平台上的节点 1 获取逻辑设备 2时，该平台将应用 2 重定向到节点 3；当应用 3连接到平台上的节点 1获取逻辑设备 3，该平台将应用程序 3 重定向到节点 4。其中，所有的逻辑设备是通过一个多功能物理设MHMH/T 0048.22015 3 备来实现。 注： 应用程序通过设备的名称和接口访问设备，与设备所在位置无关，名称和接口都由环境变量指定。应用程序不能推理出平台组件的任何特定实现方法，以及设备与平台连接的任何特定物理实现方法。 3.2 接口状态 CUPPS接口的不同状态如表1所示。 在生产环境中， 如果应用程序试图使用支持状态之外的接口， 平台应记录相应的信息
7、供管理员审查，并触发警报。 表1 CUPPS接口状态 状态 描述 提出 接口已经被提出，但是还没计划 计划 接口正在计划中 开发 接口处于实验性测试状态，不能在生产环境中使用 支持 接口处于正常的生产状态 不建议 接口仍然被支持，但不推荐使用。该接口即将进入过时状态。在生产过程中对该接口的任何使用，都将产生一个警告，且被平台记录下来 废弃 接口不再被支持。在生产中任何试图使用这种接口的行为都产生一个错误 3.3 接口版本 3.3.1 在每个单独的 TCP(Transmission Control Protocol 传输控制协议)端口上的平台和设备端应同时支持多个版本的 CUPPS 接口。当应用
8、程序连接到 CUPPS 平台后，首先应请求得到该平台支持的接口版本列表，然后从获取的接口版本列表中选择一个版本进行后续的会话。 3.3.2 会话消息需通过已选择的接口版本的校验。如果校验失败，则触发消息，并立即关闭该会话。 3.3.3 如果应用程序在版本列表中没有找到支持的接口，应用程序应做以下处理： a) 记录错误； b) 发送一个错误事件； c) 通知终端用户。终端用户根据提示信息，咨询相应的技术支持人员。 所有的 CUPPS 接口都遵守一套通用的基本规则。所有 CUPPS 接口应使用 TCP 套接字，消息交换内容应符合已定义 XSD(XML Schemas Definition，XML
9、结构定义)的 W3C(World Wide Web Consortium,万维网联盟 ) XML(Extensible Markup Language，可扩展标记语言 )消息格式。 3.4 平台主机名和端口 应用程序通过TCP/IP(In ternet Protocol，网络间通信协议)连接服务器，服务器应向应用程序提供对应的服务器主机名和端口。应用程序根据CUPPSPN与CUPPSPP环境变量确定平台的主机名和端口。考虑到生产和测试环境的灵活性，可使用IP地址127.0.0.1。 3.5 会话原则 3.5.1 会话流程 应用程序和平台之间的会话流程图如图2所示，主要包括以下几个步骤： MH/
10、T 0048.22015 4 a) 平台监听一个已知的节点和端口； b) 应用程序连接到平台的相应节点和端口。在连接时，应用程序向平台发出可用接口版本列表请求，平台收到请求后返回可用接口列表； c) 应用程序向平台发送期望使用的接口版本。该接口版本经平台确认后，将用于后续会话消息的验证； d) 平台验证应用程序的合法性，并返回验证结果。如果验证成功，则应在验证结果中包含令牌信息。该令牌信息应用于所有后续通信以及验证设备连接。当平台连接关闭后，令牌失效，基于此令牌的连接也应立即断开； e) 应用程序使用已定义消息集与平台进行通信。对于每个设备会话，应用程序在断开连接之前，均应发送并获得平台对应的
11、响应； f) 应用程序断开。当应用程序关闭时，应向平台发送消息，获取消息后方可断开连接。 建立连接设置接口版本认证使用断开连接重定向图2 会话流程 基本的会话连接序列图原型参见附录A.1。 3.5.2 消息处理流程 3.5.2.1 建立连接后,当接收端收到消息时，应判断消息流的合法性。 3.5.2.2 消息从接收到处理的流程见图 3。处理流程如下： a) 接收端逐字节地读取消息头：如果接收端读取到无效字符，则接收端立即停止读取，发送的通知，并在该通知中包含信息 eventType = “headerVersion”，随后关闭连接。如果接收端读取的消息长度越界，则接收端发送的通知，并包含信息 e
12、ventType = “headerLength”，随后关闭连接。如果读取消息头超时，则接收端发送的通知，并包含信息 eventType = “headerTimeout”，随后关闭连接； b) 读取消息体：消息头中包含消息体的长度，如果在读取这个指定长度的消息体时超时，接收端发送的通知，其中包含信息 eventType =”bodyTimeout”，随后关闭连接； MHMH/T 0048.22015 5 c) 解析消息体：如果接收端无法使用选定的接口版本解析消息体，则接收端发送的通知，其中包含信息 eventType= “bodyParseFailure”，随后关闭连接； d) 处理经过解析
13、的信息。 sessionErrorEvent headerVersionsessionErrorEvent headerLengthsessionErrorEvent headerTimeoutsessionErrorEvent bodyTimeoutsessionErrorEvent bodyParseFailure读取消息头读取消息体解析消息体处理消息断开连接图3 平台消息处理流程 3.5.3 应用程序认证 3.5.3.1 一旦应用程序连接到平台并且选择好接口版本，则该应用程序应向平台请求认证。如果应用程序未能通过认证，则平台应断开与该应用程序的连接。 3.5.3.2 应用程序认证分为两步
14、： a) 应用程序向平台发送消息请求认证； b) 平台记录应用程序的认证请求，回复消息。该消息应包含以下信息： 1) 设备令牌：用于后续设备交互操作； 2) 平台参数：平台供应商 ID 和版本信息以用于日志记录； 3) 支持的加密算法列表； 4) 应用程序参数：局部存储、局部临时存储以及永久性全局存储地址； 5) 工作站参数：工作站的名字、厂商信息、平台的配置信息、操作系统默认的打印机名称等； 6) 设备分配列表(样品)； 7) 特殊模式接口，ZI(IATA message software device，IATA 信息设备)和 ZL（logging software device，日志设备）
15、都是被指定的。 应用程序认证请求与回复的消息示例参见附录A.8。 3.5.4 应用程序主动与平台断开连接 MH/T 0048.22015 6 3.5.4.1 应用程序与平台端口断开连接之前，应向平台发送消息以通知平台方应用程序将要断开连接。平台端接收到消息后，回复消息，并等待应用程序断开连接。附录 A.6 为与平台断开连接的示例。 3.5.4.2 应用程序发送消息后， 平台端将该应用程序设置为 aSpg 状态，不允许该应用程序继续向平台发送其他消息。如果该应用程序在 aSpg 状 态试图发送消息，平台记录事件。 3.5.4.3 平台接收后，等待应用程序断开连接,且不能向应用程序发送其他消息。如
16、果在PltSockMaxIdleTime1)后，该应用程序仍未断开，平台应作相应日志记录，然后断开该连接。 3.5.5 平台端发起的应用程序正常退出机制 3.5.5.1 本部分仅规范了应用程序的正常退出机制，应用程序的异常退出机制见本标准第 1 部分的9.1.8。 3.5.5.2 平台端可通过发送特定的指令断开应用程序连接。断开连接的形式有两种，即请求方式与控制方式)。 3.5.5.3 请求方式通过平台向应用程序发送指令停止应用程序。在接收到平台的停止指令后，应用程序应关闭与设备的连接、记录日志、通知用户应用程序正在退出，并最终关闭与平台的连接。此过程应在 AppSpgTime2)时间内完成，
17、如果需要更多的时间退出应用程序，最多可增加 MaxSpgDegerTimes3)次延迟退出的请求。 3.5.5.4 控制方式通过平台端执行指令停止应用程序。在这种情况下，应用程序被置为 aSpg 状态，如果应用程序退出时长超过了 AppSpgTime4)，应用程序将会进入 aZom 状态并被强制清除。 图4给出了平台端发起的应用程序正常退出的四种情况： a) 平台允许应用程序延迟退出，但应用程序不需要延迟的情况，分为： 1) 步骤“1”，平台请求应用程序停止； 2) 步骤“2”，应用程序回复可以退出。平台立即使分配给该应用程序的设备令牌失效； 3) 步骤“3”，应用程序关闭与平台的连接，然后退
18、出程序。 b) 平台允许应用程序延迟退出，且应用程序需要延迟的情况，分为： 1) 步骤“1”，平台请求应用程序停止。应用程序回复平台需要延迟退出。平台重置应用退出计时器 AppSpgTime5)； 2) 步骤“2”，应用退出计时器超时，平台继续向应用程序发送停止请求。应用程序回复延迟退出。平台重置应用退出计时器； 1) 见表3。 2) 见表3。 3) 见表3。 4) 见表3。 5) 见表3。 MHMH/T 0048.22015 7 图4 应用程序退出场景 3) 步骤“3”，应用退出计时器超时，平台端将应用程序置为 aSpg 状态。该应用程序回复需要延迟退出时间，但是平台已不允许应用程序延时，所
19、以平台忽略了这一请求； 4) 步骤“4”，应用程序尚未终止与平台的连接，平台最后一次发送停止请求，并忽略所有来自应用程序的消息； 5) 步骤“5”，应用退出计时器超时。平台将应用程序的状态改为 aZom，强行断开连接并释放与该应用程序有关的所有资源。 c) 平台不允许应用程序延迟退出，且应用程序也不需要延迟的情况。分为： 1) 步骤“1”，平台请求应用程序停止，并将应用程序置为 aSpg 状态； 2) 步骤“2”，应用程序回复可以退出。平台立即将分配给应用程序的设备令牌失效； MH/T 0048.22015 8 3) 步骤“3”，应用程序关闭平台的连接并且终止。 d) 平台不允许应用程序延迟退
20、出，但应用程序需要延迟的情况。分为： 1) 步骤“1”，平台请求应用程序停止，并将应用程序置为 aSpg 状态，应用程序回复平台需要延迟退出； 2) 步骤“2”，平台关闭连接并且将应用程序置为 aZom 状态，然后断开与应用程序的连接并释放相关的所有资源。 应用停止指令请求的消息示例参见附录A.7。 平台应用程序A132321ApplicationStopRequest canDefer =“false”applicationStopResponse result=“OK”TCP close(c)平台应用程序A12 21ApplicationStopRequest canDefer =“fal
21、se”ApplicationStopRequest canDefer =“false”TCP close(d)ApplicationStopResponse result =“defer”图4(续) 3.6 平台令牌失效和设备会话失效 3.6.1 应用程序在使用平台期间，应和平台保持连接。如果应用程序与平台的连接中断，与该连接相对应的设备令牌应立即失效。如果应用程序使用要求终止与平台的连接，则其设备令牌也应失效。 MHMH/T 0048.22015 9 3.6.2 使用失效令牌的设备连接是无效的。失效的设备会话在 PltSockM axIdleTime6)内依然保持连接状态。在此期间，不允许再
22、往这个连接上发送消息。如果应用程序试图在无效会话上发送信息，则平台认为该消息是非法消息并回复。 3.7 消息头 3.7.1 CUPPS 信息交互协议提供多个版本的消息头。消息头遵循 vvllllllllxxx的基本格式，每一位为AZ，09对应的ASCII 字符，其中： vv 为用 2 个字节表示的消息头版本； llllllll 为一个 8 个字节长的数据表示消息体长度，数据的内容可用大写或小写字母表示，即 0123abcd和 0123ABCD是一样的； xxx为消息头版本对应的扩展数据。 表 2 为消息头格式。 表2 平台消息头格式 版本 状态 备注 01 支持的 2个字节消息头版本，后跟 8
23、 字节的长度信息。 3.7.2 从会话连接尝试读取信息时，消息头的长度指定了应读取的字节数。当写入会话连接时，长度信息应按照对应版本规定的规则进行计算。 3.7.3 如果接收方接收到不支持的消息头版本，应使用 01 版本消息头向发送方回复错误信息，并终止该会话。 3.7.4 消息头版本 01 定义最大消息长度，即 PltMaxMsgSize7)字节(大约 16MB)。由于会话使用 8字节字段的消息长度，前两个字节的长度都被置为 0。 示例： 消息头版本01 错误样例如下： 1. 01FF00003F 2. 01 . . . . . . . . 消息头版本 3. 00 . . . . . . 0
24、0是可用的，FF会导致超过PltMaxMsgSize错误 4. 00003F消息体的长度信息 3.7.5 使用版本 01时，读取或写入连接时应遵循以下规则： 当往连接中写数据时，长度信息为所有消息体字节数，消息体使用 UTF8 编码方式； 当从连接读取数据时，应按消息头中定义的消息体长度信息读取指定长度数据。消息体使用UTF8 编码方式。 示例： 消息头版本01 正确样例如下： 1. 0100000013 body 2. 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 消息头版 本01 3. 00000013 . . . . .
25、 . . . . . . . . . . . . . . 消息体长度为19个字节 4. body 消息体 3.8 流协议 6) 见表3。 7) 见表3。 MH/T 0048.22015 10 3.8.1 CUPPS 连接使用简单标准流协议传输 UTF8 编码的XML 信息。每个消息均以消息头开始，按字节从流中读取。 3.8.2 图 5 和图6分别为接口发送和接收消息状态机，消息读取端应按字节读取数据。消息接收的最大时长为 PltStrea mAccumTime8)。 3.8.3 当从连接中读取消息头时，接收方应按位读取，一旦碰上无效字符，则立即停止读取。 准备发送消息计算长度前缀发送消息头发送
26、消息体传输传输完成传输传输完成关闭连接 连接丢失超时 连接丢失连接丢失超时图5 消息发送状态机 8) 见表3。 MHMH/T 0048.22015 11 图6 消息接收状态机 3.8.4 应用程序和平台之间的交互消息应使用先进先出的顺序原则处理，包含应用程序断开请求的流消息应按其在流中出现的顺序处理。 3.8.5 平台与应用之间的消息交互方式分为两种：请求/应答与通知。在请求/应答方式下，请求需要应答确认。交互支持同时发送多个请求。请求消息包含 messageID 属性，应答消息的 messageID 与请求信息的 messageID 一致。5.1.5 详细规 定了 messageID 的定义
27、与生成规则。在通知方式下，消息从发送端传输到接收端，无需回应。 3.9 接口消息里的二进制数据 接口交互消息中的二进制数据应使用Base64方式进行编码、传输。 3.10 平台参数 应用程序在启动之前应设置的平台参数见表3。 表3 平台 参数 参数 定义 功能描述 建议值 时间跨度 AppAthTime 应用程序认证时长 平台认证应用程序的最大时长 5.0s 开始：平台接收到来自应用程序的完整认证请求；结束：平台开始发送对应用程序认证响应 AppSpgTime 应用程序停止所需时长 从收到平台关闭指示后关闭程序所需的最大时长 45.0s 开始：平台命令应用程序关闭的时刻；结束：应用程序关闭完成
28、的时刻 MH/T 0048.22015 12 表 3 (续) 参数 定义 功能描述 建议值 时间跨度 AppStgTime 应用启动时长 平台启动应用程序所消耗的最大时长，包含运行环境的准备和应用程序本身启动的时长 30.0 s 开始：终端用户点击应用程序对应菜单项的时刻；结束：应用程序启动的时刻 AppStpTime 应用已停止时长 平台在应用程序退出后，进行清理操作的最大时长 30.0 s 开始：应用程序终止的时刻；结束：平台清理完成的时刻 DevAcqMaxTime 请求设备的最大时长 处理消息的最大时长 30.0 s 开始：完全被接收的时刻；结束：完全被发送出去的时刻 DevLkdTi
29、me 锁定设备时长 设备被锁定的最大时长，超过这个时间设备将进入dStd状态 60.0 s 开始：设备进入dLkd的时刻；结束：当前时刻 DevNormTime 读设备读取时长 读设备的一个特定参数。如果不间断读取信息的设备在DevNormTime定义的时间内读取到多个数据值可用，则平台只将最后读取到的数据发送给应用 5.0 s 开始：最后一个读设备的消息被发送到应用程序的时刻；结束：当前时刻 DevPollMaxFreq 设备最大查询时长平台允许应用程序轮询设备状态的最大频率。过多轮询会导致平台回复pollingTooFast消息 5.0 s DevSpgTime 设备停止时长 设备停止所需
30、的最大时长。如果设备停止超时，则进入dZom状态 30.0 s 开始：设备进入dSpg状态的时刻；结束：当前时刻 DevStgTime 设备启动时长 正常启动设备所需的最大时长。如果设备启动超时，则从dStg 状态进入 dZom 状态。60.0 s 开始：设备进入dSpg状态的时刻；结束：当前时刻 MaxDevLockTime 锁定设备的最大时长 平台处理消息的最大时长 5.0 s 开 始 ： 平 台 接 收 到的时刻； 结束：平台返回的时刻 MaxDevStsTime 获取设备状态的最大时长 平台处理消息的最大时长 5.0 s 开 始 ： 平 台 接 收 到的时刻；结束：平台返回的时刻 MH
31、MH/T 0048.22015 13 表 3 (续) 参数 定义 功能描述 建议值 时间跨度 MaxDevUnlTime 解锁设备的最大时长 平台处理消息的最大时长 2.0 s 开 始 ： 平 台 接 收 到的 时刻；结束：平台返回的 时刻 MaxMessageID 平台消息ID的最大值 平台端发起消息的最大ID值 0xffffffff MaxSpgDeferTimes 推迟停止的最大次数 应用程序推迟关闭的最大次数 4 次 MinMessageID 消息ID的最小值 应用程序端发起消息的最小ID值 0x00000001 MinPlatformMsgID 平台消息ID最小值 平台端发起消息的最
32、小ID值 0xffff0000 MsgIDListLen 消息ID清单的长度 最近发送或接收消息ID值的最小条数 255 条 PGSMin 全局永久存储的最小值 平台为每个航空公司提供的全局存储空间的最小值1 GB PLSMin 本地永久存储的最小值 平台为每个航空公司提供的本地存储空间的最小值1 GB PNSMin 网络存储最小值 平台为每个航空公司提供的持久网络存储空间的最小值 1 GB PltAltMaxDlvTime 传递警告消息的最大时长 平台向所有工作站发送警报消息的最大时长 600.0 s PltAppStrMin 平台应用程序存储最小值 平台为每个航空公司应用程序提供的存储空间
33、的最小值 5 GB PltLogMinStr 存储平台日志文件的最小时长 平台为每个航空公司提供日志存储时间的最小值 5 天 PltMaxMsgSize 最大消息长度 接口消息的最大长度 0x00ffffff 字节 PltMsgHdrSize 消息头大小 消息头的字节数 可变的 PltRepGran 报告时间间隔 平台报告基于时间的活动的时间间隔 60.0 s 开始：平台上一次报告的时刻；结束：当前时刻 MH/T 0048.22015 14 表 3 (续) 参数 定义 功能描述 建议值 时间跨度 PltSockMaxIdleTime 连接最大空闲时间 PltSockMaxIdleTime用于以
34、下两种情况：(a)连接建立之后，未接收到任何字符之前的时间段；(b)客户端发送或 指令准备结束会话之后，关闭连接之前的时间段600.0 s 开始：a)连接建立后未接收到任何字符前，(b)客户端发送 或 之后，关闭连接之前；结束：当前时刻 PltStreamAccumTime 消息流接收时间 平台与应用之间，同一消息的字节发送之间，允许的最长空闲时间。当接收端获取到任一字节时，PltStreamAccumTime计时器复位。当接收端接收缓冲区被清空时，PltStreamAccumTime计时器启动。当PltStreamAccumTime计时器超时，则给对方发送的消息 60.0 s 开始：从连接缓
35、冲区中读取到第一个字节；结束：当前时刻 PltStreamOutMsgs 最大重复消息数量 同一个连接支持的重叠消息的最大值 5条 PltStreamOutMsgsZL ZL设备最大重复消息数量 ZL设备的连接中支持的重叠消息的最大值。对于ZL 设备，应用程序可在收到logWriteResponse消息之前，继续发送logWriteRequest。当累积到PltStreamOutMsgsZL个未收到回复的请求时，应用程序应暂停发送logWriteRequest 20条 PRMaxResponseTime 打印的最大响应时间 PR设备处理消息的最大时长。如果在这段时间过后还没有开始打印，则平台端
36、取消此次打印任务 120.0 s TSMin 最小临时存储空间 应用程序临时存储空间的最小值 1 GB UsrAthTime 用户认证时间 认证终端用户的最大时长 10.0 s 开始：接收到认证消息第一个字节的时刻；结束：当前时刻 UsrAthTries 用户认证次数 工作站连续尝试登陆均失败的最大次数 3次 MHMH/T 0048.22015 15 表 3 (续) 参数 定义 功能描述 建议值 时间跨度 UsrSpgTime 用户停止时间 用户对象退出的最大时长。一旦超时，工作站将进入 uZom 状态，在随后的清理结束后，应为下一个用户登陆做好准备 30.0 s 开始：用户开始退出 结束：用
37、户对象清除的时刻 UsrSsTime 用户屏保时间 用户在工作中运行屏幕保护程序的最大时长.一旦超时，用户从 uSs 状态进入uSpg状态 600.0 s 开始：用户在工作站上最后一个活动的时刻 结束：当前时刻 UsrToTime 用户超时时间 用户的最大空闲时间。一旦超时，用户从uStd状态进入 uSs状态 600.0 s 开始：用户在工作站上最后活动的时刻，如键盘输入、鼠标操作、设备使用等；结束：当前时刻 WsAltTime 工作站警告超时时间 工作站解除警告信息的最大时长 600.0 s 开始： 工作站进入wAlt的时刻；结束：当前时刻 WsSpgTime 工作站停止时间 工作站退出的最
38、大时长。一旦超时，工作站从wSpg状态进入wZom状态 30.0 s 开始： 工作站进入wSpg的时刻；结束：当前时刻 对于与时间相关的参数，平台和应用程序应允许运行时间偏差在1%之间。 3.11 设备锁定与解锁 3.11.1 令牌锁与连接锁 3.11.1.1 令牌锁的锁定机制基于令牌，连接锁的锁定机制基于连接。对于连接锁，一旦一个连接成功锁定设备，则其他任何连接均不能锁定该设备。而对于令牌锁，使用同样令牌的不同连接可同时锁定设备。 3.11.1.2 采用连接锁时，设备的锁定状态从开始，到对应的结束。 采用令牌锁时，设备的锁定状态从第一个开始 ，到成功锁定的最后一个结束。 3.11.1.3 图
39、 7 为两种锁机制的示例，其中有两个应用程序连接 A 与B，均希望使用设备 BC1。该图给出了应用程序与平台之间的交互，在交互开始之前，应用程序与平台均已成功建立连接。 MH/T 0048.22015 16 应用程序 B 平台1234512345deviceLockRequest byDeviceToken=A BC1deviceLockResponse OKdeviceLockRequest byDeviceToken=B BC1deviceLockResponse deviceLockeddeviceLockRequest byDeviceToken=B BC1deviceLockResp
40、onse deviceLocked应用程序 AdeviceLockRequest byConnection BC1deviceLockResponse deviceLocked6786789 910111210111213141314deviceLockRequest byDeviceToken=A BC1deviceLockResponse OK用户扫描条码notify dataAvailable BC1notify dataAvailable BC1readerReadRequest BC1readerReadResponse OK datareaderReadRequest BC1rea
41、derReadResponse OK deviceUnlockRequest BC1deviceUnlockResponse OK用户扫描条码notify dataAvailable BC1deviceLockRequest byDeviceToken=A BC1deviceLockResponse OK-deviceAlreadyLockeddeviceUnlockRequest BC1deviceUnlockResponse OKdeviceLockRequest byConnection BC1deviceLockResponse OKdeviceLockRequest byConnec
42、tion BC1deviceLockResponse deviceLocked图7 令牌锁与连接锁锁定示例 3.11.1.4 图 7 中应用程序与平台之间的交互步骤如下所示。在每个步骤之后，记录设备持有的锁状态，其中“*”代表连接锁，“t=x”代表令牌为 x 的令牌锁： a) 步骤“1”，应用程序 A 使用设备令牌 A 获得设备 BC1的锁定。其中： MHMH/T 0048.22015 17 1) A = BC1 t=A ； 2) B = ； b) 步骤“2”，应用程序 A 试图使用令牌 B 锁定设备。因为这个设备已经使用令牌 A 锁定，所以平台拒绝的该锁定请求。其中： 1) A = BC1
43、t=A ； 2) B = ； c) 步骤“3”，应用程序 B 试图使用连接锁锁定设备。但因为这个设备已经使用令牌 A 锁定，所以平台拒绝了该请求。其中： 1) A = BC1 t=A ； 2) B = ； d) 步骤“4”，应用程序 B 试图使用令牌 B 锁定设备。因为这个设备已经使用令牌 A 锁定，所以平台拒绝了该请求。其中： 1) A = BC1 t=A ； 2) B = ； e) 步骤“5”，应用程序 B 试图使用令牌 A 锁定设备。因为设备已经被令牌 A 锁定，而且使用的同样的令牌，平台允许该锁定请求。现在应用程序 A 和B共享设备 BC1 的锁。其中： 1) A = BC1 t=A
44、； 2) B = BC1 t=A； f) 步骤“6”，用户使用读设备 BC1 扫描条码。设备已经被令牌锁定，所有与此设备保持令牌锁的连接，都会收到有可用数据的通知。其中： 1) A = BC1 t=A ； 2) B = BC1 t=A ； g) 步骤“7”，应用程序 A 试图从 BC1 读取数据。当数据返回到应用程序 A 时，平台清除 BC1 的数据。其中： 1) A = BC1 t=A； 2) B = BC1 t=A ； h) 步骤“8”，应用程序 B试图从 BC1读取数据。因为在步骤“7”中应用程序 A 的读取请求后已经清除了数据，所以返回结果中，并不包含读取到的数据； i) 步骤“9”，
45、应用程序 A释放它对 BC1 的锁。其中： 1) A = ； 2) B = BC1 t=A ； j) 步骤“10”，用户使用读设备 BC1 扫描条码。设备已经被令牌锁锁定。所有与此设备保持令牌锁连接，都会收到有可用数据的通知，而此时只有应用程序 B。其中： 1) A = ； 2) B = BC1 t=A ； k) 步骤“11”，应用程序 B 试图使用令牌 A 锁定 BC1。因为应用程序 B 已经用令牌 A 锁定 BC1，所以平台回复提示应用程序已经锁定该设备。其中： 1) A = ； 2) B = BC1 t=A ； l) 步骤“12”，应用程序 B 对BC1 解锁。其中： 1) A = ；
46、2) B = ； m) 步骤“13”，应用程序 A 使用连接锁锁定设备。其中： MH/T 0048.22015 18 1) A = BC1* ； 2) B = ； n) 步骤“14”，应用程序 B 试图使用连接锁锁定 BC1。因为应用程序 A 连接已经使用连接锁锁定该设备，所以平台拒绝了该请求。其中： 1) A = BC1* ； 2) B = 。 3.11.2 设备锁定超时 一旦应用程序锁定设备，平台为应用程序启动一个时长为DevLkdTime9)的计时器。如果定时器超时，设备连接仍没有I/O（Input/Out put,输入输出）交互，则该应用程序对设备的锁定超时，平台立即向所有获得该设备连
47、接的应用程序发送消息。锁定超时的示例参见附录A.2。 3.11.3 子设备锁定规则 子设备锁定规则只适用于标准模式。当父设备被锁定时，从属于该父设备的子设备也被锁定。 子设备锁定的示例参见图8图12。其中应用程序A和B与平台通信，每个应用程序都要使用BG1设备或它的子设备BC1和DD1。假定所有图中每个应用程序和平台已成功连接到设备。 123123应用程序A 应用程序B 平台deviceAcquireRequest BG1deviceAcquireResponse BG1deviceAcquireRequest BC1deviceAcquireResponse BC1deviceAcquireRequest DD1deviceAcquireResponse DD1deviceAcquireRequest BC1deviceAcquireResponse BC1deviceAcquireRequest DD1deviceAcquireResponse DD145
