Resistometra elctricaEn este capitulo se explicaran conceptos tcnicos de las mediciones que se efectan en el IFIMAT, conceptos de resistividad elctrica y tambin el mtodo de medicin de cuatro puntas por el cual se obtienen los valores de resistencia de los materiales que se desean estudiar. La resistometra elctrica es la tcnica que consiste en el anlisis del comportamiento de la resistividad elctrica de un material, o sea a la oposicin del paso de la corriente elctrica por el mismo material. Esta es un indicador muy sensible del estado de la estructura cristalina del material bajo estudio. Si uno es capaz de excluir variaciones del estado microestructural de una aleacin (tamao de grano, densidad y arreglo de las dislocaciones) y de la temperatura de medicin (dispersin por fonones), los cambios en la resistividad pueden ser atribuidos a cambios en la distribucin local de los tomos de la aleacin [D. Trattner y W. Pfeiler: Information about SRO-kinetics from isochronal annealing of electrical resistivity. Scripta metallurgica (1983), 17, p909.]. De esta forma, es posible estudiar defectos, procesos de precipitacin, ordenamiento en corto y largo alcance o separacin de fases, y la determinacin de temperaturas de transformacin crticas. Tales estudios hacen uso del hecho de que los procesos de dispersin de los electrones de conduccin son extremadamente sensibles a detalles microestructurales en escala atmica, y que proporcionan un promedio conveniente sobre el volumen de la muestra [P.L.Rossiter: The electrical resistivity of metal and alloys. Cambridge University Press (1987)]. Realizar una experiencia de medicin mediante la tcnica de resistometra es sencillo. Se hace circular, por una muestra del material en estudio, una corriente elctrica de magnitud conocida i, mientras que se mide la cada de potencial que ocurre entre dos puntos de la misma, V. De all es inmediato obtener el valor de la resistencia, R = V/i. En general interesa conocer ms bien la magnitud intensiva (resistividad) en lugar de R, ya que esta ltima depender de la geometra de la muestra, los puntos de medicin de la diferencia de potencial, etc.. Para ello hay dos alternativas: o bien se deben conocer con suma precisin todos estos datos, calculando entonces analticamente el valor de, lo cual es en general inviable, o bien se procede a realizar algn tipo de renormalizacin de R, que la independice de las caractersticas geomtricas de la experiencia. Esta ltima es la alternativa elegida en la mayora de los casos. Adems de medir la cada de potencial, la dependencia de con la temperatura, obliga a hacer un monitoreo de la misma.

Mtodo de medicin de cuatro puntasPare la determinacin de la resistencia elctrica se utiliza el mtodo de cuatro puntas [M. L. Castro, Tesis doctoral, UNCPBA, Tandil, Argentina, 1999]: se hace circular, por la muestra del material en estudio, una corriente elctrica de magnitud conocida i , midiendo, simultneamente, la cada de potencial que ocurre entre dos puntos de la misma, V , lo que permite determinar inmediatamente la resistencia elctrica del material, R = V / i . Para realizar la medicin, se sueldan sobre la muestra dos alambres conductores conectados a una fuente de corriente y otros dos conectados a un nanovoltmetro. Para estudiar la dependencia de la resistencia con la temperatura, el necesario monitoreo de la misma se realiza soldando a la muestra una termocupla de cromelalumel conectada, a travs de una punta fra, a un multmetro digital. Una termocupla es un transductor de temperatura, constituido por dos alambres, que desarrolla una fuerza electro motriz que es funcin de la diferencia de temperatura entre sus uniones fra y caliente. Las termocuplas se fabrican con metales puros o aleaciones. A pesar de los avances efectuados con otros sensores de temperatura, las termocuplas continan siendo los ms usados debido al amplio intervalo de temperatura en el cual pueden utilizarse. La medicin de la cada de tensin se calcula entre los dos alambres conductores y la corriente que circula entre los otros dos para diferentes temperaturas dentro de un rango de 425 Kelvin a 620 Kelvin. Con estos valores, se obtiene la resistencia entre los electrodos de la siguiente forma:

RAD,CB = VCB/IAD y RBD,AC = VAC/IBDHay que tener una consideracin importante: los potenciales termoelctricos y de contacto (VTyC). Para medir el valor real de tensin sobre la muestra (VMuestra), hay que promediar los valores de tensin obtenidos por los multmetros (VMult) en uno y otro sentido de la corriente aplicada, o sea:

VMult(I) = VMuestra + VTyC VMult(-I) = -VMuestra + VTyCPara anular el efecto de los potenciales VTyC, restando las ecuaciones anteriores:

VMuestra = [VMult(I) Vmult(-I)]/2

Figura 2.1 -Equipo de resistometra utilizado en el proceso de medicin. Al medir el valor de la resistencia, aparece incluida la resistencia debida a los cables de conexin. Esta contribucin constante se puede eliminar mediante una adecuada renormalizacin de los valores obtenidos. La presencia de potenciales de contacto entre las conexiones y la muestra pueden afectar a la medida. Para eliminar esta contribucin, el ampermetro entrega una corriente en forma de onda cuadrada, como se ilustra en la figura 2.2. El programa que controla los dispositivos toma como valor de la resistencia el valor promedio entre los dos que se obtienen para distintos sentidos de circulacin de la corriente. Esto es:R = ( R+ + R ) / 2 ,

en donde R+ = (V + v ) / i es la resistencia medida en un sentido de circulacin de la corriente, yR = (V v) / i es la medida para el sentido contrario. En las frmulas anteriores,

v representa el

potencial termoelctrico, que cambia de signo al invertir el sentido de circulacin de la corriente. De esta manera, el potencial termoelctrico

v queda eliminado del valor final de la resistencia.

Figura 2.2 Corriente entregada por un ampermetro

Tcnicas de medicin de baja resistenciaLas tcnicas usadas para medir resistencias en el rango normal, generalmente no son adecuadas para mediciones de baja-resistencia debido a los errores causados por cadas de potencial a travs de los cables de conexin. Para solucionar estas limitaciones, las mediciones de baja resistencia usualmente se realizan mediante el mtodo de las cuatro puntas (Kelvin). Una fuente de corriente, inyecta una corriente I a travs de una resistencia desconocida, produciendo una cada de voltaje en el dispositivo. Aun cuando existe una resistencia de los conectores, esta no afecta la corriente a travs de la resistencia a medir debido a que se supone una fuente de corriente constante con alta impedancia de salida (aqu esta uno de los motivos de usar esa fuente de corriente). Adems, si el voltmetro tiene una muy alta impedancia de entrada, la corriente por los conectores ser despreciable, y la cada de potencial a travs los conductores ser esencialmente cero. Entonces, el voltaje medido por el medidor ser esencialmente el mismo que el voltaje a travs de la resistencia desconocida. Como la corriente a travs de la resistencia a medir y el voltaje a travs del dispositivo son ambos conocidos, el valor de la resistencia puede fcilmente ser determinado a partir de la Ley de Ohm.

Estudios y resultados de la tcnica de medicin del mtodo de cuatro puntasSiendo, en general, la resistencia elctrica de un material funcin de una multiplicidad de factores, depender de cual sea la informacin buscada el procedimiento que se utiliza para estudiar el comportamiento de la misma. Entre los factores que afectan la resistencia podemos incluir: composicin, temperatura, estado de orden atmico o magntico, presencia de impurezas o vacancias, etc.. cada experiencia de resistometra elctrica debe ser diseada de forma tal que las variaciones (o no) en el valor medido sean debido nicamente a la variacin de los parmetros de inters, manteniendo los dems parmetros en un valor constante, o al menos, con la posibilidad de eliminar sus contribuciones a posteriori. Se presentan a continuacin algunos ejemplos de estudios que se realizan con esta tcnica, con el objeto de remarcar los datos que se necesitan y las operaciones posibles con los mismos. a) Evolucin de la resistencia elctrica de un material con la temperatura. Este tipo de estudio se realiza, por ejemplo, para determinar si una aleacin experimenta transformaciones de fase en un dado rango de temperaturas, y si lo hace, obtener informacin de sus caractersticas. La temperatura en estos ensayos puede variar entre 1000C y -190C, para lo que se utilizan hornos con

controlador electrnico de temperatura, en algunos casos programados con rampas, baos refrigerantes, mezclas frigorficas o bien se introduce la muestra en termos con nitrgeno lquido, si se necesita alcanzar temperaturas ms bajas.

Figura 2.3 - Resistencia elctrica de una aleacin de Cobre Cinc Aluminio (CuZnAl ). La Figura 2.3 muestra la resistencia elctrica de una aleacin CuZnAl a medida que la temperatura varia entre 800 y 20C. Analizando esta curva apropiadamente (calculando su derivada por ejemplo) se pueden encontrar puntos crticos de la misma. En este caso en particular, estas puntos crticos (temperaturas crticas) informan acerca de un ordenamiento atmico experimentado por la red cristalina del material a medida que la temperatura es modificada.

Figura 2.4 Transformacin de fases de los smart materials La Figura 2.4 da cuenta de una transformacin de fases que experimentan ciertos materiales que se denominan materiales inteligentes Smart materials en ingls. Dentro de este grupo se encuentran los conocidos como Materiales con memoria de forma, que son con los que se trabaja en el IFIMAT. Como el nombre lo indica son materiales, aleaciones, que en respuesta a estmulos, como pueden ser temperatura, tensin, comprensin, modifican en forma controlada, su forma. De all que puedan utilizarse en gran variedad de dispositivos. Aquellos que se fabrican con aleaciones biocompatibles son aptos para aplicaciones en el campo de la medicina, la ortodoncia, como stens coronarios, por ejemplo, o prtesis. La tcnica de resistometra elctrica resulta muy til para calcular las transformaciones de fases de los smart materials. Se trata de la transformacin martenstica (manifestada por la variacin de temperatura o por aplicacin de fuerzas), y mediante esta tcnica se pueden obtener la mayora de los parmetros que la caracterizan: temperaturas crticas, histresis (tendencia de un material a conservar una de sus propiedades, en ausencia del estmulo que la ha generado), fraccin de material transformado, etc). A veces es til analizar esta transformacin a partir de la curva de fraccin transformada en funcin de la temperatura.

Figura 2.5 Evolucin de la resistencia elctrica a temperatura constante b) En la Figura 2.5 se puede ver la evolucin de la resistencia elctrica a temperatura constante: Experiencias isotrmicas. Se mantiene constante la temperatura del material y se monitorea la resistencia con el tiempo. Este tipo de experiencias tambin permite estudiar la ocurrencia o no de transformaciones de fase, pero sobre todo posibilita el estudio de la cintica de las mismas.

Figura 2.6 Evolucin de la resistencia elctrica en una aleacin de CuZnAl a temperatura ambiente En la Figura 2.6 se muestra la evolucin de la resistencia elctrica, en una aleacin CuZnAl, relativa a la correspondiente a temperatura ambiente (resistencia inicial R0) en funcin del tiempo

para muestras tratadas trmicamente a temperatura constante en el rango 250-480C. La variacin (incremento en este caso) respecto a la de referencia, indica que la aleacin experimenta una transformacin de fase (proceso de descomposicin). El anlisis de los datos obtenidos a partir de la curva permite caracterizar dinmicamente el proceso, determinar tiempos caractersticos, proporciones de fase transformada, velocidad de la transformacin, etc.

Revisin histrica, Caractersticas de los Equipos y Mecanismos de ControlGPIB: Historia y ConceptoEl Bus de Interfaz de Hewlett-Packard (HP-IB, sus siglas en ingls) es un cable de comunicacin de corto alcance desarrollado por Hewlett-Packard (HP) en los aos 70. Su funcin es conectar dispositivos de testeo y de medicin (ej. Multmetros digitales y analizadores lgicos) y permitir el control de los mismos desde una computadora. HP-IB tiene una estructura de lnea telefnica compartida en donde todos los dispositivos en el bus estn conectados en paralelo. Las 16 lneas de seal del cable HP-IB estn agrupadas en tres clases de acuerdo a su funcin: Bus de datos, Bus de control de transferencia de bytes de datos y Bus de administracin de interfaz general. Muchos comits de estandarizacin han adoptado HP-IB. El American National Standards Institute lo incorpor bajo la denominacin de ANSI Standard MC 1.1, y la International Electrotechnical Commission como IEC Publication 625-1. Otros fabricantes copiaron el HP-IB, denominndolo Bus de Interfaz de Propsitos Generales (GPIB, sus siglas en ingls). En 1977 el Bus fue estandarizado por el Instituto de Ingenieros Elctricos y Electrnicos como la interfaz digital estndar IEEE para la instrumentacin programable, IEEE-488-1977.

Estndar IEEE-488Como se explico anteriormente, los fabricantes de instrumentos y placas de adquisicin de datos lograron acordar una especificacin general para la comunicacin entre estos dispositivos lo que dio origen al estndar del Instituto de Ingenieros Electricistas y Electrnicos (IEEE) con el nombre 488. La primera versin del estndar que data de 1975 : IEEE Standard Digital Interface for Programmable Instrumentation, IEEE-488-1975 (actualmente 488.1) define los parmetros mecnicos, elctricos, y el protocolo bsico del bus GPIB. El estndar IEEE-488.2, Codes, Formats, Protocols, and Common Commands for IEEE-488.1 de 1987, proporciona la sintaxis bsica y las convenciones de formato, as como los comandos independientes de dispositivo, estructuras de datos, protocolos de error, y similares. El estndar IEEE-488 define el bus GPIB y adems especifica los protocolos de

comunicacin entre los dispositivos que utilizan el bus de comunicacin GPIB. Con respecto a la arquitectura del bus GPIB descripto en el estndar, consta de 24 pines, repartidos de la siguiente forma (ver figura 3.1): 8 lneas de transmisin de datos (DIO1-DIO8). 3 lneas para el control asncrono de la comunicacin (NRFD, NDAC y NRDAV), tambin denominado handshake. 5 lneas que gestionan la transmisin de interfaces (ATN, IFC, REN, SRQ y EOI). El resto componen las tierras de las diferentes lneas.

:

Figura 3.1 - Distribucin de los pines en el Bus GPIB El bus GPIB es el medio de comunicacin entre la placa capturadora de datos y los instrumentos de medicin que se desea programar, controlar y monitorear a travs de una PC. Para que esa comunicacin se lleve a cabo en forma correcta sin conflictos entre todos los dispositivos conectados al bus, el estndar define un mecanismo de control denominado proceso de handshake. Durante este proceso los dispositivos pueden adquirir principalmente dos roles de trabajo: el modo talker (el dispositivo enva datos) o en modo listener (el dispositivo recibe datos). Si bien todos los dispositivos conectados al bus, pueden tomar tanto el rol de talker como de

listener, solo uno de ellos puede ser el controlador (controller en ingls) del proceso de comunicacin. El controlador tambin forma parte de esta arquitectura y es el que administra el flujo de informacin sobre el bus mediante el envo de comandos y bytes de control a todos los dispositivos. En general la condicin de controlador del proceso de adquisicin es asumida por una PC a travs de una plaqueta de adquisicin de datos, la cual tomar el rol de talker para enviar datos de control a los instrumentos y listener para recibir las respuestas de los mismos. En la figura 3.10 se muestra la interaccin entre el controlador y el resto de los dispositivos de medicin.

Figura 3.10 - Interaccin entre el controlador GPIB y los dispositivos GPIB (http://www.hit.bme.hu/~papay/edu/GPIB/tutor.htm) Un equipo completo de medicin consta de uno o mas dispositivos programables, un bus de comunicacin GPIB y una placa capturadora de datos conectada a una PC. Los dispositivos son normalmente direccionables y deben proveer una forma de actualizar dichas direcciones. Cada dispositivo tiene una direccin primaria que varia entre 0 y 30, siendo la direccin 31 donde no se lee ni se transmite. A su vez poseen direcciones secundarias que pueden ser utilizadas para direccionar funciones de dispositivos. La velocidad de la transferencia de datos es controlada por la respuesta del dispositivo ms lento en el Bus, por esta razn es difcil estimar el ritmo de transferencia de datos en el Bus IEEE488 ya que son dispositivos dependientes.

Lneas de transmisin de datos:Las lneas DIO1 hasta DIO8 son utilizadas para transferir direcciones, controlar informacin y datos. Los formatos para direcciones y controles de bytes son definidos por el estndar IEEE 488, mientras que los formatos de datos son indefinidos y pueden ser ASCII (con o sin paridad) o binario. DIO1 es el Least Significant Bit (esto deber corresponder al bit 0 en la mayora de las computadoras). Se puede dividir las 8 lineas en dos grupos: 3 lineas de Handshake y 5 lineas de administracin de interfaces, las cuales de describen a continuacin. Las primeras son utilizadas para llevar a cabo el proceso de handshake.

Lneas de Handshake

Las tres lneas de handshake (NRFD, NDAC, DAV) controlan la transferencia de mensajes entre los dispositivos y definen el mecanismo para el reconocimiento de la transferencia de datos. Este proceso de handshaking garantiza que los bytes en la lnea de datos son enviados y recibidos sin ningn error de transmisin y es una de las caractersticas nicas del Bus IEEE-488. La lnea de handshake NRFD (Not Ready for Data) es sostenida por un Listener para indicar que no est todava preparado para el prximo dato o para un byte de control. Por otro lado el Controlador no ver liberado el NRFD (por ejemplo, cuando este listo para recibir datos) hasta que todos los dispositivos lo hayan liberado. La lnea de handshake NDAC (Not Data Accepted) es sostenida por un Listener para indicar que todava no est preparado para el prximo dato o para un byte de control en la lnea de datos. Por otro lado el Controlador no ver liberado el NDAC (por ejemplo, cuando el dato sea aceptado) hasta que todos los dispositivos lo hayan liberado. La lnea de handshake DAV (Data Valid) es sostenida por un Talker para indicar que un dato o byte de control ha sido colocado en la lnea de datos y ha tenido el tiempo de estabilizacin mnima especificado. Por lo tanto el byte puede ahora ser aceptado por los dispositivos. El proceso de handshaking consta de los siguientes pasos: 1- Aviso de trasmisin: Cuando el talker detecta que todos los listeners estn desocupados avisa (setea DAV en 1) que se comenzar el proceso de transmisin de un dato (o un byte de control) y espera que todos los dispositivos estn preparados para recibirlo. Si despus de setear la lnea DAV

a 1, el Controlador o el Talker perciben que las lneas NRFD y NDAC estn altas, ocurrir un error.

Figura 3.2 - Aviso de transmisin del Bus GPIB 2- Aviso de preparacin para la recepcin: Cuando cada listener esta preparado para recibir los datos realiza un aviso al talker (setea NRFD en 1 y NDAC en 0).

Figura 3.3 Aviso de preparacin para la recepcin del Bus GPIB 3- Transmisin de los datos: Cuando el talker detecta que todos los listeners estn preparados (NRFD en 1), pone los datos en el bus y avisa a los listeners (setea NRFD y DAV en 0) que ya hay datos validos en las lineas de datos.

Figura 3.4 - Transmisin de datos del Bus GPIB 4- Aviso de ocupado: Cuando los listeners detectan que hay datos vlidos en el bus avisan al talker (setea NDAC en 1) que estn ocupados recibiendo dichos datos.

Figura 3.5 Aviso de ocupado del Bus GPIB 5- Retransmisin: Una vez que el talker setea en 0 la linea DAV espera un tiempo determinado para volver a indicar a los listeners que desea enviar un nuevo dato (paso 1). Dicho tiempo puede ser configurable adaptndose a la cantidad de dispositivos instalados en el bus y la distancia entre los mismos. En la siguiente figura (figura 3.6) se muestra el proceso de handshake completo mostrando los cambios en el estado de cada linea de control (DAV, NRFD y NDAC) en cada momento del proceso.

Figura 3.6 Proceso de Handshake completo del Bus GPIB (http://www.hit.bme.hu/~papay/edu/GPIB/tutor.htm)

Lneas de administracin de interfaces:

Las cinco lneas de administracin de interfaces (ATN, EOI, IFC, REN, SRQ) administran el flujo de datos y bytes de control de un lado a otro de la interfaz. La seal ATN (Attention) es afirmada por el Controlador para indicar que una direccin o un

byte de control est ubicado en el Bus de datos. La seal ATN es liberada para permitir al Talker asignado tomar posicin o datos en el Bus de datos. El Controlador recupera el control reafirmando la seal ATN; esto normalmente es hecho de manera sincrnica con el handshake para eliminar confusiones entre el control y los bytes de datos. La seal EOI (End or Identify) tiene dos usos. Un Talker puede mantener simultneamente EOI con el ltimo byte de datos para indicar el end-of-data. El Controlador puede sostener EOI junto con ATN para iniciar un parallel poll (el proceso de sondeo, de una vez, de todos los dispositivos configurados y de lectura de una respuesta de sondeo compuesta). Aunque muchos dispositivos no usan parallel poll, todos los dispositivos debern usar EOI para finalizar la transferencia (many currently available ones do not). La seal IFC (Interface Clear) es mantenida slo por el Controlador del Sistema con el propsito de inicializar todas las interfaces de los dispositivos a un estado conocido. Despus de liberar IFC, el Controlador del Sistema es un Controlador Activo. La seal REN (Remote Enable) es mantenida slo por el Controlador del Sistema. Su uso no da lugar a dispositivos dentro del modo de control remoto; REN slo habilita a un dispositivo a ir dentro del modo remoto cuando es direccionado para escuchar (listen). Estando en modo remoto un dispositivo deber ignorar el panel de control local. La lnea SRQ (Service Request) es como una interrupcin: esta debe ser mantenida por cualquier dispositivo para requerir al Controlador que realice alguna accin. El Controlador debe determinar que dispositivo mantiene la seal SRQ. Para ello debe realizar un proceso denominado serial poll, en el cual se consulta y lee el byte de estado de a un dispositivo por vez. El dispositivo en cuestin libera la seal SRQ cuando es consultado.

Comandos SCPIEn 1990, la especificacin IEEE 488.2 incluy el documento de los Comandos Estndares para Instrumentacin Programable (SCPI por sus siglas en ingls). El SCPI define los comandos especficos que se pueden enviar desde una PC para configurar y controlar cada clase de instrumento. Por lo tanto, el SCPI garantiza compatibilidad para la medicin y la configuracin entre estos instrumentos. Actualmente no es necesario aprender un conjunto de comandos diferentes para cada instrumento, si el fabricante cumple con el SCPI sera simple reemplazar un instrumento de un proveedor con el de otro proveedor. (http://zone.ni.com/devzone/cda/tut/p/id/9020)

Los comandos SCPI se escriben como texto ASCII, y tienen una estructura jerrquica por niveles, separados por dos puntos.

Figura 3.7 - Esquema general de comandos SCPI Como se puede ver en la figura 3.7 los caracteres en maysculas son necesarios para especificar la orden, mientras que los que estn en minsculas pueden suprimirse, sirviendo slo para facilitar la lectura de programas por usuario. Los comandos en s pueden ser escritos indistintamente en maysculas o minsculas. As, SCALE, sca y scale representan todos al mismo comando. Los dos puntos sirven para separar los niveles de jerarqua, adems los comandos se pueden concatenar con un punto y coma. Una ventaja importante del estndar SCPI es la definicin homognea de comandos para todos los aparatos de una misma clase, as los voltmetros por ejemplo tendrn para la raz un conjunto de comandos determinados. En el Apndice 1, se podr ver un resumen y descripcin de los comandos utilizados en el desarrollo de la aplicacin.

Descripcin de los equiposPlaca capturadora de datos PCI

La interfaz PCI-GPIB IEEE-488 (Figura 3.8) convierte cualquier bus PCI de una computadora personal en un sistema de control de instrumentos y adquisicin de datos con una tasa de transferencia mayor a 1 MB/s. Esta transferencia de datos sobre el bus GPIB se realiza usando la mxima especificacin IEEE-488 de longitud de cable (2 metros multiplicado por el nmero de dispositivos). La alta velocidad de las placas de computadoras, el administrador de estado del bus de la mquina y el potente chip CB7210.2 asegura que la tarjeta sea capaz de mantener esta alta tasa de transferencia de datos sobre el bus GPIB. Un bfer administrado como una FIFO (First In First Out,

sus siglas en ingls) y el avanzado mtodo de transferencia de datos REP-INSW ISR proveen la potencia requerida para transferir datos entre la tarjeta GPIB y la computadora.

Figura 3.8 Placa PCI capturadora de datos

Instrumentos Programables

El Instituto de Fsica de Materiales Tandil (IFIMAT), de la Universidad Nacional del Centro, cuenta hoy con dos equipos completos de la marca Keithley para realizar ensayos de resistividad elctrica, uno con mas de 12 aos de antigedad y otro mas moderno adquirido en el ao 2007. Ambos equipos consisten de tres instrumentos programables de alta precisin: Fuente de energa: La del equipo antiguo corresponde al modelo 220 y el nuevo equipo corresponde al modelo 6220 DC Precision Current Source. Ofrecen una corriente de salida constante con alta impedancia, la cual es fundamental para realizar los ensayos de resistividad. Nanovoltmetro: El equipo antiguo incluye el modelo 181, mientras que el nuevo equipo incluye el modelo 2182A Nanovoltmeter. Este dispositivo posee una sensibilidad de 1 nV, brindan lecturas altamente precisas, estables, con bajo nivel de ruido, en distintos rangos para mediciones de voltaje DC entre 1 nV y 30V. Multmetro: El modelo 195A Digital Multimeter corresponde al equipo antiguo, mientras que el nuevo equipo incluye el modelo 2000 Multimeter. Las principales caractersticas de estos dispositivos son: 5 y dgitos de resolucin, medidas de voltaje DC entre 100nV y 1000V en 6 rangos, mediciones de resistencias entre 100 y 20M y mediciones de temperatura en el rango de -200C y + 630C.

En la tabla (Tabla 3.1) se muestran los valores de precisin de los instrumentos que posee el IFIMAT.

Tabla 3.1 Detalle de los equipos de medicin con sus funciones y precisin

Conexin entre los instrumentos programables y la PCLa placa capturadora se debe colocar en un puerto PCI de una PC estndar sin grandes requerimientos de hardware adicional. A esta placa se le conecta un bus GPIB que a su vez se conectan los dispositivos programables como lo muestra la siguiente figura:

Figura 3.9 Conexin entre dispositivos GPIB y la PC Para que los programas de aplicacin puedan interactuar con la placa de adquisicin de datos PCI instalada en la PC, es necesario agregar al Sistema Operativo el soporte de software de

bajo nivel. A este tipo de soporte se lo denomina controlador de dispositivo y abstrae las caractersticas fsicas de un dispositivo, garantizando su correcto funcionamiento del mismo cuando una aplicacin desea utilizarlo.

Soporte de software para los dispositivos GPIB del IFIMAT

Keithley solo provee controladores de software para sus productos en plataformas comerciales, no provee ningn tipo de software para plataformas de software libre. Solo recomienda algunos links a ciertos proyectos que se realizaron para algunas distribuciones de GNU/Linux, pero algunos no soportan los modelos de los equipos que posee IFIMAT o bien otros funcionaban sobre versiones del kernel ya muy antiguas. Sin embargo existen algunas distribuciones GNU/Linux que proveen mdulos de kernel para ciertos tipos de plaquetas de adquisicin PCI, que suelen funcionar correctamente con dispositivos de diversos fabricantes siempre y cuando sean compatibles. En general, adems de los mdulos, tambin incluyen las bibliotecas de programacin que proveen una abstraccin de alto nivel y facilita el desarrollo de aplicaciones que necesiten comunicarse con los instrumentos de medicin.

Diseo de la aplicacinEn primer lugar se enumeran los requerimientos funcionales y escenarios de calidad que el sistema debe satisfacer. Posteriormente se sigue un simple mecanismo iterativo para aproximar la arquitectura que satisfaga los escenarios de calidad y los requerimientos mencionados. Durante el proceso se describen los componentes y mdulos que participan en la arquitectura, las interrelaciones y las responsabilidades de cada uno. Por ltimo se presenta el diseo final de la arquitectura completa, la cual sirve de gua o esqueleto para la implementacin del sistema.

Requerimientos funcionalesLos requerimientos que se enumeran a continuacin fueron extrados durante diversas entrevistas, investigaciones, prototipos, anlisis, propuestas y especificaciones realizadas en conjunto con los investigadores del IFIMAT. Una base de los mismos proviene la ingeniera inversa y anlisis funcional del software que se utilizaba con los dispositivos mas antiguos. Adems otro conjunto de los requerimientos que a continuacin se enumeran surgen de mejoras propuestas a los investigadores. Para cada requerimiento se informa un nmero de referencia, la descripcin y algunas especificaciones ms detalladas. 1. Posibilidad de elegir el equipo a utilizar para la adquisicin de los datos y configurar nuevos equipos o variar la composicin de los existentes. Leer, interpretar y actualizar algn archivo de configuracin que permita conocer que instrumentos hay conectados a la interfaz GPIB, cuales estn disponibles para su utilizacin y como se conforma un equipo completo de resistividad. 2. Control remoto del proceso de adquisicin de datos en tiempo real: configuracin, inicializacin, comienzo, pausa o continuacin y detenimiento. En el contexto de este sistema se denomina proceso de resistividad al tipo de experimentos que se realizan para analizar la resistividad de un material. Cada experimento, antes de su ejecucin, incluye la configuracin de cierta cantidad de parmetros, como la intensidad de la corriente a aplicar en el circuito elctrico o el intervalo

de tiempo en el cual nos interesa registrar las mediciones de los instrumentos. El usuario puede configurar en el sistema distintas combinaciones de valores de esos parmetros, es decir puede almacenar distintas configuraciones del proceso de resistividad y luego realizar ejecucin del que desee. Se debe enviar a los controladores GPIB los comandos SCPI necesarios para inicializar los instrumentos programables y solicitar los datos adquiridos.?Se debe establecer el orden de inicializacin adecuado de los distintos instrumentos para los experimentos de resistividad que se deben realizar. Se debe establecer el orden y forma de recuperacin de los datos adquiridos por los instrumentos para realizar con los mismos los clculos que sean necesarios. 3. Parmetros de configuracin del proceso de resistividad configurables o establecidos por el usuario. Algunos de los parmetros configurables son: intervalo de medicin: tiempo entre dos mediciones consecutivas. intensidad de la corriente: intensidad de la corriente elctrica aplicada al circuito. tiempo mximo de la ejecucin: cuando el experimento alcance este valor, se detiene automticamente. precisin: cantidad de decimales de los datos adquiridos con los que trabajar el sistema. 4. Posibilidad de crear, modificar y seleccionar diferentes tipos de procesos de resistividad, es decir administrar diferentes conjuntos de valores para los parmetros de configuracin. A un tipo de proceso de resistividad especfico se lo denomina proyecto del sistema. Un proyecto en este sistema consiste de un conjunto de valores de configuracin (almacenados en algn archivo de configuracin del proyecto) y una lista de ejecuciones que el usuario puede iniciar para este proyecto o proceso de resistividad. Los proyectos incluyen otros parmetros como por ejemplo: nombre, descripcin y ubicacin en el sistema de archivos. Una ejecucin consiste de un conjunto de datos adquiridos por los instrumentos y comentarios del usuario realizados sobre sta, desde el momento en que se inicia el proceso de resistividad hasta el momento que se detiene. 5. Presentacin de los datos adquiridos en forma amigable y usable en diferentes formatos. Incluyen grficos en base a los datos obtenidos e informacin sobre el estado del proceso. Grficas en base a diferentes combinaciones de los datos adquiridos. Vistas textuales de los datos adquiridos. Acceso a los datos adquiridos de una ejecucin para un proyecto determinado. Acceso a los comentarios realizados durante una ejecucin de un proceso.

Posibilidad de carga en la interfaz de todos los datos relacionados a una ejecucin realizada con anterioridad. 6. Asegurar la consistencia e integridad de los datos obtenidos ante posibles fallas. Mecanismo de auto-guardado que permita, ante una falla en el sistema, recuperar en forma total o parcial el estado de la ejecucin de un proceso de resistividad. Posibilidad de que el perodo de auto-guardado sea configurable por el usuario y por proyecto. 7. Formatos de entrada y salida del sistema compatibles con otros sistemas, principalmente sistemas de anlisis de datos. Adems los formatos deben ser estndares. Formatos de entradas al sistema en archivos XML. Formatos de salida del sistema en archivos de texto estilo CSV. 8. Para los puntos del 1 al 6, adems de proveer la API que implemente dichos requerimientos se debe proveer una interfaz grfica amigable y confortable para llevar a cabo todas esas funciones en forma visual. Las grficas deben ser escalables automticamente y opcionalmente en forma manual. Adems debe ser posible aumentar o disminuir el rango de los datos en distintos niveles. Las grficas deben poderse exportar a distintos formatos de imgenes.

Escenarios de calidadA continuacin se describen algunos escenarios de calidad o requerimientos no funcionales tambin surgidos durante el anlisis antes mencionado. Los mismos ayudan a tomar las decisiones de diseo de la arquitectura. Este sistema en particular debe satisfacer al menos los siguientes escenarios: Modificabilidad: Debe asegurarse que futuros cambios impacten en la menor cantidad posible de mdulos del sistema. Estos cambios podran estar relacionados con los controles grficos, las caractersticas del proceso de resistividad, los controladores de los dispositivos, la plataforma, los algoritmos de clculo en base a los datos adquiridos, la cantidad y tipo de datos que deben manejar los procesos de resistividad, etc. Performance: Uno de los requisitos del sistema es que el intervalo de tiempo en el cual se deben registrar las mediciones pueda ser configurado por el usuario, con lo cual ese tiempo debe ser garantizado. Adems el sistema debe asegurar que el procesamiento de los eventos del usuario sobre los controles grficos no influya en los tiempos que se manejan durante el proceso de

adquisicin de los datos. Los algoritmos implementen los componentes o mdulos que trabajan en forma directa con los controladores de los dispositivos deben ser lo suficientemente eficientes, de forma tal que no afecten los tiempos que se manejan en la ejecucin de un proceso de resistividad. Fiabilidad: El sistema debe garantizar, ante fallas internas o externas, la integridad y consistencia de los datos adquiridos durante las ejecuciones de un proceso de resistividad. Usabilidad: Los controles visuales deben ser los adecuados para que el usuario sienta confortable el uso del sistema, principalmente respecto al control del proceso de medicin, las grficas y los formatos de los datos adquiridos. Interoperabilidad: Los datos generados por este sistema son utilizados por sus usuarios en tareas de pos procesamiento y anlisis numrico, por lo tanto debe garantizarse la integracin con aquellos sistemas que brinden esa funcionalidad.

Arquitectura de la aplicacin

Para obtener el esqueleto preliminar de la arquitectura del sistema, se sigue en este caso un proceso de descomposicin recursivo, en el cual para cada etapa o iteracin se eligen un conjunto de tcticas o patrones arquitectnicos para satisfacer el conjunto de requerimientos y escenarios de calidad surgidos durante el anlisis. En la figura 1 se presentan las referencias que se utilizarn en los diagramas que ayuden a entender arquitectura de componentes y mdulos obtenida.

Figura 1: Referencias utilizadas en los diagramas de arquitectura.

Arquitectura inicial

Teniendo en cuenta el escenario de modificabilidad y su importancia en este sistema se plantea una arquitectura preliminar basada en capas. El concepto de capas implica organizar los componentes del sistema en distintos niveles, donde cada nivel inferior provea una interfaz de servicios hacia el nivel superior ocultando la implementacin de los mismos. Gracias a este concepto se minimiza la propagacin de cambios realizados en los componentes de niveles inferiores hacia los componentes de nivel superior, siempre y cuando se respeten las interfaces de los servicios. En primer lugar se distinguen dos componentes funcionalmente independientes y cuyo acople se desea minimizar: la interfaz grfica y el ncleo principal del sistema. Por lo tanto, en principio, son identificados como dos grandes capas en la arquitectura. A dicho ncleo se lo llama Ncleo de Resistividad, cuya funcin principal es implementar todo el proceso de resistividad segn los requerimientos particulares de los investigadores del IFIMAT. Este proceso implica la inicializacin de los instrumentos programables de medicin, iniciacin de las mediciones, almacenamiento de las mediciones, y finalizacin de las mismas. Para entender el contexto en el cual trabaja el sistema se incluye en este primer diseo los controladores GPIB como la ltima capa de la arquitectura. Por encima de los controladores se encuentra la capa Ncleo de Resistividad (NR) y en el nivel superior la Interfaz de Usuario (IU). En la Figura 2 se muestra el diseo inicial del sistema y como se relaciona en forma directa o indirecta con todo su entorno (usuario, sistema operativo y hardware).

Figura 2: Diagrama de la arquitectura inicial

Entonces, las principales responsabilidades de los componentes del sistema seran las siguientes: Interfaz de Usuario (IU): 1. Capturar los eventos del usuario y los traducirlos en llamadas a servicios del nivel inferior. 2. Proveer al usuario los controles visuales que permitan llevar a cabo las acciones antes mencionadas y visualizar los datos obtenidos. 3. Ejecutar acciones sobre el proceso de resistividad utilizando la interfaz que provee el Ncleo de Resistividad. 4. Solicitar al Ncleo de Resistividad informacin sobre el estado del proceso de resistividad. 5. Solicitar al Ncleo de Resistividad informacin sobre los equipos instalados en el sistema. 6. Solicitar al Ncleo de Resistividad informacin sobre los proyectos abiertos. 7. Solicitar al Ncleo de Resistividad informacin sobre las ejecuciones realizadas para un

proyecto. Ncleo Resistividad (NR): 1. Proveer la interfaz adecuada para controlar el proceso de resistividad. 2. Proveer estructuras de datos fcilmente manipulables con la informacin concerniente al proceso de resistividad. 3. Enviar los comandos SCPI adecuados hacia el controlador de la placa GPIB para inicializar y controlar los instrumentos programables. 4. Solicitar al controlador las lecturas realizadas por los instrumentos programables. 5. Procesar y registrar la informacin acerca de los equipos de resistividad disponibles en el sistema y cuales instrumentos de medicin tienen configurados, segn determinados archivos de configuracin. 6. Proveer la interfaz adecuada para recuperar y actualizar la informacin sobre los equipos instalados en el sistema. 7. Procesar y registrar la informacin acerca de los proyectos abiertos, en base a al archivo de configuracin del mismo. 8. Proveer la interfaz adecuada para recuperar y actualizar la informacin de los proyectos. 9. Proveer la interfaz adecuada para recuperar la informacin de las ejecuciones de los proyectos. 10. Almacenar en archivos los datos obtenidos durante las ejecuciones de los proyectos. Mientras que las responsabilidades del controlador GPIB instalado en el sistema operativo de la PC son las siguientes: Controlador GPIB: 1. Proveer la interfaz adecuada para interpretar comandos SCPI. 2. Proveer los datos obtenidos de la interfaz y los instrumentos GPIB en un formato manipulable por los niveles de aplicacin. 3. Enviar las seales de control y de datos adecuadas hacia la placa GPIB, en base a los comandos SCPI recibidos desde el nivel superior. 4. Interpretar las seales recibidas desde la placa GPIB para generar los datos en formatos manipulables por los niveles de aplicacin.

Primera descomposicin

Para el componente Ncleo de Resistividad se puede diferenciar sus responsabilidades en tres grupos: las que refieren al proceso de resistividad o la ejecucin de un proyecto, las de administracin de los proyectos y las de administracin de los equipos instalados en el sistema. Dada la independencia de cada grupo se identifican tres componentes diferentes: Proyectos, Dispositivos y Motor de Resistividad. En la Figura 3 se puede observar el diagrama correspondiente a la descomposicin del Ncleo de Resistividad.

Figura 3: Diagrama de la arquitectura del Ncleo de Resistividad

Los componentes identificados tienen las siguientes responsabilidades: Proyectos: Recibe informacin de referencia sobre los proyectos, realiza su apertura y carga de informacin relacionada, como la creacin de nuevos proyectos. Brinda informacin sobre los proyectos al componente UI y al Motor de resistividad. Las principales responsabilidades son: 1. Proveer la interfaz adecuada para recuperar y actualizar la informacin de los proyectos. La informacin de los proyectos incluye los datos de configuracin, datos adquiridos y comentarios registrados durante la ejecucin del proyecto

2. Procesar y registrar la informacin acerca de los proyectos, utilizando para ello la ruta al archivo de configuracin del mismo. 3. Procesar y registrar informacin acerca de las ejecuciones de los proyectos, utilizando para la informacin de referencia sobre los mismos (por ejemplo la ruta correspondiente en el sistema de archivos). 4. Provee la interfaz adecuada para recuperar la informacin de las ejecuciones de los proyectos. Responsabilidades internas: 1. Garantizar, ante posibles fallas internas y externas, la integridad de los datos de configuracin del proyecto y los comentarios que realiza el usuario sobre las ejecuciones de los mismos. Para ello debe encargarse del auto guardado del proyecto. Dispositivos: Recibe informacin de referencia sobre los equipos de resistividad. Mantiene el estado de los equipos y sus instrumentos durante las ejecuciones que se realicen sobre los mismos.. Brinda informacin sobre los equipos disponibles al Motor de Resistividad y a la UI. Carga la informacin de los equipos desde los archivos de configuracin de los mismos. Las principales responsabilidades son: 1. Proveer la interfaz adecuada para recuperar la informacin sobre los equipos instalados en el sistema. 2. Proveer la interfaz adecuada para actualizar la informacin sobre los equipos instalados en el sistema. 3. Procesar y registrar la informacin acerca de equipos de medicin configurados en el sistema, en base a los archivos de configuracin del mismo. Responsabilidades internas: 1. Mantener una instancia por cada equipo disponible en el sistema con informacin sobre su estado (ocupado, no disponible, libre, etc). Motor de Resistividad: Recibe informacin de referencia sobre el equipo a utilizar e informacin de referencia sobre el proyecto a ejecutar sobre ese equipo. Crea un hilo independiente por cada ejecucin que se realice. Se encarga de guardar los datos que se adquieren durante el proceso de adquisicin y del auto guardado de los mismos. Las principales responsabilidades son: 1. Proveer la interfaz adecuada para controlar el proceso de resistividad o ejecucin de un proyecto. El control consiste del inicio de la ejecucin, pausa, continuacin y detencin. 2. Proveer la interfaz adecuada para acceder a informacin concerniente a una ejecucin vigente. La informacin de una ejecucin puede ser los datos adquiridos, el tiempo

transcurrido, el estado, etc. 3. Solicitar y actualizar a travs del componente Proyectos la informacin sobre el proyecto que est ejecutando. 4. Solicitar al componente Dispositivos la informacin acerca del equipos e instrumentos sobre los cuales realizar la ejecucin. 5. Enviar los comandos SCPI adecuados hacia el controlador de la placa GPIB para inicializar y controlar los instrumentos programables. 6. Solicitar al controlador las lecturas realizadas por los instrumentos programables. Responsabilidades internas: 1. Al iniciar una nueva ejecucin, mantener y entregar un identificador de la misma. 2. Validar el identificador de la ejecucin de la cual se quiere realizar algn control o solicitar algn dato. 3. Asegurar la sincronizacin de los diferentes hilos de ejecucin. 4. Garantizar, ante posibles fallas internas y externas, la integridad de los datos de medicin adquiridos durante la ejecucin de un proyecto.

Segunda descomposicin

Para el componente Interfaz de Usuario se aplica el patrn arquitectnico MVC, el cual permite separarlo en tres mdulos funcionalmente independientes: Modelo, Vista y Controlador. Bsicamente se separa la presentacin (Vistas) y lgica de control (Controladores) del modelo de datos y de negocio del componente. Por el momento se plantea una nica vista pero el diseo es flexible a la implementacin de mltiples vistas independientes interactuando sobre el mismo modelo. Para evitar confusiones se denominan a estos nuevos componentes ModeloIU, VistaIU y ControladorIU. En la Figura 4 se puede observar el diagrama correspondiente a la descomposicin la Interfaz de Usuario.

Figura 4: Diagrama de la arquitectura de la Interfaz de Usuario

A continuacin se describe la funcionalidad y responsabilidades que en general debe tener cada mdulo relacionando la intercomunicacin que tienen entre s y la comunicacin con el resto de los componentes del sistema. ModeloIU: Encapsula el estado y expone la funcionalidad de todo el componente a las vistas y controladores. En el contexto de este sistema y en base a la arquitectura planteada inicialmente este modulo se ubica como nexo entre el componente Interfaz del Usuario y el Ncleo de Resistividad, por lo tanto el estado que encapsula, directamente refiere a las estructuras de datos y reglas de negocio de presentacin que facilitan la implementacin de las vistas, mientras que indirectamente encapsula las estructuras de datos y reglas de negocio del Ncleo de Resistividad. Las responsabilidades especificas son: 1. Proveer al ControladorIU los servicios adecuados para que actualice su estado. 2. Informar a la VistaIU si su estado a cambiado. 3. Proveer al ControladorIU y la VistaIU los servicios para recuperar informacin sobre su estado. 4. Ejecutar acciones sobre el proceso de resistividad utilizando la interfaz que provee el Ncleo de Resistividad. 5. Solicitar al Ncleo de Resistividad informacin sobre el estado del proceso de resistividad. 6. Solicitar al Ncleo de Resistividad informacin sobre los equipos instalados en el sistema.

7. Solicitar al Ncleo de Resistividad informacin sobre los proyectos abiertos. 8. Solicitar al Ncleo de Resistividad informacin sobre las ejecuciones realizadas para un proyecto. VistaUI: Renderiza los datos y funcionalidad del modelo en controles grficos que permiten al usuario interactuar con el sistema. Las responsabilidades especificas son: 1. Proveer al ModeloIU el servicio necesario para conocer en que momento debe actualizarse. 2. Proveer al controlador los servicios para que seleccione las distintas pantallas o controles grficos. 3. Muestra al Usuario los controles grficos para que interacte con el sistema. 4. Consultar el estado del modelo. 5. Delegar al ControladorIU los eventos generados por el Usuario 6. Recibir los eventos que el Usuario realiza sobre los controles. ControladorIU: Mapea las acciones del usuario en actualizaciones sobre el modelo, seleccin y actualizacin de las vistas a visualizar. Las responsabilidades especificas son: 1. Captura los eventos del Usuario que la VistaIU le enva. 2. Selecciona de la VistaIU las pantallas o controles grficos a visualizar y actualiza su estado. 3. Actualiza el estado del ModeloIU. 4. Solicita al ModeloIU informacin sobre su estado.

Arquitectura final

En la Figura 5 se muestra el diagrama que incluye todos los componentes, mdulos y sus interrelaciones de la arquitectura final.

Figura 5: Diagrama de la arquitectura final

En base al diseo final y su descripcin se puede afirmar que la arquitectura planteada define las directivas necesarias para que la implementacin cumpla con todos los requerimientos especificados previamente. Adems se satisfacen la mayora de los escenarios de calidad sugeridos previamente, quedando algunos aspectos mencionados en los escenarios que no dependen de la arquitectura y deben ser satisfechos en posteriores refinamientos que se realicen durante la implementacin.

Lista de Figuras Figura 1: Referencias utilizadas en los diagramas de arquitectura. Figura 2: Diagrama de la arquitectura inicial Figura 3: Diagrama de la arquitectura del Ncleo de Resistividad Figura 4: Diagrama de la arquitectura de la Interfaz de Usuario Figura 5: Diagrama de la arquitectura final

Implementacin de la aplicacinEn esta seccin se describen diversas decisiones que son tomadas como gua para la implementacin de la aplicacin. Ms precisamente se describe y justifica cual es la plataforma sobre la cual ejecuta la aplicacin a implementar, las bibliotecas que utiliza cada mdulo para llevar a cabo sus funciones, las herramientas y aplicativos de software libre adecuadas para realizar dicha implementacin y cualquier otro detalle que sea de utilidad durante el desarrollo.

PlataformaLa primer decisin a tomar consiste en la eleccin de plataforma de aplicacin. En este caso se requiere un sistema operativo que posea principalmente las siguientes caractersticas: licencia libre, buena estabilidad, requisitos sobre recursos de hardware no muy elevados, procesos de instalacin-actualizacin simples y soporte para una variedad de aplicaciones o utilidades que complementen las necesidades de los usuarios de sta aplicacin. Los requerimientos para la plataforma de aplicacin, en este caso, tambin aplican a la plataforma de desarrollo. Segn las necesidades planteadas anteriormente la plataforma de aplicacin y desarrollo que mejor se ajusta es alguna de las distribuciones basadas en el proyecto Linux. Este proyecto, de filosofa orientada al software libre, tiene como base los principios e ideas de los sistemas UNIX y aporta las funciones esenciales y criticas que debe tener un sistema operativo moderno. Existen diversas distribuciones basadas en Linux, pero Debian GNU/Linux es la que mejor se ajusta a las necesidades que el instituto requiere en el actual contexto.

Debian GNU/LinuxEs un sistema operativo completo basado principalmente en los proyectos Linux y GNU. El ncleo del sistema corresponde al proyecto Linux, mientras que GNU aporta el conjunto de aplicaciones, bibliotecas y herramientas de desarrollo que actualmente los usuarios finales y desarrolladores necesitan. Las principales ventajas que hacen de Debian el sistema operativo adecuado sobre otros sistemas hoy en da vigentes son: al estar basado en el ncleo Linux no requiere una cantidad de recursos importante y garantiza una muy buena estabilidad y seguridad para las funciones crticas del sistema

operativo. el proyecto GNU aporta al sistema un conjunto completo de aplicaciones que los usuarios finales en la actualidad acostumbran a utilizar, como as tambin un completo conjunto de bibliotecas y herramientas que los desarrolladores necesitan para la implementacin de nuevas utilidades. posee una licencia no comercial al igual que los proyectos en los cuales basa su desarrollo. el gran tamao de la comunidad de usuarios finales y usuarios que colaboran en su desarrollo garantiza un excelente soporte en cuanto a actualizaciones, documentacin, manuales, guas, etc. su comunidad ha desarrollado los controladores y el soporte necesario para una gran diversidad de hardware cuyos propietarios no provean. la instalacin, configuracin y customizacin es flexible tanto para ambientes muy bsicos como para contextos muy complejos. gracias a su poltica conservadora de lanzamiento versiones incremental garantiza la estabilidad del ncleo y el software de aplicacin que provee la distribucin. La ltima versin estable de Debian GNU/Linux es la 5.0, incluye la versin 2.6.26 del ncleo de Linux y se denomina lenny. La versin 5.0 de Debian fue lanzada el 14 de Febrero de 2009, mientras que la ltima actualizacin estable es la versin 5.0.4 lanzada el 31 de Enero de 2010. En la tabla 1 se muestra una comparativa de la distribucin Debian frente a otras distribuciones Linux. En la actualidad existen ms de NNN distribuciones que utilizan Linux como ncleo del sistema, pero en base a los requerimientos y necesidades funcionales, no funcionales y filosficos solo se analizan NN. Las que posean una discontinuidad de ms de 4 aos a la fecha se descartan por la probable des actualizacin del proyecto, algunas son descartadas por su poca madures debido a su fecha de creacin de no ms de 3 aos, otras no se tienen en cuenta por alguna caracterstica en especial como por ejemplo ser productos libres pero de empresas privadas (Ubuntu) o tener un propsito de aplicacin muy especfico. Tambin fueron descartadas las distribuciones que solo provean soporte para arquitecturas x86 (Arch Linux, Ark Linux, CRUX, ATL Linux, VectorLinux, Mandriva, GoboLinux o Frugalware) y adems las que se consideran distribuciones livianas (Arch Linux, Ark Linux, Desktop Light Linux).

Tabla 1: Comparacin de las distribuciones Linux ms representativas.

Controladores de dispositivos GPIBA continuacin de describe cual es y de donde proviene el soporte que brinda Debian para el control de dispositivos GPIB. A finales del ao 2004 Robert Jordens tom el trabajo que se realiza en el proyecto LinuxGPIB para crear un paquete gpib en la distribucin Debian. Fue incluido inicialmente en forma estable en la versin 3.1 denominada sarge, lanzada el 6 de Junio de 2005. La versin del paquete gpib en ese momento fue la 3.2.03-1. El objetivo del nuevo paquete es proveer el soporte de software en Debian para dispositivos de hardware GPIB que cumplen con el estndar IEEE 488.2. Dicho soporte consiste de los mdulos controladores para tarjetas GPIB de diversos fabricante y las bibliotecas de programacin que facilitan el desarrollo de aplicaciones de monitoreo y control de estos dispositivos. Para la versin 4.0 de Debian, lanzada el 8 de Abril de 2007 bajo el nombre de etch, no se incluy el paquete gpib como estable. Luego en la versin 5.0, lanzada el 14 de Enero de 2009 bajo el nombre de lenny, se incluy como estable la versin 3.2.11-1 del paquete. En la actualidad gpib (3.2.11-1) incluye los siguientes paquetes: gpib-modules-source (3.2.11-1): Cdigo fuente de los mdulos del ncleo para varias tarjetas GPIB (IEEE 488). libgpib0: Biblioteca para el lenguaje C del controlador GPIB (IEEE 488). La API de la biblioteca est orientada a ser compatible con la biblioteca GPIB de National Instruments. libgpib0-dev: Encabezados de los enlaces para el lenguaje C del controlador GPIB

(IEEE 488). libgpib-bin: Configuracin y aplicaciones de soporte para libgpib. libgpib-perl: Enlaces de perl para libgpib. php5-gpib: Enlaces de php5 para libgpib. python-gpib: Enlaces de python para libgpib. En el apndice 4-I se detallan los pasos de instalacin, configuracin y testeo de estos paquetes. Para aclarar an ms la historia y caractersticas del controlador elegido se detalla a continuacin algunas cuestiones sobre el proyecto en el cual se basa el soporte en Debian. El proyecto Linux-GPIB es un proyecto creado por Frank Mori Hess a finales del ao 2001 con el objetivo de dar soporte a los dispositivos de hardware GPIB (cumplen con el estndar IEEE 488.2) en la versin 2.4 del ncleo de Linux. Su trabajo se bas originalmente en el paquete linuxgpib-2.05-alpha, desarrollado por Claus Schoeter para el proyecto Linux Lab (iniciado por IBM en Alemania en el ao 2000). Incluye un entorno de desarrollo que aporta una biblioteca GPIB escrita en lenguaje C, mdulos controladores para extender el ncleo del sistema y enlaces a diferentes lenguajes como tcl, python, perl y php. El soporte para tarjetas PCI de la firma Capital Equipment Corp (CEC) y las tarjetas compatibles de otras firmas como Keithley comenz a partir del 8 de Febrero de 2002 a travs de la versin linux-gpib=3.1.3. A partir de ese lanzamiento se incluye el mdulo cec_pci como controlador del tipo de tarjetas antes mencionadas. A partir de mediados del ao 2004 comenz el soporte para los ncleos 2.6 de Linux.

Software de aplicacinHasta aqu se ha hablado del ncleo del sistema operativo, controladores y algunas bibliotecas de bajo nivel, es decir el software esencial para poder sacarle provecho a una PC y otras extensiones de hardware como las tarjetas GPIB. Pero para implementar una aplicacin que cumpla con requerimientos tan especficos (como es el de control y monitoreo de los procesos de resistividad elctrica) es necesario adems, contar con un conjunto de bibliotecas de alto nivel y herramientas de aplicacin. Un ejemplo clsico de software de aplicacin son las herramientas que permiten explorar y

manipular el sistema de archivos. Mientras que un buen ejemplo de una biblioteca de aplicacin de alto nivel puede ser una biblioteca para el envo de correos electrnicos. Hoy en da los sistemas operativos proveen al menos dos tipo o modos de entornos de aplicacin, es decir la forma que proveen al usuario de acceder y manipular el software de aplicacin. La opcin ms primitiva es el entorno de una consola de comandos, que si bien la mayora de los usuarios considera obsoleta, suele ser muy til en tareas de mantenimiento, configuracin, bsquedas complejas de datos, etc. Mientras que los entornos de escritorio con gestores de ventanas, desde hace ms de 15 aos, son los ms utilizados por la mayora de los usuarios de hoy en da. Particularmente las distribuciones de Linux suelen proveer entornos de escritorio que corresponden a proyectos diferentes, por lo tanto sus caractersticas tambin son diferentes, dando la opcin al usuario de cual instalar en su sistema. Como se mencion anteriormente Debian GNU/Linux se basa en el proyecto GNU, el cual provee dos entornos de escritorio que siguen con su filosofa. El primer proyecto se denomina GNOME (GNU Network Object Model Environment) y se basa en una biblioteca para la creacin de interfaces grficas de usuario (toolkit en ingls) denominada GTK+, cuya licencia es LGPL desde su concepcin. Mientras que el segundo proyecto se denomina KDE (K Desktop Environment) y se basa en el toolkit Qt, una biblioteca creada por la firma TrollTech. Qt fue originalmente software propietario, pero hacia el ao 1998 se libera bajo una licencia del estilo BSD. En el ao 2008 TrollTech fue adquirida por Nokia y hoy en da Qt puede distribuirse con alguno de los siguientes tipos de licencias segn la filosofa del proyecto en el cual se utilice: Comercial, GNU LGPL o GNU GPL. Tanto GNOME como KDE proveen un conjunto de aplicaciones, bibliotecas y herramientas de desarrollo de buena calidad para todo tipo de usuarios y necesidades. A pesar de ello se suelen remarcar algunas diferencias, como por ejemplo que KDE incorpora funciones ms modernas y vistosas con bastante mayor anticipacin que GNOME (no siempre de mejor usabilidad). Sin embargo GNOME posee ciertas ventajas que dada las caractersticas de la aplicacin a implementar y las necesidades de sus usuarios, es la mejor eleccin en este caso. Dichas ventajas son: mayor estabilidad gracias a su poltica conservadora de los periodos de actualizacin. mejor eficiencia gracias al diseo de las interfaces con menor nivel de detalle. para cierto tipo de aplicaciones las interfaces suelen ser un poco ms intuitivas.

Desarrollo de la Interfaz de Usuario con GTK+

A partir de la eleccin de GNOME como entorno de escritorio, si bien existen diversos toolkits de desarrollo, la consecuencia directa es elegir GTK+ como el toolkit base para el desarrollo de la aplicacin que en este informe se describe. GTK+ es toolkit diseado originalmente sobre los principios del estndar Motif. Posee componentes visuales de los ms comunes hasta los mas complejos, como por ejemplo el componente de seleccin de archivos o el de seleccin de colores. Inicialmente fue desarrollado como un toolkit para el software GIMP, aplicacin para la manipulacin de imgenes, pero hoy en da se utiliza en un gran numero de aplicaciones siendo adems el toolkit del proyecto de escritorio GNOME. Respecto a su filosofa de desarrollo y distribucin, es parte del proyecto GNU, pero su licencia es GNU LGPL, permitiendo su uso por todos los desarrolladores incluyendo los que desarrollan software propietario. GTK+ es una interfaz de programacin de aplicaciones (API), siendo uno de sus objetivos principales proveer una jerarqua de widgets, permitiendo la derivacin de nuevos widgets a partir de otros ya existentes. Adems podemos mencionas las siguientes caractersticas: Est implementada en lenguaje C y para cumplir con su objetivo se base en la idea de clases y punteros a funciones (callbacks en ingls). Posee una arquitectura orientada a objetos que permite maximizar la flexibilidad. Originalmente su diseo permite soportar enlaces a distintos lenguajes, como C/C++, Perl, Python, entre otros. Si bien la biblioteca original GTK provea un mecanismo de callback estndar, GTK+ lo reemplaza con un nuevo mecanismo de seales. GTK trabaja sobre el tope de GDK (GIMP Drawing Kit) permitiendo el soporte para distintos sistemas de ventanas que se encarguen de su visualizacin. Se basa adems en la biblioteca GLib, la cual es de propsito general y permite que GTK sea portable a ms de una plataforma, ya que realiza el reemplazo de algunas llamadas al sistema estndares y provee funciones para manipular diferentes estructuras de datos que se utilizan habitualmente (listas vinculadas, arboles, etc). Los servicios ms importantes que provee GLib (desde su verin 2.0) y en los cuales GTK+ se apoya son: facilitar las bases que permiten crear una jerarqua de clases; proveer un sistema de seales.

abstraer a GTK+ de la biblioteca de la API nativa para hilos de ejecucin (threads en ingls) de las diversas plataformas. proveer la habilidad para la carga de mdulos, diversos tipos de datos tiles, macros, conversiones de tipos, utilidades para la manipulacin de cadenas de caracteres, utilidades para la manipulacin de archivos y una abstraccin del bucle principal de un programa. Las siguientes son otras bibliotecas sobre las que GTK+ se apoya para implementar funcionalidades ms especificas: Pango: Biblioteca para la obtencin de texto internacionalizado. ATK: ATK es el toolkit de accesibilidad. Provee un conjunto genrico de interfaces permitiendo tecnologas de accesibilidad para interactuar con la interfaz grfica de usuario. GdkPixbuf: Es una pequea biblioteca que permite crear, a partir de datos de imgenes o archivos de imgenes, una estructura en memoria conteniendo pxeles. Generalmente se utiliza en conjunto con otros objetos para visualizar imgenes.

Construccin de la Interfaz de usuario con GladeGlade es una herramienta de aplicacin GNOME que permite crear el diseo de componentes de una interfaz grfica de usuario GTK+ en un entorno visual, intuitivo y amigable. Provee dos mecanismos para que el diseo obtenido pueda ser integrado junto al resto del desarrollo: 1. Permite generar cdigo en lenguaje C (aunque se puede generar en otros lenguajes tambin) y utilizando la biblioteca GTK+ que represente el diseo de la interfaz deseada. Luego este cdigo puede ser editado segn sea necesario para integrarlo en forma esttica a la implementacin del resto del desarrollo. 2. Permite generar un archivo XML que describe en forma textual y estructurada el diseo de la interfaz deseada. Luego ese archivo puede ser interpretado en forma dinmica (en tiempo de ejecucin) para generar la interfaz GTK+ que corresponda (gracias a la biblioteca libglade). Consecuentemente a este mecanismo en tiempo de compilacin no existe cdigo que represente la creacin y composicin de los componentes visuales de la interfaz. Para el actual desarrollo se elige el segundo mecanismo ya que posee las siguientes ventajas:

facilita la construccin rpida de un prototipo de la aplicacin a implementar, permitiendo de esta forma la captura de nuevos o actualizacin de los requerimientos. es un mecanismo ms flexible y mantenible para proyectos de gran tamao, agiliza los procesos del tratamiento de cambios, al menos en lo que se refiere al cdigo que generalmente involucra a la interfaz de usuario. Una secuencia muy simple de los pasos para crear una interfaz utilizando Glade e integrarla al resto de la aplicacin sera: 1. Utilizando el entorno Glade, ya sea desde la aplicacin independiente que provee el proyecto o como plugin de algun otro entorno ms global (como Anjuta), se crea un nuevo proyecto o archivo .glade, el cual internamente es un archivo XML. 2. La interfaz se puede disear en forma visual (arrastrando y combinando los distintos componentes GTK sobre las posibles ventanas de la aplicacin) o bien, si se tiene mucha experiencia en Glade, escribiendo directamente los tags XML en el archivo del proyecto. Es importante definir durante el diseo el nombre de las funciones que se asociarn a algunos eventos de inters sobre algunos de los componentes que componen la interfaz (por ejemplo definir que funcin tratar el evento que ocurre al presionar un botn). 3. Para integrar un proyecto Glade en una aplicacin, bsicamente se debe incluir la biblioteca glade en algn mdulo y agregar algunas sentencias que que permitan la carga dinmica de los componentes descriptos en el archivo .glade del proyecto. 4. Implementar, en algn mdulo de la aplicacin, las funciones necesarias que traten los eventos que se desean capturar sobre la interfaz del usuario. Los nombres de las funciones deben coincidir con los de las asociaciones descriptas en el archivo del proyecto Glade.

Biblioteca para la generacin de grficosUno de los aspectos funcionales importantes en el desarrollo de la aplicacin es el componente o componentes visuales que permitan al usuario visualizar y manipular las grficas que representan el comportamiento de los datos adquiridos durante los ensayos de resistividad. La primer alternativa que surge a la hora de incluir una grfica de este tipo es hacer uso del componente GtkCurve provedo por GTK+, pero dada la complejidad de la funcionalidad requerida en este caso, las caractersticas que el widget provee no son suficientes. Por ejemplo no permite

agregar las referencias de los datos participan en el grfico. Por lo tanto se opta por buscar otras alternativas, es decir alguna otra biblioteca de software libre que cumpla con los requerimientos planteados o al menos provea una API lo suficientemente flexible como para ampliar o adaptar sus servicios. Despus de realizar diversas pruebas y analizar las siguientes bibliotecas como GtkDatabox, geg-1.0.2, GtkPlot del proyecto GtkExtra, se elige el componente PlplotCanvas del proyecto GNU PlPlot. El proyecto GNU PlPlot conforma un paquete de software, liberado bajo licencia LGPL e implementado sobre diversas plataformas, cuyo objetivo es la creacin de grficas de clculo numrico o cientficas. Incluye una biblioteca C como ncleo del proyecto que permite la extensin o customizacin del proyecto hacia objetivos ms especficos, enlaces a esta biblioteca para diversos lenguajes (C/C++, Java, Python, Ada, Perl, Tcl, etc) y diversos controladores que permiten presentar las grficas en contextos no interactivos e interactivos. La biblioteca permite la construccin de grficos de 2 dimensiones, curvas, 3D, barras, torta, logartmicos, etc. Los controladores brindan el soporte para diversos formatos (JPG, GIF, BMP, etc) para contextos de visualizacin no interactivos y un conjunto de diferentes plataformas (GNOME, GTK+, Qt, wxWidgets, etc) para entornos interactivos. En este caso se utilizar el soporte que PlPlot provee para la plataforma GNOME, es decir se integra a la interfaz de la aplicacin a implementar el widget PlplotCanvas que se incluye en la biblioteca del proyecto. Como PlPlotCanvas deriva del widget GnomeCanvas la integracin en la interfaz GNOME/GTK+ de la aplicacin a implementar resulta bastante sencilla.

Repositorios de datosPara el almacenamiento de la mayora de los datos que maneja la aplicacin, como las propiedades de los proyectos y los datos de configuracin de los equipos, se utilizan archivos en formato XML. Este formato brinda las siguientes ventajas: la informacin se almacena en texto plano en forma estructural y siguiendo un estndar definido lo cual facilita su creacin y edicin independientemente a la aplicacin, permite la integrabilidad casi con cualquier sistema de la actualidad, los mecanismos de recuperacin de la informacin tambin son estndares existiendo bibliotecas en todos los lenguajes que los implementan. En este punto cabe aclarar que no se utiliza un motor de bases de datos relacional por las siguientes razones: la mayora de los datos que maneja la aplicacin deben ser configurables por el usuario a travs de la interfaz grfica y tambin desde archivos de texto plano (por ejemplo archivos XML).

los datos que surgen de las ejecuciones de los procesos de adquisicin tambin deben ser almacenados en archivos de texto plano, ya conforman una entrada directa a los sistemas de pos procesamiento y anlisis numrico. el volumen de datos que maneja la aplicacin no es importante y los diferentes conjuntos de datos que manejan los distintos componentes no requieren de un manejo de relaciones demasiado complejo. La configuracin de los equipos de medicin se llevara a cabo a travs de dos archivos: un archivo XML diseado especialmente para este propsito ms el archivo de configuracin de instrumentos que se instala en el sistema junto con el controlador GPIB. Los datos adquiridos durante las mediciones se almacenan en archivos del estilo csv (valores separados por comas), debido a que este tipo de formato estndar puede ser recuperado por la mayora de los sistemas de anlisis de datos numricos permitiendo as la integrabilidad con este sistema. Adems, al igual que los archivos XML, son archivos de texto plano por lo tanto su creacin y edicin se realiza con cualquier editor de texto.

Biblioteca para el soporte de mltiples hilos de ejecucinPara que el control y monitoreo real de los resultados de los ensayos de resistividad puedan realizarse eficientemente es necesario que la aplicacin administre ms de un hilo de ejecucin (thread). En principio la aplicacin maneja cuatro threads independientes: el que maneja el bucle de eventos de usuario sobre la interfaz grfica de la aplicacin y se encarga de actualizar la misma. el que implementa el proceso de adquisicin de los datos provenientes de los instrumentos de medicin y almacena esos datos de forma tal que sean accesibles al resto de la aplicacin. el que actualiza la interfaz de usuario en base a dichos datos adquiridos. Este thread es necesario para que el usuario pueda seguir interactuando con la aplicacin mientras el proceso de adquisicin est activo y adems evita que los tiempos de las tareas de actualizacin de la interfaz de usuario influyan en los tiempos que se maneja el proceso de adquisicin. el que almacena, cada cierto intervalo de tiempo, todos los datos que la aplicacin mantiene en memoria, garantizando la recuperacin de los mismos ante posibles fallas del sistema. Esta funcionalidad se encapsula en otro thread para que no interfiera en la eficiencia de las funciones llevadas a cabo por los otros threads mencionados.

Los cuatro threads trabajan sobre informacin en comn, con lo cual es necesario un mecanismo de control de concurrencia que permita evitar conflictos durante la lectura y actualizacin de los datos. Como mecanismo de control se utiliza en este caso el concepto de semforos. Para la creacin de distintos threads y semforos que permitan llevar a cabo el control de concurrencia se utiliza la biblioteca gthread-2.0 la cual es parte de GLib y provee una interfaz portable sobre la biblioteca de threads C nativa dependiente de la plataforma.

Entorno y herramientas de desarrolloGNOME provee un entorno completo y verstil para el desarrollo de aplicaciones en lenguaje C/C++ denominado Anjuta Devstudio. Este entorno de desarrollo al igual que todas las herramientas que se mencionan a continuacin corresponden tambin a software libre. Algunas de las caractersticas integradas en el entorno que facilitan la tarea del programador son: Editor de cdigo fuente: Por defecto se proveen dos editores reconocidos muy potentes: uno basado en Scintilla y otro basado en GtkSourceView. Cualquiera de los dos brinda las funciones que hoy en da los programadores acostumbran a utilizar. Gestor de archivos: Permite visualizar la estructura del proyecto a travs de un tpico rbol de directorios y archivos. El gestor incluye mens contextuales sobre los archivos que facilitan la manipulacin de los mismos, ejecucin de acciones o apertura de editores internos o externos segn el tipo que representen, etc. Bsqueda de fuentes: Gestin de Proyectos: Permite abrir la mayora de los proyectos basados en autotools (automake/autoconf). Debido a que utiliza nicamente la estructura original del proyecto, sin adicionar informacin dependiente de Anjuta en el mismo, los proyectos pueden reabrirse con otras herramientas sin inconveniente. Asistentes de aplicacin (wizards): Utilizando el motor de procesamiento de plantillas autogen permite la creacin de nuevos proyectos a partir de diversas plantillas predefinidas. A su ves, provee la integracin con el diseador de IUs Glade ya explicado y con otras herramientas muy tiles para el desarrollador como: Depurador interactivo: Provee una interfaz grfica sobre el depurador gdb,

brindando varias vistas de informacin para estudiar el comportamiento de la aplicacin durante su ejecucin. Ayuda para APIs de DevHelp: Permite la visualizacin integrada de ayuda sobre aquellas bibliotecas para las cuales exista documentacin de desarrollo instalada en el sistema. Generador de clases: Permite crear fcilmente clases C++ o GObject. Adems de las caractersticas mencionadas anteriormente Anjuta posee las siguientes ventajas: La flexibilidad que brinda su avanzado sistema de empotramiento. Este permite disponer de todas las vistas en diversas formas, con posibilidad de configurar la disposicin de las mismas por proyecto. Adems el usuario puede configurar sus propias herramientas y acciones de mens. La posibilidad de extensin se sus capacidades a travs del concepto de extensiones (plugins). Todas las caractersticas son implementadas a travs de plugins, los cuales pueden ser activados o desactivados segn las necesidades del proyecto. Se provee una API en lenguaje C para el desarrollo de plugins propios y en caso de existir mas de un plugin para una misma funcin se da la opcin al usuario de elegir cual activar en sus proyectos. Por ejemplo uno de los plugins utilizados es el que provee una interfaz integrada con el gestor de archivos del proyecto para la sincronizacin con CVS.

SourceForge

SourceForge es un software de colaboracin para la administracin de desarrollos via web. Provee una portada para un amplio rango de servicios para el ciclo de vida de desarrollo de software e integra un amplio nmero de aplicaciones de software libre. Desde el sitio se pueden crear, administrar, compartir y publicar todo tipo de proyectos de software libre. El sitio provee este servicio de forma completamente libre y gratuita. Para crear un proyecto, simplemente hay que registrarse como usuario y all crear un proyecto, el cual es revisado por los moderadores del sitio. Las revisiones consisten en verificar el nombre y la breve descripcin que el desarrollador agrega. SourceForge provee al desarrollador varias herramientas que colaboran en el desarrollo y en la publicacin de un proyecto, tales como: Administracin va web.

Uso y gestin de foros en web por cada proyecto. Gestin simple de grupos de trabajo, proyectos y tareas. Listas de correo electrnico. Gestin de la documentacin. Alojamiento de pginas web sobre el proyecto, como por ejemplo pgina de estadsticas del proyecto. Gestin de lanzamientos de versiones del software. Cuentas shell va SSH y crontab. Servicio de CVS para desarrolladores y annimo.

Reconocimiento de los mdulos mas importantesLa implementacin es descripta en base a los distintos mdulos que conformarn el sistema. Los nombres de algunos de ellos se correspondern a los nombres de los componentes de la arquitectura, principalmente porque definen la interfaz de comunicacin para con el resto. Adems se agregarn diferentes mdulos que realizan funciones especificas y colaboran con el resto de los mdulos ms globales para a llevar a cabo las distintas responsabilidades de cada componente. A su vez la presencia de estos mdulos favorece aun ms la modificabilidad individual de los componentes, consecuentemente de todo el sistema. Para el componente Motor de Resistividad colaboran los siguientes mdulos: Motor de Resistividad (ResistivityEngine): Es el principal mdulo de la aplicacin ya que uno de sus objetivos primarios es la administracin de las ejecuciones de los procesos o ensayos de resistividad elctrica. Las ejecuciones implican la capacidad de comunicarse en forma adecuada con los instrumentos de medicin de modo que se obtengan los datos correctos en los tiempos esperados. Adems dichas ejecuciones se corresponden con un proyecto y un equipo donde deben ejecutar, con lo cual el mdulo debe conocer la forma de obtener la informacin relacionada a dichos proyectos y la informacin relacionada a los dispositivos que se encuentren disponibles en el sistema. Un objetivo adicional es el de garantizar en forma consistente, ante posibles fallas del sistema, la correcta recuperacin de todos o gran parte de los datos obtenidos durante las ejecuciones. Los servicios e interfaz que provee son los que representan la comunicacin entre las capas de la Interfaz del Usuario y el Ncleo de Resistividad. Contenedor de datos del Motor de Resistividad (ResistivityEngineDataContainer): Mantiene los datos globales al motor de resistividad, incluyendo los datos de cada proceso o

ensayo de resistividad que se ejecute. Mantiene diversas estructuras de datos en memoria utilizando principalmente la biblioteca glib. Contenedor de datos del proceso de resistividad (ResistivityProcessDataContainer): Mantiene los datos de un proceso de resistividad. Mantiene diversas estructuras de datos en memoria utilizando principalmente la biblioteca glib. Administrador de procesos de resistividad (ResistivityProcessManager): Provee la funcionalidad para crear, administrar y ejecutar procesos de resistividad. Crea un hilo de ejecucin por cada proceso, con lo cual hace uso de la biblioteca gthreads. Soporte GPIB (GPIBSupport): Encapsula y desacopla al componente que lo utilice de los mecanismos y caractersticas dependientes del controlador GPIB instalado en el sistema. Consecuentemente, ante un cambio del controlador, no debera verse afectada la implementacin del Motor de Resistividad. Utiliza la biblioteca gpib proveda junto a los mdulos GPIB, la cual provee la interfaz de programacin para la comunicacin y manipulacin de la tarjeta e instrumentos GPIB. Sincronizador de los datos del proceso (ProcessDataSynchronizer): Implementa en un hilo de ejecucin independiente el mecanismo de respaldo, hacia archivos, de los datos capturados durante la ejecucin de un proceso de resistividad.. Utilizar la biblioteca gthreads. Para el componente Administrador de Proyectos colaboran los siguientes mdulos: Administrador de Proyectos (ProjectManager): Permite abstraer a los mdulos que lo utilizan de la forma en que se recupera la informacin relacionada a los proyectos. Encapsula cuestiones que tienen que ver con la estructura de la informacin de un proyecto, la estructura de la informacin de sus ejecuciones, los tipos de los archivos involucrados, etc. Administrador de Propiedades (PropertyFileManager): Permite leer y escribir desde un archivo de texto plano un conjunto de propiedades de alguna entidad. La informacin almacenada en el archivo respecto a las propiedades seran en principio una clave que la represente en forma nica y un valor asociado. Si bien podemos leer y escribir archivos de propiedades de cualquier tipo de entidad, en nuestro caso utilizaremos el mdulo para las propiedades de los proyectos. Utilizar la biblioteca xml2. Administrador de columnas de datos (CSVFileManager): Mdulo que permite leer y escribir en archivos de texto plano un conjunto de datos organizados en forma de tabla, es decir son un conjunto de filas y columnas. Si bien podemos almacenar columnas de datos de cualquier contexto, en nuestro caso utilizaremos el mdulo para almacenar los datos adquiridos durante las mediciones. Utilizar la biblioteca csv.

Para el componente Administrador de Dispositivos colaboran los siguientes mdulos: Administrador de Dispositivos (DeviceManager): Permite abstraer a los mdulos que lo utilizan de la forma en que se recupera la informacin relacionada a los dispositivos o equipos de resistividad, ya sea la placa de adquisicin o los instrumentos programables conectados a esta. Encapsula cuestiones que tienen que ver con la estructura de la informacin de un de los archivos de configuracin de los equipos y los archivos de configuracin de los dispositivos GPIB instalados en el sistema. Administrador de configuracin de equipos (DeviceConfigFileManager): Este mdulo se encarga de actualizar, interpretar y extraer la informacin contenida en los archivos de configuracin de los equipos de medicin (ver apndice 4-2 en el cual se detalla la estructura del archivo). Dicha informacin, junto a la brindada por el GPIBFileManager, se utiliza luego por el componente para informar sobre la disponibilidad y estructura de los equipos de medicin configurados en el sistema. Utilizar la biblioteca xml2. Administrador de la configuracin GPIB (GPIBFileManager): Permite actualizar, interpretar y extraer la informacin de configuracin de la placa de adquisicin de datos y los instrumentos programables. Para el componente ModeloIU colaboran los siguientes mdulos: Modelo de la Interfaz de Usuario (UIModel): El principal objetivo es mantener en diversas estructuras de datos, fcilmente manipulables por la UIView, toda la informacin relacionada al estado del ResistivityEngine (equipos ocupados, proyectos y ejecuciones activas, datos de las ejecuciones), como tambin a la informacin de proyectos inactivos (historial de ejecuciones) y dispositivos disponibles en el sistema (parmetros de configuracin, estructura de los equipos, etc). Adicionalmente debe garantizar el auto-guardado de la informacin se mantiene en memoria como cambios en la configuracin de los proyectos, de los equipos, o de la propia interfaz de usuario. Se apoya principalmente en la biblioteca glib. Modelo de las grficas de datos (PlotModel): Encapsula las estructuras de datos que utiliza las vista PlotView facilitando adems los servicios de consulta y manipulacin de los mismos. Sincronizador de los datos de la aplicacin (AppDataSynchronizer): Implementa en un hilo de ejecucin independiente el mecanismo de respaldo, hacia archivos, de la informacin (datos de los proyectos, de los equipos o de la misma interfaz) que la aplicacin mantiene en memoria. Utilizar la biblioteca gthreads. Para el componente VistaIU colaboran los siguientes mdulos: Vista de la Interfaz de Usuario (UIView): Debe permitir la visualizacin, en diversas formas,

de toda la informacin que provee el UIModel. Principalmente debe proveer, en forma intuitiva, los controles visuales para: manipular las acciones sobre el Ncleo de Resistividad, manipular distintas grficas en tiempo real sobre los datos de las ejecuciones de un proyecto y actualizar informacin de configuracin sobre proyectos, equipos e interfaz de usuario. Utiliza la biblioteca gtk y gdk. Cargador de la interfaz de usuario GTK (GTKUILoader): Carga en memoria y en forma dinmica los componentes visuales GTK segn el diseo de la interfaz de usuario descripto en el archivo XML de Glade. Utiliza la biblioteca glade. Vista de las grficas de datos (PlotView): Basndose en la clase PlPlotCanvas de la biblioteca plplot, implementa la vista del componente visual que permite al usuario visualizar y manipular los grficos que representan el comportamiento de los datos adquiridos. Adems de las ventajas de PlPlotCanvas provee las siguientes funciones adicionales o personalizadas como: actualizacin automtica de la escala al agregar nuevos datos en forma dinmica; controles para aumentar o disminuir el rango de datos a visualizar; posibilidad de mover la ventana de datos desde un rango a otro. Actualizador de las vistas de la interfaz de usuario (UIViewUpdater): Implementa un hilo independiente que se encarga de actualizar las vistas de la aplicacin en base a distintos eventos internos que pudieran suceder, como por ejemplo, la obtencin de un nuevo dato para un proceso de resistividad determinado. Utilizar la biblioteca gthreads. Para el componente ControladorIU colaboran los siguientes mdulos: Controlador de la Interfaz de Usuario (UIController): Captura todos los eventos iniciados por acciones del usuario sobre la interfaz visual de la aplicacin. Debe tomar las primeras decisiones sobre como tratar dichos eventos, generalmente invocacin a servicios especializados del UIModel o la UIView. Utiliza la biblioteca gtk y gdk.

Diagrama de mdulos

En la Figura 1 se puede visualizar todo el conjunto de mdulos y sus interrelaciones ms las dependencias para con las bibliotecas ms destacadas en las cuales se apoyan.

Figura 1: Mdulos de cada componente de la aplicacin RHOcker

Soluciones de software de aplicacin existentesEn esta seccin se realiza un anlisis sencillo de las soluciones disponibles que pudieran acercarse al requerimiento esencial del IFIMAT, relacionado al control y monitoreo de instrumentos programables. Se analizan diversos proyectos de distintas caractersticas incluyendo adems la solucin propuesta en el presente trabajo. De cada software analizado se analizan las siguientes caractersticas: compatibilidad con los equipos presentes en el instituto, plataformas, licencias, gestin de los controladores, conectividad, etc.

LabVIEW Es una herramienta grfica que permite la realizacin de pruebas, control y diseo de los procesos de medicin mediante un lenguaje de programacin grfico denominado G. El lenguaje G permite generar un circuito virtual que representa al circuito real que ejecutar las mediciones, y dentro de las herramientas disponibles se incluyen controles, indicadores y funciones de medicin. Es muy til para simular mediciones y luego implementarlas. El proyecto fue creado por National Instruments en 1976 para funcionar sobre plataformas MAC, siendo su fecha de lanzamiento al mercado por primera vez en 1986. Hoy en da se encuentra disponible para las plataformas Windows, UNIX, MAC y Linux. Adems de utilizarse para adquisicin y anlisis matemtico de los datos obtenidos y la comunicacin o control de instrumentos de cualquier fabricante, provee una interfaz para diseo electrnico y aplicaciones en el campo de la robtica. Las ventajas que se destacan son las siguientes: El software es patrocinado por un fabricante de instrumentos y placas de captura como National Instruments, con lo cual proporciona un producto maduro en su desarrollo. Es compatible con los buses de comunicacin mas populares. Adems de los mdulos de captura posee mdulos para el anlisis matemtico de los datos. Entre las desventajas, podemos resaltar: Alto costo de las licencias (desde u$s 1200). Imposibilidad de adaptacin para procesos de adquisicin ms especficos como es el caso de IFIMAT. Las grficas que genera el software no concuerdan con las necesarias en los ensayos de resistividad elctrica del instituto.

Debido a la cantidad de opciones que provee hace compleja la iniciacin de una medicin, teniendo en cuenta que se debe programar la medicin que se quiere realizar. National Instruments lo construy pensando en sus instrumentos, podra haber problemas de compatibilidad con otros instrumentos ya que requiere de controladores adicionales. Los controladores deben ser especficos para LabView. Todo en Labview se basa en la programacin visual o grfica, con lo cual el usuario se ve obligado a poseer conocimiento sobre la configuracin de la placa de a