简介基于ATA iSpec 2200规范的航空器系统章节划分摘录面向机务工程、技术出版物编写、维修大纲制定等专业人员可作为标准速查参考。内容取自英文原版第163至206页系统梳理飞机组、系统与子系统定义表覆盖动力装置70章及71-84节、时限与维护检查5章等典型章节同时展示SYS/CHAP与SUB-SYS/SECTION的层级分配原则帮助读者快速理解各系统编码含义及边界。包体为单个PDF大小579KB便携易存。已有2212人浏览学习。通过这份摘录读者可掌握ATA章节分类的内在逻辑便于在编写维修工卡、归纳技术状态或处理排故数据时采用统一语言标准定义还包含“预留”与“航空公司使用”等章节能避免实际应用时的归类歧义。1. ATA iSpec 2200章节划分是什么它把航空器系统归成一套全行业通用的地址编号做维修或技术出版的人最常被问到的一句话是“这个件算几几章”。发动机燃油泵属于28章还是73章起落架收放作动筒属于32章还是29章这些问题的答案不在感觉里而在ATA iSpec 2200的章节划分规则里。它把一架飞机的系统、子系统、组件归到一套全行业通用的编号体系让维修手册、图解零件目录和排故程序能互相对得上。日常大家挂在嘴边的“ATA 21”“ATA 27”就是这套体系在交流时的缩写。这篇笔记我按自己多年做工程数据和维修手册落地的经验把从系统归类到编号落地、再到查错验证的完整路径讲清楚。看完你能直接拿着自己飞机的系统图试着拆一遍。2. iSpec章节划分的底层规则为什么空调是21章、飞行控制是27章而不是随便编2.1 没有统一编号时跨机型维修为什么会一团糟早期各厂家的技术出版物各编各的目录。同样是发电机某型号的手册放在“电气设备分册第5章”另一型号放在“电源系统第3节”同样是座舱增压有的归在环境控制有的散在空调分册。单独看一本手册没问题可一旦机队里有两三个型号维修人员换机型时要重新学一套目录航材部门按件号反查手册时也经常扑空。航空公司、维修厂、OEM之间要频繁交换维修数据和改装资料没有一个共同的“坐标”就永远在翻译。后来行业统一走的是按功能分类的路把一个系统从整机里抽出来按它“干什么用”而不是“装在哪”来给它一个固定位置。空调就是21章飞行控制就是27章燃油存储就是28章。位置一旦稳定手册、工卡、排故、航材分类都围绕这套编号组织跨机型、跨单位沟通才成为可能。这套编号的根子在ATA规范里经过多年演进现在的形态就是ATA iSpec 2200里的章节划分框架。它不规定某架飞机必须有哪些系统而是规定“如果你有这样一个系统它应该放在哪一类、怎么编号”给工程人员留扩展空间。理解这一点后面做系统归类时思路就顺了。2.2 从章、节、项到iSpec 2200编号里的三层语义整套编码看起来是一串数字其实内部有三层含义我习惯叫它“地址”章号对应系统节号对应子系统项号对应组件或单元。日常说“ATA 21”只说了第一层完整定位一个部件要往下走到节、走到项。我拿一个实际例子说明。飞行控制系统是27章27章下面有主飞行操纵、辅助飞行操纵等子系统主飞行操纵子系统下面再拆成副翼、升降舵、方向舵的操纵单元。到了文件编号里通常写成“27-30-01”这种带连字符的三段形式前两段是章和节最后一段落到具体单元。旧版规范里这些段位基本是数字章节划分相对固定ATA iSpec 2200延续了同样的语义但放宽了表达允许在需要时用字母扩展让编号能容纳更多构型和改型并且把它固化到数据模块编码的INS字段里。所以不要把章节号当成流水号。它不表示“第21个被发明的系统”而表示“空调系统”这个功能域。前一段决定大类后一段决定具体位置任何一个部件只要给出完整编号就能从章往下逐级钻到它。做系统归类时我从第一层系统开始再逐层收敛而不是拿到一个部件号就去猜它的章节。2.3 常用系统章节号对照表21–36、49、51–57、71–80到底装了什么实践里用得最多的是三个区间21到36是机身系统49是机载辅助动力装置51到57是机体结构71到80是动力装置和发动机本体。我整理了一张常用对照表你可以贴在工位上备用章节范围覆盖内容典型系统举例05–12维修支援类时限/检查、尺寸区域、起重顶升、称重平衡、牵引滑行、停车系留、标牌标记、勤务20机身标准施工紧固件、钣金、结构修理通用工艺21空调制冷、加热、增压、空气分配22自动驾驶飞行指引、自动油门23通讯话音、数据链、内话24电源发电机、汇流条、配电、应急电源25机内设备与装饰座椅、厨房、厕所、隔板26防火探测、灭火瓶、警告27飞行控制副翼、升降舵、方向舵、扰流板、配平28燃油油箱、泵、输油、加油/放油、量测29液压液压泵、油箱、蓄压器、管路、液压阀30防冰防雨风挡加温、皮托管加温、雨刷31仪表显示、记录、中央告警32起落架收放、减震支柱、机轮、刹车、位置告警33灯光外部照明、内部照明、标志灯34导航无线电导航、惯性导航、飞行管理35氧气机组与旅客供氧36气动引气分配、压力调节38水与污水饮用水、卫生间排污49机载辅助动力装置APU本体及其控制51–57机体结构52舱门、53机身、54短舱/吊架、55安定面、56窗/风挡、57机翼71–80动力装置72发动机本体、73发动机燃油与控制、74点火、78排气、79滑油、80起动这张表能解决八成的“这个东西算几几章”。剩下两成是边界模糊件比如同时牵扯燃油和发动机、同时牵扯液压和起落架这些我在第5章专门讲。拿到这张表你先做一件事找一份你手头机型的系统简图把每个系统名对照到表里的章节号就当熟悉规则。做完你会发现绝大多数系统都能对上只有少数跨功能系统需要仔细判断。3. 航空器系统归类怎么做从系统树到ATA章节号的四步映射3.1 先做系统树把飞机拆到叶子节点归类前先别急着翻章节表第一步是画系统树。飞机是一个大系统下面挂几十个子系统每个子系统再往下拆。你要拆到哪一层取决于你手里的资料目的如果做维修体系拆到可更换单元如果做技术出版物目录拆到能定位一份工作程序即可。我一般用文本列表来画不画复杂图形因为后面要对照编号逐行检查。结构是这样某型号飞机电源系统主交流电源子系统发电机控制单元发电机控制继电器这就是一棵四级树飞机、系统、子系统、单元。画的时候每个节点只写一个功能名不写品牌和件号件号留到映射完成后填。这样做的目的是逼自己先想清楚“这个层级到底承担什么功能”而不是被零件清单牵着走。很多项目在接触新机型时最容易在这里翻车——还没理清楚系统树就从件号去猜章节结果同一件号在不同图纸里被归到不同章。系统树的粒度有一个实用判据如果某个节点之下的内容都能写进同一份工作程序或同一张图解零件图这个节点就够用了如果还要往下再区分几种完全不同的工序就继续拆。粒度一致很重要有的子系统拆到三级有的停在二级后面维护时目录会很乱。3.2 再做映射系统、子系统、组件逐级找章节系统树画完开始逐级映射。第一层系统对应到章第二层子系统对应到节第三层单元对应到项。每一层都用同一个问题来判断“这个部分的核心功能是什么它服务于谁”我提炼了三个判断问题这几年用下来很管用第一这个部件或系统服务于谁起落架收放作动筒服务于起落架的收放功能所以归32章起落架不归29章液压。液压只是它的动力来源不是它的服务对象。第二谁给它发指令、谁控制它的核心逻辑发电机控制单元受电源系统控制逻辑管理它服务的对象是电网所以归24章电源不因为装在发动机附近就归到72章。第三如果这个部件同时出现在多个系统图中它的“第一图纸”属于哪个系统常见的是继电器、接触器这类通用器件它在电源图里有、在告警图里也有。判断标准是它在哪个图里承担主要功能而不是它在哪个图里先出现。对应到具体映射过程就是把系统树的每一行和章节表对齐。我举个例子某型号飞机的飞行操纵系统第一层对应27章子系统“主飞行操纵”对应27-30单元“升降舵操纵机构”对应27-30-01。每一层都只改最后一段前面的章、节保持不变这样编号在逻辑上是连贯的。映射完成后你得到一张两列对照表左边是系统树节点右边是完整章节号。这张表就是后续做数据模块编码、做工程系统字段的底表。3.3 最后核对拿厂家的AMM/IPC回来比一遍映射做完别急着交拿厂家的现行手册回来反向核对。我通常的做法是取一个具体件号输入到厂家图解零件目录里检索看它被编到哪个章节。然后把检索结果和我自己的映射结果放到同一张表里对比。这个环节经常发现两类差异。一类是我拆的系统树比厂家更细厂家在一个章节里包含了两个子系统内容而我把它们拆开编了号另一类是厂家为了延续旧手册的习惯把某些组件保留在传统章节里没有按我理解的功能归类。遇到差异时我的原则是以厂家现行出版物的正式章节为基准不强行改。原因是后续维护人员查手册是按厂家的章节目录走的你自建一套编号再合理和手册对不上就无法落地。如果确实认为厂家归类不合理比如厂家自己在新老版本间逻辑不一致那就记录一条偏差说明写清楚建议归类和厂家归类的差异提交给工程部门评审而不是悄悄改掉。第3章做完你已经拥有了一套能和厂家手册对齐的“系统-章节”对照关系。接下来要解决的是这套编号怎么进入技术出版物数据模块的问题。4. 章节号进入数据模块编码INS的拼装规则与章节目录写法4.1 数据模块编码里的INS章节划分如何被编码进DMCATA iSpec 2200落地时技术出版物不再以“整本书”为单位管理而是拆成一个个数据模块每个模块有独立的编码。这个编码也就是DMC你可以把它理解成每个数据模块的身份证号。DMC里最关键的一段就是INS它写的正是上一章里你做的章节划分结果。DMC不只包含INS。我按常见形态拆给你看它通常由型号标识、数据模块类型、INS、学习类型与等级、页码几段组成。型号标识区分飞机型号和构型数据模块类型区分这是描述类、维修类还是图解零件类INS告诉你模块属于哪个系统、哪个子系统、哪个单元页码用于区分同一INS下的不同模块顺序。写到这里必须提醒一点INS在不同厂家的落地细节不完全一样。多数型号的目录采用“系统三位、子系统两位、单元一位”的形态总长六位但我也见过系统用两位加字母的写法。做编码前先翻你手头型号的出版目录说明以它为准。不要拿别的型号的规则硬套这是这个领域最容易出现的想当然。4.2 章节目录的拆分粒度写到哪一层才算够用INS确定了紧接的问题是章节目录到底拆多细。粒度太粗一本手册一个章几百页现场翻找困难粒度太细每个零件都编一个号目录膨胀到没法维护。我一般按资料类型定粒度。维修程序类写到单元级也就是INS的最后一段培训类资料写到子系统级就够了图解零件目录则必须到件号所在的那个最低层级。颗粒度的一致性比颗粒度本身更重要。如果同一个资料集合里有的章节拆到第三层、有的停在第一层读取的人会以为第二层以下是不同系统实际只是写法的差异。一个实用做法是建“章节目录模板”。把每章的固定标题先铺好比如27章下先列主飞行操纵、辅助飞行操纵再在每个子系统下预留单元位。每次有新机型接入复制模板再按实际系统补全而不是从零开始新编一份。这样能保证所有机型在同一目录框架下保持结构一致交叉引用时也不至于一家一个样。4.3 工程系统里存章节号的字段规范与检索习惯章节号最终要落到MIS、维修管理系统、航材系统里。这个环节的坑很隐蔽我单独说一下字段规范。很多系统把“ATA章节号”设成一个自由文本字段结果录入时有人写“27-30-01”、有人写“273001”、有人写“27.30.01”同一批数据三种格式。搜索时用“27-30”前缀匹配就漏掉后两种数据直接变成死数据。我建议按以下规范建字段字段建议类型与长度说明章节号/章字符型长度3保持三位显示如027、027不足位补零节号字符型长度2不够两位前补零项号字符型长度1–2按目录定义允许字母INS完整值字符型长度6以上连字符规则全系统统一推荐“27-30-01”检索字段建议单独冗余一列去掉连字符存“273001”用于模糊匹配字段建好后检索习惯也值得统一。工程人员查章节时先输入章号系统列出该章下所有子系统再选择节系统列出对应单元。这种逐级收敛的检索方式比直接输入完整编号更不容易出错因为它逼着使用者按章节层次走而不是凭记忆打一串数字。5. 章节归类避坑五类翻车现场与修复办法5.1 功能边界上的三个翻车现场燃油泵、作动筒、APU做章节归类做久了会发现真正让人头疼的不是整系统归类而是边界件。我挑三个几乎每个项目都会遇到的现场每条按现象、原因、解决写清楚。第一个是发动机燃油泵。现象航材分类时把发动机驱动的燃油泵归到28章燃油结果在73章的图解零件目录里找不到它排故手册引用也断链。原因28章管的是燃油存储、增压、输油、量测把燃油从油箱送到发动机入口73章管的是发动机燃油与控制负责计量、调节、把燃油送进燃烧室。这台泵装在发动机上、由发动机控制逻辑操作主归属应该是73章。解决先查以发动机为中心的技术出版物泵的控制对象在发动机控制系统里就按73章记录同时在28章的交叉引用表里保留一条出处。交叉引用不是偷懒是把访查路径留给后人。第二个是液压作动筒。现象起落架收放作动筒被划进29章液压系统理由是它明明是个液压部件。原因归类规则是按“服务对象”而不是“动力来源”。作动筒的服务对象是起落架收放功能它只是恰好由液压驱动。解决装在起落架结构上的负载末端归32章29章只记录液压源、液压管路、液压控制阀这些动力产生与分配部分。判断口诀我总结过液压泵、油箱、蓄压器归29用液压干活的末端负载归负载系统。第三个是APU。现象APU同时供电和供气有人按功能拆开发电机挂到24章电源引气挂到36章气动APU本体反而没地方放。原因把输出当成主功能忽略了APU是独立的辅助动力装置。解决APU本体及其控制、燃油、排气、起动全部归49章它送出去的电和引气只是接口在24章和36章里做交叉引用即可。主归属只能有一个交叉引用可以有多个。这三个边界案例有个共同规律先问功能归属再问动力来源先定主归属再补交叉引用。只要这个顺序不乱边界件大多能找到稳定答案。5.2 迁移与数据治理里的两条血泪经验第四个坑出现在旧系统数据迁移。现象旧工程系统里存的是“21-58”这种两位节号的文本新系统按章节划分要求补到单元级迁移后有的变成“2158”、有的变成“21-5-8”分隔信息丢了前缀查询一查一个空。原因把文本字段原样搬迁既没做章、节、项拆分也没在新系统里统一补零和连字符规则。解决迁移前先拿一批样本记录做拆分演练定好补零策略和统一分隔符对迁移后有歧义的记录不要猜回到功能树重新判定。这一步我在每个项目里都要求先做因为它几乎肯定能捞出一批历史脏数据。第五个坑是同一零件跨系统出现。现象一个继电器同时出现在24章电源图和31章仪表图里两个人各按各的图归了不同章节台账里出现了两条记录。原因系统图交叉重叠又缺少主归属规则。解决在数据管理规范里定一条硬规则——主章节按部件的第一控制/驱动关系确定其它系统图里的出现一律作为交叉引用记录。规则定完请系统工程师审核签字形成书面依据。没有签字确认的归类规则三个月后大概率又被推翻重来。这五条经验不是理论推演都是实际项目里踩过的坑。现在再回头看第2章那句“编号是地址不是流水号”应该更有体感了。地址写错了在系统里怎么搜都搜不到那个件。6. 归类结果怎么验证一份自查清单加一次反向审查6.1 一份自查清单五个维度五分钟内过一遍章节归类做完后别急着宣完成。我每次交付前都会用一份清单自查五个维度很快能发现问题检查维度要查什么合格标准正向完整性从系统树逐层找章节系统树的每个叶子节点都有且仅有一个主章节反向完整性从章节目录倒查系统树每个章节下列出的组件都能在系统树里找到父节点一致性与厂家现行AMM/IPC对照同一零件的章节号与厂家一致差异有书面说明格式规范INS长度、字符范围、连字符全部记录符合系统字段规范无截断、无缺零变更记录构型或MOD后受影响组件改版记录里能查到旧号和新号的对应关系正向查的是“有没有漏”反向查的是“有没有多”一致性查的是“能不能落地”格式查的是“机器认不认”。这五个维度不花多少时间但能把归类结果里大部分问题暴露出来。6.2 反向审查把章节目录当成体检表来用如果你还想再狠一点做一次反向审查。做法很简单把章节目录从头翻一遍从21章一路看到80章每看到一个章节标题先别急着跳过问自己一句——这个章节下现在挂的内容真的是这个系统的东西吗反向审查最有价值的时刻是发现某个章节下挂着一个“看起来不太对”的组件。比如36章气动系统里挂了一件排气活门仔细查发现它其实是发动机排气系统的部件应该归78章。这种杂件混挂的问题正向检查完全发现不了只有逆向看目录时才会露出来。我自己的习惯是在项目交付前专门留半天做反向抽查不按顺序全查而是在每个章节号里随机抽几个节点去核对系统树。抽查的重点是那些跨系统边界件、最近改版过的组件、以及导入历史数据时带进来的老记录。每发现一条问题就在对照表里标红然后按系统工程师意见修正主归属或补交叉引用。这套方法做完你手里的章节对照表才有资格进入工程系统成为后续手册编写、排故检索和航材分类的依据。别嫌验证这一步繁琐多年经验告诉我现场维修人员拿着一个章节号查不到件时不会觉得是归类的问题只会觉得系统不好用。归类工作做到位是能把这种“系统不好用”的投诉消灭在源头上的。希望这篇从规则到落地再到验证的完整路径能帮你在自己手头的机型上少走几步弯路。本文还有配套的精品资源点击获取