汽车行业Simulink国产替代：局部突破与场景化替代的务实路径

1. 从一篇爆文说起为什么“国产替代”这个问题值得认真聊上一篇聊汽车行业为什么离不开 Simulink 的内容发出去之后后台收到最多的留言不是技术细节的追问而是一个更尖锐的问题既然 Simulink 这么重要那汽车行业到底有没有国产替代的可能性这个问题问得比“为什么离不开”更狠因为它直接指向了工具链的命脉。我先把结论摆在前面在可预见的周期内汽车行业不会出现对 Simulink 的“整体替代”但会出现大量“局部替代”和“场景化替代”。这两句话不矛盾前者说的是生态后者说的是单点工具。要理解这个判断得先搞清楚 Simulink 在汽车行业里到底扮演什么角色。很多人以为它就是个画框图的仿真软件这个认知偏差非常大。Simulink 在整车开发流程里承担的是模型在环MIL、软件在环SIL、硬件在环HIL三级验证的中间载体同时还是 AUTOSAR 软件组件SWC的行为建模入口更是 ISO 26262 功能安全开发中“模型级验证证据”的主要来源。换句话说它不是一个孤立的工具而是一条从需求到代码、从仿真到标定、从单元测试到整车集成的主干道。这条主干道上跑着的东西太多了Stateflow 的状态机、Simscape 的物理建模、Embedded Coder 的代码生成、Simulink Test 的测试管理、Requirements Toolbox 的需求追溯、Polyspace 的静态分析。你换掉其中任何一个环节都要面对上下游接口的重新对齐。这就是为什么“替代 Simulink”这件事本质上不是替换一个软件而是替换一套方法论和协作契约。但话说回来汽车行业从来不是一个拒绝变化的行业它只是变化得慢。慢不代表没有机会。我这两年接触了不少做国产工具链的团队也参与过几个主机厂和 Tier1 的替代方案评估下面把我看到的真实情况拆开讲。2. 先看清 Simulink 的护城河到底在哪几层2.1 第一层护城河图形化建模语言本身的表达力Simulink 的核心不是界面而是它那套基于时间步的因果建模语义。你拖一个 Gain 模块、一个 Integrator、一个 Saturation连起来之后仿真器知道怎么按固定步长或变步长去解这个微分方程组。这套语义看起来简单但要做到数值稳定、代数环检测、过零检测、变步长求解器切换背后是几十年的数值计算积累。国产工具如果只是做一个“能画框图”的编辑器那第一层都过不了。我见过一些早期国产仿真工具画出来的模型在简单场景下能跑一旦引入代数环或者刚性系统求解器直接发散。这不是界面问题是求解器内核的问题。Simulink 默认的 ode45、ode23t、ode15s 这些求解器以及针对刚性系统的隐式算法是它最硬的那块骨头。2.2 第二层护城河代码生成与 AUTOSAR 的绑定深度汽车行业用 Simulink 的终极目的很多时候不是为了仿真而是为了生成可以刷进 ECU 的 C 代码。Embedded Coder 生成的代码要满足 MISRA C 规范要能配置成 AUTOSAR SWC 的 Runnable要能和 ECU 抽象层ECUC的配置参数对齐。这套链路里Simulink 和 AUTOSAR 工具链比如 DaVinci、EB tresos之间的接口是经过大量项目验证的。我参与过一个项目尝试用某国产建模工具生成 AUTOSAR SWC 的 ARXML 描述文件结果在 Runnable 的触发周期配置上和 ECUC 模块对不上最后不得不手工改 ARXML。这种“最后一公里”的摩擦在实验室里看不出问题一到集成阶段就暴露。代码生成不是把模型翻译成 C 就完事了它要生成符合 AUTOSAR 元模型约束的完整描述这才是难点。2.3 第三层护城河ISO 26262 的证据链功能安全对工具链的要求非常具体。ISO 26262 第 6 部分和第 8 部分对软件工具的信心度Tool Confidence Level有明确要求。Simulink 和 Embedded Coder 有 TÜV SÜD 的认证证书这意味着在安全相关开发中你可以直接引用它的认证材料来支撑你的工具置信度论证。国产工具如果没有这个认证主机厂的安全经理那一关就过不去。这不是技术问题是合规成本问题。做认证要花时间、花钱、花人力而且认证不是一劳永逸的工具版本升级后还要重新评估。很多国产工具团队规模不大光靠融资很难撑到认证完成。但反过来说一旦有团队愿意啃这块硬骨头这就是一个非常高的壁垒。2.4 第四层护城河模型库与行业 Know-how 的沉淀Simulink 有 Powertrain Blockset、Vehicle Dynamics Blockset、Battery Pack Modeling 这些垂直行业库。这些库不是简单的模块集合而是把行业里成熟的建模方法固化了。比如电池包的等效电路模型里面已经处理好了 SOC 估算、热耦合、老化这些细节。国产工具要从零建这些库需要大量的实测数据和标定经验。我认识一个做电池建模的团队他们花了三年时间才把一套电池等效电路模型做到和 Simulink 自带库接近的精度。这还只是一个库。汽车行业有动力、底盘、车身、热管理、ADAS 这么多域每个域都有自己的建模 Know-how。护城河不是一天挖成的也不是一天能填平的。3. 国产替代的真实机会不是全面开战而是单点突破3.1 机会一Modelica 路线的多领域物理建模Simulink 擅长的是控制逻辑和信号流但在多领域物理建模机械、液压、热、电耦合上Modelica 路线其实更有优势。Modelica 是非因果建模你不需要指定信号流向只需要写方程求解器自己去解。这在做整车热管理、液压系统、多体动力学的时候比 Simulink 的信号流方式更自然。国内有几个团队在做 Modelica 编译器和仿真器比如苏州同元、远算科技。他们的工具在航空、能源领域已经有落地案例。汽车行业里热管理系统的建模是一个很好的切入点因为热管理系统的物理耦合强用 Modelica 描述比用 Simulink 搭信号流更简洁。我试过用 MWorks 搭一个电池冷却回路和 Simulink 的 Simscape 方案对比在建模效率上确实有优势但在和 AUTOSAR 代码生成的衔接上还有距离。提示Modelica 路线适合做“被控对象”的建模也就是 Plant Model。如果你的目标是生成 ECU 代码Modelica 目前还不是主流选择。但如果你做的是 HIL 测试台架的实时模型Modelica 编译出来的 C 代码是可以用的。3.2 机会二特定场景的仿真工具替代不是所有仿真都需要 Simulink。比如四旋翼的滑模控制仿真、LQR 控制器设计、弱磁控制仿真这些场景里 Python 生态NumPy、SciPy、Control加上一些可视化库完全可以覆盖。我见过一个做电机控制的团队他们用 Python 做算法原型用 Simulink 做最终验证两边并行。后来他们把算法原型的部分完全迁移到了 Python只在交付给客户的时候才转成 Simulink 模型。这种“外围替代”是国产工具最容易切入的地方。先替代那些不涉及代码生成、不涉及功能安全、不涉及 AUTOSAR 的仿真场景比如算法预研、控制参数整定、系统级性能评估。这些场景对工具链的绑定没那么深替换成本低用户也愿意尝试。3.3 机会三测试与验证环节的工具链Simulink Test 做测试管理Simulink Coverage 做覆盖率分析这些工具的功能相对独立替代起来比核心建模环境容易。国内有一些团队在做模型静态检查、模型差异对比、测试用例自动生成。这些工具可以挂在 Simulink 上作为插件运行也可以独立运行。我特别看好模型质量检查这个方向。Simulink 模型的可读性、可维护性一直是行业痛点怎么整理 Simulink 模型是一个高频问题。如果有一个国产工具能自动检查模型命名规范、信号线布局、子系统划分、注释完整性并且给出修复建议这个工具是有市场的。它不替代 Simulink但它让 Simulink 用起来更舒服。3.4 机会四联合仿真的中间层CarSim 和 Simulink 联合仿真、Adams 和 Simulink 联合仿真这些场景里 Simulink 扮演的是“控制算法宿主”的角色。联合仿真的接口协议比如 FMI/FMU是开放的这意味着国产工具只要支持 FMI 标准就可以接入这个生态。我见过一个国产车辆动力学仿真工具它导出 FMU然后在 Simulink 里作为被控对象运行效果和 CarSim 方案接近。这个路线的聪明之处在于不正面挑战 Simulink 的宿主地位而是把自己变成 Simulink 生态里的一个可插拔组件。用户不需要放弃 Simulink只需要在需要的时候换掉某个环节。这种“寄生式替代”在商业上更容易成立。4. 替代路上绕不开的几道硬坎4.1 数值求解器的精度与鲁棒性我前面提过求解器是硬骨头这里展开说。Simulink 的变步长求解器在处理过零点、不连续、刚性系统的时候有一套成熟的策略。国产工具如果直接用显式欧拉或者四阶龙格库塔在简单模型上没问题但遇到刚性系统比如包含快速动态和慢速动态耦合的模型就会需要极小的步长仿真时间爆炸。有个做储能控制仿真的朋友跟我吐槽他们用某国产工具跑双向储能控制模型仿真 10 秒的工况花了 40 分钟换成 Simulink 只要 2 分钟。差距就在求解器。求解器不是一朝一夕能追上的它需要大量的数值实验和调参经验。但好消息是开源社区有 SUNDIALS、CVODE 这些成熟的求解器库国产工具可以基于它们做封装至少把基础能力补齐。4.2 AUTOSAR 元模型的完整支持AUTOSAR 的元模型非常庞大ECUC 模块、NVM 模块、CAN 协议栈、网络管理每个模块都有自己的参数集和约束。Simulink 和 AUTOSAR 工具链的集成是经过大量项目打磨的。国产建模工具要支持 AUTOSAR不是生成一个 ARXML 文件就完事了它要能正确处理引用关系、变体管理、参数依赖。我见过一个团队尝试用国产工具做 AUTOSAR NVM 读写模块的建模结果在 NvMBlockDescriptor 的配置上和 ECUC 对不上导致生成的代码在刷写后无法正确读写 NVM。这种问题在实验室里很难发现只有到了台架测试才暴露。AUTOSAR 的坑大部分不在建模本身而在配置参数的语义对齐上。4.3 功能安全认证的时间与资金成本ISO 26262 的认证不是一次性的。工具认证通常遵循“工具置信度”的评估流程需要提供工具开发过程中的安全论证、工具使用说明、已知缺陷列表、版本变更影响分析。一个工具从立项到拿到 TÜV 认证通常需要 2 到 3 年费用在数百万到千万级别。对于创业团队来说这个投入是巨大的。但如果不做认证就只能用在非安全相关QM的模块上。汽车行业里 QM 模块的比例其实不低比如信息娱乐、车身舒适控制这些模块对功能安全的要求没那么高。国产工具可以先从 QM 场景切入积累项目案例再逐步向安全相关场景渗透。4.4 用户习惯与生态迁移成本这一点最容易被低估。一个工程师用了十年 Simulink他的建模习惯、快捷键、调试方法都是围绕 Simulink 建立的。你让他换一个工具即使新工具功能不差他也会觉得别扭。更不用说大量的存量模型、脚本、自定义库都是 Simulink 格式的。我参与过一次工具替换评估技术团队评估下来觉得某国产工具在功能上可以覆盖 70% 的日常需求但最后没有替换。原因很简单存量模型的迁移成本太高而且迁移过程中引入的风险无法接受。这不是技术问题是工程管理问题。替代方案必须提供平滑的迁移路径比如支持导入 Simulink 模型、支持 MATLAB 脚本的兼容层否则很难推动。5. 如果真要动手一条务实的替代路线图5.1 第一步从“外围工具”切入不碰核心建模如果你是一个国产工具团队我建议第一步不要做建模环境而是做围绕 Simulink 的辅助工具。比如模型检查、模型对比、测试用例生成、覆盖率分析、文档自动生成。这些工具可以以插件形式挂在 Simulink 上用户不需要改变工作流就能用起来。这个阶段的目标不是替代而是建立用户信任和反馈循环。你通过插件了解用户的真实痛点用户通过插件了解你的技术能力。等信任建立起来之后再推独立工具就顺理成章了。5.2 第二步在特定领域做深形成“场景闭环”选一个垂直场景比如电池管理系统BMS的建模与仿真把这个场景做透。从模型库、求解器配置、测试用例、代码生成模板形成一套完整的解决方案。让用户在这个场景里觉得“用国产工具比用 Simulink 更顺手”。这个阶段的关键是场景闭环。不是做一个通用工具让用户自己摸索而是针对特定场景提供开箱即用的体验。比如 BMS 的 SOC 估算你提供现成的等效电路模型、参数辨识工具、卡尔曼滤波模板用户只需要填参数就能跑。这种体验是 Simulink 通用平台给不了的。5.3 第三步补齐 AUTOSAR 和功能安全能力当你在特定领域有了足够的项目案例就可以开始补 AUTOSAR 和功能安全的短板。AUTOSAR 的支持可以从 CAN 协议栈、NVM 这些相对独立的模块开始逐步扩展到 SWC 和 RTE。功能安全可以先做 QM 场景积累数据后再申请认证。这个阶段需要和主机厂、Tier1 深度合作。工具认证不是闭门造车能完成的它需要真实项目的验证数据。我建议找一家愿意吃螃蟹的主机厂在一个非核心项目上试点把整个流程跑通积累证据链。5.4 第四步构建生态而不是单打独斗Simulink 的强大不在于它自己而在于它周围的生态大量的第三方工具箱、咨询公司、培训课程、社区问答。国产工具要成功也必须构建自己的生态。这包括开放 API、支持 FMI 标准、兼容 Python 生态、建立开发者社区。我特别想强调兼容 Python 生态这一点。现在做算法预研的工程师越来越多用 Python如果国产工具能无缝调用 Python 函数能导出 Python 可读的模型描述这会大大降低迁移门槛。Simulink 在这方面其实做得不够好MATLAB 和 Python 的互操作一直是个痛点。国产工具如果能把这块做好是一个差异化的机会。6. 几个真实项目的观察与个人判断6.1 一个主机厂的替代评估项目去年我参与了一个主机厂的工具链替代评估他们的目标是在三年内把 Simulink 的使用比例降低 30%。评估了五家国产工具最后选了两家做试点。试点的场景是车身域的控制逻辑建模不涉及功能安全不涉及 AUTOSAR 代码生成只做模型在环仿真和代码生成。试点跑了六个月结果很有意思在简单控制逻辑上国产工具的效率确实更高因为界面更轻量启动更快而且没有 MATLAB 授权的问题。但在复杂状态机、模型引用、库管理上和 Simulink 的差距还是很明显。最后他们的结论是在车身域的低复杂度模块上可以替代在动力和底盘域暂时不动。这个结论和我前面的判断一致局部替代可行整体替代不现实。6.2 一个创业团队的 Modelica 编译器我跟踪过一个做 Modelica 编译器的创业团队他们的技术路线很清晰不做通用建模环境只做多领域物理系统的仿真引擎。他们把自己的编译器做成一个库可以嵌入到其他工具里也可以独立运行。商业模式是给 HIL 测试台架厂商提供实时仿真引擎。这个路线的聪明之处在于避开了和 Simulink 的正面竞争找到了一个 Simulink 做得不够好的场景。Simulink 的 Simscape 虽然能做物理建模但编译出来的实时代码效率不高而且授权费用贵。他们的引擎在实时性上有优势价格也更有竞争力。目前已经在几个 HIL 台架项目上落地了。6.3 一个关于“模型整理”的小工具还有一个案例值得说。有个小团队做了一个 Simulink 模型整理工具功能很简单自动对齐信号线、统一命名规范、检查未连接的端口、生成模型结构文档。这个工具在 GitHub 上开源现在已经有不少公司在用。这个案例说明替代不一定是宏大的也可以是很具体的。Simulink 有很多让人不爽的地方比如模型乱、信号线交叉、命名混乱。这些小痛点单个看不大但积累起来很影响效率。国产工具如果能解决这些具体问题用户是愿意买单的。7. 写在最后替代是一个过程不是一个事件聊了这么多我想把观点收一收。汽车行业对 Simulink 的依赖本质上是对一套经过验证的方法论和生态的依赖。替代这套东西不是做一个功能对等的软件就能解决的它需要时间、需要项目验证、需要生态建设。但我也不认为国产工具没有机会。机会在于Simulink 不是万能的它在很多场景下笨重、昂贵、封闭。国产工具可以从这些场景切入用更轻量、更灵活、更便宜的方式解决具体问题。一个一个场景地啃一个一个模块地替最终形成合力。我个人的判断是未来五年汽车行业会出现一批国产工具它们在特定场景下可以替代 Simulink但在核心建模和代码生成环节Simulink 的地位依然稳固。这不是悲观这是对工程现实的尊重。真正的替代从来不是喊口号喊出来的是一个项目一个项目做出来的。如果你正在做国产工具或者正在评估替代方案我的建议是不要追求全面替代先找一个具体的、痛的点把它做到极致。汽车行业很大容得下很多种工具。Simulink 不是唯一的答案但它是一个很好的参照系。