Hello！大家好！
欢迎来到《搞一下汽车电子》
今天，我们给大家分享的是Adaptive AUTOSAR 专题视频：06 自动驾驶 & 域控中间件——自适应Adaptive AUTOSAR 中的坑
是视频加图文解说哦~~~ 如果觉得不错，“转发” “ 在看”支持一下吧~
点击链接观看视频 ↓ ↓ ↓ ↓ ↓
06 自动驾驶&域控中间件—— AP AUTOSAR中的坑_腾讯视频
点击链接获取PPT（提取码txhq） ↓ ↓ ↓ ↓ ↓
06 自动驾驶&域控中间件—自适应Adaptive AUTOSAR 中的坑
之前的视频中，我们给大家分享了AP VS CP AUTOSAR。在本期视频中，我们分享AP AUTOSAR 中的坑，这对于正在使用AP AUTOSAR或者即将使用AP AUTOSAR的朋友来说，是很重要的~
我们从三个方面进行分析：“ARA”，“OS”以及“Calibration”
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不能用，只要需要用到的模块工具供应商可以满足即可。
02 OS
与OS相关的坑如下图所示：
- 适配：
一个操作系统符合POSIX OS标准，不意味着有工具供应商会与该OS进行了适配。还有一个点：某些OS厂商会自己做一个工具，用来演示其OS可以与Adaptive AUTOSAR进行兼容，但并不意味着该工具可以支持量产。
据我们了解，某厂商的OS，没有工具供应商进行适配，虽然他们有自己的工具，但是，该工具能不能量产，需要打个问号。但是，这一点OS厂商不会提到。
所以，这里就有个坑，在选择OS的时候，一定要问清楚，是否有Adaptive AUTOSAR工具供应商与OS供应商的OS进行了适配。如果没有，那么选择该OS的时候，可能就无法使用Adaptive AUTOSAR。
- hypervisor：
在使用hyperivisor时，需要注意hypervisor支持的芯片、OS以及执行效率。该部分与 “OS等供应商” 有关。
据我们从一些圈内人士得到的消息，某厂的hypervisor执行效率低。所以，选择hypervisor的时候，需要注意执行效率的问题。
- 编译：
能编译出来代码，意味着代码质量高吗？不是。比如，使用Linux的时候，使用gcc、g++进行编译的时候，编译出来的代码质量就不高。
与该部分相关的供应商也是 “OS等供应商” 。在了解编译器的时候，需要调研清楚其编译器编译出的代码质量。不然，这会为以后带来调试等方面的一系列问题。
03 Calibration
- 方案1
在之前的视频中，我们给大家分享了一个实现标定的方案，如下图所示：
上图中，与File System App相关的是 “用户”。
与POSIX OS中相关的 “File System”相关的是 “OS供应商”。
如果大家对于该方案有兴趣的话，可以查看我们之前的 “How AP AUTOSAR” 视频。
- 方案2
除了上述方案外，使用现有的设备（如：INCA等）还有以下方案，如下图所示：
对上述方案进行说明如下：
1）在同一个芯片上即运行CP 又运行AP。
2）在芯片的Cortex-A 核上运行AP，在Cortex-M/R 核上运行CP
3）在CP端使用传统的方式实现标定
4）AP端通过S2S从CP端获取标定数据
5）因为是在同一个芯片上，即运行CP又运行AP，所以，需要用到hypervisor
上述方案中：
1）与标定相关的实现与 “用户” 有关。
2）S2S与 “工具供应商” 有关。但是，R19-03中，虽然有S2S模块，但是没有相关的标准，所以，如果使用R19-03，那么就不能使用上述标定方案。
3）R19-11中，没有S2S相关的模块，类似的模块为SignalPDU。需要注意的是，某些厂商不提供R19-11。
4）选择hypervisor时，需要注意其执行效率。
PS：上述方案可以基于现有标定工具（如INCA等）实现。
还有个问题，大家可能会问：AP与CP不在同一个芯片上该怎么办？一种办法是，通过Gateway进行（标定数据）通信。当然，使用Gateway时，也会存在一些问题。另一种方案如下所示。
- 方案3
还有一个方案如下图所示：
该方案直接在AP端实现标定，但是有个很大的坑是：
对设备有要求：需要标定工具支持some/ip
据我们了解，当前没有相关的工具支持通过some/ip的方式进行标定。
综上所述，一定要选择好相应的工具供应商！某些工具供应商存在很多坑，但是他们不会告诉我们。所以，一定要问清楚。
当然，我们也从上述方面对各大厂商的情况进行了调研，如果大家对于该调研报告有兴趣的话，可以随时发邮件 ([email protected]) 给我们哦，因为存在一些保密敏感的信息，所以我们通过邮件的方式进行分享哦~
好啦，本期分享到这里就结束啦，如果您对本期视频有什么问题，都可以发邮件给我们哦，我们下期视频再见~
如果觉得不错，“点赞” “分享”支持一下吧~