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