Vehicle-mounted terminal data transmission system and method
By real-time identification and switching of CAN protocol types in the on-board terminal data transmission system, and optimizing processing and reporting strategies based on data importance and real-time performance, the system's lack of adaptability to different CAN protocols and simple data transmission strategies are solved, and the system's implementation of the problem of insufficient adaptability to different CAN protocols is achieved. Higher data processing accuracy and efficiency.
Patent Information
- Application Number
- CN202411213395.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-30
- Publication Date
- 2024-12-13
AI Technical Summary
Existing vehicle-mounted terminal data transmission systems lack flexibility and scalability when facing different CAN protocols, making it difficult to quickly adapt to new protocols, resulting in limited accuracy and real-time data processing, and simple data storage and transmission strategies, which easily lead to critical issues. Data delay or loss.
A vehicle-mounted terminal data transmission system is designed, including a terminal data acquisition module, a terminal data processing module and a task scheduling module. By monitoring CAN bus data in real time, it automatically identifies the protocol type and switches the processing status, uses the target protocol analysis algorithm to analyze the data, and Cache and reporting strategies are optimized according to data importance and real-time.
It enhances protocol adaptability, improves system flexibility and scalability, improves data processing accuracy and efficiency, and ensures timely transmission and storage of key data.
Smart Images

Figure CN119135465A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the technical field of vehicle networking, and in particular to a vehicle-mounted terminal data transmission system and method. Background Art
[0002] With the rapid development of automobile electronics and intelligence, remote monitoring and data transmission of vehicles play an increasingly important role in vehicle management and maintenance. Especially in the field of electric vehicles and connected cars, real-time and accurate acquisition of vehicle status information and transmission to the remote monitoring platform has become an important means to ensure vehicle safety and reliability.
[0003] At present, the vehicle terminal system mainly obtains the vehicle's operating status information by collecting the vehicle's CAN (Controller Area Network) bus data and transmits this data to the remote monitoring platform. As a common automotive electronic communication standard, the CAN bus protocol is widely used in vehicle networks due to its high reliability and real-time performance. However, due to the diversity of vehicle models and the complexity of CAN protocol versions, the existing vehicle terminal data transmission system faces many technical challenges in dealing with the compatibility of different CAN protocols, data analysis accuracy, and data reporting efficiency.
[0004] First, when facing different versions of CAN protocols, the vehicle-mounted terminals in the prior art usually need to be manually configured or upgraded to adapt to different protocol types, and lack flexible automatic adaptation capabilities. With the continuous updating of vehicle technology, new CAN protocols and variants continue to emerge. The traditional fixed protocol parsing method is difficult to meet the diversified needs of vehicles, resulting in insufficient scalability of the system. Secondly, the CAN bus data collected by the vehicle is usually unprocessed raw data, which needs to be parsed and processed before being transmitted to the monitoring platform. In the existing system, the parsing algorithm of the data processing module is often bound to a specific CAN protocol type, and it is difficult to quickly switch between different protocols, resulting in limited accuracy and real-time performance of data processing. In addition, the storage and transmission strategies of the existing system for data are usually relatively simple, and it is impossible to effectively distinguish and process the data according to its importance and real-time performance, which easily leads to delays or loss of key data during transmission. Summary of the invention
[0005] The disclosed embodiments at least provide a vehicle-mounted terminal data transmission system and method, which can enhance protocol adaptability, improve flexibility and scalability, and improve the accuracy and efficiency of data processing.
[0006] The embodiment of the present disclosure provides a vehicle-mounted terminal data transmission system, including: a terminal data acquisition module, a terminal data processing module, a task scheduling module and an uplink data processing module;
[0007] The terminal data acquisition module is used to collect CAN bus data of the vehicle, determine the CAN protocol type corresponding to the CAN bus data, and switch the terminal data processing module to the target protocol processing state corresponding to the CAN protocol type;
[0008] The terminal data processing module is used to parse the CAN bus data into vehicle status data using a protocol parsing algorithm corresponding to the target protocol processing state, and store the vehicle status data in a cache;
[0009] The task scheduling module, according to a preset data reporting cycle and a preset data reporting strategy, calls the terminal data processing module to transmit the vehicle status data to the uplink data processing module, and triggers the uplink data processing module to report the vehicle status data to a preset monitoring platform.
[0010] In an optional implementation manner, the terminal data acquisition module is specifically used to:
[0011] Monitor the vehicle's CAN bus in real time and collect the original data frames corresponding to each vehicle control unit;
[0012] Determine the CAN protocol type according to the data flow mode corresponding to the CAN bus;
[0013] According to the CAN protocol type, the state machine of the terminal data processing module is controlled to switch to the target protocol processing state corresponding to the CAN protocol type, and the original data frame is sent to the terminal data processing module.
[0014] In an optional implementation manner, the terminal data processing module stores the vehicle status data in a cache, specifically for:
[0015] Screening emergency event data and real-time status data included in the vehicle status data;
[0016] Storing the emergency event data and the real-time status data in a first-level cache;
[0017] Screening the to-be-reissued data included in the vehicle status data;
[0018] The data to be reissued is stored in a secondary cache, and when the capacity of the secondary cache is insufficient, the data to be reissued is stored in a local disk file.
[0019] In an optional implementation manner, the task scheduling module is specifically used to:
[0020] When the system is started, a communication connection is established with the preset monitoring platform, and a login request is sent to the preset monitoring platform according to the GB32960 protocol and identity authentication is performed;
[0021] Determine a reporting priority corresponding to the vehicle status data, wherein the reporting priority corresponding to the emergency event data and the real-time status data is greater than the reporting priority corresponding to the to-be-reissued data;
[0022] Triggering a reporting process for each piece of the vehicle status data according to the reporting priority, and registering each of the reporting processes as an independent data reporting microservice;
[0023] Each of the data reporting microservices is input into a preset protocol adaptation layer, wherein the preset protocol adaptation layer supports multiple data reporting protocols, and according to the preset data reporting strategy, the corresponding data reporting protocol is configured for the data reporting microservice.
[0024] In an optional implementation, after configuring the corresponding data reporting protocol for the data reporting microservice, the task scheduling module is further used to:
[0025] When reporting the vehicle status data to the plurality of preset monitoring platforms, a preset distributed transaction coordinator is used to execute each of the data reporting microservices in parallel;
[0026] Adopting a two-phase commit distributed transaction mechanism to determine whether the vehicle status data corresponding to each data reporting microservice is consistent;
[0027] If they are consistent, update the service status corresponding to the data reporting microservice;
[0028] If they are inconsistent, the data reporting microservice is returned to the preset protocol adaptation layer.
[0029] In an optional implementation, after updating the service status corresponding to the data reporting microservice, the task scheduling module is further used to:
[0030] Real-time monitoring of whether the service status is a fault state;
[0031] If the data reporting microservice continues to be in the fault state, a circuit breaker is used to cut off the call of the data reporting microservice, and a preset detection cycle is performed at intervals to determine whether the service state corresponding to the data reporting microservice has returned to a normal state;
[0032] If the service status returns to normal, the data reporting microservice is re-enabled.
[0033] In an optional implementation manner, the vehicle-mounted terminal data transmission system further includes a downlink data processing module, and the downlink data processing module is used to:
[0034] Receiving control instructions and response messages sent by the preset monitoring platform;
[0035] The control instruction and the response message are returned to the task scheduling module.
[0036] The present disclosure also provides a vehicle terminal data transmission method, which is applied to the vehicle terminal data transmission system described in any of the above embodiments. The method includes:
[0037] Control the terminal data acquisition module to collect CAN bus data of the vehicle, determine the CAN protocol type corresponding to the CAN bus data, and switch the terminal data processing module to a target protocol processing state corresponding to the CAN protocol type;
[0038] Control the terminal data processing module to parse the CAN bus data into vehicle status data using a protocol parsing algorithm corresponding to the target protocol processing state, and store the vehicle status data in a cache;
[0039] Control the task scheduling module to call the terminal data processing module to transmit the vehicle status data to the uplink data processing module according to the preset data reporting cycle and the preset data reporting strategy, and trigger the uplink data processing module to report the vehicle status data to the preset monitoring platform.
[0040] An embodiment of the present disclosure also provides an electronic device, including: a processor, a memory and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor and the memory communicate through the bus, and when the machine-readable instructions are executed by the processor, the above-mentioned vehicle-mounted terminal data transmission method, or steps in any possible implementation of the above-mentioned vehicle-mounted terminal data transmission method are performed.
[0041] An embodiment of the present disclosure also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the computer program executes the above-mentioned vehicle-mounted terminal data transmission method, or the steps of any possible implementation of the above-mentioned vehicle-mounted terminal data transmission method.
[0042] The embodiments of the present disclosure also provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements the above-mentioned vehicle-mounted terminal data transmission method, or the steps in any possible implementation of the above-mentioned vehicle-mounted terminal data transmission method.
[0043] The disclosed embodiment provides a vehicle-mounted terminal data transmission system and method, including: a terminal data acquisition module, a terminal data processing module, a task scheduling module and an uplink data processing module; the terminal data acquisition module is used to collect the CAN bus data of the vehicle, determine the CAN protocol type corresponding to the CAN bus data, and switch the terminal data processing module to the target protocol processing state corresponding to the CAN protocol type; the terminal data processing module is used to parse the CAN bus data into vehicle status data using the protocol parsing algorithm corresponding to the target protocol processing state, and store the vehicle status data in a cache; the task scheduling module, according to a preset data reporting cycle and a preset data reporting strategy, calls the terminal data processing module to transmit the vehicle status data to the uplink data processing module, and triggers the uplink data processing module to report the vehicle status data to a preset monitoring platform. The protocol adaptability can be enhanced, the flexibility and scalability are improved, and the accuracy and efficiency of data processing are improved.
[0044] In order to make the above-mentioned objectives, features and advantages of the present disclosure more obvious and easy to understand, preferred embodiments are specifically cited below and described in detail with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS
[0045] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the following is a brief introduction to the drawings required for use in the embodiments. The drawings herein are incorporated into the specification and constitute a part of the specification. These drawings illustrate embodiments consistent with the present disclosure and are used together with the specification to illustrate the technical solutions of the present disclosure. It should be understood that the following drawings only illustrate certain embodiments of the present disclosure and should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can also be obtained based on these drawings without creative work.
[0046] Figure 1 A schematic diagram of the structure of a vehicle terminal data transmission system provided by an embodiment of the present disclosure is shown;
[0047] Figure 2 A schematic diagram showing the structure of another vehicle-mounted terminal data transmission system provided by an embodiment of the present disclosure is shown;
[0048] Figure 3 A flow chart of a vehicle terminal data transmission method provided by an embodiment of the present disclosure is shown;
[0049] Figure 4 A schematic diagram of an electronic device provided by an embodiment of the present disclosure is shown. DETAILED DESCRIPTION
[0050] In order to make the purpose, technical scheme and advantages of the embodiments of the present disclosure clearer, the technical scheme in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only part of the embodiments of the present disclosure, rather than all of the embodiments. The components of the embodiments of the present disclosure generally described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present disclosure provided in the drawings is not intended to limit the scope of the present disclosure for protection, but merely represents the selected embodiments of the present disclosure. Based on the embodiments of the present disclosure, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present disclosure.
[0051] It should be noted that similar reference numerals and letters denote similar items in the following drawings, and therefore, once an item is defined in one drawing, further definition and explanation thereof is not required in subsequent drawings.
[0052] The term "and / or" herein only describes an association relationship, indicating that three relationships may exist. For example, A and / or B may represent the following three situations: A exists alone, A and B exist at the same time, and B exists alone. In addition, the term "at least one" herein represents any combination of at least two of any one or more of a plurality of. For example, including at least one of A, B, and C may represent including any one or more elements selected from the set consisting of A, B, and C.
[0053] Research has found that when facing different versions of the CAN protocol, the vehicle-mounted terminals in the existing technology usually need manual configuration or upgrades to adapt to different protocol types, and lack flexible automatic adaptation capabilities. With the continuous updating of vehicle technology, new CAN protocols and variants continue to emerge. The traditional fixed protocol parsing method is difficult to meet the diverse needs of vehicles, resulting in insufficient scalability of the system. Secondly, the CAN bus data collected by the vehicle is usually unprocessed raw data, which needs to be parsed and processed before being transmitted to the monitoring platform. In the existing system, the parsing algorithm of the data processing module is often bound to a specific CAN protocol type, and it is difficult to quickly switch between different protocols, resulting in limited accuracy and real-time performance of data processing. In addition, the storage and transmission strategies of the existing system for data are usually relatively simple, and it is impossible to effectively distinguish and process the data according to its importance and real-time performance, which can easily lead to delays or losses of key data during transmission.
[0054] Based on the above research, the present disclosure provides a vehicle-mounted terminal data transmission system and method, including: a terminal data acquisition module, a terminal data processing module, a task scheduling module and an uplink data processing module; the terminal data acquisition module is used to collect the CAN bus data of the vehicle, determine the CAN protocol type corresponding to the CAN bus data, and switch the terminal data processing module to the target protocol processing state corresponding to the CAN protocol type; the terminal data processing module is used to parse the CAN bus data into vehicle status data using the protocol parsing algorithm corresponding to the target protocol processing state, and store the vehicle status data in a cache; the task scheduling module, according to the preset data reporting cycle and the preset data reporting strategy, calls the terminal data processing module to transmit the vehicle status data to the uplink data processing module, and triggers the uplink data processing module to report the vehicle status data to the preset monitoring platform. The protocol adaptability can be enhanced, the flexibility and scalability are improved, and the accuracy and efficiency of data processing are improved.
[0055] To facilitate understanding of this embodiment, a vehicle terminal data transmission system disclosed in the embodiment of the present disclosure is first described in detail. Figure 1 , which is a schematic diagram of the structure of a vehicle terminal data transmission system provided in an embodiment of the present disclosure.
[0056] like Figure 1 As shown in , the vehicle terminal data transmission system includes: a terminal data acquisition module 11, a terminal data processing module 12, a task scheduling module 13 and an uplink data processing module 14. The terminal data acquisition module 11, the terminal data processing module 12, the task scheduling module 13 and the uplink data processing module 14 are sequentially arranged between the vehicle CAN bus and the monitoring platform.
[0057] Specifically, the terminal data acquisition module 11 is used to collect the vehicle's CAN bus data, determine the CAN protocol type corresponding to the CAN bus data, and switch the terminal data processing module 12 to the target protocol processing state corresponding to the CAN protocol type; the terminal data processing module 12 is used to use the protocol parsing algorithm corresponding to the target protocol processing state to parse the CAN bus data into vehicle status data, and store the vehicle status data in the cache; the task scheduling module 13 calls the terminal data processing module 12 to transmit the vehicle status data to the uplink data processing module 14 according to the preset data reporting cycle and the preset data reporting strategy, and triggers the uplink data processing module 14 to report the vehicle status data to the preset monitoring platform.
[0058] In a specific implementation, the main function of the terminal data acquisition module 11 is to collect data from the vehicle's CAN bus (Controller Area Network), be compatible with a variety of CAN protocol formats, and be able to adapt to different versions of protocol variants to ensure accurate data collection and processing.
[0059] Here, the process of the terminal data acquisition module 11 collecting CAN bus data can be implemented by the following steps 1 to 3:
[0060] Step 1: Monitor the CAN bus of the vehicle in real time and collect the original data frames corresponding to each vehicle control unit.
[0061] Step 2: Determine the CAN protocol type according to the data flow mode corresponding to the CAN bus.
[0062] Step 3: According to the CAN protocol type, control the state machine of the terminal data processing module to switch to the target protocol processing state corresponding to the CAN protocol type, and send the original data frame to the terminal data processing module.
[0063] In a specific implementation, the CAN bus is the main communication network inside the vehicle, which is used to connect various control units of the vehicle (such as the engine control unit, the transmission control unit, etc.) The terminal data acquisition module 11 captures data frames from different control units by monitoring the CAN bus.
[0064] Here, different vehicles may use different CAN protocols, such as CAN 2.0A, CAN 2.0B, CAN FD, etc. The acquisition module must support these different protocols to ensure that data from all vehicles can be collected. By analyzing the data flow pattern collected from the CAN bus, the terminal data acquisition module 11 can automatically identify the type of CAN protocol currently in use. Different protocol types have different frame formats and data processing methods. After identifying the protocol type, the terminal data processing module 12 can correctly parse the data.
[0065] Exemplarily, if the data frame format detected by the terminal data acquisition module 11 conforms to the characteristics of the CAN 2.0A protocol, the terminal data acquisition module 11 will automatically switch the state of the terminal data processing module 12 to the CAN 2.0A mode to parse subsequent data frames.
[0066] As a possible implementation, the vehicle may use different CAN protocols during operation, or multiple protocols may coexist (such as CAN FD and CAN 2.0B coexist), and the terminal data acquisition module 11 must have the ability to switch between different protocols in real time. The adaptive state machine in the terminal data acquisition module 11 will dynamically adjust the working mode according to the characteristics of the currently monitored data frame to ensure that the data can be processed correctly in various situations.
[0067] Here, after determining the currently used protocol, the state machine in the terminal data acquisition module 11 switches to the corresponding protocol processing state. For example, if the data is identified as CAN FD protocol, the state machine adjusts to CAN FD processing mode and parses the frame format of CAN FD.
[0068] As another possible implementation, CAN bus data may be erroneous due to noise, interference, etc. The terminal data acquisition module 11 needs to have basic error detection and correction capabilities to ensure the accuracy and reliability of the data. Different vehicles may have different CAN bus configurations and protocol versions. These differences should be taken into account when designing the acquisition module to ensure that it can adapt to a wide range of vehicle models. With the development of new protocols or new technologies, the terminal data acquisition module 11 needs to be able to be flexibly updated and expanded to support new protocol versions or data formats that may appear in the future.
[0069] Furthermore, for some data that do not require real-time processing, the terminal data collection module 11 can perform preprocessing or filtering after collection to reduce the burden of subsequent data processing modules. For example, duplicate data or useless data frames can be filtered out to ensure that the reported data is valid and necessary.
[0070] It should be noted that during the operation of the vehicle, data collection needs to be carried out in real time, especially in situations involving safety (such as emergency braking, collision detection, etc.). Therefore, the terminal data collection module 11 must have high real-time performance to ensure that data is collected and processed in a timely manner. When the vehicle is running at high speed, the terminal data collection module 11 must be able to work continuously and stably to avoid data loss or system crash due to failure or error.
[0071] Preferably, the terminal data acquisition module 11 needs to provide a standardized data interface to transmit the processed data to other modules of the vehicle terminal, such as a data processing module or a task scheduling module. These interfaces need to ensure the stability and low latency of data transmission.
[0072] In a specific implementation, the terminal data processing module 12 is mainly responsible for caching, parsing, classifying, storing, and reporting the original data collected by the terminal data collection module 11. The terminal data processing module 12 first needs to cache the data collected by the terminal data collection module 11 to cope with network delays, excessive instantaneous data volume, or network interruptions. After caching the data, the system can ensure that even in the event of a network failure, the data will not be lost and can be resent when the network is restored.
[0073] During the data caching process, emergency event data and real-time status data included in the vehicle status data are screened; the emergency event data and real-time status data are stored in the first-level cache; the data to be reissued included in the vehicle status data are screened; the data to be reissued is stored in the second-level cache, and when the capacity of the second-level cache is insufficient, the data to be reissued is stored in a local disk file.
[0074] Here, for emergency or important events that occur during vehicle operation (such as fault alarms), such data needs to be cached and reported first, usually placed in the first-level cache to ensure that the data will not be lost due to network problems and can be reissued first. Real-time data includes important but non-urgent information such as vehicle status, location, speed, etc. These data usually need to be reported frequently. Such data is saved in the first-level cache. If the report fails, the reissue operation can be performed immediately. For data that was not successfully sent due to network problems in the previous reporting cycle, the processing module will cache it in the second-level cache or local disk file, and report it after the network is restored. It will be stored in the second-level cache first. If the capacity of the second-level cache is insufficient, the data will be transferred to the local disk file for storage.
[0075] The first-level cache is mainly used to store real-time data that needs to be reported first. It has a high access speed but limited capacity. The second-level cache stores data with lower priority. It has a larger capacity than the first-level cache, but has a slower access speed. It is suitable for storing data that is not urgently needed to be reported in a short period of time. When the cache space is insufficient, low-priority data will be stored on the local disk to ensure that the data will not be lost. After the network is restored, the data can be re-read and reported.
[0076] Furthermore, the raw data frames obtained by the terminal data acquisition module 11 from the CAN bus are usually low-level, unparsed binary data. The task of the terminal data processing module 12 is to parse these raw data frames into higher-level, meaningful data (such as specific sensor readings, vehicle parameters, etc.). According to the protocol type information obtained from the adaptive CAN protocol state machine, the terminal data processing module 12 will select the corresponding parsing algorithm to decode the raw data into readable parameter values, and store these parsed data in the cache for further processing and reporting.
[0077] As a possible implementation, after parsing the data, the terminal data processing module 12 needs to update the existing data records. This includes updating the current status information of the vehicle (such as vehicle location, speed, battery power, etc.) to ensure that the reported data is the latest. According to the importance and real-time nature of the data, the terminal data processing module 12 will manage the data in a hierarchical manner. Different cache strategies are used for data of different levels to optimize the processing capacity and response speed of the system.
[0078] As another possible implementation, data anomalies (such as data loss, data format errors, etc.) may occur during data collection, and the terminal data processing module 12 needs to have the ability to detect and handle anomalies to ensure that the final reported data is complete and accurate. If an anomaly is detected, the terminal data processing module 12 can request to resend data or obtain previous data from the cache for compensation to repair or reduce the impact of the anomaly.
[0079] As another possible implementation, before the data is reported, the terminal data processing module 12 will organize and package the data according to the current reporting strategy. Different data types will be organized into different data packets and prepared to be transmitted to the uplink data processing module 14. The terminal data processing module 12 can also dynamically adjust the priority of the reported data according to the network status and the vehicle operation status. For example, when the network bandwidth is limited, important data is reported first, and the transmission of unimportant data is delayed or reduced.
[0080] In the specific implementation, the main responsibility of the task scheduling module 13 is to coordinate various tasks in the vehicle terminal, including communication with the monitoring platform, data reporting, heartbeat packet sending, data retransmission, etc. The task scheduling module 13 adopts a task queue management mechanism to arrange the tasks in an orderly manner according to the priority and urgency of the tasks. Tasks with high priority (such as alarm data reporting, heartbeat packet sending, etc.) will be processed first.
[0081] Here, the task scheduling module 13 adopts multi-threading technology so that multiple tasks can be executed in parallel. For example, tasks such as data reporting, heartbeat packet sending, and exception handling can be performed simultaneously, and the execution of other tasks will not be affected by the delay of a certain task. The multi-threading design ensures the high responsiveness and high throughput of the system, especially when processing large amounts of data or requiring frequent communication, which can greatly improve the overall performance of the system.
[0082] Among them, the task scheduling module 13 can adjust the data processing and reporting strategies in real time according to the remote instructions of the monitoring platform or the vehicle operation status to ensure the flexibility and adaptability of the system. Through the remote update (Over-the-Air, OTA) technology, the system can update the configuration file of the data processing module at any time, support the access of new protocols and new platforms, and extend the life cycle of the system.
[0083] Specifically, when the system starts, a communication connection is established with the preset monitoring platform, and a login request is sent to the preset monitoring platform in accordance with the GB32960 protocol and identity authentication is performed; the reporting priority corresponding to the vehicle status data is determined, wherein the reporting priority corresponding to emergency event data and real-time status data is greater than the reporting priority corresponding to the data to be reissued; the reporting process of each vehicle status data is triggered according to the reporting priority, and each reporting process is registered as an independent data reporting microservice; each data reporting microservice is input into the preset protocol adaptation layer, which supports multiple data reporting protocols, and according to the preset data reporting strategy, the corresponding data reporting protocol is configured for the data reporting microservice.
[0084] Here, when the system starts, the task scheduling module 13 first needs to establish a network connection with the monitoring platform. After the connection is established, the task scheduling module 13 will send a login request to the monitoring platform and perform identity authentication in accordance with the requirements of the GB32960 protocol. After successful authentication, the system can start normal data transmission.
[0085] Among them, the task scheduling module 13 triggers the uplink data processing module 14 to send the data in the cache to the monitoring platform according to the preset reporting cycle and strategy. The priority of the reporting task can be dynamically adjusted according to the importance and real-time nature of the data. For the real-time data of the vehicle (such as location information, battery status) and emergency alarm data, the task scheduling module 13 will prioritize the scheduling and reporting to ensure that these key data can be communicated to the monitoring platform in a timely manner.
[0086] Specifically, the task scheduling module 13 uses multi-threading technology to allow multiple tasks to be executed simultaneously, thereby improving the overall processing efficiency of the system. For example, tasks such as data reporting, heartbeat packet sending, and data retransmission can be executed simultaneously to avoid blocking each other between tasks. The task scheduling module 13 manages multiple working threads to ensure that system resources are reasonably allocated and avoid resource exhaustion problems caused by too many threads.
[0087] Here, the task scheduling module 13 implements a lightweight service registration and discovery mechanism. Each data reporting service is an independent microservice and can be dynamically registered in the system. The module can flexibly add or remove reporting services according to demand and support the access of multiple reporting platforms.
[0088] Furthermore, the task scheduling module 13 designs an abstract protocol adaptation layer that can simultaneously support multiple reporting protocols such as the GB32960 protocol and enterprise private protocols. Regardless of the protocol, the system processes data through a unified interface, which not only simplifies development, but also enhances the flexibility and maintainability of the system. By performing protocol conversion through the strategy mode, the task scheduling module 13 can process data of different protocols with a unified interface, thereby simplifying system development and maintenance.
[0089] Optionally, the task scheduling module 13 adopts an event-driven asynchronous I / O model to achieve concurrent data reporting capabilities. This mechanism avoids the blocking problem caused by traditional synchronous I / O and improves the speed of data reporting and system throughput.
[0090] Furthermore, when reporting the vehicle status data to multiple preset monitoring platforms, a preset distributed transaction coordinator is used to execute each data reporting microservice in parallel; a two-phase commit distributed transaction mechanism is used to determine whether the vehicle status data corresponding to each data reporting microservice is consistent; if consistent, the service status corresponding to the data reporting microservice is updated; if inconsistent, the data reporting microservice is returned to the preset protocol adaptation layer.
[0091] Here, when reporting data across multiple platforms, the module uses a distributed transaction mechanism based on two-phase commit (2PC) to ensure the atomicity and consistency of data reporting and prevent data asynchrony. Through this mechanism, the system can ensure that all reporting operations involved are either all successful or all failed, thus avoiding data asynchrony.
[0092] The distributed transaction coordinator is responsible for coordinating transactions across multiple services. Although it does not directly participate in the specific execution of data reporting, it supports asynchronous non-blocking reporting, ensuring that multiple reporting operations can be performed in parallel while ensuring eventual consistency.
[0093] Here, the task scheduling module 13 implements a lightweight service registration and discovery framework. This framework allows different data reporting services to be dynamically registered and discovered, so that the system can flexibly add or remove reporting services as needed. Each reporting service runs as an independent microservice, which is independent of each other, avoiding the risk of single point failure. This design greatly improves the scalability and maintainability of the system.
[0094] It should be noted that because each reporting service can be run and managed independently, when it is necessary to support a new reporting platform, you only need to add the corresponding microservice without modifying the core code.
[0095] Furthermore, the service status is monitored in real time to see if it is in a fault state; if the data reporting microservice continues to be in a fault state, a circuit breaker is used to cut off the call of the data reporting microservice, and at each preset detection period, it is determined whether the service status corresponding to the data reporting microservice has returned to a normal state; if the service status has returned to a normal state, the data reporting microservice is re-enabled.
[0096] Here, the circuit breaker mechanism is mainly used to temporarily cut off the call to a service when a service in the system continues to fail, to prevent the failure from spreading. The circuit breaker can quickly detect and return an error response, avoiding the system from being stuck due to a long wait for the faulty service.
[0097] The circuit breaker will periodically detect whether the isolated service has been restored. Once the service returns to normal, the circuit breaker will automatically re-enable the service. At the same time, the circuit breaker can also reduce the overall system load by blocking requests to the faulty service, giving the faulty service more time to recover.
[0098] It should be noted that the circuit breaker is located after the service status is updated, and monitors the health status of each reporting service in real time, and decides whether to continue reporting or enter the fuse protection state according to the situation. This design greatly improves the fault tolerance and overall reliability of the system.
[0099] In this way, the microservice-based design enables the task scheduling module to flexibly respond to new requirements and new protocols that may appear in the future, extending the life cycle of the system. At the same time, it also significantly reduces the maintenance and upgrade costs of the system. Through distributed transactions, circuit breakers, multi-protocol adaptation and other mechanisms, it ensures that the system can still maintain a high degree of reliability and data consistency under high concurrency and high load conditions.
[0100] As a possible implementation, when a network anomaly or data reporting failure is detected, the task scheduling module 13 will start the data retransmission mechanism. The task scheduling module 13 first attempts to retransmit the data stored in the first-level cache. If the first-level cache is insufficient, the data stored in the second-level cache or the local disk will be retransmitted. The execution time and number of retransmission tasks can be dynamically adjusted according to the network status and vehicle operation status to reduce bandwidth occupation and the risk of repeated data reporting.
[0101] As another possible implementation, the task scheduling module 13 is also responsible for regularly sending heartbeat packets to the monitoring platform to maintain the stability of the connection and inform the online status of the platform terminal. The frequency and content of the heartbeat packet can be adjusted according to the requirements of the system configuration or the monitoring platform. Through the heartbeat packet, the module can detect the status of the current network connection. If the heartbeat packet fails to be sent successfully, the task scheduling module 13 will try to reconnect or enter the exception handling process.
[0102] As another possible implementation, the monitoring platform can dynamically adjust the data reporting strategy (such as reporting cycle, reporting content, etc.) of the vehicle terminal through remote instructions. After receiving the instruction, the task scheduling module 13 will immediately update the corresponding configuration and adjust the reporting behavior. The task scheduling module 13 can automatically adjust the reporting strategy according to the operating status of the vehicle (such as low battery, parking, etc.) to optimize the efficiency of data transmission and the use of system resources.
[0103] As another possible implementation, the task scheduling module 13 will continuously monitor the system operation status, including network connection status, data reporting success rate, cache usage, etc. Once an abnormality is detected, the task scheduling module 13 will trigger the corresponding processing mechanism. When a system failure or abnormal interruption occurs, the task scheduling module 13 will start the recovery process and reinitialize the relevant tasks to ensure that the system can resume normal operation as soon as possible.
[0104] See also Figure 2 , which is a schematic diagram of the structure of another vehicle-mounted terminal data transmission system provided in an embodiment of the present disclosure.
[0105] like Figure 2 As shown in , the vehicle-mounted terminal data transmission system includes: a terminal data acquisition module 11, a terminal data processing module 12, a task scheduling module 13 and an uplink data processing module 14, and also includes a downlink data processing module 15.
[0106] Specifically, the downlink data processing module 15 is used to: receive the control instructions and response messages sent by the preset monitoring platform; and return the control instructions and response messages to the task scheduling module 13 .
[0107] In the specific implementation, while the data is being transmitted, the vehicle terminal and the task scheduling module 13 also need to receive control instructions and response messages from the monitoring platform. The downlink data processing module 15 is responsible for processing the downlink data.
[0108] Here, for the control instructions (such as adjusting the reporting cycle, emergency stop, etc.) issued by the monitoring platform, the downlink data processing module 15 will parse and execute them in real time, and pass the configuration update to the relevant modules.
[0109] After receiving the data, the monitoring platform will send a confirmation message to the vehicle terminal through the downlink data processing module 15. The task scheduling module 13 will monitor the reception of the reporting confirmation message. If the confirmation is not received within the set time, the task scheduling module 13 will mark the data as unsuccessfully reported and trigger the resending mechanism.
[0110] It should be noted that the downlink data processing module 15 uses an asynchronous processing mechanism to avoid blocking the operation of other modules and ensure the overall smoothness and efficiency of the system.
[0111] The embodiment of the present application provides a vehicle terminal data transmission system, including: a terminal data acquisition module, a terminal data processing module, a task scheduling module and an uplink data processing module; the terminal data acquisition module is used to collect the CAN bus data of the vehicle, determine the CAN protocol type corresponding to the CAN bus data, and switch the terminal data processing module to the target protocol processing state corresponding to the CAN protocol type; the terminal data processing module is used to parse the CAN bus data into vehicle status data using the protocol parsing algorithm corresponding to the target protocol processing state, and store the vehicle status data in a cache; the task scheduling module, according to a preset data reporting cycle and a preset data reporting strategy, calls the terminal data processing module to transmit the vehicle status data to the uplink data processing module, and triggers the uplink data processing module to report the vehicle status data to a preset monitoring platform. The protocol adaptability can be enhanced, the flexibility and scalability are improved, and the accuracy and efficiency of data processing are improved.
[0112] Secondly, a vehicle-mounted terminal data transmission method disclosed in an embodiment of the present disclosure is introduced in detail. The execution subject of the vehicle-mounted terminal data transmission method provided in the embodiment of the present disclosure is generally a computer device with certain computing capabilities, and the computer device includes, for example: a terminal device or a server or other processing device, and the terminal device can be a user equipment (User Equipment, UE), a mobile device, a user terminal, a terminal, a cellular phone, a cordless phone, a personal digital assistant (Personal Digital Assistant, PDA), a handheld device, a computing device, a vehicle-mounted device, a wearable device, etc. In some possible implementations, the vehicle-mounted terminal data transmission method can be implemented by a processor calling a computer-readable instruction stored in a memory.
[0113] See also Figure 3 As shown, it is a flow chart of a vehicle terminal data transmission method provided by an embodiment of the present disclosure, and the method is applied to Figure 1-Figure 2 The vehicle terminal data transmission system shown includes steps S301 to S303, wherein:
[0114] S301, controlling the terminal data acquisition module to collect CAN bus data of the vehicle, determining the CAN protocol type corresponding to the CAN bus data, and switching the terminal data processing module to a target protocol processing state corresponding to the CAN protocol type.
[0115] S302: Control the terminal data processing module to parse the CAN bus data into vehicle status data using a protocol parsing algorithm corresponding to the target protocol processing state, and store the vehicle status data in a cache.
[0116] S303, control the task scheduling module to call the terminal data processing module to transmit the vehicle status data to the uplink data processing module according to the preset data reporting cycle and the preset data reporting strategy, and trigger the uplink data processing module to report the vehicle status data to the preset monitoring platform.
[0117] For descriptions of the processing flow of each module in the method and the interaction flow between each module, reference can be made to the relevant descriptions in the above system embodiment, which will not be described in detail here.
[0118] Those skilled in the art will appreciate that, in the above method of specific implementation, the order in which the steps are written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of the steps should be determined by their functions and possible internal logic.
[0119] The disclosed embodiment provides a vehicle-mounted terminal data transmission method, which controls the terminal data acquisition module to collect the vehicle's CAN bus data, determines the CAN protocol type corresponding to the CAN bus data, and switches the terminal data processing module to the target protocol processing state corresponding to the CAN protocol type; controls the terminal data processing module to use the protocol parsing algorithm corresponding to the target protocol processing state to parse the CAN bus data into vehicle status data, and stores the vehicle status data in a cache; controls the task scheduling module to call the terminal data processing module to transmit the vehicle status data to the uplink data processing module according to a preset data reporting cycle and a preset data reporting strategy, and triggers the uplink data processing module to report the vehicle status data to a preset monitoring platform. The protocol adaptability can be enhanced, the flexibility and scalability can be improved, and the accuracy and efficiency of data processing can be improved.
[0120] Corresponds to Figure 3 The vehicle terminal data transmission method in the present disclosure also provides an electronic device 400, such as Figure 4 FIG. 4 is a schematic diagram of the structure of an electronic device 400 provided in an embodiment of the present disclosure, including:
[0121] Processor 41, memory 42, and bus 43; memory 42 is used to store execution instructions, including memory 421 and external memory 422; memory 421 here is also called internal memory, which is used to temporarily store operation data in processor 41 and data exchanged with external memory 422 such as hard disk. Processor 41 exchanges data with external memory 422 through memory 421. When the electronic device 400 is running, the processor 41 communicates with the memory 42 through bus 43, so that the processor 41 executes Figure 3Steps of the vehicle terminal data transmission method.
[0122] The embodiment of the present disclosure also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the vehicle terminal data transmission method described in the above method embodiment are executed. The storage medium can be a volatile or non-volatile computer-readable storage medium.
[0123] The disclosed embodiment also provides a computer program product, which includes computer instructions. When the computer instructions are executed by a processor, the steps of the vehicle terminal data transmission method described in the above method embodiment can be executed. For details, please refer to the above method embodiment, which will not be repeated here.
[0124] The computer program product may be implemented in hardware, software or a combination thereof. In one optional embodiment, the computer program product is implemented as a computer storage medium. In another optional embodiment, the computer program product is implemented as a software product, such as a software development kit (SDK).
[0125] Those skilled in the art can clearly understand that, for the convenience and simplicity of description, the specific working process of the device described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here. In the several embodiments provided in the present disclosure, it should be understood that the disclosed device and method can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, and the indirect coupling or communication connection of the device or unit can be electrical, mechanical or other forms.
[0126] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0127] In addition, each functional unit in each embodiment of the present disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
[0128] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a non-volatile computer-readable storage medium that is executable by a processor. Based on this understanding, the technical solution of the present disclosure, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present disclosure. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.
[0129] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present disclosure, which are used to illustrate the technical solutions of the present disclosure, rather than to limit them. The protection scope of the present disclosure is not limited thereto. Although the present disclosure is described in detail with reference to the above-described embodiments, ordinary technicians in the field should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the above-described embodiments within the technical scope disclosed in the present disclosure, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present disclosure, and should be included in the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure should be based on the protection scope of the claims.
Claims
1. A vehicle terminal data transmission system, characterized in that: include: Terminal data acquisition module, terminal data processing module, task scheduling module and uplink data processing module; The terminal data acquisition module is used to collect CAN bus data of the vehicle, determine the CAN protocol type corresponding to the CAN bus data, and switch the terminal data processing module to the target protocol processing state corresponding to the CAN protocol type; The terminal data processing module is used to parse the CAN bus data into vehicle status data using a protocol parsing algorithm corresponding to the target protocol processing state, and store the vehicle status data in a cache; The task scheduling module, according to a preset data reporting cycle and a preset data reporting strategy, calls the terminal data processing module to transmit the vehicle status data to the uplink data processing module, and triggers the uplink data processing module to report the vehicle status data to a preset monitoring platform.
2. The vehicle terminal data transmission system according to claim 1, characterized in that: The terminal data acquisition module is specifically used for: Monitor the vehicle's CAN bus in real time and collect the original data frames corresponding to each vehicle control unit; Determine the CAN protocol type according to the data flow mode corresponding to the CAN bus; According to the CAN protocol type, the state machine of the terminal data processing module is controlled to switch to the target protocol processing state corresponding to the CAN protocol type, and the original data frame is sent to the terminal data processing module.
3. The vehicle terminal data transmission system according to claim 1, characterized in that: The terminal data processing module stores the vehicle status data in a cache, specifically for: Screening emergency event data and real-time status data included in the vehicle status data; Storing the emergency event data and the real-time status data in a first-level cache; Screening the to-be-reissued data included in the vehicle status data; The data to be reissued is stored in a secondary cache, and when the capacity of the secondary cache is insufficient, the data to be reissued is stored in a local disk file.
4. The vehicle terminal data transmission system according to claim 3, characterized in that: The task scheduling module is specifically used for: When the system is started, a communication connection is established with the preset monitoring platform, and a login request is sent to the preset monitoring platform according to the GB32960 protocol and identity authentication is performed; Determine a reporting priority corresponding to the vehicle status data, wherein the reporting priority corresponding to the emergency event data and the real-time status data is greater than the reporting priority corresponding to the to-be-reissued data; Triggering a reporting process for each piece of the vehicle status data according to the reporting priority, and registering each of the reporting processes as an independent data reporting microservice; Each of the data reporting microservices is input into a preset protocol adaptation layer, wherein the preset protocol adaptation layer supports multiple data reporting protocols, and according to the preset data reporting strategy, the corresponding data reporting protocol is configured for the data reporting microservice.
5. The vehicle terminal data transmission system according to claim 4, characterized in that: After configuring the corresponding data reporting protocol for the data reporting microservice, the task scheduling module is further used to: When reporting the vehicle status data to the plurality of preset monitoring platforms, a preset distributed transaction coordinator is used to execute each of the data reporting microservices in parallel; Adopting a two-phase commit distributed transaction mechanism to determine whether the vehicle status data corresponding to each data reporting microservice is consistent; If they are consistent, update the service status corresponding to the data reporting microservice; If they are inconsistent, the data reporting microservice is returned to the preset protocol adaptation layer.
6. The vehicle terminal data transmission system according to claim 5, characterized in that: After updating the service status corresponding to the data reporting microservice, the task scheduling module is further used to: Real-time monitoring of whether the service status is a fault state; If the data reporting microservice continues to be in the fault state, a circuit breaker is used to cut off the call of the data reporting microservice, and a preset detection cycle is performed at intervals to determine whether the service state corresponding to the data reporting microservice has returned to a normal state; If the service status returns to normal, the data reporting microservice is re-enabled.
7. The vehicle terminal data transmission system according to claim 1, characterized in that: The vehicle-mounted terminal data transmission system further includes a downlink data processing module, which is used to: Receiving control instructions and response messages sent by the preset monitoring platform; The control instruction and the response message are returned to the task scheduling module.
8. A vehicle-mounted terminal data transmission method, characterized in that: Applied to the vehicle terminal data transmission system as claimed in any one of claims 1 to 7, the method comprises: Control the terminal data acquisition module to collect CAN bus data of the vehicle, determine the CAN protocol type corresponding to the CAN bus data, and switch the terminal data processing module to a target protocol processing state corresponding to the CAN protocol type; Control the terminal data processing module to parse the CAN bus data into vehicle status data using a protocol parsing algorithm corresponding to the target protocol processing state, and store the vehicle status data in a cache; Control the task scheduling module to call the terminal data processing module to transmit the vehicle status data to the uplink data processing module according to the preset data reporting cycle and the preset data reporting strategy, and trigger the uplink data processing module to report the vehicle status data to the preset monitoring platform.
9. An electronic device, characterized in that: include: A processor, a memory and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor and the memory communicate via the bus, and when the machine-readable instructions are executed by the processor, the steps of the vehicle terminal data transmission method as described in claim 8 are performed.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which, when executed by a processor, executes the steps of the vehicle-mounted terminal data transmission method as claimed in claim 8.
