您当前所在位置：智能汽车 > 查看内容

AUTOSAR是否可以被其他的软件框架取代？

发布：lihu35 来源：

PostTime：25-4-2024 20:12

观点只要传统主机厂- 供应商的开发体系不变，使用AUTOSAR的现状就不会改变。传统主机厂（特别是欧洲的主机厂）和一些没有软件能力的主机厂会继续大规模使用。CP(Classic Platform)经过10多年发展已经是非常成熟的框 ...

以下为文章全文：(本站微信公共账号:cartech8)

汽车零部件采购、销售通信录 填写你的培训需求，我们帮你找 招募汽车专业培训老师

观点
只要传统主机厂- 供应商的开发体系不变，使用AUTOSAR的现状就不会改变。传统主机厂（特别是欧洲的主机厂）和一些没有软件能力的主机厂会继续大规模使用。CP(Classic Platform)经过10多年发展已经是非常成熟的框架，经过了众多量产项目考验。模块的功能和API成熟度高。传统主机厂最喜欢对供应商开发的东西标准化。我甚至看到主机厂直接写ECU需求直接搬AUTOSAR Spec，比如网络管理。而且，我自认为AUTOSAR最重要的贡献就是，主机厂做通讯建模之后，导出某个节点ECU的CAN通讯矩阵，以ARAXML的格式。如果供应商用的AUTOSAR，工具链直接导入生成CAN通讯的代码。我认为国产替代还是非常有希望的。AUTOSAR CP并不是什么先进的框架。只是设计得非常复杂好像显得门槛很高。国产替代能大幅度降低成本。

能否不用AUTOSAR？

结论：可以，但是我认为要想学Tesla自研不用AUTOSAR, 有几个前提。1、必须自研多个控制器。我在多个场合说过，如果自研2个控制器以上，自己撸的框架比AUTOSAR从经济的角度合算。这是基于目前AUTOSAR供应商还是被国外厂商主导。2、自己的软件团队需要有足够的实力垂直集成/开发。如果你的软件团队只能开发应用层，最好尽快打消自研的念头。你Hold不住。下面给出我个人的推荐，参考AUTOSAR分层架构。一部分模块已经很成熟方案了，一部分模块需要自研。给出参考建议方便读者内部评估是否能自研。操作系统：这部分完全没必要自研。直接选用成熟的RTOS。你发现芯片厂商在发布新的芯片时都会预先集成常见的OS或者RTOS，并且提供驱动的参考设计。也就是说，如果你选用的RTOS比较常见，你后面连底层驱动改动都会非常少。比如一般芯片厂商会提供FreeRTOS的bring-up包括bootloader和所有常见外围的驱动等等。如果你是Safety系统，选用SafeRTOS，API和FreeRTOS兼容。这里我不是很明白，很多AUTOSAR厂商打包一个底层的OS给我，对我的好处在哪里？这些OS一般都是私有，按照这些OS的API反而把你绑在这个AUTOSAR厂商上。我认为：选择常见OS的非常重要。工程师的学习成本低，而且绝对比AUTOSAR厂商提供的那套东西更成熟。唯一我能想到的好处是，AUTOSAR供应商告诉你他的OS完全满足MISRA标准。顾虑：大部分RTOS没有满足MISRA C的要求开发（包括FreeRTOS和国产RThread）。我们的做法是对几个关键的文件我们自己做了符合MISRA的改动。底层驱动：这部分芯片厂商都会提供参考设计。直接拿过来在上面改就行了。难度很低。注意Safety系统需要Safety BSP，这点上我的建议是，自己有能力就自己开发Safety BSP。没有足够的能力就让Safety OS的厂商提供。我们是自己做一部分，Safety OS厂商提供一部分通用的，节省时间和验证成本。硬件抽象HAL层：需要自己开发，屏蔽底层硬件之间的差异性。这个设计上难度中等吧。我觉得比如RThread这部分做得还不错。总体来讲，就是使用函数指针来实现功能的多态。这算是C里的基操吧。一般高级工程师都能负责。协议栈：什么网络TCP/IP, AVB，DoIP这些。大部分时候都有成熟开源的协议栈。我们一般直接拿来用或者做少量修改。我的建议是，公司内部还是最好有人熟悉代码，即使有bug或者定制的需求可以自己做。这部分对工程师要求还是比较高的。比如我们使用的成熟开源框架：

LwIP来做以太网协议栈，LittleFS做文件系统，TinyUSB做USB协议栈。

2. Linux为主的域控制器使用的开源框架就更多了。这里都没法一一罗列。
我负责的网络团队把LwIP源代码完全吃透可以做任意修改。网上中文的源代码分析也很多。难度不大。提醒：我们对涉及到Safety部分的软件功能使用开源框架还是非常非常谨慎的。我个人建议Safety部分所有代码自己撸。再往上就是一系列基础服务了：诊断，功能安全Safety，信息安全，········等等。我们都是自己开发。诊断：DoCAN，DoIP，UDS模块都是自己写的。难度低。一个高级工程师带一个研究生几个月完成开发测试。完全满足ISO14229-1, ISO15765, ISO 13400-2要求。功能安全的模块难度相对高。这里能找到又懂功能安全又懂软件开发的工程师非常非常难。AUTOSAR根据26262推荐的所有Safety measure我们都自己实现了。前后耗时做了一年多。因为开发的难度本身也要大的多。信息安全：我们直接用的WolfSSL的Crypo+TLS模块。如果遇到芯片上带HSM（Hardware Security Module）,直接把WolfSSL 的某个Crypto API替换为硬件驱动就可以了。难度低。
最后讲麻烦一点的是：比如主机厂客户用V的那套工具做CAN通讯建模。扔给你ARXML通讯矩阵。你需要自己开发工具来解析ARXML，内部生成CAN通讯的代码。

工具链: 我们自研的工具链，
1. 生成CAN/以太网通讯代码，2. 生成服务的底层通讯代码。其他的建模我认为没有必要。