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] Systems and methods consistent with exemplary embodiments of the present disclosure relate to providing a method for managing vehicle event data. [Background technology]

[0002] In the related art, vehicles, and particularly vehicle components (e.g., lights, brakes, sensors, etc.), may generate vehicle data. A subset of that vehicle data may be referred to as an event, which may be a short message sent to a log and / or other database residing on the vehicle or elsewhere. For example, if a vehicle experiences a collision, an impact sensor may log a collision event, which may be packaged and sent (e.g., to a cloud network). Events may have pre-defined types as part of a standard, so that a vehicle may be configured to take action based on receiving a particular event. For example, if a collision event is received, the vehicle may be configured to automatically contact emergency services.

[0003] A problem arises when a vehicle component may log an unexpected event for which it is not defined (e.g., the unexpected event is not published as part of a standard), and therefore the event may be logged without being properly registered, and no action can be taken on the event.

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

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

[0006] Thus, anomaly detection for non-default (unregistered event types) events can be considered as part of the standard, and an appropriate response can be made to the non-default events because the response is based on thresholds for receiving similar vehicle events.

[0007] According to an embodiment, there may be provided a method for managing vehicle event data performed by an electronic control unit (ECU) of a vehicle. 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 a number of vehicle events in the event log having the temporary event ID exceeds a predetermined threshold, and triggering a response related to the vehicle associated with the temporary event ID based on a determination that the number of vehicle events exceeds the predetermined threshold.

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

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

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

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

[0012] The predetermined threshold and the response for the vehicle associated with the temporary event ID may be stored in a database.

[0013] Triggering a response for the vehicle may include sending a message to a cloud network.

[0014] According to an embodiment, an apparatus for managing vehicle event data performed by an electronic control unit (ECU) of a vehicle may be provided. The apparatus may include at least one memory that stores computer-executable instructions and at least one processor, where the at least one processor is configured to execute the computer-executable instructions to determine that a vehicle event in an event log belongs to an unregistered event type, generate a temporary event identifier (ID) based on at least one characteristic of the vehicle event, store the temporary event ID in a database along with a timestamp, determine whether a number of vehicle events in the event log having the temporary event ID exceeds a predetermined threshold, and trigger a response related to the vehicle associated with the temporary event ID based on a determination that the number of vehicle events exceeds the predetermined threshold.

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

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

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

[0018] The at least one processor may be further configured to execute the computer-executable instructions to add the registered event types and responses for the vehicles associated with the registered event types to the database. The predetermined threshold and responses for the vehicles associated with the temporary event ID may be stored in the database.

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

[0020] Additional aspects will be set forth in part in the description that follows, and in part will be apparent from the description, or may be learned by practice of presented embodiments of the present disclosure. [Brief explanation of the drawings]

[0021] Features, aspects, and advantages of certain preferred embodiments of the present disclosure are described below with reference to the accompanying drawings, in which like reference numerals refer to like elements. [Figure 1] FIG. 1 shows a diagram of exemplary components of a device according to one or more embodiments. [Figure 2] FIG. 2 illustrates a diagram of example components of a system for processing vehicle event data according to one or more example embodiments. [Figure 3] FIG. 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] FIG. 4 is a flowchart diagram illustrating a vehicle event data management process for adding new vehicle events to an event log according to one or more exemplary embodiments. [Figure 5] FIG. 5 is a flowchart diagram illustrating a vehicle event data management process for processing receipt of multiple messages from multiple vehicle components to trigger a vehicle response according to one or more exemplary embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0022] The following detailed description of exemplary embodiments refers to the accompanying drawings. While the present disclosure provides illustration and description, it is not intended to be exhaustive or to limit one or more exemplary embodiments to the precise form disclosed. Modifications and variations are possible in light of the disclosure or may be learned from the practice of one or more exemplary embodiments. Moreover, one or more features or components of one exemplary embodiment may be incorporated into or combined with another exemplary embodiment (or one or more features of another exemplary embodiment). Furthermore, 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 occur (at least partially) concurrently, or the order of one or more operations may be switched.

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

[0024] Although particular combinations of features are recited in the claims and / or disclosed herein, such combinations are not intended to limit the disclosure of possible example embodiments. Indeed, many of the features may be combined in ways not specifically recited in the claims and / or disclosed herein. Although each dependent claim listed below may depend directly on only one claim, the disclosure of possible example embodiments includes each dependent claim in combination with all other claims in the claim set.

[0025] No element, act, or instruction used herein should be construed as critical or required unless expressly stated otherwise. Also, as used herein, the articles "a" and "an" 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 "a" or similar terms are used. Also, as used herein, the terms "has," "have," "having," "include," "including," and the like are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless expressly stated otherwise. Furthermore, phrases such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include A only, B only, or both A and B.

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

[0027] Referring to FIG. 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), a graphics processing unit (GPU), 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), or another type of processing or computational 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] Storage component 140 may store information and / or software related to the operation and use of device 100. For example, storage 140 may include a hard disk (e.g., a 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-transitory computer-readable medium along with a corresponding drive.

[0030] Input 150 may include one or more components (e.g., a touchscreen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone) that allow device 100 to receive information, such as through user input. Additionally or alternatively, input 150 may include sensors for detecting information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). Output 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 device 100.

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

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

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

[0034] FIG. 2 illustrates a diagram of example components of a system 200 for processing vehicle event data, according to one or more example embodiments. Vehicle components 210, an electronic control unit (ECU) 220, and a cloud network 230 may be provided. 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. Vehicle components 210 may be any component in a vehicle that may implement a function. For example, vehicle components 210 may include, but are not limited to, lights, brakes, and sensors. It should be understood that, depending on the particular implementation, each individual vehicle component may have its own corresponding ECU, or all individual vehicle components may share one central ECU.

[0035] Registration module 221 may allow functions of vehicle components 210 to register their own event types in event type and ID database 224 along with potential responses to the event. According to an embodiment, this may include a user interface (such as a GUI) to allow manufacturers to define new event types and associated potential responses to the event types. During build time, registration module 221 may check to find functions that have registered safety-related responses (e.g., that may require vehicle operator safety). According to an embodiment, new event types may be registered using a standard (e.g., ISO 19770-3).

[0036] The event log analysis module 222 may be a software component that may analyze anomalies in the event log 223. According to an embodiment, the event log analysis module 222 may be configured to determine characteristics of events in the event log 223 and record the characteristics in the event type and ID database 224. The characteristics may include, but are not limited to, the rate of occurrences (total number of occurrences and number of occurrences in a defined time slot) for a particular type of event, the location of the source vehicle component relative to the location of safety-critical infrastructure on the vehicle, the location of the source vehicle component relative to the location of security-critical infrastructure on the vehicle, the specific geolocation of where the event occurred, and the vehicle state (stopped, started, moving, charging, etc.). For example, the safety-critical infrastructure may relate to the safety of the user (e.g., to ensure the safe operability of the vehicle for the user), and the security-critical infrastructure may relate to the security of the vehicle (e.g., against vehicle theft). The event log analysis module 222 may be configured to use the characteristics to determine that a particular vehicle event or multiple 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 be used to evaluate the event log 223 for any vehicle events deemed to belong to an unregistered event type, ingest the event, and 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 is from), the vehicle's distance from the safety and security infrastructure, 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 vehicle's distance from the safety and security infrastructure, and the event message.

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

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

[0040] According to an embodiment, the event log analysis module 222 may delete or instruct the event log 223 to delete at least one previous event based on a determination regarding a storage threshold (e.g., a predetermined period or length of time, a predetermined number of events, etc.). For example, if the previous event is older than the storage 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 storage 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 an embodiment, the event log analysis module 222 may implement a machine learning (ML) model to perform the 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., original equipment manufacturer OEM) and stored in the event type and ID database 224. If the threshold is exceeded, a response may be triggered; for example, the event log 223 may be collected, signed, and sent to the cloud network 230. Additionally, if the event is an anomaly near security / safety-critical infrastructure, a response may be sent to the vehicle component 210 (e.g., turning on the engine warning light). For example, a threshold may be defined as the number of events related to an unregistered event type (or sharing the same temporary event ID) exceeding a predetermined threshold. Alternatively, a threshold may be defined as the number of anomaly events (of an unregistered event type) near security / safety-critical infrastructure exceeding a predetermined threshold. It should be understood by those skilled in the art that the thresholds and responses defined for the event log analysis module 222 may depend on the particular implementation.

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

[0043] At operation 310, a vehicle event in an event log (such as event log 223) may be determined as to whether the vehicle event belongs to an unregistered event type. According to an embodiment, the determination may be based on detecting that the vehicle event does not belong to any registered event type. Additionally or alternatively, the determination may be based on an analysis of features in the event log, such as the percentage of occurrences (total number of occurrences and number of occurrences in a defined time slot) for a particular type of event, the location of the source vehicle component with respect to the location of safety-critical infrastructure on the vehicle, the location of the source vehicle component with respect to the location of security-critical infrastructure on the vehicle, the specific geolocation of where the event occurred, and the vehicle state (stopped, started, moving, charging, etc.).

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

[0045] At operation 330, the temporary event ID may be stored in a database along with a timestamp. For example, this may be a database such as the event type and ID database 224 described above with respect to FIG.

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

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

[0048] For example, if there are three events associated with a message about a vehicle failing to start and a predefined threshold is two, 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 performed. According to an embodiment, the response may include sending and / or signing the data to a cloud network (e.g., cloud network 230). The cloud network may take action, such as performing analysis or recognizing patterns in the data, and may take further action, such as contacting emergency services. Nevertheless, it should be understood by those skilled in the art that the particular response may depend on the particular implementation.

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

[0050] At operation 410, a new vehicle event may be received from a vehicle component of the vehicle (e.g., vehicle component 210) and added to an event log (e.g., event log 223). For example, this may be an event received from a front driver's side light. According to some embodiments, a message may first be received from the vehicle component and then entered into the event log as an event (the event may include additional data aside from what was received as a message from the vehicle component).

[0051] At operation 420, a determination may be made as to whether the new vehicle event added to the event log belongs to an unregistered event type. This may include first ascertaining whether the new vehicle event belongs to any predefined registered event type based on an analysis with reference to the event type and ID database 224 (if it belongs to a predefined registered event type, further determination may not be necessary). The determination may also include analyzing whether the new vehicle event matches / corresponds to a temporary event ID located in the event type and ID database, and concluding that it is an unregistered event type based on a determination that it matches / corresponds. 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 characteristic of the vehicle event. This may be similar to operations 310 and 320 with reference to FIG. 3 above.

[0052] If it is determined in operation 420 that the new vehicle event to be added to the event log is not an unregistered event type (e.g., it is 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 have already been defined in the event type and ID database 224 by the registration module 221, and thus the response may be triggered based on checking 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 an amount of weight that exceeds a threshold but the seat belt is unfastened may be defined as a registered event type, and the ECU may check for and execute the associated vehicle response, which may default to illuminating a seat belt indicator light (instructing the passenger to fasten their seat belt).

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

[0054] If it is determined in operation 440 that the number of vehicle events exceeds a predetermined threshold, a response associated with the temporary ID may be triggered for the vehicle in operation 450. This may be similar to operation 350 described above with reference to FIG.

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

[0056] At operation 510, n# messages may be received from multiple vehicle components. In particular, the messages may be received from different vehicle lights attempting to start the vehicle (which may indicate that the attempt to start the vehicle failed). The messages may be security-related and are typically signed. For example, for a total of three messages, one message may be from a light on the front driver's side and two may be from lights on the front passenger's side. It should be understood that, depending on the particular scenario, messages may be received from other groups of vehicle components that may be used to receive messages (i.e., a driver's side seat sensor and a passenger's side seat sensor).

[0057] At operation 520, it may be determined that the signature of the message received at operation 510 has failed or is abnormal. Therefore, the ECU may log n# vehicle events corresponding to each message received at operation 510 in an event log. In this case, because the signature of the message has 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 the unregistered event type. While logging the event, the ECU may consider that the vehicle components are approximately equidistant from the ECU and have the same location with respect to the safety-critical infrastructure in the vehicle. Therefore, based on this, the ECU may consider each of the n# vehicle events to belong to the same unregistered event type during logging. Based on the example described at operation 510 regarding receiving a message from a front driver's side light and two messages from a front passenger's side light, a total of three vehicle events may be added to the event log corresponding to each message.

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

[0059] If it is determined in operation 530 that n # vehicle events exceed a pre-defined OEM-defined threshold, an associated response for the vehicle may be triggered in operation 540. This may be an OEM-defined response (which may be pre-defined in event type and ID database 224). For example, if more than two events are received, the OEM-defined response may be to prevent the vehicle from starting for a period of time (e.g., four hours). This may be for a security-related event to prevent thieves from stealing the vehicle. The ECU may accordingly communicate to some other component in the vehicle (e.g., data communications module (DCM)) that the vehicle has entered a lockdown state, collect an event log, sign the event log, and transmit the event log off-vehicle (e.g., to cloud network 230) for analysis. The event log may be analyzed to determine if its patterns match common passenger vehicle event log strategies, and law enforcement and / or emergency services may be contacted. Nevertheless, the specific OEM-defined response may depend on the particular implementation as determined by the vendor.

[0060] Based on the above embodiments, it can be seen that anomaly detection for events that are not default (are unregistered event types) as part of the standard can be considered, and an appropriate response can be made to the non-default events because the response is based on a threshold for receiving similar vehicle events.

[0061] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the exemplary embodiment or embodiments to the precise forms disclosed. Modifications and variations are possible in light of the disclosure or may be learned from practice of the exemplary embodiment or 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 above-described components may be implemented as instructions stored on 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-transitory storage medium (or media) having computer-readable program instructions that cause a processor to perform operations.

[0063] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, 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 suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: 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 disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge-in-groove structures with instructions recorded thereon, and any suitable combination thereof. As used herein, computer-readable storage media should not be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over wires.

[0064] The computer-readable program instructions described herein may be downloaded to each computing / processing device from a computer-readable storage medium, or 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 fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing / processing device.

[0065] The computer-readable program code / instructions for performing operations 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 or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++, or the like, and procedural programming languages such as the "C" programming language or similar programming languages. The 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 a wide area network (WAN), or the connection to the external computer may be made (e.g., through the Internet using an Internet Service Provider). In one or more exemplary 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 utilizing state information of the computer-readable program instructions to personalize the electronic circuit to perform an aspect or operation.

[0066] The computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to create a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the function(s) / act(s) specified in the block(s) of the flowcharts and / or block diagrams. The computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions that implement aspects of the function(s) / act(s) specified in the block(s) of the flowcharts and / or block diagrams.

[0067] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to create a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the function / act specified in the block or blocks of the flowcharts and / or block diagrams.

[0068] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible example implementations of systems, methods, and computer-readable media 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 portion of an instruction set, comprising one or more executable instructions that implement the specified logical function(s). The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks compared to those depicted in the figures. In one or more alternative exemplary embodiments, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed concurrently or substantially concurrently, or the blocks may even be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or acts or executes a combination of dedicated hardware and computer instructions.

[0069] It will be apparent 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 specialized control hardware or software code used to implement the systems and / or methods is not a limitation of one or more exemplary embodiments. Thus, 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 can be designed to implement the systems and / or methods based on the description herein.

Claims

1. 1. A method for managing vehicle event data performed by an electronic control unit (ECU) of a vehicle, the method comprising: determining that a vehicle event in the 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 together with a timestamp in a database; determining whether a number of vehicle events in the event log having the temporary event ID exceeds a predetermined threshold; triggering a response for the vehicle associated with the temporary event ID based on a determination that the number of vehicle events exceeds the predetermined threshold; A method comprising:

2. adding new vehicle events received from vehicle components of the vehicle to the event log; determining whether the new vehicle event belongs to the unregistered event type based on the temporary event ID; The method of claim 1 further comprising:

3. The method of 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. 3. The method of claim 1 or 2, wherein generating the temporary event ID is based on a hash using at least one of a source vehicle component of the vehicle, a distance of the source vehicle component from a safety and security infrastructure in the vehicle, and a message in the vehicle event.

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

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

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

8. 1. An apparatus for managing vehicle event data performed by an electronic control unit (ECU) of a vehicle, the apparatus comprising: at least one memory storing computer-executable instructions; at least one processor; wherein the at least one processor executes the computer-executable instructions to determining that a vehicle event in the 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 together with a timestamp in a database; determining whether the number of vehicle events in the event log having the temporary event ID exceeds a predetermined threshold; The apparatus is configured to trigger a response for the vehicle associated with the temporary event ID based on a determination that the number of vehicle events exceeds the predetermined threshold.

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

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

11. 10. The apparatus of 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 a source vehicle component of the vehicle, a distance of the source vehicle component from a safety and security infrastructure in the vehicle, and a message in the vehicle event.

12. The at least one processor further executes the computer-executable instructions to:

10. 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. 10. The apparatus of claim 8 or 9, wherein the predetermined threshold and the response for the vehicle associated with the temporary event ID are stored in the database.

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

15. 1. A non-transitory computer-readable storage medium having instructions recorded thereon for performing a method for managing vehicle event data performed by an electronic control unit (ECU) of a vehicle, the method comprising: determining that a vehicle event in the 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 together with a timestamp in a database; determining whether a number of vehicle events in the event log having the temporary event ID exceeds a predetermined threshold; triggering a response for the vehicle associated with the temporary event ID based on a determination that the number of vehicle events exceeds the predetermined threshold; A non-transitory computer-readable recording medium comprising:

16. The method comprises: adding new vehicle events received from vehicle components of the vehicle to the event log; determining whether the new vehicle event belongs to the unregistered event type based on the temporary event ID; 16. The non-transitory computer-readable storage medium of claim 15, further comprising:

17. 17. The non-transitory computer-readable storage medium of 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. 17. The non-transitory computer-readable storage medium of claim 15 or 16, wherein generating the temporary event ID is based on a hash using at least one of a source vehicle component of the vehicle, a distance of the source vehicle component from a safety and security infrastructure in the vehicle, and a message in the vehicle event.

19. The method comprises: The non-transitory computer-readable storage medium of claim 15 or 16, further comprising adding registered event types and responses for the vehicle associated with the registered event types to the database.

20. 17. The non-transitory computer-readable storage medium of claim 15 or 16, wherein the predetermined threshold and the response for the vehicle associated with the temporary event ID are stored in the database.

Images