A ship load cooperative management system and method for marine environment monitoring

Abstract

The application discloses a ship load cooperative management system and method for marine environment monitoring, and relates to the technical field of intelligent equipment management. The method comprises the following steps: constructing a function dependency graph based on equipment registration information; monitoring the load power consumption state of the whole ship in real time and triggering evaluation when the limit is exceeded; constructing a dynamic directed weighted function dependency graph, screening candidate sleep equipment and quantifying the influence of the shutdown on the task chain; based on the power consumption saving rate and dependency conflict detection, generating a conflict-free cooperative sleep decision, aiming to solve the problem that static power consumption control strategy cannot adapt to the dynamic function dependency relationship between equipment, resulting in coexistence of energy waste and task interruption risk. Through the above technical scheme, fine energy efficiency regulation of the shipborne electronic load system can be realized, while ensuring the continuity of key monitoring tasks and improving energy utilization efficiency.

Description

Technical Field

[0001] This invention relates to the field of intelligent equipment management technology, specifically a collaborative management system and method for ship loads used in marine environmental monitoring. Background Technology

[0002] Marine environmental monitoring has become a key technological link supporting marine scientific research, disaster prevention and mitigation, and maritime operational safety. Vessel platforms performing marine environmental monitoring missions have gradually evolved into highly integrated mobile sensing nodes, with the types and numbers of electronic payloads on board continuously increasing. However, limited by energy supply capacity and spatial layout, how to efficiently regulate the energy consumption of multi-source heterogeneous payloads has become a core bottleneck restricting the long-term autonomous operation capability of the system.

[0003] Current mainstream shipboard energy management strategies mostly employ threshold-triggered static power consumption control mechanisms. For example, by presetting the operating power limits and task priorities of each device, some low-priority devices are forcibly shut down when the total power consumption approaches the system's power supply capacity boundary, based on priority order. Therefore, traditional solutions rely on manually configured task scheduling tables for hibernation decisions, lacking a deep understanding of the dynamic data flow and service call relationships between devices. How to construct a collaborative load management mechanism that can dynamically characterize the functional dependency topology between shipboard monitoring devices, and on this basis, achieve quantifiable task impact, predictable energy-saving benefits, and conflict-free hibernation operations has become a current technical challenge for those skilled in the art. Summary of the Invention

[0004] The purpose of this invention is to provide a ship payload collaborative management system and method for marine environmental monitoring, in order to solve the problems raised in the prior art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a method for collaborative management of vessel payloads for marine environmental monitoring. The method of this invention includes the following four core steps: constructing a functional dependency graph, real-time monitoring of the power consumption status of the entire ship's loads, performing dependency impact assessment, and conducting collaborative decision-making. These steps are tightly coupled through data flow and control flow, forming a closed-loop feedback dynamic management architecture.

[0006] During the functional dependency mapping phase, the functional attributes and interface information reported by the marine monitoring equipment are acquired. The equipment management module is deployed within the shipborne central controller, and its communication interface adopts a standardized protocol stack. Each device actively sends registration information upon startup or registers its registration information upon initial connection. The registration information includes the device identifier, functional category, output data type, service interface address, maximum continuous power consumption, data update frequency, and service call cycle. The device identifier is used to uniquely identify the device entity; the functional categories are divided into hydrological sensing, meteorological observation, water quality analysis, acoustic detection, remote sensing imaging, and communication processing; the output data type is represented by predefined enumerated values, including temperature, salinity, dissolved oxygen, wind speed, wave height, sound velocity profile, and spectral image; the service interface address is the call entry point provided by the device, using the Uniform Resource Locator (URL) format; the maximum continuous power consumption is recorded in watts as the power consumption when the device is running at full load; the data update frequency is expressed in Hertz as the periodic rate of the device's effective data output; and the service call cycle is described in seconds as the interval between service calls provided by the device.

[0007] Based on the received registration information, the system parses the dependencies between devices and constructs a directed graph-structured functional dependency graph. The functional dependency graph is stored in the form of an adjacency list. Each node in the graph corresponds to a payload device, and each directed edge represents a relationship where an upstream device provides data or service support to a downstream device. Specifically, if the data type output by the first device matches the required data type input by the second device, a data dependency is determined, and a directed edge from the first device to the second device is added to the graph, assigning it a first-edge weight. Simultaneously, the system continuously collects service call logs between devices. If the third device periodically calls the service interface of the fourth device, a service dependency is determined, and a directed edge from the fourth device to the third device is added to the graph, assigning it a second-edge weight.

[0008] The formula for calculating the weight of the first side is: ; Where fA represents the data update frequency of the first device, fB represents the data update frequency of the second device, and tsy represents the time difference between the most recent data synchronization between the first and second devices. and Preset weighting coefficients and satisfying λ is the decay factor with a value range of 0 < λ < 1. This formula comprehensively considers the matching degree of data output rhythm between upstream and downstream devices and the timeliness decay effect, ensuring that the edge weights can accurately reflect the tightness of data dependence.

[0009] The formula for calculating the weight of the second side is: ; Where Tc represents the average call interval between the third device and the fourth device, tanh represents the hyperbolic tangent activation function, Psuc represents the historical call success rate, and γ and δ are preset weight coefficients that satisfy γ+δ=1. This formula integrates the frequency characteristics of service calls with reliability indicators, making the quantification of service dependencies more practical for engineering applications.

[0010] During the real-time monitoring of the ship's overall load power consumption, a distributed power sensor network collects the current operating power values ​​of each device. Power sensors are integrated into the power input of each device, with a sampling frequency of at least 10 Hz and a measurement accuracy better than 2%. Instantaneous power readings are obtained by polling all power sensors and then summed to obtain the total instantaneous power consumption of the entire ship. When the total instantaneous power consumption reaches a preset upper limit threshold, the system immediately triggers a dependency impact assessment process. The upper limit threshold is dynamically adjusted based on the ship's current remaining battery power, estimated endurance, and mission priority.

[0011] During the dependency impact assessment phase, a candidate set of dormant devices is first selected. Selection criteria include: the device is currently idle, or has not output valid data within a preset time threshold; all its direct downstream devices are not currently in a data acquisition window; and the device itself does not perform any scheduled wake-up tasks. The system verifies device activity through a heartbeat detection mechanism; if no data packet is received within the most recent heartbeat interval, it is determined to be in an idle state. Only devices that meet all of the above conditions can enter the candidate dormant set.

[0012] For each device in the candidate set, trace back along the directed edges in the functional dependency graph to identify all its direct and indirect dependent devices, constructing a set of devices that cannot function properly due to the device being shut down. For the... The formula for calculating the task interruption weight value TIW(i) of a device to be evaluated is as follows: ; Where Ji represents the set of devices that cannot function properly due to the shutdown of the i-th device to be evaluated; wj is the priority weight coefficient of the j-th device in the set, which is preset by the device function category, with core monitoring devices having a higher value; Dj is the data output of the j-th device in a unit sampling period, in bytes; and Tmax is the maximum tolerable task loss time threshold.

[0013] During the collaborative decision-making execution phase, the system calculates the power saving rate for each device in the candidate hibernation set. The power saving rate Rsave(k) for the k-th device is expressed as: ; Where ΔPk is the power saved after the k-th device enters sleep mode, which is equal to its current operating power; ε is a small constant to prevent division by zero, with a value of watt.

[0014] The system sorts all devices in the candidate set in descending order of their Rsave(k) values ​​and attempts to add them to the hibernation device set sequentially. Before adding, dependency conflict detection is performed: a subgraph rooted at the k-th device is constructed, containing that device and all its direct and indirect downstream devices; it is checked whether this subgraph intersects with the subgraph of any device in the hibernation device set. Conflict detection is implemented using a bitmap marking method, pre-allocating a unique bit for each device, setting the bit for all involved nodes during subgraph traversal, and quickly determining the intersection through bitwise AND operations. If there is no intersection, the k-th device is added to the hibernation device set, its current operating power is used as ΔPk, and ΔPk is accumulated into the total power saving power Ptotal; if Ptotal is greater than the current power reduction gap, the loop is terminated early.

[0015] Once the final hibernation set is determined, the system generates a standardized hibernation command packet, which is then sent out through the device driver interface. The hibernation command packet includes the target device identifier, hibernation mode, expected wake-up time, and checksum. There are two hibernation modes: shallow hibernation and deep hibernation. The former retains power to the memory to support fast wake-up, while the latter cuts off all power except for the real-time clock. The expected wake-up time is calculated by the task scheduler based on the next data request time of downstream devices. The checksum is generated using a cyclic redundancy check algorithm to ensure the reliability of command transmission.

[0016] A collaborative management system for ship payloads used in marine environmental monitoring: The system includes a device management module, a function dependency graph management module, a power consumption monitoring module, a dependency impact assessment module, a collaborative decision execution module, and a device control module. These modules are interconnected via an internal bus, forming a closed-loop feedback control architecture.

[0017] The device management module, located within the ship's central controller, receives functional attributes and interface information reported by all payload devices upon system startup or reconnection. Functional attributes include device identifier, function category, output data type, service interface address, maximum continuous power consumption, data update frequency, and service call cycle. The device management module stores this information in a structured format in its local device information database and sends a registration completion signal to the functional dependency graph management module.

[0018] The functional dependency graph management module dynamically generates and maintains a directed weighted graph, called the functional dependency graph, based on the content of the device information database. Each node in this graph corresponds to a load device, and each directed edge represents a relationship where an upstream device provides data or service support to a downstream device. Edge construction is divided into two categories: data dependency edges and service call edges.

[0019] The power consumption monitoring module collects the current operating power values ​​of each load device in real time and obtains the total instantaneous power consumption Ptotal of the entire ship's load by summing them. When Ptotal reaches the preset power consumption upper limit threshold Pmax, the power consumption monitoring module sends a trigger signal to the dependency impact assessment module to start the dependency impact assessment process.

[0020] The dependency impact assessment module first filters the candidate set of dormant devices. Filtering criteria include: the device is currently idle, or has not output valid data within a specified time threshold; all its direct downstream devices are not currently in a data acquisition window; and the device itself does not perform any scheduled wake-up tasks. Device activity is verified through a heartbeat detection mechanism: if no data packet is received from the device within the most recent heartbeat interval, it is determined to be in an idle state. Only when a device simultaneously meets all of the above conditions can it enter the candidate dormant set.

[0021] The collaborative decision-making execution module sorts all devices in the candidate hibernation set in descending order of their Rsave(i) values ​​and attempts to add them to the hibernation device set sequentially. Before adding a device, a dependency conflict check is performed: for the k-th device in the candidate hibernation set, a subgraph Gk is constructed with the k-th device as the root, containing the device and all its direct and indirect downstream devices; each device in the current hibernation device set is traversed, and its corresponding subgraph is constructed; if Gk intersects with any subgraph, a dependency conflict is determined, and the k-th device is skipped; otherwise, the k-th device is added to the hibernation device set, and ΔPk is accumulated into the total power saving Psave.

[0022] If Psave ≥ Pmax - Ptotal during processing, the loop is terminated early to ensure that the total power consumption is reduced to a safe range. Finally, the collaborative decision execution module generates a sequence of device hibernation instructions and sends them to the corresponding load devices through the device control module, causing them to enter hibernation mode.

[0023] Compared with the prior art, the beneficial effects of the present invention are: 1. By constructing a functional dependency graph with a weighted directed graph structure, a refined modeling of data flow and service links between marine monitoring equipment is realized. It not only identifies the dependency direction, but also reflects the dependency strength by quantifying the edge weights and dynamically maintains the functional dependency graph, breaking through the technical limitations of traditional methods that treat equipment as isolated units or only make binary dependency judgments. 2. By using the dependency impact assessment mechanism, the cascading impact of shutting down any device on the downstream task chain can be accurately quantified, avoiding the interruption of critical functions due to blind shutdown; combined with a greedy optimization algorithm based on task weight and power saving rate, the system can intelligently identify the optimal sleep combination when facing energy constraints, maximizing energy saving benefits while ensuring the continuity of high-priority tasks. 3. By combining real-time power consumption monitoring and mission impact assessment, dynamic collaborative hibernation decision-making for the ship's payload system was realized. Through dependency conflict detection, the integrity and robustness of the key monitoring mission chain were ensured, providing technical support for the long-endurance and reliable operation of marine environmental monitoring vessels. Attached Figure Description

[0024] Figure 1 This is a flowchart illustrating a method for collaborative management of vessel loads for marine environmental monitoring according to the present invention. Figure 2 This is a schematic diagram of the structure of a ship load collaborative management system for marine environmental monitoring according to the present invention. Detailed Implementation

[0025] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] Example: Figures 1-2 As shown, the present invention provides a technical solution: a method for collaborative management of vessel loads for marine environmental monitoring.

[0027] Existing technological solutions suffer from a deep-seated structural contradiction at the principle level: on one hand, they pursue minimizing energy consumption to extend endurance, while on the other hand, they neglect the functional topology relationships between devices, leading to an uncontrollable decline in mission reliability. This is because traditional energy management systems treat "power consumption" and "mission" as two decoupled optimization objectives, failing to establish a quantitative mapping bridge between them. When facing energy-constrained conditions, the decision-making process lacks the ability to accurately assess the scope and extent of mission chain disruption caused by shutting down a particular device. This leads to conservative strategies, such as shutting down only explicitly marked non-critical devices, or aggressive strategies, such as mass hibernation for rapid energy reduction. The former fails to release sufficient energy-saving potential, while the latter may result in the permanent loss of critical monitoring data. Especially in scenarios where real-time human intervention is impossible, such non-intelligent hibernation control can easily lead to irreversible interruptions in monitoring tasks, severely weakening the autonomous operation capabilities of the vessel platform.

[0028] Therefore, this invention constructs a load collaborative management method and system that can accurately characterize the dynamic functional dependencies between shipborne monitoring equipment, and on this basis, realize quantifiable task impact, collaborative dormancy decision-making, and closed-loop energy efficiency optimization.

[0029] During the system initialization phase, the shipborne central controller initiates the device management module. This module is deployed in the embedded operating system kernel space of the central controller, employs a standardized communication interface, and supports plug-and-play functionality. After power-on self-test, each marine monitoring device actively sends a registration message to the device management module. The registration message contains seven key fields: device identifier, function category, output data type, service interface address, maximum continuous power consumption, data update frequency, and service call cycle. The function category is divided into categories such as hydrological sensing, meteorological observation, water quality analysis, acoustic detection, remote sensing imaging, and communication processing, based on a predefined classification system. Output data covers marine observation parameters such as temperature, salinity, dissolved oxygen, wind speed, wave height, sound velocity profile, and spectral images. The service interface address follows a Uniform Resource Locator (URL). The maximum continuous power consumption, expressed in watts, records the maximum power value measured by a power sensor under full-load operation. The data update frequency, expressed in Hertz, represents the periodic rate of effective data output. The service call cycle, expressed in seconds, describes the interval at which the device provides services, and is suitable for devices with proactive service publishing capabilities.

[0030] After receiving the registration message, the central controller parses each field and persistently stores it in the device information table in non-volatile memory.

[0031] The process then moves to the functional dependency graph construction phase. This graph is represented by a directed graph structure and dynamically maintained in memory using an adjacency list. Each node in the functional dependency graph corresponds to a registered payload device, and node attributes include device identifier, current operating status, instantaneous power consumption, priority weight coefficient, and data output. Directed edges in the graph represent dependencies between devices, categorized into data dependency edges and service dependency edges.

[0032] Data dependency determination is based on the matching of input-output data types. The system traverses all device pairs, where the a-th and b-th devices on board form a device pair (DeviceaDeviceb). If the output data type set of Deviceea intersects with the required input data type set of Deviceeb, then a data dependency relationship from Deviceea to Deviceeb exists. For example, if Deviceea outputs "salinity" data, and the sound speed correction model of Deviceeb explicitly requires "salinity" as an input parameter, then a directed edge Deviceea→Deviceb is established. The weight wd1 of this edge is determined according to the formula: The calculation yielded the result.

[0033] wherein, fA is the data update frequency of the upstream device (Devicea), fB is the data update frequency of the downstream device (Deviceb), tsy is the time difference of the most recent data synchronization between the two, α and β are preset weight coefficients and satisfy α+β=1, λ is an attenuation factor and its value range satisfies 0<λ<1.

[0034] The physical meaning of this formula is as follows: when the update frequencies of upstream and downstream devices are well matched, fB / fA is close to 1 at this time, and data synchronization is timely, when tsy is small, the dependency tightness is high, and the edge weight approaches 1; on the contrary, if the frequencies are seriously mismatched or the data is outdated, the weight will decrease.

[0035] The determination of service dependency is based on service call log analysis. Whenever Devicec calls the service interface of Deviced, the log agent records the call timestamp, call result (success / failure) and response delay. The system periodically aggregates historical call records, and calculates the average call interval Tc and the historical call success rate Psuc. If Tc is less than a preset threshold and Psuc is higher than the lower reliability limit, it is determined that there is a service dependency from Devicec to Deviced, and a directed edge Devicec→Devicec is added. The weight wd2 of this edge is calculated by the formula: ; wherein, γ and δ are preset weight coefficients and satisfy γ+δ=1. This formula reflects the joint influence of the service call frequency (1 / Tc) and reliability Psuc on the dependency strength. Preferably, the unit of Tc is usually seconds.

[0036] After the graph construction is completed, the real-time monitoring phase is entered. The ship-borne distributed power sensor network collects instantaneous current and voltage signals at the power input end of each device at a sampling frequency of not less than 10Hz, and after analog-to-digital conversion and digital filtering, the current operating power value is calculated. The central controller polls all power sensors every 100 milliseconds to obtain the instantaneous power readings of each device, and accumulates them to obtain the total instantaneous power consumption of the whole ship Ptotal(t). The energy management system dynamically calculates the upper power consumption threshold Pth according to the current remaining power SOC of the boat and the estimated endurance time Trem. Preferably, the calculation method of the upper power consumption threshold is: if SOC>0.8 and Trem>24 hours, Pth is set to 90% of the rated power; if 0.5<SOC≤0.8, Pth is set to 80%; if SOC≤0.5, Pth is reduced to 60% by linear interpolation. When Ptotal(t)≥Pth, the system immediately triggers the dependency impact assessment process.

[0037] During the dependency impact assessment phase, a candidate set of dormant devices, Scan, is first used for screening. The screening criteria are a triple logical AND: First, the device is currently idle, meaning it has not sent any valid data packets within the most recent heartbeat interval (typically twice the data update cycle), as determined by a heartbeat detection mechanism. Second, all of the device's direct downstream devices are not currently in a data acquisition window, meaning their next planned acquisition time is more than a preset safety margin (e.g., 30 seconds). Third, the device itself does not undertake any scheduled wake-up tasks, meaning its task schedule has no wake-up events scheduled to be executed within the next hour. Devices meeting all of the above conditions are included in Scan.

[0038] For the i-th device in the Scan, the system traces all its direct and indirect dependent devices backward along the directed edges in the functional dependency graph, constructing a set Ji of devices that cannot function properly due to the i-th device in the Scan being shut down. This process can be implemented using a depth-first search algorithm: starting from device i, traversing all incoming edges in reverse in the graph, recursively visiting upstream nodes until no new nodes can be added. The set Ji contains all the traversed device nodes. Subsequently, the system calculates the task interruption weight value TIW(i) for device i, which is expressed as: ; Wherein, wj is the priority weight coefficient of the j-th device in Ji, which is pre-set by the device's functional category: for example, hydrological sensing and acoustic detection devices involve core physical field measurements, wj is 0.9; meteorological observation and water quality analysis devices are 0.7; remote sensing imaging devices are 0.6; and communication processing devices are 0.5. Dj is the data output of device j within a unit sampling period, in bytes, calculated from the data type and sampling resolution in the device registration information. Tmax is the maximum tolerable task loss time threshold, dynamically configured by the task planning module according to the current monitoring target: if performing a high-precision cross-sectional survey task, Tmax is set to 3600 seconds; if performing routine cruise monitoring, Tmax is set to 7200 seconds.

[0039] During the collaborative decision-making execution phase, the system calculates the power saving rate Rsave(k) for each device k in Scan, as follows: ; Where ΔPk is the power saved after the k-th device enters sleep mode, which is equal to its current operating power Pk(t); ε is a small constant to prevent division by zero, with a value of 10. -6 Watts. This indicator comprehensively reflects the ratio of energy-saving benefits to task risk; the higher the value, the greater the energy-saving benefits obtained per unit of task risk.

[0040] All devices in Scan are sorted in descending order of Rsave(k) value to form a candidate sequence. Then, devices in the sequence are sequentially added to the final sleep set Sleep. Before adding, dependency conflict detection is performed: taking the k-th device to be added as the root node, all its direct and indirect downstream devices are traversed forward in the functional dependency graph to construct a subgraph Gk. Simultaneously, for the m-th selected device in Sleep, its corresponding subgraph Gm is constructed. Conflict detection is implemented using a bitmap marking method: the system pre-allocates an N-bit bitmap Bitmap for all N devices on the ship, with an initial value of 0. All nodes in Gk are traversed, and their corresponding bits are set to 1 to obtain Bitmapk; similarly, Bitmapm for each Gm is obtained. If the bitwise AND operation between Bitmapk and any Bitmapm is non-zero, an intersection is determined, i.e., there is a shared downstream device, constituting a dependency conflict, and device k is skipped; otherwise, device k is added to Sleep, and Bitmapk is accumulated to the global bitmap Bitmapglobal.

[0041] Each time a device is successfully added, the system adds the device's current operating power to the total power saving power Psaved. If Psaved ≥ (Ptotal(t) - Pth), meaning the current power saving deficit requirement has been met, the loop terminates early, and no further devices are processed. The final determined Sleep value is the target for this collaborative sleep decision.

[0042] In one specific embodiment, the vessel carries five devices: device 1 is a navigation system positioning module, device 2 is an inertial measurement unit, device 3 is a water quality analyzer, device 4 is an underwater sonar imaging system, and device 5 is a satellite communication terminal. The device registration information is as follows: Device 1: Output data type is latitude and longitude coordinates, data update frequency is 1Hz, and maximum power consumption is 5W; Device 2: The output data type is attitude angle, the data update frequency is 10Hz, and the maximum power consumption is 8W; Device 3: Input the positioning data from Device 1, with a data update frequency of 0.1Hz and a maximum power consumption of 12W; Device 4: Requires bandwidth status information from Device 5 to determine the imaging window; call cycle is 30 seconds; historical call success rate is 0.95%; maximum power consumption is 20W. Device 5: Maximum power consumption is 15W.

[0043] Current power consumption monitoring shows a total instantaneous power consumption of 58W, and the power consumption upper limit threshold Pmax is set to 50W, triggering the dependency impact assessment process.

[0044] The device management module has constructed a functional dependency graph: Device 1 → Device 3 (wd1=0.85), Device 5 → Device 4 (wd2=0.78). There are no other valid edges in the graph, indicating that Device 2 is an independent operating unit and does not participate in any data or service dependency chains.

[0045] The dependency impact assessment module filters candidate dormant devices. Device 3 currently has no data output, no downstream devices, and does not perform timed wake-up tasks, thus meeting the candidate criteria. Device 2 is idle (recent heartbeat timed out), but has no downstream dependent devices, also meeting the criteria. Devices 1, 4, and 5 do not meet the criteria because they are in an active state or perform critical links. The candidate set is {Device 2, Device 3}.

[0046] Calculate the Task Interruption Weight Value (TIW): For device 2: its shutdown does not affect any other device, so J2 is an empty set, TIW(2)=0; For device 3: It is an end device with no downstream dependencies, and J3 is an empty set. According to the system settings, if an end device has no downstream dependencies, its TIW is treated as the minimum non-zero value, which is set to 0.01.

[0047] Calculate the power saving rate: Rsave(2)=8 / (0+10⁻ 6 )≈8×10 6 ; Rsave(3)=12 / (0.01+10⁻ 6 )≈1199.88.

[0048] Sort by Rsave value in descending order, and process device 2 first. Construct a subgraph G2={device 2}. The current hibernation set is empty and there are no conflicts. Add device 2 to the hibernation device set, Psave=8W.

[0049] Next, process device 3. Construct a subgraph G3={device 3}, which has no intersection with G2 and no dependency conflicts. Add device 3 to the set of dormant devices, and set Psave=20W.

[0050] At this point, the total system power consumption is 58W - 20W = 38W, which is lower than Pmax = 50W, meeting the power consumption safety requirements. The collaborative decision execution module generates a hibernation command and sends low-power mode commands to devices 2 and 3 respectively through the device control module, causing both devices to enter hibernation mode. Devices 1, 4, and 5 in the task chain continue to operate normally. Although the water quality monitoring task is paused, the task interruption is within a tolerable range because device 3 is the end device and has no real-time early warning requirement.

[0051] In contrast, if functional dependencies are not considered, devices are shut down in descending order of power consumption when total power consumption exceeds the limit.

[0052] Under the same initial conditions, the total power consumption was 58W, and Pmax = 50W. In the comparative example, first shutting down device 4, then device 5, resulted in a cumulative power saving of 35W, reducing the total power consumption to 23W. However, shutting down device 4 completely interrupted the underwater sonar imaging mission. Furthermore, due to the shutdown of device 5, the satellite communication link was interrupted, meaning that even if device 4 was subsequently reactivated, it could not obtain bandwidth status, resulting in a significant delay in mission recovery. Meanwhile, although devices 1, 2, and 3 were still operating, the lack of communication capabilities prevented the transmission of monitoring data, drastically reducing the overall mission effectiveness.

[0053] A collaborative management system for vessel payloads used in marine environmental monitoring. The system includes an equipment management module, a functional dependency graph management module, a power consumption monitoring module, a dependency impact assessment module, a collaborative decision execution module, and an equipment control module.

[0054] The equipment management module is used to receive the functional attributes and interface information reported by each load device, and to store the functional attributes and interface information in a structured manner in the equipment information database; The Function Dependency Graph Management Module is used to generate and maintain a directed weighted graph as a function dependency graph based on the device information database. In the function dependency graph, nodes represent load devices, and directed edges represent data dependencies or service call dependencies between devices. Edges are pruned according to preset weight thresholds. The power consumption monitoring module is used to collect the current operating power value of each load device in real time, calculate the total instantaneous power consumption, and trigger the dependency impact assessment process when the total instantaneous power consumption reaches the preset power consumption upper limit threshold. The dependency impact assessment module is used to screen candidate hibernation devices that meet the requirements of being in an idle state, having no downstream devices in the data acquisition window, and not undertaking timed wake-up tasks. It also uses the functional dependency graph to trace the set of devices affected by each candidate device and calculates the corresponding task interruption weight value. The collaborative decision-making and execution module is used to calculate the power saving rate based on the power saving amount and task interruption weight value of each candidate device, sort them in descending order of power saving rate, perform dependency conflict checks in sequence, and generate a sleep instruction sequence when there is no conflict and the cumulative power saving meets the power safety requirements. The device control module is used to send a hibernation command sequence to the corresponding payload device to put it into hibernation mode.

[0055] The functional dependency graph management module includes a directed weighted graph generation unit, a weighted value calculation unit, and a directed edge pruning unit; The directed weighted graph generation unit is used to generate a directed weighted graph based on the nodes and data dependencies of the devices. The directed weighted graph is used as a functional dependency graph. Each node in the functional dependency graph represents a device on the ship. The graph is drawn based on the data dependencies and remote call relationships between devices. The weighted value calculation unit is used to obtain the data update frequency and data synchronization time difference to calculate the first side weight, and to obtain the average call interval and historical call success rate to calculate the second side weight. The directed edge pruning unit is used to remove directed edges whose weights are less than a threshold. The collaborative decision-making and execution module includes: a power saving rate ranking unit, a conflict checking unit, and a hibernation device collection management unit. The power saving rate sorting unit is used to calculate and sort the power saving rates of the devices. The conflict checking unit is used to check whether a dependency conflict will occur between the decided devices through a graph traversal algorithm. If a conflict exists, the current device is skipped and the next candidate is evaluated until the traversal is completed or the total power consumption drops to a safe range. The hibernation device collection management unit is used to aggregate devices that meet the hibernation conditions into the hibernation device collection.

[0056] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A method for collaborative management of vessel payloads for marine environmental monitoring, characterized in that: Construct a functional dependency graph to obtain the functional attributes and interface information of marine monitoring-related equipment, parse the data output types and service call relationships of the equipment, and establish a directed graph structure for the functional dependency graph. In the functional dependency graph, each node represents a device, and each directed edge represents the relationship between upstream devices and downstream devices providing data or service support, forming a topology structure corresponding to the logical links of the real tasks. Constructing a functional dependency graph includes: When constructing the functional dependency graph, the device information of the device is obtained. The device information includes the device identifier, function category, output data type, service interface address, maximum power consumption, data update frequency and service call cycle. Based on the matching of the output data, determine whether there is a data dependency relationship. If the data output by the first device is the necessary data input by the second device, add a directed edge from the first device to the second device in the graph and assign a weight to the first edge. Analyze the service interface call logs to determine whether there are periodic remote procedure calls. If the third device periodically calls the service interface of the fourth device, add a directed edge from the fourth device to the third device and assign a weight to the second edge. Calculate the sum W of the weights of the first and second edges between any two devices. When W is less than the edge weight threshold, remove the directed edge between the two devices. The methods for calculating the weights of the first and second sides include: Obtain the data update frequencies of the first device and the second device, denoted as fA and fB respectively. Calculate the most recent data synchronization time difference tsy between the first device and the second device, and then calculate the weight wd1 of the first edge. , where α and β represent weighting coefficients, and α+β=1, and λ represents the attenuation factor, λ∈(0,1). From the historical operation logs, obtain the average call interval Tc and the historical call success rate Psuc of the third device periodically calling the fourth device, and calculate the weight wd2 of the second side. , where γ and δ represent weighting coefficients, and γ+δ=1; The system monitors the power consumption status of the entire ship's load in real time, collects the current operating power value of each device, and accumulates them to obtain the total instantaneous power consumption. When the total instantaneous power consumption reaches the preset power consumption upper limit threshold, the dependency impact assessment process is triggered. Perform a dependency impact assessment, and select devices with no active task output and no downstream devices waiting for their data from the functional dependency graph as a candidate hibernation set; for each device in the candidate set, trace all its direct and indirect dependent devices in reverse along the directed edges in the graph, and calculate the task interruption weight value caused by shutting down the device. Collaborative decision-making is implemented. Based on the ratio of task interruption weight value to unit power saving of each candidate device, at least one set of devices with no mutual dependencies and the least overall task impact is determined to form a hibernation device set. Control commands are generated and sent to the devices to put the corresponding devices into hibernation mode.

2. The method for collaborative management of vessel loads for marine environmental monitoring according to claim 1, characterized in that: The performance dependency impact assessment includes: The formula for calculating the task interruption weight value is: , j∈Ji, where TIW(i) represents the task interruption weight value of the i-th device to be evaluated, Ji represents the set of devices that cannot work properly due to the shutdown of the i-th device to be evaluated, j represents the device index of the j-th device that cannot work properly due to the shutdown of the i-th device to be evaluated, wj is the priority weight coefficient of the j-th device, Dj is the data output of the j-th device within a unit sampling period, and Tmax is the maximum tolerable task loss time threshold.

3. The method for collaborative management of vessel loads for marine environmental monitoring according to claim 2, characterized in that: The specific criteria for screening candidate hibernation devices include: The device is currently idle or has not output any valid data within a time threshold; all its direct downstream devices are not currently in the data acquisition window; and the device itself does not undertake any timed wake-up tasks; the device's activity is verified through a heartbeat detection mechanism, and if no data packet is received within the most recent heartbeat interval, it is determined to be idle; only devices that meet all the specific conditions are included in the candidate hibernation set.

4. The method for collaborative management of vessel loads for marine environmental monitoring according to claim 1, characterized in that: Collaborative decision-making and execution include: Calculate the power saving rate under the maximum unit impact, where the power saving rate of the k-th device in the candidate hibernation set is expressed as Rsave(k), Rsave(k) = ΔPk / (TIW(k) + ε), where ΔPk is the power saved by the k-th device after entering hibernation, and ε is a small constant to prevent division by zero. Sort all devices in the candidate set in descending order of power saving rate value and add them to the hibernation device set in turn. Check whether it will cause dependency conflicts between the decided devices through graph traversal algorithm. If there is a conflict, skip the current device and continue to evaluate the next candidate until the traversal is completed or the total power consumption drops to a safe range.

5. A method for collaborative management of vessel loads for marine environmental monitoring according to claim 4, characterized in that: Dependency conflict detection methods include: For the k-th device in the candidate hibernation set, calculate dependency conflicts: Construct a subgraph rooted at the k-th device, including the k-th device and all devices that have direct or indirect downstream relationships with the k-th device. Check if the subgraph intersects with the subgraph of any device in the hibernation device set. If there is no intersection, add the k-th device to the hibernation device set, use the current operating power of the k-th device as ΔPk, and accumulate ΔPk into the total power saving power Ptotal. If Ptotal is greater than the power consumption upper limit threshold, terminate the loop early. Otherwise, continue processing the next device in the candidate hibernation set until all devices in the candidate hibernation set have been traversed.

6. A vessel payload collaborative management system for marine environmental monitoring, used to execute the vessel payload collaborative management method for marine environmental monitoring as described in any one of claims 1-5, characterized in that: The system includes a device management module, a function dependency graph management module, a power consumption monitoring module, a dependency impact assessment module, a collaborative decision execution module, and a device control module; The equipment management module is used to receive the functional attributes and interface information reported by each load device, and to store the functional attributes and interface information in a structured manner in the equipment information database; The functional dependency graph management module is used to generate and maintain a directed weighted graph as a functional dependency graph based on the device information database. In the functional dependency graph, nodes represent load devices, and directed edges represent data dependencies or service call dependencies between devices. The edges are pruned according to a preset weight threshold. The power consumption monitoring module is used to collect the current operating power value of each load device in real time, calculate the total instantaneous power consumption, and trigger the dependency impact assessment process when the total instantaneous power consumption reaches the preset power consumption upper limit threshold. The dependency impact assessment module is used to screen candidate hibernation devices that meet the requirements of being in an idle state, having no downstream devices in the data acquisition window, and not undertaking timed wake-up tasks. Based on the functional dependency graph, it backtracks the set of devices affected by each candidate device and calculates the corresponding task interruption weight value. The collaborative decision-making execution module is used to calculate the power saving rate based on the power saving amount and task interruption weight value of each candidate device, sort them in descending order according to the power saving rate, perform dependency conflict checks in sequence, and generate a sleep instruction sequence when there is no conflict and the cumulative power saving meets the power safety requirements. The device control module is used to send the hibernation command sequence to the corresponding load device to put it into hibernation mode.

7. A ship payload collaborative management system for marine environmental monitoring according to claim 6, characterized in that: The functional dependency graph management module includes: a directed weighted graph generation unit, a weighted value calculation unit, and a directed edge pruning unit; The directed weighted graph generation unit is used to generate a directed weighted graph based on the nodes and data dependencies corresponding to the devices. The directed weighted graph is used as a functional dependency graph. Each node in the functional dependency graph represents a device on the ship. The graph is drawn based on the data dependencies and remote call relationships between devices. The weighted value calculation unit is used to obtain the data update frequency and data synchronization time difference to calculate the first side weight, and to obtain the average call interval and historical call success rate to calculate the second side weight. The directed edge pruning unit is used to remove directed edges whose edge weights are less than a threshold.

8. A ship payload collaborative management system for marine environmental monitoring according to claim 6, characterized in that: The collaborative decision-making execution module includes: a power saving rate value sorting unit, a conflict checking unit, and a hibernation device set management unit; The power saving rate sorting unit is used to calculate and sort the power saving rates of the devices. The conflict checking unit is used to check whether a dependency conflict will occur between the decided devices through a graph traversal algorithm. If a conflict exists, the current device is skipped and the next candidate is evaluated until the traversal is completed or the total power consumption drops to a safe range. The hibernation device collection management unit is used to aggregate devices that meet the hibernation conditions into the hibernation device collection.

Images