Message processing method of vehicle, message processing system of vehicle, and vehicle

Abstract

The application discloses a message processing method of a vehicle, a message processing system of the vehicle and the vehicle. The method comprises the following steps: acquiring a real-time message output by a message processing module in the vehicle, wherein the real-time message is used for representing a connection state between the vehicle and a vehicle-mounted device; judging whether the real-time message is consistent with a preset message in a cache module, wherein the cache module comprises a plurality of historically cached messages, and the preset message is a message last cached to the cache module in the plurality of messages; and in response to the real-time message being inconsistent with the preset message, reporting the real-time message to an application program of the vehicle, wherein the application program determines the connection state between the vehicle and the vehicle-mounted device by analyzing the real-time message. The application solves the technical problem that in the prior art, after a vehicle-mounted device fails, the vehicle-mounted device no longer sends a message, and a user cannot instantly know the state of the vehicle-mounted device.

Description

Technical Field

[0001] This invention relates to the field of vehicle-mounted equipment, and more specifically, to a vehicle message processing method, a vehicle message processing system, and a vehicle. Background Technology

[0002] In recent years, with social progress and development, people's demands for quality of life have been increasing, and the types of in-vehicle devices have become more and more diverse. Current related technologies mainly rely on applications to periodically obtain messages output by the in-vehicle device to determine its status. Although the underlying vehicle system continuously caches these messages, if a malfunction occurs after the in-vehicle device sends a message, it will stop sending messages, and the upper-layer application will not be able to obtain them. This prevents users from being informed of device malfunctions in a timely manner, causing inconvenience to their travel.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This invention provides a vehicle message processing method, a vehicle message processing system, and a vehicle, to at least solve the technical problem in the related art where the on-board equipment stops sending messages after a malfunction, and the user cannot know the status of the on-board equipment in real time.

[0005] According to one aspect of the present invention, a message processing method for a vehicle is provided, comprising: acquiring a real-time message output by a message processing module in the vehicle, wherein the real-time message is used to characterize the connection status between the vehicle and an in-vehicle device; determining whether the real-time message is consistent with a preset message in a caching module, wherein the caching module includes multiple historically cached messages, and the preset message is the last message cached to the caching module among the multiple messages; and, in response to the inconsistency between the real-time message and the preset message, reporting the real-time message to an application program in the vehicle, wherein the application program determines the connection status between the vehicle and the in-vehicle device by parsing the real-time message.

[0006] Optionally, the aforementioned real-time messages include: normal messages uploaded in real-time by the on-board equipment to the message processing module or fault messages generated by the control message processing module.

[0007] Optionally, the above method further includes: in response to the message processing module not receiving a normal message uploaded by the vehicle-mounted device within a preset time period, controlling the message processing module to generate a fault message.

[0008] Optionally, in response to a discrepancy between the real-time message and the preset message, after reporting the real-time message to the vehicle's application, the above method further includes: caching the real-time message to a cache module.

[0009] Optionally, the above method further includes: in response to the real-time message being consistent with the preset message, caching the real-time message to the cache module.

[0010] Optionally, the control message processing module generates a fault message, including: the control message processing module obtains a preset message from the cache module; and modifies the preset message based on preset rules to obtain the fault message.

[0011] Optionally, if the real-time message is a normal message, the application determines that the connection between the vehicle and the on-board equipment is in a normal state by parsing the real-time message; or, if the real-time message is a fault message, the application determines that the connection between the vehicle and the on-board equipment is in a fault state by parsing the real-time message.

[0012] Optionally, the application retrieves preset messages from the cache module at preset intervals and determines the connection status between the vehicle and the on-board equipment by parsing the preset messages.

[0013] According to another aspect of the present invention, a vehicle message processing system is also provided, comprising: a message processing module for outputting real-time messages, wherein the real-time messages are used to characterize the connection status between the vehicle and an in-vehicle device; a controller for determining whether the real-time messages are consistent with a preset message in a caching module, wherein the caching module includes a plurality of historically cached messages; the preset message is the last message cached to the caching module among the plurality of messages; in response to the inconsistency between the real-time messages and the preset messages, reporting the real-time messages to an application program of the vehicle; and an application program for determining the connection status between the vehicle and the in-vehicle device by parsing the real-time messages.

[0014] According to another aspect of the present invention, a vehicle is also provided, comprising: one or more processors; a storage device for storing one or more programs; and a message processing method for the vehicle, wherein the one or more programs are executed by the one or more processors, causing the one or more processors to perform any of the above-described methods.

[0015] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored program, wherein, when the program is running, it controls the device where the computer-readable storage medium is located to execute the above-described information push method.

[0016] According to another aspect of the present invention, a processor is also provided, which is used to run a program, wherein the program executes the above-described information push method during runtime.

[0017] In this embodiment of the invention, the real-time message output by the message processing module in the vehicle is obtained, and it is determined whether the real-time message is consistent with the preset message in the cache module. If the real-time message is inconsistent with the preset message, it indicates that the real-time message is a fault message. The vehicle system can report the real-time message to the vehicle's application, thereby enabling the vehicle system to promptly report the fault message of the vehicle equipment to the application without the application needing to periodically obtain it from the vehicle system. This ensures that the application can promptly obtain the fault message of the vehicle equipment, achieving the technical effect of instantly obtaining the status of the vehicle equipment. This solves the technical problem in related technologies where the vehicle equipment stops sending messages after a fault, and users cannot immediately understand the status of the vehicle equipment. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0019] Figure 1 This is a flowchart of a vehicle message processing method according to an embodiment of the present invention;

[0020] Figure 2 This is a schematic diagram of the structure of a vehicle infotainment system according to an embodiment of the present invention;

[0021] Figure 3 This is a structural block diagram of a vehicle message processing device according to an embodiment of the present invention;

[0022] Figure 4 This is a schematic diagram of a vehicle message processing system according to an embodiment of the present invention. Detailed Implementation

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

[0024] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0025] First, the technical terms appearing in the embodiments of this invention are explained as follows:

[0026] On-Board Unit (OBU): An OBU is a microwave device that uses Dedicated Short Range Communication (DSRC) technology to communicate with Roadside Units (RSUs). In the Electronic Toll Collection (ETC) system, the OBU is placed on the vehicle, and the Roadside Units communicate with each other via microwave. When a vehicle passes through an RSU at high speed, the OBU and RSU communicate via microwave to identify the vehicle's authenticity, obtain the vehicle type, calculate the toll rate, and deduct the toll, similar to a contactless card, but over a longer distance and at a higher frequency.

[0027] In the ETC system, the OBU uses DSRC technology to establish a microwave communication link with the RSU, enabling vehicle identification and electronic payment without stopping the vehicle during the journey. This achieves non-stop, cardless operation and establishes unmanned vehicle lanes.

[0028] Microcontroller Unit (MCU): Also known as a single-chip microcomputer or microcontroller, it is a chip-level computer that integrates a central processing unit (CPU) with a reduced frequency and specifications, along with memory, timer, Universal Serial Bus (USB), A / D converter, peripheral interfaces, and even liquid crystal display (LCD) driver circuitry, all on a single chip. This allows for different control combinations for various applications. MCUs are found in mobile phones, remote controls, automotive electronics, and industrial applications such as stepper motor and robotic arm control.

[0029] Controller Area Network (CAN) bus: Developed by Bosch, a German company renowned for its automotive electronics research and production, CAN became an international standard and is one of the most widely used fieldbuses internationally. In North America and Western Europe, the CAN bus protocol has become the standard bus for automotive computer control systems and embedded industrial control LANs, and there is also the J1939 protocol, designed specifically for large trucks and heavy machinery vehicles, based on CAN. In recent years, its high reliability and excellent error detection capabilities have gained attention, leading to its widespread application in automotive computer control systems and in harsh industrial environments with high temperatures, strong electromagnetic radiation, and high vibration.

[0030] The CAN bus system offers the following advantages: higher data transmission speed compared to traditional wiring methods; less wiring harness and reduced vehicle weight, while optimizing vehicle wiring; if one control unit connected via the CAN bus fails, the other control units can still send their data without interference; the CAN data bus is a two-wire system, and if one wire fails, the CAN system switches to single-wire operation, improving vehicle stability; the two wires of the CAN system are twisted together like a "braid" in practice, effectively preventing electromagnetic interference and outward radiation; and richer vehicle functions can be achieved based on the CAN bus system.

[0031] Message: A message is a data unit exchanged and transmitted in a network, that is, a block of data that a station sends at one time. A message contains complete data information to be sent, and its length varies, with no limit and variable length. Message authentication methods include traditional encryption authentication, message authentication codes using keys, authentication using one-way hash functions, and digital signature authentication. A message is also a unit of network transmission. During transmission, it is continuously encapsulated into packets, frames, and groups for transmission. Encapsulation involves adding information segments; these are the message headers, data organized in a specific format, completely synonymous with system-defined or user-defined data structures.

[0032] ZLGCANTest Software: ZLGCANTest is a universal testing software that integrates CAN interface card testing and ZLG CAN card driver functionality. It can resolve issues where the CAN interface card and computer cannot connect properly. If a connection fails, it will perform a rapid test and provide a test report. ZLGCANTest is the accompanying driver for the SBCAN-I / II intelligent CAN interface card and also features error detection capabilities, offering high flexibility. ZLGCANTest supports receiving, sending, viewing, analyzing, and recording CAN messages, helping users enhance the stability of CAN messages. ZLGCANTest features receive filter settings, normal send mode, file transfer, and DBC functions. The DBC function, designed for automotive electronics users, is highly convenient for analyzing and cracking automotive data and detecting vehicle status; it is the core function of ZLGCANTest.

[0033] Example 1

[0034] According to an embodiment of the present invention, a method embodiment for processing messages of a vehicle is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0035] Figure 1 This is a flowchart of a vehicle message processing method according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0036] Step S102: Obtain the real-time message output by the message processing module in the vehicle.

[0037] The system acquires real-time messages output by the vehicle's message processing module. This module primarily handles message preprocessing, extracting business information that can be converted to standard formats using the toolkit and displaying it. It also includes functions for refining message standards, comprising two sub-modules: message standard management and document management. Real-time messages characterize the connection status between the vehicle and onboard equipment, allowing users to monitor this connection in real time.

[0038] In one optional embodiment, the real-time messages output by the vehicle's message processing module can be obtained through the vehicle's infotainment system. The OBU device sends a message frame to the CAN bus every 100ms, containing the OBU's status information. Since the vehicle's infotainment system is also connected to the CAN bus, it can receive the messages sent by the OBU device. The CAN message format is a string of hexadecimal numbers, for example: 88 00 0C 00 BB 0C 00 00. Each pair of numbers represents one byte, for a total of 8 bytes. Each byte is 8 bits in binary; for example, hexadecimal "0C" converted to binary should be 00001100. Spaces are used to separate the bytes for easier identification; in practice, they are not separated.

[0039] The aforementioned vehicle-mounted equipment is used to realize the communication function between the vehicle and the roadside equipment. The roadside equipment can refer to roadside toll collection equipment, roadside charging equipment and other roadside intelligent facilities. The roadside equipment may include cameras, millimeter-wave radar, a small number of lidar, environmental sensing equipment, intelligent signs and markings and other devices.

[0040] In one optional embodiment, the vehicle-mounted device can refer to a pre-installed ETC device (i.e., an OBU device), a smart rearview mirror, a vehicle air purifier, a vehicle refrigerator, a vehicle vacuum cleaner, a vehicle massager, etc. Taking the OBU device as an example, the device is connected to the vehicle's CAN bus and can be used to detect whether the OBU device has been activated after the vehicle's power supply provides power to the OBU device. If it has not been activated, an inactivation notification is sent back via the CAN bus.

[0041] In an optional embodiment, taking the OBU device as an example, after the vehicle's power supply supplies power to the OBU device, it checks whether the OBU device has been disassembled to obtain the tamper check result. If the tamper check result indicates that the OBU device has been disassembled, the corresponding tamper failure notification is fed back to the display device via the CAN bus.

[0042] The tamper failure notification can be provided in the form of text (e.g., at least one of text, numbers, letters, etc.) and / or images (e.g., at least one of pictures, patterns, graphics, etc.). For example, after the tamper inspection result is obtained, the display device may show "Inspection completed, device not disassembled" or "Inspection completed, device has been disassembled". The methods for checking whether the OBU device has been disassembled can be varied. For example, the OBU device can send and / or receive signals through a certain line (the continuity of which is related to whether the OBU device has been disassembled). If the signal is successfully sent (e.g., received by the vehicle terminal) and / or successfully received, it is determined that it has not been disassembled. Disassembly can also be determined based on the electrical parameters of the power supply received by the OBU device (e.g., if the power supply voltage is below a threshold, it is determined that it has been disassembled).

[0043] The aforementioned display device can be any device capable of displaying information, such as an instrument panel, display screen, central control screen, head-up display, etc.

[0044] In an optional embodiment, the OBU device can also be used to: after the vehicle's power supply provides power to the OBU device, perform a self-check to see if the OBU device has malfunctioned, obtain a fault check result, and if the fault check result indicates that the OBU device has malfunctioned, then send a corresponding fault notification to the display device via the CAN bus.

[0045] The term "fault" can refer to any fault in the OBU device's software and / or hardware, as long as it can be detected through self-testing. The fault notification displayed on the display device can be in the form of text (e.g., at least one of text, numbers, letters, etc.) and / or images (e.g., at least one of pictures, patterns, graphics, etc.). For example, the display device can show the text "Device No Fault" or "Device XX has malfunctioned."

[0046] In one optional embodiment, if the OBU device is successfully scanned by the roadside equipment at the toll gate when the OBU device is activated, a corresponding normal passage notification is output through the display device and / or the vehicle's audio feedback device; if the OBU device is not successfully scanned by the roadside equipment at the toll gate when the OBU device is activated, a corresponding abnormal passage notification is output through the display device and / or the vehicle's audio feedback device.

[0047] The normal access notification provided by the display device can be in the form of text (e.g., at least one of text, numbers, letters, etc.) and / or images (e.g., at least one of pictures, patterns, graphics, etc.). The sound feedback device can be understood as any device capable of providing sound feedback, such as a buzzer, a speaker, or other device equipped with a speaker. The normal access notification provided by the sound feedback device can be a buzzer sound or a specific voice message; for example, a normal access notification is a single "beep," and an abnormal access notification is three "beep beep beep" sounds.

[0048] In one optional embodiment, if the OBU device is activated and successfully scanned by the roadside equipment at the toll exit, the consumption amount information is displayed on the vehicle's screen via the CAN bus. This display can be in the form of text (e.g., characters, numbers, letters, etc.) and / or images (e.g., pictures, patterns, graphics, etc.). For example, after a successful transaction, the vehicle's screen displays "Consumption Amount: XX Yuan". If the OBU device is activated and successfully scanned by the roadside equipment at the toll exit, a corresponding consumption notification is displayed via the vehicle's audio feedback device via the CAN bus. This notification can be in the form of a buzzer and / or a specific voice message. For example, upon successful transaction, the voice announces "Consumption Amount: XX Yuan".

[0049] The aforementioned real-time messages include: normal messages uploaded in real time by the on-board equipment to the message processing module or fault messages generated by the control message processing module.

[0050] If the message processing module does not receive a normal message uploaded by the vehicle device within a preset time period, it indicates that the connection between the vehicle device and the CAN bus has failed, and the message processing module can be controlled to generate a fault message.

[0051] The preset duration is a specific time period set by the developer, which can be 3 seconds. If no normal message is received from the vehicle device within this time period, it indicates that the connection between the vehicle device and the CAN bus has failed.

[0052] In one optional embodiment, a message generation method can be used to control the message processing module to generate fault messages. The method includes the following steps: abstractly classifying and dividing various message fields of specific message formats of various data communication protocols into bit message fields, byte message fields, string message fields, length message fields, and checksum message fields; classifying each message field of the specific message format of the data communication protocol to be generated into bit message fields, byte message fields, string message fields, length message fields, and checksum message fields; and organizing the complete byte stream of the data communication protocol message according to the input parameter values ​​of each message field of the specific message format of the data communication protocol to be generated in its respective bit message field, byte message field, string message field, length message field, and checksum message field.

[0053] The control message processing module generates a fault message, which includes: the control message processing module obtaining the preset message from the cache module; and modifying the preset message based on preset rules to obtain the fault message.

[0054] In one optional embodiment, a CAN card can be connected to the vehicle's CAN or debug port to obtain CAN messages using the ZLGCANTest software interface. A message caching method can be used to cache messages in a caching module. This method includes the following steps: parsing the received messages to determine their priority; if the occupancy of the cache queue is greater than or equal to the packet loss threshold corresponding to the priority, the message is discarded. Here, the cache queue refers to a queue composed of a series of message data, and the queue data length can be set manually. A cache queue can be used when only the most recent cached data needs to be retained, or when the data length needs to be limited due to capacity issues; if the occupancy of the cache queue is less than the packet loss threshold corresponding to the priority, the message is written to the cache queue; among adjacent priorities, the packet loss threshold corresponding to the higher priority is greater than the packet loss threshold corresponding to the lower priority. This method ensures the caching and processing of high-priority protocol messages, improving the reliability of network devices.

[0055] The above-mentioned modification of preset messages based on preset rules to obtain fault messages means that when the application does not receive messages sent by the OBU device, it considers the OBU device to be disconnected. At this time, the cached messages are changed to a set of specific fault messages, such as "00 00 00 0000 00 00 00".

[0056] The OBU device sends CAN messages every 100ms, equivalent to 10 times per second. If the vehicle's infotainment system (VIS) were to receive and parse every single frame, the workload would be enormous, significantly impacting its performance. To address this, we optimized the VIS system by adding a caching module. After optimization, the CAN message is only returned to the Android application when it changes. This optimization significantly improved the VIS's performance, but it also introduced a problem: if the OBU device suddenly experiences a physical disconnection (disconnection or line breakage), the VIS's cached data will contain the last frame sent by the OBU. This frame might indicate that the device is functioning normally, leading to a serious issue: the user perceives the device as normal, but the device is unusable, and neither the VIS application nor the user knows the cause of the problem.

[0057] The reporting of OBU device messages is optimized at the vehicle system's underlying layer. This means that the vehicle system's underlying layer is theoretically able to receive all messages from the OBU device. Therefore, we can process the messages at the underlying layer. If the vehicle system's underlying layer does not receive messages from the OBU device for a long time (let's say 3 seconds), we assume that the OBU device has disconnected. At this time, we change the cached messages to a specific set of fault messages, for example, "00 00 00 00 00 00 00 00", which are all zeros. In this way, when the Android upper-layer application obtains the OBU device's status information, if it finds that the message is all zeros, it assumes that the OBU device has disconnected.

[0058] By employing the above methods, not only is the performance of the vehicle's infotainment system optimized, but all fault scenarios of the OBU device are also taken into account, enabling a more user-friendly interactive experience and facilitating human-machine interaction. For example, when an OBU device is detected as inactive, an inactivation notification can be sent to the display device via the CAN bus. This demonstrates that human-machine interaction is achieved through the vehicle's CAN bus and in conjunction with in-vehicle devices, avoiding the inconvenience of interaction associated with pre-installed OBUs.

[0059] Step S104: Determine whether the real-time message is consistent with the preset message in the cache module.

[0060] The above judgment determines whether the real-time message is consistent with the preset message in the cache module. The cache module includes multiple historically cached messages, and the preset message is the last message cached to the cache module among the multiple messages.

[0061] If the real-time message is a normal message, the application determines that the connection between the vehicle and the on-board equipment is in a normal state by parsing the real-time message; or, if the real-time message is a fault message, the application determines that the connection between the vehicle and the on-board equipment is in a fault state by parsing the real-time message.

[0062] Among them, a normal message refers to a real-time message that is consistent with the preset message in the cache module. By parsing the real-time message, it can be determined that the connection status between the vehicle and the on-board equipment is in a normal state. A fault message refers to a real-time message that is inconsistent with the preset message in the cache module. By parsing the real-time message, it can be determined that the connection status between the vehicle and the on-board equipment is in a fault state.

[0063] The application retrieves a preset message from the cache module after a preset time interval, and determines the connection status between the vehicle and the on-board equipment by parsing the preset message.

[0064] If the real-time message matches the preset message, the real-time message will be cached in the cache module.

[0065] In an optional embodiment, the message can be parsed using Java code to determine the connection status between the vehicle and the on-board unit. In the message sent by the OBU device, the sixth byte from the left contains bits 4-6 from the left, which represent the OBU device status. The value of bits 4-6 is represented by Java code as 0x07&((obuState[5])>>2); obuState is an 8-byte CAN message, obuState[5] represents the sixth byte, and ((obuState[5])>>2) is an operation of shifting this byte 2 bits to the right and then performing an AND operation with hexadecimal 7 to obtain the desired value. The meaning of this value is shown in Table 1. The "Self-testing" state is a momentary state, which means that the device is performing a self-test and can be ignored. "No anti-tamper matching" means that the OBU device has not been matched with anti-tamper protection. In order to prevent users from moving the OBU device to evade or miss charges, the anti-tamper pin is usually pressed down to fix the OBU device to the windshield and activate it. When the OBU device is removed, the anti-tamper pin pops open and the OBU device triggers the anti-tamper failure mechanism.

[0066] Table 1. Meaning of different values

[0067] numerical values 1 2 3 4 5 meaning Self-checking Activated No anti-tamper matching Equipment hardware failure Not activated

[0068] In one optional embodiment, the method for detecting whether it has been activated can be arbitrary. For example, it can detect the value of the flag bit (indicating whether it has been activated) stored in the OBU device. If the value indicates that it has been activated, it is determined that it has been activated. If the value indicates that it has not been activated, it is determined that it has not been activated. For another example, the OBU device can detect whether it has received and stored the card information and / or electronic tag information required for the implementation of the ETC function. If it has not been stored, it is determined that it has not been activated. If it has been stored, it is determined that it has been activated.

[0069] Figure 2 This is a schematic diagram of the structure of a vehicle infotainment system according to an embodiment of the present invention, such as... Figure 2 As shown, the upper-layer application does not communicate directly with the OBU device, but instead registers a listener through the MCU. The OBU device reports messages every 100ms, which are processed by the MCU. The processing logic is as follows: the acquired message is compared with the cache. If they match, the real-time message is cached in the cache module and no further steps are taken. If they do not match, the cache is updated and the message is reported to the application layer. The upper-layer application can also actively acquire a CAN message frame from the cache in the MCU. The message processing module has a timeout mechanism. Because a listener is registered, if no message is received from the OBU device within a certain time (tentatively 3 seconds), the message processing module will update the cache, write the incorrect message, and report a message frame at the same time.

[0070] Among them, listening is a mode that can capture messages sent by the OBU device in real time.

[0071] Step S106: In response to the inconsistency between the real-time message and the preset message, the real-time message is reported to the vehicle's application.

[0072] In response to a discrepancy between the real-time message and the preset message, after reporting the real-time message to the vehicle's application, the above method further includes: caching the real-time message to a cache module for subsequent comparison.

[0073] If the real-time message differs from the preset message, it indicates that the real-time message is faulty. In this case, the real-time message can be actively uploaded to the application via the CAN bus so that the application can quickly inform the user of the vehicle equipment connection failure and cache the faulty message in the cache module. If the fault is repaired after being reported, and the faulty message differs from the normal message, the application can also quickly inform the user of the vehicle equipment connection failure and that normal operation has been restored after repair.

[0074] By employing the above steps, the system obtains real-time messages output by the vehicle's message processing module and determines whether these messages are consistent with preset messages in the cache module. If the real-time messages are inconsistent with the preset messages, it indicates that the real-time messages are faulty messages. The vehicle system's underlying layer can then report these real-time messages to the vehicle's application program. This enables the vehicle system's underlying layer to promptly report faulty messages from the in-vehicle equipment to the application program, eliminating the need for the application program to periodically retrieve these messages from the vehicle system's underlying layer. This ensures that the application program can promptly obtain faulty messages from the in-vehicle equipment, achieving the technical effect of instantly obtaining the status of the in-vehicle equipment. Consequently, this solves the technical problem in related technologies where in-vehicle equipment stops sending messages after a fault, preventing users from instantly understanding the status of the in-vehicle equipment.

[0075] Example 2

[0076] According to another aspect of the present invention, a message processing device for a vehicle is also provided. This device can execute the information push method in the above embodiments. The specific implementation scheme and application scenarios are the same as those in the above embodiments, and will not be described in detail here.

[0077] Figure 3 This is a structural block diagram of a vehicle message processing device according to an embodiment of the present invention. Figure 3 As shown, the device includes: an acquisition module 302, used to acquire real-time messages output by the message processing module in the vehicle, wherein the real-time messages are used to characterize the connection status between the vehicle and the on-board equipment, including normal messages uploaded by the on-board equipment to the message processing module in real time or fault messages generated by the control message processing module; a judgment module 304, used to judge whether the real-time messages are consistent with the preset messages in the cache module, wherein the cache module includes multiple messages cached in history, and the preset message is the last message cached to the cache module among the multiple messages; and a reporting module 306, used to report the real-time messages to the vehicle's application in response to the inconsistency between the real-time messages and the preset messages, wherein the application determines the connection status between the vehicle and the on-board equipment by parsing the real-time messages.

[0078] The device also includes a control module, which controls the message processing module to generate a fault message in response to the message processing module not receiving a normal message uploaded by the vehicle-mounted device within a preset time period.

[0079] The device also includes a caching module, which, in response to a discrepancy between the real-time message and a preset message, caches the real-time message in the caching module after reporting the real-time message to the vehicle's application.

[0080] The caching module is also used to cache real-time messages in response to the consistency between real-time messages and preset messages.

[0081] The control module includes: a control unit, used to control the message processing module to obtain preset messages from the cache module; and a modification unit, used to modify the preset messages based on preset rules to obtain fault messages.

[0082] Example 3

[0083] According to another aspect of the present invention, a vehicle message processing system is also provided. Figure 4 This is a schematic diagram of a vehicle message processing system according to an embodiment of the present invention, as shown below. Figure 4 As shown, it includes: a message processing module for outputting real-time messages, wherein the real-time messages are used to characterize the connection status between the vehicle and the in-vehicle equipment; a controller for determining whether the real-time messages are consistent with preset messages in the cache module, wherein the cache module includes multiple historically cached messages; the preset message is the last message cached to the cache module among the multiple messages; in response to the inconsistency between the real-time messages and the preset messages, the real-time messages are reported to the vehicle's application; and the application is used to determine the connection status between the vehicle and the in-vehicle equipment by parsing the real-time messages.

[0084] Example 4

[0085] According to another aspect of the present invention, a vehicle is also provided, comprising: one or more processors; a storage device for storing one or more programs; and a message processing method for the vehicle, wherein the one or more programs are executed by the one or more processors, causing the one or more processors to perform any of the above-described methods.

[0086] Example 5

[0087] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored program, wherein, when the program is running, it controls the device where the computer-readable storage medium is located to execute the above-described information push method.

[0088] Example 6

[0089] According to another aspect of the present invention, a processor is also provided, which is used to run a program, wherein the program executes the above-described information push method during runtime.

[0090] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0091] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0092] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0093] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0094] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0095] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0096] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A message processing method of a vehicle, characterized by, The method comprises the following steps: acquiring a real-time message output by a message processing module in a vehicle, wherein the real-time message is used to represent a connection state between the vehicle and a vehicle-mounted device, and the vehicle-mounted device comprises a vehicle-mounted unit, which is used to represent a microwave device for communicating with a roadside unit; determining whether the real-time message is consistent with a preset message in a cache module, wherein the cache module comprises a plurality of historically cached messages, and the preset message is a message last cached to the cache module among the plurality of messages; in response to the real-time message being inconsistent with the preset message, determining that the real-time message is a fault message, and reporting the fault message to an application program of the vehicle, wherein the application program determines the connection state between the vehicle and the vehicle-mounted device by analyzing the fault message, and the fault message is used to represent that the connection state between the vehicle and the vehicle-mounted device is in a fault state; in response to the real-time message being consistent with the preset message, determining that the real-time message is a normal message, and caching the normal message to the cache module, wherein the normal message is used to represent that the connection state between the vehicle and the vehicle-mounted device is in a normal state; The method further comprises: in response to the message processing module not receiving the normal message uploaded by the vehicle-mounted device within a preset time length, determining that the connection state between the vehicle and the vehicle-mounted device is in the fault state, and controlling the message processing module to generate the fault message, wherein the fault state is used to represent a state in which the vehicle-mounted device is disconnected from the vehicle; caching the real-time message to the cache module, comprising: analyzing the received real-time message to determine the priority of the real-time message; if the occupancy of the self-cache queue is greater than or equal to the packet loss threshold corresponding to the priority, the real-time message is discarded, wherein the cache queue refers to a queue composed of a string of message data, and the queue data length can be set by itself. When only the latest cached data needs to be retained or the data length needs to be limited due to capacity problems, the cache queue can be used; if the occupancy of the self-cache queue is less than the packet loss threshold corresponding to the priority, the real-time message is written into the cache queue; wherein in adjacent priorities, the packet loss threshold corresponding to a high priority is greater than the packet loss threshold corresponding to a low priority.

2. The method of claim 1, wherein, The real-time message comprises a normal message uploaded by the vehicle-mounted device to the message processing module in real time or a fault message generated by controlling the message processing module.

3. The method of claim 1, wherein, In response to the real-time message being inconsistent with the preset message, after reporting the real-time message to the application program of the vehicle, the method further comprises: caching the real-time message to the cache module.

4. The method of claim 1, wherein, The method further comprises: in response to the real-time message being consistent with the preset message, caching the real-time message to the cache module.

5. The method of claim 2, wherein, Controlling the message processing module to generate the fault message comprises: controlling the message processing module to acquire the preset message of the cache module; based on a preset rule, changing the preset message to obtain the fault message.

6. The method of claim 2, wherein, In a case where the real-time message is the normal message, the application program determines, by analyzing the real-time message, that the connection state between the vehicle and the vehicle-mounted device is in a normal state; Or, in a case where the real-time message is the fault message, the application program determines, by analyzing the real-time message, that the connection state between the vehicle and the vehicle-mounted device is in a fault state.

7. The method of claim 1, wherein, The application program acquires the preset message from the cache module at intervals of a preset time length, and determines the connection state between the vehicle and the vehicle-mounted device by analyzing the preset message.

8. A message processing system of a vehicle, characterized by comprising: Comprise: A message processing module is configured to output a real-time message, wherein the real-time message is used to represent a connection state between a vehicle and a vehicle-mounted device, and the vehicle-mounted device comprises a vehicle-mounted unit, which is used to represent a microwave device for communicating with a roadside unit; A controller is configured to determine whether the real-time message is consistent with a preset message in a cache module, wherein the cache module comprises a plurality of historically cached messages, the preset message is a message that is last cached in the cache module among the plurality of messages, in response to the real-time message being inconsistent with the preset message, the real-time message is determined to be a fault message, and the fault message is reported to an application program of the vehicle, wherein the application program is configured to determine the connection state between the vehicle and the vehicle-mounted device by analyzing the fault message, and the fault message is used to represent that the connection state between the vehicle and the vehicle-mounted device is in a fault state, in response to the real-time message being consistent with the preset message, the real-time message is determined to be a normal message, and the normal message is cached in the cache module, and the normal message is used to represent that the connection state between the vehicle and the vehicle-mounted device is in a normal state; The system is further configured to determine that the connection state between the vehicle and the vehicle-mounted device is in the fault state in response to the message processing module not receiving the normal message uploaded by the vehicle-mounted device within a preset time length, and to control the message processing module to generate the fault message, wherein the fault state is used to represent a state in which the vehicle-mounted device is disconnected from the vehicle; The system is further configured to analyze the received real-time message to determine a priority of the real-time message, to discard the real-time message if an occupancy of a cache queue is greater than or equal to a packet loss threshold corresponding to the priority, wherein the cache queue refers to a queue composed of a string of message data, and a queue data length can be set by itself, and the cache queue can be used when only recent cache data needs to be retained or the data length needs to be limited due to capacity problems, and to write the real-time message into the cache queue if the occupancy of the cache queue is less than the packet loss threshold corresponding to the priority, wherein in adjacent priorities, the packet loss threshold corresponding to a high priority is greater than the packet loss threshold corresponding to a low priority.

9. A vehicle characterized by comprising: Comprise: One or more processors; A storage device configured to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors perform the message processing method of any one of claims 1-7.

Images