System and method for managing vehicle event data

Abstract

To provide a method.SOLUTION: Provided are a method, system, and device for managing vehicle event data for a vehicle. The method may be implemented by an electronic control unit (ECU) of the vehicle and include: determining that a vehicle event in an event log belongs to an unregistered event type; generating a temporary event identifier (ID) indicating characteristics of the vehicle event; storing the temporary event ID in a database with a timestamp; determining whether the number of vehicle events in the event log with the same temporary event ID exceeds a predetermined threshold value; and upon determination that the number of vehicle events exceeds the predetermined threshold value, triggering a response for the vehicle associated with the temporary event ID.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] Exemplary embodiments and methods consistent with the present disclosure relate to a method for managing vehicle event data.

Background Art

[0002] In related technologies, vehicles, particularly vehicle components (e.g., lights, brakes, sensors, etc.), can generate vehicle data. A subset of the vehicle data can be referred to as an event, and the event can be a short message that is sent to logs and / or other databases existing in the vehicle or elsewhere. For example, when a vehicle experiences a collision, an impact sensor can log the collision event, and this event can be packaged and sent (e.g., to a cloud network). Since events can have a predefined type as part of a standard, a vehicle can be configured to take measures based on the reception of a specific event. For example, when a collision event is received, the vehicle can be configured to automatically contact emergency services.

[0003] Vehicle components can log unexpected events that are not predefined (e.g., the unexpected event is not published as part of a standard), and thus, the event can be logged without being properly registered, which causes problems when measures cannot be taken for the event.

[0004] Therefore, there is a need for a method for processing responses to vehicle events that can handle the registration of unexpected / anomalous events.

Summary of the Invention

[0005] According to one or more exemplary embodiments, devices and methods are provided for managing vehicle event data of a vehicle. In particular, devices and methods according to exemplary embodiments may be implemented by the vehicle's electronic control unit (ECU) and may include: determining whether a vehicle event in an event log belongs to an unregistered event type; generating a temporary event identifier (ID) that describes the characteristics of the vehicle event; storing the temporary event ID in a database along with a timestamp; determining whether the number of vehicle events in the event log having the same temporary event ID exceeds a predetermined threshold; and, based on the determination that the number of vehicle events exceeds the predetermined threshold, triggering a response relating to the vehicle associated with the temporary event ID.

[0006] Therefore, anomaly detection for non-default (unregistered event type) events may be considered as part of the standard, and an appropriate response may be given to non-default events because the response is based on a threshold for receiving similar vehicle events.

[0007] According to the embodiment, a method for managing vehicle event data performed by the vehicle's electronic control unit (ECU) may be provided. The method may include: determining that a vehicle event in an event log belongs to an unregistered event type; generating a temporary event identifier (ID) based on at least one characteristic of the vehicle event; storing the temporary event ID in a database along with a timestamp; determining whether the number of vehicle events in the event log having the temporary event ID exceeds a predetermined threshold; and, based on the determination that the number of vehicle events exceeds the predetermined threshold, triggering a response regarding the vehicle associated with the temporary event ID.

[0008] The method may further include adding new vehicle events received from the vehicle's components to the event log, and determining, based on a temporary event ID, whether the new vehicle event belongs to an unregistered event type.

[0009] The method may include determining whether a new vehicle event belongs to a registered event type based on a temporary event ID, which is done using a machine learning (ML) model.

[0010] Generating a temporary event ID may be based on a hash using at least one of the following: the source vehicle component of the vehicle, the distance of the source vehicle component from the safety and security infrastructure in the vehicle, and the message in the vehicle event.

[0011] The method may further include adding registered event types and responses regarding vehicles associated with those registered event types to the database.

[0012] Responses regarding vehicles associated with predetermined thresholds and temporary event IDs can be stored in a database.

[0013] A trigger for a vehicle-related response may include sending a message to a cloud network.

[0014] According to one embodiment, a device may be provided for managing vehicle event data performed by the vehicle's electronic control unit (ECU). 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 determine whether a vehicle event in an event log belongs to an unregistered event type, to generate a temporary event identifier (ID) based on at least one characteristic of the vehicle event, to store the temporary event ID in a database along with a timestamp, to determine whether the number of vehicle events in the event log having the temporary event ID exceeds a predetermined threshold, and to trigger a response regarding the vehicle associated with the temporary event ID based on the determination that the number of vehicle events exceeds the predetermined threshold.

[0015] At least one processor may further be configured to execute computer executable instructions to add new vehicle events received from vehicle components of the vehicle to the event log and to determine, based on a temporary event ID, whether the new vehicle event belongs to an unregistered event type.

[0016] At least one processor may be configured to use a machine learning (ML) model to determine, based on a temporary event ID, whether a new vehicle event belongs to a registered event type.

[0017] At least one processor may be configured to generate a temporary event ID based on a hash using at least one of the following: the source vehicle component of the vehicle, the distance of the source vehicle component from the safety and security infrastructure in the vehicle, and a message in the vehicle event.

[0018] At least one processor may be configured to execute computer executable instructions to add registered event types and responses regarding vehicles associated with those registered event types to a database. A predetermined threshold and responses regarding vehicles associated with a temporary event ID may be stored in the database.

[0019] At least one processor may be configured to trigger a response regarding the vehicle by sending a message to a cloud network.

[0020] Additional embodiments may be described in part in the following description and partially revealed therefrom, or may be realized by implementing the embodiments presented in this disclosure. [Brief explanation of the drawing]

[0021] Features, aspects, and advantages of certain preferred embodiments of the present disclosure are described below with reference to the accompanying drawings, in which similar reference numerals indicate similar elements. [Figure 1] Figure 1 shows an example of a device component according to one or more embodiments. [Figure 2] Figure 2 shows a diagram of exemplary components of a system for processing vehicle event data according to one or more exemplary embodiments. [Figure 3] Figure 3 is a flowchart illustrating a vehicle event data management process for generating temporary event identifiers (IDs) according to one or more exemplary embodiments. [Figure 4] Figure 4 is a flowchart illustrating a vehicle event data management process for adding new vehicle events to the event log, according to one or more exemplary embodiments. [Figure 5] Figure 5 is a flowchart illustrating a vehicle event data management process for processing the reception of multiple messages from multiple vehicle components and triggering a vehicle response, according to one or more exemplary embodiments. [Modes for carrying out the invention]

[0022] The following detailed description of the exemplary embodiments refers to the accompanying drawings. The present disclosure provides examples and explanations, but is not intended to be comprehensive nor to limit one or more exemplary embodiments to the exact forms disclosed. Modifications and variations are possible in view of the present disclosure or can be learned from the implementation of one or more exemplary embodiments. Further, one or more features or components of one exemplary embodiment can be incorporated into or combined with another exemplary embodiment (or one or more features of another exemplary embodiment). Additionally, in the flowcharts and descriptions of operations provided herein, it is understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least partially) simultaneously, and the order of one or more operations may be switched.

[0023] It will be apparent that the exemplary embodiments of the systems and / or methods and / or non - transient computer - readable storage media described herein can be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement the system and / or method is not a limitation of one or more exemplary embodiments. Thus, the operations and behaviors of the systems and / or methods and / or non - transient computer - readable storage media are described herein without reference to specific software code. It is understood that software and hardware can be designed to implement the system and / or method based on the description herein.

[0024] Even if a particular combination of features is recited in the claims and / or disclosed herein, that combination is not intended to limit the disclosure of possible exemplary embodiments. In fact, many of these features may be combined in ways that are not specifically recited in the claims or disclosed herein. Each of the dependent claims listed below may depend directly on only one claim, but the disclosure of possible exemplary embodiments includes each dependent claim combined with all the other claims in the set of claims.

[0025] Elements, acts, or instructions used herein should not be construed as important or essential unless specifically described as such. Also, 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." The term "one" or similar terms are used if only one item is intended. Also, the terms "has," "have," "having," "include," "including," or the like as used herein are intended to be open-ended terms. Further, the phrase "based on" is intended to mean "at least partially based on" unless specifically stated otherwise. Further, expressions such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include only A, only B, or both A and B.

[0026] FIG. 1 shows a diagram of exemplary components of a device 100 according to one or more embodiments. The device 100 can be used to implement the ECU 220 described with respect to FIG. 2 (as described below).

[0027] Referring to Figure 1, device 100 may include a bus 110, a processor 120, a memory 130, a storage unit 140, an input unit 150, an output unit 160, and a communication interface 170.

[0028] Bus 110 may include one or more components that allow communication between components of device 100. Processor 120 may be implemented in hardware, firmware, or a combination of hardware and software. Processor 120 may be a central processing unit (CPU), image processing unit (GPU), accelerator unit (APU), microprocessor, microcontroller, digital signal processor (DSP), field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), or another type of processing or computing component. In some implementations, processor 120 may include one or more processors that are programmable to perform functions. Memory 130 may include random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions used by processor 120.

[0029] The storage component 140 may store information and / or software related to the operation and use of device 100. For example, the storage unit 140 may include, together 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, a magnetic tape, and / or another type of non-temporary computer-readable media.

[0030] The input unit 150 may include one or more components (e.g., a touchscreen display, keyboard, keypad, mouse, buttons, switches, and / or a microphone) that allow the device 100 to receive information via user input or the like. Furthermore or alternatively, the input unit 150 may include sensors (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or actuators) for detecting information. The output unit 160 may include one or more components (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)) that provide output information from the device 100.

[0031] The communication interface 170 may include transceiver-like components (e.g., transceivers and / or separate receivers and transmitters) that enable device 100 to communicate with other devices via wired connections, wireless connections, or a combination of wired and wireless connections. The communication interface 170 may allow device 100 to receive information from and / or provide information to other devices (e.g., devices included in multiple vehicles). For example, the communication interface 170 may include 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 similar.

[0032] Device 100 may perform one or more processes described herein in response to the processor 120 executing software instructions stored in a non-temporary computer-readable medium such as memory 130 and / or storage unit 140. The computer-readable medium is defined herein as a non-temporary memory device. A memory device may include a memory space within a single physical storage device or a memory space extending across multiple physical storage devices.

[0033] Software instructions may be read into memory 130 and / or storage unit 140 from another computer-readable medium or another device via the communication interface 170. When executed, the software instructions stored in memory 130 and / or storage unit 140 can cause the processor 120 to perform one or more processes described herein. Furthermore or alternatively, hardwired circuits may be used in place of or in combination with software instructions to perform one or more processes described herein. Therefore, the implementations described herein are not limited to any particular combination of hardware circuits and software.

[0034] Figure 2 shows a diagram of exemplary components of a system 200 for processing vehicle event data according to one or more exemplary embodiments. A vehicle component 210, an electronic control unit (ECU) 220, and a cloud network 230 may be provided. The ECU 220 may include a registration module 221, an event log analysis module 222, an event log 223, and an event type and ID database 224. The vehicle component 210 may be any component in a vehicle that can implement a function. For example, the vehicle component 210 may include, but is not limited to, lights, brakes, and sensors. Depending on the particular implementation, each individual vehicle component may have its own corresponding ECU, or all individual vehicle components may share a single central ECU.

[0035] The registration module 221 may enable the functions of the vehicle components 210 to register their own event types, along with possible responses to those events, in the event type and ID database 224. According to embodiments, this may include a user interface (such as a GUI) to enable the manufacturer to define new event types and possible responses to associated event types. During construction time, the registration module 221 may perform checks to find functions that are registering safety-related responses (e.g., those that may require safety checks for the vehicle operator). According to embodiments, new event types may be registered using standards (e.g., ISO 19770-3).

[0036] The event log analysis module 222 may be a software component capable of analyzing anomalies in the event log 223. According to the embodiment, the event log analysis module 222 may be configured to determine the characteristics of events in the event log 223 and record such characteristics in the event type and ID database 224. Characteristics may include, but are not limited to, the occurrence rate of a particular type of event (the total number of occurrences and the number of occurrences in a given time slot), the location of source vehicle components related to the placement of safety-critical infrastructure in the vehicle, the location of source vehicle components related to the placement of security-critical infrastructure in the vehicle, the specific geolocation of where the event occurred, and the vehicle state (stopped, started, moving, charging, etc.). For example, safety-critical infrastructure may relate to user safety (e.g., ensuring the safe operation of the vehicle for the user), and security-critical infrastructure may relate to vehicle security (e.g., against vehicle theft). The event log analysis module 222 may be configured to use the characteristics to determine whether a particular vehicle event or a group of vehicle events belong to an unregistered event type.

[0037] The event log analysis module 222 may be configured to generate temporary event identifiers (IDs) for unregistered event types. In particular, the event log analysis module 222 may evaluate the event log 223 for any vehicle event deemed to belong to an unregistered event type, ingest the event, and use it to generate a raw hash that can be used as a temporary event ID. The temporary event ID may be based on the source of the event (e.g., which vehicle component the event originated from), the distance from the safety and security infrastructure in the vehicle, and the event message. For example, a hash algorithm function may generate a hash value (i.e., a temporary event ID or at least a portion of a temporary event ID) by using (or inputting) at least one of the source of the event, the distance from the safety and security infrastructure in the vehicle, and the event message.

[0038] According to one embodiment, a temporary event ID may be stored in the event type and ID database 224 along with a timestamp, and when any other similar event (e.g., the same event, events having at least a threshold number of common predetermined event parameters or features, events included in a predetermined group of events, etc.) is received, the same temporary event ID or a similar temporary event ID (e.g., generated by a hash algorithm) may be stored in the event type and ID database 224.

[0039] According to one embodiment, the event log analysis module 222 may also be configured to check, at least partially based on a temporary event ID, whether a previous (or older) event of the same type exists in the event log 223 when a new event is added to (or based on) it. The event log analysis module 222 may determine that a previous event is of the same (or similar) type by using a machine learning (ML) model and / or, for example, based on determined features of the events in the event log 223, by determining whether the temporary event IDs have at least a predetermined degree of similarity or overlap.

[0040] According to one embodiment, the event log analysis module 222 may delete the event log 223 or instruct the event log 223 to delete at least one previous event based on a determination of a memory threshold (e.g., a predetermined period or length of time, a predetermined number of events, etc.). For example, if a previous event is older than the memory threshold (e.g., a predetermined period or length of time), the event log analysis module 222 may instruct the event log 223 to delete the previous event. As another example, if the number of previous events of the same type in the event log 223 exceeds the memory threshold (e.g., a predetermined number of events), the event log analysis module 222 may instruct the event log 223 to delete the oldest previous event.

[0041] According to the embodiment, the event log analysis module 222 may implement a machine learning (ML) model to perform analysis. The analysis may be performed to determine whether the number of vehicle events of a particular type (e.g., sharing the same temporary event ID) exceeds a threshold. The threshold may be defined by the vehicle vendor (e.g., an OEM of the original product manufacturer) and stored in the event type and ID database 224. If the threshold is exceeded, a response may be triggered, for example, an event log 223 may be collected, signed, and sent to the cloud network 230. In addition, if the event is an anomaly near security / safety critical infrastructure, the response may be sent to the vehicle component 210 (e.g., illuminating the engine warning light). For example, a threshold may be defined as the number of events of an unregistered event type (or sharing the same temporary event ID) that exceeds a predetermined threshold. Alternatively, a threshold may be defined as the number of events (of an unregistered event type) that are an anomaly near security / safety critical infrastructure that exceeds a default threshold. Those skilled in the art should understand that the thresholds and responses defined for the event log analysis module 222 may depend on the specific implementation.

[0042] Figure 3 shows an exemplary flowchart illustrating a vehicle event data management process 300 for generating temporary event identifiers (IDs) according to an embodiment. Process 300 can be implemented using the system 200 of Figure 2 above, and in particular using the ECU 220.

[0043] In operation 310, a vehicle event in the event log (such as event log 223) may be determined to determine whether the vehicle event belongs to an unregistered event type. According to one embodiment, the determination may be based on the detection that the vehicle event does not belong to any registered event type. Alternatively, the determination may be based on an analysis of features in the event log (e.g., the occurrence rate of a particular type of event (the total number of occurrences and the number of occurrences in a given time slot), the location of source vehicle components related to the placement of safety-critical infrastructure in the vehicle, the location of source vehicle components related to the placement of security-critical infrastructure in the vehicle, the specific geolocation of where the event occurred, and the vehicle state (e.g., stopped, started, moving, charging).

[0044] In operation 320, a temporary event ID may be generated that may represent the characteristics of a vehicle event. According to the embodiment, this may be generated based on a hash function having the characteristics of a vehicle event as input. The characteristics may include at least one of the following: the source vehicle component of the vehicle, the distance of the source vehicle component from the safety and security infrastructure in the vehicle, and the message in the vehicle event.

[0045] In operation 330, temporary event IDs may be stored in a database along with their timestamps. For example, this could be a database such as the event type and ID database 224 described above with respect to Figure 2.

[0046] In operation 340, it may be determined whether the number of vehicle events in the event log with the same temporary event ID exceeds a default threshold. In particular, this default threshold may be the number of events and may be stored in a database (such as the event type and ID database 224).

[0047] In operation 350, based on the determination that the number of vehicle events exceeds a predetermined threshold (based on the determination in operation 340), a response regarding the vehicle associated with a specific temporary event ID may be triggered. The response may be pre-stored in a database (event type and ID database 224) to be associated with the temporary event ID.

[0048] For example, if there are three events related to a message about a vehicle starting failure, and the default threshold is 2, an appropriate trigger stored in the database may be executed (e.g., vehicle lockout). This may be to prevent vehicle theft, in which case the event is interpreted as security-related. Alternatively, if the event is safety-related, a safety-related response may be given. According to the embodiment, the response may include sending and / or signing data to a cloud network (e.g., cloud network 230). The cloud network may take measures such as performing analysis and recognizing patterns in the data, and may take further measures such as contacting emergency services. Nevertheless, it should be understood by those skilled in the art that a particular response may depend on a particular implementation.

[0049] Figure 4 is a flowchart illustrating a vehicle event data management process 400 for adding new vehicle events to the event log, according to one or more exemplary embodiments. The process 400 can be implemented using the system 200 of Figure 2 above, and in particular using the ECU 220.

[0050] In operation 410, a new vehicle event may be received from a vehicle component of the vehicle (e.g., vehicle component 210) and added to the event log (e.g., event log 223). For example, this could be an event received from a driver-side light in front. According to some embodiments, first a message may be received from a vehicle component and then entered into the event log as an event (the event may contain further data separate from the message received from the vehicle component).

[0051] In operation 420, it may be determined whether a new vehicle event added to the event log belongs to an unregistered event type. This may first involve checking whether the new vehicle event belongs to any default registered event type based on an analysis referencing the event type and ID database 224 (if it belongs to a default registered event type, no further determination may be required). The determination may also involve analyzing whether the new vehicle event matches / corresponds to a temporary event ID located in the event type and ID database, and, based on the determination that it matches / corresponds, concluding that it is an unregistered event type. If the new vehicle event does not match any existing temporary event ID, the analysis may still conclude that it is an unregistered event type and generate a new temporary event ID that characterizes the vehicle event. This may be similar to operations 310 and 320, referring to Figure 3 above.

[0052] If operation 420 determines that a new vehicle event added to the event log is not of an unregistered event type (for example, it is of a registered event type), then in operation 430, the ECU may trigger a vehicle response associated with the registered event type. The vehicle response and the associated registered event type may already be defined in the event type and ID database 224 by the registration module 221, and therefore the response may be triggered based on confirmation of the corresponding vehicle response in the event type and ID database 224. For example, a seat weight sensor event that occurs when a passenger seat detects a weight exceeding a threshold but the seat belt is unbuckled may be defined as a registered event type, and the ECU may check for an associated vehicle response, which may be the default, the illumination of the seat belt indicator light (instructing the passenger to fasten their seat belt), and then execute the associated vehicle response.

[0053] If operation 420 determines that a new vehicle event type added to the event log is an unregistered event type, operation 440 may determine whether the number of unregistered vehicle events of the same type with the same temporary ID as the new vehicle event exceeds a threshold defined for the number of vehicle events. This may be similar to operation 340 described above with reference to Figure 3.

[0054] If operation 440 determines that the number of vehicle events exceeds a predetermined threshold, operation 450 may trigger a response associated with a temporary ID for the vehicle. This may be similar to operation 350 described above with reference to Figure 3.

[0055] Figure 5 is a flowchart illustrating a vehicle event data management process 500 for processing the reception of multiple messages from multiple vehicle components and triggering a vehicle response, according to one or more exemplary embodiments.

[0056] In operation 510, a number of messages n# may be received from multiple vehicle components. In particular, such messages may be received from different vehicle lights attempting to start the vehicle (which may indicate that the attempt to start the vehicle failed). Messages may be security-related and are usually signed. For example, with a total of three messages, one message may be from the driver's side lights in front, and the other two may be from the passenger's side lights in front. Depending on the specific scenario, it should be understood that messages may be received from other groups of vehicle components that can be used to receive messages (i.e., driver's side seat sensors and passenger's side seat sensors).

[0057] In operation 520, it may be determined that the signing of the message received in operation 510 failed or is abnormal. Therefore, the ECU may log n# vehicle events in the event log corresponding to each message received in operation 510. In this case, because the message signing failed, the vehicle event may be determined to belong to an unregistered event type. Therefore, it should be understood that a temporary event ID may be generated or may already exist for an unregistered event type. While logging events, the ECU may consider that the vehicle components are approximately equidistant from the ECU and are in the same location for safety-critical infrastructure within the vehicle. Therefore, based on this, the ECU may consider that each of n# vehicle events belongs to the same unregistered event type during logging. Based on the example described in operation 510 regarding receiving a message from the forward driver-side light and two messages from the forward passenger-side light, a total of three vehicle events may be added to the event log corresponding to each message.

[0058] In operation 520, a number of vehicle events (n#) logged may be determined in operation 530 to exceed a default OEM-defined threshold (which may be the default in the event type and ID database 224). For example, if the default OEM threshold is set at two events, then three events logged in the example described in operation 520 may be considered to exceed the default OEM threshold.

[0059] If operation 530 determines that n# number of vehicle events exceeds a default OEM-defined threshold, operation 540 may trigger an associated response regarding the vehicle. This could be an OEM-defined response (which may be default in the event type and ID database 224). For example, if more than two events are received, the OEM-defined response might prevent the vehicle from starting for a certain period (e.g., 4 hours). This could relate to security-related events to prevent a thief from stealing the vehicle. The ECU may, accordingly, communicate to any other component in the vehicle (e.g., a data communications module (DCM)) that the vehicle has entered a lockdown state, collect an event log, sign the event log, and send the event log outside the vehicle (e.g., to a cloud network 230) for analysis. The event log may be analyzed to determine if its pattern matches a common passenger car event log strategy, and then law enforcement and / or emergency services may be contacted. Nevertheless, a particular OEM-defined response may depend on a specific implementation, as determined by the vendor.

[0060] Based on the above embodiment, it can be understood that anomaly detection for non-default (unregistered event type) events may be considered as part of the standard, and that an appropriate response may be given to non-default events because the response is based on a threshold for receiving similar vehicle events.

[0061] The foregoing disclosure provides examples and explanations, but is not intended to be exhaustive, nor is it intended to limit one or more exemplary embodiments to the exact forms disclosed. Modifications and variations are possible in view of this disclosure or can be learned from the practice of one or more exemplary embodiments.

[0062] One or more exemplary embodiments may relate to a system, method, and / or computer-readable medium at any possible level of technical detail of integration. Furthermore, one or more of the components described above may be implemented as instructions stored in a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-temporary storage medium (or medium(s)) having computer-readable program instructions that cause a processor to perform an action.

[0063] A computer-readable storage medium can be a tangible device capable of holding and storing instructions used by an instruction execution device. A computer-readable storage medium may be, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any preferred combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes, namely, 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 punched cards or grooved raised structures on which instructions are recorded, and any preferred combination thereof. The computer-readable storage media used herein should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmitting media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0064] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device, or they may be downloaded 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. A network adapter card or network interface within each computing / processing device receives computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium within each computing / processing device.

[0065] The computer-readable program code / instructions that perform the operation may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, or similar, and procedural programming languages ​​such as the C programming language or similar programming languages. The computer-readable program instructions may be fully executed on the user's computer, partially executed on the user's computer, executed as a standalone software package, partially executed on the user's computer and partially executed on a remote computer, or fully executed 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 a wide area network (WAN), or a connection to an external computer may be made (for example, via the Internet using an Internet service provider). In one or more exemplary embodiments, for example, an electronic circuit including a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) may execute a computer-readable program instruction by personalizing the electronic circuit using state information of the computer-readable program instruction in order to perform an action or operation.

[0066] The computer-readable program instructions may be provided to a processor of a general-purpose computer, a dedicated computer, or other programmable data processing device to generate a machine, and as a result, instructions executed via the processor of the computer or other programmable data processing device generate means for implementing functions / actions specified in blocks or blocks of a flowchart and / or block diagram. The computer-readable program instructions may also be stored in a computer-readable storage medium that can instruct computers, programmable data processing devices, and / or other devices to function in a particular way, and as a result, the computer-readable storage medium in which the instructions are stored comprises a manufactured article containing instructions that implement modes of functions / actions specified in blocks or blocks of a flowchart and / or block diagram.

[0067] Computer-readable program instructions can also be loaded onto a computer, other programmable data processing device, or other device to perform a series of operational steps on the computer, other programmable device, or other device, thereby generating a computer implementation process, the instructions executed on the computer, other programmable device, or other device, which implement the functions / actions specified in the blocks or blocks(s) of a flowchart and / or block diagram.

[0068] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible exemplary embodiments of a system, method, and computer-readable medium according to one or more exemplary embodiments. In this regard, each block in a flowchart or block diagram may represent a microservice, module, segment, or part of an instruction, comprising one or more executable instructions that implement a specified logical function. The method, computer system, and computer-readable medium may include additional blocks, fewer blocks, different blocks, or blocks arranged differently compared to those depicted in the drawings. In one or more alternative exemplary embodiments, the functions described in the blocks may occur regardless of the order in which they are shown in the drawings. For example, two blocks shown consecutively may actually be executed simultaneously or substantially simultaneously, or blocks may be executed in reverse order depending on the functions they relate to. 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 implemented by a dedicated hardware-based system that performs a specified function or action or executes a dedicated combination of hardware and computer instructions.

[0069] It will be apparent that the systems and / or methods described herein can be implemented in various forms of hardware, firmware, or combinations of hardware and software. Actual dedicated control hardware or software code used to implement such systems and / or methods is not limited to one or more exemplary embodiments. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it will be understood that software and hardware can be designed to implement the systems and / or methods based on the descriptions herein.

Claims

1. A method for managing vehicle event data performed by the vehicle's electronic control unit (ECU), wherein the method is: To determine if a vehicle event in the event log belongs to an unregistered event type, A temporary event identifier (ID) is generated based on at least one characteristic of the aforementioned vehicle event, The aforementioned temporary event ID is stored in the database along with the timestamp, Determining whether the number of vehicle events in the event log having the aforementioned temporary event ID exceeds a predetermined threshold representing the number of abnormal events, Based on the determination that the number of vehicle events exceeds the predetermined threshold, a response relating to the vehicle associated with the temporary event ID is triggered. Methods that include...

2. Adding new vehicle events received from the vehicle components of the aforementioned vehicle to the event log, Based on the aforementioned temporary event ID, it is determined whether the new vehicle event belongs to the aforementioned unregistered event type, The method according to claim 1, further comprising:

3. The method according to claim 2, wherein determining whether the new vehicle event belongs to the registered event type based on the temporary event ID is performed using a machine learning (ML) model.

4. The method according to claim 1 or 2, wherein generating the temporary event ID is based on a hash using at least one of the source vehicle components of the vehicle and the message in the vehicle event.

5. The method according to claim 1 or 2, further comprising adding registered event types and responses relating to the vehicle associated with the registered event types to the database.

6. The method according to claim 1 or 2, wherein the predetermined threshold and the response relating to the vehicle associated with the temporary event ID are stored in the database.

7. The method according to claim 1 or 2, wherein the trigger for the response relating to the vehicle includes sending a message to a cloud network.

8. A device for managing vehicle event data, which is performed by the vehicle's electronic control unit (ECU), wherein the device is At least one memory for storing computer executable instructions, At least one processor, The system comprises, and the at least one processor executes the computer executable instructions, Determine that the vehicle event in the event log belongs to an unregistered event type. A temporary event identifier (ID) is generated based on at least one characteristic of the vehicle event. The aforementioned temporary event ID is stored in the database along with the timestamp. Determine whether the number of vehicle events in the event log having the aforementioned temporary event ID exceeds a predetermined threshold representing the number of abnormal events. A device configured to trigger a response relating to the vehicle associated with the temporary event ID, based on a determination that the number of vehicle events exceeds a predetermined threshold.

9. The at least one processor further executes the computer executable instructions: New vehicle events received from the vehicle components of the aforementioned vehicle are added to the event log. The apparatus according to claim 8, configured to determine whether the new vehicle event belongs to the unregistered event type based on the temporary event ID.

10. The apparatus according to claim 9, wherein the at least one processor is configured to determine, by using a machine learning (ML) model, whether the new vehicle event belongs to the registered event type based on the temporary event ID.

11. The apparatus according to claim 8 or 9, wherein the at least one processor is configured to generate the temporary event ID based on a hash using at least one of the source vehicle components of the vehicle and the messages in the vehicle event.

12. The at least one processor further executes the computer executable instructions: The apparatus according to claim 8 or 9, configured to add registered event types and responses relating to the vehicle associated with the registered event types to the database.

13. The apparatus according to claim 8 or 9, wherein the predetermined threshold and the response relating to the vehicle associated with the temporary event ID are stored in the database.

14. The apparatus according to claim 8 or 9, wherein the at least one processor is configured to trigger the response relating to the vehicle by sending a message to a cloud network.

15. A non-temporary computer-readable recording medium wherein instructions are recorded on the non-temporary computer-readable recording medium to perform a method for managing vehicle event data performed by the vehicle's electronic control unit (ECU), and the method is: To determine if a vehicle event in the event log belongs to an unregistered event type, A temporary event identifier (ID) is generated based on at least one characteristic of the aforementioned vehicle event, The aforementioned temporary event ID is stored in the database along with the timestamp, Determining whether the number of vehicle events in the event log having the aforementioned temporary event ID exceeds a predetermined threshold representing the number of abnormal events, Based on the determination that the number of vehicle events exceeds the predetermined threshold, a response relating to the vehicle associated with the temporary event ID is triggered. Non-temporary computer-readable recording media, including [specific type of media].

16. The aforementioned method, Adding new vehicle events received from the vehicle components of the aforementioned vehicle to the event log, Based on the aforementioned temporary event ID, it is determined whether the new vehicle event belongs to the aforementioned unregistered event type, A non-temporary computer-readable recording medium according to claim 15, further comprising:

17. The non-temporary computer-readable recording medium according to claim 16, wherein determining whether the new vehicle event belongs to the registered event type based on the temporary event ID is performed using a machine learning (ML) model.

18. The non-temporary computer-readable recording medium according to claim 15 or 16, wherein generating the temporary event ID is based on a hash using at least one of the source vehicle components of the vehicle and the messages in the vehicle event.

19. The aforementioned method, The non-temporary computer-readable recording medium according to claim 15 or 16, further comprising adding registered event types and responses relating to the vehicle associated with the registered event types to the database.

20. The non-temporary computer-readable recording medium according to claim 15 or 16, wherein the predetermined threshold and the response relating to the vehicle associated with the temporary event ID are stored in the database.

Images