域架構(gòu)的前世今生
JOURNEY
如大家所知，“遠(yuǎn)古時(shí)期”的汽車(chē)電子電氣架構(gòu)起源于分離式架構(gòu)，也就是德美日韓四大車(chē)企巨頭橫行七大洲八大洋的時(shí)候，為了更高效地產(chǎn)出質(zhì)量穩(wěn)定的產(chǎn)品，巨頭們更多選擇將相關(guān)的“結(jié)構(gòu)模塊”和“電子模塊”綁定給同一供應(yīng)商開(kāi)發(fā)，也就是我們通常所說(shuō)的“機(jī)電一體化”，或者汽車(chē)行業(yè)中的"系統(tǒng)總成供應(yīng)商"，而其中的原因，僅僅是因?yàn)檫@個(gè)供應(yīng)商對(duì)此功能的集成方式較為精通。然而，為了能用最小成本服務(wù)不同的車(chē)型，總成供應(yīng)商會(huì)將他們系統(tǒng)打包成“平臺(tái)”，提供給他們的甲方。當(dāng)各個(gè)廠商的平臺(tái)湊在一塊的時(shí)候，自然而然地就形成了下圖中的分離式架構(gòu)。
分離式架構(gòu)發(fā)展了近數(shù)十年，其中不但誕生了大名鼎鼎的大眾MQB平臺(tái)、通用Global系列平臺(tái)，也孵化了一系列出色的供應(yīng)商體系，如博世、大陸、德?tīng)柛＃际窃谶@個(gè)大環(huán)境下成功地鞏固了自己牢不可摧的行業(yè)競(jìng)爭(zhēng)力。然而，隨著行業(yè)技術(shù)水平的不斷發(fā)展，集中式架構(gòu)的方案更多地開(kāi)始呈現(xiàn)在OEM和Tier1的會(huì)議桌之上，起初是為了優(yōu)化整車(chē)研發(fā)成本和效率，而后是因?yàn)榇蠹以絹?lái)越意識(shí)到，某一些功能，在沒(méi)有統(tǒng)一的集成環(huán)境下，是無(wú)法實(shí)現(xiàn)的。
上面兩張圖，就是近十年來(lái)集中式架構(gòu)方案里最常見(jiàn)的討論縮影，大家想要的是左圖里展示的那種純粹集中式(Pure Centralization)，即一個(gè)中央電腦Vehicle Computer實(shí)現(xiàn)所有的功能，其余部分是執(zhí)行端和采集端，也就是大家熟知的“功能上移”。而到了落地階段，卻往往只能做到右圖的多端集中式(Multiple Centralization)，其根本原因有以下三點(diǎn)：
■ 無(wú)法打破的供應(yīng)商開(kāi)發(fā)體系壁壘
很難有單個(gè)供應(yīng)商有能力做到“整車(chē)級(jí)功能完美集成”，例如擅長(zhǎng)三電體系開(kāi)發(fā)的公司，在自動(dòng)駕駛算法面前捉襟見(jiàn)肘；而精通算法的公司，往往又沒(méi)有汽車(chē)行業(yè)的開(kāi)發(fā)資質(zhì)。正所謂術(shù)業(yè)有專(zhuān)攻，成熟的系統(tǒng)研發(fā)體系下，本身就不太可能會(huì)存在技術(shù)壟斷。
■ 整車(chē)需求定義中無(wú)法避免的矛盾命題
當(dāng)一個(gè)系統(tǒng)的復(fù)雜度較高的時(shí)候，需求定義勢(shì)必會(huì)發(fā)生自然沖突。舉一個(gè)最簡(jiǎn)單的例子，我們既要實(shí)現(xiàn)純粹集中式，又要實(shí)現(xiàn)高等級(jí)的功能安全時(shí)，一定會(huì)出現(xiàn)矛盾。比如，我們現(xiàn)在假定，某車(chē)只有一個(gè)中央控制大腦VC，那么，當(dāng)VC在駕駛過(guò)程中出現(xiàn)嚴(yán)重系統(tǒng)宕機(jī)問(wèn)題時(shí)，有沒(méi)有其他控制器能取代大腦做整車(chē)級(jí)的功能調(diào)度？如果可以，那么這個(gè)控制器能替代VC多久？此外，VC和執(zhí)行器之間的通路線束如果發(fā)生故障如何處理？本地控制器要做多少備份邏輯？重要的傳感器單元又需要多少算力？
■ 軟件開(kāi)發(fā)過(guò)程中的生態(tài)問(wèn)題
汽車(chē)行業(yè)中的軟件體系在數(shù)十年的閉環(huán)開(kāi)發(fā)模式中，軟硬件強(qiáng)相關(guān)，形成了一個(gè)過(guò)于封閉的環(huán)境。甚至有人戲稱(chēng)，汽車(chē)?yán)锩嬉粋€(gè)小小的車(chē)窗控制算法對(duì)操作系統(tǒng)的要求，比航天航空的自動(dòng)巡航功能要求還高。大家知道，車(chē)窗控制算法當(dāng)然不可能比自動(dòng)巡航更復(fù)雜，其根本原因，還是因?yàn)檎?chē)軟件的可移植性較差，軟硬件無(wú)法做到解耦，每次更換一個(gè)小小的芯片都會(huì)傷筋動(dòng)骨、大動(dòng)干戈，動(dòng)輒就會(huì)涉及到數(shù)百萬(wàn)甚至上千萬(wàn)的研發(fā)費(fèi)用。所以，純粹集中式這種要拆臂斷腿的操作，自然不適合目前的整車(chē)電子電氣架構(gòu)了。
JOURNEY
在發(fā)現(xiàn)“分離式”和“純粹集中式”都走不通的時(shí)候，“功能域”和“區(qū)域”的概念就誕生了。
在看這篇文章的各位，應(yīng)該都對(duì)“功能域”和“區(qū)域”的概念并不陌生，其實(shí)現(xiàn)實(shí)情況也是，域架構(gòu)能夠非常好地改善上述提到的集中式架構(gòu)設(shè)計(jì)時(shí)遇到的三大痛點(diǎn)（供應(yīng)體系壁壘、系統(tǒng)定義矛盾、軟件生態(tài)固化）。
JOURNEY
那么，域架構(gòu)下，
我們的開(kāi)發(fā)模式會(huì)發(fā)生什么樣的變化呢？
｜基于服務(wù)架構(gòu)(SOA)的功能開(kāi)發(fā)｜
■ 上文在集中式方案介紹的時(shí)候有提到，很多人認(rèn)為某一些功能在沒(méi)有統(tǒng)一的集成環(huán)境下，是無(wú)法實(shí)現(xiàn)的。這個(gè)觀點(diǎn)并不完全正確。其實(shí)我們?nèi)钡牟⒉皇墙y(tǒng)一的集成環(huán)境，而是一個(gè)統(tǒng)一的生態(tài)。
就拿現(xiàn)在風(fēng)頭浪尖的“IOS”和“安卓”之爭(zhēng)來(lái)做例子，兩邊是拳頭撞拳頭，完全沒(méi)辦法握手的兩個(gè)操作系統(tǒng)，甚至連編程語(yǔ)言都無(wú)法做到一致（JAVA、Kotlin和Swift）。但是，我們?cè)谟檬謾C(jī)產(chǎn)品的時(shí)候，很少會(huì)發(fā)生華為手機(jī)上的微信無(wú)法給蘋(píng)果手機(jī)發(fā)消息，或者某個(gè)APP在華為手機(jī)上能安裝，但是在蘋(píng)果應(yīng)用商城里卻找不到的現(xiàn)象（某些冷門(mén)APP除外）。
你可能會(huì)說(shuō)，那是因?yàn)锳PP開(kāi)發(fā)的供應(yīng)商做了妥協(xié)，兩邊都做了同步開(kāi)發(fā)。那么，咱們?cè)傧胂耄F(xiàn)在互聯(lián)網(wǎng)行業(yè)更新迭代的驚人速度，幾乎每個(gè)月都會(huì)在“雙端”推出日新月異的更新，這種效率，真的是靠妥協(xié)和努力能在做到的么？
■ 其實(shí)，答案就在這一章的標(biāo)題里，雖然兩者的操作系統(tǒng)不同，但是，當(dāng)他們的底層模塊能打包成統(tǒng)一的“服務(wù)接口”，即使“語(yǔ)言不通”，他們依然在同一個(gè)生態(tài)里。比如藍(lán)牙的協(xié)議一旦固定，在任何操作系統(tǒng)和環(huán)境下，我們都能用統(tǒng)一的查詢(xún)方式，去操作藍(lán)牙的掃描、廣播、連接、配對(duì)，進(jìn)行一些基礎(chǔ)的功能執(zhí)行，例如電量查詢(xún)、設(shè)備信息、故障模式。
我們?cè)陂_(kāi)發(fā)過(guò)程中，看到的不再是一張張接口表，告訴你這個(gè)信號(hào)代表電量，如何解析，另一個(gè)信號(hào)代表故障，參考故障手冊(cè)可以知道其含義。相反，我們看到的是一個(gè)個(gè)服務(wù)，今天，這個(gè)服務(wù)來(lái)自安卓或IOS的藍(lán)牙模塊，叫做“電量查詢(xún)”，調(diào)用這個(gè)服務(wù)，返回的百分比可以直接顯示在智能屏幕上，不需要做任何處理。
｜區(qū)域控制器的優(yōu)勢(shì)｜
■ 正如我們上一期提到的，區(qū)域控制器給整車(chē)帶來(lái)的潛在效益非常驚人，例如Tesla的區(qū)域控制架構(gòu)為其平均線束重量減少了接近40%之多。同時(shí)，相比傳統(tǒng)分布架構(gòu)，區(qū)域架構(gòu)的線束不會(huì)出現(xiàn)因?yàn)椤坝珠L(zhǎng)又軟”而導(dǎo)致必須需要人工組裝的情況，換而言之，線束的減少使整車(chē)總裝線上更多的自動(dòng)化工藝能付諸實(shí)現(xiàn)。
■ 同時(shí)，由于功能和硬件的解耦，所以我們可以在Function Allocation上提供更多的自由。例如，未來(lái)的外燈、雨刮、鎖、鑰匙、車(chē)窗、電動(dòng)尾門(mén)可以不再是車(chē)身控制器BCM的獨(dú)有標(biāo)簽，而扭矩控制、能耗管理、擋位切換、駕駛診斷也不再是動(dòng)力控制器EMS/VCU的專(zhuān)屬功能。
換句話說(shuō)，未來(lái)的區(qū)域控制器不會(huì)以功能命名。一方面，區(qū)域控制器會(huì)更關(guān)注整車(chē)級(jí)或架構(gòu)級(jí)的應(yīng)用設(shè)計(jì)，例如上一期提到的，整車(chē)供電中心、信息中心和驅(qū)動(dòng)中心，另一方面，由于功能上移和SoA的實(shí)現(xiàn)，區(qū)域控制器可以集成BCM、VCU、Gateway、DCM甚至部分高功能安全模塊，例如EPB和iBooster的輸出邏輯，這就意味著，ASIL C/D中要求的控制單元級(jí)的冗余設(shè)計(jì)不再遙不可及， Zone和Zone之間可以做互補(bǔ)備份，當(dāng)某一個(gè)區(qū)域控制器或iBooster發(fā)生故障時(shí)，另一個(gè)區(qū)域控制器可以直接做故障監(jiān)控以及緊急接管。
■ 除此之外，Zone在整車(chē)架構(gòu)中能起到“承上啟下”的作用，上接Vehicle Computer，下接各個(gè)單元控制模塊，可以將算法和輸出完全解耦，就像RTE層在AUTOSAR架構(gòu)中的作用一樣，對(duì)平臺(tái)的拓展性、可移植性、靈活開(kāi)發(fā)性有著極大的提升。
JOURNEY
那么，區(qū)域架構(gòu)對(duì)軟件開(kāi)發(fā)而言，
又能有什么樣的好處呢？
其實(shí)這個(gè)問(wèn)題很好理解，軟件和功能開(kāi)發(fā)的未來(lái)趨勢(shì)一定會(huì)趨向于集中化。而區(qū)域架構(gòu)這一步，正是Vehicle Fusion的神來(lái)一筆。
■ 首先，正如上文提到，由于區(qū)域架構(gòu)可以將功能域淡化，意味著電子電氣架構(gòu)級(jí)的ECU可以實(shí)現(xiàn)如AUTOSAR軟件架構(gòu)中的“抽象化”的概念。在整車(chē)的茫茫軟件海洋中，我們不需要通過(guò)功能、信號(hào)、驅(qū)動(dòng)去定義功能部署，所有的軟件功能可以原子化，成為一個(gè)個(gè)獨(dú)立的服務(wù)，不同的Zone之間的調(diào)度通過(guò)Vehicle Computer來(lái)實(shí)現(xiàn)，而VC和Zone又能按需組成集群，和傳統(tǒng)的架構(gòu)相比，存在著無(wú)限升級(jí)的可能性。
舉一個(gè)稍微簡(jiǎn)單的例子來(lái)看一下，原來(lái)我們的經(jīng)典開(kāi)發(fā)模式是通過(guò)V模型形成開(kāi)發(fā)矩陣，從架構(gòu)和系統(tǒng)到硬件和軟件，最后再回到測(cè)試和驗(yàn)證，再佐以ASPICE、Fusa以及Cyber Security的開(kāi)發(fā)，形成一個(gè)堅(jiān)不可摧的閉環(huán)。而這種開(kāi)發(fā)模式比較依賴(lài)于串行合作，下游對(duì)上游需求的依賴(lài)性較強(qiáng)，同時(shí)也對(duì)相關(guān)件的要求較高。例如，如果沒(méi)有整車(chē)級(jí)的系統(tǒng)需求，比如dbc缺失和故障，會(huì)導(dǎo)致整個(gè)軟件開(kāi)發(fā)進(jìn)度的延遲。
■ 而全新的基于Zone和SoA開(kāi)發(fā)模式，并不是要打破原有流程，而是在串行合作的同時(shí)增加了平行合作的可能性。在開(kāi)發(fā)初期，軟件可以根據(jù)平臺(tái)需求先行進(jìn)行服務(wù)和集群的開(kāi)發(fā)驗(yàn)證，按軟件需求定義服務(wù)接口，再反向傳遞給架構(gòu)開(kāi)發(fā)。同時(shí)，架構(gòu)在接到Service Provider方的接口描述后，再進(jìn)行跨控制器、跨Zone級(jí)的功能分配和調(diào)整。也就是說(shuō)，在服務(wù)開(kāi)發(fā)的流程中，架構(gòu)、系統(tǒng)、軟件、硬件的V字模型是同時(shí)在運(yùn)行的，同時(shí)相互影響和驗(yàn)證。這種開(kāi)發(fā)模式非常靈活，而且極其敏捷，相對(duì)于傳統(tǒng)模式，平行開(kāi)發(fā)不會(huì)畏懼任何新的變更需求，因?yàn)榉?wù)的抽象化能夠?qū)㈥P(guān)聯(lián)影響壓到最小，變更和驗(yàn)證周期也可以大幅度減少。
■ 同時(shí)，在開(kāi)發(fā)過(guò)程中，如果出現(xiàn)設(shè)計(jì)溢出（軟硬件的設(shè)計(jì)無(wú)法滿(mǎn)足系統(tǒng)需求，例如I/O口資源不夠，CAN通路數(shù)量不足，通訊速率，存儲(chǔ)空間溢出等問(wèn)題）。在原有架構(gòu)開(kāi)發(fā)中，設(shè)計(jì)溢出常常會(huì)給功能開(kāi)發(fā)劃上句號(hào)，因?yàn)橛布兏杀具^(guò)高，所以需求只能做妥協(xié)或降級(jí)，并且將溢出部分的設(shè)計(jì)延遲至下一代的平臺(tái)開(kāi)發(fā)。而在Zone開(kāi)發(fā)過(guò)程中，由于軟硬件解耦的實(shí)現(xiàn)，即使出現(xiàn)了設(shè)計(jì)溢出，也可以通過(guò)Zone Duplicate的形式，將設(shè)計(jì)延伸以滿(mǎn)足溢出的需求。換句通俗易懂的話來(lái)說(shuō)，如果三個(gè)Zone無(wú)法解決問(wèn)題，那么就再來(lái)第四個(gè)Zone。
當(dāng)然，Zone Duplicate并不是簡(jiǎn)單的硬件相加，增加部分的軟件和服務(wù)的驗(yàn)證還是需要的，而在Zone開(kāi)發(fā)的平行合作模式里，只需要新開(kāi)一個(gè)小小的任務(wù)包即可，并不需要做傷筋動(dòng)骨的大回歸。
轉(zhuǎn)載汽車(chē)電子相關(guān)文章
轉(zhuǎn)自汽車(chē)電子與軟件
