An electronic equipment test process architecture and a method of constructing the same

Abstract

The application relates to the technical field of electronic equipment adjustment and test, and discloses an electronic equipment adjustment and test process architecture and a construction method thereof, wherein the method comprises the following steps: constructing a multilevel adjustment and test process architecture, wherein the adjustment and test process architecture comprises a top scheme layer, a middle core layer, a bottom operation layer and an auxiliary support layer; based on the adjustment and test process architecture, adjustment and test process files of each level are compiled, wherein the adjustment and test process files comprise an adjustment and test process integration outline, a process material list, a standard operation procedure and an auxiliary process file; and a mapping relationship between the adjustment and test process files of each level is established, so that hierarchical correlation management of the adjustment and test process files is completed. The application realizes standardized, hierarchical and traceable management of various process files of the adjustment and test process system, and improves adjustment and test efficiency and quality stability.

Description

Technical Field

[0001] This invention relates to the field of electronic equipment debugging and testing technology, and in particular to an electronic equipment debugging and testing process architecture and its construction method. Background Technology

[0002] With the increasing integration and complexity of electronic information equipment, its debugging and testing process has become increasingly complex, involving multiple stages such as hardware debugging, software testing, and system integration. The corresponding process document system is disorganized, with many types of process documents. Furthermore, traditional debugging and testing process documents are mostly paper documents or simple spreadsheets, which have problems such as loose structure, unclear hierarchy, poor reusability, and difficulty in traceability.

[0003] Existing technologies mostly focus on the management of single-type documents or local process optimization, failing to achieve collaborative linkage across all levels and document types. For example, CN113378529B discloses a method, apparatus, equipment, and storage medium for compiling process documents. It automatically generates process documents by setting process codes generated by function location codes and compiling them according to the established process document association relationships. However, it involves the architectural design of debugging process documents, document association, and traceability management, making it difficult to solve the core problems of chaotic process documents and poor association. Another example is CN116450666B, which discloses a method, apparatus, and storage medium for updating PBOM. It uses EBOM as the design bill of materials, obtains a preset PBOM (process bill of materials), and determines the PBOM to be updated based on the preset PBOM. However, it does not deeply associate PBOM with SOP (standard operating procedures), resulting in a disconnect between material management and debugging operations, and failing to support standardized debugging operations.

[0004] Furthermore, while some enterprises have introduced electronic testing systems or platforms, achieving a certain degree of automation in the testing process, they still lack a systematic hierarchical architecture design for process document management. Various process documents remain scattered and managed independently, failing to form an organic whole. Version management, change control, and traceability of process documents still rely on manual processes, which is not only inefficient but also prone to problems such as version inconsistencies, inconsistent requirements, and difficulties in traceability. This makes it difficult to meet the refined, systematic, and traceable requirements of complex electronic information equipment debugging and testing processes for process document management. Summary of the Invention

[0005] To address the problems of disorganized process documents, poor correlation, insufficient guidance, and weak traceability in existing electronic information equipment debugging and testing processes, this invention proposes an electronic equipment debugging and testing process architecture and its construction method. Through a clear hierarchical architecture design, core document integration, auxiliary document supplementation, and the establishment of hierarchical mapping relationships, the invention achieves standardized, regulated, and hierarchical management of debugging and testing process documents, improves debugging and testing efficiency, reduces debugging and testing error rates, ensures the stability of electronic information equipment debugging and testing quality, and enables full-process traceability of process documents, providing support for process optimization.

[0006] The technical solution adopted in this invention is as follows: A method for constructing a process architecture for debugging and testing electronic equipment includes: A multi-level debugging and testing process architecture is constructed, which includes a top-level solution layer, a middle-level core layer, a bottom-level operation layer, and an auxiliary support layer. Based on the aforementioned debugging and testing process architecture, debugging and testing process documents for each level are compiled. These debugging and testing process documents include a debugging and testing process integration outline, a process material list, standard operating procedures, and auxiliary process documents. Establish mapping relationships between debugging and testing process documents at different levels to complete hierarchical association management of debugging and testing process documents.

[0007] Furthermore, the construction of the multi-level debugging and testing process architecture includes: The top-level solution layer serves as the guiding level of the debugging and testing process architecture, defining the overall goals, scope, and organizational management requirements of the debugging and testing. The middle-level core layer serves as the core connecting level of the debugging and testing process architecture, providing the specific implementation basis for the debugging and testing process. The bottom-level operation layer serves as the execution level of the debugging and testing process architecture, directly guiding the specific operations at the debugging and testing site. The auxiliary support layer serves as the guarantee level of the debugging and testing process architecture, providing a unified and standardized basis for the compilation, review, and management of debugging and testing process documents at each level.

[0008] Furthermore, the method for compiling the debugging and testing process integration outline includes: Based on the product specifications and testing requirements of electronic equipment, determine the process development requirements and testing scope; plan the overall integration process from the perspective of the entire product system, and sort out the hierarchical relationship and material composition of each integration sub-process; sort out the overall testing process for each integration sub-process, clarify the sequence and connection requirements of each link, and divide the testing phases; allocate corresponding manufacturing resources for each integration sub-process, and clarify the usage requirements of manufacturing resources; evaluate the integration cycle of each integration sub-process, and obtain the total integration cycle of the entire system; assess the technical and resource risks that may occur during the integration process.

[0009] Furthermore, the method for compiling the process bill of materials includes: Based on the process requirements of the debugging and testing process integration outline, and combined with the design bill of materials (BOM) for electronic equipment, a process BOM is constructed with the process path as the core and the process-level resource requirements as support. The process BOM includes process path information, clarifying the sequence and logical relationships of each process; process-level personnel requirements, specifying the job types and quantities of personnel needed for each process; process-level workstation and instrument requirements, specifying the equipment and tooling required for each process; and process-level material and time requirements, specifying the material consumption and time quotas for each process. The process BOM content is presented through a combination of process path diagrams and various resource requirement tables.

[0010] Furthermore, the method for developing the standard operating procedure includes: Based on the requirements of the commissioning and testing process integration outline and process bill of materials, standardized operating procedures are designed for each commissioning and testing process. Operational precautions and safety requirements are set in the standard operating procedures. Specifications and usage requirements for tooling, instruments, and fixtures are also defined in the standard operating procedures. Each commissioning and testing process is broken down into specific operational steps, clarifying the operational content, methods, and sequence, and highlighting key operational points. Relevant operational parameters are specified for each operational step, and operational standards are quantified. The recording content, recording method, and recording time requirements for each operational step are clearly defined. An update mechanism for the standard operating procedures is established, and operational steps are optimized synchronously with the process bill of materials version updates to ensure consistency with the process bill of materials.

[0011] Furthermore, the method for compiling the auxiliary process documents includes: Develop system management standard documents to clarify the processes for preparing, reviewing, issuing, and archiving process documents at each level; develop hierarchical classification standard documents to unify the classification rules and naming conventions for debugging and testing process documents at each level; develop templates for preparing debugging and testing process documents at each level to standardize the format structure and content requirements of process documents; develop process document review standards to clarify the key points for reviewing debugging and testing process documents at each level, approval authority, and signing and approval process; develop process document archiving standards to specify the storage methods, version management rules, and access permissions for documents; and develop process document update standards to clarify the triggering conditions, change process, and synchronization requirements for document changes.

[0012] Furthermore, establishing the mapping relationship between the debugging and testing process documents at each level includes: Establish a vertical guidance mapping relationship from the top-level scheme layer to the middle core layer, so that the requirements of the debugging and testing process integration outline can be transmitted and guide the compilation of the process bill of materials; establish a vertical constraint mapping relationship from the middle core layer to the bottom operation layer, so that the process and resource requirements of the process bill of materials can constrain the operation flow and resource use of the standard operating procedures; establish a standardization mapping relationship from the auxiliary support layer to other levels, so that auxiliary process documents can provide a unified standard basis and template support for the writing of debugging and testing process documents at all levels; establish a two-way traceability mapping relationship between debugging and testing process documents at all levels, so as to realize forward traceability from the top-level scheme to the bottom operation and reverse traceability from the bottom operation to the top-level scheme.

[0013] Furthermore, establishing the mapping relationship between the debugging and testing process documents at each level also includes: A dynamic maintenance mechanism for mapping relationships is established. When any debugging process document is updated or its content is modified, the compatibility of related documents is checked simultaneously and corresponding updates are triggered. When the process bill of materials is adjusted, the corresponding standard operating procedure's operation steps and the mapping relationship between them are updated simultaneously. When the debugging process integration outline undergoes process changes, the process path of the process bill of materials and the mapping relationship between them are adjusted simultaneously. When the auxiliary process documents are updated, the format and content requirements of related documents at each level are checked and revised simultaneously. After each mapping relationship update, the consistency and relevance of debugging process documents at each level are re-verified.

[0014] Furthermore, the hierarchical association management of the debugging and testing process documents includes: Based on hierarchical mapping relationships, a complete traceability link is constructed from the top-level solution to the bottom-level operation. Through the debugging and testing process integration outline, the corresponding complete process material list and standard operating procedures can be traced. Through the process material list, the corresponding design source basis and specific operating procedures can be traced. Through the standard operating procedures, the corresponding process requirements and resource allocation can be traced. Through the on-site operation records, the corresponding process document requirements and design source can be traced back. By using the full-process traceability link, the source of problems in the debugging and testing process can be located, providing data support for process optimization and quality improvement.

[0015] An electronic equipment debugging and testing process architecture includes a top-level solution layer, a middle-level core layer, a bottom-level operation layer, and an auxiliary support layer. The top-level solution layer includes a debugging and testing process integration outline, which specifies the overall goals, scope, and integration process planning for debugging and testing. The middle core layer contains a process material list, which is used to carry the process path and resource allocation requirements of the debugging and testing process; The underlying operation layer has standard operating procedures to guide the specific operation execution at the debugging and testing site; The auxiliary support layer is equipped with auxiliary process documents, which provide a unified standard basis for the preparation of process documents at each level. The top-level scheme layer and the middle core layer are respectively connected by vertical mapping relationships, and the middle core layer and the bottom operation layer are respectively connected by standardized mapping relationships between the auxiliary support layer and the other layers, so as to realize the hierarchical association management and traceability of debugging and testing process documents.

[0016] The beneficial effects of this invention are as follows: 1. This invention constructs a multi-level debugging and testing process architecture comprising a top-level scheme layer, a middle-level core layer, a bottom-level operation layer, and an auxiliary support layer. Corresponding debugging and testing process documents are compiled according to each architecture level, and mapping relationships are established between documents at each level. This enables systematic and hierarchical management of debugging and testing process documents as a whole. Compared to the traditional decentralized process document management model, this multi-level architecture can organically organize and classify various debugging and testing process documents, ensuring that different types and levels of documents perform their respective functions and are interconnected. This effectively improves the problems of chaotic and unclear process document systems, enhancing the orderliness and standardization of process document management. Furthermore, by establishing mapping relationships between documents at each level, collaborative linkage between process documents can be achieved, avoiding the problems of independent documents and inconsistent requirements, laying the foundation for standardized management of debugging and testing processes.

[0017] 2. This invention, by clearly defining the functional positioning of each level and compiling targeted process documents, enables process documents at different levels to fully play their respective roles. The top-level commissioning and testing process integration outline provides clear overall guidance for the entire commissioning and testing work, ensuring that the work has clear objectives and scope; the middle-level process bill of materials integrates various resource requirements at the process level with the process path as the core, achieving refined management and rational allocation of commissioning and testing resources; the bottom-level standard operating procedures provide specific and detailed standardized guidance for on-site operations, effectively reducing human error and improving the consistency and stability of commissioning and testing operations; auxiliary process documents provide unified specifications and standard support for the operation of the entire system, improving the standardization of process document compilation and the orderliness of management. The mutual cooperation and synergy of documents at each level can comprehensively improve the overall quality and practicality of commissioning and testing process documents.

[0018] 3. This invention establishes a multi-dimensional mapping relationship and a dynamic maintenance mechanism between process documents at various levels, enabling full lifecycle management and synchronous updates of process documents. When a document changes, the mapping relationship can quickly locate the affected related documents and trigger corresponding synchronous updates, effectively avoiding inconsistencies in requirements and standards caused by asynchronous document changes, ensuring the consistency and coordination of the entire process document system. Simultaneously, the end-to-end traceability link built based on the hierarchical mapping relationship enables forward tracing from the top-level solution to the bottom-level operation and reverse tracing from the bottom-level operation to the top-level solution. When problems occur during debugging and testing, the source and cause of the problem can be quickly located, shortening the troubleshooting time and providing data support for process optimization and quality improvement.

[0019] 4. This invention effectively solves the problems of chaotic system, unclear hierarchy, poor correlation, low reusability, and difficulty in traceability in traditional debugging and testing process document management, thereby improving the systematization, structuring, and refinement of debugging and testing process management. The application of this method can help enterprises establish a standardized, efficient, and traceable debugging and testing process document system, improve the retrieval efficiency and reuse rate of process documents, reduce repetitive compilation work, reduce human error, and shorten the debugging and testing cycle. It plays a positive role in improving the debugging and testing efficiency and quality stability of electronic information equipment. Attached Figure Description

[0020] Figure 1 This is a flowchart of a method for constructing an electronic equipment debugging and testing process architecture according to Embodiment 1 of the present invention.

[0021] Figure 2 This is a schematic diagram of an electronic equipment debugging and testing process architecture according to Embodiment 1 of the present invention.

[0022] Figure 3 This is an integrated outline content framework diagram of Embodiment 1 of the present invention.

[0023] Figure 4 This is a framework diagram of the PBOM (Bill of Materials) content of Embodiment 1 of the present invention.

[0024] Figure 5 This is a framework diagram of the SOP (Standard Operating Procedure) of Embodiment 1 of the present invention.

[0025] Figure 6 This is a mapping diagram of the multi-level debugging and testing process document system in Embodiment 1 of the present invention.

[0026] Figure 7 This is the overall scheme planning architecture diagram of Embodiment 2 of the present invention.

[0027] Figure 8 This is a process flow diagram of Embodiment 2 of the present invention.

[0028] Figure 9 This is a system connection diagram of Embodiment 2 of the present invention. Detailed Implementation

[0029] To provide a clearer understanding of the technical features, objectives, and effects of the present invention, specific embodiments are now described. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention; that is, the described embodiments are only a part of the embodiments of the invention, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0030] Example 1 like Figure 1 As shown, this embodiment provides a method for constructing an electronic equipment debugging and testing process architecture, including: A multi-level debugging and testing process architecture is constructed, which includes a top-level solution layer, a middle-level core layer, a bottom-level operation layer, and an auxiliary support layer. Based on the aforementioned debugging and testing process architecture, debugging and testing process documents for each level are compiled. These debugging and testing process documents include a debugging and testing process integration outline, a process material list, standard operating procedures, and auxiliary process documents. Establish mapping relationships between debugging and testing process documents at different levels to complete hierarchical association management of debugging and testing process documents.

[0031] Preferably, constructing a multi-level debugging and testing process architecture includes: firstly, systematically reviewing the entire process of electronic equipment debugging and testing, clarifying all types of process documents involved in the debugging and testing process and their interrelationships. Based on this, according to the functional positioning and hierarchical role of the process documents, the entire debugging and testing process system is divided into four levels. The top-level solution layer is located at the top of the entire architecture, serving as the guiding document level for the entire system, providing overall guidance and standardization for the entire debugging and testing process system; the middle-level core layer is located below the top-level solution layer, serving as the key hub connecting the top-level solution and the bottom-level operation, responsible for transforming the requirements of the top-level solution into specific implementation basis; the bottom-level operation layer is located at the bottom of the architecture, directly facing the operators at the debugging and testing site, providing specific operational guidance for on-site operations; the auxiliary support layer, as an independent support level, runs through the entire lifecycle of the other three levels, providing unified standard basis and standard support for the entire process management of the compilation, review, release, and updating of process documents at each level. The four levels are interconnected and work synergistically to jointly constitute a complete debugging and testing process architecture system.

[0032] It should be noted that by constructing the above-mentioned debugging and testing process architecture, the previously scattered and disorganized debugging and testing process documents can be systematically classified and hierarchically managed. This ensures that each type of process document has its own function and place, avoiding problems such as document chaos, unclear hierarchy, and ambiguous responsibilities. This lays a clear architectural foundation for subsequent process document preparation and management. Furthermore, the four-layer architecture design conforms to the logical relationship from macro to micro and from general to specific, making it easier for personnel at different levels to quickly find the required process documents, improving the retrieval efficiency and ease of use of process documents.

[0033] Preferably, based on the aforementioned debugging and testing process architecture, debugging and testing process documents for each level are compiled, including: after completing the overall design of the debugging and testing process architecture, process documents for each level are compiled according to their functional positioning. For the top-level solution layer, a debugging and testing process integration outline is compiled as the overall guiding document for the entire debugging and testing process; for the middle-level core layer, a process material list is compiled as the core basis for material management, resource allocation, and process connection during the debugging and testing process; for the bottom-level operation layer, standard operating procedures are compiled as standardized guidance documents for on-site debugging and testing operations; for the auxiliary support layer, various auxiliary process documents are compiled to provide unified specifications, standards, and templates for the compilation of process documents at each level. The compilation of process documents at each level strictly follows the hierarchical division requirements of the architecture design to ensure that the content of the documents matches the hierarchical positioning and avoid problems such as hierarchical misalignment or content overlap.

[0034] It should be noted that compiling corresponding process documents according to the architectural hierarchy ensures that each type of process document has a clear functional positioning and scope of application, avoiding content overlap or unclear responsibilities between different types of documents. At the same time, a top-down guiding relationship and a bottom-up supporting relationship are formed between documents at each level, making the entire process document system an organic whole, rather than a simple collection of isolated documents.

[0035] Preferably, a mapping relationship is established between debugging and testing process documents at each level to complete the hierarchical association management of these documents. This includes: after the process documents at each level are compiled, further establishing the association mapping relationship between these documents. By establishing clear association identifiers and correspondences between process documents at different levels, the documents at each level are no longer independent documents, but form an interconnected and traceable document network. The establishment of the mapping relationship includes vertical inter-level mapping and horizontal intra-level mapping. Vertical mapping mainly reflects the guiding and being guided, and constrained and being constrained relationships between different levels, while horizontal mapping mainly reflects the association relationship between different documents within the same level. By establishing a complete mapping relationship, hierarchical association management of debugging and testing process documents is achieved, enabling efficient querying, retrieval, updating, and tracing of process documents based on the mapping relationship.

[0036] It should be noted that by establishing mapping relationships between process documents at different levels, the problems of traditional process documents being independent and having poor correlation can be effectively solved, enabling collaborative linkage of process documents. When a document is changed, other affected documents can be quickly located through the mapping relationship, ensuring that related documents are updated synchronously and avoiding problems such as inconsistent document versions and conflicting requirements. At the same time, the establishment of mapping relationships also provides basic support for subsequent full-process traceability.

[0037] More preferably, such as Figure 2 As shown, the construction of the multi-level debugging and testing process architecture includes: using the top-level solution layer as the guiding level of the debugging and testing process architecture, defining the overall goals, scope, and organizational management requirements of the debugging and testing; using the middle-level core layer as the core connecting level of the debugging and testing process architecture, carrying the specific implementation basis of the debugging and testing process; using the bottom-level operation layer as the execution level of the debugging and testing process architecture, used to directly guide the specific operations at the debugging and testing site; and using the auxiliary support layer as the guarantee level of the debugging and testing process architecture, providing a unified standard for the compilation, review, and management of debugging and testing process documents at each level.

[0038] Specifically, when designing a multi-level commissioning and testing process architecture, the functional positioning and management requirements of each level should be clearly defined. For the top-level solution layer, as the highest level of the entire system, it is primarily responsible for defining the overall goals, scope of application, organizational structure, and management principles of the commissioning and testing, providing macro-level and guiding content without involving specific operational details or process requirements, ensuring the high degree of generalization and overall guidance of the top-level documents. For the middle-level core layer, as a crucial bridging layer, it must, on the one hand, inherit the overall requirements of the top-level solution layer, translating macro-level goals and principles into specific process paths and resource allocation schemes; on the other hand, it must provide the basis and constraints for the bottom-level operation layer, ensuring that on-site operations comply with overall process requirements. For the bottom-level operation layer, as the execution layer directly facing the production site, it mainly provides directly executable content such as specific operating steps, parameter requirements, and record-keeping standards, ensuring that operators can directly carry out their work based on the documents at this level. As for the auxiliary support layer, it is clearly defined as the basic guarantee layer of the entire system. It mainly provides various management specifications, standards, templates and other supporting documents. It does not directly specify the specific process content of commissioning and testing, but provides unified rules and standards for management activities such as the preparation, review, release and updating of process documents at all levels.

[0039] It should be noted that by clearly defining the functional positioning and management requirements of each level, it is possible to ensure that the process documents at each level have clear responsibilities and content boundaries, avoiding problems such as overlapping content and contradictory requirements between different levels of documents. At the same time, the clear division of functional positioning at each level also facilitates personnel in different positions and at different levels to quickly locate and use the corresponding process documents, improving the efficiency and accuracy of process document use.

[0040] More preferably, such as Figure 3 As shown, the method for compiling the integration outline of the debugging and testing process includes: determining the process development requirements and debugging and testing scope by combining the product specifications and debugging and testing needs of the electronic equipment; planning the overall integration process from the perspective of the entire product system, sorting out the hierarchical relationship and material composition of each integration sub-process; sorting out the overall debugging and testing process for each integration sub-process, clarifying the sequence and connection requirements of each link, and dividing the debugging and testing phases; allocating corresponding manufacturing resources for each integration sub-process, and clarifying the usage requirements of manufacturing resources; evaluating the integration cycle of each integration sub-process, and comprehensively obtaining the total integration cycle of the entire system; and assessing the technical and resource risks that may occur during the integration process.

[0041] Specifically, when developing the process integration outline for debugging and testing, the first step is to thoroughly analyze the product specifications, functional performance requirements, and user-proposed debugging and testing needs of the electronic equipment. Based on this, the specific requirements for process development and the scope of debugging and testing work are clearly defined to ensure that subsequent work is targeted and effective. Secondly, from the perspective of the entire product system, a comprehensive plan for the entire integration process is developed. According to the product's structural hierarchy and functional modules, the entire integration process is divided into several sub-processes, and the hierarchical relationships and material composition between these sub-processes are organized in a tree structure, clearly demonstrating the integration path and material flow of the entire product. Thirdly, for each sub-process, the overall debugging and testing flow is meticulously reviewed, clarifying the sequence and connection requirements of each step. Different debugging and testing phases are defined according to the content and characteristics of the debugging and testing, such as hardware debugging, software testing, and system integration testing, ensuring that the debugging and testing process is logically clear and sequentially logical. Fourthly, based on the debugging and testing content and process requirements of each sub-process, corresponding manufacturing resources are allocated, including personnel allocation, workstation setup, instrument and equipment selection, and tooling and fixture preparation, clearly defining the specifications, quantity requirements, and usage guidelines for each type of resource. Fifth, considering the complexity of the process flow and resource allocation of each integrated sub-process, the integration cycle of each sub-process is assessed. Based on this, the parallel and serial relationships between the sub-processes are comprehensively considered to calculate the total integration cycle of the entire system. Finally, potential technical difficulties, resource bottlenecks, and other risk factors encountered during the integration process are identified and assessed. The probability and impact of various risks are analyzed to provide a basis for subsequent risk response.

[0042] It should be noted that the debugging and testing process integration outline compiled through the above content provides comprehensive and systematic overall guidance for the debugging and testing of the entire electronic equipment, ensuring that the debugging and testing work has clear objectives, a clear scope, and reasonable planning from the outset. As the core document of the top-level solution layer, the integration outline's systematicity and completeness directly affect the quality of the entire debugging and testing process system. By covering multiple aspects such as requirements analysis, solution planning, process streamlining, resource allocation, cycle assessment, and risk assessment, it ensures the comprehensiveness and guidance of the integration outline, providing a reliable top-level basis for the compilation of subsequent process documents at each level.

[0043] More preferably, such as Figure 4 As shown, the method for compiling the process bill of materials includes: based on the process requirements of the debugging and testing process integration outline and combined with the design bill of materials for electronic equipment, constructing a process bill of materials with the process path as the core and the process-level resource requirements as the support; entering process path information into the process bill of materials to clarify the sequence and logical relationship of each process; entering process-level personnel requirement information into the process bill of materials to clarify the job types and quantities of personnel required for each process; entering process-level workstation and instrument requirement information into the process bill of materials to clarify the equipment and tooling required for each process; entering process-level material and time requirement information into the process bill of materials to clarify the material consumption and time quotas for each process; and presenting the content of the process bill of materials through a combination of process path diagrams and various resource requirement tables.

[0044] Specifically, when compiling the process bill of materials (BOM), the debugging and testing process defined in the process integration outline is used as the basis, combined with the design BOM output during the design phase, to construct a process BOM specifically for the debugging and testing process. Unlike traditional BOMs that only contain material information, this process BOM is centered on the process path, using the debugging and testing process flow as the main thread throughout the entire list, while also being supported by various resource requirements at the process level, forming a complete set of debugging and testing process data. In the specific compilation process, firstly, process path information is entered. According to the sequence and logical relationships of the debugging and testing, the entire debugging and testing process is decomposed into several processes, clarifying the sequence, parallel relationships, and logical constraints between each process to form a complete process route. Secondly, for each process, corresponding personnel requirement information is entered, clarifying the types of personnel, skill requirements, and quantity configuration required for that process, ensuring that human resources can meet the process requirements. Thirdly, for each process, corresponding workstation and instrument requirement information is entered, clarifying the workstation locations, instrument models, tooling specifications, etc., required for that process, ensuring that equipment resources can be rationally allocated. Fourth, for each process, the corresponding material and time requirements are entered, clearly defining the types and quantities of materials consumed in that process, as well as the standard working hours required to complete it, providing a basis for material management and production scheduling. Finally, the process bill of materials is presented using a combination of process path diagrams and various resource requirement tables. The process path diagrams visually display the entire process flow and process relationships during the commissioning and testing phase, while the various resource requirement tables detail the specific resource requirements for each process. The two are mutually corresponding and complementary, making the process bill of materials both intuitive and clear, as well as comprehensive in content.

[0045] It's important to note that the process bill of materials (BOM) centered on the process path and supported by process-level resource requirements differs from traditional BOMs that only focus on material information. It provides a more comprehensive reflection of the actual needs of the commissioning and testing process. By assigning resource requirements such as personnel, workstations, instruments, materials, and working hours to the process level, it enables refined management and precise allocation of commissioning and testing resources, avoiding resource waste or shortages. Furthermore, the combination of process path diagrams and resource requirement tables allows managers to grasp the entire commissioning and testing process macroscopically, while also enabling personnel to understand the resource requirements of specific processes microscopically, thus catering to the needs of different usage scenarios.

[0046] More preferably, such as Figure 5As shown, the method for developing the standard operating procedure (SOP) includes: designing standardized operating procedures for each debugging and testing process based on the requirements of the integrated process outline and the bill of materials; setting operational precautions and safety requirements in the SOP; setting the specifications and usage requirements for tooling, instruments, and fixtures in the SOP; breaking down each debugging and testing process into specific operational steps, clarifying the operational content, methods, and sequence, and marking key operational points; clarifying relevant operational parameters for each operational step and quantifying operational standards; clarifying the recording content, recording method, and recording time requirements for each operational step; and establishing an update mechanism for the SOP, synchronously optimizing operational steps according to the version update of the bill of materials to ensure consistency with the bill of materials.

[0047] Specifically, when developing standard operating procedures (SOPs), we strictly adhere to the overall requirements of the integrated debugging and testing process outline and the process material list's workflow. For each debugging and testing step, we develop corresponding standardized operating procedures to ensure that each step has clear and unified operational specifications. The specific content includes the following aspects: First, each SOP begins with operational precautions and safety requirements, clearly outlining the special attention needed during the operation and the mandatory safety operating procedures, reminding operators to fully understand the relevant requirements before starting work to ensure operational safety. Second, it clearly defines the specifications and usage requirements of the tooling, instruments, and fixtures required for the step, including the operating methods, calibration requirements, and precautions for the instruments and equipment, as well as the usage methods and maintenance requirements for the tooling and fixtures, ensuring that operators can correctly use the relevant equipment and tooling. Third, the entire debugging and testing process is broken down into several specific operational steps, arranged sequentially. Each step clearly explains the specific operational content, methods, and sequence, with key operational points highlighted to remind operators to pay special attention. Fourth, for each operational step, clearly define the relevant operational parameters and quantify the operational standards to avoid vague descriptions and ensure that different operators can achieve consistent operational standards and results when performing the same operation. Fifth, clearly define the recording requirements for each operational step, including the content to be recorded, the recording method used, and the recording time node. Operators are required to fill in the operation record in real time and accurately during the operation to ensure the traceability of the debugging and testing process. In addition, establish a dynamic update mechanism for standard operating procedures. When the process bill of materials is updated or the process is adjusted, the corresponding standard operating procedures are revised and optimized simultaneously to ensure that the standard operating procedures always remain consistent with the process bill of materials and avoid inconsistencies between process requirements and operating instructions.

[0048] It should be noted that the standard operating procedures (SOPs) developed using the above content provide detailed, specific, and directly executable standardized guidance for on-site commissioning and testing operations, effectively reducing human error and improving the consistency and stability of commissioning and testing operations. Quantifying the operating standards avoids operational differences caused by varying understanding among operators, ensuring that commissioning and testing operations by different personnel and in different batches achieve uniform quality standards. Simultaneously, the synchronized updating mechanism between the SOPs and the process material list ensures that they remain consistent, preventing a disconnect between process requirements and operating instructions, and guaranteeing the coordination and uniformity of the entire process system.

[0049] More preferably, the method for compiling the auxiliary process documents includes: compiling a system management specification document to clarify the compilation, review, release, and archiving processes for process documents at each level; compiling a hierarchical classification standard document to unify the classification rules and naming conventions for debugging and testing process documents at each level; compiling compilation templates for debugging and testing process documents at each level to standardize the format structure and content requirements of process documents; compiling process document review specifications to clarify the review points, approval authority, and signing and approval process for debugging and testing process documents at each level; compiling process document archiving specifications to specify the storage method, version management rules, and access permissions of the documents; and compiling process document update specifications to clarify the triggering conditions, change process, and synchronization requirements for document changes.

[0050] Specifically, auxiliary process documents, as the core content of the support layer, mainly consist of various systems, standards, and templates that guide and regulate the management of process documents, providing support for the standardized and regulated operation of the entire commissioning and testing process document system. The compilation of auxiliary process documents mainly includes the following aspects: First, compiling system management standard documents, which clearly define the management principles, organizational structure, division of responsibilities, and the entire lifecycle management process of process documents at each level, including compilation, review, release, archiving, and updating, ensuring that process document management is systematic and orderly. Second, compiling hierarchical classification standard documents, which uniformly stipulate the classification rules, naming conventions, and numbering rules for commissioning and testing process documents at each level, ensuring that all process documents can be classified and identified according to unified standards, facilitating document retrieval, identification, and management. Third, compiling compilation templates for commissioning and testing process documents at each level, designing standardized templates for different levels and types of process documents, and uniformly standardizing the document format structure, chapter settings, and content requirements, ensuring consistency in the format and content of similar process documents, and improving the standardization and efficiency of document compilation. Fourth, develop process document review standards, clarifying the key points for reviewing process documents at each level, the approval authority of reviewers at each level, and a complete signing and approval process to ensure that process documents undergo rigorous review before release, guaranteeing document quality. Fifth, develop process document archiving standards, specifying the storage methods, media requirements, version management rules, access permissions, and confidentiality requirements for process documents, ensuring secure storage and standardized management of process documents. Sixth, develop process document update standards, clarifying the triggering conditions for process document changes, the change application approval process, change implementation requirements, and the synchronous update requirements for related documents, ensuring that changes to process documents are controlled and orderly.

[0051] It should be noted that by compiling the aforementioned auxiliary process documents, a complete institutional guarantee and standard support can be provided for the establishment and operation of the entire commissioning and testing process document system. This ensures that there are unified standards to follow in all aspects of process document compilation, review, publication, archiving, and updating at each level. The existence of auxiliary process documents can effectively avoid problems such as inconsistent process document formats, inconsistent standards, and chaotic management caused by different compilers and management habits, thereby improving the standardization and normalization of the entire process document system. At the same time, unified templates and standards can also reduce the difficulty of process document compilation and improve compilation efficiency.

[0052] More preferably, such as Figure 6As shown, establishing the mapping relationship between debugging and testing process documents at each level includes: establishing a vertical guidance mapping relationship from the top-level scheme layer to the middle-level core layer, so that the requirements of the debugging and testing process integration outline can be transmitted and guide the compilation of the process bill of materials; establishing a vertical constraint mapping relationship from the middle-level core layer to the bottom-level operation layer, so that the process and resource requirements of the process bill of materials can constrain the operation flow and resource use of the standard operating procedure; establishing a standard mapping relationship from the auxiliary support layer to other levels, so that the auxiliary process documents can provide a unified standard basis and template support for the writing of debugging and testing process documents at each level; and establishing a bidirectional traceability mapping relationship between debugging and testing process documents at each level, so as to realize forward traceability from the top-level scheme to the bottom-level operation and reverse traceability from the bottom-level operation to the top-level scheme.

[0053] Specifically, when establishing the mapping relationship between debugging and testing process documents at various levels, a complete mapping system is constructed mainly from four dimensions: vertical guidance, vertical constraints, standard support, and two-way traceability. First, a vertical guidance mapping relationship is established from the top-level scheme layer to the middle-level core layer. A clear correspondence is established between the debugging and testing process integration outline and the process bill of materials (BOM), ensuring that the overall requirements, process planning, and resource allocation principles specified in the integration outline are transmitted layer by layer and specifically guide the compilation of the process BOM, ensuring that the content of the process BOM conforms to the overall requirements of the top-level scheme. Second, a vertical constraint mapping relationship is established from the middle-level core layer to the bottom-level operation layer. A process-level correspondence is established between the process BOM and standard operating procedures (SOPs), ensuring that the process division, resource allocation, and time requirements specified in the process BOM constrain and guide the compilation of SOPs, ensuring that the operation flow and resource usage of SOPs are consistent with the process BOM. Third, establish a standardized mapping relationship from the auxiliary support layer to other levels. This involves establishing a standardized correspondence between auxiliary process documents and process documents at the top, middle, and bottom levels. This ensures that the compilation specifications, templates, and standards stipulated in the auxiliary process documents can be uniformly applied to the compilation process of process documents at all levels, guaranteeing that all process documents conform to the same set of standards. Fourth, establish a two-way traceability mapping relationship between debugging and testing process documents at each level. By setting interrelated identifiers and indexes in each level of documents, it is possible to trace back from the top-level scheme layer down to the corresponding middle-level core layer documents and the bottom-level operation layer documents (forward traceability); and also to trace back from the bottom-level operation layer documents up to the corresponding middle-level core layer documents and the top-level scheme layer documents (reverse traceability).

[0054] It should be noted that by establishing the aforementioned multi-dimensional mapping relationships, previously independent process documents at various levels can be organically connected to form a complete and traceable process document network. The vertical guidance and constraint mapping relationships ensure consistency and continuity between documents at different levels, avoiding inconsistencies and contradictions. Standardized mapping relationships ensure that all documents adhere to unified compilation standards, guaranteeing the standardization level of the entire system. The two-way traceability mapping relationships provide fundamental support for the full lifecycle management of process documents and quality traceability during debugging and testing, making problem identification and process optimization more efficient.

[0055] More preferably, establishing the mapping relationship between debugging and testing process documents at each level further includes: establishing a dynamic maintenance mechanism for the mapping relationship; when any debugging and testing process document undergoes a version update or content modification, the compatibility of related documents is checked simultaneously and corresponding updates are triggered; when the process bill of materials undergoes process adjustments, the operation steps of the corresponding standard operating procedure and the mapping relationship between the two are updated simultaneously; when the debugging and testing process integration outline undergoes process changes, the process path of the process bill of materials and the mapping relationship between the two are adjusted simultaneously; when the auxiliary process documents undergo specification updates, the format and content requirements of related documents at each level are checked and revised simultaneously; after each mapping relationship update, the consistency and relevance of debugging and testing process documents at each level are re-verified.

[0056] Specifically, to ensure the accuracy and timeliness of mapping relationships, a dynamic maintenance mechanism for mapping relationships is established to continuously track and update them. This maintenance mechanism includes the following aspects: First, a change triggering mechanism is established. When any debugging process document at any level undergoes a version update or content modification, the system automatically triggers a mapping relationship check process. Based on a preset mapping relationship network, it automatically identifies all other documents associated with the changed document and checks whether these associated documents are still compatible with the changed document. For incompatible documents, corresponding update requests are triggered to ensure that associated documents can be adjusted synchronously. Second, regarding the mapping between the process bill of materials (BOM) and standard operating procedures (SOPs), when the BOM undergoes changes such as the addition, deletion, sequence adjustment, or content change of operations, the corresponding SOP operation steps are automatically updated synchronously, and the mapping relationship between the two is also updated to ensure that operations and operation steps always correspond one-to-one. Third, regarding the mapping between the debugging process integration outline and the process BOM, when the integration outline undergoes process changes, scope adjustments, or changes in resource allocation principles, the process paths and resource allocation schemes in the BOM are automatically adjusted synchronously, and the mapping relationship between the two is updated to ensure that top-level requirements and mid-level implementations remain consistent. Fourth, regarding the mapping between auxiliary process documents and documents at each level, when the specifications, standards, or templates in the auxiliary process documents are updated, the system automatically checks the relevant process documents at each level. For formats and content that do not meet the new specifications, revisions and adjustments are made simultaneously to ensure that all documents comply with the latest specifications. Fifth, after each mapping update, a consistency verification is performed to re-examine the correspondence and relationships between documents at each level, ensuring that the updated mapping is accurate and avoiding mapping errors or omissions.

[0057] It should be noted that the establishment of a dynamic mapping relationship maintenance mechanism can effectively solve the synchronization problem during the process of process document changes, avoiding issues such as untimely updates of related documents and inconsistent requirements caused by changes to a single document. Through automated change triggering and synchronization mechanisms, the efficiency and accuracy of document changes can be greatly improved, reducing the workload of manual checks and synchronization, while also mitigating the risk of document inconsistencies due to human error. The verification process after each update further ensures the accuracy and reliability of the mapping relationship, guaranteeing that the entire process document system remains in a coordinated and consistent state.

[0058] More preferably, the hierarchical association management of the debugging and testing process documents includes: constructing a complete traceability link from the top-level scheme to the bottom-level operation based on the hierarchical mapping relationship; being able to trace all corresponding process material lists and standard operating procedures through the debugging and testing process integration outline; being able to trace the corresponding design source basis and specific operating procedures through the process material list; being able to trace the corresponding process requirements and resource allocation through the standard operating procedures; being able to trace the corresponding process document requirements and design source through the on-site operation records; and using the full-process traceability link to locate the source of problems in the debugging and testing process, providing data support for process optimization and quality improvement.

[0059] Specifically, based on the mapping relationships established between different levels, a complete traceability chain covering the top-level solution to the bottom-level operation is constructed, realizing hierarchical association management and full-process traceability of debugging and testing process documents. The specific traceability functions include the following aspects: First, forward traceability from the top level down, starting with the debugging and testing process integration outline, and tracing back to the complete process bill of materials corresponding to the outline through mapping relationships. Further, tracing back to the corresponding standard operating procedures through the process bill of materials forms a complete traceability chain from the top-level solution to the bottom-level operation, facilitating a comprehensive understanding of all process documents for a product or integration process from a macro perspective. Second, bidirectional traceability from the middle level to both ends, with the process bill of materials as the core. On the one hand, it can trace upwards to its corresponding debugging and testing process integration outline to understand the design source and overall requirements of the process solution; on the other hand, it can trace downwards to its corresponding standard operating procedures to understand the specific operational requirements, facilitating rapid location of relevant upstream and downstream documents from the middle level. Third, reverse tracing from the bottom up: Starting with standard operating procedures or on-site operation records, the system can trace upwards through mapping relationships to the corresponding process material lists, understanding the specific requirements and resource allocation of the process, and further tracing back to the corresponding commissioning and testing process integration outline to understand the overall design requirements and source basis. This facilitates tracing the root cause of problems from the operational level. Fourth, problem localization and process optimization are carried out based on the entire process traceability chain. When quality problems or abnormalities occur during commissioning and testing, the complete traceability chain is used to trace upwards layer by layer from on-site operation records and test data, identifying the corresponding operating procedures, process requirements, and design sources. This quickly locates the link and cause of the problem, providing accurate data support and decision-making basis for process optimization and quality improvement.

[0060] It's important to note that by constructing a complete end-to-end traceability chain, hierarchical and interconnected management of debugging and testing process documents can be achieved, transforming the entire process document system from a scattered collection of documents into an organically linked information network. The realization of end-to-end traceability not only improves the efficiency of querying and using process documents, but more importantly, it provides strong support for quality control and problem identification during the debugging and testing process. When problems occur, the causes can be quickly and accurately located, significantly shortening the time for problem identification and resolution. Simultaneously, the data accumulated during the traceability process can provide a basis for continuous process optimization, promoting the continuous improvement of the debugging and testing process level.

[0061] Accordingly, this embodiment also provides an electronic equipment debugging and testing process architecture, including a top-level solution layer, a middle-level core layer, a bottom-level operation layer, and an auxiliary support layer. The top-level solution layer has a debugging and testing process integration outline, which specifies the overall goals, scope, and integration process planning of debugging and testing. The middle-level core layer has a process material list, which carries the process path and resource allocation requirements of the debugging and testing procedures. The bottom-level operation layer has standard operating procedures, which guide the specific operation execution at the debugging and testing site. The auxiliary support layer has auxiliary process documents, which provide a unified standard basis for the compilation of process documents at each level. There are vertical mapping relationships between the top-level solution layer and the middle-level core layer, and between the middle-level core layer and the bottom-level operation layer. There are standard mapping relationships between the auxiliary support layer and the other layers, realizing hierarchical association management and traceability of debugging and testing process documents.

[0062] It should be noted that this four-layer architecture design forms a complete process documentation system from macro to micro, from general to specific. Each layer has clear responsibilities and a well-defined role, operating independently yet interconnected, forming an organic whole. The vertical mapping relationship ensures consistency and coherence between levels, avoiding disconnects; the standardized mapping relationship ensures the standardization and normalization of the entire system. The application of this architecture effectively solves the problems of traditional debugging and testing process documentation systems, such as disorganization, unclear hierarchy, poor correlation, and difficulty in traceability, thereby improving the systematization, structuring, and refinement of debugging and testing process management.

[0063] Example 2 This embodiment provides a method for constructing a process architecture for debugging and testing electronic equipment. Taking the production process of an electronic equipment manufacturing workshop as an example, the method can be implemented using the following steps: Step S1: Establish a multi-level debugging and testing process architecture.

[0064] 1. Top-level architecture layer: Compile the "XXX Debugging and Testing Process Integration Outline", clarify the overall debugging and testing objectives (ensuring that the equipment functions and performance meet the standards) and scope (pilot production, batch production), formulate document preparation, review and archiving processes, and adopt the numbering rule of "document type code-version number" (XY-DZ-001-V1.0); and compile supporting system management specifications and hierarchical division standards.

[0065] 2. Mid-level core layer: The core document is the PBOM (Process Material List), which clarifies the PBOM compilation standards, process path design requirements, and the connection requirements with the top-level integration outline and the bottom-level SOP.

[0066] 3. Bottom-level operation layer: The core document is the SOP (Standard Operating Procedure), which clarifies that the SOP must conform to the process and resource requirements of the PBOM and standardize the on-site operation process.

[0067] 4. Supporting Layer: Compile various auxiliary process documents, including process document writing management system, special writing specifications, and standard templates (integrated outline template, PBOM template, SOP template, etc.).

[0068] Step S2: Test and integrate the design outline.

[0069] The "XX Equipment Integration Outline" was compiled, specifying: 1. Process Development Requirements: This includes user requirement analysis for this product model, including the achievement of key technical indicators, integration and delivery, user usage requirements, as well as the quality, delivery time, and lean manufacturing requirements of key stakeholders.

[0070] 2. Overall Scheme Planning: Based on process development requirements, describe the composition and hierarchy of the entire product manufacturing integration process, including all sub-processes at each level, from the perspective of the entire product system. For example... Figure 7 The diagram shows the overall solution for the CPXXX.XXX product, which consists of five integrated sub-processes.

[0071] 3. Process flow planning: Using process stages as the granularity, the integrated process flow is represented by flowcharts, such as... Figure 8 The diagram shows the process flow planning for the system integration sub-process.

[0072] 4. Manufacturing Resource Allocation: The required production stations, personnel, equipment, and tooling for each sub-process are shown in the table below: Table 1 - Workstation Configuration

[0073] Table 2 - Staffing Allocation

[0074] Table 3 - Instrument, Equipment, and Tooling Configuration

[0075] 5. Cycle: The cycle required to evaluate this integrated subprocess is approximately 30 days.

[0076] 6. Overall system integration cycle: Determine the cycle of each integration sub-process, and based on the longest path, the overall system integration cycle is estimated to be 12 days.

[0077] Table 4 - Integration Cycle

[0078] 7. Risk Assessment: There is a risk that the materials for this product may not be available in a timely manner, which may affect the delivery cycle.

[0079] Step S3: PBOM Design.

[0080] Each integrated sub-process is designed. Taking the system integration sub-process as an example, it includes process path, process method, personnel requirements, workstation requirements, and instrument requirements.

[0081] Step S4: Standard Operating Procedure (SOP) Design.

[0082] Based on the PBOM, a Standard Operating Procedure (SOP) is prepared for each process. Taking the preparation process as an example, the main contents of the SOP for this process are as follows: 1. Introduction This document specifies the testing, adjustment, and troubleshooting methods for CPXXX.XXX.

[0083] This document applies to the work instructions for the preparation process of CPXXX.XXX.

[0084] 2. Precautions Before starting the process, check and adjust the product status label to ensure that the product status label is in the "ready" position.

[0085] 3. Instruments, equipment, and tooling Table 5 - Instruments, Equipment and Tooling

[0086] 4. System connection diagram, such as Figure 9 As shown.

[0087] 5. Operating Procedures Step 1: Site Preparation Site planning: Standard workstations; Power distribution: 380V (power > 10KW); The warehouse uses aviation plugs. Connect one end of the power cord distribution box connector to the aviation socket, and the other end of the power cord distribution box connector to the aviation socket. Pay attention to the phase sequence.

[0088] Step 2: Cable Tuning The cable kit list is shown below: Table 6 - Complete Set of Power Supply Vehicle Cables

[0089] Step 3: Complete the set of extension units The complete set of extension numbers is shown in the table below: Table 7 - Complete Set of Extension Units and Cabinets

[0090] 6. Data processing Fill in the completeness of the kit according to the work steps.

[0091] 7. Environmental Restoration In accordance with 6S management requirements, equipment, tooling, tools, desks, chairs, documents, etc., were organized and put in their proper places. Step S5: Design auxiliary process documents.

[0092] 1. Process Document Writing and Management System: Clearly define the processes for preparing, reviewing, and archiving various documents, and clarify the roles and responsibilities of each person; 2. Specific Writing Standards: Establish writing standards for PBOMs and SOPs, and standardize terminology and format; 3. Standard Templates: Use the PBOM process path diagram template and SOP template to complete the preparation of relevant documents; 4. Supporting record templates: Design document review record forms and version update record forms to standardize management processes.

[0093] Step S6: Establish the process document hierarchical mapping relationship.

[0094] 1. Vertical Mapping: The "CPXXX.XXX Integration Outline" guides PBOM (Publication Process Layout Plan) development, which in turn guides SOP (Standard Operating Procedure) development. Supporting process documents provide writing guidelines for all documents. The integration outline plans five integrated sub-processes, each with its own PBOM. Each sub-process's PBOM outlines multiple steps, and each step has a corresponding SOP. Each debugging / testing step corresponds to a unique PBOM step node and SOP operation steps, allowing for quick access to relevant documents. 2. Mapping relationship maintenance: If the functions or performance indicators in the integration outline are adjusted, the PBOM, SOP and mapping relationship will be updated synchronously through impact analysis; 3. Execution process traceability: When problems occur during debugging and testing, the corresponding SOP, PBOM, and integration outline can be traced back according to the hierarchical mapping relationship, and changes can be made accordingly.

[0095] The above description is merely a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the concept described herein through the above teachings or related technologies or knowledge. Modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.

[0096] It should be noted that, for the sake of simplicity, the foregoing method embodiments are described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

Claims

1. A method for constructing a process architecture for debugging and testing electronic equipment, characterized in that, include: A multi-level debugging and testing process architecture is constructed, which includes a top-level solution layer, a middle-level core layer, a bottom-level operation layer, and an auxiliary support layer. Based on the aforementioned debugging and testing process architecture, debugging and testing process documents for each level are compiled. These debugging and testing process documents include a debugging and testing process integration outline, a process material list, standard operating procedures, and auxiliary process documents. Establish mapping relationships between debugging and testing process documents at different levels to complete hierarchical association management of debugging and testing process documents.

2. The method for constructing the electronic equipment debugging and testing process architecture according to claim 1, characterized in that, The multi-level debugging and testing process architecture includes: The top-level solution layer serves as the guiding level of the debugging and testing process architecture, defining the overall goals, scope, and organizational management requirements of the debugging and testing. The middle-level core layer serves as the core connecting level of the debugging and testing process architecture, providing the specific implementation basis for the debugging and testing process. The bottom-level operation layer serves as the execution level of the debugging and testing process architecture, directly guiding the specific operations at the debugging and testing site. The auxiliary support layer serves as the guarantee level of the debugging and testing process architecture, providing a unified and standardized basis for the compilation, review, and management of debugging and testing process documents at each level.

3. The method for constructing the electronic equipment debugging and testing process architecture according to claim 1, characterized in that, The method for compiling the integrated debugging and testing process outline includes: Based on the product specifications and testing requirements of electronic equipment, determine the process development requirements and testing scope; plan the overall integration process from the perspective of the entire product system, and sort out the hierarchical relationship and material composition of each integration sub-process; sort out the overall testing process for each integration sub-process, clarify the sequence and connection requirements of each link, and divide the testing phases; allocate corresponding manufacturing resources for each integration sub-process, and clarify the usage requirements of manufacturing resources; evaluate the integration cycle of each integration sub-process, and obtain the total integration cycle of the entire system; assess the technical and resource risks that may occur during the integration process.

4. The method for constructing the electronic equipment debugging and testing process architecture according to claim 1, characterized in that, The method for compiling the process bill of materials includes: Based on the process requirements of the debugging and testing process integration outline, and combined with the design bill of materials (BOM) for electronic equipment, a process BOM is constructed with the process path as the core and the process-level resource requirements as support. The process BOM includes process path information, clarifying the sequence and logical relationships of each process; process-level personnel requirements, specifying the job types and quantities of personnel needed for each process; process-level workstation and instrument requirements, specifying the equipment and tooling required for each process; and process-level material and time requirements, specifying the material consumption and time quotas for each process. The process BOM content is presented through a combination of process path diagrams and various resource requirement tables.

5. The method for constructing the electronic equipment debugging and testing process architecture according to claim 1, characterized in that, The method for developing the standard operating procedure includes: Based on the requirements of the commissioning and testing process integration outline and process bill of materials, standardized operating procedures are designed for each commissioning and testing process. Operational precautions and safety requirements are set in the standard operating procedures. Specifications and usage requirements for tooling, instruments, and fixtures are also defined in the standard operating procedures. Each commissioning and testing process is broken down into specific operational steps, clarifying the operational content, methods, and sequence, and highlighting key operational points. Relevant operational parameters are specified for each operational step, and operational standards are quantified. The recording content, recording method, and recording time requirements for each operational step are clearly defined. An update mechanism for the standard operating procedures is established, and operational steps are optimized synchronously with the process bill of materials version updates to ensure consistency with the process bill of materials.

6. The method for constructing the electronic equipment debugging and testing process architecture according to claim 1, characterized in that, The method for compiling the auxiliary process documents includes: Develop system management standard documents to clarify the processes for preparing, reviewing, issuing, and archiving process documents at each level; develop hierarchical classification standard documents to unify the classification rules and naming conventions for debugging and testing process documents at each level; develop templates for preparing debugging and testing process documents at each level to standardize the format structure and content requirements of process documents; develop process document review standards to clarify the key points for reviewing debugging and testing process documents at each level, approval authority, and signing and approval process; develop process document archiving standards to specify the storage methods, version management rules, and access permissions for documents; and develop process document update standards to clarify the triggering conditions, change process, and synchronization requirements for document changes.

7. The method for constructing the electronic equipment debugging and testing process architecture according to claim 1, characterized in that, The establishment of the mapping relationship between the debugging and testing process documents at each level includes: Establish a vertical guidance mapping relationship from the top-level scheme layer to the middle core layer, so that the requirements of the debugging and testing process integration outline can be transmitted and guide the compilation of the process bill of materials; establish a vertical constraint mapping relationship from the middle core layer to the bottom operation layer, so that the process and resource requirements of the process bill of materials can constrain the operation flow and resource use of the standard operating procedures; establish a standardization mapping relationship from the auxiliary support layer to other levels, so that auxiliary process documents can provide a unified standard basis and template support for the writing of debugging and testing process documents at all levels; establish a two-way traceability mapping relationship between debugging and testing process documents at all levels, so as to realize forward traceability from the top-level scheme to the bottom operation and reverse traceability from the bottom operation to the top-level scheme.

8. The method for constructing the electronic equipment debugging and testing process architecture according to claim 7, characterized in that, The establishment of the mapping relationship between the debugging and testing process documents at each level also includes: A dynamic maintenance mechanism for mapping relationships is established. When any debugging process document is updated or its content is modified, the compatibility of related documents is checked simultaneously and corresponding updates are triggered. When the process bill of materials is adjusted, the corresponding standard operating procedure's operation steps and the mapping relationship between them are updated simultaneously. When the debugging process integration outline undergoes process changes, the process path of the process bill of materials and the mapping relationship between them are adjusted simultaneously. When the auxiliary process documents are updated, the format and content requirements of related documents at each level are checked and revised simultaneously. After each mapping relationship update, the consistency and relevance of debugging process documents at each level are re-verified.

9. The method for constructing the electronic equipment debugging and testing process architecture according to claim 7, characterized in that, The hierarchical association management of the debugging and testing process documents includes: Based on hierarchical mapping relationships, a complete traceability link is constructed from the top-level solution to the bottom-level operation. Through the debugging and testing process integration outline, the corresponding complete process material list and standard operating procedures can be traced. Through the process material list, the corresponding design source basis and specific operating procedures can be traced. Through the standard operating procedures, the corresponding process requirements and resource allocation can be traced. Through the on-site operation records, the corresponding process document requirements and design source can be traced back. By using the full-process traceability link, the source of problems in the debugging and testing process can be located, providing data support for process optimization and quality improvement.

10. An electronic equipment debugging and testing process architecture, characterized in that, It includes a top-level solution layer, a middle-level core layer, a bottom-level operation layer, and an auxiliary support layer; The top-level solution layer includes a debugging and testing process integration outline, which specifies the overall goals, scope, and integration process planning for debugging and testing. The middle core layer contains a process material list, which is used to carry the process path and resource allocation requirements of the debugging and testing process; The underlying operation layer has standard operating procedures to guide the specific operation execution at the debugging and testing site; The auxiliary support layer is equipped with auxiliary process documents, which provide a unified standard basis for the preparation of process documents at each level. The top-level scheme layer and the middle core layer are respectively connected by vertical mapping relationships, and the middle core layer and the bottom operation layer are respectively connected by standardized mapping relationships between the auxiliary support layer and the other layers, so as to realize the hierarchical association management and traceability of debugging and testing process documents.

Images