Event data reporting method and device and computer readable storage medium

Abstract

The invention provides an event data reporting method and device and a computer readable storage medium, and designs a uniformly formatted basic event data reporting protocol. The target event reporting protocol corresponding to the target event is constructed through the event reporting protocol generation method and the event configuration parameters of the target event, so that the protocol development efficiency is improved. In the event data reporting process, can data associated with the target event and sent by the in-vehicle controller are received; and analyzing the can data based on an independently developed target event reporting protocol, and reporting the can data to the cloud platform server when a target event triggering condition is met to realize event data reporting.

Description

Technical Field

[0001] The present application relates to the field of vehicle communication technology, and in particular to an event data reporting method, device and computer-readable storage medium. Background Art

[0002] With the continuous development of Internet of Vehicles technology, automobile manufacturers have an increasingly prominent need to accurately monitor and deeply analyze the event data generated by vehicles. These data may include vehicle speed, location, sensor data, vehicle status, etc., which is of great significance for vehicle big data management and problem review.

[0003] However, the current event data reporting mechanism has many problems. For example, the length of different event messages is inconsistent, and a separate protocol needs to be developed for each event. Especially for some specific events, such as component failure, ADAS events, driver status monitoring, sudden acceleration and braking, etc., it is necessary to report and process the event data generated by vehicle driving at the millisecond level. However, for each new event triggering data reporting, an independent development protocol is added, which not only consumes a lot of time and energy, but also is not universal among different models. In addition, the development of the protocol for each event requires a long cycle because it involves many business modules, which undoubtedly increases the communication cost. This inefficient working mode seriously hinders the rapid development of Internet of Vehicles technology in vehicle event data reporting and processing, and cannot meet the urgent needs of automobile manufacturers for efficient, accurate and universal vehicle event data monitoring and analysis.

[0004] Therefore, how to solve the above-mentioned technical problems and build an efficient, universal and adaptable vehicle event data reporting system has become a key challenge faced by OEMs in expanding the Internet of Vehicles based on millisecond-level data reporting. Summary of the invention

[0005] To overcome the problems existing in the related art, this specification provides an event data reporting method, device and computer-readable storage medium.

[0006] According to a first aspect of an embodiment of this specification, a method for reporting event data is provided, the method being applied to a telematics control unit T-Box, the method comprising:

[0007] Receive CAN data associated with the target event sent by the in-vehicle controller;

[0008] Parsing the CAN data based on a target event reporting protocol, and reporting the CAN data to a server for vehicle analysis when a target event triggering condition is met;

[0009] The target event reporting protocol is obtained by an event reporting protocol generation method, and the event reporting protocol generation method includes:

[0010] Receiving a collection task instruction issued by a server, wherein the collection task instruction includes event configuration parameters of a target event;

[0011] A target event reporting protocol is generated based on the event configuration parameters and a basic event data reporting protocol, wherein the message type of the basic event data reporting protocol corresponds to a ms-level data collection task.

[0012] According to an event data reporting method provided by the present application, the ms-level data collection includes ms-level canid extended data configuration and ms-level canid extended data transmission, and each message type has an independent definition file.

[0013] According to an event data reporting method provided by the present application, the MS-level CANID extended data configuration includes a CANID filter configuration structure and a CAN bus configuration, wherein the data item for event reporting is set in the CAN bus configuration, and when the event reporting field exists in the CAN data, it indicates that the CAN data is data reported when the target event is triggered;

[0014] The canid filter configuration structure is provided with a can identifier list including multiple groups of can channels and canids. When the transmission channel of the can data matches the can identifier list, it indicates that the can data is set to be reported periodically.

[0015] According to an event data reporting method provided by the present application, the data items of the event report include information on the event trigger condition set and the event reporting type;

[0016] The event reporting type includes a first type of data when the event is triggered and a second type of data within a set range before and after the event is triggered;

[0017] Among them, in the second type, the time parameter of data reporting is configured according to the event configuration parameter to determine the setting range.

[0018] According to an event data reporting method provided by the present application, the event trigger condition set includes multiple event trigger conditions;

[0019] When the CAN data satisfies at least one of the event triggering conditions, the target event is triggered, and the CAN data associated with the target event is reported to the server for vehicle analysis.

[0020] According to an event data reporting method provided by the present application, the configuration of the event triggering condition also includes attribute information of the event signal and condition information of the triggering operation;

[0021] The CAN data is parsed based on the target event reporting protocol, and the CAN data is reported to the server for vehicle analysis when the target event triggering condition is met, including:

[0022] Parsing the CAN data based on the attribute information of the event signal to obtain a signal value;

[0023] When the signal value satisfies the condition information of the trigger operation, it indicates that the target event is triggered, and the CAN data is reported to the server for vehicle analysis.

[0024] According to an event data reporting method provided by the present application, the ms-level canid extended data configuration also includes a T-Box instruction response configuration, and the T-Box instruction response configuration includes a data type configuration, an action configuration, and a result configuration. After the target event reporting protocol is generated based on the event configuration parameters and the basic event data reporting protocol, the result of the millisecond-level instruction response is fed back to the server;

[0025] The result of setting the command response is stored based on a second-level bus data structure.

[0026] According to an event data reporting method provided by the present application, the method further includes:

[0027] Receiving the query task instruction issued by the server;

[0028] The local tasks of the T-Box are queried based on the query task instruction, and when the collection task of the target event is queried, the task information corresponding to the target event is uploaded.

[0029] According to an event data reporting method provided by the present application, when a target event triggering condition is met, the CAN data is reported to a server for vehicle analysis, including:

[0030] When the target event triggering condition is met, the CAN data is compressed using zlib and reported to the server for vehicle analysis.

[0031] The present application also provides an event data reporting device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the event data reporting method described above is implemented.

[0032] The present application also provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the event data reporting method as described in any one of the above is implemented.

[0033] The event data reporting method, device and computer-readable storage medium in the embodiments of this specification design a unified formatted basic event data reporting protocol. When monitoring the data of the target event, the target event reporting protocol corresponding to the target event is constructed through the event reporting protocol generation method and the event configuration parameters of the target event, thereby improving the efficiency of protocol development. In the event data reporting process, the CAN data associated with the target event sent by the in-vehicle controller is received; the CAN data is parsed based on the independently developed target event reporting protocol, and the CAN data is reported to the server when the target event triggering condition is met to realize event data reporting. Among them, the message types of the basic event data reporting protocol include MS-level CANID extended data configuration and MS-level CANID extended data transmission. Each message type has an independent definition file, which further ensures that the CAN data of the target event generated by the vehicle driving is reported and processed at the millisecond level, meeting the urgent needs of automobile manufacturers for efficient, accurate and universal vehicle event data monitoring and analysis.

[0034] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present specification. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the specification and, together with the description, serve to explain the principles of the specification.

[0036] Figure 1 is a schematic diagram of a ms-level event data reporting function according to an exemplary embodiment of this specification;

[0037] Figure 2 It is a main structure diagram of an event data reporting protocol according to an exemplary embodiment of this specification;

[0038] Figure 3 is a flow chart of a method for reporting event data according to an exemplary embodiment of the present specification;

[0039] Figure 4 is a schematic diagram of an event data reporting device according to an exemplary embodiment of the present specification;

[0040] Figure 5 It is a schematic block diagram of an event data reporting device shown in this specification according to an exemplary embodiment. DETAILED DESCRIPTION

[0041] Here, the technical solutions in the embodiments (or "implementations") of the present application will be described clearly and completely in conjunction with the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements.

[0042] If there are terms involving directional indications or positional relationships in the embodiments of the present application (such as up, down, left, right, front, back, inside, outside, top, bottom, center, vertical, horizontal, longitudinal, transverse, length, width, counterclockwise, clockwise, axial, radial, circumferential, etc.), such terms are only used to explain the relative positional relationship, movement, etc. between the components under a certain specific posture (as shown in the accompanying drawings); if the specific posture changes, the directional indication or positional relationship will also change accordingly. In addition, the terms "first", "second", etc. involved in the embodiments of the present application are only used for the purpose of convenience of description and cannot be understood as indicating or implying relative importance.

[0043] The present application provides an event data reporting method, device and computer readable storage medium. The present application is described in detail below in conjunction with the accompanying drawings. In the absence of conflict, the features of the following embodiments and implementations can be combined with each other.

[0044] With the continuous development of Internet of Vehicles technology, automobile manufacturers are increasingly in need of monitoring and analyzing the event data generated by vehicles. Due to the inconsistency of the length of different event messages, a separate protocol needs to be formulated for each event, especially for some specific events, such as component failure, ADAS events, driver status monitoring, sudden acceleration and braking, etc., it is necessary to report and process the event data generated by vehicle driving at the millisecond level. These data may include the vehicle's speed, location, sensor data, vehicle status, etc., which is of great significance for vehicle big data management and problem review.

[0045] The current OEM vehicle networking is based on millisecond-level data reporting to expand event data reporting. The technical problem that needs to be solved is that each new event triggers data reporting and needs to add a new protocol, which is time-consuming and labor-intensive, and is not universal among different models. The details are as follows:

[0046] Poor applicability: Each event needs to develop a protocol independently; the triggering mode, data, and acquisition cycle of the triggering event cannot be adjusted dynamically; the data cycle before and after the trigger cannot be adjusted; the protocol format is not unified;

[0047] Low efficiency: The development cycle of each event protocol is long; there are many business modules involved and the communication cost is high.

[0048] In order to solve the above technical problems, this specification provides an event data reporting protocol.

[0049] By designing a unified protocol format for all events, business needs only require event information and parameters to be configured and used, thereby realizing the development of a reporting protocol for any event, making the vehicle model protocol platform-based and improving its applicability. At the same time, only one development cycle is required to meet the use of subsequent vehicle models without the need for secondary development, improving the efficiency of event reporting, and thus better meeting the requirements of OEMs for real-time and accuracy of event data.

[0050] In the vehicle network system, the data reporting of the target event is realized through the interaction between the server, the T-Box in the vehicle and the in-vehicle controller. Among them, the server can be a cloud platform server, an enterprise-owned server or other types of servers specially built for the Internet of Vehicles service. Since the cloud platform server has powerful computing and storage capabilities and can handle a large amount of data and complex business logic, it is preferred to select a cloud platform server, which is used to receive the data transmitted by the T-Box, and analyze, store, remotely control and monitor the data provided. T-Box (Telematics Box) is also called a telematics control unit, which can realize communication and data exchange between vehicles, vehicles and infrastructure, and vehicles and the Internet by connecting the on-board CAN bus and the external cloud platform. The in-vehicle controller refers to an electronic control unit installed inside the vehicle, which is responsible for managing and controlling various systems and functions of the vehicle, such as the engine management system, air conditioning control, and in-vehicle entertainment system. In the vehicle network system, the in-vehicle controller communicates with the cloud platform server through the T-Box or directly, provides data feedback on the internal status of the vehicle, and may receive remote commands from the cloud to adjust the internal functions of the vehicle. The cloud platform server, the T-Box in the vehicle, and the in-vehicle controller described in this article are the same as the devices on the market and achieve the same functions. No specific limitations are made on the specific structure here.

[0051] The target event described in this article usually refers to a predefined specific situation or state that needs to be monitored or processed, such as abnormal vehicle driving, accidents, maintenance reminders, etc. When the target event is triggered, the relevant data when the target event occurs is sent to the cloud platform server for analysis, recording, alarm or subsequent processing and decision-making, thereby completing the complete event data reporting process.

[0052] like Figure 1 As shown, the process of configuring a unified platform-based basic event data reporting protocol includes: the process of issuing collection tasks between the cloud platform and T-Box, the process of uploading T-Box data, and the process of T-Box querying collection tasks.

[0053] The transmission rules between the cloud platform and the T-Box are standardized and configured, and the transmission protocol used between the cloud platform server and the T-Box in the vehicle is set to MQTT3.1 to achieve efficient and low-bandwidth communication. The serialization protocol uses Google's Protocol Buffer v2.6, which is used in large-scale data exchange scenarios. Protocol Buffer can effectively compress and optimize data transmission. In order for the cloud platform to accurately identify and distinguish events of different vehicles, when each vehicle's T-Box connects to the platform, the clientId of the MQTT protocol is set to the manufacturer + vehicle VIN code. The clientId example is: GXX_LSVFA49J232037048.

[0054] Configure the data type to be transmitted, that is, the data type adopts the type defined by Protocol Buffer.

[0055] Furthermore, the overall structure of the basic event data reporting protocol is designed.

[0056] like Figure 2 As shown, Figure 2 The hierarchical nested structure diagram of the basic event data reporting protocol, the main communication protocol is used to define the transmission and processing methods of different types of events. The main protocol contains the following information: login data (Login), heartbeat data (HeartBeat), remote diagnostic data (DiagOdx), where login data refers to the data generated and transmitted when a user or device logs into the system, which may include authentication information such as user name and password; heartbeat data is a signal sent periodically to indicate that the system or device is still in normal operation and connection; remote diagnostic data is used to perform remote fault diagnosis and analysis on the device or system. Each type of information, such as login data, heartbeat data, and remote diagnostic data, is set with an independent Protocol Buffers format definition file, such as a proto file.

[0057] At the same time, the protocol also includes the configuration of the message type of the basic event data reporting protocol corresponding to the ms-level data collection task, that is, the configuration of the ms-level canid extended data configuration (CanExtendCfgMs) and the ms-level canid extended data transmission (CanExtendTsmMs), both of which also have separate Protocol Buffers format definition files (such as proto files). This means that the entire system has clear classification specifications for data transmission and processing, and different types of data have special definitions and processing methods to ensure data accuracy, efficiency and orderliness. Especially for millisecond-level canid extended data configuration and transmission, a separate proto file can accurately define its related data structure and transmission rules to meet data processing requirements with high time accuracy.

[0058] Continue to combine Figure 3 Note: In main, in order to ensure the uniqueness and orderliness of sequenceId and facilitate accurate tracking and management of data and operations, the sequenceId on the T-Box side and the sequenceId on the cloud platform side are standardized.

[0059] Specifically, the T-Box side sequenceId generation rule is: it is composed of a 13-digit timestamp accurate to milliseconds + a 6-digit self-incrementing sequence number starting from zero every millisecond.

[0060] The platform-side sequenceId generation rule is: it is composed of a 13-digit timestamp accurate to milliseconds + a 3-digit machine number + a 3-digit self-incrementing serial number starting from zero every millisecond.

[0061] The accuracy and consistency of data during data transmission are further standardized as shown in Table 1 below:

[0062] Table 1:

[0063]

[0064] For example, suppose there is a "Vehicle Identification Number" table, in which there is a field named "vin", the data type is "string", the field modifier is "do not allow null", and the maximum length is "20". This means that in this table, the "vin" field must have a value (do not allow null), and the stored user name length cannot exceed 20 characters.

[0065] Further specifications for TransmitData (transmitted data) are shown in Table 2 below:

[0066] Table 2:

[0067] Serial number Field Name Data Types Field Modifiers describe 1 type TransDataType required Transmission data type 2 data bytes required Specific data transmitted

[0068] Further specifications for TransDataType (the class of the transmitted data) are shown in Table 3 below:

[0069] Table 3:

[0070] TransDataType Name Value direction describe Login 1 Up Login data HeartBeat 2 Up Heartbeat data DiagOdx 3 Up and down Based on ODX remote diagnostic data CanExtendCfgMs 4 Up and down Ms-level Canid extended data configuration CanExtendTsmMs 5 Up Ms-level Canid extended data transmission

[0071] Further specifications for CanExtendMs (can extension configuration in milliseconds) are shown in Table 4 below:

[0072] Table 4:

[0073]

[0074]

[0075] In combination with Table 4 above, it can be seen that the MS-level CANID extended data configuration includes a canConfig data item, which is used to describe the CANID filter configuration structure and the CAN bus configuration, wherein the data item for event reporting is set in the CAN bus configuration. When the event reporting field exists in the CAN data, it represents that the CAN data is the data reported when the target event is triggered; the CANID filter configuration structure is set with a CAN identifier list containing multiple groups of CAN channels and CANIDs. When the transmission channel of the CAN data matches the CAN identifier list, it represents that the CAN data is the set periodically reported data.

[0076] Further specifications for ActionType are shown in Table 5 below:

[0077] Table 5:

[0078] name Value direction describe Set 1 / set up SetReturn 2 / Set up reply Query 3 / Query QueryReturn 4 / Inquiry Response

[0079] In this specification, different types of operations or behaviors are identified by ActionType. Corresponding operation types (Set, SetReturn, Query, QueryReturn) are provided for different operation requirements (setting, query) of the system. This classification helps to standardize and understand the nature and expected results of various operations in the system.

[0080] Canconfig (can bus configuration) is further standardized, as shown in Table 6:

[0081] Table 6:

[0082]

[0083] It can be understood that EventUpload means uploading specific event-related information, and the field modifier "optional" means that the field is optional, that is, the field may or may not exist. For example, when the EventUpload field exists in the data, it means that the current data is reported by event triggering, rather than reporting according to a fixed period.

[0084] For example, in a vehicle monitoring system, if a vehicle collision is detected, the "EventUpload" field exists and the collision-related data will be uploaded instead of periodically uploading at fixed time intervals (such as every 5 minutes).

[0085] CanIdList (can identifier list) is further standardized, as shown in Table 7:

[0086] Table 7:

[0087] Serial number name Data Types Field Modifiers describe 1 Canid Fixed Required canid 2 Channel Int32 Required Can channel

[0088] It can be understood that Required means that the "Channel" field is required and must exist and have a value in the related data record.

[0089] For example, in a car's CAN bus communication data record, the value of the "Channel" field (such as 1, 2, etc.) is used to specify which specific CAN channel is communicating or transmitting data.

[0090] Furthermore, in the CAN bus data processing of the car, the value of the "Canid" field is used to accurately identify and distinguish different CAN messages or data frames. When the transmission channel of the CAN data matches the CAN identifier list, it indicates that the CAN data is the set periodically reported data.

[0091] Further standardize EventUpload (event reporting), as shown in Table 8:

[0092] Table 8:

[0093]

[0094] The data items of the event report include a set of event trigger conditions and information on the event reporting type; among them, for the eventTriggers data field, this field can appear repeatedly in the data, that is, it can have multiple values ​​or multiple sub-items. As long as one event trigger condition is met, the event can be triggered to perform data reporting operations.

[0095] The eventUploadType event reporting type includes the first type when eventUploadType==0, which means that when the event is triggered, the reported data includes the data at the event triggering time.

[0096] The eventUploadType event reporting type also includes a second type when eventUploadType==1, which means that when the event is triggered, the reported data includes data within a set range before and after the event is triggered.

[0097] Furthermore, the data within a set range before and after the reporting event is triggered can be determined by the time parameter of the data reporting.

[0098] Specifically, for the uploadTimeBefore data field, this field is optional and does not necessarily have a value. When the value of "eventUploadType" is 1, this field is used to store the time value that needs to be reported before the trigger. For example, if the value of "eventUploadType" is 1 and the value of "uploadTimeBefore" is 60, it means that the data 60 milliseconds before the event is triggered needs to be reported.

[0099] Further specification of EventTriggers (event trigger conditions) is shown in Table 9:

[0100] Table 9:

[0101]

[0102] EventTriggers are used to define the conditions or factors that trigger an event. When adding an event trigger data, the trigger condition of the event is determined through the event configuration parameters of the event, and a separate data reporting protocol is quickly developed for the event.

[0103] Furthermore, the configuration of the event triggering condition also includes the attribute information of the event signal and the condition information of the triggering operation; as shown in Table 10:

[0104] Table 10:

[0105]

[0106]

[0107] Among them, the first 7 items in Table 10 are the attribute information of the event signal. The CAN bus can parse the signal value when it receives the corresponding CANID message. The last 2 items are the condition information of the event trigger operation. When the signal value meets the condition, it means that the event is triggered.

[0108] The ActionResult is further standardized as shown in Table 11:

[0109] Table 11:

[0110] DiagPolicy name Data Types Field Modifiers describe 1 canDataS CanDataS repeated Second-level bus data structure

[0111] The ms-level canid extended data configuration also includes the T-Box command response configuration, which includes the data type configuration. It can be understood that after the cloud platform issues the acquisition task command, the T-Box needs to respond to the command and feedback the result after the task is executed, and then the data structure of the structure is standardized, that is, the bus data structure in seconds. For example, in the operation result of a vehicle communication system, "ActionResult" may contain multiple "canDataS" fields, each of which records the bus data situation within one second.

[0112] For the CAN bus communication between T-Box and the in-vehicle controller, the CanDataModel (CAN data structure) is further standardized, as shown in Table 12:

[0113] Table 12:

[0114] Serial number name Data Types Field Modifiers describe 1 canDataS CanDataS repeated Second-level bus data structure

[0115] Indicates that the data structure "CanDataModel" contains a data element named "canDataS", whose data type is specific and repeatable, and is used to represent the second-level bus data structure. For example, in a can bus data structure, there may be multiple "canDataS" elements, which record the second-level bus data at different times or parts.

[0116] Among them, further specifications for CanDataS are shown in Table 13:

[0117] Table 13:

[0118]

[0119] Through the above configuration of the basic event data reporting protocol, the corresponding functions are implemented in the basic event data reporting protocol of this article. For example, the platform side to T-Box command issuance, T-Box to platform side command response, T-Box to platform side ms-level data transmission function. It should be noted that for all protocols of the above functions, the MQTT protocol is adopted, and clientId recommends using vin as the unique identifier. The topic topic_diag corresponding to the specific function is defined in the detailed description of the following chapters, which includes the wildcard topic topic subscribed by T-Bbox. In other words, through the above content, the basic framework and rules are set for the communication of related functions, including the protocol used, the way of client identification, and the definition and scope of the topic.

[0120] Furthermore, the corresponding functions of issuing collection tasks, reporting data, and querying collection tasks are realized through three specific topics.

[0121] In some embodiments, in combination Figure 1 As shown in Table 14, the process of issuing collection tasks regulates the message carrier issued by the cloud platform:

[0122] Table 14:

[0123]

[0124]

[0125] Furthermore, the ms-level canid extended data configuration also includes a T-Box command response configuration, and the T-Box command response configuration includes a data type configuration, an action configuration and a result configuration. After the target event reporting protocol is generated based on the event configuration parameters and the basic event data reporting protocol, the result of the millisecond-level command response is fed back to the cloud platform server; wherein, the result of the command response is set to be stored based on a second-level bus data structure.

[0126] T-Box command response configuration also includes action configuration and result configuration, as shown in Table 15:

[0127] Table 15:

[0128] Data Item value Field Modifiers illustrate mainPb.transmitData.type CanExtendCfgMs required The data type is ms data configuration canExtendMs.actionType SetReturn required The ms data configuration action is set to return canExtendMs.actionResult xx optional ms data configuration results

[0129] Through the definition of the above topics and the specification of the corresponding task data structure, the protocol of this article provides the following command functions:

[0130] Set the upload cycle to determine the time interval for uploading data from the T-Box to the cloud platform;

[0131] Set the acquisition cycle channel to determine the time interval for data acquisition of different CAN channels;

[0132] Set event trigger conditions (eventTriggers) to define the conditions that cause the target event to occur;

[0133] Set the collection method (event reporting type) after the event is triggered to determine how the data is collected and reported after the event is triggered;

[0134] Set the canid list required to be collected in a specific collection cycle channel, which is used to specify the list of can identifiers (canid) that need to be collected in each collection cycle channel;

[0135] Collect data according to the set collection cycle and canid filter list, and actually obtain data according to the set collection cycle and canid filter list.

[0136] Through the above settings and operations related to data collection, uploading and event triggering, it is ensured that data can be effectively acquired and processed according to specific requirements and rules.

[0137] It should be noted that the following points should be noted when designing the collection task in the basic event data reporting protocol:

[0138] 1. Consumption speed > production speed, that is, upload speed > collection speed, which means that the data upload rate is faster than the collection rate.

[0139] 2. Currently, the maximum number of messages that can be uploaded at one time is 200. A maximum of 200 messages can be configured to be collected in one upload cycle.

[0140] 3. (canid_cnt_1 / sampleCycleMs_1+.....+canid_cnt_n / sampleCycleMs_n)*1000*uploadCycleS<=200, used to constrain the relationship between collection and upload. Among them, canid_cnt represents the number of different canids, sampleCycleMs represents the corresponding collection cycle (milliseconds), and uploadCycleS represents the upload cycle (seconds). In other words, considering the collection frequency and upload cycle of various canids, the calculated result cannot exceed 200.

[0141] 4. Due to terminal resource reasons, the list cannot be configured without limit. The current maximum is 200 items.

[0142] 5. Canid_cnt_1+…+canid_cnt_n<=200, that is, the total number of all canids does not exceed 200.

[0143] In summary, various quantity and rate limits are set during data collection and uploading to adapt to the requirements of terminal resources and system performance.

[0144] In some embodiments, in combination Figure 1 As shown in Table 16, the process of querying the collection task standardizes the message carrier sent by the cloud platform:

[0145] Table 16:

[0146] Data Item value Field Modifiers illustrate mainPb.transmitData.type CanExtendCfgMs required The data type is ms data configuration canExtendMs.actionType Query required The ms data configuration action is query

[0147] The T-Box response is standardized as shown in Table 17:

[0148] Table 17:

[0149]

[0150] Through the definition of the above topics and the specification of the corresponding task data structure, the protocol of this article provides the following command functions:

[0151] Query the upload cycle to determine the time interval setting value for data upload;

[0152] Query the collection cycle to determine the time interval for data collection;

[0153] Query the trigger conditions of an event to clarify the specific conditions that lead to the occurrence of a specific event;

[0154] Query the collection method of event-triggered data to determine how data is collected after the event is triggered;

[0155] The signals required to be collected in a specific collection cycle are queried to determine which specific data signals should be collected in a specific collection cycle.

[0156] Querying the collection task is a follow-up task to issuing the collection task. After setting the issuing collection task so that the corresponding collection task is configured in the system, you can query the collection task in the local T-Box through querying the collection task to report the task information.

[0157] In some embodiments, the event data reporting method includes: querying the local tasks of the T-Box based on the query task instruction, and when the collection task of the target event is queried, uploading the task information corresponding to the target event.

[0158] It should be noted that the following points should be noted when designing the query collection task in the basic event data reporting protocol:

[0159] 1. If you have not set up a collection task, when you receive a query command, the fill value in the response (indicated by xx) will all be filled with the default value. That is to say, if you have never set up a collection task before, when you receive a command to query collection-related information (such as collection cycle, collection signal, etc.), in the returned response content, for those places that need to be filled with data (indicated by "xx"), all pre-set default values ​​must be filled.

[0160] For example, the default collection period may be 60 seconds. If no collection task has been set, the collection period in the query response will be displayed as 60 seconds. This is done to provide a meaningful and predictable result without specific settings, avoiding null values ​​or errors.

[0161] In some embodiments, in combination Figure 1 As shown in Table 18, the data upload process regulates the T-Box reporting to the cloud:

[0162] Table 18:

[0163]

[0164]

[0165] Through the definition of the above topics and the specification of the corresponding task data structure, the protocol of this article provides the following command functions:

[0166] Reporting an event and the data required to be reported when the event occurs, that is, when an event occurs and the event meets the pre-set conditions for reporting, the data related to the event should be reported;

[0167] Reporting no events and meeting the filtering conditions, that is, when no events occur, but the current data meets the set filtering conditions, data must also be reported.

[0168] The above two functions are used to realize event-triggered reporting and periodic reporting of data.

[0169] It should be noted that the following points should be noted in the design process of data upload in the basic event data reporting protocol:

[0170] 1. Due to some reasons, the data cannot be sent and needs to be stored in the local ROM for storage, which can at least save 200*3600*12*7=60.48 million message data; ensure that the data will not be lost, and after the reason is solved, send the stored data in time to ensure the integrity of the data;

[0171] 2. The data collected first will be sent first; ensuring the timeliness and order of the data;

[0172] 3. mainPb.transmitData.data is compressed with zlib. A segment of actual message data is tested. 100 messages are 1500 bytes long, which is 667 bytes after zlib compression.

[0173] 4. If there is data in the local ROM, the sending frequency needs to be increased and the sending cycle can be shortened to 1 / 2.

[0174] Through the above limitations, the data can be sent, stored, compressed normally, and the sending strategy can be implemented when there is local storage data, so as to ensure the integrity, timeliness and efficient transmission of the data.

[0175] Based on the above embodiments, the construction of the basic event data reporting protocol is realized. The basic event data reporting protocol provides a unified protocol format for the collection task and can be used on any vehicle model. Compared with the existing method of adding an independent development protocol for each new event trigger data report, which consumes a lot of time and effort and is not universal among different vehicle models, the event data reporting protocol in this article has the following advantages:

[0176] 1) Platform-based: The present invention can be used on any vehicle model, and only requires configuration of corresponding matrix signals and related parameters.

[0177] 2) Strong applicability: The thresholds for event triggering in the present invention can be adjusted dynamically, and the triggering events, the time before and after the events, the CAN channel, the reporting cycle, etc. can all be adjusted at will, which greatly increases the applicability and can meet the event data requirements of all vehicle services.

[0178] 3) High efficiency: The present invention only needs one development cycle to meet the needs of subsequent use among various vehicle models without the need for secondary development. And for each new event, business needs only need to provide event information and parameters for configuration and use, shortening the development cycle of the event data reporting protocol.

[0179] 4) Practicality and feasibility: It can effectively solve technical problems in vehicle network data transmission, improve the practicality and feasibility of the entire system, and better meet the requirements of OEMs for real-time and accuracy of event data.

[0180] Based on the basic event data reporting protocol designed above, an event data reporting method is proposed. Figure 3 This is a flow chart of an event data reporting method provided by an embodiment of this specification, comprising the following steps:

[0181] S100: receiving CAN data associated with a target event sent by an in-vehicle controller.

[0182] CAN data transmitted by the in-vehicle controller is received via the CAN bus, and the CAN data is related to the target time to be reported.

[0183] S200, parsing the CAN data based on a target event reporting protocol, and reporting the CAN data to the cloud platform server for vehicle analysis when a target event triggering condition is met.

[0184] In this embodiment, the target event reporting protocol is obtained by an event reporting protocol generation method, and the event reporting protocol generation method includes:

[0185] S210: Receive a collection task instruction issued by a cloud platform server, where the collection task instruction includes event configuration parameters of a target event.

[0186] A collection task instruction sent by a cloud platform server is received, wherein the collection task instruction includes event configuration parameters of a target event.

[0187] When it is necessary to monitor and analyze the data of certain specific events in the vehicle, the cloud platform server will issue a collection task instruction to collect the data of the target event. If the corresponding task is not saved in the vehicle's T-Box, it is necessary to configure the collection task of the target event. In this process, it is necessary to obtain the event configuration parameters corresponding to the target event.

[0188] As an example, specific events include component failure, ADAS events, driver status monitoring, sudden acceleration and braking, etc.

[0189] S220. Generate a target event reporting protocol based on the event configuration parameters and the basic event data reporting protocol. The message types of the basic event data reporting protocol include ms-level canid extended data configuration and ms-level canid extended data transmission. Each message type has an independent definition file.

[0190] When receiving the collection task instruction issued by the cloud platform server, a separate protocol, namely the target event reporting protocol, is formulated for the target time according to the event configuration parameters of the target event in the collection task instruction and the basic event data reporting protocol designed in the above embodiment.

[0191] In this embodiment, based on the target event reporting protocol, whether the CAN data signal associated with the target event meets the event trigger condition, the event trigger condition set includes multiple event trigger conditions. When the CAN data meets at least one of the event trigger conditions, the target event is triggered, and the CAN data associated with the target event is reported to the cloud platform server for vehicle analysis.

[0192] Further, the CAN data is parsed based on the target event reporting protocol, and the CAN data is reported to the cloud platform server for vehicle analysis when the target event triggering condition is met, including:

[0193] Parsing the CAN data based on the attribute information of the event signal to obtain a signal value;

[0194] When the signal value meets the condition information of the trigger operation, it indicates that the target event is triggered, and the CAN data is reported to the cloud platform server for vehicle analysis.

[0195] The configuration of the event triggering condition also includes the attribute information of the event signal and the condition information of the triggering operation, such as the data items in Table 10 above.

[0196] In some embodiments, after the CAN data meets the target event trigger condition, the filtering collection channel needs to collect the CAN data. When the CAN channel sending the CAN data matches the canid and the collection channel in the CanIdList or exists in the CanIdList, the CAN data is reported to the cloud platform server for vehicle analysis.

[0197] In other embodiments, when the target event is not triggered, the can data associated with the target event is further analyzed to see whether it meets the set filtering conditions (such as data items in CanIdList). If so, the can data also needs to be reported.

[0198] In some embodiments, the event data reporting method includes: when the target event triggering condition is met, the CAN data is compressed using zlib and then reported to the cloud platform server for vehicle analysis. The compression effect is demonstrated through actual testing (100 messages are compressed from 1500 bytes to 667 bytes) to reduce the amount of data transmission and improve transmission efficiency.

[0199] Based on the above embodiment, the event data reporting method further includes:

[0200] S300, receiving a query task instruction issued by the cloud platform server;

[0201] S400: query the local tasks of the T-Box based on the query task instruction, and when the collection task of the target event is found, upload the task information corresponding to the target event.

[0202] T-Box queries the local task to see if there is a collection task for the target event corresponding to the query task instruction. If so, T-Box reports the task information to the cloud platform.

[0203] In this embodiment, the T-Box can respond to the query request of the cloud platform server and provide relevant information about the target event to achieve effective management and monitoring of vehicle events. This interactive method helps the cloud platform server to obtain relevant data of the vehicle in a timely manner, so as to make corresponding decisions and processing.

[0204] The present application provides an event data reporting method, device and computer-readable storage medium, designs a unified formatted basic event data reporting protocol, and when monitoring the data of the target event, constructs a target event reporting protocol corresponding to the target event through the event reporting protocol generation method and the event configuration parameters of the target event, thereby improving the efficiency of protocol development. In the event data reporting process, the CAN data associated with the target event sent by the in-vehicle controller is received; the CAN data is parsed based on the independently developed target event reporting protocol, and the CAN data is reported to the cloud platform server when the target event triggering condition is met, thereby realizing event data reporting. Among them, the message types of the basic event data reporting protocol include MS-level CANID extended data configuration and MS-level CANID extended data transmission, and each message type has an independent definition file, which further ensures that the CAN data of the target event generated by the vehicle driving is reported and processed at the millisecond level, meeting the urgent needs of automobile manufacturers for efficient, accurate and universal vehicle event data monitoring and analysis.

[0205] Based on the same application concept as the above method, the present application embodiment also proposes an event data reporting device, such as Figure 4 shown.

[0206] The device comprises:

[0207] The data receiving module 402 is used to receive the CAN data associated with the target event sent by the in-vehicle controller;

[0208] A data analysis module 404 is used to parse the CAN data based on a target event reporting protocol, and report the CAN data to the cloud platform server for vehicle analysis when a target event triggering condition is met;

[0209] The data query module 404 is also used to obtain the target event reporting protocol through an event reporting protocol generation method, and the event reporting protocol generation method includes: receiving a collection task instruction issued by a cloud platform server, and the collection task instruction includes event configuration parameters of the target event; generating a target event reporting protocol based on the event configuration parameters and a basic event data reporting protocol, and the message types of the basic event data reporting protocol include MS-level CANID extended data configuration and MS-level CANID extended data transmission, and each message type has an independent definition file.

[0210] The implementation process of the functions and effects of each module / submodule / unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and the same technical effect can be achieved, so it will not be repeated here.

[0211] Figure 5 The following is an example of a physical structure diagram of an event data reporting device, such as Figure 5 As shown, the event data reporting device may include: a processor 810, a communication interface 820, a memory 830 and a communication bus 840, wherein the processor 810, the communication interface 820 and the memory 830 communicate with each other through the communication bus 840. The processor 810 may call the logic instructions in the memory 830 to execute the event data reporting method.

[0212] In addition, the logic instructions in the above-mentioned memory 830 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when it is sold or used as an independent product. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art, and the computer software product is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0213] On the other hand, the present application also provides a computer program product, which includes a computer program. The computer program can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the event data reporting method provided by the above methods.

[0214] On the other hand, the present application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which is implemented when the computer program is executed by a processor to execute the event data reporting method provided by the above methods.

[0215] It should be noted that the technical solutions or technical features described in the above embodiments can be combined or supplemented with each other without causing conflicts. The scope of protection of this application is not limited to the precise structures described in the above embodiments and shown in the drawings; all modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this application should be included in the scope of protection of this application.

Claims

1. A method for reporting event data, characterized in that: The method is applied to a telematics control unit T-Box, and the method comprises: Receive CAN data associated with the target event sent by the in-vehicle controller; Parsing the CAN data based on a target event reporting protocol, and reporting the CAN data to a server for vehicle analysis when a target event triggering condition is met; The target event reporting protocol is obtained by an event reporting protocol generation method, and the event reporting protocol generation method includes: Receiving a collection task instruction issued by the server, wherein the collection task instruction includes event configuration parameters of a target event; A target event reporting protocol is generated based on the event configuration parameters and a basic event data reporting protocol, wherein the message type of the basic event data reporting protocol corresponds to a ms-level data collection task.

2. The event data reporting method according to claim 1, characterized in that: The ms-level data collection includes ms-level canid extended data configuration and ms-level canid extended data transmission, and each message type has an independent definition file.

3. The event data reporting method according to claim 1, characterized in that: The MS-level CANID extended data configuration includes a CANID filter configuration structure and a CAN bus configuration, wherein the CAN bus configuration sets a data item for event reporting, and when the event reporting field exists in the CAN data, it indicates that the CAN data is data reported when the target event is triggered; The canid filter configuration structure is provided with a can identifier list including multiple groups of can channels and canids. When the transmission channel of the can data matches the can identifier list, it indicates that the can data is set to be reported periodically.

4. The event data reporting method according to claim 3, characterized in that: The data items of the event report include information on the event triggering condition set and the event report type; The event reporting type includes a first type of data when the event is triggered and a second type of data within a set range before and after the event is triggered; Among them, in the second type, the time parameter of data reporting is configured according to the event configuration parameter to determine the setting range.

5. The event data reporting method according to claim 4, characterized in that: The event trigger condition set includes multiple event trigger conditions; When the CAN data satisfies at least one of the event triggering conditions, the target event is triggered, and the CAN data associated with the target event is reported to the server for vehicle analysis.

6. The event data reporting method according to claim 5, characterized in that: The configuration of the event triggering condition also includes the attribute information of the event signal and the condition information of the triggering operation; The CAN data is parsed based on the target event reporting protocol, and the CAN data is reported to the server for vehicle analysis when the target event triggering condition is met, including: Parsing the CAN data based on the attribute information of the event signal to obtain a signal value; When the signal value satisfies the condition information of the trigger operation, it indicates that the target event is triggered, and the CAN data is reported to the server for vehicle analysis.

7. The event data reporting method according to claim 2, characterized in that: The ms-level canid extended data configuration also includes a T-Box instruction response configuration, which includes a data type configuration, an action configuration, and a result configuration. After the target event reporting protocol is generated based on the event configuration parameters and the basic event data reporting protocol, the result of the millisecond-level instruction response is fed back to the server; The result of setting the command response is stored based on a second-level bus data structure.

8. The event data reporting method according to claim 1, characterized in that: The method further comprises: Receiving the query task instruction issued by the server; The local tasks of the T-Box are queried based on the query task instruction, and when the collection task of the target event is queried, the task information corresponding to the target event is uploaded.

9. The event data reporting method according to claim 1, characterized in that: The reporting of the CAN data to the server for vehicle analysis when the target event triggering condition is met includes: When the target event triggering condition is met, the CAN data is compressed using zlib and reported to the server for vehicle analysis.

10. An event data reporting device, characterized in that: It includes a memory, a processor, and an event data reporting program stored in the memory and executable on the processor. When the processor executes the event data reporting program, the steps of the event data reporting method according to any one of claims 1 to 9 are implemented.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores an event data reporting program, and when the event data reporting program is executed, the steps of the event data reporting method according to any one of claims 1 to 9 are implemented.

Images