WO2019140906A1 - 车载监控设备的文件处理方法和车载监控设备 - Google Patents

车载监控设备的文件处理方法和车载监控设备 Download PDF

Info

Publication number
WO2019140906A1
WO2019140906A1 PCT/CN2018/102256 CN2018102256W WO2019140906A1 WO 2019140906 A1 WO2019140906 A1 WO 2019140906A1 CN 2018102256 W CN2018102256 W CN 2018102256W WO 2019140906 A1 WO2019140906 A1 WO 2019140906A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
monitoring device
weight value
vehicle
determining
Prior art date
Application number
PCT/CN2018/102256
Other languages
English (en)
French (fr)
Inventor
沈艳
王红丽
于晶
赵星星
Original Assignee
京东方科技集团股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 京东方科技集团股份有限公司 filed Critical 京东方科技集团股份有限公司
Priority to US16/469,802 priority Critical patent/US20200379954A1/en
Publication of WO2019140906A1 publication Critical patent/WO2019140906A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/176—Support for shared access to files; File sharing support
    • G06F16/1767—Concurrency control, e.g. optimistic or pessimistic approaches
    • G06F16/1774—Locking methods, e.g. locking methods for file systems allowing shared and concurrent access to files
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841—Registering performance data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/18—Closed-circuit television [CCTV] systems, i.e. systems in which the video signal is not broadcast
    • H04N7/183—Closed-circuit television [CCTV] systems, i.e. systems in which the video signal is not broadcast for receiving images from a single remote source
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/13—File access structures, e.g. distributed indices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/1727—Details of free space management performed by the file system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0608—Saving storage space on storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
    • G06F3/0652—Erasing, e.g. deleting, data cleaning, moving of data to a wastebasket
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V20/00—Scenes; Scene-specific elements
    • G06V20/50—Context or environment of the image
    • G06V20/56—Context or environment of the image exterior to a vehicle by using sensors mounted on the vehicle
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V20/00—Scenes; Scene-specific elements
    • G06V20/50—Context or environment of the image
    • G06V20/59—Context or environment of the image inside of a vehicle, e.g. relating to seat occupancy, driver state or inner lighting conditions
    • G06V20/597—Recognising the driver's state or behaviour, e.g. attention or drowsiness
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841—Registering performance data
    • G07C5/085—Registering performance data using electronic data carriers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/41422—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance located in transportation means, e.g. personal vehicle
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/422—Input-only peripherals, i.e. input devices connected to specially adapted client devices, e.g. global positioning system [GPS]
    • H04N21/4223—Cameras
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4335—Housekeeping operations, e.g. prioritizing content for deletion because of storage space restrictions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/4424—Monitoring of the internal components or processes of the client device, e.g. CPU or memory load, processing speed, timer, counter or percentage of the hard disk space used
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/765—Interface circuits between an apparatus for recording and another apparatus

Definitions

  • the present disclosure relates to the field of data storage technologies, and in particular, to a file processing method and an in-vehicle monitoring device of an in-vehicle monitoring device.
  • monitoring data such as videos and pictures are recorded and saved to the local storage space. Due to limited local storage space, related technologies delete the oldest monitoring data in the order of recording time. Deleting the monitoring data plan according to the recording time sequence will delete some important monitoring data, which will result in the inability to collect evidence when the vehicle is in an accident.
  • a file processing method of an in-vehicle monitoring device comprising:
  • the corresponding file is deleted according to the lock weight value.
  • the method before acquiring the lock weight value of each file in the local storage space, the method further includes:
  • the lock weight value is determined according to the scenario locking policy.
  • determining a scenario in which the in-vehicle monitoring device is located includes:
  • the sensing device comprises at least one of the following: an acceleration sensing device, a blind spot monitoring device, a fatigue detecting device, a pedestrian detecting device, a speed sensor, an image capturing device, and an interactive device.
  • the method further includes:
  • Deleting the corresponding file according to the locking weight value includes:
  • the corresponding file is deleted according to the lock weight value and the recording time.
  • deleting the corresponding file according to the locking weight value and the recording time comprises:
  • the method further includes:
  • the size of the occupied space in the local storage space is greater than or equal to the second storage threshold, deleting the saved file according to the importance scores from small to large, until the size of the occupied space is less than or equal to the first Two storage thresholds;
  • the second storage threshold is less than the first storage threshold.
  • the method further includes:
  • rate of increase is negatively proportional to the second storage threshold.
  • the method further includes:
  • the saved file is uploaded to the cloud in descending order of importance scores.
  • an in-vehicle monitoring device including:
  • One or more processors are One or more processors;
  • One or more memories coupled to the one or more processors and storing instructions that, when executed on the one or more processors, cause the one or more processors to be configured to:
  • the corresponding file is deleted according to the lock weight value.
  • the one or more processors are further configured to:
  • the lock weight value is determined according to the scenario locking policy.
  • the one or more processors are further configured to:
  • the sensing device comprises at least one of the following: an acceleration sensing device, a blind spot monitoring device, a fatigue detecting device, a pedestrian detecting device, a speed sensor, an image capturing device, and an interactive device.
  • the one or more processors are further configured to:
  • the corresponding file is deleted according to the lock weight value and the recording time.
  • the one or more processors are further configured to:
  • the one or more processors are further configured to:
  • the size of the occupied space in the local storage space is greater than or equal to the second storage threshold, deleting the saved file according to the importance scores from small to large, until the size of the occupied space is less than or equal to the first Second storage threshold,
  • the second storage threshold is smaller than the first storage threshold.
  • the one or more processors are further configured to:
  • the one or more processors are further configured to:
  • the saved file is uploaded to the cloud in descending order of importance scores.
  • FIG. 1 is a flow chart showing a file processing method of an in-vehicle monitoring device according to an embodiment of the present disclosure
  • FIG. 2 is a schematic flowchart of a file processing method of an in-vehicle monitoring device according to another embodiment of the present disclosure
  • FIG. 3 is a schematic flowchart of a file processing method of an in-vehicle monitoring device according to still another embodiment of the present disclosure
  • FIG. 4 is a flow diagram of deleting a file based on a lock weight value and a recording time according to an embodiment of the present disclosure
  • FIG. 5 is a schematic flowchart of a file processing method of an in-vehicle monitoring device according to still another embodiment of the present disclosure
  • FIG. 6 is a schematic flowchart of a file processing method of an in-vehicle monitoring device according to still another embodiment of the present disclosure
  • FIGS. 7 to 13 are block diagrams of a file processing apparatus of an in-vehicle monitoring device according to an embodiment of the present disclosure
  • FIG. 14 is a schematic structural diagram of an in-vehicle monitoring device according to an embodiment of the present disclosure.
  • the file processing method provided by the embodiment of the present disclosure can be applied to an electronic device such as a monitoring device, a camera, a video collection device, an audio collection device, and the like.
  • These electronic devices can continuously collect audio and video data (subsequently unified into files) for a period of time and store them in the local storage space.
  • Local storage space can be solid state drives, mechanical hard drives, and other readable storage media. Due to the limited local storage space, after the electronic device runs for a period of time, the local storage space will be used up, thereby affecting the operation of the electronic device system and software and data storage. If data is deleted in the order of storage time, it is possible to delete the more critical data, resulting in the inability to obtain critical data in some scenarios.
  • the file processing method provided in this embodiment may be applied to the foregoing electronic device, and it is first detected whether the size of the occupied space in the local storage space is greater than or equal to a storage threshold, and is obtained when the storage threshold is greater than or equal to the storage threshold. The weight of each file in the local storage space. The corresponding file is then deleted according to the lock weight value.
  • the monitoring data can be processed according to the weight of the locking weight, so that the monitoring data with a large weight value can be retained, that is, the relatively important monitoring data can be deleted, which is beneficial to subsequent query and evidence collection, and improves user use.
  • the weight of the locking weight so that the monitoring data with a large weight value can be retained, that is, the relatively important monitoring data can be deleted, which is beneficial to subsequent query and evidence collection, and improves user use.
  • FIG. 1 is a schematic flowchart of a file processing method of an in-vehicle monitoring device according to an embodiment of the present disclosure.
  • a file processing method of the vehicle monitoring device includes:
  • step 101 if it is detected that the size of the occupied space in the local storage space is greater than or equal to the first storage threshold, the locking weight value of each file in the local storage space is obtained.
  • the first storage threshold is pre-stored in the in-vehicle monitoring device.
  • the first storage threshold may be 90 GB, 80 GB, or the like.
  • the first storage threshold may also be a percentage of the local storage space, for example, 90%, 80%, and the like.
  • a person skilled in the art can set the format of the first storage threshold according to a specific scenario. It can be understood that when the first storage threshold is a percentage, it needs to be converted, and will not be described here.
  • the processor may actively query the local storage space, or may be sent to the processor in real time or periodically by the local storage space, and the solution of the embodiment may also be implemented. This is no longer limited.
  • the size of the occupied space is then directly compared to the first storage threshold.
  • the above obtaining and comparing processes are continued.
  • the size of the occupied space is greater than or equal to the first storage threshold, the lock weight value of each file in the local storage space is obtained.
  • the lock weight value is a value corresponding to the weight identifier of each file, for example, 1 to N, and the lock weight value is used to indicate the importance degree of the corresponding file.
  • the first level is represented by the number "1”
  • the second level is represented by the number "2”
  • the third level is represented by the value "3”, and so on.
  • the weight of the locking weight is "1", it means that the file is very important; if the weight of the locking weight is "2”, it means that the file is important; if the weight of the locking weight is "3”, it means that the importance of the file is generally If the weight of the lock is "4", the file is not important; if the weight of the lock is "5", the file is a junk file, and the level and value of the lock weight can be set according to the specific scene.
  • the weight of the locking weight can also be positively correlated with the value, that is, the larger the value, the larger the weight of the locking weight and the higher the level. Those skilled in the art can set according to specific scenarios.
  • the level and value of the above-mentioned locking weight value may be set by the driver or may be determined according to the scene in which the vehicle monitoring device is located, which will not be described here, and will be described in detail in subsequent embodiments.
  • the example in which the value of the lock weight value is smaller and the file level is higher is more important.
  • the corresponding file is deleted according to the lock weight value.
  • each file is sorted according to the size or level of the lock weight value, from large to small or from small to large.
  • the files are sorted in the order of the weighted weight values. Then, the file with the larger lock weight value (lower rank) is deleted in turn until the size of the occupied space in the local storage space is smaller than the first storage threshold.
  • the lock weight value of each monitoring data in the local storage space is obtained; and the locking weight value is processed according to the locking weight value.
  • the monitoring data can be processed according to the weight of the locking weight, so that the monitoring data with a large weight value can be retained, that is, the relatively important monitoring data can be deleted, which is beneficial to subsequent road condition query and evidence collection, and improves the user. Use experience.
  • FIG. 2 is a file processing method of the vehicle monitoring device according to an embodiment of the present disclosure. Schematic diagram of the process. Referring to FIG. 2, a file processing method of the vehicle monitoring device includes:
  • a scene in which the in-vehicle monitoring device is located is determined.
  • the set position on the vehicle is provided with a sensing device.
  • the sensing device includes at least one of the following: an acceleration sensing device, a blind spot monitoring device, a fatigue detecting device, a pedestrian detecting device, a speed sensor, an image capturing device, and an interactive device.
  • the in-vehicle monitoring device receives vehicle environmental parameters collected by each sensing device on the vehicle.
  • the acceleration sensor device can detect the acceleration of the vehicle in real time or at a time;
  • the blind spot monitoring device can acquire the audio and video data of the blind spot area of the vehicle in real time or at a time;
  • the fatigue detecting device can detect the physiological parameter of the driver in real time or timing to determine whether it is In a state of fatigue;
  • the pedestrian detection device can detect the presence or absence of pedestrians around the vehicle in real time or at a time;
  • the speed sensor can detect the speed of the vehicle in real time or at a time;
  • the image acquisition device can detect the traffic lights in front of the vehicle in real time or at a time;
  • the interactive device can acquire the trigger action of the user. Lock the file with a trigger.
  • Each of the above sensor devices can be combined or adjusted according to a specific scenario, so that different vehicle environmental parameters can be received.
  • the scene in which the in-vehicle monitoring device is located may be determined according to the vehicle environment parameter.
  • the lock weight value of the current file is determined according to the scenario locking policy.
  • the locking weight of the current file may be determined according to the scenario locking policy, including:
  • the scene is a blind spot monitoring device alarm, it is determined that the locking weight is a first level
  • the acceleration sensor device detects that the vehicle acceleration exceeds the acceleration threshold, determining that the locking weight is the first level
  • the fatigue detecting device detects the driver's fatigue driving, determining that the locking weight is the first level
  • the interaction device detects that the driver actively locks, determining that the weight of the lock is the first level
  • the pedestrian detection device detects that there is a pedestrian within the set range of the vehicle, determining that the weight of the lock is a second level;
  • the lock weight is determined to be the second level
  • the scene is that the image capturing device detects that the vehicle is traveling in the set environment, determining that the locking weight is a second level
  • the scene detects that the image capturing device detects a traffic light, determine that the locking weight is a third level
  • the weight value is determined to be the fourth level.
  • the technician can combine the multiple sensors in the sensing device to obtain a scenario corresponding to multiple constraints. On the basis of the corresponding scene, the level of the lock weight value is subdivided. It can be understood that the solution of the embodiment can also be implemented regardless of the combination or adjustment.
  • the in-vehicle monitoring device collects audio and video files and the like based on the determined locking weight value, and stores the file in a local storage space.
  • the in-vehicle monitoring device stores the file by using the locking weight value within a preset time period after determining the time when the weighting value is locked. The above preset time period can be adjusted according to different scenarios.
  • the preset time period may be set to 5 minutes, and then the file is stored with the locking weight value corresponding to the first level during the timing. After the timing is completed, the storage of the latter scene is performed.
  • the latter scenario can be obtained during the timing or after the timing is completed, which is not limited in this embodiment.
  • the locking weight is determined to be a third level, and the preset time period may be set to 30 seconds, and then, when timing, storing the locking weight value corresponding to the third level. file. The storage of the latter scene is performed after the timing is completed.
  • step 2031 it is detected whether the size of the occupied space in the local storage space is greater than or equal to the first storage threshold. If it is less than the first storage threshold, step 201 and step 202 are continued. When greater than or equal to the first storage threshold, step 2032 is performed.
  • a lock weight value for each file in the local storage space is obtained.
  • Steps 2031 and 2032 constitute step 203.
  • the specific methods and principles of step 203 and step 101 are the same.
  • the corresponding file is deleted according to the lock weight value.
  • step 204 and step 102 are the same.
  • steps 204 and step 102 are not described herein again.
  • the scene in which the vehicle is located ie, the scene in which the vehicle monitoring device is located
  • the locking weight value of the file collected by the vehicle monitoring device is determined according to the scenario, so that the locking weight of the file can be guaranteed.
  • the value corresponds to the scene, so that the key files are accurately obtained, which is beneficial to the subsequent deletion efficiency and accuracy, and improves the user's use efficiency.
  • FIG. 3 is a schematic flowchart of a file processing method of an in-vehicle monitoring device according to still another embodiment of the present disclosure.
  • a file processing method of the vehicle monitoring device includes:
  • step 301 if it is detected that the size of the occupied space in the local storage space is greater than or equal to the first storage threshold, the locking weight value of each file in the local storage space is obtained.
  • step 301 and step 101 are the same. For details, refer to the related content in FIG. 1 and step 101, and details are not described herein again.
  • step 302 a recording time of each file in the local storage space is obtained.
  • the recording time of the files is different. Therefore, in this embodiment, when it is detected that the size of the occupied space in the local storage space is greater than or equal to the first storage threshold, the recording time of each file is also acquired.
  • the above recording time can also be adjusted to the storage time. That is, the above recording time can be adjusted to the time value under any time reference system, and will not be described in detail herein.
  • step 302 and step 301 the order of obtaining the lock weight value of each file in step 302 and step 301 is not limited, and the lock weight value may be obtained before the recording time, and the recording time may be obtained before the lock weight value, or both. Get the recording time and the weight of the lock.
  • the corresponding file is deleted according to the lock weight value and the recording time.
  • the corresponding file is deleted based on the weighting value and the recording time, including:
  • Method 1 First, sort the files according to the size of the lock weight. During the sorting process, files with the same weighted value are sorted in chronological order. Then, the file is controlled to delete the file from the largest to the smallest. When multiple files correspond to the same lock weight value, the file is deleted from the file with the earliest recording time until the size of the local storage space is smaller than the first storage threshold.
  • step 401 based on the matching relationship between the locking weight value and the locking score value, the locking score value of the file is determined according to the locking weight value.
  • the matching relationship between the locking weight value and the locking score value may be preset in the vehicle monitoring device.
  • the lock weight value is the value "1", the lock score value is 50; the lock weight value is the value "2”, the lock score value is 40; the lock weight value is the value "3", and the lock is applied.
  • the score value is 30; the lock weight value is the value "4", the lock score value is 20; the lock weight value is the value "5", the lock score value is 10, and so on.
  • the locking score value of the file can be obtained according to the above matching relationship.
  • the time score value of the file is determined according to the recording time.
  • the matching relationship between the recording time and the time score value can be preset in the in-vehicle monitoring device.
  • the time period between the earliest recording time and the most recent recording time corresponding to the stored file is divided into a plurality of time segments, and each time segment corresponds to one time score value. Understandably, the earlier the recording time, the smaller the corresponding time score value.
  • the time score value is 0; before the recording time is 8 days, the time score value is 10; if the recording time is 6 days, the time score value is 20; The recording time is 4 days, the time score is 30; if the recording time is 2 days, the time score is 40; if the recording time is 2 days, the time score is 50; if the recording time is 0-24 hours, the time score is 60; and so on. Then, after the recording time of the file is obtained, it can be determined which time period the recording time is located, and the corresponding time score value is obtained.
  • time score value and the lock score value need to be correspondingly adjusted to the same order of magnitude, so that the two have the same degree of importance.
  • an importance score of the file is determined based on the lock score value and the time score value.
  • the lock score value and the time score value can be directly calculated into the importance score of the file.
  • the weighting coefficient can also be set for the locking score value and the time score value according to the specific scene, thereby obtaining the importance scores at different importance levels.
  • the file whose importance score is less than or equal to the importance threshold is deleted and the file whose importance score is greater than the importance threshold is saved.
  • the file with the lock weight value and the recording time is deleted in combination with the lock weight value and the recording time, thereby retaining the file with the smaller lock weight value and the recording time.
  • the local storage space have enough remaining space, but also ensure that the stored files are more important files, which is beneficial to subsequent road condition query and evidence collection, and enhances the user experience.
  • FIG. 5 is a schematic flowchart of a file processing method of an in-vehicle monitoring device according to still another embodiment of the present disclosure.
  • a file processing method of the in-vehicle monitoring device includes:
  • step 501 if it is detected that the size of the occupied space in the local storage space is greater than or equal to the first storage threshold, the locking weight value of each file in the local storage space is obtained.
  • step 501 and step 101 are the same. For details, refer to the related content in FIG. 1 and step 101, and details are not described herein again.
  • the corresponding file is deleted according to the lock weight value.
  • step 502 and step 102 are the same.
  • steps 502 and step 102 are the same.
  • details please refer to the related content of FIG. 1 and step 102, and details are not described herein again.
  • step 503 if the size of the occupied space in the local storage space is greater than or equal to the second storage threshold, the saved files are deleted in descending order of importance scores until the size of the occupied space is less than or Equal to the second storage threshold; the second storage threshold is less than the first storage threshold.
  • step 102 For the manner of deleting the file in this embodiment, reference may be made to the contents of step 102 and FIG. 2, which will not be described in detail herein. That is, each time the file is deleted, until the size of the occupied space in the local storage space is smaller than the second storage threshold.
  • the setting manner of the foregoing second storage threshold may refer to a setting manner of the first storage threshold, and the second storage threshold is smaller than the first storage threshold. For example, if the size of the local storage space is 100 GB, the first storage threshold may be 90 GB, and the second storage threshold may be 80 GB or less.
  • the second storage threshold is further adjusted according to the growth rate of the storage space, including:
  • the second storage threshold is adjusted according to a growth rate; the growth rate and the second storage threshold are in a negative ratio.
  • the occupied space of the local storage space is 85 GB
  • the occupied space of the local storage space is 86 GB
  • the growth rate of the occupied space in the first time and the second time period is It is 1GB/unit time.
  • the rate of increase is greater than a set threshold, at which point the second storage threshold can be adjusted to adjust the second storage threshold from 80 GB to 75 GB.
  • the second storage threshold can be adjusted at this time, the second storage threshold is adjusted from 80 GB to 70 GB, and so on. If the growth rate is less than the set threshold, the second storage threshold is not adjusted.
  • FIG. 6 is a schematic flowchart of a file processing method of an in-vehicle monitoring device according to still another embodiment of the present disclosure.
  • the file processing method of the vehicle monitoring device includes:
  • step 601 if it is detected that the size of the occupied space in the local storage space is greater than or equal to the first storage threshold, the locking weight value of each file in the local storage space is obtained.
  • step 601 and step 101 are the same. For details, refer to the related content in FIG. 1 and step 101, and details are not described herein again.
  • step 602 the corresponding file is deleted according to the lock weight value.
  • step 602 and step 102 are the same.
  • steps 602 and step 102 are the same.
  • details please refer to the related content in FIG. 1 and step 102, and details are not described herein again.
  • step 603 it is determined whether the in-vehicle monitoring device communicates with the cloud.
  • the in-vehicle monitoring device can send a connection request to the cloud in real time or at a time. If the in-vehicle monitoring device does not receive the response information matching the establishment of the link request within a predetermined time, it is determined that the communication cannot be communicated with the cloud. The vehicle monitoring device then continues to send the link request.
  • the in-vehicle monitoring device receives the response information matching the establishment of the link request within a prescribed time, it is determined that the in-vehicle communication can be communicated with the cloud.
  • step 604 in response to determining that the in-vehicle monitoring device communicates with the cloud, the saved file is uploaded to the cloud in descending order of importance scores.
  • the saved files are uploaded to the cloud in descending order of importance scores.
  • the in-vehicle monitoring device determines that the in-vehicle monitoring device can communicate with the cloud
  • the stored file is uploaded to the cloud, so that the key file can be stored, the subsequent road condition query and the evidence collection are performed, and the user experience is improved.
  • FIG. 7 is a block diagram of a file processing apparatus of an in-vehicle monitoring device according to an embodiment of the present disclosure.
  • the file processing apparatus 700 of the in-vehicle monitoring device includes:
  • the storage space detecting module 701 is configured to detect whether the size of the occupied space in the local storage space is greater than or equal to the first storage threshold, and send a trigger signal to the weight value acquiring module when the detection result is greater than or equal to;
  • the weight value obtaining module 702 is configured to acquire a lock weight value of each file in the local storage space when receiving a trigger signal from the storage space detecting module;
  • the file deletion module 703 is configured to delete the corresponding file according to the locking weight value.
  • the apparatus 700 further includes:
  • the scenario determining module 801 is configured to determine a scenario where the in-vehicle monitoring device is located;
  • the weight value determining module 802 is configured to determine, according to the scenario, a locking weight value of the current file according to the scenario locking policy.
  • the scene determining module 801 includes:
  • the parameter receiving unit 901 is configured to receive vehicle environment parameters collected by each sensing device on the vehicle;
  • the scenario determining unit 902 is configured to determine, according to the vehicle environment parameter, a scenario in which the in-vehicle monitoring device is located, based on a matching relationship between the environment parameter and the scenario.
  • the sensing device comprises at least one of the following: an acceleration sensing device, a blind spot monitoring device, a fatigue detecting device, a pedestrian detecting device, a speed sensor, an image collecting device, and an interaction device.
  • FIG. 10 is a block diagram of a file processing apparatus of an in-vehicle monitoring device according to an embodiment of the present disclosure.
  • the apparatus 700 includes:
  • the time obtaining module 1001 is configured to acquire a recording time of each file in the local storage space.
  • the file deletion module 703 is further configured to delete the corresponding file according to the locking weight value and the recording time.
  • the file deletion module 703 includes:
  • the lock score value determining unit 1101 is configured to determine, according to the matching relationship between the lock weight value and the lock score value, the lock score value of the file according to the lock weight value;
  • the time score value determining unit 1102 is configured to determine a time score value of the file according to the recording time based on a matching relationship between the recording time and a time score value;
  • the importance score determining unit 1103 is configured to determine an importance score of the file according to the lock score value and the time score value;
  • the file deletion unit 1104 is configured to delete the file whose importance score is less than or equal to the importance threshold and save the file whose importance score is greater than the importance threshold.
  • the file processing device further includes:
  • the storage space detecting module is further configured to detect whether the size of the occupied space in the local storage space is greater than or equal to a second storage threshold, and send a trigger signal to the file deletion module when the detection result is greater than or equal to;
  • the file deletion module is further configured to delete the saved file according to the importance scores from small to large, until the size of the occupied space is less than or equal to the second storage threshold;
  • the second storage threshold is less than the first storage threshold.
  • FIG. 12 is a block diagram of a file processing apparatus of an in-vehicle monitoring device according to an embodiment of the present disclosure.
  • the file processing apparatus 700 includes:
  • the growth rate acquisition module 1201 is configured to acquire a growth rate of the file occupation space in the local storage space.
  • the storage threshold adjustment module 1202 is configured to adjust the second storage threshold according to the growth rate; the growth rate is negatively proportional to the second storage threshold.
  • FIG. 13 is a block diagram of a file processing apparatus of an in-vehicle monitoring device according to an embodiment of the present disclosure.
  • the file processing apparatus 700 includes:
  • the communication judging module 1301 is configured to determine whether the in-vehicle monitoring device communicates with the cloud, and sends a trigger signal when communicating;
  • the file uploading module 1302 is configured to upload the saved file to the cloud in descending order of importance scores when receiving the trigger signal from the communication determining module.
  • FIG. 14 is a schematic structural diagram of an in-vehicle monitoring device according to an embodiment of the present disclosure.
  • the in-vehicle monitoring device 1400 includes:
  • the processor 1401 The processor 1401;
  • a memory 1402 for storing the processor executable instructions and files
  • the processor 1401 is configured to execute executable instructions in the memory 1402 to implement the steps of the file deletion methods described above.
  • first and second are used for descriptive purposes only and are not to be construed as indicating or implying relative importance.
  • the term “plurality” refers to two or more, unless specifically defined otherwise.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Databases & Information Systems (AREA)
  • Signal Processing (AREA)
  • Data Mining & Analysis (AREA)
  • Human Computer Interaction (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Traffic Control Systems (AREA)
  • Time Recorders, Dirve Recorders, Access Control (AREA)

Abstract

一种车载监控设备的文件处理方法和车载监控设备。文件处理方法包括：若检测到本地存储空间中被占用空间的大小大于或者等于第一存储阈值，获取本地存储空间内每个文件的加锁权重值；根据加锁权重值删除相应的文件。

Description

车载监控设备的文件处理方法和车载监控设备
相关申请的交叉引用
本申请要求2018年1月19日递交的中国申请CN201810055037.2的优先权，其全部公开内容通过引用合并于此。
技术领域
本公开涉及数据存储技术领域，尤其涉及一种车载监控设备的文件处理方法和车载监控设备。
背景技术
目前，视频设备应用越来越广泛。在视频设备作为车载监控设备使用时，会录制诸如视频和图片的监控数据，然后保存至本地存储空间中。由于本地存储空间有限，相关技术会按照录制时间顺序删除时间最早的监控数据。按照录制时间顺序删除监控数据方案，会将部分重要的监控数据删除，导致车辆发生事故时无法采集证据。
发明内容
根据本公开实施例的第一方面，提供一种车载监控设备的文件处理方法，所述方法包括：
若检测到本地存储空间中被占用空间的大小大于或者等于第一存储阈值，获取所述本地存储空间内每个文件的加锁权重值；以及
根据所述加锁权重值删除相应的文件。
在实施例中，获取所述本地存储空间内每个文件的加锁权重值之前，所述方法还包括：
确定车载监控设备所处场景；
基于所述场景，根据场景加锁策略确定加锁权重值。
在实施例中，确定车载监控设备所处场景包括：
接收车辆上各传感设备采集的车辆环境参数；以及
基于环境参数与场景的匹配关系，根据所述车辆环境参数确定所述车载监控设备所处 场景。
在实施例中，所述传感设备包括以下至少一种：加速度传感设备、盲点监测设备、疲劳检测设备、行人检测设备、速度传感器、图像采集设备和交互设备。
在实施例中，所述方法还包括：
获取所述本地存储空间内每个文件的录制时间；
根据所述加锁权重值删除相应的文件包括：
根据所述加锁权重值和所述录制时间删除相应的文件。
在实施例中，根据所述加锁权重值和所述录制时间删除相应的文件包括：
基于所述加锁权重值和加锁得分值的匹配关系，根据所述加锁权重值确定所述文件的加锁得分值；
基于所述录制时间和时间得分值的匹配关系，根据所述录制时间确定所述文件的时间得分值；
根据所述加锁得分值和所述时间得分值确定所述文件的重要度分值；以及
删除所述重要度分值小于或者等于重要度阈值的文件以及保存所述重要度分值大于所述重要度阈值的文件。
在实施例中，保存所述重要度分值大于所述重要度阈值的文件之后，所述方法还包括：
若所述本地存储空间中被占用空间的大小大于或者等于第二存储阈值，则按照重要度分值从小到大的顺序删除保存的文件，直至所述被占用空间的大小小于或者等于所述第二存储阈值；
其中所述第二存储阈值小于所述第一存储阈值。
在实施例中，根据所述加锁权重值和所述录制时间删除相应的文件之后，所述方法还包括：
获取所述本地存储空间中文件占用空间的增长速率；以及
根据所述增长速率调整所述第二存储阈值，
其中所述增长速率与所述第二存储阈值成负比例。
在实施例中，根据所述加锁权重值删除相应的文件之后，所述方法还包括：
判断所述车载监控设备与云端是否通信；
响应于判断所述车载监控设备与云端通信，按照重要度分值从大到小的顺序将保存的文件上传至所述云端。
根据本公开实施例的第二方面，提供一种车载监控设备，包括：
一个或多个处理器；以及
一个或多个存储器，与所述一个或多个处理器连接，并存储有指令，所述指令在所述一个或多个处理器上运行时使所述一个或多个处理器被配置为：
若检测到本地存储空间中被占用空间的大小大于或者等于第一存储阈值，获取所述本地存储空间内每个文件的加锁权重值；以及
根据所述加锁权重值删除相应的文件。
在实施例中，所述一个或多个处理器还被配置为：
确定车载监控设备所处场景；以及
基于所述场景，根据场景加锁策略确定加锁权重值。
在实施例中，所述一个或多个处理器还被配置为：
接收车辆上各传感设备采集的车辆环境参数；以及
基于环境参数与场景的匹配关系，根据所述车辆环境参数确定所述车载监控设备所处场景。
在实施例中，所述传感设备包括以下至少一种：加速度传感设备、盲点监测设备、疲劳检测设备、行人检测设备、速度传感器、图像采集设备和交互设备。
在实施例中，所述一个或多个处理器还被配置为：
获取所述本地存储空间内每个文件的录制时间；以及
根据所述加锁权重值和所述录制时间删除相应的文件。
在实施例中，所述一个或多个处理器还被配置为：
基于所述加锁权重值和加锁得分值的匹配关系，根据所述加锁权重值确定所述文件的加锁得分值；
基于所述录制时间和时间得分值的匹配关系，根据所述录制时间确定所述文件的时间得分值；
根据所述加锁得分值和所述时间得分值确定所述文件的重要度分值；以及
删除所述重要度分值小于或者等于重要度阈值的文件以及保存所述重要度分值大于所述重要度阈值的文件。
在实施例中，所述一个或多个处理器还被配置为：
若所述本地存储空间中被占用空间的大小是否大于或者等于第二存储阈值，按照重要度分值从小到大的顺序删除保存的文件，直至所述被占用空间的大小小于或者等于所述第二存储阈值，
其中，所述第二存储阈值小于所述第一存储阈值。
在实施例中，所述一个或多个处理器还被配置为：
获取所述本地存储空间中文件占用空间的增长速率；以及
根据所述增长速率调整所述第二存储阈值；所述增长速率与所述第二存储阈值成负比例。
在实施例中，所述一个或多个处理器还被配置为：
判断所述车载监控设备与云端是否通信；以及
响应于判断所述车载监控设备与云端通信，按照重要度分值从大到小的顺序将保存的文件上传至所述云端。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
图1是根据本公开实施例的车载监控设备的文件处理方法的流程示意图；
图2是根据本公开另一实施例的车载监控设备的文件处理方法的流程示意图；
图3是根据本公开又一实施例的车载监控设备的文件处理方法的流程示意图；
图4是根据本公开实施例的基于加锁权重值和录制时间删除文件的流程示意图；
图5是根据本公开又一实施例的车载监控设备的文件处理方法的流程示意图；
图6是根据本公开又一实施例的车载监控设备的文件处理方法的流程示意图；
图7～图13是根据本公开实施例的一种车载监控设备的文件处理装置的框图；
图14是本公开实施例的车载监控设备的结构示意图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
可理解的是，本公开实施例提供的文件处理方法可以应用于监控设备、摄像头、视频采集设备、音频采集设备等电子设备。这些电子设备在一段时间内可以持续的采集音视频数据(后续统一为文件)存储在本地存储空间内。本地存储空间可以为固态硬盘、机械硬盘以及其他可读取存储介质。由于本地存储空间有限，电子设备在运行一段时间后，本地存储空间会被使用完，从而影响到电子设备的系统和软件的运行以及数据存储。若按照存储时间的先后顺序删除数据，则可能将比较关键的数据删除，导致在一些场景中无法获取关键的数据。在这种情况下，可以将本实施例提供的文件处理方法应用到上述电子设备中，先检测到本地存储空间中被占用空间的大小是否大于或者等于存储阈值，在大于或者等于存储阈值时获取本地存储空间内每个文件的加锁权重值。然后根据所述加锁权重值删除相应的文件。
可见，本实施例中可以根据加锁权重值对监控数据进行处理，这样可以保留权重值较大的监控数据，即可以不删除相对重要的监控数据，有利于后续查询以及证据采集，提升用户使用体验。
为简化说明，本公开实施例中将上述文件处理方法应用于车载监控设备，图1是根据本公开实施例示出的一种车载监控设备的文件处理方法的流程示意图。参见图1，该车载监控设备的文件处理方法，包括：
在步骤101，若检测到本地存储空间中被占用空间的大小大于或者等于第一存储阈值，获取所述本地存储空间内每个文件的加锁权重值。
本实施例中，第一存储阈值预先存储在车载监控设备中，例如本地存储空间的大小为 100GB，则第一存储阈值可以为90GB、80GB等。另外，该第一存储阈值还可以是占用本地存储空间的百分比，例如，90％、80％等。本领域技术人员可以根据具体场景设置第一存储阈值的形式，可以理解的是，在第一存储阈值为百分比时，还需要对其进行转换，在此不再说明。
首先，获取当前时刻本地存储空间的被占用空间的大小，可以由处理器主动向本地存储空间查询，也可以由本地存储空间实时或者定时向处理器发送，同样可以实现本实施例的方案，在此不再限定。
然后，将被占用空间的大小与第一存储阈值直接进行比较。当然，也可以计算被占用空间的大小与本地存储空间的最大值的比例值，之后将该比例值与第一存储阈值进行比较。
再者，在被占用空间的大小小于第一存储阈值时，继续上述获取和比较过程。在被占用空间的大小大于或者等于第一存储阈值时，则获取本地存储空间内每个文件的加锁权重值。
需要说明的是，上述加锁权重值为对应各文件的权重标识的数值，例如1～N，该加锁权重值用于指示对应文件的重要程度。例如，第一级采用数字“1”表示，第二等级采用数字“2”表示，第三等级采用数值“3”表示，以此类推。可理解为，若加锁权重值为“1”，则表示文件非常重要；若加锁权重值为“2”，则表示文件重要；加锁权重值为“3”，则表示文件重要程度一般；加锁权重值为“4”，则表示文件不重要；加锁权重值为“5”，则表示文件为垃圾文件，可以根据具体场景设置加锁权重值的等级以及数值。当然，加锁权重值与数值之间也可以正相关，即数值越大，则表示加锁权重值越大，等级越高。本领域技术人员可以根据具体场景进行设置。
上述加锁权重值的等级和数值可以由驾驶员进行设置，也可以根据车载监控设备所处场景进行确定，在此先不作说明，后续实施例会详细描述。
后续各实施例中，以加锁权重值的数值越小且文件的等级越高越重要的示例进行说明。
在步骤102，根据所述加锁权重值删除相应的文件。
本实施例中，按照加锁权重值的大小或者等级对各文件进行排序，从大到小或者从小到大。在一实施例中，按照加锁权重值大小的顺序对文件排序。然后依次删除加锁权重值较大(等级低)的文件，直至本地存储空间中被占用空间的大小小于第一存储阈值。
本实施例中在检测到本地存储空间中被占用空间的大小大于或者等于第一存储阈值，获取所述本地存储空间内每个监控数据的加锁权重值；根据所述加锁权重值处理所述监控数据。可见，本实施例中可以根据加锁权重值对监控数据进行处理，这样可以保留权重值较大的监控数据，即可以不删除相对重要的监控数据，有利于后续路况查询以及证据采集，提升用户使用体验。
为解决人为设置的加锁权重值不准确的问题，本实施例中基于车载监控设备所处场景确定加锁权重值，图2是根据本公开实施例的一种车载监控设备的文件处理方法的流程示意图。参见图2，该车载监控设备的文件处理方法，包括：
在步骤201，确定车载监控设备所处场景。
实际应用中，车辆上的设定位置设置有传感设备。例如传感设备包括以下至少一种：加速度传感设备、盲点监测设备、疲劳检测设备、行人检测设备、速度传感器、图像采集设备和交互设备。
本实施例中，车载监控设备接收车辆上各传感设备采集的车辆环境参数。例如，加速度传感器设备可以实时或定时检测车辆的加速度；盲点监测设备可以实时或定时获取车辆的盲点区域的音频和视频的数据；疲劳检测设备可以实时或定时检测驾驶员的生理参数以确定其是否处于疲劳状态；行人检测设备可以实时或定时检测车辆周围是否存在行人；速度传感器可以实时或定时检测车辆的速度；图像采集设备可以实时或定时检测车辆前方的红绿灯；交互设备可以获取用户的触发动作以触发文件加锁。
上述各传感器设备可以根据具体场景进行组合或者调整，从而可以接收到不同的车辆环境参数。
本实施例中，根据车辆环境参数与场景的匹配关系，可以根据车辆环境参数确定车载监控设备所处的场景。
在步骤202，基于所述场景，根据场景加锁策略确定当前文件的加锁权重值。
本实施例中，在获取到场景后，可以根据场景加锁策略确定当前文件的加锁权重值，包括：
若场景为盲点监测设备报警，则确定加锁权重值为第一级；
若场景为加速度传感器设备检测车辆加速度超过加速度阈值，则确定加锁权重值为第 一级；
若场景为疲劳检测设备检测到驾驶员疲劳驾驶，则确定加锁权重值为第一级；
若场景为交互设备检测到驾驶员主动加锁，则确定加锁权重值为第一级；
若场景为行人检测设备检测到车辆设定范围内有行人，则确定加锁权重值为第二级；
若场景为速度传感器检测到车辆超速行驶，则确定加锁权重值为第二级；
若场景为图像采集设备检测到车辆在设定环境下行驶，则确定加锁权重值为第二级；
若场景为图像采集设备检测到红绿灯，则确定加锁权重值为第三级；
若场景为图像采集设备检测到车辆压线行驶，则确定加锁权重值为第三级；
若场景为除上述各场景外的其他情况，则确定权重值为第四级。
本实施例中仅介绍了部分场景和加锁权重值的情况，技术人员可以根据传感设备中的多个传感器进行组合，从而得到多个限制条件对应的场景。在对应场景的基础上，对加锁权重值的等级进行细分。可理解的是，无论如何组合或者调整，同样可以实现本实施例的方案。
本实施例中，车载监控设备基于确定的加锁权重值采集音视频等文件，并存储至本地存储空间中。
需要说明的是，由于车辆行进过程中速度通常位于10～80Km/h之间，即车辆每秒移动约0～20米，由于每个场景对应相应的时间段或者地点，例如，红绿灯仅在于几十米的范围内，车辆驶过后则场景已经过去；又如，车辆之前有行人，行人距离车辆10米之内为危险场景，如果车辆先过则耗时可能为几秒，若行人先过，则耗时可能为十几秒。为保证场景的实时性，在一实施例中，在确定加锁权重值时刻后的预设时间段内，车载监控设备采用该加锁权重值对文件进行存储。上述预设时间段可以根据不同的场景进行调整。
例如，在确定场景为驾驶员疲劳驾驶时，则确定加锁权重值为第一级，上述预设时间段可以设置为5分钟，然后计时过程中以第一级对应的加锁权重值存储文件，在计时完成后执行后一场景的存储工作。后一场景可以在计时过程中或者计时完成后获取，本实施例不作限定。
又如，在确定场景为车辆压线行驶时，则确定加锁权重值为第三级，上述预设时间段可以设置为30秒，然后计时时，以第三级对应的加锁权重值存储文件。在计时完成后执行 后一场景的存储工作。
另外，若计时期间持续获取场景，且后一场景的加锁权重值高于当前场景的加锁权重值，则切换到后一场景，即采用新的加锁权重值存储文件。
在步骤2031，检测到本地存储空间中被占用空间的大小是否大于或者等于第一存储阈值。如果小于第一存储阈值，继续执行步骤201和步骤202。在大于或者等于第一存储阈值时，执行步骤2032。
在步骤2032，在获取所述本地存储空间内每个文件的加锁权重值。
其中步骤2031和步骤2032构成步骤203，该步骤203和步骤101的具体方法和原理一致，详细描述请参考图1及步骤101的相关内容，此处不再赘述。
在步骤204，根据所述加锁权重值删除相应的文件。
其中步骤204和步骤102的具体方法和原理一致，详细描述请参考图1及步骤102的相关内容，此处不再赘述。
本实施例中根据车辆上的传感设备可以确定车辆所处场景(即车载监控设备所处场景)，然后根据场景确定车载监控设备采集文件的加锁权重值，这样可以保证文件的加锁权重值与场景相对应，从而准确获取到关键性文件，有利于后续的删除效率以及准确度，提升用户的使用效率。
图3是根据本公开又一实施例的车载监控设备的文件处理方法的流程示意图。参见图3，该车载监控设备的文件处理方法，包括：
在步骤301，若检测到本地存储空间中被占用空间的大小大于或者等于第一存储阈值，获取所述本地存储空间内每个文件的加锁权重值。
其中步骤301和步骤101的具体方法和原理一致，详细描述请参考图1及步骤101的相关内容，此处不再赘述。
在步骤302，获取所述本地存储空间内每个文件的录制时间。
考虑到按照加锁权重值对文件进行排序时，会存在排序相同(即加锁权重值相同)，但是文件的录制时间不同的情况。为此，本实施例中，在检测到本地存储空间中被占用空间的大小大于或者等于第一存储阈值时，还获取各个文件的录制时间。
可理解的是，由于本地存储空间中可能存在手动存储文件的情况，为此上述录制时间 还可以调整为存储时间。即上述录制时间可以调整为任意一个时间参考系下的时间值，在此不再详细说明。
需要说明的是，步骤302和步骤301中获取每个文件的加锁权重值的顺序不作限定，可以先于录制时间获取加锁权重值，可以先于加锁权重值获取录制时间，还可以同时获取录制时间和加锁权重值。
在步骤303，根据所述加锁权重值和所述录制时间删除相应的文件。
本实施例中，基于加锁权重值和录制时间删除相应的文件，包括：
方式一：首先，按照加锁权重值的大小对文件进行排序。在排序过程中，相同加锁权重值的文件按照时间先后顺序进行排序。然后控制加锁权重值的顺序从大到小删除文件，在多个文件对应同一个加锁权重值时，从录制时间最早的文件开始删除，直至本地存储空间的大小小于第一存储阈值。
方式二：参见图4，在步骤401，基于加锁权重值和加锁得分值的匹配关系，根据加锁权重值确定文件的加锁得分值。
其中加锁权重值和加锁得分值的匹配关系可以预先设置在车载监控设备中。例如，加锁权重值为数值“1”，加锁得分值为50；加锁权重值为数值“2”，加锁得分值为40；加锁权重值为数值“3”，加锁得分值为30；加锁权重值为数值“4”，加锁得分值为20；加锁权重值为数值“5”，加锁得分值为10，依次类推。
在确定加锁权重值之后，可以根据上述匹配关系得到文件的加锁得分值。
在步骤402，基于所述录制时间和时间得分值的匹配关系，根据所述录制时间确定所述文件的时间得分值。
其中录制时间和时间得分值的匹配关系可以预先设置在车载监控设备中。例如，将所存储文件对应的最早录制时间和最近录制时间之间的时间段划分为多个时间段，每个时间段对应一个时间得分值。可理解的是，录制时间越早，对应的时间得分值越小。例如，若录制时间为10天前，则时间得分值为0；录制时间为8天前，则时间得分值为10；若录制时间为6天前，则时间得分值为20；若录制时间为4天前，则时间得分值为30；若录制时间为2天前，则时间得分值为40；若录制时间为2天内，则时间得分值为50；若录制时间为0-24小时，则时间得分值为60；以此类推。然后在获取到文件的录制时间后，即可确定 该录制时间位于哪个时间段，从而得到对应的时间得分值。
需要说明的是，上述时间得分值和加锁得分值需要对应调整到同一个数量级下，从而体现两者具有相同的重要程度。
在步骤403，根据所述加锁得分值和所述时间得分值确定所述文件的重要度分值。
本实施例中，可以直接将加锁得分值和时间得分值计算到文件的重要度分值。当然，还可以根据具体场景分别为加锁得分值和时间得分值设置权重系数，从而得到不同重要程度下的重要度分值。
在步骤404，删除所述重要度分值小于或者等于重要度阈值的文件以及保存所述重要度分值大于所述重要度阈值的文件。
可见，本实施例中结合加锁权重值和录制时间可以删除加锁权重值大且录制时间早的文件，从而保留下加锁权重值较小且录制时间较近的文件。这样，不但可以保证本地存储空间有足够的剩余空间，还可以保证所存储的文件都是比较重要文件，有利于后续路况查询以及证据采集，提升用户使用体验。
图5是根据本公开又一实施例的车载监控设备的文件处理方法的流程示意图。参见图5，该车载监控设备的文件处理方法，包括：
在步骤501，若检测到本地存储空间中被占用空间的大小大于或者等于第一存储阈值，获取所述本地存储空间内每个文件的加锁权重值。
其中步骤501和步骤101的具体方法和原理一致，详细描述请参考图1及步骤101的相关内容，此处不再赘述。
在步骤502，根据所述加锁权重值删除相应的文件。
其中步骤502和步骤102的具体方法和原理一致，详细描述请参考图1及步骤102的相关内容，此处不再赘述。
在步骤503，若所述本地存储空间中被占用空间的大小大于或者等于第二存储阈值，则按照重要度分值从小到大的顺序删除保存的文件，直至所述被占用空间的大小小于或者等于所述第二存储阈值；所述第二存储阈值小于所述第一存储阈值。
实际应用中，由于每次删除文件的过程会占用车载监控设备的系统资源，使车载监控设备运行缓慢甚至死机，因此需要降低删除文件的频率或者在车辆停止时删除文件，此时 需要每一次删除文件时都尽可能多的删除文件，这样可以提升车载监控设备的性能。
本实施例中删除文件的方式可以参考步骤102和附图2的内容，在此不再详细说明。即每一次删除文件时，直至本地存储空间中被占用空间的大小小于第二存储阈值为止。
上述第二存储阈值的设置方式可以参考第一存储阈值的设置方式，并且第二存储阈值小于第一存储阈值。例如本地存储空间的大小为100GB，则第一存储阈值可以为90GB，则第二存储阈值可以为80GB或者更少。
考虑到每辆车辆的行驶频率不同，使得本地存储空间中文件占用空间的增长速率发生变化，从而导致车载监控设备删除文件的频率会发生变化。为此，本实施例中还结合存储空间的增长速率对第二存储阈值进行调整，包括：
获取本地存储空间中文件占用空间的增长速率；
根据增长速率调整所述第二存储阈值；增长速率和所述第二存储阈值成负比例。
例如，在第一时间本地存储空间的被占用空间的大小为85GB，在第二时间本地存储空间的被占用空间的大小为86GB，则第一时间与第二时间段内，占用空间的增长速率为1GB/单位时间。该增长速率大于设定阈值，此时可以调整第二存储阈值，将第二存储阈值从80GB调至75GB。又如，占用空间的增长速度为2GB/单位时间时，由于增长速率大于设定阈值，此时可以调整第二存储阈值，将第二存储阈值从80GB调至70GB，以此类推。若增长速率小于设定阈值，则不调整第二存储阈值。
当然，步骤501和步骤502对应的方案还可以采用步骤301～步骤303对应的方案替代，在此不再详细说明。
本实施例中考虑到每辆车辆的行驶频率以及增长速率，设置第二存储阈值以及调整该第二存储阈值，从而调整删除文件的频率，保证本地存储空间具有足够大的空间来存储文件，同时还可以保证车载监控设备中系统和软件的运行效率。
图6是根据本公开又一实施例的车载监控设备的文件处理方法的流程示意图。参见图6，该车载监控设备的文件处理方法，包括：
在步骤601，若检测到本地存储空间中被占用空间的大小大于或者等于第一存储阈值，获取所述本地存储空间内每个文件的加锁权重值。
其中步骤601和步骤101的具体方法和原理一致，详细描述请参考图1及步骤101的 相关内容，此处不再赘述。
在步骤602，根据所述加锁权重值删除相应的文件。
其中步骤602和步骤102的具体方法和原理一致，详细描述请参考图1及步骤102的相关内容，此处不再赘述。
在步骤603，判断所述车载监控设备与云端是否通信。
本实施例中，车载监控设备可以实时或者定时向云端发送建立链接请求，若在规定的时间内，该车载监控设备未接收到与建立链接请求相匹配的响应信息，则确定无法与云端通信。然后车辆监控设备继续发送链接请求。
若在规定的时间内，该车载监控设备接收到与建立链接请求相匹配的响应信息，则确定可以与云端通信。
在步骤604，响应于判断所述车载监控设备与云端通信，则按照重要度分值从大到小的顺序将保存的文件上传至所述云端。
之后，按照重要度分值从大到小的顺序将保存的文件上传到云端。当然还可以按照加锁权重值的等级将保存的文件上传到云端。
将本地存储空间内的文件全部上传至云端，或者仅最近更新的文件上传至云端。在每个文件上传成功后，同时可以删除该文件，从而降低本地存储空间的使用率。
本实施例中在车载监控设备确定可以与云端通信时将存储的文件上传至云端，从而可以对关键文件进行存储，后续路况查询以及证据采集，提升用户使用体验。
图7是根据本公开实施例的车载监控设备的文件处理装置的框图。参见图7，该车载监控设备的文件处理装置700包括：
存储空间检测模块701，用于检测到本地存储空间中被占用空间的大小是否大于或者等于第一存储阈值，并在检测结果为大于或者等于时向权重值获取模块发送触发信号；
所述权重值获取模块702，用于在接收到来自所述存储空间检测模块的触发信号时，获取所述本地存储空间内每个文件的加锁权重值；
文件删除模块703，用于根据所述加锁权重值删除相应的文件。
参见图8，在图7所示文件处理装置的基础上，所述装置700还包括：
场景确定模块801，用于确定车载监控设备所处场景；
权重值确定模块802，用于基于所述场景，根据场景加锁策略确定当前文件的加锁权重值。
参见图9，在图8所示文件处理装置的基础上，场景确定模块801包括：
参数接收单元901，用于接收车辆上各传感设备采集的车辆环境参数；
场景确定单元902，用于基于环境参数与场景的匹配关系，根据所述车辆环境参数确定所述车载监控设备所处场景。
可选地，所述传感设备包括以下至少一种：加速度传感设备、盲点监测设备、疲劳检测设备、行人检测设备、速度传感器、图像采集设备和交互设备。
图10是根据本公开实施例的车载监控设备的文件处理装置的框图。在图7所示文件处理装置的基础上，参见图10，所述装置700包括：
时间获取模块1001，用于获取所述本地存储空间内每个文件的录制时间；
所述文件删除模块703，还用于根据所述加锁权重值和所述录制时间删除相应的文件。
参见图11，在图10所示的文件处理装置的基础上，所述文件删除模块703包括：
加锁得分值确定单元1101，用于基于所述加锁权重值和加锁得分值的匹配关系，根据所述加锁权重值确定所述文件的加锁得分值；
时间得分值确定单元1102，用于基于所述录制时间和时间得分值的匹配关系，根据所述录制时间确定所述文件的时间得分值；
重要度分值确定单元1103，用于根据所述加锁得分值和所述时间得分值确定所述文件的重要度分值；
文件删除单元1104，用于删除所述重要度分值小于或者等于重要度阈值的文件以及保存所述重要度分值大于所述重要度阈值的文件。
可选地，所述文件处理装置还包括：
存储空间检测模块还用于检测所述本地存储空间中被占用空间的大小是否大于或者等于第二存储阈值，并在检测结果为大于或者等于时向所述文件删除模块发送触发信号；
所述文件删除模块还用于按照重要度分值从小到大的顺序删除保存的文件，直至所述被占用空间的大小小于或者等于所述第二存储阈值；
所述第二存储阈值小于所述第一存储阈值。
图12是根据本公开实施例的车载监控设备的文件处理装置的框图。在图7所示文件处理装置的基础上，参见图12，所述文件处理装置700包括：
增长速率获取模块1201，用于获取所述本地存储空间中文件占用空间的增长速率；
存储阈值调整模块1202，用于根据所述增长速率调整所述第二存储阈值；所述增长速率与所述第二存储阈值成负比例。
图13是根据本公开实施例的车载监控设备的文件处理装置的框图。在图7所示文件处理装置的基础上，参见图13，所述文件处理装置700包括：
通信判断模块1301，用于判断所述车载监控设备与云端是否通信，并在通信时发送触发信号；
所述文件上传模块1302，用于在接收到来自所述通信判断模块的触发信号时按照重要度分值从大到小的顺序将保存的文件上传至所述云端。
图14是本公开实施例的车载监控设备的结构示意图。参见图14，该车载监控设备1400包括：
处理器1401；
用于存储所述处理器可执行指令和文件的存储器1402；
其中，所述处理器1401被配置为执行所述存储器1402中可执行指令以实现上述各文件删除方法的步骤。
在本公开中，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性。术语“多个”指两个或两个以上，除非另有明确的限定。
本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。
应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (18)

  1. 一种车载监控设备的文件处理方法，包括：
    若检测到本地存储空间中被占用空间的大小大于或者等于第一存储阈值，获取所述本地存储空间内每个文件的加锁权重值；以及
    根据所述加锁权重值删除相应的文件。
  2. 根据权利要求1所述的文件处理方法，其中，获取所述本地存储空间内每个文件的加锁权重值之前，所述方法还包括：
    确定车载监控设备所处场景；以及
    基于所述场景，根据场景加锁策略确定加锁权重值。
  3. 根据权利要求2所述的文件处理方法，其中，确定车载监控设备所处场景包括：
    接收车辆上各传感设备采集的车辆环境参数；以及
    基于环境参数与场景的匹配关系，根据所述车辆环境参数确定所述车载监控设备所处场景。
  4. 根据权利要求3所述的文件处理方法，其中，所述传感设备包括以下至少一种：加速度传感设备、盲点监测设备、疲劳检测设备、行人检测设备、速度传感器、图像采集设备和交互设备。
  5. 根据权利要求1所述的文件处理方法，还包括：
    获取所述本地存储空间内每个文件的录制时间，
    其中，根据所述加锁权重值删除相应的文件包括：
    根据所述加锁权重值和所述录制时间删除相应的文件。
  6. 根据权利要求5所述的文件处理方法，其中，根据所述加锁权重值和所述录制时间删除相应的文件包括：
    基于所述加锁权重值和加锁得分值的匹配关系，根据所述加锁权重值确定所述文件的加锁得分值；
    基于所述录制时间和时间得分值的匹配关系，根据所述录制时间确定所述文件的时间得分值；
    根据所述加锁得分值和所述时间得分值确定所述文件的重要度分值；以及
    删除所述重要度分值小于或者等于重要度阈值的文件以及保存所述重要度分值大于所述重要度阈值的文件。
  7. 根据权利要求6所述的文件处理方法，保存所述重要度分值大于所述重要度阈值的文件之后，所述方法还包括：
    若所述本地存储空间中被占用空间的大小大于或者等于第二存储阈值，则按照重要度分值从小到大的顺序删除保存的文件，直至所述被占用空间的大小小于或者等于所述第二存储阈值，
    其中，所述第二存储阈值小于所述第一存储阈值。
  8. 根据权利要求7所述的文件处理方法，根据所述加锁权重值和所述录制时间删除相应的文件之后，所述方法还包括：
    获取所述本地存储空间中文件占用空间的增长速率；以及
    根据所述增长速率调整所述第二存储阈值，
    其中，所述增长速率与所述第二存储阈值成负比例。
  9. 根据权利要求6所述的文件处理方法，根据所述加锁权重值删除相应的文件之后，所述方法还包括：
    判断所述车载监控设备与云端是否通信；以及
    响应于判断所述车载监控设备与云端通信，按照重要度分值从大到小的顺序将保存的文件上传至所述云端。
  10. 一种车载监控设备包括：
    一个或多个处理器；以及
    一个或多个存储器，与所述一个或多个处理器连接，并存储有指令，所述指令在所述一个或多个处理器上运行时使所述一个或多个处理器被配置为：
    若检测到本地存储空间中被占用空间的大小大于或者等于第一存储阈值，获取所述本地存储空间内每个文件的加锁权重值；以及
    根据所述加锁权重值删除相应的文件。
  11. 根据权利要求10所述的车载监控设备，其中，所述一个或多个处理器还被配置为：
    确定车载监控设备所处场景；以及
    基于所述场景，根据场景加锁策略确定加锁权重值。
  12. 根据权利要求11所述的车载监控设备，其中，所述一个或多个处理器还被配置为：
    接收车辆上各传感设备采集的车辆环境参数；以及
    基于环境参数与场景的匹配关系，根据所述车辆环境参数确定所述车载监控设备所处场景。
  13. 根据权利要求12所述的车载监控设备，其中，所述传感设备包括以下至少一种：加速度传感设备、盲点监测设备、疲劳检测设备、行人检测设备、速度传感器、图像采集设备和交互设备。
  14. 根据权利要求10所述的车载监控设备，其中，所述一个或多个处理器还被配置为：
    获取所述本地存储空间内每个文件的录制时间；以及
    根据所述加锁权重值和所述录制时间删除相应的文件。
  15. 根据权利要求14所述的车载监控设备，其中，所述一个或多个处理器还被配置为：
    基于所述加锁权重值和加锁得分值的匹配关系，根据所述加锁权重值确定所述文件的加锁得分值；
    基于所述录制时间和时间得分值的匹配关系，根据所述录制时间确定所述文件的时间得分值；
    根据所述加锁得分值和所述时间得分值确定所述文件的重要度分值；以及
    删除所述重要度分值小于或者等于重要度阈值的文件以及保存所述重要度分值大于所述重要度阈值的文件。
  16. 根据权利要求15所述的车载监控设备，其中，所述一个或多个处理器还被配置为：
    若所述本地存储空间中被占用空间的大小是否大于或者等于第二存储阈值，按照重要度分值从小到大的顺序删除保存的文件，直至所述被占用空间的大小小于或者等于所述第二存储阈值，
    其中，所述第二存储阈值小于所述第一存储阈值。
  17. 根据权利要求16所述的车载监控设备，其中，所述一个或多个处理器还被配置为：
    获取所述本地存储空间中文件占用空间的增长速率；以及
    根据所述增长速率调整所述第二存储阈值；所述增长速率与所述第二存储阈值成负比例。
  18. 根据权利要求15所述的车载监控设备，其中，所述一个或多个处理器还被配置为：
    判断所述车载监控设备与云端是否通信；以及
    响应于判断所述车载监控设备与云端通信，按照重要度分值从大到小的顺序将保存的文件上传至所述云端。
PCT/CN2018/102256 2018-01-19 2018-08-24 车载监控设备的文件处理方法和车载监控设备 WO2019140906A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/469,802 US20200379954A1 (en) 2018-01-19 2018-08-24 File processing method for vehicle mounted monitoring device and vehicle mounted monitoring device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810055037.2A CN108280902A (zh) 2018-01-19 2018-01-19 车载监控设备的文件处理方法及装置、车载监控设备
CN201810055037.2 2018-01-19

Publications (1)

Publication Number Publication Date
WO2019140906A1 true WO2019140906A1 (zh) 2019-07-25

Family

ID=62804267

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/102256 WO2019140906A1 (zh) 2018-01-19 2018-08-24 车载监控设备的文件处理方法和车载监控设备

Country Status (3)

Country Link
US (1) US20200379954A1 (zh)
CN (1) CN108280902A (zh)
WO (1) WO2019140906A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114844779A (zh) * 2022-04-22 2022-08-02 重庆长安汽车股份有限公司 一种车机系统性能监控及改进方法和系统

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108280902A (zh) * 2018-01-19 2018-07-13 京东方科技集团股份有限公司 车载监控设备的文件处理方法及装置、车载监控设备
CN109308748A (zh) * 2018-08-01 2019-02-05 福建省汽车工业集团云度新能源汽车股份有限公司 一种保存车辆事故原因的方法及系统
CN109388624A (zh) * 2018-10-09 2019-02-26 郑州云海信息技术有限公司 分布式文件删除方法、装置、系统及计算机可读存储介质
CN109830002A (zh) * 2019-01-23 2019-05-31 征辕科技(宁波)有限公司 行车事件数据记录方法、装置及事件数据记录器
CN112419537A (zh) * 2019-08-22 2021-02-26 合肥杰发科技有限公司 影像存储方法、行车记录仪及具有存储功能的装置
CN114677782A (zh) * 2020-12-24 2022-06-28 北京百度网讯科技有限公司 信息处理方法、装置、电子设备及存储介质
CN112925478B (zh) * 2021-01-29 2022-10-25 惠州Tcl移动通信有限公司 相机存储空间控制方法、智能终端及计算机可读存储介质
CN114333099B (zh) * 2021-12-10 2023-12-05 华人运通(上海)云计算科技有限公司 一种车辆使用工况的监控方法、装置和车辆
CN116932793A (zh) * 2022-04-08 2023-10-24 鸿海精密工业股份有限公司 用于视觉检测的数据删除方法、装置、设备及存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1691007A (zh) * 2004-04-22 2005-11-02 惠普开发有限公司 用于文档处理的方法、系统或存储计算机程序的存储器
CN101506893A (zh) * 2006-08-21 2009-08-12 大陆汽车有限责任公司 对电子电路中的数据存储器的访问进行控制的方法和装置
CN102289642A (zh) * 2010-06-04 2011-12-21 I+Me阿克蒂亚计算机和微电子有限公司 用于读取数据的读取装置与系统
CN103685449A (zh) * 2012-09-07 2014-03-26 佳能株式会社 信息处理装置及控制方法
CN103955421A (zh) * 2014-05-06 2014-07-30 珠海市君天电子科技有限公司 一种针对文件删除的方法及系统
CN105095252A (zh) * 2014-05-06 2015-11-25 腾讯科技（深圳）有限公司 一种文件管理方法和系统
CN108280902A (zh) * 2018-01-19 2018-07-13 京东方科技集团股份有限公司 车载监控设备的文件处理方法及装置、车载监控设备

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5530146B2 (ja) * 2009-09-30 2014-06-25 富士通テン株式会社 データ管理装置、データ読取方法及びプログラム
JP6378066B2 (ja) * 2014-11-27 2018-08-22 クラリオン株式会社 情報処理装置および実行管理プログラム
CA2976344A1 (en) * 2015-02-10 2016-08-18 Mobileye Vision Technologies Ltd. Sparse map for autonomous vehicle navigation
CN105046763B (zh) * 2015-07-08 2017-08-29 广东翼卡车联网服务有限公司 一种多存储行车信息记录的系统及方法
CN106027934A (zh) * 2016-07-13 2016-10-12 深圳市爱培科技术股份有限公司 一种基于后视镜的车辆行车录像存储方法及系统
CN106296875A (zh) * 2016-08-16 2017-01-04 湖南纽思曼导航定位科技有限公司 一种行车记录仪及存储方法

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1691007A (zh) * 2004-04-22 2005-11-02 惠普开发有限公司 用于文档处理的方法、系统或存储计算机程序的存储器
CN101506893A (zh) * 2006-08-21 2009-08-12 大陆汽车有限责任公司 对电子电路中的数据存储器的访问进行控制的方法和装置
CN102289642A (zh) * 2010-06-04 2011-12-21 I+Me阿克蒂亚计算机和微电子有限公司 用于读取数据的读取装置与系统
CN103685449A (zh) * 2012-09-07 2014-03-26 佳能株式会社 信息处理装置及控制方法
CN103955421A (zh) * 2014-05-06 2014-07-30 珠海市君天电子科技有限公司 一种针对文件删除的方法及系统
CN105095252A (zh) * 2014-05-06 2015-11-25 腾讯科技（深圳）有限公司 一种文件管理方法和系统
CN108280902A (zh) * 2018-01-19 2018-07-13 京东方科技集团股份有限公司 车载监控设备的文件处理方法及装置、车载监控设备

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114844779A (zh) * 2022-04-22 2022-08-02 重庆长安汽车股份有限公司 一种车机系统性能监控及改进方法和系统

Also Published As

Publication number Publication date
US20200379954A1 (en) 2020-12-03
CN108280902A (zh) 2018-07-13

Similar Documents

Publication Publication Date Title
WO2019140906A1 (zh) 车载监控设备的文件处理方法和车载监控设备
US20210191979A1 (en) Distributed video storage and search with edge computing
JP6499514B2 (ja) ドライブレコーダ、データ記録システム、データ記録方法、及び、プログラム
US20180359445A1 (en) Method for Recording Vehicle Driving Information and Creating Vehicle Record by Utilizing Digital Video Shooting
US20180152517A1 (en) Methods and apparatus to adaptively manage data collection devices in distributed computing systems
CN110728218A (zh) 危险驾驶行为的预警方法、装置、电子设备及存储介质
US11479260B1 (en) Systems and methods for proximate event capture
CN105788269A (zh) 基于无人机的异常交通识别方法
CN112997227A (zh) 交通辅助系统、服务器及方法、车载装置及其动作方法、计算机程序、记录介质、计算机及半导体集成电路
CN105590479A (zh) 车位监测方法和装置
US10785404B2 (en) Information processing method, information processing apparatus, and non-transitory recording medium
TWI729461B (zh) 行車記錄器與狀況資訊管理系統
JPWO2019207796A1 (ja) ドライブレコーダ情報提供システム、ドライブレコーダ情報提供方法、プログラム、およびドライブレコーダ
KR102311805B1 (ko) 딥러닝 기반 차량 및 인체 자동 감지용 영상 모니터링 방법 및 이를 이용한 데이터 전송 방법
US20200312050A1 (en) Control device, server, safety system, and control method of control device
JP2018173291A (ja) 検出装置、検出方法及びプログラム
WO2020258720A1 (zh) 图像采集设备遮挡状态检测方法、装置、设备和存储介质
WO2019146488A1 (ja) 運転状況監視装置、運転状況監視方法、および運転状況監視システム
US20210056329A1 (en) Driving state monitoring device, driving state monitoring system, driving state monitoring method and recording medium
JP2002190013A (ja) 画像認識による渋滞検知システム及び渋滞検知方法
CN113470314A (zh) 一种疲劳预警控制方法、装置、设备及汽车
JP2020194206A (ja) 学習方法、運転支援方法、学習プログラム、運転支援プログラム、学習装置、運転支援システム及び学習システム
CN116052334A (zh) 共享车辆的还车方法、系统及相关设备
EP4167193A1 (en) Vehicle data collection system and method of using
US20180362050A1 (en) Mobile object management apparatus, mobile object management method, and storage medium

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18901210

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 26/11/2020)

122 Ep: pct application non-entry in european phase

Ref document number: 18901210

Country of ref document: EP

Kind code of ref document: A1