軟件架構設計的案例
從功能安全視角看軟件架構設計
功能安全應該如何考慮軟件架構，什么樣的架構是符合功能安全標準要求的，對于軟件架構工程師和功能安全工程師，很難在兩個方面都說得明白，本篇來從功能安全的角度談談軟件架構設計的基本要求。
首先，功能安全軟件的架構設計是基于兩個層次的：
第一：
選取和建立一個層次分明，易于理解的軟件架構；
第二：
在第一條的基礎上，符合相應功能安全等級要求的軟件設計要求。
接下來，以汽車功能安全標準ISO26262-6和軌道交通軟件功能安全標準EN50128作為基準，談談標準是如何從以上兩個層次來做出規定的。
軟件架構階段的開始
軟件架構設計是軟件生命周期的第二個階段，前面的階段是軟件需求階段（software requirements specification）,在軟件需求設計時，把整個軟件當成一個黑盒處理，來確定該軟件的所有功能、性能，與硬件的接口定義，與外部其它系統的接口定義，而在軟件架構階段，需要設計一種架構來滿足軟件需求，通過層次化結構的方式來表示軟件架構的組件構成和他們之間的交互方式。以下圖為例，虛線框之外是軟件需求，虛線框內是軟件架構。
什么是軟件組件
上面這個圖用于解釋軟件架構所做的工作，將整個軟件劃分為功能和接口清晰的組件。
展開 從功能安全視角看軟件架構設計
來源 | 薄說安全
功能安全應該如何考慮軟件架構，什么樣的架構是符合功能安全標準要求的，對于軟件架構工程師和功能安全工程師，很難在兩個方面都說得明白，本篇來從功能安全的角度談談軟件架構設計的基本要求。
首先，功能安全軟件的架構設計是基于兩個層次的：
第一：選取和建立一個層次分明，易于理解的軟件架構；
第二：在第一條的基礎上，符合相應功能安全等級要求的軟件設計要求。
接下來，以汽車功能安全標準ISO26262-6和軌道交通軟件功能安全標準EN50128作為基準，談談標準是如何從以上兩個層次來做出規定的。
軟件架構階段的開始
軟件架構設計是軟件生命周期的第二個階段，前面的階段是軟件需求階段（software requirements specification）,在軟件需求設計時，把整個軟件當成一個黑盒處理，來確定該軟件的所有功能、性能，與硬件的接口定義，與外部其它系統的接口定義，而在軟件架構階段，需要設計一種架構來滿足軟件需求，通過層次化結構的方式來表示軟件架構的組件構成和他們之間的交互方式。以下圖為例，虛線框之外是軟件需求，虛線框內是軟件架構。
什么是軟件組件
上面這個圖用于解釋軟件架構所做的工作，將整個軟件劃分為功能和接口清晰的組件。
展開 SOA中的軟件架構設計及軟硬件解耦方法論
SOA的軟件架構設計原理
如下圖表示了典型的SOA軟件架構設計原理。這種以服務為目標的開發架構實際上是實現面向服務開發的SOA架構模型方案，讓產品經理專注于服務的設計，而系統軟件則深入到產品的開發過程中，這也是解決汽車軟件危機的重大突破。整個SOA架構可以總結為由邏輯架構構建起的一個軟硬解耦的系統和由服務架構完成的服務抽象與適配，最終建立了一個標準化的服務體系。
其整體邏輯架構設計過程可概括為：
電子電氣架構：
設計可拓展的架構（也叫計算與通信架構）需要滿足分層設計、分層測試、分層驗證要求，避免在開發階段軟件更迭的連鎖反應和集成測試中問題集中爆發，使得發現問題更加迅速，軟件版本更迭更加快速。
硬件計算平臺：
可擴展的硬件平臺包括SOA基礎服務管理和SOA硬件I/O控制管理，可兼容自動駕駛系統的多個傳感器和外部設備，支持多異構芯片和硬件升級。
操作系統內核/服務中間件：作為文件調度和驅動的核心，操作系統在支撐軟硬件解耦和軟件在硬件上的部署方面可以實現最好的支配能力。
通信架構：
通信架構的可擴展性可以很好的確保平臺化車型開發中快速適配，車型之間的差異可以減少到最少，開發下階段車型秩序進行通信擴展借鑒當前這代產品，不用再進行很多額外的開發工作，這樣可以大大減少后期產品線維護的壓力。
為了滿足車輛控制實時性的要求，核心網將會采用如TSN等的可靠通訊技術。在區域控制器下的局域網內，傳統的CAN、Lin等通訊方式將會繼續存在。局域網內可以以傳統的信號的方式進行通信，在核心的以太網骨干網絡中，將會以服務的方式進行數據之間的交互，就需要如DDS等通信中間件。
展開 高級軟件架構與系統設計
高級軟件架構與系統設計 課程基礎信息 發布年份：2026年 總章節/課程數：14個專項模塊、169節課程 總時長：7小時 文件大小：2.5GB 視頻編碼：h264，分辨率1280x720 音頻編碼：AAC，44.1千赫，雙聲道 課程語言：英語 學習收獲 掌握分布式
聯合電子：面向服務架構（SOA）的汽車軟件三部曲
系統架構設計
系統架構設計的目的是設計和得到服務到架構要素的映射，以及要素間服務調用關系。下圖中藍色小圓圈代表分析得到的服務，通過系統架構設計，被映射至不同的架構要素( Platform A~C)(圖15)。在這里，架構要素對應汽車上搭載不同控制器平臺(Platform)。
圖15 系統架構設計：服務與系統要素的映射
5. 軟件架構設計
軟件架構設計的目的是設計和得到服務（service）到服務組件（Service Component）的映射關系，過程與系統架構的設計過程類似，但需要將關注點轉移到控制器內部。
在圖16，SOA架構中，軟件架構設計的行為發生在藍色陰影區。軟件架構的設計受到諸多因素的限制(以太網通訊Port口資源，客戶具體用例場景的迭代變更等等)。總體設計思想上，高內聚，低耦合仍是設計的通用原則和架構評價的關鍵指標。額外需要強調的，應對智能網聯軟件需求迭代多變的特性，在SOA服務架構的設計中，還需強調重用性和擴展性，充分的靈活度才能以最小的軟件變更應對大量的需求輸入。
展開 符合功能安全的Level2層VCU架構設計
來源 |
電動學堂
隨著軟件定義汽車的趨勢日益加強，道路車輛電子電器系統滿足功能安全已經成為基本要求。近期，在歐盟車輛型式批準（typeapproval依據部分UNECE法規）和我國車輛的CCC認證中，對采用電子控制的轉向、制動、動力電池管理系統等也引入了功能安全要求。高效的軟件架構設計顯然對功能安全的實施和落地起著引導性作用，所以電子電器系統滿足功能安全要求已經成為產品基本屬性。
針對軟件架構如何滿足功能安全要求，業內人士紛紛借鑒了E-Gas架構，E-Gas最先被應用于發動機控制器EMS，由Level1功能層、Level2功能監控層、Level3控制器監控層三部分組成。國內相關論文分別將E-Gas架構應用于各個控制功能中，其中專利、文獻、文獻、文獻、文獻都針對功能安全標準設計了整車控制器硬件和軟件，但并未涉及Level2軟件架構。
因此，為了彌補E-Gas架構未明確提出基于模型開發MBD的Level2軟件架構的缺陷，且架構設計要滿足高內聚低耦合、合適的分層等功能安全要求，本文針對整車控制器VCU設計了一種Level2功能監控層軟件架構，不但符合功能安全架構設計要求，而且可應用于其他ECU功能安全Level2設計中，有助于功能安全設計進一步落地，降低實施難度。
一、VCU模型整體架構
設計整車控制器VCU模型Level1、Level2架構，如圖1所示，包括時序調度、輸入信號、Level1、Level2和輸出信號模塊，需滿足功能安全可理解性、一致性、簡單性、可驗證性、模塊化、抽象化、封裝性、可維修性等架構設計原則和要求。
展開 車載SOA軟件架構設計
組合：
用于按層次結構組織軟件組件。
應用軟件組件（SWC）：
它表示在軟件體系結構層具有足夠粒度的給定功能。它應該足夠細化，可以部署在單個硬件組件上。SWC應為AUTOSAR經典或自適應或非AUTOSAR軟件組件。如果是AUTOSAR經典或自適應，則必須按照標準AUTOSAR定義遵循類型-原型-實例結構。
軟件端口：
軟件端口存在于軟件組件上，表示操作（如果是客戶端服務通信）或數據元素（如果是發送方=接收方通信 ），提供或訂閱的數據，發送方-接收方接口或客戶端接口被分配給軟件端口。
軟件組裝連接器：
通過使用軟件組裝連接器（軟件級數據流）連接軟件端口，使軟件相互連接。
客戶機服務接口、操作和參數：
如果軟件端口以客戶機和服務器模式交換數據，則分配給它們的接口稱為客戶機服務接口。這個接口需要包括每個操作的操作和參數（輸入和返回）。
發送方=接收方接口和數據元素：
如果軟件端口以雙向模式交換數據，則分配的接口稱為發送方-接收方接口。此接口需要包括數據元素（表示交換的數據）和數據類型分配。數據類型應為應用數據類型和實現數據類型。應根據這些數據類型定義計算方法。
SOA設計—圖表設計
SOA設計和軟件架構( architecture)數據應以表格格式或圖表形式可視化。
應使用定制的表格格式來可視化SOA設計數據和軟件架構定義面向服務的體系結構圖(SOAD):該圖應可視化給定功能或服務、服務角色(服務提供者和服務使用者)、服務端口和服務接口。
展開 支持L3+的軟件架構及產品架構
ROS2本來就不是為實時域設計的，如果一定要把實時性要求高的車輛控制算法運行在 ROS2中，那是軟件設計的錯誤（原型系統沒關系，量產不行），而不是ROS2的問題。ROS2能否用于量產的智能駕駛控制器？答案是可以，前提是補齊 L.BSW層所需要完成的所有功能，補齊 A 軸所有切面要求的特性。這實際上是基于 ROS2的架構去實現一套 AP AutoSar 規范。這可以成為一個單獨的產品，投入時間+人+錢可以開發出來，只是看有沒有必要，值不值得。
3.2 ROS/ROS2 在 (D.P + L.FW)中的地位
ROS/ROS2 確實實現了一個機器人開發的應用框架并提供了很多基礎組件，大大便利了機器人應用的開發。但是目前的機器人應用都是在一個很小的區域內移動。一般范圍比較大的是倉庫機器人，運動范圍也就在百米數量級，場景也比較單一。所以 ROS/ROS2對機器人開發的支持映射到智能駕駛，多體現在分形遞歸的 EPX 模型的最內層。即短距離內單一場景的感知、規劃和控制執行。其并沒有對復雜的場景的調度(S)和多場景并行下的執行仲裁(A)機制。畢竟還沒有機器人需要從北京走到廣州。
所以作為智能駕駛的軟件開發框架，ROS/ROS2仍然有很多欠缺，但是作為快速原型工具仍然是非常好的選擇。
3.3 關于"中間件"
顧名思義，“中間件”一定是在兩層中間，為上層屏蔽底層的復雜性。計算機軟件架構中有一句名言：“計算機科學領域的任何問題都可以通過增加一個間接的中間層來解決” 。這是軟件架構設計的一個主要的設計哲學，用在了無數地方，也解決了無數的問題。而且“中間”一詞也是相對的，當有多層堆疊的時候，每一層都是其上下兩層的中間層。所以我們說“中間件”的時候，需要指明其上下文，否則容易出現表達與理解的不一致。
展開 嵌入式系統的軟件架構設計！
可測試性是軟件質量的一個度量指標
好的軟件是設計出來的，好的軟件也一定是便于測試的。一個難于測試的軟件的質量是難以得到保障的。在今天軟件規模越來越大的趨勢下，以下問題是普遍存在的：
測試只能手工進行，回歸測試代價極大，實際只能執行點測，質量無法保證
各個模塊只有集成到一起后才能測試
代碼不經過任何單元測試就集成
這些問題的根源都在于缺乏一個良好的軟件設計。一個好的軟件設計應該使得單元測試，模塊測試和回歸測試都變得容易，從而保證測試的廣度和深度，最終產生高質量的軟件。除了功能，非功能性需求也必須是可測試的。所以，可測試性是軟件設計中一個重要的指標，是系統架構師需要認真考慮的問題。
6.2. 測試驅動的軟件架構
這里談的是測試驅動的軟件架構，而不是測試驅動的開發。TDD(Test Driven Development) 是一種開發方式，是一種編碼實踐。而測試驅動的架構強調的是，從提高可測試性的角度進行架構設計。軟件的測試分為多個層次：
6.3. 系統測試
系統測試是指由測試人員執行的，驗證軟件是否完整正確的實現了需求的測試。這種測試中，測試人員作為用戶的角色，通過程序界面進行測試。在大部分情況下這些工作是手工完成的。在規范的流程中，這個過程通常要占到整個軟件開發時間的1/3以上。而當有新版本發布的時候，盡管只涉及了軟件的一部分，測試部門依然需要完整的測試整個軟件。這是由代碼“副作用”特點決定的。有時候修改一個bug可以引發更多的bug，破壞原來工作正常的代碼。這在測試中叫回歸測試(Regression test)。
展開 ISO 26262安全的軟件開發流程
3) 系統和子系統架構應該在對應的ASIL等級上符合技術安全需求。
4) 每個元素應從它實現的技術安全需求中繼承最高的ASIL等級。
5) 對于安全相關的元素，應該定義其內部和外部的接口，這是為了避免其它元素影響它們的安全性。
在系統設計階段中， ISO 26262-4的7.4.3.7中規定了為了避免高復雜性引起的失敗，架構設計應該滿足模塊化，足夠的顆粒度和簡單的原則。其中模塊化的系統設計應該滿足的屬性如下表所示。
在Studio中，RTE運行時環境層根據架構層軟件組件的架構設計，定義了軟件組件間通信接口，有明確的通信接口生成規定，同時也避免了不必要的接口復雜度，減少了依賴關系。系統映射根據架構層定義的軟件組件架構和ECU拓撲結構，完成軟件和硬件的映射關系，避免了軟硬件的耦合關系，減少了交互的不必要的復雜度，同時也是避免了軟硬件交互的接口復雜度，減少了依賴關系。
在ISO 26262-6中規定了軟件級設計和安全相關的概念。軟件架構設計代表了所有的軟件組件和它們在層次化結構中的交互關系。軟件架構設計提供了可以實現軟件安全需求的方法以及處理軟件開發的復雜性。
為了保證軟件架構設計獲得的信息足夠讓后續的開發流程正確有效的執行，軟件架構設計應該用下表中列出的表示法描述合適的抽象等級。
為了避免因高復雜度導致的錯誤，軟件架構設計應該滿足模塊化，封裝性和簡單這三個基本的屬性，下表中給出了軟件架構設計的原則。
在Studio的層次結構中，支持軟件組件的層次化結構，每個軟件組件通過內部行為表示其軟件組件具體完成的功能，滿足高內聚性和低耦合性。
架構層的設計保證了軟件架構設計開發到合理的程度使得所有的軟件單元能夠區別開。
展開 一篇有關軟件架構設計的文章(轉自軟件工程專家網，注意其中有關性能的內容)
復用分析、外購：縮短軟件開發周期、降低成本的有效方案未必是自行開發軟件，可以對現有軟件進行復用或進行外購。應考慮其對構架的影響。
除了系統組織的問題，構架應重點考慮對于細節全面影響的設計決策，深入這些決策領域：外部軟件接口（兼容性、通信方式、傳遞數據結構）、用戶接口（用戶接 口和系統層次劃分）、數據庫組織和內容、非數據庫信息、關鍵算法、內存管理（配置策略）、并行性、安全性、可移植性、網絡多人操作、錯誤處理。
要保證需求的可追蹤性，即保證每個需求功能都有相應模塊去實現。
構架不能只依據靜態的系統目標來設計，也應當考慮動態的開發過程，如人力資源的情況，進度要求的情況，開發環境的滿足情況。構架必須支持階段性規劃，應該 能夠提供階段性規劃中如何開發與完成的方式。不應該依賴無法獨立運行的子系統構架。將系統各部分的、依賴關系找出來，形成一套開發計劃。
六、結語
系統構架設計和千差萬別的具體的開發平臺密切相關，因此在此無法給出通用的解決方案，主要是為了說明哪些因素是需要考慮的。對于每個因素的設計策略和本文 未提到的因素需要軟件構架設計師在具體開發實踐中靈活把握。不同因素之間有時是矛盾的，構架設計時需要根據具體情況進行平衡。
參考文獻
《軟件構架實踐》SEI軟件工程譯叢，林·巴斯著
《微軟項目：求生法則》Steve McConnell著，余孟學譯
《實用軟件工程》第二版，鄭人杰、殷人昆、陶永雷等著
《軟件工程：實踐者的研究方法》（第5版）Roger S.Pressman著
《軟件開發的科學與藝術》陳宏剛等著
展開 
智能駕駛域控制器的軟件架構及實現：軟件架構基礎及問題
實際上只要是有意識的基于多層級的 EXP-S 模型來設計軟件架構，每一個EXP-S單元都有其合適的體現，實際上是可以實現一套軟件架構支持從 L1到L3+以上的自動駕駛基本。只是說 S 單元對 L2以下功能來說比較弱一些，但是其架構地位仍然存在。
L2及以下單一功能控制器的軟件架構
我們先來看一下L2 功能的常用軟件架構，我們對常用
2.1 使用Smart Sensor 的 AEB/ACC/LKA 解決方案
AEB/ACC/LKA 三個功能是 L2 最經典的駕駛輔助功能，一般的系統方案的感知部分多采用前向的攝像頭輸出目標(車輛、行人)信息，并與前向毫米波雷達給出的目標數據做融合，得到更準確的速度和距離。視覺感知和雷達感知多采用Smart Sensor 方案，這樣 Tier 1 可以選用成熟的 Tier2 供應商的產品。Tier 1 主要的開發工作在感知融合與功能狀態機的實現以及車輛控制算法。
2.1.1 常用的硬件架構
方案一：視覺感知結果傳遞給雷達感知控制器，雷達感知控制器中完成感知融合和 L2功能狀態機
圖 5 方案一拓撲
方案二：獨立的L2 控制器連接 視覺和雷達的Smart Sensor，L2控制器完成感知融合和 L2 功能狀態機
圖 6 方案二拓撲
兩個方案都是經常被采用的。方案一采用較高性能的雷
達控制器，分配部分計算單元用來實現融合算法和功能狀態機。
很多芯片廠商做雷達處理芯片設計時就考慮到這部分算力預留。
展開 面向軟件模塊的整車E/E架構設計開發咨詢服務
從當前的技術及市場趨勢來看，汽車硬件體系將逐漸趨于一致，OEM很難在硬件上打造差異化，軟件和算法將逐漸成為OEM競爭的核心要素，即軟件成為定義汽車的關鍵。整車E/E架構團隊作為整車電子電氣系統的頂層設計團隊，必須從提高軟件競爭力的角度來應對挑戰，更好地統籌整車電子電氣系統的軟件架構。
服務內容
經緯恒潤多年來一直致力于為客戶提供先進的電子電氣架構解決方案，憑借專業的架構技術團隊和豐富的電子電氣架構設計經驗、控制器軟硬件產品開發經驗，可為客戶提供面向軟件模塊的整車E/E架構設計開發咨詢服務。
? 規劃平臺級E/E Feature
? E/E架構整體方案設計
? 基于用戶場景的Use Case分析
? 功能實現方案設計
? 面向軟件模塊的子系統方案設計
? ECU軟件需求規范設計
? ECU硬件需求規范設計
服務優勢
? 10年以上電子電氣架構開發經驗
? 30多個OEM整車E/E架構開發案例
? 100人以上的專業架構開發團隊
? 功能安全、信息安全、車載以太網等專業技術團隊支撐
? 豐富的工程咨詢服務經驗
? 豐富的產品開發配套經驗
展開 整車電控系統及架構設計技術
整車電控系統及架構則需要為實現這些功能提供完善的硬件和軟件平臺。
當前系統架構軟件和硬件標準平臺還不成熟，對我國來說正好是個機會，可以依托強大國內市場，快速研究相關軟件和硬件技術，并引入到國際標準內，占領技術制高點。
整車電控系統及架構設計技術
本文的目的是基于我們對域控制設計方法的研究，提出相關的設計過程和規則，從而設計出我們3年后的新電控系統及架構平臺，也就為實現軟件定義汽車和硬件通用化提供可能性。同時，也希望能為國內電控系統及架構設計標準化帶來一些思考。
1. 設計方法
1.1 新電控系統和架構核心設計方法
舊的電控系統架構基于分布式和集成式設計方法，其中每個電控系統都基于AUTOSAR軟件架構設計，對應的用戶功能基本都在一個系統內完成。而當前隨著用戶需求越來越多，許多功能都是跨系統的。因此，從IT行業引入層次化和系統低耦合性。
1.1.1 分布式和集成式設計方法
分布式和集成式設計方法的架構方案大致拓撲如圖1所示。這是一種基本上可以不依賴其他系統，就可以實現功能需求的設計方法。車載電子控制單元(Electronic Control Unit，ECU)都是一個相對獨立的系統，所有輸入傳感器?輸出執行器和邏輯處理都在一個主ECU控制的系統內完成。這造成整車ECU數量眾多，難以管理。
1.1.2 域控制設計方法
域控制架構拓撲如圖2所示，主要內容如下:
①功能分解:實現功能邏輯與實際的物理硬線信號剝離，并把功能邏輯集中到一個域控制器實現。
②接口標準化:域控制器與區域控制器信號接口和區域控制器與所有物理信號輸入輸出設備接口。
③區域劃分:整理出所有輸入輸出設備，并按位置區域進行分配，接入區域控制器管理。
1.1.3 SOA設計方法
SOA是面向對象的服務架構，本文不做深入探討。
展開 