Dynamic configuration cockpit host video test multiplexing method

Abstract

The invention belongs to the technical field of computers, and particularly relates to a dynamically configured cockpit host video test multiplexing method. The method aims at solving the problems that a traditional testing means is poor in universality, incomplete in coverage and low in automation degree. A structural equipment description file is constructed by analyzing a host technical document, an adaptive dynamic test configuration template is automatically generated in combination with a test case library, and flexible configuration of multi-channel video stream parameters, abnormal injection modes and time sequence logic is supported. A containerized virtual signal source is deployed on a universal computing platform, and an analog video stream conforming to an input specification is generated in real time. Through the equipment description driving and virtualization signal generation technology, the multiplexing capability and coverage integrity of the testing system are improved, efficient and automatic testing of multiple types of hosts is achieved, and the hardware cost and the deployment period are remarkably reduced.

Description

Technical Field

[0001] This application belongs to the field of computer technology, specifically relating to a method for dynamically configured cockpit host video testing and reuse. Background Technology

[0002] With the continuous evolution of smart cockpit technology, the complexity of in-vehicle information systems has significantly increased. The cockpit host, as the core hub of human-machine interaction, undertakes the tasks of acquiring, processing, and displaying multiple video signals. During the R&D and production testing phases, it is necessary to comprehensively verify the cockpit host's video input interface, decoding capabilities, screen switching logic, and display timing. Traditional testing methods rely on dedicated hardware signal sources to simulate camera input, requiring corresponding test equipment for each host model. This results in high redundancy, low resource utilization, and difficulty in adapting to the parallel testing needs of multiple platforms and configurations. Especially with rapid vehicle model iteration, the setup and maintenance cycle of the testing environment is long, severely impacting development efficiency and production line pace.

[0003] The key to cockpit main unit video testing lies in achieving accurate simulation and dynamic response of test signals to cover the differences in the number of cameras, resolution, frame rate, and transmission protocols across different vehicle configurations. To support multi-vehicle co-production, the testing system must possess cross-platform compatibility, flexibly adapt to the video input specifications of different main units, and quickly switch test parameters without requiring hardware replacement. Furthermore, the testing process must simultaneously verify the main unit's fault tolerance mechanisms and recovery strategies under abnormal signal input to ensure its stability and safety in real-world vehicle scenarios.

[0004] In existing technologies, test signal sources mostly employ dedicated equipment with fixed configurations, resulting in a single signal output mode and an inability to dynamically adjust video stream parameters based on the model and configuration of the host under test, leading to insufficient test coverage. Simultaneously, the test system lacks real-time analysis capabilities of host feedback information, making it difficult to achieve closed-loop control of the test process. Test steps rely on manual intervention, resulting in low automation. Furthermore, the synchronous generation and status management of multi-channel video signals depend on independent controllers, leading to a complex system architecture, poor scalability, and an inability to meet the demands of flexible test production lines for rapid deployment and efficient reuse. Therefore, there is an urgent need for a cockpit host video test reuse method that supports dynamic configuration to improve the flexibility, versatility, and automation level of the test system. Summary of the Invention

[0005] The purpose of this invention is to provide a dynamically configurable cockpit main unit video testing and reuse method, which can effectively solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows: a method for dynamic configuration of cockpit host video testing and reuse, comprising the following specific steps: Step (1) Establishing a device description file for the cockpit host under test: by parsing the technical documents and communication protocols provided by the host manufacturer, extracting the number of video input interfaces, physical type, supported video resolution, frame rate range, encoding format and transmission protocol parameters, and constructing a structured device description file. The file is defined using Extensible Markup Language format and includes host model, camera channel mapping relationship, signal timing requirements and anomaly handling strategy; Step (2) Generating a dynamic test configuration template: based on the device description file and combined with a preset test case library, automatically generating a test configuration template adapted to the current host model. The template includes parameter combinations of multi-channel video streams, signal switching sequences, anomaly injection modes and timing control logic, supports dynamic adjustment of resolution from 640 x 480 to 1920 x 1080 and frame rate from 15 frames per second to 60 frames per second, encoding formats covering H.264 and MJPEG, and transmission protocols adapted to GMSL2 and FPDLink. III; Step (3) Deploy virtualized test signal source: Instantiate multiple software-defined video signal generators on a general computing platform. Each generator runs independently in a containerized environment and generates a simulated video stream that conforms to the target host input specifications in real time according to the test configuration template. The signal generator is connected to the host through a PCIe interface or Gigabit Ethernet and supports the synchronous output of up to 8 high-definition video streams; Step (4) Execute closed-loop test process: After the test is started, the virtual signal source sends video streams to the host according to a preset sequence, and at the same time listens to the status information fed back by the host through the diagnostic bus, including decoding status, screen switching response time, error code and system log, and analyzes the feedback information in real time. The information is used to determine whether the host behavior meets expectations; Step (5) Dynamically adjust the test strategy: When the host feedback is abnormal or enters a specific working mode, the subsequent test steps are dynamically modified according to the preset rules, including injecting specific types of signal interference, adjusting video stream parameters to simulate low light or high latency scenarios, or triggering emergency switching tests to achieve adaptive evolution of the test process; Step (6) Generate a structured test report: Summarize the input signal parameters, host response data, timing deviations, error events and recovery behaviors in the test process to generate a structured test report that conforms to industry standards. The report includes pass / fail judgment, performance index statistics and problem location suggestions, and supports automatic archiving and traceability analysis.

[0007] Preferably, the device description file construction process in step (1) includes the identification and matching of the host firmware version to ensure that the differences in video input specifications between different versions are accurately recorded. The file is obtained from the enterprise-level configuration management database through a secure encrypted channel and is updated regularly to support the access of new host models.

[0008] Preferably, the test case library in step (2) contains a multi-dimensional test set covering normal working scenarios, boundary conditions and fault modes. The anomaly injection modes include simulated video signal loss, frame synchronization disorder, color distortion, resolution change and transmission delay jitter. Each mode is configured with adjustable parameters to achieve different levels of interference intensity control.

[0009] Preferably, in step (3), the containerized environment adopts lightweight virtualization technology. Each video signal generator container is allocated an independent CPU core and memory resources to ensure the real-time performance and stability of the multi-channel video stream generation process. The containers are synchronized through high-speed shared memory to avoid signal timing deviations caused by resource competition.

[0010] Preferably, the video stream generation module in step (3) has a variety of built-in image synthesis algorithms that can render camera images in simulated driving scenarios in real time, including forward driving, surround view stitching, rear-view reversing and blind spot monitoring perspectives. The images include dynamic traffic elements, lighting changes and weather effects, which are used to verify the host's processing capabilities under complex visual input.

[0011] Preferably, in step (4), the diagnostic bus uses vehicle Ethernet or CAN FD protocol for communication, and the status information collection frequency is not less than once every 100 milliseconds. The parsing process includes semantic decoding of the diagnostic message returned by the host, extracting key performance indicators such as first frame display delay, screen switching time and number of decoding errors, and comparing them with preset thresholds.

[0012] Preferably, the dynamic adjustment mechanism in step (5) is implemented based on a finite state machine model. The current operating state of the host is used as the input of the state machine. Combined with the preset decision rule table, the corresponding test strategy change is triggered. The rule table can be updated online through an external configuration interface to adapt to the test requirements of new models.

[0013] Preferably, the signal interference injection in step (5) is achieved by modifying the output parameters of the virtual signal source, including artificially introducing packet dropping, timestamp disorder, key frame interval lengthening and quantization parameter abnormality. The timing and duration of the interference mode application are dynamically determined by the test strategy to ensure coverage of various triggering conditions of the host fault tolerance mechanism.

[0014] Preferably, the method further includes a test resource scheduling and management module, which monitors the test task queues of multiple hosts under test, dynamically allocates virtual signal source instances according to the device idle status, test priority and resource configuration, realizes cross-project sharing and load balancing of test resources, and supports concurrent testing of up to 32 hosts.

[0015] Preferably, the method integrates an automated test execution engine, which supports the definition of complex test processes through scripting languages. The scripts include condition judgment, loop execution, and exception jump logic, which can simulate real user operation sequences, such as multi-screen linkage switching, voice command-triggered screen jump, and multi-task parallel processing scenarios.

[0016] Preferably, the structured test report is organized using a unified data model, including a metadata area, a test configuration area, an execution log area, and a result analysis area. It supports integration with an enterprise-level quality management system to achieve automatic uploading of test results, defect correlation, and trend analysis, with a report generation time of less than 30 seconds.

[0017] Compared with the prior art, the present invention has the following beneficial effects: Enhancing the versatility and reusability of the testing system: By establishing structured device description files and dynamic configuration templates, this invention achieves unified testing support for different models of cockpit mainframes, eliminating the need to configure dedicated hardware signal sources for each mainframe. The testing system can be reused to cover more than 16 mainstream mainframe platforms, improving hardware resource utilization by more than 70% and significantly reducing the procurement and maintenance costs of testing equipment.

[0018] Enhanced test coverage completeness and flexibility: This invention supports dynamic adjustment of multi-dimensional video parameters and precise injection of abnormal signals. Test cases cover normal operating conditions, boundary conditions and extreme fault scenarios, with test coverage increased to over 98%, which is 40 percentage points higher than the traditional fixed signal source method, effectively discovering potential defects of the host under complex input.

[0019] Achieving closed-loop control and automation of the testing process: By analyzing host feedback information in real time and dynamically adjusting the testing strategy, this invention constructs a closed-loop testing mechanism from signal input to behavioral response. The testing process requires no manual intervention, with an automation execution rate of over 95%, and the single complete test cycle is shortened to less than 8 minutes, which is 6 times more efficient than manual operation.

[0020] Supports rapid deployment of flexible production lines: The virtualized signal source architecture eliminates the dependence on dedicated hardware, and the test system can be quickly deployed on a standardized computing platform. The import time of test configurations for new models has been shortened from 3 days to 2 hours, meeting the needs of agile switching of test environments for multi-model co-production.

[0021] Improve the traceability and analytical value of test data: The generated structured test report fully records the data of the entire testing process, supports deep integration with the quality management system, and provides high-value data support for defect root cause analysis, process optimization and host software iteration, reducing the problem location time by an average of 50%.

[0022] Ensuring the real-time performance and stability of the system: Containerized isolation and exclusive resource allocation mechanisms are adopted to ensure that the synchronous generation of multi-channel high-definition video streams is not disturbed, and the signal output timing jitter is controlled within 1 millisecond, meeting the stringent requirements of the cockpit host for real-time video input. The test results are highly consistent and repeatable. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the overall technical solution architecture of the dynamically configured cockpit host video testing reuse method proposed in this invention; Figure 2 This is a schematic diagram of the core principle framework of adaptive closed-loop testing and dynamic strategy adjustment in this invention. Detailed Implementation

[0024] Example 1 Please refer to Figure 1 and Figure 2 To make the objectives, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail below with reference to specific embodiments.

[0025] In the above-mentioned method for dynamic configuration of cockpit host video testing and reuse, step (1) establishes the device description file of the cockpit host under test: by parsing the technical documents and communication protocols provided by the host manufacturer, the number of video input interfaces, physical type, supported video resolution, frame rate range, encoding format and transmission protocol parameters are extracted to construct a structured device description file. The file is defined using Extensible Markup Language (EXPLAIN) format and includes the host model, camera channel mapping relationship, signal timing requirements and anomaly handling strategy. Specifically, the construction process of the device description file includes the identification and matching of the host firmware version to ensure that the differences in video input specifications between different versions are accurately recorded. The host firmware version information is obtained by reading the diagnostic message broadcast when the host starts up. The message format conforms to the ISO14229-1 standard and includes the host hardware platform identifier, software version number and build timestamp. The system retrieves the corresponding video input specification template from the enterprise-level configuration management database based on the host model and firmware version combination. This database is deployed in the cloud using a master-slave architecture, with the master node located in the data center and slave nodes distributed across various test sites. Data synchronization is performed via a secure encrypted channel (TLS 1.3 protocol) to ensure data consistency and tamper-proof protection. The device description file is defined in XML format, with its root node as `<root>` and child nodes such as `<head>`. Each node includes the number of interfaces (ranging from 1 to 8), physical type (enumerated values: GMSL2, FPDLinkIII, LVDS, HDMI), a list of supported resolutions (e.g., 640×480, 720×480, 1280×720, 1920×1080), frame rate range (minimum 15 frames / second, maximum 60 frames / second), encoding format (H.264, MJPEG), and transmission protocol parameters (e.g., GMSL2's link rate is configured as 1.5Gbps or 3Gbps). The nodes adopt a key-value pair structure, defining the mapping relationship between the host's internal video processing channels and the physical interfaces of external cameras, such as "Channel0→FrontCamera" and "Channel3→RearCamera," and supporting virtual channel definition in multi-signal splicing mode. Signal timing requirements include parameters such as the vertical synchronization interval of the video stream, the horizontal blanking period, and the pixel clock phase offset. These values ​​are derived from the timing specifications provided by the host manufacturer, in nanoseconds, with an accuracy controlled within ±5ns. The anomaly handling strategy defines the host's response behavior when receiving abnormal signals, such as the default screen switching logic when a signal is lost, the buffering strategy when the frame rate changes abruptly, and the retry mechanism when encoding errors occur. After the device description file is generated, a hash value is generated using the SHA-256 algorithm and stored in the database. Integrity verification is performed before each call to prevent accidental configuration modification. This file is updated regularly, weekly, or triggered immediately upon detecting a new host model, ensuring the system continuously supports the latest vehicle models.

[0026] In the above-mentioned method for dynamic configuration of cockpit host video test reuse, step (2) generates a dynamic test configuration template: based on the device description file and combined with the preset test case library, a test configuration template adapted to the current host model is automatically generated. The template includes parameter combinations of multi-channel video streams, signal switching sequences, anomaly injection modes, and timing control logic. It supports dynamic adjustment of resolution from 640×480 to 1920×1080 and frame rate from 15 frames / second to 60 frames / second. The encoding format covers H.264 and MJPEG, and the transmission protocol is adapted to GMSL2 and FPDLink III. Specifically, the test case library contains a multi-dimensional test set covering normal working scenarios, boundary conditions, and fault modes. The anomaly injection modes include simulated video signal loss, frame synchronization disorder, color distortion, resolution abrupt change, and transmission delay jitter. Each mode is configured with adjustable parameters to achieve different degrees of interference intensity control. The test case library is stored in a relational database, with table structures including fields such as TestCaseID, ScenarioType (normal, boundary, fault), ParameterRange, InjectionMode, and ExpectedBehavior. After loading the device description file, the system filters all executable test items from the test case library based on the interface types and parameter ranges supported by the host, and sorts them according to preset priorities. Dynamic test configuration templates are generated in JSON format, with a top-level structure containing fields such as TestSequence, ChannelConfig, InjectionProfile, and TimingLogic. TestSequence defines the execution order of test steps, supporting both linear sequence and conditional jump modes. ChannelConfig assigns independent parameter configurations to each video channel, including resolution, frame rate, encoding format, and image content type (static image, dynamic scene, noise map). InjectionProfile defines the type, start time, duration, and intensity parameters of anomaly injection. For example, the intensity parameter for "signal loss" mode is packet loss rate (adjustable from 0% to 100%), and the parameters for "color distortion" mode are hue shift (±180 degrees) and saturation attenuation coefficient (0 to 1). TimingLogic defines the synchronous and asynchronous switching logic for multi-channel signals, supporting precise control based on absolute timestamps with a time resolution of 1 millisecond. During template generation, the system performs validity checks on parameter combinations, excluding configurations beyond the host's support range, and automatically inserts boundary value test cases, such as combinations of maximum resolution and minimum frame rate, and combinations of maximum frame rate and minimum resolution. Furthermore, the system supports importing custom test sequences through an external configuration interface for specific vehicle model verification.

[0027] In the above-mentioned method for dynamic configuration of cockpit host video test multiplexing, step (3) deploys a virtualized test signal source: multiple software-defined video signal generators are instantiated on a general-purpose computing platform. Each generator runs independently in a containerized environment and generates a simulated video stream that conforms to the target host input specifications in real time according to the test configuration template. The signal generator is connected to the host through a PCIe interface or Gigabit Ethernet and supports the synchronous output of up to 8 high-definition video streams. Specifically, the containerized environment adopts lightweight virtualization technology. Each video signal generator container is allocated independent CPU cores and memory resources to ensure the real-time performance and stability of the multi-channel video stream generation process. The containers are synchronized through high-speed shared memory to avoid signal timing deviations caused by resource contention. The general-purpose computing platform adopts an x86_64 architecture server, equipped with an Intel Xeon Gold 6330 processor (28 cores and 56 threads), 256GB DDR4 memory, NVIDIA A40 GPU (48GB video memory), and dual-port 10GbE network card. The containerized environment is deployed on a Kubernetes cluster, using Docker as the container runtime. Each video signal generator is encapsulated as an independent Pod, bound to a specific physical core via CPU affinity. Memory resources are hard-isolated using cgroups, with a minimum allocation of 4GB and a maximum limit of 8GB. GPU resources are scheduled through NVIDIA Container Runtime, with each container able to request 1 / 4 to 1 full GPU instance to accelerate image synthesis and video encoding. Inter-container communication is achieved through a POSIX shared memory region on the host machine, with a shared memory size of 16GB and a circular buffer structure for transmitting synchronization signals, timestamps, and status flags. The video stream generation module incorporates multiple image synthesis algorithms, capable of rendering camera footage in simulated driving scenarios in real time, including forward driving, surround view stitching, rear-view reversing, and blind spot monitoring perspectives. The footage includes dynamic traffic elements, lighting changes, and weather effects, used to verify the host's processing capabilities under complex visual input. Image synthesis is custom-developed based on Unreal Engine 5. Scene models include typical environments such as urban roads, highways, tunnels, and parking lots. Dynamic elements include vehicles, pedestrians, and traffic lights. The lighting system supports day and night cycles (sunlight from 06:00 to 18:00 and night from 18:00 to 06:00). The weather system can simulate four modes: sunny, rainy, foggy, and snowy. Each mode has independent visibility, light attenuation, and road surface reflectivity parameters.The video encoding module supports both H.264 and MJPEG formats. Encoding parameters (such as bitrate, keyframe interval, and quantization parameters) are dynamically adjusted according to the test configuration template. H.264 encoding is implemented using the x264 library, with keyframe intervals ranging from 1 to 30 frames and quantization parameters ranging from 18 to 36. MJPEG encoding uses the libjpeg-turbo library, with compression quality set to 80 to 95. Signal output connects to a GMSL2 serializer chip (such as MAX96745) via a PCIe interface or sends RTP / UDP video streams via Gigabit Ethernet. Output timing is precisely controlled by a hardware timer to ensure that the synchronization error of multi-channel signals is less than 1 millisecond.

[0028] In the above-mentioned dynamic configuration cockpit host video test reuse method, step (4) executes a closed-loop test process: after the test is started, the virtual signal source sends a video stream to the host according to a preset sequence, and at the same time listens to the status information fed back by the host through the diagnostic bus, including decoding status, screen switching response time, error code and system log, and analyzes the feedback information in real time to determine whether the host behavior meets expectations. Specifically, the diagnostic bus uses the vehicle Ethernet or CANFD protocol for communication, and the status information collection frequency is not less than once every 100 milliseconds. The analysis process includes semantic decoding of the diagnostic message returned by the host, extracting key performance indicators such as first frame display delay, screen switching time and decoding error count, and comparing them with preset thresholds. When the test process starts, the automated test execution engine loads the test script, which is written in Python and includes condition judgment, loop execution and exception jump logic. It can simulate real user operation sequences, such as multi-screen linkage switching, voice command triggering screen jump and multi-task parallel processing scenarios. The virtual signal source generates and sends a video stream based on the test configuration template. Simultaneously, the diagnostic monitoring module connects to the host diagnostic bus via a dedicated interface (such as a PCAN-USB FD adapter or BroadR-Reach PHY) and polls for status messages every 100 milliseconds. Received messages are first parsed: if it's a CAN FD message, the DLC (Data Length Code) and data fields are extracted according to the ISO 11898-1 standard; if it's a vehicle Ethernet message, the MAC frame is parsed according to the IEEE 802.3 standard, and then the service ID, method ID, and payload are extracted according to the SOME / IP protocol. The semantic decoding module loads the corresponding diagnostic dictionary based on the host model, converting the raw byte stream into readable status variables. For example, the "Decoding Status" field value is 0x00 for normal operation, 0x01 for a bitstream error, and 0x02 for a buffer overflow; the "Screen Switching Response Time" field is a 32-bit unsigned integer in milliseconds. The key performance indicator (KPI) extraction logic is as follows: First frame display latency is defined as the time difference between the completion of sending the first frame of video data and the host returning a "screen displayed" status, recorded using a high-precision timer (1 microsecond accuracy); screen switching time is obtained by detecting the time interval between the host receiving the channel switching command and the output screen source change; decoding error count is calculated by accumulating the frequency of error code messages. All indicators are compared in real time with preset thresholds, which are stored in the test configuration template. For example, the first frame display latency threshold is set to 500 milliseconds, the screen switching time threshold is set to 200 milliseconds, and the decoding error count threshold is set to 0. If any indicator exceeds the threshold, the system marks the test item as failed and records the context information for subsequent analysis.

[0029] In the above-mentioned method for dynamic configuration of cockpit host video testing and reuse, step (5) dynamically adjusts the test strategy: when the host feedback is abnormal or enters a specific working mode, the subsequent test steps are dynamically modified according to preset rules, including injecting specific types of signal interference, adjusting video stream parameters to simulate low light or high latency scenarios, or triggering emergency switching tests, so as to realize the adaptive evolution of the test process. Specifically, the dynamic adjustment mechanism is based on a finite state machine model. The current operating state of the host is used as the input of the state machine. Combined with the preset decision rule table, the corresponding test strategy change is triggered. The rule table can be updated online through an external configuration interface to adapt to the test requirements of new vehicle models. The finite state machine includes states such as Idle, NormalOperation, ErrorDetected, LowLightSim, HighLatencySim, and EmergencySwitch. The state transition is driven by the state information fed back by the host. For example, when "decoding error count > 0" is parsed, the state machine transitions from NormalOperation to ErrorDetected; when the host is detected to enter "night driving mode", it transitions to LowLightSim. The decision rule table is stored in YAML format. Each rule contains a Condition (conditional expression), an Action (action to be performed), and a Priority (priority). Conditional expressions support logical operations, such as "DecodingErrorCount>0 AND FrameRate<30". Actions include "InjectionMode=PacketLoss", "FrameRate=15", and "TriggerEmergencySwitch". The rule table supports online updates via a RESTful API; update requests require a digital signature to verify permissions. Signal interference injection is achieved by modifying the output parameters of the virtual signal source, including artificially introducing packet dropping, timestamp distortion, keyframe interval lengthening, and quantization parameter anomalies. The timing and duration of the interference mode application are dynamically determined by the test strategy to ensure coverage of various triggering conditions of the host fault tolerance mechanism. Packet dropping is implemented at the transport layer, either by modifying the UDP checksum or by directly dropping a specified percentage of packets (the packet loss rate can be set from 1% to 20%). Timestamp distortion is achieved by injecting random offsets (±50 milliseconds) into the video stream's timestamp field. Keyframe interval lengthening is achieved by modifying the H.264 encoder parameters, increasing the GOP (Group of Pictures) size from the default value of 15 to 60. Abnormal quantization parameters are caused by forcing the QP value to be above 40, resulting in severe image distortion. The application of interference modes follows a "gradual" principle, with an initial strength set at a low level. If the host does not trigger a recovery mechanism, the strength is gradually increased until a preset upper limit is reached, used to test the boundaries of the host's fault tolerance capabilities.

[0030] In the above-mentioned dynamically configured cockpit host video test reuse method, step (6) generates a structured test report: summarizing the input signal parameters, host response data, timing deviations, error events and recovery behaviors during the test process, and generating a structured test report that conforms to industry standards. The report includes pass / fail judgment, performance index statistics and problem location suggestions, and supports automatic archiving and traceability analysis. Specifically, the structured test report is organized using a unified data model, including a metadata area, a test configuration area, an execution log area and a result analysis area. It supports interface with an enterprise-level quality management system to realize automatic uploading of test results, defect correlation and trend analysis, and the report generation time is less than 30 seconds. The metadata area records basic test information, including host model, firmware version, test timestamp, tester ID, and test environment temperature and humidity. The test configuration area stores a complete copy of the device description file and test configuration template used in this test in XML format. The execution log area uses a time-series database (such as InfluxDB) to record the input signal parameters and host feedback status every millisecond, forming a complete time-series curve. The result analysis area includes statistical tables and charts, such as "First Frame Delay Distribution Chart for Each Channel," "Statistical Table of Decoding Error Count," and "Box Plot of Screen Switching Response Time." Pass / fail judgment is based on preset pass / fail criteria, including that all key indicators do not exceed thresholds, there are no fatal error codes, and recovery behavior meets expectations. Problem localization suggestions are generated by the rule engine, based on error pattern matching of the historical case library. For example, when "host restarts after 3 consecutive decoding errors," it is suggested to "check for host H.264 decoder memory leak issues." The report generation module uses multi-threaded parallel processing; data aggregation and formatting are completed within 10 seconds, PDF rendering and compression are completed within 20 seconds, and the total time is controlled within 30 seconds. The generated report is automatically uploaded to an enterprise-level quality management system (such as JIRA or TestRail) via HTTPS protocol, triggering a defect creation process. The defect ticket is automatically associated with the test report URL, host log file, and video recording clip.

[0031] In the aforementioned method for dynamically configured cockpit host video testing and reuse, the method further includes a test resource scheduling and management module. This module monitors the test task queues of multiple hosts under test and dynamically allocates virtual signal source instances based on device idle status, test priority, and resource configuration. This enables cross-project sharing and load balancing of test resources, supporting concurrent testing of up to 32 hosts. The test resource scheduling and management module runs as an independent microservice on a Kubernetes cluster and communicates with each test node via a gRPC interface. Its core functions include task queue management, resource status monitoring, scheduling decisions, and failover. The task queue uses Redis as the message middleware and supports priority queues. Test tasks are categorized into four levels based on project urgency: P0 (urgent), P1 (high), P2 (medium), and P3 (low). The resource status monitoring module collects CPU, memory, GPU, network bandwidth usage, and virtual signal source instance occupancy data for each test node every 5 seconds. This data is stored in a Prometheus time-series database. The scheduling decision uses a weighted scoring algorithm to calculate the comprehensive score for each idle node. Among them, weight , , Set them to 0.4, 0.3, and 0.3 respectively. For the overall score, Available CPU resources Total CPU resources Available GPU resources Total GPU resources Available network bandwidth Total network bandwidth reflects the importance of computing, graphics, and network resources. The system selects the node with the highest score to assign tasks and reserves 10% of resources as a margin to handle sudden loads. When a node fails, its unfinished tasks are automatically migrated to other available nodes to ensure test continuity. This module supports concurrent testing on up to 32 hosts, with each host using up to 8 virtual semaphores, for a total semaphore instance pool of 256.

[0032] In the aforementioned dynamically configured cockpit host video testing and reuse method, the method integrates an automated test execution engine. This engine supports defining complex test processes using a scripting language. The scripts include conditional statements, loop execution, and exception handling logic, simulating real user operation sequences such as multi-screen switching, voice-triggered screen transitions, and multi-task parallel processing scenarios. The automated test execution engine is developed based on Python 3.9 and provides a domain-specific language (DSL) for writing test scripts. The script syntax supports if-elif-else conditional branches, for / while loops, try-catch exception handling, and function definition and calling. A typical script example is as follows: Start the forward driving view and wait 2 seconds; if an obstacle warning is detected, switch to the surround-view stitching mode; otherwise, maintain the original view; loop 5 times, randomly switching to any camera view each time with a 1-second interval; simulate the voice command "Open the rearview camera" to verify whether the host switches to the rearview view within 500 milliseconds. During script execution, the engine monitors the host status in real time. If an anomaly occurs (such as a host crash), it executes preset recovery actions, such as restarting the host or re-initializing the signal source. The engine supports the parallel execution of multiple scripts, with each script running in an independent coroutine. Stability under high concurrency is ensured through event loop scheduling.

[0033] In the aforementioned method for reusing dynamically configured cockpit mainframe video tests, the generation process of the structured test report further includes in-depth analysis of the test data to support long-term quality trend monitoring. The system calculates a resource configuration deviation index to evaluate the rationality of the test resource configuration. Where N is the number of sampling points within the test period, spatial mismatch rate refers to the proportion of mismatch between the physical location of the test resource and the location of the host under test, target deviation refers to the difference between the actual test coverage and the target coverage, and execution lag coefficient is the ratio of actual execution time to planned time. This index is used to optimize resource scheduling strategies.

[0034] In a specific application example of the aforementioned dynamically configured cockpit host video testing multiplexing method, a test of a certain model of intelligent cockpit host (model: ICU-8200) is taken as an example. Before the test, the system reads the host firmware version as V2.1.3 through the diagnostic interface, downloads the corresponding device description file from the configuration management database, and confirms that it supports 4 GMS L2 interfaces, with a maximum resolution of 1920×1080@60fps and an encoding format of H.264. The system generates a test configuration template containing 128 test cases, covering scenarios such as normal video input, resolution abrupt changes (1080p→720p), frame rate jitter (60→30→60fps), and color distortion (hue shift +90 degrees). The test resource scheduling module allocates a server equipped with an A40 GPU and instantiates 4 video signal generator containers to simulate forward-looking, surround-view, rear-looking, and side-looking cameras, respectively. During the test execution, the 45th test case (simulating a sudden change in lighting when entering or exiting a tunnel) triggers a stutter in the host screen, and the diagnostic message displays "decoding buffer overflow". The dynamic adjustment module immediately switched subsequent tests to "high-load stress test" mode, continuously sending 1080p@60fps H.264 video streams and injecting 5% random packet loss. The host automatically restarted after the third stress test; the system recorded this behavior and marked it as a critical defect. After the test, a structured report was generated, including data such as an average first-frame latency of 320 milliseconds, an average screen transition time of 180 milliseconds, and 6 decoding errors. The problem localization suggestion pointed to "a resource leak risk in the video decoder memory management module." The report was automatically uploaded to the quality management system, associated with defect ID: DEF-20240520-087.

[0035] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A method for dynamically configured cockpit main unit video testing and reuse, characterized in that, Includes the following steps: A device description file is created for the main unit of the cockpit under test. By parsing the technical documents and communication protocols provided by the main unit manufacturer, the number of video input interfaces, physical type, supported video resolution, frame rate range, encoding format and transmission protocol parameters are extracted to construct a structured device description file. A dynamic test configuration template is generated. Based on the device description file and a preset test case library, a test configuration template adapted to the current host model is automatically generated. The test configuration template includes parameter combinations of multi-channel video streams, signal switching sequences, anomaly injection modes, and timing control logic. Deploy virtualized test signal sources, instantiate multiple software-defined video signal generators on a general computing platform, with each generator running independently in a containerized environment, and generate simulated video streams that conform to the target host input specifications in real time according to the test configuration template; The closed-loop test process is executed. After the test is started, the virtualized test signal source sends video streams to the host in a preset sequence. At the same time, the status information fed back by the host through the diagnostic bus is listened to and the status information is analyzed in real time to determine whether the host behavior meets expectations. The test strategy is dynamically adjusted. When the host feedback is abnormal or enters a specific working mode, the subsequent test steps are dynamically modified according to the preset rules. Generate a structured test report that summarizes the input signal parameters, host response data, timing deviations, error events and recovery behaviors during the test process, and generates a structured test report that conforms to industry standards.

2. The method according to claim 1, characterized in that, The device description file is defined using Extensible Markup Language (EXPLAIN) format and includes host model, camera channel mapping relationship, signal timing requirements, and anomaly handling strategy. The construction process of the device description file includes the identification and matching of host firmware version to ensure that the differences in video input specifications between different versions are accurately recorded. The device description file is obtained from the enterprise-level configuration management database through a secure encrypted channel and is updated regularly to support the access of new host models.

3. The method according to claim 1, characterized in that, The test case library contains a multi-dimensional test set covering normal working scenarios, boundary conditions, and fault modes. The anomaly injection modes include simulated video signal loss, frame synchronization disorder, color distortion, resolution abrupt change, and transmission delay jitter. Each mode is configured with adjustable parameters to achieve different levels of interference intensity control.

4. The method according to claim 1, characterized in that, The containerized environment employs lightweight virtualization technology, with each video signal generator container allocated independent CPU cores and memory resources to ensure real-time performance and stability during the multi-channel video stream generation process. Containers synchronize their states through high-speed shared memory to avoid signal timing deviations caused by resource contention.

5. The method according to claim 1, characterized in that, The multi-channel video stream generation module incorporates various image synthesis algorithms, enabling real-time rendering of camera footage in simulated driving scenarios, including forward driving, surround view stitching, rear-view reversing, and blind spot monitoring perspectives. The footage includes dynamic traffic elements, lighting changes, and weather effects, used to verify the host's processing capabilities under complex visual inputs.

6. The method according to claim 1, characterized in that, The diagnostic bus communicates using vehicle Ethernet or CAN FD protocol, and the status information is collected at a frequency of no less than once every 100 milliseconds. The status information collection process includes semantic decoding of the diagnostic messages returned by the host, extracting key performance indicators such as first frame display delay, screen switching time, and number of decoding errors, and comparing them with preset thresholds.

7. The method according to claim 1, characterized in that, The mechanism for dynamically adjusting the test strategy is based on a finite state machine model. The current operating state of the host is used as the input of the state machine. Combined with a preset decision rule table, the corresponding test strategy changes are triggered. The decision rule table can be updated online through an external configuration interface to adapt to the testing requirements of new vehicle models.

8. The method according to claim 1, characterized in that, The signal intensity is altered by modifying the output parameters of the virtual signal source, including artificially introducing packet dropping, timestamp distortion, keyframe interval lengthening, and quantization parameter anomalies. The timing and duration of the interference mode application are dynamically determined by the test strategy to ensure coverage of various triggering conditions of the host fault tolerance mechanism.

9. The method according to claim 1, characterized in that, It also includes a test resource scheduling and management module, which monitors the test task queues of multiple hosts under test, dynamically allocates virtual signal source instances based on device idle status, test priority and resource configuration, realizes cross-project sharing and load balancing of test resources, and supports concurrent testing of up to 32 hosts.

10. The method according to claim 1, characterized in that, It integrates an automated test execution engine, which supports the definition of complex test processes through a scripting language. The scripting language includes condition judgment, loop execution and exception jump logic, which can simulate real user operation sequences, multi-screen linkage switching, voice command-triggered screen jump and multi-task parallel processing scenarios.

Images