引言 ：嵌入式軟件開發(fā)分層、模塊化是理想狀態(tài)，實(shí)際開發(fā)中因各種限制而有所取舍，但這不妨礙學(xué)習(xí)參考優(yōu)秀軟件架構(gòu)，即使有部分思想在項(xiàng)目中落實(shí)，也是大有裨益的。

1、AUTOSAR的軟件分層理論

汽車電子與消費(fèi)電子不同，其硬件、軟件都更關(guān)注可靠性、安全性和長效性。其軟件需要兼容不同供應(yīng)商、在不同車型可復(fù)用，汽車電子行業(yè)的軟件架構(gòu)AUTOSAR（Automotive Open System Architecture）可以作為參考對(duì)象。因?yàn)椴辉褂煤拖到y(tǒng)學(xué)習(xí)，基于有限信息理解其軟件分層思想，可能有所偏差。

AUTOSAR是一種汽車開放系統(tǒng)架構(gòu)，AUTOSAR規(guī)范的運(yùn)用使得電子控制單元的接口特征標(biāo)準(zhǔn)化，應(yīng)用軟件具備更好的可擴(kuò)展性以及可移植性，實(shí)現(xiàn)對(duì)現(xiàn)有軟件的重用，提高軟件產(chǎn)品的質(zhì)量。

傳統(tǒng)的汽車電子軟件開發(fā)流程存在很多不足：

1、軟件復(fù)用性極差

2、硬件平臺(tái)各式各樣，接口難以統(tǒng)一

3、功能差異性導(dǎo)致軟件模塊化極其有限

4、嵌入式系統(tǒng)不支持硬件抽象

這也是芯片供應(yīng)緊缺或升級(jí)迭代加快，頻繁更換物料時(shí)嵌入式設(shè)備軟件開發(fā)所面臨的問題，重復(fù)的無用功太多。

如車載空調(diào)ECU零件（Electronic Control Unit 電子控制單元），在A款車型上進(jìn)行首次開發(fā)，可通過實(shí)體按鍵操作調(diào)節(jié)溫度。但是同樣的空調(diào)、同樣的ECU，換到B款車型上做開發(fā)時(shí)，想用中控大屏幕來控制溫度，之前寫的控制代碼就不管用了，需要從頭開始重新開發(fā)。或者說，同樣的A款車型，想升級(jí)換另一個(gè)空調(diào)零件，那么軟件也得重新開發(fā)。

深度耦合的架構(gòu)，導(dǎo)致新項(xiàng)目很難復(fù)用以前的代碼，幾乎每一個(gè)新項(xiàng)目都是從頭開始。

而AUTOSAR的目的就是建立分層的體系架構(gòu)和制定接口規(guī)范，將分層架構(gòu)高度抽象，使得汽車嵌入式系統(tǒng)軟硬件耦合度降低。

應(yīng)用軟件層專注于業(yè)務(wù)功能開發(fā)，不關(guān)注底層硬件細(xì)節(jié)；基礎(chǔ)軟件層針對(duì)不同的硬件適配提供基礎(chǔ)接口，不關(guān)注業(yè)務(wù)邏輯。各個(gè)供應(yīng)商或廠家按統(tǒng)一的標(biāo)準(zhǔn)實(shí)現(xiàn)各自的功能，互不干擾。

基礎(chǔ)軟件層框架：

基礎(chǔ)層基于硬件實(shí)現(xiàn)基礎(chǔ)的驅(qū)動(dòng)功能，類似BSP效果，但進(jìn)行了一定抽象封裝，與硬件解耦。

應(yīng)用層實(shí)現(xiàn)業(yè)務(wù)功能，為保證業(yè)務(wù)功能和底層的解耦，中間是運(yùn)行時(shí)環(huán)境RTE隔離。RTE是AUTOSAR 體系的核心，支持軟件組件間、基礎(chǔ)軟件間、軟件組件與基礎(chǔ)軟件之間的通信。

AUTOSAR的標(biāo)準(zhǔn)化，使軟件開發(fā)合作如同堆積木一樣，可以按需修改和更換不同的子模塊，其核心思想是“統(tǒng)一標(biāo)準(zhǔn)、分散實(shí)施、集中配置”。軟件系統(tǒng)的開放化和標(biāo)準(zhǔn)化提高軟件開發(fā)的效率和質(zhì)量。

2、軟件分層實(shí)施

軟件分層理論不錯(cuò)，但如汽車電子的AUTOSAR的復(fù)雜架構(gòu)需要工具配置保證接口和規(guī)范，對(duì)于消費(fèi)電子或者小公司無法滿足條件的，如何結(jié)合實(shí)情進(jìn)行簡化實(shí)施呢？

以電子產(chǎn)品充電時(shí)需要亮LED為例，即主芯片的某個(gè)GPIO控制LED亮滅的需求，拋磚引玉的發(fā)表見解。

主控芯片可能有C1、C2、C3三種，而不同的產(chǎn)品形態(tài)導(dǎo)致硬件布局差異，即使都是C1主控方案，可能采用P1、P2、P3三個(gè)引腳的其中一個(gè)用于LED控制，對(duì)于點(diǎn)亮LED，P1、P2是輸出高亮燈，而P3是輸出低亮燈。

針對(duì)這個(gè)需求，充電時(shí)亮燈屬于業(yè)務(wù)需求，按需求執(zhí)行亮燈接口；底層提供GPIO輸出，對(duì)于LED的控制屬于運(yùn)行時(shí)環(huán)境。為了簡化稱呼，自定義為三層結(jié)構(gòu)，即平臺(tái)適配層---功能組件層---業(yè)務(wù)層 ，最下層為芯片原廠庫或者SDK。

軟件開發(fā)從底層開始，不同的芯片控制GPIO的接口不同，因此需要封裝一層，使用固定的pal_gpio_write接口，至于最終使用哪顆芯片的HAL庫或者SDK，需要根據(jù)芯片類型配置決定，這樣功能組件層不關(guān)注芯片差異導(dǎo)致的GPIO控制接口差異，只需要關(guān)注具體的GPIO引腳，而這個(gè)由LED功能里的配置決定。最終提供給業(yè)務(wù)層的接口就只有l(wèi)ed_charge_show()，具體這個(gè)接口運(yùn)行在什么平臺(tái)、控制哪個(gè)端口都是封閉的。對(duì)于業(yè)務(wù)層開發(fā)，只需要知道，充電時(shí)LED的工作狀態(tài)執(zhí)行l(wèi)ed_charge_show即可，其內(nèi)部細(xì)節(jié)不關(guān)注。

這其中除了C源碼開發(fā)，對(duì)腳本處理及其擴(kuò)展也是軟件分層實(shí)現(xiàn)的基礎(chǔ)，僅僅使用IDE開發(fā)工具是無法做到的。按開發(fā)環(huán)境選擇合適的腳本語言，分層配置，最后統(tǒng)一使用某個(gè)項(xiàng)目宏，即開啟對(duì)應(yīng)的項(xiàng)目宏。編譯時(shí)選擇對(duì)應(yīng)的C文件或者宏定義，實(shí)現(xiàn)一套代碼選擇性的編譯匹配不同的硬件主板或軟件需求。腳本方面可以參考微信公眾號(hào)** 嵌入式系統(tǒng)** 的 《[項(xiàng)目配置與編譯自動(dòng)化]

3、小節(jié)

因?yàn)榻涌跇?biāo)準(zhǔn)化，軟件與硬件解耦，業(yè)務(wù)邏輯和驅(qū)動(dòng)模塊解耦，功能組件相互獨(dú)立解耦，軟件復(fù)用度提高，多人并行開發(fā)，軟件質(zhì)量和進(jìn)度大大提高。

分層隔離的優(yōu)點(diǎn)很多，但也存在些弊端。

**1、資源消耗大 ** 因?yàn)槟K化、分層，存在冗余兼容代碼，對(duì)代碼存儲(chǔ)和RAM有一定要求，過于低端或者資源緊缺的芯片估計(jì)難以實(shí)現(xiàn)，但也可局部分層。

**2、配置多 ** 因?yàn)檐浖枰嫒莶煌酒⒉煌靼濉⒁约案鞣N功能組合，每個(gè)具體項(xiàng)目存在很多配置項(xiàng)，而且部分配置互相關(guān)聯(lián)，如果不熟悉或者沒有類似AUTOSAR的可視化工具，新加項(xiàng)目或者更換主板可能需要點(diǎn)時(shí)間。

**3、邏輯流程繁瑣 **分層軟件的特點(diǎn)是各種指針和內(nèi)存共享等，而且因?yàn)楦綦x，原本很簡單的操作需要經(jīng)過不同組件間接操作，流程不夠直接，代碼出現(xiàn)問題，排查比較困難。

總體來說，分層和模塊化是一種開發(fā)思想，需要結(jié)合硬件資源和團(tuán)隊(duì)特性來實(shí)施。

更多開發(fā)技巧與思路，請(qǐng)關(guān)注微信公眾號(hào) 嵌入式系統(tǒng)。