汽车软件为何钟情Autosar工具链,手撸C不香了?

  

目录

  

往期推荐

1. 可行性

复杂性管理

标准化

2. 难度

开发人员技能门槛

调试和维护难度

3. 成本

时间成本

经济成本

4. 可控性

功能安全性

版本管理与配置管理

5. 相关利益方的需求

整车厂(OEM)

供应商

开发者

总结


往期推荐

  1. 2025汽车行业新宠:欧企都在用的工具软件
  2. 【AUTOSAR高效开发神器】Davinci AutomationInterface帮你!
  3. ETAS工具链自动化实战指南<一>
  4. ETAS工具链自动化实战指南<二>
  5. ETAS工具链自动化实战指南<三>
  6. AUTOSAR工程师必读:Artop的核心功能
  7. Vector工具链自动化实战指南<一>
  8. isolar高手秘籍| ECU Configuration三分钟速成!
  9. 掌握核心步骤:RTA-BSW以太网配置全解析
  10. 一文详解TC399 CAN MCAL 配置
  11. LSL常见应用场景及示例<一>
  12. LSL常见应用场景及示例<二>
  13. LSL常见应用场景及示例<三>
  14. 为什么Autosar钟情arxml而非json?大揭秘!
  15. 深入浅出:SOME/IP-SD的工作原理与应用
  16. 【技术进阶】|一文掌握Autosar ComStack的精髓!
  17. Autosar培训笔记整理<一>
  18. 【AutoSAR进阶】|实战详解ETAS工具链UDS 0x2f服务核心配置!
  19. 实战详解ETAS工具链CanTp模块自动化配置
  20. 一文掌握5种常见的AUTOSAR 错误类型
  21. 【AUTOSAR工程师必备知识】一文搞懂AUTOSAR架构9种通信方式
  22. 实战干货|详解ETAS工具链之 intra-ECU通信的数据转换

近期开会总听到客户抱怨道:"国内Autosar工具链缺乏统一的完整工具链生态,市场成熟度和可靠性还有待验证;国外Autosar工具链单个模块价格从数万美元到几十万美元不等,完整工具链(总成本可能超过百万人民币,价格贵不说,售后技术支持还少,真不如直接手撸C"。

其实这种抱怨在一些国内的汽车软件开发者中确实很常见,尤其是对于那些预算有限或者刚刚接触AUTOSAR的开发人员来说,国外工具链的高价格和复杂的学习曲线确实带来了不少压力。但是“手撸C代码真的一定优于使用现有的Autosar工具链吗?

图片

在汽车电子软件开发过程中,AUTOSAR工具链的重要性来自于其为复杂汽车系统开发提供的规范性、效率和质量保障。虽然个别的公司或个体工程师呼吁直接采用C语言手动coding亦可,实际上也就一说,实践中根本行不通, 当前Autosar已经成为事实上的汽车软件标准,是现实中多方长期博弈的结果,而且在可见的将来很难改变。本文从如下几个方面进行本质的原因剖析为什么Autosar在可见的时间内很难被替代:

1. 可行性

复杂性管理

现代汽车系统包含数十到上百个ECU(电子控制单元),这些ECU需要协同工作。AUTOSAR提供了标准化的架构和接口定义,通过分层设计(RTE、BSW、Application Layer)大幅降低开发复杂度。

  • 手工开发难以管理的规模:直接使用C语言需要开发者手动管理复杂的硬件抽象、内存映射和通信协议(如CAN、LIN、FlexRay、Ethernet),且极易出错,对开发工程师C语言要求极高,现实中可以说符合要求的人都很难招到。

  • AUTOSAR的需求抽象和规范:工具链生成的代码自动实现了底层硬件抽象和通信接口,使开发者可以专注于应用层逻辑,Autosar把汽车电子中常用的功能已经抽象总结为规范的接口,这些需求本身是汽车行业许多的领头企业数十年实践经验总结的结果,如果自己独立的去总结这些需求经验本身也是一个很大的挑战。

标准化

AUTOSAR提供了一套全球通用的标准,定义了模块接口、通信方式和配置方法,使开发者能够在不同的汽车制造商和供应商之间实现高效协作。

  • 可移植性:直接用C语言编写的软件往往依赖特定硬件、不同车型、不同供应商、不同的工程师编码水平,移植到新平台需要耗费大量精力,而AUTOSAR通过标准化的接口极大降低了移植成本。

  • 互操作性:标准化的协议和接口定义保证了不同供应商开发的软件模块可以无缝集成。屏蔽了车型差异、硬件平台差异、供应商差异、工程师水平差异,使得互操作性和质量得到稳定的保障。

2. 难度

开发人员技能门槛

  • 手工开发需求更高的专业技能:直接使用C语言开发需要开发者精通硬件架构、通信协议和实时操作系统(RTOS)的细节。市场上具备手动实现autosar规范同等功能的工程师数量非常稀少,作为一般的公司去规模化的培养这样水平的工程师代价极大,实践中由于利益关系不可能这么做。

  • AUTOSAR工具链的自动化:通过工具链生成底层代码(如OS配置、通信栈),开发者只需关注模块配置,大幅降低了技术门槛。实际上把这些底层细节的难度转移到工具链供应商,专业的人干专业的事,整体成本是最低的。

调试和维护难度

手工开发的代码在调试和维护时极为困难,尤其是涉及复杂的通信协议和任务调度时。而AUTOSAR工具链能够提供丰富的诊断功能(如故障码管理、诊断通信),大幅提升了调试效率。

3. 成本

时间成本

  • 直接C语言开发的时间更长:即便花费重金招聘到具备手动coding的团队,从头开发所有功能模块需要巨大的时间投入,包括通信协议栈、操作系统和硬件抽象层。

  • AUTOSAR工具链加速开发:工具链可自动生成代码,且模块化开发缩短了开发周期。

经济成本

虽然AUTOSAR工具链(如Vector DaVinci、EB tresos)初期投入成本较高,但其通过减少开发时间、提升开发质量,降低了长期的开发和维护成本。

直接用C语言开发可能在初期成本较低,但长期来看维护和修改成本会显著上升,甚至最终不可维护。

4. 可控性

功能安全性

AUTOSAR严格遵循ISO 26262标准,支持功能安全开发,通过工具链生成的代码能够自动满足安全要求(如ASIL等级),手工开发很难在不增加成本的情况下达到同样的安全性保障。

版本管理与配置管理

AUTOSAR工具链内置的配置管理功能支持高效的版本迭代。直接用C语言开发难以实现这种高效的配置管理,尤其是当多个供应商参与时,协同集成难度之大可想而知,大量的精力成本将会耗费在沟通和接口对齐上。

5. 相关利益方的需求

整车厂(OEM

整车厂需要确保供应商提供的软件模块可与其他模块无缝集成,AUTOSAR标准通过接口一致性和模块化设计满足了这一需求。手工开发难以保证模块化和接口一致性,极大的增加了整车厂的集成难度,将会大大增加软件开发成本。车厂的本质属性是硬件生产公司,软件的工作属性和硬件的工作属性有本质的不同、工作本身价值评估方式差异也很大,相关工程师的文化属性要求也差异巨大,车厂去管理一个大型纯软件团队是一个巨大的挑战,甚至不可能。

供应商

供应商通过AUTOSAR工具链能够快速开发和验证模块,提升竞争力。没有工具链,供应商需要开发更多非增值功能模块(如通信协议),浪费资源。实际上工具链供应商就是做软件的那帮人从车厂独立出来,同时也把纯软件的工作也分离出来进行高效率的管理,这种生产要素的分离管理是提升行业生产力的重要手段。

开发者

工具链提升了生产力,降低了开发者的重复劳动,尤其是底层模块开发(如OS、通信栈等)的工作量。作为大部分汽车软件开发者软件本身能力的门槛降低,更多专注于功能应用场景本身,而不是c语言实现细节,对于软件开发者的要求则侧重在实际场景的深刻理解和高效的变形应用。分工更明确整体效率也更高。   

总结

所以,如果你打算使用C语言进行手动coding替代autosar工具链方案,那么你想好了如何应对这些巨大的矛盾和利益冲突吗?从技术复杂性、开发效率和迭代周期、长期成本控制、功能安全性利益方协同需求,AUTOSAR工具链为现代汽车软件开发提供了一整套高效解决方案。而直接使用C语言开发虽然在简单系统中可能可行,但在复杂系统中会面临巨大的成本、技术和管理挑战。AUTOSAR工具链通过标准化和自动化,在开发复杂度、功能安全、协作效率等关键维度上显著优于传统C语言开发,从而成为现代汽车软件开发的首选方案。 

小编认为虽然手撸C代码对于一些简单的系统可能有效,但面对AUTOSAR复杂的模块化架构、功能需求以及对安全、可靠性的高标准要求时,手工编码无法与成熟的工具链相比。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值