4、计划阶段（PSAC）：软件适航计划（PSAC）的编写要点、内容结构及评审流程
好，咱们进入第四个章节。说实话，PSAC 这份文档，是我个人觉得在整个DO-178C生命周期里，最容易被低估的一份文件。
很多人觉得，不就是个计划嘛，随便写写，后面反正要改。嗯，我年轻时也这么想。直到有一次，我在一个飞控项目中，因为PSAC里对“软件等级”的描述含糊不清，导致局方审查时直接叫停了整个开发活动。那滋味，真不好受。
所以，今天咱们就好好聊聊，这份“软件适航计划”到底该怎么写，才能既过审，又实用。
4.1 什么是PSAC？为什么它如此重要？
PSAC，全称是 Plan for Software Aspects of Certification。说白了，它就是一份你向适航当局（比如局方或者DER）提交的“承诺书”。
你在这份文件里，要清楚地告诉对方：
- 我这个项目是干啥的？
- 软件有多关键？（软件等级）
- 我打算用什么流程来开发？
- 我打算怎么证明我是对的？
核心观点： PSAC 不是写给自己看的，是写给审查方看的。它是你与审查方之间达成的第一个“契约”。一旦批准，后续的所有活动都得按这个来。想改？可以，走变更流程。
我记得有一次，一个团队在开发过程中发现原来的测试策略太保守，想换一种更高效的。结果翻出PSAC一看，里面白纸黑字写死了测试方法。最后只能走正式的“计划变更”流程，折腾了好几周。你想想看，如果当初在PSAC里写得灵活一点，是不是就省事了？
4.2 PSAC 的编写要点
写PSAC，我个人习惯遵循三个原则：清晰、完整、可追溯。
4.2.1 清晰定义软件等级
这是PSAC的灵魂。软件等级（A、B、C、D、E）直接决定了你要做多少工作。等级越高，审查越严，证据要求越多。
- A级： 灾难性。比如飞控计算机的主控软件。一旦失效，飞机就没了。
- B级： 危险。比如可能导致飞机失控，但还有备份。
- C级： 主要。比如影响飞行员操作，但不会直接导致坠机。
- D级： 次要。比如乘客娱乐系统。
- E级： 无影响。比如一些非安全相关的日志记录软件。
避坑指南： 我曾经见过一个项目，把本该是B级的软件写成了C级，理由是“我们有硬件备份”。结果审查方一句话怼回来：“硬件备份能保证100%切换成功吗？如果不能，软件失效依然可能导致危险。” 最后只能重新定级，整个开发计划推倒重来。所以，定级一定要基于系统安全评估的结果，别自己拍脑袋。
4.2.2 明确生命周期过程
你需要列出你打算采用哪些过程。DO-178C 规定了三大类过程：
- 开发过程： 需求、设计、编码、集成。
- 综合过程： 验证、确认、配置管理、质量保证、审定联络。
- 完整过程： 其实就是上面这些过程的组合。
在PSAC里，你不需要把每个过程的细节都写出来，但必须说明：
- 你打算用哪些工具？（比如：用什么编译器？用什么测试工具？）
- 这些工具是否经过鉴定？（Tool Qualification Level）
- 你的开发方法是什么？（比如：基于模型设计？手写代码？）
4.2.3 定义软件生命周期数据
说白了，就是你要产出哪些文档和记录。比如：
- 软件需求规格（SRS）
- 软件设计描述（SDD）
- 源代码
- 测试用例和测试结果
- 问题报告（PR）
这些数据，是审查方判断你是否合规的唯一依据。所以，在PSAC里就要想清楚，哪些数据是必须的，哪些是可选的。
4.3 PSAC 的内容结构
嗯，这里我直接给一个我常用的模板结构。你可以根据项目实际情况调整，但核心要素不能少。
| 章节 | 内容 | 说明 |
|---|---|---|
| 1. 引言 | 项目背景、目的、范围 | 简单介绍这个软件是干啥的，用在哪个飞机上。 |
| 2. 软件等级 | 定义软件等级及依据 | 引用系统安全评估报告，说明为什么是这个等级。 |
| 3. 生命周期过程 | 描述开发、综合过程 | 列出所有过程，并说明每个过程的输入输出。 |
| 4. 软件生命周期数据 | 列出所有计划产出的数据 | 包括文档、代码、测试记录等。 |
| 5. 工具鉴定 | 列出所有需要鉴定的工具 | 说明每个工具的鉴定等级和方法。 |
| 6. 审定联络 | 说明与审查方的沟通计划 | 比如：多久开一次会？如何提交材料？ |
| 7. 变更管理 | 描述PSAC本身的变更流程 | 计划变了怎么办？谁来批准？ |
小技巧： 在写“生命周期过程”这一章时，我建议你画一张流程图。虽然PSAC里不强制要求，但一张清晰的图，能让审查方一眼看懂你的开发逻辑。我每次提交PSAC，都会附上一张A3纸大小的流程图，审查方看了都说好。
4.4 PSAC 的评审流程
PSAC写完了，不是直接提交就完事了。它需要经过严格的内部评审和外部评审。
4.4.1 内部评审
在提交给审查方之前，你的团队内部必须先过一遍。我建议至少包括以下角色：
- 项目负责人： 确认项目范围和时间节点是否合理。
- 系统工程师： 确认软件等级和系统安全要求是否一致。
- 软件工程师： 确认开发过程和技术方案是否可行。
- 质量保证（QA）： 确认文档格式和流程是否符合公司规范。
内部评审的目的，是确保PSAC在逻辑上是自洽的，没有明显的漏洞。
4.4.2 外部评审（与审查方沟通）
这是最关键的一步。PSAC提交给审查方后，通常会经历以下流程：
- 初步审查： 审查方会先快速浏览，看有没有明显的硬伤。比如软件等级定义错误、缺少关键过程等。
- 正式评审会议： 审查方会召集一个会议，逐条讨论PSAC的内容。这时候，你需要准备好回答各种问题。比如：“你为什么选择这个工具？”“你的测试覆盖率目标是多少？”
- 问题整改： 审查方会提出一堆问题（Review Findings）。你需要逐一回复，并修改PSAC。
- 批准： 当所有问题都关闭后，审查方会签署批准。这时候，PSAC就正式生效了。
避坑指南： 我曾经在外部评审时，因为PSAC里没有明确说明“软件需求的可追溯性方法”，被审查方打回来三次。第一次我补了一句“我们会做追溯”，他说不够具体。第二次我写了“使用工具做追溯”，他问“什么工具？怎么保证工具的输出是正确的？” 第三次我详细描述了工具的名称、版本、以及如何验证追溯矩阵的正确性，这才通过。所以，别想着糊弄，审查方比你想象的更专业。
4.5 总结
PSAC 是整个适航认证的“地基”。地基没打好，后面盖再高的楼都是危楼。我个人建议，在项目启动阶段，花足够的时间把PSAC写扎实。哪怕多花两周，也比后面返工强。
记住一句话：PSAC 不是一份文档，而是一个承诺。 你承诺了什么，就要做到什么。做不到，就别写进去。写进去了，就一定要做到。
最后送大家一个口诀： 等级定生死，过程要清晰，数据要完整，评审要较真。