CN111447128A

CN111447128A - Vehicle data acquisition and uploading method capable of being remotely and dynamically configured and storage medium

Info

Publication number: CN111447128A
Application number: CN202010215063.4A
Authority: CN
Inventors: 喻胜; 曾国龙
Original assignee: Chongqing Changan Automobile Co Ltd
Current assignee: Chongqing Changan Automobile Co Ltd
Priority date: 2020-03-24
Filing date: 2020-03-24
Publication date: 2020-07-24

Abstract

The invention discloses a vehicle data acquisition uploading method capable of realizing remote dynamic configuration and a storage medium, which adopt a white list filtering mechanism, receive configuration information issued by a TSP service provider through a built-in communication module, control the triggering condition and corresponding action of a CAN signal by using an MCU after script analysis, and realize data acquisition, data processing, storage and uploading of white list CAN messages through a data processing module in a T-BOX. The invention CAN realize the real-time communication between the CAN network of the automobile body and the outside, so that an automobile design manufacturer or a service provider CAN monitor the working state of each controller of the automobile body in real time.

Description

Vehicle data acquisition and uploading method capable of being remotely and dynamically configured and storage medium

Technical Field

The invention belongs to the technical field of vehicle data acquisition and transmission, and particularly relates to a vehicle data acquisition and uploading method capable of realizing remote dynamic configuration and a storage medium.

Background

In the automobile Control, each controllable hardware corresponds to an ecu (electronic Control unit), i.e., an electronic Control unit. As a vehicle-specific microcontroller, the ECU generates corresponding signals at the same time as controlling the components. With the increase of automobile controllable hardware, the number of ECUs is increased. When a plurality of ECUs exist in a vehicle body and information interaction exists, the CAN network technology is rapidly applied.

Can (era Control network) network, i.e. local area controller network, is generally applied to automobile Control networks. In the CAN network, each common node participating in CAN network communication is called a CAN node. Corresponding to the whole vehicle, each ECU is regarded as a CAN node, and all the CAN nodes are connected through a CAN bus. Because of the numerous vehicle body ECUs, the functions and signal transmission rates of the various ECUs are different. Accordingly, the vehicle body CAN bus is divided into a plurality of CAN buses. In order to facilitate management of signal transmission and processing of each CAN node on each CAN bus, a gateway is introduced to realize overall management.

Generally, a vehicle body CAN network is relatively closed, and cannot perform real-time information interaction with a network outside the vehicle body. Under the traditional mode, the MCU terminal can fixedly collect several types or several types of signals for uploading, but the method has more limitations: firstly, the requirement of real-time uploading cannot be realized in the current rapid social rhythm; secondly, the adopted signals are set as defaults before leaving the factory, so that the information interaction cannot be realized more flexibly. In view of the above, it is very important to develop a new scheme to realize the collection and uploading scheme of the remote dynamic configuration data.

Disclosure of Invention

The invention aims to provide a whole vehicle data acquisition uploading method and a storage medium capable of being remotely and dynamically configured so as to realize real-time communication between a vehicle body CAN network and the outside, so that a vehicle design manufacturer or a service provider CAN monitor the working state of each controller of a vehicle body in real time.

The invention relates to a vehicle data acquisition uploading method capable of realizing remote dynamic configuration, which adopts a white list filtering mechanism, receives configuration information issued by a TSP service provider through a built-in communication module, controls the triggering condition and the corresponding action of a CAN signal by using an MCU after script analysis, and realizes data acquisition, data processing, storage and uploading of white list CAN messages through a data processing module in a T-BOX.

Further, after XM L script information issued by the TSP service provider is acquired, script data is converted into CAN white list information which CAN be identified by the system through script analysis and conversion, and the MCU configures trigger conditions and actions of corresponding CAN signals.

Further, after the MCU acquires CAN white list information, the CAN white list information is fed back to the NAD side, the NAD acquires each signal position in a CAN signal of the vehicle body according to the DBC text of the vehicle type, and the signal positions are in one-to-one correspondence with the CAN in the white list configuration information fed back by the MCU, so that matching of TSP configuration information and the CAN signal of the vehicle body is completed.

Further, when the CAN signals in the CAN white list in the CAN network change, the CAN transceiver module collects the changed CAN signals.

Further, when the collected CAN signals are subjected to data processing, the collected CAN signals are subjected to combinational logic judgment, and after the preset logic combination is met, corresponding events are triggered to carry out packet uploading of corresponding data; the trigger event comprises parameter uploading, operation of the parameters and historical data uploading.

Further, the reporting logic of the current configuration script is obtained according to other items analyzed in the configuration flow, and when the uploading mode is immediate uploading, the data is uploaded in real time; when the uploading mode is the regular storage uploading, the data is written into the sending buffer area firstly, and then the compression uploading is carried out.

In a second aspect, the present invention provides a storage medium storing one or more computer readable programs, which when being invoked by one or more controllers, can implement the steps of the vehicle data acquisition and upload method capable of being remotely and dynamically configured according to the present invention.

The invention has the following advantages: in the data acquisition process, the limitation of data signals to be acquired can be realized through a remote configuration mode, the data signals can be acquired after the corresponding signals are changed, and the storage and communication pressure caused by the practical problems of insufficient storage, limited bandwidth and the like due to numerous vehicle body area data is effectively solved. Compared with other data acquisition modes, the scheme can be dynamically configured, and can freely set data acquisition rules and uploading rules, such as timing acquisition, change acquisition and event trigger acquisition; timed uploading, fixed data size uploading, real-time uploading, compressed uploading and the like. The system has certain data storage capacity and real-time analysis capacity, and can be used for various scenes such as remote monitoring, behavior analysis, remote control and the like.

Drawings

FIG. 1 is a system framework diagram of the present invention;

FIG. 2 is a timing diagram illustrating configuration script parsing and loading in accordance with the present invention;

FIG. 3 is a schematic diagram of an XM L script format configured by a TSP server in the present invention;

FIG. 4 is a diagram of the correspondence of signal parameters in the present invention;

FIG. 5 is a timing diagram of CAN message synchronization and processing in the present invention;

FIG. 6 is a flow chart of data packet packing and uploading in the present invention;

FIG. 7 is a state transition diagram of a CAN message in the present invention;

FIG. 8 is a flow chart of the big data processing module according to the present invention;

FIG. 9 is a schematic representation of the CAN matrix for NAD maintenance by the Tbox of the present invention.

DETAILED DESCRIPTION OF EMBODIMENT (S) OF INVENTION

The present invention will be described in detail below with reference to the accompanying drawings.

In this embodiment, a white list filtering mechanism is adopted, configuration information issued by a TSP service provider is received through a built-in communication module, a trigger condition and a corresponding action of a CAN signal are controlled by using an MCU after script analysis, and data acquisition, data processing, storage, and uploading of a white list CAN message are realized through a data processing module in a T-BOX. The method specifically comprises the following steps:

after XM L script information issued by TSP service provider is obtained, script data is converted into CAN white list information which CAN be identified by system through script analysis and conversion, and MCU configures trigger condition and action of corresponding CAN signal.

And after the MCU acquires the CAN white list information, feeding the CAN white list information back to the NAD side, acquiring each signal position in the CAN signal of the vehicle body by the NAD according to the DBC text of the vehicle type, and corresponding each signal position to the CAN in the white list configuration information fed back by the MCU one by one to complete the matching of the TSP configuration information and the CAN signal of the vehicle body.

When CAN signals in a CAN white list in a CAN network change, the CAN transceiver module collects the changed CAN signals.

When the collected CAN signals are subjected to data processing, the collected CAN signals are subjected to combinational logic judgment, and after the preset logic combination is met, corresponding events are triggered to carry out packet uploading of corresponding data; the trigger event comprises parameter uploading, operation of the parameters and historical data uploading.

Acquiring the reporting logic of the current configuration script according to other items analyzed in the configuration flow, and uploading data in real time when the uploading mode is immediate uploading; when the uploading mode is the regular storage uploading, the data is written into the sending buffer area firstly, and then the compression uploading is carried out.

The present embodiment is described in detail below with reference to examples:

(1) parsing of TSP configuration files

The TSP server issues a configuration file which contains a combinational logic configuration script. A timing diagram for configuration script parsing and loading is shown in fig. 2.

XM L script format configured from TSP server, see fig. 3.

In the above example, the message transmitted from the conventional TSP server to the T-BOX includes the following four parts:

① respStatus (request type);

② errorCode (error code);

③ errorMsg (error message);

④ data (big data related parameter).

The parameter function of the data section will be mainly described as follows:

1) CanIdwhite L ist, CAN ID whitelist description field, including CanId field, Timeout field, and SampleCycle field;

2) the uplink rule L ist is an acquisition and uploading rule of a message to be uploaded, and the uplink rule L ist comprises the following fields:

RuleType, upload rule of current Case;

collecting condition, collection rule of message to be uploaded;

collecting content, namely collecting the CAN message ID required to be collected after the condition is triggered;

upload condition of the upload condition, case;

the ConditionType is used for acquiring the uploading mode of the message, including immediate uploading and cache uploading;

the ConditionContent, a cache upload limit condition, including cache size, etc.;

the UploadType is used for acquiring the uploading format of the message, and comprises TCP uploading and file uploading;

the UploadParameter describes uploading parameters;

mid, describing the Mid number of the TCP uploading mode;

FileType, which describes the uploaded descriptor.

3) ConfTimestamp, the configuration time of the current configuration script, is used to update the configuration script usage.

The big data analysis module comprises an analysis submodule and a processing submodule, wherein the analysis submodule needs to analyze the message into a data message which can be synchronously sent to the processing submodule, and the constrained conversion format rule is as follows:

conversion of operators: the involved operators are converted by binary data of 1 byte, and the specific correspondence is shown in table 1.

Table 1:

analysis relation of CAN signal/message: the premise of signal conversion is that the NAD must maintain CAN messages of the current vehicle type, the NAD searches the position of a signal in a signal table at the NAD side by searching a signal name table in a configuration file, and the signal of the signal table strictly corresponds to the name. Therefore, the corresponding signals in the conditions and the operation in the configuration file are analyzed, and the analysis of the signals is realized. The correspondence of the signal parameters is shown in fig. 4.

(2) Update synchronization of CAN signals

After the signals in the CAN network are updated, the CAN module on the MCU side uploads the change of the collected message to the NAD, and the CAN signal processing module on the NAD side performs logic processing and uploads the result combination to the TSP server, and the synchronization timing chart is shown in fig. 5.

(3) Reporting of collected data

The big data analysis module calculates and processes the trigger result, and the big data analysis module needs to obtain the reporting logic of the current configuration script according to the Other items analyzed in the configuration flow.

The data uploading module needs to analyze an Update _ Method field, namely, the uploading mode:

when the uploading mode is immediate uploading: the data uploading module packages and uploads the data;

when the uploading mode is uploading after the storage for a fixed time: the data uploading module stores the time according to the ConditionContent description; and when the triggering timeout time is detected to be larger than the preset time, the data uploading module compresses the data in the time period in the extracted storage space and uploads the compressed data.

The reporting process is shown in fig. 6.

(4) MCU side CAN data processing

① CAN data frame collected in vehicle body domain

The CAN message collected in the vehicle body domain CAN be set according to actual needs. When the MCU collects the signal change in the CAN network in real time and is subjected to differential processing and CAN message state processing, the signal change is synchronized to a storage buffer area of a CAN signal processing module at the NAD (networking module) side for further processing.

② IACC (i.e. integrated adaptive cruise system) CAN data frame needing to be collected

The CAN message which needs to be collected by the IACC CAN be set according to actual needs. And when the MCU acquires the signal change in the CAN network in real time and is subjected to differential processing and CAN message state processing, the signal change is synchronized to a storage buffer area of a CAN signal processing module at the NAD side for further processing.

③ CAN signal acquisition and uploading fault-tolerant processing

The CAN signals received in the body domain and the IACC domain are necessary parameters for big data processing. In an exception case, a functional exception of big data handling may result:

1) during communication between the MCU and the NAD, part of necessary CAN messages are lost: the signal loss in the necessary CAN message may cause that in the IACC mode, the data upload module will uninterruptedly transmit invalid data to the TSP, which affects data blocking of other networking functional modules and affects the overall function.

2) CAN network blocking: due to the limitation of the transmission bandwidth of the MCU and the NAD, if the signal change in the CAN network is fast, the CAN message is synchronously blocked, and the data loss is caused.

Therefore, fault-tolerant processing is required in the acquisition logic of the CAN message at the MCU side to ensure high timeliness of the input parameter of the big data module.

Fault tolerance strategy:

1) in the CAN message receiving stage of the MCU side, the ID validity of the message, the legal length of the message, the validity of the signal in the message and the like need to be checked, and the message is directly discarded without rules;

2) the state of the CAN message needs to be monitored and recorded on the MCU side, and the synchronization of the state data CAN be uploaded at regular time.

3) And a redundancy check and retransmission mechanism is required to be carried out on data in the data communication between the MCU and the NAD, so that data loss is prevented.

④ CAN Signal acquisition

The synchronization of the CAN messages is transmitted in the format of a binary data packet to reduce the transmission bandwidth of the MCU and the NAD, and the specific synchronization format is shown in table 2:

table 2:

ID	LENTH	PAYLOAD
			2BYTE	1BYTE	n BYTE(n<＝8)

wherein ID is the serial number of the CAN frame with the high byte in front during transmission, L ENTH is the actual length of PAY L OAD, and PAY L OAD is the actual data of the CAN frame.

⑤ CAN signal storage format

Because the message synchronized to the NAD by the MCU does not describe detailed signal functions, different signals in the CAN network need to be maintained in the CAN message processing module on the NAD side according to the definition of the DBC file, so as to provide a convenient access path for other modules. The signal format maintained in the CAN message processing module at the NAD side is as follows:

STRUCT SIGNAL{

SIGNA L _ DATA _ FROM _ CAN// CAN signal parameter values

SIGNA L _ NAME// CAN signal NAME

SIGNA L _ DATA _ START _ BIT;/CAN signal START BIT

SIGNA L _ DATA _ WIDE// number of bits occupied by CAN signal

SIGNA L _ DATA _ EXCHANGE _ FROM _ DBC// Signal conversion to actual valid parameter value

SIGNA L _ DATA _ STATE, the STATE of the// signal 0 indicates that the signal is invalid and 1 indicates that the signal is normal.

}；

⑥ CAN signal state synchronization

And the NAD receives the CAN message synchronized with the MCU and updates a signal table maintained by the NAD in real time. Because the synchronous function of the MCU uses differential reporting, namely the CAN signal is synchronized to the NAD side under the condition of change. Under abnormal conditions, if the CAN message is sent from normal to abnormal and stops, the real value of the signal cannot be acquired in the process, and the parameter abnormality is caused to cause an error result. Therefore, when the MCU synchronizes the NAD differential changing messages, the state of all messages needs to be uploaded synchronously, which is used as the basis for the fault tolerance of the CAN signal processing module.

The CAN message comprises three states of initialization, loss and normal.

The state transition of the CAN message is shown in fig. 7. From the CAN message states depicted in the figure, the values of the desirable parameters for CAN message state synchronization CAN be defined, as shown in table 3. The state of one CAN message is marked by using 2 bits in the table, so that the state of all CAN messages marked on the MCU side only needs less bytes, and the communication pressure between the MCU and the NAD is reduced as much as possible on the premise of increasing functions.

Table 3:

(4) NAD side CAN data processing

The main functions of the big data analysis module are as follows: loading a CAN message white list (CAN message filtering); loading of a combinational logic processing script; analyzing the combined logic processing script; acquiring and packaging CAN signals; compression and synchronization of data packets. After receiving the change of the CAN signal, the processing flow of the CAN signal processing module is as shown in fig. 9.

① classification of CAN data

The CAN signal processing module has the main functions of filtering CAN messages defined in primitive language according to TSP configured messages and classifying differential signals reported by the MCU. And dividing the received CAN messages into CAN messages related to vehicle types and CAN messages related to big data.

② storage of CAN data

And the CAN data is independently stored after being distributed. The CAN message related to the vehicle type CAN be divided into two parts, wherein one part is a signal (original function) related to the Tbox state; the other part is a CAN message related to big data, and the CAN message is directly synchronized to a big data analysis module of the NAD.

③ conditional combining and decision logic for CAN data

The input of the condition combination logic of the CAN data is part of CAN signals in a CAN message white list, and the combination logic of the CAN signals triggers corresponding events when meeting the appointed conditions so as to realize the uploading of corresponding data. The triggered event can be parameter uploading, operation of the parameter and historical data uploading and the like. And when the triggering condition of the real-time reporting logic is met, uploading the packed corresponding data to be uploaded to the TSP server. And under the condition that partial input combinational logic conditions are met, triggering and reporting the historical data packet.

After the trigger source executes, data of the first 30s and the last 10s when the trigger state changes need to be recorded, so the reporting time of the data packet is 10s after the event trigger. And the primitive processed by the combinational logic can be configured by the TSP server, and the corresponding requirement of uploading data can be decomposed into conditions and actions. The MCU synchronizes the differential CAN message to the CAN signal processing module of the NAD, and the CAN signal processing module needs to maintain all reported CAN signal state tables, namely the CAN signal table of the NAD side is consistent with the CAN signal table of the MCU side. The parameter data uploaded in real time is shown in table 1, and the historical data to be uploaded in real time is shown in table 4.

Table 4:

④ processing of combinational logic data

The data format of the combinational logic which is configured by the TSP and transmitted to the data downloading module adopts the Json format. Each primitive must contain the following:

condition ═ and "; // Condition, i.e. input

Operation ═ o "; // operation, i.e. output

The following examples are given:

Condition＝"((ACC_ESPPrefill＝＝0x1)||(ACC_ABAavailable＝＝0x1)||(ACC_PCW_latentWarning＝＝0x1)||(ACC_PCW_preWarning＝＝0x1)||(ACC_AWBavailable＝＝0x1)||(ACC_AEBDecCtrlAvail＝＝0x1))！＝0x00"；

Operation＝"ACC_ESPPrefill；ACC_ABAavailable；ACC_PCW_latentWarning；ACC_PCW_preWarning；ACC_AWBavailable；ACC_AEBDecCtrlAvail；HU_LocalTimeYear；HU_LocalTimeMonth；HU_LocalTimeDate；HU_LocalTimeHour；HU_LocalTimeMinute；HU_LocalTimeSecond；HU_CurrentLocationLongitude；HU_CurrentLocationLatitude；IP_TotalOdometer；HU_navCurrentRoadType；ESP_VehicleSpeed；"；

in the above example, the Operation is triggered when the CAN signal satisfies the Condition. Namely, the big data processing module reads the CAN signal table maintained in the CAN signal processing module. And only when the Condition is established, the big data processing module executes corresponding Operation according to the primitive description in the Operation, packages the signals in the Operation and synchronizes the signals to the data uploading module.

The combinational logic processing submodule of the big data analysis module needs to support the following primitive analysis functions: dividing the primitive according to the operational characters; the CAN signal name is matched with the CAN signal value; converting character strings and numerical values; mapping the functions of the operational characters;

matching and merging of Operation.

The primitives are partitioned according to the operators. The big data parsing module needs internal operation logic for extracting high-priority operation primitive fragments from Condition and preferentially interpreting the primitive fragments.

The CAN signal name is matched with the CAN signal value. The big data analysis module needs to extract the corresponding CAN signal name from the Condition, compare the CAN signal name with a CAN signal table, perform escape, and take the escape result as the next parameter.

And converting the character string and the numerical value. The big data analysis module needs to support decimal and hexadecimal parameter conversion.

The functional mapping of operators, contains basic binary operators. The big data parsing module needs to support operators so as to support partial operation logic.

Matching and merging of Operation. Matching of Operation needs to support the following functions: setting a timer; setting a trigger; matching the CAN signal name to be sent with the CAN signal value; the packets of the signal to be transmitted.

In this embodiment, table 5 is an operator table of the combinational logic processing primitive:

table 5:

operational character	Description of functions	Remarks for note
			+	Adding	Binary operator
-	Reducing	Binary operator
			*	Riding device	Binary operator
/	Removing device	Binary operator
			％	Get surplus	Binary operator
&	Is pressed to be located at	Binary operator
			\|	On the basis of position or	Binary operator
&&	And	binary operator
			\|\|	Or	Binary operator
>	Is greater than	Binary operator
			<	Is less than	Binary operator
>＝	Not less than	Binary operator
			<＝	Not more than	Binary operator
！＝	Is not equal to	Binary operator
			()	Brackets	Combinatory operator
；	Branch number	Decomposing operators

⑤ CAN packet packing and processing

The packaging of the CAN data packet is divided into two parts.

1) And packaging the real-time data packet. The main function of the real-time data is to connect the user with the automobile through the network to realize real-time interaction, so that only corresponding fixed messages need to be transmitted in data processing, and the bandwidth of the TSP server is consumed to reduce the processing pressure of the server and the T-box.

2) Compressed packing of history/fixed-length packets. The history/fixed length data is mainly used for recording the running data of the automobile so as to record the use condition of the automobile. The real-time requirement on the data is low. And when the data packet uploading condition meets the condition, writing the data into the file and performing compression transmission to reduce the bandwidth of the TSP server.

(6) Data packet upload and retransmission

And writing the data packet to be uploaded into the sending buffer area, and informing the data uploading module to upload the data.

The format of data transmitted to the TSPHander module by the real-time uploaded data packets is shown in table 6:

table 6:

and uploading the data packet, wherein the format is as follows:

interface address:

https://{fileUploadDomain}:{serverDomainPort}/{apiContext}/api/2.0/termina l/uploadFile

the request mode comprises the following steps: POST (positive position transducer)

Input HTTP UR L Fields/HTTP Post Form Fields:

tuid: terminal unique identifier

DeviceTime terminal System time stamp (represented by type Long from 1970 to the present), accurate to milliseconds. Such as: 1463106055567 (standing for 2016-5-1310: 21: 46.567).

type, the service type of the uploaded file, the value range of which is BigData (big data), L og (log), Dtc (log), OverHeat, UserBehavior (user behavior), Carbody (vehicle body domain), if empty, the server defaults to the log file

sign: signature, take the value of sha256(md5 (terminal certificate public key file) + deviceitime)

valid, file integrity check, value md5 (Log File)

file, wherein the log file uploaded by the terminal is recommended to be uploaded by using a compressed packet, and the uploaded log is named according to the following rules:

tuid _ [ terminal upload time, format: yyyMMddHHmmss ]. zip is as follows:

10001001160913110000000300287980_20170109161200.zip

the retransmission function of the data packet needs to be processed by the data uploading module, and the data uploading module needs to transmit the sending state to the big data analyzing module as an input parameter of the module.

The transmission state is as follows: the transmission is successful; during the sending; failed to transmit and retry; the transmission fails.

When the data uploading module fails to send the data packet, the data uploading module needs to notify the data storage module to store the data packet which is failed to send into the nonvolatile storage area, and waits for subsequent retry.

Because the data packet is stored in the read-write Flash area, in order to prevent the Flash from having a short service life caused by repeated erasing and writing to a fixed Flash space for a long time, the data storage module needs to realize a nonlinear storage logic, namely, the addresses of the data packet written in each time are different, thereby reducing the service life of the Flash area.

(7) Interaction of related modules

① MCU-to-NAD communication protocol

After the MCU acquires and processes the CAN message, the data of the packaged CAN message is synchronized to the NAD side so that the NAD side CAN analyze the message and decompose the signal. The MCU will encapsulate the message in the format shown in table 7 at the stage to be uploaded:

table 7:

data type	CAN ID	Lenth	Payload
				Data length	2 bytes	1 byte	(L nth) byte

The field description:

CAN ID: namely, the MCU is synchronized to the CAN message ID number of the NAD, and the standard frame ID is from 0x0000 to 0x07 FF;

l nth, namely the Payload length of the CAN message to be uploaded;

payload: that is, the actual data of the current CAN packet includes all the signals of the current packet.

After the MCU side collects the CAN packet, it will periodically synchronize to NAD, and the format of the synchronized communication protocol is shown in table 8:

table 8:

the field description:

channel: the MCU synchronizes the channel number of the CAN message;

SID MID: the MCU synchronizes protocol numbers of the CAN messages;

the CAN Frame: data of a single CAN message;

CRC: the CRC check value of the current data frame.

② NAD to MCU communication protocol

And after receiving the new configuration file, the NAD obtains big data white list data through analysis and decomposition. And the NAD synchronizes the white list data to the MCU side so as to analyze and report the white list of the CAN message of the MCU side. The single data format of the white list is shown in table 9:

table 9:

data type	CAN ID	Upload Count
			Data length	2 bytes	2 bytes

The field description:

cycle Time: defaulting to use 5s as a message effective period;

upload Count: that is, the MCU actually synchronizes to the frequency of the NAD after acquiring the message change.

After collecting the white list data, the NAD side synchronizes to the MCU, and the format of the synchronized communication protocol is shown in table 10:

table 10:

the field description:

channel: the channel number of the NAD synchronous CAN message white list;

SID MID: the protocol number of the NAD synchronous CAN message white list;

control St: a control frame, 0x01 represents a single frame, 0x02 represents a multiframe imperfection, and 0x03 represents a multiframe end;

white L ist, data of a single CAN message White list;

CRC: the CRC check value of the current data frame.

③ MCU to NAD configuration confirmation protocol

And after receiving the white list data of the NAD configuration, the MCU replies a configuration data receiving state message to the NAD. The message format is shown in table 11:

table 11:

Channel	SID	MID	Status
				1 byte	1 byte	1 byte	1 byte
0x12	0x02	0x2E	......

The field description:

channel: the MCU synchronizes the channel number of the CAN message;

SID MID: the MCU synchronizes protocol numbers of the CAN messages;

status: data of a single CAN message. The value range is as follows: 0x00 synchronization failure; the 0x01 synchronization was successful.

④ MCU-to-NAD message state synchronization protocol

And the MCU synchronizes the loss state of the message to the NAD when judging that the message received in the white list is not updated within the overtime time.

The message format is shown in table 12:

table 12:

Channel

SID

MID

Status

CAN ID

Status

CAN ID

1 byte

2 bytes

1 byte

2 bytes

0X12

0X02

0x25

......

The field description:

channel: the MCU synchronizes the channel number of the CAN message;

SID MID: the MCU synchronizes protocol numbers of the CAN messages;

description of the State group:

status: status of a single CAN message. The value range is as follows: 0x00 missing; 0x01 reservation;

CAN ID: the ID value of the CAN message in the lost state.

⑤ TBox to TSP communication protocol

And after the data uploading module of the Tbox collects the CAN message to be reported, uploading the CAN message to the TSP server according to the uploading rule in the configuration script. The uploading mode comprises the following steps: a TCP uploading mode; and (4) a file uploading mode. When the TCP uploading mode is selected: SID is a fixed value of 7, MID is determined by MID in the Uplodparameter parameter in the configuration, Content is shown in Table 13:

table 13:

when the file uploading mode is selected, a FileType parameter in an uploadParameter parameter is used as a type parameter of a terminal uploading file interface, the file content performs base64 coding on a byte array according to the sequence of Timestamp + CanId + Cancontent L ength + Cancontent (for example, 016439C7D960018C080102030405060708,016439C7D960 is a Timestamp, 018C is CanId,08 is Cancontent length, and 0102030405060708 is the Can content), then writes the byte array into a text file, and finally uploads the text file after zip compression.

⑥ CAN matrix table configuration

And when the T-BOX is configured offline, the current vehicle type code is written. The model code will be synchronized to the NAD side as a parameter to synchronize with the TSP server. And after the Tbox obtains the vehicle type parameters, merging the basic CAN matrix table and the CAN matrix table special for the vehicle type. I.e., the NAD of the T-BOX, will store a CAN matrix table as shown in fig. 9 to accommodate different vehicle models in the off-line configuration.

After receiving the vehicle type configuration code, the NAD executes the following operations to adapt to the current vehicle type and realize the analysis of the CAN message:

1) a big data module at the NAD side receives a vehicle type configuration code, such as a vehicle type 1;

2) searching a special matrix table of the vehicle type 1, namely a special matrix table of the vehicle type 1;

3) if the item ID in the exclusive matrix table of the vehicle type 1 conflicts with the item ID in the base CAN matrix table (namely, the items with the same ID exist), the items of the vehicle type 1 need to replace the corresponding items in the base CAN matrix table;

4) if the entry ID in the vehicle type 1 exclusive matrix table is not in the basic CAN matrix table, the entry of the vehicle type 1 needs to be added to the basic CAN matrix table.

After the execution is finished, the NAD side analyzes the CAN message synchronized by the MCU only according to the basic CAN matrix table so as to analyze the signal in the message. In addition, if a new vehicle type needs to be added, a special matrix table of the new vehicle type needs to be added to the T-BOX during burning so as to adapt to the new vehicle type.

⑦ virtual CAN message protocol

The NAD big data module of Tbox needs to rely on the internal parameters of the system, such as GPS, signal strength, etc. additionally when running. In order to report the consistency of the protocol and the processing of big data conditions, the part of data is virtualized into a CAN message. Since the ID range of the CAN in the CAN standard frame is 0x0000 to 0x07FF, that is, 0x0800 to 0xFFFF is not used, the unused part may be used for the virtual CAN packet of the system, as shown in table 14 specifically:

table 14:

virtual CAN ID	Parameter(s)	Description of the invention
			0x0800	GPS data	Storing and transmitting GPS-related data
0x0801	Signal strength, run time, etc	Storing and transmitting system related data
			......	......	......

⑧ synchronization of vehicle type codes

After the vehicle is installed on a vehicle, writing data of the current vehicle, such as vehicle VIN codes, APN (access point name), vehicle type codes and the like, into an NAD (plug and play) side in an offline configuration (EO L) stage.

In this embodiment, the storage medium stores one or more computer-readable programs, and when the computer-readable programs are called and executed by one or more controllers, the steps of the vehicle data acquisition and uploading method capable of being remotely and dynamically configured as described in this embodiment can be implemented.

Claims

1. A whole vehicle data acquisition uploading method capable of being remotely and dynamically configured is characterized in that: and a white list filtering mechanism is adopted, configuration information issued by a TSP service provider is received through a built-in communication module, the MCU is used for controlling the triggering condition and the corresponding action of the CAN signal after the script is analyzed, and the data acquisition, data processing, storage and uploading of white list CAN messages are realized through a data processing module in the T-BOX.

2. The vehicle data collection and uploading method capable of being remotely and dynamically configured as claimed in claim 1, wherein after XM L script information issued by TSP facilitator is acquired, script data is converted into CAN white list information recognizable by the system through script parsing conversion, and MCU configures trigger conditions and actions of corresponding CAN signals.

3. The vehicle data acquisition and uploading method capable of being remotely and dynamically configured according to claim 2, characterized in that: and after the MCU acquires the CAN white list information, feeding the CAN white list information back to the NAD side, acquiring each signal position in the CAN signal of the vehicle body by the NAD according to the DBC text of the vehicle type, and corresponding each signal position to the CAN in the white list configuration information fed back by the MCU one by one to complete the matching of the TSP configuration information and the CAN signal of the vehicle body.

4. The vehicle data acquisition and uploading method capable of being remotely and dynamically configured according to claim 3, characterized in that: when CAN signals in a CAN white list in a CAN network change, the CAN transceiver module collects the changed CAN signals.

5. The vehicle data acquisition and uploading method capable of being remotely and dynamically configured according to claim 4, characterized in that: when the collected CAN signals are subjected to data processing, the collected CAN signals are subjected to combinational logic judgment, and after the preset logic combination is met, corresponding events are triggered to carry out packet uploading of corresponding data; the trigger event comprises parameter uploading, operation of the parameters and historical data uploading.

6. The vehicle data acquisition and uploading method capable of being remotely and dynamically configured according to claim 5, characterized in that: acquiring the reporting logic of the current configuration script according to other items analyzed in the configuration flow, and uploading data in real time when the uploading mode is immediate uploading; when the uploading mode is the regular storage uploading, the data is written into the sending buffer area firstly, and then the compression uploading is carried out.

7. A storage medium, characterized by: one or more computer readable programs are stored, and when the computer readable programs are called and executed by one or more controllers, the steps of the remote dynamically configurable finished automobile data acquisition and uploading method according to any one of claims 1 to 6 can be realized.