架構的案例
支持L3+的軟件架構及產品架構
繼上一篇文章智能駕駛域控制器的軟件架構及實現：軟件架構基礎及問題，本文將提出智能駕駛域控制器軟件架構的鳥瞰圖，并從三個維度闡述軟件架構的組成。
Level 2 及以下級別的自動駕駛功能基本上都是屬于“駕駛輔助”性質。各功能的場景，主要的駕駛行為是駕駛員主導，自動駕駛系統只在非常限定的條件約束內對車輛進行操作。而且這些約束條件所形成的場景基本上是各自獨立的，這也就是各功能能夠由不同供應商獨立開發的原因之一。
從 Level3 開始逐步主導車輛的駕駛，與Level2 有了根本性的變化。L3級別就要求在良好的路況環境下，大多數操作將由汽車為主導，車輛將自動完成自適應巡航、車道居中保持、自動變道、自動駛入（駛出）高速匝道等一系列操作。駕駛員只需要在必要的時候對汽車進行干涉。當然這就對自動駕駛系統的硬件算力，傳感器配置，各種感知、規劃、控制算法都提出了更高的要求。
在自動駕駛技術中，比較受關注的如何提高硬件的算力，尤其是能支持深度學習的算法能力，如何開發更好的感知算法等等，然而如何讓這些得到大大提升的各專項能力能協同工作卻很少被特別提及。我們需要的不僅僅是車輛運行過程中，各種自動駕駛功能關聯的技術模塊能協同工作，還要考慮這些不同的技術模塊在開發階段如何能進行有效的分解，因為不同技術模塊往往是完全不同的技術領域，需要不同的專業團隊(或供應商)去完成。如果能把這些技術模塊“拆得開”又“裝得上”就是軟件架構需要解決的問題。
正因為從 Level 2 到 Level 3 的跨越難度太大，所以人們在 L2的軟硬件架構上修修補補，在不改變核心架構邏輯的基礎上盡量增加一些新的功能，才有所謂的 Level2.5。
展開 車載E/E架構不斷升級，整車架構指引趨勢
引言
ADAS功能不斷升級導致對芯片計算能力需求提升，駕駛輔助功能快速提升，分布式架構向“功能域”集中式架構演進成為趨勢。
一、背景信息
1、分布式ECU在汽車電氣化、智能化時代，因為駕駛輔助功能快速的提升，面臨著巨大的挑戰：
各個ECU之間計算能力無法協同，相互冗余，產生極大浪費；
嵌入式操作系統及Application Software由不同的Tier1提供，編程語言和編程風格迥異，導致難以統一維護和OTA升級；
分布式架構需要大量內部通信，導致線束成本增加并加大裝配難度。
因此，分布式架構向“功能域”集中式架構演進成為趨勢。
2、SOA架構助力整車OTA
對比傳統汽車，OTA為汽車注入新的活力。在“軟件定義汽車”時代，OTA（Over The Air）能夠滿足智能汽車軟件快速迭代的需求，避免傳統汽車每次更新都需要去4S店，從而導致效率低下的問題。通過它可以不斷給客戶開啟新的功能，不斷優化產品體驗，吸引客戶，形成生態鏈。
傳統分布式ECU軟硬件架構，整車OTA效率低下。
展開 智能駕駛域控制器的軟件架構及實現：軟件架構基礎及問題
第一篇內容分享到這里，近日將更新第二篇：《支持L3+的軟件架構及產品架構》，歡迎大家關注！
作者：肖猛，北京未動科技有限公司研發VP
閱讀原文，關注作者知乎
MBSE體系架構模型的理論研究：基于MBSE與SysML的空空導彈系統架構建模研究
基于此，本文引入基于SysML的系統架構建模方法[9,10]，在方案設計階段利用基于MBSE的設計方法對空空導彈系統架構進行建模，并對不同系統架構進行仿真分析，最終獲得最優系統架構，實現在方案論證階段減少甚至消除設計中的邏輯錯誤，避免到設計后期才發現由于邏輯錯誤而造成循環設計[11-13]。
1 MBSE理論概述
本文展開基于MBSE 的空空導彈系統架構設計工作。從需求分析和用例出發，利用RHAPSODY 建模工具，基于MBSE 方法和SysML建模語言，對空空導彈系統架構進行建模與仿真，主要包括基于SysML 的需求分析、系統分析和系統設計三個部分，最終實現在空空導彈系統方案設計階段對其架構進行仿真，獲得最優系統架構。
（1）需求分析
該階段目的是將軍方原始需求轉化為系統需求，同時依據需求定義空空導彈用例，詳細描述系統的行為，主要通過SysML的需求圖和用例圖表達。
（2）系統分析
該階段主要是把系統需求分解為功能性需求和非功能性需求，同時將系統功能性需求轉化為若干個可執行模型，利用SysML 的順序圖、活動圖和狀態來實現每一個用例的分析。
（3）系統設計
該階段分為架構分析與架構設計兩個階段。架構分析階段是利用順序圖、活動圖和狀態圖對不同的系統架構進行評估分析，獲得最佳系統架構。架構設計階段功能性需求分配到系統架構的結構中，從而完成系統設計。
2 需求分析
需求分析是指對空空導彈進行詳細的分析，弄清楚空空導彈的戰術要求，包括需要輸入什么命令、什么數據，最后應該輸出什么、做出什么機動動作。具體的需求分析包括功能需求、性能需求、接口需求和約束需求等。首先將DOORS中條目化的軍方需求和量化的性能需求逐條轉化為SysML的需求圖，使得每條細化后的需求都能夠以用例圖來進行動態行為分析。
展開 
純電動汽車架構設計(一) ：電動車架構設計核心與前懸架選擇
圖2 大眾MQB平臺未加強前指梁，不利于小偏置碰撞
那什么是車輛架構設計呢？車輛架構是某款車型上所應用的技術組合方式，這些方式可以基于平臺設計，也可以不基于平臺設計。架構設計不同于平臺設計，平臺指的是零件物理上的相同或相似，架構指的是設計理念和思路上的相同或相似。架構設計是汽車頂層設計的一部分，在架構設計層面我們需要權衡技術、市場與消費者期望和物料、研發成本，而引入的技術也可以反哺平臺或服務后續車型。
圖3 架構設計要合理組合汽車所有關鍵部件和人體
因此平臺是穩定、普適的，而架構是靈活、專一的。特定車型的架構設計在大框架上應該存在最優解。例如前橫置前驅+麥弗遜懸架組合，以及機艙縱梁+車身縱梁、門檻梁、中央通道的傳力路徑組合，已經成為傳統燃油車型的標準架構。
3 現階段電動車的平臺架構設計的追求
中國的純電動車行業，細節設計如NVH、強度分析、臺架試驗等能力已經逐漸形成，但是對平臺架構和整體設計研究依然進展寥寥，隨著汽車電動化浪潮的推進，頂層設計能力薄弱的問題愈發凸顯。
合理的電動車平臺規劃有利于充分利用電動車的零部件特點和整車總體優勢，例如成員艙空間、車身碰撞性能、更好的整車尺寸等，此外對于零部件選型和設計也有很強指導意義。
展開 新型電子電氣架構的思考
02、架構如何設計
在上述層層關系中，某種程度來說，架構是成就了軟件定義汽車，如下圖所示。
圖3 EEA成就軟件定義汽車
那在弄清楚軟件如何定義汽車之前，我覺得最重要的是考慮清楚架構如何設計，而我的專業是架構，所以我從自身經驗出發，分析下架構如何設計：
作為OEM，首先要對架構如何設計了然于心，并有一套可以適用于所有車型的架構設計方法論，這套方法論必須做到不管技術如何更新迭代，架構如何演變，方法論可以一直被沿用，內容可以不斷更新，但框架始終不變。如下圖所示，就是我理解中的架構設計方法論。
我將架構設計劃分為四大方向：
架構特征、架構拓撲，架構決策，設計指導。
圖4 架構設計方法論
1、架構特征
首先，架構特征是定義整車架構最主要的一個維度，架構特征定義了系統的成功標準，它通常與系統的功能強相關，通過功能需求和OEM需求來推導和定義架構特征。比如，如果OEM需要通過沿用架構來降低成本，那架構特征就必須包括可復用性，同時如果技術不斷變革，架構勢必也要具備不斷更新迭代，但如何做到即可復用又滿足后續技術發展，這樣的架構就必須要做到可擴展性，隨著智能駕駛等級的不斷升級，整車系統的安全穩定同樣也是一個重要的特征，因此比起可復用性和擴展性來說，架構的可靠性也變得尤為重要。
2、架構拓撲
架構通過拓撲來呈現，而拓撲劃分為物理拓撲，網絡拓撲，功能拓撲。不同的拓撲對應不同的架構團隊，各個架構團隊負責各自的專業內容設計，并要做到整個架構系統協調統一。
下一章節會重點介紹。
展開 架構設計到底在做什么？
來源 | 侯哥工作感悟
知圈 | 進“電子電氣群”請加微13636581676,備注架構
架構設計到底在做什么？這個好像不應該成為問題，因為每個人都會回答：架構設計就是設計架構唄。然而，設計架構又是設計什么東西呢？
讓我們先回顧一下以前聊過的一個話題：什么是電子電氣架構？架構是基于復雜系統的一個概念，體現的是系統之內的元素的基本結構和關系，是一種系統設計和演進的原則。
對于汽車的EEA（Electronic Electrical Architecture）來說，定義的就是汽車上電子部件之間的相互關系，及所有的電子部件（包含硬件實體及其中的軟件）所共同承載的邏輯功能之間的關系，以及為了設計和維護這些電子部件所規定的各種原則。
(Source:Bing)
從上面這個定義中可以看出，架構并不是一個具象化的實體，而是一個抽象的東西，任何一種具象化的東西都沒有辦法完整的表示出什么是架構。而且，架構一定是依賴于系統而存在的。
汽車的電子電氣架構EEA依賴的就是汽車上的電子電氣E/E系統。談到EEA，一定離不開這個E/E系統。架構是系統的架構。
網絡拓撲是架構的一部分，電氣拓撲也是架構的一部分，但是它們都沒有辦法來代表完整的架構。它們所表示的僅僅是EEA的一部分特性或者屬性。
接下來，讓我們從城市的設計建造過程來理解E/E系統的開發工作以及EEA設計的工作。
雖然我以前曾經以一個大樓的設計、建造過程來解釋過EEA設計的工作，可是從事EEA的工作越久，就越覺得汽車上EEA設計的復雜。由于現代車輛本身的高度復雜性，整車電子EEA設計更像城市規劃。
展開 一文盤點博世、豐田、特斯拉等6家主流智能汽車電子架構
來源 | 智能網聯汽車網
本文對幾家主流智能汽車的架構設計概念進行了技術分析，并對幾種智能汽車的架構設計概念進行了評價。
智能汽車電子架構研究現狀
傳統分布式汽車電子電氣架構的設計 思想為硬件定義規格，硬件架構采用CAN總線網絡和分布式功能單元，單功能單控制器，軟硬件不能解耦，專用傳感，專用控制器，專用算法。傳統汽車電子電氣架構面對汽車“四化”的挑戰和需求難以支撐，汽車行業主要企業都給出了自己的解決方案，對未來智能汽車的電子電氣架構進行了思考，提出了新型的汽車電子電氣架構概念。
博世
博世作為整車Tire1供應商的重要代 表，提出了未來智能汽車電子電氣架構的 演進方向（圖 1）。從整個演進過程分為6個階段：分布式功能模塊、功能模塊合并、多域控制器架構、功能域逐漸融合階段、域融合終極階段汽車大腦，最后遠景云端計算階段。
博世汽車電子電器架構的演進概念清晰指明了未來汽車電子電氣架構算力會逐漸集中化，最終會發展到云端計算。當前架構主流處于功能模塊合并階段，正在朝多域控制器架構方向發展。
圖1 博世汽車電子電氣架構演進路線圖
聯合電子
聯合汽車電子有限公司面向未來智能汽車，設計開發了擴展型域控制器平臺， 將于2020年實現量產。聯合電子設想未來汽車電子電氣架構分為三層（如圖2），頂層為云服務平臺，中層為計算與控制，下層標準化的執行器和傳感器。中層計算與控制包括五個功能域的主控和以太網主干網、車載無線通訊共七個架構主要構成元素。聯合電子面向未來智能汽車的架構思路為集中式域控制器架構。
圖2：聯合電子未來汽車電子電氣架構
安波福
安波福提出了智能汽車架構的概念以適應自動駕駛的需求。
展開 MBSE產品模型架構應用：基于模型驅動架構概念的自主水下航行器控制器的MBSE應用（上）
3.2
AUV的一般控制架構
AUV的物理架構由以下子系統組成：制導子系統；導航子系統；和控制子系統。這些子系統有自己的任務，但它們也必須合作以允許主體完成其任務。圖1顯示了SysML中的模塊定義圖，其中描述了子系統的交互。
圖1.自主水下航行器（AUV）的自主架構模塊定義圖
根據上述AUV動態和控制架構，以及第2節中描述的HDS的定義，AUV控制器可以被視為HDS，其動態行為可以通過HA建模，并通過視線（LOS）導航性實現。
文章來源：創景科技
MBSE產品模型架構應用：基于模型的系統工程 (MBSE) 在汽車傳動系統子系統架構中的應用
上下文圖/背景圖：
○ 代表系統與外部環境的交互
○ 交互系統被定義為“黑盒”
P-圖：
○ 擴展和細化上下文以獲得更詳細的黑匣子
○ 包括有關輸入信號、控制因素、噪聲因素、輸出和潛在故障模式的詳細信息
MBSE
○ 建模語言（SysML、UML 等）
○ 建模方法
○ 建模工具（Magicdraw、IBM Rational Rhapsody 等）
基于模型的系統工程概念：系統需求
● 需求以技術術語定義客戶和利益相關者的需求
● 在 SysML 中，系統需求陳述被定義為對象
● 每個對象都包含需求文本和唯一標識符
● 需求類型定義了需求可以關聯的特征
● 泛化通過繼承關系管理和分配需求
● 需求必須通過測試用例進行驗證
● 測試用例是檢查點，例如設計評審或物理測試
SysML中的標準類型需求用于在定義系統時提供嚴格性和清晰性
基于模型的系統工程概念：功能和邏輯架構
● 功能定義必須完成或完成哪些動作/活動才能獲得預期結果
● 操作是塊的屬性
● 塊是系統任何部分的抽象表示，如物理硬件或信號
● 功能通過與各個子系統和組件的邏輯關系相互關聯
● 邏輯架構描述了系統將如何實現
● 邏輯架構抽象地定義了基于系統所需的子系統、組件及其關系的技術解決方案
● 邏輯架構只能在明確定義系統的功能和需求后創建
● 邏輯架構沒有定義任何特定的系統實現，而是定義通用指南，以保持解決方案中立
建模方法：功能分解
● 從 P 圖中識別出傳動系統的五個基本操作
● 系統需要
○ 傳遞扭矩
展開 【域架構的演進】
■除此之外，Zone在整車架構中能起到“承上啟下”的作用，上接Vehicle Computer，下接各個單元控制模塊，可以將算法和輸出完全解耦，就像RTE層在AUTOSAR架構中的作用一樣，對平臺的拓展性、可移植性、靈活開發性有著極大的提升。
那么，區域架構對軟件開發而言，又能有什么樣的好處呢？
其實這個問題很好理解，軟件和功能開發的未來趨勢一定會趨向于集中化。而區域架構這一步，正是Vehicle Fusion的神來一筆。
■ 首先，正如上文提到，由于區域架構可以將功能域淡化，意味著電子電氣架構級的ECU可以實現如AUTOSAR軟件架構中的“抽象化”的概念。在整車的茫茫軟件海洋中，我們不需要通過功能、信號、驅動去定義功能部署，所有的軟件功能可以原子化，成為一個個獨立的服務，不同的Zone之間的調度通過Vehicle Computer來實現，而VC和Zone又能按需組成集群，和傳統的架構相比，存在著無限升級的可能性。
舉一個稍微簡單的例子來看一下，原來我們的經典開發模式是通過V模型形成開發矩陣，從架構和系統到硬件和軟件，最后再回到測試和驗證，再佐以ASPICE、Fusa以及Cyber Security的開發，形成一個堅不可摧的閉環。而這種開發模式比較依賴于串行合作，下游對上游需求的依賴性較強，同時也對相關件的要求較高。
展開 
電子電氣架構設計需要考慮哪些方面？
因此汽車制造商紛紛革新現有的的電子電氣架構，像國內小鵬的X-EEA3.0中央計算平臺+區域控制架構、廣汽埃安的中央計算平臺架構——星靈架構、長城的計算平臺架構GEEP3.0等（如圖1所示）。
意在降低電子電氣架構的復雜性，對軟硬件進行解耦，以及為后續高級的功能落地提供基礎，如圖2所示。
圖1 上汽、廣汽、長城的中央計算平臺架構(來源網絡)
圖2 分布式架構與中央架構優缺點對比(來源九章智駕)
在設計電子電氣架構的過程中，一個關鍵的任務是基于整車需求分解出電氣/電子需求。整車需求包括機械、電氣/電子、軟件、熱學等。工程師需要從中提取電氣/電子方面需求，并且對其進行分解然后協調各下游部門進行開發設計。在整個過程中，涉及電子電氣架構的定義、設計和交付的各種工程師必須平衡相互依賴的需求。下面從以下這些方面來聊一聊電子電氣架構設計。
01.
網絡拓撲
在定義拓撲時，首先是需要各控制器的接口人負責整理出功能清單，然后同一個域的會組織會議討論功能分配優化，網絡連接等，例如：
1.升級 ECU 以在一個或多個連接上支持更高波特率的網絡；
2.將二級網絡中控制器的功能移至域控制器，以支持更高級的功能實現；
同時不同域之間也會開會討論功能分配優化，看是否需要將功能劃到其他域中去。
從分布式架構到域控制器架構的過渡相對容易，這種升級通常僅是將部分分散于不同控制器的功能整合到一個控制器中(圖3)。這些通常在功能域內進行轉移，并進行適度更新以使其適應新車型。再下一階段是將域控制器重組為更通用的計算單元，將大部分功能集中至通用計算單元，而二級或者三級網絡中的控制器僅作為執行器。區域控制器是根據車輛的物理布局將其余功能整合在一起。
展開 MBSE方法論專題 | OOSEM-Modelook綜合設計候選架構
定義及流程
綜合設計候選架構的目的是在系統功能需求和邏輯架構的牽引下，非功能性需求約束下，明確定義物理架構方案。物理架構由為特定子系統設計選定的有形設備組成。物理架構設計還應考慮除功能性之外約束，例如由安全性牽引得到的冗余備份設計。
綜合設計候選架構流程如下圖所示：
系統功能需求和邏輯架構的牽引下，將系統分解為多個物理子系統，一般物理子系統可以理解為邏輯架構中的邏輯元素的初步物理劃分，類似于用戶界面對應由顯示器和鍵盤組成的顯控子系統。定義物理子系統之間的交聯關系，可以為子系統定義端口，端口間的連接關系；
子系統設計，將子系統分解為物理部件，物理部件可以是設備，也可以直接分解到軟硬件等。定義物理部件之間的交聯關系，包含物理部件的端口及端口間的連接關系；
當存在多個物理架構時，需要進行架構權衡，對比不同的系統總體方案，評估系統可靠度、技術成熟度、系統復雜程度、成本、研制周期、系統重量等因素，對不同方案進行權衡；
定義接口，包含子系統或者設備間傳遞的信號、能量、物質等信息；
定義物理部件的功能，將系統功能進一步細化定義為各個部件如何執行支撐整個系統功能；
定義各物理部件的需求，將分析之后的個物理部件的功能及指標作為需求，并維護和系統需求的追溯關系。
圖 1 綜合設計候選架構
2. 責任角色
在由多學科背景組成的系統工程團隊中，物理架構模型一般由總體部門的系統工程師（或者稱為系統架構師）負責，子系統工程師參與子系統的設計。
3.
展開 世上沒有完美的架構
微服務架構的演變
微服務架構的技術體系、社區目前已經越來越成熟。在最初系統架構的搭建，或者當現有架構已到達瓶頸需要進行架構演進時，很多架構師、運維工程師會考慮是否需要搭建微服務架構體系。
雖然很多文章都說微服務架構是復雜的、會帶來很多分布式的問題，但只要我們了解這些問題，并找到解法，就會有種撥開云霧的感覺。
微服務架構也不是完美的，世上沒有完美的架構，微服務架構也是隨著業務、團隊成長而不斷演進的。最開始可能就幾個、十幾個微服務，每個服務是分庫的，通過 API Gateway 并行進行服務數據合并、轉發。
隨著業務擴大、不斷地加入搜索引擎、緩存技術、分布式消息隊列、數據存儲層的數據復制、分區、分表等。
微服務是一種服務間松耦合的、每個服務之間高度自治并且使用輕量級協議進行通信的可持續集成部署的分布式架構體系。這一句包含了微服務的特點，微服務架構和其他架構有什么區別？以下對比一些常見的架構。
單體架構
單體架構是最簡單的軟件架構，常用于傳統的應用軟件開發以及傳統 Web 應用。傳統 Web 應用，一般是將所有功能模塊都打包（jar、war）在一個 Web 容器（JBoss、Tomcate）中部署、運行。
隨著業務復雜度增加、技術團隊規模擴大，在一個單體應用中維護代碼，會降低開發效率，即使是處理一個小需求，也需要將所有機器上的應用全部部署一遍，增加了運維的復雜度。
SOA 架構
當某一天使用單體架構發現很難推進需求的開發、以及日積月累的技術債時，很多企業會開始做單體服務的拆分，拆分的方式一般有水平拆分和垂直拆分。
展開 電子電氣架構設計需要考慮哪些方面？
因此汽車制造商紛紛革新現有的的電子電氣架構，像國內小鵬的X-EEA3.0中央計算平臺+區域控制架構、廣汽埃安的中央計算平臺架構——星靈架構、長城的計算平臺架構GEEP3.0等（如圖1所示）。
意在降低電子電氣架構的復雜性，對軟硬件進行解耦，以及為后續高級的功能落地提供基礎，如圖2所示。
圖1 上汽、廣汽、長城的中央計算平臺架構(來源網絡)
圖2 分布式架構與中央架構優缺點對比(來源九章智駕)
在設計電子電氣架構的過程中，一個關鍵的任務是基于整車需求分解出電氣/電子需求。整車需求包括機械、電氣/電子、軟件、熱學等。工程師需要從中提取電氣/電子方面需求，并且對其進行分解然后協調各下游部門進行開發設計。在整個過程中，涉及電子電氣架構的定義、設計和交付的各種工程師必須平衡相互依賴的需求。下面從以下這些方面來聊一聊電子電氣架構設計。
01.
展開 