摘要：本文介绍了航空电子FPGA开发中的需求层级，从PRD到HDD，通过一张图和通俗比喻，帮助读者理解这些文档在DO-254/ARP4754体系中的位置和作用，以及FPGA工程师在需求追溯中的角色和职责。
写给 FPGA 新人的话：刚入行航空电子时，相比新人会被一堆缩写搞懵了——SRD、ERD、HRD、HDD、PRD…… 本文试图用一张图和几个通俗比喻，帮你理清这些文档在 DO-254/ARP4754 体系中的位置和作用。
一、为什么要搞懂这些文档？（立住规矩）
在航空领域，FPGA 不是"写完了能跑就行"。适航标准（主要是 DO-254）要求你必须证明：每一个硬件功能都有明确的需求来源，每一个需求都被设计实现，每一个设计都被测试验证。
这个过程叫做 需求追溯（Traceability）。而追溯的链条，就是靠一层层的需求文档串起来的。
二、需求层级全景图（自上而下）
如果把一架飞机比作一个人，需求分解的过程就像是从"这个人要做什么"逐步细化到"每个细胞怎么工作"。
flowchart TD
classDef aircraft fill:#e1f5fe,stroke:#01579b,stroke-width:2px,color:#000
classDef system fill:#fff3e0,stroke:#e65100,stroke-width:2px,color:#000
classDef equipment fill:#f3e5f5,stroke:#4a148c,stroke-width:2px,color:#000
classDef hardware fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px,color:#000
classDef design fill:#fce4ec,stroke:#880e4f,stroke-width:2px,color:#000
classDef fpgaRole fill:#fffde7,stroke:#f57f17,stroke-width:1px,stroke-dasharray: 5 5,color:#000
A["🛫 飞机级需求<br/>Aircraft Level Requirements<br/>『飞机要能自动着陆』"]:::aircraft
B["📋 SRD<br/>System Requirements Document<br/>系统需求文档<br/>ARP4754A 管辖<br/>『自动着陆系统接收 GPS/ILS 信号』"]:::system
C["📦 ERD<br/>Equipment Requirements Document<br/>设备需求文档<br/>ARP4754A / DO-254 交界<br/>『导航计算机输出位置数据，20Hz』"]:::equipment
D["🔧 HRD<br/>Hardware Requirements Document<br/>硬件需求文档<br/>DO-254 核心管辖<br/>『FPGA 实现 UART 115200 8N1』"]:::hardware
E["💻 HDD<br/>Hardware Design Description<br/>硬件设计描述<br/>DO-254 实现层<br/>Verilog/VHDL、原理图、约束文件"]:::design
P["📑 PRD<br/>Product/Project Requirements Document<br/>产品/项目需求文档<br/>公司内部定义（非 DO-254 标准术语）"]:::system
R3["👤 FPGA 工程师<br/>✍️ 核心编写工作"]:::fpgaRole
R4["👤 FPGA 工程师<br/>✍️ 核心设计实现"]:::fpgaRole
A -->|"分解为"| B
B -->|"分配到设备"| C
C -->|"细化到硬件"| D
D -->|"设计实现为"| E
P -.->|"可能分解为"| C
D -.-> R3
E -.-> R4
E -.->|"向上追溯"| D
D -.->|"向上追溯"| C
C -.->|"向上追溯"| B
B -.->|"向上追溯"| A三、各层级详解（FPGA 工程师视角）
1. SRD — System Requirements Document（系统需求文档）
这是谁写的？ 系统工程师。
FPGA 工程师需要做什么？ 读它，理解系统要做什么。
SRD 描述的是系统层面的功能和性能。比如"飞行管理系统（FMS）要能在 5 秒内完成航路计算"。这时候 FPGA 还只是系统框图里的一个"黑盒子"，可能标注为"信号处理模块"。
关键认知：SRD 通常不会直接提到 FPGA 内部的寄存器或时序，它关心的是系统输入输出。
2. ERD — Equipment Requirements Document（设备需求文档）
这是谁写的？ 设备/模块级工程师。
FPGA 工程师需要做什么？ 参与评审，确认分配给 FPGA 的功能边界。
ERD 把 SRD 的系统功能分解到具体的设备（LRU，Line Replaceable Unit）。比如"导航计算机"作为一个设备，它要包含电源板、接口板、FPGA 处理板。
ERD 会定义：
- 设备的物理接口（连接器型号、引脚定义）
- 设备的性能指标（延迟、吞吐量）
- 设备的环境要求（温度、振动）
对 FPGA 的意义：ERD 是你 FPGA 所在"盒子"的顶层约束。如果 ERD 说"接口延迟必须小于 1ms"，你的 FPGA 设计就必须满足这个。
3. HRD — Hardware Requirements Document（硬件需求文档）
这是谁写的？ 硬件工程师（就是你！）。
这是 DO-254 的 C 级审查核心。
HRD 把 ERD 中分配给 FPGA/硬件的功能进一步细化，变成可验证的硬件需求。HRD 里的每一条需求，最终都要在测试用例里被覆盖。
HRD 的典型内容：
| 需求 ID | 需求描述 | 来源（追溯） |
|---|---|---|
| HRD_001 | FPGA 应实现 1 路 RS422 接收，波特率 115200，8N1 | ERD_042 |
| HRD_002 | 数据解析模块应在收到帧头后 10μs 内输出有效标志 | ERD_055 |
| HRD_003 | 内部 FIFO 深度应不小于 1024 字 | 系统安全性分析 |
关键认知：
- HRD 必须用可验证的语言写。避免"高性能"、"快速"这种模糊词。
- 每一条 HRD 都必须能向上追溯到 ERD/SRD。
- DO-254 审查官会随机抽 HRD 条目，检查它是否有设计实现和测试覆盖。
4. HDD — Hardware Design Description（硬件设计描述）
这是谁写的？ 还是你，FPGA 工程师。
这是需求的"实现层"。
HDD 不是一份单独的"文档"，而是所有设计产物的集合：
- HDL 源代码（Verilog/VHDL）
- 原理图和 PCB 布局
- 时序约束文件（SDC/XDC）
- 设计说明文档（模块划分、状态机描述、算法流程）
HDD 与 HRD 的关系：
- HRD 说"要什么"（What）
- HDD 说"怎么做"（How）
DO-254 要求 HDD 能向下覆盖 HRD。简单说：HRD 里的每一条需求，你都要在 HDD 里找到对应的设计实现。
四、那 PRD 是什么？
在 DO-254 和 ARP4754A 的标准术语里，并没有 PRD 这个缩写。
但在实际项目中，你看到的 PRD 通常指以下几种之一：
| 可能的含义 | 解释 | 在层级中的位置 |
|---|---|---|
| Product Requirements Document（产品需求文档） | 公司某款"产品"（如某型飞行控制计算机）的顶层需求，向下分解为多个 ERD | ERD 之上 |
| Project Requirements Document（项目需求文档） | 某个具体项目/合同的交付要求，包含进度、合规、配置管理要求 | 与 ERD 平行或之上 |
| Process Requirements Document（过程需求文档） | 定义开发过程、工具链、编码规范等 | 过程域，非功能需求 |
建议：如果你在公司文档里看到 PRD，先查一下公司的《术语表》或《需求管理计划》，确认具体定义。不同公司用法不同，不要假设。
五、FPGA 工程师的日常：需求追溯怎么落地？
作为 FPGA 工程师，你不需要写 SRD 和 ERD，但你要深刻理解它们。你的核心工作是在 HRD ↔ HDD ↔ 测试 之间建立闭环。
实际工作流示例
flowchart TD
%% ========== 样式定义 ==========
classDef read fill:#e3f2fd,stroke:#1565c0,stroke-width:2px,color:#000
classDef write fill:#fff8e1,stroke:#f9a825,stroke-width:2px,color:#000
classDef design fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px,color:#000
classDef test fill:#fce4ec,stroke:#c2185b,stroke-width:2px,color:#000
classDef review fill:#f3e5f5,stroke:#6a1b9a,stroke-width:2px,color:#000
classDef trace fill:#e0f2f1,stroke:#00695c,stroke-width:1px,stroke-dasharray: 5 5,color:#000
classDef milestone fill:#ffebee,stroke:#b71c1c,stroke-width:3px,color:#000
%% ========== 步骤 1：读需求 ==========
S1["📖 Step 1：读 SRD / ERD<br/>理解系统要求"]:::read
S1_Detail["每秒处理 1000 个雷达回波<br/>（系统级指标）"]:::read
%% ========== 步骤 2：写 HRD ==========
S2["✍️ Step 2：写 HRD<br/>硬件需求文档"]:::write
S2_Detail["FPGA 雷达接口模块<br/>以 1MHz 速率接收 ADC 采样数据"]:::write
T1["🔗 追溯至 ERD_xxx"]:::trace
%% ========== 步骤 3：写 HDD（设计）==========
S3["💻 Step 3：写 HDD<br/>硬件设计描述"]:::design
S3_Detail["module adc_interface<br/>SPI 接收 + FIFO 缓冲 + 状态机"]:::design
T2["🔗 追溯：HRD_xxx 由<br/>adc_interface 实现"]:::trace
%% ========== 步骤 4：写测试 ==========
S4["🧪 Step 4：写 Test Cases<br/>测试验证"]:::test
S4_Detail["Testbench 注入 1MHz 数据<br/>检查 FIFO 不溢出"]:::test
T3["🔗 追溯：覆盖 HRD_xxx<br/>测试通过 ✓"]:::trace
%% ========== 步骤 5：审查 ==========
S5["🔍 Step 5：适航审查"]:::review
S5_Q["审查官：HRD_xxx 这条需求<br/>设计在哪？测了吗？"]:::review
S5_A["出示 HDD 代码 + 测试报告<br/>链路闭合 ✓"]:::review
DONE["🎉 DO-254 需求追溯闭环"]:::milestone
%% ========== 流程连接 ==========
S1 --> S1_Detail
S1_Detail -->|"分解"| S2
S2 --> S2_Detail
S2_Detail --> T1
T1 -->|"驱动"| S3
S3 --> S3_Detail
S3_Detail --> T2
T2 -->|"验证"| S4
S4 --> S4_Detail
S4_Detail --> T3
T3 -->|"审查"| S5
S5 --> S5_Q
S5_Q --> S5_A
S5_A --> DONE
%% ========== 双向追溯示意 ==========
DONE -.->|"向上追溯<br/>Trace Up"| T3
T3 -.-> T2
T2 -.-> T1
T1 -.->|"追溯到源头"| S1_Detail六、新手容易踩的坑
| 坑 | 为什么危险 | 怎么办 |
|---|---|---|
| HRD 写得太像设计 | 把"用什么算法"写进需求，导致设计变更时必须改需求 | HRD 只写"要什么"，不写"怎么做" |
| 需求没有唯一 ID | 无法追溯，审查时找不到对应关系 | 所有需求必须有全局唯一编号（如 HRD_FPGA_001） |
| 需求不可验证 | "处理速度尽量快"——怎么算通过？ | 用数字说话："延迟 ≤ 5μs" |
| 忽略 ERD 的接口定义 | FPGA 引脚分配错误，导致板子改线 | 早期就冻结接口需求，与硬件/结构对齐 |
七、一句话总结
SRD 定义系统做什么，ERD 定义设备做什么，HRD 定义 FPGA 做什么，HDD 定义 FPGA 怎么做。PRD 可能是你们公司的"产品需求"，先查内部定义。DO-254 的核心就是：每一层都能向上追溯、向下覆盖、中间有验证。
参考标准
- DO-254：《Design Assurance Guidance for Airborne Electronic Hardware》
- ARP4754A：《Guidelines for Development of Civil Aircraft and Systems》
如有错误，欢迎指正交流。
