第一次接觸“架構性需求”，大約在六年前，當時一位大佬指導我們說，在前期產品規劃時，最重要的就是找到“架構性需求”。本人就一頭的問號，“架構性需求”是什么？我沒有聽錯吧？當時也沒怎么放在心上，直到近年架構設計經驗增多，才領悟這句話的正確性。

什么是？

首先，什么是需求？

需求是一個多義詞，它的準確所指往往取決于你所處的位置。在汽車行業我們往往會利用ASPICE的V模型來找到自己需求的來源。比如做詳細設計，其需求來源就是架構設計。

但是這個理解是不準確的，下圖的表述會更加準確，也就是說本層次的需求往往有三個來源，以Domain level - Functional architecture步驟為例：

Vehicle level的Functional architecture

Vehicle level的Logical architecture

Domain level的Requirements

RFLP: MBSE背后的方法論

什么是架構性需求？

架構性需求是整個系統的最重要的那些需求，它可能出現在產品開發的各個層次和各個階段，對產品的形態、功能、開發周期等等往往起著決定性的作用。它們最大的特征是：只能在項目早期出現，在項目中期出現往往會導致巨大的工作量，甚至需要將整個項目推倒重來。

典型的架構性需求一般有這么三類（但也有不少不在其中）：

系統的主要功能需求，它們確定了這個系統必須擁有的功能。比如：汽車必須能在路上開、SOA通信框架必須能跨MPU和MCU通信等等。

質量需求和非功能性需求，一般是指這個系統的那些功能要完成的有多好。比如剎車系統必須達到ASIL-D標準、最差通信時延必須在1ms以內等等。

決定了解決方案和項目的各種約束條件。比如X項目必須在1年之內完成、某ECU的內存只有100KB等等。

那么接下來以汽車行業的典型“架構性需求”為例，從不同的層次依次展開講講。

2. 整車級別

整車級別的架構性需求會特別多，就會有下面這些：

車輛的售價：定價20萬區間的車，如果中途說改成要賣40萬，幾乎就是不可能完成的任務。

上市時間：一輛新車的正向開發時間普遍要3年左右，如果說要1年內上市一款新車，那整體的開發策略會完全不一樣。

這個環節離用戶會比較接近，大家一看就明白，我就不多講了。

3. 域(子系統)級別域指的是功能域，一般乘用車會分為“座艙域”、“智駕域”、“車輛控制域”、“動力底盤域”等等。這里以座艙域的“3秒內倒車影像啟動”展開講。

種類：非功能性需求

這個需求是由整車級別的R和F同時作用下，才決定了是否需要這個需求： -車輛的售價決定了是否需要高品質

-車輛的功能拆解決定了是否有倒車影像

自從車載倒車影像出現以來，在車輛啟動之后3秒內，倒車影像就可以正常工作就是個基礎需求。否則的話，司機系好安全帶后若要倒車，就只能傻坐著，用戶體驗非常之差。 這個需求對于Linux時代的車載多媒體系統不是問題，因為Linux本身啟動就比較快。但是當車載多媒體系統進入Android時代，就要了命了。

下圖是Android的啟動順序，Android的界面要能顯示圖像，需要至少到下面的Normal Mode處。當前行業的優秀水平是15秒以內完全啟動。那怎么辦呢？

http://www.ryantzj.com/boot-sequence-in-android.html

行業一般有幾種辦法：

駝鳥大法：忽略這個需求，15秒就讓用戶等吧，反正我這車也便宜。

深度改造法：對Android系統進行深度定制，比如將倒車影像的啟動順序直接提前到跟Zygote并行啟動。但這個的研發成本很高，需要引入一套新的GUI系統，因為這時Android的UI系統還沒啟動完畢呢。

Hypervisor法：近年來不少芯片都支持Hypervisor，就直接將倒車影像的精簡版本部署到啟動較快的系統上，如Linux或QNX。在快啟階段使用精簡版本的功能，等到Android完全啟動后再切換至完整版本。

休眠法：某些芯片支持在關機時將當前系統狀態保存至Flash上，這樣下次開機就能更快了。但支持這個功能代價是很高的，首先是這種芯片就不多，然后還得浪費幾個G的寶貴空間用于保存狀態。

不下電法：對于純電車，干脆就不讓車機下電，后果就是每天要多掉個幾公里續航，并且對系統的穩定性提出了更高的要求。畢竟每次關機都是清除系統垃圾的機會，不關機就沒有這個時機了。

不管哪個解決辦法，這個看似簡單的“3秒啟動”的需求，搞出了這么多解決方案，也是讓各大廠商的工程師掉了好多頭發。

4.ECU級別

各個域的功能設計做進一步的拆解，就落到了ECU里面。這里就以MCU的“極少的內存（以KB為單位）”做展開。

種類：約束條件

這個需求的來源大致如下：

為了實現車內的各種功能，如無線鑰匙、遠程解鎖、防盜報警等等，車內的電子器件現在已經是不可或缺的了 (Vehicle Level - Functional)

受限于成本考慮，能由MCU完成的，絕不用MPU (Domain Level - Functional)

說到“極少的內存”，沒接觸過MCU編程的工程師都會想，那又怎么樣？那我就少實現點功能唄。但其實對你的編程模式發生極大的影響。

MCU的一大特點是內存極小，在車載行業較常見的Renesas V850系列，其內存最小8K，最大也就192K。

這么一點內存，在MPU端，往往啟動一個進程就可以耗光了，根本就不夠用。啟動一個線程，至少需要給它分配兩部分內存，TCB和Stack，TCB還好，但Stack會較大，比如Linux的默認配置就是8MB。那么怎么辦呢？這就引出了一條軟件架構設計階段的“架構性需求”。

基于RTE運行

很多針對MCU的軟件架構都會包含RTE這一角色，其核心的功能就是大部分的線程/Task由RTE創建，并由各個應用共享，這樣就可以節省很多Stack的內存開銷。

最著名的就是AUTOSAR了，你的程序（應用）被拆成了一個個的Runnables，多個Runnable可以運行在同一個Task中，共享同一個棧。

而一旦你的程序需要基于RTE運行，那么隨之而來的，就是要做幾件基礎的事情：

對你的程序進行配置，主要是配置有哪些Runnable。

配置觸發這些Runnable對應的事件Event。

實現這些Runnable。

下圖為Mathworks對Runnable的配置界面：

支持的Event類型

https://www.mathworks.com/help/autosar/ug/configure-runnables-events-irvs.html

這種開發方式就跟MPU端的靈活開發有非常大的不同。一切都是由事件觸發，沒有main()函數，并且需要時刻牢記一點：不能block當前的task，否則整個ECU可能都會卡死。

5. 模塊級別

各個ECU確定了選型后，做了整體的系統設計和軟件架構設計后，最終的實現會落到軟件模塊級別。我們以“禁止動態分配內存”為例展開這部分。

種類：約束條件

這個需求的來源大致如下：

車輛的動力底盤域要絕對可靠 (Domain Level - Requirement)

動力底盤域的某ECU上的軟件的可靠性要達到ASIL-D級別(ECU Level -Requirement)

想達到ASIL-D級別，是必然不允許動態分配內存的。(Module Level - Requirement)

動態分配內存有很多好處，但是壞處也不少

內存利用率相對較低

需要內存管理程序，會額外占用內存

產生內存碎片，需要定期清理

不確定性較大

虛擬內存往往會大于物理內存，不可避免的引發缺頁中斷，使得分配內存的時間不確定性較大

分配內存時，查找可用內存也會引入一定的不確定性

分配內存可能會失敗，為避免這種情況往往需要較為復雜的內存回收機制（如Android的OOM killer），而不定時的觸發會進一步導致不確定性）

所以，像SafeRTOS這種對可靠性要求極高的OS干脆就禁用了動態分配內存。

這又意味著什么呢？這就意味著本來在系統層面上的資源分配會前移到代碼編寫階段，對編程模式是個重大的改變。

比如AUTOSAR中的Component配置就包含了這些東西：

提供哪些接口，類型是啥？

需要使用哪些接口，類型是啥？

6. 如何識別架構性需求

既然架構性需求是如此的關鍵，那么如何才能在項目前期將絕大部分的架構性需求識別出來呢？個人覺得主要?有兩大類方法：

用常見的架構性需求分類來幫助梳理，就如文章開頭所講的：

系統的主要功能需求

質量需求和非功能性需求

決定了解決方案和項目的各種約束條件

進行行業對標和調研，對于行業中各個領域的解決方案中特殊的點要知其然且知其所然，而不是簡單的想當然，因為這些特殊的點往往就是為了滿足特定的“架構性需求”而來的。

結語

三年前，有位大佬問我，架構設計那么多環節，哪個環節最重要？我回答說：“把需求弄清楚最重要”。現在想來，確實如此，萬一你漏了一條“架構性需求”，可該怎么辦？