聊聊MBD开发流程

作为一个小的知识拓展，这里先给出常见的开发流程（或称为开发方法，Development Methodologies）：

• 瀑布流方法（Waterfall）
• V型方法（V-model）
• 迭代式开发（Iterative and incremental development, IID）
• 螺旋开发（Spiral）
• 敏捷开发（Scrum）
• 极限编程（Extreme programming, XP）

据我的了解，很多互联网大厂使用的就是敏捷开发，敏捷开发现在在国内也越来越火热。当然非管理岗位，很少会了解这些开发方法的细节，有兴趣的读者可以去学习一下。

从本质上来讲，MBD可以使用所有的这些流程来开展工作。但实际中，V型开发流程用的最多。简单的检索一下，我们就能得到很多V型开发流程，就像下面这样的：

V型开发流程 - From Internet

有一个问题可能很少有人去考虑过，那就是介绍MBD的时候，为什么大家都不约而同的选择了“V型”？虽然没有很严谨地查证过，但有一个较为可靠的解释是，V型开发流程是来源于ISO26262的4、5、6部分，分别对应系统层、软件层和硬件层，见下图：

Overview of the ISO 26262 series of standards - From ISO26262

“V型”其实是相对于更加传统的瀑布方法（Waterfall Methodology）而言的，MBD也可以使用瀑布方法来开展，瀑布方法一般长这样：

但是瀑布流程并不符合MBD的开发思想，MBD有一个很重要的特征，那就是以模型为中心，反复验证、测试和迭代，这一过程在瀑布流程中是难以实现的。*（MBD的这一特征和敏捷开发有点相似了，感兴趣的读者可以去了解一下） *

2 V型开发流程

MBD的V型流程形式有很多种，包括先后顺序不同，执行内容不同等等。这种形式差异是正常的，实际项目开发中，拥有的资源和开发目标都不相同，是需要这种合理的调整和取舍。我认为ST的这张V型图能较好的描述MBD的开发流程：

V-model with MBD - From ST

MBD V型流程的核心要素有以下几点：

**1. **需求定义

—— Requirements& Specifications

• 项目开始的第1个阶段是需求定义，需求定义要求详细、具体，每一项需要有明确的验证和测试方法。同时需求定义还要求可记录，可追踪，所以要求和模型建立硬联系，即每一项需求有对应的模型来实现。要实现需求的追踪管理，就需要借助工具了（例如MathWorks的SimulinkRequirements工具）。

**2. **系统架构设计

—— System& Architecture Design

**3. **组件设计

—— Components Design

• 上述第2、3点即分层级的建模过程，在这个阶段实现相应的算法，或者状态机，或者其他函数API。这个阶段还可以实施的是MIL（Model In the Loop），即没有生成代码之前验证模型的有效性。
• 如果有足够的资源，还可以在代码生成之前进行RCP（Rapid Control Prototyping）。RCP使用的是原型控制器（非最终形态的产品），一般情况下原型机的性能会高于落地的产品，所以它的验证能力有限，比不上HIL（Hardware In the Loop）。

**4. **自动代码生成

—— Code Generation

**5. **代码测试和验证

—— Code Verification& Validation

• 第4、5点是代码的生成和验证，Verification和Validation的中文都可以翻译成验证，但它们的着重点不同：Verification是过程，Validation是结果，表示是否有效。具体地，Verification就是SIL（Simulation In the Loop）和PIL（ProcessorIn the Loop）；Validation就是SIL和PIL的验证报告。
• 如果算法中需要用到定点数，那么在SIL和PIL之前需要对模型进行定点化。一般来说PIL的验证能力能覆盖SIL，如果控制系统不复杂，可以只进行PIL。

**6. **系统集成测试

—— Integration Testing

• 第6点的系统集成测试即HIL（Hardware In the Loop）测试，关于HIL，以后再开新的文章具体谈一谈。

**7. **验收测试

—— Acceptance Testing

• 最后，HIL测试通过以后，就可以给客户验收了。

关于V型开发流程中会使用到的一些工具和工具链，后续会专门文章介绍。

3 MBD的模型迭代

如果一帆风顺的话，上述V流程只走一遍就可以了。但往往事与愿违，在项目前期很难考虑得非常周全，前期的需求有遗漏或者错误，就需要及时修正，我们知道越在后期，修改前期错误的成本就越大。

这时就能体现出MBD相比于手写代码的巨大优势。因为MBD是围绕模型展开的，所以修复遗漏和错误也是通过模型修改来实现的。由于模型的图形化和结构化，使得能很方便、直观地进行需求更新和算法修改，而不用一行一行的检查代码。越是项目规模大，越能体现这种优势。

为了更好的说明MBD的模型迭代，这里把V型流程分为两个阶段：

• 代码生成前——建模阶段；
• 代码生成后——验证阶段。

那么MBD模型的迭代是如下进行的：

MBD模型迭代 - From autoMBD

从上图可以看到，算法迭代和需求的更新都是是围绕着模型展开的，而将需求定义、建模和测试验证串联起来的是需求追踪。这样就在模型和需求之间打通了回路，形成了良好的反馈纠错和正向促进。

4 资源更新

资源中更新了ISO26262的英文文档（2018版part 1~12）和中文文档（2011版），聊天界面点击MBD->资源即可获得。