UNIVERSIDAD DE CHILEFACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICASDEPARTAMENTO 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 CHILEAGOSTO 2008

2008

UNIVERSIDAD DE CHILEFACULTAD 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 DEINGENIERO CIVIL ELECTRICISTA

SANTIAGO DE CHILEAGOSTO 2008

AgradecimientosA 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 MEMORIAPARA OPTAR AL TÍTULODE INGENIERO CIVIL ELECTRICISTAPOR: DANIEL CORTÉS BARRÍAFECHA: 03 DE JULIO DE 2008PROF. GUÍA: SR. NICOLÁS BELTRÁN

Desarrollo de una interfaz UTMC para Letreros de Mensajería VariableEl 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 figurasFigura 1: Sala de Control de Tránsito.........................................................................................10Figura 2: Letrero de Mensajería Variable...................................................................................12Figura 3: Arquitectura de un Sistema Embebido........................................................................16Figura 4: Dispositivos PC104 apilados.......................................................................................21Figura 5: Tarjeta TS7200............................................................................................................23Figura 6: Modelo de Referencia lógica para un sistema UTMC.................................................28Figura 7: Estándares de NTCIP..................................................................................................32Figura 8: Arquitectura SNMP......................................................................................................35Figura 9: Estructura de Árbol de la MIB......................................................................................37Figura 10: Shell de Unix..............................................................................................................40Figura 11: Esquema general de la implementación de la interfaz UTMC para VMS.................44Figura 12: cable Null­modem......................................................................................................51Figura 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  ObjetivosEl 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 memoriaEl 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ánsitoEl   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

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

Figura 1: Sala de Control de Tránsito

● 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.

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

Figura 2: Letrero de Mensajería Variable

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

 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

Figura 3: Arquitectura de un Sistema Embebido

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.

Una  instalación  típica  incluye una placa base, conversores analógico­digital  y módulos I/O 

21

Figura 4: Dispositivos PC104 apilados

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.

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

Figura 5: Tarjeta TS7200

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  ITSITS  (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

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

Figura 6: Modelo de Referencia lógica para un sistema UTMC

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.

32

Figura 7: Estándares de NTCIP

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. 

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

Figura 8: Arquitectura SNMP

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. 

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

Figura 9: Estructura de Árbol de la MIB

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 libreEl  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

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

Figura 10: Shell de Unix

● /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

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

Figura 11: Esquema general de la implementación de la interfaz UTMC para VMS

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.

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

Figura 12: cable Null­modem

● 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.binftp://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/ / nfs exec,dev,suid 1

1 6

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

1 $ sudo umount ­t ext2 /dev/disk/by­id/usb­Sony_USB_HS­CF_Card_50000005BF1F­0\:0­part1 /media/sandisk 

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> fconfigload ­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 ARGSextendfix 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).

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

Figura 13: Información SNMP obtenida con el Webserver 

 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......................................................................................................................................14VMS..................................................................................................ii, 6, 11, 33, 38, 45, 48, 74

86

 8  Anexos   

 8.1  El Microprocesador ARMSe 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:     robin@idtuk.com 

­­     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     OBJECT   IDENTIFIER   ::= { utmcTrafficCounter 1} 

­­  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       OBJECT   IDENTIFIER   ::= { utmcRisingBollard 1} 

END 

91

 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

    TRAP­TYPE FROM RFC­1215 

  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