El héroe anónimo de su cámara de salpicadero con IA: cómo RideView cuida la tarjeta SD

Descubre cómo RideView optimiza el rendimiento de las tarjetas SD en las cámaras de tablero con IA para reducir la fragmentación, prolongar la vida útil de la tarjeta y garantizar una grabación de video fiable.

Por qué la tarjeta SD de tu cámara de tablero se estropea antes de tiempo y cómo lo hemos solucionado

Una cámara de tablero con IA graba de forma continua, pero casi nada de ese metraje sale del dispositivo; solo unos pocos segundos alrededor de un evento marcado se suben a la nube. Todo lo demás reside en la tarjeta SD. Esto convierte a la tarjeta en el almacenamiento principal de la cámara, no en un búfer temporal de paso, y deposita una gran responsabilidad en dos aspectos: la velocidad de escritura de la tarjeta, que limita la cantidad de video, audio y metadatos que la cámara puede grabar de forma fiable, y la rapidez con la que se desgasta, que determina cuánto tiempo sobrevive el hardware en el campo. Ambos dependen de la calidad del hardware de la tarjeta y, lo que es igual de importante, de cómo el software escribe en ella.

Este artículo analiza dos problemas de almacenamiento que determinan la fiabilidad y el coste: la fragmentación y la amplificación de escritura , y cómo la ruta de grabación de RideView está diseñada en torno a ellos.

Pero no hay discos giratorios, ¿por qué iba a importar la fragmentación?

En un disco duro mecánico antiguo, la fragmentación era claramente perjudicial. Un archivo disperso por el plato obligaba al cabezal de lectura a moverse de un lado a otro para reunir sus fragmentos, y ese movimiento era lento. Por eso todos ejecutábamos el "desfragmentador" durante la noche.

Una tarjeta SD no tiene platos, ni cabezales, ni tiempo de búsqueda. Por lo tanto, la conclusión natural es que la fragmentación es un problema resuelto en la memoria flash. Para las lecturas, eso es mayormente cierto. Para escribe, no lo es, y la razón se oculta en dos niveles distintos.

Qué sucede realmente dentro de la tarjeta

Primer nivel: el sistema de archivos (FAT32). Las tarjetas de cámaras de tablero suelen estar formateadas en FAT32, que rastrea cada archivo como una cadena de clústeres de 32 KB en la Tabla de Asignación de Archivos. Cuando esos clústeres están contiguos, el sistema operativo puede mover el archivo en unas pocas transferencias grandes y secuenciales. Cuando están dispersos, no puede: el sistema operativo debe recorrer una larga cadena de clústeres y dividir el trabajo en muchas operaciones de E/S pequeñas y no contiguas, cada una con su propia configuración de comandos, gestión de finalización y búsqueda de metadatos.

Esa sobrecarga no tiene nada que ver con la memoria flash en sí. Más fragmentos simplemente significan más operaciones individuales para mover los mismos bytes, y eso consume tiempo tanto en lecturas como en escrituras.

Segundo nivel: la memoria flash (el FTL). La memoria flash NAND también tiene una limitación física que el sistema de archivos no puede ver:

  • Se escribe en pequeñas páginas.
  • Solo se puede borrar en bloques de borradomucho más grandes.
  • No se puede sobrescribir directamente; cambiar cualquier dato en un bloque de borrado implica leer el bloque, fusionar los datos nuevos, borrarlo y volver a escribirlo todo.

Un controlador llamado Flash Translation Layer (FTL) oculta esto a la cámara. Y aquí está el problema: cuando las escrituras son pequeñas y dispersas, ocupan muchos bloques de borrado solo parcialmente, y el FTL se ve obligado a realizar constantes operaciones de lectura-modificación-escritura y recolección de basura solo para recuperar espacio libre. Todo eso se ejecuta detrás de tu escritura y la ralentiza. Si, en cambio, alimentas la tarjeta con escrituras grandes, secuenciales y contiguas, el FTL llena bloques de borrado completos en una sola pasada, sin necesidad de reorganización.

Por lo tanto, en el almacenamiento flash, la fragmentación no te cuesta tiempo de búsqueda. Cuesta E/S adicional en la capa FAT32 y empuja al FTL de la tarjeta a su modo más lento. Las lecturas evitan ese segundo costo por completo, porque leer nunca activa un borrado o una recolección de basura, que es exactamente la razón por la que la fragmentación penaliza mucho más a las escrituras que a las lecturas.

No queríamos discutir sobre ello, así que lo medimos

La teoría es una cosa; nosotros queríamos una cifra. Realizamos una prueba controlada en una tarjeta FAT32 de 128 GB, llenándola de dos maneras y comparándolas directamente:

  • Fragmentado: muchos escritores ejecutándose en paralelo, cada uno vaciando el búfer con frecuencia, por lo que FAT32 terminó intercalando clústeres entre archivos.
  • Contiguo: un solo escritor grabando un archivo grande a la vez en una tarjeta recién formateada.

Los tamaños de archivo (30–50 MB) y el nivel de llenado fueron idénticos en ambas ocasiones, y vaciamos todas las cachés antes de cada medición. Los dos diseños no podrían haber sido más diferentes:

Esto es lo que eso le hizo al rendimiento:

Las lecturas apenas se inmutaron, tal como predice la teoría de la memoria flash. Pero las escrituras —lo que una cámara de tablero hace cada segundo de cada viaje— fueron aproximadamente un tercio más lentas una vez que los datos se fragmentaron, y la brecha se mantuvo en ejecuciones repetidas.

Una advertencia: las velocidades absolutas son específicas de esta tarjeta y de su estado NAND actual, ya que las tarjetas SD de consumo no admiten TRIM y el desgaste previo afecta al rendimiento bruto. La cantidad significativa y repetible es la brecha *relativa*, y esa es la parte que controla la estrategia de escritura.

Cómo son la mayoría de los flujos de trabajo de las cámaras de salpicadero y lo que eso conlleva

El camino de menor resistencia es dejar que el vídeo, el audio, el GPS, los datos del acelerómetro y los metadatos de IA escriban y vacíen sus datos según su propio calendario. Eso produce exactamente el patrón de escritura que describe el benchmark anterior. Los clústeres terminan dispersos por toda la tarjeta. El FTL se ve forzado a realizar ciclos constantes de lectura-modificación-escritura. Las velocidades de escritura caen un tercio por debajo de la capacidad del hardware. Y tras meses de grabación continua, la amplificación de escritura aumenta: las tarjetas envejecen más rápido de lo que indica su resistencia nominal y fallan antes de lo que los operadores de flotas tienen previsto.

No porque haya algo malo en la tarjeta, sino por cómo la trata el software.

RideView elige el camino más difícil.

Cómo RideView escribe vídeo de la forma correcta

La grabadora de RideView está diseñada para que la fragmentación nunca tenga oportunidad de aparecer. Las decisiones de diseño se corresponden directamente con los puntos anteriores.

El principio parece sencillo: el almacenamiento flash prefiere escrituras grandes y secuenciales. Lo difícil es hacer que una cámara de salpicadero real se comporte así mientras graba múltiples transmisiones en directo, reacciona a eventos y protege las grabaciones ante choques o cortes de energía. 

1. Un archivo multiplexado, no un montón de archivos pequeños.

RideView multiplexa cada transmisión en un único archivo de grabación por segmento de tiempo, escrito como una unidad continua, de modo que la tarjeta recibe un patrón de escritura más limpio: menos escrituras dispersas, menor amplificación de escritura, menos desgaste evitable y una mayor vida útil de la tarjeta.

2. Un único escritor dedicado.

La peor fragmentación en nuestras pruebas provenía de escritores que competían en paralelo. RideView canaliza toda la grabación a través de un hilo de escritura dedicado, por lo que nada compite por el asignador y el sistema de archivos puede colocar los clústeres en largas secuencias contiguas.

3. Escrituras secuenciales, grandes y almacenadas en búfer.

En lugar de realizar muchas escrituras pequeñas, RideView almacena los datos en un búfer y los escribe en bloques grandes, añadiéndolos de forma secuencial en cada archivo; exactamente el patrón que permite al FTL llenar bloques de borrado completos de manera eficiente.

4. Vaciados de búfer periódicos y basados en eventos.

No se pueden perder grabaciones en caso de fallo, pero vaciar el búfer tras cada fotograma dispersaría las escrituras y obligaría al FTL a volver a su ruta lenta. RideView realiza vaciados en intervalos optimizados *y* ante eventos críticos, como una posible colisión, equilibrando la durabilidad con un patrón de escritura limpio. Cada grabación es un segmento delimitado e independiente, por lo que el comportamiento de escritura se mantiene predecible durante todo el trayecto.

Al combinar todo esto, se obtiene el patrón de escritura secuencial, grande y de un solo flujo que ganó la prueba de rendimiento; no por suerte, sino en cada cámara y en cada trayecto.

La mayor ventaja: su tarjeta realmente dura más

Las escrituras más rápidas están bien. La verdadera victoria a largo plazo es el desgaste.

Cada celda de memoria flash solo puede borrarse y reescribirse un número limitado de veces antes de agotarse. Para un dispositivo que graba las 24 horas durante años, la pregunta que realmente importa no es "¿qué tan rápido?", sino "¿cuánto desgaste físico estoy generando por cada gigabyte de video que grabo?". Esa proporción es la amplificación de escritura:

amplificación de escritura = bytes escritos físicamente en la memoria flash / bytes que la aplicación solicitó escribir

Un valor de 1.0 es perfecto: no se desperdicia nada. El comportamiento de lectura-modificación-escritura del FTL es lo que eleva esta cifra: cada vez que la fragmentación o las escrituras dispersas obligan a la tarjeta a reescribir un bloque de borrado medio vacío, se escriben físicamente más datos de los que la aplicación solicitó. Un factor de 2.0 significa que la tarjeta está envejeciendo el doble de rápido de lo que sugeriría su vida útil nominal.

En otras palabras, la amplificación de escritura es simplemente la cara a largo plazo del mismo problema que ralentiza las escrituras. Si optimizas el patrón de escritura, solucionas ambos problemas a la vez.

Cómo se traduce esto en nuestra flota real

Algunas implementaciones de RideView utilizan tarjetas SD que exponen sus propios contadores de estado internos, incluyendo los totales de escritura física frente a la lógica. Esto significa que no necesitamos estimar la amplificación de escritura; podemos leerla directamente de las tarjetas que ya están en uso.

Los datos provienen de una amplia variedad de flotas y vehículos desplegados en cinco continentes. En aproximadamente 4,000 cámaras, incluyendo algunas con casi un año de uso y hasta 14 TB de video grabado, las cifras medidas son las siguientes:

Amplificación de escritura (medida en campo)

El límite teórico es 1.0, por lo que una mediana de flota de 1.01 significa que prácticamente no se desperdicia nada, y eso en tarjetas con meses o años de grabación, no en hardware recién salido de la caja. En la práctica, el patrón de escritura es lo suficientemente limpio como para que la tarjeta SD rara vez sea el factor que limite la vida útil de una cámara.

Por qué esto es importante para usted

La forma en que una cámara de tablero escribe en su tarjeta SD termina determinando tres aspectos que realmente le interesan:

  • Fiabilidad — unas escrituras que siguen el ritmo de las cámaras garantizan que no haya fotogramas perdidos ni interrupciones en sus grabaciones.
  • Margen de maniobra — evitar la penalización de fragmentación de aproximadamente el 33 % deja espacio para más cámaras, mayores tasas de bits y metadatos más completos en el mismo hardware.
  • Coste de propiedad — una amplificación de escritura cercana a 1.01 significa que las tarjetas no se desgastan prematuramente, lo que se traduce en menos fallos y menos reemplazos.

Nada de esto es accidental. Proviene de comprender lo que realmente sucede dentro de una tarjeta flash NAND — más allá de la intuición de que "al no tener piezas móviles, no importa" — y luego escribir vídeo siguiendo el único patrón que el hardware realmente prefiere: de escritura única, grande, secuencial, contiguo y vaciado según un programa lógico.