Tugboat network system and data processing method

Abstract

The invention provides a tug network system and a data processing method, and relates to the technical field of tugs. The tug network system comprises a main server, a plurality of switches and a plurality of ship subsystem devices, the plurality of switches form a ring network based on an Ethernet ring protection switching protocol, a first switch in the plurality of switches is in communication connection with the main server, and a second switch in the plurality of switches is in communication connection with the ship subsystem devices. At least part of target switches in the plurality of switches are in communication connection with the ship subsystem equipment; each target switch is used for receiving the ship subsystem real-time data collected and sent by the corresponding ship subsystem equipment, and forwarding the ship subsystem real-time data to the first switch along an unblocked physical shortest path in the ring network; the first switch forwards the real-time data of the ship subsystem to the main server; and the main server is used for generating a first auxiliary driving instruction according to the real-time data of the ship subsystem, so that ring network redundancy can be realized, the communication reliability can be improved, the hardware modification cost can be reduced, and the expansibility can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of tugboat, in particular to a tugboat network system and a data processing method. BACKGROUND

[0002] With the development of new energy ship technology and the improvement of port intelligence level, as the key power equipment in port operation, the reliability, real-time performance and intelligence level of the tugboat driving control system directly affect the navigation safety and operation efficiency.

[0003] In the prior art, the tugboat network system usually adopts a star network architecture for communication control, wherein the star network architecture mainly relies on a central switch, and once the central node fails, the whole system will be paralyzed, especially in a dense port operation environment, network interruption may cause safety accidents such as emergency obstacle avoidance failure and command delay, in addition, based on the star network architecture, when new equipment is added, the wiring needs to be re-arranged or the switch port needs to be expanded.

[0004] It can be seen that the existing tugboat network system has poor reliability and the expansion mode is not flexible. SUMMARY

[0005] The present application aims at the deficiencies in the prior art, and provides a tugboat network system and a data processing method, which can realize ring network redundancy, improve communication reliability, reduce hardware modification cost and improve expandability.

[0006] To achieve the above object, the technical scheme adopted by the embodiments of the present application is as follows: In a first aspect, the present application provides a tugboat network system, comprising a master server, a plurality of switches and a plurality of ship subsystem devices, the plurality of switches are connected to form a ring network based on an Ethernet ring protection switching protocol, a first switch in the plurality of switches is in communication connection with the master server, and at least part of target switches in the plurality of switches are in communication connection with the ship subsystem devices, and each target switch and its corresponding ship subsystem device constitute a ship subsystem subnetwork. Each target switch is configured to receive ship subsystem real-time data collected and sent by the ship subsystem device corresponding to the target switch, and forward the ship subsystem real-time data to the first switch along the physical shortest path in the ring network which is not blocked. The first switch is configured to receive the ship subsystem real-time data forwarded by each target switch through the ring network, and send the ship subsystem real-time data to the master server. The master server is configured to receive the ship subsystem real-time data sent by the first switch, and generate a first auxiliary driving instruction according to the ship subsystem real-time data.

[0007] In an optional implementation, the tugboat network system further comprises: a backup server, the backup server and the master server constitute a server cluster, and the backup server and the master server communicate based on a heartbeat mechanism; a second switch in the plurality of switches is communicatively connected to the backup server. Each of the target switches is further configured to receive the real-time ship subsystem data collected and transmitted by the ship subsystem device corresponding thereto, and forward the real-time ship subsystem data to the second switch along a physically shortest path in the ring network that is not blocked. The second switch receives the real-time ship subsystem data forwarded by each of the target switches through the ring network and transmits the real-time ship subsystem data to the backup server. The backup server is configured to receive the real-time ship subsystem data transmitted by the second switch, and when the master server is determined to be faulty based on a heartbeat communication mechanism, generate a second auxiliary driving instruction based on the real-time ship subsystem data.

[0008] In an optional implementation, the real-time ship subsystem data comprises at least one of: self-ship condition data, surrounding ship information, water area geographic information, meteorological and hydrological data, and energy state data, and the master server comprises a path planning module. The master server is further configured to receive the real-time ship subsystem data transmitted by the first switch, and based on the real-time ship subsystem data, output an optimal route from a preset starting point to a preset ending point through the path planning module.

[0009] In an optional implementation, the master server is specifically configured to calculate and obtain the optimal route based on the real-time ship subsystem data, the preset starting point, and the preset ending point through the path planning module, the optimal route being a shortest route after avoiding a risk area.

[0010] In an optional implementation, the real-time ship subsystem data comprises at least one of: energy system information, main propulsion engine information, and rudder information, and the master server comprises a fault prediction model. The master server is further configured to receive the real-time ship subsystem data transmitted by the first switch, and based on the real-time ship subsystem data, output an early warning information through the fault prediction model.

[0011] In an optional implementation, the tugboat network system further comprises: a first display screen, the first display screen being communicatively connected to the master server, and the first display screen being configured to display at least one of the following information transmitted by the master server through a preset ring network management software: the optimal route, the early warning information, ring network topology information, a ship subsystem device state, a switch state, and a server state.

[0012] In an optional embodiment, the first auxiliary driving instruction comprises a propeller power adjustment instruction and / or a heading adjustment instruction. The main server is further configured to send the propeller power adjustment instruction and / or the heading adjustment instruction to the first switch. The first switch receives the propeller power adjustment instruction and / or the heading adjustment instruction sent by the main server, and sends the propeller power adjustment instruction to a first target switch along an unblocked physical shortest path, and / or sends the heading adjustment instruction to a second target switch, wherein the ship subsystem device corresponding to the first target switch comprises a propeller controller, and the ship subsystem device corresponding to the second target switch comprises a rudder controller.

[0013] In an optional embodiment, the main server comprises a first network card and a second network card, a first switch in the plurality of switches is communicatively connected to the main server through the first network card, and a third switch in the plurality of switches is communicatively connected to the main server through the second network card. The third switch is configured to, when determining that the first switch is faulty, receive the ship subsystem real-time data forwarded by each target switch through the ring network, and send the ship subsystem real-time data to the main server through the second network card.

[0014] In an optional embodiment, the first switch is further configured to, when recovering from a fault state to a normal state, receive the ship subsystem real-time data forwarded by each target switch through the ring network, and send the ship subsystem real-time data to the main server through the first network card.

[0015] In a second aspect, the application provides a data processing method applied to a main server in the tugboat network system of any one of the preceding embodiments, and the method comprises: receiving ship subsystem real-time data sent by a first switch, wherein the ship subsystem real-time data is forwarded by each target switch to the first switch along an unblocked physical shortest path in the ring network after receiving ship subsystem real-time data collected and sent by a ship subsystem device corresponding to the target switch; generating a first auxiliary driving instruction according to the ship subsystem real-time data.

[0016] The application has the following beneficial effects: The tugboat network system and data processing method provided in this application embodiment include: a main server, multiple switches, and multiple ship subsystem devices. The multiple switches form a ring network based on an Ethernet ring protection switching protocol. The first switch among the multiple switches is communicatively connected to the main server, and at least some of the target switches among the multiple switches are communicatively connected to the ship subsystem devices. Each target switch and its corresponding ship subsystem device constitute a ship subsystem subnet. Each target switch is used to receive real-time ship subsystem data collected and sent by its corresponding ship subsystem device, and forward the real-time ship subsystem data to the first switch along the unblocked physical shortest path in the ring network. The first switch receives the real-time ship subsystem data forwarded by each target switch through the ring network and sends it to... The main server receives real-time data from the ship's subsystems sent by the first switch and generates first auxiliary driving commands based on the real-time data. In this embodiment, multiple switches are configured to form a ring network to achieve ring network redundancy, improving communication reliability. Ship subsystem devices can flexibly access the subnet switches via standard Ethernet interfaces, resulting in low hardware modification costs and strong scalability. Introducing a server as a data processing center enables centralized computing, integrating multi-source data, supporting data fusion, avoiding data silos, reducing cross-device collaboration latency, improving computing power utilization, and reducing energy consumption. Compared to a distributed architecture, it eliminates the need to deploy multiple industrial control computers; the server and ring network switches can be integrated into a modular cabinet, reducing hardware costs and significantly improving space utilization. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A system architecture diagram of a tugboat network system provided in this application embodiment; Figure 2 A system architecture diagram of another tugboat network system provided in this application embodiment; Figure 3 A system architecture diagram of another tugboat network system provided in this application embodiment; Figure 4 This application provides a data interaction method based on a tugboat network system. Figure 5 A flowchart illustrating a data processing method provided in an embodiment of this application; Figure 6 This is a schematic diagram of an electronic device structure provided in an embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0020] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0021] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0022] In related technologies, tugboat network systems mostly adopt a star network architecture for communication and control. This star network architecture relies heavily on a central switch; a failure of the central node can paralyze the entire system. Especially in the intensive operation environment of ports, network outages can lead to safety incidents such as emergency obstacle avoidance failures and command delays. Furthermore, with a star network architecture, adding new equipment requires rewiring or expanding switch ports. Existing systems may face integration difficulties due to incompatible interface protocols (such as a mix of analog and digital signals), making it difficult to quickly adapt to the intelligent upgrade requirements of new energy tugboats. Therefore, existing tugboat network systems have poor reliability and lack flexibility in expansion methods.

[0023] In addition, some existing technologies also set up tugboat network systems based on single-link connections (such as single switches or single servers). In this case, a single point of failure in the single-link connection method can easily lead to the paralysis of the entire system, which cannot meet the operational requirements of "never-interrupted" communication of tugboat network systems.

[0024] Some existing technologies employ a distributed computing model to construct tugboat network systems. However, in this model, ship subsystems communicate directly with the industrial control computer (ICC), which processes data independently. Cross-system collaboration (such as navigation and propulsion control linkage) suffers from latency, making it difficult to meet real-time requirements. Furthermore, distributed architectures often require the deployment of multiple ICCs, switches, and independent power modules, occupying 2-3 cubic meters of cockpit space, which is incompatible with the "miniaturization and integration" of new energy tugboats. The distributed computing approach suffers from several drawbacks: conflicting trends and large space requirements; data silos exist, with data from various subsystems (such as navigation, propulsion, and energy) scattered across independent industrial control computers, lacking unified storage and analysis, and unable to achieve cross-system linkage (such as combining battery status with navigation route optimization); each subsystem in the distributed architecture is equipped with an independent industrial control computer, resulting in hardware redundancy that increases costs by 30%-50%, and computing power cannot be shared (e.g., when one industrial control computer is overloaded, other industrial control computers are idle), leading to serious waste of computing resources; distributed hardware redundancy increases standby power consumption (e.g., multiple industrial control computers running 24 hours a day), resulting in low energy efficiency; switching between primary and backup devices mainly relies on manual intervention (e.g., after the primary server crashes, the backup machine needs to be manually started), with switching times reaching several minutes, which may cause accidents in emergency scenarios and delay emergency response.

[0025] In summary, it can be seen that the existing methods of constructing tugboat network systems using distributed computing models have problems such as poor real-time performance, large space occupation, data silos, serious waste of computing resources, low energy efficiency, high maintenance complexity, and delayed emergency response.

[0026] In view of this, this application provides a tugboat network system. This tugboat network system is built on a ring network centralized computing architecture. Multiple switches form a ring network to achieve ring network redundancy, which can improve communication reliability. By introducing a server as a data processing center to achieve centralized computing, it can integrate multi-source data, support data fusion, avoid data silos, reduce cross-device collaboration latency, improve computing power utilization, and reduce energy consumption. Compared with a distributed architecture, it does not require the deployment of multiple industrial control computers. The server and ring network switches can be integrated into a modular cabinet, which can reduce hardware costs and significantly improve space utilization.

[0027] Figure 1 A system architecture diagram of a tugboat network system provided in this application embodiment is shown below. Figure 1 As shown, the tugboat network system includes a main server 10, multiple switches, and multiple ship subsystem devices 20. The multiple switches form a ring network based on the Ethernet ring protection switching protocol. The first switch 40 among the multiple switches is connected to the main server 10, and at least some of the target switches 30 among the multiple switches are connected to the ship subsystem devices 20. Each target switch 30 and its corresponding ship subsystem device 20 constitute a ship subsystem subnet.

[0028] Among them, the tugboat network system is a network system applied to tugboats, which are small vessels with powerful engines and flexible maneuverability. They are mainly used to assist large vessels in berthing, unberthing, turning, and shifting operations in environments such as ports, docks, and narrow waterways.

[0029] Optionally, the ship subsystem equipment 20 in the tugboat network system may include: propulsion system equipment (which may include propeller controller AMS, controllable pitch propeller control unit, etc.), energy system equipment (which may include battery management system MS / EMS), navigation and communication system equipment (which may include radar, AIS, GPS / BeiDou positioning system, etc.), main engine and auxiliary engine system equipment (which may include main engine remote control system, generator controller, etc.), steering gear and side thruster system equipment (which may include rudder angle feedback device, hydraulic pump station, etc.), and environmental system equipment (which may include vibration sensor, temperature sensor, humidity sensor, smoke sensor, etc.).

[0030] In some implementations, such as Figure 1 As shown, in the tugboat network system, multiple switches can form a ring network via fiber optic cables or CAT6 network cables based on the Ethernet Ring Protection Switching (ERPS) protocol. Each switch can provide data forwarding services and has storm suppression capabilities. The main server 10 can communicate with the first switch 40 among the multiple switches, thus providing two paths between any switch and the server, achieving ring network redundancy. In the event of a single point of failure, the network automatically switches paths to ensure continuity. At least some of the target switches 30 among the multiple switches, excluding the first switch 40, can communicate with their corresponding ship subsystem devices 20 via network cables using standard Ethernet interfaces. Each target switch 30 and its corresponding ship subsystem are in the same subnet, and each subnet is connected to the ring network through the target switch 30. This enables the ship subsystem devices 20 to flexibly access subnet switches, adapt to new protocols at the software level, and has low hardware modification costs. Optionally, each ship subsystem device 20 can support protocols such as Modbus / TCP and NMEA2000.

[0031] Of course, this application does not limit the number of switches in the tugboat network system, nor is it limited to the number of switches connected to each ship subsystem device 20. The number can be flexibly configured according to the actual application scenario. It should be noted that, depending on the actual application scenario, some switches may not be connected to the ship subsystem device 20 and may mainly perform data forwarding functions. When a new ship subsystem device 20 needs to be connected, it will then be connected through the switch to form a ship subsystem subnet.

[0032] Each target switch 30 is used to receive real-time ship subsystem data collected and sent by its corresponding ship subsystem device 20, and forward the real-time ship subsystem data to the first switch 40 along the unblocked physical shortest path in the ring network; the first switch 40 receives the real-time ship subsystem data forwarded by each target switch 30 through the ring network, and sends it to the master server 10; the master server 10 is used to receive the real-time ship subsystem data sent by the first switch 40, and generate a first auxiliary driving command based on the real-time ship subsystem data.

[0033] During data communication, each ship subsystem can periodically send the collected real-time data of the ship subsystem to the target switch 30 located in the same subnet. Upon receiving the real-time data of the ship subsystem, each target switch 30 can forward the real-time data of the ship subsystem to the first switch 40 along the physical shortest path in the ring network to realize data forwarding between subnets. Based on the ring network redundancy mechanism, when the physical shortest path is blocked, each target switch 30 can automatically switch links within 50ms based on the ERPS protocol and forward the real-time data of the ship subsystem to the first switch 40 along the unblocked physical shortest path in the ring network. This can shorten the path, reduce latency, improve communication reliability, and ensure uninterrupted transmission of critical data such as radar and Beidou.

[0034] After receiving real-time data from the ship's subsystems forwarded by the target switches 30 through the ring network, the first switch 40 can directly forward it to the main server 10. At this time, the main server 10 can integrate the received real-time data from the ship's subsystems, generate a first auxiliary driving command based on a unified data platform and computing power scheduling strategy. Specifically, the first auxiliary driving command can be a navigation command, a thruster power adjustment command, a heading adjustment command, etc., which is not limited here and can vary depending on the actual application scenario.

[0035] Understandably, based on the Layer 2 network infrastructure and Layer 3 routing function of the tugboat network system, the main server 10 can obtain real-time data from all target switches 30 of the ship's subsystems. Therefore, it can uniformly parse and centrally integrate multi-source data (such as navigation and communication system data, propulsion system data, energy system data, etc.) to achieve data fusion and cross-system linkage (such as combining battery status with route optimization). Compared with the existing distributed architecture, it can avoid the introduction of multiple industrial control computers, improve computing power utilization, and reduce energy consumption. Based on centralized computing, the server can also monitor the status of equipment in real time (such as switch port traffic and server CPU load) through ring network management software, shortening fault location time and reducing dimensional complexity. Moreover, compared with the distributed architecture, there is no need to deploy multiple industrial control computers. The server and ring network switches can be integrated into a modular cabinet, significantly improving space utilization. In addition, by setting the server to energy-saving mode (such as automatic frequency reduction under low load), energy consumption can be further reduced.

[0036] It should be noted that, depending on the actual application scenario, the main server 10 can be designed based on a microservice architecture and support hardware hot-swappable functionality.

[0037] If the main server 10 receives real-time data from multiple types of ship subsystems, it can prioritize processing the higher-priority real-time data based on the preset priorities corresponding to each type of ship subsystem. For example, it may prioritize parsing alarm data and then energy system information; this is not a limitation here.

[0038] In summary, this application provides a tugboat network system, including: a main server, multiple switches, and multiple ship subsystem devices. The multiple switches form a ring network based on an Ethernet ring protection switching protocol. A first switch among the multiple switches is communicatively connected to the main server, and at least some of the target switches among the multiple switches are communicatively connected to the ship subsystem devices. Each target switch and its corresponding ship subsystem device constitute a ship subsystem subnet. Each target switch is used to receive real-time ship subsystem data collected and sent by its corresponding ship subsystem device, and forward the real-time ship subsystem data to the first switch along the unblocked physical shortest path in the ring network. The first switch receives the real-time ship subsystem data forwarded by each target switch through the ring network and sends it to the main server. The main server receives real-time data from the ship's subsystems sent by the first switch and generates first auxiliary driving commands based on the real-time data. In this embodiment, multiple switches are configured to form a ring network to achieve ring network redundancy, improving communication reliability. Ship subsystem devices can flexibly access the subnet switches via standard Ethernet interfaces, resulting in low hardware modification costs and strong scalability. Introducing a server as a data processing center enables centralized computing, integrating multi-source data, supporting data fusion, avoiding data silos, reducing cross-device collaboration latency, improving computing power utilization, and reducing energy consumption. Compared to a distributed architecture, it eliminates the need to deploy multiple industrial control computers; the server and ring network switches can be integrated into a modular cabinet, reducing hardware costs and significantly improving space utilization.

[0039] Figure 2 A system architecture diagram of another tugboat network system provided in an embodiment of this application. In optional implementations, such as... Figure 2 As shown, the tugboat network system also includes: a backup server 50, which and the main server form a server cluster, and the backup server 50 and the main server communicate based on a heartbeat mechanism. The second switch 60 among the multiple switches is connected to the backup server 50.

[0040] The backup server 50 and the primary server communicate using a heartbeat mechanism. Specifically, the backup server 50 and the primary server periodically send small probe signals (called "heartbeats") to monitor each other's operational status in real time. If the backup server 50 detects that the primary server is out of service, it will automatically take over, following the procedures described below, to ensure the normal operation of the tugboat network system.

[0041] Each target switch is also used to receive real-time data of the ship subsystem collected and sent by its corresponding ship subsystem equipment, and forward the real-time data of the ship subsystem to the second switch 60 along the unblocked physical shortest path in the ring network; the second switch 60 receives the real-time data of the ship subsystem forwarded by each target switch through the ring network, and sends it to the backup server 50; the backup server 50 is used to receive the real-time data of the ship subsystem sent by the second switch 60, and when the master server fails based on the heartbeat communication mechanism, it generates a second auxiliary driving command based on the real-time data of the ship subsystem.

[0042] The backup server 50 and the primary server can form a dual-server cluster. The backup server 50 and the primary server can share the load (load balancing) or serve as backups for each other. The backup server 50 and the primary server have similar functions, serving as the data processing center for the entire system. Optionally, in some implementations, the dual-server cluster may further include a database cluster, which can be used to store the data processed and integrated by the primary server and the data processed and integrated by the backup server 50, thereby ensuring high data availability and data consistency.

[0043] Optionally, each target switch can also forward the real-time data of the ship subsystem to the second switch 60 along the shortest physical path that is not blocked in the ring network; after receiving the real-time data of the ship subsystem forwarded by each target switch through the ring network, the second switch 60 can directly forward it to the backup server 50.

[0044] For the backup server 50, if a failure of the primary server is determined based on the heartbeat communication mechanism, the received real-time data from the ship's subsystems can be integrated. Based on a unified data platform and computing power scheduling strategy, a second auxiliary driving command can be generated to achieve automatic takeover. In some implementations, the switching time can be less than 1 second, ensuring the reliability of system operation even in the event of a primary server failure. For a description of the second auxiliary driving command, please refer to the relevant content of the first auxiliary driving command; it will not be repeated here.

[0045] Furthermore, if a network link fails during the operation of the backup server 50, the backup path can be activated within 50ms using the ERPS protocol. For further details regarding the backup server 50, please refer to the relevant sections mentioned above, which will not be repeated here. It should also be noted that in some implementations, when the primary server is operating normally, it can also synchronize its processed data to the backup server 50 in real time to enable seamless failover later.

[0046] In an optional implementation, the real-time data of the ship subsystem includes at least one of the following: its own ship status data, information on surrounding ships, geographical information of the water area, meteorological and hydrological data, and energy status data. The main server includes a path planning module.

[0047] The main server is also used to receive real-time data of the ship subsystem sent by the first switch, and based on the real-time data of the ship subsystem, output the optimal route from the preset starting point to the preset ending point through the route planning module.

[0048] It is understood that real-time data from different ship subsystems can be collected using different ship subsystem equipment. Optionally, this ship subsystem equipment can be a gyrocompass, velocimeter, multibeam echo sounder, bottom echo sounder, battery management system, etc., and is not limited here.

[0049] Optionally, the vessel's own information may include: the latitude and longitude, heading, speed, and acceleration of the tugboat itself, which can be obtained by measuring and acquiring equipment such as BeiDou / GPS, gyrocompass, and speedometer; information about surrounding vessels may include: the latitude and longitude, heading, speed, and acceleration of other vessels around the tugboat, which can be obtained by acquiring equipment such as radar and Automatic Identification System (AIS); geographical information of the water area may include: electronic nautical charts and depth maps, where electronic nautical charts can indicate channel boundaries, shoals, and prohibited areas, and can be detected by equipment such as multibeam echo sounders, while depth maps can be obtained by equipment such as bottom sounders; meteorological and hydrological data may include: wind speed, wind direction, wave height, current speed and direction, which can be measured by equipment such as anemometers; and energy status data may include: remaining battery power, charging status, and power output capacity, which can be measured by equipment such as battery management systems.

[0050] In some implementations, the path planning module can be built using a large language model or based on a pre-trained model (e.g., BERT, GPT, Dijkstra, etc.). For example, in some implementations, real-time sample data from multiple first vessel subsystems can be acquired. Each first vessel subsystem's real-time sample data can be labeled with optimal route information. The real-time sample data from each first vessel subsystem can include at least one of the following: its own vessel status data, surrounding vessel information, water area geographic information, meteorological and hydrological data, and energy status data. Based on these multiple first vessel subsystem real-time sample data, a path planning module is trained using a pre-trained model.

[0051] Optionally, after receiving the real-time data of the ship subsystem sent by the first switch, the server can input it into the path planning module, which will then perform path planning based on its internal algorithm and output the optimal route from the preset starting point to the preset ending point, the recommended speed curve, etc.

[0052] In some implementations, the optimal route can be the route with the lowest risk coefficient, the lowest energy consumption, the shortest distance, or a comprehensive optimal route with low energy consumption and high safety based on BeiDou positioning, radar data, battery power, etc. There is no limitation here. Depending on the actual application scenario, the route that best meets the user's requirements can be generated.

[0053] In some implementations, the optimal route generated by the master server can be further sent to a first display screen, where it is displayed on an electronic nautical chart. This allows the navigator to follow the optimal route in accordance with their driving expectations. Alternatively, in some implementations, the master server can also generate thruster power adjustment commands and / or heading adjustment commands based on the optimal route, enabling the navigator to make precise adjustments to the tugboat.

[0054] In an optional implementation, the main server is specifically used to calculate and obtain the optimal route based on real-time data of the ship subsystem, a preset starting point, and a preset ending point through the route planning module. The optimal route is the shortest route after avoiding the risk area.

[0055] In some implementations, the optimal route can also be the shortest route from a preset starting point to a preset ending point, avoiding risky areas or having the lowest risk factor. Of course, it should be noted that the definition of the optimal route is not limited to this and can vary depending on the actual application scenario.

[0056] In an optional implementation, the real-time data of the ship's subsystems includes at least one of the following: propulsion control information, energy system information, main propulsion engine information, and steering gear information, and the main server includes a fault prediction model.

[0057] The main server is also used to receive real-time data of the ship's subsystems sent by the first switch, and output early warning information based on the real-time data of the ship's subsystems through a fault prediction model.

[0058] Optionally, the energy system information may include the individual voltage, total voltage, SOC, SOH, charging and discharging current, temperature difference, etc. of the power supply; the main propulsion engine information may include the oil pressure, water temperature, exhaust temperature, number of starts, running time, etc. of the main propulsion engine; the servo information may include: rudder angle response delay, oil temperature, pressure fluctuation, etc., which are not limited here.

[0059] In some implementations, the fault prediction model can be constructed based on a large language model or a pre-trained model (e.g., LSTM, Transformer-based models). For example, in some implementations, real-time sample data from multiple second ship subsystems can be acquired. Each real-time sample data from a second ship subsystem can be labeled with warning information (e.g., warning type, warning location). The real-time sample data from each second ship subsystem can include at least one of the following: energy system information, main propulsion engine information, and steering gear information. Based on these multiple real-time sample data from the second ship subsystems, a fault prediction model is trained using a pre-trained model.

[0060] Optionally, after receiving real-time data from the ship's subsystems sent by the first switch, the server can input this data into a fault prediction model. The model then uses its internal algorithm to predict faults, and if a fault is determined, it outputs a warning message. In some implementations, this warning message may include: warning type, warning location, warning reason, etc., which are not limited here.

[0061] Of course, it should be noted that in some implementations, the path planning module and / or fault prediction module can also be deployed on the backup server. For specific deployment methods, please refer to the instructions for the main server, which will not be repeated here.

[0062] By applying the embodiments of this application, the high computing power of the server can be utilized to achieve low-latency decision-making and control, and the provided tugboat system can support advanced functions such as real-time path planning and equipment health prediction, which helps new energy tugboats upgrade to autonomous driving and improves the intelligence of tugboats.

[0063] In some implementations, in the existing distributed system architecture, distributed devices are scattered throughout the cockpit, and fault location requires checking each device individually (such as poor cable contact or industrial computer crash), with an average repair time of more than 2 hours and high maintenance complexity.

[0064] In alternative implementations, such as Figure 2 As shown, the tugboat network system provided in this application embodiment further includes: a first display screen 11, which is communicatively connected to the main server. The first display screen 11 is used to display at least one of the following information sent by the main server through preset ring network management software: optimal route, early warning information, ring network topology information, ship subsystem equipment status, switch status, and server status.

[0065] The ring network topology information may include: the connection relationships, settings, and subnet identifiers of each switch in the tugboat network system; the ship subsystem equipment information may include: the operating status (e.g., normal, abnormal, low power consumption, etc.) and operating parameters of at least some ship subsystem equipment; the switch status may include: the operating status (e.g., normal, fault, etc.) and operating parameters (e.g., backplane bandwidth, packet forwarding rate, port traffic, etc.) of each switch; and the server status may include: the operating status (e.g., normal, fault, etc.) and operating parameters (e.g., CPU load, memory utilization, etc.), which are not limited here.

[0066] Optionally, the first display screen 11 can be a touch screen and directly connected to the server via an HDMI / DP interface. In some embodiments, based on centralized computing, the main server can also deploy preset ring network management software. The first display screen 11 can display the aforementioned information to be displayed sent by the main server through the preset ring network management software. It is understood that at this time, the background maintenance personnel can monitor the status of ship subsystem equipment, switches, servers and other equipment in real time through the preset ring network management software, quickly locate the location of the fault, shorten the fault location time, and reduce the maintenance complexity compared to the prior art.

[0067] Of course, it should be noted that this application does not limit the number of first display screens 11 connected to the server. Depending on the actual application scenario, multiple first display screens 11 can be set up, and each first display screen 11 can be placed in the cockpit to achieve multi-screen collaborative display (e.g., the main screen displays electronic charts, and the secondary screen monitors battery parameters). Key information is highlighted through dynamic charts.

[0068] In some implementations, such as Figure 2 As shown, the tugboat network system also includes: a second display screen 51, which is connected to a backup server. The second display screen 51 is used to display at least one of the following information sent by the second server through preset ring network management software: optimal route, early warning information, ring network topology information, ship subsystem equipment status, switch status, and server status.

[0069] The backup server and the primary server form a dual-server cluster, with the backup server having the same functions as the primary server. The backup server can also deploy pre-configured ring network management software. The second display screen 51 can display the aforementioned information sent by the backup server through the pre-configured ring network management software. Further details regarding the second display screen 51 can be found in the first display screen 11 described above, and will not be repeated here.

[0070] In an optional implementation, the first assisted driving command includes: a thruster power adjustment command and / or a heading adjustment command; the master server is further configured to send the thruster power adjustment command and / or heading adjustment command to the first switch; the first switch receives the thruster power adjustment command and / or heading adjustment command sent by the master server, and sends the thruster power adjustment command to the first target switch along the unblocked physical shortest path, and / or sends the heading adjustment command to the second target switch, wherein the ship subsystem equipment corresponding to the first target switch includes a propulsion controller, and the ship subsystem equipment corresponding to the second target switch includes a steering gear controller.

[0071] Optionally, thruster power adjustment commands and / or heading adjustment commands can be generated based on the optimal route, or they can be generated based on early warning information; no limitation is made here.

[0072] In some implementations, the server can further send the generated thruster power adjustment commands and / or heading adjustment commands to the corresponding devices to achieve automatic control functions.

[0073] Among them, the ship subsystem equipment in the same subnet as the first target switch includes the propulsion controller, and the ship subsystem equipment in the same subnet as the second target switch includes the steering gear controller.

[0074] Optionally, during adjustments, the master server can send the generated thruster power adjustment command and / or heading adjustment command to the first switch. The first switch, based on the Ethernet ring protection switching protocol, sends the thruster power adjustment command to the first target switch along the unblocked physical shortest path to achieve energy consumption optimization. Alternatively, the second target switch sends the heading adjustment command to achieve precise navigation. It should be noted that after the propulsion controller and / or servo controller make adjustments according to the thruster power adjustment command and / or heading adjustment command, they can provide real-time feedback of the status to the server.

[0075] By applying the embodiments of this application, it is possible to automatically adjust the power of the propulsion controller and / or the heading of the servo motor after generating the propulsion power adjustment command and / or heading adjustment command, thereby improving the intelligence of the tugboat system.

[0076] Of course, it should be noted that in some implementations, the first display screen 11 is used as an example for illustration. Users can also interact with the first display screen 11. For instance, the server can display the generated first assisted driving commands through the first display screen 11, and users can interact with the first display screen 11 to determine whether to automatically adjust the propulsion controller and / or servo controller. This is not limited here. Of course, in some real-time modes, users can also manually take over based on the propulsion power adjustment commands and / or heading adjustment commands. This is not limited here either.

[0077] Figure 3 A system architecture diagram of another tugboat network system provided in this application embodiment. In optional implementations, such as... Figure 3 As shown, the main server includes a first network card and a second network card. The first switch 40 among the multiple switches communicates with the main server through the first network card, and the third switch 70 among the multiple switches communicates with the main server through the second network card.

[0078] The third switch 70 is used to receive real-time data of the ship's subsystems forwarded by each target switch through the ring network when the first switch 40 is determined to be faulty, and to send the real-time data of the ship's subsystems to the main server through the second network card.

[0079] Optionally, the server can be equipped with dual network interface cards (NICs), which can be connected to different switches in the ring network to further ensure link redundancy. For example, the server's first and second NICs can be connected to the first switch 40 and the third switch 70, respectively.

[0080] In some implementations, during data exchange, the first switch 40 connected to the first network card can be set as the master switch, and the third switch 70 connected to the second network card can be set as the backup switch. If the third switch 70 determines that the first switch 40 is faulty (e.g., hardware failure, link interruption, or software abnormality) based on R-APS messages, OAM connectivity mechanisms, etc., it can activate this switch to receive the real-time data of the ship subsystem forwarded by each target switch through the ring network, and send the real-time data of the ship subsystem to the master server through the second network card.

[0081] By applying the embodiments of this application, the dual network card configuration enables timely data exchange via a third switch when the first switch connected to the main server fails. This system design with dual network cards and a dual server cluster ensures that a single hardware failure does not affect the overall system operation, further guaranteeing link redundancy and improving system reliability.

[0082] In an optional implementation, the first switch is further configured to receive real-time data of the ship's subsystems forwarded by each target switch through the ring network when the system recovers from a fault state to a normal state, and send the data to the main server through the first network card.

[0083] Optionally, if it is determined that the fault of the first switch has been recovered, the first switch can be used to receive the real-time data of the ship subsystem forwarded by each target switch through the ring network and send it to the main server through the first network card to avoid network instability.

[0084] Of course, it should be noted that, for the master server, if it is determined that the master server has recovered, the master server will generate the first auxiliary driving command based on the real-time data of the ship's subsystems to avoid network instability.

[0085] Figure 4 This application provides a data interaction method based on a tugboat network system. Optionally, as... Figure 4 As shown, the method may include: S401. Each ship subsystem device registers with the target switch of the corresponding subnet and periodically reports real-time data of the ship subsystem to the corresponding target switch.

[0086] S402. Each target switch receives the real-time data of the ship subsystem collected and sent by its corresponding ship subsystem equipment, and forwards the real-time data of the ship subsystem to the first switch along the shortest physical path that is not blocked in the ring network.

[0087] S403. The first switch receives real-time data from the ship's subsystems forwarded by each target switch through the ring network and sends it to the main server.

[0088] S404. The main server receives real-time data of the ship's subsystems sent by the first switch, generates thruster power adjustment commands and / or heading adjustment commands based on the real-time data of the ship's subsystems, and sends the thruster power adjustment commands and / or heading adjustment commands to the first switch.

[0089] S405. The first switch receives the thruster power adjustment command and / or heading adjustment command sent by the master server, and sends the thruster power adjustment command to the first target switch along the unblocked physical shortest path, and / or sends the heading adjustment command to the second target switch.

[0090] The ship subsystem equipment corresponding to the first target switch includes a propulsion controller, and the ship subsystem equipment corresponding to the second target switch includes a steering gear controller.

[0091] S406. The first target switch forwards the thruster power adjustment command to the propulsion controller, and the second target switch forwards the heading adjustment command to the servo controller.

[0092] In summary, this application provides a tugboat network system with the following characteristics: the ring network centralized architecture can achieve 50ms-level fault self-healing through the ERPS protocol; the dual-server cluster avoids single points of failure and improves system reliability; the ring network supports flexible subnet expansion; ship subsystem equipment can be connected through standard Ethernet interfaces; and the software layer can quickly adapt to new protocols (such as MQTT, OPC). The dual-server cluster can reduce hardware modification costs and offer flexible expansion. Centralized servers directly aggregate data from the entire ring network, shortening data transmission paths and reducing latency. They can integrate multi-source data, supporting data fusion (e.g., using BeiDou positioning and remaining battery power to optimize flight routes), driving path planning modules and / or fault prediction models to achieve intelligent decision-making and avoid data silos. Dual-server clusters concentrate computing power and dynamically allocate resources (e.g., calling idle computing power from the energy management module when navigation calculations are busy), reducing hardware costs and improving computing power utilization. Deploying ring network management software in the servers and monitoring device status in real time (e.g., switch port traffic, server CPU load) shortens fault location time. The combination of dual-server clusters and an automatic ring network switching mechanism ensures a primary / backup switching time of less than 1 second, guaranteeing real-time issuance of emergency commands (e.g., power cut-off in case of fire). Dual servers and ring network switches can be integrated into modular cabinets, improving space utilization. Centralized server processing reduces the number of devices and lowers energy consumption.

[0093] Figure 5 This is a flowchart illustrating a data processing method provided in an embodiment of this application. This method can be applied to the main server in any of the foregoing embodiments of a tugboat network system, such as... Figure 5 As shown, the method includes: S501. Receive real-time data of the ship subsystem sent by the first switch. The real-time data of the ship subsystem is forwarded to the first switch by each target switch along the shortest physical path in the ring network that is not blocked after receiving the real-time data of the ship subsystem collected and sent by its corresponding ship subsystem equipment.

[0094] S502. Generate the first auxiliary driving command based on real-time data from the ship's subsystems.

[0095] By applying the embodiments of this application, ring network redundancy can be achieved by setting up multiple switches to form a ring network, which can improve communication reliability. By setting up ship subsystem equipment, it is possible to flexibly access the subnet switches based on standard Ethernet interfaces, resulting in low hardware modification costs and strong scalability. By introducing a server as a data processing center to achieve centralized computing, multi-source data can be integrated, data fusion can be supported, data silos can be avoided, cross-device collaboration latency can be reduced, computing power utilization can be improved, and energy consumption can be reduced. Moreover, compared with a distributed architecture, there is no need to deploy multiple industrial control computers. The server and ring network switches can be integrated into a modular cabinet, which can reduce hardware costs and significantly improve space utilization.

[0096] Figure 6 This is a schematic diagram of an electronic device structure provided in an embodiment of this application. This electronic device can be integrated into the aforementioned main server. Figure 6 As shown, the electronic device may include a processor 210, a storage medium 220, and a bus 230. The storage medium 220 stores machine-readable instructions executable by the processor 210. When the electronic device is running, the processor 210 communicates with the storage medium 220 via the bus 230, and the processor 210 executes the machine-readable instructions to perform the steps of the above method embodiment. The specific implementation and technical effects are similar and will not be described in detail here.

[0097] Optionally, this application also provides a storage medium storing a computer program, which, when run by a processor, executes the steps of the above-described method embodiments. The specific implementation and technical effects are similar and will not be repeated here.

[0098] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0099] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0100] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.

[0101] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0102] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need further definition and explanation in subsequent figures. The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A tugboat network system, characterized in that, include: The system comprises a main server, multiple switches, and multiple ship subsystem devices. The multiple switches form a ring network based on the Ethernet ring protection switching protocol. The first switch among the multiple switches is communicatively connected to the main server, and at least some of the target switches among the multiple switches are communicatively connected to the ship subsystem devices. Each target switch and its corresponding ship subsystem device constitute a ship subsystem subnet. Each of the target switches is used to receive real-time data of the ship subsystem collected and sent by its corresponding ship subsystem equipment, and forward the real-time data of the ship subsystem to the first switch along the unblocked physical shortest path in the ring network; The first switch receives real-time data from the ship subsystem forwarded by each of the target switches through the ring network and sends it to the main server; The master server is used to receive real-time data of the ship subsystem sent by the first switch, and generate a first assisted driving command based on the real-time data of the ship subsystem.

2. The tugboat network system according to claim 1, characterized in that, The tugboat network system further includes: a backup server, which and the main server constitute a server cluster, and the backup server and the main server communicate based on a heartbeat mechanism; and a second switch among the multiple switches communicates with the backup server. Each of the target switches is also used to receive real-time data of the ship subsystem collected and sent by its corresponding ship subsystem equipment, and forward the real-time data of the ship subsystem to the second switch along the unblocked physical shortest path in the ring network; The second switch receives real-time data from the ship's subsystems forwarded by each of the target switches through the ring network and sends it to the backup server; The backup server is used to receive real-time data of the ship's subsystem sent by the second switch, and generate a second auxiliary driving command based on the real-time data of the ship's subsystem when the main server fails, based on the heartbeat communication mechanism.

3. The tugboat network system according to claim 1, characterized in that, The real-time data of the ship subsystem includes at least one of the following: its own ship status data, information of surrounding ships, geographical information of the water area, meteorological and hydrological data, and energy status data. The main server includes a path planning module. The main server is also used to receive real-time data of the ship subsystem sent by the first switch, and based on the real-time data of the ship subsystem, output the optimal route from the preset starting point to the preset ending point through the path planning module.

4. The tugboat network system according to claim 3, characterized in that, The main server is specifically used to calculate and obtain the optimal route through the route planning module based on the real-time data of the ship subsystem, the preset starting point and the preset ending point. The optimal route is the shortest route after avoiding the risk area.

5. The tugboat network system according to claim 1, characterized in that, The real-time data of the ship subsystem includes at least one of the following: energy system information, main propulsion engine information, and steering gear information; the main server includes a fault prediction model. The main server is also used to receive real-time data of the ship subsystem sent by the first switch, and output early warning information based on the real-time data of the ship subsystem through the fault prediction model.

6. The tugboat network system according to claim 1, characterized in that, The tugboat network system further includes: a first display screen, which is communicatively connected to the main server. The first display screen is used to display at least one of the following information sent by the main server through preset ring network management software: optimal route, early warning information, ring network topology information, ship subsystem equipment status, switch status, and server status.

7. The tugboat network system according to claim 1, characterized in that, The first assisted driving command includes: thruster power adjustment command and / or heading adjustment command; The master server is also used to send thruster power adjustment commands and / or heading adjustment commands to the first switch; The first switch receives thruster power adjustment commands and / or course adjustment commands sent by the master server, and sends the thruster power adjustment commands to the first target switch along the unblocked physical shortest path, and / or sends the course adjustment commands to the second target switch. The ship subsystem equipment corresponding to the first target switch includes a propulsion controller, and the ship subsystem equipment corresponding to the second target switch includes a steering gear controller.

8. The tugboat network system according to any one of claims 1-7, characterized in that, The main server includes a first network interface card (NIC) and a second NIC. The first switch among the plurality of switches is connected to the main server through the first NIC, and the third switch among the plurality of switches is connected to the main server through the second NIC. The third switch is used to receive real-time data of the ship subsystem forwarded by each of the target switches through the ring network when the first switch is determined to be faulty, and to send the real-time data of the ship subsystem to the main server through the second network card.

9. The tugboat network system according to claim 8, characterized in that, The first switch is also used to receive real-time data of the ship subsystem forwarded by each of the target switches through the ring network when the system recovers from a fault state to a normal state, and send it to the main server through the first network card.

10. A data processing method, characterized in that, The method, applied to the master server in the tugboat network system according to any one of claims 1-9, comprises: The system receives real-time data of the ship subsystem sent by the first switch. The real-time data of the ship subsystem is forwarded to the first switch by each target switch after receiving the real-time data of the ship subsystem collected and sent by its corresponding ship subsystem device, along the shortest physical path in the network that is not blocked. The first assisted driving command is generated based on the real-time data of the ship's subsystems.

Images