严新平院士团队 :面向新一代航运系统的软件定义智能船舶航行控制进展

软件定义是指在硬件资源数字化、标准化的基础上，通过应用编程接口(Application Programming Interface, API)实现计算、存储、网络等基础资源的管理和调用，从而根据需求动态改变资源，实现灵活配置。软件定义理念最早由互联网工程任务组于1985年提出，并成功应用于无线电领域。软件定义无线电的成功实践，引发了各行业对软件定义架构的探索和研究。软件定义理念逐步拓展并形成了软件定义网络、软件定义卫星、软件定义装备、软件定义汽车以及软件定义城市等应用领域，如图1和表1所示。

图1 软件定义应用领域

表1  软件定义应用领域、场景及特征

软件定义技术通过与不同行业的固有特点深度融合，实现了系统灵活性、可扩展性与智能化的飞跃。如表1所示，各应用领域均展现出其独特的场景与特征。在软件定义网络方面，2010年斯坦福大学McKeown教授提出软件定义网络(Software Defined Network, SDN)的概念，将网络控制与数据转发分离，体系结构分为数据层、控制层和应用层，已成功应用于传感器网络、智能船舶网络、无人机组网等领域，如图2所示。

图2 SDN体系结构

在软件定义装备方面，2009年美国国防研究与工程局提出开放式雷达体系结构，实现软硬件隔离，解决了维护升级困难、研制周期长等难题。随后美国国防部启动了软件定义无人装备集群研制工作，并于2017年提出“马赛克战”概念。在软件定义汽车方面，百度公司提出软件定义汽车的概念，华为公司推出“计算+通信”组件应用架构，采用“以太环网+区域控制器”构建车内通信架构。在软件定义卫星方面，2018年龙江二号微卫星搭载了软件定义无线电，2019年中国发射首颗软件定义卫星“天智一号”，2021年欧洲Quantum卫星借助灵活基带软件实现在轨通信功能重构与升级。在软件定义城市方面，东软集团已参与中国200多个中心城市的智慧应用建设。上述各领域的成功实践表明，软件定义理念已成为推动行业智能化转型的关键路径。

国外方面，挪威Kongsberg公司的综合平台管理系统通过冗余的大通信宽带网络系统集成了船舶导航、动态定位、推进控制和机舱自动化等独立子系统，采取分布式控制策略和通用的通信协议，实现了各子系统间的数据信息交互。德国SAM公司基于开放式体系研发了综合平台管理系统，在船舶网络框架下，各设备依据不同功能被分类集成为相应的系统。同时，该系统遵循统一的操作和设计方式，使用通用的硬件平台，降低了设备安装维护难度、备件数量和人员培训成本，从而实现降本增效。日本启动“智能船舶应用平台”项目并搭建了服务于各应用系统的统一数据交互平台，实现了智能航行、智能机舱、智能能效和远程维护管理等功能。日本未来科技公司推出船舶物联网平台，利用物联网技术在亚马逊网络服务上实时积累数据，如航行路线、燃料消耗、天气和海洋信息等。该平台以船舶数据为起点，提供安全、低油耗的航行路线和故障预兆检测等，能够实现船岸一体化的数据协作运营和船舶相关周边服务的优化。韩国现代重工与埃森哲公司合作推出OceanLink智能船舶平台，可通过传感器和数据分析软件，实时跟踪船舶的状态，获得船舶的位置、设备、货舱状态等信息，为用户提供船舶运营优化服务。

国内方面，2015年发布的《智能船舶规范》首次从顶层设计出发，将智能船舶划分为智能航行、智能船体、智能机舱、智能能效管理、智能货物管理和智能集成平台六大功能模块，为软件定义船舶理念提供了系统框架。2016年启动的“智能船舶1.0”专项，进一步提出“1+N”技术架构并推动实船验证。2019年，工业和信息化部、交通运输部、国防科工局联合印发《智能船舶发展行动计划(2019-2021年)》，明确提出推动船用设备智能化升级围绕智能船舶辅助决策、自主控制等功能需求，系统梳理感知与控制基础元器件技术要求，着重补齐短板，强化综合集成，推动船舶航行、作业、动力等相关设备的智能化升级，研制信息和控制高度集成的新型船用设备，全面提升船舶智能化水平，强调扩大典型智能船舶“1个平台+N个智能应用”的示范推广。2021年提出的“岸基驾控为主、船端值守为辅”的新一代航运系统构架，革新了传统的船员操控航行模式，使环境感知、规划决策与运动控制等核心功能逐步从船端转移至岸基智能设备与系统。

（2）船舶电子电气架构演进

电气与电子架构最初由汽车行业提出，其核心是采用模块化系统设计，通常划分为环境感知、信息评估、规划与决策、车辆控制以及人机交互等关键功能模块。随着软件定义理念的发展，EEA被引入船舶工业领域，并引领船舶EEA的重构与升级。船舶EEA作为智能船舶的神经系统，负责将全船的传感器、电子控制单元(Electronic Control Unit, ECU)、线束拓扑和能源分配系统整合为统一整体，实现运算、动力与能量的协同分配，是支撑船舶智能功能实现的基础。随着智能船舶的发展，船舶EEA逐步从分布式、域集中式控制、向中央集中式的架构演进，如图3所示。

1) 分布式EEA：此阶段船舶主要实现基础的辅助驾驶功能。智能化控制主要依赖堆砌独立的ECU来实现，呈现出软硬件紧密耦合、缺乏统一中间件层的特征。虽然这种架构开发门槛低、周期短，能满足早期自动化需求，但其弊端日益凸显：各ECU之间算力无法协同形成“数据孤岛”，导致资源极大浪费；异构的软件框架使得外部开发者难以进行统一维护和在线升级(Over-the-Air, OTA)；此外，点对点的复杂通信需求导致线束成本高昂且装配困难。

2) 域集中式EEA(面向功能的架构阶段)：域集中式EEA将船舶划分为智能航行、智能能效、智能机舱等智能系统，各域智能系统作为区域性的计算与决策中心，负责域内传感器数据的融合与闭环控制；而智能集成平台则扮演全船信息枢纽的角色，负责跨域的信息集成与数据交换。域集中式架构有效缓解了传统分布式架构中算力分散与通信带宽不足的问题，既能满足特定功能的高实时性需求，又避免了全船级架构重构的高昂成本，是智能船舶由L2向L3过渡的阶段的主流技术路线。

3) 中央集中式EEA(面向服务的架构阶段)：中央集中式EEA打破传统的“系统”边界，转而采用区域控制器，并将全船的核心算力汇聚至中央计算平台，呈现出算力集中化、软硬件解耦及平台标准化的核心特征。中央集中式EEA通过高速以太网骨干和SOA，能够实现跨域数据的深度融合与全局资源调度，使船舶具备“类脑”思考能力，从而满足高阶自主航行对强实时感知、多维决策融合及软件持续迭代和拓展。这种架构是支撑船舶迈向L3及L4等级的关键基石。

图3 智能船舶EEA演进路线图

综上所述，域集中式架构主要解决了分布式阶段系统“离散与无序”的问题，通过系统模块化显著提升了集成度，而中央集中式架构则进一步解决物理层面的“冗余与繁重”及计算层面的“迟滞”问题，通过精简线束拓扑与聚合高性能算力，为实现船舶更高自主等级的智能航行奠定了物理基础。在此演进过程中，SOA是中央集中式EEA实现软硬件解耦与功能重用的关键技术手段。尽管SOA在信息技术(Information Technology, IT)领域已应用成熟，但受限于船舶行业在标准框架、底层硬件及通信协议等方面产业生态链尚不成熟。未来，在智能船舶云计算阶段，船舶部分功能转移至云端，智能船舶的各种传感器和执行器可被软件定义和控制，船舶的零部件逐步变成标准化，彻底实现软件定义船舶功能。

（3）既有智能船舶航行控制系统局限

如表2所示，IMO将船舶划分为具有自动化流程和有船员决策支持的自主船、有船员可遥控的船、无船员的遥控船和完全自主船舶4个等级，并明确指出船舶在单次航程中可在不同等级间动态切换，揭示了未来船舶航行控制必须具备高度的灵活性、可重构性和智能演进能力。

表2  船舶智能航行等级划分

当前，船舶智能航行的发展仍主要集中在L2-L3阶段。智能船舶作为新一代航运系统的核心载体，其智能航行功能的实现高度依赖于底层硬件设施。具体而言，船舶所搭载的传感器与执行器的类型与数量，直接决定了航行控制系统的能力边界。在硬件基础之上，系统（软件）则成为影响船舶智能航行功能与性能水平的核心要素，实施环境感知、路径规划、路径跟踪、自主避碰决策与运动控制等关键任务。然而，当前船舶的设计与制造模式存在显著制约。船舶制造通常由船厂集成来自多个供应商的各类设备与部件，包括雷达、主机等，这种组装式生产模式使得既有智能船舶航行控制系统智能化升级面临系列问题：

1) 底层的控制器非常之多，且全部由供应商各自管理自己的软件和硬件，导致系统整体难以统一维护与升级，形成“信息孤岛”；

2) 控制器与控制器的连接是由具有公共协议接口的网关实现的，任何调整都会影响到所有其他控制器，显著增加系统集成与迭代的复杂度；

3) 控制器很难单独连接到互联网，都需要逐个单独连接进行更新，导致软件维护效率低下，难以实现远程、快速的功能迭代与安全补丁部署；

4) 一个功能涉及到多个控制器一起调整，各种供应商会相互制约，严重阻碍系统整体功能的优化与新功能的引入。

这些问题导致了既有智能船舶航行控制系统难以根据多变的航行任务、实时船舶状态或更新的海事法规进行快速优化，无法高效地进行功能实现和功能迭代，也限制了船舶智能航行控制系统向更高自动化等级的平滑演进。新一代航运系统的建设离不开船舶智能设备的发展，亟需构建标准化、模块化、谱系化的船舶智能设备与系统技术体系，发展软件定义智能船舶航行控制势在必行。

基于中央集中EEA的软件定义智能船舶航行控制架构由用户端、云控端、船舶端、岸基端以及应用层、控制层、设备层构成，如图4所示。通过端间的协同与层间的解耦，实现从用户任务意图到船舶物理执行的端到端闭环，进而达成资源全局优化、功能弹性部署与系统持续演进的核心目标，最终支撑船舶多任务场景下的动态功能组合与按需服务。

图4 基于中央集中式EEA的软件定义智能船舶航行控制架构

（1）用户端

用户端是系统与用户（船东/船企）的直接交互界面，是航行任务的指令输入枢纽与全局态势的可视化窗口。其核心职能在于将用户的业务意图转化为系统可识别、可执行的航行任务指令，向云控端提交定制化的航行任务（如“点对点节能航行”或“特定时间窗口抵港”），实时接收并展示来自云控端的任务执行状态（如进度、预计抵达时间）、船舶实时态势（如船位、航速、设备状态），从而确保用户能够实时追踪船队的位置，在任务全周期内掌握船舶航行动态，为运营决策提供数据支持。

（2）云控端

云控端是驱动整个航行控制架构的“智慧大脑”，承担全局资源解析、智能计算、任务规划、资源编排等核心职能。它接收用户端的任务指令，解析来自船舶端（船舶状态、设备健康度）与岸基端（气象、航道、港口调度）的多源资源信息。云控端主要在全球范围内执行数据处理、云服务管理、资源监控与编排以及任务管理等任务，作为系统的数据中心、管理中心和决策中心，从而确保船-岸-云协同计算架构的高效运行。在此过程中，超算中心依托其大数据中心提供全域数据基底，借助算法模型库实现模型驱动的决策优化，生成最优的航行策略与资源分配方案。最终，规划好的航行策略被下发至船舶端执行，船舶状态以及岸基调度信息同步至岸基端，以支持全局航行监管与交通组织优化。

作为云控端的知识基底，大数据中心汇聚了多源历史与实时数据，包括全球海图、水文气象、港口信息、船舶性能数据、航行案例库等。算法模型库则存储和迭代优化各类智能算法，如深度强化学习路径规划模型、高精度船舶运动模型、设备预测性维护模型等。

（3）船舶端

船舶端是航行任务的直接执行者，负责承载具体的航行操作，在复杂海洋环境中安全、智能航行。它向云控端上传本船的基础资源信息，并接收来自云控端的航行指令。

船舶端内部采用应用层-控制层-设备层三层结构，实现控制逻辑与物理硬件的彻底解耦。其中，应用层接收来自云控端的航行指令，提供满足船舶智能航行控制需求的服务应用（如路径规划、路径跟踪）。它可以向控制层发送各种计算任务请求，控制层调度云计算、边缘计算和本地计算等资源来执行任务，并确保应用服务的及时交付。船端的控制层由船舶中央网关控制器及其下属的功能域控制器（感知域、航行控制域、通信域）构成，可以通过软件编程实现，将设备层的物理设备（舵、推进器等）抽象为统一的逻辑信号，并生成具体的控制指令（如舵角、转速设定值）。船端的控制层通过接口与设备层和应用层相连接，并通过网络控制岸基端和船舶端的计算环境，以实现船-岸-云协同计算控制。设备层作为物理实体，包括传感器、执行机构及船载计算硬件等，通过以太网、CAN总线等网络架构连接，收集并传输资源、网络和设备的状态信息至控制层，同时接收来自控制层的控制指令或策略以处理和执行数据。负责接收并执行控制层的标准化指令，完成船舶最终的物理动作。

（4）岸基端

岸基端是一种部署在航道沿岸或港口区域的计算与服务实体。作为软件定义船舶智能航行控制的支持与协作中心，为船舶航行提供岸基保障和增值服务，它向云控端输入岸基设施信息，并根据云控端的航行指令，进行全局航行监管与交通组织优化，有助于优化岸上资源调度，以实现跨区域协作。同时，岸基端负责结合场景需求，必要时实现不同航行模式的安全切换。

为支撑上述三层结构落地，本文架构在物理实现上采用了基于功能域的集中式电子电气架构，如图5所示。整船层面设置中央网关控制器作为核心枢纽，并依据功能特性将底层硬件划分为三大核心功能域控制器：

感知域：集成摄像机、激光雷达、毫米波雷达及航海雷达等，实现多源异构数据的采集，为船舶提供全方位、多维度的环境态势数据。

航行控制域：直接连接并管控发动机、电机等动力源，以及螺旋桨、推进器等操舵执行机构，依据上层决策指令精确调节航速与航向。

通信域：管理4G/5G、海事卫星、北斗、VDES、TD-LTE等多模态链路，负责带宽调度与链路优选，确保船-岸-云数据交互的实时性与稳定性。

图5 基于中央集中式EEA的软件定义智能船舶航行控制功能域划分

基于中央集中EEA的软件定义智能船舶航行控制架构通信网络设计分为域内骨干网络与外部协同网络两个层面。

船舶内部网络采用“中央网关-域控制器-ECU”的层级拓扑。传统的传输控制协议(Transmission Control Protocol, TCP)/互联网协议无法满足高同步性和高实时性的控制要求，通过中央网关控制器来完成整个网络内的时间同步，以满足低延迟和更高鲁棒性的要求。在骨干网层面，中央网关与各域控制器之间采用高带宽以太网作为主干链路。域内网络依据数据吞吐量与可靠性需求进行差异化配置。针对视觉感知与雷达点云数据，采用以太网或低压差分信号(Low Voltage Differential Signaling, LVDS)通信。LVDS凭借其低功耗、强抗干扰及高速率特性，专门用于传感器原始视频流的无损传输。针对推进器、舵机等关键执行机构，沿用成熟的CAN总线，利用其高抗噪性确保控制指令的可靠传输。针对交换机状态监测及非关键传感器，采用LIN总线以降低线束与节点成本。域内的设备连接到两条通信总线，数据通过总线传输到中央网关控制器进行统一清理和处理。成本实现可行性方面，架构能够实现性能与成本的最佳平衡，既利用了以太网的高带宽解决了智能化带来的数据传输瓶颈，又最大限度地沿用成熟且低成本的CAN/LIN总线方案。

图6  船舶航行实时通信网络

外部通信网络旨在构建“船-岸-云”协同体系，如图6所示。通过集成4G/LTE/5G/WiFi/甚高频(Very High Frequency, VHF)/通信卫星等多种通信手段，依据覆盖范围、带宽需求与通信成本执行多模态链路的智能切换策略。如表3所示，近岸/港区/内河场景优先接入5G/4G及WiFi网络，利用其高带宽、低时延特性，支持高清视频流实时回传、航行大数据转存及远程实时驾控。远海航行场景切换至通信卫星链路。在保障核心控制指令与关键状态数据连通性的同时，适应远海覆盖需求。法定安全通信始终保留VHF/AIS链路，作为避碰与航行安全的法定保底手段。外部通信网络将依据覆盖范围、带宽需求与通信成本进行多模态链路的智能切换，如表3所示。

表3  船舶通信特征与应用场景分析

(1) 单船路径跟踪性能测试

在无额外网络延迟与丢包的受控环境中，开展了单艘无人船艇跟踪“∞”字形路径的任务。结果如图7所示。

图7 单船性能测试结果

实际跟踪轨迹与预设路径高度吻合。跟踪误差数据显示，无人船艇能够精确跟踪复杂曲线，最大跟踪误差约为1.5 m，平均误差维持在较小范围内，表明该架构具备良好的控制精度。网络往返时延统计显示，在受控环境下通信延迟稳定，为控制指令的实时传输提供了保障。

(2) 多船协同编队控制测试

通过逐步增加受控船舶节点的数量，验证了云控端在多任务并发下的调度能力。如图8所示，分布在不同起始位置的船舶能够保持编队队形并同步跟踪“∞”字形路径。

图8 多船编队控制测试结果

云控端的资源负载情况显示：在正常运行期间，计算负载较低，资源占用处于合理范围；随着受控节点增加，CPU利用率呈线性增长趋势，内存占用增长平缓。这一结果证明，该架构具备良好的可扩展性，能够支撑大规模船队的协同编队控制。

(3) 网络化控制测试

开放和网络化的软件架构使得通信易受到网络攻击。本试验模拟了混合网络攻击场景（包括数据丢包与虚假数据注入）。结果如图9所示。

图9 网络化控制测试结果

在攻击初期，由于数据包丢失导致控制偏差瞬时上升，但随后呈现下降趋势并回归稳定状态。事件触发机制在网络环境恶化时降低了非关键数据的发送频率，有效过滤了冗余数据包。CPU利用率在遭受混合攻击时显著飙升，但系统并未崩溃，而是在弹性控制机制下维持了基本功能。这一结果表明，该架构具备网络弹性防御能力，能够应对高负载或攻击环境下的系统可用性挑战。

如图10所示，软件定义智能船舶航行控制将原本由PLC承担的计算决策与控制功能，迁移至部署在云端或本地服务器的软件模块中，通过将船舶的控制逻辑与物理硬件解耦，解决了传统系统软硬耦合的难题，使其具备了灵活性、可重构性、可扩展性与易维护性的特性。与传统航行控制系统相比，本文提出的架构具有三大核心特征：

（1）控制功能与物理执行解耦

通过应用层-控制层-设备层的分层设计，高层控制逻辑被抽象为可复用、可组合的软件化服务，独立于底层特定硬件进行开发与迭代。这一设计显著提升了系统的灵活性与可靠性：一方面，支持控制算法的快速在线升级与扩展；另一方面，当特定物理设备发生单点故障时，系统可基于最终有效指令或预设降级策略维持航行能力。

（2）开放可扩展的体系架构

在软件层面，通过标准化的API，系统能够无缝集成第三方算法与服务至云控平台，持续丰富智能模型库；在硬件层面，推动船舶设备朝通用化、模块化发展，使得新增功能无需改变船载硬件基础，仅需在应用层部署或更新相应服务即可实现。

（3）面向任务的按需服务与动态重构

系统在云控端的全局调度下，能够依据特定航行任务从虚拟化的资源池中动态抽取、组合并实例化所需的软件服务，快速构建一个与航行任务目标高度匹配的临时“虚拟控制系统”。这一过程确保了在不同任务阶段或模式间切换时，系统功能与控制回路的平滑过渡。

图10 硬件架构图：传统航行控制系统与软件定义智能航行控制系统对比