面向实时仿真 基于模型的设计

核心要点

• 基于模型的设计只有在模型能够贯穿设计、代码生成和HIL测试的整个过程并保持可执行性时，才能发挥最佳效果，而不能仅止步于概念设计阶段。
• 在为可靠的台架测试做准备时，时间预算、接口协议和需求可追溯性比模型细节更为重要。
• 传统的汽车开发模式往往将集成风险推迟到后期，而规范的模型划分和可追溯的验证则能让故障在更早阶段显现。

当您的仿真 成为在HIL中执行的同一资产时，基于模型的设计可降低验证风险。

当模型停留在早期设计阶段，无法发展为可重复使用的测试资产时，团队就会浪费时间。道路交通事故导致 20,400人死亡 ，这使得验证工作始终与公共安全息息相关，而非仅仅取决于流程偏好。您需要一套工作流，确保在代码进入测试环境之前，时序、接口和需求依据始终清晰可见。

基于模型的设计将仿真 转化为可执行的测试资产

基于模型 仿真 您的被控对象和控制模型将成为可执行的测试资产，从早期设计阶段到HIL验证阶段始终发挥作用。其价值在于有条不紊地复用。由于每个阶段都会对相同的行为进行验证，您将能更早地发现接口和时序故障。

电机控制团队能够快速实现这种控制方案。控制器模型最初以控制概念的形式呈现，随后与被控对象模型结合进行闭环调谐，接着生成代码，最后在HIL测试台上进行带故障注入的运行。您无需在每个阶段重新定义设计意图，而是不断优化一个可执行的行为描述。

这种转变至关重要，因为每次交接都会引入解释误差。如果电流限制器、传感器标定和状态机时序已经包含在模型中，那么在硬件到位之前，您就能发现其中的不一致之处。此外，由于模型已经明确展示了正常和异常的运行状态，而非将这些信息埋藏在独立的文档中，您还能编写出更精准的测试用例。

V模型将控制设计与验证证据联系起来

在汽车工程领域，V型模型之所以重要，是因为它将每项设计决策与相应的验证活动紧密关联。当每个需求、模型元素和测试用例都保持相互关联时，基于模型的设计便契合了这种结构。这种关联使验证不再只是一个后期检查点，而是形成了一条可供审查的证据链。

电池管理要求便是一个典型的例子。温度降额规则最初作为系统需求出现在V模型的左侧，随后作为逻辑规则出现在控制器模型中，最后又以具有明确通过阈值的MIL、SIL和HIL测试形式出现在V模型的右侧。由于整个路径始终清晰可见，验证工程师无需猜测测试结果的含义。

“基于仿真 您的过程和控制模型将成为可执行的测试资产，从早期设计阶段到HIL验证阶段都能持续发挥作用。”

V模型本身并不能纠正不规范的建模习惯。只有当您的模型足够具体，足以在设计评审中支持论证时，它才真正发挥作用。这就是为什么验证工程师对可追溯性的重视程度，不亚于控制器工程师对控制性能的重视。

在进行模型细化之前，先从闭环用例入手

闭环用例应优先于模型细化，因为它们能告诉你哪些行为在时间压力下必须运行正确。一个缺乏测试目标的详细模型只会徒劳无功。你会花费数周时间打磨那些根本不会影响你真正需要解答的验证问题的动态特性。

一个电动助力转向系统很好地展示了这一流程。首先是泊车辅助、车道保持修正、扭矩叠加以及传感器故障恢复。这些用例定义了模型必须支持的扭矩带宽、转向齿条动态特性以及故障注入。被控对象只需具备足够的细节，以展现控制器在这些条件下的行为即可。

这种方法确保了该模型在HIL测试中的实用性。如果下一个基准目标是在20毫秒内完成故障恢复，那么你就应重点优化影响恢复时序的关键部分，而将次要细节留待后续处理。通过将工作范围限定在需要完成的闭环任务上，既能控制执行成本，也能使验证结果更具可信度。

HIL 工作流程以时序预算为起点，而非功能框图

HIL 工作流程应从时序预算开始，因为实时执行往往在延迟问题上先于视觉模型结构问题而失败。即使您的方块图看起来很整洁，仍可能无法满足时限要求。时序预算迫使您在模型进入目标系统之前，就必须确定采样时间、I/O 延迟和计算限制。

牵引逆变器测试台将这一问题暴露无遗。控制环路以 50 微秒为周期运行，被控对象的阶跃响应以 1 微秒为周期，而 I/O 更新则以另一个固定间隔进行。如果信号调理、通信和数据记录占用了过多时间，即使控制逻辑正确，测试结果也无法令人信服。

正因如此，优秀的HIL团队会像管理硬件资源一样规划时间。你会更早地划分任务，减少不必要的日志记录，并将低效的监控逻辑与高效的循环逻辑分离。如果将这些决策拖到集成后期才做，超时现象就会显得毫无规律，调试工作也会演变成在工具、硬件和模型结构之间漫无目的的搜索。

Simulink 模型在进行实时部署前需要明确的接口

当接口在执行开始前明确、固定且可测试时，Simulink 模型就能顺利部署到实时目标上。接口规范比模型大小更为重要。如果您的 I/O、单位、初始状态和故障标志存在歧义，模型虽然能编译通过，但在首次有意义的 HIL 测试中仍会失败。

制动控制器便是常见的例子。该逻辑在桌面运行时看似合理，但一旦车轮速度标度与 I/O 映射不符，或者启动状态假设了一个在测试台上根本不存在的传感器值，部署就会失败。使用 OPAL-RT 的团队通常会通过在模型编译为目标版本之前先显示接口契约，从而更早地解决这个问题。

• 为每个输入和输出路径设置采样时间。
• 在代码生成之前锁定单元、缩放比例和数据类型。
• 定义工厂和控制器模块的启动状态。
• 将故障标志作为可测试的输入项公开，而非隐藏的逻辑。
• 文档 I/O 映射，其中模型名称与测试台信号相匹配。

这份检查清单虽简短，却能避免许多后期出现的意外。您正在将模型打造成实验室级资产，而非桌面仿真。一旦这些接口稳定下来，部署就变成了一个验证步骤，而非一场调试马拉松。

“基于模型的设计与传统的文档驱动开发之间的主要区别在于，集成风险何时显现。”

基于模型的系统工程可在测试过程中确保需求可追溯

基于模型的系统工程能够确保测试的可靠性，因为它保持了需求意图、模型行为与测试证据之间的联系。验证工程师需要这一链条来解释结果为何通过或失败。如果没有这一链条，测试执行虽然会生成日志，却无法提供有说服力的证据。

充电控制要求很好地说明了这一点。该要求规定了热降额期间的电流限制，系统模型将该限制与信号和工作模式相关联，而HIL测试则会同时检查该限制值以及温度故障后的过渡时间。当测试失败时，您可以追溯问题根源至逻辑、标定或要求表述，而非争论责任归属。

这就是基于模型的设计与基于模型的系统工程的交汇点。前者为您提供可执行的行为，后者则确保该行为与系统意图保持一致。如果您是一名验证工程师，这种结合将节省审查时间，因为每次测试失败都已附带了相应的背景、假设和验收边界。

传统开发方式会将集成风险隐藏到汽车测试的后期阶段

基于模型的设计与传统的文档驱动开发之间的主要区别在于，集成风险何时显现。基于模型的设计能在您仍可快速重新运行模型时，就揭示出行为、时序和接口方面的问题。而传统的开发流程则将许多此类问题推迟到台架和车辆测试阶段，届时每次修复都需要耗费更多时间。

传统的交接流程体现了这种模式。需求集中在一个工具中，控制逻辑则存在于另一个工具中，而HIL团队收到的只是编译好的软件，对相关假设的了解十分有限。当出现扭矩仲裁故障时，团队必须同时查阅文档、代码和台架配置。软件质量低下使美国在2022年至少损失了 2.41万亿美元，这充分说明了当集成反馈在设计交接后才出现时，缺陷发现过晚将带来多么高昂的代价。

你无需在文档和模型之间做出选择。两者都不可或缺。更好的做法是让模型承载可执行的意图，然后利用文档来界定需求、假设和发布依据。这种顺序能让汽车测试始终聚焦于验证，而非重建。

模型划分不当会破坏实时目标的确定性

模型划分不当会破坏确定性，因为一旦快速任务和慢速任务共享了错误的执行路径，它们就会相互干扰。实时系统需要将被控对象细节、控制环路、通信和日志记录明确分离。如果这种分离不够彻底，超时现象就会隐藏在正常的测试活动中，导致测试结果失去可信度。

在电力电子实验台上，这种情况往往最先显现出来。开关模型应运行在快速执行路径上，而监督控制、用户交互和文件日志记录则应运行在较慢的路径上。如果将它们全部放在同一个分区中，一个看似无害的日志记录更改就可能导致延迟发生足够大的变化，从而破坏当前控制环路的结果。工程师们随后便会追查一个控制问题，而实际上这根本是一个调度问题。

优秀的基于模型的设计最终体现在严谨的模块划分上，因为确定性是验证证据的一部分，而非技术注脚。坚持这一原则的团队通常能从OPAL-RT中获得更大价值，因为该仿真器从一开始就接收到了符合时序、接口和测试意图的模型结构。这正是让您在完成调试工作后对测试台结果充满信心的原因。