Incremental knowledge operation and management methods for big data in ship design knowledge

Abstract

This invention relates to the field of ship design knowledge management technology, and discloses an incremental knowledge operation and management method for ship design knowledge big data. The method first acquires initial knowledge data from a ship design knowledge base and assigns incremental tags; then, it acquires metadata records, classifies and processes them, and stores them hierarchically; it sets update tags for operation terminals and associates them with incremental tags, synchronizes knowledge data, and matches update cycles according to time information; it compares the knowledge status of operation terminals with the update cycle and generates update prompts; it obtains usage frequency to calculate a knowledge activity index, combines it with operator identification, and transmits it to the management backend terminal; after verifying updated knowledge, it adjusts knowledge priorities. This method achieves orderly storage, timely updates, and rational utilization of knowledge data, improves retrieval efficiency, ensures knowledge timeliness, optimizes knowledge management, and enhances the overall level of ship design.

Description

Technical Field

[0001] This invention relates to the field of ship design knowledge management technology, specifically to an incremental knowledge operation and management method for ship design knowledge big data. Background Technology

[0002] In the field of ship design, with the rapid development of the shipbuilding industry and the deep application of digital and intelligent technologies, the knowledge data generated during the ship design process is experiencing explosive growth. This knowledge data covers a wealth of content, including design specifications, parameter standards, and case experience. It is not only an important foundation for ship design innovation but also a key resource for improving the quality and efficiency of ship design. However, traditional ship design knowledge management methods face many serious challenges.

[0003] From the perspective of knowledge data storage, traditional methods often lack systematicity and structure. Because ship design knowledge data comes from a wide range of sources and is diverse in type, the mixed storage of knowledge data from different formats and fields leads to extremely low data retrieval efficiency. Designers often need to spend a significant amount of time sifting through massive amounts of data when searching for specific design specifications or case studies, which greatly affects the speed of design work. Furthermore, the lack of effective classification and hierarchical storage makes it difficult to demonstrate the relationships between knowledge data, preventing the formation of a complete knowledge system and reducing the reusability of knowledge.

[0004] In terms of knowledge data update and management, traditional methods exhibit significant lag. The ship design industry is rapidly evolving technologically, with design codes and standards constantly being updated, and new design concepts and methods emerging continuously. However, traditional knowledge updating methods typically rely on periodic manual checks and updates, which are not only inefficient but also prone to oversights. Some crucial knowledge data may fail to be updated in a timely manner due to human negligence, leading designers to use outdated knowledge in their work, thus causing design errors and increasing design risks and costs.

[0005] Furthermore, traditional management methods lack scientific and effective means for assessing the usage and importance of knowledge data. Without accurately understanding the frequency of knowledge data use, its application scenarios, and its actual value to design work, it is difficult to rationally prioritize and allocate resources. Some critical, high-value knowledge data may not receive the attention and utilization it deserves, while low-value or outdated knowledge data occupies storage resources, resulting in waste.

[0006] With the continuous expansion and increasing complexity of ship design projects, traditional knowledge management methods can no longer meet the demands of modern ship design for efficient management and utilization of knowledge data. Therefore, there is an urgent need for a scientific and efficient method to manage large amounts of ship design knowledge data, enabling the orderly storage, timely updating, and rational utilization of this data, thereby enhancing the overall level and competitiveness of ship design. Summary of the Invention

[0007] The purpose of this invention is to provide an incremental knowledge operation and management method for big data of ship design knowledge, so as to solve the problems mentioned in the background art.

[0008] To achieve the above objectives, this invention provides an incremental knowledge operation and management method for ship design knowledge big data, the method comprising:

[0009] Step A: Obtain initial knowledge data from the ship design knowledge base and set incremental tags for the initial knowledge data;

[0010] Step B: Obtain the metadata records of the knowledge data, classify the metadata records to obtain structured data, extract the feature identifiers of the structured data, divide the knowledge into categories according to the feature identifiers, and store the knowledge data in layers according to the knowledge categories.

[0011] Step C: Set the update tag for the operation terminal. The update tag and the incremental tag are associated through a data interface. The hierarchically stored knowledge data is synchronized to the operation terminal to obtain time information and match the update cycle according to the time information.

[0012] Step D: Obtain the knowledge status of the operating terminal, compare the knowledge status with the update cycle, obtain a first comparison conclusion, and generate an update prompt instruction based on the first comparison conclusion;

[0013] Step E: Obtain the usage frequency and operator identification of the operation terminal, calculate the knowledge activity index based on the usage frequency, transmit the knowledge activity index and operator identification to the management backend terminal, verify the updated knowledge according to a preset ratio, obtain verification records, and adjust the knowledge priority based on the verification records.

[0014] Preferably, step A includes the following sub-steps:

[0015] Step A1: Obtain the knowledge source in the knowledge chain and set the basic label of the knowledge source. The basic label consists of a unique code and a basic feature code. The unique code is generated by the identifier generation module, and the basic feature code is a combination of the domain classification and professional direction of the knowledge source.

[0016] Step A2: Obtain knowledge data from the initial ship design knowledge base, and set incremental tags for the initial knowledge data. The incremental tags consist of a unique code and an incremental feature code. The unique code is generated by the identifier generation module, and the incremental feature code consists of the creation year, creation month, and creation date of the knowledge data. The basic tags and the incremental tags are associated with each other through a data interface. The initial knowledge base represents the original knowledge set that has not undergone incremental updates.

[0017] Preferably, step B includes the following sub-steps:

[0018] Step B1: Obtain the metadata records of the knowledge data, classify the metadata records to obtain structured data, and the classification process includes topic filtering and hierarchical division.

[0019] Step B2: Extract the feature identifiers of the structured data. The feature identifiers of the structured data include content attributes and association attributes. The content attributes include design specifications, parameter standards, and case experience. The association attributes are technical associations and process associations.

[0020] Step B3: Divide knowledge into categories based on feature identifiers, and store the knowledge data in a hierarchical manner according to the knowledge categories.

[0021] Preferably, the logic for classifying the knowledge categories includes:

[0022] Call the knowledge classification library, input the knowledge type, and obtain the content attributes and associated attributes corresponding to the knowledge type. Combine the content attributes and associated attributes corresponding to the knowledge type into a standard classification set.

[0023] The feature identifiers of the structured data include content attributes and association attributes, and the feature identifiers of the structured data, including content attributes and association attributes, are combined into the current classification set;

[0024] Match the correspondence between the current category set and the standard category set, traverse the correspondence, select the correspondence with the highest matching degree, obtain the standard category set corresponding to the correspondence with the highest matching degree, and set the standard category set corresponding to the correspondence with the highest matching degree as the knowledge category. The knowledge category is described as: content attribute and association attribute.

[0025] Prioritize the storage and processing of knowledge data related to design specifications and technologies.

[0026] Preferably, the matching degree is determined by the proportion of the same attributes in the current classification set and the standard classification set, and the higher the proportion, the higher the matching degree.

[0027] Preferably, step C includes the following sub-steps:

[0028] Step C1: Set the update tag for the operating terminal. The update tag consists of a unique code and an update feature code. The unique code is generated by the identifier generation module. The update feature code is the device number of the operating terminal. The update tag is associated with the incremental tag through a data interface.

[0029] Step C2: Synchronize the hierarchically stored knowledge data to the operation terminal and obtain time information. The time information includes the last update time of the knowledge data and the current system time. The management backend terminal refers to the core platform for the overall management of knowledge data.

[0030] Step C2: Match the update cycle based on the time information.

[0031] Preferably, the matching logic for the update cycle includes:

[0032] Step C2: Obtain any cycle plan, and obtain usage parameters based on historical data. The usage parameters include: knowledge access frequency, terminal online duration, and data transmission stability. Evaluate the necessity of the update based on the knowledge access frequency, terminal online duration, and data transmission stability.

[0033] Iterate through the update necessities, select the update necessity with the best evaluation result, obtain the cycle scheme corresponding to the update necessity with the best evaluation result, and set the cycle scheme corresponding to the update necessity with the best evaluation result as the update cycle.

[0034] Preferably, step D includes the following sub-steps:

[0035] Step D1: Obtain the knowledge status of the operating terminal, compare the knowledge status with the update cycle, and obtain a first comparison conclusion, which is either needing to be updated or not needing to be updated.

[0036] Step D2: When the first comparison conclusion indicates that an update is required, an update prompt instruction is sent to the operation interface of the operating terminal until the first comparison conclusion indicates that an update is not required, at which point the sending of update prompt instructions stops.

[0037] Preferably, step E includes the following sub-steps:

[0038] Step E1: Obtain the usage frequency of the operating terminal, the operator identifier, and the duration of the update cycle. The operator identifier is a combination of numbers and letters.

[0039] Step E2: Calculate the product of the number of times knowledge data is called and the frequency of use within a preset time period, set the product of the number of times the data is called and the frequency of use as the knowledge activity index, and transmit the knowledge activity index and the operator identifier to the management backend terminal.

[0040] Step E3: Verify the updated knowledge according to a preset ratio and obtain verification records, which are the number of non-conformities. Obtain the total number of updated knowledge, calculate the ratio of the number of non-conformities to the total number of updated knowledge, and set the ratio of the number of non-conformities to the total number of updated knowledge as an adjustment coefficient. The adjustment of knowledge priority is based on the reverse correlation of the adjustment coefficient.

[0041] Preferably, the logic for generating the verification record includes:

[0042] Call the verification standard library, input the knowledge type, and obtain the set of verification items corresponding to the knowledge type. The set of verification items includes content completeness, expression accuracy, and association rationality.

[0043] The verification items for updated knowledge are obtained, and each verification item is compared with the set of verification items. Verification items that fail the comparison are recorded, and the verification items that fail the comparison are summarized as non-conformities. The non-conformities are counted item by item.

[0044] Compared with the prior art, the beneficial effects of the present invention are:

[0045] In terms of knowledge data storage and classification, by acquiring and classifying the metadata records of knowledge data, complex and diverse knowledge data is transformed into structured data. Feature identifiers are then extracted for knowledge category division and hierarchical storage. This approach makes knowledge data storage more orderly and standardized, greatly improving data retrieval efficiency. Designers can quickly and accurately find the required knowledge data, reducing wasted time and effort, thereby accelerating the ship design process. Simultaneously, hierarchical storage of knowledge data clearly demonstrates the relationships between knowledge points, forming a complete knowledge system and improving knowledge reusability and sharing. For example, prioritizing the storage of design specifications and technically relevant knowledge data allows designers to quickly access key knowledge during related design processes, improving design quality.

[0046] In the management of knowledge data updates, update tags are set and associated with incremental tags. Update cycles are matched based on time information, and the knowledge status of operational terminals is obtained in real time and compared with the update cycle, prompting timely update instructions. This series of operations automates and intelligently updates knowledge data, ensuring its timeliness and accuracy. Regardless of how rapidly technical specifications in the ship design industry change, designers can always access the latest and most accurate knowledge data, effectively avoiding design errors and risks caused by using outdated knowledge, reducing design costs, and improving the reliability and safety of designs.

[0047] For the use and priority management of knowledge data, a knowledge activity index is calculated by acquiring the usage frequency of operational terminals. This index is then combined with operator identification for comprehensive analysis. Updated knowledge is verified according to a preset ratio, and knowledge priorities are adjusted based on the verification records. This approach accurately assesses the value and importance of knowledge data, enabling dynamic management. High-value, highly active knowledge data is prioritized for display and recommendation to designers, allowing them to quickly access the most helpful knowledge for their design work, thus improving knowledge utilization efficiency. Simultaneously, the rational adjustment of knowledge data priorities optimizes the allocation of storage resources, ensuring better protection and utilization of critical knowledge data, and enhancing the overall operational efficiency and management level of the ship design knowledge management system.

[0048] The incremental knowledge operation and management method for ship design knowledge big data of the present invention comprehensively improves the scientificity, efficiency and intelligence of ship design knowledge management, provides strong support for the development of the ship design industry, and has important practical significance and broad application prospects. Attached Figure Description

[0049] Figure 1 This is a schematic diagram illustrating the working principle of the incremental knowledge operation and management method for ship design knowledge big data as described in this invention.

[0050] Figure 2 A flowchart illustrating the logic of knowledge category classification;

[0051] Figure 3 A detailed flowchart for step D;

[0052] Figure 4 A flowchart for the logic of generating verification records. Detailed Implementation

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

[0054] Please see Figures 1-4 This invention provides an incremental knowledge operation and management method for big data on ship design knowledge, the method comprising:

[0055] Step A: Obtain initial knowledge data from the ship design knowledge base and set incremental tags for the initial knowledge data. Organize the original knowledge set in the knowledge base, clarify the scope of the initial knowledge data, and set incremental tags for this data to facilitate subsequent tracking of knowledge updates and management.

[0056] Step B involves acquiring metadata records of the knowledge data, classifying these records to obtain structured data, extracting feature identifiers from the structured data, categorizing the knowledge data based on these feature identifiers, and then storing the knowledge data hierarchically according to these categories. In this process, we first collect various metadata information from the knowledge data, then transform it into structured data through classification methods such as topic filtering and hierarchical division. Next, we extract feature identifiers such as content attributes and association attributes from the structured data, categorize the knowledge based on these feature identifiers, and finally store the knowledge data hierarchically according to different knowledge categories to achieve orderly knowledge management.

[0057] Step C involves setting update tags for the operational terminal. These update tags are linked to incremental tags via a data interface. This synchronizes the hierarchically stored knowledge data to the operational terminal, obtains time information, and matches an update cycle based on this time information. Specifically, an update tag consisting of a unique code and an update feature code is set for the operational terminal, and this tag is linked to the incremental tag via a data interface. The hierarchically stored knowledge data is synchronized to the operational terminal, and time information such as the last update time of the knowledge data and the current system time is obtained. Based on this time information, an appropriate update cycle is matched.

[0058] Step D involves acquiring the knowledge status of the operating terminal, comparing it with the update cycle to obtain a first comparison conclusion, and generating an update prompt instruction based on this conclusion. In other words, the knowledge status in the operating terminal is acquired in real time, compared with a predetermined update cycle, and it is determined whether the knowledge needs updating. If an update is required, an update prompt instruction is generated and sent to the operating terminal's interface until the knowledge status indicates that no update is needed, at which point sending stops.

[0059] Step E involves obtaining the usage frequency and operator identification of the operational terminals, calculating the knowledge activity index based on the usage frequency, and transmitting the knowledge activity index and operator identification to the management backend terminal. Updated knowledge is verified according to a preset ratio, and verification records are obtained. Knowledge priority is adjusted based on these verification records. Specifically, this involves collecting the usage frequency of operational terminals and the numerical and alphanumeric combination codes of operators. The knowledge activity index is calculated by multiplying the number of times knowledge data is accessed by its usage frequency within a preset time period. This index and operator identification are transmitted to the management backend terminal. Updated knowledge is verified according to a preset ratio, and verification records such as the number of non-conformities are recorded. An adjustment coefficient is calculated based on the verification records, and the knowledge priority is adjusted according to the inverse correlation between the adjustment coefficient and knowledge priority.

[0060] Example 1:

[0061] This embodiment specifically describes how to acquire knowledge sources within a knowledge chain and set basic tags for these sources. These basic tags consist of a unique code and a basic feature code. The unique code is generated by an identifier generation module, which can employ hash algorithms or other encoding rules to ensure the generated code is unique throughout the system and accurately identifies each knowledge source. The basic feature code is a combination of the knowledge source's domain classification and professional direction. The domain classification can be based on different areas of ship design, such as hull design, marine engineering design, and electrical design. The professional direction further refines the specific professional directions within each domain, such as structural design and fluid dynamics design within hull design. This combination allows for preliminary feature description and classification of knowledge sources, facilitating subsequent management and retrieval.

[0062] Next, knowledge data from the initial ship design knowledge base is acquired, and incremental tags are set for this initial knowledge data. Incremental tags also consist of a unique code and an incremental feature code. The unique code is generated by the identifier generation module, following the same generation rules as the basic tag's unique code to ensure its uniqueness. The incremental feature code consists of the creation year, creation month, and creation date of the knowledge data. Specifically, the creation year is represented by four digits, such as 2023; the creation month is represented by two digits, padded with leading zeros if less than two digits, such as 05; and the creation date is also represented by two digits, padded with leading zeros if less than two digits, such as 08. This combination forms an incremental feature code like 20230508, clearly indicating the creation time information of the knowledge data.

[0063] Basic tags and incremental tags are linked together through a data interface, which can take the form of an API or other data transmission methods, establishing a connection between knowledge sources and knowledge data. For example, when a piece of knowledge data originates from a specific knowledge source, the incremental tag of that knowledge data is associated with the corresponding basic tag of the knowledge source through the data interface. This allows for quick tracing of the source of the knowledge data through tags during subsequent management and use.

[0064] The initial knowledge base represents the raw collection of knowledge that has not been incrementally updated. This knowledge data may include various types of information such as design specifications, parameter standards, and case experience. When acquiring the initial knowledge data, a comprehensive review and screening of the knowledge base is necessary to ensure that no raw knowledge data is missed. Methods such as database queries and file traversal can be used to extract all knowledge data from the knowledge base and perform preliminary organization and classification.

[0065] When setting basic and incremental tags, it is essential to ensure the accuracy and completeness of the tags. The domain classification and professional direction of the knowledge source need to be confirmed and categorized by professional ship designers to guarantee the accuracy of the basic feature encoding. The creation time of the knowledge data needs to be extracted from the metadata of the knowledge data, such as the file creation time and the record time in the database, to ensure the accuracy of the incremental feature encoding.

[0066] In practice, situations may arise where the domain classification and professional direction of knowledge sources are unclear. In such cases, it is necessary to organize professionals to discuss and analyze the issues to determine an appropriate classification and direction. For instances where the creation time of knowledge data is missing, it is necessary to supplement this information through other means as much as possible, such as reviewing relevant documentation or consulting with the individuals who created the knowledge data.

[0067] In addition, a label management mechanism needs to be established to record and manage operations such as label creation, modification, and deletion, ensuring label consistency and traceability. A database can be used to store label information, with appropriate access controls set up so that only authorized personnel can perform label management operations.

[0068] The above steps establish and associate tags for knowledge sources and initial knowledge data, laying the foundation for subsequent knowledge management and updates. During incremental knowledge updates, new knowledge data can be quickly identified through incremental tags and linked and integrated with existing knowledge data, improving the efficiency and accuracy of knowledge management. Furthermore, the association between basic and incremental tags allows for better tracing of the source and history of knowledge data, supporting knowledge quality control and application.

[0069] Example 2:

[0070] This embodiment specifically describes the acquisition of metadata records from knowledge data, followed by classification processing to obtain structured data. The classification process includes topic filtering and hierarchical division. When acquiring metadata records, relevant information needs to be extracted from various sources of the knowledge data, such as the title, author, creation time, keywords, and abstract. These metadata records can be obtained through database queries, file parsing, etc. For example, for knowledge data stored in a database, its metadata can be extracted using SQL queries; for knowledge data in document format, its metadata can be extracted using document parsing tools.

[0071] Topic filtering involves analyzing the acquired metadata records to select content relevant to the knowledge data's topic. It's necessary to determine the topic scope of the knowledge data and filter the metadata accordingly. For example, for knowledge data related to ship structure design, topic filtering should focus on metadata related to ship structure design, such as keywords like "ship structure" and "strength calculation," and descriptions of ship structure design in the abstract. Natural language processing techniques, such as keyword extraction and text classification, may be used during topic filtering to improve accuracy and efficiency.

[0072] Hierarchical partitioning involves dividing filtered metadata records according to a specific hierarchical structure, transforming the metadata into structured data. Hierarchical partitioning can be based on the logical relationships and organizational structure of the knowledge data. For example, metadata can be divided into levels such as basic information, content information, and related information. Basic information includes titles, authors, and creation times; content information includes keywords, abstracts, and design specifications; and related information includes relationships with other knowledge data. During the hierarchical partitioning process, it is crucial to ensure the rationality and logic of the hierarchical structure to facilitate subsequent processing and analysis of the structured data.

[0073] After classifying and processing the data to obtain structured data, feature identifiers are extracted. These feature identifiers include content attributes and relational attributes. Content attributes cover aspects such as design specifications, parameter standards, and case experience. Design specifications refer to ship design-related regulations involved in the knowledge data, such as relevant regulations of the International Maritime Organization (IMO) and national ship design standards. Parameter standards refer to the standard values ​​of various parameters involved in the knowledge data, such as ship size parameters and performance parameters. Case experience refers to ship design cases and their experience summaries contained in the knowledge data. Extracting content attributes requires in-depth analysis of the structured data to identify and extract the design specifications, parameter standards, case experience, and other relevant content.

[0074] The association attributes are categorized into technical associations and process associations. Technical associations refer to the technical relationships between knowledge data and other knowledge data, such as the technical relationship between a design specification and a parameter standard, or the technical relationship between a case study and a design specification. Process associations refer to the relationships between knowledge data within the ship design process, such as the process relationship between a design step and the next, or the process relationship between a design task and related design resources. Extracting association attributes requires analyzing the interrelationships between knowledge data, determining their technical and process associations, and then extracting these relationships.

[0075] Knowledge is categorized based on feature identifiers, and knowledge data is then stored hierarchically according to these categories. When categorizing knowledge, a knowledge classification library is first invoked. This library stores various knowledge types and their corresponding content attributes and related attributes. When a knowledge type is input, the corresponding content attributes and related attributes are retrieved from the knowledge classification library and combined into a standard classification set. For example, inputting the knowledge type "ship structure design" retrieves relevant content attributes (such as ship structure design specifications, structural strength parameter standards, etc.) and related attributes (such as technical associations with ship structure analysis software, and process associations with the ship structure design workflow, etc.) from the knowledge classification library, and combines them into a standard classification set.

[0076] The process involves acquiring feature identifiers from structured data and combining them into a current category set. This combines extracted content attributes and related attributes to form the current knowledge data's category set. The process then matches the current category set with a standard category set, iterating through all possible matches and selecting the one with the highest matching degree. The matching degree is determined by the percentage of identical attributes in the current and standard category sets; a higher percentage indicates a higher matching degree. For example, if the current category set has 10 attributes, and 8 of them are identical to those in the standard category set, the matching degree is 80%.

[0077] Obtain the standard classification set corresponding to the highest matching degree and set it as a knowledge category. The knowledge category is described as a content attribute and an association attribute. For example, if the content attributes of the standard classification set with the highest matching degree are "hull structure design code" and "structural strength parameter standard", and the association attribute is "technical association with hull structure analysis software", then the knowledge category is described as "hull structure design code and technical association with hull structure analysis software".

[0078] Knowledge data is stored in layers based on knowledge categories, with knowledge data of the same category stored in the same layer and knowledge data of different categories stored in different layers. Knowledge data that meets design specifications and is technically relevant receives priority storage treatment; for example, it may be stored on more secure and efficient storage media or given higher access permissions to ensure its security and availability.

[0079] In practice, situations may arise where the knowledge classification base does not contain a knowledge type that perfectly matches the current knowledge data. In such cases, the knowledge classification base needs to be updated and improved, or the knowledge types adjusted according to the actual situation. Simultaneously, when extracting feature identifiers and classifying knowledge categories, accuracy and consistency must be ensured to avoid classification errors caused by human factors. Furthermore, a management mechanism for knowledge categories and hierarchical storage needs to be established to record and manage operations such as the creation, modification, and deletion of knowledge categories, as well as adjustments to hierarchical storage, ensuring the standardization and traceability of knowledge management.

[0080] Example 3:

[0081] This embodiment specifically implements the setting of update tags for operating terminals. The update tag consists of a unique code and an update feature code. The unique code is generated by an identifier generation module, which can use methods such as hash algorithms or sequential incrementing to ensure the generated code is unique within the system and accurately identifies the update tag of each operating terminal. The update feature code is the device number of the operating terminal. Device numbers are typically compiled by the manufacturer according to certain rules and include information such as the device type and production batch. By using the device number as the update feature code, the operating terminal device corresponding to the update tag can be clearly identified. The update tag and the incremental tag are associated through a data interface, which can be in the form of an API or a database connection, establishing a mapping relationship between the two. For example, a correlation table can be created in the database to record the correspondence between the unique codes of the update tag and the unique codes of the incremental tag, enabling the update operation of the operating terminal to be correlated with the incremental information of the knowledge data.

[0082] The hierarchical knowledge data is synchronized to the operational terminal, obtaining time information including the last update time of the knowledge data and the current system time. The hierarchically stored knowledge data is stored on different levels of storage media according to the previously categorized knowledge types. Synchronization requires data transfer protocols such as FTP or HTTP to transfer the knowledge data from each level to the operational terminal's storage area. The management backend terminal, as the core platform for overall management of the knowledge data, is responsible for coordinating the synchronization process and recording relevant time information. The last update time can be extracted from the knowledge data's metadata, while the current system time is obtained from the terminal device's clock module, ensuring the accuracy of the time information.

[0083] The update cycle is matched based on time information. Specifically, any cycle plan is obtained, with different update intervals pre-set, such as daily, weekly, or monthly. Usage parameters are obtained based on historical data, including knowledge access frequency, terminal online duration, and data transmission stability. Knowledge access frequency can be obtained by statistically analyzing the number of times the operating terminal accesses knowledge data over a past period; terminal online duration is calculated by accumulating the time the operating terminal spends connected to the system; and data transmission stability can be assessed based on indicators such as packet loss rate and latency during historical data transmission.

[0084] The necessity of updating is assessed based on the frequency of knowledge access, terminal online duration, and data transmission stability. For operational terminals with high knowledge access frequency, the necessity of updating is high to ensure timely updates of the knowledge data they use. Longer terminal online duration indicates more opportunities for data updates, thus increasing the necessity of updating. Good data transmission stability facilitates smooth update operations, making the necessity of updating relatively high. Conversely, if the frequency of knowledge access is low, the terminal online duration is short, or the data transmission stability is poor, the necessity of updating is lower.

[0085] The algorithm iterates through all evaluation results of update necessity and selects the update necessity with the best evaluation result, i.e., the situation deemed most necessary to update after comprehensively considering all usage parameters. It then obtains the corresponding cycle plan for this optimal update necessity and sets it as the update cycle. For example, if an operational terminal has a high knowledge access frequency, long online time, and stable data transmission, and the evaluation result shows a high update necessity, with a corresponding cycle plan of daily updates, then the update cycle for that operational terminal is set to daily.

[0086] In practice, situations may arise where historical data is insufficient. In such cases, the default cycle plan can be used, and adjustments can be made gradually as data accumulates. For different types of operational terminals, such as those used by the design department and those used by the production department, their knowledge retrieval frequency and usage needs may differ. Therefore, the necessity of updates should be assessed separately, and corresponding update cycles should be set accordingly.

[0087] The updated tag settings must correspond one-to-one with the operating terminals to avoid errors in the update operation due to incorrect tags. When synchronizing knowledge data, network bandwidth and storage capacity limitations must be considered, and appropriate synchronization strategies should be adopted, such as incremental synchronization, which transmits only the updated knowledge data to improve synchronization efficiency.

[0088] Time information acquisition must ensure time zone consistency to avoid update cycle mismatches due to time errors. The algorithm for evaluating the necessity of updates can be optimized according to actual needs. For example, different weights can be assigned to each parameter, with higher weights for knowledge access frequency and relatively lower weights for terminal online duration and data transmission stability, to better suit real-world application scenarios.

[0089] Establish an update cycle management mechanism to record the update cycle settings for each operational terminal and allow administrators to manually adjust the update cycle based on actual conditions. When the usage scenario of an operational terminal changes, such as a sudden increase in the frequency of knowledge access or a decrease in data transmission stability, the necessity of updates can be reassessed and the update cycle adjusted to ensure that the knowledge data in the operational terminal is always up-to-date and meets user needs.

[0090] Example 4:

[0091] This embodiment specifically involves acquiring the knowledge status of the operating terminal, comparing the knowledge status with the update cycle to obtain a first comparison conclusion, and generating an update prompt instruction based on the first comparison conclusion. When acquiring the knowledge status of the operating terminal, relevant information needs to be extracted from the terminal's knowledge storage area. The knowledge status includes the version number of the knowledge data, the last update time, and whether an update package exists. For example, if an operating terminal stores ship structure design specification knowledge data with version number V1.0 and a last update time of June 1, 2025, it is necessary to check whether an update package for this knowledge data exists.

[0092] The knowledge status can be obtained by periodically scanning the knowledge storage area of ​​the operating terminal, or by automatically detecting it when the operating terminal starts up. During the scanning or detection process, it is necessary to read the metadata of the knowledge data to obtain status information such as version number and last update time. For knowledge data with update packages, it is necessary to record relevant information about the update packages, such as the size of the update package and a summary of the updated content.

[0093] The knowledge status is compared with the update cycle, which is set based on previous steps, such as daily, weekly, or monthly. The comparison mainly includes whether the interval between the last update time of the knowledge data and the current system time exceeds the update cycle, and whether the version number of the knowledge data is lower than the latest version number. For example, if an operator terminal's update cycle is set to once a week, and the current system time is June 29, 2025, while the last update time of certain knowledge data on this operator terminal is June 20, 2025, the interval is 9 days, exceeding the 7-day update cycle. In this case, the first comparison conclusion is that an update is needed. If the last update time is June 25, 2025, the interval is 4 days, not exceeding the update cycle, then the first comparison conclusion is that an update is not needed.

[0094] Another example is that the latest version number of a certain knowledge data is V1.2, while the version number in the operation terminal is V1.0. In this case, regardless of the last update time, the first comparison conclusion is that it needs to be updated; if the version number in the operation terminal is V1.2, then the first comparison conclusion is that it does not need to be updated.

[0095] After obtaining the first comparison result, an update prompt instruction is generated based on that result. When the first comparison result indicates that an update is required, an update prompt instruction is sent to the operation terminal's interface. This instruction can take the form of a pop-up window, message notification, etc., prompting the operator that the knowledge data needs to be updated and displaying relevant update information, such as a summary of the update content and the size of the update package. For example, a pop-up window might display: "The knowledge data for ship structure design specifications has been updated; the version number has been updated from V1.0 to V1.2. The update includes the addition of a certain design parameter standard; immediate update is recommended."

[0096] After receiving the update prompt, operators can choose to update immediately or update later. When operators choose to update immediately, the system begins downloading the update package and performing the update operation; when operators choose to update later, the system will send the update prompt again after a period of time, until the operator performs the update operation or the first comparison result changes to no update required.

[0097] If the initial comparison concludes that no update is needed, the system does not send an update prompt and continues to check the knowledge status according to the update cycle. For example, the knowledge status is retrieved again at regular intervals (such as once a day) and compared with the update cycle to determine whether an update is required.

[0098] In practice, unstable network connections may occur, preventing timely acquisition of the knowledge status of operational terminals or the sending of update notification commands. In such cases, the system needs a retry mechanism to re-acquire and send data once the network connection is restored.

[0099] When there are multiple operating terminals, it is necessary to obtain the knowledge status of each terminal separately, compare it according to its respective update cycle, and generate update prompts. For example, the operating terminals of the design department and the production department may have different update cycles, which need to be handled separately.

[0100] Update prompts must be clear and concise, allowing operators to quickly understand the required data and its details, enabling them to make informed update decisions. Simultaneously, the system needs to record the sending of update prompts, including the sending time and operator response, for later retrieval and management.

[0101] Once the knowledge data is updated, the knowledge status on the operational terminal will change, such as the version number being updated to the latest version and the last update time being updated to the current system time. At this point, when a comparison is performed again, the initial comparison conclusion will change to "no update required," and the system will stop sending update prompts.

[0102] In addition, the system needs to have the function of manually triggering update checks, allowing operators to manually check the knowledge status and obtain update prompts when needed. For example, before undertaking an important design task, operators can manually trigger an update check to ensure that the knowledge data used is up-to-date.

[0103] Example 5:

[0104] This embodiment specifically describes the acquisition of the usage frequency, operator identification, and update cycle duration of the operating terminal. The operator identification is a combination of numbers and letters, such as "DES001," where "DES" represents the design department and "001" represents the first operator in that department. Usage frequency refers to the number of times the operating terminal accesses knowledge data per unit of time, which can be statistically analyzed through system logs. The update cycle duration is such as daily or weekly; for example, if an operating terminal's update cycle is set to weekly, the duration is 7 days.

[0105] The product of the number of times knowledge data is accessed and its usage frequency within a preset time period is calculated and set as the knowledge activity index. The preset time period can be set according to actual needs, such as one month. For example, if an operator terminal accesses knowledge data A 5 times per day within a month (30 days), and the number of accesses is 100, then the knowledge activity index is 100 × 5 = 500. The knowledge activity index and operator identifier are transmitted to the management backend terminal, which can then store and analyze this data.

[0106] Updated knowledge is verified according to a preset ratio, and verification records are generated. The preset ratio can be set according to the type and importance of the knowledge, such as 20%. For example, if a batch of updated knowledge contains 100 items, 20 items are randomly selected for verification at a ratio of 20%. The verification record shows the number of non-conformities, and the set of verification items includes content completeness, accuracy of expression, and reasonableness of association.

[0107] The system calls upon the verification standard library, inputs the knowledge type, and obtains a set of verification items corresponding to that knowledge type. For example, inputting the knowledge type "ship structure design" will result in a set of verification items including whether the content fully covers a certain structural design code, whether the description accurately describes the strength calculation method, and whether the association with other structural design knowledge is reasonable.

[0108] The verification items for updated knowledge are obtained and compared item by item with the set of verification items. Verification items that fail the comparison are recorded. For example, the verification items for updated knowledge B are: content covering a structural design code, description of strength calculation methods, and association with structural analysis knowledge. When comparing with the set of verification items, it is found that its content does not fully cover a structural design code, but the description is accurate and the association is reasonable; therefore, the number of non-compliance items is 1.

[0109] The ratio of the number of non-compliant items to the total number of updated knowledge items is set as the adjustment coefficient. For example, if the total number of updated knowledge items is 100 and the number of non-compliant items is 5, the adjustment coefficient is 5 ÷ 100 = 5%. The adjustment of knowledge priority is based on the inverse correlation of the adjustment coefficient; that is, the lower the adjustment coefficient, the higher the knowledge priority. For example, knowledge with an adjustment coefficient of 5% has a lower priority than knowledge with an adjustment coefficient of 3%.

[0110] In practice, the coding rules for operator identification must be standardized so that the management backend terminal can identify the operator's department and identity. Usage frequency statistics must be accurate to avoid deviations in the calculation of the knowledge activity index due to errors in system log recordings. The selection of the preset time period should be reasonable; if the time period is too long, it may not be able to reflect changes in knowledge activity in a timely manner; if it is too short, the statistical results may not be stable enough.

[0111] During the verification process, verifiers must possess professional knowledge to ensure the accuracy of the verification results. For example, when verifying knowledge of ship hull structure design, verifiers should be familiar with relevant design codes and standards. For any non-conformities, the reasons must be recorded in detail so that personnel updating their knowledge can make the necessary corrections.

[0112] After the adjustment coefficients are calculated, the management backend terminal sorts the knowledge priorities according to these coefficients. Knowledge priorities determine the display order and update frequency of knowledge in the operational terminal. For example, higher-priority knowledge is displayed first in search results and has a shorter update cycle.

[0113] Furthermore, when operators access knowledge, the management backend terminal can record information such as the access time and operator identification. Combined with the knowledge activity index and priority, this data can be used to analyze knowledge usage patterns and needs, providing a reference for subsequent knowledge management. For example, if a certain type of knowledge consistently exhibits a high activity index and high priority, increasing the update frequency of that type of knowledge or expanding its content can be considered.

[0114] For the verification of updated knowledge, if the number of non-conformities in the sample exceeds a certain threshold, such as if the proportion of non-conformities found in the preset ratio verification exceeds 10%, a comprehensive verification of the entire batch of updated knowledge can be considered to ensure the quality of the updated knowledge.

[0115] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0116] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. An incremental knowledge operation and management method for ship design knowledge big data, characterized in that, Includes the following steps: Step A: Obtain initial knowledge data from the ship design knowledge base and set incremental tags for the initial knowledge data; Step B: Obtain the metadata records of the knowledge data, classify the metadata records to obtain structured data, extract the feature identifiers of the structured data, divide the knowledge into categories according to the feature identifiers, and store the knowledge data in layers according to the knowledge categories. Step C: Set the update tag for the operation terminal. The update tag and the incremental tag are associated through a data interface. The hierarchically stored knowledge data is synchronized to the operation terminal to obtain time information and match the update cycle according to the time information. Step D: Obtain the knowledge status of the operating terminal, compare the knowledge status with the update cycle, obtain a first comparison conclusion, and generate an update prompt instruction based on the first comparison conclusion; Step E: Obtain the usage frequency and operator identification of the operation terminal, calculate the knowledge activity index based on the usage frequency, transmit the knowledge activity index and operator identification to the management backend terminal, verify the updated knowledge according to a preset ratio, obtain verification records, and adjust the knowledge priority based on the verification records.

2. The incremental knowledge operation and management method for ship design knowledge big data as described in claim 1, characterized in that: Step A includes the following sub-steps: Step A1: Obtain the knowledge source in the knowledge chain and set the basic label of the knowledge source. The basic label consists of a unique code and a basic feature code. The unique code is generated by the identifier generation module, and the basic feature code is a combination of the domain classification and professional direction of the knowledge source. Step A2: Obtain knowledge data from the initial ship design knowledge base, and set incremental tags for the initial knowledge data. The incremental tags consist of a unique code and an incremental feature code. The unique code is generated by the identifier generation module, and the incremental feature code consists of the creation year, creation month, and creation date of the knowledge data. The basic tags and the incremental tags are associated with each other through a data interface. The initial ship design knowledge base is represented as the original knowledge set that has not undergone incremental updates.

3. The incremental knowledge operation and management method for ship design knowledge big data as described in claim 1, characterized in that: Step B includes the following sub-steps: Step B1: Obtain the metadata records of the knowledge data, classify the metadata records to obtain structured data, and the classification process includes topic filtering and hierarchical division. Step B2: Extract the feature identifiers of the structured data. The feature identifiers of the structured data include content attributes and association attributes. The content attributes include design specifications, parameter standards, and case experience. The association attributes are technical associations and process associations. Step B3: Divide knowledge into categories based on feature identifiers, and store the knowledge data in a hierarchical manner according to the knowledge categories.

4. The incremental knowledge operation and management method for ship design knowledge big data as described in claim 3, characterized in that: The logic for classifying knowledge categories includes: Call the knowledge classification library, input the knowledge type, and obtain the content attributes and associated attributes corresponding to the knowledge type. Combine the content attributes and associated attributes corresponding to the knowledge type into a standard classification set. The feature identifiers of the structured data include content attributes and association attributes, and the feature identifiers of the structured data, including content attributes and association attributes, are combined into the current classification set; Match the correspondence between the current category set and the standard category set, traverse the correspondence, select the correspondence with the highest matching degree, obtain the standard category set corresponding to the correspondence with the highest matching degree, and set the standard category set corresponding to the correspondence with the highest matching degree as the knowledge category. The knowledge category is described as: content attribute and association attribute. Prioritize the storage and processing of knowledge data related to design specifications and technologies.

5. The incremental knowledge operation and management method for ship design knowledge big data as described in claim 4, characterized in that: The matching degree is determined by the proportion of the same attributes in the current classification set and the standard classification set. The higher the proportion, the higher the matching degree.

6. The incremental knowledge operation and management method for ship design knowledge big data as described in claim 1, characterized in that: Step C includes the following sub-steps: Step C1: Set the update tag for the operating terminal. The update tag consists of a unique code and an update feature code. The unique code is generated by the identifier generation module. The update feature code is the device number of the operating terminal. The update tag is associated with the incremental tag through a data interface. Step C2: Synchronize the hierarchically stored knowledge data to the operation terminal and obtain time information. The time information includes the last update time of the knowledge data and the current system time. The management backend terminal refers to the core platform for the overall management of knowledge data. Step C2: Match the update cycle based on the time information.

7. The incremental knowledge operation and management method for ship design knowledge big data as described in claim 1, characterized in that: The matching logic for the update cycle includes: Step C2: Obtain any cycle plan, and obtain usage parameters based on historical data. The usage parameters include: knowledge access frequency, terminal online duration, and data transmission stability. Evaluate the necessity of updating based on the knowledge access frequency, terminal online duration, and data transmission stability. Iterate through the update necessities, select the update necessity with the best evaluation result, obtain the cycle scheme corresponding to the update necessity with the best evaluation result, and set the cycle scheme corresponding to the update necessity with the best evaluation result as the update cycle.

8. The incremental knowledge operation and management method for ship design knowledge big data as described in claim 1, characterized in that: Step D includes the following sub-steps: Step D1: Obtain the knowledge status of the operating terminal, compare the knowledge status with the update cycle, and obtain a first comparison conclusion, which is either needing to be updated or not needing to be updated. Step D2: When the first comparison conclusion indicates that an update is required, an update prompt instruction is sent to the operation interface of the operating terminal until the first comparison conclusion indicates that an update is not required, at which point the sending of update prompt instructions stops.

9. The incremental knowledge operation and management method for ship design knowledge big data as described in claim 1, characterized in that: Step E includes the following sub-steps: Step E1: Obtain the usage frequency of the operating terminal, the operator identifier, and the duration of the update cycle. The operator identifier is a combination of numbers and letters. Step E2: Calculate the product of the number of times knowledge data is called and the frequency of use within a preset time period, set the product of the number of times the data is called and the frequency of use as the knowledge activity index, and transmit the knowledge activity index and the operator identifier to the management backend terminal. Step E3: Verify the updated knowledge according to a preset ratio and obtain verification records, which are the number of non-conformities. Obtain the total number of updated knowledge, calculate the ratio of the number of non-conformities to the total number of updated knowledge, and set the ratio of the number of non-conformities to the total number of updated knowledge as an adjustment coefficient. The adjustment of knowledge priority is based on the reverse correlation of the adjustment coefficient.

10. The incremental knowledge operation and management method for ship design knowledge big data as described in claim 9, characterized in that: The logic for generating the verification record includes: Call the verification standard library, input the knowledge type, and obtain the set of verification items corresponding to the knowledge type. The set of verification items includes content completeness, expression accuracy, and association rationality. The verification items for updated knowledge are obtained, and each verification item is compared with the set of verification items. Verification items that fail the comparison are recorded, and the verification items that fail the comparison are summarized as non-conformities. The non-conformities are counted item by item.

Images