黃一帆，李海峰

(1.南京市第一中學，南京 210000； 2.北京航空航天大學，北京 100191)

0 概述

在停車場、小區(qū)、寫字樓等場所，都設有道閘管理系統(tǒng).通過軟硬件設備，綜合運用紅外線檢測、地感檢測、車牌拍照識別、智能卡識別、壓力波檢測等技術，實現(xiàn)道閘上升/下降控制、計時收費等功能.其中，最核心的組成部分就是道閘管理系統(tǒng)軟件，是系統(tǒng)的控制中樞，決定道閘上升/下降控制功能邏輯、計時收費功能邏輯的正確執(zhí)行.因此，道閘管理系統(tǒng)軟件的安全性能否得到有效保障，對于車輛財產(chǎn)甚至人身安全具有非常直接的影響[1-2].

經(jīng)過多年的發(fā)展，國內外道閘管理系統(tǒng)都已經(jīng)融入智能化功能，包括車牌智能識別、車輛進入智能感知與引導、自動計費定位等[3].現(xiàn)有關于道閘管理系統(tǒng)的技術研究，也多借助先進的智能化技術方法，進行系統(tǒng)的設計與實現(xiàn).例如IC卡技術、RFID射頻識別技術，多項傳感器融合技術等[4],但關于道閘管理系統(tǒng)安全性分析改進的研究則相對較少.

車輛或行人穿越道閘時，道閘意外下降、道閘無法上升，阻礙車輛進入等系統(tǒng)事故常有發(fā)生.但很少有人會去思考，為什么道閘管理系統(tǒng)軟件會引發(fā)這些安全事故.事實上，因為沒有對道閘管理系統(tǒng)軟件進行深入安全性分析，對于各類異常的任務場景或外部激勵的考慮不足，導致軟件失效，進而引發(fā)系統(tǒng)事故，造成不必要的財產(chǎn)損失甚至人身傷害.因此，本文將依據(jù)道閘管理系統(tǒng)軟件的工作原理，基于故障樹技術，針對“車輛或行人穿越道閘時，道閘意外下降”這一典型事故進行分析，識別導致事故發(fā)生的各類原因，為預防或避免類似危險事件發(fā)生提供參考依據(jù).

1 道閘管理系統(tǒng)工作原理與典型事故

1.1 道閘管理系統(tǒng)工作原理

圖1是一種采用“車牌拍照識別”與“地感檢測”技術的典型道閘管理系統(tǒng)[5].

依據(jù)圖1，安裝于控制機的“道閘管理系統(tǒng)軟件”從攝像機、地感設備、自動道閘等設備中接收車牌圖像、地感信號、道閘角度等輸入信號，經(jīng)過自動道閘控制或人工道閘控制等功能邏輯處理后，向自動道閘輸出道閘上升電流與道閘下降電流.因此，道閘管理系統(tǒng)軟件工作原理也是一種輸入(Input)—處理(Process)—輸出(Output)的典型黑盒控制過程[4].基于這一系統(tǒng)工作原理，針對道閘管理系統(tǒng)軟件兩項典型功能邏輯介紹如下.

1.1.1 自動道閘控制功能

輸入數(shù)據(jù)：“車牌圖像”“地感信號”“道閘角度”.

處理流程如圖圖2所示.

圖2 “自動道閘控制功能”處理流程

由圖2，道閘管理系統(tǒng)軟件接收到攝像機拍攝的車牌圖像后，進行車牌模式識別.若為有效的車牌圖像，輸出道閘上升電流，驅動道閘上升，直至道閘角度取值為90°，即完全打開，停止輸出道閘上升電流；若為無效的車牌圖像，則不做任何處理.

待道閘角度取值為90°后，道閘管理系統(tǒng)軟件周期性(20 ms)判斷地感信號取值是否有效.若取值為有效，表明車輛正在穿越道閘，則道閘管理系統(tǒng)軟件不做任何處理，保持道閘打開；若取值為無效，則道閘管理系統(tǒng)軟件輸出道閘下降電流，驅動道閘下降，直至道閘角度取值為0°，即關閉完全，停止輸出道閘下降電流.

輸出數(shù)據(jù)：道閘上升電流、道閘下降電流.

1.1.2 人工道閘控制功能

輸入數(shù)據(jù)：道閘上升指令、道閘下降指令.

處理流程如圖3所示.

由圖3，若軟件接收到的道閘上升指令取值為有效，則輸出道閘上升電流；否則，停止輸出.若軟件接收到道閘下降指令取值為有效，則輸出道閘下降電流；否則，停止輸出.

輸出數(shù)據(jù)：道閘上升電流、道閘下降電流.

1.2 道閘管理系統(tǒng)典型事故

圖3 “人工道閘控制功能”處理流程

道閘管理系統(tǒng)是人們日常生活中經(jīng)常遇到的公共設施，由于系統(tǒng)軟件設計存在缺陷或者考慮不足，會出現(xiàn)各類事故場景，對社會財產(chǎn)或人身安全造成嚴重影響.本小節(jié)對道閘管理系統(tǒng)可能的典型事故進行分類總結，為基于故障樹的安全性分析工作提供輸入.

道閘管理系統(tǒng)典型事故，可從控制車輛進入、以及計費管理2大方面進行分類.

1.2.1 控制車輛進入方面典型事故

①不應下降時下降，應下降時未下降

?車輛穿越道閘時，道閘下降

?車輛駛離道閘后，道閘未下降

?行人穿越道閘時，道閘下降

?道閘始終保持下降狀態(tài)

?……

②應上升時未上升、不應上升時上升

?識別出有效車牌，道閘未上升

?車牌識別未通過，道閘上升

?道閘兩側同時有車輛駛入，道閘上升

?道閘始終保持為上升狀態(tài)

?沒有車輛駛入，道閘卻上升

?……

控制車輛進入方面的典型事故對人身安全、車輛或者道閘設備有直接影響，因此是本文重點分析對象.

1.2.2 計費管理方面典型事故

①未進行有效計費

?識別有效車牌后，未進行計費

?車輛停留過夜后，計費重新開始

?……

②超時計費

?車輛已經(jīng)離開，卻未停止計費

?將小車識別為大車，進行額外計費

?……

計費管理屬于財產(chǎn)損失的范疇，對安全性的影響相對較弱，故不是本文重點分析的對象.

2 基于故障樹的道閘管理系統(tǒng)安全性分析

2.1 道閘管理系統(tǒng)軟件故障樹分析模型建立

故障樹分析技術(Fault Tree Analysis，F(xiàn)TA)以一個不希望的系統(tǒng)故障事件(或災難性的系統(tǒng)危險)，即頂事件作為分析的目標，通過自上而下的嚴格按層次的故障因果邏輯分析，逐層識別導致故障事件的直接原因，最終找出導致頂事件發(fā)生的所有原因及其組合[6-8].在本章節(jié)中將借助故障樹分析技術，針對車輛或行人穿越道閘時，道閘意外下降這一典型系統(tǒng)事故展開分析，即將該事故作為頂事件，結合道閘管理系統(tǒng)軟件工作原理，自頂向下建立故障樹分析模型，逐層識別導致這一事故產(chǎn)生的各種可能原因，進而針對原因分析結果，對道閘管理系統(tǒng)軟件功能進行設計改進，預防或控制此事故的發(fā)生.

結合道閘管理系統(tǒng)軟件工作原理可知，觸發(fā)道閘管理系統(tǒng)軟件輸出道閘下降電流的主要事件有2個，即地感信號取值變?yōu)闊o效，以及道閘下降指令取值變?yōu)橛行?基于這兩個事件，所建立的軟件故障樹分析模型如圖4所示.

2.2 基于故障樹模型的軟件安全性分析

2.2.1 分析過程

基于故障樹模型的軟件安全性分析過程是自上而下的，主要內容如下：首先定義要分析的頂事件(即道閘管理系統(tǒng)典型事故)作為故障樹的“根”；然后分析導致頂事件發(fā)生的直接原因(即中間事件)，并用適當?shù)倪壿嬮T與頂事件相連，作為故障樹的“節(jié)”；重復上述步驟，一直追溯到導致頂事件發(fā)生的全部最小獨立原因(即底事件)為止，這些底事件構成故障樹的“葉”.

圖4 道閘管理系統(tǒng)軟件故障樹分析模型

2.2.2 故障樹最小割集計算

1)基于下行法的最小割集計算

下行法的基本原理是：從頂事件開始，逐級向下尋查.遇到“與門”就將其輸入事件排在同一行(只增加割集的階數(shù)，不增加割集的個數(shù))；遇到“或門”就將其輸入事件各自排成一行(只增加割集的個數(shù)，不增加割集的階數(shù)).重復上述步驟，直到全部換成底事件為止，這樣得到的割集借助布爾代數(shù)中的運算律，去重合并，剩下的即為故障樹的全部最小割集.

2)基于上行法的最小割集計算

上行法的基本原理是：從故障樹底事件開始，自下而上逐層進行事件集合運行.將“或門”輸出事件用輸入事件的并(布爾和)代替，將“與門”輸出事件用輸入事件的交(布爾積)代替.在逐層帶入過程中，按照布爾代數(shù)吸收律和等冪律來化簡，最后將頂事件表示成底事件積之和的最簡式.其中每一積項對應于故障樹的一個最小割集.

2.2.3 頂事件發(fā)生概率計算

在全部最小割集的基礎上，將故障樹頂事件表示為最小割集中底事件積之和的最簡布爾表達式，即可對頂事件發(fā)生概率進行定量評估計算.

用最小割集表示故障樹頂事件.在求得全部最小割集C1，C2，Cr的基礎上，可將故障樹的頂事件表示為式(1)：

(1)

式中，Xi為屬于第Cj個(j=1,…,r)最小割集的第i個底事件.則故障樹頂事件T的發(fā)生概率是各個最小割集中底事件X發(fā)生概率的函數(shù)，如式(2)：

P(T)=Q(q1,q2,…,qn)

(2)

2.2.4 分析結果

依據(jù)圖4所示的故障樹分析模型，識別出如表1所示的原因事件.

表1 基于故障樹的原因事件分析

上表所示的4個原因事件由“或門”相連接，即每個原因事件都可以獨立地導致頂事件發(fā)生，因此是都可以獨立作為故障樹的最小割集事件，即導致頂事件事故發(fā)生的最直接原因[9-10].

鈉表測量所需的pH值，pH計測量樣水所需的溫度值，都可以作為狀態(tài)值，用來輔助判斷當前的樣水是否符合測量要求。

這4個事件中，前3個原因事件與道閘管理系統(tǒng)軟件直接相關，即由于軟件功能邏輯出現(xiàn)故障而導致的；最后一個原因事件則與軟件無關，是由硬件設備故障導致的.因此，本文將重點針對前3個原因事件展開分析，將其映射為生活中常見的事故場景，分別描述事故場景、事故原因、軟件故障、事故影響、軟件設計改進等分析內容，在增強人們對道閘管理系統(tǒng)軟件安全性分析直觀認識的同時，為避免或控制此類事故發(fā)生提供參考建議.

2.3 事故場景分析及軟件改進

2.3.1 典型事故場景一

前車正在穿過道閘，后車緊隨進入，地感設備受到干擾，傳輸信號產(chǎn)生跳變，系統(tǒng)意外驅動道閘下降，碰到行駛車輛.

事故原因(原因事件X1)：前車正在穿過道閘，輸入數(shù)據(jù)地感信號取值為有效.此時后車緊隨進入，由于兩車距離過近，車輛震動頻率重疊，地感設備受到干擾，使得地感信號取值發(fā)生跳變，即由有效變?yōu)闊o效.

軟件故障：由于地感信號取值跳變?yōu)闊o效，自動道閘控制功能將自動輸出道閘下降電流，意外驅動道閘下降.

事故影響：系統(tǒng)驅動道閘下降，砸到正在行駛的汽車頂部，造成財產(chǎn)損失.

分析說明：這種場景在生活中很常見.很多車輛為節(jié)省時間，等不及道閘完全放下，就緊隨前車一起穿越道閘.一旦地感設備設計不夠精密，易受到外界信號干擾，那么就可能會導致地感信號跳變，使得道閘意外下降，造成財產(chǎn)損失.

基于安全性分析的軟件設計改進.

針對事故原因事件X1，在自動道閘控制功能邏輯中，增加對輸入數(shù)據(jù)地感信號的濾波處理.即當?shù)馗行盘柸≈涤捎行ё優(yōu)闊o效時，軟件需對地感信號取值進行判斷，連續(xù)5個周期地感信號取值均為無效時，軟件才輸出道閘下降電流.改進后的處理邏輯如圖5.

圖5 基于事故原因X1的軟件設計改進

本論文之所以推薦5個周期的檢測時間，是因為：若檢測時間設置過長(例如大于10個周期)，則將降低軟件執(zhí)行效率，即軟件需要連續(xù)采集10個周期以上的數(shù)據(jù)，才能執(zhí)行1次處理邏輯.這對于有一定實時性和靈敏度要求的道閘系統(tǒng)來說，不容易接受；若檢測時間設置過短(例如2、3個周期)，軟件會頻繁連續(xù)地進行濾波處理，增加軟件運行負擔.因此，綜合考慮運行負擔與執(zhí)行效率，并參考其他類似工業(yè)設備的設計方法，本論文推薦檢測時間設置為5個周期，也可依據(jù)具體系統(tǒng)進行設定.

此外，還可考慮借助車牌圖像數(shù)據(jù)，輔助道閘管理系統(tǒng)識別兩個車輛緊跟進入這種異常情況.即若系統(tǒng)接收兩個車牌圖像的時間間隔較短(例如小于1 s)，則軟件判斷此時可能出現(xiàn)兩輛車緊隨進入或者兩輛車同時進入等狀況，此時將持續(xù)保持道閘上升電流的輸出.

2.3.2 典型事故場景二

車輛穿過道閘后，道閘開始下降.此時，有行人或非機動車輛跟隨進入.而道閘繼續(xù)下降，行人或非機動車輛被道閘碰到.

事故原因(原因事件X2)：車輛穿過道閘后，道閘準備開始下降.此時，有行人或非機動車輛(電動車、摩托車等)跟隨進入.由于行人或非機動車輛的震動頻率與汽車不一樣，地感設備無法對其進行有效檢測和感知，輸入地感信號取值將保持為無效.

軟件故障：行人或非機動車輛穿越導致道閘過程中，地感信號取值保持為無效，自動道閘控制功能將輸出道閘下降電流，驅動道閘快速下降.

事故影響：系統(tǒng)驅動道閘快速下降，砸到正在進入的行人或非機動車輛，導致車輛損壞或人員傷亡.

分析說明：這種場景在生活中也很常見，很多電動車或行人不清楚道閘管理系統(tǒng)的工作原理，以為道閘會感知自己而不會下降，心存僥幸緊隨車輛進入小區(qū)，意外引發(fā)嚴重的安全性事故.

基于安全性分析的軟件設計改進：針對事故原因事件X2，在自動道閘控制功能邏輯中，增加道閘下降電流延時處理.即當?shù)馗行盘栕優(yōu)闊o效后，軟件開始計時，計時5 s后，輸出道閘下降電流.改進處理邏輯如圖6.

圖6 基于事故原因X2的軟件設計改進

需要說明的是，本論文之所以推薦5 s的延時時間是因為：若延時時間設置過短，則地感信號變?yōu)闊o效后，道閘立刻就會變?yōu)橄陆禒顟B(tài).正在穿越的人群或非機動車輛來不及響應；若延時時間設置過長，則道閘又將長時間保持停滯狀態(tài)，影響后面車輛的正常進入.因此，綜合考慮反應時間與正常運行，并參考其他類似工業(yè)設備的設計方法，本論文推薦5 s的延時時間，也可依據(jù)具體系統(tǒng)進行設定.

此外，還可考慮借助紅外裝置，輔助道閘管理系統(tǒng)識別行人或非機動車輛.即紅外裝置接收正在進入道閘的物體所輻射的紅外線信號，并反饋至道閘管理系統(tǒng)軟件.軟件對反饋的紅外線信號進行判斷，若識別為機動車輛、行人、或非機動車輛等物體，則需要繼續(xù)保持道閘上升電流的輸出.

圖7 基于事故原因X3的軟件設計改進

2.3.3 典型事故場景三

車輛正在穿過道閘，道閘保持上升狀態(tài).此時，管理員誤操作，通過“人工道閘控制”功能驅動道閘下降，砸到行駛中的車輛.

事故原因(原因事件X3)：車輛正在穿過道閘，輸入數(shù)據(jù)地感信號取值為有效.此時，管理員誤操作，按壓道閘下降按鈕，輸入數(shù)據(jù)道閘下降指令取值變?yōu)橛行?

軟件故障：輸入數(shù)據(jù)地感信號取值為有效，自動道閘控制功能將不輸出道閘下降電流.但此時，輸入數(shù)據(jù)道閘下降指令取值變?yōu)橛行?，人工道閘控制功能將輸出道閘下降電流，驅動道閘快速下降.

事故影響：系統(tǒng)驅動道閘下降，砸到正在行駛的汽車頂部，造成財產(chǎn)損失.

分析說明：這個問題是由于管理員誤輸入道閘下降指令，使得自動道閘控制功能與人工道閘控制功能并發(fā)，產(chǎn)生沖突導致的事故.現(xiàn)實中，管理員由于視線受阻，很可能會在車輛未穿越道閘的情況下，執(zhí)行誤操作輸入，干擾自動控制功能實現(xiàn)，錯誤驅動道閘下降.

基于安全性分析的軟件設計改進.

針對事故原因事件X3，在人工道閘控制功能邏輯中，增加地感信號的判斷.當輸入數(shù)據(jù)道閘下降指令取值變?yōu)橛行Ш?，軟件判斷輸入?shù)據(jù)地感信號取值.若“地感信號”取值為“有效”，則輸出“告警提示”，待管理員確認后，才輸出“道閘下降電流”.改進后處理邏輯如圖7所示.

2.4 軟件改進前后對比

綜上分析，針對各種事故原因進行軟件設計改進后，可有效地避免相應事故的發(fā)生.對比說明如下.

2.4.1 事故原因事件X1

增加輸入數(shù)據(jù)地感信號的濾波設計之后，可有效判別由于兩車距離過近，車輛震動頻率重疊所導致的地感信號取值跳變現(xiàn)象.從而避免前車正在穿過道閘，后車緊隨進入，系統(tǒng)意外驅動道閘下降，碰到行駛車輛事故的發(fā)生.

2.4.2 事故原因事件X2

增加道閘下降電流延時設計之后，可提升道閘下降時對突發(fā)事件的處理能力.即當車輛穿過道閘后，此時若有行人或非機動車輛跟隨進入，則給予行人或非機動車充足的穿越時間，避免誤傷.

2.4.3 事故原因事件X3

增加地感信號的判斷設計之后，可防止由于管理員誤操作而引發(fā)的意外道閘下降事件.即若管理員誤輸入道閘下降指令后，可根據(jù)地感信號是否有效，對管理員進行提示，待其確認后才運行下降.

2.5 設計改進方案的優(yōu)化原則

基于多個失效原因分別進行軟件設計改進時，可能會對同一個輸入輸出接口數(shù)據(jù)進行修改，或者同一個時序約束進行修改，導致取值或時序沖突.針對此問題，本論文提出如下流程優(yōu)化原則，確保改進之間相互兼容并滿足已有需求.

2.5.1 優(yōu)先級原則

根據(jù)失效原因導致的事故嚴重程度，對各類設計改進方案進行優(yōu)先級劃分.即多個設計改進方案出現(xiàn)沖突時，以導致事故最為嚴重的設計方案為準，進行改進方案合并或優(yōu)化.

2.5.2 統(tǒng)一化原則

如果多個失效原因的事故嚴重程度相同，此時可從設計成本、可行性等角度進行綜合考慮，針對多個改進方案進行統(tǒng)一化處理，確保多個改進方案采用相同的處理策略.

3 結束語

本文針對道閘管理系統(tǒng)軟件，借助故障樹分析技術，識別導致車輛或行人穿越道閘時，道閘意外下降這一安全性問題的3類典型原因事件，這些原因事件均可映射為各類常見的生活場景.這說明，導致道閘智能管理系統(tǒng)軟件安全性問題的原因是與道閘的使用方式密切相關的.事實上，借助故障樹技術，結合更多的生活使用場景，還可以識別其他各類原因事件：例如，道閘還未上升到90°(即未全部打開)，汽車就開始駛入；系統(tǒng)識別出有效車牌信息后，車輛卻沒有及時駛入；兩輛車同時從道閘兩側駛入；系統(tǒng)同時識別出2個有效的車牌信息等等.這些原因事件可能會導致道閘控制異?；蛘哂嫊r收費錯誤等危險事故的產(chǎn)生，造成不必要的財產(chǎn)損失甚至人身傷亡.

綜上，安全性問題并不只存在于航空航天等高科技領域，在日常生活中也是隨處可見，例如商場電梯、地鐵出入閘機、地鐵車門等生活設施.借助故障樹技術，可以針對這些生活設施中的控制軟件進行安全性分析，有效識別身邊的各種安全隱患，從而有效規(guī)避或預防財產(chǎn)損失、環(huán)境污染、人身傷亡等危險事故的發(fā)生.

[1] GJB/Z 102A軍用軟件安全性設計指南[S].北京: 總裝備部軍標出版發(fā)行部，2012.

[2] Huang Z Q，Xu B F，Kan S L，et al.Survey on embedded software analysis standards，methods and tools for airborne system[J].Journal of Software，2014，25(2): 200-218.

[3] Oentaryo.Self-trained automated parking system [C].Control Automation，Robotics and Vision Conference，2004.ICARCV 2004，2: 1005-1010.

[4] 李揚威，焦鵬鵬.城市智能停車管理系統(tǒng)研究[J].交通信息與安全，2014，32(4): 160-164.

[5] https: //www.zhihu.com/question/33818269/answer/108820828.

[6] Liu J，Dehlinger J，Lutz R.Safety analysis of software product lines using state-based modeling [J].Journal of System and Software.2007，80(11): 1879-1892.

[7] GJB/Z 768A故障樹分析指南[S].北京: 總裝備部軍標出版發(fā)行部，2012.

[8] 周薇，劉慶生.嵌入式火控系統(tǒng)軟件故障樹分析研究[J].現(xiàn)代電子技術，2015，38(8): 105-108.

[9] Ma L，Huang ZQ，Xu BF，Chen Z.A fault tree analysis method supporting model checking.[J].Computer & Digital Engineering，2013，41(2): 257-260.

[10] 章雪梅，李文靜.軟件系統(tǒng)的故障樹分析(FTA)[J].無線電通信技術，2003，29(1): 39-42.