Vehicle data processing method and device based on TBox, automobile and readable storage medium

Abstract

The application relates to the technical field of new energy vehicles, and provides a vehicle data processing method and device based on a TBox, a vehicle and a readable storage medium. The method comprises the following steps: a data collection thread sequentially performs prescribed processing on vehicle message data collected by the TBox, including storing the vehicle message data in a global static area storage space, and sending a corresponding signal value to a pre-constructed buffer queue after each vehicle message data is processed, the signal value being associated with a vehicle message data in the global static area storage space; a monitor thread sequentially responds to the signal value in the buffer queue, and calls a blocking interface or a non-blocking interface to respond to a data request of an upper-layer application of a TBox system to the vehicle message data. According to the application, stable and accurate data collection of the data collection thread can also respond to data interaction requirements of a layer application through the monitor thread, so that the thread CPU occupation pressure is greatly reduced, and the system is more stable and reliable.

Description

Technical Field

[0001] This application relates to the field of new energy vehicle technology, and in particular to a vehicle data processing method, device, vehicle, and readable storage medium based on TBox. Background Technology

[0002] According to the national standard GB32960.3, new energy vehicles are required to report vehicle data, which includes:

[0003] 1. Routine vehicle status: Routine vehicle status information such as speed, total mileage, location, vehicle status, and SOC;

[0004] 2. Information related to the three main electrical components: such as battery voltage / current / motor speed / motor torque / charging information, etc.;

[0005] 3. Alarm information: Level 1 / Level 2 / Level 3 vehicle alarms, and vehicle status information at the time of the alarm.

[0006] Therefore, data collection is necessary both to comply with relevant national regulations and to ensure the personal safety of users, and to better serve users by providing intelligent services.

[0007] Currently, the collection of vehicle data is defined by business needs, with R&D handling the collection and reporting. Whether it's manual or automatic data tracking, the common attribute is that the data is defined, its meaning is clear, and its content is understandable. However, a vehicle consists of dozens of ECUs of varying sizes, each capable of generating numerous signals at different frequencies (e.g., 10ms / 20ms / 50ms / 100ms / 200ms). A typical car requires the collection of anywhere from a few thousand to tens of thousands of signals, posing a significant cost challenge for data collection, reporting, and transmission.

[0008] Specifically, if a vehicle collects data every 20ms, gathering 5000 signals per collection, the instantaneous throughput per second would reach 250,000 data points, based on a conventional data structure design. The embedded chip faces numerous challenges in handling these tens of thousands of data points, including instantly receiving raw messages, storing them in memory, processing each received message while simultaneously ensuring normal message reception, and dealing with intermittent interactions from other upper-layer applications. Clearly, such a large volume and high frequency of data places extremely high demands on the MPU's performance, placing immense pressure on the vehicle's data acquisition thread. This thread must not only reliably receive data but also strive to monitor the received data as quickly as possible and respond to the needs of upper-layer applications.

[0009] For example, see Figure 1This describes an existing TBox data acquisition model. In this model, the upper-layer receiving chip of the TBox sequentially processes vehicle message data through a data receiving and unpacking module, a data security verification module, a global memory storage module, a special data monitoring module, and a service upload application module. The same processing is then applied to the next vehicle message. This TBox data acquisition model has the following problems in practical use:

[0010] First, the reading and writing of the data acquisition module requires read-write locks to protect variables. When storing data, generally only read locks are used, and when used as monitoring data, generally only write locks are used. Frequently operating on different locks in the same thread will greatly increase the CPU waiting probability of each action of the current thread. In severe cases, it will affect the real-time performance of data acquisition, causing new data to be unable to be updated and the response to be extremely poor.

[0011] Secondly, for the data acquisition module to achieve stable data acquisition, the program needs to spend most of its time processing data and doing as little other work as possible. On the other hand, the more accurate the acquisition of each signal, the more CPU time is required to frequently collect the latest data and process the relationships between data logic. The two are inherently contradictory, and how developers can balance the proportion of each has always been a challenge.

[0012] Furthermore, the data acquisition module typically uses global variables to iterate through the interface of the upper-layer application. A better approach would be to provide a non-blocking interface that allows each module to register the value changes and threshold triggers of the packets it wants to monitor without consuming too much of its own time.

[0013] Finally, data acquisition should not consume too much SoC memory. Excessive CPU usage can cause device lag, such as disrupting the normal operation of high-precision timers and GNSS (Global Navigation Satellite System) acquisition processes. Furthermore, excessive memory and CPU usage can easily lead to various system malfunctions, such as deadlocks caused by frequent I / O, abnormal interruptions, and array access out of bounds.

[0014] It is evident that achieving stable data acquisition requires the program to spend most of its time processing data, minimizing other tasks. Conversely, achieving precise acquisition of each signal necessitates spending more CPU time frequently collecting the latest data and processing the relationships between data logic. These two approaches are inherently contradictory. Therefore, finding a balance between these two approaches to achieve stable and accurate data acquisition while simultaneously meeting the data interaction needs of responsive applications is a significant technical challenge in the current development of new energy vehicles. Summary of the Invention

[0015] In view of this, embodiments of this application provide a vehicle data processing method, device, vehicle, and readable storage medium based on TBox, to solve the problem of how the TBox system in new energy vehicles can stably and accurately collect data while also responding to the data interaction needs of layer applications.

[0016] A first aspect of this application provides a vehicle data processing method based on a TBox, comprising:

[0017] A data acquisition thread is established to sequentially process the vehicle message data collected by the TBox, and after processing each vehicle message data, a corresponding signal value is sent to a pre-built buffer queue. The specified processing includes storing the vehicle message data in a global static area storage space, and the signal value is associated with a vehicle message data stored in the global static area storage space.

[0018] A monitor thread is created to respond to the signal values ​​in the buffer queue in sequence, and calls the blocking interface or non-blocking interface to respond to the data request for the vehicle message data from the upper layer application where the TBox system is located. The data acquisition thread and the monitor thread share the global static area storage space.

[0019] A second aspect of this application provides a vehicle data processing device based on a TBox, comprising:

[0020] The first processing module is configured to open a data acquisition thread to sequentially process the vehicle message data collected by the TBox, and after processing each vehicle message data, send a corresponding signal value to a pre-built buffer queue. The specified processing includes storing the vehicle message data in a global static area storage space, and the signal value is associated with a vehicle message data stored in the global static area storage space.

[0021] The second processing module is configured to open a monitor thread to respond sequentially to the signal values ​​in the buffer queue, and call a blocking interface or a non-blocking interface to respond to the data request for the vehicle message data from the upper layer application where the TBox system is located. The data acquisition thread and the monitor thread share the global static area storage space.

[0022] A third aspect of this application provides an automobile including a TBox system. The TBox system includes a TBox bottom-level acquisition chip and a TBox top-level receiving chip, which are connected. The TBox top-level receiving chip includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the above-described method.

[0023] A fourth aspect of this application provides a readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0024] The beneficial effects of this application embodiment compared with the prior art are as follows: The above-mentioned vehicle data processing method based on TBox decouples the data storage and monitoring functions during vehicle data acquisition into two threads, forming a single producer-dual consumer queue-single consumer model. This allows the data acquisition thread to be only responsible for receiving and storing data, while the monitor thread independently completes data monitoring and provides services to the upper layer. As a result, the situation where a certain thread has to handle high-frequency data reading and writing in real time, as well as high-frequency reading and monitoring data and providing real-time query functions, is no longer present. This greatly reduces the CPU usage pressure of the threads and makes the system more stable and reliable. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is an architecture diagram of the existing TBox data acquisition model;

[0027] Figure 2 This is an architecture diagram of a decoupled TBox dual-thread model according to an embodiment of this application;

[0028] Figure 3 This is a flowchart of a vehicle data processing method based on a TBox provided in an embodiment of this application;

[0029] Figure 4 This is an architecture diagram of another decoupled TBox dual-thread model provided in the embodiments of this application;

[0030] Figure 5 This is an architecture diagram of a finite blocking interface iteration model according to an embodiment of this application;

[0031] Figure 6 This is an architecture diagram of an existing TBox blocking remote control execution model;

[0032] Figure 7 This is an architecture diagram of a TBox non-blocking remote control execution model provided in an embodiment of this application;

[0033] Figure 8 This is a schematic diagram of the structure of a vehicle data processing device based on a TBox provided in an embodiment of this application;

[0034] Figure 9 This is a partial structural diagram of a car provided in an embodiment of this application;

[0035] Figure 10 This is an architecture diagram of a complete TBox dual-thread model provided in an embodiment of this application;

[0036] Figure 11 This is a schematic diagram of the structure of a TBox upper layer receiving chip provided in an embodiment of this application. Detailed Implementation

[0037] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0038] See Figure 2 In one application scenario of this application, a decoupled TBox dual-thread model is provided, including a TBox lower-level acquisition chip and a TBox upper-level receiving chip. The TBox upper-level receiving chip is connected to the TBox lower-level acquisition chip, which is connected to the control chip network of various control domains on the vehicle via a communication bus to receive vehicle message data sent by each control chip. The TBox lower-level acquisition chip then transmits the vehicle message data to the TBox upper-level receiving chip, which processes the received vehicle message data by running a program. Specifically, an architecture with two threads and one storage space is provided. The two threads are a data acquisition thread and a monitoring server thread, respectively. The storage space is a global static area storage space shared by both threads.

[0039] The data acquisition thread is responsible for data reception, validity verification, and data storage. It features high real-time performance, fast execution speed, and the ability to quickly enter the next loop. After processing each vehicle message, it only needs to send a signal value to the buffer queue to notify the monitoring server thread.

[0040] The monitoring server thread acts as a monitor thread, using a buffer queue to address speed mismatches. Because of the buffer queue, there is no need to worry about missing collected vehicle message data, so each signal can be carefully processed within this thread, updating the latest status value of the current vehicle more frequently.

[0041] The working principle of the aforementioned TBox dual-thread model is as follows: After the data acquisition thread stores a vehicle message, it notifies the monitoring server thread using a buffer queue. The monitoring server thread processes the data based on the incoming CAN message ID index, allowing it to further handle issues such as signal transitions, trigger thresholds, or provide query interfaces to upper-layer applications. Thus, the two threads share a global static area storage space, using read-write locks to achieve data synchronization and mutual exclusion. Compared to existing TBox data acquisition models, this application scenario eliminates the need for a single thread to simultaneously handle high-frequency data read / write operations and provide real-time query functionality, significantly reducing CPU usage and making the system more stable and reliable.

[0042] The data receiving and unpacking module, data security verification module, global memory storage module, special data monitoring module, and service upload application module sequentially perform unpacking, verification, storage, monitoring, and distribution of the vehicle message data. Specifically, the upper-layer applications of the TBox system include, but are not limited to, message alarm modules, remote modules, data reporting modules, and ECall modules. These modules can fulfill their respective business requirements by querying the vehicle message data stored in the global memory storage module by the upper-layer receiving chip of the TBox.

[0043] Vehicle message data is typically collected from various control domains within the vehicle. Each control domain manages specific vehicle functions and generates corresponding data. This data is collected by the controller of each control domain at a set frequency and sent to the communication bus connected to the underlying acquisition chip of the TBox for collection. For example, Figure 1 The TBox's underlying acquisition chip collects vehicle message data, such as BCM domain data, PLG domain data, and VCU domain data, from the vehicle via the CAN bus.

[0044] See Figure 3 In the first embodiment of this application, a vehicle data processing method based on TBox is provided, including the following steps:

[0045] S101, a data acquisition thread is opened to process the vehicle message data collected by TBox in sequence, and after processing each vehicle message data, a corresponding signal value is sent to the pre-built buffer queue. The processing includes storing the vehicle message data in a global static area storage space, and the signal value is associated with a vehicle message data stored in the global static area storage space.

[0046] S102, a monitor thread is created to respond to the signal values ​​in the buffer queue in sequence, and calls the blocking interface or non-blocking interface to respond to the data request of the upper layer application of the TBox system for the vehicle message data. The data acquisition thread and the monitor thread share the global static area storage space.

[0047] Specifically, data requests from upper-layer applications include blocking data requests and non-blocking data requests, meaning that the application needs to obtain the latest vehicle message data to update its services.

[0048] The vehicle data processing method provided in this embodiment decouples the data storage and monitoring functions during vehicle data acquisition into two threads, forming a single producer-dual consumer queue-single consumer model. This allows the data acquisition thread to be responsible only for receiving and storing data, while the monitor thread independently completes data monitoring and provides services to the upper layer. As a result, the situation where a single thread has to handle high-frequency data reading and writing in real time, as well as high-frequency reading and monitoring data and providing real-time query functions, is no longer present. This greatly reduces the CPU usage pressure on the threads and makes the system more stable and reliable.

[0049] In step S101 above, the prescribed processing of vehicle message data includes at least one of the following: receiving, unpacking, security verification, and storage. For example, the prescribed processing in this embodiment includes sequentially receiving, verifying, and storing the vehicle message data. Specifically, in conjunction with... Figure 2In this process, the data acquisition thread receives and unpacks vehicle message data transmitted from the TBox's underlying acquisition chip. This involves parsing and unpacking the vehicle message data according to the protocol specifications. Unpacking involves analyzing the received data frames and extracting valid information such as message ID, data length, and data content. Next, the vehicle message data undergoes security verification to ensure its integrity and authenticity. For example, vehicle message data security verification includes data integrity verification and data authentication. Data integrity verification can use verification algorithms, cyclic redundancy check algorithms, or hash algorithms to ensure that the data has not been tampered with during transmission. Data authentication can use digital signatures or other encryption algorithms to verify the source and authenticity of the data, preventing data forgery. Furthermore, during these vehicle message data verification processes, the system can decide whether to accept or discard the received vehicle message data based on the verification results. Finally, the verified vehicle message data is stored in the global static area storage space, completing the prescribed processing of the vehicle message data.

[0050] In a program, a buffer queue is typically a data structure used to temporarily store the signal values ​​corresponding to vehicle message data that has been processed by the data acquisition thread and stored in the global static storage area, so as to notify the monitor thread to process it. Specifically, the signal value in the buffer queue is a marker indicating the state of a vehicle message data after the data acquisition thread has performed specified processing. This marker notifies the monitor thread to process the corresponding vehicle message data based on the signal value index, including but not limited to handling issues such as signal transitions, trigger thresholds, or providing query interfaces for upper-layer applications. Therefore, the signal value can be an index marker corresponding to the vehicle message data.

[0051] Furthermore, the data structure type of the buffer queue is not unique. For example, in one alternative embodiment, an array can be constructed as the buffer queue. Of course, in practice, the buffer queue can also be other types of data structures, and this application embodiment does not limit this.

[0052] The global static area storage space is used to store global static variables and static objects, so that vehicle message data can be shared and accessed by different threads and modules, such as by the data acquisition thread and the monitor thread, thereby realizing the storage and monitoring of vehicle message data.

[0053] See Figure 4 In some optional embodiments, based on the processing specified in step S10, before storing the vehicle message data in a global static area storage space, the method further includes:

[0054] Identify whether the valid bit length of the vehicle message data is less than or equal to a preset length, which is an integer multiple of the length of a single byte;

[0055] If so, the vehicle message data is compressed into a message of the preset length in bytes and then stored in the global static area storage space.

[0056] If not, the vehicle message data will be stored directly in the global static area storage space.

[0057] Specifically, in combination Figure 2 In general, the specifications of vehicle message data collected and sent to the CAN data bus by different control domains are different. Some vehicle message data has a longer effective bit length, while some vehicle message data has a shorter effective bit length. Therefore, if the same storage space is provided for these two different types of messages, it will lead to a waste of global static area storage space.

[0058] In one optional embodiment, assuming the vehicle message data is an 8-byte message with a preset length of 16 bits (2 bytes), when the effective bit length of the vehicle message data is less than or equal to 16 bits, the 8-byte message is forcibly converted to a 2-byte message. For example, the high 6 bytes are deleted, and the message is compressed into a 2-byte message to obtain compressed vehicle message data. The compressed vehicle message data is then stored in the global static area storage space. In addition, when the effective bit length of the vehicle message data is greater than 16 bits, the 8-byte format vehicle message data is retained, and the uncompressed vehicle message data is stored in the global static area storage space.

[0059] As can be seen, this embodiment simplifies the CAN data of different specifications received by the data acquisition thread into two types based on the actual signal length: compressed messages and normal messages. When a message meets the compression conditions, it is forcibly converted from an original 8-byte message to a 2-byte message, reducing the data storage pressure by 4 times, thereby effectively improving the utilization efficiency of the global static area storage space.

[0060] In step S102 above, the monitor thread provides two data access methods to the upper-layer application: blocking and non-blocking interfaces. In other words, the monitor thread can respond to both blocking and non-blocking data requests from the upper-layer application.

[0061] The specific implementation of the monitor thread responding to the blocking data requests of the upper layer application is not unique, and includes, but is not limited to, synchronous calls, waiting for conditions to be met, waiting for locks, etc.

[0062] In one alternative embodiment, the monitor thread responds to blocking data requests from the upper-layer application, including:

[0063] Before acquiring vehicle message data, the trywait function is called repeatedly to consume all currently available semaphores.

[0064] Within the specified time, the sem_timedwait function is called to block and wait for the monitor thread to send a POST primitive;

[0065] If a POST primitive is received within the specified time, the monitor thread is allowed to access vehicle message data in the global static area storage space in response to the blocking data request, based on the mutex lock.

[0066] If the POST primitive is not received within the specified time, the response to the blocking data request will automatically terminate based on the sem_timedwait function.

[0067] The `trywait` function is used to manipulate semaphores and is commonly used in thread synchronization and mutual exclusion mechanisms. Specifically, the `trywait` function attempts to acquire ownership of a semaphore. If the semaphore's value is greater than zero, the acquisition is successful, and the semaphore's value is decremented by one. If the semaphore's value is zero, the `trywait` function returns immediately without blocking the current thread and returns an error code indicating the reason for the failure to acquire the semaphore.

[0068] `sem_timedwait` is a function related to semaphore operations, typically used in scenarios involving thread synchronization and mutual exclusion. Specifically, the `sem_timedwait` function attempts to acquire a semaphore resource. If the resource becomes available within the specified timeout period, it acquires the resource and returns success; otherwise, if the timeout expires and the resource remains unavailable, the function returns failure. In this embodiment, the data acquisition thread and the monitor thread are multi-threaded. `sem_timedwait` can be used to handle situations where resources are waiting (e.g., accessing vehicle message data), but the waiting time needs to be limited to avoid prolonged thread blocking, which could lead to resource waste or deadlock.

[0069] A mutex is a commonly used synchronization mechanism in multithreaded programming to protect shared resources, such as vehicle message data in this example, preventing race conditions caused by multiple threads simultaneously accessing and modifying the same data. Specifically, the main characteristic of a mutex is that only one thread is allowed to hold the lock at any given time, and other threads must wait for the first thread to release the lock before they can acquire it and access the protected shared resource.

[0070] This embodiment is based on the trywait+sem_timedwait+post mechanism, and combines the underlying principle of mutex locks to perform data synchronization and mutual exclusion operations on the global static area storage space, so as to respond to the blocking data requests of the upper layer application.

[0071] For example, in existing technologies, due to safety regulations for automotive electronics, each remote control operation must undergo a mandatory security anti-theft authentication process. During this process, the upper-layer remote control application, after issuing control commands, queries the anti-theft authentication result and decides whether to proceed to the next step of result verification. In the process of querying the anti-theft authentication result, the data acquisition thread checks whether each received authentication result is successful. If so, it notifies the remote control thread by modifying the value of a global variable.

[0072] It is clear that this solution has two problems:

[0073] First, the information collection thread needs to store and monitor each message it receives, which consumes a lot of performance.

[0074] Second, because the upper-level application thread and the information collection thread are multi-threaded communication, there are data synchronization and mutual exclusion issues that lead to dirty data.

[0075] To solve this technical problem, in conjunction with the above optional embodiments, and referring to... Figure 5 Before collecting data, all available semaphores are consumed using a try-wait loop to ensure no interference. Within a specified time (e.g., 1 second), the sem_timedwait interface is called to block and wait for the monitor thread to send a POST primitive. If a POST signal is received, the global variable is accessed via a mutex, allowing the remote control program to determine whether the anti-theft authentication was received and executed successfully or failed. If no POST signal is received within the specified time, the blocking primitive automatically exits according to the sem_timedwait mechanism, allowing the remote control program to conclude that the anti-theft authentication was unresponsive.

[0076] This embodiment, based on the ordinary wait-post optimization mechanism, further considers the principle of using a blocking query framework. It uses semaphores of the trywait + sem_timedwait + post system primitives to obtain vehicle message data. If a deadlock occurs, the sem_timedwait primitive can actively exit the blocking wait and return a failure message if the required signal is not received within the specified time specified by the user. This achieves data synchronization and mutual exclusion operations on core variables in the global static area storage space, avoiding the situation where upper-layer applications can only use the inefficient polling method to query data.

[0077] In another alternative embodiment, the monitor thread responds to non-blocking data requests from the upper-layer application, including:

[0078] Register callback functions to the monitor thread in advance;

[0079] When the monitor thread responds to the non-blocking data request from the upper-layer application of the TBox system, it uses the monitor thread to monitor whether the vehicle message data corresponding to the signal value meets the callback condition in turn.

[0080] If so, the callback function is invoked to process the vehicle message data that meets the callback conditions.

[0081] Specifically, after the monitor thread sequentially monitors whether the vehicle message data corresponding to the signal value meets the callback condition, it also includes: if not, maintaining the monitor thread's monitoring of the vehicle message data.

[0082] According to the technical solution provided in this embodiment, for non-blocking data requests from upper-layer applications, the observer pattern from object-oriented languages ​​is ported. The observer registers callbacks with the observed. When the required event is triggered, i.e., when the callback condition is met, the monitored state is automatically notified to the upper-layer application, eliminating the need for variable polling. This achieves stable data acquisition, allowing the fast data acquisition thread to focus primarily on data processing, minimizing other tasks; while the slower monitor thread dedicates more CPU time to ensuring the most accurate acquisition of each signal for real-time reading by the upper-layer application.

[0083] For example, combining Figure 6 In existing new energy vehicles, when the upper-level application needs to collect data on whether a collision has occurred, the program on the TBox opens a thread and checks the current collision validity bit every second or every 100ms as required. If it is TRUE, it immediately reports to the TSP server and takes emergency response measures. Although this can complete the corresponding business functions, when there are dozens or hundreds of signals on the vehicle, each polling requires iterating through all signal values ​​for anomalies, greatly consuming CPU resources on this low-probability, high-importance task.

[0084] For this technical issue, see [link / reference]. Figure 7 This embodiment is based on the observer pattern, using the upper-layer early warning process as the observer. During program initialization, a callback function is registered with the monitor thread of the data acquisition process. When the monitoring thread detects a collision signal, it actively calls the callback function of the upper-layer application to complete the upper-layer transmission of the alarm information. As can be seen, by using callback functions, the result of asynchronous operations can be directly passed to the caller, thus achieving a simple and flexible way to handle the results of non-blocking operations.

[0085] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0086] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0087] See Figure 8 In a second embodiment of this application, a vehicle data processing device based on a TBox is provided, comprising:

[0088] The first processing module is configured to open a data acquisition thread to sequentially process the vehicle message data collected by the TBox, and after processing each vehicle message data, send a corresponding signal value to a pre-built buffer queue. The processing includes storing the vehicle message data in a global static area storage space, and the signal value is associated with a vehicle message data stored in the global static area storage space.

[0089] The second processing module is configured to open a monitor thread to respond to the signal values ​​in the buffer queue in turn, and call the blocking interface or non-blocking interface to respond to the data request of the upper layer application of the TBox system for the vehicle message data. The data acquisition thread and the monitor thread share the global static area storage space.

[0090] According to the technical solution provided in the embodiments of this application, by decoupling the data storage and monitoring functions during vehicle data acquisition into two threads, a single producer-dual consumer queue-single consumer model is formed. This allows the data acquisition thread to be responsible only for receiving and storing data, while the monitor thread independently completes data monitoring and provides services to the upper layer. As a result, the situation where a certain thread has to handle high-frequency data reading and writing in real time, as well as high-frequency reading and monitoring data and providing real-time query functions, is no longer present. This greatly reduces the CPU usage pressure of the threads and makes the system more stable and reliable.

[0091] In some alternative embodiments, the above-described TBox-based vehicle data processing device further includes:

[0092] The compression storage module is configured to identify whether the effective bit length of the vehicle message data is less than or equal to a preset length, which is an integer multiple of the length of a single byte, before storing the vehicle message data in a global static area storage space. If yes, the vehicle message data is compressed into a message with a byte length corresponding to the preset length and then stored in the global static area storage space; otherwise, the vehicle message data is directly stored in the global static area storage space.

[0093] In some optional embodiments, the second processing module is configured such that the monitor thread responds to the blocking data request from the upper-layer application. Before acquiring vehicle message data, it repeatedly calls the trywait function to consume all currently available semaphores. Within a specified time, it calls the sem_timedwait function to block and wait for the monitor thread to send a post primitive. If the post primitive is received within the specified time, the monitor thread is allowed to access the vehicle message data in the global static area storage space based on the mutex lock to respond to the blocking data request. If the post primitive is not received within the specified time, the monitor thread automatically exits the response to the blocking data request based on the sem_timedwait function.

[0094] In some optional embodiments, the second processing module is configured such that the monitor thread responds to the non-blocking data request of the upper layer application and pre-registers a callback function with the monitor thread; when the monitor thread responds to the non-blocking data request of the upper layer application of the TBox system, the monitor thread sequentially monitors whether the vehicle message data corresponding to the signal value meets the callback condition; if so, the callback function is called to process the vehicle message data that meets the callback condition.

[0095] All of the above-mentioned optional technical solutions can be combined in any way to form the optional embodiments of this application, and will not be described in detail here.

[0096] See Figure 9 In a third embodiment of this application, a vehicle is provided, including a TBox system. The TBox system includes a TBox bottom-layer acquisition chip and a TBox upper-layer receiving chip, which are connected. The vehicle can be a new energy vehicle, for example, any one of a pure electric vehicle, a plug-in hybrid electric vehicle, and a hybrid electric vehicle.

[0097] A TBox (short for Telematics Box) is an in-vehicle remote communication device, typically installed in new energy vehicles, used to achieve functions such as remote vehicle monitoring, remote control, vehicle positioning, and data collection. A TBox mainly consists of two parts: hardware and software.

[0098] Combination Figure 2 In general, the hardware of the TBox includes a TBox bottom-level acquisition chip and a TBox top-level receiving chip. The TBox bottom-level acquisition chip is connected to the control chip network of various control domains on the vehicle via a communication bus to receive vehicle message data sent by each control chip. Then, the TBox bottom-level acquisition chip transmits the vehicle message data to the TBox top-level receiving chip.

[0099] Of course, in practice, the TBox hardware can also include a main control module, a communication module, a positioning module, and sensor modules. Specifically, the main control module is primarily responsible for handling the communication and control of various functional modules. The communication module is used to communicate with a remote server and typically includes 4G / 5G, Bluetooth, and Wi-Fi modules. The positioning module is used to locate the vehicle's position information and usually uses a GPS module.

[0100] The TBox software includes computer programs running on the TBox's underlying acquisition chip and upper-layer receiver chip. In this embodiment, combined with... Figure 2 In this context, the software includes, but is not limited to, computer programs corresponding to functions such as the message alarm module, remote module, data reporting module, and ECall module in the upper-layer application of the TBox system, as well as computer programs corresponding to the data acquisition thread and monitor thread, or computer programs that implement the aforementioned vehicle data processing method steps based on the TBox. These computer programs can run on the TBox's underlying acquisition chip or the TBox's upper-layer receiving chip, or simultaneously on both the TBox's underlying acquisition chip and the TBox's upper-layer receiving chip, or on other hardware of the TBox. This application embodiment does not impose any limitations on this.

[0101] In addition, the software of a TBox in practice can also include embedded software, a communication protocol stack, data processing algorithms, and remote control interfaces or data interfaces. Specifically, the embedded software typically runs on the TBox main control module as an embedded operating system and application program, responsible for controlling hardware modules, processing vehicle data, and communicating with remote servers. The communication protocol stack is used to handle communication with the remote server and usually supports communication protocols such as TCP / IP, HTTP, and MQTT. The data processing algorithm is used to process the collected vehicle data. For example, the steps of the vehicle data processing method based on the TBox utilize a data acquisition thread to perform specified processing on the transparent vehicle message data, while a monitor thread responds to service requests from upper-layer applications. The remote control interface is used to implement the function of remotely controlling the vehicle, while the data interface is used for upper-layer applications to obtain the corresponding vehicle message data. For example, the data interface includes blocking and non-blocking interfaces provided by the monitor thread.

[0102] For example, combining Figure 10 In a TBox dual-threaded model application scenario, the TBox comprises an architecture with two threads and one storage space. The two threads include a data acquisition thread and a monitor thread. The storage space includes, but is not limited to, a buffer queue.

[0103] The data acquisition thread is responsible for data reception, validity verification, and data storage. It needs to meet the requirements of high real-time performance, fast execution speed, and the ability to quickly enter the next loop. After each data processing, it only needs to pass a small semaphore value to the buffer queue to notify the monitor thread.

[0104] The monitor thread uses a buffer queue as a buffer to address the speed mismatch. Because of the buffer queue, there is no need to worry about missing reported vehicle data, so each signal can be carefully processed within the thread, and the latest status value of the current vehicle can be updated more frequently.

[0105] Furthermore, combined Figure 10 As shown, the model architecture provided in this embodiment is equivalent to a single producer-dual queue-single consumer model. It simplifies CAN data of different specifications into two types (compressed messages and normal messages) according to the actual signal length. When the message meets the compression conditions, it is forcibly converted from the original 8-byte message to a 2-byte message, which reduces the data acquisition and storage pressure by 4 times.

[0106] In addition, two types of monitors are provided for upper-layer applications: blocking and non-blocking (based on the Observer design pattern), to avoid upper-layer applications having to use the inefficient polling method to query data individually.

[0107] The complete process of the upper-layer receiving chip in the TBox processing vehicle message data is as follows: After receiving the data transparently transmitted by the underlying microcontroller chip, the SoC chip in the TBox is responsible for receiving and processing this data. The specific processing method is as follows: a data acquisition thread, a monitor thread, and a global flag array are created, forming a producer-consumer-buffer queue model. The received raw data is processed through multi-threading and division of labor, and an access interface is provided to all other applications. The data acquisition thread is dedicated to high-speed, single-processing of the received data, the monitor thread is dedicated to executing various complex algorithms, and the global flag array is responsible for marking the data that can be processed at present, thereby further processing the data in the buffer. In the process of processing raw data, based on the characteristic that most vehicle-side CAN data can only take the lower 2 bytes, the data is flexibly compressed, directly reducing the total amount of data processing. In terms of supporting other modules that need data, two access methods have been added: blocking mode and non-blocking mode to obtain the underlying data. This reduces the dependence of upper-layer applications on the underlying data and allows upper-layer applications to flexibly access the underlying data.

[0108] As can be seen, the working principle of the TBox dual-thread model provided in this embodiment is as follows: After the data acquisition thread stores a packet of data, it notifies the monitor thread using a buffer queue. The monitor thread processes the data based on the incoming CAN message ID index. It can further handle issues such as signal transitions, trigger thresholds, or provide query interfaces to upper-layer applications. The two threads share a global static area storage space, and data synchronization and mutual exclusion are achieved through read-write locks. After splitting, there is no longer a situation where a single thread has to handle high-frequency data read / write in real time while also handling high-frequency monitoring data reading and providing real-time query functionality. The CPU usage pressure of the threads is greatly reduced, and the system is more stable and reliable.

[0109] See Figure 11 The upper-layer receiving chip of the TBox includes a processor 111, a memory 112, and a computer program 113 stored in the memory 112 and executable on the processor 111. When the processor 111 executes the computer program 113, it implements the steps in the various method embodiments described above. Alternatively, when the processor 111 executes the computer program 113, it implements the functions of each module in the various device embodiments described above.

[0110] The upper-layer receiving chip of the TBox may include, but is not limited to, a processor 111 and a memory 112. Those skilled in the art will understand that... Figure 11 This is merely an example of an upper-layer receiver chip for the TBox and does not constitute a limitation on the upper-layer receiver chip for the TBox. It may include more or fewer components than shown, or different components.

[0111] The processor 111 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0112] The memory 112 can be an internal storage unit of the TBox upper-layer receiver chip, such as a hard drive or RAM of the TBox upper-layer receiver chip. The memory 112 can also be an external storage device of the TBox upper-layer receiver chip, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card equipped on the TBox upper-layer receiver chip. The memory 112 can also include both internal storage units of the TBox upper-layer receiver chip and external storage devices. The memory 112 is used to store computer programs and other programs and data required by electronic devices.

[0113] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional modules in the embodiments 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.

[0114] If the integrated module is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium (e.g., a computer-readable storage medium). Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The computer-readable storage medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0115] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications 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 this application, and should all be included within the protection scope of this application.

Claims

1. A vehicle data processing method based on TBox, characterized in that, include: A data acquisition thread is established to sequentially process the vehicle message data collected by the TBox, and after processing each vehicle message data, a corresponding signal value is sent to a pre-built buffer queue. A vehicle data processing method, device, vehicle and readable storage medium based on TBox specifies that the processing includes storing vehicle message data in a global static area storage space, and the signal value is associated with a vehicle message data stored in the global static area storage space. A monitor thread is created to respond to the signal values ​​in the buffer queue in sequence, and calls the blocking interface or non-blocking interface to respond to the data request of the vehicle message data from the upper layer application where the TBox system is located. The data acquisition thread and the monitor thread share the global static area storage space. Before storing vehicle message data in a global static area storage space, the following steps are also included: Identify whether the effective bit length of the vehicle message data is less than or equal to a preset length, wherein the preset length is an integer multiple of the length of a single byte; If so, the vehicle message data is compressed into a message of the byte length corresponding to the preset length and then stored in the global static area storage space; If not, the vehicle message data will be stored directly in the global static area storage space.

2. The method according to claim 1, characterized in that, The monitor thread responds to blocking data requests from the upper-layer application, including: Before acquiring vehicle message data, the trywait function is called repeatedly to consume all currently available semaphores. Within the specified time, the sem_timedwait function is called to block and wait for the monitor thread to send a POST primitive; If a POST primitive is received within the specified time, the monitor thread is allowed to access vehicle message data in the global static area storage space based on the mutex lock, in response to the blocking data request. If no POST primitive is received within the specified time, the response to the blocking data request will automatically exit based on the sem_timedwait function.

3. The method according to claim 1, characterized in that, The monitor thread responds to non-blocking data requests from the upper-layer application, including: Register callback functions to the monitor thread in advance; When the monitor thread responds to the non-blocking data request from the upper-layer application of the TBox system, it uses the monitor thread to monitor whether the vehicle message data corresponding to the signal value meets the callback condition in turn. If so, the callback function is invoked to process the vehicle message data that meets the callback conditions.

4. A vehicle data processing device based on a TBox, characterized in that, include: The first processing module is configured to open a data acquisition thread to sequentially process the vehicle message data collected by the TBox, and after processing each vehicle message data, send a corresponding signal value to a pre-built buffer queue. The specified processing includes storing the vehicle message data in a global static area storage space, and the signal value is associated with a vehicle message data stored in the global static area storage space. The second processing module is configured to open a monitor thread to respond to the signal values ​​in the buffer queue in sequence, and call the blocking interface or non-blocking interface to respond to the data request of the upper layer application where the TBox system is located for the vehicle message data, wherein the data acquisition thread and the monitor thread share the global static area storage space. The compression storage module is configured to, before storing vehicle message data in a global static area storage space, identify whether the effective bit length of the message in the vehicle message data is less than or equal to a preset length, wherein the preset length is an integer multiple of the length of a single byte: if yes, then the vehicle message data is compressed into a message with a byte length corresponding to the preset length and stored in the global static area storage space; if no, then the vehicle message data is directly stored in the global static area storage space.

5. The apparatus according to claim 4, characterized in that, The second processing module is configured so that the monitor thread responds to the blocking data request of the upper layer application. Before obtaining vehicle message data, it calls the trywait function in a loop to consume all available semaphores. Within a specified time, it calls the sem_timedwait function to block and wait for the monitor thread to send a post primitive. If the post primitive is received within the specified time, the monitor thread is allowed to access the vehicle message data in the global static area storage space based on the mutex lock in response to the blocking data request. If no POST primitive is received within the specified time, the response to the blocking data request will automatically exit based on the sem_timedwait function.

6. The apparatus according to claim 4, characterized in that, The second processing module is configured to have the monitor thread respond to non-blocking data requests from the upper-layer application and to pre-register callback functions with the monitor thread; when the monitor thread responds to non-blocking data requests from the upper-layer application of the TBox system, the monitor thread is used to monitor whether the vehicle message data corresponding to the signal value meets the callback conditions in turn. If so, the callback function is invoked to process the vehicle message data that meets the callback conditions.

7. A vehicle comprising a TBox system, the TBox system including a TBox lower-level acquisition chip and a TBox upper-level receiving chip, the TBox lower-level acquisition chip and the TBox upper-level receiving chip being connected, and the TBox upper-level receiving chip including a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 3.

8. A readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 3.

Images