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

梁鴻煜， 燕 飛

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

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

梁鴻煜1， 燕 飛2

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

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

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

1 發(fā)展概況

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

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

參考圖1，需求分析階段包括用戶/系統(tǒng)/子系統(tǒng)/軟件需求分析活動；設(shè)計實現(xiàn)階段包括軟件架構(gòu)設(shè)計、軟件詳細(xì)設(shè)計、編碼實現(xiàn)活動；測試階段則包括V模型右半邊的代碼走查、軟件單元測試、軟件集成測試、軟件確認(rèn)測試、系統(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)度人員進(jìn)行在線監(jiān)測行車狀態(tài)、進(jìn)行自動控制和人工干預(yù)的信號系統(tǒng)。一方面，ATS通過其他信號子系統(tǒng)獲得現(xiàn)場信號設(shè)備和列車運行的實時狀態(tài)信息，并把這些信息如實地展示給調(diào)度人員進(jìn)行站場狀態(tài)監(jiān)視；另一方面，ATS還提供了人機交互界面，方便調(diào)度人員根據(jù)現(xiàn)場情況實時進(jìn)行人工控制。針對不同的控制級別，ATS提供不同的自動化控制手段，從而減輕運營調(diào)度人員的作業(yè)負(fù)擔(dān)，提高運輸效率和服務(wù)水平。其主要功能包括：站場信息顯示、信號控制、列車追蹤和控制、控制區(qū)域管理、運行圖管理、報警/日志管理、其他輔助功能[5](見圖2)。

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

3 全生命周期驗證方法

3.1 需求分析階段驗證

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

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

3.1.1 標(biāo)桿比較

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

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

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

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

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

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

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

3.1.2 專家評審

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

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

3.1.3 檢查表

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

清晰性：

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

追溯性：

需求是可跟蹤的嗎？

完整性：

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

?

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

3.1.4 追溯矩陣

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3 測試階段驗證

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

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

實際上，軟件的SIL等級是根據(jù)功能來劃分的。ATS系統(tǒng)定義為SIL2級則是按功能的SIL2等級定義。由于ATS是一個龐大的信息系統(tǒng)，除了安全功能外，還有許多非安全功能。對于SIL0的模塊，功能測試、接口測試是強烈推薦，因此驗證員也需要關(guān)注這些SIL0的模塊是否進(jìn)行了功能測試和接口測試。由于ATS系統(tǒng)軟件直接參與運營活動，因此SIL0模塊的白盒測試，在條件允許的情況下仍建議進(jìn)行，從而保證提供給用戶高質(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的安全功能涉及臨時限速、道岔強扳和計軸復(fù)位；在全自動駕駛模式(FAM)下，安全功能還涉及雨雪模式、火災(zāi)聯(lián)動等。對于這些影響行車安全的功能主程序以及邏輯處理層，建議進(jìn)行黑白盒測試，而不是僅選擇歐標(biāo)列出的最低標(biāo)準(zhǔn)；對于其他非安全模塊，可以根據(jù)實際情況酌情刪減，比如日志記錄、報警等僅需做功能測試和接口測試，代碼走查、單元測試則需要考慮投入的性價比。

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

3.4 變更驗證

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

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

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

4 結(jié)語

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

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

[1] 燕飛,郜春海,唐濤.軌道交通信號工程安全管理與認(rèn)證模式[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] 中國城市軌道交通軌道技術(shù)裝備專業(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ù)驅(qū)動的ATS系統(tǒng)功能測試方法研究[J].鐵路通信信號工程技術(shù)，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] 地鐵設(shè)計規(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)驗證與確認(rèn)應(yīng)用，lhysmile@foxmail.com

U231

A

1672-6073(2017)03-0035-05