系統架構的案例
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 的需求分析、系統分析和系統設計三個部分，最終實現在空空導彈系統方案設計階段對其架構進行仿真，獲得最優系統架構。
展開 以飛機為例的MBSE系統架構入門系列(1)
因此，一個架構設計空間就產生了，不同的系統架構從這個空間衍生出來，并沿著敏捷4.0系統工程產品開發過程向前推進。
飛機系統簡介
飛機是系統，因為它可以飛行和運輸有效載荷（系統功能），這得益于其所有實體連接在一起，如發動機、機身、機翼和機載系統。因此，架構圖描述了系統的不同方面。例如，架構可以表示組成系統的所有部分、它的生命周期、外部用戶如何操作它以及許多其他信息。系統架構是一種特定的體系結構，它只表示作為系統一部分的所有組件（系統體系結構中的實體）以及它們是如何連接在一起的。體系結構框架為多個系統體系結構的標準表示提供了指導方針。文獻中有幾種架構框架可用，例如Zachman的框架、DoDAF、MODAF、NAF和TOGAF。
展開 MBSE | 創新藍圖：系統架構模型的重要性
因此，工程師和設計人員面臨著新的挑戰，而傳統的系統工程流程已難以為繼。此外，企業規模越來越大、越來越復雜，這會進一步加劇挑戰，因此需要可擴展且可供所有利益相關方訪問的解決方案。
以設計無人駕駛月球車為例，該月球車將探索月球表面，并為研究人員收集重要數據。月球車的復雜設計不僅依賴于最新技術，還依賴于具有多學科背景的大型研究團隊的專業知識。
月球上的月球車
為了正確地開展協作，研究人員需要一種有效共享信息的方法，確保他們都在使用最新的設計迭代，并確認所有設計階段都符合安全標準，而上述這些步驟都隨著設計的日益復雜而變得更具挑戰性。
什么解決方案有可能改善這種情況呢？航空航天與國防（A&D）、汽車、高科技和醫療等眾多行業的研究人員，都在利用系統架構模型（SAM）來應對這些現代挑戰。為了一探究竟，我們來深入了解一下為什么各行各業的工程師都在使用SAM。
在快速變化的領域開發日益復雜的技術
首先，作為基礎背景，我們先來探討基于模型的系統工程（MBSE），這是一種不斷發展的方法，它利用數字系統和模型而不是文檔，來設計、制造和維護復雜系統。
MBSE并不依賴傳統的靜態文檔，而是通過創建和使用數字系統和工程領域模型，來促進關鍵信息、反饋和需求的交換。
對于現代工程師而言，MBSE提供了一種結構化、系統化的方法來解決復雜的工程問題，從而簡化開發流程并提高效率。MBSE包括三個主要組成部分：
1. 統領性的SAM
在SAM中，所設計的系統由一系列描述系統物理和功能架構的連接方框圖表示。SAM還包含系統所需達到的質量和功能的綜合列表。
在MBSE中，SAM是待研究系統架構的真相源。
展開 淺談系統安全架構設計
對于一個系統，架構設計通常決定了該系統的整體性能表現，而功能安全標準對架構設計的要求及安全分析方法論引用比較復雜，如何在系統設計之初，合理并充分的考慮其安全設計成為了當前很多同行在做安全設計的一個難點。
筆者從事功能安全領域工作八年有余，有過多家外企合資企業的三電系統，ADAS系統相關產品的安全開發設計經驗。此次受SESETECH安全技術論壇邀請，結合個人經驗分享一下對系統安全架構設計的淺薄理解，希望能夠解決部分同行對于安全架構設計的痛點。限于個人認知，此文僅供各位同行交流討論，不針對任何企業或者產品安全提出設計建議。
內容框架：
安全架構設計必須了解的術語及安全方法說明
E-GAS三層架構的理解及使用約束
ADAS系統安全架構設計及安全等級的分解
02
安全架構設計必須了解的
術語及安全方法說明
在ISO 26262的第三部分，第四部分及第九部分，提到了很多關于系統或者相關項的安全術語，包括故障類型判斷，安全分解策略，故障控制/避免措施，等。如何正確地理解并應用這些術語及背后的方法論，對于安全架構設計尤為重要。本文主要針對涉及到系統安全架構設計的必要術語進行一些系統性闡述，幫助大家理解其中關系。
故障控制措施（Fault control）
和故障避免措施（Fault avoidance）
在功能安全標準或者一些教學中，經常會提到系統性失效和隨機硬件失效兩個概念作為電子電氣系統的兩大失效來源。
展開 
MBSE建模語言學習：ARCADIA和SysML方法在自適應巡航控制系統架構建模中的對比
狀態機指定系統何時執行特定動作。
圖20. ACC狀態機圖
指定“黑盒”需求
需求分析結果將應用在基于場景分析和其他行為分析的系統黑盒規范中。黑盒規范定義了系統的外部可觀察的行為和物理特性。系統需求以所需的功能、外部接口、性能和質量特征、控制和系統必須存儲的項的形式被捕獲。需求通常使用SysML需求圖（req）創建，并直接鏈接到相關的模型元素。無論如何，需求總是可以導出為所需的格式。
3. 邏輯架構定義
邏輯架構設計和定義的目的在于，基于已識別的系統功能創建系統架構的抽象表示，為后面在物理架構階段進行的組件和技術選擇提供基線。換句話說，這個階段的目標是捕獲解決方案的主要架構驅動因素，確定高層級組件及其預期功能，提供系統如何工作的愿景，而不必過多地關注技術細節。
ARCADIA方法
邏輯架構（Logical Architecture, LA）
邏輯架構定義是從問題域轉移到解決方案域的階段。運行分析（OA）和系統分析（SA）階段有助于更好地了解用戶和系統需求，邏輯架構（LA）和物理架構（PA）階段有助于找到抽象和具體的解決方案來滿足這些需求。
為定義邏輯架構而開展的主要活動如下：
· 定義影響架構的因素并分析視角；
· 定義系統行為的原理；
· 構建基于組件的系統結構備選方案；
· 選擇提供最佳權衡方案的架構備選方案。
這一階段的主要步驟是：
· 定義邏輯組件
· 邏輯功能分解
· 定義邏輯組件場景和狀態
· 為組件分配邏輯功能
定義邏輯組件
系統的邏輯組件是根據分配給系統的功能來標識的。
展開 MBSE架構圖：一種集成系統建模與多學科分析的MBSE開發框架
3
系統建模與流程
根據圖2給出的整體MBSE集成方案架構，將通過以下六個主要步驟完成整個建模與分析過程。此模型框架建模步驟包括：
1) 生成需求圖及系統架構；
圖3 創建需求和系統架構
a) 最初的需求規格可以是用DOORS/Excel進行描述，將早期的需求規格說明導入到Rhapsody/MagicDraw中，創建需求圖，在需求圖中包含相應指標的上下限以及需求目標。
圖4 建立需求圖
b) 基于需求生成系統架構，定義SysML原型，使用SysML的BDD圖對系統架構進行描述。
本方案中，將SysML進行了擴展來描述建模分析組件，這些組件運行在ModelCenter框架。下圖給出了配置屬性中定義的原型。MC_Component原型用于指定一個約束模塊(例如，分析塊)的可執行的分析模型的位置。MC_Variable 原型來創建SysML端口(例如，參數)和分析模型變量之間的映射。InOut枚舉來指定由MC_Variable原型實例化參數(輸入或輸出)的因果關系。在這個功能中，工程分析被用于自動檢查需求的一致性。為了達到這個目的，RequirementVerification模板可以應用于需求塊。
展開 下一代自動駕駛域控制器系統架構設計
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是面向對象的服務架構，本文不做深入探討。
展開 周界防范系統包含哪些子系統？系統架構如何？系統如何設計？
周界防范系統的應用很廣泛，只要涉及到周界入侵防范的，都需要設置這個系統，有的設置電子圍欄，有的設置主動紅外報警，有的設置警戒攝像機等等，今天分享一套全面的周界防范系統設計方案，涉及到各個周界子系統，可以參考一下。
終將渡過成長的海
01
正文
第 一 章周界防范子系統
1.1系統概述
周界防范主要在園區周界，如圍墻、柵欄、樹林、邊界、河邊等場景中，通過各種技術手段一旦發現布防區域中的異常情況，系統能夠以最快和最佳的方式發出警報并提供有用信息，從而能夠更加有效的協助安保人員處理危機，最大限度的降低誤報和漏報現象，切實提高布放區域的安全防范能力，是園區安防系統的第一道防線。
1.2系統設計
1.2.1系統架構
周界防范子系統由前端報警、傳輸網絡、管理中心組成。其中前端報警部分包括周界入侵探測器和防區脈沖主機以及報警主機。報警主機到管理中心的傳輸網絡可以是公共電話交換網（PSTN）、無線信道（CDMA/GSM）、Internet網絡等。管理中心則有管理計算機以及相應軟件組成。
整體架構如下圖所示：
圖1.周界防范系統架構圖
1.2.2業務流程
周界防范的業務流程分為：當有活動目標進入布防區域時，檢測設備開始檢測活動目標，產生周界防范報警事件，并將事件上報給后中心平臺；綜合安防管理平臺報警系統接收到事件后，可進行事件查看，并通過平臺的聯動模塊配置不同的聯動方式。
展開 前沿 | 針對智能駕駛的預期安全系統架構
為了解決安全問題，提出了一種智能駕駛安全系統。該系統針對智能汽車感知、決策和控制方面的預期問題，實時提供安全分析和監控服務模塊。基于預期功能安全的概念，對駕駛場景和系統安全進行分析和評估，以提高智能駕駛的安全性，有助于智能駕駛的發展。
1.介紹
智能駕駛汽車的駕駛行為高度依賴于操作系統的穩定性、智能性、安全性。
安全風險主要來源于以下三類：
硬件安全
與傳統汽車相比，智能駕駛汽車不要求駕駛員直接控制車輛，而是將部分或者是全部的控制權限交由自動控制系統。硬件架構設置是否科學合理；各無人計算控制單元和控制器的設置是否完善；無人駕駛的傳感器是否完善；車輛能夠快速準確地獲取道路環境信息，車輛運動感知和信息融合功能在無人駕駛車輛中起著決定性作用。
軟件安全
與傳統汽車相比，自動駕駛汽車的開發時間較短，技術開發仍不成熟，軟件系統仍需要長期的可靠性分析。例如，著名的無人駕駛汽車制造商谷歌已經在無人駕駛汽車平臺上進行了9年的封閉式測試，但測試時間不夠，因素也相對很簡單。因此，其安全性和穩定性仍需要長期監測。
環境安全
在人工智能算法的基礎上，智能駕駛汽車能夠實現自動避障和完成自動駕駛在一些較為復雜的道路上。然而，無人駕駛汽車仍然需要其他的交通參與者的正確駕駛來駕駛。只有當其他駕駛員做出正確駕駛的判斷時，無人駕駛汽車的測試才會相應做出正確、合理的判斷。
該論文在對無人駕駛事故和安全隱患的分析基礎上，提出了自動駕駛汽車的預期安全系統。該系統可以進行監督、預測和保證智能駕駛車輛的駕駛狀態，從感知、決策和控制等方面提高智能駕駛的安全性。
2.系統架構
智能駕駛離不開幾項關鍵技術。
展開 
針對智能駕駛的預期安全系統架構
對目標場景的考慮不全面，導致系統無法準確識別環境要素；功能仲裁邏輯不合理，導致系統決策錯誤；執行機構響應不足，導致運動控制偏離預期。
環境干擾
自動駕駛受到路況、周邊事物、環境天氣等諸多因素的影響。如何克服環境干擾，可靠地執行環境工作行車識別、駕駛決策和運動控制是確保安全駕駛的關鍵。預期安全系統源于預期功能安全(SOTIF)的概念，旨在為智能駕駛的感知、決策和控制系統(執行響應)設計一種安全監管系統，以克服環境干擾，改善智能駕駛系統的局限性。建議的安全系統架構如下圖所示。
該安全系統預計將分為三個基本模塊：感知數據的處理、決策信息的確定和執行器響應的檢測。首先，基于智能車輛傳感器的感覺數據，進行多傳感器分析和融合，重建當前的駕駛場景。通過分析駕駛現場，安全系統可以確定每個傳感器的置信度，并根據傳感器的置信度為智能汽車的決策和控制提供保證。
其次，決策信息的判斷主要基于“安全熵”和安全系統的定量評價。最后，執行器響應的檢測相對偏向于仿真和測試。對于已知情況，可以選擇軟件/硬件測試和車輛測試.
3. 駕駛現場和系統安全
駕駛現場構建
要分析駕駛場景，構建場景數據庫（如下圖）是一個先決條件。針對不同的典型場景，通過采集真實駕駛員的駕駛數據，形式化并分析駕駛決策。智能車輛結合場景檢索與識別，在保證各項功能的前提下，可以大大提高智能駕駛的安全性。
本文提到的駕駛場景庫由交通信號.道路屬性.環境屬性.時間構成
因此，提出了一種對行車場景進行定性分析作為多傳感器融合基礎的行車場景構建方案。
展開 掌握了這幾種監控系統架構，大小弱電監控項目都不怕！
監控系統是我們工作中最常見的子系統，監控系統架構常見的有幾種呢？今天給大家匯總一下，掌握這幾種系統架構，可以通吃市面上所有的大小監控系統了。
終將渡過成長的海
01
正文
第一種：傳統方式，由網絡攝像機+電源+網線組成
在綜合布線的時候，同時要布電源線和網線，電源也可以就近取220V交流電，這樣節省電源線材，這里暫不討論它的利弊。給每個網絡攝像機提供電源。再有一路網線傳輸網絡數據到網絡硬盤錄像機NVR。
第二種：POE供電方式，網絡攝像機+POE交換機
這樣就比前面一種方式節省一條電源線，一臺網絡攝像機只要一根網線作為傳輸信號的介質就可以，不再用到電源線了。網線用非屏蔽超五類雙絞線就可以了，傳輸距離90米沒有任何問題，100米建議用六類線。
展開 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建模框架，支撐產品自頂而下的逐層分解，及自底而上的系統集成，為產品指標優化及系統設計協同奠定基礎。
展開 以飛機為例的MBSE系統架構入門系列(3)
敏捷項目的兩個主要局限性
1.解決的MDAO問題的起點是一組給定的設計要求和給定的系統架構選擇（給定架構選擇的示例包括：選擇全電動機載系統、選擇支撐機翼系統等）。潛在的推理假設是認為提前完成需求和架構選擇，并且它們在整個交付過程中是不會發生任何變化的。這就導致了在給定的配置下限制了可選的（或可衡量的）權衡范圍。
2. 總體范式和旨在加速MDAO系統部署和操作的方法，還沒有通過利用數字設計工程原則進行形式化和建模。因此，一方面，形式化的缺乏對使用不同技術的外部人員利用該方法提出了挑戰。另一方面，由于追溯困難，缺乏“敏捷MDAO系統藍圖”的模型對變更或擴展的實現提出了挑戰(如第一個限制所示)。
一種系統，其中的原因和結果之間存在非平凡的關系：每個結果可能是由多個原因造成；每個原因可能產生多重影響；原因和結果可能作為反饋循環相關，有積極的和消極的；而且因果鏈是循環的、高度糾纏的，而不是線性可分的。
展開 