Download desarrollo de una interfaz utmc para letreros de mensajería variable

 UNIVERSIDAD DE CHILE
FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS
DEPARTAMENTO DE INGENIERÍA ELÉCTRICA
DESARROLLO DE UNA INTERFAZ UTMC PARA LETREROS DE MENSAJERÍA VARIABLE
MEMORIA PARA OPTAR AL TITULO DE INGENIERO CIVIL ELECTRICISTA
DANIEL ORLANDO CORTÉS BARRÍA
PROFESOR GUÍA:
NICOLÁS HUMBERTO BELTRÁN MATURANA
MIEMBROS DE LA COMISIÓN:
LUÍS SANTIAGO VARGAS DÍAZ
JUAN PABLO BOBENRIETH GIGLIO
SANTIAGO DE CHILE
AGOSTO 2008
2008
UNIVERSIDAD DE CHILE
FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS
DEPARTAMENTO DE INGENIERÍA ELÉCTRICA
DESARROLLO DE UNA INTERFAZ UTMC PARA LETREROS DE MENSAJERÍA VARIABLE
DANIEL ORLANDO CORTÉS BARRÍA
COMISIÓN EXAMINADORA
CALIFICACIONES
Nota (Nº)
Nota (Letras)
Firma
PROFESOR GUÍA:
SR. NICOLÁS BELTRÁN
:
………
……………………
……………….
PROFESOR CO­GUÍA:
SR. HECTOR AGUSTO ALEGRÍA
:
………
……………………
……………….
PROFESOR INTEGRANTE:
SR. JUAN PABLO BOBENRIETH
:
………
……………………
……………….
NOTA FINAL EXAMEN DE TÍTULO
:
………
……………………
……………….
MEMORIA PARA OPTAR AL TÍTULO DE
INGENIERO CIVIL ELECTRICISTA
SANTIAGO DE CHILE
AGOSTO 2008
Agradecimientos
A mis padres, Ismael y Jeannette. A mis abuelos, mis hermanos y mis sobrinos. Gracias, hermano, por moverme pese a la enorme inercia ofrecida por mí.
A mis profesores, Nicolás Beltrán y Héctor Agusto, por la confianza, la paciencia y la dedicación.
A Juan Pablo Bobenrieth por el apoyo, a mis ex­compañeros de SSS en Auter por la ayuda, soporte, enseñanzas y por la TS7200.
A todos mis amigos de la Universidad, desde primer año en adelante. Son muchísimos para nombrarlos a todos, pero ellos saben quienes están incluídos acá.
i
RESUMEN DE LA MEMORIA
PARA OPTAR AL TÍTULO
DE INGENIERO CIVIL ELECTRICISTA
POR: DANIEL CORTÉS BARRÍA
FECHA: 03 DE JULIO DE 2008
PROF. GUÍA: SR. NICOLÁS BELTRÁN
Desarrollo de una interfaz UTMC para Letreros de Mensajería Variable
El objetivo del presente Trabajo de Título es implementar un dispositivo que comunique un sistema de control de tránsito, bajo el estándar UTMC (Urban Traffic Management & Control), con letreros de mensajería variable VMS (Variable Message Signs), para desplegar información en carreteras y autopistas. El estándar UTMC está disponible desde 1997 y fue una iniciativa para impulsar el desarrollo abierto de Sistemas de Transporte Inteligentes (ITS) en áreas urbanas. Dentro de los distintos elementos de un Sistema de Control de Tránsito, se encuentran los Letreros de Mensajería Variable. Estos paneles luminosos, que utilizan tecnología LED (light emiting diode), proporcionan información al conductor referente a las condiciones de operación de la vía en cada momento.
El sistema desarrollado utiliza la tarjeta TS7200 de Technologic Systems para realizar la implementación. Esta tarjeta incluye un computador de placa única (Single Board Computer, SBC) que contiene un procesador ARM9 de 200 MHz. La tarjeta utilizada y el enfoque de UTMC de ocupar sistemas abiertos conduce a operar en un entorno Linux para el desarrollo de software, debido a su robustez, adaptabilidad y funcionalidad. Linux está disponible en muchas distribuciones diferentes escogiéndose para el desarrollo de esta aplicación la distribución Debian para el cliente y Ubuntu para el servidor.
UTMC especifica que los equipos VMS deben comunicarse vía SNMP (Simple Network Management Protocol) con los servidores. En este desarrollo se utilizó Net­SNMP, un software de código abierto para Linux que define directivas de extensibilidad del agente SNMP. Entre ellas, se usó la directiva pass, que permite traspasar el control completo de un sub­conjunto de información de SNMP a un comando específico. Se definió un script programado en bash (Lenguaje de consola o shell de Linux), para recibir las peticiones SNMP del servidor.
En el caso del servidor se implementó un webserver en Apache, utilizando el lenguaje PHP para generar dinámicamente una página HTML, para recibir y entregar datos al Agente. Para esto se utilizó, además de PHP, las bibliotecas PHP­GD para manejo de gráficos y PHP­
SNMP para implementar el cliente SNMP en Apache.
El sistema desarrollado con software abierto y disponible en Internet, cumple con las funciones básicas de un Sistema de Control de Tránsito, bajo el estándar UTMC, para Letreros de Mensajería Variable VMS. La interfaz en un sistema embebido, incluido en la tarjeta TS7200 de Technologic Systems, permite enviar desde una consola mensajes a desplegar en un panel de aviso de autopista o carretera, satisfactoriamente.
ii
"Las obras de conocimiento deben ser libres, no hay excusas para que no sea así"
R. Stallman
1
Índice de contenido
1 Introducción ..............................................................................................................................6
1.1 Objetivos............................................................................................................................7
1.2 Estructura de la memoria..................................................................................................8
2 Contextualización......................................................................................................................9
2.1 Control de Tránsito............................................................................................................9
2.2 Redes de comunicaciones .............................................................................................10
2.3 Letreros de mensajes variables (VMS)...........................................................................11
2.4 Sistemas Embebidos.......................................................................................................13
2.4.1 Introducción..............................................................................................................13
2.4.2 Arquitectura básica...................................................................................................15
2.4.3 Microprocesador.......................................................................................................16
2.4.4 Memoria....................................................................................................................18
2.4.5 Single Board Computers (SBC)...............................................................................20
2.4.6 Placa TS7200...........................................................................................................22
2.5 ITS...................................................................................................................................26
2.6 Estándar UTMC ..............................................................................................................27
2.6.1 Introducción..............................................................................................................27
2.6.2 Características globales...........................................................................................27
2.6.3 Arquitectura..............................................................................................................27
2.6.4 Cumplimiento de norma UTMC................................................................................29
2.6.4.1 Cumplimiento de Interfaz..................................................................................29
2.6.4.2 Cumplimiento de Productos y Sistemas UTMC...............................................29
2.6.4.3 Cumplimiento de Estatuto y Legales................................................................30
2.6.4.4 Certificación de Sistema...................................................................................30
2.6.4.5 Decisiones de Cumplimiento y Consecución....................................................30
2.6.4.6 Actividades de desarrollo..................................................................................30
2.6.5 NTCIP.......................................................................................................................31
2.6.6 Implementaciones Piloto..........................................................................................33
2.7 SNMP...............................................................................................................................34
2.7.1 Introducción..............................................................................................................34
2.7.2 Componentes básicos de SNMP ............................................................................34
2.7.3 Estructura de mensaje SNMP de UTMC.................................................................37
2.8 GNU, Linux y el software libre.........................................................................................38
2.8.1 Distribuciones de Linux............................................................................................41
2.9 Descripción del trabajo específico de esta memoria.......................................................42
2.9.1 Metodología..............................................................................................................42
2.9.2 Diseño del sistema...................................................................................................43
2.9.3 Servidor UTMC: .......................................................................................................44
2.9.3.1 Apache..............................................................................................................45
2
2.9.4 Cliente UTMC...........................................................................................................45
2.9.4.1 NET­SNMP.......................................................................................................45
2.9.4.2 Generando código a partir del MIB...................................................................46
2.9.4.3 Estructuras de Datos........................................................................................47
2.9.4.4 Búsqueda de Datos...........................................................................................47
2.9.4.5 Manipulación de Datos.....................................................................................48
2.9.5 Entorno de Programación........................................................................................48
2.9.5.1 Herramientas de compilación...........................................................................48
2.9.6 Definición de la entrada al sistema..........................................................................48
3 Implementación del Sistema Desarrollado.............................................................................50
3.1 Servidor UTMC................................................................................................................50
3.1.1 Descripción y configuración del servidor.................................................................50
3.1.2 Minicom....................................................................................................................51
3.1.3 CrossTool­0.42.........................................................................................................52
3.2 Cliente UTMC..................................................................................................................53
3.2.1 Descripción de la configuración de la Tarjeta TS7200............................................53
3.2.2 Flash OnBoard TS7200 ...........................................................................................55
3.2.3 Recursos y soporte para actualizaciones ...............................................................56
3.2.4 Actualización Flash OnBoard ..................................................................................57
3.2.5 Actualización de Bibliotecas en la Flash OnBoard .................................................58
3.2.6 Actualización de la Imagen del Kernel ....................................................................59
3.2.7 Bootloader RedBoot.................................................................................................60
3.2.8 Debian......................................................................................................................61
3.2.8.1 apt­get...............................................................................................................61
3.2.8.2 Usar Debian con NFS.......................................................................................63
3.2.8.3 Usar Debian en la Compact Flash....................................................................64
3.2.9 Utilizando Net­SNMP...............................................................................................66
3.2.9.1 Control de Acceso.............................................................................................67
3.2.9.2 Extensibilidad del Agente..................................................................................69
3.2.10 Implementación del Script para la extensión del agente.......................................70
3.3 Implementación del webserver........................................................................................71
3.3.1 Configuración de Apache.........................................................................................71
3.3.2 Utilizando PHP y GD................................................................................................72
4 Discusión de resultados..........................................................................................................74
5 Conclusiones ..........................................................................................................................78
6 Referencias.............................................................................................................................79
7 Glosario...................................................................................................................................81
8 Anexos....................................................................................................................................87
8.1 El Microprocesador ARM.................................................................................................87
8.2 Archivo Y1­01017­v2.txt (Cabecera MIB UTMC)............................................................88
8.3 Archivo VMSUTMC.MIB..................................................................................................92
3
8.4 Script para Net­SNMP (archivo utmcVMSType1.sh)....................................................111
8.5 Archivo Index.php para el webserver............................................................................113
4
Índice de figuras
Figura 1: Sala de Control de Tránsito.........................................................................................10
Figura 2: Letrero de Mensajería Variable...................................................................................12
Figura 3: Arquitectura de un Sistema Embebido........................................................................16
Figura 4: Dispositivos PC104 apilados.......................................................................................21
Figura 5: Tarjeta TS7200............................................................................................................23
Figura 6: Modelo de Referencia lógica para un sistema UTMC.................................................28
Figura 7: Estándares de NTCIP..................................................................................................32
Figura 8: Arquitectura SNMP......................................................................................................35
Figura 9: Estructura de Árbol de la MIB......................................................................................37
Figura 10: Shell de Unix..............................................................................................................40
Figura 11: Esquema general de la implementación de la interfaz UTMC para VMS.................44
Figura 12: cable Null­modem......................................................................................................51
Figura 13: Información SNMP obtenida con el Webserver .......................................................73
5
1 Introducción Este proyecto se enmarca en los sistemas de control de tránsito, y su estandarización mediante normas para conseguir una fácil implementación de estructuras que por su complejidad poseen componentes de distintas tecnologías o distintos mecanismos de comunicación. En particular, se implementa un dispositivo que comunique un sistema de control bajo el estándar UTMC (Urban Traffic Management & Control, Control y Manejo de Tránsito Urbano) con letreros de mensajería variable para desplegar información en vías, VMS (Variable Message Signs). La ventaja de contar con un dispositivo que realice esta comunicación es tener acceso a los distintos tipos de letreros VMS instalados en Santiago, sin que éstos necesariamente cumplan con la norma UTMC, y realizar el control y la comunicación integrada sobre ellos de manera eficaz. La implementación está enfocada dentro de los sistemas utilizados en Chile para el control de tránsito en áreas urbanas. En Santiago está manejado por la Unidad Operativa de Control de Tránsito (UOCT). La UOCT es un organismo técnico dependiente del Ministerio de Transportes y Telecomunicaciones, cuya principal función es la administración y operación del sistema de control de tránsito de Santiago.
Este sistema centralizado permite coordinar, supervisar y monitorear remotamente la operación de casi la totalidad de los semáforos existentes en la ciudad. Opera permanentemente en tiempo real. En cada segundo transmite y recibe información a todos los semáforos. Para ello, se cuenta con una completa red de comunicaciones entre cada cruce unido al sistema y la UOCT.
El sistema es propietario de SIEMENS. La empresa AUTER (Automática y Regulación S.A.) se dedica a la mantención y subcontratación de los sistemas de la UOCT. [1]
AUTER, produce y comercializa servicios de ingeniería y productos en el área de control electrónico aplicado al Tránsito y Transportes. Fundada en 1980, nace a la vida comercial para prestar servicios de mantención de sistemas de control de tránsito, expandiendo posteriormente su campo de acción a la integración de soluciones de control e informática que ayuden a la gestión vial de ciudades y carreteras. [2]
En la UOCT, se controlan letreros de mensajería variable VMS para desplegar información de tiempos de viaje y estado de las vías en algunos puntos estratégicos de Santiago. Para esto se contrata un servicio externo que utiliza vehículos para viajar por las vías y calcular el tiempo de viaje de un punto a otro. Esta información es recibida por un operador de la sala de control de tránsito en la UOCT, el cual se encarga de configurar y transmitir los mensajes a los letreros VMS, vía módem. Esta operación manual cumple con los objetivos de desplegar 6
mensajes, pero no permite automatizar las instrucciones de acuerdo al estado de otros dispositivos de control de tránsito. La principal motivación de este trabajo de memoria es incorporar efectivamente el uso de Letreros de Mensajería Variable dentro de un sistema de control de tránsito y permitir la definición de políticas de control y comunicación, además de reducir los costos de operación de letreros VMS.
1.1 Objetivos
El objetivo principal es implementar un dispositivo autónomo (es decir, cuyo funcionamiento no dependa de otros equipos) que permita comunicar un sistema de control bajo el estándar UTMC con letreros de mensajería variable para desplegar información en vías, VMS. Tal dispositivo debe tener los puertos necesarios para comunicarse tanto con el servidor del sistema de control como con los letreros, al menos con uno, aunque es preferible que sea con varios. También debe contar con la capacidad de procesamiento y memoria necesarias para controlar los letreros, recibiendo las instrucciones del sistema de control y enviando el estado de distintas variables del letrero al sistema. Estas variables deben ser al menos las que están especificadas por el estándar UTMC.
Para lograr el objetivo principal se definen los siguientes objetivos secundarios:
●
Obtener el dispositivo que será utilizado para realizar la interfaz.
El dispositivo debe cumplir con los requisitos mencionados. Además es preferible que sea un sistema embebido de bajo costo y que facilite la incorporación de software libre en él.
●
Cumplir con el estándar UTMC.
UTMC define los protocolos que deben ser utilizados para la comunicación con dispositivos VMS, y un conjunto de variables y sus características las cuales serán comprendidas por la interfaz implementada. ●
Utilizar software libre y de poco tamaño.
La implementación se realiza utilizando software libre, el cual se encuentra disponible en la red sin costo. Además debe tener documentación adecuada y de preferencia contar con foros de consulta o listas de correo. Sin perjuicio de lo anterior, se prefiere software de menor tamaño posible, para que pueda ser instalado en el sistema embebido.
●
Realizar las pruebas necesarias para decidir si el objetivo principal fue cumplido.
Para esto se implementa un webserver por el lado del servidor UTMC, para observar el estado de la comunicación vía SNMP y realizar cambios en el VMS.
●
Realizar un análisis de costo estimado de la implementación.
Dicho análisis permitirá hacer una comparación frente a un sistema implementado con software propietario, para estimar el ahorro que se puede lograr con un sistema de código abierto.
7
1.2 Estructura de la memoria
El capítulo 1 es esta introducción para enmarcar los objetivos, estructura y alcances. Permite visualizar y comprender el contenido de la misma.
En el capítulo 2 se hace una revisión bibliográfica y una contextualización del control de tránsito. Se introducen brevemente los sistemas embebidos, los cuales son dispositivos que procesan información e interactúan con el medio y con otros equipos. Se describen los estándares de comunicación, que están implementados en el sistema desarrollado en este trabajo. También se realiza una descripción del hardware y el software utilizado en la implementación, haciendo énfasis en el carácter de “software libre” de los programas.
En el capítulo 3 se describe la implementación del dispositivo, así como la simulación de un servidor UTMC para la comunicación. Además, se incluyen las pruebas experimentales realizadas para observar el comportamiento del sistema.
En el capítulo 4 se analizan los resultados, bajo los parámetros establecidos por UTMC para una adecuada comprensión del sistema. Se realiza una evaluación del comportamiento del dispositivo.
En el capítulo 5 se presentan las conclusiones finales y se realiza una reseña del trabajo futuro, para expandir y generalizar la implementación para otros equipos de control de tránsito.
Se incluyen también referencias bibliográficas, un glosario de términos y anexos.
8
2 Contextualización. 2.1 Control de Tránsito
El transporte constituye un fenómeno social, histórico, económico y jurídico. Considerado como la circulación o desplazamiento de personas y materiales, es un fenómeno unido a la humanidad. [3]
Entre los diferentes tipos de transporte podemos encontrar:
●
Transporte vehicular
●
Transporte aéreo ●
Transporte ferrocarril ●
Transporte marítimo ●
Transporte fluvial ●
Transporte en bicicleta ●
Transporte peatonal ●
Transporte impulsado por animal El Transporte o tránsito vehicular (también llamado tráfico vehicular) es el fenómeno causado por el flujo de vehículos en una vía, calle o autopista. En español no existe la diferenciación que se hace en inglés entre las palabras "tránsito" y "tráfico". En inglés, la primera (transit) se refiere exclusivamente a lo que en español puede llamarse "transporte público", mientras que la segunda (traffic) es aproximadamente igual a "tráfico vehicular" o "tránsito vehicular". En castellano suele utilizarse "tránsito" para describir el flujo de elementos con movilidad y "tráfico" a los elementos transportados por otro medio.
En las grandes urbes, el tránsito vehicular se encuentra presente en casi todas las esferas de la actividad diaria de la gente y ocasiona numerosos fenómenos, entre los que destacan especialmente los congestionamientos y los accidentes.
Para regular el tránsito se han ideado múltiples mecanismos de control: desde el control humano (una autoridad regulando el flujo en el lugar mismo), pasando por la invención de los semáforos, hasta los modernos sistemas automatizados de control de tránsito. Especial atención merecen los sistemas de control de tránsito vehicular, donde un sistema centralizado controla simultánea y sincronizadamente varios actuadores (semáforos, letreros) distribuidos geográficamente, por ejemplo dentro de una ciudad. En la figura 1 se aprecia una sala de control de tránsito típica para una ciudad.
9
Figura 1: Sala de Control de Tránsito
Dada la magnitud de estos sistemas y su complejidad, se han realizado esfuerzos para estandarizarlos. El estándar UTMC, el cual se especifica en el punto 2.6, es el marco principal de este trabajo.
2.2 Redes de comunicaciones Obviando posibles predecesores en la mitología griega, la mensajería a caballo y las señales de humo, la Ingeniería de Telecomunicación, como se concibe actualmente, empezó con la telegrafía. Desde sus inicios ha estado profundamente unida a la electrónica de señales. [4]
En los últimos años y aprovechándose del desarrollo en el campo de la informática, ambas tecnologías han convergido hacia los sistemas digitales de emisión y recepción, como la telemática y la telefonía móvil o celular.
Los elementos de un sistema de telecomunicación son un emisor, un medio y un receptor. El emisor es un dispositivo que transforma o codifica el mensaje en un fenómeno físico: la señal. El medio de transmisión, por su naturaleza física, tiende a modificar o degradar la señal en su trayecto desde el emisor al receptor. El receptor debe requerir un mecanismo de decodificación para recuperar el mensaje a partir de la señal recibida. Este mecanismo puede ser diseñado para tolerar una degradación significativa de la señal.
Para describir el uso de datos entre la conexión física de la red y la aplicación del usuario final, la ISO (International Standarization Organization, Organización Internacional de Estandarización) desarrolló en 1984 un modelo llamado OSI (Open Systems Interconection, Interconexión de sistemas abiertos). Este modelo permite establecer una comunicación entre los dos extremos mediante una concepción de ella en base a las siguientes capas: [5]
10
●
Capa Física: Se encarga de las características eléctricas, mecánicas, funcionales y de procedimiento que se requieren para mover los bits de datos entre cada extremo del enlace de la comunicación.
●
Capa de Enlace: Asegura la confiabilidad del medio de transmisión, ya que realiza verificación de errores, retransmisión, control fuera del flujo y la secuenciación de las capacidades que se utilizan en la capa de red.
●
Capa de Red: Proporciona los medios para establecer, mantener y concluir las conexiones conmutadas entre los sistemas del usuario final. Es, por lo tanto, la capa más baja que se ocupa de la transmisión de extremo a extremo.
●
Capa de Transporte: Esta capa proporciona el control de extremo a extremo y el intercambio de información con el nivel que requiere el usuario. Representa el corazón de la jerarquía de los protocolos que permite realizar el transporte de los datos en forma segura y económica.
●
Capa de Sesión: Administra el diálogo entre las dos aplicaciones en cooperación, mediante el suministro de los servicios que se necesitan para establecer la comunicación, flujo de datos y conclusión de la conexión.
●
Capa de Presentación:
Permite a la capa de aplicación interpretar el significado de la información que se intercambia. Realiza las conversiones de formato mediante las cuales se logra la comunicación de dispositivos.
●
Capa de Aplicación:
Se entiende directamente con el usuario final, al proporcionarle el servicio de información distribuida para soportar las aplicaciones y administrar las comunicaciones por parte de la capa de presentación.
2.3 Letreros de mensajes variables (VMS)
Estos carteles luminosos de tecnología LED (Light Emiting Diode, Diodo Emisor de Luz) brindan información al conductor referente a las condiciones de operación de la autopista en cada momento. La información puede ser de diferentes tipos:
●
Mensajes de Precaución
Alertan de la existencia de un incidente ocasional y tienen máxima prioridad para ser 11
presentados al conductor. Por ejemplo: accidentes, niebla, pavimento resbaladizo, zona de derrumbes, etc.
●
Mensajes de Prevención
Alertan sobre la existencia de incidentes repetitivos. Por ejemplo: congestión o tránsito lento.
●
Mensajes de Información
Son mensajes relacionados con normas de seguridad, anuncios de tareas planificadas y datos de interés. Este tipo de mensajes es el de menor prioridad.
La información desplegada en un letrero de mensajería variable se genera en el Centro de Monitoreo y Control de Tránsito, ya sea en forma automática, gracias a los diversos mecanismos de detección, o manualmente a través de un operador.
Por tratarse de mensajes que un conductor recibe circulando a alta velocidad, deben ser breves y concisos, dando preferencia a formatos estándares establecidos con el fin de lograr que un mismo fenómeno se anuncie siempre con un mismo mensaje.
En la figura 2 se observa un VMS instalado en una vía para proveer información a los automovilistas.
Figura 2: Letrero de Mensajería Variable
Las ventajas de utilizar la tecnología LED son las siguientes:
●
Los LEDs producen más luz por energía que las lámparas incandescentes. Esto es útil en dispositivos energizados por baterías o energía solar.
●
Los LEDs pueden emitir luz en un color determinado sin el uso de filtros adicionales.
Esto es más eficiente en términos energéticos y disminuye los costos iniciales.
●
El Empaquetado sólido de los LEDs puede ser diseñado para enfocar su luz. 12
Las fuentes de luz incandescentes o fluorescentes a menudo requieren un reflector externo para juntar la luz y dirigirla a un área determinada.
●
Mejor respuesta frente a variabilidad de luz.
Si los LEDs son usados en aplicaciones donde se requiere variabilidad de luz (dimm), éstos no cambian su tinte de color en función de la corriente, a diferencia de las lámparas incandescentes que tienden a volverse amarillentas a menor corriente.
●
Los LEDs son ideales para aplicaciones que están sujetas a frecuentes ciclos on­off.
A diferencia de las fluorescentes que muestran menor tiempo de vida útil en este tipo de régimen.
●
Los LEDs, son elementos de estado sólido.
Difícilmente son dañados frente a movimientos físicos causados por un agente externo. ●
Tienen una vida útil relativamente larga. Se estima entre 35.000 a 50.000 horas, en contraste a los tubos fluorescentes que duran aproximadamente 30.000 horas y las lámparas incandescentes que duran entre 1.000 y 2.000 horas.
●
Los LEDs fallan disminuyendo su luz en la mayoría de los casos.
A diferencia de la destrucción abrupta típica de las luces incandescentes.
●
Los LEDs pueden ser muy pequeños y fácilmente instalables en circuitos impresos.
También hay desventajas de utilizar LEDs: mayor precio por lumen en base al costo inicial, mayor dependencia de la temperatura ambiente, necesidad de resistencias en serie para regular la corriente suplida, espectro de LEDs blancos difiere significativamente de un radiador de cuerpo negro (como el sol o las luces incandescentes). Sin embargo, estas desventajas no son significativas frente a sus ventajas en la mensajería variable para caminos y carreteras [6].
2.4 Sistemas Embebidos
2.4.1 Introducción
Son dispositivos usados para controlar equipos, operación de maquinarias o plantas industriales completas. El término "embebido" (también se lo conoce como "incrustado", "embutido", o “empotrado”) implica que estos dispositivos son una parte integral del sistema en que se encuentran. La ventaja de un sistema "embebido" es que al estar de tal forma incrustado, puede quedar tan oculto que la presencia de tales circuitos resulte desapercibida a quien observe el sistema. [7]
En la parte central se encuentra un microprocesador, un microcontrolador, un DSP (Digital Signal Processor, Procesador de Señal Digital) o un FPGA (Field Programmable Gate Array, Arreglo de Compuertas Programable), es decir, la unidad que aporta inteligencia al sistema. 13
Según los requisitos del sistema puede incluir memoria interna o externa y otro microprocesador con arquitectura específica.
La comunicación adquiere gran importancia en los sistemas embebidos. Es común que se requiera comunicación mediante interfaces estándar de cable o inalámbricas. Normalmente se incorporarán puertos de comunicaciones del tipo RS232, RS485, SPI, I²C, CAN, USB, IP, WiFi, GSM, GPRS, entre otros.
●
RS232: Estándar de comunicación serial (también llamado EIA232C) establecido por la “Electronic Industry Association” en 1969, cuya última modificación fue hecha en 1997 (EIA232F). Se definen las características eléctricas, tasa de señal, temporización, señales de slew­rate, nivel de voltaje resistivo, comportamiento de corto­circuito y máxima capacitancia de carga. [8]
●
RS485: Estándar de comunicación serial de conexión de dos hilos trenzados, half­duplex y multipunto. Permite comunicación hasta 32 dispositivos interconectados. También incluye la opción full­duplex con 4 hilos. [9]
●
SPI: Serial Peripherical Interface, bus Interfaz de Periféricos Serial. Estándar de Motorola que opera en modo full­duplex. Los dispositivos se comunican en un modo maestro/esclavo donde el maestro inicia el envío de datos. Es llamado también bus serial de cuatro hilos.[10]
●
I²C: Estándar creado por Phillips de comunicación en un bus serial multi­maestro. Utiliza 2 líneas seriales de colector abierto con resistencias, con voltajes típicos entre +5V y +3.3V. Se define un espacio de direcciones de 7 bits con 16 direcciones reservadas, por lo que pueden comunicarse en el mismo bus un máximo de 112 nodos. Los modos más comunes son el modo estándar a 100 Kbit/s y el modo de baja velocidad a 10 Kbit/s [11]
●
CAN: Controller­Area­Network, Red de Área de Controladores, es un protocolo de red y un estándar de bus diseñado para permitir a los microcontroladores y dispositivos comunicarse entre ellos y un computador huésped. Fue desarrollado en 1988 por Intel y estandarizado por la ISO 11898.
●
USB: Universal Serial Bus, Bus Serial Universal. Creado en 1996 por IBM, Intel, Northern Telecom, Compaq, Microsoft, Digital Equipment Corporation y NEC. Permite varios periféricos conectados en una interfaz y mejorar las capacidades de plug­and­play permitiendo conectar y desconectar sin reiniciar el computador. Provee también 14
alimentación de baja potencia sin necesidad de una fuente externa y permite usar varios dispositivos sin requerir drivers específicos de los fabricantes. La especificación actual es la 2.0 con revisiones.[12]
●
IP: Internet Protocol, Protocolo de Internet. Protocolo orientado a datos utilizado para comunicar información a través de una red por conmutación de paquetes. Se utiliza comúnmente en conjunto con TCP (Transmission Control Protocol, Protocolo de Control de Transmisión) en la capa de transporte y Ethernet en la capa física del modelo OSI.[13]
El subsistema de presentación tipo suele ser una pantalla gráfica, táctil, LCD (Display de Cristal Líquido), alfanumérico, o cualquier visualizador de información que se adapte a las necesidades del sistema.
Denominamos actuadores a los elementos mediante los cuales se controlan las variables requeridas. Puede ser un motor eléctrico, un conmutador tipo relé, una válvula, una luz, o cualquier dispositivo que produzca una acción. El módulo de E/S, tanto analógicas como digitales, suele emplearse para procesar señales procedentes de sensores, activar diodos LED, reconocer el estado abierto o cerrado de un conmutador e interactuar con los actuadores.
El módulo de reloj es el encargado de generar diferentes oscilaciones a partir de un único oscilador principal. El tipo de oscilador es importante por varios aspectos: por la frecuencia, estabilidad y consumo de corriente requeridos. Los osciladores con mejores características en cuanto a estabilidad y costo son basados en resonadores de cristal de cuarzo, mientras que los que requieren menor consumo son basados en circuitos RC (filtros de resistencias y condensadores). Mediante sistemas PLL (Phase­Locked Loop, Bucles de Enganche de Fase), se obtienen otras frecuencias con la misma estabilidad que el oscilador patrón.
El módulo de energía se encarga de generar las diferentes tensiones y corrientes para alimentar los circuitos del sistema embebido. Usualmente se trabaja con un intervalo de posibles tensiones de entrada que, mediante conversores AC/DC o DC/DC, se obtienen las diferentes tensiones necesarias para alimentar los componentes activos del circuito.
Además de los conversores AC/DC y DC/DC se utilizan otros módulos típicos, tales como filtros o circuitos integrados supervisores de alimentación. El consumo de energía puede ser determinante en el desarrollo de sistemas embebidos que se alimentan con baterías, con lo que el tiempo de uso suele ser la duración de la carga de éstas.
2.4.2 Arquitectura básica
Un sistema embebido posee una arquitectura semejante a la de un computador. En la figura 3 se muestra un ejemplo sencillo de arquitectura. 15
Figura 3: Arquitectura de un Sistema Embebido
2.4.3 Microprocesador
También se denomina CPU (Central Processing Unit, Unidad Central de Procesamiento). La CPU se ocupa del control y el proceso de datos en los computadores. Básicamente existen dos tipos de diseño de los microprocesadores: RISC (Reduced−Instruction−Set Computing, Cómputo con Set de Instrucciones Reducido) y CISC (complex−instruction−set computing, Cómputo con Set de Instrucciones Complejo). Los microprocesadores RISC se basan en la idea que la mayoría de las instrucciones para realizar procesos son relativamente simples, por lo tanto se minimiza el número de instrucciones y su complejidad a la hora de diseñar la CPU. Algunos ejemplos de arquitectura RISC son el SPARC de Sun Microsystems, el microprocesador Alpha diseñado por la antigua Digital, hoy absorbida por Compaq y los Motorola 88000, PowerPC y la línea ARM. Estos procesadores se suelen emplear en aplicaciones industriales y profesionales por su gran rendimiento y fiabilidad. Los microprocesadores CISC, por el contrario, tienen una gran cantidad de instrucciones, por lo tanto son muy rápidos procesando código complejo. Las CPU CISC más extendidas son las de la familia 80x86 de Intel. Existen otras compañías como Cirix y AMD que fabrican microprocesadores con el juego de instrucciones 80x86 a un precio inferior que los de Intel.
Existen muchos tipos de Microprocesadores, algunas de las principales arquitecturas se enumeran a continuación:
●
MIPS: 16
Acrónimo de Microprocessor without Interlocked Pipeline Stages, es una arquitectura de procesadores tipo RISC desarrollada por MIPS Computer Systems Inc. Los diseños de MIPS se usan en las estaciones de trabajo de Silicon Graphics y tienen una importante presencia en sistemas embebidos, dispositivos que soportan Windows CE y en los routers de Cisco.
●
PowerPC: PowerPC (usualmente abreviada PPC), es el nombre original de la arquitectura de computadoras de tipo RISC que fue desarrollada por IBM, Motorola y Apple. Los procesadores de esta familia son producidos por IBM y Freescale Semiconductor, la división de semiconductores y microprocesadores de Motorola. Son utilizados principalmente en computadores Macintosh de Apple Computer.
●
Intel x86: Microprocesadores de la familia Intel o compatibles, denominados así por la terminación (antigua) de sus nombres: 8086, 80286, 80386 y 80486. La arquitectura es notablemente no limpia, por mantener compatibilidad con la línea de procesadores de 16 bits de Intel, los cuales a su vez también eran compatibles con una familia de procesadores de 8 bits.
●
Coldfire: Microprocesador de arquitectura de 68k fabricado para desarrollo de sistemas embebidos por Freescale (anteriormente el sector dedicado a semiconductores de Motorola). Los modelos más modernos de ColdFire son suficientemente compatibles con los procesadores 68k. El proyecto Debian está trabajando en compatibilizar su adaptación a m68k con los ColdFires, pues existen modelos de ColdFire más rápidos que el 68060.
●
ARM: El diseño del ARM se ha convertido en uno de los más usados del mundo, sobre todo en el mundo de los sistemas embebidos. En 2008, cerca del 75% de los procesadores de 32 bits poseen este chip en su núcleo. Las ventajas de utilizar procesadores ARM para sistemas embebidos son su eficiencia, bajo nivel de consumo y simplicidad de utilización. En el anexo 1 se describe en detalle esta arquitectura.
●
SPARC: SPARC (Scalable Processor ARChitecture) es una arquitectura RISC big­endian, es decir, una arquitectura con un conjunto reducido de instrucciones. Sun Microsystems diseñó esta arquitectura y la licenció a otros fabricantes: Texas Instruments, Cypress Semiconductor, Fujitsu, LSI Logic, entre otros. SPARC es la primera arquitectura RISC abierta y las especificaciones de diseño son públicas, de esta manera otros fabricantes de microprocesadores pueden desarrollar su propio diseño.
●
AVR: 17
Los AVR son una familia de microcontroladores RISC de Atmel. La arquitectura de los AVR fue concebida por dos estudiantes en el Norwegian Institute of Technology y posteriormente fue refinada y desarrollada en Atmel Norway, subsidiaria de Atmel y fundada por los dos arquitectos del chip. El AVR es una CPU de arquitectura Harvard. Tiene 32 registros de 8 bits. A diferencia de los microcontroladores PIC, el stack se ubica en éste espacio de memoria unificado, y no está limitado a un tamaño fijo.
●
PA­RISC: Nombre por el que se conoce una arquitectura de microprocesadores desarrollada por sistemas Hewlett­Packard y VLSI Technology Operation. Esta arquitectura se basa en el modelo RISC y en PA (Precision Architecture). También se suelen referir a ella como la arquitectura HP/PA, Hewlett Packard Precision Architecture. PA se desarrolla en Palo Alto, donde se encuentra la central de HP.
2.4.4 Memoria
En ella se encuentra almacenado el código ejecutable y los datos. La memoria de un computador se puede definir como los circuitos que permiten almacenar y recuperar la información. En un sentido más amplio, puede referirse también a sistemas externos de almacenamiento, como las unidades de disco o de cinta. En un computador hay una jerarquía de memorias atendiendo al tiempo de acceso y a la capacidad, que normalmente son factores contrapuestos por razones económicas y en muchos casos también físicas. Comenzando desde el procesador hacia el exterior, es decir en orden creciente de tiempo de acceso y capacidad, se puede establecer la siguiente jerarquía: ●
Registros de procesador: Estos registros interaccionan continuamente con la CPU (porque forman parte de ella). Los registros tienen un tiempo de acceso muy pequeño y una capacidad mínima, normalmente igual a la palabra del procesador (1 a 8 bytes).
●
Registros intermedios: Constituyen un paso intermedio entre el procesador y la memoria. Tienen un tiempo de acceso breve y muy poca capacidad.
●
Memorias caché: Son memorias de pequeña capacidad. Normalmente su tamaño es una fracción de la memoria principal y tienen un tiempo de acceso menor a ésta. Este nivel de memoria se coloca entre la CPU y la memoria central. Dentro de la memoria caché pueden existir, a su vez, dos sub­niveles denominados caché on chip, o memoria caché dentro del circuito integrado y caché on board, memoria caché en la placa de circuito impreso pero fuera del circuito integrado. Por razones físicas, la primera es mucho más rápida que la segunda.
●
Memoria central o principal:
18
En este nivel residen los programas y los datos. La CPU lee y escribe en esta memoria con menos frecuencia que en los niveles anteriores. Tiene un tiempo de acceso relativamente rápido y gran capacidad.
●
Extensiones de memoria central:
Son memorias de la misma naturaleza que la memoria central, que amplían su capacidad de forma modular. El tiempo de acceso es similar o un poco mayor al de la memoria principal y su capacidad puede ser algunas veces mayor.
●
Memorias de masas o auxiliares:
Son memorias que residen en dispositivos externos al computador, en ellas se archivan programas y datos para su uso posterior. También se utilizan estas memorias para apoyo de la memoria central en caso que ésta sea insuficiente (memoria virtual). Éstas memorias suelen tener gran capacidad pero pueden llegar a tener un tiempo de acceso muy lento comparado a los niveles anteriores. Dentro de ellas también se pueden establecer varios niveles de jerarquía.
Además existen dos tipos especiales de memoria:
●
BIOS­ROM
BIOS (Basic Input & Output System, Sistema Básico de Entrada y Salida) es código necesario para empezar la comunicación de los distintos elementos de la placa madre. La ROM (Read Only Memory, Memoria de Sólo Lectura no volátil) es un chip donde se encuentra el código BIOS.
●
CMOS­RAM
Es un chip de memoria de lectura y escritura, alimentado con una pila, donde se almacena el tipo y ubicación de los dispositivos conectados a la placa madre (disco duro, puertos de entrada y salida u otros). Además, contiene un reloj en permanente funcionamiento, que ofrece al sistema la fecha y la hora.
Un sistema embebido puede incorporar ranuras de expansión para tarjetas de tareas específicas que no vienen incorporadas en la placa madre, por ejemplo, más puertos de comunicaciones, acceso a red de computadores vía LAN (Local Area Network, Red de Área Local) o vía red telefónica. Un PC estándar suele tener muchas más ranuras de expansión que un sistema embebido. Las ranuras de expansión están asociadas a distintos tipos de bus: VESA, ISA, PCI, NLX (ISA + PCI), etc.
Al momento del desarrollo de esta memoria existen en el mercado fabricantes que integran un microprocesador y los elementos controladores de los dispositivos fundamentales de entrada y salida en un mismo circuito integrado, pensando en las necesidades de los sistemas embebidos (bajo costo, pequeño tamaño y entradas y salidas específicas). Su capacidad de proceso suele ser inferior a los procesadores de propósito general, pero cumplen con su cometido porque los sistemas donde se ubican no requieren tanta potencia. 19
En cuanto a los sistemas operativos necesarios para que un sistema basado en microprocesador pueda funcionar y ejecutar programas, suelen ser específicos para los sistemas embebidos. Así, nos encontramos con sistemas operativos de bajos requisitos de memoria, posibilidad de ejecución de aplicaciones de tiempo real y modulares (inclusión sólo de los elementos necesarios para el sistema embebido concreto). Los más conocidos en la actualidad son Linux Embedded, Windows CE, QNX y VxWorks de WindRiver.
2.4.5 Single Board Computers (SBC)
Los computadores típicamente consistían en media docena o más de tarjetas conectadas a una tarjeta base (backplane) que contenía la CPU, memoria, controlador de discos y puertos seriales y paralelos. Los PC basados en backplane fueron usados para adquisición de datos, control de procesos y proyectos, pero eran en general muy aparatosos para ser usados como sistemas embebidos con dispositivos.
Sin embargo, la tecnología de circuitos integrados avanzó rápidamente y funciones que realizaban placas enteras fueron integradas en un solo circuito LSI (large scale integration). Ésto permitió que circuitos LSI para CPU, memoria, almacenamiento y puertos I/O implementaran sistemas completos en una sola tarjeta, sin backplanes. El primer SBC fue el Big Board basado en el Z80 (1980), capaz de ejecutar un sistema operativo comercial, el CP/
M. [14]
Actualmente existen cientos de fabricantes de SBC con distintas tecnologías. Inicialmente, cada producto SBC era completamente único, en cuanto a su arquitectura y su implementación física. Al crecer el interés por disponer de compatibilidad con PC/AT, básicamente por el bajo costo debido a la producción en masa de PC/IBM compatibles, se crearon estándares para fabricar SBCs. Los principales estándares se describen a continuación:
●
EPIA­ITX: Es una versión compacta de las placas madres ATX, desarrolladas por VIA technologies. Existen versiones mini­itx (17x17 cm), nano­itx (12x12 cm), pico­itx (100x72 mm) y mobile­
itx (75 x 45 mm). Aunque son muy eficientes en términos de espacio, su principal desventaja es el precio elevado para el poder de procesamiento que entregan.
●
Flex­ATX: Es un formato derivado de ATX lanzado en 1999 por Intel. Especifica un tamaño no mayor que 229x191 mm y no puede tener más de 3 puertos de expansión [15]. No se encuentra actualmente en desarrollo activo, por lo que se decidió descartar para utilizar en este trabajo. ●
DTX: Formato anunciado para su desarrollo por AMD en 1997. Diseñado para pequeños PC con una dimensión de 203x244mm. Es un estándar abierto y compatible con ATX. Existe una 20
versión mini­DTX de 203x170mm. [16]. Como aún se encuentra en desarrollo, no existen placas de bajo costo que incorporen esta tecnología. ●
COM: COM­Express o “computador en módulo” (computer­on­module), es un PC altamente integrado y compacto que puede ser usado en una aplicación como un componente de circuito. Cada módulo COM Express integra una CPU y funcionalidad de memoria, I/O de un PC/AT, USB, puertos de audio, gráficos y Ethernet. Todas las señales de I/O son ubicadas en dos conectores de alta densidad en la parte inferior del módulo. La especificación es mantenida por PICMG [17]. Dado que se usa como componente de un circuito mayor, no se adecúa al diseño desarrollado en este trabajo.
●
PC104: Es un estándar de computador embebido que define el formato de la placa base (form factor) y el bus del sistema. La especificación completa está disponible en la IEEE P996.1. Es una implementación compacta del bus PC/AT ISA adecuada para sistemas embebidos. A diferencia de la clásica arquitectura ATX y bus PCI, usados en la mayoría de los computadores personales, el PC104 está diseñado para aplicaciones específicas, como adquisición de datos o sistemas de control industrial. La arquitectura de la placa base no es la típica placa de circuitos integrados (backplane), en el que van insertados los componentes. En un sistema PC104, éstos se ubican en módulos apilados. El tamaño estándar es de 90.17 mm × 95.89 mm. Utiliza conectores rígidos y confiables de pines en dos grupos de 40 y 64 pines cada uno. El manejador de bus es de 6mA que permite un bajo consumo por módulo (1 a 2 Watts). La altura depende del número de módulos conectados. En la figura 4 se muestra un ejemplo de sistema PC104.
Figura 4: Dispositivos PC104 apilados
Una instalación típica incluye una placa base, conversores analógico­digital y módulos I/O 21
digitales.
Existen tres versiones de la norma PC104, como se aprecia en la tabla 1:
Tabla 1: Normas PC104
Fecha
Nombre
Bus
Versión (2005)
1992
PC104
ISA (AT y XT)
2.5
1997
PC104­Plus
ISA y PCI
2.0
2003
PCI­104
PCI
1.0
El bus de la versión de 1992 del PC104 usa 104 pines. Estos pines incluyen todas las líneas normales usadas por el bus ISA, además añade líneas de masa para mejorar la integridad de las señales. La sincronización de las señales y los niveles de tensión son idénticos al bus ISA, pero con menos requisitos de corriente.
De forma similar, el bus del PC104­Plus es una versión compacta del bus PCI.
2.4.6 Placa TS7200
Existen más de 100 placas PC104 de distintos fabricantes (AMD, Kontron Embedded Modules, Fastwel Co., RTD Embedded Technologies, WinSystems, LiPPERT, VersaLogic Corp., Eurotech Spa, SeaTech Computers Inc, Technologic Systems, etc.). Los criterios para escoger una placa adecuada para el trabajo de esta memoria son los siguientes:
●
Bajo costo: No superior a 200 dólares
●
Procesador ARM. Dado que el 75% de los sistemas embebidos utiliza un procesador ARM, y existen muchos sistemas operativos diseñados para esta arquitectura, es razonable escoger un procesador ARM para el diseño.
●
Con soporte para Linux: En el desarrollo de esta memoria se escogió utilizar el sistema operativo Linux, por ser el sistema operativo de código libre más extendido para la implementación en la tarjeta y en el servidor (ver punto 2.8). Por lo tanto, idealmente se debe contar con una placa que tenga soporte para Linux, es decir: documentación, descarga de archivos y lista de correos.
Por estas consideraciones se escogió la placa TS7200 de Technologic Systems.
La TS7200 consiste en un computador de placa única (SBC) que contiene un procesador ARM9 de 200 Mhz. Pertenece a la serie TS­72XX la cual viene en varias configuraciones.
22
El EP9302 de Cirrus es el procesador central de la placa. Ésta contiene además 10/100 Ethernet on­chip, USB y un controlador de Flash/SDRAM. Se dispone de 32 Mb SDRAM Micron funcionando a 66 Mhz y 8 Mb de Flash Strata Intel. Un PLD (Dispositivo de Lógica Programable, Programmable Logic Device) es el circuito lógico de enlace. La placa también posee un timer watchdog, una Compact Flash IDE y un puerto PC104 de 8 bit. El procesamiento de números enteros es 20% más rápido que un procesador x86 de 133 Mhz de similares características. El TS7200 no necesita ventiladores ni disipadores de calor en el intervalo de temperaturas de ­20° a 70° C. Contiene un DSP (Procesador de Señal Digital), habilitado a través de 5 canales, un conversor Digital/Análogo de 12 bit, 20 líneas de Entrada/Salida y 2 puertos seriales estándar.
La interfaz PC104 de 8/16 bit habilita funcionalidades adicionales. En la figura 5 se muestra una fotografía de esta tarjeta.
Figura 5: Tarjeta TS7200
Las características del TS7200 son las siguientes:
●
Sistema operativo embebido TS­Linux instalado: El TS­Linux es una distribución de Linux que viene instalada en la memoria Flash por defecto. Sirve para demostrar la fácil utilización de las tarjetas TS­72XX. Está basada en la 23
versión 2.4.26, compilada para el procesador Cirrus ARM920T EP9301 y tiene capacidad de operación en tiempo real habilitando el módulo RTAI. El sistema de archivos puede ser JFFS/YAFFS en la Flash Onboard, EXT2 en la tarjeta Compact Flash o NFS a través del puerto Ethernet. [18]
●
CPU:
ARM920T EP9301 de 200 Mhz con MMU (Unidad de Manejo de Memoria, Memory Manager Unit) permite la utilización de sistemas operativos como Linux, Windows CE y otros similares. El núcleo ARM opera a 1.8V, mientras que el sistema de I/O opera a 3.3 V con un consumo entre 100 mW y 750 mW. La arquitectura ARM920T tiene 32 bit, un pipeline de 5 etapas (obtener, decodificar, ejecutar, almacenar, escribir). Con una arquitectura Von­Neumann, tiene 16 Kb de caché de instrucciones y 16 Kb de caché de datos. Para aplicaciones con restricciones de memoria, el set de instrucciones Thumb puede ser utilizado para proveer alta densidad de código. ●
8 Mb de memoria Strata Flash OnBoard (para boot de TS_Linux): Consiste en una memoria Flash Strata Intel de 3.3 V para recurso de Flash Onboard. Está compuesta de 64 sectores uniformes con 128 Kbytes por sector. El primer sector está reservado para el código de inicialización TS­BOOTROM, el cual inicia varias configuraciones internas para la operación adecuada del TS7200 y comprueba el acceso a la SDRAM. Los siguientes 48 sectores (6 Mb) son usados por JFFS2. Éste es un sistema de archivo con journaling (método para recuperar los datos frente a una desconexión de la energía) y utiliza un mecanismo para prolongar la vida de la Flash. Además es tolerante a fallas de poder durante las secuencias de escritura. Los últimos 1920 Kb de la Flash están reservados para el monitor ROM RedBoot, el FIS RedBoot (Flash Image System) y el FCONFIG de RedBoot (configuración de la Flash). El Kernel de Linux por defecto, vmlinux, es cargado en el FIS y el script1 por defecto y la dirección de MAC están contenidas en el FCONFIG. Se puede usar RedBoot FIS para almacenar y cargar imágenes2 Flash que contengan aplicaciones de eCos u otros sistemas operativos de tiempo real.
●
32 MB SDRAM: La SDRAM no es continua en el mapa físico de memoria del EP9302, pero la MMU es programada para remapear los bloques de RAM para que parezcan un bloque contiguo de memoria al comienzo del mapa virtual de memoria. En el caso de un chip de 256 Mb SDRAM, esta es localizada desde 0 a 32 Mb en el mapa virtual de memoria.
●
Socket de Compact Flash True­IDE: 1 un script es un guión o conjunto de instrucciones. Permiten la automatización de tareas creando pequeñas utilidades. Es muy utilizado para la administración de sistemas Unix. Son ejecutados por un intérprete de línea de órdenes y usualmente son archivos de texto.
2 Una imagen es un archivo en el cual está toda la información de una unidad física (disco duro, óptico, USB, etc.). El archivo se vuelca completamente sobre la unidad previamente formateada.
24
Permite conectar tarjetas Compact Flash (CF). Tienen la ventaja de ser un medio removible. Una Compact Flash USB Sandisk es recomendada para transferencia de archivos con un PC. En el TS7200 la interfaz de Compact Flash no es intercambiable, es decir, el TS7200 debe ser reiniciado antes de remover e instalar una Compact Flash. El formato de la CF debe ser EXT2 para su correcta operación con Linux como sistema de archivo raíz.
●
2 puertos OHCI compatibles con USB 2.0 (12 Mbit/s máximo)
●
2 puertos seriales (hasta 230 Kbaudios). También provee disponibilidad para conexiones RS485.
●
Puerto Ethernet 10/100 Mb:
Con LED de actividad en el conector RJ45, que indica el estado actual de Ethernet. El LED de enlace (verde) se activa cuando el TS7200 se enciende y está conectado correctamente a una red Ethernet 10/100BaseT. El LED de actividad parpadea cuando hay actividad de red de entrada o salida. El LED de velocidad (ámbar) se enciende cuando se detecta una red de 100 Mb y se apaga si es de 10 Mb. Ambos LEDs son controlados por el KS8721 y no requieren supervisión del procesador. El Chip Ethernet PHY puede ser apagado por software para ahorrar 90 mA de consumo. Ésto se controla por el puerto H de salida del EP9302, bit 2. Un cero lógico apaga la interfaz del KS8721 PHY.
●
20 líneas de Entrada/Salida
●
Conector USB: El TS7200 provee dos interfaces USB para el usuario. Están directamente conectadas al procesador EP9302, que integra una interfaz de control de puerto USB dual­port (Open HCI). Esto provee comunicaciones seriales a una tasa de 12 Mb/s. Hasta 127 dispositivos USB pueden ser conectados en el USB con la topología tiered­star.
●
Conversor A/D de 5 canales:
Conversor Análogo/Digital de 12­bit con un multiplexor análogico y un intervalo de entrada de 0 a 3.3 V. En el TS7200 sólo se disponen los canales ADC0 y ADC4 en el Header DIO1.
●
Reloj Watchdog
●
Bus de expansión PC104
●
Interfaces para LCD alfanumérico y teclado de matriz.
●
Fuente de poder única de +5 VDC a 450 mA.
●
Tamaño de placa de 9,7 x 11,5 cm.
●
Intervalo de temperatura entre ­20° a +70° C.
●
Intervalo de temperatura extendido de ­40° a +85° C a bajas velocidades de reloj 25
de CPU (166 MHz)
2.5 ITS
ITS (Intelligent Transport Systems, Sistemas Inteligentes de Transporte) es un sistema de transporte comprometido con información avanzada y redes de telecomunicaciones para usuarios, caminos y vehículos. La IEEE define qué sociedades se enmarcan en este ámbito. La sociedad ITS (ITSS) desarrolla aspectos teóricos, experimentales y operacionales de las tecnologías aplicadas en los sistemas de transporte ITS. La ITSS implementa una lista de correo, conferencias a nivel mundial, publicación de papers y noticias. [19]
Existen muchas sociedades ITS en el mundo, en Chile existe la ITS­Chile, que es una corporación de derecho privado sin fines de lucro, dedicada a establecer puntos de encuentro y desarrollo de sistemas inteligentes de transporte.
ITS está compuesta de más de 16 tipos de tecnologías divididos en sistemas inteligentes de infraestructura y sistemas inteligentes de vehículos. Estos sistemas son:
●
Administración de vías principales.
●
Administración de autopistas.
●
Manejo de Tránsito.
●
Manejo de incidentes.
●
Manejo de emergencias.
●
Pagos electrónicos.
●
Información de viaje.
●
Administración de la información.
●
Prevención de accidentes y seguridad.
●
Mantención y operación de vías ferroviarias.
●
Supervisión de clima en caminos.
●
Operaciones de vehículos comerciales.
●
Enlaces intermodales.
En Chile, se utilizan sistemas de control de tránsito similares a los de Inglaterra, por lo tanto estándar de sistemas de control impulsado por el gobierno británico, UTMC, es factible de utilizar y permite un desarrollo sin incurrir en grandes costos. Esto se debe a que UTMC está pensado para utilizar sistemas de costo efectivo, medios flexibles para administrar el transporte en áreas urbanas y permitir lograr los objetivos de políticas de transporte definidos por la ITS. UTMC facilita la integración de sistemas de transporte, lo cual permite que la información esté disponible como una herramienta de administración y disponer de medios 26
para modificar el comportamiento de los usuarios.
2.6 Estándar UTMC 2.6.1 Introducción
UTMC (Urban Traffic Management & Control) es un programa lanzado en 1997, como iniciativa para el desarrollo abierto de Sistemas de Transporte Inteligentes (ITS) en áreas urbanas. Durante los primeros 3 años fueron establecidos un cierto número de proyectos de investigación, para establecer y validar una aproximación basada en sistemas modulares y estándares abiertos. Estos proyectos han contribuido a crear las especificaciones técnicas que definen el estándar UTMC. Fue creado por el departamento de Transporte de Gran Bretaña (DfT).
En Enero de 2001 el programa entró en una fase de pruebas para demostrar los resultados de la investigación inicial. Se implementaron planes pilotos en las ciudades Preston, Reading y Stratford­upon­Avon, UK. Un elemento clave en el programa UTMC es facilitar el desarrollo continuo del control de tránsito y la implementación de ésta estrategia de control, que es una de las tareas del grupo de Desarrollo de UTMC (UDG), compuesto por autoridades británicas del tránsito y empresas fabricantes de equipos. [20]
2.6.2 Características globales
El documento TS003:2005 [21] contiene las especificaciones generales para la capa de estándares (o framework) de UTMC homologado por la OMG (Object Management Group). En él, se especifican qué documentos deben consultarse y como se puede implementar un sistema bajo el estándar UTMC.
2.6.3 Arquitectura
El modelo de Referencia Lógica mostrado en la figura 6 describe un sistema UTMC como una serie de nodos interconectados. 27
Figura 6: Modelo de Referencia lógica para un sistema UTMC
Los Nodos UTMC se definen como:
●
Nodo A: Puertas de enlace fijas a sistemas externos, incluyendo otros sistemas UTMC.
●
Nodo B: Centros de administración UTMC.
●
Nodo C: Estaciones de exterior UTMC.
●
Nodo D: Unidades controladas UTMC.
●
Nodo E: Unidades móviles.
Basados en este modelo, las especificaciones y las restricciones se aplican a los nodos indicados en el documento TS004:2005 [22], donde se describen las interconexiones para configurar un sistema UTMC que controle el flujo de tránsito.
Se debe especificar siguiendo la norma UTMC los siguientes aspectos del sistema:
●
Interfaz Hombre­Máquina
28
Con Interfaz de Usuario y Servicios de Administración de Sistema.
●
Estándares de Niveles de Información:
Donde es importante recalcar que los Objetos de Datos y sus procesos de intercambio deben ser descritos en un lenguaje de especificación estándar adecuado.
●
Estándar de nivel de aplicación: Intercambio de datos genéricos, intercambio específico de datos UTMC, Interfaz de Aplicación e Interfaces de Aplicación de Servicios.
●
Estándar de nivel de Transporte: Protocolos de comunicación (IP,UDP,TCP) e “implementación típica” de uso de UDP/IP.
●
Estándar de Sub­Redes y niveles de planta: Uso de tecnología inalámbrica.
●
Seguridad y Prevención de Accidentes.
2.6.4 Cumplimiento de norma UTMC
2.6.4.1 Cumplimiento de Interfaz
La intención primaria de la especificación técnica de UTMC es facilitar la interoperabilidad de módulos en un sistema de control de Tránsito. Al respecto se estipula: ●
Una interfaz específica en un sistema de control de Tránsito es una “interfaz en norma UTMC”, si todas las comunicaciones a través de ella son conducidas usando los estándares técnicos de TS003:2005 secciones 4­8, transportando sólo objetos registrados UTMC listados en TS004.
●
Una interfaz es “Interfaz en norma UTMC extendida”, si utiliza estándares técnicos de TS003 y los datos que transporta están estructurados como objetos de datos UTMC, donde quiera que estén disponibles. 2.6.4.2 Cumplimiento de Productos y Sistemas UTMC
Los productos deben tener interfaces para las comunicaciones y para la interconexión entre los sistemas. Un Sistema de Control de Tránsito es construido sobre la base de un número de productos configurados para el problema particular del tránsito de una ciudad. No siempre será necesario o eficiente cumplir con UTMC para satisfacer los objetivos primarios o facilitar interoperabilidad. Por lo tanto, un producto o Sistema no requiere estrictamente cumplir con la norma UTMC y en ocasiones se implementa el Sistema con productos que no siguen esta norma.
Sin embargo, es recomendable que los proveedores y los administradores de tránsito valoren el hecho que los productos y sistemas cumplan las especificaciones UTMC y ser reconocidos 29
bajo esta norma. 2.6.4.3 Cumplimiento de Estatuto y Legales
Todos los sistemas UTMC, sus componentes y aplicaciones deben cumplir con todos los requerimientos de Estatuto y Legales de Gran Bretaña y Estados Unidos.
2.6.4.4 Certificación de Sistema
Los sistemas UTMC pueden ser conformes a los requerimientos del Procedimiento de Certificación de Sistemas como se define en la norma TA8406 [23].
2.6.4.5 Decisiones de Cumplimiento y Consecución
Las especificaciones de UTMC son solo una guía, las cuales documentan un acercamiento técnico consensuado para Sistemas de Control de Tránsito modulares. Las decisiones de consecución deben definirse para ser realizadas acorde a las regulaciones planteadas. 2.6.4.6 Actividades de desarrollo
La siguiente es una lista actualizada de actividades de desarrollo que han sido generadas por UTMC, de las cuales se han producido documentos aprobados y de libre acceso: ●
Prioridad de vehículo actuado: Consiste en definir qué tipos de vehículos tienen prioridad y cómo puede otorgarlas. Existe prioridad de buses colectivos y vehículos de emergencia. Hay distintos mecanismos para detectar y otorgar prioridad a un vehículo en particular. [24]
●
Manejo de tránsito a través de límites de jurisdicción: Para resolver los problemas de patrones de tránsito y los problemas de transporte se debe considerar los límites de jurisdicción y las complicaciones institucionales que pueden ocurrir en su implementación. El manejo responsable y efectivo requiere soluciones integrales, quizás a través de varias jurisdicciones diferentes. En este marco se intenta definir una arquitectura común a los componentes de la interfaz de sistema externa UTMC, Nodo A y Nodo B, los cuales deben soportar la administración de tránsito avanzada, control y estrategias de información. [25]
●
Estrategias para minimizar emisiones de vehículos: Considera el desarrollo de sensores y estrategias para detectar las emisiones contaminantes de vehículos. ●
Monitoreo, modelamiento y manejo de redes: Comparación de diferentes topologías, análisis de los medios de comunicación y estudio de protocolos de telecomunicaciones. ●
Criterios de funcionamiento de Sistemas UTMC: 30
Evaluación de implementaciones piloto y métodos para evaluar el funcionamiento de un sistema UTMC.
●
Contenido y calidad de datos de Entrada/Salida: Un sistema UTMC consiste en varios sub­sistemas o componentes, cada uno realizando una parte de la función de control y administración. Uno de los requisitos del concepto UTMC es que estos componentes deben ser modulares en su diseño, para lograr sistemas genuinamente abiertos, que satisfagan estándares internacionales. Los datos son el “pegamento” que asegura que diferentes sistemas UTMC cumplan este requisito. Con el acuerdo de qué datos son usados en estos sistemas y qué datos son intercambiados entre ellos, se facilita una aproximación “plug and play”. Si los sistemas UTMC pueden comunicarse en el mismo lenguaje, los diseñadores de sistema y agencias deben asegurar interoperabilidad entre sistemas de diferentes fabricantes. [20]
●
Conveniencia de comunicaciones basadas en NTCIP: ver punto 2.6.3.
●
Conveniencia de aplicaciones de mensajería de NTCIP: ver punto 2.6.3.
Además de estas actividades existen otras, como obtención de integración UTMC usando Common Database, comunicaciones inalámbricas entre usuarios de vías y UTMC, modelo de costo propietario, entre otros.
2.6.5 NTCIP
NTCIP (National Transportation Communications for ITS Protocol) es una familia de estándares que define protocolos, perfiles abiertos y estándares de comunicación basados en consenso. NTCIP fue creado por la NEMA (Asociación de Comercio para la Elección de Productos Eléctricos para la Industria) en Estados Unidos en 1992. Otras instituciones se unieron al desarrollo de NTCIP y se convirtió en el estándar oficial de Estados Unidos para la elección de protocolos de comunicación en sistemas de Control de Tránsito.
Cuando es usado para el control de caminos y otros dispositivos de administración de transporte, NTCIP puede ayudar en la interoperabilidad e intercambiabilidad de equipos. La familia de estándares NTCIP está pensada para usarse en todo tipo de sistemas administrados de transporte, incluyendo autopistas, señales y control de tránsito, manejo de emergencias, información de viaje y adquisición de datos. NTCIP es implementado para comunicaciones por cable o inalámbrica entre los equipos.
NTCIP utiliza una aproximación en capas o modular para los estándares de comunicación, similar al modelo OSI de ISO. En general las comunicaciones de datos entre dispositivos puede ser considerada en los siguientes niveles en NTCIP:
●
Nivel de planta: Consiste en el medio físico de transmisión, por ejemplo: cable de cobre, coaxial, fibra óptica 31
o inalámbrica.
●
Nivel de Subred: Contiene estándares para la interfaz física, por ejemplo: módem, interfaz de red, CSU/DSU y el método de transmisión de paquetes.
●
Nivel de Transporte: Contiene estándares para la subdivisión de paquetes de datos, re­ensamblaje de paquetes y enrutamiento. Por ejemplo: TCP, UDP, IP.
●
Nivel de Aplicación: Contiene estándares para la estructura de paquetes de datos y manejo de sesiones. Por ejemplo: SNMP, STMP, DATEX­ASN, CORBA, FTP.
●
Nivel de Información: Contiene estándares de los elementos de datos, objetos y mensajes a ser transmitidos. Por ejemplo: TCP/IP, NTCIP 1200, MS/ETMCC.
En la figura 7 se presenta la arquitectura de estándares de NTCIP.
Figura 7: Estándares de NTCIP
32
NTCIP cumple los requerimientos de control de tránsito existentes. Provee comunicaciones de administración de transporte y se acomoda a futuros desarrollos en tecnología de información y comunicaciones. Ésto lo convierte en una planta adecuada para UTMC, por lo que NTCIP es usado como la base de protocolos de comunicación en UTMC. En NTCIP, cada dispositivo es definido con su propia declaración de objeto y todos los fabricantes deben satisfacer los elementos obligatorios de esta especificación. Por ser un estándar norteamericano, para ser utilizado en UTMC, varios aspectos de NTCIP necesitan ser modificados para adecuarse al ambiente británico. Las diferencias radican en la colecciones de protocolos más que los protocolos en sí mismos. A nivel de dispositivos, también existen diferencias en los detalles de sus definiciones. [26]
2.6.6 Implementaciones Piloto
En diciembre de 2000 cuatro ciudades fueron escogidas por el DfT para implementar pilotos a escala real basados en el estándar UTMC. Estos fueron Preston, Reading, Stratford­upon­
avon y York. La fase de demostración dio la oportunidad de consolidar los resultados del desarrollo previo. A continuación se describen estas implementaciones piloto.
●
Preston
El Condado de Lancashire desarrolló una estrategia ITS para el área metropolitana de Preston, basada en la filosofía trazada en los programas pioneros de implementación de sistemas ITS. Ésta es definida en un establecimiento de visión y plan de despliegue de ITS, los cuales forman la base del plan piloto de Preston. El documento UTMC29 Preston provee el esqueleto para una ambiciosa visión de transporte controlado, conocida como la TTN (Total Transport Network).
En el informe de evaluación se detallan los beneficios que se han encontrado durante la implementación y puesta en marcha de UTMC en el área metropolitana de Preston.
●
Reading
El proyecto de plan piloto UTMC29 de Reading se enfoca en el Corredor Sur (con un desarrollo de alta tecnología) y en el área de intercambio de transporte del centro. El objetivo principal del plan es influenciar la manera y puntualidad del viaje, ayudando a hacer mejor uso de la infraestructura de transporte público. Para lograrlo, es fundamental la entrega precisa de información en tiempo real a los usuarios cómo y cuándo sea más apropiado.
●
Stratford­upon­Avon
El sistema de manejo de tránsito de Stratford­upon­Avon ha sido ideado para asegurar que la red de autopistas en la ciudad pueda ser controlada, para tratar con fluctuaciones importantes de tránsito e incidentes. También permite estrategias de transporte local y esquemas favorables para el medio ambiente. El proyecto de Stratford­upon­Avon UTMC29 usa sistemas VMS, UTC, sensores de ocupación de estacionamientos de autos y 33
mediciones de tiempos de viaje. Para ello, utiliza tecnología de reconocimiento automático de patentes para manejar flujos de tránsito y enrutamiento, mejorar la utilización de estacionamientos y dar prioridad a buses.
●
York
El proyecto UTMC29 de York es la primera fase de implementación del sistema de congestión de tránsito de la ciudad de York (TCMS). Fue implementado durante un período de 5 años para cubrir toda la ciudad. TCMS apuntó a proveer soluciones sostenibles de transporte junto a herramientas para supervisar la calidad del aire, reducción de la contaminación, avisos dinámicos de mensajería en la ruta, administración y control de tránsito y promover además áreas verdes y de recreación. UTMC fue vital para esta primera fase y proporcionó una plataforma para el resto del sistema, que se construirá más adelante. Cada demostración provee un reporte de evaluación, un reporte de “lecciones aprendidas” y un caso de negocios, que se encuentran disponibles en Internet [27].
2.7 SNMP
2.7.1 Introducción
El protocolo de gestión de red simple o SNMP (Simple Network Management Protocol) es un protocolo de la capa de aplicación, que facilita el intercambio de información de gestión entre dispositivos de red. Este protocolo es parte del conjunto de protocolos TCP/IP (Transmission Control Protocol/Internet Protocol). SNMP permite a los administradores gestionar el rendimiento, encontrar y solucionar problemas y planificar el crecimiento futuro de la red. Si bien SNMP se diseñó, en un principio, con el propósito de supervisar en forma sencilla y resolver problemas en routers y bridges, con su ampliación este protocolo es utilizado para supervisar y controlar routers, switches, bridges, hubs, servidores y estaciones Windows y Unix, servidores de terminal, etc. El protocolo SNMP opera sobre varios protocolos de transporte, habitualmente sobre UDP (User Datagram Protocol), aunque actualmente también soporta OSI CLNS (ConnectionLess Network Service), AppleTalk DDP (Datagram­Delivery Protocol) y Novell IPX (Internet Packet Exchange). [28]
2.7.2 Componentes básicos de SNMP Los componentes básicos de una red gestionada con SNMP son: los agentes (componentes de software que se ejecutan en los dispositivos a gestionar) y los gestores (componentes de software que se ejecutan en los sistemas de gestión de red). Un equipo puede operar exclusivamente como gestor o agente, o bien puede desempeñar simultáneamente ambas 34
funciones. Por consiguiente, el protocolo SNMP tiene una arquitectura cliente/servidor distribuida, como se ilustra en la figura 8. Figura 8: Arquitectura SNMP
La parte servidora de SNMP consiste en un software gestor. Es responsable del sondeo de los agentes para la obtención de información específica y del envío de peticiones a dichos agentes, solicitando la modificación de un determinado valor relativo a su configuración. Es decir, son los elementos del sistema ubicados en la plataforma de gestión centralizada de red, que interaccionan con los operadores, desencadenando las acciones necesarias para llevar a cabo las tareas invocadas o programadas por ellos.
La parte cliente de SNMP consiste en un software agente y una base de datos con información de gestión o MIB (Management Information Base). Los agentes SNMP reciben peticiones y reportan información a los gestores para la comunidad a la que pertenecen. Una comunidad es un dominio administrativo de agentes y gestores SNMP, es decir, define qué elementos del sistema ubicados en cada uno de los dispositivos a administrar pueden ser invocados por un gestor de la red específico. El principio de funcionamiento reside, por consiguiente, en el intercambio de información de administración entre nodos gestores y nodos gestionados. Habitualmente, los agentes mantienen en cada dispositivo gestionado información acerca de su estado y su configuración. El gestor pide al agente, a través del protocolo SNMP, que realice determinadas operaciones 35
con esta información de administración, gracias a las cuales podrá conocer el estado del recurso y podrá influir en su comportamiento. Cuando se produce alguna situación anómala en un recurso gestionado, los agentes, sin necesidad de ser invocados por el gestor, emiten los denominados eventos o notificaciones que son enviados a un gestor para que el sistema pueda actuar en consecuencia. El gestor SNMP puede ejecutar cualquiera de estos tres comandos sobre un agente SNMP: ●
Get
Es una petición del valor específico de un objeto en la MIB de un agente. Este comando es utilizado por el gestor para monitorizar los dispositivos gestionados. ●
Get­Next
Es una petición del valor en el siguiente objeto en la MIB de un agente. Este comando es utilizado para obtener cada valor sucesivo en un subconjunto o rama de la MIB (se denomina recorrer el conjunto de objetos o árbol de la MIB). ●
Set
Es utilizado para cambiar el valor de un objeto en la MIB de un agente, en caso que el objeto tenga habilitada la lectura y escritura de su valor. Este comando es utilizado por el gestor para administrar los dispositivos gestionados. Por otro lado, un agente SNMP podría también mandar un mensaje a un gestor SNMP sin el envío previo de una solicitud por parte de éste. Este tipo de mensaje es conocido como Trap o notificación. Las notificaciones son generalmente enviadas para reportar eventos, por ejemplo una falla repentina de un dispositivo.
El protocolo SNMP debe tener en cuenta posibles incompatibilidades entre los dispositivos a gestionar y permitir ajustarlas. Cada equipo utiliza distintas técnicas de representación de los datos, lo cual puede comprometer la habilidad de SNMP para intercambiar información entre los dispositivos a gestionar. Para evitar este problema, SNMP utiliza un subconjunto de ASN.1 (Abstract Syntax Notation One) en la comunicación entre los diversos sistemas. [29]
En su versión original, cada gestor y agente son configurados con un nombre de comunidad, que es una cadena de texto plano. Los nombres de comunidad, enviados junto a cada comando lanzado por el gestor, sirven como un débil mecanismo de autentificación; puesto que el mensaje no está cifrado, es muy sencillo que un intruso determine cual es dicho nombre capturando los mensajes enviados a través de la red. Cuando un agente SNMP captura una petición, comprueba que la petición entrante es para la comunidad a la cual pertenece. Si el agente pertenece a dicha comunidad, consulta en la MIB el valor del objeto solicitado. Luego envía una respuesta al gestor SNMP con dicho valor en el caso de un comando Get, o bien cambia el valor en el caso de un comando Set.
36
Una MIB (Management Information Base) es una base de datos jerárquica de objetos y sus valores, almacenados en un agente SNMP. En la figura 9 se ilustra la estructura en árbol de la MIB. Figura 9: Estructura de Árbol de la MIB
Cada MIB individual es un sub­árbol de la estructura total de MIB definida por la ISO. La RFC 1156, llamada MIB­I, especifica ciertas informaciones de primer nivel. La RFC 1158, llamada MIB­II, es más exhaustiva. Sin embargo, como estas especificaciones no permiten describir con la precisión requerida todo tipo de agentes, los fabricantes de hardware y programadores de software están desarrollando MIB propietarias. De esta forma, una organización puede tener autoridad sobre los objetos y ramas de una MIB. Generalmente, los objetos de la MIB son referenciados por un identificador. Por ejemplo, el objeto Internet, corresponde al identificador 1.3.6.1, o bien iso.org.dod.internet.
2.7.3 Estructura de mensaje SNMP de UTMC
UTMC define la estructura de SNMP que debe ser utilizada en un sistema de control de tránsito. Cada elemento de un mensaje SNMP puede ser expresado por un tipo de “Secuencia”, “Entero”, “Cadena de Octetos” o “Idenfificador de Objeto”. Estos tipos indican el significado del valor del componente. Un mensaje SNMP consiste en dos campos predefinidos más una Unidad de Datos de Protocolo (PDU), definido en secuencia. En la PDU hay un identificador de petición, un estatus de error y un índice de error, seguido por el contenido del mensaje. El mensaje puede consistir en uno o varios objetos.
La estructura de mensaje SNMP añade 23 bytes por objeto más 26 bytes por mensaje. La 37
cabecera UDP añade 8 bytes al mensaje, y la cabecera IP añade 20 bytes al mensaje. Un protocolos de menor nivel, como Ethernet, añadirá 26 bytes más.
El Registro de Objetos UTMC, definido en TS004, mantiene y publica una lista de los objetos UTMC junto a su estatus. Éste se utiliza para formar las bases de cualquier mensaje SNMP bajo UTMC.
SNMP utiliza el concepto de objetos para la comunicación, usando un modelo Get/Set para leer o asignar el estado de un objeto. Los MIBs para uso en sistemas UTMC son descritos en TS004 Anexo E [22]. Estos MIBs estandarizados deben ser utilizados donde sea factible para administrar los datos traspasados bajo SNMP en un sistema UTMC. La siguiente es la lista de MIBs definidos:
●
UTMC Header MIB: Archivo de cabecera con definiciones globales.
●
Air quality monitor MIB: Para dispositivos sensores de calidad del aire.
●
VMS MIB: Para letreros de mensajes variables.
●
Simple UTC MIB: Definiciones para controladores de semáforos simples.
●
UTC MIB: Definiciones para controladores de semáforos.
●
Car Park Monitor MIB: Para monitores de estacionamientos de vehiculos.
●
Traffic Counter MIB: Para dispositivos contadores de vehículos.
La raíz (definida en el UTMC­Header­MIB) se coloca en la siguiente rama del árbol MIB:
.1.3.6.1.4.1.13267 (iso.org.dod.internet.private.enterprises.utmc)
2.8 GNU, Linux y el software libre
El proyecto GNU fue iniciado por Richard Stallman en 1983, con el objetivo de crear un sistema operativo completamente libre. GNU es un acrónimo recursivo que significa “GNU no es Unix”. El manifiesto GNU establece motivaciones para realizar este proyecto, entre las que destaca "volver al espíritu de cooperación que prevaleció en los tiempos iniciales de la comunidad de usuarios de computadoras".
La colección GNU incluye compiladores para C, C++, Objective C, Fortran, JAVA y ADA, así como bibliotecas para estos lenguajes de programación.
GNU no sólo agrupa implementaciones de software, también posee un tipo de licencia llamado “software libre” (GNU Public Licence o GPL). En GPL la definición de libertad no es de precio, sino de libertad de los usuarios para ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software. Se especifican cuatro libertades:
●
La libertad de usar el programa, con cualquier propósito (libertad 0). ●
La libertad de estudiar el funcionamiento del programa, y adaptarlo a las 38
necesidades (libertad 1). El acceso al código fuente es una condición previa para esto. ●
La libertad de distribuir copias, entregando la posibilidad de ayudar a otros programadores (libertad 2). ●
La libertad de mejorar el programa y hacer públicas las mejoras, de modo que toda la comunidad se beneficie (libertad 3). De igual forma que la libertad 1 el acceso al código fuente es un requisito previo. El proyecto GNU está patrocinado por la Fundación para el Software Libre (FSF). [30]
POSIX es el acrónimo de Portable Operating System Interface, y la X viene de Unix. El término fue sugerido por Richard Stallman. El estándar POSIX está especificado por la IEEE 1003 y permite generalizar las interfaces de los sistemas operativos, para que una misma aplicación pueda ejecutarse en distintas plataformas. POSIX especifica las interfaces de usuario y el software de Sistema Operativo. La línea de comandos estándar y las interfaces de scripting se basaron en la aplicación Korn Shell. Entre otros programas definidos a nivel de usuario, se incluye ls, awk, echo, ed, vi, sed, y un largo etcétera. POSIX se divide en tres partes [31]: ●
POSIX.1: Servicios de Núcleo: Implementa las llamadas del estándar ANSI C.
●
POSIX.1b: Extensiones para tiempo real.
●
POSIX.1c: Extensiones para hilos (threads). En 1991, Linus Torvalds comenzó a escribir el núcleo Linux a modo de hobbie y decidió distribuirlo bajo la licencia GPL. Linus tenía como referencia Minix, un pequeño sistema Unix. En 1992, el núcleo Linux fue combinado con el sistema GNU, resultando un sistema operativo libre y completamente funcional. Linus trabajó continuamente hasta que sacó la versión 1.0 en 1994. El Kernel, al estar distribuido bajo GPL, está disponible en forma de código fuente de manera gratuita. Rápidamente, múltiples programadores se unieron a Linus en el desarrollo, colaborando a través de Internet y consiguiendo paulatinamente que Linux llegase a ser un núcleo compatible con POSIX (portátil, multiusuario y multitarea).
La robustez, adaptabilidad y funcionalidad de Linux lo ha convertido en la principal alternativa frente a sistemas Unix propietarios o Microsoft Windows. Aunque ha sido adaptado globalmente como plataforma de servidores, su uso para el hogar y oficina está en ascenso. Linux puede ser incorporado además directamente en sistemas embebidos y está siendo cada vez más usado en ellos. [32]
La forma natural y estándar de interactuar con Linux (o cualquier sistema Unix) es usando la línea de comandos, también conocida como consola o shell. La versión más común, presente en casi todos los sistemas Linux, es la Bash o “Bourne Again Shell”, diseñada por GNU. En la figura 10 se muestra una vista típica de esta interfaz:
39
Figura 10: Shell de Unix
Se pueden ejecutar comandos Unix en esta interfaz para modificar cualquier parte del sistema. Como medida de seguridad se definen jerarquías de permisos para distintos usuarios y grupos de usuarios. Siempre existe un usuario que tiene control total sobre el sistema y se le denomina superusuario o root.
El sistema de archivos está organizado como un árbol de directorios, siendo el directorio raíz (/) la base del árbol y donde se adhieren todos los demás archivos y directorios, independientemente de su origen físico o lógico. Entre los directorios principales se encuentran los siguientes (los nombres son sólo una guía, adoptados por común acuerdo. No está especificado por norma que así deban llamarse):
●
●
●
●
●
●
●
●
●
●
●
●
/boot: Contiene información de arranque del sistema.
/dev: Aquí se encuentran archivos asociados a los dispositivos del sistema, unidades de disco, dispositivos de audio, red, unidades extraíbles, puertos comunicaciones, etc.
/home: Aquí se encuentran los archivos personales de cada usuario del sistema.
/media: también llamado /mnt en muchos sistemas, es donde se montan los dispositivos externos.3
/bin: aquí se encuentran los programas ejecutables básicos del sistema definidos por POSIX.
/etc: aquí se definen las configuraciones del sistema. Muchos archivos de configuración pueden ser leídos y manipulados con editores de texto por el usuario.
/lib: aquí se incluyen las bibliotecas utilizadas por los lenguajes de programación que existan en el sistema.
/opt: se ubican programas de terceros, ya sea licenciados o alternativas a los programas usuales.
/proc: Es un sistema de archivos virtual utilizado para interactuar con el Kernel. /root: directorio home del superusuario.
/sbin: Programas utilizados por el sistema, generalmente solo el root puede ejecutarlos. Por ejemplo mount y shutdown.
/tmp: Directorio donde se ubican archivos temporales del sistema.
3 El montaje es un procedimiento que realiza el sistema para poder utilizar el dispositivo. En Linux se realiza con el comando “mount”.
40
●
●
/usr: Contiene bibliotecas, documentación e información de los programas de usuario.
/var: contiene información variable del sistema, archivos de log (notificaciones) e información de correo.
2.8.1 Distribuciones de Linux
Una distribución de Linux es una versión del sistema operativo construida especialmente por una compañía, organización o individuo. Lo único que tienen en común es que utilizan el Kernel de Linux. Desde ese punto, cada desarrollador añade programas, herramientas y otras aplicaciones. Algunas distribuciones están dedicadas a usos específicos mientras otras están pensadas para el público masivo. En general se pueden clasificar por idioma, arquitectura de microprocesador en la que están implementadas (x86, 64 bits, ARM, etc.) o por su objetivo (escritorio, servidores, sistemas embebidos, minimalista, LIVE CD, routers y minimalistas). Existen demasiadas distribuciones para enumerarlas, por lo que aquí sólo se muestran las principales:
●
Debian GNU/Linux:
Distribución libre mantenida y actualizada por el trabajo de un gran número de voluntarios. Contiene una gran selección de programas pre­empaquetados, entre los que existen herramientas que permiten una instalación fácil en sistemas individuales o sistemas distribuidos en clusters. ●
Gentoo Linux:
Está diseñada para el desarrollador, usuario avanzado o entusiastas. Incorpora los últimos archivos fuentes y tecnologías, tal como el sistema de archivos ReiserFS.
●
Mandriva:
Poderoso sistema operativo disponible para múltiples plataformas. Incluye administración gráfica y wizards que hacen intuitiva su utilización. ●
RedHat:
Distribución pagada de Linux, pensada para negocios y necesidades de requerimientos críticos de sistemas. ●
Slackware Linux:
Distribución compatible con casi todo el hardware para sistemas tipo Intel­PC. Provee alto rendimiento y soporte para multiprocesadores, PCI y optimizaciones especiales de código para Pentium y AMD Athlon.
●
SUSE Linux:
Basada en Slackware, es una de las distribuciones más conocidas a nivel mundial. Es una de las más sencillas de instalar y administrar.
●
Fedora:
41
Distribución libre y de propósito general, desarrollada por RedHat. Fue creada para reemplazar versiones de bajo costo y consumo de RedHat Linux.
●
Knoppix:
Está pensada para iniciar desde un CD sin necesidad de instalación en el disco duro (LiveCD). Es ideal para demostraciones o para recuperación del sistema ante fallas.
●
Ubuntu:
Ideada por Canonical Ltd., es una distribución basada en Debian desarrollada por una comunidad de usuarios y cuyo objetivo son laptops, PCs de escritorio y servidores. La distribución Ubuntu, en su versión actual 8.04 (Hardy­Heron) es un completo sistema operativo libre creado alrededor del núcleo Linux. La comunidad de Ubuntu gira alrededor de las ideas expresadas en la Filosofía Ubuntu: que el software debe estar disponible de forma gratuita, que las herramientas de software deben poder ser utilizadas por la gente en su idioma local y que la gente debe tener la libertad de personalizar y alterar su software de la manera que necesiten. Ubuntu entrega el software libre de GNU y aquellos que cumplan con la licencia GPL.
2.9 Descripción del trabajo específico de esta memoria
2.9.1 Metodología
Primero se debe obtener un esquema del sistema donde será utilizada la interfaz a desarrollar. Este esquema debe ser congruente con la arquitectura de sistemas de control de tránsito de UTMC, expuesta en la figura 6.
En el diagrama, los VMS corresponden a equipos de nodo D y la interfaz implementada corresponde a un nodo C, la cual se comunica con los servidores o sistemas de estación interna, ubicados en la sala de control del sistema (nodos B).
Para que la interfaz pueda encontrarse en el exterior, es necesario contar con hardware que pueda cumplir con este requisito. Un sistema embebido, como los descritos en el punto 2.4, satisfacen esta necesidad. Existe también la posibilidad de utilizar un PC industrial, con características similares a un equipo de estación interna (arquitectura IBM compatible), pero por sus altos costos se descartó esta opción en el diseño.
UTMC requiere la elección de protocolos de comunicación entre los dispositivos del sistema. Para ello se observa en la figura 7, que los protocolos preferidos para la comunicación del centro de control a terreno están hacia el lado derecho.
Considerando las características del sistema embebido escogido, por sus salidas y puertos disponibles, se escogen los protocolos de menor nivel a utilizar. A nivel de planta, se utiliza par cruzado. Para el nivel de Sub­red de utiliza Ethernet. En el nivel de Transporte se escoge UDP bajo IP.
42
Finalmente, en el nivel de Aplicación se escogerá SNMP, por las necesidades de administración de los datos de un sistema VMS. Además, como se vio en el punto 2.7.3, UTMC especifica la estructura de datos de VMS, la cual se incorporará en el procesamiento del sistema embebido.
Para realizar la implementación de software, se definen los entornos de programación, bibliotecas y herramientas de compilación. Se escogen además las entradas que obtendrá la interfaz desde el sistema UTMC y las salidas hacia los letreros VMS.
Es necesario obtener una salida por el lado del servidor, que permita observar y evaluar el comportamiento de la interfaz, para definir si el resultado satisface o no los requerimientos establecidos por los objetivos de la memoria. Se escogió una visualización bajo un webserver que permita observar y controlar la interfaz vía HTML para ser vista en un navegador estándar. Esto otorga varias ventajas:
●
Puede ser utilizado por cualquier sistema operativo, con el requisito que esté conectado en red con el sistema y posea un navegador HTML estándar.
●
No es necesario programar un software especializado para el despliegue y control de la información.
●
La tendencia actual de la tecnología es utilizar este tipo de interfaz por las ventajas anteriormente mencionadas. Existen varias herramientas de software y lenguajes de programación de código abierto especializados en implementar ésto, como PHP.
2.9.2 Diseño del sistema
En la figura 11 se muestra un esquema del sistema que se implementará en este trabajo, para Letreros de Mensajería Variable.
43
Figura 11: Esquema general de la implementación de la interfaz UTMC para VMS
Los requisitos para escoger el software a utilizar son los siguientes:
●
Deben permitir cumplir las especificaciones de UTMC. ●
De preferencia y donde sea factible, utilizar software de código abierto. UTMC fue desarrollado para promover sistemas abiertos e interoperabilidad de otros componentes con sistemas UTMC.
●
Utilizar software con la mayor cantidad de documentación. Es preferible aquellos programas que sean mencionados en foros y que cuenten con listas de correos activas para realizar consultas.
●
Utilizar software de menor tamaño posible para el caso del cliente SNMP. Esto no debe impedir cumplir con los requisitos anteriores.
Considerando todos esto se definen los aspectos a implementar en el servidor y en el cliente (interfaz).
2.9.3 Servidor UTMC: Se realizará una simulación de un servidor UTMC. Por lo tanto, es requisito tener capacidades de red adecuadas para utilizar los protocolos de NTCIP. Ésto sumado al enfoque UTMC de utilizar sistemas abiertos, conduce rápidamente a ocupar un entorno Linux. El servidor genera 44
mensajes de petición y configuración de datos bajo el protocolo SNMP. Para este propósito, se implementa un webserver en Apache mediante el cual se puede leer el estado del cliente y las salidas que se generan hacia el VMS controlado.
2.9.3.1 Apache
El servidor HTTP Apache es un servidor HTTP de código abierto para plataformas Unix, Windows, Macintosh y otras. Apache implementa el protocolo HTTP/1.1 y la noción de sitio virtual. Cuando comenzó su desarrollo en 1995, se basó inicialmente en código del popular NCSA HTTPd 1.3, pero más tarde fue reescrito por completo. Su nombre fue escogido con el objeto de entregar la connotación de algo firme y enérgico, pero no agresivo. La tribu Apache fue la última en rendirse al que pronto se convertiría en gobierno de Estados Unidos. Para sus creadores la preocupación era que llegasen las empresas y "civilizasen" el paisaje que habían creado los primeros ingenieros de internet. Además, Apache consistía solamente en un conjunto de correcciones (parches) a aplicar al servidor de NCSA. Era, dicho en inglés, a patchy server (un servidor "emparchado").
El servidor Apache se desarrolla dentro del proyecto HTTP Server (httpd) de la Apache Software Foundation.
Apache presenta entre otras características: mensajes de error altamente configurables, bases de datos de autenticación y negociación de contenido, pero fue criticado por la falta de una interfaz gráfica que ayude en su configuración.
2.9.4 Cliente UTMC
El cliente UTMC será un dispositivo capaz de interactuar vía SNMP con el servidor, utilizando un software SNMP para Linux. Debe recibir las peticiones del servidor y procesarlas para manejar un letrero de mensaje variable (VMS). Se utilizará un PC embebido (SBC) con Linux, el TS7200, con una distribución Debian. Para procesar las peticiones del servidor, se programará el sistema embebido con un servidor SNMP que reciba las instrucciones y permita obtener los datos para ser transmitidos hacia un VMS. El programa debe estar ejecutándose continuamente y debe traducir las instrucciones de UTMC hacia el protocolo específico del Letrero VMS.
2.9.4.1 NET­SNMP
Net­SNMP es un paquete de software de código abierto realizado por usuarios alrededor de la red. Está originalmente basado en el código SNMP CMU 2.1.2.1. En 1995 fue renombrado de cmu­snmp a ucd­snmp y luego de ucd­snmp a net­snmp en el 2000. [33]
Entre las aplicaciones se incluye:
●
Comandos para recibir información y enviar peticiones de SNMP (snmpget, snmpgetnext, snmpwalk, snmptable y snmpdelta).
45
●
Recibir colecciones fijas de información de un dispositivo SNMP (snmpdf, snmpnetstat, snmpstatus).
●
Convertir entre formas numéricas y textuales de OIDs y desplegar el contenido del árbol MIB (snmptranslate).
●
Un browser MIB gráfico basado en Tk/Perl (tkmib) .
●
Una aplicación demonio para recibir notificaciones SNMP (snmptrapd). Las notificaciones seleccionadas pueden ser archivadas, enviadas a otro administrador SNMP o pasadas a una aplicación externa.
●
Un agente extensible para responder a peticiones SNMP para administración de la información (snmpd). Éste incluye soporte por defecto para un amplio intervalo de módulos de información MIB y puede ser extendido usando módulos cargados dinámicamente: por medio de scripts y comandos externos, a través de los protocolos de multiplexación de SNMP (SMUX) o la extensibilidad del agente (AgentX).
●
Una biblioteca para desarrollar nuevas aplicaciones SNMP con APIs4 para C y Perl. 2.9.4.2 Generando código a partir del MIB
Para generar código del cliente SNMP, se utiliza la aplicación mib2c con un archivo de configuración llamado mib2c.mfd.conf y se usa con el argumento ­c. De esta manera, se produce un formato simple de código. Además, el código generado está diseñado para conectarse a un agente SNMP.
MFD (MIB For Dummies, de ahora en adelante el nombre para designar mib2c con la configuración mib2c.mfd.conf) genera un código plantilla que se utiliza para la implementación deseada. Esconde detalles específicos de SNMP para crear un módulo y permite al resto de la plantilla usar simples estructuras de C. La mayoría de las funciones de la plantilla son cortas y simples, con un claro propósito definido.
Otra motivación, es separar el método usado para localizar los datos de los métodos para manipularlos. Los módulos MFD realizan la búsqueda utilizando la interfaz netsnmp_container. Las plantillas generadas por MFD se agrupan en 3 categorías: estructuras de datos, búsqueda de datos y manipulación de datos. Las estructuras contienen los datos utilizados para responder una petición, los buscadores de datos encuentran los datos correctos para la petición y la manipulación de datos devuelve valores existentes o configura nuevos valores.
4 API: (del inglés Application Programming Interface ­ Interfaz de Programación de Aplicaciones) es el conjunto de funciones y procedimientos que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción.
46
2.9.4.3 Estructuras de Datos.
Hay 4 estructuras de datos importantes usadas en un módulo MFD. Estas son: contexto de usuario, contexto de MIB, contexto de datos y el contexto de petición de fila.
●
Contexto de usuario
Es un puntero provisto por el usuario durante la inicialización del módulo. No es utilizado por el código MFD excepto para ser almacenarlo para el usuario. Si el módulo necesita acceso a un dato externo, se puede usar este puntero en vez de una variable global.
●
Contexto de MIB
El contexto MIB es una estructura utilizada para almacenar los índices del MIB en una fila.
●
Contexto de datos
Ésta estructura debe contener todo los datos necesarios para asignar u obtener un valor. El archivo de configuración de MFD generará una estructura de contexto de datos, con espacio suficiente para todos los objetos definidos en el MIB.
●
Contexto de petición de fila
Conecta todos los contextos anteriores. El contenedor de tabla tendrá un contexto de petición de fila por cada fila en la tabla.
2.9.4.4 Búsqueda de Datos
Hay diferentes formas de acceder a los datos. Pueden ser una lista enlazada, un archivo de texto, una base de datos o una API hacia algún dispositivo. En vez de tratar con todas las posibilidades, se utiliza el netsnmp_container.
Hay 3 interfaces diferentes entre la plantilla de código MFD y el netsnmp_container utilizadas para localizar el dato para una petición.
●
Contenedor de caché
Este es el método por defecto, el cual es suficientemente genérico para manejar casi cualquier situación. Combina dos características de Net­SNMP: el cache helper y el netsnmp_container. La primera vez que una petición se recibe para una tabla, se invoca una rutina de cache_load con un puntero a netsnmp_container. Esta función accede a cualquier datastore que contenga datos y añade todas las filas al contenedor. El contenedor se usa entonces para encontrar la fila para la petición entrante y opcionalmente se guarda para un número configurable de segundos en futuras peticiones.
●
Iterador (desordenado­externo)
El método iterador es una interfaz implementada alrededor del netsnmp_container container_iterator. Este método es muy flexible, con una sencilla interfaz. Cuando una petición es recibida para una tabla, una rutina get_next es invocada repetidamente 47
para iterar sobre cada ítem en el datastore. El agente selecciona la fila apropiada para la petición. Debido a la ineficiencia de este método, solo es recomendado para pequeños datastores o cuando los límites de memoria son muy fuertes y los tiempos de respuesta no son importantes. ●
Directo
Este método más avanzado, se utiliza con un netsnmp_container implementado por el usuario. Permite tener un netsnmp_container alrededor de un método existente de almacenamiento/acceso de datos. Sin embargo la implementación de los métodos find y next del contenedor deben manejar reglas lexicográficas de SNMP.
2.9.4.5 Manipulación de Datos
Una vez que la estructura de datos apropiada es recibida del datastore, se llama a las rutinas de manipulación de datos. Para cada objeto definido en el módulo MIB, una función se genera para extraer el valor del dato en la estructura localizada durante la fase de búsqueda.
Para objetos que poseen atributos de lectura­escritura, las manipulación es más complicada. Las peticiones de SET son procesadas en múltiples pasos, en consecuencia existen múltiples funciones generadas por cada objeto. Éstas incluyen funciones para verificación de sintaxis, verificación de valores y opción de deshacer el valor configurado. Adicionalmente, varias funciones son generadas por tabla, para tareas en las cuales sólo se necesita ser ejecutadas una vez, incluso si múltiples objetos son configurados para un índice dado.
2.9.5 Entorno de Programación
Se utilizará como entorno de programación el IDE para Linux Geany, el cual permite una rápida lectura de archivos de C y C++ y marcación de sintaxis con colores. 2.9.5.1 Herramientas de compilación
Se utilizarán las herramientas de GNU para lenguaje C y C++ (denominado GCC). Las versiones son CPP 4.2.3 (Preprocesador), G++ 3.4.6 (Compilador C++) GCC 4.2.3 (Compilador de C), libGCC 4.2.3 (bibliotecas estándares) y MCPP 2.6.4 (Preprocesador alternativo). [34]
Para la compilación de programas de la tarjeta TS7200 se utilizará el compilador Crosstool­
Linux­GCC 4.0.1.
2.9.6 Definición de la entrada al sistema.
Se define como entrada al sistema, desde el servidor, un mensaje con formato que será desplegado en un VMS particular. Este mensaje puede contener varias líneas, varias páginas, tiempos de secuencia definidos para cada página, colores y cualquier otra variable especificada en UTMC. 48
Los archivos que definen estas variables se encuentran disponibles en Internet. Se llaman VMSUTMC.mib y Y1­01017.txt (el segundo es la cabecera de datos de los objetos UTMC en SNMP). Fue necesario realizar modificaciones al archivo original, las cuales se describen en el capítulo de implementación, por lo que se adjuntan los archivos utilizados en los anexos 2 y 3.
49
3 Implementación del Sistema Desarrollado 3.1 Servidor UTMC
3.1.1 Descripción y configuración del servidor
Por motivos prácticos se implementó el servidor en un PC de escritorio. Posee un microprocesador AMD Athlon XP 1500+, 1 Gb RAM, 160 Gb en disco duro y periféricos típicos de un PC, tales como CD/DVD ROM, USB, Ethernet, teclado, mouse y monitor LCD. Además incorpora un lector de tarjetas SD/MMC/CF, el cual sirve para utilizar la Compact Flash de 256 MB de la tarjeta TS7200.
La versión del núcleo Linux es la 2.6.24­16.
El sistema operativo utiliza un gestor de aplicaciones llamado Aptitude. En su versión gráfica (Synaptic) permite instalar software fácilmente abriendo el gestor (Sistema → Administrador → Gestor de aplicaciones). Se necesita la contraseña de superusuario para instalar software nuevo en el equipo. En la ventana se escoge buscar y se especifica el software que se desea instalar (o remover). Los siguientes programas están instalados en el sistema y tienen directa relación con la implementación de la comunicación con la TS7200:
●
G++ 3.4.6 (Compilador C++)
●
GCC 4.2.3 (Compilador de C)
●
libGCC 4.2.3 (bibliotecas estándares)
●
libglib1.2­dev (Biblioteca Glib de rutinas C)
●
libstdc++6­dev (Encabezados de C++)
●
MCPP 2.6.4 (Preprocesador alternativo)
●
Mbrowse 0.3.1­6 (Visualizador gráfico de MIBS)
●
TKMib 5.4.1 (Visualizador gráfico de MIBS Tk)
●
scli 0.2.12 (colección de comandos SNMP)
●
Firefox­3.0 (Navegador Web para Internet)
●
Geany 0.13 (Entorno de programación)
●
TFTP 0.17­5 (Servidor FTP simple)
●
nfs­common 1.1.2 (Soporte para NFS)
●
nfs­kernel­server 1.1.2 (Soporte para NFS­kernel)
50
●
portmap 6.0­4: Servidor que convierte números RPC (llamadas de proceso remoto) en números de puerto de protocolo DARPA. NFS utiliza este servicio.
3.1.2 Minicom
Para realizar la comunicación entre el TS7200 y el PC a través del puerto serial, se utiliza un cable NULL­MODEM cuya configuración se muestra en la figura 12.
Figura 12: cable Null­modem
Este cable tiene terminales tipo db9 hembra en ambos lados.
Para el terminal de software se utiliza el programa minicom para Linux. Minicom es un programa de comunicación basado en el programa TELIX pero es de código libre. Entre sus características esta un directorio de dialing con auto­redial, soporte para archivos de cerrado tipo UUCP en dispositivos seriales, un interprete de script separado, la posibilidad de capturar a un archivo, usuarios múltiples con configuraciones individuales, etc.
El archivo de configuración de minicom es .minirc.dfl y se encuentra en el directorio $HOME. Se configura con el comando minicom ­s. Para la comunicación con la tarjeta TS7200 se utiliza la siguiente configuración (puede variar dependiendo del puerto serial a utilizar):
$ pu port /dev/ttyS0 $ pu rtscts No Lo anterior especifica el puerto serial a utilizar (/dev/ttyS0).
La configuración del puerto RS232 se especifica dentro del programa:
●
Tasa: 115.200 baudios
●
8 bit datos
●
Sin paridad
51
●
Sin control de flujo
●
1 bit de parada.
3.1.3 CrossTool­0.42
El compilador cruzado es una herramienta muy recomendable que permite al programador desarrollar aplicaciones para la tarjeta TS7200 pero en una plataforma distinta que posea mayores recursos de memoria y disco. La razón fundamental del uso de esta herramienta corresponde a la programación de módulos del Kernel, debido a que se requieren las fuentes del mismo y eventualmente ésto puede ocupar un espacio importante de memoria. Los pasos para instalar el compilador cruzado son: ●
Copiar el archivo crosstool­linux­0.28rc39.tar.bz2 en la raíz y descomprimir usando tar xjf crosstool*
Se genera el directorio: /usr/local/opt/crosstool/ ●
Instalar modutils para la versión de Kernel 2.4, es decir copiar modutils­2.4.27.tar.bz2 en la raíz y descomprimir. $ tar xjf modutils2.4.27.tar.bz22 $ cd modutils2.4.27 $./configure ­­build=i386­linux ­­host=arm­linux ­­prefix=/usr/local/
opt/crosstool/arm­ linux/gcc­3.3.4­glibc­2.3.2 $ make $ make install Hasta este punto la instalación del crosscompiler estaría completa, sin embargo, para compilar los módulos se requiere disponer del código fuente (al menos los headers) del Kernel 2.4. Se encuentran disponibles en:
ftp://oz.embeddedarm.com/linux/linux24­ts8­kernelsource.tar.gz
Para instalarlas se debe copiar el archivo en la raíz y luego descomprimir. A continuación, es necesario ajustar el archivo Makefile ubicado en el directorio /linux24, indicando la ruta en donde se encuentra el compilador cruzado y modutils, es decir: CROSS_COMPILE=/usr/local/opt/crosstool/armlinux/gcc­3.3.4­
glibc­2.3.2/bin/arm­linux­ MOD_UTILS=/usr/local/opt/crosstool/armlinux/gcc­3.3.4­
glibc­2.3.2/sbin/depmod ●
Se debe actualizar la configuración de las fuentes y luego ajustar las dependencias, 52
es decir: $ make ts7200_config $ make dep ●
La siguiente etapa para la compilación de módulos es fabricar un Makefile apropiado. A continuación se adjunta un ejemplo (módulo denominado MOD05) cuyo principal objetivo es configurar la ruta del compilador y el código fuente del Kernel.
CROSS_COMPILE=/usr/local/opt/crosstool/arm­linux/gcc­3.3.4­
glibc­2.3.2/bin/arm­linux­gcc MOD_UTILS=/usr/local/opt/crosstool/arm­linux/gcc­3.3.4­
glibc­2.3.2/sbin/depmod INCLUDEDIRS = /linux24/include MOD05 : $(CROSS_COMPILE) ­D__KERNEL__ ­DMODULE ­D__ARM_ARCH__ ­O ­Wall ­I$(INCLUDEDIRS) ­c MOD05.c ­o MOD05.o ●
Para compilar, escribir: $ make MOD05 3.2 Cliente UTMC
3.2.1 Descripción de la configuración de la Tarjeta TS7200
Inicialmente el Kernel es cargado en memoria desde el RedBoot, luego se inicializa el hardware y se montan los sistemas de archivos. A continuación se da lugar al primer proceso de sistema: /sbin/init, que se encarga de gestionar la configuración activando los procesos o servicios. Cuando se inicializa la configuración de procesos, init busca el archivo inittab ubicado en el directorio /etc. Cerca del comienzo del archivo, aparece una sentencia que define el nivel de ejecución: Id:2:initdefault
Mediante el nivel de ejecución, init determina la ubicación de los scripts que activan los primeros procesos. Antes de iniciar el nivel de ejecución, independiente del nivel configurado, se ejecuta un script especificado en inittab, encargado de realizar tareas obligatorias tales 53
como: inicializar puertos serie, resolver dependencias entre módulos, sincronizar reloj, etc.
Con el nivel de ejecución establecido, se procede a llamar al script rc ubicado en /etc/init.d/rc ingresándo como argumento el valor de nivel. Este dato lo utiliza rc para definir en qué directorio se encuentra el conjunto de scripts (en estricto rigor son enlaces a los scripts ubicados en /etc/init.d/) que se debe activar. Por el contenido de inittab, los enlaces se encuentran en el directorio /etc/rc2.d/.
En el directorio /etc se encuentran los directorios /rc1.d/ .. /rc6.d/ asociados a distintos niveles. En particular, el nivel 1 corresponde al más básico en donde no se levanta ningún tipo de servicio de red y permite un solo usuario. Los siguientes niveles caracterizan opciones multiusuario con más o menos servicios adicionales. Centrándose en el nivel 2 (nivel más básico configurado por defecto para multiusuarios y servicios de red) se pueden encontrar los siguientes enlaces dentro del directorio /etc/rc2.d :
ts7200:/etc/rc2.d# ls S14ppp@ S20snmpd@ S23ntp@ S91apache­ssl@ S20inetd@ S20ssh@ S50wu­ftpd@ S99rmnologin@ S20makedev@ S21nfs­common@ S89cron@ S99stop­bootlogd@ En donde:
●
S10sysklogd: Demonio5 para controlar el Logs que describe los eventos del sistema (los archivos en /var/log/syslog*). ●
S11klogd: Demonio para administrar el registro que describe los pasos del Kernel.
●
S89atd: Demonio encargado que un proceso se ejecute a una determinada hora, o el tiempo que el usuario defina.
●
S11hotplug: Servicio que permite conectar y desconectar periféricos, sin necesidad de reiniciar el sistema (útil por ejemplo para dispositivos USB).
●
S89cron: Demonio que revisa los archivos crontab de los usuarios con permiso para utilizar el 5 En linux se denomina “demonios” a las aplicaciones de sistema que están ejecutándose permanentemente y ofrecen servicios para el resto del software.
54
servicio, verificando la necesidad de ejecutar un programa en un instante determinado.
●
S20inetd: Demonio encargado de escuchar los puertos TCP y levantar aplicaciones dependiendo del servicio solicitado. Siempre debe estar presente si se desea usar FTP y Telnet. ●
S19nfs­common: NFS: (Network File System) sistema de archivo virtual que permite a una máquina Unix, conectada en red, montar (como un directorio local) un sistema de archivos ubicado en otra máquina. Posee la flexibilidad de utilizar distintos formatos de almacenamiento. ●
S20ssh: Servicio que incluye protocolo tipo Telnet para acceder a otras máquinas pero con un grado mayor de seguridad, mediante cifrado de claves de acceso. ●
S91apache: Servidor de paginas web estable para Unix (ver punto 3.4).
●
S20nfs­kernel­server NFS: Descrito anteriormente, pero incluye el concepto de servidor NFS (por si algún cliente desea montar un directorio ubicado en el servidor).
Para activar o desactivar los servicios en un nivel dado, se debe renombrar o eliminar el enlace. No se pueden utilizar nombres que comiencen con S* o K*, debido a que el script rc trabaja sobre el listado de enlaces que comienzan con esos caracteres. Al entrar a un nivel, los scripts 'S' son ejecutados con el parámetro "start", mientras que al salir los scripts 'K' se ejecutan con el parámetro "stop". 3.2.2 Flash OnBoard TS7200 La tarjeta TS7200 posee una Flash OnBoard de 8Mb, compuesta por 64 sectores de 128Kb cada uno. La Flash se particiona en tres:
●
TS­BOOTROM
Inicializa registros relacionados con el hardware. ●
Sistema de archivos JFFS2
Espacio en donde residen las aplicaciones de usuario (48 sectores). ●
RedBoot
Corresponde a un sistema de monitoreo que permite la manipulación de la Flash OnBoard. En este espacio se encuentra, entre otras, la imagen del Kernel y configuraciones de Red.
Si la tarjeta TS7200 se ejecuta bajo Linux desde la Compact Flash, entonces es posible revisar el contenido en el espacio JFF2S de la Flash OnBoard mediante la instrucción:
55
$ mount /dev/mtdblock/1 /mnt En /dev/mtdblock/ existen los dispositivos 0,1 y 2 los cuales representan respectivamente las particiones descritas anteriormente. JFFS2 corresponde a un sistema administrador de archivos optimizado para su uso en dispositivos Flash, característicos de sistemas embebidos. JFFS2 genera una abstracción que permite al sistema operativo visualizar el dispositivo Flash como si fuera otro disco. Fue desarrollado por RedHat. Entre las características más importantes se destaca la maximización del tiempo de vida de la Flash y la inmunidad frente a fallas de energía durante procesos de escritura. [35]
El comando de Linux mkfs permite crear una imagen de formato JFFS2 desde un directorio predefinido. Este comando es utilizado para actualizar la Flash OnBoard de la tarjeta TS7200 a partir de la Compact Flash, con una imagen pre­fabricada. (más adelante se explica donde conseguir las imágenes disponibles para el TS7200)
3.2.3 Recursos y soporte para actualizaciones Hasta la fecha de realización de esta memoria, Embbeded ARM ha contado con un sitio FTP en donde se encuentran disponibles diversas actualizaciones asociadas a sus productos y accesibles como usuario anonymous:
ftp://oz.embeddedarm.com En el subdirectorio /images se distinguen las siguientes categorías: ●
Imágenes del Kernel: Corresponden a las ejecutadas al inicio, durante el proceso de RedBoot.
● Imágenes orientadas a la Flash OnBoard: Corresponden a la réplica exacta de la estructura de archivos por defecto, insertada en la partición tipo JFFS2. ●
Imágenes de la Compact Flash: También corresponden a réplicas exactas de una estructura de archivos por defecto, insertada en la partición destinada para el usuario. En el directorio /images/os se pueden encontrar imágenes para las plataformas TS7200 y TS7250 en variados formatos de Flash y sistemas de archivos.
Adicionalmente, Embedded ARM se encuentra realizando un esfuerzo en ordenar la información de imágenes en la página web: http://www.seiner.com/ts7000/index.php/WhereToGetTheLatestImages
56
La convención utilizada para nombrar los archivos dentro del directorio /images/os es la siguiente: Tarjeta­TamañoFlash­Default, la cual en rigor corresponde a un enlace que apunta a la dirección física en donde reside el archivo en cuestión. Al estudiar los archivos relacionados con los enlaces se aprecia lo siguiente: ●
Los archivos con extensión .jffs2 corresponden a imágenes orientadas a la memoria Flash OnBoard. JFFS2 es el sistema de administración de archivos optimizado para este tipo de dispositivos. ●
En algunos casos, a modo de referencia, se indica la fecha del precompilado y la versión especifica, por ejemplo: ts5, ts6 y ts8. ●
Los archivos con extensión tar o bz2 para 128 y 256 Mb corresponden a imágenes destinadas a dispositivos Compact Flash. En estos casos solo basta con descomprimir y desempaquetar su contenido en la partición apropiada de Flash. ●
Es importante notar el tamaño de los archivos *.jff2. Las imágenes orientadas a la Flash OnBoard de 8Mb de la tarjeta TS7200 deben pesar 6291456 bytes (debido a la forma recomendada por el fabricante para particionar la Flash). En relación a la imagen precompilada del Kernel, (cargada durante el proceso de RedBoot) se encuentra disponible la versión en formato para real time y la versión normal. Por ejemplo, en la dirección: ftp://oz.embeddedarm.com/ts9/vmlinux­ts7200­ts9.bin
está disponible la imagen normal del Kernel 2.4 versión ts9 y sus módulos se pueden bajar desde: ftp://oz.embeddedarm.com/ts9/linux24­ts9­modules.tar.gz
La imagen precompilada que incluye la versión para Real Time Adeos (Sistema para Tiempo Real) está en la dirección: ftp://oz.embeddedarm.com/rt/arm­ts9/
3.2.4 Actualización Flash OnBoard La versión utilizada por defecto para la Flash OnBoard de la TS7200 es la ts8. En el sitio FTP 57
se puede encontrar como el enlace ts7200­8­default, el cual apunta al archivo tslinux6­ts8.jffs2 y tiene el tamaño adecuado para la partición JFFS2. (6291456 bytes) Una imagen más actual, que no se encuentra enlazada, corresponde al archivo tslinux­8mb­10­26­2005.jffs2. Se debe tener precaución que exista compatibilidad de versión entre la imagen del Kernel, cargada durante el proceso de RedBoot y la imagen cargada en la Flash OnBoard. Si, por ejemplo, la versión del Kernel es ts9 y los módulos de la Flash OnBoard no son coincidentes, entonces deberán ser actualizados descomprimiendo el archivo ubicado en la dirección: ftp://oz.embeddedarm.com/ts9/linux24­ts9­modules.tar.gz
Finalmente, para actualizar la imagen de la Flash OnBoard, se debe inicializar la tarjeta TS7200 sobre la Compact Flash. A continuación, copiar la imagen en cualquier directorio y luego desde esa posición ingresar el comando: dd if=NombreImagen of=/dev/mtdblock/1 Para revisar el resultado, se puede montar la partición JFFS2 sobre la Compact Flash mediante el comando: mount /dev/mtdblock/1 /mnt 3.2.5 Actualización de Bibliotecas en la Flash OnBoard Las imágenes disponibles para actualizar la Flash OnBoard, vienen en su formato por defecto y no incluyen algunas bibliotecas que son útiles para la ejecución de ciertas aplicaciones. En particular, no se incluye la biblioteca asociada a los POSIX Threads. Para actualizar la biblioteca asociada a los POSIX Threads se debe: ●
Si la aplicación fue desarrollada usando el compilador cruzado, entonces buscar archivos de la forma: libpthread* al interior del directorio en donde se instaló el compilador cruzado. Como resultado, puede aparecer el archivo (o enlace) libpthread.so.0 y archivos de la forma libpthread­ 0.xx.so (xx indica la versión de la biblioteca).
●
Si el archivo libpthread.so.0 es un enlace, entonces mediante ls –l observar hacia donde se dirige, en esa dirección se encuentra la biblioteca de interés. ●
Si el archivo libpthread.so.0 no corresponde a un enlace, entonces la biblioteca se encuentra contenida en él. ●
Copiar la biblioteca en el directorio /lib de la Flash que corresponda en la tarjeta TS7200. 58
●
Si la biblioteca es de la forma libpthread­0.xx.so, entonces se debe fabricar su enlace al interior del directorio /lib mediante: ln –s libpthread­0.xx.so libpthread.so.0 Existe una manera, desde el compilador GCC, para incrustar las bibliotecas dinámicas en el binario final. Para ésto, se debe utilizar la opción –static de GCC. Eventualmente, esta herramienta puede ser útil para evitar actualizar bibliotecas. Sin embargo, el binario resultante es bastante mayor. 3.2.6 Actualización de la Imagen del Kernel Al buscar las imágenes precompiladas dentro del sitio FTP, se pueden encontrar imágenes para tiempo real e imágenes normales. En la dirección: ftp://oz.embeddedarm.com/ts9/vmlinux­ts7200­ts9.bin
se encuentra la imagen normal versión ts9, de 735Kb, lo cual es apropiado para el espacio destinado en el segmento FIS del RedBoot (segmento del RedBoot en donde se almacena la imagen del Kernel). En el caso que se desee actualizar la imagen del Kernel, utilizando alguna versión precompilada de tiempo real, se encuentran disponibles los siguientes archivos: ftp://oz.embeddedarm.com/rt/arm­ts9/ts7200_rtvmlinux.bin
ftp://oz.embeddedarm.com/rt/arm­ts9/ts7200_rtzimage
El primero pesa aproximadamente 1.5Mb y el segundo 742Kb. El segundo corresponde a la versión comprimida del primero. En RedBoot se debe ejecutar la imagen comprimida, debido a que el archivo .bin excede el espacio permitido. Ejecutar la imagen comprimida no genera problemas, pues al iniciar el sistema se detecta automáticamente esta condición y se descomprime en la memoria antes de la ejecución.
Para actualizar la imagen del Kernel se utiliza la herramienta load del RedBoot, que permite descargar la imagen desde un servidor TFTP. Éste corresponde a un servicio muy similar al FTP. Algunas consideraciones antes de traspasar la imagen del Kernel son: ●
La IP del PC en donde se encuentra el servidor TFTP debe pertenecer a la misma red configurada en el TS7200.
●
Observar que no exista ningún firewall activo.
●
Comprobar la comunicación utilizando el comando ping.
●
Copiar la imagen en el directorio por defecto del servidor TFTP, asignándole un 59
nombre apropiado (vmlinux para Linux normal o rtvmlinux para Linux de real time). Finalmente, para ejecutar el proceso de carga, se debe reiniciar la tarjeta TS7200 e ingresar al RedBoot presionando CTRL+C. Luego se debe ejecutar: Load –r –b 0x00218000 –h Server_IP Nombre_Imagen Si se desea cambiar definitivamente la imagen ubicada en el FIS del RedBoot, primero se debe eliminar la imagen actual mediante: fis delete Nombre_Imagen a continuación, cargar la nueva imagen tal como se explicó anteriormente, y finalmente grabarla dentro del FIS utilizando: fis create Nombre_Imagen
3.2.7 Bootloader RedBoot
Al encender la tarjeta TS7200, se ejecuta código de inicio propietario de Technologic Systems TS­BOOTROM y luego inmediatamente ejecuta RedBoot. Éste es un monitor de inicio que permite la manipulación de la Flash OnBoard, imágenes JFFS2/YAFFS2, carga y ejecución del Kernel o ejecutables vía TFTP, consola serial o de la memoria Flash. Si no se interrumpe en un segundo, se ejecuta un script pre­existente, ejecutando un núcleo Linux por defecto en la memoria de la Flash OnBoard. Esto causará que se carguen las imágenes pre­existentes JFFS2/YAFFS2. Se pueden observar los parámetros por defecto con el siguiente comando en la línea de comandos de RedBoot:
$ fconfig ­l
Los parámetros pueden ser modificados ingresando fconfig. Al final se pregunta si se desean guardar o descartar los cambios realizados. Luego se ejecuta el comando reset para reiniciar la tarjeta.
El script por defecto carga el núcleo de Linux de la Flash y usa la imagen JFFS2/YAFFS2 para el sistema de archivos de root. El Kernel debe ser cargado en la dirección de memoria 0x00218000. El comando que realiza automáticamente esta operación es:
$ fis load vlinux
60
Después de cargar el Kernel, el script lo ejecuta con el siguiente comando:
$ exec ­c "console=ttyAM0,115200 root=/dev/mtdblock1”
Para terminar la definición del script, el usuario debe ingresar una línea vacía presionando enter.
3.2.8 Debian
Debian es una distribución de Linux poderosa y completa, basada en su mayoría sobre herramientas GNU. Incluye todo lo necesario para desarrollar y ejecutar aplicaciones Linux. Contiene varias utilidades originales y herramientas de instalación, para hacer de la utilización del sistema y actualización de paquetes tareas sencillas. Con Debian, los usuarios experimentados tienen un sistema completo de Linux, para obtener el máximo de ventaja en su conocimiento y los usuarios nuevos tienen un ambiente fácil de usar, para empezar a conocer Linux.
Technologic Systems utiliza Debian como una distribución de desarrollo. Ofrece tarjetas Compact Flash de 256 Mb con Debian preinstalado. Junto con las utilidades básicas, se agregan herramientas de desarrollo que incluye un compilador arm­gcc nativo para C/C++. Contiene además un intérprete de Perl y una gran variedad de servicios de red, tal como FTP, Telnet, SSH y servidor HTTP Apache. Se puede utilizar Debian vía un sistema de archivos remoto (NFS) o con un dispositivo de memoria Flash.
3.2.8.1 apt­get
Cuando se ocupa un sistema de archivos Debian, se añade o remueve software con el administrador de paquetes de Debian (Aptitude). Para instalar un paquete se utiliza el comando:
$ apt­get install “paquete_nuevo”
Para remover un paquete:
$apt­get remove “paquete_a_desinstalar”
Para actualizar la base de datos del gestor:
$ apt­get update
Se puede obtener más información con el comando man apt­get.
61
Como fue señalado anteriormente, Debian puede ser instalado en un NFS (Network File System) o en un dispositivo de memoria Flash. Se especifica a continuación la manera de realizar ambas instalaciones, dado que ambas se utilizaron para el desarrollo de esta memoria: la primera para probar las aplicaciones desarrolladas y la segunda para comprobar que funcionarán correctamente sin necesidad del soporte de espacio del PC.
Primero se debe conseguir una distribución de Debian adecuada. En la página de Technologic Systems se encuentran las siguientes distribuciones libres para su descarga:
●
debian­sarge­1.07.tar.bz2
●
debian­sarge­1.12.tar
●
debian­sarge­256MB­05­01­2006.tar.bz2
●
debian­woody­256MB­08­09­2006.tar.bz2
●
debian­woody­256MB­10­27­2005.tar.bz2
Debian posee distintas ramas de desarrollo, que se agrupan en distintas distribuciones. Las ramas son:
●
Estable: “Debian estable” (stable) es la versión estabilizada de Debian. Esta versión cuenta con el apoyo del equipo de seguridad de Debian y es la recomendada para un uso de producción.
●
De Pruebas:
“Debian en pruebas” (testing) es la versión experimental de Debian. En esta versión se encuentran paquetes que han estado previamente en la versión inestable, pero que contienen muchas menos fallas. Además, debe poder instalarse en todas las arquitecturas para las cuales fueron construidas. Es la versión más recomendada para ser usada como sistema de escritorio. De esta distribución saldrá la futura versión estable.
●
Inestable: “Debian inestable” (unstable) o Sid, es donde tiene lugar el desarrollo activo de Debian. Es la distribución que usan los desarrolladores del proyecto.
Actualmente Etch es la versión estable. Sarge y Woody fueron versiones estables anteriores. Sarge es más actual que Woody, por lo que se utilizará para esta memoria la versión Sarge de 256Mb. Es decir, se utilizará el archivo:
debian­sarge­256MB­05­01­2006.tar.bz2
Una vez descargado, se descomprime con el comando tar en Linux:
$ tar ­zxvf debian­sarge­256MB­05­01­2006.tar.bz2 ­C .
62
Donde los parámetros zxvf indican que se utiliza el formato bzip2 (z), se extraen (x), se muestra el trabajo realizado (v) y se especifica que se trata de un archivo (f). ­C especifica que los archivos se extraigan en el directorio donde se ejecute el comando. De todas maneras, los archivos quedan almacenados en un directorio nuevo, en este caso es /debian­
sarge­256MB­05­01­2006, porque ese directorio esta especificado dentro del archivo.
3.2.8.2 Usar Debian con NFS.
Por conveniencia, se crea un enlace al directorio generado, para simplificar los comandos del NFS:
$ ln ­s /home/TS7200/debian­sarge­256MB­05­01­2006 /home/TS7200/debian
Si se requiere utilizar otra de las distribuciones de Debian, simplemente se cambia el enlace hacia el otro directorio, sin alterar las configuraciones de NFS.
Se instala el demonio NFS. En Ubuntu es necesario instalar los paquetes nfs­common (version 1:1.1.2), nfs­kernel­server (version 1:1.1.2) y portmap (versión 6.0­4).
Es importante configurar el archivo /etc/exports en el PC que hospeda el NFS. Se agrega la siguiente línea en ese archivo:
$ sudo vi /etc/exports /home/TS7200/debian/ 192.168.1.101/255.255.255.0(rw,no_root_squash,insecure) Es decir, se específica el directorio donde está el NFS, la IP del host (la del PC), la máscara de red y los atributos rw (read­write), no­root­squash (sin poder de superusuario), insecure (modo inseguro).
Después se reinicia el demonio:
$ sudo /etc/init.d nfs­kernel­server restart
También es necesario configurar el Debian preparado para el NFS. Para configurar la red, se modifica el archivo /etc/network/interfaces:
$ vi /home/TS7200/debian/etc/network/interfaces Se debe añadir: 63
iface eth0 inet static address 192.168.1.103 network 192.168.1.0 netmask 255.255.255.0 broadcast 192.168.1.255 También se debe modificar el archivo /etc/fstab, que contiene las definiciones de los sistemas de archivo que existirán en el NFS:
$ vi /home/TS7200/debian/etc/fstab # /dev/sdcard0/disc0/part3 / ext2 defaults,noatime,async 1 1 192.168.1.101:/home/dcortes/TS7200/debian/ /
1 6
nfs
exec,dev,suid
1
Una vez realizado todo esto, se puede encender la tarjeta y presionar Control+C en el primer segundo, para modificar el script de inicio de RedBoot con el siguiente script:
load ­r ­v ­b 0x00218000 ­m disk hda1:/boot/vmlinux.bin exec ­c "console=ttyAM0,115200 ip=dhcp nfsroot=192.168.1.101:/home/TS7200/debian" Como se aprecia, el Kernel utilizado está en la Compact Flash y se llama vmlinux.bin. Por lo tanto, la Compact Flash deberá estar presente con ese archivo, para que funcione el script.
3.2.8.3 Usar Debian en la Compact Flash.
Para montar Debian en la Compact Flash se deben cumplir 2 requisitos:
●
El sistema de archivos no debe exceder los 256 Mb.
●
Se debe disponer de la versión correcta del Kernel en el directorio /root.
Si ambos requisitos se satisfacen, se puede copiar la distribución en la Compact Flash. Primero es necesario formatear la tarjeta en formato EXT2. Se recomienda en este punto respaldar los archivos que pudiesen existir en la Compact Flash, porque serán borrados definitivamente. Se recomienda hacerlo también cuando se detecte alguna anomalía en los archivos:
# fdisk /dev/sdc1 6 # es un comentario, es la línea que estaba por defecto y se quita, para añadir la segunda.
64
# mke2fs /dev/sdc1 La utilidad fdisk es interactiva, despliega un menú con distintas opciones de configuración del dispositivo. Primero se debe suprimir la (las) particion(es) existente(s) con d, añadir una nueva partición con n, cambiar el identificador del sistema con t y escoger el tipo de partición EXT2 (85, extendida), verificar la tabla de particiones con v y salir escribiendo las modificaciones con w.
Luego se monta la Compact Flash en el PC ejecutando los siguientes comandos:
$ sudo mount ­t ext2 /dev/disk/by­id/usb­Sony_USB_HS­
CF_Card_50000005BF1F­0\:0­part1 /media/sandisk $ cd /media/sandisk Se recomienda en este punto respaldar los archivos que pudiesen existir en la Compact Flash (a menos que se haya formateado en el paso anterior) porque serán borrados definitivamente.
$ sudo rm ­r * $ sudo cp ­r /home/dcortes/TS7200/debian/* . En el último comando, el directorio señalado es donde se ubica la distribución que se quiere copiar en la Compact Flash.
Luego es necesario configurar el tipo de archivos que debe registrar el sistema. Esto es realizado por el archivo /media/sandisk/etc/fstab.
$ sudo vi /etc/fstab /dev/ide/host0/bus0/target0/lun0/part1 /
ext2
defaults,noatime,async
1
1 #192.168.1.101:/home/dcortes/TS7200/debian/ /
nfs exec,dev,suid
1 $ sudo umount ­t ext2 /dev/disk/by­id/usb­Sony_USB_HS­
CF_Card_50000005BF1F­0\:0­part1 /media/sandisk 1
Es decir, en vez de utilizar el NFS, se utiliza el tipo de archivos EXT2. Una vez que la Compact Flash está en la tarjeta TS7200, es necesario realizar un procedimiento para que la fecha de la última verificación no sea incoherente con la fecha de la tarjeta. Ésto se debe a que antes de sincronizarse con NTP (lo cual ocurre cuando el sistema ya ha inicializado), la tarjeta tiene la fecha de 31 de diciembre de 1969. Este problema puede ser solucionado con un reloj de hardware montado en el puerto PC104. Para hacer coincidir la fecha de verificación de checkfs con la fecha de la tarjeta, se realiza el siguiente comando desde el NFS: 65
$ tune2fs /dev/ide/host0/bus0/target0/lun0/part1 ­T 19691231
Con este cambio realizado, se reinicia la tarjeta y se cambia el script de inicio del BOOTROM, para que cargue el sistema de la Compact Flash:
REDBOOT> fconfig
load ­r ­v ­b 0x00218000 ­m disk hda1:/boot/vmlinux.bin exec ­c "console=ttyAM0,115200 ip=dhcp root=/dev/hda1" Con ésto, el sistema está listo para utilizar Debian en la Compact Flash. En las discusiones se examina la factibilidad de utilizar un sistema de mayor capacidad vía USB o una CF mayor.
3.2.9 Utilizando Net­SNMP
Net­SNMP utiliza varios archivos de configuración para sus aplicaciones. Por defecto, las aplicaciones buscan archivos de configuración en los siguientes directorios, en orden de prioridad:
/usr/local/etc/snmp
/usr/local/share/snmp
/usr/local/lib/snmp
$HOME/.snmp
donde $HOME es el directorio del usuario (definido por el sistema).
En cada directorio se buscan archivos de extensión .conf y .local.conf (la segunda de menor prioridad). Por lo que hay 8 lugares por defecto donde puede existir un archivo de configuración. Los directorios por defecto pueden ser re­asignados utilizando la variable de entorno SNMPCONFPATH, con una lista de directorios separada por dos puntos (a:b:c...). El directorio para los datos persistentes debiera estar incluido cuando las aplicaciones necesitan datos persistentes, como por ejemplo snmpd. Las aplicaciones leerán archivos de configuración persistente en el siguiente orden de preferencia:
●
Archivos en el directorio apuntado por la variable de entorno
SNMP_PERSISTENT_FILE.
●
Directorios definidos por la variable de entorno SNMPCONFPATH.
●
Directorios definidos por la variable persistentDir en el archivo snmp.conf.
●
Directorios definidos por la variable de entorno SNMP_PERSISTENT_DIR.
●
El directorio por defecto /var/net­snmp.
66
Cada aplicación puede utilizar distintos archivos de configuración. Por ejemplo, el agente snmpd entiende directivas de configuración en el archivo snmpd.conf y snmp.conf. El archivo snmp.conf está pensado para aplicaciones que soporten directivas para controlar todas las aplicaciones SNMP, tales como manipular y descifrar archivos textuales de MIB SNMP.
Los archivos MIB utilizados son VMSUTMC­v2.mib y el archivo de cabecera Y1­01017­
v2.txt. Por defecto, estos archivos no se pueden compilar por NET­SNMP. Se realizaron las siguientes modificaciones para lograr la compilación:
●
Hay partes en la cabecera de VMSUTMC.mib que deberían estar comentadas por ser texto informativo y no lo están. Se soluciona añadiendo ­­ al principio de cada línea.
●
En la línea 53 de VMSUTMC.mib se invoca al archivo de Y1­01017­v2.txt, con el siguiente comando:
utmc, utmcVMS, utmcVMSType1, TruthTable FROM Header­MIB;;
Pero en el archivo Y1­01017.txt está definido como UTMC­Header­MIB. Esto se soluciona cambiando la directiva en el archivo VMSUTMC.mib por: FROM UTMC­Header­
MIB;; ●
En la línea 144 de VMSUTMC.mib aparece:
::={sysinfo12}
pero debería ser sysInfo (con mayúscula). También se modifica.
●
En la directiva de invocación, línea 53, dice: TruthTable. Esto debería estar definido en el archivo Y1­01017.txt pero está definido como TruthValue. Se cambia y la compilación resulta exitosa.
Por estas razones se incluye en los anexos 2 y 3 los archivos modificados Y1­01017­
v2.txt y VMSUTMC­v2.mib.
3.2.9.1 Control de Acceso
Existen dos modalidades de control de acceso, la más simple es el método tradicional de SNMP que utiliza las siguientes directivas:
rouser USER [noauth|auth|priv [OID | ­V VIEW [CONTEXT]]] rwuser USER [noauth|auth|priv [OID | ­V VIEW [CONTEXT]]]
rocommunity COMMUNITY [SOURCE [OID | ­V VIEW [CONTEXT]]] rwcommunity COMMUNITY [SOURCE [OID | ­V VIEW [CONTEXT]]]
rocommunity6 COMMUNITY [SOURCE [OID | ­V VIEW [CONTEXT]]] rwcommunity6 COMMUNITY [SOURCE [OID | ­V VIEW [CONTEXT]]]
67
En ellas, se definen permisos de acceso de lectura y/o escritura de la información para distintos usuarios, mediante comunidades (una palabra clave que sólo debe ser conocida por aquellos que tengan el permiso). Las dos últimas están pensadas para IPV6.
El otro método es el Modelo de control de acceso basado en vistas (VACM), definido en el documento RFC 2575. Este método consta de varias partes:
●
Mapear la comunidad a un nombre de seguridad.
Las directivas com2sec y com2sec6 asocian los nombres de las comunidades a nombres de seguridad, a la vez que se restringen a un huésped específico, a una sub­red, o globalmente por defecto. Una sub­red se define por IP/Máscara o IP/bits. Una comunidad puede ser especificada en varias directivas y la primera combinación que se adecúe a la petición entrante será seleccionada. Si un contexto es especificado, utilizando el argumento ­Cn, la comunidad será mapeada en dicho contexto de SNMPv3. ●
Mapear los nombres de seguridad a grupos
La directiva group mapea un nombre de seguridad, especificado en el paso anterior, a un grupo. Varias directivas pueden especificar el mismo nombre de grupo, permitiendo accesos individuales que apliquen a varios usuarios y/o comunidades. Típicamente, una directiva com2sec está acompañada de dos directivas group.
●
Asignar Vistas
La directiva view define una vista, que consiste en un subconjunto del árbol MIB. Es llamada comúnmente sub­árbol. Varias directivas view pueden ser dadas con el mismo nombre, para construir colecciones más complejas de OIDs. Además los sub­árboles pueden ser incluidos o excluidos lo que define vistas aun más complejas. También se puede definir una máscara, la cual consiste en un valor hexadecimal que indica cuales sub­
identificadores (o sub­niveles del árbol especificados) pueden ser accesados y cuales no. Es útil para definir que columnas pueden ser vistas en una tabla.
●
Autorización de vistas a las comunidades
authcommunity asocia las comunidades definidas a las diferentes vistas, en modo de lectura, escritura y notificación (de manera independiente cada uno). Asimismo, existen las directivas authuser para asociar usuarios a las vistas, authgroup para asociar grupos, authaccess para los accesos y setaccess para asignar los accesos.
En la configuración realizada en el archivo snmpd.conf, se escogió el método VACM, por ser más flexible y adecuado en términos de seguridad. Se creó la comunidad de nombre utmc, con accesos de escritura y lectura para el subárbol MIB, definido por UTMC, el cual empieza en .1.3.6.1.4.1.13267 (iso.org.dod.internet.private.enterprises.utmc)
68
3.2.9.2 Extensibilidad del Agente
En el archivo snmpd.conf se definen las directivas de extensibilidad del agente. exec [MIBOID] NAME PROG ARGS sh [MIBOID] NAME PROG ARGS
Estas directivas invocan el programa indicado con PROG, con los argumentos ARGS. Estas directivas agregan información dentro del sub­árbol indicado por MIBOID, se retorna la información en MIBOID.100.0 y el comando completo en una pseudo­tabla en MIBNUM.101, con una columna por cada línea de salida retornada.
extend [MIBOID] NAME PROG ARGS
extendfix NAME PROG ARGS
Estas directivas se prefieren a exec y sh, que serán dejadas obsoletas, por lo que no se describen con mayor detalle.
pass [­p priority] MIBOID PROG
Esta directiva traspasa el control completo del sub­árbol MIBOID al comando específico definido por PROG. Las peticiones de GET y GETNEXT para los OIDs del sub­árbol ejecutarán el programa de la siguiente forma:
PROG ­g OID PROG ­n OID El comando PROG deberá retornar la respuesta a la petición como tres lineas separadas a stdout, la primera línea debería ser el OID del valor retornado, la segunda su tipo (integer, gauge, counter, timeticks, ipaddress, objectid o string) y la tercera debería ser el valor retornado.
Si la petición no corresponde al OID especificado o no es una petición de GET, entonces la salida no debiera producir nada. Esto resultará por parte del agente en un error noSuchName o noSuchInstance.
Las peticiones de SET resultarán en el comando:
PROG ­s OID TYPE VALUE
donde TYPE indica el tipo del valor pasado como tercer parámetro. Si la asignación es 69
exitosa, el comando PROG debiera salir sin producir ninguna información. Los errores deben ser indicados escribiendo not­writable si el OID no tiene acceso de escritura o wrong­
type si no corresponde el tipo. En cada caso, el comando debe salir una vez que finaliza el proceso. Cada petición disparará una invocación separada del comando. La prioridad de registro es por defecto 127. Ésto se puede modificar con el argumento opcional ­p, donde los registros de baja prioridad son usados de preferencia a los de valores más altos.
Otra extensibilidad del Agente Net­SNMP es el soporte para Perl Embebido. En el marco de este trabajo no se consideró esta alternativa, pero se analizará su aplicabilidad en las discusiones.
3.2.10 Implementación del Script para la extensión del agente
Se utilizó la directiva pass para invocar un script implementado con el lenguaje de script de bourne shell. Este script discrimina el argumento de entrada para las peticiones de get (­g), getnext (­n) y set (­s). Para las dos primeras, verifica que el número de argumentos sea dos. En caso de ser correcto, busca en un archivo, generado por el mib2c, el OID especificado en el segundo argumento y devuelve el valor del MIB. Se utilizó el lenguaje awk para buscar los valores y el OID. El lenguaje awk, en términos generales, se invoca de la siguiente forma:
awk filtro acción
Donde filtro es un patrón de expresión regular, que permite seleccionar los registros donde se realice la acción. Por ejemplo, una de las invocaciones implementadas es la siguiente:
awk '$1 ~ /^'$DIFF'$/ {print $3; print $4}' $FILE
En esta expresión, $1 es el primer objeto de una fila del archivo y $DIFF es la variable que se compara. En caso de coincidir, se realiza la acción que es desplegar el tercer y el cuarto objeto de la fila seleccionada. Ésto es realizado en el archivo $FILE.
Si el primer argumento es ­s, la petición es de tipo set, por lo tanto el script verifica que coincidan el tipo requerido y el de la variable (dado por los strings integer; gauge; counter; timeticks; ipaddress; objectid; o string). Si no coincide el tipo, se devuelve en la salida el token wrong­type. En caso de coincidencia de tipo, se modifica el archivo de datos nuevamente, utilizando una llamada de tipo awk. Si la variable no soporta ser escrita de acuerdo al MIB, entonces el script devuelve en la salida el atributo not­writable.
En el anexo 3 se adjunta el script implementado. 70
3.3 Implementación del webserver
3.3.1 Configuración de Apache
Apache viene por defecto en Debian y Ubuntu. Es fácilmente configurable a través de los archivos de configuración situados en /etc/apache2. Cualquier ajuste que se requiera realizar, ya sea para configurar sitios de red virtuales u otra funcionalidad adicional, se puede realizar sin modificar el archivo principal de configuración. Se puede utilizar cualquier archivo con extensión *.conf dentro del directorio:
/etc/httpd/conf.d Por ejemplo, si se require añadir un alias para un directorio localizado en /home/user/www, el cual se desea visualizar como el directorio /user en Apache, bastaría crear un archivo, denominado arbitrariamente como /etc/httpd/conf.d/aliases.conf, con el siguiente contenido: Alias /www /home/user/www El acceso estará restringido a este nuevo directorio virtual con el navegador. Para poder ser accedido, deberá existir un documento índice en el interior (index.html, index.php, etc.) o bien, que dicho directorio sea configurado para mostrar el contenido del siguiente modo: Alias /www /home/user/www <Directory "/home/user/www"> Options Indexes MultiViews FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory> El parámetro Indexes indica que se deberá mostrar el contenido del directorio. El parámetro FollowSymLinks posibilita poder colocar enlaces simbólicos dentro del directorio. El parámetro Includes especifica el permiso de utilización de los SSI (Server Side Includes), que entregan funciones de autentificación. El parámetro AllowOverride None deshabilita el acceso a los archivos .htaccess.
Cuando sea necesario, es posible configurar un directorio en particular para que Apache redirija de modo transparente éste y su contenido hacia cualquier otra dirección. Redirect 301 /webmail http://mail.su­dominio.net/ En el ejemplo anterior, se indica que si se trata de acceder hacia el subdirectorio /webmail 71
en el servidor, Apache deberá redirigir hacia http://mail.su­dominio.net/. El número 301 corresponde al mensaje del protocolo HTTP para indicar que la redirección es permanente. Si, por ejemplo, hubiese un objeto en /webmail, como /webmail/estadisticas.php, Apache realizará el re­direccionamiento transparente hacia:
http://mail.su­dominio.net/estadisticas/estadisticas.php. Para añadir algún tipo de extensión o tipo MIME, como TTF (TrueType Fonts), se debe generar un archivo, por ejemplo /etc/httpd/conf.d/extensiones.conf, con el siguiente contenido: AddType application/ttf .ttf AddDescription "TrueType2 Fonts" .ttf AddIcon /icons/a.png .ttf Soporte para CGI con extensión *.cgi Para reconocer la extensión *.cgi como un guión CGI (Common Gateway Interface), basta añadir un archivo, que denominaremos arbitrariamente /etc/httpd/conf.d/cgi.conf con el siguiente contenido: AddHandler cgi­script .cgi 3.3.2 Utilizando PHP y GD
PHP es un lenguaje de scripting embebido en HTML. Su sintaxis está tomada de C, JAVA y Perl, más características únicas y específicas. Su propósito es permitir crear a los desarrolladores páginas HTML generadas dinámicamente con rapidez. Los programas PHP se ejecutan en el lado del servidor. Está publicado bajo Licencia PHP, considerada una licencia de software libre por la FSF.
Para instalar PHP y las bibliotecas utilizadas se utiliza el siguiente comando en Ubuntu:
#sudo apt­get install libapache2­mod­php5 php5 php5­gd php5­snmp
La versión instalada es PHP 5, lanzada en 2004, utilizando el motor Zend Engine 2. Ésta versión tiene soporte para orientación a objetos, MySQL, XML, SQLite, SOAP, Iteradores de datos y manejo de excepciones. Utilizando la biblioteca de manejo de gráficas GD y la biblioteca de utilidades de cliente SNMP, es sencillo implementar una web dinámica para desplegar información del servidor SNMP. La figura 13 es una captura de la página web localizada en el servidor, que realiza una 72
petición snmpget para obtener la versión del MIB de UTMC (vmsMibSoftwareVersion) y despliega el mensaje actual desplegado en el VMS en una imagen .png, generada dinámicamente (displayText).
Figura 13: Información SNMP obtenida con el Webserver La función que añade el texto a partir de una fuente Truetype2 es:
imagefttext($image, $size, $angle, $px, $y,$color,$font,$string);
Donde $image es la referencia a la imagen desplegada, $size el tamaño de fuente, $angle el ángulo de despliegue (0 grados para desplegar de izquierda a derecha), $px y $py coordenadas del texto en la imagen a partir de la esquina inferior derecha, $color el color de la fuente y $string el string obtenido a partir de la llamada snmpget.
Para utilizar las bibliotecas GD y SNMP en PHP, no es necesario configurar el archivo php.ini (donde se añaden directivas para la ejecución), pero si es necesario reiniciar el servicio PHP y el servicio Apache.
Se adjunta en el anexo 4 el archivo index.php construido en esta implementación.
73
4 Discusión de resultados El objetivo principal de esta memoria de título es implementar una interfaz para desplegar información en letreros de mensajería variable, cumpliendo los requerimientos del estándar UTMC. Para lograr este objetivo, se utilizó una tarjeta embebida TS7200 que posee un procesador ARM9. Las ventajas de utilizar procesadores ARM para sistemas embebidos son su eficiencia, su bajo nivel de consumo y simplicidad de utilización.
Otra ventaja de la implementación realizada es el uso de PC104 como estándar de módulo embebido o form factor. El éxito en el mercado de la especificación PC104, se debe a que provee un balance entre los beneficios de tener grandes redes de módulos montados en rack, con la fácil integración de módulos múltiples sin necesidad de gabinetes pesados o complejos. La tarjeta TS7200 debe ser capaz de recibir peticiones de lectura y escritura de datos bajo el protocolo SNMP. Se comprobó que esto es factible: la información de un letrero en particular es almacenada en un archivo, el cual puede ser leído o escrito por cualquier letrero VMS conectado a la tarjeta, ya sea mediante un puerto serial (RS232 o RS485), Ethernet u otro protocolo de comunicación. Es sencillo extender los resultados para el caso de varias interfaces conectadas en una LAN con un servidor. Bastaría incluir cada dirección IP en distintas peticiones SNMP, todas bajo una misma comunidad. También es posible considerar varios letreros VMS conectados a una misma interfaz. Para ello, sería necesario considerar un script de shell y un archivo de información por cada letrero añadido; y un script general que discrimine por la ID del letrero en cuestión (definida por la variable SNMP VMS::signID).
En vez de utilizar un script de shell, el agente Net­SNMP podría ser extendido mediante el soporte para Perl embebido. Este soporte viene por defecto en las versiones 5.4.1 en adelante, y la versión de Net­SNMP utilizada en Debian es la 5.2.1. Versiones actualizadas de Debian (etch, lenny) incluyen versiones 5.4.1 o mayores y se pueden realizar las peticiones mediante scripts de Perl. Se debe considerar restricciones de memoria al incluir versiones más nuevas de Debian en la tarjeta TS7200. La ventaja de utilizar Perl en vez de un script de shell solo es en términos de simplicidad, pues todas las capacidades de lectura y escritura de datos en SNMP están disponibles actualmente en la implementación. Por otro lado, la restricción de capacidad de la Compact Flash también se puede superar y es recomendable utilizar una Compact Flash de mayor tamaño, al menos de 512 Mb. Ésto permitirá instalar versiones actualizadas de Debian, incluir soporte para Perl o añadir nuevos paquetes. Otra alternativa es utilizar un dispositivo diferente para almacenar el sistema de archivos. En 74
los manuales de la tarjeta TS7200 se explica como utilizar un dispositivo de almacenamiento USB. Se realiza invocando el script que carga los drivers USB en la tarjeta:
$ /usr/bin/loadUSBModules.sh Y paracargar los drivers en el Kernel se ejecuta el siguiente script:
$ /usr/bin/LoadUSB.sh
Las restricciones de esta alternativa son netamente de costos, ya que en un sistema donde existan varias tarjetas controlando letreros, añadir dispositivos de almacenamiento USB por cada una podría ser prohibitivo.
También se puede discutir la conveniencia de utilizar SNMP frente a otras alternativas. SNMP, por su amplia utilización en redes empresariales, es considerado el estándar de facto en detrimento del protocolo CMIP (Common Management Information Protocol), de la familia de protocolos OSI, más utilizado en las grandes redes de las operadoras de telecomunicación. Otra alternativa es utilizar software de gestión en la capa de de aplicación del modelo OSI o el nivel de información en el modelo NTCIP. Ésto implicaría comprar un software licenciado para la administración y envío de información entre los dispositivos y el sistema, lo cual no cumpliría con el estándar UTMC.
La principal ventaja de SNMP para los programadores de herramientas de gestión de red, es su sencillez frente a la complejidad inherente a CMIP. Por el lado del usuario de dichas herramientas, CMIP resuelve la mayor parte de las limitaciones de SNMP. Sin embargo, consume mayores recursos (alrededor de 10 veces más que SNMP), por lo tanto es poco utilizado en las redes de telecomunicación empresariales. Puesto que la consulta sistemática de los gestores es más habitual que la emisión espontánea de datos por parte de los agentes cuando surgen problemas, SNMP es un protocolo que consume un considerable ancho de banda, lo cual limita su utilización en entornos de red muy extendidos. Esto es una desventaja de SNMP respecto a CMIP, puesto que éste, al trabajar en modo conectado en vez de sondeo secuencial, permite optimizar el tráfico. SNMP, en su versión original, tampoco permite transferir eficientemente grandes cantidades de datos. No obstante, la limitación más importante de SNMP es que carece de autentificación, lo cual supone una alta vulnerabilidad en términos de seguridad, como por ejemplo: modificación de información, alteración de la secuencia de mensajes, enmascaramiento de la entidad emisora, etc. CMIP, por trabajar en modo conectado, ofrece una mayor seguridad que SNMP. La versión 3 de SNMP (SNMPv3) ofrece capacidades de identificación y encriptación.
Un objetivo secundario de este trabajo fue utilizar sólo herramientas de código abierto, bajo licencias admitidas por la FSF. El único código propietario en la implementación, es el primer sector de la memoria Flash OnBoard de la tarjeta TS7200 (128 Kb). Si bien esto impide 75
concretar el objetivo mencionado en un 100%, el costo del hardware propietario debe ser asumido de todas maneras, debiendo considerarse este sector de código como parte del costo de hardware. Actualmente el concepto de hardware libre es incipiente y sólo existen unas pocas tarjetas para requerimientos específicos. El enfoque tradicional es diseñar la tarjeta, lo que en este caso fue descartado por los altos costos de diseño y tiempo.
Por el lado del servidor, la solución de instalar un webserver utilizando Apache se explica con gran facilidad. Apache no sólo está disponible para sistemas Unix, también se puede instalar en un servidor Windows o Macintosh.
Apache tiene amplia aceptación en la red: desde 1996, Apache es el servidor HTTP más usado. Alcanzó su máxima cuota de mercado en 2005, siendo el servidor empleado en el 70% de los sitios web en el mundo. Sin embargo, ha sufrido un descenso en su cuota de mercado en los últimos años. (Estadísticas históricas y de uso diario proporcionadas por Netcraft [36]).
La mayoría de las vulnerabilidades de seguridad descubiertas y resueltas tan sólo pueden ser aprovechadas por usuarios locales y no remotamente. Sin embargo, algunas se pueden accionar remotamente en ciertas situaciones, o explotar por los usuarios locales malévolos en las disposiciones de recibimiento compartidas que utilizan PHP como módulo de Apache. Entre las alternativas, no existen muchas que logren compensar estas desventajas de Apache, frente a sus ventajas (disponibilidad sin costo, facilidad de configuración, disponibilidad de documentación extensa y comprobabilidad de funcionamiento).
Para estimar el costo de la implementación realizada, se considera el costo de la tarjeta TS7200, más 12 semanas de trabajo de un ingeniero. Esto se traduce en los siguientes valores:
●
Sueldo de un ingeniero civil: $1.283.613 [37].
●
Hora/hombre ingeniero estimada: $6.000 (obtenido en www.futurolaboral.cl).
●
Horas por semana: 30.
●
Costo Ingeniero: $2.340.000.
●
Dólar: $500.
●
Tarjeta TS7200: USD150.
Tabla 2: Costos de la implementación
Ítem
Costo ($)
Tarjeta TS7200
75000
Costo Ingeniero
2160000
Total
2235000
76
Agregando costos de infraestructura, servicio de Internet, computador y mantenimiento, los cuales son considerados como costos parciales, debido a que son aprovechables en trabajos posteriores y divisibles por la cantidad de personas que pueden aprovechar el mismo servicio, el costo estimado de este proyecto es de $2.500.000.
Existe en el mercado una amplia variedad de software licenciado para realizar desarrollo de implementaciones SNMP y webserver, cuyos valores dependen de los requerimientos del sistema, cantidad de licencias y características incluidas en los paquetes de software. Algunos ejemplos son:
●
SNMPc: Standalone Workgroup Edition. USD$1,795
●
/n software IP*Works! Secure SNMP ­ C++ Edition – V6.0 USD$1,234
●
PowerSNMP for .NET: Developer License with Free Subscription. USD$1,399
●
Abyss Webserver X2. USD$60
También se debe considerar el costo de las herramientas de desarrollo y el sistema operativo: ●
Sistema Operativo (Windows Vista Business): $92.255 (obtenido en www.wei.cl).
●
Sistema Operativo para la placa (Windows Embedded): USD$1,500.
●
C++ Builder: USD$2,500.
La estimación del costo asociado a un desarrollo utilizando software licenciado (aproximadamente USD$1,500), más el sistema operativo y el software de desarrollo ($2.100.00); considerando la mitad del tiempo requerido de horas de ingeniero, se puede observar en la tabla 3:
Tabla 3: Costos estimados usando Software Licenciado
Ítem
Costo ($)
Tarjeta (Embest CE S3C2410)
320000
Costo Ingeniero
1080000
Costo Software (SNMP+Webserver+Windows Embedded)
2100000
Costo Sist. Operativos + Entorno desarrollo
700000
Total
4200000
Por lo que se estima un costo de $4.500.000 incluyendo gastos adicionales. Por lo tanto, se puede obtener una idea comparativa al aplicar software libre en contraposición al tradicional software propietario, de un ahorro del 45%.
77
5 Conclusiones Se cumplió el objetivo principal de este trabajo, realizar una interfaz de un Sistema de Control de Tránsito bajo el estándar UTMC, para Letreros de Mensajería Variable VMS. Las pruebas de conexión, envío y recepción de datos, mediante el estándar SNMP, fueron exitosas. El Servidor logra establecer la comunicación mediante un webserver Apache, implementado con PHP. Esta interfaz fue realizada en un sistema embebido, utilizando una tarjeta TS7200 de Technologic Systems. El principal beneficio de utilizar un sistema embebido es su adaptabilidad a espacios reducidos y lugares de exterior, siempre que se ubiquen en cajas metálicas herméticas. Actualmente, las tarjetas embebidas están suficientemente estandarizadas para facilitar el desarrollo en ellas, aunque todavía lejos de los estándares de software y protocolos de comunicación. Otro objetivo del trabajo fue utilizar software de código abierto bajo el Sistema Operativo Linux. Los beneficios más importantes del software libre son la disminución de costo de desarrollo y posibilitar la observación de la implementación realizada por otros desarrolladores que a futuro investiguen éste y otros aspectos de los Sistemas de Control de Tránsito. Lo anterior permitirá facilitar los medios para que el conocimiento sea libre, público y eficaz en su propósito de mejorar el funcionamiento de los sistemas.
Para el trabajo futuro, se sugiere incluir SNMPv3 en la implementación, para obtener una mejor autentificación y posibilitar encriptación de datos. Otra alternativa para encriptar los datos es a nivel de hardware, es decir, enviar y recibir los datos encriptados debajo del protocolo SNMP . Ésto se puede lograr utilizando dispositivos de encriptación conectados a la interfaz, por ejemplo a través del puerto PC104 de la misma.
También se puede agregar mensajes de notificaciones utilizando el servicio snmptrapd de Net­SNMP. Ésto permite notificar fallas de conexión o fallas de sistema de los Letreros VMS.
Es posible generalizar esta interfaz para otros módulos de Sistemas de Control, como controladores de semáforos, cámaras de seguridad, contadores de vehículos u otros sistemas de tránsito. Para ésto, es necesario generalizar la interpretación de la base de datos MIB al archivo leído por el script que invoca el comando pass de Net­SNMP. Se recomienda utilizar Perl como lenguaje de scripting para este trabajo, por su simplicidad y extensibilidad.
Al integrar distintos elementos de control, monitoreo y comunicación en un Sistema de Control estandarizado, es posible lograr interacciones entre ellos, complementando la información que reciben del medio y generando procedimientos para manejar situaciones de manera eficiente y automática. Contar con interfaces adecuadas para lograr esta meta, permite ahorrar costos de desarrollo, de operación y de implementación. 78
6 Referencias [1] uoct, Unidad Operativa de Control de Tránsito, 2008, www.uoct.cl
[2] auter, Automática y Regulación S.A., 2006, www.auter.cl
[3] gob. de España, Direccion General de Tráfico de España, 2008, www.dgt.es/portal/es/la_dgt/historia/
[4] wikipedia.org, http://es.wikipedia.org/wiki/Ingeniería_de_telecomunicación, 2008, es.wikipedia.org
[5] Hubert Zimmerman, OSI Reference Model, 1980
[6] U.S. Department of Energy, Solid­State Lighting: LED Basics, 2008, www.netl.doe.gov
[7] Victor Grimblatt H., Apuntes de EL65P: Sistemas Embebidos ­ Otoño, 2005
[8] EIA, EIA Standard RS­232­C, 1985
[9] ByB Electronics Ltd., RS485 Basics, 2008, www.bb­
elec.com/tech_articles/rs485_basics.asp
[10] Motorola, Motorola MC68HC11 Reference Manual, 1989
[11] NXP, NXP I2C rev 08 specification, 2007
[12] USB Implementers Forum, Inc., Universal Serial Bus Revision 2.0 specification, 2008, www.usb.org/developers/docs/usb_20_040908.zip
[13] Internet Protocol DARPA Internet Program Protocol Specification, 1981, RFC 791
[14] LinuxDevices.com Staff, A Linux­oriented Intro to Embeddable Single Board, 2005, www.linuxdevices.com/articles/AT6449817972.html
[15] Teleport, FlexATX Addendum to the microATX Specification v1.0, 1999
[16] Advanced Micro Devices Inc., DTX Specification, 2007, www.dtxpc.org
[17] PicMG, Directory of Specifications, 2008, http://www.picmg.org/v2internal/specifications.htm
[18] Technologic Systems, Technologic Systems Homepage, 2008, www.embeddedarm.com
[19] IEEE, Intelligent Transportation Systems Society, 2008, www.ewh.ieee.org/tc/its/
[20] UTMC, Página oficial de UTMC, 2006, www.utmc.uk.com
[21] UTMC, UTMC Framework Technical Specification., 2005
[22] UTMC, UTMC Object Registry, 2005
[23] The HighWays Agence, Code of Practice for Traffic Control And Information Systems, 2006
[24] S Jones, M Hallworth and K Fox, State of the Art and User Needs for Selected Vehicle Priority, 1998
[25] UTMC, UTMC 07/17 DELIVERABLE 4: TECHNICAL REPORT, 2007
[26] David Kamnitzer, Applicability of NTCIP Based Communications for UK UTMC, 2000
[27] DfT, Department for Transport ­ Demostrators, 2006, www.dft.gov.uk
[28] Ramon Jesus Millan Tejedor, SNMPv3 (Simple Network Management Protocol version 3), 2003
79
[29] ITU, Abstract SyntaxNotation One (ASN.1): Specification of basic notation, 2002
[30] FSF, The Free Software Foundation, 2008, www.fsf.org
[31] IEEE, The Open Group ­ Making Standards Work, 2008, www.opengroup.org/
[32] Linux Online Inc., The Linux Operating System, 2008, www.linux.org
[33] NET­SNMP, Net­SNMP Homepage, 2007, www.net­snmp.org
[34] GNU, Compilación de Compiladores de GNU, 2008, gcc.gnu.org
[35] David Woodhouse, JFFS: The Journalling Flash File System, 2002
[36] NetCraft Ltd., Internet Research, Anti­Phishing and PCI, 2008, http://news.netcraft.com/
[37] Universia, Universia, 2008, www.universia.cl
[38] ARM Limited, ARM Information Center, 2007, infocenter.arm.com/help/index.jsp
80
7 Glosario Apache........................................................................................................ii, 45, 61, 71 ss., 76
API..........................................................................................................................................47
ARM..................................................................................ii, 16 s., 22, 24, 41, 53, 56, 74, 88 s.
ATX.....................................................................................................................................20 s.
AUTER......................................................................................................................................6
awk....................................................................................................................................39, 70
BIOS.......................................................................................................................................19
C....................................................................................23, 25, 38 s., 46, 48, 50, 60 ss., 64, 72
caché................................................................................................................18, 24, 47, 88 s.
CAN........................................................................................................................................14
CISC.......................................................................................................................................16
Compact..............................................................................................23 ss., 50, 61, 64 ss., 74
C++.......................................................................................................................38, 48, 50, 61
81
CPU.................................................................................................................16, 18 ss., 24, 26
Debian...............................................................................................ii, 41 s., 45, 61 ss., 71, 74
DSP.............................................................................................................................13, 23, 89
Ethernet..........................................................................................................15, 23, 25, 38, 50
EXT2.........................................................................................................................24 s., 64 s.
Flash................................................................................23 ss., 50, 55 ss., 60 s., 64 ss., 74 s.
FPGA......................................................................................................................................13
FTP...........................................................................................................32, 50, 55 ss., 59, 61
GD.......................................................................................................................................72 s.
GNU..............................................................................................................38 s., 41 s., 48, 61
GPL...............................................................................................................................38 s., 42
GSM........................................................................................................................................14
HTML...................................................................................................................................ii, 72
HTTP....................................................................................................................45, 61, 72, 76
I²C...........................................................................................................................................14
IBM..............................................................................................................................14, 20, 88
IEEE............................................................................................................................21, 26, 39
82
Intel.......................................................................................................14, 16, 20, 23 s., 41, 88
IP.....................................................................................14 s., 29, 32, 34, 38, 59 s., 63, 68, 74
ISA................................................................................................................................19, 21 s.
ITS.......................................................................................................................ii, 26 s., 31, 33
JAVA...........................................................................................................................38, 72, 89
JFFS2....................................................................................................................24, 55 ss., 60
Kernel....................................................................................................................24, 39, 52 ss.
LAN...................................................................................................................................19, 74
LCD.............................................................................................................................15, 25, 50
LED.........................................................................................................................ii, 11, 15, 25
Linux.....................................................ii, 20, 22 ss., 38 s., 41 s., 44 s., 48, 50 s., 55 s., 60 ss.
MFD....................................................................................................................................46 s.
MIB....................................................................................................35 ss., 46 s., 67 s., 70, 73
Motorola......................................................................................................................14, 16, 88
NFS.............................................................................................................24, 50 s., 55, 61 ss.
NTCIP..........................................................................................................................31 ss., 44
83
NTP.........................................................................................................................................65
OID................................................................................................................................67, 69 s.
OMG.......................................................................................................................................27
OnBoard..................................................................................................................55, 57 s., 60
OSI..................................................................................................................10, 15, 31, 34, 75
PC.............................................................................19 ss., 25, 41, 45, 50 s., 59, 62 s., 65, 88
PC104...........................................................................................................................21 s., 65
PCI..........................................................................................................................19, 21 s., 41
Perl.................................................................................................................46, 61, 70, 72, 74
Phillips.....................................................................................................................................14
PHP...........................................................................................................................ii, 72 s., 76
PLL..........................................................................................................................................15
POSIX.................................................................................................................................39 s.
RAM............................................................................................................................19, 24, 50
RedBoot................................................................................................................24, 53, 55 ss.
RedHat..........................................................................................................................41 s., 56
84
RFC...................................................................................................................................37, 68
RISC.................................................................................................................................16, 88
ROM............................................................................................................................19, 24, 50
RS232.........................................................................................................................14, 51, 74
RS485.........................................................................................................................14, 25, 74
SBC.........................................................................................................................ii, 20, 22, 45
SNMP...................................................................ii, 32, 34 ss., 44 ss., 48, 50, 66 s., 70, 72 ss.
SPARC....................................................................................................................................16
SPI..........................................................................................................................................14
TCP.................................................................................................................15, 29, 32, 34, 55
TS7200...........................................................ii, 22 s., 25, 45, 48, 50 ss., 55 ss., 63 ss., 74 ss.
Ubuntu.................................................................................................................ii, 42, 63, 71 s.
UDP......................................................................................................................29, 32, 34, 38
Unix...........................................................................................................34, 38 ss., 45, 55, 76
UOCT........................................................................................................................................6
USB..........................................................................................14, 21, 23, 25, 50, 54, 65 s., 75
85
UTC...................................................................................................................................33, 38
UTMC.......................................... s., 6, 8, 10, 26 ss., 33 s., 37 s., 44 s., 48, 50, 53, 68, 73 ss.
UTMC,.....................................................................................................................................78
VACM......................................................................................................................................68
GPRS......................................................................................................................................14
VMS..................................................................................................ii, 6, 11, 33, 38, 45, 48, 74
86
8 Anexos 8.1 El Microprocesador ARM
Se denomina ARM a una familia de microprocesadores RISC diseñados por Acorn Computers y desarrollados por Advanced RISC Machines Ltd., una empresa derivada de la anterior. [38]
El diseño del ARM comenzó en 1983 como un proyecto de desarrollo en la empresa Acorn Computers Ltd. cuya meta era el desarrollo de un procesador avanzado, pero con una arquitectura similar a la del 6502 de MOS Technology. El equipo terminó el diseño preliminar y los primeros prototipos del procesador en el año 1985, al que llamaron ARM1. La primera versión utilizada comercialmente se bautizó como ARM2 y se lanzó en el año 1986.
La arquitectura del ARM2 posee un bus de datos de 32 bits y ofrece un espacio de direcciones de 26 bits, junto con 16 registros de 32 bits. Uno de estos registros se utiliza como contador de programa, aprovechándose sus 4 bits superiores y los 2 inferiores para contener los flags de estado del procesador. Su sucesor, el ARM3, incluye una pequeña memoria caché de 4 KB, lo que mejora los accesos a memoria repetitivos.
A finales de los años 80, Acorn decidió crear una nueva compañía llamada Advanced RISC Machines, que sería la encargada del diseño y gestión de las nuevas generaciones de procesadores ARM. Este trabajo derivó en el ARM6, presentado en 1991. Apple utilizó el ARM 610 (basado en el ARM6), como procesador básico para su innovador PDA, el Apple Newton. Por su parte, Acorn lo utilizó en 1994 como procesador principal en su RISC PC.
La mayor utilización de la tecnología ARM se alcanzó con el procesador ARM7TDMI, con millones de unidades en teléfonos móviles y sistemas de videojuegos portátiles.
DEC licenció el diseño, lo cual generó algo de confusión debido a que ya producía el DEC Alpha, y creó el StrongARM. Con una velocidad de reloj de 233 MHz, este procesador consumía solo 1 watt de potencia (este consumo de energía se ha reducido en versiones más recientes). Esta tecnología pasó posteriormente a manos de Intel, como fruto de un acuerdo jurídico, que la integró en su línea de procesadores Intel i960 e hizo más ardua la competencia.
Freescale (una empresa que derivó de Motorola en el año 2004), IBM, Infineon Technologies, OKI, Texas Instruments, Nintendo, Philips, VLSI, Atmel, Sharp, Samsung y STMicroelectronics también licenciaron el diseño básico del ARM.
El diseño del ARM se ha convertido en uno de los más usados del mundo, desde discos duros hasta juguetes. Hoy en día, cerca del 75% de los procesadores de 32 bits poseen este chip en su núcleo.
87
La distintas versiones de procesadores ARM son las siguientes:
●
ARM1: con arquitectura ARMv1. Sólo experimental.
●
ARM2: en versiones ARMv2 (4 MIPS @ 8 MHz) y ARMv2a (7 MIPS @ 12 Mhz)
●
ARM3: similar a ARM2 pero con 4 Kb de caché.
●
ARM6: con arquitectura ARMv3. En versiones ARM60, ARM 600 y ARM 610 (17 MIPS @ 20 Mhz).
●
ARM7: con arquitectura ARMv4 en versiones ARM7TDMI, ARM710T, ARM720T, ARM740T (60 MIPS @ 59,8 Mhz). También con arquitectura ARMv5tej con instrucciones para DSP.
●
StrongARM: con arquitectura ARMv4 en versiones SA­110 y SA­1110 (233 Mhz)
●
ARM8: Arquitectura ARMv4, versión ARM810 (84 MIPS @ 72 Mhz)
●
ARM9TDMI: Arquitectura ARMv4T, versiones ARM9TDMI, ARM920T (200 MIPS @ 180 MHz) , ARM922T, ARM940T. La T se refiere a la tecnología Thumb, de instrucciones de 16 bits.
●
ARM9E: Con arquitectura ARMv5TE y ARMv5TEJ (soporte para JAVA)
●
Xscale: Arquitectura ARMv5TE, 18 versiones, la versión Mohanans tiene 1000 MIPS @ 1.25 Ghz
●
ARM11: Arquitecturas ARMv6, ARMv6T2, ARMv6KZ y ARMv6K.
●
Cortex: Arquitecturas ARMv7A, ARMv7R y ARMv7M. 8.2 Archivo Y1­01017­v2.txt (Cabecera MIB UTMC)
UTMC­Header­MIB DEFINITIONS ::= BEGIN ­­ Y1­01017.txt ­­ Revision: 1.05 ­­ Product No: UTMC Header MIB ­­ Date: 22/2/2005 ­­ Written: Robin Jefferson ­­ Revision History ­­ V1.00 13/5/2002 First Issue RLJ ­­ V1.01 24/5/2002 Car Parks sub­branch added RLJ ­­ V1.02 15/12/2004 Rising Bollard sub­branch 88
added RLJ ­­ V1.03 18/2/2005 Add Common definitions RLJ ­­ V1.05 22/2/2005 Modify True/False, Add Time format RLJ ­­ City of York Council ­­ 9 St Leonard's Place ­­ York ­­ YO1 7ET ­­ Tel +44 1904 551372 ­­ Fax +44 1904 551412 ­­ Maintained by ­­ Integrated Design Techniques Ltd ­­ Endurance House ­­ Seventh Avenue ­­ Team Valley ­­ Tyne & Wear ­­ NE11 0EF ­­ Tel +44 191 491 0800 ­­ Fax +44 191 491 0799 ­­ email: [email protected] ­­ This module provides definitions and registration points for ­­ City of York Council's UTMC compliant outstations ­­ City of York Council reserve the right to make changes in this specification ­­ and other information contained in this document without ­­ prior notice. In no event shall City of York Council be liable for any ­­ incidental, indirect, special or consequential damages arising out of, or ­­ related to the use of this document or the information contained in it. ­­ City of York Council grant vendors and end­users a non­
89
exclusive ­­ licence to use this specification in the connection with management ­­ of UTMC compliant outstations. ­­ Copyright City of York Council 2002 ­­ Defined OIDs from RFC1155­SMI ­­ ccitt OBJECT IDENTIFIER ::= { 0 } null OBJECT IDENTIFIER ::= { ccitt 0 } ­­ iso OBJECT IDENTIFIER ::= { 1 } org OBJECT IDENTIFIER ::= { iso 3 } dod OBJECT IDENTIFIER ::= { org 6 } internet OBJECT IDENTIFIER ::= { dod 1 } directory OBJECT IDENTIFIER ::= { internet 1 } mgmt OBJECT IDENTIFIER ::= { internet 2 } experimental OBJECT IDENTIFIER ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT IDENTIFIER ::= { private 1 } ­­ Mod V1.03 ­ Add common definitions DisplayString ::= OCTET STRING ­­ This data type is defined to support textual information using ­­ the ASCII character set. By convention, objects declared with this ­­ syntax, unless otherwise specified are declared as having: ­­ ­­ SIZE (0..255) TruthValue ::= INTEGER{true (1), false (2)} UTMCTime ::= DisplayString (SIZE(13)) ­­ This object sets or returns the current time as YYMMDDHHmmssZ. Z indicates zulu or GMT ­­ CoYC UTMC OID utmc OBJECT IDENTIFIER ::= { enterprises 13267 } 90
­­ UTMC sub­branches ­ Registration points ­­ Air Quality utmcAirQualityMonitor OBJECT IDENTIFIER ::= { utmc 1} utmcAirQualType1 OBJECT IDENTIFIER ::= { utmcAirQualityMonitor 1} ­­ Dial Up UTC utmcDialUpUTC OBJECT IDENTIFIER ::= { utmc 2} utmcDialUpUTCType1 OBJECT IDENTIFIER ::= { utmcDialUpUTC 1} ­­ Full UTC utmcFullUTC OBJECT IDENTIFIER ::= { utmc 3} utmcFullUTCType1 OBJECT IDENTIFIER ::= { utmcFullUTC 1} ­­ Simple UTC utmcSimpleUTC OBJECT IDENTIFIER ::= { utmc 4} utmcSimpleUTCType1 OBJECT IDENTIFIER ::= { utmcSimpleUTC 1} ­­ Traffic Counter utmcTrafficCounter OBJECT IDENTIFIER ::= { utmc 5} utmcTrafficCounterType1 { utmcTrafficCounter 1} OBJECT IDENTIFIER ::= ­­ VMS utmcVMS OBJECT IDENTIFIER ::= { utmc 6} utmcVMSType1 OBJECT IDENTIFIER ::= { utmcVMS 1} ­­ Car Parks utmcCarParks OBJECT IDENTIFIER ::= { utmc 7} utmcCarParksType1 OBJECT IDENTIFIER ::= { utmcCarParks 1} ­­ Rising Bollard utmcRisingBollard OBJECT IDENTIFIER ::= { utmc 8} utmcRisingBollardType1 { utmcRisingBollard 1} END 91
OBJECT IDENTIFIER ::= 8.3 Archivo VMSUTMC.MIB
­­IDENTIFICATION ­­ Module : VMSUTMC.mib ­­ Version : V3.01 ­­ Author : A Kipling ­­ Date : 25/01/2005 ­­ ­­ Function: ­­ For the control and management of Variable Message Signs via the SNMP Protocol ­­ ­­ VMS object definitions MIB ­­ ­­ Variable Message Signs Limited ­­ Unit 1, ­­ Monkton Business Park North, ­­ Mill Lane, ­­ Hebburn, ­­ Tyne & Wear ­­ NE31 2JZ, ­­ United Kingdom ­­ ­­ Modified 06/06/2002 to include CoYC Header File ­ ALK ­­ Modified 29/10/2002 ­ updated descriptiond of objects ­ ALK ­­ Modified 29/10/2002 ­ Changed ACCESS on msgTime and statusTime to READ only ­­ Modified 29/10/2002 ­ added vmsSetTime and vmsPort objects. ­­ Modified 31/07/2003 ­ added vmsCommsCheckStatus node ­­ Modified 31/07/2003 ­ added ­­ vmsCommsCheckcoms,vmsCheckTimer,vmsBlankOnFault,vmsTimeOut,trapExtcom
92
ms ­­ Modified 25/01/2005 ­ TruthTable Definition has been removed and added to the header.mib ­­ Modified 25/01/2005 ­ Updated description on vmsMibSoftwareVersion, vmsMaxHeight, ­­ vmsMaxWidth, vmsMaxFontSpacing ­­ Modified 25/01/2005 ­ Updated description on vmsMaxFontHeight, vmsMaxFontWidth, ­­ vmsMinHeight, vmsMinWidth ­­ Modified 25/01/2005 ­ Updated description on vmsMinFontSpacing, vmsMinFontHeight, ­­ vmsMinFontWidth ­­ Modified 25/01/2005 ­ Updated description on signID, vmsPassword, signType, vmsConfigTime, ­­ vmsHeight, vmsWidth ­­ Modified 25/01/2005 ­ Updated description on vmsFontSpacing, vmsFontHeight, vmsFontWidth ­­ Modified 25/01/2005 ­ Updated description on vmsReturnIpAddress, vmsLogIn, vmsSetTime, ­­ vmsPort, displayText ­­ Modified 25/01/2005 ­ Updated description on msgTime, vmsLuminanceOverride, vmsLuminance, ­­ statusTime ­­ Modified 25/01/2005 ­ faultDescription, numberFaults objects added to the vmsFaultStatus node. ­­ Modified 25/01/2005 ­ Updated description on vmsCommsCheck, vmsCheckTimer, ­­ Modified 25/01/2005 ­ faultChange TRAP added. ­­ ­­
=====================================================================
= ­­VARIABLE MESSAGE SIGNS (VMS) OBJECTS VMS DEFINITIONS ::= BEGIN IMPORTS 93
FROM RFC­1215 TRAP­TYPE OBJECT­TYPE FROM RFC­1212 IpAddress, enterprises FROM RFC1155­SMI utmc, utmcVMS, utmcVMSType1, TruthTable FROM UTMC­Header­MIB; ­­For the purpose of this section, the following OBJECT IDENTIFIERS are used: ­­the node location is: private/enterprises/utmc/utmcVMS/utmcVMSType1 sysInfo OBJECT IDENTIFIER ::={ utmcVMSType1 1 } ­­This node is used to define the limits in which the VMS has to operate within. vmsMibSoftwareVersion OBJECT­TYPE SYNTAX OCTET STRING (SIZE (0..255)) ACCESS read­only STATUS mandatory DESCRIPTION "The current MIB version being used by the vms. Version 3.01 will be stored as 'v3.01'" ::= {sysInfo 1} vmsMaxHeight OBJECT­TYPE SYNTAX INTEGER (0..100) ACCESS read­only STATUS mandatory DESCRIPTION "This object holds the maximum number of rows the VMS sign can display. if the object is not used a default value of 0 (zero) should be entered." ::= {sysInfo 2} vmsMaxWidth OBJECT­TYPE SYNTAX INTEGER (0..100) ACCESS read­only 94
STATUS mandatory DESCRIPTION "This object holds the maximum number of characters the VMS sign can display per line. if the object is not used a default value of 0 (zero) should be entered." ::= {sysInfo 3} vmsMaxFontSpacing OBJECT­TYPE SYNTAX INTEGER (0..100) ACCESS read­only STATUS mandatory DESCRIPTION "This object holds the maximum value of the font spacing (in pixels) allowed on the VMS sign. if the object is not used a default value of 0 (zero) should be entered." ::= {sysInfo 4} vmsMaxFontHeight OBJECT­TYPE SYNTAX INTEGER (0..100) ACCESS read­only STATUS mandatory DESCRIPTION "This object holds the maximum font height (in pixels) the VMS sign can display. if the object is not used a default value of 0 (zero) should be entered." ::= {sysInfo 5} vmsMaxFontWidth OBJECT­TYPE SYNTAX INTEGER (0..100) ACCESS read­only STATUS mandatory DESCRIPTION "This object holds the maximum font width (in pixels) the VMS sign can display. if the object is not used a default value of 0 95
(zero) should be entered." ::= {sysInfo 6} vmsLanternsPresent OBJECT­TYPE SYNTAX TruthTable ACCESS read­only STATUS mandatory DESCRIPTION "Does the sign have 'Flashing Lanterns?', 1=True, 2=False" ::= {sysInfo 7} vmsMinHeight OBJECT­TYPE SYNTAX INTEGER (0..100) ACCESS read­only STATUS mandatory DESCRIPTION "This object holds the minimum number of rows the VMS sign can support. if the object is not used a default value of 0 (zero) should be entered." ::= {sysInfo 8} vmsMinWidth OBJECT­TYPE SYNTAX INTEGER (0..100) ACCESS read­only STATUS mandatory DESCRIPTION "This object holds the minimum number of characters the VMS sign can support per row. if the object is not used a default value of 0 (zero) should be entered." ::= {sysInfo 9} vmsMinFontSpacing OBJECT­TYPE SYNTAX INTEGER (0..100) ACCESS read­only STATUS mandatory DESCRIPTION "This object holds the minimum value of the font 96
spacing (in pixels) allowed on the VMS sign. if the object is not used a default value of 0 (zero) should be entered." ::= {sysInfo 10} vmsMinFontHeight OBJECT­TYPE SYNTAX INTEGER (0..100) ACCESS read­only STATUS mandatory DESCRIPTION "This object holds the minimum font height (in pixels) the VMS sign can display. if the object is not used a default value of 0 (zero) should be entered." ::= {sysInfo 11} vmsMinFontWidth OBJECT­TYPE SYNTAX INTEGER (0..100) ACCESS read­only STATUS mandatory DESCRIPTION "This object holds the minimum font width (in pixels) the VMS sign can display. if the object is not used a default value of 0 (zero) should be entered." ::= {sysInfo 12} sysConfig OBJECT IDENTIFIER ::={ utmcVMSType1 2 } ­­This node is used to give the current settings of the VMS. signID OBJECT­TYPE SYNTAX INTEGER (0..255) ACCESS read­write STATUS mandatory DESCRIPTION "the Unique ID of the VMS. if the object is not used a default value of 0 (zero) should be entered." ::= {sysConfig 1} 97
vmsPassword OBJECT­TYPE SYNTAX OCTET STRING (SIZE (0..50)) ACCESS read­write STATUS mandatory DESCRIPTION "The current Password must be given to allow the sign to be used. A NULL string will be used to indicate that no password is required to log onto the system. The use of 'logoff' is to be prevented as this is used to log the user off from the system." ::= {sysConfig 2} signType OBJECT­TYPE SYNTAX OCTET STRING (SIZE(0..255)) ACCESS read­write STATUS mandatory DESCRIPTION "Textual Description of the sign type currently been used. If this object is not used a default NULL string will be entered" ::= {sysConfig 3} vmsLanterns OBJECT­TYPE SYNTAX TruthTable ACCESS read­write STATUS mandatory DESCRIPTION "Indicates if any lanterns present are available for use on this VMS" ::= {sysConfig 4} vmsConfigTime OBJECT­TYPE SYNTAX OCTET STRING (SIZE (11)) ACCESS read­only STATUS mandatory 98
DESCRIPTION "Displays the time of the current config settings. The Format is YYMMDDHHmmZ where Z represents GMT Timezone. If this object is not used a default value of '0000000000Z' is to be entered." ::= {sysConfig 5} vmsHeight OBJECT­TYPE SYNTAX INTEGER (0..100) ACCESS read­write STATUS mandatory DESCRIPTION "Indicates the maximum number of rows available for message display (eg 4). If this object is not used a default value of 0 (zero) is to be entered." ::= {sysConfig 6} vmsWidth OBJECT­TYPE SYNTAX INTEGER (0..100) ACCESS read­write STATUS mandatory DESCRIPTION "Indicates the maximum number of characters per line (eg 15). If this object is not used a default value of 0 (zero) is to be entered." ::= {sysConfig 7} vmsFontSpacing OBJECT­TYPE SYNTAX INTEGER (0..100) ACCESS read­write STATUS mandatory DESCRIPTION "Number of pixels between characters (eg 2). If this object is not used a default value of 0 (zero) is to be 99
entered." ::= {sysConfig 8} vmsFontHeight OBJECT­TYPE SYNTAX INTEGER (0..100) ACCESS read­write STATUS mandatory DESCRIPTION "The height of the vms font in pixels (eg 5). If this object is not used a default value of 0 (zero) is to be entered." ::= {sysConfig 9} vmsFontWidth OBJECT­TYPE SYNTAX INTEGER(0..100) ACCESS read­write STATUS mandatory DESCRIPTION "The width of the vms font in pixels (eg 7). If this object is not used a default value of 0 (zero) is to be entered." ::= {sysConfig 10} vmsReturnIpAddress OBJECT­TYPE SYNTAX IpAddress ACCESS read­write STATUS mandatory DESCRIPTION "This object holds the IP Address to which traps are returned. If the object is invalid or 0.0.0.0 (default value) then traps are returned to the IP Address of the manager which last made a SET or GET request" ::= {sysConfig 11} vmsLogIn OBJECT­TYPE SYNTAX OCTET STRING (SIZE(0..50)) 100
ACCESS read­write STATUS mandatory DESCRIPTION "This object is written to in order to log onto the vms, the value written into here is compared the vmsPassword object. A value of 'logoff' is used to log the user off. The default value for this object is a NULL string. If access to any of the MIB objects does not occur within a 2 minute period any active user will be automatically logged off. All Passwords are case sensitive." ::= {sysConfig 12} vmsSetTime OBJECT­TYPE SYNTAX OCTET STRING (SIZE(11)) ACCESS read­write STATUS mandatory DESCRIPTION "This object is used to write the current system into, it allows the VMS internal clock to be update with this system time Format is YYMMDDHHmmZ where Z represents GMT Timezone. The default value of this object will be '0000000000Z'. When the time has been updated this object should return to its default value." ::= {sysConfig 13} vmsPort OBJECT­TYPE SYNTAX INTEGER ACCESS read­write STATUS mandatory 101
DESCRIPTION "This object holds the Port number to which traps are returned. If the object is 0 (zero) then traps are returned to the local port of the manager which last made a SET or GET request. The default value for this object will be 0 (zero)." ::= {sysConfig 14} vmsDisplayConfig OBJECT IDENTIFIER ::={utmcVMSType1 3} ­­ This Node is used to group all the objects for the VMS sign displayed messages. messageTable OBJECT­TYPE SYNTAX SEQUENCE OF MessageTableEntry ACCESS not­accessible STATUS mandatory DESCRIPTION "This table holds the currently displayed messaged" ::= {vmsDisplayConfig 1} messageTableEntry OBJECT­TYPE SYNTAX MessageTableEntry ACCESS not­accessible STATUS mandatory DESCRIPTION "parameters of the Message List Table" INDEX {messageLineID} ::= {messageTable 1} MessageTableEntry ::= SEQUENCE { messageLineID INTEGER, displayText OCTET STRING} messageLineID OBJECT­TYPE SYNTAX INTEGER (0..100) ACCESS read­write STATUS mandatory DESCRIPTION "Indicates the line number of the Message to display" 102
::= {messageTableEntry 1} displayText OBJECT­TYPE SYNTAX OCTET STRING (SIZE(0..100)) ACCESS read­write STATUS mandatory DESCRIPTION "The contents of the line to be displayed. If a new display request is recieved by the VMS (and it is valid) the previous message is to be cleared from the table and the the VMS display will be updated accordingly" ::= {messageTableEntry 2} lanternsOnOff OBJECT­TYPE SYNTAX TruthTable ACCESS read­write STATUS mandatory DESCRIPTION "Indicates if the lanterns are turned On or Off for the currently displayed message" ::= {vmsDisplayConfig 2} msgTime OBJECT­TYPE SYNTAX OCTET STRING (SIZE(11)) ACCESS read­only STATUS mandatory DESCRIPTION "Time at which current displayed message was set. The Format is YYMMDDHHmmZ where Z represents GMT Timezone. The default value for this object is '0000000000Z'." ::= {vmsDisplayConfig 3} vmsLuminanceOverride OBJECT­TYPE SYNTAX TruthTable ACCESS read­write STATUS mandatory 103
DESCRIPTION "This is set to 'True' if the luminance level is to be set by the operator and not by the sign. This object MUST be set to 'True' in a previous packet before you can update the vmsLuminance obect." ::= {vmsDisplayConfig 4} vmsLuminance OBJECT­TYPE SYNTAX INTEGER(0..15) ACCESS read­write STATUS mandatory DESCRIPTION "Indicates the current luminance level of the vms, 0 (zero) is the lowest setting, 15 is the highest setting. vmsLuminanceOverride MUST be set to 'True' in an earlier SNMP packet before this object will accept updates. When the vmsLuminanceOverride object is set to 'True' this object should be updated to hold the default of 7 (the midway point in the luminance levels)." ::= {vmsDisplayConfig 5} vmsFaultStatus OBJECT IDENTIFIER ::={utmcVMSType1 4} ­­ Holds all the current vms faults to be reported back to the instation faultStatus OBJECT­TYPE SYNTAX TruthTable ACCESS read­only STATUS mandatory DESCRIPTION "Indicates if the vms currently has a fault present" 104
::= {vmsFaultStatus 1} statusTime OBJECT­TYPE SYNTAX OCTET STRING (SIZE(11)) ACCESS read­only STATUS mandatory DESCRIPTION "Time at which status information was last requested he Format is YYMMDDHHmmZ where Z represents GMT Timezone. If this object is not used a default value of '0000000000Z' is to be entered." ::= {vmsFaultStatus 2} internalCommsStatus OBJECT­TYPE SYNTAX TruthTable ACCESS read­only STATUS mandatory DESCRIPTION "Indicates an internal comms failure within the VMS" ::= {vmsFaultStatus 3} messageFail OBJECT­TYPE SYNTAX TruthTable ACCESS read­only STATUS mandatory DESCRIPTION "Indicates message fail/watchdog reset error" ::= {vmsFaultStatus 4} ledFailNonCritical OBJECT­TYPE SYNTAX TruthTable ACCESS read­only STATUS mandatory DESCRIPTION "Indicates a single led failure in the vms display modules" ::= {vmsFaultStatus 5} 105
ledFailCritical OBJECT­TYPE SYNTAX TruthTable ACCESS read­only STATUS mandatory DESCRIPTION "Indicates multiple led failures on the vms display modules" ::= {vmsFaultStatus 6} heaterFail OBJECT­TYPE SYNTAX TruthTable ACCESS read­only STATUS mandatory DESCRIPTION "Indicates a heater fail within the vms unit" ::= {vmsFaultStatus 7} watchDogReset OBJECT­TYPE SYNTAX TruthTable ACCESS read­only STATUS mandatory DESCRIPTION "Indicates a watchdog reset on the vms" ::= {vmsFaultStatus 8} overTemperature OBJECT­TYPE SYNTAX TruthTable ACCESS read­only STATUS mandatory DESCRIPTION "Indicates an overtemperature in the vms enclosure" ::= {vmsFaultStatus 9} luminanceFail OBJECT­TYPE SYNTAX TruthTable ACCESS read­only STATUS mandatory DESCRIPTION "Indicates a luminance fail in the vms" ::= {vmsFaultStatus 10} 106
lanternFail OBJECT­TYPE SYNTAX TruthTable ACCESS read­only STATUS mandatory DESCRIPTION "Indicates a lantern failure on the vms" ::= {vmsFaultStatus 11} invalidSignAddress OBJECT­TYPE SYNTAX TruthTable ACCESS read­only STATUS mandatory DESCRIPTION "This object is set to 1 (true) if a received signID value is greater than 255d. The object will be cleared automatically when a valid signID is received" ::= {vmsFaultStatus 12} configError OBJECT­TYPE SYNTAX TruthTable ACCESS read­only STATUS mandatory DESCRIPTION "This will object is set to 1 (true) if an invalid config is requested to be set" ::= {vmsFaultStatus 13} powerFail OBJECT­TYPE SYNTAX TruthTable ACCESS read­only STATUS mandatory DESCRIPTION "This object is set to 1 (true) if a power fail is detected on the VMS" ::= {vmsFaultStatus 14} noConfigFile OBJECT­TYPE SYNTAX TruthTable ACCESS read­only 107
STATUS mandatory DESCRIPTION "Object set to 1 (true) if the configuration file cannot be located. Will only be used during startup of VMS and will not be cleared during normal operation. This has no use if the config file method of loading parameters is not used." ::= {vmsFaultStatus 15} noSysInfoFile OBJECT­TYPE SYNTAX TruthTable ACCESS read­only STATUS mandatory DESCRIPTION "Object set to 1 (true) if the System Info file cannot be located. Will only be used during startup of VMS and will not be cleared during normal operation. This has no use if the sysinfo file method of loading parameters is not used." ::= {vmsFaultStatus 16} noSignID OBJECT­TYPE SYNTAX TruthTable ACCESS read­only STATUS mandatory DESCRIPTION "This object is to be used with the signID object." ::= {vmsFaultStatus 17} vmsExternalCommsFault OBJECT­TYPE SYNTAX TruthTable ACCESS read­only STATUS mandatory DESCRIPTION "Indicates a comms failure to the Instation. Once set the 108
vmsCommsCheckStatus node is disabled. Comms can only be re­instated by the Instation or a local connection." ::= {vmsFaultStatus 18} faultDescription OBJECT­TYPE SYNTAX OCTET STRING (SIZE(0..255)) ACCESS read­only STATUS optional DESCRIPTION "A maunfacturer specific text string used to supply a 'user­friendly' description of any faults present on the VMS." ::= {vmsFaultStatus 19} numberFaults OBJECT­TYPE SYNTAX INTEGER ACCESS read­only STATUS mandatory DESCRIPTION "The total number of faults present on the VMS. This is used to generate faultChange TRAP. whenever value of this objects changes a the faultChange TRAP will be raised. If this object is not used a default value of 0 (zero) will be returned (this will also disable the trapFaultChange TRAP)." ::= {vmsFaultStatus 20} vmsCommsCheckStatus OBJECT IDENTIFIER ::={utmcVMSType1 5} ­­ This Node is used to define the rules for the checking the external comms link to the Instation. vmsCommsCheck OBJECT­TYPE SYNTAX TruthTable 109
ACCESS read­write STATUS mandatory DESCRIPTION "If the object is set to true, the VMS will send out a extComms TRAP every 'checktimer' minutes, The Instation is expected to reply to the VMS after the extComms TRAP has been raised. Every time a valid message (correctly access any MIB object) is recieved from the Instation the timer is re­set. If no response is recieved to the extComms TRAP it is assumed that the comms to Instation has failed, a maximum of 5 attempts to conact the in­station should be made with a delay of 1 minute between TRAPS" ::= {vmsCommsCheckStatus 1} vmsCheckTimer OBJECT­TYPE SYNTAX INTEGER (0..1440) ACCESS read­write STATUS mandatory DESCRIPTION "The time period for checking the external comms to the Instatation. The time period is in minutes. If this object is not used a default value of 0 should be returned." ::= {vmsCommsCheckStatus 2} vmsBlankOnFault OBJECT­TYPE SYNTAX TruthTable ACCESS read­write STATUS mandatory DESCRIPTION "If the object is set to true, the VMS will clear its 110
display if an exteralcomms fault is detected." ::= {vmsCommsCheckStatus 3} vmsTimeOut OBJECT­TYPE SYNTAX TruthTable ACCESS read­only STATUS mandatory DESCRIPTION "Used for the extComms TRAP. This object is set true to trigger the trap once the timer has elapsed. Object is set back to false after the TRAP has been sent, ready for the next attempt." ::= {vmsCommsCheckStatus 4} ­­Trap Definitions trapFaults TRAP­TYPE ENTERPRISE vmsFaultStatus VARIABLES {faultStatus} ::= 1 trapExtcomms TRAP­TYPE ENTERPRISE vmsCommsCheckStatus VARIABLES {vmsTimeOut} ::= 2 trapFaultChange TRAP­TYPE ENTERPRISE vmsFaultStatus VARIABLES {numberFaults} ::= 3 ­­ END 8.4 Script para Net­SNMP (archivo utmcVMSType1.sh)
#! /bin/sh ­f FILE=/home/dcortes/utmcVMSType1 111
PLACE=".1.3.6.1.4.1.13267.6.1" REQ="$2" if [ $# ­eq 2 ]; then DIFF=`echo $REQ |sed s/$PLACE//` if [ "$1" = "­n" ]; then case "$REQ" in $PLACE) RET=$PLACE.1.1 ;; $PLACE.1)
RET=$PLACE.1.1 ;; $PLACE.2)
RET=$PLACE.2.1 ;; $PLACE.3)
RET=$PLACE.3.1.1.1 ;; $PLACE*) RET=$PLACE`awk '$1 ~ /^'$DIFF'$/ {getline;print $1}' $FILE`;; $*)
exit 0;; esac elif [ $1 = "­g" ]; then case "$REQ" in $PLACE) exit 0;; $PLACE*)
RET=$REQ;; $*)
exit 0;; esac else exit 1 fi echo $RET DIFF=`echo $RET |sed s/$PLACE//` awk '$1 ~ /^'$DIFF'$/ {print $3; print $4}' $FILE # salida ok exit 0 elif [ $# ­eq 4 ]; then DIFF=`echo $REQ |sed s/$PLACE//` TYPE="$3" 112
VAL=`echo ­n "$4"` if [ "$1" = "­s" ]; then TYPE_V=`awk '$1 ~ /^'$DIFF'$/ {print $3}' $FILE` if [ $TYPE = $TYPE_V ]; then #
echo "not­writable" #
echo "'/'$DIFF' / {print $1, $2, $3, '$VAL'} !/'$DIFF' / {print}' $FILE" >> $FILE.dbg awk '/'$DIFF' / {print $1, $2, $3, '$VAL'} !/'$DIFF' / {print}' $FILE > $FILE.tmp echo $* >> $FILE.log cp $FILE $FILE.bck cp $FILE.tmp $FILE exit 0 else echo "wrong­type" exit 0 fi else exit 0 fi else # echo "Usage: "$0" [­g|­n] OID \n "$0" ­s OID type val" # echo "Type: integer, gauge, counter, timeticks, ipaddress, objectid, or string" exit 127 fi 8.5 Archivo Index.php para el webserver
<html> <head> <title>UTMC VMS</title> </head> 113
<body bgcolor = "#90b498"> <H1>Interfaz de Letreros VMS</H1> <br> <br> <?php //var_dump(gd_info()); $ip = "192.168.1.103"; $community= "utmc"; $OID_Base= ".1.3.6.1.4.1.13267.6.1"; $request = snmpget($ip,$community,$OID_Base . ".1.1"); $exp_req_value = explode("\"",$request); $req_value = $exp_req_value[1]; echo "Mib Version: ",$req_value, "<br>"; $request2 = snmpset( $ip,$community,$OID_Base . ".3.1.1.2","s","Hola Mundo"); //echo $request2; $request3 = snmpget($ip,$community,$OID_Base . ".3.1.1.2"); $exp_req_value = explode("\"",$request3); $req_value3 = $exp_req_value[1]; echo "<img src='button.php?text=",$req_value3,"'></img>"; ?> <p></p> </body> </html> 114