嵌入式系统需求工程：从模糊需求到精确实现

1. 嵌入式系统需求工程的核心挑战

在嵌入式系统开发领域，我们常常面临一个根本性矛盾：用户需求总是模糊多变的，而嵌入式设备却要求精确到每个时钟周期的确定性行为。作为在工业控制领域摸爬滚打十余年的工程师，我见过太多因为需求不明确导致的灾难性后果——从自动售货机吞币不吐货，到医疗设备误触发致命操作。

1.1 自然语言需求的局限性

传统需求文档最致命的缺陷在于自然语言的二义性。记得有个汽车电子项目，需求文档写着"系统应在碰撞时快速打开安全气囊"。结果测试时发现：

• 机械工程师理解的"快速"是50ms内
• 软件团队实现的"快速"是200ms
• 而实际物理实验证明超过80ms就可能造成额外伤害

这种语义鸿沟（semantic bypass）在嵌入式系统中尤为危险。我曾参与调试过一个工业PLC系统，因为"当压力过高时关闭阀门"这条需求中：

• "压力过高"未定义阈值
• "关闭阀门"未说明是渐进式还是立即关闭 导致价值数百万的生产线阀门被瞬间关闭的液压冲击损毁。

1.2 优秀需求的八大特征

经过多年实践，我总结出优质嵌入式需求必须具备的特性：

经验之谈：在医疗设备项目中，我们要求每条需求都必须有对应的验证方法字段。例如"心率检测误差≤2bpm"对应"用ECG模拟器输入标准波形，对比显示值"。

2. 行为建模的双轨方法论

2.1 用例分析的实践技巧

用例(Use Case)是需求捕获的起点，但90%的团队都用错了。以智能门锁系统为例，典型错误包括：

• 只描述"happy path"（用户按预期操作）
• 忽略异常流（如指纹识别失败后的备用方案）
• 未定义前置条件（门锁电池电量临界值）

正确的用例模板应包含：

1. 用例名称：紧急开锁 2. 参与者：业主、物业管理员 3. 前置条件： - 系统供电正常 - 已录入管理员指纹 4. 主事件流： 1. 连续三次指纹验证失败 2. 系统启动声光报警 3. 自动发送求助短信给管理员 4. 管理员远程发送临时密码 5. 异常流： - 3.1 短信发送失败 → 启动本地蜂鸣器 - 4.1 密码验证超时 → 锁定键盘5分钟 6. 后置条件： - 系统日志记录异常事件 - 触发防拆传感器时上传位置信息

2.2 序列枚举的技术实现

当用例分析完成后，就需要用序列枚举技术填补那些"未说出口"的逻辑。以文章中的可乐机为例，其核心在于：

1. 黑盒建模：先定义清晰的输入输出接口

   • 输入：硬币/选择按钮/机器状态
   • 输出：饮料/找零/指示灯

2. 分层枚举：

   • Level 1：单事件响应（如投币→无输出）
   • Level 2：双事件组合（投币+退币→退钱）
   • ...
   • Level N：直到所有路径收敛

3. 等价类划分： 发现"投币三次+选择"与"投币两次+退币+投币三次+选择"应产生相同输出，这就是状态机的理论基础。

实操建议：

• 使用Excel数据验证功能约束输入值
• 用条件格式标出非法序列
• 添加"需求追踪"列确保全覆盖

3. 状态机设计的工程化转换

3.1 从枚举到状态变量

通过序列枚举，我们可以精确提取出系统必须记忆的历史信息。在可乐机案例中，关键状态变量包括：

typedef struct { uint8_t coin_count; // 0-3枚硬币 bool coke_available; // 是否有库存 bool power_on; // 是否通电 } VendingMachineState;

3.2 状态迁移图的绘制规范

工业级状态图必须包含：

1. 明确的状态标识（如S1:等待投币）
2. 完整的事件/动作标注（Q/coin++）
3. 异常处理路径（超时重置）
4. 并行状态标识（如同时监控温度和压力）

示例状态处理代码框架：

void handle_event(Event e) { switch(current_state) { case WAIT_COIN: if(e == QUARTER) { coin_count++; if(coin_count >=3) transition_to(READY); } break; case READY: if(e == SELECT) { dispense(); transition_to(WAIT_COIN); } ... } }

4. 工业实践中的进阶技巧

4.1 需求变更的管控策略

在汽车电子项目中，我们采用"需求基线+变更集"管理：

1. 冻结基线版本（如V1.0）
2. 所有修改通过变更单跟踪
3. 影响分析必须包含：
   • 相关序列枚举的调整
   • 状态机修改点
   • 回归测试用例

4.2 形式化验证的应用

对于安全关键系统（如轨道交通信号控制），我们会：

1. 将序列枚举转换为NuSMV模型
2. 用CTL公式验证属性：

   AG(power_on -> AF(coke_available))

   表示"一旦通电最终必须保证可乐可供应"

4.3 自动化工具链搭建

成熟团队应该建立：

1. 需求管理：DOORS或Jama
2. 行为建模：IBM Rhapsody
3. 代码生成：基于状态图自动生成框架代码
4. 测试覆盖：VectorCAST确保枚举路径全验证

5. 血泪教训：那些年踩过的坑

1. 时序问题：某工业控制器因未枚举"快速连续投币"场景，导致硬币计数器溢出。解决方案：

   • 添加防抖计时器
   • 状态机增加COIN_DEBOUNCE状态

2. 优先级冲突：电梯控制系统同时收到"紧急停止"和"楼层请求"。现在我们会：

   • 定义事件优先级矩阵
   • 在枚举表中用颜色区分紧急事件

3. 内存耗尽：智能电表因未处理"持续异常事件"导致日志溢出。改进措施：

   • 在枚举中明确循环缓冲区策略
   • 添加"内存临界"状态处理

最后分享一个实用checklist，用于评审需求质量：

1. [ ] 所有名词术语有明确定义（如"快速"=≤100ms）
2. [ ] 每个功能需求都有对应的异常处理
3. [ ] 输入输出边界值已明确（如硬币数0-3）
4. [ ] 状态持续时间有限制（如投币超时30秒）
5. [ ] 所有派生需求可追溯至原始需求

在嵌入式领域，需求工程不是纸上谈兵，而是防患于未然的关键屏障。每次项目启动前，我都会问团队：如果这个设备失控，最坏结果是什么？把这个问题的答案刻在需求文档的首页，或许能少走很多弯路。