Log in Page Discussion History Go to the site toolbox

PFC Lab database

From WikIRI

Contents

Integración de datos experimentales en una Wiki para el análisis colaborativo de los resultados

Descripcion del proyecto y anuncio en FIB File:Projecte.doc

Datos administrativos

  DATOS ALUMNO 


Normativa PFC [1]

Lista PFC de la FIB [2]

Ponente: Rene Alquezar Mancho

Adreça OMEGA DESPATX 325 C. JORDI GIRONA, 1-3 08034 BARCELONA SPAIN Telèfon 93-4137784 Adreça de correu alquezar@lsi.upc.edu

REQUISITOS PARA EL DISEÑO

Documento Requisitos de usuario (DRU) Media:Requisitos_del_Usuario_ultim.doc

Documento Especificaciones de Software (DES) Media:Requisitos_de_Software_ultim.doc

Estandares ESA para los requerimiento de usuario

Requisitos para la base de datos

  • El sistema deberá ser ampliable, por si se amplían los sensores, o llegan nuevas variables, éstas serán reconocidas en nuevos campos. Como por ejemplo, en la verificación de controladores (nuevas pilas, nuevas estaciones, etc).REQ-09
  • El sistema no deberá modificar los archivos originales. REQ-13
  • Cada ensayo se realiza con una sola pila, por tanto cada registro de la base de datos no podrá tener datos brutos de pilas distintas. Cada ensayo tiene asociado un único archivo de datos brutos.REQ-15-16
  • Se deberá crear un campo en la base de datos, que refleje los segundos que han pasado desde el inicio del ensayo. Para ello, se tomará la diferencia entre el tiempo de la muestra y el del inicio del ensayo. REQ-12
  • Cada entrada de datos de un ensayo es única. REQ-14

RELACIONES: Requisitos de búsqueda

  • Búsqueda por cada una de las variables de las tablas, por todas las que se quiera, es decir, posibilidad de añadir condiciones de búsqueda (aditivas) REQ-18
  • Intervalos de búsqueda >, <, = REQ-18

(El sistema deberá realizar búsquedas sobre las variables que se han insertado en el sistema, con la posibilidad de añadir más condiciones para buscar. Las principales opciones de búsqueda serán >, <, = con un cierto valor, también se usarán intervalos, y se podrán concatenar varias opciones de búsqueda, para realizar una búsqueda más compleja.)REQ-18

  • Guardar las condiciones de la búsqueda. El sistema deberá realizar nuevas consultas a partir de consultas viejas ya hechas anteriormente. REQ-19
  • Formar archivo nuevo con los resultados de la busqueda (posibilidad de bajar dicho archivo) con mismo sistema de columnas. El sistema deberá dejar descargar al usuario un fichero con los resultados de las búsquedas efectuadas REQ-20
  • Listado de archivos con éxito en la búsqueda REQ-21
  • Tipos de datos que pueden entrar en la búsqueda: * Temporales (mayoritariamente) *Frecuenciales (espectroscopias)
  • Ampliación de variables: el plug-in de introducción de datos debe leer la cabecera de los datos brutos y crear una variable/tabla en la base de datos por cada una del archivo bruto. REQ-11
  • El sistema deberá ver para cada ensayo los sensores que se usan, y cada sensor será usado por varios ensayos. Será útil en los resultados de las búsquedas que se muestren los sensores que se usaron con ensayos con éxito. REQ-17
  • El sistema deberá poder mostrar los ensayos, y sus correspondientes ficheros, los cuales cumplen las condiciones de la búsqueda. REQ-18

Requisitos del interfaz de entrada de datos

  • El sistema deberá mostrar una interfaz gráfica cómoda para que el usuario pueda introducir los datos a ser tratados. Cada ensayo tendrá asociado una carpeta en la cual estarán todos los ficheros relacionados de ese ensayo. REQ-01
  • 2 alternativas: dentro de la wiki o fuera. DENTRO: programada en PHP, acceso con FORM de la wiki, tiene q tener conectividad con servidor datos brutos y con la máquina virtual dnd está la base de datos. (q es la misma de la wiki). FUERA: programada en PHP, script local q tenga acceso a lo mismo. REQ-02
  • El sistema deberá tratar de distinta manera los ensayos viejos de los nuevos, ya que en los antiguos no nos pasan el fichero metadatos, por tanto nos faltará información, como los tipos de ficheros asociados, etc. Por tanto usaremos dos sistemas de reconocimiento, el reconocimiento de tipos de ficheros y el reconocimiento de nombres de los ddbb . Los nuevos sí que nos pasarán el fichero metadatos, por tanto no hará falta hacer ningún reconocimiento de ficheros. REQ-03
  • El sistema deberá identificar cada uno de los ficheros que nos pasan, teniendo en cuenta la extensión o el nombre de cada uno de los ficheros. REQ-04
  • El sistema deberá identificar con los siguientes patrones según el tipo de fichero que sea: REQ-05-06
Metaxxx =>  Fichero metadatos 
-(Ej: META_2008_04_21_...)
-Fecha_Hora_Pila_Id => Datos Brutos 
-(Ej: 2008_04_21_14_55_EC1_...)
-¿? => Espectroscopias, Interrupciones de corriente, Pseudorandom
-Xxxreport => Report del ensayo (html)
-Xxx.jpg => Imagen
REQ-05
  • El método se basará en que los nombres de los ficheros tendrán una estructura similar a Fecha_Hora_Pila_Id. El resto de campos críticos se rellenarán preguntando al usuario. REQ-07
  • El sistema deberá mostrar al usuario el resultado final de los reconocimientos efectuados, para ver si se han hecho correctamente todos los reconocimientos automáticos.REQ-08
  • Los archivos de datos brutos asociados a una misma pila, normalmente tienen una gran cantidad de variables físicas comunes con nombres iguales o similares. Para una misma variable, dos archivos de datos brutos en distintos ensayos, pueden nombrarla con nombres distintos. Por tanto el sistema deberá estandarizar esos distintos nombres de una misma variable física, siempre pidiendo permiso al usuario para verificar que esa variable se corresponda a una variable estándar o para verificar que sea una nueva variable. REQ-10
  • El sistema debe ser ampliable. Debe realizar la lectura del cabecero del archivo de datos brutos, si encuentra un campo que no está asociado a la tabla de la pila, entonces pregunta al usuario. REQ-11
  • Formato de los archivos originales de las espectroscopias:
Caso 1: Cada columna de la tabla será un archivo de texto plano con el 
siguiente formato:

Fx.X == frecuencia
Mx.txt == magnitud
Fx.txt == fase.

donde x=numero entero.
En este caso, tendremos 3 archivos para cada espectroscopia.


Caso 2: Cada espectroscopia es un archivo único con cuatro columnnas, con el 
siguiente formato:

Columna 1: Nº muestra.
Columna 2: Frecuencia.
Columna 3: Fase.
Columna 4: amplittud.
  • Todos las espectroscopias realizadas en un ensayo, se guardaran dentro de una carpeta llamada "EIS".
  • Todos los archivos de Interrupción de corriente correspondientes a un ensayo, vendrán en una carpeta llamada "IC".
  • Todos los archivos de Pseudorandom correspondientes a un ensayo, vendrán en una carpeta llamada "PRBS".
  • El formato de los archivos de interrupción de corriente y de pseudorandom es idéntico, con el siguiente formato:
Columna 1: Nº muestra.
Columna 2: Consigna I.
Columna 3: Medida I.
Columna 4: Vstack (con signo negativo).
Columna 5: Señal control.


Propuesta de diagrama de flujos:

Media:Entrada_datos_ultim.vsd Actualizado

TABLAS DE LA BASE DE DATOS

Media:Base de datos.vsd Actualizado

METADATOS

  • Número registro: identificador único de cada ensayo, sirve para relacionar tablas. CRITICO
  • ID ensayo(=tags, keywords, no son unicas): 1 palabra que nos sean utiles para identificar rapidamente el ensayo. CRITICO
  • Pila: EC1_5, EC7_50_001, EC7_50_002, H100_001, H100_002, NEXA. CRITICO
  • Hora inicio, fecha CRITICO
  • Estación de ensayo: Test station 1, Test Station 2, Test Station 3, Nexa (opcional)
  • Persona encargada del ensayo: (opcional)
  • Lista de todo los archivos con el ensayo. CRITICO
    • Nombre archivos datos brutos (en principio, 1 único archivo DDBB) Está en base de tiempos.
    • Archivo de report: si/no, nombre
    • imágenes asociadas (JPG, TIFF...)
    • Archivos frecuenciales (espectroscopias) con tabla propia y probablemente vengan en otra carpeta.
  • Tabla sensores y acrónimos: tendrá tabla propia. (opcional)
  • Tipo de ensayo: curva polarizacion, interrupcion de corriente, espectroscopia, genérico, prueba. (opcional)


Se puede hacer una tabla para cada pila viendo cuales son los datos más habiatuales, y luego, que el plug-in de entrada de datos verifique que todas las columnas del archivo bruto coinciden con la tabla y las asigne, preguntando en caso de duda.


Propuesta esquema para el caso de varios archivos de datos brutos

[[3]]


Tabla de acrónimos y sensores

A la tabla k viene hay que añadir como primera columna el nº registro ensayo.

TABLA: Nº registro, acrónimo, sensor utilizado, Posición en la estación, Situación


Josele´s idea: realizar 2 tablas en vez de una,

TABLA Acronimos:acrónimo y descripción.

Tabla Configuración: Nº registro, acrónimo, sensor utilizado, posición en la estación y situación.


Espectroscopias

Tareas pendientes

ver como organizar los archivos de espectroscopias OK, mas o menos!!!!

ver como actuar cuando hay varios archivos de datos brutos No se da el caso

OK=relacion entre entre METADATOS y tabla de acrónimos, es decir, par primario = (nº registro, acrónimo) PRIMARY KEY=par

tabla acrónimos y sensores se puede rellenar por el usuario?? NOO

realizar hoja de abreviaciones usadas en el doc RDU


MIGUEL relación con tabla DDBB relación de ficheros en metadatos, viene con todos los archivos o no????? Configuración de las espectroscopias, formato de archivos de espectroscopias .HDR

Links interesantes

ESA - ESTÁNDARES DE INGENIERÍA DEL SOFTWARE - Requisitos de usuario y software [4]

INGENIERÍA DEL SOFTWARE I Apuntes Carlos III [5]

Algo sobre bases de datos [6]

Site Toolbox:

Personal tools
This page was last modified on 26 May 2008, at 14:54. - This page has been accessed 4,936 times. - Disclaimers - About WikIRI