Port Data Sharing Method Based on Intelligent Scheduling

Abstract

This invention relates to a port data sharing method based on intelligent scheduling, applicable to data demander systems, data provider systems, and data sharing platforms. The demander submits a sharing ticket, which the platform sends to the provider. The provider returns a commitment result based on pruning rules: when the sharing policy corresponding to the purpose identifier is "only allow judgment" or "prohibit judgment," only the judgment result field is delivered; when the time limit requirement exceeds the committable range, the committable time limit and delivery window are returned; when the range identifier meets the splitting conditions, sub-tickets are obtained and delivery fields and delivery windows are determined separately; the provider forms a delivery package; the demander initiates a delivery request within the validity period calculated from the time the delivery package is published; the platform verifies the request and delivers it; if the time limit is exceeded or the scope is crossed, the request is rejected and a new ticket is required; the demander sends back the signature information, and the platform updates the subsequent ticket scheduling parameters accordingly, lowering the priority of tickets without signatures and restricting delivery methods.

Description

Technical Field

[0001] This invention belongs to the field of data processing and information sharing technology, specifically relating to a port data sharing method based on intelligent scheduling. Background Technology

[0002] Based on existing technical documents, it can be seen that while current data sharing and scheduling methods used in port scenarios have made some progress in data security, access control, and permission management, they still have significant shortcomings and drawbacks in intelligent port scheduling applications that are characterized by high concurrency, high timeliness, and strong business coupling. Taking the data security access system based on a zero-trust architecture disclosed in CN115514523A as an example, its core technical idea focuses on achieving traceability of data sources, controllability of data users, and traceability of data dissemination through user digital identity identifiers and data identity identifiers. This strengthens the security and trustworthiness of data throughout its entire lifecycle from the system architecture level. This solution has positive significance in preventing data from being illegally accessed, tampered with, and abused. However, its focus is mainly on who can access the data and how the data is used securely, while lacking a targeted scheduling mechanism design for when, at what granularity, and under what business urgency the data is delivered. In port scheduling operations, scenarios such as ship berthing decisions and berth release assessments have extremely high timeliness requirements. If a uniform access control and encryption / decryption process is still used for complete data delivery, it often introduces additional processing and verification overhead, leading to data acquisition delays and impacting the real-time nature of scheduling decisions. Existing zero-trust solutions do not dynamically differentiate data delivery methods and schedules based on factors such as the impact level of business timeouts and differences in business urgency, easily resulting in a situation where security is prioritized but efficiency is insufficient under high load. Furthermore, such solutions lack a feedback mechanism driven by actual data usage after delivery. The system typically assumes that as long as the access request is legally authorized, the data will be used appropriately. However, in actual port operations, due to plan adjustments, unforeseen events, and other reasons, a large amount of data is delivered but not actually used for business decisions. Existing solutions do not adaptively adjust subsequent data delivery strategies based on confirmation or usage results, easily leading to data resource waste and the accumulation of ineffective deliveries. Looking at the government data access control method based on government consortium blockchain disclosed in CN115442045A, this solution achieves controllable permission granularity, dynamic and precise access control, and traceable access behavior through consortium blockchain structure and multi-chain layered design. It has obvious advantages in data ownership confirmation and auditing in cross-departmental and multi-entity collaborative scenarios. However, this type of solution is also mainly aimed at the compliance, security and accountability requirements of government data sharing. The overall design focuses on static permission configuration and attribute-driven access control model, and does not give sufficient consideration to the real-time differences of data requests and the differences in business priorities.In port intelligent scheduling scenarios, different data requests often have significantly different time windows and levels of business impact. For example, for data requests related to ship berthing, the berthing feasibility determination and the detailed operational status of the berth are not equivalent in terms of business value and urgency. However, existing government consortium blockchain solutions typically treat them as the same type of controlled data object, making it difficult to implement a hierarchical delivery strategy of first determining and then detailing at the access control level. In addition, while introducing blockchain consensus and on-chain records, consortium blockchain solutions inevitably increase system complexity and response latency. In high-frequency port scheduling scenarios, if every data access or status change requires on-chain confirmation or multi-node collaborative processing, it will further amplify system response latency, which is detrimental to ensuring the real-time and continuous nature of scheduling decisions. In summary, existing technical solutions generally suffer from an overemphasis on security control and a neglect of business scheduling. They lack intelligent scheduling mechanisms that integrate data access control with business timeliness, business impact, and feedback from actual usage behavior. This makes it difficult to dynamically adjust data delivery granularity, validity period, and access methods based on the port's operational status. This is particularly problematic in situations involving multiple concurrent documents, overlapping uses, and concentrated high-impact business transactions, easily leading to duplicate deliveries, invalid deliveries, and resource waste. Furthermore, most existing solutions lack closed-loop adjustment mechanisms for post-data usage behavior. They lack the ability to dynamically converge and constrain subsequent data delivery strategies based on confirmation results and invalid usage statistics, resulting in the system remaining in a passive authorization state for extended periods, unable to proactively guide data to be used according to plan, on demand, and on time. Summary of the Invention

[0003] The purpose of this invention is to provide a port data sharing method based on intelligent scheduling, thereby addressing some of the drawbacks and shortcomings pointed out in the background art.

[0004] The present invention addresses the aforementioned technical problems by employing the following technical solution: a port data sharing method based on intelligent scheduling, applicable to data demander systems, data provider systems, and data sharing platforms, comprising: the demander submitting a sharing ticket, the sharing ticket including a purpose identifier, timeliness requirements, scope identifier, and timeout impact identifier; the platform sending the ticket to the provider; The provider returns the commitment result according to the pruning rules: when the sharing policy corresponding to the purpose identifier is to allow only judgment or prohibit judgment, only the judgment result field is delivered; when the time requirement exceeds the committable range, the committable time and delivery window are returned; when the range identifier meets the splitting condition, sub-tickets are split and the delivery fields and delivery windows are determined respectively. The provider forms a delivery package, which includes fields, validity period, scope of application, and usage constraints. The requester initiates a delivery request within the validity period calculated from the time the delivery package is published. The platform verifies the delivery and delivers the package. If the delivery expires or exceeds the validity period, the platform rejects the request and requires the delivery of the invoice again. The requester sends back the signature information, and the platform updates the subsequent invoice scheduling parameters accordingly, lowers the priority of invoices without signatures, and restricts the delivery method.

[0005] Furthermore, the provider sets the delivery package to a judgment level and a detail level based on the timeout impact identifier of the shared ticket; the judgment level delivery package only contains the judgment result field and has a first validity period, and the detail level delivery package contains extended fields allowed by the usage constraint information and has a second validity period, and the second validity period does not exceed the first validity period; the platform selects the corresponding delivery package for delivery based on the level identifier in the delivery request, so that tickets with higher timeout impact receive priority for judgment level delivery.

[0006] Furthermore, the return signature information includes a delivery package identifier and a usage result identifier; the platform updates the scheduling parameters or delivery method of subsequent tickets corresponding to the usage identifier based on the return signature status, wherein when the number of return signatures within a preset statistical window is greater than or equal to a threshold, the delivery method of the subsequent tickets is set to a pre-return signature mode. In the pre-return signature mode, the data requester submits pre-return signature information containing a business action identifier before obtaining the data, and the platform only accepts the delivery request after receiving the pre-return signature information; and the platform shortens the time by a certain percentage. The validity period of the subsequent delivery package is shortened, and the shortening ratio is... Calculated by the following formula: in, This indicates the number of times there was no response within the preset statistics window. This indicates the total number of signatures within the preset statistics window. This represents the proportionality coefficient. Indicates the minimum shortening ratio. This represents the maximum shortening ratio, and satisfies... The validity period of the delivery package has been extended from the original validity period. Update the validity period as follows: : in, The validity period of the subsequent delivery package before it was shortened. This refers to the shortened validity period.

[0007] Furthermore, the judgment level delivery package includes a judgment result field, which is used to indicate whether judgment is allowed or prohibited; when the timeout impact indicator reaches the preset impact level, the platform first delivers the judgment level delivery package containing the judgment result field, and only accepts subsequent delivery requests for the detailed level delivery package when the judgment result is allowed.

[0008] Furthermore, for multiple shared tickets with the same purpose identifier and overlapping scope of application, the platform performs a merge scheduling, the timeout impact identifier of the merged ticket is taken as the highest impact level among the multiple shared tickets, and the first validity period is taken as the minimum value among the first validity period of the multiple shared tickets, and a determination level delivery package is generated and delivered.

[0009] Furthermore, the usage constraint information includes parameters for the number of allowed calls and the call interval; after delivering the judgment level delivery package, the data sharing platform limits the delivery frequency of the detail level delivery package according to the parameters; if the requester does not request the detail level delivery package within the first validity period, the release status of the detail level delivery package is revoked or its second validity period is adjusted to 0 to make it immediately invalid.

[0010] Furthermore, after generating the merged invoice, the platform establishes a request fingerprint set for the merged invoice. The request fingerprint consists of at least a purpose identifier, an applicable scope identifier, and a first validity period. When a delivery request carrying a matching request fingerprint set is received, the platform reuses the same decision level delivery package for delivery and only returns the identification information of the decision level delivery package for duplicate matching delivery requests.

[0011] Furthermore, the pre-signature information includes an expected usage time identifier and an expected usage scope identifier; the platform associates it with the delivery package identifier, and only accepts the delivery request when the request time of the delivery request falls within the expected usage time identifier and the requested object falls within the expected usage scope identifier.

[0012] Furthermore, the usage result identifier includes used and unused; when the usage result identifier is unused, the platform accumulates an invalid sharing count for the ticket corresponding to the delivery package identifier; when the count reaches a threshold within a preset statistical window, the platform performs field convergence on subsequent tickets corresponding to the purpose identifier, limiting delivery to only the judgment result field and prohibiting field expansion, until the count is lower than the threshold.

[0013] Furthermore, the invalid shared count is categorized by delivery package identifier and summarized by purpose identifier; before triggering field convergence, the platform first determines whether the number of delivery requests for subsequent tickets corresponding to the purpose identifier within a preset statistical window has reached a preset threshold. If it has not reached the threshold, field convergence is not performed, and the delivery frequency of the subsequent tickets is reduced or the delivery window is postponed.

[0014] The beneficial effects of this invention are as follows: The port data sharing method based on intelligent scheduling provided by this invention achieves refined management and dynamic scheduling of the entire data sharing process by introducing shared tickets, delivery packages, and return-signature mechanisms. On the one hand, data providers can trim, split, and deliver shared data in a hierarchical manner based on usage identifiers, timeliness requirements, scope identifiers, and timeout impact identifiers, effectively reducing unnecessary data exposure risks while ensuring business timeliness. On the other hand, the platform sets judgment level and detailed level delivery packages, combined with validity period and usage constraint information, so that high-timeliness and high-impact data needs can receive judgment results first, thereby improving response efficiency and decision reliability in port business collaboration.

[0015] Furthermore, this invention constructs an adaptive scheduling strategy based on usage behavior feedback through return signature information, no-return signature statistics, pre-return signature mode, and field convergence mechanism. The platform can dynamically adjust the delivery method, validity period, and delivery field range of subsequent tickets according to the actual usage of the demand side, constraining low-utilization or non-standard usage behaviors, and providing more stable data support for high-value, compliant usage needs. This improves the overall utilization efficiency of port data sharing while ensuring data security and compliance, reduces duplicate deliveries and resource waste, and enhances the intelligence level and sustainable operation capability of the data sharing platform. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the logical judgment process for port data sharing based on shared tickets in this invention.

[0017] Figure 2 This is a diagram illustrating the vertical relationship between the hierarchical delivery and adaptive control of the present invention.

[0018] Figure 3 This is a simplified logic diagram of the shared ticket merging and progressive scheduling control of the present invention.

[0019] Figure 4 This is a schematic diagram illustrating the graded delivery of delivery packages based on the judgment level and detail level of the timeout impact identifier in Embodiment 1 of the present invention.

[0020] Figure 5 This is a schematic diagram illustrating the triggering of the pre-signature mode based on the return signature information and the dynamic adjustment of the validity period of the delivery package in Embodiment 1 of the present invention.

[0021] Figure 6 This is a schematic diagram of the controlled delivery process based on decision priority and usage constraints at the detail level in Embodiment 1 of the present invention.

[0022] Figure 7 This is a schematic diagram illustrating the merging and scheduling of multiple shared tickets with the same purpose identification and overlapping applicable scope in Embodiment 2 of the present invention.

[0023] Figure 8 This is a schematic diagram of the decision-level delivery packet reuse response based on the request fingerprint set in Embodiment 2 of the present invention.

[0024] Figure 9 This is a schematic diagram of the field convergence hierarchical triggering mechanism based on pre-signature constraints and invalid shared counts in Embodiment 2 of the present invention. Detailed Implementation

[0025] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0026] Combined with appendix Figure 1 This invention relates to a port data sharing method based on intelligent scheduling, applicable to application scenarios involving collaboration among data requester systems, data provider systems, and a data sharing platform. The data requester system submits a sharing ticket through the data sharing platform to initiate a data sharing request based on its own business needs. The sharing ticket, as the core control carrier in the data sharing process, includes at least a purpose identifier, a timeliness requirement, a scope identifier, and a timeout impact identifier. The purpose identifier clarifies the specific business purpose corresponding to the data request, allowing for subsequent constraints on the content and usage of the data. The timeliness requirement characterizes the time sensitivity of the data request or the expected acquisition timeframe. The scope identifier limits the business object scope or spatial range of the required data. The timeout impact identifier indicates the degree of impact on the business if the data is not delivered within the expected timeframe. Upon receiving the sharing ticket, the data sharing platform verifies its completeness and compliance. After successful verification, the sharing ticket is sent to the corresponding data provider system, allowing the data provider to assess the feasible sharing method and delivery strategy based on the ticket content, thus providing a basis for subsequent data trimming, scheduling, and delivery.

[0027] After receiving a shared ticket forwarded by the data sharing platform, the data provider system parses and evaluates the ticket according to pre-configured pruning rules and returns the corresponding commitment results to the data sharing platform. Pruning rules constrain the field scope, delivery timeliness, and applicability of data sharing, ensuring that data delivery complies with data security and business management requirements. When the sharing policy corresponding to the purpose identifier in the shared ticket is limited to allowing only judgment or prohibiting judgment, the data provider does not directly deliver the original or detailed data, but only generates and returns the judgment result field to characterize business feasibility, thus avoiding unnecessary data exposure. When the timeliness requirement indicated in the shared ticket exceeds the scope that the data provider's current resources or capabilities can commit to, the data provider returns the committable timeliness information based on its own supported processing capabilities, and simultaneously provides the corresponding data delivery window to indicate that data delivery can be completed within the time frame. When the scope identifier in the shared ticket meets the preset splitting conditions, the data provider splits the shared ticket into multiple sub-tickets, and determines the deliverable data fields and corresponding delivery windows for each sub-ticket, thereby achieving fine-grained decomposition and scheduling of large-scale or complex data requests.

[0028] After evaluating the shared ticket and generating a commitment result, the data provider system forms a corresponding data delivery package based on the commitment result. The delivery package, as the control unit for actual data delivery, includes at least the deliverable data fields, validity period, scope of application, and usage constraints. The validity period limits the usability of the delivery package from the time of publication; the scope of application limits the business objects or spatial range within which the data can be requested and used; and the usage constraints constrain the number of times the data is called, the interval between calls, or the method of use. Upon receiving the delivery package, the data sharing platform publishes it, enabling data requesters to initiate delivery requests within the validity period calculated from the time the delivery package is published. Upon receiving a delivery request, the platform verifies whether the request is within the validity period and whether it complies with the scope of application and usage constraints. If the verification passes, the platform delivers the corresponding data content to the requester. If the delivery request exceeds the validity period or the scope of application, the platform rejects the delivery request and prompts the requester to resubmit the shared ticket. After completing their data usage, data requesters send back signed information to the data sharing platform to provide feedback on the usage of the delivery package. The data sharing platform updates the scheduling parameters of subsequent shared tickets related to that purpose based on the signed information, and downgrades the scheduling priority of shared tickets without signed information and restricts their delivery methods accordingly.

[0029] Combined with appendix Figure 2When generating delivery packages, the data provider system categorizes data delivery methods based on the timeout impact identifier carried in the shared ticket, thus dividing delivery packages into judgment-level delivery packages and detail-level delivery packages. Judgment-level delivery packages are used to meet data requests with high timeliness requirements or significant timeout impact. They contain only a judgment result field indicating whether the business is allowed to execute and are set to a first validity period to ensure the judgment result can be obtained and used within a short time. Detail-level delivery packages provide further detailed data content, provided the judgment result allows it. They contain extended fields permitted by usage constraints and are set to a second validity period, which does not exceed the first validity period, thus preventing detailed data from continuing to be used after the judgment result expires. When the data sharing platform receives a delivery request from a data requester, it determines the requested data level based on the level identifier carried in the delivery request and selects the corresponding delivery package accordingly. This ensures that shared tickets with high timeout impact receive priority for judgment-level delivery, thereby improving response efficiency for high-timeliness business scenarios while ensuring data security and compliance.

[0030] After acquiring and using data, data requesters are required to send back signed information to the data sharing platform. This signed information includes at least a delivery package identifier and a usage result identifier. The delivery package identifier uniquely indicates the delivered data package, while the usage result identifier indicates whether the data in the corresponding delivery package has been actually used. The data sharing platform aggregates and statistically analyzes the received signed information and dynamically updates the scheduling parameters or delivery methods of subsequent sharing tickets corresponding to the usage identifier based on the signed information status, thereby achieving adaptive scheduling control based on actual usage feedback. When the number of times no signed information is detected within a preset statistical window is greater than or equal to a preset threshold, the data sharing platform determines that the data requester corresponding to the current usage identifier has a high risk of non-feedback or low utilization, and adjusts the delivery method of subsequent sharing tickets to a pre-signed information mode. The pre-signed information mode requires data requesters to submit pre-signed information containing a business action identifier to the data sharing platform before acquiring data, explaining the intended data usage behavior. The data sharing platform only accepts the corresponding delivery request after successfully receiving the pre-signed information, thus introducing usage intent verification before actual data delivery and reducing the possibility of data misuse or idleness.

[0031] Building upon the above, the data sharing platform also dynamically compresses the validity period of subsequent delivery packages based on the sign-off behavior, further constraining the usable lifespan of the data. Specifically, the platform shortens the validity period by a certain percentage. The validity period of subsequent delivery packages will be adjusted, with a reduction in the proportion. Determined by the following formula: in, This indicates the number of no-return signatures counted within the preset statistics window. This indicates the total number of signatures received within the preset statistics window. This is a proportionality coefficient used to adjust the degree to which the lack of a response affects the shortening ratio. This indicates the minimum allowed shortening percentage. This indicates the maximum allowed shortening ratio, and it must satisfy the following conditions: Determining the shortening ratio Subsequently, the data sharing platform updates the validity period of the delivery package in the following manner: in, Indicates the validity period before the subsequent delivery package is shortened. This indicates the shortened validity period. The data sharing platform can dynamically adjust the validity period of data delivery based on the data requester's response, ensuring that untimely or non-standard responses directly reflect in subsequent data sharing conditions.

[0032] The decision-level delivery package, as the first layer of data tiered delivery, includes a decision result field. This field clearly indicates whether the corresponding data request is allowed or prohibited under the current conditions, providing a decision-making basis for subsequent data acquisition and business processing. When the timeout impact indicator carried in the shared ticket reaches the preset impact level, the data sharing platform prioritizes the timeliness of business decisions. Without directly delivering detailed data, it first delivers a decision-level delivery package containing the decision result field to the data requester, enabling them to quickly ascertain whether the business is executable. The data sharing platform only accepts subsequent delivery requests from the data requester for the detailed-level delivery package if the decision result field indicates that the decision is allowed, thus avoiding premature or ineffective delivery of detailed data when the business is unexecutable or lacks the necessary conditions.

[0033] Usage constraints are used to fine-tune the subsequent use of data. They include at least a allowed number of calls parameter and a call interval parameter. The allowed number of calls parameter limits the maximum number of times detailed-level data can be requested or called within a predetermined period, while the call interval parameter limits the minimum time interval between two consecutive detailed-level data requests. After delivering the judgment-level delivery package, the data sharing platform controls the delivery behavior of the detailed-level delivery package based on the usage constraints. When a data requester initiates a detailed-level delivery request, the platform determines whether the request meets the limits of the allowed number of calls parameter and the call interval parameter, and only delivers the package if the limits are met, thus preventing high-frequency calls or abnormal usage. If the data requester does not initiate a delivery request for the detailed-level delivery package within the first validity period, the data sharing platform considers that the detailed-level delivery package no longer necessary for delivery and accordingly cancels its publication status or adjusts its second validity period to zero to make it immediately invalid, thereby preventing expired or idle detailed data from remaining in a deliverable state.

[0034] Combined with appendix Figure 3 When the data sharing platform receives multiple shared tickets within a preset time frame, and these tickets share the same purpose identifier and have overlapping applicable scopes, the platform does not schedule each ticket independently. Instead, it performs a merged scheduling process. Through merged scheduling, the platform integrates multiple shared tickets into a single merged ticket, reducing resource consumption caused by redundant scheduling and delivery. When forming the merged ticket, the platform compares the timeout impact identifiers of the multiple shared tickets, selecting the one with the highest impact level as the timeout impact identifier for the merged ticket. This ensures that the scheduling strategy covers the most stringent business impact requirements. Simultaneously, the platform compares the first validity period of the multiple shared tickets, selecting the smallest first validity period as the first validity period of the merged ticket. This guarantees that the validity period of the merged ticket does not exceed the validity period allowed by any of the original tickets. Based on the merged ticket, the platform generates and delivers a corresponding judgment level delivery package, enabling data requesters to obtain a unified judgment result while meeting the strictest timeliness and impact constraints. This improves the overall efficiency of port data sharing scheduling and reduces system load.

[0035] After generating a consolidated document, the data sharing platform establishes a corresponding request fingerprint set for that document to identify and recognize data delivery requests related to it. Each request fingerprint consists of at least a purpose identifier, an applicable scope identifier, and a first validity period, characterizing the key features of the delivery request in terms of business purpose, data applicable scope, and timeliness constraints. When the data sharing platform receives a delivery request from a data requester, it extracts the corresponding purpose identifier, applicable scope identifier, and validity period parameter from the request and matches them against the established request fingerprint set. When a fingerprint in the delivery request matches any fingerprint in the request fingerprint set, the platform does not regenerate a new delivery package but directly reuses the already generated delivery package of the same decision level, thus avoiding redundant calculations and data processing. For delivery requests that correspond to duplicate matching fingerprints, the platform only returns the identifier of the decision level delivery package to the data requester, enabling them to obtain the existing decision result based on this identifier.

[0036] When the data sharing platform adopts a pre-signature model for delivery control of subsequent shared documents, the data requester must submit pre-signature information to the data sharing platform before initiating a data delivery request. The pre-signature information includes at least an expected usage time identifier and an expected usage scope identifier. The expected usage time identifier represents the time interval during which the data plan will actually be used, and the expected usage scope identifier represents the scope of business objects or spatial range within which the data plan will be used. Upon receiving the pre-signature information, the data sharing platform associates it with the corresponding delivery package identifier and uses it as an important basis for subsequent delivery verification. When the data requester initiates a delivery request, the data sharing platform first compares the request time with the expected usage time identifier and matches the requested object with the expected usage scope identifier. The delivery request is only accepted if the request time falls within the time range defined by the expected usage time identifier and the object corresponding to the delivery request falls within the range defined by the expected usage scope identifier, thus ensuring that the data delivery behavior is consistent with the pre-declared usage plan.

[0037] After acquiring the data, the data requester provides feedback on the usage results of the corresponding delivery package to the data sharing platform via a confirmation message. The usage result identifier includes at least two states: used and unused, indicating whether the delivered data has been actually used in business operations. The data sharing platform statistically analyzes the usage of delivery packages based on the usage result identifier. When a delivery package is detected as unused, the platform increments the invalid sharing count on the shared ticket corresponding to that identifier, reflecting instances where data delivery has not been actually utilized. The data sharing platform continuously monitors the invalid sharing count within a preset statistical window. When the invalid sharing count reaches a preset threshold, the platform determines that the data sharing behavior related to that usage identifier carries a risk of low utilization efficiency and implements field convergence control on subsequent shared tickets corresponding to that usage identifier. This means that subsequent deliveries are limited to only the judgment result field and the delivery of extended fields is prohibited until the invalid sharing count decreases below the threshold within the statistical window. This reduces the scope of detailed data delivery to suppress invalid or low-value data sharing behavior.

[0038] Furthermore, invalid sharing counts are statistically analyzed item by item according to delivery package identifiers and summarized at the usage identifier level to evaluate data usage effectiveness from both individual delivery package and overall usage perspectives. Before triggering field convergence, the data sharing platform also judges the number of delivery requests for subsequent shared tickets corresponding to the usage identifier within a preset statistical window. When the number of delivery requests does not reach the preset threshold, the platform considers that the current invalid sharing situation is not sufficient to directly limit the data field range, and therefore does not perform field convergence processing. Instead, it performs flexible control by reducing the delivery frequency of subsequent shared tickets or delaying the corresponding delivery window. Through the above-mentioned hierarchical judgment and gradual scheduling control mechanism, this invention effectively avoids excessive restrictions on data sharing strategies due to short-term fluctuations or a few abnormal behaviors while ensuring normal business continuity.

[0039] Example 1: This embodiment uses a data sharing platform of a large coastal container port as an application scenario. The port dispatch center acts as the data requester system, and the terminal production management system acts as the data provider system. Both systems interact through a unified data sharing platform. The port dispatch center needs to obtain information on whether a berth is ready for berthing within the next hour to schedule incoming vessels. This process is highly time-sensitive; delays directly impact vessel queuing and the overall port operational efficiency. Therefore, when submitting a data sharing request, the port dispatch center sets the purpose identifier to vessel berthing decision, the time requirement to feedback within ten minutes, the scope identifier to the target berth number, and the delay impact identifier to a high-impact level. Upon receiving the data sharing request, the data sharing platform forwards it to the terminal production management system for processing.

[0040] After identifying that the timeout impact flag corresponding to the shared ticket belongs to the high-impact level, the port production management system generates a corresponding data delivery package for the shared ticket according to the preset hierarchical delivery rules, and divides the delivery package into a judgment-level delivery package and a detail-level delivery package. For example... Figure 4 As shown in the upper center, the decision-level delivery package only contains a decision result field, which directly indicates whether the target berth is permitted to berth within a specified time window, such as returning a result of "berthing permitted" or "berthing prohibited." To ensure the timeliness of the decision result, this decision-level delivery package is set to an initial validity period of ten minutes, starting from the time the delivery package is published. Figure 4 During the implementation process shown, the corresponding release time is 10:00:00 and the expiration time is 10:10:00.

[0041] At the same time, such as Figure 4 As shown in the lower center, the terminal production management system also generates detailed-level delivery packages. These packages provide more detailed business data, provided the berthing result indicates berthing is permitted. These detailed-level delivery packages include extended fields permitted by usage constraints, such as the current operational status of the berth, the estimated release time, and the occupancy status of related equipment. To prevent detailed data from being requested and used after the judgment result expires, these detailed-level delivery packages have a second validity period of five minutes, calculated from the time of publication and expiring at 10:05:00, and this second validity period does not exceed the first validity period. Both types of delivery packages are published together to the data sharing platform for unified management.

[0042] When the port dispatch center initiates a delivery request, it explicitly includes a level identifier as the judgment level in the request. The data sharing platform then prioritizes delivery packages based on this judgment level. Figure 4 During the implementation process shown, the judgment result field is returned within 3 minutes of the request being initiated, i.e., the judgment result is delivered at 10:03:00. Based on this judgment result, the port dispatch center quickly makes a vessel berthing decision, thus ensuring the continuity of high-efficiency operations. If, even if the port dispatch center determines that berthing is permitted, it needs further detailed operational information about the berth to optimize operational arrangements, it can initiate a delivery request with a level identifier of "detailed" within the first validity period. The data sharing platform will only deliver the corresponding detailed-level delivery package after verification. Figure 4 As can be seen from the time sequence shown, the tiered delivery and different validity periods can ensure timely decision-making while avoiding unnecessary premature or expired exposure of detailed data.

[0043] In the subsequent process, after obtaining the judgment-level delivery package and confirming that the judgment result allowed berthing, the port dispatch center further requested a detailed-level delivery package within the first validity period to optimize berth operation arrangements. After completing the delivery of this detailed-level delivery package, the data sharing platform generates a unique delivery package identifier and requires the port dispatch center to return a confirmation message after the data has been actually used. The confirmation message includes the delivery package identifier and a usage result identifier, used to indicate whether the data corresponding to the delivery package has been actually used for business decision-making.

[0044] In this embodiment, due to temporary channel control adjustments, the port dispatch center was unable to use some of the delivered detailed data as originally planned. Therefore, the usage result of the corresponding delivery package was marked as unused in the return signature information. The data sharing platform uses the purpose identifier as the statistical dimension for ship berthing decisions and summarizes and analyzes the return signature information within a preset statistical window. This statistical window is set to the most recent 7 days. Within this window, the platform recorded 20 delivery behaviors related to this purpose identifier, of which 12 were successfully returned with signatures and marked as used, and 8 were either not returned with signatures or marked as unused. The number of times no signatures were returned is recorded as follows: The total number of times the signature is returned is recorded as follows: The platform pre-sets a threshold of 8 for the number of no-return signatures. When the number of no-return signatures within the statistics window is greater than or equal to this threshold, the scheduling strategy adjustment condition is triggered. (This is because in this embodiment...) Based on this, the data sharing platform determined that the data usage corresponding to this purpose identifier was unstable, and therefore adjusted the delivery method of subsequent shared tickets to the pre-signature mode.

[0045] Under the pre-signature model, before requesting vessel berthing-related data again, the port dispatch center needs to submit pre-signature information to the data sharing platform, specifying the proposed business action. For example, before submitting a new shared ticket, the port dispatch center needs to submit pre-signature information including the business action identifier of the next vessel's berthing schedule. The data sharing platform only processes the corresponding delivery request after successfully receiving this pre-signature information, thus introducing usage intent constraints before actual data delivery and preventing situations where data is delivered but not used.

[0046] At the same time, such as Figure 5 As shown, the data sharing platform also dynamically compresses the validity period of subsequent delivery packages based on the lack of confirmation. The platform pre-configures a proportional coefficient. Minimum shortening ratio Maximum shortening ratio Based on the statistical results, substitute the above parameters into the formula for calculating the shortening ratio: First, calculate the intermediate term: Compare the results with the minimum shortening ratio: Then compare it with the maximum shortening ratio: Therefore, in this embodiment, the shortening ratio is determined to be: The validity period of the original subsequent delivery package is set to be If it takes minutes, the formula is updated according to the validity period: The shortened validity period can be obtained as follows: minute That is approximately 6.9 minutes. Based on this, the data sharing platform dynamically reduces the validity period of subsequent judgment level or detailed level delivery packages from the original 10 minutes to approximately 7 minutes, forcing the port dispatch center to complete data requests and usage in a shorter time, thereby compelling it to initiate data acquisition only after confirming business needs.

[0047] During the aforementioned implementation process, the port dispatch center was adjusted to a pre-signature mode by the data sharing platform due to the existence of unused data. The platform also dynamically compressed the validity period of subsequent delivery packages. Based on this, the port dispatch center submitted a new shared ticket to handle the berthing arrangement of a container ship scheduled to arrive at the port at 14:30 that day. Since the ship's late arrival would directly affect the loading and unloading schedules of the subsequent three shipping routes, the data sharing platform, based on the timeout impact flag in the shared ticket, determined that this transaction belonged to a pre-defined high-impact scenario, thus triggering a priority-based tiered delivery mechanism.

[0048] In this scenario, the data provider only generates and delivers a decision-level delivery package. This package contains a decision result field, which explicitly indicates whether the target berth is permitted to berth within a specified time window. The decision result field is set to return a "permitted" result, which the port dispatch center uses to confirm that the vessel meets berthing requirements and decides whether to obtain further detailed data within the first validity period. After delivering the decision-level delivery package, the data sharing platform does not immediately open the detailed-level delivery package; instead, it waits for the port dispatch center to initiate a clear follow-up request based on the decision result, thus avoiding premature delivery of detailed data before the business is confirmed to be executable.

[0049] Provided the judgment result is valid, the port dispatch center initiates a detailed-level delivery request within 3 minutes of delivery. Before accepting the request, the data sharing platform verifies the detailed-level delivery behavior based on the usage constraint information carried in the delivery package. If the allowed number of calls in the usage constraint information is set to 3 and the call interval parameter is set to 2 minutes, then after recording the first detailed-level delivery, the platform will only allow subsequent detailed-level delivery requests to be accepted if there is a minimum interval of 2 minutes, and will automatically reject new detailed-level requests after the cumulative number of deliveries reaches 3. Figure 6 As shown, under the first validity period of 7 minutes, only requests that meet the constraints of call interval and call count are successfully delivered, and the rest are rejected.

[0050] Meanwhile, if the port dispatch center does not initiate any detailed-level delivery request for the obtained judgment-level delivery package within the first validity period (e.g., the first validity period is set to 7 minutes, and the port dispatch center only completes business decisions based on the judgment results within this time frame without further requesting detailed data), the data sharing platform will automatically revoke the release status of the corresponding detailed-level delivery package after the first validity period expires, or adjust its second validity period to 0, making the detailed-level delivery package immediately invalid. This ensures that detailed data is only requested and used when there is a genuine business need and within a limited time, avoiding invalid data remaining in a deliverable state for a long time.

[0051] Example 2: Based on Example 1, as the concurrency of port operations increases, the port dispatch center often initiates multiple data requests from different business modules or different dispatch subsystems for the same business purpose within the same time period, resulting in multiple shared tickets with the same purpose identifier and overlapping applicable scopes. For example... Figure 7 As shown in the figure, this diagram visually illustrates a typical scenario where multiple shared tickets exist in parallel within the same scheduling period and their validity windows overlap, presented in a timeline format.

[0052] In this embodiment, the port dispatch center submitted three shared tickets within the same dispatch cycle. All three tickets were identified as vessels berthing decisions and covered the same berth number (e.g., berth B12), but originated from different dispatch subtasks. Specifically, the first shared ticket had a high-impact timeout rating and a first validity period of 10 minutes; the second shared ticket had a medium-impact timeout rating and a first validity period of 12 minutes; and the third shared ticket had a high-impact timeout rating and a first validity period of 8 minutes. Figure 7The start time and validity period of the three shared tickets are marked with three parallel time bars, and it can be seen that there is a clear overlap in the time windows of the three.

[0053] After receiving the three shared tickets, the data sharing platform performs a matching analysis of their purpose identifiers and applicable scopes, identifying that the three shared tickets meet the conditions of having the same purpose identifier and overlapping applicable scopes. Based on this, the platform no longer schedules the three shared tickets independently but triggers a merge scheduling mechanism for unified processing. During the merge scheduling process, the platform first compares the timeout impact identifiers of the three shared tickets, selecting them in descending order of impact level, and taking the highest impact level as the timeout impact identifier for the merged ticket. Since the first and third shared tickets are both of high impact level, the timeout impact identifier for the merged ticket is determined to be of high impact level, such as... Figure 7 The annotations corresponding to the merged bills are shown to ensure that subsequent scheduling strategies can meet the most stringent timeliness requirements.

[0054] Meanwhile, the platform compared the first validity periods of the three shared tickets, which were 10 minutes, 12 minutes, and 8 minutes, respectively, and determined the first validity period of the merged ticket to be 8 minutes based on the principle of taking the minimum value. Figure 7 The time stripe length of the merged ticket corresponds to the 8-minute validity period. This result indicates that the merged scheduling result will not exceed the strictest time limit allowed by any original shared ticket, thus avoiding the unreasonable amplification of the validity period due to merged scheduling.

[0055] After determining the parameters of the merged ticket, the data sharing platform generates a decision-level delivery package based on the merged ticket, delivering only the decision result field, which indicates whether the target berth is permitted to berth within the current time window. This decision-level delivery package uniformly corresponds to the business requirements of the original three shared tickets and is released externally within the first validity period of 8 minutes. Regardless of which scheduling subsystem the port dispatch center initiates the decision-level delivery request from within this validity period, the data sharing platform reuses the same decision-level delivery package for response, thereby avoiding redundant calculations, redundant deliveries, and resource waste. This reuse effect is evident in… Figure 7 This is clearly reflected in the consolidated invoice identifier.

[0056] After merging and scheduling multiple shared tickets with the same purpose and overlapping scope of application, the data sharing platform needs to effectively identify and deduplicate subsequent delivery requests from different business modules or different scheduling subsystems to avoid duplicate delivery or invalid responses in the merged scheduling scenario. Figure 8 The process of request identification and reuse is illustrated using a timeline and request event markers.

[0057] In this embodiment, after generating a merged invoice, the data sharing platform establishes a corresponding request fingerprint set for that invoice. Each request fingerprint consists of at least three key elements: a purpose identifier, an applicable scope identifier, and a first validity period. The purpose identifier uniquely represents the business objective, such as a ship berthing decision; the applicable scope identifier limits the scope of the business, such as berth number B12; and the first validity period limits the time limit of the judgment result, such as 8 minutes. The platform combines these elements to generate a unique request fingerprint and adds it to the request fingerprint set as a basis for rapid matching of subsequent delivery requests. Figure 8 The fingerprint of the request is centrally annotated above the timeline.

[0058] During the scheduling period following the effective date of the consolidated bill, different scheduling subsystems of the port scheduling center initiated multiple determination-level delivery requests. For example, the berth scheduling module initiated a determination-level delivery request in the first minute after the consolidated bill was issued, and the schedule coordination module initiated another determination-level delivery request in the second minute after the consolidated bill was issued. Although the two requests originated from different modules, their purpose identifier was the same: vessel berthing decision; their applicable scope identifier was the same: berth B12; and the requests occurred within the first 8-minute period of the consolidated bill's validity. Figure 8 The system uses different shaped request markers to distinguish between the first request and subsequent repeated requests.

[0059] Upon receiving the aforementioned delivery request, the data sharing platform parses the purpose identifier, scope of application identifier, and validity period parameter carried in the request and matches them against the established request fingerprint set, determining that both requests completely match the same request fingerprint. If a match is successful, the data sharing platform does not regenerate a new decision-level delivery package but directly reuses the previously generated decision-level delivery package for delivery processing. For the first delivery request matching the request fingerprint, the platform returns a complete decision-level delivery package to the port dispatch center, including the decision result field and its corresponding validity period information. For subsequent duplicate matching delivery requests, the platform does not repeatedly return the complete data content but only returns the identifier information of the decision-level delivery package, such as... Figure 8 The corresponding identifier for subsequent requests is shown in the image.

[0060] Through the above processing method, different scheduling subsystems of the port dispatch center avoid duplicate data delivery and redundant computational overhead while sharing the same judgment result, and also reduce the number of times data is transmitted in the network. Within the first validity period of 8 minutes, as long as the delivery request is consistent with the fingerprint in the request fingerprint set, the data sharing platform can complete the response by reusing the judgment-level delivery packet, thereby achieving rapid judgment response in high-concurrency scenarios. Figure 8 The high-concurrency reuse effect was visually verified.

[0061] Because the port dispatch center has delivered detailed data multiple times in previous dispatch cycles without actually using it, the data sharing platform has enabled the pre-signature mode for subsequent shared tickets corresponding to the purpose identifier. Figure 9 The pre-signature constraint verification and field convergence trigger path are comprehensively illustrated by displaying time windows, request events and statistical judgment results side by side.

[0062] In this embodiment, before requesting data related to vessel berthing decisions again, the port dispatch center needs to submit pre-signature information to the data sharing platform. The pre-signature information includes at least an expected usage time identifier and an expected usage scope identifier. The expected usage time identifier indicates the time interval during which the data is planned to be used, such as between 14:30 and 14:45. The expected usage scope identifier indicates the scope of the business object corresponding to the data, such as berth number B12. After receiving the pre-signature information, the data sharing platform associates and stores it with the corresponding decision level delivery package identifier, and then... Figure 9 The expected usage time window is identified by a continuous time strip.

[0063] During the period when the pre-recognition information was in effect, the port dispatch center initiated a determination level delivery request at 14:32, with the requested object still being berth B12. The data sharing platform verified the request time and the requested object of the delivery request, confirming that the request time fell within the time interval defined by the expected usage time identifier, and that the requested object fell within the scope defined by the expected usage scope identifier. Therefore, the delivery request was accepted and the corresponding determination level delivery package was returned. Figure 9 The request was marked on the acceptance level within the pre-return time band, which intuitively reflects the result of meeting the dual constraints.

[0064] If the port dispatch center initiates a delivery request at 14:50, even though the requested target is still berth B12, the data sharing platform will reject it because the request time exceeds the expected usage time window, thus failing to meet the time constraint conditions. Similarly, if the delivery request is initiated at 14:35, but the requested target is another berth number, such as C03, then although the request time meets the requirements, it will also be rejected by the platform because the requested target is outside the expected usage range. These two types of rejection scenarios are... Figure 9 The reasons for time out of bounds and range out of bounds are distinguished by text labels, which are located at different rejection levels.

[0065] After the data is actually delivered and the business processing is completed, the port dispatch center still needs to send back the confirmation information as required by the platform. The usage result identifier is used to indicate whether the delivered data has been actually used. In this embodiment, the port dispatch center sends back a usage result identifier of an outgoing delivery package at a specific judgment level as "unused." Upon receiving this confirmation information, the data sharing platform increments the invalid sharing count by one for the shared document corresponding to that delivery package identifier, continuously counts the invalid sharing count within a preset statistical window, records it by delivery package identifier, and summarizes and analyzes it at the usage identifier level.

[0066] Within the statistical window of the most recent 7 days, the delivery package corresponding to the determination level of the ship berthing decision purpose identifier has a total of 4 invalid sharing counts. The invalid sharing threshold configured by the platform for this purpose identifier is 4. When this threshold is reached, the data sharing platform triggers the field convergence determination process to determine whether to enter the field convergence execution stage. Figure 9 The statistical information box on the right displays the above statistical results. Before performing field convergence, the platform first determines whether the number of delivery requests for this purpose identifier within the same statistical window has reached a preset threshold, for example, a preset threshold of 10 times. If the statistical results show that the number of delivery requests corresponding to this purpose identifier is only 6 times within 7 days, which has not yet reached the preset threshold, the platform considers that the current invalid sharing behavior is not sufficient to directly limit the range of data fields, and therefore does not immediately perform field convergence.

[0067] In the aforementioned circumstances, the data sharing platform adopts a gradual control strategy, reducing the delivery frequency or delaying the delivery window for subsequent shared tickets corresponding to the purpose identifier. For example, it may delay the acceptance of delivery requests that could have been accepted immediately by 2 minutes, or limit the number of delivery requests that can be accepted per unit time. If, within the subsequent statistical window, the number of delivery requests corresponding to the purpose identifier reaches or exceeds a preset threshold, and the invalid sharing count remains above the threshold, the data sharing platform will converge the formal execution field of subsequent shared tickets, limiting the delivery to only the judgment result field and prohibiting the delivery of extended fields, until the invalid sharing count drops below the threshold within the statistical window.

[0068] pass Figure 9The pre-signature constraint verification path, statistical judgment logic, and control results shown demonstrate that, based on merged scheduling and request fingerprint reuse, this invention further refines data usage behavior through pre-signature information constraints, invalid sharing count statistics, and a hierarchical triggering mechanism for field convergence. This mechanism can guide data usage according to plan in the early stages through time and scope constraints, and gradually tighten delivery strategies when invalid sharing behavior continues to occur. This effectively suppresses unnecessary detailed data diffusion while ensuring the continuity of core port scheduling judgment business, demonstrating the practicality and scalability of this invention in high-concurrency port scheduling scenarios.

[0069] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A port data sharing method based on intelligent scheduling, applicable to data demand-side systems, data provider systems, and data sharing platforms, characterized in that... include: The requesting party submits a shared ticket, which includes a purpose identifier, time limit requirement, scope identifier, and impact of timeout identifier; The platform sends the invoice to the provider. The provider returns the commitment result according to the pruning rules: when the sharing policy corresponding to the purpose identifier is to allow only judgment or prohibit judgment, only the judgment result field is delivered; when the time requirement exceeds the committable range, the committable time and delivery window are returned; when the range identifier meets the splitting condition, sub-tickets are split and the delivery fields and delivery windows are determined respectively. The provider forms a delivery package, which includes fields, validity period, scope of application, and usage constraints. The requester initiates a delivery request within the validity period calculated from the time the delivery package is published. The platform verifies the delivery and delivers the package. If the delivery expires or exceeds the validity period, the platform rejects the request and requires the delivery of the invoice again. The requester sends back the signature information, and the platform updates the subsequent invoice scheduling parameters accordingly, lowers the priority of invoices without signatures, and restricts the delivery method.

2. The port data sharing method based on intelligent scheduling according to claim 1, characterized in that... The provider sets the delivery package to a judgment level and a detail level based on the timeout impact identifier of the shared ticket. The judgment level delivery package only contains the judgment result field and has a first validity period. The detail level delivery package contains extended fields allowed by the usage constraint information and has a second validity period, and the second validity period does not exceed the first validity period. The platform selects the corresponding delivery package for delivery based on the level identifier in the delivery request, so that tickets with higher timeout impact are given priority for judgment level delivery.

3. The port data sharing method based on intelligent scheduling according to claim 1, characterized in that... The return signature information includes a delivery package identifier and a usage result identifier. The platform updates the scheduling parameters or delivery method of subsequent tickets corresponding to the usage identifier based on the return signature status. When the number of return signatures within the preset statistical window is greater than or equal to the threshold, the delivery method of subsequent tickets is set to pre-return signature mode. In pre-return signature mode, the data requester submits pre-return signature information containing business action identifiers before obtaining data. The platform only accepts delivery requests after receiving pre-return signature information and shortens the validity period of subsequent delivery packages by a preset ratio.

4. The port data sharing method based on intelligent scheduling according to claim 2, characterized in that... The judgment level delivery package includes a judgment result field, which is used to indicate whether judgment is allowed or prohibited. When the timeout impact indicator reaches the preset impact level, the platform first delivers the judgment level delivery package containing the judgment result field, and only accepts subsequent delivery requests for the detailed level delivery package when the judgment result is allowed.

5. The port data sharing method based on intelligent scheduling according to claim 2, characterized in that... For multiple shared tickets with the same purpose and overlapping scope of application, the platform performs a merge scheduling. The timeout impact identifier of the merged ticket is taken as the highest impact level among the multiple shared tickets, and the first validity period is taken as the minimum value among the first validity period of the multiple shared tickets. A judgment level delivery package is generated and delivered.

6. The port data sharing method based on intelligent scheduling according to claim 2, characterized in that... The usage constraint information includes parameters for the number of allowed calls and the call interval; after delivering the judgment level delivery package, the data sharing platform limits the delivery frequency of the detail level delivery package according to the parameters; if the requester does not request the detail level delivery package within the first validity period, the release status of the detail level delivery package is revoked or its second validity period is adjusted to 0 to make it immediately invalid.

7. The port data sharing method based on intelligent scheduling according to claim 5, characterized in that... After generating the merged invoice, the platform establishes a request fingerprint set for the merged invoice. The request fingerprint consists of at least a purpose identifier, an applicable scope identifier, and a first validity period. When a delivery request matching the request fingerprint set is received, the platform reuses the same decision level delivery package for delivery and returns only the identification information of the decision level delivery package for duplicate matching delivery requests.

8. The port data sharing method based on intelligent scheduling according to claim 3, characterized in that... The pre-signature information includes an expected usage time identifier and an expected usage scope identifier; the platform associates it with the delivery package identifier and only accepts the delivery request when the request time of the delivery request falls within the expected usage time identifier and the requested object falls within the expected usage scope identifier.

9. The port data sharing method based on intelligent scheduling according to claim 3, characterized in that... The usage result identifier includes used and unused; when the usage result identifier is unused, the platform accumulates an invalid sharing count for the ticket corresponding to the delivery package identifier; when the count reaches a threshold within a preset statistical window, the platform performs field convergence on subsequent tickets corresponding to the usage identifier, limiting only the delivery judgment result field and prohibiting field expansion, until the count is lower than the threshold.

10. The port data sharing method based on intelligent scheduling according to claim 9, characterized in that... The invalid shared count is categorized by delivery package identifier and summarized by purpose identifier; before triggering field convergence, the platform first determines whether the number of delivery requests for subsequent tickets corresponding to the purpose identifier within the preset statistical window has reached the preset number threshold. If it has not reached the threshold, field convergence is not performed, and the delivery frequency of the subsequent tickets is reduced or the delivery window is postponed.

Images