3. 计划阶段（PSAC）：软件合格审定计划的内容、编写要点与评审
各位工程师，咱们今天聊聊PSAC。
PSAC，全称是“软件合格审定计划”。说白了，它就是整个DO-178C项目的“宪法”。你想想看，一个项目动辄几十万行代码，如果没有一份清晰的计划，后面肯定乱成一锅粥。
我个人习惯，拿到一个新项目，第一件事不是写代码，而是先把PSAC的框架搭起来。为什么？因为PSAC决定了你后面所有工作的“游戏规则”。
3.1 PSAC到底要写什么？
PSAC不是一本天书，它是一份可执行的计划。我把它拆成几个核心模块，你照着这个思路写，基本不会跑偏。
| 模块 | 核心内容 | 我的经验 |
|---|---|---|
| 1. 系统概述 | 软件在飞机上的功能、系统架构 | 别写太虚，要具体到哪个LRU |
| 2. 软件等级 | A/B/C/D/E级，以及降级依据 | 降级必须有局方认可的证据 |
| 3. 生命周期 | 定义开发、验证、配置管理等流程 | 建议用图表示，一目了然 |
| 4. 工具鉴定 | 列出所有工具，说明鉴定等级 | 工具版本号一定要写清楚 |
| 5. 数据清单 | 所有计划产出的文件列表 | 包括LAL、SAS等 |
| 6. 偏差与豁免 | 计划偏离DO-178C的地方 | 提前沟通，别等审查时再说 |
核心要点：PSAC必须回答三个问题——你要做什么？你怎么做？你怎么证明你做对了？
3.2 编写要点：别踩这些坑
我在项目中遇到过不少PSAC写得“四不像”的情况。嗯，这里我总结几个最常见的坑。
3.2.1 软件等级别写错
有一次，一个同事把B级软件写成了C级。结果审查时局方直接问：“你凭什么降级？” 场面一度非常尴尬。记住，等级判定必须基于系统安全评估（SSA），不能拍脑袋。
3.2.2 生命周期定义要闭环
你定义了“需求阶段”，那就要写清楚：输入是什么？输出是什么？谁负责？用什么工具？我曾经见过一份PSAC，写了“进行需求评审”，但没写评审标准。这等于没写。
3.2.3 工具鉴定别遗漏
DO-178C对工具要求很严。编译器、静态分析工具、测试工具，只要它“消除、替代或自动化”了人工活动，就必须鉴定。我建议你列一个工具清单，逐个确认。
我的小技巧：写PSAC时，先画一张流程图。把开发、验证、配置管理、质量保证的流程串起来。流程通了，文档自然就顺了。
3.3 PSAC的评审：别当走过场
PSAC写完后，要经过正式评审。评审不是找茬，而是帮你堵漏洞。
评审时，我一般关注这几个点：
- 一致性：PSAC里的描述，和系统需求、项目计划是否一致？
- 完整性：所有DO-178C要求的内容都覆盖了吗？特别是“软件生命周期环境”部分。
- 可执行性：计划里的方法，团队真的能做到吗？别写“用形式化方法验证”，结果团队没人会。
警告：PSAC一旦被局方批准，就是“铁律”。后续任何变更，都必须走正式的变更流程。我曾经有一个项目，因为临时换了一个编译器版本，没更新PSAC，结果被开了不符合项。
3.4 知识体系图：PSAC的核心逻辑
下面这张图，是我自己总结的PSAC核心逻辑。你写文档时，可以照着这个框架来。
3.5 避坑指南：我踩过的雷
我曾经在一个项目中，PSAC写得特别“完美”，但实际执行时发现根本做不到。比如，我写了“所有代码走查由高级工程师执行”，结果项目组就两个高级工程师，根本忙不过来。
所以，我建议你写PSAC时，多和团队成员聊一聊。确认一下：
- 这个流程，大家真的能执行吗？
- 这个工具，大家真的会用吗？
- 这个时间节点，真的合理吗？
记住：PSAC不是写给局方看的“面子工程”，它是你整个项目的“作战地图”。地图画错了，仗怎么打？
好了，关于PSAC，今天就聊这么多。你写的时候，如果遇到拿不准的地方，随时翻翻DO-178C的第2章和第11章，那里有最权威的指导。