架構(gòu)性需求的基礎(chǔ)知識

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

什么是？

首先，什么是需求？

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

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

Vehicle level的Functional architecture

Vehicle level的Logical architecture

Domain level的Requirements

RFLP: MBSE背后的方法論

什么是架構(gòu)性需求？

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

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

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

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

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

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

2. 整車級別

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

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

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

這個環(huán)節(jié)離用戶會比較接近，大家一看就明白，我就不多講了。

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

種類：非功能性需求

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

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

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

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

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

行業(yè)一般有幾種辦法：

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

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

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

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

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

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

4.ECU級別

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

種類：約束條件

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

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

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

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

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

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

基于RTE運行

很多針對MCU的軟件架構(gòu)都會包含RTE這一角色，其核心的功能就是大部分的線程/Task由RTE創(chuàng)建，并由各個應(yīng)用共享，這樣就可以節(jié)省很多Stack的內(nèi)存開銷。

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

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

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

配置觸發(fā)這些Runnable對應(yīng)的事件Event。

實現(xiàn)這些Runnable。

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

支持的Event類型

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

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

5. 模塊級別

各個ECU確定了選型后，做了整體的系統(tǒng)設(shè)計和軟件架構(gòu)設(shè)計后，最終的實現(xiàn)會落到軟件模塊級別。我們以“禁止動態(tài)分配內(nèi)存”為例展開這部分。

種類：約束條件

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

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

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

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

動態(tài)分配內(nèi)存有很多好處，但是壞處也不少

內(nèi)存利用率相對較低

需要內(nèi)存管理程序，會額外占用內(nèi)存

產(chǎn)生內(nèi)存碎片，需要定期清理

不確定性較大

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

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

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

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

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

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

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

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

6. 如何識別架構(gòu)性需求

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

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

系統(tǒng)的主要功能需求

質(zhì)量需求和非功能性需求

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

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

結(jié)語

三年前，有位大佬問我，架構(gòu)設(shè)計那么多環(huán)節(jié)，哪個環(huán)節(jié)最重要？我回答說：“把需求弄清楚最重要”?，F(xiàn)在想來，確實如此，萬一你漏了一條“架構(gòu)性需求”，可該怎么辦？