System and method for handling over-the-air event logs

Abstract

A system and method for handling event logs over-the-air. [Solution] A method, system, and apparatus are provided for handling event logs over-the-air. The method may include: a first handler object receiving a first log request to a first event log for a first event class, which originates from a main logger object, wherein the first log request includes a first event object for the first event class and the first event log is stored in persistent storage; and a handler object sending a first write request to a storage object to write the first event object to the first event log, wherein upon receiving the first write request, the storage object is configured to serialize the first event object and write the serialized first event object to the first event log.

Description

Technical Field

[0001] Embodiment examples of the present disclosure are related to over-the-air (OTA) communication and, in particular, to event logging of OTA events.

Background Art

[0002] In the prior art, events related to over-the-air (OTA) communication can be received. Such OTA events can be logged for troubleshooting and compliance-related uses. Further, there can be different types of events such as related communication logs, related operations, related anomalies, and events for debugging.

[0003] In the prior art, the method for handling different types of events for logging may not have been clear. In particular, even if different types of events can have different formats, different types of events can be handled using the same event log.

[0004] Furthermore, prior art systems may typically use a single handler object that occupies a single thread, which may not be efficient from the perspective of processing when multiple events can be received simultaneously. Further, since there is a possibility of exceeding the memory allocated during logging, problems can occur in handling the storage for the event log.

[0005] Therefore, there is a need for a more efficient system for handling different types of OTA events for logging.

Summary of the Invention

[0006] Embodiments consistent with this disclosure provide processes for more efficient handling of OTA event logs. In particular, apparatus and methods according to embodiments include receiving a first log request to a first event log for a first event class, which originates from a main logger object, by a first handler object, wherein the first log request comprises a first event object for the first event class and the first event log is stored in persistent storage, and sending a first write request by a handler object to a storage object for writing the first event object to the first event log, wherein upon receiving the first write request, the storage object is configured to serialize the first event object and write the serialized first event object to the first event log.

[0007] In one embodiment, a method for handling event log entries may be provided. The method may include a first handler object receiving a first log request to a first event log for a first event class, which originates from a main logger object, wherein the first log request comprises a first event object for the first event class and the first event log is stored in persistent storage, and a handler object to a storage object sending a first write request to write the first event object to the first event log, wherein upon receiving the first write request, the storage object is configured to serialize the first event object and write the serialized first event object to the first event log.

[0008] The method may include: a second handler object receiving a second log request originating from a main logger object for a second event log for a second event class different from a first event class, wherein the second log request comprises a second event object of the second event class and the second event log is stored in persistent storage; and a second handler object sending a second write request to a storage object to write the second event object to the second event log, wherein upon receiving the second write request, the storage object is configured to serialize the second event object and write the serialized second event object to the second event log.

[0009] The storage object may be configured to reset the read pointer for the first event log when it receives a read start request originating from the main logger object. The storage object may also be configured to return the event object corresponding to the read pointer in the first event log to the main logger object in JSON format when it receives a read request originating from the main logger object.

[0010] The first event log may be formatted as a first-in-first-out (FIFO) buffer, and the storage object is configured to write serialized first event objects to the first event log by overwriting the oldest entry in the first event log if the first event log is full.

[0011] In one embodiment, the method may further include, by a first handler object, receiving a debug log request containing a debug trace originating from a main logger object, and by the first handler object, returning the debug trace to an output stream. The first handler object, the second handler object, and the storage object may be instantiated by the main logger object.

[0012] In one embodiment, a device for handling event log entries may be provided. The device may include at least one memory for storing computer executable instructions and at least one processor, the at least one processor being configured to execute computer executable instructions to receive by a first handler object a first log request to a first event log for a first event class, which originates from a main logger object, the first log request comprising a first event object for a first event class and the first event log being stored in persistent storage, and a handler object to a storage object sending a first write request to write the first event object to the first event log, the storage object being configured to serialize the first event object and write the serialized first event object to the first event log upon receiving the first write request.

[0013] In one embodiment, the processor may be further configured to execute a computer executable instruction to receive a second log request originating from a main logger object, by a second handler object, for a second event log for a second event class different from a first event class, wherein the second log request comprises a second event object of the second event class and the second event log is stored in persistent storage, and to send a second write request by a second handler object to a storage object for writing the second event object to the second event log, wherein upon receiving the second write request, the storage object is configured to serialize the second event object and write the serialized second event object to the second event log.

[0014] In one embodiment, the processor may be configured to execute a computer executable instruction to receive a debug log request by a first handler object, which includes a debug trace originating from a main logger object, and to return the debug trace to an output stream by the first handler object.

[0015] Additional embodiments may be partially revealed in the description below, partially evident from the description, or realized by the practice of the embodiments expressed in the disclosure. [Brief explanation of the drawing]

[0016] The features, advantages and importance of the exemplary embodiments of the disclosure are described below with reference to the accompanying drawings, where similar reference numerals in the accompanying drawings refer to similar elements. [Figure 1] Figure 1 shows a block diagram of an example of the components of a system that handles OTA event logging according to one or more embodiments. [Figure 2]Figure 2 shows an example of a call flow diagram for initializing a system according to one or more embodiments. [Figure 3] Figure 3 shows an example of a call flow diagram for reading and writing events according to one or more embodiments. [Figure 4] Figure 4 shows an example of a method for writing to multiple event logs according to one or more embodiments. [Figure 5] Figure 5 shows an example of system components that may be configured to perform one or more embodiments. [Modes for carrying out the invention]

[0017] A detailed description of the following exemplary embodiments will be made with reference to the accompanying drawings. The foregoing disclosure provides drawings and descriptions, but is not intended to be exhaustive or to limit embodiments to the exact forms disclosed. Modifications and changes are possible in light of the foregoing disclosure and can be obtained from the implementation of embodiments. Furthermore, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). In addition, it will be understood that in the flowcharts and descriptions of operations provided below, one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part), and the order of one or more operations may be changed.

[0018] Even if specific combinations of features are listed in the claims and / or described in the specification, these combinations are not intended to limit the disclosure of possible embodiments. In fact, many of these features can be combined in ways not specifically listed in the claims and / or described in the specification. Each of the dependent claims listed below is directly dependent on only one claim, but the disclosure of possible embodiments includes each dependent claim in combination with all other claims in the claims.

[0019] Any element, action, or instruction used herein should not be construed as important or essential unless explicitly stated otherwise. Furthermore, the articles “a” and “an,” as used herein, are intended to include one or more items and may be used interchangeably with “one or more.” Where only one item is intended, the term “one” or a similar expression should be used. Also, in this specification, terms such as “have,” “include,” etc., are intended to be open-ended. Furthermore, the phrase “based on it” is intended to mean “at least, based on it,” unless otherwise explicitly stated. Additionally, expressions such as "[A] and / or [B]," “at least one of [A] and [B],” or “at least one of [A] or [B]” should be understood as including only A, only B, or both A and B.

[0020] Expressions such as "at least one processor" configured to perform multiple operations or execute multiple instructions should be understood as either a single processor performing multiple operations, or each of multiple processors performing at least some (but not necessarily all) of multiple operations.

[0021] Any references to “one embodiment,” “a certain embodiment,” “an exemplary embodiment not to limit,” or similar phrases found throughout this specification mean that any specific features, structures, or characteristics described in relation to the embodiments shown are included in at least one embodiment of the present solution. Therefore, the phrases “in one embodiment,” “a certain embodiment,” “an exemplary embodiment not to limit,” and similar phrases found throughout this specification may, but do not necessarily, refer to the same embodiment.

[0022] Furthermore, the features, advantages, and characteristics of the present disclosure described may be combined in any suitable manner in one or more embodiments. Those skilled in the art will recognize, in light of the description herein, that the present disclosure may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features or advantages may be recognized in certain embodiments that may not be present in all embodiments of the present disclosure.

[0023] Furthermore, the term "vehicle" as described herein refers to any suitable type of vehicle that can be implemented in embodiments of the present disclosure. For example, "vehicle" may refer to a car, truck, bus, motorcycle, or any other suitable type of motor vehicle powered by an engine, motor, or other mechanical means. Alternatively or additionally, the "vehicle" as described herein may refer to a bicycle, skateboard, and any other suitable type of non-motorized vehicle without departing from the scope of the present disclosure.

[0024] Embodiments of the present disclosure provide a method, system, and apparatus for more efficiently handling OTA event logs. In particular, the apparatus and method according to the embodiments may include receiving, by a first handler object, a first log request for a first event log for a first event class that is derived from a main logger object, the first log request including a first event object of the first event class and the first event log being stored in persistent storage, and transmitting, by the handler object to a storage object, a first write request for writing the first event object to the first event log, and when receiving the first write request, the storage object is configured to serialize the first event object and write the serialized first event object to the first event log.

[0025] Ultimately, embodiments of the present disclosure enable more efficient handling of event logging. Since multiple handler objects can be used for each event type (capable of corresponding to different components in an OTA application), concurrent operations are possible while avoiding threading issues and multiple events can be received simultaneously. Similarly, since different event objects can be used for each event type, different event fields may be allowed for each of the different event types. Further, only one main logger object needs to function as a controller for handling multiple objects so as to reduce the total number of objects generated.

[0026] In addition, a FIFO queue using a circular buffer can be implemented, so that old logs for a given event type can be deleted only without affecting the logs of different event types while not requiring a single object to handle all of persistent storage.

[0027] Thus, a more efficient method for handling multiple event types for an OTA application can be achieved.

[0028] The features, advantages, and significance of the embodiments described herein are merely a part of the present disclosure and are not intended to be exhaustive or to limit the scope of the present disclosure. Further descriptions of the embodiments, features, components, configurations, and operations of the embodiments of the present disclosure will be provided hereinafter.

[0029] FIG. 1 shows a block diagram of an example of components of a system for handling OTA event logging according to one or more embodiments.

[0030] In one embodiment, an over-the-air (OTA) application 100 may be provided. The OTA application 100 may be used to initialize a main logger object 101. The main logger object 101 may serve as the top-level class for logging in the OTA application 100. The main logger object 101 may be the first object initialized by the OTA application 100, and the main logger object 101 may then be used to initialize a plurality of logger handler objects 103-1, 103-2, 103-3, 103-4 (which may be used by components of the OTA application 100 to record logs) and a single logger storage object 102 (which may perform storage processing tasks and be shared with all objects). In one embodiment, the main logger object 101 may also provide an interface for reading and clearing persistently stored logs. The main logger object 101 may be concurrently usable (for example, users of the same logger do not need to worry about using the handle from different threads). In other words, multithreading may be supported in some embodiments. In one embodiment, the main logger object 101 may persist for the entire lifetime of the OTA application 100, and once the main logger object 101 is deleted, all logger handler objects 103 and logger storage objects 102 may no longer be valid.

[0031] The main logger object 101 may be initialized using a constructor method that can take a directory handle and an application name as input.

[0032] The main logger object 101 may include a logger handler pointer method for returning a pointer to a logger handler object 103 for a specific component. The input to the logger handler pointer method may be based on a string name indicating the component name for the logger handler object.

[0033] Furthermore, the main logger object 101 may include a method for initiating the reading of an event log, which may reset a pointer for reading (e.g., a tail pointer) to the beginning of a particular event log (e.g., a communication log 121, an error log 122, or an operation log 123). In some embodiments, this method may be requested before the main logger object 101 can read entries from a particular event log. In some embodiments, each type of event log may have its own method for the operations described above.

[0034] The main logger object 101 may include a method for reading the event log. This method may read the entry corresponding to the pointer and return the log entry in a serialized format (e.g., JSON format). If there are no further entries, a null pointer or a string of length 0 may be returned. When the read method is performed again, the pointer is then advanced to the next entry. In one embodiment, each type of event log may have its own method for the operations described above.

[0035] The main logger object 101 may include a method for deleting the entire event log corresponding to a particular event type. In one embodiment, each type of event log may have its own specific methods.

[0036] In one embodiment, a logger handler object 103 may be provided. As described above, the logger handler class object may be initialized by the main logger object. Each logger handler object (103-1, 103-2, 103-3, and 103-4, respectively) may be used to handle logging for each component of the OTA application by communicating with an object responsible for handling persistent storage (e.g., a logger storage object 102). For this reason, each logger handler object 103-1, 103-2, 103-3, and 103-4 may be responsible for a single type of event (e.g., communication, anomaly, operation, and debug), but in some configurations, the logger handler object 103 may, depending on the embodiment, handle more than a single type of event.

[0037] Each recorded event may be defined as an event object, such as a communication event object 111, an abnormal event object 112, or an operation event object 113. Each event object may be associated internally with a timestamp when recorded. In one embodiment, each recorded event may also generate a debug trace string (to be associated with the debug log 130).

[0038] The logger handler object 103 may be initialized using a constructor method that includes the component name of the OTA application 100, the OTA application name, and a reference to the logger storage object 102. This constructor method may typically be used by the main logger object 101.

[0039] In one embodiment, a log event method may be provided to the logger handler object 103. The log event method may receive events in the form of event objects (111, 112, 113) as input parameters. In one embodiment, each type of event log may have its own methods and its own event object classes (for example, an abnormal log event method for abnormal log 122 may require an abnormal event object 112 as input, while a communication log event method for communication log 121 may require a communication event object 111 as input, with abnormal event object 112 and communication event object 111 being separate classes). In a particular embodiment, the specific operations for each log event method for each event object class may differ from one another.

[0040] Each type of event log may generate debug prints for events, but for some event types (such as communication events), the generation of debug prints may be disabled by flooding of the output stream.

[0041] In one embodiment, a debugging method may be included. This may be used for a debug log 130 and may print debug messages to an output stream based on the debug trace.

[0042] As described above, a logger storage object 102 may be provided. The logger storage object 102 may be used to coordinate the storage of events to the event log of storage 120, and may also be used so that the main logger object 101 can read the log again. In one embodiment, the logger storage object 102 may be used to serialize (e.g., convert from an event object to a format such as a JSON string) and deserialize the recorded events. Interaction with storage 120 may be handled using an API (e.g., PAL). A single logger storage object 102 may be initialized and allocated by the main logger object 101 and may be shared (e.g., by reference) with the logger handler object 103. In one embodiment, multiple logger handler objects 103 may send log events to be written to the event log at any time (simultaneously), in which case the operation from each logger handler object to the logger storage object is thread-safe.

[0043] Each event log (121, 122, 123) may correspond to a different event type and may have a FIFO ring buffer structure (as described above). The logger storage object may track a head pointer and a tail pointer (these may be stored in the first few bytes of the storage log file). When the capacity is full (e.g., when the head pointer catches up to the tail pointer), the oldest entries may be overwritten. Each event log may have a specific storage allocation (e.g., 10MB). Each event log (121, 122, 123) may be packed as binary and stored as separate items in the ring buffer, in which case each event entry is recorded as a fixed-length integer value. It should be understood that the files corresponding to each event log / event type may need to be opened in binary so that bytes can be overwritten.

[0044] The logger storage object 102 may have a constructor method, which may be executed by the main logger object 101 to initialize the logger storage object 102.

[0045] In one embodiment, a log entry writing method may be provided. This method may include a timestamp and may provide a serialized event log entry (e.g., an event object converted to a serialized format such as JSON). In one embodiment, each type of event log may have its own methods.

[0046] The logger storage object 102 may handle a method for initiating the reading of an event log (as described above with reference to the main logger object), which may reset the read pointer (e.g., the tail pointer) to the beginning of a particular event log. In some embodiments, this method may be requested before the main logger object 101 is able to read entries from a particular event log. In some embodiments, each type of event log has its own method for the operations described above.

[0047] The logger storage object 102 may have a method for reading entries in the event log (as described above with reference to the main logger object 101). This method may read the entry corresponding to the pointer and return the log entry in a serialized format (e.g., JSON format). If there are no further entries, a null pointer or a string of length 0 may be returned. When the read method is performed again, the pointer is then advanced to the next entry. In one embodiment, each type of event log has its own method for the operations described above.

[0048] In one embodiment, the logger storage object 102 may be capable of handling the deletion of event logs.

[0049] In some embodiments, different types of events may need to be handled by the system. Each type of event may be stored in an individual event log. Each event log may be stored individually in storage 120, which may be persistent storage. In some embodiments, the event logs are stored using a first-in-first-out (FIFO) queue. In some embodiments, the FIFO queue may be implemented using a ring buffer along with tail / head pointers.

[0050] In one embodiment, a communication log 121 may be provided. The communication log 121 may be responsible for tracking all communication events, for example, during an OTA update campaign. This may include transmit and receive events. Communication events may be required to be recorded in order to troubleshoot any problems that occur (e.g., problems following a failed update).

[0051] In one embodiment, an error log 122 may be provided. The error log may include information about an anomaly (e.g., an anomaly event), such as a transmission error that occurs during an OTA update. In one embodiment, this information may include an error code.

[0052] In one embodiment, an operation log 123 may be provided. The operation log may include, for example, user events and campaign status events that occur during an OTA update campaign.

[0053] In one embodiment, a debug log 130 may be provided. The debug log does not necessarily need to be stored in storage 120 and may be used only to provide an API for debug trace logging during development. The debug log may be output as an output stream to obtain information during integration test execution.

[0054] Each event log may correspond to a unique event object class, and each event object may have its own set of fields, such as a communication event object 111, an abnormal event object 112, and an operation event object 113. For example, a communication log event 111 may have a field indicating the direction of the communication event, while an abnormal event 112 may have a field indicating an error code.

[0055] Figure 2 shows an example of a call flow diagram for initializing a system according to one or more embodiments. The OTA application, persistent storage (e.g., storage 120), main logger object, logger storage object, and logger handler object may be provided and may correspond to those objects as described in the reference to Figure 1 above.

[0056] In operation S201, the OTA application may create a main logger object. This may be done after persistent storage has been initialized, allowing all components to access the main logger object and each to create an instance of its own logger handler object.

[0057] In operation S202, the main logger object may initialize the logger storage object (for example, by using the constructor method).

[0058] In operation S203, the logger storage object may return a message or pointer to the main logger object indicating that the logger storage object was successfully initialized.

[0059] In operation S204, the logger handler acquisition operation may be performed by an OTA application.

[0060] In operation S205, based on S204, the main logger object may generate logger handler objects. As described above, each logger handler object may correspond to a specific component and / or event type for any OTA application.

[0061] In operation S206, the main logger object may return a reference pointer to the generated logger handler object to the OTA application.

[0062] Figure 3 shows an example of a call flow diagram for reading and writing events according to one or more embodiments. The OTA application, persistent storage (e.g., storage 120), main logger object, logger storage object, and logger handler object may be provided and may correspond to those objects as described in the reference to Figure 1 above. The steps shown in Figure 3 may be performed following, for example, the steps shown in Figure 2.

[0063] Operations S301–S303 illustrate an example of a write operation. Operations S301–S303 may be repeated for multiple logger handler objects for different event logs, depending on the execution.

[0064] In operation S301, the log event operation may be sent by the OTA application. In one embodiment, it may be first sent to the main logger object and then forwarded to the logger handler object in operation S301b, or it may be sent directly from the OTA application to the logger handler object.

[0065] In operation S302, a logger handler object may send a write error log (e.g., a write request) to the logger storage object. Upon receiving a write request, the logger storage object may serialize the object into a string (e.g., JSON format).

[0066] In Operation S303, the logger storage object may write the serialized event object to the event log of persistent storage. In this step, it should be understood that the logger storage object may overwrite the oldest entry if the storage is full for any event log.

[0067] Operations S311–S314 show examples of reading operations.

[0068] In operation S311a, the read event log operation may be sent by an OTA application. In one embodiment, this may be sent first to the main logger object and then forwarded to the logger storage object in operation S311b, or it may be sent directly from the OTA application to the logger storage object.

[0069] In operation S312, read log requests may be sent to persistent storage.

[0070] In operation S313, based on the request from S312, the serialized event may be returned to the logger storage object. The logger storage object may deserialize the event into an event object.

[0071] In operation S314a, the logger storage object may return an event object to the OTA application. In one embodiment, this may be first sent from the logger storage object to the main logger object and then forwarded to the OTA application in operation S314b, or it may be sent directly from the logger storage object to the OTA application.

[0072] Figure 4 shows an example of a method 400 for writing to multiple event logs, relating to one or more embodiments.

[0073] In operation S410, the first log request to the first event log is received by the first handler object. The first log request may be of the first event class and may originate from the main logger object. The first log request may contain the first event object of the first event class, and the first event log may be stored in persistent storage.

[0074] In operation S420, a handler object may send a first write request to the storage object. The first write request may instruct the storage object to write the first event object to the first event log. Upon receiving the first write request, the storage object may be configured to serialize the first event object and write the serialized first event object to the first event log.

[0075] In operation S430, a second log request is received for the second event log. The second log request may be for a second event class different from the first event class, and may originate from the main logger object. The second log request may contain a second event object of the second event class, and the second event log may be stored in persistent storage.

[0076] In operation S440, a handler object may send a second write request to the storage object. The second write request may instruct the storage object to write the second event object to the second event log. Upon receiving the second write request, the storage object may be configured to serialize the second event object and write the serialized second event object to the second event log.

[0077] Figure 5 shows an example of system components according to one or more embodiments. As shown in Figure 5, the system 510 may include at least one bus 511, at least one processor 512, at least one memory 513, at least one storage component 514, at least one input component 515, at least one output component 516, and at least one communication interface 517.

[0078] System 510 may include more or fewer components than those shown in Figure 5 without departing from the scope of this disclosure. For example, in some embodiments, System 510 may include a plurality of storage components 514, the input component 515 and the output component 516 may be implemented as transceiver components, and the memory 513 and the storage component 514 may be implemented as memory storage.

[0079] Bus 511 may be configured to facilitate or enable communication between components of System 510. In particular, Bus 511 may connect components in a communicative manner to provide means for data transfer and control signal flow between components. Bus 511 may include one or more internal buses, address buses, data buses, control buses, Controller Area Network (CAN) buses, Ethernet buses, Peripheral Component Interconnect Express (PCIe) buses, and any other suitable types of buses that may be implemented in System 510 to enable real-time (or near real-time) communication and cooperation between components within System 510.

[0080] The processor 512 may be implemented in hardware, firmware, or a combination of hardware and software, and may be configured to handle real-time (or near real-time) data processing and control of the control system 510. The processor 512 may include one or more of the following: a central processing unit (CPU), a graphical processing unit (GPU), a neural processing unit (NPU), a tensor processing unit (TPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), and / or other types of processing or computing components that can be implemented in the system 510. In some embodiments, the processor 512 may be programmed to perform one or more operations described herein. Furthermore, the processor 512 may include a plurality of processing units, each processing unit specialized for performing a particular operation.

[0081] Memory 513 may include one or more media for storing temporary data, runtime variables, program instructions, and buffers required for the operation of the control system 510. Memory 513 may include one or more of the following: flash memory, read-only memory (ROM), random access memory (RAM), dynamic or static storage devices (e.g., flash memory, magnetic memory, and / or optical memory), and any other suitable type of memory that can be implemented in the system 510 for storing information and / or instructions used by the processor 512.

[0082] The storage component 514 may be configured to store non-volatile data such as firmware, configuration settings, calibration data, information, and / or software relating to the operation and use of the system 510. For example, the storage component 514 may include, along with a corresponding drive, a hard disk (e.g., magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cartridge, magnetic tape, and / or other types of non-transient computer-readable media.

[0083] In one embodiment, the storage component 514 may be configured to store computer-readable or computer-executable instructions for performing one or more operations of the system 510. The storage component 514 may provide the stored information to the memory 513 for execution by the processor 512.

[0084] The input component 515 may include one or more input components (e.g., a touchscreen display, keyboard, keypad, mouse, buttons, switches, and / or microphone) that allow the system 510 to receive information, for example, via user input. The output component 516 may include one or more output components (e.g., a display, speaker, navigation device, one or more light-emitting diodes (LEDs), etc.) that provide output information from the system 510. In some embodiments, the input component 515 and / or the output component 516 may be optionally excluded from the system 510.

[0085] At least one communication interface 517 may include a transceiver-like component (e.g., a transceiver and / or separate receiver and transmitter) that enables the system 510 to communicate with other components (e.g., ECUs, user equipment, etc.) via, for example, a wired connection, a wireless connection, or a combination of wireless and wired connections. For example, the communication interface 517 may include a Controller Area Network (CAN) bus interface, an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a Universal Serial Bus (USB) interface, a Wi-Fi interface, a cellular network interface, or equivalents thereof.

[0086] In one or more embodiments, the communication interface 517 may include at least one input / output (I / O) interface, at least one network interface, at least one storage interface, or equivalent thereof, enabling components 512–516 to communicate with other components. Furthermore, the communication interface 517 may include one or more application programming interfaces (APIs) that enable the system 510 (or one or more components included therein) to communicate with one or more software applications (e.g., software applications deployed on an ECU).

[0087] Computer executable instructions (e.g., software instructions) may be read into memory 513 and / or storage component 514 from other computer-readable media or other devices (e.g., remote servers, external storage, etc.), for example, via a communication interface 517. When executed, the computer executable instructions stored in memory 513 and / or storage component 514 may cause the processor 512 to perform one or more processes as described herein. In addition, or instead, hardwired circuits may be used instead of or in combination with software instructions to perform one or more processes as described herein. Therefore, the embodiments described herein are not limited to any particular combination of hardware circuits and software.

[0088] Based on the above, it is understood that the embodiments of this disclosure enable more efficient handling of event logging. Multiple handler objects may be used for each event type (which may correspond to different components in an OTA application), allowing for concurrent operations while avoiding threading issues and enabling the simultaneous reception of multiple events. Similarly, different event objects may be used for each event type, allowing for different event fields for each of the different event types. Furthermore, it is necessary that only one main logger object functions as a controller for handling multiple objects in order to reduce the total number of objects generated.

[0089] In addition, a FIFO queue using a circular buffer can be implemented, requiring a single object to handle all persistent storage, while allowing older logs for a given event type to be deleted without affecting logs of different event types.

[0090] Therefore, a more efficient method can be achieved for handling multiple event types for OTA applications.

[0091] It should be noted that the features, advantages, and importance of the embodiments described earlier in this specification are merely a part of this disclosure and are not intended to be exhaustive or to limit the scope of this disclosure. Further descriptions of the embodiments, features, components, configurations, and operations of the embodiments of this disclosure, along with the relevant technical advantages and importance, are provided hereafter.

[0092] It is understood that the specific order or hierarchy of blocks in the processes / flowcharts disclosed herein is illustrative of an example approach. It is understood that the specific order or hierarchy of blocks in the processes / flowcharts may be rearranged based on design preferences. Furthermore, some blocks may be combined or omitted. The attached method claims represent elements of various blocks in an example order and are not intended to be limited to a specific order or hierarchy.

[0093] Some embodiments may relate to systems, methods, and / or computer-readable media in integration at any possible level of technical detail. Furthermore, as described herein, one or more of the above-described components may be implemented as instructions stored on a computer-readable medium and may be executable by at least one processor (and / or include at least one processor). The computer-readable medium may include a computer-readable non-temporary storage medium (or media) having computer-readable program instructions that cause a processor to perform an operation.

[0094] Computer-readable storage media can be tangible devices capable of holding or storing instructions used by an instruction execution device. Computer-readable media include, but are not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. A more detailed illustrative list of computer-readable storage media includes: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or grooved raised structures on which instructions are recorded, and any suitable combination thereof. The computer-readable storage medium used herein should not be interpreted as a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, or electronic signals propagating through wires; rather, electromagnetic waves propagate through waveguides or transmission media (for example, light pulses passing through fiber optic cables).

[0095] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing unit, or to an external computer or external storage device via a network such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. In each computing / processing unit, a network adapter card or network interface receives computer-readable program instructions from the network and transfers the computer-readable program instructions for storage on the computer-readable storage medium within each computing / processing unit.

[0096] Computer-readable program code / instructions for performing an operation may be assembler instructions, instruction set architecture (ISA) instructions, machine language instructions, machine language-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or either source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, and procedural programming languages ​​such as C or similar programming languages. Computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or wide area network (WAN), or it may be connected to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, an electronic circuit including, for example, a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer-readable program instructions by using state information of computer-readable program instructions that should personalize the electronic circuit in order to perform an action or operation.

[0097] These computer-readable program instructions may be provided to a processor of an SoC, a general-purpose computer, a dedicated computer, or other programmable data processing device, and a machine may be produced such that instructions executed via a computer processor or other programmable data processing device generate means for performing functions / operations defined in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions may be stored in a computer-readable storage medium that can instruct a computer, a programmable data processing device, and / or other device to function in a specific manner in order to function in a particular way, wherein the computer-readable storage medium storing the instructions comprises a product containing instructions that perform functions / operations defined in one or more blocks of a flowchart and / or block diagram.

[0098] Computer-readable program instructions may be loaded into a computer, another programmable data processing device, or another device to cause the computer, the other programmable device, or the other device to perform a series of operational steps to generate a computer implementation process, in which case the instructions executed by the computer, the other programmable device, or the other device perform functions / operations defined by one or more blocks in a flowchart and / or block diagram.

[0099] The flowcharts and block diagrams in the drawings illustrate the architecture, functions, and operations of possible embodiments of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in a flowchart or block diagram represents a module, segment, or portion of an instruction, which constitute one or more executable instructions to perform a particular logical function. Methods, computer systems, and computer-readable media may include additional blocks, fewer blocks, different blocks, or blocks arranged differently from those depicted in the diagram. In some alternative embodiments, the functions shown in the blocks may occur contrary to the rules shown in the diagram. For example, two blocks shown consecutively may actually be executed simultaneously or substantially simultaneously, or these blocks may sometimes be executed in reverse order depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, may be performed by a dedicated hardware-based system that performs a particular function or operation, or by a combination of dedicated hardware and computer instructions.

[0100] It is evident that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limited to the embodiments. Therefore, although the operation and behavior of the systems and / or methods are described herein without reference to specific software code, it will be understood that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

Claims

1. A method for handling event log entries, The first handler object receives a first log request to a first event log for a first event class, which originates from a main logger object, wherein the first log request comprises a first event object of the first event class, and the first event log is stored in persistent storage. The first handler object to the storage object sends a first write request to write the first event object to the first event log, A method wherein, upon receiving the first write request, the storage object is configured to serialize the first event object and write the serialized first event object to the first event log.

2. The method according to claim 1, The second handler object receives a second log request to a second event log for a second event class different from the first event class, which originates from the main logger object, wherein the second log request comprises a second event object of the second event class, and the second event log is stored in the persistent storage. The second handler object sends a second write request to the storage object to write the second event object to the second event log, It further includes, A method wherein, upon receiving the second write request, the storage object is configured to serialize the second event object and write the serialized second event object to the second event log.

3. A method according to claim 1 or 2, wherein the storage object is configured to reset the read pointer for the first event log when it receives a read start request originating from the main logger object.

4. A method according to claim 3, wherein the storage object is configured to return an event object corresponding to the read pointer in the first event log to the main logger object in JSON format when it receives a read request originating from the main logger object.

5. A method according to claim 1 or 2, wherein the first event log is formatted as a first-in-first-out (FIFO) buffer, and the storage object is configured to write serialized first event objects to the first event log by overwriting the oldest entry in the first event log when the first event log is full.

6. A method according to claim 1 or 2, The first handler object receives a debug log request that includes a debug trace originating from the main logger object, The first handler object returns the debug trace to the output stream, A method that further includes this.

7. A method according to claim 2, wherein the first handler object, the second handler object, and the storage object are instantiated by the main logger object.

8. A device for handling event log entries, At least one memory for storing computer executable instructions, At least one processor, Equipped with, The at least one processor executes the computer executable instructions, The first handler object receives a first log request to a first event log for a first event class, which originates from a main logger object, wherein the first log request comprises the first event object of the first event class, and the first event log is stored in persistent storage. The first handler object is configured to send a first write request to the storage object to write the first event object to the first event log, When the first write request is received, the storage object is configured to serialize the first event object and write the serialized first event object to the first event log. Device.

9. The apparatus according to claim 8, wherein the at least one processor executes the computer executable instructions, The second handler object receives a second log request to a second event log for a second event class different from the first event class, the second log request originating from the main logger object, wherein the second log request comprises a second event object of the second event class, and the second event log is stored in the persistent storage. The second handler object sends a second write request to the storage object to write the second event object to the second event log, It is configured to do the following: When the storage object receives the second write request, it is configured to serialize the second event object and write the serialized second event object to the second event log. Device.

10. The apparatus according to claim 8 or 9, wherein the storage object is configured to reset the read pointer for the first event log when it receives a read start request originating from the main logger object.

11. The apparatus according to claim 10, wherein the storage object is configured to return an event object corresponding to the read pointer in the first event log to the main logger object in JSON format when it receives a read request originating from the main logger object.

12. The apparatus according to claim 8 or 9, wherein the first event log is formatted as a first-in-first-out (FIFO) buffer, and the storage object is configured to write the serialized first event object to the first event log by overwriting the oldest entry in the first event log when the first event log is full.

13. The apparatus according to claim 8 or 9, wherein the at least one processor executes the computer executable instructions, The first handler object receives a debug log request that includes a debug trace originating from the main logger object, The first handler object returns the debug trace to the output stream, A device configured to perform the following further.

14. The apparatus according to claim 9, wherein the first handler object, the second handler object, and the storage object are instantiated by the main logger object.

15. A computer program that causes at least one processor to perform a method for outputting a user interface for setting operation rules for controlling one or more components of a vehicle, wherein the method is The first handler object receives a first log request to a first event log for a first event class, which originates from a main logger object, wherein the first log request comprises a first event object of the first event class, and the first event log is stored in persistent storage. The first handler object sends a first write request to the storage object to write the first event object to the first event log, Includes, When the first write request is received, the storage object is configured to serialize the first event object and write the serialized first event object to the first event log. Computer program.

16. A computer program according to claim 15, wherein the method is: The second handler object receives a second log request to a second event log for a second event class different from the first event class, which originates from the main logger object, wherein the second log request comprises a second event object of the second event class, and the second event log is stored in the persistent storage. The second handler object sends a second write request to the storage object to write the second event object to the second event log, It further includes, When the storage object receives the second write request, it is configured to serialize the second event object and write the serialized second event object to the second event log. Computer program.

17. A computer program according to claim 15 or 16, wherein the storage object is configured to reset the read pointer for the first event log when it receives a read start request originating from the main logger object.

18. A computer program according to claim 17, wherein the storage object is configured to return an event object corresponding to the read pointer in the first event log to the main logger object in JSON format when it receives a read request originating from the main logger object.

19. A computer program according to claim 15 or 16, wherein the first event log is formatted as a first-in-first-out (FIFO) buffer, and the storage object is configured to write the serialized first event object to the first event log by overwriting the oldest entry in the first event log when the first event log is full.

20. A computer program according to claim 15 or 16, wherein the method is The first handler object receives a debug log request that includes a debug trace originating from the main logger object, The first handler object returns the debug trace to the output stream, A computer program that further includes this.

Images