T/CATAGS 63.1-2023 不正常行李交互规范 第1部分：服务平台建设

　　CATAGS

　　中 国 航 空 运 输 协 会 团 体 标 准T/CATAGS 63.1—2023

　　不正常行李交互规范 第 1 部分：服务平台

　　建设

　　Abnormal luggage interaction specification—Part 1: service platform construction

　　2023-05-22 发布 2023-05-22 实施

　　中国航空运输协会 发 布

　　目 次

　　前 言

　　本文件按照GB/T 1.1—2020《标准化工作导则 第1部分：标准化文件的结构和起草规则》的规定起草。

　　本文件是T/CATAGS 63《不正常行李交互规范》的第1部分，T/CATAGS 63《不正常行李交互规范》

　　包括以下部分：

　　——第 1 部分：服务平台建设;

　　——第 2 部分：处理流程;

　　——第 3 部分：流程数据;

　　——第 4 部分：数据接口。

　　本文件由中国航空运输协会归口。

　　请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。

　　本文件起草单位：中国民航信息网络股份有限公司、上海民航华东凯亚系统集成有限公司、中国民航大学。

　　本文件主要起草人：智慧、耿思、胡冰、孙琼巍、于辉、刘王君、潘乃槟、董云杉、王军峰、王道明、黄小东、洪泽琳、毛丹、马晓宁、胡泽。

　　引 言

　　新时代民航高质量发展要求加快推进智慧民航的建设，着力改善旅客出行的便利性和体验。近年来，中国民航大力投入以提升行李服务的水平，推动全行业行李运输的信息化、智能化发展。以往行李丢失是旅客行李服务的痛点, 民航旅客不正常行李服务平台用于解决旅客行李丢失的问题。

　　T/CATAGS 63旨在建立普遍适用于不正常行李处理的业务交互中服务平台建设、处理流程、流程数据，以及数据接口的准则，拟由四个部分构成：

　　——第 1 部分 服务平台建设。目的在于明确不正常行李处理服务平台建设的功能。

　　——第 2 部分 处理流程。目的在于规范不正常行李的处理流程。

　　——第 3 部分 流程数据。目的在于规范不正常行李的流程数据。

　　——第 4 部分 数据接口。目的在于规范不正常行李的数据接口。

　　为促进不正常行李服务平台的统一建设，特制定本文件。

　　不正常行李交互规范 第 1 部分：服务平台建设

　　1 范围

　　本文件规定了不正常行李服务平台(简称服务平台)应具备的主要功能，包括服务平台主体功能、数据存储、数据安全性、服务可用性等级。

　　本文件适用于航空公司、机场等服务平台的建设。

　　2 规范性引用文件

　　本文件没有规范性引用文件。

　　3 术语和定义

　　本文件没有需要界定的术语和定义。

　　4 缩略语

　　下列缩略语适用于本文件。

　　API：应用程序接口(Application Programming Interface)

　　5 主要功能

　　5.1 服务平台主体功能

　　5.1.1 通用要求

　　服务平台应包括不正常行李案件登记、不正常行李案件查询、不正常行李查找匹配、不正常行李案件数据交换、服务平台监控及服务平台管理六大主体功能。

　　5.1.2 不正常行李案件登记

　　服务平台应支持不正常行李案件登记，包括少收行李、多收行李、破损行李、速运行李案件信息的登记，建立基于统一编码规则的案件编号的不正常行李档案。同时应提供对应的案件登记API，为航空公司、机场或第三方用户提供建案功能。

　　5.1.3 不正常行李案件查询

　　服务平台应支持平台用户通过搜索条件查询指定的少收行李档案、多收行李档案、破损行李档案、速运行李档案，并对外提供案件查询API，搜索条件应至少支持平台用户通过档案编号查询。

　　5.1.4 不正常行李查找匹配

　　服务平台应具有少收行李档案与多收行李档案的全网查找与匹配功能，应至少支持如下2种维度的匹配查找：

　　——基于信息项的匹配查找：应至少支持通过航班日期、行李牌号、行李箱颜色、行李箱类型、行李箱外观描述信息项进行匹配查找。

　　——基于图片的匹配查找：应支持基于图片特征值进行匹配查找，应至少提取 2 种图片特征值、综合匹配阈值可根据建设方要求自行设定。如可提取图片颜色和尺度特征值，综合阈值可设为 70 以上。

　　5.1.5 不正常行李案件数据交换

　　服务平台应具有与其他系统进行不正常行李案件交换共享功能。服务平台支持与其它系统通过API方式进行不正常案件数据共享和服务协同。不正常行李案件数据交换功能还应具有集成协议转换、权限校验、加密、压缩、交换过程监控等多种功能，对用户权限、交换规则进行管理，通过数据交换引擎保证与其他系统间数据有效交换共享。

　　5.1.6 服务平台监控功能

　　服务平台监控应包括对各子模块、子服务存活状态、各服务响应状态、业务异常监控、消息中间件状态监控、数据库中间件状态监控、缓存中间件状态监控、系统报警的监控处理，负责监控整个服务平台运行状态。应包含如下主要功能模块：

　　——服务平台参数与报警参数配置：可对服务平台的各项参数进行配置，包括配置各个监控参数的报警阈值等。

　　——监控各系统组件状态：能够对服务平台各系统模块状态进行监控。

　　——记录服务平台日志和异常信息：能够记录服务平台日志，显示与查询异常信息。

　　——监控对象启停控制：能够对被监控对象进行启动、停止、重启操作。

　　——及时了解当前监控信息，当监控对象的性能参数超过告警阈值时，及时产生报警：告警阈值能够分级设置，不同级别产生不同告警，通过多种告警手段提供现场和远程告警，并且可定制发送方式和告警优先级。

　　——通过图形化方式直观地显示监控信息，并能够进行统计分析。

　　——数据交换服务总线：能够对交换服务总线进行监控，包括每个数据交换服务统计信息及运行状态等。

　　——安全管理：能够对安全管理进行监控，包括系统连接、登录、访问信息等。

　　5.1.7 服务平台管理功能

　　服务平台应能够为不同用户、岗位分配不同权限，记录用户操作日志，保障系统使用安全。主要包含：

　　——部门/用户管理，根据用户建立各类用户的组织结构和用户;

　　——功能权限管理，为不同岗位开放不同的模块功能，使用便捷、安全;

　　——数据权限管理，航空公司、机场用户设置可查询、操作、统计的数据规则，保证数据使用安全;

　　——操作日志记录，记录日志，帮助回溯关键操作。

　　5.2 数据存储

　　5.2.1 数据存储方式

　　服务平台所有数据应根据数据特性、采用冷热分离的分级存储机制，同时应支持数据的异地存储备份。

　　5.2.2 数据存储时间

　　服务平台应支持1年的不正常行李档案数据存储能力、1个月的图片数据存储、支持1000次/秒的并发处理。服务平台应保存所有用户的操作日志记录，宜至少保存1年以上的用户操作信息记录，具体保存时间可根据建设方实际情况自行设定。

　　5.2.3 其他要求

　　其它要求主要包括：

　　——数据存储能力应能够可持续扩展;

　　——应支持为服务平台用户提供以案件类型、旅客、航班、机场等为主题的多维分析与统计;

　　——应能够为数据服务提供底层数据支持，具备高效的数据抽取能力。

　　5.3 数据安全性

　　5.3.1 数据加密

　　数据存储加密应满足以下要求：

　　——保障密码和其他身份鉴别信息不被泄露。

　　——在重要数据的存储过程中进行适当加密，确保重要数据不被泄露。

　　在重要数据传输过程中，应对重要数据进行适当加密。

　　5.3.2 数据脱敏

　　对于涉及旅客信息的数据，如旅客姓名等数据字段，应采取适当数据脱敏措施，重要数据用于开发、测试、外包、非生产环境中时应进行适当变形，确保数据安全的基础上保障数据可用。

　　5.3.3 数据存储控制

　　授权用户的可操作对象和可操作类型应受控制。系统应建立数据操作日志，记录所有非法操作的企图。

　　5.4 服务可用性等级

　　5.4.1 系统性能

　　服务平台应采用规划合理、运行高效的中间件和产品，应具有处理大量并发事务的能力，并具有灵活的可扩充性和高度的可配置管理性。

　　系统响应应满足以下要求：

　　——应确保系统所有功能均能正常使用，且不影响关联系统的功能、性能;

　　——服务平台数据的储存方式应支持高效的重复利用、不应出现数据丢失;

　　——关键控制点数据请求响应时间应小于 500ms。

　　5.4.2 系统可靠性

　　服务平台全年一级故障累计时间应不超过260分钟，可用性应不小于99.95%;全年二级故障累计时间应不超过520分钟，可用性应不小于99.9%。

　　注：故障等级定义如下：

　　——一级 (Severity 1)：全局性生产系统停顿，系统服务核心功能不可用或系统提供的服务完全停止;

　　——二级 (Severity 2)：系统提供的部分功能不可用或系统性能下降，大范围用户感觉不便，核心功能可以维持。

　　5.4.3 其他

　　服务平台全年总计划停机时间应不超过18小时，超过3小时的计划停机全年应不超过4次。