简介一份面向航空维修工程师、机务人员及标准编写者的航空运输协会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 则说明这套编号体系不只是覆盖真机还覆盖训练仿真设备对做模拟机维护工卡的人是个明确指引。表格形式整理这些章节的归类要点会更直观章节号标题归类要点5时间限制/维护检查时限数据与计划检查分离-30/-40 为保留细分位6尺寸和区域站位、访问门/区域划分、物理位置7顶升和支撑千斤顶点位、尾撑、配重、顶升程序8校水平和称重称重数据记录、水平测量专用部件9牵引和滑行牵引点位置图、转弯半径、转弯限制10停放、系留、存储与恢复服务正常/非正常状态下的长期停放程序11标牌和标记外部颜色方案归 -10外部标牌 -20内部标牌 -3012勤务补充液体、轮胎充气、定期清洁等18振动和噪音分析仅直升机主旋翼轨迹、尾桨平衡、机身振动监测20标准实践-机身机身通用标准做法-90 保留给航空公司21空调按功能拆 -10 到 -70温度控制独立成段70/71-84动力装置70 是分组71-84 是细分发电机不归本组91图表图表类内容统一收纳115/116模拟机系统训练仿真设备纳入章节体系这个表对做 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那说明排除项逻辑写反了。从那以后我每次做章节映射表的入库都强制先跑一遍这三条反查用例全过才允许导入生产环境。这不是流程仪式感而是因为最容易出错的往往不是解析脚本本身而是做映射的人对系统边界的理解。反查验证就像一份后悔药在数据污染之前提前拦住问题。希望帮到你。本文还有配套的精品资源点击获取