第2章：基于模型设计（MBD）基础：MBD概念、V流程开发模式、Simulink/Stateflow工具链简介

2.1 什么是基于模型设计？

先说说我个人的理解。基于模型设计，简称MBD，说白了就是用图形化的模型来代替手写代码，完成控制算法的开发。

你想想看，传统的开发方式是什么样的？

• 先在纸上画流程图
• 然后写C代码
• 编译、烧录、测试
• 发现问题，改代码，再编译...

这个过程，我当年刚入行时深有体会。有一次做一个PID控制器的项目，代码写了三千多行，结果测试时发现一个积分饱和的问题。改一处代码，牵连了七八个函数。折腾了两周才搞定。

MBD的思路完全不同。它把整个控制系统抽象成一个模型。这个模型就是你的设计本身。你可以直接在这个模型上仿真、调试、生成代码。

2.2 V流程开发模式

说到MBD，就绕不开V流程。这是汽车行业最经典的开发模式。我参与过的几个量产项目，都是按这个流程走的。

V流程长什么样？左边是设计阶段，右边是验证阶段。从上到下，再从下到上，形成一个V字。

阶段	左侧（设计）	右侧（验证）
系统级	需求分析	系统测试
子系统级	架构设计	集成测试
组件级	详细设计	单元测试
实现级	代码生成	代码审查

嗯，这里要注意一点。V流程不是简单的「先设计再测试」。它强调每个设计阶段都有对应的验证手段。

举个例子。我在做ACC自适应巡航项目时，需求阶段就定义了「跟车距离误差不超过2米」。这个需求在系统测试阶段会被严格验证。如果等到最后才发现问题，那返工成本就太高了。

2.3 Simulink/Stateflow工具链简介

讲工具之前，我先说说为什么选Simulink。市面上做MBD的工具不少，但Simulink在汽车和航空航天领域，基本上是事实标准。

我见过很多团队尝试用其他工具，最后都转回来了。为什么？因为生态太成熟了。

2.3.1 Simulink：连续与离散系统的建模

Simulink的核心能力是搭建动态系统的模型。你可以用拖拽的方式，把积分器、传递函数、PID控制器这些模块连起来。

举个例子，一个简单的低通滤波器：

% 在Simulink中搭建一阶低通滤波器
% 传递函数：1/(tau*s + 1)
% tau = 0.1

模块：
  1. 输入信号源（阶跃信号）
  2. 传递函数模块（1/(0.1s+1)）
  3. 示波器（查看输出）

我曾经带过一个实习生，他花了两周手写滤波器的C代码，调试时发现相位滞后算错了。我用Simulink搭了个模型，十分钟就验证了算法正确性。这就是工具的力量。

2.3.2 Stateflow：状态机的建模

Stateflow是Simulink的兄弟，专门用来做状态机。说白了，就是处理「什么时候该做什么事」这类逻辑。

比如自动驾驶中的车道保持功能：

• 状态1：正常行驶
• 状态2：检测到偏离
• 状态3：纠正转向
• 状态4：回到车道中心

用Stateflow画出来，每个状态是一个框，状态之间的转换用箭头连接。清晰直观，比写switch-case语句好理解多了。

2.3.3 工具链的完整流程

Simulink/Stateflow不是孤立的工具。它们和整个开发流程紧密配合：

1. 建模阶段：在Simulink中搭建控制算法模型
2. 仿真阶段：用不同工况测试模型行为
3. 代码生成阶段：用Embedded Coder生成C代码
4. 验证阶段：将生成的代码与模型进行等价性测试
5. 集成阶段：将代码部署到目标硬件

你想想看，整个过程从模型到代码，几乎不需要手动写一行C代码。这就是MBD的魅力所在。

2.4 为什么MBD适合自动驾驶？

自动驾驶系统有多复杂？传感器融合、路径规划、控制执行，每个模块都涉及大量算法。如果用传统方式开发，光文档就能堆满一个书架。

MBD有几个天然优势：

• 可视化：算法逻辑一目了然，评审时大家都能看懂
• 可仿真：在实车测试前，就能发现大部分问题
• 可复用：模型可以在不同项目间迁移
• 可追溯：从需求到代码，每个环节都有对应关系

我记得有一次做紧急制动系统，客户要求响应时间小于200毫秒。我们在模型里仿真了各种工况，发现有一个场景下响应慢了50毫秒。如果等到实车测试才发现，那改硬件就来不及了。

2.5 本章小结

这一章我们聊了MBD的基本概念、V流程的开发模式，以及Simulink/Stateflow工具链的用法。说白了，就是用模型代替代码，用仿真代替猜测，用工具链保证质量。

下一章，我会带大家动手搭建第一个Simulink模型。到时候咱们边做边聊，你会发现，其实没那么难。

---

公众号:蓝海资料掘金营，微信deep3321