系統架構設計的案例
淺談系統安全架構設計
對于一個系統，架構設計通常決定了該系統的整體性能表現，而功能安全標準對架構設計的要求及安全分析方法論引用比較復雜，如何在系統設計之初，合理并充分的考慮其安全設計成為了當前很多同行在做安全設計的一個難點。
筆者從事功能安全領域工作八年有余，有過多家外企合資企業的三電系統，ADAS系統相關產品的安全開發設計經驗。此次受SESETECH安全技術論壇邀請，結合個人經驗分享一下對系統安全架構設計的淺薄理解，希望能夠解決部分同行對于安全架構設計的痛點。限于個人認知，此文僅供各位同行交流討論，不針對任何企業或者產品安全提出設計建議。
內容框架：
安全架構設計必須了解的術語及安全方法說明
E-GAS三層架構的理解及使用約束
ADAS系統安全架構設計及安全等級的分解
02
安全架構設計必須了解的
術語及安全方法說明
在ISO 26262的第三部分，第四部分及第九部分，提到了很多關于系統或者相關項的安全術語，包括故障類型判斷，安全分解策略，故障控制/避免措施，等。如何正確地理解并應用這些術語及背后的方法論，對于安全架構設計尤為重要。本文主要針對涉及到系統安全架構設計的必要術語進行一些系統性闡述，幫助大家理解其中關系。
故障控制措施（Fault control）
和故障避免措施（Fault avoidance）
在功能安全標準或者一些教學中，經常會提到系統性失效和隨機硬件失效兩個概念作為電子電氣系統的兩大失效來源。
展開 下一代自動駕駛域控制器系統架構設計
L3+級自動駕駛相對于初級版L3主要呈現的問題如下：
1）當前L3級自動駕駛系統中仍然存在較大的傳感探測盲區，比如當前架構下前視攝像頭對前方目標的距離深度及廣度探測存在局限性；側向雷達無法完成側方目標（包含距離、類型、方位）的精準探測；后向通過側向雷達存在較大的三角探測盲區等問題都會在一定程度上影響對于目標的輸出，而這種探測局限性又很可能導致自動駕駛存在一定的危險性；
2）此外，中央域控制器算力、帶寬不足以滿足傳感器輸入的指數級數據量，從而導致無論對于傳感信息亦或者邏輯信息的處理實時性、有效性均無法滿足性能要求；
3）系統架構設計無法滿足駕駛功能安全及性能設計要求。這里我們指的系統架構包含但不限于網絡架構、冗余設計架構、關聯系統接口以及診斷設計架構；
4）功能安全設計是下一代自動駕駛需要解決的老大難問題，所有的系統開發工作均圍繞著功能安全展開。其中的設計過程包含了系統級、零部件級等等，從整體系統級別出發的功能安全等級分析往往需要牽一發而動全身，其智能駕駛系統自身內部設計的方方面面均需要考慮全面，同時參照其控制器、執行器搭載架構而言還需要更多的關注零部件級硬件+軟件功能安全分析。
5）系統功能測試局限問題明顯。對于真正的自動駕駛而言，系統開發往往圍繞正向開發過程進行，正向開發意味著很多邊緣化的場景并未在開發過程中進行響應，我們知道通過APICE流程開發模型中，其中涉及的單元測試和過程測試正是針對開發原始軟件的漏洞和缺陷進行實時補充和更新的方式，這就要求測試過程具備極為豐富的場景庫以及測試平臺搭建能力。場景庫不難理解，就是我們常常稱之為的UseCase，而平臺搭建能力則是對下一代自動駕駛系統測試的巨大挑戰。因為其中包含了仿真測試與實車測試兩種方式。
展開 整車電控系統及架構設計技術
來源 |
廣州汽車集團股份有限公司汽車工程研究院
知圈 |
進“電子電氣群”請加微13636581676,備注架構
引言：
本文的目
的是基于我們對域控制設計方法的研究
，
提出相關的設計過程和規則
，
從而設計出我們3年后的新電控系統及架構平臺
，
也就為實現軟件定義汽車和硬件通用化提供可能性
。
同時
，
也希望能為國內電控系統及架構設計標準化帶來一些思考
。
1設計方法
1.1新電控系統和架構核心設計方法
舊的電控系統架構基于分布式和集成式設計方法，其中每個電控系統都基于AUTOSAR軟件架構設計，對應的用戶功能基本都在一個系統內完成。而當前隨著用戶需求越來越多，許多功能都是跨系統的。因此，從IT行業引入層次化和系統低耦合性。
1.1.1分布式和集成式設計方法
分布式和集成式設計方法的架構方案大致拓撲如圖1所示。這是一種基本上可以不依賴其他系統，就可以實現功能需求的設計方法。車載電子控制單元(Electronic Control Unit，ECU)都是一個相對獨立的系統，所有輸入傳感器?輸出執行器和邏輯處理都在一個主ECU控制的系統內完成。這造成整車ECU數量眾多，難以管理。
1.1.2域控制設計方法
域控制架構拓撲如圖2所示，主要內容如下:
①功能分解:實現功能邏輯與實際的物理硬線信號剝離，并把功能邏輯集中到一個域控制器實現。
②接口標準化:域控制器與區域控制器信號接口和區域控制器與所有物理信號輸入輸出設備接口。
展開 整車電控系統及架構設計技術
本文的目的是基于我們對域控制設計方法的研究，提出相關的設計過程和規則，從而設計出我們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是面向對象的服務架構，本文不做深入探討。
展開 
高級軟件架構與系統設計
高級軟件架構與系統設計 課程基礎信息 發布年份：2026年 總章節/課程數：14個專項模塊、169節課程 總時長：7小時 文件大小：2.5GB 視頻編碼：h264，分辨率1280x720 音頻編碼：AAC，44.1千赫，雙聲道 課程語言：英語 學習收獲 掌握分布式
周界防范系統包含哪些子系統？系統架構如何？系統如何設計？
周界防范系統的應用很廣泛，只要涉及到周界入侵防范的，都需要設置這個系統，有的設置電子圍欄，有的設置主動紅外報警，有的設置警戒攝像機等等，今天分享一套全面的周界防范系統設計方案，涉及到各個周界子系統，可以參考一下。
終將渡過成長的海
01
正文
第 一 章周界防范子系統
1.1系統概述
周界防范主要在園區周界，如圍墻、柵欄、樹林、邊界、河邊等場景中，通過各種技術手段一旦發現布防區域中的異常情況，系統能夠以最快和最佳的方式發出警報并提供有用信息，從而能夠更加有效的協助安保人員處理危機，最大限度的降低誤報和漏報現象，切實提高布放區域的安全防范能力，是園區安防系統的第一道防線。
1.2系統設計
1.2.1系統架構
周界防范子系統由前端報警、傳輸網絡、管理中心組成。其中前端報警部分包括周界入侵探測器和防區脈沖主機以及報警主機。報警主機到管理中心的傳輸網絡可以是公共電話交換網（PSTN）、無線信道（CDMA/GSM）、Internet網絡等。管理中心則有管理計算機以及相應軟件組成。
整體架構如下圖所示：
圖1.周界防范系統架構圖
1.2.2業務流程
周界防范的業務流程分為：當有活動目標進入布防區域時，檢測設備開始檢測活動目標，產生周界防范報警事件，并將事件上報給后中心平臺；綜合安防管理平臺報警系統接收到事件后，可進行事件查看，并通過平臺的聯動模塊配置不同的聯動方式。
展開 MBSE體系架構模型的理論研究：基于MBSE與SysML的空空導彈系統架構建模研究
空空導彈系統是一個涉及機械、控制、電子、液壓和軟件等多種領域的復雜大系統[1,2]。傳統的空空導彈設計方法是一種文檔驅動式設計方法，主要包括系統方案設計、系統詳細設計、系統軟硬件聯調、系統驗證分析等多個步驟。隨著航空技術的發展，當前空空導彈設計方法轉變為基于文檔和數字化模型混合的設計方法，但其本質上還是文檔驅動式的設計方法。該方法各階段的設計成果均為文字、圖表等文檔，導致在各階段之間傳遞的信息也是各種文檔，造成了設計方案表達不充分、信息表達的二義性、領域設計之間存在鴻溝、文檔的不可執行性以及軟件測試工作量大等缺點。近年來，基于模型的系統工程（MBSE）技術越來越得到工業界的認可[3-5]，MBSE 是系統設計工作通過數字化設計手段的實現，因此在工作流程上與傳統系統工程并無太大差異，仍然分為需求分析、系統分析、系統設計三個步驟[6-8]。MBSE與傳統系統工程方法主要的區別是利用模型代替傳統的文檔方式，模型具有的唯一性和可執行性是其最大的特點。基于此，本文引入基于SysML的系統架構建模方法[9,10]，在方案設計階段利用基于MBSE的設計方法對空空導彈系統架構進行建模，并對不同系統架構進行仿真分析，最終獲得最優系統架構，實現在方案論證階段減少甚至消除設計中的邏輯錯誤，避免到設計后期才發現由于邏輯錯誤而造成循環設計[11-13]。
1 MBSE理論概述
本文展開基于MBSE 的空空導彈系統架構設計工作。從需求分析和用例出發，利用RHAPSODY 建模工具，基于MBSE 方法和SysML建模語言，對空空導彈系統架構進行建模與仿真，主要包括基于SysML 的需求分析、系統分析和系統設計三個部分，最終實現在空空導彈系統方案設計階段對其架構進行仿真，獲得最優系統架構。
展開 工廠視頻監控系統架構如何設計？
怎樣設計工廠的視頻監控系統？工廠內視頻監控的系統結構是什么？本文對工廠視頻監控系統的設計方案進行了探討。
終將渡過成長的海
01
正文
一、系統概述
針對工廠智能化生產和辦公的實際需要，在車間、倉庫、職能部門等各目標部位安裝24小時監控設備。
二、系統設計
全套高清攝像機，支持攝像和攝像功能；主機房配置核心交換機，提供視頻大容量數據交換，核心交換機通過萬兆光纖連接到聚合層交換機，匯聚層到接入層通過千兆光纖傳輸，接入層交換機提供百兆 POE以太網端口連接 HD攝像機(傳輸部分已經包括在網絡通信中)；視頻處理選擇監控管理平臺軟件，配備監控管理平臺服務器，將視頻存儲在網絡存儲陣列中，存儲陣列容量保證所有視頻都能保存30天；顯示部分支持多界面顯示，支持遠程控制，視頻管理，視頻播放等功能；視頻監控系統可與其他安全系統集成。監視中心設備位于網絡主機房服務器機柜內。監控點的設計見綜合布線圖和視頻監控圖，根據監控點的設計使用監控機。
展開 【CATIA】設計架構 | 達索系統百世慧?
供與大多數CAD系統的接口，以優化整個供應鏈中的溝通。
產品數據管理的集成解決方案。
角色/功能
擴展STEP界面
為長期歸檔和公司流程提供了新的擴展STEP功能：
大型程序集可以導出為多個STEP文件，每個產品一個文件。
有兩個可能的選項，全局和部分。
Global為裝配的所有級別生成STEP文件。
Partial僅為一種產品生成STEP文件（不導出子級別）。
允許用戶以STEP格式存儲CATIA FT＆A演示文稿的真實副本，并進行檢索（所見即所得的導入/導出）。
適用的數據啟動器（例如復合材料）。
產品數據過濾
在數據交換之前有選擇地刪除敏感信息來幫助公司管理和保護其知識產權：
根據零件或產品結構定義，可以在與供應商鏈和/或OEM進行數據交換之前，使用經過過濾（刪除）的敏感信息來創建新零件。
CAA API僅適用于產品過濾。
可以以交互方式或批處理方式調用。
批處理模式可通過命令行使用，其中過濾選項作為參數傳遞。
步驟插入
提供CAD數據的互操作性功能，以實現MultiCAx可視化和上下文設計：
組織在保留其CAD投資的同時仍能受益于豐富的上下文設計和數字模型化流程。
協同工作，數據來自多個不同的CAD系統，并在單個異構數字模型和設計環境中使用。
利用數字模型和設計工具（例如平面，坐標系和圓柱軸）提供的功能，對MultiCAx零件進行精確定位和精確測量。
裝配支持：在支持裝配的情況下，可以解決裝配到零件的鏈接，從而可以將完整的裝配自動，準確地插入到數字模型產品結構中。
展開 嵌入式系統的軟件架構設計！
如果你是這個設備的架構師，哪些問題是在設計架構的時候應該關注的呢？
2.1. 常見的誤解
2.1.1. 小型的系統不需要架構
有相當多的嵌入式系統規模都較小，一般是為了某些特定的目的而設計的。受工程師認識，客戶規模和項目進度的影響，經常不做任何架構設計，直接以實現功能為目標進行編碼。這種行為表面上看滿足了進度、成本、功能各方面的需求。但是從長遠來看，在擴展和維護上付出的成本，要遠遠高于最初節約的成本。如果系統的最初開發者繼續留在組織內并負責這個項目，那么可能一切都會正常，一旦他離開，后續者因為對系統細節的理解不足，就可能引入更多的錯誤。
要注意，嵌入式系統的變更成本要遠遠高于一般的軟件系統。好的軟件架構，可以從宏觀和微觀的不同層次上描述系統，并將各個部分隔離，從而使新特性的添加和后續維護變得相對簡單。
舉一個城鐵刷卡機的例子，這個例子在前面的課程中出現過。簡單的城鐵刷卡機只需要實現如下功能：
一個While循環足以實現這個系統，直接就可以開始編碼調試。但是從一個架構師的角度，這里有沒有值得抽象和剝離的部分呢？
計費系統。計費系統是必須抽象的，比如從單次計費到按里程計費。
傳感器系統。傳感器包括磁卡感應器，投幣器等。設備可能更換。
故障處理和恢復。考慮到較高的可靠性和較短的故障恢復時間，這部分有必要單獨設計。
未來很可能出現的需求變更：
操作界面。是否需要抽象出專門的Model來？以備將來實現View。
數據統計。是否需要引入關系型數據庫？
如果直接以上面的流程圖編碼，當出現變更后，有多少代碼可以復用？
不過，也不要因此產生過度的設計。
展開 MBSE產品模型架構應用：基于模型的系統工程 (MBSE) 在汽車傳動系統子系統架構中的應用
上下文圖/背景圖：
○ 代表系統與外部環境的交互
○ 交互系統被定義為“黑盒”
P-圖：
○ 擴展和細化上下文以獲得更詳細的黑匣子
○ 包括有關輸入信號、控制因素、噪聲因素、輸出和潛在故障模式的詳細信息
MBSE
○ 建模語言（SysML、UML 等）
○ 建模方法
○ 建模工具（Magicdraw、IBM Rational Rhapsody 等）
基于模型的系統工程概念：系統需求
● 需求以技術術語定義客戶和利益相關者的需求
● 在 SysML 中，系統需求陳述被定義為對象
● 每個對象都包含需求文本和唯一標識符
● 需求類型定義了需求可以關聯的特征
● 泛化通過繼承關系管理和分配需求
● 需求必須通過測試用例進行驗證
● 測試用例是檢查點，例如設計評審或物理測試
SysML中的標準類型需求用于在定義系統時提供嚴格性和清晰性
基于模型的系統工程概念：功能和邏輯架構
● 功能定義必須完成或完成哪些動作/活動才能獲得預期結果
● 操作是塊的屬性
● 塊是系統任何部分的抽象表示，如物理硬件或信號
● 功能通過與各個子系統和組件的邏輯關系相互關聯
● 邏輯架構描述了系統將如何實現
● 邏輯架構抽象地定義了基于系統所需的子系統、組件及其關系的技術解決方案
● 邏輯架構只能在明確定義系統的功能和需求后創建
● 邏輯架構沒有定義任何特定的系統實現，而是定義通用指南，以保持解決方案中立
建模方法：功能分解
● 從 P 圖中識別出傳動系統的五個基本操作
● 系統需要
○ 傳遞扭矩
展開 
基于新架構的智能汽車整車線束設計研究
本文從成本的角度、電連接性能以及汽車電子電氣新架構角度出發，對整車線束的設計進行了研究，達到了提高車輛可靠性、降低成本、提升電連接性能的目的。
1. 電子電氣架構對汽車影響
電子電氣架構起到電子電氣系統總布置的功能。在功能需求、法規和設計要求等特定約束下，通過對功能、性能、成本和裝配等各方面進行分析，所得到最優的電子電氣系統模型。就現代汽車制造業來說，汽車電子電氣架構設計集中反映出消費者對于汽車舒適度、人性化、智能化以及美觀性的消費需求。同時，汽車電子電氣架構是一項系統、復雜的工作，廣泛涉及軟件、硬件、網絡、線路等多方面內容。
2. 電子電氣架構設計流程
針對汽車電子電氣架構的設計，國際通用的開發模式為V模式開發流程。電子電氣架構整體設計工作和流程優化，需要遵循六個步驟進行，電子電氣架構開發流程見圖1。
圖1 電子電氣架構開發流程
1）對于汽車功能需求進行定義。在該階段實施期間，需要根據市場對汽車的實際需求、客戶的具體需求進行分析，并對這些數據進行整理、分析以及統計等工作，保證在初期工作中，能夠對整車需求進行統計與評估，也能對進電子電器系統需求進行定義，這樣才能使電氣測試規范的制定滿足相關需求。
2）對整個電子電器系統的架構進行設計，保證其制定的合理性。期間，需要根據電子電氣系統的實際需求，對各個系統以及電氣加工方案進行合理制定，在整體上，保證整車電子電氣架構方案物理、邏輯架構的充分設計。
3）對電子電器件進行具體設計。在實際工作執行期間，需要根據一個環節，對電子電氣架構方案進行物理、邏輯的優化設計，保證在真正含義能夠促進電氣電器件解決方案的優化設計。
展開 基于新架構的智能汽車整車線束設計研究
來源 |
汽車功能安全
本文從成本的角度、電連接性能以及汽車電子電氣新架構角度出發，對整車線束的設計進行了研究，達到了提高車輛可靠性、降低成本、提升電連接性能的目的。
1. 電子電氣架構對汽車影響
電子電氣架構起到電子電氣系統總布置的功能。在功能需求、法規和設計要求等特定約束下，通過對功能、性能、成本和裝配等各方面進行分析，所得到最優的電子電氣系統模型。就現代汽車制造業來說，汽車電子電氣架構設計集中反映出消費者對于汽車舒適度、人性化、智能化以及美觀性的消費需求。同時，汽車電子電氣架構是一項系統、復雜的工作，廣泛涉及軟件、硬件、網絡、線路等多方面內容。
2. 電子電氣架構設計流程
針對汽車電子電氣架構的設計，國際通用的開發模式為V模式開發流程。電子電氣架構整體設計工作和流程優化，需要遵循六個步驟進行，電子電氣架構開發流程見圖1。
圖1 電子電氣架構開發流程
1）對于汽車功能需求進行定義。在該階段實施期間，需要根據市場對汽車的實際需求、客戶的具體需求進行分析，并對這些數據進行整理、分析以及統計等工作，保證在初期工作中，能夠對整車需求進行統計與評估，也能對進電子電器系統需求進行定義，這樣才能使電氣測試規范的制定滿足相關需求。
2）對整個電子電器系統的架構進行設計，保證其制定的合理性。期間，需要根據電子電氣系統的實際需求，對各個系統以及電氣加工方案進行合理制定，在整體上，保證整車電子電氣架構方案物理、邏輯架構的充分設計。
3）對電子電器件進行具體設計。
展開 No Magic—復雜機電產品系統架構開發套件
<p><strong>產品概述</strong></p><p> CATIA Magic，原名MagicDraw，俗稱No Magic，被達索收購后融入3DExperience產品協同研發管理平臺中，形成更具協同體驗的系統工程解決方案。該軟件提供對SysML/UML/UAF語言的完整支持，提供獨有的MagicGrid方法論，涵蓋：業務和任務分析、利益攸關者需要及需求分析、系統需求定義、系統架構定義、設計方案權衡、系統分析驗證及協同設計管理等內容，支持早期對方案可行性進行快速驗證，并更快地分析替代方案，探索更完整的設計空間。采用統一的標準語言及流程規范，借助協同研發平臺的統一數據源優勢，實現模型元素追溯，便于變更管理及影響分析、提高設計重用、溝通和理解質量。</p><p> </p><p><strong>產品功能及特點</strong></p><ul><li>提供獨特的MagicGrid方法論</li></ul><p> MagicGrid方法論是基于INCOSE-OOSEM方法和MBSE工程實踐提出的，與ISO/IEC/IEEE 15288定義的流程一致。涵蓋：問題域與利益相關者需求開發流程、解決方案域與架構定義流程及實現域與設計實現流程。該方法論為客戶提供了完整且適用于產品研發流程的MBSE建模框架，支撐產品自頂而下的逐層分解，及自底而上的系統集成，為產品指標優化及系統設計協同奠定基礎。
展開 助力國產操作系統！國內首款基于云架構的三維CAD：CrownCAD，設計師們歡呼吧！（2021年9月8日正式發布）
在努力追趕國際先進水平9年后，國內首款完全自主可控的新一代基于云架構的三維CAD產品——CrownCAD，將于2021年9月8日正式發布。將“工業大腦”搬上云端，打開網頁就能進行產品三維設計，CrownCAD或將實現“換道超車 ”。
國產三維云CAD:CrownCAD 通過 Web 瀏覽器將它們帶給用戶，從而提供最流行和最需要的云功能——數據存儲和管理、3D 可視化、通信和協作。可以在CrownCAD 平臺上開發應用程序，以提供更復雜和特定的用戶功能，例如在 Web 上建模，編輯和分析 3D 模型，CAE有限元，以及二次開發。由于被許可方可獲得 CrownCAD的附加價值，這些應用程序的開發速度比平時快得多。
CrownCAD擁有完全自主的三維幾何建模引擎DGM和幾何約束求解器DCS兩大CAD核心技術，在CAD關鍵技術上實現國產自主，很大程度上使中國制造業不再受制于人，為中國制造業的創新提供堅實保障。
CrownCAD的使用非常靈活，不僅對成熟的公司而且對雄心勃勃的初創企業都具有吸引力。
結合了許多典型的工程功能，如可視化和創作 3D 模型，以及調度用戶請求和數據存儲的云能力。雖然 3D 模型的所有計算都是在云服務器上進行的，但用戶可以訪問 3D 模型的表示，并可以通過 WebGL 和 Typescript/Javascript 在基于 Web 瀏覽器的應用程序中導航和操作它。在實時協作期間提供對模型的即時操作，具有適合大公司的可擴展性。
三維CAD平臺CrownCAD技術。它是一個多用戶平臺，專為協作工作而設計，專為在私有云和公共云上工作而設計。
展開 