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