梁鴻煜， 燕 飛

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

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

梁鴻煜1， 燕 飛2

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

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

城市軌道交通； 自動列車監(jiān)控； 驗證； V模型

1 發(fā)展概況

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

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

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

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

2 ATS系統(tǒng)概述

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

圖2 越南河內(nèi)線ATS調(diào)度工作站車輛段站場圖Fig.2 The depot map of ATS scheduling workstation of Hanoi, Vietnam

3 全生命周期驗證方法

3.1 需求分析階段驗證

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

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

3.1.1 標桿比較

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

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

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

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

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

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

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

3.1.2 專家評審

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

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

3.1.3 檢查表

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

清晰性：

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

追溯性：

需求是可跟蹤的嗎？

完整性：

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

?

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

3.1.4 追溯矩陣

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

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

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

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

3.2 設計實現(xiàn)階段驗證

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

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

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

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

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

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

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

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

3.3 測試階段驗證

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

表1 根據(jù)SIL等級的建議測試方法

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

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

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

3.4 變更驗證

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

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

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

4 結語

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

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

[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] 中國城市軌道交通軌道技術裝備專業(yè)委員會.城市軌道交通CBTC信號系統(tǒng):ATS子系統(tǒng)規(guī)范: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] 陳俊強. 基于數(shù)據(jù)驅動的ATS系統(tǒng)功能測試方法研究[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] 地鐵設計規(guī)范:GB 50157—2013[S].北京: 中國建筑工業(yè)出版社,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)系統(tǒng)的性能和功能要求：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

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

U231

A

1672-6073(2017)03-0035-05