面向機載軟件的預期功能安全分析驗證過程及方法研究

姜夢岑，溫曉玲，李海峰

（1.航空工業(yè)沈陽飛機設計研究所，遼寧沈陽 110035；2.北京航空航天大學，北京 100191）

機載軟件對系統(tǒng)任務完成與運行安全有著決定性的影響，其一旦發(fā)生失效，輕則導致任務失敗，重則導致飛行事故［1］。因此，機載軟件通常需要滿足較高的安全性要求［2-3］。國內外已經(jīng)制定了一系列標準［4-5］，來保障機載軟件安全性滿足指標要求。

對于具有復雜邏輯的機載軟件來說，其導致系統(tǒng)危險的原因，不僅僅是非法數(shù)據(jù)、通信中斷等單點失效，還可能是軟硬耦合沖突、人機交互異常、外部環(huán)境干擾、功能并發(fā)沖突等復雜行為。而傳統(tǒng)功能安全技術，例如，故障模式與影響分析（Fault Modes and Effect Analysis，F(xiàn)MEA）、故障樹分析（Fault Tree Analysis，F(xiàn)TA）等，傾向于將此類復雜行為排除在系統(tǒng)設計范圍之外，導致很多機載軟件雖然經(jīng)歷了較為充分的功能安全和測試工作，但運行時仍然會出現(xiàn)非預期的系統(tǒng)危險，難以滿足新一代復雜機載系統(tǒng)及其軟件的高安全、高可靠要求。

針對傳統(tǒng)功能安全技術應用于復雜系統(tǒng)時存在的不足，自動駕駛汽車領域提出了預期功能安全（Safety of the Intended Functionality，SOTIF）的概念［6-7］。依據(jù)ISO 26262 與ISO 21448，SOTIF定義如下：系統(tǒng)不存在由于危險而導致的不合理風險。其中，危險是由于系統(tǒng)預期功能不足（設計不足或性能局限）或合理可預見的人員誤操作引發(fā)的。

依據(jù)上述定義，相對于傳統(tǒng)功能安全，SOTIF重點關注系統(tǒng)在與外界環(huán)境、交聯(lián)設備、任務場景和操作人員交互時，由于自身功能設計存在遺漏或者缺陷而導致的軟件失效。SOTIF是功能安全在復雜系統(tǒng)上的擴展與完善，可以更加準確地追溯系統(tǒng)安全事故的復雜成因，有效保障系統(tǒng)和軟件在非預期交互、動態(tài)控制異常、工作狀態(tài)異常、多失效組合等復雜情況下的安全性水平，確保將系統(tǒng)和軟件的運行風險控制在可接受的范圍內。

近些年來，國內外高校、研究所、公司等針對SOTIF開展了大量的技術研究和典型應用［8-14］。已有研究表明，SOTIF理論將復雜系統(tǒng)安全性視為一個動態(tài)控制問題，具有分析過程動態(tài)化、非單點故障的危險溯源、多失效組合分析等優(yōu)勢，可有效識別復雜系統(tǒng)的安全隱患和約束條件，彌補傳統(tǒng)功能安全應用于復雜系統(tǒng)時存在的不足，已成為系統(tǒng)和軟件在安全性領域的重要研究方向與發(fā)展趨勢。但是，目前SOTIF 多以汽車駕駛系統(tǒng)為對象開展研究，在航空、航天等領域則極為少見。因此，本文將借鑒SOTIF 在汽車領域的成功應用經(jīng)驗，面向復雜機載軟件系統(tǒng)，開展機載軟件SOTIF分析驗證過程與方法研究，為SOTIF 在機載軟件領域的研究與應用提供支撐。

1 機載軟件SOTIF分析驗證框架

SOTIF與功能安全類似，均需通過完整且嚴格的分析驗證過程來保障系統(tǒng)安全能力，本質在于將大量技術活動歸納于若干步驟，轉化為執(zhí)行性高、可復現(xiàn)的操作指南，在最大程度上規(guī)避因人員能力或經(jīng)驗差異而導致的工作結果不一致的情況。因此，本文參考ISO 21448 標準，機載軟件SOTIF分析驗證過程需要貫徹“迭代”的概念［6］，實施框架如圖1 所示。

圖1 機載軟件SOTIF分析驗證過程

在圖1 中，標注綠色的部分為機載軟件SOTIF 分析驗證相關的關鍵技術活動，說明如下。

①相關項定義。

依據(jù)ISO 21448 開展SOTIF 工作，需要先確定分析驗證的對象［6］。因此，本文針對該項技術活動，將開展機載軟件SOTIF建模技術研究。

②危險分析與風險評估。

此項活動需要識別系統(tǒng)危險，并評估風險等級。在本文中，針對該項活動，開展基于功能危險分析（Functional Hazard Analysis，F(xiàn)HA）的機載軟件SOTIF危險分析研究和基于危險分析的風險評估研究。

本質上，F(xiàn)HA 技術來源于功能安全，但也可以應用于SOTIF。這是因為SOTIF是功能安全的擴展和補充，二者的目標是相同的，即消除系統(tǒng)危險，控制風險在合理可接受的范圍內。因此，本文將參考功能安全的工程經(jīng)驗，將FHA技術應用于SOTIF活動。

③識別功能不足與觸發(fā)條件。

此項活動需要分析導致危險的系統(tǒng)功能存在的不足，以及引發(fā)系統(tǒng)功能存在的不足的觸發(fā)條件（即原因），進而針對觸發(fā)條件制定安全性需求，以消除危險，降低系統(tǒng)運行風險。本文針對該項活動，開展基于系統(tǒng)理論的事故模型（Systems Theoretic Accident Modeling and Process，STAMP）的機載軟件SOTIF分析技術研究。

④針對已知危險及其原因的測試驗證。

ISO 21448 將系統(tǒng)運行場景分為4 個區(qū)域［6］，即已知安全場景（區(qū)域1）、已知不安全場景（區(qū)域2）、未知不安全場景（區(qū)域3）和未知安全場景（區(qū)域4），如圖2所示。

圖2 SOTIF系統(tǒng)運行場景

其中，區(qū)域2 和區(qū)域3 是SOTIF需要解決的問題，即充分識別系統(tǒng)運行過程中的各種危險及其原因（功能設計不足、性能局限或者人員誤操作等），驗證已知不安全場景和未知不安全場景是否得到有效識別與消除。因此，本文針對該項活動，將開展場景驅動的機載軟件SOTIF測試技術研究。

需要說明的是，圖1 中除了上述4 項活動，還有“回顧與復審”“運維階段活動”“功能提升和修改”等活動，限于篇幅，不作為本文討論的重點。

2 機載軟件SOTIF建模與危險分析技術

2.1 機載軟件SOTIF建模

有研究表明，在SOTIF 分析驗證過程中引入建模技術有利于工作效率的提升［14］。因此，本文參考SOTIF構建汽車自動駕駛系統(tǒng)測試場景的經(jīng)驗，從控制邏輯、外部設備、軟硬耦合、運行場景、數(shù)據(jù)交互等角度對機載軟件需求進行SOTIF建模。

（1）系統(tǒng)控制視圖建模。

首先，參考機載系統(tǒng)的典型控制任務，建立系統(tǒng)控制視圖模型，如圖3 所示。

圖3 系統(tǒng)控制視圖模型

該模型描述機載系統(tǒng)控制過程以及與外部設備（傳感器、執(zhí)行機構、操作人員等）之間的交互情況，為其他模型的構建提供輸入基礎。

（2）外部接口建模。

對軟件外部輸入輸出接口、數(shù)據(jù)及其關聯(lián)設備等信息進行規(guī)范描述，支撐從接口角度進行SOTIF 分析。需明確數(shù)據(jù)取值、時序關系、通信協(xié)議、源／目的設備、故障策略、余度關系等內容，具體建模要求如下。

①數(shù)據(jù)取值：包括取值范圍、取值精度、安全值／初始值設置等。

②時序關系：包括輸入輸出時刻、輸入輸出周期、輸入輸出持續(xù)時間等。

③通信協(xié)議：包括數(shù)據(jù)幀格式、數(shù)據(jù)幀長度、數(shù)據(jù)幀校驗方式等。

④源／目的設備：明確輸入數(shù)據(jù)來源設備的狀態(tài)或工作模式，以及輸出數(shù)據(jù)目的設備的狀態(tài)或工作模式。

⑤故障策略：包括故障診斷、故障處理、故障復位等故障策略。

⑥余度關系：包括多余度輸入數(shù)據(jù)表決、多余度輸出數(shù)據(jù)表決等。

（3）功能邏輯建模。

對軟件功能處理邏輯、控制過程等進行規(guī)范描述，支撐從功能角度進行SOTIF 分析。須明確控制過程、數(shù)據(jù)解算、處理邏輯、余度切換等內容。具體建模要求如下。

①控制過程：應明確軟件所控制的對象、輸出的控制指令、采用的控制律算法等內容。

②數(shù)據(jù)解算：應明確數(shù)據(jù)解算的輸出值范圍、數(shù)據(jù)解算公式、數(shù)據(jù)解算模型等內容。

③處理邏輯：應明確功能進入條件、功能執(zhí)行分支、功能操作過程等內容。

④余度切換：應明確主備通道的切換條件、切換時機、切換時長等內容。

（4）交互關系建模。

對軟件與硬件項、操作人員之間，軟件功能項之間等因素的交互關系進行規(guī)范描述，支撐從外部交互角度進行SOTIF 分析。須明確軟硬耦合、人員操作、告警顯示、功能交互等內容。具體建模要求如下。

①軟硬耦合：明確軟件項與硬件項之間的控制耦合關系、數(shù)據(jù)交互關系等內容。

②人員操作：明確人員操作軟件的操作方式、輸入方式等內容。

③告警顯示：明確告警顯示的方式、優(yōu)先級、顯示時序等內容。

④功能交互：明確功能之間的組合、調用等交互關系。

（5）運行場景建模。

對機載軟件運行中所經(jīng)歷的飛行階段、狀態(tài)模式、任務環(huán)境等信息進行規(guī)范描述，支撐從運行場景角度進行SOTIF分析。須明確典型運行場景、場景切換過程、場景切換條件等內容。具體建模要求如下。

①典型運行場景：應明確機載軟件運行過程中所處的工作模式、飛行階段、任務階段等內容。

②場景切換過程：應明確各個場景之間的切換過程、切換時序等內容。

③場景切換條件：應明確場景的進入條件、退出條件等內容。

2.2 系統(tǒng)功能危險分析

針對機載系統(tǒng)功能，識別不同工作狀態(tài)下的功能危險，并分析危險對于系統(tǒng)任務完成或運行安全的影響后果與等級。具體過程與技術方案如下。

（1）系統(tǒng)功能識別。

首先，依據(jù)系統(tǒng)需求，識別機載系統(tǒng)運行過程中可能經(jīng)歷的飛行階段及工作狀態(tài)。然后，依據(jù)GJB 438B／C等標準，從“外部輸入（Input）→處理過程（Process）→外部輸出（Output）”的黑盒角度，識別不同工作狀態(tài)或飛行階段下的系統(tǒng)功能，形成系統(tǒng)功能清單，為“功能危險識別”提供輸入。

（2）系統(tǒng)功能危險分析。

系統(tǒng)功能危險指的是功能輸出的各類異常。本文考慮針對機載系統(tǒng)功能的外部輸出數(shù)據(jù)，從數(shù)據(jù)失效、時序失效、通信失效、目的設備失效等角度，分析不同飛行階段或者工作狀態(tài)下，系統(tǒng)功能輸出的各種異常。例如“系統(tǒng)功能持續(xù)N 秒未輸出”“系統(tǒng)功能輸出超限”等。

（3）危險影響分析和等級評估。

從“運行安全”（對機載設備或機組人員的損傷）和“任務完成”（任務無法完成或者性能降低）這兩個角度分析機載系統(tǒng)危險的影響后果，例如，系統(tǒng)死機崩潰、任務執(zhí)行超時、設備損壞等。可建立系統(tǒng)外部交聯(lián)環(huán)境視圖、功能組成框圖等，輔助危險影響分析的開展，并評估影響后果的嚴重等級，包括A、B、C、D等級別。

2.3 基于危險分析的系統(tǒng)風險評估

系統(tǒng)風險評估包括危險事件分析、危險嚴重性等級評估、危險可能性等級評估、系統(tǒng)風險指標評估等幾項內容。其中，危險事件分析、危險嚴重性等級評估已經(jīng)在2.2 節(jié)中進行了說明，本節(jié)重點闡述后兩項內容的技術方案。

（1）危險可能性等級評估。

可依據(jù)危險所在功能的運行頻率或者導致危險的外部輸入頻率，以及系統(tǒng)所采取的軟件和硬件檢測手段，分析每項系統(tǒng)危險出現(xiàn)的可能性（即出現(xiàn)概率P），進而對危險可能性等級進行評估。依據(jù)GJB／Z 102A，可能性等級可分為5 級，即經(jīng)常（P ＞10-1）、很可能（10-2≤P≤10-1）、偶然（10-3≤P≤10-2）、很少（10-4≤P≤10-3）和極少（P≤10-4）。

（2）系統(tǒng)風險指標評估。

綜合每項系統(tǒng)危險事件的嚴重性等級和可能性等級，采用表1 的系統(tǒng)風險指標評估矩陣，對每項危險的系統(tǒng)風險指標進行評估。

表1 系統(tǒng)風險指標評估矩陣

3 基于STAMP的機載軟件SOTIF 分析技術

STAMP將事故理解為系統(tǒng)設計、開發(fā)和操作過程中的安全性相關約束沒有得到充分控制或充分施行［15］，這與STAMP模型的思想不謀而合。因此，本文將依據(jù)ISO 21448 等標準，參考STAMP模型及其應用技術系統(tǒng)理論過程分析（Systems-Theoretic Process Analysis，STPA），在SOTIF 安全模型基礎上，開展機載軟件SOTIF分析技術研究。主要過程如圖4 所示。

圖4 基于STAMP的機載軟件SOTIF分析

3.1 復雜場景下的機載軟件SOTIF影響因素

參考SOTIF構建汽車自動駕駛系統(tǒng)測試場景的經(jīng)驗，針對機載軟件系統(tǒng)控制視圖模型中的運行環(huán)境、任務階段、控制邏輯、軟硬耦合、外部激勵等場景進行分析，識別安全影響因素，為異常控制行為及其原因分析提供依據(jù)。主要包括以下內容。

①軟硬件耦合沖突：由于外部執(zhí)行機構行為或屬性出現(xiàn)異常，導致軟件任務失敗或運行異常。例如，執(zhí)行機構運動速度過快或過慢，執(zhí)行機構的運動位置超出物理極限位置等。

②動態(tài)控制異常：軟件控制過程或者控制律算法出現(xiàn)各種異常，導致軟件任務失敗或者運行異常。例如，執(zhí)行機構行為與控制指令連續(xù)多個周期不相符、控制過程提前結束或者滯后結束等。

③工作狀態(tài)異常：由于軟件所處的工作狀態(tài)出現(xiàn)異常，導致軟件任務失敗或者運行異常。例如，工作狀態(tài)切換后，功能異常終止等。

④功能并發(fā)沖突：軟件多個功能或組件并發(fā)時出現(xiàn)沖突，導致軟件任務失敗或運行異常。例如，多個功能同時對同一數(shù)據(jù)進行賦值，產(chǎn)生沖突等。

⑤運行環(huán)境影響：與軟件處于同一環(huán)境的硬件項或軟件項出現(xiàn)異常，導致任務失敗或運行異常。例如，外存故障或存滿，操作系統(tǒng)不兼容等。

⑥人員誤操作：操作人員的非法操作、快速操作、誤操作等異常。例如，執(zhí)行關鍵控制時未充分確認，重復施加控制指令等。

3.2 基于故障樹的軟件異?？刂菩袨樽R別

本文依據(jù)機載系統(tǒng)體系結構與可靠性框圖，構建故障樹，自上而下地識別導致系統(tǒng)危險的軟件原因事件，即異?？刂菩袨?，形成系統(tǒng)向軟件分配的SOTIF需求，反饋至系統(tǒng)設計架構中。包括如下內容。

（1）系統(tǒng)體系結構分析。

自上而下確定系統(tǒng)由哪些子系統(tǒng)、設備、軟件項或硬件項組成，并確定這些組成項之間的層級關系，以及這些組成項之間的動態(tài)數(shù)據(jù)交互關系，從而為故障樹模型構建提供依據(jù)。

（2）基于系統(tǒng)體系結構的故障樹建模。

首先，針對系統(tǒng)功能危險分析結果，選取“影響等級”為“A級”的功能危險，作為故障樹頂事件。然后，基于系統(tǒng)體系結構自上而下逐層展開，分析組成項可能存在的異常失效，構建故障樹的中間事件和底事件。同時，依據(jù)組成項之間的動態(tài)運行關系，構建相應的“邏輯門”。例如，組成項之間為串聯(lián)關系，對應“或門”；組成項之間為并聯(lián)關系，對應“與門”。

（3）基于故障樹的軟件異常控制行為識別。

基于故障樹模型，識別底事件中由軟件導致系統(tǒng)危險的原因，即軟件異常控制行為。主要包括以下部分。

①控制行為不完整安全：例如，沒有提供必須的控制行為，沒有提供充分的控制行為，以及控制行為可能會導致人員傷亡、設備損壞或環(huán)境破壞。

②控制行為時序不符合約束要求：例如，執(zhí)行時間過晚或過早、控制行為持續(xù)時間過長或過短、控制行為無法結束或者異常中斷等。

③執(zhí)行機構未正確響應：例如，執(zhí)行機構未響應或未正確響應控制信號，執(zhí)行機構過早或者過晚響應控制信號等。

④執(zhí)行機構運行異常：例如，執(zhí)行機構運動速度過快或過慢，執(zhí)行機構位置超出物理限位等。

（4）系統(tǒng)向軟件分配的SOTIF要求。

針對故障樹中與軟件相關的底事件和軟件異常控制行為，從事前預防或事后控制的角度，形成系統(tǒng)向軟件分配的SOTIF要求，主要包括以下部分。

①針對數(shù)據(jù)失效的SOTIF要求：針對輸出接口數(shù)據(jù)的取值、組合、變化等異常情況，進行檢查，提出處理措施，確保輸出取值有效的數(shù)據(jù)信息。

②針對時序失效的SOTIF 要求：針對輸出周期、時刻、持續(xù)時長等異常情況，進行檢查，提出處理措施，確保輸出時序有效的數(shù)據(jù)信息。

③針對通信失效的SOTIF要求：針對輸出接口的格式、內容等異常情況，進行檢查，提出處理措施，確保軟件能夠輸出通信協(xié)議有效的數(shù)據(jù)信息。

④針對余度失效的SOTIF要求：針對軟件余度表決關系，進行容錯檢查，分析余度輸出不一致、余度輸出無效等異常情況，提出相應處理措施。

⑤針對交聯(lián)設備失效的SOTIF要求：對外部交聯(lián)設備進行檢查，分析設備未響應指令或者處于故障狀態(tài)等異常情況，提出相應處理措施，確保軟件正確實現(xiàn)與交聯(lián)設備的數(shù)據(jù)或控制交互。

3.3 基于影響因素的異?？刂菩袨樵蚍治?/h3>

最后，依據(jù)SOTIF 影響因素，識別導致異?？刂菩袨榈母鞣N可能原因。例如，接口數(shù)據(jù)異常、軟硬耦合沖突、設備狀態(tài)異常、外部非法干擾、人機交互異常、狀態(tài)場景異常、功能邏輯異常、功能組合異常等。具體如下。

①接口數(shù)據(jù)異常：針對軟件外部接口的數(shù)據(jù)取值、時序約束、通信協(xié)議等進行異?？刂菩袨樵蚍治?，例如數(shù)據(jù)取值異常、通信中斷、關聯(lián)設備故障、余度設計異常等。

②功能邏輯異常：針對軟件控制過程、數(shù)據(jù)解算、處理邏輯等進行異常控制行為原因分析，例如功能執(zhí)行超時、邏輯分支無法成立等。

③功能組合異常：針對軟件功能之間的并發(fā)、串行、調用等組合關系，進行異?？刂菩袨樵蚍治?，例如功能并發(fā)沖突、順序執(zhí)行異常等。

④狀態(tài)場景異常：針對軟件工作狀態(tài)和飛行階段，進行異?？刂菩袨樵蚍治觯鐮顟B(tài)無法退出、狀態(tài)轉移導致功能中斷等。

⑤軟硬耦合沖突：針對軟件項與硬件項之間的控制或者數(shù)據(jù)交互關系進行異常控制行為原因分析，例如硬件未響應軟件的控制指令、硬件錯誤響應軟件的控制指令等。

⑥人機交互異常：針對人員操作行為進行異常控制行為原因分析，例如重復操作、誤操作等。

⑦設備狀態(tài)異常：針對交聯(lián)設備的狀態(tài)進行異?？刂菩袨樵蚍治?，例如設備處于上電、下電、故障等異常狀態(tài)。

⑧外部非法干擾：針對軟件所處的運行環(huán)境和外部信號等進行異?？刂菩袨樵蚍治?，例如強電磁干擾信號等。

4 場景驅動的機載軟件SOTIF測試技術

在SOTIF模型與軟件異常控制行為原因分析基礎上，構建基于SOTIF 的測試用例及典型測試場景，實現(xiàn)對軟件各類異?？刂菩袨楹蛷碗s運行場景的有效覆蓋。

4.1 機載軟件SOTIF測試場景構建

基于軟件異常控制行為及其原因分析結果，參考汽車自動駕駛系統(tǒng)測試場景構建方法，構建機載軟件SOTIF測試場景，實現(xiàn)對軟硬耦合、控制過程、外部激勵、人機交互、狀態(tài)切換等復雜場景的有效模擬或仿真。

“場景”通常用于描述導致結果的一系列動作和事件。在ISO 26262 標準中，將場景分為功能場景、邏輯場景和具體場景3 類［7］。在本文中，機載軟件的場景（測試場景或者運行場景）主要指的是，軟件與其任務階段、運行環(huán)境等組成要素在一段時間內的總體動態(tài)描述，這些要素組成由所期望完成的系統(tǒng)任務與具體功能決定。

基于上述定義，本文將識別的軟件異?？刂菩袨榧捌湓?，轉化為機載軟件與其任務階段、運行環(huán)境等要素表征的一系列動作與事件，形成軟件SOTIF 測試場景構建要求。主要包括以下部分。

①基于接口數(shù)據(jù)異常的SOTIF測試場景：針對外部接口數(shù)據(jù)的各類異常，通過異常激勵數(shù)據(jù)施加構建測試場景。例如，設置輸入數(shù)據(jù)取值大于值域上限、取值一段時間內保持不變等。

②基于控制過程異常的SOTIF測試場景：針對軟件控制過程中的各類異常，通過異常激勵數(shù)據(jù)施加或環(huán)境仿真構建測試場景。例如，設置控制律長時間未輸出數(shù)據(jù)、輸出取值大于值域上限等。

③基于交聯(lián)設備異常的SOTIF 測試場景：針對源／目的等交聯(lián)設備的異常，通過設備模擬或仿真等方式構建測試場景。例如，設置傳感器下電故障、數(shù)據(jù)庫容量已存滿、執(zhí)行機構卡滯等。

④基于余度表決異常的SOTIF測試場景：針對余度表決異常，通過余度模擬或者仿真等方式構建測試場景。例如，設置余度來源設備處于下電狀態(tài)、余度間的數(shù)據(jù)取值之差大于規(guī)定閾值等。

⑤基于狀態(tài)切換異常的SOTIF測試場景：針對軟件工作狀態(tài)之間的切換異常，通過異常激勵數(shù)據(jù)施加或仿真等方式構建測試場景。例如，設置狀態(tài)切換超時、同時進入兩個工作狀態(tài)等。

4.2 場景驅動的軟件SOTIF測試用例設計

在所構建的SOTIF測試場景基礎上，建立異常控制行為原因、SOTIF要求與用例輸入，以及預期輸出之間的關聯(lián)關系，設計SOTIF測試用例。

①確定用例輸入數(shù)據(jù)：依據(jù)異?？刂菩袨樵颍鞔_相應接口數(shù)據(jù)的取值規(guī)則，以選取確定數(shù)值或者等價類數(shù)值作為SOTIF測試用例輸入數(shù)據(jù)。

②確定用例約束條件：依據(jù)異常控制行為原因，選取相應功能執(zhí)行邏輯、運行場景或外部環(huán)境等，作為SOTIF測試用例執(zhí)行的約束條件。

③確定用例預期輸出與通過準則：依據(jù)機載軟件SOTIF要求和異?？刂菩袨椋鞔_相應輸出數(shù)據(jù)的取值規(guī)則以確定測試用例的預期輸出，即軟件異常控制行為不發(fā)生或者得到有效控制。一般來說，用例執(zhí)行通過準則應與預期輸出完全一致。但若危險等級較低，則通過準則也可適當放寬。

④確定SOTIF測試用例格式：依據(jù)外部接口控制文件（ICD），確定輸入接口數(shù)據(jù)的通信格式。進而依據(jù)接口通信格式和相應的數(shù)據(jù)取值內容，拼裝成可執(zhí)行的軟件SOTIF測試用例。

5 典型應用

本文針對機輪轉彎控制軟件，開展SOTIF 分析應用，驗證本文研究成果的可行性與有效性。

（1）機載軟件SOTIF建模。

首先，依據(jù)軟件需求，建立機載軟件的系統(tǒng)控制視圖模型，如圖5 所示。

圖5 系統(tǒng)控制視圖模型實例

依據(jù)上述系統(tǒng)控制結構模型，對轉彎控制軟件的相關需求描述如下。

①控制器：機輪轉彎控制系統(tǒng)。

②執(zhí)行機構：機輪裝置。

③源設備：機輪角度傳感器。

④控制過程中的外部輸入輸出數(shù)據(jù)（包含控制反饋信號），外部輸入輸出數(shù)據(jù)列表如表2 所示。

表2 外部輸入輸出數(shù)據(jù)列表

⑤控制過程：軟件依據(jù)上位機傳輸?shù)妮斎霐?shù)據(jù)“目標角度”（由人員設置）和機輪裝置反饋的輸入數(shù)據(jù)“機輪角度”（來自于傳感器）進行實時閉環(huán)控制解算，輸出“轉彎控制指令”至機輪裝置，驅動機輪裝置運動到“目標角度”。同時，輸出“顯示角度”至上位機顯示。

（2）機載軟件系統(tǒng)危險分析。

依據(jù)系統(tǒng)控制視圖模型，機載軟件系統(tǒng)的功能危險分析如下。

①H-1：機輪轉彎速度過快，導致飛機側翻。

②H-2：機輪到達指定角度位置的時間過久，導致飛機沖出跑道

針對識別的系統(tǒng)危險，參考STAMP 模型理論，確定相關的安全約束條件如下。

①SC-1：軟件必須控制機輪轉彎速度小于2°／s（對應危險H-1）。

②SC-2：軟件必須在規(guī)定的時間內（50 s），控制機輪轉動到規(guī)定位置（對應危險H-2）。

依據(jù)上述系統(tǒng)控制視圖模型，對安全約束條件進一步細化如下。

①SC-11：軟件必須控制機輪轉彎速度小于2°／s（對應危險H-1），即機輪裝置反饋的“機輪角度”取值變化率應小于2°／s。

②SC-22：軟件必須在規(guī)定的時間內（50 s），控制機輪轉動到規(guī)定位置（對應危險H-2），即機輪裝置反饋的“機輪角度”取值應與“目標角度”相一致。

（3）異常控制行為識別。

依據(jù)3.2 節(jié)中列舉的基于故障樹的異?？刂菩袨樽R別方法，對兩個安全約束條件進行分析，識別導致危險的可能異?？刂菩袨槿缦?。

①針對安全約束條件SC-1（軟件必須控制機輪轉彎速度小于2°／s），識別的異?？刂菩袨槿绫? 所示。

表3 SC-1 的異?？刂菩袨樽R別

②針對安全約束條件SC-2（軟件必須在規(guī)定的50 s時間內，控制機輪轉動到規(guī)定位置），識別的異?？刂菩袨閁CA如表4 所示。

表4 SC-2 的異?？刂菩袨樽R別

（4）異?？刂菩袨樵蚍治?。

依據(jù)3.3 節(jié)中的基于影響因素的異常控制行為原因分析方法，對上述異常控制行為的原因分析如下。

①針對異?？刂菩袨閁CA.1.1，識別原因如表5所示。

表5 UCA.1.1 的原因分析

②針對異?？刂菩袨閁CA.1.2，識別原因如表6所示。

表6 UCA.1.2 的原因分析

③針對異?？刂菩袨閁CA.2.1，識別原因如表7所示。

表7 UCA.2.1 的原因分析

④針對異常控制行為UCA.2.2，識別原因如表8所示。

表8 UCA.2.2 的原因分析

6 結束語

本文參考ISO 21448 標準中的SOTIF實施框架和汽車領域工程經(jīng)驗，借助功能危險分析、故障樹模型、STAMP模型、場景驅動等理論方法，針對機載軟件運行特征構建SOTIF分析驗證工作的實施過程，包括機載軟件SOTIF 建模、系統(tǒng)功能危險分析、基于危險分析的系統(tǒng)風險評估、復雜場景下的機載軟件SOTIF 影響因素識別、基于故障樹的軟件異?？刂菩袨樽R別、基于影響因素的異?？刂菩袨樵蚍治觥C載軟件SOTIF測試場景構建、場景驅動的機載軟件SOTIF 測試用例設計等內容。

上述研究成果及其初步工程應用結果表明，面向機載軟件的SOTIF分析驗證過程及方法可以推進SOTIF技術在機載軟件研制過程中的推廣與應用，形成符合標準要求、適用于復雜系統(tǒng)的機載軟件SOTIF 分析驗證能力，避免FMEA、FTA等安全性分析技術多關注非法數(shù)據(jù)、通信中斷等單點失效的不足，支撐研制人員充分識別機載軟件運行過程中的軟硬耦合沖突、人機交互異常、場景切換異常等復雜失效模式。同時，支持測試人員面向構建機載軟件的SOTIF 測試場景，實現(xiàn)對軟硬耦合、控制過程、外部激勵、人機交互、狀態(tài)切換等復雜場景的有效模擬或仿真，提升軟件測試效率和質量，最終確保機載軟件能夠滿足高安全、高可靠的研制要求。

需要說明的是，本文主要目標是建立SOTIF 在機載軟件研制中的完整實施過程，為后續(xù)的相關技術研究與工程應用提供參考。但限于篇幅，本文重點給出可能的技術方案和初步的工程示例，還需在未來工作中進行更加深入的技術研究與工程應用。