Trusted sharing system for marine environment monitoring data

Abstract

The invention relates to the technical field of marine environment data informatization, and discloses a trusted sharing system for marine environment monitoring data. According to the method, a trust mechanism is constructed through the block chain and the smart contract, standardized access and high-precision space-time label binding of multi-source heterogeneous data are realized, and real-time evidence storage and tampering prevention of data fingerprints are ensured by using a double-chain structure; a dynamic verification engine based on a marine environment rule base automatically outputs a hierarchical confidence report, drives an intelligent contract to dynamically adjust access permission according to quality, and realizes safe and controllable sharing of data in combination with an attribute encryption technology, so that the data credibility, the quality evaluation efficiency and the permission management flexibility are remarkably improved; and the authenticity and the application value of ocean monitoring data are ensured.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of informationization of marine environment data, in particular to a marine environment monitoring data credible sharing system. BACKGROUND

[0002] The sharing of marine environment monitoring data mainly adopts a centralized database to store and share marine monitoring data, realizes multi-source data access through a unified interface, and manages by relying on basic data cleaning rules and static permission control mechanisms. However, in the prior art, it is difficult to effectively compatible heterogeneous device protocols and data formats, lacks a verification mechanism for the credibility of data sources, and cannot dynamically respond to data quality changes, resulting in doubts about the authenticity of shared data, lagging abnormal detection, and limiting the reasonable flow and application value of data due to rigid permission policies. Therefore, a marine environment monitoring data credible sharing system is proposed. SUMMARY

[0003] In view of the deficiencies of the prior art, the present application provides a marine environment monitoring data credible sharing system to solve the problems in the background art.

[0004] To achieve the above-mentioned purpose, the present application provides the following technical scheme: a marine environment monitoring data credible sharing system, comprising:

[0005] A multi-source heterogeneous data access and adaptation module is used to connect and receive multi-source heterogeneous raw monitoring data from different marine environment monitoring devices and platforms, and standardize the multi-source heterogeneous raw monitoring data into preprocessed data in a unified format;

[0006] A data preprocessing and space-time label module is connected with the multi-source heterogeneous data access and adaptation module, and is used to preliminarily clean the preprocessed data and additionally attach a space-time label of a geographical position coordinate and a unified time reference to generate standardized data with a space-time label;

[0007] A blockchain credible evidence storage module is connected with the data preprocessing and space-time label module, and is used to calculate a data fingerprint of the standardized data with a space-time label, and package the data fingerprint and related traceability information to generate an evidence storage transaction, and store the evidence storage transaction on a blockchain network;

[0008] A marine environment logical verification engine is connected with the blockchain credible evidence storage module, and has a rule library based on marine environment knowledge built-in; according to the type and space-time information of the standardized data with a space-time label, a matching environment logical rule is called to perform rationality verification, and a verification report containing a verification result, a confidence level and a hierarchical mark is outputted;

[0009] An intelligent contract driven sharing and permission management module is deployed on the blockchain network, and is connected with the blockchain credible evidence storage module and the marine environment logical verification engine; the module is used to:

[0010] executing a data provider defined sharing policy smart contract, the policy including data access permissions and usage conditions;

[0011] dynamically adjusting data accessibility according to the confidence level of the verification report

[0012] generating a dynamic access token upon authorized access;

[0013] a trusted sharing database: storing the notarized standardized data with spatiotemporal tags and its corresponding data fingerprints, verification reports in a distributed manner;

[0014] a data access interface module: connecting with the smart contract driven sharing and permission management module and the trusted sharing database, for verifying the dynamic access token and returning authorized data.

[0015] Preferably, the rule base of the marine environment logical verification engine includes but is not limited to:

[0016] spatiotemporal consistency rule: checking whether there are significant contradictions in the same type of monitoring data of adjacent spatiotemporal points;

[0017] physical quantity range rule: checking whether the temperature, salinity, dissolved oxygen, pH value, etc. are within the reasonable marine environment range;

[0018] physical / chemical / biological correlation rule: checking whether there is a reasonable correlation between different parameters;

[0019] device performance limitation rule: checking based on the accuracy, range, response time, etc. of the specific sensor model;

[0020] historical data comparison rule: comparing and analyzing abnormal fluctuations with historical same period or adjacent location data.

[0021] Preferably, the blockchain trusted notarization module adopts a double-chain structure:

[0022] The first chain is a notarization main chain, used for storing the final state and consensus result of key notarization transactions (data fingerprint, spatiotemporal tag summary, device identification, operator signature, verification report fingerprint);

[0023] The second chain is a high-speed side chain or state channel, used for fast processing of fingerprint calculation and initial notarization request of massive standardized data, and anchoring batch notarization summaries to the notarization main chain regularly.

[0024] Preferably, the related traceability information at least includes device identification, spatiotemporal tag summary and operator identity signature information; the blockchain network adopts a consortium chain architecture.

[0025] Preferably, the multi-source heterogeneous data access and adaptation module is built-in with multiple protocol parsers and data format converters for standardizing different data, and the original monitoring data at least includes device identification, location information, timestamp, sensor type and measurement value.

[0026] Preferably, the trusted shared database adopts attribute-based encryption (ABE) or proxy re-encryption (PRE) technology, and the data access interface module can only decrypt data when the requester attribute meets the encryption policy.

[0027] Preferably, the marine environment logical verification engine grades the verification results, including: trusted (confidence ≥ 90%), to be reviewed (70% ≤ confidence < 90%), and unavailable (confidence < 70%); and the smart contract driven sharing and permission management module only allows access to data marked as "trusted".

[0028] Preferably, the system is built-in with a data anomaly processing procedure: when the marine environment logical verification engine outputs a "to be reviewed" or "unavailable" label, a review request is automatically triggered to the data provider, and the data to be corrected is temporarily stored in an isolated sandbox.

[0029] Preferably, the system further comprises a management control module, which provides a visual interface for administrators, data providers and data users to configure data access, manage sharing strategies, view evidence and verification information, and manage permissions.

[0030] Compared with the prior art, the present application has the following beneficial effects:

[0031] The present application builds a trust mechanism through blockchain and smart contract, realizes standardized access of multi-source heterogeneous data and high-precision space-time label binding, uses a double-chain structure to ensure real-time evidence storage and non-tamperability of data fingerprints, and automatically outputs a graded confidence report based on a dynamic verification engine of a marine environment rule base, drives a smart contract to dynamically adjust access permissions according to quality, and realizes safe and controllable sharing of data by combining attribute encryption technology, thereby significantly improving data credibility, quality evaluation efficiency and permission management flexibility, and guaranteeing the authenticity and application value of marine monitoring data. BRIEF DESCRIPTION OF DRAWINGS

[0032] Figure 1 The figure is a whole architecture diagram of the system of the present application;

[0033] Figure 2 The figure is a double-chain evidence storage structure diagram of the present application;

[0034] Figure 3 The figure is a logical verification engine flowchart of the present application;

[0035] Figure 4 The figure is a smart contract permission control flowchart of the present application;

[0036] Figure 5 The flowchart of the abnormal structure processing of the present application. DETAILED DESCRIPTION

[0037] Referring to Figures 1-5 The present application is a marine environment monitoring data trusted sharing system. The present application solves the three core problems of low source credibility, missing quality assessment, and rigid permission control in marine data sharing by constructing a blockchain storage and smart contract collaborative trust mechanism. The embodiment is applied to the East China Buoy Monitoring Network, and is deployed in a cloud-edge collaborative architecture (edge processing data collection, cloud performing storage and sharing), realizing full-process closed-loop management from data collection to trusted sharing.

[0038] 1. Multi-source heterogeneous data access and adaptation module

[0039] Solve the access problem caused by the diversity of marine monitoring equipment protocols and the non-uniformity of data formats.

[0040] Input: raw monitoring data stream, for example:

[0041] Buoy (Modbus TCP protocol): {"device_id": "BUOY_EC01", "lat": 31.2, "lon": 122.5, "time": "2023-08-15T08:00:00Z", "sensor": "thermometer", "value": 25.3}.

[0042] Unmanned ship (MQTT protocol): binary data stream (such as 0x3E 0xA1..., including position, time, sensor reading).

[0043] Satellite remote sensing (HTTP API): GeoJSON format data (including image metadata, observation value, space-time range).

[0044] 1. Protocol analysis: The protocol parser (such as Modbus parser, MQTT unpacker, HTTP API client) in the module automatically selects the corresponding parser according to the data source identifier. For example, for MQTT binary stream, the parser disassembles and verifies according to the pre-defined message structure (start symbol, device ID, longitude, latitude, timestamp, sensor type code, value length, value, check code).

[0045] 2. Data extraction and normalization: The parsed valid data fields (device ID, latitude, longitude, timestamp, sensor type, measurement value) are extracted. The timestamp is converted to UNIX timestamp (millisecond precision). The sensor type name (e.g. "thermometer", "salinity_sensor") is mapped to an internal uniform code (e.g. "temperature", "salinity"). The location information (latitude and longitude) is kept as floating point numbers.

[0046] 3. Format conversion: The extracted and converted data is encapsulated into a uniform pre-processing data structure inside the system.

[0047] Output: Structured pre-processing data table (JSON or database record) containing the following core fields:

[0048]

[0049] Unified access of 12 types of mainstream monitoring equipment raw data, conversion delay <100ms, providing standardized input for subsequent processing.

[0050] 2. Data preprocessing and spatio-temporal tagging module

[0051] Perform data quality preliminary screening and attach high-precision uniform spatio-temporal tags.

[0052] Input: Pre-processed data table from the multi-source heterogeneous data access and adaptation module.

[0053] 1. Data cleaning:

[0054] Missing value check: Check if the mandatory fields (device_id, position_lat, position_lon, timestamp, sensor_type, value) of each record are missing. If any mandatory field is missing, or the missing rate of non-mandatory fields exceeds 30%, mark the record as invalid and discard it.

[0055] GPS drift correction: For the same device data reported continuously:

[0056] Calculate the Euclidean distance and time difference between the adjacent two records.

[0057] Calculate the instantaneous speed: speed = distance / time difference.

[0058] If the instantaneous speed is greater than a preset threshold (e.g. 30 knots, about 15.4 m / s, much higher than the normal moving speed of the buoy), it is determined that the GPS drift is abnormal. Correction method: use linear interpolation method, use the effective position data before and after the device to calculate the most likely position (lat_interp, lon_interp) at the abnormal time point to replace the abnormal value.

[0059] Value range preliminary check: check if the measured value is within a reasonable range of the sensor's physical range (e.g. temperature sensor range -5℃ ~ 45℃). Values outside the range are marked as suspicious (but not immediately discarded, pending environmental engine deep verification).

[0060] 2. Space-time label addition:

[0061] Space label (GeoHash encoding): Use the GeoHash algorithm to encode the latitude and longitude (position_lat, position_lon) into a string (set the precision level to 8, for example "wtw3sz"). Precision level 8 corresponds to an error range of about ±19 meters, which meets most marine monitoring needs. The encoding process is represented as: geo_hash = geohash_encode(lat, lon, precision = 8).

[0062] Time label: Ensure that the timestamp is in UTC time. If the original data is in local time, convert it to UTC time according to the time zone information. The final time label is stored as a UNIX timestamp (millisecond-level precision), for example 1692086400000.

[0063] Quality label: According to the cleaning result, add quality_flag to the record (for example: 0 = valid, 1 = corrected after cleaning, 2 = suspicious to be verified).

[0064] Output: JSON format standardized data with space-time label and quality label:

[0065]

[0066] It improves the space-time consistency and basic quality of the data, effectively filters out invalid data, controls the spatial positioning error within ±19 meters, and achieves millisecond-level time synchronization accuracy, laying the foundation for credible evidence.

[0067] 3. Blockchain credible evidence module

[0068] Build data credible traceability capability, calculate data fingerprint and store on chain.

[0069] Input: standardized data with space-time label from the data preprocessing and space-time label module.

[0070] 1. Calculate data fingerprint: Use SHA-256 hashing algorithm to calculate the hash value of the concatenated string of standardized data key fields (including data_id, sensor_type, value, timestamp, geo_hash), generate a unique data fingerprint data_fp, represented as:

[0071] data_fp = SHA256(data_id || sensor_type || value || timestamp || geo_hash)

[0072] Where || represents the string concatenation operation.

[0073] 2. Generate space-time label digest: Perform SHA-256 hashing on the space-time label (the first 8 characters of geo_hash + timestamp) to generate the digest space_time_digest, represented as:

[0074] space_time_digest = SHA256(geo_hash || (timestamp) 0:7 )

[0075] Where (timestamp) 0:7 represents the first 8 characters (index 0 to 7) of the timestamp string.

[0076] 3. Construct evidence storage transaction: Assemble a JSON transaction data structure containing the following core fields:

[0077]

[0078] 4. Double-chain evidence storage

[0079] High-speed side chain (handle massive fingerprints and initial evidence storage): Use a high-performance blockchain platform (such as a private chain based on Geth). Send the constructed evidence storage transaction to the side chain node. The side chain node quickly verifies the transaction format and signature validity, and packs it into a side chain block. The side chain has high throughput (design target 12,000+ TPS) and is specifically designed to handle massive data fingerprint calculation and initial evidence storage requests.

[0080] Storage main chain (store key summary and final consensus): Use consortium chain platform (such as Hyperledger Fabric). Side chain submits the Merkle root hash of the latest batch of side chain transaction blocks (representing the aggregated summary of all transactions in this batch) and key information (such as starting / ending side chain block height, time range) as an anchor transaction to the main chain every 5 minutes, for example. The consortium nodes of the main chain reach a consensus on the anchor transaction (such as Kafka + Raft), and write it into the main chain block after consensus. The main chain stores the summary anchor point of the side chain batch, rather than all the original transactions, ensuring the final security and tamper resistance of the key storage information.

[0081] Output: For side chain storage, return the side chain transaction receipt (including transaction hash 0x9a3f...cbd2 and side chain block height #12345). For main chain anchoring, return the main chain transaction receipt (including main chain transaction hash 0xfed5...a1b2 and main chain block height #7821). The system internally maintains a mapping relationship between data_id and its corresponding side chain transaction hash and main chain anchor transaction hash.

[0082] The double-chain architecture realizes real-time storage of massive data, the main chain has high tamper resistance, and solves the problem of source traceability.

[0083] 4. Marine environment logical verification engine

[0084] Built-in oceanographic rule base, dynamically call rules for data rationality verification.

[0085] Input: Standardized data with spatiotemporal tags from the data preprocessing and spatiotemporal tag module + historical database (storing historical data of adjacent spatiotemporal points) + device metadata database (storing sensor accuracy, range).

[0086] The engine applies the rule set in sequence or in parallel for verification, and each rule verification failure will reduce the confidence of the data (initial value 100%):

[0087] 1. Spatiotemporal consistency rule: Query the historical database for data of the same device or adjacent location (geo_hash first 6-7 bits match) within a similar time (such as ±1 hour) for the same type of sensor.

[0088] Logic: Calculate the difference between the current value and the adjacent value / average value. If the difference exceeds a reasonable threshold (such as salinity > 1 ‰, temperature > 2 ℃), an exception is triggered.

[0089] Impact: confidence new = confidence old -20% (example value).

[0090] 2. Physical quantity range rule: Check if the measured value is within a reasonable range of the known marine environment (not the sensor range).

[0091] Logic: e.g. open sea water temperature <-2℃ or >40℃; salinity <0 or >50psu; dissolved oxygen <0mg / L; pH <6.5 or >9.0.

[0092] Impact: If violated, directly judged as invalid confidence new = 0%.

[0093] 3. Physical / chemical / biological correlation rule: Check if the logical relationship between the associated parameters is reasonable.

[0094] Logic: e.g.

[0095] Temperature-salinity relationship (T-S): In a specific sea area / water layer, temperature rise usually accompanies slight rise or stability of salinity. If the reported data temperature ↑ while salinity ↓ abnormally, it is violated.

[0096] Chlorophyll and nutrients: Nutrients (nitrate, phosphate) are usually the limiting factor of chlorophyll (phytoplankton biomass indicator), and there is a positive correlation. It may not be reasonable for chlorophyll to be abnormally high without nutrient input.

[0097] Impact: confidence new = confidence old -15% (example value).

[0098] 4. Equipment performance limitation rule: According to the sensor model information in the equipment meta database, obtain its nominal accuracy, range, response time, etc.

[0099] Logic: Check if the measured value exceeds the sensor range; check if the value change rate exceeds the maximum response capability of the sensor (e.g. temperature jumps 10℃ within 1 second).

[0100] Impact: If it exceeds the range, confidence new = 0%; if the response is abnormal, confidence new = confidence old -10% (example value).

[0101] 5. Historical data comparison rule: Compare with historical same period (same month and same day ± N days) or adjacent position long-term average data.

[0102] Logic: Calculate the number of times the current value deviates from the historical average value or standard deviation. For example, the dissolved oxygen value drops more than 3 times the standard deviation.

[0103] Impact: confidence new= confidence old -10% x (deviation factor - 2) (example formula).

[0104] Classification Marking: Marking according to the final calculated confidence value:

[0105] Valid: confidence >= 90% -> Green Mark;

[0106] To be reviewed: 70% <= confidence < 90% -> Yellow Mark;

[0107] Invalid: confidence < 70% -> Red Mark.

[0108] Output: JSON format verification report

[0109]

[0110]

[0111] Identify more than 95% of false / abnormal data, average verification time <200ms, provide quantitative quality basis.

[0112] 5. Smart contract driven sharing and permission management module

[0113] Automatically execute sharing strategies using smart contracts, dynamically respond to data quality changes.

[0114] Input: Verification report from marine environment logical verification engine (containing data_id, mark_level, confidence) + data provider predefined sharing strategy (stored in smart contract).

[0115] 1. Strategy smart contract execution: When a data user requests access to a specific data_id, trigger the smart contract deployed on the blockchain (usually the notarization main chain or side chain). The contract code contains the access control logic set by the data provider (usually based on access control list ACL or attributes).

[0116] Example contract fragment (Solidity-like pseudo code):

[0117]

[0118]

[0119] 2. Dynamic access control: Smart contract makes real-time decisions based on the mark_level (mapped to trustLevel) of the verification report:

[0120] Trustable (trustLevel = 1): Allow access if the requester organization is in the authorized list. The contract calls the generateToken function to generate a token.

[0121] Under review (trustLevel = 2): Only allow access to the data owner or specified review roles (usually for data provider self-check reasons). Other requesters are rejected.

[0122] Not available (trustLevel = 3): All access requests are prohibited. The contract automatically triggers the exception handling process (see exception handling process later).

[0123] Dynamic access token generation: When access is allowed, the smart contract calls an off-chain service or uses on-chain randomness to generate an encrypted, time-limited dynamic access token (e.g. JWT-JSON Web Token). The token contains key information: {"data_id":"...","user_id":"OceanUniv","access_scope":"read-only / temperature","expire":1692172800}, and is signed with the module private key.

[0124] Output: Dynamic access token (encrypted string, such as JWT) or access rejection message + reason (e.g. "Data under review").

[0125] Implement automatic permission management to ensure that only "trustable" data is open for sharing.

[0126] 6. Trustable shared database

[0127] Use ABE / PRE encryption technology to ensure storage confidentiality.

[0128] 1. Storage content: Structured storage of the following information:

[0129] Standardized data with space-time labels (from data preprocessing and space-time label module); Corresponding data fingerprint (from blockchain trusted storage module, data_fp); Verification report (from marine environment logical verification engine); Related blockchain storage information (main / side chain transaction ID).

[0130] 2. Encryption method: Use attribute-based encryption (ABE).

[0131] Policy definition: Data providers define decryption policies when uploading data. The policy is a Boolean expression that describes which attribute combinations of users can decrypt. For example: (institution type: "research institution" AND data use: "non-commercial research") OR (security permission level >= 3).

[0132] Data Encryption: Encrypt data plaintext with ABE public key that matches the policy. Only when user's private key attributes meet the policy, can it be decrypted.

[0133] Key Management: Trusted authority (e.g. system administrator or specialized key management service) is responsible for distributing private keys containing user's attribute set.

[0134] 3. Technical Implementation:

[0135] Distributed Storage: Use distributed file system / IPFS cluster to store encrypted data blocks, achieve high availability and scalability. Metadata and index are stored in queryable databases (e.g. MongoDB, PostgreSQL).

[0136] Access Control: Data access interface module (below) is responsible for verifying the validity of the user's token and checking whether its attributes meet the ABE policy of the target data when the user requests data. Only when the attributes match the policy, will the decryption operation be performed and the plaintext will be returned to the user.

[0137] Output: This module mainly responds to query requests and does not directly output externally. The query result returned is an encrypted data block.

[0138] Decryption capability is dynamically bound to user attributes, maintaining high storage throughput, effectively balancing security and performance.

[0139] 7. Data Access Interface Module

[0140] As a data sharing security gateway, it performs token verification and decryption operations.

[0141] Input: User's data query request (specify data_id or query condition) + dynamic access token (from smart contract driven sharing and permission management module).

[0142] 1. Token Verification: Use module public key to verify token signature, ensure token authenticity and integrity; check if the token is within the valid period (expire > current_time); parse token content to get authorization information (data_id, user_id, access_scope).

[0143] 2. Access Authorization Confirmation: Although the smart contract has performed an authorization check when issuing the token, the interface module will again quickly confirm whether the access rights corresponding to the token are still valid for the current request data_id and access_scope (prevent token from being stolen or permissions revoked within the token validity period). This is usually achieved by querying the smart contract state or access control list cache.

[0144] 3. Query Trusted Share Database: Retrieve corresponding encrypted data block and its metadata (including ABE decryption policy) from Trusted Share Database according to the requested data_id.

[0145] 4. ABE Policy Attribute Matching and Decryption:

[0146] Get user attributes (usually from system user database or attribute certificate, such as {Institution Type: "Research Institution", Data Purpose: "Ecological Research", Security Clearance Level: 2}).

[0147] Match and calculate user attributes with target data's ABE decryption policy.

[0148] Only when user attributes satisfy the policy: invoke ABE decryption algorithm to decrypt encrypted data block using user's attribute private key, get data plaintext.

[0149] 5. Result Filtering and Returning (Optional): According to access_scope in token (such as "read-only / temperature"), filter returned plaintext data, only return data within authorized scope (for example, only return temperature field, or only read not write).

[0150] Output:

[0151] Success: Return requested plaintext data (or subset within authorized scope).

[0152] Failure: Return error code and reason (such as: 403 Forbidden - Token invalid / expired, 403 Forbidden - Access denied, 403 Forbidden - Attributes do not satisfy policy, 404 Not Found).

[0153] Support 1000+ concurrent requests, response <150ms, achieve "on-demand decryption" secure delivery.

[0154] 8. Abnormal processing flow

[0155] Automatically respond to "pending review / unavailable" data, isolate problem data.

[0156] Trigger condition: The verification report output by the marine environment logical verification engine has a mark_level of "pending review" or "unavailable".

[0157] 1. Automatic notification:

[0158] The system sends an alert to the data provider's designated contact via a reliable messaging protocol (e.g. SMTP email, DingTalk / DingBot API, SMS).

[0159] The system sends an alert to the data provider's designated contact via a reliable messaging protocol (e.g. SMTP email, DingTalk / DingBot API, SMS).

[0160] Notification content examples:

[0161]

[0162] 2、Data isolation:

[0163] The system immediately migrates standardized data marked as "under review" or "unavailable", its corresponding verification report, and evidence information from the main business database to a dedicated isolated sandbox environment.

[0164] Sandbox implementation: a separate, strictly controlled access database cluster (e.g. Redis cluster or isolated MongoDB / PostgreSQL instance). Only the index or reference to the data is retained in the main database and trusted shared database (marked as isolated), pointing to the actual data in the sandbox. The smart contract will reject all access requests for isolated data (except for data owners / reviewers).

[0165] 3、Review and correction:

[0166] Data provider personnel log in to the "data review" interface of the management control module (below).

[0167] The interface displays detailed information about the isolated data: raw data, standardized data, verification report, triggered rules, historical data comparison charts, etc.

[0168] The provider can:

[0169] Confirm the anomaly: if the data is confirmed to be invalid (e.g. sensor failure), the data can be discarded. The system records the reason for discarding.

[0170] Correct the data: if it is believed to be a transmission or processing error, a corrected value (e.g. corrected salinity value) or corrected raw data file can be provided on the interface.

[0171] Add explanation: if the data is a real abnormal value (e.g. red tide, pollution event), a scientific explanation can be added to request the data to be marked as "special event - trusted".

[0172] 4、Reprocessing:

[0173] If the provider submits a corrected value or corrected raw data, the system will:

[0174] Overwrite the original isolated data with new data (or regenerate the standardized data based on new original data).

[0175] Move the corrected data out of the sandbox and resubmit it to the data preprocessing and spatiotemporal tagging or blockchain trusted storage (generally generate a corrected storage transaction) and marine environment logic verification engine for reprocessing and verification.

[0176] According to the new verification results (confidence and labels), the data may become "trusted" again and enter the sharing process, or remain in the "to be reviewed / unusable" state.

[0177] 100% of problem data is processed in a timely manner, with short average repair time, preventing misuse of propagation.

[0178] 9. Management control module

[0179] Provide visual operation interfaces for various users.

[0180] Specific implementation process and functional interface:

[0181] User roles and functional panels:

[0182] 1. Data Provider (Data Provider):

[0183] Panel: Data access configuration, sharing strategy management, my data dashboard, data review.

[0184] Data access configuration: Configure the access parameters of the devices it is responsible for (protocol type, IP / URL, port, authentication information, data format mapping rules). Provide test connection function.

[0185] Sharing strategy management: Visual interface to define and manage the access strategy of its data smart contract. Authorized organizations can be added / removed, data usage restrictions can be set, ABE encryption strategies can be defined, and minimum trust level requirements can be set. Support policy version management and release.

[0186] My data dashboard: View the list of its provided data, status (normal / to be reviewed / unusable), storage information (on-chain transaction ID / status), verification report details, and access log statistics.

[0187] Data review: Receive data to be reviewed alerts, view data details, verification reports, historical comparisons, and perform data confirmation, discard or correction operations (see exception handling process).

[0188] Output content example (sharing strategy management): Strategy editor interface, policy release status, authorized organization list, ABE strategy expression preview.

[0189] 2. Research user / Data Consumer:

[0190] Panel: Data Catalog Browsing, Data Retrieval & Application, My Access Token, Download History.

[0191] Data Catalog Browsing: View metadata of publicly accessible or authorized datasets (spatiotemporal range, sensor type, data provider, average confidence, sample preview - non-sensitive information).

[0192] Data Retrieval & Application: Retrieve data based on conditions such as spatiotemporal range, sensor type, confidence threshold. Select desired data to initiate access application. View application status (approved / rejected / pending).

[0193] My Access Token: View currently valid access tokens and their details (authorized data ID, range, validity period). Manually revoke unused tokens.

[0194] Download History: View historical data download records (time, data ID, size, status).

[0195] Output content example (data retrieval result): List of standardized data summaries meeting conditions (without sensitive values), proof-of-existence status icon, verification report trustworthiness marker, application button.

[0196] 3. System Administrator:

[0197] Panel: System Monitoring, User & Permission Management, Blockchain Proof-of-Existence Monitoring, Exception Dashboard, Device Metadata Management, Rule Library Management.

[0198] System Monitoring: View system overall operation status dashboard (data access volume, throughput, latency, module load, storage usage).

[0199] User & Permission Management: Manage system user accounts (add, delete, modify, query), role assignment, organization management. Manage ABE attribute authorities.

[0200] Blockchain Proof-of-Existence Monitoring: Integrate blockchain explorer function, view main chain / side chain block height, transaction quantity, transaction details (hash, type, time), node status.

[0201] Exception Dashboard: Centralized view of all data lists in "pending review" and "unavailable" states (see isolated sandbox list in exception handling process), track processing progress.

[0202] Device Metadata Management: Maintain sensor device model library, input / update device performance parameters such as accuracy, range, response time (for marine environment logic verification engine).

[0203] Rule base management: view, configure and update the rule base of the marine environment logical verification engine (threshold adjustment, rule enable / disable, add new rules).

[0204] Output content example (blockchain storage monitoring): blockchain browser view - block list, transaction list, transaction details (sender, receiver, gas, input data digest), network topology diagram.

[0205] 4. Operator:

[0206] Panel: operation log, performance analysis, isolated sandbox management.

[0207] Operation log: query operation log, error log, and audit log of each module of the system.

[0208] Performance analysis: view historical trends and real-time monitoring of processing delay, resource consumption (CPU, memory, network) of each module. Set alarm threshold.

[0209] Isolated sandbox management: view isolated sandbox storage usage. Perform sandbox data backup, archiving or cleaning operations (according to strategy). Monitor sandbox access log.

[0210] Output content example (isolated sandbox management): isolated sandbox data list (data ID, device, time, location, marking reason, status, storage time), storage capacity statistics, access log.

[0211] Implement full-link data tracking, significantly improve system operability and transparency.

[0212] Summary of embodiments:

[0213] The embodiment of the present application provides a marine environment monitoring data trusted sharing system, which realizes full-process closed-loop management through a cloud-edge collaborative architecture (edge data collection, cloud processing and storage and sharing) in an East China buoy monitoring network: first, a multi-source heterogeneous data access module unifies and standardizes the original data of buoys, unmanned ships and satellites; the data preprocessing module cleans and adds high-precision space-time labels (GeoHash encoding and UTC timestamp); the blockchain double-chain storage module processes massive data fingerprints through a high-speed side chain, anchors key summaries on the main chain to ensure source credibility; the marine environment logical verification engine calls the rule base of space-time consistency and parameter correlation for intelligent checking and outputs a hierarchical confidence report; the sharing module driven by a smart contract dynamically controls permissions according to the verification results, allowing access only to "trusted" data, and finally realizes controllable sharing through an encrypted database and a secure interface, thereby solving the three core problems of low source credibility, missing quality assessment and rigid permission control.

Claims

1. A system for trustworthy sharing of marine environment monitoring data, characterized in that, Comprise: Multi-source heterogeneous data access and adaptation module: for connecting and receiving multi-source heterogeneous raw monitoring data from different marine environment monitoring devices and platforms, and standardizing them into pre-processed data in a unified format; Data preprocessing and spatio-temporal tagging module: connected with the multi-source heterogeneous data access and adaptation module, for preliminary cleaning of the pre-processed data, and adding spatio-temporal tags with geographical location coordinates and unified time reference, to generate standardized data with spatio-temporal tags; Blockchain trusted storage module: connected with the data preprocessing and spatio-temporal tagging module, for calculating the data fingerprint of the standardized data with spatio-temporal tags, and packaging the data fingerprint and related traceability information to generate a storage transaction, and storing it on the blockchain network; Marine environment logical verification engine: connected with the blockchain trusted storage module, with an internal rule base based on marine environment knowledge; according to the type and spatio-temporal information of the standardized data with spatio-temporal tags, the matching environmental logical rules are called for rationality verification, and the verification report containing verification results, confidence and classification marks is output; Smart contract driven sharing and permission management module: deployed on the blockchain network, connected with the blockchain trusted storage module and marine environment logical verification engine; this module is used to: Execute the sharing strategy smart contract defined by the data provider, which includes data access permission and usage conditions; Dynamically adjust the accessibility of data according to the confidence of the verification report Generate dynamic access tokens when authorized access; Trusted sharing database: distributed storage of the standardized data with spatio-temporal tags and its corresponding data fingerprint, verification report after storage; Data access interface module: connected with the smart contract driven sharing and permission management module and trusted sharing database, used to verify the dynamic access token and return the authorized data.

2. The system for trustworthy sharing of marine environment monitoring data according to claim 1, wherein, The rule base of the marine environment logical verification engine includes but is not limited to: Spatio-temporal consistency rules: check whether there are significant contradictions in the same type of monitoring data of adjacent spatio-temporal points; Physical quantity range rules: check whether temperature, salinity, dissolved oxygen, pH value, etc. are within the reasonable marine environment range; Physical / chemical / biological correlation rules: check whether there is a reasonable correlation between different parameters; Device performance limitation rules: check based on the accuracy, range, response time, etc. of specific sensor models; Historical data comparison rules: compare with historical data of the same period or adjacent location to analyze abnormal fluctuations.

3. The system for trustworthy sharing of marine environment monitoring data according to claim 1, wherein, The blockchain trusted storage module adopts a double-chain structure: The first chain is the storage main chain, used to store the final state and consensus result of key storage transactions (data fingerprint, spatio-temporal tag summary, device identification, operator signature, verification report fingerprint); The second chain is a high-speed side chain or state channel, used to quickly process massive standardized data fingerprint calculation and initial storage requests, and anchor batch storage summaries to the storage main chain regularly.

4. The system for trustworthy sharing of ocean environment monitoring data according to claim 1, wherein, The related traceability information at least includes device identification, spatio-temporal tag summary and operator identity signature information; the blockchain network adopts a consortium chain architecture.

5. The system for trustworthy sharing of ocean environment monitoring data according to claim 1, wherein, The multi-source heterogeneous data access and adaptation module is built-in with multiple protocol analyzers and data format converters, which are used to standardize different data, and the original monitoring data at least includes device identification, location information, timestamp, sensor type and measurement value.

6. The system for trustworthy sharing of ocean environment monitoring data according to claim 1, wherein, The trusted shared database adopts attribute-based encryption (ABE) or proxy re-encryption (PRE) technology, and the data access interface module can only decrypt the data when the requester's attributes meet the encryption policy.

7. The system for trustworthy sharing of ocean environment monitoring data according to claim 1, wherein, The marine environment logical verification engine grades the verification results, including: trusted (confidence ≥ 90%), to be reviewed (70% ≤ confidence < 90%), and unavailable (confidence < 70%); the smart contract driven sharing and permission management module only allows access to data marked as "trusted".

8. The system for trustworthy sharing of ocean environment monitoring data according to claim 7, wherein, The system is built-in with data exception handling process: when the marine environment logical verification engine outputs "to be reviewed" or "unavailable" label, it automatically triggers a review request to the data provider, and temporarily stores the data to be corrected in the isolated sandbox.

9. The system for trustworthy sharing of ocean environment monitoring data according to claim 1, wherein, The system also includes a management control module, which provides a visual interface for administrators, data providers and data users to configure data access, manage sharing strategies, view evidence and verification information, and manage permissions.

Images