Data storage device and method for accident mode storage of vehicle information

Abstract

A data storage device and method for accident mode storage of vehicle information are disclosed. In one embodiment, a data storage device is provided that includes a memory and one or more processors. The memory includes a single-layer cell (SLC) memory and a multi-layer cell (MLC) memory. The one or more processors, individually or in combination, are configured to: receive a command from a vehicle to enter an accident mode; and in response to receiving a command from the vehicle to enter the accident mode, relocating the vehicle information stored in the MLC memory to the SLC memory. Other embodiments are disclosed.

Description

Cross-references to related applications

[0001] This application claims the benefit and priority of U.S. Nonprovisional Patent Application Serial No. 18 / 434,976. Background Technology

[0002] Data storage devices can be used in vehicles to store various vehicle information, such as vehicle speed, video from cameras on the vehicle, etc. If a vehicle is involved in an accident, it may be desirable to retrieve vehicle information from the data storage device for analysis, thereby helping to understand events that occurred before, during, and / or after the accident. Attached Figure Description

[0003] Figure 1A This is a block diagram of the data storage device in the implementation scheme.

[0004] Figure 1B This is a block diagram illustrating the storage module of an example implementation.

[0005] Figure 1C This is a block diagram illustrating a hierarchical storage system for an example implementation.

[0006] Figure 2A This is an example based on the implementation plan. Figure 1A The block diagram of the controller components of the data storage device is illustrated in the figure.

[0007] Figure 2B This is an example based on the implementation plan. Figure 1A The block diagram of the components of the data storage device is shown in the figure.

[0008] Figure 3 This is a block diagram of the host and data storage devices in the implementation scheme.

[0009] Figure 4 This is a flowchart of the accident mode storage method for the implementation plan.

[0010] Figure 5 This is a flowchart of an accident mode storage method for another implementation scheme. Detailed Implementation

[0011] The following embodiments generally relate to a data storage device and method for storing accident modes of vehicle information. In one embodiment, a data storage device is provided, comprising a memory and one or more processors. The memory includes single-cell (SLC) memory and multi-cell (MLC) memory. One or more processors are configured individually or in combination to: receive a command to enter an accident mode from a vehicle; and in response to receiving the command to enter an accident mode from the vehicle, relocate vehicle information stored in the MLC memory to the SLC memory.

[0012] In some implementations, one or more processors, individually or in combination, are also configured to prevent vehicle information from being relocated back to the MLC memory until a command to exit accident mode is received from the vehicle.

[0013] In some implementations, one or more processors, individually or in combination, are also configured to write-protect the vehicle information after it has been relocated to the SLC memory.

[0014] In some implementations, write trimming is used to relocate vehicle information to SLC memory, and this write trimming is more resistant to high temperatures than write trimming used when the data storage device is not in accident mode.

[0015] In some implementations, vehicle information is identified by a logical block address (LBA) range received from the vehicle.

[0016] In some implementations, one or more processors are also configured individually or in combination to: store additional vehicle information outside the LBA range in the SLC memory; and prevent the additional vehicle information from being relocated to the MLC memory until a command to exit accident mode is received from the vehicle.

[0017] In some implementations, the relocation of vehicle information from MLC memory to SLC memory is given higher priority than other operations.

[0018] In some implementations, one or more processors are also configured individually or in combination to: receive a command to exit accident mode from the vehicle; and in response to receiving the command to exit accident mode from the vehicle, fold vehicle information stored in the SLC memory into the MLC memory.

[0019] In some implementations, vehicle information includes vehicle speed, vehicle steering angle, vehicle tire pressure, vehicle braking activity, vehicle engine / motor activity, sound recordings captured by vehicle microphones, images captured by vehicle cameras, videos captured by vehicle cameras, vehicle geolocation, and / or data derived from vehicle geolocation.

[0020] In some implementations, the memory includes a three-dimensional memory.

[0021] In another embodiment, a method is provided to be performed in a data storage device including memory comprising single-level cell (SLC) regions and multi-level cell (MLC) regions. The method includes: receiving an accident notification from a vehicle; and in response to receiving the accident notification from the vehicle: creating free space in the SLC region by erasing previously written data in the SLC region; and writing vehicle information into the free space created in the SLC region, wherein the vehicle information is not collapsed into the MLC region until the accident notification is cleared.

[0022] In some implementations, the method further includes: receiving a command to clear an incident notification; and in response to receiving the command to clear an incident notification, collapsing vehicle information into the MLC area.

[0023] In some implementations, the method also includes write protection of vehicle information.

[0024] In some implementations, write trimming is used to write vehicle information into the free space of the SLC area. This write trimming is more resilient to high temperatures than write trimming used before the data storage device receives accident notification from the vehicle.

[0025] In some implementations, vehicle information is identified by a logical block address (LBA) range received from the vehicle.

[0026] In some implementations, the method further includes storing additional vehicle information outside the LBA range in the SLC area, wherein the additional vehicle information is not collapsed into the MLC area until the accident notification is cleared.

[0027] In some implementations, creating free space and writing vehicle information are given higher priority than other operations.

[0028] In some implementations, vehicle information includes vehicle speed, vehicle steering angle, vehicle tire pressure, vehicle braking activity, vehicle engine / motor activity, sound recordings captured by vehicle microphones, images captured by vehicle cameras, videos captured by vehicle cameras, vehicle geolocation, and / or data derived from vehicle geolocation.

[0029] In some implementations, the memory includes a three-dimensional memory.

[0030] In another embodiment, a data storage device is provided, comprising: a single-cell (SLC) memory; a multi-cell (MLC) memory; and a component for storing vehicle information received from the vehicle in the SLC memory instead of the MLC memory in response to receiving an accident prediction from the vehicle.

[0031] Other embodiments are possible, and each embodiment can be used alone or in combination. Therefore, various embodiments will now be described with reference to the accompanying drawings. Implementation Plan

[0032] The implementation schemes described below relate to data storage devices (DSDs). As used herein, a "data storage device" refers to a non-volatile device that stores data. Examples of DSDs include, but are not limited to, hard disk drives (HDDs), solid-state drives (SSDs), tape drives, hybrid drives, etc. Detailed information about example DSDs is provided below.

[0033] Figures 1A to 1C Examples of data storage devices suitable for implementing various aspects of these implementation schemes are shown below. It should be noted that these are merely examples and other specific implementations may be used. Figure 1A This is a block diagram illustrating a data storage device 100 according to an implementation scheme. (See reference) Figure 1A In this example, the data storage device 100 includes a controller 102 coupled to non-volatile memory, which may consist of one or more non-volatile memory dies 104. As used herein, the term "die" refers to a non-volatile memory cell formed on a single semiconductor substrate and the associated circuitry for managing the physical operations of those non-volatile memory cells. The controller 102 interacts with a host system and sends sequences of commands for read, program, and erase operations to the non-volatile memory die 104. Furthermore, as used herein, the phrase "communicating with" or "coupled with" can mean directly communicating / coupling with or indirectly communicating / coupling with through one or more components, which may or may not be shown or described herein. The communication / coupling can be wired or wireless.

[0034] Controller 102 (which may be a non-volatile memory controller (e.g., flash memory, resistive random access memory (ReRAM), phase-change memory (PCM), or magnetoresistive random access memory (MRAM) controller)) may include one or more components configured individually or in combination to perform certain functions, including but not limited to those described herein and illustrated in the flowcharts. For example, such as Figure 2AAs shown, controller 102 may include one or more processors 138, which are individually or in combination configured to perform functions, such as, but not limited to, those described herein and illustrated in the flowcharts, by executing computer-readable program code stored in one or more non-transitory memories 139 within controller 102 and / or external to controller 102 (e.g., in random access memory (RAM) 116 or read-only memory (ROM) 118). Furthermore, the one or more components may include circuitry, such as, but not limited to, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers.

[0035] In one example implementation, a nonvolatile memory controller 102 is a device that manages data stored on nonvolatile memory and communicates with a host (such as a computer or electronic device) having any suitable operating system. The nonvolatile memory controller 102 may have various functionalities beyond those specifically described herein. For example, the nonvolatile memory controller may format the nonvolatile memory to ensure proper operation, map out faulty nonvolatile memory cells, and allocate spare cells to replace future failed cells. A portion of the spare cells may be used to maintain firmware (and / or other metadata for housekeeping and tracking) to operate the nonvolatile memory controller and implement other features. In operation, the host may communicate with the nonvolatile memory controller when it needs to read data from or write data to the nonvolatile memory. If the host provides a logical address where data will be read / written, the nonvolatile memory controller may translate the logical address received from the host into a physical address in the nonvolatile memory. The non-volatile memory controller can also perform various memory management functions, such as, but not limited to, wear leveling (distributing writes to avoid wear on specific memory blocks that would otherwise be repeatedly written) and garbage collection (moving only valid data pages to a new block after a block is full, so that the full block can be erased and reused).

[0036] The non-volatile memory die 104 may comprise any suitable non-volatile storage medium, including resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), phase-change memory (PCM), NAND flash memory cells, and / or NOR flash memory cells. The memory cells may take the form of solid-state (e.g., flash memory) memory cells and may be programmable once, less-programmable, or more-programmable. The memory cells may also be single-level cells (SLC), multi-level cells (MLC) (e.g., two-level cells, three-level cells (TLC), four-level cells (QLC), etc.) or may use other memory cell-level technologies now known or developed hereafter. Furthermore, the memory cells may be fabricated in two or three dimensions.

[0037] The interface between controller 102 and non-volatile memory die 104 can be any suitable flash memory interface, such as switching modes 200, 400, or 800. In one embodiment, data storage device 100 can be a card-based system, such as a Secure Digital (SD) card or a micro-Secure Digital (micro-SD) card. In another embodiment, data storage device 100 can be part of an embedded data storage device.

[0038] Despite Figure 1A In the illustrated example, data storage device 100 (sometimes referred to herein as a storage module) includes a single channel between controller 102 and non-volatile memory die 104; however, the subject matter described herein is not limited to having a single memory channel. For example, in some architectures (such as...) Figure 1B and Figure 1C In the architecture shown, depending on the controller's capabilities, there may be two, four, eight, or more memory channels between the controller and the memory device. In any of the embodiments described herein, even if a single channel is shown in the figures, there may be more than one single channel between the controller and the memory die.

[0039] Figure 1B An example is illustrated of a storage module 200 comprising multiple non-volatile data storage devices 100. Thus, the storage module 200 may include a storage controller 202 that interfaces with a host and with data storage devices 204, which include multiple data storage devices 100. The interface between the storage controller 202 and the data storage devices 100 may be a bus interface, such as a Serial Advanced Technology Attachment (SATA), a Peripheral Component Rapid Interconnect (PCIe) interface, a Double Data Rate (DDR) interface, or a Serial Connected Small Scale Compute Interface (SAS / SCSI). In one embodiment, the storage module 200 may be a solid-state drive (SSD) or a non-volatile dual in-line memory module (NVDIMM), as found in server PCs or portable computing devices such as laptops and tablets.

[0040] Figure 1C This is a block diagram illustrating a hierarchical storage system. The hierarchical storage system 250 includes a plurality of storage controllers 202, each of which controls a corresponding data storage device 204. A host system 252 can access the memory within the storage system 250 via a bus interface. In one embodiment, the bus interface may be a Non-Volatile Memory Fast (NVMe) interface or an Ethernet Fibre Channel (FCoE) interface. In one embodiment, Figure 1CThe illustrated system may be a rack-mounted mass storage system that can be accessed by multiple host computers, such as those found in data centers or other locations where mass storage is required.

[0041] Refer again Figure 2A The controller 102 in this example also includes a front-end module 108 communicating with the host, a back-end module 110 communicating with one or more non-volatile memory dies 104, and various other components or modules, such as, but not limited to, a buffer manager / bus controller module that manages buffers in RAM 116 and controls the internal bus arbitration of controller 102. Modules may include one or more processors or components, as discussed above. ROM 118 may store system boot code. Although in Figure 2A The RAM 116 is illustrated as being located separately from the controller 102, but in other embodiments, one or both of the RAM 116 and ROM 118 may be located within the controller 102. In yet another embodiment, portions of the RAM 116 and ROM 118 may be located both within and outside the controller 102.

[0042] Front-end module 108 includes a host interface 120 and a physical layer interface (PHY) 122 that provide electrical communication with the host or next-level storage controller. The type of host interface 120 may be selected depending on the type of memory used. Examples of host interfaces 120 include, but are not limited to, SATA, SATA Express, Serial ATA Small Computer System Interface (SAS), Fibre Channel, Universal Serial Bus (USB), PCIe, and NVMe. Host interface 120 typically facilitates the transmission of data, control signals, and timing signals.

[0043] Backend module 110 includes an error correction code (ECC) engine 124 that encodes data bytes received from the host and decodes and corrects errors in data bytes read from the non-volatile memory. Command sequencer 126 generates command sequences (such as programming and erasing command sequences) to be sent to the non-volatile memory die 104. RAID (Redundant Array of Independent Disks) module 128 manages the generation of RAID parity and the recovery of faulty data. RAID parity can be used as an additional level of integrity protection for data being written to memory device 104. In some cases, RAID module 128 may be part of ECC engine 124. Memory interface 130 provides command sequences to the non-volatile memory die 104 and receives status information from the non-volatile memory die 104. In one embodiment, memory interface 130 may be a double data rate (DDR) interface, such as a switching mode 200, 400, or 800 interface. The controller 102 in this example also includes a media management layer 137 and a flash control layer 132, which controls the overall operation of the back-end module 110.

[0044] The data storage device 100 also includes other discrete components 140, such as external electrical interfaces, external RAM, resistors, capacitors, or other components that can interface with the controller 102. In an alternative embodiment, one or more of the physical layer interface 122, RAID module 128, media management layer 138, and buffer management / bus controller 114 are optional components that are not necessary in the controller 102.

[0045] Figure 2B This is a block diagram illustrating the components of the non-volatile memory die 104 in more detail. The non-volatile memory die 104 includes peripheral circuitry 141 and a non-volatile memory array 142. The non-volatile memory array 142 includes non-volatile memory cells for storing data. The non-volatile memory cells can be any suitable non-volatile memory cells, including ReRAM, MRAM, PCM, NAND flash memory cells, and / or NOR flash memory cells in a two-dimensional and / or three-dimensional configuration. The non-volatile memory die 104 also includes a data cache 156 for caching data. The peripheral circuitry 141 in this example includes a state machine 152 that provides state information to the controller 102. The peripheral circuitry 141 may also include one or more components that are individually or in combination configured to perform certain functions, including but not limited to those described herein and illustrated in the flowchart. For example, as... Figure 2BAs shown, the memory die 104 may include one or more processors 168, which are individually or in combination configured to execute computer-readable program code stored in one or more non-transitory memories 169, in the memory array 142, or external to the memory die 104. Alternatively, the one or more components may include circuitry, such as, but not limited to, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers.

[0046] As a complement or alternative to one or more processors 138 (or more generally, components) in controller 102 and one or more processors 168 (or more generally, components) in memory die 104, data storage device 100 may include another set of one or more processors (or more generally, components). Generally, regardless of the location and number of the one or more processors (or more generally, components) in data storage device 100, these processors may be configured individually or in combination to perform various functions, including but not limited to those described herein and illustrated in the flowcharts. For example, the one or more processors (or components) may be located in controller 102, memory device 104, and / or other locations within data storage device 100. Furthermore, different processors (or components) or combinations of processors (or components) may be used to perform different functions. Additionally, components for performing functions may be implemented using a controller that includes one or more components (e.g., processors or other components described above).

[0047] Return again Figure 2A The flash control layer 132 (which will be referred to herein as the flash translation layer (FTL)) handles flash errors and communicates with the host. Specifically, the FTL (which may be an algorithm in the firmware) is responsible for the internal operations of memory management and translates writes from the host into writes destined for memory 104. An FTL may be necessary because memory 104 may have limited endurance, may only be written to in multi-page format, and / or may not be written to at all (unless it is erased as a block). The FTL understands these potential limitations of memory 104, which may be invisible to the host. Therefore, the FTL attempts to translate writes from the host into writes destined for memory 104.

[0048] The FTL may include a logical-to-physical address (L2P) mapping (sometimes referred to herein as a table structure or data structure) and allocated cache memory. In this way, the FTL translates logical block addresses (“LBAs”) from the host into physical addresses in memory 104. The FTL may include other features such as, but not limited to, power-down recovery (enabling the recovery of the FTL’s data structures in the event of a sudden power outage) and wear leveling (ensuring uniform wear across memory blocks to prevent certain blocks from becoming excessively worn, which would lead to a greater likelihood of failure).

[0049] Turn to the attached image again. Figure 3 This is a block diagram of a host 300 and a data storage device 100 according to an embodiment. The host 300 may take any suitable form, including but not limited to a computer, mobile phone, tablet, wearable device, digital video recorder, surveillance system, etc. The host 300 (hereinafter referred to as a computing device) in this embodiment includes one or more processors 330 and one or more memories 340. In one embodiment, computer-readable program code stored in one or more memories 340 configures one or more processors 330 to perform actions described herein as being performed by the host 300. Therefore, actions performed by the host 300 are sometimes referred to herein as being performed by an application (computer-readable program code) running on the host 300. For example, the host 300 may be configured to transfer data (e.g., initially stored in the host's memory 340) to the data storage device 100 for storage in the memory 104 of the data storage device.

[0050] As mentioned above, data storage devices can be used in vehicles (e.g., cars, trucks, buses, trains, airplanes, ships, motorcycles, scooters, etc.) to store various vehicle information. As used herein, "vehicle information" can refer to any information generated by components in or on a vehicle and / or information related to a vehicle but generated by components outside the vehicle. Examples of such “vehicle information” include, but are not limited to, speed (e.g., generated by a speed sensor in the vehicle), steering angle positioning or movement (e.g., generated by a steering angle sensor in the vehicle), tire pressure (e.g., generated by a tire pressure sensor in the vehicle), braking activity (e.g., generated by a brake pedal sensor and / or a brake controller in the vehicle), engine / motor activity (e.g., generated by an engine / motor sensor / controller in the vehicle), sound recording (e.g., generated by a microphone inside and / or outside the vehicle), distance information to another vehicle (e.g., using radar, ultrasound, etc.), image and / or video recording (e.g., generated by a camera installed inside and / or outside the vehicle, with its field of view inside and / or outside the vehicle) and / or geographic location (e.g., Global Positioning System (GPS) coordinates) with optional derived data (e.g., speed, rate, etc. based on various geographic location data points). As these examples show, “vehicle information” can relate to the state of a vehicle (e.g., speed, steering angle, etc.) and / or to events outside or inside the vehicle, but not necessarily to events concerning the vehicle itself (e.g., video footage of the road, video footage of the vehicle’s driver, etc.).

[0051] If a vehicle is involved in an accident, it may be desirable to retrieve vehicle information from data storage devices for analysis to help understand events that occurred before, during, and / or after the accident. For example, if the vehicle is a car, knowing how fast it was traveling before the accident, when and how quickly it applied the brakes, whether the vehicle suddenly veered, whether driver image or video data shows the driver was asleep or impaired, and whether image or video data shows how long the collision object remained in the driver's field of vision. In this way, the data storage devices in a vehicle can be considered similar to the "black boxes" on an airplane.

[0052] Data storage devices can be configured to store vehicle information in any suitable manner. For example, vehicle information (e.g., from predefined key functions) can be stored cyclically (similar to a surveillance system), where the vehicle information is stored for a time period (e.g., 30 seconds, minutes, a day, or multiple days), and then overwritten by new data as new data appears (e.g., in a first-in, first-out (FIFO) manner). In this example, the data storage device acts as a circular buffer, storing vehicle information generated during a specified time period prior to the incident. In other examples, the data storage device may also store vehicle information generated during and / or after the incident, as such information can aid in incident analysis (or in other contexts, such as carjacking or surveillance of external events (e.g., criminal activity occurring near the vehicle but not involving the vehicle)).

[0053] Because vehicle information can be critical data, it may be desirable to protect it in the memory of a data storage device so that it can be reliably retrieved after an accident. However, several reliability challenges may exist. For example, if an accident generates heat, this heat could lead to the loss of vehicle information in memory. Also, it may take a relatively long time to retrieve vehicle information from the data storage device after an accident (e.g., because the vehicle has been in a wrecked car parking lot for an extended period). The memory in the data storage device may not be able to reliably store vehicle information for extended periods, especially in the presence of other adverse conditions such as heat. These problems can be exacerbated when vehicle information is stored in multi-level cell (MLC) areas of the memory, as MLC memory is generally less reliable than single-level cell (SLC) memory.

[0054] The following implementation scheme can be used to address this reliability issue. In one implementation scheme, a vehicle (in these examples, it will be referred to as host 300) is configured to predict impending accidents (e.g., by interpreting various vehicle information, etc.) and transmit notifications of such events to data storage device 100. In response to receiving the notification, controller 102 in data storage device 100 may store subsequently received data in an SLC region (e.g., a partition) in memory 104 instead of an MLC region (e.g., a partition), since data is generally more reliably stored in SLC memory than in MLC memory. Optionally, controller 102 may utilize write trimming that is more resilient to high temperatures (e.g., “special reliable write trimming”) to store the data.

[0055] For example, a notification could be an identifier of a logical block address (LBA) range of data that is considered relevant to incident analysis (e.g., a key factor in incident analysis) and is therefore expected to be stored with relatively high reliability for analysis in the event of a predicted incident. In this example, the controller 102 in the data storage device 100 receives data from the host 300 and stores it in an allocated LBA range in an SLC partition (and optionally, with special reliability trimmings that will be more resilient to high temperatures).

[0056] Furthermore, controller 102 can be configured to relocate critical data from the MLC partition to a specially allocated LBA range within the SLC partition. In such cases, relocation can be given priority over other operations. Additionally, controller 102 can mark data as "do not relocate to MLC" until host 300 releases the accident mode or until it is rewritten (the specially allocated LBA range can be marked for write protection). Moreover, to protect predicted accident data, the next set of received data can also be written to the SLC memory (e.g., forced by a counter) and can also be marked as "do not relocate to MLC".

[0057] In the event that the host machine's prediction of an impending accident is incorrect, the host 300 can provide a message to the data storage device 100 to avoid the accident, and the data storage device 100 can exit accident mode. Upon exiting accident mode, the controller 102 can collapse the SLC data to the MLC and continue normal mode operation. However, in the event of an actual accident, the above implementation helps ensure that critical vehicle data is stored with relatively high reliability and has a better chance of withstanding high temperatures and remaining in a wrecked car parking lot for a longer period. Protecting such data can aid in analyzing post-accident issues and understanding safety concerns.

[0058] Turn to the attached image again. Figure 4 This is a flowchart 400 illustrating this implementation scheme. In this example, the host 300 is a vehicle, such as a car. Figure 4As shown, host 300 sends a command to data storage device 100 to write data LBA x…LBA y (actions 405 and 410). When host 300 identifies that a vehicle may be involved in an accident, host 300 notifies data storage device 100 that LBA yz to LBA y are affected (action 415). This puts data storage device 100 into accident mode. In this example, accident mode causes controller 102 in data storage device 100 to change write trimming to handle high temperatures (action 417). Furthermore, when host 300 sends a command to data storage device 100 to write-protect LBA A;B (action 420), controller 102 in storage device 100 responds by marking LBA yz to LBA y as for relocation from MLC memory to SLC memory (action 422) and further marking those LBAs as "do not relocate to MLC", so that the data in those blocks is not moved back to MLC memory (action 424). When the host 300 sends a command to the data storage device 100 to write data LBA n (Action 425), the controller 102 in the data storage device 100 uses special trimming and writes the data as the last LBA to be written to the SLC with the "Do not relocate to MLC" setting (Action 427).

[0059] At a later point, host 300 (or another entity) sends a command to data storage device 100 to read the protected data (action 430). After reading the protected data, host 300 (or another entity) may send a command to data storage device 100 to clear the accident mode (action 435). In response to this command, controller 102 in data storage device 100 can clear the accident mode from all LBAs in memory 104 (action 437). Then, host 300 (or another entity) may send a command to data storage device 100 to clear write protection on the LBAs (action 440), and controller 102 executes the command (action 442).

[0060] As described above, many implementation schemes can be used. For example, some data storage devices store data only in the SLC memory area. Using such data storage devices, the saved data can be divided into segments, for example, 30 seconds. In the event of an accident, the host can decide to retain the data and not overwrite it. Therefore, in this example, no special trigger is used to retain the data. The advantage of this method is that the data is always stored in the SLC memory area and is more resilient (e.g., the program-erase count (PEC) of an SLC block can be thirty times that of an MLC block).

[0061] In another embodiment, host 300 is configured to identify emergency incident conditions and transmit a notification to data storage device 100. The advantage of this embodiment is that, in most cases, memory 104 is used as MLC, and data remains in SLC when it should be saved for analysis. In one example, the data has at least two “parts” of size. In the event of an incident, host 300 can transmit a notification to store the current part in SLC memory and not relocate it to MLC memory. Therefore, the data stored in SLC memory is protected until it is rewritten or erased. In parallel, host 300 can erase the two old parts to free up SLC space for data storage. In one example, those parts (or LBA ranges) are not rewritten until the protected parts are erased or rewritten. The above process can be performed several times. A typical scenario could be saving the pre-incident and post-incident parts. This process may be limited by the ratio of SLC to MLC memory areas. Therefore, once the stored vehicle information is retrieved, the host 300 can release the accident section or send a specific command to the data storage device 100 to release all sections.

[0062] Turn to the attached image again. Figure 5 This is flowchart 500 illustrating this implementation scheme. In this example, host 300 is a vehicle, such as a car. Figure 5 As shown, host 300 sends a command to data storage device 100 to write data LBA x…LBA y (actions 505 and 510). When host 300 identifies that a vehicle is involved in an accident, host 300 notifies the data storage device (action 515). Next, host 300 marks the portion of data it wants to protect (action 520). In response, controller 102 of data storage device 100 enters accident mode by marking portion N (which is LBA yz to y) as protected (action 522). Then, host 300 sends a command to data storage device 100 to erase one or more (here, two) sets of old portions (action 525). Afterward, host 300 continues to send commands to write data to data storage device 100 (action 530), and controller 102 in data storage device 100 executes the commands (action 532).

[0063] At a later time, host 300 (or another entity) sends a command to data storage device 100 to read the protected data (action 535). After reading the protected data, host 300 (or another entity) may send a command to data storage device 100 to clear the accident mode (action 540). In response to this command, controller 102 in data storage device 100 can clear the accident mode from all LBAs in memory 104 (action 542).

[0064] Finally, as mentioned above, any suitable type of memory can be used. Semiconductor memory devices include volatile memory devices, such as dynamic random access memory (“DRAM”) devices or static random access memory (“SRAM”) devices; non-volatile memory devices, such as resistive random access memory (“ReRAM”), electrically erasable programmable read-only memory (“EEPROM”), flash memory (which is considered a subset of EEPROM), ferroelectric random access memory (“FRAM”), and magnetoresistive random access memory (“MRAM”), as well as other semiconductor elements capable of storing information. Each type of memory device can have different configurations. For example, flash memory devices can be configured in a NAND configuration or a NOR configuration.

[0065] Memory devices can be formed from passive and / or active elements in any combination. As a non-limiting example, passive semiconductor memory elements include ReRAM device elements, which in some embodiments include resistivity-switching storage elements such as antifuses, phase-change materials, and optionally manipulation elements such as diodes. As yet another non-limiting example, active semiconductor memory elements include EEPROM and flash memory device elements, which in some embodiments include elements comprising charge storage regions, such as floating gates, conductive nanoparticles, or charge storage dielectric materials.

[0066] Multiple memory elements can be configured such that they are connected in series or that each element is individually accessible. As a non-limiting example, a flash memory device (NAND memory) in a NAND configuration typically comprises memory elements connected in series. A NAND memory array can be configured such that the array consists of multiple memory strings, where a string consists of multiple memory elements sharing a single bit line and accessed as a group. Alternatively, memory elements can be configured such that each element is individually accessible, for example, a NOR memory array. NAND and NOR memory configurations are examples, and memory elements can be configured in other ways.

[0067] Semiconductor memory elements located within and / or above a substrate can be arranged in two or three dimensions, such as two-dimensional memory structures or three-dimensional memory structures.

[0068] In a two-dimensional memory structure, semiconductor memory elements are arranged in a single plane or a single memory device level. Typically, in a two-dimensional memory structure, the memory elements are arranged in a plane that extends substantially parallel to the main surface of the substrate supporting the memory element (e.g., in the xz plane). The substrate may be a wafer on which the memory element layer is formed, or the substrate may be a carrier substrate attached to the memory element after the memory element has been formed. As a non-limiting example, the substrate may include a semiconductor such as silicon.

[0069] Memory elements can be arranged in an ordered array (such as by multiple rows and / or columns) within a single memory device level. However, memory elements can be arranged in an irregular or non-orthogonal configuration. Each memory element may have two or more electrodes or contact lines, such as bit lines and word lines.

[0070] The three-dimensional memory array is arranged such that the memory elements occupy multiple planes or multiple memory device levels, thereby forming a three-dimensional structure (i.e., along the x, y and z directions, where the y direction is generally perpendicular to the main surface of the substrate, and the x and z directions are generally parallel to the main surface of the substrate).

[0071] As a non-limiting example, a three-dimensional memory structure can be vertically arranged as a stack of multiple two-dimensional memory device levels. As another non-limiting example, a three-dimensional memory array can be arranged as multiple vertical columns (e.g., columns extending substantially perpendicular to the main surface of the substrate (i.e., along the y-direction), each column containing multiple memory elements. The columns can be arranged in a two-dimensional configuration (e.g., in the xz plane) to produce a three-dimensional arrangement of memory elements with multiple vertically stacked elements on the memory plane. Other configurations of the three-dimensional memory elements can also constitute a three-dimensional memory array.

[0072] As a non-limiting example, in a three-dimensional NAND memory array, memory elements may be coupled together to form NAND strings within a single horizontal (e.g., xz) memory device level. Alternatively, memory elements may be coupled together to form vertical NAND strings spanning multiple horizontal memory device levels. Other three-dimensional configurations are conceivable, where some NAND strings contain memory elements within a single memory level, while others contain memory elements spanning multiple memory levels. The three-dimensional memory array can also be designed in NOR and ReRAM configurations.

[0073] Typically, in a monolithic three-dimensional memory array, one or more memory device levels are formed over a single substrate. Optionally, the monolithic three-dimensional memory array may also have one or more memory layers located at least partially within the single substrate. As a non-limiting example, the substrate may include a semiconductor such as silicon. In a monolithic three-dimensional array, the layer constituting each memory device level of the array is typically formed on the layer of the lower memory device level of the array. However, layers of adjacent memory device levels in a monolithic three-dimensional memory array may be shared or intermediate layers may be present between memory device levels.

[0074] Furthermore, two-dimensional arrays can be formed individually and then packaged together to form a non-monolithic memory device with multi-layered memory. For example, a non-monolithic stacked memory can be constructed by forming memory stages on individual substrates and then stacking the memory stages on top of each other. The substrate can be thinned or removed from the memory device stages before stacking, but since the memory device stages are initially formed on individual substrates, the resulting memory array is not a monolithic three-dimensional memory array. Additionally, multiple (monolithic or non-monolithic) two-dimensional or three-dimensional memory arrays can be formed on individual chips and then packaged together to form a stacked chip memory device.

[0075] The operation of memory elements and communication with memory elements typically require associated circuitry. As a non-limiting example, a memory device may have circuitry for controlling and driving the memory element to perform functions such as programming and reading. This associated circuitry may be located on the same substrate as the memory element and / or on a separate substrate. For example, a controller for memory read / write operations may be located on a separate controller chip and / or on the same substrate as the memory element.

[0076] Those skilled in the art will recognize that the present invention is not limited to the described two-dimensional and three-dimensional structures, but covers all relevant memory structures as described herein and as understood by those skilled in the art within the spirit and scope of the invention.

[0077] The above detailed description is intended to be understood as an illustration of selected forms of the invention, and not a definition of the invention. Only the following claims (including all equivalents) are intended to define the scope of the claimed invention. Finally, it should be noted that any aspect of any embodiment described herein may be used alone or in combination with each other.

Claims

1. A data storage device, the data storage device comprising: The memory includes single-cell (SLC) memory and multi-cell (MLC) memory; and One or more processors, wherein the one or more processors are configured individually or in combination to: Receive the command to enter accident mode from the vehicle; as well as In response to receiving the command to enter accident mode from the vehicle, the vehicle information stored in the MLC memory is relocated to the SLC memory.

2. The data storage device of claim 1, wherein the one or more processors are further configured individually or in combination to: The vehicle information is prevented from being relocated back to the MLC memory until a command to exit accident mode is received from the vehicle.

3. The data storage device of claim 1, wherein the one or more processors are further configured individually or in combination to: After the vehicle information is relocated to the SLC memory, the vehicle information is write-protected.

4. The data storage device of claim 1, wherein the vehicle information is relocated to the SLC memory using write trimming, the write trimming being more resistant to high temperatures than write trimming used when the data storage device is not in accident mode.

5. The data storage device of claim 1, wherein the vehicle information is identified by a logical block address (LBA) range received from the vehicle.

6. The data storage device of claim 5, wherein the one or more processors are further configured individually or in combination to: Additional vehicle information outside the LBA range is stored in the SLC memory; and The additional vehicle information is prevented from being relocated to the MLC memory until a command to exit accident mode is received from the vehicle.

7. The data storage device of claim 1, wherein the relocation of the vehicle information from the MLC memory to the SLC memory is given higher priority than other operations.

8. The data storage device of claim 1, wherein the one or more processors are further configured individually or in combination to: Receive a command to exit accident mode from the vehicle; and In response to receiving the command to exit accident mode from the vehicle, the vehicle information stored in the SLC memory is folded into the MLC memory.

9. The data storage device of claim 1, wherein the vehicle information includes vehicle speed, vehicle steering angle, vehicle tire pressure, vehicle braking activity, vehicle engine / motor activity, sound recordings captured by a vehicle microphone, images captured by a vehicle camera, videos captured by a vehicle camera, the geographical location of the vehicle, and / or data derived from the geographical location of the vehicle.

10. The data storage device according to claim 1, wherein the memory includes a three-dimensional memory.

11. A method, the method comprising: Perform the following operations in a data storage device including memory, wherein the memory comprises single-cell (SLC) regions and multi-cell (MLC) regions: Receive accident notifications from vehicles; and In response to receiving the accident notification from the vehicle: Free space is created in the SLC area by erasing previously written data in the SLC area; as well as Vehicle information is written into the free space created in the SLC area, wherein the vehicle information is not collapsed into the MLC area until the accident notification is cleared.

12. The method according to claim 11, further comprising: Receive a command to clear the incident notification; as well as In response to receiving the command to clear the accident notification, the vehicle information is collapsed into the MLC area.

13. The method according to claim 11, further comprising write protection of the vehicle information.

14. The method of claim 11, wherein the vehicle information is written to the free space in the SLC area using write trimming, the write trimming being more resistant to high temperatures than write trimming used before the data storage device receives the accident notification from the vehicle.

15. The method of claim 11, wherein the vehicle information is identified by a logical block address (LBA) range received from the vehicle.

16. The method of claim 15, further comprising storing additional vehicle information outside the LBA range in the SLC area, wherein the additional vehicle information is not collapsed into the MLC area until the accident notification is cleared.

17. The method of claim 11, wherein creating free space and writing the vehicle information are given higher priority than other operations.

18. The method of claim 11, wherein the vehicle information includes vehicle speed, vehicle steering angle, vehicle tire pressure, vehicle braking activity, vehicle engine / motor activity, sound recordings captured by a vehicle microphone, images captured by a vehicle camera, videos captured by a vehicle camera, the geographical location of the vehicle, and / or data derived from the geographical location of the vehicle.

19. The method of claim 11, wherein the memory comprises a three-dimensional memory.

20. A data storage device, the data storage device comprising: Single-cell (SLC) memory; Multi-level cell (MLC) memory; and A component for storing vehicle information received from a vehicle in the SLC memory instead of the MLC memory in response to receiving an accident prediction from the vehicle.

Images