ARTICLE · 1166625

ECU应用层软件模型开发之43 哪些是AI不能替你干的Simulink建模

发布时间：2026-10-13 08:38:34 最近访问：2026-10-13 08:38:35

ECU应用层软件模型系列文章更新陆陆续续超过40来篇，本着从零开始教你做应用层开发，目前文章如下

我们一定要使用AI来实现Simulink建模，但是我们也不能完全都让AI做了。因为有些事情还得必须自己做一遍，不然我们就跟不上AI的节奏了。

本文就结合实际项目经验，分享几点个人认为自己应该去做的重要事情之一--需求分析！

案例1 DBC或CAN matrix分析

从ECU供应商角度，对于DBC，关注无非就是两块：Rx报文和Tx报文，针对Rx报文，我该怎么用；针对Tx报文，我该怎么发。

这两块谁可以回答？主要靠客户，通常是主机厂，他想我们做什么，怎么做，即体现在Rx报文，他想我们发给他什么，他期望我们按照怎么的逻辑去定义了给他发的，即体现在Tx报文。

要充分理解客户的意图，那么客户输入过来的软件需求非常重要，结合需求去看客户的Rx报文和Tx报文是否承载了这些内容和信息。

DBC是接口，完整的DBC报文和信号定义是软件需求实现的基础，因此我认为结合DBC和软件需求的分析，这是第一优先级的。况且对于客户（主机厂）来说，DBC的变更通常是耗时的，先做它将是保证软件开发进度的关键动作。

再呢，以前看DBC的感觉就是：哦，我们的输入和输出有这些信号哈，然后加上就完了。而现在看DBC，会联想到软件需求，会评估我们产品功能和性能能否满足，会猜想客户通过这些接口是怎么去实现他的整车功能的呢？

案例2 状态机跳转

对于应用软件开发而言，基本上都有一个状态机来决定产品处于何种状态，而执行何种动作，如下所示：

这里关于状态机，通常完整的状态机都需要考虑正常情况和异常情况，以使得产品功能和性能的完整性。因此对于所有情况的考虑，将体现在跳转条件中，即一个状态在满足哪些条件下，可以跳转到另一个状态，以此类推，构建起了完整的状态机。然后在每个状态下，应该要干什么，要去控制哪些执行器去执行哪些动作，即状态动作。

比如汽车挂挡，P档，无动力输出；D档，动力正向输出；R档，动力反向输出。

注意实际考虑到这个状态切换，并不是仅仅考虑几个关键因素：油门踏板深度，制动踏板深度，车速和档位位置，而是还有其他很多因素，比如故障状态和其他功能抑制等。

因此，充分分析状态机相关的需求极其关键，一方面全面理解功能意图和预期的行为，即状态跳转的条件和状态所需执行的控制；另一方面当前需求定义中的逻辑闭环和自洽，即需求定义的是否正确且完整，状态是否足够，跳转是否独立或互斥等。

也就是说通过这样的需求分析，我们可以通过状态机相关需求的综合理解构建起整个功能实现的软件框架等。

案例3 软件实现相关方

当我们着手于软件开发工作，我觉得有个点特别重要：你知道你能做什么，你不能做什么。即有哪些是完全自己独立可做的，有哪些是其他部门和同事来做的，又有哪些是需要依赖或关联其他部门和同事才能做。因此清晰认识软件实现相关方，这非常重要。

就好比于你负责APP，那么有哪些是与BSW关联的，比如APP和BSW要通过RTE做怎样的交互，如下所示：

4 小结

以上就简答列举三个案例/点，就是当前实际项目中我觉得必须得自己去做，而不能完全依赖AI。只有自己去做好了这些重要工作，才能保证AI给你的东西不超出你的认知范围，你才能去把控AI交付给你的东西。

也就是说：先让AI当你的小弟，帮你去做具体的事情，大脑还得是你，由你把控；当然同时让AI辅助你扩展自己的认知边界，知识的广度和深度，再进一步指挥AI来具体做什么。

ECU应用层模型开发中标定量与观测量的应用与原理15