A shipboard electronic monitoring device state real-time monitoring and early warning system and method

Abstract

The application relates to the technical field of ship monitoring and early warning, and discloses a real-time monitoring and early warning system and method for the state of a shipborne electronic monitoring device, which comprises the following modules: a unit generation module for generating a shipborne monitoring unit; a collection space-time judgment module for determining a front-end collection validity value and a space-time binding validity value; a retention delivery module for determining a retention validity value and a ship-shore delivery validity value; a state snapshot coding module for generating a same-round state snapshot and a continuity state code; an early warning evidence generation module for generating an abnormal information locking result and an abnormal time period evidence file; a state supplement transmission module for supplementally or continuously transmitting early warning information, an abnormal shipborne monitoring unit same-round state snapshot and an abnormal time period evidence file; and a recovery summary module for determining a breakpoint recovery condition, persistent abnormal information and a whole-ship summary state code. The application realizes real-time monitoring and accurate early warning of the state of the shipborne electronic monitoring device.

Description

Technical Field

[0001] This invention belongs to the field of ship monitoring and early warning technology, specifically relating to a real-time monitoring and early warning system and method for the status of shipborne electronic monitoring equipment. Background Technology

[0002] With the increasing demand for ship video surveillance, operation recording, and ship-shore information linkage, shipborne electronic monitoring equipment has been widely used in scenarios such as monitoring work areas on board, associating ship position information, video storage, and shore-based supervision. Existing shipborne monitoring systems typically consist of cameras, video recorders, positioning sources, storage devices, and ship-shore transmission links. Their operational status directly affects the continuous acquisition, effective storage, and timely delivery of monitoring information from the ship. Especially in environments involving long-distance ocean operations, extended voyages, and significant fluctuations in communication conditions, if shipborne electronic monitoring equipment experiences connectivity issues, missing spatiotemporal information, storage abnormalities, or upload failures, it can easily lead to interruptions in monitoring records, affecting the continuous monitoring of the ship's operations and the shore-based timely understanding of the ship's operational status.

[0003] In existing technologies, the status management of shipborne electronic monitoring equipment mainly relies on individual device online / offline detection, simple fault alarms, or post-event retrieval of video files. This often involves processing cameras, recorders, positioning devices, storage devices, and transmission links separately, lacking a unified organizational approach centered around the same monitored object. This can easily lead to the following problems: First, the boundaries of the monitored object are unclear, making it difficult to uniformly associate specific operating areas, camera equipment, positioning information, storage resources, and ship identification. Second, equipment status determination often remains at the level of a single device, lacking a holistic assessment of the acquisition, spatiotemporal, retention, and delivery processes. Third, when an anomaly occurs, it often only generates a simple alarm, failing to simultaneously create an abnormal status snapshot and abnormal video evidence. Fourth, when the ship-to-shore link is unstable, existing systems typically lack a tiered retransmission and continuation mechanism for status data and evidence files, making it difficult to close the loop on abnormal data in a timely manner. Summary of the Invention

[0004] This invention provides a real-time monitoring and early warning system and method for the status of shipborne electronic monitoring equipment, which solves the technical problems in related technologies such as unclear boundaries of the monitoring objects of shipborne electronic monitoring equipment, scattered determination of equipment status, difficulty in linking abnormal status with video evidence, and difficulty in delivering status data and evidence files in a closed loop when the ship-to-shore link is abnormal.

[0005] This invention provides a real-time monitoring and early warning system for the status of shipborne electronic monitoring equipment, comprising: The unit generation module is used to acquire operational scenario information, camera information, and basic information of shipborne equipment, and to generate shipborne monitoring units. The spatiotemporal determination module is used to acquire real-time device connectivity data and real-time ship position spatiotemporal data of each shipborne monitoring unit, and to determine the validity value of the front-end acquisition and the validity value of the spatiotemporal binding. The retention and delivery module is used to obtain real-time operating data from the storage pool of each shipborne monitoring unit, feedback data uploaded from the ship-to-shore synchronization interface, and the monitoring timestamp for this round, and to determine the retention validity value and the ship-to-shore delivery validity value. The status snapshot encoding module is used to generate a status snapshot of the same round based on the validity value collected by the front end, the validity value of spatiotemporal binding, the validity value of retention, the validity value of ship-to-shore delivery, and the timestamp of the current round of monitoring, and to generate a continuous status code; The early warning evidence generation module is used to lock abnormal information and generate evidence files for abnormal periods from the same-ship status snapshots and video recordings of abnormal periods for shipborne monitoring units with continuous abnormal status codes. The status retransmission module is used to acquire early warning information, snapshots of the same vessel status of the abnormal shipborne monitoring unit, and evidence files of abnormal periods. It retransmits the early warning information and the snapshots of the same vessel status, and segments and retransmits the evidence files of abnormal periods. The recovery summary module is used to obtain the previous round of continuous status codes, the current round of continuous status codes, status data upload status records, and evidence file upload status records of each shipborne monitoring unit, and to determine the breakpoint recovery status, persistent abnormal information, and the overall ship summary status code.

[0006] This invention also provides a method for real-time monitoring and early warning of the status of shipborne electronic monitoring equipment, comprising the following steps: Step 81: Obtain operation scene information, camera information, and basic information of shipborne equipment, and generate shipborne monitoring unit; Step 82: Obtain real-time device connectivity data and real-time ship position spatiotemporal data of each shipborne monitoring unit, and determine the validity value of front-end acquisition and the validity value of spatiotemporal binding; Step 83: Obtain the real-time operating data of the storage pool of each shipborne monitoring unit, the feedback data uploaded by the ship-to-shore synchronization interface, and the monitoring timestamp of this round, and determine the retention validity value and the ship-to-shore delivery validity value. Step 84: Generate a snapshot of the same-cycle status based on the front-end collected validity value, spatiotemporal binding validity value, retention validity value, ship-to-shore delivery validity value and the current round monitoring timestamp, and generate a continuity status code; Step 85: For the shipboard monitoring unit with continuous status code anomalies, perform anomaly information locking and generate evidence files for the abnormal period from the same ship status snapshot and video recording files of the abnormal period. Step 86: Obtain early warning information, snapshots of the same vessel status of the abnormal shipborne monitoring unit, and evidence files of the abnormal period; retransmit the early warning information and the snapshots of the same vessel status; and segment and retransmit the evidence files of the abnormal period. Step 87: Obtain the previous round continuity status code, current round continuity status code, status data upload status record, and evidence file upload status record of each shipborne monitoring unit, and determine the breakpoint recovery status, persistent abnormal information, and overall ship summary status code.

[0007] The beneficial effects of this invention are as follows: Based on a shipborne monitoring unit, this invention unifies and associates the operational scene, cameras, video recorders, positioning sources, storage pools, and ship identification, avoiding the problem of unclear object boundaries caused by scattered monitoring of individual devices in existing technologies. By separately determining the validity values ​​of front-end acquisition, spatiotemporal binding, retention, and ship-to-shore delivery, and further generating same-ship status snapshots and continuous status codes, the continuous status of the shipborne electronic monitoring evidence chain can be uniformly expressed, improving the completeness and consistency of status determination. Furthermore, this invention can simultaneously generate early warning information, lock the abnormal information, and form evidence files for the abnormal period after an anomaly occurs, establishing a clear association between the abnormal state and the corresponding video evidence. At the same time, by employing supplementary transmission and segmented continuation transmission mechanisms for status data and evidence files, combined with recovery and summary processing, the stability of abnormal data delivery and the accuracy of subsequent verification can be improved. Attached Figure Description

[0008] Figure 1 This is a schematic diagram of a module of a shipborne electronic monitoring equipment status real-time monitoring and early warning system according to the present invention. Detailed Implementation

[0009] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, features described in some examples may be combined in other examples.

[0010] It should be noted that, unless otherwise defined, the technical or scientific terms used in one or more embodiments of the present invention should have the ordinary meaning understood by one of ordinary skill in the art to which this invention pertains. The terms "first," "second," and similar terms used in one or more embodiments of the present invention do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0011] like Figure 1 As shown, a real-time monitoring and early warning system for the status of shipborne electronic monitoring equipment includes: The unit generation module is used to acquire operational scenario information, camera information, and basic information of shipborne equipment, and to generate shipborne monitoring units. The spatiotemporal determination module is used to acquire real-time device connectivity data and real-time ship position spatiotemporal data of each shipborne monitoring unit, and to determine the validity value of the front-end acquisition and the validity value of the spatiotemporal binding. The retention and delivery module is used to obtain real-time operating data from the storage pool of each shipborne monitoring unit, feedback data uploaded from the ship-to-shore synchronization interface, and the monitoring timestamp for this round, and to determine the retention validity value and the ship-to-shore delivery validity value. The status snapshot encoding module is used to generate a status snapshot of the same round based on the validity value collected by the front end, the validity value of spatiotemporal binding, the validity value of retention, the validity value of ship-to-shore delivery, and the timestamp of the current round of monitoring, and to generate a continuous status code; The early warning evidence generation module is used to lock abnormal information and generate evidence files for abnormal periods from the same-ship status snapshots and video recordings of abnormal periods for shipborne monitoring units with continuous abnormal status codes. The status retransmission module is used to acquire early warning information, snapshots of the same vessel status of the abnormal shipborne monitoring unit, and evidence files of abnormal periods. It retransmits the early warning information and the snapshots of the same vessel status, and segments and retransmits the evidence files of abnormal periods. The recovery summary module is used to obtain the previous round of continuous status codes, the current round of continuous status codes, status data upload status records, and evidence file upload status records of each shipborne monitoring unit, and to determine the breakpoint recovery status, persistent abnormal information, and the overall ship summary status code.

[0012] In one embodiment of the present invention, a unit generation module is used to acquire operational scene information, camera information, and basic information of shipborne equipment, and generate a shipborne monitoring unit. This module is a prerequisite module for subsequent real-time monitoring of equipment status, continuous status coding, anomaly warning, anomaly evidence retention, and retransmission verification. The processing object of this module is not a simple collection of all video devices on the ship, but rather a structured organization around the monitoring objects jointly determined by the ship's operational activities and the electronic observer's task configuration. The operational scene information refers to the ship's operational area information directly related to the shipborne electronic monitoring task, such as the surface of the fishing vent, the hook-casting point, the buoy-casting point, the catch processing area, and the area forward of the bow or mast. The camera information refers to the camera information actually referenced in the electronic observer's task configuration, not an indiscriminate collection of all installed cameras on the ship. The basic information of the shipborne equipment refers to the basic equipment information that forms a monitoring link with the camera information, including at least video recorder information, location source information, storage pool information, ship identification, equipment login parameters, and equipment network address. Among them, the video recorder information refers to the video access and recording storage device information corresponding to the target camera; the positioning source information refers to the data source information used to provide ship position, latitude and longitude, speed, heading, and time identifiers; the storage pool information refers to the storage resource information used to store monitoring videos and status data; the ship identification refers to the unique identification information used to identify the current ship; the device login parameters refer to the authentication parameters required to access the camera or video recorder; and the device network address refers to the communication address information of the camera, video recorder, and other devices in the shipboard network. Specifically, the shipboard monitoring unit is generated, including: Step 11: Standardize the operational scenario information. This standardization process involves unifying the different names for the same operational area in different deployment files, equipment configuration tables, or task configuration records, merging duplicate scenarios, and generating a unique scenario identifier. The scenario identifier can use a fixed number consistent with the shipborne task system or a scenario number assigned sequentially according to the operational area. This process converts inconsistent descriptions of operational areas into unified scenario objects. For example, descriptions with the same meaning such as "Shangyukou sea surface," "Shangyukou area sea surface," and "fish catch entry location sea surface" can be uniformly mapped to the same operational scenario and assigned a unique scenario identifier. After this process, based on the scenario association relationships in the electronic observer task configuration, target camera information corresponding one-to-one with each operational scenario can be filtered from the camera information. The scenario association relationship refers to the pre-established correspondence between cameras and operational scenarios in the task configuration. Through this filtering action, the system's monitoring objects are limited to target camera information actually related to the electronic observer task, thereby avoiding the inclusion of cameras unrelated to operational supervision in subsequent status judgment processes.

[0013] Step 12: After obtaining the target camera information, extract the associated recorder information, location source information, storage pool information, ship identification, device login parameters, and device network address from the shipborne equipment basic information based on each target camera information. This extraction of associated information is not simply reading the entire equipment register; rather, it establishes corresponding device link relationships based on the target camera information. That is, each target camera information should correspond to specific recorder information, location source information, and storage pool information, and should be able to be associated with the ship's identification and the device login parameters and device network address required to access the linked device. After extraction, bind the operational scenario information, each target camera information, and the extraction results to generate each shipborne monitoring unit. The shipborne monitoring unit refers to the smallest monitoring object constructed for subsequent status monitoring, early warning, and evidence collection. It is not a single camera or a single recorder, but a structured monitoring unit composed of operational scenario information, target camera information, and associated shipborne equipment basic information. In other words, the shipborne monitoring unit embodies a complete shipborne monitoring link object, capable of simultaneously carrying the basic relationships required for data acquisition, positioning, storage, and uploading.

[0014] Step 13: Generate standardized basic information records for each shipborne monitoring unit, and then aggregate these records to generate a monitoring benchmark table. The standardized basic information records refer to fixed records that have been field-based and structured for various types of information contained in a single shipborne monitoring unit. These include operational scenario information, target camera information, video recorder information, location source information, storage pool information, ship identification, device login parameters, and device network address. The monitoring benchmark table is a basic data table formed by aggregating the standardized basic information records of all shipborne monitoring units. It is used as a unified basis for data retrieval and object indexing in subsequent steps. For example, in the subsequent spatiotemporal determination process, connectivity and login checks can be performed on the target camera and video recorder directly based on the device network address and device login parameters in the monitoring benchmark table. In the subsequent retention and delivery determination process, real-time operating data from the storage pool, real-time ship position spatiotemporal data, and ship-shore synchronization interface feedback data can be read based on the storage pool information, location source information, and ship identification in the monitoring benchmark table. Therefore, the monitoring benchmark table not only serves as an object management tool, but also as a unified data entry point for subsequent status collection and status coding.

[0015] For example, when a deep-sea fishing vessel is equipped with three operational scenarios—the surface of the fishing spot, the hook-casting area, and the catch processing area—the system first generates corresponding scenario identifiers for each of these scenarios. Then, based on the electronic observer's task configuration, it filters out the information from three corresponding target cameras. Subsequently, for each target camera, it extracts the connected video recorder information, associated location source information, corresponding storage pool information, as well as the ship's identifier, device login parameters, and device network address, generating three shipborne monitoring units. Afterward, it generates a standardized basic information record for each shipborne monitoring unit and summarizes them into a monitoring benchmark table. In this way, in subsequent monitoring, the system does not perform decentralized monitoring of all shipboard equipment indiscriminately, but rather performs targeted monitoring and subsequent early warning processing based on the monitoring units at the surface of the fishing spot, the hook-casting area, and the catch processing area.

[0016] This embodiment solves the problem of unclear monitoring object boundaries in the shipborne electronic monitoring link by structurally binding operation scenario information, target camera information, and shipborne equipment basic information; by standardizing operation scenario information and generating shipborne monitoring units, the status of monitoring equipment is no longer simply the online status of the equipment, but the monitoring link status corresponding to the specific operation area supervision task; thus providing a unified, clear, and scalable processing foundation for subsequent steps.

[0017] In one embodiment of the present invention, the spatiotemporal determination module is used to acquire real-time device connectivity data and real-time ship position spatiotemporal data of each shipborne monitoring unit, and determine the front-end acquisition validity value and the spatiotemporal binding validity value. This module no longer processes scattered cameras, recorders, positioning sources, or ship position data, but rather synchronously acquires the front-end acquisition status and spatiotemporal binding status within the same round of monitoring around the same shipborne monitoring unit. The real-time device connectivity data refers to the connectivity and login results read from cameras and recorders in the current monitoring round; the real-time ship position spatiotemporal data refers to the real-time ship position, latitude and longitude, speed, heading, and time identifier data corresponding to the shipborne monitoring unit in the current monitoring round. The front-end acquisition validity value refers to the valid or invalid result obtained after judging the front-end acquisition link status of cameras and recorders; the spatiotemporal binding validity value refers to the valid or invalid result obtained after judging whether the real-time ship position spatiotemporal data can form a spatiotemporal identifier status that can be written into the monitoring record. Specifically, determining the front-end acquisition validity value and the spatiotemporal binding validity value includes: Step 21: Based on the monitoring benchmark table, perform synchronous data collection in the same round for each shipborne monitoring unit. Synchronous data collection in the same round means that for a single shipborne monitoring unit, within the same monitoring period, the connectivity status and spatiotemporal data of the corresponding device are read according to a unified time benchmark, thereby ensuring that the subsequent front-end acquisition validity values ​​and spatiotemporal binding validity values ​​originate from the same monitoring object and the same monitoring round. Specifically, first, the device network address and device login parameters corresponding to the current shipborne monitoring unit are read from the monitoring benchmark table. Then, based on the device network address and device login parameters, the connectivity and login results of the corresponding camera, as well as the connectivity and login results of the corresponding recorder, are read. The connectivity result refers to the detection result of whether the device network address is accessible in the current round; the login result refers to the success or failure result of authenticating access to the device using the device login parameters. If the current camera has both a real address and a recorder forwarding address, only the connectivity result corresponding to the real address is used as the reading result of the camera's connectivity status, and the connectivity result corresponding to the recorder forwarding address is not used. In this way, the real address directly corresponds to the camera itself, which can more accurately reflect the network reachability status of the camera itself. The forwarding address of the recorder only reflects the access status of the camera after it is forwarded through the recorder link. If the forwarding address is directly used instead of the real address, it is easy to misjudge the status of the forwarding link as the status of the camera itself.

[0018] Step 22: Determine the front-end acquisition validity value based on the camera connectivity results, camera login results, video recorder connectivity results, and video recorder login results corresponding to each shipborne monitoring unit. The front-end acquisition validity value refers to the binary judgment result made on whether the front-end acquisition chain of the shipborne monitoring unit is complete and usable. In specific implementation, the system uniformly judges the four results read in step 21: when the camera connectivity result, camera login result, video recorder connectivity result, and video recorder login result are all successful, the front-end acquisition validity value is determined to be valid; when any one of the above four results fails, the front-end acquisition validity value is determined to be invalid. In other words, this embodiment does not solely rely on camera connectivity as the sole basis for the validity of the front-end acquisition chain, nor does it solely rely on video recorder login as the sole basis for validity. Instead, it treats the camera and video recorder as continuous components of the same front-end acquisition chain. Only when both the camera itself and the video access link simultaneously meet the connectivity and login conditions is the front-end acquisition validity value of the shipborne monitoring unit determined to be valid. This avoids situations where the camera network is reachable but login is impossible, or the video recorder is accessible but cannot normally receive the front-end video stream, leading to misjudgments of the front-end acquisition chain's validity. For example, in a shipborne monitoring unit, if the camera connection is successful, the camera login is successful, and the recorder connection is successful, but the recorder login fails, it indicates that the recording access terminal of the monitoring unit is not in normal working condition. In this case, the validity value of the front-end acquisition should be determined as invalid, and the entire front-end acquisition chain should not be judged to be valid simply because the camera itself is online.

[0019] Step 23: Read the real-time ship position, latitude and longitude, speed, heading, and time identifier from the real-time ship position spatiotemporal data corresponding to each shipborne monitoring unit, and convert them into standardized fields. Based on the standardized fields and ship identifiers, determine the spatiotemporal binding validity value for each shipborne monitoring unit. The standardized fields refer to the conversion of the original real-time ship position spatiotemporal data into standardized data fields that can be directly written into monitoring records or status records, including at least a ship position field, a location field, an operation field, and a time field. The ship position field describes the current real-time position status of the ship; the location field carries latitude and longitude information; the operation field carries speed and heading information; and the time field carries the time identifier for the current monitoring round. The ship identifier still refers to information used to uniquely identify the current ship and serves as one of the associated primary keys after the standardized fields are written. In specific implementation, the system first reads the real-time ship position, latitude and longitude, speed, heading, and time identifier corresponding to the current shipborne monitoring unit, and then converts the above original data into standardized fields according to preset field rules. For example, latitude and longitude can be written into the location field, speed and heading into the operation field, and the time identifier into the time field. After the conversion is completed, a completeness determination is made based on the standardized fields and the ship's identification: if the ship's position field, time field, and ship's identification in the standardized fields are complete and can be written to a record, the spatiotemporal binding validity value is determined to be valid; otherwise, the spatiotemporal binding validity value is determined to be invalid. The term "writable record" means that the format, content, and association of the corresponding fields meet the system's basic requirements for writing monitoring records, rather than simply having raw data values. In other words, the determination of the spatiotemporal binding status in this embodiment is not simply a matter of whether latitude, longitude, or time has been collected, but rather whether these data, together with the ship's identification, can form a complete spatiotemporal identification chain that can fall into the monitoring record. For example, if the real-time ship's position and latitude, longitude, and time have been acquired, but the time identifier is missing, or the ship's identification cannot be associated, then the spatiotemporal binding validity value of the shipborne monitoring unit should be determined to be invalid.

[0020] This embodiment performs synchronous data collection in the same round on a per-shipboard monitoring unit basis, unifying the previously scattered device connectivity information and ship position spatiotemporal information under a single object framework for judgment. This ensures the consistency of the front-end acquisition status and spatiotemporal binding status in terms of object attribution and time reference. By jointly determining the front-end acquisition validity value based on camera connectivity results, camera login results, video recorder connectivity results, and video recorder login results, the complete availability status of the shipboard electronic monitoring front-end link can be more accurately reflected. By converting real-time ship position, latitude and longitude, speed, heading, and time identifiers into standardized fields and combining them with ship identifiers to determine the spatiotemporal binding validity value, the complete writing status of spatiotemporal information in the shipboard monitoring records can be more accurately reflected.

[0021] In one embodiment of the present invention, the retention and delivery module is used to acquire the real-time operating data of the storage pool of each shipborne monitoring unit, the data uploaded and fed back from the ship-to-shore synchronization interface, and the timestamp of the current monitoring round, and to determine the retention validity value and the ship-to-shore delivery validity value. The real-time operating data of the storage pool refers to the real-time usage and operating status data of the storage pool associated with the shipborne monitoring unit in the current monitoring round; the data uploaded and fed back from the ship-to-shore synchronization interface refers to the upload result data returned by the ship-to-shore synchronization interface after the system sends the status information corresponding to the shipborne monitoring unit to the shore end in the current monitoring round; the timestamp of the current monitoring round refers to the unified time identifier corresponding to the current monitoring round, used to identify the monitoring time corresponding to the collection, judgment, and upload in this round. The retention validity value refers to the valid or invalid judgment result made on whether the shipborne monitoring unit currently has effective storage retention capability; the ship-to-shore delivery validity value refers to the valid or invalid judgment result made on whether the status information corresponding to the shipborne monitoring unit has been successfully delivered to the shore end. Specifically, determining the retention validity value and the ship-to-shore delivery validity value includes: Step 31: Based on the monitoring benchmark table, read the storage pool information and ship identification associated with each shipborne monitoring unit; based on the real-time operating data of the storage pools, eliminate the system disk storage pool, and read the utilization rate, real-time operating status, and local data retention flag of the non-system disk storage pool. The system disk storage pool refers to the system-level storage area that carries the shipborne system's operating files, applications, or basic software environment; the non-system disk storage pool refers to the business storage area used to store monitoring videos and status data, excluding the system disk storage pool. The system disk storage pool primarily supports the shipborne system's operation, and its capacity changes and operating status cannot be directly equated to the retainability of monitoring business data. The non-system disk storage pool, on the other hand, directly undertakes the function of storing monitoring videos and status data, and more accurately reflects the retention capacity in the monitoring evidence chain. The utilization rate refers to the proportion of the non-system disk storage pool's used capacity to the total available capacity in the current monitoring round; the real-time operating status refers to whether the non-system disk storage pool is operating normally in the current monitoring round; and the local data retention flag indicates whether the data generated in this monitoring round has been successfully saved locally. In practice, the system first reads the storage pool information and ship identification corresponding to the current shipborne monitoring unit from the monitoring benchmark table, and then calls the storage management interface or storage status acquisition interface to read the real-time operating data of the storage pool corresponding to the storage pool information. Subsequently, the system disk storage pool is removed from all the storage pools read, and only the non-system disk storage pools are retained. The system then reads the usage rate, real-time operating status, and local data storage identifier of each non-system disk storage pool.

[0022] Step 32: Determine the retention validity value of each shipborne monitoring unit based on the usage rate, real-time operating status, and local data retention flag of the non-system disk storage pool. The preset full-load threshold refers to a pre-set threshold used to determine whether a non-system disk storage pool is approaching its storage limit. If at least one non-system disk storage pool can retain data normally and has not reached the preset full-load threshold, the retention validity value is determined to be valid; otherwise, the retention validity value is determined to be invalid. In other words, this embodiment does not use the condition that all non-system disk storage pools are in a completely normal state as the condition for valid retention, but rather uses whether at least one non-system disk storage pool can normally undertake the task of retaining monitoring data for this round as the basis for judgment. Thus, in shipborne monitoring scenarios, multiple business storage pools may operate in parallel. As long as at least one non-system disk storage pool can still normally save monitoring video or status data, the retention chain in the shipborne monitoring evidence chain is not completely interrupted. In practice, the system sequentially checks the real-time operating status and utilization rate of each non-system disk storage pool to determine whether it has the ability to retain data normally. If any non-system disk storage pool is found to be operating normally and its utilization rate is lower than the preset full load threshold, and the local data retention flag indicates that the data for this round can be saved locally, then the retention validity value of the current shipborne monitoring unit is determined to be valid. Conversely, if all non-system disk storage pools are in an abnormal state, have reached or exceeded the preset full load threshold, or the local data retention flag indicates that the data for this round has not been saved locally, then the retention validity value is determined to be invalid. For example, if a shipborne monitoring unit is associated with two non-system disk storage pools, where the first non-system disk storage pool is close to full load, but the second non-system disk storage pool is still operating normally and has sufficient capacity, then the system can still determine the retention validity value of the shipborne monitoring unit to be valid; however, if all non-system disk storage pools are full load or cannot operate normally, then its retention validity value should be determined to be invalid.

[0023] Step 33: Integrate the equipment status information and ship position information of each shipborne monitoring unit, write the ship identifier, and upload it via the ship-shore synchronization interface; determine the ship-shore delivery validity value based on the feedback data uploaded via the ship-shore synchronization interface. The equipment status information refers to the equipment status-related information already formed around the current shipborne monitoring unit, including at least the structured results corresponding to the front-end acquisition status, spatiotemporal binding status, and retention status; the ship position information refers to the spatiotemporal information such as the real-time ship position, latitude and longitude, speed, heading, and time stamp corresponding to the current shipborne monitoring unit; the ship-shore synchronization interface refers to the communication interface for transmitting status information between the ship and the shore. In specific implementation, the system first integrates the equipment status information and ship position information corresponding to each shipborne monitoring unit to form an upload data object for the current round, and writes the ship identifier read from the monitoring benchmark table into this upload data object to ensure that the shore can clearly identify the ship and monitoring unit to which the uploaded data belongs. Subsequently, the system calls the ship-shore synchronization interface to send the upload data object to the shore and receives the upload feedback data returned by the ship-shore synchronization interface. If the uploaded feedback data indicates a successful upload, the ship-to-shore delivery validity value of the current shipborne monitoring unit is determined to be valid; if the uploaded feedback data indicates a failed upload, or if no successful feedback is received within the preset response time, the ship-to-shore delivery validity value is determined to be invalid.

[0024] It's important to note that in this embodiment, the determination of ship-to-shore delivery status is based not on whether an upload has been initiated, but on whether interface feedback data indicating successful delivery has been received. This means that simply initiating an upload action on the ship side does not directly confirm the validity of the ship-to-shore delivery chain. Only after the shore side returns a clear success feedback is the status information of the shipborne monitoring unit for the current round considered to have been successfully delivered. For example, if a shipborne monitoring unit has successfully generated equipment status information and ship position information in this round of monitoring and has sent it to the shore, but due to communication interruption, lack of confirmation of receipt by the shore side, or interface failure, the ship-to-shore delivery validity value of that shipborne monitoring unit should be determined as invalid.

[0025] This embodiment generates a retention validity value by jointly determining the usage rate of the non-system disk storage pool, real-time operating status, and local data storage identifier for this round. It also generates a ship-to-shore delivery validity value based on the uploaded data after writing device status information and ship position information into the ship identifier and performing a ship-to-shore synchronization interface upload. This extends the status of shipborne electronic monitoring equipment from the front-end acquisition chain and spatiotemporal binding chain to the retention chain and delivery chain, forming a continuous status determination basis for the integrity of the shipborne monitoring evidence chain. This provides a unified input for subsequent generation of same-round status snapshots, continuous status code encoding, anomaly warnings, and retransmission verification.

[0026] In one embodiment of the present invention, the status snapshot encoding module is used to generate a same-round status snapshot based on the front-end acquisition validity value, spatiotemporal binding validity value, retention validity value, ship-to-shore delivery validity value, and the current round monitoring timestamp, and to generate a continuous status code. The same-round status snapshot refers to a single-round status record obtained by uniformly encapsulating the front-end acquisition validity value, spatiotemporal binding validity value, retention validity value, ship-to-shore delivery validity value, and the current round monitoring timestamp formed by the same shipborne monitoring unit within the same monitoring round; the continuous status code refers to a status identifier formed by extracting four types of validity values ​​from the same-round status snapshot and encoding them in a fixed order; the breakpoint type refers to the evidence chain interruption category determined by the invalid position in the continuous status code. Specifically, generating a same-round status snapshot based on the front-end acquisition validity value, spatiotemporal binding validity value, retention validity value, ship-to-shore delivery validity value, and the current round monitoring timestamp, and generating a continuous status code, includes: Step 41: Generate a snapshot of the same-cycle status for each shipborne monitoring unit in the order of front-end acquisition validity value, spatiotemporal binding validity value, retention validity value, ship-to-shore delivery validity value, and the current monitoring timestamp. Specifically, for each shipborne monitoring unit, the system first reads the front-end acquisition validity value, spatiotemporal binding validity value, retention validity value, and ship-to-shore delivery validity value already determined for that unit in the current monitoring cycle, then reads the corresponding current monitoring timestamp, and subsequently writes them sequentially into the same status record according to a predetermined order, forming a snapshot of the same-cycle status for that shipborne monitoring unit. Thus, the snapshot of the same-cycle status is no longer a single status value, but a complete encapsulated status result formed with the shipborne monitoring unit as the object and the current monitoring timestamp as the time reference.

[0027] Step 42: Extract the front-end acquisition validity value, spatiotemporal binding validity value, retention validity value, and ship-to-shore delivery validity value from the same-cycle status snapshots of each shipborne monitoring unit. Then, concatenate these values ​​in a fixed order to generate a continuous status code. This fixed order means that the meaning of each position in the continuous status code remains consistent across all shipborne monitoring units and all monitoring cycles. Specifically, the first position corresponds to the front-end acquisition validity value, the second to the spatiotemporal binding validity value, the third to the retention validity value, and the fourth to the ship-to-shore delivery validity value. In practice, the system first extracts the aforementioned four types of validity values ​​from the same-cycle status snapshots, and then forms a fixed-length encoding result, i.e., a continuous status code, according to the fixed order. Since all four types of validity values ​​use a valid or invalid determination format, the continuous status code can directly reflect the continuous status of the four key links in the monitoring evidence chain of the same shipborne monitoring unit within the current cycle. For example, when the front-end acquisition validity value, spatiotemporal binding validity value, and retention validity value of a shipborne monitoring unit are valid, but the ship-to-shore delivery validity value is invalid, its continuity status code can reflect that there is a break in the delivery chain for that unit. Through this step, the system realizes the transformation from scattered status values ​​to a unified coded object, providing a direct basis for subsequent anomaly classification and early warning generation.

[0028] Step 43: Determine the breakpoint type based on the continuity status code. When all four aspects of the continuity status code are valid, the breakpoint type is determined to be a continuous evidence chain. When any one or more aspects of the continuity status code are invalid, determine the corresponding breakpoint type, and generate ship-side and shore-side early warning information by combining the unit number, operation scenario information, equipment basic information, and the current monitoring timestamp in the monitoring benchmark table. The continuous evidence chain refers to the front-end acquisition chain, spatiotemporal binding chain, retention chain, and ship-shore delivery chain all being in a valid state. The corresponding breakpoint type refers to the anomaly category determined based on the invalid position in the continuity status code. When only one position is invalid, it can be determined as a front-end acquisition breakpoint, spatiotemporal binding breakpoint, retention breakpoint, or ship-shore delivery breakpoint. When two or more positions are invalid, it is determined as a composite breakpoint. In practice, the system first reads the continuity status code and then judges the validity of the status represented by each position. If all four are valid, no abnormal warning is generated, and the current breakpoint type is determined as a continuous chain of evidence. If any or more positions are invalid, the breakpoint type is determined based on the combination of invalid positions. For example, if the first and third positions are invalid simultaneously, the breakpoint type is: front-end acquisition-retention composite breakpoint. Subsequently, the system reads the unit number, operation scenario information, and equipment basic information corresponding to the shipborne monitoring unit from the monitoring benchmark table, and combines them with the monitoring timestamp of this round to organize the above breakpoint types and continuity status codes into structured warning objects, generating ship-side warning information and shore-side warning information respectively. The ship-side warning information and shore-side warning information refer to the abnormal prompt information output to the ship-side display terminal and the shore-side display terminal respectively. They originate from the same continuity status code and the same breakpoint type, but differ in display position and receiving object.

[0029] This embodiment encapsulates the front-end acquisition validity value, spatiotemporal binding validity value, retention validity value, ship-to-shore delivery validity value, and the current monitoring timestamp into a single-cycle status snapshot, and further generates a continuous status code. This elevates the expression of the shipborne electronic monitoring equipment status from a decentralized judgment result to a structured, coded, and traceable status object. By determining the breakpoint type based on the continuous status code and generating ship-side and shore-side early warning information, the system can clearly distinguish between the continuous state of the evidence chain and the breakpoint state at different locations.

[0030] In one embodiment of the present invention, the early warning evidence generation module is used to perform anomaly information locking and anomaly period evidence file generation for the same-ship status snapshot and abnormal time period video files of the shipborne monitoring unit with continuous status code anomalies. The anomaly information locking result refers to a structured locking result formed after fixedly associating the abnormal shipborne monitoring unit, the corresponding operational scenario information, and the monitoring time of the current round; the abnormal time period video file refers to the video file corresponding to the abnormal shipborne monitoring unit in the abnormal round; the abnormal time period evidence file refers to a collection of evidence files formed after segmenting, compressing, naming, and registering the abnormal time period video files. Specifically, performing anomaly information locking and abnormal time period evidence file generation includes: Step 51: When the continuous status code is not a continuous evidence chain, filter the corresponding shipborne monitoring unit; read the same-cycle status snapshot of the shipborne monitoring unit, and store the same-cycle status snapshot separately after associating it with the continuous status code and breakpoint type; simultaneously lock the shipborne monitoring unit, the operation scenario information, and the current round monitoring time to generate an anomaly information locking result. In specific implementation, the system first judges the continuous status code of each shipborne monitoring unit. When the continuous status code indicates the existence of any breakpoint or compound breakpoint, the shipborne monitoring unit is identified as an abnormal shipborne monitoring unit. Subsequently, the same-cycle status snapshot corresponding to the abnormal shipborne monitoring unit is read, and the same-cycle status snapshot is associated with the corresponding continuous status code and breakpoint type and stored separately. Separate storage means saving the status snapshot of the abnormal round independently from the regular round status record to avoid subsequent normal round records overwriting the abnormal round status. After separate storage, the abnormal shipborne monitoring unit, its corresponding operation scenario information, and the current round monitoring time are synchronously locked to form an anomaly information locking result. Thus, the system completed the fixed processing of abnormal state objects, providing a unified index basis for subsequent retrieval of video files from abnormal periods.

[0031] Step 52: Based on the shipborne monitoring unit, operation scenario information, and current monitoring time in the anomaly information locking result, retrieve the corresponding abnormal time period video file; segment the abnormal time period video file sequentially according to a preset time length, and compress the segmented video file. The preset time length refers to the pre-set duration of a single segmented video file; the sequential segmentation refers to dividing the abnormal time period video file into multiple consecutive segments according to the chronological order of the time. In specific implementation, the system retrieves the corresponding abnormal time period video file from the local video storage based on the fixed shipborne monitoring unit, operation scenario information, and current monitoring time in the anomaly information locking result. After retrieving the abnormal time period video file, the system sequentially segments the video file according to the preset time length, generating multiple segmented video files corresponding to the time interval. Subsequently, each segmented video file is compressed to reduce the subsequent storage and transmission load.

[0032] Step 53: Read the vessel identification and camera information from the monitoring baseline table, and read the monitoring date corresponding to the current monitoring time and the segment number corresponding to the segment processing result. Combine the vessel identification, camera information, monitoring date, and segment number into a file name according to a preset naming order, and register the compressed video file with the file name. Summarize the registered compressed video files into an abnormal time period evidence file. The monitoring date refers to the date information converted from the current monitoring time; the segment number refers to the sequence number identifier corresponding to each segmented video file after sequential segmentation; the preset naming order refers to the pre-set rule for the arrangement order of each field in the file name. In specific implementation, the system first reads the vessel identification and camera information corresponding to the current abnormal shipborne monitoring unit from the monitoring baseline table, then extracts the monitoring date from the current monitoring time, and extracts the segment number corresponding to each segmented video file from the segment processing result. Subsequently, the vessel identification, camera information, monitoring date, and segment number are combined into a file name according to the preset naming order, and the compressed video file is registered with this file name. After all registrations are completed, the compressed video files from each registration are compiled to form an evidence file for the abnormal time period corresponding to that abnormal round. The abnormal time period evidence file generated in this way can simultaneously reflect the abnormal object, the collection location, the abnormal time, and the segmentation relationship.

[0033] This embodiment stores snapshots of the same-ship status of the abnormal shipborne monitoring unit separately when the continuous status code is not part of the evidence chain, and simultaneously locks the shipborne monitoring unit, operational scenario information, and the monitoring time of the current round, giving the abnormal state object clear object and time boundaries. By retrieving the video file of the abnormal period based on the abnormal information locking result, and performing sequential segmentation, compression, naming, and registration processing on the abnormal period video file, a one-to-one correspondence is formed between the abnormal evidence file and the abnormal state object. This allows the invention not only to identify abnormal states, but also to generate traceable, retransmittable, and verifiable abnormal period evidence files around the abnormal states.

[0034] In one embodiment of the present invention, the status retransmission module is used to acquire early warning information, a snapshot of the same-ship status of the abnormal shipborne monitoring unit, and an evidence file for the abnormal period, retransmit the early warning information and the same-ship status snapshot, and segment and retransmit the evidence file for the abnormal period. The status data refers to the data to be retransmitted, consisting of ship-side early warning information, shore-side early warning information, and a separately stored snapshot of the abnormal shipborne monitoring unit status; the evidence file refers to the file object to be retransmitted corresponding to the evidence file for the abnormal period; the status data upload status record refers to the result of recording the upload status and number of failures during the status data retransmission process; the evidence file upload status record refers to the result of recording the number of bytes uploaded, the number of remaining bytes, the current segment number to be transmitted, and the upload status during the evidence file segmentation and retransmission process. Specifically, retransmitting the early warning information and the same-ship status snapshot, and segmenting and retransmitting the evidence file for the abnormal period, includes: Step 61: Obtain ship-side early warning information, shore-side early warning information, separately stored snapshots of the abnormal shipborne monitoring units' status on the same vessel, and evidence files for the abnormal period. Define the ship-side early warning information, shore-side early warning information, and separately stored snapshots of the abnormal shipborne monitoring units' status as status data, and define the evidence files for the abnormal period as evidence files. In specific implementation, the system first reads the ship-side and shore-side early warning information already generated in the abnormal vessel, then reads the separately stored snapshots of the abnormal shipborne monitoring units' status and the corresponding evidence files for the abnormal period. Subsequently, the ship-side early warning information, shore-side early warning information, and separately stored snapshots of the abnormal shipborne monitoring units' status are merged into a status data object; simultaneously, the evidence files for the abnormal period are defined as evidence file objects. The objects to be uploaded are divided into status data and evidence files because the two types of objects differ in data volume, upload method, and failure recovery path. Status data typically consists of structured fields, has a smaller data volume, and is suitable for overall retransmission using a retry mechanism; evidence files typically consist of segmented video files, have a larger data volume, and are more suitable for segmented retransmission. Through this step, the system completes the classification of abnormal objects to be delivered, providing a unified input for subsequent execution of status data retransmission and evidence file splitting and retransmission.

[0035] Step 62: Upload the status data via the ship-shore synchronization interface. If the first upload fails, mark the upload status, accumulate the number of failures, add it to the queue for retransmission, and re-upload at preset retry intervals until the upload is successful or the number of failures reaches the preset maximum retry count. Record the upload status and the number of failures as a status data upload status record. The preset retry interval refers to the time interval between two status data retransmissions pre-set by the system; the preset maximum number of retryes refers to the maximum number of times the system allows to continue retrying after a status data retransmission failure. In specific implementation, the system first sends the status data to the shore end through the ship-shore synchronization interface. If the first upload is successful, the current upload status is directly recorded as successful, and a corresponding status data upload status record is formed. If the first upload fails, the current status data is marked as uploaded unsuccessfully, one failure count is accumulated, and it is added to the queue for retransmission. Afterward, the system retrieves the status data from the queue for retransmission at preset retry intervals and initiates the upload again. After each retransmission, the system updates the upload status and the number of failures. When the status data is successfully uploaded, retries stop, and the final upload status and number of failures are written to the status data upload status record. When the number of failures reaches the preset maximum number of retries, retries stop, and the final failure status and cumulative number of failures are written to the status data upload status record. Through this step, the system standardizes the retransmission process of status data into a bounded, status-recorded retry procedure, thereby ensuring that subsequent steps can determine whether abnormal status data has been successfully delivered based on the status data upload status record.

[0036] Step 63: Divide the evidence file into file segments according to the preset file segment size, and record the number of bytes uploaded, the number of bytes remaining, the current segment number to be uploaded, and the upload status. Upload the file segments one by one. If interrupted, continue uploading the unfinished file segments according to the current segment number to be uploaded. Generate an evidence file upload status record after the last file segment is successfully uploaded. The preset file segment size refers to the data size of a single file segment pre-set by the system; the number of bytes uploaded refers to the total amount of evidence file data that has been successfully uploaded to the shore end; the number of bytes remaining refers to the amount of data that has not yet been uploaded after subtracting the number of bytes uploaded from the total number of bytes in the evidence file; the current segment number to be uploaded refers to the sequential number of the next file segment that has not yet been uploaded in the current round. In specific implementation, the system first divides the evidence file into multiple file segments according to the preset file segment size. Then, before uploading each segment, initialize or update the number of bytes uploaded, the number of bytes remaining, the current segment number to be uploaded, and the upload status. The system then uploads file segments one by one according to the current segment number to be uploaded. For each successfully uploaded segment, the system updates the number of bytes uploaded, the number of bytes remaining, the current segment number to be uploaded, and the upload status. If the upload is interrupted, the system does not re-upload the successfully uploaded segments, but instead continues uploading the unfinished segments based on the current segment number to be uploaded. Once the last file segment is successfully uploaded, the system marks the overall upload status as complete and writes the number of bytes uploaded, the number of bytes remaining, the current segment number to be uploaded, and the overall upload status into the evidence file upload status record. Through this process, the system transforms the delivery of large volumes of evidence files during abnormal periods into an interruptible, recoverable, and traceable segmented and resumed upload process.

[0037] This embodiment divides anomaly-related objects into two categories: status data and evidence files. It employs a retry transmission mechanism for status data and a segmentation and continuation transmission mechanism for evidence files, respectively. This ensures that anomaly warning information, anomaly status snapshots, and evidence files for anomaly periods can be continuously delivered under ship-to-shore link fluctuations. This enables the invention to not only have anomaly identification and evidence generation capabilities, but also structured retransmission and continuation transmission capabilities for anomaly-related data.

[0038] In one embodiment of the present invention, the recovery summary module is used to obtain the previous round continuous status code, the current round continuous status code, the status data upload status record, and the evidence file upload status record of each shipborne monitoring unit, and to determine the breakpoint recovery status, persistent anomaly information, and the ship-wide summary status code. The previous round continuous status code refers to the continuous status code generated by the same shipborne monitoring unit in the previous monitoring round; the current round continuous status code refers to the continuous status code generated by the same shipborne monitoring unit in the current monitoring round; the breakpoint recovery status refers to the recovery result obtained by comparing the continuous status codes of two adjacent rounds bit by bit; the persistent anomaly information refers to anomaly information that has not been eliminated and has not completed anomaly closure after multiple rounds of continuous verification; the ship-wide summary status code refers to the ship-wide level status code obtained by uniformly comparing the current round continuous status codes of all shipborne monitoring units on the entire ship according to their corresponding positions. Specifically, determining the breakpoint recovery status, persistent anomaly information, and the ship-wide summary status code includes: Step 71: Obtain the previous and current continuity status codes for each shipborne monitoring unit, and compare them bit by bit according to the corresponding positions of the front-end acquisition validity value, spatiotemporal binding validity value, retention validity value, and ship-to-shore delivery validity value. When any corresponding position changes from invalid to valid, determine the recovery status of the corresponding breakpoint; when any corresponding position remains invalid, determine the persistence of the corresponding anomaly. In specific implementation, the system reads the previous and current continuity status codes for each shipborne monitoring unit, maintaining strict consistency in their bit order. The bit-by-bit comparison of corresponding positions refers to comparing the first position with the first position, the second position with the second position, the third position with the third position, and the fourth position with the fourth position, without cross-position comparison. Among them, the first position corresponds to the front-end acquisition validity value, the second position corresponds to the spatiotemporal binding validity value, the third position corresponds to the retention validity value, and the fourth position corresponds to the ship-to-shore delivery validity value. If a corresponding position was invalid in the previous continuity status code but valid in the current continuity status code, it indicates that the link corresponding to that position has recovered from an abnormal state to a normal state, and the system determines the recovery status of the breakpoint corresponding to that position accordingly. If a corresponding position is invalid in both the previous and current continuity status codes, it indicates that the link abnormality corresponding to that position has not been resolved, and the system determines that the abnormality corresponding to that position continues.

[0039] Step 72: Based on the status records of uploaded status data and uploaded evidence files, the system verifies the results of the ongoing anomaly. When all four digits of the current round's continuous status code are valid, the corresponding ship-side and shore-side warnings are closed. When any corresponding position is invalid for multiple consecutive rounds, and the status records of uploaded status data and uploaded evidence files do not indicate that the anomaly has been closed, the system determines that the anomaly information is ongoing. The anomaly closure means that the status data and evidence files corresponding to the anomaly have both achieved clear delivery results and are no longer in a state of pending retransmission or continuation. In specific implementation, after obtaining the ongoing anomaly result in step 71, the system continues to read the status records of uploaded status data and uploaded evidence files corresponding to the shipborne monitoring unit to determine whether the anomaly has been closed. If all four digits of the current round's continuous status code are valid, it indicates that the shipborne monitoring unit's front-end acquisition chain, spatiotemporal binding chain, retention chain, and ship-shore delivery chain have all returned to normal in the current round, and the system accordingly determines to close the corresponding ship-side and shore-side warnings. If a corresponding position remains invalid for multiple consecutive rounds, and the status records of uploaded status data and evidence files still indicate that the anomaly-related data has not been closed, the system escalates the anomaly to a persistent anomaly and generates corresponding persistent anomaly information. Closing the corresponding ship-side and shore-side warnings means stopping the anomaly status of the object in the ship-side and shore-side display terminals. Through this step, the system no longer judges solely based on whether the status bit remains invalid, but also incorporates the anomaly delivery status into the review, thus making the persistent anomaly information more accurately reflect whether the anomaly has truly ended.

[0040] Step 73: Obtain the current-cycle continuity status code of each shipborne monitoring unit and perform a unified comparison according to the corresponding positions of the front-end acquisition chain, spatiotemporal binding chain, retention chain, and ship-to-shore delivery chain. When all current-cycle continuity status codes at the same corresponding position are valid, the corresponding position of the overall ship summary status code is determined to be valid; otherwise, it is determined to be invalid. The continuity status code, breakpoint type, breakpoint recovery status, persistent anomaly information, overall ship summary status code, equipment basic information, ship position validity status, storage operation status, upload status, and monitoring update time are integrated into a standardized monitoring result synchronized between ship and shore. In specific implementation, the system reads the current-cycle continuity status code of all shipborne monitoring units and then performs a unified comparison according to the four corresponding positions. If a certain position is valid in all shipborne monitoring units, the overall ship summary status code for that position is determined to be valid; if any shipborne monitoring unit is invalid at a certain position, the overall ship summary status code for that position is determined to be invalid. The resulting ship-wide aggregated status code reflects the overall continuous status of the entire ship within the current cycle across the front-end acquisition chain, spatiotemporal binding chain, retention chain, and ship-to-shore delivery chain. After generating the ship-wide aggregated status code, the system integrates the continuous status codes, breakpoint types, breakpoint recovery status, and persistent anomaly information of each shipborne monitoring unit with the corresponding basic equipment information, ship position validity status, storage operation status, upload status, and monitoring update time to form standardized ship-to-shore synchronized monitoring results. These standardized monitoring results refer to result objects organized according to a unified field structure, capable of being used simultaneously for status display and anomaly viewing on both ship-side and shore-side display terminals. Through this step, the system further aggregates the unit-level status evolution results into ship-wide status results and outputs monitoring result objects in a unified format.

[0041] This embodiment establishes a cross-cycle verification mechanism for the status of shipborne monitoring evidence chain by comparing the previous and current continuous status codes bit by bit. By introducing the uploading of status data and evidence files into the verification process of persistent anomalies, a comprehensive judgment on whether the anomaly has truly been closed is achieved. By performing a unified comparison of the current continuous status codes at the ship-wide level, a ship-wide summary status code is generated, and further standardized monitoring results synchronized between ship and shore are formed. This enables the shipborne electronic monitoring equipment status real-time monitoring and early warning system and method described in this invention to not only identify single-cycle anomalies, but also to judge anomaly recovery, identify persistent anomalies, and output the overall status of the entire ship.

[0042] This invention also provides a method for real-time monitoring and early warning of the status of shipborne electronic monitoring equipment, comprising the following steps: Step 81: Obtain operation scene information, camera information, and basic information of shipborne equipment, and generate shipborne monitoring unit; Step 82: Obtain real-time device connectivity data and real-time ship position spatiotemporal data of each shipborne monitoring unit, and determine the validity value of front-end acquisition and the validity value of spatiotemporal binding; Step 83: Obtain the real-time operating data of the storage pool of each shipborne monitoring unit, the feedback data uploaded by the ship-to-shore synchronization interface, and the monitoring timestamp of this round, and determine the retention validity value and the ship-to-shore delivery validity value. Step 84: Generate a snapshot of the same-cycle status based on the front-end collected validity value, spatiotemporal binding validity value, retention validity value, ship-to-shore delivery validity value and the current round monitoring timestamp, and generate a continuity status code; Step 85: For the shipboard monitoring unit with continuous status code anomalies, perform anomaly information locking and generate evidence files for the abnormal period from the same ship status snapshot and video recording files of the abnormal period. Step 86: Obtain early warning information, snapshots of the same vessel status of the abnormal shipborne monitoring unit, and evidence files of the abnormal period; retransmit the early warning information and the snapshots of the same vessel status; and segment and retransmit the evidence files of the abnormal period. Step 87: Obtain the previous round continuity status code, current round continuity status code, status data upload status record, and evidence file upload status record of each shipborne monitoring unit, and determine the breakpoint recovery status, persistent abnormal information, and overall ship summary status code.

[0043] It should be noted that the range and threshold size are set for ease of comparison. The size of the threshold depends on the amount of sample data and the number of bases set by those skilled in the art for each set of sample data, as long as it does not affect the ratio between the parameter and the quantized value.

[0044] The embodiments of the present invention have been described above, but the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms based on the guidance of the present embodiments, all of which are within the protection scope of the present embodiments.

Claims

1. A real-time monitoring and early warning system for the status of shipborne electronic monitoring equipment, characterized in that, include: The unit generation module is used to acquire operational scenario information, camera information, and basic information of shipborne equipment, and to generate shipborne monitoring units. The spatiotemporal determination module is used to acquire real-time device connectivity data and real-time ship position spatiotemporal data of each shipborne monitoring unit, and to determine the validity value of the front-end acquisition and the validity value of the spatiotemporal binding. The retention and delivery module is used to obtain real-time operating data from the storage pool of each shipborne monitoring unit, feedback data uploaded from the ship-to-shore synchronization interface, and the monitoring timestamp for this round, and to determine the retention validity value and the ship-to-shore delivery validity value. The status snapshot encoding module is used to generate a status snapshot of the same round based on the validity value collected by the front end, the validity value of spatiotemporal binding, the validity value of retention, the validity value of ship-to-shore delivery, and the timestamp of the current round of monitoring, and to generate a continuous status code; The early warning evidence generation module is used to lock abnormal information and generate evidence files for abnormal periods from the same-ship status snapshots and video recordings of abnormal periods for shipborne monitoring units with continuous abnormal status codes. The status retransmission module is used to acquire early warning information, snapshots of the same vessel status of the abnormal shipborne monitoring unit, and evidence files of abnormal periods. It retransmits the early warning information and the snapshots of the same vessel status, and segments and retransmits the evidence files of abnormal periods. The recovery summary module is used to obtain the previous round of continuous status codes, the current round of continuous status codes, status data upload status records, and evidence file upload status records of each shipborne monitoring unit, and to determine the breakpoint recovery status, persistent abnormal information, and the overall ship summary status code.

2. The real-time monitoring and early warning system for the status of shipborne electronic monitoring equipment according to claim 1, characterized in that, Acquire operational scenario information, camera information, and basic information about shipborne equipment, and generate a shipborne monitoring unit, including: Step 11: Perform name unification, duplicate merging, and scene identifier generation on the operation scene information; based on the scene association relationship in the camera information configured for the electronic observer task, filter the target camera information corresponding to each operation scene information; Step 12: Based on the information from each target camera, extract the associated video recorder information, positioning source information, storage pool information, ship identification, device login parameters, and device network address from the basic information of the shipborne equipment; bind the information of each operation scenario, the information of each target camera, and the extraction results to generate each shipborne monitoring unit. Step 13: Generate standardized basic information records for each shipborne monitoring unit. The standardized basic information records include operation scene information, target camera information, video recorder information, positioning source information, storage pool information, ship identification, equipment login parameters, and equipment network address. Summarize the standardized basic information records to generate a monitoring benchmark table.

3. The real-time monitoring and early warning system for the status of shipborne electronic monitoring equipment according to claim 1, characterized in that, Acquire real-time device connectivity data and real-time ship position spatiotemporal data from each shipborne monitoring unit, and determine the validity values ​​of the front-end acquisition and spatiotemporal binding, including: Step 21: Based on the monitoring benchmark table, perform synchronous data collection in the same round for each shipborne monitoring unit; according to the device network address and device login parameters, read the connectivity and login results of the corresponding camera, as well as the connectivity and login results of the corresponding recorder; when the camera has both a real address and a recorder forwarding address, only read the connectivity result corresponding to the real address. Step 22: Determine the front-end acquisition validity value based on the camera connectivity results, camera login results, video recorder connectivity results, and video recorder login results corresponding to each shipborne monitoring unit; when the camera connectivity results, camera login results, video recorder connectivity results, and video recorder login results are all successful, the front-end acquisition validity value is determined to be valid; otherwise, the front-end acquisition validity value is determined to be invalid. Step 23: Read the real-time ship position, latitude and longitude, speed, heading and time identifier from the real-time ship position spatiotemporal data corresponding to each shipborne monitoring unit, and convert them into standardized fields; determine the spatiotemporal binding validity value of each shipborne monitoring unit based on the standardized fields and ship identifier; when the ship position field, time field and ship identifier in the standardized fields are complete and can be written to a record, the spatiotemporal binding validity value is determined to be valid, otherwise the spatiotemporal binding validity value is determined to be invalid.

4. A real-time monitoring and early warning system for the status of shipborne electronic monitoring equipment according to claim 1, characterized in that, Acquire real-time operational data from the storage pools of each shipborne monitoring unit, data uploaded via the ship-to-shore synchronization interface, and the current monitoring timestamp to determine the validity values ​​for retention and delivery from ship to shore, including: Step 31: Based on the monitoring benchmark table, read the storage pool information and ship identification associated with each shipborne monitoring unit; based on the real-time operation data of the storage pool, remove the system disk storage pool, and read the usage rate, real-time operation status and local data storage identifier of the non-system disk storage pool. Step 32: Determine the retention validity value of each shipborne monitoring unit based on the usage rate of the non-system disk storage pool, the real-time operating status, and the local data storage identifier for this round; when at least one non-system disk storage pool can retain data normally and has not reached the preset full load threshold, the retention validity value is determined to be valid; otherwise, the retention validity value is determined to be invalid. Step 33: Integrate the equipment status information and ship position information of each shipborne monitoring unit, write them into the ship identifier, and upload them by calling the ship-to-shore synchronization interface; determine the validity value of ship-to-shore delivery based on the feedback data uploaded by the ship-to-shore synchronization interface.

5. A real-time monitoring and early warning system for the status of shipborne electronic monitoring equipment according to claim 1, characterized in that, Based on the front-end collected validity values, spatiotemporal binding validity values, retention validity values, ship-to-shore delivery validity values, and the current monitoring timestamp, a snapshot of the same-round status is generated, and a continuous status code is generated, including: Step 41: Based on the front-end acquisition validity value, spatiotemporal binding validity value, retention validity value, ship-to-shore delivery validity value and the current round monitoring timestamp, generate the same-round status snapshot of each shipborne monitoring unit in the order of the front-end acquisition validity value, spatiotemporal binding validity value, retention validity value, ship-to-shore delivery validity value and the current round monitoring timestamp; Step 42: Extract the front-end acquisition validity value, spatiotemporal binding validity value, retention validity value and ship-to-shore delivery validity value from the same-ship status snapshots of each shipborne monitoring unit, and concatenate them in a fixed order to generate a continuous status code; Step 43: Determine the breakpoint type based on the continuity status code. When all four items of the continuity status code are valid, the breakpoint type is determined to be a continuous chain of evidence. When any one or more items of the continuity status code are invalid, determine the corresponding breakpoint type based on the invalid location, and generate ship-end early warning information and shore-end early warning information by combining the unit number, operation scenario information, equipment basic information and the monitoring timestamp of this round in the monitoring benchmark table.

6. A real-time monitoring and early warning system for the status of shipborne electronic monitoring equipment according to claim 1, characterized in that, For shipboard monitoring units with continuous status code anomalies, the system performs anomaly information locking and generates evidence files for the anomaly periods from onboard status snapshots and video recordings of the abnormal time periods, including: Step 51: When the continuous status code is not a continuous evidence chain, filter the corresponding shipborne monitoring unit; read the same-wheel status snapshot of the shipborne monitoring unit, and store the same-wheel status snapshot separately after associating it with the continuous status code and breakpoint type; at the same time, lock the shipborne monitoring unit, the operation scenario information and the current round monitoring time, and generate an anomaly information locking result; Step 52: Based on the shipborne monitoring unit, operation scenario information, and monitoring time of this round in the abnormal information locking result, retrieve the corresponding abnormal time period video file; divide the abnormal time period video file into segments according to the preset time length, and compress the segmented video file; Step 53: Read the ship identification and camera information in the monitoring benchmark table, read the monitoring date corresponding to the monitoring time of this round and the segment number corresponding to the segment processing result; combine the ship identification, camera information, monitoring date and segment number into a file name according to the preset naming order, and register the compressed video file with the file name, and summarize the registered compressed video files into an abnormal time period evidence file.

7. A real-time monitoring and early warning system for the status of shipborne electronic monitoring equipment according to claim 1, characterized in that, Acquire early warning information, snapshots of the same vessel's status from the abnormal shipborne monitoring unit, and evidence files for the abnormal period; retransmit the early warning information and the snapshots of the same vessel's status; and segment and retransmit the evidence files for the abnormal period, including: Step 61: Obtain ship-side early warning information, shore-side early warning information, separately stored abnormal shipborne monitoring unit status snapshots and abnormal period evidence files; determine ship-side early warning information, shore-side early warning information, and separately stored abnormal shipborne monitoring unit status snapshots as status data, and determine abnormal period evidence files as evidence files; Step 62: Upload the status data by calling the ship-shore synchronization interface. When the first upload fails, mark the upload status, accumulate the number of failures, add it to the queue to be re-uploaded, and re-upload at the preset retry time interval until the upload is successful or the number of failures reaches the preset maximum number of retries; record the upload status and the number of failures as the status data upload status record. Step 63: Divide the evidence file into file segments according to the preset file segment size, and record the number of bytes uploaded, the number of bytes remaining, the current segment number to be uploaded, and the upload status; upload the file segments one by one, and if interrupted, continue uploading the unfinished file segments according to the current segment number to be uploaded; generate an evidence file upload status record after the last file segment is successfully uploaded.

8. A real-time monitoring and early warning system for the status of shipborne electronic monitoring equipment according to claim 1, characterized in that, Obtain the previous round's continuity status code, the current round's continuity status code, status data upload status records, and evidence document upload status records for each shipborne monitoring unit; determine the breakpoint recovery status, persistent anomaly information, and the overall shipwide summary status code, including: Step 71: Obtain the previous and current continuity status codes of each shipborne monitoring unit, and compare them bit by bit according to the corresponding positions of the front-end acquisition validity value, spatiotemporal binding validity value, retention validity value, and ship-to-shore delivery validity value; when any corresponding position changes from invalid to valid, determine the recovery status of the corresponding breakpoint; when any corresponding position remains invalid, determine the continuation of the corresponding anomaly. Step 72: Based on the status records uploaded by the status data upload and the status records uploaded by the evidence file, review the results of the continuous anomaly; when all four digits of the continuous status code in this round are valid, determine to close the corresponding ship-side warning and shore-side warning; when any corresponding position is invalid for multiple consecutive rounds, and the status records uploaded by the status data upload and the status records uploaded by the evidence file do not indicate that the anomaly has been closed, determine the continuous anomaly information; Step 73: Obtain the current-cycle continuity status code of each shipborne monitoring unit and perform a unified comparison according to the corresponding positions of the front-end acquisition chain, spatiotemporal binding chain, retention chain, and ship-to-shore delivery chain; when all current-cycle continuity status codes at the same corresponding position are valid, the corresponding position of the overall ship summary status code is determined to be valid; otherwise, it is determined to be invalid; and integrate the continuity status code, breakpoint type, breakpoint recovery status, persistent abnormal information, overall ship summary status code, equipment basic information, ship position validity status, storage operation status, upload status, and monitoring update time into a standardized monitoring result synchronized between ship and shore.

9. A method for real-time monitoring and early warning of the status of shipborne electronic monitoring equipment, characterized in that, The real-time monitoring and early warning system for the status of shipborne electronic monitoring equipment as described in any one of claims 1-8 includes the following steps: Step 81: Obtain operation scene information, camera information, and basic information of shipborne equipment, and generate shipborne monitoring unit; Step 82: Obtain real-time device connectivity data and real-time ship position spatiotemporal data of each shipborne monitoring unit, and determine the validity value of front-end acquisition and the validity value of spatiotemporal binding; Step 83: Obtain the real-time operating data of the storage pool of each shipborne monitoring unit, the feedback data uploaded by the ship-to-shore synchronization interface, and the monitoring timestamp of this round, and determine the retention validity value and the ship-to-shore delivery validity value. Step 84: Generate a snapshot of the same-cycle status based on the front-end collected validity value, spatiotemporal binding validity value, retention validity value, ship-to-shore delivery validity value and the current round monitoring timestamp, and generate a continuity status code; Step 85: For the shipboard monitoring unit with continuous status code anomalies, perform anomaly information locking and generate evidence files for the abnormal period from the same ship status snapshot and video recording files of the abnormal period. Step 86: Obtain early warning information, snapshots of the same vessel status of the abnormal shipborne monitoring unit, and evidence files of the abnormal period; retransmit the early warning information and the snapshots of the same vessel status; and segment and retransmit the evidence files of the abnormal period. Step 87: Obtain the previous round continuity status code, current round continuity status code, status data upload status record, and evidence file upload status record of each shipborne monitoring unit, and determine the breakpoint recovery status, persistent abnormal information, and overall ship summary status code.

Images