In-vehicle system having volatile and non-volatile storage and method of use thereof - Patents.com

Abstract

To more efficiently use vehicle resources.SOLUTION: A method for collecting data in a vehicle includes receiving sensor data from at least one sensor. The method further includes determining whether or not one or more predetermined conditions are satisfied, and the one or more predetermined conditions relate to a rule for collection of the sensor data. The method further includes storing the sensor data in a non-volatile memory (NVM) structure according to the determination that at least one of the one or more predetermined conditions is satisfied. The method further includes storing the sensor data in a volatile memory (VM) structure according to the determination that none of the one or more predetermined conditions is satisfied.SELECTED DRAWING: Figure 5

Description

[Background technology]

[0001] In-vehicle systems use increasingly sophisticated computing technology that makes extensive use of sensors within the vehicle to collect information about the vehicle's operation or the vehicle's surrounding environment. This information may be transmitted to a central server for evaluation and analysis to help improve the vehicle's operation and to collect information about the vehicle's environment. In some cases, third parties, such as application developers, insurance companies, or government agencies, may query information about the vehicle's operation or the vehicle's surrounding environment. [Brief description of the drawings]

[0002] Aspects of the present disclosure will be best understood from the following detailed description read in conjunction with the accompanying drawings, in which: It should be noted that, in accordance with standard industry practice, the various drawings are not drawn to scale, and in practice, dimensions of various features may be appropriately expanded or reduced for clarity of illustration.

[0003] [Figure 1] FIG. 1 is a schematic diagram of a request retrieval system according to an embodiment. [Diagram 2] FIG. 2 is a diagram illustrating a GUI (Graphical User Interface) in the request retrieval system according to the embodiment. [Diagram 3] FIG. 4 is a data structure diagram of a request search command in the embodiment. [Figure 4] FIG. 1 is a schematic diagram of a request retrieval system according to an embodiment. [Diagram 5] 1 is a flowchart of a method for implementing a request retrieval system according to an embodiment. [Figure 6] 1 is a flowchart of a data collection method using an in-vehicle system according to an embodiment. [Figure 7] FIG. 1 is a configuration diagram of a system for implementing a request search system according to an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0004] The following disclosure provides many different embodiments or examples for implementing different features of the subject matter. The specific examples of components, values, operations, materials, combinations, etc. described below are for the purpose of simplifying the disclosure. These are, of course, merely examples and are not intended to be limiting. Other components, values, operations, materials, combinations, etc. are also applicable. For example, in the following description, a structure in which a first shape is on a second shape may include an embodiment in which the first shape and the second shape are formed so that they are in direct contact, and may also include an embodiment in which an additional shape is formed between the first shape and the second shape so that the first shape and the second shape are not in direct contact. Furthermore, reference numerals may be repeated in some examples in the present disclosure. Such repetition is for the sake of simplicity and clarity of description and does not indicate a relationship between the embodiments and / or configurations in which it is used.

[0005] Additionally, spatial relationship terms such as "beneath," "below," "lower," "above," and "upper" may be used herein to simply describe the relationship of one element or feature to another element or feature depicted in the drawings. The spatial relationship terms are used with the intent to encompass different orientations in addition to the device or operational orientation used in the drawings. The device may be oriented in other directions (rotated 90 degrees or at other orientations) where the spatial relationship descriptors may be similarly interpreted according to that orientation.

[0006] Data collection based on a triggering event detected in one or more vehicles can be used for the fulfillment of a rule or request received by a third party customer. Data collection for a rule or request occurs in response to a triggering event detected. In some embodiments, data collection includes retrieval of data stored in a memory in the vehicle. In some embodiments, data collection includes acquisition of newly detected data from one or more sensors in the vehicle. In some embodiments, data collection includes both retrieval of stored data and acquisition of new data.

[0007] This specification includes a description of an in-vehicle system having two different types of storage media: volatile storage media (VM) and non-volatile storage media (NVM). The inclusion of two different types of storage media helps prevent NVM burnout during rapid data collection while taking advantage of NVM's advantages in long-term data retention, especially when low power risks are possible. When NVM burns out, replacing the storage media can be expensive or time-consuming. In addition, failure to replace NVM potentially inhibits application of the burn-out time-to-replace rule.

[0008] The VM is used to collect sensor data in situations where there is low certainty that the data will be used in the future. For example, if the data is not associated with a rule or is associated with a rule that involves collecting historical data in response to the detection of a trigger event, then the certainty of data use is said to be low. For example, in response to the detection of a trigger event, in one embodiment, data from the accelerometer is collected for 10 seconds prior to the detection of the trigger event. However, if no trigger event is detected, the accelerometer data is overwritten on a first-in, first-out basis to maintain a 10-second window of accelerometer data. The in-vehicle system is less certain that the data will be used and overwritten immediately, and runs the risk of burning out the NVM cells in this situation.

[0009] NVM is used when there is a high degree of certainty that the data will be used in the future or when the data will be stored for a long period of time. For example, the certainty that the data will be used in the future is high when the rules are applied at periodic intervals or are part of the rules related to a safety system in the vehicle. If there is a high degree of certainty that the data will actually be used in the future or if the data is likely to be requested after a long period of time, reducing the risk of NVM burning becomes more meaningful.

[0010] Because each vehicle has a finite amount of resources, using two different types of storage media allows for a more efficient use of the available resources, which in turn allows for a greater number of rules to be applied and satisfied.

[0011] In one embodiment, a user is offered a fee to be able to select the storage medium to be used to satisfy the rules the user creates. In one embodiment, a user is offered a fee to be able to store data for a longer period of time to satisfy rules that require data from a longer period before a triggering event. In one embodiment, this time before a triggering event is called a lookback window. For example, in one embodiment, if the lookback window defined by a rule is long enough that the data is stored in NVM, a higher fee is charged than for a rule with a shorter lookback window that can be implemented using VM.

[0012] 1 is a schematic diagram of a request retrieval system 100 in an embodiment. The request retrieval system 100 includes a user interface (UI) 110. The UI 100 is configured to receive a user request for data from a vehicle 140. The request retrieval system 100 further includes a server 120. The server 120 is configured to receive the user request from the UI 110, transmit the user request to the vehicle 140, receive data from the vehicle 140, and provide the data to the user via an accessible console 150. The server 120 includes a communication unit 130 for communicating with the UI 110 and the vehicle 140. The request retrieval system 100 further includes the accessible console 150 configured to communicate data collected from the vehicle 140 to the user.

[0013] The UI 110 is configured to receive input instructions from a user. In one embodiment, the user includes a software developer. In one embodiment, the user includes a developer of machine learning models. In one embodiment, the user includes an insurance company. In one embodiment, the user includes a law enforcement agency. In one embodiment, the user includes a market research company. The UI 110 provides options for the user to select a vehicle type and a data type for which the data request is made. In one embodiment, the UI 110 can generate the data request using a form for vehicle identification information, a requested data type, and a start and end time. In one embodiment, the start and end times are absolute times, such as UNIX time, which represents time since the UNIX epoch. In one embodiment, the start and end times are relative times relative to the time the data request was received by the vehicle. In one embodiment, the start and end times are relative times relative to a trigger event. In one embodiment, the UI 110 also provides the user with options for selecting a trigger event and a data collection period relative to the trigger event. In one embodiment, the UI 110 includes information regarding the vehicle type for which data is requested. In one embodiment, the UI 110 includes a vehicle ID that can uniquely identify the vehicle for which the request is made. For example, the vehicle ID includes a universally unique identifier (UUID) format. In one embodiment, the UI 110 includes a data type that can identify the source of the data the user wants to collect. For example, the data type includes a sensor ID for a sensor from which sensor data is collected and an application ID for an application from which application logs are collected. In one embodiment, the sensor ID and application ID format includes a UUID format. In one embodiment, the UI 110 includes a drop-down menu. In one embodiment, the UI 110 includes an editable area for receiving information related to the data request. In one embodiment, the UI 110 provides information regarding the types of data options available to the user. In one embodiment, the types of data options available are dependent on the user.For example, in some embodiments, law enforcement agencies may have more data options to choose from than insurance companies.

[0014] In one embodiment, the UI 110 includes a graphical user interface (GUI). In one embodiment, the UI 110 includes a mobile device, such as a mobile phone, that can connect to the server 120. In one embodiment, the UI 110 includes a web interface, such as a RESTful API. In one embodiment, the UI 110 includes a computer that can connect to the server 120. In one embodiment, the UI 110 can connect wirelessly to the server 120. In one embodiment, the UI 110 can connect to the server 120 via a wired connection. The UI 110 can also provide updates to the user regarding the status of the data request. In one embodiment, the UI 110 provides updates to the status of the data request in response to further inquiry by the user. In one embodiment, the UI 110 provides updates to the status of the data request automatically, without user intervention, in response to receiving updates from the server 120. In one embodiment, the updates to the status trigger a notification by the UI 110 to the user. In one embodiment, the notification includes an audio notification or a visual notification.

[0015] In one embodiment, the UI 110 includes a means for accepting payment by a user. In one embodiment, the UI 110 includes a data entry field where a user can enter payment card information. In one embodiment, the UI 110 includes a reader for detecting payment card information, such as a magnetic stripe reader, a bar code reader, an IC chip reader, or other suitable reader.

[0016] The server 120 includes a communication unit 130 configured to communicate with the UI 110 and the vehicle 140. The communication unit 130 includes a receiver 131 configured to receive a data request from the UI 110. In one embodiment, the receiver 131 includes a wireless receiver. In one embodiment, the receiver 131 is configured to receive the data request via a wired connection. In one embodiment, the receiver 131 is further configured to perform initial processing on the received data request. In one embodiment, the received data request includes priority level information. In one embodiment, the receiver 131 is configured to associate a priority level with the data request based on the identity of a user who registered the data request or a fee paid by the user who registered the data request. In one embodiment, the receiver 131 is configured to associate a request identification number (request ID) with each received data request. In one embodiment, the server 120 is configured to restrict access to certain sensors in the vehicle 140 based on the identity of the user. For example, in one embodiment, a third-party user cannot access sensors related to safety features of the vehicle 140.

[0017] The communication unit 130 further includes a storage unit 132 configured to store data requests received by the receiver 131. In an embodiment, the storage unit 132 includes a random access memory, a semiconductor memory, or other types of memory. In an embodiment, the storage unit 132 is configured to store the data requests along with a status of the data request. In an embodiment, the status of the data request includes waiting to be registered (before the data request is sent to the vehicle 140), registered (after the data request is sent to the vehicle 140), and completed (after the requested data is received from the vehicle 140). In an embodiment, the storage unit 132 is accessible by a user. In an embodiment, an update of information in the storage unit 132 triggers a notification to the user associated with the information updated in the storage unit 132. In an embodiment, the storage unit 132 stores the data requests along with timestamp information indicating the time the data request was received. In an embodiment, the storage unit 132 stores the data requests in association with a priority level. In an embodiment, the priority level is determined based on the identity of the user. For example, in some embodiments, law enforcement agencies have a higher priority than insurance companies, which have a higher priority than general users such as software developers. In some embodiments, users can pay a fee to increase the priority level of their requests or to get requested data faster. In some embodiments, the priority level of a data request increases as the time interval between when the data request is first stored and when it is sent to the vehicle increases.

[0018] The communication unit 130 further includes a transmitter 133. The transmitter 133 is configured to transmit a status of the data request to the UI 110. In an embodiment, the status of the data request is transmitted wirelessly to the UI 110. In an embodiment, the status of the data request is transmitted to the UI 110 via a wired connection. In an embodiment, the transmitter 133 is configured to automatically provide an update of the data request in response to updates in the storage unit 132. In an embodiment, the transmitter 133 is configured to provide an update of the data request in response to an update request received from a user. In an embodiment, the transmitter 133 is configured to automatically transmit a request ID when the data request is initially stored in the storage unit 132. In an embodiment, the status of the data request includes a priority level of the data request. In an embodiment, the status of the data request includes an estimated time until the data request is transmitted to the vehicle 140.

[0019] The communication unit 130 further includes a query queue 134 configured to store the data requests according to priority for transmission to the vehicle 140. In one embodiment, the query queue 134 is integrated with the storage unit 132. In one embodiment, the query queue 134 is separate from the storage unit 132. In one embodiment, the query queue 134 is configured to retrieve the data requests from the storage unit 132 based on the priority level and the time stamp information. In one embodiment, the query queue 134 is configured to sort the data requests based on the priority level and, for data requests with the same priority level, by the time elapsed since they were first stored in the storage unit 132.

[0020] The communication unit 130 further includes a transmitter 135 configured to transmit the data request from the inquiry queue 134 to the vehicle 140. The transmitter 135 is configured to transmit the data request to the vehicle 140 based on the order of the data requests in the inquiry queue 134. In one embodiment, the data request is transmitted wirelessly to the vehicle 140. In one embodiment, the data feed is transmitted to the vehicle 140 via a wired connection. The data request transmitted to the vehicle 140 includes trigger event information, data period information regarding how much data should be collected before and after the trigger event, and sensor information indicating the types of sensors of the vehicle 140 that should be included in the data collection. In one embodiment, the data request transmitted to the vehicle 140 includes priority level information. In one embodiment, the transmitter 135 is configured to transmit the data request to the vehicle 140 when the vehicle 140 transmits a request to the server 120 to transmit the data request to the vehicle 140. In one embodiment, the transmitter 135 is configured to transmit a data request to the vehicle 140 whenever the communication unit 130 has sufficient connectivity to transmit a data request to the vehicle 140, as long as the communication unit 130 has not received information indicating that the vehicle 140 is unable to accept a new data request. In one embodiment, the transmitter 135 is configured to periodically transmit a data request to the vehicle 140 as long as the vehicle 140 is able to receive a new data request and the transmitter 135 has sufficient connectivity with the vehicle 140. In one embodiment, the transmitter 135 is configured to transmit data requests to the vehicle 140 in batches of five data requests, twenty data requests, or any other number of data requests. In one embodiment, the transmitter 135 is configured to request an acknowledgment of the data request from the vehicle 140. If an acknowledgment is not received from the vehicle within a predetermined period of time, the transmitter 135 is configured to resend the data request. In one embodiment, the status of the data request stored in memory unit 132 is updated to indicate registration with vehicle 140 in response to communication unit 130 receiving an acknowledgement of the data request from vehicle 140.

[0021] The communication unit 130 further includes a receiver 136 configured to receive notification of the occurrence of a triggering event from the vehicle 140. In one embodiment, the occurrence of the triggering event is the receipt of a data request. In one embodiment, the receiver 136 is configured to receive notification of the triggering event wirelessly. In one embodiment, the receiver 136 is configured to receive notification of the triggering event via a wired connection. In one embodiment, the receiver 136 is configured to send a signal to the memory unit 132 to update the status of the data request associated with the notified triggering event.

[0022] The communication unit 130 further includes a receiver 137 configured to receive data from the vehicle 140 in response to the data request transmitted by the transmitter 135. In one embodiment, the data is divided by the vehicle 140 into packets for transmission from the vehicle 140 to the server 120, and the receiver 137 receives the data packets from the vehicle 140. In one embodiment, the receiver 137 is configured to receive data wirelessly. In one embodiment, the receiver 137 is configured to receive data via a wired connection. In one embodiment, the receiver 137 is configured to send a signal to the storage unit 132 to update the status of the data request associated with the received requested data. In one embodiment, data corresponding to one data request is received in one packet from the vehicle 140. In one embodiment, data corresponding to one data request is received in multiple packets from the vehicle 140. The receiver 137 passes the received data to the pre-processor 122.

[0023] The server 120 includes a preprocessor 122 configured to receive data from the receiver 137 and perform preprocessing on the data to generate collected data. In one embodiment, the preprocessing includes reconstructing the data from multiple packets into data corresponding to a data request. In one embodiment, the preprocessing includes deserializing and structuring the data from the byte order in which it was received. In one embodiment, the preprocessing includes decompressing the data that was compressed prior to transmission from the vehicle 140. In one embodiment, the preprocessing includes error correction using an error correcting code (ECC), such as a Reed-Solomon (RS) code, a Bose-Chaudhuri-Hocquenghem (BCH) code, a low density parity check (LDPC) code, or the like. In one embodiment, the preprocessing includes removing outliers and smoothing the data to reduce the risk of reporting inaccurate data to a user. In one embodiment, the preprocessing includes associating data request ID information, priority level information, or other suitable information with the data received from the receiver 137. In one embodiment, the data is preprocessed so that it is provided to a user in a format that is easy to understand and does not require special knowledge or equipment to read.

[0024] The server 120 further includes a data storage 126 configured to store the collected data generated by the preprocessor 122. In an embodiment, the data storage 126 is integrated with the storage 132. In an embodiment, the data storage 126 is separate from the storage 132. In an embodiment, the data storage 126 includes a solid state drive (SSD), a random access memory, or other suitable memory. In an embodiment, the data storage 126 is accessible by a user using, for example, the UI 110 or the accessible console 150. In an embodiment, the data storage 126 is configured to notify a user that data related to a data request is available. In an embodiment, the notification includes a notification to the user. In an embodiment, the notification includes an audio or visual notification. In an embodiment, the data storage 126 is configured to cause the UI 110 or the accessible console 150 to automatically display a notification about the availability of the collected data. In an embodiment, the data storage 126 is accessible by a user using the accessible console 150 without the user having to register a data request. In one embodiment, the data in the data storage 126 is searchable by a user via the accessible console 150. In one embodiment, the collected data is visualized in the accessible console 150.

[0025] The request retrieval system 100 further includes a vehicle 140. The vehicle 140 includes a number of sensors that detect both the interior conditions of the vehicle 140 and the external environment around the vehicle 140. In an embodiment, the sensors include a camera, a Light Distance And Ranging (LiDAR) sensor, a Radio Distance And Ranging (RADAR) sensor, a Sound Navigation And Ranging (SONAR) sensor, an acceleration sensor, a steering wheel position, a vehicle speed sensor, or other suitable sensors. The vehicle 140 can receive the data request wirelessly or via a wired connection.

[0026] In one embodiment, the vehicle 140 is configured to assign a data request ID to the received data request in response to receiving the data request. The data request is processed independent of the system or program from which the data request originated. In another embodiment, the communication unit 130 assigns the data request ID on behalf of the vehicle 140, and the data request ID is included in the data request that the communication unit 130 sends to the vehicle 140. Making the data request independent of the system or program from which the data request originated allows the vehicle 140 to receive and process data requests from a wider range of different users and systems. The vehicle 140 includes a processor that processes the data request and determines what types of data from sensors available to the vehicle 140 can satisfy the data request. The vehicle 140 further includes a memory that stores data from the sensors. In one embodiment, the vehicle 140 includes different types of memory. In one embodiment, the vehicle 140 includes a volatile memory (VM) and a non-volatile memory (NVM). In one embodiment, the VM includes a memory structure such as a random access memory (RAM), e.g., a dynamic RAM or a static RAM, or other suitable volatile memory structure. In one embodiment, the NVM includes a flash memory, an erasable programmable ROM (EPROM), a ferroelectric RAM, or other suitable type of non-volatile memory structure. The VM reads and writes data quickly and has a low risk of burning the memory structure. However, because the VM uses power to maintain data in the memory structure, the risk of data loss or corruption increases when power is lost or insufficient, as compared to the NVM. Burning of the memory structure occurs when the memory structure is repeatedly overwritten and the repeated erasing and rewriting of the memory structure corrupts components of the memory structure such that the memory structure can no longer reliably store data. Due to the NVM's characteristic of reliably storing data even in low or no power conditions, the structure of the NVM is more susceptible to burning than the structure of the VM. In one embodiment, the processor accesses the memory to determine whether the stored data can satisfy a data request.Vehicle 140 may further transmit data that satisfies a data request to server 120 wirelessly or via a wired connection. In one embodiment, the processor is configured to satisfy the received data requests in priority order based on the priority level of the received data request. In one embodiment, vehicle 140 is configured to preferentially transmit data to the server based on the priority level of the received data request.

[0027] In one embodiment, the memory and processor of the vehicle 140 are configured to store and execute software applications in an electronic control unit (ECU) in the vehicle 140. In one embodiment, the data request is generated by the software application stored in the ECU. In one embodiment, the data request is generated in response to a trigger event, such as sudden acceleration, sudden braking, acquisition of sensor data including a particular object or a particular scene predefined in the software application, the software application ceasing to operate (crash), detection of an anomaly in the software application, or detection of any other suitable occurrence. In one embodiment, the vehicle 140 is configured to generate a notification to a maintainer of the software application, e.g., a user, in response to detection of a trigger event associated with the software application. In one embodiment, the notification is sent directly to the user, e.g., via the UI 110, wirelessly or via a wired connection. In one embodiment, the notification is sent to the user via the server 120, wirelessly or via a wired connection. In one embodiment, the notification is configured to cause the UI 110 to automatically display the notification without user intervention.

[0028] The request retrieval system 100 further includes an accessible console 150. The accessible console 150 allows a user to access the collected data stored in the data storage 126. In some embodiments, the accessible console 150 is integrated with the UI 110. In some embodiments, the accessible console 150 is separate from the UI 110. In some embodiments, the accessible console 150 comprises a separate server separate from the server 120. In some embodiments, the accessible console 150 automatically receives the collected data associated with a data request from a user when the data storage 126 receives the collected data. In some embodiments, the accessible console 150 allows a user to search the data storage 126 to determine which of the collected data stored in the data storage 126 is useful to the user, even if the user has not registered a data request.

[0029] The request retrieval system 100 allows a user to retrieve information from one or more vehicles 140 in an easy to understand format without requiring special equipment to request or read the received data. The request retrieval system 100 can prioritize data requests to ensure that law enforcement or other users receive the data and to ensure that paying users receive the data quickly. This flexibility of the request retrieval system 100 makes it more useful to a wide range of users.

[0030] FIG. 2 is a diagram illustrating graphical user interfaces (GUIs) 200 and 250 in the request retrieval system of the embodiment. In one embodiment, the GUI 200 can be used as the UI 110 (FIG. 1) of the request retrieval system 100. In one embodiment, the GUI 200 can be used to generate a data request to be received by the receiver 131 (FIG. 1). The GUI 200 includes a number of information types 210 that identify the types of information that the GUI 200 can accept from a user. The GUI 200 further includes a number of fields 220 configured to receive information related to the corresponding information types 210 of the GUI 200. The GUI 200 includes a registration button 230 configured to register a data request with a server, for example, the server 120 (FIG. 1), based on the information in the fields 220. Those skilled in the art will recognize that the names and numbers of the number of information types 210 are merely exemplary and different numbers and types of information are also within the scope of the present disclosure.

[0031] In one embodiment, fields 220 include fields for a user to enter a vehicle ID, a data type, a start time, and an end time. In one embodiment, fields 220 further include fields for a user to enter a priority level for the data request. In one embodiment, GUI 200 further includes information regarding how a user may increase the priority level of a data request, such as listing fees associated with each applicable priority level. In one embodiment, GUI 200 includes fields 220 where a user may enter login information for identification purposes. In one embodiment, GUI 200 is configured to subsequently display the priority level of a user who has received the login information. In one embodiment, GUI 200 further includes fields 220 for receiving payment information regarding fees for prioritizing a data request.

[0032] The GUI 250 is configured to be displayed to a user after the user selects the register button 230 of the GUI 200. In one embodiment, the GUI 250 can be used as the GUI 110 (FIG. 1) in the request retrieval system 100. The GUI 250 includes information indicating that a data request has been received. The GUI 250 includes a request ID label 260 and a request ID field 270. Information for display in the request ID field 270 is received from a server, e.g., the server 120 (FIG. 1), after the server receives and stores the data request. In one embodiment, the GUI 250 includes vehicle ID information. In one embodiment, the GUI 250 includes information related to a priority level of the data request. In one embodiment, the GUI 250 includes information related to the status of the data request, such as awaiting registration, registered, completed, etc. In one embodiment, the GUI 250 includes information related to an estimated time until the data request is registered to a vehicle, e.g., the vehicle 140 (FIG. 1). In one embodiment, the GUI 250 is automatically displayed in response to receipt of the request ID information from the server. In one embodiment, GUI 250 is displayed in response to a user registering a request for updates on uploaded data requests.

[0033] 3 is a diagram of a data structure 300 of a request retrieval command 310 in an embodiment. In one embodiment, the request retrieval command 310 is sent from the server 120 to the vehicle 140 (FIG. 1). The request retrieval command 310 includes information related to the type of data that the data request requests from the vehicle, such as the vehicle 140 (FIG. 1).

[0034] The request retrieval instruction 310 includes a transfer priority parameter 311 that indicates a priority level of the data request. The request retrieval instruction 310 further includes a log level parameter 312 that indicates the type of data (if any) to retrieve from other applications in the vehicle. For example, in one embodiment, the request retrieval instruction 310 retrieves data from an object detection application. The log level parameter 312 defines what type of data to retrieve from other applications, such as error level or major problem level. In one embodiment, the log level parameter 312 is omitted from the request retrieval instruction 310 or the log level parameter 312 is left in a null state. The request retrieval instruction 310 further includes a collection time range parameter 313 that indicates a time range for which data should be collected around the trigger event. The time range corresponds to a start time and an end time entered by the user in the GUI 200 (FIG. 2). The request retrieval instruction 310 further includes a Uniform Resource Locator (URL) destination parameter 314 that indicates a destination for data collected in response to the data request. The request search instruction 310 further includes a frequency parameter 315 indicating how frequently data should be sampled in the time range indicated in the collection time range parameter 313. For example, if the time t of the event is 100 seconds, the time range has a start time of -1 second and an end time of 2 seconds, and the frequency is 10 Hz (100 millisecond period), data at times t of 99.0 seconds, 99.1 seconds, 99.2 seconds, ..., 101.9 seconds, and 102.0 seconds is collected by the request search instruction. The request search instruction 310 further includes a log ID parameter 316 indicating the type of sensor and / or application that can be used to collect the data requested by the data request. In one embodiment, a unique ID (e.g., a universally unique identifier (UUID)) is pre-assigned to every sensor and application, and the unique ID for which the user requests data collection is specified in the log ID parameter 316. The request search instruction 310 further includes a requester ID parameter 317 indicating the identity of the user who created the data request.The request retrieval instruction 310 further includes an event ID parameter 318 that indicates a triggering event associated with the data request. The request retrieval instruction 310 further includes an allocation ID parameter 319 that indicates how much of the resources of the vehicle, e.g., vehicle 140 (FIG. 1), to allocate to satisfy the data request. Those skilled in the art will also appreciate that the request retrieval instruction 310 will not always include all of the parameters shown in FIG. 3. For example, in some embodiments, the allocation ID parameter 319 is omitted.

[0035] 4 is a block diagram of a request search system 400 according to an embodiment. In one embodiment, the request search system 400 is part of the request search system 100 (FIG. 1). In one embodiment, the request search system 400 can be used in conjunction with the request search system 100 (FIG. 1). In one embodiment, the request search system 400 can be separate from the request search system 100 (FIG. 1).

[0036] The request retrieval system 400 includes a detection vehicle system 410 configured to obtain information of or around the vehicle. The detection vehicle system 410 obtains the information of the vehicle and its surroundings and transmits the information to a server. The request retrieval system 400 is configured to receive the information, encode the information, and disseminate the information to the user terminals 460.

[0037] The detection vehicle system 410 includes an ECU 420 configured to receive data from sensors 414, a Global Positioning System (GPS) 416, and a map 418. The ECU 420 includes a situation detection unit 422, a data identification unit 432, a log collection unit 434, and a log transmission unit 436. The situation detection unit 422 includes a vehicle control monitor 424, an object detection unit 426, and a scene detection unit 428.

[0038] In one embodiment, the ECU 420 further includes a localization unit configured to receive data from the GPS 416 and the map 418 to determine the vehicle's position and orientation and the vehicle's state relative to detected and / or known object and / or road locations. Orientation is the direction of the vehicle relative to a reference point, such as a roadway. In one embodiment, the vehicle's position is represented with a vehicle position vector. The orientation and vehicle state are represented by the speed and the vehicle's heading. In one embodiment, the orientation and vehicle state are represented with the vehicle's velocity vector, acceleration vector, and jerk vector. In one embodiment, the position vector, velocity vector, acceleration vector, and jerk vector include angle vectors. In one embodiment, the vehicle state is represented with whether the vehicle's engine or motor is running or not.

[0039] The sensor 414 is configured to capture information, e.g., images, about the vehicle's surroundings. In some embodiments, the sensor 414 includes a visible light camera, an infrared light camera. In some embodiments, the sensor 414 is replaced by or further includes a LiDAR sensor, a RADAR sensor, a SONAR sensor, or other suitable sensor. In some embodiments, the sensor 414 includes an additional camera at another location on the vehicle. For example, in some embodiments, the additional camera is located on the side of the vehicle to detect a larger area of ​​the environment to the left and right of the target vehicle. Because vehicle occupants can see out of the vehicle's side windows, the additional camera that detects a larger area of ​​the vehicle's surroundings can be used to improve detection of objects or situations around the vehicle. For example, in some embodiments, the additional camera is located at the rear of the vehicle to detect a larger area of ​​the environment behind the vehicle. This information can capture information about objects. In some embodiments, the data from the sensor 414 includes a timestamp or other metadata to enable synchronization of data from the sensor 414 with data from other devices.

[0040] The GPS 416 is configured to determine the location of the vehicle. Knowing the location of the target vehicle allows an object or situation to be associated with the determined location on the map 418.

[0041] The map 418 includes information related to the roadway and known objects along the roadway. In one embodiment, the map 418 can be used in conjunction with the GPS 416 to determine the vehicle's location and heading. In one embodiment, the map 418 is received from an external device, such as a server 440. In one embodiment, the map 418 is periodically updated based on information from the sensors 414 and / or the GPS 416. In one embodiment, the map 418 is periodically updated based on information received from an external device. In one embodiment, the map 418 is generated from sensor data using a Simultaneous Localization And Mapping (SLAM) algorithm. The inclusion of the map 418 can determine whether an object is a known object. The inclusion of the map 418 with known objects can improve the accuracy of detecting new objects.

[0042] The condition detector 422 is configured to generate information regarding the operation of the vehicle and in-vehicle systems. The condition detector 422 may collect information from devices in the vehicle, such as the sensors 414, the braking system, the acceleration system, and other suitable devices. Using such information, the condition detector 422 may determine the operation of the vehicle. In an embodiment, the condition detector 422 is further configured to monitor the operation of software and networks in the vehicle. For example, in an embodiment, the condition detector 422 is configured to receive information regarding a "crash" of software or an application in the vehicle. In an embodiment, the condition detector 422 is configured to collect information regarding the storage capacity of a storage device in the vehicle. In an embodiment, the condition detector 422 is configured to receive information regarding the processing capacity of a processor in the vehicle.

[0043] Vehicle control monitor 424 is configured to receive sensor data and control logs related to the current operation of the vehicle. In one embodiment, the sensor data includes information related to vehicle speed, acceleration, jerk, braking, steering, pitch, roll, yaw, hazard light flashing, horn, or other suitable information. Vehicle control monitor 424 is configured to determine whether any of the received sensor data indicates satisfaction of a request fulfillment criteria, such as satisfaction of a trigger event.

[0044] The object detector 426 is configured to receive sensor data from the sensor 414 and determine whether a foreign object is present on the roadway. In one embodiment, the object detector 426 is further configured to determine whether an object is present along or near the roadway. In one embodiment, the sensor data from the sensor 414 includes images, and the object detector 426 is configured to perform image recognition on the received images to detect the foreign object, for example, using a trained neural network. In one embodiment, the object detector 426 is configured to compare the identified object to information from the GPS 416 and the map 418 so that a type of the identified object can be determined. In one embodiment, the object detector 426 is configured to identify objects such as tires, vehicle parts, animals, potholes, traffic signs, emergency vehicles, vehicles with hazard lights on, or other suitable objects.

[0045] The scene detector 428 is configured to receive sensor data from the sensor 414 and determine whether a scene that satisfies the conditions for fulfilling the request is present in the environment surrounding the vehicle. In one embodiment, the scene detector 428 is configured to determine that a vehicle accident has occurred based on detecting two or more vehicles in contact with each other or a vehicle surrounded by multiple fallen objects. In one embodiment, the scene detector 428 is configured to determine that construction is occurring based on detecting multiple construction vehicles in close proximity. In one embodiment, the scene detector 428 is configured to determine that a vehicle is parked on the shoulder based on detecting that a vehicle is near the roadway and is not moving or is moving at a significantly slower speed than other vehicles. In one embodiment, the scene detector 428 is configured to determine the content of the scene surrounding the vehicle using, for example, image recognition using a trained neural network.

[0046] In one embodiment, each of the object detector 426 and the scene detector 428 operates throughout the time the vehicle is operating, e.g., while the vehicle engine or motor is running. In one embodiment, at least one of the object detector 426 and the scene detector 428 operates in response to a determination by the vehicle control monitor 424 that a predetermined condition, e.g., a trigger event, is detected.

[0047] The data specifier 432 is configured to receive a determination that the request has been fulfilled or that a trigger event has been detected. The data specifier 432 is configured to analyze the received information and determine which sensor data from the sensors 414 should be collected based on the received data. For example, in one embodiment, the data specifier 432 is configured to determine that image data from a front camera among the sensors 414 should be captured if an abnormal steering operation by the driver is detected. Furthermore, the data specifier 432 is configured to determine a time interval for collecting data from the determined sensors based on the duration of the detected condition. In one embodiment, the data specifier 432 is configured to determine which sensors 414 should be included in the data collection based on instructions in the request received from the user.

[0048] In one embodiment, the data identifier 432 is configured to determine a region of the received sensor data that is associated with the detected situation. In one embodiment, the region of the received sensor data is identified based on object recognition performed by the object detector 426 or the scene detector 428. In one embodiment, the data identifier 432 is configured to crop the images received from the sensors to reduce the amount of information in the abnormal situation log, or to remove unnecessary data from the sensor data if the sensor data is not an image. In one embodiment, the data identifier 432 is configured to remove personal information, such as license plates, people's faces, etc., from the sensor data.

[0049] The logger 434 is configured to receive data from the data identifier 432. In one embodiment, the logger 434 is configured to receive data directly from the sensor 414, GPS 416, or condition detector 422 based on information provided by the data identifier 432. The logger 434 also determines what information can be used to identify the type and location of the object, such as location information from the GPS 416 or map 418, image information from the sensor 414, cropped or reduced information from the data identifier 432, timestamp information regarding the time the object or scene was detected, or other suitable information.

[0050] The log collector 434 generates log data based on the received and correlated data, such as the cropped image and location data. The log collector 434 also associates timestamp information with the log data to facilitate synchronization of the collected data and ordering by priority in the server 440. In one embodiment, the log collector 434 generates log data that further includes world coordinates associated with the cropped image. In one embodiment, the log collector 434 generates log data that further includes a map location associated with the cropped image. In one embodiment, the log collector 434 generates log data that includes additional information that contributes to a more accurate determination of the object or scene.

[0051] While the above relates to generating log data based on image data from sensor 414, one skilled in the art will appreciate that log collector 434 is not limited to generating log data based solely on images. In some embodiments, log collector 434 is configured to generate log data based on information from other sensors mounted on the vehicle, such as a RADAR, LiDAR, or other suitable sensor. In some embodiments, log collector 434 is configured to generate log data based additionally on information received from smart glasses, if the occupant is using the smart glasses.

[0052] The log sender 436 is configured to receive the log data from the log collector 434 and send the log data to the server 440. In one embodiment, the log sender 436 is configured to send the log data wirelessly. In one embodiment, the log sender 436 is configured to send the log data via a wired connection. In one embodiment, the log sender 436 is configured to send the log data directly to the user terminal 460. In one embodiment, the log sender 436 sends the log data to a mobile device accessible by the user, where the mobile device is configured to send the log data to the server 440. In one embodiment, the log sender 436 is configured to send the log data to the mobile device using Bluetooth or other suitable wireless technology. In one embodiment, the ECU 420 is configured to determine whether a data transfer rate from the mobile device to the server 440 is higher than a transfer rate from the log sender 436 to the server 440. If it is determined that the data transfer rate from the portable device to the server 440 is higher, the log transmission unit 436 is configured to transmit the log data to the portable device so that the log data is transmitted from the portable device to the server 440. If it is determined that the data transfer rate from the portable device to the server 440 is not higher, the log transmission unit 436 is configured to transmit the log data directly from the detection vehicle system 410 to the server 440 without transferring it to the portable device.

[0053] In one embodiment, the detection vehicle system 410 further includes a memory configured to store sensor data from a sensor mounted on the vehicle. In one embodiment, the memory is further configured to store information associated with previously detected objects or scenes. In one embodiment, if an object or scene matching a previously detected object or scene is detected, the data identification unit 432 is configured to provide a result based on the matching object or scene. In one embodiment, the detection vehicle system 410 is further configured to determine whether the detection vehicle has received information from the server 440 related to an object or scene matching the determined object or scene from the situation detection unit 422. In one embodiment, if it is determined that the detection vehicle has already received information related to the determined object or scene, the detection vehicle system 410 is configured to suppress sending log data to the server 440. By avoiding sending duplicate information to the server 440, the data sent to the server 440 can be reduced, and the power consumption of the detection vehicle system 410 can be reduced. In one embodiment, the storage of past requests is referred to as caching. One skilled in the art will appreciate that caching is the use of hardware or software to store data so that the data can be provided faster for future requests.

[0054] The server 440 includes a log data receiver 442 configured to receive log data from the log sender 436. In one embodiment, the log data receiver 442 is configured to receive log data from a mobile device. The server 440 further includes a log encoder 444 that encodes the log data. The server 440 further includes a log forwarder 446 that forwards the encoded log data to the user terminal 160. The server 440 further includes a request / rule receiver 448 configured to receive a request or rule from the user terminal 460.

[0055] The log data receiver 442 is configured to receive the log data from the log sender 436. In one embodiment, the log data receiver 442 is configured to receive the log data from a mobile device. In one embodiment, the log data receiver 442 is configured to receive the log data wirelessly. In one embodiment, the log data receiver 442 is configured to receive the log data via a wired connection. In one embodiment, the log data receiver 442 is configured to timestamp the log data with the time the log data was received.

[0056] The log encoding unit 444 is configured to encode the received log data according to a predetermined encoding protocol. By encoding the log data according to a predetermined encoding protocol, the user terminal 460 can reliably decode the log data when the log data is used at the user terminal 460. In an embodiment, the log encoding unit 444 is configured to perform compression, image encoding, generation of thumbnail images, or other suitable encoding protocols for the log data. In an embodiment, the log encoding unit 444 is configured to perform encryption of the log data. In an embodiment, the log encoding unit 444 is configured to perform super-resolution processing to make the data more easily viewable by a user. Those skilled in the art will understand that super-resolution processing is a process of obtaining a high-resolution image from a low-resolution image. Improving the resolution of the log data can reduce false positives or false negatives.

[0057] In one embodiment, the server 440 further includes a database for storing the received log data. In one embodiment, the log data is stored in the database prior to or after encoding by the log encoding unit 444. In one embodiment, the log data is stored in a priority queue in the database. In one embodiment, the priority queue is based on the time an object or scene, e.g., a trigger event, was detected, the time the log data was received by the log data receiving unit 442, the type of object or scene, the identity of the driver of the detected vehicle, or other suitable priority criteria.

[0058] The log forwarder 446 is configured to receive the encoded log data from the log encoder 444. The log forwarder 446 is configured to transmit the encoded log data to the user terminal 460. In one embodiment, the log forwarder 446 is configured to transmit the encoded log data to a portable device accessible to the user. In one embodiment, the log forwarder 446 is configured to transmit the encoded log data wirelessly. In one embodiment, the log forwarder 446 is configured to transmit the encoded log data over a wired connection. In one embodiment, the log forwarder 446 is configured to transmit coded protocol information along with the encoded log data. Transmitting the coded protocol information of the encoded log data allows the portable device or user terminal 460 to correctly decode the encoded log data for use by the user terminal 460.

[0059] The request / rules receiver 448 is configured to receive new or updated rules or requests for data from a user. In one embodiment, the request / rules receiver 448 is configured to receive new or updated rules or requests wirelessly. In one embodiment, the request / rules receiver 448 is configured to receive new or updated rules or requests over a wired connection. In one embodiment, the request / rules receiver 448 is configured to receive new or updated rules or requests from the UI 110 (FIG. 1).

[0060] In one embodiment, server 440 is configured to receive location information from a plurality of vehicles. In one embodiment, server 440 is configured to receive navigation information from a plurality of vehicles. In one embodiment, log forwarder 446 is configured to limit transmission of encoded log data to vehicles within a predetermined distance of a detected trigger event.

[0061] In one embodiment, server 440 is configured to only transmit log data associated with newly detected trigger events, i.e., if a trigger event has already been reported by server 440, it will not be reported again. By avoiding repeated reporting of trigger events, server 440 can reduce duplicate data received by the user terminal.

[0062] User terminal 460 is a user terminal accessible to a user associated with the fulfilled request. In one embodiment, user terminal 460 includes a GUI. In one embodiment, user terminal 460 is configured to automatically generate a notification in response to receiving data from server 440. In one embodiment, the notification includes an audio or visual notification.

[0063] Those skilled in the art will appreciate that modifications to the request retrieval system 400 are within the scope of this disclosure. For example, in one embodiment, the detection vehicle system 410 can transmit the log data directly to the user terminal 460 over a network, such as a wireless network. In one embodiment, a portable device of an occupant of the detection vehicle can transmit the log data directly to the user terminal 460 over a network, such as a wireless network.

[0064] A user may configure the operation of an application or software used by a processing system in the vehicle, such as ECU 420, to automatically identify and disseminate data detected in the environment within or around the vehicle in relation to the satisfaction of a rule or requirement. In one embodiment, object information related to an event, such as an accident, may be received.

[0065] 5 is a flow chart of a method 500 performed by the request retrieval system of an embodiment. In one embodiment, the method 500 is performed by the request retrieval system 100 (FIG. 1) or the request retrieval system 400 (FIG. 4). In one embodiment, the method 500 is performed by a system 700 (FIG. 7) in which the request retrieval system is implemented. In one embodiment, the method 500 is performed by a system other than the request retrieval system 100 (FIG. 1), the request retrieval system 400, or the system 700 (FIG. 7). The following description relates to processing rules or requests received from a vehicle.

[0066] In operation 505, sensor data is collected. The sensor data is collected by one or more sensors connectable to the vehicle. In some embodiments, the sensor data includes control parameters of the vehicle. In some embodiments, the sensor data includes information about the vehicle's surroundings. In some embodiments, the sensor data includes data from sensors 414 (FIG. 4) and / or other sensors on the vehicle.

[0067] In operation 510, the sensor data is processed. The sensor data is processed to identify one or more triggering events for one or more rules stored in the vehicle's memory. In one embodiment, the sensor data is processed by the situation detector 422 (FIG. 4). In one embodiment, the sensor data is processed based on pre-processing instructions for one or more rules stored in the vehicle's memory. In one embodiment, the sensor data is processed to remove privacy concerns from the sensor data. In one embodiment, the sensor data is processed to compress the sensor data for storage in the vehicle's memory.

[0068] At operation 515, a determination is made as to whether one or more storage conditions have been satisfied. In one embodiment, the one or more storage conditions are satisfied when there is a high certainty that the data from operation 510 will be used in the future. In one embodiment, the one or more storage conditions include sensor data having an importance greater than a threshold. Storing the important sensor data in NVM reduces a risk that the important sensor data will be lost if the vehicle is shut down. In one embodiment, the sensor data is determined to have an importance greater than a threshold responsive to being related to vehicle safety, vehicle operation, or other suitable criteria.

[0069] In one embodiment, the determination regarding certainty is made based on whether the data is associated with a rule that satisfies one or more predefined conditions. The following description focuses on the certainty determination of operation 515 in one embodiment. In response to a determination that the rule satisfies one or more predefined conditions, a determination is made that there is a high certainty that the data will be used in the future. In response to a determination that the rule does not satisfy one or more predefined conditions, a determination is made that there is a low certainty that the data will be used in the future.

[0070] The determination of operation 515 is made by identifying a type of data required to be collected for each rule stored in the detection vehicle system 410. The type of data includes both sensor information identifying the sensor used to collect the required data and the time of data collection relative to a trigger event associated with the rule. If it is determined that the sensor data is not collected by any rule stored in the detection vehicle system 410, then it is determined that there is a low certainty that the data will be used.

[0071] The predetermined condition is set based on criteria that indicate that the rule has a high probability of being triggered, that the rule is associated with one or more safety systems in the vehicle, or that the user who created the rule has paid a fee to use a particular type of storage medium. In one embodiment, the predetermined condition includes whether the rule is being applied and is currently collecting data, whether the rule includes collecting data for the time prior to the detection of a triggering event, the length of time that data prior to the triggering event is collected, whether the user has paid a fee for use of the NVM, whether the rule is associated with one or more safety systems in the vehicle, whether a triggering event is likely to occur, or other suitable predetermined condition.

[0072] If the rules have already been applied and data collection has already begun, then there is a high degree of certainty that the data will be used in the future. Because the data has already been collected, use of the data is all but guaranteed. Thus, in operation 515, it is determined that there is a high degree of certainty that the data will be used in the future.

[0073] If the rule includes data collection before the detection of the trigger event, and the data collection period before the trigger event is shorter than the first period threshold, then there is a low certainty that the data will be used in the future. In one embodiment, the first period threshold is a value ranging from 5 seconds to 20 seconds. If the first period threshold is too short, then in one embodiment, there is an increased risk of NVM burn-in due to the risk of repeated data overwriting. If the first period threshold is too long, then in one embodiment, there is an increased risk that data required by the rule is stored in the VM and lost in part due to, for example, a power drop. Because the period of data collection is relatively short, the data is frequently overwritten. If the data is frequently overwritten, there is an increased risk of NVM burn-in. Also, a short data collection period before the detection of the trigger event means that for the data to be used in the future, the trigger event must be detected within a short period of time from the time the data was collected. As a result, data associated with a rule that includes a short period of data collection before the detection of the trigger event has a low certainty that the data will be used in the future. Thus, operation 515 determines that the data has a low certainty that the data will be used in the future.

[0074] In contrast, if a rule includes data collection before the detection of a triggering event, and the data collection period before the triggering event is equal to or longer than the second period threshold, there is a high certainty that the data will be used in the future. In one embodiment, the first period threshold is equal to the second period threshold. In one embodiment, the second period threshold is a value in the range of 30 seconds to 1 minute. If the second period threshold is too short, in one embodiment, there is an increased risk of NVM burn-in due to the risk of repeated data overwriting. If the second period threshold is too long, in one embodiment, there is an increased risk that data required by the rule is stored in the VM and some of it will be lost, for example, due to a power drop. Because the period of data collection is relatively long, the data is not overwritten frequently, and the risk of NVM burn-in is reduced compared to a rule that collects data for a short period before the triggering event. Also, a long period of data collection before the detection of a triggering event means that the triggering event is more likely to be detected within the period during which the data was collected. As a result, data associated with a rule that includes a long period of data collection before the detection of a triggering event has a high certainty that it will be used in the future. Thus, operation 515 determines that the data has a high certainty that it will be used in the future.

[0075] If the user has paid a fee for use of the NVM, operation 515 determines that there is a high certainty that the data will be used in the future. In one embodiment, the detection vehicle system 410 is notified, for example, using the UI 110 (FIG. 1), that the user has paid a fee to use the more reliable technology of the NVM. Because the user has paid a fee associated with the use of the NVM, the cost of replacing the burned NVM is offset by the fee collected from the user.

[0076] If the rule is associated with one or more safety systems in the vehicle, operation 515 may determine that the data is likely to be used in the future. Because safety systems in a vehicle are likely to be tested frequently to ensure proper operation, rules associated with one or more safety systems are likely to be applied and data associated with such rules is likely to be used.

[0077] If the trigger event is likely to occur, operation 515 may determine that there is a high probability that the data will be used. In one embodiment, the trigger event is the passage of time, i.e., a periodic trigger event. In such a situation, the trigger event occurs repeatedly, necessitating the use of NVM to reliably collect the data.

[0078] The above description addresses some of the predefined conditions individually. In some embodiments, if any one of the predefined conditions is satisfied, operation 515 determines that there is a high likelihood that the data will be used in the future. In some embodiments, the detection vehicle system 410 uses a priority relationship between the rules to resolve conflicts between the predefined conditions. For example, in some embodiments, if a rule requires data for a short period of time before a triggering event, but the rule is related to a safety system in the vehicle, operation 515 may determine that there is a high likelihood that the data will be used if the predefined condition related to the safety system has a higher priority than the rule for the period of time before the triggering event. In some embodiments, the priority between the predefined conditions is determined by the manufacturer of the vehicle. In some embodiments, the priority between the predefined conditions is adjustable by an operator of a server, such as server 440 (FIG. 4).

[0079] By determining whether the data is likely to be used by the detection vehicle system 410, operation 515 helps improve memory usage efficiency within the detection vehicle system 410, extending the useful life of the memory and allowing for accurate and precise collection of rule satisfying data. By storing frequently overwritten data in the VM, method 500 reduces the risk of NVM burnout and helps extend the useful life of the NVM, thereby reducing costs for the vehicle owner and maintaining sufficient resources of the vehicle to continue satisfying rules for longer. By storing data related to safety systems or meeting other criteria in the NVM, method 500 ensures that data that is of high value to the user, manufacturer, vehicle owner, or other third party is preserved even in low or no power conditions.

[0080] In response to determining that there is a low likelihood that the data will be used in the future, method 500 proceeds to operation 517. In response to determining that there is a high likelihood that the data will be used in the future, method 500 proceeds to operation 519. Regardless of the determination at operation 515, method 500 also proceeds to operation 520.

[0081] In operation 517, the data is stored in the VM. In one embodiment, the VM includes RAM, such as dynamic RAM (DRAM), static RAM (SRAM), or other suitable volatile memory structure. The data stored in the VM can be used to collect rule data in operation 525 in response to detection of a trigger event associated with a rule that requires the data stored in the VM.

[0082] In operation 519, the data is stored in NVM. In one embodiment, the NVM comprises flash memory, EPROM, ferroelectric RAM, or other suitable type of non-volatile memory structure. The data stored in the NVM can be used to collect rule data in operation 525 in response to detecting a trigger event associated with a rule that requires the data stored in the NVM.

[0083] At operation 520, a triggering event is detected. The triggering event is determined based on one or more rules stored in the NVM or VM at the detection vehicle system 410. The triggering event is detected using one or more sensors in the vehicle. In one embodiment, the triggering event is a periodic triggering event that results in a rule being applied after a predetermined period of time has elapsed. In response to detecting the triggering event, one or more rules associated with the triggering event are applied.

[0084] In operation 525, data is collected based on the one or more rules applied based on the trigger event detected in operation 520. In an embodiment, the rule data is collected from the VM. In an embodiment, the rule data is collected from the NVM. In an embodiment, the rule data is collected from both the VM and the NVM. In an embodiment, multiple different rules require similar or overlapping sensor data. That is, the sensor type and time period in the data satisfying a first rule overlaps at least partially with the sensor type and time period in the data satisfying a second rule. In an embodiment, the first rule satisfies at least one predetermined condition and the second rule does not satisfy any of the predetermined conditions. In such a condition, the data satisfying the first rule is stored in the NVM and the data satisfying the second rule is stored in the VM. In an embodiment, to conserve vehicle resources, the data satisfying the first rule is stored in the NVM and only the data satisfying the second rule that does not overlap with the data satisfying the first rule is stored in the VM. In such a situation, operation 525 may read data from both the VM and the NVM in response to detecting a triggering event associated with the second rule in operation 520. In one embodiment, the collected rule data includes timestamp information regarding the time the data was collected or the time the triggering event was detected. In one embodiment, the collected rule data is stored using log collector 434 (FIG. 4).

[0085] In operation 530, the collected rule data is sent to server 440. In one embodiment, the collected rule data is sent wirelessly. In one embodiment, the collected rule data is sent over a wired connection. In one embodiment, the collected rule data is sent using log sender 436 (FIG. 4).

[0086] In operation 535, the transmitted data is received by server 440. In one embodiment, the data is received by log data receiver 442 (FIG. 4). In one embodiment, the received data is stored in memory of server 440. In one embodiment, the received data is stored in a priority queue of server 440.

[0087] At operation 540, the received data is encoded. In one embodiment, the received data is encoded according to a predefined encoding protocol. In one embodiment, the received data is encoded according to criteria defined by a rule associated with the received data. In one embodiment, the received data is encoded according to a priority of the data in a priority queue. In one embodiment, the encoded data is stored in memory of server 440. In one embodiment, the encoded data is stored in memory in a priority queue of server 440. In one embodiment, operation 540 is omitted and the received data is not encoded.

[0088] In operation 545, the encoded data is transmitted to the user terminal 460. In one embodiment, the encoded data is transmitted wirelessly. In one embodiment, the encoded data is transmitted over a wired connection. In one embodiment, the encoded data is transmitted according to the priority of the encoded data in a priority queue. In one embodiment, the encoded data is transmitted by the log forwarder 446 (FIG. 4).

[0089] At operation 550, the encoded data is received. In one embodiment, the encoded data is received by a user terminal 460 (FIG. 4). In one embodiment, the received data is stored in a memory of the user terminal 460 (FIG. 4) prior to decoding. In one embodiment, the received data is stored in a priority queue of the user terminal 460 (FIG. 4).

[0090] At operation 555, the data is decoded. In one embodiment, the data is decoded according to a predetermined decoding protocol. In one embodiment, the data is decoded based on encoding protocol information received with the data from server 440. In one embodiment, the data is decoded according to the type of data received. In one embodiment, the data is decoded based on a priority in a priority queue. In one embodiment, the decoded data is stored in a memory of user terminal 460 (FIG. 4). In one embodiment, the decoded data is stored in a priority queue in a memory of user terminal 460 (FIG. 4).

[0091] At operation 560, the decoded data is visualized. Visualizing the decoded data provides a visual representation of the data. In one embodiment, the visual representation includes an image of the data from the vehicle. In one embodiment, the visual representation includes an icon representing the data from the vehicle. In one embodiment, the visual representation includes a table of the data. In one embodiment, the visual representation includes text, such as JSON text. In one embodiment, the visual representation includes a map location of the detected trigger event. In one embodiment, the decoded data is visualized using a user terminal 460 (FIG. 4).

[0092] In operation 565, a user is notified of the visualized data. In one embodiment, the user is notified using a UI, such as UI 110 (FIG. 1). In one embodiment, the user is notified using a portable device accessible by the occupant. In one embodiment, the notification includes an audio or visual notification. In one embodiment, the notification is configured to automatically generate a notification on a portable device accessible by the user.

[0093] Those skilled in the art will appreciate that modifications of method 500 are within the scope of the present disclosure. In some embodiments, at least one additional operation is included in method 500. For example, in some embodiments, method 500 further includes receiving confirmation of the triggering event from an occupant of the vehicle. In some embodiments, at least one operation is removed from method 500. For example, in some embodiments, operation 540 is removed and the data is provided to user terminal 460 without being encoded. In some embodiments, the order of operations in method 500 is changed. For example, in some embodiments, operation 510 is performed after a determination as to whether a triggering event was detected to store the sensor data. Those skilled in the art will appreciate that other modifications to method 500 are within the scope of the present disclosure.

[0094] FIG. 6 is a flow chart of a method 600 for collecting data using an in-vehicle system in an embodiment. In one embodiment, method 600 is performed as one or more operations of method 500 (FIG. 5). In one embodiment, method 600 is performed by context detector 422 (FIG. 4). In one embodiment, method 600 is performed using request retrieval system 100 (FIG. 1) or request retrieval system 400 (FIG. 4). In one embodiment, method 600 is performed using a system other than request retrieval system 100 (FIG. 1) or request retrieval system 400 (FIG. 4). Method 600 can be used to determine a memory structure to use to store sensor data based on whether the sensor data is likely to be used to satisfy a rule.

[0095] In operation 605, sensor data is collected. The sensor data is collected from one or more sensors connectable to the vehicle. In some embodiments, the sensor data includes control parameters of the vehicle. In some embodiments, the sensor data includes information about the vehicle's surroundings. In some embodiments, the sensor data includes data from sensors 414 (FIG. 4) and / or other sensors in the vehicle.

[0096] In operation 610, the sensor data is processed. The sensor data is processed to identify one or more triggering events for one or more rules stored in the vehicle's memory. In one embodiment, the sensor data is processed by the situation detector 422 (FIG. 4). In one embodiment, the sensor data is processed based on pre-processing instructions for one or more rules stored in the vehicle's memory. In one embodiment, the sensor data is processed to remove privacy concerns from the sensor data. In one embodiment, the sensor data is processed to compress the sensor data for storage in the vehicle's memory.

[0097] At operation 615, a determination is made as to whether the data from operation 610 has a high likelihood of future use. The determination is made based on whether the data is associated with a rule that satisfies one or more predefined conditions. In response to a determination that the rule satisfies one or more predefined conditions, a determination is made that the data has a high likelihood of future use. In response to a determination that the rule does not satisfy any of the one or more predefined conditions, a determination is made that the data has a low likelihood of future use. In one embodiment, operation 615 is similar to operation 515 and will not be described in detail for brevity.

[0098] By determining whether the data is likely to be used, operation 615 helps improve memory usage efficiency within the vehicle, extending the useful life of the memory and allowing for accurate and precise collection of rule-satisfying data. By storing frequently overwritten data in the VM, method 600 reduces the risk of NVM burnout and helps extend the useful life of the NVM, thereby reducing costs for the vehicle owner and maintaining sufficient resources of the vehicle to continue satisfying rules longer. By storing data related to safety systems or meeting other criteria in the NVM, method 600 ensures that data that is of high value to the user, manufacturer, vehicle owner, or other third parties is preserved even in low or no power conditions.

[0099] In response to determining that there is a low likelihood that the data will be used in the future, method 600 proceeds to operation 620. In response to determining that there is a high likelihood that the data will be used in the future, method 600 proceeds to operation 625. Regardless of the determination at operation 615, method 600 also proceeds to operation 630.

[0100] In operation 620, the data is stored in the VM. In one embodiment, the VM includes RAM, such as dynamic RAM (DRAM), static RAM (SRAM), or other suitable volatile memory structure. The data stored in the VM can be used to collect rule data in operation 635 in response to detection of a trigger event associated with a rule that requires the data stored in the VM.

[0101] In operation 625, the data is stored in NVM. In one embodiment, the NVM comprises flash memory, EPROM, ferroelectric RAM, or other suitable type of non-volatile memory structure. The data stored in the NVM can be used to collect rule data in operation 635 in response to detecting a trigger event associated with a rule that requires the data stored in the NVM.

[0102] In operation 630, a trigger event is detected. The trigger event is determined based on one or more rules stored in the NVM or VM at the vehicle. The trigger event is detected using one or more sensors in the vehicle. In one embodiment, the trigger event is a periodic trigger event that results in a rule being applied after a predetermined period of time has elapsed. In response to detecting the trigger event, one or more rules associated with the trigger event are applied.

[0103] In operation 635, data is collected based on the one or more rules applied based on the trigger event detected in operation 630. In an embodiment, the rule data is collected from the VM. In an embodiment, the rule data is collected from the NVM. In an embodiment, the rule data is collected from both the VM and the NVM. In an embodiment, multiple different rules require similar or overlapping sensor data. That is, the sensor type and time period in the data satisfying a first rule overlaps at least partially with the sensor type and time period in the data satisfying a second rule. In an embodiment, the first rule satisfies at least one predetermined condition and the second rule does not satisfy any of the predetermined conditions. In such a condition, the data satisfying the first rule is stored in the NVM and the data satisfying the second rule is stored in the VM. In an embodiment, to conserve vehicle resources, the data satisfying the first rule is stored in the NVM and only the data satisfying the second rule that does not overlap with the data satisfying the first rule is stored in the VM. In such a situation, operation 635 may read data from both the VM and the NVM in response to detecting a triggering event associated with the second rule in operation 630. In one embodiment, the collected rule data includes timestamp information regarding the time the data was collected or the time the triggering event was detected. In one embodiment, the collected rule data is stored using log collector 434 (FIG. 4).

[0104] In operation 640, the collected rule data is sent to a server, such as server 440 (FIG. 4). In one embodiment, the collected rule data is sent wirelessly. In one embodiment, the collected rule data is sent over a wired connection. In one embodiment, the collected rule data is sent using log sender 436 (FIG. 4).

[0105] Those skilled in the art will appreciate that modifications of method 600 are within the scope of the present disclosure. In some embodiments, at least one additional operation is included in method 600. For example, in some embodiments, method 600 further includes sending a notification to a user terminal, such as user terminal 460 (FIG. 4). In some embodiments, at least one operation is removed from method 600. For example, in some embodiments, operation 610 is removed if the raw sensor data is sent to a server. In some embodiments, the order of operations in method 600 is changed. For example, in some embodiments, operation 615 is performed prior to operation 610. Those skilled in the art will appreciate that other modifications to method 600 are within the scope of the present disclosure.

[0106] 7 is a schematic diagram of a system 700 in which the request retrieval system of the embodiment is implemented. The system 700 includes a processor 702, which is hardware, and a non-transitory computer-readable storage medium 704, which is encoded with, e.g., includes, a computer program code 706, e.g., an executable instruction set. The computer-readable storage medium 704 also has encoded therein instructions 707 for connecting to an external device. The processor 702 is electrically coupled to the computer-readable storage medium 704 via a bus 708. The processor 702 is also electrically coupled to an I / O interface 710 via the bus 708. The network interface 712 is also electrically coupled to the processor 702 via the bus 708. The network interface 712 is connected to a network 714, which allows the processor 702 and the computer-readable storage medium 704 to be connected to external elements via the network 714. The processor 702 is configured to execute computer program code 706 encoded on a computer-readable storage medium 704 to enable the system 700 to perform some or all of the operations described in the request retrieval system 100 (FIG. 1), the request retrieval system 400 (FIG. 4), the method 500 (FIG. 5), and the method 600 (FIG. 6).

[0107] In one embodiment, the processor 702 is a Central Processing Unit (CPU), a multi-processor, a distributed processing system, an Application Specific Integrated Circuit (ASIC), and / or other suitable processing unit.

[0108] In one embodiment, computer readable storage medium 704 is an electronic, magnetic, optical, electromagnetic, infrared, and / or semiconductor system (or apparatus or device). For example, computer readable storage medium 704 includes a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a Random Access Memory (RAM), a Read-Only Memory (ROM), a rigid magnetic disk, and / or an optical disk. In one embodiment using an optical disk, computer readable storage medium 704 includes a Compact Disk - Read Only Memory (CD-ROM), a Compact Disk - Read / Write (CD-R / W), and / or a Digital Versatile Disk (DVD).

[0109] In one embodiment, the storage medium 704 stores computer program code 706 configured to cause the system 700 to perform some or all of the operations described in the request retrieval system 100 (FIG. 1), the request retrieval system 400 (FIG. 4), the method 500 (FIG. 5), and the method 600 (FIG. 6). In one embodiment, the storage medium 704 stores information necessary to perform some or all of the operations described in the request retrieval system 100 (FIG. 1), the request retrieval system 400 (FIG. 4), the method 500 (FIG. 5), and the method 600 (FIG. 6), as well as information generated in performing some or all of the operations described in the request retrieval system 100 (FIG. 1), the request retrieval system 400 (FIG. 4), the method 500 (FIG. 5), and the method 600 (FIG. 6), such as sensor data parameters 716, rule parameters 718, collected data parameters 720, storage criteria parameters 722, and / or executable instructions for performing some or all of the operations described in the request retrieval system 100 (FIG. 1), the request retrieval system 400 (FIG. 4), the method 500 (FIG. 5), and the method 600 (FIG. 6).

[0110] System 700 includes an I / O interface 710. I / O interface 710 couples with external circuitry. In one embodiment, I / O interface 710 includes a keyboard, a keypad, a mouse, a trackball, a trackpad, and / or cursor direction keys for communicating information and commands to processor 702.

[0111] The system 700 also includes a network interface 712 coupled to the processor 702. The network interface 712 enables the system 700 to communicate with a network 714 to which one or more other computer systems are connected. The network interface 712 includes a wireless network interface, such as Bluetooth, Wi-Fi, WiMAX, GPRS, or WCDMA, or a wired network interface, such as Ethernet, USB, or IEEE 1394. In an embodiment, some or all of the operations described in the request retrieval system 100 (FIG. 1), the request retrieval system 400 (FIG. 4), the method 500 (FIG. 5), and the method 600 (FIG. 6) are implemented in two or more systems 700, and information such as priority level, query ID, query state, and query data is exchanged between the different systems 700 via the network 714.

[0112] [Appendix 1]

[0113] A method for collecting data in a vehicle includes receiving sensor data from at least one sensor. The method further includes determining whether one or more predetermined conditions are satisfied, the one or more predetermined conditions relating to rules for collection of the sensor data. The method further includes, in response to determining that at least one of the one or more predetermined conditions is satisfied, storing the sensor data in a non-volatile memory (NVM) structure. The method further includes, in response to determining that none of the one or more predetermined conditions is satisfied, storing the sensor data in a volatile memory (VM) structure.

[0114] [Appendix 2]

[0115] The method of claim 1, wherein the one or more predetermined conditions include whether a rule is applied, whether the rule includes a requirement for collection of data for a time period prior to detection of a triggering event, the length of time period prior to the triggering event for which data is collected, whether a fee has been received for the rule to use the NVM structure, or whether the rule relates to one or more safety systems in the vehicle.

[0116] [Appendix 3]

[0117] 3. The method of claim 1 or 2, wherein determining whether the one or more predetermined conditions are satisfied comprises determining whether the one or more predetermined conditions are not satisfied in accordance with a rule that includes a requirement for data for a period of time less than a first period threshold prior to the detected trigger event.

[0118] [Appendix 4]

[0119] A method according to any one of Supplementary Notes 1-3, wherein determining whether the one or more predetermined conditions are satisfied includes determining whether the one or more predetermined conditions are satisfied in accordance with rules including a requirement for data for a period of time equal to or longer than a second duration threshold prior to the detected trigger event.

[0120] [Appendix 5]

[0121] The method of any one of claims 1-4, wherein the first time period threshold is equal to the second time period threshold.

[0122] [Appendix 6]

[0123] A method according to any one of Supplementary Notes 1-5, wherein determining whether one or more predetermined conditions are satisfied comprises determining whether the one or more predetermined conditions are satisfied in response to a rule including a periodic trigger event.

[0124] [Appendix 7]

[0125] The method of any one of claims 1-6, further comprising detecting a triggering event and collecting sensor data in response to detecting the triggering event, where the triggering event is associated with a rule and where collecting the sensor data comprises reading the sensor data from at least one of an NVM structure or a VM structure.

[0126] [Appendix 8]

[0127] The method according to any one of Supplementary Notes 1-7, wherein collecting the sensor data includes reading the sensor data from both the NVM structure and the VM structure.

[0128] [Appendix 9]

[0129] A system for collecting data in a vehicle includes a non-volatile memory (NVM) structure and a volatile memory (VM) structure, where at least one of the NVM structure or the VM structure is configured to store instructions, and further includes a processor coupled to the NVM structure and the VM structure. The processor is configured to execute instructions for receiving sensor data from at least one sensor. The processor is configured to execute instructions for determining whether one or more predetermined conditions are satisfied, where the one or more predetermined conditions relate to rules for collection of the sensor data. The processor is configured to execute instructions in response to determining that at least one of the one or more predetermined conditions is satisfied, for storing the sensor data in the NVM structure. The processor is configured to execute instructions in response to determining that none of the one or more predetermined conditions is satisfied, for storing the sensor data in the VM structure.

[0130] [Appendix 10]

[0131] The system of claim 9, wherein the one or more predetermined conditions include whether a rule is applied, whether the rule includes a requirement for collection of data for a time period prior to detection of a triggering event, the length of time period prior to the triggering event for which data is collected, whether a fee has been received for the rule to use the NVM structure, or whether the rule relates to one or more safety systems in the vehicle.

[0132] [Appendix 11]

[0133] The system of claim 9 or 10, wherein the processor is further configured to execute instructions for determining whether one or more predetermined conditions are not satisfied in response to a rule comprising a request for data for a period shorter than a first period threshold prior to a detected trigger event.

[0134] [Appendix 12]

[0135] The system of any one of Supplementary Notes 9-11, wherein the processor is further configured to execute instructions for determining whether one or more predetermined conditions are satisfied in response to a rule including a requirement for data for a period of time equal to or longer than a second duration threshold prior to a detected trigger event.

[0136] [Appendix 13]

[0137] The system of any one of Appendixes 9-12, wherein the first time period threshold is equal to the second time period threshold.

[0138] [Appendix 14]

[0139] The system of any one of Supplementary Notes 9-13, wherein the processor is further configured to execute instructions for determining whether one or more predetermined conditions are satisfied in response to a rule including a periodic trigger event.

[0140] [Appendix 15]

[0141] The system of any one of Clauses 9-14, wherein the processor is further configured to execute instructions for detecting a triggering event and collecting sensor data in response to detecting the triggering event, where the triggering event is associated with a rule and where collecting the sensor data includes reading the sensor data from at least one of an NVM structure or a VM structure.

[0142] [Appendix 16]

[0143] The system of any one of Supplementary Notes 9-15, wherein the processor is further configured to execute instructions to collect sensor data by reading the sensor data from both the NVM structure and the VM structure.

[0144] [Appendix 17]

[0145] A non-transitory computer-readable medium configured to store instructions. The instructions are configured to cause a processor to perform an operation to receive sensor data from at least one sensor. The instructions are configured to cause the processor to perform an operation to determine whether one or more predetermined conditions are satisfied, where the one or more predetermined conditions relate to rules for collection of the sensor data. The instructions are configured to cause the processor to perform an operation to store the sensor data in a non-volatile memory (NVM) structure in response to determining that at least one of the one or more predetermined conditions is satisfied. The instructions are configured to cause the processor to perform an operation to store the sensor data in a volatile memory (VM) structure in response to determining that none of the one or more predetermined conditions are satisfied.

[0146] [Appendix 18]

[0147] The non-transitory computer-readable medium of claim 17, wherein the one or more predetermined conditions include whether a rule is applied, whether the rule includes a requirement for collection of data for a time period prior to detection of a triggering event, the length of time period prior to the triggering event for which data is collected, whether a fee for the rule to use the NVM structure has been received, or whether the rule relates to one or more safety systems in the vehicle.

[0148] [Appendix 19]

[0149] 19. The non-transitory computer-readable medium of claim 17 or 18, wherein the instructions are further configured to cause the processor to perform operations for detecting a triggering event and collecting sensor data in response to detecting the triggering event, where the triggering event is associated with a rule and where collecting the sensor data includes reading the sensor data from at least one of an NVM structure or a VM structure.

[0150] [Appendix 20]

[0151] The non-transitory computer-readable medium of any one of Supplementary Notes 17-19, wherein the instructions are further configured to cause the processor to perform an operation to collect sensor data by reading the sensor data from both the NVM structure and the VM structure.

[0152] The above outlines features of some embodiments to enable those skilled in the art to better understand aspects of the present disclosure. Those skilled in the art will appreciate that the present disclosure can be readily utilized to design or improve other processes or structures to carry out similar purposes and / or achieve similar advantages as the embodiments presented herein. Those skilled in the art will also recognize that such equivalent constructions do not depart from the spirit and scope of the present disclosure, and that modifications, substitutions, and variations of the present disclosure may be made without departing from the spirit and scope of the present disclosure.

Claims

1. receiving sensor data from at least one sensor; determining whether one or more predetermined conditions are satisfied, the one or more predetermined conditions relating to rules for collection of sensor data; responsive to determining that at least one of the one or more predetermined conditions is satisfied, storing the sensor data in a non-volatile memory (NVM) structure; responsive to determining that none of the one or more predetermined conditions are satisfied, storing the sensor data in a volatile memory (VM) structure.

16. A method for collecting data in a vehicle, comprising:

2. The one or more predetermined conditions are: Whether said rules are applied, whether the rule includes a requirement to collect data about the time prior to detection of a triggering event; the length of time during which the data is collected prior to the triggering event; Whether or not a fee was received for the rules for using the NVM structure; or whether the rule relates to one or more safety systems within the vehicle; 2. The method of claim 1, comprising:

3. 3. The method of claim 1 or 2, wherein determining whether the one or more predetermined conditions are satisfied comprises determining whether the one or more predetermined conditions are not satisfied according to the rule including a requirement for data for a period of time less than a first period threshold prior to a detected trigger event.

4. 4. The method of claim 3, wherein determining whether the one or more predetermined conditions are satisfied comprises determining whether the one or more predetermined conditions are satisfied in accordance with the rule including a requirement for data for a period of time equal to or greater than a second duration threshold prior to a detected triggering event.

5. The method of claim 4 , wherein the first duration threshold is equal to the second duration threshold.

6. 3. The method of claim 1 or 2, wherein determining whether the one or more predetermined conditions are satisfied comprises determining whether the one or more predetermined conditions are satisfied in response to the rule including a periodic trigger event.

7. detecting a triggering event, said triggering event being associated with said rule; and collecting sensor data in response to detecting the trigger event, the collecting sensor data including reading the sensor data from at least one of the NVM structure or the VM structure. The method according to claim 1 or 2.

8. The method of claim 7 , wherein collecting the sensor data includes reading the sensor data from both the NVM structure and the VM structure.

9. a non-volatile memory (NVM) structure; a volatile memory (VM) structure, and at least one of the NVM structure or the VM structure configured to store instructions; receiving sensor data from at least one sensor; determining whether one or more predetermined conditions are satisfied, the one or more predetermined conditions relating to rules for collection of sensor data; responsive to determining that at least one of the one or more predetermined conditions is satisfied, storing the sensor data in the NVM structure; In response to determining that none of the one or more predetermined conditions are satisfied, save the sensor data to the VM structure. a processor coupled to the NVM structure and the VM structure, the processor configured to execute instructions for: A system for collecting data in a vehicle.

10. The one or more predetermined conditions are: Whether said rules are applied, whether the rule includes a requirement to collect data about the time prior to detection of a triggering event; the length of time during which the data is collected prior to the triggering event; Whether or not a fee was received for the rules for using the NVM structure; or whether the rule relates to one or more safety systems within the vehicle; The system of claim 9 , comprising:

11. 11. The system of claim 9 or 10, wherein the processor is further configured to execute instructions for determining whether the one or more predetermined conditions are not satisfied in response to the rule comprising a request for data for a period of time less than a first duration threshold prior to a detected trigger event.

12. 12. The system of claim 11, wherein the processor is further configured to execute instructions for determining whether the one or more predetermined conditions are satisfied in response to the rule including a request for data for a period of time equal to or greater than a second duration threshold prior to a detected triggering event.

13. The system of claim 12 , wherein the first duration threshold is equal to the second duration threshold.

14. 11. The system of claim 9 or 10, wherein the processor is further configured to execute instructions for determining whether the one or more predetermined conditions are satisfied in response to the rule comprising a periodic trigger event.

15. The processor, detecting a triggering event, said triggering event being associated with said rule; and further configured to execute instructions for collecting sensor data in response to detecting the trigger event, the collecting the sensor data including reading the sensor data from at least one of the NVM structure or the VM structure.

11. A system according to claim 9 or 10.

16. The method of claim 9 or 10, wherein the processor is further configured to execute instructions to collect the sensor data by reading the sensor data from both the NVM structure and the VM structure.

17. A non-transitory computer-readable medium for inclusion in a system within a vehicle and configured to store instructions, the instructions comprising: receiving sensor data from at least one sensor; determining whether one or more predetermined conditions are satisfied, the one or more predetermined conditions relating to rules for collection of sensor data; responsive to determining that at least one of the one or more predetermined conditions is satisfied, storing the sensor data in a non-volatile memory (NVM) structure; responsive to determining that none of the one or more predetermined conditions are satisfied, storing the sensor data in a volatile memory (VM) structure. A non-transitory computer-readable medium configured to cause a processor to perform operations for:

18. The one or more predetermined conditions are: Whether said rules are applied, whether the rule includes a requirement to collect data about the time prior to detection of a triggering event; the length of time during which the data is collected prior to the triggering event; Whether or not a fee was received for the rules for using the NVM structure; or whether the rule relates to one or more safety systems within the vehicle; 20. The non-transitory computer readable medium of claim 17, comprising:

19. The instructions cause the processor to: detecting a triggering event, said triggering event being associated with said rule; and further configured to perform an operation to collect sensor data in response to detecting the trigger event, the collecting the sensor data including reading the sensor data from at least one of the NVM structure or the VM structure.

19. The non-transitory computer readable medium of claim 17 or 18.

20. 20. The non-transitory computer-readable medium of claim 19, wherein the instructions are further configured to cause the processor to perform an operation to collect the sensor data by reading the sensor data from both the NVM structure and the VM structure.

Images