CTSO-2C611 机载航空数据处理及相关数据库

日

日期：2025 年 8 月 18局长授权

批准：

中国民用航空技术标准规定

本技术标准规定根据中国民用航空规章《民用航空材料、零部件和机载设备技术标准规定》（CCAR37）颁发。中国民用航空技术标准规定是对用于民用航空器上的某些航空材料、零部件和机载设备接受适航审查时，必须遵守的准则。

机载航空数据处理及相关数据库

1.目的

本技术标准规定（CTSO）适用于为机载航空数据处理及相关数据库申请技术标准规定项目批准书（CTSOA）的航空数据供应商。本 CTSO 规定了机载航空数据处理及相关数据库为获得批准和使用适用的 CTSO 标记进行标识所必须满足的最低标准要求。

2.适用范围

a. 本 CTSO 所规定的机载航空数据是指用于支持导航、飞行计划、地形感知和其他航空应用的数据（如导航数据、地形及障碍物数据以及机场地图数据等）。其他用途可能包括新颖航空应用（如动态电子航图等），此类应用的数据质量要求（DQR）与预期功能可能需要制定新政策或问题纪要。各类机载系统和设备为了匹配特定机型所用到的软件编程引脚（用于可选项软件）、配置文件、航空器个性化模块、注册表、参数数据项或查找表（即各类机载系统的数据库）等，不适用于本 CTSO。

CAAC CTSO-2C611

b. 本 CTSO 适用于自其生效之日起提交的申请。本 CTSO 是对申请人数据处理流程和质量管理的要求，数据处理流程、质量管理系统及数据处理工具的重大更改，需要向局方报告，获得批准后方可实施。

c. 按本 CTSO 批准的数据质量要求和数据处理流程进行的数据更新，无需局方另行批准。

d. 按本 CTSO 批准生产的数据库可以装于其兼容设备，当该兼容设备获得装机批准时，该数据库可以随该兼容设备装机，无需局方另行批准。

3.管理要求

a. CTSOA 类别

按本 CTSO 获取的机载航空数据处理及相关数据库 CTSOA 分为1 类 CTSOA 和 2 类 CTSOA 两种类别。

( ⅰ ) 1 类 CTSOA

1 类 CTSOA 基于航空数据供应商和其客户（通常为航空电子设备制造商）之间商定的数据要求。1 类 CTSOA 确认数据供应商所交付的航空数据库满足本 CTSO 的要求，但不对数据库与机载系统或设备的兼容性进行确认。1 类 CTSOA 确认生产航空数据库的流程符合本 CTSO 的要求，适用于数据供应商、运营人或终端用户、航空电子设备制造商或其他单位。1 类 CTSOA 与具体审定项目（如 TC/STC或设备 CTSOA）或设备型号无关。数据质量要求可以由航空数据供

- 2 -

应商定义并由其客户接受，也可由数据供应商与其客户共同协商确定。

( ⅱ ) 2 类 CTSOA

2 类 CTSOA 确认数据供应商所交付的航空数据库满足本 CTSO要求，并且与特定航空电子系统兼容，支持其实现预期功能。2 类 CTSOA 通过列出相关设备来确认其与支持预期功能的DQR 的兼容性。终端用户可以在数据库运行审批流程或经批准的维修方案中使用2 类 CTSOA 作为数据库完好性的证据。2 类 CTSOA 只适用于列于该CTSOA 的设备，申请人负责识别使用该数据库的所有设备。

2 类CTSOA 适用设计批准持有人（DAH）（设备CTSOA、TC/STC）或能够制定与 DAH 的 DQR 完全相同DQR 的数据供应商。这个完全相同可以通过建立设计同一性来获得，也可以通过 DAH 与申请人之间的许可协议来获得。无论如何，完全相同性需要所有参与者之间有正式协议（如 DQR 协议、许可协议等）。使用许可协议或设计同一性方法时，仍由 DAH 负责表明（如使用系统验证测试、抽样检查等） DQR 与设备的预期功能一致。

一些航空器和航空电子设备制造商在 RTCA/DO-200B 发布前已获得相关系统的批准。对于这些系统，申请 2 类 CTSOA 前，申请人必须确定航空电子设备的 DQR。

一些作为应用集成商申请 2 类 CTSOA 的机构，可能雇佣另一机构来进行某些阶段的航空数据处理，如开发打包工具供其他机构来准备和分发数据。然而，无论局方是否认可该被雇佣机构的流程符合

- 3 -

RTCA/DO-200B 的要求，申请人数据处理所用的流程必须是申请人自己的。申请人必须向局方表明其所定义的流程是有效的，并且有相应的批准、控制和监督机制来确保在申请人机构之外执行的工作同样符合要求。对于被雇佣为申请人工作的机构，他们所使用的流程以及他们所维护的记录必须在申请人的控制之下，并且可被访问。

b. 质量管理系统（QMS）

按本 CTSO 申请机载航空数据处理及相关数据库 CTSOA 的申请人应符合 RTCA/DO-200B 要求。RTCA/DO-200B 是用于开发、评估变更及支持数据质量管理实施的标准，其目的是通过要求机构建立包含航空数据处理流程相关要求的 QMS，来解决航空数据处理流程的具体问题。

申请人建立和保持符合 RTCA/DO-200B 要求的 QMS，即可被视为符合了 CCAR-21 部中对技术标准规定项目批准书申请人和持有人的质量系统相关要求。

4.技术要求

申请人应表明对 RTCA/DO-200B 的符合性。此外，根据适用性，还需要表明符合以下目标要求：

a. 获得 CTSOA 后的责任

申请人获得 CTSOA 后，应该承担以下责任，并且在质量管理系统的相关程序中进行规定：

（i）错误报告

- 4 -

持证人必须向客户（应用提供商，终端用户等）、局方以及数据提供者（如适用）报告已发布的可能对运行安全产生不利影响的故障、错误或有缺陷的数据；必须及时提供与安全相关的错误或缺陷的初始报告，确保错误或缺陷能被迅速处理（自发现起 48 小时内）；必须通过程序文件确保相关人员接收到有错误或缺陷数据的告警。在使用受影响的数据之前，必须考虑任何与安全相关的数据告警。

( ⅱ)保持质量管理系统

持证人必须持续保持 RTCA/DO-200B 第 2.5 节规定的质量管理系统。针对 QMS 中影响数据质量目标的所有更改，持证人必须在更改实施前向局方报告。

(ⅲ)数据处理流程的更改

对已获得 CTSOA 的设计小改，必须遵照局方认可的程序向局方报告更改。对于设计大改，持证人必须证明符合性，并在局方批准后方可实施。数据处理流程变更的报告程序必须包括数据处理流程中所用工具的更改的报告程序。

(ⅳ)审计

必须按照 RTCA/DO-200B 第 3 章中的说明定期对本 CTSO 和DO-200B 的目标进行内部审计，两次审计之间的最长时间间隔不超过一年。审计可以是全部的，也可以是增量式进行，但必须保证每年审计所有的目标。对于审计中发现的 RTCA/DO-200B 第 3.4 节中所述的任何重大不符合项，必须报告局方。局方根据与持证人确认

- 5 -

的程序进行定期审计，审计的时间间隔使用基于风险的原则来确定，综合考虑 CTSOA 类型、持证人 QMS 的成熟度以及持证人内部审计计划的执行情况等因素。

( ⅴ )当不再满足 CTSOA 的要求时，持证人必须通知所有用户和局方。

(ⅵ) 对应每一个航空数据库的发布，持证人必须同时出具一份发布声明，明确相应 CTSOA 的状态，声明符合性，并提供已知的偏离和更改信息。发布的声明应包括以下内容：

  CTSOA 的状态（如有效、暂停、失效等）；

 所有对约定DQR 的偏离（如由于源/处理错误而删除程序（即完整性更改）等）；

 所有的数据更改（参照 RTCA/DO-200B 第 2.4.2 节）。

发布声明的形式可以是随附的文档、带有下载文件的电子公告或网页上的发布信息。

当持证人不再符合持有该 CTSOA 的条件时，必须申请撤销该CTSOA。CTSOA 不可转让，并在持证人申请撤销或由局方终止之前有效。

(ⅶ)告知航空数据用户 CTSOA 的状态变化

持证人必须将 CTSOA 的状态告知航空数据用户。持证人还必须了解并向数据用户提供数据链条中前端参与者的 CTSOA 状态的任何变更，回溯范围直至但不包括 ICAO 缔约国的航空资料汇编（AIP）。通知的方式应足够及时，以确保用户在接受下一次数据

- 6 -

更新之前可以对 CTSOA 的状态变化做出反应。

注：CTSOA 状态变化的通知方式可以是在网站上发布 CTSOA的副本，并建立在更新数据之前关联该网站的程序。

b. 对于申请人的数据处理要求

（i）数据的验证和确认

申请人可以从航空数据链条中的任何数据供应商处接收数据。如果数据供应商提供的数据符合 RTCA/DO-200B 或先前版本，并已经得到民航局的认可（获航空数据 CTSOA），根据 RTCA/DO-200B第 1.5 节和2.3.3（3），可以不要求确认接收的数据是否符合 DQR。对于 AIP 中公布的数据，以及通过官方政府来源（需被民航局认可）或权威来源（需被民航局认可，参考 RTCA DO-200B 附录 A）提供的数据，也可以不要求确认数据是否符合 DQR 要求。建议尽可能使用验证或确认技术来识别数据错误。

申请人必须在交付前通过民航局批准的程序对从非权威来源获得的数据进行验证和确认（参考 RTCA/DO-200B 附录 C）。

数据处理保证等级（DPAL）表明数据处理过程中用来确保数据质量所进行的验证和确认活动工作量的严苛级别。DPAL 取决于基于系统架构的初步系统安全性评估的风险分配中对数据的完好性需求（参考 RTCA/DO-200B 附录 C 第 C.2 节、AC 23.1309-1、AC 25.1309-1、ARP 4754A 和 ARP 4761）。如果处理多个 DPAL 的混合数据，需按照其 DPAL 等级最高的标准进行处理，或者采取分区和保护措施，将不同 DPAL 的数据分开处理，以确保较高 DPAL 的

- 7 -

数据集遵循较高的严格性要求。无论如何，DPAL 应该与由数据引起的故障或可用性影响所产生的最严格的要求相一致（参考RTCA/DO-200B，附录 C，C.2.3 节）。

申请人需要依据 RTCA/DO-200B 附录 C、RTCA/DO-201A 第

2.1.7 节和附录 B 提供的可接受技术来验证和确认导航和其他航空数据；依据 RTCA/DO-272D 第 3.10 节提供的可接受技术来验证和确认机场测绘数据；依据 RTCA/DO-276C 第 6.1.4 和 6.1.5 节提供的可接受技术来验证和确认地形和障碍物数据。

（ii）数据安保

申请人的数据处理程序必须定义确认所接收的数据未被破坏的方法，保护存储的数据免受损坏的方法，以及向用户提供验证他们从申请人处收到的数据未被破坏的方法。

为防止故意损坏的可能性，申请人必须持续记录表明实现数据安保目标所采取的安保规定。申请人的数据安保规定必须描述所实施的技术和组织控制，以确保从已知的来源接收数据，并防止在处理和交换数据期间的故意损坏。数据安保规定必须描述如何识别、评估和减轻安保威胁，并防止对数据或工具的未经授权的访问。

DPAL 越高的数据所需的控制和规定应该越严格。此外， 为了保护以更高的项目研制保证等级（IDAL）开发的数据，安全规定需要解决在较低 DPAL 下处理的数据的混合以及影响更关键数据的任何潜在漏洞。

（iii）更改 DQR 和识别不符合要求的数据

- 8 -

申请人必须在构型管理计划中明确建立新构型基线的过程。

DQR 的更改必须在数据供应商和接收数据的用户之间进行协调。申请人应该提前通知 DQR 更改情况，以便让数据链条的后续参与者（航空电子设备制造商、原始设备制造商（OEM）和可能的运营人或终端用户）有充足的时间来评估更改的影响。

如果将不符合 RTCA DO-200B 中三个 DPAL 等级要求的数据与符合 DO-200B 要求的数据一起交付，那么商定的 DQR 应将不符合要求的数据确定为 DPAL4，表明其可能不满足安全目标。DPAL4 数据必须通过民航局接受的方式与符合要求的数据区分开来。运营人或终端用户最终负责确保 DPAL4 数据满足其预期应用的质量要求。

（iv）客户化数据

客户化数据是来源于运营人或终端用户并由其全权负责且仅供其自身使用的航空数据。该类数据的验证、确认和损坏检测方法及其后续更新的责任完全由运营人或终端用户承担，数据供应商不承担责任。1 类和 2 类 CTSOA 数据供应商必须确保客户化的数据不会分发给请求客户化数据的运营人或终端用户以外的其他单位。1类 CTSOA持证人必须充分识别客户化数据，以支持 2 类 CTSOA 持证人满足这一分发限制。

（v）工具鉴定

在进行工具鉴定时，使用 RTCA/DO-330《软件工具鉴定注意事项》所推荐的过程和目标表明符合性，并可参考 RTCA/DO-200B 附录 D 对 RTCA/DO-330 做调整。

- 9 -

申请人需要提供所有必要的工具鉴定数据作为 CTSOA 申请的一部分，对工具鉴定数据的更改需遵循 CTSOA 的更改流程。同时， 申请人必须提交文件（例如，工具完成总结（TAS）），表明工具鉴定任务已完成。

5.偏离

如果采用替代或等效的符合性方法来满足本 CTSO 规定的最低标准要求，则申请人必须表明数据处理流程保持了等效的安全水平。申请人应按照 CCAR-21 第 21.368 条（一）要求申请偏离。

6.标记

对于交付的航空数据库，应按照本 CTSO 的 4.a. (ⅵ) 的要求提供发布声明，此声明即视为对本标记的符合。

7.申请资料要求

申请人必须向负责该项目审查的人员提交相关技术资料以支持设计和生产批准。提交资料包括 CCAR-21 第 21.353 条（一）1 规定的符合性声明和航空数据说明资料副本。说明资料包含以下内容：

a. 单位信息：机载航空数据生产单位的名称和地址。

b. CTSOA 类别：简要说明申请的 CTSOA 类别：1 类 CTSOA 或

2 类 CTSOA。

注：对于 2 类 CTSOA，申请书必须标识出兼容系统的件号/型号（硬件、软件和数据库）。兼容系统的更改会导致DQR的更改，在航空数据产品评审前，申请人应尽早与兼容系统

- 10 -

DAH 协调更改，确保更新的航空数据符合新的需求。

c. 数据集：简要说明申请书中包含的数据集类型（例如导航、地形、障碍物、机场地图等）。

d. 数据包：申请数据包必须包括所有授权版本的航空数据处理和质量管理要求的计划和程序。2 类 CTOSA 申请人还必须提供能够证实 DQR 的材料，表明航空数据支持所要安装设备的预期功能，并且是适航批准文档的一部分。数据包的复杂程度取决于数据的重要性，这与使用数据的产品有关。数据包必须包括，但不限于：

( ⅰ)符合性文件

RTCA/DO-200B第2.2节所描述的符合性文件的副本一份。包括RTCA/DO-200B第2.2.1节所述的符合性计划，以及RTCA/DO-200B第2.2.2节所述的支持申请人符合性的所有文件。符合性计划包括一个完整的RTCA/DO-200B符合性矩阵（RTCA/DO-200B，附录F），以及本CTSO附录中的符合性目标矩阵。

(ⅱ)数据处理描述

根据RTCA/DO-200B附录E第3项中描述的数据处理程序，提供数据处理、检查和测试程序（包括过程控制和供应商来料控制）的高阶描述或流程图。包括DQR更改、数据处理程序更改以及航空数据处理实施变更的应对机制。说明所有交付的航空数据的可追溯性和构型控制的方法。

- 11 -

(ⅲ)兼容性

2类CTSOA的申请人必须提交一份兼容系统清单，包括件号/型号（硬件、软件和数据库）。对于这些系统，申请人应通过表明（例如，使用系统验证测试、抽样检查等）DQR与相关设备的预期功能一致来确保与预期应用的兼容性。如果相关设备尚未获得适航批准，则申请人需在申请材料中予以说明。增加兼容设备清单时，需要与OEM/DAH协商来完成。局方建议对个别数据集进行定期抽样检测（例如，通过仿真，测试平台环境等）以证明持续的兼容性。

(ⅳ)数据错误的处理和报告程序

数据错误被认为是对数据供应商质量系统的偏离，即未满足DQR的要求。申请人必须有相应的程序来处理在分发的数据中发现的不安全状况或错误，并制定和分发纠正措施给所有受影响的各方（如数据源、数据库用户、局方）。程序中必须描述如何与数据供应商就所有疑似和确认的源数据错误进行沟通，以及如何告知用户和局方数据错误可能对运行使用的安全产生不利影响。申请人的程序必须描述如何在没有不当延迟的情况下（在发现/知道后48小时内）通报CTSOA状态的变化和任何可能对运行安全产生不利影响的经确认的数据错误。有可能对安全产生不利影响的数据错误包括但不限于最后进近航段（FAS）数据块的改变、航径和航段终止点的“航段类型”编码，以及关键和必要的数据元素。

- 12 -

8.引用文件

DO-200B Standards for processing aeronautical data, June18, 2015. DO-330 Software Tool Qualification Considerations, Dec. 13, 2011. RTCA/DO-201A Standards for aeronautical information, April 19,

2000.

RTCA/DO-272D User requirements for aerodrome mapping information, October 12, 2001.

RTCA/DO-276C User requirements for terrain and obstacle data, March 5, 2002.

RTCA 文件可从以下地址订购：

Radio Technical Commission for Aeronautics, Inc.

1150 18th Street NW, Suite 910, Washington D.C. 20036

也可通过网站 www.rtca.org 订购副本。

- 13 -

CAAC CTSO-2C611

附录符合性目标矩阵

目标编号

符合性目标

CTSO 索引

申请人参考文件名或文件编号

目标是否满足

（是,否,待定,不适用）

备注

A.1 CTSOA 批准后的持证人责任

1-1

持证人必须向用户、局方以及数据提供者报告已发布的可能对运行安全产生不利影响的故障、错误或有缺陷的数据。

4.a.( ⅰ)

1-2

迅速及时提供与安全相关的错误或缺陷的初始报告，确保错误或缺陷能被迅速处理。

1-3

必须通过程序文件确保相关人员接收到有错误或缺陷数据的告警。

1-4

在使用受影响的数据之前，必须考虑任何与安全相关的数据告警。

1-5

持证人必须持续保持 RTCA/DO-200B 第 2.5 节所述的 QMS。

4.a.(ⅱ)

1-6

针对 QMS 中影响数据质量目标的所有更改，持证人必须在更改实施前向局方报告。

1-7

对现有 CTSOA 的设计小改，必须遵照局方认可的程序向局方报告更改。

4.a.(ⅲ)

1-8

对于设计大改，持证人必须证明符合性，并在局方批准后方可实施。

1-9

数据处理流程变更的报告程序必须包括数据处理流程中所用工具的更改的报告程序。

1-10

必须按照 RTCA/DO-200B 第 3 章中的说明定期对本 CTSO 和 DO-200B 的目标进行内部审计，两次审计之间的最长时间间隔不超过一年。

4.a.(ⅳ)

1-11

审计过程中发现的 RTCA/DO-200B 第 3.4 节中所述的任何重大不符合项，必

- 14 -

须报告局方。

1-12

当不再满足 CTSOA 的要求时，持证人必须通知所有用户和局方。

4.a.(ⅴ)

1-13

对应每一个航空数据库的发布，持证人必须同时出具一份发布声明，明确相应CTSOA 的状态，声明符合性，并提供已知的偏离和更改信息。

4.a.(ⅵ)

1-14

发布声明中必须包括 CTSOA 的状态。

1-15

发布声明中必须包括所有对约定DQR 的偏离。

1-16

发布声明中必须包括所有的数据更改。

1-17

当不再满足 CTSOA 要求时，持证人必须向局方申请撤销 CTSOA。

1-18

持证人必须将 CSTOA 的状态告知航空数据用户。

4.a.(ⅶ)

1-19

持证人必须知晓并向航空数据用户提供数据链条前端参与者（直到但不包括缔约国 AIP）的 CTSOA 状态的任何变化。

1-20

通知的方式应足够及时，以确保用户在接受下一次数据更新之前可以对CSTOA 的状态变化做出反应。

A.2 数据供应商对本 CTSO 的符合

2-1

申请人必须在交付前通过民航局批准的程序对从非权威来源获得的数据进行验证和确认。

4.b.( ⅰ)

2-2

申请人的数据处理程序必须定义确认所接收的数据未被破坏的方法，保护存储的数据免受损坏的方法，以及向用户提供验证他们从申请人处收到的数据未被

4.b.(ⅱ)

- 15 -

破坏的方法。

2-3

为防止故意损坏的可能性，申请人必须持续记录表明实现数据安保目标所采取的安保规定。

2-4

申请人的数据安保规定必须描述所实施的技术和组织控制，以确保从已知的来源接收数据，并防止在处理和交换数据期间的故意损坏。

2-5

数据安保规定必须描述如何识别、评估和减轻安保威胁，并防止对数据或工具的未经授权的访问。

2-6

4.b.(ⅲ)

2-7

DQR 的更改必须在数据供应商和接收数据的用户之间进行协调。

2-8

DPAL4 数据必须通过局方接受的方式与任何符合要求的数据区分开来。

2-9

数据供应商必须确保客户化的数据不会分发给请求客户化数据的运营人或终端用户以外的其他单位。

4.b.(ⅳ)

2-10

申请人必须提交文件表明工具鉴定任务已完成。

4.b.(ⅴ)

- 16 -

Number：CTSO-2C611

Date of approval：August 18, 2025

Approved by：Xu Feng

China Civil Aviation Technical Standard Order

This China Civil Aviation Technical Standard Order (CTSO) is issued according to Part 37 of the China Civil Aviation Regulations (CCAR-37). Each CTSO is a criterion which the concerned aeronautical materials, parts or appliances used on civil aircraft must comply with when it is presented for airworthiness certification.

Airborne Aeronautical Data Processes and Associated Databases

1. Purpose.

This China Civil Aviation Technical Standard Order (CTSO) is for

manufacturers seeking airborne aeronautical data processes and

associated databases CTSO authorization (CTSOA). This CTSO specifies the minimum performance standards that airborne aeronautical data

processes and associated databases must meet for approval and identification with the applicable CTSO marking.

2. Applicability.

a. Aeronautical data of this CTSO designate to data used for aeronautical applications such as navigation, flight planning, terrain awareness, and other purposes (e.g., navigation data, terrain and obstacle data, and airport mapping data). Other applications may include new and novel aeronautical applications (e.g., dynamic electronic charts, etc.), for which the data quality requirements and intended functions may require

CAAC CTSO-2C611

new policy development, or issue papers. Software programming pins (for selectable software option), configuration files, aircraft personal modules, registries, parameter data items, or lookup tables used by airborne systems and equipment to adapt equipment to the aircraft (i.e., airborne system databases) are not applicable.

b. This CTSO affects new applications submitted after its effective date. It describes the requirements for the applicant’s data processing procedure, quality management, and data quality. However, any major change to data processing procedures, quality management systems, or data processing tools must be reported to the authority and may only be implemented after its approval.

c. Data updates under the authorized processing procedure and quality requirements of this CTSO have no needs to go through the change approval process.

d. Databases produced under the approval of this CTSO may be installed in their compatible equipment. When such compatible equipment obtains installation approval, the database may be installed along with the compatible equipment without separate approval from the authority.

3. Management Requirements.

a. CTSOA Categories

The airborne aeronautical data processes and associated databases CTSOAs authorized under this CTSO are classified into two types: Type 1 CTSOA and Type 2 CTSOA.

(i) Type 1 CTSOA

Type 1 CTSOA are based on data requirements agreed upon

between a data supplier and their customer (typically an avionics

manufacturer), a Type 1 CTSOA provides recognition of the aeronautical databases meeting the objectives ofthis CTSO with no identified

compatibility with an aircraft system or equipment. A Type 1 CTSOA

ensures the processes for producing the aeronautical data meets the

objectives ofthis CTSO. This CTSOA applies to data suppliers, operators / end-users, avionics manufacturers, or others. A Type 1 CTSO A is not

associated with a specific certification project (such as a TC, STC, or CTSOA) or equipment type. Data quality requirements(DQRs) can be defined by the data supplier and accepted by their customer, or can be agreed upon between them.

(ii)A Type 2 CTSOA

A Type 2 CTSOA provides recognition of the aeronautical databases meeting the objectives ofthis CTSO and the compatibility of the

delivered data with particular avionic systems supporting an intended function. A Type 2 CTSOA recognizes compatibility with the DQRs

necessary to support an intended function by listing the associated

equipment. An end-user can utilize a Type 2 CTSOA as evidence of

database integrity during the operational approval process or for an

approved maintenance program. A Type 2 CTSOA is only applicable for the equipment listed on the CTSOA, and the applicant is responsible for identifying all equipment utilizing the relevant databases.

A Type 2 CTSOA applies to a design approval holder (DAH)

(TC/STC/CTSOA) or to a data supplier who can establish its data

requirements are identical to those defined by a design approval

holder(DAH). Achievement of this identicality can be done by either

establishing design equivalency or by a licensing agreement between the DAH and the entity seeking approval. Regardless, identicality requires

formal agreement between all participants (e.g., agreement to DQRs,

licensing agreements, etc.). When under license or using design

equivalence, the DAH remains responsible for demonstrating (e.g., using system verification tests, sampling checks, etc.) the DQRs are consistent with the intended function of the equipment.

Certain aircraft and avionics manufacturers have obtained approval for systems prior to the issuance of RTCA/DO-200B. For such systems, applicants must identify the DQRs for the avionics prior to application for a Type 2 CTSOA.

Many organizations seeking a Type 2 CTSOA as an application integrator may employ other organizations to do certain phases of their aeronautical data processing. A typical model for this arrangement would entail creating a packing tool for the other organizations to use to prepare and distribute data. However, regardless of whether the authority recognizes the other organizations as RTCA/DO-200B compliant for their processes, the processes used for the data processing must be the applicant ’s own. Applicant must demonstrate his defined processes are effective and have the appropriate approval, control, and oversight mechanisms to ensure compliance when being performed outside of his organization. For organizations working for the applicant, the processes they use, as well as the records they maintain, must be under the applicant ’s control and accessible.

b. Quality Management System (QMS)

Applicants seeking an airborne aeronautical data processes and associated databases CTSOA under this CTSO should comply with RTCA/DO-200B. RTCA/DO-200B provides requirements to develop, assess change, and support implementation of data quality management, it is intended to address the specific issues of the aeronautical data processes by requiring organizations to establish an acceptable aeronautical data processing QMS.

An applicant who establishes and maintains a QMS comply with RTCA/DO-200B is deemed to meet the quality system requirements for both applicants and holders ofa CTSOA specified in CCAR-21.

4. Technical Requirements.

Applicants should demonstrate his compliance with RTCA/DO- 200B. In addition, where applicable, compliance with the following objective requirements should also be demonstrated:

a. CTSOA post acceptance responsibilities

The requirements for maintaining an CTSOA privileges are as follows, which should be defined within the relevant procedures ofthe QMS:

(i) Error Reporting

CTSOA holder must report to customers (application provider, end-user, etc.), the CAAC and to source (if applicable) any failure, malfunction, or defect in the distributed data having potential to adversely affect the safety of operational use. The initial reporting of confirmed safety-related errors or defects must be timely and prompt (within 48 hours of detection/knowledge) to ensure swift resolution. CTSOA holder must endeavor, through documented procedure, to ensure receipt of data alerts reporting safety-related errors or defects. Any safety-related data alerts prior to use of the

affected data must be considered.

(ii) Maintain a QMS

The CTSOA holder must maintain a QMS as described in RTCA/DO-200B, section 2.5. All changes made to the QMS affecting the data quality objectives must be reported to the authority before their implementation.

(iii) Changes to data process

Minor design changes for an existing CTSOA must be submitted in accordance with procedures agreed to with the authority. CTSOA holder must substantiate major design changes, and the authority must accept them prior to their implementation. Procedures for reporting of changes to the data process must also address changes to tools used in its data process.

(iv) Auditing

CTSOA holder must perform periodic internal audits of both CTSO 2C612 and RTCA/DO-200B objectives as described in RTCA/DO-200B, section 3, with the maximum time between audits not to exceed one year. Audits may be total or conducted incrementally, as long as they audit all the objectives at least annually. Any major non-conformities as described in RTCA/DO-

200B, section 3.4, must be reported to the authority. Additionally, the authority may perform periodic audits in accordance with procedures agreed to by the CTSOA holder and the authority. Scheduling of periodic authority audits should use a risk-based approach to determine the appropriate intervals considering such factors as the type of CTSOA, maturity of the CAAC/data supplier relationship, and evidence the data supplier's internal audit program is performing adequately.

(v) The CTSOA holder must notify all users and the authority when no longer comply with the conditions of the CTSOA.

(vi) The CTSOA holder must provide a release statement with each database distribution to broadcast the identified CTSOA status, state its compliance, and provide information on known deviations and alterations. The release statement must include:

  CTSOA status (e.g., current, suspended, expired, etc.);

  Any deviations to the agreed DQRs (e.g., deletion of procedures due to source / processing errors (i.e., completeness change), etc.).

  Any data alteration (reference RTCA/DO-200B, section 2.4.2).

The release statement may be in the form of an enclosed document, an electronic posting with the download files, or on the web.

The CTSOA holder must surrender or withdraw the CTSOA if he no longer uphold its terms and conditions. The CTSOA is not transferable and is effective until surrendered or withdrawn by its holder, or terminated by the authority.

(vii) Notification ofCTSOA Status Changes to Data customers

The CTSOA holder must notify his data customers of the status of the CTSOA, be aware of and provide any change in status of CTSOAs (or foreign acceptance, including designation of the foreign authority acknowledging the foreign source’s compliance to RTCA/DO-200B and the means of approval or acceptance) for previous data chain participant(s) up to, but not including, a Contracting State’s Aeronautical Information Publication (AIP). The method of notification must be timely to ensure customers can react to changes in the status of a CTSOA before they accept the next data update.

Note: An example of this notification requirement might consist of posting a copy of the CTSOA on a website for customers, with a procedure to reference the site before updating

data.

b. Requirements for Data suppliers

(i) Data Verification and Validation

Applicants may receive data from any data supplier in the

aeronautical data chain. If a data supplier has complied with the requirements of RTCA/DO-200B, or previous version as

evidenced by the authority, the responsibility to validate the incoming data meets the DQRs is discharged (reference

RTCA/DO-200B, section 1.5 and 2.3.3 (3)). For data published in the AIP, provided via an official government source (as

recognized by the authority), or an authoritative source (as

recognized by the authority (reference RTCA/DO-200B,

appendix A)), the responsibility to validate the incoming data meets the DQRs is discharged. The use of verification or

validation techniques whenever possible to catch data errors is recommended.

Applicants must verify and validate data obtained from non- authoritative sources through an approved process prior to

delivery.

The level of rigor representing the amount of verification and validation tasks performed during data processing to assure data

quality is known as data process assurance level, or DPAL. The

DPAL is determined by the integrity requirement of the data

through allocation of risk using a preliminary system safety

assessment of the system architecture (reference RTCA/DO-

200B, appendix C, section C.2, AC 23.1309-1, AC 25.1309-1,

ARP 4754A, and ARP 4761). For data processes with a mixture ofDPALs, then the higher DPAL is recommended across a mixed data set. Otherwise, the applicant must employ partitioning and

protection to ensure the higher DPAL data set utilizes the higher rigor. Regardless, the DPAL should be consistent with the tightest requirements derived from malfunction or availability effects

caused by the data (reference RTCA/DO-200B, appendix C, section C.2.3).

Acceptable techniques for the verification and validation of

navigation and other aeronautical data are in RTCA/DO-200B,

appendix C and RTCA/DO-201A, sections 2.1.7 and appendix B. Acceptable techniques for the verification and validation of

airport mapping data are in RTCA/DO-272D, section 3.10.

terrain and obstacle data are in RTCA/DO-276C, sections 6.1.4 and 6.1.5.

(ii) Data Security

The applicant's data processing procedures must define the means of confirming data he receives is not corrupted, his means to protect stored data from corruption, and what methods he provides the user to verify the data they receive from him is not corrupted.

To protect from the possibility of intentional corruption, the applicant must maintain records showing what data security provisions he implement to accomplish these objectives. His data security provisions must describe both the technical and organizational controls he implements to ensure receive data from known sources and to prevent intentional corruption during processing and exchange of data. Provisions for data security must describe how the applicant identify, assess, and mitigate security threats and prevent unauthorized access to data or tools.

The higher the DPAL the more rigorous controls and protocols are needed to implement. Additionally, to protect data developed with higher item development assurance levels (IDAL), security provisions need to address any mixing of data processed at lesser DPALs and any potential vulnerability affecting the more critical data.

(iii) Changes to DQRs and Identification of Non-Compliant Data

The applicant must identify the process for establishing new configuration baselines in the configuration management plan.

Changes to the DQRs must be coordinated between the data supplier and user receiving the data. The applicant should give sufficient advance notice of changes to allow subsequent participants in the data chain (avionics manufacturer, OEM, and potentially the operator / end-user) ample time to review the effect of the change.

If data elements not compliant with the three assurance levels identified in RTCA/DO-200B is delivered with RTCA/DO-200B compliant data, the agreed-upon DQRs should identify this data as assurance Level 4, indicating it may not satisfy safety objectives. Level 4 data must be distinguishable from any compliant data through means acceptable to the authority. The operator / end-user is ultimately responsible for ensuring Level 4 data meets the quality requirements for its intended application.

(iv) Tailored Data

Tailored data is aeronautical data originated by an operator/ end-user under their sole responsibility and for their exclusive use.

The accountability for this data, and its subsequent update, remains solely with the operator / end-user and thus verification, validation, and corruption detection requirements are applicable to the data originator and not the data supplier. Therefore, both Type 1 and Type 2 CTSOA data suppliers must ensure tailored data is not distributed to entities other than the operator/end-user requesting the data.

The Type 1 CTSOA holder must sufficiently identify tailored data to support the Type 2 CTSOA holder in meeting this distribution constraint.

(v) Tool Qualification

Performance of tool qualification utilizes RTCA/DO-330, Software Tool Qualification Considerations, with adaptations provided in RTCA/DO-200B, appendix D.

The applicant should provide all necessary tool qualification data as part of the CTSOA application and subsequent changes to the tool qualification data should follow the agreed to CTSOA change process. In addition, the applicant must submit the documentation (e.g., a Tool Accomplishment Summary (TAS)) demonstrating tool qualification activities were satisfactorily completed.

5. Deviations.

For using alternative or equivalent means of compliance to the criteria in the minimum performance standards of this CTSO, the applicant must show that the data processing procedures equipment maintains an equivalent level of safety. Apply for a deviation pursuant to Paragraph (1) of Section 21.368 in CCAR-21.

6. Marking.

For delivered aeronautical data, a release statement should be provided in accordance with Section 4.a.(vi) of this CTSO. This release statement is considered as marking compliance.

7. Application Data Requirements.

The Applicant must give the responsible certification personnel a statement of conformance, as specified in section 21.353(a)(1) in CCAR- 21 and one copy each of the following technical data to support your design and production approval.Aeronautical Data Description Documentation containing the following:

a. Facility. The name and address of the facility.

b. CTSOA Type: A brief description of the CTSOA Type of CAAC acceptance sought: Type 1 CTSOA or Type 2 CTSOA.

Note: For a Type 2 CTSOA, the application must

identify the compatible systems part/model numbers (hardware, software, and database). Changes to the compatible system may change the DQRs. The applicant should coordinate those changes with the DAH early, to ensure updates to data products meet the new requirements at the same time the product is reviewed.

c. Datasets: A brief description of the type of datasets included in the scope of the application (e.g., navigation, terrain, obstacle, airport mapping, etc.).

d. Data Package: The application data package must include authorized versions of all of the plans and procedures for the processing of aeronautical data and quality management requirements. For a Type 2 CTSOA, substantiation ofthe DQRs must be included, demonstrating the aeronautical data will support the intended function of the installed equipment and are part of the airworthiness approval documentation. The complexity of the data package will vary depending upon the critical nature of the data as it relates to the product in which it will be loaded. The data package must include, but is not limited to, the following:

(i) Compliance Documentation

One copy of the compliance documentation as described in RTCA/DO-200B Section 2.2, including the Compliance Plan (RTCA/DO-200B, Section 2.2.1), as well as all documentation supporting your compliance as described in RTCA/DO-200B, section 2.2.2. The compliance plan includes a completed RTCA/DO-200B compliance matrix (see RTCA/DO-200B, appendix F), as well as a completed objectives matrix found in the appendix of this CTSO.

(ii) Data Process Description

Provide a high-level description or process diagram of the data process, inspection and test procedures (including process controls and incoming supplier controls) for processing data in the Data Processing Procedures as described in RTCA/DO-200B, appendix E, item 3. This includes means to address any changes to the DQRs, data processing procedures, and implementation into the aeronautical data process. Additionally, illustrate the methods of traceability and configuration control for all delivered aeronautical data.

- 17 -

(iii) Compatibility

For a Type 2 CTSOA, the applicants must include a list of systems for which the applicant will ensure compatibility with intended use including part/model numbers (hardware, software, and database) by demonstrating (e.g., using system verification tests, sampling checks, etc.) that the DQRs are consistent with the intended function of the associated equipment. This is always done through an appropriate arrangement with the original equipment manufacturer (OEM) / DAH at time of first listing on the CTSOA or when proposing additions to the compatible equipment list. The authority recommends performing periodic sampling checks on individual datasets(e.g.,through simulation, test platform environments, etc.) to demonstrate ongoing compatibility.

(iv) Data Error Handling and Reporting

Data errors are considered as an escape from the supplier's quality system and a failure to meet DQRs. The applicant must have procedures to address any unsafe condition or error found in distributed data. The procedures should address the actions the applicant intend

- 18 -

to take to develop and distribute corrective action to all affected parties (e.g., source, database users, the authority). The procedures must describe how to communicate with data suppliers for all suspected and confirmed errors with the source data, and how to inform customers and the authority of confirmed data errors having potential to adversely affect the safety of operational use. The procedures must describe how to communicate without undue delay (within 48 hours of detection/knowledge) change in CTSOA status and any confirmed data errors having potential to adversely affect the safety of operational use. Examples of data errors with potential to adversely affect safety include, but are not limited to final approach segment (FAS) data block changes, path and terminator “leg type ” coding, as well as critical and essential data elements.

8. Referenced Documents

DO-200B Standards for processing aeronautical data, June18, 2015.

DO-330 Software Tool Qualification Considerations, Dec. 13,2011.

RTCA/DO-201A Standards for aeronautical information，April 19, 2000.

- 19 -

RTCA/DO-272D User requirements for aerodrome mapping information，October 12, 2001.

RTCA/DO-276C User requirements for terrain and obstacle data，March 5, 2002.

RTCA documents may be ordered from:

1150 18th Street NW, Suite 910, Washington D.C. 20036 Copies may also be ordered online at:www.rtca.org

- 20 -

CAAC CTSO-2C611

Appendix Objectives Matrix

Objective

Number

CTSO

Reference

Applicant’s Reference Document or ID

Objective Met Yes, No, Pending or N/A

Notes

A.1 CTSOA post acceptance responsibilities

You must report to customers, the authority and to source any failure, malfunction, or defect in the distributed data having potential to adversely affect the safety of operational use.

4.a.( i)

The initial reporting of confirmed safety-related errors or defects must be timely and prompt to ensure swift resolution.

You must endeavor, through documented procedure, to ensure receipt of data alerts reporting safety-related errors or defects.

You must consider any safety-related data alerts prior to use of the affected data

You must maintain a QMS as described in RTCA/DO-200B, section 2.5.

You must report all changes made to the QMS affecting the data quality objectives to the autority before their implementation.

- 21 -

You must submit minor design changes for an existing CTSOA in accordance with procedures agreed to with the authority.

You must substantiate major design changes, and the authority must accept them prior to their implementation.

Procedures for reporting of changes to the data process must address changes to tools used in its data process.

You must perform periodic internal audits of both this CTSO and RTCA/DO-200B objectives as described in RTCA/DO-200B, Section 3, with the maximum time between audits not to exceed one year.

Any major non-conformities as described in RTCA/DO-200B, section 3.4, must be reported to the authority.

You must notify all users and the authority, when you no longer comply with the conditions of the CTSOA.

You must provide a release statement with each database distribution to broadcast the identified CTSOA status, state your compliance, and provide information on known deviations and alterations.

4.a.(w)

The release statement must include CTSOA Status.

- 22 -

The release statement must include any deviations to the agreed DQRs.

The release statement must include any data alteration.

You must surrender or withdraw your CTSOA if you no longer uphold the terms and conditions.

You must notify your data customers of the status of your CTSOA.

4.a.(Ⅶ)

You must be aware of and provide any change in status of CTSOA for previous data chain participant(s) up to, but not including, a Contracting State’s AIP.

The method of notification must be timely to ensure customers can react to changes in the status of an CTSOA before they accept the next data update.

A.2 Compliance of the Data suppliers with this CTSO

You must verify and validate data obtained from non- authoritative sources through an approved process prior to delivery.

4.b.( i)

Your data processing procedures must define the means of

- 23 -

confirming data you receive is not corrupted, your means to protect stored data from corruption, and what methods you provide the user to verify the data they receive from you is not corrupted.

To protect from the possibility of intentional corruption, you must maintain records showing what data security provisions you implement to accomplish these objectives.

Your data security provisions must describe both the technical and organizational controls you implement to ensure you receive data from known sources and to prevent intentional corruption during processing and exchange of data.

Provisions for data security must describe how you identify, assess, and mitigate security threats and prevent unauthorized access to data or tools.

You must identify the process for establishing new configuration baselines in the configuration management plan.

Changes to the DQRs must be coordinated between the data supplier and user receiving the data.

- 24 -

DPAL4 data must be distinguishable from any compliant data through means acceptable to the authority.

There are currently no established requirements for tailored data. Therefore, data suppliers must ensure tailored data is not distributed to entities other than the operator/end-user requesting the data.

In addition, regardless of which framework, you must submit the documentation demonstrating tool qualification activities were satisfactorily completed.

(The English version is for reference only. In case of any discrepancy or ambiguity of meaning between this English translation and the Chinese version, the latter shall prevail.)

- 25 -