|
|
楼主 |
发表于 2026-5-20 09:45:37
|
显示全部楼层
# 完成 MIL 仿真，对控制逻辑和对象模型进行初步验证
## 一、AI 构建激励源与测试场景
在模型搭建完成后，工程师往往需要构建模型应用场景，以进行 MIL 测试。
测试激励源和测试场景是可以由 AI 构建的。
其方式可以是自然语言生成、脚本生成、边界工况组合生成，也可以是基于历史测试数据的自动扩展。
在传统 MBD 工程中，MIL、SIL、PIL、HIL 任何一环的推进都离不开验证。
尽管存在自动化工具，工程师仍然需要一定的跨领域能力，去构建对应不同层级的测试例。
而在 AI 介入的工程中，验证工作的重点可以前移。
这里的“前移”并不是指后续 SIL、PIL、HIL 不再需要验证。
而是指：
> 在 MIL 阶段尽可能提前构建测试场景、输入输出基准和功能判据，为后续 SIL、PIL、HIL 提供统一的验证标准。
也就是说，MIL 不能替代 SIL、PIL、HIL。
MIL 能够提前固化的是功能逻辑、对象模型和测试基准。
SIL 仍然需要验证 C 代码和模型语义是否一致。
PIL 仍然需要验证代码在目标处理器、编译器和运行环境下是否一致。
HIL 仍然需要验证实时性、IO 接口、采样周期、量化误差、板级通信和闭环稳定性。
AI 的作用，是让同一套测试场景能够被快速迁移到不同平台。
```text
MIL 测试场景
↓
形成标准输入输出数据
↓
迁移到 C 代码测试
↓
迁移到 HDL 测试
↓
迁移到板级 IO 测试
↓
对标同一套 golden data
```
通过这种方式，AI 可以基于同一套测试数据，生成不同平台的测试例，大幅提高后续工程落地效率。
---
## 二、一切的起点：标准 MIL 测试例构建
MIL 是整个 AI + MBD 流程中最重要的起点。
人工需要在 MIL 环节开始时，对 AI 生成的模型及测试例进行一次判断。
这是工程师最基本的能力。
判断的目的，不是简单看模型能不能跑通。
而是确认：
```text
顶层设计是否符合实际工程场景
模型结构是否符合需求
输入输出边界是否清晰
控制逻辑是否正确
对象模型是否具备基本机理
测试结果是否满足最终验收指标
```
测试的执行、分析和自迭代工作，可以大量交给 AI。
但是，第一轮测试结果的判断，以及后续迭代完成的条件，必须由工程师在最初阶段给出。
换句话说，工程师需要把自己期望的“宏伟蓝图”传递给 AI。
AI 很擅长执行。
AI 也很擅长根据已有模型做测试、补脚本、分析曲线、生成报告。
但是 AI 判断的基准，大部分来自于：
> “结果是否符合当前模型的运行逻辑。”
这并不等于：
> “模型的物理机理一定正确。”
如果模型在搭建阶段缺少关键机理、关键参数或关键边界条件，那么 AI 仍然可能判断测试通过。
因为在 AI 看来，执行结果与当前模型描述是自洽的。
但“模型自洽”不等于“模型正确”。
这也是 AI 参与 MBD 工程时最容易出现的问题。
AI 能够判断一个模型是否按照它已有的结构正常运行，却不能天然判断这个模型是否符合真实对象的物理机理。
因此，一个成功的 MIL 构建，本质上是将 AI 的黑盒行为约束到固定的、明确的、可追溯的工程场景中。
---
## 三、测试数据的继承
在 MIL 阶段，经过 AI 在线测试生成的结果，一旦被人工认定合理且标准，就需要将该结果作为后续 SIL、PIL、HIL 的预期结果保存下来。
这套数据可以称为 golden data。
但是 golden data 不能只理解成输出曲线。
它至少应当包括：
```text
测试输入
模型参数
初始状态
采样周期
求解器配置
输出结果
版本信息
允许误差范围
```
如果只保存输出结果，而没有保存对应的测试条件，那么后续阶段很容易出现结果对不上的情况。
例如：
```text
步长不一致
初始状态不一致
solver 不一致
参数版本不一致
随机激励源不一致
浮点 / 定点误差不一致
IO 延迟没有对齐
```
这些问题都会导致后续 SIL、PIL、HIL 的结果与 MIL 对不上。
此时问题未必出在代码生成，也未必出在硬件实现，而可能只是测试基准没有被完整继承。
所以，MIL 阶段形成的 golden data，不应该只是一个结果文件。
它应该是一套完整的测试资产。
这套测试资产本身，将作为后续 MBD 开发过程中任何设计的测试例。
它可以被调用为：
```text
模型测试例
C 代码测试例
HDL 代码测试例
板级 IO 收发测试例
闭环 HIL 测试例
```
在后续阶段中，AI 可以基于固定测试例数据，大量执行如下动作：
```text
测试源构建
↓
平台封装
↓
对标 golden data
↓
误差分析
↓
自迭代修正
```
这样一来，AI 每次执行生成动作之后，都可以基于同一套标准数据进行自我验证。
---
## 四、golden data 的本质
需要强调的是，MIL 阶段形成的 golden data，并不代表物理世界的绝对真理。
它代表的是：
> 在当前工程需求、模型参数、测试条件和验收标准下，经过人工确认后的工程认可基准。
这一点非常重要。
因为 AI 从原理上只能提高结果的置信度，而不能保证结果一定正确。
尤其在涉及 AI 跨平台生成时，不同人给出的提示词不同，不同工具链生成的结果不同，不同编译器和硬件平台的执行细节也不同。
从最终结果上看，它们应该殊途同归。
但是从中间实现上看，它们可能完全不同。
这就会带来一个问题：
> AI 生成的代码、测试脚本和封装逻辑，往往可读性较差，不便于人工逐行进行机理判断。
因此，人工不应该把所有精力放在逐行阅读 AI 生成物上。
更合理的方式是：
> 将涉及 AI 的流程视作黑盒，对结果进行判断。
而 golden data，就是判断这个黑盒是否可信的标准。
只要输入条件一致，输出结果能够在允许误差范围内对齐，那么当前生成结果就可以被认为满足该阶段的工程预期。
---
## 五、AI 参与下的 MBD 可追溯性
传统 MBD 流程中的可追溯性，来自于模型、代码、测试和报告之间的人工管理。
而 AI 参与之后，可追溯性的核心应当转移到测试基准上。
也就是说，AI 可以生成不同层级的模型、代码和测试脚本。
但所有结果都必须回到同一套 golden data 上进行判断。
```text
MIL：确认模型和功能逻辑
↓
SIL：确认 C 代码与模型一致
↓
PIL：确认目标处理器执行结果一致
↓
HIL：确认硬件 IO、实时性和闭环行为一致
```
每一环都可以由 AI 辅助生成测试、执行测试、分析误差和修正问题。
但每一环的判断标准，都必须来源于 MIL 阶段经过人工确认的测试资产。
因此，在 AI 参与的 MBD 流程中，人工的角色并没有消失。
人工的角色从“逐个手工搭模型、写代码、造测试例”，转变为：
```text
定义需求
约束边界
判断机理
确认基准
设置误差
管理追溯
```
AI 负责提高效率。
工程师负责保证方向。
这才是 AI 参与 MBD、HIL 工程时更合理的分工。
|
|
|MBD全栈技术学校|苏ICP备2025212294号-1|Hyowinner校长B站首页|手机版|小黑屋|Hyowinner的MBD技术论坛
发表于 2026-5-13 10:51:25
