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