探讨AUTOSAR是否可能被其他软件框架取代

欧洲

只要传统主机厂与供应商之间的开发体系没有改变，那么使用 AUTOSAR 的现状也不会发生根本性变化。对于传统主机厂（尤其是欧洲的主机厂）以及那些自身缺乏软件能力的主机厂来说，它们仍然会大规模依赖 AUTOSAR。Classic Platform（CP）经过多年的发展，已经成为一个非常成熟的框架，并通过了众多量产项目的验证。其模块功能和 API 的成熟度极高，能够满足大多数项目需求。此外，传统主机厂倾向于对供应商开发的内容进行标准化处理，甚至可以直接将 ECU 需求映射到 AUTOSAR 规范中，例如网络管理部分。在我看来，AUTOSAR 最大的贡献之一在于：主机厂完成通信建模后，可以导出某个节点 ECU 的 CAN 通信矩阵，并以 ARXML 格式呈现。如果供应商也使用 AUTOSAR，工具链可以直接导入这些数据并生成 CAN 通信代码，极大地简化了开发流程。从这个角度来看，我认为国产替代在这一领域有着很大的潜力。实际上，AUTOSAR CP 并不是什么特别先进的技术框架，它只是设计得非常复杂，给人一种高门槛的印象。然而，国产替代方案可以通过优化设计、减少不必要的复杂性，从而大幅降低成本。 结论尽管如此，我认为要想像特斯拉那样完全自研并放弃 AUTOSAR，需要满足几个前提条件：1. 必须自研多个控制器 在多次公开场合中我都提到过，如果你计划自研两个或以上的控制器，那么从经济角度考虑，自己开发的框架可能比直接采用 AUTOSAR 更划算。这是因为目前 AUTOSAR 的供应商市场仍然被国外厂商主导，导致整体成本居高不下。2. 软件团队需具备足够的垂直集成/开发能力 如果你的软件团队仅限于应用层开发，而无法深入到底层架构或系统集成，那么建议不要轻易尝试自研。否则，你可能会发现难以掌控整个开发过程。接下来，我将基于 AUTOSAR 分层架构给出一些建议，帮助读者评估是否适合自研某些模块。

操作系统（OS）操作系统这部分完全没有必要自研。直接选择成熟的实时操作系统（RTOS）即可。通常情况下，芯片厂商在发布新款芯片时，都会预先集成常见的 OS 或 RTOS，并提供驱动程序的参考设计。这意味着，如果你选择了常见的 RTOS，后续几乎不需要对底层驱动进行太多改动。例如，许多芯片厂商已经为 FreeRTOS 提供了完整的 bring-up 支持，包括 bootloader 和所有常见外设的驱动程序等。如果你需要开发安全相关的系统，则可以选择 SafeRTOS，其 API 与 FreeRTOS 完全兼容。至于为什么很多 AUTOSAR 厂商会打包一个底层的操作系统给我们用？说实话，我一直不太明白这种做法的实际意义。这些操作系统通常是私有的，按照它们提供的 API 进行开发反而会让你牢牢绑定在这家 AUTOSAR 厂商身上。相比之下，选择常见的操作系统具有明显优势：工程师的学习成本更低，且这些系统经过了更广泛的验证，显然比 AUTOSAR 厂商提供的解决方案更加成熟。唯一我能想到的好处是，AUTOSAR 供应商可能会告诉你，他们的操作系统完全符合 MISRA 标准。但从实际开发角度看，这一点并不足以成为选择它们的理由。

下面进一步分析其他模块的自研可能性 BSW（Basic Software Layer）BSW 是 AUTOSAR 的核心组成部分，主要包括通信、诊断、存储等功能模块。对于这部分内容，可以根据具体需求决定是否自研。- 通信模块：如 CAN、LIN、Ethernet 等协议栈，虽然 AUTOSAR 提供了现成的解决方案，但这些模块本身已经相当成熟，市场上也有许多开源或低成本的替代方案。如果团队具备足够经验，完全可以自行实现。 - 诊断模块：例如 UDS 协议栈，这是现代车辆诊断的核心部分。虽然 AUTOSAR 提供了标准化的实现方式，但如果团队有较强的技术实力，也可以根据项目需求定制化开发，避免支付高昂的授权费用。- 存储模块：如 NVM（非易失性存储），这一块同样存在大量成熟方案。如果性能要求不高，完全可以采用开源库或简单的设计来满足需求。 RTE（Runtime Environment）RTE 是连接上层应用软件与底层基础软件的关键桥梁。对于是否自研，我的建议如下：- 如果团队已经有完善的分层架构设计能力，可以尝试自研 RTE。这样不仅可以更好地控制系统的灵活性和扩展性，还能减少对第三方工具的依赖。- 但需要注意的是，RTE 的开发涉及复杂的接口管理和数据交互逻辑，如果没有足够的经验积累，容易导致开发周期延长甚至失败。 MCAL（Microcontroller ABStraction Layer）MCAL 主要负责硬件抽象，使得上层软件可以独立于具体硬件平台运行。对于这一层，我的观点是：- 如果所使用的芯片型号相对固定，且团队对硬件驱动开发有丰富经验，完全可以自行开发 MCAL 层。- 不过，考虑到市场上已有许多成熟的 MCAL 解决方案（如由芯片厂商直接提供），除非有特殊需求，否则一般不建议花过多精力在此处。

XML

综合评估综上所述，虽然 AUTOSAR 提供了一套完整的汽车电子软件开发框架，但它的复杂性和高昂成本使其并非唯一选择。特别是对于那些希望实现深度自研的企业来说，可以根据自身需求和技术能力，灵活调整各模块的实现策略。以下是一些具体的建议：1. 对于操作系统部分，优先选择成熟的第三方 RTOS，避免重复造轮子。2. 在 BSW 和 MCAL 层面，结合项目实际情况权衡是否采用现有方案或自研。3. 如果团队具备较强的系统设计能力和丰富的实践经验，可以尝试自研 RTE，以提升系统的灵活性和可控性。最终目标是，在保证功能安全和可靠性的同时，尽可能降低开发成本，缩短产品上市时间。这既是对企业竞争力的考验，也是对未来技术发展趋势的前瞻性布局。