MH T 0048.1-2014 中国民用机场共用旅客处理系统技术规范 第1部分 系统结构.pdf

《MH T 0048.1-2014 中国民用机场共用旅客处理系统技术规范 第1部分 系统结构.pdf》由会员分享，可在线阅读，更多相关《MH T 0048.1-2014 中国民用机场共用旅客处理系统技术规范 第1部分 系统结构.pdf（49页珍藏版）》请在麦多课文档分享上搜索。

1、ICS 35.240.60 V 07 MH 中华人民共和国民用航空行业标准 MH/T 0048.12014 民用机场共用旅客处理系统技术规范 第 1 部分：系统结构 Specification of common use passenger processing systems in civil aviation airports Part 1： System architecture 2014 12 03 发布 2015 03 01 实施中国民用航空局 发布MH/T 0048.12014 I 目 次 前言 . . II 1 范围 . . 1 2 规范性引用文件 . . 1 3 术语和定义 .

2、 . 1 4 CUPPS 总则. . 2 5 CUPPS 系统功能. . 3 6 平台管理 . . 14 7 工作站管理 . . 19 8 用户管理 . . 26 9 应用程序管理 . . 32 10 设备管理 . . 37 11 应用程序需求 . . 43 MH/T 0048.12014 II 前 言 MH/T 0048分为三个部分： 第 1 部分：系统结构； 第 2 部分：应用软件数据交换； 第 3 部分：硬件设备数据交换。 本部分为MH/T 0048的第1部分。 本部分按照GB/T 1.1-2009给出的规则起草。 本部分由中国民用航空局人教司提出。 本部分由中国民用航空局航空器适航审定

3、司批准立项。 本部分由中国民航科学技术研究院归口。 本部分起草单位：中国民航大学、中国民航信息网络股份有限公司。 本部分主要起草人：李建伏、张博、徐涛、赵森、贺怀清、董晨欣、张清文、惠康华、丁玎。 MHMH/T 0048.12014 1 民用机场共用旅客处理系统技术规范 第 1 部分：系统结构 1 范围 MH/T 0048的本部分规定了共用旅客处理系统的平台管理、工作站管理、用户管理、应用程序管理、设备管理以及对应用程序的要求。 本部分适用于中国民用机场共用旅客处理系统的建设。 2 规范性引用文件 下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不

4、注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 IATA推荐性惯例1797：2011 共用旅客处理系统技术规范(Recom mended practice 1797 common use passenger processing systems technical specification) 标准编号欧洲航空协会技术规范2009 (AEA Techn ical Specifications 2009) 3 术语和定义 下列术语和定义适用于本文件。 3.1 共用旅客处理规范 CUPPS Common Use Passenger Processing Systems 由国际航协定

5、义，用于航空公司使用机场的终端设备的信息处理规范。 3.2 CUPPS工作站 CUPPS Workstation 运行于CUPPS平台上的硬件和操作系统软件。硬件包括计算机、移动终端设备、智能手机、简易客户终端等。 3.3 CUPPS应用 CUPPS Application 运行在CUPPS平台上，使用CUPPS平台接口的应用程序。 3.4 商用现成品或技术 COTS Commercial off the shelf 指可以采购到的具有开放式标准定义的接口的软件或硬件产品。 COTS应用即基于COTS的应用。 MH/T 0048.12014 2 4 CUPPS 总则 4.1 总体要求 CUPP

6、S平台应遵循以下原则： 平台独立性：不依赖于平台提供商，也不必对不同提供商提供的不同平台进行分别维护； 简化业务流程：提供一个灵活的平台，能简化多种业务的应用； 功能定义范围：本部分中定义的为必须实现的功能； 经济效益： 通过简化产品的安装，支持与升级维护，降低航空公司与机场的重复投资； 可维护性：提供强有力的可维护性，平台需要可以快速的部署、维护和升级； 安全性：提供相应的安全措施确保系统可以平稳运行； 服务性：可以方便地应对应用程序的升级和维护需求。 适用于CUPPS的应用程应遵循以下原则： 可运行于 CUPPS 所支持的操作系统上； 必要组件的安装、配置和访问由应用自身完成； 应用不会对

7、平台构成安全风险； 应用程序不能影响平台的稳定性； 应用程序不能违反任何支付卡行业数据安全标准。 4.2 逻辑系统结构 MH/T XXXX-XXXX的本部分只提供与CUPPS逻辑架构相关的信息，不提供具体的实现细节定义。CUPPS提供商可自由实现符合要求的CUPPS平台。CUPPS提供的统一逻辑架构见图1。 图1 CUPPS 系统逻辑架构 应用服务器或航空公司主机系统与CUPPS系统通过双向通信协议进行通信。CUPPS应用程序与CUPPS系统之间使用本部分定义的CUPPS平台接口进行通信。CUPPS应用程序只能通过CUPPS平台接口访问CUPPS管理的设备；CUPPS应用程序可以通过操作系统提

8、供的基本服务，使用工作站提供的其他功能。航空公司系统管理员和平台提供商系统管理员通过CUPPS定义的管理接口与CUPPS平台通信。CUPPS平台通过事件报告与外部系统管理工具进行交互。 关于CUPPS更为详细的逻辑结构见图2。 MHMH/T 0048.12014 3 图2 CUPPS 系统逻辑结构 4.3 设备接口 CUPPS工作站支持的设备见表1。单个硬件设备可以支持本部分中描述的多个设备功能。CUPPS平台提供商可以自由选择符合要求的硬件设备。 5 CUPPS 系统功能 5.1 CUPPS 系统构成 CUPPS系统包括CUPPS平台、 CUPPS工作站、CUPPS 用户、应用程序(CUPP

9、S应用与COTS应用)、CUPPS设备的管理。这些对象之间的逻辑关联见图3。 CUPPS系统需要管理整个CUPPS平台，控制CUPPS工作站的启动和停止，并将CUPPS警报信息分发到CUPPS工作站。CUPPS工作站负责管理工作站的运行环境，C UPPS用户的启动和停止，将CUPPS警报信息传递给CUPPS用户。CUPPS用户负责管理特定CUPPS用 户的运行环境，CUPPS应用程序和COTS 应用程序的启动和停止。应用程序负责管理特定CUPPS应用程序和COTS应用程序实例的运行环境。CUPPS设备负责对设备实例的逻辑关系的管理。 图3 CUPPS 系统构成 MH/T 0048.12014

10、4 CUPPS系统各部分的构成满足以下要求： 每个 CUPPS 平台由零个或多个 CUPPS 工作站组成； 每个 CUPPS 平台由零个或多个 CUPPS 设备组成； 每个 CUPPS 工作站由零个或多个用户和 CUPPS 设备组成； 每个CUPPS 用户由零个或多个应用程序组成。 表1 CUPPS 设备接口细节 接口模式a)缩写 名称 AEA(Association Europe Airlines)b)标准 特殊 其他 Windows 打印服务BC 条码阅读器 DNRc)DR BE 蜂鸣器 DNR DNR BG 登机口阅读器 DR DR BP 登机牌打印机 DR BT 行李标签打印机 DRd

11、)DD 显示设备 DR IR 身份证阅读器 DR MS 磁条阅读器 DR OC 护照阅读器 DR PP 密码键盘设备 DR PR 文档打印机 DRdDR RW 其他设备 DR SD 称重设备 DNR DNR SN 快照设备 ZI IATA 报文软件设备 DR ZL 日志软件设备 DR a表中空白处表示NDNR，未定义也不强制要求实现的接口；另外，DR为定义并且必须实现的接口，DNR为定义但不强制要求实现的接口。 b本部分中提到的AEA是指AEA 2009标准，其他版本的AEA不做要求。 c在AEA模式下，BC是BG的一个子设备。 d如果设备支持射频识别技术(Radio Frequency Id

12、entification，RFID)，则可包含 RFID 的功能。 5.2 命名标准 5.2.1 总体要求 CUPPS工作站名称、CUPPS设备名称应是标准化的，并且在全球站点实现唯一命名。该命名标准旨在使名称解析具备可靠性和可扩展性。 5.2.2 工作站和设备名称 工作站和设备命名标准支持全球唯一性标识，并且能够根据这个名称判断出工作站和设备的大概物理位置。 MHMH/T 0048.12014 5 对于非测试环境下的CUPPS操作，平台应使用其所在的机场及城市代码。在测试环境下，可使用测试名称标志Z。无论什么情况下，平台提供商应保证工作站和设备名称的唯一性。 工作站或者设备的名称由字符串组成

13、，并且需要包含以下信息：机场或者城市代码，具体的平台提供商代码，功能区代码，以及设备相关信息。 工作站或设备节点标准化命名的构成见表2。 表2 工作站或设备的名称构成 编号 长度 格式 内容 1 3 AN 机场代码，国际航协机场或者城市代码 2 1 AN 采用国际航协提供的平台提供商代码，见表 3 3 1 AN 航站楼编号，如果是测试节点则设为 Z 4 1-7 AN 平台提供商自定义可变字符，需包含表 4 中的功能区代码 5* 2 AN 表 1 中的设备类型码 6* 1 N 设备索引 注： *为可选项，AN为字母-数字，N为数字 表3 平台提供商代码 代码 平台提供商 A ARINC B IB

14、S C Ink Aviation D BagDrop Systems I AirIT K IIAC and Asiana IDT R RESA S SITA T TravelSky U Ultra X 任何新的平台提供商应到 IATA 的 CUWG 组注册才能获得提供商代码 功能区代码的描述见表4。 表4 功能区域代码 代码 描述 代码 描述 BG 行李提取 HH 手持设备 BH 行李搬运 JW 登机通道 BK 行李托运检查 LA 实验室 BO 办公室 LB 大厅 BS 行李扫描 LF 失物认领 Bn 地下楼层 n 为 19 LG 休息室 CK 值机柜台 LW 隔离厅 CM 海关 MD 主层

15、MH/T 0048.12014 6 表4(续) 代码 描述 代码 描述 CN 引导处 Mn 夹层 n 为 19 CO 贵宾服务 RP 扶梯 CR 路边(临时停车区) TD 签转柜台 CS 客户服务区 TK 售票区 DR 通道 TN 培训室 GT 登机口 TR 机场火车、地铁站 GH 传达室 nn 楼层 0199 示例： TAOT1CKE12 表示青岛流亭机场(TAO),TravelSky(T)提供 CUPPS 平台，1 号航站楼(1)，E 区 12 号值机柜台(CKE12)工作站。TAOT1CKE12BP1 表示位于这个柜台上的 1 号登机牌打印机(BP1)。 5.3 CUPPS 平台功能 5

16、.3.1 软件和硬件 5.3.1.1 操作系统 平台服务器可以使用任意平台提供商认为合适的操作系统，只要能够像基于微软windows的服务器一样提供以下功能并保证其实现对于终端软件是透明的： 提供适当的访问控制机制共享网络和打印机； 终端用户认证基础结构要符合本部分的条款。 5.3.1.2 硬件 平台服务器没有预定义的硬件列表，其硬件配置由平台提供商决定。 服务器硬件可从任何硬件平台提供商获取。本部分不提供任何已授权、首选等类似的厂商推荐。 5.3.2 存储功能 5.3.2.1 应用存储 平台应提供一种机制存储 COTS 应用程序、CUPPS 应用程序及配置数据。应用存储可以基于服务器，也可基

17、于工作站。 基于服务器存储应提供一个简单的单磁盘卷或一个复杂的磁盘阵列系统。底层存储机制对使用它的应用来说应是透明的。 平台应为每个航空公司提供最低限度 5 GB 的应用存储空间。 5.3.2.2 非应用存储 非应用存储包括数据、应用日志、临时文件等的存储。 平台应提供永久性全局存储、永久性局部存储和临时存储三种存储方式。 三种不同类型存储方式的特征见表5 。 MHMH/T 0048.12014 7 表5 三种存储方式的比较 特征 永久性全局存储 永久性局部存储 临时存储 持久性 无限 无限 应用程序使用期间 可由其他工作站访问 是 否 否 受航空公司保护 是 是 是 磁盘配额 1 GB 1

18、GB 1 GB 备份和恢复 可以 不可以 不可以 存储位置 网络或本地 本地 本地 5.3.2.3 永久性全局存储 永久性全局存储允许所有CUPPS工作站访问，应被站点数据备份策略覆盖。 CUPPS平台应提供永久全局存储供COTS应用程序和CUPPS应用程序使用。 永久性全局存储设备应能被所有工作站访问。写入此存储区域的数据应无限期保留，其数据规模不能超过表5中所分配的配额。永久性全局存储区域应包含在安装备份和恢复策略中。 应用程序通过环境变量CUPPSPGSD、 CUPPSPGSU和消息中persistentGlobal变量值决定其永久存储位置。 5.3.2.4 永久性局部存储 永久性本地存

19、储只允许CUPPS本地工作站访问，不应被站点数据备份策略覆盖。 CUPPS平台应提供永久性本地存储供应用使用。为确保最大吞吐量，永久性本地存储应部署在本地工作站上，其他工作站不能访问。写入此存储区域的数据应无限期保留，其数据规模不能超过表5中所分配的配额。应用程序通过环境变量CUPPSPLSD、CUPPSPLSU以及消息中persistentLocal变量值决定其永久性本地存储位置。 5.3.2.5 临时存储 CUPPS平台应提供临时存储供应用使用。每个工作站的临时存储区域独立于其他工作站，一个工作站不允许访问其他工作站的临时存储区域。写入临时存储的数据应在应用程序终止时由平台自动删除。临时存

20、储不必包含在安装备份和恢复策略中。 应用程序通过环境变量CUPPSSTSD、CUPPSSTSU以及消息中transie nt变量值决定其临时存储位置。 5.3.3 查询功能 5.3.3.1 平台应支持查询功能以便于应用程序获取有关运行环境的信息。查询功能应基于本部分中定义的全球命名标准。 5.3.3.2 平台查询功能应能确定哪些 CUPPS 管理设备配置可以使用。 5.3.3.3 平台可提供上述要求外的其他查询功能。 5.3.4 消息功能 5.3.4.1 CUPPS 平台应提供一定形式的广播消息。这类消息用于安全警报、管理员警报等。 5.3.4.2 CUPPS 平台应提供图形用户界面以输入要分

21、发的 CUPPS 警报信息。 图形用户界面应使用 CUPPS菜单系统或其他安全机制，以保证只有 CUPPS 平台管理员才可访问该界面。 MH/T 0048.12014 8 5.3.4.3 界面应显示以下信息： 管理员输入的消息内容； 输入的日期和时间； 发布消息的管理员信息。 5.3.4.4 平台不必对未在平台上运行的工作站实现消息队列功能，也不必提供浏览历史消息的功能。消息功能只为实现实时传递。 5.3.5 认证功能 5.3.5.1 平台应提供通用认证机制。在实现方式上，可使用平台的内置认证机制，也可借助操作系统的内置认证机制或者其他设施。 5.3.5.2 认证方案应提供基于用户名和密码的验

22、证方式，并实现基于角色的身份验证和权限机制。 5.3.6 监控功能 平台应对关键对象实施监控。并且应给管理员提供一个图形用户界面来监控处于异常状态的对象，主要包括： 应用被要求运行但处于 aStp 状态； 应用处于 aZom 状态； 设备被要求启动但处于 dStp 状态； 设备处于 dErr 状态或 dZom 状态； 工作站被要求启动但处于 wStp 状态； 工作站处于 wZom 状态； 用户被要求启动但处于 uStp 状态； 用户处于 uZom 状态。 5.3.7 平台管理报告 5.3.7.1 总体要求 CUPPS 平台应提供合适的数据用于报告平台的可用性。 鉴于数据用途以及用户对报告需求的

23、多样性，此处不定义报告的具体格式。CUPPS 平台应提供原始数据以供用户创建报告。报告可以使用各种工具完成，比如微软的 Excel 软件等。 平台不要求使用某种特定的方法获取这些数据，也不必为其提供某种特定的接口。 5.3.7.2 可用性报告 平台只需要报告对象处于异常状态的时段，主要包括： aZom 状态； dErr 状态； dZom 状态； pStp 状态； uZom 状态； wZom 状态。 平台报告的时段的最小间隔为 60 s，如果时段不是 60 s 的整数倍，将其取整到下一整数。 MHMH/T 0048.12014 9 5.3.7.3 使用情况报告 CUPPS 平台应提供数据用于报告

24、平台的使用情况。 平台应记录以下使用情况： 从用户的身份验证开始到用户完成注销的时间，精确到 60 s； 物理设备的每次使用情况。 5.3.8 设备管理界面 平台应为设备管理提供图形用户界面并实现以下功能： 设备管理，如安装新设备，移除现有设备等； 设备监控。 具体功能和实现方法由平台提供商决定。 5.3.9 日志功能 5.3.9.1 平台应实现对平台相关操作的综合日志记录功能，包括与应用交互的消息和数据流，与平台各模块交互的消息和数据流，与其他平台交互的消息和数据流。 5.3.9.2 平台应提供软件日志设备处理日志记录操作。 5.3.9.3 平台相关日志应遵循以下原则： 平台相关日记记录功能

25、可被平台开启； 平台相关日志记录功能可被应用开启； 平台相关日记记录功能可根据系统的配置被强制禁止。 5.3.9.4 数据记录形式不能违背支付卡行业数据安全标准。 5.3.9.5 平台应给每个航空公司提供大小 1 GB 的永久性网络存储空间用于存储平台的相关日志。该存储区域可根据存储类型分区，如可执行文件、临时数据、应用日志等。平台日志至少保留 5 天。 5.3.10 令牌管理 5.3.10.1 令牌可被平台和应用程序用来执行各种任务，例如访问控制和数据安全性。 5.3.10.2 生成令牌的方法由平台决定，应用程序不能尝试从令牌值推断任何特定的信息。 5.3.10.3 在授权应用程序访问平台资

26、源之前，平台应验证应用程序的每个实例。应用程序应给出消息中要求的数值，平台可使用任意方法来执行认证。当应用程序成功通过验证后，平台授予其一个设备令牌。应用程序实例使用此令牌与平台进行所有后续连接。 5.3.10.4 当接口信息交互时， 应用程序向平台提供明确的令牌。 平台应先验证令牌再处理后续的交易。如果应用提供的令牌无效，交易会被拒绝并且标识相应的状态码。 5.3.10.5 当接口信息交互时，应用程序未向平台提供明确的令牌，平台应先验证打开逻辑会话时所用的令牌。如果应用提供的令牌无效，交易会被拒绝并且标识相应的状态码。 5.3.10.6 当 CUPPS 平台管理接口连接断开后，令牌立即失效。

27、基于此过期令牌的后续交易都被拒绝并标识相应的状态码。 5.3.11 实例控制 5.3.11.1 CUPPS 平台应提供管理应用程序实例个数的功能。 MH/T 0048.12014 10 5.3.11.2 应用程序运行实例个数的判断由底层操作系统的进程管理功能决定。 5.3.11.3 应用程序实例个数的管理功能基于应用程序配置。如果未配置，平台不限制应用程序的实例数。 5.3.11.4 如果平台阻止了应用程序的实例化，平台应记录事件，显示相关应用程序、工作站和用户的信息。 5.3.12 标准环境变量 CUPPS平台应给应用程序提供一个用于描述环境的标准环境变量列表。 应用程序与平台之间信息交换所

28、需的环境变量见表6。 表6 CUPPS 平台上运行时环境变量 变量 定义 例值 CUPPSACN 工作站所在的计算机的别名，由计算机、航空公司和用户构成，默认为 CUPPSCN ABC1234 CUPPSAL2 航空公司的 2 字 IATA 代码或本地定义值 LH CUPPSAL3 航空公司的 3 字 IATA 代码或本地定义值 DLH CUPPSALA IATA 结算代码 220 CUPPSAPD 应用路径，使用盘符和路径 Q：APPSLH CUPPSAPL 应用路径盘符 Q CUPPSAPU 符合通用命名规则的应用路径 nodeshare CUPPSBNI 壁垒服务器 IP 地址 155.

29、237.18.253 CUPPSBNP 壁垒服务器端口 1835 CUPPSCN 计算机名 LHRT4LB00302PR1 CUPPSDSP 默认 windows spooler 打印机 nodeprtshareCUPPSPGSD 永久性全局存储位置，盘符和路径 Z：LH CUPPSPGSL 永久性全局存储位置，盘符 Z CUPPSPGSU 永久性全局存储位置，符合通用命名规则 nodeshare CUPPSPLSD 永久性本地存储位置，盘符和路径 Z：AA CUPPSPLSL 永久性本地存储位置，盘符 Z CUPPSPLSU 永久性本地存储位置，符合通用命名规则 nodeshare CUPP

30、SPLT 平台参数 Xxx CUPPSPN 平台节点，节点名称用来连接以进行查询、日志等其他平台级别操作 LHRCUPPS CUPPSPP 平台端口 7535 CUPPSTSD 临时存储位置，盘符和路径 Y：ABC CUPPSTSL 临时存储位置，盘符 Y CUPPSTSU 临时存储位置，符合通用命名规则 nodeshare CUPPSUN 用户名称，即当前会话的逻辑用户名，通常是航空公司名，也可为地服人员名称 LH CUPPSXSDD XSD 位置，盘符和路径 W：AB CUPPSXSDL XSD 位置，盘符 W CUPPSXSDU XSD 位置，UNC nodeshare CUPPSxxn

31、 设备类型 xx 索引 n，例如，CUPPSPR1 表示第一个打印机，CUPPSOC1 表示第一个护照扫描器 LHRT4LB00302PR1 MHMH/T 0048.12014 11 在标准环境变量中提供给应用程序的信息应与返回给应用程序的消息中的信息保持一致。 除了在消息中，平台将所有驱动器号和路径中的斜线转换为反斜线外，平台提供的标准环境变量值应遵循基本的数据类型规则，如长度限制、样式等。 5.3.13 任意环境变量 平台应支持配置任意的环境变量。 环境变量由任意工作站、航空公司和用户的组合在配置时定义。工作站、用户和应用的组合可提供一个键值以查找相应的值。 处理操作顺序如下： 为工作站定

32、义变量，如果没有用户登录，则完成环境构建过程； 当用户在应用程序启动之前登录，首先为工作站定义变量，然后添加或者改写为用户定义的变量； 当应用程序启动之前，首先为工作站定义变量，然后添加或者改写为用户定义的变量、应用程序变量等，直到操作顺序完成。 5.3.14 IATA 报文接口 CUPPS 平台应提供一个标准的、公共的接口与非标准报文系统进行 IATA 报文交换。 IATA报文接口的模型见图4。 图4 IATA 信息接口 IATA报文发送者或接收者和非标准报文发送者或接收者可能需要集成引擎，本部分不要求CUPPS平台提供该集成引擎。 平台应提供IATA报文接口软件设备进行报文交互操作。 5.

33、3.15 设备处理的可扩展性 CUPPS平台的设计应满足以下可扩展性需求： a) 支持至少 30 个设备：CUPPS 平台应为应用程序分配至少 30 个设备，以确保具有高需求的应用能获得足够的设备连接； b) 支持至少 254 个并发设备会话：CUPPS 平台应为逻辑设备提供至少 254 个并发连接，确保设备的访问具有足够的灵活性和并发性； MH/T 0048.12014 12 c) 支持至少 4 个虚拟串口：CUPPS 工作站应提供至少 4 个虚拟串口，用于多种用途，如为其他串口设备提供连接。 d) 串口编号至少支持到 COM255：CUPPS 平台支持的串口编号至少为 255，其中至少包含

34、 4 个虚拟端口，以确保平台具有足够的灵活性来满足较高的连接性要求，而不必修改平台代码。串口编号应符合下述格式：COM1，COM2. COM255。 5.3.16 设备支持中文的要求 对于可打印输出内容的设备，例如BT、BP、PR，应包含符合中文GB18030要求的字库。 5.3.17 网络设置 平台应定制的网络设置的 Windows 注册表键值见表 7。 表7 Windows XP/W indows 7 网络参数 级别 设置 值 HKLMSYSTEMCurrentControlSetServicesTcpipParametersInterfaces 必须 EnablePMTUDiscover

35、y 0x00000001 必须 EnablePMTUBHDetect 0x00000001 必须 KeepAliveInterval 0x00001388 必须 KeepAliveTime 0x00007530 推荐，XP 下 TcpMaxConnectRetransmissions 0x00000003 推荐 TcpMaxDataRetransmissions 0x00000005 推荐，XP 下 TcpWindowSize 0x0000CD50 推荐 MTU 0x0000058C HKLMSYSTEMCurrentControlSetServicesNetBTParametersInter

36、faces 推荐 SessionKeepAlive 0x0000AFC8 5.4 CUPPS 工作站功能 5.4.1 软硬件标准 5.4.1.1 操作系统 CUPPS工作站应满足以下要求： 操作系统要求为 32 位 Win7 Prof essional 版，最低要求是 Windows XP SP2 系统； 默认配置语言为简体中文，其他语言包或输入法可根据需要加载； 如果虚拟机或者类似技术(比如 VMWare 和 Citrix)能够提供一个与前述操作系统等效的运行环境系统(如对应用的内存分配等)，也可以使用。 5.4.1.2 硬件 CUPPS工作站包括的硬件见表8。 MHMH/T 0048.12

37、014 13 表8 平台工作站硬件 功能 描述 计算机 计算机及其内部组件 键盘 每个终端用户工作站应有一个标准的英文101+-的键盘 鼠标 每个工作站都应有一个，也可提供具有鼠标操作功能的键盘 平台工作站硬件的最低性能要求见表9。 表9 硬件性能标准 指标 最小值 硬盘大小 250 GB 内存 4 GB CPU 双核2.0 GHz 网络带宽 100 Mbps 5.4.2 功能 CUPPS工作站应具有以下功能： a) 应用程序管理：CUPPS 工作站应实现应用管理功能； b) 身份验证：CUPPS 工作站应提供认证服务来验证用户是否有权限登录工作站或访问本地网络资源； c) COTS 软件互用

38、性：COTS 软件应能够在 CUPPS 工作站上正常运行，并且不能对工作站或者当地网络带来明显的性能影响或安全风险。COTS 软件不能使用 CUPPS 系统的服务，比如设备等； d) CUPPS 应用要求：CUPPS 软件应能在 CUPPS 工作站上良好的运行，并且不能对工作站或者当地网络带来不合理的性能影响或者安全风险。每个 CUPPS 应用程序应遵循同一套命令标准，以便于查询应用程序版本或平台提供商； e) 事件管理：CUPPS 工作站应实现事件管理功能，以便于应用程序和系统之间使用管理接口进行事件信息的交换； f) 日志：CUPPS 工作站应提供一个用于应用程序支持和调试目的的通用日志接

39、口； g) 菜单：CUPPS 工作站应提供具有安全性的菜单系统； h) 消息：CUPPS 工作站应提供消息传送功能，将管理人员发布的广播消息，在界面中展示给用户； i) 许可：CUPPS 工作站应提供功能实现对 CUPPS 工作站系统资源、网络资源、用户或航空公司数据的管理和安全访问； j) 工作站管理：CUPPS 工作站应提供管理功能以便于 CUPPS 系统管理、支持和使用； k) 存储： CUPPS 工作站应提供一个接口使应用程序能存储数据。 接口应支持临时存储与永久存储； l) 全球统一命名原则：CUPPS 应使用全球统一的原则为 CUPPS 工作站及其设备进行命名； m) 性能：应为

40、CUPPS 工作站定义性能标准，包括登录过程时间、注销过程时间、通讯延迟时间和设备性能等。 5.5 COTS 软件互用 如果一个应用程序可以在工作站上运行，则其为COTS应用程序。如果应用程序因为依赖于CUPPS平台而不能运行，则其为CUPPS应用程序。 MH/T 0048.12014 14 标准的COTS软件有.NET框架、Adobe Acrobat Reader、Microsoft Data Access Components、Microsoft Internet Explorer、VC6 libraries等。 6 平台管理 6.1 状态管理 6.1.1 总体要求 平台状态的定义见表10

41、。 表10 平台状态摘要 状态 描述 pAlt 警报状态，表示平台向CUPPS 工作站发布警报信息。只有当CUPPS 平台管理员发布CUPPS 警报信息时才会进入此状态 pStd 已启动状态，表示平台正在运行，平台的正常操作状态 pStg 正在启动状态，表示平台正在执行其启动引导操作 pStp 已停止状态，表示平台未运行，平台的默认状态 pSpg 正在停止状态，表示平台应执行必要操作来关闭其功能 平台管理状态机见图5。 图5 平台状态机 平台状态机中允许的状态转换见表11。 MHMH/T 0048.12014 15 表11 平台状态间的转换 到达状态 出发状态 pStp pStg pStd p

42、Alt pSpg pStp pStg pStd pAlt pSpg 注： “”表示可以转换；“”表示转换无意义；“”表示不可能转换 工作站管理状态机与远程状态机的交互见表12。 表12 平台状态机远程交互 状态 说明 pAlt 当平台有 CUPPS警报信息发布时，平台通知所有的工作站 pSpg 当平台要停止时，平台停止所有工作站 pStd 当平台完成启动，会启动所有被设置为自启动的工作站 wAlt 当工作站传递 CUPPS警报信息时，向平台报告传递过程 wSpg 当工作站要停止时，向平台报告 wStd 当工作站完成启动，向平台报告其成功完成启动 wZom 当工作站未能退出 wSpg状态时，故障

43、工作站向平台报告该事件 6.1.2 pAlt 状态 6.1.2.1 进入 pAlt 状态 当授权用户向平台发布CUPPS警报信息时， 平台进入pAlt状态， 触发事件。 pAlt状态机见6。 图6 pAlt 状态机 6.1.2.2 pAlt 状态处理过程 当进入pAlt状态后，平台将CUPPS警报信息的以下元素记录到日志中： 输入警报信息的终端用户 ID； MH/T 0048.12014 16 警报信息的内容。 为了监控CUPPS警报信息的分发过程，平台应执行以下操作： 记录一条日志消息表明 CUPPS 警报信息已经开始分发； 记录一条日志消息表明 CUPPS 警报信息已经开始分发给某个特定工

44、作站； 记录一条日志消息表明 CUPPS 警报信息已经完成分发给某个特定工作站； 记录一条日志消息表明 CUPPS 警报信息已经完成分发。 平台会向所有处在wStd、wBsy或wAlt 状态下的工作站发送CUPPS警报信息。警报信息的传输应是非阻塞的，这样向某一个工作站的警报传输不会妨碍向其他工作站的传输。 当有一个CUPPS警报信息传递给工作站后，这个警报会被添加到工作站的消息队列中，这时工作站马上进入wAlt状态。 工作站应主动确认警报信息是否正确收到，如果向某个工作站分发CUPPS警报信息失败，失败信息应记录到日志中。 6.1.2.3 退出 pAlt 状态 出现以下任意一种情况时，平台退

45、出pAlt状态： 平台完成对所有适用工作站的 CUPPS 警报信息的发布； 平台管理员引导平台停止； 平台意外的出现故障。 当平台退出pAlt状态并且在进入下一个状态之前，触发事件。 6.1.3 pSpg 状态 6.1.3.1 进入 pSpg 状态 当CUPPS平台管理员引导平台关闭时 ，平台进入pSpg状态，并记录一条消息说明平台已经停止。当平台进入pSpg状态后，触发事件。 pSpg状态机见图7。 图7 pSpg 状态机 6.1.3.2 pSpg 状态处理过程 当平台进入pSpg状态后，执行以下操作： a) 平台在处理过程中以恰当方式记录以下日志： 1) 进入 pSpg 状态； 2) 停止平台的管理员信息； 3) 开始执行关闭工作站的操作； MHMH/T 0048.12014 17 4) 开始关闭某个特定工作站； 5) 完成关闭某个特定工作站； 6) 完成停止信息的分发。 b) 平台将所有工作站置为 wSpg 状态； c) 平台应向处于以下状态的工作站发送关闭命令： 1) wStd 状态； 2) wStg 状态； 3) wBsy 状态； 4) w