在传统嵌入式系统中，存储方案通常是直接操作硬件，例如通过IIC通信与EEPROM进行交互。这种方式虽然简单，但软件结构混乱，驱动和应用代码混在一起。稍微改进的做法是，将IIC驱动独立出来，形成一个公共模块，这样可以使软件层次更加清晰。
但对于AUTOSAR来说，它将EEPROM、DataFlash等非易失性存储统称为NVM，并设计了专门的模块来管理这些存储设备。这样做的目的是为了提高软件的可维护性和扩展性。在AUTOSAR架构中，NVM模块向上提供统一的接口，向下则通过FEE和EA模块与具体的存储硬件进行交互。
FEE是Flash EEPROM Emulation的缩写，主要作用是将DataFlash模拟成EEPROM使用，同时考虑了磨损均衡算法，以延长存储设备的寿命。EA则是EEPROM Abstraction的缩写，它提供了一个抽象层来统一管理不同厂家的EEPROM设备，同样也包含了磨损均衡算法。
在AUTOSAR中，NVM的存储结构被抽象成了RAM Block、Data Set等概念，这使得存储管理更加模块化和层次化。而NVM的使用则通过AUTOSAR的开发工具链进行配置，为SWC生成对应的接口调用。
总的来说，AUTOSAR的存储管理虽然在开始时让人感到困惑，但一旦理解了它的设计理念，就会发现它其实是一种非常高效和灵活的存储解决方案。它通过抽象和模块化，使得复杂的存储硬件变得易于管理和维护，这对于汽车行业这样对可靠性和长期维护性有极高要求的领域来说，是非常有价值的。
很多人都觉得AUTOSAR的Memory很复杂，搞了很久都摸不透里面的原理策略。
其实，AUTOSAR的Memory在AUTOSAR的架构下，封装得很好，只是我们很多人从普通嵌入式软件开发模式而来，一下子转不过弯而已。
本文就从普通嵌入式软件开发中的Memory入手，逐步讲解AUTOSAR的Memory原理策略。
注：以下讲的Memory方案是指EEPROM、DataFlash等非易失性存储（NVM）的软件方案。
1.传统嵌入式存储方案
试想下，一个简单的嵌入式系统软件里，如果想存储写信息到EEPROM（假设外置的EEPROM，通过IIC访问），你会如何设计？
最简单的办法，写好IIC通信，直接根据EEPROM的地址通过IIC进行访问，反正就是操作EEPROM，不用管那么多。但是软件结构比较混乱，驱动和应用混在一起。
这种做法，但凡有点软件层次结构概念的人都不会这么干，当然只是临时调试下硬件是无所谓的。
那么，改进下软件设计，把IIC驱动单独出来，是很常用的做法吧，比较IIC算是MCU的驱动，除了可以访问EEPROM，还可以用来跟其他外设通信，做成独立公共的驱动模块，是理所当然的。软件层次结构就像下面的这样子。
当然，对软件有追求的人，肯定是比较鄙视上面两种结构的，EEPROM好歹也要单独一个模块吧。单独一个应用倒是无所谓，如果要好几个应用要读写EEPROM，岂不是乱成一团了！
于是，设计成这样的接口，看起来是比较理想的。
普通的嵌入式软件的EEPROM设计，大多都是这样的，也比较灵活。
然而，AUTOSAR有更高的追求，它把EEPROM、DataFlash等NVM看成一类存储，而不管存储的实际介质是什么，统统都叫NVM。
于是乎，设计一个NVM的模块就呼之欲出了。NVM的对外的接口是统一的，而它对接DataFlash或EEPROM，还分别多加了一个FEE和EA这样的模块。
2.AUTOSAR的存储方案
到这里，我们对比下这几种方案。
上图方案A和方案B就不考虑了，那方案C和方案D的对比，差别在哪？
除了NVM这个模块是通用性的，还多出了个FEE和EA，那么FEE和EA分别是干嘛的？
在解释这两个模块之前，先从AUTOSAR的架构层面来看看，实际上FEE和EA就在Memory Hardware Abstraction层里面，注意关键字Abstraction。
FEE是Flash EEPROM Emulation的缩写，而EA是EEPROM Abstraction的缩写。
AUTOSAR考虑问题比较周到，NVM的存储是要考虑寿命的，特别是用在汽车行业。
一般情况下，DataFlash的P/E Cycle是10万次，EEPROM的是100万次。另外，DataFlash的擦写单位是比较大的，如果只想写一两个byte，需要擦除一大片，非常不友好。
于是要将DataFlash模拟成EEPROM来使用，这个FEE就出来了。当然FEE还考虑了磨损均衡算法，英文一般叫Wear Leveling。
那EA呢？因为EEPROM不同厂家做的地址、page管理等方式不一样，所以要做个抽象层来统一管理下，同时也加入了磨损均衡算法，来增加EEPROM的寿命。
以下以在0x0008地址写入0x11, 0x22, 0x33, 0x44这四个字节内容为例，看看EEPROM和DataFlash的实际操作情况：
很明显，EEPROM在同一个位置频繁操作也不是非常好的，只要次数多也是会影响寿命的，而Flash在这方面的劣势就更明显了，不但擦写单位比较大，寿命也比较短，所以这个FEE和EA的抽象是有必要的，磨损均衡技术也是有必要的。
至于这个磨损均衡技术是怎么实现的，涉及到的内容比较多，后续再细讲。
细心的小伙伴，会发现，为什么还有个MemIf？
实际上这个MemIf很简单，仅仅是统一封装了下FEE和EA的接口，为NVM提供一个统一的接口管理而已，如果非要说，那只能说NVM比较娇贵，啥都要给它准备得好好的。
3.NVM的存储结构
这样就完了吗，软件架构层次基本就这样了。
然而，AUTOSAR里面的这个Memory这一套东西，是很有搞头的，怎么说呢？
除了层次分明外，它对存储的结构抽象得很明确，于是就有了RAM Block，Data Set等这样的概念。
这部分内容，在《一图读懂AUTOSAR NvM(附pdf版文档资源)》里面已经讲得很清楚了，本文不再累述。再次附上一张NVM Block结构的汇总图，方便平时查阅。
4.AUTOSAR NVM的配置
讲了这么多，NVM怎么使用？
想其他AUTOSAR的Mode模块一样，NVM的接口不是给应用直接调用的，而是通过AUTOSAR的开发工具链给SWC配置NVM的Service接口，然后生成对应的Runnable等接口调用的，这里有套规则。
这个NVM配置的内容虽然涉及到的概念有点多，步骤也有点多，但搞清楚后就很简单了。
审核编辑：刘清
