AUTOSAR的三類接口

AUTOSAR中有三種類型的接口，分別是：AUTOSAR接口，標(biāo)準(zhǔn)化AUTOSAR接口和標(biāo)準(zhǔn)化接口。

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

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

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

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

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

這張圖乍一看可能會(huì)有點(diǎn)一頭霧水，我們來(lái)看一下這些箭頭代表什么意思。

AUTOSAR各層軟件之間的交互

下面我們通過一個(gè)例子來(lái)詳細(xì)看一下AUTOSAR各個(gè)軟件層之間是如何交互的，看完這個(gè)例子你將會(huì)了解：

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

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

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

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

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

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

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

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

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

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

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

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

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

Std_ReturnType Ea_Write
(
uint16 BlockNumber,
uint8 *DataBufferPtr
)

NVM設(shè)備使用場(chǎng)景

場(chǎng)景一：只使用一種NVM設(shè)備類型

這是通常的用法，使用EEPROM或者Flash中的一種NVM設(shè)備。這種情況下，Memory Abstraction可以用簡(jiǎn)單的宏定義實(shí)現(xiàn)，該定義忽略設(shè)備索引參數(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: 不存在

此種情況沒有運(yùn)行時(shí)的額外代碼，NVM manager直接訪問EEPROM Abstraction 或 Flash emulation。

場(chǎng)景二： 使用兩種或以上NVM設(shè)備類型

此時(shí)必須使用設(shè)備索引參數(shù)來(lái)選擇正確的NVM設(shè)備。通過使用函數(shù)指針數(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};

由上面的例子可以看出：

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