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