Log collection system and method
Patent Information
- Application Number
- CN202511366647.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2025-09-18
- Filing Date
- 2025-09-23
- Publication Date
- 2026-10-09
AI Technical Summary
同时,也可避免或至少缓解因为发生单点故障(例如同时实现以上多个功能的ECU故障)而导致整个日志采集系统无法运行的问题
[0005]本申请的实施例主要提供了一种日志采集系统和方法,使得采集管理功能、采集触发功能与日志采集功能可分别由不同ECU实现,增强日志采集系统的灵活性与可扩展性,由此可实现日志的按需采集,避免因持续采集日志对日志采集系统性能和存储空间的影响。同时,也可避免或至少缓解因为发生单点故障(例如同时实现以上多个功能的ECU故障)而导致整个日志采集系统无法运行的问题。
Smart Images

Figure CN122884782A_ABST
Abstract
Description
Technical Field
[0001] This application relates to information transmission, and more specifically, to log collection systems and methods, computer-readable storage media, computer program products, and vehicles. Background Technology
[0002] With vehicles becoming increasingly intelligent, ensuring the functional stability of in-vehicle software has become even more crucial. Logs recorded during the operation of in-vehicle software are indispensable tools for locating and analyzing problems or defects in the software. These logs are continuously generated by the in-vehicle terminal running the software and are typically collected and stored locally by the terminal for further analysis.
[0003] However, the vehicle-mounted terminal running the in-vehicle software (e.g., the Electronic Control Unit (ECU)) may not have the storage capacity to store such continuously generated logs, especially when facing high-frequency, large-sample log collection, which can easily fail to meet log storage requirements and increase system overhead. Furthermore, a single point of failure may occur in the designated ECU used for log collection, rendering the entire log collection process impossible.
[0004] It should be noted that the information disclosed above is only used to enhance the understanding of the background technology of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention
[0005] The embodiments of this application primarily provide a log acquisition system and method, enabling the acquisition management function, acquisition triggering function, and log acquisition function to be implemented by different ECUs, thereby enhancing the flexibility and scalability of the log acquisition system. This allows for on-demand log acquisition, avoiding the impact of continuous log acquisition on the system's performance and storage space. Simultaneously, it also avoids or at least mitigates the problem of the entire log acquisition system failing to operate due to a single point of failure (e.g., a failure of an ECU simultaneously performing multiple functions).
[0006] According to one aspect of this application, a log collection system is provided, the log collection system comprising: a first subsystem configured to: receive a collection trigger event from a second subsystem of the log collection system, determine collection settings corresponding to the collection trigger event, and send a collection request, wherein the collection request includes at least a portion of the collection settings; and a third subsystem having the collection settings pre-received from the first subsystem, the third subsystem being configured to: The system receives the collection request from the first subsystem, determines the collection method corresponding to the at least part of the collection settings based on the at least part of the collection settings, and collects logs according to the collection method.
[0007] In one or more embodiments of this application, optionally, the second subsystem is configured to: receive a collection setting update event from the first subsystem and update the collection triggering conditions according to the collection setting update event; when the collection triggering conditions are met, send the collection triggering event to the first subsystem, wherein the collection triggering event indicates that the vehicle information service running in the second subsystem has been interrupted.
[0008] Optionally, in one or more embodiments of this application, the log collection system further includes a fourth subsystem, wherein the log is generated by a fifth subsystem, and the third subsystem is further configured to: after completing the collection of the log generated by the fifth subsystem, store the collected log in the fourth subsystem, and send a collection completion event to the first subsystem.
[0009] In one or more embodiments of this application, optionally, the first subsystem is further configured to: in response to receiving the collection completion event from the third subsystem, send an upload request to the fourth subsystem to upload the collected logs stored in the fourth subsystem to the cloud service platform.
[0010] In one or more embodiments of this application, optionally, the data collection triggering condition includes the duration of interruption of the vehicle information service exceeding a threshold duration, and the data collection setting includes the time interval for sending the data collection triggering event and the duration for sending the data collection triggering event according to the trigger interval.
[0011] In one or more embodiments of this application, optionally, the at least partial collection settings include the name of the log, the collection method is associated with the name of the log, and the collection settings include the name of the log and the collection method.
[0012] According to one aspect of this application, a log collection method is provided, the log collection method being applied to a log collection system, the log collection system including a first subsystem, a second subsystem, and a third subsystem, the log collection method comprising: the first subsystem receiving a collection trigger event from the second subsystem; the first subsystem determining collection settings corresponding to the collection trigger event and sending a collection request, wherein the collection request includes at least a portion of the collection settings; the third subsystem receiving the collection request from the first subsystem; and, based on the at least a portion of the collection settings, the third subsystem determining a collection mode corresponding to the at least a portion of the collection settings, and collecting logs according to the collection mode, wherein the third subsystem has the collection settings received in advance from the first subsystem.
[0013] In one or more embodiments of this application, optionally, the log collection method further includes: the second subsystem receiving a collection setting update event from the first subsystem, and updating the collection triggering conditions according to the collection setting update event; when the collection triggering conditions are met, the second subsystem sending the collection triggering event to the first subsystem, wherein the collection triggering event indicates that the vehicle information service running in the second subsystem has been interrupted.
[0014] Optionally, in one or more embodiments of this application, the log collection system further includes a fourth subsystem, the logs are generated by a fifth subsystem, and the log collection method further includes: after the third subsystem completes the collection of the logs generated by the fifth subsystem, it stores the collected logs in the fourth subsystem and sends a collection completion event to the first subsystem.
[0015] In one or more embodiments of this application, optionally, the log collection method further includes: in response to receiving the collection completion event from the third subsystem, the first subsystem sends an upload request to the fourth subsystem to upload the collected logs stored in the fourth subsystem to a cloud service platform.
[0016] In one or more embodiments of this application, optionally, the data collection triggering condition includes the duration of interruption of the vehicle information service exceeding a threshold duration, and the data collection setting includes the time interval for sending the data collection triggering event and the duration for sending the data collection triggering event according to the trigger interval.
[0017] In one or more embodiments of this application, optionally, the at least partial collection settings include the name of the log, the collection method is associated with the name of the log, and the collection settings include the name of the log and the collection method.
[0018] According to one aspect of this application, a computer-readable storage medium is provided, wherein instructions are stored therein, which, when executed by a processor, cause any of the log collection methods described above to be implemented.
[0019] According to one aspect of this application, a computer program product is provided, the computer program product including computer instructions that, when executed by a processor, implement any of the log collection methods described above.
[0020] According to one aspect of this application, a vehicle is provided, the vehicle including any of the log collection systems described above. Attached Figure Description
[0021] The above and other features, aspects, and advantages of this application will become better understood when the following detailed description is read with reference to the accompanying drawings, in which the same or similar elements are indicated by the same reference numerals. It should be noted that the drawings in this application are merely schematic and may not be drawn to scale or in specific quantities. In the drawings: Figure 1 A log collection system according to one or more embodiments of this application is shown; Figure 2 An exemplary embodiment of the log collection system is shown; Figure 3 This application illustrates a log collection method according to one or more embodiments. Detailed Implementation
[0022] The present application will now be described more fully with reference to the accompanying drawings, which illustrate illustrative embodiments thereof. In the following detailed description of the embodiments, numerous specific details are set forth in order to provide a more thorough understanding of the disclosures herein. However, in one or more embodiments, well-known features have not been described in detail to avoid unnecessarily complicating the description. Where applicable, embodiments of the present application and features thereof may be combined with each other.
[0023] In this application, terms such as “comprising,” “including,” and “having” indicate that, in addition to the units and steps that are directly and explicitly stated in the specification and claims, the technical solution described in this application may also include other units and steps that are not directly or explicitly stated.
[0024] Unless otherwise specified, terms such as “first” and “second” do not indicate the order of the elements they modify in terms of time, space, size, etc., nor are they intended to limit any element they modify to a single element, but are merely used to distinguish the elements.
[0025] In this application, the cloud service platform can be a remote server that communicates with the vehicle via a wireless network. The cloud service platform provides its users with log collection configuration interfaces and collection trigger configuration interfaces for detailed log collection settings and trigger configuration. For example, registered users of the cloud service platform can create log collection tasks for specific vehicles for which log collection is desired, and configure the log collection tasks, such as setting the type of logs to be collected, the trigger method, and the log upload method. The cloud service platform can also store logs uploaded from the vehicle.
[0026] Figure 1 A log acquisition system 100 according to one or more embodiments of this application is illustrated. The log acquisition system 100 is deployed in a vehicle. The log acquisition system 100 is programmed to implement at least four software functions, specifically management, triggering, acquisition, and storage and uploading functions. These software functions can be implemented by one or more subsystems of the log acquisition system 100 that can operate independently of each other. The electronic control unit (ECU) (or other general-purpose or special-purpose electronic device, for example, with signal processing and communication capabilities) in the vehicle can be programmed to form the one or more subsystems. For example, any ECU can be selected from a plurality of suitable ECUs in the vehicle (e.g., with desired computing and / or storage capabilities) to be configured as multiple subsystems to implement all of these software functions; multiple (e.g., four) suitable ECUs can also be selected to be configured as corresponding multiple (e.g., four) subsystems, each implementing one or more of these software functions.
[0027] like Figure 1 As shown, the log collection system 100 includes a first subsystem 110, a second subsystem 120, a third subsystem 130, a fourth subsystem 140, and a fifth subsystem 150. It should be noted that, although... Figure 1Five subsystems are shown, but the number of subsystems may be less than or more than five, and this application does not limit this. In this application, the log collection system 100 may include only one first subsystem 110 to maintain direct management of the entire log collection system 100. Any two subsystems of the first to fifth subsystems 110-150 can be connected and communicate with each other through an in-vehicle communication network (e.g., in-vehicle Ethernet and corresponding Ethernet switches), and one or more subsystems of the first to fifth subsystems 110-150 can communicate with a cloud service platform through a network access device (NAD) via, for example, a 4G and / or 5G cellular network. Among these subsystems, the first to fourth subsystems 110-140 can be configured to respectively implement the aforementioned management functions, triggering functions, collection functions, and storage and uploading functions, and the fifth subsystem is the subsystem that provides the log source (i.e., generates the logs to be collected), which will be described in detail below.
[0028] The first subsystem 110 manages log collection within the log collection system 100. It can receive log collection setting update tasks and publish log collection setting update events via the in-vehicle communication network based on these tasks. The log collection setting update task can be created by a user of the cloud service platform for a vehicle where log collection is desired (e.g., a designated vehicle undergoing software service diagnostics) and updates the current log collection settings (e.g., the default log collection settings). The updated log collection settings can be published by the first subsystem 110 to other subsystems in the log collection setting update event. The first subsystem 110 can also receive log collection trigger events and, based on these events, request other subsystems to complete log collection and upload the collected logs.
[0029] The second subsystem 120 monitors the software services running within the log collection system 100 and determines whether to trigger log collection. Specifically, the second subsystem 120 runs an in-vehicle information service and monitors its operating status. The in-vehicle information service may include positioning (e.g., satellite positioning) services and network (e.g., cellular network) services. The second subsystem 120 can subscribe to the first subsystem 110 to receive collection setting update events, thereby obtaining updated log collection settings, which include, for example, collection trigger conditions. When an abnormal operating status of the in-vehicle information service is detected, the second subsystem 120 can determine whether the current operating status meets the collection trigger conditions, and send a collection trigger event when the collection trigger conditions are met, so as to trigger the third subsystem 130 to collect the corresponding logs generated on the fifth subsystem 150 (e.g., logs corresponding to the log names in the log collection settings).
[0030] The third subsystem 130 performs log collection within the log collection system 100. Similarly, it can subscribe to the first subsystem 110 to receive collection setting update events. Upon receiving a collection request transmitted via the in-vehicle communication network, it collects the corresponding logs generated by the fifth subsystem 150 when the in-vehicle information service is malfunctioning, based on the updated log collection settings in the collection setting update event. Upon completion of collection, the collected logs can be packaged and uploaded to the cloud service platform via NAD, or they can be packaged and transmitted via the in-vehicle communication network. Therefore, if the storage space in the ECU configured as the third subsystem 130 for storing the collected logs is insufficient, other ECUs can be used to complete the storage and uploading of the collected logs.
[0031] The fourth subsystem 140 stores and uploads the collected logs within the log collection system 100. The fourth subsystem 140 receives the collected logs transmitted via the in-vehicle communication network and temporarily stores them locally. Upon receiving a log upload request, it uploads the stored logs corresponding to that request via, for example, a 4G and / or 5G cellular network.
[0032] The fifth subsystem 150 provides log sources in the log collection system 100 for the third subsystem 130 to collect.
[0033] The following will combine Figure 2 To describe an exemplary embodiment 200 of the log collection system 100. For example... Figure 2 As shown, in this exemplary embodiment, the log collection system 100 performs operations 202 to 218.
[0034] In operation 202, the first subsystem 110 is configured to receive a data collection setting update task sent by the cloud service platform via a cellular network, such as 4G and / or 5G, through a NAD, and publish a data collection setting update event via the in-vehicle communication network based on the data collection setting update task. One or more data collection setting update tasks may be created by users of the cloud service platform for vehicles for which log collection is desired, and received by the first subsystem 110 in the form of a task list containing these data collection setting update tasks to update the current log collection settings. The updated log collection settings may be published by the first subsystem 110 to the second subsystem 120 and the third subsystem 130 in the data collection setting update event.
[0035] In one or more embodiments, the user of the cloud service platform determines the subsystem implementing the data collection function in the data collection setting update task through the log collection setting interface provided by the cloud service platform. For example, any ECU among multiple ECUs in the vehicle can be selected and configured as a third subsystem 130 to implement the data collection function. The user can also determine the subsystem implementing the triggering function in the data collection setting update task through the data collection triggering setting interface provided by the cloud service platform. For example, any ECU among multiple ECUs in the vehicle can be selected and configured as a second subsystem 120 to implement the triggering function. Furthermore, the user can also select any ECU among multiple ECUs in the vehicle to configure it to simultaneously implement both the data collection and triggering functions.
[0036] Furthermore, users can configure detailed log collection settings through the log collection configuration interface, generating a log collection configuration file that records these detailed settings. This log collection configuration file is subscribed to by the first, second, and third subsystems 110-130. Specifically, the log collection configuration file may include the name of the ECU configured as the third subsystem 130 and a set of the following items: the log name of the type of log to be collected (e.g., logs generated by the baseband circuit of NAD), the name of the ECU configured to store and upload this type of log and the corresponding log storage method (e.g., log storage path), the collection trigger method, and the log collection method.
[0037] The data collection triggering method can be a set of trigger sources and trigger conditions that define the triggering of this type of log. This set defines the ECU of the second subsystem 120 configured to trigger the collection of this type of log, the trigger source (which can be a service running in the second subsystem 120, such as the location service in an in-vehicle information service), the service interruption duration (the service interruption duration exceeding a threshold duration allows the second subsystem 120 to determine that a service interruption has occurred and send a data collection trigger event indicating the service interruption), the trigger interval (the time interval at which the second subsystem 120 sends the data collection trigger event, such as a minimum set value for the time interval), and the trigger duration (the duration for which the second subsystem 120 sends the data collection trigger event according to the trigger interval, such as a maximum set value for the duration). Adjusting the trigger interval can adjust the log collection frequency to, for example, avoid an excessively high collection frequency that causes the throughput of the collected log data to exceed a throughput threshold. Correspondingly, adjusting the trigger duration can adjust the log collection duration to, for example, avoid an excessively long collection duration that causes the amount of collected log data to exceed a corresponding storage space threshold.
[0038] Similarly, the log collection method can be a set of log collection parameters defined for collecting this type of log. This set defines the collection duration (the duration of a single collection, such as the maximum duration of a single collection). Optionally, this set also includes filter configurations (the network download address of the filter used in this single collection, allowing the third subsystem 130 to download the filter file via this network download address) and predefined static collection parameters on the cloud service platform, such as the collection size (the size of the log file in this single collection, such as the maximum log file size), the collection interface (the name of the network interface in this single collection), and the collection port (the name of the network port in this single collection). The third subsystem 130 can dynamically adjust collection parameters not predefined on the cloud service platform as needed by downloading the filter file.
[0039] Furthermore, users can configure the log collection trigger in detail through the collection trigger setting interface provided by the cloud service platform, generating a collection trigger configuration file that records the detailed settings and the name of the ECU configured as the second subsystem 120. This collection trigger configuration file is subscribed to by the first subsystem 110. Specifically, the detailed settings can be recorded in the form of code blocks in a list associated with the collection trigger event. This list includes an identifier for the collection trigger event indicating a service interruption running in the second subsystem 120 (the identifier of the collection trigger event uniquely identifies the collection trigger event), a descriptor for the collection trigger event (describing the type of the collection trigger event, such as network service interruption, location service interruption, etc.), and a log type set. The log type set defines the log type of the log to be collected corresponding to the collection trigger event in set form. Each element in the set can be a key-value pair, which includes the name of the ECU configured as the third subsystem 130 for implementing the collection function and the log name. Because of the uniqueness of the identifier for the trigger event, the identifier can be used to determine the set of log types in the list in which the identifier is located, and then to determine the ECU configured as the third subsystem 130 among multiple ECUs and the corresponding log collection method.
[0040] The log collection configuration file and collection trigger configuration file generated through the log collection setting interface and collection trigger setting interface, respectively, both include the log name and the name of the ECU configured as the third subsystem 130, and are associated through this log name and the name of the ECU configured as the third subsystem 130. Based on the log name, collection trigger method (including the name of the ECU configured as the second subsystem 120) and log collection method (including the name of the ECU configured as the third subsystem 130) in the same set of the log collection configuration file, the log type, corresponding collection method, and storage method of the log collected when a certain collection trigger event is issued by the second subsystem 120 are uniquely determined (and the corresponding ECU that performs the collection and storage functions is also determined).
[0041] Next, in operation 204, the second subsystem 120 can be configured to receive a data collection setting update event from the first subsystem 110 via the in-vehicle communication network, thereby obtaining updated log collection settings, which include the set of data collection triggering methods described above. The second subsystem 120 can update the locally stored default trigger source and triggering conditions to the trigger source and triggering conditions defined in this set (including service interruption duration, trigger interval, and trigger duration).
[0042] Synchronously or asynchronously with the second subsystem 120 receiving a collection setting update event from the first subsystem 110, the third subsystem 130 may receive a collection setting update event from the first subsystem 110 during operation 204 to obtain updated log collection settings. These updated log collection settings include the set of log collection methods described above. The third subsystem 130 may update the locally stored default log collection parameters to optional collection parameters defined in this set, such as collection duration, filter configuration, collection volume, collection interface, and collection port.
[0043] Next, in operation 206, the second subsystem 120 can be configured to send a data acquisition trigger event to the first subsystem 110 via the in-vehicle communication network when the data acquisition trigger condition is met. When an abnormal operating status of a service running on it is detected, the second subsystem 120 determines whether the current operating status meets the data acquisition trigger condition. Specifically, if the service interruption duration of the running in-vehicle information service exceeds a threshold duration, the second subsystem 120 sends a data acquisition trigger event indicating service interruption to the first subsystem 110, including an identifier for sending the data acquisition trigger event.
[0044] Next, in operation 208, the first subsystem 110 can be configured to receive the data acquisition trigger event from the second subsystem 120 via the in-vehicle communication network and determine the log acquisition settings corresponding to the data acquisition trigger event. The first subsystem 110 can retrieve the data acquisition setting update task corresponding to the data acquisition trigger event from the task list containing one or more data acquisition setting update tasks described in operation 202 by using the identifier of the data acquisition trigger event, and then obtain the log acquisition settings in the data acquisition setting update task.
[0045] Next, in operation 210, the first subsystem 110 can be configured to send a log collection request to the third subsystem 130 via an in-vehicle communication network. The log collection request includes at least some of the collection settings in the log collection settings, such as the log name.
[0046] Next, in operation 212, the third subsystem 130 can be configured to receive the log collection request from the first subsystem 110 via the in-vehicle communication network, determine the collection method according to at least some of the collection settings in operation 210, and collect the logs generated by the fifth subsystem 150 according to the collection method. In operation 204, the third subsystem 130 receives a collection setting update event from the first subsystem 110 in advance and thus obtains the updated log collection settings, which include the aforementioned set containing log names and log collection methods. In operation 212, the third subsystem 130 can determine the set containing the log name and the corresponding log collection method based on the received log name. Therefore, the third subsystem 130 collects the corresponding logs generated by the fifth subsystem 150 according to the determined log collection method, such as collection duration and collection parameters like filter configuration, collection volume, collection interface, and collection port, and according to one or more of these collection parameters.
[0047] In the above operations, the first subsystem 110, the second subsystem 120, and the third subsystem 130 can be configured from any suitable ECU in the vehicle to respectively implement the data acquisition management function, the data acquisition triggering function, and the log acquisition function. For example, if one ECU malfunctions and cannot be configured as the second subsystem 120, another ECU can be configured as the second subsystem 120, allowing the data acquisition triggering function to function normally. This can avoid or at least mitigate the problem of the entire log acquisition system 100 failing to operate due to a single point of failure (such as the failure of an ECU that simultaneously performs multiple functions).
[0048] Next, in operation 214, the third subsystem 130 can be configured to package the collected logs and send them to the fourth subsystem 140 via the in-vehicle communication network after the collection is completed according to the set collection parameters such as collection duration. The fourth subsystem 140 can be configured to store the logs locally according to the storage path. The third subsystem 130 is also configured to send a collection completion event to the first subsystem 110 after sending the collected logs to the fourth subsystem 140, indicating that the log collection has been completed according to the updated log collection settings.
[0049] Next, in operation 216, the first subsystem 110 can be configured to send an upload request (including log name) to the fourth subsystem 140 via the in-vehicle communication network after receiving the data collection completion event sent from the third subsystem 130, instructing the fourth subsystem 140 to upload the stored logs to the cloud service platform for storage.
[0050] Next, in operation 218, the fourth subsystem 140 can be configured to upload the stored logs to the cloud service platform via the cellular network after receiving an upload request from the first subsystem 110 via the in-vehicle communication network. Users can configure the log upload mode so that the collected logs are uploaded in real-time in response to a collection trigger event or uploaded to the cloud service platform for storage according to a preset upload cycle. For example, when the cellular network service is currently unavailable, an upload can be attempted according to a preset upload cycle to complete the upload when the cellular network service is restored. Furthermore, the fourth subsystem 140 can also be configured to send an upload completion message (including the log name) to the first subsystem 110 after the upload is completed. The fourth subsystem 140 can also be configured to delete the aforementioned stored logs stored locally after receiving a message from the cloud service platform indicating successful upload.
[0051] During the aforementioned operation, the second subsystem 120 periodically sends collection trigger events to the first subsystem 110 at trigger intervals, causing the logs to be periodically collected by the third subsystem 130 at the same trigger intervals. When the trigger duration is reached (i.e., the maximum set value for the duration of periodically sending collection trigger events at trigger intervals), the second subsystem 120 stops monitoring the service status of the running service and stops sending collection trigger events until the service resumes operation, thereby avoiding various resource consumptions caused by continuous collection, such as storage space consumption.
[0052] Figure 3 A log collection method 300 according to one or more embodiments of this application is shown, which can be implemented by a log collection system 200. The log collection method 300 includes steps 302-318.
[0053] In step 302, the first subsystem may receive a data collection setting update task sent by the cloud service platform via NAD through, for example, a 4G and / or 5G cellular network, and publish a data collection setting update event via the in-vehicle communication network based on the data collection setting update task. In one or more embodiments, the cloud service platform, the data collection setting update task, and the data collection setting update event may be implemented using... Figure 2 The corresponding cloud service platform, data collection and setting update task, and data collection and setting update event are described, and the execution process of step 302 is similar to that of operation 202, so it will not be described again here.
[0054] In step 304, the second subsystem may receive a data collection setting update event from the first subsystem via the in-vehicle communication network, thereby obtaining updated log collection settings, which include a set of data collection triggering methods. In one or more embodiments, the data collection triggering method here may be achieved by means of... Figure 2 The acquisition triggering method is described here, and the execution process of step 304 is similar to that of operation 204, so it will not be described again here.
[0055] In step 306, when the acquisition triggering condition is met, the second subsystem may send an acquisition triggering event to the first subsystem via the in-vehicle communication network. In one or more embodiments, the acquisition triggering condition and acquisition triggering event here may be achieved by means of... Figure 2 The corresponding acquisition triggering conditions and acquisition triggering events are described, and the execution process of step 306 is similar to that of operation 206, so it will not be described again here.
[0056] In step 308, the first subsystem may receive the data collection trigger event from the second subsystem via the in-vehicle communication network and determine the log collection settings corresponding to the data collection trigger event. In one or more embodiments, the execution process of step 308 may be similar to the execution process of operation 208, and will not be described again here.
[0057] In step 310, the first subsystem may send a log collection request to the third subsystem via the in-vehicle communication network. The log collection request includes at least a portion of the collection settings in the log collection settings. In one or more embodiments, the execution process of step 310 may be similar to the execution process of operation 210, and will not be described again here.
[0058] In step 312, the third subsystem may receive the log collection request from the first subsystem via the in-vehicle communication network, determine the collection method according to the at least partial collection settings, and collect the logs generated by the fifth subsystem according to the collection method. In one or more embodiments, the execution process of step 312 may be similar to the execution process of operation 212, and will not be described again here.
[0059] In step 314, after the data collection is completed according to the set collection duration and other parameters, the third subsystem can package the collected logs and send them to the fourth subsystem via the in-vehicle communication network. In one or more embodiments, the execution process of step 314 may be similar to that of operation 214, and will not be described again here.
[0060] In step 316, after receiving the data acquisition completion event from the third subsystem, the first subsystem may send an upload request to the fourth subsystem via the in-vehicle communication network. In one or more embodiments, the execution process of step 316 may be similar to that of operation 216, and will not be described again here.
[0061] In step 318, after receiving the upload request from the first subsystem via the in-vehicle communication network, the fourth subsystem uploads the stored logs to the cloud service platform via the cellular network. In one or more embodiments, the execution process of step 318 may be similar to that of operation 218, and will not be described again here.
[0062] Those skilled in the art will appreciate that some or all of the steps may be combined or omitted, and that some or all of the steps may be performed in parallel, and that additional steps may be performed further. Therefore, the scope of this disclosure should not be considered limited to [specific steps not provided in the original text]. Figure 3 The specific arrangement of the steps shown.
[0063] According to another aspect of this application, a vehicle is also provided, which includes the log collection system as described above. This application does not limit the vehicle's layout (e.g., wheeled vehicle, tracked vehicle, etc.) or its driving force (e.g., electric vehicle, hybrid vehicle, gasoline-powered vehicle, gas-powered vehicle, etc.).
[0064] According to another aspect of this application, a computer-readable storage medium is also provided, on which instructions are stored, which, when executed by a processor, can realize the above-mentioned functions. Figure 3 The method includes one or more steps.
[0065] According to another aspect of this application, a computer program product is also provided, the computer program product comprising computer instructions, which, when executed by a processor, can implement the above-mentioned... Figure 3 The method includes one or more steps.
[0066] The processor mentioned in this application can be an integrated circuit chip with signal processing capabilities. In the implementation process, the above utilizes... Figure 3One or more steps included in the method can be implemented by integrated logic circuitry in the processor hardware or by instructions in software. The processor described above can be a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor.
[0067] The term "computer-readable storage medium" as used in this application includes various types of computer storage media, and can be any available medium accessible to a general-purpose or special-purpose computer. For example, a computer-readable storage medium may include RAM, ROM, EPROM, E2PROM, registers, hard disk, removable disk, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage device, or any other temporary or non-temporary medium capable of carrying or storing desired program code units in the form of instructions or data structures and accessible by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Combinations of the above should also be included within the scope of protection of computer-readable storage media. An exemplary storage medium is coupled to a processor so that the processor can read and write information from / to the storage medium. In an alternative, the storage medium may be integrated into the processor.
[0068] It should be noted that the embodiments described in this application are intended to make the disclosure herein comprehensive and complete, and are not intended to limit the scope of the claimed subject matter. Those skilled in the art can conceive of other possible variations or substitutions based on the technical scope disclosed in this application, and such variations or substitutions are all covered within the protection scope of this application. Those skilled in the art will understand that the above descriptions and examples are provided for ease of illustration and example only, and are not intended to cover all aspects of this application or to limit this application to the precise form disclosed. The technical solutions described in this application can be implemented in different forms without departing from the spirit and scope of this application.
Claims
1. A log collection system, the log collection system comprising: The first subsystem is configured as follows: Receive collection trigger events from the second subsystem of the log collection system. Determine the acquisition settings corresponding to the acquisition trigger event and send an acquisition request, wherein the acquisition request includes at least a portion of the acquisition settings; A third subsystem, having the acquisition settings pre-received from the first subsystem, is configured to: Receive the collection request from the first subsystem. Based on the at least partial collection settings, a collection method corresponding to the at least partial collection settings is determined, and logs are collected according to the collection method.
2. The log collection system as described in claim 1, wherein, The second subsystem is configured as follows: Receive the data collection setting update event from the first subsystem, and update the data collection triggering conditions according to the data collection setting update event; When the data collection triggering condition is met, the data collection triggering event is sent to the first subsystem, wherein the data collection triggering event indicates that the vehicle information service running in the second subsystem has been interrupted.
3. The log collection system as described in claim 1, further comprising a fourth subsystem, wherein, The log is generated by the fifth subsystem, and the third subsystem is further configured to: After collecting the logs generated by the fifth subsystem, the collected logs are stored in the fourth subsystem, and a collection completion event is sent to the first subsystem.
4. The log collection system as described in claim 3, wherein, The first subsystem is also configured to: In response to receiving the data collection completion event from the third subsystem, an upload request is sent to the fourth subsystem to upload the collected logs stored in the fourth subsystem to the cloud service platform.
5. The log collection system as described in claim 2, wherein, The data collection triggering conditions include the duration of interruption of the vehicle information service exceeding a threshold duration, and the data collection settings include the time interval for sending the data collection triggering event and the duration for sending the data collection triggering event according to the trigger interval.
6. The log collection system as described in claim 1, wherein, The at least partial collection settings include the name of the log, the collection method is associated with the name of the log, and the collection settings include the name of the log and the collection method.
7. A log collection method, wherein the log collection method is applied to a log collection system, the log collection system comprising a first subsystem, a second subsystem, and a third subsystem, the log collection method comprising: The first subsystem receives the acquisition trigger event from the second subsystem; The first subsystem determines the acquisition settings corresponding to the acquisition trigger event and sends an acquisition request, wherein the acquisition request includes at least a portion of the acquisition settings; The third subsystem receives the acquisition request from the first subsystem; Based on the at least partial collection settings, the third subsystem determines a collection method corresponding to the at least partial collection settings and collects logs according to the collection method, wherein the third subsystem has the collection settings received in advance from the first subsystem.
8. A computer-readable storage medium storing instructions, characterized in that, When executed by the processor, the instruction causes the log collection method as described in claim 7 to be implemented.
9. A computer program product, the computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the log collection method as described in claim 7.
10. A vehicle, characterized in that, The vehicle includes a log collection system as described in any one of claims 1 to 6.