Resistometría eléctrica

En este capitulo se explicaran conceptos técnicos de las mediciones que se efectúan en el

IFIMAT, conceptos de resistividad eléctrica y también el método de medición de cuatro puntas por
el cual se obtienen los valores de resistencia de los materiales que se desean estudiar.

La resistometría eléctrica es la técnica que consiste en el análisis del comportamiento de la

resistividad eléctrica de un material, o sea a la oposición del paso de la corriente eléctrica 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 aleación (tamaño
de grano, densidad y arreglo de las dislocaciones) y de la temperatura de medición (dispersión por
fonones), los cambios en la resistividad pueden ser atribuidos a cambios en la distribución local de
los átomos de la aleación [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 precipitación, ordenamiento en corto y largo
alcance o separación de fases, y la determinación de temperaturas de transformación críticas. Tales
estudios hacen uso del hecho de que los procesos de dispersión de los electrones de conducción son
extremadamente sensibles a detalles microestructurales en escala atómica, 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 medición mediante la técnica de resistometría es sencillo. Se
hace circular, por una muestra del material en estudio, una corriente eléctrica de magnitud conocida
i, mientras que se mide la caída 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 más bien la
magnitud intensiva (resistividad) en lugar de R, ya que esta última dependerá de la geometría de la
muestra, los puntos de medición de la diferencia de potencial, etc.. Para ello hay dos alternativas: o
bien se deben conocer con suma precisión todos estos datos, calculando entonces analíticamente el
valor de, lo cual es en general inviable, o bien se procede a realizar algún tipo de renormalización
de R, que la independice de las características geométricas de la experiencia. Esta última es la
alternativa elegida en la mayoría de los casos.
Además de medir la caída de potencial, la dependencia de con la temperatura, obliga a hacer
un monitoreo de la misma.
Método de medición de cuatro puntas

Pare la determinación de la resistencia eléctrica se utiliza el método de cuatro puntas [M.

L. Castro, Tesis doctoral, UNCPBA, Tandil, Argentina, 1999]: se hace circular, por la muestra del
material en estudio, una corriente eléctrica de magnitud conocida i , midiendo, simultáneamente, la
caída de potencial que ocurre entre dos puntos de la misma, V , lo que permite determinar
inmediatamente la resistencia eléctrica del material, R = V / i . Para realizar la medición, se sueldan
sobre la muestra dos alambres conductores conectados a una fuente de corriente y otros dos
conectados a un nanovoltímetro. 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 cromel-
alumel conectada, a través de una punta fría, a un multímetro digital. Una termocupla es un
transductor de temperatura, constituido por dos alambres, que desarrolla una fuerza electro motriz
que es función de la diferencia de temperatura entre sus uniones fría y caliente. Las termocuplas se
fabrican con metales puros o aleaciones. A pesar de los avances efectuados con otros sensores de
temperatura, las termocuplas continúan siendo los más usados debido al amplio intervalo de
temperatura en el cual pueden utilizarse.
La medición de la caída de tensión 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/IBD

Hay que tener una consideración importante: los potenciales termoeléctricos y de contacto
(VTyC). Para medir el valor real de tensión sobre la muestra (VMuestra), hay que promediar los valores
de tensión obtenidos por los multímetros (VMult) en uno y otro sentido de la corriente aplicada, o sea:

VMult(I) = VMuestra + VTyC

VMult(-I) = -VMuestra + VTyC

Para anular el efecto de los potenciales VTyC, restando las ecuaciones anteriores:
VMuestra = [VMult(I) – Vmult(-I)]/2
 Figura 2.1 -Equipo de resistometría utilizado en el proceso de medición.

Al medir el valor de la resistencia, aparece incluida la resistencia debida a los cables de

conexión. Esta contribución constante se puede eliminar mediante una adecuada renormalización de
los valores obtenidos.
La presencia de potenciales de contacto entre las conexiones y la muestra pueden afectar a la
medida. Para eliminar esta contribución, el amperímetro 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
circulación de la corriente. Esto es:
R = ( R+ + R − ) / 2 ,

en donde R+ = (V + v ) / i es la resistencia medida en un sentido de circulación de la corriente, y

R− = (V − v) / i es la medida para el sentido contrario. En las fórmulas anteriores, v representa el
potencial termoeléctrico, que cambia de signo al invertir el sentido de circulación de la corriente.
De esta manera, el potencial termoeléctrico v queda eliminado del valor final de la resistencia.

Figura 2.2 – Corriente entregada por un amperímetro

Técnicas de medición de baja resistencia

Las técnicas usadas para medir resistencias en el rango normal, generalmente no son
adecuadas para mediciones de baja-resistencia debido a los errores causados por caídas de potencial
a través de los cables de conexión. Para solucionar estas limitaciones, las mediciones de baja
resistencia usualmente se realizan mediante el método de las cuatro puntas (Kelvin). Una fuente de
corriente, inyecta una corriente I a través de una resistencia desconocida, produciendo una caída de
voltaje en el dispositivo. Aun cuando existe una resistencia de los conectores, esta no afecta la
corriente a través 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).
Además, si el voltímetro tiene una muy alta impedancia de entrada, la corriente por los
conectores será despreciable, y la caída de potencial a través los conductores será esencialmente
cero. Entonces, el voltaje medido por el medidor será esencialmente el mismo que el voltaje a través
de la resistencia desconocida.
Como la corriente a través de la resistencia a medir y el voltaje a través del dispositivo son
ambos conocidos, el valor de la resistencia puede fácilmente ser determinado a partir de la Ley de
Ohm.

Estudios y resultados de la técnica de medición del método de cuatro

puntas

Siendo, en general, la resistencia eléctrica de un material función de una multiplicidad de

factores, dependerá de cual sea la información buscada el procedimiento que se utiliza para estudiar
el comportamiento de la misma. Entre los factores que afectan la resistencia podemos incluir:
composición, temperatura, estado de orden atómico o magnético, presencia de impurezas o
vacancias, etc.. cada experiencia de resistometría eléctrica debe ser diseñada de forma tal que las
variaciones (o no) en el valor medido sean debido únicamente a la variación de los parámetros de
interés, manteniendo los demás parámetros en un valor constante, o al menos, con la posibilidad de
eliminar sus contribuciones a posteriori.
Se presentan a continuación algunos ejemplos de estudios que se realizan con esta técnica,
con el objeto de remarcar los datos que se necesitan y las operaciones posibles con los mismos.

a) Evolución de la resistencia eléctrica de un material con la temperatura. Este tipo de estudio se

realiza, por ejemplo, para determinar si una aleación experimenta transformaciones de fase en un
dado rango de temperaturas, y si lo hace, obtener información de sus características. La
temperatura en estos ensayos puede variar entre 1000ºC y -190ºC, para lo que se utilizan hornos con
controlador electrónico de temperatura, en algunos casos programados con rampas, baños
refrigerantes, mezclas frigoríficas o bien se introduce la muestra en termos con nitrógeno líquido, si
se necesita alcanzar temperaturas más bajas.

Figura 2.3 - Resistencia eléctrica de una aleación de Cobre – Cinc – Aluminio (CuZnAl ).

La Figura 2.3 muestra la resistencia eléctrica de una aleación CuZnAl a medida que la
temperatura varia entre 800 y 20ºC. Analizando esta curva apropiadamente (calculando su derivada
por ejemplo) se pueden encontrar puntos críticos de la misma. En este caso en particular, estas
puntos críticos (temperaturas críticas) informan acerca de un ordenamiento atómico experimentado
por la red cristalina del material a medida que la temperatura es modificada.
 Figura 2.4 – Transformación de fases de los “smart materials”

La Figura 2.4 da cuenta de una transformación de fases que experimentan ciertos materiales
que se denominan materiales inteligentes “Smart materials en inglés”. 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 estímulos,
como pueden ser temperatura, tensión, comprensión, 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 prótesis.
La técnica de resistometría eléctrica resulta muy útil para calcular las transformaciones de
fases de los “smart materials”. Se trata de la transformación martensítica (manifestada por la
variación de temperatura o por aplicación de fuerzas), y mediante esta técnica se pueden obtener la
mayoría de los parámetros que la caracterizan: temperaturas críticas, histéresis (tendencia de un
material a conservar una de sus propiedades, en ausencia del estímulo que la ha generado), fracción
de material transformado, etc). A veces es útil analizar esta transformación a partir de la curva de
fracción transformada en función de la temperatura.
 Figura 2.5 – Evolución de la resistencia eléctrica a temperatura constante

b) En la Figura 2.5 se puede ver la evolución de la resistencia eléctrica a temperatura constante:

Experiencias isotérmicas. Se mantiene constante la temperatura del material y se monitorea la
resistencia con el tiempo. Este tipo de experiencias también permite estudiar la ocurrencia o no de
transformaciones de fase, pero sobre todo posibilita el estudio de la cinética de las mismas.

Figura 2.6 – Evolución de la resistencia eléctrica en una aleación de CuZnAl a temperatura

ambiente

En la Figura 2.6 se muestra la evolución de la resistencia eléctrica, en una aleación CuZnAl,

relativa a la correspondiente a temperatura ambiente (resistencia inicial R0) en función del tiempo
para muestras tratadas térmicamente a temperatura constante en el rango 250-480ºC. La variación
(incremento en este caso) respecto a la de referencia, indica que la aleación experimenta una
transformación de fase (proceso de descomposición). El análisis de los datos obtenidos a partir de la
curva permite caracterizar dinámicamente el proceso, determinar tiempos característicos,
proporciones de fase transformada, velocidad de la transformación, etc.
Revisión histórica, Características de los
Equipos y Mecanismos de Control

GPIB: Historia y Concepto

El Bus de Interfaz de Hewlett-Packard (HP-IB, sus siglas en inglés) es un cable de

comunicación de corto alcance desarrollado por Hewlett-Packard (HP) en los años ´70. Su función
es conectar dispositivos de testeo y de medición (ej. Multímetros digitales y analizadores lógicos) y
permitir el control de los mismos desde una computadora.
HP-IB tiene una estructura de línea telefónica compartida en donde todos los dispositivos en
el bus están conectados en paralelo. Las 16 líneas de señal del cable HP-IB están agrupadas en tres
clases de acuerdo a su función: Bus de datos, Bus de control de transferencia de bytes de datos y
Bus de administración de interfaz general.
Muchos comités de estandarización han adoptado HP-IB. El American National Standards
Institute lo incorporó bajo la denominación de ANSI Standard MC 1.1, y la International
Electrotechnical Commission como IEC Publication 625-1.
Otros fabricantes copiaron el HP-IB, denominándolo Bus de Interfaz de Propósitos
Generales (GPIB, sus siglas en inglés).
En 1977 el Bus fue estandarizado por el Instituto de Ingenieros Eléctricos y Electrónicos
como la interfaz digital estándar IEEE para la instrumentación programable, IEEE-488-1977.

Estándar IEEE-488

Como se explico anteriormente, los fabricantes de instrumentos y placas de adquisición de

datos lograron acordar una especificación general para la comunicación entre estos dispositivos lo
que dio origen al estándar del Instituto de Ingenieros Electricistas y Electrónicos (IEEE) con el
nombre 488.
La primera versión del estándar que data de 1975 : IEEE Standard Digital Interface for
Programmable Instrumentation, IEEE-488-1975 (actualmente 488.1) define los parámetros
mecánicos, eléctricos, y el protocolo básico del bus GPIB. El estándar IEEE-488.2, Codes,
Formats, Protocols, and Common Commands for IEEE-488.1 de 1987, proporciona la sintaxis
básica y las convenciones de formato, así como los comandos independientes de dispositivo,
estructuras de datos, protocolos de error, y similares.
El estándar IEEE-488 define el bus GPIB y además especifica los protocolos de
comunicación entre los dispositivos que utilizan el bus de comunicación GPIB.
Con respecto a la arquitectura del bus GPIB descripto en el estándar, consta de 24 pines,
repartidos de la siguiente forma (ver figura 3.1):
– 8 líneas de transmisión de datos (DIO1-DIO8).
– 3 líneas para el control asíncrono de la comunicación (NRFD, NDAC y NRDAV), también
denominado handshake.
– 5 líneas que gestionan la transmisión de interfaces (ATN, IFC, REN, SRQ y EOI).
– El resto componen las tierras de las diferentes líneas.

Figura 3.1 - Distribución de los pines en el Bus GPIB

El bus GPIB es el medio de comunicación entre la placa capturadora de datos y los

instrumentos de medición que se desea programar, controlar y monitorear a través de una PC.
Para que esa comunicación se lleve a cabo en forma correcta sin conflictos entre todos los
dispositivos conectados al bus, el estándar 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 envía 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 inglés) del proceso de
comunicación. El controlador también forma parte de esta arquitectura y es el que administra el
flujo de información sobre el bus mediante el envío de comandos y bytes de control a todos los
dispositivos. En general la condición de “controlador” del proceso de adquisición es asumida por
una PC a través de una plaqueta de adquisición 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 interacción entre el controlador y el resto de los dispositivos
de medición.

Figura 3.10 - Interacción entre el controlador GPIB y los dispositivos GPIB

(http://www.hit.bme.hu/~papay/edu/GPIB/tutor.htm)
Un equipo completo de medición consta de uno o mas dispositivos programables, un bus de
comunicación 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 dirección primaria que varia entre 0 y 30, siendo la
dirección 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 más
lento en el Bus, por esta razón es difícil estimar el ritmo de transferencia de datos en el Bus IEEE-
488 ya que son dispositivos dependientes.
Líneas de transmisión de datos:

Las líneas DIO1 hasta DIO8 son utilizadas para transferir direcciones, controlar información
y datos. Los formatos para direcciones y controles de bytes son definidos por el estándar 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 mayoría de las
computadoras).
Se puede dividir las 8 lineas en dos grupos: 3 lineas de Handshake y 5 lineas de
administración de interfaces, las cuales de describen a continuación. Las primeras son utilizadas
para llevar a cabo el proceso de “handshake”.

Líneas de Handshake

Las tres líneas 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 línea de datos son enviados y
recibidos sin ningún error de transmisión y es una de las características únicas del Bus IEEE-488.
La línea de handshake NRFD (Not Ready for Data) es sostenida por un Listener para indicar
que no está todavía preparado para el próximo 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 línea de handshake NDAC (Not Data Accepted) es sostenida por un Listener para indicar
que todavía no está preparado para el próximo dato o para un byte de control en la línea 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 línea de handshake DAV (Data Valid) es sostenida por un Talker para indicar que un
dato o byte de control ha sido colocado en la línea de datos y ha tenido el tiempo de estabilización
mínima 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 trasmisión: Cuando el talker detecta que todos los listeners están desocupados avisa
(setea DAV en 1) que se comenzará el proceso de transmisión de un dato (o un byte de control) y
espera que todos los dispositivos estén preparados para recibirlo. Si después de setear la línea DAV
a 1, el Controlador o el Talker perciben que las líneas NRFD y NDAC están altas, ocurrirá un error.

Figura 3.2 - Aviso de transmisión del Bus GPIB

2- Aviso de preparación para la recepción: 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 preparación para la recepción del Bus GPIB

3- Transmisión de los datos: Cuando el talker detecta que todos los listeners están 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 - Transmisión de datos del Bus GPIB

4- Aviso de ocupado: Cuando los listeners detectan que hay datos válidos en el bus avisan al talker
(setea NDAC en 1) que están ocupados recibiendo dichos datos.
 Figura 3.5 – Aviso de ocupado del Bus GPIB

5- Retransmisión: 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 adaptándose 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)

Líneas de administración de interfaces:

Las cinco líneas de administración 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 señal ATN (Attention) es afirmada por el Controlador para indicar que una dirección o un
byte de control está ubicado en el Bus de datos. La señal ATN es liberada para permitir al Talker
asignado tomar posición o datos en el Bus de datos. El Controlador recupera el control reafirmando
la señal ATN; esto normalmente es hecho de manera sincrónica con el handshake para eliminar
confusiones entre el control y los bytes de datos.
La señal EOI (End or Identify) tiene dos usos. Un Talker puede mantener simultáneamente
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 deberán usar EOI para finalizar la
transferencia (many currently available ones do not).
La señal IFC (Interface Clear) es mantenida sólo por el Controlador del Sistema con el
propósito de inicializar todas las interfaces de los dispositivos a un estado conocido. Después de
liberar IFC, el Controlador del Sistema es un Controlador Activo.
La señal REN (Remote Enable) es mantenida sólo por el Controlador del Sistema. Su uso no
da lugar a dispositivos dentro del modo de control remoto; REN sólo 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 línea SRQ (Service Request) es como una interrupción: esta debe ser mantenida por
cualquier dispositivo para requerir al Controlador que realice alguna acción.
El Controlador debe determinar que dispositivo mantiene la señal 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 cuestión libera la señal SRQ cuando es consultado.

Comandos SCPI

En 1990, la especificación IEEE 488.2 incluyó el documento de los Comandos Estándares

para Instrumentación Programable (SCPI por sus siglas en inglés). El SCPI define los comandos
específicos que se pueden enviar desde una PC para configurar y controlar cada clase de
instrumento. Por lo tanto, el SCPI garantiza compatibilidad para la medición y la configuración
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 jerárquica 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 mayúsculas son necesarios para especificar la
orden, mientras que los que están en minúsculas pueden suprimirse, sirviendo sólo para facilitar la
lectura de programas por usuario. Los comandos en sí pueden ser escritos indistintamente en
mayúsculas o minúsculas. Así, SCALE, sca y scale representan todos al mismo comando. Los dos
puntos sirven para separar los niveles de jerarquía, además los comandos se pueden concatenar con
un punto y coma. Una ventaja importante del estándar SCPI es la definición homogénea de
comandos para todos los aparatos de una misma clase, así los voltímetros por ejemplo tendrán para
la raíz un conjunto de comandos determinados.
En el Apéndice 1, se podrá ver un resumen y descripción de los comandos utilizados en el
desarrollo de la aplicación.

Descripción de los equipos

Placa 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 adquisición de datos con una tasa
de transferencia mayor a 1 MB/s. Esta transferencia de datos sobre el bus GPIB se realiza usando la
máxima especificación IEEE-488 de longitud de cable (2 metros multiplicado por el número de
dispositivos).
La alta velocidad de las placas de computadoras, el administrador de estado del bus de la
máquina 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 búfer administrado como una FIFO (First In First Out,
sus siglas en inglés) y el avanzado método 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 Física 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 eléctrica, uno con mas de 12 años de antigüedad y otro mas moderno adquirido en el
año 2007. Ambos equipos consisten de tres instrumentos programables de alta precisión:
– Fuente de energía: 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.
– Nanovoltímetro: 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.
– Multímetro: El modelo 195A Digital Multimeter corresponde al equipo antiguo,
mientras que el nuevo equipo incluye el modelo 2000 Multimeter. Las principales
características de estos dispositivos son: 5 y ½ dígitos de resolución, 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 -200ºC y + 630ºC.
 En la tabla (Tabla 3.1) se muestran los valores de precisión de los instrumentos que posee el
IFIMAT.

Tabla 3.1 – Detalle de los equipos de medición con sus funciones y precisión

Conexión entre los instrumentos programables y la PC

La placa capturadora se debe colocar en un puerto PCI de una PC estándar 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 Conexión entre dispositivos GPIB y la PC

Para que los programas de aplicación puedan interactuar con la placa de adquisición 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
características físicas de un dispositivo, garantizando su correcto funcionamiento del mismo cuando
una aplicación 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 ningún 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 módulos de kernel para
ciertos tipos de plaquetas de adquisición PCI, que suelen funcionar correctamente con dispositivos
de diversos fabricantes siempre y cuando sean compatibles. En general, además de los módulos,
también incluyen las bibliotecas de programación que proveen una abstracción de alto nivel y
facilita el desarrollo de aplicaciones que necesiten comunicarse con los instrumentos de medición.
Diseño de la aplicación

En 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 módulos que participan en la arquitectura, las interrelaciones y las
responsabilidades de cada uno.
Por último se presenta el diseño final de la arquitectura completa, la cual sirve de guía o
esqueleto para la implementación del sistema.

Requerimientos funcionales

Los requerimientos que se enumeran a continuación fueron extraídos durante diversas

entrevistas, investigaciones, prototipos, análisis, propuestas y especificaciones realizadas en
conjunto con los investigadores del IFIMAT. Una base de los mismos proviene la ingeniería inversa
y análisis funcional del software que se utilizaba con los dispositivos mas antiguos. Además otro
conjunto de los requerimientos que a continuación se enumeran surgen de mejoras propuestas a los
investigadores.
Para cada requerimiento se informa un número de referencia, la descripción y algunas
especificaciones más detalladas.

1. Posibilidad de elegir el equipo a utilizar para la adquisición de los datos y configurar nuevos
equipos o variar la composición de los existentes.
– Leer, interpretar y actualizar algún archivo de configuración que permita conocer que
instrumentos hay conectados a la interfaz GPIB, cuales están disponibles para su utilización
y como se conforma un equipo completo de resistividad.
2. Control remoto del proceso de adquisición de datos en tiempo real: configuración,
inicialización, comienzo, pausa o continuación 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 ejecución, incluye la configuración de cierta cantidad de
parámetros, como la intensidad de la corriente a aplicar en el circuito eléctrico 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
parámetros, es decir puede almacenar distintas configuraciones del proceso de resistividad y
luego realizar ejecución 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
inicialización adecuado de los distintos instrumentos para los experimentos de resistividad
que se deben realizar.
– Se debe establecer el orden y forma de recuperación de los datos adquiridos por los
instrumentos para realizar con los mismos los cálculos que sean necesarios.
3. Parámetros de configuración del proceso de resistividad configurables o establecidos por el
usuario. Algunos de los parámetros configurables son:
– intervalo de medición: tiempo entre dos mediciones consecutivas.
– intensidad de la corriente: intensidad de la corriente eléctrica aplicada al circuito.
– tiempo máximo de la ejecución: cuando el experimento alcance este valor, se detiene
automáticamente.
– precisión: 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 parámetros de configuración.
– A un tipo de proceso de resistividad específico se lo denomina proyecto del sistema.
– Un proyecto en este sistema consiste de un conjunto de valores de configuración
(almacenados en algún archivo de configuración del proyecto) y una lista de ejecuciones que
el usuario puede iniciar para este proyecto o proceso de resistividad.
– Los proyectos incluyen otros parámetros como por ejemplo: nombre, descripción y
ubicación en el sistema de archivos.
– Una ejecución 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. Presentación de los datos adquiridos en forma amigable y usable en diferentes formatos.
Incluyen gráficos en base a los datos obtenidos e información sobre el estado del proceso.
– Gráficas en base a diferentes combinaciones de los datos adquiridos.
– Vistas textuales de los datos adquiridos.
– Acceso a los datos adquiridos de una ejecución para un proyecto determinado.
– Acceso a los comentarios realizados durante una ejecución de un proceso.
 – Posibilidad de carga en la interfaz de todos los datos relacionados a una ejecución 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 ejecución de un proceso de resistividad.
– Posibilidad de que el período 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 análisis de datos. Además los formatos deben ser estándares.
– 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, además de proveer la API que implemente dichos requerimientos se
debe proveer una interfaz gráfica amigable y confortable para llevar a cabo todas esas funciones
en forma visual.
– Las gráficas deben ser escalables automáticamente y opcionalmente en forma manual.
Además debe ser posible aumentar o disminuir el rango de los datos en distintos niveles.
– Las gráficas deben poderse exportar a distintos formatos de imágenes.

Escenarios de calidad

A continuación se describen algunos escenarios de calidad o requerimientos no funcionales

también surgidos durante el análisis antes mencionado. Los mismos ayudan a tomar las decisiones
de diseño 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 módulos del sistema. Estos cambios podrían estar relacionados con los controles
gráficos, las características del proceso de resistividad, los controladores de los dispositivos, la
plataforma, los algoritmos de cálculo 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. Además el sistema debe asegurar que el procesamiento de los eventos del usuario
sobre los controles gráficos no influya en los tiempos que se manejan durante el proceso de
adquisición de los datos. Los algoritmos implementen los componentes o módulos 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 ejecución 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 medición, las
gráficas 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 análisis numérico, por lo tanto debe garantizarse la integración con
aquellos sistemas que brinden esa funcionalidad.

Arquitectura de la aplicación

Para obtener el esqueleto preliminar de la arquitectura del sistema, se sigue en este caso un
proceso de descomposición recursivo, en el cual para cada etapa o iteración se eligen un conjunto
de tácticas o patrones arquitectónicos para satisfacer el conjunto de requerimientos y escenarios de
calidad surgidos durante el análisis.

En la figura 1 se presentan las referencias que se utilizarán en los diagramas que ayuden a
entender arquitectura de componentes y módulos 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 implementación de los mismos. Gracias a este
concepto se minimiza la propagación 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 gráfica y el núcleo principal del sistema. Por lo tanto, en
principio, son identificados como dos grandes capas en la arquitectura.
A dicho núcleo se lo llama Núcleo de Resistividad, cuya función principal es implementar
todo el proceso de resistividad según los requerimientos particulares de los investigadores del
IFIMAT. Este proceso implica la inicialización de los instrumentos programables de medición,
iniciación de las mediciones, almacenamiento de las mediciones, y finalización de las mismas.
Para entender el contexto en el cual trabaja el sistema se incluye en este primer diseño los
controladores GPIB como la última capa de la arquitectura. Por encima de los controladores se
encuentra la capa Núcleo de Resistividad (NR) y en el nivel superior la Interfaz de Usuario (IU).
En la Figura 2 se muestra el diseño 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 serían 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 Núcleo
de Resistividad.
4. Solicitar al Núcleo de Resistividad información sobre el estado del proceso de resistividad.
5. Solicitar al Núcleo de Resistividad información sobre los equipos instalados en el sistema.
6. Solicitar al Núcleo de Resistividad información sobre los proyectos abiertos.
7. Solicitar al Núcleo de Resistividad información sobre las ejecuciones realizadas para un
 proyecto.

Núcleo Resistividad (NR):

1. Proveer la interfaz adecuada para controlar el proceso de resistividad.
2. Proveer estructuras de datos fácilmente manipulables con la información 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 información acerca de los equipos de resistividad disponibles en el
sistema y cuales instrumentos de medición tienen configurados, según determinados
archivos de configuración.
6. Proveer la interfaz adecuada para recuperar y actualizar la información sobre los equipos
instalados en el sistema.
7. Procesar y registrar la información acerca de los proyectos abiertos, en base a al archivo de
configuración del mismo.
8. Proveer la interfaz adecuada para recuperar y actualizar la información de los proyectos.
9. Proveer la interfaz adecuada para recuperar la información 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 aplicación.
3. Enviar las señales de control y de datos adecuadas hacia la placa GPIB, en base a los
comandos SCPI recibidos desde el nivel superior.
4. Interpretar las señales recibidas desde la placa GPIB para generar los datos en formatos
manipulables por los niveles de aplicación.
Primera descomposición

Para el componente Núcleo de Resistividad se puede diferenciar sus responsabilidades en

tres grupos: las que refieren al proceso de resistividad o la ejecución de un proyecto, las de
administración de los proyectos y las de administración 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 descomposición del
Núcleo de Resistividad.

Figura 3: Diagrama de la arquitectura del Núcleo de Resistividad

Los componentes identificados tienen las siguientes responsabilidades:

Proyectos: Recibe información de referencia sobre los proyectos, realiza su apertura y carga de
información relacionada, como la creación de nuevos proyectos. Brinda información 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 información de los proyectos. La
información de los proyectos incluye los datos de configuración, datos adquiridos y
comentarios registrados durante la ejecución del proyecto
 2. Procesar y registrar la información acerca de los proyectos, utilizando para ello la ruta al
archivo de configuración del mismo.
3. Procesar y registrar información acerca de las ejecuciones de los proyectos, utilizando para
la información de referencia sobre los mismos (por ejemplo la ruta correspondiente en el
sistema de archivos).
4. Provee la interfaz adecuada para recuperar la información de las ejecuciones de los
proyectos.
Responsabilidades internas:
1. Garantizar, ante posibles fallas internas y externas, la integridad de los datos de
configuración 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 información 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 información sobre los equipos disponibles al Motor de Resistividad y a la UI. Carga la
información de los equipos desde los archivos de configuración de los mismos. Las principales
responsabilidades son:
1. Proveer la interfaz adecuada para recuperar la información sobre los equipos instalados en el
sistema.
2. Proveer la interfaz adecuada para actualizar la información sobre los equipos instalados en
el sistema.
3. Procesar y registrar la información acerca de equipos de medición configurados en el
sistema, en base a los archivos de configuración del mismo.
Responsabilidades internas:
1. Mantener una instancia por cada equipo disponible en el sistema con información sobre su
estado (ocupado, no disponible, libre, etc).

Motor de Resistividad: Recibe información de referencia sobre el equipo a utilizar e información

de referencia sobre el proyecto a ejecutar sobre ese equipo. Crea un hilo independiente por cada
ejecución que se realice. Se encarga de guardar los datos que se adquieren durante el proceso de
adquisición y del auto guardado de los mismos. Las principales responsabilidades son:
1. Proveer la interfaz adecuada para controlar el proceso de resistividad o ejecución de un
proyecto. El control consiste del inicio de la ejecución, pausa, continuación y detención.
2. Proveer la interfaz adecuada para acceder a información concerniente a una ejecución
vigente. La información de una ejecución puede ser los datos adquiridos, el tiempo
 transcurrido, el estado, etc.
3. Solicitar y actualizar a través del componente Proyectos la información sobre el proyecto
que está ejecutando.
4. Solicitar al componente Dispositivos la información acerca del equipos e instrumentos sobre
los cuales realizará la ejecución.
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 ejecución, mantener y entregar un identificador de la misma.
2. Validar el identificador de la ejecución de la cual se quiere realizar algún control o solicitar
algún dato.
3. Asegurar la sincronización de los diferentes hilos de ejecución.
4. Garantizar, ante posibles fallas internas y externas, la integridad de los datos de medición
adquiridos durante la ejecución de un proyecto.

Segunda descomposición

Para el componente Interfaz de Usuario se aplica el patrón arquitectónico MVC, el cual

permite separarlo en tres módulos funcionalmente independientes: Modelo, Vista y Controlador.
Básicamente se separa la presentación (Vistas) y lógica de control (Controladores) del modelo de
datos y de negocio del componente. Por el momento se plantea una única vista pero el diseño es
flexible a la implementación de múltiples 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 descomposición la
Interfaz de Usuario.
 Figura 4: Diagrama de la arquitectura de la Interfaz de Usuario

A continuación se describe la funcionalidad y responsabilidades que en general debe tener

cada módulo relacionando la intercomunicación que tienen entre sí y la comunicación 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 Núcleo de
Resistividad, por lo tanto el estado que encapsula, directamente refiere a las estructuras de datos y
reglas de negocio de presentación que facilitan la implementación de las vistas, mientras que
indirectamente encapsula las estructuras de datos y reglas de negocio del Núcleo 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 información sobre su
estado.
4. Ejecutar acciones sobre el proceso de resistividad utilizando la interfaz que provee el Núcleo
de Resistividad.
5. Solicitar al Núcleo de Resistividad información sobre el estado del proceso de resistividad.
6. Solicitar al Núcleo de Resistividad información sobre los equipos instalados en el sistema.
 7. Solicitar al Núcleo de Resistividad información sobre los proyectos abiertos.
8. Solicitar al Núcleo de Resistividad información sobre las ejecuciones realizadas para un
proyecto.

VistaUI: Renderiza los datos y funcionalidad del modelo en controles gráficos 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
gráficos.
3. Muestra al Usuario los controles gráficos para que interactúe 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, selección y
actualización de las vistas a visualizar. Las responsabilidades especificas son:
1. Captura los eventos del Usuario que la VistaIU le envía.
2. Selecciona de la VistaIU las pantallas o controles gráficos a visualizar y actualiza su estado.
3. Actualiza el estado del ModeloIU.
4. Solicita al ModeloIU información sobre su estado.
Arquitectura final

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

Figura 5: Diagrama de la arquitectura final

En base al diseño final y su descripción se puede afirmar que la arquitectura planteada

define las directivas necesarias para que la implementación cumpla con todos los requerimientos
especificados previamente. Además se satisfacen la mayoría 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
implementación.
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 Núcleo de Resistividad
Figura 4: Diagrama de la arquitectura de la Interfaz de Usuario
Figura 5: Diagrama de la arquitectura final
Implementación de la aplicación

En esta sección se describen diversas decisiones que son tomadas como guía para la
implementación de la aplicación. Más precisamente se describe y justifica cual es la plataforma
sobre la cual ejecuta la aplicación a implementar, las bibliotecas que utiliza cada módulo para llevar
a cabo sus funciones, las herramientas y aplicativos de software libre adecuadas para realizar dicha
implementación y cualquier otro detalle que sea de utilidad durante el desarrollo.

Plataforma

La primer decisión a tomar consiste en la elección de plataforma de aplicación. En este caso

se requiere un sistema operativo que posea principalmente las siguientes características: licencia
libre, buena estabilidad, requisitos sobre recursos de hardware no muy elevados, procesos de
instalación-actualización simples y soporte para una variedad de aplicaciones o utilidades que
complementen las necesidades de los usuarios de ésta aplicación.
Los requerimientos para la plataforma de aplicación, en este caso, también aplican a la
plataforma de desarrollo.
Según las necesidades planteadas anteriormente la plataforma de aplicación y desarrollo que
mejor se ajusta es alguna de las distribuciones basadas en el proyecto Linux. Este proyecto, de
filosofía 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/Linux

Es un sistema operativo completo basado principalmente en los proyectos Linux y GNU. El

núcleo 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 día vigentes son:
– al estar basado en el núcleo Linux no requiere una cantidad de recursos importante y
garantiza una muy buena estabilidad y seguridad para las funciones críticas 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í también un completo conjunto de
bibliotecas y herramientas que los desarrolladores necesitan para la implementación de
nuevas utilidades.
– posee una licencia no comercial al igual que los proyectos en los cuales basa su desarrollo.
– el gran tamaño de la comunidad de usuarios finales y usuarios que colaboran en su
desarrollo garantiza un excelente soporte en cuanto a actualizaciones, documentación,
manuales, guías, etc.
– su comunidad ha desarrollado los controladores y el soporte necesario para una gran
diversidad de hardware cuyos propietarios no proveían.
– la instalación, configuración y customización es flexible tanto para ambientes muy básicos
como para contextos muy complejos.
– gracias a su política conservadora de lanzamiento versiones incremental garantiza la
estabilidad del núcleo y el software de aplicación que provee la distribución.

La última versión estable de Debian GNU/Linux es la 5.0, incluye la versión 2.6.26 del
núcleo de Linux y se denomina “lenny”. La versión 5.0 de Debian fue lanzada el 14 de Febrero de
2009, mientras que la última actualización estable es la versión 5.0.4 lanzada el 31 de Enero de
2010.
En la tabla 1 se muestra una comparativa de la distribución Debian frente a otras
distribuciones Linux. En la actualidad existen más de NNN distribuciones que utilizan Linux como
núcleo del sistema, pero en base a los requerimientos y necesidades funcionales, no funcionales y
filosóficos solo se analizan NN. Las que poseían una discontinuidad de más de 4 años a la fecha se
descartan por la probable des actualización del proyecto, algunas son descartadas por su poca
madures debido a su fecha de creación de no más de 3 años, otras no se tienen en cuenta por alguna
característica en especial como por ejemplo ser productos libres pero de empresas privadas
(Ubuntu) o tener un propósito de aplicación muy específico. También fueron descartadas las
distribuciones que solo proveían soporte para arquitecturas x86 (Arch Linux, Ark Linux, CRUX,
ATL Linux, VectorLinux, Mandriva, GoboLinux o Frugalware) y además las que se consideran
distribuciones livianas (Arch Linux, Ark Linux, Desktop Light Linux).
 Tabla 1: Comparación de las distribuciones Linux más representativas.

Controladores de dispositivos GPIB

A continuación de describe cual es y de donde proviene el soporte que brinda Debian para el
control de dispositivos GPIB.
A finales del año 2004 Robert Jordens tomó el trabajo que se realiza en el proyecto Linux-
GPIB para crear un paquete gpib en la distribución Debian. Fue incluido inicialmente en forma
estable en la versión 3.1 denominada “sarge”, lanzada el 6 de Junio de 2005. La versión 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 estándar IEEE 488.2. Dicho soporte consiste de los módulos
controladores para tarjetas GPIB de diversos fabricante y las bibliotecas de programación que
facilitan el desarrollo de aplicaciones de monitoreo y control de estos dispositivos.
Para la versión 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 versión 5.0, lanzada el 14 de Enero de 2009 bajo
el nombre de “lenny”, se incluyó como estable la versión 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): Código fuente de los módulos del núcleo 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: Configuración 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 apéndice 4-I se detallan los pasos de instalación, configuración y testeo de estos

paquetes.

Para aclarar aún más la historia y características del controlador elegido se detalla a
continuación 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 año 2001
con el objetivo de dar soporte a los dispositivos de hardware GPIB (cumplen con el estándar IEEE
488.2) en la versión 2.4 del núcleo de Linux. Su trabajo se basó originalmente en el paquete linux-
gpib-2.05-alpha, desarrollado por Claus Schoeter para el proyecto Linux Lab (iniciado por IBM
en Alemania en el año 2000).
Incluye un entorno de desarrollo que aporta una biblioteca GPIB escrita en lenguaje C,
módulos controladores para extender el núcleo 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 través de la
versión linux-gpib=3.1.3. A partir de ese lanzamiento se incluye el módulo cec_pci como
controlador del tipo de tarjetas antes mencionadas.
A partir de mediados del año 2004 comenzó el soporte para los núcleos 2.6 de Linux.

Software de aplicación

Hasta aquí se ha hablado del núcleo 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 aplicación que cumpla
con requerimientos tan específicos (como es el de control y monitoreo de los procesos de
resistividad eléctrica) es necesario además, contar con un conjunto de bibliotecas de alto nivel y
herramientas de aplicación.
Un ejemplo clásico de software de aplicación son las herramientas que permiten explorar y
manipular el sistema de archivos. Mientras que un buen ejemplo de una biblioteca de aplicación de
alto nivel puede ser una biblioteca para el envío de correos electrónicos.
Hoy en día los sistemas operativos proveen al menos dos tipo o modos de entornos de
aplicación, es decir la forma que proveen al usuario de acceder y manipular el software de
aplicación. La opción más primitiva es el entorno de una consola de comandos, que si bien la
mayoría de los usuarios considera obsoleta, suele ser muy útil en tareas de mantenimiento,
configuración, búsquedas complejas de datos, etc. Mientras que los entornos de escritorio con
gestores de ventanas, desde hace más de 15 años, son los más utilizados por la mayoría de los
usuarios de hoy en día.
Particularmente las distribuciones de Linux suelen proveer entornos de escritorio que
corresponden a proyectos diferentes, por lo tanto sus características también son diferentes, dando
la opción 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 filosofía. El primer proyecto se denomina GNOME (GNU Network Object Model Environment)
y se basa en una biblioteca para la creación de interfaces gráficas de usuario (toolkit en inglés)
denominada GTK+, cuya licencia es LGPL desde su concepción. 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 año 1998 se libera bajo
una licencia del estilo BSD. En el año 2008 TrollTech fue adquirida por Nokia y hoy en día Qt
puede distribuirse con alguno de los siguientes tipos de licencias según la filosofía 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 más modernas y
vistosas con bastante mayor anticipación que GNOME (no siempre de mejor usabilidad). Sin
embargo GNOME posee ciertas ventajas que dada las características de la aplicación a implementar
y las necesidades de sus usuarios, es la mejor elección en este caso. Dichas ventajas son:
– mayor estabilidad gracias a su política conservadora de los periodos de actualización.
– mejor eficiencia gracias al diseño de las interfaces con menor nivel de detalle.
– para cierto tipo de aplicaciones las interfaces suelen ser un poco más intuitivas.

Desarrollo de la Interfaz de Usuario con GTK+

 A partir de la elección 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 aplicación que en este informe se describe.
GTK+ es toolkit diseñado originalmente sobre los principios del estándar Motif. Posee
componentes visuales de los más comunes hasta los mas complejos, como por ejemplo el
componente de selección de archivos o el de selección de colores.

Inicialmente fue desarrollado como un toolkit para el software GIMP, aplicación para la
manipulación de imágenes, pero hoy en día se utiliza en un gran numero de aplicaciones siendo
además el toolkit del proyecto de escritorio GNOME.

Respecto a su filosofía de desarrollo y distribución, 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 programación de aplicaciones (API), siendo uno de sus objetivos
principales proveer una jerarquía de widgets, permitiendo la derivación de nuevos widgets a partir
de otros ya existentes. Además podemos mencionas las siguientes características:

– Está implementada en lenguaje C y para cumplir con su objetivo se base en la idea de

clases y punteros a funciones (callbacks en inglés).

– Posee una arquitectura orientada a objetos que permite maximizar la flexibilidad.

– Originalmente su diseño permite soportar enlaces a distintos lenguajes, como C/C++,

Perl, Python, entre otros.

– Si bien la biblioteca original GTK proveía un mecanismo de callback estándar, GTK+ lo

reemplaza con un nuevo mecanismo de señales.

GTK trabaja sobre el tope de GDK (GIMP Drawing Kit) permitiendo el soporte para
distintos sistemas de ventanas que se encarguen de su visualización.

Se basa además en la biblioteca GLib, la cual es de propósito general y permite que GTK
sea portable a más de una plataforma, ya que realiza el reemplazo de algunas llamadas al sistema
estándares y provee funciones para manipular diferentes estructuras de datos que se utilizan
habitualmente (listas vinculadas, arboles, etc). Los servicios más importantes que provee GLib
(desde su verión 2.0) y en los cuales GTK+ se apoya son:

– facilitar las bases que permiten crear una jerarquía de clases; proveer un sistema de
señales.
 – abstraer a GTK+ de la biblioteca de la API nativa para hilos de ejecución (threads en
inglés) de las diversas plataformas.

– proveer la habilidad para la carga de módulos, diversos tipos de datos útiles, macros,
conversiones de tipos, utilidades para la manipulación de cadenas de caracteres,
utilidades para la manipulación de archivos y una abstracción del bucle principal de un
programa.

Las siguientes son otras bibliotecas sobre las que GTK+ se apoya para implementar
funcionalidades más especificas:

– Pango: Biblioteca para la obtención de texto internacionalizado.

– ATK: ATK es el toolkit de accesibilidad. Provee un conjunto genérico de interfaces

permitiendo tecnologías de accesibilidad para interactuar con la interfaz gráfica de
usuario.

– GdkPixbuf: Es una pequeña biblioteca que permite crear, a partir de datos de

imágenes o archivos de imágenes, una estructura en memoria conteniendo píxeles.
Generalmente se utiliza en conjunto con otros objetos para visualizar imágenes.

Construcción de la Interfaz de usuario con Glade

Glade es una herramienta de aplicación GNOME que permite crear el diseño de

componentes de una interfaz gráfica de usuario GTK+ en un entorno visual, intuitivo y amigable.
Provee dos mecanismos para que el diseño obtenido pueda ser integrado junto al resto del
desarrollo:
1. Permite generar código en lenguaje C (aunque se puede generar en otros lenguajes también)
y utilizando la biblioteca GTK+ que represente el diseño de la interfaz deseada. Luego este
código puede ser editado según sea necesario para integrarlo en forma estática a la
implementación del resto del desarrollo.
2. Permite generar un archivo XML que describe en forma textual y estructurada el diseño de
la interfaz deseada. Luego ese archivo puede ser interpretado en forma dinámica (en tiempo
de ejecución) para generar la interfaz GTK+ que corresponda (gracias a la biblioteca
libglade). Consecuentemente a este mecanismo en tiempo de compilación no existe código
que represente la creación y composición de los componentes visuales de la interfaz.

Para el actual desarrollo se elige el segundo mecanismo ya que posee las siguientes ventajas:
 – facilita la construcción rápida de un prototipo de la aplicación a implementar,
permitiendo de esta forma la captura de nuevos o actualización de los requerimientos.
– es un mecanismo más flexible y mantenible para proyectos de gran tamaño,
– agiliza los procesos del tratamiento de cambios, al menos en lo que se refiere al código
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 aplicación sería:

1. Utilizando el entorno Glade, ya sea desde la aplicación independiente que provee el

proyecto o como plugin de algun otro entorno más global (como Anjuta), se crea un nuevo
proyecto o archivo “.glade”, el cual internamente es un archivo XML.

2. La interfaz se puede diseñar en forma visual (arrastrando y combinando los distintos

componentes GTK sobre las posibles ventanas de la aplicación) o bien, si se tiene mucha
experiencia en Glade, escribiendo directamente los tags XML en el archivo del proyecto. Es
importante definir durante el diseño el nombre de las funciones que se asociarán a algunos
eventos de interés sobre algunos de los componentes que componen la interfaz (por ejemplo
definir que función tratará el evento que ocurre al presionar un botón).

3. Para integrar un proyecto Glade en una aplicación, básicamente se debe incluir la biblioteca
glade en algún módulo y agregar algunas sentencias que que permitan la carga dinámica de
los componentes descriptos en el archivo “.glade” del proyecto.

4. Implementar, en algún módulo de la aplicación, 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 generación de gráficos

Uno de los aspectos funcionales importantes en el desarrollo de la aplicación es el

componente o componentes visuales que permitan al usuario visualizar y manipular las gráficas que
representan el comportamiento de los datos adquiridos durante los ensayos de resistividad.
La primer alternativa que surge a la hora de incluir una gráfica de este tipo es hacer uso del
componente GtkCurve proveído por GTK+, pero dada la complejidad de la funcionalidad requerida
en este caso, las características que el widget provee no son suficientes. Por ejemplo no permite
agregar las referencias de los datos participan en el gráfico.
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. Después 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 creación de gráficas de cálculo
numérico o científicas. Incluye una biblioteca C como núcleo del proyecto que permite la extensión
o customización del proyecto hacia objetivos más específicos, enlaces a esta biblioteca para
diversos lenguajes (C/C++, Java, Python, Ada, Perl, Tcl, etc) y diversos controladores que permiten
presentar las gráficas en contextos no interactivos e interactivos. La biblioteca permite la
construcción de gráficos de 2 dimensiones, curvas, 3D, barras, torta, logarítmicos, etc. Los
controladores brindan el soporte para diversos formatos (JPG, GIF, BMP, etc) para contextos de
visualización 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 aplicación a implementar el widget PlplotCanvas que se incluye en la
biblioteca del proyecto. Como PlPlotCanvas deriva del widget GnomeCanvas la integración en la
interfaz GNOME/GTK+ de la aplicación a implementar resulta bastante sencilla.

Repositorios de datos

Para el almacenamiento de la mayoría de los datos que maneja la aplicación, como las
propiedades de los proyectos y los datos de configuración de los equipos, se utilizan archivos en
formato XML. Este formato brinda las siguientes ventajas: la información se almacena en texto
plano en forma estructural y siguiendo un estándar definido lo cual facilita su creación y edición
independientemente a la aplicación, permite la integrabilidad casi con cualquier sistema de la
actualidad, los mecanismos de recuperación de la información también son estándares 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 mayoría de los datos que maneja la aplicación deben ser configurables por el usuario a
través de la interfaz gráfica y también desde archivos de texto plano (por ejemplo archivos
XML).
 ● los datos que surgen de las ejecuciones de los procesos de adquisición también deben ser
almacenados en archivos de texto plano, ya conforman una entrada directa a los sistemas de
pos procesamiento y análisis numérico.
● el volumen de datos que maneja la aplicación no es importante y los diferentes conjuntos de
datos que manejan los distintos componentes no requieren de un manejo de relaciones
demasiado complejo.

La configuración de los equipos de medición se llevara a cabo a través de dos archivos: un

archivo XML diseñado especialmente para este propósito más el archivo de configuración 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 estándar puede ser recuperado por la
mayoría de los sistemas de análisis de datos numéricos permitiendo así la integrabilidad con este
sistema. Además, al igual que los archivos XML, son archivos de texto plano por lo tanto su
creación y edición se realiza con cualquier editor de texto.

Biblioteca para el soporte de múltiples hilos de ejecución

Para que el control y monitoreo real de los resultados de los ensayos de resistividad puedan
realizarse eficientemente es necesario que la aplicación administre más de un hilo de ejecución
(thread). En principio la aplicación maneja cuatro threads independientes:
– el que maneja el bucle de eventos de usuario sobre la interfaz gráfica de la aplicación y se
encarga de actualizar la misma.
– el que implementa el proceso de adquisición de los datos provenientes de los instrumentos de
medición y almacena esos datos de forma tal que sean accesibles al resto de la aplicación.
– 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 aplicación mientras el proceso de
adquisición está activo y además evita que los tiempos de las tareas de actualización de la
interfaz de usuario influyan en los tiempos que se maneja el proceso de adquisición.
– el que almacena, cada cierto intervalo de tiempo, todos los datos que la aplicación mantiene en
memoria, garantizando la recuperación 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 información en común, con lo cual es necesario un
mecanismo de control de concurrencia que permita evitar conflictos durante la lectura y
actualización de los datos. Como mecanismo de control se utiliza en este caso el concepto de
semáforos.
Para la creación de distintos threads y semáforos 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 desarrollo

GNOME provee un entorno completo y versátil 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 continuación corresponden también a software libre. Algunas de
las características integradas en el entorno que facilitan la tarea del programador son:
– Editor de código 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 día los programadores acostumbran a
utilizar.
– Gestor de archivos: Permite visualizar la estructura del proyecto a través de un
típico árbol de directorios y archivos. El gestor incluye menús contextuales sobre los
archivos que facilitan la manipulación de los mismos, ejecución de acciones o
apertura de editores internos o externos según el tipo que representen, etc.
– Búsqueda de fuentes:
– Gestión de Proyectos: Permite abrir la mayoría de los proyectos basados en
autotools (automake/autoconf). Debido a que utiliza únicamente la estructura
original del proyecto, sin adicionar información dependiente de Anjuta en el mismo,
los proyectos pueden reabrirse con otras herramientas sin inconveniente.
– Asistentes de aplicación (wizards): Utilizando el motor de procesamiento de
plantillas autogen permite la creación de nuevos proyectos a partir de diversas
plantillas predefinidas.
A su ves, provee la integración con el diseñador de IUs Glade ya explicado y con otras
herramientas muy útiles para el desarrollador como:
– Depurador interactivo: Provee una interfaz gráfica sobre el depurador gdb,
 brindando varias vistas de información para estudiar el comportamiento de la
aplicación durante su ejecución.
– Ayuda para APIs de DevHelp: Permite la visualización integrada de ayuda sobre
aquellas bibliotecas para las cuales exista documentación de desarrollo instalada en
el sistema.
– Generador de clases: Permite crear fácilmente clases C++ o GObject.

Además de las características 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 disposición de las
mismas por proyecto. Además el usuario puede configurar sus propias herramientas y
acciones de menús.
– La posibilidad de extensión se sus capacidades a través del concepto de extensiones
(plugins). Todas las características son implementadas a través de plugins, los cuales
pueden ser activados o desactivados según 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 función se da la opción 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 sincronización con CVS.

SourceForge

SourceForge es un software de colaboración para la administración 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 número 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 descripción que el desarrollador agrega.
SourceForge provee al desarrollador varias herramientas que colaboran en el desarrollo y en
la publicación de un proyecto, tales como:
– Administración vía web.
 – Uso y gestión de foros en web por cada proyecto.
– Gestión simple de grupos de trabajo, proyectos y tareas.
– Listas de correo electrónico.
– Gestión de la documentación.
– Alojamiento de páginas web sobre el proyecto, como por ejemplo página de
estadísticas del proyecto.
– Gestión de lanzamientos de versiones del software.
– Cuentas shell vía SSH y crontab.
– Servicio de CVS para desarrolladores y anónimo.

Reconocimiento de los módulos mas importantes

La implementación es descripta en base a los distintos módulos que conformarán el sistema.

Los nombres de algunos de ellos se corresponderán a los nombres de los componentes de la
arquitectura, principalmente porque definen la interfaz de comunicación para con el resto. Además
se agregarán diferentes módulos que realizan funciones especificas y colaboran con el resto de los
módulos más globales para a llevar a cabo las distintas responsabilidades de cada componente. A su
vez la presencia de estos módulos favorece aun más la modificabilidad individual de los
componentes, consecuentemente de todo el sistema.

Para el componente Motor de Resistividad colaboran los siguientes módulos:

– Motor de Resistividad (ResistivityEngine): Es el principal módulo de la aplicación ya que uno
de sus objetivos primarios es la administración de las ejecuciones de los procesos o ensayos de
resistividad eléctrica. Las ejecuciones implican la capacidad de comunicarse en forma adecuada
con los instrumentos de medición de modo que se obtengan los datos correctos en los tiempos
esperados. Además dichas ejecuciones se corresponden con un proyecto y un equipo donde
deben ejecutar, con lo cual el módulo debe conocer la forma de obtener la información
relacionada a dichos proyectos y la información 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 recuperación de todos o gran parte de los datos obtenidos
durante las ejecuciones. Los servicios e interfaz que provee son los que representan la
comunicación entre las capas de la Interfaz del Usuario y el Núcleo 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
ejecución 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 características dependientes del controlador GPIB instalado en el sistema.
Consecuentemente, ante un cambio del controlador, no debería verse afectada la
implementación del Motor de Resistividad. Utiliza la biblioteca gpib proveída junto a los
módulos GPIB, la cual provee la interfaz de programación para la comunicación y manipulación
de la tarjeta e instrumentos GPIB.
– Sincronizador de los datos del proceso (ProcessDataSynchronizer): Implementa en un hilo
de ejecución independiente el mecanismo de respaldo, hacia archivos, de los datos capturados
durante la ejecución de un proceso de resistividad.. Utilizará la biblioteca gthreads.

Para el componente Administrador de Proyectos colaboran los siguientes módulos:

– Administrador de Proyectos (ProjectManager): Permite abstraer a los módulos que lo
utilizan de la forma en que se recupera la información relacionada a los proyectos. Encapsula
cuestiones que tienen que ver con la estructura de la información de un proyecto, la estructura
de la información 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 información
almacenada en el archivo respecto a las propiedades serían 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 módulo para las
propiedades de los proyectos. Utilizará la biblioteca xml2.
– Administrador de columnas de datos (CSVFileManager): Módulo 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 módulo para almacenar los datos adquiridos durante
las mediciones. Utilizará la biblioteca csv.
 Para el componente Administrador de Dispositivos colaboran los siguientes módulos:
– Administrador de Dispositivos (DeviceManager): Permite abstraer a los módulos que lo
utilizan de la forma en que se recupera la información relacionada a los dispositivos o equipos
de resistividad, ya sea la placa de adquisición o los instrumentos programables conectados a
esta. Encapsula cuestiones que tienen que ver con la estructura de la información de un de los
archivos de configuración de los equipos y los archivos de configuración de los dispositivos
GPIB instalados en el sistema.
– Administrador de configuración de equipos (DeviceConfigFileManager): Este módulo se
encarga de actualizar, interpretar y extraer la información contenida en los archivos de
configuración de los equipos de medición (ver apéndice 4-2 en el cual se detalla la estructura del
archivo). Dicha información, junto a la brindada por el GPIBFileManager, se utiliza luego por
el componente para informar sobre la disponibilidad y estructura de los equipos de medición
configurados en el sistema. Utilizará la biblioteca xml2.
– Administrador de la configuración GPIB (GPIBFileManager): Permite actualizar,
interpretar y extraer la información de configuración de la placa de adquisición de datos y los
instrumentos programables.

Para el componente ModeloIU colaboran los siguientes módulos:

– Modelo de la Interfaz de Usuario (UIModel): El principal objetivo es mantener en diversas
estructuras de datos, fácilmente manipulables por la UIView, toda la información relacionada al
estado del ResistivityEngine (equipos ocupados, proyectos y ejecuciones activas, datos de las
ejecuciones), como también a la información de proyectos inactivos (historial de ejecuciones) y
dispositivos disponibles en el sistema (parámetros de configuración, estructura de los equipos,
etc). Adicionalmente debe garantizar el auto-guardado de la información se mantiene en
memoria como cambios en la configuración de los proyectos, de los equipos, o de la propia
interfaz de usuario. Se apoya principalmente en la biblioteca glib.
– Modelo de las gráficas de datos (PlotModel): Encapsula las estructuras de datos que utiliza las
vista PlotView facilitando además los servicios de consulta y manipulación de los mismos.
– Sincronizador de los datos de la aplicación (AppDataSynchronizer): Implementa en un hilo
de ejecución independiente el mecanismo de respaldo, hacia archivos, de la información (datos
de los proyectos, de los equipos o de la misma interfaz) que la aplicación mantiene en memoria.
Utilizará la biblioteca gthreads.

Para el componente VistaIU colaboran los siguientes módulos:

– Vista de la Interfaz de Usuario (UIView): Debe permitir la visualización, en diversas formas,
 de toda la información que provee el UIModel. Principalmente debe proveer, en forma
intuitiva, los controles visuales para: manipular las acciones sobre el Núcleo de Resistividad,
manipular distintas gráficas en tiempo real sobre los datos de las ejecuciones de un proyecto y
actualizar información de configuración 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
dinámica los componentes visuales GTK según el diseño de la interfaz de usuario descripto en
el archivo XML de Glade. Utiliza la biblioteca glade.
– Vista de las gráficas de datos (PlotView): Basándose en la clase PlPlotCanvas de la biblioteca
plplot, implementa la vista del componente visual que permite al usuario visualizar y manipular
los gráficos que representan el comportamiento de los datos adquiridos. Además de las ventajas
de PlPlotCanvas provee las siguientes funciones adicionales o personalizadas como:
actualización automática de la escala al agregar nuevos datos en forma dinámica; 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 aplicación en base a distintos eventos
internos que pudieran suceder, como por ejemplo, la obtención de un nuevo dato para un
proceso de resistividad determinado. Utilizará la biblioteca gthreads.

Para el componente ControladorIU colaboran los siguientes módulos:

– Controlador de la Interfaz de Usuario (UIController): Captura todos los eventos iniciados
por acciones del usuario sobre la interfaz visual de la aplicación. Debe tomar las primeras
decisiones sobre como tratar dichos eventos, generalmente invocación a servicios especializados
del UIModel o la UIView. Utiliza la biblioteca gtk y gdk.

Diagrama de módulos

En la Figura 1 se puede visualizar todo el conjunto de módulos y sus interrelaciones más las
dependencias para con las bibliotecas más destacadas en las cuales se apoyan.
Figura 1: Módulos de cada componente de la aplicación RHOcker
Soluciones de software de aplicación existentes

En esta sección se realiza un análisis 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 características incluyendo además la
solución propuesta en el presente trabajo. De cada software analizado se analizan las siguientes
características: compatibilidad con los equipos presentes en el instituto, plataformas, licencias,
gestión de los controladores, conectividad, etc.

LabVIEW
Es una herramienta gráfica que permite la realización de pruebas, control y diseño de los
procesos de medición mediante un lenguaje de programación gráfico 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 medición. 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 día se encuentra
disponible para las plataformas Windows, UNIX, MAC y Linux.
Además de utilizarse para adquisición y análisis matemático de los datos obtenidos y la
comunicación o control de instrumentos de cualquier fabricante, provee una interfaz para diseño
electrónico y aplicaciones en el campo de la robótica.
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 comunicación mas populares.
– Además de los módulos de captura posee módulos para el análisis matemático de los
datos.
Entre las desventajas, podemos resaltar:
– Alto costo de las licencias (desde u$s 1200).
– Imposibilidad de adaptación para procesos de adquisición más específicos como es
el caso de IFIMAT.
– Las gráficas que genera el software no concuerdan con las necesarias en los ensayos
de resistividad eléctrica del instituto.
 – Debido a la cantidad de opciones que provee hace compleja la iniciación de una
medición, teniendo en cuenta que se debe programar la medición que se quiere
realizar.
– National Instruments lo construyó pensando en sus instrumentos, podría haber
problemas de compatibilidad con otros instrumentos ya que requiere de
controladores adicionales.
– Los controladores deben ser específicos para LabView.
– Todo en Labview se basa en la programación visual o gráfica, con lo cual el usuario
se ve obligado a poseer conocimiento sobre la configuración de la placa de
adquisición de datos y los instrumentos.

KE5FX GPIB Toolkit

Es un software que permite la captura de los datos de un instrumento y genera gráficas. Los
gráficos son simples pero no son configurables, tampoco es posible modificar la forma de
adquisición, ni programarla de ninguna forma. Solo tiene versiones del producto para el sistema
operativo Windows y no es software libre, sino que se distribuye bajo una licencia Freeware.

Delaytor
Software diseñado para un instrumento especifico, sin ser compatible con los instrumentos
del IFIMAT. Simplemente se encarga de obtener la medición de un determinado instrumento sin
posibilidad de generar gráficas ni programar las mediciones. Corre únicamente bajo plataforma
Windows y su distribución es en modo Freeware.

FreeVIEW
FreeVIEW es un software de control, monitoreo y captura de datos de instrumentos GPIB,
especialmente indicado para instrumentos de medición de sonido. Tiene la posibilidad de generar
gráficos, pero optimizados para el tipo de medición mencionado. Además solo está disponible para
instrumentos del fabricante National Instruments. Es un software propietario y funciona únicamente
en la plataforma Windows.

TestPad Development Studio

Proyecto en el cual se ha desarrollado una implementación base para desarrollo de
aplicaciones para medición y control de instrumentos. Colabora en la conexión con la placa de
adquisición de datos y de esta con los equipos de medición. El punto mas interesante del proyecto
es la capacidad de configurar cualquier instrumentos programable a través de un conjunto de
parámetros genéricos, evitando la necesidad de instalar controladores específicos para cada
dispositivo de medición.
Aunque permite almacenar los resultados de la medición en archivos base de datos, no
brinda la posibilidad de configurar los gráficos que genera, ni tampoco reescalarlos en forma
automática.
Solo se encuentra disponible para instrumentos de la marca National Instruments o Agilent y
plataforma Windows. Además se distribuye con Licencia Freeware.

RHOcker
Corresponde al desarrollo descripto en el presente trabajo. El objetivo principal consiste en
el control y monitoreo de ensayos de resistometría eléctrica. Para llevar a cabo ese objetivo soporta
la comunicación con un equipo GPIB completo que incluye una placa capturadora de datos, un
multímetro, un nanovoltímetro y una fuente de corriente.
Desde la aplicación se pueden crear, iniciar, pausar y detener un proceso de adquisición de
datos para el contexto mencionado. Además permite visualizar por pantalla en tiempo real todas las
mediciones en forma textual y en forma gráfica se puede observar y analizar el comportamiento de
los datos adquiridos y las fórmulas calculadas en base a los mismos. Puede seleccionarse hasta tres
tipos de gráficas según las variables que estas incluyan: resistencia vs tiempo, resistencia vs
temperatura y temperatura vs tiempo.
En la tabla 2 se puede observar la comparación de RHOcker con los proyectos antes
mencionados. Las referencias para dicha tabla son las siguientes:
– Licencia: licencia con la que se distribuye el software.
– Gráficos: capacidad para generar gráficas de las mediciones.
– Gráficos auto ajustables: capacidad de que los gráficos sean auto-ajustables conforme
a las mediciones obtenidas.
– Captura de datos: capacidad para la captura de datos desde un dispositivo.
– Plataformas: plataformas en las que se puede ejecutar el software.
– Gestión de controladores: capacidad de gestionar, a través de sus controladores, los
instrumentos instalados en el sistema.
– Conexión USB: capacidad de conexión a través de una placa de adquisición de datos
USB.
– Post-procesamiento: herramientas de post-procesamiento de los datos obtenidos.
 Tabla 2 - Comparación de soluciones de medición y monitoreo para ensayos

Soluciones de post-procesamiento datos

El post-procesamiento de los datos obtenidos de la medición incluye además de poder

importar los datos generados por la aplicación, poder generar gráficas sobre el comportamiento del
material medido, aplicarle algunas operaciones del calculo diferencial e integral, como así también
poder exportar las gráficas de estas funciones a imágenes para poder agregar datos de la medición
en informes o investigaciones.

En el proceso de selección de la aplicación para realizar las tareas de procesamiento se tuvieron en

cuenta los siguientes aspectos:

-Licencia
-Funcionalidad total requerida
-Simplicidad de manejo
-Facilidad de instalación

Para eso se hizo un análisis de las mejores soluciones disponibles para GNU/Linux y aquí los
resultados:

Scigraphica
http://scigraphica.sourceforge.net
Ventajas
-Licencia GNU GPL
-Genera gráficas en 2 y tres dimensiones
-Importa datos numéricos

Desventajas
-No exporta las gráficas a imágenes
-No contiene la capacidad de ejecutar funciones de calculo diferencial e integral
-No se encuentra en los repositorios oficiales de la distribución GNU-Linux Debian
-La ultima versión publicada data de 2005, por lo que ha quedado bastante relegada por productos
mas modernos.

RlPlot
http://rlplot.sourceforge.net
Ventajas
-Licencia GNU GPL
-Genera gráficas de gran calidad
-Esta disponible en los repositorios oficiales de la distribución GNU-Linux Debian

Desventajas
-No exporta las gráficas a imágenes
-No contiene la capacidad de ejecutar funciones de calculo diferencial e integral
-No tiene la funcionalidad de importar datos numéricos

KmPlot
http://edu.kde.org/kmplot
Ventajas
-Forma parte del entorno de escritorio KDE y tiene muchos años de desarrollo.
-Se encuentra disponible en la distribución GNU-Linux Debian
-Tiene la capacidad de generar gráficas de gran calidad y poder exportarlas fácilmente a imágenes
-Tiene la posibilidad de aplicar a las gráficas la funciones de calculo diferencial e integral

Desventajas
-La sintaxis de las funciones a la hora de generar las gráficas puede resultar complicada
-No tiene la funcionalidad de importar datos numéricos

LabPlot
http://labplot.sourceforge.net/
Ventajas
-Genera gráficas de funciones de una forma muy simple
-Puede importar datos numéricos
-Tiene la funcionalidad de exportar las gráficas a imágenes
-Tiene la posibilidad de aplicar a las gráficas la funciones de calculo diferencial e integral
-Se encuentra disponible en la distribución GNU/Linux Debian

Desventajas
-En los repositorios oficiales de GNU/Linux Debian no se encuentra la ultima versión que contiene
varios errores de la interface solucionados.

Por estas razones se eligió a LabPlot como la mejor alternativa, ya que cumple con todos los
requerimientos necesarios para el post-procesamiento de los datos, incluso es muy simple de utilizar
para todas las opciones que posee, como la importación de los datos numéricos y ejecución de las
funciones de calculo, ya que con un breve conjunto de clicks ya se obtienen los resultados
necesarios.

En el apéndice 4 se anexa un breve manual de uso de la aplicación con todas las funcionalidades
requeridas para el post procesamiento de los datos obtenidos de la medición.
Conclusiones

El trabajo desarrollado arroja varias conclusiones que tienen que ver con varios aspectos: con el
proyecto en si mismo, con el aporte a la comunidad universitaria, con el aporte a la comunidad de
software libre, además de los resultados obtenidos de la colaboración interdisciplinaria, el avance
que se logró con el software construido y por ultimo las grandes posibilidades de extender el
proyecto.
Este proyecto permitió recorrer todas las fases de desarrollo de un proyecto completo:
-Captura de requerimientos.
-Análisis.
-Investigación.
-Diseño de la solución.
-Implementación de la solución.
-Testeos y documentación.

Por estas razones se completa un ciclo completo de un proyecto completo de ingeniería de sistemas,
desde las reuniones iniciales con los integrantes del IFIMAT, pasando por la captura completa de
los requerimientos, el análisis y la investigación que hubo que realizar para resolver el problema
planteado, como así también el diseño y la implementación de la solución propuesta.

Algunos aspectos con respecto a la forma en que se desarrollo el trabajo tienen que ver con la solida
comunicación y el trabajo interdisciplinario logrado entre la Facultad de Ciencias Exactas, contando
a los integrantes de este proyecto como así el director elegido, con los integrantes del IFIMAT, ya
que desde el primer momento la predisposición y la voluntad ofrendada fueron fundamentales para
el desarrollo del proyecto.

Con respecto al aporte al IFIMAT, también debe considerarse la utilidad que se le dará al software
construido. Las investigaciones que realizan en el instituto constituyen un aporte muy importante a
la comunidad tandilense, sobre todo en sectores fabriles donde se solicitan estudios de materiales y
su reacción a la electricidad y la temperatura, para luego ser utilizados en productos que se
comercializan aquí y se exportan a varios lugares del mundo. Por esta razón es fundamental que el
IFIMAT contenga todas las herramientas posibles para obtener mejores resultados en las medición
y facilitar el estudio de los materiales.

El aporte al instituto no termina con la facilidad de mejorar las investigaciones, sino también con la
posibilidad que genera este proyecto de fomentar otro tipo de investigaciones relacionadas al
estudio de materiales y con el uso de los instrumentos de medición y su interacción con la PC.

A nivel investigación el proyecto contemplo dos aspectos importantes, la comparación con

soluciones de software de aplicación disponibles y la posibilidad de utilizar soluciones de calculo
numérico como post-procesamiento de los datos. Al buscar soluciones al problema planteado desde
el IFIMAT se encontró que en el mundo del software libre no se encontraba una solución que
pudiera adaptarse al problema. En el mundo del software comercial tampoco ya que ante la
imposibilidad de adaptar una solución existente queda inviable la implementación en el IFIMAT.
En el rubro de post-procesamiento de la información no se corrió la misma suerte, hubo varios
proyectos de software libre a analizar y se eligió el que tenia las características necesarias en este
momento, en el futuro podrían requerirse mas funciones que seguramente estarán contempladas en
varios de los proyectos analizados.

El aporte a la comunidad del software libre es otra de las conclusiones importantes, además de la
necesidad de fomentar el uso y el desarrollo de este tipo de proyectos, que garantiza el acceso al
código fuente del software desarrollado, como así también facilita la redistribución y la
colaboración mutua entre desarrolladores en cualquier parte del mundo. Desde la facultad de
Ciencias Exactas y el IFIMAT es importante que se promocionen y se fomente la implementación
de proyectos de esta índole. Este proyecto desde sus orígenes fue realizado con software libre y
también todo lo relacionado con la implementación, testeos, entorno de desarrollo y software de
base es software libre.

Por ultimo, se enumeran las posibles extensiones que se pueden realizar al software construido y a
los módulos que lo componen. El desarrollo de toda la aplicación se mantuvo ordenado de tal forma
que sea bastante cómodo realizar pequeños cambios y modificaciones para agregar, quitar o
modificar funcionalidad. Las posibles extensiones podrían utilizarse para otro proyecto de trabajo
final de ingeniería de sistemas o proyecto de investigación del IFIMAT.

-Administración vía Web:

La aplicación podría portarse sin problemas a un entorno web que contenga todas las funciones
actuales. Esto garantizara una administración remota de los procesos de medición y de captura de
datos de estas mediciones.

-Configuración del controlador para utilizar una placa capturadora mediante el puerto USB:
Muchos fabricantes de instrumentos y placas capturadoras ya están ofreciendo en el mercado una
evolución de placas capturadoras de datos a través del puerto USB. Tener una placa USB permite
una flexibilidad a la hora de utilizar la PC, ya que se podría usar cualquier PC portátil o portar la
captura de datos a cualquier PC. La idea de la portabilidad hacia una placa USB es configurar o
recompilar el controlador instalado para que la reconozca y funcione de la misma manera que una
placa PCI.

-Administración de datos obtenidos vía web:

Relacionado con el primer punto, si no se puede portar la aplicación completamente, se puede crear
un sitio web que permita obtener los datos y hacer el post-procesamiento de estos datos, como por
ejemplo generar gráficas de integrales o derivadas o hacer cálculos matemáticos.

-Extensión de la aplicación para otros instrumentos:

En el futuro podrían agregarse otros instrumentos que realicen mediciones distintas y que la
aplicación necesite capturar los datos de otra forma, como los gráficos deberían mostrar otro tipo de
datos, incluso necesitar alguna funcionalidad extra. Sin embargo gran parte de la aplicación como el
controlador instalado podrían reutilizarse.

-Gestión de dispositivos:
La gestión de dispositivos desde la aplicación actualmente no se realiza, cada vez que se desee
agregar un dispositivo de medición debe configurarse desde el controlador instalado en la
plataforma y además no se puede agregar un conjunto de comandos SCPI para poder realizar otro
tipo de mediciones que no solamente estén relacionadas a la resistividad.

-Portabilidad de plataforma:
La portabilidad del sistema a otra plataforma podría ser una extensión del trabajo realizado, incluso
podría programarse otro sistema que sea multiplataforma y que gestionando los controladores como
se planteo en el punto anterior pudiera funcionar sin problemas en varias plataformas de sistemas
operativos.

-Post-procesamiento de los datos:

El ultimo punto a extender podría ser el desarrollo de una aplicación de post-procesamiento de los
datos obtenidos en el sistema que cumpla con todos los requerimientos del instituto IFIMAT a la
hora de analizar los datos obtenidos de las mediciones.
elm, R. Johnson, J. Vlissides. Addison-Wesley, 1995.