張軼

（廣東機場白云信息科技有限公司，廣東 廣州 510470）

0 引言

民航領(lǐng)域的信息共享還需要多方的支持，這樣才能滿足正常運行的要求，以此來滿足數(shù)據(jù)的共同管理要求。為了能夠讓數(shù)據(jù)的協(xié)同共享得到落實，基于安全數(shù)據(jù)共享基礎(chǔ)設(shè)備的支持，通過相應(yīng)技術(shù)的分析實現(xiàn)運行數(shù)據(jù)的協(xié)同共享。

1 航班協(xié)同運行保障系統(tǒng)的整體架構(gòu)設(shè)計

基于區(qū)塊鏈層次結(jié)構(gòu)和網(wǎng)絡(luò)架構(gòu)進行分析，以某機場實際航班運行數(shù)據(jù)進行分析，最終提出航班信息共享鏈架構(gòu)[1]。針對本架構(gòu)，主要是考慮到基礎(chǔ)的運行保障系統(tǒng)應(yīng)用架構(gòu)，然后做好對應(yīng)的分析與改進處理。

1.1 架構(gòu)設(shè)計

與具體的航班運行數(shù)據(jù)和對應(yīng)的區(qū)塊鏈基礎(chǔ)架構(gòu)進行結(jié)合，并且將其具體劃分為數(shù)據(jù)層、智能合約層等等，其實際內(nèi)容如圖1所示。

圖1 航班信息共享鏈層次結(jié)構(gòu)

1.2 網(wǎng)絡(luò)結(jié)構(gòu)

基于網(wǎng)絡(luò)結(jié)構(gòu)視頻之下的區(qū)塊鏈網(wǎng)絡(luò)，還要求了其節(jié)點的數(shù)據(jù)流向和對應(yīng)的關(guān)系表現(xiàn)情況需要進行具體的分析?？紤]到業(yè)務(wù)方面的需求，與區(qū)塊鏈網(wǎng)絡(luò)節(jié)點實現(xiàn)相互之間的配合處理，這樣就可以獲取對應(yīng)的網(wǎng)絡(luò)結(jié)構(gòu)，滿足實際要求，如圖2所示。通過調(diào)查統(tǒng)計分析，主要包含了機場、地服、航空、空管四個方面。而每一個參與方都包含了證書頒發(fā)機構(gòu)、主節(jié)點、背書節(jié)點、錨節(jié)點、記賬節(jié)點[2]。

圖2 航班信息共享鏈網(wǎng)絡(luò)結(jié)構(gòu)圖

2 基于智能合約的航班協(xié)同運行保障系統(tǒng)實現(xiàn)

考慮到航班協(xié)同運行的保障，在區(qū)塊鏈技術(shù)下，就要求能夠選擇智能合約航班協(xié)同運行保障系統(tǒng)，在具體分析中通過基于智能合約的分布式存儲模塊研究，希望可以滿足航班運行數(shù)據(jù)協(xié)同共享的需求。

2.1 智能合約需求

需求分析是系統(tǒng)設(shè)計與實現(xiàn)基礎(chǔ)，通過系統(tǒng)要求與目的的分析可以落實后續(xù)的開發(fā)。所以，本章主要是考慮到智能合約，其主要是為了滿足穩(wěn)定與安全的要求，同時在實際的運行之中也能夠合理的規(guī)避出現(xiàn)篡改的問題。

針對本系統(tǒng)，需要統(tǒng)一管理航班的運行數(shù)據(jù)，如查詢航班信息、航班運行數(shù)據(jù)等等。各個參與方則要分別上傳運行過程中的航班數(shù)據(jù)，然后基于權(quán)限做好對應(yīng)數(shù)據(jù)的查詢與分析。本文建立的智能合約主要是分析基于分布式存儲來進行分析，通過智能合約擁有的不可更改、自動執(zhí)行等特點，滿足存儲航班運行數(shù)據(jù)的要求[3]。

2.2 環(huán)境配置及聯(lián)盟鏈網(wǎng)絡(luò)搭建

在系統(tǒng)的設(shè)計方面，還需要落實超級賬本聯(lián)盟鏈的有效搭接，并且通過兩臺實體機進行操作，這樣就會有兩個節(jié)點的存在，對應(yīng)的搭建流程圖如圖3所示。

圖3 聯(lián)盟鏈網(wǎng)絡(luò)搭建流程

2.3 基于智能合約的分布式存儲模塊

鏈上代碼在超級賬本之中屬于智能合約，同時也屬于去中心化的實際交易程序處理要求，在執(zhí)行方面，就要求做好節(jié)點的驗證處理。對于鏈碼而言，其本身包含的是系統(tǒng)與用戶。一般情況下，用戶的鏈碼，其屬于基本的賬本訪問方式。在編寫之中選擇go語言進行對應(yīng)的操作，這樣就能夠匹配接口代碼的要求。針對上層的應(yīng)用主要是考慮到鏈碼的初始化以及針對賬本管理的具體狀態(tài)。只要能夠擁有恰當?shù)臋?quán)限，那么久可以滿足鏈碼的相互調(diào)用處理。在服務(wù)方面，代碼的存放直接考慮到docker的處理，執(zhí)行環(huán)境更加便捷、安全。選擇區(qū)塊鏈技術(shù)和P2P網(wǎng)絡(luò)，就可以提供一個穩(wěn)定、安全的運行環(huán)境，然后在區(qū)塊鏈之中嵌入航班運行數(shù)據(jù)，這樣就可以提供交互界面給用戶與底層相關(guān)的數(shù)據(jù)，最終才能夠滿足上傳數(shù)據(jù)、修改數(shù)據(jù)以及查詢數(shù)據(jù)的要求。

在安裝鏈碼上，主要是通過背書節(jié)點，基于通道實例化的處理，然后做好背書方面的定義，以便保障運行的正常性。在鏈碼部署之后，就不能再進行更改處理，不過，基于新功能或者是進行問題上針對性的修復(fù)。對于fabric設(shè)計，要求在安全docker容器沙盒中進行鏈碼相應(yīng)的運行處理。在容器內(nèi)部，主要是考慮到背書節(jié)點來進行創(chuàng)建管理的處理，這樣才能夠滿足相互之間的隔離要求，滿足實際的運行處理。

考慮到超級賬本智能合約而言，因為與代碼平臺相互的類似，所以，在對應(yīng)的環(huán)境之下，可以針對性的做好其處理，以此來滿足實際的外界隔離，并且在共識節(jié)點執(zhí)行之后，合約就可以基于超級賬本節(jié)點，會按照合約規(guī)則滿足數(shù)據(jù)的分布式存儲要求。每一個參與方也都能看到航班的基礎(chǔ)信息，所以本模塊的數(shù)據(jù)結(jié)構(gòu)與分布式存儲航班的基本信息函數(shù)，不同在不同參與方的進入下，也需要讓合約的部署能夠達成一致的要求，代碼如圖4所示。

圖4 航班信息數(shù)據(jù)結(jié)構(gòu)

通過圖4代碼可以看出，ID作為唯一的運行數(shù)據(jù)表示，通過相應(yīng)的數(shù)據(jù)增加之后，就會讓ID數(shù)值自動+1，這就代表的運行基本數(shù)據(jù)。其中航班號為Flt_no，執(zhí)行日期為Date，航班計劃出發(fā)時間為STD，計劃到達時間為STA，航班狀態(tài)是否在正常的狀態(tài)下是Status，預(yù)計起飛時間為ETFT，預(yù)計撤輪擋時間為EOBT。通過相應(yīng)的數(shù)據(jù)結(jié)構(gòu)分析之后，通過圖4之中的代碼數(shù)據(jù)編寫添加之后，其實際的數(shù)據(jù)信息見圖5代碼所示。

圖5中的代碼作為合約存儲航班信息的基本函數(shù)。對于這一點，就需要考慮到字符串狀態(tài)變量的有效使用，這樣能夠滿足多個數(shù)據(jù)聲明的要求。在執(zhí)行過程中，這一變量值在存儲的過程中，其返回的時候，就會有交易方面的數(shù)值出現(xiàn)。在本節(jié)點內(nèi)，會直接發(fā)送共識節(jié)點相應(yīng)的數(shù)據(jù)，然后做好對應(yīng)的存儲，這樣才能夠與數(shù)據(jù)信息存證相互的配合起來。在使用Angularjs工具之后，其見圖6所示。

基于圖6所示，在航班信息填寫進入之后，就可以直接向區(qū)塊鏈提交用戶的基本信息，并且無法進行更改。之后，基于撤輪擋數(shù)據(jù)要求，在業(yè)務(wù)處理中，其需要進行多次的更改，這個時候，yoghurt就可以實現(xiàn)分布式存儲函數(shù)的調(diào)用，之后，再通過對應(yīng)的程序，直接傳入不同的數(shù)據(jù)，這樣會讓原本的字符串出現(xiàn)被覆蓋的情況，雖然數(shù)據(jù)也會最終的返回，不過區(qū)塊鏈的歷史區(qū)塊之中依舊會有之前的數(shù)據(jù)存在，并且是不能更改和刪除的[4-5]。

3 結(jié)語

總而言之，針對傳統(tǒng)模式下的航班運行協(xié)同共享系統(tǒng)，其要求的是共享航班運行數(shù)據(jù)的處理要求，基于單獨數(shù)據(jù)庫的建立健全，但是它不能統(tǒng)一，并且數(shù)據(jù)庫分散，所以需要基于信任來確保數(shù)據(jù)的可靠性和真實性，基于區(qū)塊鏈技術(shù)的航班運行數(shù)據(jù)協(xié)同共享就能滿足對于航班運行數(shù)據(jù)的分析要求。