集裝箱碼頭操作控制子系統產品化研發實施

張毅

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

關鍵詞：集裝箱碼頭操作系統；產品化；研發；實施

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

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

1集裝箱碼頭操作管理系統國內現狀

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

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

2重點解決以下幾個問題

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

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

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

（4）根據碼頭業務的差異和維護實施需要如何設計出通用配置化的架構。

3具體設計方案

（1）VC++開發的非托管客戶端如何調用基于IIS的.NET服務

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

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

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

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

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

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

結論

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

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

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

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

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

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

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

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

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

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

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

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

（4）根據碼頭業務的差異和維護實施需要如何設計出通用配置化的架構

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

1）界面元素配置化

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

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

②提供一個模板基類，對XML中的UI元素統一的消息處理，將所有的事件依據XML中配置的函數名進行事件分發。

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

2）業務流程的配置化

業務規則定制由3部分組成：框架、XML配置文件、業務規則定義。

1）業務規則管理實現了ITOSRuleManage接口，該部分由系統框架實現，提供如下功能：提供業務規則的管理；提供數據參數的傳遞；根據業務流程編號按順序執行配置文件中使用到的業務規則；可獲取業務規則返回的信息。

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

3）業務規則定義，即通過輸入的數據，來判斷是否符合規則。

4預期效果

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

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

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

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

參考文獻：

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

[2] 馬健麗. 基于400M無線網絡的中小型集裝箱碼頭無線作業調度系統[J]. 中國科技信息，2010（12）：130.

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

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

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

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