前言

最近面向服务的架构SOA经常被谈。AP AUTOSAR作为SOA这种设计思想的一种实现，成为汽车SOA落地时的一种不错的选择。


但是，计划采用AP AUTOSAR就意味要选择AP AUTOSAR工具链。本篇闲谈，跟大家分享一些AP AUTOSAR供应商不愿说的“坑点”（或者说应该从哪些角度考虑来选择AP AUTOSAR工具链）以协助大家更好地选择AP AUTOSAR工具链。


搞一下汽车电子也对全球20+ AP AUTOSAR供应商进行了调研，如果大家有兴趣，可以后台联系我们（免费）！


全系内容可在《搞一下汽车电子》后台回复 “系列”，或进入菜单栏 “分享平台” --> “系列分享”


本系列请点击：《搞一下闲谈》


所有系列请点击：《汽车电子系列分享》

一、ARXML设计工具的 “坑点”

基于AP AUTOSAR进行开发时，主要包括以下阶段：


建模阶段：制作ARXML
生成阶段：生成代码及Manifest
集成阶段：集成编译调试等


如下图所示：





在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写到 AP AUTOSAR的 ara::com 中。那么，类似于这种宣传材料都一堆技术问题的工具链能不能用来量产，敢不敢用去做量产，就交给各位朋友自己评估了。


考虑功能安全认证：


如果所开发的项目对功能安全有要求，我们需要考虑AP AUTOSAR工具链在功能安全认证方面的内容。（PS：分解到工具链上的，具体技术细节不探讨）


AP AUTOSAR供应商不一定会去做功能安全认证。
绝大部分AP AUTOSAR供应商都没有拿到AP 工具链的功能安全认证证书。
即使拿到了，可能也就是个QM级别（没啥用），都不是ASIL级别的。


考虑标准 API 是否开源：


在做项目开发时，上层应用程序需要调用AP AUTOSAR ARA中的 Foundation 部分的 FC 的 API 函数，这个时候，我们需要考虑这些API函数是否开源。


不是所有的AP AUTOSAR供应商都会开源自己的Standard API，如果不开源的话，我们就无法看到这些API的源码，对于后期集成调试来说，相对比较费劲！


考虑是否提供用户手册和 Demo：


用户手册的重要性不言而喻，不管是初期学习，还是后期开发，手册是非常重要的！而且，如果有视频demo的话，可以极大的降低前期的学习成本。


但是，不是所有的工具供应商都会提供手册。有些工具供应商是不提供用户手册的，这对于用户来说是一件非常痛苦的事情。能提供视频demo的公司可能就那么1、2家。


考虑国内工程师资源：


技术支持几乎是每个项目所必须的，作为国内的工程师来说，笔者认为，我们应当关注一下国内的工程师资源，以便评估这些供应商的国内工程师是否可以支持项目落地。（PS：老外就算了，时差语言等，导致沟通成本很高，沟通效率也差）


不是所有的供应商都有本地的AP AUTOSAR工程师！也就意味着，无法提供本地的技术支持！


考虑是否可以满足定制开发：


实际项目时，难免会碰到需要定制化的开发需求。比如，如果选定了某一版本的OS，这个时候，没有工具供应商适配此版本的OS，也就意味着，我们需要单独付费让供应商进行开发。这个时候就需要考虑供应商是否有能力开发。


能够做定制化开发的供应商不多！


考虑对 OS 的适配性：


由于项目需求，我们可能选择了一种OS，但是工具供应商不一定适配了你选择的OS。


所以，要问清楚工具供应商适配过哪些OS，以及具体适配的是哪个版本。比如：工具供应商适配了Ubuntu，不代表你选Ubuntu的版本，工具供应商有适配！

三、集成编译时的 “坑点”

在集成编译时，需要从以下方面对IDE进行考虑。


考虑提供的 IDE 是否有维护：


大多数工具供应商提供的IDE都是开源的，也就意味着IDE可能没有维护。如果做量产项目，且对功能安全有要求，建议选择一些有维护的IDE。


考虑提供的 IDE 编译代码的质量：


工具供应商如果提供的IDE是纯开源的，那么编译出来的代码质量可能不高！


考虑 IDE 是否包含代码分析：


工具供应商如果提供的IDE是纯开源的，那么可能要付费购买第三方的插件等。

四、Tier2承担的任务

根据AP AUTOSAR方法论，Tier2需要承担一些工作的。如开发Adaptive Platform Level的Application等。


考虑是否可以开发Platform-Level Application：


在开发项目时，需要考虑Tier2是否可以开发Platform-Level 的Application。这个可以由OEM指定由谁来开发，一般是工具供应商来开发。


笔者之前曾跟一些工具供应商的工程师交流过，比较可怕的是，这些工具供应商的工程师既然说没听过Platform-Level 的Application。不知道这些工具供应商的工程师能否提供好技术支持。当然，OEM如果说不需要Platform-Level的Application，那就另说了。


考虑与 Machine 开发相关的工作：


根据AP AUTOSAR方法论，与Machine开发相关的工作是与Tier2相关的。一般是工具供应商。


需要考虑工具供应商是否会承担相应的工作。


考虑集成开发时的人力：


在后期项目集成开发时，需要考虑项目需要的技术支持。


工具供应商不一定有足够的人力来支持集成开发。

五、其他方面

除了AP AUTOSAR工具链技术点之外，还需要考虑：


工具链的商业模式：


几乎所有的公司都具有至少两种 license 授权方式。到这里，建议大家一定要问清楚所有可能牵扯到的费用！


有的公司告诉你的价格看似很低，但是，小心这也是个坑。因为，这是评估版 license 或者开发版 license。


即使工具供应商告诉你是量产版 license，也要注意，因为这个价格可能是不带功能安全的价格，你要功能安全的版本，就需要再加钱。


即使工具供应商告诉你这个确实是所有工具的价格，但是，仍要小心。因为，只有一个AP AUTOSAR工具链可能是不够的。工具供应商还有其他产品等着你，比如什么自家改装的Linux OS，比如Secure Boot等等。而且，可能他们的工具只会适配自己改装的OS，你如果不选他们的OS，你就用不起来他们的AP工具链。一环套一环，环环相扣！


这个时候问题就来了，你用较低的价格拿到了AP AUTOSAR工具链，但是，后面还有其他的产品等着你，如果你不买其他的产品，那么你可能就无法量产。如果你买了，那么后面的这些产品可能费用很高。


这个时候，你要是选择买后续产品，后续产品的费用可能承担不起，要是不买，换其他家工具链，那么你之前的钱就算是白花了！


所以，强烈建议各位朋友，在购买工具链的时候，问清楚整个项目过程中，还可能有哪些产品是后期要用的，这些后期要用到的产品的商业模式及价格是多少！


其他方面的考虑：


除了AP AUTOSAR工具链之外，整个项目开发的过程中，我们还需要OS、BSP乃至Hypervisor等。对于这些部件，我们仍需要从以下几个方面进行考虑：


OS与AP的适配性问题：
OS不一定有工具供应商适配！


OS与AP的优化问题：
工具供应商不一定对OS进行过优化！


OS与Hypervisor的适配性问题：
OS与Hypervisor不一定适配！


OS与BSP适配性问题：
芯片厂商提供的BSP不一定与OS适配！


OS与芯片适配性问题：
OS不一定与所选的芯片适配！


OS是否有功能安全认证：
所选的OS不一定有过功能安全认证！曾有公司说使用他们改装的OS，可以到达ASIL-B。笔者认为，等他们拿到证书再信也不迟！


本期分享就到这里。如果大家有其他方面的点，也欢迎补充！

联系我们

微信：shactiontech
邮箱：support@shactiontech.com