3、需求分析实战：从任务书到软硬件需求的分解与文档化
好，咱们进入第三讲。前面两章我们把太阳翼驱动机构的整体架构和关键器件聊透了。今天要干的活，说白了就是——把任务书里那些“人话”，翻译成工程师能懂的“技术话”。
我个人习惯，拿到一份任务书，先不急着看技术指标。我会先看“约束条件”。为什么？因为指标可以谈，约束往往是死线。比如“整机重量不超过2.5kg”、“工作温度-40℃到+85℃”、“功耗不超过15W”。这些是硬杠杠，后面所有设计都得绕着它们转。
3.1 任务书的“三层皮”
一份典型的太阳翼驱动机构任务书，我习惯把它剥成三层：
- 顶层：系统级要求——比如“驱动机构寿命15年”、“在轨可靠度0.999”。这种话听着很虚，但它是所有设计的源头。
- 中间层：功能与性能要求——比如“驱动速度0.1°/s”、“定位精度±0.05°”、“具备遥测遥指令接口”。这些是我们要分解的核心。
- 底层：环境与接口要求——比如“抗辐照总剂量50krad”、“EMC满足GJB151B”、“机械接口为M6螺栓×4”。这些决定了你的器件选型和结构设计。
嗯，这里要注意：任务书里经常藏着“隐含要求”。比如它只写了“工作温度-40℃~+85℃”，但没写“存储温度”。你想想看，卫星发射前可能要在地面存放半年，存储温度范围往往更宽。我曾经就吃过这个亏，选了个工业级芯片，存储温度上限才85℃，结果地面测试时仓库温度到了90℃，差点翻车。
3.2 从“系统级”到“软硬件”的分解方法
分解需求，我有一套固定的流程。说白了就是三步走：
- 功能拆解：把“驱动太阳翼”这个动作，拆成“电机转动”、“角度测量”、“位置锁定”、“故障诊断”等子功能。
- 性能分配：把“定位精度±0.05°”这个指标，分配给“电机控制精度”、“编码器分辨率”、“机械传动间隙”三个环节。每个环节分多少？我一般用误差预算表。
- 接口定义：明确软硬件之间的“握手协议”。比如“CPU每10ms发送一次角度指令”、“电机驱动器收到指令后必须在5ms内响应”。
实战案例： 我参与过一个项目，任务书要求“太阳翼对日指向精度优于0.1°”。乍一看很简单。但分解后发现，编码器分辨率0.01°、电机步距角0.036°、减速器回差0.03°，再加上控制算法的跟踪误差0.02°，平方和开根号一算——0.054°，勉强合格。如果当时没做这个分解，直接拍脑袋选器件，后面肯定要返工。
3.3 需求文档化的“三张表”
文档化不是写作文，是把需求变成可追溯、可验证的条目。我习惯用三张表：
表1：软件需求规格表（SRS）
| 编号 | 需求描述 | 优先级 | 验证方法 |
|---|---|---|---|
| SRS-001 | 系统上电后，应在500ms内完成自检 | 高 | 示波器测量上电到自检完成信号 |
| SRS-002 | 角度控制周期为10ms，误差不超过±1ms | 高 | 逻辑分析仪抓取控制周期 |
| SRS-003 | 当检测到电机堵转时，应在20ms内切断驱动 | 中 | 注入堵转信号，测量保护响应时间 |
表2：硬件需求规格表（HRS）
| 编号 | 需求描述 | 关键参数 | 备注 |
|---|---|---|---|
| HRS-001 | 电机驱动器额定电流≥2A | 峰值3A，持续1s | 考虑启动冲击 |
| HRS-002 | 编码器分辨率≥0.01° | 输出接口：RS-422 | 抗辐照等级需满足 |
| HRS-003 | 电源模块输入28V±6V，输出5V/3.3V | 纹波≤50mVpp | 需加EMI滤波器 |
表3：软硬件接口表（HSI）
| 接口编号 | 信号名称 | 方向 | 电气特性 | 时序要求 |
|---|---|---|---|---|
| HSI-001 | 角度指令 | CPU→驱动器 | TTL 3.3V | 脉宽100μs±10μs |
| HSI-002 | 编码器数据 | 编码器→CPU | RS-422差分 | 波特率2.5Mbps |
| HSI-003 | 故障标志 | 驱动器→CPU | 开漏输出，上拉3.3V | 低电平有效，持续≥1ms |
我的小技巧： 这三张表不是一次写死的。我会先写个V0.1版，然后拿着它去和系统工程师、结构工程师、测试工程师“吵架”。吵完一轮，改到V0.3版，基本就稳了。文档化的过程，其实就是把模糊的共识变成白纸黑字。
3.4 避坑指南：需求分解中的“三个坑”
做这行十几年，我踩过的坑不少。挑三个最典型的说说：
- 坑一：忽略“非功能性需求”。比如“软件可维护性”、“硬件可测试性”。任务书里不会写，但你不考虑，后面维护阶段会哭。我曾经设计过一个驱动板，所有测试点都藏在电机下面，每次调试都得拆电机——嗯，后来被测试工程师追着骂了三天。
- 坑二：需求粒度太粗。比如只写“电机能正反转”，没写“正反转切换时间不超过50ms”。结果软件按100ms做，硬件按20ms设计，联调时发现时序对不上。这种问题，在需求阶段用一张时序图就能避免。
- 坑三：软硬件接口“想当然”。比如软件认为“硬件会在中断里自动清标志”，硬件认为“软件会读完后手动清标志”。结果呢？标志位永远为1，系统死循环。我建议，所有接口信号的行为，必须用时序图+状态机画清楚，别靠默契。
特别提醒： 需求文档写完后，一定要做一次“需求追溯矩阵”。就是把每个需求条目，和后面的设计文档、测试用例一一对应起来。别问我为什么强调这个——我见过一个项目，写了200条需求，最后测试时发现30条根本没实现，因为设计阶段就把它们漏了。
3.5 一个完整的分解示例
咱们拿“太阳翼驱动机构具备角度闭环控制功能”这条需求，走一遍完整的分解流程：
第一步：功能拆解
- 角度采集（硬件：编码器；软件：读取并滤波）
- 角度计算（软件：PID控制器）
- 电机驱动（硬件：H桥电路；软件：PWM生成）
- 故障检测（硬件：电流采样；软件：过流判断）
第二步：性能分配
- 编码器分辨率：0.01°（硬件负责）
- PID控制周期：10ms（软件负责）
- PWM频率：20kHz（硬件负责）
- 电流采样精度：±5%（硬件负责）
- 过流响应时间：<10ms（软硬件协同）
第三步：接口定义
- 软件每10ms通过SPI发送目标角度给硬件
- 硬件每1ms通过SPI返回当前角度和电流值
- 当电流超过阈值时，硬件自动拉高中断引脚，软件在中断服务函数中处理
你看，一条模糊的“角度闭环控制”，经过这三步，变成了可设计、可验证、可测试的具体条目。这就是需求分析的价值。
好了，这一讲就到这里。下一讲我们开始进入硬件设计环节，聊聊电机驱动器的选型与电路设计。到时候我会分享一个我当年选型踩过的坑——嗯，那个故事挺有意思的。