从自研角度看待Adaptive AUTOSAR

lixinfu

前言

Adaptive AUTOSAR（AP）是一种新的汽车软件框架，旨在满足现代汽车行业中不断增长的技术需求。随着汽车新四化的兴起，汽车变得越来越智能，对处理器的性能需求不断的增长。

Adaptive AUTOSAR通过灵活的软件配置、基于高性能计算和通信机制满足现代汽车电子电气架构需求。AP软件不同于MCU Classic AUTOSAR（CP）软件，开发模式更偏向于互联网后端开发，可通过JSON、XML、YAML等文件的配置变更快速实现不同的需求，无需进行代码编译，这点完全不同于传统CP软件必须将配置转换成C、C++、头文件，并且将这些文件进行再次编译的开发模式。

但是，目前Adaptive AUTOSAR在国内并没有很火，很多OEM尤其是新势力或者传统OEM的新品牌，选择在高性能计算机上自研软件，以满足客户应用程序动态部署、程序需求高端计算能力等需求。

Adaptive AUTOSAR

无论是否使用Adaptive AUTOSAR，整车采用统一的电子电气架构是必需的。为了提高开发效率、降低成本并支持创新、符合千人千面的需求，统一标准和保持灵活性是必要的。

很多OEM已不采用AP，如若不使用Adaptive AUTOSAR，采用自研的架构，我们可以从AP架构中汲取营养。

AP与CP相比，AP实时性要求有所降低，但是需要保证一定的功能安全、提高对高性能能力的处理支持。

CP和AP的差异如下所示：

AP基于服务，CP基于组件，那就意味着AP可动态，CP必须静态。

AP基于POSIX意味着兼容多操作系统，有大量的开源软件可供集成。CP基于AUTOSAR OS，几乎没有现成的开源库可以使用。

AP支持配置管理，即软件更新模块类似Linux的apt install命令。CP只能靠bootloader完成软件更新。

因此，AP和CP的架构统一需要被考虑，此处不仅仅是软件架构的统一，也是需求架构的统一，更是工具链架构的统一。

自研AP

我们先放一张CP、一张AP的架构图。





目前主流的架构形式是MCU侧普遍采用Classic AUTOSAR，SOC侧采用自研架构。

CP侧除了OS之外，重要的几个模块：各种Management例如ComM，CanSM，CanNm，EcuM，NvM。和自研AP侧隐式相关的软件模块有各类Com（含CDD相关的Com），各类Crypto协议栈，EcuM（主要是各类状态管理），RTE接口。和AP强相关的模块有TimeSync。

AP侧各类模块，除了各种Core Types。最基础的有三个模块：Execution Management、State Management、Platform Health Management。辅助模块有日志管理、Identify Access Management（IAM），这些辅助模块一般不和外界交互，只存在系统内部。

Persistency类比CP中的NvM Stack，目的均是存储数据。自研AP要重新适配开发此模块。

自研AP的Crypto Stack在算法层级和CP侧的Crypto保持兼容。Time Sync和CP侧的Time Sync保持兼容即可。

自研AP的诊断（Diagnosics）、网络管理（Network Management）、通信管理（Communication Management）相关的模块要么是汽车电子特色模块，要么和整车电子电气架构、通信矩阵强相关。必然需要考虑整层层级的需求、架构和模块的统一。

配置管理的相关内容我们单独列出，一般芯片原厂会给出解决方案。

自研AP的相关需求总结如下：

Execution Management（EM）、State Management（SM）、Platform Health Management（PHM）需要根据需求自行开发。

日志管理（LOG）和IAM需要单独开发，可选。

Persistency需要单独开发

Crypto需要适配

诊断、网络管理、通信管理相关的需和整车需求绑定开发。

配置管理单独讨论。

自研AP的开源软件

EM、SM和PHM几乎没有大型的开源软件可以参考，只能基于自身需求进行设计，但是需求可以参考Adaptive AUTOSAR相关规范，主要考虑信息安全与功能安全融合性考虑，以及其他开源模块的交互考量。此处必须要特别指出SM与MCU ECUM之间的交互需要被考虑到，PHM与自身功能安全相关考虑需要协同。

日志管理有大量的开源软件可以参考，比如说Log4Cpp，glog,boost.log，spdlog等等。如果是快速实现demo可以快速集成相关模块。

IAM是一个很有意思的模块，本质上就是分布式的权限管理系统，如果基于IDPS深度定制开发，这个模块更符合信息安全要求，也可以减少资源浪费。

Persistency也称持久化，如果不按照AP AUTOSAR相关需求开发，POSIX本身的相关功能就可以满足相关的需求，当然，也可以按照自身的需求定制化相关设计。这块内容开发与否，其实对最终的架构设计影响有限。

Crypto也称加密解密库，典型的开源软件代表就是OpenSSL，这个库可以满足几乎所有的加密解密需求。建议对这个库，对常用的算法进行二次封装，简化应用程序调用的逻辑。

诊断模块分为两部分，第一部分是DCM相关模块，第二部分是DEM相关模块。在开源世界有一些DCM有关的开源软件可以参考，但是受众比较小，各有的各的写法，诊断模块不需要适配MCU，仅仅需要支持SoC。不需要支持多端的适配，如果仅是为了满足需求，Dcm中的DSL,DSD，DSP相关分层结构无需适配，只需开发DSP以及时间参数相关的设计即可。此外，还需特别注意DoIP,CANTP等传输层相关代码也需要同步开发，开源世界均有相关参考。DEM模块开源较少，但是可以通过将相关信息转发给MCU的方式间接实现相关功能。

网络管理相关模块，即Nm，属于汽车电子专属模块，一般SoC侧用的不多，相关真实需求较少，属于重要但是不紧急的任务。

通信管理是最重要的任务，其实对于AUTOSAR可以下这样一个结论：AUTOSAR的核心就是通信模块的设计。

通信管理可以有不同的分类，如下图所示，



如果采用DDS或者SomeIP相关协议，FastDDS,CycloneDDS,vSomeIP相关开源软件是可以集成使用的。如若采用SoC内部通信，则可集成Iceoryx开源软件。如若使用RestFul相关接口，则可集成RPC相关开源代码，Google开源软件，你值得拥有。

此外，MCU-SoC通信，SoC异构核通信，SPI相关通信，必然需要自研一部分，做好相关的架构设计。

当然，还有一些其他的需求，例如车云通信采用HTTPS的开源代码libcurl，JSON相关开源代码：yyJson,FastJSON等等。

Adaptive AUTOSAR有一大部分的功能是工具开发，主要就是通信管理相关的开发，解析DBC，通信矩阵，ARXML，生成代码或者生成配置。自研AP也需要完成相关的功能。

配置管理的相关功能属于FOTA的范畴，定制化程度较高，但是也有相关的开源代码SwUpdate可以参考，此开源仓库包含了上位机的打包工具，下位机的刷新工具，功能强大，值得学习。此外，压缩解压缩工具tar有对应的libtar开源库可以集成。

总结

EM、SM、PHM与MCU之间的交互需要被考虑到，功能安全、信息安全相关的需求需要被囊括。

日志管理有开源代码可参考

IAM可深度定制

Persistency可后续再开发

OpenSSL可作为Crypto的替代

诊断、网络管理需自行开发

通信管理可自行根据需求定制化或者使用开源代码，例如FastDDS，Iceoryx等等

FOTA属于定制化的需求，可参考开源代码SwUpdate