简介：一份面向航空维修工程师、机务人员及标准编写者的航空运输协会iSpec 2200规范节选，聚焦航空器系统的章节划分与归类规则。资源为英文版PDF文档，仅包含一个文件，总大小约五百七十九KB，内容取自规范第一百六十三至二百零六页，详细列出飞机各系统（如动力装置系统、发动机系统等）的分组定义、章与节编号体系及子系统划分说明，并覆盖一般时间限制与维修检查等具体条目，有助于快速掌握标准中系统编码的对应关系。已有两千二百零九人学习，适合在机型维护手册编写、工卡制定或系统分类检索场景中作为对照参考。对于需要理解现行章节体系与系统子系统定义逻辑的读者，这份节选能提供原始英文表述，帮助理清行业标准编码规则，节省查阅整本规范的时间。

1. ATA iSpec 2200 章节划分：航空器系统归类与维修任务映射的起点

做维修工程管理系统或者给工卡做编号时，真正卡人的往往不是业务流程，而是“这项维护工作到底该落在哪个章节号下面”。ATA iSpec 2200 的章节划分就是用来回答这个问题的标准框架，它按功能而不是按物理位置把整架飞机拆成可归档、可检索的章节号。这份资料覆盖英文版第 163 到 206 页，正好包含第 5 章时间限制、第 6 章尺寸区域、第 7 章顶升支撑、第 8 章校水平与称重、第 9 章牵引滑行、第 10 章停放存储、第 11 章标牌标记、第 12 章勤务、第 18 章直升机振动噪音，以及第 21 章空调和第 70、71-84 章发动机系统，还有第 91 图表、115/116 模拟机系统。适合机务工程、MRO 软件实施和维修手册数字化的人，新手能照章节号建数据表，熟手能拿来做系统边界校验。

2. 章节归类逻辑拆解：第 5 章到第 71 章的系统边界、排除项与编号规则

2.1 第 5 章为什么是“时间限制/维护检查”而不是维护大纲

第 5 章的章节号是 5，标题是 Time Limits/Maintenance Checks，文档里明确定义为“制造商推荐的检查、维护和翻修时间限制”。很多人第一次看到这个章节名，会误以为它就是维修大纲的正文，实际不是。文档在 -10 到 -40 后面专门加了一条 NOTE，说除非政府法规要求，否则这些时限数据不允许直接放进手册出版物里。航空公司的确需要制造商推荐的时间限制，但这些内容应该另出一份独立文档。

这个设计决定了数据建模时的处理方式：第 5 章的职责是“给时限数据一个去处”，不是“承载具体工卡步骤”。它的子章节划分很典型：-00 General 是总论，-10 Time Limits 放制造商推荐的检查、维护、翻修时限和部件寿命，发动机厂商还要在这里面写明主要旋转部件的飞行循环寿命；-20 Scheduled Maintenance Checks 放由 -10 时限派生出来的计划维护检查清单，并且要与航空公司工卡上的名称交叉引用；-30 和 -40 是保留位，文档原话是“当 -20 的第四位编号不够细分时使用”；-50 Unscheduled Maintenance Checks 放特殊条件下的非计划检查，比如重着陆、超重着陆、鸟击、湍流、雷击、含雪水 ingestion、放射性污染、发动机停车后拖飞前的检查等。

从数据表设计的角度看，第 5 章最容易被做错的一点是：把 -10 到 -40 之间的内容当成工卡步骤去引用。实际业务中，我一般会把 -10 的时限数据单独拆成一张“时限主数据表”，-20 的计划检查只保留与工卡的交叉引用编号，-50 的非计划检查单独打一个“触发条件”标签。做计划维修系统的时候，第 5 章是索引源头，不是内容仓库。

2.2 靠排除项定义边界：第 21 章空调的 -10 到 -70 拆分逻辑

第 21 章 Air Conditioning 的定义是：为压力密封舱内提供增压、加热、冷却、湿度控制、过滤和处理空气的那些单元和部件。这个定义本身不难理解，难的是它靠“不包括什么”来划清边界。文档在 -10 Compression 明确写“不包括座舱增压的压力控制和指示系统”，-40 Heating 写“不包括温度控制和指示系统”，-50 Cooling 也写“不包括温度控制和指示系统”，而 -60 Temperature Control 单独掌管温度控制，-70 Moisture/Air Contaminant Control 管湿度、臭氧浓度、放射性碎片过滤和空气处理。

这个“排除项”设计是整个 ATA 章节体系里最容易被误读的地方。表面上看它只是划清了职责范围，实际上它决定了自动归类逻辑怎么写：某个物理部件如果装在供气管路上但承担温度控制功能，就不该挂到 -40 Heating 下，而要挂到 -60 下。做维修任务归类时，如果只根据部件的安装位置去匹配章节号，很可能把温度传感器挂到 -20 Distribution（分配）里。这就是为什么我在做归类脚本时，会把“does not include”后面的内容单独提取成一个排除项字段，而不是直接塞在定义文本里。

再往下看，-20 Distribution 负责引气和分配空气，包括设备架冷却、鼓风机、风斗、管道、进气口、单向活门、线路等；-30 Pressurization Control 管机身压力控制，包括控制活门、释压活门、指示器、开关、放大器、线路。注意 -10 的排除项里说的“压力控制与指示系统”指的就是 -30。所以，-10 Compression 管压缩空气供应，-30 管座舱压力控制，二者分属不同功能域。

2.3 第 70/71-84 发动机、91 图表与 115/116 模拟机：非常规章节的归类

发动机系统的归类逻辑在文档里很特殊。第 70 章 Power Plant 本身是一个分组章节，71 到 84 章才是具体系统，定义原文是“通过排气或螺旋桨产生推力的完整动力单元，不包括发电机、座舱增压器等，那些属于各自对应的系统”。这句话的工程含义是：发电机即使物理上安装在发动机附件齿轮箱上，它的章节归属仍然是第 24 章电气系统，而不是跟着发动机走。做工卡归类时，最常翻车的点就在这里。

91 章 Charts 是一个容易忽略的存在，它把图表类内容单独成章，说明在实际手册体系里，图表不一定挂在系统章节下，可能统一收在 91 章。115 章 Flight Simulator Systems 和 116 章 Flight Simulator Cuing Systems 则说明这套编号体系不只是覆盖真机，还覆盖训练仿真设备，对做模拟机维护工卡的人是个明确指引。

表格形式整理这些章节的归类要点会更直观：

这个表对做 MRO 数据库初始化的人基本够用，但注意 13 到 17 章、19 章在文档里是 Unassigned 状态，属于未分配章节，不能拿来挂日常维修任务。

3. 把第 163-206 页转成结构化数据：解析脚本、数据模型与三步校验

3.1 先建数据模型：章节号、标题、定义、排除项分开存

拿到这份英文 PDF 之后，第一步不是急着写正则，而是先想清楚最终要存成什么样的数据表。我的习惯是建一张章节定义主表和一张子章节明细表，二者的关系是 1 对 N。主表字段包括 chapter_no（两位或三位数字）、chapter_title（章节标题）、definition（系统定义原文）、note_flag（是否有 NOTE 标记）；子表字段包括 chapter_no、sub_sys（-00/-10/-20 这类）、sub_title、sub_definition、exclusion_items（排除项）。这里最关键的字段就是 exclusion_items，它存的是“不包括”后面的内容，单独拎出来是为了后面做归类逻辑的二段校验。

为什么要单独存排除项？因为实际归类时，一个维修任务如果命中了排除项的表述，说明该任务很可能挂错了系统。比如你在第 21 章 -10 的定义里读到“不包括座舱增压压力控制和指示系统”，那么一条关于座舱压差指示器的工卡，哪怕它的部件安装在空调舱，也不应该挂到 21-10。数据模型把这个字段独立出来，分类逻辑里就可以写 if exclusion keyword matched then re-route。

3.2 PDF 文本提取：用 pdfplumber 按行首正则抓章节

文档是英文版 PDF，且是 2001 年前的排版风格，多数字段是表格线加文本流的混合布局。直接用 pypdf 提取会出现大量断行和页眉噪声，我建议用 pdfplumber 逐页提取文本，再结合正则做章节匹配。下面这个脚本是我处理这类手册的常见做法：

import re import pdfplumber pdf_path = "ata_ispec_2200_p163_206.pdf" # 匹配行首为2~3位数字、后跟多个空格和大写标题的章节头 chapter_pattern = re.compile(r"^(\d{2,3})[ \t]{2,}([A-Z][A-Z &'/\-]+)$") pages_text = [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: text = page.extract_text() if text: pages_text.append(text) full_text = "\n".join(pages_text) lines = full_text.split("\n") records = [] current_chapter = None for line in lines: stripped = line.strip() m = chapter_pattern.match(stripped) if m: current_chapter = { "chapter_no": m.group(1), "chapter_title": m.group(2), "raw_lines": [] } records.append(current_chapter) elif current_chapter is not None: current_chapter["raw_lines"].append(stripped) # 看一下第5章抓到的原始行，确认正则没有漏掉章节 for record in records[:2]: print(record["chapter_no"], record["chapter_title"])

这段脚本的逻辑是：先按页提取全文，再按换行拆成行列表，用正则匹配行首数字加大写标题。正则里的{2,}要求数字和标题之间至少有 2 个空格，这是为了避开页码和表格里的单元格编号。注意章节标题里可能有斜杠和连字符，所以字符集写成[A-Z &'/\-]+。如果原始文档某章标题跨了两行，比如“PARKING, MOORING, STORAGE & RETURN TO SERVICE”，正则会只匹配到第一行的一部分，这种情况下需要再写一个续行合并函数，把下一行非数字开头的纯大写文本拼接上去。

3.3 子章节拆分与定义合并：-00/-10/-20 的归属处理

主章节抓到之后，子章节的拆分是第二个容易出错的地方。子章节的特征是行首以负号和两位数字开头，比如 -00 General、-10 Time Limits。定义文本从子章节标题之后的下一行开始，一直持续到下一个子章节或下一个主章节出现为止。页眉里反复出现的“ATA iSpec 2200 - This material was created to be used in the electronic environment.”这类免责声明要先行过滤，否则它们会被拼进定义文本里。

下面这一段是子章节拆分逻辑：

sub_section_pattern = re.compile(r"^\s*-\d{2}\s+(.+)$") noise_keywords = ["Copyright 2001", "ATA iSpec 2200", "Air Transport Association"] def split_sub_sections(records, noise_keywords): result = [] for chapter in records: subs = [] current_sub = None for line in chapter["raw_lines"]: if any(kw in line for kw in noise_keywords): continue m = sub_section_pattern.match(line) if m: if current_sub: subs.append(current_sub) current_sub = { "sub_sys": line.strip()[:3], "sub_title": m.group(1), "definition_lines": [] } elif current_sub is not None: current_sub["definition_lines"].append(line) if current_sub: subs.append(current_sub) chapter["sub_sections"] = subs result.append(chapter) return result

这段代码的要点在于：先过滤噪声行，再匹配子章节头，逻辑上不算复杂，但顺序很重要。先过滤再匹配，是因为页眉噪声里有“AIR TRANSPORT ASSOCIATION”这种大写文本，如果不先过滤掉，会被子章节正则或定义合并逻辑误收。过滤完成后，子章节的定义文本会累积到下一个章节头或下一个子章节头出现为止。之所以不建议用 pdfplumber 的表格提取功能，是因为这份文档的表格布局在字符间距不统一时，很容易把“定义”列拆成多个碎片列，反而增加人工清洗工作量。

整理完原始文本后，需要输出成结构化文件做校验。输出 JSON 的好处是结构清晰，SQL 兼容也好。校验时重点看三件事：第一，章节号是否连续；第二，每个章节是否至少有 -00 General；第三，排除项是否被单独切出来。一个简单的校验脚本可以检查章节数量是否符合预期，比如第 163-206 页应该覆盖第 5、6、7、8、9、10、11、12、18、20、21、70、91、115、116 这些章节，且 13-17、19 章不能出现在解析结果里。

4. 章节映射避坑：五类误判的背后原因与处理手段

4.1 误把第 5 章当工卡库，导致时限数据混进维修程序

现象：做 MRO 系统初始化时，把第 5 章 -10 到 -20 的时限直接导成工卡步骤，维修人员执行时看到的是一堆时限数值，却找不到具体操作程序。

原因：文档里明确写了 -10 到 -40 的数据除非政府法规要求，否则不应放进手册正文，航空公司希望制造商推荐的时限单独成册。很多人只看了章节标题没看 NOTE。

解决：在数据模型里把第 5 章标记为“索引型章节”，只存时限主数据和与工卡的交叉引用。计划维修任务从航空公司自己的审定维修大纲同步，第 5 章只作为来源引用。

4.2 删掉第 1-4 章保留位，后续航空公司自定义无处挂载

现象：数据清洗时看到 1-4 章标题写着 Reserved for Airline Use，顺手标记为“无效数据”过滤掉。结果客户提需求要加自定义站点流程时，发现没有可用的扩展章节位。

原因：Reserved 不是空，是“留给航空公司自己填”，它是标准的扩展机制，不是无内容。

解决：保留 1-4 章作为占位章节，字段设计里加一个“自定义标识”布尔值。航空公司自定义流程可以挂到这些章节下，不影响标准章节的编号约束。

4.3 把 -30/-40 当作空内容，忽略“持续细分”的语义

现象：第 5 章 -30/-40 在文档里写着 Reserved for use，实施人员理解成“没有内容”，在子章节表里直接不建这两条记录。后来 -20 的四位编号不够细分时，没有位置可挂。

原因：这里的 Reserved 说明是“当 -20 的四位编号不够用时的扩展位”，属于可复用占位。

解决：建子章节表时把 -30/-40 的面包屑建好，用 empty_flag 标记，后续分配编号时在约束条件里检查是否有剩余容量。

4.4 第 18 章“仅直升机”被忽略，固定翼任务挂错系统

现象：一条固定翼机身的振动监测任务被挂到第 18 章 Vibration and Noise Analysis，因为章节标题里没有直接显示 Helicopter Only，只在定义文本里写明仅适用于直升机。

原因：章节标题里确实写了 HELICOPTER ONLY，但很多二次开发的数据表只截取了标题前几个词，或者卡片被单独引用时丢了限定条件。

解决：在解析脚本里把适用范围（固定翼/直升机/两者）提出来作为独立字段。第 18 章强制设置 aircraft_type 为 helicopter，固定翼任务归类时先校验该字段。

4.5 把“不包括发电机”当成不能分类，排除项被反向误读

现象：做自动归类时，读到第 70 章定义里的“Excludes items such as generators”，认为发电机无法归类，于是给发动机驱动的发电机单独建了一套自定义章节。

原因：排除项的意思是“该设备归其他系统章节”，不是“无法分类”。发电机应该归电气系统，这是章节体系的边界划分逻辑，不是黑洞。

解决：把排除项单独存成 exclusion_items 列表，归类逻辑里先做正向匹配（includes），再用排除项做二次校验。命中排除项的工卡重定向到对应系统章节，而不是新建编号。

这一章的最后说点个人感受：章节归类这件事，表面上是查编号，实际上是在理解“系统边界”这个概念。很多数据问题，根子在于把“Reserved”当成“没有”，把“Excludes”当成“排除在外”。把这两类语义处理对了，后面做自动归类就顺很多。如果哪天分类脚本给出的结果让你觉得“玄学”，先回去查排除项字段是不是被吞了。

5. 入库前的反查验证：用称重、空调渗漏、发动机更换三条任务验一遍

5.1 反查用例设计与预期章节号

章节映射表建完之后，别急着全量导入生产库，先用三条典型任务做反向验证。我通常固定用三个用例：称重、空调管路渗漏、发动机附件更换。这三条任务的预期章节号分别是：称重应落在第 8 章 Leveling & Weighing 的 -10 Weighing and Balancing，也就是 8-10-xx；空调管路渗漏应落在第 21 章 Air Conditioning 的 -20 Distribution 或 -60 Temperature Control，具体要看渗漏点是在分配管路还是在温度控制传感器附近；发动机附件更换要分情况，如果换的是发电机，落在电气系统章节，如果换的是起动级或燃油泵，落在 71-84 章动力装置细分章节。

为什么选这三条？因为称重考验的是“专用设备章节”归类，空调渗漏考验的是“功能边界”理解，发动机附件更换考验的是“物理位置不等于系统归属”的边界意识。三条任务分别覆盖了三种最容易被误判的场景。如果这三条的反查结果都对了，说明解析出来的章节定义数据和映射逻辑大体可用。

5.2 用关键词 SQL 做二次校验

反查验证的具体操作可以用 SQL 实现。思路是拿任务描述里的关键词，去章节标题和定义里做模糊匹配，看命中的章节是否符合预期。比如要做“称重”验证，执行下面这条查询：

SELECT chapter_no, sub_sys, title, definition FROM ata_chapter_defs WHERE title ILIKE '%level%' OR title ILIKE '%weigh%' OR definition ILIKE '%weigh%' ORDER BY chapter_no;

这条 SQL 的逻辑是：标题命中 level 或 weigh，或者定义里命中 weigh。正常结果里应该出现第 8 章 -10、-20 的记录，并且不会有第 21 章空调混进来。如果第 21 章也命中了 weigh，不要急着判错，先看看是不是定义里写了“weight and balance”相关的词，比如第 21 章某些活门定义里可能提到重量，这时需要手动判断是相关还是干扰。参数调整上，ILIKE 的模糊匹配在数据量大时性能一般，建议给 title 建一个 B-tree 索引，或者改成只匹配 title 字段，定义字段留到人工复核。

“空调渗漏”的验证也类似，关键词用 leak、duct、distribution，预期命中 21-20 或 21-60。这里最容易踩的坑是：一条“空调管路渗漏”的工卡如果同时提到了“温度传感器”，关键词 lemp 会把 21-60 也带出来，结果是合理的，不要误以为重复。真正要排查的是命中了 21-10 Compression 却命不中 21-20，那说明排除项逻辑写反了。

从那以后我每次做章节映射表的入库，都强制先跑一遍这三条反查用例，全过才允许导入生产环境。这不是流程仪式感，而是因为最容易出错的往往不是解析脚本本身，而是做映射的人对系统边界的理解。反查验证就像一份后悔药，在数据污染之前提前拦住问题。希望帮到你。

本文还有配套的精品资源，点击获取