CN111694766A

CN111694766A - CAN data acquisition method and device

Info

Publication number: CN111694766A
Application number: CN202010547933.8A
Authority: CN
Inventors: 邓冕
Original assignee: Beijing Jingwei Hirain Tech Co Ltd
Current assignee: Beijing Jingwei Hirain Tech Co Ltd
Priority date: 2020-06-16
Filing date: 2020-06-16
Publication date: 2020-09-22
Anticipated expiration: 2040-06-16
Also published as: CN111694766B

Abstract

According to the scheme, vehicle-mounted equipment acquires CAN data of all CAN channels on a vehicle, and the CAN data are compressed and uploaded to a cloud server. The vehicle-mounted equipment does not filter, screen, analyze and process the CAN data, and the cloud server is responsible for the utilization of the CAN data including receiving, analyzing, warehousing and utilization. Therefore, the cloud server CAN obtain the full CAN data of the vehicle, and CAN quickly obtain the CAN data required by the new application requirement from the received full CAN data when facing the requirement change, namely quickly responding to the new scene requirement change. In addition, the vehicle-mounted equipment compresses the CAN data and then uploads the compressed CAN data, so that the bandwidth and the flow required by uploading the CAN data are reduced.

Description

CAN data acquisition method and device

Technical Field

The application belongs to the technical field of car networking, and particularly relates to a CAN data acquisition method and device.

Background

The internet of vehicles is a typical application of the internet of things in the field of automobiles, and the internet of vehicles is based on an in-vehicle CAN bus network, a wireless communication network and the internet, and performs real-time wireless communication and information exchange among vehicles, people, roads and vehicles according to an agreed communication protocol and a data interaction standard, so that an integrated network system of intelligent traffic management, intelligent dynamic information service and intelligent vehicle control CAN be realized. The CAN bus remote monitoring is used as the core of the car networking, CAN collect the running data (namely the car information) of the engine, transmission, braking, energy storage, light, car door and electricity, mileage, speed, positioning and the like of the car at a very high frequency, and transmits the running data to the cloud server in real time.

The existing vehicle information acquisition scheme is that firstly, which type of CAN data needs to be received is determined according to specific requirements, then, the vehicle-mounted equipment screens out specified CAN data from a CAN bus according to configuration, analyzes and preliminarily analyzes the CAN data and then transmits the CAN data back to a cloud server. In the car networking architecture, tasks undertaken by the car-mounted equipment mainly include data receiving, screening, preliminary analysis and result uploading, and the cloud server mainly has the tasks of summarizing, counting, displaying and the like of analysis results. The scheme has no problem under the conditions that the CAN network structure and the message of the vehicle body are relatively fixed and the requirement is clear and not frequently changed.

However, with the development of the car networking technology and the emergence of new application scenarios such as V2X, big data, automatic driving, etc., more and more car body CAN network integrated controllers are provided, the CAN messages are more and more complex and changeable, and the utilization mode of the CAN data is flexible and changeable. The scheme CAN only collect fixed partial CAN data according to determined configuration, and cannot quickly respond to new demand change.

Disclosure of Invention

In view of this, an object of the present application is to provide a method and an apparatus for acquiring CAN data, so as to solve the technical problem that the existing CAN data acquisition method CAN only acquire a fixed part of CAN data according to a determined configuration and cannot quickly respond to a new demand change, and a specific technical scheme disclosed in the present application is as follows:

on one hand, the application provides a CAN data acquisition method, which is applied to vehicle-mounted equipment, and the method comprises the following steps:

receiving CAN data transmitted by any CAN channel and storing the CAN data into a memory block allocated to the CAN channel;

generating a corresponding compression task according to the CAN data stored in the memory block;

storing the compression tasks into a compression task queue, reading corresponding CAN data from a corresponding memory block according to the compression tasks in the compression task queue, and compressing the CAN data to obtain compressed CAN data;

and sending the compressed CAN data to a cloud server according to a preset uploading strategy so that the cloud server decompresses and stores the compressed CAN data sent by the vehicle-mounted equipment.

Optionally, the receiving and storing the CAN data transmitted by any CAN channel into a memory block allocated to the CAN channel includes:

after receiving CAN data from a CAN channel, judging whether the memory space of a memory block allocated to the CAN channel is sufficient;

if the memory space of the memory block is sufficient, storing the received CAN data into the memory block allocated to the CAN channel;

and if the memory space of the memory block is insufficient, marking the memory block allocated to the CAN channel as unavailable, generating a compression task corresponding to the memory block, allocating a new memory block to the CAN channel again, and storing the CAN data into the new memory block.

Optionally, the generating a corresponding compression task according to the CAN data stored in the memory block includes:

when a vehicle flameout signal is monitored, marking a memory block corresponding to a CAN channel which transmits CAN data at present as unavailable, and generating a compression task;

and after the memory block rotation timer is triggered, comparing the timestamp of the first piece of data stored in the memory block with the current timestamp, if the time difference reaches the set time of the memory block rotation timer, marking the memory block as unavailable, and generating a compression task according to the CAN data stored in the memory block.

Optionally, the storing the compression task into a compression task queue includes:

judging whether the compression task queue is full;

if the compression task queue is not full, directly storing the generated compression task into the compression task queue;

and if the compression task queue is full, deleting the earliest compression task in the compression task queue and storing the generated compression task into the compression task queue.

Optionally, reading corresponding CAN data from the corresponding memory block according to the compression task in the compression task queue and compressing the CAN data to obtain compressed CAN data, including:

when the timing of a compression task timer reaches a first set time length, judging whether a compression task queue is empty or not, wherein the compression task timer starts timing when a compression task is executed and the compression task queue is not empty or a new compression task is added into the compression task queue and no compression task is executed;

if the compression task queue is not empty, reading a compression task from the compression task queue;

determining the positioning information of the memory block according to the read compression task, and reading CAN data to be compressed from the memory block according to the positioning information;

and compressing the CAN data to be compressed to obtain the compressed CAN data.

Optionally, according to a preset uploading policy, the compressed CAN data is sent to a cloud server, including:

generating an uploading task according to the compressed CAN data, and judging whether an uploading task queue is full or not;

if the uploading task queue is not full, adding the uploading task into the uploading task queue;

if the uploading task queue is full, writing compressed CAN data corresponding to the earliest uploading task in the uploading task queue into a disk file, and adding the uploading task into the uploading task queue;

when the time of an upload task timer reaches a second set time length, judging whether the upload task queue is empty or not, wherein the upload task timer starts to time when an upload task is executed and the upload task queue is not empty or a new upload task is added to the upload task queue and no currently executed upload task exists;

and if the uploading queue is not empty, reading the uploading task from the uploading task queue, reading the compressed CAN data from the memory block according to the read uploading task, and sending the compressed CAN data to the cloud server.

Optionally, after writing the compressed CAN data corresponding to the earliest upload task in the upload task queue into a disk file, the method further includes:

when a cache file monitoring timer is triggered, judging whether a disk is empty and the number of tasks in the uploading task queue is smaller than a preset proportional threshold;

if the disk is not empty and the number of tasks in the uploading task queue is smaller than a preset proportional threshold, reading a cache file from the disk;

and generating an uploading task according to the read cache file, adding the uploading task into the uploading task queue, and starting the cache file monitoring timer.

Optionally, in the process of sending the compressed CAN data to a cloud server, the method further includes:

and when a vehicle flameout signal is detected, stopping the uploading task which is being executed, and writing the compressed CAN data corresponding to all the uploading tasks in the uploading task queue into a disk file.

In a second aspect, the present application further provides a CAN data acquisition method applied to a cloud server, where the method includes:

receiving compressed CAN data, wherein the compressed CAN data is obtained by a vehicle-mounted device by using the CAN data acquisition method in any one of the first aspect, and the compressed CAN data comprises data acquired by any one CAN channel in a vehicle;

and decompressing the received compressed CAN data and storing the decompressed CAN data into a database so that the application program plug-in extracts and processes the CAN data required by the application program from the database.

In a third aspect, the present application further provides a CAN data collection device applied to a vehicle-mounted device, where the device includes:

the data receiving module is used for receiving CAN data transmitted by any CAN channel, storing the CAN data into a memory block allocated to the CAN channel, and generating a corresponding compression task according to the CAN data stored in the memory block;

the data compression module is used for storing the compression tasks into a compression task queue, reading corresponding CAN data from a corresponding memory block according to the compression tasks in the compression task queue and compressing the CAN data to obtain compressed CAN data;

and the data uploading module is used for sending the compressed CAN data to a cloud server according to a preset uploading strategy so that the cloud server decompresses and stores the compressed CAN data sent by the vehicle-mounted equipment.

In a fourth aspect, the present application further provides a CAN data collection device applied to a cloud server, the device includes:

the data receiving module is used for receiving compressed CAN data, the compressed CAN data is obtained by vehicle-mounted equipment by using the CAN data acquisition method in any one of the first aspect, and the compressed CAN data comprises data acquired by any CAN channel in a vehicle;

and the data application module is used for decompressing the received compressed CAN data and storing the decompressed CAN data into a database so that the application program plug-in extracts the CAN data required by the application program from the database and processes the CAN data.

According to the CAN data acquisition method, the vehicle-mounted equipment allocates a memory block to each CAN channel, and stores the received CAN data into the corresponding memory block. And then, generating a corresponding compression task aiming at the CAN data stored in the memory block and storing the compression task in a compression task queue. And executing the compression task in the compression task queue, reading the CAN data from the memory block and compressing to obtain the compressed CAN data. And finally, uploading the compressed CAN data to a cloud server according to a preset uploading strategy, and uniformly processing, processing and applying the CAN data by the cloud server. According to the process, the CAN data of all CAN channels on the vehicle are collected by the vehicle-mounted equipment, and the CAN data are compressed and then uploaded to the cloud server. The vehicle-mounted equipment does not filter, screen, analyze and process the CAN data, and the cloud server is responsible for the utilization of the CAN data including receiving, analyzing, warehousing and utilization. Therefore, the cloud server CAN obtain the full CAN data of the vehicle, and CAN quickly obtain the CAN data required by the new application requirement from the received full CAN data when facing the requirement change, namely quickly responding to the new scene requirement change. In addition, the vehicle-mounted equipment compresses the CAN data and then uploads the compressed CAN data, so that the bandwidth and the flow required by uploading the CAN data are reduced.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, and it is obvious that the drawings in the following description are some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

FIG. 1 is a schematic structural diagram of a vehicle networking system provided in an embodiment of the present application;

fig. 2 is a flowchart of a CAN data acquisition method provided in an embodiment of the present application;

fig. 3 is a flowchart of a process of receiving CAN data by an on-board device according to an embodiment of the present application;

FIG. 4 is a flowchart illustrating a process of storing a compression task into a compression task queue by an on-board device according to an embodiment of the present disclosure;

FIG. 5 is a flowchart of a process of executing a compression task by an on-board device according to an embodiment of the present application;

fig. 6 is a flowchart of a data uploading process of a vehicle-mounted device according to an embodiment of the present application;

fig. 7 is a flowchart of a process in which a vehicle-mounted device reads data from a disk file and joins in an upload task queue according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of a CAN data acquisition device provided in an embodiment of the present application;

fig. 9 is a schematic structural diagram of another CAN data acquisition device provided in the embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

Referring to fig. 1, a schematic structural diagram of a car networking system provided in an embodiment of the present application is shown, where the system mainly includes a vehicle-mounted device 1 and a cloud server 2.

The vehicle-mounted device 1 and the cloud server 2 are interconnected through a network, for example, a mobile communication network, such as a 4G network, a 5G network, and the like.

The vehicle-mounted equipment 1 is used for collecting data on all CAN buses in the vehicle, namely CAN data, compressing the CAN data and uploading the compressed CAN data to the cloud server 2. Namely, the CAN data is processed by three steps of data receiving, data compression and data uploading. Moreover, the vehicle-mounted equipment does not perform any filtering and screening on the CAN data and does not analyze or process the content of the CAN data.

It should be noted that, the execution sequence of data reception, data compression and data upload has no precedence relationship, and only indicates the flow direction of data, and in actual operation, the three steps are simultaneously and asynchronously operated by three threads.

The vehicle-mounted device refers to a device which CAN be connected to a vehicle body CAN bus and hardware of which meets requirements (such as processor performance, memory, a disk, a network and the like), for example, a vehicle-mounted communication module (T-Box) and the like.

The cloud server 2 is used for receiving, analyzing and warehousing data and realizing service logic in a specific application scene by using the CAN data transmitted by the vehicle-mounted device 1.

Referring to fig. 2, the CAN data collection method applied to the car networking system will be described in detail below, and as shown in fig. 2, the CAN data collection method mainly includes the following steps:

and S110, the vehicle-mounted equipment receives the CAN data transmitted by any CAN channel and stores the CAN data into a memory block allocated to the CAN channel.

The vehicle-mounted equipment applies for a series of continuous memory blocks with fixed sizes during initialization to form a memory pool for caching received CAN data, wherein one memory block is allocated to each CAN channel so as to store the CAN data transmitted by different CAN channels into different memory blocks.

And after receiving the data transmitted by any CAN channel, storing the data into a memory block allocated to the CAN channel, and adding a timestamp to the data. When the memory block meets a certain condition, the next operation is executed on the data in the memory block, namely the received CAN data is processed in a centralized way instead of processing one by one, so that the efficiency is improved.

And S120, the vehicle-mounted equipment generates a corresponding compression task according to the CAN data stored in the memory block.

In an application scenario of the present application, when a memory block is full of data, a corresponding compression task is generated. The compression task includes location information of a memory block storing the CAN data to be compressed, where the location information of the memory block may include a first address of the memory block and a size of the memory block.

In an embodiment of the present application, a cache data forced upload mechanism is provided, and under this mechanism, even if a memory block is not full, processing of a next link is performed, where the mechanism includes two cases: a vehicle key-OFF signal (i.e., a vehicle IGN OFF signal) is monitored, and a memory block cycle timer triggers.

(1) Monitoring vehicle flameout signal (i.e. vehicle IGN OFF signal)

After the vehicle is shut down, the CAN bus gradually enters a dormant state, and each vehicle-mounted controller and each vehicle-mounted device gradually enter the dormant state or the power-off state, so that CAN data transmission may not exist in a short time, and existing data in the current memory block are uploaded to the cloud server even if the current memory block is not full.

(2) Memory block rotation timer trigger

Because the load of each CAN channel is different, the CAN data of some CAN channels are possibly very little, which causes that a memory block is not written in a long time, and further causes that the data of the CAN channel is not uploaded in time.

When the CAN data is stored in each memory block, the memory block records a timestamp when the first CAN data is stored, the memory block rotation timer is periodically started, the timestamp recorded by each memory block is compared with the current timestamp, and if the timestamp exceeds the time set by the memory block rotation timer, the next operation CAN be carried out even if the memory block is not full.

It should be noted that S110 and S120 may be completed by a data receiving thread in the in-vehicle device.

And S130, the vehicle-mounted equipment stores the compression tasks into a compression task queue, and reads corresponding CAN data from the corresponding memory block according to the compression tasks read from the compression task queue and compresses the CAN data to obtain compressed CAN data.

The vehicle-mounted device needs to create a compression task queue during initialization, and in order to ensure that each CAN channel always has available memory blocks, the size of the compression task queue is configured to be smaller than the number of the memory blocks in the memory pool, for example, the memory pool includes 100 memory blocks, and the compression task queue may be set to 80. It should be noted that the memory blocks included in the memory pool CAN be shared by each CAN channel and recycled, and therefore, the number of the memory blocks has no fixed relationship with the number of the CAN channels, for example, the number of the CAN channels is 6, and the number of the memory blocks is 100.

And when the compression task is executed, determining the address of the memory block according to the memory block positioning information in the compression task, reading CAN data in the memory block according to the address, and compressing the CAN data to obtain compressed CAN data. The read-write rule of the compression task queue is first in first out, that is, the compression task written into the compression task queue first is taken out first for execution. It should be noted that the data compression process may be performed by a data compression thread in the vehicle-mounted device.

And S140, the vehicle-mounted equipment sends the compressed CAN data to a cloud server according to a preset uploading strategy.

The compressed CAN data CAN be uploaded to a cloud server according to a preset uploading strategy so as to ensure that the data are not lost.

In order to avoid data loss, the characteristics of large capacity and non-volatility of a disk (such as emmc, an SD card, ssd and other large-capacity storage media) are used as a secondary cache of a memory, when a network link is unstable and data uploading is unsuccessful, data are written into a disk file to avoid CAN data loss, meanwhile, real-time uploading is guaranteed to be prior to disk caching, and the disk caching is used only under necessary conditions, so that disk reading and writing operations are reduced, the efficiency is improved, and the read-write life of the disk is prolonged.

The data uploading process can be completed by a data uploading thread in the vehicle-mounted equipment.

And S150, decompressing the compressed CAN data sent by the vehicle-mounted equipment by the cloud server, and storing and utilizing the compressed CAN data.

And after receiving the compressed CAN data sent by the vehicle-mounted equipment, the cloud server uniformly processes, processes and applies the CAN data.

A File Transfer Protocol (FTP) server for receiving data, a database for storing data, and other components related to specific services need to be deployed in the cloud server. The process of processing and applying CAN data by the cloud server is as follows:

(1) and after the CAN data are uploaded by the vehicle-mounted equipment, the FTP server receives the data and stores the data into the hard disk in a file form.

(2) And regularly taking the recently uploaded data from the hard disk, verifying the CAN data according to the packet header information of the CAN data packet, discarding the data which fails in verification if the data is invalid, decompressing the data which passes the verification by using a decompression algorithm which is symmetrical to the vehicle-mounted equipment, and storing the analyzed data into a database.

(3) Different application program plug-ins extract different data from the database according to self requirements and process the data according to different steps according to different requirements.

For example, for big data analysis, firstly, the required data, such as message ID, vehicle number, time period, etc., are determined according to the purpose of analysis, then the required data are taken out from the database, and the data are analyzed and processed according to the corresponding algorithm to obtain the result.

For real vehicle scene reconstruction, all message data of a certain vehicle in a certain time period are taken out from a database, then the data are reorganized into a file format (such as an asc file which CAN be used by CANoe software) which CAN be used by CAN message playback equipment, the reconstructed message file is played back on a CAN bus of a test environment, an ECU (electronic control unit) or other components to be tested are accessed on the test CAN bus, and finally the real vehicle debugging effect is achieved.

It should be noted that, the corresponding application plug-ins are customized and developed respectively according to different application scenarios and requirements.

In the method for acquiring CAN data provided by this embodiment, the vehicle-mounted device allocates a memory block to each CAN channel, and stores the received CAN data in the corresponding memory block. And then, generating a corresponding compression task aiming at the CAN data stored in the memory block and storing the compression task in a compression task queue. And executing the compression task in the compression task queue, reading the CAN data from the memory block and compressing to obtain the compressed CAN data. And finally, uploading the compressed CAN data to a cloud server according to a preset uploading strategy, and uniformly processing, processing and applying the CAN data by the cloud server. According to the process, the CAN data of all CAN channels on the vehicle are collected by the vehicle-mounted equipment, and the CAN data are compressed and then uploaded to the cloud server. The vehicle-mounted equipment does not filter, screen, analyze and process the CAN data, and the cloud server is responsible for the utilization of the CAN data, including receiving, analyzing, warehousing and utilization. Therefore, the cloud server CAN obtain the full CAN data of the vehicle, and CAN quickly obtain the CAN data required by the new application requirement from the received full CAN data when facing the requirement change, namely quickly responding to the new scene requirement change. In addition, the vehicle-mounted equipment compresses the CAN data and then uploads the compressed CAN data, so that the bandwidth and the flow required by uploading the CAN data are reduced.

In an embodiment of the present application, as shown in fig. 3, a process of receiving CAN data transmitted by a CAN channel and storing the CAN data in a corresponding memory block is as follows:

s111, after the vehicle-mounted equipment receives CAN data from the CAN channel, judging whether the memory space of the memory block allocated to the CAN channel is sufficient; if not, executing S112; if so, S113 is performed.

And S112, marking the memory block allocated to the CAN channel as unavailable, allocating a new memory block to the CAN channel again, and storing the CAN data into the new memory block.

If the current memory block has insufficient space, the current memory block is marked as unavailable, and a corresponding compression task is generated so as to compress the data in the memory block as soon as possible. And then, taking out a new memory block from the memory pool to allocate to the current CAN channel, caching CAN data transmitted by the CAN channel into the newly allocated memory block, and adding a timestamp.

In one embodiment of the application, data reception and data compression are performed by different threads respectively. And after the data compression thread executes the corresponding data compression task, sending a notification of data compression completion to the data receiving thread so that the data receiving thread releases the memory block space, namely, the memory block is marked as available again and added into the memory pool.

And S113, storing the received CAN data into a memory block allocated to the CAN channel.

And if the memory block corresponding to the current CAN channel has enough space to store new CAN data, directly storing the new CAN data into the memory block, and adding a timestamp.

The process of receiving the CAN data provided by this embodiment allocates different memory blocks for different CAN channels, and after receiving the CAN data transmitted by this CAN channel, first determines whether there is enough space for the memory block allocated by this CAN channel, if so, directly stores this CAN data, if not, triggers the processing of the next link, thereby realizing centralized processing rather than processing one by one for the received CAN data, and thereby improving the data uploading efficiency.

In another embodiment of the present application, as shown in fig. 4, the process of storing the compression task into the compression task queue is as follows:

s131, judging whether the compression task queue is full; if so, go to S132; if not, S133 is executed.

After the data compression thread receives the data compression task sent by the data receiving thread, the data compression thread judges that the compression task queue is full, if the compression task queue is full, a new compression task cannot be written in, and if the compression task queue is not full, the new compression task can be stored continuously.

S132, deleting the earliest compression task in the compression task queue.

If the compression task queue is full, the earliest compression task in the queue is taken out (namely the earliest compression task is deleted from the compression task queue), and the memory space for storing the CAN data corresponding to the compression task is recycled, namely the memory block is marked as available again and added into the memory pool. And then S133 is executed.

The earliest compression task in the queue refers to the compression task which is currently stored in the queue and has the earliest queuing time.

And S133, storing the compression task into the compression task queue.

If the compression task queue is full, the new compression task can be added into the compression task queue after the oldest compression task is deleted.

And if the compression task queue is not full, directly storing the new compression task into the compression task queue.

And S134, starting a compression task timer when the compression task is determined not to be executed currently.

After storing the new compression task into the compression task queue, if the compression task is not executed currently, starting a compression task timer, namely starting timing by the compression task timer.

The purpose of setting the compression task timer is to trigger the data compression thread to perform data compression operations. The compression task timer can achieve two effects, namely, the asynchronous execution effect can be achieved; another is to be able to perform the compression operation by a compression task timer cycle in case the compression task queue is not empty but no new compression task is received.

In the process of compressing the task queue by the compression task storage according to the embodiment, the compression task queue is used for realizing asynchronous execution of CAN data reception and data compression, instead of executing compression operation immediately after receiving a piece of CAN data, so that the data uploading efficiency is improved. Moreover, the data received first can be guaranteed to be compressed and uploaded first, and the real-time performance of data uploading is guaranteed.

In one embodiment of the present application, as shown in FIG. 5, the process of performing the compression task is as follows:

s135, when the compression task timer is triggered, judging whether the compression task queue is empty; if not, executing S136; if so, the current flow ends.

And triggering the compression task timer when the timing duration of the compression task timer reaches a first set time.

In one embodiment of the present application, as described above, after a new compression task is added to the compression task queue, and when the compression task is not currently executed, the compression task timer is started.

And S136, determining the positioning information of the memory block according to the compression task read from the compression task queue, and reading the CAN data to be compressed from the memory block according to the positioning information.

As described above, the compression task includes an address of a memory block storing data to be compressed, and the CAN data to be compressed is read from the corresponding memory block according to the address.

And S137, compressing the CAN data to be compressed to obtain the compressed CAN data.

And S138, informing the data uploading thread to upload data and informing the data receiving thread to recycle the corresponding memory space.

And storing the compressed CAN data into the applied new memory block, and informing a data receiving thread to recover the memory space of the original CAN data corresponding to the compressed CAN data. And informing the data uploading thread to upload the compressed CAN data, namely generating an uploading task.

And S139, when the compression task queue is determined not to be empty, starting the compression task timer again.

Namely, the starting condition of the compression task timer includes two cases: one is to add a new compression task into the compression task queue and start when no compression task is currently executed; the other is that the data compression thread is started after executing a compression task and the compression task queue is not empty.

In the data compression process provided by this embodiment, after the compression task timer is triggered, a compression task is read from the compression task queue and executed, and the compression task timer is utilized to implement asynchronous execution of the reception and execution of the compression task, so that the compression task received first is executed first, the real-time performance of data uploading is ensured, and meanwhile, the data uploading efficiency can be improved.

In an embodiment of the application, a data uploading thread is mainly responsible for uploading data, and when the vehicle-mounted device is initialized, an uploading task queue and a cache file list need to be created, and a cache file monitoring timer is started. As shown in fig. 6, the data upload process is as follows:

s141, generating an uploading task according to the compressed CAN data, and judging whether an uploading task queue is full; if not, go to S144; if yes, go to S142;

after the CAN data are compressed by the data compression thread, a corresponding uploading task is generated and sent to the data uploading thread, so that the compressed data CAN be uploaded in time. The upload task includes location information of a memory block storing the data to be uploaded, such as a first address and a size of the memory block.

After the data uploading thread receives the uploading task sent by the data compression task, the uploading task needs to be added into an uploading task queue, before the uploading task is added into the queue, whether the uploading task queue is full is judged, and if the queue is not full, the newly received uploading task can be directly added into the queue.

And S142, writing the compressed CAN data corresponding to the earliest uploading task in the uploading task queue into a disk file, and adding the disk file into the cache file list.

And if the queue is full, the newly received uploading task cannot be directly added into the queue, in this case, the earliest uploading task in the uploading task queue is read, compressed CAN data to be uploaded is read from the memory block according to the earliest uploading task, the compressed CAN data is written into a disk file, and the cache file is added into the cache file list.

And caching the data to be uploaded corresponding to the earliest task in the uploading task queue into a disk file, so that data loss can be avoided. Meanwhile, a new uploading task is ensured to be added into the uploading task queue and uploaded in time, and data is ensured to be uploaded in time.

S143, determining the source of the uploading task written in the disk file, and recycling the corresponding memory according to the determined source.

And (4) performing memory recovery by adopting different modes aiming at different sources of the compressed CAN data. Specifically, if the compressed CAN data comes from the data compression thread, the memory block used by the data compression thread for storing the compressed CAN data is recovered, that is, marked as available again; and if the compressed CAN data is read from the disk file, the memory block in which the compressed CAN data is read from the disk file is recovered by the data uploading thread. After S143, S144 is executed.

And S144, adding the uploading task into an uploading task queue.

S145, judging whether the uploading task is being executed, if not, executing S146; if yes, the current process is ended, and the step S146 is executed again until the uploading task is executed.

And S146, starting an uploading task timer.

And after the uploading task timer is started, the uploading task timer starts to time.

The uploading task timer is used for taking out the compressed CAN data from the uploading task queue for uploading after a fixed time period (namely a second set time length), so that the generation and execution of the uploading task are asynchronously executed, and the data uploading efficiency is improved.

In this embodiment, a new upload task is added to the upload task queue, and the upload task queue is not empty, the upload task timer is started.

In another embodiment of the present application, an upload task timer is started when an upload task is executed and an upload task queue is not empty so as to trigger the upload operation to be executed circularly.

S147, judging whether the uploading task queue is empty or not when the uploading task timer is triggered; if not, go to S148; if yes, the current process is ended, and when the uploading task timer is triggered next time, whether the uploading task queue is empty is judged.

And triggering the uploading task timer when the timing time of the uploading task timer reaches a second set time, and then judging whether the uploading task queue is empty.

The uploading task queue is empty, which indicates that no unexecuted uploading task exists in the queue; if the upload task queue is not empty, the queue is indicated to have an unexecuted upload task.

And S148, reading the compressed CAN data from the memory block according to the uploading task in the uploading task queue, and sending the compressed CAN data to the cloud server.

And if the uploading task queue is not empty, reading an uploading task from the uploading task queue, and executing the uploading task.

In an application scenario, after a vehicle flameout signal (i.e., an IGN OFF signal) is detected, in order to avoid data loss after the vehicle is flamed out, the uploading task that is being executed is stopped, compressed CAN data corresponding to all the uploading tasks in an uploading task queue are written into a disk file, the corresponding disk file is added into a cache file list, and meanwhile, corresponding memory resources are recovered according to the data source of the uploading task.

In the upload task execution process provided by this embodiment, the upload task is triggered by the upload task timer to be executed circularly, so that the generation of the upload task and the asynchronous execution of the task execution are realized, instead of sequentially performing the operations of each step one by one, thereby improving the data upload efficiency. And the disk is used as the secondary cache of the memory, so that the data can be buffered to avoid losing when the network link is unstable and the data uploading is unsuccessful. Meanwhile, the real-time uploading is guaranteed to be prior to the disk cache, and the disk cache is only used under the necessary condition, so that the disk reading and writing operations are reduced, the efficiency is improved, and the reading and writing life of the disk is prolonged.

In another embodiment, when the upload task queue is empty (that is, the upload task queue is not empty and the ratio of the number of tasks in the queue to the total number of tasks that CAN be accommodated by the task queue is less than a preset ratio threshold), the upload task corresponding to the compressed CAN data written into the disk file is added into the upload task queue again so as to upload the data to the cloud server, and the process is triggered and executed by the cache file monitoring timer in a circulating manner. As shown in fig. 7, the process includes the steps of:

s1410, when the cache file monitoring timer is triggered, judging whether the disk is not empty and the number of tasks in the uploaded task queue is smaller than a preset proportion threshold value; if so, S1420 is performed. If not, the process is ended.

The preset proportion threshold may be determined according to the actual requirement and the size of the upload task queue, for example, 10%, and of course, in other embodiments, other values may be selected as the preset proportion threshold.

And S1420, reading the cache file from the disk, generating an uploading task according to the cache file, adding the uploading task into an uploading task queue, and starting a cache file monitoring timer.

The process of adding the upload task into the queue is the same as the process of S141 to S146, which is not described herein again, and the corresponding cache file is deleted from the cache file list.

According to the above content, the mechanism can ensure that data written in the disk file can also be uploaded to the cloud server, the uploading of the data of the disk file is triggered by the cycle of the cache file monitoring timer, and meanwhile, in order to ensure that compressed data generated in real time is prior to the data in the disk file, when the uploading task in the uploading task queue is less, the uploading task corresponding to the data in the disk file is added into the uploading task queue.

Corresponding to the embodiment of the CAN data acquisition method, the application also provides an embodiment of a CAN data acquisition device.

As shown in fig. 8, a CAN data acquisition device provided in an embodiment of the present application includes:

the data receiving module 110 is configured to receive CAN data transmitted by any CAN channel, store the CAN data in a memory block allocated to the CAN channel, and generate a corresponding compression task according to the CAN data stored in the memory block.

In an embodiment of the present application, the data receiving module 110 is configured to receive CAN data transmitted by any CAN channel, store the CAN data in a memory block allocated to the CAN channel, and when generating a corresponding compression task according to the CAN data stored in the memory block, specifically:

And the data compression module 120 is configured to store the compression task into the compression task queue, and read and compress the corresponding CAN data from the corresponding memory block according to the compression task in the compression task queue to obtain the compressed CAN data.

In an embodiment of the present application, when the data compression module 120 is configured to store the compression task in the compression task queue, it is specifically configured to:

judging whether the compression task queue is full;

and if the compression task queue is full, deleting the earliest compression task in the compression task queue, and storing the generated compression task into the compression task queue.

In an embodiment of the present application, when the data compression module 120 is configured to read corresponding CAN data from a corresponding memory block according to a compression task in a compression task queue and compress the corresponding CAN data to obtain compressed CAN data, specifically:

when the compression task timer is triggered, judging whether the compression task queue is empty or not, and starting the compression task timer when one compression task is executed and the compression task queue is not empty or a new compression task is added into the compression task queue and no compression task is currently executed;

if the compression task queue is not empty, reading the compression task from the compression task queue;

And the data uploading module 130 is configured to send the compressed CAN data to the cloud server according to a preset uploading policy, so that the cloud server decompresses and stores the compressed CAN data sent by the vehicle-mounted device.

In an embodiment of the present application, the data uploading module 130 is specifically configured to:

if the uploading task queue is full, writing compressed CAN data corresponding to the earliest uploading task in the uploading task queue into a disk file, and adding the uploading task to be added into the uploading task queue;

when the uploading task timer is triggered, judging whether the uploading task queue is empty or not, and starting the uploading task timer when an uploading task is executed and the uploading task queue is not empty or a new uploading task is added into the uploading task queue and no uploading task is currently executed;

and if not, reading the uploading task from the uploading task queue, reading the compressed CAN data from the memory block according to the read uploading task, and sending the compressed CAN data to the cloud server.

In another embodiment of the present application, after writing the compressed CAN data corresponding to the earliest upload task in the upload task queue into the disk file, the data upload module 130 is further configured to:

when the cache file monitoring timer is triggered, judging whether a disk is empty and the number of tasks in an uploaded task queue is smaller than a preset proportional threshold;

if the disk is not empty and the number of the tasks in the uploaded task queue is smaller than a preset proportional threshold, reading a cache file from the disk;

and generating an uploading task according to the read cache file, adding the uploading task into an uploading task queue, and starting a cache file monitoring timer.

In another embodiment of the present application, the data uploading module 130 is further configured to: and when the vehicle flameout signal is detected, stopping the uploading task which is being executed, and writing the compressed CAN data corresponding to all the uploading tasks in the uploading task queue into the disk file.

On the other hand, this application embodiment still provides a CAN data acquisition device who is applied to cloud server, as shown in fig. 9, the device includes:

and the data receiving module 210 is configured to receive compressed CAN data, where the compressed CAN data is obtained by the vehicle-mounted device by using the CAN data acquisition method on the vehicle-mounted device side, and the compressed CAN data includes data acquired by any CAN channel in the vehicle.

And the data application module 220 is configured to decompress the received compressed CAN data and store the decompressed CAN data in a database, so that the application plug-in extracts and processes the CAN data required by the application from the database.

The application provides a CAN data acquisition device gathers the CAN data of all CAN passageways on the vehicle by mobile unit to compress the CAN data and upload to high in the clouds server. The vehicle-mounted equipment does not filter, screen, analyze and process the CAN data, and the cloud server is responsible for the utilization of the CAN data including receiving, analyzing, warehousing and utilization. Therefore, the cloud server CAN obtain the full CAN data of the vehicle, and CAN quickly obtain the CAN data required by the new application requirement from the received full CAN data when facing the requirement change, namely quickly responding to the new scene requirement change. In addition, the vehicle-mounted equipment compresses the CAN data and then uploads the compressed CAN data, so that the bandwidth and the flow required by uploading the CAN data are reduced.

An in-vehicle device includes a processor and a memory having stored therein a program executable on the processor. When the processor runs the program stored in the memory, any CAN data acquisition method executed by the vehicle-mounted equipment is realized.

The embodiment of the application provides a server, and equipment comprises a processor, a memory and a program which is stored on the memory and CAN run on the processor, wherein when the processor executes the program, any CAN data acquisition method executed by the cloud server is realized.

The processor comprises a kernel, the kernel fetches corresponding programs from the memory, and the kernel can be set to one or more than one.

While, for purposes of simplicity of explanation, the foregoing method embodiments have been described as a series of acts or combination of acts, it will be appreciated by those skilled in the art that the present application is not limited by the order of acts or acts described, as some steps may occur in other orders or concurrently with other steps in accordance with the application. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required in this application.

It should be noted that, in the present specification, the embodiments are all described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments may be referred to each other. For the device-like embodiment, since it is basically similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

The steps in the method of the embodiments of the present application may be sequentially adjusted, combined, and deleted according to actual needs.

The device and the modules and sub-modules in the terminal in the embodiments of the present application can be combined, divided and deleted according to actual needs.

In the several embodiments provided in the present application, it should be understood that the disclosed terminal, apparatus and method may be implemented in other manners. For example, the above-described terminal embodiments are merely illustrative, and for example, the division of a module or a sub-module is only one logical division, and there may be other divisions when the terminal is actually implemented, for example, a plurality of sub-modules or modules may be combined or integrated into another module, or some features may be omitted or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or modules, and may be in an electrical, mechanical or other form.

The modules or sub-modules described as separate parts may or may not be physically separate, and parts that are modules or sub-modules may or may not be physical modules or sub-modules, may be located in one place, or may be distributed over a plurality of network modules or sub-modules. Some or all of the modules or sub-modules can be selected according to actual needs to achieve the purpose of the solution of the present embodiment.

In addition, each functional module or sub-module in the embodiments of the present application may be integrated into one processing module, or each module or sub-module may exist alone physically, or two or more modules or sub-modules may be integrated into one module. The integrated modules or sub-modules may be implemented in the form of hardware, or may be implemented in the form of software functional modules or sub-modules.

Finally, it should also be noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

The foregoing is only a preferred embodiment of the present application and it should be noted that those skilled in the art can make several improvements and modifications without departing from the principle of the present application, and these improvements and modifications should also be considered as the protection scope of the present application.

Claims

1. A CAN data acquisition method is characterized by being applied to vehicle-mounted equipment, and comprises the following steps:

2. The method according to claim 1, wherein the receiving and storing the CAN data transmitted by any CAN channel into a memory block allocated to the CAN channel comprises:

if the memory space of the memory block is insufficient, the memory block allocated to the CAN channel is marked as unavailable, a compression task corresponding to the CAN data stored in the memory block is generated, a new memory block is allocated to the CAN channel again, and the received CAN data is stored in the new memory block.

3. The method according to claim 1, wherein the generating the corresponding compression task according to the CAN data stored in the memory block includes:

4. The method of claim 1, wherein storing the compressed task into a compressed task queue comprises:

judging whether the compression task queue is full;

5. The method according to claim 1, wherein reading and compressing the corresponding CAN data from the corresponding memory block according to the compression task in the compression task queue to obtain compressed CAN data, includes:

when the timing of a compression task timer reaches a first set time length, judging whether the compression task queue is empty or not, wherein the compression task timer starts timing when a compression task is executed and the compression task queue is not empty or a new compression task is added into the compression task queue and no compression task is executed;

6. The method of claim 1, wherein sending the compressed CAN data to a cloud server according to a preset upload policy comprises:

generating an uploading task according to the compressed CAN data, and judging whether the uploading task queue is full;

and if the uploading task queue is not empty, reading the uploading task from the uploading task queue, reading the compressed CAN data from the memory block according to the read uploading task, and sending the compressed CAN data to the cloud server.

7. The method of claim 6, wherein after writing compressed CAN data corresponding to an earliest uploading task in the uploading task queue to a disk file, the method further comprises:

when a cache file monitoring timer is triggered, judging whether the disk is empty and the number of tasks in the uploading task queue is smaller than a preset proportional threshold;

8. A CAN data acquisition method is applied to a cloud server, and comprises the following steps:

receiving compressed CAN data, wherein the compressed CAN data is obtained by vehicle-mounted equipment by using the CAN data acquisition method of any one of claims 1 to 7, and the compressed CAN data comprises data acquired by any one CAN channel in a vehicle;

9. The CAN data acquisition device is applied to vehicle-mounted equipment, and comprises:

10. The utility model provides a CAN data acquisition device which characterized in that is applied to in the high in the clouds server, the device includes:

the CAN data acquisition system comprises a data receiving module, a data processing module and a data processing module, wherein the data receiving module is used for receiving compressed CAN data, the compressed CAN data are obtained by vehicle-mounted equipment by using the CAN data acquisition method of any one of claims 1 to 7, and the compressed CAN data comprise data acquired by any one CAN channel in a vehicle;