ETAS如何打破AUTOSAR的固有偏见

前言：

AUTOSAR Classic 常被诟病为复杂且缓慢——但这种看法是否合理？ETAS 首席产品经理 Darren Buttle 在《Automotive World》中阐述了 RTA-CAR 如何直击真正的痛点：将构建时间从数小时缩短至几分钟，通过虚拟 ECU 加速调试，并借助自动化工作流简化配置——同时绝不牺牲安全性与效率。

更快、更简、更智能：ETAS 如何打破 AUTOSAR 的固有偏见

ETAS深入解析RTA-CAR如何解决AUTOSAR Classic的主要痛点。

作者：Megan Lampinen, Automotive World

2026年4月2日

AUTOSAR Classic素有增加复杂性、拖慢开发速度之名，但这种看法大多源于误解而非事实。ETAS嵌入式平台软件首席产品经理Darren Buttle指出，对于从事车载深度嵌入式电子控制单元（ECU）开发的团队而言，这一标准化软件框架确实发挥着关键作用。 关键在于ETAS的RTA-CAR平台，它切实解决了AUTOSAR开发中的实际痛点。从简化配置、加速代码生成，到支持虚拟化和CI/CD工作流，RTA-CAR使工程团队能够在不牺牲安全、安全性或空间利用率的前提下加快开发进度。

AUTOSAR为何以复杂著称？这种说法是否站得住脚？

AUTOSAR的复杂性本质上是其构建方式的产物。在25多年的时间里，贡献者们提出了各自的想法，该标准正是通过整合所有这些想法而发展起来的。每个人都能在其中找到适合自己的特定解决方案，并忽略其余部分。

其目标更多在于覆盖面而非简洁性——如何尽可能容纳更多的变体和边界情况？ 此外，AUTOSAR 的很大一部分是为支持从 AUTOSAR 之前时代遗留解决方案的迁移而构建的，同时也反映了 OEM 厂商处理系统工程的方式。

若撇开种种误解，AUTOSAR Classic 究竟试图解决什么问题？

从本质上讲，AUTOSAR 致力于解决深度嵌入式实时系统面临的根本性挑战：运行时调度、可靠通信、可靠数据存储，以及现场系统诊断能力。 AUTOSAR 系统运行在裸机上；在部署该栈之前，设备上没有任何其他内容。AUTOSAR 本质上充当了硬件（不同芯片之间差异显著）与 OEM 要求（同样存在显著差异）之间的粘合剂。

人们对 AUTOSAR 的诸多不满似乎主要集中在实现层面，而非标准本身。工具或工作流集成不佳，为何会让一个健全的框架变成开发瓶颈？

这种挫败感与其说是源于实现，不如说是源于配置。配置空间包含数十万个元素，其中确实存在着“选择悖论”。当你带着具体的工程问题接触 AUTOSAR 时，会面临海量的选项，但标准本身对哪些选项适合特定情况却几乎没有提供指导。 结果便是，你试图解决的问题与AUTOSAR所宣称的“可行方案”之间存在语义鸿沟。而正是这个鸿沟，导致了大量时间和风险的积聚。

ETAS平台具体如何解决这些实施痛点？

我们主要提供两项价值：其一是时间。当客户询问我们是否有某项工具时，他们真正关心的是这能否加快工作进度。 我们致力于缩短从构思到在 ECU 上进行测试的时间，以及从修改到观察修改效果的时间。这直接关系到工程师的工作效率。RTA-CAR 只需几分钟就能完成构建，而无需等待八小时。这意味着您每天可以查看 20、30 甚至 50 处修改，而不是仅有一处。

我们销售的第二项价值是专业知识——即我们数十年来积累的洞见与经验。我们的工具不仅提供自动化，更融合了 对问题领域的深刻理解，使客户不仅能加速开发，更能朝着正确的方向加速前进。

深度嵌入式软件开发面临着独特的约束：确定性、内存占用、安全认证。ETAS的方法如何在不迫使工程师在这些因素之间进行权衡取舍的情况下处理这些问题？

经典的权衡在于空间与时间之间：运行更快通常需要更多空间，而运行更慢则占用较少空间。我们在操作系统内核中实现了一些出色的优化，让您能够更好地控制这种空间/时间的权衡。例如，通过牺牲系统中的空闲时间来换取更小的内存占用，或者反之，这种能力赋予了开发人员对系统资源更灵活的控制权。

此外，我们充分利用了自身作为“代码生成优先”解决方案的特性——而非先编写标准代码，再生成供代码运行的数据。我们的目标是生成最少量的代码和数据，以实现客户配置的落地。这使得我们的解决方案体积比竞争对手小三到四倍。

RTA-CAR 具体如何简化配置、缩短集成时间并减轻调试负担？

借助 RTA-CAR 的导入功能和自动配置工作流，您可以利用一组 OEM 文件，以惊人的速度构建出几乎可运行的 ECU。

我们的入门套件是预先构建的参考集成方案，包含针对特定设备及特定第三方微控制器驱动软件的极简系统框架。其核心理念是实现最快速度的启动与运行。虚拟ECU确实能显著加速集成过程。在主机PC上而非芯片本身进行集成，能带来极大的效率提升：编译更快、调试更简便，且不受嵌入式硬件限制的束缚。 虽然迁移到嵌入式硬件时难免会出现问题，但既然您已经在虚拟环境中验证过软件，便能确定任何新出现的故障都仅限于软硬件接口，而非更广泛的软件缺陷。虚拟ECU的方法让您能够将大部分调试工作提前完成。当您最终进入目标硬件环境时，面临的剩余挑战将变得范围更小且界定清晰。

根据您与整车厂商（OEM）及一级供应商合作的经验，开发团队在处理深度嵌入式软件时，通常会在哪些环节耗费最多时间或引入最大风险？解决这些问题又该如何着手？

在为使用新的芯片进行调试时，设备在某个阶段总会存在缺陷。如果能在芯片投入量产前先在虚拟环境中进行调试，将大有裨益。如今，芯片本身的复杂性使得开发工作变得极其繁琐。过去调试单核微控制器只需两三天，而现在光是让芯片稳定启动就可能耗费数月时间。

另一项常见的挑战在于设备资源的使用。如果芯片上搭载了大型多核系统，大量并行处理会带来新的难题。当两个功能模块需要交换数据时，迟早会有一个模块必须暂停执行，传输数据，等待处理完成，再接收回数据。 我们的工具集提供了功能，帮助团队准确掌握核心之间往返传输的数据，并确保以最佳方式强制对这些数据进行串行化和互斥，从而避免数据损坏等问题。

这还涉及整体性能的考量。一个 CPU 核心可能拥有核心本地内存，同时也与其他 CPU 共享内存；而另一个 CPU 则可能拥有独立的核心本地内存。这些内存的访问时间各不相同。数据 在系统中的放置位置，对整体时序响应能力有着显著影响。我们可以帮助客户理解数据放置与访问相关的成本及权衡。

如果一个工程团队今天正在启动一个新的深度嵌入式软件项目，您希望他们了解什么？即在项目初期选择正确的平台，将如何决定两三年后哪些功能是可行的，哪些是不可能实现的？

他们需要以最简洁的方式明确待解决的问题。随后，我们的现场工程团队将协助他们制定合适的解决方案架构。理解待运行应用程序的复杂性，可能是任何项目中最基础的一环。

如果您能给一个开发团队，或者一位对采用基于 AUTOSAR Classic 的工作流犹豫不决的经理一条建议，那会是什么？

AUTOSAR蕴含着丰富的嵌入式工程经验，能够为现实中的工程难题提供优雅的解决方案。您需要像ETAS这样经验丰富的合作伙伴，引导您发掘这些宝藏，并帮助您在项目中充分利用这些优势。