集裝箱碼頭操作控制子系統(tǒng)產(chǎn)品化研發(fā)實施

張毅

摘要：論文結(jié)合多年碼頭實際研發(fā)實施現(xiàn)狀，設計出可適應多種碼頭類型的架構(gòu)，抽象出多個可復用的公用組件，并從業(yè)務層面總結(jié)出一批同時適應多種碼頭業(yè)務的可配置內(nèi)容，大大減少了新碼頭的開發(fā)成本以及后期實施的成本，為集裝箱碼頭操作系統(tǒng)產(chǎn)品化道路邁出了堅實的一步。

關鍵詞：集裝箱碼頭操作系統(tǒng)；產(chǎn)品化；研發(fā)；實施

中圖分類號：U169.6文獻標識碼：A

本研究課題計劃以招商局青島碼頭CTOS研發(fā)實施項目為依托，在CTOS產(chǎn)品研發(fā)中植入產(chǎn)品化的理念，第一步實現(xiàn)主要部件組件化，利用積累起來的業(yè)務經(jīng)驗逐步增加模塊復用的程度，研發(fā)出具有自主知識產(chǎn)權的，在技術架構(gòu)以及開發(fā)工具上具有一定先進性并且可以滿足碼頭營運的，世界一流的集裝箱碼頭操作系統(tǒng)；然后以此為基礎搭建符合國內(nèi)外集裝箱碼頭操作習慣，業(yè)界領先的集裝箱碼頭操作開發(fā)平臺，增加CTOS的競爭能力。

1集裝箱碼頭操作管理系統(tǒng)國內(nèi)現(xiàn)狀

TOS系統(tǒng)，俗稱集裝箱碼頭操作系統(tǒng)，在集裝箱碼頭的軟性指標中處于核心地位；國外的TOS系統(tǒng)發(fā)展多年，依靠早年積累起來的技術和眾多的客戶為業(yè)務背景，已經(jīng)開發(fā)出很成熟的產(chǎn)品，可以適應大型集裝箱碼頭的操作管理需要；但是另一方面也存在費用高，維護周期長，本地化差異及核心技術受制于他人的問題；國內(nèi)的TOS系統(tǒng)起步較晚，產(chǎn)品較不成熟，所以國內(nèi)大型集裝箱碼頭使用的基本上是國外的產(chǎn)品，比如招商局旗下的蛇口集裝箱碼頭使用美國的Navis，赤灣集裝箱碼頭使用的是比利時的Cosmos產(chǎn)品；而此兩大碼頭占了整個深圳集裝箱碼頭的約一半箱量。

目前市面上各大碼頭用的TOS系統(tǒng)產(chǎn)品主要來源于國外的Navis、Cosmos、TSB等大的廠商；而國內(nèi)較大的TOS系統(tǒng)研發(fā)企業(yè)有上海海勃、華東電子等主要公司，競爭相當強。招商局國際作為招商局旗下的優(yōu)質(zhì)公司，TOS系統(tǒng)作為企業(yè)的軟性核心競爭力，不論從國家重點發(fā)展自主創(chuàng)新的理念，還是市場化的需要，對自身的TOS系統(tǒng)的研發(fā)提出了更高的要求，產(chǎn)品化道路勢在必行。2003年至今，招商局集裝箱碼頭操作管理系統(tǒng)（下稱CTOS）已經(jīng)在旗下5個中小碼頭成功實施，多年來積累了豐富的研發(fā)實施經(jīng)驗，CTOS系統(tǒng)從1.0版本也發(fā)展到了3.0版本，但是隨著碼頭業(yè)務的不斷發(fā)展，原有項目化發(fā)展的CTOS系統(tǒng)逐步暴露出諸如單證等子系統(tǒng)之間的數(shù)據(jù)交換復雜、系統(tǒng)整體性能較低、后期擴展性弱、維護成本高等問題；所以盡快使CTOS系統(tǒng)產(chǎn)品化迫在眉睫。

2重點解決以下幾個問題

（1）VC++的客戶端程序如何高效的調(diào)用基于IIS的.NET中間層服務。

（2）如何設計和抽取出一套基于Windows平臺的核心通用組件，增加復用率并且降低將來實施新碼頭TOS系統(tǒng)的研發(fā)實施成本。

（3）無線終端2.4G技術如何與目前大量使用的400M技術相結(jié)合。

（4）根據(jù)碼頭業(yè)務的差異和維護實施需要如何設計出通用配置化的架構(gòu)。

3具體設計方案

（1）VC++開發(fā)的非托管客戶端如何調(diào)用基于IIS的.NET服務

在.NET應用3層架構(gòu)應用程序中，中間層應用服務器可使用.net remoting或WebService實現(xiàn)，兩種技術的主要特點如下：

a）WebService：語言獨立，平臺獨立，穿透防火墻，適合Internet場景應用；性能比TCP+Binary形式的Remoting慢；和host在IIS上的HTTP+Binary形式的Remoting性能基本相當；比host在IIS上的HTTP+SOAP形式的Remoting性能高；必須host在WebServer上；面向接口實現(xiàn)，適用于傳遞簡單數(shù)據(jù)類型或系統(tǒng)內(nèi)置對象，不太適合傳遞復雜對象；遠程對象生命周期：只支持SingleCall模式。

b）Remoting：客戶端局限于.net framework；跨應用程序域的.net component；支持Binary or SOAP格式；支持TCP，HTTP，自定義通信協(xié)議；WebServer不是必須的，可host在其它自定義應用程序；TCP通道下的remoting性能比WebService性能高；完全的面向?qū)ο髮崿F(xiàn)；遠程對象生命周期：支持SingleCall、Singleton、CAO三種方式。

在本系統(tǒng)中間層技術選型中，性能是第一位的考慮因素。TCP通道和二進制格式下的Remoting比WebService性能高是很明確的，但使用TCP通道一般需要另行開發(fā)一個Windows Service程序作為Remoting應用的host程序，這種方式主要的問題是比較難實現(xiàn)系統(tǒng)的負載均衡，且增加了系統(tǒng)的復雜度和增加了工作量?；谪撦d均衡的考慮，在本系統(tǒng)中，不考慮使用TCP通道的Remoting技術實現(xiàn)。

由于排除了使用TCP通道的Remoting，所以在系統(tǒng)性能比較上就只考慮IIS上的Remoting和WebService，通過參考微軟對兩種技術的性能對比測試報告，并進行實際的性能對比測試，對比性能測試的結(jié)果與微軟的測試報告結(jié)果一致：WebService比HTTP+SOAP方式的Remoting性能高；WebService與HTTP+Binary方式的Remoting性能基本相當，多數(shù)情況下WebService的性能稍高一些。

通過性能對比測試，顯示W(wǎng)ebService和Host在IIS上的Remoting在性能上基本沒有差別，另外的重要的考慮因素是對VC++應用的支持。在TOS系統(tǒng)中，前臺應用程序采用VC++語言開發(fā)，前臺程序具有復雜的圖形處理，暫時不準備將這部分程序移植到.NET平臺實現(xiàn)。這種情況下如果中間層應用服務器使用Remoting技術實現(xiàn)，則前臺程序必須完全用.NET技術重寫；而如果中間層應用服務器使用WebService技術實現(xiàn)，則前臺應用程序可仍然使用VC++開發(fā)，這可以大大減少開發(fā)工作量，降低項目風險。

結(jié)論

經(jīng)過對比Remoting和WebService技術的處理性能和適用場景，認為WebService技術更適合在本系統(tǒng)中，所以在本系統(tǒng)中決定采用WebService技術實現(xiàn)中間層應用服務器。

（2）如何設計和抽取出一套基于Windows平臺的核心通用組件，增加復用率并且降低將來實施新碼頭TOS系統(tǒng)的研發(fā)實施成本

系統(tǒng)計劃采取的架構(gòu)基于COM組件，采用二進制方式進行共享，而不是傳統(tǒng)的代碼級重用，能夠降低系統(tǒng)的耦合型，更好的對并行開發(fā)方式的支持。SDK與ATL+WTL的結(jié)合，即可以減少對MFC的依賴，又可以利用成熟的ATL+WTL的模板類來進行快速的開發(fā)，在WTL中已經(jīng)有很好的對窗口類的封裝，很好的對ATL進行了補充。ATL和WTL對用戶來說都是開源的，在調(diào)試跟蹤方面或者問題排查上，會有很大的幫助。

基于上述原因，整體圖形化系統(tǒng)采取COM組件搭建，設計思想如下：系統(tǒng)框架不緩存任何數(shù)據(jù)，COM實體緩存顯示和操作必需的數(shù)據(jù)。所有COM組件的數(shù)據(jù)交換采用標準的XML結(jié)構(gòu)處理，可跨開發(fā)語言平臺使用（基于Windows）。根據(jù)實際情況，計劃對部分通用以及可能通用的模塊采取標準化的組件設計，進行COM抽象改造之后，可被其它模塊或者開發(fā)語言調(diào)用使用，降低了開發(fā)成本。

1）船側(cè)視圖。2）船瀏覽圖。3）船貝圖。4）船柱狀圖。5）堆場外觀圖。6）堆場鳥瞰圖。7）堆場貝位圖。8）堆場欄圖。9）泊位計劃。10）統(tǒng)計表。

（3）無線終端2.4G技術如何與目前大量使用的400M技術相結(jié)合

關于碼頭無線終端的使用，目前存在兩種帶寬的技術：400MHz和2.4GHz；這兩種技術模式各有優(yōu)缺點，說明如下（灰色底色表示優(yōu)點）：

從上表可以看出，400MHz的目前需要繼續(xù)使用的理由是由于歷史原因以及成本考慮，長期來看會逐步被2.4GHz所替代；但是400MHz的會繼續(xù)存在2～3年或更久。所以，在設計上我們必須考慮將兩者在系統(tǒng)級別不作區(qū)分。統(tǒng)一設計維護。

基于以上考慮，無線終端服務設計思路如下：

1）無線終端服務端只關注界面邏輯，業(yè)務邏輯放到IIS的中間層進行處理。

2）2.4GHz的終端和400MHz的終端統(tǒng)一通過封裝的無線終端服務進行中間層的訪問，終端不直接訪問中間層。

3）由于400MHz的界面顯示處理只能在無線終端服務端進行；故在無線終端服務端的設計內(nèi)單獨加入400MHz的界面處理類，其余的類不再區(qū)分2.4GHz或者400MHz，進行統(tǒng)一處理。2.4GHz的客戶端處理當作Windows客戶端處理，不需服務端介入。

（4）根據(jù)碼頭業(yè)務的差異和維護實施需要如何設計出通用配置化的架構(gòu)

為提高圖形化系統(tǒng)的產(chǎn)品化程度（主要包含船舶管理和堆場管理兩大模塊），減少新碼頭的開發(fā)成本以及后期實施的成本，需要對各個碼頭對于碼頭圖形化系統(tǒng)的需求進行抽象并且進行配置化處理，主要分為以下兩類的配置化：

1）界面元素配置化

在VC++的實現(xiàn)框架下，采用的XML來進行UI配置，目標是將目前存在的每個碼頭一套代碼合并成統(tǒng)一的一套編譯代碼，而最終的目的則是要將前臺軟件產(chǎn)品化。因此，在UI部分進行合并時，則要求不是簡單的將所有代碼能合并到一個編輯框架下，而是消除現(xiàn)有軟件實施過程中碼頭化的概念，將所有的功能都合并起來，形成一個功能全集；通過配置，選擇不同的功能模塊，以滿足不同碼頭的業(yè)務需求。

①以XML文件來描述UI組件的位置，控件類型，以及所對應的事件。

②提供一個模板基類，對XML中的UI元素統(tǒng)一的消息處理，將所有的事件依據(jù)XML中配置的函數(shù)名進行事件分發(fā)。

③對于需要定制化的UI界面，繼承框架提供的模板基類，并注冊事件處理函數(shù)后，通過裝載UI XML來達到界面功能配置化的目的。

2）業(yè)務流程的配置化

業(yè)務規(guī)則定制由3部分組成：框架、XML配置文件、業(yè)務規(guī)則定義。

1）業(yè)務規(guī)則管理實現(xiàn)了ITOSRuleManage接口，該部分由系統(tǒng)框架實現(xiàn)，提供如下功能：提供業(yè)務規(guī)則的管理；提供數(shù)據(jù)參數(shù)的傳遞；根據(jù)業(yè)務流程編號按順序執(zhí)行配置文件中使用到的業(yè)務規(guī)則；可獲取業(yè)務規(guī)則返回的信息。

2）通過XML配置文件來定義業(yè)務流程中使用到的校驗項，分兩部分：業(yè)務規(guī)則集合定義和業(yè)務流程中使用的規(guī)則：業(yè)務規(guī)則定義包含：規(guī)則ID、組件CLSID、函數(shù)名稱；業(yè)務流程包含：業(yè)務流程編號、使用規(guī)則、規(guī)則對應附加參數(shù)的描述。

3）業(yè)務規(guī)則定義，即通過輸入的數(shù)據(jù)，來判斷是否符合規(guī)則。

4預期效果

（1）業(yè)務邏輯層采用了標準WebService方法構(gòu)建，適應各種不同的客戶端（含C/S，B/S）調(diào)用，無需過多考慮開發(fā)語言和模式，只要能調(diào)用標準WebService都可以。

（2）抽象了10個以上的圖形化組件，此部分內(nèi)容可適應目前所知的絕大部分碼頭的需要，不需要再進行開發(fā)。大大減少了圖形化系統(tǒng)的研發(fā)和實施時間。

（3）技術和業(yè)務上整合了無線終端目前的主流頻點400MHz和2.4GHz開發(fā)，可以適應所有碼頭的無線終端的需求；實施過程中只需要根據(jù)各碼頭實際業(yè)務進行業(yè)務處理調(diào)整即可，無需對技術架構(gòu)進行改變。

（4）由于根據(jù)已實施碼頭的實際經(jīng)驗以及業(yè)界其他碼頭的可能預期在圖形化系統(tǒng)進行了可配置項的設置，此部分內(nèi)容可適應絕大部分碼頭的需要，只需要根據(jù)新碼頭的實際情況進行配置即可，不需要再進行開發(fā)，大大減少了圖形化系統(tǒng)的研發(fā)和實施時間。

參考文獻：

[1] 張莉. D港集裝箱碼頭堆場系統(tǒng)業(yè)務流程現(xiàn)狀、問題及對策[J]. 物流技術，2009，28（1）：44.

[2] 馬健麗. 基于400M無線網(wǎng)絡的中小型集裝箱碼頭無線作業(yè)調(diào)度系統(tǒng)[J]. 中國科技信息，2010（12）：130.

[3] 徐繼成，曲國臣. 集裝箱碼頭操作系統(tǒng)解決方案研究[J]. 水運科學研究，2006（3）：35.

[4] 彭傳圣. 集裝箱碼頭經(jīng)營與技術信息[J]. 水運科學研究，2007（1）：58.

[5] 蘇波，歐陽仁堂. 深圳港口物流現(xiàn)狀與發(fā)展對策[J]. 集裝箱化，2005（2）：31.

[6] 朱靜霞. 中國港口集裝箱碼頭信息技術應用現(xiàn)狀與展望[J]. 中國遠洋航務，2006（8）：58.