作者 | 不可說
出品 | 汽車電子與軟件
#01 前 言
汽車軟件SWC（Software Component）的概念主要來源于Autosar（Automotive Open System Architecture）架構，代表著汽車電子控制器中的軟件組件/單元，用以實現某些功能。
在SWC設計之前，需要進行一系列的準備和規劃工作，以確保后續設計的順利進行和項目的成功實施。
這些工作主要包括以下兩個方面：
1. 需求分析
明確功能需求：首先，需要明確SWC需要實現的具體功能，包括輸入輸出、處理邏輯、性能要求等。這通常來自于項目工程師或產品經理的需求文檔。劃分功能模塊：將整體功能需求細分為不同的功能模塊，這些模塊將對應不同的SWC。這有助于實現功能的模塊化設計，提高代碼的可維護性和復用性。
2. 系統架構設計
在明確功能需求的基礎上，需要設計整體的系統架構，包括SWC之間的層次關系和交互方式。AUTOSAR架構是一個常用的選擇，它提供了標準化的軟件架構和接口規范。
下面會提供一種需求分析思路與流程。
#02 需求分析關聯方及流程
FO ：function owner 功能負責人
1、用例與功能系統設計
用例，即Use Case；來源于用戶需求；可以由功能負責人分析、設計；用例（Use Case）驅動的開發方法是一種軟件開發策略，它強調以用戶為中心的設計思想，確保整個開發過程緊密圍繞用戶的實際需求進行。這種方法的核心在于，從用戶的視角出發，而非單純從技術或開發人員的便利性角度，來識別、定義和實現系統的功能需求。
具體而言，它包含以下幾個關鍵步驟和特性：
-
用戶參與與需求捕獲；
-
用例編寫：基于收集到的用戶需求，開發團隊會將這些需求轉化為具體的用例描述。每個用例都詳細描述了用戶（或系統外部實體）與系統進行交互的目的、前置條件、主要流程（包括成功路徑和異常路徑）、后置條件等，從而形成一個清晰的、可驗證的需求模型。
-
系統外部視角：用例驅動的開發方法特別重視從系統外部觀察系統的使用情況。這意味著開發人員需要跳出技術實現的細節，站在用戶的角度去思考系統應該如何工作，以及用戶在使用過程中可能會遇到哪些問題。這種視角有助于避免“內部人”思維，確保系統設計符合用戶的真實需求和使用習慣。
-
迭代開發與驗證：隨著用例的逐步細化，開發團隊會基于這些用例進行迭代開發。
- 持續反饋與調整：整個開發過程中，開發團隊與用戶之間保持密切溝通，及時收集用戶反饋。根據反饋結果，開發團隊可以對用例進行必要的調整和優化，以確保系統始終能夠滿足用戶的實際需求。
參與者：用戶
系統：主駕座椅加熱系統連線表示用戶與用例之間的關聯
如果用文字表述，需要分清晰層次來說明用例，如：
用例名：UC01-主駕座椅加熱2檔前置條件：座椅加熱狀態為關閉&主駕有人
操作：手動點擊屏幕主駕座椅加熱虛擬按鍵
后置狀態：座椅加熱開到2擋
如果需求完善，且實際硬件支持錯誤檢測，可以補充異常路徑：
異常路徑 ：彈窗提示，開啟失敗
2、能力設計
PC（Product Capabilities） 或者VC（Vehicle Capabilities）：是構成產品功能實現基石的核心概念，它源自于精心設計的架構平臺。在這個平臺上，PC/VC被明確定義為一系列可復用、可組合的基本功能單元，這些單元共同支撐起產品復雜多樣的功能體系。在產品的功能設計階段，開發團隊需要深入理解和挖掘PC/VC所提供的豐富能力，作為構建具體功能特性的基礎。
具體而言，每當面臨新的業務需求或用戶用例時，設計者們會首先審視并篩選適用的PC/VC單元。這些PC/VC單元就像一塊塊積木，通過不同的組合方式，能夠靈活、高效地搭建出滿足特定需求的功能模塊。此過程要求設計者對PC/VC有深刻的理解，能夠準確判斷哪些PC/VC能夠直接應用，哪些需要通過微調或擴展來滿足特定需求。
PC 的設計需要遵循如下原則：
-
PC具有唯一性：PC的唯一性體現在每個能力單元在系統中的身份識別上都是獨一無二的。這意味著，在定義PC時，我們會為每個能力賦予一個明確的、不重復的名稱和標識，以確保在整個產品開發周期內，無論是設計、開發還是維護階段，都能準確無誤地引用和識別這些能力。這樣的唯一性有助于避免功能重疊和混淆，確保產品功能的清晰劃分和高效實現。
-
PC具有獨立性：PC的獨立性是指每個能力單元在邏輯上是自洽的，不依賴于其他PC的具體實現細節。這意味著，一個PC可以獨立地被設計、測試和維護，而不必考慮它與其他PC之間的內部交互細節。這種獨立性提高了系統的可維護性和可擴展性，使得開發者可以專注于優化單個PC的性能和穩定性，而不必擔心對其他部分造成影響。
-
PC的顆粒度不能太小：在定義PC時，需要仔細考慮其顆粒度大小。顆粒度過小會導致PC數量過多，增加系統設計的復雜性和維護成本；而顆粒度過大則可能使得PC過于龐大，難以復用和組合。因此，合理的PC顆粒度應該是既能夠清晰地表達功能需求，又能夠保持足夠的復用性和組合靈活性。一般來說，PC應該聚焦于解決一類相似的問題或實現一組緊密相關的功能。
- PC的重用性：PC的重用是提升產品開發效率和質量的關鍵。通過定義可復用的PC，我們可以在不同的產品、項目或功能模塊中重復使用這些能力單元，減少重復勞動和錯誤。為了實現PC的重用，我們需要建立一套完善的PC庫，并對PC進行詳細的文檔化和版本管理。這樣，當新的需求出現時，開發者可以快速搜索和找到合適的PC進行復用，從而加速產品的開發進程。
根據上述劃分的原則，可以設計如下的PC來實現上面舉例的UC；
3、模塊設計
即Module DesignSystem Architect在接收到Function Owner的PC需求后，會組織一次跨部門或團隊的會議，需要全面評估這些需求對系統整體架構的影響。會議參與者可能包括硬件專家、軟件開發者、項目經理及其他相關利益方。通過集體討論，團隊會首先探索是否可以利用現有系統中的PC資源來滿足新功能的需要。
如果經過綜合考量，確定現有PC無法滿足新功能的要求，或者采用現有PC會導致不必要的復雜性和成本增加，System Architect會提出新增PC的提議。接下來，System Architect將負責將新增PC的需求細化為具體的規格參數，并依據系統架構的邏輯和功能模塊的劃分，將這些PC資源合理地分配至最適合的Module。
在分配過程中，System Architect會確保新增PC能夠無縫集成到現有的系統架構中，同時保持各模塊間的獨立性和可擴展性。如果遇到沒有直接對應的Module來容納新增PC的情況，System Architect將承擔起創建新Module的責任。這包括定義新Module的邊界、功能范圍、與其他模塊的交互接口以及所需的集成策略，以確保新Module的引入不會破壞系統的整體穩定性和性能。
整個過程中，System Architect還會與Function Owner保持緊密溝通，確保新增PC的需求得到充分理解和滿足，并在必要時對設計方案進行調整，直至達成雙方認可的最優解決方案。
可以設計如下的Module來實現上面舉例的PC，在實際開發中要注意PC的實現不能重復或者遺漏：
4、模塊部署
在詳細規劃與實現過程中，首先需明確每個Module（模塊）的具體功能及其所需的輸入輸出接口、處理邏輯、以及預期的性能指標。隨后，基于這些詳盡的功能定義，我們可以將各個Module逐一分配到對應的電子控制系統中去實現，這一過程涉及以下幾個關鍵步驟以確保清晰性、具體性和條理性：
功能細化與分類：首先，對每個Module的功能進行細化分析，識別出哪些是數據處理功能、哪些是控制邏輯功能、哪些是通信接口功能等。根據功能類型，將Module劃分為不同的類別，如傳感器數據處理模塊、執行器控制模塊、通信協議轉換模塊等。
系統匹配與選擇：根據已劃分的Module類別，評估現有的電子控制系統的技術特點、處理能力、接口資源及成本效益，為每個類別的Module選擇最合適的電子控制系統。這一步驟需要綜合考慮系統的可擴展性、可維護性、以及與現有系統或設備的兼容性。
接口定義與協議制定：為選定的電子控制系統與Module之間定義清晰的接口規范，包括物理接口（如GPIO、串口、網口等）、通信協議（如CAN、Modbus、Ethernet/IP等）、數據格式與傳輸速率等。確保Module與控制系統之間能夠順暢、高效地進行數據交換和控制指令的傳遞。
根據設計部署經驗及原則，上述兩個Module均可部署在車身控制器中；
#03 小 結
至此，我們可以認為已經完成了軟件組件（SWC）設計前期的核心任務——軟件需求分析。這一階段的成功標志著我們對系統需求有了全面而深入的理解，并能夠將這些需求轉化為具體的軟件功能要求。然而，上述描述僅代表了一種理想化的正向設計流程概覽，僅提供了一個清晰的起點和方向。
在實際的軟件與系統開發過程中，往往會遇到遠比理論描述更為復雜多變的場景。UC與Module之間的追溯關系錯綜復雜，它們之間不僅存在直接的映射，還可能涉及多對多、層級嵌套或相互依賴的關系。這種復雜性要求我們在設計過程中保持高度的靈活性和嚴謹性，以確保每一個功能需求都能被準確無誤地映射到相應的軟件模塊上，同時保證模塊間的接口清晰、耦合度低，便于后續的維護和擴展。 為了有效應對這些挑戰，我們可以考慮引入一系列先進的工具和技術來輔助設計管理。例如，利用需求管理工具來跟蹤和管理需求變更，確保所有相關方對需求的理解保持一致；采用UML（統一建模語言）或SysML（系統建模語言）等建模工具來構建系統的邏輯架構和物理架構，直觀展示UC與Module之間的追溯關系；通過版本控制系統來管理設計文檔和代碼，確保設計的一致性和可追溯性；以及利用自動化測試工具來驗證設計實現是否符合需求規格說明，提高軟件質量。不過工具只是輔助手段，應權衡利弊，不應被其復雜的操作所拖累。
