AUTOSAR BSW标准解读 – NvM

NvM的全称是NVRAM Manager。NVRAM是用来保存NV(Non Volatile,非易失)数据的,所谓的非易失数据指的是那些在掉电以后不会丢失的数据,而NvM模块是用来提供Nv数据管理的,用来维护NV数据。

满足AUTOSAR标准的NVRAM内存结构如下图,从这张图,我们能够比较清晰的看到AUTOSAR的NvM设计逻辑:
NvM_Mem_Structure

NvM的数据存储结构

NvM中的的数据承载是以块(Block)出现的,总共有四种类型的数据块,又可以称为基础存储对象(Basic Storage Objects),他们分别是:
1. NV Block:这种类型的块必须要有的,它存储了非易失的数据,对于NvM是可见的,对于应用程序不可见;
1. RAM Block:这种类型的块用于应用程序访问数据,它又分为permanent和temporary两种,两者的区别是,permanent类型的RAM在调用NvM读取接口的时候(readall,readblock)会自动的将NV Block里边的数据读取到permanent RAM block,而temporary类型的RAM必须作为readblock接口的参数,在readblock调用的时候会被填充,对于应用程序和NvM均为可见;
1. ROM Block:这种类型的块提供了数据的默认值,是可选的,对于NvM可见,对于应用程序不可见;
1. Administrative Block:这种类型的块用于提供NvM数据管理用到的信息,对于NvM可见,对应用程序是不可见的。

每一种块的结构可以参考下面三张图,对于Admin Block,与具体的NvM实现相关,AUTOSAR并没有规定它的具体结构:
NvM_Nv_Block
NvM_RAM_Block
NvM_ROM_Block

值得注意的是,以上提到的Block的概念是NvM中的概念,是抽象出来的和具体实现无关,大家不要和普通的RAM/ROM以及FLASH/RAM/DLFASH/EEPROM等概念混淆。下边这个实现样例表格可以帮助大家加深一些理解:

NvM Block 在EEPROM上的物理实现(无论外部内部) 在DFLASH/PFLASH上的物理实现
1个NV Block 在EEPROM上的一段地址区间 RAM上的一段地址区间+FLASH上的一段地址区间
1个RAM Block RAM上的一段地址区间 RAM上的另外一端地址区间
1个ROM Block EEPROM上的另一端地址区间(不会被NvM写,只会读) FLASH上的另外一块地址区间

NvM的寻址方式

NvM模块为程序运行提供了数据管理,因此很多模块会和NvM有交互,跟NvM交互的模块有RTE,DEM,EcuM,DET,MemIf,SchM,CRC Library。

为了实现存储管理NvM需要对FLASH或者EEPROM进行操作,这种操作并不是直接进行的,而是通过MemIf模块,MemIf模块把位于它下面的FLASH或者EEPROM抽象成线性的32位地址空间(包含了16位的逻辑块编号和16位的逻辑块内地址偏移),这个规定决定了NvM允许的最大逻辑块数为65536块,而每一块的大小为64K。 而逻辑块编号又可以分成两部分(块标识和dataset标识),这两部分的长度是可以通过NvMDatasetSelectionBits来配置的,它代表了dataset标识符的长度,出去dataset标识符部分就是块标识符了,dataset标识符最长为8个bit(最多256个datasets)。下边可以通过简单的一个示例图直观的看出这个概念:
NvM_Addressing

NvM的逻辑数据块管理类型

NvM的逻辑块有三种类型:

  1. NVM_BLOCK_NATIVE:包含1个NV Block,1个RAM Block,0到1个ROM Block,1个Admin Block。最简单的NvM类型,效率最高
  2. NVM_BLOCK_REDUNDANT:包含2个NV Block,1个RAM Block,0到1个ROM Block,1个Admin Block。比NATIVE类型具有更高的稳定性和容错能力,使用两个NV Block能够在一个NV Block失效的情况下从另外一个NV Block读取数据。
  3. NVM_BLOCK_DATASET:包含1到255个NV Block,1个RAM Block,0到n个ROM Block,1个Admin Block。

NvM模块提供了相应的接口函数管理逻辑块,为了能够使NvM更广泛的应用到汽车领域,根据不同的硬件资源,这些API可以被裁减使用,这种裁减分类三类:

  1. Class3 – 所有API都是支持的
  2. Class2 – 中等程度支持
  3. Class1 – 简单程度支持,这种裁减下,NVM_BLOCK_DATASET是不支持的

具体对应的的API列表在规范中可以查到,这里就不列出来了。

汽车软件工程师都应该学一点Python

从开始入门python,到现在已经有快7个年头了,在这些年中,我一直在中重度的使用Python,基本上需要在PC机上编程解决的问题,我第一时间总会选择Python,小到文本处理脚本,大到GUI界面/Web界面,可以说Python解决另外我工作中遇到的很多难题,也很大程度提高了工作效率,我也很希望大家都能够从Python中获益。。

虽然可能有些读者已经对Python有过接触或者了解,我这里还是简单的介绍一下这门语言。

首先,Python是一门解释性语言(所谓解释性语言就是,不需要编译器就行编译,由解释器对源代码进行解释执行),它是由Guido van Rossum于1989年发明的,是纯粹的自由软件,它的解释器基本上都是开源的,也就意味着不需要什么使用成本。

然后,Python是一种面向对象的编程语言,在Python里边一切都是对象,在加上Pytohn要求编程的时候强制缩进,从而导致使用Python写出来的代码都非常整洁。

最后,Python是一门胶水语言,所谓胶水语言就是能够方便快速的调用其他语言模块,而Python在开源社区非常受欢迎,从而导致有非常丰富的第三方软件库可以使用(这也是为什么Python能提高我们工作效率,解决我们遇到问题的主要原因)。

那么对于我们汽车嵌入式软件工程师来说,Python能给我们带来什么呢。

  1. 嵌入式软件中的文本处理和分析。S19/Hex/Bin文件的分析和处理,Cross Compiler编译结果分析(例如MAP文件处理,Log文件处理等),CAN消息分析,A2L文件地址升级(根据MAP文件或者ELF文件)。
  2. 利用Python做测试。Python可以方便的调用其它语言的库文件,因此可以控制PC来实现测试目的,最典型的如调用CAN驱动实现CAN消息收发,调用COM口实现串口收发(可以模拟KW,LIN)等。
  3. AUTOSAR ARXML文件处理。随着AUTOSAR的逐渐普及,我们跟ARXML文件交互的机会越来越多,Python可以让ARXML文件操作变得异常简单。
  4. 编译系统。Scons是基于Python的一个编译系统框架,虽然说不如Makefile那么简单直接,但是如果不想再学习Makefile的晦涩语法的话,Scons也是一个选择
  5. 科学计算。
  6. 自动代码生成。

以上的这些强大的功能都可以借由Pytohn的开源库来实现,最后我这边总结一下常用的一些Python库供大家学习参考:

  1. 文本处理: re(正则表达式),binascii,bincopy(S19/Hex/Bin文件处理),pyelftools(ELF文件处理)
  2. 硬件交互:基本上PC端的硬件设备都是通过DLL向外提供API服务的,Python可以通过ctypes简单的访问这些DLL,甚至更高级一点的可以通过IronPython来访问COM组件/.NET组件
  3. ARXML文件处理:ARXML文件说白了就是基于AUTOSAR XML Schema的XML文件,Python中有很多对XML处理的库,我这里推荐BeautifulSoup和generateds,前一个用于ARXML文件的读取和标签查找,后一个可以生成标准的ARXML文件
  4. 编译系统,我们前边已经提到了Scons这个库
  5. 科学计算,我没有做过很深入的,NumPy,SciPy,Matplotlib似乎性能上很不错
  6. 自动代码生成,Mako是一个模板库,可以根据模板自动生成输入文件

Python语言有两个分支2.x和3.x,大家不要以为3.x是对2.x的简单的升级,其实从2.x到3.x有着重大的改变,以至于语法上都有很多不兼容,目前主流的库都在2.x上有支持,在3.x上支持较少,因此建议大家还是从2.x最新版本开始学习和使用。Python的解释器可以在http://www.python.org 上下载,Python的入门文档我这边推荐两本免费的书籍A Byte of Pythondive into python,网上可以下载到PDF。Python语言非常简单易懂,作为一种高级语言,它比C语言更接近自然语言,从我个人经验,一到两周的时间就可以完成入门,接下来就是实际应用中体验Python带来的高效了。

从软件构架看符合AUTOSAR标准的软件 Part 2 – 软件接口

这是从《软件构架看符合AUTOSAR标准的软件》的第二篇文章,在这篇文章中,我们来讨论一下软件构架的另一个体现软件接口。AUTOSAR对软件的接口进行了合理的分类和定义,在标准化的前提下实现了最大限度的可扩展性和可移植性,从而为AUTOSAR应用于整个汽车系统而不是某个汽车ECU提供了基础。那么AUTOTSAR对软件接口究竟是怎么定义的呢,我们再来看一下下边这张经典的图。

AUTOSAR_Architecture

从图中我们可以看到,有三种接口描述,我们先从定义的角度来看这三种接口有什么不同。

  1. Standardized Interface(标准接口):“标准接口是在AUTOSAR标准中被标准化的接口,但是并没有使用AUTOSAR接口技术,标准接口通常被用在某个ECU内部的软件模块之间的通讯,不能用于网络通讯”
  2. Standardized AUTOSAR Interface(标准AUTOSAR接口):“标准AUTOSAR接口是在AUTOSAR标准中使用AUTOSAR接口技术标准化的接口,这样的接口的语法和语义都被规定好了,这样的接口通常使用在AUTOSAR服务中,这样的接口是基础软件服务提供给应用程序的”
  3. AUTOSAR Interface(AUTOSAR接口):“AUTOSAR接口定义了软件模块和BSW模块(仅仅是IO抽象和复杂驱动)之间交互的方式,AUTOSAR接口是以port的形式出现的,AUTOSAR将ECU内部的通讯和网络通讯使用的接口进行了统一”

从上边的定义中我们可以看出不同的接口使用的场景不同,及不同的模块交互会使用到不同的接口。除了将接口归类以外,这样定义究竟有什么实际的意义呢?从实际使用的角度来看,第一和第二类接口都是语法语义标准化的接口,即接口函数的数量/函数的名字/函数参数名字及数量/函数的功能/函数的返回值都已经在标准里边定义好了,不同的公司的软件在实施这些接口的时候虽然内容算法不同,但是它们长相和功能是一致的,接口定义在AUTOSAR规范文档里边是可以查得到的。第三类接口呢AUTOSAR仅仅规定了简单的命名规则,这类接口高度的和应用相关,比如BCU控制大灯打开的接口可以是Rte_Call_RPort_BeamLight_SetDigOut也可以是Rte_Call_RPort_HeaderLight_Output,公司可以自己定义,又比如仪表想要从CAN总线上获得车速,改接口可以是Rte_IRead_RE_Test_RPort_Speed_uint8也可以是Rte_IRead_Test_RE_RPort_Spd_uint8,这些接口必须通过RTE交互。刚刚提到的这些RTE命名规则在AUTOSAR中有详细的介绍,我们后续也会针对RTE这个AUTOSAR的核心软件层有详细的分析。

AUTOSAR BSW标准解读 – BswM

BswM模块全称是BSW Mode Manager,这个模块有两个任务:

  1. 模式仲裁(Mode Arbitration):指的是通过仲裁规则/SWC的请求/其他BSW模块的请求来发起模式切换
  2. 模式控制(Mode Control):指的是通过执行动作列表(Action List)里边的动作实现模式切换

BswM模块是一个模式管理模块,它的行为完全由配置来决定和实现。BswM模块不要求对其他BSW模块制定的动作的返回值存储或者作出反应(但是错误返回值E_NOT_OK可以触发DEM事件或者触发动作列表执行取消),因此其他的状态管理模块的状态可以用作BswM的仲裁输入。模式仲裁和模式控制各司其职,模式仲裁以后如果确认要进行模式切换,那么模式控制就会执行定义好的这个模式切换需要执行的动作列表里边的动作(可以是动作,也可以是另外的动作列表)。

下边我们来分别看一下AUTOSAR里边对模式仲裁和模式控制都有哪些规定:

1. 模式仲裁
实现模式仲裁的基础是规则(Rules),规则由一系列的模式请求条件通过逻辑关系组合起来,规则是根据不同的需求配置的(也就是做AUTOSAR里边没有定义具体的规则是什么)。模式切换条件可以通过AND/OR/XOR/NAND来组合起来形成规则,而其中的每一个切换条件都可以设置是等于的时候满足还是不等于的时候满足。在BswM的实现中,规则会在下边三种情况下被检查:

  • 输入模式切换请求(来自SWC),即SWC通过调用BswM提供的模式切换函数(当然会通过RTE,最终会调用到AUTOSAR标准接口BswM_RequestMode来请求模式切换),BswM模式仲裁机制会根据当前已有的请求,以及当前请求的类型选择立即仲裁或者是推后仲裁。

  • 模式标识改变(来自其他BSW模块,比如EcuM,WdgM等),其他BswM模块来请求一个模式的仲裁。

  • BswM主函数,相当于BswM模块的周期任务,在主函数里会有周期性的模式仲裁,它一般用来处理被推后仲裁的请求。

我们上边已经提到一个概念:立即仲裁(Immediate)和推后仲裁(Deferred),这叫模式仲裁的执行方式,除了规则检查加执行方式和起来构成了模式仲裁机制。我们上文中也有提到,立即仲裁指的是在模式切换请求发生的时候就进行模式仲裁,而推后仲裁指的是将当前的请求放到仲裁队列中,在BswM主函数中进行仲裁。

下边我们来看这张图,模式仲裁最终的结果就是规则检查的结果,简单来说就是规则满足(True)和规则不满足(Flase),定义规则的同时会同时定义这个规则满足时执行动作列表或者规则不满足时执行动作列表,或者两者都执行(一般来说是两个不同的动作列表),然后模式控制就会去执行绑定的动作列表。:
BswM_ModeAbitration

BswM模式仲裁中以上的这些都是可以配置的。

2.模式控制
模式控制是根据模式仲裁的结果执行相应的动作列表,动作列表(Action List)是一系列按顺序排列的动作(Action)
动作列表中的动作有三类(参考下图):

  • 调用其他的BSW模块或者调用RTE

  • 连接到其他的动作列表

  • 模式仲裁规则,这些规则将在对应的动作列表执行的时候被检查和评估

BswM_ModeControl

我们来看一个模式控制的信息交互路径示例:
BswM_ModeControl_Process

SWC发出模式切换请求给模式仲裁,然后仲裁结果被传给模式控制,然后模式控制根据结果执行相应的动作列表,动作列表执行完毕后,BswM模块可以通知请求发出的SWC和使用到这个模式的SWC模式切换完毕。

动作列表的执行有两种方式:

  • 每一次规则在被检查的时候,都会根据设定的期望结果来执行,称为条件执行(condition)

  • 当规则的检查结果跟上次规则检查的结果不同的时候才会执行,称为触发执行(Trigger)

为了简化ECU的配置和BswM模块的设计以及代码的生成,AUTOSAR预定义了一些动作列表:

  • ComM – 设置一个通讯接口的通讯模式
  • ComM – 限制通讯模式
  • ComM – 使能一个ComM通道的通讯
  • LinSm – 设置LIN调度表
  • FlexRay – 切换到“All Slot Mode”
  • COM – 激活和停用PDU Group
  • COM – 使能或禁用截至时间超时监控
  • COM – 触发I-PDU发送
  • EcuM – 设置ECU模式
  • EcuM – 关闭运行请求
  • Network Management – 使能或禁用网络管理通讯
  • PduR – 使用或禁用PDU Routing Path
  • RTE和BSW调度器的模式切换

3.BswM上的接口(端口类型)和端口

BswM的端口在RTE上边和下边都有,每个使用到BswM服务的SWC都需要创建相应的端口,这些接口都具有相同的接口类型,都会被连到BswM的端口上。

端口类型:

  • Mode Request端口,这是一个Sender Port,一个SWC作为模式的改变者可以用来请求BswM进行模式切换,在BswM中有对应的Recevie Port
  • Mode Switch端口,这是一个Receive Port,一个SWC也可以是模式的使用者,因此它需要知道BswM的仲裁结果,因此它需要有这样一个R-Port,在BswM中对应的要有Sender Port(这个端口用来实现Mode Notifications,端口类型同样是Mode Switch),另外BswM在需要知道当前的模式的话也需要Mode Switch R-Port

端口:

  • Mode Request端口:BswM读取请求的模式可以使用R-Port Rte_Read_modeRequestPort0_requestedMode(&)
  • Mode Switch端口:切换BswM的模式,可以是Rte_Switch_modeSwitchPort0_currentMode()或者SchM_Switch_modeSwitchPort0_currentMode()
  • Mode Notifications端口:SWC读取BswM的模式可以通过R-Port Rte_Mode_modeNotificationPort0_currentMode(&)或者SchM_Mode_modeNotificationPort0_currentMode(&)

BswM_Port

最后我们看一下上边这张端口连接图:
Application Mode Manager(SWC)通过modeRequestPort和BswM相连,Application Mode Manager(SWC)/Application Part(SWC)/BswM(如果需要知道当前的模式)会跟BswM(模式仲裁和模式控制)之间通过modeSwitchPort相连,用来得到BswM在模式切换以后的通知。

4.参考资料
AUTOSAR_SWS_BSWModeManager.pdf

AUTOSAR BSW标准解读 – IO抽象层

上一篇AUTOSAR的文章中,我们讨论了宏观结构上的AUTOSAR分层,这篇文章我们来一起讨论一下,BSW中的IO抽象层,这也是BSW中最为简单的一部分内容。我们先来看下边这张图,从图中我们清晰的看明白IO抽象层所处的位置。

IoHwLayer

  • 什么是IO抽象层

IO抽象层是ECU抽象层的一部分,它并不像其他ECU抽象层一样(比如COM 硬件抽象,Memory硬件抽象等)会提供接口给服务层使用(当然IO抽象层的接口也有可能跟其他BSW模块进行交互),而是直接连接到RTE,并提供接口给SWCIO抽象层是和特定的ECU实现紧密相关的,狭义来讲它提供了对ECU Pin脚的抽象(同时提供了诊断功能)。它也并不是针对某一个底层模块,而是多个底层模块的集合,只要是直接给SWC提供ECU硬件接口的都属于这一层,它可以是ECU AD信号读取接口,可以是ECU 离散输入输出操作接口,还能够是操作ECU ASCI芯片资源的SPI接口,这一部分BSW软件在不同的ECU上会有很大的不同,因此AUTOSAR标准并没有(也不可能)将它标准,而仅仅是提出一个实现指导,对应的AUTOSAR标准文档为:AUTOSAR_SWS_IOHardwareAbstraction.pdf

  • IO抽象层的功能

  1. IO抽象层的初始化和反初始化函数由EcuM来管理调用。
  2. IO抽象层可以包含一个或多个处理主程序(根据不同的驱动可以分类),这些处理主程序可以被BSW调度器调度;
  3. IO抽象层支持使用Nofification或者Callback;
  4. IO抽象层可以有两种调度方式,Runnable方式和BSW调度方式;
  5. IO抽象层也是通过各种ProvidesRequires端口与SWC交互的
  6. 为了根据不同信号的不同的实时性要求,IO抽象层引入了Age Attribute的概念,对于输入信号,这个属性代表IO抽象层所读取回来的数据的有效时间,对于输出信号,这个属性代表使用IO抽象层操作输出的时候的延时时间,熟悉嵌入式软件设计的人可能更为熟悉的概念是立即操作(IMMEDIATE)和缓存操作(BUFFERED),当Age Attribute为0是代表操作为立即错误,当它为大于0是,代表采用缓存操作时可以允许的最大的延时;
  7. IO抽象层需要对硬件提供保护,例如检测输出的状态,出现短路过温的时候关闭输出,但是故障以后的恢复逻辑只能在SWC中而不在IO抽象层中;
  8. IO抽象层是随着不同的ECU不同的,非AUTOSAR标准的模块,因此在AUTOSAR系统中又被称为Integration Code;
  • 与其它BSW的交互

1. [MCAL]根据IO抽象层的需求来看,它需要向SWC提供对所有MCAL驱动访问的功能,我们来看一下怎么阅读下边这张AUTOSAR提供的IO抽象与MCAL交互汇总表。

MCAL_IoAbstract这张表表示了从IO抽象层到MCAL的调用关系,例如:

  • IO抽象层会调用ADC驱动的API,IO抽象层会调用DIO驱动的API
  • IO抽象层会收到GPT驱动的通知,IO抽象层会收到ICU驱动的通知
  • IO抽象层不会收到DIO驱动的通知

2. [ASIC]如果MCU有外围芯片,需要通过通讯来访问(例如:SPI,I2C),IO抽象层需要提供这种访问能力,所有的这些ASIC芯片操作都需要通过IO抽象层,比如外部ADC芯片,预驱芯片等,这种交互方式可以从下边这个图一目了然的看出来。

ASIC_IoAbstract

 

3. [System Service]IO抽象层可以和这几个系统服务进行交互:EcuM(初始化函数),DEMDETBSW Scheduler;

4. [DCM]IO抽象层可以向DCM提供接口,用于SWC的功能性诊断。

  • 总结

IO抽象层由于高度依赖于ECU的功能和设计,因此AUTOSAR没有标准化这部分软件的具体功能,AUTOSAR BSW软件供应商也就无法提供者一部分内容的软件,这部分功能的实现跟一般的SWC类似,在系统设计的时候需要设计所有的Port口,并由ECU开发者将这些Port口一一实现。

 

 

从软件构架看符合AUTOSAR标准的软件 Part 1 – 软件分层

引言:

在上一篇AUTOSAR文章中,我们介绍了AUTOSAR即是一个组织,又是一套标准,如果有必要的话,大家还可以再回顾一下什么是AUTOSAR这篇文章,在我们后续的文章中提到AUTOSAR一般都会是指AUTOSAR标准。

既然AUTOSAR标准是汽车行业内的一套软件设计软件开发标准,那么到底什么样的软件是符合AUTOSAR标准的软件呢?主要在于两个方面:

  • 软件构架符合AUTOSAR标准,这里软件构架包括软件分层和软件接口
  • 软件开发方法符合AUTOSAR标准

AUTOSAR的目标是为了满足未来汽车的需求,增强软件的可用性、安全性、可维护性,增加软件的灵活性和可扩展性,要实现这一目标唯一的手段是通过良好的分层即模块抽象来将软件模块的耦合性降到最低,因此AUTOSAR定义了汽车上所有的ECU都适用的通用的软件构架(软件分层和软件接口)。

AUTOSAR软件分层:

在这一篇文章中我们会跟大家一起看AUTOSAR规定的软件分层是什么样的,在AUTOSAR标准解释文档中,有三张不同详细程度的软件分层图,我们这里拿中间详细程度的这张图来讨论一下,为什么选取这个等级的分层图来讨论呢,因为我们这篇文章是从比较宏观的层面来讨论AUTOSAR软件分层,过粗的图容易漏掉一些基本概念,过细的图则显得累赘没有必要,对于详细的分层和分模块,我们在后续还会有系列文章逐一解析。

autosar-software-layer

位于上面的软件分层图中最下方黑色的部分表示的是汽车电控单元所使用的电子硬件(包括主控CPU以及外围设备),在这一层上边的部分才是软件部分。从整体来看,AUTOSAR将软件分为三层,分别为应用层(Applicaiton Layer),中间件(RTE:Runtime Environment)和基础软件(BSW:Basic Software)。

1. 应用层 – Applicaiton Layer

应用层部分是指实现特定的ECU功能的那部分软件,这部分软件负责实现ECU的逻辑功能,比如说,通过算法控制大灯,控制空调,控制电机,它是汽车功能的一种抽象,与ECU所使用的硬件没有关系。应用层又可以细分为软件组件(SWC),软件组件之间的信息交互不能直接进行必须通过RTE。

application_layer_swc

通过SWC概念的设计,对应用层软件进一步解耦,使得应用层中的SWC具有了被替换的可能。

2. 中间件 – RTE,Runtime Environment

中间件部分给应用层提供了通信手段,这里的通信是一种广义的通讯,可以理解成接口,应用层与其他软件体的信息交互有两种,一种是应用层中的不同模块之间的信息交互,第二种是应用层模块同基础软件之间的信息交互,而RTE就是这些交互使用的接口的集散地,它汇总了所有需要和软件体外部交互的接口。从某种意义上来看,设计符合AUTOSAR的系统其实就是设计RTE,对于这一点我们会在以后的文章中仔细展开。

3. 基础软件 – BSW,Basic Software

虽然汽车中有各种不同的ECU,它们具有各种各样的功能,但是实现这些功能所需要的基础服务是可以抽象出来的,比如IO操作,AD操作,诊断,CAN通讯,操作系统等,无非就是不同的ECU功能,所操作的IO/AD代表不同的含义,所接收发送的CAN消息代表不同的含义,操作系统调度的任务周期优先级不同。这些可以被抽象出来的基础服务被称为基础软件。根据不同的功能对基础软件继续可以细分成四部分,分别为服务层(Service Layer),ECU抽象层(ECU Abstract Layer),复杂驱动(Complex Driver)和MCAL,四部分之间的互相依赖程度不尽相同。

  • 服务层(Service Layer),这一层基础软件提供了汽车ECU非应用相关的服务,包括OS,网络通讯,内存管理(NVRAM),诊断(UDS,故障管理等),ECU状态管理模块等,它们对ECU的应用层功能提供辅助支持,这一层软件在不同领域的ECU中也非常相似,例如不同的ECU中的OS的任务周期和优先级不同,不同的ECU中的NVRAM的分区不同,存储的内容不同。
  • ECU抽象层(ECU Abstract Layer),这一层软件提供了ECU应用相关的服务,它是对一个ECU的抽象,它包括了所有的ECU的输入输出,比如AD,DIO,PWM等,这一层软件直接实现了ECU的应用层功能,可以读取传感器状态,可以控制执行器输出,不同领域的ECU会有很大的不同。
  • MCAL,这一层软件是对ECU所使用的主控芯片的抽象,它跟芯片的实现紧密相关,是ECU软件的最底层部分,直接和主控芯片及外设芯片进行交互,它的作用是将芯片提供的功能抽象成接口,然后把这些接口提供给上边的服务层/ECU抽象层使用。
  • 复杂驱动(Complex Drivers),汽车ECU中有一些领域的ECU会处理相当复杂的硬件信号,执行相当复杂的硬件动作,例如发动机控制,ABS等,这些功能相关的软件很难抽象出来适用于所有的汽车ECU,它是跟ECU的应用以及ECU所使用的硬件紧密相关的,属于AUTOSAR构架中在不同的ECU平台上无法移植的部分。

总结:

AUTOSAR定义了汽车上所有的ECU都适用的通用的软件分层结构,想要设计符合AUTOSAR标准的ECU软件,首先需要按照AUTOSAR规定的软件分层来对ECU中不同的软件进行抽象。

XCP协议和A2L文件 – A2L(ASAP2)解析

XCP协议和A2L文件系列文章将要接近尾声了,我们最后将要讲解的是同样重要的A2L文件和ASAP2标准,ASAP2标准是一个比较复杂的标准,详细的一条一条讲解标准内容并没有太大的价格,我们将主要以一种应用的方式来带领大家认识ASAP2标准理解作为ASAP2表现形式的A2L文件的作用,最后学会如何阅读和修改A2L文件。

首先我们要搞清楚什么是A2L什么是ASAP2标准,简单来说ASAP2标准是ASAM组织制定的一套标准,该标准规定了上位机(Master)和ECU(Slave)之间的通讯所需要的所有信息(可以是XCPonCAN,XCPonUSB等,也可以是CCP,还可以是UDS),而A2L文件就是ASAP2标准的表现形式,符合ASAP2标准的A2L文件主要含有两部分内容:ECU的描述信息和通讯方式的描述信息。

  • 什么是ASAP2标准

ASAP2标准是ASAM在1998年提出来的,现在它的名字叫做ASAM MCD-2MC/D,是ASAP标准中的第二部分。整个ASAP有3部分内容,ASAP1描述了上位机(Master)和ECU(Slave)之间的通讯协议,我们这个系列文章介绍的XCP以及它的前身CCP都是属于ASAP1标准,ASAP2规定了Master端如何去描述和解析Slave端的信息,ASAP3规定了如何使用第三方工具和设备操作和控制上位机(Master),例如如何使用台架软件来控制标定测量工具去对ECU进行控制和测试。

ASAP_Overview

ASAP2标准目前的版本为v1.6,对应的文件全名为:ASAM_MCD-2MC_DataSpecifcation_V1.6.pdf

  • 什么是A2L文件

前边介绍了,A2L文件是基于ASAP2标准书写完成的,那么A2L文件到底是什么东西了。首先它是采用ASAP2指定的一套类XML语言的描述性语言(采用开标签和关标签来描述信息)书写的文件,它里边包含了某个特定的ECU中的软件和系统信息,还包含了上位机和ECU通讯方式的约定,它用来指导上位机和ECU的通讯交互过程,让他们对交互的信息有一致的认识,从而是上位机工具准确且友好的将ECU中的信息展现给用户。下面我们来看一下A2L文件的结构和组成。

一个A2L文件只能有一个Project(项目),而项目中至少要有一个Module,A2L文件的注释和C语言的注释方式是一样的,支持/**/和//两种方式。上边文件结构中,不同的文件块都有着重要的意义:

  1. HEADER:这个块里边包含了项目信息,包括项目编号,项目版本等信息。
  2. MODULE:这个块里边包含了在标定测量层面来描述ECU需要的所有信息,一个ECU对应一个MODULE块,MODULE由许多子块来组成。
    1.  MOD_PAR:这个块里包含了用于管理ECU的数据,例如客户名,编号,CPU类型,ECU的内存分配等,其中最重要的就是ECU的内存分配,开发人员需要根据ECU内存分段情况定义MEMORY SEGMENT和SEGMENT里边的PAGE,这里的SEGMENT/PAGE的概念和在线标定中的概念是一致的,请参考在线标定篇章,一个MODULE里边只能出现一次;
    2. MOD_COMMON:这个块用来指定ECU的一些标准的一般性描述信息,比如大小端,数据的对齐方式,FLOAT变量的处理方式等,一个MODULE里边只能出现一次;
    3. CHARACTERISTIC:这个块用来定义标定变量,里边包含了可以被标定的变量的名字,地址,长度,计算公式,精度,最大最小值等信息,一个MODULE里边可以出现很多次这样的块,也就是说一个ECU可以有很多的标定变量;
    4. AXIS_PTS:这个块用来定义数组或查表变量对应的轴的类型,它将被RECORD_LAYOUT块来引用,一个ECU里边可以有很多种不同的轴类型,用于实现查表和插值;
    5. MEASUREMENT:这个块用来定义测量变量,里边包含了可以被测量的变量的名字,地址,长度,计算公式,精度,最大最小值等信息,一个MODULE里边可以出现很多次这样的块,也就是说一个ECU可以有很多的测量变量;
    6. COMPU_METHOD:用于定义计算公式,及原始值和物理值之前的转换关系,这些公司可以被标定变量和测量变量来引用,从而将原始值转换成便于用户阅读和使用的物理值;
    7. COMPU_TAB:这个块用来定义原始值和物理值的映射关系,是一种特殊的转换关系,它一般应用于枚举变量,例如我们想采集一个代表XCP状态机的变量,分别为0对应DISCONNECTED,1对应CONNECTED,2对应RESUME,那么我们就可以把这样的映射关系定义层一个COMPU_TAB,然后关联到对应的变量上,这时候如果上位机采集到1这样的原始值,它就可以将当前的状态显示成“CONNECTED”字样,方便用于阅读和使用;
    8. FUNCTION:这个块不是必须;
    9. GROUPS:这个块这个把标定变量和测量变量按照一定的逻辑(比如功能模块)组织起来,在上位机工具中形成一个下拉菜单,使得用于可以从中选择变量,这个块不是必须的;
    10. RECORD_LAYOUT:这个块用来定义标定变量的物理存储结构(单个变量,二维表,三维表等)。

上述的这些信息块可以分为两类,一类是随着ECU和XCP实施完成以后就确定的,这类信息一经确定以后再后续的使用过程中是不需要修改的,例如大小端,MEMORY SEGMENT内存分配等,上述HEADER/MOD_PAR/MOD_COMMON属于这一类,另外一类是当ECU软件有所调整的时候就会变化的,例如已有的标定变量和测量变量的地址,甚至变量名,或者可能会新增变量,上述CHARACTERISTIC/AXIS_PTS/MEASUREMENT/COMPU_METHOD/COMPU_TAB/FUNCTION/GROUPS/RECORD_LAYOUT属于这一类。在第二类中改动最多的尤其是CHARACTERISTIC和MEASUREMENT快中的变量地址信息,因为每次软件变化重新编译都会造成这部分信息的更新,地址更新导致的块信息更新需要手动的更改A2L文件才能使得A2L和当前的软件配置起来,只有两者相匹配才能实现正确的标定和测量。

  • A2L块示例

1.测量变量vechicle_speed可以进行如下定义,该变量处于RAM中,对应的地址是0xD0001234,它的范围是[0-230] ,它在ECU中以一个UWORD类型来表示,原始值和物理值的转换关系为:Phy = 0.003 X Raw ,即Ax+B中A=0.003,B=0

2.测量变量xcp_state代表XCP的状态,可以进行如下定义,它处于RAM中,在ECU中的地址是0xD0005678,它是一个枚举量,0对应DISCONNECTED,1对应CONNECTED,2对应RESUME

3.标定变量Current_threshold可以进行如下定义,它处在FLASH标定区域,在ECU中的地址是0x00012345,它的范围是[-20,20],是一个有符号量,精度为0.125,即Phy = 0.125 X Raw

我们前边提到的,在每次软件有更新重新编译以后,会导致这些变量在ECU中的地址有变化,那么上边这些变量对应的ECU ADDRESS条目的内容就需要随着改变,变量的地址信息可以从编译生成的MAP文件中获得,然后手动更新到A2L中。

XCP协议和A2L文件 – XCP协议解析 Part2

在上一篇文章中,我们解析了XCP协议中一些宏观的概念,在本篇文章中,我们将会利用CAN传输层来展示具体到XCP消息结构。我们将首先从一个通用的角度来看XCP的消息结构,这里的通用指的是既针对CTO又针对DTO,然后我们会对基于CAN传输层的CTO和DTO的消息结构分别进行讲解。注:文章中所使用到的DTO概念适用于DAQ和STIM,但是举例和描述中都默认使用DAQ。

  • 通用消息结构

通用的消息结构既适用于CTO也适用于DTO,通用的消息结构既适用于CAN传输层也适用于其他传输层,在构造不同命令的时候,通用结构里边的某些字段的含义不同或者是字段的长度不同。

XCP_Message_Format_General

一个完整的XCP消息(也可以说一帧XCP消息)由三部分组成,它们是XCP Header(XCP消息头),XCP Packet(XCP消息体),XCP Tail(XCP消息尾),Header和Tail的存在是依赖于具体的传输层的,而Packet在不同的传输层上都是必须的。Packet又有3个组成部分,分别是标识区(Identification Field),时间戳区(Timestamp Field),数据区(Data Field)。

对于CAN传输层来说,Header是不存在的,因此实际的XCP消息帧就是消息体加Tail,而Tail又于DLC的设置相关,如果DLC=8,但是消息体的长度又不够8个字节的时候,Tail的大小就是8减去消息体字节长度,Tail的内容就是CAN消息的填充(0xFF,0x00或者其它指定的值),而如果DLC是根据消息长度设置的,那么Tail长度就始终是0。

  1. 标识区:标识区用来标识该帧消息,用以和别的消息帧进行区分,告诉接收方现在这条消息是什么类型,里边的数据代表什么意义。从CTO的角度举例的话,它可以连接命令,可以是断开连接命令,也可以是标定页切换命令,这些命令在CAN消息层面来说,都是几个字节的数,那么接收方如何知道现在这条命令是什么命令呢,接收方就是通过标识区来识别的,不同的标识区对应不同作用的命令。从DTO的角度举例来说,现在发送出来的ECU内部数据到底是哪部分的数据,对应于ECU中的哪个或哪几个变量,这些信息又是怎么同别的信息区分开来的呢,也是通过标识区。
  2. 时间戳:时间戳用来反映本帧数据的时刻,它只有在DTO中是有效的,也就是说在CTO中时间戳的长度是0即不存在。跟标识区不同的是,标识区在DTO的每一帧中都存在,用以区别本帧和其他帧的所代表的意义,而时间戳仅仅出现在一个DAQ中所有的DTO消息中的第一条。这是因为DTO都是通过块传输模式通讯的,通过前边的文章,我们知道了ECU向上位机上传变量信息数据的时候通过DAQ,而DAQ反应在消息层面就是很多条DTO消息,对于同一个DAQ里边的DTO消息他们所代表的是同一时刻的不同数据,因此只要第一条消息中含有时间戳就可以代表整个DAQ消息块中所有消息的时刻。如果大家对前边的概念有些遗忘,可以再去回顾一下DAQ同步数据传输详解这篇文章。
  3. 数据区:顾名思义,数据区包含了XCP消息的真正数据内容。从CTO的角度来看,数据区里边的数据代表着命令的参数,用来告诉接收方怎么去执行标识区标识的命令。而从DTO的角度来看,数据区里边就是实际的ECU当中的变量的值或者内存里边的值。
  • CTO消息结构

CTO的消息包含了一个BYTE的标识区(PID),时间戳长度为0,剩下的都是数据区,因此消息结构就退化成了以下这样。

XCP_Message_Format_CTO

针对不同的CTO命令,PID和DATA的数据格式都不同,具体的信息在XCP标准Part2中可以查到。这里我们仅对PID部分做个简单的说明:

CMD:  PID的范围是 0xC0 — 0xFF,不同的PID代表不同的命令

RES:PID是0xFF,代表对于CMD的肯定响应

ERR:PID是0xFE,代表对于CMD的否定响应

EV: PID是0xFD,用于向上位机报告事件

SERV:PID是0xFC,用于请求上位机做某些动作

  • DTO消息结构

DTO的消息结构略微复杂一点,可以根据实际的ECU资源和应用情况选择使用不同的结构。如下图所示,标识区和时间戳都有多种长度可以选择,不同标识区和时间戳格式是可以随便组合使用的。

  1. 标识区:PID就是DAQ块通讯时候的DTO消息的编号,从0x00到0xFB,用来识别消息中数据所代表的意义(类似于UDS连续帧中的消息计数),同时标识区可以最大扩充到4个Byte,后边可以放置目前数据所处的DAQ编号。为什么要有这样的扩充呢。利用CAN传输层举例来看,在XCP实施中,可以选取不同的CAN ID来标识不同的DAQ,这种情况下DAQ的标号对于接收方来说是可以通过CAN ID来区分出来的,另外一种方式是使用相同的CAN ID来处理不同的DAQ,这个时候接受方就无法从CAN ID来区别不同的DAQ,那么就可以在标识区中增加DAQ编号来达到这个目的。
  2. 时间戳:根据实际的资源情况,时间戳可以从1、2、4字节的长度中来选择

XCP_Message_Format_DTO

PID的范围:

DAQ: PID的范围是0x00 — 0xFB

STIM:PID的范围是0x00 — 0xBF

  • PID范围总结

最后我们一目了然的看一下整个XCP通信中的PID取值分布情况:

XCP_Message_PID_List

 

XCP协议和A2L文件 – XCP协议解析 Part 1

在接下来的两篇文章中,我们将主要通过XCPonCAN(即XCP运行在CAN传输层上)来仔细讲解XCP协议层的内容。本篇文章主要侧重于XCP协议层中的通讯拓扑,通讯模型,状态机以及消息分类,下一篇文章主要侧重于XCP命令的格式。

  • 通讯拓扑

XCP 通讯是一种点对点的通讯协议,即同一时刻单个Master和单个Slave之间进行通讯,通讯都是由Master来发起的,Slave根据实际情况来回答Master的请求,Slave端同一时刻只允许同一个Master建立连接。但是,XCP协议也是可以支持网关的。

XCP_Topology

  • 通讯模型

所谓的通讯模型指的是使用XCP通讯的Master和Slave之间的通讯方式,在XCP协议里边规定了支持三种通讯模型,标准型,块传输型(主块传输和从块传输两种),交替型。标准型指的是一问一答的方式,块传输则是多问一答,交替型比较特殊,指的是,被问的一方可以根据自己的实际状态延迟做回答(多问多答)。

接下来大家看一下下边4幅图,大家可以在看图的同时思考一下,它们分别对应的是哪种通讯模型,然后看看自己都分析的是否正确。

上边4幅图从左到右对应的通讯模式分别是:标准型,主块传输型,从块传输型和交替型,你答对了吗?那么这4种通讯模型具体的使用场景是什么呢,为什么要分这4种模型呢。

  1. 标准型。同大部分CAN通讯协议一样,XCP首先支持一问一答的通讯方式,使用这种方式通讯的时候,上位机向下位机发起某个请求,下位机根据上位机的这个请求执行相应的动作,并适当的根据情况给予响应,上位机在收到下位机的响应以后才会发起下一个请求。这种方式被应用到大部分的XCP命令中。
  2. 块传输型。当一条CAN消息无法容纳一次通讯需要的全部数据的时候,为了减小交互时间,XCP设计给出数据的一方不停的将全部数据发送出来以后,接收方才进行一次回复,典型的应用场景为,XCP中的内存上传、下载、刷新命令。在这种传输方式下,因为一方要不停的发送数据给接收方,为了保证数据能够正确不丢失的传输,XCP定义了两个参数,块传输过程中两帧的最小间隔时间MIN_ST以及一次快传输所能使用的最大的块大小MAX_BS。
  3. 交替型。这种传输方式比较特别,在实际应用中使用较少。交替型传输意味着,收到数据的一方(Slave端)在收到Master发来的请求以后可以不立即响应,这个时候Master可以继续发下一条情况,从而在Slave端形成一个请求队列,Slave端可以根据自己的资源情况,当资源空闲时再去一一服务和响应请求。设计这种通讯模式的目的是考虑到有的ECU(Slave端)硬件资源有限,毕竟XCP是一种开发手段,在ECU软件设计中处于低优先级的服务,因此没办法及时响应Master发来的请求。
  • Slave状态机

Slave状态机是一个通讯协议中必不可少的一部分,它描述了使用通讯协议的时候,Slave有哪些状态,状态间是的互相切换规则是怎么样的。XCP在Slave端的状态机如下图所示。

XCP_Statemachine

XCP的状态机中只有简单的三个状态,DISCONNECTED,CONNECTED和RESUME状态。当系统启动以后XCP会根据当前的RESUME模式是否使能来判断进入DISCONNECTED还是RESUME。我们先来看一下大部分使用场景的RESUME模式关闭状态,RESUME模式我们稍后介绍。当XCP处于DISCONNECTED状态下,除了连接命令以外的其他XCP命令都会被XCP协议栈忽略,只有当协议栈收到连接指令以后,协议栈才会切换到CONNECTED状态,在这个状态下,协议栈可以响应和处理所有的XCP命令(所有的标定猜数都是在这个状态下处理的)。当处在CONNECTED状态下的协议栈收到断开连接的命令以后会退回到DISCONNECTED状态。此外,当协议栈中发生了严重等级为S3的致命错误的时候,协议栈也会从CONNECTED状态退回到DISCONNECTED状态。这些严重度等级对应的具体错误在XCP的规范中可以查找的到。

我们刚提到系统启动以后会先检查RESUME模式是否使能,那么什么是RESUME模式呢。从上边的状态图可以看出,如果要实现对系统的变量参数采集,上位机需要和XCP协议栈进行连接握手才能进行采集,其实在实际采集前的握手交互远不止这些,还有采集的变量列表的初始化(ODT/DAQ初始化),这些动作是非常耗时间的,而且需要上位机来发起,但是有时候我们需要实时的获取到ECU系统启动过程中的一些重要数据,那么在这种工作模式下,这些重要参数是没办法被采集到的。为了解决这个问题,XCP引入了RESUME模式,在这种模式下,ECU在上次运行的时候,上位机可以通知它使能RESUME模式,并把需要采集的重要数据的ODT/DAQ描述存储到NVRAM中,然后ECU经过一次掉电和上电的复位以后,在启动过程中,协议栈会检查到RESUME模式已经被使能,那么就会直接进入RESUME状态来不停的将ECU中的指定参数发送出来。值得注意的是RESUME模式跟DISCONNECTED模式有一个相同点就是,在这个模式下协议栈无法响应除了连接命令以外的其他命令。一旦收到连接命令以后,协议栈会进入CONNECTED状态,同时停止数据发送,等待正常的命令交互。

  • 消息分类

不同的命令各司其职从而实现了XCP的协议,对消息进行分类有助于更好的理解和实现XCP协议栈。XCP的消息分为两大类:CTO(Command Transfer Object,命令传输对象)和DTO(Data Transfer Object,数据传输对象),顾名思义,CTO是指所有功能性命令的传输,DTO是指所有数据的传输。

CTO中又包含一种主发给从的CMD(命令),和四种从发给主的消息,RES(肯定响应),ERR(否定响应),EV(事件,在发生某些事件的时候,下位机用这种消息来通知上位机),SERV(服务请求,在某些情况下,下位机虚需要请求上位机做一些动作,那么它将通过这种消息来发起请求)

DTO中包含了一种主发给从的STIM(反向DAQ),这种消息跟我们前边文章中介绍的STIM和BYPASS功能使用相关,它用来大批量的向下位机发送数据。另一种DTO是DAQ,这种消息用于大批量的将ECU中的数据发送给上位机,也就是数据采集和测量用到的主要消息。

 

XCP_Message_Packet_Type

XCP协议和A2L文件 – 在线标定详解

在前边的章节中我们也介绍过在线标定的基本用例,大家应该对在线标定实现的功能有了了解。在这一篇文章中,我们将基于XCP标准中规定的在线标定的实现方式和一些概念,来讨论怎么在一个实际的ECU中设计在线标定方案。

首先大家来看一下下边的这个图,在XCP协议中,提出来PAGE(页)的概念,所谓的页就是对数据赋予了访问属性的概念,页是一种对数据的描述,一个SEGMENT中不同的页代表这相同地址上的相同的数据,唯一的区别是他们的数据内容和访问权限是不同的,下图中SEGMENT1中的页1是ECU可以访问的,而页2只有XCP可以访问,这个图只是XCP标准里边的示意图,在具体的在线标定实现中,没有这么复杂的页设置,一般来讲,在线标定只需要两个页,即Working Page(工作页)和Reference Page(参考页)。在实际应用中,控制算法中正在使用或者访问的数据来源页被称为激活页(Active Page),页的切换动作会有XCP提供的命令来触发,同时XCP也会提供相应的命令可以获取现在ECU中的激活页编号。同一个SEGMENT里边的不同的页通过PAGE_NUMBER这样的术语来索引,页的索引都是从0开始,连续递增的。这个图中提到的SEGMENT表示的是ECU地址分配的逻辑分区(与FLASH物理状态无关,纯逻辑应用概念),举例来说SEGMENT1可以是标定区,SEGMENT0可以是程序区,每一个SEGEMENT可以有多个页。SEGMENT是用SEGMENT_NUMBER这样的术语来索引的,该索引页是从0开始连续递增的,而SECTOR则代表着ECU地址分配的物理分区,它就是指FLASH的物理分区状态,每一个SECTOR代表一个单独可擦除的物理分区。

xcp_pages

那么,这些PAGE啊SEGMENT的概念是怎么和在线标定联系起来的。首先,有个概念我们要明确一下,所谓标定数据,就是控制算法中使用的一些固定的参数,这些参数在完成开发阶段的调优以后就会固化起来,因此显而易见,这部分数据会被分配到ECU的FLASH区域中,而作为ECU开发阶段重要过程的参数调优(标定过程)则要求这些数据可以通过通讯(XCP等)能够实时被修改,因此这部分数据又需要被分配到ECU的ram中。而数据的承载形式-变量在编译链接以后只能有一个地址,因为标定数据本质上看是固定的参数,因此他们会实际被配置到FLASH中。而这些数据在开发阶段同时需要具备被修改的RAM属性,对照上文我们看到的页的概念,可以自然而然的将页的概念引入进来,然后,FLASH中的标定数据就称为参考页(Reference Page),RAM中的标定数据就成为工作页(Working Page),参考页就是可以被ECU/XCP读取但不能写入的数据,工作页就是可以被ECU读取/写入,可以被XCP读取和写入的数据,他们在逻辑上都是对应了相同的FLASH地址而被赋予了不同的读写属性。下边的这个图可以给大家一个更加直观的概念解释,在ECU中的标定数据(标定SEGMENT)里边含有两个页(页0-参考页,页1-工作页),处于标定SEGMENT中有一个标定量为CAL_PID_K,它在链接以后会被分配FLASH地址(位于RP中),当激活页为RP的时候,这个变量的内容会从FLASH中获得此时为20,然后上位机通过XCP命令让ECU工作于工作页(WP),这个时候这个变量的内容会从RAM中获得此时为15,同时由于数据都从RAM中获得,这个时候如果更改了RAM中的数据,相应的应用到算法上的变量CAL_PID_K也会相应的变化,从而实现了在线标定。

xcp_wp_rp

上边介绍了在线标定所使用的基本原理,这时候,聪明的你可能已经看出来,这里有一个最不可思议的点,怎么用相同的地址来在不同的情况下访问RAM或者FLASH呢。解决这个难题主要的手段是通过地址映射来将本来链接时候固定下来的变量地址(我们称为逻辑地址)在不同的激活页的情况下映射到不同的物理地址上,有两种方案来实现这个映射,这两种方案和ECU所使用的主控芯片有关,我们来逐一介绍一下。

1.硬件实现地址映射

目前有很多支持硬件实现地址映射的芯片,例如PowerPC系列(MMU模块),TriCORE系列(Overlay 模块),如果你的ECU选取了这类芯片作为主控芯片,那么我们就可以很简单的通过配置几个寄存器实现地址映射即页切换。这种方式的好处是,控制逻辑在访问标定变量的时候不需要做任何软件的转换和干预,使用起来简单方便,软件好维护,缺点是,带有这种功能的芯片价格都偏高。

hardware_addressing_mapping

 

2. 软件处理地址映射

如果处于成本考虑,你的ECU的主控芯片并没有硬件的地址映射模块,那么必须通过一些软件干预的形式实现这个功能,具体我们来看下边这个图,标定变量在实际编译的时候会放置在FLASH区域(图中绿色实线箭头),而当激活WP以后,标定变量的内容会从RAM区域的WP去获取,而获取的方式是通过在访问变量的时候增加一个偏移量实现的。举例来说,我们有个字节型的控制变量current等于一个可标定的阈值,那么使用的时候可以这样写current = *(uint8_t*)((uint32_t)CAL_Current + offset),这个offset就是软件地址转换的核心,当激活RP的时候,该offset = 0,标定变量的地址实际指向0x000到0x200范围内,而激活WP的时候offset就可以设置为0x1000,那么current在获取标定数据的时候就自动在地址上增加了该偏移量,从而指向0x1000到0x1200区域。这种方式的优点是,可以适用于任何芯片,缺点也显而易见,需要在访问标定数据的时候增加偏移量,会增加软件的维护工作量。

software_addressing_mapping