Authorization plan processing method and device based on airworthiness authentication platform

Abstract

The invention provides an approval plan processing method and device based on an airworthiness approval platform, and relates to the field of airworthiness of aircrafts. The method comprises the following steps: acquiring to-be-checked software qualification approval plan data; according to a plurality of verification items in a preset verification list, performing correctness verification and normativity verification on the software qualification approval plan data to generate first verification information and second verification information; wherein the first verification information is used for indicating the correctness information, and the second verification information is used for indicating the normalization information. And performing integration processing on the first verification information and the second verification information to generate a verification report. Therefore, the technical problem that in the prior art, the auditing efficiency of the existing auditing whole process is low is solved.

Description

Technical Field

[0001] This application relates to the field of aircraft airworthiness, and more specifically, to a method and apparatus for processing certification plans based on an airworthiness certification platform. Background Technology

[0002] Currently, airworthiness certification of civil aviation airborne systems is a core pillar of the aviation safety system, serving as a "license" for aircraft design, manufacturing, and operation to enter the market. Its essence is to ensure, through scientific and standardized verification methods, that aircraft meet the stringent safety standards set by the International Civil Aviation Organization (ICAO) and national airworthiness authorities throughout their entire lifecycle, from design and manufacturing to operation. In this process, the Software Qualification Assessment Program (PSAC), as the guiding document for airworthiness review, plays a crucial role in comprehensively explaining to the regulatory authorities the conformity methods, lifecycle activities, and data of the airborne software development process. It is the core basis for applicants to demonstrate their software safety assurance capabilities to the certification body.

[0003] However, in existing technologies, the entire process of traditional software qualification assessment mainly relies on human experience to check the correctness and standardization of documents. This traditional method is inefficient and costly. Although some rule-based automated document review systems exist, most of them focus on checking basic document format, such as grammar proofreading and terminology consistency, resulting in low overall efficiency in the current assessment process. Summary of the Invention

[0004] The purpose of this application is to provide a certification plan processing method and apparatus based on an airworthiness certification platform, so as to solve the technical problem of low certification efficiency in the existing certification process.

[0005] Firstly, a method for processing certification plans based on an airworthiness certification platform is provided, which may include: Obtain the software conformity assessment plan data to be inspected; Based on multiple verification items in the preset verification form, the software qualification review plan data is verified for correctness and compliance, generating first verification information and second verification information; wherein, the first verification information is used to indicate correctness information, and the second verification information is used to indicate compliance information; The first verification information and the second verification information are integrated and processed to generate a verification report.

[0006] Secondly, an airworthiness certification plan processing device based on an airworthiness certification platform is provided, the device may include: The acquisition module is used to acquire the software conformity assessment plan data to be inspected; The inspection module is used to perform correctness verification and standardization verification on the software qualification review plan data according to multiple verification items in the preset verification form, and generate first verification information and second verification information; wherein, the first verification information is used to indicate correctness information, and the second verification information is used to indicate standardization information; The generation module is used to integrate and process the first verification information and the second verification information to generate a verification report.

[0007] Thirdly, an electronic device is provided, which includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements any of the steps described in the first aspect above.

[0008] Fourthly, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when executed by a processor, the computer program implements the steps of any of the methods described in the first aspect above.

[0009] This application provides a certification plan processing method and apparatus based on an airworthiness certification platform. Based on each verification item in a preset verification form, it performs correctness and standardization verification on software qualification certification plan data and generates a verification report. This not only solves the problems of low efficiency and strong subjectivity of traditional manual inspection and reduces human error, but also overcomes the limitations of existing rule-based document review systems in semantic understanding. It achieves high-precision automatic inspection of document correctness (such as chapter content compliance) and standardization (such as terminology consistency), significantly improving the intelligence level and reliability of the airworthiness certification process. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A flowchart illustrating a certification plan processing method based on an airworthiness certification platform, provided for an embodiment of this application; Figure 2 A flowchart illustrating a certification plan processing method based on an airworthiness certification platform, provided for an embodiment of this application; Figure 3A flowchart illustrating a certification plan processing method based on an airworthiness certification platform, provided for an embodiment of this application; Figure 4 A schematic diagram of an inspection report template based on an airworthiness certification platform provided for an embodiment of this application; Figure 5 A flowchart illustrating a certification plan processing method based on an airworthiness certification platform, provided for an embodiment of this application; Figure 6 A flowchart illustrating a certification plan processing method based on an airworthiness certification platform, provided for an embodiment of this application; Figure 7 A flowchart illustrating a certification plan processing method based on an airworthiness certification platform, provided for an embodiment of this application; Figure 8 A flowchart illustrating a certification plan processing method based on an airworthiness certification platform, provided for an embodiment of this application; Figure 9 A flowchart illustrating an airworthiness certification plan processing device based on an airworthiness certification platform, provided for an embodiment of this application; Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise defined, the technical or scientific terms used in this application should have the ordinary meaning understood by those skilled in the art. The words "first," "second," and similar terms used in this application do not indicate any order, quantity, or importance, but are only used to distinguish different components. The words "comprising" or "including," etc., mean that the element or object preceding the word covers the element or object listed after the word and its equivalents, but do not exclude other elements or objects. The words "connected," "coupled," or "connected," etc., are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. "Up," "down," "left," "right," etc., are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0013] The certification plan processing method based on an airworthiness certification platform provided in this application can be applied to electronic devices equipped with an airworthiness certification platform; or servers; or devices equipped with a certification plan processing device based on an airworthiness certification platform, without limitation. Since this application achieves automatic checking of the software conformity certification plan based on verification items in the verification form, the implementation of each verification item and the final integration of multiple verification item contents need to be clearly reflected in the airworthiness certification platform. Therefore, the construction of this airworthiness certification platform can adopt the framework of the Dify platform, and be fine-tuned on this framework to adapt to the automatic checking of the software conformity certification plan. The Dify platform has a built-in visual orchestration canvas, which, through the linking of various modules, ultimately forms a visual and modular workflow environment, supporting an end-to-end processing flow from document upload to report generation, improving the flexibility and maintainability of automatic checking of the software conformity certification plan.

[0014] To ensure the accuracy of the inspection, the server is an application server or cloud server with strong computing power. The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0015] Figure 1 This is a flowchart illustrating a certification plan processing method based on an airworthiness certification platform, provided as an embodiment of this application. Figure 1 As shown, the method may include: Step S101: Obtain the software qualification plan data to be inspected.

[0016] For example, in response to a user's upload operation, the software qualification plan data to be inspected is obtained. The software qualification plan data is the software qualification plan document to be evaluated, and it includes multiple chapters and the content under each chapter (a chapter may be referred to as a section, and the content of a section may be simply referred to as content).

[0017] Step S102: Based on multiple verification items in the preset verification form, perform correctness verification and standardization verification on the software qualification review plan data, and generate first verification information and second verification information; wherein, the first verification information is used to indicate correctness information, and the second verification information is used to indicate standardization information.

[0018] For example, the verification form includes multiple preset verification items. Based on the preset verification form, the software qualification plan data is verified for correctness, generating first verification information; the software qualification plan data is also verified for compliance, generating second verification information. The first verification information indicates the correctness of chapters and content; the second verification information indicates the compliance information corresponding to each chapter.

[0019] Optionally, document correctness verification includes chapter correctness checks and content compliance checks for the software qualification audit plan data. Chapter correctness checks include chapter completeness checks. Standardization verification includes checking the consistency of the table of contents structure and the completeness of headers and footers. Secondly, regular expressions are used to extract text from chapter titles and their complete content within the software qualification audit plan data. This extracted text is used as known information in the large model, and prompts are created for each verification item based on the verification form's content. The large language model's semantic understanding capabilities then perform semantic analysis to derive corresponding inspection conclusions.

[0020] Step S103: Integrate and process the first verification information and the second verification information to generate a verification report.

[0021] For example, the first verification information and the second verification information are integrated and processed to generate a complete verification report.

[0022] In this embodiment, software qualification plan data to be inspected is acquired. Based on multiple verification items in a pre-set verification form, the software qualification plan data is verified for correctness and compliance, generating first verification information and second verification information. The first verification information indicates correctness, and the second verification information indicates compliance. The first and second verification information are integrated to generate a verification report. This solution, based on the various verification items in the pre-set verification form, performs correctness and compliance verification on the software qualification plan data. This not only solves the problems of low efficiency and strong subjectivity in traditional manual inspection, reducing human error, but also overcomes the limitations of existing rule-based document review systems in semantic understanding. It achieves high-precision automatic inspection of document correctness (e.g., chapter content compliance) and compliance (e.g., terminology consistency), significantly improving the intelligence level and reliability of the airworthiness certification process.

[0023] Figure 2 This is a flowchart illustrating a certification plan processing method based on an airworthiness certification platform, provided as an embodiment of this application. Figure 2 As shown, the method may include: Step S201: Obtain the software qualification plan data to be inspected.

[0024] For example, this step is described in step S101, and will not be repeated here.

[0025] Step S202: Based on multiple verification items in the preset verification form, verify the correctness of the chapters and contents under the chapters in the software qualification review plan data, and generate the first verification information; wherein, the first verification information is used to indicate the correctness information of the chapters, the conformity information of the contents, and the correctness information of the contents; the conformity information indicates whether the contents conform to the chapters.

[0026] For example, Figure 3 A flowchart illustrating a certification plan processing method based on an airworthiness certification platform, as provided in this application embodiment, is shown below. Figure 3 As shown, the software qualification review plan data is first processed through the platform (i.e. Figure 3 The software qualification assessment plan is uploaded, and the uploaded document is preprocessed using the platform's document extraction module. The document content is converted into a more clearly structured Markdown format, facilitating subsequent extraction of chapter content and document headers and footers. Next, a pre-set verification form is used to perform a comprehensive check of the document content, including document correctness (i.e., completeness) verification, generating the first verification information. The document correctness verification includes chapter correctness checks and content compliance checks for the software qualification assessment plan data. The first verification information indicates the correctness of the chapters, the compliance of the content, and whether the content conforms to the chapters.

[0027] Optionally, since the software qualification plan data requires content and document format checks, uploaded DOCX or PDF documents need to be converted into plain text in Markdown format with clearer chapter titles and content to support subsequent automatic checks. However, the document extractor node built into the Dify platform cannot convert uploaded documents into plain text in Markdown format. Therefore, at the implementation level, this application chooses MarkitDown as the core backend service for document content conversion to fine-tune the document content extraction module. It supports converting DOCX, PDF, and other document formats into plain text in Markdown format. The deployed MarkitDown tool is encapsulated into a custom tool supported by Dify via API. An OpenAPI Schema format file is written according to the MarkitDown API documentation to describe the API endpoints, parameters, and responses. Then, the written Schema file is imported into the Dify backend. Appropriate configuration is performed according to the API authentication requirements (e.g., API KEY). Finally, testing is conducted to confirm that the document content extraction module can run normally, thus allowing it to be applied in the workflow as an important document content conversion module.

[0028] Optionally, the verification form is primarily created based on the specific requirements of the software conformity assessment plan in DO-178C (Software Considerations in the Certification of Airborne Systems and Equipment), a crucial standard required during the airborne software certification process. It also incorporates expert opinions and refines the specifications and inspection methods for the verification items. For example, regarding the verification item of whether the original document includes a system overview section, in addition to checking whether the system overview section exists, it is necessary to focus on whether the content under the system overview section includes a description of system functions, and whether it provides details such as the system architecture, the processor used, the allocation of functions to hardware and software, and security features.

[0029] DO-178C is an internationally recognized core standard for airworthiness certification of airborne software. DO-178C ensures that software functionality aligns with airworthiness and safety requirements by rigorously defining the software lifecycle process (requirements, design, coding, verification, etc.) and Design Assurance Levels (DAL AE). Regarding the airworthiness certification plan, DO-178C explicitly requires the development of a Software Qualification Assessment Plan (PSAC) as a core compliance document. This plan must clearly articulate the software's target level, development / verification methods, tool qualification strategies, and process control measures. It must cover key activities such as requirements traceability, layered verification, and fault tolerance, and integrate sub-plans such as configuration management and quality assurance. Ultimately, this forms a reviewable chain of evidence demonstrating that the software meets airworthiness objectives throughout its entire lifecycle, providing systematic safety guidelines for airworthiness authorities (such as the FAA and EASA).

[0030] The verification form mainly includes two aspects: accuracy verification and compliance verification. Accuracy verification primarily involves checking the correctness and content conformity of each chapter in the software qualification plan data. Compliance verification mainly includes checking the document format, such as filenames / file numbers, copyright information, document version records, and consistency checks for the table of contents / table of figures.

[0031] Furthermore, the content of each verification item on the verification form was broken down, disassembling a single verification item into multiple parts for inspection and obtaining corresponding results. The breakdown logic is based on the specific inspection content of each verification item, decomposing it into several sub-items. This facilitates a clearer presentation of the generated inspection report. For example, the verification item "Does the homepage contain file name, file number, version, file release date, and copyright statement?" is broken down into five parts: file name determination, file number determination, version determination, file release date determination, and copyright statement determination. However, the verification item "Does it correctly list historical version change document information?", which only involves checking one item, does not require splitting. An example of the specific content of the verification form is as follows: Does the homepage include the file name, file number, version, release date, and copyright notice? Does the document version history correctly list historical versions and their authors? Does it correctly list historical version change order information? Does the document have a table of contents? Is the table of contents consistent with the table of contents structure in the main text? Step S203: Based on multiple verification items in the preset verification form, perform semantic analysis on the chapters and contents under the chapters of the software qualification review plan data to generate second verification information.

[0032] In one example, step S203 includes: extracting text from the software qualification approval plan data based on multiple verification items in a preset verification form to generate extracted text; generating prompt words corresponding to each verification item; and performing semantic analysis on the extracted text based on the prompt words corresponding to each verification item to generate second verification information.

[0033] In one example, step S203 includes: performing semantic analysis and extraction processing on the software qualification review plan data based on multiple verification items in a preset verification form and a preset document content matching function to generate a list to be verified; based on the list to be verified, traversing the software qualification review plan data to generate second verification information; wherein, the normative information indicated by the second verification information includes whether the software qualification review plan data is consistent with the list to be verified.

[0034] For example, such as Figure 3 As shown, document compliance checks include the completeness of headers and footers, filenames / file numbers, copyright information, file version history, consistency of the main text / tables / figures, consistency of cited documents, consistency of terminology and abbreviations, standardization of commonly used units, and compliance with reference standards. Regular expressions are used to extract text from document chapter titles and their complete content. This extracted text is used as known information in a large language model. Each verification item is then used to generate prompts based on the verification items in the verification form. The large language model's semantic understanding capability performs semantic analysis on the chapter content to derive corresponding inspection conclusions. The prompts employ a multi-level design, including role definitions, background descriptions, responsibility limitations, skill requirements, goal settings, and output format constraints. This ensures that the inspection conclusions correspond to the verification item content and are output in a strict JSON format. Finally, the document generation module of the airworthiness certification platform integrates the conclusions from the large language model to generate the final verification report. The following section will provide a detailed explanation of the platform development and automated inspection process.

[0035] Optionally, the large language model module is the core module for implementing automatic airworthiness certification plan checks in this application, responsible for intelligent semantic analysis and content checks of airworthiness certification plan documents. As a key module of the airworthiness certification plan processing method based on the airworthiness certification platform, it uses advanced natural language processing technology to deeply understand and evaluate the standardization of the chapter content of the Software Qualification Assessment Plan (PSAC). Through integration with the large language model module, the deployment of the large language model is as follows: (1) Model selection and deployment method The large language model module employs a hybrid model architecture, combining the advantages of the Deepseek-R1 32B model and the Qwen-2.5 3B model. The Deepseek model possesses deep thinking capabilities, making it suitable for complex semantic understanding tasks (such as the correctness analysis of system functional descriptions, including integrity analysis); the Qwen-2.5 3B model, as a lightweight model, focuses on simple semantic judgments (such as basic terminology checking). Both models are implemented through local deployment, managed using the LMstudio tool, and executed through local API calls (such as LMstudio's custom API). This local deployment ensures zero risk of data leakage from uploaded documents, meeting the high data security requirements of the aviation airworthiness field. Simultaneously, the use of the hybrid model optimizes processing efficiency: for complex verification items, the Deep model provides deep inference; for simple verification items, the Qwen-2.5 3B model responds quickly. Testing shows that the hybrid model architecture reduces document checking time by more than 20% compared to a single model and improves accuracy to over 95%, effectively avoiding misjudgments caused by model "illusions."

[0036] (2) Workflow and prompt design The large language model module, as the core node of a single verification item workflow, operates strictly based on a pre-defined verification form. For each verification item, the large language model module achieves accurate semantic analysis through a customized prompt word mechanism: The prompt word structure employs a multi-level design, including role definition, background description, responsibility limitations, skill requirements, goal setting, and output format constraints, thereby enabling checks on different verification items. The following example, using the verification item "Does the system description section contain system function descriptions?", illustrates how the prompt words specify how the model analyzes the section content, determines whether the content contains the elements involved in the verification item, and outputs the answer in a fixed format. The specific prompt word style is shown below.

[0037] - Role definition: Semantic understanding expert and document reviewer.

[0038] - Background Description: Users need to review the system description section to confirm whether it covers the overall system overview, including an overview of system functions. Users only need to determine if the document content contains the above elements; they do not need to provide improvement suggestions.

[0039] - Job Responsibilities: You are a professional semantic understanding expert and document reviewer with keen text analysis skills, capable of accurately identifying whether a document contains specific content, and familiar with the key elements of the system description and how they are expressed in the document.

[0040] -Skills required: You can quickly and accurately determine whether a document covers the description of system functions, ensuring the correctness and accuracy of the document content.

[0041] - Target setting: Determine only whether the system description section provides a comprehensive overview of the system, including descriptions of system functions, and output the verification results in JSON format.

[0042] - Output format constraints: Only determine whether the document content contains the above elements; do not provide improvement suggestions or analysis beyond the scope. The analysis should be based on the document content and be objective and accurate. Verification results must be output in JSON format, and the format must meet the requirements. The output should clearly indicate whether the system description section contains a system function description. The plain text JSON output is as follows: [{“Does the System Description section include an overview of system functions?]”: “Yes / No”},{“Does the System Description section include detailed descriptions of system functions?]”: “The content here is for your judgment”}.

[0043] Input and Output Processing: The large language model module receives Markdown-formatted text (such as the content of the system description section) from the chapter content extraction function module, and uses prompt words as input parameters. The model output is strictly limited to a standardized JSON format (e.g., [{"Does the system description section contain a system function overview?]]:"Yes / No"}]). Subsequently, the output is cleaned up using a format specification function, removing extra spaces or illegal characters to ensure the JSON text is compatible with the downstream automatic report generation module. This design significantly improves the consistency and reliability of the output, avoiding system errors caused by the unstable output format of traditional large language models.

[0044] Optionally, this application also includes custom function modules, which contain various custom functions. Specifically, the custom function modules programmatically extract, match, and logically judge specific content from documents. Since the verification form involves chapter content extraction and document format checking, the addition of custom function modules can compensate for the limitations of pure rule checking and large language model checking, allowing the platform to handle changes or additions to verification items more flexibly. All functions in the custom function modules are developed using Python. The implementation of the custom function modules involves fine-tuning the code nodes of the Dify platform. Because Dify's built-in code nodes rely on a sandbox environment, they cannot easily support the text processing library calls required by Python functions. Therefore, this application chooses to build a custom sandbox image to implement the Python function text library calls. A Dockerfile is created in the Dify installation directory, and a new image is built using the Docker Build command in Docker. Finally, Docker Compose is modified to point the sandbox service portion to the newly built image, thereby enabling the text processing library calls of the custom function modules. The custom functions built in this application mainly include the following three categories: ①Chapter content extraction class function The chapter content extraction function is responsible for extracting complete chapter titles and all content under each chapter from the Markdown formatted plain text content in the document content extraction module. It can also determine the presence or absence of chapter content. The function obtains chapter content by constructing regular expressions; the specific matching rules are as follows: Markdown-formatted text headings begin with the # character, followed by a space and the heading text. The number of # characters indicates the heading level; more # characters result in a lower heading level. This function's extraction rules are based on the specific heading content to be extracted from the input, such as the "Software Overview" section in a software qualification plan. The function iterates through the entire document's text content, finding text with the # symbol for "Software Overview" (the number of # characters is unlimited). When the "Software Overview" section content is successfully found, it is retrieved and used as the starting index. After finding the target heading, the function continues searching for the next heading of the same or higher level, outputting all text content between the headings. If no matching or higher-level heading is found, all content up to the end of the text is output, thus obtaining all content under the "Software Overview" section. If the "Software Overview" section is not found, the function will output that the "Software Qualification Plan does not contain a Software Overview" section, thereby achieving the determination of the presence or absence of a document's heading and the complete extraction of its content.

[0045] ②Document content matching functions The document content matching functions are primarily responsible for verifying whether the table of contents matches the headings in the main text, whether the figures and tables in the document have corresponding titles in the main text, whether the terms and abbreviations appear in the main text, and whether the documents mentioned in the cited sections are correctly cited in the document. Since these verification items require traversing the entire document for comparison, they are not suitable for implementation using a separate large language model node. Traversing the entire document would consume excessive tokens, increasing the runtime burden on the large language model and increasing the risk of false positives. Therefore, these verification items are more suitable to be implemented using function nodes. The matching rules for the document content matching functions are as follows: First, regular expressions are used to locate the sections in the Markdown text converted by the document content extraction module that require content matching, such as the table of contents, figure list, table list, terminology and abbreviation section, and cited documents section. Second, the content of each section needs to be extracted and compiled into a list. For example, all headings in the table of contents section, all figure and table headings in the figure and table list section, the content in the terminology and abbreviation section, and all cited documents in the cited documents section are summarized into a check list. Finally, the entire Markdown text is traversed to check if all content in the check list appears in the main text, thus achieving the content matching function.

[0046] ③ Formatting Standard Functions Since this invention requires the automated generation of inspection reports, the output of each verification item must be in a uniform JSON text format. This allows the automatic inspection report generation module to replace the output of the verification items with the report template content, thus achieving automatic report generation. The format specification functions are designed to handle the output of Large Language Model (LLM) nodes and function nodes, ensuring they are converted to standard JSON text format and eliminating interference factors such as spaces, extra characters, and incorrect quotation marks. This provides structured and parsable data input for subsequent inspection report generation. For example, LLM nodes may produce non-standard output due to "illusion" phenomena (e.g., extra spaces, illegal characters, or incomplete JSON structures), and function node output may contain format noise due to programming errors (e.g., unescaped quotation marks or indentation errors). Through the format specification functions, the final output of each verification item workflow is forcibly standardized into clean JSON text, ensuring that the automatic inspection report generation module can seamlessly parse and use the data, avoiding system failures or report generation failures caused by format errors. The main rules of the format specification functions are as follows: The function takes the raw output text of a large language model node or function node as input. This text may contain a JSON prototype but may also contain interfering elements (such as spaces, line breaks, Chinese punctuation, or redundant descriptions). For example, a typical output of a large language model node might be "[{"[[Does the system description section contain a system function overview?]]": "Yes"}]", which contains leading / trailing spaces and redundant quotation marks, affecting the extraction performance of the automatic report generation module. This function is implemented in Python, combining regular expressions and a string processing library to ensure proper JSON formatting. First, regular expressions are used to match and remove all unnecessary spaces and interfering characters. Second, a string processing library is used to detect and fix common JSON format errors, primarily covering quotation mark handling: converting single quotes to double quotes to ensure JSON key-value pairs are compliant; bracket balance: verifying the pairing of [] and {}, automatically completing them if missing; and key-value pair cleanup: removing illegal symbols from JSON key names or values, such as replacing Chinese colons with English ones. The final function outputs a standard JSON string for downstream parsing, ensuring that the output can be correctly extracted by the automatic report generation module by strictly adhering to the set JSON specifications.

[0047] Optionally, the airworthiness certification plan inspection is defined as a checklist-based inspection process, which can quickly adapt to airworthiness certification document standards. When the document standards are updated, the content of the verification items in the checklist can be modified accordingly, improving adaptability to frequent dynamic changes in the certification plan. Furthermore, a visual workflow design is implemented for each verification item, making the inspection process accurately observable and allowing for rapid modification when a problem occurs in a sub-node.

[0048] Therefore, by innovatively combining large language model technology with function nodes, the advantages of large language model semantic understanding, text generation and Python function regular expression matching and logical judgment are integrated. At the same time, precise prompt word restrictions are added, so that more impressive output results can be obtained without too much human intervention. While reducing costs, the reliability of output results is improved, effectively avoiding the "illusion" problem that may occur in large language models and improving the flexibility of the entire inspection process.

[0049] Step S204: Integrate and process the first verification information and the second verification information to generate a verification report.

[0050] In one example, step S204 includes: generating a verification report format file; wherein the verification report format file includes multiple locations to be supplemented identified by preset keywords, and the locations to be supplemented correspond to each verification item; and generating a verification report based on the verification report format file, the first verification information, and the second verification information.

[0051] In one example, step S204 further includes: if the verification report generation fails, then generating a failure list.

[0052] In one example, step S204 further includes: generating a download link; wherein the download link is used to redirect to a target page that displays a verification report and / or a list of failures.

[0053] For example, this application also includes an automatic inspection report generation module. This module is a core output component of the airworthiness certification platform, capable of summarizing the inspection content of each verification item and ultimately presenting it in the form of an inspection report. This module uses the Python Flask framework to implement a web service and can be integrated into the Dify platform via an API (Application Programming Interface) for use as a custom tool in workflows. Furthermore, this module employs intelligent template replacement technology to automatically generate inspection reports and supports automatic highlighting in red when the inspection result of a verification item is "no". The specific implementation details of the inspection report generation module are as follows: (1) Automatic report generation mechanism The automatic report generation function of the inspection report generation module is mainly implemented through the following steps: First, template pre-definition: First, the module needs to prepare a DOCX format inspection report template file (i.e., a verification report format file). This verification report format file contains a series of places to be filled (placeholders) identified by preset keywords, such as [[whether the file name is included]], [[file name]], etc. The placeholders correspond to each verification item and represent the verification items that need to be dynamically filled in the report. At the same time, the module receives HTTP POST requests through a specific API endpoint (such as / generate). The request content is in JSON format and contains structured key-value pair data generated by LLM nodes or function nodes. The JSON format is strictly limited to [key][value] format, such as [{"[[whether the system description section includes a system function overview]]", "yes / no"}]. Figure 4 A schematic diagram of an inspection report template based on an airworthiness certification platform provided in this application embodiment, as shown below. Figure 4 As shown, the inspection report template is named "[[Project Name]] AI Intelligent Review Report".

[0054] Second, intelligent content replacement and formatting This module uses the Python-docx library to load DOCX format verification report files into memory, forming a programmable Document Object Model (DOM). The module also pre-designs a recursive function to perform a depth-first search of all elements in the document, including paragraphs, tables, and text blocks (Runs) within paragraphs. To improve replacement accuracy and preserve the original formatting, the algorithm first merges the text content of all Runs within a paragraph, retaining the font style (size, color, bold, etc.) of the first Run. The merged text is then matched against the received data keys. Once a matching key is found, the corresponding value is used to replace the placeholder in the template. Furthermore, the module includes intelligent highlighting capabilities. When a verification item's result is "no" (i.e., it fails the check), the algorithm highlights the text in red (a technique known as red highlighting) and bolds key content such as the assessment conclusion. The module also records the replacement status (success or failure) of each data key and, after the replacement is complete, counts the total number of items that were judged as "no".

[0055] (2) Automatic display mechanism of download links After the report is generated, a download link is provided to the user through the following process: Upon successful document saving, the module immediately and dynamically constructs a download URL (Uniform Resource Locator) pointing to the file. This URL is constructed by concatenating the server host address (request.host) and the download endpoint path (e.g., / download / <filename>), ensuring the link's validity and direct accessibility. Furthermore, the module intelligently analyzes the data generated during the process and generates a summary message informing the user that the review is complete, along with a list of previously analyzed items that returned a negative result. Upon receiving this response, the front-end interface renders a message containing the issue list and a clickable download link to the user. Clicking the link triggers the browser to download the generated Word report. When the user clicks the link, a request triggers another API endpoint, which uses Flask's send_from_directory function to securely send the file stored in the specified server directory as an attachment to the user's browser, completing the download process.

[0056] (3) Integrate the module into the Dify platform First, deploy this automatic inspection report generation module as a standalone service (e.g., a Docker container) on the server, ensuring that its API is accessible to the Dify platform. Next, create a custom tool on the Dify platform's tool management page. Define the tool by filling in a YAML file or form; the main configurations are as follows: Name: Inspection Report Auto Generator Description: Automatically generates and returns a download link for a review report in Word format based on JSON data.

[0057] API endpoint: http: / / :5000 / generate (POST request) Input parameters: Define a parameter named data, of type object or string (must be a JSON string), to receive structured data input from upstream large model nodes or function nodes.

[0058] After successful integration, an automatic inspection report generation node can be created in Dify's workflow to enable the automatic generation of inspection reports.

[0059] In this embodiment, software qualification approval plan data to be inspected is obtained. Based on multiple verification items in a pre-set verification form, the correctness of the chapters and their contents within the software qualification approval plan data is verified, generating first verification information. This first verification information indicates the correctness of the chapters, the conformity of the content, and the correctness of the content itself. The conformity information indicates whether the content conforms to the chapters. Based on multiple verification items in the pre-set verification form, semantic analysis processing is performed on the chapters and their contents within the software qualification approval plan data, generating second verification information. The first and second verification information are integrated to generate a verification report. Therefore, based on the pre-set verification items in the verification form, the correctness and standardization verification of the software qualification approval plan data are performed. This not only solves the problems of low efficiency and strong subjectivity of traditional manual inspection, reducing human error, but also overcomes the limitations of existing rule-based document review systems in semantic understanding. It achieves high-precision automatic inspection of document correctness (such as chapter content compliance) and standardization (such as terminology consistency), significantly improving the intelligence level and reliability of the airworthiness approval process. Simultaneously, inspection reports are generated in real time, and abnormal inspection results are highlighted in red. Furthermore, it features full-process digital traceability, supports version control and audit trails, and ensures data immutability; automation reduces manual intervention, precise resource scheduling reduces rework rates, and saves costs in the long term; it supports templated configuration, quickly adapting to new regulations or customized needs.

[0060] In one example, the implementation of a single verification item is achieved by linking various modules in a visual orchestration canvas within a pre-built airworthiness certification platform to construct a complete workflow, thereby realizing the inspection process for a single verification item. The patent selects to encapsulate large language models and function writing into separate modules to complete the connection between data. The orchestration of verification item workflows mainly includes three categories: verification items involving simple semantic judgment, verification items involving complex semantic understanding, and verification items using function modules as core processing modules. The orchestration of these three categories of verification items will be explained below through the orchestration process of a typical verification item workflow. The specific verification item orchestration content is shown below: 1. Simple semantic judgment verification items, using "Does the homepage contain file name, file number, version, release date, and copyright statement?" as an example for overview. Figure 5 This application provides a flowchart illustrating a certification plan processing method based on an airworthiness certification platform, with the workflow arranged as follows: Figure 5 As shown: ① Document Upload: Upload the software qualification review plan that needs to be checked.

[0061] ② Document Content Extraction: The main function of the Document Content Extraction node is to extract the Markdown formatted content of a document from the document object, facilitating subsequent operations on the document content. Its input parameter is the document uploaded in the start node, and its output parameter is the Markdown formatted text content.

[0062] ③ Homepage content extraction function: This function is a chapter content extraction function. Its main purpose is to split the software qualification review plan with excessively long content, extract the parts that the large model node needs to judge, and then upload them as input parameters to the large model node, so as to avoid the large language model node consuming a lot of tokens to process too much text.

[0063] ④ Large Model Node: In this workflow, the large language model node primarily checks whether the homepage contains file name, file number, version, release date, and copyright statement based on specified prompts. The output of the large language model node is limited to a fixed-format JSON text output. This is primarily to allow the subsequent report generation function to better integrate the output of each workflow and achieve automatic report generation. Since the large language model only needs to make simple semantic judgments in this verification item, without involving deep semantic understanding, the Qwen-2.5 3B small model (without any thought process) is chosen as the core backend for the large model node. This choice significantly shortens the verification time and does not consume excessive tokens. The model is deployed using LMstudio. When calling the model, it can be invoked by entering the local model call API provided by LMstudio, ensuring that prompts can be customized for different verification items.

[0064] The JSON text is formatted as follows: [{"[[Does the homepage contain file names?]]": "Yes / No"}, {"[[Does the homepage contain file name details?]]": "This content is the complete file name you extracted. If no file name was extracted, the answer will be "File name not found"}]. Only one answer result's JSON format is shown here. The formats of other results are similar and will not be elaborated further.

[0065] ⑤ JSON Text Standardization Function: This function is mainly to avoid the illusion phenomenon of large language models, which would cause them to output incorrectly formatted content. It standardizes the results generated by the large language model, removing symbols, spaces, and other elements that do not conform to the JSON text standard format, thus ensuring the standardization of the output results.

[0066] 2. Verification items related to complex semantic understanding: The following example summarizes the requirements: "Does the software qualification plan include a system description section? Does this section provide an overview of the system, including system function descriptions, system architecture (including software / hardware interfaces), the processor used, function allocation to software and hardware, and security features?" Figure 6 This application provides a flowchart illustrating a certification plan processing method based on an airworthiness certification platform, with the workflow arranged as follows: Figure 6 As shown. This verification item combines the semantic understanding and semantic generation capabilities of a large language model with the regular expression matching and logical judgment capabilities of Python functions, thereby completing the check of complex semantic understanding-related verification items.

[0067] ① Document Upload: Upload the software qualification review plan that needs to be checked.

[0068] ② Document Content Extraction: The main function of the Document Content Extraction node is to extract the Markdown formatted content of a document from the document object, facilitating subsequent operations on the document content. Its input parameter is the document uploaded in the start node, and its output parameter is the Markdown formatted text content.

[0069] ③ System Description Chapter Title Judgment and Content Extraction Function: Implement the function by writing Python code to determine whether the System Description chapter exists in the document. If the chapter exists, extract the complete chapter content. If the System Overview chapter does not exist, output the result that the document does not contain the System Description chapter.

[0070] ④ Judge: Based on the results of the function that determines the chapter in the system description, it is divided into two branches. If the chapter is not included, the corresponding result is output directly. If the chapter content is included, the complete chapter content is passed into the large model node.

[0071] ⑤ Large Model Node: In this workflow, the large language model node primarily performs compliance checks on the system overview section content based on specified prompts. Furthermore, the output of the large language model node is restricted to a fixed-format JSON text output. This is mainly to allow the subsequent report generation function to better integrate the output of each workflow, enabling automatic report generation. For verification items involving complex semantic understanding, the DeepseekR1-32B model is selected. Deepseek models have a thought process for more complex semantic understanding. Using local deployment instead of online API calls ensures no risk of data leakage during upload. The model is deployed using LM Studio, and can be invoked by entering the local model call API provided by LM Studio, ensuring that prompts can be customized for different verification items.

[0072] The JSON text format is as follows: [{"[[Does the System Description section include an overview of system functions?]]": "Yes / No"}]. Only one answer's JSON format is shown here; other results are similar and will not be elaborated further. Restricting the large language model's answers to this format prepares for the automatic generation of subsequent inspection reports. The self-developed automatic report generation function can find content in the results that matches the template and replace it with the final judgment result generated by the large language model.

[0073] The constraints on the prompt words are also based on the content of the verification items to strictly constrain the large language model. The entire process of the prompt words constrains the large language model according to the following steps: role, background, responsibility, skills, goal, constraints, and output format, so as to ensure that the large language model can output the correct judgment result and judgment format.

[0074] ⑥ JSON Text Standardization Function: This function is mainly to avoid the illusion phenomenon caused by the large language model, which leads to the output of incorrect format content. It standardizes the results generated by the large language model, and removes elements such as symbols and spaces that do not conform to the JSON text standard format, so as to ensure the standardization of the output results.

[0075] 3. Verification items using function modules as the core processing module: The workflow orchestration for this type of verification item prioritizes function nodes as the core implementation module rather than large language model nodes. The reason is that when checking document format rather than semantic understanding, the probability of the large language model exhibiting errors increases significantly. For example, when determining whether "the list of figures and / or tables contains all the corresponding table names in the main text and the content is consistent," it is necessary to traverse the entire document for judgment. Uploading the entire document to the large language model would consume too many tokens and the judgment results would be prone to errors. Therefore, this type of verification item uses a combination of function nodes to implement the verification content. The following example, "Does the document have a table of contents?" and "Is the table of contents consistent with the table of contents structure in the main text?", provides an overview. Figure 7 This application provides a flowchart illustrating a certification plan processing method based on an airworthiness certification platform, with the workflow orchestrated as follows: Figure 7 As shown: ① Document Upload: Upload the software qualification review plan that needs to be checked.

[0076] ② Document Content Extraction: The main function of the Document Content Extraction node is to extract the Markdown formatted content of a document from the document object, facilitating subsequent operations on the document content. Its input parameter is the document uploaded in the start node, and its output parameter is the Markdown formatted text content.

[0077] ③ Table of Contents Extraction Function: This function belongs to the category of chapter content extraction functions. Its main purpose is to check whether the uploaded document contains a table of contents. If the document contains a table of contents, the table of contents can be completely extracted and uploaded to the next function node to determine whether the complete table of contents matches the main text table of contents structure.

[0078] ④ Document directory existence checker: This checker divides the result of the directory extraction function into two branches. If the document does not contain a directory, it outputs that the document does not contain a directory; otherwise, it uploads the extracted directory content to the next function node.

[0079] ⑤ Function to check if the table of contents matches the main text structure: This function belongs to the format specification category. Its purpose is to traverse each chapter of the entire document, check whether the chapter content matches the table of contents, and output the final judgment result.

[0080] ⑥ Directory Structure Match Checker: This checker divides the result of the function that checks if the directory and main text structures match into two branches. If they match completely, it outputs that the directory structure and main text structure are consistent; if they do not match, it outputs that they are inconsistent and lists the specific chapters that are inconsistent. The function's output format is still limited to plain text output in JSON format, which will not be elaborated on here. Since the output of the function module does not have the illusion problem, its output does not need to be finally processed by the format specification function.

[0081] The construction of other verification items is similar to that of these three main categories. Different module combinations can be selected based on the specific content required for each verification item. For example, the verification item of whether a directory exists and whether its content corresponds one-to-one with the text titles can be checked using the text content matching functions described earlier. This eliminates the need to add a large language model node to the workflow, reducing the consumption of large language model tokens while improving the accuracy of the check results. For verification items involving simple semantic understanding, such as whether a document correctly lists its historical authors and version records, the large language model node can use the thoughtless Qwen-2.5 3B model. This reduces check time and token consumption, preventing the large language model node from generating incorrect judgments due to "illusions."

[0082] When the verification items change, such as when the DO-178C document is updated or when airworthiness experts suggest changes to the verification items, the functions implemented by adding / removing the number of modules or changing the function nodes can be used to quickly change the verification items without affecting other verification items. The verification items can be updated quickly through the design of the canvas layout.

[0083] In one example Figure 8 A flowchart illustrating a certification plan processing method based on an airworthiness certification platform, as provided in this application embodiment, is shown below. Figure 8 As shown, this includes: uploading the software qualification assessment plan data to be inspected; verification items (verification items are...) Figure 8 (Inspection items) 1 Sub-process module, Verification items (Verification items are...) Figure 8 (Inspection items) 2 Sub-process module, Verification items (Verification items are...) Figure 8 The inspection items in the process) 3 sub-process modules, verification items (verification items are...) Figure 8The implementation encapsulates the verification item process into a callable module, allowing it to be invoked in new workflows. Each verification item module is integrated into a complete verification form workflow, ultimately producing only one output containing JSON-formatted inspection results for multiple verification items. This final output is then fed into the automatic inspection report generation node to generate the corresponding verification report. This airworthiness certification platform achieves a series of functions, including document upload, problem classification, overall inspection, text extraction, semantic analysis, conclusion drawing, and report generation. The software qualification certification plan inspection is just one application example of this application; through a systematic automatic inspection method, it can be extended to the automatic inspection of other categories of airworthiness certification plans.

[0084] Corresponding to the above method, this application also provides a certification plan processing device based on an airworthiness certification platform, such as... Figure 9 As shown, the device includes: Module 41 is used to acquire the software qualification approval plan data to be inspected; The inspection module 42 is used to perform correctness verification and standardization verification on the software qualification review plan data according to multiple verification items in the preset verification form, and generate first verification information and second verification information; wherein, the first verification information is used to indicate correctness information, and the second verification information is used to indicate standardization information; The generation module 43 is used to integrate and process the first verification information and the second verification information to generate a verification report.

[0085] The functions of each functional unit of the certification plan processing device based on the airworthiness certification platform provided in the above embodiments of this application can be implemented through the above method steps. Therefore, the specific working process and beneficial effects of each unit in the certification plan processing device based on the airworthiness certification platform provided in the embodiments of this application will not be repeated here.

[0086] This application also provides an electronic device, such as... Figure 10 As shown, it includes a processor 510, a communication interface 520, a memory 530, and a communication bus 540, wherein the processor 510, the communication interface 520, and the memory 530 communicate with each other through the communication bus 540.

[0087] Memory 530 is used to store computer programs; The processor 510 performs the above steps when executing the program stored in the memory 530.

[0088] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0089] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0090] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0091] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0092] The implementation methods and beneficial effects of the various components of the electronic device in the above embodiments for solving the problem can be found in [reference needed]. Figure 1 The steps in the illustrated embodiments are used to implement the electronic device. Therefore, the specific working process and beneficial effects of the electronic device provided in this application will not be repeated here.

[0093] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores instructions that, when executed on a computer, cause the computer to perform any of the certification plan processing methods based on the airworthiness certification platform described in the above embodiments.

[0094] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the certification plan processing methods based on the airworthiness certification platform described in the above embodiments.

[0095] Those skilled in the art will understand that the embodiments in this application can be provided as methods, systems, or computer program products. Therefore, the embodiments in this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments in this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The embodiments in this application are described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments in this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, produce implementations of the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0096] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0097] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0098] Although preferred embodiments have been described in this application, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of this application. Clearly, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. Thus, if these modifications and variations of the embodiments of this application fall within the scope of the claims in this application and their equivalents, then this application is also intended to include these modifications and variations.

Claims

1. A method for processing certification plans based on an airworthiness certification platform, characterized in that, The method includes: Obtain the software conformity assessment plan data to be inspected; Based on multiple verification items in the preset verification form, the software qualification review plan data is verified for correctness and compliance, generating first verification information and second verification information; wherein, the first verification information is used to indicate correctness information, and the second verification information is used to indicate compliance information; The first verification information and the second verification information are integrated and processed to generate a verification report.

2. The method as described in claim 1, characterized in that, Based on multiple verification items in the preset verification form, the software qualification approval plan data is verified for correctness and standardization, generating first verification information and second verification information, including: Based on multiple verification items in the preset verification form, the correctness of the chapters and the content under the chapters in the software qualification review plan data is verified, and first verification information is generated; wherein, the first verification information is used to indicate the correctness information of the chapter, the conformity information of the content, and the correctness information of the content; the conformity information indicates whether the content conforms to the chapter; Based on multiple verification items in the preset verification form, semantic analysis is performed on the chapters of the software qualification review plan data and the content under the chapters to generate second verification information.

3. The method as described in claim 2, characterized in that, Based on multiple verification items in the preset verification form, semantic analysis is performed on the chapters and contents under the chapters of the software qualification approval plan data to generate second verification information, including: Based on multiple verification items in the preset verification form, the software qualification approval plan data is processed by text extraction to generate extracted text; Generate prompts for each verification item; Based on the prompt words corresponding to each verification item, the extracted text is subjected to semantic analysis to generate second verification information.

4. The method as described in claim 2, characterized in that, Based on multiple verification items in the preset verification form, semantic analysis is performed on the chapters and contents under the chapters of the software qualification approval plan data to generate second verification information, including: Based on multiple verification items in the preset verification form and the preset document content matching function, semantic analysis and extraction processing are performed on the software qualification review plan data to generate a list to be verified. Based on the list to be verified, the software qualification review plan data is traversed to generate second verification information; wherein, the normative information indicated by the second verification information includes whether the software qualification review plan data is consistent with the list to be verified.

5. The method according to any one of claims 1-4, characterized in that, The first verification information and the second verification information are integrated and processed to generate a verification report, including: Generate a verification report format file; wherein, the verification report format file includes multiple preset keyword identifiers for locations to be supplemented, and the locations to be supplemented correspond to each verification item; A verification report is generated based on the verification report format file, the first verification information, and the second verification information.

6. The method as described in claim 5, characterized in that, The method further includes: If the verification report fails to be generated, a failure list will be generated.

7. The method as described in claim 6, characterized in that, The method further includes: Generate a download link; wherein the download link is used to redirect to a target page, the target page displaying the verification report and / or the failure list.

8. A certification plan processing device based on an airworthiness certification platform, characterized in that, The device includes: The acquisition module is used to acquire the software conformity assessment plan data to be inspected; The inspection module is used to perform correctness verification and standardization verification on the software qualification review plan data according to multiple verification items in the preset verification form, and generate first verification information and second verification information; wherein, the first verification information is used to indicate correctness information, and the second verification information is used to indicate standardization information; The generation module is used to integrate and process the first verification information and the second verification information to generate a verification report.

Images