汽车电子autosar系列50篇（四）-基于Vector的Autosar Postbuild

1引言

随着汽车电气化的程度越来越高，汽车中的ECU的数量保持着逐年上升趋势，ECU之间的交互目前大多基于CAN总线，同时CAN总线上传输的信号数量也是越来越多，并且普通CAN总线信号定义并无官方的标准（J1939协议除外，Sae J1939已经定义了总线上面的信号，该协议仅适用于商用车），当一个ECU去适配多个类似的ECU时，经常会遇到总线信号定义并非一致的问题。

传统的ECU软件开发在软件开发结束后无法修改CAN总线的信号定义，导致即使功能类似，仅仅是CAN信号的差异，也需要重新开发，导致针对变型软件的开发，维护，测试成本都很高，项目周期长。为解决变型开发中的这些问题， Autosar提出了Post-build的概念：可以允许在ECU的开发工作结束后对ECU的参数做出修改，以节省变型开发的成本。

本文针对基于Vector（Autosar软件供应商）的Autosar Post-build原理以及工作流程做出来详细的介绍与分析，相对于传统ECU开发的优势，以及需要注意的问题。

2 Autosar Post-build 介绍

2.1 什么是Autosar Post-build

2.1.1 Autosar 简介

AUTOSAR一一Auto motive Open System Architecture (汽车开放式系统架构) ，定义了一套支持分布式的，功能驱动的汽车电子软件开发方法和电子控制单元上的软件架构标准化方案，以便应用于不同的汽车和平台。

图1是Autosar的软件架构，分为三层，应用软件，运行时环境，基础软件。基础软件中包含了一些常用的模块，OS，故障管理，诊断服务，通讯服务等，另外非标准Autosar模块可以通过CDD模块来实现，本文讨论的Autosar Post-build主要是针对基础软件。

2.1.2 Autosar 配置类

Autosar 基础模块包含非常多的参数，其定义了三种配置参数类别：

2.1.2.1 Pre-compile time

Pre-compile time参数主要包含一些宏定义，主要用来使能/禁止一些可选的功能，提供选项优化可执行文件的大小或者性能等。

该类参数在代码生成阶段生成在*.cfg.h(宏定义等)/*.cfg.c(constant参数定义等)文件中;

该类参数由两点限制：

1. 由于该类参数多数是宏定义，所以要求模块的静态代码以源码形式提供；

2. 同样如果该类参数变更，需要重新编译模块。

以SPI模块为例：

在Spi_cfg.h文件中：

#define SPI_DEV_ERROR_DETECT ON

在Spi_cfg.c中：

const uint8 myconstant = 1U;

在Spi.c文件中：

#include "Spi_Cfg.h" /* for importing the configuration parameters */
extern const uint8 myconstant;
#if (SPI_DEV_ERROR_DETECT == ON)
Det_ReportError(Spi_ModuleId, 0U, 3U, SPI_E_PARAM_LENGTH); /* only one instance available */
  #endif

2.1.2.2 Link time

该类参数主要是在Link阶段才可以确定的，比如模块配置的call-back函数（定义在其他的源代码文件内）。

该类参数在代码生成阶段生成在*.lcfg.h()/*.lcfg.c文件中。

以Canif模块为例：

在Canif_lcfg.c文件：

CONST(CanIf_RxIndicationFctListType, CANIF_CONST) CanIf_RxIndicationFctList[] = 
{ 
   { CanTp_RxIndication }       , CanIf_AdvancedRxIndicationLayout 
};

在CanTP.c中：

FUNC(void, CANTP_CODE) CanTp_RxIndication(PduIdType RxPduId, P2CONST(PduInfoType, AUTOMATIC, CANTP_APPL_DATA) PduInfoPtr)
{
/* Cantp functionality */
}

2.1.2.3 Post-build time

该类参数主要适用于部分参数的结构是确定的，但是内容在ECU生产的时候是不确定的，或者参数很有可能在ECU生产之后做出改变等。

可以定义很多的变型，但是只有其中的一个变型可以在运行时使用。

Canif_pbcfg.c：

CONST(CanIf_PBConfigsType, CANIF_PBCFG) CanIf_PBConfig = 
{
  { /* Index: 0 Keys: [Config_Variant_1] */
      326121937L                               
    , CanIf_MailBoxConfigVariant_1 
    , NULL_PTR                                 
    , CanIf_RxPduConfigVariant_1 
    , CanIf_TxPduConfigVariant_1 
    , CanIf_UlTxPduId2InternalTxPduIdVariant_1 
    , 0x00040900uL                              
    , 181uL                                    
    , 0uL                                       
    , 103uL                                     
    , 78uL                                     
    , 78uL                                      
    , 0x0212u                                   
    , 0uL                                    
    , 0x3C1Eu                                  
  },
  { /* Index: 1 Keys: [Config_Variant_2] */
      326121937L                                
    , CanIf_MailBoxConfigVariant_2 
    , NULL_PTR                                  
    , CanIf_RxPduConfigVariant_2 
    , CanIf_TxPduConfigVariant_2 
    , CanIf_UlTxPduId2InternalTxPduIdVariant_2 
    , 0x00040900uL                              
    , 181uL                                    
    , 0uL                                       
    , 103uL                                     
    , 78uL                                      
    , 78uL                                      
    , 0x0212u                                  
    , 0uL                                       
    , 0x3C1Eu                                   
  }
};

在Ecum.c中

CanIf_Init(&(CanIf_PBConfig.Config_Variant_1));

2.1.3 Autosar Post-build 方案简介

为了提高ECU变型开发的灵活性，缩短变型开发的周期以降低成本，Autosar 定义了两种类型的Post-build 方案，一个项目可以同时使用一种，或者两种方案，也即Post-build loadable 和selectable时可以共存在一个ECU中的。

• Post-build selectable，同时为一个ECU配置多个变型的参数配置，生成包含多套不同参数的源文件代码，编译链接，同时软件集成时实现一个特定的策略，ECU根据该策略来选择其中一个变型。

• Post-build loadable，在ECU的开发结束后，OEM (整车制造商) 可以修改部分（Post-build time类参数）配置参数，生成一份只包含Post-build数据段部分的hex文件，通过bootloader等来更新参数，而无需零部件供应商的参与。

2.2 基于Vector的Autosar Post-build 原理分析

2.2.1 Post-build基础

Autosar 底层软件模块都需要提供一个xx_init()函数来完成初始化功能，这个初始化函数接受一个指针变量作为输入，以CAN driver模块为例，Autosar定义了如下需求SRS_Can_01042：The CAN Driver shall support dynamic selection of configuration sets[3]。

在该基础上，我们可以把基础软件模块的所有的参数打包到一个结构体里面，只需要使用不同的结构体指针传入初始化函数，即可使用不同的变型参数。

另外以Autosar的Can_init函数为例，Autosar有明确定义（图3），Autosar要求该初始化函数需要一个传入指针参数，这个指针指向模块的参数结构体Can_ConfigType，而具体这个结构体的定义是厂商自定义的（图4）。在Autosar C implementation Rules文档中，对单个模块，ECUM (ECU state manager) 基于Post-build的实现提出了一些建议，但是Autosar通常只定义接口，不规定具体实现，我们以Vector的实现为例来具体分析Post-build的原理。

2.2.1 地址分配

为了使Post-build数据可以单独更新，Post-build的Rom/Ram数据必须分配到一个独立的地址空间上，和其他的应用软件分开，考虑到在Post-build阶段可能的新增配置项，所以需要有一定的预留空间才可以。

Post-build RAM/ROM的起始地址需要在Vector的Configurator里面配置，在编译链接时已经是明确的，通常工具里面配置的和软件编译链接时的是使用的一样的地址范围。

2.2.2 数据更新策略

Vector定义了两种更新策略，由于通常的ECU ROM资源非常有限，一般选择第一种“Global update”策略，因为该模式可以节省ROM的空间使用。

1. Global update：

所有的BSW模块使用同一段Post-build数据段，Post-build时所有的BSW模块需要一起生成新的Post-build数据，即使部分模块并未修改，好处是只需要保证这一个Post-build段时可单独擦写的即可，节省ROM空间。

1. Module Individual Update:

每个BSW模块有自己的独立的地址空间，因为考虑到可能新增配置操作，所以需要预留空间，造成ROM资源的浪费。

并且为了保证了每个模块的单独可擦写，需要为其分配独立的Flash逻辑块，而Flash的逻辑块的大小是相对固定的，8/32/64/128/256/512Kb，会导致更多的Flash资源浪费。

2.2.3 全局更新数据结构描述

图6是全局更新数据方式的数据存储结构示意图，该例子包含两个变型(selectable)。其特点如下：

1. ECUM配置结构体位于Post-build ROM的起始地址，且地址在Post-build阶段一般是不可变更的，该结构体的成员包含其他模块配置结构体的地址引用，在Post-build阶段更新模块参数后，ECUM配置结构体中的地址引用信息会根据实际情况更新，其他基础模块使用该地址来初始化；

2. 其他模块（A,B等）的配置结构体的位置是可以变化的；

3. 每个变型的参数都会存储在ECU的ROM空间内，作为一个独立的结构体存在，所以增加变型会增加ECU的ROM资源的消耗；

4. 多个变型公用同一块RAM空间，分配的是最大的一个变型需要的空间；

3 Vector Post-build工作流程

一个典型的没有Post-build的ECU开发基本流程如下（步骤1/4/5可以是并行的）：

1. 根据OEM的系统需求创建Davinci工程(.dpa)；

2. 根据OEM需求配置BSW模块；

3. 生成所有BSW模块的配置源代码；

4. 根据应用需求生成或者手写应用层软件；

5. 根据需求配置RTE并生成相关的源代码；

6. 编译链接所有的源代码得到可执行文件；

7. 测试并确认ECU满足OEM的需求；

8. 生产ECU后释放给OEM；

增加Post-build的支持需要额外的步骤相对于上面的开发，具体的工作流程如图7，可见，左边是零部件供应商的工作，右边是OEM的工作，下面主要针对这两部分的工作流程做出具体分析。

3.1 Post-build 零部件供应商工作

如下的步骤仅关注在支持Post-build的ECU开发的差异点：

3.1.1 需求分析确认

在项目前期零部件供应商需要和OEM一起定义Post-build的具体参数：

1. 是否支持变型（selectable），以及变型之间的差异；

2. 变型之间切换的策略；

3. 是否支持Post-build loadable，具体哪些参数需要在Post-build阶段进行修改；

4. Post-build数据的更新策略，Bootloader，UDS服务或者其他方式；

主要需要关注的问题点如下：

1. ECU的资源分配情况，由于selectable会增加ECU ROM资源的消耗，越多的变型，使用越多的ROM，需要根据ECU的资源以及客户的需求做出一定的协调；

2. 并非所有的Autosar 配置参数都可在Post-build阶段修改，所以需要和客户明确具体的需求，以确保不会在Post-build时才发现部分参数无法修改，具体哪些参数可以修改需要参考Autosar标准文档以及Autosar供应商的文档，以Autosar文档为例，Valeo Configuration Class中的Post-build-time，需要标注为X，且为“VARIANT-POST-BUILD”，改参数才是可以在post-build阶段修改的。

3.1.2 基础模块参数配置

1. 根据前期的需求分析，selectable涉及的模块需要选择“Postbuild-Selectable Support”，loadable涉及的模块需要在Implementation Variant中选择“VARIANT-POST-BUILD-LOADABLE”；

1. 对于selectable，需要根据需求创建变型，配置每一个变型的参数；

2. 对于loadable，还需要在ECUC模块中指定Post-build的地址信息，同样的信息需要设置在项目的链接脚本中；

3.1.3 软件集成

支持Post-build的Autosar集成需要如下的额外方法：

1. 链接脚本/地址分配

Linker（链接）脚本控制编译器的链接，需要一个单独的可擦写的ROM地址空间来存放Post-build的配置数据信息，该信息和在配置工具中配置的是一致的；

1. Memory mapping

变量在链接的时候需要被链接到一个合适的链接器的输出段中（output section）， 由于嵌入式软件使用的编译器种类繁多，每个编译器的命令格式又有很大差别，为了方便一个模块可以灵活运用于多个MCU，以及多个编译器，Autosar引入了memory mapping的概念，每一个模块都有一个{模块名前缀}_MemMap.h，用于控制模块变量，函数等的地址分配。

需要额外支持处理的section有：

• SEC_PBCFG

• SEC_PBCFG_GLOBALROOT

• SEC_VAR_PBCFG

需要注意点为：

1. SEC_PBCFG_GLOBALROOT 必须在SEC_PBCFG的前面；

2. SEC_PBCFG_GLOBALROOT 必须在Post-build的ROM地址的最前端，以保证每次生成时地址不变，且不造成浪费；

3. 回调函数实现

Autosar 的Ecum模块的EcuM_DeterminePbConfiguration()函数用来更新EcuM_GlobalPBConfig_Ptr，该函数由软件集成开发者根据3.1.1中定义的变型切换策略来实现，该指针用来获取其他模块的配置结构体地址。

3.1.4 软件测试

除了常规的基于客户需求的软件测试，在释放软件给客户前，还要按照Post-build的工作流程，修改相关的参数，并生成hex文件，更新ECU，并验证修改参数涉及的功能，以保证Post-build阶段OEM可以顺利进行。

3.1.5 软件释放

普通的ECU开发，供应商释放给客户的输出为：ECU硬件（ECU软件已经在生产时已经更新在ECU的硬件里面），而支持Post-build的项目供应商需要释放额外的产物给客户：

1. 切换到post-build 阶段的Davinci 配置工程（.dpa, .xml）;

2. Davinci 配置工具;

3. Autosar BSW模块静态代码（.h）;

Post-build OEM工作流程

对于不支持Post-build功能的ECU项目，工作基本在零部件供应商处完成，OEM收到的即为可用的ECU，无需做额外的开发工作。支持Post-build的ECU，OEM在需要根据最新的需求来进行Post-build工作，修改基础模块的参数，生成配置源代码，生成hex文件，更新并针对新的改动做相关的测试，以保证Post-build的修改是正确的。

3.2.1修改BSW模块参数，生成源码

根据新的需求，修改对应的模块的对应的参数，

3.2.3 生成hex文件，更新

Post-build Hex文件的生成可由Vector提供的工具来完成，通常由零部件供应商通过Vector Davinci的external generator 来实现以简化OEM的工作，并且也可以保证双方操作的一致性，具体可参考Vector文档Startup_Vector_SLP4.pdf，章节2.2.1 External Generation Steps。

1. 生成xml文件

Vector提供PostBuildXmlGen.exe的输入为*.pbcfg.c，输出为一个Xml文件，典型用法如下，具体使用可参阅Vector文档TechnicalReference_PostBuildXmlGenerator.pdf。

需要注意的是，所有使能了Post-build selectable的模块均需要作为参数输入给该工具，即使该模块并没有任何参数变化。

1. 生成hex文件

使用Vector提供的PostBuildHexFileGenerator.exe可以把上一步生成的xml文件，转化为可烧录到ECU的Hex文件。典型用法如下，具体使用可参阅Vector技术文档TechnicalReference_PostBuildHexFileGenerator.pdf

ECU更新Post-build的数据的手段由很多中，Boot loader，UDS服务等等，需要零部件供应商和OEM一起协商一致，常规选择为使用Bootloader单独更新Post-build数据区域。

3.2.5 测试ECU功能

和普通的ECU配置开发工作一样，Post-build变更也需要测试来验证配置是否符合需求，具体测试项也需要根据改动来具体定义。

以CAN 消息的配置为例，如果在Post-build阶段修改了CAN消息的ID，周期等参数，最起码需要保证这些变更的参数是要经过测试的，实际中还需要评估该改动对系统其他的功能的影响，复测对应项目。

结束语

目前随着汽车电气化程度越来越高，以及汽车配置越来越丰富，变型开发的开发周期以及成本问题也会越来越显著。本文针对Autosar Post-build的原理以及工作流程，以及对比常规ECU项目的开发的差异进行归纳总结，以期对其他项目有一定的指导作用。