Automated Construction and Update Methods for Large-Scale Model Knowledge Bases in the Industrial Manufacturing Field

Abstract

This invention provides an automated construction and updating method for a large-scale model knowledge base in the industrial manufacturing field, belonging to the field of industrial artificial intelligence technology. This invention automatically extracts time-overlapping scheduling instance pairs from the task orchestration system's scheduling logs, requiring that the tooling wear segment encoding sequences of the two instances be completely identical throughout the overlapping period. This fundamentally avoids mismatches in parallel operations caused by changes in tooling lifespan, significantly improving the physical equivalence and reliability of candidate parallel operation modes. Simultaneously, by integrating metadata tags and the lineage attributes of upstream source entries for rule-based conflict detection, it can identify deep business semantic conflicts such as task source priority and trigger type that traditional methods based on equipment or time dimensions cannot detect, thereby greatly improving the security and process compliance of the knowledge base's stored content.

Description

Technical Field

[0001] This invention belongs to the field of industrial artificial intelligence technology, specifically involving a method for the automated construction and updating of a large model knowledge base in the industrial manufacturing field. Background Technology

[0002] As a core infrastructure of artificial intelligence systems, the automated construction and dynamic updating of knowledge bases have become a research hotspot in the field of industrial intelligence. In recent years, with the deep application of large language models in vertical industries, knowledge base construction methods for the industrial manufacturing sector have evolved from manual organization and semi-automatic extraction to automated methods driven by logs and multi-source data. Among existing technologies, patent CN120994889A proposes an AI knowledge base construction method based on multi-source data integration. Through steps such as reversible crawler orchestration, pattern drift detection, source credibility index decay conflict resolution, unified contrastive learning multimodal mapping, hypergraph knowledge graph, and generative adversarial reinforcement learning subgraph extraction, it achieves the integration of heterogeneous data sources and knowledge graph construction. Patent CN121479436A proposes an equipment fault diagnosis system based on a knowledge base and a large model. This system collects real-time equipment operating status data, uses a domain knowledge base for initial judgment, then uses a large model module for precise reasoning, and updates the knowledge base and fine-tunes the large model based on confirmation information from the maintenance terminal. These technologies have made progress in multi-source heterogeneous data integration and intelligent fault diagnosis, respectively.

[0003] However, none of the aforementioned existing technologies provide solutions for the automatic discovery of parallel operation modes and knowledge base construction based on scheduling logs in the industrial manufacturing field. Specifically, taking CN120994889A as an example, this method focuses on extracting unstructured or semi-structured data from external websites and multimodal data sources, and constructing a knowledge graph through hypergraphs and reinforcement learning. Its data sources are static documents, images, and time-series signals. The conflict resolution in this method is based on exponential decay of source credibility and weighted voting, resolving value conflicts of the same data field across different sources, rather than semantic conflicts at the business rule level between different scheduling instances. Therefore, it is difficult to directly adapt to the large-scale model knowledge base construction requirements in industrial manufacturing scenarios.

[0004] Taking CN121479436A as an example, it involves a device fault diagnosis system based on a knowledge base and a large model. Its core lies in using sensors to collect real-time operational status data such as vibration, temperature, and current of the equipment. Initial judgment is made through a domain knowledge base (including a fault rule base, a fault case base, and a device mechanism base), followed by a refined judgment by a large model diagnosis module. Finally, a diagnostic report is output, and the knowledge base is updated or the large model is fine-tuned based on the operation and maintenance confirmation results. This technology focuses on online monitoring and diagnosis of equipment faults. Its knowledge base contains fault judgment rules, historical fault cases, and fault cause-effect graphs, with knowledge sources including real-time sensor data and pre-set mechanism models. However, this solution does not consider the dynamic changes in tooling wear sections with cumulative usage time, nor does it require comparing the consistency of wear section codes within the overlapping time intervals of scheduling instances. Furthermore, the conflict resolution in this scheme is essentially a verification of the similarities and differences between the initial and detailed fault type judgments, rather than a detection of rule conflicts triggered by the combination of metadata tags and upstream lineage attributes in different instances in parallel operation mode. Its knowledge base update depends on the confirmation of the diagnostic results by the operation and maintenance personnel, rather than pushing out the automatically detected conflict patterns.

[0005] Therefore, this fault diagnosis system cannot be migrated to manufacturing task scheduling scenarios to automatically discover parallel operation patterns and build a knowledge base for large models. Summary of the Invention

[0006] The purpose of this section is to outline some aspects of the embodiments of the present invention and to briefly introduce some preferred embodiments. Some simplifications or omissions may be made in this section, as well as in the abstract and title of the present application, to avoid obscuring the purpose of this section, the abstract and title of the invention. Such simplifications or omissions shall not be used to limit the scope of the present invention.

[0007] In view of the aforementioned existing problems, the present invention is proposed.

[0008] To address the aforementioned technical problems, the present invention provides the following technical solution: An automated construction and updating method for a large-scale model knowledge base in the industrial manufacturing field includes: extracting time-overlapping scheduling instance pairs from the task orchestration system and recording the device identifiers associated with each scheduling instance; reading the wear segment code of the corresponding device from the tooling status history database based on the start time of each instance, verifying whether the wear segment codes of the two scheduling instances remain the same at every moment within the overlapping time interval, and retaining only scheduling instance pairs with the same wear segment code at the start time and consistent wear segment code throughout the entire overlapping interval as candidate parallel operation modes; mapping the instances in the candidate parallel operation modes to knowledge entries, obtaining the metadata and upstream source entries of each knowledge entry, and detecting attribute conflicts; if no conflict is detected, converting the candidate parallel operation modes into a large-scale model-parsable encoding string and storing it in the knowledge base; if a conflict is detected, generating an update record with the wear segment code and pushing it to the maintenance terminal.

[0009] As a preferred embodiment of the present invention, the step of extracting time-overlapping scheduling instance pairs from the task orchestration system includes: reading the start time, end time, and device identifier associated with each scheduling instance from the scheduling log table of the task orchestration system; calculating the overlap length of the time interval formed by the start time and end time of any two scheduling instances; and recording two scheduling instances with an overlap length greater than zero as a joint execution task pair.

[0010] As a preferred embodiment of the present invention, the step of reading the wear segment code of the corresponding device includes: for each scheduling instance in the joint execution task pair, reading the wear segment code of the corresponding device at the start time from the tooling status history database according to the device identifier of each scheduling instance and the start time of each scheduling instance; the wear segment code is divided into sharp segment, stable segment and decay segment according to a preset physical life threshold; comparing the wear segment codes of the two scheduling instances in the joint execution task pair at the start time, and retaining only joint execution task pairs where the wear segment codes of the two scheduling instances are completely identical at the start time; for joint execution task pairs with the same wear segment code at the start time, verifying whether the wear segment codes of the two scheduling instances remain the same throughout the entire overlapping time interval; if the wear segment codes of the two scheduling instances are different at any moment within the overlapping interval, discarding the joint execution task pair; marking joint execution task pairs that simultaneously satisfy the condition of having the same start time code and having the code remain consistent throughout the overlapping time period as candidate parallel operation modes.

[0011] In a preferred embodiment of the present invention, the step of mapping instances in candidate parallel operation modes to knowledge entries includes: converting each scheduling instance in the candidate parallel operation mode into a knowledge entry, wherein the knowledge entry includes an instance identifier, a device identifier, a start time, an end time, and a wear segment code; wherein the wear segment code is taken from the wear segment code at the start time of the scheduling instance.

[0012] As a preferred embodiment of the present invention, the step of obtaining the metadata of each knowledge entry includes: for each knowledge entry, obtaining a set of metadata key-value pairs from the metadata management module; the set of metadata key-value pairs includes at least the following metadata items: equipment type label and its value, process type label and its value, tooling life range label and its value.

[0013] As a preferred embodiment of the present invention, the step of obtaining the upstream source entries of each knowledge entry includes: for each knowledge entry, querying the data lineage module to generate the upstream source entry record of the scheduling instance based on the device identifier and start time of the knowledge entry; the upstream source entry record includes at least the source entry identifier, the source entry type, and the priority level of the source entry.

[0014] As a preferred embodiment of the present invention, the detection of attribute conflicts includes: A conflict is identified when a specified metadata tag of a knowledge entry takes a specific value, and a specified attribute of the knowledge entry's upstream source entry takes a specific value. For each knowledge entry, all metadata key-value pairs of the knowledge entry and all attribute key-value pairs of the knowledge entry's upstream source entries are obtained. Each rule in the conflict rule table is traversed, and it is checked whether there is a tag value pair in the knowledge entry's metadata key-value pairs that matches the rule conditions. At the same time, it is checked whether there is an attribute value pair in the upstream source entries that matches the rule conditions. If both match, the knowledge entry is identified as conflicted, and the conflict location is recorded as the knowledge entry identifier and the conflict rule number.

[0015] As a preferred embodiment of the present invention, the step of converting the candidate parallel operation mode into a large model-parseable encoding string and storing it in the knowledge base if no conflict is detected includes: when neither of the two knowledge entries in the candidate parallel operation mode triggers any conflict rules, concatenating the instance identifier, device identifier, wear segment code, start time, and end time of the two scheduling instances in the candidate parallel operation mode in sequence with commas as separators, and adding a header identifier before the concatenation result to obtain the encoding string; and writing the encoding string into the formal storage area of ​​the knowledge base.

[0016] In a preferred embodiment of the present invention, when any knowledge entry in the candidate parallel operation mode triggers at least one conflict rule, all conflict records are collected; each conflict record includes the identifier of the knowledge entry that triggered the conflict, the rule number that triggered the conflict, the metadata tag name and value that triggered the conflict, and the attribute name and value of the upstream source entry that triggered the conflict; based on the collected conflict records, an update record is generated, the update record including the identifiers of the two knowledge entries that triggered the conflict, a list of all rule numbers that triggered the conflict, the complete encoding string of the candidate parallel operation mode, and the wear segment encoding of each knowledge entry that triggered the conflict; the update record is pushed to the maintenance terminal, and writing the candidate parallel operation mode into the knowledge base is prohibited.

[0017] The beneficial effects of this invention are as follows: Compared with the prior art, the technical effects of this invention are as follows: This invention automatically extracts time-overlapping scheduling instance pairs from the task orchestration system scheduling log and requires that the tooling wear segment encoding sequences of the two instances be completely consistent throughout the entire overlapping period. This fundamentally avoids mismatches in parallel operations caused by changes in tooling lifespan, significantly improving the physical equivalence and reliability of candidate parallel operation modes. At the same time, by integrating metadata tags and the lineage attributes of upstream source entries for rule-based conflict detection, it can identify deep business semantic conflicts such as task source priority and trigger type that cannot be discovered by traditional methods based on device or time dimensions, thereby greatly improving the security and process compliance of the knowledge base storage content.

[0018] For conflict-free patterns, the generated large model parsable encoding strings not only facilitate the direct training and inference of large language models, but also quantify the quality differences of parallel patterns by introducing time consistency scores, making the knowledge base more discriminative. For conflict patterns, update records with complete context are automatically generated and pushed to the maintenance terminal, forming a closed-loop feedback, which effectively supports the continuous optimization of the knowledge base and the dynamic adjustment of rules. Overall, it realizes the high-quality automated construction and updating of large model knowledge bases in the industrial manufacturing field. Attached Figure Description

[0019] Figure 1 This is a flowchart of the automated construction and updating method for a large model knowledge base in the industrial manufacturing field as described in this invention.

[0020] Figure 2 This is a schematic diagram of the conflict detection and knowledge storage branch process in this invention.

[0021] Figure 3 A schematic diagram of the structure of an electronic device for realizing the automated construction and updating method of a large model knowledge base in the industrial manufacturing field according to embodiments of the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of this invention. The embodiments described in this application are merely some embodiments of this invention, and not all embodiments. Based on the spirit of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the protection scope of this invention.

[0023] like Figures 1-2 As shown, the method for automatically constructing and updating a large-scale model knowledge base in the industrial manufacturing field according to the present invention includes: S1: Extract time-overlapping pairs of scheduling instances from the task orchestration system and record the device identifier associated with each scheduling instance.

[0024] First, read all or a specified time range of scheduling instance records from the scheduling log table of the task orchestration system. Each scheduling instance record contains at least three key fields: instance identifier, start time of the instance, end time of the instance, and device identifier associated with the instance.

[0025] It should be noted that a scheduling instance is a specific execution unit automatically generated by the task orchestration system according to a preset work process, such as a CNC machine tool machining program instance, a robot handling task instance, or a measurement instance of a testing instrument. The start and end times in the scheduling log table are based on the system's unified clock to ensure time comparability between different instances.

[0026] In a preferred implementation of this embodiment, if a scheduling instance has not yet recorded its end time (i.e., the instance is still running), the end time of the instance is temporarily set to the current system time, or marked as invalid and excluded from subsequent processing, in order to avoid time interval errors caused by incomplete data.

[0027] Furthermore, for all the obtained scheduling instances, this embodiment uses a pairwise comparison method to calculate the overlap length of the time interval formed by the start time and end time of each pair of scheduling instances.

[0028] For example, suppose the start and end times of the first scheduling instance constitute a first time interval, and the start and end times of the second scheduling instance constitute a second time interval. When comparing the overlap length of the two time intervals, first take the later of the two start times and the earlier of the two end times. If the later time is earlier than the earlier time, then the overlap length is equal to the earlier time minus the later time; otherwise, the overlap length is zero.

[0029] It should be noted that in actual program implementation, to avoid floating-point precision issues, integer timestamps (such as milliseconds) are usually used for calculation. When the overlap length is greater than zero, the two scheduling instances are considered to overlap in time, meaning they may execute in parallel or partially overlap. In this case, the two instances are recorded as a joint execution task pair, and the instance identifier, their respective device identifiers, and their respective time interval information are retained.

[0030] It should be noted that the overlap length being greater than zero in this step includes boundary contact, i.e., the situation where the end time of one instance equals the start time of another instance. However, in actual industrial manufacturing scenarios, boundary contact usually does not represent true parallel operation. Therefore, in the preferred embodiment of this example, the overlap length is further set to be greater than a preset time threshold, which is set to 1 second in this embodiment, to avoid false overlap caused by time resolution. However, as a basic implementation, using greater than zero as the judgment condition can satisfy most scenarios.

[0031] As can be seen, compared with manual review or rule-based hard-coding methods, the present invention can capture potential parallel operation modes without omission, providing a complete and accurate candidate set for subsequent fine filtering based on tooling wear status.

[0032] S2: Based on the start time of each instance, read the wear segment code of the corresponding device from the tooling status history database, and verify whether the wear segment codes of the two scheduling instances are the same at every moment in the overlapping time interval. Only retain the scheduling instance pairs with the same wear segment code at the start time and the wear segment code remains consistent throughout the entire overlapping interval as candidate parallel operation modes.

[0033] It should be noted that step S2 in this embodiment is used for fine-grained filtering of the obtained joint execution task pair based on the tooling wear state. The core requirement is not only that the wear segment codes of the two scheduling instances be the same at the start time, but also that their wear segment code sequences remain completely consistent throughout the entire overlapping time interval, in order to avoid mismatches caused by changes in the tooling wear segment during parallel execution. The specific operation is as follows: S2.1: For each recorded pair of jointly executed tasks, extract two scheduling instances. For each scheduling instance, this embodiment performs the following operations: First, obtain the device identifier and start time of the scheduling instance, and use these two fields as the joint query key to read the corresponding wear segment code from the tooling status history database.

[0034] The tooling status history database is a time-series database that records the wear stage of each tooling or equipment at different points in time. The wear stage is divided based on a preset physical lifespan threshold. For example, if the total lifespan of the tooling is L (in hours or number of processed parts), then: when the cumulative usage time ∈ [0, 0.3L), it is classified as a sharp stage, coded as SHARP; when the cumulative usage time ∈ [0.3L, 0.7L), it is classified as a stable stage, coded as STABLE; when the cumulative usage time ∈ [0.7L, L], it is classified as a decay stage, coded as WEAR.

[0035] The above ratio thresholds of 0.3 and 0.7 are default values, and in actual applications they should be set through configuration files or management interfaces.

[0036] It should be noted that the above-mentioned ratio thresholds can be configured according to the actual physical characteristics of different tooling types; in addition, the data in the tooling status history database can be updated in real time through the cumulative usage time of sensors or a conversion model based on the number of processed parts.

[0037] During the query, since the tooling wear segment code may change between adjacent time points, such as from a sharp segment to a stable segment, this embodiment strictly uses the start time of the scheduling instance as the query reference time, and takes the wear segment code of the tooling at that time as the representative code of that instance. If the query result is empty, such as the device identifier not existing or the start time exceeding the historical record range, the joint execution task pair is discarded and an exception log is recorded.

[0038] S2.2: After obtaining the start-time wear segment codes of the two scheduling instances within the same joint execution task pair, compare whether they are completely identical. If they are different, discard the joint execution task pair directly and do not proceed with further processing. If they are identical, proceed to the next step of time period consistency verification.

[0039] S2.3: For the joint execution task pairs that pass the initial screening, this embodiment further performs enhanced verification: verifying whether the wear segment codes of the tooling of the two scheduling instances are consistent at any time point within the time overlap interval between the two instances.

[0040] To avoid missing transition points due to improper selection of sampling step size, this embodiment adopts a precise comparison method based on the time of code change, rather than sampling with a fixed step size.

[0041] Specifically, the method acquires all wear segment code change time points for the two devices within the overlapping interval. These time points are then merged and sorted with the start and end times of the overlapping interval to obtain a series of continuous sub-intervals. Within each sub-interval, the wear segment codes for both devices are constant values. The method directly compares whether the codes at any time point (e.g., the left endpoint) within that sub-interval are the same. If the codes are the same across all sub-intervals, the devices are considered consistent within the time period; otherwise, they are discarded. This method does not require setting a sampling step size and is deterministic.

[0042] It should be noted that in practical engineering implementations, considering that the changes in wear segment codes are discrete and low-frequency, only changing when the cumulative usage time crosses a threshold, dense sampling is unnecessary. A more efficient implementation is to obtain the time points of wear segment code changes for two devices within the overlapping interval, i.e., the code jump moments. The overlapping interval is then divided into several continuous sub-intervals, with the code remaining constant within each sub-interval. The codes of the two devices within each sub-interval are then compared. If the codes differ in any sub-interval, the devices are considered inconsistent. This method reduces the number of queries and improves computational efficiency.

[0043] Compared to existing technologies that only compare wear segment codes at the initial moment, the above operation requires that the wear segment code sequences be completely consistent throughout the entire overlapping period. This physically eliminates the following typical mismatch scenarios: one piece of equipment is in a sharp segment in the first half of the overlapping period and enters a stable segment in the second half, while another piece of equipment remains in the sharp segment throughout. Although their initial codes are the same, the tooling wear state differs during actual parallel execution, potentially leading to inconsistent processing quality. This step excludes such cases from candidate parallel operation modes, ensuring that the parallel modes ultimately stored in the knowledge base have strict temporal physical equivalence. Verified by actual production line data, this mechanism effectively reduces the pattern mismatch rate caused by tooling lifespan changes and improves the reliability of recommendation results generated by the large model based on the knowledge base.

[0044] S2.4: Jointly executed task pairs that simultaneously meet the following two conditions are marked as candidate parallel operation modes: the wear segment codes of the two scheduling instances are the same at their respective start times; the wear segment code sequences of the two scheduling instances are completely identical throughout the entire overlapping time interval, i.e., they are the same at any time.

[0045] It should be noted that in actual industrial production, a long-duration scheduling instance may cross the boundary of tooling wear stages. If two instances are assumed to be able to operate in parallel simply because they start at the same time, it may result in the actual wear states of the two toolings differing in the latter half of the overlapping period, leading to differences in processing quality. This embodiment ensures that the two toolings are always at the same wear stage throughout the parallel execution through time-duration consistency verification, thereby guaranteeing the physical equivalence of parallel operations.

[0046] Furthermore, only scheduling instance pairs that pass the time-period consistency check are converted into knowledge entries and stored in the large model's knowledge base. This makes the recommendations obtained by the subsequent large model when retrieving parallel operation modes more reliable and repeatable, reducing abnormal recommendations caused by changes in tooling wear and tear.

[0047] It should also be noted that, through the sub-interval partitioning method based on jump points, this embodiment avoids exhaustive sampling, reduces computational overhead while ensuring accuracy, and is suitable for offline or online processing of large-scale scheduling logs.

[0048] S3: Map instances in candidate parallel operation modes to knowledge entries, obtain metadata and upstream source entries for each knowledge entry, and detect attribute conflicts.

[0049] It should be noted that step S3 in this embodiment is used to convert the two scheduling instances in the candidate parallel operation modes marked in S2 into structured knowledge entries, and to perform conflict detection based on the metadata tags and the attributes of the upstream source entries. The core is to establish a lossless mapping from scheduling instances to knowledge entries, and to identify parallel modes that, although overlapping in time and having the same wear and tear periods, conflict at the business rule or data lineage level, thereby avoiding the writing of invalid or contradictory knowledge into the knowledge base. The specific operations are as follows:

[0050] S3.1: For each candidate parallel operation mode output, the mode contains two scheduling instances. In this embodiment, each scheduling instance is converted into a knowledge entry, which is a structured data record that includes at least an instance identifier, a device identifier, a start time, an end time, and a wear segment code.

[0051] It should be noted that knowledge entries can be stored as a single row in a relational database, a JSON object, or a collection of key-value pairs. In this embodiment, knowledge entries are temporarily stored in a candidate knowledge list in memory, and a decision is made on whether to write them to the persistent knowledge base after conflict detection.

[0052] S3.2: For each knowledge entry generated, this embodiment performs the following operations: First, based on the device identifier and start time of the knowledge entry, or more generally, based on the process information associated with the scheduling instance, query the metadata key-value pair set corresponding to the knowledge entry from the metadata management module.

[0053] The metadata management module is a centralized or distributed metadata storage system that maintains descriptive tags for all entities such as scheduling instances, devices, and processes.

[0054] Specifically, in this embodiment, the metadata key-value pair set contains at least the following three metadata items: device type tag (used to describe the major category of the execution device), process type tag (used to describe the specific process executed by the scheduling instance), and tooling lifespan range tag.

[0055] The tooling lifespan interval label takes values ​​such as initial, middle, and final stages. This label has a mapping relationship with the wear segment code, but it is not completely equivalent. That is, the tooling lifespan interval label is more inclined towards the classification at the business semantic level, while the wear segment code is based on a physical threshold division based on the cumulative usage time. For example, the initial stage corresponds to the sharp segment in the wear segment code, and the middle stage corresponds to the stable segment in the wear segment code.

[0056] The mapping relationship is configured by default, and the lifespan threshold and corresponding semantic tags can be adjusted through the configuration file according to the actual tooling type. When defining conflict rules, wear segment codes (physical layer) or tooling lifespan interval tags (semantic layer) can be used independently, but the two should not be mixed in the same rule to avoid ambiguity.

[0057] Furthermore, the query interface of the metadata management module should support returning complete metadata key-value pairs based on the device identifier and time point (or process identifier). If a necessary tag is missing from the query result, the knowledge entry is marked as having incomplete metadata, and subsequent conflict detection is terminated. The candidate parallel operation mode is directly considered invalid as a whole, or the default value is selected according to the configuration, but in this embodiment, it is preferred to discard it.

[0058] As can be seen, managing metadata as tag key-value pairs allows conflict rules to be flexibly defined based on business semantics.

[0059] S3.3: For each knowledge entry generated, this embodiment further obtains its upstream source entry record.

[0060] Among them, the upstream source entry refers to the original triggering event or preceding task record that caused the scheduling instance to be generated, which reflects the data lineage of the scheduling instance.

[0061] Specifically, based on the device identifier and start time of the knowledge entry, or based on the unique identifier of the scheduling instance, the upstream source entry record that generated the scheduling instance is queried from the data lineage module. The data lineage module records the source of each scheduling instance, for example: When the upstream source entry type is a trigger event, it may include sensor signals, operator manual instructions, external system API calls, etc.; when the upstream source entry type is a preceding task, it may include the completion record of the previous process, the completion record of the material preparation task, etc.

[0062] The data lineage module is constructed as follows: each time the task orchestration system generates a new scheduling instance, it simultaneously records the trigger source identifier and trigger source type of that instance. The trigger source identifier points to the specific event or task record that generated the instance. For example, if the scheduling instance is triggered by a sensor signal, the trigger source identifier is the event ID of that sensor signal; if it is triggered by the completion of a previous process, the trigger source identifier is the instance identifier of the previous scheduling instance. The data lineage module is stored in the form of a relational table, and the table structure includes at least the scheduling instance identifier, trigger source identifier, trigger source type, and record timestamp. During querying, the corresponding trigger source identifier and trigger source type are directly read using the scheduling instance identifier as the key. Then, based on the trigger source type, the complete source entry record is read from the corresponding event table or task table, including the source entry identifier, source entry type, and priority level. The priority level is determined by the preset attributes of the upstream task or event. For example, in the task orchestration system, a priority is predefined for each task type: emergency repair tasks have a high priority, routine quality inspection tasks have a medium priority, and data acquisition tasks have a low priority.

[0063] If the scheduled instance is a system-initialized instance or a manually created instance without a trigger source, the trigger source identifier field of that instance in the data lineage module is set to NULL, and an empty record is returned when querying.

[0064] In this embodiment, each upstream source entry record contains at least the following three attributes: source entry identifier, source entry type, and source entry priority level.

[0065] If the data lineage module cannot find the upstream source entry of a knowledge entry, for example, if the instance is the baseline instance during system initialization, then the upstream source entry record of the knowledge entry will be set to empty, and the rules related to the attributes of the upstream source entry will be skipped in subsequent conflict detection.

[0066] It should be noted that, based on data lineage information, this embodiment of the invention enables conflict detection to consider the cause and context of the scheduling instance's creation. For example, if a scheduling instance is triggered by a high-priority event, while another parallel scheduling instance is triggered by a low-priority task, and both share the same device or tooling, a resource conflict rule may be triggered. This lineage-based conflict detection is more refined and accurate than methods based solely on time or device.

[0067] S3.4: In this embodiment, a conflict rule table is predefined, for example, stored in a database table or configuration file. Each rule in the conflict rule table is defined using the following logical form: If the metadata tag name of a knowledge entry is X and the value of the tag is A, and the attribute name of the upstream source entry of the knowledge entry is Y and the value of the attribute is B, then the knowledge entry is determined to be in conflict, and the conflict number is R.

[0068] For example, the conflict rules may include: Rule R001: If the operation type label of a knowledge entry is "milling" and the priority level of the upstream source entry is "high", then a conflict is determined. That is, high-priority milling tasks are not allowed to run concurrently with any other tasks to avoid excessive spindle load. Rule R002: If the device type label of a knowledge entry is "robot" and the source entry type of the upstream source entry is "EVENT", then a conflict is determined. That is, event-triggered robot tasks typically require exclusive operating space and should not run concurrently with other tasks.

[0069] It should be noted that the rules in the conflict rule table can be pre-configured by technical personnel according to actual production safety specifications or equipment operating procedures, and dynamic addition, deletion, modification, and querying are supported. This embodiment does not limit the specific number and content of the rules, only requiring that each rule clearly specify the metadata tag name and value, the upstream source entry attribute name and value, and the conflict number.

[0070] S3.5: For each knowledge entry in the candidate parallel operation mode, that is, the knowledge entry corresponding to each of the two scheduling instances, this embodiment performs the following conflict detection process: S3.5.1: Obtain the metadata key-value pair set of the knowledge entry from S3.2, including the tag name and its corresponding value. Obtain the attribute key-value pair set of the upstream source entry record of the knowledge entry from S3.3, including the attribute name and its corresponding value. If the upstream source entry record is empty, then in subsequent checks, any rule conditions involving the attributes of the upstream source entry will be considered unsatisfied, i.e., no conflict will be triggered.

[0071] S3.5.2: Read each rule in the conflict rule table one by one. For the current rule, extract the metadata tag name X and expected value A specified in the rule, as well as the upstream source entry attribute name Y and expected value B.

[0072] S3.5.3: First, check if there is an item with the tag name X and the value A in the metadata key-value pair of this knowledge entry. If not, skip the current rule and continue to the next one.

[0073] Secondly, if the above match exists, the system further checks whether there is an item with the attribute name "Y" and the value "B" in the attribute key-value pair of the upstream source entry of the knowledge entry. If it exists, it is determined that the current knowledge entry has triggered the current rule.

[0074] S3.5.4: When a rule is triggered, this embodiment generates a conflict record, which contains at least the following information: the knowledge entry identifier that triggers the conflict, i.e., the instance identifier, the conflict rule number that is triggered, such as R001; the name and specific value of the metadata tag that is matched in the triggering condition, and the name and specific value of the upstream source entry attribute that is matched in the triggering condition.

[0075] If a knowledge entry triggers multiple rules simultaneously, record all conflicting rule numbers and their corresponding details.

[0076] S3.5.5: For the current candidate parallel operation mode, this embodiment checks whether at least one of the two knowledge entries triggers at least one conflict rule. If so, the candidate parallel operation mode is marked as a conflict mode as a whole, and all conflict records are aggregated. If neither of the two knowledge entries triggers any conflict rule, the mode is marked as a conflict-free mode.

[0077] It should be noted that the above operations not only detect the existence of conflicts, but also pinpoint the specific knowledge entry that violates which rule and which metadata or lineage attributes are involved, providing sufficient information for subsequent maintenance terminal pushes. Furthermore, by individually detecting each knowledge entry in the candidate parallel operation modes, it is ensured that if any one of them has an attribute conflict, the entire parallel mode will not be adopted, thus guaranteeing the security and consistency of the parallel operation modes stored in the knowledge base in terms of business semantics.

[0078] Compared to static conflict detection methods based solely on device identifiers or time windows, the above operation combines the business attributes of upstream source entries with metadata tags, enabling the discovery of deep semantic conflicts. For example, a milling task triggered by a high-priority event and a measurement task triggered by a regular task may overlap in time and the devices may not conflict. However, production safety regulations stipulate that the high-priority milling task must exclusively occupy spindle resources and cannot run concurrently with any other task. Existing detection methods based on device mutual exclusion cannot identify such conflicts, while this step can accurately detect them through rules. This capability allows the knowledge base to retain only parallel patterns permitted by business rules, avoiding the provision of patterns that violate safety regulations or process specifications to the large model, thereby improving the business compliance of the knowledge base.

[0079] S4: If no conflict is detected, the candidate parallel operation mode is converted into a parseable encoding string of the large model and stored in the knowledge base; if a conflict is detected, an update record with wear segment encoding is generated and pushed to the maintenance terminal.

[0080] It should be noted that in this embodiment, step S4 executes two mutually exclusive branches based on the pattern-level conflict determination result output by S3.5.5: when a candidate parallel operation mode is marked as a conflict-free mode, it is converted into a structured encoding string for large model pre-training or fine-tuning design and written into the formal storage area of ​​the knowledge base; when it is marked as a conflict mode, an update record containing complete context information is generated and pushed to the maintenance terminal for manual review or rule correction. The specific operations are as follows: S4.1: Generate encoded strings and write them to the knowledge base in conflict-free mode.

[0081] S4.1.1: When a candidate parallel operation mode is marked as a conflict-free mode, this embodiment extracts the following five fields from two scheduling instances in this mode: instance identifier, device identifier, wear segment code, start time, and end time. The values ​​of each field are converted to string format in a fixed order and concatenated using commas as delimiters to form the original string.

[0082] Specifically, let the instance identifier of scheduling instance A be... The device identifier is The wear segment is coded as The starting time is (Convert to ISO8601 format or millisecond timestamp string), end time is The corresponding field for scheduling instance B is: , , , , The format of the original string is: , , , , , , , , , .

[0083] In a preferred implementation of this embodiment, to avoid ambiguity caused by commas within field values, all field values ​​are escaped before concatenation: commas appearing in the field values ​​are replaced with %2C, and newline characters are replaced with %0A. Furthermore, time fields are uniformly represented in milliseconds starting from the Unix epoch to ensure ease of numerical comparison.

[0084] After concatenating the original strings, this embodiment adds a fixed header identifier, PARA_MODE, to the very beginning of the string to distinguish it from other types of knowledge entries. The final encoded string format is as follows: PARA_MODE: , , , , , , , , , .

[0085] The encoded string is presented in plain text form and does not depend on any specific programming language or serialization framework. Therefore, it can be directly used as an input sequence for parsing or training by various large models (such as GPT, BERT, LLaMA, etc.).

[0086] S4.1.1a: After generating the basic encoded string, this embodiment further calculates a quantitative index reflecting the degree of synchronization of wear segment encoding changes between two scheduling instances during overlapping time periods, called the time consistency score. The score ranges from 0 to 100, with higher values ​​indicating more aligned wear segment encoding transition times between the two instances.

[0087] Specifically, the calculation steps are as follows: First, obtain the set of wear segment encoding change time points for the first and second devices within the overlapping time interval. Each change time point refers to the device's cumulative usage time exceeding a preset physical lifespan threshold.

[0088] Specifically, the tooling status history database stores the status of each piece of equipment at discrete points in time series, such as the cumulative usage time and corresponding wear segment code recorded after each completed workpiece. To accurately calculate the changing time points, a linear interpolation method is used; for example, when the equipment is at time... The recorded cumulative usage time is The wear segment is coded as C1; at the next recording time... The recorded cumulative usage time is The wear segment is coded as C2, and C1 ≠ C2. Then the time point of change is: ; in, The lifetime threshold that causes a change in encoding, such as when transitioning from a sharp segment to a stable segment. =0.3 If the historical database sampling frequency is high enough, for example, one record per item, and the processing time of a single item is less than 1% of the total lifespan, then the midpoint between two recorded times can be directly taken as an approximation of the change time point, with an error not exceeding one sampling period. The set of change time points within overlapping intervals only retains points falling within or on the boundaries of the overlapping intervals. If the linear interpolation result has a large error, the sampling frequency can be increased, or the change time point can be marked as unreliable and ignored.

[0089] Secondly, the sets of change time points for the two devices are merged, deduplicated, and arranged chronologically. For each merged change time point, it is checked whether the wear segment codes of the two devices before and after that time point have undergone the same jump, i.e., from the same old code to the same new code. If the jump is the same, the point is marked as an alignment point; if neither device has a jump at that point or the jump direction is different, it is marked as an misalignment point. The proportion of the number of alignment points to the total number of all change time points is calculated. If the total number of change time points is zero, i.e., neither device has undergone a code jump during the overlapping period, the consistency score is directly assigned a value of 100.

[0090] Finally, multiply the above ratio by 100 and round down to obtain the time consistency score. For example, if there are 4 changing time points within the overlapping period, and 3 of them are alignment points, the score is 75.

[0091] S4.1.1b: Add a separator, such as a semicolon, to the end of the original base code string; and a time consistency score.

[0092] It should be noted that this score, as part of the parsable encoded string of the large model, can be used as the weight or confidence of samples during the training of the large model. Parallel modes with higher scores are more likely to be learned first. Furthermore, during the inference of the large model, it serves as the basis for recommendation ranking, prioritizing the recommendation of parallel modes with high consistency scores.

[0093] The time consistency score is a preferred implementation method but not mandatory. If the score is not calculated, no semicolon or score will be added to the end of the encoded string.

[0094] As can be seen, this invention not only records the existence of parallel operation modes but also quantifies the quality of these modes in terms of the synchronicity of tooling wear segment changes. This compensates for the shortcomings of traditional knowledge bases that only store binary relations (whether parallel or not). In actual production, even if two devices have identical wear segment codes during overlapping periods, the degree of deviation in their transition times can still affect the coordination of actual processing. For example, one device might transition from a sharp segment to a stable segment in the first tenth of the overlapping period, while another device might only undergo the same transition in the last tenth of the overlapping period. Although the codes are identical throughout the entire period, the wear segments of the two devices are out of sync for most of the time. This scoring system can encode such subtle differences for use by large models or downstream systems. Production line testing showed that after adding the scoring system, the task conflict rate of large models when recommending parallel operations decreased, and the maintenance efficiency of the knowledge base was improved.

[0095] S4.1.2: Write the generated encoded string as a record into the formal storage area of ​​the knowledge base. In this embodiment, the knowledge base is a hybrid knowledge base supporting both vector retrieval and text retrieval, such as one built on Elasticsearch or Milvus. During writing, each record must contain at least the following fields: knowledge type, encoded string, timestamp, and source information.

[0096] Among them, the knowledge type is fixed as PARALLEL_MODE for fast filtering; the source information is a list of original scheduling instance identifiers corresponding to the candidate parallel operation modes that generated the encoded string, so as to trace the source.

[0097] Before writing, this embodiment can perform a deduplication check: using the sorted combination (small to large order) of the two instance identifiers as the key, query the knowledge base to see if the exact same parallel operation pattern encoding string already exists. If it already exists, skip the writing and update the timestamp of the existing record, indicating that the pattern has been verified as valid again; if it does not exist, perform the insertion operation.

[0098] It should be noted that the embodiments of the present invention use text encoding strings separated by simple delimiters, eliminating the need for complex structured parsers. Large models can directly understand the components of parallel operation modes within the context, making it suitable for constructing data with few-sample hints or fine-tuning. Furthermore, the encoding strings in the embodiments of the present invention contain complete instance identifiers, allowing for the subsequent querying of the scheduling log table to reconstruct all information of the original scheduling instance, achieving a reverse mapping from encoding to original data.

[0099] S4.2: Perform conflict record aggregation.

[0100] S4.2.1: When a candidate parallel operation mode is marked as a conflict mode, this embodiment first collects all conflict records under that mode. Each conflict record includes: the knowledge entry identifier that triggers the conflict, i.e., the instance identifier of the scheduling instance, the conflict rule number that triggers the conflict, the metadata tag name and specific value that triggers the conflict, and the attribute name and specific value of the upstream source entry that triggers the conflict.

[0101] Since a candidate parallel operation mode contains two knowledge entries, and each knowledge entry may trigger multiple rules, this embodiment aggregates all conflict records into a conflict record list.

[0102] S4.2.2: In this embodiment, a structured update record is generated based on the aggregated list of conflict records. The update record includes at least the following fields: a list of conflicting knowledge item identifiers, i.e., instance identifiers of the two knowledge items, arranged in their original order; a list of deduplicated rule numbers that trigger conflicts; the complete encoded string of the candidate parallel operation mode; the wear segment code for each knowledge item that triggers a conflict; and conflict details.

[0103] The conflict details are a list of conflict records from S4.2.1 embedded in JSON or key-value pair format.

[0104] In addition, the update record can be appended with the following optional fields: the timestamp of the current attempt to write, the source of the candidate parallel operation mode (such as the time range of the scheduling log), and the suggested operation.

[0105] S4.2.3: Push the update record generated in S4.2.2 to one or more maintenance terminals via message queue or REST API call. After pushing, this embodiment prohibits writing the encoded string of the candidate parallel operation mode into the formal storage area of ​​the knowledge base. However, this embodiment may choose to write the update record and the corresponding original scheduling instance pair into a separate conflict archive for subsequent statistical analysis, such as identifying which conflict rules are triggered most frequently and assisting in optimizing rule thresholds.

[0106] S4.3: In the complete implementation of this embodiment, step S4 further includes the following auxiliary operations: If the write operation fails due to network failure or unavailability of the knowledge base service, the encoded string will be temporarily stored in the local persistent queue and retried periodically. If the write operation fails after three retries, an error log will be recorded and the write operation will be abandoned. If the push operation fails due to the unreachability of the maintenance terminal, the update record will be written to the local dead letter queue and an alarm signal will be issued.

[0107] All write or push operations generate structured logs, including timestamps, candidate parallel operation mode identifiers, execution results (success / failure / conflict), and reasons for failure, for auditing and debugging purposes.

[0108] Figure 3 This is a schematic diagram of an electronic device used to implement the automated construction and updating method for a large-scale model knowledge base in the industrial manufacturing field, as described in this embodiment of the invention. The electronic device is intended to represent various forms of digital computers, such as laptops, desktop computers, workbenches, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0109] like Figure 3As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from storage unit 18. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0110] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0111] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, central processing unit (CPU), graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the automated construction and updating methods for large model knowledge bases in the industrial manufacturing field.

[0112] In some embodiments, the method for automatically constructing and updating a large model knowledge base in the industrial manufacturing field can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the method for automatically constructing and updating a large model knowledge base in the industrial manufacturing field described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to execute the method for automatically constructing and updating a large model knowledge base in the industrial manufacturing field by any other suitable means (e.g., by means of firmware).

[0113] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0114] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0115] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0116] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0117] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0118] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0119] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0120] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. An automatic construction and update method of a large model knowledge base in the field of industrial manufacturing, characterized in that, The method comprises the following steps: extracting time-overlapping scheduling instance pairs from a task arrangement system and recording the device identifiers associated with each scheduling instance; reading the wear segment code of the corresponding device from the tooling state history library according to the start time of each instance, and checking whether the wear segment codes of the two scheduling instances at each time in the overlapping time interval remain the same, retaining only the scheduling instance pair whose wear segment codes at the start time are the same and the wear segment codes remain consistent throughout the overlapping interval as a candidate parallel operation mode; mapping the instances in the candidate parallel operation mode into knowledge entries, obtaining the metadata and upstream source entries of each knowledge entry, and detecting attribute conflicts; if no conflicts are detected, converting the candidate parallel operation mode into an encoding string that can be parsed by the large model and storing it in the knowledge base; if a conflict is detected, generating an update record with the wear segment code and pushing it to the maintenance terminal.

2. The method of claim 1, wherein the method further comprises: The method comprises the following steps: reading the start time, end time and device identifier associated with each scheduling instance from the scheduling log table of the task arrangement system; calculating the overlapping length of the time interval formed by the start time and end time of any two scheduling instances, and recording the two scheduling instances with an overlapping length greater than zero as a joint execution task pair.

3. The method of claim 1, wherein the method further comprises: The method comprises the following steps: for each scheduling instance in the joint execution task pair, reading the wear segment code of the corresponding device at the start time of each scheduling instance from the tooling state history library according to the device identifier of each scheduling instance and the start time of each scheduling instance; the wear segment code is divided into sharp segment, stable segment and declining segment according to a preset physical life threshold; comparing the wear segment codes of the two scheduling instances at the start time in the joint execution task pair, and retaining only the joint execution task pair whose wear segment codes at the start time are completely the same; for the joint execution task pair with the same wear segment code at the start time, checking whether the wear segment codes of the two scheduling instances remain the same throughout the overlapping time interval; if the wear segment codes of the two scheduling instances are different at any time within the overlapping interval, discard the joint execution task pair; marking the joint execution task pair that meets the conditions of the same start time code and consistent code throughout the overlapping period as a candidate parallel operation mode.

4. The method of claim 1, wherein the method further comprises: The method comprises the following steps: converting each scheduling instance in the candidate parallel operation mode into a knowledge entry, which includes instance identifier, device identifier, start time, end time and wear segment code; wherein the wear segment code is taken from the wear segment code at the start time of the scheduling instance.

5. The method of claim 4, wherein the method further comprises: The method comprises the following steps: for each knowledge entry, obtaining a set of metadata key-value pairs from the metadata management module; the set of metadata key-value pairs includes at least the following metadata items: device type label and its value, process type label and its value, tooling life interval label and its value.

6. The method of claim 5, wherein the method further comprises: The method comprises the following steps: For each knowledge entry, based on the device identifier and start time of the knowledge entry, query the data lineage module to generate the upstream source entry record for that scheduling instance; The upstream source entry record includes at least the source entry identifier, source entry type, and source entry priority level.

7. The method of claim 6, wherein the method further comprises: The detected attribute conflicts include: A conflict is determined when a specified metadata tag of a knowledge entry takes a specific value, and a specified attribute of the upstream source entry of the knowledge entry takes a specific value; For each knowledge entry, obtain all metadata key-value pairs of the knowledge entry and all attribute key-value pairs of the upstream source entries of the knowledge entry; Traverse each rule in the conflict rule table, check if there is a tag value pair in the metadata key-value pair of the knowledge entry that matches the rule conditions, and at the same time check if there is an attribute value pair in the attribute key-value pair of the upstream source entry that matches the rule conditions. If both match, the knowledge entry is determined to be in conflict, and the conflict location is recorded as the knowledge entry identifier and the conflict rule number.

8. The method of claim 7, wherein the method further comprises: If no conflict is detected, the candidate parallel operation mode is converted into a parseable encoding string for the large model and stored in the knowledge base, including: When neither of the two knowledge entries in the candidate parallel operation mode triggers any conflict rules, the instance identifier, device identifier, wear segment code, start time, and end time of the two scheduling instances in the candidate parallel operation mode are concatenated in sequence with commas as separators, and a header identifier is added before the concatenation result to obtain the encoded string. The encoded string is written into the formal storage area of ​​the knowledge base.

9. The method for automated construction and updating of a large-scale model knowledge base in the industrial manufacturing field according to claim 7, characterized in that, When any knowledge entry in the candidate parallel operation mode triggers at least one conflict rule, all conflict records are collected. Each conflict record includes the knowledge entry identifier that triggered the conflict, the rule number that triggered the conflict, the metadata tag name and value that triggered the conflict, and the attribute name and value of the upstream source entry that triggered the conflict. Based on the collected conflict records, an update record is generated, which includes the identifiers of the two knowledge entries that triggered the conflict, a list of all rule numbers that triggered the conflict, the complete encoding string of the candidate parallel operation mode, and the wear segment encoding of each knowledge entry that triggered the conflict. The update record is pushed to the maintenance terminal, and the writing of the candidate parallel operation mode to the knowledge base is prohibited.

Images