Method, apparatus and program product for managing vehicle event data

Abstract

The present disclosure provides a method, an apparatus, and a program product for managing vehicle event data. The present disclosure provides methods, systems, and devices for managing vehicle event data associated with a vehicle. The method may be implemented by an electronic control unit (ECU) of a vehicle, may include: determining that a vehicle event in an event log belongs to an unregistered event type; generating a temporary event identifier (ID) representing a characteristic of the vehicle event; storing the temporary event ID and the timestamp in a database; determining whether the number of vehicle events in the event log having the same temporary event ID exceeds a predetermined threshold value; and triggering a vehicle-related response associated with the temporary event ID based on a determination that the number of vehicle events exceeds a prescribed threshold.

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 Art

[0002] In the related art, vehicles, particularly vehicle components (e.g., lights, brakes, sensors, etc.), can generate vehicle data. A subset of this vehicle data can be referred to as an event, which can be a short message to be sent to logs and / or other databases present in the vehicle or other locations. For example, in the case where a vehicle experiences a collision, an impact sensor can log the collision event, and the event can be encapsulated and sent (e.g., sent to a cloud network). Events can have a predefined type as part of a standard, so a vehicle can be configured to take measures based on the receipt of a specific event. For example, a vehicle can be configured to automatically contact emergency services upon receiving a collision event.

[0003] Vehicle components may log events that are not predefined and unexpected (e.g., the unexpected event is not published as part of the standard), so the event may be logged without proper registration and no measures can be taken for the event, which can cause problems in this case.

[0004] Therefore, there is a need for a method for processing the registration of unexpected / anomalous events and for processing responses to vehicle events. Summary of the Invention

[0005] According to one or more exemplary embodiments, there is provided an apparatus and a method for managing vehicle event data of a vehicle. In particular, the apparatus and method of the exemplary embodiments can be implemented by an electronic control unit (ECU) of a vehicle and can include: determining that a vehicle event in an event log belongs to an unregistered event type; generating a temporary event identifier (ID: identifier) representing the characteristics 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 same temporary event ID exceeds a specified threshold; and triggering a vehicle-related response associated with the temporary event ID based on the determination that the number of vehicle events exceeds the specified threshold.

[0006] Therefore, anomaly detection related to events that are not predefined as part of the standard (as unregistered event types) can be considered, and since the response is based on a threshold related to the receipt of the same vehicle event, an appropriate response can be made for unregistered events.

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

[0008] The method may further include: appending a new vehicle event received from a vehicle component of the vehicle to the 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, and the determination is performed using a machine learning (ML) model.

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

[0011] The method may further include: appending a registered event type and a vehicle-related response associated with the registered event type to the database.

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

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

[0014] According to an embodiment, a device for managing vehicle event data implemented by an electronic control unit (ECU) of a vehicle can be provided. The device may include: at least one memory storing computer-executable instructions; and at least one processor configured to execute the computer-executable instructions to: determine whether a vehicle event in an event log belongs to an unregistered event type; generate a temporary event identifier (ID) based on at least one feature of the vehicle event; store the temporary event ID together with a timestamp in a database; determine whether the number of vehicle events in the event log with the temporary event ID exceeds a specified threshold; and trigger a vehicle-related response associated with the temporary event ID based on the determination that the number of vehicle events exceeds the specified threshold.

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

[0016] The at least one processor may be configured to: determine whether a new vehicle event belongs to a registered event type based on the temporary event ID 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 value, where the hash value is obtained by using at least one of a source vehicle component of the vehicle, a distance of the source vehicle component from a safety infrastructure and a security infrastructure in the vehicle, and a message in the vehicle event.

[0018] The at least one processor may further be configured to execute the computer-executable instructions to: append a registered event type and a vehicle-related response associated with the registered event type to the database. The specified threshold and the vehicle-related response associated with the temporary event ID may be stored in the database.

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

[0020] Additional aspects will be described in part in the following description, may be partially apparent from the description, or may be implemented by the practice of the presented embodiments of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Hereinafter, features, aspects, and advantages of specific preferred embodiments of the present disclosure will be described with reference to the accompanying drawings, in which like reference numerals represent like elements.

[0022] Figure 1 A diagram showing exemplary components of a device representing more than one embodiment.

[0023] Figure 2 A diagram related to exemplary components of a system for processing vehicle event data representing more than one exemplary embodiment.

[0024] Figure 3 A flowchart showing a vehicle event data management process for generating temporary event identifiers (IDs) representing more than one exemplary embodiment.

[0025] Figure 4 A flowchart showing a vehicle event data management process for adding new vehicle events to an event log representing more than one exemplary embodiment.

[0026] Figure 5 A flowchart showing a vehicle event data management process for processing the reception of multiple messages from multiple vehicle components and triggering a vehicle response representing more than one exemplary embodiment. Detailed Description

[0027] The following detailed description of exemplary embodiments will refer to the accompanying drawings. The present disclosure provides examples and explanations, but is not intended to be exhaustive, nor is it intended to limit more than one exemplary embodiment to the exact forms disclosed. Modifications and variations can be made in view of the present disclosure, or can be learned from the implementation of more than one exemplary embodiment. Moreover, one or more features or components of one exemplary embodiment can be incorporated into another exemplary embodiment (or one or more features of another exemplary embodiment), or can be combined with it. Also, it can be understood that in the flowchart and description of operations provided in this specification, one or more operations can be omitted, one or more operations can be added, one or more operations can be (at least partially) performed simultaneously, or the order of one or more operations can be switched.

[0028] It is obvious that the exemplary embodiments of the systems and / or methods and / or non-transitory computer-readable storage media described in this specification can be implemented in various forms of hardware, firmware, or a combination of hardware and software. There is no limitation to more than one exemplary embodiment on the actual dedicated control hardware or software code used to implement the system and / or method. Therefore, the operations and behaviors of the system and / or method and / or non-transitory computer-readable storage media are described in this specification without reference to specific software code. It can be understood that software and hardware can be designed to implement the system and / or method based on the description in this specification.

[0029] Even if a particular combination of features is recited in the claims and / or disclosed in the specification, that combination is not intended to limit the disclosure of possible exemplary embodiments. In fact, many of these features may be combined in ways not specifically recited in the claims and / or not disclosed in the specification. 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 in combination with all the other claims within the set of claims.

[0030] Unless specifically stated otherwise, elements, acts, or instructions used in this specification should not be construed as critical or essential. Additionally, the articles "a" and "an" used in this specification are intended to include more than one item and may be used interchangeably with "more than one". When only one item is meant, the term "one" or equivalent is used. Further, the terms "has", "have", "having", "include", "including", or similar terms used in this specification are meant to be open-ended terms. Also, unless specifically stated otherwise, the phrase "based on..." means "at least partially based on...". Moreover, 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.

[0031] Figure 1 A diagram showing exemplary components of device 100 representing more than one embodiment. Device 100 can be used (as described below) to implement Figure 2 the ECU 220 described in relation to

[0032] 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.

[0033] The bus 110 may include more than one component that permits communication among the components of the device 100. The processor 120 may be implemented by hardware, firmware, or a combination of hardware and software. The 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 component or computing component. In some implementations, the processor 120 may include more than one processor programmable to perform functions. The memory 130 may include a random access memory (RAM), a read only memory (ROM), and / or another type of dynamic storage device or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions for use by the processor 120.

[0034] The storage unit 140 may store information and / or software related to the operation and use of the device 100. For example, the storage unit 140 may include corresponding drivers and include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, and / or a solid state drive), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium.

[0035] The input unit 150 may include more than one component that permits the device 100 to receive information via user input or the like (e.g., a touch screen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone). Further or alternatively, the input unit 150 may include sensors for sensing information (e.g., a Global Positioning System (GPS) component, an accelerometer, a gyroscope, and / or an actuator). The output unit 160 may include more than one component that provides output information from the device 100 (e.g., a display, a speaker, and / or more than one Light Emitting Diode (LED)).

[0036] The communication interface 170 may include components such as a transceiver that enables the device 100 to communicate with other devices via a wired connection, a wireless connection, or a combination of a wired connection and a wireless connection, etc. (e.g., a transceiver and / or separate receivers and transmitters). The communication interface 170 may permit the device 100 to receive information from another device (e.g., a device included in multiple vehicles, etc.) and / or provide information to the other device. 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 Wireless Fidelity (Wi-Fi) interface, a cellular network interface, or similar interfaces.

[0037] The device 100 may perform one or more processes described in this specification in response to the processor 120 executing software instructions stored in a non-transitory computer-readable medium such as the memory 130 and / or the storage unit 140. The computer-readable medium is determined to be a non-transitory storage device in this specification. The storage device includes a storage space within a single physical storage device or a storage space extended across multiple physical storage devices.

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

[0039] Figure 2 FIG. is related to exemplary components of a system 200 for processing vehicle event data in more than one exemplary embodiment. 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 perform a function. For example, the vehicle component 210 may include lights, brakes, and sensors, but is not limited thereto. It should be understood that according to a particular implementation, each of the individual vehicle components may have its own corresponding ECU, or all of the individual vehicle components may share a central ECU.

[0040] The registration module 221 may enable the functions of the vehicle component 210 to register its own event type and possible responses to the event in the event type and ID database 224. According to an embodiment, the registration module may include a user interface (such as a GUI (Graphical User Interface)) to enable a manufacturer to determine new event types and possible responses to the associated event types. During build time, the registration module 221 may perform a check to retrieve the function of the registered (e.g., safety-related responses that may require the safety of the vehicle operator) safety-related responses. According to an embodiment, new event types may be registered using a standard (e.g., ISO19770-3).

[0041] The event log analysis module 222 may be a software component capable of analyzing anomalies in the event log 223. According to an embodiment, the event log analysis module 222 may be configured to determine the characteristics of the events in the event log 223 and record the characteristics in the event type and ID database 224. The characteristics may include the ratio of occurrences related to a particular type of event (the overall number of occurrences and the number of occurrences within a determined time slot), the location of the source vehicle component related to the configuration of the safety infrastructure in the vehicle, the location of the source vehicle component related to the configuration of the security infrastructure in the vehicle, the specific geolocation of the location where the event occurred, and the vehicle state (stopped, started, moving, charging, etc.), but are not limited thereto. For example, the safety infrastructure may be associated with the safety of the user (e.g., to assure the user of the safe operation of the vehicle), and the security infrastructure may be associated with 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 whether a particular vehicle event or multiple vehicle events belong to an unregistered event type.

[0042] The event log analysis module 222 can be configured to generate a temporary event identifier (ID) for an unregistered event type. In particular, the event log analysis module 222 can be used to evaluate the event log 223 for any vehicle event considered to belong to an unregistered event type, introduce the event, and thus generate an original hash value that can be used as a temporary event ID. The temporary event ID can be based on the source of the event (e.g., which vehicle component the event originated from), the distance from the safety infrastructure and security infrastructure in the vehicle, and the event message. For example, a hash algorithm function can generate a hash value (i.e., the temporary event ID or at least a part of the temporary event ID) by using (or inputting) at least one of the source of the event, the distance from the safety infrastructure and security infrastructure in the vehicle, and the event message.

[0043] According to an embodiment, the temporary event ID can be stored in the event type and ID database 224 together with a timestamp. When any other same event (e.g., the same event, an event having at least a threshold number of common predefined event parameters or features, an event included within a predefined group of events, etc.) is received, the same temporary event ID (e.g., generated by a hash algorithm) or a similar temporary event ID can be stored in the event type and ID database 224.

[0044] According to an embodiment, the event log analysis module 222 can also be configured to confirm in the case where a new event is appended to the event log 223 (or based on a new event being appended to the event log 223) to investigate whether there is a previous (or older) event of the same type in the event log 223 at least partially based on the temporary event ID. The event log analysis module 222 can determine whether the temporary event ID has at least a predefined degree of similarity or repeatability by using a machine learning (ML) model and / or features determined based on the events in the event log 223, thereby determining the previous event as being of the same (or similar) type.

[0045] According to an embodiment, the event log analysis module 222 may delete the event log 223 or instruct the event log 223 in a manner that deletes at least one previous event based on a determination related to a storage threshold (e.g., a specified period or length of time, a specified number of events, etc.). For example, in the case where the previous event is older than the storage threshold (e.g., the specified 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, in the case where the number of previous events of the same type in the event log 223 exceeds the storage threshold (e.g., the specified number of events), the event log analysis module 222 may instruct the event log 223 to delete the oldest previous event.

[0046] According to an embodiment, the event log analysis module 222 may implement a machine learning (ML) model for analysis. The analysis may be performed in a manner that determines whether the number of vehicle events of a specific type (e.g., sharing the same temporary event ID) exceeds a threshold. The threshold may be determined by a vehicle vendor (e.g., an original equipment manufacturer OEM (Original Equipment Manufacturer)) and stored in the event type and ID database 224. In the case where 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. In addition, in the case where the event is an anomaly near the security / safety infrastructure, a response may be sent to the vehicle component 210 (e.g., turning on the engine warning light). For example, the threshold that may be determined is the number of events related to an unregistered event type (or sharing the same temporary event ID) that exceeds a specified threshold. Alternatively, the threshold that may be determined is the number of anomaly events (of an unregistered event type) near the security / safety infrastructure that exceeds a predefined threshold. Those skilled in the art should understand that the determined threshold and response related to the event log analysis module 222 may depend on a specific implementation.

[0047] Figure 3 An exemplary flowchart of a vehicle event data management process 300 for generating a temporary event identifier (ID) representing an embodiment is shown. The process 300 may be implemented using the Figure 2 system 200 described above, particularly using the ECU 220.

[0048] In operation S310, regarding vehicle events in an event log (such as event log 223), it can be determined whether the vehicle event belongs to an unregistered event type. According to an embodiment, the determination can be based on the detection that the vehicle event does not belong to any registered event type. Further or alternatively, the determination can be based on an analysis of features in the event log (e.g., the ratio of occurrences related to a specific type of event (the total number of occurrences and the number of occurrences within a determined time slot), the location of source vehicle components in the vehicle related to the configuration of the safety infrastructure, the location of source vehicle components in the vehicle related to the configuration of the security infrastructure, the specific geolocation of the location where the event occurred, and the vehicle state (stopped, starting, moving, charging, etc.)).

[0049] In operation S320, a temporary event ID that can represent the features of the vehicle event can be generated. According to an embodiment, the temporary event ID can be generated based on a hash function that takes the features of the vehicle event as input. The features can include at least one of the source vehicle components of the vehicle, the distance of the source vehicle components from the safety infrastructure and the security infrastructure in the vehicle, and the message in the vehicle event.

[0050] In operation S330, the temporary event ID can be stored in a database together with a timestamp. For example, the database can be a database such as the event type and ID database 224 described above in relation to Figure 2 the relevant records.

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

[0052] In operation S350, based on the determination that the number of vehicle events exceeds the predetermined threshold (based on the determination in operation S340), a vehicle-related response associated with a specific temporary event ID can be triggered. The response can be pre-stored in a database (event type and ID database 224) in a manner associated with the temporary event ID.

[0053] For example, in a situation where there are three events associated with a message related to the failure of starting a vehicle and a predefined threshold is 2, an appropriate trigger stored in the database (e.g., lockout of the vehicle) can be executed. This can be for preventing vehicle theft, in which case the events are interpreted as security related. Alternatively, in a situation where the events are safety related, a safety related response can be made. According to an embodiment, the response can include sending data to a cloud network (e.g., cloud network 230) and / or signing the data. The cloud network can take measures such as performing analysis, identifying patterns in the data, etc., and can take further measures such as contacting emergency services. Nevertheless, those skilled in the art should understand that the specific response depends on the specific implementation scenario.

[0054] Figure 4 is a flowchart of a vehicle event data management process 400 for adding new vehicle events to an event log, which represents more than one exemplary embodiment. The process 400 can be implemented using the above Figure 2 system 200, particularly using the ECU 220.

[0055] In action S410, a new vehicle event can 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, the new vehicle event can be an event received from the front driver-side light. According to some embodiments, it can be that first, a message is received from the vehicle component and then input as an event into the event log (the event can include further data in addition to the data received as a message from the vehicle component).

[0056] In action S420, it can be determined whether the new vehicle event added to the event log belongs to an unregistered event type. This determination can include: first, based on an analysis obtained by referring to the event type and ID database 224, confirming whether the new vehicle event belongs to any predefined registered event type (in a situation where the new vehicle event belongs to a predefined registered event type, further determination may not be required). The determination can also include: analyzing whether the new vehicle event is consistent / corresponds with a temporary event ID located in the event type and ID database; and based on the determination that the new vehicle event is consistent / corresponds with the temporary event ID located in the event type and ID database, making a conclusion that the new vehicle event is an unregistered event type. It can be that in a situation where the new vehicle event is not consistent with any existing temporary event ID, a conclusion that the new vehicle event is an unregistered event type is still made in the analysis, and a new temporary event ID representing the characteristics of the vehicle event is generated. Refer to the above Figure 3, this action may be the same as actions S310 and S320.

[0057] When it is determined in action S420 that the new vehicle event to be added to the event log is not an unregistered event type (for example, the new vehicle event is a registered event type), in action S430, the ECU may trigger a vehicle response associated with the registered event type. The vehicle response and the associated registered event type may have been determined by the registration module 221 in the event type and ID database 224, so the response can be triggered based on the confirmation of the corresponding vehicle response in the event type and ID database 224. For example, a seat weight sensor event generated when a weight exceeding a threshold is detected on the passenger seat but the seat belt is unfastened can be determined as a registered event type, and the ECU can confirm the associated vehicle response and execute the associated vehicle response, where the associated vehicle response may be set as the lighting of a seat belt display light (indicating that the passenger fastens their own seat belt).

[0058] When it is determined in action S420 that the new vehicle event type to be added to the event log is an unregistered event type, in action S440, the ECU may determine whether the number of vehicle events of the unregistered type with the same temporary event ID as the new vehicle event exceeds a threshold determined as the number of vehicle events. This action may be the same as action S340 described above with reference to Figure 3 and described.

[0059] When it is determined in action S440 that the number of vehicle events exceeds the specified threshold, in action S450, a response associated with the temporary event ID can be triggered for the vehicle. This action is the same as action S350 described above with reference to Figure 3 and described.

[0060] Figure 5 It is a flowchart of a vehicle event data management process 500 for processing the reception of multiple messages from multiple vehicle components and triggering vehicle responses, representing one or more exemplary embodiments.

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

[0062] In action S520, it can be determined that the signature of the messages received in action S510 fails or is abnormal. Therefore, the ECU can record n# vehicle event logs corresponding to each of the messages received in action S510 in the event log. In this case, since the signature of the message fails, the vehicle event can be determined to belong to an unregistered event type. Therefore, it should be understood that a temporary event ID can be generated or, for unregistered event types, a temporary event ID may already exist. During the logging of the event, the ECU can consider that the vehicle components are approximately equidistant from the ECU and are in the same location related to the safety infrastructure within the vehicle. Therefore, based on the above, the ECU can consider that in the logging, the n# vehicle events each belong to the same unregistered event type. Based on the example described in action S510 for the case of receiving two messages from the driver's side light in the front and the passenger side lights in the front, a total of three vehicle events can be added to the event log corresponding to each message.

[0063] In action S530, it can be determined that the number n# of vehicle events logged in action S520 exceeds a predefined OEM-defined threshold (which may be predefined in the event type and ID database 224). For example, when the predefined OEM threshold is set to two events, the three events logged related to the example described in action S520 can be considered to exceed the predefined OEM threshold.

[0064] In the case where it is determined in operation S530 that the number of vehicle events with number n# exceeds a predefined OEM-defined threshold, in operation S540, a response associated with the vehicle establishment can be triggered. This response can be an OEM-defined response (which may be predefined in the event type and ID database 224). For example, when more than two events are received, the OEM-defined response can be to prevent the vehicle from starting for a certain period (e.g., four hours). This OEM-defined response can be a security-related event response for preventing vehicle theft by thieves. The ECU can, in accordance with this response, convey the situation that the vehicle has entered the locked state to some other components in the vehicle (e.g., the data communication module (DCM: Data Communication Module)), collect event logs, sign the event logs, and send the event logs outside the vehicle (e.g., send them to the cloud network 230) for analysis. The event logs can be analyzed to determine if their patterns are consistent with the policies of event logs of general passenger vehicles, and law enforcement and / or emergency services can be contacted. Nevertheless, a specific OEM-defined response can also depend on a specific implementation in a manner determined by the supplier.

[0065] Based on the above-described embodiments, it can be understood that anomaly detection related to events (as unregistered event types) not predefined as part of the standard can be considered. Since the response is based on a threshold related to the reception of the same vehicle events, an appropriate response can be made for events not predefined.

[0066] The above disclosure provides examples and explanations, but is not intended to be exhaustive, nor is it intended to limit more than one exemplary embodiment to the exact forms disclosed. Modifications and variations can be made in view of the present disclosure, or can be learned from the implementation of more than one exemplary embodiment.

[0067] In more than one exemplary embodiment, systems, methods, and / or computer-readable media at any possible technical detail level of integration can be involved. Moreover, one or more of the above components can be implemented as instructions (and / or including at least one processor) stored in a computer-readable medium and executable by at least one processor. The computer-readable medium can include a computer-readable non-transitory storage medium (or media) having computer-readable program instructions for causing the processor to perform operations.

[0068] A computer-readable storage medium can be a tangible device that can hold and store instructions for use by an instruction execution device. The computer-readable storage medium can be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above, but is not limited to these. A non-exhaustive list of more specific examples of computer-readable storage media includes the following, namely, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM (Erasable Programmable Read Only Memory) or flash memory), a static random access memory (SRAM: Static Random Access Memory), a portable compact disk read-only memory (CD-ROM: Compact Disk Read Only Memory), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as a punched card or a raised structure in a slot that records instructions, and any suitable combination of the above. The computer-readable storage medium used in this specification should not be construed as a transient signal itself such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated through a waveguide or other transmission medium (for example, an optical pulse passing through an optical fiber cable), or an electrical signal transmitted through a wire.

[0069] The computer-readable program instructions described in this specification can be downloaded from a computer-readable storage medium to various computing / processing devices, or can be downloaded to an external computer or an external storage device via a network, for example, the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter or network interface in each computing / processing device receives the computer-readable program instructions from the network and transmits the computer-readable program instructions to be stored in the computer-readable storage medium in each computing / processing device.

[0070] The computer-readable program code / instruction for performing an action can be assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for an integrated circuit, or source code or object code written in any combination of one or more programming languages, where the one or more programming languages include object-oriented programming languages such as Smalltalk, C++, or the like, and procedural programming languages such as the "C" programming language or the like. The computer-readable program instructions can be executed entirely on the user's computer, can be partially executed on the user's computer, can be executed as a stand-alone software package, can be partially executed on the user's computer and partially on a remote computer, or can be executed entirely on a remote computer or server. In the latter scenario, the remote computer can 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 can be connected to an external computer (e.g., by using an Internet service provider via the Internet). In one or more exemplary embodiments, to perform a solution or an action, an electronic circuit including, for example, a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) can utilize the state information of the computer-readable program instructions to individualize the electronic circuit, thereby executing the computer-readable program instructions.

[0071] The computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device for generating a machine, such that the instructions executed via the processor of the computer or other programmable data processing device generate a component for implementing the function / behavior specified in the function box or function boxes in the flowchart and / or block diagram. The computer-readable program instructions can also be stored in a computer-readable storage medium, which can direct a computer, a programmable data processing device, and / or other devices to function in a particular manner, such that the computer-readable storage medium storing the instructions therein has an article of manufacture, which includes instructions for implementing the solution for the function / behavior specified in the function box or function boxes in the flowchart and / or block diagram.

[0072] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices to generate a computer-implemented process, such that the instructions executed on the computer, other programmable apparatus, or other devices implement the functions / acts specified in the functional block or blocks of the flowchart and / or block diagram.

[0073] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible exemplary embodiments of systems, methods, and computer-readable media according to more than one exemplary embodiment. In this regard, each functional block in the flowchart or block diagram may represent a microservice, module, segment, or portion of an instruction comprising one or more executable instructions for implementing the specified logical function. The methods, computer systems, and computer-readable media may include additional functional blocks, fewer functional blocks, different functional blocks, or functional blocks configured in a different manner than those depicted in the figures. In more than one alternative exemplary embodiment, the functions described in the functional blocks may occur out of the order described in the figures. For example, two functional blocks shown in succession may in fact be executed concurrently or substantially concurrently, or the functional blocks may be executed in the reverse order depending on the associated functionality. It should also be noted that each functional block of the block diagrams and / or flowcharts, and combinations of functional blocks in the block diagrams and / or flowcharts, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[0074] It is apparent that the systems and / or methods described in this specification can be implemented in various forms of hardware, firmware, or a combination of software and hardware. The actual specific control hardware or software code used to implement the systems and / or methods is not limited by more than one exemplary embodiment. Thus, it is understood that the operations and behaviors of the systems and / or methods are described in this specification without reference to specific software code, and software and hardware can be designed to implement the systems and / or methods based on the description in this specification.

Claims

1. A method for managing vehicle event data, which is performed by an electronic control unit (ECU) of a vehicle, wherein, The method includes: Determining whether a vehicle event in an event log belongs to an unregistered event type; Generating a temporary event identifier ID based on at least one feature of the vehicle event; Storing the temporary event ID together with a time stamp in a database; Determining whether the number of vehicle events in the event log with the temporary event ID exceeds a specified threshold; and Triggering a vehicle-related response associated with the temporary event ID based on the determination that the number of vehicle events exceeds the specified threshold.

2. The method according to claim 1, further including: Appending a new vehicle event received from a vehicle component of the vehicle to the event log; And Based on the temporary event ID, determining whether the new vehicle event belongs to the unregistered event type.

3. The method according to claim 2, including: Based on the temporary event ID, determining whether the new vehicle event belongs to a registered event type, and this determination is made using a machine learning ML model.

4. The method according to any one of claims 1 to 3, wherein Generating the temporary event ID is based on a hash value, where the hash value is obtained using at least one of a source vehicle component of the vehicle, the distance between the source vehicle component and a safety infrastructure and a security infrastructure in the vehicle, and a message in the vehicle event.

5. The method according to any one of claims 1 to 4, further including: Appending a registered event type and a vehicle-related response associated with the registered event type to the database.

6. The method according to any one of claims 1 to 5, wherein The specified threshold and the vehicle-related response associated with the temporary event ID are stored in the database.

7. The method according to any one of claims 1 to 6, wherein The triggering of the vehicle-related response includes sending a message to a cloud network.

8. A device for managing vehicle event data, which is implemented by an electronic control unit (ECU) of the vehicle, wherein, The apparatus includes: At least one memory storing computer-executable instructions; and At least one processor, The at least one processor is configured to execute the computer-executable instructions so as to: Determine whether a vehicle event in an event log belongs to an unregistered event type; Generate a temporary event identifier ID based on at least one feature of the vehicle event; Store the temporary event ID together with a time stamp in a database; Determine whether the number of vehicle events in the event log with the temporary event ID exceeds a specified threshold; And Based on the determination that the number of vehicle events exceeds the specified threshold, trigger a vehicle-related response associated with the temporary event ID.

9. The apparatus according to claim 8, wherein The at least one processor is further configured to execute the computer-executable instructions so as to: Append a new vehicle event received from a vehicle component of the vehicle to the event log; And Based on the temporary event ID, determine whether the new vehicle event belongs to the unregistered event type.

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

11. The apparatus according to any one of claims 8 to 10, wherein, the at least one processor is configured to generate the temporary event ID based on a hash value, where the hash value is obtained by using at least one of a source vehicle component of the vehicle, a distance of the source vehicle component from a safety infrastructure and a security infrastructure in the vehicle, and a message in the vehicle event.

12. The apparatus according to any one of claims 8 to 11, wherein, the at least one processor is further configured to execute the computer-executable instructions so that: append a registered event type and a vehicle-related response associated with the registered event type to the database.

13. The apparatus according to any one of claims 8 to 12, wherein, the specified threshold and the vehicle-related response associated with the temporary event ID are stored in the database.

14. The apparatus according to any one of claims 8 to 13, wherein, the at least one processor is configured to trigger the vehicle-related response by sending a message to a cloud network.

15. A computer program product having instructions recorded thereon for performing a method for managing vehicle event data, the method being performed by an electronic control unit ECU of a vehicle, the method comprising: 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 feature of the vehicle event; store the temporary event ID in a database together with a timestamp; determine whether the number of vehicle events in the event log having the temporary event ID exceeds a specified threshold; and based on the determination that the number of vehicle events exceeds the specified threshold, trigger a vehicle-related response associated with the temporary event ID.

16. The computer program product according to claim 15, wherein, the method further comprises: append a new vehicle event received from a vehicle component of the vehicle to the event log; and based on the temporary event ID, determine whether the new vehicle event belongs to the unregistered event type.

17. The computer program product according to claim 16, wherein, the method comprises: determining whether the new vehicle event belongs to a registered event type based on the temporary event ID, and the determination is performed by using a machine learning ML model.

18. The computer program product according to any one of claims 15 to 17, wherein, Generating the temporary event ID is based on a hash value, where the hash value is obtained using at least one of the source vehicle components of the vehicle, the distance of the source vehicle components from the safety infrastructure and the security infrastructure in the vehicle, and the message in the vehicle event.

19. The computer program product according to any one of claims 15 to 18, wherein The method further includes: Appending the registered event type and the vehicle-related response associated with the registered event type to the database.

20. The computer program product according to any one of claims 15 to 19, wherein The specified threshold value and the vehicle-related response associated with the temporary event ID are stored in the database.

Images