Automobile hybrid gateway AI automatic test system and method

Abstract

The invention provides an automobile hybrid gateway AI automatic test system and method, and belongs to the technical field of vehicle-mounted electronic communication. The system is composed of a protocol analysis module and an AI automatic test module. The protocol analysis module is based on hardware supporting a multi-protocol interface, and dynamic loading, signal cross-protocol conversion and consistency verification of CAN FD, LIN and Ethernet messages are achieved. The AI automatic test module is a core, and a data layer of the AI automatic test module constructs an automobile gateway test knowledge graph fusing four entities of a bus protocol, a function module, a fault mode and a test index; the AI model layer automatically analyzes the demand document and generates a high-coverage test case; the test execution layer drives the protocol analysis module to complete an automatic test; and the intelligent analysis layer outputs a test report. Through deep combination of the knowledge graph and the AI large model, the problems of incomplete protocol coverage, low regression test efficiency and insufficient edge scene case coverage in the prior art are solved, and the intellectualization of hybrid gateway test is realized.

Description

Technical Field

[0001] This invention relates to the field of vehicle electronic communication technology, specifically to an automated testing system and method for automotive hybrid gateway AI. Background Technology

[0002] With the rapid advancement of automotive intelligence and connectivity, modern in-vehicle network architecture has evolved from traditional distributed architectures based on CAN and LIN buses to domain-centralized or centrally computed architectures integrating high-speed in-vehicle Ethernet. Against this backdrop, automotive hybrid gateways, acting as data hubs connecting different network domains (such as powertrain, body, infotainment, and autonomous driving domains), are becoming increasingly complex. They not only need to implement cross-network segment data routing and signal-level conversion between multiple protocols such as CAN, LIN, and Ethernet, but also support advanced functions such as network management, security encryption, and OTA upgrades. This presents unprecedented challenges to gateway testing: the testing scope must cover multiple protocols, the testing scenarios must encompass a massive number of normal and abnormal situations, and the testing efficiency must match the short software iteration cycle.

[0003] However, existing gateway testing technologies and systems have significant shortcomings and cannot meet the above requirements, mainly in the following three aspects:

[0004] First, protocol coverage is incomplete. Existing test systems are mostly designed for traditional CAN and LIN buses, lacking in-depth support for automotive Ethernet protocols (such as DoIP and SOME / IP). This makes it impossible to effectively verify new application scenarios involving Ethernet communication, such as high-speed data interaction between smart cockpits and domain controllers, and Ethernet-based diagnostic communication (DoIP), resulting in blind spots in testing.

[0005] Second, regression testing is inefficient. In agile development models, gateway software iteration cycles have been shortened to 2-4 weeks. However, traditional automated testing methods require test engineers to manually re-adapt over 70% of test cases after each iteration, resulting in regression testing cycles of 3-5 days. This severely slows down product development and cannot meet the demands of rapid iteration.

[0006] Third, test case coverage is insufficient. Traditional testing heavily relies on the manual experience of test engineers to write test cases. This method is highly subjective and difficult to exhaustively cover. As a result, it can only cover about 80% of routine functional scenarios, while coverage of edge-case scenarios and fault tolerance tests, such as "multi-bus data concurrency conflicts," "communication protocol timeout and retransmission mechanisms," and "packet loss under high load," is severely lacking. This makes it difficult to detect some potential defects that only trigger under extreme conditions in a timely manner, posing hidden dangers to the safety of the entire vehicle.

[0007] Therefore, there is an urgent need in this field for a new testing solution that can achieve intelligent generation of test cases, highly automated testing process, and self-optimization capabilities. Summary of the Invention

[0008] In view of this, the present invention aims to propose an AI-automated testing method and system for automotive hybrid gateways to solve the problems existing in the prior art. It deeply integrates artificial intelligence technology with domain knowledge graphs to build an intelligent testing system that can understand requirements, autonomously generate test cases, automatically execute tests, and continuously learn and optimize, thereby systematically solving the problems of protocol coverage, testing efficiency, and test coverage.

[0009] To achieve the above objectives, the technical solution of the present invention is implemented as follows:

[0010] An AI automated testing system for automotive hybrid gateways, characterized in that it includes a protocol parsing module and an AI automated testing module;

[0011] The protocol parsing and conversion module supports dynamic loading of CAN FD, LIN, and Ethernet protocols to achieve signal-level cross-protocol conversion;

[0012] The AI ​​automated testing module is connected to the protocol parsing module to intelligently drive the entire testing process.

[0013] Furthermore, the AI ​​automated testing module includes:

[0014] The data layer is used to build and store the automotive gateway test knowledge graph and test database;

[0015] The AI ​​model layer integrates a requirement analysis AI model, which is used to automatically parse the gateway software requirement document based on the knowledge graph, extract test points, and generate structured test case files.

[0016] The test execution layer is used to import and automatically execute the test cases, and control the protocol parsing module to complete the test stimulus and response verification.

[0017] The intelligent analysis layer is used to collect test data and generate automated test reports that include test case execution results, defect statistics, and performance metrics.

[0018] Furthermore, the protocol parsing and conversion mode is configured with a hardware main control chip that supports multiple CAN, CAN-FD, LIN, and Gigabit Ethernet interfaces, and implements cross-protocol conversion, routing forwarding, and consistency verification of test messages according to the routing configuration table.

[0019] Furthermore, the construction process of the automotive gateway test knowledge graph includes: multi-source data preprocessing and cleaning of gateway software requirement documents, design drawings, and historical test data; entity recognition based on a BERT model fine-tuned by the gateway domain corpus, with an accuracy rate of no less than 92%; relation extraction by combining predefined rule templates and relation classification models; filling attribute information into entities; and finally storing the structured data in the graph database.

[0020] Furthermore, the relation extraction process includes:

[0021] For explicit relationships, templates are extracted based on domain syntax rules. Template types include function-protocol dependency, use case-function coverage, and defect-module association.

[0022] For fuzzy relationships, a sentence pair classification model is used to process them. After generating entity pairs, they are input into the fine-tuned BERT classification model, and the relationships with a probability of not less than 0.85 are taken as the extraction results.

[0023] When there is a conflict between the results extracted by the rule engine and the model, manual review and historical data verification shall prevail.

[0024] Furthermore, the automotive gateway test knowledge graph has an incremental update mechanism. It monitors changes in data sources through timed scanning and event triggering, and performs conflict detection and incremental updates on the graph content according to preset priority rules and manual review rules. The priority rules are: latest requirement documents > latest design drawings > latest test data > historical data.

[0025] Furthermore, in the diagnostic routing test scenario, the protocol parsing module can encapsulate the OBD diagnostic request into an Ethernet frame using DoIP, route it to the gateway under test, and after the gateway parses it, convert it into a CAN UDS command and forward it to the designated ECU node. The verification module then confirms the correctness and timing of the routing.

[0026] Accordingly, the present invention also provides an automated testing method for automotive hybrid gateway AI based on the above system, comprising the following steps:

[0027] S1: Construct and initialize the automotive gateway test knowledge graph, and establish an incremental update mechanism;

[0028] S2: When there are new software requirements, the requirements are analyzed through the AI ​​model layer, and the knowledge graph is used to automatically reason and generate test cases that cover both regular functions and edge abnormal scenarios.

[0029] S3: Import and execute the test cases through the test execution layer to drive the protocol parsing module to complete the sending, receiving, conversion and consistency comparison of multi-protocol messages;

[0030] S4: The intelligent analysis layer analyzes the test data, generates a test report that meets functional safety standards, and feeds back the test results and defect information to the data layer to optimize the knowledge graph and AI model.

[0031] Furthermore, the specific steps for constructing the knowledge graph in step S1 include:

[0032] S11: Multi-source data preprocessing: Convert the format of the gateway software requirements document, remove irrelevant content, and standardize technical terms; extract module block diagrams and interface definitions from the design drawings using APIs or target detection models; clean and align historical test data;

[0033] S12: Entity Recognition: Using a BERT model finely tuned on a gateway domain corpus, four core entities are identified from the preprocessed text.

[0034] S13: Relationship Extraction: Combining rule templates with the BERT relationship classification model, extract relationships between entities and handle possible relationship conflicts;

[0035] S14: Attribute population: Extract detailed information from the source data to supplement attributes for the entity;

[0036] S15: Graph Storage: Store the "entity-relationship-attribute" triples into the graph database.

[0037] Furthermore, the specific process of generating test cases in step S2 is as follows: the requirement parsing AI model extracts the functional descriptions and performance indicators from the requirement document, and automatically derives a complete set of test scenarios, including normal function verification, performance stress testing, and protocol fault tolerance testing, by querying the associated fault modes, protocol constraints, and historical defect data in the knowledge graph.

[0038] Compared with existing technologies, the automotive hybrid gateway AI automated testing method and system described in this invention have the following advantages:

[0039] (1) More comprehensive protocol coverage: By supporting multiple protocol interfaces at the hardware level and dynamic protocol loading at the software level, it achieves comprehensive testing of CAN, LIN, Ethernet and their hybrid networking scenarios.

[0040] (2) Improve regression testing efficiency: AI automatically parses requirements and generates test cases, transforming 70% of the manual test case adaptation work in regression testing into automatic completion, shortening the regression testing cycle from several days to several hours.

[0041] (3) High test coverage: By leveraging the semantic reasoning capabilities of knowledge graphs, AI generates regular functional test cases and automatically derives test scenarios involving complex interactions, edge conditions, and abnormal failures. The test case coverage has increased from about 80% to over 95%, reducing the risk of missed detections.

[0042] (4) Possesses continuous evolution capability: The incremental update mechanism of the knowledge graph enables the system to learn from each test and continuously enrich and correct the domain knowledge model. Attached Figure Description

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

[0044] Figure 1 This is a schematic diagram of the hardware and data interaction of an automotive hybrid gateway AI automated testing system according to an embodiment of the present invention;

[0045] Figure 2 This is a flowchart of the AI ​​automated testing workflow according to an embodiment of the present invention;

[0046] Figure 3 This is a schematic diagram of the automated construction and incremental update process of a knowledge graph according to an embodiment of the present invention. Detailed Implementation

[0047] 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.

[0048] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0049] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0050] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0051] In the description of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "multiple" means two or more.

[0052] Before providing a detailed description of the solution in this application, the terms used in this application are explained as follows:

[0053] DOIP: DOIP stands for Diagnostics over Internet Protocol, which is a communication standard in the automotive electronics field used for efficient data transmission between vehicles and external diagnostic devices (such as diagnostic instruments and diagnostic software on computers). Simply put, DOIP is a "network communication rule" specifically designed for automotive diagnostic functions.

[0054] ETH AVB: ETH stands for Ethernet. In the automotive field, it specifically refers to automotive Ethernet, a high-speed network technology optimized for vehicle environments (such as electromagnetic compatibility, temperature, and cost). AVB stands for Audio Video Bridging. It is a set of protocols based on Ethernet, specifically designed to ensure real-time, synchronous, low-latency, and uninterrupted transmission of audio and video data over the network. The overall definition of ETH AVB is: a technical standard operating on automotive Ethernet that manages and schedules network traffic to provide deterministic low-latency and high-reliability transmission guarantees for data streams such as audio and video that require high real-time performance.

[0055] SOME / IP: SOME / IP stands for Scalable service-oriented middleware over IP. It is an automotive communication middleware based on in-vehicle Ethernet. It adopts a service-oriented architecture to enable on-demand communication between ECUs. Through service discovery, remote procedure calls, and other mechanisms, it significantly improves network utilization efficiency and system flexibility, serving as a core support for the realization of intelligent vehicle functions.

[0056] CANFD: CAN FD is an upgraded version of the traditional CAN (Controller Area Network) protocol, short for Flexible Data Rate CAN. While retaining the classic CAN two-wire serial communication mechanism and compatibility, it significantly improves bandwidth by increasing the single-frame data length (from 8 bytes to 64 bytes) and variable data transmission rates (arbitration and data segments can use different rates, with data segments reaching up to 5Mbps or more). This allows for efficient support of the ever-increasing data volume communication needs between modern automotive ECUs.

[0057] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0058] The purpose of this invention is to provide an AI-automated testing system and method for automotive hybrid gateways to solve the problems existing in the prior art. It deeply integrates artificial intelligence technology with domain knowledge graphs to build an intelligent testing system that can understand requirements, autonomously generate test cases, automatically execute tests, and continuously learn and optimize, thereby systematically solving the problems of protocol coverage, testing efficiency, and test coverage.

[0059] To achieve the above objectives, the present invention provides the following solution:

[0060] As attached Figure 1 As shown, the testing system of the present invention mainly includes an automated testing module 100, a protocol conversion module 200, and a gateway under test 300 in terms of hardware.

[0061] The automated testing module 100 and the protocol conversion module 200 are connected via a gigabit Ethernet cable. The protocol conversion module 200 integrates support for multiple automotive protocols such as DoIP, ETH AVB, SOME / IP, and CANFD, and is connected to the corresponding port of the gateway under test 300 via appropriate physical cables (such as CAN bus or automotive Ethernet cable).

[0062] When the system is working, the data flow is as follows:

[0063] Test incentive distribution: The automated testing module 100 generates test case data from its internal test database and distributes it to the protocol conversion module 200.

[0064] Protocol encapsulation and transmission: The protocol conversion module 200 encapsulates the received test data according to the protocol specified in the test case (such as DoIP), generates the final routing message, and sends it to the gateway under test 300.

[0065] Message forwarding and return: The gateway under test 300 processes the message according to its internal routing table and forwards it to the target network (this process is monitored by the "test system"). At the same time, the gateway under test 300 will send a gateway message return acknowledgment signal back to the protocol conversion module 200.

[0066] Result Collection and Verification: The protocol conversion module 200 performs preliminary parsing of the received gateway response signals and monitored network packets, and sends the results back to the automated testing module 100. The automated testing module 100 compares the actual results with the expected results to complete the test verification.

[0067] like Figure 2 As shown, an automated testing method for AI in automotive hybrid gateways includes the following steps:

[0068] S1: Data Layer Import and Graph Update: The data layer continuously imports gateway software requirements documents, design drawings, and historical test data, and drives... Figure 3 The process shown builds or updates the gateway testing domain knowledge graph.

[0069] like Figure 3 The process shown includes the following steps:

[0070] S11: Data Acquisition: The system automatically collects data from multiple sources, including but not limited to: gateway software requirements documents (Word / PDF format), design drawings (Visio / CAD format), and historical test cases and results data;

[0071] S12: Data Preprocessing: Cleaning and formatting the collected unstructured or semi-structured data. For example, using Python's PyPDF2 library to parse text in PDF documents, and using the win32com.client library to read component and connection information from Visio drawings;

[0072] S13: Entity Recognition: Named Entity Recognition (NER) is performed using a BERT model finely tuned for text in the automotive electronics field, which automatically identifies “functional entities” (such as “Ethernet to CAN message forwarding”), “protocol entities” (such as “CANFD”), “fault mode entities” (such as “bus timeout”) from the text.

[0073] S14: Relationship Extraction: Similarly, using AI models or rule-based methods, extract the relationships between entities from the text, such as "<Ethernet to CAN message forwarding function, dependent on CAN FD protocol>" and "<Function A, performance indicators, latency ≤10ms>".

[0074] S15: Attribute population: Add attributes to the identified entities, such as adding attributes like "maximum rate 5Mbps" to the "CAN FD protocol" entity;

[0075] S16: Graph storage: Store the entities, relations and attributes obtained in the above steps in the form of triples in a graph database (such as Neo4j) to form a structured knowledge graph;

[0076] S17: Quality Verification and Incremental Update: The system performs quality verification on the constructed knowledge graph. When new data (such as a new version of the requirements document) is input or new data is generated after testing, the system will initiate the incremental update process, performing steps S12 to S16 only on the new data, thereby efficiently updating the knowledge graph and ensuring its timeliness.

[0077] S2: AI Model for Analyzing Requirements and Generating Test Points: The requirement analysis AI model (based on a fine-tuned BERT model) reads the latest requirement documents and uses knowledge graphs as background knowledge for deep understanding, automatically extracting specific test points (e.g., accurately extracting "Ethernet to CAN message forwarding function" and its performance requirements from the description), and generating a structured test requirement database.

[0078] S3: Test Execution Layer Performs Tests: The test execution layer (usually host computer software) identifies test cases to be executed from the database according to the test plan, automatically generates executable test scripts, and starts the multi-protocol adaptation unit (i.e., protocol conversion module 200). This unit controls the hardware to send test messages to the gateway under test and monitors and collects the response results;

[0079] S4: Intelligent Analysis Layer Report Generation: The intelligent analysis layer performs in-depth analysis of test results, automatically generating a visualized test coverage heatmap and a detailed "Test Report". Simultaneously, it automatically synchronizes discovered defect information to a defect management system (such as Jira).

[0080] S5: Feedback and Knowledge Evolution: All data generated in this test (including test cases, pass / fail results, and specific defect information) is fed back to the AI ​​model layer and data layer to update the knowledge graph (e.g., marking a common failure scenario as a new "failure mode" entity). This step makes the knowledge graph richer and more accurate, thereby directly improving the accuracy and intelligence of the next round of testing, enabling the system to learn and continuously optimize itself.

[0081] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0082] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0083] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0084] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0085] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0086] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0087] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. An automated testing system for automotive hybrid gateway AI, characterized in that, Includes a protocol parsing module and an AI automated testing module; The protocol parsing and conversion module supports dynamic loading of CAN FD, LIN, and Ethernet protocols to achieve signal-level cross-protocol conversion; The AI ​​automated testing module is connected to the protocol parsing module to intelligently drive the entire testing process.

2. The automotive hybrid gateway AI automated testing system according to claim 1, characterized in that, The AI ​​automated testing module includes: The data layer is used to build and store the automotive gateway test knowledge graph and test database; The AI ​​model layer integrates a requirement analysis AI model, which is used to automatically parse the gateway software requirement document based on the knowledge graph, extract test points, and generate structured test case files. The test execution layer is used to import and automatically execute the test cases, and control the protocol parsing module to complete the test stimulus and response verification. The intelligent analysis layer is used to collect test data and generate automated test reports that include test case execution results, defect statistics, and performance metrics.

3. The automotive hybrid gateway AI automated testing system according to claim 1, characterized in that, The protocol parsing and conversion mode is equipped with a hardware main control chip that supports multiple CAN, CAN-FD, LIN, and Gigabit Ethernet interfaces, and implements cross-protocol conversion, routing forwarding, and consistency verification of test messages according to the routing configuration table.

4. The automotive hybrid gateway AI automated testing system according to claim 2, characterized in that, The construction process of the automotive gateway test knowledge graph includes: multi-source data preprocessing and cleaning of gateway software requirements documents, design drawings, and historical test data; entity recognition based on a BERT model fine-tuned by gateway domain corpus, with an accuracy rate of no less than 92%; relation extraction by combining predefined rule templates and relation classification models; filling attribute information into entities; and finally storing structured data in the graph database.

5. The automotive hybrid gateway AI automated testing system according to claim 4, characterized in that, The relation extraction process includes: For explicit relationships, templates are extracted based on domain syntax rules. Template types include function-protocol dependency, use case-function coverage, and defect-module association. For fuzzy relationships, a sentence pair classification model is used to process them. After generating entity pairs, they are input into the fine-tuned BERT classification model, and the relationships with a probability of not less than 0.85 are taken as the extraction results. When there is a conflict between the results extracted by the rule engine and the model, manual review and historical data verification shall prevail.

6. The automotive hybrid gateway AI automated testing system according to claim 1, characterized in that, The automotive gateway test knowledge graph has an incremental update mechanism. It monitors changes in data sources through timed scanning and event triggering, and performs conflict detection and incremental updates on the graph content according to preset priority rules and manual review rules. The priority rules are: latest requirement documents > latest design drawings > latest test data > historical data.

7. The automotive hybrid gateway AI automated testing system according to claim 3, characterized in that, In the diagnostic routing test scenario, the protocol parsing module can encapsulate the OBD diagnostic request into an Ethernet frame using DoIP, route it to the gateway under test, and after the gateway parses it, convert it into a CAN UDS command and forward it to the designated ECU node. The verification module then confirms the correctness and timing of the routing.

8. A method for automated testing of AI in automotive hybrid gateways, applied to the automated testing system for AI in automotive hybrid gateways as described in any one of claims 1 to 7, characterized in that, Includes the following steps: S1: Construct and initialize the automotive gateway test knowledge graph, and establish an incremental update mechanism; S2: When there are new software requirements, the requirements are analyzed through the AI ​​model layer, and the knowledge graph is used to automatically reason and generate test cases that cover both regular functions and edge abnormal scenarios. S3: Import and execute the test cases through the test execution layer to drive the protocol parsing module to complete the sending, receiving, conversion and consistency comparison of multi-protocol messages; S4: The intelligent analysis layer analyzes the test data, generates a test report that meets functional safety standards, and feeds back the test results and defect information to the data layer to optimize the knowledge graph and AI model.

9. The automotive hybrid gateway AI automated testing method according to claim 8, characterized in that, The specific steps for constructing the knowledge graph in step S1 include: S11: Multi-source data preprocessing: Convert the format of the gateway software requirements document, remove irrelevant content, and standardize technical terms; extract module block diagrams and interface definitions from the design drawings using APIs or target detection models; clean and align historical test data; S12: Entity Recognition: Using a BERT model finely tuned on a gateway domain corpus, four core entities are identified from the preprocessed text. S13: Relationship Extraction: Combining rule templates with the BERT relationship classification model, extract relationships between entities and handle possible relationship conflicts; S14: Attribute population: Extract detailed information from the source data to supplement attributes for the entity; S15: Graph Storage: Store the "entity-relationship-attribute" triples into the graph database.

10. The automotive hybrid gateway AI automated testing method according to claim 8, characterized in that, The specific process of generating test cases in step S2 is as follows: The requirement parsing AI model extracts the functional descriptions and performance indicators from the requirement document, and automatically derives a complete set of test scenarios, including normal function verification, performance stress testing, and protocol fault tolerance testing, by querying the associated fault modes, protocol constraints, and historical defect data in the knowledge graph.

Images