APAUTOSAR中的坑_新能源技术.docVIP

APAUTOSAR中的坑 01 ARA ARA是AUTOSAR Runtime for Adaptive applications，我们主要从ARA之上的Application及ARA方面说明分享存在的坑。 Application 在之前的视频中，我们提到，Adaptive AUTOSAR中，主要包含两种Application： 1）Application-Level的Application 2）Platform-Level的Application Application-Level的Application会生成源代码和目标代码，这部分与 “用户” 有关。 Platform-Level的Application会生成目标代码，这部分与 工具供应商 有关。 Platform-Level的Application是需要由工具供应商来提供。因此，这里有个坑，很多工具供应商不提供，但也不会告诉用户这个需要。所以，在调研工具供应商的时候，需要问清楚他们是否提供Platform-Level的Application。 据我们了解，某些厂商不提供哦~ ARA 与ARA相关的坑，如下图所示：  版本： 有些朋友会问：当前在使用R19-03，已经购买了部分模块，而且想用R19-11版本，那么，能否剩余模块使用R19-11，答案是不可以。 版本混杂使用会带来很多麻烦，举个简单的例子，R19-03与R19-11的通信模块就有几百处不同。所以，千万不要版本混杂使用，在项目确定前，要固定使用的版本。使用哪个版本取决于用户。 加密： 在Adaptive AUTOSAR中，可以使用软件加密，那么可否直接使用芯片的硬件加密，答案是不可以。与硬件加密相关的是 “工具供应商”?。 所以，如果计划使用硬件加密，要问清楚工具供应商是否提供相关的驱动包，据我们了解某些厂商当前不提供硬件加密的驱动包。 通信： 从之前的视频中，我们知道，在Adaptive AUTOSAR中，存在面向服务的通信方式DDS，RESTful，但是，这不意味着我们就可以直接使用DDS与RESTful。 能否使用DDS与RESTful取决于 “工具供应商”，据我们了解，当前几乎没有工具供应商支持DDS与RESTful。所以，要想使用DDS与RESTful还需要打个问号。问清楚工具供应商。 与ARA相关的坑，还有以下内容，如下图所示： 诊断： 诊断模块不可以直接使用，需要进行定制化开发，这部分也与 “工具供应商”有关。 据我们了解，某些厂商定制化的时间较长，所以，如果计划使用Adaptive AUTOSAR，请注意定制化的时间与项目节点。 S2S： S2S是指信号到服务的转换。当前，工具供应商主要适配的Adaptive AUTOSAR版本是R19-03，那么在R19-03中，能否使用信号到服务的转化呢？答案是不能。 虽然，R19-03中有S2S这个模块，但是没有相关的标准与元模型，因此，如果需要用到信号到服务的转换，那么，请注意使用的Adaptive AUTOSAR版本。如果，当前购买了R19-03的工具，那么这个坑可能无法绕过。 之所以在这里提到S2S，主要与后面分享的标定有关。如果需要使用S2S，建议从R19-11起步。据我们了解，某些厂商不提供R19-11版本的工具，直接跳过R19-11，提供R20-11的工具，这带来的问题就是，时间上会延迟2年左右的时间。 模块： 在使用Adaptive AUTOSAR时，需要根据项目情况，决定使用的模块。当然，也需要这些模块可以支持量产。 这部分也与 “工具供应商” 有关。但是，据我们了解，当前几乎没有工具供应商可以支持所有的模块。举个简单的例子，DDS该模块就很少有工具供应商提供。 当然，这并不意味着Adaptive AUTOSAR不能用，只要需要用到的模块工具供应商可以满足即可。 OS 与OS相关的坑如下图所示：  适配： 一个操作系统符合POSIX OS标准，不意味着有工具供应商会与该OS进行了适配。还有一个点：某些OS厂商会自己做一个工具，用来演示其OS可以与Adaptive AUTOSAR进行兼容，但并不意味着该工具可以支持量产。 据我们了解，某厂商的OS，没有工具供应商进行适配，虽然他们有自己的工具，但是，该工具能不能量产，需要打个问号。但是，这一点OS厂商不会提到。 所以，这里就有个坑，在选择OS的时候，一定要问清楚，是否有Adaptive AUTOSAR工具供应商与OS供应商的OS进行了适配。如果没有，那么选择该OS的时候，可能就无法使用Adaptive AUTOSAR。 hypervisor： 在使用hyperivisor时，需要注意hypervisor支持的芯片、OS以及执行效率。该部分与 “OS等供应商” 有关。 据我们从一些圈内人士得