Data storage method, solid state disk and computer program product

Abstract

The invention is suitable for the technical field of data processing, and provides a data storage method, a solid state disk and a program product, and the method comprises the steps: obtaining environment data of an area where a vehicle is located in a vehicle driving process; the environment data comprises obstacle data in a shooting range of the vehicle; inputting the environment data into a trained collision prediction model for processing to obtain collision prediction information between the vehicle and the obstacle; the collision prediction information comprises collision time; if the collision time is smaller than or equal to the first preset time, target data corresponding to the vehicle in the preset collision time period is solidified to the nonvolatile storage device. According to the method, the risk is pre-judged in advance through the collision prediction model, the data solidification process is actively triggered before the actual collision, the process does not depend on hardware signal feedback after the collision occurs, and the problems that the system fails and data cannot be written in when the collision occurs are solved.

Description

Technical Field

[0001] This application belongs to the field of data processing technology, and in particular relates to a data storage method, a solid-state drive, and a computer program product. Background Technology

[0002] With the increasing intelligence of automobiles, especially the widespread adoption of Autonomous Driving (AD) and Advanced Driving Assistance Systems (ADAS), the amount of data generated by vehicles is growing exponentially. Currently, Event Data Recorders (EDRs) and Data Storage Systems for Automated Driving (DSSAD) installed in vehicles are required to be able to record critical vehicle telemetry data before and after a collision.

[0003] However, existing vehicle storage architectures typically employ reactive data protection mechanisms, passively writing data only upon receiving a storage instruction from the central processing unit (CPU). This storage instruction is generated by the CPU after receiving a collision signal from the airbag control unit. Therefore, existing technology suffers from the problem of system failure following a collision, preventing data writing. Summary of the Invention

[0004] This application provides a data storage method, a solid-state drive, and a computer program product to solve the problem in the prior art where a collision causes the system to fail, making it impossible to write data.

[0005] In a first aspect, embodiments of this application provide a data storage method applied to a solid-state drive, the method comprising: During vehicle operation, environmental data of the area where the vehicle is located is acquired; the environmental data includes obstacle data within the vehicle's shooting range; The environmental data is input into a trained collision prediction model for processing to obtain collision prediction information between the vehicle and the obstacle; the collision prediction information includes the collision time. If the collision time is less than or equal to a first preset time, the target data of the vehicle within the preset collision time period will be stored in a non-volatile storage device.

[0006] The beneficial effects of the embodiments in this application compared with the prior art are: This application provides a data storage method that acquires environmental data of the area where the vehicle is located during vehicle operation. The environmental data includes obstacle data within the vehicle's field of view. The environmental data is input into a trained collision prediction model for processing to obtain collision prediction information between the vehicle and the obstacles. The collision prediction information includes the collision time. If the collision time is less than or equal to a first preset time, the target data corresponding to the vehicle within the preset collision time period is persisted to a non-volatile storage device. This application uses a collision prediction model to predict risks in advance and proactively triggers the data persistence process before the actual collision occurs. This process does not rely on hardware signal feedback after the collision, solving the problem of system failure and data inability to be written during a collision. Therefore, this application upgrades the solid-state drive (SSD) from a passive data warehouse to a security black box with proactive sensing capabilities. By integrating visual computing capabilities (i.e., a collision prediction model) within the SSD, and utilizing the time difference between the speed of light (visual perception) and physical speed (vehicle movement), emergency data persistence can be completed before a physical impact occurs.

[0007] In one possible implementation of the first aspect, acquiring environmental data of the area where the vehicle is located includes: The environmental data is obtained from the controller memory buffer of the solid-state drive; the environmental data is sent to the controller memory buffer by the vehicle's data acquisition device via point-to-point communication.

[0008] In the above embodiments, in the prior art, environmental data from the vehicle-mounted acquisition device typically requires a multi-node transmission link through the acquisition device → deserializer → SoC DRAM → CPU processing → PCIe bus → solid-state drive, resulting in long transmission delays and potential lag in input data for the collision prediction model. This embodiment directly sends environmental data to the controller memory buffer of the solid-state drive via point-to-point communication, eliminating intermediate steps such as deserializers and CPU processing. This significantly shortens the data transmission path and reduces latency, ensuring that the collision prediction model can obtain real-time, up-to-date environmental data, improving the accuracy of collision time prediction, and reserving sufficient execution window for data solidification.

[0009] In one possible implementation of the first aspect, before inputting the environmental data into a trained collision prediction model for processing to obtain collision prediction information between the vehicle and the obstacle, the method further includes: Obtain the identity information of the user using the vehicle; Based on the identity information and the environmental data, the collision prediction model is determined.

[0010] In the above embodiments, existing technologies mostly employ general collision prediction models, which do not consider the differences in driving habits and skills among different users, easily leading to prediction bias or false alarms / missed alarms. This embodiment, however, can associate user identity information with their historical driving data and combine it with real-time environmental data to match exclusive or adapted collision prediction models for different users, thus improving prediction accuracy. Furthermore, existing general models struggle to cover the risk characteristics of all scenarios, while this embodiment highly couples the vehicle driving environment with user driving behavior. The model provided by this embodiment maintains high prediction performance under various operating conditions, avoiding the accuracy degradation of a single model in complex scenarios.

[0011] In one possible implementation of the first aspect, before inputting the environmental data into a trained collision prediction model for processing to obtain collision prediction information between the vehicle and the obstacle, the method further includes: The collision prediction model performs hardware-level logic hardening acceleration operations on the specified components; the specified components include convolutional layers, pooling layers, and activation functions, and the hardware-level logic hardening acceleration operations refer to the operation of decomposing the mathematical operations corresponding to the specified components into hardware-executable logic circuits.

[0012] In the above implementation, the convolutional and pooling layers of the collision prediction model require massive matrix operations on environmental data. If general-purpose computing units at the software level are used, there will be additional overhead in instruction scheduling and data transfer, resulting in high computational latency. This implementation can accelerate the process through hardware logic hardening. The mathematical operations of convolution, pooling, and activation functions are directly decomposed into dedicated logic circuits, realizing hardware decoding and parallel execution of computation instructions. Compared with software computation, the model inference latency can be reduced by an order of magnitude, ensuring that collision prediction results can be output in milliseconds in high-speed driving scenarios. This provides sufficient execution time window for subsequent data solidification, avoiding the failure to solidify critical data in a timely manner due to model computation lag.

[0013] In one possible implementation of the first aspect, before inputting the environmental data into a trained collision prediction model for processing to obtain collision prediction information between the vehicle and the obstacle, the method further includes: Build a physical simulation environment using a simulation engine; Scene parameterization and parameter combination operations are performed in the physical simulation environment to obtain multiple different virtual collision scenarios; Acquire simulation environment data for each of the aforementioned virtual collision scenarios; The collision prediction model is obtained by optimizing and training the pre-built deep learning model based on the simulation environment data.

[0014] In the above embodiments, the training of collision prediction models in the prior art heavily relies on real-vehicle data. However, extreme collision scenarios in real-world conditions have a low probability of occurrence and are difficult to collect, which can easily lead to insufficient model recognition capabilities for low-probability, high-risk scenarios. This embodiment can construct virtual collision scenarios through a simulation engine, accurately parameterize scenario elements, and generate a massive number of differentiated virtual scenarios through parameter combinations. This allows the model training data to cover the full range of conditions from conventional to edge to extreme scenarios, significantly improving the model's prediction accuracy for complex and rare collision scenarios and avoiding the risk of missed detections due to missing real-vehicle data.

[0015] In one possible implementation of the first aspect, acquiring simulation environment data in each of the virtual collision scenarios includes: Obtain initial simulation data for each of the aforementioned virtual collision scenarios; Data augmentation processing is performed on each of the initial simulation data to obtain each of the simulation environment data; the data augmentation processing is used to simulate the characteristics of the data acquisition device when it performs data acquisition in a real environment.

[0016] In the above embodiments, the initial data generated by the virtual simulation environment has idealized characteristics and differs from the output of the data acquisition device in a real scene. For example, the simulated image lacks lens distortion, noise, and underexposure / overexposure issues. This embodiment can use data augmentation processing to make the simulation environment data perfectly match the output characteristics of the real acquisition device, eliminating the data domain gap between simulation and reality. This solves the problem that the model performs well in the simulation environment but its prediction accuracy drops sharply after actual deployment, ensuring that the model stably outputs high-precision collision prediction results in real vehicle scenarios.

[0017] In one possible implementation of the first aspect, after the target data corresponding to the vehicle within a preset collision time period is stored in a non-volatile storage device, the method further includes: The vehicle status is determined after a second preset time; the second preset time is longer than the first preset time. If the vehicle state is used to characterize that no collision has occurred, then a negative reward operation is performed on the collision prediction model.

[0018] In the above embodiments, existing collision prediction models often suffer from false alarms due to feature extraction bias and unreasonable threshold settings. These false alarms predict a collision risk that does not actually occur, interfering with the driving experience and wasting onboard storage resources. This embodiment can verify the vehicle status at a second preset time. If no collision occurs, the model weights are corrected in reverse through negative rewards, allowing the model to understand that this type of feature combination will not cause a real collision. This accurately suppresses false alarms in similar scenarios, reduces the likelihood of the model becoming oversensitive, and improves the matching degree between prediction results and real-world conditions.

[0019] In one possible implementation of the first aspect, after processing the environmental data by inputting it into a trained collision prediction model to obtain collision prediction information between the vehicle and the obstacle, the method further includes: If the collision prediction information is used to characterize that no collision exists, the vehicle state of the vehicle is determined; If the vehicle state is used to characterize that a collision avoidance operation has been performed, then a negative reward operation is performed on the collision prediction model.

[0020] In the above embodiments, existing collision prediction models are prone to implicit biases, such as predicting no collisions but the vehicle actually triggering collision avoidance maneuvers. This embodiment uses scenarios where the model predicts no collisions and the vehicle performs collision avoidance maneuvers as negative reward triggering conditions, which inversely correct the model weights, guide the model to learn the characteristic patterns of such critical risk scenarios, improve the model's sensitivity to predicting dangerous scenarios, and avoid safety hazards caused by missed risk assessments.

[0021] Secondly, embodiments of this application provide a data storage device applied to a solid-state drive, the device comprising: The first acquisition unit is used to acquire environmental data of the area where the vehicle is located during the vehicle's operation; the environmental data includes obstacle data within the vehicle's shooting range. The input unit is used to input the environmental data into a trained collision prediction model for processing to obtain collision prediction information between the vehicle and the obstacle; the collision prediction information includes the collision time. The solidification unit is used to solidify the target data of the vehicle within the preset collision time period to a non-volatile storage device if the collision time is less than or equal to a first preset time.

[0022] Thirdly, embodiments of this application provide a solid-state drive (SSD) for executing the data storage method as described in any of the first aspects. The SSD includes: a real-time control core group, a visual acceleration engine, a controller memory buffer, and a built-in memory, wherein the controller memory buffer is located in the built-in memory. The real-time control core group is used to send task instructions to the visual acceleration engine; The visual acceleration engine is connected to the real-time control core group and is used to respond to the task instructions. It accesses the environmental data of the area where the vehicle is located stored in the controller memory buffer through the target bus. Based on the environmental data, it performs collision prediction on the vehicle to obtain collision prediction information. The collision prediction information includes the collision time. The real-time control core group is also used to, when the collision time is detected to be less than or equal to a first preset time, to solidify the environmental data stored in the controller memory buffer and the metadata stored in the built-in memory to a non-volatile storage device.

[0023] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a solid-state drive, implements the data storage method as described in any one of the first aspects above.

[0024] Fifthly, embodiments of this application provide a computer program product that, when run on a solid-state drive, enables the solid-state drive to execute the data storage method described in any one of the first aspects. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a schematic diagram of the structure of a solid-state drive provided in an embodiment of this application; Figure 2 This is a flowchart illustrating the implementation of a data storage method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating the implementation of a data storage method provided in another embodiment of this application; Figure 4 This is a flowchart illustrating the implementation of a data storage method provided in another embodiment of this application; Figure 5 This is a flowchart illustrating the implementation of a data storage method according to another embodiment of this application; Figure 6 This is a schematic diagram of the structure of a data storage device provided in an embodiment of this application. Detailed Implementation

[0027] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0028] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0029] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0030] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0031] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0032] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0033] In practical applications, with the increasing intelligence of automobiles, especially the widespread adoption of Autonomous Driving (AD) and Advanced Driving Assistance Systems (ADAS), the amount of data generated by vehicles is growing exponentially. Currently, Event Data Recorders (EDRs) and Data Storage Systems for Automated Driving (DSSADs) installed in vehicles are required to be able to record critical vehicle telemetry data before and after a collision.

[0034] However, existing vehicle storage architectures typically employ reactive data protection mechanisms, passively writing data only upon receiving a storage instruction from the central processing unit (CPU). This instruction is generated by the CPU after receiving a collision signal from the airbag control unit. In other words, existing storage architectures are blind; they are unaware that the vehicle is in imminent danger and passively wait for read / write instructions. Even if the vehicle's cameras have clearly captured images of the impending impact, the existing storage architecture remains in a normal low-power or background garbage collection state, failing to prepare for emergency writes. Therefore, existing technology suffers from the inability to write data in situations involving high-speed / high-damage vehicle collisions resulting in physical vehicle damage.

[0035] Therefore, this application provides a data storage method and a solid-state drive with computing power that can predict whether a collision will occur. It can actively trigger the data solidification process before the actual collision occurs. This process does not rely on hardware signal feedback after the collision occurs, thus solving the problem of system failure and data inability to be written when a collision occurs.

[0036] Please see Figure 1 , Figure 1 This is a schematic diagram of the structure of a solid-state drive provided in one embodiment of this application. Figure 1 As shown, the solid-state drive 1 includes: a real-time control core group 10, a visual acceleration engine 20, and built-in memory 30. A portion of the built-in memory 30 can also be designated as a controller memory buffer 31.

[0037] Specifically, the real-time control core group 10 is used to send task instructions to the visual acceleration engine 20.

[0038] The visual acceleration engine 20, connected to the real-time control core group 10, is used to respond to task instructions by accessing the environmental data of the area where the vehicle is located stored in the controller memory buffer through the target bus; based on the environmental data, it performs collision prediction on the vehicle to obtain collision prediction information; the collision prediction information includes the collision time.

[0039] The real-time control core group 10 is also used to solidify the environmental data stored in the controller memory buffer 31 and the metadata stored in the built-in memory 30 to a non-volatile storage device when the collision detection time is less than or equal to a first preset time.

[0040] It should be noted that the Real-Time Cores 10 may include high-performance processors (such as the ARM Cortex-R series) or open-source instruction set architectures based on the Reduced Instruction Set Computer (RISC) computing principle, and other high-performance real-time cores.

[0041] In this embodiment, the real-time control core group 10 can be used for Non-Volatile Memory Host Controller Interface Specification (NVM Expres, NVMe) specification protocol parsing, Logical-to-Physical (L2P) address mapping, and NAND flash memory timing control.

[0042] Specifically, the real-time control core group 10 can be responsible for global task scheduling, protocol management, and hardware resource allocation, and directly manage the working status of the visual acceleration engine 20 and the built-in memory 30: issuing task instructions (such as model loading, inference startup, and result collection) to the visual acceleration engine 20 and allocating computing resources; issuing memory mapping rules (such as which storage areas are exposed to the high-speed serial computer extension bus standard (Peripheral Component Interconnect Express, PCI-Express, PCIe)) to the built-in memory 30, and defining the area exposed to the bus as the controller memory buffer 31 (CMB)). At the same time, the real-time control core group 10 can also manage the data interaction between the CMB and the NAND flash memory through L2P mapping.

[0043] In some possible embodiments, the real-time control core group 10 can configure the size (e.g., 512MB) and attributes (Write Combine) of the controller memory buffer 31 via the NVMe command Set Features.

[0044] In this embodiment, the visual acceleration engine (Embedded NPU) 20 integrates a neural processing unit (NPU), such as the ARM Ethos-U series.

[0045] It should be noted that the aforementioned neural network accelerator can directly access the built-in memory 30 in the solid-state drive 1 via a high-bandwidth internal bus protocol (Advanced eXtensible Interface, AXI).

[0046] The built-in memory 30 includes, but is not limited to, static random-access memory (SRAM) and dynamic random-access memory (DRAM).

[0047] In this embodiment, the visual acceleration engine 20 responds to the task instructions sent by the real-time control core group 10, and can access the environmental data of the area where the vehicle is located, including the solid-state drive 1, stored in the controller memory buffer 31 through the target bus, namely the AXI bus, and perform collision prediction on the vehicle based on the environmental data to output collision prediction information.

[0048] Understandably, the Visual Acceleration Engine 20 is equipped with a collision prediction model.

[0049] The collision prediction information includes the collision time.

[0050] It should be noted that Time-To-Collision (TTC) refers to the time when a vehicle and an obstacle may collide, defined as the distance between them divided by their relative speed. Obstacles include, but are not limited to, other vehicles, pedestrians, and living or non-living entities that obstruct the vehicle's movement.

[0051] In this embodiment, the real-time control core group 10 is further configured to actively trigger a cache write operation when the detected collision time is less than or equal to a first preset time. This allows the real-time control core group 10 to save the aforementioned environmental data stored in the controller memory buffer 31 and the metadata corresponding to the environmental data stored in the built-in memory 30 to a non-volatile storage device before the physical impact and power failure. The first preset time can be set according to actual needs and is not limited here. For example, the first preset time can be 1.5 seconds.

[0052] It should be noted that non-volatile storage devices include, but are not limited to, single-level cell NAND (SLC NAND) regions.

[0053] In some possible embodiments, the solid-state drive 1 is also equipped with a semantic trigger (not shown in the figure), which can monitor the TTC value output by the aforementioned visual acceleration engine 20 in real time.

[0054] In this embodiment, different TTC values ​​output by the semantic trigger can trigger different state machine logics. These state machine logics include, but are not limited to, safety and emergency commit.

[0055] The "Safe" status indicates that solid-state drive 1 can record normally in a loop, overwriting old data.

[0056] The Emergency Commit status indicates that the real-time control core group in the solid-state drive 10 needs to immediately perform an internal commit operation to force the image data in the controller memory buffer 31 and the metadata in the built-in memory 30 to be flushed into the SLC NAND area.

[0057] In this embodiment, the solid-state drive 1 can set the state machine logic corresponding to a TT value greater than a first preset time to a safe state, and the solid-state drive 1 can set the state machine logic corresponding to a TT value less than or equal to the first preset time to an emergency submission state.

[0058] Therefore, when the real-time control core group 10 detects that the state machine has switched to the emergency submission state, it indicates that the collision detection time is less than or equal to the first preset time.

[0059] Please see Figure 2 , Figure 2 This is a flowchart illustrating the implementation of a data storage method according to an embodiment of this application. In this embodiment, the data storage method is executed by a solid-state drive (SSD). The SSD may include automotive-grade SSDs (Computational Solid State Disks or Solid State Drives, SSDs) and computational storage devices (CSDs), among other devices.

[0060] It should be noted that in all embodiments of this application, the solid-state drive is... Figure 1 The corresponding solid-state drive.

[0061] like Figure 2 As shown, a data storage method provided in one embodiment of this application may include S101~S103, which are described in detail below: In S101, during vehicle operation, environmental data of the area where the vehicle is located is acquired; the environmental data includes obstacle data within the vehicle's shooting range.

[0062] In this embodiment, during vehicle operation, the solid-state drive can acquire real-time environmental data of the area where the vehicle is located, and predict whether a collision will occur based on this environmental data. The environmental data includes, but is not limited to, obstacle data within the vehicle's shooting range and vehicle operation data.

[0063] Obstacle data includes, but is not limited to, the position and speed of each obstacle.

[0064] Vehicle operating data includes, but is not limited to, vehicle speed and acceleration.

[0065] In one embodiment of this application, the solid-state drive may obtain the above-mentioned environmental data according to the following steps, detailed below: Environmental data is obtained from the controller memory buffer of the solid-state drive; the environmental data is sent to the controller memory buffer by the vehicle's data acquisition device via point-to-point communication.

[0066] In this embodiment, during vehicle operation, the vehicle's data acquisition device can collect environmental data of the area where the vehicle is located in real time. The data acquisition device includes, but is not limited to, external cameras and radar sensors of the vehicle.

[0067] After acquiring the aforementioned environmental data, the data acquisition device can send the environmental data to the deserializer, which then sends the environmental data to the bus master device.

[0068] In some possible embodiments, the above-mentioned deserializer can be a deserializer with high-speed serial link technology, such as a GMSL2 / 3 (Gigabit Multimedia Serial Link) deserializer.

[0069] Bus Master devices include, but are not limited to, PCIe bridge chips and Field Programmable Gate Arrays (FPGAs).

[0070] It should be noted that during the initialization phase of the solid-state drive, the vehicle's host CPU has already informed the bus master device bridge chip of the physical address of the controller memory buffer in the solid-state drive.

[0071] Therefore, in this embodiment, during vehicle operation, the environmental data collected by the data acquisition device, after being sent to the bus master device, can be directly sent to the CMB address of the solid-state drive via PCIe Write TLP, i.e., sent to the CMB via point-to-point communication (P2P). It is evident that in this embodiment, the entire process of sending environmental data to the CMB does not involve the host CPU or occupy the vehicle's host DRAM bandwidth, achieving zero-copy transmission.

[0072] Based on this, solid-state drives can obtain environmental data through their own controller memory buffer.

[0073] In one implementation of this embodiment, the visual acceleration engine in the solid-state drive can access the environmental data stored in the CMB to enable the solid-state drive to obtain environmental data through its own controller memory buffer.

[0074] In existing technologies, environmental data from vehicle-mounted acquisition devices typically requires a multi-node transmission link: acquisition device → deserializer → SoCDRAM → CPU processing → PCIe bus → solid-state drive. This results in long transmission delays and can easily lead to lag in input data for collision prediction models. This embodiment directly sends environmental data to the controller memory buffer of the solid-state drive via point-to-point communication, eliminating intermediate steps such as deserializers and CPU processing. This significantly shortens the data transmission path and reduces latency, ensuring that the collision prediction model can obtain real-time, up-to-date environmental data, improving the accuracy of collision time prediction, and reserving sufficient execution window for data solidification.

[0075] In some other possible embodiments, the bus master device may maintain a write pointer to the CMB in the solid-state drive, and the environmental data acquired in real time by the data acquisition device may be written cyclically in a ring buffer.

[0076] In other possible embodiments, after each frame of environmental data is input into the CMB, the data acquisition device can write a flag to a specific doorbell register of the solid-state drive, or the solid-state drive can poll a specific flag bit in the CMB to trigger the visual acceleration engine in the solid-state drive to start accessing the environmental data and performing collision prediction.

[0077] In one embodiment of this application, the firmware of the solid-state drive includes multiple model slots suitable for different scenarios for collision prediction, and one model slot corresponds to one model. Therefore, the solid-state drive can determine the collision prediction model to be used in the end according to the following steps, as detailed below: Obtain the identity information of the user using the vehicle; Based on identity information and environmental data, a collision prediction model is determined.

[0078] It should be noted that the above-mentioned models include, but are not limited to: radical model, conservative model, high-speed model, urban area model, and long-distance model.

[0079] Among them, the conservative model lowers the collision risk threshold (e.g., TTC=2.5s is considered high risk) and strengthens the identification of sudden risks to pedestrians / non-motorized vehicles, that is, the model parameters of this model are biased towards high sensitivity.

[0080] The aggressive model optimizes obstacle trajectory prediction in high-speed scenarios (≥100km / h) and improves the risk threshold for close following.

[0081] High-speed model: It optimizes obstacle trajectory prediction in high-speed scenarios (≥100km / h) and improves the recognition accuracy of obstacles at long distances (≥200m), that is, the model parameters of this model are biased towards high accuracy.

[0082] Urban model: sensitive to sudden crossings by pedestrians / electric vehicles, adapted to congested start-stop conditions.

[0083] Long-distance model: Adapts to the fatigue risk of long-distance driving, and enhances lane departure and adjacent vehicle collision prediction.

[0084] It should be noted that solid-state drives (SSDs) can pre-write the model weights of each trained model into the corresponding slots. Simultaneously, the SSD firmware can assign a unique identifier (Slot ID) to each slot and record the computing resources required to start each model (such as the number of FPGA logic units and memory bandwidth), ensuring rapid resource allocation during subsequent slot switching.

[0085] In this embodiment, after the vehicle is powered on, the in-vehicle camera can capture the driver's facial image and match the driver's ID using existing facial recognition algorithms. If no driver is recognized (e.g., the driver's face is obscured), alternative verification methods are triggered (e.g., reading the car key's NFC ID / vehicle system login account ID / Bluetooth-bound mobile phone MAC address).

[0086] After successful matching, the solid-state drive can obtain the identity information of the user using the vehicle. Among them, the user can be the driver.

[0087] Identity information includes, but is not limited to, user ID.

[0088] In this embodiment, the solid-state drive can extract core features of environmental data from the controller's memory buffer, including but not limited to scene features and risk features.

[0089] Scene characteristics may include: road type (highway / city / rural), vehicle speed, road conditions (congested / smooth), and obstacle type (pedestrian / vehicle / non-motorized vehicle), etc.

[0090] Risk characteristics may include: relative speed and distance to obstacles, as well as movement trajectory (straight / crossing / changing lanes), etc.

[0091] Afterwards, the solid-state drive can complete model matching using a pre-stored model index table.

[0092] Specifically, if the solid-state drive detects a model corresponding to the user ID determined at this time through the correspondence between different user IDs and different models set in the model index table, and the core features of the above environmental data meet the adaptation scenario triggering conditions of the model, then the model is directly determined as the final collision prediction model.

[0093] If the solid-state drive fails to detect a model corresponding to the currently determined user ID through the correspondence between different user IDs and different models set in the model index table, and / or the core features of the above environmental data exceed the adaptation scenario of the model corresponding to the currently determined user ID, then the basic general model will be determined as the final collision prediction model.

[0094] The basic general model can be determined according to actual needs, and there are no restrictions here. For example, the basic general model can be the urban area model mentioned above.

[0095] In some possible embodiments, after determining the collision prediction model, the SSD firmware can release the currently occupied model slot resources (if any) and lock the memory and hardware acceleration resources of the target slot (i.e., the slot corresponding to the collision prediction model). Then, the firmware can read the corresponding model weights and hardware hardening parameters from the target slot, load them into the SSD's hardware acceleration module, and complete the configuration of circuit parameters such as convolutional layers / pooling layers. Finally, after loading is complete, step S102 can be executed.

[0096] Existing technologies mostly employ general-purpose collision prediction models, failing to consider the differences in driving habits and skills among different users, which can easily lead to prediction bias or false alarms / missed alarms. This embodiment can associate user identity information with their historical driving data and combine it with real-time environmental data to match exclusive or adapted collision prediction models for different users, thereby improving prediction accuracy. Furthermore, compared to existing general-purpose models that struggle to cover the risk characteristics of all scenarios, this embodiment highly couples the vehicle driving environment with user driving behavior, enabling the model provided to maintain high prediction performance under various operating conditions and avoiding the accuracy degradation of a single model in complex scenarios.

[0097] In S102, environmental data is input into the trained collision prediction model for processing to obtain collision prediction information between the vehicle and the obstacle; the collision prediction information includes the collision time.

[0098] In this embodiment of the application, after obtaining environmental data, the solid-state drive can input the environmental data into the collision prediction model in the visual acceleration engine for inference calculation to obtain collision prediction information between the vehicle and the obstacle.

[0099] Collision prediction information includes, but is not limited to: target detection bounding boxes, distance information, and collision time.

[0100] Among them, the target detection box is used to mark various obstacles.

[0101] Distance information is used to describe the relative distance between a vehicle and an obstacle.

[0102] In some possible embodiments, due to the power consumption and heat dissipation limitations of solid-state drives, the above collision prediction model can adopt a lightweight model, such as the MobileNet series model, TinyViT series model, or EfficientNet series model.

[0103] Lightweight models are used to describe AI models that have a small number of parameters, low computational requirements, and low memory consumption. Lightweight models aim to improve efficiency while maintaining high performance, enabling them to run quickly on resource-constrained devices.

[0104] In other possible embodiments, to improve model processing efficiency, when the solid-state drive (SSD) inputs environmental data into the collision prediction model, it may first downsample and normalize the environmental data before inputting the processed environmental data into the collision prediction model.

[0105] In one embodiment of this application, since the solid-state drive has performed hardware-level logic hardening acceleration operations on the set components in the collision prediction model before executing step S102, the collision prediction model can perform convolution, pooling and other operations in parallel through the hardened hardware-executable logic circuits to quickly output collision prediction information.

[0106] The components include convolutional layers, pooling layers, and activation functions.

[0107] Hardware-level logic hardening acceleration refers to the operation of breaking down the mathematical operations corresponding to the set components into hardware-executable logic circuits.

[0108] In this embodiment of the application, after obtaining the collision time, the solid-state drive can compare the collision time with a first preset time.

[0109] In one embodiment of this application, when the solid-state drive detects a collision time less than or equal to a first preset time, it can execute step S103.

[0110] In another embodiment of this application, when the solid-state drive detects that the collision time is greater than a first preset time, it indicates that the vehicle is very likely not to collide with the obstacle. In other words, the vehicle is in normal driving at this time. Therefore, the solid-state drive does not need to perform data solidification operation or trigger a real alarm. It can continue to acquire environmental data at the next moment and continue to execute step S102 to continue to realize collision prediction of the vehicle.

[0111] In S103, if the collision time is less than or equal to the first preset time, the target data of the vehicle within the preset collision time period is saved to a non-volatile storage device.

[0112] In this embodiment of the application, when the solid-state drive detects that the collision time is less than or equal to a first preset time, it indicates that the vehicle is very likely to collide with the obstacle. In other words, the solid-state drive needs to perform a data solidification operation. Therefore, the solid-state drive can solidify the target data of the vehicle within the preset collision time period to a non-volatile storage device.

[0113] The preset collision time period can be determined according to actual needs and is not restricted here.

[0114] The target data includes, but is not limited to, the environmental data mentioned above, and the metadata corresponding to the environmental data stored in the built-in memory of the solid-state drive.

[0115] In some possible embodiments, the solid-state drive (SSD) may perform real-time encryption (Self-Encrypting Drive, SED) on the target data before it is stored on a non-volatile storage device. The key obtained from the real-time encryption is generated from the user's biometrics to ensure that only authorized personnel authorized by the user can view the target data subsequently.

[0116] Biometric features include, but are not limited to, fingerprints, irises, facial features, hand shapes, and DNA.

[0117] As can be seen from the above, the data storage method provided in this application acquires environmental data of the area where the vehicle is located during vehicle operation. The environmental data includes obstacle data within the vehicle's shooting range. The environmental data is input into a trained collision prediction model for processing to obtain collision prediction information between the vehicle and the obstacle. The collision prediction information includes the collision time. If the collision time is less than or equal to a first preset time, the target data corresponding to the vehicle within the preset collision time period is solidified to a non-volatile storage device. This application predicts risks in advance through a collision prediction model and actively triggers the data solidification process before the actual collision occurs. This process does not rely on hardware signal feedback after the collision, solving the problem of system failure and data inability to be written when a collision occurs. It can be seen that this application upgrades the solid-state drive from a passive data warehouse to a security black box with active perception capabilities. By integrating visual computing capabilities (i.e., a collision prediction model) inside the solid-state drive, and utilizing the time difference between the speed of light (visual perception) and physical speed (vehicle movement), emergency data persistence can be completed before a physical impact occurs.

[0118] In one embodiment of this application, since real-world collision data is scarce and difficult to cover all extreme cases, solid-state drives can construct a GPU cluster-based synthetic data pipeline to optimize and train a pre-built deep learning model to obtain the final collision prediction model.

[0119] In practical applications, a synthetic data generation pipeline is a systematic process for creating artificially generated datasets that simulate the statistical characteristics, structure, and distribution of real-world data, but without containing any real personal or sensitive information. The core objective of this process is to provide high-quality, large-scale, and accurately labeled data for training, testing, or data augmentation of machine learning models, while addressing challenges such as the scarcity of real-world data, privacy concerns, or insufficient coverage of long-tail scenarios.

[0120] Therefore, please refer to Figure 3 , Figure 3 This is a flowchart illustrating the implementation of a data storage method according to another embodiment of this application. Relative to... Figure 2 In a corresponding embodiment, prior to S102, this embodiment may also include S201~S204, as detailed below: In S201, a physical simulation environment is built using a simulation engine.

[0121] It should be noted that existing simulation tools / platforms can be used for the simulation engine, and no specific restrictions are placed on the type of simulation engine here.

[0122] In this embodiment, the physical simulation environment may include: Vehicle dynamics model: Import vehicle parameters (such as body size, wheelbase, braking performance, steering response characteristics, and tire friction coefficient) and simulate the real motion trajectory of vehicle acceleration, braking, steering, etc.

[0123] Environmental physics rules: Configure road surface type (asphalt / cement / icy / snowy road surface), friction coefficient, gravitational acceleration and air resistance parameters, etc.; and configure weather system (sunny / rainy / foggy / strong light at night) to simulate the impact of different lighting and visibility on sensor data collection.

[0124] Obstacle Model Library: Construct diverse obstacle models (pedestrians / non-motorized vehicles / cars / trucks / roadblocks) and define their motion characteristics (such as pedestrians randomly crossing, vehicles illegally changing lanes, and non-motorized vehicles weaving).

[0125] In S202, scene parameterization and parameter combination operations are performed in the physical simulation environment to obtain multiple different virtual collision scenarios.

[0126] In this embodiment, the solid-state drive can decompose the core elements of various real-world collision scenarios into quantifiable parameter dimensions, and set multi-level parameter values ​​for each dimension in the aforementioned physical simulation environment to ensure comprehensive scenario coverage.

[0127] The parameters include, but are not limited to: road type (e.g., urban congested roads, highways, rural roads, ramp merging / exiting, etc.), vehicle speed range (e.g., low speed (e.g., 0-30km / h), medium speed (e.g., 30-80km / h), high speed (e.g., 80-120km / h), etc.), obstacle type (e.g., pedestrians (adults / children), non-motorized vehicles (bicycles / electric vehicles), motorized vehicles (cars / trucks), static road barriers, etc.), obstacle behavior (e.g., stationary, constant speed straight, crossing the road, sudden lane change, emergency braking, etc.), weather / lighting (e.g., sunny day, rainy day, foggy day, night, backlight, etc.), and following distance (e.g., safe distance (e.g., ≥2s distance), critical distance (e.g., 1-2s distance), danger distance (e.g., <1s distance), etc.).

[0128] In this embodiment, the solid-state drive can generate multiple different virtual collision scenarios through full factorial combination and orthogonal experimentation, i.e., a massive number of virtual collision scenarios, in order to balance scenario diversity and training efficiency.

[0129] Among them, the full factor combination is used to combine key parameters (such as vehicle speed, obstacle type and obstacle behavior) to generate a basic scene library (such as 100km / h on the highway + emergency braking of a truck, 30km / h in the city + children crossing the road, etc.). Orthogonal sampling is used to sample non-critical parameters (such as weather / lighting) in an orthogonal manner to reduce redundant scenarios and improve training efficiency.

[0130] In S203, simulation environment data for each virtual collision scenario is acquired.

[0131] In this embodiment, after obtaining multiple different virtual collision scenarios, the solid-state drive can run each of these virtual collision scenarios in the simulation engine to obtain simulation environment data for each virtual collision scenario.

[0132] In one embodiment of this application, the solid-state drive can obtain simulation environment data according to the following steps, detailed below: Obtain initial simulation data for each virtual collision scenario; Data augmentation processing is performed on each initial simulation data to obtain data for each simulation environment; the data augmentation processing is used to simulate the characteristics of the data acquisition device when acquiring data in a real environment.

[0133] In this embodiment, since the initial data generated by the virtual simulation environment has idealized characteristics and there is a domain difference between it and the output of the data acquisition device in the real scene, the solid-state drive can perform data augmentation processing on the acquired initial simulation data to eliminate the domain difference between the idealized simulation data and the real data, and obtain the final simulation environment data.

[0134] Data augmentation processing is used to simulate the characteristics of data acquisition devices when acquiring data in real-world environments. These characteristics include, but are not limited to, lens distortion, Gaussian noise, motion blur, radar point cloud noise, point cloud sparsity, and sensor measurement errors.

[0135] It should be noted that for specific data augmentation methods, please refer to existing data augmentation techniques, which will not be elaborated here.

[0136] In some possible embodiments, the solid-state drive may add lens distortion, Gaussian noise, motion blur (simulating vehicle bumps), underexposure / overexposure (simulating backlight / nighttime), rain and snow obstruction (simulating severe weather) to the image data in the initial simulation data; and / or, randomly crop or flip the image (focusing on obstacle areas).

[0137] In some other possible embodiments, the solid-state drive can add radar point cloud noise, point cloud sparsification (simulating point cloud missingness of distant obstacles), and occlusion (simulating occlusion by a nearby vehicle) to the point cloud data in the initial simulation data.

[0138] In some other possible embodiments, for time-series data, the solid-state drive may add small jitter (simulating sensor measurement error); and / or adjust the data sampling interval (simulating sensor frame rate fluctuation).

[0139] Because the initial data generated by the virtual simulation environment has idealized characteristics, it differs from the output of the data acquisition device in a real scene. For example, simulated images lack lens distortion, noise, and underexposure / overexposure issues. Therefore, this embodiment can use data augmentation processing to make the simulation environment data perfectly match the output characteristics of the real acquisition device, eliminating the data domain gap between simulation and reality. This solves the problem that the model performs well in the simulation environment but its prediction accuracy drops sharply after actual deployment, ensuring that the model stably outputs high-precision collision prediction results in real vehicle scenarios.

[0140] In S204, a pre-built deep learning model is optimized and trained based on data from various simulation environments to obtain a collision prediction model.

[0141] In this embodiment, after obtaining data from various simulation environments, the solid-state drive can input the data from each simulation environment into a pre-built deep learning model and perform multiple rounds of iterative training to optimize the training of the deep learning model, thereby obtaining the final collision prediction model.

[0142] It should be noted that the specific implementation process of the above-mentioned optimized training can be found in the existing model training implementation process, which will not be elaborated here.

[0143] In some possible embodiments, the training processes for the aforementioned radical model, conservative model, high-speed model, urban area model, and long-distance model, in conjunction with step S101, can all be referred to as follows: Figure 3 The steps S201~S204 are shown.

[0144] In one embodiment of this application, the solid-state drive can use quantization-aware training technology to optimize the training of a deep learning model.

[0145] In practical applications, Quantization-Aware Training (QAT) is a training optimization technique for lightweighting and hardware deployment of deep learning models. Its core is to introduce quantization error simulation during the model training stage, allowing the model to adapt to low-precision operations (such as 8-bit integers, INT8) in advance, thereby reducing the model's computational load and memory usage while maximizing the preservation of the model's prediction accuracy.

[0146] In one embodiment of this application, since the solid-state drive is located in the vehicle, and the vehicle is usually bound to the user, the collision prediction model trained above may also contain the user's personal information, such as the user ID bound to the corresponding model. Therefore, in order to improve the confidentiality of the collision prediction model trained, the solid-state drive can combine national cryptographic standards (such as NVMe SSD) and hardware unique identifiers (Unique ID, UID) to manage the collision prediction model.

[0147] In another embodiment of this application, after obtaining the trained collision prediction model, the solid-state drive can update the old prediction model that the user has pre-stored in the cloud based on the collision prediction model, so that when the user changes cars, he / she can obtain the latest collision prediction model corresponding to it from the cloud without retraining the model.

[0148] In one implementation of this embodiment, the vehicle does not need to send the entire trained collision prediction model to the cloud. Instead, it can send only the difference in the weight matrix (DeltaWeights) between the collision prediction model and the old prediction model to reduce over-the-air (OTA) traffic.

[0149] In another embodiment of this application, after obtaining the above-mentioned collision prediction model, the solid-state drive can use an encryption algorithm to encrypt the model file corresponding to the collision prediction model. During the encryption process, the solid-state drive's Physical Unclonable Function (PUF) is combined to generate a hardware key, thereby further improving the security of the model.

[0150] The encryption algorithm mentioned above can be an existing encryption algorithm, which will not be elaborated here. For example, the encryption algorithm can be AES-256.

[0151] As can be seen from the above, the data storage method provided in this embodiment, compared with the prior art where the training of collision prediction models highly depends on real vehicle data collection, and the low probability and difficulty of collecting extreme collision conditions in real scenarios, which easily leads to insufficient model recognition ability for low-probability, high-risk scenarios, this embodiment can construct virtual collision scenarios through a simulation engine, accurately parameterize scene elements, and generate massive differentiated virtual scenarios through parameter combinations. This enables the model training data to cover the full range of working conditions from normal scenarios to edge scenarios to extreme scenarios, greatly improving the model's prediction accuracy for complex and rare collision scenarios and avoiding the risk of missed reports due to missing real vehicle data.

[0152] Please see Figure 4 , Figure 4 This is a flowchart illustrating the implementation of a data storage method provided in another embodiment of this application. Compared to... Figure 2 In a corresponding embodiment, this embodiment may further include S301~S302 after S103, as detailed below: In S301, the vehicle status is determined after a second preset time; the second preset time is greater than the first preset time.

[0153] In this embodiment, after the collision prediction model outputs the second preset time of the collision time, the solid-state drive can determine the vehicle's state to detect whether a collision has occurred.

[0154] It should be noted that the second preset time is longer than the first preset time. For example, the first preset time can be 5 seconds.

[0155] In one implementation of this embodiment, the solid-state drive can acquire vehicle data across multiple dimensions. These multiple dimensions include, but are not limited to, airbag status, vehicle acceleration, vehicle speed and trajectory, and collision warning status.

[0156] Specifically, the solid-state drive (SSD) can determine the airbag status via the vehicle's CAN bus, determine vehicle speed and acceleration via the vehicle's inertial vehicle unit, determine vehicle speed via a vehicle speed sensor, determine the trajectory via a GPS / BeiDou positioning module, and determine the collision warning status via a domain controller.

[0157] In this embodiment, after the solid-state drive determines that the airbag control unit has no detonation signal through the airbag status, and / or determines the instantaneous acceleration of the no-collision level through the vehicle speed acceleration, and / or the vehicle speed does not drop suddenly (the drop is <30km / h), the vehicle trajectory does not change abruptly, and / or the on-board collision avoidance system does not report any collision event, the vehicle state at this time can be used to characterize that no collision has occurred.

[0158] In S302, if the vehicle state is used to represent that no collision has occurred, a negative reward operation is performed on the collision prediction model.

[0159] In this embodiment, after the solid-state drive determines that the vehicle state is used to represent that no collision has occurred, it indicates that the collision prediction model has given a false alarm. Therefore, the solid-state drive can use the above-mentioned multiple dimensions of data as penalty signals based on reinforcement learning to perform negative reward operations on the collision prediction model in real time, so as to fine-tune the collision prediction model and reduce the false alarm rate.

[0160] It should be noted that the specific implementation process of performing the negative reward operation described above can be found in the existing implementation process of reinforcement learning, and will not be elaborated here.

[0161] In some possible embodiments, the negative reward operation described above can be performed while the vehicle is charging or idle.

[0162] As can be seen from the above, the data storage method provided in this embodiment, compared with the existing collision prediction models which often suffer from false alarms due to feature extraction deviations and unreasonable threshold settings, which can disrupt the driving experience and waste vehicle storage resources, can verify the vehicle status at a second preset time. If no collision occurs, the model weights are corrected in reverse through negative rewards, so that the model knows that this type of feature combination will not cause a real collision, accurately suppressing false alarms in similar scenarios, reducing the possibility of the model becoming oversensitive, and improving the matching degree between the prediction results and the actual working conditions.

[0163] Please see Figure 5 , Figure 5 This is a flowchart illustrating the implementation of a data storage method according to another embodiment of this application. Compared to... Figure 2 In a corresponding embodiment, this embodiment may further include S401~S402 after S103, as detailed below: In S401, if the collision prediction information is used to characterize that there is no collision, the vehicle state is determined.

[0164] In this embodiment, after the solid-state drive detects collision prediction information used to indicate that there is no collision, it can determine the vehicle status in real time.

[0165] It should be noted that the specific process for determining the vehicle status described above can be found in [reference needed]. Figure 4 Step S301 in the process will not be described in detail here.

[0166] In S402, if the vehicle state is used to characterize the collision avoidance operation that has been performed, then a negative reward operation is performed on the collision prediction model.

[0167] In this embodiment, when the solid-state drive detects that the vehicle's state is used to represent that a collision avoidance operation has been performed, it indicates that the collision prediction model has missed a report. Therefore, the solid-state drive can use the multi-dimensional data about the vehicle obtained at this time as a penalty signal based on reinforcement learning to perform a negative reward operation on the collision prediction model, so as to fine-tune the collision prediction model in real time and reduce the false alarm rate.

[0168] Collision avoidance operations include, but are not limited to, emergency braking operations.

[0169] It should be noted that the specific implementation process of performing the negative reward operation described above can be found in the existing implementation process of reinforcement learning, and will not be elaborated here.

[0170] In some possible embodiments, since false negatives are more harmful than false positives and are more likely to cause injury to people and vehicles, in reinforcement learning, the negative reward value (negative number) of the negative reward operation corresponding to a false negative needs to be less than the negative reward value (negative number) of the negative reward operation corresponding to a false positive.

[0171] In other possible embodiments, the above-described negative reward operation can be performed while the vehicle is charging or idle.

[0172] As can be seen from the above, the data storage method provided in this embodiment, compared with the implicit bias of existing collision prediction models that are prone to predicting no collision but the vehicle actually triggers anti-collision operations, can use the scenarios where the model predicts no collision and the vehicle performs anti-collision operations as negative reward triggering conditions to reverse the model weights, guide the model to learn the characteristic patterns of such critical risk scenarios, improve the model's sensitivity to predicting dangerous scenarios, and avoid safety hazards caused by missed risk assessments.

[0173] Combination Figures 2-5 For corresponding embodiments, please refer to Table 1. Table 1 is an analysis of the advantages of predictive brushing compared to reactive brushing in practical applications, provided by an embodiment of this application, across different dimensions. Predictive brushing is used to characterize... Figures 2-5 The corresponding implementation of the data storage method, reactive brushing, is used to characterize existing data storage methods.

[0174] Table 1:

[0175] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0176] Corresponding to the data storage method described in the above embodiments, Figure 6 A schematic diagram of a data storage device according to an embodiment of this application is shown. For ease of explanation, only the parts related to the embodiment of this application are shown. (Refer to...) Figure 6 The data storage device 500 includes: a first acquisition unit 51, an input unit 52, and a storage unit 53. Wherein: The first acquisition unit 51 is used to acquire environmental data of the area where the vehicle is located during the vehicle's operation; the environmental data includes obstacle data within the vehicle's shooting range.

[0177] The input unit 52 is used to input the environmental data into the trained collision prediction model for processing to obtain collision prediction information between the vehicle and the obstacle; the collision prediction information includes the collision time.

[0178] The solidification unit 53 is used to solidify the target data of the vehicle within the preset collision time period to a non-volatile storage device if the collision time is less than or equal to a first preset time.

[0179] In one embodiment of this application, the first acquisition unit 51 specifically includes: a second acquisition unit.

[0180] The second acquisition unit is used to acquire the environmental data from the controller memory buffer of the solid-state drive; the environmental data is sent to the controller memory buffer by the vehicle's data acquisition device through point-to-point communication.

[0181] In one embodiment of this application, the data storage device 500 further includes: a third acquisition unit and a model determination unit. Wherein: The third acquisition unit is used to acquire the identity information of the user using the vehicle.

[0182] The model determination unit is used to determine the collision prediction model based on the identity information and the environmental data.

[0183] In one embodiment of this application, the data storage device 500 further includes: a first operation unit. Wherein: The first operation unit is used to perform hardware-level logic hardening acceleration operations on the set components in the collision prediction model; the set components include convolutional layers, pooling layers and activation functions, and the hardware-level logic hardening acceleration operations refer to the operation of decomposing the mathematical operations corresponding to the set components into hardware-executable logic circuits.

[0184] In one embodiment of this application, the data storage device 500 further includes: a construction unit, a second operation unit, a fourth acquisition unit, and a training unit. Wherein: Building blocks are used to construct physical simulation environments using a simulation engine.

[0185] The second operation unit is used to perform scene parameterization operations and parameter combination operations in the physical simulation environment to obtain multiple different virtual collision scenarios.

[0186] The fourth acquisition unit is used to acquire simulation environment data in each of the virtual collision scenarios.

[0187] The training unit is used to optimize and train the pre-built deep learning model based on the simulation environment data to obtain the collision prediction model.

[0188] In one embodiment of this application, the fourth acquisition unit specifically includes: a fifth acquisition unit and an enhancement processing unit. Wherein: The fifth acquisition unit is used to acquire the initial simulation data in each of the virtual collision scenarios.

[0189] The enhancement processing unit is used to perform data enhancement processing on each of the initial simulation data to obtain each of the simulation environment data; the data enhancement processing is used to simulate the characteristics of the data acquisition device when it performs data acquisition in a real environment.

[0190] In one embodiment of this application, the data storage device 500 further includes: a first determining unit and a first executing unit. Wherein: The first determining unit is used to determine the vehicle status after a second preset time; the second preset time is longer than the first preset time.

[0191] The first execution unit is configured to perform a negative reward operation on the collision prediction model if the vehicle state is used to characterize that no collision has occurred.

[0192] In one embodiment of this application, the data storage device 500 further includes: a second determining unit and a second execution unit. Wherein: The second determining unit is used to determine the vehicle state of the vehicle if the collision prediction information is used to characterize that no collision exists.

[0193] The second execution unit is used to perform a negative reward operation on the collision prediction model if the vehicle state of the vehicle is used to characterize that a collision avoidance operation has been performed.

[0194] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0195] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0196] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a solid-state drive, implements the steps described in the above-described method embodiments.

[0197] This application provides a computer program product that, when run on a solid-state drive (SSD), enables the SSD to perform the steps described in the above-described method embodiments.

[0198] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a solid-state drive, recording media, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0199] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0200] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A data storage method, characterized in that, Applied to solid-state drives, the method includes: During vehicle operation, environmental data of the area where the vehicle is located is acquired; the environmental data includes obstacle data within the vehicle's shooting range; The environmental data is input into a trained collision prediction model for processing to obtain collision prediction information between the vehicle and the obstacle; the collision prediction information includes the collision time. If the collision time is less than or equal to a first preset time, the target data of the vehicle within the preset collision time period will be stored in a non-volatile storage device.

2. The data storage method as described in claim 1, characterized in that, The acquisition of environmental data of the area where the vehicle is located includes: The environmental data is obtained from the controller memory buffer of the solid-state drive; the environmental data is sent to the controller memory buffer by the vehicle's data acquisition device via point-to-point communication.

3. The data storage method as described in claim 1, characterized in that, Before inputting the environmental data into the trained collision prediction model for processing to obtain the collision prediction information between the vehicle and the obstacle, the method further includes: Obtain the identity information of the user using the vehicle; Based on the identity information and the environmental data, the collision prediction model is determined.

4. The data storage method as described in claim 1, characterized in that, Before inputting the environmental data into the trained collision prediction model for processing to obtain the collision prediction information between the vehicle and the obstacle, the method further includes: The collision prediction model performs hardware-level logic hardening acceleration operations on the specified components; the specified components include convolutional layers, pooling layers, and activation functions, and the hardware-level logic hardening acceleration operations refer to the operation of decomposing the mathematical operations corresponding to the specified components into hardware-executable logic circuits.

5. The data storage method as described in claim 1, characterized in that, Before inputting the environmental data into the trained collision prediction model for processing to obtain the collision prediction information between the vehicle and the obstacle, the method further includes: Build a physical simulation environment using a simulation engine; Scene parameterization and parameter combination operations are performed in the physical simulation environment to obtain multiple different virtual collision scenarios; Acquire simulation environment data for each of the aforementioned virtual collision scenarios; The collision prediction model is obtained by optimizing and training the pre-built deep learning model based on the simulation environment data.

6. The data storage method as described in claim 5, characterized in that, The acquisition of simulation environment data in each of the virtual collision scenarios includes: Obtain initial simulation data for each of the aforementioned virtual collision scenarios; Data augmentation processing is performed on each of the initial simulation data to obtain each of the simulation environment data; the data augmentation processing is used to simulate the characteristics of the data acquisition device when it performs data acquisition in a real environment.

7. The data storage method according to any one of claims 1-6, characterized in that, After storing the target data corresponding to the vehicle within a preset collision time period into a non-volatile storage device, the method further includes: The vehicle status is determined after a second preset time; the second preset time is longer than the first preset time. If the vehicle state is used to characterize that no collision has occurred, then a negative reward operation is performed on the collision prediction model.

8. The data storage method according to any one of claims 1-6, characterized in that, After inputting the environmental data into a trained collision prediction model for processing to obtain collision prediction information between the vehicle and the obstacle, the method further includes: If the collision prediction information is used to characterize that no collision exists, the vehicle state of the vehicle is determined; If the vehicle state is used to characterize that a collision avoidance operation has been performed, then a negative reward operation is performed on the collision prediction model.

9. A solid-state drive, characterized in that, The solid-state drive is used to execute the data storage method as described in any one of claims 1-8, and the solid-state drive includes: a real-time control core group, a visual acceleration engine, a controller memory buffer, and a built-in memory, wherein the controller memory buffer is located in the built-in memory; The real-time control core group is used to send task instructions to the visual acceleration engine; The visual acceleration engine is connected to the real-time control core group and is used to respond to the task instructions. It accesses the environmental data of the area where the vehicle is located stored in the controller memory buffer through the target bus. Based on the environmental data, it performs collision prediction on the vehicle to obtain collision prediction information. The collision prediction information includes the collision time. The real-time control core group is also used to, when the collision time is detected to be less than or equal to a first preset time, to solidify the environmental data stored in the controller memory buffer and the metadata stored in the built-in memory to a non-volatile storage device.

10. A computer program product, characterized in that, It includes a computer program that, when run, implements the data storage method as described in any one of claims 1 to 8.

Images