车载基础软件——AUTOSAR CP技术发展趋势
我是穿拖鞋的汉子，魔都中一工程师。老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的人：
“
理解是很难的事情，也是几乎不可能实现的事情。没有人可以跨过自身的立场和对世界的认知去理解你，当你明白这一点，很多时候就不会那么愤怒了。快乐是不容易的，但不愤怒时可以尽力做到的。
”
Return to today's topic !
本文继续关于AUTOSAR CP内容进行讨论。
AUTOSAR CP 发展历史悠久，从诞生到现在已经有近20年的历史。本章节将从当前痛点分析角度来阐述 AUTOSAR CP存在的问题和未来发展趋势。AUTOSAR CP带来的优势和便利前文已经叙述了很多，但是它也不是完美的，在实际应用过程中也存在一些问题（当然任何事情都不是十全十美），下面将从五个方面分别阐述：
架构充分解耦导致标准和接口规范繁多
-> 架构充分解耦导致标准和接口规范繁多。不可否认 AUTOSAR CP的规范文档非常详尽，但正是两百多个多达几万页的标准文档让一些传统的嵌入式工程师望而止步（这个叫做知难而退）。同时 AUTOSAR CP提出了很多新概念，比如标定量通过描述文件进行描述；应用接口不通过传统全局变量的方式与底层软件交互，而是对接口进行描述定义通过 RTE 统一接口进行匹配等。AUTOSAR CP的软件开发理念和传统嵌入式工程师的认知偏差也是其普及率不高的原因之一。
工具链价格昂贵，国产研发之路任重而道远
-> 工具链价格昂贵，国产研发之路任重而道远。动辄几百上千万的软件使用授权费对OEM、Tier1 来说都是很大的研发投入。尽管国内已经有华为、普华基础软件、经纬恒润、东软睿驰、中汽创智等几家供应商开始布局工具链的开发，但国产工具链的研发推广之路依然任重而道远。关于业界最多的感受还是国外的稳定，但是贵的离谱。自己有幸在国产的AUTOSAR服务商工作过，国内对于AUTOSAR Solution，主要是用户较少，车规级软件不像手机之类，对实时性要求极高，现阶段单凭一个公司做各种压力测试、功能测试都无法全覆盖所有应用场景，特别是异常场景！
工具链之间兼容性差影响合作开发的灵活性
-> 工具链之间兼容性差影响合作开发的灵活性。在实际项目中并没有体现出AUTOSAR CP软件模块的复用性和独立性。由于各厂商对 AUTOSAR CP规范的理解并不完全一致，而且各厂商的工具也并不完全兼容，导致 OEM 集成各家供应商开发的软件模块需要花费大量的精力和时间。原本希望借助 AUTOSAR CP标准统一的优势合作开发，但是因为工具链的兼容性问题而不得不统一工具链的使用，严重限制了合作开发的灵活性。这个也是在指定规范之初没有想到的地方！！！
自动化程度低导致开发和集成效率偏低
->自动化程度低导致开发和集成效率偏低。基础软件与应用软件的接口集成需要大量的手动配置工作，不仅操作上低效出错率高，而且在错误检查方面也不如传统软件集成方便。对于某些错误提示往往不能快速定位错误原因，对于某些需求追加或变更往往不能快速对应。针对这一痛点，国内大部分OEM都已经开始使用自动化脚本工具直接操作 ARXML来代替这种重复性的工作。该软件体系，从需求定义到功能实现，都有偏系统的操作，关联性特别强，稍微出错一点，就是半天的纠错成本。
代码可读性差导致调试困难
-> 代码可读性差导致调试困难。这是代码生成工具普遍存在的问题，和 MATLAB 的 AUTOSAR 工具箱生成的代码一样，一些 AUTOSAR 工具链的RTE、OS代码生成工具生成的代码可读性也较差，这给软件调试带来了不少麻烦。例如在调试基于 SOMEIP 的服务通信时需要根据服务请求信号、提供信号的数据流向和函数调用关系，一层一层地查询才能理解整个通信过程。但是该软件体系是解耦的，比如自己以前在跟踪数据流时，想通过Debug（使用Trace 32劳特巴赫）单步调试，但是各个模块之间都有隔离，调试过程那酸爽，真不是一般语言可以形容的。
描述完毕，搁笔！
愿你我相信时间的力量，
做一个长期主义者！
页:
[1]