作者 | 不可說
出品 | 汽車電子與軟件
#01 前 言
汽車軟件SWC（Software Component）的概念主要來源于AUTOSAR（Automotive Open System Architecture）架構(gòu)。
在Autosar架構(gòu)中，SWC是核心概念之一，代表了一個(gè)獨(dú)立的、可重用的、自我描述的、可替換的軟件單元。這些軟件組件具有清晰的輸入輸出接口，相較于整個(gè)汽車電子系統(tǒng)來說，是一個(gè)更小的功能模塊。
SWC可以是一個(gè)可執(zhí)行的模塊或者是一個(gè)庫，它獨(dú)立于其他組件工作，自帶相應(yīng)的狀態(tài)和管理接口。SWC之間的通信通過AUTOSAR定義的接口進(jìn)行，這些接口確保了不同組件之間的互操作性和數(shù)據(jù)交換的標(biāo)準(zhǔn)化。
#02 SWC開發(fā)輸入
SWC的設(shè)計(jì)開發(fā)工作是軟件架構(gòu)設(shè)計(jì)領(lǐng)域中一個(gè)至關(guān)重要的環(huán)節(jié)。它不僅僅是架構(gòu)藍(lán)圖中的一部分，更是實(shí)現(xiàn)軟件功能、提升系統(tǒng)性能、確保可維護(hù)性和可擴(kuò)展性的基石。作為軟件架構(gòu)的開發(fā)者，整個(gè)工作流程需遵循嚴(yán)格的邏輯與系統(tǒng)性，以充分理解和分析軟件需求為起點(diǎn)。
按照ASPICE開發(fā)流程，SWC的設(shè)計(jì)屬于SWE.2軟件架構(gòu)設(shè)計(jì)的工作，需要接收來自于SWE.1的軟件需求分析輸出，基于深入分析的需求，架構(gòu)師著手規(guī)劃SWC的設(shè)計(jì)。這包括定義組件的接口（即對外提供的服務(wù)和所需的環(huán)境或數(shù)據(jù)），明確組件的職責(zé)范圍（即它能做什么和不能做什么），以及設(shè)計(jì)組件內(nèi)部的邏輯結(jié)構(gòu)和數(shù)據(jù)流。在設(shè)計(jì)過程中，需考慮組件的復(fù)用性、解耦程度、與系統(tǒng)中其他組件的交互方式等因素，以確保設(shè)計(jì)既能滿足當(dāng)前需求，又能為未來的擴(kuò)展和維護(hù)預(yù)留空間。
如按照軟件需求的PC（Product Capabilities） /Module分析方法論，分析如下主駕座椅加熱用戶需求Case：
UC 01 : 座椅加熱關(guān)閉時(shí)，手動點(diǎn)擊屏幕主駕座椅加熱虛擬按鍵，座椅加熱開到2擋
UC 02 : 座椅加熱2擋位時(shí)，手動點(diǎn)擊屏幕主駕座椅加熱虛擬按鍵，座椅加熱開到1擋
UC 03 : 座椅加熱1擋位時(shí)，手動點(diǎn)擊屏幕主駕座椅加熱虛擬按鍵，座椅加熱關(guān)閉
UC 04 : 座椅加熱開啟時(shí)時(shí)，且主駕離座時(shí)，觸發(fā)座椅加熱關(guān)閉
軟件架構(gòu)開發(fā)工作者收到類似如下圖的分析結(jié)果，（副駕座椅加熱有同樣需求，此處不做額外展示），就可以進(jìn)行下一步的進(jìn)行軟件架構(gòu)的設(shè)計(jì)工作；
#03 SWC劃分
3.1 SWC分層
在SWC設(shè)計(jì)中，一般開發(fā)者會根據(jù)經(jīng)驗(yàn)，按照PC的功能范疇來劃分SWC，除此之外，可以考慮采用分層設(shè)計(jì)的思路，目的是使得SWC具有更好的操作性與可重用性，即使得軟件組件可以在不同的汽車平臺和項(xiàng)目中復(fù)用，減少了重復(fù)開發(fā)的工作量，提高了開發(fā)效率，分層設(shè)計(jì)也可以將應(yīng)用軟件邏輯層與執(zhí)行層隔離開來，降低了應(yīng)邏輯對下層BSW的依賴，提高了系統(tǒng)的穩(wěn)定性和可靠性。例如，可以分為SA（Sensors and actuators）層與VC（Vehicle Control）層SWC；
以第二小節(jié)中的需求輸入為例，可以劃分兩個(gè)SWC：
VC層SWC：主副駕座椅占位狀態(tài)檢測，即接收屏幕按鍵狀態(tài)、座椅加熱狀態(tài)，給出加熱關(guān)閉判定；
SA層SWC：主副駕座椅加熱請求與主副駕座椅加熱狀態(tài)檢測，綜合給出加熱關(guān)閉判定；
座椅加熱SWC劃分
3.2 SWC區(qū)域化劃分
在當(dāng)今汽車技術(shù)日新月異的時(shí)代背景下，電子電氣架構(gòu)（EEA）正經(jīng)歷著前所未有的深刻變革，這一變革不僅重塑了車輛內(nèi)部系統(tǒng)的布局與交互方式，還深刻影響了車輛上電子控制單元（ECU）的角色定位與開發(fā)流程。從分布式電子電氣架構(gòu)，到現(xiàn)如今應(yīng)用最為廣泛的域控制器電子電氣架構(gòu)，更進(jìn)一步的架構(gòu)發(fā)展是為了應(yīng)對更高級別的自動駕駛需求和不斷增加的車輛內(nèi)部復(fù)雜度，區(qū)域控制器電子電氣架構(gòu)的概念開始浮現(xiàn)。在這一架構(gòu)下，車輛被劃分為幾個(gè)邏輯或物理上的區(qū)域，每個(gè)區(qū)域由專門的區(qū)域控制器管理，這些區(qū)域控制器之間通過高速網(wǎng)絡(luò)進(jìn)行通信，實(shí)現(xiàn)信息的實(shí)時(shí)共享與協(xié)同控制。
具體到BCM（車身控制模塊）控制器，作為車身域中的重要組成部分，其功能在傳統(tǒng)架構(gòu)中主要負(fù)責(zé)燈光、門窗、雨刮等車身附件的控制。然而，在下一代電子電氣架構(gòu)的演進(jìn)過程中，BCM的功能很可能會根據(jù)區(qū)域劃分的需求被拆分成左右兩個(gè)區(qū)域控制器來實(shí)現(xiàn)，每個(gè)區(qū)域控制器負(fù)責(zé)相應(yīng)側(cè)車身附件的集中控制，為了將應(yīng)用軟件平臺化，可以做出如下劃分，
也就是將上一小節(jié)中的SA層SWC拆分為主副駕座椅加熱功能分別執(zhí)行的兩個(gè)SWC，當(dāng)下一代區(qū)域控制電子電氣架構(gòu)導(dǎo)入時(shí)，VC層的SWC可以直接部署在中央計(jì)算平臺內(nèi)，SA層的兩個(gè)SWC就分別部署在左右區(qū)域控制器中；極大的增強(qiáng)了SWC的重用性；
盡管將SWC拆分成更細(xì)致的模塊能夠顯著提升其重用性和靈活性，從而降低開發(fā)成本并加速產(chǎn)品上市時(shí)間，然而，這種高度的細(xì)分化在當(dāng)前的開發(fā)平臺上也伴隨著一系列問題。具體而言，過于細(xì)化的模塊劃分往往意味著模塊間的內(nèi)部信號交互將顯著增加，這不僅會加大系統(tǒng)的復(fù)雜性和維護(hù)難度，還可能引入額外的性能開銷，如通信延遲和額外的處理負(fù)擔(dān)。
因此，作為架構(gòu)開發(fā)者，在決定SWC模塊劃分的精細(xì)度時(shí)，必須采取一種平衡且全面的視角。
首先，需要深入了解并評估公司當(dāng)前的開發(fā)平臺特性，包括其支持的通信機(jī)制、性能瓶頸、內(nèi)存限制以及擴(kuò)展能力等因素。這有助于開發(fā)者在模塊劃分時(shí)避免設(shè)計(jì)出超出平臺承載能力或難以實(shí)現(xiàn)的架構(gòu)。
其次，規(guī)劃也是不可或缺的一環(huán)。開發(fā)者需要根據(jù)公司長遠(yuǎn)的發(fā)展戰(zhàn)略、項(xiàng)目目標(biāo)以及預(yù)期的產(chǎn)品迭代周期，來制定合適的SWC劃分策略。這包括考慮未來可能的需求變更、技術(shù)升級以及模塊間的依賴關(guān)系，確保架構(gòu)既能滿足當(dāng)前需求，又能靈活應(yīng)對未來的變化。
#04 SWC 設(shè)計(jì)
在設(shè)計(jì)SWC交互信息時(shí)，需要基于軟件需求分析報(bào)告，我們著手為各個(gè)功能模塊創(chuàng)建對應(yīng)的SWC外部接口。這一過程首先涉及對需求文檔中明確指出的功能模塊與外部系統(tǒng)或組件之間的交互信息進(jìn)行細(xì)致解析。這些交互信息通常包括了通信協(xié)議、消息格式、以及觸發(fā)交互的條件等關(guān)鍵要素。隨后，我們根據(jù)這些要求，為每一個(gè)SWC設(shè)計(jì)并定義其外部Port、Interface、參數(shù)類型等，確保這些信息能夠準(zhǔn)確無誤地反映功能模塊與外界的交互需求。
在創(chuàng)建外部接口的過程中，我們尤為注重為每個(gè)接口精心規(guī)劃其參數(shù)列表以及相應(yīng)的數(shù)據(jù)類型。參數(shù)的選擇需緊密貼合功能模塊的業(yè)務(wù)邏輯和交互需求，數(shù)據(jù)類型則必須明確且一致，以避免在后續(xù)的開發(fā)和集成過程中出現(xiàn)數(shù)據(jù)不匹配或理解歧義的問題。通過這樣的細(xì)致規(guī)劃，我們旨在構(gòu)建一個(gè)清晰、規(guī)范且易于理解和維護(hù)的SWC接口體系。
此外，除了遵循需求分析中定義的外部交互外，如果我們將功能模塊進(jìn)一步細(xì)化為多個(gè)SWC時(shí)，我們必然需要處理這些SWC之間的內(nèi)部交互問題。為此，我們需要明確每個(gè)SWC之間的交互點(diǎn)，即內(nèi)部SWC之間的Port/Interface的設(shè)定。這些Port/Interface將作為SWC間通信的橋梁，通過RTE負(fù)責(zé)傳遞數(shù)據(jù)和指令。
在確定Port/Interface后，我們還需要為每個(gè)交互點(diǎn)詳細(xì)定義所需的參數(shù)以及對應(yīng)的數(shù)據(jù)類型。這些參數(shù)應(yīng)當(dāng)能夠完整表達(dá)SWC間傳遞的信息內(nèi)容，而數(shù)據(jù)類型的選擇則需確保數(shù)據(jù)的一致性和準(zhǔn)確性。通過這樣的規(guī)劃，我們能夠?qū)崿F(xiàn)SWC間的高效、可靠的交互。
根據(jù)3.1小節(jié)中對SWC的劃分設(shè)計(jì)，給出如下Port設(shè)計(jì)和展示：
座椅加熱SWC的Port設(shè)計(jì)
接口的設(shè)計(jì)規(guī)范在軟件開發(fā)過程中占據(jù)著至關(guān)重要的地位，它通常需要組織內(nèi)部通過一系列會議商定出來的的準(zhǔn)則來確保接口的統(tǒng)一性和一致性。目的是構(gòu)建一個(gè)清晰、可預(yù)測且易于理解的接口體系，從而極大地提升開發(fā)效率，降低維護(hù)成本，并促進(jìn)團(tuán)隊(duì)內(nèi)部及跨團(tuán)隊(duì)之間的協(xié)作。
具體而言，接口設(shè)計(jì)規(guī)范應(yīng)包含以下幾個(gè)方面來確保開發(fā)者能夠較為容易地辨識接口所表示的含義及其代表的屬性：
命名規(guī)范：接口及其方法、參數(shù)、返回值等命名應(yīng)遵循一致的命名約定，如使用駝峰命名法或下劃線分隔等，同時(shí)確保名稱能夠直觀反映其功能和作用，便于開發(fā)者理解和記憶。
注釋文檔：為接口及其組成部分提供詳盡的注釋文檔，包括功能描述、參數(shù)說明、返回值類型及可能的異常信息等。這些文檔應(yīng)采用統(tǒng)一格式編寫，如使用Markdown或特定API文檔工具，以便于自動化生成和維護(hù)。版本控制：明確接口的版本管理策略，確保接口的變更能夠被有效追蹤和記錄。對于不兼容的變更，應(yīng)提供清晰的升級指南或遷移路徑，以減輕對現(xiàn)有系統(tǒng)的影響。
數(shù)據(jù)規(guī)范：定義接口交互過程中涉及的數(shù)據(jù)格式、編碼方式及數(shù)據(jù)校驗(yàn)規(guī)則等。這有助于保證數(shù)據(jù)的準(zhǔn)確性、一致性和安全性，減少因數(shù)據(jù)格式不一致導(dǎo)致的錯(cuò)誤。
所有關(guān)聯(lián)開發(fā)者通過遵循這些規(guī)范，可以顯著提升軟件開發(fā)的質(zhì)量和效率。
Port口對應(yīng)的參數(shù)類型大致上也需要按照上面的約定來制定，這里不會給出詳細(xì)的規(guī)范說明，畢竟由于軟件開發(fā)的高度靈活性和多樣性，不同的開發(fā)者或開發(fā)團(tuán)隊(duì)可能會根據(jù)自己的項(xiàng)目需求、技術(shù)棧偏好、以及過往經(jīng)驗(yàn)，對這些約定進(jìn)行不同程度的調(diào)整或擴(kuò)展。因此，雖然存在某種普遍接受的“一般性”做法，但實(shí)際應(yīng)用中卻鮮有完全一致的“普適性”規(guī)范。
對于SWC設(shè)計(jì)的關(guān)聯(lián)信息可以使用表格或者其他工具進(jìn)行管理，個(gè)人設(shè)計(jì)座椅加熱功能中主副駕座椅占位檢測SWC設(shè)計(jì)信息如下：
|
SWC Name |
Port Name |
Port Direction |
Interface Name |
Interface Type |
Data Type |
|
SeatHeatOccy |
R_DrSeatOccupySt |
IN |
IF_DrSeatOccupySt |
Receiver |
DT_CommSts |
|
R_AsSeatOccupySt |
IN |
IF_AsSeatOccupySt |
Receiver |
DT_CommSts |
|
|
S_DrSeatHeatCoordReq |
OUT |
IF_DrSeatHeatCoordReq |
Sender |
DT_CommReq |
|
|
S_AsSeatHeatCoordReq |
OUT |
IF_AsSeatHeatCoordReq |
Sender |
DT_CommReq |
Data Type 即表明接口的參數(shù)類型、范圍、單位、初始值等信息，一般需要單獨(dú)維護(hù)：
|
Data Type |
Base Type |
Min value |
Max value |
……
|
Data Detile |
|
DT_CommSts |
Enum |
0 |
1 |
…… |
0：kClose 1：kOpen |
|
DT_CommReq |
Enum |
0 |
1 |
…… |
0：kNO_Req 1：kReq |
“一千家開發(fā)者有一千八百種開發(fā)習(xí)慣”，在設(shè)計(jì)Port、接口、參數(shù)類型時(shí)，雖然可以借鑒已有的成功經(jīng)驗(yàn)和行業(yè)標(biāo)準(zhǔn)，但更重要的是結(jié)合項(xiàng)目實(shí)際情況，靈活調(diào)整，確保設(shè)計(jì)方案既符合項(xiàng)目需求，又能夠高效、穩(wěn)定地運(yùn)行。
