A simulation automation test system and method for vehicle-mounted Ethernet based on SOA architecture

Abstract

The application discloses a kind of based on SOA architecture's vehicle-mounted Ethernet simulation automation test system and method, it is related to Ethernet simulation test technical field, on the computer of Ubuntu operating system deployment Python test framework, through vehicle-mounted Ethernet converter, computer is connected with the equipment under test, and another computer is realized remote development environment through network connection, and the test running environment for vehicle-mounted Ethernet communication is established.The application realizes vehicle-mounted Ethernet simulation test by pure software mode, reduces the dependence on hardware and commercial tool, reduces cost and improves deployment efficiency, while supporting multi-node parallel simulation to enhance complex scene adaptation capability;Through layered decoupling architecture and standardized interface design, improve test development flexibility and reusability, and combined with automation execution and result management mechanism, improve overall test efficiency and result analysis capability.

Description

Technical Field

[0001] This application relates to the field of Ethernet simulation testing technology, specifically to an automated testing system and method for in-vehicle Ethernet simulation based on SOA architecture. Background Technology

[0002] As automotive electronic and electrical architectures gradually evolve towards Service-Oriented Architecture (SOA), automotive Ethernet has become the core network foundation for high-speed communication and service interaction between various domain controllers in a vehicle. Among these, the SOME / IP (Scalable Service-Oriented Middleware over IP) protocol, as a key communication protocol suitable for automotive SOA architecture, is widely used in service publishing, subscription, and remote invocation between multiple functional domains such as cockpit domain controllers, body domain controllers, intelligent driving domain controllers, and in-vehicle TBOX. Against this backdrop, to ensure the correctness and stability of service interaction functions based on the SOME / IP protocol between various controllers, the industry typically adopts automotive Ethernet simulation testing solutions based on commercial testing tools. For example, testing platforms represented by Vector's CANoe tool, by deploying dedicated Ethernet interface cards (such as the VN5650), combined with the tool's internal network modeling capabilities and CAPL scripting language, can achieve the sending, receiving, parsing, and business logic verification of SOME / IP messages, and construct simulated ECU nodes by loading ARXML service description files, thereby completing the functional testing and verification process of the automotive Ethernet communication system.

[0003] Existing commercially available automotive Ethernet testing solutions still have many limitations in practical applications: First, these solutions heavily rely on dedicated hardware and commercial software licenses, resulting in high overall construction costs, typically reaching hundreds of thousands of yuan per system, making it difficult to meet the needs of large-scale testing deployments and cost-sensitive R&D scenarios. Second, their testing capabilities are limited by the number and performance of hardware interface cards, resulting in a limited number of ECU nodes that can be simulated simultaneously, making it difficult to support complex interaction scenarios between multi-domain controllers and large-scale concurrent testing requirements. Third, existing solutions mainly rely on dedicated scripting languages ​​such as CAPL for test development, which suffers from high learning costs, low development efficiency, and a closed ecosystem, failing to fully utilize the advantages of general-purpose programming languages ​​such as Python in automated testing, data processing, and third-party library support. Furthermore, in terms of simulating complex network environments, the ability to flexibly construct abnormal scenarios such as network latency, packet loss rate, response time fluctuations, and multi-task concurrency is insufficient, making it difficult to meet the high flexibility and high automation testing requirements of cross-domain service interactions under the automotive SOA architecture.

[0004] Therefore, there is an urgent need for a low-cost, highly scalable automotive Ethernet testing solution with strong simulation and automation capabilities to overcome the above-mentioned shortcomings.

[0005] The information disclosed in the background section is only intended to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] The purpose of this application is to provide an automated testing system and method for vehicle Ethernet simulation based on SOA architecture, in order to solve the problems mentioned in the background art.

[0007] To achieve the above objectives, this application provides the following technical solution: an automated testing method for in-vehicle Ethernet simulation based on SOA architecture, comprising the following steps: Deploy a Python testing framework on a computer running the Ubuntu operating system, connect the computer to the device under test via an in-vehicle Ethernet converter, and connect to another computer via a network to create a remote development environment, thereby establishing a test and operation environment for in-vehicle Ethernet communication. Based on the test environment, the network parameters and service information of multiple simulated electronic control unit nodes are defined by reading JSON or YAML configuration files. The network parameters include virtual LAN identifier, IP address and port number. The network isolation and communication relationship between each simulated electronic control unit node are achieved through virtual network card configuration. Based on the network parameters and service information of multiple simulated electronic control unit nodes, test cases are written by calling the pre-encapsulated interface application programming interface. The test cases include the sending of service request instructions and the acquisition of response data, and are used to describe the interaction logic of in-vehicle Ethernet services. The test case execution process is initiated. Based on the network parameters and service information of multiple simulated electronic control unit nodes, the service publication and subscription of SOME / IP and SOME / IP-SD protocols are completed. Service request message sending, response data reception and parsing are performed, and the test results are determined based on the parsing results. Concurrent execution and abnormal scenario injection are also supported. After the test cases are executed, a visual test report is generated based on the test results. The test report includes the test case execution status, pass rate, request and response data records, and error location information.

[0008] Preferably, the simulated electronic control unit nodes are isolated and constructed through joint configuration of the operating system network namespace and virtual LAN tags. Each node is bound to an independent network interface and a unique IP resource. At the same time, cross-domain communication paths are set through routing rules, thereby realizing a network topology structure in which logical independence and directional communication coexist between multi-functional domain electronic control units, and supporting the stable maintenance of communication links in a multi-node parallel operation environment.

[0009] Preferably, the interface application programming interface includes a service request construction interface, a response data parsing interface, and an event subscription interface. Each interface describes the service identifier, method identifier, and payload content through a unified parameter structure, and completes the assembly and parsing of SOME / IP message format through a protocol encapsulation mechanism, thereby achieving decoupling control between business logic and underlying communication processing logic.

[0010] Preferably, the SOME / IP and SOME / IP-SD protocol processing includes multiple communication stages such as service broadcasting, service lookup, subscription request sending, and subscription confirmation response. Each stage is managed through a message state control mechanism, and the communication process is associated and controlled through session identifiers and message identifiers, thereby realizing the ability to discover services across multiple nodes and dynamically bind services.

[0011] Preferably, the abnormal scenario injection is accomplished through parameterized configuration, including network latency injection, packet drop probability setting, and response time fluctuation control. The network latency is achieved through a sending queue delay mechanism, packet drop is controlled through a random packet loss algorithm, and response time fluctuation is achieved through dynamic processing time adjustment, thereby constructing a multi-dimensional communication anomaly simulation environment.

[0012] Preferably, concurrent execution is achieved through a multi-threaded or asynchronous event scheduling mechanism. Each test task corresponds to an independent execution unit. Computing resources are allocated through a task scheduling strategy, and multiple service call processes are coordinated through an event-driven approach, thereby enabling parallel communication verification between multiple electronic control unit nodes and high-load scenario testing capabilities.

[0013] Preferably, the test report generation process includes three stages: communication log collection, structured storage of test results, and visualization data conversion. The communication logs include request message content, response message content, and timestamp information. The structured storage organizes the test data through a unified data model, and the visualization conversion graphically displays the test pass rate and communication path information.

[0014] Preferably, the configuration file describes the node attributes and service relationships of the simulated electronic control unit in JSON or YAML format. The configuration content includes node identifiers, service identifiers, and subscription relationships. It is dynamically loaded into the test environment through a configuration parsing mechanism, thereby enabling rapid switching of test scenarios and reuse of multiple business scenarios.

[0015] Preferably, the test execution process introduces a containerized deployment mechanism, which encapsulates the Python test framework, protocol processing components and runtime dependencies into independent container images, and allocates computing resources through container orchestration. Each container instance corresponds to an independent simulation execution unit, supporting parallel operation of multiple instances and scheduling across computing nodes. At the same time, the loading of test task parameters and centralized management of execution results are achieved through a shared configuration directory and log output path, thereby realizing the ability to quickly deploy the test environment, migrate across platforms, and perform large-scale automated test execution.

[0016] An automated testing system for vehicle Ethernet simulation based on SOA architecture includes a test layer, an interface layer, a protocol and electronic control unit simulation layer, and a test object layer. The testing layer is used to implement test case construction, business logic orchestration, test result generation, and test data configuration management. The testing layer includes a test case module, a business logic module, a report generation module, and a configuration and data-driven module. The test case module is used to build test cases for multiple business scenarios, the business logic module is used to encapsulate the service call logic of the vehicle function domain, the report generation module is used to generate visual test reports, and the configuration and data-driven module is used to load test parameters and drive test data execution through configuration files. The interface layer is used to encapsulate the in-vehicle Ethernet service call interface. The interface layer includes the SOME / IP application interface module, which provides standardized interface application programming interfaces, including service request call interface, response acquisition interface and event subscription interface, for the test layer to call. The protocol and electronic control unit (ECU) simulation layer is used to implement in-vehicle Ethernet protocol processing and multi-ECU simulation. This layer includes a SOME / IP protocol processing module, a SOME / IP-SD service discovery module, a TCP or UDP communication module, a data parsing module, and a network parameter configuration module. The SOME / IP protocol processing module is used to construct service message structures and control message types; the SOME / IP-SD service discovery module is used to implement service publishing, service search, and service subscription processing; the TCP or UDP communication module is used to implement Ethernet data link communication; the data parsing module is used to complete the serialization and deserialization processing of payload data; and the network parameter configuration module is used to configure the virtual LAN identifier, IP address, and port parameters of multiple electronic control unit nodes through virtual network cards, thereby realizing network isolation and communication relationship establishment between nodes. The object under test (AUT) layer is used to receive in-vehicle Ethernet service requests and execute corresponding business functions, while returning response data. The AUT layer includes multiple in-vehicle domain controller nodes and in-vehicle Ethernet conversion devices. Each in-vehicle domain controller node includes a cockpit domain controller, a body domain controller, a remote communication node, and other in-vehicle function nodes.

[0017] The technical effects and advantages provided by this application in the above technical solution are as follows: This application constructs a pure software-based automotive Ethernet simulation testing system, migrating protocol processing, node simulation, and test execution entirely to a general-purpose computing environment. This eliminates reliance on dedicated hardware interface devices and commercial testing tools, effectively controlling the cost of building the testing system. In practical applications, the entire testing process can be deployed using only ordinary computers and Ethernet conversion equipment, lowering the hardware investment threshold and reducing the testing environment setup cycle, enabling rapid reuse and expansion of testing resources. Furthermore, the unified software implementation method frees testing capabilities from the constraints of the number of physical interfaces, supporting the parallel operation of more simulation nodes. This significantly enhances the applicability of the testing system in complex automotive network scenarios and provides strong support for large-scale testing deployments.

[0018] This application effectively separates business logic development from underlying communication processing through a layered decoupled architecture and standardized interface design, making test case writing more flexible and scalable. In practical use, developers can quickly build test logic based on a general-purpose programming language and switch between multiple scenarios through configuration files, thereby reducing repetitive development work and improving script reusability. Simultaneously, leveraging multi-node simulation capabilities and protocol extension mechanisms, the system can adapt to different functional domain interaction requirements and various vehicle communication protocol environments, demonstrating stronger adaptability in complex business verification and cross-domain collaborative testing scenarios. Furthermore, through automated execution and result output mechanisms, the testing process forms a closed-loop management system, helping to improve overall development efficiency and enhance the traceability and analytical capabilities of test results. Attached Figure Description

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

[0020] Figure 1 This is the architecture diagram of the vehicle Ethernet simulation automated testing system based on SOA architecture in this application.

[0021] Figure 2This is a flowchart illustrating the test process structure of the SOA-based automotive Ethernet simulation automated test system of this application. Detailed Implementation

[0022] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that the description of this disclosure will be more complete and fully convey the concept of the exemplary embodiments to those skilled in the art.

[0023] like Figure 1 and Figure 2 As shown, this application provides an automated testing method for automotive Ethernet simulation based on SOA architecture, including the following steps: Deploy a Python testing framework on a computer running the Ubuntu operating system, connect the computer to the device under test via an in-vehicle Ethernet converter, and connect to another computer via a network to create a remote development environment, thereby establishing a test and operation environment for in-vehicle Ethernet communication. Based on the test environment, the network parameters and service information of multiple simulated electronic control unit nodes are defined by reading JSON or YAML configuration files. The network parameters include virtual LAN identifier, IP address and port number. The network isolation and communication relationship between each simulated electronic control unit node are achieved through virtual network card configuration. Based on the network parameters and service information of multiple simulated electronic control unit nodes, test cases are written by calling the pre-encapsulated interface application programming interface. The test cases include the sending of service request instructions and the acquisition of response data, and are used to describe the interaction logic of in-vehicle Ethernet services. The test case execution process is initiated. Based on the network parameters and service information of multiple simulated electronic control unit nodes, the service publication and subscription of SOME / IP and SOME / IP-SD protocols are completed. Service request message sending, response data reception and parsing are performed, and the test results are determined based on the parsing results. Concurrent execution and abnormal scenario injection are also supported. After the test cases are executed, a visual test report is generated based on the test results. The test report includes the test case execution status, pass rate, request and response data records, and error location information.

[0024] Implementation Method 1: In this implementation, a single general-purpose computer running the Ubuntu operating system is used as the core testing platform. A complete vehicle-mounted Ethernet simulation and automated testing environment is constructed using software. The computer is pre-installed with a Python runtime environment and deploys an automated testing framework developed using the Python language. A Socket communication mechanism is also introduced to support network data transmission and reception based on TCP or UDP protocols, thus providing the basic conditions for building a vehicle-mounted Ethernet communication link. At the network connection level, an vehicle-mounted Ethernet converter is used to adapt the Ethernet physical interface, converting the standard RJ45 interface to a vehicle-mounted Ethernet interface (e.g., 100Base-T1 or 1000Base-T1), enabling the computer to establish a physical connection with the device under test. Simultaneously, the computer is connected to another development terminal running a Windows operating system via a local area network, forming a test architecture that separates development and execution. Developers can use remote development tools on the Windows terminal to edit, debug, and control the test programs in the Ubuntu environment, improving development efficiency and reducing environment switching costs.

[0025] After completing the basic operating environment construction, simulated electronic control unit (ECU) nodes are defined using a configuration file-driven approach. Specifically, JSON or YAML format files are used to describe the network and service attributes of each node. Network attributes include parameters such as virtual LAN identifier, IP address, subnet mask, and communication port number. Service attributes include service identifier, instance identifier, method identifier, event identifier, and corresponding service publication or subscription relationships. During the initialization phase, the test framework parses the configuration file content and dynamically creates virtual network interface cards (NICs) within the operating system based on the parsing results. Each simulated ECU node corresponds to an independent virtual NIC, and each NIC is assigned a corresponding virtual LAN identifier and IP address, thus constructing a logically isolated multi-node network environment. For network isolation, data isolation between different nodes is achieved through the operating system's network namespace or virtual LAN tag mechanism. Simultaneously, routing configuration ensures communication reachability between specific nodes, simulating the communication topology between different domain controllers in a real vehicle network.

[0026] After establishing the simulated node network environment, the test case development phase begins. In this phase, test logic is written using the test organization mechanism provided by the Python testing framework, through calls to pre-encapsulated application programming interfaces (APIs). These APIs encapsulate the underlying communication protocols, providing a unified entry point to the upper layers, such as service request sending interfaces, response data retrieval interfaces, and event subscription interfaces, thus shielding the details of the underlying protocol processing. During test case writing, data packets conforming to the SOME / IP protocol format are constructed and sent by calling the service request sending interface. These packets include message header fields, service identifiers, method identifiers, session identifiers, and payload data. Simultaneously, data returned from the target node is received through the response data retrieval interface, and the returned data is parsed in a structured manner. Test cases can not only describe basic service call flows but also define complex business logic, such as multi-step interactions, conditional judgments, and state dependencies, thereby simulating real-world interactions between different functional domains in an in-vehicle system.

[0027] During the test execution phase, test cases are triggered to run through the test framework scheduling mechanism. During execution, the underlying protocol processing logic is responsible for completing the entire process of the SOME / IP protocol and the SOME / IP-SD service discovery protocol, including service publishing, service discovery, service subscription, and service unsubscription. During service publishing, simulated nodes broadcast service availability information to the network according to the service attributes defined in the configuration file; during service discovery, other nodes obtain target service information by sending service query messages; during service subscription, the subscribing node sends a subscription request to the service provider node, thereby establishing a service communication relationship. After completing the service discovery and subscription process, test cases drive the sending of service request messages. The underlying communication module sends the messages to the target node via the Socket interface. Upon receiving the messages, the target node executes the corresponding business logic and returns response data. After the response data is returned to the test platform via the network, the protocol parsing module decodes the data, including parsing message header fields, verifying return codes, and extracting payload data content. Based on preset assertion conditions, it determines whether the test results meet expectations.

[0028] During test execution, an abnormal scenario simulation mechanism can be introduced through parameter configuration to enhance test coverage. For example, network latency parameters can be set before sending packets to simulate link latency through a delayed sending mechanism; some data packets can be dropped with probability during communication to simulate packet loss scenarios; and response time can be dynamically adjusted to simulate response fluctuations caused by changes in system load. Furthermore, the concurrent execution capabilities supported by the test framework allow multiple test cases or multiple simulation node tasks to run simultaneously to verify the stability and reliability of system communication under high concurrency conditions. In terms of concurrent execution implementation, multi-threading or asynchronous event-driven mechanisms can be used to enable multiple service call tasks to run in parallel within the same time window, thus approximating the multi-task operating environment of a real in-vehicle system.

[0029] After test execution is complete, the test result processing and report generation phase begins. The testing framework generates structured data based on the execution results of each test case, including execution status, execution time, assertion results, and exception information. It also records complete communication log data, such as request message content, response message content, and communication timestamps. This data is then converted into a visual test report format, displaying the test results graphically. For example, it can show the test pass rate in a statistical chart, the request and response process in a timeline, and communication details in a log list, providing developers with intuitive test result analysis. During report generation, error messages can also be categorized and located, such as distinguishing between protocol parsing errors, communication timeout errors, and business logic errors, and providing corresponding error context information to quickly pinpoint the root cause of the problem.

[0030] The above implementation method enables the simulation and automated testing of multiple electronic control unit nodes in automotive Ethernet systems, without relying on dedicated hardware interface cards or commercial testing tools, using only a general-purpose computer and open-source software environment. This method significantly reduces the cost of building the testing system and enhances the flexibility and scalability of the testing environment. Furthermore, through configuration file-driven and interface encapsulation mechanisms, test case development becomes more efficient and maintainable. In addition, by supporting abnormal scenario simulation and concurrent execution capabilities, it can cover complex testing scenarios that are difficult to achieve with traditional testing methods, thereby improving the testing depth and verification capabilities of automotive SOA architecture systems.

[0031] Implementation Method Two: In this implementation method, the simulation is further extended to a multi-domain electronic control unit (ECU) collaborative interaction scenario. Multiple simulated ECU nodes with different business responsibilities are constructed to achieve high-fidelity simulation of cross-domain service communication behavior under the vehicle SOA architecture. The overall system still uses a computer running the Ubuntu operating system as the execution entity. Multiple logically independent but interactive network nodes are constructed on this computer through configuration drivers. Each node corresponds to a functional domain controller in the vehicle system, such as the cockpit domain controller, body domain controller, remote communication node, and auxiliary service node. Each node is described through a unified configuration file, which defines node identifiers, virtual LAN identifiers, IP addresses, port numbers, and service role information, including the identity of the service provider or service subscriber. Furthermore, the dependencies and calling relationships between nodes are defined, giving the entire simulated network a complete service topology.

[0032] During network environment construction, an independent network interface is created for each simulated electronic control unit node using the virtual network card mechanism provided by the operating system. Each network interface is bound to a unique IP address and port resources, and different network domains are distinguished by virtual LAN labels, thereby achieving a logically isolated multi-network environment on the same physical computer. In terms of network routing configuration, data communication paths across virtual LANs are established through static routing rules or bridging policies, enabling data exchange between different functional domains according to predefined rules. For example, the cockpit domain controller node can access services provided by the body domain controller node, while remote communication nodes establish indirect communication relationships with the body domain through intermediate network paths, thus constructing a domain-specific communication structure that closely resembles a real in-vehicle network. This network construction method not only ensures the logical independence between nodes but also simulates cross-domain communication behavior in actual in-vehicle networks.

[0033] In terms of service modeling, configuration files define the services provided by each node and their interface information, including service identifiers, instance identifiers, method lists, and event lists. Service call chains are also defined; for example, the cockpit domain controller node subscribes to the body control service of the body domain controller node, and the remote communication node subscribes to the remote control service of the cockpit domain controller node. This service modeling enables the entire simulation system to possess complete service publication and subscription relationships, providing a foundation for subsequent testing of complex business logic.

[0034] During the test case development phase, test logic is written by calling a unified, encapsulated API (Application Programming Interface). This API provides standardized service call entry points, such as service request sending interfaces, response retrieval interfaces, and event subscription interfaces. Developers can use these interfaces to describe specific business scenarios. For example, in the exterior light control test scenario, the cockpit domain controller node initiates an exterior light activation request, sending a SOME / IP message containing service and method identifiers through the service request interface. Upon receiving the request, the body domain controller node executes the corresponding control logic and returns the execution result. Subsequently, the cockpit domain controller node receives the response and verifies the result. Remote communication nodes can also be introduced into this process, such as a remote communication node sending remote control commands to the cockpit domain, which are then forwarded to the body domain, thus constructing a multi-level call chain to verify the integrity of cross-domain business logic.

[0035] During test execution, the underlying protocol processing logic provides full-process support for the SOME / IP and SOME / IP-SD protocols. In the service initialization phase, each simulation node automatically publishes its available service information according to its configuration file, declaring its service availability to other nodes via network broadcast. In the service lookup phase, service-subscribing nodes send service lookup messages to obtain target service information. In the service subscription phase, subscribing nodes send subscription requests to service-providing nodes, thereby establishing a service communication channel. After service communication is established, test cases drive each node to execute service calls according to preset business logic, completing the sending of request messages and the receiving of response data. During communication, the protocol parsing mechanism decodes the messages, including parsing message header information, verifying message types, extracting payload data, and verifying return codes, thereby achieving fine-grained control and verification of the communication process.

[0036] To verify system performance under multi-node parallel operation, a concurrent execution mechanism is introduced during test execution. Multiple test cases or service call tasks are run simultaneously within the same time window using multi-threading or asynchronous task scheduling, simulating the concurrent execution of multiple tasks in a real in-vehicle system. For example, multiple control commands, such as window control, lighting control, and air conditioning adjustment, can be triggered simultaneously, verifying whether there are conflicts, delays, or communication loss issues between nodes under concurrent conditions. Concurrent testing allows for the evaluation of the system's stability and reliability under high load conditions.

[0037] In terms of constructing abnormal scenarios, various network anomaly simulation capabilities are achieved through parameterized configuration. For network latency simulation, a delay parameter is introduced before sending packets to achieve a controllable delay in packet transmission time, thereby simulating network transmission delays. For packet loss simulation, a packet loss probability is set, and some packets are randomly dropped during communication to verify the system's fault tolerance capability under incomplete data conditions. For response fluctuation simulation, the response time instability caused by changes in system load is simulated by dynamically adjusting node processing time or introducing random response delays. Furthermore, abnormal packets or error return codes can be constructed to verify the protocol parsing logic's ability to handle abnormal data. Through these abnormal scenario injection mechanisms, complex network states that are difficult to achieve in traditional testing environments can be covered, thereby improving the test coverage.

[0038] During the test result processing phase, the system comprehensively records the communication behavior between each node, including request message content, response message content, communication timestamps, and execution paths. By structuring this data, multi-dimensional test result data can be generated, such as communication success rate for each node, average response time, and number of anomalies. In the report generation phase, the test results are presented in a visual format, including statistical charts, interactive flowcharts, and log lists, providing developers with intuitive analytical support. Furthermore, anomalies can be categorized, such as communication anomalies, protocol parsing anomalies, and business logic anomalies, and detailed error context information can be provided for quick problem localization.

[0039] This implementation method enables high-precision simulation of multiple electronic control unit nodes in a single computer environment and supports automated testing of complex business interaction scenarios. It not only overcomes the limitations of traditional hardware testing environments in terms of node quantity and scalability but also achieves flexible network construction and service configuration through software, allowing the testing environment to quickly adapt to different business needs. Furthermore, through concurrent execution and abnormal scenario simulation capabilities, it can comprehensively verify the performance and stability of in-vehicle SOA architecture systems under complex operating environments, thereby significantly improving testing efficiency and depth, and providing a reliable verification method for in-vehicle system function development.

[0040] Implementation Method 3: In this implementation method, building upon basic simulation and multi-domain interaction capabilities, an extended automated testing platform for large-scale engineering applications is further constructed. Through a systematic upgrade of the testing framework, the entire system evolves from a single testing tool into a platform-based automotive Ethernet testing infrastructure. The core of this implementation method lies in achieving protocol extension capabilities, standardized environment deployment capabilities, automated testing processes, and centralized resource management capabilities, thereby meeting the continuous testing needs of automotive SOA architectures in complex R&D environments.

[0041] At the protocol extension level, the original communication processing logic is modularly decomposed, encapsulating the encoding / decoding logic, communication flow control logic, and data processing logic of different protocols into independent components, and establishing a unified protocol adaptation interface within the testing framework. Each automotive Ethernet protocol can be connected to the testing platform by implementing a unified interface specification. For example, the DoIP protocol is used for diagnostic communication scenarios, the TSN protocol for time-sensitive network communication scenarios, and the MQTT protocol for vehicle-to-cloud communication scenarios. During operation, each protocol component receives test case requests through a unified calling interface and constructs corresponding data packets according to the protocol specifications to complete the sending, receiving, and parsing process. In this way, multiple protocol types can be supported simultaneously on the same testing platform, and the calling logic of different protocols can be freely combined in test cases to achieve cross-protocol interactive testing. For example, in complex scenarios, remote control commands can be issued first through the MQTT protocol, then local service calls can be completed through the SOME / IP protocol, and finally diagnostic information can be read through the DoIP protocol, thus forming a complete cross-protocol testing link.

[0042] In terms of test environment deployment, containerization technology is introduced to standardize and encapsulate the entire test system. By packaging the Python testing framework, protocol processing components, configuration files, and runtime dependencies into container images, a high degree of consistency in the test environment is achieved. During deployment, a complete test environment can be quickly obtained simply by starting a container instance on the target server or test host, without the need for complex software installation and environment configuration. During container operation, flexible modification of test configurations and unified storage of test results are achieved by mounting configuration file directories and log output directories. Furthermore, container orchestration technology allows multiple test instances to be started simultaneously on multiple servers, supporting the execution of large-scale parallel test tasks. In practical applications, container resources can be dynamically allocated according to testing needs, such as allocating more container instances for high-concurrency test tasks, thereby improving overall test throughput.

[0043] Regarding the test execution process, a continuous integration mechanism is introduced to achieve automatic triggering and execution of test tasks. During the development process, once developers complete code modifications and commit them to the version control system, the continuous integration tool automatically detects the code changes and triggers pre-defined test tasks. During execution, the test task pulls the latest code from the repository, automatically deploys the test system in a containerized environment, loads the corresponding test cases, and executes the test process. After test execution is complete, the system automatically generates a test report and feeds the results back to the developers or the quality management system, thus forming a complete automated testing loop. Different triggering strategies can also be configured during continuous integration, such as triggering by code commit, triggering by time period, or triggering by version release, to meet the testing needs of different development stages.

[0044] At the test management level, a web-based test management platform is built to achieve centralized management of test resources and test tasks. This platform provides a graphical interface to display test case lists, test task status, and test result statistics. Developers can use this platform to manage test cases, including creating, editing, categorizing, and versioning them. They can also configure test task parameters through the interface, such as selecting execution nodes, specifying test environments, and setting execution priorities. For task scheduling, the platform automatically allocates test tasks to different test nodes based on current resource usage, thus achieving load balancing. In multi-test bench scenarios, the platform can manage multiple physical or virtual test environments simultaneously and supports remote task deployment and execution status monitoring, thereby achieving distributed test execution capabilities.

[0045] Regarding the distributed execution mechanism, test execution units are deployed on different computing nodes, enabling multiple test tasks to run in parallel across these nodes. Each execution node communicates with the management platform via the network and periodically reports its resource status, such as CPU utilization, memory usage, and current task execution status. The management platform dynamically schedules tasks based on this information, allocating tasks to nodes with sufficient resources, thereby improving overall resource utilization efficiency. During execution, each node independently runs test cases and uploads the results to the management platform in real time for unified aggregation and analysis. In complex testing scenarios, a large test task can be broken down into multiple sub-tasks, executed on different nodes, thus shortening the overall testing time.

[0046] In terms of test data management, a unified data storage mechanism is established to centrally manage log data, communication data, and result data generated during the testing process. All communication records generated during test execution, including request messages, response messages, and timestamp information, can be stored in a database or log system and quickly retrieved through an indexing mechanism. During the test analysis phase, statistical analysis can be performed based on this data, such as calculating average response time, analyzing the frequency of anomalies, and identifying performance bottlenecks, thereby providing data support for system optimization.

[0047] In terms of scalability, this implementation supports the evolution of the testing platform to higher levels. For example, an artificial intelligence analysis module can be further introduced to intelligently analyze test results and detect anomalies, identifying potential problem patterns through machine learning methods; it can also be integrated with a cloud platform to deploy test tasks to the cloud environment, achieving elastic scalability; at the same time, it can support multi-user collaborative operation, implementing access control for different roles through a permission management mechanism, thereby meeting the needs of enterprise-level applications.

[0048] This implementation method upgrades existing testing methods from single testing tools to a comprehensive testing system with platform capabilities, achieving full automation and standardization from test environment deployment and test execution to test management. This method significantly improves testing efficiency and system scalability while reducing testing costs, and can adapt to the complex testing needs brought about by the continuous evolution of automotive SOA architectures, thus possessing greater engineering value and application prospects in the field of automotive Ethernet testing.

[0049] An automated testing system for vehicle Ethernet simulation based on SOA architecture includes a test layer, an interface layer, a protocol and electronic control unit simulation layer, and a test object layer. The testing layer is used to implement test case construction, business logic orchestration, test result generation, and test data configuration management. The testing layer includes a test case module, a business logic module, a report generation module, and a configuration and data-driven module. The test case module is used to build test cases for multiple business scenarios, the business logic module is used to encapsulate the service call logic of the vehicle function domain, the report generation module is used to generate visual test reports, and the configuration and data-driven module is used to load test parameters and drive test data execution through configuration files. The interface layer is used to encapsulate the in-vehicle Ethernet service call interface. The interface layer includes the SOME / IP application interface module, which provides standardized interface application programming interfaces, including service request call interface, response acquisition interface and event subscription interface, for the test layer to call. The protocol and electronic control unit (ECU) simulation layer is used to implement in-vehicle Ethernet protocol processing and multi-ECU simulation. This layer includes a SOME / IP protocol processing module, a SOME / IP-SD service discovery module, a TCP or UDP communication module, a data parsing module, and a network parameter configuration module. The SOME / IP protocol processing module is used to construct service message structures and control message types; the SOME / IP-SD service discovery module is used to implement service publishing, service search, and service subscription processing; the TCP or UDP communication module is used to implement Ethernet data link communication; the data parsing module is used to complete the serialization and deserialization processing of payload data; and the network parameter configuration module is used to configure the virtual LAN identifier, IP address, and port parameters of multiple electronic control unit nodes through virtual network cards, thereby realizing network isolation and communication relationship establishment between nodes. The object under test (AUT) layer is used to receive in-vehicle Ethernet service requests and execute corresponding business functions, while returning response data. The AUT layer includes multiple in-vehicle domain controller nodes and in-vehicle Ethernet conversion devices. Each in-vehicle domain controller node includes a cockpit domain controller, a body domain controller, a remote communication node, and other in-vehicle function nodes.

[0050] The present invention provides an automated testing method for vehicle Ethernet simulation based on SOA architecture, which is implemented through the aforementioned automated testing system for vehicle Ethernet simulation based on SOA architecture. For details on the specific method and process of the automated testing system for vehicle Ethernet simulation based on SOA architecture, please refer to the aforementioned embodiment of the automated testing method for vehicle Ethernet simulation based on SOA architecture, which will not be repeated here.

[0051] The foregoing has only described certain exemplary embodiments of this application by way of illustration. Undoubtedly, those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of this application. Therefore, the foregoing drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of this application.

Claims

1. An automated testing method for in-vehicle Ethernet simulation based on SOA architecture, characterized in that, Includes the following steps: Deploy a Python testing framework on a computer running Ubuntu, connect the computer to the device under test via an in-vehicle Ethernet converter, and connect another computer via a network to create a remote development environment, thus establishing a test and runtime environment for in-vehicle Ethernet communication. Based on the test environment, the network parameters and service information of multiple simulated electronic control unit nodes are defined by reading JSON or YAML configuration files. The network parameters include virtual LAN identifier, IP address and port number. The network isolation and communication relationship between each simulated electronic control unit node are achieved through virtual network card configuration. Based on the network parameters and service information of multiple simulated electronic control unit nodes, test cases are written by calling the pre-encapsulated interface application programming interface. The test cases include the sending of service request instructions and the acquisition of response data, and are used to describe the interaction logic of in-vehicle Ethernet services. The test case execution process is initiated. Based on the network parameters and service information of multiple simulated electronic control unit nodes, the service publication and subscription of SOME / IP and SOME / IP-SD protocols are completed. Service request message sending, response data reception and parsing are performed, and the test results are determined based on the parsing results. Concurrent execution and abnormal scenario injection are also supported. After the test cases are executed, a visual test report is generated based on the test results. The test report includes the test case execution status, pass rate, request and response data records, and error location information.

2. The automated testing method for in-vehicle Ethernet simulation based on SOA architecture according to claim 1, characterized in that, The simulated electronic control unit nodes are isolated and constructed through joint configuration of the operating system network namespace and virtual LAN tags. Each node is bound to an independent network interface and a unique IP resource, and cross-domain communication paths are set through routing rules.

3. The automated testing method for in-vehicle Ethernet simulation based on SOA architecture according to claim 1, characterized in that, The API includes a service request construction interface, a response data parsing interface, and an event subscription interface. Each interface describes the service identifier, method identifier, and payload content through a unified parameter structure, and completes the assembly and parsing of SOME / IP message format through a protocol encapsulation mechanism.

4. The automated testing method for in-vehicle Ethernet simulation based on SOA architecture according to claim 1, characterized in that, The SOME / IP and SOME / IP-SD protocol processing includes multiple communication stages such as service broadcasting, service lookup, subscription request sending, and subscription confirmation response. Each stage is managed through a message state control mechanism, and the communication process is associated and controlled through session identifiers and message identifiers.

5. The automated testing method for in-vehicle Ethernet simulation based on SOA architecture according to claim 1, characterized in that, Abnormal scenario injection is accomplished through parameterized configuration, including network latency injection, packet drop probability setting, and response time fluctuation control. Network latency is achieved through a sending queue delay mechanism, packet drop is controlled through a random packet loss algorithm, and response time fluctuation is achieved through dynamic processing time adjustment, thereby constructing a multi-dimensional communication anomaly simulation environment.

6. The automated testing method for in-vehicle Ethernet simulation based on SOA architecture according to claim 1, characterized in that, Concurrent execution is achieved through multi-threading or asynchronous event scheduling mechanisms. Each test task corresponds to an independent execution unit. Computing resources are allocated through task scheduling strategies, and multiple service call processes are coordinated in an event-driven manner.

7. The automated testing method for in-vehicle Ethernet simulation based on SOA architecture according to claim 1, characterized in that, The test report generation process includes three stages: communication log collection, structured storage of test results, and visualization data transformation. The communication logs contain request message content, response message content, and timestamp information. The structured storage organizes the test data through a unified data model, and the visualization transformation graphically displays the test pass rate and communication path information.

8. The automated testing method for vehicle Ethernet simulation based on SOA architecture according to claim 1, characterized in that, The configuration file describes the node attributes and service relationships of the simulated electronic control unit in JSON or YAML format. The configuration content includes node identifiers, service identifiers, and subscription relationships, and is dynamically loaded into the test environment through a configuration parsing mechanism.

9. The automated testing method for in-vehicle Ethernet simulation based on SOA architecture according to claim 1, characterized in that, The test run process introduces a containerized deployment mechanism, which encapsulates the Python test framework, protocol processing components and runtime dependencies into independent container images, and allocates computing resources through container orchestration. Each container instance corresponds to an independent simulation execution unit, supporting parallel operation of multiple instances and scheduling across computing nodes. At the same time, the loading of test task parameters and centralized management of execution results are achieved through a shared configuration directory and log output path.

10. An automated testing system for in-vehicle Ethernet simulation based on SOA architecture, characterized in that, It includes a test layer, an interface layer, a protocol and electronic control unit simulation layer, and a test object layer; The testing layer is used to implement test case construction, business logic orchestration, test result generation, and test data configuration management. The testing layer includes a test case module, a business logic module, a report generation module, and a configuration and data-driven module. The test case module is used to build test cases for multiple business scenarios, the business logic module is used to encapsulate the service call logic of the vehicle function domain, the report generation module is used to generate visual test reports, and the configuration and data-driven module is used to load test parameters and drive test data execution through configuration files. The interface layer is used to encapsulate the in-vehicle Ethernet service call interface. The interface layer includes the SOME / IP application interface module, which provides standardized interface application programming interfaces, including service request call interface, response acquisition interface and event subscription interface, for the test layer to call. The protocol and electronic control unit (ECU) simulation layer is used to implement in-vehicle Ethernet protocol processing and multi-ECU simulation. This layer includes a SOME / IP protocol processing module, a SOME / IP-SD service discovery module, a TCP or UDP communication module, a data parsing module, and a network parameter configuration module. The SOME / IP protocol processing module is used to construct service message structures and control message types; the SOME / IP-SD service discovery module is used to implement service publishing, service search, and service subscription processing; the TCP or UDP communication module is used to implement Ethernet data link communication; the data parsing module is used to complete the serialization and deserialization processing of payload data; and the network parameter configuration module is used to configure the virtual LAN identifier, IP address, and port parameters of multiple electronic control unit nodes through virtual network cards. The object under test (AUT) layer is used to receive in-vehicle Ethernet service requests and execute corresponding business functions, while returning response data. The AUT layer includes multiple in-vehicle domain controller nodes and in-vehicle Ethernet conversion devices. Each in-vehicle domain controller node includes a cockpit domain controller, a body domain controller, a remote communication node, and other in-vehicle function nodes.

Images