航天嵌入式軟件代碼邏輯分析①

左萬娟,董 燕,黃 晨,王小麗

1(北京控制工程研究所,北京 100190)

2(北京軒宇信息技術有限公司,北京 100190)

航天嵌入式軟件,因其自主處理能力強、運行實時性要求高、故障診斷與處理手段多、在軌運行時間長以及在軌運行環境復雜等特點,導致其部分運行場景很難在地面實現真實狀態下的動態驗證.因此,在地面所開展的動態測試往往會存在這樣或那樣的測試缺口,導致了某些軟件問題的在軌發生,這對于有著高可信高可靠高自主要求的航天嵌入式軟件而言,是難以接受的.同時,隨著軟件定義衛星設計理念的提出,軟件規模和復雜度的不斷攀升,也導致軟件潛在缺陷越來越多[1,2].因此,研究軟件測試方法,進一步提升軟件測試質量勢在必行.

軟件測試,根據是否運行軟件,一般分為靜態測試和動態測試,其中,針對靜態測試,一般采用基于工具的靜態分析、和基于人工的代碼審查等測試手段.根據目前的工程實踐,對于有著高可信高可靠要求的航天嵌入式軟件而言,基于工具的靜態分析手段仍然無法取代人工代碼審查,只能作為人工代碼審查的補充手段.因此,在現有條件下,對于航天嵌入式軟件的質量保證而言,人工代碼審查仍然是不可或缺的一種重要技術手段.

自從1976年首次提出代碼審查(code inspection)以來,代碼審查一直被認為是一種重要而且有效的改進軟件質量的方法[3,4].經驗表明,組織良好的代碼審查,可以發現程序中30%～70%的編碼和邏輯設計錯誤[5].高質量的代碼審查能夠發現60%以上的軟件問題,而且往往能夠發現很多通過工具和動態測試無法發現的深層次代碼問題,如算法實現問題、軟件架構問題、時序邏輯問題等[6].代碼審查可以比動態測試更有效地發現某些特定類型的缺陷,且實施時無需特別條件,成本較低[7].眾多研究成果表明,相比動態測試,代碼審查更為高效、靈活且發現問題能力強.

但是,由于代碼審查本質上仍然屬于一種既費時又費力的技術手段,且測試結果嚴重依賴于人的能力,因此,雖然是目前工程實踐中的一種主要技術手段、但是針對性的研究并不多.當前軟件測試的研究熱點更多地集中在工具、自動化和人工智能等方面[8-12].有限的針對基于人工代碼審查所開展的研究多著眼于檢查項(即檢查內容)的研究與總結[13-16],對方法的研究與總結則很少,尤其在基于人工的代碼邏輯分析方面,尚無相關研究成果發表.而基于檢查項的代碼審查方法,屬于片段式檢查,缺乏對代碼的整體邏輯分析,不利于發現代碼中潛藏的深層次復雜邏輯問題.

本文針對代碼審查重點內容之一的代碼邏輯分析開展研究,提出了場景分析法、時序分析法、假想故障追源法等10 種主要的代碼邏輯分析方法,并開展了工程應用分析.

1 分析方法

“分析”,通俗來說,是以某種方式將復雜對象分解為更小的部分,以更好地理解該對象的過程[17].

通過對近10年來航天型號軟件在軌、在研以及第三方評測中軟件缺陷的機理、缺陷查找過程、缺陷暴露過程以及缺陷引發后果的研究,提出了場景分析法、時序分析法、假想故障追源法、答疑解惑分析法等十種主要的代碼邏輯分析方法,分別予以闡述.

1.1 場景分析法

軟件系統的執行過程可看作是大量場景的有序序列[18].

針對特定的軟件功能,結合軟件的運行時序及運行狀態,構造不同的軟件運行場景,進行針對特定場景的軟件運行狀態與邏輯分析.

通過此法,重點確認針對各種可能的運行場景,軟件是否均能達到設計預期;針對特定場景,是否存在設計失效、甚至進而引發嚴重的不良后果.

實例說明如下:

某單機采用雙機冷備份,設計了如下自主故障診斷及處理策略:

如果診斷到主份連續故障20 s,則臨時切換至備份(主份斷電、備份加電),2 s 后再切換回主份(主份加電、備份斷電).

切換回主份后,如果診斷到主份設備仍然故障,則當連續故障達到100 s 則永久切換至備份.

針對上述設計,需要構造如下場景,并對相關代碼邏輯進行分析:

場景1.臨時主備切換之后,主份恢復正常(默認備份正常).

場景2.臨時主備切換之后,主份仍然故障(默認備份正常).

經場景2 分析發現,由于主備故障診斷共用了一個連續故障計時變量,當主份故障20 s 臨時切換至備份期間,由于備份正常,導致連續故障計時變量被清零,則切換回主份后,20 s 后會再次執行臨時切換備份處理.即,在場景2 下,軟件會周期性地執行主備切換,這顯然違背了設計預期.按照設計預期,如果主份持續故障,則100 s 后應執行永久切備份處理.

上述設計缺陷,如果僅做場景一分析,是無法檢出的;如果分析過程中,未考慮備份狀態對軟件運行狀態的影響,也無法檢出.

1.2 時序分析法

航天器實際上是一個分布的、網絡化的嵌入式系統,在這個系統中各個單機采用相同或不同的中央處理單元(CPU)及編程語言,彼此之間通過各種串口、并口或總線,采用中斷或查詢方式進行通訊[19],這就要求彼此之間的通訊時序必須匹配良好,否則將導致通訊失敗,影響航天器的正常運行.

時序分析法,重點針對航天器系統中各個單機之間的通訊時序匹配性開展分析.至于單機內部的運行時序,一般可以通過變量分析以及代碼邏輯分析中的場景分析法等來確認.

實例說明如下:

軟件通過422 串口與上位機通訊,接收上位機指令,并回復應答數據.

為確認軟件設計是否滿足上述通訊需求,應重點做如下時序分析:

(1)接收時序分析:接收的及時性必須保證,否則導致接收丟字符.

(2)應答時序分析:應答的及時性必須保證,否則影響上位機軟件接收應答數據.

根據上述分析,代碼審查時重點關注如下時序相關設計:

(1)串口中斷的處理時間:如果一個字符的接收/發送觸發一次串口中斷,則串口中斷的設計必須簡捷,即,中斷處理時間不能過長,否則,將不能及時接收/發送下一個字符.

(2)高優先級中斷的處理時間:如果有比串口中斷更高優先級的中斷,則高優先級中斷的處理時間必須嚴格控制,避免影響串口中斷響應及處理的及時性.

(3)關中斷時間:如果軟件中采取了關中斷保護設計,則關中斷的時間必須嚴格控制,避免影響串口中斷響應及處理的及時性.

1.3 假想故障追源法

針對軟件中的某些特定設計,需要建立假想故障,并追蹤溯源,分析代碼設計是否存在觸發假想故障的源頭,如果存在,則為潛在設計缺陷.

以常見的while 循環設計為例,建立假想故障為while 死循環,分析代碼設計上是否存在觸發while 死循環故障的源頭.此類缺陷較多,實例說明如下:

實例1.當軟件依賴于特定的硬件狀態條件退出while 循環時,如果硬件狀態始終不具備,則導致while死循環.

實例2.依賴于計數條件退出while 循環時,如果計數條件被破壞導致計數無法累加,則因計數條件始終不滿足而導致while 死循環.

1.4 答疑解惑分析法

代碼中總是會或多或少地存在一些令人困惑的設計細節,這通常是由于需求描述的顆粒度限制所導致的,這些令人困惑的設計細節就是答疑解惑分析法的分析對象,分析目標就是實現對這些設計細節的答疑解惑,即,理清代碼設計的理由和依據,以確認代碼設計的正確性.如果通過分析無法解除疑惑,則通常在這些設計細節中是存在潛在的設計缺陷的.

實例說明如下:

軟件每秒給下位機軟件發同步校時指令,針對指令中的同步校時時間Time.sync,代碼設計如下:

Time.sync=Time.Star_Orbit- 0.02+(Time.DeltaT*1.0e-6);

針對同步校時時間Time.sync,需求中并未明確說明其計算方法.通過代碼分析發現,Time.Star_Orbit是當前控制周期起始時刻,操作“Time.Star_Orbit-0.02”,將時間校正到上一控制周期TCTM 任務起始時刻.而操作“+(Time.DeltaT* 1.0e-6)”中,變量Time.DeltaT是上一次(也就是上一秒)同步校時指令發出時刻相對于指令發出所在控制周期的TCTM 任務起始時刻的時間偏差.綜上,這是一個很令人困惑的設計,困惑點如下:

(1)參與Time.sync計算的Time.Star_Orbit-0.02與Time.DeltaT* 1.0e-6的時間基準不同,導致計算結果的物理意義不明確.

(2)為什么不是將Time.sync調整到同步校時指令發出時刻呢?

經與開發方溝通反饋,代碼修改如下:

Time.sync=Time.Star_Orbit+0.65;

修改后的代碼中,0.65是根據任務調度時序計算得到的同步校時指令發出時刻相對于當前控制周期起始時刻的時間偏差,即,Time.sync為同步校時指令發出時刻.至此,疑惑解除,分析通過.

1.5 類似設計對比法

代碼中經常會存在一些類似設計,比如,針對同類多個單機的操作、不同場景下的同類處理,等.針對此類設計,開發人員通常采用代碼克隆的方式實現.

所謂代碼克隆,是指軟件開發中由于復制、粘貼引起的重復代碼現象.研究指出,一般商業軟件中存在5%～20%的重復代碼[20].

針對代碼中的類似設計,可采用類似設計對比法開展分析.即,針對類似設計代碼進行比對,查看類似設計之間是否存在差異,分析差異之處的設計正確性.

通常,通過簡單的比對,可以找出因代碼克隆時的疏忽而導致的設計缺陷.但是,也有些較深層次的設計缺陷,需要通過更審慎的分析才可發現.

實例說明如下:

軟件在task4中根據標志hk6start啟動HK6 相關處理,正常結束HK6 處理時,會清標志hk6start、并發TC_HK6 指令停止HK6 處理.但是,軟件在處理某故障時存在僅清標志hk6start、未發TC_HK6 指令的設計,與正常結束HK6 處理的流程不一致.

類似設計對比法的應用,主要有如下兩個方面:

(1)通過比對發現類似設計上的差異,通過差異分析查找缺陷.

(2)某處類似設計中檢出缺陷后,應繼續分析其它類似設計處是否存在類似缺陷.

1.6 相關性(影響域)分析法

有些情況下,軟件的各個功能之間存在一定的相關性,即,某一功能的實現方式可能會影響另一功能的實現結果.因此,需要開展相關性(影響域)分析.

實例說明如下:

需求要求以變量形式定義某S 存儲區的地址空間,以便在軌重新分配地址空間.

軟件實現時,以變量形式定義了S 存儲區的地址空間,并在實施S 區存儲時以變量形式訪問地址,滿足需求.但是,在S 存儲區數據下卸指令處理中,軟件按照初始設置的S 存儲區的起始/結束(固定)地址來進行指令參數合法性判斷,顯然,該合法性判斷設計與“在軌重新分配S 區地址空間”的需求是不符的.

1.7 星地控制匹配分析法

衛星在軌運行具有高度自主性,同時以遙測的形式,將其在軌運行狀態打包發回地面,供地面監控,必要時,地面通過遙控指令等方式對衛星實施控制.但是,從在軌數據打包、到數據發回地面、至地面完成解析與數據判讀,總是會有或多或少的時延,這也就導致地面可能在并未實時獲知衛星在軌運行狀態的情況下對衛星進行了遙控控制,從而可能導致衛星自主控制與地面遙控控制之間發生相互間的干擾、覆蓋等不匹配行為.

星地控制匹配分析法,針對星地控制的匹配性開展分析,其分析對象一般是星上自主和地面遙控兩種手段均可控制的功能,分析兩種控制手段之間是否存在相互干擾、覆蓋等不匹配行為并造成了不良后果.

目前,針對同時具備星地兩種控制手段的功能,通常的設計準則是地面優先,即,地面遙控可以覆蓋星上自主控制,反之不行.但是,也存在個例.比如模式轉換,如果在星上自主轉模式M 之后,地面再次發遙控指令轉模式M,則星上軟件一般應屏蔽地面發的遙控轉模式M 指令,否則,轉模式時的初始化操作會干擾星上正常的自主模式控制過程.

實例說明如下:

某部件控制指令,有星上自主發出和地面遙控發出兩種手段.

軟件在task1中根據當前運行狀態自主設定控制參數、并發送該指令.

軟件在task2中接收地面遙控指令,其中的控制參數由地面設定.

根據上述設計,軟件形成如下運行時序:task2 接收遙控指令→;task1 自主設置指令→;task1 發送指令.可見,遙控指令必定被自主指令所覆蓋,從而導致遙控失效.

1.8 接口軟件狀態分析法

有些情況下,被測軟件會采集與其接口的軟件狀態,并將該狀態作為特定處理的判定條件,即,接口軟件的狀態會影響被測軟件的運行狀態,而這通常是軟件設計師容易忽視的地方.測試過程中,忽略接口軟件狀態對被測軟件狀態的影響,或者對接口軟件狀態未仔細探究而采取了想當然的心態,都容易導致被測軟件相關設計缺陷被遺漏.

當接口軟件狀態影響到被測軟件的運行狀態時,需要分析各種可能的接口軟件狀態對被測軟件的影響,以確認被測軟件在相關設計上的正確性.

實例說明如下:

某故障處理策略:陀螺連續故障計數達到100,則給陀螺斷電10 個控制周期,然后再給陀螺加電.

但是,由于陀螺斷電期間,被測軟件采集到的陀螺通訊狀態為異常,導致連續故障計數不變(注:通訊正常情況下,才進行診斷并操作連續故障計數),從而導致軟件重復執行連續故障計數100的處理分支,與設計預期不符.

1.9 隱含需求分析法

隱含需求通常指那些必須要實現、但是需求分析人員又沒有意識到需要把它們在需求規格說明中清晰描述出來的需求.這些需求,一旦未予實現,通常會引發一定的不良后果.

實例說明如下:

故障診斷及處理功能中,如果采取了故障后給設備斷電、再加電的處理策略,則需要考慮持續故障情況下,是否會導致設備重復斷電、加電,這種持續故障情況下的設備重復斷電加電通常是設計上所不期望的.但是,通常的需求規格說明中僅會提出故障后給設備斷電再加電的需求,而不會明確說明持續故障后的處理需求.因此,持續故障情況下的處理策略就屬于隱含需求,需要明確需求后對相關處理開展分析檢查.

隱含需求通常涉及如下方面:

(1)遵循的標準、芯片手冊:比如,標準及芯片手冊中的操作規范、時序要求等.

(2)軟件接口交互需求:比如,交互雙方的接收與應答響應等.

(3)硬件接口交互需求:比如,查詢、等待硬件狀態的延時涉及等.

(4)可靠性安全性需求:比如,指令合法性校驗、重要數據三取二等.

(5)功能級需求:最為復雜的一類隱含需求,需要結合具體功能做具體分析.

1.10 需求/設計合理性分析法

在代碼審查過程中,針對需求和設計,都需要做合理性分析,避免盲從.

有許多需求/設計不合理的實例:

實例1.參數(變量)有初值,同時支持上注修改.但是,在上注異常時軟件將參數清零、而非恢復為初值或保留之前的上注值.——設計不合理.

實例2.協議規定遙測中的CAN 重新初始化標志占用1 bit,A、B 總線共用,發生一次CANA 或CANB重新初始化,則遙測位翻轉一次.如果在1 個遙測輪詢周期內A、B 總線均重新初始化,則遙測結果與A、B 總線均未重新初始化的遙測結果是一樣的,導致遙測設計失效.——需求不合理.

實例3.AD 采集過程中,如果軟件采用了連續采集多次取均值的設計,則連續采集過程中,每次采集均應重新啟動AD 轉換,否則會導致連續采集設計無意義.——設計不合理.

2 應用分析

2.1 應用說明

作為代碼審查的重點內容之一,代碼邏輯分析側重于功能級的代碼邏輯的分析與確認.工程應用中,應針對代碼邏輯分析與檢查單、變量分析[21,22]、中斷訪問沖突分析[23,24]等其它代碼審查重點內容開展綜合性分析與確認,以期達到最佳的工程應用效果.

2.2 應用數據分析

根據中國空間技術研究院軟件產品保證中心的統計數據,近半年內,開展代碼邏輯分析所檢測出的缺陷占比為23%.

選取近期結束的5 個項目,對綜合開展代碼邏輯分析、檢查單確認、變量分析、中斷訪問沖突分析后的代碼審查發現缺陷占比進行統計,數據如表1.

表1 綜合應用數據統計

數據來源說明:

(1)統計數據取自中國空間技術研究院軟件產保中心第三方評測數據庫.

(2)所選項目均為星載嵌入式軟件第三方評測項目、且提交第三方評測之前均已完成開發方自測試.

(3)僅統計已做修改程序處理的缺陷數.

(4)統計數據不含注釋錯誤、多余物等低級缺陷.

通過應用數據可以看出,綜合開展代碼邏輯分析、檢查單確認、變量分析、中斷訪問沖突分析后,代碼審查發現缺陷占比明顯高于業界公認的30～70%,應用效果良好.

2.3 應用意義分析

依托具體方法,開展綜合性代碼審查,產生的意義如下:

(1)使代碼審查過程有法可依、有章可循,有助于提升人的能力,縮小人與人之間測試質量的差異,實現整體測試能力的提升.

(2)為代碼設計提供參考,編碼階段借鑒這些方法,有助于及早規避軟件缺陷,實現缺陷早期預防.

(3)為測試設計提供參考,有利于提高動態測試的充分性.

(4)為缺陷自動化檢測工具研發提供參考,有助于促進工具能力的提升.

(5)為缺陷自動化檢測工具的推廣應用提供了參照目標,工具的能力必須超越人,才能真正取代人.

2.4 不同測試手段的對比分析

結合多年的軟件測試工程實踐,開展了靜態分析工具、人工代碼審查、動態測試手段的對比分析如表2.

表2 不同測試手段對比分析

綜上,各種測試手段各有千秋,在工程上,尤其是對于高可信高可靠航天嵌入式軟件而言,應該多種手段并舉,充分發揮各自的優勢,形成優勢互補,共同促進軟件質量的提升.

2.5 工程適用性說明

綜合以上分析結果,總結代碼審查的工程適用性如下:

(1)在測試環境受限、測試工期有限等不適宜開展動態測試的情況下,由中-高級測試人員開展代碼審查.比如,型號軟件的初樣研制階段.

(2)在具有高可信高可靠要求、且規模允許的軟件測試中,必須開展代碼審查.

3 結束語

隨著自動化測試以及工具檢測相關研究的熱度的提升,基于人工的代碼審查技術的研究及其在工程實踐中的推廣應用都陷入了瓶頸.但是,在當前自動化測試以及工具檢測能力都不足以保證航天嵌入式軟件質量的前提下,研究并應用人工代碼審查方法仍然是必要的.而且,無論是工具的研發,還是工具能力的提升,都需要一定的出發點和參照點,而人的分析方法、分析范圍以及分析能力的提升,都為工具研發及能力提升提供了一個很好的參照,這也是當前條件下,堅持人工代碼審查方法研究及方法推廣的意義所在.

隨著軟件在航天器中的作用和地位越來越突出,軟件的可信性直接關系到航天任務的成敗,不存在一種單獨的方法能夠完全保證軟件可信[19].NASA 從多年的軟件工程中吸取的一個重要教訓是沒有一個單一的解決方法能夠解決所有問題[25].因此,為滿足航天嵌入式軟件的可信性要求,需要廣大的工程技術人員在軟件研制各階段綜合采用各種技術和方法.只有這樣,才能將各種技術和方法的研究與應用不斷地推向新的高度.

本文的研究成果對于軟件研制、動態測試、測試工具研發均有一定的參考價值.后續將重點研究如何將研究成果推廣至工具研發,以期最大限度地提升缺陷自動化檢測能力,促進多種測試手段的互補與并舉.