¿Database o no database? Ese es el dilema… hasta ahora!

Introducción

Hace algún tiempo que vengo programando sistemas embebidos industriales. Algunos de gama media y otros de gama alta. El desafío en mi caso, es que al trabajar en adquisición de datos (que es básicamente el mayor uso que se les da a estás plataformas) es poder resguardar los datos para poder darles cierta integridad y fiabilidad. Aunque existen pseudo-motores de base de datos estos presentan una serie de inconvenientes al momento de portarlos a sistemas operativos no convencionales (diferentes RTOS) para poder utilizarlos. Si bien nos encontramos con muy buenas opciones como lo es Sqlite o Itzam, estás presentan las desventajas, en algunos casos como el que nos ocupa, de ser demasiado excedidas en virtudes al momento de portarlas para nuestras necesidades.

Problema

Los pseudo-motores de base de datos requieren mucho esfuerzo y conocimiento al momento de portarlos a sistemas embebidos con RTOS no convencionales. Por lo general sólo necesitamos almacenar datos de forma secuencial, o sea, el 90% de los sistemas de adquisición de datos simples sólo almacenan como clave el tiempo y luego las variables y unidades que utilizan. Esto hace que los pseudo-motores sean demasiado completos para implementar con este modelo de trabajo. Sin embargo, requerimos una estructura de almacenamiento organizada y que nos permita algunas de las ventajas que presentan las base de datos embebidas.

Propuesta

Actualmente trabajo en un hìbrido, parte Flatfile Database, parte Embeddeb Database. La idea es desarrollar un pequeño mecanismo de almacenamiento sequencial que posee una serie de caracterìsticas:

  • Pequeño  footprint.
  • Soporte para 32 bits (por el momento).
  • Linux/POSIX, ThreadX (Incluyendo NET+OS 7.5 >=).
  • Sin utilizaciòn de un servidor.
  • Completamente embebible.
  • Sin configuracciòn.
  • Relativamente flexible.
  • Detecciòn de errores (CRC32).
  • Escrita en ANSI/C.
  • Desarrollado para almacenamiento en medios electrònicos (memorias FLASH).

Este trabajo principalmente esta siendo testeado bajo x86 GNU/Linux y ARM9 ThreadX. En un futuro tambien quiero lograr probarlo bajo sistemas con Cortex-M0.

Pero… ¿Para que sirve?

Sencillo de contestar, si estamos tomando datos a un tiempo regular y requerimos almacenarlo de forma de dar confiabilidad a la adquisiciòn còmo asì luego poder recuperar de forma sencilla los datos; y ademàs se necesite implementar muy fàcilmente, ¡Sirve!

Prestaciones

En mi caso, luego de leer e informarme mucho, necesito que pueda:

  • Almacenar datos de forma segura.
  • Muy fàcil implementaciòn bajo ThreadX y procesadores ARM‘s.
  • Tolerancia a fallos alta.
  • Rapidez en la ejecuciòn.
  • Y que se entienda…

¿Pido mucho?

Algunas funciones

/**** Prototypes ****/
int db_create(struct db_id_struct *db_id, struct db_header_struct *db_header);
int db_open(struct db_id_struct *db_id, struct db_header_struct *db_header);
int db_close(struct db_id_struct *db_id);
int db_save(struct db_id_struct *db_id, struct db_data_struct *db_element);
int db_query(struct db_id_struct *db_id, struct db_data_struct *db_element);
int db_lock(struct db_id_struct *db_id);
int db_unlock(struct db_id_struct *db_id);

Que nos depara el futuro…

Subtitulo complicado, en realidad este mecanismo puede llegar a ser ùtil o no para algunos, por lo pronto es totalmente ùtil para mì. Este hìbrido va a funcionar, porque necesariamente lo requiero para una implementaciòn, por lo que voy  a poder dar màs detalles sobre el uso y funcionamiento, asì como los buenos y malos resultados…

Saludos.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s