APAUTOSAR供应商不愿说的“坑点”.docVIP

APAUTOSAR供应商不愿说的“坑点”  一、ARXML设计工具的 坑点 基于AP AUTOSAR进行开发时，主要包括以下阶段： 建模阶段：制作ARXML 生成阶段：生成代码及Manifest 集成阶段：集成编译调试等 如下图所示： 图 AP?开发流程概览 在ARXML设计时，主要包括以下几个方面的设计： Adaptive?Application Design Service Instance Design Platform Module Design Execution Design Machine Design Diagnostic Design ...... 如下图所示： 对ARXML设计工具应考虑以下几点内容： 考虑设计项的覆盖度： 工具供应商提供的ARXML设计工具不一定可以覆盖所有跟AP相关的设计项！ 需要问清楚工具供应商ARXML设计工具的覆盖度！ 考虑设计工具的数量： 只是AP ARXML设计，就可能会有多个工具。如：进行SOME/IP设计时是一个工具，进行Manifest设计时又是一个工具，进行诊断设计时又是一个工具。 所以，应当考虑设计工具的数量，以及上手的难易程度！ 考虑设计工具的易用性： 在进行ARXML设计时，有些工具是通过点选的方式来制作ARXML文件。有些工具则是通过书写文本来进行设计。 对于刚开始制作AP ARXML来说，会时常忘记该有哪些项要设计，如果是通过文本的形式来设计，那么上手成本相对来说会比较高！当然，对于已经熟悉了文本设计的朋友来说可以忽略。 考虑设计工具的兼容性： 虽然，ARXML是标准化的，但是也需要注意ARXML与 FC Code Manifest 生成器的适配性问题等。 考虑设计工具的版本： ARXML设计工具也是根据具体的一个AP AUTOSAR版本（如R19-11）进行开发的。当进行项目开发时，需要问清楚对应的AP AUTOSAR版本。 工具供应商提供的设计工具的版本，不一定能够满足项目的要求，如当前能提供R1911 ARXML设计工具的厂商非常少！ 有些公司甚至就不会开发R1911这个版本的工具链。想要R1911？对不起，臣妾做不到。 需要注意的是：ARXML设计工具的版本要与 FC Code Manifest 生成器的版本一致！ 二、Code Manifest 生成器等的?坑点 Code Manifest 生成器是AP AUTOSAR工具供应商的核心竞争点！在选择Code Manifest生成器时，要考虑以下几方面的内容： 考虑与ARXML设计工具的兼容性： 如上文提到的，我们需要考虑Code Manifest生成器与ARXML设计工具的兼容性！ A公司的ARXML设计工具，不一定会与B公司的生成器兼容！而且一定要考虑两种工具在版本上的兼容性！不要版本混合使用！ 考虑AP AUTOSAR版本： 在进行服务设计时，有一个 向后兼容的服务版本控制功能 是在R1911这个版本中进行解决的，这对于服务开发和Variant管理来说非常重要！ 所以，一定要根据项目需求选择合适的AP AUTOSAR版本。当前，绝大部分供应商是基于R1903开发的，甚至有些公司仍在基于R1810这个版本在开发。要根据项目情况来确认工具供应商提供的版本是否可以满足项目需求！ PS：基于R1911开发完所有模块的公司当前应该只有1家！如果大家还有知道其他的，欢迎与我们交流！ 考虑Roadmap时间： 很多AP AUTOSAR 工具供应商还在开发自己的工具，这个时候就需要考虑，工具供应商 Release 的时间，是否可以跟得上项目的节点！ 考虑 FC 的完善度： 即使AP AUTOSAR供应商是基于某个版本开发的工具，但是，他们也不一定会开发所有的FC，比如说，大多数公司都不会开发DDS、S2S等。 这也就意味着，在确定了版本后，我们可能永远用不了DDS、S2S等，因为工具供应商不会基于我们选择的版本开发这些模块。所以，一定要问清楚工具供应商哪些模块是不开发的！（使劲砸钱让他们开发的情况就不说了） 考虑 FC 的完成度： 前面提到，工具供应商有些模块压根就不会开发，除此之外，即使有些模块工具供应商决定开发，但是仍然没有开发完。 比如：状态管理，时间同步等模块，有很多公司仍在开发。笔者认为，像这种还在开发的就不要对外宣称说现在能用来量产版了，等开发完再说也不迟！但是，几乎所有的工具供应商即使没有开发完要开发的模块，也会说现在能用来量产！ 考虑是否可以用来量产： 有些公司即使开发出来了工具，但是也不一定可以用来量产。因为开发的模块不全！或者其他原因。在做量产项目时，需要考虑是否可以用来量产。 有些公司会对外宣传的非常好，但真的能用来量产吗？不见得！笔者曾看到过一些公司写的宣传材料，能把CAN写