Remote test system and method for cabin ecology
By designing a remote testing system for the cockpit ecosystem, the problems of low efficiency and difficulty in collaboration in traditional cockpit testing have been solved. It enables efficient remote automated and manual collaborative testing, improves testing efficiency and quality, and shortens the cockpit system development cycle.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SAIC VOLKSWAGEN AUTOMOTIVE CO LTD
- Filing Date
- 2026-01-23
- Publication Date
- 2026-04-21
AI Technical Summary
Traditional cockpit testing is inefficient, costly, has limited scenario coverage, and is difficult to conduct remote collaboration. Existing remote testing tools lack unified resource management, intelligent task scheduling, and multimodal interaction capabilities.
Design a remote testing system for cockpit ecosystem, including a cloud service platform, test bench, web service module, business logic module, data storage module, and remote scheduling module. Employ the Vue framework, Express framework, MySQL database, and Redis cache to achieve unified management, task scheduling, and real-time monitoring of remote automated and manual testing.
It achieves efficient automation and human collaboration in cross-regional testing, reduces labor costs, improves testing efficiency and quality, supports full-process testing management, and shortens the cockpit system development cycle.
Smart Images
Figure CN121907741A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of automotive cabin testing technology, and more specifically, to a remote testing system and method for cabin ecology. Background Technology
[0002] With the rapid development of automotive intelligence and connectivity, the cockpit system has become the core carrier of human-machine interaction, encompassing multiple functional modules such as infotainment, navigation, vehicle control, and voice interaction. Traditional cockpit testing typically relies on on-site operation of test benches by test personnel, resulting in low testing efficiency, high labor costs, limited scenario coverage, and difficulties in remote collaboration. Especially today, with the increasing prevalence of distributed development and remote collaboration, existing testing methods are insufficient to meet the demands for efficient, flexible, and collaborative testing.
[0003] While some remote testing tools or platforms exist, they mostly focus on the remote execution of single functions and lack the ability to provide unified management of test resources, intelligent task scheduling, multimodal interaction (such as remote audio and video interaction), and closed-loop support for the entire testing process. Therefore, there is an urgent need for an integrated cockpit ecosystem testing system with high integration, strong scalability, and support for remote collaboration. Summary of the Invention
[0004] The present invention aims to provide a remote testing system and method for cabin ecology, in order to solve the problems of low testing efficiency, difficulty in collaboration, and decentralized resource management in the prior art.
[0005] To achieve the above objectives, the present invention provides the following technical solution:
[0006] A remote testing system for cockpit ecosystem includes: a cloud service platform with a web service module, a business logic module, a data storage module, and a remote scheduling module; and at least one test bench deployed at a remote physical location for performing cockpit ecosystem testing tasks.
[0007] The web service module provides users with an interactive interface for remote access and handles user-initiated test commands and status query requests.
[0008] The business logic module communicates and connects with the web service module to manage user permissions, test bench resources, test task queues, and test data.
[0009] The data storage module communicates with the business logic module and is used to manage and store data.
[0010] The remote scheduling module communicates with the business logic module and the distributed test bench. It receives test tasks issued by the business logic module and schedules the tasks to the corresponding target test bench for execution.
[0011] According to the provided system, the web service module builds the user interface based on the Vue framework and PrimeVue components, and provides static resources and request forwarding to the user terminal through the Nginx server.
[0012] According to the provided system, the business logic module implements business logic based on the Express framework, and provides application programming interfaces (APIs) for user management, rack management, task scheduling and test report processing.
[0013] According to the provided system, the data storage module uses a MySQL database to achieve persistent storage of test data, while ensuring data isolation between users, and is paired with a Redis caching server to provide queue support for test task scheduling.
[0014] According to the provided system, the remote scheduling module includes a remote agent unit corresponding to each test bench. The remote agent unit is used to encapsulate the communication protocol and network address of the corresponding test bench and provide a unified remote call interface to the business logic module.
[0015] According to the provided system, the test bench includes a control unit, which is communicatively connected to a remote agent unit to receive and feedback control information transmitted from the remote agent unit and to perform corresponding control on the test bench.
[0016] According to the provided system, the web service module and business logic module are deployed in containers.
[0017] According to the provided system, the system also includes an operations and maintenance module, which provides visual management of MySQL, Redis, and containers.
[0018] According to the provided system, the operation and maintenance module integrates a MySQL database management tool for visual management of MySQL, integrates PHPRedisAdmin for visual management of Redis, and integrates PortainerDocker for visual management of containers.
[0019] This invention also provides a remote testing method for cabin ecology, comprising the following steps:
[0020] S1. Users log in to the system through a browser, create or select a test task, and specify the target test bench;
[0021] S2. The cloud service platform distributes tasks to the corresponding racks;
[0022] S3. After receiving the task, the test bench will execute the test and transmit the status and results back to the cloud service platform in real time.
[0023] S4. The cloud service platform updates task status, stores test data, and provides a real-time monitoring interface and test report generation function.
[0024] The benefits of this invention are that it breaks physical limitations. Regardless of the location of the cockpit test benches, users can complete remote automated or manual testing simply by logging in remotely via a web interface, significantly reducing the labor costs and improving the efficiency of cross-regional testing. This invention automates the entire testing process, including automated testing, test ticketing, and report generation, further enhancing testing efficiency and quality. Through this system, users can uniformly manage test bench resources distributed across different locations, enabling the scheduling and execution of test tasks. Automated or manual testing between benches does not interfere with each other, allowing for real-time monitoring of test progress and bench status, and automatic collection and analysis of test data. This invention supports end-to-end management from test preparation to report generation, enabling teams located in different locations to collaborate, significantly improving testing efficiency, and thus shortening the cockpit system development cycle. Attached Figure Description
[0025] Figure 1 This is a schematic diagram of a remote testing system architecture for cockpit ecology.
[0026] Figure 2 This is a flowchart of a remote testing method for cabin ecology.
[0027] Attached label: 1-Test bench, 2-Internal network / switch, 3-Browser 2, 4-Browser 1, 5-Administrator, 6-Tester, 7-Cloud platform server, 8-Web service module, 9-Business logic module, 10-Data storage module, 11-Remote scheduling module. Detailed Implementation
[0028] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the invention.
[0029] See Figure 1 This invention provides a remote testing system for cockpit ecology, characterized by comprising: a cloud service platform 7 and at least one test bench 1, deployed at a remote physical location for performing cockpit ecology testing tasks. The user interaction logic involves the test bench 1 and the cloud service platform 7 being interconnected via an internal network 2. A PC client also accesses the system via the internal network. Security is ensured by the cloud service platform's access to the internal network. Testers 6 and administrators 5 interact with the system through client browsers 3 and 4.
[0030] The cloud service platform 7 deploys a web service module 8, a business logic module 9, a data storage module 10, and a remote scheduling module 11. The web service module 8 uses the Vue framework and PrimeVue components to build the user interface and provides static resources and request forwarding to user terminals via an Nginx server. The business logic module uses the Express framework to implement business logic, providing application programming interfaces (APIs) for user management, rack management, task scheduling, and test report processing. The data storage module 10 uses a MySQL database to persistently store test data while ensuring data isolation between users, and is paired with a Redis caching server to provide queue support for test task scheduling.
[0031] Web service module 8 provides users with an interactive interface for remote access and handles user-initiated test commands and status query requests. Specifically, the web service module uses the Vue framework (a JavaScript framework for building user interfaces) and PrimeVue (a UI library) components to build static resources for user interface development. These static resources and request forwarding are then provided to the user terminal via an Nginx (high-performance gateway) server. Static resources (such as HTML, CSS, JS, and images) are requested by the client's PC browser. After the request reaches Nginx, Nginx reads the resources from the local file system or a specified directory and returns them to the client.
[0032] Nginx supports the delivery of static resources and the interaction of dynamic content in the system, while also connecting with previously mentioned components such as MySQL and Redis to form a complete closed loop. Nginx is the system's front-end access layer, directly interfacing with the client browser. The static resources in this invention are fixed and do not require real-time generation, including HTML, images, CSS, and files. For static requests from the user's browser, such as static web pages, static images, page style sheets, page scripts, and file downloads, Nginx directly reads these static resources and quickly returns them to the browser for basic web page rendering, business logic modules, MySQL, and other components. Dynamic content is generated in real-time and changes with business data. For dynamic requests from the user's browser, including fetching user lists, rack status, and test results, Nginx does not directly process these contents. Instead, it forwards the dynamic requests to the API layer, which then calls business logic modules, MySQL, and other components to obtain real-time data, ultimately returning the results to the browser via Nginx.
[0033] Business logic module 9 communicates with the web service module and is used to manage user permissions, test bench resources, test task queues, and test data. Specifically, the business logic module serves as the core processing hub of the system and is built on the Express framework. This layer can receive requests from the web service module and provide application programming interfaces (APIs) for user management, bench management, task scheduling, and test report processing.
[0034] The data storage module 10 uses MySQL (database management engine) to achieve persistent storage of test data, while ensuring data isolation between users, and is equipped with a Redis caching server to provide queue support for test task scheduling.
[0035] The MySQL engine offers many database table structures, which can be broadly categorized into three main types:
[0036] The user management tables include the Department table, User table, Role table, Permission table, User-role association table, and role-permission association table. The core fields include user ID (primary key), password, role, permission identifier, creation time, etc., and their function is to support user login, access control and other functions.
[0037] The bench management tables include the TestBench table, BenchProject table, BenchTask table, Benchdevice table, and Testcase table. The core fields include bench ID (primary key), bench name, bench description, and status (offline / online / cloud mode / local mode), etc. Their purpose is to record basic bench information and provide a data foundation for operation management.
[0038] The operation management tables include the ScheduleTask table, TestReport table, and Notification table. The core fields include the scheduled task ID (primary key), the execution rig ID (foreign key), creation time, start time, execution result, and failure reason. Their purpose is to track the operation data of the entire life cycle of the rig and to be used for test plan management and result statistical analysis.
[0039] Each MySQL table corresponds to a Model (data model) in the business logic module. The attributes of the model correspond to the fields of the table. For example, the userId of the User model corresponds to the ID field of the user table. Its function is to automatically complete the conversion of model operations into SQL statements without the need to manually write SQL (database language). For example, when querying users, you can directly call userModel.findById(1001), and the framework will automatically generate select *from userwhereid=1001; when adding a bench, after setting the attributes of benchModel, call save(), and the framework will automatically execute the insert statement.
[0040] In addition, DataModel&CacheManager (Manage layer) was developed in business logic module 9. It is the core coordinator connecting the Redis cache, the Model (data model), and MySQL. Its design adopts a proxy pattern and a cache-first approach. The specific logic is as follows: The Manager holds references to the Redis cache and the Model. The Redis cache acts as a proxy for the Model, prioritizing data retrieval from the cache. Only when the cache misses does it query MySQL through the Model. The Model directly interfaces with MySQL, responsible for converting object operations into SQL.
[0041] Business logic module 9 also includes an API layer, which corresponds to database tables and contains APIs from different modules. For example, the UserAPI is a management API, including CRUD operations for users, roles, and permissions. In addition, there are other APIs for specific needs: parameter validation to verify the validity of request parameters and prevent invalid requests from entering the business logic module; permission interception to check if a user has the necessary permissions; format conversion to convert the Model object returned by the business logic module into the API response format, hiding internal fields; and exception handling to uniformly capture exceptions thrown by the business logic module and return standardized error messages. Users interact with the data system using these APIs through their client browsers.
[0042] The data storage module 10 also features a Redis cache to intercept high-frequency requests and reduce database pressure. For frequently queried data, such as real-time rack status, or data with high computational costs, Redis caching is used. The Redis caching strategy prioritizes queries through the cache. When the business logic module queries data, it first checks if the data exists in the Redis cache; if it does, it returns the result directly; otherwise, it queries MySQL through the model and then writes the result to the Redis cache. A Redis cache expiration policy is also implemented to manage the validity period of cached data, ensuring timely updates and releasing invalid data.
[0043] The Manager layer manages caching strategies, including priority read caching and updating expired caches. Redis is used for the scheduled task queue, receiving and storing tasks to be executed in an orderly manner for the system to execute sequentially or on a schedule. The Redis queue only stores the unique identifier of each task, responsible for task sorting and scheduling, with performance far exceeding that of directly querying MySQL for sorting. The scheduled task queue is designed so that tasks are not lost even if the service restarts. This invention employs a method of cooperation between a Redis server and a MySQL server. MySQL stores complete task information, while Redis stores task IDs and sorts them by execution order or time, responsible for task scheduling and sequential execution, and is used for high-frequency read / write and sorting operations. Finally, the test manager manages the scheduled task queue through a browser using the Service layer API, including database entry, queue entry, queued execution, retry strategies, delay strategies, and exception notifications.
[0044] Furthermore, this invention utilizes connection pooling technology to increase throughput and avoid the overhead of repeatedly creating TCP connections. The MySQL connection pool pre-creates a certain number of MySQL connections, preventing performance degradation caused by frequent connection creation or closure. The connection pool size is configurable, such as 10-20 connections. Similarly, cached connections are also managed through pooling to improve the efficiency of high-frequency interactions.
[0045] The remote scheduling module 11, communicatively connected to the business logic module 9 and the distributed test bench 1, receives test tasks issued by the business logic module and schedules the tasks to the corresponding target test bench for execution. Further, the remote scheduling module includes a remote proxy unit corresponding to each test bench. The remote proxy unit encapsulates the communication protocol and network address of the corresponding test bench, providing a unified remote call interface to the business logic module. The remote scheduling module only needs to call the unified interface of the remote proxy unit, without needing to know where the test bench is or how it communicates.
[0046] When the front-end page initiates a remote operation request, the business logic module accepts the request, performs permission verification and parameter formatting, and then sends the request to the corresponding bench endpoint through the remote scheduling module. This invokes the automated testing framework deployed on the bench to execute the remote test. The remote scheduling module has a dedicated remote proxy unit responsible for managing the connection and message forwarding between the remote proxy and the bench endpoint. All messages between the remote proxy module and the bench endpoint are transmitted through the remote proxy unit; no direct connection establishment is required. Messages are sent and received through the remote proxy unit, avoiding connection anomalies caused by bench offline or network fluctuations. The bench, as the interface of the actual bench, is a service deployed locally on the bench, receiving and executing remote call commands. The bench includes a control unit, which communicates with the remote proxy unit to receive and respond to control information from the remote proxy unit and perform corresponding control on the bench. After the bench completes automatic execution, the control unit sends the execution result back to the remote scheduling module through the remote proxy unit. The remote scheduling module then passes it to the API layer, which encapsulates it into a JSON response and forwards it to the browser via Nginx. The front-end page then displays the operation result.
[0047] In addition, to enable the manual testing mode of the remote cockpit system, this system uses a remote screen projection and reverse control module to enable remote control of the vehicle and mobile phone, a local audio acquisition and remote audio transmission module to enable remote audio interaction with the vehicle, a global shared memory module to monitor the vehicle status, a vehicle signal control module to enable remote control of vehicle signals, and a temporary task submission module to isolate cloud-based automated operations and manual operations to avoid conflicts.
[0048] The remote screen projection and control functions for vehicle-mounted systems and mobile phones are divided into two parts: remote projection of screen images and reverse control. This system supports multiple screens in the cockpit interaction system, such as the instrument panel, central control screen, passenger screen, and rear screens, displayed simultaneously on the front end, and allows different users to view the projected content from the same platform at the same time. The remote screen projection module specifically works by capturing the screen display of the Android system vehicle-mounted system using scrcpy or LVDS acquisition devices, converting it to JPEG format, and mapping it to local automated testing software. To reduce video transmission bandwidth consumption, the LIBJPEG-Turbo library is used to decode the JPEG images and then encode them into BMP format images. The BMP images from the local testing software are then transmitted frame by frame to the cloud for display via a self-developed messagepeer communication protocol. The remote screen reverse control technology works as follows: by capturing the interface operation actions projected onto the browser, the operation data is transmitted to the cloud server via WebShocket, and then transmitted from the cloud server to the local automated testing software via the RCP communication protocol. The local testing software transmits the acquired operation information to the scrcpyAPP installed on the host computer via the messagepeer protocol. At the same time, the scrcpyAPP simulates the mouse click events as local mouse click events on the host computer, thus realizing the remote control function of the Android device.
[0049] This system achieves this function through remote two-way audio transmission technology, thereby enabling remote audio interaction between web-based users and the local vehicle infotainment system. To achieve remote audio transmission, a local audio terminal hardware device was developed for sound acquisition, playback, and remote transmission between the local vehicle infotainment system and the host computer. This device uses an ESP32 microcontroller as its core, recording local voice data via a microphone, amplifying the sound from the microcontroller via an amplifier, playing the sound through a speaker locally, and communicating with the host computer via an SPI data-to-Ethernet data module. Since the local recording is raw PCM data, and PCM format is large and consumes a lot of bandwidth, this system uses an ffmpeg plugin (which records, converts, and streams digital audio and video) on the host computer to encode and compress the PCM into an MP3 audio stream before uploading it to the cloud. The Libmadmp3 decoder (an open-source, high-precision MPEG audio decoding library) decodes the MP3 file received from the cloud and converts it back to PCM (pulse code modulation) format for playback.
[0050] To prevent interference with the execution of remote automated scripts, this system converts remote manual operations into temporary scripts. When a user submits a remote action, it is automatically converted into a temporary script by a script deployed in the cloud and then transmitted from the cloud to the local host computer. The automated testing software deployed on the host computer first pauses the currently running task, inserts this temporary script as a temporary task at the front of the task queue, runs it, and feeds back the test results to the cloud platform and the user's webpage. After the temporary task ends, the test bench will resume the previously paused task.
[0051] Because the current system's test bench has multiple testing modes, such as local automation, local manual testing, remote automation, and remote manual testing, the cloud cannot confirm the bench's status in real time. To solve this problem, this invention deploys a global status table based on shared memory in the local automated testing software. When a script, such as one that opens a car door but hasn't run or has finished running, queries the global status table to check the door's status, allowing other processes to know the door's status at any time. Since the data type of each row in the shared memory table is not fixed, its length is also not fixed, requiring the use of variable-length data types, making variable-length data space allocation a challenge. For variable-length data space allocation, this system implements a shared memory-based allocator, specifically using a binary tree buddy memory allocation algorithm, allowing different processes to know the status of space allocated by other processes. The speed at which different processes access shared memory is almost the same as the speed at which they access variables within their own process. Simultaneously, the cloud can also indirectly access the global status table via an RPC communication protocol. Therefore, this shared memory table supports simultaneous access from scripts, the host computer, and the cloud. To ensure the safety of concurrent access to the shared memory area by various processes, this invention employs an inter-process mutual exclusion lock mechanism. When a process needs to access shared memory, it first acquires a mutex lock to prevent other processes from accessing it simultaneously; after the access is complete, it releases the mutex lock, at which point other processes are allowed to access the shared memory.
[0052] The core modules of this system are deployed in containers, such as MySQL, Redis, and Nginx. Portainer manages the containers to ensure system environment consistency, efficient resource utilization, rapid deployment and expansion, as well as isolation and security.
[0053] This system's design, development, and operation and maintenance module provides visualized management of three servers (MySQL, Redis, and containers) through a web-based interface for status monitoring, data manipulation, and container control. The operation and maintenance web interface offers independent management entry points for MySQL, Redis, and the container manager, each with its own set of dedicated operation and maintenance functions. The system integrates PHPMyAdmin (a MySQL database management tool), providing full database management capabilities with root privileges. It allows direct manipulation of the core MySQL database content without logging into the server to execute commands, including table structure viewing and management, data querying and manipulation, and status monitoring. The system also integrates PHPRedisAdmin, managing all cached and queued data with root privileges, monitoring cached data and queue status, including cache data viewing and cleanup, task queue monitoring and intervention, and Redis service monitoring. The core services of this invention are deployed in containers. The system integrates PortainerDocker (a container manager), providing high-privilege monitoring of all containers and offering container management services via a web page. It provides full lifecycle monitoring and operation of containers, including monitoring all containers, container health, container running status, container console, and container running logs. The system's operation and maintenance module provides services via a web page, allowing the operation and maintenance manager to perform operations through a browser.
[0054] See Figure 2 The present invention also provides a remote testing method for cabin ecology, comprising the following steps:
[0055] S1. Users log in to the system through a browser, create or select a test task, and specify the target test bench;
[0056] S2. The cloud server distributes the tasks to the corresponding racks;
[0057] S3. After receiving the task, the test bench executes the test and transmits the status and results back to the cloud server in real time.
[0058] S4. The cloud server updates task status, stores test data, and provides a real-time monitoring interface and test report generation function.
[0059] In one embodiment, when an administrator views a user list, the browser's request first reaches the Nginx container's request entry point. The Nginx container determines whether the request is for a static resource. If it is, it directly reads the corresponding HTML, IMAGE, CSS, and FILE files without going through the API, and returns these static files to the browser. The browser then quickly renders the table titles, buttons, etc. If it's a dynamic data request, the Nginx container forwards the request to the API layer. Upon receiving the request, the API layer first checks the Redis container cache. If the cache is hit, the data is retrieved directly from Redis, skipping the database. If the cache is not hit, the data model is invoked, querying the database through the MySQL container's connection pool. After retrieving the MySQL data, the ServiceAPI layer synchronizes the data to the Redis container for future queries. The user list data is then returned to the Nginx container via the API layer, and the Nginx container forwards the response back to the browser. The browser receives the data, populates the user data information into the table on the page, and finally, the administrator sees the complete user list, ending the entire data flow. The operations manager initiates requests to the MySQLAdmin, RedisAdmin, and Portainer containers through a browser and the operations webpage. The three containers respond with data in response to the requests.
[0060] In one embodiment, when a tester is testing a test bench, the front-end page initiates a remote operation request. The business logic module accepts the request, performs permission verification and parameter formatting, and then sends the request to the corresponding test bench via the remote scheduling module.
[0061] The bench control unit communicates with the remote agent unit in the remote scheduling module, invoking the automated testing framework deployed on the bench to execute remote tests. After the bench completes automatic execution, the control unit sends the execution result back to the remote scheduling module through the remote agent unit. The remote scheduling module then passes it to the API layer, which encapsulates it into a JSON response and forwards it to the browser via Nginx. The front-end page displays the operation results, provides a real-time monitoring interface and test report generation function, while the data storage module stores the test data.
[0062] The benefits of this invention are that it breaks physical limitations. Regardless of the location of the cockpit test benches, users can complete remote automated or manual testing simply by logging in remotely via a web interface, significantly reducing the labor costs and improving the efficiency of cross-regional testing. This invention automates the entire testing process, including automated testing, test ticketing, and report generation, further enhancing testing efficiency and quality. Through this system, users can uniformly manage test bench resources distributed across different locations, enabling the scheduling and execution of test tasks. Automated or manual testing between benches does not interfere with each other, allowing for real-time monitoring of test progress and bench status, and automatic collection and analysis of test data. This invention supports end-to-end management from test preparation to report generation, enabling teams located in different locations to collaborate, significantly improving testing efficiency, and thus shortening the cockpit system development cycle.
[0063] The embodiments described above are merely further illustrations of the present invention and are not intended to limit the present invention in any other way. The present invention may have many other embodiments. Without departing from the spirit and essence of the present invention, those skilled in the art can make various corresponding modifications and changes based on the present invention, but all such modifications and changes should fall within the protection scope of the present invention.
Claims
1. A remote testing system for cockpit ecology, characterized in that, include: The cloud service platform is equipped with web service modules, business logic modules, data storage modules, and remote scheduling modules. At least one test bench, deployed at a remote physical location, is used to perform cockpit ecosystem testing tasks. The web service module provides users with a remote access interface and processes user-initiated test commands and status query requests. The business logic module communicates with the web service module and manages user permissions, test bench resources, test task queues, and test data. The data storage module is communicatively connected to the business logic module and is used to manage and store data. The remote scheduling module is communicatively connected to the business logic module and the distributed test bench and is used to receive test tasks issued by the business logic module and schedule the tasks to the corresponding target test bench for execution.
2. The system according to claim 1, characterized in that, The web service module builds a user interface based on the Vue framework and PrimeVue components, and provides static resources and request forwarding to user terminals through an Nginx server.
3. The system according to claim 1, characterized in that, The business logic module is based on the Express framework to implement business logic and provides application programming interfaces (APIs) for user management, rack management, task scheduling and test report processing.
4. The system according to claim 3, characterized in that, The data storage module uses a MySQL database to persistently store test data while ensuring data isolation between users, and is paired with a Redis caching server to provide queue support for test task scheduling.
5. The system according to claim 1, characterized in that, The remote scheduling module includes a remote proxy unit corresponding to each test bench. The remote proxy unit is used to encapsulate the communication protocol and network address of the corresponding test bench and provide a unified remote call interface to the business logic module.
6. The system according to claim 5, characterized in that, The test bench includes a control unit, which is communicatively connected to a remote agent unit to receive and feedback control information transmitted from the remote agent unit and to perform corresponding control on the test bench.
7. The system according to claim 1, characterized in that, The web service module and business logic module are deployed in a container.
8. The system according to claim 7, characterized in that, The system also includes an operation and maintenance module, which provides visual management of MySQL, Redis, and containers.
9. The system according to claim 8, characterized in that, The operation and maintenance module integrates a MySQL database management tool for visual management of MySQL, PHPRedisAdmin for visual management of Redis, and PortainerDocker for visual management of containers.
10. A remote testing method for cabin ecology, characterized in that, The system described in any one of claims 1-9 includes the following steps: S1. Users log in to the system through a browser, create or select a test task, and specify the target test bench; S2. The cloud service platform distributes tasks to the corresponding racks; S3. After receiving the task, the test bench will execute the test and transmit the status and results back to the cloud service platform in real time. S4. The cloud service platform updates task status, stores test data, and provides a real-time monitoring interface and test report generation function.