Implementación y Análisis de Desempeño del Protocolo de Instrumentación IICP sobre el Canal de Comunicación IEEE 1394 Edición Única

Texto completo

(1)INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY CAMPUS MONTERREY PROGRAMA DE GRADUADOS EN ELECTRÓNICA, COMPUTACIÓN, INFORMACIÓNY COMUNICACIONES. Implementación y Análisis de Desempeño del Protocolo de Instrumentación IICP sobre el Canal de Comunicación IEEE 1394. TESIS PRESENTADA COMO REQUISITO PARCIAL PARA OBTENER EL GRADO ACADEMICO DE: MAESTRO EN Maestrı́a en Ciencias con especialidad en Ingenierı́a Electrónica (Telecomunicaciones). POR: Milton Rodrı́guez Guerrero. MONTERREY , N.L.. Mayo 2005.

(2)

(3) INSTITUTO TECNOLÓGICO DE ESTUDIOS SUPERIORES DE MONTERREY DIVISIÓN DE ELECTRÓNICA, COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES PROGRAMAS DE GRADUADOS EN ELECTRÓNICA, COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES Los miembros del comité de tesis recomendamos que la presente tesis del Ingeniero en Electrónica y Telecomunicaciones Milton Rodrı́guez Guerrero sea aceptada como requisito parcial para obtener el grado académico de Maestro en Maestrı́a en Ciencias con especialidad en Ingenierı́a Electrónica (Telecomunicaciones). Comité de tesis:. Dr. Alfonso Ávila Ortega Asesor. Dr. Manuel Macias González Sinodal. M.C. Luis Molina Hernández Sinodal. Dr. David Garza Salazar Director del Programa de Graduados en Electrónica, Computación, Información y Comunicaciones. Mayo, 2005.

(4)

(5) Implementación y Análisis de Desempeño del Protocolo de Instrumentación IICP sobre el Canal de Comunicación IEEE 1394. POR: Milton Rodrı́guez Guerrero. TESIS Presentada al Programa de Graduados en Electrónica, Computación, Información y Comunicaciones. Este trabajo es requisito parcial para obtener el grado de Maestro en Maestrı́a en Ciencias con especialidad en Ingenierı́a Electrónica (Telecomunicaciones). INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY. Mayo, 2005.

(6) c Milton Rodrı́guez Guerrero, 2005.

(7) Te damos gracias, Señor Dios Todopoderoso, el que eres, que eras y que has de venir Ap 11:17.

(8) Gracias Dios Padre por siempre estar presente en mi corazón y llenarlo con tu amor. Agradezco las enseñanzas y ánimos de mi Señor Jesucristo durante el transcurso de mi vida. Gracias Espı́ritu Santo por tu guı́a y comprensión tan indispensables a cada instante.. Mi trabajo está dedicado con amor a mis papás Sara y Jorge, a mi hermana Georgina y mis sobrinos Jorge Manuel, Regina y Andrés, a mi hermana Guinett y mi sobrino Jorge Raúl, a mis abuelitos Margarita y Zenaido, que descansan en Paz, a todos ustedes gracias por su amor y confianza.. También dedico este trabajo con mucho amor a mi novia y prometida Karime. Gracias por siempre amarme y creer en mı́, por animarme y ayudarme a salir adelante.. Finalmente agradezco a la Sra. Esperanza y Sra. Angélica, por darme alojamiento y su completa amistad.

(9) Reconocimientos ITESM Campus Monterrey, por darme la oportunidad de aceptarme como alumno y permitirme realizar mis estudios de maestrı́a.. Mi más sincera gratitud a mi asesor de tesis Dr. Alfonso Ávila Ortega, por su tiempo y apoyo invertido en la presente investigación, por sus conocimientos y consejos que fueron clave para concluir este trabajo.. También agradezco al Dr. Manuel Macias González y M.C. Luis Molina Hernández, miembros del comité de tesis, por sus comentarios y observaciones que ayudaron a mejorar y afinar este documento.. A todos mis profesores de la maestrı́a, Dr. César Vargas Rosales, Dr. Ramón M. Rodrı́guez, Dr. David Muñoz, Dr. José Ramón Rodrı́guez y M.C. Artemio Aguilar, agradezco sus enseñanzas y amistad.. Milton Rodrı́guez Guerrero Instituto Tecnológico y de Estudios Superiores de Monterrey Mayo 2005.

(10) Implementación y Análisis de Desempeño del Protocolo de Instrumentación IICP sobre el Canal de Comunicación IEEE 1394. M.C. Milton Rodrı́guez Guerrero Instituto Tecnológico y de Estudios Superiores de Monterrey, 2005. Resumen Los sistemas de instrumentación actualmente utilizan el estándar IEEE 488 (GPIB) como principal canal de comunicación, pero las aplicaciones continúan experimentando un gran crecimiento, donde constantemente estos sistemas tienen que transmitir a mayores tasas. En los sistemas de automatización de mediciones y pruebas, la reducción de costos es el principio de las aplicaciones que utilizan canales de comunicación comerciales como Ethernet, USB y FireWire, donde estas tecnologı́as proveerán múltiples ventajas, tal como presencia estándar en los equipos de cómputo, mayores tasas de transmisión, flexibilidad, mejores rendimientos y aplicación en otros proyectos que no son de instrumentación. En este trabajo se investiga el desempeño del protocolo de instrumentación IICP (Instrument and Industrial Control Protocol ), que corre sobre el canal serial FireWire (IEEE 1394a) con una tasa de transmisión hasta de 400 Mbps. La implementación del protocolo IICP se realiza mediante programación orientada a objetos en C++ y utilizando el FireWire–API de Unibrain. La evaluación de IICP incluye pruebas para analizar el desempeño con diferentes tipos de instrumentos como osciloscopios y multı́metros digitales. El objetivo es presentar una comparación entre GPIB y los protocolos de instrumentación en los canales comerciales como Ethernet (VXI–11), USB (USBTMC-USB488) y FireWire (IICP)..

(11) Índice general 1. Introducción. 1. 1.1. Descripción del Problema y Justificación . . . . . . . . . . . . . . . . . . . . . .. 2. 1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3. 1.3. Contribución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3. 1.4. Organización de la Tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4. 2. Antecedentes y Fundamentos. 5. 2.1. Caracterı́sticas del Reemplazo de IEEE 488 . . . . . . . . . . . . . . . . . . . . .. 5. 2.2. Descripción de los Reemplazos de IEEE 488 . . . . . . . . . . . . . . . . . . . .. 9. 2.2.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 9. 2.2.2. Universal Serial Bus (USB) . . . . . . . . . . . . . . . . . . . . . . . . .. 9. 2.2.3. IEEE 1394 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3. Selección del Reemplazo de IEEE 488 . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.2. USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.3. IEEE 1394 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4. Implicaciones de Conexión IEEE 1394 . . . . . . . . . . . . . . . . . . . . . . . . 13 2.5. Fundamentos del canal IEEE 488 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.5.1. IEEE 488.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5.2. IEEE 488.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.5.3. Estándar SCPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5.4. HS488, IEEE 488 de Alta Velocidad . . . . . . . . . . . . . . . . . . . . . 20 2.6. Fundamentos del canal IEEE 1394 . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.6.1. Razones para Utilizar IEEE 1394 . . . . . . . . . . . . . . . . . . . . . . 21 2.6.2. Ventajas de IEEE 1394 sobre IEEE 488 . . . . . . . . . . . . . . . . . . . 22 2.6.3. Estándares y Documentos Relacionados . . . . . . . . . . . . . . . . . . . 22 2.6.4. Arquitectura IEEE 1394 . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 xi.

(12) ÍNDICE GENERAL. xii. 2.6.5. Arquitectura de Nodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.6.6. Espacio de Memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3. Protocolo IICP. 26. 3.1. Descubrimiento de Funcionalidad . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.1. Configuración de ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2. Memoria direccionada para entrada/salida . . . . . . . . . . . . . . . . . . . . . 36 3.2.1. Mecanismo de Interrupción para dispositivos IICP con memoria direccionada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.2.2. Limitaciones de memoria direccionada para entrada/salida . . . . . . . . 40 3.3. Conexión ası́ncrona de IICP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.3.1. Paquetes de Información IICP . . . . . . . . . . . . . . . . . . . . . . . . 41 3.3.2. Arquitectura de Conector IICP . . . . . . . . . . . . . . . . . . . . . . . 42 3.3.3. Descripción de los Registros del Conector IICP . . . . . . . . . . . . . . 44 3.3.4. Operaciones permitidas en los registros del Conector IICP . . . . . . . . 51 3.3.5. Transferencia de Paquetes Grandes . . . . . . . . . . . . . . . . . . . . . 51 3.3.6. Transferencia de Paquetes Pequeños . . . . . . . . . . . . . . . . . . . . . 53 3.3.7. Mezcla entre Transferencia de Paquetes Pequeños y Grandes . . . . . . . 54 3.3.8. Esquema de Conector IICP . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.3.9. Múltiples Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4. Implementación del Protocolo IICP. 56. 4.1. Análisis de Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.1.1. Modelo de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.2. Diseño de Clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.2.1. Transformar Objetos del Análisis de Requerimientos . . . . . . . . . . . . 62 4.2.2. Identificar Operaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.3. Diseño de Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.3.1. Sistema Operativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.3.2. Lenguaje de Programación . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.3.3. Interfaz IEEE 1394 (API) . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.4. Consideraciones de Implementación . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.4.1. Algoritmos Propuestos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66.

(13) ÍNDICE GENERAL 5. Metodologı́a y Resultados. xiii 71. 5.1. Medidas de Desempeño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.1.1. Calidad de Servicio, (QoS) . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.2. Pruebas de Desempeño IEEE 488 . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.2.1.. % Utilización Ancho de Banda . . . . . . . . . . . . . . . . . . . . . . . 74. 5.2.2. Latencia del 1o Byte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.2.3. Latencia Completa de 10 Bytes . . . . . . . . . . . . . . . . . . . . . . . 79 5.2.4. Respuesta en Frecuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.3. Pruebas de Desempeño IEEE 1394 . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.3.1.. % Utilización Ancho de Banda . . . . . . . . . . . . . . . . . . . . . . . 82. 5.3.2. Latencia del 1o Byte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.3.3. Latencia Completa de 10 Bytes . . . . . . . . . . . . . . . . . . . . . . . 88 5.3.4. Respuesta en Frecuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.4. Comparación de Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.4.1. Eficiencia de Protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.4.2. Tiempos de Latencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.4.3. Respuesta en Frecuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 6. Conclusiones y Futuras Investigaciones. 99. 6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 6.2. Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 6.3. Futuras Investigaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 A. Ambiente de Pruebas. 102. A.1. Instrumentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 A.2. Equipo de Cómputo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 A.3. IEEE 488 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 A.3.1. % Utilización Ancho de Banda . . . . . . . . . . . . . . . . . . . . . . . 103 A.3.2. Latencia del 1o Byte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 A.4. IEEE 1394 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 A.4.1. Clase IICP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 A.4.2. Clase CMGR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 A.4.3. Procedimiento main() para CMGR . . . . . . . . . . . . . . . . . . . . . 111 A.4.4. Clase CCLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 A.4.5. Procedimiento main() para CCLI . . . . . . . . . . . . . . . . . . . . . . 113.

(14) ÍNDICE GENERAL. xiv B. Resultados de Mediciones. 115. B.1. Utilización del Ancho de Banda . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 B.1.1. Latencia del 1o Byte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 B.1.2. Latencia Completa de 10 Bytes . . . . . . . . . . . . . . . . . . . . . . . 118 B.1.3. Respuesta en Frecuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Glosario. 125. Vita. 130.

(15) Índice de figuras 2.1. Utilización de Ethernet, USB e IEEE 1394 en los sistemas de instrumentación .. 6. 2.2. Nivel de conocimientos generales de Ethernet, USB e IEEE 1394 . . . . . . . . .. 8. 2.3. Sistema de instrumentación con conexión Ethernet . . . . . . . . . . . . . . . . 11 2.4. Sistema de instrumentación con conexión central USB . . . . . . . . . . . . . . . 12 2.5. Sistema central IEEE 1394 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.6. Sistema en cadena IEEE 1394 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.7. Conexión IEEE 488 en cadena . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.8. Conexión IEEE 488 en estrella . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.9. Conexión entre dispositivos IEEE 488, sin controlador . . . . . . . . . . . . . . . 14 2.10. Conector IEEE 488 con asignación de lı́neas de señales y tierra . . . . . . . . . . 15 2.11. Particiones de un instrumento IEEE 488.1 . . . . . . . . . . . . . . . . . . . . . 16 2.12. Modelo de instrumentación SCPI . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.13. Equipo de cómputo con adaptador IEEE 1394 . . . . . . . . . . . . . . . . . . . 23 2.14. Extensión del canal IEEE 1394 utilizando nodos . . . . . . . . . . . . . . . . . . 24 2.15. Arquitectura IEEE 1394 de módulo, nodo y unidades . . . . . . . . . . . . . . . 24 2.16. Arquitectura IEEE 1394 de módulo, nodo y unidades . . . . . . . . . . . . . . . 25 2.17. Arquitectura IEEE 1394 de módulo, nodo y unidades . . . . . . . . . . . . . . . 25 3.1. Rango de direcciones para configuración de ROM . . . . . . . . . . . . . . . . . 27 3.2. Formato general de ROM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28. 3.3. Campos del bloque header info . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.4. Campos del bloque header info . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.5. Campos del bloque root directory . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.6. Formato de descripción de campo (Textual Descriptor) . . . . . . . . . . . . . . 32 3.7. Campos del bloque instance directory . . . . . . . . . . . . . . . . . . . . . . . . 32 3.8. Campos del bloque descripción clave . . . . . . . . . . . . . . . . . . . . . . . . 33 3.9. Campos del bloque unit directory . . . . . . . . . . . . . . . . . . . . . . . . . . 34 xv.

(16) xvi. ÍNDICE DE FIGURAS. 3.10. Descripción de la clave de modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.11. Rango de espacio de memoria privada . . . . . . . . . . . . . . . . . . . . . . . . 36 3.12. Formato y comportamiento del registro interrupt enable. . . . . . . . . . . . . . 38. 3.13. Formato y comportamiento del registro interrupt handlr . . . . . . . . . . . . . 39 3.14. Conexión IICP entre equipo de cómputo y dispositivo de instrumentación . . . . 41 3.15. Espacio de memoria de registros . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.16. Registros públicos de control, para conexión IICP . . . . . . . . . . . . . . . . . 43 3.17. Registros de control privados, para conexiones ası́ncronas IICP . . . . . . . . . . 44 3.18. Formato y comportamiento del registro ProducerLimits . . . . . . . . . . . . . . 44 3.19. Formato y comportamiento del registro base PageTableElement . . . . . . . . . 46 3.20. Rango de espacio de memoria inicial del nodo . . . . . . . . . . . . . . . . . . . 46 3.21. Formato y comportamiento del registro SmallFrameProducer . . . . . . . . . . . 47 3.22. Formato y comportamiento del registro LargeFrameProducer . . . . . . . . . . . 48 3.23. Formato y comportamiento del registro SmallFrameConsumer . . . . . . . . . . 50 3.24. Formato y comportamiento del registro LargeFrameConsumer . . . . . . . . . . 50 3.25. Flujo general en la transferencia de paquetes grandes . . . . . . . . . . . . . . . 52 3.26. Flujo general en la transferencia de paquetes pequeños . . . . . . . . . . . . . . 53 3.27. Esquema de conexión IICP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.28. Esquema simplificado de conexión IICP . . . . . . . . . . . . . . . . . . . . . . . 55 3.29. Múltiples conexiones IICP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.1. Diagrama de Casos de Uso para nodo CMGR . . . . . . . . . . . . . . . . . . . 59 4.2. Diagrama de Casos de Uso para nodo CCLI . . . . . . . . . . . . . . . . . . . . 59 4.3. Diagrama de Casos de Uso para Productor y Consumidor . . . . . . . . . . . . . 60 4.4. Diagrama de interacción para establecer conexión IICP . . . . . . . . . . . . . . 61 4.5. Diagrama de interacción para el envı́o de paquetes grandes . . . . . . . . . . . . 62 4.6. Diagrama de interacción para el envı́o de paquetes pequeños . . . . . . . . . . . 62 4.7. Definición básica de clases para el protocolo IICP . . . . . . . . . . . . . . . . . 63 4.8. Definición básica de clases para el protocolo IICP . . . . . . . . . . . . . . . . . 63 4.9. Definición básica de clases para el protocolo IICP . . . . . . . . . . . . . . . . . 64 4.10. Arquitectura lógica del protocolo IICP . . . . . . . . . . . . . . . . . . . . . . . 65 4.11. Arquitectura de la interfaz Unibrain–FireAPI . . . . . . . . . . . . . . . . . . . 66 5.1. Ambiente de prueba para análisis de utilización ancho de banda . . . . . . . . . 74 5.2. Tiempos de transmisión para IEEE 488 con diferentes tamaños de bloques . . . 75.

(17) ÍNDICE DE FIGURAS. xvii. 5.3. Rendimiento total de IEEE 488 . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.4. Porcentaje de utilización del ancho de banda para IEEE 488 . . . . . . . . . . . 77 5.5. Ambiente de prueba para análisis de latencia 1o byte . . . . . . . . . . . . . . . 78 5.6. Tiempo de latencia 1 Byte para IEEE 488 . . . . . . . . . . . . . . . . . . . . . 78 5.7. Ambiente de prueba para análisis de latencia completa 10 bytes . . . . . . . . . 79 5.8. Tiempo de latencia completa 10 Bytes para IEEE 488 . . . . . . . . . . . . . . . 80 5.9. Ambiente de prueba para análisis de respuesta en frecuencia . . . . . . . . . . . 80 5.10. Diagrama de Bode para el canal IEEE 488 . . . . . . . . . . . . . . . . . . . . . 83 5.11. Ambiente de prueba para análisis de utilización ancho de banda . . . . . . . . . 84 5.12. Tiempos de transmisión para IEEE 1394 con diferentes tamaños de bloques . . . 85 5.13. Rendimiento total de IEEE 1394 . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.14. Porcentaje de utilización del ancho de banda para IEEE 1394 . . . . . . . . . . 87 5.15. Ambiente de prueba para análisis de latencia 1o byte . . . . . . . . . . . . . . . 87 5.16. Tiempo de latencia 1 Byte para IEEE 1394 . . . . . . . . . . . . . . . . . . . . . 88 5.17. Ambiente de prueba para análisis de latencia completa 10 bytes . . . . . . . . . 89 5.18. Tiempo de latencia completa 10 Bytes para IEEE 1394 . . . . . . . . . . . . . . 89 5.19. Ambiente de prueba para análisis de respuesta en frecuencia . . . . . . . . . . . 90 5.20. Diagrama de Bode para el canal IEEE 1394 . . . . . . . . . . . . . . . . . . . . 93 5.21. Comparación entre tiempo de transmisión y tasa real de transmisión . . . . . . . 93 5.22. Comparación de desempeño entre los protocolos GPIB e IICP . . . . . . . . . . 94 5.23. Comparación de la tasa de transmisión . . . . . . . . . . . . . . . . . . . . . . . 95 5.24. Comparación de desempeño entre IICP y otros sustitutos de GPIB . . . . . . . 95 5.25. Comparación de los tiempos de latencia . . . . . . . . . . . . . . . . . . . . . . . 96 5.26. Capacidad de procesamiento de consultas y respuestas . . . . . . . . . . . . . . 97 5.27. Señal senoidal 10 Hz, de entrada u(t) al canal y salida y(t) . . . . . . . . . . . . 97 5.28. Sistema de control utilizando proceso de medición . . . . . . . . . . . . . . . . . 98 5.29. Diagramas de Bode para análisis en frecuencia . . . . . . . . . . . . . . . . . . . 98 A.1. Ejemplo LabVIEW para leer y escribir a instrumentos GPIB . . . . . . . . . . . 107.

(18) Índice de cuadros 2.1. Comparación entre IEEE 488, IEEE 1394, USB y Ethernet . . . . . . . . . . . .. 7. 2.2. Comparación de costos entre IEEE 488, Ethernet, USB e IEEE 1394 . . . . . . .. 8. 2.3. Direcciones y mensajes de interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4. Secuencias de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.5. Protocolos de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.6. Mensajes de dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1. Definición de la estructura de configuración de ROM . . . . . . . . . . . . . . . 28 3.2. Definición de los campos del directorio raı́z . . . . . . . . . . . . . . . . . . . . . 30 3.3. Definición de los campos del directorio raı́z . . . . . . . . . . . . . . . . . . . . . 31 3.4. Definición de los campos básicos del directorio unitario . . . . . . . . . . . . . . 33 3.5. Definición de la extensión de campos del directorio unitario . . . . . . . . . . . . 35 3.6. Valores posibles del campo maxIntLength. . . . . . . . . . . . . . . . . . . . . . 40. 3.7. Valores posibles del campo maxLoad . . . . . . . . . . . . . . . . . . . . . . . . 45 3.8. Tamaño de página de memoria, para transferencia de paquetes . . . . . . . . . . 49 3.9. Valores del campo mode, en el registro LargeFrameConsumer . . . . . . . . . . . 51 4.1. Clase semáforo para manejo de instancias . . . . . . . . . . . . . . . . . . . . . . 67 4.2. Funciones para manejo de instancias . . . . . . . . . . . . . . . . . . . . . . . . 67 4.3. Clase para manejo de excepciones . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.4. Utilización de Apuntadores en C++ . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.5. Definición de la clase para administración de memoria . . . . . . . . . . . . . . . 70 5.1. Parámetros de calidad, para diferentes tipos de instrumentos . . . . . . . . . . . 72 5.2. Tiempos de transmisión para IEEE 488 con diferentes tamaños de bloques . . . 75 5.3. Rendimiento total para IEEE 488 con diferentes tamaños de archivos . . . . . . 76 5.4. Porcentaje de utilidad del ancho de banda para IEEE 488 . . . . . . . . . . . . . 77 5.5. Latencia 1 Byte para IEEE 488 . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 xviii.

(19) ÍNDICE DE CUADROS. xix. 5.6. Latencia completa de 10 Bytes para IEEE 488 . . . . . . . . . . . . . . . . . . . 79 5.7. Magnitud de la función de transferencia del canal IEEE 488 . . . . . . . . . . . 81 5.8. Fase de la función de transferencia del canal IEEE 488 . . . . . . . . . . . . . . 82 5.9. Tasa de transmisión protocolo IEEE 1394a . . . . . . . . . . . . . . . . . . . . . 83 5.10. Tiempos de transmisión para IEEE 1394 con diferentes tamaños de bloques . . . 84 5.11. Rendimiento total para IEEE 1394 con diferentes tamaños de archivos . . . . . . 85 5.12. Porcentaje de utilidad del ancho de banda para IEEE 1394 . . . . . . . . . . . . 86 5.13. Latencia 1 Byte para IEEE 1394 . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.14. Latencia completa de 10 Bytes para IEEE 1394 . . . . . . . . . . . . . . . . . . 89 5.15. Magnitud de la función de transferencia del canal IEEE 1394 . . . . . . . . . . . 91 5.16. Fase de la función de transferencia del canal IEEE 1394 . . . . . . . . . . . . . . 92.

(20) Capı́tulo 1 Introducción El temor del Señor es el principio del conocimiento Pr 1:7. La industria de mediciones y pruebas, evoluciona de acuerdo a las necesidades de los sistemas de instrumentación, que se implementan en diferentes ramas de aplicaciones como telecomunicaciones, industria automotriz, biomédica, electrónica óptica y lı́neas de producción. Actualmente los principales requerimientos son la reducción de costos, sistemas basados en equipo de cómputo y el análisis de nuevas tecnologı́as como alternativas para crear soluciones de instrumentación más efectivas. Los sistemas de instrumentación tienden a utilizar algún tipo de interfaz con computadora, para que los datos adquiridos en los instrumentos se envı́en, analicen y distribuyan a través de una red de cómputo. El resultado es un sistema flexible, que permite dar formato a la información y procesamiento rápido de los datos. Desde 1974 la industria de mediciones y pruebas ha utilizado principalmente el canal IEEE 488 (GPIB) como interfaz entre instrumentos y equipo de cómputo. Cada nueva generación de dispositivos incrementa la tasa de producción de información teniendo como lı́mite el ancho de banda de IEEE 488. Debido a esta limitante del ancho de banda y costos elevados de hardware, algunas aplicaciones han iniciado la búsqueda de alternativas en tecnologı́as que sı́ soporten los requerimientos actuales. Nuevos estándares y protocolos empiezan a ser tecnologı́as populares en los equipos de cómputo, para dejar atrás a los puertos serial y paralelo. Debido a la aceptación de canales como Ethernet, USB e IEEE 1394 (FireWire1 , i–Link2 ), los sistemas de instrumentación empiezan a considerarlos como alternativas de interfaz para las aplicaciones de mediciones y pruebas. Esta investigación se concentra en el estudio del canal IEEE 1394 como posible candidato en el reemplazo de IEEE 488, para la implementación de sistemas de intrumentación.. 1 2. FireWire es una marca registrada de Apple Computer, Inc. i–Link es una marca registrada de Sony Corporation.

(21) 2. CAPÍTULO 1. INTRODUCCIÓN. 1.1.. Descripción del Problema y Justificación. IEEE 488 es una plataforma de control diseñada especı́ficamente para la industria de mediciones y pruebas. Definió el primer estándar para conectar instrumentos con computadoras. Hoy en dı́a los sistemas de instrumentación encuentran desventajas en el canal GPIB, como tasa de transmisión pequeña, procedimientos de instalación complicados, poca flexibilidad y costos elevados. Existen otras plataformas industriales alternativas a GPIB, como HS488, VXI, PXI, CompactPCI y VME, que pueden solucionar algunas de las limitantes del canal IEEE 488 como la tasa de transmisión, pero tienen un precio igual o superior. También se cuenta con el estándar de una red de comunicación denominado Industrial Fieldbus, para comunicar instrumentos de diversos fabricantes utilizando un mismo canal y protocolo; en el mercado existe la competencia entre diferentes implementaciones como ISA-SP50, Profibus, CAN, y DeviceNet, pero estas opciones no llegan a unirse en un único y común canal de comunicación industrial Fieldbus. La utilización de canales de comunicación estándares en los equipos de cómputo, ofrece soluciones como bajo costo, evitar la adquisición e instalación de un adaptador de canal, eliminar conflictos entre recursos, los sistemas operativos ya incluyen el software controlador del adaptador (drivers) y se pueden utilizar para otro tipo de aplicaciones que no sean de instrumentación. Entre los candidatos más populares y con la capacidad para reemplazar IEEE 488 se encuentran Ethernet, USB e IEEE 1394; todos ellos ya vienen implementados y configurados en los equipos de cómputo actuales y modelos recientes. Actualmente en la industria de mediciones y pruebas, todavı́a no se perfila un candidato como reemplazo absoluto de GPIB, pues las nuevas versiones de cada estándar (IEEE 1394b, USB 2.0, GigaEthernet), los alcances y limitaciones de cada canal, son hasta el momento temas de discusión para elegir la mejor tecnologı́a que sustituya IEEE 488. En consecuencia, los fabricantes de instrumentos han implementado en forma limitada los canales Ethernet, USB e IEEE 1394 en sus productos y han preferido desarrollar hardware intermediario (gateways). Un equipo intermediario incluye mı́nimo dos clases de interfaz para canales diferentes, lo que permite la interacción entre sistemas de instrumentación tradicionales con IEEE 488 y los canales Ethernet, USB e IEEE 1394. Las ventajas y desventajas de cada posible sustituto de IEEE 488, son indicadores a considerar contra los requerimientos de los diferentes sistemas de instrumentación. Entonces los sistemas se van agrupando de acuerdo a los beneficios de cada reemplazo. Las aplicaciones de mediciones y pruebas empiezan a dividirse entre los estándares Ethernet, USB e IEEE 1394, dependiendo de las necesidades de cada aplicación y qué alternativa las satisface mejor. El canal IEEE 1394 se puede utilizar como medio de comunicación entre dispositivos de instrumentación y equipo de cómputo, pero la transmisión de información y administración de recursos requiere adicionalmente de un protocolo de comunicación. La asociación 1394TA3 ha propuesto dos estándares: el estándar IICP [12] (Instrument & Industrial Control Protocol), como protocolo de instrumentación para el canal IEEE 1394 y el estándar IICP488 [11], para describir el uso de IICP en la comunicación de mensajes GPIB sobre el canal IEEE 1394. Los estándares IICP e IICP488 todavı́a no han sido implementados y por lo mismo no se tienen investigaciones que analicen su desempeño, ni se producen dispositivos que los utilicen. 3. 1394 Trade Association.

(22) 1.2. OBJETIVOS. 3. Aunque se han realizado estudios de comparación entre los canales IEEE 488 e IEEE 1394 como [6], [22] y [27], en ninguno de ellos se analizan los efectos de los protocolos de comunicación IICP e IICP488 sobre el canal IEEE 1394. El presente documento de investigación propone una implementación de los protocolos IICP e IICP488, para analizar su desempeño en conjunto con el canal IEEE 1394, y ası́ obtener una referencia de comparación real respecto a GPIB y los requerimientos actuales de los sistemas de instrumentación.. 1.2.. Objetivos. Esta investigación tiene los siguientes objetivos particulares: 1. Proponer una implementación actualizada del protocolo IICP, para la comunicación de instrucciones y mensajes IEEE 488, utilizando el canal IEEE 1394. 2. Realizar una comparación de desempeño entre los protocolos GPIB e IICP, utilizando métricas imparciales para obtener parámetros de eficiencia que incluyan a los canales IEEE 488 e IEEE 1394. 3. Identificar las caracterı́sticas y requerimientos de los sistemas de instrumentación adecuados para utilizar la plataforma IEEE 1394–IICP, considerando los resultados de desempeño y comparación.. 1.3.. Contribución. Para esta investigación se realizará un nuevo desarrollo del protocolo IICP en plataforma Win32 y C++, mediante programación orientada a objetos, que suplirá la falta de una aplicación o librerı́a que actualmente implemente el protocolo IICP de instrumentación. El protocolo IICP está diseñado conforme al estándar IEEE 1212–1991 [20], aunque durante el presente trabajo, la programación e implementación de IICP se realizará considerando la revisión actualizada del estándar IEEE 1212–2001 [21]. Los parámetros y resultados de desempeño obtenidos en esta investigación, se podrán utilizar de referencia para una comparación entre los otros posibles candidatos para reemplazar IEEE 488 y sus respectivos protocolos de instrumentación: Ethernet y VXI–11, USB y USBTMC–USB488. Una vez que se han identificado las categorı́as de los sistemas de mediciones y pruebas adecuados para implementar IEEE 1394, se disminuye la incertidumbre relacionada con la factibilidad de IEEE 1394 como interfaz y sustituto de IEEE 488. Entonces los fabricantes de instrumentos tienen más antecedentes y respaldo para proceder a construir productos que integren la tecnologı́a IEEE 1394–IICP..

(23) 4. 1.4.. CAPÍTULO 1. INTRODUCCIÓN. Organización de la Tesis. Este documento está dividido en cinco capı́tulos, un glosario y apéndices. Cada capı́tulo comienza con una breve descripción del contenido a presentar. Al final del documento se incluye un glosario como una lista del vocabulario especı́fico utilizado en los estándares IEEE 1394 e IEEE 488. El capı́tulo 2, realiza una comparación entre los candidatos principales para reemplazar IEEE 488: Ethernet, USB e IEEE 1394. También se describen implicaciones y requerimientos relacionados con los instrumentos que utilizan una interfaz IEEE 1394. Además se presentan conceptos generales y fundamentos de los estándares IEEE 488 e IEEE 1394. Los detalles de implementación del protocolo de instrumentación IICP, que es el complemento de IEEE 1394 para establecer una comunicación GPIB, se describe en el capı́tulo 3. La sección de metodologı́a y resultados está formada por el capı́tulo 5; introduce el modelo analı́tico que describe las métricas utilizadas para la comparación de desempeño entre los protocolos GPIB e IICP. También se presentan los resultados numéricos obtenidos de la evaluación de desempeño. El capı́tulo 6 concluye el trabajo, y se hace la recomendación de los sistemas de instrumentación adecuados para implementar el protocolo IICP. Finalmente se agregan indicaciones y sugerencias para futuras investigaciones. En la sección de anexos se incluye el código completo de la implementación del protocolo IICP, los resultados de todas las mediciones realizadas para obtener los parámetros de desempeño y las caracterı́sticas de los ambientes de pruebas..

(24) Capı́tulo 2 Antecedentes y Fundamentos Pero con Dios están la sabidurı́a y el poder; Suyo es el consejo y la inteligencia. Job 12:13 Resumen Para responder a las preguntas de por qué Ethernet, USB e IEEE 1394 son posibles alternativas de IEEE 488 y por qué se analiza en esta investigación la opción IEEE 1394, la primera parte de este capı́tulo presenta las caracterı́sticas que se buscan en el reemplazo de IEEE 488. Después se realiza una comparación entre Ethernet, USB e IEEE 1394 para identificar las ventajas y limitaciones de cada canal. Entonces se describen los beneficios y propiedades de cada reemplazo respecto a los sistemas de mediciones y pruebas. También se presentan las implicaciones de utilizar una interfaz IEEE 1394 en los instrumentos. En la segunda parte se incluyen los conceptos generales de IEEE 488 e IEEE 1394 para comprender el funcionamiento básico de cada canal, ası́ como sus capacidades.. 2.1.. Caracterı́sticas del Reemplazo de IEEE 488. Aunque algunos canales como Ethernet, USB e IEEE 1394 se han convertido en elementos estándar para los equipos de cómputo, y que tienen potencial para ser utilizados en la industria de mediciones y pruebas, es importante señalar que la tecnologı́a en las computadoras evoluciona más rápido que en los sistemas de instrumentación. Independientemente de la cantidad y de cuáles estándares reemplacen IEEE 488, los canales seleccionados tienen que asegurar una permanencia en el mercado a largo plazo. Un estudio realizado cada año por la compañı́a Keithley Instruments [17], revisa los requerimientos actuales y esperados, que la industria de medición y pruebas contempla respecto a la utilización de los canales IEEE 488 y sus posibles reemplazos. Los resultados del año 2003 se muestran en la figura 2.1. De la figura 2.1 se observa que en los sistemas de medición y pruebas, IEEE 488 tiene aproximadamente una participación del 47 %, aunque sin tener un incremento en su utilización, mientras que Ethernet en promedio interviene con el 39 %, USB tiene una aplicación del 19,4 %,.

(25) 6. CAPÍTULO 2. ANTECEDENTES Y FUNDAMENTOS. Figura 2.1: Utilización de Ethernet, USB e IEEE 1394 en los sistemas de instrumentación con un incremento de 5 % anual y el canal IEEE 1394 tiene una tasa de crecimiento de 3,3 % al año y se emplea en promedio 9,1 %. Por lo tanto se puede concluir que no hay una tendencia definida para que quede un solo reemplazo y los otros dos candidatos sean eliminados, sino que Ethernet, USB e IEEE 1394, todos tienden a ser parte del reemplazo de IEEE 488. Cada año los canales sustitutos incrementan su porcentaje de participación en los sistemas de instrumentación, aunque sı́ hay diferencias en los rangos de uso, pues Ethernet es el que tiene mayor preferencia, mientras que IEEE 1394 es el menos utilizado. Los sistemas tradicionales de IEEE 488 no desaparecen por completo ni en forma precipitada debido al tamaño de la infraestructura actual, pero sı́ empiezan a considerar introducir alguna alternativa. Andy Purcell [26] y Joe Engler [6] , presentan otras caracterı́sticas que los sistemas de instrumentación requieren al reemplazar IEEE 488, y cómo es que Ethernet, USB e IEEE 1394 las satisfacen. Las caracterı́sticas se muestran en el cuadro 2.1. Algunas de las propiedades del cuadro 2.1 se describen a continuación: Conexión Permeable El conector fı́sico (adaptador) ya está instalado en el equipo de cómputo y el sistema operativo cuenta con el software necesario para controlar el hardware (drivers). También implica bajo costo de los cables. Latencia Retardo de tiempo para comunicar el resultado de una medición al equipo de cómputo. Las solicitudes de entrada/salida de información pueden implicar lectura y escritura de registros; que deben realizarse en el menor tiempo posible. Emulación GPIB Implica desarrollar software controlador de hardware (drivers) que integre el lenguaje de comunicación GPIB del canal IEEE 488, para mantener una compatibilidad con aplicaciones desarrolladas anteriormente. Punto a Punto, Peer to Peer Establecer una conexión entre dispositivos sin la necesidad de una computadora como intermediario. Hot pluggable, Plug and Play Los dispositivos se pueden agregar al canal, enumerarse y ser removidos sin necesidad de reinicializar el sistema..

(26) 2.1. CARACTERÍSTICAS DEL REEMPLAZO DE IEEE 488 Propiedad Formato de interfaz Tasa máxima de transmisión Dispositivos Longitud de cable máxima Latencia Conexión permeable Punto a Punto Hot pluggable Escalable. Acceso remoto Conexión inalámbrica Software controlador de hardware Seguridad Emulación GPIB Herramientas de desarrollo. 7. IEEE 488 Paralelo. IEEE 1394 Serial. USB Serial. Ethernet Serial. 488: 8 Mbps HS488: 64 Mbps 14 20 m. 1394a: 400 Mbps 1394b: 800 Mbps 63 1394a: 4.5 m 1394b: 100 m. USB1: 12 Mbps USB2: 480 Mbps 123 20 m. 100 µseg Requiere tarjeta de interfaz No No, dirección manual Limitada. Muy cara. Requiere más tarjetas de interfaz. No No. 1394a: 120 µseg Sı́. USB1: 1000 µseg Sı́. V100: 100 Mbps V1G: 1Gbps Ilimitado V10, 100: 100 m. Sin lı́mite con router e Internet V100: 100 µseg Sı́. Sı́ Sı́. No Sı́. Software de control (drivers). –. Software de control (drivers) ó TPC/IP Expuesta, si se utiliza Internet IICP–IICP488. VISA. VISA. No expuesta. Limitada. quiere tarjetas interfaz. Sı́ No. Remás de. Limitada. Requiere más tarjetas de interfaz. No No Software de control (drivers) No expuesta USBMTC– USB488 VISA. Sı́ No, dirección manual o DHCP Ilimitada. Requiere más concentradores. Sı́ Sı́, requiere tarjeta de interfaz Software de control (drivers) ó TCPIP, Telnet Muy expuesta, si se utiliza Internet VXI–11 VISA. Cuadro 2.1: Comparación entre IEEE 488, IEEE 1394, USB y Ethernet Los alcances y limitaciones de Ethernet, USB e IEEE 1394 que se muestran en el cuadro 2.1, sirven de indicadores para seleccionar algún canal como reemplazo, dependiendo de los requerimientos del sistema de instrumentación a desarrollar. Otra de las principales razones para reemplazar IEEE 488, es reducir los costos de implementación. Debido a que IEEE 488 fue diseñado especificamente para el control de instrumentos, no es posible utilizar el canal para otro tipo de aplicaciones. En comparación con los posibles reemplazos, la demanda de IEEE 488 en el mercado de tecnologı́a de información, es mucho menor, lo que eleva los costos de las tarjetas de interfaz y de los cables. En el cuadro 2.2 se muestra una comparación de costos entre IEEE 488, Ethernet, USB e IEEE 1394, para un sistema de instrumentación con un solo dispositivo y para otro sistema con.

(27) 8. CAPÍTULO 2. ANTECEDENTES Y FUNDAMENTOS. 5 instrumentos. Se asume que los dispositivos ya cuentan con la interfaz correspondiente y que si se necesitan tarjetas adicionales, son para los equipos de cómputo. El cuadro 2.2 indica que en Interfaz IEEE 488 USB Ethernet. Un instrumento [USD] Tarjeta y cable – $650 Cable – $10 Cable – $10 Tarjeta (si se requiere) $20 IEEE 1394 Cable – $20 Tarjeta (si se requiere) $20–$80. Sistema tı́pico con 5 dispositivos [USD] Tarjeta y cables – $1,750 Concentrador y cables – $195 Concentrador y cables – $225 Tarjeta (si se requiere) $20 Cables – $220 Tarjeta (si se requiere) $20–$80. Cuadro 2.2: Comparación de costos entre IEEE 488, Ethernet, USB e IEEE 1394 promedio, implementar un sistema de instrumentación utilizando Ethernet, USB ó IEEE 1394, es aproximadamente 8 veces más económico que la interfaz IEEE 488. También es importante considerar el conocimiento que los profesionistas de la industria de medición y pruebas, tienen de cada sustituto de IEEE 488, pues dependiendo del nivel de experiencia, es la capacidad de introducción de la tecnologı́a en las aplicaciones de instrumentación. A mayor conocimiento de un canal, mayor probabilidad de ser utilizado; pues no se tiene mucha confianza en usar algo que no se conoce. Una encuesta realizada por la revista CED [18], muestra el grado de conocimientos generales que profesionistas en tecnologı́a de información, tuvieron acerca de Ethernet, USB e IEEE 1394 durante el año 1999, los resultados se presentan en lafigura 2.2.. Figura 2.2: Nivel de conocimientos generales de Ethernet, USB e IEEE 1394 Se puede observar de la figura 2.2, que muy pocos profesionistas tienen la experiencia y conocimientos adecuados en cada uno de los reemplazos de IEEE 488, con tan solo 30,4 % en Ethernet, 16,2 % con USB y 8,7 % para IEEE 1394. Esta carencia de nociones puede significar un retraso en la introducción de tecnologı́as alternativas a IEEE 488 en los sistemas de medición y pruebas..

(28) 2.2. DESCRIPCIÓN DE LOS REEMPLAZOS DE IEEE 488. 2.2.. 9. Descripción de los Reemplazos de IEEE 488. Utilizando los alcances y limitaciones de los posibles sustitutos de IEEE 488, presentados en los cuadros 2.1 y 2.2, ası́ como otras caracterı́sticas particulares a cada candidato, se procede a examinar de manera individual los canales Ethernet, USB e IEEE 1394, y su aplicación en la industria de mediciones y pruebas.. 2.2.1.. Ethernet. La principal aplicación de Ethernet es utilizar protocolos de red en los instrumentos, para obtener beneficios como compartir recursos, aplicaciones Internet & Intranet, RPCs, telnet, acceso remoto, redes inalámbricas, conexión punto a punto (peer to peer ), y distancias ilimitadas entre dispositivos y equipo de cómputo. Por el contrario, una de las mayores desventajas es su incapacidad para el descubrimiento automático de los instrumentos, pues cada elemento requiere una dirección IP y nombre de equipo. Se genera una depedencia con el personal administrador de las direcciones y nombres. Otro factor a considerar es que las tasas nominales de transmisión de 10 Mbps, 100 Mbps y 1 Gbps, no se llegan a tener en el desempeño real de las aplicaciones. Ethernet requiere transmitir información para el mantenimiento de la red, como encabezados en los paquetes, detección de colisiones, detección de errores, y monitoreo de portadora. Además, al compartir la red con múltiples dispositivos, el tráfico aumenta y la tasa de transmisión disminuye porque el ancho de banda se distribuye. Esto implica que no es posible establecer una tasa de transmisión de manera determinı́stica. Si el sistema de instrumentación procesa información confidencial y sensible, para mantener la integridad y privacidad de los datos se tienen que aplicar sistemas de seguridad como firewalls y programas antivirus. Ethernet es el reemplazo de IEEE 488 más utilizado en la actualidad, porque es la interfaz con mayor presencia en la implementación de redes locales, con más de 100 millones de computadoras utilizando TCP/IP1 . Además de que el personal de Tecnologı́a de Información (TI) ya cuenta con herramientas, procedimientos y conocimientos para administrar redes Ethernet.. 2.2.2.. Universal Serial Bus (USB). El canal de USB ofrece un estándar para el control de periféricos en casi todos los equipos de cómputo fabricados en la actualidad. Tiene mayor probabilidad de estar presente en las computadoras producidas desde 1997, que las tarjetas Ethernet [15]. USB ofrece la propiedad de hot pluggable. Los instrumentos con USB pueden llegar a prescindir de fuente de poder y ser alimentados a través del canal y de la computadora a la que se conectan. Todas estas propiedades permiten diseñar instrumentos más compactos y económicos en comparación con Ethernet e IEEE 1394. La limitante más importante de USB, es que es un canal centralizado. Se requiere de un equipo de cómputo para que administre el canal, lo que incrementa los tiempos de latencia. 1. Vanessa Trujillo. Guide to instrument and control buses. ProQuest. 2001.

(29) 10. CAPÍTULO 2. ANTECEDENTES Y FUNDAMENTOS. El instrumento no puede empezar a transmitir información hasta que el administrador del canal lo indique. Entonces no es posible conectar dos dispositivos entre sı́, pues se necesita una computadora como intermediario. Esta limitante tiene otra consecuencia para los instrumentos virtuales, porque inicialmente el equipo donde están implementados se designa como administrador del canal, pero no se pueden enviar los resultados de pruebas y mediciones a otra computadora, porque USB está diseñado para incluir una sola computadora por canal. Para resolver este problema se requiere de una tarjeta adaptadora de entrada/salida que contiene un conector y controlador periférico de USB, además de tener que modificar el BIOS del equipo donde está el instrumento virtual. Otra solución es utilizar la tecnologı́a OTG como extensión de USB 2.0, para que varias computadoras compartan la administración del canal, pero OTG se implementa con muy poca frecuencia en la industria [29]. También hay que considerar que los cables de USB no están preparados para ambientes industriales y el desempeño del canal se puede disminuir en ambientes con ruido, además de que no hay un mecanismo para prevenir que se desconecten accidentalmente los cables.. 2.2.3.. IEEE 1394. IEEE 1394 es un canal que utiliza memoria de acceso directo (DMA), lo que permite transferir la información del instrumento directamente a la memoria de la computadora, sin la intervención del procesador (CPU) en el equipo de cómputo. Además, en cuanto un instrumento tiene información para transmitir, puede hacerlo sin la necesidad de que algún administrador del canal se lo indique. Otra ventaja de IEEE 1394 es la conexión punto a punto, donde se pueden conectar directamente dos dispositivos sin la necesidad de un equipo de cómputo como intermediario. Igual que USB, IEEE 1394 ofrece la propiedad de hot pluggable, y que los instrumentos pueden llegar a prescindir de fuente de poder para ser alimentados a través del canal y de la computadora a la que se conectan. Protocolos de red como TCP/IP, NetBEUI e IPX/SPX, pueden ser emulados por el canal IEEE 1394. En teorı́a cualquier protocolo que utilice TCP/IP se puede transmitir sobre IPv4–1394. Esta propiedad permite tener beneficios de Ethernet como compartir recursos, aplicaciones Internet & Intranet y RPCs, además de las propiedades que el propio IEEE 1394 ofrece. La limitante más significativa de IEEE 1394 es la falta de permeabilidad como la que tienen Ethernet y USB, esto en parte se debe a que la compañı́a Intel promueve USB, y que se requiere pagar un costo de licencia por cada producto IEEE 1394. En realidad es un costo de $0.25 USD por licencia, que sólo aplica para los productores de circuitos integrados 1394, el costo no está relacionado directamente con los fabricantes de tarjetas de interfaz, ni con los consumidores o desarrolladores. La empresa Apple Computers también solicita un pago de licencia por la utilización de su logotipo y marca registrada de “FireWire”. Otra desventaja es cuando se generan pequeñas rafagas de datos, el canal IEEE 1394 tiene un desempeño menor que con bloques de información grandes, ya que el tiempo requerido para establecer la comunicación es generalmente mayor al tiempo requerido para realizar la transferencia del mensaje corto..

(30) 2.3. SELECCIÓN DEL REEMPLAZO DE IEEE 488. 2.3.. 11. Selección del Reemplazo de IEEE 488. De acuerdo a las diferentes ventajas y desventajas que ofrece cada reemplazo de IEEE 488, implica que las tecnologı́as Ethernet, USB e IEEE 1394 no representan el mismo nivel de beneficios para cualquier tipo de aplicación de instrumentación, sino que los requerimientos y funcionalidad del sistema determinan el reemplazo que conviene seleccionar. En esta sección se presentan las caracterı́sticas recomendables en los sistemas de medición y pruebas, para implementar cada una de las tecnologı́as alternativas a IEEE 488.. 2.3.1.. Ethernet. Cuando el objetivo primordial del sistema sea compartir instrumentos y resultados de mediciones, además de permitir la colaboración entre multiple personal en diferentes localidades, ası́ como controlar los dispositivos de manera remota a través de la red TCP/IP (LAN, WAN) con una interfaz para navegador de Internet (Netscape, IE) e implementar un ambiente de control distribuido, entonces se recomienda utilizar Ethernet, como se muestra en la figura 2.3. Figura 2.3: Sistema de instrumentación con conexión Ethernet. 2.3.2.. USB. Debido a que USB tiene la mejor permeabilidad, este canal presenta una conexión directa más simple y sencilla que Ethernet o IEEE 1394, se recomienda para la configuración local e inmediata de los instrumentos, ası́ como para sistemas donde el rendimiento total del canal (throughput) no es importante, debido a los tiempos de latencia de USB. También se recomienda cuando se trata de fabricar dispositivos compactos y económicos que no se requieren compartir en una red. En la figura 2.4 se muestra un ejemplo de conexión USB..

(31) 12. CAPÍTULO 2. ANTECEDENTES Y FUNDAMENTOS. Figura 2.4: Sistema de instrumentación con conexión central USB. 2.3.3.. IEEE 1394. Si el sistema de instrumentación requiere conexión punto a punto, tiempos de latencia mı́nimos y es importante el rendimiento total del canal (throughput), entonces se recomienda utilizar IEEE 1394. Este canal puede representar una mezcla entre USB y Ethernet al ofrecer ventajas de ambos canales. Por ejemplo de Ethernet se puede implementar el compartir instrumentos, colaboración entre multiple personal o controlar los dispositivos en forma remota, pero de manera reducida a través de una sola red local, ya que existen las limitantes de IEEE 1394 respecto a la longitud de los cables y el número de instrumentos que soporta el canal. Al igual que USB, IEEE 1394 puede establecer una conexión sencilla e inmediata con los dispositivos, implementarse como interfaz en dispositivos de bajo costo como transductores o digitalizadores (A/D) que requieren un mı́nimo de capacidad de procesamiento, y llegar a alimentar de corriente al instrumento, para que no se requiera fuente de poder. El canal IEEE 1394 se puede utilizar una configuración central o en cadena, como se muestra en las figuras 2.5 y 2.6.. Figura 2.5: Sistema central IEEE 1394. Figura 2.6: Sistema en cadena IEEE 1394.

(32) 2.4. IMPLICACIONES DE CONEXIÓN IEEE 1394. 2.4.. 13. Implicaciones de Instrumentos con Interfaz IEEE 1394. Los instrumentos que implementan una conexión IEEE 1394, deben diseñar el software controlador (driver ) para que soporte protocolos de nivel superior. La organización 1394TA creó la definición de los protocolos IICP e IICP488 para proveer mecanismos de comunicación que emulan GPIB, y que las aplicaciones desarrolladas para IEEE 488 se puedan seguir utilizando, pero ahora teniendo IEEE 1394 como reemplazo. El estándar IICP define la comunicación ası́ncrona entre dispositivos de control e instrumentos para mediciones y pruebas, que utilizan el canal IEEE 1394. Las ventajas de IICP son las siguientes Protocolo especı́fico para el canal IEEE 1394 y sistemas de instrumentación. Dos puertos IEEE 1394 dedicados para transmitir información • Puerto de datos. • Puerto de control. Dos modos de transmisión de información que optimizan el envı́o de cualquier tipo de paquete • Modo de transferencia de paquetes pequeños. • Modo de transferencia de paquetes grandes. Permite utilizar tablas de páginas de memoria no secuencial, y generar un espacio de memoria total para almacenar la información en el equipo de cómputo. Debido a que IEEE 1394 puede emular TCP/IP, también se puede utilizar TCP/IP como protocolo de instrumentación a través de comunicación ASCII, ya que IEEE 488 intrı́nsecamente soporta este tipo de comunicaciones. Existe el protocolo VXI-11 que emula GPIB sobre Ethernet, y como utiliza TCP/IP, en teorı́a VXI-11 también se puede transmitir sobre IEEE 1394.. 2.5.. Fundamentos del canal IEEE 488. Esta sección describe de manera general el funcionamiento del canal IEEE 488. Para mayor información consultar los estándares IEEE 488.1–1987 [23] e IEEE 488.2 [24]. El canal IEEE 488 fue creado por la compañı́a HP2 en el año de 1974, con el objetivo de definir un modelo estándar para la interconexión y control de instrumentos programables de medición y pruebas, con equipos de cómputo. Originalmente la interfaz se llamó HP–IB (HP Interface Bus), pero en 1978 el canal fue adoptado por la IEEE y lo renombró GPIB (General Purpose Interface Bus), con el estándar número 488. IEEE 488 está formado por las siguientes tres especificaciones: 2. Hewlett & Packard.

(33) 14. CAPÍTULO 2. ANTECEDENTES Y FUNDAMENTOS. IEEE 488.1 Estándar que define la interfaz mecánica y eléctrica del canal. Todos los fabricantes de instrumentos deben diseñar el hardware de acuerdo a esta especificación. IEEE 488.2 Es un complemento de IEEE 488.1, que especifica el formato de datos, reporte de estatus, manejo de errores, funcionalidad del controlador, ası́ como las instrucciones requeridas en todos los instrumento. El enfoque principal es la definición de software y protocolo para la comunicación entre instrumentos y equipo controlador. SCPI (Standard Commands for Programmable Instruments). Especificación que hace una expansión de las instrucciones definidas en el estándar IEEE 488.2, al establecer un conjunto de instrucciones de alto nivel, que se implementan en cualquier instrumento, independientemente del fabricante.. 2.5.1.. IEEE 488.1. IEEE 488 es un canal paralelo, de 8 bits de datos y con tasa de transmisión de 1 MBytes/s. La interfaz soporta un total de 15 dispositivos, incluyendo un dispositivo controlador, que generalmente es una computadora. Se utiliza un mismo tipo de cable para interconectar diferentes instrumentos al equipo de cómputo, mediante una configuración en cadena o estrella, ver las figuras 2.7 y 2.8. Los cables y conectores están diseñados para un ambiente industrial y permiten una distancia máxima de 4m entre dos dispositivos.. Figura 2.7: Conexión IEEE 488 en cadena. Figura 2.8: Conexión IEEE 488 en estrella. También es posible interconectar instrumentos, sin la necesidad de un dispositivo controlador, como se muestra en la figura 2.9, donde un dispositivo sólo transmite información, mientras que otro instrumento únicamente escucha lo que se envı́a por el canal.. Figura 2.9: Conexión entre dispositivos IEEE 488, sin controlador.

(34) 2.5. FUNDAMENTOS DEL CANAL IEEE 488. 15. Los dispositivos IEEE 488 pueden ser transmisores, receptores y/o controladores. Un dispositivo transmisor envı́a mensajes de datos a uno o más receptores. Los dispositivos receptores aceptan y procesan los mensajes de los transmisores. El dispositivo controlador administra el flujo de información en el canal al mandar instrucciones a todos los instrumentos. 2.5.1.1.. Estructura Fı́sica. El canal IEEE 488 utiliza lógica negativa, con niveles de voltaje TTL. Por ejemplo, cuando se tiene una señal verdadera implica un nivel TTL bajo (≤ 0.8 V), y cuando se tiene una señal falsa es un nivel TTL alto (≥ 2.0 V). La interfaz IEEE 488 conciste de 16 lı́neas de señales y 8 lı́neas de tierra como se muestra en la figura 2.10.. Figura 2.10: Conector IEEE 488 con asignación de lı́neas de señales y tierra Las lı́neas de señales se clasifican en las siguientes tres categorı́as: Lı́neas de datos (8) Las lı́neas de datos (Entrada Dato 1 – Entrada Dato 8) transmiten información y mensajes de control. La lı́nea de atención de estado (ATN) indica si el mensaje es de información o control. Todos los mensajes utilizan 7 bits para implementar el código ASCII ó ISO, por lo que la entrada de dato 8 no se utiliza o se asigna de paridad. Lı́neas de handshake (3) . Son lı́neas de control ası́ncrono, para la transmisión de mensajes entre los dispositivos del canal. Este proceso se llama 3–handshake, que garantiza que los mensaje en las lı́neas de datos se envı́en y reciban, sin errores de transmisión. Las lı́neas de handshake son las siguientes: NRFD (not ready for data) NDAC (not data accepted).

(35) 16. CAPÍTULO 2. ANTECEDENTES Y FUNDAMENTOS DAV (data valid). Lı́neas de administración de la interfaz (5) Estas lı́neas se utilizan para controlar la operación del canal, y en general para el flujo de información a través de la interfaz. Las lı́neas de administración son las siguientes: ATN (attention) IFC (interface clear) REN (remote enable) SRQ (service request) EOI (end or identify) Para una descripción más detallada acerca de las lı́neas de señales, consultar la referencia [9]. 2.5.1.2.. Mensajes de Interfaz. Los dispositivos IEEE 488 se comunican con otros dispositivos a través del envı́o de mensajes de interfaz y mensajes de dispositivo. Los mensajes de dispositivo son datos que contienen información especı́fica al dispositivo, como instrucciones de programación, resultados de medición y estatus del equipo. Los mensajes de interfaz son mensajes para la administración del canal, que realizan funciones como inicializar el canal, asignar direcciones a dispositivos o configurar modos para programación remota o local. También se les llama instrucciones. El estándar IEEE 488.1 define a los instrumentos con una partición para interfaz y otra partición de dispositivo, como se muestra en la figura 2.11. Los mensajes de interfaz y direcciones son enviados por el dispositivo controlador a la partición de interfaz del instrumento.. Figura 2.11: Particiones de un instrumento IEEE 488.1 En el cuadro 2.3 se muestran las direcciones y mensajes de interfaz definidos en el estándar IEEE 488.1. Las direcciones de recepción MLA, LAD y UNL tienen asignadas el rango 2016 − 3F16 . MTA, TAD y UNT son direcciones para transmitir y están en el rango 4016 − 5F16 . Un dispositivo responde con el mismo valor a las direcciones de transmisión como a las direcciones de recepción, por ejemplo LAD 416 y TAD 416 . Los dispositivos también pueden tener direcciones secundarias que están en el rango 6016 −7F16 . Aunque existen hasta 31 direcciones posibles para asignar a los dispositivos, sólo se puede utilizar un máximo de 15 direcciones para establecer un canal IEEE 488 con instrumentos y controlador..

(36) 2.5. FUNDAMENTOS DEL CANAL IEEE 488. 17. Instrucción Descripción Instrucciones de direcciones MLA MTA LAD TAD SAD UNL UNT. My Listen Address. Del controlador a él mismo My Talk Address. Del controlador a él mismo Device Listen Address. Direcciones para recepción (0 − 1E16 ) Device Talk Address. Direcciones para transmitir (0 − 1E16 ) Secondary Device Address. Direcciones secundarias (0 − 1E16 ) Unlisten. Sin recepción (LAD 1F16 ) Listen. Recepción (TAD 1F16 ). Instrucciones universales para todos los dispositivos LLO DCL PPU SPE SPD. Local Lockout. Device Clear. Parallel Poll Unconfigure. Serial Poll Enabled. Serial Poll Disabled.. Instrucciones para dispositivos con dirección asignada SDC GTL GET PPC TCT. Selected Device Clear. Go to Local. Device Trigger. Parallel Poll Configure. Take Control. Cuadro 2.3: Direcciones y mensajes de interfaz. 2.5.2.. IEEE 488.2. El estándar IEEE 488.1 definió la interconexión entre instrumentos y dispositivos controladores, pero no especificó el proceso de comunicación de mensajes de dispositivo en el canal. Entonces cada fabricante estableció sus propios formatos de mensajes y respuestas. Por eso en 1987 se creó el estándar IEEE 488.2, que precisa la estructura de los mensajes, instrucciones que todos los dispositivos deben implementar, reporte de estatus (Standard Status Reporting Structure) y protocolos para los dispositivos controladores.. 2.5.2.1.. Secuencias de Control. El estándar IEEE 488.2 define los requerimientos para un dispositivo controlador, que incluye un conjunto de capacidades de control que la interfaz IEEE 488 debe implementar. Estas secuencias de control especifican los mensajes de interfaz IEEE 488.1 que el dispositivo controlador envı́a. En el cuadro 2.4 se muestran las 15 secuencias requeridas y 4 opcionales. Las secuencias de control describen el estado exacto de la interfaz IEEE 488 y eliminan ambigüedad en la posible condición del canal, por lo que dispositivos de control e instrumentos pueden ser compatibles..

(37) 18. CAPÍTULO 2. ANTECEDENTES Y FUNDAMENTOS. Secuencia SEND COMMAND SEND SETUP SEND DATA BYTES SEND RECEIVE SETUP RECEIVE/RESPONSE MESSAGE RECEIVE SEND IFC DEVICE CLEAR ENABLE LOCAL CONTROLS ENABLE REMOTE SET RWLS SEND LLO READ STATUS BYTE TRIGGER PASS CONTROL PERFORM PARALLEL POLL PARALLEL POLL CONFIGURE PARALLEL POLL UNCONFIGURE. Descripción Enviar lı́nea ATN-verdadero Enviar dirección para mandar datos Enviar lı́nea ATN-falso Enviar un mensaje de programa Enviar dirección para recibir datos Recibir lı́nea ATN-falso Recibir un mensaje de respuesta Pulso en la lı́nea IFC Poner el dispositivo en DCAS Poner el dispositivo en estado local Poner dispositivo en estado remoto Dispositivo en remoto y bloquear local Poner dispositivo estado local bloqueado Leer el byte de estatus de IEEE 488.1 Enviar ejecución de trigger grupal (GET) Pasar el control a otro dispositivo Realizar una encuesta paralela Configurar respuesta de encuesta paralela Deshabilitar propiedad encuesta paralela. Exigencia Obligatoria Obligatoria Obligatoria Obligatoria Obligatoria Obligatoria Obligatoria Obligatoria Obligatoria Obligatoria Obligatoria Obligatoria Obligatoria Obligatoria Obligatoria Opcional Opcional Opcional Opcional. Cuadro 2.4: Secuencias de control 2.5.2.2.. Protocolos de Control. Un dispositivo de control debe implementar protocolos, que son rutinas de alto nivel que combinan secuencias de control para realizar operaciones básicas en los sistemas de instrumentación. El estándar IEEE 488.2 define 2 protocolos obligatorios y 6 opcionales, como se muestra en el cuadro 2.5. Los protocolos más importantes son FINDLSTN y FINDRQS. El protocolo FINDLSTN localiza dispositivos que están escuchando en el canal. El resultado es una lista de todos los instrumentos que pueden recibir mensajes. Este protocolo se utiliza al iniciar la ejecución de una aplicación, para verificar la configuración del sistema y para que el dispositivo contralador genere una lista de todos los instrumentos disponibles. FINDRQS es un mecanismo para localizar dispositivos que solicitan servicios. El resultado es una lista de todos los instrumentos que solicitan servicio del controlador. A esta lista se pueden asignar prioridades para que los dispositivos crı́ticos, reciban servicio primero. 2.5.2.3.. Instrucciones de Dispositivos. Los instrumentos IEEE 488 responden a mensajes de dispositivos, utilizando formato de datos y protocolos de intercambio de información que están implementados en todos los dispositivos. El estándar IEEE 488.2 define un conjunto mı́nimo de operaciones para establecer comunicación en el canal y reporte de estatus. El cuadro 2.6 muestra las operaciones obligatorias, ası́ como aquellas que son opcionales para instrumentos con capacidad extendida. La operación más utilizada es ∗IDN?, debido a que es la primera instrucción que se envı́a.

(38) 2.5. FUNDAMENTOS DEL CANAL IEEE 488 Nombre RESET FINDRQS ALLSPOLL PASSCTL REQUESTCTL FINDLSTN SETADD TESTSYS. Descripción Reinicia el sistema (Reset System) Dispositivo que busca servicio (Find Device Requesting Service) Encuesta serial de todos los dispositivos (Serial Poll All Devices) Pasar el control del sistema (Pass Control) Solicitar el control del sistema (Request Control) Buscar receptores (Find Listeners) Configurar dirección (Set Address) Autoverificación del sistema (Self-Test System). 19 Exigencia Obligatorio Opcional Obligatorio Opcional Opcional Opcional Opcional Opcional. Cuadro 2.5: Protocolos de control a un instrumento, porque la respuesta permite identificar al dispositivo a través del fabricante, modelo, número de serie y revisión, además de que esta operación se utiliza para verificar la comunicación con el instrumento.. 2.5.3.. Estándar SCPI. El estándar SCPI tiene como objetivo definir un conjunto único de instrucciones de alto nivel, para ser utilizado en la programación y control de cualquier dispositivo de instrumentación. La primera versión de este estándar fue realizada en 1990 y define su propio grupo de instrucciones obligatorias, además de las requeridas por el estándar IEEE 488.2. Las instrucciones definidas por SCPI, abarcan todas las principales funciones que cualquier instrumento puede realizar, por lo que un mismo desarrollo de sistema de medición con determinados dispositivos, se puede utilizar con instrumentos equivalentes de otros fabricantes, minimizando el esfuerzo requerido de tener que realizar un nuevo sistema. SCPI utiliza un modelo de jerarquı́a de instrucciones, por lo que es posible agregar instrucciones para realizar nuevas funciones. La figura 2.12 muestra el modelo de instrumentación SCPI que aplica para todos los tipos de instrumentos.. Figura 2.12: Modelo de instrumentación SCPI.

(39) 20. CAPÍTULO 2. ANTECEDENTES Y FUNDAMENTOS. Operación Función Operaciones obligatorias. Descripción. ∗IDN? ∗RST ∗TST? ∗OPC ∗OPC? ∗WAI ∗CLS ∗ESE ∗ESE? ∗ESR? ∗SRE ∗SRE? ∗STB?. Indagar identificación del dispositivo Reiniciar el canal Autoverificación Operación terminada Indagar operación terminada Tiempo de espera Despejar el canal Evento habilitar estatus Indagar el evento habilitar estatus Indagar el evento registro de estatus Servicio de habilitar solicitud Indagar el servicio de habilitar solicitud Indagar lectura del byte de estatus. Identification query Reset Self-Test query Operation Complete Operation Complete query Wait to complete Clear Status Event Status Enable Event Status Enable query Event Status Register query Service Request Enable Service Request Enable query read Status Byte query. Operaciones para instrumentos que soportan reconocimiento paralelo ∗IST? ∗PRE ∗PRE?. Individual Status query Parallel Poll Register Enable Parallel Poll Register Enable query. Operaciones para instrumentos que soportan trigger ∗TRG. Trigger. Operaciones para dispositivos de control ∗PCB. Pass Control Back. Operaciones para instrumentos que soportan guardar su configuración ∗RCL ∗SAV. Recall configuration Save configuration. Operaciones para instrumentos que soportan guardar configuración del registro habilitar ∗PSC ∗PSC?. Saves enable register values PSC value query Cuadro 2.6: Mensajes de dispositivo. No todos los elementos del modelo SCPI aplican para todos los instrumentos, por ejemplo un osciloscopio no tiene la funcionalidad definida por el elemento generación de señal.. 2.5.4.. HS488, IEEE 488 de Alta Velocidad. La empresa National Instruments ha desarrollado un protocolo GPIB de alta velocidad, que se denomina HS488 (High–Speed GPIB handshake protocol), que permite incrementar la tasa de transmisión establecida por el protocolo IEEE 488.1 cuando todos los dispositivos en.

(40) 2.6. FUNDAMENTOS DEL CANAL IEEE 1394. 21. el canal implementan HS488. La máxima tasa de transmisión entre dos dispositivos HS488 con una separación de 2m es de 8 MBytes/s. Para un sistema completo con 15 dispositivos y una longitud total de cable de 15m, la tasa máxima es de 1.5 MBytes/s.. 2.6.. Fundamentos del canal IEEE 1394. El estándar IEEE 1394 tiene su origen en la mitad de la década de 1980, en el canal diseñado por la empresa Apple Computer Corporation denominado FireWire; término utilizado todavı́a por varios fabricantes, mientras que otros han adoptado el nombre i.Link, que es marca registrada de Sony Corporation. Debido a la aceptación que tuvo Firewire en el mercado de electrónica, se formó un comité de trabajo para crear un estándar formal de la arquitectura. La especificación resultante se envı́o a la organización IEEE y se le asignó el número 1394.. 2.6.1.. Razones para Utilizar IEEE 1394. El estándar IEEE 1394 ó HPSB (High Performance Serial Bus), describe un canal serial de alta velocidad. El canal 1394 está definido según el estándar ISO/IEC 13213 [4] (ANSI/IEEE 1212), que describe una arquitectura de comunicación entre varios canales a través de Registros de Comando y Estado (CSR). Además del estándar original 1394–1995, existen las definiciones suplementarias IEEE 1394a e IEEE 1394b, y está en desarrollo IEEE 1394.1 en el que se definirá una nueva extensión del canal. IEEE 1394 soporta implementaciones sobre placa (backplane) y cable. El ambiente de placa establece tasas de transmisión de 25 Mbps y 50 Mbps para un canal de comunicación redundante y serial, en conjunto con la implementación de un canal paralelo. El ambiente sobre cable permite la interconexión de tarjetas en distinto panel, además de periféricos externos y dispositivos digitales multimedia como televisores y cámaras de video, al igual que dispositivos tradicionales de equipo de cómputo como discos duros e impresoras. Todos estos dispositivos requieren una tasa de transmisión alta. El canal 1394a soporta transmitir hasta 400 Mbps, lo que implica una tasa teórica de 50 MBytes/seg, en comparación con la tasa de ISA (8 MBytes/seg) y PCI (132 MBytes/seg). El estándar IEEE 1394a provee un desempeño escalable al soportar tasas de transmisión de 400 Mbps, 200 Mbps y 100 Mbps. A diferencia de otros canales donde la comunicación depende de un dispositivo de control o equipo de cómputo central, IEEE 1394 soporta un modelo punto a punto en el que cualquier dispositivo puede comunicarse directamente con cualquier otro, siempre y cuando utilicen los mismos protocolos. Según el estándar IEC 13213, los dispositivos incorporan una memoria ROM de configuración con el detalle sobre sus propiedades, funciones y protocolos que soportan, de forma que pueden comunicar esta información a otros dispositivos conectados al canal. Las facilidades de conectar y usar (plug and play), y la memoria ROM de configuración, permiten la coexistencia de distintos protocolos donde la única limitante es el ancho de banda disponible..

(41) 22. CAPÍTULO 2. ANTECEDENTES Y FUNDAMENTOS. 2.6.2.. Ventajas de IEEE 1394 sobre IEEE 488. El canal serial IEEE 1394 es una alternativa en lugar de otros canales paralelos diseñados. Los principales beneficios de un canal serial sobre implementaciones de canales paralelos son los siguientes: Periféricos en las computadoras personales residen en una variedad de canales, como PCI e ISA. La comunicación entre estos dispositivos puede resultar problemática debido a las diferencias entre velocidad y protocolos, lo que disminuye el desempeño. IEEE 1394 provee la capacidad para interconectar una gran variedad de periféricos al mismo canal serial. Hasta 63 nodos pueden ser anexados a un mismo canal. Costos reducidos en comparación con la mayoria de implementaciones de canales paralelos. Varios sistemas en canales paralelos están limitados a un pequeño espacio fı́sico, pero el canal IEEE 1394 tiene mayor flexibilidad hasta 4.5 metros entre cada dispositivo. IEEE 1394 permite conectar directamente dispositivos remotos al canal.. 2.6.3.. Estándares y Documentos Relacionados. IEEE 1394–1995 Se trata del estándar original que fue terminado y aprovado en 1995; por eso el nombre IEEE 1394–1995. IEEE 1394a Diferentes implementaciones de la especificación 1995 generaron problemas de interoperación. Para aclarar el estándar original se diseñó el suplemento 1394a, manteniendo compatibilidad total con los productos anteriores. IEEE 1394b Se desarrolló un canal serial 1394 más rápido llamado la versión B, que define la extensión del estándar original para soportar velocidades de 800 Mbps, 1.6 Gbps y 3.2 Gbps. Actualmente la máxima tasa de transmisión que se puede implementar es de 800 Mbps. IEEE 1394.1 Este estándar especifica el diseño de un puente 1394 (bridge), para conectar diferentes canales IEEE 1394 entre sı́, y formar un sistema que permite anexar más de 64 nodos y controlar el ancho de banda.. 2.6.4.. Arquitectura IEEE 1394. Para implementar el canal IEEE 1394 en los equipos de cómputo, generalmente se utiliza un adaptador 1394 anexado al canal PCI de la computadora, utilizando un puente OHCI para integrar ambos canales. La figura 2.13 muestra la configuración tı́pica del adaptador 1394 en los equipos de cómputo..

(42) 2.6. FUNDAMENTOS DEL CANAL IEEE 1394. 23. Figura 2.13: Equipo de cómputo con adaptador IEEE 1394. 2.6.5.. Arquitectura de Nodos. Los nodos o dispositivos 1394 pueden tener uno o más puertos. Un nodo con un solo puerto termina una rama del canal, mientras que nodos con dos o más puertos permiten continuar el canal como se muestra en la figura 2.14. Los nodos con múltiples puertos 1394 permiten extender la topologı́a con un ambiente de señalización punto a punto. Cuando un nodo multipuerto recibe un paquete, se detecta, acepta, sincroniza con el reloj local del repetidor y retransmite a los otros puertos del nodo. La organización fı́sica y lógica de los dispositivos conectados al canal IEEE 1394, se clasifican según los siguientes términos: Módulo Representa un dispositivo fı́sico conectado al canal 1394, que contiene uno o más.