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