CP AUTOSAR PostBuild怎么用

shinch

目录
1. AUTOSAR的配置参数编译方式

2. PostBuild分类

3. Post-Build Loadable集成要点

4. SWC上的变体管理

5. 小结

---

1. AUTOSAR的配置参数编译方式

在CP AUTOSAR中提出了变体处理的概念，其实对应的就是配置参数在不同阶段参与编译，如下：

Pre-CompileTime：在这个阶段配置参数参与编译后就无法再改变了，常见的如宏定义，该方式可以有效缩减代码量，节省Flash空间。生成文件通常为：Cfg.c/h。LinkTime：为配置参数分配地址，处理symbol等工作。生成文件通常为：Lcfg.c/hPostBuildTime：在这个阶段参与编译的配置参数还可以进行修改，生成文件为：PBCfg.c/h

上述流程可以总结如下：

在PreBuild阶段，通常是系统常数、宏定义的处理；在Post Build阶段通常是对某些数据的重编程。那么为什么要提出对配置参数提出PreCompile、PostBuild这些属性呢？我举个例子，做过座舱的同学在做整车测试的时候最常刷的DID想必就是配置字了，这个配置字对应的就是同一车型的高中低配置。实际上，对于同样平台的车型来说，我们基本上都是复用同样的静态代码逻辑，只是通过刷写不同配置字来开启不同功能，这也和AUTOSAR提出的模块复用概念如出一辙，如下图：

上图中，白色部分是全平台通用，那么可以做成库或者静态代码复用；其他颜色是车型独有，可通过量产后重编程的方式来进行选择，那么具体如何实现的？我们今天就来看看。

---

2. PostBuild分类

虽然说现在CP AUTOSAR说明了不再使用Loadable和Selectable作为PostBuild属性，但是我认为这两个属性是对PostBuild最好的诠释。

Loadable：可以在编译好的程序里直接更新配置，不需要重新构建应用程序；Selectable：在ECU中存储多个可选配置。启动时，选择其中一个配置并将其用于BSW初始化。

上面我所提到的通过配置字来更新车型，就是用的Selectable类型，这种方式简单好用，通过诊断工具即可实现，但是需要额外的Flash空间；这个较为简单，今天就不聊了。主要聊聊Loadable的方式。Loadable可以节省空间，但需要考虑如何将PostBuild的配置数据生成hex，这部分数据通过Boot刷进Flash的注意事项等。

---

3. Post-Build Loadable集成要点

很明显，要实现配置数据可以更新，和标定数据管理一样，单独在链接文件中给这类属性的配置参数定义一块空间是非常重要的，如下图：

橙色部分是在工程构建完成后下载到Flash中，版本稳定了基本就不会再更新了；蓝色部分的初值与橙色部分一起下进Flash，但是可以在后续通过bootloader单独更新；因此Post-Build Flash\RAM的起始地址和长度是必须要进行配置的，如下：

此之外，在做工程配置时对于这类配置参数要选择Post-Build，例如 CanifTxPduCanId的属性就支持如下三种：


生成代码如下：

这就给我们提供了很好的思路。假设主机厂有需求不同平台使用通信矩阵的报文ID相同，信号不同；使用这种方式可极大减少工作量。

---

4.SWC上的变体管理

上面讲的基本都是BSW这一层级的，其实针对SWC应用层级，我们同样可以使用变体来进行管理。假设现在相同平台出了柴油版本和汽油版本的车型，本质上将除了控制策略上不同，基础平台完全可以不变。除了我们通过标定参数来选择，还可以用PostBuild Selectable的方式，当然在应用设计上就可以有如下考虑：

这样的设计我想到了，SIMULINK当然也想到了。它基于AUTOSAR Software Components提出了配置Postbuild Variant的设计。示例如下图：



上述模型使用AUTSOAR.parameter：rainSensor的值为条件，用于VAR1\2的选择。生成的Arxml如下：

代码如下：void Runnable_Step(void)
{
...
  /* Outputs for Atomic SubSystem: '<Root>/Variant Subsystem' */
  if (Rte_PbCon_mAutosarVariantSubsystem_c0()) {
...
  } else if (Rte_PbCon_mAutosarVariantSubsystem_c1()) {
...
  }
  /* End of Outputs for SubSystem: '<Root>/Variant Subsystem' */
...
}很明显，AUTOSAR SWC使用变体来根据定义的条件在执行路径中启用或禁用AUTOSAR相关接口或者具体实现。

---

5.小结

经过上面简单的分析，我们把PC\PB等属性搞得七七八八了，不过基于AUTOSAR规范的配置项的PC\PB还比较容易设计，涉及到Vendor自定义的，特别是MCAL里面的，如何来定义PC\PB，这确实需要仔细考量。

---

往期回顾：

1.汽车标定精选
汽车标定技术--标定概念详解
汽车标定技术--Bypass的前世今生
万字长文：汽车标定技术--XCP概述

2.AUTOSAR精选
AUTOSAR CryptoStack--CSM Job夹带了哪些私货
AUTOSAR 诊断栈分析(一)
AUTOSAR OS概述（一）

3.汽车网络安全精选
汽车信息安全--MCU启动常用密码算法
汽车网络安全方案需求分析
汽车信息安全--常见车规MCU安全启动方案
车载信息安全场景概述

4.汽车功能安全精选

5.汽车虚拟化精选

    汽车ECU虚拟化技术初探(一)

    汽车ECU虚拟化技术(二)--U2A虚拟化功能

6.杂七杂八

    Flash模拟EEPROM原理浅析

    征途漫漫:汽车MCU的国产替代往事

    车规MCU应用场景及国产替代进展