MathWorks的汽车AI哲学：当AI存在不确定性，如何建立AI信心？

AI技术在各行各业的落地正在持续进行，典型的像是汽车——而且这种落地可能是涉及到各方各面的。比如前不久的2024 MathWorks中国汽车年会上，MathWorks开发总监Jon Cherrie特别在主题演讲中提到了AI驱动的工程系统。

他说AI正对工程系统产生革新，比如说KPIT公司就用MATLAB^®训练神经网络，用于估测电池电量状态（SOC）和健康状态（SOH）。“他们验证网络的鲁棒性，并使用AUTOSAR Blockset和Embedded Coder将其融入到Simulink^®模型中进行嵌入式部署。不需要在车内使用特别的物理传感器，也就节约了成本。”Jon说。

再比如斯巴鲁在MATLAB中采用降阶建模（Reduced Order Modeling）打造了AI代理模型，大幅缩减了分析变速控制系统所需的时间；还有APTIV将实车上采集到的测试数据转换为虚拟场景，通过模拟严格验证ADAS闭环算法用。

另外还有现在格外流行的生成式AI。Jon认为生成式AI对工程化工作流的影响，表现在3个方面：第一，加强现有工作流，可用于学习、帮助构建代码、进行分析，以及检查工作质量等；其次，对MATLAB和Simulink用户而言，也可使用和打造自己的Transformer模型；第三，在工程系统中也能用生成式AI，将LLM应用于时间序列（time-series）传感器数据，打造实时和近实时的系统，且确保安全性。

这些固然是AI的价值所在。但考虑到汽车的高可靠性、安全性需要，AI技术的不透明及可能存在的模型幻觉问题，是汽车行业参与者选择AI技术的阻碍。所以Jon演讲的主题实际上是为AI驱动的工程系统设计“构建信心”。想必这也是MATLAB这类开发工具提供商在AI技术大潮之下，最需要向客户和行业佐证的。

要先解决数据的问题

构建一套上述例子中的工程系统：首先需要发现问题，那么就需要了解用户预期；用户预期和顾虑会驱动工程需求；随后获取数据，进行数据管理和准备——可能需要生成数据，或者进行数据标注一类的预处理；然后开发系统架构和设计；

构建起AI模型，并基于数据进行训练；还要进行AI模型验证；将AI模型放进系统架构中，并且再次进行系统验证和确认；搞定之后就可以进行模型的部署了；部署完成以后，仍然需要监测其工作情况；基于AI模型工作的信息，以及用户的反馈，对其做进一步的加强。

以上就是整个工程系统的常规设计流程。那么该怎么构建起使用AI的信心呢？主要思路是将每一步的信息都反馈到上一步或更早的步骤——如上图中的绿色虚线所示。“搭配每一步正确的工具、正确的流程和步骤，那么在设计流程的更早阶段就能做出稳定可靠的决策，提升设计的整体信心。”

Jon演讲中主要谈到了其中的数据管理与准备、AI模型开发与训练、AI集成/系统验证和确认、AI模型部署，以及贯穿始终的监管和治理（regulation and governance）。

首先是数据——应用的数据质量很重要。“但真实数据通常是杂乱的（messy），而且数据量也经常不够。”Jon谈到，“面向特定领域，对数据进行预处理，是件比较困难的事情。”所以针对特定领域，做基于AI的数据处理，MathWorks提供了对应的工具。Jon主要谈到两个方面：数据标注（Data Labelers）、数据合成（Data Synthesis）...

对于数据标注，MathWorks提供的工具支持对图像、信号、视频、激光雷达等数据做AI引导自动化的标注。Jon特别举了卡特彼勒（Caterpillar）的例子，此前这家公司在真值（ground truth）的数据标注上需要耗费大量时间。在和MathWorks合作之后，卡特彼勒开发了一套基于web的真值标注系统，包括用于数据存储和查询的数据库，从而开发时间大幅缩短。

“数据标注是原始数据清洗的一个步骤，” MathWorks中国区汽车行业经理周斌在采访中说，“我们提供的数据标注工具箱，专注于让流程更加自动化；而且工具本身也有出色的UI交互界面，使用门槛低。用户基本不需要自己去写脚本或代码，点点鼠标就能完成数据标注工作。”

而有关数据合成——也是我们此前讨论AI训练时逃不开的话题。即在真实数据不够的情况下，合成数据就能做对应的补足。MathWorks的解决方案是用Simscape模型，以及虚幻引擎（Unreal Engine）来生成合成数据 —— 包括自动驾驶行车数据，无人驾驶车辆的非道路（off-road）相关数据等。

AI模型有了，验证是关键

如前所述，数据准备就绪了，接下来的关键就是AI模型构建、验证及部署了。对于MathWorks的用户而言，可以用MATLAB来构建专属的模型——不管是适用于嵌入式应用的LSTM，视觉和LiDAR领域仍然很流行的CNN，还是数据中心的生成式AI大模型都可以；当然用户也可以使用其他模型。

用户构建自己的AI模型，有着相当广泛的方法。是在本地，还是在云端打造模型，取决于应用的具体需求。

在本地，可以选择用MATLAB及其深度学习工具箱，从头搭建自有模型；或者基于预训练模型，从TensorFlow或PyTorch^®导入到MATLAB——可在本地构建、运行或fine-tune对应的模型，“我们的产品会为用户提供了丰富的功能、接口和引导。” Jon说到。

而在云端，要跑现在很流行的LLM，可以在Hugging Face网站上查看通用排名 ——包括来自OpenAI, Google, Anthropic时下相当火的模型，这些模型通过Github库”llms-with-matlab“就能使用。并执行文本生成等任务，以构建客户自己的内部助手；或者从文本生成图像，以测试计算机视觉解决方案的鲁棒性。

在构建好AI模型之后，如文首所述，对开发者而言，更关键的问题是确保AI模型的可靠性、鲁棒性，以及Jon特别在采访中提到的“可解释性（explainability）”；所以对AI模型的验证、解释很重要。MathWorks认为应采用三种关键方法。

针对模型的可解释性，应该采用白盒建模（white box modeling）的方式——只不过Jon并未就这一问题做深入。他在采访中提到MathWorks有一些技术方案和工具可达成这种可解释性；另外两种关键方法，分别是AI验证，以及仿真与测试。

举例来说，神经网络可能对车载摄像头看到的对象进行错误归类。他谈到行车过程中在路侧骑行的人，在加入某些细微噪声以后，就可能被模型误判为电线杆。这显然是开发者和用户不能接受的。“这其实还挺常见的。”Jon说道。

对此，MathWorks有了神经网络验证技术，这是一种形式化验证方法，又被称为抽象解释（abstract interpretation）。

这种方法并不只做一种输入、后观察输出；而是做一整套的输入，比如说针对一张图片——改变某些像素的组合方式，再观察输出。验证算法可用于证明，在输入存在扰动的情况下，模型的鲁棒性如何。就像前文提到的，仅在画面中加入噪音，模型是否将其中的骑行对象识别为杆子。

另外还需要进行仿真与测试。“MathWorks本身就非常擅长做仿真测试，这也是在设计系统中构建起信心的另一种方法。”Jon举例谈到通用汽车基于采集到的真实数据，来生成驾驶场景，用以验证车道居中系统（lane centering system）。这个过程用的就是MathWorks的工具。通用汽车此前已经在SAE上发表了这一成果，有兴趣的读者可前往阅读。

周斌补充说：”自动驾驶的感知算法很重要，而算法的验证也很重要。自动驾驶系统包含了感知、规划、决策控制、场景、传感器、车辆动力学等好几个模块。Simulink提供了完整的测试仿真框架和工具，将这些模块集成到同一个平台上，实现闭环的系统仿真，用以对AI模块的可靠性进行验证。”

加上基于实车采集的数据构建真实场景，就可以利用仿真来验证系统是否按照预期进行工作。因此仿真在自动驾驶系统开发中就起到了很重要的作用。总而言之，针对自动驾驶开发，MATLAB, Simulink和RoadRunner从虚拟仿真、算法设计，再到软件集成、测试和部署提供了完备的端到端开发平台。”

归根到底，软件定义汽车时代，软件快速交付的同时，必须兼顾软件质量 “要保证软件质量，一定要把测试验证做充分，无论是模型层面还是代码层面。因此越来越多的汽车客户采用基于模型设计（Model-Based Design）的方法和流程开发符合 ISO 26262、ASPICE等行业标准的应用软件，以保证在模型、代码层面进行充分测试；也可以在早期通过仿真去验证功能，从而更早地发现问题。”周斌总结道。

适配各类硬件的部署方式

AI模型及配套开发准备就绪以后，就到了真正部署于硬件的环节。MathWorks宣称：支持零代码错误、部署到任意处理器上，包括模型压缩（包括剪枝、投影-projection、量化）之后，针对AI模型做代码生成，最终就能以出色的效率部署到不同类型的处理器上，如下图所示。

当然部署的并不单纯是神经网络，而是包括神经网络的整个系统：MATLAB代码和Simulink模型。Jon强调说：“MathWorks在代码生成工具开发方面有超过20年的经验，这是确保部署到不同处理器的关键因素之一。”

周斌在采访中说，MathWorks在与包括高通、英飞凌等在内的芯片厂商保持着紧密的合作。“譬如我们为英飞凌定制开发了AURIX TC4x的硬件支持包，可以降低用户使用它的门槛，并轻松地将AI算法高效部署到并行处理单元PPU上。如果没有这样的硬件支持包，用户就需要对其硬件要有更深入的了解，否则无法部署”

与此同时，客户在开发初期可能不知道会采用什么芯片和硬件，Jon表示：“在设计过程更早期就能用我们的代码生成技术，选择模型的时候也不需要受限于特定的处理器，可以晚一点再做决定”。这也是提高开发效率、缩短time-to-market的一部分。

英飞凌展位上展示的AURIX TC4x，周斌特别谈到MathWorks与英飞凌合作，采用定制开发的硬件支持包HSP生成的代码能够充分释放这款芯片中的PPU并行处理单元的性能

“一般一种算法要适配不同硬件和芯片，甚至可能需要重新开发软件，工作量是很大的。”周斌表示，“基于模型的设计提供了一套成熟的工具链，帮助客户设计算法、测试模型，自动生成C/C++代码，然后再由硬件支持包HSP将算法跑在对应的芯片上。”“而且Simulink提供了适配不同软件架构和中间件的产品和工作流支持，譬如AUTOSAR, DDS, ROS等。用户按照参考流程，就能方便、自动化地实现算法重用和移植。”

与此同时，Jon特别提到MathWorks在模型压缩方面的投入及工作成果。比如文首提到电池SOC状态预测的例子，即是将原来超过460k参数规模的LSTM模型，借助MathWorks的模型压缩工具，将参数量缩减至32k左右，实现了模型尺寸93%的缩减。再看其他性能，fine-tuned projected之后的模型性能快了1倍，而且精度损失相当小。这也是当前efficient AI相关所有市场参与者的必修课了。

在“卷”的市场中，实现降本增效

从需求到高质量数据准备，从架构设计到AI模型构建，从测试验证到最终部署，MathWorks在整个链条上实现了工作流闭环。不过构建AI系统信心还有一环，即监管和治理。这涉及对应的行业标准、强制法规等。

AI本身在各行业各领域的发展也正逐渐走向标准与法规的完善。MathWorks也紧跟这些趋势、法规和认证，尝试在不同行业之间引入最佳实践。我们认为航空航天领域EASA（欧洲航空安全局）的W型开发流程很值得借鉴，它和很多人熟悉的基于模型设计的V型工作流很相似。” Jon提到。

“基于这样的模式，我们开发了相应的参考工作流，客户也就能够基于自己的情况应用这种开发流程，确保包含AI的系统能够在标准出来以后就满足需求。法规可能不会那么快出来，但跟着这个模式去走，就相当于准备好了面向未来的系统认证。”

从MathWorks的这番阐述，实际不难发现，构建起AI技术信心、为整个工作流提供成熟可靠的工具，也变相实现了系统开发的降本增效。

比如说电池SOC状态估测，用“虚拟传感器”替代物理传感器；比如涉及到AI应用部署时，支持不同处理器类型及供应商的代码生成；再比如参考工作流的构建，也为客户极大程度缓解了技术发展及市场变量造成的不确定性；还有EE架构走向集中化趋势下，ECU数量缩减，MathWorks提供System Composer和AUTOSAR Blockset等工具应对不断增长的系统和软件复杂度、面向服务架构的新范式等等…

不得不说在这个越来越卷的汽车市场大环境下，对MathWorks这类提供开发工具的市场角色而言，“卷”既是挑战，也是机会：无论是为客户构建起使用AI的信心，还是借此机会实现更进一步的降本增效。