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

什么是？

首先，什么是需求？

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

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

Vehicle level的Functional architecture

Vehicle level的Logical architecture

Domain level的Requirements

RFLP: MBSE背后的方法論

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

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

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

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

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

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

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

2. 整車級別

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

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

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

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

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

種類：非功能性需求

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

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

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

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

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

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

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

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

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

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

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

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

4.ECU級別

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

種類：約束條件

這個(gè)需求的來源大致如下：

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

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

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

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

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

基于RTE運(yùn)行

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

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

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

對你的程序進(jìn)行配置，主要是配置有哪些Runnable。

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

實(shí)現(xiàn)這些Runnable。

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

支持的Event類型

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

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

5. 模塊級別

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

種類：約束條件

這個(gè)需求的來源大致如下：

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

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

想達(dá)到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)存的時(shí)間不確定性較大

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

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

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

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

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

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

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

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

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

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

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

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

決定了解決方案和項(xiàng)目的各種約束條件

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

結(jié)語

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