4、需求分析与系统建模：ABS系统功能需求、非功能需求、需求分析方法、SysML/UML建模基础
好，咱们进入第四章。说实话，很多工程师觉得写需求就是走个过场，真正干活还是靠画板子、调代码。我以前也这么想，直到有一次……嗯，ABS项目做到一半，客户突然说“你们这个制动响应时间不对啊，我们要求150ms以内，你们怎么测出来180ms？”
翻需求文档？翻出来一看，里面只写了“响应要快”。你说这锅该谁背？从那以后，我养成了一个习惯：需求分析阶段多花一周，后面调试少花一个月。
4.1 ABS系统的功能需求
功能需求，说白了就是“系统要干什么”。对于ABS来说，核心功能其实就一条：防止车轮抱死。但你不能只写这一句，得拆开。
我个人习惯把功能需求分成三个层次：
- 感知层：轮速传感器要能检测到0~250km/h的车速，精度±1%。
- 决策层：ECU要能根据轮速差判断是否即将抱死，并在10ms内输出减压指令。
- 执行层：液压调节器要在5ms内完成增压、保压、减压三种状态的切换。
你看，这样写出来，测试工程师拿到手就知道怎么测。我在项目中遇到过最坑的事，就是需求里写“系统应能正常工作”，结果测试组和开发组对“正常工作”的理解差了十万八千里。
关键点：功能需求必须可验证。每个需求后面都要跟一句“如何验证”。比如“轮速传感器精度±1%”怎么验证？拿标准信号源灌进去，看输出对不对。
4.2 非功能需求：那些容易被忽略的“隐形杀手”
非功能需求，就是系统“要运行得多好”。ABS系统里，非功能需求往往比功能需求更致命。为什么？因为功能出问题，车还能刹住（只是体验差）；非功能出问题，车可能直接刹不住。
我列几个ABS里最要命的非功能需求：
| 类别 | 具体需求 | 典型指标 |
|---|---|---|
| 实时性 | 从轮速突变到输出控制指令 | ≤ 10ms |
| 可靠性 | 系统无故障运行时间 | ≥ 10000小时 |
| 安全性 | 单点故障不导致制动失效 | ASIL D |
| 环境适应性 | 工作温度范围 | -40℃ ~ 125℃ |
| 电磁兼容性 | 抗辐射干扰 | 100V/m |
嗯，这里要注意。非功能需求不是写出来就完事了，你得有办法去验证。我曾经在一个项目里，需求写了“系统应满足ASIL D”，结果到功能安全认证的时候才发现，整个软件架构根本没按ASIL D来设计。那叫一个惨……
避坑指南：我曾经以为非功能需求是“架构师的事”，跟写代码的没关系。后来发现，非功能需求必须落实到每个模块的接口和时序约束里。比如实时性需求，你得在需求文档里明确写出“CAN报文发送周期不超过5ms”，而不是笼统地说“系统要实时”。
4.3 需求分析方法：怎么把“人话”变成“机器话”
需求分析，说白了就是翻译。把客户说的“刹车要灵敏”翻译成“制动压力上升斜率≥200bar/s”。怎么翻译？我一般用三步法：
- 场景分析法：列出所有可能的驾驶场景。比如干燥路面、湿滑路面、冰雪路面、对开路面（左边冰右边柏油）。每个场景下，ABS的行为都不一样。
- 用例分析法：画用例图。谁在用系统？驾驶员、诊断仪、生产线。每个角色对系统有什么期望？
- 约束分析法：有什么限制？成本、功耗、芯片选型、通信协议。这些约束会直接影响你的架构设计。
举个例子。客户说“ABS要在各种路面上都能正常工作”。你想想看，这句话能直接写进需求文档吗？不能。你得拆：
- 干燥沥青路面：制动距离≤40m（初速度100km/h）
- 湿滑路面：制动距离≤60m
- 冰雪路面：制动距离≤100m
- 对开路面：车辆不偏离车道超过0.5m
这样写，开发人员才知道代码里要判断哪些条件，测试人员才知道要准备哪些测试用例。
4.4 SysML/UML建模基础：让需求“看得见”
光写文字需求，容易产生歧义。我建议用模型来辅助。UML和SysML就是干这个的。UML偏软件，SysML偏系统。ABS这种软硬结合的系统，我一般混着用。
4.4.1 用例图（Use Case Diagram）
用例图用来展示“谁”要“做什么”。ABS系统的用例图大概长这样：
+-------------------+ +-------------------+
| 驾驶员 | | 诊断仪 |
+-------------------+ +-------------------+
| |
| 触发制动 | 读取故障码
v v
+-------------------------------------------+
| ABS系统 |
| - 防止车轮抱死 |
| - 提供制动压力调节 |
| - 自诊断与故障上报 |
| - 与ESC/TCS协同工作 |
+-------------------------------------------+
你看，一张图就把系统边界和交互关系说清楚了。我在项目中遇到过最头疼的事，就是开发到一半发现“哎？这个功能到底算ABS的还是ESC的？”——如果有用例图，这种问题一开始就能避免。
4.4.2 状态机图（State Machine Diagram）
ABS的核心逻辑就是状态切换。我习惯用状态机图来描述：
状态：正常制动 -> 检测到抱死趋势 -> 进入ABS调节 -> 退出ABS调节 -> 回到正常制动
触发条件：
- 正常制动 -> 检测到抱死趋势：轮速减速度 > 阈值
- 检测到抱死趋势 -> 进入ABS调节：轮速差 > 阈值
- 进入ABS调节 -> 退出ABS调节：轮速恢复 > 阈值
- 退出ABS调节 -> 正常制动：轮速稳定 > 阈值
嗯，这里要注意。状态机图里的每个状态，都要对应到代码里的一个模块。我曾经见过一个项目，状态图画了十几页，结果代码里全用if-else硬写，最后状态一多就乱套了。
4.4.3 时序图（Sequence Diagram）
时序图用来展示“时间顺序”。ABS里最关键的时序就是“从轮速变化到制动压力调整”的整个过程：
轮速传感器 -> ECU: 发送轮速数据 (每10ms)
ECU -> 控制算法: 计算滑移率
控制算法 -> 液压调节器: 输出减压指令 (5ms内)
液压调节器 -> 制动轮缸: 降低制动压力
为什么时序图重要？因为实时性需求就靠它来验证。我建议每个关键路径都画一张时序图，然后标出每个步骤的时间预算。比如：
- 传感器采集：2ms
- CAN通信：3ms
- 算法计算：3ms
- 执行器响应：2ms
- 总时间：10ms
如果总时间超过了需求里的10ms，那你就得优化了。是换更快的传感器？还是优化算法？还是换更快的执行器？这些决策，都得基于时序图来做。
个人经验：我习惯在需求分析阶段就把时序图画出来，哪怕只是草稿。因为画着画着，你就会发现一些“隐藏”的依赖关系。比如有一次我画时序图时发现，ABS和ESC共用了同一个CAN消息，但两个系统的周期不一样，导致数据冲突。这个问题如果在需求阶段发现，改起来很容易；要是等到联调才发现，那就得改代码、改协议、改测试用例……
4.5 小结：需求分析不是“写文档”，是“建模型”
说了这么多，其实就一句话：需求分析不是写作文，是建模。文字只是载体，真正的价值在于你通过分析、拆解、建模，把模糊的客户需求变成清晰的系统规格。
我个人习惯，每个项目开始前，先花一周时间做需求分析。产出物包括：
- 一份功能需求列表（可验证的）
- 一份非功能需求列表（带指标的）
- 一套UML/SysML模型（用例图、状态机图、时序图）
有了这些东西，后面的设计、开发、测试，都会顺畅很多。你想想看，如果连需求都没搞清楚就开始写代码，那不是给自己挖坑吗？
好，这一章就到这儿。下一章咱们聊聊ABS的软件架构设计，到时候我会拿一个实际项目的架构图出来，咱们一起拆解。