Storage device for autonomous vehicle and data storage method thereof

Abstract

A storage device configured to receive write data from at least one processor corresponding to an autonomous vehicle, the storage device including a memory and a storage controller configured to receive the write data and an accident risk tag corresponding to the write data from the at least one processor, the accident risk label corresponds to an accident risk level of the autonomous vehicle, the accident risk label corresponds to at least one of a first accident risk level, a second accident risk level and a third accident risk level, the first accident risk level corresponds to a high accident risk, and the second accident risk level corresponds to a third accident risk level. The second accident risk level corresponds to an accident risk lower than the first accident risk level, and the third accident risk level corresponds to an accident risk lower than the second accident risk level, selecting a storage method for storing the write data on the memory based on the accident risk tag, and storing the write data on the memory based on the selected storage method.

Description

[0001] Cross-references to related applications

[0002] This application is based on and claims priority to Korean Patent Application No. 10-2024-0115939, filed on August 28, 2024, with the Korean Intellectual Property Office, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] Embodiments of this disclosure relate to a semiconductor device, and more specifically, to a storage device for autonomous driving and a method for storing data thereon. Background Technology

[0004] Autonomous vehicles can be defined as vehicles that, without driver intervention, independently identify and control their surroundings and driving environment to reach a given destination. Autonomous vehicles can avoid collisions with obstacles in their path using various sensors installed on them. Furthermore, they can adjust their speed and direction based on road shape to reach their destination autonomously.

[0005] As the research and deployment of autonomous vehicles become more widespread, identifying the causes of accidents and determining responsibility in accidents involving autonomous vehicles is becoming increasingly important. If the cause of an accident is a mistake or problem within the autonomous vehicle, the responsibility lies with the company that manufactured the vehicle. Conversely, if an accident occurs when the driver has control of the autonomous vehicle, the responsibility lies with the driver. Therefore, in cases involving autonomous vehicles, it is crucial to ensure the availability of evidentiary information to determine the cause or responsibility of the accident. To achieve this, the process of storing driving data or various sensor data acquired while driving the autonomous vehicle must first be completed.

[0006] As the level of autonomous driving in vehicles increases, the need to collect additional data (sensor data, driving records) beyond the stored data (i.e., event data recorder (EDR) data) at the time of an accident is growing. The large amount of data collected will be used to analyze the cause of the accident or determine liability. Solid-state drives (SSDs) based on NAND flash memory are being used as one of the storage devices for storing data at the time of an accident. However, SSDs store data in a way that manages user data and corresponding metadata separately for performance reasons. In other words, metadata is only written to the non-volatile memory (NVM) device when certain conditions are met separately from the user data.

[0007] Successful recovery of accident data is only possible if user data and metadata are synchronized. However, performing synchronization of user data and metadata for all data stored in an SSD can be inefficient. Furthermore, as autonomous driving levels increase, the synchronization of sensor data applications becomes increasingly complex, and storing it can lead to a rapid increase in costs. Therefore, a technology is needed that ensures highly reliable evidence in the event of an autonomous vehicle accident while efficiently storing the data.

[0008] The information disclosed in this background section was already known or derived by the inventors before or during the implementation of the embodiments of this application, or it is technical information acquired during the implementation of the embodiments. Therefore, it may contain information that does not form prior art already known to the public. Summary of the Invention

[0009] One or more exemplary embodiments provide a storage device and a data storage method for autonomous driving, which can efficiently store accident records of autonomous vehicles.

[0010] Additional aspects will be set forth in part in the description which follows, and will be apparent in part from the description, or may be learned by practicing the embodiments presented.

[0011] According to one aspect of an example embodiment, a storage device configured to receive write data from at least one processor corresponding to an autonomous vehicle may include a storage controller and a memory configured to receive write data and an accident risk label corresponding to the write data from at least one processor. The accident risk label corresponds to an accident risk level of the autonomous vehicle, wherein the accident risk label corresponds to at least one of a first accident risk level, a second accident risk level, and a third accident risk level. The first accident risk level corresponds to a high accident risk, the second accident risk level corresponds to an accident risk lower than the first accident risk level, and the third accident risk level corresponds to an accident risk lower than the second accident risk level. A storage method for storing the write data on the memory is selected based on the accident risk label, and the write data is stored on the memory based on the selected storage method.

[0012] According to one aspect of an example embodiment, a method of a storage device may include receiving incident data including risk tags and a write command from a host, determining an incident risk level based on the risk tags, wherein the incident risk tags correspond to at least one of a first incident risk level, a second incident risk level, and a third incident risk level, the first incident risk level corresponding to a high incident risk, the second incident risk level corresponding to an incident risk lower than the first incident risk level, the third incident risk level corresponding to an incident risk lower than the second incident risk level, selecting a storage method for storing the incident data on a memory based on the incident risk level, and storing the incident data on a memory based on the selected storage method.

[0013] According to one aspect of an example embodiment, a storage device configured to store incident data may include a first memory, a buffer memory, a storage controller, a storage manager, and a namespace table. The buffer memory stores incident data and metadata of the incident data. The storage controller is configured to receive incident data and incident risk tags corresponding to the incident data. The storage controller may include a tag analyzer configured to extract the incident risk level corresponding to the incident risk tag. The storage manager is configured to select a storage method for storing the incident data on the first memory based on the extracted incident risk level. The namespace table is configured with the namespace address of the first memory where the incident data is stored. The incident risk tag corresponds to at least one of a first incident risk level, a second incident risk level, and a third incident risk level. The first incident risk level corresponds to a high incident risk, the second incident risk level corresponds to an incident risk lower than the first incident risk level, and the third incident risk level corresponds to an incident risk lower than the second incident risk level. Attached Figure Description

[0014] The above and other aspects, features, and advantages of certain exemplary embodiments of the present disclosure will become more apparent from the following description taken in conjunction with the accompanying drawings, wherein:

[0015] Figure 1 This is a diagram illustrating an autonomous vehicle equipped with a storage device according to one or more embodiments;

[0016] Figure 2 This illustrates one or more embodiments. Figure 1 A block diagram of a storage device;

[0017] Figure 3 This illustrates one or more embodiments. Figure 2 A block diagram of the configuration of the storage controller;

[0018] Figure 4 This illustrates one or more embodiments. Figure 2A block diagram of the structure of the non-volatile memory device shown;

[0019] Figure 5 This is a diagram illustrating a method for generating a risk label in a host according to one or more embodiments;

[0020] Figure 6 This is a table illustrating examples of methods for sending generated risk tags to a storage device according to one or more embodiments;

[0021] Figure 7 This illustrates one or more embodiments. Figure 6 The table configuring the operation code field;

[0022] Figure 8 This is a table illustrating examples of methods for sending risk tags from a host to a storage device according to one or more embodiments;

[0023] Figure 9 This is a flowchart illustrating a method for generating write commands executed in a host according to one or more embodiments;

[0024] Figure 10 This is a flowchart illustrating a method for storing data in a storage device based on a risk label, according to one or more embodiments;

[0025] Figure 11 This is a flowchart illustrating operation S250 according to one or more embodiments;

[0026] Figure 12 This is a diagram illustrating an example of write scheduling for low-risk write data according to one or more embodiments;

[0027] Figure 13 This is a diagram illustrating an example of write scheduling for low-risk write data according to one or more embodiments;

[0028] Figure 14 This is a flowchart illustrating operation S260 according to one or more embodiments;

[0029] Figure 15 This is a diagram illustrating a method for adding risk data journals to a meta-cell when the number of journals exceeds a threshold, according to one or more embodiments.

[0030] Figure 16 This is a flowchart illustrating operation S270 according to one or more embodiments;

[0031] Figure 17This is a diagram illustrating an example of a method for configuring on-demand logs performed in operation S274 according to one or more embodiments;

[0032] Figure 18 This is a flowchart illustrating an example of a data storage method based on a risk label in a storage device according to one or more embodiments;

[0033] Figure 19 This is a block diagram illustrating a storage device according to one or more embodiments; and

[0034] Figure 20 This is a block diagram illustrating a storage device according to one or more embodiments. Detailed Implementation

[0035] In the following, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. The same reference numerals are used for the same components in the drawings, and redundant descriptions thereof will be omitted. The embodiments described herein are exemplary embodiments, and therefore, the present disclosure is not limited thereto and may be implemented in various other forms.

[0036] As used herein, expressions such as "at least one of..." modify the entire list of elements when preceding it, without modifying any individual element in the list. For example, the expression "at least one of a, b, and c" should be understood to include only a, only b, only c, both a and b, both a and c, both b and c, or all of a, b, and c.

[0037] Figure 1 This is a diagram illustrating an autonomous vehicle equipped with a storage device according to one or more embodiments. Reference Figure 1 The autonomous vehicle 10 may include multiple processors (100, 200, 300, 400, 500, 600, 700 and 800) and storage devices, with each processor connected to multiple sensors and actuators.

[0038] The autonomous vehicle 10 can detect roads, surrounding environment, obstacles, etc., using multiple sensors. The autonomous vehicle 10 can use multiple sensors to sense motion information detected during operation, such as speed, acceleration, altitude, and rotation rate. These multiple sensors may include object detection devices, internal cameras, and state detection sensors. The object detection devices can detect external objects of the autonomous vehicle 10 and generate sensor data including information about the external objects. For example, the object detection devices may include vision sensors, such as cameras, radar, lidar (Light Detection and Ranging) sensors, etc. The internal cameras can detect the driver or passengers and generate sensor data including information about the driver or passengers. The state detection sensors can sense the state of the autonomous vehicle 10 and generate sensor data including state information of the autonomous vehicle 10. For example, the state detection sensors may include at least one of the following: inertial navigation system (INS) sensors, collision sensors, wheel sensors, speed sensors, tilt sensors, weight detection sensors, heading sensors, position modules, vehicle forward / backward sensors, battery sensors, fuel sensors, tire sensors, steering sensors, vehicle interior temperature sensors, vehicle interior humidity sensors, ultrasonic sensors, illuminance sensors, accelerator pedal position sensors, and brake pedal position sensors. As shown in the figure, sensor data detected by the sensors is provided to the processor (Super core and ZCU1 to ZCU7). Furthermore, the device can be operated based on the sensing results using multiple actuators.

[0039] Processors 100 to 800 can control the overall operation of the electronic devices provided in the autonomous vehicle 10. Processors 100 to 800 can process sensor data from multiple sensors and drive actuators or generate event data based on the processing results. For example, processors 100 to 800 can collect sensor data from camera sensors or LIDAR sensors to provide advanced driver assistance systems (ADAS) or automated driving systems (ADS) functions, such as forward collision warning or forward collision prevention. Alternatively, processors 100 to 800 can provide lane keeping assist system (LKAS) functions, which assist the autonomous vehicle 10 in staying within its lane while driving using sensor data.

[0040] Specifically, processors 100 to 800 may include zone control units (ZCUs) that control the various zones used to control the autonomous vehicle 10. As the centralization and electrification of semiconductors used in the autonomous vehicle 10 accelerates, an architecture can be implemented to control the autonomous vehicle 10 by dividing them into zones. For example, the control area of ​​the autonomous vehicle 10 can be divided into front (F), left front (FL), right front (FR), left center (ML), right center (MR), left rear (RL), and right rear (RR). ZCUs 200 to 800 can be responsible for sensing and control of each zone. A supercore 100 can be provided to manage these ZCUs 200 to 800.

[0041] Processors 100 to 800 can acquire data from sensors. Specifically, at least one of processors 100 to 800 can process the sensed data to determine accident risk. For example, at least one of processors 100 to 800 performing ADAS functions can use sensor data to determine the expected time of collision (TTC). Accident risk can be determined based on derived TTC, forward collision warning system (FCWS), rear-end collision, lane-changing vehicle (cutting in), lateral drift, etc. The risk of the accident can be generated as, for example, including at least three risk levels: low, medium, and high. When an accident risk is identified, at least one of processors 100 to 800 can provide a command, flag, or control signal including the risk of the accident information to a storage device. Hereinafter, the risk of the accident information is referred to as a risk tag R-tag.

[0042] Storage device 1000 can receive and store event data and sensor data provided by processors 100 to 800. According to one or more embodiments, storage device 1000 can process data requested for writing based on a risk tag (R-tag). For example, storage device 1000 can apply different storage methods to the data requested for writing based on the risk tag. In the case of write data accompanied by tags with high incident risk, storage device 1000 can configure user data and metadata as a single log and store them at high speed in separately designated storage areas. User data and metadata configured as a single log or write unit are hereinafter referred to as On-Demand Logs (ODLs). In the case of write data accompanied by tags with low incident risk, storage device 1000 can efficiently manage the data by assigning an internal stream ID to the incident data and storing it in a superblock, or process it in a write buffer queue by high-priority scheduling. Additionally, in the case of write data accompanied by tags with incident risk, storage device 1000 can also maintain synchronization between user data and metadata and flush the write data to a non-volatile memory device. Alternatively, storage device 1000 handles write data with tags associated with accident risk using forced unit access (FUA). However, the input / output functions in the namespace of the write data must be maintained. The method for handling write data based on the risk tag R-tag of storage device 1000 will be described in more detail below.

[0043] In an autonomous vehicle 10 equipped with a storage device 1000 according to one or more embodiments, a large amount of accident data is processed according to different storage methods based on accident risk. Therefore, the storage efficiency and data reliability of the accident data stored in the storage device 1000 can be improved.

[0044] Figure 2 This illustrates one or more embodiments. Figure 1 A block diagram of the storage device. (See reference) Figure 2 The storage device 1000 can receive write requests, including a risk tag R-tag, from multiple processors 100 to 800 corresponding to the host. Here, write requests unrelated to risk may not include the risk tag R-tag.

[0045] Each of the multiple processors 100 to 800 can perform an accident risk prediction operation based on sensor data. Then, at least one of the multiple processors 100 to 800 can determine the accident risk as a result of the accident risk prediction operation. A risk tag R-tag can then be generated based on the determined accident risk. The risk tag R-tag can be included in the event data write command and sent to the storage device 1000. That is, the first risk tag R-tag_1 generated by the accident risk prediction operation of the super core 100 can be included in the corresponding user data write command and sent to the storage device 1000. On the other hand, in the case of general write data unrelated to accident risk, a write request can be made by a write command without a risk tag R-tag. Risk tags R-tag_2 to R-tag_n generated as a result of the accident risk prediction operation of each of the ZCUs 200 to 800 can also be sent to the storage device 1000 in the same manner as the super core 100.

[0046] Storage device 1000 may include storage controller 1100 and non-volatile memory device 1200. Figure 2 The storage controller 1100 may include a risk data manager 1110 and a flash interface 1160. The non-volatile memory device 1200 can store data and metadata requested to be written by the host. Furthermore, the buffer memory 1300 can store and manage the physical address information of the non-volatile memory device 1200 for ODL by configuring a lookup table.

[0047] Storage controller 1100 can store various data provided by processors 100 to 800 in non-volatile memory device 1200. Non-volatile memory device 1200 configured with flash memory typically has the characteristic that it is impossible or not allowed to be rewritten and that more data than requested is written to the memory cells. This characteristic is called write amplification factor (WAF). To minimize WAF and write performance degradation, storage controller 1100 may have the write characteristic of storing user data and corresponding metadata for write requests at different times. However, this method of managing write data becomes a factor that makes it difficult to recover accidental data in the event of an accident. That is, only by ensuring that user data and metadata are synchronized can the data saved in the event of an accident be successfully recovered.

[0048] According to one or more embodiments, the risk data manager 1110 of the storage controller 1100 can process data requested for writing from the host differently based on the risk tag R-tag. That is, the risk data manager 1110 can apply different storage methods to the requested data for writing based on the risk tag R-tag. The flash memory interface 1160 can store the write data for each risk configured in the risk data manager 1110 in the non-volatile memory device 1200.

[0049] For example, when a write request for data with a risk tag R-tag of "high" is received from the supercore 100, the risk data manager 1110 can configure user data and metadata into an ODL. The risk data manager 1110 can configure an ODL with a page size, which is a write unit of the non-volatile memory device 1200. A separate namespace can be allocated for the ODL. Furthermore, the risk data manager 1110 can program the configured ODL into a separate namespace area provided in the non-volatile memory device 1200. The area storing the ODL can be managed in the form of a lookup table, allowing it to be specified by the risk data manager 1110 without a separate address mapping operation. Additionally, the risk data manager 1110 can encrypt the ODL using a key or add a checksum or cyclic redundancy check (CRC) to ensure the security or fault tolerance of the ODL. Even if an error occurs during an ODL read operation, the risk data manager 1110 can exclude read failures. This is because, due to environmental factors or shocks during the storage of accidental data, the write operation may not be fully executed.

[0050] If a write request for data with a risk tag R-tag of "low" is received from ZCU 200, the risk data manager 1110 can store the requested data for writing by applying an internal stream identifier. Alternatively, the risk data manager 1110 can schedule the queue priority of the requested data for writing to "high" in the write buffer.

[0051] On the other hand, if a write request for data with a risk tag R-tag of "medium" is received from ZCU 300, the Risk Data Manager 1110 can maintain synchronization between user data and metadata and quickly flush the write data to the non-volatile memory device 1200 when the risk increases. To this end, the Risk Data Manager 1110 can select a meta-cell (log data and metadata) configured in the write buffer whose log data quantity is greater than or equal to a threshold TH. A log of the requested write data can be created and inserted into the selected meta-cell to configure the meta-cell, and the configured meta-cell can be flushed to the non-volatile memory device 1200. If no meta-cell has a log data quantity greater than or equal to the threshold TH, the log of the requested write data can be inserted by selecting the meta-cell with the largest amount of log data. In this case, it is possible to flush the incident data when the input / output of the namespace using the write data is not blocked and is activated.

[0052] The functionality of the storage device 1000 according to one or more embodiments has been described above. The risk data manager 1110 according to one or more embodiments can process data requested for writing from the host differently based on the risk tag R-tag. That is, the risk data manager 1110 can apply different storage methods to the requested data based on the risk tag R-tag. Therefore, the storage efficiency and data reliability of incident data stored in the storage device 1000 can be improved.

[0053] Figure 3 This illustrates one or more embodiments. Figure 2 A block diagram illustrating the configuration of the storage controller. (See reference) Figure 3 The storage controller 1100 may include a risk data manager 1110, a host interface 1120, a processing unit 1130, a working memory 1140, a buffer manager 1150, and a flash interface 1160.

[0054] Risk Data Manager 1110 can extract risk tags R-tags included in commands from the host and determine the storage method for data requested to be written to non-volatile memory device 1200 based on the extracted risk tags R-tags. Risk Data Manager 1110 may include a tag analyzer 1111, a storage manager 1113, an ODL generator 1115, an ODL migrater 1117, and an ODL namespace table 1119 for processing the written data according to the risk tags R-tags.

[0055] Tag analyzer 1111 can extract and analyze risk tags R-tags included in commands provided from multiple processors 100 to 800 of the host. For example, the multiple processors 100 to 800 can add the risk tag R-tag to the operation code (hereinafter, interchangeably referred to as Opcode) of the command format used to send a write request and provide it to the storage device 1000. Alternatively, the multiple processors 100 to 800 can send the risk tag R-tag to the storage device 1000 using a specific field of the direct command. The method of sending the risk tag R-tag is not limited to the example above and can be sent through various control signals or flags. If the tag included in the write request corresponds to the risk tag R-tag, the tag analyzer 1111 can send the extracted risk tag to the storage manager 1113.

[0056] Storage manager 1113 can select a data storage method that varies depending on the risk level of the data requested to be written via a risk tag (R-tag). For this purpose, storage manager 1113 may include a low-risk controller (LDC), a medium-risk controller (MDC), and a high-risk controller (HDC).

[0057] The Low-Risk Controller (LDC) can be activated when the requested data to be written has a low risk level. For low-risk write data, the write priority to the non-volatile memory device 1200 can be scheduled higher than the write priority of other previously written general data (excluding data with risk tags). The LDC can manage the metadata of low-risk write data by writing metadata cells to the non-volatile memory device 1200 when the metadata cell's log buffer is full. In other words, the metadata of low-risk write data can be managed in the same way as the metadata of general write data. However, to schedule the priority of low-risk write data, the LDC can impose an internal stream identifier on the write data. The LDC can reschedule the priority of write data to urgent tasks or adjust it to a higher priority than other urgent tasks. However, since all urgent tasks should not be pushed down in priority, the LDC can manage low-risk write data and urgent tasks by adjusting the ratio between low-risk write data and urgent tasks.

[0058] The Medium Risk Controller (MDC) can be activated when the risk level of the requested data to be written is medium. In the case of medium-risk data writes, the MDC can perform management operations to maintain synchronization between user data and metadata, and quickly flush the written data to the non-volatile memory device 1200. The MDC can select the amount or number of log data (log data and metadata) configured in the write buffer that exceeds the threshold TH. Logs of the written data can be inserted into the selected meta-units to configure them, and the configured meta-units can be flushed to the non-volatile memory device 1200. If no meta-unit has a log data amount or quantity exceeding the threshold TH, the logs of the requested data to be written can be inserted by selecting the meta-unit with the maximum amount of log data. In this case, flushing the incident data is possible if the input / output of the namespace using the written data is not blocked and is activated.

[0059] The High-Risk Controller (HDC) can be activated when the requested data to be written is of a high risk level. High-risk write data can be written to the non-volatile memory device 1200 with the highest priority. Furthermore, if user data and metadata are managed separately, such as for low-risk or medium-risk data, consistency may not be guaranteed during recovery. Therefore, the metadata and user data of high-risk write data can be configured as a single write unit to maintain consistency. In the following text, this single write unit will be referred to as the ODL.

[0060] The High Risk Controller (HDC) can request the ODL generator 1115 to configure an ODL for high-risk write data. The ODL can be configured as a page unit, which is a write unit for high-speed writing to the non-volatile memory device 1200. That is, the ODL generator 1115 can configure the user data and metadata of the high-risk write data as a single-page or multi-page ODL. The data format and configuration of the ODL will be described in more detail with reference to the accompanying drawings described below.

[0061] The physical address information of the ODL generated by the ODL generator 1115 can be stored in the ODL namespace table 1119. The ODL written in the ODL namespace table 1119 can be allocated to the memory region of the non-volatile memory device 1200 specified in the corresponding namespace without a separate address mapping process. The physical address information written in the ODL namespace table 1119 may include, for example, the channel, way, block, and page address of the allocated namespace.

[0062] When the absence of the risk tag R-tag in the write command persists for a specific period of time, the ODL migrater 1117 can migrate the ODL stored in the ODL namespace area to the meta area and the user area.

[0063] The host interface 1120 can provide an interface between the host and the storage controller 1100 corresponding to multiple processors 100 to 800. The host and the storage controller 1100 can be connected via one of a variety of standardized interfaces. Here, standardized interfaces include various interface methods such as Advanced Technology Attachment (ATA), Serial ATA (SATA), External SATA (e-SATA), Small Computer Small Interface (SCSI), Serial Attached SCSI (SAS), Peripheral Component Interconnect (PCI), PCI Express (PCIe), Universal Serial Bus (USB), IEEE 1394, Universal Flash Memory (UFS), Embedded Multimedia Card (eMMC), NVMe, NVMe-of, NVMe-MI, etc.

[0064] Processing unit 1130 may include a central processing unit or a microprocessor. Processing unit 1130 may drive software or firmware for driving storage controller 1100. Specifically, processing unit 1130 may drive software modules loaded into working memory 1140. Furthermore, processing unit 1130 may perform core functions of storage device 1000, such as flash translation layer (FTL). Additionally, processing unit 1130 may be provided in a multi-core form consisting of multiple central processing units (CPUs). In one or more embodiments, risk data manager 1110 may be loaded into working memory 1140 in the form of firmware or software. Processing unit 1130 executes risk data manager 1110 loaded into working memory 1140, thereby implementing the variable data storage according to risk level of the present invention.

[0065] Software modules or data used to control the storage controller 1100 can be loaded into the working memory 1140. The software and data loaded into the working memory 1140 can be driven or processed by the processing unit 1130. The working memory 1140 can be implemented, for example, as static random access memory (RAM) (SRAM).

[0066] Buffer manager 1150 can provide buffering functionality for reading or writing data that moves between host interface 1120 and flash interface 1160. Buffer manager 1150 can control a buffer memory (1300, see [link]) implemented as mass dynamic RAM (DRAM). Figure 2This provides direct memory access (DMA) or buffering functionality between the non-volatile memory device 1200 and the host. The ODL namespace table 1119 can be configured, stored, and updated in the buffer memory 1300.

[0067] The flash memory interface 1160 can provide an interface between the storage controller 1100 and the non-volatile memory device 1200. For example, data processed by the processing unit 1130 can be stored in the non-volatile memory device 1200 via the flash memory interface 1160. As another example, data stored in the non-volatile memory device 1200 can be exchanged with the storage controller 1100 via the flash memory interface 1160.

[0068] An exemplary configuration of the storage controller 1100 has been described above. However, it will be well understood that the components of the storage controller 1100 are not limited to those mentioned above. For example, the storage controller 1100 may also include a read-only memory (ROM) that stores code data or error-correcting code blocks required for booting operations.

[0069] According to one or more embodiments, data written from a host based on a request from the risk data manager 1110 can be programmed in the non-volatile memory device 1200 according to a risk tag R-tag and different storage methods. Therefore, the storage efficiency and data reliability of incident data stored in the storage device 1000 can be improved.

[0070] Figure 4 This illustrates one or more embodiments. Figure 2 A block diagram illustrating the structure of a non-volatile memory device. (Reference) Figure 4 The diagram illustrates the structure of a non-volatile memory device 1200 implemented as a flash memory device. The non-volatile memory device 1200 may include a cell array 1210, a row decoder 1220, a page buffer circuit 1230, control logic circuitry 1240, and a voltage generator 1250. The non-volatile memory device 1200 may also include data input / output circuitry or an input / output interface. Furthermore, the non-volatile memory device 1200 may also include elements such as column logic, a pre-decoder, a temperature sensor, a command decoder, and an address decoder.

[0071] Cell array 1210 may include multiple memory blocks. Each of the multiple memory blocks may include multiple memory cells. The multiple memory blocks may be located in a single memory plane, but embodiments are not limited thereto. Cell array 1210 may be connected to page buffer circuitry 1230 via bit line BL and to line decoder 1220 via word line WL, serial select line SSL, and ground select line GSL. In one or more embodiments, cell array 1210 may include a three-dimensional memory cell array.

[0072] Cell array 1210 may include a metadata area 1211 for storing metadata and log data, and a user area 1213 for storing user data. This is controlled by the risk data manager (1110, see...). Figure 3 User data requested for writing can be stored in user area 1213. On the other hand, metadata managed in units of meta-cells can be programmed in meta-area 1211 in units of stripes. Specifically, cell array 1210 may include ODL namespace area 1215, in which ODL generated from high-risk write data is stored. If idle time or the absence of a risk tag R-tag persists for a certain period, the ODL stored in ODL namespace area 1215 can be migrated. That is, the ODL stored in ODL namespace area 1215 can be migrated to meta-area 1211 and user area 1213.

[0073] The row decoder 1220 can select any one of the memory blocks in the cell array 1210 in response to the address ADDR. The row decoder 1220 can select any one of the word lines of the selected memory block in response to the address ADDR. The row decoder 1220 can transmit a voltage VWL corresponding to the operating mode to the word line of the selected memory block. During a programming operation, the row decoder 1220 can transmit both the programming voltage and the verification voltage to the selected word line, and transmit a pass voltage to the unselected word line. During a read operation, the row decoder 1220 can transmit a read voltage to the selected word line, and transmit a read pass voltage to the unselected word line.

[0074] Page buffer circuit 1230 may include multiple page buffers PB0 to PBn-1. The multiple page buffers PB0 to PBn-1 can be connected to memory cells via multiple bit lines BL. Page buffer circuit 1230 can select at least one bit line among the bit lines BL in response to a column address. Page buffer circuit 1230 can operate as a write driver or a sense amplifier depending on the operating mode. For example, during a programming operation, page buffer circuit 1230 can apply a bit line voltage corresponding to the data to be programmed to the selected bit line. During a read operation, page buffer circuit 1230 can detect the data stored in the memory cell by detecting the current or voltage of the selected bit line.

[0075] Control logic circuit 1240 can control various operations in non-volatile memory device 1200. Control logic circuit 1240 can output various control signals for programming data in cell array 1210, reading data from cell array 1210, or erasing data stored in cell array 1210 in response to control signals CTRL, commands CMD, and / or addresses ADDR. For example, control logic circuit 1240 can output voltage control signal VTG_C, address ADDR, etc. In one or more embodiments, control logic circuit 1240 can output control signals for programming multi-bit data based on received control signals CTRL, commands CMD, and / or addresses ADDR.

[0076] The voltage generator 1250 can generate various types of voltages for performing programming, reading, and erasing operations based on the voltage control signal VTG_C. For example, the voltage generator 1250 can generate programming voltages, reading voltages, programming verification voltages, etc., as word line voltages VWL. For example, the programming voltage can be generated in incremental step pulse programming (ISPP) mode.

[0077] Figure 5 This is a diagram illustrating a method for generating a risk label in a host according to one or more embodiments. Reference Figure 5 At least one of the multiple processors 100 to 800 can determine the time to collision (TTC) and generate a risk label R-tag based on the result.

[0078] At least one of the multiple processors 100 to processor 800 can detect the relative distance D and relative speed (V1-V2) between the autonomous vehicle 10 and the vehicle 20 in front. The detected relative distance D and relative speed (V1-V2) can then be used to determine the TTC based on equation (1).

[0079] (1)

[0080] exist Figure 5 The graphs shown confirm that the deceleration of the autonomous vehicle 10 increases as the TTC (Time To Control) shortens. For example, when the TTC is between 2.5 seconds and 1.5 seconds, partial braking of the autonomous vehicle 10 begins. And when the TTC is less than 0.9 seconds, the autonomous vehicle 10 can perform full braking for deceleration.

[0081] The risk tag R-tag can be determined based on the TTC. For example, when the TTC is longer than 2.5 seconds, the host does not generate a risk tag R-tag. In this case, the host can issue a write command stating that the risk tag R-tag should not be inserted. When the TTC is between 2.5 seconds and 1.5 seconds, the host can generate a risk tag R-tag as "low". The host can add the risk tag R-tag corresponding to "low" to the write command and send it to storage device 1000.

[0082] If the TTC is between 1.5 seconds and 0.9 seconds, the host can generate a risk tag R-tag as "Medium". The host can then add the risk tag R-tag corresponding to "Medium" to the write command and send it to storage device 1000. If the TTC is less than 0.9 seconds, the host can generate a risk tag R-tag as "High". The host can then add the risk tag R-tag corresponding to "High" to the write command and send it to storage device 1000.

[0083] The above provides a brief explanation of the method for generating risk tags (R-tags) based on TTC. However, in general, risk tags (R-tags) may not depend solely on TTC. To generate risk tags (R-tags), the host computer can combine various sensor data, such as anticipated TTC, FCW, LKAS, rear-side collision, forward lane-changing vehicle (cut-in) detection, and side offset.

[0084] Figure 6 This is a table illustrating examples of methods for sending generated risk tags to a storage device according to one or more embodiments. References Figure 6 The example shows the common command format used in the NVMe interface. In the common command format, the risk tag R-tag can be inserted into the operation code Opcode field.

[0085] A host corresponding to at least one of the processors 100 to 800 can generate a command format for sending a write request after generating a risk tag R-tag. The host can insert the risk tag R-tag into the Opcode field, which is assigned to the command format as a "Dword 0". The remaining fields of the command format used to send the risk tag R-tag can be the same as the common command format. Therefore, the namespace identifier NSID, metadata pointer MPTR, data pointer DPTR, etc., can be configured in the same way as the general write command.

[0086] Figure 7 This illustrates one or more embodiments. Figure 6 The table contains the configuration fields for the operation codes. (See reference.) Figure 7 According to one or more embodiments, the risk label R-tag can be inserted into the opcode field configured in the first byte 'Byte 0' of 'Dword 0'.

[0087] The first two bits [1:0] of the opcode configured in a one-byte unit indicate the direction of data transfer. For example, if the data transfer direction [1:0] is "00b", it indicates that no data is being transferred. If the data transfer direction [1:0] is '01b', it indicates that data is being transferred from the host to the storage controller. If the data transfer direction [1:0] is '10b', it indicates that data is being transferred from the storage controller to the host. The five bits [6:2] of the opcode indicate the function. The last bit [7] of the opcode indicates the command type. That is, the last bit [7] of the opcode indicates whether it is the standard command "0b" or the vendor-specific command "01b".

[0088] The risk tag R-tag, according to one or more embodiments, can be sent using reserved or unused fields of the operation code Opcode. For example, in the case of operation code Opcode '00100001b' (corresponding to '21h'), it can indicate a low-risk data write request. In the case of operation code Opcode '01000001b' (corresponding to '41h'), it can indicate a medium-risk data write request. And in the case of operation code Opcode '01100001b' (corresponding to '61h'), it can indicate a high-risk data write request.

[0089] An exemplary method for assigning a risk tag (R-tag) to a reserved field of an operation code (Opcode) is described. However, it will be well understood that the bit values ​​of these specific operation codes (Opcodes) are merely examples, and various changes or adjustments are possible.

[0090] Figure 8 This is a table illustrating examples of methods for sending risk tags from a host to a storage device according to one or more embodiments. Figure 8 The direct send command used in the NVMe interface is shown as an example. In the direct send command, the risk tag R-tag can be inserted into the direct send type "DTYPE" field defined in bit [15:08].

[0091] The host can use the bit values ​​of the Direct Transfer Type "DTYPE" field to define a risk tag (R-tag). For example, a bit value of "0x11" in the Direct Transfer Type "DTYPE" field can indicate a low-risk data write request. A bit value of "0x12" in the Direct Transfer Type "DTYPE" field can indicate a medium-risk data write request. And a bit value of "0x13" in the Direct Transfer Type "DTYPE" field can indicate a high-risk data write request. The remaining bits of the Direct Transfer Type "DTYPE" field (e.g., 0x33) can be reserved for defining more detailed risks.

[0092] Figure 9 This is a flowchart illustrating a method for generating write commands executed in a host according to one or more embodiments. (Reference) Figure 9 At least one of the multiple processors 100 to 800 can perform an accident risk prediction operation based on sensor data. The host can then send a risk tag R-tag generated based on the result of the accident risk prediction operation to the storage device 1000.

[0093] In operation S110, the host can check whether the storage device 1000 supports the risk tag R-tag. If the storage device 1000 does not support the risk tag R-tag, the adjustment of the data storage method according to the risk tag R-tag may not be applied.

[0094] In operation S120, an operation branch can occur depending on whether the risk label R-tag is supported. If the storage device 1000 supports the risk label R-tag ("yes" direction), the process can proceed to operation S130. On the other hand, if the storage device 1000 does not support the risk label R-tag ("no" direction), the process can proceed to operation S140.

[0095] In operation S130, the host can insert a risk tag R-tag generated based on the result of the accident risk prediction operation into the write command, or it can send it to the storage device 1000 using a direct transmission method. Then, the storage device 1000 can change the storage method of the data requested to be written to the non-volatile memory device 1200 according to the value of the risk tag R-tag.

[0096] In operation S140, the host can send a write command to the storage device 1000 without inserting a risk tag R-tag. In this case, the storage device 1000 can separate metadata from user data and store them in the non-volatile memory device 1200, regardless of the risk tag R-tag.

[0097] In other words, according to one or more embodiments, the host may determine whether to insert the risk tag R-tag into the command depending on whether the storage device 1000 supports the risk tag R-tag.

[0098] Figure 10 This is a flowchart illustrating a method for storing data in a storage device based on a risk label, according to one or more embodiments. (Reference) Figure 10 Risk data manager of storage device 1000 (1110, see storage device 1000) Figure 3 It can analyze risk tags R-tags and select a storage method for data requested to be written into the non-volatile memory device 1200 based on the analysis results.

[0099] In operation S210, the risk data manager 1110 can receive write commands sent from the host or commands sent via direct transmission.

[0100] In operation S220, the Risk Data Manager 1110 can extract the risk tag R-tag included in the received command. The Risk Data Manager 1110 can analyze the extracted risk tag R-tag to determine the risk of the requested data to be written.

[0101] In operation S230, the risk data manager 1110 can execute an operation branch based on the value of the risk tag R-tag. If the write command does not include the risk tag R-tag ("No" direction), the process can move to operation S240. On the other hand, if the write command includes the risk tag R-tag (one of "L", "M" and "H"), the process can move to one of operations S250, S260 and S270 based on the value of the risk tag R-tag.

[0102] In operation S240, the risk data manager 1110 can store the data to be written in the non-volatile memory device 1200 according to a normal write operation. That is, the risk data manager 1110 can treat the data to be written as data unrelated to risk, and can separate metadata and user data and store them in the non-volatile memory device 1200 without adjusting the write priority or write scheduling.

[0103] In operation S250, the Risk Data Manager 1110 can perform "low-risk operations" for storing low-risk data. The Risk Data Manager 1110 can schedule the write priority of low-risk data to be higher than that of previously requested general data (excluding data with risk labels). The Risk Data Manager 1110 can manage the metadata of low-risk data in the same way as general data writes. The Risk Data Manager 1110 can assign internal stream IDs for scheduling low-risk data writes. The Risk Data Manager 1110 can reschedule the write data to an urgent task or adjust its priority to a higher priority than other urgent tasks.

[0104] In operation S260, the Risk Data Manager 1110 can perform a "medium-risk operation" for storing medium-risk data. The Risk Data Manager 1110 can maintain synchronization between the metadata and user data of the medium-risk written data. Furthermore, the Risk Data Manager 1110 can perform management operations to quickly flush the written data to the non-volatile memory device 1200. The Risk Data Manager 1110 can select a meta-cell (log data and metadata) configured in the write buffer whose log data size is greater than or equal to a threshold TH. The log of the written data can be inserted into the selected meta-cell to complete the meta-cell configuration, and the configured meta-cell can be flushed to the non-volatile memory device 1200. If no meta-cell exists with a log data size greater than or equal to the threshold TH, the log of the requested data can be inserted by selecting the meta-cell with the largest amount of log data. In this case, by using the namespace of the written data, it is possible to flush the incident data in an active state without blocking input / output. In such an active input / output state, the incident data flushing operation can be referred to as a "pseudo-FUA / flush".

[0105] In operation S270, the Risk Data Manager 1110 can perform "high-risk operations" for storing high-risk data. The Risk Data Manager 1110 can configure a single write unit (i.e., ODL) to maintain consistency between the metadata of the high-risk write data and user data. The ODL can be configured as a page unit for high-speed writing to the non-volatile memory device 1200. Furthermore, the Risk Data Manager 1110 can store the physical address information of the generated ODL to be stored in a namespace table (1119, see...). Figure 3 The ODL written in the ODL namespace table 1119 can be assigned to the memory region of the non-volatile memory device 1200 specified in the corresponding namespace without a separate address mapping process.

[0106] According to one or more embodiments, the risk data manager 1110 can process data requested for writing from the host differently based on the risk tag R-tag. That is, the risk data manager 1110 can apply different storage methods to the requested data based on the risk tag R-tag. Therefore, the storage efficiency and data reliability of incident data stored in the storage device 1000 can be improved.

[0107] Figure 11 This is a flowchart illustrating operation S250 according to one or more embodiments. (Reference) Figure 11 Risk Data Manager (1110, see below) Figure 3 It can perform low-risk operations for storing low-risk data.

[0108] In operation S251, the risk data manager 1110 can generate internal stream IDs for low-risk write data. If an internal stream ID is assigned to low-risk write data, it can be managed on a stream-by-stream basis.

[0109] In operation S253, the Risk Data Manager 1110 can perform queue scheduling for the write stream. That is, the Risk Data Manager 1110 can set the write priority of the write stream higher than that of general data already existing in the queue (excluding data with risk tags). The Risk Data Manager 1110 can manage the metadata of low-risk write data in the same way as general write data. The Risk Data Manager 1110 can reschedule the priority of write data to urgent tasks or adjust its priority to a higher priority than other urgent tasks.

[0110] In operation S255, the risk data manager 1110 can store the write stream in the non-volatile memory device 1200 according to the adjusted priority. The risk data manager 1110 can manage the metadata and user data of low-risk write data in the same way as general data. However, depending on the adjusted priority, the programming order of low-risk write data to the non-volatile memory device 1200 can be faster than the programming order of general data or urgent data.

[0111] Figure 12 This is a diagram illustrating an example of write scheduling for low-risk data writing according to one or more embodiments. (Reference) Figure 12 The commit queue of the host used for low-risk write data can be adjusted by rescheduling performed in storage device 1000.

[0112] Requests from the host to write low-risk data can be issued as commands that include a risk tag (R-tag). Two commit queues from the host, SQ1 and SQ2, can each load a write command that includes both risk tags (R-tag).

[0113] Storage device 1000 can read two low-risk R-tag commands loaded in two commit queues SQ1 and SQ2 from the host. Storage device 1000 can then assign an internal flow ID to each of the low-risk R-tag commands. Using the internal flow ID, storage controller 1100 can perform rescheduling of the low-risk R-tag commands. For example, storage controller 1100 can classify the low-risk R-tag commands into an urgent task group and give them a higher write priority than commands in the normal task group. Furthermore, storage controller 1100 can schedule low-risk R-tag commands to have the highest priority within the urgent task group. In this case, some adjustments can be made to prevent other urgent task commands from being excessively delayed. For example, the ratio of low-risk R-tag commands to urgent task commands, and the ratio of commands assigned to the highest priority within the urgent task group, can be set to 2:1.

[0114] The low-risk tag R-tag commands rescheduled by the scheduler can then be assigned to flash queues FQ1 and FQ2. As a result, the write data corresponding to the low-risk tag R-tag can be programmed into the non-volatile memory device 1200 according to the highest write order. The writing of metadata corresponding to the low-risk tag R-tag can be handled according to the general method of separating metadata and user data.

[0115] Figure 13 This is a diagram illustrating an example of write scheduling for low-risk data writing according to one or more embodiments. (Reference) Figure 13The commit queue for hosts writing low-risk data can be adjusted through rescheduling performed in storage device 1000. Risk task groups for writing low-risk data can be managed separately in the scheduler.

[0116] Requests from the host to write low-risk data can be issued as commands that include a risk tag (R-tag). Two commit queues on the host, SQ1 and SQ2, can each load a write command that includes both risk tags (R-tag).

[0117] Storage device 1000 can read two low-risk R-tag commands loaded in two commit queues SQ1 and SQ2 from the host. Storage device 1000 can assign an internal flow ID to each of the low-risk R-tag commands. Using the internal flow ID, storage controller 1100 can classify the low-risk R-tag commands into a risk task group with a higher priority than the urgent task group. Storage controller 1100 can assign the highest priority to the low-risk R-tag commands.

[0118] The low-risk tag R-tag commands rescheduled by the scheduler can then be assigned to flash queues FQ1 and FQ2. As a result, the write data corresponding to the low-risk tag R-tag can be programmed into the non-volatile memory device 1200 according to the highest write order. The metadata writing of the write data corresponding to the low-risk tag R-tag can be handled according to the general method of separating metadata and user data.

[0119] Figure 14 This is a flowchart illustrating operation S260 according to one or more embodiments. (Reference) Figure 14 Risk Data Manager (1110, see below) Figure 3 It can perform medium-risk operations for storing medium-risk data.

[0120] In operation S261, the risk data manager 1110 can check the status of the data buffer of the buffer memory 1300 configured for the meta-unit. It can detect meta-units where the number of logs exceeds the threshold TH.

[0121] In operation S262, the risk data manager 1110 can determine whether there are any cells among multiple cells whose number of logs exceeds the threshold TH. If there are no cells whose number of logs exceeds the threshold TH ("No" direction), the process can proceed to operation S263. On the other hand, if there are cells whose number of logs exceeds the threshold TH ("Yes" direction), the process can proceed to operation S264.

[0122] In operation S263, the Risk Data Manager 1110 can select the cell with the largest number of logs from among multiple cells. The Risk Data Manager 1110 can then insert the logs of the data to be written into the selected cell.

[0123] In operation S264, the risk data manager 1110 can refresh the risk data to be written to the non-volatile memory device 1200.

[0124] In operation S265, the risk data manager 1110 can insert a log of the data to be written into the selected meta cell to complete the configuration of the meta cell, and write the configured meta cell to the non-volatile memory device 1200.

[0125] In the aforementioned medium-risk operations, input / output requests using the namespace for writing data can be kept active without being blocked.

[0126] Figure 15 This is a diagram illustrating a method for adding risk data logs to a meta-cell when the number of logs exceeds a threshold, according to one or more embodiments. (Reference) Figure 15 When the number of selected log cells exceeds the threshold TH, the risk data manager 1110 can create a log 'R-Jnl' for the risk data to be written and insert it into the log buffer. The log cell containing the risk data 'R-Jnl' can then be stored in the non-volatile memory device 1200.

[0127] On the other hand, if there are no cells with more than the threshold TH of logs, the cell with the largest number of logs among multiple cells can be selected. Then, the log "R-Jnl" of the risk data to be written can be inserted into the selected cell. The cell where the risk data log 'R-Jnl' is inserted can be updated in the non-volatile memory device 1200.

[0128] Figure 16 This is a flowchart illustrating operation S270 according to one or more embodiments. (See reference...) Figure 16 Risk Data Manager (1110, see below) Figure 3 It can perform high-risk operations used to store high-risk data.

[0129] In operation S271, the Risk Data Manager 1110 can analyze the risk tags R-tags sent from the host. If the analysis result of the risk tag R-tag corresponds to high-risk data, the Risk Data Manager 1110 can be configured as an ODL (Optical Data Level) as a single write unit to maintain the consistency of user data and metadata of the high-risk data. To configure the ODL, the ODL generator 1115 can set a buffer area of ​​a specific size in the buffer memory 1300.

[0130] In operation S272, the risk data manager 1110 can identify the address translation cache (ATC) or ODL namespace table 1119 used to write the ODL generated in operation S271 to the non-volatile memory device 1200. The ATC or ODL namespace table 1119 has an ODL namespace region (1215, see [link]) allocated to the non-volatile memory device 1200 for the ODL. Figure 4 Risk Data Manager 1110 can obtain the physical address information of ODL namespace region 1215 from Address Translation Cache (ATC) or ODL namespace table 1119.

[0131] In operation S273, the risk data manager 1110 can select a memory block for storing the ODL based on address information obtained from the address translation cache (ATC) or the ODL namespace table 1119. The memory block used to store the ODL can be selected from any of the free blocks. Alternatively, a pre-allocated memory block can be selected for storing the ODL.

[0132] In operation S274, the Risk Data Manager 1110 can configure an ODL, which is a single write unit used to maintain the consistency of metadata and user data for high-risk data. That is, the Risk Data Manager 1110 can configure an ODL including both metadata and user data for high-risk data within the buffer area selected in operation S273. The size of the ODL can be the page size, which is a write unit of the non-volatile memory device 1200. This will be described below. Figure 17 The configuration method of ODL is described in more detail in the document.

[0133] In operation S275, the Risk Data Manager 1110 can flush the ODL configured in the specified buffer area to the ODL namespace area 1215 of the non-volatile memory device 1200. The ODL configured at the page size can be written to the non-volatile memory device 1200 as quickly as possible. The method providing the fastest programming speed can be selected as the method for programming the ODL in the non-volatile memory device 1200.

[0134] Figure 17This is a diagram illustrating an example of a method for configuring on-demand logging performed in operation S274 according to one or more embodiments. (Reference) Figure 17 An ODL can be generated based on high-risk data provided from multiple hosts, with each ODL being a page unit. For clarity, an example is provided here where high-risk data from two hosts (a first host and a second host) is configured into a single ODL.

[0135] High-risk data provided from the first host can be configured as the first header (Header1, 1171, and 1173) of the ODL. The first header, Header1, can be configured with a first meta-field 1171 and a first data field 1173. The first meta-field 1171 can include a namespace identifier (NSID) assigned to the ODL, a data offset, a timestamp (TS), and metadata including log and metadata information. Here, the data offset can be a value indicating the length or size of the first data field 1173 in the ODL. The first data field 1173 can store high-risk data, which is user data requested to be written by the first host.

[0136] High-risk data provided from the second host may include a second header (Header2, 1172, and 1174) of the ODL. The second header, Header2, may include a second meta-field 1172 and a second data field 1174. The second meta-field 1172 may include a namespace identifier (NSID), a data offset, a timestamp (TS), and metadata including log and metadata assigned to the ODL. Here, the data offset may be a value indicating the length or size of the second data field 1174 in the ODL. The second data field 1174 may store high-risk data, which is user data requested to be written by the second host.

[0137] The illustrated ODL has been described as an example where high-risk data requested for writing from two hosts is comprised of a single write unit. However, the embodiment is not limited to this. An ODL can consist of two or more page units. Furthermore, an ODL can include high-risk data from one host or three or more hosts.

[0138] Figure 18 This is a flowchart illustrating an example of a data storage method based on a risk label in a storage device according to one or more embodiments. (Reference) Figure 18 Risk Data Manager (1110, see below) Figure 3 The system can analyze the risk tag R-tag and select a storage method for the data requested to be written to the non-volatile memory device 1200 based on the analysis results. In one or more embodiments, the medium-risk operation and Figure 10 The difference in the embodiments is that it is executed after a low-risk operation is performed.

[0139] In operation S310, the risk data manager 1110 can receive write commands sent from the host or commands sent via direct transmission.

[0140] In operation S320, the Risk Data Manager 1110 can extract the risk tag R-tag included in the received command. The Risk Data Manager 1110 can analyze the extracted risk tag R-tag to determine the risk level of the data requested to be written.

[0141] In operation S330, the risk data manager 1110 can execute an operation branch based on the value of the risk tag R-tag. If the write command does not include the risk tag R-tag ("No" direction), the process can move to operation S340. On the other hand, if the write command includes a low-risk or medium-risk tag (L or M), the process can move to operation S350. If the write command includes a high-risk tag H, the process can move to operation S370.

[0142] In operation S340, the risk data manager 1110 can store the data to be written in the non-volatile memory device 1200 according to the normal write operation. That is, the risk data manager 1110 can treat the data to be written as data that is not related to risk, and can store metadata and user data separately in the non-volatile memory device 1200 without adjusting the write priority or scheduling.

[0143] In operation S350, the Risk Data Manager 1110 can perform low-risk operations for storing low-risk data. The Risk Data Manager 1110 can schedule the write priority of low-risk data to be higher than the write priority of previously requested general data (excluding data with risk tags). The Risk Data Manager 1110 can manage the metadata of low-risk data in the same way as general data. The Risk Data Manager 1110 can assign internal stream IDs for scheduling low-risk data. The Risk Data Manager 1110 can reschedule the write priority to urgent tasks or adjust it to a higher priority than other urgent tasks.

[0144] In operation S355, the risk data manager 1110 can execute an operation branch based on whether the received risk tag R-tag is low-risk (L) or medium-risk (M). If the risk tag R-tag of the written command corresponds to low-risk (L) ('L' direction), the process can be terminated. On the other hand, if the risk tag R-tag of the written command corresponds to medium-risk (M) ('M' direction), the process can move to operation S360.

[0145] In operation S360, the Risk Data Manager 1110 can perform medium-risk operations for storing medium-risk data. The Risk Data Manager 1110 can maintain synchronization between the metadata and user data of the medium-risk written data. Furthermore, the Risk Data Manager 1110 can perform management operations for quickly flushing the written data to the non-volatile memory device 1200. The Risk Data Manager 1110 can select a meta-cell (log data and metadata) configured in the write buffer whose log data size is greater than or equal to a threshold. A meta-cell can be configured by inserting the log of the written data into the selected meta-cell, and the configured meta-cell can be flushed to the non-volatile memory device 1200. If no meta-cell exists whose log data size is greater than or equal to the threshold, the log of the data to be written can be inserted by selecting the meta-cell with the largest amount of log data. In this case, flushing the incident data is possible if the input / output of the namespace using the written data is not blocked and is activated.

[0146] In operation S370, the Risk Data Manager 1110 can perform high-risk operations for storing high-risk data. The Risk Data Manager 1110 can configure a single write unit (i.e., ODL) to maintain consistency between the metadata and user data of the high-risk write data. The ODL can be configured as a page unit for high-speed writing to the non-volatile memory device 1200. The Risk Data Manager 1110 can then store the physical address information of the generated ODL to be stored in the namespace table (1119, see...). Figure 3 The ODL written in the ODL namespace table 1119 can be assigned to the memory region of the non-volatile memory device 1200 specified in the corresponding namespace without a separate address mapping process.

[0147] According to one or more embodiments, the risk data manager 1110 can process data requested for writing from the host differently based on the risk tag R-tag. That is, the risk data manager 1110 can select / execute different storage methods for the requested data based on the risk tag R-tag. Therefore, the storage efficiency and data reliability of incident data stored in the storage device 1000 can be improved.

[0148] Figure 19 This is a block diagram illustrating a storage device according to one or more embodiments. Reference Figure 19The storage device 2000 can receive write requests including risk tags (R-tags) from a plurality of processors 100 to 800 corresponding to the host. Specifically, the storage device 2000 may include a buffer memory 2300 having a separate fixed area 2310 for writing risk data. In addition to further including the buffer memory 2300 having a separate fixed area 2310 for writing risk data, the storage device 2000 may be connected to… Figure 2 The storage device 1000 is basically the same. Therefore, the description of the host 100 to 800 and the non-volatile memory device 2200 will be omitted.

[0149] By using a buffer memory 2300 with a separate fixed area 2310 for inputting risk data, the efficiency of risk data management within the storage device 2000 of the risk data manager 2110 can be improved.

[0150] Figure 20 This is a block diagram illustrating a storage device according to one or more embodiments. Reference Figure 20 The storage device 3000 can receive write requests, including risk tags (R-tags), from multiple processors 100 to 800 corresponding to the host. Specifically, the storage device 3000 can use the host's ATC to access the host DRAM 900.

[0151] ATC can refer to a technology that caches the host's virtual memory addresses into physical addresses. Therefore, the address translation process for virtual memory addresses can be omitted, and the host DRAM 900 can be directly accessed using the cached physical addresses, thereby achieving fast data transfer. Furthermore, the host DRAM 900 can be assigned a fixed risk data region 910. When ATC is used for the fixed risk data region 910 in the storage controller 3100, the transfer speed of risk data stored in the fixed risk data region 910 can be increased. That is, the risk data manager 3110 can receive risk data from the host DRAM 900 by utilizing the physical address of the fixed risk data region 910 without the overhead of address translation. For this purpose, the risk data manager 3110 can include a risk data address 3110 for managing the physical address of the fixed risk data region 910. The storage device 3000 can be connected to... Figure 2 The storage device 1000 is essentially the same, except that it can use the ATC function. Therefore, the description of the host 100 to 800, the non-volatile memory device 3200, and the buffer memory 3300 will be skipped. The ATC function can improve the performance of critical data exchanges between the host DRAM 900 and the storage device 3000.

[0152] As used in conjunction with various embodiments of this disclosure, the term "module" may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with other terms such as logic, logic block, component, or circuit. A module may be a single integrated component or its smallest unit or portion adapted to perform one or more functions. For example, according to an embodiment, a module may be implemented as an application-specific integrated circuit (ASIC).

[0153] The various embodiments described herein can be implemented as software including one or more instructions stored in a machine-readable storage medium. For example, a machine's processor can invoke at least one of the one or more instructions stored in the storage medium and execute it with or without one or more other components under the processor's control. This allows the machine to be operated to perform at least one function according to the invoked at least one instruction. The one or more instructions may include code generated by a compiler or code executable by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. The term "non-transitory" simply means that the storage medium is a tangible device and does not include signals (e.g., electromagnetic waves), but the term does not distinguish between locations where data is stored semi-permanently in the storage medium and locations where data is temporarily stored in the storage medium.

[0154] According to embodiments, methods according to various embodiments of this disclosure may be included and provided in a computer program product. The computer program product may be traded as a product between a seller and a buyer. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., an optical disc read-only memory (CD-ROM)) or via an app store (e.g., the Play Store). TM The computer program product may be distributed online (e.g., downloaded or uploaded) or directly between two user devices (e.g., smartphones). If distributed online, at least a portion of the computer program product may be temporarily generated or at least temporarily stored in a machine-readable storage medium, such as the memory of a manufacturer's server, an app store's server, or a relay server.

[0155] According to various embodiments, each of the above components (e.g., a module or program) may include a single entity or multiple entities, and some of the multiple entities may be separately located in different components. According to various embodiments, one or more of the above components may be omitted, or one or more other components may be added. Alternatively or additionally, multiple components (e.g., modules or programs) may be integrated into a single component. In this case, according to various embodiments, the integrated component can still perform one or more functions of each of the multiple components in the same or similar manner as performed by the corresponding component of the multiple components prior to integration. According to various embodiments, operations performed by a module, program, or other component may be performed sequentially, in parallel, repeatedly, or heuristically, or one or more operations in the operations may be performed in a different order or omitted, or one or more other operations may be added.

[0156] At least one of the devices, units, components, modules, units, etc. represented by the boxes or equivalent indications in the above embodiments can be physically implemented by analog and / or digital circuits including one or more of logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, etc., and can also be implemented or driven by software and / or firmware (configured to perform the functions or operations described herein).

[0157] It is not excluded that each embodiment provided in the above description is associated with one or more features of another example or another embodiment that is also provided herein or that is not provided herein but is consistent with this disclosure.

[0158] Although this disclosure has been specifically shown and described with reference to embodiments thereof, it should be understood that various changes in form and detail may be made therein without departing from the spirit and scope of the appended claims.

Claims

1. A storage device configured to receive write data from at least one processor corresponding to an autonomous vehicle, the storage device comprising: a memory; and a storage controller configured to: receive, from the at least one processor, the write data and an accident risk tag corresponding to the write data, the accident risk tag corresponding to an accident risk level of the autonomous vehicle, wherein the accident risk tag corresponds to at least one of a first accident risk level, a second accident risk level, and a third accident risk level, the first accident risk level corresponding to a high accident risk, the second accident risk level corresponding to an accident risk lower than the first accident risk level, and the third accident risk level corresponding to an accident risk lower than the second accident risk level; select a storage method for storing the write data on the memory based on the accident risk tag; and store the write data on the memory based on the selected storage method. based on the accident risk tag corresponding to the first accident risk level, the storage controller is configured to select a first storage method for storing the write data on the memory, and 2. The memory device of claim 1, wherein, wherein, in the first storage method, the storage controller is configured to configure the write data and metadata of the write data as an on-demand log, the on-demand log is a single write unit, and store the on-demand log on the memory. the on-demand log is configured as a page unit corresponding to a write unit of the memory.

3. The memory device of claim 2, wherein, the memory includes a namespace region configured to store the on-demand log.

4. The memory device of claim 3, wherein, based on the accident risk tag corresponding to the third accident risk level, the storage controller is configured to select a second storage method for storing the write data on the memory, and 5. The memory device of claim 1, wherein, wherein, in the second storage method, the storage controller is configured to assign an internal stream identifier to the write data and adjust a write priority of the write data. based on the accident risk tag corresponding to the second accident risk level, the storage controller is configured to select a third storage method for storing the write data on the memory, and 6. The memory device of claim 1, wherein, wherein, in the third storage method, the storage controller is configured to: select a meta unit in a buffer memory having a number of logs exceeding a threshold value; insert log data of the write data into the selected meta unit; and store the write data and the selected meta unit on the memory. based on none of the meta units having a number of logs exceeding the threshold value among the meta units, the storage controller is further configured to insert log data into a meta unit having a largest number of logs among the meta units.

7. The memory device of claim 6, wherein, 8. The storage device of claim 1, further comprising a buffer memory in which the write data and the metadata of the write data are stored, the storage controller is further configured to manage a region of the buffer memory in which the write data is stored as an address translation cache. wherein ​ 9. A method of storing an apparatus, comprising: receiving, from a host, incident data including a risk tag and a write command; determining an incident risk level based on the risk tag, wherein the incident risk level corresponds to at least one of a first incident risk level, a second incident risk level, and a third incident risk level, the first incident risk level corresponding to a high incident risk, the second incident risk level corresponding to an incident risk lower than the first incident risk level, and the third incident risk level corresponding to an incident risk lower than the second incident risk level; selecting a storage method for storing the incident data on a storage based on the incident risk level; and storing the incident data on the storage based on the selected storage method.

10. The method of claim 9, wherein, The selecting the storage method for storing the incident data on the storage includes: based on the incident risk level corresponding to the third incident risk level, selecting a first storage method for storing the incident data on the storage, the first storage method including adjusting a write priority of the incident data to be higher than a write priority of general data.

11. The method of claim 10, wherein, The adjusting the write priority of the incident data includes assigning an internal stream identifier to the write data.

12. The method of claim 9, wherein, The selecting the storage method for storing the incident data on the storage includes: based on the incident risk level corresponding to the second incident risk level, selecting a second storage method for storing the incident data on the storage, the second storage method including: selecting a meta unit having a number of logs exceeding a threshold value; inserting log data of the write data into the selected meta unit; and storing the write data and the selected meta unit on the storage.

13. The method of claim 12, wherein, The second storage method further includes, based on there being no meta unit having a number of logs exceeding the threshold value, selecting a meta unit having a largest number of logs among the meta units.

14. The method of claim 9, wherein, The selecting the storage method for storing the incident data on the storage includes, based on the incident risk level corresponding to the first incident risk level, selecting a third storage method for storing the incident data on the storage, the third storage method including configuring the incident data and metadata of the incident data into an on-demand log, the on-demand log being a single write unit, and storing the on-demand log on the storage.

15. The method of claim 14, wherein, The on-demand log is configured as a page unit corresponding to a write unit of the storage.

16. The method of claim 14, wherein, The on-demand log includes: a meta field including at least one of a namespace identifier of the incident data, a data length, a timestamp, and meta information; and a data field including the incident data.

17. A storage apparatus configured to store incident data, the storage apparatus comprising: a first storage; a buffer storage on which the incident data and metadata of the incident data are stored; and a storage controller configured to receive the incident data and an incident risk tag corresponding to the incident data, wherein the storage controller includes: a tag analyzer configured to extract an accident risk level corresponding to the accident risk tag; a storage manager configured to select a storage method for storing the accident data on the first storage based on the extracted accident risk level; and a namespace table configured with a namespace address of the first storage where the accident data is stored, and wherein the accident risk tag corresponds to at least one of a first accident risk level, a second accident risk level, and a third accident risk level, the first accident risk level corresponding to a high accident risk, the second accident risk level corresponding to an accident risk lower than the first accident risk level, and the third accident risk level corresponding to an accident risk lower than the second accident risk level.

18. The memory device of claim 17, wherein, based on the extracted accident risk level corresponding to the first accident risk level, the storage manager is configured to select a first storage method for storing the write data on the first storage, wherein in the first storage method, the storage manager is configured to configure the accident data and the metadata as a single write unit and store the single write unit on the first storage.

19. The memory device of claim 17, wherein, based on the extracted accident risk level corresponding to the second accident risk level, the storage manager is configured to select a second storage method for storing the write data on the first storage, and wherein in the second storage method, the storage manager is configured to select a metadata unit having a number of logs exceeding a threshold value among metadata units on a buffer storage, insert log data of the accident data into the selected metadata unit, and store the accident data and the metadata unit on the first storage.

20. The memory device of claim 19, wherein, based on the extracted accident risk level corresponding to the third accident risk level, the storage manager is configured to select a third storage method for storing the write data on the first storage, and wherein in the third storage method, the storage manager is configured to allocate an internal flow identifier to the accident data and adjust a write priority of the accident data.

Images