基于V模型的ATS軟件驗證方法研究

梁鴻煜， 燕 飛

(1. 交控科技股份有限公司， 北京 100070; 2. 北京交通大學電子信息工程學院, 北京 100044)

基于V模型的ATS軟件驗證方法研究

梁鴻煜1， 燕 飛2

(1. 交控科技股份有限公司， 北京 100070; 2. 北京交通大學電子信息工程學院, 北京 100044)

軌道交通信號系統必須經過嚴格的驗證才能進入工程應用。以ATS自動列車監控系統軟件為例，研究信號系統在生命周期V模型下的驗證方法，把開發周期簡要劃分為需求分析、設計實現、測試驗證3個階段，用以論述驗證活動，闡述在產品生命周期各個階段采用如評審、追溯分析、測試分析等不同驗證方法，從而更大程度地保證系統的正確性。說明ATS系統的驗證活動是一個龐大的工程，在產品開發生命周期的各個階段都應執行充分的驗證活動，收集足夠的客觀證據證明產品各個階段的輸出滿足需求。

城市軌道交通； 自動列車監控； 驗證； V模型

1 發展概況

在軌道信號系統的招標文件和采購合同中，都明確要求，信號系統應符合國際國內行業標準。如國際鐵路行業標準(IRIS)和中華人民共和國國家標準質量管理體系(GB/T 19001—2008)中都明確要求，產品應通過全生命周期的驗證。系統或軟件的驗證是指對一個系統或產品評價的過程活動，以確定一個給定階段的輸出是否滿足該階段開始時所給定的要求。當前，國產信號系統發展獲得廣泛的工程應用，然而對信號系統的驗證活動相對缺乏[1-2]。因此，筆者以自動列車監控系統(automatic train control system，ATS)為例，總結地鐵信號系統的驗證方法，旨在探索業內空白，并對其他信號系統的驗證活動提供參考。本文以獲得英國勞氏鐵路認證，并成功應用于北京地鐵7號線的ATS系統軟件為例。

ATS系統的驗證活動是一個龐大的工程，在產品開發生命周期的各個階段都應執行充分的驗證活動，ATS系統的安全完善度(safety integrity level，SIL)等級根據安全分析被定義為2級，因此應按照SIL2的標準對ATS系統進行驗證活動。安全生命周期應參考EN 50126標準中的系統周期定義，并與產品項目中定義的系統生命周期相一致。系統生命周期中的設計和確認部分可看作一個自上而下階段并伴隨一個自下而上的階段(如V型)[3-4]。信號系統的生命周期經常采用圖1的V模型，V模型可作為信號系統的一個通用模型，由于軟件規模以及開發周期歷時等原因，通常對生命周期的階段進行合并，本文把開發周期簡要劃分為需求分析、設計實現、測試驗證3個階段，用以論述驗證活動。

參考圖1，需求分析階段包括用戶/系統/子系統/軟件需求分析活動；設計實現階段包括軟件架構設計、軟件詳細設計、編碼實現活動；測試階段則包括V模型右半邊的代碼走查、軟件單元測試、軟件集成測試、軟件確認測試、系統測試等活動。

圖1 生命周期V模型Fig.1 V-type model of the life cycle

2 ATS系統概述

自動列車監控系統是列車自動控制系統(automatic train control system, ATC)的重要子系統之一，是一套提供給運營調度人員進行在線監測行車狀態、進行自動控制和人工干預的信號系統。一方面，ATS通過其他信號子系統獲得現場信號設備和列車運行的實時狀態信息，并把這些信息如實地展示給調度人員進行站場狀態監視；另一方面，ATS還提供了人機交互界面，方便調度人員根據現場情況實時進行人工控制。針對不同的控制級別，ATS提供不同的自動化控制手段，從而減輕運營調度人員的作業負擔，提高運輸效率和服務水平。其主要功能包括：站場信息顯示、信號控制、列車追蹤和控制、控制區域管理、運行圖管理、報警/日志管理、其他輔助功能[5](見圖2)。

圖2 越南河內線ATS調度工作站車輛段站場圖Fig.2 The depot map of ATS scheduling workstation of Hanoi, Vietnam

3 全生命周期驗證方法

3.1 需求分析階段驗證

驗證活動首先要保證需求的正確性和完備性。本階段驗證活動應強調：需求分析的正確性與完備性、需求的可追溯性、需求的可測性。

需求驗證通常采用的方法是標桿比較、專家評審、檢查表和追溯矩陣。

3.1.1 標桿比較

信號系統的需求通常來自于國際國內的行業標準以及運營的特殊要求。標桿比較則是將初步提取的需求與行業標準、業內先進經驗進行比較，從而分析出遺漏與不足，改進自身需求的過程。

以ATS系統為例，2015年中國城市軌道交通軌道技術裝備專業委員會發布了《城市軌道交通CBTC信號系統——ATS子系統規范》，作為歸納總結后的需求規范，可作為重要的參考。信號系統的其他產品可參考相應的子系統規范、IEEE的CBTC性能功能需求以及其他行業設計規范、法規。安全系統還需要參考安全評價標準，如歐洲電氣標準委員會定義的(CENELEC)基于IEC 61508標準制定的軌道交通系統開發和安全評價的4個參考標準[6]：

1) EN 50126鐵路應用：可靠性、可用性、可維護性和安全性(RAMS)規范和說明。

2) EN 50128鐵路應用：通信、信號和處理系統，鐵路控制和防護系統用軟件。

3) EN50129鐵路應用：通信、信號傳輸和處理系統，信號傳輸用于電子系統的安全。

4) EN 50159鐵路應用：通信、信號和處理系統。

由于ATS系統直接提供給調度人員直觀的人機交互界面，因此不同的運營線路常常有不同的需求。例如，北京地鐵2號線全程都是地下車站，而北京地鐵7號線有地上、地下兩種類型的車站，則需要ATS系統在站場顯示時新增地標顯示功能，用以區別地上或地下車站。因此，在驗證需求時，不僅需要參考標準，還需要參考合同文件及其他附屬技術聯絡會議文件等，根據實際情況進行調整，以滿足特定用戶的需求。

3.1.2 專家評審

專家評審是保障需求正確性的重要手段。在產品需求經過內部評審后正式定稿前，驗證人員應組織專家評審，對需求進行二次檢查。專家評審通常以會議的形式進行，邀請行業專家參會評審。

通常事先將相關材料發放給專家，或是直接在會上采取頭腦風暴的方法進行專家提問。ATS系統的專家評審會應邀請業內專家、運營調度人員或用戶代表、項目經理、產品經理、驗證和確認人員。在專家評審過程中，產品經理應起主導作用：闡述產品需求、記錄專家評審意見、進行解釋說明、進行整改記錄，最終獲取專家認可。在專家評審會最終應達成專家評審意見，獲取專家對需求的認可，并進行簽字確認。

3.1.3 檢查表

在EN 50129 表E9中，對SIL2級的產品強烈推薦使用檢查表的方式進行驗證。不僅是產品需求，產品生命周期的所有文檔都應進行文檔檢查。通常在企業標準中會制定相應的檢查表。以下以產品需求為例，說明檢查的內容。產品需求的檢查項，包括且不限于以下方面。

清晰性：

是否存在有理解分歧的需求?需求是明確、準確和清晰的嗎?是否每個需求都是切實可行的?

追溯性：

需求是可跟蹤的嗎？

完整性：

是否所有的需求都被完整地定義了?是否包括了與功能性相關的所有需求?是否包括了與性能相關的所有需求?是否包括了與外部接口相關的所有需求?是否包括了與數據庫相關的所有需求?是否包括了與硬件相關的所有需求?

?

不同的軟件文檔應制定不同的產品文檔檢查表模板，進行針對性的檢查。

3.1.4 追溯矩陣

在信息系統中，通常關注需求的分配基線，而系統架構說明書則是分配基線的直觀體現。在系統架構中，通常把系統的功能需求進行羅列，劃分到各個子系統需求中，再由子系統需求分配到軟硬件需求，再到概要設計、詳細設計，最后通過編碼實現。在ATS產品中，通常以調度人員的各個操作工作站為基礎，進行劃分子系統。常見的有計劃/編圖工作站、維護工作站、調度工作站、派班工作站、值班工作站、網關計算機、現地工作站等子系統。在對分配基線進行驗證時，主要采取的手段是追溯矩陣。追溯的目的是保證所有的需求都能正確實現，且不存在不可追溯的內容，追溯需要達到雙向的100%覆蓋，即常說的雙百覆蓋。

信號系統采取結構化的設計方法，因此對需求的分配也是至上而下。如，產品需求分配到子系統需求應保證100%，從而確保產品需求沒有遺漏；其次，子系統需求應追溯產品需求，保證沒有多余的需求。軟硬件需求、概要/詳細設計，代碼同樣需要遵循這個原則，進行雙百覆蓋，保證產品線縱向的一致性。

在這個過程中，從上至下常常是一對多的關系。比如通用的站場顯示的需求，需要分配到調度工作站子系統，也需要分配到現地工作站子系統。在需求分配時，則需要考慮到該條需求是否全部分配到對應的子系統中去。

在驗證活動中，軟件需求應完全滿足需求，確保需求得到滿足，開發人員對此與驗證人員容易達成一致。比較有分歧的一點是，是否可以存在設計大于需求的情況。通常研發人員出于更全面的考慮，分析出來的某條需求，無法向上層需求進行追溯。然而，這樣的設計通常不被驗證人員接受。首先，多余的需求可能會造成額外的故障；其次，可能會被認為是產品的固定附加值：假設北京地鐵獲得了一個錦上添花的功能，上海地鐵在考察時，覺得該功能不錯進行了采購，結果卻未獲得該功能，則容易引起合同分歧。

3.2 設計實現階段驗證

為確保設計和開發輸出滿足輸入要求，應依據所策劃的安排對設計和開發進行驗證。驗證結果及任何必要措施的記錄應予保持。在設計階段同樣應采取追溯的方法。

在軟件概要設計階段，驗證工作將強調：驗證軟件概要設計的正確性；確認軟件概要設計對軟件需求覆蓋的完備性；確認軟件集成測試用例作為軟件概要設計一系列測試案例的充分性。

在完成軟件概要設計后，驗證人員應組織相關人員對軟件概要設計進行審查，主要審查設計方案與主要算法的可行性和先進性，以及接口設計的性能和軟件運行環境的恰當性，從而論證概要設計的正確性和可行性；此外應對每個軟件實施概要設計追溯分析，在這項活動中，軟件概要設計應追溯軟件需求，軟件集成測試用例應追溯軟件概要設計，從而論證軟件概要設計的完備性和可驗證性。

在軟件詳細設計階段，驗證工作將強調：確認軟件詳細設計對軟件概要設計覆蓋的完備性；確認軟件單元測試用例作為軟件詳細設計一系列測試案例的充分性。

在完成軟件詳細設計后，驗證活動分為2個階段：第1階段，驗證人員組織相關人員進行審查，評審軟件單元間的接口，包括共享外部數據，參數形式和傳送方式以及上下層調用關系，保證軟件每個單元輸入變量和輸出變量都能被明確定義；第2階段，采用追溯分析的方法保證軟件詳細設計到軟件概要設計的追溯，分析軟件單元功能與概要設計的一致性。

在代碼實現階段，驗證工作將強調：確認軟件代碼對詳細設計覆蓋的充分性和完備性；確認軟件確認測試用例作為軟件需求一系列測試案例的充分性。

在軟件編碼活動完成后，驗證人員應實施驗證活動以保證代碼的正確性、完備性及可用性。首先，采用人工走查的方法對軟件的代碼進行審查，組織相關人員提出意見或缺陷；然后使用代碼走查工具對代碼進行規則檢查，進一步確保軟件代碼的正確性和規范性；最后，通過建立軟件代碼與詳細設計的追溯矩陣，保證軟件代碼對詳細設計覆蓋的充分性，且所有軟件代碼都能追溯軟件詳細設計，并且沒有冗余代碼。如果以上幾種方式都可以通過，那么該代碼即可發布，進行正式的配置管理；若存在問題，則需要進行整改。

在ATS系統中，較為特殊的是涉及多個公共模塊。例如，在調度工作站、現地工作站、派班工作站等都會涉及操作日志記錄、報警信息顯示等這類公用模塊，因此在軟件實現的時候較為合理的是開發公共模塊，應用軟件通過調用公共模塊實現產品功能。因此，在進行追溯分析時，應考慮模塊應用的一致性以及模塊的追溯。

3.3 測試階段驗證

軟件測試是驗證產品正確性的重要手段。在測試階段，廣義的驗證包括測試活動本身，狹義的驗證則僅指測試審核的過程。本文中的驗證指的是狹義的驗證。由于ATS系統的安全完善度等級定義為SIL2，因此，需要按照EN 50128：2011的標準執行測試。在EN 50128：2011Table A.5-Verification and Testing 中對SIL2的功能測試進行了要求[6-12]，其中靜態分析、動態分析/測試、功能/黑盒測試、性能測試、接口測試都是強烈推薦(HR)，而靜態分析、動態分析/測試和功能測試則是必做其一。因此，在測試活動策劃初期，驗證就應該介入，檢查這些測試活動是否完備(見表1)。

表1 根據SIL等級的建議測試方法

實際上，軟件的SIL等級是根據功能來劃分的。ATS系統定義為SIL2級則是按功能的SIL2等級定義。由于ATS是一個龐大的信息系統，除了安全功能外，還有許多非安全功能。對于SIL0的模塊，功能測試、接口測試是強烈推薦，因此驗證員也需要關注這些SIL0的模塊是否進行了功能測試和接口測試。由于ATS系統軟件直接參與運營活動，因此SIL0模塊的白盒測試，在條件允許的情況下仍建議進行，從而保證提供給用戶高質量的產品。由于ATS是ATC的重要組成子系統，因此，ATS通常會與ATC的其他子系統有信息交互，比如來自CI(計算機聯鎖)的站場信息、來自VOBC(車載控制器)的車輛信息、來自DSU(數據庫存儲單元)的限速信息等。ATS必須通過與這些系統的接口測試才能正確實現產品功能，所以系統對外的接口測試不區分SIL等級，都是必不可缺的。

在傳統自動駕駛模式(AM)下，ATS的安全功能涉及臨時限速、道岔強扳和計軸復位；在全自動駕駛模式(FAM)下，安全功能還涉及雨雪模式、火災聯動等。對于這些影響行車安全的功能主程序以及邏輯處理層，建議進行黑白盒測試，而不是僅選擇歐標列出的最低標準；對于其他非安全模塊，可以根據實際情況酌情刪減，比如日志記錄、報警等僅需做功能測試和接口測試，代碼走查、單元測試則需要考慮投入的性價比。

在EN 50128中，將靜態分析作為驗證的手段，實際上靜態分析作為測試手段更為恰當。靜態分析可分為桌前檢查(程序員自己檢查)、內部走查(測試人員獨自檢查)和外部走查(測試人員與程序員一起檢查)，選用哪種方式取決于代碼量、程序的復雜程度、測試人員對代碼的理解程度。但常見的活動是由獨立研發的白盒測試人員直接測試代碼正確性，而驗證人員對比活動進行二次檢查。驗證活動在本階段主要是檢查測試的代碼覆蓋率、用例的執行率，測試活動的充分性以論證產品的正確性。

3.4 變更驗證

在V模型中，變更活動始終貫穿于產品開發的生命周期中。信號系統屬于慢迭代穩定系統，因此對變更的控制具有嚴格要求。如果發生變更，驗證活動則需要被重復實施。通過對需求、設計、測試活動重復進行驗證，給出審核結論，保證變更后的系統仍具有正確性和一致性。

在變更驗證過程中，驗證人員應重點關注：變更完成是否與變更申請一致；變更是否可追溯；變更是否可驗證；變更是否測試驗證通過。

以ATS系統為例，在不同的工程項目中應用，通常需要對通用產品進行特殊應用開發。V模型的一個重大優越性在于變更的控制，而信號系統產品生命周期內的變更無法避免，因此對變更的驗證同樣重要。

4 結語

綜上所述，ATS系統需要經過充分的驗證活動，收集足夠的客觀證據證明產品各個階段的輸出滿足需求。盡管在驗證活動中，驗證員通常需要反復提出意見要求整改，但是驗證活動的初衷絕不是找出系統的錯誤，而是搜集系統正確的證據，從而提供給產品生成方、評估方乃至產品使用者充足的信心。因此，驗證員所扮演的絕不是一個挑毛病的角色，而是幫助產品趨于完善。

本文以ATS系統為例對驗證活動進行研究，對于其他SIL2的信號系統，如冗余ATO(列車自動駕駛系統)可參考本驗證方法，SIL等級較高的CI(計算機聯鎖)、ATP(列車自動保護裝置)等，則需要更加嚴格的驗證活動，從而更大限度地保證產品的正確性。

[1] 燕飛,郜春海,唐濤.軌道交通信號工程安全管理與認證模式[J].都市快軌交通,2011,24(4):12-16.

YAN Fei,GAO Chunhai,TANG Tao.Safety management and authentication modes for a rail transit signaling engineering project [J].Urban rapid rail transit, 2011, 24(4):12-16.

[2] 燕飛,唐濤,郜春海.城市軌道交通安全評價體系研究[J].都市快軌交通,2010,23(3):32-36.

YAN Fei,TANG Tao,GAO Chunhai.Esearch on safety assessment framework for urban rail transit[J].Urban rapid rail transit, 2010, 23(3):32-36.

[3] 中國城市軌道交通軌道技術裝備專業委員會.城市軌道交通CBTC信號系統:ATS子系統規范:CZJS/T 0030—2015[S].北京,2015.

CAMET.ATS subsystem specification:CBTC signal system for urban rail transit:CZJS/T 0030—2015[S].Beijing, 2015.

[4] 陳俊強. 基于數據驅動的ATS系統功能測試方法研究[J].鐵路通信信號工程技術，2016，13(2)：70-73.

CHEN Junqiang. Research on ATS function testing method based on data driven[J]. Railway signal & communication engineering, 2016, 13(2):70-73.

[5] 地鐵設計規范:GB 50157—2013[S].北京: 中國建筑工業出版社,2014.

Code for design of metro: GB 50157—2013[S].Beijing: China Architecture & Building Press, 2014.

[6] STEVEN R R.Software verification and validation for practitioners and managers[J].Artech house,Inc.,2001(2): 44-45.

[7] Railway application:Communication, signalling and processing systems：software for railway control and protection systems: EN 50128: 2011[S].CENELEC, 2011.

[8] Railway applications：Communication, signalling and processing systems：safety related electronic systems for signaling: EN 50129: 2003[S].CENELEC, 2003.

[9] 基于通信的列車控制(CBTC)系統的性能和功能要求：IEEE Std.1474.1—2004[S].IEEE-SA Standards Board,2004.

Communications-based train control (CBTC) performance and functional requirements:IEEE standard 1474.1—2004[S].IEEE-SA Standards Board,2004.

[10] International railway industry standard:IRIS: 2009 V02 [S].UNIFE, 2009.

[11] Guide for software verification and validation plans:IEEE Std 1059—1993[S].IEEE,1993.

[12] Standard for software verification and validation:IEEE Std 1012—1998[S].IEEE-SA Standards Board,1998.

(編輯：郝京紅)

Using V-model Method for Verifying ATS Software

LIANG Hongyu1， YAN Fei2

(1. Traffic Control Technology Co., Ltd., Beijing 100070; 2. School of Electronic and Information Engineering, Beijing Jiaotong University, Beijing 100044)

The signal system must be thoroughly examined before it can be applied in engineering. Taking the automatic train supervision system (ATS) as an example, this paper attempts to investigate the verification method used for the signal systems under the lifecycle of V-model. The development cycle is divided into 3 stages, including requirement analysis, design implementation and test verification, in order to demonstrate the validation activities. The model is divided into different stages with varied methods used in each stage of a product′s lifecycle, including assessment, traceability analysis and test analysis, to ensure a higher degree of accuracy of the system. Description of ATS system validation activities is a huge project, all validation activities should be performed at all stages of the product development lifecycle, and collecting sufficient objective evidence should be done to demonstrate that the output of each stage of the product meets the requirements.Keywords: urban rail transit; ATS; verification; V-model

10.3969/j.issn.1672-6073.2017.03.007

2016-07-19

2016-10-08

梁鴻煜，女，本科，系統保證工程師，專業方向為信號系統驗證與確認應用，lhysmile@foxmail.com

U231

A

1672-6073(2017)03-0035-05