A vehicle-mounted hardware diagnosis method, system, electronic device and storage medium

Abstract

The application provides a vehicle-mounted hardware diagnosis method and system, electronic equipment and a storage medium. The method comprises the following steps: performing service layering on a vehicle-mounted system based on a service-oriented architecture, the service layering comprising an upper layer system and an intermediate layer; in response to a diagnosis task request, the upper layer system acquires target hardware information according to the diagnosis task request, generates a corresponding target hardware detection task according to the target hardware information, and delivers the target hardware detection task to the intermediate layer; the target hardware detection task is sent to the target hardware in a preset communication mode, so that the target hardware performs hardware detection, acquires the current state of the target hardware, and generates feedback information and sends the feedback information to the intermediate layer; and abnormality processing is performed based on the feedback information to complete the diagnosis of the target vehicle-mounted hardware. The application has universality, strong portability, meets all the hardware at present, supports the development of business processes more quickly, and changes the business processes more easily.

Description

Technical Field

[0001] This application relates to the field of computer applications, specifically to an in-vehicle hardware diagnostic method, system, electronic device, and storage medium. Background Technology

[0002] In the automotive industry, different car models may correspond to different products, and consequently, different hardware. Therefore, for developers, different hardware testing procedures need to be developed each time, which undoubtedly increases the manpower costs for R&D staff. Hardware testing is often carried out in the early stages of mass production. Checking the status of in-vehicle hardware for after-sales products is often a very complex process. Although hardware generally does not have problems, it has an inseparable relationship with intelligent software.

[0003] Currently, existing hardware testing methods are primarily based on test software written for individual hardware components, employing diverse solutions that are difficult to port, lack reusability, and may not be applicable to different hardware. For hardware testing in automotive systems, there is currently no unified testing solution. Automotive systems differ from mobile phone systems; they rely more heavily on hardware, interacting almost entirely with it. Therefore, hardware status monitoring is essential. Only by monitoring the current hardware status can software analyze problems in the automotive system, such as the hardware status of chips like the screen, camera, GPS, Wi-Fi, and Bluetooth. However, these are undoubtedly the lowest-level devices; no upper-level software layer can directly obtain the status of each hardware component. Therefore, a channel is needed to connect from top to bottom, requiring different protocols to define hardware diagnostic codes. Summary of the Invention

[0004] In view of the shortcomings of the prior art described above, the present invention provides an in-vehicle hardware diagnostic method, system, electronic device and storage medium to solve the above technical problems.

[0005] The vehicle hardware diagnostic method provided in this application includes: performing service layering of the vehicle system based on a service-oriented architecture, wherein the service layering includes an upper-layer system for providing a hardware detection entry point and an intermediate layer for communicating with target hardware; in response to a diagnostic task request, the upper-layer system obtains target hardware information according to the diagnostic task request, generates a corresponding target hardware detection task according to the target hardware information, and sends it to the intermediate layer; the target hardware detection task is sent to the target hardware using preset communication methods of different types, so that the target hardware performs hardware detection, obtains the current state of the target hardware, and generates feedback information to be sent to the intermediate layer; and anomaly handling is performed based on the feedback information to complete the diagnosis of the target vehicle hardware.

[0006] In one embodiment of this application, the current state of the target hardware is converted to generate a status code and / or an error code; the current state of the target hardware is indicated based on the status code to prompt the user; the fault state of the target hardware is indicated based on the error code to enable developers to query and analyze the problems of the target hardware.

[0007] In one embodiment of this application, the target hardware detection task is sent to the microcontroller unit via serial communication, so that the microcontroller unit issues a detection command to the target hardware; or, the target hardware detection task is sent to the kernel via inter-process communication, so that the kernel issues a detection command to the target hardware via shared memory; or, the target hardware detection task is sent to the microcontroller unit via Ethernet, so that the microcontroller unit issues a detection command to the target hardware.

[0008] In one embodiment of this application, the upper-layer system and the middle layer expose service interfaces based on an interface definition language to enable communication between the upper-layer system and the middle layer, wherein the middle layer is a local service layer.

[0009] In one embodiment of this application, the status data of all hardware is acquired; the status data is organized according to a preset data exchange format, wherein the data exchange format is a lightweight data exchange format; based on the organized data, the target hardware is determined, and the current status of the target hardware is acquired.

[0010] In one embodiment of this application, the upper-layer system includes the Android system, the interface definition language includes the Android Interface Definition Language, and the target hardware includes peripherals.

[0011] According to one aspect of the embodiments of this application, an in-vehicle hardware diagnostic system includes: an upper-layer system for providing a hardware detection entry point; a middle layer for communicating with target hardware, wherein the upper-layer system and the middle layer are obtained by service layering of the in-vehicle system based on a service-oriented architecture; a diagnostic module for performing anomaly handling based on feedback information to complete the diagnosis of the target in-vehicle hardware; in response to a diagnostic task request, the upper-layer system obtains target hardware information according to the diagnostic task request, generates a corresponding target hardware detection task according to the target hardware information, and sends it to the middle layer; the middle layer sends the target hardware detection task to the target hardware using preset different types of communication methods, so that the target hardware performs hardware detection, obtains the current state of the target hardware, and generates the feedback information and sends it to the middle layer.

[0012] In one embodiment of this application, the intermediate layer includes: a conversion module, configured to convert the current state of the target hardware, generate a status code and / or an error code, indicate the current state of the target hardware based on the status code to prompt the user, and indicate the fault state of the target hardware based on the error code to enable developers to query and analyze the problems of the target hardware.

[0013] According to one aspect of the embodiments of this application, an in-vehicle hardware diagnostic device is provided, comprising: an upper-layer system for providing a hardware detection entry point; a middle layer for communicating with target hardware, wherein the upper-layer system and the middle layer are obtained by service layering of the in-vehicle system based on a service-oriented architecture; a diagnostic module for performing anomaly handling based on feedback information to complete the diagnosis of the target in-vehicle hardware; in response to a diagnostic task request, the upper-layer system obtains target hardware information according to the diagnostic task request, generates a corresponding target hardware detection task according to the target hardware information, and sends it to the middle layer; the middle layer sends the target hardware detection task to the target hardware using preset different types of communication methods, so that the target hardware performs hardware detection, obtains the current state of the target hardware, and generates the feedback information and sends it to the middle layer.

[0014] According to one aspect of the embodiments of this application, an electronic device is provided, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to implement the vehicle hardware diagnostic method as described above.

[0015] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, on which computer-readable instructions are stored, which, when executed by a computer's processor, cause the computer to perform the vehicle hardware diagnostic method as described above.

[0016] In the technical solutions provided by some embodiments of this application, the vehicle hardware diagnostic method, system, electronic device and storage medium of this application are universal, highly portable and compatible with current hardware communication solutions. This application can meet the needs of almost all current hardware. It adopts the SOA architecture solution, which can realize the separation of system model and system. SOA supports faster development of business processes and easier changes to business processes. It can enable organizations to adapt to changes in their business environment more quickly and bring products and services to market more quickly. It has agility, consistency and flexibility.

[0017] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0019] Figure 1 This is a schematic diagram of the system architecture of an on-board hardware diagnostic method illustrated in an exemplary embodiment of this application;

[0020] Figure 2 This is a schematic flowchart illustrating an exemplary embodiment of the vehicle hardware diagnostic method of this application;

[0021] Figure 3 This is a block diagram illustrating an on-board hardware diagnostic system, as shown in an exemplary embodiment of this application.

[0022] Figure 4 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0023] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0024] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0025] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the invention.

[0026] In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0027] Figure 1 This is a schematic diagram illustrating an exemplary method flow as shown in an exemplary embodiment of this application.

[0028] Reference Figure 1 As shown,

[0029] The vehicle-mounted hardware diagnostic method in this embodiment includes:

[0030] S110. The vehicle system is layered based on a service-oriented architecture. The service layer includes an upper-layer system for providing hardware detection entry points and an intermediate layer for communicating with target hardware.

[0031] In one embodiment of this application, the status data of all hardware is acquired; the status data is then processed according to a preset data exchange format, which is a lightweight data exchange format; based on the processed data, the target hardware is determined, and the current status of the target hardware is obtained. In this embodiment, the upper-layer system is an upper-layer Android system, used to provide the detection of hardware status on the page and the entry point for detection, making it convenient for users to intuitively view the hardware status and understand the working status of peripherals. The middle layer is an SOA (Native) program, used to process peripheral data and the communication channel with the hardware, and to process the data (which can be processed into JSON or files). JSON (JavaScript Object Notation) is a lightweight data exchange format.

[0032] In one embodiment of this application, the current state of the target hardware can be converted to generate a status code and / or an error code. The status code indicates the current state of the target hardware to prompt the user; the error code indicates the fault state of the target hardware, enabling developers to query and analyze problems with the target hardware. This is achieved by collecting the status information uploaded by various peripheral devices. This information is converted into a user-recognizable status code to prompt the user, and into a corresponding error code for developers to query and analyze problems in real time.

[0033] S120. In response to the diagnostic task request, the upper-layer system obtains the target hardware information according to the diagnostic task request, generates the corresponding target hardware detection task according to the target hardware information, and sends it to the middle layer.

[0034] In one embodiment of this application, the upper-layer system and the middle layer expose service interfaces based on an interface definition language to enable communication between them. The middle layer is a Native (local service) layer. The upper-layer system includes the Android system, the interface definition language includes the Android Interface Definition Language, and the target hardware includes peripherals.

[0035] In one embodiment of this application, the target hardware detection task is sent to the microcontroller unit (MCU) via serial communication, so that the MCU issues a detection command to the target hardware; or, the target hardware detection task is sent to the kernel via inter-process communication, so that the kernel issues a detection command to the target hardware via shared memory; or, the target hardware detection task is sent to the MCU via Ethernet, so that the MCU issues a detection command to the target hardware. To enable other applications to access the services provided by this application, the Android system uses Remote Procedure Call (RPC). Android uses an Interface Definition Language (IDL) to expose service interfaces. Three of the four Android application components (Activity, BroadcastReceiver, and ContentProvider) can perform cross-process access, and the other Android application component, Service, can as well. Such cross-process accessible services are called AIDL (Android Interface Definition Language) services. Optionally, in this embodiment, communication between the upper layer and the Native layer uses Android's native AIDL. The communication methods between the middle layer (Native) and the microcontroller unit (MCU), as well as between the middle layer (Native) and the kernel, are CAN communication and serial communication. Kernel communication can use Android's native HIDL method (the principle is the same as AIDL), which is also a type of Native binder communication. Its main business is in the SOA Native layer service layer, used for collecting and organizing data.

[0036] S130. Send the target hardware detection task to the target hardware using different preset communication methods so that the target hardware can perform hardware detection, obtain the current status of the target hardware, and generate feedback information to send to the middle layer.

[0037] In one embodiment of this application, the application layer issues diagnostic tasks. After receiving the task to diagnose a specific target hardware, the intermediate Native service distributes the task to the corresponding hardware module using different methods. Upon receiving the diagnostic information, the hardware module obtains its current hardware status and then feeds it back to the intermediate Native layer. This approach solves the communication problems between Android and the Kernel, between Android and the MCU (Microcontroller Unit), and between the MCU and the hardware.

[0038] S140. Perform anomaly handling based on feedback information to complete the diagnosis of the target vehicle hardware.

[0039] In one embodiment of this application, after the service receives the data, it can perform an exception handling process (e.g., converting it into an error code displayed to the user at the UI layer, or into an error message that the developer can recognize). In this embodiment, it can detect the hardware devices of all peripheral devices of the vehicle system, effectively confirm the hardware status and whether it is damaged, speed up the software problem analysis, and has portability, reducing development costs and promoting the speed of software problem analysis and shortening the cycle.

[0040] Figure 3 This is a block diagram illustrating an in-vehicle hardware diagnostic system according to an exemplary embodiment of this application. The system can be applied to an in-vehicle hardware diagnostic implementation environment and is specifically configured within an in-vehicle system. The system can also be applied to other exemplary implementation environments and specifically configured in other devices; this embodiment does not limit the implementation environment to which the device is applicable.

[0041] like Figure 3 As shown, this exemplary vehicle hardware diagnostic system includes:

[0042] The upper-layer system is used to provide a hardware detection entry point;

[0043] The middle layer is used to communicate with the target hardware. The upper system and the middle layer are obtained by layering services in the vehicle system based on a service-oriented architecture.

[0044] The diagnostic module is used to handle anomalies based on feedback information in order to complete the diagnosis of the target vehicle hardware.

[0045] In response to a diagnostic task request, the upper-layer system obtains the target hardware information based on the diagnostic task request, generates the corresponding target hardware detection task based on the target hardware information, and sends it down to the middle layer.

[0046] The middle layer sends the target hardware detection task to the target hardware using different preset communication methods, so that the target hardware can perform hardware detection, obtain the current status of the target hardware, and generate feedback information to send to the middle layer.

[0047] In one embodiment of this application, the intermediate layer includes: a conversion module, used to convert the current state of the target hardware, generate a status code and / or an error code, indicate the current state of the target hardware based on the status code to prompt the user, and indicate the fault state of the target hardware based on the error code to enable developers to query and analyze the problems of the target hardware.

[0048] It should be noted that the upgrade device and the upgrade method provided in the above embodiments belong to the same concept. The specific ways in which each module and unit performs operations have been described in detail in the method embodiments and will not be repeated here. In practical applications, the vehicle hardware diagnostic device provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. For example, the vehicle hardware diagnostic device in this embodiment is also applicable to any controller whose physical channel is upgraded using UDS FBL, and this is not a limitation here.

[0049] Embodiments of this application also provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to implement the image processing methods provided in the above embodiments.

[0050] Figure 4 A schematic diagram of a computer system suitable for implementing the embodiments of this application is shown. It should be noted that... Figure 4 The computer system 1200 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0051] like Figure 4As shown, the computer system 1200 includes a Central Processing Unit (CPU) 1201, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1202 or programs loaded from storage portion 1208 into Random Access Memory (RAM) 1203, such as performing the methods described in the above embodiments. The RAM 1203 also stores various programs and data required for system operation. The CPU 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An Input / Output (I / O) interface 1205 is also connected to the bus 1204.

[0052] The following components are connected to I / O interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to I / O interface 1205 as needed. Removable media 1211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1210 as needed so that computer programs read from them can be installed into storage section 1208 as needed.

[0053] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1209, and / or installed from removable medium 1211. When the computer program is executed by central processing unit (CPU) 1201, it performs various functions defined in the system of this application.

[0054] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: 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), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0055] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0056] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0057] Another aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the vehicle hardware diagnostic method as described above. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not assembled into the electronic device.

[0058] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the vehicle hardware diagnostic methods provided in the various embodiments described above.

[0059] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the claims of the present invention.

Claims

1. A method for diagnosing vehicle-mounted hardware, characterized in that, include: The in-vehicle system is layered based on a service-oriented architecture. The service layer includes an upper-layer system for providing hardware detection entry points and an intermediate layer for communicating with target hardware. In response to a diagnostic task request, the upper-layer system obtains target hardware information based on the diagnostic task request, generates a corresponding target hardware detection task based on the target hardware information, and sends it down to the middle layer. The target hardware detection task is sent to the target hardware using different preset communication methods, so that the target hardware can perform hardware detection, obtain the current status of the target hardware, and generate feedback information to send to the middle layer. Based on the feedback information, anomaly handling is performed to complete the diagnosis of the target vehicle hardware, including: The current state of the target hardware is transformed to generate a status code and an error code; The status code indicates the current status of the target hardware, in order to prompt the user. The error code indicates the fault status of the target hardware, enabling developers to query and analyze the problems of the target hardware. Sending the target hardware detection task to the target hardware using different preset communication methods also includes: exposing service interfaces between the upper-layer system and the middle layer based on an interface definition language to enable communication between the upper-layer system and the middle layer, wherein the middle layer is a local service layer. The process of obtaining the current status of the target hardware and generating feedback information to send to the middle layer includes: obtaining the status data of all hardware; organizing the status data according to a preset data exchange format, wherein the data exchange format is a lightweight data exchange format; and determining the target hardware based on the organized data and obtaining the current status of the target hardware.

2. The vehicle-mounted hardware diagnostic method according to claim 1, characterized in that, Sending the target hardware detection task to the target hardware using different preset communication methods includes: The target hardware detection task is sent to the microcontroller unit via serial communication, so that the microcontroller unit issues a detection command to the target hardware. or, The target hardware detection task is sent to the kernel via inter-process communication, so that the kernel can issue detection instructions to the target hardware through shared memory. or, The target hardware detection task is sent to the microcontroller unit via Ethernet, so that the microcontroller unit issues a detection command to the target hardware.

3. The vehicle-mounted hardware diagnostic method according to claim 1, characterized in that, The upper-layer system includes the Android system, the interface definition language includes the Android Interface Definition Language, and the target hardware includes peripherals.

4. An on-board hardware diagnostic system, characterized in that, include: The upper-layer system is used to provide a hardware detection entry point; The middle layer is used to communicate with the target hardware. The upper system and the middle layer are obtained by layering services of the vehicle system based on a service-oriented architecture. The diagnostic module is used to handle anomalies based on feedback information in order to complete the diagnosis of the target vehicle hardware. In response to a diagnostic task request, the upper-layer system obtains target hardware information based on the diagnostic task request, generates a corresponding target hardware detection task based on the target hardware information, and sends it down to the middle layer. The intermediate layer sends the target hardware detection task to the target hardware using different preset communication methods, so that the target hardware can perform hardware detection, obtain the current status of the target hardware, and generate the feedback information to send to the intermediate layer. The intermediate layer includes: a conversion module, used to convert the current state of the target hardware, generate a status code and an error code, indicate the current state of the target hardware based on the status code to prompt the user, and indicate the fault state of the target hardware based on the error code to enable developers to query and analyze the problems of the target hardware; Sending the target hardware detection task to the target hardware using different preset communication methods also includes: exposing service interfaces between the upper-layer system and the middle layer based on an interface definition language to enable communication between the upper-layer system and the middle layer, wherein the middle layer is a local service layer. The process of obtaining the current status of the target hardware and generating feedback information to send to the middle layer includes: obtaining the status data of all hardware; organizing the status data according to a preset data exchange format, wherein the data exchange format is a lightweight data exchange format; and determining the target hardware based on the organized data and obtaining the current status of the target hardware.

5. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to implement the vehicle hardware diagnostic method as described in any one of claims 1 to 3.

6. A computer-readable storage medium, characterized in that, It stores computer-readable instructions, which, when executed by the computer's processor, cause the computer to perform the vehicle hardware diagnostic method according to any one of claims 1 to 3.

Images