Event data reporting method, device and computer readable storage medium

Abstract

The specification provides an event data reporting method, device and computer readable storage medium, a unified formatted basic event data reporting protocol is designed, when the data of a target event is monitored, a target event reporting protocol corresponding to the target event is constructed through an event reporting protocol generation method and event configuration parameters of the target event, and the protocol development efficiency is improved. Further, 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 trigger condition is met, and the event data reporting is realized.

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 conduct in-depth analysis of event data generated by vehicles. This 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 presents numerous issues, such as inconsistent message lengths for different events, necessitating a separate protocol for each event. This is particularly true for specific events, such as component failures, ADAS events, driver status monitoring, and sudden acceleration and braking, which require millisecond-level reporting and processing of vehicle event data. However, developing a separate protocol for each new event triggering data reporting consumes significant time and effort and is not universal across vehicle models. Furthermore, developing a protocol for each event requires a lengthy process due to the involvement of numerous business modules, which undoubtedly increases communication costs. This inefficient operating model severely hinders the rapid development of connected vehicle technology for vehicle event data reporting and processing, failing to meet the urgent needs of automakers for efficient, accurate, and universal vehicle event data monitoring and analysis.

[0004] Therefore, how to solve the above 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 target events sent by the in-vehicle controller;

[0008] Parsing the CAN data based on the target event reporting protocol and reporting the CAN data to the server for vehicle analysis when the 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] receive a collection task instruction issued by a server, the collection task instruction including event configuration parameters of a target event;

[0011] generate a target event reporting protocol based on the event configuration parameters and a basic event data reporting protocol, a message type of the basic event data reporting protocol corresponding to an ms-level data collection task.

[0012] According to the event data reporting method provided in the 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 the event data reporting method provided in the application, 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 can data includes the event reporting field, it indicates that the can data is data reported when the target event is triggered.

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

[0015] According to the event data reporting method provided in the application, the data item for event reporting includes an event trigger condition set and information of an event reporting type.

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

[0017] In the second type, a time parameter for data reporting is configured according to the event configuration parameters to determine the set range.

[0018] According to the event data reporting method provided in the application, the event trigger condition set includes multiple event trigger conditions.

[0019] 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 server for vehicle analysis.

[0020] According to the event data reporting method provided in the application, the configuration of the event trigger condition further includes attribute information of an event signal and condition information of a trigger operation.

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

[0022] The can data is parsed based on the attribute information of the event signal, and a signal value is obtained;

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

[0024] According to the event data reporting method provided by the application, the ms-level canid extension data configuration further includes T-Box instruction response configuration, the T-Box instruction response configuration includes data type configuration, action configuration and result configuration, after the target event reporting protocol is generated based on the event configuration parameter and the basic event data reporting protocol, the result of the millisecond-level instruction response is fed back to the server;

[0025] Among them, the result of the instruction response is stored based on the second-level bus data structure.

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

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

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

[0029] According to the event data reporting method provided by the application, the can data is reported to the server when the target event trigger condition is met, for vehicle analysis, including:

[0030] When the target event trigger condition is met, the can data is compressed by zlib and reported to the server for vehicle analysis.

[0031] The 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, and the processor executes the program to realize the event data reporting method as described above.

[0032] The application also provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to realize the event data reporting method as described above.

[0033] The event data reporting method, device and computer readable storage medium in the embodiments of the present specification design a unified formatted basic event data reporting protocol. When monitoring the data of a target event, a target event reporting protocol corresponding to the target event is constructed by an event reporting protocol generation method and event configuration parameters of the target event, thereby improving the protocol development efficiency. Then, 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, thereby realizing event data reporting. The message types of the basic event data reporting protocol include ms-level canid extension data configuration and ms-level canid extension 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, and meets the urgent needs of automobile manufacturers for efficient, accurate and universal vehicle event data monitoring and analysis.

[0034] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present specification. BRIEF DESCRIPTION OF DRAWINGS

[0035] The accompanying drawings incorporated in the specification and forming a part thereof illustrate embodiments consistent with the present specification and serve to explain the principles of the present specification together with the specification.

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

[0037] Figure 2 is a main structure schematic diagram in an event data reporting protocol according to an exemplary embodiment of the present specification;

[0038] Figure 3 is a flowchart of an event data reporting method 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 is a schematic block diagram of an event data reporting device according to an exemplary embodiment of the present specification. DETAILED DESCRIPTION

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

[0042] If the application embodiments involve directional indications or positional relationships (such as up, down, left, right, front, back, inner, outer, 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 in a certain posture (as shown in the drawings); if the posture changes, the directional indication or positional relationship will also change accordingly. In addition, the terms "first", "second", etc. in the application embodiments are only used for convenience of description, and cannot be understood as indicating or implying relative importance.

[0043] The application provides an event data reporting method and device and a computer readable storage medium. The application will be described in detail below in conjunction with the drawings. The features in the following embodiments and implementation modes can be combined with each other without conflict.

[0044] With the continuous development of Internet of Vehicles technology, automobile manufacturers need to monitor and analyze the event data generated by vehicles more and more. Because the lengths of different event messages are inconsistent, a separate protocol needs to be formulated for each event, especially for some specific events, such as component failure, ADAS event, driver state monitoring, sudden acceleration and sudden braking, etc. The event data generated by the vehicle needs to be reported and processed at the millisecond level. These data may include the speed, position, sensor data, and vehicle state of the vehicle, which are of great significance for the big data management and problem review of the vehicle.

[0045] The current host factory Internet of Vehicles needs to solve the technical problem of event data reporting based on millisecond-level data reporting expansion. Each newly added event trigger data reporting needs to add a new protocol, which is time-consuming and laborious, and is not universal among different vehicle models. Specifically as follows:

[0046] Poor applicability: including independent development of protocol for each event; the trigger event trigger mode, data, and collection period cannot be dynamically adjusted; the data period before and after the trigger cannot be adjusted; the protocol format is not unified;

[0047] Low efficiency: including long development period of each event protocol; involving multiple business modules, high communication cost.

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

[0049] By designing a unified protocol format for all events, the business requirements only need to provide event information and parameters for configuration and use, thereby realizing the development of the reporting protocol for any event, making the vehicle protocol platform, and improving its applicability. At the same time, only one development cycle is needed 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 real-time and accuracy requirements of the host factory for event data.

[0050] In the vehicle network system, the data reporting of the target event is realized through the interaction of the server, the T-Box in the vehicle, and the in-vehicle controller. The server can be a cloud platform server, an enterprise server, or other types of servers specially built for vehicle networking services. Since the cloud platform server has strong computing and storage capabilities, it can handle a large amount of data and complex business logic. Preferably, a cloud platform server is selected, which is used to receive data transmitted by the T-Box, analyze, store, remotely control, and monitor the provided data. The T-Box (Telematics Box) is also known as a remote information processing control unit, which can connect the vehicle CAN bus and the external cloud platform to realize communication and data exchange between vehicles, infrastructure, and the Internet. The in-vehicle controller is an electronic control unit installed in the vehicle, responsible for managing and controlling various systems and functions of the vehicle, such as engine management systems, air conditioning control, and vehicle entertainment systems. In the vehicle network system, the in-vehicle controller communicates with the cloud platform server through the T-Box or directly, providing data feedback of the vehicle's internal state, and may receive remote commands from the cloud to adjust the vehicle's internal functions. In this paper, the cloud platform server, T-Box in the vehicle, and in-vehicle controller are the same as the devices on the market, achieving the same function, and the specific structure is not limited here.

[0051] The target event described in this paper generally refers to a specific situation or state that needs to be monitored or handled in advance, such as abnormal driving of the vehicle, accidents, maintenance reminders, etc. When the target event is triggered, the relevant data at the time of the occurrence of the target event 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] As shown in Figure 1 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 the T-Box, the process of T-Box data upload, and the process of T-Box query collection tasks.

[0053] The transmission rules between the cloud platform and the T-Box are standardized and configured. MQTT 3.1 is used as the transmission protocol between the cloud platform server and the vehicle's T-Box, enabling efficient, low-bandwidth communication. Google's Protocol Buffer v2.6 is used as the serialization protocol. Protocol Buffer effectively compresses and optimizes data transmission in large-scale data exchange scenarios. To ensure the cloud platform can accurately identify and distinguish events from different vehicles, the MQTT client ID for each vehicle's T-Box when connecting to the platform is set to the manufacturer plus the vehicle's VIN. An example client ID 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 This diagram shows the hierarchical nested structure of the basic event data reporting protocol. The main communication protocol is used to define the transmission and processing methods for different types of events. The main protocol contains the following information: login data (Login), heartbeat data (HeartBeat), and remote diagnostic data (DiagOdx). 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 username and password; heartbeat data is a periodically sent signal used to indicate that the system or device is still operating normally and connected; remote diagnostic data is used for remote fault diagnosis and analysis of devices or systems. Each type of information, such as login data, heartbeat data, and remote diagnostic data, is provided with a separate Protocol Buffers format definition file, such as a proto file.

[0057] Meanwhile, 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 (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 in terms of data transmission and processing, and different types of data have dedicated definitions and processing methods to ensure data accuracy, efficiency, and order. In particular, for the ms-level canid extended data configuration and transmission, separate proto files can accurately define the relevant data structure and transmission rules to meet the high-precision data processing requirements.

[0058] Continue to combine Figure 3 It is explained that, in the main, in order to ensure the uniqueness and orderliness of the sequenceId, facilitate accurate tracking and management of data and operations, the sequenceId of the T-Box end and the sequenceId of the cloud platform end are specified.

[0059] Specifically, the T-Box end sequenceId generation rule: composed of a 13-bit timestamp accurate to milliseconds + a 6-bit self-incrementing serial number starting from zero within each millisecond.

[0060] The platform end sequenceId generation rule: composed of a 13-bit timestamp accurate to milliseconds + a 3-bit machine number + a 3-bit self-incrementing serial number starting from zero within each millisecond.

[0061] Further specification of data accuracy and consistency during data transmission, as shown in Table 1 below:

[0062] Table 1:

[0063]

[0064] For example, assume there is a "vehicle identification code" table with a field named "vin" and a data type of "string", with a field modifier of "not allowed to be empty" and a maximum length of "20". This means that in this table, the "vin" field must have a value (not allowed to be empty) and the length of the stored username cannot exceed 20 characters.

[0065] Further specification of TransmitData (transmitted data), as shown in Table 2 below:

[0066] Table 2:

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

[0068] Further specification of TransDataType (class of transmitted data) is shown in Table 3 as follows:

[0069] Table 3:

[0070] TransDataType name Value direction describe Login 1 Upward Login data HeartBeat 2 Upward 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 Upward Ms-level Canid extended data transmission

[0071] Further specification of CanExtendMs (can extension configuration in milliseconds) is shown in Table 4 as follows:

[0072] Table 4:

[0073]

[0074]

[0075] In combination with Table 4, it can be seen that the ms-level canid extension data configuration includes a canConfig data item for describing a canid filter configuration structure and a can bus configuration. The can bus configuration sets a data item for event reporting. 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 sets 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 indicates that the can data is periodically reported data.

[0076] Further specification of ActionType (action type) is shown in Table 5 as follows:

[0077] Table 5:

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

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

[0080] Further specification of Canconfig (can bus configuration) is shown in Table 6 as follows:

[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, i.e. the field can exist or not. For example, when the EventUpload field exists in the data, it means that the current data is reported by the event trigger, rather than being reported according to the fixed period.

[0084] For example, in a vehicle monitoring system, if the event of vehicle collision is detected, the collision related data will be uploaded when the "EventUpload" field exists, rather than being periodically uploaded according to a fixed time interval (such as every 5 minutes).

[0085] The CanIdList (CAN identifier list) is further specified as shown in Table 7:

[0086] Table 7:

[0087] Serial number name Data Type 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 CAN bus communication data record of a vehicle, 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] Further, in the CAN bus data processing of a vehicle, 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 means that the can data is set to be periodically reported.

[0091] The EventUpload (event reporting) is further specified as shown in Table 8:

[0092] Table 8:

[0093]

[0094] The event reporting data item includes a set of event trigger conditions and information of event reporting type. For the data field of eventTriggers, this field can appear repeatedly in the data, i.e. 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 operation.

[0095] The eventUploadType event reporting type includes a first type when eventUploadType == 0, which means that the data reported when the event is triggered 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 the data reported when the event is triggered includes the data within a set range before and after the event triggering.

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

[0098] Specifically, for the data field of uploadTimeBefore, 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 triggering. 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 triggering needs to be reported.

[0099] The EventTriggers (event triggering condition) is further specified, as shown in Table 9:

[0100] Table 9:

[0101]

[0102] The EventTriggers is used to define the conditions or factors for triggering a certain event. When a new event triggering data is added, the triggering condition of the event is determined through the event configuration parameter of the event, and a separate data reporting protocol is quickly formulated for the event.

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

[0104] Table 10:

[0105]

[0106]

[0107] In Table 10, the first 7 items are attribute information of the event signal, and the can bus can parse the signal value corresponding to the canid message. The last 2 items are condition information of the event triggering operation, and the signal value satisfies the condition when the event is triggered.

[0108] The specification of the ActionResult is further specified, as shown in Table 11:

[0109] Table 11:

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

[0111] The ms-level canid extended data configuration also includes a T-Box instruction response configuration, which includes a data type configuration. It can be understood that after the cloud platform issues a collection task instruction, the T-Box is set to respond to the instruction and feed back the result after executing the task, and then the data structure of this structure is specified, that is, the bus data structure is specified by seconds. For example, in the operation result of a vehicle communication system, the “ActionResult” can contain multiple “canDataS” fields, each of which records the bus data situation within one second.

[0112] For the can bus communication between the T-Box and the in-vehicle controller, the CanDataModel is further specified, as shown in Table 12:

[0113] Table 12:

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

[0115] It is indicated that in the “CanDataModel” data structure, a data element named “canDataS” is included, which is specific in data type and repeatable, and is used to represent the bus data structure by seconds. For example, in a can bus data structure, there can be multiple “canDataS” elements, each of which records the bus data situation at different times or different parts of a second.

[0116] Further specification of CanDataS is shown in Table 13:

[0117] Table 13:

[0118]

[0119] Through the configuration of the basic event data reporting protocol described above, the corresponding functions are realized in the basic event data reporting protocol in this paper. For example, platform side to T-Box instruction issuing, T-Box to platform side instruction response, and T-Box to platform side ms-level data transmission function. It should be noted that all the protocols for the above functions adopt the MQTT protocol, and the clientId is recommended to use the vin as the unique identifier. The topic topic_diag corresponding to the specific function is defined in the detailed description of each chapter below, which includes the wildcard topic topic subscribed by the T-Bbox. That is, through the above content, the basic framework and rules for the communication of related functions are set, including the protocol used, the way of client identification, and the definition and scope of the topic.

[0120] Further, the three specific topics topic realize the functions of issuing collection tasks, data reporting, and querying collection tasks.

[0121] In some embodiments, in combination with Figure 1 As shown in the process of issuing collection tasks, the cloud platform message carrier is specified, as shown in Table 14:

[0122] Table 14:

[0123]

[0124]

[0125] Further, the ms-level canid extended data configuration also includes T-Box instruction response configuration, which includes data type configuration, action configuration, and result configuration. After generating the target event reporting protocol 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 cloud platform server; wherein the result of the instruction response is stored based on the second-level bus data structure.

[0126] The T-Box instruction 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 topic and the specification of the corresponding task data structure, the protocol in this paper provides the following instruction functions:

[0130] Set the upload period 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 by different can channels.

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

[0133] Set the event trigger post-acquisition method (event reporting type) to determine how data is collected and reported after the event is triggered.

[0134] Set the canid list required for specific acquisition cycle channel acquisition to specify the list of can identifiers (canid) that need to be acquired in each acquisition cycle channel.

[0135] According to the set acquisition cycle, the canid filter list collects data, which is used to actually obtain data according to the acquisition cycle and canid filter list that have been set.

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

[0137] It should be noted that the following matters need attention in the design process of issuing acquisition tasks in the basic event data reporting protocol:

[0138] 1. The consumption speed is greater than the production speed, that is, the uploading speed is greater than the acquisition speed, which means that the data uploading rate should be faster than the acquisition rate.

[0139] 2. Currently, the maximum number of messages uploaded at a time is 200, and the maximum number of messages that can be configured for acquisition in one upload cycle is 200.

[0140] 3. (canid_cnt_1 / sampleCycleMs_1+.....+canid_cnt_n / sampleCycleMs_n)*1000*uploadCycleS<=200, which is used to constrain the relationship between acquisition and uploading. Where canid_cnt represents the number of different canids, sampleCycleMs represents the corresponding acquisition cycle (milliseconds), and uploadCycleS represents the upload cycle (seconds). That is, the result calculated by combining the acquisition frequency of various canids and the upload cycle cannot exceed 200.

[0141] 4. Due to terminal resource reasons, the list cannot be configured unlimitedly, and the maximum number is currently 200.

[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 in data collection and uploading processes are set to adapt to terminal resources and system performance requirements.

[0144] In some embodiments, the query collection task is combined with Figure 1 As shown, the process of querying the collection task specifies the message carrier issued by the cloud platform, as shown in Table 16:

[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 specified as shown in Table 17:

[0148] Table 17:

[0149]

[0150] Through the above definition of topic and specification of corresponding task data structure, the protocol of the present application provides the following instruction functions:

[0151] Query upload period, used to determine the time interval setting value of data uploading;

[0152] Query collection period, used to determine the time interval arrangement of data collection;

[0153] Query event trigger condition, used to specify the specific condition setting that causes a specific event to occur;

[0154] Query event trigger data collection method, used to determine how data is collected after an event is triggered;

[0155] Query the signals required for the specific collection period, used to determine which specific data signals should be collected in a specific collection period.

[0156] Query collection task is a follow-up task for issuing collection tasks. After the issuance of collection tasks is set so that the corresponding collection tasks are configured in the system, the collection tasks in the T-Box local can be queried through the query collection task, and the above reporting task information.

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

[0158] It should be noted that the following matters need attention in the design process of querying collection tasks in the basic event data reporting protocol:

[0159] 1. If no acquisition task is set, the filling value (xx represents) in the response is filled with the default value. That is, if there has never been a setting operation of the acquisition task before, when receiving the instruction of querying the acquisition related information (such as acquisition period, acquisition signal, etc.), in the returned response content, for those places that need to be filled with data (indicated by "xx"), all of them are filled with the default value set in advance.

[0160] For example, the default acquisition period can be 60 seconds, and if no acquisition task is set, the acquisition 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 with Figure 1 As shown, the process of data uploading, the T-Box reports to the cloud are specified, as shown in Table 18:

[0162] Table 18:

[0163]

[0164]

[0165] Through the definition of the above topic and the specification of the corresponding task data structure, the protocol of the present application provides the following instruction functions:

[0166] Reporting data when there is an event and the event meets the reporting requirements, that is, when an event occurs and the event meets the pre-set reporting requirements, the data related to the event needs to be reported;

[0167] Reporting data when there is no event and the filtering condition is met, that is, when there is no event, but the current data meets the set filtering condition, data reporting is also required.

[0168] Through the above two functions, event triggered reporting and periodic reporting of data are realized.

[0169] It should be noted that in the design process of data uploading in the basic event data reporting protocol, the following matters need attention:

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

[0171] 2. The data collected first is sent first; ensure the timeliness and sequence of the data;

[0172] 3. mainPb.transmitData.data uses zlib compression. We tested a segment of actual message data. 100 messages of 1500 bytes are compressed to 667 bytes using zlib.

[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] The above limitations enable data to be sent, stored, compressed, or transmitted locally when it cannot be sent, stored, or compressed normally, thereby ensuring data integrity, timeliness, and efficient transmission.

[0175] Based on the above embodiments, a basic event data reporting protocol is constructed. This basic event data reporting protocol provides a unified protocol format for collection tasks and can be used on any vehicle model. Compared with the existing method of developing a new independent protocol for each new event triggering data reporting, which consumes a lot of time and effort and is not universal across different vehicle models, the event data reporting protocol in this paper has the following advantages:

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

[0177] 2) Strong applicability: The thresholds for event triggering in the present invention are all dynamically adjustable, and the triggering events, the time before and after the event, 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) Efficiency: This invention requires only one development cycle to meet the needs of subsequent use across various vehicle models, eliminating the need for secondary development. Furthermore, for each new event, business requirements only require providing 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 Internet of Vehicles 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 in an embodiment of this specification, which includes the following steps:

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

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

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

[0184] In the embodiment, the target event reporting protocol is obtained through an event reporting protocol generation method, and the event reporting protocol generation method comprises:

[0185] S210, receive a collection task instruction issued by the cloud platform server, and the collection task instruction comprises event configuration parameters of a target event.

[0186] The collection task instruction issued by the cloud platform server is received, and the collection task instruction comprises event configuration parameters of a target event.

[0187] When it is necessary to monitor and analyze the data of some specific events in a vehicle, the cloud platform server issues a collection task instruction for collecting the data of a target event, and when the corresponding task is not saved in the T-Box of the vehicle, the collection task of the target event needs to be configured. Among them, the event configuration parameters corresponding to the target event need to be obtained.

[0188] As an example, the specific events are, for example, component failure, ADAS event, driver state monitoring, sudden acceleration and sudden braking.

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

[0190] When the collection task instruction issued by the cloud platform server is received, a separate protocol for the target event is formulated 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 foregoing embodiment, that is, the target event reporting protocol.

[0191] In the embodiment, based on the target event reporting protocol, whether the can data signal associated with the target event meets an event triggering condition, the event triggering condition set comprises a plurality of event triggering conditions, when the can data meets 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 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 when the target event trigger condition is met, for vehicle analysis, including:

[0193] The can data is parsed based on the attribute information of the event signal, and a signal value is obtained.

[0194] When the signal value meets the condition information of the trigger operation, it is indicated 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 trigger condition further includes attribute information of the event signal and condition information of the trigger operation, such as the data item in Table 10.

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

[0197] In another embodiment, when the target event is not triggered, it is further determined whether the can data associated with the target event meets the set filtering condition (such as the data item in CanIdList), and if so, the can data also needs to be reported.

[0198] In some embodiments, the event data reporting method comprises: when the target event trigger condition is met, the can data is compressed by zlib and then reported to the cloud platform server for vehicle analysis. The actual test shows the compression effect (100 messages are compressed from 1500 bytes to 667 bytes), so as to reduce the data transmission amount and improve the transmission efficiency.

[0199] Based on the above embodiments, the event data reporting method further comprises:

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

[0201] S400, querying the local task of the T-Box based on the query task instruction, and uploading the task information corresponding to the target event when the collection task of the target event is queried.

[0202] It is determined through the T-Box whether the collection task of the target event corresponding to the query task instruction exists in the local task, and in the case of existence, the T-Box reports the task information to the cloud platform.

[0203] In this embodiment, the T-Box can respond to query requests from 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 obtain relevant vehicle data 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. Furthermore, 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 when the target event triggering condition is met, the CAN data is reported to the cloud platform server 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.

[0205] Based on the same application concept as the above method, the embodiment of the present application 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 CAN data associated with the target event sent by the in-vehicle controller;

[0208] A data analysis module 404 is configured 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 trigger 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 the cloud platform server, and the collection task instruction includes the event configuration parameters of the target event; generating the target event reporting protocol based on the event configuration parameters and the 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 effects 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 communications interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communications interface 820, and the memory 830 communicate with each other via 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 sold or used as an independent product. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0213] On the other hand, the present application also provides a computer program product, which includes a computer program, which 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 to execute the event data reporting method provided by the above methods when the computer program is executed by a processor.

[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 conflict. The scope of protection of the present application is not limited to the precise structure described in the above embodiments and shown in the accompanying drawings; any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present application shall be included in the scope of protection of the present application.

Claims

1. A method for reporting event data, characterized in that: The method is applied to a telematics control unit T-Box, and includes: Receive CAN data associated with target events sent by the in-vehicle controller; Parsing the CAN data based on the target event reporting protocol and reporting the CAN data to the server for vehicle analysis when the 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, wherein: 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, wherein: 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. 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 the set periodically reported data.

4. The event data reporting method according to claim 3, wherein: The data items of the event report include the event trigger condition set and the event report type information; 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, wherein: 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, wherein: The ms-level canid extended data configuration also includes a T-Box command 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 millisecond-level command response result 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, wherein: The method further comprises: Receiving a 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, wherein: The step of reporting the CAN data to a server for vehicle analysis when a 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: The method comprises 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, which, when executed, implements the steps of the event data reporting method according to any one of claims 1 to 9.

Images