Automatic driving system architecture design management method, system and medium

Abstract

The present application relates to a kind of automatic driving system architecture design management method, system and medium, the method includes obtaining the architecture design management problem to be processed, and according to architecture design management problem Generation or select work paradigm template;Work paradigm template is split into multiple step items, wherein each step item includes input information, implementation and output result;For each step item, mark its dependent upstream step item, and construct dependency graph according to the dependency relationship between step item;Dependency graph is sorted and processed, to generate serial execution flow;According to serial execution flow, each step item is executed item by item, wherein according to the task type of each step item, select the corresponding implementation path, and implementation path includes one or more of artificial input, search enhancement generation link, rule method and external process;And the execution result of each step item is written into context cache, and the information in context cache is passed to subsequent step item as input.

Description

Technical Field

[0001] This invention relates to the field of electronic digital data processing technology, and in particular to a method, system, and medium for designing and managing the architecture of an autonomous driving system. Background Technology

[0002] With the development of autonomous driving technology, vehicle functions are gradually expanding from simple driver assistance to higher levels and more complex system capabilities. High-level autonomous driving systems involve multiple subsystems, including perception, localization, fusion, prediction, planning, control, human-machine interaction, chassis control, body control, diagnostics, communication, and cloud-vehicle collaboration. Their system architecture design needs to comprehensively consider differences in vehicle platform, sensor configuration, controller capabilities, functional definitions, interface signals, associated component capabilities, historical project experience, and regulatory safety requirements. In actual R&D, companies accumulate a large amount of historical design documents, requirement documents, review records, system design specifications, interface documents, functional link descriptions, and problem closure records. These materials contain a wealth of reusable domain knowledge and engineering experience, but most are unstructured or semi-structured, scattered across different documents, projects, and platforms. Retrieval-enhanced generation (RAG) technology can combine external knowledge base retrieval results with generative models to provide answers for specific tasks that are closer to the internal knowledge base.

[0003] However, existing technologies still have some shortcomings. Traditionally, engineers rely on experience to determine which documents to retrieve, which information to extract, how to organize the analysis process, and how to output evaluation conclusions, leading to efficiency heavily influenced by human experience. In the scenario of autonomous driving system architecture design and management, using RAG alone is insufficient to fully address the problem. On one hand, architecture design tasks are usually not simple question-and-answer sessions but require step-by-step completion according to a defined business process; on the other hand, some steps require accurate interface comparisons, signal difference verification, or database queries. These tasks are better suited to rule-based methods or tools rather than being entirely generated by large language models. Furthermore, existing technologies lack mechanisms to abstract architecture design paradigms into standardized steps, mechanisms to automatically generate sequential execution flows based on dependencies between steps, unified orchestration capabilities for combining manual processes, RAG / large language models, rule tools, and external review processes within the workflow, and mechanisms for passing intermediate results through context caching and ensuring process traceability. Summary of the Invention

[0004] In view of the shortcomings of the prior art described above, the purpose of this invention is to provide an autonomous driving system architecture design management method, system and medium. By abstracting the architecture design paradigm into standardized steps and automatically generating a serial execution flow based on the dependencies between steps, and combining the unified orchestration capabilities of manual, RAG / large language model, rule tools and external countersigning processes as well as a context caching mechanism, the efficiency, accuracy and traceability of autonomous driving system architecture design can be effectively improved.

[0005] To achieve the above objectives, the present invention adopts the following technical solution.

[0006] Firstly, the present invention provides an autonomous driving system architecture design and management method, which adopts the following technical solution: Identify pending architecture design management issues and generate or select a working paradigm template based on those issues. The work paradigm template is broken down into multiple steps, each of which includes input information, implementation method, and output result; For each step item, label the upstream step items it depends on, and construct a dependency graph based on the dependencies between step items; The dependency graph is sorted to generate a serial execution flow; Each step is executed sequentially according to the described serial execution flow, wherein a corresponding implementation path is selected based on the task type of each step. The implementation path includes one or more of the following: manual input, retrieval-enhanced generation chain, rule-based methods, and external processes; and The execution results of each step are written to the context cache, and the information in the context cache is passed to the subsequent step as input.

[0007] Furthermore, in the above method, the step of sorting the dependency graph to generate a serial execution flow includes: Perform cycle detection on the dependency graph; If no cycle exists, a serial execution order is generated based on the sorting of dependent nodes; and If a loop exists, the loop is broken to generate a serial execution order.

[0008] Furthermore, in the above method, the damage treatment includes at least one of the following: Rewrite the loop process into a finite number of sequential steps; and Multiple cyclic steps are aggregated into a single composite step.

[0009] Furthermore, in the above method, the step of selecting the corresponding implementation path based on the task type of each step includes: For steps that require explicit input, information should be obtained through manual input. For steps that require semantic retrieval and information extraction based on historical design documents, this can be achieved through retrieval enhancement generation links or large language model links. For steps requiring comparison or difference analysis, a rule-based approach is used; and For steps that require external confirmation, this is achieved through an external process.

[0010] Furthermore, in the above method, the step of retrieving enhanced generation links or large language model links includes: Generate search criteria based on the input of the current step item and the information in the context cache; Retrieve relevant document blocks from historical design documents; and The search criteria, the relevant document blocks, and the preset prompt templates are input into the large language model to generate structured output results.

[0011] Furthermore, in the above method, the implementation through rule-based methods includes: Read the output of the upstream step item from the context cache; Retrieve the data to be compared from an internal database or interface file; and Field-level comparisons are performed using rule scripts or difference comparison tools to generate difference analysis results.

[0012] Furthermore, in the above method, the information stored in the context cache includes at least one of the following: Basic task information, manually input information, enhanced search results, rule execution results, large language model generated results, exception prompts, referenced documents, and external countersigning status.

[0013] Furthermore, in the above method, the architecture design management problem includes at least one of the following types: Functional reverse switching feasibility assessment, new functional architecture scheme evaluation, cross-vehicle function reuse analysis, platform interface difference analysis, and functional link integrity check.

[0014] Furthermore, the above method also includes: After all step items have been executed, the output results of each step item are read from the context cache; and An architecture design management evaluation report is generated according to a preset report template, wherein the conclusions in the evaluation report are linked to the corresponding step items and upstream basis.

[0015] Furthermore, in the above method, the step item includes at least one of the following: Define the functional baseline vehicle and baseline, define the target vehicle and baseline, define the specific functions, retrieve the relevant design documents, define the differences between vehicle platforms, define the functional related components, define the functional related signals, evaluate the signal correspondence and differences, evaluate the changes to the related components and conduct a preliminary assessment of the architectural feasibility.

[0016] Secondly, the autonomous driving system architecture design and management system provided by this invention adopts the following technical solution: The problem acquisition module is used to acquire architecture design management problems to be processed, and generate or select a working paradigm template based on the architecture design management problems. The step splitting module is used to split the work paradigm template into multiple step items, wherein each step item includes input information, implementation method and output result; The dependency building module is used to mark the upstream step items that each step item depends on, and to build a dependency graph based on the dependency relationships between step items; The process generation module is used to sort the dependency graph and generate a serial execution process; The step execution module is used to execute each step item sequentially according to the serial execution flow, wherein the corresponding implementation path is selected according to the task type of each step item, and the implementation path includes one or more of manual input, retrieval enhancement generation link, rule method, and external process; and The context management module is used to write the execution results of each step item into the context cache and pass the information in the context cache to subsequent step items as input.

[0017] Thirdly, the present invention provides a readable storage medium, which adopts the following technical solution: A readable storage medium storing computer instructions that, when executed by a processor, implement the method as described in any one of the first aspects above.

[0018] In summary, compared with the prior art, the present invention has at least one of the following beneficial technical effects: The method of this invention abstracts the architectural design paradigm into standardized steps, enabling the systematic decomposition and management of complex architectural design tasks and reducing reliance on individual engineer experience. By automatically generating a serial execution flow based on the dependencies between steps, it ensures that each step is executed in the correct logical order, avoiding information loss or duplication of work due to incorrect execution order. By selecting different implementation paths based on task type, such as manual input, retrieval-enhanced generation links, rule-based methods, or external processes, it ensures that each type of task adopts the most suitable processing method, leveraging the advantages of large language models in semantic understanding and information extraction while ensuring the accuracy of precise tasks such as interface comparison and signal difference verification. Through a context caching mechanism, the execution results of each step are passed, achieving complete recording of intermediate states and effective information transmission, ensuring the traceability of the entire architectural design management process and the interpretability of the conclusions. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A flowchart of an autonomous driving system architecture design management method according to an embodiment of the present invention is shown.

[0021] Figure 2 A flowchart illustrating the sorting process of a dependency graph according to an embodiment of the present invention is shown.

[0022] Figure 3 A flowchart illustrating the selection of an implementation path based on task type according to an embodiment of the present invention is shown.

[0023] Figure 4 A flowchart illustrating the steps of generating links by retrieval enhancement according to an embodiment of the present invention is shown.

[0024] Figure 5 A flowchart illustrating the implementation of step items via a rule-based method according to an embodiment of the present invention is shown.

[0025] Figure 6 A flowchart illustrating the generation of an architecture design management evaluation report according to an embodiment of the present invention is shown.

[0026] Figure 7 A structural block diagram of an autonomous driving system architecture design and management system according to an embodiment of the present invention is shown. Detailed Implementation

[0027] 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 some embodiments of this application, and not all 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. Furthermore, it should be understood that the specific embodiments described herein are only for illustration and explanation of this application and are not intended to limit this application.

[0028] It should be noted that the order of description of the following embodiments is not intended to limit the preferred order of the embodiments of this application. Furthermore, the descriptions of each embodiment in the following embodiments have their own emphasis; for parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0029] The method steps described in this embodiment of the invention can be executed in the order described in the specific implementation, or the execution order of each step can be adjusted according to actual needs, provided that the technical problem can be solved. These are not listed one by one here.

[0030] The present invention will be further described in detail below with reference to the accompanying drawings.

[0031] Reference Figure 1 This invention provides an autonomous driving system architecture design management method 100, which transforms the working paradigm in autonomous driving system architecture design management into an executable serial process, and calls manual input, retrieval enhancement generation links, rule methods and external processes as needed in each process step, thereby realizing the effective use of unstructured historical design data, the automated decomposition of complex design tasks and the rule-based guarantee of accuracy tasks.

[0032] Method 100 includes steps 102, 104, 106, 108, 110, and 112.

[0033] In step 102, the architecture design management issues to be processed are obtained, and a working paradigm template is generated or selected based on the architecture design management issues. Architecture design management issues include at least one of the following types: functional backslicing feasibility assessment, new functional architecture scheme evaluation, cross-vehicle function reuse analysis, platform interface difference analysis, and functional link integrity check. The working paradigm template corresponds to a specific type of architecture design management task and is used to define the processing flow for that task.

[0034] Step 104 breaks down the work paradigm template into multiple step items, each of which includes input information, implementation method, and output result. This breakdown method decomposes complex architecture design and management tasks into several executable, verifiable, and reusable processing units. Each step item, as a basic unit of the process, has clearly defined inputs, processing methods, and outputs.

[0035] Step 106: For each step item, label its dependent upstream step items and construct a dependency graph based on the dependencies between step items. If the input of one step item depends on the output of another step item, a directed dependency relationship is established between them. The dependency graph represents the information flow and upstream / downstream dependencies between step items.

[0036] Step 108 sorts the dependency graph to generate a serial execution flow. The sorting process transforms the dependency graph into a serial link with a defined execution order, ensuring that each step is executed in the correct logical order.

[0037] Step 110 executes each step sequentially according to the serial execution flow. The corresponding implementation path is selected based on the task type of each step, and these paths include one or more of the following: manual input, retrieval-enhanced generation, rule-based methods, and external processes. For steps requiring explicit input, information is obtained through manual input; for steps requiring semantic retrieval and information extraction based on historical design documents, retrieval-enhanced generation or large language model methods are used; for steps requiring comparison or difference analysis, rule-based methods are used; and for steps requiring external confirmation, external processes are used.

[0038] Step 112 writes the execution results of each step to the context cache and passes the information in the context cache to subsequent step items as input. The output of the previous step item is passed as context information to the downstream step item, thereby transforming the complex analysis process that traditionally relies on engineer experience into an orchestratable and reusable workflow. The information stored in the context cache includes at least one of the following: basic task information, manual input information, search enhancement-generated search results, rule execution results, large language model generation results, exception prompts, referenced documents, and external countersigning status.

[0039] Method 100 is deployed as a local tool, server tool, or R&D management platform plugin. The inputs to Method 100 include a description of the problem to be evaluated, the functional base vehicle and current baseline, the vehicle and baseline requiring reverse switching, specific functional items, historical design documents, CTS / SSTS documents, vehicle platform information, related component information, and signal interface information from the internal database. The outputs of Method 100 include the execution results of each step, platform difference analysis results, signal difference analysis results, related component change items, preliminary architectural feasibility assessment conclusions, and evaluation materials for external review and approval.

[0040] As described above, step 108 sorts the dependency graph to generate a serial execution flow. Figure 2 The specific process of sorting the dependency graph 200 to generate a serial execution flow is illustrated. The sorting process 200 includes steps 202, 204, 206, 208, and 210.

[0041] Step 202 performs cycle detection on the dependency graph. Cycle detection is used to determine whether there are circular dependencies in the dependency graph, that is, the output of a certain step becomes the input of the same step after passing through several intermediate steps. Cycle detection identifies whether there is a path starting from a certain node, passing through several nodes, and returning to the same node by traversing the directed edges in the dependency graph.

[0042] Step 204 determines whether a cycle exists in the dependency graph based on the cycle detection results. If the cycle detection results indicate that no cycle exists in the dependency graph, the sorting process 200 proceeds to step 210; if the cycle detection results indicate that a cycle exists in the dependency graph, the sorting process 200 proceeds to step 206.

[0043] When there are no cycles in the dependency graph, step 210 generates a serial execution order based on the dependency node sorting. The specific process of dependency node sorting is as follows: Select steps in the dependency graph that have no upstream dependencies and assign execution numbers to these steps according to preset rules; remove the numbered steps from the dependency graph; select new steps without upstream dependencies and assign execution numbers; repeat the above process until all steps are numbered; arrange the steps in the order of their numbers to obtain the serial execution flow. Through dependency node sorting, the dependency graph is transformed into a serial link with a definite execution order.

[0044] When a cycle exists in the dependency graph, step 206 performs cycle breaking processing to generate a serial execution order. Cycle breaking processing includes at least one of the following methods: rewriting the cyclic process into a finite number of serial steps, and aggregating multiple cyclic step items into a composite step item.

[0045] In some implementations, rewriting the loop process into a finite number of sequential steps is suitable for scenarios requiring iterative convergence. For example, when the output of a certain step needs to be repeatedly fed back to the upstream step for convergence, the loop process is limited to a finite number of sequential steps, such as three sequential steps: "initial evaluation - correction - re-evaluation". By limiting the number of iterations, the loop process is expanded into a sequence of sequential steps with a clear execution order.

[0046] In some implementations, aggregating multiple cyclic step items into a single composite step item is suitable for local iteration scenarios. The multiple cyclic step items are aggregated into a composite step item, where the local iteration logic is handled internally, while the external process maintains a serial output. The composite step item participates in dependency node sorting as a whole, thereby eliminating cycles in the dependency graph.

[0047] After step 206 completes the dependency disruption process, step 208 generates a serial execution order based on the dependency graph after the disruption process. Step 208 uses the same dependency node sorting method as step 210 to sort the dependency graph after the disruption process and generate a serial execution flow.

[0048] Through the above sorting process 200, regardless of whether there are cycles in the dependency graph, a serial execution flow with a definite execution order and termination condition can be generated, so that each step can be executed in the correct logical order.

[0049] As described above, step 110 executes each step item sequentially according to the serial execution flow, wherein the corresponding implementation path is selected according to the task type of each step item. Figure 3 The implementation path selection process 300 is shown, which selects the corresponding implementation path based on the task type of each step. The implementation path selection process 300 includes steps 302, 304, 306, 308 and 310.

[0050] Step 302 determines the task type of the step item and selects the corresponding implementation path. Implementation paths include one or more of the following: manual input, retrieval-enhanced generation chain, rule-based methods, and external processes. The task type of a step item determines which implementation path to use. Each step item includes a step number, step name, upstream dependencies, input information, implementation method, output result, and output format. Through this attribute composition method, the step item, as the basic unit of the process, has clearly defined inputs, processing methods, and outputs.

[0051] For steps requiring explicit input, step 304 obtains information through manual input. Steps requiring explicit input include vehicle model, baseline, and function name—content that requires user confirmation or cannot be automatically determined. After the user inputs relevant information in the tool interface or command entry, a basic completeness check is performed on the manual input. This check includes verifying whether the vehicle model / platform field, baseline field, and function name field are empty, and whether the Base vehicle model and the reverse-cut vehicle model are both filled in. If information is missing, the user is prompted to supplement it; if the information is complete, the manually entered information is written to the context cache.

[0052] Step 306 addresses steps requiring semantic retrieval and information extraction based on historical design documents, implemented through a retrieval-enhanced generation link or a large language model link. Steps requiring semantic retrieval and information extraction based on historical design documents include document retrieval, functional description extraction, platform difference analysis, related component identification, and functional signal identification. The retrieval-enhanced generation link or the large language model link can retrieve content related to the current step from unstructured historical design documents and organize and extract information from the document semantics using a large language model.

[0053] In some implementations, for steps implemented through retrieval-enhanced generation links or large language model links, a prompt template and output format are configured for each type of step, instead of using completely open-ended questions and answers. The prompt template includes the current vehicle platform, a list of involved functional items, related document chunks, upstream step output, and an output template. The output template is required to include structured fields and uncertainty markers. For information not explicitly stated in the document, the large language model should not automatically complete it into a definitive conclusion, but should indicate in the uncertainty marker that manual confirmation is required. By using prompt templates and structured output, retrieval-enhanced generation links or large language model links can both utilize the generative model to organize the document semantics and reduce the risk of arbitrary generation through structured output and uncertainty markers.

[0054] Step 308, for steps requiring comparison or difference analysis, is implemented using rule-based methods. Steps requiring comparison or difference analysis include tasks with high accuracy requirements such as CTS / SSTS retrieval, signal correspondence comparison, and interface difference checks. Rule-based methods are implemented through internal databases, rule scripts, or difference comparison tools, rather than relying on large language models for free inference. Rule-based methods include exact function name matching, function alias matching, vehicle platform matching, baseline version matching, and document type filtering. By delegating the comparison work to rule-based methods or difference comparison tools, the large language model avoids inferring correspondences based on incomplete context, thereby improving the accuracy of interface, signal, and difference-related tasks.

[0055] Step 310: For steps requiring external confirmation, this is accomplished through an external process. Steps requiring external confirmation include those requiring confirmation from the developers of related components. The external process submits the initial evaluation materials, issues to be confirmed, a list of related components, and discrepancies to the relevant developers or review processes. After the external process is completed, the developers' confirmation comments, supplementary risks, and countersigning conclusions are written back to the context cache as part of the final evaluation report.

[0056] The above-described path selection process 300 selects the appropriate implementation path based on the task type of each step, ensuring that each type of task can be handled using a suitable method. Manual input is used to obtain information requiring user confirmation; the retrieval enhancement generation link or the large language model link is used for semantic retrieval and information extraction from historical design documents; rule-based methods are used to handle comparison and difference analysis tasks with high accuracy requirements; and external processes are used to obtain matters requiring confirmation from multiple teams. This path selection method improves automation while avoiding the accuracy risks associated with relying solely on large language models for all tasks.

[0057] Figure 4 The specific process of implementing step items through retrieval enhancement generation link 400 is illustrated. As described above, for step items that require semantic retrieval and information extraction based on historical design documents, this is achieved through retrieval enhancement generation link or large language model link. Retrieval enhancement generation link 400 includes steps 402, 404, and 406.

[0058] Step 402 generates search criteria based on the input of the current step item and information in the context cache. The search criteria are generated based on information such as the function name, the base vehicle platform, and the CTS / SSTS document name. When executing a step item in the search enhancement generation chain, the vehicle platform information, baseline information, and function item information output from the upstream step item are read from the context cache, and this information is combined into search criteria. The search criteria are used to locate document blocks related to the current step item from historical design documents.

[0059] Step 404 retrieves relevant document blocks from historical design documents. Historical design documents include Autonomous Driving Function CTS, SSTS, System Architecture Design Specifications, historical vehicle platform data, signal interface specifications, related component specifications, functional link specifications, and historical review records. For unstructured documents, they are segmented according to document chapters, titles, functional items, interface names, or fixed-length text blocks. A document index is established with index fields related to document name, version, vehicle platform, functional item, and baseline information. The document index is matched using search criteria to retrieve document blocks relevant to the current step.

[0060] Step 406 inputs the search criteria, relevant document blocks, and a preset prompt template into the large language model to generate structured output results. The prompt template includes vehicle platform placeholders, function item list placeholders, document block placeholders, and output template placeholders. In some implementations, the prompt template is expressed as: the current vehicle platform is <vehicle platform placeholder>, the specific function item list is <function item list placeholder>, the block associated with the CTS document is <document block placeholder>, please output the function-related signal list in JSON format, specifically in the format <output template placeholder>.

[0061] The large language model's output template must include fields such as signal_name, sender, receiver, meaning, source_document, related_function, confidence, and uncertain_reason. For information not explicitly stated in the document, the large language model should not automatically complete it into a definitive conclusion; instead, it should indicate in the uncertain_reason field that manual confirmation is required. The large language model's output results should be marked as requiring manual confirmation or entering the rule comparison step, thus avoiding directly using uncertain content as the final conclusion.

[0062] In some implementations, if the CTS / SSTS document for which the target function is not detected in the enhanced generation link, an error message is output, and subsequent steps are blocked or a manual supplementation process is initiated. This approach ensures that when the search results are insufficient to support subsequent analysis, the process does not force a definitive conclusion but instead prompts the user to supplement relevant information.

[0063] By enhancing the generation link 400 through the above retrieval, content related to the current step item is retrieved from unstructured historical design documents, and the semantics of the documents are organized and information is extracted through a large language model. At the same time, the risk of arbitrary generation is reduced through structured output and uncertainty labeling.

[0064] As mentioned above, steps requiring comparison or difference analysis are implemented using a rule-based approach. Figure 5 The specific process of implementing the step item through rule method 500 is shown. Rule method 500 includes steps 502, 504, and 506.

[0065] Step 502 reads the output of the upstream step item from the context cache. The output of the upstream step item includes a list of function-related signals extracted from the enhanced generation link, manually input vehicle platform information, and baseline information. When executing the step item of the rule method, the structured data output by the upstream step item is retrieved from the context cache as input for rule comparison.

[0066] Step 504 retrieves the data to be compared from the internal database or interface files. The internal database stores structured data such as vehicle platform information, signal interface definitions, related parts lists, and baseline version information. Interface files include signal definition tables, interface specification files, and signal matrix files from CTS / SSTS documents. When retrieving CTS / SSTS documents using rule-based methods, the matching methods employed include exact function name matching, function alias matching, vehicle platform matching, baseline version matching, and document type filtering. Exact function name matching is used to locate document entries that are exactly the same as the target function name; function alias matching is used to handle situations where the same function uses different names in different projects or documents; vehicle platform matching is used to filter documents related to the target vehicle platform; baseline version matching is used to locate documents under a specific baseline version; and document type filtering is used to distinguish between CTS documents, SSTS documents, and other types of documents.

[0067] Step 506 involves performing field-level comparisons using rule scripts or difference comparison tools to generate difference analysis results. In some implementations, signal comparison establishes a correspondence based on fields such as signal name, transmitter, receiver, data type, value range, period, and link direction. The signal name field uniquely identifies the signal; the transmitter and receiver fields identify the sender and receiver; the data type field describes the signal's data format; the value range field defines the signal's valid value range; the period field describes the signal's transmission period; and the link direction field identifies the signal's transmission direction within the functional link.

[0068] Signal comparison results are categorized into one of the following types: Matchable, Name Difference / Mapping Required, Missing / Addition or Adaptation Required, Definition Difference / Further Evaluation Required. Matchable means the signals for the Base model and the target model match across all fields; Name Difference / Mapping Required means the signals have the same function but differ in name, requiring a mapping relationship to be established; Missing / Addition or Adaptation Required means the target model lacks a corresponding signal, requiring the addition of a signal or adaptation development; Definition Difference / Further Evaluation Required means the signal exists but the field definitions differ, requiring further evaluation of the impact of these differences.

[0069] In some implementations, the rule script performs field-by-field matching according to preset comparison rules and writes the comparison results into the difference analysis results. The difference comparison tool supports batch signal comparison and generates structured output containing difference items, difference types, and difference details. The difference analysis results are written to a context cache for subsequent steps to read and use.

[0070] By using the aforementioned rule method 500, the comparison work is delegated to rule scripts or difference comparison tools, avoiding large language models from inferring correspondences based on incomplete context, thereby improving the accuracy of interface, signal, and difference tasks.

[0071] After completing each step, Method 100 proceeds to the evaluation report generation stage. Figure 6 The diagram illustrates an evaluation report generation process 600 for generating an architecture design management evaluation report. The evaluation report generation process 600 includes steps 602, 604, and 606.

[0072] Step 602 indicates that all steps have been completed. Once all steps in the serial execution flow have been executed and the output of each step has been written to the context cache, the evaluation report generation process 600 begins.

[0073] Step 604 reads the output results of each step from the context cache. As mentioned above, the information stored in the context cache includes at least one of the following: basic task information, human input information, retrieval results generated by retrieval enhancement, rule execution results, large language model generation results, anomaly prompts, cited documents, and external countersigning status. The data in the context cache is stored using both structured fields and text summaries. For human input and rule comparison results, structured fields are used; for analysis content generated by the retrieval enhancement generation link or the large language model link, text results, cited document block identifiers, and explanations of uncertainties are also stored. Through this storage method, downstream step items can read the output of upstream step items, and users can also view the basis for each conclusion in the final report.

[0074] Step 606 generates an architecture design management assessment report according to a preset report template, where the conclusions in the assessment report are linked to the corresponding step items and upstream basis. The assessment report includes at least the following: basic task information, base vehicle model and baseline, target reverse-cut vehicle model and baseline, specific functions, retrieved CTS / SSTS documents, platform differences, list of related components, list of function-related signals, signal difference analysis, related component change items, preliminary assessment of architecture feasibility, issues to be confirmed, and the development team's signed conclusion.

[0075] In some implementations, each conclusion in the evaluation report is linked to a corresponding step and upstream basis. For example, platform differences come from the step of clarifying differences between vehicle models and platforms; the signal list comes from the step of clarifying function-related signals; signal differences come from the step of evaluating signal correspondence and difference analysis; related component changes come from the step of evaluating related component changes; preliminary feasibility assessment comes from the step of preliminary architectural feasibility assessment; and final confirmation comes from the step of collaborating with related component developers. This organizational method allows users to trace the process of generating each conclusion, facilitating review, evaluation, and subsequent reuse.

[0076] The associated parts list is organized according to fields such as associated part name, domain, function, relationship to function, whether it exists in the base model, and whether it exists in the target model. The change item output includes the change item name, reason for change, scope of impact, involved teams, whether development is required, whether testing and verification are required, and suggested handling methods.

[0077] If a step fails to obtain sufficient information, the final report will mark that step as requiring manual confirmation or supplementary information, rather than forcibly generating a definitive conclusion. For example, if the retrieval of the enhanced generation link fails to detect the CTS / SSTS document for the target function, the retrieval step will output an anomaly message, and subsequent steps will be blocked or enter the manual supplementation process. If the signal difference analysis step finds that the target vehicle model is missing a signal, the architecture feasibility preliminary assessment step will list this signal as a high-risk item and submit it for confirmation from the related component developer in the related component developer integration step.

[0078] Through the aforementioned evaluation report generation process 600, after all steps are completed, the output results of each step are read from the context cache, and an architecture design management evaluation report is generated according to a preset report template. The conclusions in the evaluation report are linked to the corresponding step items and upstream references, making the entire architecture design management process traceable and the conclusions interpretable.

[0079] In addition to the above-described method embodiments, the present invention also provides system embodiments for performing the above-described methods. Figure 7 The diagram illustrates the structural block diagram of an autonomous driving system architecture design and management system 700. The autonomous driving system architecture design and management system 700 is configured to transform the work paradigm in autonomous driving system architecture design and management into an executable serial process, and to invoke human input, retrieve enhanced generation links, rule methods, and external processes as needed in each process step.

[0080] The autonomous driving system architecture design and management system 700 includes a problem acquisition module 702, a step decomposition module 704, a dependency building module 706, a process generation module 708, a step execution module 710, and a context management module 712.

[0081] The problem acquisition module 702 is configured to acquire pending architecture design management problems and generate or select a working paradigm template based on these problems. Architecture design management problems include at least one of the following types: functional backsliding feasibility assessment, new function architecture scheme assessment, cross-vehicle function reuse analysis, platform interface difference analysis, and function link integrity check. Functional backsliding feasibility assessment evaluates the technical feasibility of switching a function from a base vehicle model to a target vehicle model; new function architecture scheme assessment evaluates the implementation scheme of a new function under the existing system architecture; cross-vehicle function reuse analysis analyzes the reuse of the same function across different vehicle platforms; platform interface difference analysis analyzes the interface differences between different vehicle platforms; and function link integrity check checks whether the signal links involved in function implementation are complete. The problem acquisition module 702 selects the corresponding working paradigm template from a preset working paradigm template library based on the type of architecture design management problem, or dynamically generates a working paradigm template based on the problem description.

[0082] The step decomposition module 704 is configured to decompose the work paradigm template into multiple step items, where each step item includes input information, implementation method, and output result. The step item includes at least one of the following: clarifying the functional baseline vehicle model and baseline, clarifying the target vehicle model and baseline, clarifying the specific function, retrieving function-related design documents, clarifying the differences between vehicle platforms, clarifying function-related components, clarifying function-related signals, evaluating signal correspondence and differences, evaluating component change items, and preliminary assessment of architectural feasibility. The steps for defining the functional baseline vehicle and baseline are as follows: Defining the Base Vehicle and Baseline: This step identifies the Base vehicle and corresponding baseline version where the function resides; Defining the Target Vehicle and Baseline: This step identifies the target vehicle and corresponding baseline version that need to be reverse-sliced ​​or reused; Defining the Specific Function: This step identifies the specific function to be evaluated; Retrieving Function-Related Design Documents: This step retrieves CTS, SSTS, and other design documents related to the function from historical design documents; Defining Platform Differences: This step identifies platform differences between the Base vehicle and the target vehicle; Defining Function-Related Associates: This step identifies associates involved in function implementation; Defining Function-Related Signals: This step identifies signals involved in function implementation; Evaluating Signal Correspondence and Differences: This step compares signal differences between the Base vehicle and the target vehicle; Evaluating Associate Changes: This step evaluates the change requirements for associates on the target vehicle; Preliminary Architecture Feasibility Assessment: This step synthesizes the above analysis results to provide a preliminary assessment conclusion on architecture feasibility.

[0083] The dependency building module 706 is configured to label the upstream step items that each step item depends on, and to construct a dependency graph based on the dependencies between step items. The dependency building module 706 analyzes the source of input information for each step item; if the input of one step item depends on the output of another step item, a directed dependency is established between them. The dependency graph represents the information flow and upstream / downstream dependencies between step items.

[0084] The process generation module 708 is configured to sort the dependency graph to generate a serial execution flow. The module 708 performs cycle detection on the dependency graph; if no cycle exists, it generates a serial execution order based on the sorted dependency nodes; if a cycle exists, it breaks the cycle before generating a serial execution order. The sorting process transforms the dependency graph into a serial link with a defined execution order, ensuring that each step is executed in the correct logical order.

[0085] The step execution module 710 is configured to execute each step item sequentially according to a serial execution flow. The implementation path is selected based on the task type of each step item, and includes one or more of the following: manual input, retrieval-enhanced generation link, rule-based methods, and external processes. For step items requiring explicit input, the step execution module 710 obtains information through manual input; for step items requiring semantic retrieval and information extraction based on historical design documents, it implements the process through a retrieval-enhanced generation link or a large language model link; for step items requiring comparison or difference analysis, it implements the process through rule-based methods; and for step items requiring external confirmation, it implements the process through an external process.

[0086] The context management module 712 is configured to write the execution results of each step to the context cache and pass the information in the context cache to subsequent step items as input. The context management module 712 maintains the read and write operations of the context cache, ensuring that the output of the previous step can be passed as context information for the downstream step. The information stored in the context cache includes at least one of the following: basic task information, manual input information, retrieval results generated by retrieval enhancement, rule execution results, large language model generation results, exception prompts, referenced documents, and external countersigning status.

[0087] In some implementations, the autonomous driving system architecture design and management system 700 is deployed and runs as a local tool, a server tool, or a plugin for a research and development management platform. The modules of the autonomous driving system architecture design and management system 700 communicate with each other through data interfaces. The output of the problem acquisition module 702 is passed to the step splitting module 704, the output of the step splitting module 704 is passed to the dependency building module 706, the output of the dependency building module 706 is passed to the process generation module 708, and the output of the process generation module 708 is passed to the step execution module 710. During execution, the step execution module 710 interacts with the context management module 712 to read and write to the context cache.

[0088] The aforementioned autonomous driving system architecture design and management system 700 abstracts the architecture design paradigm into standardized steps and automatically generates a serial execution flow based on the dependencies between steps. Combined with manual input, enhanced generation links, rule-based methods, and the unified orchestration capabilities of external processes, as well as a context caching mechanism, it enables the effective utilization of unstructured historical design data, the automated decomposition of complex design tasks, and the rule-based guarantee of accuracy tasks.

[0089] This invention also includes a readable storage medium.

[0090] A computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in any of the above embodiments. The computer-readable storage medium may include any entity or device capable of carrying a computer program, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), and a software distribution medium, etc. The computer program includes computer program code. The computer program code may be in the form of source code, object code, an executable file, or some intermediate form, etc. The computer-readable storage medium may include any entity or device capable of carrying computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), and a software distribution medium, etc.

[0091] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0092] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a system including a processing module or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0093] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for designing and managing the architecture of an autonomous driving system, characterized in that, include: Identify pending architecture design management issues and generate or select a working paradigm template based on those issues. The work paradigm template is broken down into multiple steps, each of which includes input information, implementation method, and output result; For each step item, label the upstream step items it depends on, and construct a dependency graph based on the dependencies between step items; The dependency graph is sorted to generate a serial execution flow; Each step is executed sequentially according to the serial execution flow, wherein the corresponding implementation path is selected according to the task type of each step, and the implementation path includes one or more of manual input, retrieval enhancement generation link, rule method and external process; as well as The execution results of each step are written to the context cache, and the information in the context cache is passed to the subsequent step as input.

2. The method according to claim 1, characterized in that, The step of sorting the dependency graph to generate a serial execution flow includes: Perform cycle detection on the dependency graph; If no cycle exists, a serial execution order is generated based on the sorting of dependent nodes; and If a loop exists, the loop is broken to generate a serial execution order.

3. The method according to claim 2, characterized in that, The damage treatment includes at least one of the following methods: Rewrite the loop process into a finite number of sequential steps; and Multiple cyclic steps are aggregated into a single composite step.

4. The method according to any one of claims 1 to 3, characterized in that, The step of selecting the corresponding implementation path based on the task type of each step includes: For steps that require explicit input, information should be obtained through manual input. For steps that require semantic retrieval and information extraction based on historical design documents, this can be achieved through retrieval enhancement generation links or large language model links. For steps requiring comparison or difference analysis, a rule-based approach is used; and For steps that require external confirmation, this is achieved through an external process.

5. The method according to claim 4, characterized in that, The method of enhancing the generation link or the large language model link through retrieval includes: Generate search criteria based on the input of the current step item and the information in the context cache; Retrieve relevant document blocks from historical design documents; and The search criteria, the relevant document blocks, and the preset prompt templates are input into the large language model to generate structured output results.

6. The method according to claim 4, characterized in that, The implementation via rule-based methods includes: Read the output of the upstream step item from the context cache; Retrieve the data to be compared from an internal database or interface file; and Field-level comparisons are performed using rule scripts or difference comparison tools to generate difference analysis results.

7. The method according to any one of claims 1 to 3, characterized in that, The information stored in the context cache includes at least one of the following: Basic task information, manually input information, enhanced search results, rule execution results, large language model generated results, exception prompts, referenced documents, and external countersigning status.

8. The method according to any one of claims 1 to 3, characterized in that, The architecture design management issues include at least one of the following types: Functional reverse switching feasibility assessment, new functional architecture scheme evaluation, cross-vehicle function reuse analysis, platform interface difference analysis, and functional link integrity check.

9. The method according to any one of claims 1 to 3, characterized in that, Also includes: After all step items have been executed, the output results of each step item are read from the context cache; as well as An architecture design management evaluation report is generated according to a preset report template, wherein the conclusions in the evaluation report are linked to the corresponding step items and upstream basis.

10. The method according to any one of claims 1 to 3, characterized in that, The step item includes at least one of the following: Define the functional baseline vehicle and baseline, define the target vehicle and baseline, define the specific functions, retrieve the relevant design documents, define the differences between vehicle platforms, define the functional related components, define the functional related signals, evaluate the signal correspondence and differences, evaluate the changes to the related components and conduct a preliminary assessment of the architectural feasibility.

11. An autonomous driving system architecture design and management system, characterized in that, include: The problem acquisition module is used to acquire architecture design management problems to be processed, and generate or select a working paradigm template based on the architecture design management problems. The step splitting module is used to split the work paradigm template into multiple step items, wherein each step item includes input information, implementation method and output result; The dependency building module is used to mark the upstream step items that each step item depends on, and to build a dependency graph based on the dependency relationships between step items; The process generation module is used to sort the dependency graph and generate a serial execution process; The step execution module is used to execute each step item one by one according to the serial execution flow, wherein the corresponding implementation path is selected according to the task type of each step item, and the implementation path includes one or more of manual input, retrieval enhancement generation link, rule method and external process; as well as The context management module is used to write the execution results of each step item into the context cache and pass the information in the context cache to subsequent step items as input.

12. A readable storage medium, characterized in that, The readable storage medium stores computer instructions that, when executed by a processor, implement the method as described in any one of claims 1-10.

Images