(中央宣傳部電影技術質(zhì)量檢測所 檢測認證中心，北京 100086)

1 引言

近年來，點播影院作為商業(yè)影院互補業(yè)態(tài)，發(fā)展迅猛，據(jù)不完全統(tǒng)計，以點播方式提供電影放映服務的各類營業(yè)場所已超過萬家，但其運營管理水平良莠不齊，行業(yè)發(fā)展狀況較為混亂。2019年5月28日,《跨省點播院線審批服務指南》和《點播影院暫行技術規(guī)范》(以下簡稱《規(guī)范》)正式發(fā)布。《規(guī)范》包括點播影院的系統(tǒng)架構(gòu)、發(fā)行版和安全級別、計費系統(tǒng)數(shù)據(jù)上報、放映質(zhì)量、設備等六個方面的技術要求，其內(nèi)容基本涵蓋了點播影院相關系統(tǒng)各項軟硬件的要求，并具有相應的測量方法?！兑?guī)范》的發(fā)布，從技術上落實了規(guī)范點播影院市場、保護內(nèi)容版權、保證點播影院放映質(zhì)量的管理思路。

政策層面不斷加強對點播影院的規(guī)范引導，表明了國家對電影播映新模式發(fā)展的鼓勵與支持，也預示著點播影院市場將拉開體系化、規(guī)范化的序幕。而放映許可證等證照齊全、片源正版化、放映設備和計費系統(tǒng)等軟硬件合規(guī)化是點播影院規(guī)范化建設的重點內(nèi)容。點播院線計費系統(tǒng)作為點播影院票房統(tǒng)計最主要的數(shù)據(jù)來源，其規(guī)范符合性檢測的重要性不言而喻。

2 檢測概述

《規(guī)范》對點播院線計費系統(tǒng)數(shù)據(jù)上報的要求，分為基本規(guī)則、業(yè)務功能要求、數(shù)據(jù)備份與恢復、安全保證四個部分。對點播院線計費系統(tǒng)的規(guī)范符合性檢測，即按照這四個部分的要求來進行。對于《規(guī)范》未作要求的點播院線計費系統(tǒng)的功能，不進行檢測，但這些功能有可能成為檢測的支撐。

依據(jù)《規(guī)范》，對點播院線計費系統(tǒng)進行檢測時，檢測機構(gòu)需提供一個已通過驗證的檢測工具——全國點播影院經(jīng)營管理信息系統(tǒng)模擬器，被測點播院線計費系統(tǒng)通過互聯(lián)網(wǎng)或者局域網(wǎng)與全國點播影院經(jīng)營管理信息系統(tǒng)模擬器連接，同時，被測點播院線計費系統(tǒng)需要至少三家與其匹配的點播影院系統(tǒng)作為數(shù)據(jù)支撐，因為點播院線計費系統(tǒng)自身并不產(chǎn)生票房數(shù)據(jù)，其僅是一個數(shù)據(jù)轉(zhuǎn)發(fā)的角色，所有的票房數(shù)據(jù)均來自于點播影院系統(tǒng)。因《規(guī)范》未對點播影院系統(tǒng)作出要求，也未對點播影院系統(tǒng)與點播院線計費系統(tǒng)的通訊作出要求，所以檢測機構(gòu)無法將點播影院系統(tǒng)作為檢測工具提供，需由被測點播院線計費系統(tǒng)的軟件廠商自行提供。點播院線計費系統(tǒng)的測量框圖如圖1所示。

圖1 點播院線計費系統(tǒng)測量框圖

檢測工具軟件全國點播影院經(jīng)營管理信息系統(tǒng)模擬器由服務端程序和Web端展示兩個部分組成。服務端程序為依據(jù)《規(guī)范》附錄C建立的點播院線計費系統(tǒng)信息數(shù)據(jù)接口服務平臺，能夠提供符合《規(guī)范》附錄C信息數(shù)據(jù)接口要求的通訊功能。檢測時，服務端程序運行為后臺服務程序，能夠自動接收被測點播院線計費系統(tǒng)發(fā)送的信息數(shù)據(jù)接口請求報文，并返回相應的響應報文，同時將通信報文存儲至數(shù)據(jù)庫；也能夠?qū)eb端生成的信息數(shù)據(jù)接口下行指令報文發(fā)送至被測點播院線計費系統(tǒng)，并接收被測點播院線計費系統(tǒng)返回的響應報文，同時將通信報文存儲至數(shù)據(jù)庫。

圖2 全國點播影院經(jīng)營管理信息系統(tǒng)模擬器測試軟件結(jié)構(gòu)

Web端為全國點播影院經(jīng)營管理信息系統(tǒng)模擬器的操作和展示界面。在Web端，可以維護檢測所需的基礎信息(包括院線信息、影院信息、影廳信息、節(jié)目信息等)，也可瀏覽檢測過程中產(chǎn)生的、由服務端程序存儲于數(shù)據(jù)庫中的所有報文信息及報文解析信息，還可操作生成對被測點播院線計費系統(tǒng)信息數(shù)據(jù)接口的下行指令報文，并存儲至數(shù)據(jù)庫，由服務端程序執(zhí)行發(fā)送操作。全國點播影院經(jīng)營管理信息系統(tǒng)模擬器測試軟件結(jié)構(gòu)如圖2所示。

為滿足《規(guī)范》“通訊安全”條款的要求，檢測時，全國點播影院經(jīng)營管理信息系統(tǒng)模擬器需配置服務器端證書，被測點播院線計費系統(tǒng)需配置相應的客戶端證書，證書由全國點播影院經(jīng)營管理信息系統(tǒng)統(tǒng)一制作、頒發(fā)。

《規(guī)范》中對于點播院線計費系統(tǒng)數(shù)據(jù)上報要求的條款及信息數(shù)據(jù)接口的要求，其中很多內(nèi)容都與GY/T 276—2013《電影院票務管理系統(tǒng)技術要求和測量方法》標準(以下簡稱“276標準”)類似，相應的檢測方法也類似，276標準頒布時間較早，整套的檢測流程和檢測方法已非常成熟，因此本文在對點播院線計費系統(tǒng)的檢測進行描述時，會與276標準相應的內(nèi)容做比較說明。

3 檢測重點內(nèi)容解析

按照《規(guī)范》的要求，點播院線計費系統(tǒng)的檢測可以分為下載和上報兩大主要內(nèi)容，而下載和上報的通訊基礎由“通訊安全”條款所規(guī)定，“影院編碼”“節(jié)目編碼”條款的要求是服務于下載內(nèi)容的規(guī)則，“營業(yè)日期歸屬” “營業(yè)狀態(tài)” “營業(yè)場次” “場次人數(shù)”條款的要求是服務于上報內(nèi)容的規(guī)則，“數(shù)據(jù)備份與恢復”和“保存期限” “操作權限” “日志”等安全保證條款的要求則是軟件系統(tǒng)的常規(guī)功能。下載和上報兩個檢測的主要內(nèi)容，也基本覆蓋了《規(guī)范》附錄A、附錄B、附錄C的全部條款要求。本文以《規(guī)范》中的下載、上報、營業(yè)日期歸屬、營業(yè)狀態(tài)作為點播院線計費系統(tǒng)規(guī)范符合性檢測的重點內(nèi)容進行解析，而“數(shù)據(jù)備份與恢復”和“保存期限” “操作權限” “日志”等安全保證條款的檢測較為常規(guī)，對照《規(guī)范》中的檢測方法完全可自行操作，本文不再贅述。

點播院線計費系統(tǒng)的下載和上報通過信息數(shù)據(jù)接口完成，《規(guī)范》附錄C定義了信息數(shù)據(jù)接口的通訊協(xié)議、通訊機制、報文結(jié)構(gòu)。通訊協(xié)議要求為，在傳輸層采用符合RFC 793標準的TCP協(xié)議；鏈路安全采用符合RFC 2246的TLS 1.0版本雙向驗證方式；采用長連接方式，當連接斷開后重新連接應重新進行身份認證。通訊機制要求為，采用雙向異步通信實現(xiàn)雙向請求，采用停等和消息ID匹配機制，請求方請求數(shù)據(jù)中包含唯一消息ID，同一業(yè)務數(shù)據(jù)消息多次重發(fā)時要保證消息ID不變；如果報文發(fā)送后30秒無對應消息ID響應報文，發(fā)送端可重發(fā)報文，發(fā)送方累計發(fā)送3個報文沒有收到響應則認為鏈路斷開，應斷開連接重新連接后重新發(fā)送。《規(guī)范》附錄C共定義了7組、16個報文結(jié)構(gòu)，與276標準相比，報文結(jié)構(gòu)數(shù)量有所減少，但報文結(jié)構(gòu)定義類似。

3.1 下載

點播院線計費系統(tǒng)的下載分為影院編碼下載和節(jié)目編碼下載，影院編碼下載所涉及的報文結(jié)構(gòu)為0xC4影院信息請求數(shù)據(jù)結(jié)構(gòu)、0xC5影院信息數(shù)據(jù)結(jié)構(gòu)、0xC6影院信息確認數(shù)據(jù)結(jié)構(gòu)，節(jié)目編碼下載所涉及的報文結(jié)構(gòu)為0xC7節(jié)目信息下載請求數(shù)據(jù)結(jié)構(gòu)、0xC8節(jié)目信息數(shù)據(jù)結(jié)構(gòu)、0xC9節(jié)目信息確認數(shù)據(jù)結(jié)構(gòu)。

影院編碼下載和節(jié)目編碼下載的規(guī)范符合性檢測主要從通訊協(xié)議、通訊機制、報文結(jié)構(gòu)以及數(shù)據(jù)正確性等方面進行驗證。被測點播院線計費系統(tǒng)要以文件軟證書為基礎實現(xiàn)TLS 1.0雙向驗證方式的安全長連接鏈路，要實現(xiàn)能夠支持雙向請求的雙向異步通信，要實現(xiàn)停等和消息ID匹配機制。這些要求也適用于上報的檢測。

檢測時，在全國點播影院經(jīng)營管理信息系統(tǒng)模擬器中維護好可供下載的影院信息和節(jié)目信息，被測點播院線計費系統(tǒng)連接至全國點播影院經(jīng)營管理信息系統(tǒng)模擬器后，從其上下載影院信息和節(jié)目信息。操作完成后，以全國點播影院經(jīng)營管理信息系統(tǒng)模擬器服務端的接收請求報文和返回響應報文來驗證被測點播院線計費系統(tǒng)通訊協(xié)議、通訊機制的規(guī)范符合性，以模擬器Web端的報文瀏覽和報文解析來驗證被測點播院線計費系統(tǒng)報文結(jié)構(gòu)的規(guī)范符合性及數(shù)據(jù)正確性。

此外，檢測要對《規(guī)范》中“影院編碼下載”和“節(jié)目編碼下載”條款要求的內(nèi)容進行功能驗證，被測點播院線計費系統(tǒng)不允許人工輸入和修改點播影院編碼、節(jié)目編碼，不允許有其他方式的影院編碼和節(jié)目編碼來源。

3.2 上報

點播院線計費系統(tǒng)的上報分為原始場次數(shù)據(jù)上報和統(tǒng)計營業(yè)數(shù)據(jù)上報。原始場次數(shù)據(jù)上報所涉及的報文結(jié)構(gòu)為0xCC原始場次數(shù)據(jù)上報數(shù)據(jù)結(jié)構(gòu)、0xCD原始場次數(shù)據(jù)上報確認反饋數(shù)據(jù)結(jié)構(gòu)，統(tǒng)計營業(yè)數(shù)據(jù)上報所涉及的報文結(jié)構(gòu)為0xCE統(tǒng)計營業(yè)數(shù)據(jù)上報數(shù)據(jù)結(jié)構(gòu)、0xCF統(tǒng)計營業(yè)數(shù)據(jù)上報確認反饋數(shù)據(jù)結(jié)構(gòu)。

檢測時，被測點播院線計費系統(tǒng)接收所屬點播影院系統(tǒng)上報來的原始場次數(shù)據(jù)，接收后10分鐘內(nèi)，要自動上報至全國點播影院經(jīng)營管理信息系統(tǒng)模擬器；在每日6∶00至14∶00之間，被測點播院線計費系統(tǒng)要將其所屬所有點播影院經(jīng)營數(shù)據(jù)匯總，以點播影院和營業(yè)日為單位完成前一營業(yè)日的統(tǒng)計上報。操作完成后的驗證與下載的檢測一致。

此外，檢測要對《規(guī)范》中“數(shù)據(jù)上報”條款要求的內(nèi)容進行功能驗證。被測點播院線計費系統(tǒng)的原始上報要在收到點播影院上報的原始場次數(shù)據(jù)后10分鐘內(nèi)完成向全國點播影院經(jīng)營管理信息系統(tǒng)模擬器上報；非正常營業(yè)狀態(tài)的影院也要按照《規(guī)范》附錄C的格式要求上報原始場次數(shù)據(jù)。被測點播院線計費系統(tǒng)的統(tǒng)計上報要有補報能力，補報要按照從早到晚的時間順序進行；非正常營業(yè)狀態(tài)的影院也要按照《規(guī)范》附錄C的格式要求上報統(tǒng)計營業(yè)數(shù)據(jù)；向全國點播影院經(jīng)營管理信息系統(tǒng)模擬器上報的統(tǒng)計營業(yè)數(shù)據(jù)必須是被測點播院線計費系統(tǒng)所屬點播影院的全部經(jīng)營數(shù)據(jù)；上報的統(tǒng)計營業(yè)數(shù)據(jù)為已經(jīng)扣除退票退場數(shù)據(jù)后的最終數(shù)據(jù)。這些功能在數(shù)據(jù)正確性方面也需要通過全國點播影院經(jīng)營管理信息系統(tǒng)模擬器Web端的報文瀏覽和報文解析來驗證。盡管在《規(guī)范》條款中未作說明，檢測時，我們還是要求點播院線計費系統(tǒng)的原始上報有補報能力。

3.3 營業(yè)日期歸屬

“營業(yè)日期”和“營業(yè)場次時間”兩條款可以合并為一條進行檢測，我們可以稱之為“營業(yè)日期歸屬”的檢測。

檢測的前提條件：被測的點播院線計費系統(tǒng)要求接入一家點播影院即可，該點播影院要求至少具備三個影廳。檢測時，操作接入的點播影院的經(jīng)營管理系統(tǒng)，使其產(chǎn)生如圖3所示的場次數(shù)據(jù)。

圖3 營業(yè)日期歸屬檢測場次數(shù)據(jù)示意

因《規(guī)范》“營業(yè)日期”條款規(guī)定為“當日上午6∶00至次日上午6∶00(不含次日上午6∶00)”，“營業(yè)場次時間”條款規(guī)定為“營業(yè)場次包括開場時間和結(jié)束時間，根據(jù)場次結(jié)束時間所屬營業(yè)日確定場次的歸屬營業(yè)日；例：早5∶00開場場次，至早7∶00場次結(jié)束，則該場次營業(yè)日歸屬為7∶00所屬營業(yè)日”。所以，產(chǎn)生的場次數(shù)據(jù)的場次結(jié)束時間圍繞06∶00前后展開，而場次開始時間對于營業(yè)日期歸屬檢測來說無價值，圖中給出的場次開始時間值僅為示意，即，檢測以場次的結(jié)束時間為目標、以時間軸上的06∶00為臨界值來進行判定。

檢測結(jié)果的判定：因檢測過程中要形成原始場次數(shù)據(jù)上報和統(tǒng)計營業(yè)數(shù)據(jù)上報，而《規(guī)范》附錄C定義的統(tǒng)計營業(yè)數(shù)據(jù)上報數(shù)據(jù)結(jié)構(gòu)是按照營業(yè)日統(tǒng)計的數(shù)據(jù)進行上報，即上報的數(shù)據(jù)為單個營業(yè)日的所有場次的統(tǒng)計數(shù)據(jù)，且報文數(shù)據(jù)結(jié)構(gòu)中僅有“session_count”一個與場次信息有關的字段，再無其他場次相關信息。這一點與276標準不同，276標準定義的票房數(shù)據(jù)統(tǒng)計上報數(shù)據(jù)結(jié)構(gòu)是按照營業(yè)日內(nèi)每個場次統(tǒng)計的數(shù)據(jù)進行上報，且報文數(shù)據(jù)結(jié)構(gòu)中有“screen_code” “film_code” “session_code” “session_datetime”等與場次信息相關的多個字段，可以很清晰地判定營業(yè)日期場次的包含關系。因此，對于點播院線計費系統(tǒng)營業(yè)日期歸屬的檢測，在數(shù)據(jù)報文中沒有明確字段判定營業(yè)日期歸屬的情況下，需要產(chǎn)生的六個場次的觀影人數(shù)和包場費設置不同數(shù)量，使其兩兩相加的值不同，以觀影人數(shù)和包場費的合計值來判定營業(yè)日期包含的場次信息是否正確。

此外，在實際的檢測情況中，場次結(jié)束時間并不容易精確控制為“05∶59∶59” “06∶00∶00” “06∶00∶01”，此時，需要把握“06∶00∶00”前結(jié)束一場、“06∶00∶00”整結(jié)束一場、“06∶00∶00”后結(jié)束一場以及三場結(jié)束時間盡量靠近“06∶00∶00”的原則。

3.4 營業(yè)狀態(tài)

《規(guī)范》在“營業(yè)狀態(tài)”條款中，規(guī)定影院營業(yè)狀態(tài)包括測試(在點播影院開業(yè)前系統(tǒng)調(diào)試測試時標注為測試狀態(tài))、營業(yè)(點播影院正式開業(yè)后標注為營業(yè)狀態(tài))兩種狀態(tài)。但在附錄C信息數(shù)據(jù)接口的點播影院信息數(shù)據(jù)結(jié)構(gòu)定義中，影院營業(yè)狀態(tài)卻有“測試” “正常營業(yè)” “停業(yè)” “注銷”四種。

本文描述的規(guī)范符合性檢測，以四種影院營業(yè)狀態(tài)的定義展開。僅在“正常營業(yè)”狀態(tài)時，被測點播院線計費系統(tǒng)要以正常的經(jīng)營數(shù)據(jù)完成原始場次數(shù)據(jù)上報和統(tǒng)計營業(yè)數(shù)據(jù)上報。在“測試”“停業(yè)”“注銷”狀態(tài)，被測點播院線計費系統(tǒng)應認為點播影院為非正常營業(yè)狀態(tài)，要以附錄C原始場次數(shù)據(jù)上報數(shù)據(jù)結(jié)構(gòu)中定義的“非正常營業(yè)影院也需要上報，場次編碼為zzzzzzzzzzzzzzzzz，節(jié)目編碼為10000000000000，收入為0”規(guī)則完成原始場次數(shù)據(jù)上報，以附錄C統(tǒng)計營業(yè)數(shù)據(jù)上報數(shù)據(jù)結(jié)構(gòu)中定義的“非正常營業(yè)影院，上報場次、人數(shù)、收入均為0”規(guī)則完成統(tǒng)計營業(yè)數(shù)據(jù)上報，在“正常營業(yè)”狀態(tài)上報的統(tǒng)計營業(yè)數(shù)據(jù)中不包含“測試”狀態(tài)的數(shù)據(jù)。

影院營業(yè)狀態(tài)在實際檢測中存在不少問題，這會在本文后續(xù)部分再提及。

4 積極作用與存在問題

4.1 點播院線計費系統(tǒng)數(shù)據(jù)上報要求的積極作用

4.1.1 規(guī)范市場

《規(guī)范》對點播院線計費系統(tǒng)的數(shù)據(jù)上報、下載及其他必要功能做出了明確的技術要求，對數(shù)據(jù)上報、下載的通訊協(xié)議、通訊機制、報文結(jié)構(gòu)給出了約束規(guī)則，并提供了相應的檢測方法，使得軟件廠商對點播院線計費系統(tǒng)的研發(fā)有章可循，也使點播院線計費系統(tǒng)的檢測得以規(guī)?；_展，對于點播影院市場的規(guī)范化發(fā)展有著非常積極的作用。

4.1.2 云端部署方向

相比于276標準，《規(guī)范》的通訊安全摒棄了硬件USBKey，采用文件軟證書。如果采用硬件USBKey方案來保障通訊安全，在云端部署時，會面臨較大困難，云端部署的系統(tǒng)無法接入大量的硬件USBKey，一般采取的應對措施是在影院內(nèi)部再部署一臺通訊安全服務器，接入硬件USBKey，實現(xiàn)通訊安全，但會形成云端系統(tǒng)和影院端通訊安全服務器之間的多次數(shù)據(jù)交互。文件軟證書的方案則不存在這樣的問題，云端系統(tǒng)可以存儲和配置大量的文件軟證書，實現(xiàn)與硬件USBKey方案基本一致的通訊安全。采用文件軟證書的通訊安全方案不僅提高了軟件運行效率，也使得點播院線計費系統(tǒng)云端部署的趨勢進一步明朗。

4.1.3 接口統(tǒng)一

相比于276標準，《規(guī)范》將原始場次數(shù)據(jù)上報和統(tǒng)計營業(yè)數(shù)據(jù)上報統(tǒng)一在信息數(shù)據(jù)接口中，采用相同的通訊方式進行上報。在276標準中，原始數(shù)據(jù)上報采用TCP+TLS方式，統(tǒng)計數(shù)據(jù)上報采用HTTP+POST方式。對于軟件廠商來說，不同通訊方式的數(shù)據(jù)上報接口，雖然沒有多大的開發(fā)難度，但統(tǒng)一通訊方式的數(shù)據(jù)上報接口，總體而言是簡化了軟件廠商的研發(fā)工作。

4.1.4 接口報文匹配明確

相比于276標準，《規(guī)范》在信息數(shù)據(jù)接口報文結(jié)構(gòu)中，加入了“message_id”(消息ID)和“packet_id”(通訊報文ID)兩個字段?！兑?guī)范》附錄C要求，報文通信采用消息ID匹配機制，請求方請求數(shù)據(jù)中應包含唯一消息ID，同一業(yè)務數(shù)據(jù)消息多次重發(fā)時要保證消息ID不變。消息ID作為業(yè)務通信中請求、應答間對應消息的唯一標識，在一組業(yè)務多次交互過程中，交互雙方使用唯一的消息ID。增加的“message_id”字段，可使點播院線計費系統(tǒng)明確發(fā)送和接收報文的匹配情況。

4.2 點播院線計費系統(tǒng)數(shù)據(jù)上報要求在檢測中存在的問題

4.2.1 影院營業(yè)狀態(tài)問題

首先，在《規(guī)范》的“營業(yè)狀態(tài)”條款中，影院營業(yè)狀態(tài)僅定義有“測試” “營業(yè)”二種，但在附錄C信息數(shù)據(jù)接口的點播影院信息數(shù)據(jù)結(jié)構(gòu)定義中，影院營業(yè)狀態(tài)又有“測試” “正常營業(yè)” “停業(yè)” “注銷”四種，《規(guī)范》本身存在需要進一步完善的地方。

其次，影院營業(yè)狀態(tài)中的“測試”狀態(tài)設計初衷需要進一步明確，如果僅為點播院線計費系統(tǒng)被檢時使用，則可以刪除“測試”狀態(tài)。在《規(guī)范》中，有“院線系統(tǒng)上報數(shù)據(jù)時根據(jù)影院營業(yè)狀態(tài)進行上報，測試數(shù)據(jù)將不計入正常統(tǒng)計”的要求，又有“數(shù)據(jù)上報……非正常營業(yè)影院也應上報，上報格式在附錄C說明”的要求，附錄C中還有“原始場次數(shù)據(jù)上報數(shù)據(jù)結(jié)構(gòu)……非正常營業(yè)影院也需要上報，場次編碼為zzzzzzzzzzzzzzzzz，節(jié)目編碼為10000000000000，收入為0。全國點播影院經(jīng)營管理信息系統(tǒng)不接收測試數(shù)據(jù)”和“統(tǒng)計營業(yè)數(shù)據(jù)上報數(shù)據(jù)結(jié)構(gòu)……非正常營業(yè)影院，上報場次、人數(shù)、收入均為0。全國點播影院經(jīng)營管理信息系統(tǒng)不接收測試數(shù)據(jù)”的要求。按《規(guī)范》要求，“測試”狀態(tài)應歸為非正常營業(yè)影院，也應按照“場次編碼為zzzzzzzzzzzzzzzzz，節(jié)目編碼為10000000000000，收入為0”的要求上報原始場次數(shù)據(jù)，但“全國點播影院經(jīng)營管理信息系統(tǒng)不接收測試數(shù)據(jù)”，這種情況下為何要讓“測試”狀態(tài)的點播影院上報？而且，“測試”狀態(tài)的點播影院數(shù)據(jù)上報格式和“停業(yè)” “注銷”狀態(tài)的點播影院數(shù)據(jù)上報格式一致，上報報文結(jié)構(gòu)中又沒有影院營業(yè)狀態(tài)字段，在不對照全國點播影院經(jīng)營管理信息系統(tǒng)所存儲的點播影院營業(yè)狀態(tài)的情況下，無法區(qū)分出“測試”狀態(tài)和“停業(yè)” “注銷”狀態(tài)的點播影院上報的數(shù)據(jù)報文?！兑?guī)范》定義的“測試”營業(yè)狀態(tài)為“在點播影院開業(yè)前系統(tǒng)調(diào)試測試時標注為測試狀態(tài)”，實際上，按照這樣的定義，“測試”狀態(tài)的點播影院產(chǎn)生和上報的數(shù)據(jù)均為假數(shù)據(jù)，也可以歸為垃圾數(shù)據(jù)，這樣的數(shù)據(jù)不應該上報至全國點播影院經(jīng)營管理信息系統(tǒng)，以避免對全國點播影院經(jīng)營管理信息系統(tǒng)的數(shù)據(jù)造成紊亂影響。較為合理的邏輯為，全國點播影院經(jīng)營管理信息系統(tǒng)應具備生產(chǎn)和測試兩套環(huán)境，兩套環(huán)境具備相同的數(shù)據(jù)接收機制；點播影院在系統(tǒng)調(diào)試測試時，產(chǎn)生的均為假數(shù)據(jù)，應上報至全國點播影院經(jīng)營管理信息系統(tǒng)的測試環(huán)境；在系統(tǒng)調(diào)試測試完成時，點播影院的上報對象應切換至全國點播影院經(jīng)營管理信息系統(tǒng)的生產(chǎn)環(huán)境；“測試”狀態(tài)應定義為點播影院正式開業(yè)前的試營業(yè)狀態(tài)，該狀態(tài)下產(chǎn)生的數(shù)據(jù)為點播影院的正常經(jīng)營數(shù)據(jù)，應如實正常上報至全國點播影院經(jīng)營管理信息系統(tǒng)的生產(chǎn)環(huán)境；上報的數(shù)據(jù)報文結(jié)構(gòu)中，應添加影院營業(yè)狀態(tài)字段。

再次，“停業(yè)”和“注銷”狀態(tài)的點播影院，其軟件系統(tǒng)可能已經(jīng)停止運行，是否還需要再進行數(shù)據(jù)上報？即使需要上報數(shù)據(jù)，也是由點播院線計費系統(tǒng)生成假數(shù)據(jù)進行上報，全國點播影院經(jīng)營管理信息系統(tǒng)對這樣的假數(shù)據(jù)有沒有接收的必要性，這個問題值得商榷。

4.2.2 退場問題

對于點播影院經(jīng)營的實際情況來說，退場的可能性是存在的。對于退場，《規(guī)范》附錄C信息數(shù)據(jù)接口的原始場次數(shù)據(jù)上報數(shù)據(jù)結(jié)構(gòu)和統(tǒng)計營業(yè)數(shù)據(jù)上報數(shù)據(jù)結(jié)構(gòu)中均未有定義，僅在“表2 點播院線計費系統(tǒng)數(shù)據(jù)上報要求”有“統(tǒng)計上報……所上報經(jīng)營數(shù)據(jù)應為已經(jīng)扣除退票退場數(shù)據(jù)后的最終數(shù)據(jù)”的要求，原始場次數(shù)據(jù)上報在遇到退場情況時沒有明確的處理規(guī)則。退場情況的原始場次數(shù)據(jù)上報是否要執(zhí)行？如需上報，相關的觀影人數(shù)和收入如何填值？這些問題需要進一步明確。最簡單的做法是，原始場次數(shù)據(jù)上報和統(tǒng)計營業(yè)數(shù)據(jù)上報都不上報退場情況，但這需要管理機構(gòu)認可。

4.2.3 非規(guī)范操作處理問題

《規(guī)范》要求“出現(xiàn)非規(guī)范操作時(如非正常關機、斷電等)，應保持必要數(shù)據(jù)的一致性”，現(xiàn)在軟件系統(tǒng)云端部署已成趨勢，點播影院的軟件系統(tǒng)也不例外，已有很多點播院線計費系統(tǒng)和經(jīng)營管理系統(tǒng)部署于云端。對于云端部署、尤其是公有云部署的軟件系統(tǒng)，非正常關機、斷電之類的操作已經(jīng)不太適用。

4.2.4 信息數(shù)據(jù)接口報文字段問題

《規(guī)范》附錄C定義了點播院線計費系統(tǒng)與全國點播影院經(jīng)營管理信息系統(tǒng)之間進行數(shù)據(jù)通迅的信息數(shù)據(jù)接口，其中定義的通訊報文結(jié)構(gòu)的報文頭中“client_code”字段數(shù)據(jù)類型為char(8)，建議改為char(9)；原始場次數(shù)據(jù)上報數(shù)據(jù)結(jié)構(gòu)中的“session_code”字段數(shù)據(jù)類型為char(17)，在非正常營業(yè)影院進行原始場次數(shù)據(jù)上報時建議填值為16個“z”，而不是《規(guī)范》描述的17個“z”。以使全部char(n)類型的字段均滿足《規(guī)范》附錄C中C.2.2“數(shù)據(jù)類型”條款的定義“char(n) n個字節(jié)定長以0為結(jié)束符的字符串，字符串最大長度為n-1個字節(jié)，當字符串長度不足n-1個字節(jié)時，剩余字節(jié)值都為0”，這樣既統(tǒng)一了《規(guī)范》的描述，也能夠避免在對字段進行解析時產(chǎn)生困擾。

另外，統(tǒng)計營業(yè)數(shù)據(jù)上報數(shù)據(jù)結(jié)構(gòu)中“total_report_count”字段，含義不夠明確，可以理解為點播院線計費系統(tǒng)在該營業(yè)日期上報原始場次數(shù)據(jù)的次數(shù)，也可以理解為上報本條統(tǒng)計營業(yè)數(shù)據(jù)的次數(shù)，或者可以理解為點播院線計費系統(tǒng)上報原始場次數(shù)據(jù)或統(tǒng)計營業(yè)數(shù)據(jù)的總次數(shù)，也可以理解為僅上報原始場次數(shù)據(jù)或統(tǒng)計營業(yè)數(shù)據(jù)成功的次數(shù)。

5 總結(jié)

相比于276標準對電影院票務管理系統(tǒng)的要求，《規(guī)范》對點播影院計費系統(tǒng)的要求要少很多，但作為電影播映新模式這一新生事物的技術規(guī)范，在開展符合性檢測時的難度和工作量并不小。首先，要對《規(guī)范》的每一條款進行詳細研讀、充分理解，要保證理解的一致性；其次，要與軟件廠商配合，對其點播院線計費系統(tǒng)進行調(diào)試，這是一個反復而漫長的過程；再次，在檢測過程中，要對軟件廠商進行《規(guī)范》的宣貫。通過多次檢測的實踐，積累了一些經(jīng)驗和心得，也遇到了一些問題，于是撰寫本文，希望對相關軟件廠商的點播院線計費系統(tǒng)研發(fā)和送檢有所裨益，也希望在大家共同努力下，問題得到解決。

點播影院的規(guī)范化，必然要經(jīng)歷反復的經(jīng)驗摸索和市場驗證，是一條漫長又艱難的道路。作為電影行業(yè)質(zhì)檢機構(gòu)從業(yè)人員，理應迎難而上，嚴守質(zhì)檢關，為電影播映新模式的健康發(fā)展做出貢獻。