預期安全系統(tǒng)架構(gòu)的案例
前沿 | 針對智能駕駛的預期安全系統(tǒng)架構(gòu)
然而，由于近期無人駕駛事故頻發(fā)，安全性能令人擔憂。為了解決安全問題，提出了一種智能駕駛安全系統(tǒng)。該系統(tǒng)針對智能汽車感知、決策和控制方面的預期問題，實時提供安全分析和監(jiān)控服務模塊。基于預期功能安全的概念，對駕駛場景和系統(tǒng)安全進行分析和評估，以提高智能駕駛的安全性，有助于智能駕駛的發(fā)展。
1.介紹
智能駕駛汽車的駕駛行為高度依賴于操作系統(tǒng)的穩(wěn)定性、智能性、安全性。
安全風險主要來源于以下三類：
硬件安全
與傳統(tǒng)汽車相比，智能駕駛汽車不要求駕駛員直接控制車輛，而是將部分或者是全部的控制權(quán)限交由自動控制系統(tǒng)。硬件架構(gòu)設(shè)置是否科學合理；各無人計算控制單元和控制器的設(shè)置是否完善；無人駕駛的傳感器是否完善；車輛能夠快速準確地獲取道路環(huán)境信息，車輛運動感知和信息融合功能在無人駕駛車輛中起著決定性作用。
軟件安全
與傳統(tǒng)汽車相比，自動駕駛汽車的開發(fā)時間較短，技術(shù)開發(fā)仍不成熟，軟件系統(tǒng)仍需要長期的可靠性分析。例如，著名的無人駕駛汽車制造商谷歌已經(jīng)在無人駕駛汽車平臺上進行了9年的封閉式測試，但測試時間不夠，因素也相對很簡單。因此，其安全性和穩(wěn)定性仍需要長期監(jiān)測。
環(huán)境安全
在人工智能算法的基礎(chǔ)上，智能駕駛汽車能夠?qū)崿F(xiàn)自動避障和完成自動駕駛在一些較為復雜的道路上。然而，無人駕駛汽車仍然需要其他的交通參與者的正確駕駛來駕駛。只有當其他駕駛員做出正確駕駛的判斷時，無人駕駛汽車的測試才會相應做出正確、合理的判斷。
該論文在對無人駕駛事故和安全隱患的分析基礎(chǔ)上，提出了自動駕駛汽車的預期安全系統(tǒng)。該系統(tǒng)可以進行監(jiān)督、預測和保證智能駕駛車輛的駕駛狀態(tài)，從感知、決策和控制等方面提高智能駕駛的安全性。
2.系統(tǒng)架構(gòu)
智能駕駛離不開幾項關(guān)鍵技術(shù)。
展開 針對智能駕駛的預期安全系統(tǒng)架構(gòu)
導致危害的因素
所需的安全技術(shù)
車輛因素
電子電氣系統(tǒng)的故障
功能安全
電子電氣系統(tǒng)功能的局限性
預期功能安全
環(huán)境因素
環(huán)境干擾
網(wǎng)絡攻擊
信息安全
系統(tǒng)功能限制
主要原因是設(shè)計開發(fā)過程中的系統(tǒng)功能定義不能完全滿足目標市場的使用要求。對目標場景的考慮不全面，導致系統(tǒng)無法準確識別環(huán)境要素；功能仲裁邏輯不合理，導致系統(tǒng)決策錯誤；執(zhí)行機構(gòu)響應不足，導致運動控制偏離預期。
環(huán)境干擾
自動駕駛受到路況、周邊事物、環(huán)境天氣等諸多因素的影響。如何克服環(huán)境干擾，可靠地執(zhí)行環(huán)境工作行車識別、駕駛決策和運動控制是確保安全駕駛的關(guān)鍵。預期安全系統(tǒng)源于預期功能安全(SOTIF)的概念，旨在為智能駕駛的感知、決策和控制系統(tǒng)(執(zhí)行響應)設(shè)計一種安全監(jiān)管系統(tǒng)，以克服環(huán)境干擾，改善智能駕駛系統(tǒng)的局限性。建議的安全系統(tǒng)架構(gòu)如下圖所示。
該安全系統(tǒng)預計將分為三個基本模塊：感知數(shù)據(jù)的處理、決策信息的確定和執(zhí)行器響應的檢測。
展開 面向預期功能安全的決策規(guī)劃系統(tǒng)仿真測試方法
因為，觸發(fā)機制隱蔽、觸發(fā)源往往不是獨立要素（涉及到復合場景）、觸發(fā)條件與所產(chǎn)生的危害對應關(guān)系不明（作用過程是連續(xù)的）
依據(jù)上述分析可知：針對環(huán)境感知系統(tǒng)分析觸發(fā)條件是比較可行的；我們采用了基于事件鏈的分析框架，結(jié)合觸發(fā)源本體模型進行推演，取得了一定的效果。然而，針對決策規(guī)劃系統(tǒng)，想要提出類似的系統(tǒng)性分析方案則非常困難；對于L3+或及復雜場景下的自動駕駛系統(tǒng)而言，上述問題尤甚（注：對于簡單環(huán)境中，執(zhí)行簡單行駛?cè)蝿盏淖詣玉{駛系統(tǒng)而言，尚可進行一定程度的分析）。
由此引出了本文的關(guān)鍵問題：如何有效地針對決策規(guī)劃系統(tǒng)進行預期功能安全分析與測試？
2 綜述：面向SOTIF的決策規(guī)劃系統(tǒng)仿真測試方法
由于決策規(guī)劃系統(tǒng)的輸入輸出都是信息和信號，相對于整車在環(huán)或場地實車測試而言，系統(tǒng)在環(huán)仿真測試是對其進行測試的最主要手段（等效性高、測試效率高、成本低）。此外，在測試過程中，一般將決策規(guī)劃系統(tǒng)視為“黑箱”處理。
以下繼續(xù)圍繞第一部分留下的關(guān)鍵問題，將現(xiàn)有的相關(guān)測試方法做分析和梳理，希望明確其中較為可行的仿真測試方法及其適用性。
在此借用一下哈貝馬斯（Habermas）哲學分析理論里的兩個概念：系統(tǒng)（System）與生活世界（Life world）；前者是人為設(shè)計的、規(guī)范的，而后者是自然發(fā)生的。
展開 面向預期功能安全的決策規(guī)劃系統(tǒng)仿真測試方法
因為，觸發(fā)機制隱蔽、觸發(fā)源往往不是獨立要素（涉及到復合場景）、觸發(fā)條件與所產(chǎn)生的危害對應關(guān)系不明（作用過程是連續(xù)的）
依據(jù)上述分析可知：針對環(huán)境感知系統(tǒng)分析觸發(fā)條件是比較可行的；我們采用了基于事件鏈的分析框架，結(jié)合觸發(fā)源本體模型進行推演，取得了一定的效果。然而，針對決策規(guī)劃系統(tǒng)，想要提出類似的系統(tǒng)性分析方案則非常困難；對于L3+或及復雜場景下的自動駕駛系統(tǒng)而言，上述問題尤甚（注：對于簡單環(huán)境中，執(zhí)行簡單行駛?cè)蝿盏淖詣玉{駛系統(tǒng)而言，尚可進行一定程度的分析）。
由此引出了本文的關(guān)鍵問題：如何有效地針對決策規(guī)劃系統(tǒng)進行預期功能安全分析與測試？
2 綜述：面向SOTIF的決策規(guī)劃系統(tǒng)仿真測試方法
由于決策規(guī)劃系統(tǒng)的輸入輸出都是信息和信號，相對于整車在環(huán)或場地實車測試而言，系統(tǒng)在環(huán)仿真測試是對其進行測試的最主要手段（等效性高、測試效率高、成本低）。此外，在測試過程中，一般將決策規(guī)劃系統(tǒng)視為“黑箱”處理。
以下繼續(xù)圍繞第一部分留下的關(guān)鍵問題，將現(xiàn)有的相關(guān)測試方法做分析和梳理，希望明確其中較為可行的仿真測試方法及其適用性。
在此借用一下哈貝馬斯（Habermas）哲學分析理論里的兩個概念：系統(tǒng)（System）與生活世界（Life world）；前者是人為設(shè)計的、規(guī)范的，而后者是自然發(fā)生的。
展開 
淺談系統(tǒng)安全架構(gòu)設(shè)計
對于一個系統(tǒng)，架構(gòu)設(shè)計通常決定了該系統(tǒng)的整體性能表現(xiàn)，而功能安全標準對架構(gòu)設(shè)計的要求及安全分析方法論引用比較復雜，如何在系統(tǒng)設(shè)計之初，合理并充分的考慮其安全設(shè)計成為了當前很多同行在做安全設(shè)計的一個難點。
筆者從事功能安全領(lǐng)域工作八年有余，有過多家外企合資企業(yè)的三電系統(tǒng)，ADAS系統(tǒng)相關(guān)產(chǎn)品的安全開發(fā)設(shè)計經(jīng)驗。此次受SESETECH安全技術(shù)論壇邀請，結(jié)合個人經(jīng)驗分享一下對系統(tǒng)安全架構(gòu)設(shè)計的淺薄理解，希望能夠解決部分同行對于安全架構(gòu)設(shè)計的痛點。限于個人認知，此文僅供各位同行交流討論，不針對任何企業(yè)或者產(chǎn)品安全提出設(shè)計建議。
內(nèi)容框架：
安全架構(gòu)設(shè)計必須了解的術(shù)語及安全方法說明
E-GAS三層架構(gòu)的理解及使用約束
ADAS系統(tǒng)安全架構(gòu)設(shè)計及安全等級的分解
02
安全架構(gòu)設(shè)計必須了解的
術(shù)語及安全方法說明
在ISO 26262的第三部分，第四部分及第九部分，提到了很多關(guān)于系統(tǒng)或者相關(guān)項的安全術(shù)語，包括故障類型判斷，安全分解策略，故障控制/避免措施，等。如何正確地理解并應用這些術(shù)語及背后的方法論，對于安全架構(gòu)設(shè)計尤為重要。本文主要針對涉及到系統(tǒng)安全架構(gòu)設(shè)計的必要術(shù)語進行一些系統(tǒng)性闡述，幫助大家理解其中關(guān)系。
故障控制措施（Fault control）
和故障避免措施（Fault avoidance）
在功能安全標準或者一些教學中，經(jīng)常會提到系統(tǒng)性失效和隨機硬件失效兩個概念作為電子電氣系統(tǒng)的兩大失效來源。
展開 MBSE產(chǎn)品模型架構(gòu)應用：基于模型的系統(tǒng)工程 (MBSE) 在汽車傳動系統(tǒng)子系統(tǒng)架構(gòu)中的應用
上下文圖/背景圖：
○ 代表系統(tǒng)與外部環(huán)境的交互
○ 交互系統(tǒng)被定義為“黑盒”
P-圖：
○ 擴展和細化上下文以獲得更詳細的黑匣子
○ 包括有關(guān)輸入信號、控制因素、噪聲因素、輸出和潛在故障模式的詳細信息
MBSE
○ 建模語言（SysML、UML 等）
○ 建模方法
○ 建模工具（Magicdraw、IBM Rational Rhapsody 等）
基于模型的系統(tǒng)工程概念：系統(tǒng)需求
● 需求以技術(shù)術(shù)語定義客戶和利益相關(guān)者的需求
● 在 SysML 中，系統(tǒng)需求陳述被定義為對象
● 每個對象都包含需求文本和唯一標識符
● 需求類型定義了需求可以關(guān)聯(lián)的特征
● 泛化通過繼承關(guān)系管理和分配需求
● 需求必須通過測試用例進行驗證
● 測試用例是檢查點，例如設(shè)計評審或物理測試
SysML中的標準類型需求用于在定義系統(tǒng)時提供嚴格性和清晰性
基于模型的系統(tǒng)工程概念：功能和邏輯架構(gòu)
● 功能定義必須完成或完成哪些動作/活動才能獲得預期結(jié)果
● 操作是塊的屬性
● 塊是系統(tǒng)任何部分的抽象表示，如物理硬件或信號
● 功能通過與各個子系統(tǒng)和組件的邏輯關(guān)系相互關(guān)聯(lián)
● 邏輯架構(gòu)描述了系統(tǒng)將如何實現(xiàn)
● 邏輯架構(gòu)抽象地定義了基于系統(tǒng)所需的子系統(tǒng)、組件及其關(guān)系的技術(shù)解決方案
● 邏輯架構(gòu)只能在明確定義系統(tǒng)的功能和需求后創(chuàng)建
● 邏輯架構(gòu)沒有定義任何特定的系統(tǒng)實現(xiàn)，而是定義通用指南，以保持解決方案中立
建模方法：功能分解
● 從 P 圖中識別出傳動系統(tǒng)的五個基本操作
● 系統(tǒng)需要
○ 傳遞扭矩
展開 經(jīng)緯恒潤預期功能安全（SOTIF）解決方案為自動駕駛安全保駕護航
近年來，“安全”被普遍認為是智能駕駛汽車被用戶接受或者得到商業(yè)應用最大的問題，ISO26262功能安全旨在避免由E/E系統(tǒng)功能失效導致的不可接受的風險，主要是針對系統(tǒng)性失效/隨機硬件失效導致的風險進行分析和控制，然而傳感器和感知算法(e.g. machine learning, neural networks) ，在沒有出現(xiàn)電子電器系統(tǒng)失效時，由于設(shè)計的局限性也會導致風險，但此部分并不屬于ISO 26262的范疇。為了彌補ISO 26262的局限，預期功能安全（Safety of the intended functionality，SOTIF）應運而生。
預期功能安全是自動駕駛車輛落地的重要保障，它確保了自動駕駛系統(tǒng)在各種正常操作情況下能夠安全地執(zhí)行其預期功能，提高系統(tǒng)的安全性和可靠性。這包括了正確理解復雜場景、合理和可靠的決策系統(tǒng)，以及高風險情況的處理。從而使自動駕駛技術(shù)能夠真正應用于實際交通環(huán)境中，實現(xiàn)自動駕駛車輛的商業(yè)化和大規(guī)模應用。
經(jīng)過長期探索，經(jīng)緯恒潤形成一套全流程的預期功能安全產(chǎn)品開發(fā)技術(shù)咨詢服務。不僅融合了功能安全和預期功能安全活動，建立滿足雙重“安全”標準的流程體系。同時，還深入預期功能安全各個階段開發(fā)活動，從安全分析、數(shù)據(jù)驅(qū)動、場景開發(fā)多個維度提升自動駕駛功能的安全性和可用性。從流程和產(chǎn)品兩個維度幫助企業(yè)更好實現(xiàn)自動駕駛落地。
· 流程上：經(jīng)緯恒潤總結(jié)的雙重“安全”標準的流程體系，與企業(yè)內(nèi)現(xiàn)有開發(fā)流程完成融合。流程搭建完成后，可由國際認證機構(gòu)DEKRA進行認證審核，審核通過后頒發(fā)流程認證證書。
展開 如何理解預期功能安全
當前汽車行業(yè)熱度非常高的三個標準為預期功能安全ISO21448，功能安全ISO26262和網(wǎng)絡安全ISO21434，其中預期功能安全對于系統(tǒng)開發(fā)者來說比較陌生，容易將它與功能安全混為一談，預期功能安全要解決的問題是什么，為什么要在功能安全之外還要考慮預期功能安全，網(wǎng)上已經(jīng)有很多的資料去講，本篇談談對預期功能安全概念的理解。
背景
Road vehicles - safety of the intended functionality SOTIF（道路車輛 預期功能安全）標準在2019年1月作為公開技術(shù)規(guī)范發(fā)布（ISO/PAS 21448），正式版預計將于2022年發(fā)布，目前PAS版本共有29頁+23頁附件，重點關(guān)注SAE自動化level 1和level 2駕駛輔助功能。
這個規(guī)范用于降低由于系統(tǒng)的預期功能不足（設(shè)計不足或性能局限）或可預見的人員誤操作導致的不可接受風險，這也是預期功能安全概念的定義，適用的電子系統(tǒng)為安全功能受外部環(huán)境影響的功能，來自于傳感器和處理算法，典型的有AEB自動緊急制動系統(tǒng)、車道保持系統(tǒng)等高級駕駛輔助系統(tǒng)。
預期功能安全概念
功能安全在于解決系統(tǒng)內(nèi)的隨機失效和系統(tǒng)性失效引起的危害，造成安全事故，包括硬件故障、軟件故障，而系統(tǒng)功能正常時出現(xiàn)的危害不在功能安全考慮的范圍內(nèi)，由于使用傳感器或算法的性能限制，駕駛?cè)藛T對系統(tǒng)的誤操作，SOTIF規(guī)范的推出旨在解決這一類問題。下圖來自中國汽車標準化技術(shù)委員會在2020年發(fā)布的《預期功能安全國際標準ISO21448及中國實踐白皮書》，用于說明功能安全與預期功能安全概念的區(qū)別。
展開 自動駕駛預期功能安全要素及準入難點解讀
作者 | Aimee
出品 | 焉知
知圈 | 進“電子電氣群”請加微13636581676,備注架構(gòu)
自動駕駛汽車準入制度旨在為自動駕駛汽車市場化提供合法性支撐、預防和應對技術(shù)的不確定性挑戰(zhàn)，并尋求道德倫理的正當性。當前，自動駕駛功能的研發(fā)及量產(chǎn)已經(jīng)進入白熱化階段，各家主機廠在該領(lǐng)域的投入也傾注了大量的精力和能力，對于上市也是勢在必得。但是對于法律和標準規(guī)定來說，自動駕駛上市必須拿到工信部代表交通部頒發(fā)相關(guān)的準入牌照才能受到相關(guān)社會的認可。
然而，自動駕駛準入需要充分考慮汽車研發(fā)的各個方面，最重要的是保證駕駛過程中具備足夠的安全性，這就要求在設(shè)計之初就需要充分考慮到其中的關(guān)鍵一環(huán)：功能安全及預期功能安全。由功能安全涉及的失效和故障（一般指系統(tǒng)級功能和功能故障的E / E故障）將導致錯誤的轉(zhuǎn)向或制動，這被認為是自動駕駛與安全性相關(guān)的最高風險（一般能達到ASIL D）。通過根據(jù)ISO PAS 21448 SOTIF方法開發(fā)的功能來定義安全功能和系統(tǒng)，包括第一個初步的體系結(jié)構(gòu)，是朝著按照ISO 26262應用功能安全性邁出的第一步-創(chuàng)建項目定義。該項目定義應包括功能的定義，包括其對環(huán)境和其他項目/車輛的依賴性以及與環(huán)境和其他項目/車輛的相互作用。根據(jù)項目定義，可以進行危害分析和風險評估，以找到該功能及其相關(guān)系統(tǒng)的根本要求或安全目標。下一步是開發(fā)功能和技術(shù)安全概念。
自動駕駛預期功能安全分析能力
自動駕駛系統(tǒng)必須具有一組基本的系統(tǒng)屬性，此處將其指定為功能。下面將討論為了聲明整個系統(tǒng)是安全的應具有的功能。這些功能分為故障安全功能（FS）和故障降級功能（FD）。故障安全功能可提供并實現(xiàn)客戶價值。故障安全功能可以被終止，因為其不可用性的安全相關(guān)性足夠低，或被故障降級功能所覆蓋。
展開 自動駕駛預期功能安全要素及準入難點解讀
總結(jié)
本文主要講了與自動駕駛功能相關(guān)的惡預期功能安全策略，從基本的概念、目標、架構(gòu)、標準及測試范圍著手進行了全面的分析，旨在為下一節(jié)自動駕駛準入過程中的難點分析鋪墊。使讀者能夠在深入淺出的了解到預期功能安全的重難點，從而后續(xù)為自動駕駛的設(shè)計過程提供的必要的支撐，支撐產(chǎn)品順利通過準入。
技術(shù) | 用于自動駕駛的安全車載以太網(wǎng)——多級安全架構(gòu)
對汽車的攻擊點包括外部節(jié)點，如車載診斷接口 (OBD) 或無線連接（參見圖2），被黑客破解的現(xiàn)有節(jié)點，如安全防護等級低的信息娛樂控制設(shè)備，或者被交換和被操縱的控制設(shè)備。
圖2：汽車無線連接數(shù)量增加
三、動態(tài)威脅
汽車的壽命期相對較長，因此攻擊模式可能隨著時間發(fā)展而改變。根據(jù)摩爾定律，計算機處理能力約每2年翻倍一次。這一定律也適用于不斷擴大和日趨復雜化的攻擊。例如，8年前被視為安全的數(shù)據(jù)加密方法現(xiàn)在可能會受到攻擊，因為當時的密鑰長度對于現(xiàn)在來說太短了。
四、多級安全架構(gòu)
多級安全架構(gòu)可以有效對抗這些外部威脅，這個概念可避免黑客僅攻破一道安全屏障就能破解整個系統(tǒng)，從而造成巨大的破壞。
Elektrobit (EB) 開發(fā)的安全架構(gòu)包括4個等級，可以分層保護系統(tǒng)。第1級“加密網(wǎng)絡權(quán)限”，嚴格限制網(wǎng)絡訪問權(quán)，盡可能讓惡意攻擊者難以進入通信網(wǎng)絡。這一級已經(jīng)能夠提供非常有效的防護。如果第一級被攻破了，第2級“安全車載通信”可確保被交換的所有安全相關(guān)消息得到保護，防止被攻擊者篡改。如果這一級也被攻破，第3級“數(shù)據(jù)使用政策”會要求執(zhí)行特定的用戶驗證以進行保護。在進一步處理敏感消息內(nèi)容前，系統(tǒng)會在特定的用戶環(huán)境中執(zhí)行檢查。最后第4級是“檢測與防御”。這一級會檢查整個通信模式的異常情況。如果發(fā)現(xiàn)攻擊行為，防御機制會確保恢復被攻破的1-3級安防層。這種多級架構(gòu)可為針對系統(tǒng)可用性、完整性和保密性的攻擊提供全面的防護。
展開 
周界防范系統(tǒng)包含哪些子系統(tǒng)？系統(tǒng)架構(gòu)如何？系統(tǒng)如何設(shè)計？
周界防范系統(tǒng)的應用很廣泛，只要涉及到周界入侵防范的，都需要設(shè)置這個系統(tǒng)，有的設(shè)置電子圍欄，有的設(shè)置主動紅外報警，有的設(shè)置警戒攝像機等等，今天分享一套全面的周界防范系統(tǒng)設(shè)計方案，涉及到各個周界子系統(tǒng)，可以參考一下。
終將渡過成長的海
01
正文
第 一 章周界防范子系統(tǒng)
1.1系統(tǒng)概述
周界防范主要在園區(qū)周界，如圍墻、柵欄、樹林、邊界、河邊等場景中，通過各種技術(shù)手段一旦發(fā)現(xiàn)布防區(qū)域中的異常情況，系統(tǒng)能夠以最快和最佳的方式發(fā)出警報并提供有用信息，從而能夠更加有效的協(xié)助安保人員處理危機，最大限度的降低誤報和漏報現(xiàn)象，切實提高布放區(qū)域的安全防范能力，是園區(qū)安防系統(tǒng)的第一道防線。
1.2系統(tǒng)設(shè)計
1.2.1系統(tǒng)架構(gòu)
周界防范子系統(tǒng)由前端報警、傳輸網(wǎng)絡、管理中心組成。其中前端報警部分包括周界入侵探測器和防區(qū)脈沖主機以及報警主機。報警主機到管理中心的傳輸網(wǎng)絡可以是公共電話交換網(wǎng)（PSTN）、無線信道（CDMA/GSM）、Internet網(wǎng)絡等。管理中心則有管理計算機以及相應軟件組成。
整體架構(gòu)如下圖所示：
圖1.周界防范系統(tǒng)架構(gòu)圖
1.2.2業(yè)務流程
周界防范的業(yè)務流程分為：當有活動目標進入布防區(qū)域時，檢測設(shè)備開始檢測活動目標，產(chǎn)生周界防范報警事件，并將事件上報給后中心平臺；綜合安防管理平臺報警系統(tǒng)接收到事件后，可進行事件查看，并通過平臺的聯(lián)動模塊配置不同的聯(lián)動方式。
展開 MBSE體系架構(gòu)模型的理論研究：基于MBSE與SysML的空空導彈系統(tǒng)架構(gòu)建模研究
空空導彈系統(tǒng)是一個涉及機械、控制、電子、液壓和軟件等多種領(lǐng)域的復雜大系統(tǒng)[1,2]。傳統(tǒng)的空空導彈設(shè)計方法是一種文檔驅(qū)動式設(shè)計方法，主要包括系統(tǒng)方案設(shè)計、系統(tǒng)詳細設(shè)計、系統(tǒng)軟硬件聯(lián)調(diào)、系統(tǒng)驗證分析等多個步驟。隨著航空技術(shù)的發(fā)展，當前空空導彈設(shè)計方法轉(zhuǎn)變?yōu)榛谖臋n和數(shù)字化模型混合的設(shè)計方法，但其本質(zhì)上還是文檔驅(qū)動式的設(shè)計方法。該方法各階段的設(shè)計成果均為文字、圖表等文檔，導致在各階段之間傳遞的信息也是各種文檔，造成了設(shè)計方案表達不充分、信息表達的二義性、領(lǐng)域設(shè)計之間存在鴻溝、文檔的不可執(zhí)行性以及軟件測試工作量大等缺點。近年來，基于模型的系統(tǒng)工程（MBSE）技術(shù)越來越得到工業(yè)界的認可[3-5]，MBSE 是系統(tǒng)設(shè)計工作通過數(shù)字化設(shè)計手段的實現(xiàn)，因此在工作流程上與傳統(tǒng)系統(tǒng)工程并無太大差異，仍然分為需求分析、系統(tǒng)分析、系統(tǒng)設(shè)計三個步驟[6-8]。MBSE與傳統(tǒng)系統(tǒng)工程方法主要的區(qū)別是利用模型代替?zhèn)鹘y(tǒng)的文檔方式，模型具有的唯一性和可執(zhí)行性是其最大的特點。基于此，本文引入基于SysML的系統(tǒng)架構(gòu)建模方法[9,10]，在方案設(shè)計階段利用基于MBSE的設(shè)計方法對空空導彈系統(tǒng)架構(gòu)進行建模，并對不同系統(tǒng)架構(gòu)進行仿真分析，最終獲得最優(yōu)系統(tǒng)架構(gòu)，實現(xiàn)在方案論證階段減少甚至消除設(shè)計中的邏輯錯誤，避免到設(shè)計后期才發(fā)現(xiàn)由于邏輯錯誤而造成循環(huán)設(shè)計[11-13]。
1 MBSE理論概述
本文展開基于MBSE 的空空導彈系統(tǒng)架構(gòu)設(shè)計工作。從需求分析和用例出發(fā)，利用RHAPSODY 建模工具，基于MBSE 方法和SysML建模語言，對空空導彈系統(tǒng)架構(gòu)進行建模與仿真，主要包括基于SysML 的需求分析、系統(tǒng)分析和系統(tǒng)設(shè)計三個部分，最終實現(xiàn)在空空導彈系統(tǒng)方案設(shè)計階段對其架構(gòu)進行仿真，獲得最優(yōu)系統(tǒng)架構(gòu)。
展開 從功能安全視角看軟件架構(gòu)設(shè)計
EN50128 Table A.17 建模技術(shù)
在上表中，常用的建模方法有：
數(shù)據(jù)流圖——描述數(shù)據(jù)如何由輸入逐步流向輸出的過程；
控制流圖——描述由輸入經(jīng)過一系列控制動作到輸出的過程；
狀態(tài)機圖——描述系統(tǒng)不同狀態(tài)之間的轉(zhuǎn)換關(guān)系；
真值表——描述一個復雜的組合邏輯關(guān)系；
序列圖——描述不同組成部分通過信息交互的時序關(guān)系；
結(jié)構(gòu)圖——描述組件之間的層次關(guān)系。
序列圖示例
這些軟件建模方法屬于軟件通用的設(shè)計方法，在UML、SysML軟件建模語言中就有上述建模方法，屬于半形式化類方法。
注意這些建模方法在項目中使用，需要讓項目中與軟件架構(gòu)關(guān)聯(lián)的人理解一致，需要建立建模方法的使用指南，以規(guī)范其編寫要求。
以上作為軟件架構(gòu)的通用性要求，軟件缺陷為系統(tǒng)性失效，不存在失效概率的問題，因此，如果寫的代碼沒有bug，它百分之百是按照定義的需求去執(zhí)行。但是，有兩個問題是安全軟件需要考慮的，第一，軟件不可避免會存在bug；第二，軟件的實現(xiàn)與它所運行的硬件，與它所接口的外部系統(tǒng)相關(guān)聯(lián)，任何與它關(guān)聯(lián)的外部環(huán)境發(fā)生改變，都會對軟件的預期行為產(chǎn)生影響，因此，安全軟件不僅要考慮正常情況下的預期行為，也要考慮故障和干擾情況下的預期行為。
展開 從功能安全視角看軟件架構(gòu)設(shè)計
EN50128 Table A.17 建模技術(shù)
在上表中，常用的建模方法有：
數(shù)據(jù)流圖——描述數(shù)據(jù)如何由輸入逐步流向輸出的過程；
控制流圖——描述由輸入經(jīng)過一系列控制動作到輸出的過程；
狀態(tài)機圖——描述系統(tǒng)不同狀態(tài)之間的轉(zhuǎn)換關(guān)系；
真值表——描述一個復雜的組合邏輯關(guān)系；
序列圖——描述不同組成部分通過信息交互的時序關(guān)系；
結(jié)構(gòu)圖——描述組件之間的層次關(guān)系。
序列圖示例
這些軟件建模方法屬于軟件通用的設(shè)計方法，在UML、SysML軟件建模語言中就有上述建模方法，屬于半形式化類方法。
注意這些建模方法在項目中使用，需要讓項目中與軟件架構(gòu)關(guān)聯(lián)的人理解一致，需要建立建模方法的使用指南，以規(guī)范其編寫要求。
以上作為軟件架構(gòu)的通用性要求，軟件缺陷為系統(tǒng)性失效，不存在失效概率的問題，因此，如果寫的代碼沒有bug，它百分之百是按照定義的需求去執(zhí)行。但是，有兩個問題是安全軟件需要考慮的，第一，軟件不可避免會存在bug；第二，軟件的實現(xiàn)與它所運行的硬件，與它所接口的外部系統(tǒng)相關(guān)聯(lián)，任何與它關(guān)聯(lián)的外部環(huán)境發(fā)生改變，都會對軟件的預期行為產(chǎn)生影響，因此，安全軟件不僅要考慮正常情況下的預期行為，也要考慮故障和干擾情況下的預期行為。
展開 