远洋客船网络化服务平台系统组件兼容性分析

于栋亮 薛亚宾

(上海外高桥造船有限公司 上海 201200)

近年来，伴随经济发展和社会进步，市场对客运船舶的需求越来越多；为紧跟远洋客船相关航运和商业发展趋势，国务院、交通运输部、文化和旅游部以及国家发改委等部门相继出台一系列产业政策来扶持国内远洋客船经济的发展。上海、天津、海南、厦门、青岛等地方政府的产业发展政策也为区域远洋客船航运的发展注入强劲的动力。目前，我国多家船舶制造企业已承接包括大型邮轮、客运滚装船、中小型邮轮在内的远洋客船订单，市场占有率达到世界前列。以客滚船为例，截至目前我国客滚船手持订单共31艘，占全球130艘订单总量的23.8%，位居世界第一，为从欧洲向中国进行产业转移提供了基础条件。据推测，到2030 年，我国高技术远洋客船旅客将达到1 750万人次，成为世界上最大的远洋游客市场之一。大型邮轮作为高度现代化的远洋航海船舶的典型代表，被称为造船业的“皇冠上最光芒的珍珠”。中国船舶工业集团有限公司在2018年首届国际进口博览会上与美国嘉年华集团、意大利芬坎蒂尼集团签署了建造2+4 艘Vista 级13.55 万吨大型邮轮的合同，这是中国造船业发展历程中的一个里程碑，标志着中国船舶工业正式进入了大型邮轮和客滚船等高技术远洋客船建造的新时代。

高技术远洋客船的船上服务水平是该类产品竞争力的重要组成。目前，我国形成的船上服务模式和手段难以满足乘员对于船上服务日益增长的需求。网络化手段可有效改善船上服务质量，并提高我国远洋客船产品的竞争力。中国在“互联网+”技术应用领域的很多方面已经走在世界前列，如移动支付、移动视听平台、互联网+社区、智慧交通和智能城市等成功案例非常多，将“互联网+”技术与高技术远洋客船船上服务相结合，是我国在高技术远洋客船行业实现弯道超车的突破口。

在构建我国高技术远洋客船船上服务研究与应用过程中，首先需要进行船上网络化服务模式研究，构建适合我国国情，并增添中国元素的网络化服务体系。客船网络化服务平台因强大的功能需求，包含了很多子系统及其组件。这就对网络服务平台不同运行环境下，种类繁多的软件程序与各子系统、系统组件间的兼容性有高要求、高标准。

1 船上网络化服务平台系统组件介绍

1.1 定位导航设备

船上定位导航平台主要用于对旅客进行区域引导与指引，高技术远洋客船定位导航平台硬件集成方案主要分为系统定位设备研发构建以及测试与校正系统两部分，如图1所示。

图1 高技术远洋客船定位导航平台硬件集成方案

图2 高技术远洋客船以太网设备集成方案

图3 高技术远洋客船视频监控设备设计方案

1.2 以太网设备

以太网硬件设备按内部终端千兆网络带宽配置，摄像头、无线AP、定位微基站等采用POE供电方式，主干网络如存储器、交换机、路由器、服务器采用主备模式和双网传输，预留防火墙、上网行为管理、路由器、上网计费网关等网络设备接口，实现无线访问功能。同时考虑三阶段测试、验证的系统扩容。

1.3 无线Wi-Fi-AP设备

结合邮轮内部及客人无线网络需求情况，为了提供稳定、高速、可靠、安全且易于维护管理的无线接入网络，采取了AP+AC的无线网络结构。这种方案可以有效地满足用户对无线网络的各种需求，提供稳定的信号覆盖、高速的数据传输、安全的数据加密、可靠的网络连接以及易于管理的网络控制。具体设计为在船端部署两台无线AC 控制器、双机热备，保障运行安全与冗余。控制器采用集中管理模式，无线AP接入网络后会自动下载相应的控制器配置。这种集中管理模式可以方便地对整个网络进行统一管理和控制，提高网络的效率和稳定性，同时也保证了网络的安全性和可靠性。无须手动配置，系统可以自动识别和下载所需的配置信息，使网络的管理更加智能化和高效化。登船系统、POS收银机、刷卡机使用以及其他移动专用设备上网；隐藏SSID，MAC+密码认证接入无线网络（无线AC上认证），手动静态IP，DHCP上通过MAC绑定协助重启设备获取到原来设定的IP。

船员办公应用，该网段可以访问内网服务器；有DHCP 分配，但DHCP 分配的IP 无法上网，必须手动配置IP，由管理员分配可上网的IP；默认开通互联网邮箱（IAM 开通邮件应用）；其他上网权限需要向管理部门申请开放。

1.4 视频监控设备

视频监控设备包括200 万像素高清半球摄像头（POE 供电模式）、摄像头、交换机（采用Cat6A 网线互联）；存储设备（录像存储不少于30 d）；电视（实时查看摄像头画面）。

1.5 生物体征识别设备

邮轮上生物体征识别设备是一种安全识别和认证设备。该设备采用自动化方法来验证或识别个体身份，这些方法基于个体的生理或行为特征。这些特征包括指纹、面部图像、虹膜和语音识别。生物体征识别设备包括智能功能、热成像功能、可见光功能、红外相关功能、系统功能以及接口功能等。

1.6 广播系统设备

邮轮广播系统是一种多功能设备，它可以远程或本地进行寻呼，全区或仅某一区进行广播喊话。该系统还可以实现背景音乐和消防系统的联动，系统会自动停止播放背景音乐，优先播放消防广播，以最大程度地减少人员伤亡和财产损失。在紧急情况下，该系统可以及时播放紧急广播信息，并停止公共广播系统的其他功能（如背景音乐、一般广播等），迅速引导人员疏散，并指引疏散方向，直至紧急状态解除。

1.7 消防系统设备

消防系统设备具有自动化功能，当火灾探测器探测到火灾信号后，系统会自动执行一系列措施。首先，在火灾刚刚发生时，火灾探测器会将烟雾、热量，以及光辐射等一些物理信号转变为数字信号，并将其传输到火灾报警控制器。控制器会准确地显示火灾发生的位置，并记录火灾发生的时间。其次，消防设备将启动自动灭火程序，这些程序包括切断报警区域内的空调器，关闭防火阀以及停止换风机，以便避免火势蔓延。同时，消防设备也会开启排烟阀，并关闭电动防火门和卷帘门等设备，以控制火源和减缓火势。再次，非消防用电源将被切断，而事故照明和疏散标志灯将被打开，以便给人员提供必要的照明和指示。最后，为了确保人员的安全，除了消防电梯以外的所有电梯都将被停用，以避免人员迷路或者被困在电梯内，立即启动灭火系统，进行自动灭火[1]。所有措施都旨在保护人员和财产的安全，减轻火灾造成的破坏与减少损失。

2 一般系统组件兼容性研究

远洋客船船上网络化服务平台系统及其组件主要是指网络化服务平台集成所涉及的上述硬件设备、设施，实现分布式的设备设施集成。充分研究远洋客船船上网络化服务平台系统组件兼容性，并进行整体集成，是为平台的正常运行提供的前期研究探索，也是保证软件系统功能实现的具体举措，对硬件环境搭建与软件系统应用具有重要意义。

兼容性测试主要用于验证软件与其所依赖的环境之间的依赖程度，包括硬件和软件平台的依赖程度，以确保软件能够在不同的环境下稳定运行。该测试方法要关注多个方面的因素。其中包括待测试项目在不同版本的同一操作系统平台和不同操作系统平台上的兼容性测试，以确保其能够在多种操作系统平台上正常运行[2]。此外，还需要测试待测试项目与其他相关软件的兼容性，以避免相互影响。在测试过程中还需要检查待测试项目在指定的硬件环境中是否能够高效、稳定地运行，以避免因硬件问题而导致的系统崩溃或其他故障。最后，还需要测试待测试项目在不同的网络环境中的可用性和稳定性，以确保其能够在各种网络条件下正常运行。综合这些因素，测试人员需要对待测试项目进行全面的测试，以确保其能够在多种情况下稳定运行，并满足用户需求。

兼容性测试主要包括以下几个方面：首先是测试软件是否能够在不同操作系统平台上兼容，并检查软件在同一操作系统平台的不同版本上是否能够正常运行；其次，测试软件本身是否具有向前和向后兼容性，也就是说，旧版本的软件能否与新版本的软件兼容，新版本的软件是否能够兼容旧版本的软件；再次，测试软件能否与其他相关软件兼容，包括一些常见的用户软件，这样才能确保整个软件生态系统的稳定性；最后，测试软件所使用的数据是否具有兼容性，是否能够被共享。

2.1 操作系统/平台的兼容性测试

平台兼容性测试是为了确保待测试项目在不同类型的操作系统平台下能够正常运行。由于备用方案有不同类型的操作系统，因此需要进行该操作系统平台的兼容性测试，以确保软件能够在不同的操作系统下正常运行。用户的系统配置也会影响软件的最终运行情况，从而产生兼容问题。软件程序可能在一些操作系统下能正常运转，在更换其他操作系统后就会出现系统不兼容[3]。因此，优秀的网络服务系统应该具有平台无关性。

针对船上人员使用的操作系统为Windows，软件开发人员在进行兼容性测试时应该优先考虑当前主流操作系统版本的兼容性。这样可以确保软件能够在大多数用户使用的主流操作系统上正常运行，提高软件的可用性和稳定性。但是，除了主流操作系统版本，还有一些用户使用非主流操作系统版本的情况，因此在主流操作系统版本兼容性测试的基础上，对非主流操作系统版本也应进行测试，以尽可能保证项目的操作系统版本兼容性测试的完整性。这样可以更全面地覆盖用户的使用情况，降低软件出现兼容性问题的风险，提高软件的质量和用户体验。需要注意的是，在进行兼容性测试时，应该注重测试的深度和广度，尽可能地覆盖不同的操作系统版本、不同的硬件平台和不同的应用场景，以确保测试的全面性和准确性。

2.2 应用软件兼容性测试

网络化服务平台在运行过程中需要与各种软件、子系统及组件进行交互，这种交互过程可能会引起平台的运行问题。为了确保平台能够正常运行，需要评估其所需的应用软件支持，并为了确保软件能够正常运行，需要进行兼容性测试。兼容性测试的目的是判断软件与其他常用软件一起使用时是否会出现兼容性问题，以及软件本身是否能够正确实现其功能。

2.3 浏览器兼容性测试

B/S 结构的应用软件是以浏览器作为Web 客户端的核心构建块，但是不同浏览器来自不同的厂商，对Java、JavaScript、ActiveX、plugins 或HTML 规范的支持会有所不同，甚至同一厂商的不同版本之间也可能存在兼容性问题[4]。这些差异和问题可能会影响应用软件的使用效果和用户体验，甚至导致应用软件无法正常运行。此外，浏览器的框架和层次结构风格也会有所不同，有些浏览器甚至根本不支持某些框架或层次结构风格。这也可能导致同一个应用在不同的浏览器中显示效果不同，甚至无法正常显示。另外，不同浏览器对于安全性和Java 设置的处理方式也不一样。例如：有些浏览器可能默认禁止Java的自动运行，需要用户手动授权才能运行，而有些浏览器可能默认允许Java 自动运行，这可能会对系统的安全性产生影响。因此，在开发Web应用时，需要考虑到不同浏览器之间的差异性，并进行兼容性测试，以确保应用能够在不同浏览器中正常运行。同时，开发者还需要注意Web 技术的兼容性问题，尽量避免使用某些浏览器特有的技术，以兼容更多的浏览器。

3 船上网络化服务平台系统组件兼容性分析

3.1 无线网络中TCP与IPsec的兼容性分析

TCP 协议是目前应用最广泛的传输层协议，主要提供可靠有序的数据传输，其在固定网络中的表现非常出色。但是，由于无线网络中信道的不稳定性和其他影响因素，TCP 协议在无线网络中的性能受到了很大的影响。在无线网络环境下，网络拥塞控制和丢包恢复机制的效率都会受到很大的挑战，从而导致TCP的性能下降、网络速度变慢、延迟增加等问题[5]。为了改善TCP 在无线环境下的性能，提出了优化拥塞控制算法、重传机制以及流量控制等提高TCP 在无线网络中的性能的改进方案。然而，这些改进方案与IPsec协议存在一定的冲突。因此，在实际应用中，需要综合考虑网络环境、应用需求和安全性要求等因素来选择合适的协议和方案。如果网络环境较差，TCP 协议的改进方案可以提高网络的性能和可靠性；如果通信内容需要保密或者防止被篡改，IPsec协议可以提供较高的安全性[6]。

3.1.1 无线网络中TCP与IPsec的兼容性分析

传输层安全协议（TLS）和安全套接层协议（SSL）是基于传输层的安全协议，它们只对TCP 连接的数据部分进行加密保护，而TCP 报头以明文形式传输。相比于IPsec 协议，TLS 和SSL 的优势在于可以与TCP 的改进方案协同工作，从而提高TCP 在无线网络中的性能和可靠性[5,7]。因此，TLS和SSL可以代替IPsec，使网络中的中间节点可以对TCP 报头进行操作，以便更好地支持无线网络。然而，该方案存在些许缺点，由于TCP 报头和IP 报头都通过明文形式在网络传输，攻击者可以轻易地获得通信双方的身份信息，从而进行各种攻击，如欺骗、窃听、篡改等。此外，TLS 和SSL 也存在一些安全漏洞，如心脏滴血漏洞、POODLE 漏洞等，这些漏洞可能会被黑客利用进行攻击。因此，为了解决TCP改进方案与IPsec兼容性的问题，需要在保证通信安全的前提下，采用一些更为安全的协议来替代TLS 和SSL，以提高无线网络中TCP 协议的性能和安全性。

3.1.2 扩展ESP协议

为了在无线网络中改进TCP 协议，可采用扩展ESP协议的方案，该方案在ESP头部添加TCP源端口、目的端口、报文序号和确认序号等数据域，但只对这些数据进行完整性保护而不进行加密，这样网络中间节点可以获取这些数据，从而TCP 在无线网络中的改进方案能够正常工作，如Snoop方案[5,7]。然而，该方案存在一些缺陷，如不允许中间节点对TCP 报头进行修改操作，无法提供端到端的加密保护等。因此，在选择安全方案时，需要考虑网络环境、应用需求和安全性要求等因素，如需要高度保密和防篡改，可选择IPsec 协议提供更高的安全性；如果网络环境较差，可采用TCP协议的改进方案提高网络的性能和可靠性。同时，及时更新安全协议和软件也很重要，以防止安全漏洞被黑客利用。

3.1.3 对TCP路径分段

一条TCP会话的通信路径通常包括无线网络和有线网络两个部分。其中，无线网络连接移动主机和基站之间，在移动过程中会经历多个基站之间的切换。有线网络连接基站和远端固定主机之间，通常通过Internet 或局域网等网络进行连接。如果用户信任无线网络的安全性，则可以使用链路层安全协议来提高TCP性能，并使用IPsec协议来保护有线网络的数据传输安全性。IPsec协议提供了端到端的数据加密、认证和完整性保护功能，可以确保数据传输的安全[7]。然而，TCP 改进方案通常只在移动主机和基站之间的无线网络上运行，不涉及基站和远端固定主机之间的有线网络。为了确保通信安全并避免IPsec 与TCP 改进方案之间的冲突，可以采用链路层的安全协议和IPsec协议来保护数据传输的安全性，这种方法可以同时确保通信的安全和TCP的性能。该方案的局限性在于需要对无线网络完全信任，如果无线网络出现问题，则可能会导致通信的安全性受到威胁。

上述3 种解决方案都存在一定的限制，需要进一步研究来解决IPsec与TCP改进方案之间的冲突问题。改进方案需要尽量减少对IPsec安全性能的影响，以确保通信的安全性。要综合考虑安全性、性能和实现难度等因素，以找到最优的改进方案。

3.2 视频监控系统编解码兼容性分析

视频监控系统的数据采集、存储、调取、查看作为核心功能，将能够根据硬盘容量大小进行滚动覆盖式循环存储；不同的监控系统应具有良好的兼容性，以实现不同区域间的互联互通、分级控制管理和流媒体信息共享。

H.264编解码产品的兼容性包括2个方面，性能和功能，最终评价指标将由两者按一定的规则评分综合构成。

功能方面主要是对必需服务进行确认和评估，包括设置和控制远程编解码设备、云台矩阵等参数。

性能方面包括H.264 标准语法检验、产品间互编互解和编解码质量。语法检验判断其是否满足H.264标准，产品间互编互解体现其兼容能力，编解码质量判断其主/客观视频效果。

H.264标准语法检验是一种检查编码产品输出的视频码流是否符合H.264 标准语法定义的方法[8]。为了确保编码产品输出的H.264 基本视频流是标准的H.264 码流，可以采取用H.264 标准组织的JM 测试和第三方评价软件的方法来共同判断。在产品开发周期中，产品间的互编互解是一种理想的工作方式，可以大大降低后续系统开发的复杂度和成本，同时也便于统一管理。通过互编互解，不同厂商开发的产品可以相互测试和验证编解码的正确性和兼容性，确保产品之间的互通性和互操作性，从而提高整个行业的标准化水平。然而，大部分厂商采用的技术和使用范围各有不同，往往给互编互解造成麻烦。

目前大多数H.264 产品之间尚不能实现互编互解、无法兼容，其原因主要有3 个方面：一是编码产品输出尽管符合H.264 标准码流，但由于其所采用的H.264标准的规范（Profile）和等级（Level）不同，其他解码产品其所支持的H.264 规范（Profile）和等级（Level）有限造成不能够正确解码；二是编码产品输出符合H.264标准码流，其数据封装格式不兼容（如采用TCP/IP、UDP/IP、是否加有RTP/TS/PS 流等），造成无法实现互联互通；三是编码产品在H.264 基本码流或传送包中加有自己的私有信息。

因此，在通过了H.264 语法校验后要进行互联互通测试，编解码器间的互通性测试通常可以采取以下两种方式。（1）相同码流和传输格式测试：将所有编解码器配置成相同的码流和传输格式，检测其是否能够实现互联互通。这种方式可以验证编解码器的基本兼容性，但是无法检测不同厂商的私有扩展功能是否兼容。（2）H.264 标准码流测试，即清除数据封装，输出H.264标准码流，测试是否可以被各种设备和软件系统兼容。

除了完成编解码硬件产品的互联互通测试之外，编码器与软件解码的兼容性测试也是一项非常重要的内容，软件解码可将视频流送到PC桌面上，通过PC工作站直接观看和访问控制各个不同的远端视频监控点。该项测试需要各个编码器厂商提供各相应的软解码SDK，从而用这些SDK 开发测试软件来接收不同厂商的编码器视频流，判断兼容性。为便于开发和应用，传输协议和传输方式最好能够对用户透明，用户只需要指定数据封装格式和传输方式SDK 就可以完成H.264解码和显示，并且应该具备编码器、云台、矩阵参数设置和控制等功能。这样，视频编解码兼容性和功能兼容性都可以得到测试。

评判一个视频产品，除了兼容性之外，其视频质量也是一个非常重要的技术指标。视频传输质量受编码、传输和解码等多种条件影响，但主要体现在编码方面。视频压缩传输技术的实质是在不超过规定码率的条件下，使压缩传输后的图像质量达到最好，且传输延时在允许的范围以内[9]。虽然每个厂家所采用H.264标准算法是一致的，但其码流控制技术的不同将导致最终视频图像的质量和传输结果有很大的差异。尽管码率控制不是H.264 标准所规定的内容，但却是每个厂家在视频通信产品研发中必不可少并且充分体现其产品性能差异的关键技术之一。

为了保证编解码测试的准确性和可比性，测试应该在相同的H.264 编码条件下进行，并考虑不同码率对测试结果的影响；同时，还需要对各个产品的主观和客观质量进行评估。除了视频质量外，编解码器的码率控制性能也是测试中需要考虑的因素之一。码率控制性能可以反映编解码器在不同码率下的表现和稳定性。主观质量可以采用MOS多人打分评判，客观质量可以采用有参考的视频质量PSNR和无参考视频质量PSNR来进行评判，同时应该考虑到主客观质量吻合程度。例如可采取如下评价方法：在各组码率条件下分别计算“客观质量得分码率控制得分”后得到平均得分，同时将主观质量与客观质量对比验证并根据吻合性进行部分修正后综合评价。

4 结语

本文分析了依托首制船的网络化服务平台系统组件兼容性，对船上网络化服务平台与设备组件进行重点分析，并提出了相关兼容性重点问题；介绍了首制船网络化服务平台、组件等集成时需要考虑的兼容性问题，包括软件类兼容性、硬件类兼容性、网络协议类兼容性等，为船上网络化服务平台相关设备及硬件的研发、集成提供理论基础。