从用例到MILS测试的全链路追溯——丰田底盘开发中...

hyowinner

原讲者：丰田汽车 底盘开发第2开发部 Takeaki Koga

---

各位MBD同仁，大家好。

今天想和大家分享一篇非常接地气的MBSE实践案例——来自丰田Koga先生在2025年系统工程峰会上的演讲。这个案例最打动我的地方，是它没有空谈“数字孪生”或“全自动建模”，而是老老实实地解决了两个最现实的问题：

• 顶层需求分析怎么才能不“拍脑袋”？
• 模型怎么和底层的MILS测试真正挂上钩？
  
  
  

下面我把核心干货提炼出来，供大家参考。

---

一、背景：为什么选这个项目“吃螃蟹”？

丰田在2022年刹车开发中遇到了反复出现的质量问题，于是决定用系统工程的思路彻底整改。他们选了一个典型功能——雷达巡航的Stop & Hold（跟停并保持静止），理由很现实：

• 该功能与大量其他功能交互（EPS、Camera、EPB……）
• 涉及的关联团队非常多
• 使用场景极其宽泛（不同路况、驾驶员行为、天气……）
  
  
  

——这种“牵一发动全身”的特性，恰恰是MBSE最能发挥价值的地方。

---

二、两条腿走路：Top-down + Bottom-up

很多MBSE项目容易陷入“只画顶层用例图，落地全靠脑补”的困境。丰田的做法很务实，同时推进两个方向：

1. Top-down：用例分析 + 生命周期切分

他们不是从现有的软件实现倒推需求，而是从车辆行为视角逐层拆解：

• 先定义基本用例（例如：前车停止 → 本车刹停并保持）
• 然后提取影响因子（如：驾驶员开门、松安全带、坡度、雨雪……）
• 对每个因子，明确期望的车辆响应 + 决策理由（不是只写“应该刹车”，而是写“为什么这样设计”）
  
  
  

最有趣的是，他们尝试了多种用例表达方式，最终发现树形结构 + 时间序列的混合视图最容易被工程师理解——这比死磕标准UML图要智慧得多。

2. Bottom-up：用MILS波形“撬开”遗留架构

为什么需要自底向上？因为现有ECU的很多行为并不是文档写清楚的，而是藏在MILS（模型在环）仿真波形里的。他们做了一件很“笨”但极有效的事：

• 跑出典型场景的MILS输出波形
• 反向解析出ECU内部的状态机逻辑和信号交互
• 把这些“挖掘出来的设计意图”与顶层用例建立追溯链
  
  
  

——这样一来，上层用例不再悬空，底层代码也不再是“黑盒”。

---

三、工具落地：为什么选Cameo（SysML）？

他们对比了多种方案，最终选择Cameo Systems Modeler，原因非常务实：

“不需要写代码就能可视化多层追溯关系”

具体做法是三层分层建模：

[td]

层级	视角	典型内容
Level 1	整车行为	驾驶员操作 → 车辆状态变化（如EPB锁止）
Level 2	ECU间交互	Camera发减速度请求 → Brake ECU执行驱动
Level 3	模块内部	应用层发刹车请求 → PF模块输出执行器驱动

这三层通过Cameo的追溯关系（Traceability）直接串联，从用例一路拖拽到MILS测试用例，甚至到物理接口信号。

---

四、效果与未来方向

已兑现的收益（试算）：

• QA缺陷降低 29%
• 从用例到实现的完整追溯（再也不用“找老王问这个需求对应哪个测试”）
• 测试用例识别变得系统化（不再依赖个人经验）
  
  
  

下一步计划：

• 扩展到其他刹车控制系统
• 将设计信息集中到系统模型中，形成知识库（而非分散在Excel/Word）
• 长远目标：AI辅助设计 + 自动知识抽取（当然这还很远，但方向已定）
  
  
  

---

五、给工程师的几点启发

• 别迷信“纯正向设计” —— 在成熟的汽车行业，遗留代码和MILS波形是宝贵的“逆向需求源”，善用它们。
• 用例分析要“带理由” —— 不只是写“期望行为”，更要写“为什么这样期望”，这能大幅减少后续需求变更时的争论。
• 工具链不必追求大而全 —— Cameo只用了表视图、树视图、追溯视图，已经解决了80%的沟通问题。
• MBSE的ROI可以量化 —— 他们直接拿出了29%的缺陷降低率，这对说服管理层很有力。