15年前，如果你去dSPACE、FEV、博世这些企业官网看一下，满屏都是第二次工业革命的画面，恍惚之间，你甚至能闻到浓浓的汽油柴油的味道，映入眼帘的几乎是清一色的发动机、变速箱的测试。
![]()
8年前，你再去他们的官网看一下，大篇幅的新能源汽车测试内容，BMS、VCU，巴拉巴拉的。
![]()
3年前到现在，你再去看一下他们的官网，画风又变了，大篇幅的智能座舱、智能网联OTA、无人驾驶等等……
![]()
我们很容易发现，这些供应商真是“随波逐流”啊，啥赚钱搞啥，毫无“初心”、“坚守”、“节操”可言。😂😂
dSPACE产品线阵容的一些新变化
不过呢，这也是再正常不过的商业逻辑了，毕竟，如果赚不到钱，这些企业你也看不到啦~~~
但是，有些内容是一直没有变化的，比如我们对ECU测试内容的分类。对于任何一个车载ECU而言，它的工作大致分为以下几类：
比如诊断、刷写、网络管理、物理层链路层通讯一致性等等，这些方面是车载ECU功能的基础，如果这些都保证不了，那其他的都别提了。做出来的车，品质肯定好不到哪里去。协议栈测试一般都是依据企标或者行业标准来执行，内容繁杂、条目众多，执行难度较大，但是预期结果相对比较明确。这方面的测试，最好直接找供应商买设备，省心省事，自己只要把测试用例excel格式，以及需要采用哪些参数，提清楚，就好了。有的坑是交货的时候就给你挖好了，因为你没提清楚需求，供应商给你把参数写死了；有些坑是半年后出现的，因为车上新增了控制器，这个测试系统覆盖不了了。有些坑是过几年才形成的，因为标准有欠缺，更新了，你没有规划好，需要升级设备，又被敲竹杠了；还有的坑是同事给你挖的，他负责的ECU不按标准来，但他还比较蛮横，领导也偏向他。所以，有能力的话，还是值得尝试自主开发的，虽然比较困难，但是做好之后能通用很多控制器，用处很大，应对多种情况都游刃有余！功能逻辑是比较直观、简单易上手的工作内容，也是大多数中低水平公司的测试重点，同时也是比较容易扯皮的业务。它的工作来源是功能定义文档，大多数都是明确的结果，比如3=1+2、c=a*b、f=d&e这样的内容。
然而很多公司开发流程比较混乱，定义文档都写不清楚，经常导致不同部门之间掐架、甩锅，这又是另一个话题了。
体验类测试，也分两类。
一是研发层面的，比如标定、动态调教、人机交互等等；二是工厂组织的用户测试，比如VES评价等等。说实话，这部分内容距离研发稍微远了点，尤其是工厂测试，基本上属于用户层面的操作测试， 一般是由营销管理部、质量部去做的。
所以，绝大多数测试团队，都把精力用在了功能逻辑测试方面。这个方向，门槛低，并且也方面对外显摆，而且一脚踏入了软件的领地，PPT也好写。
这个指的是雨刮、天窗、门锁、空调、热管理、电池管理、踏板等等相关的逻辑，它们的重点难点在于自动化测试和测试用例库建设。这个主要针对的是EMS、TCU、MCU等需要较逼真仿真模型的HIL测试领域，它们需要使用车辆技术定义的第二类HIL模型。HIL13讲，零基础教程，第一类“HIL整车模型”的作用
针对低实时性测试，如果时间充足，完全可以买一些板卡，自主搭建集成一些测试系统来使用。而且这个也不是重点，不应占用太多时间，真正的重点是自动化测试和测试用例库的建设。针对高实时性测试，就算了吧，HIL设备和HIL模型就直接从供应商买就好了，自己做也做不好，还浪费了时间。当下汽车行业的一大现状，就是大多数新增的功能、概念及其控制器，对物理仿真实时性要求都不高，低物理实时性控制器的占了大多数。热管理、电池管理、VCU、座舱、智能网联、V2X、以太网……这些个当红炸子鸡们，全部都是如此！dSPACE最初发明的那一套玩法，可能越来越玩不转了。当然，真正玩不转倒不至于，那一套玩法应该还是很有用的，只不过不少人都懂了，收不了智商税了。现在的智商税高发区变地方了，也变到了那些所谓的行业热点前沿！
