1. V模型与Simulink模型化开发总览

在汽车电子、航空机载、工业控制等安全关键领域，控制器的开发早已不是"写代码—烧录—试车"的线性过程。随着功能安全标准（如 ISO 26262、DO-178C）对可追溯性和验证充分性的要求不断提高，V模型成为主流的开发流程框架。而 Simulink 作为 MathWorks 工具链的核心，承担了 V 模型左侧"设计—建模—验证"与右侧"集成—测试—确认"之间最关键的桥梁角色。本节先建立整体地图：V 模型左右两侧如何对应、模型化开发处在什么位置、Simulink 为什么能成为核心工具链，以及本课程最终要交付什么。

V模型左右两侧的对应关系

V 模型并不是"先下降再上升"的两条独立路径，而是一组逐层分解与逐层验证的镜像对应。左侧自上而下是需求分解：整车级需求 → 系统需求 → 子系统/软件需求 → 软件架构 → 详细设计（模型/代码）。右侧自下而上是验证集成：单元测试 → 软件集成测试 → 系统集成测试 → 系统测试 → 整车/验收测试。关键在于：左侧每一层的设计产物，都必须在右侧有明确的测试层级与之对应，且测试用例要能追溯到左侧的需求条目。

以本课程的项目为例，左侧"软件需求"层可能写着"当车速大于 30 km/h 且驾驶员踩下制动踏板时，制动灯应在 100 ms 内点亮"；那么右侧对应的"软件集成测试"就必须构造车速、踏板信号，测量制动灯输出响应时间，并判定是否 ≤100 ms。这种"需求—测试"的镜像关系，正是 V 模型区别于瀑布模型的核心价值：验证不是最后一步，而是从需求阶段就被规划好的。

模型化开发在V模型中的定位

传统 V 模型左侧的"详细设计"往往以文档和伪代码形式存在，右侧测试则依赖手工编写的 C 代码。这种模式下，设计与测试之间存在语义鸿沟：文档描述的控制逻辑，到了代码里可能因为手写误差而变形。模型化开发（Model-Based Development, MBD）把"详细设计"从文档升级为可执行的图形化模型——Simulink 模型本身就是设计产物，同时又能直接仿真、自动生成代码、自动生成测试框架。

这就带来一个根本性变化：V 模型左侧的"设计"和右侧的"验证"共用同一个模型资产。左侧用模型表达控制算法，右侧用同一个模型做模型在环（MIL）、软件在环（SIL）、处理器在环（PIL）甚至硬件在环（HIL）测试。模型成为贯穿 V 模型全生命周期的"单一事实源"（Single Source of Truth）。

Simulink作为核心工具链的工程价值

Simulink 之所以能承担这个角色，不是因为它"能画框图"，而是因为它把建模、仿真、代码生成、测试、追溯串成了一条可自动化的工具链。具体来说：

• 图形化建模与仿真：用模块和信号线表达连续/离散/混合系统，支持定步长与变步长求解器，可在秒级完成控制逻辑的时域验证。
• 自动代码生成：Embedded Coder 可从模型直接生成符合 MISRA-C 等规范的 C 代码，消除手写代码引入的偏差，并支持 ASAP2/A2L 标定文件生成。
• 测试自动化：Simulink Test 支持基于需求的测试用例管理、基线测试、回退测试；Simulink Coverage 可统计模型覆盖率（决策覆盖、条件覆盖、MC/DC）。
• 需求追溯：Requirements Toolbox 可将需求条目与模型元素、测试用例双向链接，满足功能安全对追溯性的强制要求。
• 与 V 模型右侧衔接：同一模型可导出为 SIL/HIL 可用的代码或 FMU，实现从桌面仿真到台架测试的平滑过渡。

换句话说，Simulink 的工程价值不在于"画得好看"，而在于把 V 模型左右两侧的工程活动用同一套资产、同一套工具、同一套追溯关系连接起来，让验证从"事后补救"变成"设计的一部分"。

课程项目背景与最终交付物

本课程以一个典型的车身控制场景为项目背景：车门控制模块（Door Control Module, DCM）。该模块需要根据车门开关、车速、钥匙状态等输入，控制车门锁执行器、车窗电机和车内照明。项目需求以简化的需求规格形式给出，包含约 12 条功能需求，覆盖正常操作、防夹保护、车速联锁和故障降级四类场景。

课程将沿着 V 模型左侧向下：从需求分析开始，建立 Simulink 模型，划分软件架构，完成详细设计；再沿右侧向上：用同一模型做 MIL 测试、SIL 测试，最终在 HIL 台架上验证。整个过程中，所有需求条目、模型元素、测试用例都通过追溯关系连接。