Data collection method, terminal device, medium and system

Abstract

The present application relates to the field of data collection technology, and specifically provides a data collection method, terminal device, medium and system, aiming to solve the technical problem of low data collection efficiency of existing methods. To this end, the data collection method of the present application includes: obtaining a first configuration file, the first configuration file includes an abnormal event and its corresponding abnormal data collection rule set; receiving parameter information of the abnormal event; obtaining the abnormal data collection rule corresponding to the abnormal event from the first configuration file based on the parameter information; collecting data based on the abnormal data collection rule. In this way, the efficiency and quality of data collection are improved, the complexity of using different tools and configuration files at different stages is avoided, the compilation of multiple versions of software is reduced, and the maintainability and scalability of the system are improved.

Description

Technical Field

[0001] The present application relates to the field of data collection technology, and specifically provides a data collection method, terminal equipment, medium and system. Background Art

[0002] As competition becomes increasingly fierce, manufacturers generally continue to collect abnormal data from terminal devices in order to update the software and provide users with a better user experience.

[0003] The life cycle of current terminal devices generally includes the R&D stage, the trial stage, and the mass production stage. Existing methods generally capture abnormal data at a specific stage, such as startup failures in the R&D stage, or problem feedback in the mass production stage. Alternatively, tools with different configuration files are used to capture abnormal data in each stage or scenario. At the same time, since there is a certain period of parallelism between the trial stage and the mass production stage, manufacturers will compile multiple software versions, resulting in more testing experience investment, ultimately extending the project time and increasing labor costs. Summary of the invention

[0004] In order to overcome the above defects, the present application is proposed to provide a solution or at least partially solve the technical problem of low data collection efficiency of the existing method. The present application provides a data collection method, terminal device, medium and system.

[0005] In a first aspect, the present application provides a data collection method, applied to a terminal device, the method comprising:

[0006] Obtaining a first configuration file, wherein the first configuration file includes an abnormal event and a corresponding abnormal data collection rule set;

[0007] Receive parameter information of abnormal events;

[0008] Acquire, from the first configuration file, an abnormal data collection rule corresponding to the abnormal event based on the parameter information;

[0009] Data is collected based on the abnormal data collection rules.

[0010] In one implementation of the present application, obtaining the first configuration file includes:

[0011] Acquire device information of the terminal device;

[0012] Determine the life cycle of the terminal device based on the device information;

[0013] Obtaining a preset configuration file corresponding to the life cycle;

[0014] The first configuration file is determined based on the preset configuration file.

[0015] In one implementation of the present application, the obtaining of a preset configuration file corresponding to the life cycle includes:

[0016] Receive the preset configuration file from a cloud device; or

[0017] The data is obtained from a file stored locally on the terminal device.

[0018] In one embodiment of the present application, after determining the first configuration file based on the preset configuration file, the method further includes:

[0019] Determine whether the cloud device sends the first configuration information;

[0020] When the cloud device sends the first configuration information, the first configuration file is updated based on the first configuration information.

[0021] In one embodiment of the present application, the device information includes a software version number and a hardware version number;

[0022] The determining the life cycle of the terminal device based on the device information includes:

[0023] When the software version number includes a trial identifier, the life cycle of the terminal device is in the trial stage;

[0024] When the software version number includes a mass production identifier, determining whether the hardware version number includes a mass production identifier; if so, the life cycle is the mass production stage, otherwise it is the trial stage;

[0025] When the software version number does not include a trial identifier and a mass production identifier, the life cycle is the research and development stage.

[0026] In one embodiment of the present application, the parameter information includes the abnormal event type;

[0027] The acquiring, from the first configuration file based on the parameter information, an abnormal data collection rule corresponding to the abnormal event includes:

[0028] Determining whether the abnormal event type exists in the first configuration file;

[0029] When the abnormal event type exists in the first configuration file, an abnormal data collection rule corresponding to the abnormal event is obtained from the first configuration file according to the abnormal event type.

[0030] In one embodiment of the present application, the method comprises:

[0031] When the abnormal event type does not exist in the first configuration file, requesting the cloud device to send second configuration information, the second configuration information including an abnormal data collection rule corresponding to the abnormal event type, the abnormal event type being an abnormal event type that does not exist in the first configuration file;

[0032] Update the first configuration file according to the second configuration information.

[0033] In one embodiment of the present application, the parameter information includes a data path;

[0034] The collecting data based on the abnormal data collection rule includes: collecting data from the data path based on the abnormal data collection rule.

[0035] In one embodiment of the present application, the first configuration file also includes an abnormal event and a set of abnormal data storage rules corresponding thereto; the method further includes:

[0036] Acquire, from the first configuration file according to the parameter information, an abnormal data storage rule corresponding to the abnormal event;

[0037] The collected data is stored according to the abnormal data storage rule.

[0038] In one embodiment of the present application, the parameter information includes the abnormal event type;

[0039] The acquiring the abnormal data storage rule corresponding to the abnormal event from the first configuration file based on the parameter information includes:

[0040] Determining whether the abnormal event type exists in the first configuration file;

[0041] When the abnormal event type exists in the first configuration file, the abnormal data storage rule corresponding to the abnormal event is obtained from the first configuration file according to the abnormal event type.

[0042] In one embodiment of the present application, the first configuration information includes a data retention threshold;

[0043] The updating of the first configuration file based on the first configuration information includes: updating the first configuration file based on the data retention threshold.

[0044] In one embodiment of the present application, the method further includes:

[0045] When receiving parameter information of multiple abnormal events, determining whether the parameter information of the multiple abnormal events is consistent;

[0046] If so, a single data collection is performed based on the abnormal data collection rule.

[0047] In a second aspect, a terminal device is provided, including:

[0048] at least one processor;

[0049] and, a memory communicatively coupled to the at least one processor;

[0050] Wherein, a computer program is stored in the memory, and the computer program is the aforementioned data collection method when executed by the at least one processor.

[0051] In a third aspect, a computer-readable storage medium is provided, wherein a plurality of program codes are stored in the computer-readable storage medium, wherein the program codes are suitable for being loaded and run by a processor to execute any of the aforementioned data collection methods.

[0052] In a fourth aspect, a data collection system is provided, the data collection system comprising the aforementioned terminal device and a cloud device, wherein the cloud device is used to send a preset configuration file and configuration information to the terminal device.

[0053] Solution 1. A data collection method, applied to a terminal device, characterized in that the method comprises:

[0054] Obtaining a first configuration file, wherein the first configuration file includes an abnormal event and a corresponding abnormal data collection rule set;

[0055] Receive parameter information of abnormal events;

[0056] Acquire, from the first configuration file, an abnormal data collection rule corresponding to the abnormal event based on the parameter information;

[0057] Data is collected based on the abnormal data collection rules.

[0058] Solution 2. The data collection method according to Solution 1, characterized in that obtaining the first configuration file comprises:

[0059] Acquire device information of the terminal device;

[0060] Determine the life cycle of the terminal device based on the device information;

[0061] Obtaining a preset configuration file corresponding to the life cycle;

[0062] The first configuration file is determined based on the preset configuration file.

[0063] Solution 3. The data collection method according to Solution 2 is characterized in that the step of obtaining a preset configuration file corresponding to the life cycle comprises:

[0064] Receive the preset configuration file from a cloud device; or

[0065] The data is obtained from a file stored locally on the terminal device.

[0066] Solution 4. The data collection method according to Solution 2 is characterized in that after determining the first configuration file based on the preset configuration file, the method further includes:

[0067] Determine whether the cloud device sends the first configuration information;

[0068] When the cloud device sends the first configuration information, the first configuration file is updated based on the first configuration information.

[0069] Solution 5. The data collection method according to Solution 2, wherein the device information includes a software version number and a hardware version number;

[0070] The determining the life cycle of the terminal device based on the device information includes:

[0071] When the software version number includes a trial identifier, the life cycle of the terminal device is in the trial stage;

[0072] When the software version number includes a mass production identifier, determining whether the hardware version number includes a mass production identifier; if so, the life cycle is the mass production stage, otherwise it is the trial stage;

[0073] When the software version number does not include a trial identifier and a mass production identifier, the life cycle is the research and development stage.

[0074] Solution 6. The data collection method according to Solution 1, characterized in that the parameter information includes the abnormal event type;

[0075] The acquiring, from the first configuration file based on the parameter information, an abnormal data collection rule corresponding to the abnormal event includes:

[0076] Determining whether the abnormal event type exists in the first configuration file;

[0077] When the abnormal event type exists in the first configuration file, an abnormal data collection rule corresponding to the abnormal event is obtained from the first configuration file according to the abnormal event type.

[0078] Solution 7. The data collection method according to Solution 6, characterized in that the method comprises:

[0079] When the abnormal event type does not exist in the first configuration file, requesting the cloud device to send second configuration information, the second configuration information including an abnormal data collection rule corresponding to the abnormal event type, the abnormal event type being an abnormal event type that does not exist in the first configuration file;

[0080] Update the first configuration file according to the second configuration information.

[0081] Solution 8. The data collection method according to Solution 1, characterized in that the parameter information includes a data path;

[0082] The collecting data based on the abnormal data collection rule includes: collecting data from the data path based on the abnormal data collection rule.

[0083] Solution 9. The data collection method according to Solution 1 is characterized in that the first configuration file also includes an abnormal event and a set of abnormal data storage rules corresponding thereto; the method further includes:

[0084] Acquire, from the first configuration file according to the parameter information, an abnormal data storage rule corresponding to the abnormal event;

[0085] The collected data is stored according to the abnormal data storage rule.

[0086] Solution 10. The data collection method according to Solution 9, wherein the parameter information includes an abnormal event type;

[0087] The acquiring the abnormal data storage rule corresponding to the abnormal event from the first configuration file based on the parameter information includes:

[0088] Determining whether the abnormal event type exists in the first configuration file;

[0089] When the abnormal event type exists in the first configuration file, the abnormal data storage rule corresponding to the abnormal event is obtained from the first configuration file according to the abnormal event type.

[0090] Solution 11. The data collection method according to Solution 4, wherein the first configuration information includes a data retention threshold;

[0091] The updating of the first configuration file based on the first configuration information includes: updating the first configuration file based on the data retention threshold.

[0092] Solution 12. The data collection method according to Solution 1, characterized in that the method further comprises:

[0093] When receiving parameter information of multiple abnormal events, determining whether the parameter information of the multiple abnormal events is consistent;

[0094] If so, a single data collection is performed based on the abnormal data collection rule.

[0095] Solution 13. A terminal device, comprising:

[0096] at least one processor;

[0097] and, a memory communicatively coupled to the at least one processor;

[0098] Wherein, a computer program is stored in the memory, and when the computer program is executed by the at least one processor, the data collection method described in any one of Schemes 1 to 12 is implemented.

[0099] Solution 14. A computer-readable storage medium storing a plurality of program codes, wherein the program codes are suitable for being loaded and run by a processor to execute the data collection method described in any one of Solutions 1 to 12.

[0100] Solution 15. A data collection system, characterized in that the data collection system includes the terminal device and cloud device described in Solution 13, wherein the cloud device is used to send a preset configuration file and configuration information to the terminal device.

[0101] The above one or more technical solutions of this application have at least one or more of the following Beneficial effects:

[0102] The data collection method provided by the present application includes: first obtaining a first configuration file, the first configuration file includes an abnormal event and its corresponding abnormal data collection rule set; receiving parameter information of the abnormal event; obtaining the abnormal data collection rule corresponding to the abnormal event from the first configuration file based on the parameter information; and collecting data based on the abnormal data collection rule. The abnormal data collection rule can accurately collect data for specific abnormal events, ensure that the collected data has a high degree of relevance and value, improve the efficiency and quality of data collection, avoid the complexity of using different tools and configuration files at different stages, reduce multi-version software compilation, simplify the management and configuration of data collection, and improve the maintainability and scalability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0103] The disclosure of the present application will become more easily understood with reference to the accompanying drawings. It is easy for those skilled in the art to understand that these drawings are only for illustrative purposes and are not intended to limit the scope of protection of the present application. In addition, similar numbers in the drawings are used to represent similar components, among which:

[0104] Figure 1 It is a schematic diagram of the main process of a data collection method in one embodiment of the present application;

[0105] Figure 2 is a schematic diagram of the structure of an electronic device in one embodiment of the present application;

[0106] Figure 3 This is a system architecture diagram corresponding to a data collection method in one embodiment of the present application;

[0107] Figure 4 It is a flowchart of determining the life cycle stage of a terminal device in one embodiment of the present application;

[0108] Figure 5 It is a schematic diagram of the process of flashing the hardware version number in one embodiment of the present application;

[0109] Figure 6 This is a schematic diagram of equipment production in which a trial stage and a mass production stage coexist in one embodiment of the present application;

[0110] Figure 7 is a complete method diagram of a data collection method in one embodiment of the present application;

[0111] Figure 8 It is a schematic diagram of a process of realizing data collection by interaction between a client device and a cloud device in one embodiment of the present application;

[0112] Fig. 9 is a schematic diagram of the structure of a data collection device in one embodiment of the present application;

[0113] Fig.10 It is a schematic diagram of the structure of a terminal device in one embodiment of the present application. DETAILED DESCRIPTION

[0114] Some embodiments of the present application are described below with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are only used to explain the technical principles of the present application and are not intended to limit the protection scope of the present application.

[0115] In the description of the present application, "module" and "processor" may include hardware, software or a combination of the two. A module may include hardware circuits, various suitable sensors, communication ports, memory, and may also include software parts, such as program code, or a combination of software and hardware. The processor may be a central processing unit, a microprocessor, an image processor, a digital signal processor or any other suitable processor. The processor has data and / or signal processing functions. The processor may be implemented in software, hardware or a combination of the two. Non-temporary computer-readable storage media include any suitable medium that can store program code, such as a disk, a hard disk, an optical disk, a flash memory, a read-only memory, a random access memory, etc. The term "A and / or B" means all possible combinations of A and B, such as only A, only B or A and B. The term "at least one A or B" or "at least one of A and B" has a similar meaning to "A and / or B" and may include only A, only B or A and B. The singular terms "one" and "the" may also include plural forms.

[0116] At present, the traditional method generally uses tools with different configuration files to capture abnormal data in each stage or scenario. At the same time, due to the parallel period between the trial stage and the mass production stage, multiple software versions need to be compiled, which leads to more testing experience investment, ultimately prolonging the project time and increasing labor cost expenditure.

[0117] To this end, the present application provides a data collection method, terminal device, medium and system.

[0118] The data collection method in this application is applied to terminal devices. The terminal devices in this application can be mobile phones, tablet computers, personal computers (PCs), personal digital assistants (PDAs), smart watches, netbooks, wearable electronic devices, augmented reality (AR) devices, virtual reality (VR) devices, vehicle-mounted devices, smart cars, smart speakers, robots, etc. This application does not specifically limit the specific form of the terminal devices.

[0119] See attached Figure 1 , Figure 1 It is a flowchart of the main steps of a data collection method according to an embodiment of the present application. The data collection method of the present application can be applied to a terminal device.

[0120] like Figure 1 As shown, the data collection method in the embodiment of the present application mainly includes the following steps S10 to S40.

[0121] Step S10: Obtain a first configuration file.

[0122] The first configuration file is a file including abnormal events and their corresponding abnormal data collection rule sets, that is, the first configuration file includes the correspondence between all possible abnormal events and abnormal data collection rules.

[0123] The correspondence between abnormal events and abnormal data collection rules refers to the mapping relationship between abnormal events and abnormal data collection rules, that is, each abnormal event corresponds to at least one abnormal data collection rule, so as to ensure that data can be collected using appropriate abnormal data collection rules according to different abnormal events. The abnormal event collection rules may include abnormal event type, collection frequency, collection duration, etc., which can be adaptively adjusted according to actual application scenarios, and are not specifically limited to this.

[0124] An exception event can be an exception or error that occurs during the running of an application. The exception event type is the type of the exception event.

[0125] The data may be all data generated by the application itself, the software system in which the application is located, or other applications associated with the application itself during the operation of the application, etc., and the embodiments of the present application do not make specific limitations on this.

[0126] Step S20: receiving parameter information of the abnormal event through a preset abnormal event feedback interface.

[0127] The abnormal event feedback interface is a pre-set interface for receiving parameter information of abnormal events from different sources, such as receiving parameter information of abnormal events sent from different business applications. In addition, the abnormal event feedback interface can also support synchronous and / or asynchronous functions, such as synchronously receiving parameter information of abnormal events sent from different business applications, or asynchronously receiving parameter information of abnormal events sent from different business applications, thereby providing a more flexible data processing method to meet the needs of different scenarios.

[0128] The parameter information of the abnormal event refers to the relevant parameters of the specific abnormal event received through the abnormal event feedback interface, such as the abnormal event type and data path.

[0129] Abnormal event types are used to classify and identify different types of abnormal events. Each abnormal event type represents a type of abnormal situation or fault.

[0130] The data path may be an address where the abnormal data is located.

[0131] Step S30: Acquire an abnormal data collection rule corresponding to the abnormal event from the first configuration file based on the parameter information.

[0132] The first configuration file includes an abnormal event and a set of abnormal data collection rules corresponding to the abnormal event. The abnormal data collection rules corresponding to the abnormal event can be obtained from the first configuration file according to the parameter information.

[0133] Step S40: Collect data based on abnormal data collection rules.

[0134] The first configuration file can be obtained when the terminal device is started. After obtaining the first configuration file, the obtained first configuration file can be stored in a local folder of the terminal device. When an abnormal event occurs subsequently, the abnormal data collection rule corresponding to the abnormal event can be directly searched from the first configuration file according to the parameter information, and finally data collection is performed according to the abnormal data collection rule.

[0135] Based on the above steps S10 to S40, first obtain the first configuration file; receive the parameter information of the abnormal event; obtain the abnormal data collection rules corresponding to the abnormal event from the first configuration file based on the parameter information; collect data based on the abnormal data collection rules. Through the abnormal data collection rules, accurate data collection can be performed for specific abnormal events to ensure that the collected data has a high degree of relevance and value, improve the efficiency and quality of data collection, avoid the complexity of using different tools and configuration files at different stages, reduce multi-version software compilation, simplify the management and configuration of data collection, and improve the maintainability and scalability of the system.

[0136] Exemplarily, taking electronic devices such as mobile phones and tablet computers as examples of terminal devices, the hardware structure of the terminal devices is described in detail.

[0137] like Figure 2 As shown, in a specific implementation, the electronic device of the present application may include a processor 110, an external memory interface 120, an internal memory 121, a Universal Serial Bus (USB) interface 130, a charging management module 140, a wireless charging coil 140A, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a microphone 170B, an earphone interface 170C, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera module 193, a display screen 194, and a Subscriber Identification Module (SIM) card interface 195. The processor 110 may be directly or indirectly connected to other components through a system bus.

[0138] The processor 110 may include one or more processing units, for example, the processor 110 may include a central processing unit (CPU), an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor and / or a neural network processor (NPU), etc. Different processing units may be independent devices or integrated into one or more processors. The processor 110 may generate an operation control signal according to the instruction opcode and the timing signal to complete the control of reading and executing instructions.

[0139] The internal memory 121 can be used to store computer executable program codes, and the executable program codes include instructions. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function, etc. The data storage area may store data created during the use of the electronic device, etc. The internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (Universal Flash Storage, UFS), etc. The processor 110 executes various functional applications and data processing of the electronic device by running instructions stored in the internal memory 121 and / or instructions stored in a memory provided in the processor.

[0140] The wireless communication function of the electronic device can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, baseband processor, etc. In some embodiments, the antenna 1 of the electronic device is coupled with the mobile communication module 150, and the antenna 2 is coupled with the wireless communication module 160, so that the electronic device can communicate with other devices through a wireless communication network.

[0141] The mobile communication module 150 can provide electronic devices with wireless communication solutions including 2G / 3G / 4G / 5G.

[0142] The wireless communication module 160 can provide wireless communication solutions for electronic devices, including wireless local area networks (WLAN), wireless fidelity (Wi-Fi) networks, Bluetooth (BT), global navigation satellite systems (GNSS), near field communication technology (NFC), infrared technology (IR), etc.

[0143] The sensor module 180 may include an ambient light sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a proximity light sensor 180D, an acceleration sensor 180E, a fingerprint sensor 180F, a Hall sensor 180G, and a laser sensor 180H. In some examples, a health sensor and other types of sensors for monitoring the health of the user may also be included. The electronic device may collect various data through the sensor module 180.

[0144] It is understood that the above example structures do not constitute a specific limitation on the electronic device. In some other examples, the electronic device may include more or fewer components, or combine certain components, or split certain components, or arrange the components differently. In some examples, the same type of components may be one or more, such as a speaker or a microphone. The illustrated components may include hardware, software, or a combination of software and hardware.

[0145] In addition, if Figure 3 As shown, the present application also provides a system architecture of a terminal device-cloud device for implementing a data collection method, wherein the terminal device mainly implements the management of configuration files and the collection of abnormal data.

[0146] Cloud devices refer to remote devices that are accessed and managed remotely via the Internet. The main functions of cloud devices include data storage, application deployment, etc., which can provide users with flexible, scalable and efficient services. For example, a cloud server can be used as an example of the cloud device.

[0147] The modules in the terminal device are described in detail below.

[0148] like Figure 3As shown in the figure, the business applications in the end-side device can include data collection control applications, user feedback applications, Bluetooth, photo albums and other applications. The data collection control application is mainly an application used by developers to control the data collection process during the development and testing phase. It allows developers to set parameters such as the time interval, frequency, and type of data collection to better adjust and optimize the data collection plan. In addition, the application also provides the function of viewing data collection results in real time, which is convenient for developers to debug and verify.

[0149] The user feedback application is mainly used during the trial and mass production stages, where users send feedback to the system through this application. The feedback information includes not only general opinions and suggestions, but also various problems encountered by users during use.

[0150] The framework / kernel in system monitoring is used to monitor the operation of the entire system in an all-round way, including but not limited to CPU load, memory usage, remaining hard disk space, etc. Once any abnormality is found, the tracking point information is immediately reported and the data collection method of this application is used for data collection to prevent the potential risk from expanding.

[0151] The power consumption in system monitoring is used to monitor the power consumption of the device in real time. Factors that affect the power consumption of the software system may include CPU usage, memory usage, network communication, screen display, etc.

[0152] Peripheral subsystem monitoring is used to monitor the working status of various peripheral devices or subsystems of the terminal device, such as whether the camera is working normally, whether the microphone has noise interference, etc.

[0153] The abnormal event feedback interface is an application program interface provided by the terminal device. When an application fails or its performance degrades, the application can send parameter information to the abnormal data collection service by calling this interface, so that the corresponding abnormal data can be collected by the abnormal data collection service.

[0154] The data upload service is used to upload the locally collected data to the cloud device securely and reliably. In order to protect user privacy, the data needs to be desensitized before uploading. In addition, in order to ensure data security, encryption technology can be used for transmission.

[0155] Profile management is used to manage a complete set of preset profiles obtained from cloud devices. The preset profiles clearly specify what kind of data should be collected under what conditions. The business party can also modify the preset profiles adaptively according to the specific usage scenarios. This can ensure the validity of the data and avoid excessive collection and waste of resources. Specifically, the preset profile management includes different profiles for different life cycle stages of the device.

[0156] Collection permission management is used to regulate the code of conduct for data collection, stipulating details such as who has the right to collect data and how to collect it.

[0157] Storage file management is used to manage data storage solutions, including selecting appropriate storage media, determining data retention periods, and formulating disaster recovery plans.

[0158] The tracking point collection service is used to pre-set "tracking points" in the code, and trigger data collection every time these points are executed.

[0159] Configuration parsing management is used to parse configuration information from the cloud to update configuration files. In this way, data collection parameters and data storage parameters can be adjusted remotely and flexibly without redeploying the software.

[0160] Next, each module in the cloud device is described in detail.

[0161] The information management service is used to manage the relevant data processed by cloud devices. The tracking point management in the information management service is used to maintain a list of all known tracking points, which is convenient for developers to check and reference at any time. At the same time, it is also responsible for maintaining the mapping relationship between tracking points and specific business logic to ensure that each data collection can accurately reflect the actual business situation.

[0162] The device management in the information management service is used to record the basic information of each device and its current status, such as whether it is online, version number, geographic location, etc. In addition, the health status of the device should be checked regularly to warn of possible problems in advance.

[0163] Data monitoring and display service is a service used to monitor and display system, application or device data in real time. It helps administrators and users understand the system's operating status, identify potential problems, and make corresponding decisions by collecting, processing and visualizing data.

[0164] Threshold management is used to set upper and lower limits for various indicators. If the range is exceeded, a warning will be triggered. This allows you to take remedial measures before the problem worsens.

[0165] Report management is used to automatically generate various statistical reports to help decision-makers understand the overall situation. At the same time, it is also necessary to provide the function of customizing reports to generate reports based on the collected data to meet personalized needs.

[0166] The configuration delivery service is mainly used to manage and distribute configuration information to ensure that each module or device in the system can perform corresponding operations according to the latest configuration parameters.

[0167] Rule management defines a series of rules to determine when and how to push new configuration information to specified devices. These rules can be customized based on factors such as device type and geographical distribution to meet diverse needs.

[0168] Pull management is used to provide a mechanism for devices to download required content from cloud devices when the device actively requests the latest configuration.

[0169] The project management subsystem includes module management and issue management, etc. Module management divides the entire project into several independent small modules, each of which has its own person in charge and technology stack.

[0170] Problem management is used to collect and track various problems in the project, whether they are technical problems or other problems, and then arrange for dedicated people to solve these problems according to priority.

[0171] Data storage services can include modules such as data access and data storage. Data access is used to receive raw data from terminal devices or other systems, and clean and pre-process it to meet the requirements of the database.

[0172] Data warehousing is used to insert processed data into corresponding tables to form a structured data warehouse. At the same time, it can also perform tasks such as index optimization to improve query efficiency.

[0173] The permission management subsystem can include user management and page management, etc. User management is used to create, edit and delete user accounts, assign appropriate permission levels, and ensure that each user can only perform operations within their own permission range.

[0174] Page management is used to control which pages users of different levels can see and what content they can see.

[0175] The process management subsystem can include review flow creation and approval notification management. Review flow creation is used to establish a standardized approval process, covering all steps from application to approval, which can not only standardize internal operations but also show a professional image to the outside world.

[0176] Approval notification management is used to automatically send emails or text messages to notify relevant personnel to participate in approval activities, and to record the results of each approval for future inquiries.

[0137] Combine the following Figure 3 The system architecture shown further illustrates the above steps S10 to S40 respectively.

[0138] Specifically, step S10 can be implemented through the following steps S101 to S104.

[0139] Step S101: Acquire device attribute information of a terminal device.

[0140] Device attribute information is a parameter used to characterize the attributes of terminal devices, including but not limited to device model, hardware configuration, device software version number, device hardware version number, and usage environment, etc. The usage environment refers to the physical environment and operating environment in which the terminal device is located during actual operation, etc. The physical environment may include the life cycle, temperature, humidity, and electromagnetic interference of the terminal device, etc. The operating environment includes power quality, network conditions, system compatibility, and software updates and support, etc.

[0141] Specifically, device attribute information may be read from the memory of the terminal device.

[0142] Step S102: Determine the life cycle of the terminal device based on the device attribute information.

[0143] The life cycle of a terminal device refers to the stage that the terminal device is currently in, which can be the research and development stage, the trial stage, the mass production stage, the trial and mass production coexistence stage, etc.

[0144] In a specific embodiment of the present application, the device attribute information includes a device software version number and a device hardware version number; the determining of the life cycle of the terminal device based on the device attribute information includes: when the device software version number of the terminal device includes a trial identifier, the life cycle of the terminal device is in a trial stage; when the device software version number of the terminal device includes a mass production identifier, continue to determine whether the device hardware version number includes a mass production identifier, if so, the life cycle of the terminal device is in a mass production stage, otherwise it is in a trial stage; when the device software version number of the terminal device does not include a trial identifier and a mass production identifier, the life cycle of the terminal device is in a research and development stage.

[0145] The device software version number refers to the number of the software version currently running on the terminal device.

[0146] The device hardware version number refers to the number of the hardware version currently used by the terminal device.

[0147] The identifier is a character or string in the device software version number and the device hardware version number that is used to identify the current stage of the device.

[0148] Next, combine Figure 4 Steps S1021 to S1026 in the flowchart describe in detail how to determine the life cycle of the terminal device.

[0149] Step S1021: Set the initial life cycle of the terminal device to the research and development stage.

[0150] Step S1022: Obtain the device software version number.

[0151] Step S1023: Determine whether the device software version number contains a trial identifier. If so, the terminal device is currently in the trial stage. Otherwise, execute the following step S1024.

[0152] Step S1024: Determine whether the device software version number contains a mass production identifier. When the device software version number does not contain a mass production identifier, it is determined that the device is currently in the research and development stage. Otherwise, execute the following steps S1025 and S1026.

[0153] Step S1025: Obtain the device hardware version number.

[0154] Step S1026: further determine whether the device hardware version number contains a mass production identifier. If so, the terminal device is currently in the mass production stage, otherwise it is in the trial stage.

[0155] The current life cycle stage of the terminal device can be determined through the device software version number and the device hardware version number, which provides support for the subsequent acquisition of configuration files corresponding to different life cycle stages. A version can be compiled by default, and differentiated requirements can be issued through cloud configuration, so that only one version can be tested, saving labor costs.

[0156] Step S103: Obtain a preset configuration file corresponding to the life cycle of the terminal device.

[0157] The preset configuration file is a pre-set configuration file, which includes all possible abnormal events in the life cycle of the device and their corresponding abnormal data collection rule sets. In a specific embodiment of the present application, the preset configuration file can be received from a cloud device; or obtained from a file stored locally on the terminal device.

[0158] Specifically, abnormal events can be divided into three aspects: stability, performance and power consumption.

[0159] For stability, abnormal events mainly include abnormal events of system-level stability, abnormal events of application-level stability, and abnormal events of hardware-level stability. Abnormal events of system-level stability may include system restart, system crash, and device unresponsiveness. Abnormal events of application-level stability may include application flashback, application crash, interface abnormality, and functional failure. Abnormal events of hardware-level stability may include hardware failure and signal interference.

[0160] Taking the failure of Bluetooth connection as an example of an abnormal event of stability, the abnormal event types may include a failure of the Bluetooth module, an incorrect installation of the Bluetooth driver, a long distance between the Bluetooth and the device, etc.

[0161] In the preset configuration file, when the abnormal event type is a Bluetooth module failure, the corresponding abnormal event collection rules can be: the abnormal data type includes hardware status log, error code, call stack trace and environmental information, etc.; the collection frequency is to collect data every five minutes; the collection time is to continue collecting until the problem is solved.

[0162] When the abnormal event type is that the Bluetooth driver is not installed correctly, the corresponding abnormal event collection rules can be: the abnormal data type includes driver information, system log, installation history, etc.; the collection frequency is to collect data once an hour; the collection time is to continue collecting until the problem is solved.

[0163] When the abnormal event type is that the distance between Bluetooth and the device is too far, the corresponding abnormal event collection rules are: the abnormal data type can include Bluetooth signal strength, location information, user operation log, etc.; the collection frequency is once per minute; the collection time is continuous collection until the problem is solved.

[0164] For performance, abnormal events mainly include slow application startup and freezes, etc. Taking the freeze of video application playback as an example, the corresponding abnormal event types may include network delay and insufficient bandwidth, video buffering problems and video file incompatibility.

[0165] When the abnormal event type is network delay and insufficient bandwidth, the corresponding abnormal event collection rules are: the abnormal event data type includes network delay data, broadband usage and packet loss rate, etc.; the collection frequency is once every five seconds; the collection time is continuous collection until the problem is solved.

[0166] When the abnormal event type is a video buffering problem, the corresponding abnormal event collection rules are: the abnormal data type includes buffering time, buffering times, buffering percentage, etc.; the collection frequency is once every second where the freeze occurs; the collection time is continuous collection until the problem is solved.

[0167] When the abnormal event type is video file incompatibility, the corresponding abnormal event collection rules are: the abnormal data type includes video file integrity check, file format information, encoding parameters, etc.; the collection frequency is once each time a decoding error occurs; the collection time is continuous collection until the problem is solved.

[0168] For power consumption, abnormal events mainly include severe heating, fast power consumption and slow charging. Taking mobile phones as an example, the abnormal event types corresponding to slow charging include power adapter problems, battery aging and charging port failure.

[0169] When the abnormal event type is a power adapter problem, the corresponding abnormal event collection rules are: the abnormal data type includes adapter information, cable information, charging status log and error code, etc.; the collection frequency is once per minute; the collection time is continuous collection until the problem is solved.

[0170] When the abnormal event type is battery aging, the corresponding abnormal event collection rules are: the abnormal data type includes battery health status, charging curve and temperature information, etc.; the collection frequency is once per second; the collection time is continuous collection until the problem is solved.

[0171] When the abnormal event type is a charging interface failure, the corresponding abnormal event collection rules are: the abnormal data type includes hardware status logs, error code messages, and physical inspection records, etc.; the collection frequency is once per minute; and the collection time is continuous collection until the problem is solved.

[0172] Specifically, according to the life cycle of the device, a preset configuration file corresponding to the life cycle of the terminal device can be obtained, aiming to ensure the pertinence and effectiveness of data collection, which is conducive to improving the efficiency and accuracy of data collection.

[0173] Step S104: determining a first configuration file based on a preset configuration file.

[0174] Specifically, the preset configuration file can be used as the first configuration file. The specific abnormal data collection rules in the preset configuration file can also be adjusted to obtain the first configuration file, such as adding new abnormal data collection rules and / or deleting some abnormal data collection rules.

[0175] In a specific implementation of the present application, after determining the first configuration file based on the preset configuration file, the method further includes: determining whether the cloud device sends down the first configuration information; when the cloud device sends down the first configuration information, updating the first configuration file based on the first configuration information.

[0176] The first configuration information is the abnormal data collection rules corresponding to the abnormal events issued by the cloud device, which may specifically include the abnormal data type, collection duration, collection frequency, etc., without specific limitation.

[0177] Specifically, after obtaining the first configuration file, it can be further determined whether the cloud device sends the first configuration information. When the cloud device sends the first configuration information, the first configuration file is updated according to the abnormal event collection rules corresponding to the abnormal events sent by the cloud device. Specifically, it can be to add or delete abnormal event collection rules in the first configuration file according to the first configuration information. For example, when the first configuration information is an abnormal data type corresponding to a certain abnormal event, the abnormal data type corresponding to the abnormal event can be modified in the first configuration file; when the first configuration information is an abnormal data collection rule corresponding to a certain abnormal event, the abnormal event collection rule corresponding to the abnormal event can be directly added to the first configuration file. In this way, for the first configuration information sent by the cloud, differentiated business configurations for different stages of the device can be achieved, thereby dynamically adjusting the first configuration file, which is conducive to improving data collection efficiency.

[0178] The above is a further description of step S10 , and the following is a further description of step S20 .

[0179] Specifically, an abnormal event feedback interface needs to be pre-set, and there may be one or more abnormal event feedback interfaces. The upper-layer business application may send the parameter information of the abnormal event to the abnormal event collection service by calling the abnormal event feedback interface.

[0180] Application developers can add an exception event feedback interface to the application during the application development process. Then, when an exception event occurs in the application, the application can call the exception event feedback interface to feedback the parameter information of the exception event to the data collection service. After receiving the parameter information of the exception event fed back by the application, the data collection service takes the exception event as the target exception event.

[0181] The above is a further description of step S20 , and the following is a further description of step S30 .

[0182] The parameter information of the abnormal event includes the abnormal event type.

[0183] Specifically, step S30 can be implemented through the following steps S301 to S303.

[0184] Step S301: Determine whether there is an abnormal event type in the first configuration file.

[0185] Specifically, it is searched in the first configuration file whether there is a keyword matching the abnormal event type, if so, the following step S302 is executed, otherwise, the following step S303 is executed.

[0186] Step S302: Acquire an abnormal data collection rule corresponding to the abnormal event from the first configuration file according to the abnormal event type.

[0187] Specifically, an abnormal data collection rule matching the abnormal event type is extracted from the first configuration file. The abnormal data collection rule includes at least the abnormal data type, and may also include data collection duration and collection frequency, etc.

[0188] Step S303: Request the cloud device to send second configuration information, where the second configuration information includes abnormal data collection rules corresponding to abnormal event types, where the abnormal event types are abnormal event types that do not exist in the first configuration file; update the first configuration file according to the second configuration information.

[0189] The second configuration information is configuration information received from the cloud, and the second configuration information includes newly discovered or defined abnormal event types and detailed data collection rules for these types.

[0190] Specifically, when the abnormal event type does not exist in the first configuration file, a request is sent to the cloud device to obtain a new abnormal event type and its corresponding data collection rule (second configuration information). Then, the new abnormal event type and its corresponding data collection rule are added to the first configuration file to ensure that the existing data collection rules are not overwritten or conflicted, and the updated first configuration file is saved.

[0191] According to the type of abnormal event, specific abnormal data collection rules are obtained or added to the first configuration file, which can ensure that the collected data is not only comprehensive but also highly targeted, improve the accuracy and effectiveness of data collection, reduce unnecessary data collection, and reduce the waste of system resources. In addition, new abnormal data collection rules corresponding to the abnormal event type can be dynamically added to the first configuration file, which enhances the flexibility and adaptability of the system and enables it to better cope with various complex abnormal situations.

[0192] Compared with the mass production stage of existing terminal devices, under the condition of the same user experience (with minimal impact on user experience in terms of performance, power consumption, device life, etc.), for a certain type of exception, the default debugging information is incomplete. It is necessary to change the configuration file and iterate the software version before collecting the exception information. The present application can immediately optimize the configuration file according to the exception, which can not only quickly adjust the exception information collection content and configuration file, but also reduce the range of affected users, thereby improving the efficiency of exception data collection.

[0193] The above is a further description of step S30 , and the following is a further description of step S40 .

[0194] Specifically, after obtaining the abnormal data collection rules corresponding to the abnormal events, the abnormal data collection service collects data according to the abnormal data collection rules, thereby achieving accurate data collection for abnormal events and ensuring that the collected data is highly relevant and valuable.

[0195] In a specific implementation of the present application, the parameter information includes a data path; and the collecting data based on the abnormal data collection rule includes: collecting data from the data path based on the abnormal data collection rule.

[0196] The data path refers to the path where the abnormal data to be collected is located.

[0197] Specifically, according to the specific location of the data path accessing the data storage, data is collected from the data path according to the abnormal data collection rules. In this way, the purpose of directly collecting abnormal data from the data path is achieved, and the data collection efficiency is improved.

[0198] In a specific embodiment of the present application, the first configuration file also includes an abnormal event and its corresponding abnormal data storage rule set; the method also includes: obtaining the abnormal data storage rule corresponding to the abnormal event from the first configuration file according to the parameter information; and storing the collected data according to the abnormal data storage rule. Wherein, the parameter information includes the abnormal event type; the obtaining the abnormal data storage rule corresponding to the abnormal event from the first configuration file based on the parameter information includes: determining whether the abnormal event type exists in the first configuration file; when the abnormal event type exists in the first configuration file, obtaining the abnormal data storage rule corresponding to the abnormal event from the first configuration file according to the abnormal event type.

[0199] Abnormal data storage rules are specific data storage strategies corresponding to abnormal events, wherein the abnormal data storage rules may specifically include storage location, storage format, storage cycle, data retention mechanism, etc.

[0200] Specifically, when an abnormal event type exists in the first configuration file, the abnormal data storage rule corresponding to the abnormal event type is directly obtained from the first configuration file, and the abnormal data collection service further stores the collected data according to the abnormal data storage rule. Exemplarily, the collected data can be stored in a specified location in a preset format according to the storage format and storage location in the abnormal data storage rule. The size of the stored data can also be controlled according to the data retention mechanism in the first configuration file.

[0201] In a specific implementation of the present application, the first configuration information includes a data retention threshold; and updating the first configuration file based on the first configuration information includes: updating the first configuration file based on the data retention threshold.

[0202] The first configuration information also includes a data retention threshold value issued by the cloud device. The data retention threshold value refers to the maximum amount of collected data that can be retained.

[0203] Exemplarily, the data retention threshold value sent from the cloud can update the data retention threshold value for storing files in the first configuration file from one copy to three copies, so that more collected data can be stored, thereby improving data security.

[0204] In a specific implementation of the present application, it also includes: when the abnormal event feedback interface receives parameter information of multiple abnormal events, determining whether the parameter information of the multiple abnormal events is consistent; if so, performing a single data collection based on the abnormal data collection rule.

[0205] Specifically, when the abnormal event feedback interface receives parameter information of multiple abnormal events, key information, such as the abnormal event type, is extracted from each parameter information, and the parameter information of multiple abnormal events is further compared to determine whether they are completely consistent. If the parameter information is inconsistent, each abnormal event is processed separately. If the parameter information is consistent, one or a single data collection is performed according to the abnormal data collection rules. In this way, the efficiency and accuracy of data collection are improved, the abnormal event processing process is simplified, and the reliability and stability of the system are enhanced.

[0206] pass Figure 5 Steps S1-S3 in the figure illustrate the process of flashing the hardware version number of the terminal device.

[0207] Step S1: First, a batch of devices are produced, and the initial stage of the device life cycle is set to the research and development stage. Then, a specific hardware version number is flashed into this batch of devices.

[0208] Step S2: Select a portion of the R&D devices that have been flashed with a specific hardware version number as trial devices, and further flash another specific hardware version number into the trial devices.

[0209] Step S3: For the devices put into mass production, a specific hardware version number is flashed again, and the hardware version number is different from the hardware version number of the aforementioned trial device.

[0210] pass Figure 6 Steps S11-S17 in the figure illustrate the equipment production process in which the trial stage and the mass production stage coexist in the present application.

[0211] Step S11: The R&D personnel compile a software version number with a trial identification, such as ××__beta.

[0212] Step S12: Push this version to relevant personnel for trial.

[0213] Step S13: The project development is about to be completed, and the R&D personnel compile a software version number ××__mp with a mass production logo.

[0214] Step S14: Push this version to relevant personnel for trial. At this time, all trial versions become ××__mp, and there is no ××__beta.

[0215] Step S15: Determine if there is no abnormality in the trial of this version. If so, execute step S16; otherwise, execute step S17.

[0216] Step S16: Push to the factory for production and sale.

[0217] Step S17: After R&D corrects the problem, it re-releases version yy__mp and tries it out.

[0218] Figure 7 It can be used as a flow chart of the data collection method of this application. Figure 7 As shown, the data collection method can be implemented through the following steps S111 to S115.

[0219] Step S111: Each application identifies its own abnormal scenario.

[0220] Step S112: After an exception occurs in the application, the application calls the exception event feedback interface and sends the exception event type to the exception data collection service.

[0221] Step S113: The abnormal data collection service determines whether the abnormal event type already exists in the first configuration file. If so, step S114 is executed; otherwise, step S115 is executed.

[0222] Step S114: Automatically collect abnormal data according to corresponding abnormal data collection rules.

[0223] Step S115: Request the cloud to send second configuration information, where the second configuration information includes abnormal data collection rules corresponding to abnormal event types that do not exist in the first configuration file, and add abnormal data collection rules corresponding to the abnormal event types in the first configuration file based on the second configuration information, and automatically collect abnormal data based on the added abnormal data collection rules.

[0224] Figure 8 It can be used as a complete flow chart of the data collection method of this application. Figure 8As shown, the data collection method can be implemented through steps S21 to S27.

[0225] Step S21: When the user manually reports an abnormality (such as Figure 8 S211 in the example) or business applications automatically discover anomalies (such as Figure 8 , execute the following step S22.

[0226] Step S22: The user feedback application or the business application calls the abnormal event feedback interface and sends parameter information (such as the abnormal event type) to the abnormal data collection service.

[0227] Step S23: The abnormal data collection service obtains a preset configuration file from the cloud server.

[0228] Step S24: The abnormal data collection service obtains a first configuration file according to a preset configuration file.

[0229] Step S25: The abnormal data collection service obtains corresponding abnormal data collection rules from the first configuration file according to the abnormal event type, and collects data according to the abnormal data collection rules.

[0230] Step S26: The abnormal data collection service obtains the corresponding abnormal data storage rule from the first configuration file according to the abnormal event type, and stores the collected data according to the abnormal data storage rule.

[0231] Step S27: Upload the collected data to the cloud server.

[0232] This application uses a system architecture that combines a set of core exception collection services with different business clients, and combines data upload, configuration update, and remote server on the device side to form a set of abnormal data collection methods for various services of terminal devices. Through flexible configuration control, a set of software can meet the user experience of users at different stages of the entire product life cycle. At the same time, the occasional anomalies or possible optimizations of various services generated during the operation of terminal devices can be located in a timely and rapid manner to avoid multiple recurrences of the problem.

[0233] Specifically, when identifying different life cycle stages of a device, first set the initial stage as the research stage; identify whether it is in the trial or mass production stage based on the device software version number; in particular, in the trial and mass production stages, the software version number is the same, and the trial or mass production stage can be identified by the hardware version number; finally, according to the different stages of automatic identification, the differentiated business demands of the corresponding stages are executed. In particular, in the trial and mass production stages, devices with the same software version can also update the differentiated business configurations of the corresponding stages of different device groups through the configuration information sent from the cloud.

[0234] It should be pointed out that although the various steps in the above embodiments are described in a specific order, those skilled in the art can understand that in order to achieve the effect of the present application, different steps do not have to be executed in such an order. They can be executed simultaneously (in parallel) or in other orders. These changes are within the scope of protection of the present application.

[0235] Furthermore, the present application also provides a data collection device.

[0236] See attached Fig. 9 , Fig. 9 It is a main structural block diagram of a data collection device according to an embodiment of the present application.

[0237] like Fig. 9 As shown, the data collection device in the embodiment of the present application mainly includes a first acquisition module 11, a receiving module 12, a second acquisition module 13 and a collection module 14. In some embodiments, one or more of the first acquisition module 11, the receiving module 12, the second acquisition module 13 and the collection module 14 can be combined into one module.

[0238] In some embodiments, the first acquisition module 11 may be configured to acquire a first configuration file, where the first configuration file includes an abnormal event and a corresponding abnormal data collection rule set.

[0239] The receiving module 12 may be configured to receive parameter information of an abnormal event.

[0240] The second acquisition module 13 may be configured to acquire the abnormal data collection rule corresponding to the abnormal event from the first configuration file based on the parameter information.

[0241] The collection module 14 may be configured to collect data based on the abnormal data collection rules.

[0242] In one implementation, the description of the specific implementation functions can refer to steps S10-S40.

[0243] The data collection device is used to perform Figure 1 The data collection method embodiments shown in the figure are similar in their technical principles, technical problems solved and technical effects produced. Technical personnel in this technical field can clearly understand that for the convenience and conciseness of description, the specific working process and related instructions of the data collection device can refer to the contents described in the embodiment of the data collection method, which will not be repeated here.

[0244] Further, it should be understood that since the setting of each module is only for illustrating the functional units of the device of the present application, the physical devices corresponding to these modules may be the processor itself, or a part of the software in the processor, a part of the hardware, or a part of the combination of software and hardware. Therefore, the number of each module in the figure is only schematic.

[0245] It is understood by those skilled in the art that each module in the device can be adaptively split or merged. Such splitting or merging of specific modules will not cause the technical solution to deviate from the principle of the present application, and therefore, the technical solutions after splitting or merging will fall within the protection scope of the present application.

[0246] It is understood by those skilled in the art that all or part of the processes in the method for implementing the above-mentioned embodiment of the present application can also be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable storage medium may include: any entity or device, medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory, random access memory, electrical carrier signal, telecommunication signal and software distribution medium, etc. that can carry the computer program code.

[0247] Furthermore, the present application also provides a terminal device, which may include at least one processor; and a memory connected to the at least one processor in communication; wherein a computer program is stored in the memory, and when the computer program is executed by the at least one processor, the data collection method described in any of the above embodiments is implemented. Fig.10 As shown, Fig.10 The structure of the terminal device is exemplarily shown in FIG. , which includes a processor 100 and a memory 200 .

[0248] Furthermore, the present application also provides a computer-readable storage medium. In a computer-readable storage medium embodiment according to the present application, the computer-readable storage medium can be configured to store a program for executing the data collection method of the above-mentioned method embodiment, and the program can be loaded and run by the processor to implement the above-mentioned data collection method. For ease of explanation, only the parts related to the embodiment of the present application are shown. For specific technical details not disclosed, please refer to the method part of the embodiment of the present application. The computer-readable storage medium can be a memory device formed by various electronic devices. Optionally, the computer-readable storage medium in the embodiment of the present application is a non-temporary computer-readable storage medium.

[0249] Furthermore, the present application also provides a data collection system, which includes the aforementioned terminal device and cloud device, wherein the cloud device is used to send preset configuration files and configuration information to the terminal device.

[0250] The relevant user personal information that may be involved in the various embodiments of this application is strictly in accordance with the requirements of laws and regulations, following the principles of legality, legitimacy and necessity, based on the reasonable purposes of business scenarios, to process the personal information that users actively provide during the use of products / services or generated due to the use of products / services, as well as the personal information obtained with the user's authorization.

[0251] The user personal information processed by this application will vary depending on the specific product / service scenario, and will be based on the specific scenario in which the user uses the product / service. It may involve the user's account information, device information, driving information, vehicle information or other related information. The applicant will treat the user's personal information and its processing with a high degree of diligence.

[0252] This application attaches great importance to the security of user personal information and has taken reasonable and feasible security protection measures that meet industry standards to protect user information and prevent personal information from being accessed, disclosed, used, modified, damaged or lost without authorization.

[0253] So far, the technical solutions of the present application have been described in conjunction with the specific implementations shown in the accompanying drawings, but it is easy for those skilled in the art to understand that the protection scope of the present application is obviously not limited to these specific implementations. Without departing from the principles of the present application, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will fall within the protection scope of the present application.

Claims

1. A data collection method, applied to a terminal device, characterized in that: The method comprises: Obtaining a first configuration file, wherein the first configuration file includes an abnormal event and a corresponding abnormal data collection rule set; Receive parameter information of abnormal events; Acquire, from the first configuration file, an abnormal data collection rule corresponding to the abnormal event based on the parameter information; Data is collected based on the abnormal data collection rules.

2. The data collection method according to claim 1, characterized in that: The obtaining of the first configuration file includes: Acquire device information of the terminal device; Determine the life cycle of the terminal device based on the device information; Obtaining a preset configuration file corresponding to the life cycle; The first configuration file is determined based on the preset configuration file.

3. The data collection method according to claim 2, characterized in that: The obtaining of a preset configuration file corresponding to the life cycle includes: Receive the preset configuration file from a cloud device; or The data is obtained from a file stored locally on the terminal device.

4. The data collection method according to claim 2, characterized in that: After determining the first configuration file based on the preset configuration file, the method further includes: Determine whether the cloud device sends the first configuration information; When the cloud device sends the first configuration information, the first configuration file is updated based on the first configuration information.

5. The data collection method according to claim 2, characterized in that: The device information includes software version number and hardware version number; The determining the life cycle of the terminal device based on the device information includes: When the software version number includes a trial identifier, the life cycle of the terminal device is in the trial stage; When the software version number includes a mass production identifier, determining whether the hardware version number includes a mass production identifier; if so, the life cycle is the mass production stage, otherwise it is the trial stage; When the software version number does not include a trial identifier and a mass production identifier, the life cycle is the research and development stage.

6. The data collection method according to claim 1, characterized in that: The parameter information includes the abnormal event type; The acquiring, from the first configuration file based on the parameter information, an abnormal data collection rule corresponding to the abnormal event includes: Determining whether the abnormal event type exists in the first configuration file; When the abnormal event type exists in the first configuration file, an abnormal data collection rule corresponding to the abnormal event is obtained from the first configuration file according to the abnormal event type.

7. The data collection method according to claim 6, characterized in that: The method comprises: When the abnormal event type does not exist in the first configuration file, requesting the cloud device to send second configuration information, the second configuration information including an abnormal data collection rule corresponding to the abnormal event type, the abnormal event type being an abnormal event type that does not exist in the first configuration file; Update the first configuration file according to the second configuration information.

8. The data collection method according to claim 1, characterized in that: The parameter information includes a data path; The collecting data based on the abnormal data collection rule includes: collecting data from the data path based on the abnormal data collection rule.

9. The data collection method according to claim 1, characterized in that: The first configuration file also includes an abnormal event and a set of abnormal data storage rules corresponding thereto; the method further includes: Acquire, from the first configuration file according to the parameter information, an abnormal data storage rule corresponding to the abnormal event; The collected data is stored according to the abnormal data storage rule.

10. The data collection method according to claim 9, characterized in that: The parameter information includes the abnormal event type; The acquiring the abnormal data storage rule corresponding to the abnormal event from the first configuration file based on the parameter information includes: Determining whether the abnormal event type exists in the first configuration file; When the abnormal event type exists in the first configuration file, the abnormal data storage rule corresponding to the abnormal event is obtained from the first configuration file according to the abnormal event type.

Images