Coverage driven orchestration of engineering review tasks and result failure control method

Abstract

The application discloses a kind of engineering review task coverage driven arrangement and result invalidation control method, system, equipment, medium and program product. Abstract, object and relationship record are generated to schematic diagram, bill of materials and printed circuit board file;According to frozen review configuration, establish the coverage record containing expected item, valid item, excluded item, missing item, state and reason for input, analysis, object, relationship, rule and evidence;Hard dependency, optional dependency graph of coverage item and machine check are constructed, and checks that hard dependency does not satisfy are prevented from entering processor queue and being written into unknown;Execution result is bound with baseline, coverage snapshot, rule version, evidence positioning and attempt identification. When coverage or dependency changes, affected closure is traversed from change node, historical result is invalidated first, only affected check is rearranged, and old attempt is rejected to rewrite. The application reduces invalid processor call, avoids missing input to be written as pass and that expired result covers current state.

Description

Technical Field

[0001] This invention relates to the fields of computer-aided engineering, electronic design automation data processing, static analysis, and computer task scheduling, and particularly to a method, system, electronic device, computer-readable storage medium, and computer program product for coverage-driven orchestration and result failure control of engineering review tasks.

[0002] This invention is applicable to electronic hardware engineering reviews involving schematic diagrams, bills of materials, printed circuit board design documents, and corresponding parsers, deterministic rules, graph computation, numerical computation, or models. It is used to control processor task submission, result status, and incremental re-evaluation based on the actual processable data range. Background Technology

[0003] Electronic hardware engineering review systems typically read schematics, bills of materials, and printed circuit board design documents, converting the documents into engineering objects such as components, networks, packages, pads, copper areas, and material items, as well as the connections, inclusions, and mapping relationships between these objects. Then, they call rules, graph algorithms, numerical calculations, or models to generate review results.

[0004] The reliability of the review results depends not only on the checking algorithm itself, but also on whether the expected input exists, whether the file is completely parsed, whether the target objects and relationships are extracted, whether the rules are actually executed, and whether the results can locate engineering evidence.

[0005] Existing systems typically use a single successful parsing flag, a single coverage percentage, or whether a problem item was generated to indicate the overall status. However, when printed circuit board files are missing, complex elements are not parsed, relationship extraction fails, or rules are not invoked, the system may still generate a pass flag even if the problem item list is empty.

[0006] In the above situations, an empty problem list could mean the check actually passed, or it could mean the check didn't obtain the necessary input, the parser doesn't support the target object, the check didn't enter the execution queue, or the evidence couldn't be located. If these states aren't distinguished, missing input could be mistakenly recorded as passed, resulting in a false negative in machine review.

[0007] On the other hand, different review domains require different data. The material domain may only rely on schematics and bills of materials, while package or copper area reviews also rely on printed circuit board design documents. Stopping all checks when any input is missing would waste available data, while allowing all checks to still enter the processor queue would result in invalid calls and misleading results.

[0008] Existing verification coverage techniques can count whether code, signals, or test items have been executed, and existing dependency graph techniques can locally recalculate based on dirty nodes. However, they cannot directly provide joint coverage of input, parsing, objects, relationships, rules, and evidence for multi-source engineering design data, nor can they enable joint coverage to simultaneously drive checks for enqueuing, writing to unknown states, invalidation of historical results, and rejection of late callbacks.

[0009] When new parsing results arrive, the parser is upgraded, the rule version changes, or the evidence becomes invalid, if the system directly overwrites the running state, the late callback of the old task may overwrite the new result; if a full rerun is performed for each change, it will increase processor time, storage access, and task queue load.

[0010] Therefore, a data structure and computer processing flow are needed for specific electronic hardware engineering design data, so that the coverage gap can be converted into processor task gating and explicit machine state, and only the affected results are invalidated and recalculated after coverage or version changes. Summary of the Invention

[0011] The technical problem to be solved by this invention is: how to prevent machine-executable checks that do not have the necessary data from consuming processor resources and generating false passes when multi-source electronic hardware engineering design data is incomplete or has limited parsing capabilities, and how to prevent expired results from continuing to be effective or overwriting the current state after overriding or relying on version changes.

[0012] To solve the above-mentioned technical problems, the present invention first calculates content summaries for at least two types of schematic files, bill of materials and printed circuit board design files respectively, and generates engineering object records and engineering relationship records by a parser with the corresponding format, forming a frozen engineering design baseline and generating a baseline identifier.

[0013] The machine-readable review configuration declares the review domain, expected inputs, expected object types, expected relationship types, machine-executable checks, evidence location requirements, and check dependencies. The review configuration, along with the engineering baseline, is frozen and versioned at the start of the review run.

[0014] This invention establishes structured coverage records for six coverage dimensions: input, parsing, engineering objects, engineering relationships, rules, and evidence. Each coverage record stores expected items, valid items, excluded items, missing items, coverage status, and reason codes, rather than just storing a percentage.

[0015] For the d-th coverage dimension, the expected item set is E_d, the valid item set is V_d, and the excluded item set is X_d. The valid denominator D_d is equal to the number of elements in the difference between sets E_d and X_d, the coverage numerator N_d is equal to the number of elements in the intersection of V_d and the difference set, and the missing item set M_d is equal to the difference between the difference set and V_d.

[0016] Coverage status includes covered, partially covered, blocked, and out of scope. Blocked is defined when a required item of a hard dependency is missing; partially covered is defined when a hard dependency is satisfied but an optional dependency has a gap; exclusions are explicitly given by the freeze review configuration and cannot be arbitrarily added after execution to improve coverage.

[0017] All coverage records are frozen into coverage snapshots. Each coverage snapshot has a coverage snapshot identifier, is bound to the baseline identifier of the frozen engineering design baseline, and contains all coverage records at the time of generation. Changes to coverage records generate new coverage snapshots without modifying existing ones in situ. A run identifier is generated at the start of each review run. This run identifier is bound to the baseline identifier and the coverage snapshot identifier for task record association and result write-back verification.

[0018] This invention constructs a directed dependency graph that includes at least coverage item nodes and machine-executable check nodes. Dependency edges from coverage item nodes to machine-executable check nodes record at least the dependency type, minimum coverage state, object scope, and dependency version. Dependency types are categorized as hard dependencies and optional dependencies. In some implementations, the directed dependency graph also includes result nodes, issue item nodes, and report snapshot nodes.

[0019] The scheduler iterates through the incoming edges of each machine's executable checks. If any hard dependency does not reach the minimum coverage state, the corresponding check does not enter the processor's execution queue, and the system directly writes it to the unknown state record; when all hard dependencies are satisfied, a normal execution task or a degraded execution task is generated based on whether the optional dependencies are satisfied.

[0020] The execution task only references the frozen engineering design baseline and coverage snapshot. The execution result is solidified into a result tuple, which includes at least the baseline identifier, coverage snapshot identifier, inspection identifier, rule version, object scope, evidence location set, result status, result validity limit, and processing attempt identifier.

[0021] The result status includes at least Pass, Fail, Unknown, Unevaluated, and Inapplicable. The summary processing uses a pre-stored finite status summary table. Unknown and Unevaluated statuses are not included in the pass count. When a hard dependency is missing, a pass cannot be written even if the issue item is empty.

[0022] When the overridden record or dependency version changes, this invention traverses the directed dependency graph starting from the changed overridden item node or dependency edge to obtain the closure of the affected checks, results, issue items, and report snapshots.

[0023] Before generating a re-evaluation task, the system first marks the affected historical results as invalid or lowers the validity limit of the results in the transaction; unaffected results retain historical references, and only affected checks re-enter the processor execution queue.

[0024] Each review run generates a run identifier, and each execution generates a processing attempt identifier. The result write-back process simultaneously verifies the run identifier, check identifier, processing attempt identifier, baseline identifier, actual input summary, and object version. Mismatched old callbacks are entered into the rejection log and cannot overwrite the current result.

[0025] Manual coverage verification and machine coverage calculation are stored separately. Manual verification can record known gaps and reasons for degradation, but it cannot rewrite expected items, valid items, or missing items, nor can it change blocked items to covered items, nor can it change unknown items to passed items.

[0026] Compared to schemes that unconditionally add all checks to the queue, this invention terminates checks for unmet hard dependencies before they are enqueued, thereby reducing invalid processor calls, data reads, and task queue occupancy.

[0027] Compared to the approach that passes if the problem item is empty, this invention transforms the coverage gap into an unknown state with a cause code and a missing set, preventing false passes from occurring due to checks that lack observation conditions.

[0028] Compared to the full re-evaluation scheme, this invention only re-orders the affected checks by affecting the closure; by invalidating first and then re-evaluating and processing the verification attempt, it can prevent old results from continuing to be effective after coverage decreases or version changes and prevent late callbacks from overwriting the current state. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the structure of the overlay-driven engineering review task orchestration and result failure control system in an embodiment of the present invention.

[0030] Figure 2 This is a schematic diagram of the six-dimensional covering record and its set fields in an embodiment of the present invention.

[0031] Figure 3 This is a dependency graph of coverage items and machine-executable checks, and a task gating diagram in an embodiment of the present invention.

[0032] Figure 4 This is a schematic diagram illustrating the summary of result status and the upper limit control of result validity in an embodiment of the present invention.

[0033] Figure 5 This is a schematic diagram illustrating the process of result invalidation, incremental re-evaluation, and old callback rejection after a change in the covered or dependent version in an embodiment of the present invention. Detailed Implementation

[0034] The embodiments of the present invention will be further described below with reference to the accompanying drawings. These embodiments are used to explain the technical solutions of the present invention, and are not intended to limit the scope of protection. Technical features in each embodiment can be combined where there is no conflict.

[0035] likeFigure 1 As shown, the computer system includes an engineering design document and frozen baseline 610, a coverage calculation module 620, a dependency graph checking module 630, a scheduler checking module 640, a rule, graph calculation, numerical calculation, or model execution module 650, a result and validity control module 660, and an impact location and incremental reassessment module 670. The baseline generation module generates and maintains the engineering design document and frozen baseline 610; the dependency graph checking module 630 and the scheduler checking module 640 together constitute the dependency graph and scheduling module; the result and validity control module 660 implements the function of the result solidification module; and the impact location and incremental reassessment module 670 implements the function of the failure reassessment module. The rule, graph calculation, numerical calculation, or model execution module 650 executes normal or degraded execution tasks generated by the dependency graph and scheduling module.

[0036] Engineering design documents can be stored on a local file system, object storage, or version repository. Before parsing each input file, a content digest is calculated, recording the file type, file length, retrieval time, version source, and security check result. The content digest can use SHA-256 or other collision-resistant digest algorithms.

[0037] The schematic parser generates device, pin, net labels, and layer page objects; the bill of materials (BOM) parser generates material entries, manufacturer part numbers, quantities, and reference designator sets; the printed circuit board (PCB) parser generates device, pad, via, net, copper area, board outline, and layer objects. Different parsers can be used for different formats.

[0038] A project object record must contain at least an object identifier, object type, field set, source file summary, source location locator, and resolver version. A project object record may also contain an object version, which is determined by at least one of the field set, source file summary, and resolver version; the object version changes when any one of these changes. A project relationship record must contain at least a relationship identifier, relationship type, start object identifier, end object identifier, source location locator, and resolver version.

[0039] The source location locator selects the file's hierarchical path, page number, coordinates, cell, network name, tag number, or object sequence number based on the file format. The evidence location set consists of one or more source location locators, bound to a corresponding source file digest, to avoid locating the wrong version after a file update.

[0040] The frozen engineering design baseline includes an input list, a summary of all input content, parsed output addresses, a set of parser versions, a machine-readable review configuration version, and a baseline identifier. The baseline identifier can be obtained by calculating a summary from the serialization results of the above fields.

[0041] Machine-readable review configurations can be in JSON, YAML, relational tables, or other structured formats. The configuration declares required inputs, optional inputs, expected object types, expected relationship types, check identifiers, rule versions, evidence location requirements, output thresholds, and dependency edges for each review domain. Machine-readable review configurations also declare each machine-executable check as required or optional.

[0042] Review domains can include material consistency, packaging consistency, electrical connectivity, power supply, clock, interface, manufacturability, thermal, reliability, or supply chain. Different domains have independent coverage records, task sets, and domain states. A dependency path exists between two review domains if their machine-executable checks are connected via a common coverage node or dependency edge; otherwise, the two review domains execute independently.

[0043] like Figure 2 As shown, the coverage snapshot 700 includes input coverage 710, parsing coverage 720, engineering object coverage 730, engineering relationship coverage 740, rule coverage 750, and evidence coverage 760. Each coverage dimension consists of multiple coverage topic records.

[0044] Coverage topics are used to limit coverage records to review domains, object types, engineering design versions, or check sets. For example, engineering object coverage can be created separately for schematic component object coverage, printed circuit board component object coverage, and material entry object coverage.

[0045] The expected set of items for the d-th coverage dimension is denoted as E_d, the valid set of items is denoted as V_d, and the excluded set of items is denoted as X_d. Valid items must pass the current baseline identifier, format validation, object type validation, and version validation; they cannot be included simply because a record with the same name exists in the database.

[0046] The effective denominator D_d = |E_d\X_d|, the coverage numerator N_d = |V_d∩(E_d\X_d)|, and the set of missing items M_d = (E_d\X_d)\V_d. The coverage ratio can be expressed as N_d / D_d, but scheduling and state determination directly use M_d, dependency type, and reason code.

[0047] When D_d is zero and the covered topic is explicitly excluded by the machine-readable review configuration, the coverage status is out of range; when D_d is zero but there is no explicit exclusion basis, the system writes the configuration exception reason code instead of automatically determining that it has been covered.

[0048] The expected items for input coverage 710 come from the machine-readable review configuration. Only inputs with a content summary, that pass integrity checks, and are bound to the current baseline are included in the set of valid items. Different reason codes are used for missing files, summary conflicts, or unavailable permissions.

[0049] The parsing coverage is 720, with the expected parsing task or format capability item as the denominator. Parser completion is not equivalent to complete parsing; if the parsing log contains unsupported objects, missing fields, or premature termination, the corresponding item is not included in the set of valid items, and a semantic loss reason code is written.

[0050] The project object coverage 730 uses the expected object type, object list, or verifiable catalog item as the denominator. Object records must have an object identifier, object type, and source location locator; if critical fields are missing, the object itself can be recorded as valid while the field coverage subject is recorded as missing.

[0051] The engineering relationship coverage 740 uses the connection, containment, mapping, or derivation relationship types declared in the machine-readable review configuration as the denominator. If an object exists but a critical endpoint or relationship type is missing, the check of the dependency topology is still blocked.

[0052] Rule coverage 750 uses the machine-executable checks applicable to the current review domain as the expected set of items. A rule only enters the set of valid items when the corresponding task is actually completed, the rule version is consistent, and the result tuple is successfully persisted; different reasons are recorded for non-enqueueing, execution exceptions, and write-back rejections.

[0053] Evidence coverage 760 uses the machine-readable review configuration statement's evidence location requirements as the expected set of items. Results containing an object identifier and source location locator corresponding to the current source file summary are included in the valid item set; results with only natural language descriptions but without locating the source data are not considered valid evidence.

[0054] The coverage status determination process first handles excluded items, then checks for missing hard dependencies. If no item is missing, the system is considered covered; if all hard dependencies are satisfied but optional dependencies are missing, the system is considered partially covered; if at least one required item of a hard dependency is in the missing set, the system is considered blocked.

[0055] The reason codes use machine-comparable enumeration values. For example, IN_MISSING indicates missing input, IN_DIGEST_MISMATCH indicates inconsistent digests, PARSE_FAILED indicates parsing failure, OBJ_UNSUPPORTED indicates unsupported object type, REL_MISSING indicates relation extraction failure, RULE_NOT_RUN indicates rule not executed, RULE_ERROR indicates rule exception, and EVIDENCE_UNLOCATABLE indicates evidence cannot be located.

[0056] A coverage snapshot includes a snapshot identifier, a baseline identifier, a review configuration version, all coverage records, and a generation time. A unique run identifier is generated at the start of each review run. This run identifier is bound to the baseline identifier and the coverage snapshot identifier and written to the task record generated for this review run. After a review run begins, the current task can only read this snapshot; changes to coverage records (such as new inputs, new parsing results, or rule coverage updates) generate new coverage snapshots, without modifying the snapshot currently in use.

[0057] like Figure 3 As shown, a directed dependency graph contains at least coverage item nodes and machine-executable check nodes, and may also include result nodes, issue item nodes, and report snapshot nodes. Coverage item nodes correspond to coverage records or their coverage topics. Each edge from a coverage item node to a check node records the dependency type, minimum coverage state, object scope, allowed degradation conditions, and dependency version.

[0058] In one implementation, the coverage snapshot has a snapshot type field, which includes an admission type and a result type. Admission type coverage snapshots are generated before machine-executable checks enter the processor execution queue and serve as read objects for task gating and change detection. Result type coverage snapshots are generated as rule coverage or evidence coverage is updated during check execution and are bound to the corresponding processing attempt identifier. The change detector only selects two snapshots from the admission type coverage snapshots that have the same object range and a valid sequential relationship for comparison. Result type coverage snapshots are not written to the change detection input set and are not used as trigger sources for re-evaluation tasks. The storage layer can structurally prevent result writes from triggering duplicate evaluations of themselves by using check constraints to make the re-evaluation routing field of the result type snapshot record null, or by using foreign key constraints to ensure that re-evaluation event records can only reference admission type coverage snapshots.

[0059] Hard dependencies indicate that a technically valid result cannot be obtained when a PCB footprint is missing. For example, a PCB footprint existence check has a hard dependency on printed circuit board device objects covering it; the check is not invoked if no PCB object exists.

[0060] Optional dependencies mean that a limited range of checks can still be performed even when they are missing, but the gaps must be documented and the validity of the results limited. For example, consistency between schematic and PCB package names can use the manufacturer's recommended package information as an optional dependency.

[0061] The scheduler 640 checks each incoming edge. If a hard dependency is not satisfied, the scheduler does not create an execution container, allocate processor time, or read large amounts of geometric data, and writes the UNKNOWN result record and the missing item set.

[0062] If all hard dependencies and all optional dependencies are satisfied, the scheduler generates a normal execution task; if all hard dependencies are satisfied but at least one optional dependency is not satisfied, the scheduler generates a degraded execution task based on the allowed degradation conditions. If degradation is not allowed in the configuration, the check is still written as unknown and not enqueued.

[0063] The task log must include at least the read-only address of the frozen baseline, the baseline identifier, the run identifier, the overwrite snapshot identifier, the check identifier, the object scope, the rule version, the result validity cap, and the processing attempt identifier. The degradation task also includes the missing set of optional dependencies.

[0064] The task executor can be a process, thread, container, workflow activity, or remote compute node. Regardless of the execution method, the executor must read frozen data according to the task record and write a summary of the actual input read into the result tuple.

[0065] The result tuple can be represented as R=(B,C,K,V,O,E,S,L,A), where B is the baseline identifier, C is the coverage snapshot identifier, K is the inspection identifier, V is the rule version, O is the object scope, E is the evidence location set, S is the result status, L is the upper limit of result validity, and A is the processing attempt identifier.

[0066] The resulting state S includes at least PASSED, FAILED, UNKNOWN, NOT_EVALUATED, and NOT_APPLICABLE. PASSED indicates that the check was actually performed on the declared object scope and the overridden snapshot and the decision conditions were met; FAILED indicates that the check was actually performed and the conditions were not met.

[0067] UNKNOWN indicates that a hard dependency is missing, the allowed scope of degradation is insufficient, execution is abnormal, or the evidence cannot meet the minimum requirements, and the system cannot make a pass or fail conclusion; NOT_EVALUATED indicates that the check has not yet entered the current execution; NOT_APPLICABLE indicates that the machine-readable review configuration is explicitly excluded.

[0068] like Figure 4 As shown, the domain state is generated through a finite state summary table. If any required check is FAILED, the domain state is FAILED; otherwise, if UNKNOWN or NOT_EVALUATED exists, the domain state is UNKNOWN; the domain state is PASSED only if all required checks are PASSED or NOT_APPLICABLE.

[0069] The validity upper limit L is the lowest value among the method eligibility upper limit, engineering object coverage upper limit, evidence coverage upper limit, and output strategy upper limit. The method eligibility upper limit is pre-configured based on the type of method used in the machine-executable check; for example, the method eligibility upper limit for deterministic rules and graph computation can be configured to be higher than that for probabilistic models. The upper limit can be represented using ordered enumeration to allow the processor to perform a constant number of comparisons.

[0070] The formal issue queue and write threshold settings are configured via an identifier field. When the result status is UNKNOWN or the result validity limit is below the threshold, write operations are blocked, and the reason code, the set of missing items, and a reference to the original result tuple are saved in a machine-readable report.

[0071] In the first electronic hardware embodiment, the input includes a schematic diagram, a bill of materials (BOM), and a PCB file. The parser generates records of schematic components, BOM entries, PCB components, nets, and package relationships.

[0072] If the bill of materials and schematic diagram are complete but the PCB file is missing, the hard dependencies of the material manufacturer part number check and quantity-reference number consistency check are met and the material is queued; the hard dependencies of the PCB package existence check and board-level pitch check are not met, so the material is not queued and is written as UNKNOWN.

[0073] Assume that the machine-readable review configuration in this embodiment has twenty required checks, seven of which have hard dependencies on PCB objects. When a PCB file is missing, the processor execution queue only receives the remaining thirteen checks, thus reducing check calls by seven compared to unconditional scheduling; this number is directly determined by the dependency graph and the missing set.

[0074] If the PCB file exists but complex copper area objects are not parsed, package checks relying on ordinary component objects can be performed, but power plane checks relying on the complete copper area topology are unknown due to relationship coverage blocking. A power plane check cannot be considered passed simply because it did not generate any problematic items.

[0075] If the schematic and PCB component objects are complete but the manufacturer's recommended package information is missing, the package name and pad quantity checks can be performed as a configuration fallback. The result tuple records the missing optional dependencies and limits the validity of the results to suggestive.

[0076] Different review domains maintain their status and queues independently. The material domain can be PASSED, the PCB domain can be UNKNOWN, and the thermal domain can be NOT_APPLICABLE; the overall operation record is written to PARTIAL_COMPLETION and lists the status of each domain, instead of simplifying the overall status to a single success identifier.

[0077] Manual coverage verification records are stored in a separate table or document, containing the verification subject, time, baseline identifier, known gaps, and reasons for degradation. The coverage calculation module does not read manual verification records to change the expected or valid item set.

[0078] like Figure 5 As shown, the change detector compares the baseline identifier, set of valid items, set of missing items, and coverage status of two consecutive coverage snapshots, and compares the rule version, parser version, engineering mode version, or evidence version of the dependent edges.

[0079] Nodes or edges corresponding to decreased coverage, removal of valid items, addition of missing items, or changes in dependency versions are added to the traversal queue. This affects the localization module's traversal along outgoing edges, checking nodes, result nodes, problem item nodes, and report snapshot nodes.

[0080] Traversal can be performed using breadth-first or depth-first search, and a visited set is used to prevent duplicate visits. In the adjacency list implementation, the traversal time complexity is O(|V|+|E|), where |V| and |E| are the number of nodes and edges actually visited, respectively.

[0081] Checks encountered during the iteration are added to the re-evaluation set, while results, issue items, and report snapshots encountered during the iteration are added to the invalidation set. For checks not in the re-evaluation set, new reports can continue to reference the original result tuples, avoiding duplicate calculations.

[0082] In one implementation, for machine-executable checks not in the re-evaluation set, a double-match check is performed before maintaining the original result tuple reference: First, the content summary of the actual read input recorded in the original result tuple is compared with the content summary of the corresponding input in the current frozen engineering design baseline. Second, the rule version of the original result tuple is compared with the rule version of the corresponding check in the current machine-readable review configuration, and the upper limit of the result validity of the original result tuple is compared with a preset output threshold. If all matches and the upper limit of result validity is not lower than the output threshold, the original result tuple reference is maintained; if any match occurs, the result tuple is reclassified as an affected result, marked as invalid, and the corresponding check is added to the re-evaluation set. This check ensures that cross-baseline result reuse only occurs when the input within the object scope remains unchanged and the review context is consistent.

[0083] Before generating a re-evaluation task, the transaction first changes the current result pointers in the failure set to a failure state or lowers the result validity cap before committing the re-evaluation task. If the task commit fails, historical results retain their failure markers to prevent old results from being reused.

[0084] In the parser upgrade embodiment, the input file digest remains unchanged, but the PCB parser version changes and a new copper area object is added. The changes include parsing overriding and copper area object overriding; the affected closures only contain checks that depend on the copper area object or relationships.

[0085] In the rule version change implementation, only one encapsulated rule version changes. The impact is located starting from the dependency edge or check node, and only the results, issue items, and report paragraphs generated by that rule are invalidated; the material availability check is not rerun.

[0086] Each review run generates a run identifier, and each first execution or retry generates a different processing attempt identifier A. The current task record in the results store saves the run identifier, check identifier, A, and corresponding baseline identifier B that are allowed to be written.

[0087] The write-back transaction compares the run flag, check flag, A, B, the actual input summary, and the object version within the object scope. Specifically, the run flag, check flag, A, and B are compared to their corresponding values ​​stored in the current task record; the actual input summary is compared to the input summary in the frozen engineering design baseline; and the object version is compared to the current object version in the engineering object record within the object scope. If the old task arrives late after the new task completes, and the run flag, A, or B does not match, the storage layer writes the callback to the rejection log without changing the current result pointer.

[0088] The resulting tuples and overlay snapshots can be stored in a relational database, document database, or object store, and the directed dependency graph can be stored in a relational table, graph database, or in-memory adjacency list. Changes in storage implementation do not alter the overlay set, dependency gating, result invalidation, and attempt-to-validate semantics of this invention.

[0089] The rule, graph computation, numerical computation, or model execution module 650 can employ deterministic rules, graph traversal, simulation, knowledge retrieval, or probabilistic models. When using a probabilistic model, the model output must still be bound to the object scope and evidence location set, and is subject to the upper limit of the result validity.

[0090] The computer system can be deployed on local workstations, private clouds, or hybrid environments. For large volumes of PCB geometry data, a hard-rely-on-queue gating system is implemented before initiating subsequent parsing checks or remote transmission, thereby reducing invalid data readings and transmissions.

[0091] Electronic devices may include one or more processors, memory, storage interfaces, and network interfaces. When a program in memory is executed by a processor, it performs baseline generation, coverage calculation, dependency graph construction, task gating, result persistence, effect traversal, result invalidation, and write-back verification.

[0092] When verifying the effectiveness of the technology, scenarios such as missing input, unsupported object type, failed relation extraction, rule anomaly, decreased coverage, rule upgrade, and late callback can be constructed respectively. The number of enqueue checks, the number of blocked checks, the number of erroneous writes that pass, the number of affected closure nodes, the number of actual re-evaluations, and the number of old callback rejections can be recorded.

[0093] Under the same engineering design baseline and machine-readable review configuration, the number of enqueued checks is equal to the number of checks that satisfy hard dependencies and meet the conditions for allowing degradation; compared with unconditional scheduling, the number of reduced check calls is equal to the number of checks that are blocked because hard dependencies are not satisfied or degradation is not allowed.

[0094] When the overriding or dependency version only affects some nodes, the actual number of re-evaluations is equal to the number of checks in the affected closure, not the total number of checks; unaffected results are reused by referencing result tuples, reducing redundant computations and storage writes.

[0095] The above embodiments provide specific implementations of engineering design documents, parsing records, coverage sets, state determination, dependency graphs, task records, result tuples, influence traversal, and write-back transactions, enabling those skilled in the art to implement this invention.

Claims

1. A method for coverage-driven orchestration and result failure control of engineering review tasks, executed by a computer system, used to process electronic hardware engineering design data, characterized in that, include: For engineering design files containing at least two types of documents, including schematic files, bill of materials, and printed circuit board design files, a content summary is calculated. A parser corresponding to the file format generates engineering object records and engineering relationship records, and a frozen engineering design baseline is formed by the content summary and parser version. A baseline identifier for the frozen engineering design baseline is also generated. Read the machine-readable review configuration, which declares the review domain, expected input items, expected object types, expected relationship types, machine-executable checks, evidence location requirements, and dependencies of the machine-executable checks. Establish coverage records for six coverage dimensions: input, parsing, engineering objects, engineering relationships, rules, and evidence. Each coverage record includes at least a set of expected items, a set of valid items, a set of excluded items, a set of missing items, a coverage status, and a reason code. Rule coverage and evidence coverage are updated as checks are actually executed and evidence location results are obtained. Generate a coverage snapshot with a coverage snapshot identifier. This snapshot is bound to the baseline identifier and contains all coverage records at the time of generation. Changes to coverage records generate new coverage snapshots without modifying existing ones. Construct a directed dependency graph that includes at least coverage item nodes and machine-executable check nodes. Each dependency edge from a coverage item node to a machine-executable check node records at least a hard dependency or optional dependency, minimum coverage status, object scope, and dependency version. Traverse the incoming edges of each machine-executable check. If any hard dependency does not reach the minimum coverage status, prevent the corresponding machine from executing. The process involves checking items entering the processor execution queue and writing an unknown state record containing the missing item set and cause code. When all hard dependencies reach the minimum coverage state, a normal execution task or a degraded execution task is generated based on the satisfaction of optional dependencies. The normal execution task or degraded execution task is executed, and a result tuple is persisted. The result tuple includes at least the baseline identifier, the coverage snapshot identifier, the check identifier, the rule version, the object scope, the evidence location set, the result status, the result validity upper limit, and the processing attempt identifier. When a change in coverage record or dependency version is detected, the directed dependency graph is traversed starting from the changed coverage item node or dependency edge to obtain the closure of the affected machine-executable checks. The result tuple referencing the affected machine-executable checks is identified as the affected result. Before generating a re-evaluation task, the affected result is atomically marked as invalid or the result validity upper limit is reduced. Historical references to unaffected results are maintained. Only the affected machine-executable checks are submitted to the processor execution queue. When writing back the result, the processing attempt identifier and the baseline identifier are verified to reject the old processing attempt from covering the current result.

2. The method according to claim 1, characterized in that, The project object record includes at least an object identifier, object type, field set, source file summary, source location locator, and parser version; the project relationship record includes at least a relationship identifier, relationship type, start object identifier, end object identifier, source location locator, and parser version; the source location locator includes at least one of the following: file hierarchical path, page number, coordinates, cell, network name, tag number, or object sequence number; for the d-th coverage dimension, the expected item set is denoted as E_d, the valid item set as V_d, and the excluded item set as X_d, the valid denominator D_d is the number of elements in the difference between set E_d and set X_d, the coverage numerator N_d is the number of elements in the intersection of set V_d and the difference set, and the missing item set M_d is... The difference set is the difference between the difference set and the set V_d; the coverage record stores D_d, N_d, and M_d simultaneously, instead of only storing the coverage ratio obtained from N_d and D_d; the coverage status includes covered, partially covered, blocked, and out of range; it is determined to be covered when the missing item set is empty, partially covered when all expected items corresponding to hard dependencies are valid and at least one expected item corresponding to an optional dependency is missing, blocked when at least one expected item corresponding to a hard dependency is missing, and out of range when the machine-readable review configuration explicitly excludes the corresponding item; different reason codes are used for input missing, summary inconsistency, parsing failure, unsupported object type, relation extraction failure, rule not executed, rule execution abnormality, and evidence cannot be located.

3. The method according to claim 1, characterized in that, Each review run generates a run identifier, and each task's first execution or retry generates a different processing attempt identifier; Generating a normal execution task or a degraded execution task includes: writing the read-only address of the frozen engineering design baseline, the baseline identifier, the run identifier, the coverage snapshot identifier, the check identifier, the object scope, the rule version, and the processing attempt identifier into the task record; for degraded execution tasks, the set of unmet optional dependencies and the upper limit of result validity are also written into the task record; the task executor only reads the frozen data pointed to by the task record and prohibits new parsing results arriving during the run from changing the current coverage snapshot; the current task record stores the run identifier, check identifier, processing attempt identifier, and baseline identifier that are allowed to be written; the engineering object record has an object version, which changes with the field set, source file digest, or parser version of the corresponding engineering object record; the result write operation compares the run identifier, check identifier, processing attempt identifier, and baseline identifier carried by the callback with the corresponding values ​​stored in the current task record within the same transaction, and compares the content digest and object version of the actual read input carried by the callback with the input content digest in the frozen engineering design baseline and the current object version of the engineering object record within the object scope, respectively, and updates the current result pointer only if all are consistent, otherwise the callback is written to the rejection log without changing the current result.

4. The method according to claim 1, characterized in that, The result status includes Pass, Fail, Unknown, Unevaluated, and Inapplicable. Review domain statuses are generated according to a pre-stored finite status summary table, where Fail has higher priority than Unknown, and Unknown has higher priority than Pass. Unknown and Unevaluated statuses are not counted in the pass count. A review domain is only marked as Pass when all required checks for that review domain pass or it is determined as Inapplicable by a machine-readable review configuration. The result validity upper limit is the lowest value among the method eligibility upper limit, engineering object coverage upper limit, evidence coverage upper limit, and output strategy upper limit. The method eligibility upper limit is pre-configured based on the method type used for the machine-executable check. When the result status is Unknown or the result validity upper limit is lower than a preset output threshold, the corresponding result is prohibited from being written to the formal issue queue or pass flag field, and the cause code and missing item set are written to a machine-readable report. Each review domain has independent domain statuses and processor execution queues. When a review domain generates an Unknown status due to a hard dependency not being met, another review domain without a dependency path to that review domain continues execution, and a partial completion status, baseline identifier, coverage snapshot identifier, and domain status for each review domain are written to the overall execution record.

5. The method according to claim 1, characterized in that, The directed dependency graph also includes result nodes, issue item nodes, and report snapshot nodes; Obtaining the closure and determining the affected result includes: adding nodes or edges corresponding to decreased coverage, changes in the set of valid items, or changes in dependency versions to the traversal queue; performing breadth-first or depth-first traversal along the outgoing edges between coverage item nodes, machine-executable check nodes, result nodes, issue item nodes, and report snapshot nodes; adding the traversed machine-executable checks to the re-evaluation set, and adding the traversed results, issue items, and report snapshots to the failure set; maintaining the original result tuple reference for checks not in the re-evaluation set, wherein maintaining the original result tuple reference includes: comparing the content summary of the actual read input recorded in the result tuple with the content summary of the corresponding input in the current frozen engineering design baseline, and comparing the rule version of the result tuple with the rule version of the corresponding machine-executable check in the current machine-readable review configuration; maintaining the reference only when all of the above match and the upper limit of the result validity of the result tuple is not lower than the preset output threshold; if any item does not match, the result tuple is determined as an affected result, marked as failure, and the corresponding machine-executable check is added to the re-evaluation set.

6. The method according to claim 1, characterized in that, The coverage snapshot has a snapshot type, which includes an admission type and a result type. The coverage snapshot generated before the machine-executable check enters the processor execution queue is an admission type. The new coverage snapshot generated due to rule coverage or evidence coverage as the check is actually executed and the evidence location results are updated is a result type, and the coverage snapshot of the result type is bound to the processing attempt identifier that generated the coverage snapshot. When detecting changes in coverage records, only the coverage snapshot of the admission type is used as the before-and-after comparison object, and the coverage snapshot of the result type is not used as the trigger source for generating a re-evaluation task.

7. The method according to claim 1, characterized in that, Manual coverage confirmation records and coverage calculation records are stored separately. The manual coverage confirmation record includes the confirmation subject, confirmation time, baseline identifier on which the confirmation is based, known gaps, and reasons for degradation. Writing to the manual coverage confirmation record does not modify the expected item set, the valid item set, and the missing item set, does not rewrite blocking as covered, and does not rewrite unknown as passed.

8. A coverage-driven orchestration and result failure control system for engineering review tasks, used to process electronic hardware engineering design data, characterized in that, include: The baseline generation module is used to summarize and parse at least two types of calculation content in schematic files, bill of materials and printed circuit board design files into engineering object records and engineering relationship records, form a frozen engineering design baseline and generate a baseline identifier; The coverage calculation module is used to generate coverage records for six coverage dimensions—input, parsing, engineering objects, engineering relationships, rules, and evidence—according to the machine-readable review configuration. These records include expected item sets, valid item sets, excluded item sets, missing item sets, coverage status, and cause codes. It also generates a coverage snapshot with a coverage snapshot identifier and bound to the baseline identifier. The dependency graph and scheduling module is used to construct a directed dependency graph that includes at least coverage item nodes and machine-executable check nodes. Dependency edges from coverage item nodes to machine-executable check nodes have hard or optional dependency attributes, and a minimum coverage state. When a hard dependency does not reach the minimum coverage state, the corresponding machine-executable check is prevented from entering the processor execution queue and written to an unknown state record. When a hard dependency reaches the minimum coverage state, a normal execution task or a degraded execution task is generated. The result consolidation module is used to persist result tuples containing the baseline identifier, the coverage snapshot identifier, the inspection identifier, the rule version, the object range, the evidence location set, the result status, the result validity limit, and the processing attempt identifier; And a failure re-evaluation module, used to traverse the directed dependency graph to obtain the closure of the affected machine executable check when the overwrite record or dependency version changes, identify the result tuple referencing the affected machine executable check as the affected result and invalidate it first, submit only the affected machine executable check to the processor execution queue, and reject the old processing attempt to write back by verifying the processing attempt identifier and baseline identifier.

9. An electronic device comprising a processor and a memory, characterized in that, The memory stores a computer program that, when executed by the processor, implements the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 7.

Images