作者 | 不可說
出品 | 汽車電子與軟件
#01 前 言
汽車軟件SWC（Software Component）的概念主要來源於AUTOSAR（Automotive Open System Architecture）架構。
在Autosar架構中，SWC是核心概念之一，代表了一個獨立的、可重用的、自我描述的、可替換(huan)的軟件單元(yuan)。這些軟件組件具有(you)清晰的輸入輸出接口，相(xiang)較於整個汽車電子係統來說，是一個更小的功能模塊。
SWC可以是一個可執行的模塊或者是一個庫，它獨立於其他(ta)組件工作，自帶(dai)相(xiang)應(ying)的狀(zhuang)態和管理(li)接口。SWC之間的通信通過AUTOSAR定義(yi)的接口進行，這些接口確保了不同組件之間的互操作性和數據交換(huan)的標準化。
#02 SWC開發輸入
SWC的設計開發工作是軟件架構設計領域中一個至關重要的環節。它不僅僅是架構藍圖中的一部分，更是實現軟件功能、提升係統性能、確保可維護性和可擴展性的基石。作為軟件架構的開發者，整個工作流程需(xu)遵循嚴格的邏輯與係統性，以充分理(li)解和分析軟件需(xu)求(qiu)為起點。
按照ASPICE開發流程，SWC的設計屬於SWE.2軟件架構設計的工作，需(xu)要接收(shou)來自於SWE.1的軟件需(xu)求(qiu)分析輸出，基於深入分析的需(xu)求(qiu)，架構師著手規劃SWC的設計。這包(bao)括定義(yi)組件的接口（即對外提供(gong)的服務和所需(xu)的環境或數據），明確組件的職責範圍（即它能做什(shi)麼和不能做什(shi)麼），以及設計組件內部的邏輯結構和數據流。在設計過程中，需(xu)考慮組件的複用性、解耦程度、與係統中其他(ta)組件的交互方式等因素(su)，以確保設計既(ji)能滿足(zu)當(dang)前需(xu)求(qiu)，又能為未來的擴展和維護預留空間。
如按照軟件需(xu)求(qiu)的PC（Product Capabilities） /Module分析方法論，分析如下主駕(jia)座椅加熱用戶需(xu)求(qiu)Case：
UC 01 : 座椅加熱關閉(bi)時，手動點擊(ji)屏(ping)幕主駕(jia)座椅加熱虛擬按鍵，座椅加熱開到2擋
UC 02 : 座椅加熱2擋位時，手動點擊(ji)屏(ping)幕主駕(jia)座椅加熱虛擬按鍵，座椅加熱開到1擋
UC 03 : 座椅加熱1擋位時，手動點擊(ji)屏(ping)幕主駕(jia)座椅加熱虛擬按鍵，座椅加熱關閉(bi)
UC 04 : 座椅加熱開啟時時，且(qie)主駕(jia)離座時，觸發座椅加熱關閉(bi)
軟件架構開發工作者收(shou)到類似如下圖的分析結果，（副駕(jia)座椅加熱有(you)同樣(yang)需(xu)求(qiu)，此處不做額外展示），就可以進行下一步的進行軟件架構的設計工作；
#03 SWC劃分
3.1 SWC分層
在SWC設計中，一般開發者會根據經(jing)驗(yan)，按照PC的功能範疇(chou)來劃分SWC，除此之外，可以考慮采用分層設計的思(si)路，目的是使得SWC具有(you)更好的操作性與可重用性，即使得軟件組件可以在不同的汽車平(ping)台和項目中複用，減少了重複開發的工作量(liang)，提高了開發效率，分層設計也(ye)可以將應(ying)用軟件邏輯層與執行層隔離開來，降低(di)了應(ying)邏輯對下層BSW的依賴，提高了係統的穩定性和可靠性。例如，可以分為SA（Sensors and actuators）層與VC（Vehicle Control）層SWC；
以第(di)二小節中的需(xu)求(qiu)輸入為例，可以劃分兩個SWC：
VC層SWC：主副駕(jia)座椅占位狀(zhuang)態檢測，即接收(shou)屏(ping)幕按鍵狀(zhuang)態、座椅加熱狀(zhuang)態，給出加熱關閉(bi)判定；
SA層SWC：主副駕(jia)座椅加熱請求(qiu)與主副駕(jia)座椅加熱狀(zhuang)態檢測，綜合給出加熱關閉(bi)判定；
座椅加熱SWC劃分
3.2 SWC區域化劃分
在當(dang)今(jin)汽車技術日新月(yue)異的時代背景下，電子電氣架構（EEA）正(zheng)經(jing)曆著前所未有(you)的深刻變(bian)革(ge)，這一變(bian)革(ge)不僅重塑了車輛內部係統的布局(ju)與交互方式，還深刻影(ying)響了車輛上電子控製單元(yuan)（ECU）的角色定位與開發流程。從分布式電子電氣架構，到現如今(jin)應(ying)用最為廣(guang)泛的域控製器電子電氣架構，更進一步的架構發展是為了應(ying)對更高級別的自動駕(jia)駛需(xu)求(qiu)和不斷增加的車輛內部複雜度，區域控製器電子電氣架構的概念開始浮現。在這一架構下，車輛被劃分為幾(ji)個邏輯或物(wu)理(li)上的區域，每個區域由(you)專(zhuan)門的區域控製器管理(li)，這些區域控製器之間通過高速(su)網絡進行通信，實現信息的實時共享與協同控製。
具體到BCM（車身(shen)控製模塊）控製器，作為車身(shen)域中的重要組成部分，其功能在傳統架構中主要負責燈(deng)光、門窗、雨刮等車身(shen)附(fu)件的控製。然而，在下一代電子電氣架構的演進過程中，BCM的功能很可能會根據區域劃分的需(xu)求(qiu)被拆分成左右兩個區域控製器來實現，每個區域控製器負責相(xiang)應(ying)側車身(shen)附(fu)件的集中控製，為了將應(ying)用軟件平(ping)台化，可以做出如下劃分，
也(ye)就是將上一小節中的SA層SWC拆分為主副駕(jia)座椅加熱功能分別執行的兩個SWC，當(dang)下一代區域控製電子電氣架構導入時，VC層的SWC可以直(zhi)接部署在中央計算平(ping)台內，SA層的兩個SWC就分別部署在左右區域控製器中；極大的增強了SWC的重用性；
盡管將SWC拆分成更細致的模塊能夠顯(xian)著提升其重用性和靈活性，從而降低(di)開發成本並加速(su)產品上市時間，然而，這種(zhong)高度的細分化在當(dang)前的開發平(ping)台上也(ye)伴隨著一係列問題(ti)。具體而言，過於細化的模塊劃分往往意味著模塊間的內部信號交互將顯(xian)著增加，這不僅會加大係統的複雜性和維護難度，還可能引(yin)入額外的性能開銷，如通信延遲(chi)和額外的處理(li)負擔。
因此，作為架構開發者，在決定SWC模塊劃分的精細度時，必須采取(qu)一種(zhong)平(ping)衡(heng)且(qie)全麵的視角。
首先，需(xu)要深入了解並評估公司當(dang)前的開發平(ping)台特性，包(bao)括其支持的通信機製、性能瓶頸、內存限製以及擴展能力(li)等因素(su)。這有(you)助(zhu)於開發者在模塊劃分時避免設計出超出平(ping)台承載能力(li)或難以實現的架構。
其次，規劃也(ye)是不可或缺的一環。開發者需(xu)要根據公司長遠的發展戰略、項目目標以及預期的產品迭(die)代周(zhou)期，來製定合適的SWC劃分策略。這包(bao)括考慮未來可能的需(xu)求(qiu)變(bian)更、技術升級以及模塊間的依賴關係，確保架構既(ji)能滿足(zu)當(dang)前需(xu)求(qiu)，又能靈活應(ying)對未來的變(bian)化。
#04 SWC 設計
在設計SWC交互信息時，需(xu)要基於軟件需(xu)求(qiu)分析報告(gao)，我們著手為各個功能模塊創建對應(ying)的SWC外部接口。這一過程首先涉(she)及對需(xu)求(qiu)文檔中明確指(zhi)出的功能模塊與外部係統或組件之間的交互信息進行細致解析。這些交互信息通常包(bao)括了通信協議、消息格式、以及觸發交互的條件等關鍵要素(su)。隨後，我們根據這些要求(qiu)，為每一個SWC設計並定義(yi)其外部Port、Interface、參數類型等，確保這些信息能夠準確無誤地反映功能模塊與外界的交互需(xu)求(qiu)。
在創建外部接口的過程中，我們尤為注重為每個接口精心規劃其參數列表以及相(xiang)應(ying)的數據類型。參數的選(xuan)擇需(xu)緊密(mi)貼合功能模塊的業務邏輯和交互需(xu)求(qiu)，數據類型則必須明確且(qie)一致，以避免在後續(xu)的開發和集成過程中出現數據不匹(pi)配或理(li)解歧(qi)義(yi)的問題(ti)。通過這樣(yang)的細致規劃，我們旨(zhi)在構建一個清晰、規範且(qie)易(yi)於理(li)解和維護的SWC接口體係。
此外，除了遵循需(xu)求(qiu)分析中定義(yi)的外部交互外，如果我們將功能模塊進一步細化為多(duo)個SWC時，我們必然需(xu)要處理(li)這些SWC之間的內部交互問題(ti)。為此，我們需(xu)要明確每個SWC之間的交互點，即內部SWC之間的Port/Interface的設定。這些Port/Interface將作為SWC間通信的橋梁，通過RTE負責傳遞數據和指(zhi)令(ling)。
在確定Port/Interface後，我們還需(xu)要為每個交互點詳細定義(yi)所需(xu)的參數以及對應(ying)的數據類型。這些參數應(ying)當(dang)能夠完整表達SWC間傳遞的信息內容，而數據類型的選(xuan)擇則需(xu)確保數據的一致性和準確性。通過這樣(yang)的規劃，我們能夠實現SWC間的高效、可靠的交互。
根據3.1小節中對SWC的劃分設計，給出如下Port設計和展示：
座椅加熱SWC的Port設計
接口的設計規範在軟件開發過程中占據著至關重要的地位，它通常需(xu)要組織內部通過一係列會議商定出來的的準則來確保接口的統一性和一致性。目的是構建一個清晰、可預測且(qie)易(yi)於理(li)解的接口體係，從而極大地提升開發效率，降低(di)維護成本，並促進團隊內部及跨團隊之間的協作。
具體而言，接口設計規範應(ying)包(bao)含(han)以下幾(ji)個方麵來確保開發者能夠較為容易(yi)地辨識接口所表示的含(han)義(yi)及其代表的屬性：
命名規範：接口及其方法、參數、返回值(zhi)等命名應(ying)遵循一致的命名約(yue)定，如使用駝(tuo)峰命名法或下劃線分隔等，同時確保名稱能夠直(zhi)觀反映其功能和作用，便於開發者理(li)解和記憶。
注釋文檔：為接口及其組成部分提供(gong)詳盡的注釋文檔，包(bao)括功能描述、參數說明、返回值(zhi)類型及可能的異常信息等。這些文檔應(ying)采用統一格式編寫，如使用Markdown或特定API文檔工具，以便於自動化生成和維護。版本控製：明確接口的版本管理(li)策略，確保接口的變(bian)更能夠被有(you)效追(zhui)蹤和記錄。對於不兼容的變(bian)更，應(ying)提供(gong)清晰的升級指(zhi)南或遷(qian)移路徑(jing)，以減輕(qing)對現有(you)係統的影(ying)響。
數據規範：定義(yi)接口交互過程中涉(she)及的數據格式、編碼(ma)方式及數據校驗(yan)規則等。這有(you)助(zhu)於保證數據的準確性、一致性和安全性，減少因數據格式不一致導致的錯誤。
所有(you)關聯開發者通過遵循這些規範，可以顯(xian)著提升軟件開發的質量(liang)和效率。
Port口對應(ying)的參數類型大致上也(ye)需(xu)要按照上麵的約(yue)定來製定，這裏不會給出詳細的規範說明，畢竟(jing)由(you)於軟件開發的高度靈活性和多(duo)樣(yang)性，不同的開發者或開發團隊可能會根據自己的項目需(xu)求(qiu)、技術棧偏好、以及過往經(jing)驗(yan)，對這些約(yue)定進行不同程度的調整或擴展。因此，雖(sui)然存在某(mou)種(zhong)普遍接受的“一般性”做法，但實際(ji)應(ying)用中卻(que)鮮(xian)有(you)完全一致的“普適性”規範。
對於SWC設計的關聯信息可以使用表格或者其他(ta)工具進行管理(li)，個人設計座椅加熱功能中主副駕(jia)座椅占位檢測SWC設計信息如下：
|
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 即表明接口的參數類型、範圍、單位、初始值(zhi)等信息，一般需(xu)要單獨維護：
|
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 |
“一千家開發者有(you)一千八百種(zhong)開發習(xi)慣”，在設計Port、接口、參數類型時，雖(sui)然可以借鑒已(yi)有(you)的成功經(jing)驗(yan)和行業標準，但更重要的是結合項目實際(ji)情況，靈活調整，確保設計方案既(ji)符合項目需(xu)求(qiu)，又能夠高效、穩定地運行。
