A core system, apparatus and method for vehicle diagnostics

Abstract

The application discloses a core system, device and method for vehicle diagnosis. The core system for vehicle diagnosis is connected with a vehicle and comprises an operating system layer, a protocol layer, a service layer and an application layer. The operating system layer comprises an operating system and a driver corresponding to diagnostic system hardware. The protocol layer comprises a hardware protocol stack corresponding to the diagnostic system hardware, and the hardware protocol stack is provided with multiple types of hardware protocols. The service layer is provided with multiple preset services corresponding to the types of the hardware protocols. The application layer comprises a diagnostic program used for performing a diagnostic operation on the vehicle. When the diagnostic program performs the diagnostic operation and generates a hardware calling request, the hardware calling request is sent to a preset service of a corresponding type. Each preset service determines a hardware scheduling strategy according to all currently received hardware calling requests, and schedules a hardware protocol of the corresponding type according to the hardware scheduling strategy, so that the diagnostic program completes control on the diagnostic system hardware in the diagnostic operation process.

Description

Technical Field

[0001] This invention relates to the field of automotive diagnostic technology, and in particular to a core system, device and method for vehicle diagnostics. Background Technology

[0002] Typically, vehicle off-line diagnostics are performed on automobile and other vehicle production lines to ensure the stability and reliability of vehicle production. This involves testing various indicators related to these processes after completing specific assembly steps. If problems are detected, the vehicle must be repaired or modified to resolve the fault until it passes the tests before it can be released from the production line.

[0003] However, due to the different manufacturing processes of different vehicles, vehicle manufacturers need to develop separate diagnostic functions for each step of the diagnostic process, distributing diagnostic functions to different testing equipment and having diagnostic personnel at the corresponding workstations perform the corresponding operations, thereby ensuring the orderly diagnosis of vehicles throughout the production process.

[0004] However, this approach still presents some challenges. Because diagnostic functions are distributed across different modules, system integration and coordination become difficult. Communication and collaboration between different modules require complex design and debugging, increasing system complexity and development costs. Furthermore, since existing diagnostic functions are typically designed for specific vehicle models or specific diagnostic needs, developing different diagnostic functions often involves redundant development of basic protocols and services, further increasing development costs. Summary of the Invention

[0005] The purpose of this invention is to provide a core system and device for vehicle diagnostics, which can effectively improve the compatibility of diagnostic equipment with different diagnostic procedures and reduce development and adaptation costs.

[0006] This invention provides a core system for vehicle diagnostics, which is communicatively connected to both the vehicle and a data server. It is characterized by comprising: an operating system layer, including an operating system and drivers corresponding to the diagnostic system hardware; a protocol layer, including a hardware protocol stack corresponding to the diagnostic system hardware, the hardware protocol stack having multiple types of hardware protocols; and a service layer, having multiple preset services corresponding to the types of hardware protocols. When a hardware call request is received during a vehicle diagnostic operation performed by a diagnostic program, each preset service determines a hardware scheduling strategy based on all currently received hardware call requests and schedules the corresponding type of hardware protocol according to the hardware scheduling strategy. This allows the diagnostic program to control the diagnostic system hardware during the diagnostic operation. The service layer integrates and temporarily stores the diagnostic results fed back during the vehicle diagnostic operation and sends them to the data server when a communication connection is established.

[0007] Furthermore, the core system for vehicle diagnostics provided by the present invention may also have the following technical features: the service layer is further provided with a remote call service; the diagnostic program and the service layer are located on different processors that are interconnected; the different processors jointly execute the diagnostic program to complete the vehicle diagnostic operation; when the diagnostic program generates a hardware call request, it sends the hardware call request to the remote call service; the remote call service calls the corresponding preset service based on the hardware call request; thereby enabling the different processors that are interconnected to jointly complete the vehicle diagnostic operation.

[0008] Furthermore, the core system for vehicle diagnostics provided by this invention may also have the following technical features, including: an application layer comprising a diagnostic program, wherein the service layer, protocol layer, and operating system layer are located on the first processor, the application layer is located on the data server, and the different processors that are interconnected are the first processor and the data server. The diagnostic operation is a calibration operation performed during vehicle operation. When the calibration operation is initiated, the data server runs the diagnostic program, and the generated request is encapsulated and sent to the first processor via remote service call. The corresponding preset service in the service layer will respond to the encapsulated request to initialize, and call the protocol layer, protocol layer, operating system layer, and diagnostic system hardware layer by layer to complete the initialization and enter the calibration mode.

[0009] Furthermore, the core system for vehicle diagnostics provided by this invention may also have the following technical features: after entering calibration mode, in response to requests generated by the diagnostic program, the preset service, upon receiving the encapsulated request, calls the protocol layer to perform secondary encapsulation of the request. The protocol layer further calls the hardware interface through the operating system layer to send the secondary encapsulated request to the vehicle. In response to diagnostic data fed back by the vehicle, the operating system layer acquires, organizes, and temporarily stores the diagnostic data. The preset service calls the protocol layer to unpack and / or repack the diagnostic data, and further sends it to the second device through a remote call service, enabling the diagnostic program to perform business logic processing and judgment.

[0010] Furthermore, the core system for vehicle diagnostics provided by the present invention may also have the following technical features, including: an application layer, comprising at least one diagnostic program; an operating system layer, a protocol stack, a service layer, and an application layer, all located on the same processor; a diagnostic operation being a calibration operation performed during vehicle operation; when the calibration operation is initiated, the processor runs the diagnostic program, and the generated request is sent to the service layer; the corresponding preset service in the service layer responds to the encapsulated request to initialize, and calls the protocol layer, the operating system layer, and the diagnostic system hardware layer by layer to complete the initialization and enter the calibration mode.

[0011] Furthermore, the core system for vehicle diagnostics provided by this invention may also have the following technical features: the processor is connected to an interface circuit, which includes a connector interface, at least two adapter interfaces, and an automatic switching switch. The connector interface is compatible with the model of the external interface. The automatic switching switch is located between the connector interface and the adapter interface and is used to switch the matching adapter interface according to the signal type output by the external interface. The protocol layer also includes a network protocol stack and a CAN protocol stack. The service layer also includes a vehicle communication service for scheduling the network protocol stack and the CAN protocol stack. After the automatic switching switch switches to match the corresponding adapter interface, the vehicle communication service also determines the corresponding communication protocol from the network protocol stack and / or the CAN protocol stack according to the signal type output by the external interface as the current communication protocol, and completes communication interaction based on the current communication protocol when performing vehicle diagnostic operations.

[0012] Furthermore, the core system for vehicle diagnostics provided by this invention may also have the following technical features: the protocol layer includes a network protocol stack and a CAN protocol stack, and the service layer includes a vehicle communication service for scheduling the network protocol stack and the CAN protocol stack. When the vehicle establishes a communication connection, the vehicle communication service schedules the network protocol stack and / or the CAN protocol stack to complete the communication connection. When the diagnostic program performs vehicle diagnostic operations, the corresponding vehicle diagnostic data is sent to the vehicle communication service through a vehicle communication request. The vehicle communication service determines a communication scheduling strategy based on all currently received vehicle communication requests and calls the network protocol stack and / or the CAN protocol stack according to the communication scheduling strategy to complete the transmission of vehicle diagnostic data and diagnostic results.

[0013] Furthermore, the core system for vehicle diagnostics provided by the present invention may also have the following technical features, wherein the hardware scheduling strategy includes: determining whether each hardware protocol corresponding to the preset service is invoked by two or more currently received hardware call requests; if so, sorting the hardware call requests according to the timestamp and / or priority of the hardware call requests, thereby prioritizing the processing of the hardware call request with the highest priority, and processing the subsequent hardware call requests in sequence; when a hardware call request is determined to be waiting for subsequent processing, the preset service sends a waiting message to the corresponding diagnostic program.

[0014] The present invention also provides a core device for vehicle diagnostics, having the technical features described above, wherein the device is equipped with any of the aforementioned core systems for vehicle diagnostics.

[0015] The present invention also provides a method for diagnosing vehicles while they are in motion during the vehicle's production process. This method features a core device that diagnoses vehicles in motion, wherein the core device is equipped with any of the aforementioned core systems for vehicle diagnosis.

[0016] Invention Function and Effect

[0017] According to the core system, apparatus, and method for vehicle diagnostics provided by the present invention, by setting up a basic operating system layer, protocol layer, and service layer on the core device, and determining the hardware scheduling strategy through preset services of the service layer to call the protocol layer and operating system layer by layer when responding to diagnostic programs, the core system of the present invention allows the processor of the diagnostic device to focus only on the operation and calling of basic services, protocols, and systems, greatly reducing the computational resource burden on the processor. This allows the diagnostic device to select a less powerful processor to complete the diagnosis at a lower cost and has compatibility with different diagnostic programs. At the same time, the diagnostic program can be flexibly set on a server connected to the core device, other high-performance processors, or the processor of the core device itself (when the performance of the processor is sufficient to support it), thereby dynamically adjusting the deployment of the diagnostic program during the vehicle off-line diagnostic process.

[0018] 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. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0019] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0020] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below.

[0021] Figure 1 This is a schematic diagram of a vehicle diagnostic system provided in an embodiment of the present invention.

[0022] Figure 2 This is a structural block diagram of the core system for vehicle diagnostics in an embodiment of the present invention.

[0023] Figure 3 This is a schematic diagram of the vehicle diagnostic device provided in an embodiment of the present invention.

[0024] Figure 4 This is a structural block diagram of a vehicle diagnostic device provided in an embodiment of the present invention.

[0025] Figure 5 This is a timing diagram of radar calibration detection performed on a vehicle in an embodiment of the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0027] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such orders can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein.

[0028] Furthermore, the terms “comprising” and “having”, and any variations thereof, are intended to cover non-exclusive inclusion, such that a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or apparatus.

[0029] <Example>

[0030] This embodiment uses a vehicle diagnostic device as the core system for a vehicle. In this embodiment, the vehicle diagnostic device can be wired to the vehicle's external interface via an interface component. The vehicle diagnostic device and the server work together through the core system of this embodiment to perform diagnostic operations on the vehicle.

[0031] Figure 1 This is a schematic diagram of a vehicle diagnostic system provided in an embodiment of the present invention. Figure 2 This is a structural block diagram of the core system for vehicle diagnostics in an embodiment of the present invention. (Reference) Figure 1 The vehicle diagnostic system 1000 includes multiple vehicle diagnostic devices 100 and a main controller 200 that is connected to them in communication. The vehicle diagnostic system 1000 is equipped with a core system 2000, which specifically includes an operating system layer 2001, a protocol layer 2002, a service layer 2003, and an application layer 2004.

[0032] First, let's elaborate on the vehicle diagnostic system 1000.

[0033] Figure 3 This is a schematic diagram of the vehicle diagnostic device provided in an embodiment of the present invention. Figure 4 This is a structural block diagram of a vehicle diagnostic device provided in an embodiment of the present invention.

[0034] refer to Figure 3 and Figure 4 The vehicle diagnostic device 100 specifically includes a housing 01, a core board 10, an interface component 20, an interaction component 30, a power supply component 40, and an expansion interface component 50. The core board 10 includes a base plate, and a diagnostic module 130, a cache module 131, a wireless module 150, and a Bluetooth module 170 disposed on the base plate.

[0035] In this embodiment, the vehicle diagnostic device 100 is a handheld diagnostic terminal; the main controller 200 is a server, which stores all the diagnostic programs required by the manufacturer during the vehicle's production process. Diagnostic personnel carry the vehicle diagnostic device 100 during the diagnostic process and perform diagnostics on the vehicle using the pre-loaded diagnostic programs. When a diagnostic program not loaded in the vehicle diagnostic device 100 needs to be executed, the vehicle diagnostic device 100 can be connected to the main controller 200 for communication, allowing the main controller 200 and the vehicle diagnostic device 100 to jointly complete the diagnostic process.

[0036] The core board 10 is used to implement the main diagnostic functions of the vehicle diagnostic device 100, such as sending diagnostic signals to the vehicle, organizing and uploading diagnostic data, and executing diagnostic programs. Next, the core board 10 and its related modules will be described in detail:

[0037] The substrate is used to fix and electrically connect hardware such as the diagnostic module 130, cache module 131, wireless module 150, interface component 20, interaction component 30, power component 40 and expansion interface component 50. In this embodiment, the substrate is a circuit board.

[0038] The diagnostic module 130 is electrically connected to various modules, including the cache module 131, wireless module 150, interface component 20, interaction component 30, power supply component 40, and expansion interface component 50, and controls each module. Additionally, the diagnostic module 130 can be electrically connected to the vehicle via the interface component 20 to perform diagnostics on the vehicle.

[0039] The cache module 131 includes a high-speed memory set up in the diagnostic module 130 and a flash memory card connected via a flash memory interface.

[0040] In one specific implementation, the diagnostic module 130 is an ARM main processor of model Cortex-A7 (dual core), which supports parallel processing and is compatible with multiple diagnostic protocols. The high-speed memory consists of 256M DDR memory and 256M Nand-flash memory located in the ARM main processor, and the flash memory card is an SD card, which is connected to the ARM main processor through the SD card slot (i.e., expansion interface component 50).

[0041] like Figure 1As shown, in this embodiment, the vehicle diagnostic device 100 is connected to the main controller 200 via a wireless module 150. In this embodiment, the main controller 200 is a server. To perform vehicle diagnostics, the main controller 200 works in conjunction with the diagnostic module 130. Specifically, the diagnostic module 130 can store different diagnostic programs and perform vehicle diagnostics through the interface component 20. During the diagnostic process, diagnostic data, processing results, logs, and other data are stored through the cache module 131. Simultaneously, when the vehicle diagnostic device 100 establishes a connection with the main controller 200 via the wireless module 150, it also uploads the cached data from the cache module 131 to the main controller 200, where the main controller 200 performs data analysis, statistics, archiving, and other processing.

[0042] However, due to the large number of actual vehicle diagnostic programs, the low-cost diagnostic module 130 may not be able to store all of them. In this case, if the vehicle diagnostic device 100 needs to execute a diagnostic program that has not been loaded, the diagnostic module 130 can connect to the main controller 200, retrieve the diagnostic program from the main controller 200, and load or replace it. Alternatively, the diagnostic module 130 may not load the diagnostic program, but instead run the diagnostic program through the main controller 200 and complete the diagnosis by forwarding diagnostic signals through the vehicle diagnostic device 100.

[0043] During the diagnostic process, specifically due to the compatibility of the ARM main processor, it stores various communication and hardware protocols required for the diagnostic process through a protocol stack. Therefore, the diagnostic module 130 can communicate with the vehicle and call hardware such as the wireless module 150 and the touch screen 193 based on these protocols. When diagnostic data, processing results, logs, and other data are obtained, the ARM main processor will organize and archive this data. If the wireless module 150 is connected to the main controller 20 at this time, it will also upload the organized data to the main controller 20 in parallel.

[0044] The wireless module 150 is a WIFI module, used to enable the diagnostic module 130 to communicate with the main controller 20 via WIFI and to complete data transmission and reception. The WIFI module 150 includes a WIFI chip 151 and an antenna 152.

[0045] The WIFI chip 151 is electrically connected to the diagnostic module 130 on the substrate and to the second DC-DC converter 144. The operating voltage is obtained from the second conversion terminal of the second DC-DC converter 144 to ensure operation. The antenna 152 is connected to the WIFI chip 151 and is used to provide signal transmission and reception.

[0046] In one practical application, the diagnostic module 130 has a diagnostic program pre-downloaded in it. When the WIFI module 150 establishes a communication connection with the main controller 20, it can upload the diagnostic data and corresponding results obtained by the diagnostic module 130 after completing the vehicle diagnosis to the server for archiving and storage.

[0047] In another practical application, the diagnostic module 130 does not have the required diagnostic program. In this case, the main controller 20 runs the diagnostic program and sends diagnostic signals to the diagnostic module 130 via the wireless module 150. The diagnostic module 130 then calls various protocols to communicate with the vehicle to complete the diagnosis. The diagnostic data and corresponding results are temporarily stored and organized in the cache module 131 and then uploaded to the main controller 20 in parallel for storage. In this case, the main controller 20 and the diagnostic module 130 jointly perform vehicle diagnosis, so the diagnostic module 130 can flexibly adapt to different diagnostic scenarios in practical applications.

[0048] To achieve high-bandwidth transmission in the vehicle diagnostic device 100, the bandwidth rate of the entire wireless module 150 needs to reach 600-900 Mbits (preferably 750 Mbits). Correspondingly, the connection bandwidth rate between the diagnostic module 130 and the WIFI chip 151 needs to reach 400-1000 Mbits (preferably 700 Mbits). In this embodiment, the WIFI chip 151 supports two frequencies: 2.4G and 5G. The antenna 152 is a dual-antenna system supporting MIMO, with a signal frequency of 80MHz, enabling the 5G WIFI to support a maximum transmission rate of 867Mbps. Simultaneously, the high-speed memory in the cache module 131 also supports high-speed read and write operations, effectively supporting the connection bandwidth rate of the diagnostic module 130. This design gives the vehicle diagnostic device 100 high-bandwidth characteristics, and combined with the aforementioned parallel processing capabilities, it enables timely downloading and uploading of diagnostic data.

[0049] The interface assembly 20 is partially mounted on the housing and partially mounted on the base plate, and is used to connect to the vehicle's external interfaces. The interface assembly 20 includes a connector interface 121, two adapter interfaces 122(1) and 122(2), and an automatic switching switch 123.

[0050] The connector interface 121 is matched with the model of the vehicle's external interface, such as an OBD interface or other industrial-grade connector interface. The connector interface 121 is mounted on the housing to facilitate the connection of the vehicle diagnostic device 100 to the vehicle by diagnostic personnel. The adapter interface 122 corresponds to the interface protocol supported by the vehicle's external interface. The adapter interface 122 and the automatic switching switch 123 are mounted on the base plate. The two adapter interfaces 122(1) and 122(2) are electrically connected to the diagnostic module 130, respectively.

[0051] As one specific implementation, the adapter interface 122 is a CAN interface and an ETH interface. It can be understood that the adapter interface can be set according to the interface protocol supported by various vehicle models in the actual market. For example, in other implementations, the adapter interface 122 can also be a CANFD interface or other interfaces that can support vehicle diagnostics, and three or more adapter interfaces 122 can be set as needed.

[0052] The automatic switching switch 123 is used to automatically switch the appropriate adapter interface 122 according to the interface protocol corresponding to the external interface when the connector interface 121 is connected to the vehicle's external interface. Specifically, the automatic switching switch 123 is an automatic switching switch matrix, which is set between the connector interface 121 and the adapter interface 122, and can automatically adapt to different OBD interface pin definitions. When a signal type output from the vehicle's external interface is received, the automatic switching switch 123 switches to match the corresponding adapter interface 122 according to the signal type.

[0053] In this embodiment, since different interface types have different pin definitions in the OBD interface, when the vehicle is connected, different interface protocols will send electrical signals to the connector interface 121 through different pins. Therefore, the automatic switching switch 123 can determine the type of the current interface protocol based on the number of pins corresponding to the electrical signal, and thus switch to match the corresponding adapter interface 122.

[0054] In practice, due to vehicle security access mechanisms, diagnostic operations often require the transmission and reception of diagnostic data through specific physical access interfaces on the vehicle. Furthermore, different vehicles may support different interface types, causing difficulties in customizing diagnostic equipment. Therefore, this solution improves the versatility of the vehicle diagnostic device 100 during vehicle off-line diagnostics by pre-setting commonly used interface types on the market and automatically adapting to different vehicles via automatic switching switches 123.

[0055] The interactive component 30 is mounted on the housing and is used to enable the diagnostic module 130 to interact with the user.

[0056] As one specific implementation method, such as Figure 3 As shown, the interactive component 30 includes a touchscreen 193, five indicator lights 191, and five buttons 192. Specifically, the front of the housing (i.e., the side of the vehicle diagnostic device 100 facing the user when in use) may have a screen mounting slot, and below the screen mounting slot, ten mounting holes are provided to match the number and shape of the indicator lights 191 and buttons 192.

[0057] The touchscreen 193, used for display and input, is installed in a screen mounting slot and electrically connected to the diagnostic module 130 via a data cable. In this embodiment, the touchscreen 193 may be a touch LCD screen, used to display the corresponding interface according to the diagnostic program stored in the diagnostic module 130, enabling diagnostic personnel to perform related operations.

[0058] It should be noted that although the touch screen 193 is a touch screen in this embodiment, and the diagnostic personnel can input operation commands through the touch screen, in practical applications, the touch screen 193 can also be replaced with a regular screen, so that the diagnostic personnel can operate through the button 192.

[0059] The indicator light 191 is used to indicate the execution result of the diagnostic program of the diagnostic module 130 or other results. In one specific embodiment, each indicator light 191 may be a charging indicator light indicating the charging status of the vehicle diagnostic device 100, a running indicator light indicating whether the diagnostic program is running, a vehicle connection indicator light indicating whether the interface component 20 has been successfully connected to the vehicle, a WIFI indicator light indicating the WIFI connection status, etc.

[0060] Button 192 is used to allow diagnostic personnel to perform simple control of the vehicle diagnostic device 100. In one specific implementation, each button 192 can be a power button for turning the vehicle diagnostic device 100 on and off, as well as other function keys adapted to the diagnostic program, such as starting diagnostics, pausing diagnostics, etc.

[0061] The aforementioned indicator light 191 and button 192 are fixed on the base plate and electrically connected to the diagnostic module 130. They are exposed to the outside of the housing through the mounting holes on the housing so that users can check the status of the indicator light or operate the button.

[0062] It should be noted that although the indicator light 191 and button 192 described in this embodiment are both located below the touch screen 193, in actual applications, the indicator light 191 and button 192 can also be located on the side of the touch screen, the side of the casing, or other locations that are convenient for users to observe and use. This embodiment does not impose any restrictions on this. Furthermore, it is understood that the number of indicator lights 191 and buttons 192 and their corresponding functions can also be adjusted according to actual development needs, and this embodiment does not impose any restrictions on this either.

[0063] In other implementations, the interaction component 30 may also include a speaker to prompt the diagnostic personnel by playing audio.

[0064] The power supply assembly 40 is electrically connected to the interface assembly 20, the wireless module 150, and the diagnostic module 130, respectively, for providing power and performing power adaptation.

[0065] Specifically, the power supply assembly 40 includes a protection assembly 141, a first DC-DC converter 142, a power switch 143, and a second DC-DC converter 144 connected in series, and also includes a battery module electrically connected to the first DC-DC converter 142, the battery module including a battery manager 145 and a battery 146.

[0066] The protection component 141 is used to protect the power output by the vehicle through the interface component 20. It has a fuse and a transient diode (TVS). When the vehicle erroneously outputs a large voltage, the protection component 141 can protect the vehicle diagnostic device 100 from damage in time.

[0067] The first conversion terminal of the first DC-DC converter 142 is electrically connected to the protection component 141, and the second conversion terminal is electrically connected to the first conversion terminal of the second DC-DC converter 144 via a power switch 143. In this embodiment, the first DC-DC converter 142 is used to convert between 12V and 5V voltages, with the voltage at its first conversion terminal being 12V and the voltage at its second conversion terminal being 5V.

[0068] The power switch 143 is used to control the switching on and off of the vehicle and the power supply of the battery 146 to the diagnostic module 130, thereby realizing the operation switch of the entire vehicle diagnostic device 100.

[0069] The second conversion terminal of the second DC-DC converter 144 is electrically connected to the diagnostic module 130 and the Wi-Fi module 150. In this embodiment, the second DC-DC converter 144 is used to convert between 5V and 3.3V voltages, with the voltage at its first conversion terminal being 5V and the voltage at its second conversion terminal being 3.3V.

[0070] In this embodiment, since a battery 146 is provided and a battery manager 145 is used to manage and control the power output of the battery 146, the vehicle diagnostic device 100 can also operate normally when not connected to the vehicle, making it convenient for diagnostic personnel to carry and use.

[0071] The expansion interface component 50 is fixed to the housing and electrically connected to the diagnostic module 130 to achieve the corresponding function.

[0072] In one specific implementation, the expansion interface component 50 is a Pogo Pin interface 161 and a flash memory interface 162.

[0073] The Pogo Pin 161 is located on the side of the casing and can support data transfer and charging simultaneously.

[0074] The flash memory interface 162 is an SD card slot for inserting an SD card and enabling the diagnostic module 130 to read the SD card, thereby making the SD card a cache module 131.

[0075] In other embodiments, the expansion interface component can also be any one of a USB interface, a Type-C interface, or any combination of multiple USB interfaces, Type-C interfaces, Pogo Pin interfaces, and SD interfaces. Specifically:

[0076] The USB interface is used to connect a USB flash drive, enabling the reading of its contents. When used in vehicle diagnostic devices, the USB flash drive can be used to install system image files, allowing the installation, updating, or flashing of the diagnostic module 130's system to be completed via the USB flash drive. Additionally, the USB interface can also be used to export diagnostic data and results from the diagnostic module 130.

[0077] The Type-C interface serves a similar purpose to the Pogo Pin interface, supporting both data transfer and charging simultaneously.

[0078] The Bluetooth module 170 enables the diagnostic module 130 to communicate with a Bluetooth-enabled configuration device held by the diagnostic personnel. In practical applications, the Bluetooth module 170 also allows the diagnostic personnel to modify the configuration information of the diagnostic module 130 via the Bluetooth connection, such as configuring or changing the WIFI SSID and IP address.

[0079] In this embodiment, the overall voltage of the core board 10 is below 5V, and the power consumption is controlled between 1.5W and 2.0W. The power consumption of the entire vehicle diagnostic device 100 is controlled between 3W and 5W. Therefore, the core board 10 also has low power consumption characteristics, which can effectively meet the needs of long-term vehicle diagnostics.

[0080] It should also be noted that, in specific implementations, the vehicle diagnostic device 100 may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the vehicle diagnostic device 100 may only include the components necessary for implementing the embodiments of this application, and not necessarily all the components shown in the figures.

[0081] The main controller 200 is used in conjunction with the vehicle diagnostic device 100 to perform vehicle diagnostics. In this embodiment, the main controller 200 is a data server 200, which is also used to manage the various vehicle diagnostic devices 100, and to store and process the diagnostic data and diagnostic structures uploaded by the vehicle diagnostic devices 100.

[0082] As one implementation, the data server 200 has multiple running services and stores all diagnostic programs. The running services are used to execute the diagnostic programs.

[0083] In other embodiments, the main controller 200 may also be other terminals, computers or other computing devices that are communicatively connected to the vehicle diagnostic device 100. This embodiment does not limit this.

[0084] The above is a detailed introduction to the vehicle diagnostic system 1000. Next, we will elaborate on the core system 2000.

[0085] refer to Figure 2 The core system 2000 specifically includes the operating system layer 2001, the protocol layer 2002, the service layer 2003, and the application layer 2004.

[0086] The operating system layer 2001 includes the operating system and the drivers corresponding to the diagnostic system hardware 1001 (the diagnostic system hardware 1001 is the wireless module 150, Bluetooth module 170, interface component 20, interaction component 30, power component 40 and expansion interface component 50 in the vehicle diagnostic device 100).

[0087] In this embodiment, the operating system and hardware drivers are used to provide functions such as original hardware drivers, process calls, and memory management. The protocol layer 2002, service layer 2003, and application layer 2004 are set on the operating system.

[0088] Protocol Layer 2002 includes a hardware protocol stack for driving hardware and a network protocol stack for communication.

[0089] In this embodiment, the hardware protocol stack includes multiple hardware driver protocols corresponding to the diagnostic system hardware 1001, such as a lamp driver protocol corresponding to the indicator light. The network protocol stack includes an Ethernet protocol stack and a CAN protocol stack. The network protocol stack includes standard TCP / IP protocol, data server communication heartbeat protocol, etc., while the CAN protocol stack includes various diagnostic communication protocols (such as CAN protocol, ETH protocol, etc.). Furthermore, in practical applications, the protocol layer 2002 may also include other auxiliary protocols.

[0090] Service layer 2003 includes multiple preset services, which are used for scheduling and managing the hardware protocol stack and network protocol stack. Different preset services correspond to their respective protocol types. When a preset service receives a call request from application layer 2004, it will call the corresponding protocol according to the type.

[0091] If the call request is a hardware call request, the relevant preset service will call the hardware protocol from the hardware protocol stack accordingly, and the hardware protocol will control the diagnostic system hardware 1001 to perform relevant operations through the driver of the operating system layer 2001, thereby realizing the functions required by the diagnostic program.

[0092] If the request is a communication request, the relevant preset service will call the corresponding communication protocol from the network protocol stack, and the communication protocol will perform operations such as unpacking, encapsulating, and transmitting the data.

[0093] In this embodiment, the preset services include vehicle communication services for calling the network protocol stack and the CAN protocol stack, as well as various hardware calling services corresponding to different hardware protocol types.

[0094] In practice, direct access to hardware services through the application layer 2004 can lead to conflicts. For example, when a diagnostic program occupies a certain piece of hardware, it can cause other diagnostic programs to fail to access that hardware. Therefore, it is necessary to use a pre-defined service for unified invocation to resolve the conflict problem of application access.

[0095] When the vehicle diagnostic device 100 is connected to the vehicle, the automatic switching switch 123 will switch to match the corresponding adapter interface 122. Then, the vehicle communication service will determine the communication protocol that is compatible with the current vehicle based on the signal type network protocol stack and / or CAN protocol stack output by the external interface, and will use the compatible communication protocol to complete data exchange in subsequent communication with the vehicle.

[0096] In addition, when the preset service receives multiple hardware call requests, it determines the hardware scheduling strategy based on all the hardware call requests received, and schedules the corresponding type of hardware protocol according to the hardware scheduling strategy, so that the diagnostic program can complete the control of the diagnostic system hardware during the diagnostic operation.

[0097] Specifically, the hardware scheduling strategy includes the following steps:

[0098] Determine whether each hardware protocol corresponding to this preset service is invoked by more than two currently received hardware call requests;

[0099] If so, the hardware call requests are sorted according to their timestamps and / or priorities, so that the hardware call request at the top of the list is processed first, and the subsequent hardware call requests are processed in sequence.

[0100] When a hardware call request is determined to be pending further processing, the default service sends a wait message to the corresponding diagnostic program.

[0101] The above hardware scheduling strategy can avoid conflicts in hardware calls from the application layer 2004.

[0102] In this embodiment, the operating system layer 2001, the protocol layer 2002, and the service layer 2003 are disposed on the diagnostic device 100; the application layer 2004 is partially disposed on the diagnostic device 100 and entirely disposed on the data server 200, that is, the diagnostic device 100 is provided with some diagnostic programs, while the server is provided with all diagnostic programs.

[0103] Service layer 2003 also includes a remote procedure call (RPC) service. When data server 200 or other computing devices execute diagnostic programs, they can send the generated call request to service layer 2003 of vehicle diagnostic device 100 via the RPC service. Subsequently, the corresponding preset service responds to the call request and invokes the appropriate protocol to complete the data interaction between data server 200, diagnostic device 100, and vehicle. Diagnostic data and results fed back by the vehicle during subsequent communication can also be sent to data server 200 for storage via the RPC service. This enables data server 200 and vehicle diagnostic device 100 to jointly perform diagnostic operations on the vehicle.

[0104] In another implementation, when the diagnostic device 100 executes a diagnostic program, the relevant call requests are directly sent to the corresponding preset service, which then calls the appropriate protocol to complete the data interaction between the vehicle diagnostic device 100 and the vehicle. The service layer 2003 integrates and temporarily stores the diagnostic data and results fed back by the vehicle during subsequent communication until the vehicle diagnostic device 100 establishes a communication connection with the data server 200, at which point the diagnostic data and results are sent to the data server 200 for storage. This also allows the data server 200 and the diagnostic device 100 to jointly complete the vehicle diagnostic operation.

[0105] In this case, the data integration operation of the service layer 2003 for diagnostic data and diagnostic results is also performed through a preset service, such as a communication protocol service. This communication protocol service can organize the diagnostic data and diagnostic results into data packets to be sent and temporarily store them in the cache module 131 until a communication connection is established with the data server 200 to upload them.

[0106] Application Layer 2004 includes at least one diagnostic program. Different diagnostic programs are used to perform different diagnostic operations on the vehicle, such as radar calibration, window calibration, camera calibration, software remapping, ECU testing, etc.

[0107] In practical applications, the data server 200 can overwrite and adjust some of the diagnostic programs installed on the diagnostic device 100. For example, the diagnostic device 100 originally has radar calibration and window calibration software. However, when the diagnostic personnel complete these diagnostic operations and need to perform a software flashing operation, they can select to install the software flashing program through the interactive component 30 of the diagnostic device 100. At this time, the data server 200 will install the stored software flashing program onto the diagnostic device 100 via wireless communication.

[0108] The aforementioned vehicle diagnostic system 1000 and its core system 2000 can be applied to all diagnostic items during the vehicle off-line testing process. In particular, this solution can also effectively support some procedures that require the vehicle to be in motion for diagnosis, such as radar calibration testing, enabling diagnostic personnel to conveniently complete calibration operations. The following section provides a detailed description of this test state in conjunction with a timing diagram.

[0109] Figure 5 This is a timing diagram of radar calibration detection performed on a vehicle in an embodiment of the present invention.

[0110] like Figure 5 As shown, taking radar calibration testing during vehicle driving as an example in the vehicle off-line inspection, the detailed data processing flow of the vehicle diagnostic system 1000 and core system 2000 during the diagnostic operation is as follows:

[0111] Before starting radar calibration testing, the vehicle diagnostic device 100 has already connected with the vehicle and determined the corresponding communication protocol according to the vehicle model.

[0112] First, the calibration preparation process for the vehicle diagnostic device 100 begins. The diagnostic personnel need to drive the vehicle into the test track and start the diagnostic program (hereinafter referred to as the APP). The specific process between the vehicle diagnostic system 1000 and the core system 2000 after the APP is started is as follows:

[0113] Data server 200 runs a diagnostic program that sends a start APP request to vehicle diagnostic device 100 via RPC service;

[0114] The relevant preset services in the service layer 2003 of the vehicle diagnostic device 100 respond to the APP request and perform initialization;

[0115] When the default service is initialized, the protocol corresponding to it in the protocol layer 2002 is initialized. When the protocol is initialized, the resources corresponding to it in the operating system layer 2001 are initialized. When the operating system 2001 resources are initialized, the hardware interface of the corresponding diagnostic system hardware is confirmed to be available.

[0116] The startup results are returned layer by layer from the hardware layer, operating system layer 2001, protocol layer 2002, service layer 2003, and application layer 2004. After receiving the startup results, the diagnostic program waits to enter the radar calibration process.

[0117] It should be noted that the diagnostic program in this embodiment runs on the data server 200, and therefore needs to receive APP requests through the RPC service. In other embodiments, if the diagnostic program runs on the vehicle diagnostic device 100, the RPC service is not required, and the requests generated by the diagnostic program will be directly sent to the preset service.

[0118] Next, after confirming the vehicle and completing the preparations, the diagnostic personnel click on the vehicle diagnostic device 100 to put the diagnostic program into calibration mode. In calibration mode, the vehicle diagnostic device 100 maintains a communication connection with the vehicle and exchanges data in real time between requests generated by the diagnostic program and diagnostic data returned by the vehicle. The specific process for sending diagnostic program requests is as follows:

[0119] The diagnostic program in the data server 200 generates a communication request and sends it to the vehicle diagnostic device 100 via RPC service. The vehicle communication service in the service layer 2003 obtains the communication request.

[0120] The vehicle communication service encapsulates the communication request using the communication protocol determined during the initial connection with the vehicle and sends it to the operating system layer 2001.

[0121] The operating system layer 2001 calls the interface module 20 to send the encapsulated communication request to the vehicle through the interface module 20.

[0122] In calibration mode, the operating system layer 2001 continuously monitors the vehicle's status through interface module 20. Once diagnostic data (such as radar detection data) is received from the vehicle, the specific process for feedback is as follows:

[0123] The operating system layer 2001 obtains the diagnostic data fed back by the vehicle through the interface module 20, organizes the diagnostic data and temporarily stores it;

[0124] The vehicle communication service calls the communication protocol determined during the previous connection with the vehicle to unpack / encapsulate the diagnostic data;

[0125] The remote call service sends the unpacked / encapsulated diagnostic data to the data server 200, enabling the diagnostic program to perform subsequent business logic processing and judgment. At the same time, the communication protocol service integrates all the diagnostic data during this radar calibration process.

[0126] In calibration mode, the above process will be repeated until the calibration is completed.

[0127] Finally, the communication protocol service integrates all diagnostic data from the radar calibration process and the data generated by the diagnostic program to form a diagnostic result, which is temporarily stored in the operating system layer 2001 (cache module 131). Once the vehicle diagnostic device 100 establishes a communication connection with the data server 200, it sends the diagnostic result to the data server 200, as follows:

[0128] A diagnostic program (e.g., a result upload program) in the application layer 2004 detects that the vehicle diagnostic device 100 has established a communication connection with the data server 200 and initiates an upload request to the communication protocol service;

[0129] The communication protocol service determines all diagnostic results that need to be uploaded and controls the corresponding preset services to start the corresponding data interface communication protocol;

[0130] The data interface communication protocol obtains relevant diagnostic results from the operating system layer 2001 (cache module 131) and sends them to the protocol layer 2002 after verifying data integrity.

[0131] The data interface communication protocol unpacks / encapsulates the diagnostic results, and the communication protocol service uploads the unpacked / encapsulated diagnostic results to the data server 200 via a remote call service.

[0132] In the above process, the diagnostic results temporarily stored in the operating system layer 2001 (cache module 131) can be the results of multiple diagnoses. When the vehicle diagnostic device 100 connects to the data server 200, the communication protocol service will upload all diagnostic results at once. In practical applications, if the connection time between the two is insufficient to upload all diagnostic results, the communication protocol service can also record the node from which the last diagnostic result was uploaded and start uploading from the recorded node in the next upload, thereby realizing the function of resuming interrupted uploads.

[0133] Finally, it should be noted that the above embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A core system for vehicle diagnostics, communicatively connected to both the vehicle and a data server, characterized in that, include: The operating system layer includes the operating system and the drivers corresponding to the diagnostic system hardware; The protocol layer includes a hardware protocol stack corresponding to the diagnostic system hardware, and the hardware protocol stack is configured with multiple types of hardware protocols. The service layer includes multiple preset services corresponding to the types of the hardware protocols. as well as The application layer includes at least one diagnostic procedure. Specifically, when a hardware call request is received during the execution of vehicle diagnostic operations by the diagnostic program, each of the preset services determines a hardware scheduling strategy based on all currently received hardware call requests, and schedules the corresponding type of hardware protocol according to the hardware scheduling strategy, thereby enabling the diagnostic program to control the diagnostic system hardware during the diagnostic operation. The service layer integrates and temporarily stores the diagnostic results returned when the vehicle undergoes the diagnostic operation, and sends them to the data server when a communication connection is established with the data server. The operating system layer, the protocol stack, the service layer, and the application layer are all located on the same processor. The diagnostic operation is a calibration operation performed while the vehicle is in motion. When the calibration operation is initiated, the processor runs the diagnostic program and sends the generated request to the service layer. The corresponding preset service in the service layer will respond to the encapsulated request to initialize, and call the protocol layer, operating system layer, and diagnostic system hardware layer by layer to complete the initialization and enter the calibration mode. The processor is connected to an interface circuit. The interface circuit includes a connector interface, at least two adapter interfaces, and an automatic switching switch. The connector interface is compatible with the model of the external interface. The automatic switching switch is located between the connector interface and the adapter interface, and is used to switch the matching adapter interface according to the signal type output by the external interface. The protocol layer also includes a network protocol stack and a CAN protocol stack. The service layer also includes vehicle communication services for scheduling the network protocol stack and the CAN protocol stack. After the automatic switching switch switches to match the corresponding adapter interface, the vehicle communication service also determines the corresponding communication protocol from the network protocol stack and / or the CAN protocol stack based on the signal type output by the external interface as the current communication protocol, and completes communication interaction based on the current communication protocol when performing the vehicle diagnostic operation.

2. The core system for vehicle diagnostics according to claim 1, characterized in that: in, The service layer also includes a remote invocation service. The diagnostic program and the service layer are located on different processors that are communicatively connected. These different processors jointly execute the diagnostic program to complete the vehicle diagnostic operation. When the diagnostic program generates the hardware call request, it sends the hardware call request to the remote call service, which then calls the corresponding preset service based on the hardware call request, so that the different but interconnected processors can work together to complete the diagnostic operation of the vehicle.

3. The core system for vehicle diagnostics according to claim 2, characterized in that: in, The service layer, the protocol layer, and the operating system layer are disposed on the first processor, and the application layer is disposed on the data server. The different processors that are communicatively connected to each other are the first processor and the data server. The diagnostic operation is a calibration operation performed while the vehicle is in motion. When the calibration operation is initiated, the data server runs the diagnostic program, and the resulting request is encapsulated and sent to the first processor via the remote call service. The corresponding preset services in the service layer will respond to the encapsulated request to initialize, and call the protocol layer, operating system layer, and diagnostic system hardware layer by layer to complete the initialization and enter the calibration mode.

4. The core system for vehicle diagnostics according to claim 3, Its features are: in, After entering calibration mode In response to the request generated by the diagnostic program, when the preset service receives the encapsulated request, it calls the protocol layer to encapsulate the request a second time. The protocol layer then calls the hardware interface through the operating system layer to send the encapsulated request to the vehicle. In response to the diagnostic data returned by the vehicle, the operating system layer acquires, organizes, and temporarily stores the diagnostic data. The preset service calls the protocol layer to unpack and / or repack the diagnostic data, and then sends it to the data server through the remote call service, enabling the diagnostic program to perform business logic processing and judgment.

5. The core system for vehicle diagnostics according to claim 1, characterized in that: in, The protocol layer also includes a network protocol stack and a CAN protocol stack. The service layer also includes vehicle communication services for scheduling the network protocol stack and the CAN protocol stack. When the vehicle establishes a communication connection, the vehicle communication service schedules the network protocol stack and / or the CAN protocol stack to complete the communication connection. When the diagnostic program performs the vehicle diagnostic operation, the corresponding vehicle diagnostic data is sent to the vehicle communication service through a vehicle communication request. The vehicle communication service determines a communication scheduling strategy based on all the currently received vehicle communication requests, and calls the network protocol stack and / or the CAN protocol stack according to the communication scheduling strategy to complete the transmission of the vehicle diagnostic data and the diagnostic results.

6. The core system for vehicle diagnostics according to claim 1, characterized in that: in, The hardware scheduling strategy includes: Determine whether each of the hardware protocols corresponding to this preset service is invoked by more than two currently received hardware call requests. If so, the hardware call requests are sorted according to their timestamps and / or priorities, with the highest-ranked hardware call request being processed first, followed by subsequent hardware call requests in sequence. When the hardware call request is determined to be pending further processing, the preset service sends a waiting message to the corresponding diagnostic program.

7. A core device for vehicle diagnostics, characterized in that, The device is equipped with a core system for vehicle diagnostics as described in any one of claims 1 to 6.

8. A method for performing diagnostics on a vehicle while it is in motion during its production line rollout, characterized in that: The vehicle is diagnosed by a core device that is in motion, the core device being equipped with a core system for vehicle diagnosis as described in any one of claims 1 to 6.

Images