介紹一下AUTOSAR各個軟件層之間交互的接口

AUTOSAR的三類接口

AUTOSAR中有三種類型的接口，分別是：AUTOSAR接口，標準化AUTOSAR接口和標準化接口。

• AUTOSAR接口：用于SWC與SWC之間、SWC與BSW之間交換信息的接口。這類接口獨立于特定的編程語言、ECU和網(wǎng)絡技術。AUTOSAR接口用來定義SWC之間以及SWC與BSW之間的Port，通過這些Port SWC與SWC、SWC與BSW可以相互通信(發(fā)送或接收數(shù)據(jù)，或調(diào)用服務)。無論這些SWC與BSW位于本地ECU，還是位于不同的ECU(通過車載網(wǎng)絡)，都可以通過AUTOSAR接口實現(xiàn)數(shù)據(jù)交換。
• 標準化AUTOSAR接口：標準化AUTOSAR接口也是一種AUTOSAR接口，可以看作是AUTOSAR接口的子集。它們的特別之處是這類接口的語法和語義都是被標準化的，用來定義AUTOSAR服務，這些服務是BSW提供給SWC應用軟件的標準化服務。
• 標準化接口：一種在AUTOSAR中標準化的API接口，沒有使用AUTOSAR接口技術。標準化接口一般是基于特定編程語言的(如C語言)，鑒于此，標準化接口往往用于同一個ECU上的軟件模塊之間的交互。當軟件模塊通過標準化接口通信，也就無法通過網(wǎng)絡將通信路由到別的ECU上的軟件模塊了。

上面的描述可能有些晦澀難懂，下面這張圖可以幫助大家更好地理解這三種接口的用法。

由上面的圖可以看出，AUTOSAR接口主要用于應用軟件組件(SWC)之間以及應用軟件組件與基礎軟件之間(BSW)的通信。標準化AUTOSAR接口主要用于應用軟件組件與基礎軟件的標準化服務之間的通信。而標準化接口則主要用于不同基礎軟件模塊之間的通信(OS、通信模塊可以通過標準化接口與SWC通信)。

AUTOSAR接口的通用規(guī)則

從之前的文章我們了解到AUTOSAR定義了不同的軟件層級，不同的層級又包含很多軟件模塊。那么在不同的軟件層級以及軟件模塊之間，如何使用AUTOSAR的三種接口呢，接口使用上有哪些限制呢？讓我們通過一張圖來了解一下。

這張圖乍一看可能會有點一頭霧水，我們來看一下這些箭頭代表什么意思。

AUTOSAR各層軟件之間的交互

下面我們通過一個例子來詳細看一下AUTOSAR各個軟件層之間是如何交互的，看完這個例子你將會了解：

• 各層軟件之間如何交互？
• 軟件接口看起來是怎樣的？
• ECU抽象層內(nèi)部是什么？
• 如何高效地實現(xiàn)抽象層？

這個例子將說明NVM manager和WatchDog manager如何在假定的硬件配置下與SPI驅(qū)動程序交互。

ECU硬件包含一個外部的EEPROM和一個外部的看門狗，它們通過SPI與MCU連接。

SPIHandlerDriver控制EEPROM及WatchDog對SPI硬件的并發(fā)訪問，并且使WatchDog對SPI硬件訪問的優(yōu)先級高于EEPROM。

MCU內(nèi)部包含一個Flash，它和外部EEPROM并行使用。EEPROM抽象層和Flash EEPROM Emulation擁有語義上相同的API。

Memory Abstraction Interface可以通過以下幾種方式實現(xiàn)：

• 運行時通過設備索引路由(internal/external)
• 運行時通過Block索引路由(>0x03FF = 外部EEPROM)
• 通過包含函數(shù)指針的ROM table在配置期間路由(此時Memory Abstraction Interface只是虛擬存在)

NVM manager通過抽象層來訪問Hardware Driver，根據(jù)設備索引來區(qū)分不同的存儲設備。

Memory Abstraction Interface的接口可能像下面這樣：

包含設備索引、Block序號和數(shù)據(jù)緩存指針。

Std_ReturnType MemIf_Write
(
uint8 DeviceIndex,
uint16 BlockNumber,
uint8 *DataBufferPtr
)

而EEPROM抽象層和Flash EEPROM Emulation的接口可能像下面這樣：

包含Block序號和數(shù)據(jù)緩存指針，由于到這一層已經(jīng)索引到具體的設備了，因此不再需要設備索引了。

Std_ReturnType Ea_Write
(
uint16 BlockNumber,
uint8 *DataBufferPtr
)

NVM設備使用場景

場景一：只使用一種NVM設備類型

這是通常的用法，使用EEPROM或者Flash中的一種NVM設備。這種情況下，Memory Abstraction可以用簡單的宏定義實現(xiàn)，該定義忽略設備索引參數(shù)。下面的例子展示了寫NVM的函數(shù)定義：

File MemIf.h:

#include "Ea.h" /* for providing access to the EEPROM Abstraction */
...
#define MemIf_Write(DeviceIndex, BlockNumber, DataBufferPtr) \\
Ea_Write(BlockNumber, DataBufferPtr)

File MemIf.c: 不存在

此種情況沒有運行時的額外代碼，NVM manager直接訪問EEPROM Abstraction 或 Flash emulation。

場景二： 使用兩種或以上NVM設備類型

此時必須使用設備索引參數(shù)來選擇正確的NVM設備。通過使用函數(shù)指針數(shù)組，同樣可以高效地實現(xiàn)。下面的例子展示了寫NVM的函數(shù)定義：

File MemIf.h:

extern const WriteFctPtrType WriteFctPtr[2];
#define MemIf_Write(DeviceIndex, BlockNumber, DataBufferPtr) \\
WriteFctPtr[DeviceIndex](BlockNumber, DataBufferPtr)

File MemIf.c:

#include “Ea.h“ /* for getting the API function addresses */
#include “Fee.h“ /* for getting the API function addresses */
#include “MemIf.h“ /* for getting the WriteFctPtrType */
const WriteFctPtrType WriteFctPtr[2] = {Ea_Write, Fee_Write};

由上面的例子可以看出：

• 抽象層可以非常高效地實現(xiàn)
• 根據(jù)需要，抽象層可以簡化
• Memory Abstraction Interface簡化了NVM manager 對一個或多個EEPROM和Flash設備的訪問。