Vehicle off-line inspection methods and systems

Abstract

This invention discloses a method and system for detecting vehicle off-line performance. Compared with existing technologies, this invention develops an EOL (Electronic End-of-Line) detection service natively through the vehicle's infotainment system and uses the system itself as the diagnostic host, completely eliminating the reliance on external electrical testing hardware. It replaces traditional hardware equipment with a pure software solution, thereby significantly reducing production line construction and operation costs. At the same time, by leveraging the cooperation between the workstation sensing unit and the vehicle's built-in sensing module, it achieves automatic workstation ID recognition, triggering the server to automatically match and issue the corresponding detection script. The entire process requires no manual intervention, eliminating the risk of errors caused by human operation and greatly improving detection efficiency.

Description

Technical Field

[0001] This invention relates to the technical field of automobiles, specifically to a method and system for detecting the off-line inspection of complete vehicles. Background Technology

[0002] With the increasing level of automotive electronics, vehicle off-line testing has become a crucial step in ensuring vehicle quality and safety. Currently, off-line testing generally uses external electronic diagnostic hardware as the diagnostic host. Operators need to physically connect the external device to the vehicle via the OBD interface and manually complete operations such as VIN code entry, workstation selection, and vehicle model matching before they can perform the testing and calibration tasks for each ECU.

[0003] However, the above methods rely heavily on external electrical testing hardware and manual intervention. The hardware procurement and maintenance costs are high, and the manual operation is inefficient and prone to errors, making it difficult to meet the production line's needs for cost reduction and efficiency improvement. At the same time, the underlying differences between different vehicle operating systems (Android in the cockpit domain and QNX / Linux in the vehicle control domain) also make it difficult to deploy and coordinate the testing system on multi-OS vehicle systems. Summary of the Invention This invention aims to at least address the technical problems existing in the prior art, which rely on external electrical testing hardware and manual intervention, resulting in high hardware procurement and maintenance costs, and low efficiency and error-prone manual operation. Therefore, this invention provides a method and system for vehicle off-line testing.

[0004] According to a first aspect of the present invention, a method for vehicle off-line testing based on an on-board diagnostic system is applied to an in-vehicle infotainment system. The method includes: After the vehicle is powered on, it enters factory mode through hardware triggering or key verification and starts the natively developed EOL detection service. The EOL detection service integrates UDS diagnostic protocol, OBD diagnostic protocol and DoIP diagnostic protocol, and is deeply integrated with the vehicle diagnostic module. It establishes communication with each ECU of the vehicle through in-vehicle Ethernet, CAN bus or CAN FD bus. The system obtains the workstation ID by scanning the workstation sensing unit deployed at the workstation using the built-in sensing module, uploads the vehicle VIN code, its own software and hardware version and the workstation ID to the production line cloud / edge server, and receives the detection script matched and issued by the production line cloud / edge server according to the workstation ID. The cockpit domain and vehicle control domain are scheduled through an abstract communication middleware. The vehicle control domain performs diagnostic operations with high safety requirements, while the cockpit domain provides the HMI interactive interface. The on-board diagnostic module is driven by the detection script to perform detection operations, collect the result data of each detection item and upload it to the production line cloud / edge server, and receive the detection pass instruction from the production line cloud / edge server. Based on the qualified test instruction, automatically exit factory mode, clear temporary data generated during the test, and switch to user mode.

[0005] A vehicle off-line testing method based on an on-board diagnostic system according to an embodiment of the present invention has at least the following beneficial effects: Compared with existing technologies, this invention develops an EOL (Electronic Occurrence Limit) detection service natively in the vehicle and uses the vehicle itself as the diagnostic host, completely eliminating the reliance on external electrical testing hardware. It replaces traditional hardware equipment with a pure software solution, significantly reducing production line construction and operating costs. Simultaneously, by leveraging the cooperation between the workstation sensing unit and the vehicle's built-in sensing module, it achieves automatic workstation ID recognition, triggering the server to automatically match and issue the corresponding detection script. The entire process requires no manual intervention, eliminating the risk of errors caused by human operation and greatly improving detection efficiency. Furthermore, this invention abstracts the communication middleware to shield the underlying differences between the cockpit domain's Android system and the vehicle control domain's QNX / Linux system. The vehicle control domain performs high-security diagnostic operations to ensure safety, while the cockpit domain provides the HMI (Human Interface) to enhance the user experience, achieving inter-domain collaboration in a multi-OS environment. After detection, the vehicle automatically exits factory mode, clears temporary data, and switches to user mode, achieving a "zero-residue" reset in a pure software manner, ensuring the purity of the vehicle's factory state.

[0006] According to some embodiments of the present invention, the factory mode is equipped with access protection, allowing access only through a preset key or hardware trigger; the EOL detection service supports automatic background operation and provides a front-end interactive interface for displaying detection progress, detection results and operation guidance.

[0007] According to some embodiments of the present invention, the workstation sensing unit is one or more of an RFID reader, a UWB base station, a Bluetooth beacon, or a visual positioning device; the built-in sensing module is an RFID reader, a UWB receiver module, or a Bluetooth module that is matched with the workstation sensing unit.

[0008] According to some embodiments of the present invention, the cockpit domain runs the Android system, and the vehicle control domain runs the QNX system or the Linux system; the abstract communication middleware shields the underlying differences between different operating systems, provides a unified API interface, and supports dynamic adaptation to different operating system versions. When the vehicle system is upgraded, only the middleware adaptation layer needs to be updated.

[0009] According to some embodiments of the present invention, if a test fails during the execution of the test operation, the vehicle-mounted system automatically pauses the test and displays the fault code, fault location, and repair suggestions on the HMI interface; after the operator completes the troubleshooting according to the repair suggestions, the vehicle-mounted system continues to execute the remaining test process; if the final test fails, the vehicle-mounted system receives a rework marking instruction issued by the production line cloud / edge server and marks the vehicle as pending rework.

[0010] According to some embodiments of the present invention, the detection operations include: ECU online status detection, fault code reading and clearing, sensor signal detection, actuator function testing, parameter calibration and configuration writing.

[0011] According to some embodiments of the present invention, the method further includes: receiving a test script upgrade package remotely issued by the production line cloud / edge server, and automatically upgrading the EOL test service on the vehicle terminal in the background; wherein the production line cloud / edge server provides test script management, workstation management, test data statistics and fault analysis functions.

[0012] According to some embodiments of the present invention, the vehicle-mounted system uploads information to the production line cloud / edge server via in-vehicle Ethernet or 5G / C-V2X wireless communication.

[0013] According to a second aspect of the present invention, a vehicle off-line inspection system based on an on-board diagnostic system includes an in-vehicle system, an on-board diagnostic module, a workstation sensing unit, and a production line cloud / edge server; the in-vehicle system is configured to perform the vehicle off-line inspection method as described in any one of claims 1 to 8.

[0014] According to some embodiments of the present invention, the vehicle infotainment system includes: The EOL testing service module is natively developed for the vehicle system and integrates UDS, OBD and DoIP diagnostic protocols. It is deeply integrated with the vehicle diagnostic module and is used as a diagnostic host to perform testing operations in factory mode. The workstation identification module is used to obtain the workstation ID by scanning the workstation sensing unit through the built-in sensing module; The communication module is used for sending and receiving data with the production line cloud / edge server; An abstract communication middleware module, deployed in the vehicle system, is used to shield the differences between the operating systems of the cockpit domain and the vehicle control domain, and provide a unified API to enable inter-domain collaboration. The factory mode management module is used to control the vehicle to enter factory mode through hardware triggering or key verification, and automatically exit factory mode, clear temporary data, and switch to user mode after the detection is completed.

[0015] According to a fourth aspect of the present invention, a computer-readable storage medium stores computer-executable instructions for causing a computer to perform the control method.

[0016] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. Attached Figure Description

[0017] The present invention will be further described below with reference to the accompanying drawings and embodiments, wherein: Figure 1 This is a diagram of the overall system architecture. Figure 2 This is a flowchart of the testing process; Figure 3 Diagram of a multi-operating system collaborative architecture; Figure 4 This is a flowchart of a hardware-free offline testing method for vehicles based on an on-board diagnostic system. Detailed Implementation

[0018] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0019] In the description of this invention, it should be understood that the orientation descriptions, such as up, down, etc., are based on the orientation or positional relationship shown in the drawings and are only for the convenience of describing this invention and simplifying the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention.

[0020] In the description of this invention, "multiple" refers to two or more. The use of "first" and "second" is for distinguishing technical features only and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or the order in which the indicated technical features are presented.

[0021] In the description of this invention, unless otherwise explicitly defined, terms such as "setting," "installing," and "connecting" should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this invention in conjunction with the specific content of the technical solution.

[0022] The following will be combined with the appendix Figures 1 to 4The technical solution of the present invention will be clearly and completely described below. Obviously, the embodiments described below are some embodiments of the present invention, not all embodiments.

[0023] It should be noted that, in this embodiment of the invention, the vehicle-mounted infotainment system (IVI) refers to the in-vehicle infotainment system (IVI) integrated into the vehicle and its associated in-vehicle computing platform, which includes at least one or more processors, memory, and communication interfaces, capable of running an operating system and executing applications. The vehicle-mounted diagnostic module refers to the diagnostic function module integrated into the vehicle, supporting diagnostic protocol stacks such as UDS (Unified Diagnostic Service), OBD (On-Board Diagnostics), and DoIP (DoIP-based Diagnostics). The production line cloud / edge server refers to a cloud server or edge computing server deployed in the automotive production workshop for data interaction with the vehicle-mounted infotainment system. The workstation sensing unit refers to a physical identifier or signal transmitting device deployed at each testing workstation for uniquely identifying the workstation.

[0024] Example 1 This embodiment provides a vehicle hardware-free offline testing method based on an on-board diagnostic system, applicable to in-vehicle infotainment systems, such as... Figure 4 As shown, the method includes the following steps: Step S101: After the vehicle is powered on, it enters factory mode through hardware triggering or key verification and starts the natively developed EOL detection service.

[0025] In this embodiment, when the vehicle is powered on for the first time after final assembly, the vehicle's infotainment system initiates a bootloader. During the boot process, the system detects hardware trigger signals. For example, production line operators can determine whether to enter factory mode by pressing a specific combination of physical buttons on the vehicle, such as pressing and holding the "volume +" and "power" buttons for 3 seconds, or by applying a specific electrical signal through the diagnostic interface. If a valid hardware trigger signal is detected, the system bootloader jumps to the factory mode boot process.

[0026] As an alternative access method, after startup, the vehicle system sends a key verification request to the production line cloud / edge server via the production line LAN or 5G / C-V2X wireless network. Upon successful verification, the server returns a confirmation command to the vehicle system, which then enters factory mode. Factory mode is protected by access controls, allowing access only via the aforementioned preset key or hardware trigger to prevent unauthorized access from outside the facility that could lead to misuse of detection functions or tampering with vehicle data.

[0027] After the vehicle's infotainment system enters factory mode, it automatically starts the natively developed End-of-Life (EOL) diagnostic service. This EOL diagnostic service is a service program natively developed based on the vehicle's operating system (such as Android). It integrates the UDS diagnostic protocol, OBD diagnostic protocol, and DoIP diagnostic protocol, and is deeply integrated with the on-board diagnostic module. Through this EOL diagnostic service, the vehicle's infotainment system directly acts as the diagnostic host and interactive terminal of the diagnostic system, establishing stable diagnostic communication connections with each of the vehicle's electronic control units (ECUs) via in-vehicle Ethernet, CAN bus, or CAN FD bus. In this embodiment, the EOL diagnostic service runs automatically in the background after startup, while simultaneously displaying a diagnostic preparation interface on the vehicle's HMI (Human-Machine Interface) to indicate the current diagnostic status to the operator.

[0028] Step S102: Obtain the workstation ID by scanning the workstation sensing unit deployed at the workstation through the built-in sensing module, upload the vehicle VIN code, its own software and hardware version and workstation ID to the production line cloud / edge server, and receive the detection script issued by the production line cloud / edge server according to the workstation ID.

[0029] In this embodiment, after the vehicle enters the inspection station, the vehicle's infotainment system scans the station's sensing units deployed there using its built-in sensing module to obtain the station ID and area information, thus completing automatic station identification. Specifically: In one implementation, the workstation sensing unit is an RFID reader, and correspondingly, the vehicle's infotainment system has an RFID reader built in. When the vehicle enters the inspection workstation and stops at the designated location, the vehicle's infotainment system actively reads the RFID tags deployed on the floor or side of the workstation using the RFID reader to obtain the unique workstation ID-2. In another implementation, the workstation sensing unit is a UWB base station, and the vehicle's infotainment system has a built-in UWB receiving module. It uses UWB positioning technology to obtain the area information of the vehicle's current workstation and maps it to the corresponding workstation ID-1. In yet another implementation, the workstation sensing unit is a Bluetooth beacon. The vehicle's infotainment system scans and identifies the broadcast signal of the workstation's Bluetooth beacon using its built-in Bluetooth module, and parses out the workstation ID-35. In yet another implementation, the workstation sensing unit is a visual positioning device (such as a QR code recognition camera). The vehicle's infotainment system scans the QR code image on the floor or wall of the workstation using its onboard camera to identify the workstation ID.

[0030] After obtaining the workstation ID, the vehicle-mounted system automatically collects the following information: the vehicle's VIN (Vehicle Identification Number), the system's own software and hardware version number, and the current workstation ID. The system then packages and uploads this information to the production line cloud / edge server-1 via in-vehicle Ethernet or 5G / C-V2X wireless communication.

[0031] After receiving the information uploaded by the vehicle's infotainment system, the production line cloud / edge server matches the corresponding inspection process for that workstation in the server's database based on the workstation ID. For example, workstation ID "EOL-01" corresponds to the powertrain inspection process, "EOL-02" to the body system inspection process, and "EOL-03" to the final inspection process. Once the server matches the corresponding inspection process, it sends the corresponding inspection script and diagnostic sequence to the vehicle's infotainment system. The vehicle's infotainment system receives the inspection script from the server and automatically matches and triggers the inspection process, requiring no manual intervention throughout the entire process.

[0032] Step S103: The cockpit domain and vehicle control domain are scheduled through an abstract communication middleware. The vehicle control domain performs diagnostic operations with high safety requirements, while the cockpit domain provides the HMI interactive interface.

[0033] In this embodiment, the vehicle infotainment system includes a cockpit domain and a vehicle control domain. The cockpit domain runs the Android operating system and is responsible for providing the HMI interface and multimedia functions; the vehicle control domain runs the QNX system or Linux system and is responsible for performing vehicle control and diagnostic operations with high safety requirements.

[0034] To address communication and collaboration issues between different operating systems, the vehicle infotainment system deploys an abstract communication middleware. This middleware shields the underlying differences between Android and QNX / Linux systems, providing a unified API (Application Programming Interface) to upper-layer applications, enabling unified calls and communication across multiple operating system platforms. The middleware supports dynamic adaptation to different operating system versions. When the vehicle infotainment system is upgraded, there is no need to modify the core detection logic; only the middleware adaptation layer needs to be updated, thereby improving the compatibility and maintainability of the solution.

[0035] During the testing process, the vehicle's infotainment system coordinates the work between the cockpit domain and the vehicle control domain through an abstract communication middleware. Specifically, the vehicle control domain is responsible for performing diagnostic operations with high safety requirements, including ECU calibration, configuration writing, and fault code clearing—operations with high real-time and safety requirements. The cockpit domain provides a unified HMI interface, displaying testing steps, progress, results, fault codes, and repair suggestions in real time on the vehicle's screen, while also receiving anomaly handling commands input by operators via the touchscreen. Through this inter-domain collaboration mechanism, integrated coordination between testing execution and interactive display is achieved.

[0036] Step S104: Drive the on-board diagnostic module to perform the test operation according to the test script, collect the result data of each test item and upload it to the production line cloud / edge server, and receive the test pass instruction from the production line cloud / edge server.

[0037] In this embodiment, after the in-vehicle computer receives the detection script sent by the server, it drives the on-vehicle diagnostic module through the EOL detection service and sequentially executes the detection operations according to the script sequence. Specifically, the detection operations include but are not limited to: ECU online status detection - checking whether each ECU of the whole vehicle is online and the communication is normal; fault code reading and clearing - reading the fault codes of each ECU and clearing the historical fault codes before detection; sensor signal detection - reading the signal values of each sensor and judging whether they are within a reasonable range; actuator function test - sending control commands to each actuator and verifying whether the response is correct; parameter calibration - calibrating the calibration parameters in the ECU; configuration writing - writing vehicle configuration information to the ECU.

[0038] During the detection process, the in-vehicle computer real-time collects the result data of each detection item, including the detection pass / fail status, specific values, fault codes, etc., and synchronously uploads them to the production line cloud / edge server through in-vehicle Ethernet or 5G / C-V2X wireless communication. The server analyzes the received real-time data and automatically determines whether each detection item is qualified.

[0039] If a detection failure occurs during the detection process, such as abnormal ECU communication, sensor signal overrun, incorrect actuator response, etc., the in-vehicle computer automatically pauses the detection process and displays the fault code, fault location and repair suggestions on the HMI interface. After the operator completes the troubleshooting according to the suggestions displayed on the HMI interface, the operator can click the continue detection button on the HMI interface, and the in-vehicle computer continues to execute the remaining detection process after responding to the operation instruction.

[0040] When all detection items are executed and all are qualified, the production line cloud / edge server generates a complete detection report and sends the detection qualified instruction to the in-vehicle computer. The in-vehicle computer receives the detection qualified instruction feedback from the production line cloud / edge server and confirms that the whole vehicle passes the offline detection.

[0041] Step S105: According to the detection qualified instruction, automatically exit the factory mode, clear the temporary data generated during the detection process, and switch to the user mode.

[0042] In this embodiment, after the in-vehicle computer receives the detection qualified instruction sent by the production line cloud / edge server, it automatically performs the following operations: First, the in-vehicle computer closes the background operation of the EOL detection service, stops all diagnostic communication sessions, and disconnects the detection connection with the on-vehicle diagnostic module. Secondly, the in-vehicle computer clears all temporary data generated during the detection process, including the cache of the detection script, the log of the diagnostic session, the temporary configuration parameters, etc., to ensure that no detection-related data or configuration remains in the user mode. Then, the in-vehicle computer exits the factory mode and switches the system operation mode to the user mode. In the user mode, the in-vehicle computer restores the regular user function interface, and the vehicle can normally drive away from the detection station and enter the next production link or be stored in the warehouse.

[0043] At this point, the closed-loop inspection of the entire vehicle off the production line is complete, and the vehicle is delivered to the next process in normal user mode.

[0044] If the inspection fails, meaning that there are no test items that fail and the operator cannot complete the repair on-site, the vehicle will be marked as pending repair, and the inspection report will be pushed to the repair station simultaneously to facilitate subsequent repair and re-inspection.

[0045] This embodiment reduces the hardware cost per workstation by eliminating dedicated electrical testing hardware such as external diagnostic instruments and related wiring. It also reduces equipment calibration, maintenance, and depreciation costs, lowers production line modification investment, and enables fully automated triggering and execution of the testing process. There is no need for manual plugging and unplugging of OBD connectors or selection of workstations, shortening the testing cycle and avoiding problems such as poor contact and operational errors.

[0046] Example 2 This embodiment is basically the same as Embodiment 1, except that the specific implementation method of workstation identification is different.

[0047] In this embodiment, the workstation sensing unit employs a combined deployment of visual positioning devices (such as QR code recognition cameras) and UWB base stations. After a vehicle enters the inspection station, the vehicle-mounted unit first obtains the approximate location of the vehicle within the production line via the UWB receiving module, initially determining the workstation's location. Subsequently, it scans the QR code image on the workstation floor or wall using the vehicle's onboard camera to accurately identify the unique ID of the current workstation. This combined identification method ensures both the accuracy and efficiency of workstation identification, avoiding the identification failures that may occur with a single identification method in complex production line environments.

[0048] Example 3 This embodiment is basically the same as Embodiment 1, except that the specific implementation method of multi-operating system collaboration is different.

[0049] In this embodiment, instead of the abstract communication middleware solution, containerization technology is used to achieve unified interaction and collaboration between the cockpit domain and the vehicle control domain. Specifically, the EOL detection service is encapsulated as a container image and deployed in the container runtime environment of the vehicle system. The container runtime shields the differences in the underlying operating systems, allowing the same detection service container to run seamlessly on Android or QNX / Linux systems. The cockpit domain and the vehicle control domain communicate through a virtual network between containers to issue detection commands and report detection results. This alternative solution also achieves the technical effect of shielding operating system differences and enabling inter-domain communication, and is an equivalent alternative to the abstract communication middleware of this invention.

[0050] Example 4 This embodiment is basically the same as Embodiment 1, except for the alternative to the diagnostic host.

[0051] In this embodiment, the EOL detection service and the on-board diagnostic module are not integrated into the vehicle's infotainment system, but rather into the on-board T-Box (Telematics Terminal) or domain controller. After the vehicle is powered on, the T-Box or domain controller enters factory mode via hardware triggering or key verification, initiating the EOL detection service. As the diagnostic host, it establishes communication with each ECU in the vehicle via the in-vehicle network. The vehicle's infotainment system only acts as an HMI (Host Interface) terminal, connecting to the T-Box or domain controller via the in-vehicle Ethernet to receive and display the detection progress and results. This alternative replaces the diagnostic host from the vehicle's infotainment system with a T-Box or domain controller, but it essentially still falls under the core idea of ​​replacing external hardware with on-board equipment, thus falling within the scope of this invention.

[0052] This embodiment provides a vehicle off-line testing system based on an on-board diagnostic system, such as... Figure 1 As shown, the system includes a vehicle infotainment system 100, an on-board diagnostic module 200, a workstation sensing unit 300, and a production line cloud / edge server 400.

[0053] The following combination Figure 1 A detailed description of each component and its connections is provided.

[0054] The vehicle infotainment system 100, integrated into the vehicle, serves as the core control and interaction center of this system. The vehicle infotainment system 100 includes at least one processor, memory, communication interface, and human-machine interface display. The vehicle infotainment system 100 runs an operating system, such as Android, QNX, or Linux, and natively features an EOL detection service that integrates the UDS diagnostic protocol, OBD diagnostic protocol, and DoIP diagnostic protocol. The vehicle infotainment system 100 is configured to execute the detection methods described in any of Embodiments 1 to 4.

[0055] Specifically, after the vehicle is powered on, the vehicle infotainment system 100 enters factory mode via hardware triggering or key verification, and automatically starts the EOL (End of Service) detection service in factory mode. The vehicle infotainment system 100 establishes a communication connection with the on-board diagnostic module 200 via in-vehicle Ethernet, CAN bus, or CAN FD bus, and then performs diagnostic communication with each ECU of the vehicle through the on-board diagnostic module 200.

[0056] The on-board diagnostic module 200, integrated into the vehicle, communicates with the vehicle infotainment system 100 via the in-vehicle network. The on-board diagnostic module 200 has a complete diagnostic protocol stack, supporting UDS diagnostic services such as Service 10 - Diagnostic Session Control, Service 11 - ECU Reset, Service 22 - Read Data, Service 2E - Write Data, and Service 31 - Routine Control; OBD diagnostic services such as reading freeze frames and reading oxygen sensor monitoring data; and DoIP diagnostic services, which are IP-based diagnostic communication. Driven by the vehicle infotainment system 100, the on-board diagnostic module 200 performs diagnostic operations on each ECU of the vehicle.

[0057] The workstation sensing unit 300 is deployed at each inspection workstation on the production line. At least one workstation sensing unit 300 is deployed at each inspection workstation, and each workstation sensing unit 300 corresponds to a unique workstation ID and inspection process. In this embodiment, the workstation sensing unit 300 can adopt any one or more of the following combinations: In one implementation, the workstation sensing unit 300 is an RFID tag or RFID reader, deployed on the floor or side of the workstation, storing the unique ID information of the workstation, and communicating with the vehicle system 100 through RFID radio frequency signals.

[0058] As another implementation method, the workstation sensing unit 300 is a UWB base station deployed around the workstation. It communicates with the vehicle system 100 through UWB positioning signals. The vehicle system 100 obtains its own location through UWB positioning technology and maps it to the corresponding workstation ID.

[0059] As another implementation, the workstation sensing unit 300 is a Bluetooth beacon deployed in the workstation area, continuously broadcasting a Bluetooth signal containing the workstation ID, and the vehicle system 100 obtains the workstation ID by scanning via Bluetooth.

[0060] As another implementation method, the workstation sensing unit 300 is a visual positioning identifier, such as a QR code pattern, deployed on the workstation floor or wall. The vehicle system 100 collects and identifies the identifier through the vehicle camera to obtain the workstation ID.

[0061] The production line cloud / edge server 400 is deployed in the production workshop and communicates with the vehicle system 100 via in-vehicle Ethernet, 5G, or C-V2X wireless communication networks. The production line cloud / edge server 400 includes at least one processor, memory, and communication interface. The server 400 stores the testing procedures, testing scripts, and diagnostic sequences corresponding to each workstation.

[0062] In this embodiment, server 400 receives the vehicle VIN code, vehicle hardware and software version, and workstation ID uploaded by vehicle infotainment system 100. It matches the corresponding testing process based on the workstation ID and sends the corresponding testing script to vehicle infotainment system 100. Server 400 also receives the test result data uploaded by vehicle infotainment system 100, analyzes the data, determines whether the test items are qualified, and after all test items are qualified, issues a test qualification command to vehicle infotainment system 100 and generates a complete test report, which is stored in the server's memory for data traceability. The test report is associated with information such as vehicle VIN code, workstation ID, and testing time.

[0063] In addition, the production line cloud / edge server 400 also provides functions such as inspection script management, workstation management, inspection data statistics and fault analysis. It supports managers to remotely issue inspection script upgrade packages through the server to update and optimize the inspection process.

[0064] The following section describes the working process of this system using a complete testing procedure.

[0065] First, after the vehicle completes final assembly, it enters the testing station. Upon powering on the vehicle, the vehicle infotainment system 100 enters factory mode via hardware triggering or key verification, initiating the natively developed EOL (End-of-Life) testing service. The vehicle infotainment system 100 uses its built-in sensing module to scan the station sensing units 300 deployed at the current station and obtain the station ID.

[0066] Then, the vehicle infotainment system 100 collects the vehicle's VIN code, its own software and hardware version, and workstation ID, and uploads it to the production line cloud / edge server 400 via in-vehicle Ethernet or 5G / C-V2X wireless communication. The server 400 matches the corresponding testing process according to the workstation ID and sends the corresponding testing script to the vehicle infotainment system 100.

[0067] Next, the vehicle infotainment system 100, based on the received test script, drives the on-board diagnostic module 200 through the EOL test service to execute test operations according to the script sequence. During the test, the vehicle infotainment system 100 collects the result data of each test item in real time and uploads it synchronously to the server 400. The server 400 analyzes the data and automatically determines whether the test items are qualified.

[0068] If a test fails, the vehicle's infotainment system 100 will automatically pause the test and display the fault code, fault location, and repair suggestions on the HMI interface. After the operator completes the troubleshooting according to the suggestions, the vehicle's infotainment system 100 will continue to execute the remaining test procedures.

[0069] Finally, once all test items pass, server 400 generates a complete test report and issues a test pass command to vehicle infotainment system 100. Upon receiving the command, vehicle infotainment system 100 automatically exits factory mode, clears temporary data generated during the testing process, switches to user mode, and completes the closed loop of vehicle off-line testing.

[0070] The aforementioned system achieves deep integration of the vehicle infotainment system 100 and the on-board diagnostic module 200, using the vehicle infotainment system 100 as the diagnostic host and interactive terminal. This completely eliminates the need for external electrical testing hardware, enabling purely software-based off-line testing. The workstation sensing unit 300 achieves automatic vehicle-to-workstation binding and process matching without manual intervention. The production line cloud / edge server 400 enables centralized management and remote distribution of testing scripts, as well as centralized storage and analysis of testing data, facilitating data traceability and production line optimization.

[0071] This embodiment provides a vehicle hardware-free offline testing system based on an on-board diagnostic system, and further includes the internal functional modules of the vehicle system 100 in this embodiment.

[0072] like Figure 3 As shown, the vehicle system 100 includes: an EOL detection service module 110, a workstation identification module 120, a communication module 130, an abstract communication middleware module 140, and a factory mode management module 150.

[0073] The EOL detection service module 110 is natively developed on the operating system of the vehicle system 100 and integrates the UDS diagnostic protocol, OBD diagnostic protocol, and DoIP diagnostic protocol. The EOL detection service module 110 is deeply integrated with the on-board diagnostic module 200 and establishes a communication connection with the on-board diagnostic module 200 through in-vehicle Ethernet, CAN bus, or CAN FD bus.

[0074] EOL (End-of-Life) testing service module 110 is used as a diagnostic host to perform testing operations in factory mode. Specifically, when the factory mode management module 150 controls the vehicle to enter factory mode, the EOL testing service module 110 automatically starts and runs in the background. The EOL testing service module 110 receives the testing script forwarded from the production line cloud / edge server 400 by the communication module 130, parses and executes the diagnostic instruction sequence in the script, and drives the on-board diagnostic module 200 to perform testing operations on each ECU. The testing operations include, but are not limited to: ECU online status detection, fault code reading and clearing, sensor signal detection, actuator function testing, parameter calibration and configuration writing.

[0075] The EOL testing service module 110 is also used to stop all diagnostic communication sessions, disconnect from the on-board diagnostic module 200, and release testing resources after the testing is completed, according to the control instructions of the factory mode management module 150.

[0076] The workstation identification module 120 is connected to the built-in sensing module of the vehicle system 100. The sensing module may be an RFID reader, a UWB receiver module, a Bluetooth module, or an in-vehicle camera. The workstation identification module 120 is used to scan the workstation sensing units 300 deployed at each inspection workstation through the sensing module to obtain the workstation ID and area information of the current vehicle's workstation.

[0077] Specifically, the working process of the workstation identification module 120 is as follows: In one implementation, the workstation identification module 120 reads the workstation ID data from the workstation RFID tag using an RFID reader to complete the workstation identification.

[0078] As another implementation, the workstation identification module 120 receives the positioning signal from the UWB base station through the UWB receiving module, calculates the current position coordinates of the vehicle in the production line, and obtains the corresponding workstation ID by matching according to the preset workstation area mapping relationship table.

[0079] In another implementation, the workstation identification module 120 scans the broadcast signal of the Bluetooth beacon via the Bluetooth module and parses the workstation ID from the broadcast data packet. In yet another implementation, the workstation identification module 120 captures a QR code image via a vehicle-mounted camera, decodes the image, and identifies the workstation ID.

[0080] After the workstation identification module 120 identifies the workstation ID, it transmits the workstation ID information to the communication module 130 for uploading to the server 400.

[0081] The communication module 130 is located in the vehicle infotainment system 100 and is used to send and receive data with the production line cloud / edge server 400. The communication module 130 supports multiple communication methods, including in-vehicle Ethernet communication, 5G cellular communication and C-V2X (cellular vehicle-to-everything) communication.

[0082] The communication module 130 is used to: upload the vehicle VIN code, the vehicle's own hardware and software version, and the workstation ID obtained by the workstation identification module 120 to the production line cloud / edge server 400; receive the inspection script issued by the server 400 according to the workstation ID; upload the result data of each inspection item to the server 400 in real time during the inspection process; receive the inspection pass instruction or rework mark instruction fed back by the server 400; and receive the inspection script upgrade package remotely issued by the server 400.

[0083] The abstract communication middleware module 140 is deployed in the vehicle infotainment system 100, located between the operating system layer and the application layer. The vehicle infotainment system 100 includes a cockpit domain and a vehicle control domain, where the cockpit domain runs the Android system and the vehicle control domain runs the QNX system or Linux system. The abstract communication middleware module 140 is used to shield the underlying differences between the different operating systems in the cockpit domain and the vehicle control domain, providing a unified API interface to upper-layer applications such as the EOL detection service module 110, enabling unified calling and communication across multiple operating system platforms.

[0084] Specifically, the abstract communication middleware module 140 adopts an adapter pattern or proxy pattern design, providing different adaptation layer implementations for different operating systems. When the EOL detection service module 110 needs to call functions of the vehicle control domain (such as ECU calibration, configuration writing, and other operations with high safety requirements), it initiates a call request through the unified API interface of the abstract communication middleware module 140. The abstract communication middleware module 140 automatically routes the request to the vehicle control domain for execution and returns the execution result to the EOL detection service module 110.

[0085] The abstract communication middleware module 140 also supports dynamic adaptation to different operating system versions. When the vehicle system is upgraded (such as an Android system version upgrade or a QNX system version upgrade), there is no need to modify the core detection logic of the EOL detection service module 110. Only the adaptation layer code of the corresponding system in the abstract communication middleware module 140 needs to be updated to ensure the normal operation of the detection service, which greatly improves the compatibility and maintainability of the solution.

[0086] Furthermore, the abstract communication middleware module 140 is also used for inter-domain collaborative control between the cockpit domain and the vehicle control domain. The vehicle control domain is responsible for performing diagnostic operations with high safety requirements, while the cockpit domain is responsible for providing the HMI interface, displaying the testing steps, real-time progress, testing results, fault codes, and repair suggestions, and receiving abnormal handling instructions from the operator. Through the abstract communication middleware module 140, efficient data exchange and command collaboration are achieved between the cockpit domain and the vehicle control domain, completing the integrated coordination of testing execution and interactive display.

[0087] The factory mode management module 150 is used to control the switching of the operating modes of the vehicle infotainment system 100. The factory mode management module 150 provides two triggering methods for entering factory mode: one is a hardware triggering method—the factory mode management module 150 monitors specific hardware pins or physical button combinations of the vehicle infotainment system 100. When a valid hardware trigger signal is detected (such as a specific button combination being pressed and held for more than 3 seconds, or a predetermined level signal being applied to a specific pin of the diagnostic interface), the factory mode management module 150 controls the vehicle infotainment system 100 to enter factory mode.

[0088] Another method is key verification. After the vehicle system 100 is started, the factory mode management module 150 sends a key verification request to the production line cloud / edge server 400 through the communication module 130. After the server 400 verifies the validity of the key, it returns a verification pass instruction to the vehicle system. The factory mode management module 150 controls the vehicle system 100 to enter the factory mode according to the instruction.

[0089] After the vehicle's infotainment system enters factory mode, the factory mode management module 150 automatically triggers the EOL detection service module 110 to start running.

[0090] After the test is completed, the factory mode management module 150 receives the test pass instruction from the server 400 forwarded by the communication module 130, and automatically performs the following operations according to the instruction: shuts down the EOL test service module 110, clears all temporary data generated during the test (including test script cache, diagnostic session logs, temporary configuration parameters, etc.), and switches the vehicle infotainment system 100 from factory mode to user mode. In user mode, the vehicle infotainment system 100 restores the normal user function interface, and the vehicle can drive away from the test station normally.

[0091] If the inspection fails, the factory mode management module 150 receives the rework marking instruction from the server 400 and marks the vehicle as pending rework, but does not execute the operation of exiting factory mode so that the factory mode can be used for re-inspection at the rework station later.

[0092] The following section describes the collaborative working process of each module in this embodiment using a complete detection process.

[0093] After the vehicle is powered on, the factory mode management module 150 detects the hardware trigger signal or key verification result, controls the vehicle to enter factory mode, and automatically starts the EOL detection service module 110.

[0094] The workstation identification module 120 scans the workstation sensing unit 300 through its built-in sensing module to obtain the workstation ID, and then transmits the workstation ID to the communication module 130. The communication module 130 uploads the workstation ID, along with the vehicle VIN code and the vehicle infotainment software and hardware version, to the server 400.

[0095] The communication module 130 receives the detection script from the server 400 and passes it to the EOL detection service module 110. The EOL detection service module 110 parses the detection script and needs to call the functions of the cockpit domain or vehicle control domain through the abstract communication middleware module 140. The abstract communication middleware module 140 routes the instructions to the corresponding domain for execution based on the operation type. Diagnostic operations with high safety requirements are executed by the vehicle control domain, while HMI interactive displays are executed by the cockpit domain.

[0096] During the testing process, the EOL testing service module 110 transmits the testing results to the communication module 130 in real time, and the communication module 130 uploads them to the server 400. The server 400 analyzes the data and determines the testing results, and returns the determination instruction through the communication module 130.

[0097] After all test items pass, the communication module 130 receives the test pass instruction from the server 400. The factory mode management module 150 controls the vehicle to exit the factory mode, clear temporary data, and switch to user mode according to the instruction, thus completing the test closed loop.

[0098] In this embodiment, an alternative to the abstract communication middleware module 140 is to use containerization technology to encapsulate the EOL detection service module 110 as a container image and deploy it in the container runtime environment of the vehicle system 100. This utilizes container technology to shield the differences in the underlying operating system, achieving unified interaction and collaboration between the cockpit domain and the vehicle control domain. This alternative also falls within the protection scope of this invention.

[0099] In this embodiment, an alternative to the factory mode management module 150 is to integrate the factory mode entry logic into the bootloader of the vehicle system 100, detect the trigger signal in the earliest stage of system startup, and decide whether to enter the factory mode to further improve safety and reliability.

[0100] This embodiment targets a pure electric passenger vehicle that uses the Android 12 system in the intelligent cockpit domain and the QNX 7.1 system in the vehicle control domain. The specific implementation environment is as follows: (1) Vehicle side: The vehicle unit has built-in EOL detection service, abstract communication middleware and UWB receiving module; the vehicle diagnostic module integrates UDS and DoIP protocols and supports CAN FD and Ethernet communication; the vehicle supports factory mode and needs to be triggered by the production line special key to start.

[0101] (2) Workstation: Each testing workstation is equipped with a UWB base station (corresponding to a unique workstation ID); there are no external electrical testing equipment at the workstation, only production line server terminals are deployed to monitor the testing status.

[0102] (3) Server side: The production line edge server is used to deploy the EOL inspection management platform, which supports workstation management, inspection script distribution, inspection result storage, data traceability and fault analysis, and can be connected with the MES system of car manufacturers.

[0103] Step 1: After the vehicle rolls off the production line, it enters the testing station. The operator inputs the key into the vehicle's computer using the production line's dedicated equipment. After the computer verifies the key, it automatically enters factory mode and starts the EOL (End of Service) testing service. The EOL service automatically initializes the on-board diagnostic module and establishes communication connections with various ECUs, such as the powertrain, chassis, body, and cabin ECUs.

[0104] Step 2: The vehicle's infotainment system scans the UWB base station at the workstation using its built-in UWB receiver module to obtain workstation ID=05 (final inspection workstation). At the same time, it collects the vehicle's VIN code (such as LVXXX123456789012) and the vehicle's software and hardware version information, and uploads them to the edge server via the in-vehicle Ethernet.

[0105] Step 3: After receiving the information, the edge server matches the final inspection process according to workstation ID=05 and sends the final inspection script (including ECU fault detection, light / wiper / window / door lock function test, battery management system calibration, charging function test and other test items) to the vehicle system.

[0106] Step 4: The vehicle's infotainment system calls the diagnostic interface of the QNX vehicle control domain through the abstract communication middleware to execute the final inspection script: ① Read the fault codes of each ECU to confirm that there are no faults; ② Control the lights (low beam, high beam, turn signals, etc.), wipers, windows, and door locks to operate sequentially and test the actuator functions; ③ Perform parameter calibration on the battery management system and verify the charging voltage and current parameters; ④ Test the on-board charging function and verify the reliability of the charging interface communication and charging start-up.

[0107] Step 5: The Android vehicle HMI interface displays the progress of each test item in real time (e.g., "Lighting test: 80%)", and the test data is uploaded to the edge server synchronously. When an abnormality is detected in the left rear window lifting mechanism, the vehicle system automatically pauses the test, displays the fault code "B1234" and the repair suggestion "Check the left rear window lifting motor and wiring". After the operator troubleshoots and repairs the fault, they can click the "Continue test" button on the interface, and the vehicle system will continue to perform the remaining test items.

[0108] Step 6: After all test items pass, the edge server generates a test report, stores it in association with the VIN code and workstation ID, and sends a test pass command to the vehicle-mounted system. After receiving the command, the vehicle-mounted system automatically clears the temporary test data, exits the factory mode, switches to the user mode, and issues a test pass prompt tone.

[0109] Step 7: After the operator confirms that the inspection is qualified, the vehicle is released and the edge server synchronizes the inspection report to the MES system to complete the vehicle off-line inspection.

[0110] Furthermore, it also includes factory mode protection: in addition to the production line-specific key, factory mode can also be started via hardware trigger, such as connecting the production line-specific OBD trigger line, providing double protection to prevent unauthorized access; if the factory mode is forcibly exited during the testing process, the vehicle's system will automatically clear the testing data, the testing process will fail, and the testing needs to be restarted.

[0111] If a communication interruption occurs during the testing process, such as the vehicle's infotainment system losing connection with the server, the system will save the current testing progress and automatically resume data transmission and testing once communication is restored. If the number of failed tests exceeds a preset threshold (e.g., 3 times), the system will lock the testing function, requiring administrators to unlock it and retest.

[0112] This embodiment can be adapted to both fuel vehicles and hybrid vehicles. Only the detection script needs to be updated to cover the detection requirements of different vehicle models. For the cockpit domain vehicle system using Linux, only the adaptation layer of the abstract communication middleware needs to be updated, without modifying the core detection logic.

[0113] This invention also provides a vehicle, including a memory, a processor, and a program stored in the memory and executable on the processor. When the program is executed by the processor, it implements the aforementioned method for hardware-free offline vehicle testing based on an on-board diagnostic system.

[0114] The processor can be implemented using a general-purpose central processing unit (CPU), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0115] The memory can be implemented in the form of read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory and is called and executed by the processor.

[0116] The vehicles also include the aforementioned vehicle off-line inspection system. Specifically, the vehicles can be private cars, such as sedans, SUVs, MPVs, or pickup trucks. They can also be commercial vehicles, such as vans, buses, small trucks, or large semi-trailers. The vehicles can be gasoline-powered or new energy vehicles. When a vehicle is a new energy vehicle, it can be a hybrid or a pure electric vehicle.

[0117] According to an embodiment of the present invention, a computer-readable storage medium is stored thereon, which, when executed by a processor, implements the above-described method for hardware-free offline vehicle testing based on an on-board diagnostic system.

[0118] The computer-readable storage medium of this invention can be any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0119] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0120] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0121] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0122] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0123] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of the present invention.

Claims

1. A method for vehicle off-line testing based on an on-board diagnostic system, characterized in that, Applied to in-vehicle systems, the vehicle off-line inspection method includes: After the vehicle is powered on, it enters factory mode through hardware triggering or key verification and starts the natively developed EOL detection service. The EOL detection service integrates UDS diagnostic protocol, OBD diagnostic protocol and DoIP diagnostic protocol, and is deeply integrated with the vehicle diagnostic module. It establishes communication with each ECU of the vehicle through in-vehicle Ethernet, CAN bus or CAN FD bus. The system obtains the workstation ID by scanning the workstation sensing unit deployed at the workstation using the built-in sensing module, uploads the vehicle VIN code, its own software and hardware version and the workstation ID to the production line cloud / edge server, and receives the detection script matched and issued by the production line cloud / edge server according to the workstation ID. The cockpit domain and vehicle control domain are scheduled through an abstract communication middleware. The vehicle control domain performs diagnostic operations with high safety requirements, while the cockpit domain provides the HMI interactive interface. The on-board diagnostic module is driven by the detection script to perform detection operations, collect the result data of each detection item and upload it to the production line cloud / edge server, and receive the detection pass instruction from the production line cloud / edge server. Based on the qualified test instruction, automatically exit factory mode, clear temporary data generated during the test, and switch to user mode.

2. The vehicle off-line inspection method according to claim 1, characterized in that, The factory mode is protected by access permissions, allowing entry only via a preset key or hardware trigger. The EOL detection service supports automatic background operation and provides a front-end interactive interface to display detection progress, detection results, and operation guidance.

3. The method according to claim 1, characterized in that, The workstation sensing unit is one or more of an RFID reader, a UWB base station, a Bluetooth beacon, or a visual positioning device; the built-in sensing module is an RFID reader, a UWB receiver module, or a Bluetooth module that is matched with the workstation sensing unit.

4. The vehicle off-line inspection method according to claim 1, characterized in that, The cockpit domain runs the Android system, and the vehicle control domain runs the QNX system or the Linux system. The abstract communication middleware shields the underlying differences between different operating systems, provides a unified API interface, and supports dynamic adaptation to different operating system versions. When the vehicle system is upgraded, only the middleware adaptation layer needs to be updated.

5. The vehicle off-line inspection method according to claim 1, characterized in that, If a test fails during the testing process, the vehicle system will automatically pause the test and display the fault code, fault location, and repair suggestions on the HMI interface. After the operator completes the troubleshooting according to the repair suggestions, the vehicle system will continue to execute the remaining testing procedures. If the final inspection fails, the vehicle's infotainment system receives a rework marking instruction from the production line cloud / edge server and marks the vehicle as requiring rework.

6. The vehicle off-line inspection method according to claim 1, characterized in that, The detection operations include: ECU online status detection, fault code reading and clearing, sensor signal detection, actuator function testing, parameter calibration and configuration writing.

7. The vehicle off-line inspection method according to claim 1, characterized in that, Also includes: The system receives the test script upgrade package remotely issued by the production line cloud / edge server and automatically upgrades the EOL test service on the vehicle terminal in the background. The production line cloud / edge server provides test script management, workstation management, test data statistics and fault analysis functions.

8. The vehicle off-line inspection method according to claim 1, characterized in that, The vehicle-mounted system uploads information to the production line cloud / edge server via in-vehicle Ethernet or 5G / C-V2X wireless communication.

9. A vehicle off-line inspection system based on an on-board diagnostic system, characterized in that, It includes an in-vehicle infotainment system, an on-board diagnostic module, a workstation sensing unit, and a production line cloud / edge server; the in-vehicle infotainment system is configured to perform the vehicle off-line inspection method as described in any one of claims 1 to 8.

10. The vehicle off-line inspection system according to claim 9, characterized in that, The vehicle infotainment system includes: The EOL testing service module is natively developed for the vehicle system and integrates UDS, OBD and DoIP diagnostic protocols. It is deeply integrated with the vehicle diagnostic module and is used as a diagnostic host to perform testing operations in factory mode. The workstation identification module is used to obtain the workstation ID by scanning the workstation sensing unit through the built-in sensing module; The communication module is used for sending and receiving data with the production line cloud / edge server; An abstract communication middleware module, deployed in the vehicle system, is used to shield the differences between the operating systems of the cockpit domain and the vehicle control domain, and provide a unified API to enable inter-domain collaboration. The factory mode management module is used to control the vehicle to enter factory mode through hardware triggering or key verification, and automatically exit factory mode, clear temporary data, and switch to user mode after the detection is completed.

Images