集装箱码头操作控制子系统产品化研发实施

张毅

摘要：论文结合多年码头实际研发实施现状，设计出可适应多种码头类型的架构，抽象出多个可复用的公用组件，并从业务层面总结出一批同时适应多种码头业务的可配置内容，大大减少了新码头的开发成本以及后期实施的成本，为集装箱码头操作系统产品化道路迈出了坚实的一步。

关键词：集装箱码头操作系统；产品化；研发；实施

中图分类号：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.