姜夢岑,溫曉玲,李海峰
(1.航空工業沈陽飛機設計研究所,遼寧沈陽 110035;2.北京航空航天大學,北京 100191)
機載軟件對系統任務完成與運行安全有著決定性的影響,其一旦發生失效,輕則導致任務失敗,重則導致飛行事故[1]。因此,機載軟件通常需要滿足較高的安全性要求[2-3]。國內外已經制定了一系列標準[4-5],來保障機載軟件安全性滿足指標要求。
對于具有復雜邏輯的機載軟件來說,其導致系統危險的原因,不僅僅是非法數據、通信中斷等單點失效,還可能是軟硬耦合沖突、人機交互異常、外部環境干擾、功能并發沖突等復雜行為。而傳統功能安全技術,例如,故障模式與影響分析(Fault Modes and Effect Analysis,FMEA)、故障樹分析(Fault Tree Analysis,FTA)等,傾向于將此類復雜行為排除在系統設計范圍之外,導致很多機載軟件雖然經歷了較為充分的功能安全和測試工作,但運行時仍然會出現非預期的系統危險,難以滿足新一代復雜機載系統及其軟件的高安全、高可靠要求。
針對傳統功能安全技術應用于復雜系統時存在的不足,自動駕駛汽車領域提出了預期功能安全(Safety of the Intended Functionality,SOTIF)的概念[6-7]。依據ISO 26262 與ISO 21448,SOTIF定義如下:系統不存在由于危險而導致的不合理風險。其中,危險是由于系統預期功能不足(設計不足或性能局限)或合理可預見的人員誤操作引發的。
依據上述定義,相對于傳統功能安全,SOTIF重點關注系統在與外界環境、交聯設備、任務場景和操作人員交互時,由于自身功能設計存在遺漏或者缺陷而導致的軟件失效。SOTIF是功能安全在復雜系統上的擴展與完善,可以更加準確地追溯系統安全事故的復雜成因,有效保障系統和軟件在非預期交互、動態控制異常、工作狀態異常、多失效組合等復雜情況下的安全性水平,確保將系統和軟件的運行風險控制在可接受的范圍內。
近些年來,國內外高校、研究所、公司等針對SOTIF開展了大量的技術研究和典型應用[8-14]。已有研究表明,SOTIF理論將復雜系統安全性視為一個動態控制問題,具有分析過程動態化、非單點故障的危險溯源、多失效組合分析等優勢,可有效識別復雜系統的安全隱患和約束條件,彌補傳統功能安全應用于復雜系統時存在的不足,已成為系統和軟件在安全性領域的重要研究方向與發展趨勢。但是,目前SOTIF 多以汽車駕駛系統為對象開展研究,在航空、航天等領域則極為少見。因此,本文將借鑒SOTIF 在汽車領域的成功應用經驗,面向復雜機載軟件系統,開展機載軟件SOTIF分析驗證過程與方法研究,為SOTIF 在機載軟件領域的研究與應用提供支撐。
SOTIF與功能安全類似,均需通過完整且嚴格的分析驗證過程來保障系統安全能力,本質在于將大量技術活動歸納于若干步驟,轉化為執行性高、可復現的操作指南,在最大程度上規避因人員能力或經驗差異而導致的工作結果不一致的情況。因此,本文參考ISO 21448 標準,機載軟件SOTIF分析驗證過程需要貫徹“迭代”的概念[6],實施框架如圖1 所示。

圖1 機載軟件SOTIF分析驗證過程
在圖1 中,標注綠色的部分為機載軟件SOTIF 分析驗證相關的關鍵技術活動,說明如下。
①相關項定義。
依據ISO 21448 開展SOTIF 工作,需要先確定分析驗證的對象[6]。因此,本文針對該項技術活動,將開展機載軟件SOTIF建模技術研究。
②危險分析與風險評估。
此項活動需要識別系統危險,并評估風險等級。在本文中,針對該項活動,開展基于功能危險分析(Functional Hazard Analysis,FHA)的機載軟件SOTIF危險分析研究和基于危險分析的風險評估研究。
本質上,FHA 技術來源于功能安全,但也可以應用于SOTIF。這是因為SOTIF是功能安全的擴展和補充,二者的目標是相同的,即消除系統危險,控制風險在合理可接受的范圍內。因此,本文將參考功能安全的工程經驗,將FHA技術應用于SOTIF活動。
③識別功能不足與觸發條件。
此項活動需要分析導致危險的系統功能存在的不足,以及引發系統功能存在的不足的觸發條件(即原因),進而針對觸發條件制定安全性需求,以消除危險,降低系統運行風險。本文針對該項活動,開展基于系統理論的事故模型(Systems Theoretic Accident Modeling and Process,STAMP)的機載軟件SOTIF分析技術研究。
④針對已知危險及其原因的測試驗證。
ISO 21448 將系統運行場景分為4 個區域[6],即已知安全場景(區域1)、已知不安全場景(區域2)、未知不安全場景(區域3)和未知安全場景(區域4),如圖2所示。

圖2 SOTIF系統運行場景
其中,區域2 和區域3 是SOTIF需要解決的問題,即充分識別系統運行過程中的各種危險及其原因(功能設計不足、性能局限或者人員誤操作等),驗證已知不安全場景和未知不安全場景是否得到有效識別與消除。因此,本文針對該項活動,將開展場景驅動的機載軟件SOTIF測試技術研究。
需要說明的是,圖1 中除了上述4 項活動,還有“回顧與復審”“運維階段活動”“功能提升和修改”等活動,限于篇幅,不作為本文討論的重點。
有研究表明,在SOTIF 分析驗證過程中引入建模技術有利于工作效率的提升[14]。因此,本文參考SOTIF構建汽車自動駕駛系統測試場景的經驗,從控制邏輯、外部設備、軟硬耦合、運行場景、數據交互等角度對機載軟件需求進行SOTIF建模。
(1)系統控制視圖建模。
首先,參考機載系統的典型控制任務,建立系統控制視圖模型,如圖3 所示。

圖3 系統控制視圖模型
該模型描述機載系統控制過程以及與外部設備(傳感器、執行機構、操作人員等)之間的交互情況,為其他模型的構建提供輸入基礎。
(2)外部接口建模。
對軟件外部輸入輸出接口、數據及其關聯設備等信息進行規范描述,支撐從接口角度進行SOTIF 分析。需明確數據取值、時序關系、通信協議、源/目的設備、故障策略、余度關系等內容,具體建模要求如下。
①數據取值:包括取值范圍、取值精度、安全值/初始值設置等。
②時序關系:包括輸入輸出時刻、輸入輸出周期、輸入輸出持續時間等。
③通信協議:包括數據幀格式、數據幀長度、數據幀校驗方式等。
④源/目的設備:明確輸入數據來源設備的狀態或工作模式,以及輸出數據目的設備的狀態或工作模式。
⑤故障策略:包括故障診斷、故障處理、故障復位等故障策略。
⑥余度關系:包括多余度輸入數據表決、多余度輸出數據表決等。
(3)功能邏輯建模。
對軟件功能處理邏輯、控制過程等進行規范描述,支撐從功能角度進行SOTIF 分析。須明確控制過程、數據解算、處理邏輯、余度切換等內容。具體建模要求如下。
①控制過程:應明確軟件所控制的對象、輸出的控制指令、采用的控制律算法等內容。
②數據解算:應明確數據解算的輸出值范圍、數據解算公式、數據解算模型等內容。
③處理邏輯:應明確功能進入條件、功能執行分支、功能操作過程等內容。
④余度切換:應明確主備通道的切換條件、切換時機、切換時長等內容。
(4)交互關系建模。
對軟件與硬件項、操作人員之間,軟件功能項之間等因素的交互關系進行規范描述,支撐從外部交互角度進行SOTIF 分析。須明確軟硬耦合、人員操作、告警顯示、功能交互等內容。具體建模要求如下。
①軟硬耦合:明確軟件項與硬件項之間的控制耦合關系、數據交互關系等內容。
②人員操作:明確人員操作軟件的操作方式、輸入方式等內容。
③告警顯示:明確告警顯示的方式、優先級、顯示時序等內容。
④功能交互:明確功能之間的組合、調用等交互關系。
(5)運行場景建模。
對機載軟件運行中所經歷的飛行階段、狀態模式、任務環境等信息進行規范描述,支撐從運行場景角度進行SOTIF分析。須明確典型運行場景、場景切換過程、場景切換條件等內容。具體建模要求如下。
①典型運行場景:應明確機載軟件運行過程中所處的工作模式、飛行階段、任務階段等內容。
②場景切換過程:應明確各個場景之間的切換過程、切換時序等內容。
③場景切換條件:應明確場景的進入條件、退出條件等內容。
針對機載系統功能,識別不同工作狀態下的功能危險,并分析危險對于系統任務完成或運行安全的影響后果與等級。具體過程與技術方案如下。
(1)系統功能識別。
首先,依據系統需求,識別機載系統運行過程中可能經歷的飛行階段及工作狀態。然后,依據GJB 438B/C等標準,從“外部輸入(Input)→處理過程(Process)→外部輸出(Output)”的黑盒角度,識別不同工作狀態或飛行階段下的系統功能,形成系統功能清單,為“功能危險識別”提供輸入。
(2)系統功能危險分析。
系統功能危險指的是功能輸出的各類異常。本文考慮針對機載系統功能的外部輸出數據,從數據失效、時序失效、通信失效、目的設備失效等角度,分析不同飛行階段或者工作狀態下,系統功能輸出的各種異常。例如“系統功能持續N 秒未輸出”“系統功能輸出超限”等。
(3)危險影響分析和等級評估。
從“運行安全”(對機載設備或機組人員的損傷)和“任務完成”(任務無法完成或者性能降低)這兩個角度分析機載系統危險的影響后果,例如,系統死機崩潰、任務執行超時、設備損壞等。可建立系統外部交聯環境視圖、功能組成框圖等,輔助危險影響分析的開展,并評估影響后果的嚴重等級,包括A、B、C、D等級別。
系統風險評估包括危險事件分析、危險嚴重性等級評估、危險可能性等級評估、系統風險指標評估等幾項內容。其中,危險事件分析、危險嚴重性等級評估已經在2.2 節中進行了說明,本節重點闡述后兩項內容的技術方案。
(1)危險可能性等級評估。
可依據危險所在功能的運行頻率或者導致危險的外部輸入頻率,以及系統所采取的軟件和硬件檢測手段,分析每項系統危險出現的可能性(即出現概率P),進而對危險可能性等級進行評估。依據GJB/Z 102A,可能性等級可分為5 級,即經常(P >10-1)、很可能(10-2≤P≤10-1)、偶然(10-3≤P≤10-2)、很少(10-4≤P≤10-3)和極少(P≤10-4)。
(2)系統風險指標評估。
綜合每項系統危險事件的嚴重性等級和可能性等級,采用表1 的系統風險指標評估矩陣,對每項危險的系統風險指標進行評估。

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

圖4 基于STAMP的機載軟件SOTIF分析
參考SOTIF構建汽車自動駕駛系統測試場景的經驗,針對機載軟件系統控制視圖模型中的運行環境、任務階段、控制邏輯、軟硬耦合、外部激勵等場景進行分析,識別安全影響因素,為異常控制行為及其原因分析提供依據。主要包括以下內容。
①軟硬件耦合沖突:由于外部執行機構行為或屬性出現異常,導致軟件任務失敗或運行異常。例如,執行機構運動速度過快或過慢,執行機構的運動位置超出物理極限位置等。
②動態控制異常:軟件控制過程或者控制律算法出現各種異常,導致軟件任務失敗或者運行異常。例如,執行機構行為與控制指令連續多個周期不相符、控制過程提前結束或者滯后結束等。
③工作狀態異常:由于軟件所處的工作狀態出現異常,導致軟件任務失敗或者運行異常。例如,工作狀態切換后,功能異常終止等。
④功能并發沖突:軟件多個功能或組件并發時出現沖突,導致軟件任務失敗或運行異常。例如,多個功能同時對同一數據進行賦值,產生沖突等。
⑤運行環境影響:與軟件處于同一環境的硬件項或軟件項出現異常,導致任務失敗或運行異常。例如,外存故障或存滿,操作系統不兼容等。
⑥人員誤操作:操作人員的非法操作、快速操作、誤操作等異常。例如,執行關鍵控制時未充分確認,重復施加控制指令等。
本文依據機載系統體系結構與可靠性框圖,構建故障樹,自上而下地識別導致系統危險的軟件原因事件,即異常控制行為,形成系統向軟件分配的SOTIF需求,反饋至系統設計架構中。包括如下內容。
(1)系統體系結構分析。
自上而下確定系統由哪些子系統、設備、軟件項或硬件項組成,并確定這些組成項之間的層級關系,以及這些組成項之間的動態數據交互關系,從而為故障樹模型構建提供依據。
(2)基于系統體系結構的故障樹建模。
首先,針對系統功能危險分析結果,選取“影響等級”為“A級”的功能危險,作為故障樹頂事件。然后,基于系統體系結構自上而下逐層展開,分析組成項可能存在的異常失效,構建故障樹的中間事件和底事件。同時,依據組成項之間的動態運行關系,構建相應的“邏輯門”。例如,組成項之間為串聯關系,對應“或門”;組成項之間為并聯關系,對應“與門”。
(3)基于故障樹的軟件異常控制行為識別。
基于故障樹模型,識別底事件中由軟件導致系統危險的原因,即軟件異常控制行為。主要包括以下部分。
①控制行為不完整安全:例如,沒有提供必須的控制行為,沒有提供充分的控制行為,以及控制行為可能會導致人員傷亡、設備損壞或環境破壞。
②控制行為時序不符合約束要求:例如,執行時間過晚或過早、控制行為持續時間過長或過短、控制行為無法結束或者異常中斷等。
③執行機構未正確響應:例如,執行機構未響應或未正確響應控制信號,執行機構過早或者過晚響應控制信號等。
④執行機構運行異常:例如,執行機構運動速度過快或過慢,執行機構位置超出物理限位等。
(4)系統向軟件分配的SOTIF要求。
針對故障樹中與軟件相關的底事件和軟件異常控制行為,從事前預防或事后控制的角度,形成系統向軟件分配的SOTIF要求,主要包括以下部分。
①針對數據失效的SOTIF要求:針對輸出接口數據的取值、組合、變化等異常情況,進行檢查,提出處理措施,確保輸出取值有效的數據信息。
②針對時序失效的SOTIF 要求:針對輸出周期、時刻、持續時長等異常情況,進行檢查,提出處理措施,確保輸出時序有效的數據信息。
③針對通信失效的SOTIF要求:針對輸出接口的格式、內容等異常情況,進行檢查,提出處理措施,確保軟件能夠輸出通信協議有效的數據信息。
④針對余度失效的SOTIF要求:針對軟件余度表決關系,進行容錯檢查,分析余度輸出不一致、余度輸出無效等異常情況,提出相應處理措施。
⑤針對交聯設備失效的SOTIF要求:對外部交聯設備進行檢查,分析設備未響應指令或者處于故障狀態等異常情況,提出相應處理措施,確保軟件正確實現與交聯設備的數據或控制交互。
最后,依據SOTIF 影響因素,識別導致異常控制行為的各種可能原因。例如,接口數據異常、軟硬耦合沖突、設備狀態異常、外部非法干擾、人機交互異常、狀態場景異常、功能邏輯異常、功能組合異常等。具體如下。
①接口數據異常:針對軟件外部接口的數據取值、時序約束、通信協議等進行異常控制行為原因分析,例如數據取值異常、通信中斷、關聯設備故障、余度設計異常等。
②功能邏輯異常:針對軟件控制過程、數據解算、處理邏輯等進行異常控制行為原因分析,例如功能執行超時、邏輯分支無法成立等。
③功能組合異常:針對軟件功能之間的并發、串行、調用等組合關系,進行異常控制行為原因分析,例如功能并發沖突、順序執行異常等。
④狀態場景異常:針對軟件工作狀態和飛行階段,進行異常控制行為原因分析,例如狀態無法退出、狀態轉移導致功能中斷等。
⑤軟硬耦合沖突:針對軟件項與硬件項之間的控制或者數據交互關系進行異常控制行為原因分析,例如硬件未響應軟件的控制指令、硬件錯誤響應軟件的控制指令等。
⑥人機交互異常:針對人員操作行為進行異常控制行為原因分析,例如重復操作、誤操作等。
⑦設備狀態異常:針對交聯設備的狀態進行異常控制行為原因分析,例如設備處于上電、下電、故障等異常狀態。
⑧外部非法干擾:針對軟件所處的運行環境和外部信號等進行異常控制行為原因分析,例如強電磁干擾信號等。
在SOTIF模型與軟件異常控制行為原因分析基礎上,構建基于SOTIF 的測試用例及典型測試場景,實現對軟件各類異常控制行為和復雜運行場景的有效覆蓋。
基于軟件異常控制行為及其原因分析結果,參考汽車自動駕駛系統測試場景構建方法,構建機載軟件SOTIF測試場景,實現對軟硬耦合、控制過程、外部激勵、人機交互、狀態切換等復雜場景的有效模擬或仿真。
“場景”通常用于描述導致結果的一系列動作和事件。在ISO 26262 標準中,將場景分為功能場景、邏輯場景和具體場景3 類[7]。在本文中,機載軟件的場景(測試場景或者運行場景)主要指的是,軟件與其任務階段、運行環境等組成要素在一段時間內的總體動態描述,這些要素組成由所期望完成的系統任務與具體功能決定。
基于上述定義,本文將識別的軟件異常控制行為及其原因,轉化為機載軟件與其任務階段、運行環境等要素表征的一系列動作與事件,形成軟件SOTIF 測試場景構建要求。主要包括以下部分。
①基于接口數據異常的SOTIF測試場景:針對外部接口數據的各類異常,通過異常激勵數據施加構建測試場景。例如,設置輸入數據取值大于值域上限、取值一段時間內保持不變等。
②基于控制過程異常的SOTIF測試場景:針對軟件控制過程中的各類異常,通過異常激勵數據施加或環境仿真構建測試場景。例如,設置控制律長時間未輸出數據、輸出取值大于值域上限等。
③基于交聯設備異常的SOTIF 測試場景:針對源/目的等交聯設備的異常,通過設備模擬或仿真等方式構建測試場景。例如,設置傳感器下電故障、數據庫容量已存滿、執行機構卡滯等。
④基于余度表決異常的SOTIF測試場景:針對余度表決異常,通過余度模擬或者仿真等方式構建測試場景。例如,設置余度來源設備處于下電狀態、余度間的數據取值之差大于規定閾值等。
⑤基于狀態切換異常的SOTIF測試場景:針對軟件工作狀態之間的切換異常,通過異常激勵數據施加或仿真等方式構建測試場景。例如,設置狀態切換超時、同時進入兩個工作狀態等。
在所構建的SOTIF測試場景基礎上,建立異常控制行為原因、SOTIF要求與用例輸入,以及預期輸出之間的關聯關系,設計SOTIF測試用例。
①確定用例輸入數據:依據異常控制行為原因,明確相應接口數據的取值規則,以選取確定數值或者等價類數值作為SOTIF測試用例輸入數據。
②確定用例約束條件:依據異常控制行為原因,選取相應功能執行邏輯、運行場景或外部環境等,作為SOTIF測試用例執行的約束條件。
③確定用例預期輸出與通過準則:依據機載軟件SOTIF要求和異常控制行為,明確相應輸出數據的取值規則以確定測試用例的預期輸出,即軟件異常控制行為不發生或者得到有效控制。一般來說,用例執行通過準則應與預期輸出完全一致。但若危險等級較低,則通過準則也可適當放寬。
④確定SOTIF測試用例格式:依據外部接口控制文件(ICD),確定輸入接口數據的通信格式。進而依據接口通信格式和相應的數據取值內容,拼裝成可執行的軟件SOTIF測試用例。
本文針對機輪轉彎控制軟件,開展SOTIF 分析應用,驗證本文研究成果的可行性與有效性。
(1)機載軟件SOTIF建模。
首先,依據軟件需求,建立機載軟件的系統控制視圖模型,如圖5 所示。

圖5 系統控制視圖模型實例
依據上述系統控制結構模型,對轉彎控制軟件的相關需求描述如下。
①控制器:機輪轉彎控制系統。
②執行機構:機輪裝置。
③源設備:機輪角度傳感器。
④控制過程中的外部輸入輸出數據(包含控制反饋信號),外部輸入輸出數據列表如表2 所示。

表2 外部輸入輸出數據列表
⑤控制過程:軟件依據上位機傳輸的輸入數據“目標角度”(由人員設置)和機輪裝置反饋的輸入數據“機輪角度”(來自于傳感器)進行實時閉環控制解算,輸出“轉彎控制指令”至機輪裝置,驅動機輪裝置運動到“目標角度”。同時,輸出“顯示角度”至上位機顯示。
(2)機載軟件系統危險分析。
依據系統控制視圖模型,機載軟件系統的功能危險分析如下。
①H-1:機輪轉彎速度過快,導致飛機側翻。
②H-2:機輪到達指定角度位置的時間過久,導致飛機沖出跑道
針對識別的系統危險,參考STAMP 模型理論,確定相關的安全約束條件如下。
①SC-1:軟件必須控制機輪轉彎速度小于2°/s(對應危險H-1)。
②SC-2:軟件必須在規定的時間內(50 s),控制機輪轉動到規定位置(對應危險H-2)。
依據上述系統控制視圖模型,對安全約束條件進一步細化如下。
①SC-11:軟件必須控制機輪轉彎速度小于2°/s(對應危險H-1),即機輪裝置反饋的“機輪角度”取值變化率應小于2°/s。
②SC-22:軟件必須在規定的時間內(50 s),控制機輪轉動到規定位置(對應危險H-2),即機輪裝置反饋的“機輪角度”取值應與“目標角度”相一致。
(3)異常控制行為識別。
依據3.2 節中列舉的基于故障樹的異常控制行為識別方法,對兩個安全約束條件進行分析,識別導致危險的可能異常控制行為如下。
①針對安全約束條件SC-1(軟件必須控制機輪轉彎速度小于2°/s),識別的異常控制行為如表3 所示。

表3 SC-1 的異常控制行為識別
②針對安全約束條件SC-2(軟件必須在規定的50 s時間內,控制機輪轉動到規定位置),識別的異常控制行為UCA如表4 所示。

表4 SC-2 的異常控制行為識別
(4)異常控制行為原因分析。
依據3.3 節中的基于影響因素的異常控制行為原因分析方法,對上述異常控制行為的原因分析如下。
①針對異常控制行為UCA.1.1,識別原因如表5所示。

表5 UCA.1.1 的原因分析
②針對異常控制行為UCA.1.2,識別原因如表6所示。

表6 UCA.1.2 的原因分析
③針對異常控制行為UCA.2.1,識別原因如表7所示。

表7 UCA.2.1 的原因分析
④針對異常控制行為UCA.2.2,識別原因如表8所示。

表8 UCA.2.2 的原因分析
本文參考ISO 21448 標準中的SOTIF實施框架和汽車領域工程經驗,借助功能危險分析、故障樹模型、STAMP模型、場景驅動等理論方法,針對機載軟件運行特征構建SOTIF分析驗證工作的實施過程,包括機載軟件SOTIF 建模、系統功能危險分析、基于危險分析的系統風險評估、復雜場景下的機載軟件SOTIF 影響因素識別、基于故障樹的軟件異常控制行為識別、基于影響因素的異常控制行為原因分析、機載軟件SOTIF測試場景構建、場景驅動的機載軟件SOTIF 測試用例設計等內容。
上述研究成果及其初步工程應用結果表明,面向機載軟件的SOTIF分析驗證過程及方法可以推進SOTIF技術在機載軟件研制過程中的推廣與應用,形成符合標準要求、適用于復雜系統的機載軟件SOTIF 分析驗證能力,避免FMEA、FTA等安全性分析技術多關注非法數據、通信中斷等單點失效的不足,支撐研制人員充分識別機載軟件運行過程中的軟硬耦合沖突、人機交互異常、場景切換異常等復雜失效模式。同時,支持測試人員面向構建機載軟件的SOTIF 測試場景,實現對軟硬耦合、控制過程、外部激勵、人機交互、狀態切換等復雜場景的有效模擬或仿真,提升軟件測試效率和質量,最終確保機載軟件能夠滿足高安全、高可靠的研制要求。
需要說明的是,本文主要目標是建立SOTIF 在機載軟件研制中的完整實施過程,為后續的相關技術研究與工程應用提供參考。但限于篇幅,本文重點給出可能的技術方案和初步的工程示例,還需在未來工作中進行更加深入的技術研究與工程應用。