3、需求分析：制动控制系统的功能需求、非功能需求与文档编写
好，我们进入第三章。这一章聊需求分析。
说实话，很多工程师觉得需求分析是「产品经理的事」，跟我搞软件的没关系。我年轻时也这么想。直到有一次，我按着模糊的需求把代码写完了，结果台架测试时发现——制动响应慢了50毫秒。嗯，50毫秒，在制动系统里，可能就是一场事故的距离。
所以，需求分析不是走形式。它是整个制动控制软件的「宪法」。后面所有的架构设计、模块划分、代码实现，都得围着它转。
3.1 制动控制系统的功能需求
功能需求，说白了就是「系统要干什么」。制动控制系统的核心功能，我归纳为以下几条：
- 基础制动控制：根据驾驶员踩下制动踏板的行程，计算出目标制动压力，并控制液压单元执行。这是最根本的功能，不能有任何闪失。
- 防抱死制动（ABS）：在紧急制动时，防止车轮完全抱死。我参与过一个项目，ABS介入的时机判断错了0.1秒，结果测试车在湿滑路面上直接侧滑出去。嗯，从那以后我对轮速信号的滤波算法格外敏感。
- 电子制动力分配（EBD）：根据车辆载荷和前后轴附着力，动态分配前后轮的制动力。说白了，就是让车在刹车时不「点头」太厉害，同时保持稳定。
- 车身稳定控制（ESC）：通过主动对单个车轮施加制动力，纠正车辆的横摆力矩。这个功能对实时性要求极高，后面我们会细说。
- 再生制动协调：对于新能源车，需要协调电机的再生制动和液压制动。我见过一个案例，再生制动退出时液压制动没有及时补上，导致制动踏板「空行程」——驾驶员感觉像踩空了，非常吓人。
我的经验：功能需求一定要写清楚「触发条件」和「退出条件」。比如ABS，不能只说「在紧急制动时激活」，要写明：轮速减速度超过阈值且滑移率超过15%时激活，车速低于5km/h时退出。否则，测试用例都没法写。
3.2 制动控制系统的非功能需求
非功能需求，是「系统要干得多好」。制动系统是安全件，非功能需求比功能需求更致命。我重点讲三个：实时性、安全性、可靠性。
3.2.1 实时性
制动控制是典型的硬实时系统。什么叫硬实时？就是错过截止时间，等于系统失效。
我列一个典型的实时性指标表，供你参考：
| 功能模块 | 控制周期 | 最大允许延迟 | 备注 |
|---|---|---|---|
| 基础制动控制 | 2ms | 1ms | 踏板信号采样到执行器响应 |
| ABS控制 | 5ms | 2ms | 轮速信号处理到电磁阀动作 |
| ESC控制 | 10ms | 5ms | 横摆角速度传感器到单轮制动 |
| CAN通信 | 10ms | 5ms | 接收其他ECU的信号 |
你想想看，2ms的控制周期意味着什么？意味着你的主循环必须在2ms内跑完所有任务。如果某个函数执行时间超过500μs，你就得考虑把它拆开或者放到低优先级任务里。
避坑指南：我曾经在一个项目里，把轮速滤波算法写得太复杂了，一个周期跑了800μs。结果ABS控制周期被拖到了3ms以上，轮速信号出现了明显的相位滞后。后来我把滤波算法改成了滑动窗口平均，执行时间降到了150μs。嗯，有时候简单就是最好的。
3.2.2 安全性
制动系统的安全性，必须达到ASIL D等级（ISO 26262）。这意味着什么？
- 单点故障容错：任何一个硬件或软件模块失效，系统必须能进入安全状态。比如，主MCU挂了，备份MCU必须在10ms内接管。
- 故障检测覆盖率：对关键信号（如制动压力、轮速）必须有诊断机制。我习惯的做法是：每个传感器信号都做「合理性检查」——比如制动压力信号，如果变化率超过50bar/ms，基本可以判定传感器故障。
- 安全状态定义：系统检测到故障后，要进入什么状态？是降级运行（比如只保留基础制动），还是完全关闭？我个人建议：对于制动系统，永远不要完全关闭。降级到「机械备份模式」是最稳妥的。
警告：安全需求不是写出来就完事了。它需要贯穿整个开发流程。我见过一个团队，安全需求文档写了200页，结果代码里连一个看门狗都没加。文档写得再好，代码不落地，等于零。
3.2.3 可靠性
可靠性，说白了就是「系统能稳定运行多久不失效」。对于制动系统，整车厂通常要求：
- MTBF（平均无故障时间）：不低于100,000小时
- 使用寿命：与整车同寿命，通常15年或300,000公里
- 环境适应性：温度范围-40°C到125°C，湿度95%RH，振动等级按ISO 16750
我特别想强调一点：可靠性不是测出来的，是设计出来的。你想想看，如果代码里用了动态内存分配，在高温下内存碎片化导致malloc失败，那系统就挂了。所以，制动控制软件里，我从来不用动态内存分配，全部静态分配。
3.3 需求文档的编写
好，需求分析完了，怎么把它写下来？
我个人习惯用「需求编号+需求描述+验收标准」的三段式结构。举个例子：
需求编号：REQ-BRK-ABS-001
需求描述：当车辆在直线行驶且车速大于10km/h时，系统应能检测到车轮抱死趋势，并在100ms内激活ABS控制。
验收标准：
1. 在干沥青路面（附着系数0.8）上，以100km/h初速度紧急制动，ABS介入时间不超过100ms。
2. 在湿滑路面（附着系数0.3）上，以60km/h初速度紧急制动，ABS介入时间不超过150ms。
3. 任何单轮抱死持续时间不超过200ms。为什么要写验收标准？因为需求不能模棱两可。你说「ABS要快速介入」，多快算快？100ms还是200ms？没有验收标准，开发和测试就会扯皮。
我的建议：需求文档最好用「需求管理工具」来维护，比如DOORS或者Polarion。别用Word。我见过一个项目，Word版本混乱，有人改了需求没通知其他人，结果开发按旧需求做，测试按新需求测，全乱套了。
另外，需求文档要分层次：
- 系统级需求：整车厂给的定义，比如「制动距离不超过40m（100km/h初速度）」
- 软件级需求：我们软件团队要实现的，比如「ABS控制周期为5ms」
- 模块级需求：具体到某个模块的，比如「轮速信号滤波模块的截止频率为20Hz」
每一层需求都要可追溯。系统级需求分解到软件级，软件级再分解到模块级。这样，当整车厂问「你这个功能能不能满足制动距离要求」时，你可以直接追溯到对应的软件实现。
嗯，这一章的内容就到这里。需求分析是地基，地基打不牢，后面盖的楼再漂亮也没用。下一章，我们聊聊制动控制软件的顶层架构设计——怎么把需求变成模块。