A method for verifying the consistency of hardware PDF files with component models in the BOM.

Abstract

This invention provides a method for verifying the consistency of device models between a hardware PDF file and a Bill of Materials (BOM), comprising the following steps: parsing the hardware PDF file to obtain a set of evidence blocks including at least one evidence block per page of the PDF; extracting traceable device models from the hardware PDF file; generating a PDF scheme baseline list based on the corresponding traceable device models and device quantities; identifying valid rows and columns in the BOM file; identifying the quantity of materials within valid material rows and aggregating valid material row data of the same model to obtain a BOM aggregate list; and using the PDF scheme baseline list as a benchmark, performing model matching and quantity consistency verification on the PDF baseline models and the BOM aggregate models to obtain a consistency verification result.

Description

Technical Field

[0001] This invention relates to the field of BOM review, and in particular to a method for reviewing the consistency between hardware PDF files and device models within the BOM. Background Technology

[0002] In the hardware product development process, the hardware design scheme is usually formed first based on project requirements and then solidified into a hardware PDF file. The schematic design is then completed based on the design scheme, and finally the bill of materials (BOM) is derived from the schematic. This serves as the core basis for component procurement, production assembly, cost accounting, and project delivery. The key component models and corresponding quantities required in the hardware PDF file must be consistent with the component specifications and procurement quantities in the BOM. This is the core review process to ensure the consistency of design implementation and avoid errors in production materials.

[0003] In actual project execution, as hardware design complexity continues to increase, there is often a disconnect between solution iteration, schematic adjustments, and BOM updates. This frequently leads to issues such as component selection changes not being updated in sync, omission of key components, and non-standard schematic modifications. Traditional manual verification methods are inefficient and incomplete in identifying these problems: Firstly, component models in hardware PDF files are scattered across various formats, including block diagrams, text descriptions, parameter tables, figure annotations, and design comments, and may contain outdated models from previous versions or have minor differences in component suffixes, making manual checking prone to oversights. Secondly, projects often involve cross-checking multiple versions of hardware PDF files and multiple BOM files, making manual comparison extremely inefficient and labor-intensive, and prone to omissions and errors, thus failing to guarantee the quality and efficiency of the review process.

[0004] While existing technologies include PDF document structure recognition, BOM table parsing, component library management, and BOM version comparison, none of them are well-suited for scenarios involving PDF solutions and BOM consistency review. Their main shortcomings are as follows: 1. General PDF recognition and structuring tools only focus on the extraction and formatting of general text, tables, and annotations. They do not have a professional identification and filtering mechanism for electronic component models for hardware solution scenarios. They are very likely to misidentify circuit network names and signal interface names such as VCC_3V3, POWER_IN, and FPGA_VCC as component models. The recognition accuracy cannot meet the requirements of professional review.

[0005] 2. Traditional BOM comparison or version comparison systems use two structured BOM files as the comparison objects, which cannot adapt to cross-format comparison scenarios of "unstructured / semi-structured PDF solution files and one or more structured BOM files"; conventional table matching scripts can only process structured data with fixed fields and cannot parse the scattered and non-standardized model descriptions and quantity information in PDFs, and do not have the ability to review solutions at the solution level.

[0006] 3. The approach of directly reading PDFs from general large models and outputting review conclusions lacks a strict original text evidence constraint mechanism. It generally suffers from problems such as fictitious device models in the model, omission of key materials, inability to trace the original text location in the review results, unverifiable quantity inference logic, and non-standard output format. It is difficult to meet the rigid requirements of hardware design review for accuracy, traceability, and auditability.

[0007] Therefore, there is an urgent need for a technical solution that can quickly and accurately verify the consistency between hardware PDF files and device models in the BOM. Summary of the Invention

[0008] The purpose of this invention is to provide a method for verifying the consistency between hardware PDF files and component models in the BOM, thereby enabling rapid and accurate consistency verification between hardware PDF files and component models in the BOM.

[0009] To achieve the above objectives, this technical solution provides a method for verifying the consistency of device models between hardware PDF files and BOMs, including the following steps: S1: Parse the hardware PDF file to obtain an evidence block set including at least one evidence block per page of the PDF. Extract the traceable device model from the hardware PDF file. Calculate the device quantity of the traceable device model based on the number of times the evidence block appears and the explicit quantity identifier. The number of times the evidence block appears is the number of times the traceable device model appears in different evidence blocks. The explicit quantity identifier is a string that can directly represent the quantity near the traceable device model. Generate a PDF scheme benchmark list based on the corresponding traceable device model and device quantity. Each PDF benchmark model in the PDF scheme benchmark list includes benchmark information including the suggested quantity for the corresponding traceable device model. S2: Identify the valid rows and columns of the BOM file. Valid rows include header rows and material rows. Valid columns include model, quantity, tag number, and material number columns. Identify and filter to obtain valid material rows. Identify the material quantity within the valid material rows and aggregate the valid material row data of the same model to obtain the BOM aggregate list. Each BOM aggregate model in the BOM aggregate list includes the aggregation information of the corresponding target material. S3: Based on the PDF solution baseline list, perform model matching and quantity consistency review on the PDF baseline model and the BOM aggregated model to obtain the consistency review results.

[0010] Compared with existing technologies, this technical solution has the following characteristics and beneficial effects: (1) Unlike traditional solutions that treat the full text of a PDF as ordinary text and cannot locate the source of the extracted results, this solution first parses the hardware PDF file page by page into a set of evidence blocks containing multiple independent semantic text units, and simultaneously establishes a page text index, recording the page number, text content, evidence block number, page coordinates, and reading order of each evidence block. All traceable device models, quantity clues, context descriptions, and final review conclusions obtained from the identification can be bound to the corresponding evidence blocks to achieve full-chain traceability. This mechanism solves the pain point of traditional PDF text recognition that "it can only extract strings and cannot locate the source, trace the context, or verify the authenticity of the original text," making the review results of the hardware PDF file and BOM have engineering reviewability. Engineers can quickly backtrack and verify the results based on the page numbers, evidence block numbers, and original text fragments in the report, avoiding the review results becoming an unexplainable black box judgment.

[0011] (2) To address the issue that device model numbers in hardware PDF files are easily split into multiple lines due to layout, table width, line breaks, or format conversion, leading to incomplete model number extraction and subsequent matching failures, this solution introduces a line merging preprocessing mechanism based on multi-evidence weighted rules before model number extraction. The system calculates the weighted score of adjacent text lines using four types of positive evidence: hyphen continuation evidence, slash continuation evidence, short suffix completion evidence, and knowledge base known model protection evidence. At the same time, negative suppression conditions are introduced to calculate suppression terms, comprehensively determining whether adjacent lines need to be merged. Compared with a single continuation rule, this mechanism can significantly improve the complete extraction rate of long model numbers, model numbers with package / order suffixes, and multi-line split model numbers. At the same time, negative suppression effectively avoids incorrectly concatenating non-model content such as VCC and GND into device model numbers, reducing the probability of incorrect merging.

[0012] (3) Unlike solutions that rely solely on regular expressions for extraction or general AI models that directly output conclusions, this solution's model identification model is deeply involved in the device model extraction process, and the output results are strictly constrained by the original evidence in the hardware PDF file. The system inputs the evidence block text into the pre-trained model identification model in the form of a sliding window. The model output includes the device model, candidate category, quantity expression, page number, evidence block number, and the model output candidates of the original evidence. At the same time, it can distinguish between real device models and non-model objects such as power network names, interface signal names, functional module names, and parameter values. Compared with a single regular expression extraction method, this method can effectively adapt to the complex layout scenarios of hardware solution PDFs, and significantly improve the model extraction accuracy in complex scenarios.

[0013] (4) Unlike schemes that rely on a single rule extraction, a single model recognition, or a single database matching, this scheme does not depend on a single information source to determine the device model. Instead, it generates candidate device models by using a rule extractor and candidate device models by using a model recognition model. These are then combined with verification from the enterprise knowledge base and normalized before being merged into a unified candidate device model, which carries full-dimensional information in the form of candidate nodes. This mechanism takes the candidate device model node as its core, binding the original PDF evidence, extraction source, contextual semantics, quantity clues, and knowledge base hit information, serving as an intermediate object for generating the PDF scheme benchmark list and conducting consistency reviews.

[0014] (5) Unlike the binary judgment mode of "hit / miss" in traditional document / BOM recognition, this solution upgrades device model recognition to a continuous confidence assessment with multi-dimensional evidence weighting, calculating a comprehensive confidence score for each candidate node. The comprehensive confidence score integrates seven positive scores: rule form score, AI model score, PDF original text evidence score, context semantic score, knowledge base hit score, quantitative evidence score, and multi-source consistency score. At the same time, it superimposes three negative penalties: exclusion word penalty, network name penalty, and rule and model conflict penalty. After weighted calculation and mapping, a confidence score result in the range of 0 to 1 is obtained. This comprehensive confidence score is not the classification probability of a single model, but the comprehensive evidence credibility for hardware device review scenarios. The system can automatically include high-confidence models and exclude low-confidence interference items based on the confidence score threshold, and push medium-confidence models for manual confirmation. Moreover, each judgment is supported by corresponding evidence, significantly improving the transparency, interpretability, and auditability of the review results.

[0015] (6) To address the issues of model number generation, unlocatable evidence, and unverifiable results that arise when directly processing documents using general large models, this solution performs original text evidence constraint verification on all output candidates of the model identification model, retaining only model candidate device models that meet the original text constraints. The verification dimensions cover five aspects: existence of evidence fragments, model mention location, normalization rationality, category legality, and evidence block location. This mechanism strictly limits the model's free generation space and forces the model output to accept original text verification, format verification, and category verification. From a mechanism perspective, it avoids the risk of AI generating model numbers and expanding information, ensuring the reliability of PDF model extraction results and meeting the stringent requirements of hardware R&D review for accuracy and traceability.

[0016] (7) Unlike solutions that only extract text content and compare structured quantity fields, this solution addresses the unstructured nature of PDF solutions and the tendency for model numbers to repeat. It constructs a dual-dimensional logic for inferring device quantity based on "the number of times evidence blocks appear and explicit quantity identifiers," supporting dual consistency review of model and quantity. The system counts the number of times traceable device models appear in different evidence blocks to avoid over-counting caused by repeated descriptions in the same paragraph or table cell. Simultaneously, it detects explicit quantity identifiers in the model context window and filters out interfering numbers such as voltage, current, parameters, and version numbers through validity rules. Quantity calculation follows the principle of "explicit quantity identifiers first, evidence block occurrence counts as supplement." When there is a conflict between the two, it is marked as "quantity needs confirmation" and pushed for manual verification. This mechanism is more stable than simply relying on AI natural language to infer quantities and is more in line with the actual logic of hardware solution review than simply counting the number of times strings appear. It can accurately generate suggested quantities on the PDF solution side, providing a reliable benchmark for subsequent quantity consistency review.

[0017] (8) This solution uses the confirmed PDF solution baseline list as the review benchmark and conducts a full-dimensional consistency comparison with single or multiple BOM aggregate lists. On the BOM side, the system can automatically identify the header row and model column, quantity column, tag number column, and material number column, adapting to the differences in BOM templates for different projects; it obtains valid material rows by filtering through material number prefixes, prioritizes quantity column values ​​for quantity reading, and supplements the quantity column by tag number parsing when the quantity column is abnormal, and finally generates a BOM aggregate list by aggregating similar materials according to normalized model, retaining the original traceability information throughout the process. In the matching review stage, a multi-level matching strategy is adopted, including exact matching, alias matching, main model matching, and suffix difference matching, and the matching relationship is determined according to priority; the quantity consistency verification is carried out simultaneously, and multiple review statuses are output, such as consistent, acceptable consistent, inconsistent quantity, missing BOM, redundant BOM, and suffix difference requiring confirmation, which can comprehensively cover various abnormal scenarios such as missing BOM, redundant BOM, model suffix difference, and inconsistent quantity.

[0018] (9) Unlike tools that only identify once and have no continuous optimization capabilities, this solution constructs a closed-loop optimization system of "review - manual confirmation - knowledge base iteration - re-review". The manual confirmation results of engineers are fed back to the enterprise knowledge base to continuously improve system performance. This mechanism is not a simple database update, but directly transforms human experience into scoring and matching rules in the review process. As the frequency of use increases, the system will gradually accumulate the enterprise's exclusive device identification experience and rules, continuously reducing the false recognition rate and the workload of manual review.

[0019] (10) The traceable review report generated by this solution not only includes the final consistency conclusion, but also covers a complete set of content such as a verification overview, a PDF solution benchmark list, details of evidence extracted from the model identification model, a conflict table of rule candidates and model identification model candidates, a summary of BOM details, consistency review results, exclusion items, and items to be confirmed. Each review result can be traced back to the corresponding PDF page number, evidence block number, original evidence fragment, and full-chain information such as BOM file, line number, tag number, matching type, and comprehensive confidence level; at the same time, different color labels can be set for different review statuses to facilitate engineers to quickly locate anomalies. This reporting mechanism can support engineers to quickly locate problems, verify evidence chains, and complete closed-loop processing, and is applicable to various engineering scenarios such as hardware R&D review, BOM archiving, design change verification, and pre-production data confirmation. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart of a method for verifying the consistency of hardware PDF files with device models in the BOM according to embodiments of this application; Figure 2 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0021] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0022] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0023] Example 1 like Figure 1 As shown, this solution provides a method for verifying the consistency of device models between hardware PDF files and BOMs, including the following steps: S1: Parse the hardware PDF file to obtain an evidence block set including at least one evidence block per page of the PDF. Extract the traceable device model from the hardware PDF file. Calculate the device quantity of the traceable device model based on the number of times the evidence block appears and the explicit quantity identifier. The number of times the evidence block appears is the number of times the traceable device model appears in different evidence blocks. The explicit quantity identifier is a string that can directly represent the quantity near the traceable device model. Generate a PDF scheme benchmark list based on the corresponding traceable device model and device quantity. Each PDF benchmark model in the PDF scheme benchmark list includes benchmark information including the suggested quantity for the corresponding traceable device model. S2: Identify the valid rows and columns of the BOM file. Valid rows include header rows and material rows. Valid columns include model, quantity, tag number, and material number columns. Identify and filter to obtain valid material rows. Identify the material quantity within the valid material rows and aggregate the valid material row data of the same model to obtain the BOM aggregate list. Each BOM aggregate model in the BOM aggregate list includes the aggregation information of the corresponding target material. S3: Based on the PDF solution baseline list, perform model matching and quantity consistency review on the PDF baseline model and the BOM aggregated model to obtain the consistency review results.

[0024] Regarding step S1: A hardware PDF file is defined as a PDF file that describes the hardware solution and the key components and connection methods that must be used in the hardware circuit design. In this solution, each independent text area in the hardware PDF file is defined as an "evidence block". An evidence block refers to a text unit with relatively independent semantics in the hardware PDF file. The text unit can be a paragraph, a table unit area, a figure caption, a title area, or a local explanatory text.

[0025] In some embodiments, when the hardware PDF file is a native text PDF, the text content of each page in the hardware PDF file is extracted to obtain an evidence block; when the hardware PDF file is a scanned PDF, the pages of the hardware PDF file are rendered as images according to a set DPI, and then the text block structure is output through OCR to obtain the evidence block.

[0026] Furthermore, to facilitate the retrieval of evidence blocks and ensure that subsequent model output candidates can be traced back to their corresponding evidence blocks, this solution establishes a page text index. This index records each evidence block and its information, including page number, text content, evidence block number, page coordinates, and reading order. Moreover, the page text index allows for verification of whether the model output candidates genuinely originate from the hardware PDF file, providing a foundation of evidence for subsequent validation.

[0027] Specifically, the page number information for each evidence block records the page number of the evidence block in the hardware PDF file; the text content records the content of the evidence block, which is used for subsequent model extraction and context analysis; the evidence block number records the number of the evidence block, which is used to distinguish different evidence blocks on the same page; the page coordinates record the position of the evidence block in the hardware PDF file, which is used to trace the position of the evidence block in the PDF page in the report; and the reading order records the order of the evidence blocks, which is used to ensure that the model recognition model understands the context in the order in which humans read PDFs.

[0028] For example, parsing the hardware PDF file on page p into a set of evidence blocks for the current page is represented as: ; ; in For the set of evidence blocks on page p, Let be the i-th evidence block on page p, and n represent the total number of evidence blocks on that page. This represents the text of the i-th evidence block on page p. Let be the page coordinate position of the i-th text cell on page p. Indicates the evidence block number. Indicates the reading order.

[0029] Traceable device models are those identified and traceable in the hardware PDF file. Considering that hardware PDF files are usually not standardized BOM files, meaning that the same device model may be mentioned repeatedly in the text description, tables, figure captions, titles, or notes, this solution does not directly use the number of times the traceable device model appears as the number of devices with the traceable device model. Instead, it combines the number of times the evidence block appears and the explicit quantity identifier to identify the number of devices with the traceable device model.

[0030] This solution uses different evidence blocks to count the occurrences of evidence blocks, rather than directly counting the occurrences of strings. This avoids excessive counting due to repeated descriptions on the same page, in the same table cell, or in the same paragraph. For example, if a model number is repeatedly mentioned in the same evidence block, the system can still consider it as a valid occurrence. As mentioned earlier, the number of evidence block occurrences refers to the number of times the traceable device model appears in different evidence blocks, calculated using the following formula: ; ; in Indicates the traceable device model The i-th evidence block, where n represents the number of different evidence blocks. For traceable device models The set of evidence blocks that appear Indicates the number of elements in the set.

[0031] In addition to the frequency of evidence blocks, this scheme also detects explicit quantity identifiers near the traceable device model. As mentioned earlier, explicit quantity identifiers are strings that directly represent the quantity near the traceable device model, for example ( 2, x 2, 2pcs, 2 pieces.

[0032] In some embodiments, the explicit quantity identifier is located in the evidence block containing the traceable device model and the adjacent context window, and the explicit quantity identifier is converted into Arabic numerals. The calculation method for the quantity identifier is as follows: ; in For traceable device models The context window, This represents a quantity parsing function used to convert matched quantity identifiers into Arabic numerals. This is a function for explicitly identifying the quantity of matching.

[0033] Furthermore, to avoid misidentifying parameter values, voltage values, version numbers, or interface numbers as explicit quantity identifiers, this solution sets validity judgment conditions for explicit quantity identifiers. Specifically, it identifies strings near the traceable device model that directly represent the quantity as quantity identifiers, and selects quantity identifiers that meet any of the validity judgment conditions as explicit quantity identifiers. The validity judgment conditions are as follows: ① The quantity identifier immediately follows the traceable device model number, for example, "SGM2210" 2””TPS61086 ×2”; ② The quantity identifier is located in the same table cell as the traceable device model, for example, "Model: SGM2210, Quantity: 2"; ③ The quantity identifier is located within the phrase containing the traceable device model, such as "2 SGM2210 chips" or "two Flash chips"; ④ Quantity markers appear together with semantic terms related to quantity such as “quantity,” “dosage,” “number of pills,” “number of tablets,” “pcs,” and “PCS.” ⑤ The system reduces the validity or disregards the quantity identifier when it meets one of the following conditions: The quantity is placed immediately next to the unit of voltage, current, resistance, capacitance, or frequency, such as "3.3V", "2A", "10kΩ", "100nF", "24MHz"; The quantity numbers belong to the interface number, version number, page number, or chapter number, such as "I2C2", "SPI3", "V1.2", "Chapter 2"; The quantity numbers appear in the network name, power rail name, or parameter expression, such as "VCC_3V3", "LDO_1V8", and "GPIO2".

[0034] In some embodiments, this scheme calculates the number of traceable device models based on the principle of prioritizing explicit quantity identifiers and supplementing with the number of occurrences of evidence blocks. When there is a valid explicit quantity identifier near the traceable device model, it means that the quantity corresponding to the traceable device model has been directly given in the hardware PDF file. Therefore, the system prioritizes the use of explicit quantity identifiers.

[0035] Specifically, if no valid explicit quantity identifier is identified, the number of times the evidence block appears is used as the number of devices for the traceable device model; if a valid explicit quantity identifier is identified, and there is a conflict between the number of times the evidence block appears and the explicit quantity identifier, the explicit quantity identifier is used as the number of devices for the traceable device model, while the number of times the evidence block appears is displayed as supplementary evidence.

[0036] Furthermore, when there is a conflict between the number of times the evidence block appears and the explicit quantity identifier, an engineer will conduct a manual review, and the result of the manual review will be used as the number of devices for the traceable device model.

[0037] Using the above method, this solution makes quantity inferences solely based on the frequency and explicit quantity markers of evidence blocks in the hardware PDF file, avoiding over-reliance on AI's subjective understanding of the quantity of natural language, while still being able to identify " Direct quantitative expressions such as “2”, “×3”, and “2pcs” are used to improve the stability and interpretability of quantity extraction.

[0038] After obtaining the traceable device model and quantity, this solution can display the corresponding traceable device model and quantity, allowing for manual intervention to perform operations such as inclusion, exclusion, modification of model, modification of quantity, addition to knowledge base, addition to exclusion thesaurus, or addition to alias library. Subsequently, a PDF solution benchmark list is generated based on the corresponding traceable device model and quantity. This PDF solution benchmark list is the standard input for subsequent consistency review with the BOM aggregation list. Each PDF benchmark model in the PDF solution benchmark list includes the benchmark information of the corresponding traceable device model.

[0039] In some embodiments, the baseline information includes project name, traceable device model, original mention, number of confirmed items, recommended number, overall confidence level, source page number, evidence block number, original evidence, confirmation status, and remarks.

[0040] In addition, this solution provides an embodiment of a method for obtaining traceable device model as follows: Step 1: Identify the original text of the hardware PDF file, split the original PDF text line by line to obtain multiple text lines represented as strings, merge adjacent text lines based on multi-evidence weighting rules, extract candidate device models from the merged text lines based on the rule extractor, and record the position information of the candidate device models. The multi-evidence weighting rules include hyphen continuation evidence, slash continuation evidence, short suffix completion evidence, and knowledge base known model protection evidence. Step 2: Divide the evidence into multiple overlapping input windows, input each input window into the pre-trained model recognition model to obtain the model output candidate, and perform original evidence constraint verification on the model output candidate to retain the model candidate device model that meets the original evidence constraint. Step 3: Normalize and merge the regular candidate device models and model candidate device models to obtain a unified candidate device model. Define the unified candidate device model, the regular candidate device models not included in the unified candidate device model, and the model candidate device models not included in the unified candidate device model as candidate nodes. Calculate the comprehensive confidence of the candidate nodes and select the candidate node with the high comprehensive confidence as the traceable device model.

[0041] In Step 1: This scheme employs a multi-evidence weighted rule to merge adjacent text lines. The advantage of this approach is that it integrates different types of evidence to improve the credibility of the merged process, thereby increasing the overall accuracy. Specifically, it calculates a weighted score for adjacent text lines based on evidence of hyphen continuation, slash continuation, short suffix completion, and known model protection evidence from the knowledge base. It also calculates negative suppression terms for adjacent text lines based on suppression conditions. Finally, it calculates a merge score for adjacent text lines based on the weighted score and the negative suppression terms. If the merge score exceeds a set threshold, the adjacent text lines are merged.

[0042] Furthermore, the scores for the continuation of hyphens in adjacent text lines are calculated based on the continuation of slashes, the continuation of slashes in adjacent text lines is calculated based on the continuation of slashes, the continuation of short suffixes in adjacent text lines is calculated based on the continuation of short suffixes, and the continuation of known models in the knowledge base is calculated based on the protection evidence of known models in the knowledge base. The weighted scores for the continuation of hyphens, the continuation of slashes, the continuation of short suffixes, and the protection evidence of known models in the knowledge base are then summed to obtain a weighted score. Regarding evidence of hyphen continuation: Hyphen continuation evidence is used to determine whether adjacent lines need to be merged based on hyphens. That is, if the previous line ends with a hyphen and the next line begins with a letter or number, it means that the previous line is likely to be truncated due to line breaks in the PDF.

[0043] That is, if the previous line of text ends with a hyphen and the next line of text begins with a letter or number, the hyphen continuation evidence score is 1, as shown below:

[0044] in Score the evidence for continuation of hyphens. To determine whether the text line of the i-th line ends with a hyphen, To determine whether the text line in the (i+1)th row begins with a letter that is a number. This is an indicator function that takes the value 1 when the condition is true and 0 when the condition is false.

[0045] Evidence regarding the continuation of slashes: The slash continuation evidence is used to determine whether adjacent lines need to be merged based on the slash symbol. That is, if the previous line ends with a slash and the next line begins with a short suffix, such as a short order suffix, packaging suffix, or version suffix, it means that the next line may be the suffix part of the model number of the previous line.

[0046] That is, if the previous line ends with a forward slash and the next line begins with a short suffix, and the short suffix is ​​alphanumeric and not an excluded word, then the evidence score for the forward slash continuation is 1, as shown below: ; in Score the evidence for the continuation of the slash. To determine whether the text line of the i-th line ends with a forward slash. To determine whether the text line in the (i+1)th row has a short alphanumeric suffix, This indicates whether the short suffix belongs to the excluded words that should not be merged. This is an indicator function that takes the value 1 when the condition is true and 0 when the condition is false.

[0047] In some embodiments, excluded terms include, but are not limited to, network names, function names, or device category abbreviations such as VCC, VDD, GND, MCU, FPGA, LDO, ADC, DAC, PWM, and GPIO.

[0048] Evidence regarding the completion of short suffixes: Short suffix completion evidence is used to determine whether adjacent lines need to be merged based on short suffixes. Specifically, if the previous line ends with the main characteristics of the device model, and the next line begins with a short suffix (such as a short package suffix, temperature rating suffix, packaging suffix, or order suffix), and the short suffix is ​​not an exclusion term, then the next line may be used to complete the full model number of the previous line. This condition can identify continuation relationships like "STM32F405" and "RGT6," thus merging them into "STM32F405RGT6."

[0049] Furthermore, the main characteristics of the device model are that the string at the end of the previous line contains both letters and numbers, the string length reaches the preset minimum length of the main model, and it is not a pure number, pure unit, pure network name or ordinary function abbreviation.

[0050] That is, if the previous line of text ends with the main characteristics of a device model, and the next line of text begins with a short suffix and is not an exclusion word, then the short suffix completion evidence score is 1, as shown below: ; in To complete the evidence for the short suffix, score points. This indicates that the end of the previous line of text contains the main characteristics of the device model. To determine whether the text line in the (i+1)th row has a short alphanumeric suffix, This indicates whether the short suffix belongs to the excluded words that should not be merged. This is an indicator function that takes the value 1 when the condition is true and 0 when the condition is false.

[0051] Regarding evidence for known model protection in the knowledge base: The evidence for protecting known models in the knowledge base is based on determining whether adjacent lines need to be merged. If the string obtained by concatenating adjacent text lines matches a model already existing in the knowledge base, it indicates that the concatenation result is a historical material of the enterprise or a confirmed device model, and its integrity should be protected first.

[0052] That is, merge the strings of adjacent lines. If the merged string matches an existing model in the knowledge base, the evidence score for the known model protection in the knowledge base is 1, as shown below: ; in The evidence score is used to protect known models in the knowledge base. This is the concatenation result of the text lines from line i to line j. For a knowledge base containing known models, This is an indicator function that takes the value 1 when the condition is true and 0 when the condition is false.

[0053] In some embodiments, a sliding concatenation judgment is performed on the combination of consecutive text lines. When the merged string matches an existing model number, the system merges the text lines to obtain a complete model number, thereby handling the case of splitting three or more lines.

[0054] As previously stated, the formula for calculating the weighted score of adjacent text lines based on hyphen continuation evidence, slash continuation evidence, short suffix completion evidence, and known model protection evidence from the knowledge base is as follows: ; ; in This represents the weighted score of the i-th line of text and the (i+1)-th line of text. This represents the evidence score for the kth type of evidence (corresponding to the hyphen continuation evidence score, slash continuation evidence score, short suffix completion evidence score, and knowledge base known model protection evidence score mentioned above). Then, it represents the weight of the k-th type of evidence.

[0055] In addition, to reduce the probability of erroneous merging, this scheme also calculates negative suppression terms for adjacent text lines based on suppression conditions. In some embodiments, it is determined whether adjacent text lines meet the suppression conditions, and the negative suppression term is obtained by weighted summation of the suppression conditions that are met. The suppression conditions are any of the following text lines: power network name, ground network name, interface signal name, common function abbreviation, unit symbol, header / footer content, table title content, or obvious natural language description. Each suppression condition has a corresponding suppression weight.

[0056] In addition, this solution merges adjacent text lines line by line based on the line order of the original PDF text, using a multi-evidence weighting rule. That is, for the current text line, it first calculates whether the current text line and the next text line should be merged based on the multi-evidence weighting rule. If merging is required, the merged text line is used as the current text line, and the multi-evidence weighting rule is then applied.

[0057] As mentioned above, by using multi-evidence weighting rules and suppression conditions, this scheme can comprehensively judge the model continuation relationship in hardware PDF text based on multiple types of evidence such as hyphens, slashes, short suffixes, model main features, and the enterprise's known model library. Compared with the method that relies on only a single regular expression rule, this method can improve the complete extraction rate of long models, models with package suffixes, models with packaging suffixes, and multi-line split models. At the same time, by excluding words and negative suppression terms, it reduces the risk of network names, functional abbreviations, and common short words being mistakenly merged into device models.

[0058] Furthermore, this solution uses a rule extractor to extract candidate device models from the merged text lines. The rule extractor mainly filters based on the character morphological features of the device models.

[0059] In some embodiments, the rule extractor has preset string requirements, and compares the strings in the merged text lines one by one to see if they meet the preset string requirements. The strings that meet the preset string requirements are taken as the rule candidate device models. The location information of the rule candidate device models includes the page number, evidence block number, context fragment, occurrence position and occurrence number of the rule candidate device model.

[0060] Furthermore, this invention defines the regular candidate device model as a string that satisfies the following conditions: ① The string contains at least one letter and at least one number; ② The string length is within a preset range to avoid the erroneous extraction of excessively short ordinary numbers and excessively long non-model text; ③ The string is allowed to contain common device model separators such as hyphens, forward slashes, periods, and underscores; ④ The string should not completely match the exclusion dictionary, such as VCC, GND, RESET, POWER, GPIO, etc.; ⑤ The string should not conform to the typical power network name pattern, such as VCC_3V3, LDO_1V8, FPGA_VCCIO_2V5, etc.

[0061] Correspondingly, the rule candidate judgment function within the rule extractor is: ;

[0062] in This refers to the q-th string in the current line of text. Indicates whether the j-th string contains a letter. This indicates whether the j-th string contains a number. This represents the length of the j-th string. and These represent the minimum and maximum lengths of the candidate device models, respectively. This indicates whether the j-th string matches the excluded word list. This indicates whether the j-th string satisfies the pattern of a network name or power rail name. This is an indicator function that takes the value 1 when the condition is true and 0 when the condition is false.

[0063] Furthermore, when At time 1, the rule extractor filters the current string as a candidate device model for the rule.

[0064] In Step 2: This solution utilizes a model identification model to identify potential candidate device models in hardware PDF files. Regarding the model extraction for model identification, evidence blocks marked with device models can be used for training, which will not be elaborated upon here.

[0065] To avoid omissions in the model recognition due to excessively long input content and to prevent the model and explanatory text from being truncated by the window boundary, this solution uses a sliding window method to group evidence blocks. That is, multiple consecutive evidence blocks are grouped into an input window according to the reading order, and overlapping evidence blocks are retained between adjacent input windows.

[0066] In some embodiments, the window length of each input window is not greater than the maximum allowed input length, and the number of overlapping evidence blocks between adjacent input windows is not less than the minimum number of overlapping evidence blocks. By overlapping the windows of continuous windows, it can be ensured that the model and its description text located at the edge of the continuous window will not be omitted due to segmentation.

[0067] In some embodiments, each model output candidate includes candidate information including device model, candidate category, whether it is recommended for inclusion in the review, quantitative expression, inferred quantity, page number, evidence block number, original text evidence fragment, original text mentions, and model confidence level, as shown below: ; in This indicates the u-th model output candidate extracted by the model for the k-th input window, and s represents the number of model output candidates.

[0068] In some embodiments, the model recognition model performs the following tasks for each input window: ① Identify the device model that appears directly in the current input window; ② Identify the device model that has been separated by line breaks, spaces, or separators; ③ Determine whether the extracted object belongs to chip model, discrete device, module model, network name, power rail name, function block name, parameter value, or uncertain item; ④ Extract quantity expressions near the component model, such as "2 pieces", "two chips", "three channels in total", "U1 / U2", "one motherboard and one interface board", etc. ⑤ Output the original text evidence fragments and content mentioned in the original text that support the judgment.

[0069] Furthermore, since the output of the model identification model must be bound to the original evidence in the hardware PDF file, rather than being freely generated, the model output candidates are only constrained candidates and must subsequently undergo original evidence verification and comprehensive confidence calculation. That is, to avoid device models not present in the hardware PDF file in the model output, this solution also requires performing original evidence constraint verification on the model output candidates to retain model candidate device models that meet the original evidence constraints. This original evidence constraint verification mainly determines whether the model output candidates, original evidence fragments, original text mentions, and page numbers can be accurately located in the hardware PDF file.

[0070] In some embodiments, for each model output candidate, the existence score of evidence fragment, the location score of model mention, the normalization reasonableness score, the category legality score, and the location score of evidence block are calculated respectively. The existence score of evidence fragment, the location score of model mention, the normalization reasonableness score, the category legality score, and the location score of evidence block are weighted to obtain the validity score. Model output candidates with a validity score greater than a set threshold are retained as model candidate device models.

[0071] Furthermore, if the corresponding evidence block contains original text evidence fragments, the evidence fragment existence score is 1; if the original text evidence fragment contains content mentioned in the original text or the edit distance similarity between the original text evidence fragment and the content mentioned in the original text reaches a set threshold, the model mention location score is 1; if the length of the device model is less than the content mentioned in the original text, the normalization reasonableness score is 1; if the candidate category belongs to the preset category set, the category reasonableness score is 1; if the original PDF text contains page numbers and evidence block numbers, the evidence block location score is 1.

[0072] In some embodiments, the formula for calculating edit distance similarity is as follows: ; Where (a) represents the content mentioned in the original text, and (b) represents the substring in the original text that is closest to (a). and These represent the length of the string.

[0073] In some embodiments, if the length ratio between the length of the device model and the length of the original text after removing spaces and meaningless separators is within a preset reasonable range, the normalized reasonableness score is 1. The formula for calculating the length ratio is as follows:

[0074] in This indicates the original text content after removing spaces and meaningless delimiters. For device model, This is the length ratio.

[0075] In some embodiments, the sum of the weights of the evidence fragment existence score, model mention location score, normalization reasonableness score, category legality score, and evidence block location score is 1. If the validity score is less than a set threshold, it is marked as "insufficient evidence" or "suspected model fabrication".

[0076] In Step 3: After obtaining the regular candidate device model and the model candidate device model, this solution also needs to normalize and merge the regular candidate device model and the model candidate device model to obtain a unified candidate device model.

[0077] Furthermore, after normalizing the rule-based candidate device models and model-based candidate device models, a standard normalized model is obtained. Rule-based and model-based candidate device models with the same standard normalized model are merged into a unified candidate device model. The node information for each unified candidate device model includes the normalized model, page number set, evidence block set, original text evidence fragment set, source set, and quantity clue set. When the source originates from a rule-based candidate device model, the source set is defined as rule extraction; when the source originates from a model-based candidate device model, the source set is defined as AI extraction.

[0078] Furthermore, for rule candidate device models and / or model candidate device models belonging to the same standard normalization model but from different evidence blocks, the context similarity of the rule candidate device models and / or model candidate device models is calculated. When the context similarity is greater than a set threshold, they are merged into a unified candidate device model and the evidence set is merged; when the context similarity is less than the set threshold, they are merged into a unified candidate device model but their respective evidence sources are retained.

[0079] In some embodiments, a normalization function is applied to the regular candidate device model and the model candidate device model to obtain a standard normalized model, wherein the normalization function is expressed as follows: ; in To remove leading and trailing spaces, To delete invisible characters, Convert full-width characters to half-width characters. To ensure uniform conversion to uppercase, To standardize the format of delimiters such as hyphens, forward slashes, and parentheses, (x) represents the string of candidate device model numbers for rules or models. This is a standardized model.

[0080] Furthermore, when auxiliary matching of the main model is required, the main model function is executed on the standard normalized model to obtain the filtered main model. The main model is only used to assist in judging suffix differences and does not cover the original normalized model. The main model function is expressed as follows: ; in This function represents the process of removing common order suffixes, packaging suffixes, or tape / reel suffixes.

[0081] For example, a unified candidate device model is represented as follows: ; Where z represents the standard normalized model number. Represents a set of page numbers. Represents a set of evidence blocks. This represents a collection of evidence fragments from the original text. Represents the source set, This represents a set of quantity clues.

[0082] To avoid relying solely on a single rule or AI judgment to determine whether a candidate should be included in the review process, this approach calculates a comprehensive confidence score for each identical unified candidate device model. The comprehensive confidence score indicates the degree of confidence that the unified candidate device model is a genuine device model and should be included in the PDF scheme benchmark list.

[0083] In some embodiments, the rule morphology score, AI model score, PDF original text evidence score, contextual semantic score, knowledge base hit score, quantitative evidence score, multi-source consistency score, exclusion word penalty, network name, power rail name or function block penalty, and conflict penalty between rule results and AI classification results are calculated for the unified candidate device model, rule candidate device model, and model candidate device model, and then weighted and summed to obtain the comprehensive confidence score.

[0084] The formula for calculating the overall confidence level is as follows: ;

[0085] in As a candidate node, Indicates the overall confidence level. Indicates the score based on the rule pattern. This indicates the score of the AI ​​model. This indicates the score of the original PDF evidence. Indicates contextual semantic score, Indicates the knowledge base hit score, Indicates the quantitative evidence score, Indicates the consistency score across multiple sources. Indicates exclusionary words and penalties Indicates network name, power rail name, or function block penalty. This indicates a penalty for conflicts between the rule-based results and the AI ​​classification results. ~ This indicates configurable weights.

[0086] In some embodiments, the overall confidence score is mapped to a value between 0 and 1 using the Sigmoid function, where the closer the overall confidence score is to 1, the more likely the candidate node is to be a real device model.

[0087] The calculation methods for each score within the overall confidence level are as follows: ①Rule-based scoring : The string used to measure whether a candidate node conforms to the common character structure of a device model is composed of a length score, an alphanumeric combination score, a separator score, a prefix score, and a package suffix score. The calculation formula is as follows: ; ; in This indicates whether the length is within the common range for the device model. Indicates whether it contains both letters and numbers. Indicates whether common model separators such as hyphens, forward slashes, and periods are included. Indicates whether the device prefix library is hit. Indicates whether common packaging or order suffixes are included. As weight.

[0088] ②AI model score : The model identification score is used to measure whether the model recognizes a candidate node as a real device model, and whether the model's output is stable, complete, and interpretable. It is determined by the model's output confidence score and output validity score, and the calculation formula is as follows: ; in This represents the output confidence level of the model identification model. This represents the output validity score of the model identification model.

[0089] ③ PDF Original Evidence Score : The method used to measure whether a candidate node can be traced back to a PDF page and evidence block consists of three parts: existence of evidence fragments, location of model mentions, and location of evidence blocks. The calculation formula is as follows: ; ; in This indicates whether there are fragments of original evidence within the hardware PDF file. Indicate whether the evidence fragment contains model information. This indicates whether page numbers and evidence blocks exist in the hardware PDF file, each... Indicates the weight.

[0090] ④ Contextual semantic score : This is used to measure whether semantic terms related to devices such as chips, LDOs, DC-DC converters, MOS transistors, sensors, and power management appear near candidate nodes. The calculation is based on the number of device semantic keywords matched in the candidate model's context, and the formula is as follows: ; in This represents the number of keywords required to achieve a perfect score, where K represents the number of semantic keywords related to the device that are hit.

[0091] ⑤ Knowledge base hit score : This is used to measure whether a candidate node matches the confirmed device model library, device prefix library, or alias library. The determination is based on whether the candidate node matches the enterprise knowledge base. If a candidate node completely matches the confirmed device model library, then... Take the higher value; if only the prefix matches the device prefix library, take the medium value; if only the main model matches the alias library, take the lower but valid value; if there is no match at all, take 0.

[0092] ⑥ Quantitative evidence score : This is used to measure whether there are interpretable quantitative clues near the candidate node. The score is determined by whether there are explicit quantitative expressions near the candidate node. If there are explicit quantitative expressions such as "2", "two pieces", or "three paths", the score is high; if there are only positional clues such as U1 / U2, the score is medium; if there are only occurrence counts, the score is low; if there are no quantitative clues, the score is 0.

[0093] ⑦ Consistency score from multiple sources : The formula used to measure whether a candidate node is supported by multiple sources is as follows:

[0094] in This indicates how many sources identified the candidate node.

[0095] ⑧ Exclusionary word penalty : This is used to reduce the score of candidate nodes that are known to be non-device models. If a candidate node matches the exclusion word list, such as VCC, GND, RESET, CLK, GPIO, MIPI, I2C, etc., the exclusion word penalty is 1; otherwise, it is 0.

[0096] ⑨ Internet name punishment : Used to process power rail names and functional network names. If a candidate node meets the network name patterns such as VCC_3V3, LDO_1V8, or FPGA_VCCIO_2V5, the network name penalty is 1; otherwise, it is 0.

[0097] ⑩ Conflict Punishment : This is used to handle situations where the rule extractor and the model recognition model make inconsistent judgments. If the rule extractor extracts the candidate but the model recognition model judges it as a network name, function block, or parameter, the conflict penalty is 1; otherwise, it is 0.

[0098] This solution calculates the overall confidence level and then makes subsequent judgments based on it. If the overall confidence level is greater than the certain threshold, the current node is selected as the traceable device model. If the overall confidence level is less than the certain threshold but greater than the suspected threshold, the solution displays the original PDF location, contextual evidence, AI judgment reasons, and explanations of doubts for the current candidate node to be reviewed manually. If the overall confidence level is less than the suspected threshold but greater than the denial threshold, it is displayed as a candidate node with low confidence. If the overall confidence level is less than the denial threshold, the current candidate node is automatically excluded.

[0099] Regarding step S2: Since the table structure of BOM files may differ for different projects, this solution cannot use the first row as the header row. Instead, it is necessary to identify the headers of the first few rows and select the row with the highest header score that exceeds the header identification threshold as the header row. The rows below the header row are defined as material rows.

[0100] In some embodiments, if the highest header score of the BOM file is lower than the header recognition threshold, an abnormal BOM table structure is indicated, requiring manual confirmation of the header rows.

[0101] In some embodiments, after confirming the header row, the model column, quantity column, tag number column, and material number column are identified based on column name similarity. The column name similarity can be achieved by keyword matching, edit distance, or semantic similarity. In this way, the system can adapt to the problem of inconsistent column names in different BOM files.

[0102] In the "Identify and Filter to Obtain Valid Material Lines" step, the material number within the material line is identified, and the material number is judged based on its prefix to obtain valid material lines. The advantage of this design is that a BOM file may simultaneously contain multiple materials such as ICs, MOS transistors, resistors, capacitors, connectors, structural components, and auxiliary materials, while hardware PDF file reviews typically focus only on key ICs, MOS transistors, modules, or specific material categories, requiring a unified target material.

[0103] In some embodiments, a preset set of material prefixes is used. If the prefix of the material number of the current material line is the same as the prefix of a material in the set of material prefixes, then the current material line can be considered a valid material line. The calculation formula is as follows: Let the material number of a certain material line in the BOM be... The target material number prefix set is: If a certain material prefix exists , making If so, the current material line will be considered a valid material line and will enter the subsequent review scope; otherwise, it can be excluded according to the configuration. Indicates material number Material prefix beginning.

[0104] It should be noted that if the material number of a material line is empty, but its model or tag number column contains valid content, the system should not skip it directly, because there may be omissions in the material number. Skipping it directly will lead to missed review. In this case, the system will mark the material line as "material number missing but suspected valid material" and enter the abnormal prompt or manual confirmation process.

[0105] In the "Identify the quantity of material in the valid material row" step, the quantity in the quantity column of the valid material row is identified as the material quantity. If the quantity column is invalid but the tag number column is valid, the material quantity is identified based on the tag number column of the valid material row. If both the quantity column and the tag number column are invalid, the material quantity is 0.

[0106] In some embodiments, an invalid quantity column means that the quantity column is empty, not a number, or does not exist.

[0107] In some embodiments, when the content in the quantity column is an integer, a decimal, or a string that can be parsed into a numerical value, the system considers the quantity column to be a valid numerical value and converts it into the corresponding numerical result to obtain the material quantity.

[0108] In some embodiments, the tag number field of the tag number column may include a single tag number, multiple comma-separated tag numbers, a range of consecutive tag numbers, or a tag number expression with a quantity identifier. When the quantity column is invalid but the tag number column is valid, it indicates that the quantity field in the BOM may be missing or have an abnormal format. In this case, the parsing result of the tag number field of the tag number column is used as the material quantity of the valid material row.

[0109] Furthermore, after obtaining the material quantity for each valid material line, the BOM aggregation list is obtained by aggregating material line data of the same model according to the normalized model. Each BOM aggregation model in the BOM aggregation list includes the aggregation information of the corresponding target material. The aggregation information includes the original BOM model, the line number of the material line, the set of tag numbers, the material number, and the source BOM file.

[0110] Regarding step S3: This solution uses the PDF solution baseline list as a benchmark and applies multi-level matching rules to match the PDF baseline model and the BOM aggregated model. The multi-level matching rules are as follows: Match type: Exact match. If the PDF base model and the BOM aggregate model are exactly the same, then they are considered an exact match. Matching type: Alias ​​match. If the PDF base model and the BOM aggregate model exist in the alias rule base, then they are considered to be alias matches. Matching type: Main model matching. The main model is obtained by removing the order suffix and package suffix from the PDF base model and the BOM aggregate model respectively. If the main models are the same, the PDF base model and the BOM aggregate model are considered to be main model matching. Matching type: Suffix difference matching. If either the PDF base model number or the BOM aggregate model number is a prefix of the other, then a suffix difference is considered to exist between the two, requiring manual verification.

[0111] The priority of matching types is as follows: exact match > alias match > main model match > suffix difference match > no match.

[0112] In some embodiments, for each PDF baseline model, model matching of BOM aggregated models is performed based on multi-level matching rules, and the BOM aggregated model with the highest priority is taken as the matching object.

[0113] If the PDF baseline model does not match any BOM aggregate model, the consistency review result is "BOM missing". That is, when a PDF baseline model exists in the PDF solution baseline list, but no corresponding exact match, alias match, main model match, or suffix difference match is found in the BOM aggregate list, the system outputs a "BOM missing" status. This status indicates that the device model required in the solution is not reflected in the BOM, which may indicate a problem such as missing BOM entries, incorrect model entries, devices not imported into the BOM, or a misalignment between the solution and the schematic design.

[0114] If a BOM aggregated model number is not matched by any PDF baseline model number, the conformance review result is "BOM Redundant". That is, when a certain BOM aggregated model number exists in the BOM aggregated list, but no corresponding matching item is found in the PDF solution baseline list, the system outputs the "BOM Redundant" status. This status indicates that there are component models in the BOM that are not explicitly required by the solution. This may be due to newly added components in the schematic that have not been synchronized to the solution, or the BOM retaining historical designs, alternative designs, redundant materials, or incorrect materials.

[0115] Furthermore, after matching the PDF baseline model and the BOM aggregated model to obtain the matching results, this solution conducts a quantity consistency review on the matching. Specifically, this solution still uses the model quantity confirmed by the PDF solution side as the solution baseline quantity, and uses the material quantity obtained by aggregating the same or equivalent models on the BOM side as the BOM actual quantity, and compares the two.

[0116] In some embodiments, for matched PDF base model and BOM aggregate model, when the material quantity and recommended quantity are the same, and the matching type of the PDF base model and BOM aggregate model is exact match, alias match, or main model match, the consistency review result is "consistent" or "acceptable consistency". The "consistent" status indicates that the PDF base model and BOM aggregate model are completely identical and have the same quantity; the "acceptable consistency" status indicates that although the PDF base model and BOM aggregate model have differences in alias, main model, or standardized expression, they can be considered to correspond to the same device after judgment by the rule base or main model, and the quantity is consistent.

[0117] In some embodiments, for matching PDF baseline models and BOM aggregate models, when the material quantity and the recommended quantity are different, the consistency review result is "quantity inconsistency," and the difference between the material quantity and the recommended quantity is recorded. This difference is output as a review anomaly for engineers to further verify the PDF scheme description, BOM tag number quantity, and actual schematic design. In this case, if the material quantity is greater than the recommended quantity, it indicates that the quantity of that model or equivalent model in the BOM is greater than the PDF scheme requirement; if the material quantity is less than the recommended quantity, it indicates that the quantity of that model or equivalent model in the BOM is less than the PDF scheme requirement.

[0118] In some embodiments, for PDF baseline models and BOM aggregate models with a matching type of suffix difference matching, even if the material quantity and recommended quantity are the same, the consistency review result is a "suffix difference needs confirmation" status. This status is used to prompt engineers to confirm whether the PDF baseline model and the BOM aggregate model are indeed the same material. For example, the two may only differ in packaging suffix, temperature rating suffix, package suffix, or order suffix, or the suffix difference may lead to differences in device package, accuracy, temperature range, packaging method, or supply status. Therefore, such results require manual confirmation before being considered as the final consistency result.

[0119] This solution aggregates all consistency review results. Each result records the matching, missing, redundant, or discrepancy assessment between the baseline model in the matching PDF and the aggregated model in the BOM. This consistency review process transforms the model consistency, quantity consistency, and suffix difference risks between the hardware PDF and BOM files into structured consistency review results. This allows engineers to quickly locate missing, redundant, inconsistent quantity, and manually verified issues, thereby improving the efficiency of hardware solution review and BOM verification. Furthermore, the method for verifying the consistency between the hardware PDF file and the device models in the BOM provided in this solution further includes step S4: A traceable review report is generated based on the conformity review results. The traceable review report includes at least the verification overview, conformity review results, PDF scheme benchmark list, details of evidence extracted from the model identification model, conflict table of rule candidates and model identification model candidates, BOM summary details, as well as exclusion items and items to be confirmed.

[0120] Specifically, the verification overview displays the number of PDF baseline models, the total number of devices in the PDF baseline models of the PDF solution, the number of BOM aggregated models, the total number of devices in the BOM aggregated models, the number of consistent items, the number of inconsistent items, the number of missing BOM items, and the number of redundant BOM items; the consistency review results display the PDF baseline models, PDF quantity, BOM aggregated models, BOM quantity, quantity difference, matching type, review status, and remarks item by item; the PDF solution baseline list displays the PDF solution models, confirmed quantity, overall confidence level, page number, and evidence fragments after manual confirmation; the model identification model extracted evidence details display the model, category, quantity expression, inferred quantity, confidence level, evidence validity score, and original evidence extracted by the model identification model; the rule candidate and model identification model candidate conflict table displays the candidate items where the rule extraction and model identification model classification are inconsistent, facilitating engineers to review the reasons for misidentification; the BOM summary details display the original BOM model, normalized model, aggregated quantity, tag number, material number, and BOM. Line number; Excluded items and pending confirmation items are used to display candidate items that have been excluded by the system or require manual confirmation, along with the reasons.

[0121] In addition, the system can set different visual identifiers based on the consistency review results. For example, consistent items, inconsistent quantity items, missing BOM items, redundant BOM items, suffix differences, conflicting items, and excluded items are displayed in different colors (consistent: green; inconsistent quantity: yellow; missing BOM: red; redundant BOM: orange; suffix differences requiring confirmation: blue; rule conflicts with AI model: purple; excluded items: gray). Through this report, engineers can not only see the final conclusions but also trace the PDF source, BOM source, and algorithm judgment basis for each conclusion.

[0122] Furthermore, the method for verifying the consistency between the hardware PDF file and the device models in the BOM provided in this solution further includes step S5: For content that requires manual confirmation, manual confirmation is performed and the confirmation result is obtained. The knowledge base in the system is then updated based on the confirmation result.

[0123] If an engineer confirms that a candidate is a real device model, the system will add that model to the confirmed device model database. When the same model appears again in the future, its knowledge base hit score will increase.

[0124] If an engineer confirms that a candidate is a network name, power rail name, function block, or parameter, the system adds the candidate or its pattern to the exclusion dictionary. When the same or similar strings appear again, the penalty for the exclusion word or network name will be increased.

[0125] If the engineer confirms that the PDF solution model and the BOM model belong to the same device despite having different suffixes, the system will write their relationship into the alias rule base, and alias matching can be performed directly during subsequent reviews.

[0126] Once a project review is completed, the system writes a PDF benchmark list to the project benchmark library. When the same or similar projects are reviewed again, the system can access the historical benchmark list for comparison of additions, deletions, common items, and quantity changes.

[0127] Through this closed-loop mechanism, the system can gradually reduce the false recognition rate as the number of uses increases, thereby improving the stability of PDF solution model extraction and BOM review.

[0128] Example 2 This embodiment also provides an electronic device, see reference. Figure 2 It includes a memory 404 and a processor 402, the memory 404 storing a computer program and the processor 402 being configured to run the computer program to perform the steps in any of the above embodiments of the method for verifying the consistency of device models in a hardware PDF file and a BOM.

[0129] Specifically, the processor 402 may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0130] The memory 404 may include a large-capacity memory 404 for data or instructions. The memory 404 can be used to store or cache various data files that need to be processed and / or communicated, as well as possible computer program instructions executed by the processor 402.

[0131] The processor 402 reads and executes computer program instructions stored in the memory 404 to implement any of the hardware PDF files and device model consistency verification methods in the BOM in the above embodiments.

[0132] Optionally, the electronic device may further include a transmission device 406 and an input / output device 408, wherein the transmission device 406 is connected to the processor 402, and the input / output device 408 is connected to the processor 402.

[0133] The transmission device 406 can be used to receive or send data via a network. Specific examples of the network described above may include wired or wireless networks provided by the communication provider of the electronic device. In one example, the transmission device includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 406 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0134] Input / output device 408 is used to input or output information. In this embodiment, the input information may be a hardware PDF file, etc., and the output information may be a conformity review result, etc.

[0135] Optionally, in this embodiment, the processor 402 can be configured to perform the following steps via a computer program: S1: Parse the hardware PDF file to obtain an evidence block set including at least one evidence block per page of the PDF. Extract the traceable device model from the hardware PDF file. Calculate the device quantity of the traceable device model based on the number of times the evidence block appears and the explicit quantity identifier. The number of times the evidence block appears is the number of times the traceable device model appears in different evidence blocks. The explicit quantity identifier is a string that can directly represent the quantity near the traceable device model. Generate a PDF scheme benchmark list based on the corresponding traceable device model and device quantity. Each PDF benchmark model in the PDF scheme benchmark list includes benchmark information including the suggested quantity for the corresponding traceable device model. S2: Identify the valid rows and columns of the BOM file. Valid rows include header rows and material rows. Valid columns include model, quantity, tag number, and material number columns. Identify and filter to obtain valid material rows. Identify the material quantity within the valid material rows and aggregate the valid material row data of the same model to obtain the BOM aggregate list. Each BOM aggregate model in the BOM aggregate list includes the aggregation information of the corresponding target material. S3: Based on the PDF solution baseline list, perform model matching and quantity consistency review on the PDF baseline model and the BOM aggregated model to obtain the consistency review results.

[0136] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0137] Generally, various embodiments can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects of the invention can be implemented in hardware, while others can be implemented by firmware or software executed by a controller, microprocessor, or other computing device, but the invention is not limited thereto. Although various aspects of the invention may be shown and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that, by way of non-limiting example, these blocks, apparatuses, systems, techniques, or methods described herein can be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0138] Embodiments of the present invention can be implemented by computer software, which may be executable by a data processor of a mobile device, such as a processor entity, or by hardware, or by a combination of software and hardware. Computer software or programs (also referred to as program products), including software routines, applets, and / or macros, can be stored in any device-readable data storage medium, and they include program instructions for performing specific tasks. A computer program product may include one or more computer-executable components configured to perform embodiments when the program is run. One or more computer-executable components may be at least one piece of software code or a portion thereof. Additionally, it should be noted that any block in the logical flow of the figures may represent a program step, or interconnected logical circuitry, blocks and functions, or a combination of program steps and logical circuitry, blocks and functions. The software may be stored on physical media such as memory chips or blocks of storage implemented within a processor, magnetic media such as hard disks or floppy disks, and optical media such as, for example, DVDs and their data variants, CDs, etc. The physical medium is a non-transient medium.

[0139] Those skilled in the art should understand that the technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0140] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for hardware PDF file and device model number consistency review in a BOM, characterized in that, Includes the following steps: S1: Parse the hardware PDF file to obtain an evidence block set including at least one evidence block per page of the PDF. Extract the traceable device model from the hardware PDF file. Calculate the device quantity of the traceable device model based on the number of times the evidence block appears and the explicit quantity identifier. The number of times the evidence block appears is the number of times the traceable device model appears in different evidence blocks. The explicit quantity identifier is a string that can directly represent the quantity near the traceable device model. Generate a PDF scheme benchmark list based on the corresponding traceable device model and device quantity. Each PDF benchmark model in the PDF scheme benchmark list includes benchmark information including the suggested quantity for the corresponding traceable device model. S2: Identify the valid rows and columns of the BOM file. Valid rows include header rows and material rows. Valid columns include model, quantity, tag number, and material number columns. Identify and filter to obtain valid material rows. Identify the material quantity within the valid target material row and aggregate the valid material row data of the same model to obtain the BOM aggregate list. Each BOM aggregate model in the BOM aggregate list includes the aggregation information of the corresponding target material. S3: Based on the PDF solution baseline list, perform model matching and quantity consistency review on the PDF baseline model and the BOM aggregated model to obtain the consistency review results.

2. The hardware PDF file and BOM consistency review method according to claim 1, wherein, Identify strings that directly represent the quantity near the traceable device model as quantity identifiers, and select quantity identifiers that meet any validity judgment condition as explicit quantity identifiers.

3. The method of claim 1, wherein the hardware PDF file and the device model number in the BOM consistency review method is characterized in that, If no valid explicit quantity identifier is identified, the number of times the evidence block appears shall be used as the number of devices for the traceable device model; if a valid explicit quantity identifier is identified, and there is a conflict between the number of times the evidence block appears and the explicit quantity identifier, the explicit quantity identifier shall be used as the number of devices for the traceable device model, and the number of times the evidence block appears shall be displayed as supplementary evidence.

4. The method for verifying the consistency of hardware PDF files and component models within the BOM according to claim 1, characterized in that, Identify the material number within a material line. Preset a set of material prefixes. If the prefix of the material number in the current material line is the same as the prefix in the set of material prefixes, then the current material line can be considered a valid material line.

5. The method for verifying the consistency of hardware PDF files and component models within the BOM according to claim 1, characterized in that, The quantity in the quantity column of a valid material row is used as the material quantity. If the quantity column is invalid but the tag number column is valid, the material quantity is identified based on the tag number column of the valid material row. If both the quantity column and the tag number column are invalid, the material quantity is 0.

6. The method for verifying the consistency of hardware PDF files and component models within the BOM according to claim 1, characterized in that, For each PDF baseline model, model matching of the BOM aggregated model is performed based on multi-level matching rules. The BOM aggregated model with the highest priority is taken as the matching object. The multi-level matching rules are as follows: Match type: Exact match. If the PDF base model and the BOM aggregate model are exactly the same, then they are considered to be an exact match. Matching type: Alias ​​matching. If the PDF base model and the BOM aggregate model exist in the alias rule base, then they are considered to be alias matching. Matching type: Main model matching. The main model is obtained by removing the order suffix and packaging suffix from the PDF base model and the BOM aggregate model respectively. If the main models are the same, the PDF base model and the BOM aggregate model are considered to be main model matching. Matching type: Suffix difference matching. If one of the PDF base model and the BOM aggregate model is a prefix of the other, then the two are considered to have a suffix difference. The priority of matching types is as follows: exact match > alias match > main model match > suffix difference match > no match.

7. The method for verifying the consistency of hardware PDF files and component models within the BOM according to claim 1, characterized in that, For matched PDF base models and BOM aggregate models, when the material quantity and the recommended quantity are the same, and the matching type of the PDF base model and the BOM aggregate model is exact match, alias match, or main model match, the consistency review result is "consistent" or "acceptable consistency"; for matched PDF base models and BOM aggregate models, when the material quantity and the recommended quantity are different, the consistency review result is "quantity inconsistent", and the difference between the material quantity and the recommended quantity is recorded; for PDF base models and BOM aggregate models with matching type of suffix difference match, even if the material quantity and the recommended quantity are the same, the consistency review result is "suffix difference needs to be confirmed"; If the PDF baseline model does not match any BOM aggregate model, the conformity review result is BOM missing; If the BOM aggregate model is not matched by any PDF baseline model, the conformance review result is that the BOM is redundant.

8. The method for verifying the consistency of hardware PDF files and component models within the BOM according to claim 1, characterized in that, Including step S4: A traceable review report is generated based on the conformity review results. The traceable review report includes at least the verification overview, conformity review results, PDF scheme benchmark list, details of evidence extracted from the model identification model, conflict table of rule candidates and model identification model candidates, BOM summary details, as well as exclusion items and items to be confirmed.

9. The method for verifying the consistency of hardware PDF files and component models within the BOM according to claim 1, characterized in that, For content that requires manual confirmation, manual confirmation is performed and the confirmation result is obtained. The knowledge base in the system is then updated based on the confirmation result.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the hardware PDF file and device model consistency review method in the BOM as described in any one of claims 1 to 9.

Images