La Flora Intestinal

UNIVERSIDAD SIMN BOLVAR
Decanato de Estudios Profesionales

Coordinacin de Ingeniera Electrnica
Anlisis y Mejora del Canal de Informacin de Trfico del

Real Automvil Club de Catalua
Por
Ricardo Amadoz
Sartenejas, Febrero de 2007


Por
Ricardo Amadoz
Realizado con la Asesora de

Mnica Karel Huerta
PROYECTO DE GRADO
Presentado ante la Ilustre Universidad Simn Bolvar
como requisito parcial para optar al ttulo de Ingeniero Electrnico


PROYECTO DE GRADO presentado por
Ricardo Amadoz
Carnet N 01-33538
REALIZADO CON LA ASESORIA DE Mnica Karel Huerta

RESUMEN
El Canal de Mensajes de Trfico (TMC) es un estndar europeo plenamente
operativo, empleado para difundir va radio informacin en tiempo real del estado del
trfico y las condiciones meteorolgicas. El Real Automvil Club de Catalua (RACC)
ofrece informacin sobre el estado del trfico a travs de las principales emisoras de
radio catalanas desde hace ms de quince aos. Actualmente, aspira a dirigir esta
informacin directamente a los usuarios de las vas mediante el sistema TMC. El
primer objetivo de este proyecto es realizar el anlisis y validacin de la
infraestructura tecnolgica existente de transmisin TMC del RACC, y en general, de
la seccin correspondiente de la Cadena de Servicio: Desde la fuente original de
informacin de datos de trfico (DGT) al Sistema Cliente-Servidor del CIT operativo
en las instalaciones del RACC; posteriormente a Radio Nacional de Espaa (datos
en formato RDS/TMC), y finalmente a los Dispositivos de Navegacin Personal. El
segundo objetivo es implementar mejoras en el CIT, y disear la inclusin de nuevos
canales de entrada y salida para mejorar la calidad de la informacin y diversificar los
medios de comunicacin.
PALABRAS CLAVE
Traffic Message Channel, Radio Data System, UECP SPB-490, Informacin de
Trfico.
Aprobado con mencin:_______

Postulado para el premio:_______
i
Anlisis y Mejora del Canal de Informacin de Trfico del Real Automvil Club de Catalua
NDICE GENERAL
1. INTRODUCCIN .............................................................................................. 1
2. OBJETIVOS...................................................................................................... 3
3. MARCO TERICO ........................................................................................... 5
3.1.
TMC ............................................................................................................................. 5
3.1.1.
El lenguaje virtual TMC ...................................................................................... 10
3.1.2.
Contenido de los mensajes ................................................................................ 11
3.1.2.1.
Descripcin de eventos (11 bits) ................................................................ 11
3.1.2.2.
Localizacin Primaria (16 bits) ................................................................... 11
3.1.2.3.
Direccin y Extensin (4 bits) ..................................................................... 12
3.1.2.4.
Duracin (3 bits)......................................................................................... 13
3.1.2.5.
Aviso de desvo (1 bit)................................................................................ 14
3.1.3.
Gestin de mensajes.......................................................................................... 15
3.1.3.1.
Mensajes de sistema ................................................................................. 15
3.1.3.2.
Base de datos de localizaciones ................................................................ 16
3.1.3.3.
Requisitos de los terminales....................................................................... 16
3.1.4.
Transmisin ....................................................................................................... 17
3.1.4.1.
Formato de los grupos tipo 8A ................................................................... 17
3.1.4.2.
Repeticin inmediata.................................................................................. 17
3.1.4.3.
Mensajes de usuario de grupo nico .......................................................... 18
3.1.4.4.
Mensajes de Sistema................................................................................. 19
3.1.4.4.1.
Informacin de sistema ......................................................................... 20
3.1.4.4.1.1.
Formato de la Informacin de Sistema en el grupo tipo 3A ............ 20
3.1.4.4.1.2.
Modos de transmisin RDS-TMC................................................... 22
3.1.4.4.1.2.1.
Modo Bsico ............................................................................ 23
3.1.4.4.1.2.2.
El modo intensificado ............................................................... 23
3.2.
RDS ........................................................................................................................... 26
3.2.1.
Caractersticas de modulacin del canal de datos (Capa Fsica)......................... 26
3.2.1.1.
Frecuencia de la subportadora ................................................................... 28
3.2.1.2.
Fase de la subportadora ............................................................................ 28
3.2.1.3.
Mtodo de modulacin ............................................................................... 28
3.2.1.4.
Frecuencia del reloj y tasa de datos ........................................................... 28
3.2.1.5.
Codificacin diferencial .............................................................................. 28
3.2.1.6.
Modelado del espectro del canal de datos.................................................. 30
3.2.2.
Codificacin en banda base (Capa de Enlace de Datos)..................................... 33
3.2.2.1.
Estructura de la codificacin en banda base............................................... 33
3.2.2.2.
Proteccin de errores................................................................................. 34
3.2.2.3.
Sincronizacin de bloques y grupos ........................................................... 35
3.2.3.
Formato de los mensajes (Capas de Sesin y Presentacin)............................. 36
3.2.3.1.
Caractersticas principales ......................................................................... 36
3.2.3.2.
Tipos de grupos ......................................................................................... 37
3.2.3.3.
Aplicaciones de Datos Abiertas (ODA) ....................................................... 37
3.2.3.3.1.
Estructura de los grupos ....................................................................... 38
3.2.3.4.
Codificacin de los tipos de grupos ............................................................ 38
3.2.3.4.1.
Grupos tipo 3A: Identificacin de ODAs................................................. 38
3.2.3.4.2.
Grupos tipo 8A: Traffic Message Channel o ODAs ................................ 39
3.2.4.
Descripcin de las caractersticas ms importantes del RDS .............................. 40
3.2.4.1.
Lista de Frecuencias Alternativas (AF) ....................................................... 40
ii
3.2.4.2.
3.2.4.3.
3.2.4.4.
3.2.4.5.
3.2.4.6.
3.2.4.7.
3.2.4.8.
3.2.4.9.
3.2.4.10.
3.2.4.11.
3.2.4.12.
Hora y Fecha (CT) ..................................................................................... 40

Aplicaciones internas (IH) .......................................................................... 40
Indicador de Locucin o Msica (MS)......................................................... 41
Identificacin del Programa (PI) ................................................................. 41
Nombre del Servicio de Programa (PS)...................................................... 41
Tipo de Programa (PTY) ............................................................................ 41
Nombre del Tipo de Programa (PTYN)....................................................... 42
Radio Paging (RP) ..................................................................................... 42
Radio Text (RT) ......................................................................................... 42
Identificacin de Anuncios de Trfico (TA).................................................. 43
Identificacin de Programa de Trfico (TP)................................................. 43
3.3.
UECP SPB 490 .......................................................................................................... 43
3.3.1.
Modelo estructural.............................................................................................. 44
3.3.1.1.
Mtodo de direccionamiento ...................................................................... 44
3.3.1.2.
Modelo del Hardware ................................................................................. 45
3.3.1.3.
Modos de transmisin ................................................................................ 46
3.3.2.
Descripcin del protocolo ................................................................................... 47
3.3.2.1.
Capa Fsica ............................................................................................... 47
3.3.2.1.1.
Especificaciones mecnicas.................................................................. 47
3.3.2.1.2.
Formato de los datos ............................................................................ 49
3.3.2.2.
Capa de Enlace de Datos .......................................................................... 49
3.3.2.2.1.
Formato general de las tramas.............................................................. 50
3.3.2.2.2.
Start...................................................................................................... 51
3.3.2.2.3.
Address ................................................................................................ 51
3.3.2.2.4.
Sequence Counter ................................................................................ 52
3.3.2.2.5.
Message Field Lenght ........................................................................... 52
3.3.2.2.6.
Message ............................................................................................... 52
3.3.2.2.7.
Cyclic Redundancy Check..................................................................... 52
3.3.2.2.8.
Stop ...................................................................................................... 53
3.3.2.2.9.
Tcnica de Byte-stuffing ........................................................................ 53
3.3.2.3.
Formato del campo Message ..................................................................... 53
3.3.2.3.1.
Estructura del mensaje.......................................................................... 53
3.3.2.3.2.
Message Element Code (MEC) ............................................................. 54
3.3.2.3.3.
Message Element data Lenght (MEL).................................................... 54
3.3.2.3.4.
Message Element Data (MED) .............................................................. 55
3.3.2.3.4.1.
ODA Configuration and Short Message Command ........................ 55
3.3.2.3.4.2.
ODA free-format group .................................................................. 56
3.3.2.3.4.3.
TMC .............................................................................................. 58
3.3.2.3.4.4.
Free-format group ......................................................................... 60
4. ARQUITECTURA ACTUAL DEL CANAL DE INFORMACIN DE TRFICO

DEL RACC...................................................................................................... 61
4.1.
Descripcin del sistema TIC ....................................................................................... 61
4.1.1.
Principios de diseo ........................................................................................... 62
4.1.2.
El TIC Editor....................................................................................................... 63
4.1.3.
El TIC Server ..................................................................................................... 69
4.1.3.1.
El Proceso de Recoleccin ........................................................................ 70
4.1.3.2.
El Proceso de Administracin..................................................................... 72
4.1.3.3.
El Proceso de Distribucin ......................................................................... 73
4.1.4.
El Mdulo TIC RDS/TMC.................................................................................... 74
4.2.
Arquitectura actual del sistema TIC del RACC ............................................................ 75
4.3.
Canal de entrada TIC DGT ...................................................................................... 78
4.4.
Canal de salida TIC RNE ......................................................................................... 79
4.5.
Distribucin RDS realizada por RNE ........................................................................... 81
iii
5. ANLISIS Y VALIDACIN DEL FUNCIONAMIENTO DEL SISTEMA .......... 85

5.1.
Situacin actual del Departamento de Infotrnsit......................................................... 85
5.1.1.
Metodologa de trabajo actual............................................................................. 85
5.1.2.
Justificacin del uso del sistema......................................................................... 87
5.2.
Situacin actual del RDS/TMC en Espaa .................................................................. 87
5.3.
El sistema RDS de RNE ............................................................................................. 90
5.3.1.
El direccionamiento SPB en RNE ....................................................................... 92
5.4.
Relacin entre los formatos de datos del sistema TIC y el exterior .............................. 93
5.4.1.
Formato de los datos provenientes de la DGT .................................................... 93
5.4.1.1.
Registros de tipo Retenciones.................................................................... 94
5.4.1.2.
Registros de tipo Climatologa.................................................................... 96
5.4.1.3.
Registros de tipo Puertos de montaa........................................................ 96
5.4.1.4.
Registros de tipo Obras.............................................................................. 97
5.4.1.5.
Ejemplos de interpretacin de los datos del fichero gsmplus.txt.................. 97
5.4.2.
Campos de datos del TIC Editor para la generacin de mensajes TMC .............. 98
5.4.3.
Correspondencia entre los datos de la DGT y los campos de datos del TIC Editor
para la generacin de mensajes TMC ................................................................ 99
5.4.4.
Formato de los datos enviados a RNE.............................................................. 102
5.5.
Anlisis del formato de datos interno del sistema TIC ............................................... 102
5.6.
Resultados de las pruebas RDS/TMC entre el RACC y RNE .................................... 105
6. MEJORAS IDENTIFICADAS ........................................................................ 111

6.1.
Incorporacin de nuevas fuentes de datos al sistema ............................................... 111
6.1.1.
Informacin de radares..................................................................................... 111
6.1.1.1.
Radares de la DGT .................................................................................. 111
6.1.1.2.
Radares del SCT ..................................................................................... 112
6.1.2.
Puntos Negros ................................................................................................. 112
6.1.2.1.
Puntos negros de la DGT......................................................................... 112
6.1.2.2.
Puntos negros del Pas Vasco ................................................................. 113
6.1.3.
EuroRAP .......................................................................................................... 113
6.1.4.
EuroTAP .......................................................................................................... 113
6.1.5.
Cmaras en lnea ............................................................................................. 114
6.2.
Incorporacin de los datos dinmicos del SATI ......................................................... 114
6.2.1.
Justificacin e inters ....................................................................................... 114
6.2.2.
Propuesta ........................................................................................................ 116
6.2.3.
Carga de datos estticos .................................................................................. 119
6.3.
El sistema de informacin de trfico RACC TME.................................................... 121
6.3.1.
Requisitos para el intercambio de informacin .................................................. 121
6.3.2.
Arquitectura funcional....................................................................................... 122
6.3.3.
Protocolos de comunicacin ............................................................................. 124
6.4.
Seleccin y adquisicin de un navegador GPS ......................................................... 125
6.4.1.
Caractersticas del Mio C710............................................................................ 125
6.5.
Mejoras y ajustes realizados al sistema TIC.............................................................. 131
7. CONCLUSIONES ......................................................................................... 136

8. REFERENCIAS BIBLIOGRFICAS............................................................. 138
APNDICES....................................................................................................... 141
iv
NDICE DE TABLAS Y FIGURAS
FIGURAS
Figura
Pgina
Figura 1. Cobertura del TMC en Europa......6

Figura 2. Grupos RDS tipo 8A, presentando la estructura definida para RDS/TMC...17
Figura 3. Estructura completa de mensajes de grupo nico RDS-TMC...19
Figura 4. Estructura de los grupos tipo 3A, transportando informacin de sistema RDS-TMC....20
Figura 5. Espacios de tiempo del modo Intensificado RDS-TMC y estructura24
Figura 6. Diagrama de bloques de un equipo de radio-datos en el transmisor...27
Figura 7. Diagrama de bloques de un receptor/decodificador de radio-datos.27
Figura 8. Respuesta en amplitud del filtro pasa-bajo de un transmisor o un receptor31
Figura 9. Espectro de las seales radio/datos codificadas bifsicamente31
Figura 10. Funcin en el tiempo de un smbolo bifsico.32
Figura 11. Seales radio/datos de 57 KHz32
Figura 12. Estructura de la codificacin en banda base..33
Figura 13. Formato y direccionamiento de los mensajes.34
Figura 14. Grupos ODA versin A...38
Figura 15. Grupos ODA versin B...38
Figura 16. Formato de los grupos 3A / AID para ODAs...39
Figura 17. Formato de los grupos 8A / TMC..40
Figura 18. Ejemplo ficticio de direccionamiento a distintos sitios...44
Figura 19. Modelo de hardware de un codificador RDS..45
Figura 20. Formato de las tramas SPB...50
Figura 21. Formato del comando ODA Configuration and Short Message...55
Figura 22. Formato del cdigo ODA Free-format group................................................................57
Figura 23. Formato del cdigo TMC....59
Figura 24. Formato del cdigo Free-format group.60
Figura 25. Arquitectura del sistema TIC..62
Figura 26. Vista general del TIC Editor....64
Figura 27. Detalle de la List Window del TIC Editor, donde se observa que algunos
mensajes son codificables en TMC y otros no....65
Figura 28. Detalle de la pestaa Mapa, dentro de la Detail Window..66
Figura 29. Evolucin en el tiempo de un parmetro del Estado del Sistema....67
Figura 30. Vista general del TIC Info Wizard..68
v
Figura 31. Definicin inicial del filtro geogrfico para Catalua..69

Figura 32. El proceso de Recoleccin de datos71
Figura 33. El proceso de Administracin de datos...72
Figura 34. El proceso de Distribucin de datos.73
Figura 35. Diagrama de bloques del mdulos RDS/TMC75
Figura 36. Diagrama de la arquitectura actual del sistema TIC del RACC...76
Figura 37. Plataforma actual del sistema TIC del RACC.76
Figura 38. Departamento de Infotrnsit del RACC...77
Figura 39. Sala de Servidores del RACC, con detalle de su interior.78
Figura 40. Esquema de distribucin de los datos RDS de la Direccin Tcnica de RNE..82
Figura 41. Fotografa del mdem TMC asignado al RACC.83
Figura 42. Vista general de una de las oficinas de la Direccin Tcnica de RNE. Se observan
tres dispositivos que intervienen en la distribucin RDS de los datos del RACC.84
Figura 43. Equipos empleados por los locutores de Infotrnsit para sus conexiones de radio.86
Figura 44. Esquema del funcionamiento del sistema RDS/TMC (datos recolectados
manualmente)...88
Figura 45. Esquema del funcionamiento del sistema RDS/TMC (datos recolectados
automticamente)....89
Figura 46. Fotografa de unas espiras inductivas antes de un semforo: Se pueden
observar las marcas que quedaron en el pavimento tras su instalacin....89
Figura 47. Correspondencia entre las direcciones en formato SPB y en formato hexadecimal....92
Figura 48. Correspondencia entre los datos de la DGT y los campos del TIC Editor...100
Figura 49. Identificacin y descripcin de todos los elementos del formato de datos interno
del sistema TIC, a partir del estudio de unos mensajes reales.....104
Figura 50. Pantalla del Gestor SPB...107
Figura 51. Pantalla del Analizador de Protocolos RDS..107
Figura 52. Fragmento de la pantalla del TIC Admin, donde se fijan, entre otros parmetros,
las direcciones SPB..109
Figura 53. Extracto del registro de salida del mdulo RDS/TMC.....109
Figura 54. Diagrama de la arquitectura del sistema TIC del RACC, con la incorporacin
de los datos del SATI....115
Figura 55. Atributos, formatos y ejemplos de los datos de entrada del SATI al sistema TIC..120
Figura 56. Esquema bsico de la arquitectura de comunicacin del SITTR......122
Figura 57. Determinando una direccin cualquiera: C/Jordi Girona, 31. Barcelona..127
Figura 58. Pantalla de informacin sobre la seal GPS, y otras informaciones.....128
Figura 59. Pantalla de ajustes TMC, donde se puede elegir que el dispositivo tenga o
no presente los mensajes TMC al momento de calcular una ruta. En la imagen, el
navegador no ha conseguido todava ninguna estacin de radio que transmita
vi
informacin TMC....128
Figura 60. Se observa que el dispositivo ha conseguido una estacin de radio que transmite
informacin TMC: RNE 3..129
Figura 61. Pantalla de mensajes de trfico: Lista todas las incidencias captadas hasta
el momento.129
Figura 62. Clculo de una ruta entre dos puntos sin considerar los mensajes TMC:
El dispositivo simplemente busca la ruta ms directa, sin importar que en ella
haya retenciones de trfico. La lnea roja representa la ruta establecida; la lnea
azul la congestin (est cubierta por la roja, pero se ve su indicativo).130
Figura 63. Clculo de una ruta entre dos puntos considerando los mensajes TMC:
El dispositivo opta por rutas alternas (en la medida de lo posible) para evitar las
retenciones de trfico. La lnea roja representa la ruta establecida; la lnea azul
la congestin..130
Figura 64. Liberacin de algo ms de 435 MB de datos antiguos......132
Figura 65. Redefinicin del filtro geogrfico del rea de Catalunya. Imagen tomada durante
el proceso......133
Figura 66. Ajuste de la frecuencia de actualizacin del TIC Server135
vii
TABLAS
Tabla
Pgina
Tabla 1. Cdigos de duracin para periodos relacionados con el viaje actual del usuario final...13
Tabla 2. Cdigos de duracin para largos periodos de tiempo..14
Tabla 3. Definicin del campo Aviso de desvo.15
Tabla 4. Campos de datos TMC incluidos en grupos nicos..18
Tabla 5. Codificacin del parmetro de intervalo G..23
Tabla 6. Codificacin de Td..25
Tabla 7. Codificacin de Ta..25
Tabla 8. Codificacin de Tw.25
Tabla 9. Reglas de codificacin de los datos de fuente en la transmisin RDS..29
Tabla 10. Reglas de decodificacin de los datos en el receptor.29
Tabla 11. Cdigo de grupo/versin y descripcin de los grupos 3A y 8A.37
Tabla 12. Seales del conector de 9 pines para el DTE..47
Tabla 13. Detalle del formato de las tramas SPB.....50
Tabla 14. Estructura de los elementos de mensaje.....54
Tabla 15. Configuracin del buffer mediante los bits 1 y 0 del cuarto MED del comando
ODA Configuration and Short Message...56
Tabla 16. Configuracin del buffer mediante los bits 1 y 0 del segundo MED del cdigo
ODA Free-format group...57
Tabla 17. Seleccin del modo de transmisin mediante los bits 3 y 2 del segundo MED
del cdigo ODA Free-format group...58
Tabla 18. Establecimiento de la prioridad de transmisin mediante los bits 5 y 4 del segundo
MED del cdigo ODA Free-format group.58
Tabla 19. Configuracin del buffer mediante los bits 6 y 5 del primer MED del cdigo
ODA TMC..59
Tabla 20. Configuracin del buffer mediante los bits 6 y 5 del segundo MED del cdigo
Free-format group60
Tabla 21. Parmetros de la transmisin TMC por la red de emisoras de RNE 391
Tabla 22. Longitud de los campos del fichero gsmplus.txt..93
Tabla 23. Estructura del fichero gsmplus.txt..93
Tabla 24. Valores y significados del campo Causa de los registros de tipo Retencin..94
Tabla 25. Valores y significados del campo Nivel de los registros de tipo Retencin.95
Tabla 26. Valores y significados del campo Sentido de los registros de tipo Retencin95
Tabla 27. Valores y significados del campo Causa de los registros de tipo Climatologa..96
viii
Tabla 28. Valores y significados del campo Nivel de los registros de tipo
Puertos de montaa...97
Tabla 29. Correspondencia entre el campo Nivel de los registros de la DGT y el Cdigo
de Evento TMC asignado..100
Tabla 30. Correspondencia entre el campo Prefijo de los registros de la DGT y el
Cdigo de Evento TMC asignado...................................................................................101
Tabla 31. Correspondencia entre el campo Causa de los registros de la DGT y el
Cdigo de Evento TMC asignado...................................................................................101
Tabla 32. Ejemplo del formato de los radares de la DGT..111
Tabla 33. Ejemplo del formato de los radares del SCT..112
Tabla 34. Ejemplo del formato de los puntos negros de la DGT...112
Tabla 35. Ejemplo del formato de los puntos negros del Pas Vasco..113
Tabla 36. Caractersticas de los campos de inters del SATI...115
Tabla 37. Representacin fsica de los campos de inters y su correspondencia con
los nodos del documento XML..116
ix
LISTA DE ACRNIMOS
ADD
Address
AF
Alternative Frequencies
AFI
Alternative Frequency Indicator
AID
Application ID
ALERT-C
Advice and Problem Location for European Road Traffic, Version C
CT
Clock Time
CTS
Clear to Send
CPU
Central Processing Unit
CRC
Cyclic Redundancy Code/Check
DAB
Digital Audio Broadcasting
DATEX
Data Exchange
DCD
Data Carrier Detect
D-GPS
Diferential GPS
DGT
Direccin General de Trfico
DSN
Data Set Number
DSR
Data Set Ready
DTE
Data Terminating Equipment
DTR
Data Terminal Ready
DVB
Digital Video Broadcasting
EBU
European Broadcasting Union (Unin de Radiodifusores Europeos)
ECMT
Conferencia Europea de Ministros de Transportes
EON
Enhanced Other Network
FCD
Floating Car Data
FM
Frequency Modulation
FTP
File Transfer Protocol
GEWI
Empresa alemana fabricante del sistema TIC
GND
Signal Ground
GPS
Global Positioning System
HTTP
Hypertext Transfer Protocol
x
IGN
Instituto Geogrfico Nacional
IH
In House application
IP
Internet Protocol
ISO/OSI
International
Organisation
for
Interconnection
ITS
Intelligent Transport Systems
LCP
Low Cost Profile
l.s.b.
Least Significant Bit(s)
LTN
Location Table Number
MEC
Message Element Code
MED
Message Element Data
MEL
Message Element data Length
MFL
Message Field Lenght
MGS
Message Geographical Scope
MJD
Modified Julian Date
MS
Music Speech
m.s.b
Most Significant Bit(s)
MSG
Message
NVRAM
Non-volatile RAM
ODA
Open Data Applications
PI
Programme Identification
PK
Punto kilomtrico
POP3
Post Office Protocol version 3
PS
Programme Service
PSN
Programme Service Number
PTY
Programme Type
PTYN
Program Type Name
RACC
RAM
Random Access Memory
RDS
Radio Data System
RI
Ring Indicador
Standardization/Open
Systems
xi
RNE
Radio Nacional de Espaa
RNE-CLAS Red de emisoras Clsica de Radio Nacional de Espaa

ROM
Read Only Memory
RP
Radio Paging
RP
Regular Profile
RT
Radio Text
RTS
Request to Send
RxD
Received Data
SATI
Servicio de Asistencia en carretera del RACC
SCT
Servei Catal de Trnsit
SID
Service ID
SITTR
Sistema de Informacin de Trfico en Tiempo Real de TME
SMS
Short Message Service
SMTP
Simple Mail Transfer Protocol
SOAP
Simple Object Access Protocol
SQC
Sequence Counter
SQL
Structured Query Language
SSL
Secure Socket Layer
STA
Start
STP
Stop
Ta
Activity Time
TA
Traffic Announcement
Td
Delay time
TIC
Traffic Information Centre
TMC
Traffic Message Channel
TP
Traffic Programme
TPEG
Transport Protocol Experts Group
TSL
Transport Secure Layer
TTI
Traffic and Traveler Information
Tw
Window Time
TxD
Transmitted Data
xii
UTC
Coordinated Universal Time
VHF
Very High Frequency
WAP
Wireless Application Protocol
XML
Extensible Markup Language
XSL
Extensible Stylesheet Language
1
1. INTRODUCCIN
La aplicacin de desarrollos telemticos a las redes de transporte terrestre ha

cambiado drsticamente la forma de en que nos movilizamos. Desde las compaas
de transporte de cargas pesadas al transporte pblico, desde los servicios de
emergencia y seguridad hasta los vehculos de particulares: Los Sistemas de
Transporte Inteligentes (ITS, por sus siglas en ingls) son hoy en da una parte ms,
a veces incluso desapercibida, de nuestro entorno.
Son muchas las distintas ramas dentro del mundo de los ITS, pues su rango
de accin es multidisciplinario, y los desarrollos se suceden a pasos agigantados,
siempre con prototipos a la espera de ver la luz. Una de las ramas de mayor impacto,
por su repercusin directa sobre las personas, es conocida como TTI Traffic and
Traveler Information y abarca todo lo relacionado con la provisin de informacin a
los conductores y viajeros: desde los medios empleados para transmitir el mensaje
hasta su propio contenido. Uno de los sistemas con mejor posicionamiento en
Europa es el TMC: Traffic Message Channel, el cual, combinado con el RDS Radio
Data System se constituye como una tecnologa capaz de llegar de forma masiva a
los conductores.
En Espaa, la informacin TMC es provista nicamente por la Direccin
General de Trfico, y difundida por la red de emisoras RNE 3 de Radio Nacional de
Espaa. El servicio est operativo desde 1999, y sin embargo es an prcticamente
un desconocido. El Real Automvil Club de Catalua (RACC) cuenta en sus
instalaciones con un sistema que le podra llevar a convertirse en un futuro cercano
en el segundo Proveedor de Servicio TMC de toda Espaa. El objeto de este
proyecto es analizar el Canal de Informacin de Trfico del RACC, y participar desde
diversos frentes en su mejora, en pro de alcanzar eventualmente este objetivo.
En el captulo 3 se presenta el marco conceptual sobre el que se sustentan el
sistema del RACC y el proceso de transmisin de datos hacia las estaciones de
2
radio. El captulo 4 expone la arquitectura actual del servicio, estudiando en detalle

tanto el funcionamiento interno del sistema, como sus canales de entrada y de salida.
En el captulo 5 se analiza el funcionamiento del sistema desde el punto de
vista del intercambio de datos, y se realizan algunas pruebas relacionadas con la
transmisin RDS/TMC. El captulo 6 presenta el diseo de las mejoras que
experimentar el sistema prximamente, y permite apreciar su potencial de
crecimiento.
Finalmente, en el captulo 7 se plantean las conclusiones del proyecto y las
perspectivas de futuro.
3
2. OBJETIVOS
Actualmente el RACC dispone de un sistema que permite la recoleccin y
gestin de informacin de trfico, as como su posterior distribucin va RDS/TMC.
Sin embargo, el sistema se encuentra en desuso, principalmente porque la calidad
de la informacin de trfico que se carga no es del todo fiable, se encuentra poco
optimizado y no dispone de todos los acontecimientos necesarios. Los objetivos del
presente proyecto giran en torno a la validacin del funcionamiento del sistema, y a
la bsqueda de reas de mejora para el mismo.
Para ello, lo primero ser comprender las metodologas de funcionamiento y
transmisin de datos. Luego, ser necesario analizar el procesado que estos sufren a
nivel interno. Finalmente, en el marco de nuevos aportes, habr que desarrollar el
estudio para incorporar dentro del sistema del RACC tres nuevas fuentes de datos:
Informacin esttica: Aquella proveniente de radares oficiales gubernamentales,

puntos negros de carreteras (aquellos puntos que registran mayor nmero de
accidentes), el EuroRAP (un estudio a nivel europeo que determina el nivel de
riesgo de las carreteras), el EuroTAP (similar al anterior, aplicado a los tneles
europeos), y las cmaras en carretera de la Direccin General de Trfico y el
Servei Catal de Trnsit.
Informacin propia del RACC: Extrada automatizadamente a partir de los registros

del Servicio de Asistencia en carretera que ofrece RACC.
Movistar: La primera operadora mvil de Espaa cuenta actualmente con el

servicio Ruta Movistar, el cual provee a los usuarios informacin GPS
simplemente con su telfono celular (y un receptor GPS Bluetooth externo en caso
de que ste no venga incorporado en el telfono). Un nuevo acuerdo con el RACC
se ha establecido para que ste le agregue a la cartografa esperada el valor
aadido del estado de las vas en tiempo real.
4
Por otra parte, tambin se deber evaluar el desempeo del sistema como
emisor de informacin RDS/TMC, por tratarse tambin de otro punto estratgico
dentro de los intereses del RACC.
5
3. MARCO TERICO
Los Sistemas de Transporte Inteligentes (ITS, por sus siglas en ingls)
tambin conocidos como Transport Telematics son aplicaciones de las tecnologas
de la informacin y la comunicacin en el campo del transporte. En los ltimos aos,
los ITS se han afianzado como una manera de mejorar la eficacia y la seguridad del
transporte terrestre, y de reducir su impacto en el ambiente. Las herramientas ITS
permiten a operadores y autoridades planear y administrar actividades relacionadas
con el transporte con ms eficacia. Tambin proporcionan servicios de informacin,
que ayudan a conductores y a viajeros a organizar mejor sus viajes. El campo dentro
de los ITS encargado de proveer a los conductores con informacin relacionada con
el estado de las vas es conocido como TTI: Traffic and Traveler Information.
Muchos
avances
se
han
producido
relacionados
con
las
TTI.
Tradicionalmente, los narradores de boletines de trfico va radio slo tienen slots

(intervalos) peridicos de duracin fija en sus transmisiones, por lo que deben
concentrar toda la informacin en pocos minutos y describir en un cierto orden las
incidencias dentro de su zona de cobertura. Por su parte, es bien sabido el cuantioso
gasto que representan las congestiones de trfico en trminos de tiempo, dinero,
combustible, contaminacin ambiental, y dems: Segn (1), los conductores
americanos perdieron, en media, 47 horas durante el 2003 en retenciones de trfico
(variando estos datos por ciudad, desde Seattle 46 horas hasta Los Angeles 91
horas ). Se estima que se desperdiciaron unos 8,69 billones de litros de
combustible, se acumularon en total 3,7 billones de horas de retrasos, y el costo total
de las congestiones de trfico ascendi a $ 63,1 billones.
3.1. TMC:
El Canal de Mensajes de Trfico (TMC, por sus siglas en ingls) es un

estndar europeo plenamente operativo en ms de 13 pases, empleado para
6
difundir informacin en tiempo real del trfico y de las condiciones meteorolgicas.

En la Figura 1 se presenta la cobertura actual del TMC en Europa.
Figura 1. Cobertura del TMC en Europa.
Los mensajes de datos se reciben silenciosamente es decir, los usuarios

pueden seguir escuchando la estacin mientras se recibe y decodifica el mensaje, en
lugar de que este interrumpa la programacin (aunque tambin se puede activar esta
funcionalidad a voluntad) y son descifrados por la radio del vehculo (al incorporar
directamente el decodificador TMC) o por un sistema de navegacin, y entregados al
conductor en una variedad de maneras (por pantalla, va procesadores de texto/voz,
etc). El ms comn de stos es un sistema de navegacin con TMC incorporado que
7
puede ofrecer direccin dinmica de la ruta: Alerta al conductor de un problema en la

trayectoria prevista y calcula una ruta alternativa para evitar el incidente.
El sistema TMC permite transmitir hasta 300 mensajes por hora, entregados
instantneamente, tan pronto como se creen. Esto permite a los Proveedores de
Servicio TMC despachar ms informacin (por ejemplo, obras en la va). Adems, los
receptores TMC brindan la posibilidad de filtrar los mensajes relevantes a un rea
local especfica para el viaje actual, e incluso reproducirlos en el idioma del usuario.
As, es posible realizar una travesa transnacional por la red de carreteras y
autopistas europeas y recibir instrucciones por parte del navegador TMC en el idioma
del conductor (independientemente del pas en el que se encuentre) para llegar de
manera directa y exacta al destino.
El estndar TMC se basa en el protocolo de codificacin de mensajes de
trfico ALERT-C (Advice and Problem Location for European Road Traffic, Version
C), el cual fue un importante resultado del proyecto DRIVE V1029, RDS Advice and
Problem Location for European Road Traffic (Aviso RDS y Localizacin de
Problemas de Trfico de las Carreteras Europeas). El
proyecto RDS-ALERT
pretendi definir normas para el RDS-TMC en toda Europa, trabajando junto a la

Unin de Radiodifusores Europeos (European Broadcasting Union) y la Conferencia
Europea de Ministros de Transportes (ECMT) (2).
El Protocolo ALERT-C est designado para ofrecer en su mayora mensajes
de informacin para el usuario final de carretera orientados a eventos. Muchos
enlaces se han dejado para un futuro desarrollo y se incluyeron algunos mensajes
de informacin para el usuario final de carretera orientados al estado.
Los mensajes RDS-TMC1 son independientes del idioma y pueden ser
presentados en el idioma de eleccin del usuario. El protocolo ALERT-C utiliza una
1
Los detalles del Radio Data System se introducirn ms adelante. Por ahora, slo es necesario
saber que los mensajes TMC se envan empleando el estndar RDS; de all que se les suela referir
como un mismo mensaje.
8
Lista de Eventos estandarizada (3) de mensajes de eventos con sus valores de

cdigo, los cuales tambin incluyen problemas de trfico a todos los niveles y
condiciones meteorolgicas.
Los mensajes estndar de usuario RDS-TMC ofrecen los siguientes cinco
elementos bsicos de informacin explcita emitida:
1. Descripcin del evento, dando detalles de la situacin de eventos de carretera,
problemas
generales de trfico y condiciones meteorolgicas (por ejemplo,
congestin causada por accidente) y donde sea necesario, su gravedad (por

ejemplo, longitud de la cola resultante).
2. Localizacin, indicando la localizacin de tipo rea, segmento de carretera o
punto donde se sita el origen del problema.
3. Direccin y Extensin, identificando las localizaciones especficas, de tipo
segmento o punto, adyacentes que tambin estn afectadas por el incidente, y
cuando sea apropiado la direccin del trfico afectada.
4. Duracin, dando una indicacin sobre cundo se espera que finalice el problema.
5. Aviso de desvo, indicando si se recomienda que los usuarios finales busquen
una ruta alternativa.
Se puede aadir informacin opcional a cualquier mensaje usando uno o ms
grupos de datos RDS adicionales. Esta aadidura opcional puede dar mayor detalle
o puede tratar situaciones inusuales. En principio, se puede aadir cualquier nmero
de campos adicionales a cada mensaje bsico hasta una extensin de mensaje
mxima de cinco grupos de datos RDS.
9
El protocolo ALERT-C pretende codificar la mayora de los mensajes en un

solo grupo RDS, y distingue entre mensajes de usuario y mensajes de sistema. Los
mensajes de usuario son aquellos que potencialmente se hacen conocer al usuario
final, pues contienen los detalles de los eventos de trfico. Pueden usar uno o ms
grupos de tipo 8A. La mayora de los mensajes puede transmitirse usando un nico
grupo de tipo 8A, sin embargo los mensajes con ms detalle (por ejemplo, el aviso
de desvo) pueden usar hasta un total de cinco grupos de tipo 8A.
Los mensajes de sistema son usados nicamente por el terminal RDS-TMC,
con el propsito de gestionar los mensajes, y detallar los parmetros que el terminal
necesita para poder identificar y decodificar la informacin TMC. La informacin de
sistema se transmite en grupos de tipo 3A y grupos de tipo 8A.
RDS es un sistema de emisin en una sola direccin, y por tanto un proveedor
de servicios no tiene manera de saber si los datos RDS han sido satisfactoria y
correctamente recibidos por los receptores de audio RDS o los terminales TMC. Hay
un nmero de factores que afectan a la capacidad de recibir informacin RDS,
incluyendo la topologa del rea de emisin, el nivel de insercin de la seal de datos
RDS y la localizacin de un terminal en concreto. Para optimizar la posibilidad de que
un terminal reciba datos RDS, todos los grupos RDS se transmiten ms de una vez.
Para la informacin esttica (o que es esttica durante un largo tiempo), los
grupos RDS se repiten peridicamente, y los periodos ente grupos repetidos
sucesivos puede ser de varios minutos. Para el caso de datos referidos a situaciones
que cambian dinmicamente (por ejemplo, condiciones de trfico), los grupos RDSTMC apropiados se repiten en secuencia rpida. Tpicamente se transmite un grupo
de mensaje RDS-TMC de tipo 8A seguido de, entre tres y once grupos que no son
TMC, luego una repeticin exacta del mensaje RDS-TMC de tipo 8A, otra
interrupcin de tres a once grupos de mensaje que no son RDS-TMC, y finalmente
otra repeticin del grupo de mensaje RDS-TMC. Pruebas de campo demostraron que
10
este patrn de repeticin inmediato de los grupos es el ptimo para la adquisicin

de datos RDS por parte de un terminal.
El protocolo ALERT-C requiere que un terminal reciba al menos dos grupos
RDS-TMC idnticos, a travs de repeticiones inmediatas o peridicas, antes de que
pueda aceptar el dato como vlido.
3.1.1.
El lenguaje virtual TMC:
La informacin sobre el Canal de Mensajes de Trfico (TMC) se comunica por

medio de un lenguaje virtual en el que los cdigos emitidos por el aire contienen
direcciones almacenadas en bases de datos en los terminales. Estas bases de datos
contienen listas de situaciones de eventos de las carreteras, incluyendo problemas
de trfico generales y situaciones meteorolgicas, duraciones y otras informaciones;
ms listas de localizaciones, incluyendo intersecciones, nmeros de carretera y
nombres de lugares. Muchos procesos estn implicados:
a) antes de la transmisin, la informacin en relacin a un evento se mapea en el
lenguaje virtual TMC (bien sea empleando mens anidados de descripciones de
eventos y localizaciones), o por un sistema de control de informacin de trfico
completamente automatizado;
b) los mensajes codificados resultantes se transmiten por RDS con frecuentes
repeticiones;
c) en el terminal se comprueban los cdigos TMC para ver si contienen informacin
nueva o son actualizaciones de mensajes ya recibidos. Los nuevos cdigos se
almacenan en la memoria y son sometidos a la gestin del mensaje; y
d) en momentos adecuados los cdigos se traducen de nuevo en mensajes por
medio de tablas para la presentacin al usuario final.
11
Dentro de este concepto de lenguaje virtual, las Listas de Eventos usados en

la fuente y las usadas en un terminal final no son necesariamente idnticas. Por
ejemplo, los mensajes pueden ser introducidos en un idioma y reproducidos en otro.
Las traducciones de descripciones de eventos, en los trminos correctos y
tradiciones de los idiomas y pases correspondientes (por ejemplo, castellano), tienen
que ser consistentes con las definiciones inglesas.
3.1.2.
Contenido de los mensajes:
Como se mencion en lneas anteriores, los mensajes RDS-TMC para el

usuario estn compuestos por cinco tipos de informacin: Descripcin del Evento,
Localizacin, Direccin y Extensin, Duracin, y Aviso de desvo. A continuacin se
explicarn en detalle sus caractersticas:
3.1.2.1.
Descripcin de eventos (11 bits):
La descripcin de eventos se encuentra listada en (3). Esta lista estandarizada

est formada por un repertorio de frases pre-definidas. Muchas descripciones de
eventos son descripciones de una sola frase. Adems, la Lista de Eventos contiene
descripciones de eventos en las que dos o ms frases han sido combinadas para
que puedan ser usadas (de forma similar a la descripcin de una nica frase) en un
mensaje de grupo nico.
3.1.2.2.
Localizacin Primaria (16 bits):
Cuando la fuente del
problema (por ejemplo, un accidente o un
embotellamiento) ocurre en una localizacin TMC definida, su localizacin primaria

puede ser emitida usando el nmero de localizacin relevante. Cuando la fuente de
un problema direccional (por ejemplo, una cola) ocurre entre dos localizaciones TMC
de tipo punto, su localizacin primaria puede ser emitida usando el nmero de
localizacin del punto ms cercano hacia abajo, medido en la direccin del trfico
12
afectado. Cuando el evento se define como bidireccional, su localizacin primaria

puede ser emitida usando cualquiera de las dos localizaciones TMC de tipo punto
ms cercanas que delimitan el evento.
Cuando un terminal recibe un mensaje TMC referido a una localizacin no
incluida en su base de datos, no debe producir ningn mensaje de salida para el
usuario final. Los 2048 nmeros de localizacin ms altos no se usan para objetos
geogrficos. Estn reservados para usos especiales. Otros nmeros de localizacin
con una funcin especial son:
- Nmero 65533: indica que el mensaje est destinado a todos los oyentes, sin
importar su posicin o destino ni cualquier filtro de seleccin geogrfico que puedan
haber activado en su terminal. Puede ser usado para informacin general, no
necesariamente urgente, sobre el servicio TMC, o para avisos de mal tiempo a
escala nacional. En vez del nombre de localizacin, un terminal puede presentar una
frase como mensaje para todos los usuarios.
- Nmero 65534: cdigo de localizacin silencioso (ignorando de nuevo cualquier
filtro geogrfico en el terminal) para indicar que no se debe mostrar ningn nombre
de localizacin o frase alternativa. Puede ser usado tambin para mensajes de
informacin general y puede ser til para otros propsitos.
- Nmero 65535: para la actualizacin de mensajes independientemente de su
localizacin o su cancelacin.
3.1.2.3.
Direccin y Extensin (4 bits):
- Direccin (1 bit): El bit de direccin (0 = positivo, 1 = negativo) debe indicar la

direccin del crecimiento de cola para todos los tipos de eventos definidos como
direccionales; es decir, es opuesta a la direccin del flujo de trfico afectada. Cuando
un evento se define como bidireccional y, por tanto, que afecta ambas direcciones, el
bit de direccin slo se usa para indicar la localizacin secundaria.
13
- Extensin (3 bits): La extensin identifica una cadena de hasta siete pasos a travs
de localizaciones TMC adyacentes tambin afectadas por el evento. El ltimo paso
en esta cadena identifica la localizacin secundaria, que junto con la localizacin
primaria abarca el evento. Cuando el evento afecta slo una localizacin TMC, la
extensin es cero.
3.1.2.4.
Duracin (3 bits):
El cdigo de duracin en los mensajes establece ocho niveles de duracin

esperada del problema. La interpretacin del cdigo de duracin depende de la
naturaleza y del tipo de duracin del evento tal y como se define en (3). Para
mensajes de grupo nico, la duracin es un campo bsico codificado en 3 bits. Para
mensajes multigrupo, la duracin es un punto opcional. Estimar duraciones vlidas
es difcil a menudo, por lo que se recomienda el uso del Cdigo 0 cuando no haya
certeza sobre la duracin.
En el caso de eventos dinmicos con naturaleza informativa (como se
especifica en (3)), el cdigo de duracin indica periodos relacionados con el viaje
actual de un usuario final. Estas duraciones se definen como: Se espera que la
situacin contine durante..., y se presentan en la Tabla 1.
Cdigo
Significado
Decrementar?
(no dar duracin explcita)
no disminuye
durante al menos el siguiente cuarto no disminuye

de hora
durante al menos la siguiente media disminuye despus de

hora
15 min
durante al menos la siguiente hora
disminuye despus de
30 min
durante al menos las siguientes dos disminuye despus de 1

horas
14
durante al menos las siguientes tres disminuye despus de 1

horas
durante al menos las siguientes disminuye despus de 1

cuatro horas
durante el resto del da
no disminuye
Tabla 1. Cdigos de duracin para periodos relacionados con el viaje actual del usuario final.
Se espera que algunos eventos duren largos periodos de tiempo (3). En caso
de eventos de informacin, estas duraciones se definen como Se espera que la
situacin contine ... , y se presentan en la Tabla 2.
Cdigo
Significado
Decrementar?
(no dar duracin explcita)
no disminuye
durante las siguientes horas
no disminuye
durante el resto del da
no disminuye
hasta maana por la tarde
disminuye a medianoche
durante el resto de la semana
disminuye el viernes a
medianoche
hasta el final de la semana que viene
disminuye el domingo a
medianoche
hasta finales de mes
no disminuye
durante un largo periodo
no disminuye
Tabla 2. Cdigos de duracin para largos periodos de tiempo.
3.1.2.5.
Aviso de desvo (1 bit):
El bit de desvo, incluido en mensajes de grupo nico, slo indica si se

recomienda a los usuarios finales que encuentren y sigan una ruta alternativa
15
alrededor del problema de trfic descrito en alguna parte del mensaje. Se define en
la Tabla 3.
Cdigo
Significado
No se recomienda desvo
Se recomienda evitar el rea si

es posible
Tabla 3. Definicin del campo Aviso de desvo.
Para mensajes multigrupo donde el bit de desvo no est presente, se define

un cdigo de control que tiene el mismo efecto que el bit de desvo. Con eventos
bidireccionales, se dan slo avisos de desvo predefinidos para una direccin (de la
localizacin secundaria a la primaria), puesto que no siempre es posible decidir si se
quiere un aviso de desvo en la direccin opuesta.
3.1.3.
Gestin de mensajes:
Existen dos tipos de mensajes: Mensajes de sistema y mensajes de usuario

(estos se explican en 3.1.4.3).
3.1.3.1.
Mensajes de sistema:
Se definen dos tipos de mensajes de sistema:

a) Informacin de sistema; e
b) Informacin de sintonizacin.
La informacin de sistema se transmite dentro de los grupos de tipo 3A con el
Identificador de Aplicacin (AID) para ALERT-C. A partir de 1996, la Oficina de
16
Registros RDS del RDS Forum (mximo organismo de decisiones relacionadas con
el RDS) le asign al ALERT-C el AID hCD46 (4). La informacin de sintonizacin2 se
transmite en el grupo tipo 8A en las variantes 4 a la 9:
X3 X0 = 0100 [4] a X3 X0 = 1000 [9], siempre con X4 = 1.
3.1.3.2.
Base de datos de localizaciones:
La informacin de sistema tambin se usa para indicar el ID de servicio del

transmisor y la base de datos de localizaciones a la que se refieren los cdigos de
localizacin en los mensajes del transmisor. (5) contiene una lista (tabla) de los
nmeros de bases de datos por pas; la Tabla de Localizaciones espaola es la N
17. A su vez, en (5) se establecen las maneras de especificar los lugares y
posiciones en los mensajes de TTI, incluyendo mensajes RDS-TMC, es decir, define
la estructura y semntica de las Tablas de Localizaciones para Centros de
Informacin de Trfico (TIC) y receptores.
3.1.3.3.
Requisitos de los terminales:
El reconocimiento de un servicio RDS-TMC se debe llevar a cabo mediante la

deteccin de un grupo de tipo 3A llevando el AID del ALERT-C. Los grupos de tipo
3A indican el grupo usado para llevar los mensajes RDS-TMC en ese canal, que
deben ser grupos del tipo 8A.
Se espera que un terminal sea capaz de almacenar en memoria por lo menos
300 mensajes RDS-TMC. Se requiere que los mensajes sean almacenados en el
terminal hasta que dejen de ser vlidos, sean actualizados o sean borrados. A su
vez, se espera que los proveedores de servicios se aseguren de que el nmero de
mensajes RDS-TMC que han transmitido, los cuales no han sido especficamente
cancelados o habrn concluido automticamente, no exceda el mximo de 300.
2
No se ofrecen en este proyecto mayores detalles sobre la informacin de sintonizacin, al no ser de

inters directo para el mismo. Para informacin relacionada, vase (2).
17
3.1.4. Transmisin:
3.1.4.1.
Formato de los grupos tipo 8A:
La informacin RDS-TMC se transmite en grupos RDS de tipo 8A. La Figura 2

muestra el formato de grupos de tipo 8A que se usan para transmitir todos los
mensajes RDS-TMC.
Figura 2. Grupos RDS tipo 8A, presentando la estructura definida para RDS/TMC.
Las secuencias de dos o ms grupos de tipo 8A se usan para transmitir

informacin adicional del contenido del mensaje. Cada mensaje RDS-TMC
multigrupo consta de un primer grupo con informacin bsica, que siempre se enva
primero, seguida de otros grupos en secuencia. El nmero mximo de grupos de que
consta cualquier mensaje RDS-TMC es cinco.
3.1.4.2.
Repeticin inmediata:
Se recomienda que los grupos se acepten como vlidos solamente despus

de que dos copias idnticas bit a bit (para los bits TMC, excepto obviamente el ndice
de continuidad) del mismo grupo hayan sido recibidas, por transmisin o por
repeticin de mensajes. El uso de correccin de errores RDS depende del fabricante
del terminal.
18
Para mensajes multigrupo, se repite el primer grupo, despus el segundo, etc.

Los grupos RDS diferentes a los grupos de tipo 8A pueden enviarse entre
repeticiones inmediatas, pero no debe enviarse ningn otro grupo de tipo 8A.
3.1.4.3.
Mensajes de usuario de grupo nico:
Los mensajes de usuario de grupo nico se indican en la seccin de

transmisin con dos bits en el Bloque 2, bit X4 y el identificador de mensaje de
usuario de grupo nico (bit X3). Estos bits se definen de la siguiente forma para
mensajes de grupo nico:
X4
X3
El bit X4 = 1 se utiliza para informacin de sintonizacin y para uso futuro. Los

campos de datos TMC de un mensaje se incluyen, en grupos nicos, segn se indica
en la Tabla 4.
Campo de datos
MSB
LSB
X2
X0
Aviso de desvo
Y15
Direccin
Y14
Extensin
Y13
Y11
Evento
Y10
Y0
Localizacin
Z15
Z0
Duracin / persistencia
Tabla 4. Campos de datos TMC incluidos en grupos nicos
Las asignaciones de bits a los campos de datos se ilustran en la Figura 3,

seguida de su leyenda.
19
Leyenda:
T = 0 indica mensaje de Usuario;
T = 1 indica Informacin de Sintonizacin (o reservado para uso futuro)
F = 0 indica mensaje multigrupo;
F = 1 indica mensaje de grupo nico
DP = valores de Duracin y Persistencia
D = 0 indica que no se recomienda desvo
D = 1 indica que se aconseja a los conductores seguir el desvo sugerido
+/- = 0 indica direccin positiva
+/- = 1 indica direccin negativa
Figura 3. Estructura completa de mensajes de grupo nico RDS-TMC
3.1.4.4.
Mensajes de Sistema:
Como se introdujo antes, se definen dos tipos de mensajes de sistema:

Informacin de sistema e informacin de sintonizacin.
20
3.1.4.4.1.
Informacin de sistema:
El RDS-TMC se define dentro del sistema RDS para utilizar una Aplicacin de
Datos Abierta (ODA3), que inherentemente requiere grupos RDS de tipo 3A para
indicar la presencia de RDS-TMC. Por definicin ODA se asigna a un ID de
aplicacin (hCD46) y adicionalmente, en el caso del RDS-TMC, se usa el grupo tipo
8A. La Informacin de Sistema permite a un producto RDS-TMC descifrar y evaluar
datos fundamentales, que describen la transmisin que est siendo recibida.
3.1.4.4.1.1. Formato de la Informacin de Sistema en el grupo tipo 3A:

La Informacin de Sistema se transmite en las variantes 0 (Y14 = 0) y 1 (Y14 =
1) del Bloque 3 del grupo tipo 3A (vase la Figura 4).
Leyenda:
LTN = Nmero de Tabla de Localizaciones (6 bits)
AFI = Indicador de Frecuencia Alternativa (1 bit)
MGS = Campo de Aplicacin Geogrfica de Mensaje (un total de 4 bits)
3
En la siguiente seccin se harn comentarios sobre las ODA.
21
I = Internacional (INTER-ROAD) (1 bit)

N = Nacional (1 bit)
R = Regional (1 bit)
U = Urbano (1 bit)
SID = Identificador de Servicio (6 bits)
rfu = reserved for future use
G = Parmetro de intervalo de tiempo (2 bits)
M = Modo de Transmisin (1 bit)
si M = 1
Ta = Tiempo de actividad (2 bits)
Tw = Tiempo de ventana (2 bits)
Td = Tiempo de retraso (2 bits)
Figura 4. Estructura de los grupos tipo 3A, transportando informacin de sistema RDS-TMC.
La Informacin de Sistema suministrada consta del LTN (Nmero Tabla de

Localizaciones), un AFI (Indicador de Frecuencia Alternativa), un MGS (Campo de
Aplicacin Geogrfica de Mensaje) y un SID (Identificador de Servicio). En (5) se
especifican los LTNs asignados a cada pas.
Si todas las frecuencias de una red de programas (igual al cdigo PI) llevan el
mismo servicio RDS-TMC, entonces el AFI se debera fijar en AFI = 1. En todos los
dems casos el AFI debera ser 0. Los cuatro bits del MGS (campo de Cobertura
Geogrfica de Mensaje) indican la relevancia geogrfica del servicio RDS-TMC; la
cual se establece fijando el bit respectivo en 1, y es la siguiente: Internacional,
Nacional, Regional y Urbano.
El SID identifica el proveedor de servicios de datos, y debera ser asignado
nicamente a nivel nacional. Su significado es:
- 0 = servicio general;
- todos los dems nmeros = servicio especfico.
22
El terminal receptor contiene una lista de todos los SID admisibles, cuyos
significados son entonces:
- 0 = acepta un servicio de cualquier estacin; o
- todos los dems SID = sintoniza el servicio especfico
Puede haber hasta 63 SID posibles, puesto que el SID = 0 se reserva para
servicios generales que permitirn a los terminales recibir informacin por razones de
seguridad del trfico.
3.1.4.4.1.2. Modos de transmisin RDS-TMC:

Un servicio RDS-TMC a lo largo de un rea o pas usar probablemente una
red de transmisores, que puede o no corresponder a la red usada para proveer un
servicio de audio. Al igual que el receptor de audio RDS, el terminal RDS-TMC
necesitar evaluar frecuencias y sintonizar con los trasmisores que provean la seal
ptima. Para que un terminal pueda evaluar frecuencias alternativas para el servicio
RDS-TMC sin perder ningn mensaje, se establecieron intervalos de tiempo
previsibles entre grupos RDS-TMC sucesivos en el flujo de datos. El terminal puede
aprovechar estos intervalos para la evaluacin de frecuencias y resintonizacin.
La transmisin de RDS-TMC en el flujo de datos RDS est planificada tal
manera que estn siempre presentes intervalos cortos entre dos grupos de tipo 8A
(este es el llamado Modo Bsico). Un modo de transmisin adicional, el Modo
Intensificado, suprime completamente la transmisin de grupos de tipo 8A en
momentos previstos y regulares, para crear intervalos extendidos entre grupos de
tipo 8A sucesivos.
23
3.1.4.4.1.2.1.Modo Bsico:
El modo bsico se indica fijando el bit de Modo M (Y4) en la variante 0 del

grupo de tipo 3A a 0. El intervalo Bsico entre grupos de tipo 8A se da
explcitamente mediante el valor del parmetro G trasmitido mediante los bits Y13 y
Y12 en la variante 1 del grupo de tipo 3A. Estos dos bits permiten que sean indicados
cuatro tamaos alternativos de intervalo entre grupos 8A, como se muestra en la
tabla 5, as como el nmero medio de grupos de tipo 8A trasmitidos para cada
tamao de intervalo.
Cdigo Binario
Intervalo (grupos)
Media de grupos 8A
por segundo
00
2,85
01
1,90
10
1,27
11
11
0,95
Tabla 5. Codificacin del parmetro de intervalo G.
Aunque es posible transmitir una media de hasta 2,85 grupos/segundo de tipo

8A, no ms de 2,5 de stos deberan ser mensajes de usuario para limitar las
capacidades de procesamiento requeridas en el terminal.
3.1.4.4.1.2.2.El modo intensificado:
El modo intensificado se indica poniendo el bit de Modo M (Y4) en la variante
0 del grupo de tipo 3A a 1. En el modo intensificado, tambin llamado modo
Spinning Wheel (Rueda Giratoria), se planifica que en momentos previstos de un
ciclo de un minuto, no se emita ningn grupo de tipo 8A. Se crean as intervalos ms
grandes entre grupos de tipo 8A sucesivos, durante los cuales puede producirse
24
operaciones de bsqueda de PI, sabiendo que los datos TMC no estn siendo
perdidos. Estos largos intervalos, o ventanas, se crean del siguiente modo:
- Se divide cada minuto en un nmero entero de espacios de tiempo; y
- Se separa cada uno de estos espacios de tiempo en dos partes, un tiempo de
actividad (Ta) durante el cual los grupos de tipo 8A pueden ser trasmitidos, y la
ventana de tiempo (Tw) durante la cual se suspende la transmisin de grupos de
tipo 8A.
La Figura 5 presenta los intervalos de tiempo y estructura del modo
Intensificado.
Figura 5. Espacios de tiempo del modo Intensificado RDS-TMC y estructura.
Ningn grupo de tipo 8A debera comenzar durante la ventana de tiempo;

pero se puede completar un grupo de tipo 8A que ya hubiera comenzado durante el
tiempo de actividad. Ambos Ta y Tw son nmeros enteros de segundos y adems
tienen que cumplir la siguiente ecuacin:
60 (segundos)/( Ta + Tw) = n (donde n es un nmero entero > 0)
25
Para que un terminal pueda aprovechar las ventanas para buscar el PI y

otras tareas, su tamao y posicin en el ciclo del minuto debe ser comunicado al
terminal. Esto se consigue mediante tres parmetros transmitidos en la variante 1 del
grupo de tipo 3A, que da el tamao del tiempo de actividad, ventana de tiempo y
posicin de comienzo de la secuencia actividad/ventana, referenciado desde el lmite
del minuto, referido como el tiempo de retraso (Td). El dato del lmite del minuto se
determina a partir de los grupos de tipo 4A Hora de reloj (CT).
Las tablas 6, 7 y 8 muestran los valores permitidos para Td, Ta y Tw
respectivamente (no todas las combinaciones de estos parmetros dan opciones
vlidas).
Cdigo binario
Td (segundos)
Cdigo binario
Ta (segundos)
00
00
01
01
10
10
11
11
Tabla 6. Codificacin de Td
Tabla 7. Codificacin de Ta
Cdigo binario
Tw (segundos)
00
01
10
11
8
Tabla 8. Codificacin de Tw
26
3.2. RDS:
En general, la transmisin actual del TMC se realiza empleando el Sistema de
Datos de Radio (RDS), un estndar empleado por la EBU para enviar cantidades
pequeas de informacin digital usando las trasmisiones convencionales de radio
FM. El Sistema de Datos de Radio, RDS, ha sido diseado para utilizarse en
transmisiones VHF/FM en el rango de 87,5 a 108,0 MHz, en el cual se pueden enviar
programas estereofnicos (sistema del tono-piloto) o monofnicos. Los objetivos
principales del RDS son ofrecer funcionalidades mejoradas a los receptores FM y
hacerlos ms amigables al usar caractersticas como identificacin de programa (PI),
exhibicin del nombre del servicio del programa (PS) y, donde est disponible,
sintonizacin automtica para radios porttiles y, particularmente, de vehculos (6).
3.2.1. Caractersticas de modulacin del canal de datos (Capa Fsica):

Como se mencion anteriormente, el RDS se dise para utilizarse en
transmisiones VHF/FM en el rango de 87,5 a 108,0 MHz, en el cual se pueden enviar
programas estereofnicos (sistema del tono-piloto) o monofnicos. Las seales de
datos se envan en una subportadora que se aade a la seal mltiplex estreo (o a
la seal monofnica, segn corresponda) en la entrada del transmisor VHF/FM. En
las figuras 6 y 7 se muestras los diagramas de bloques de la fuente de datos en el
transmisor, y un arreglo tpico del receptor, respectivamente.
27
Figura 6. Diagrama de bloques de un equipo de radio-datos en el transmisor.
Figura
7. Diagrama de bloques de un receptor/decodificador de radio-datos.
28
3.2.1.1.
Frecuencia de la subportadora:
Durante transmisiones estreo, la frecuencia de la subportadora estar

enganchada al tercer armnico del tono-piloto de 19KHz. Puesto que la tolerancia de
la frecuencia de dicho tono es 2 Hz (6), la tolerancia de la frecuencia de la
subportadora durante transmisiones estreo ser 6Hz.
3.2.1.2.
Fase de la subportadora:
Durante transmisiones estreo, la subportadora estar enganchada, bien sea

en fase o en cuadratura, al tercer armnico del tono piloto de 19 KHz. La tolerancia
en este ngulo de la fase es 10 (6).
3.2.1.3.
Mtodo de modulacin:
La subportadora es modulada en amplitud por la seal de datos. La forma de

esta ha sido modificada, y se le ha aplicado codificacin bifsica.
3.2.1.4.
Frecuencia del reloj y tasa de datos:
La frecuencia de reloj bsica se obtiene al dividir la frecuencia de la

subportadora transmitida entre 48. As, la tasa de datos bsica del sistema es 1187,5
bps 0,125 bps. Esto se puede ver en la Figura 6.
3.2.1.5.
Codificacin diferencial:
Los datos de la fuente en el transmisor son codificados diferencialmente segn

las reglas expuestas en la tabla 9.
29
Salida previa
Nueva entrada
Nueva salida
(en t = ti-1)
(en t = ti)
(en t = ti)
Tabla 9. Reglas de codificacin de los datos de fuente en la transmisin RDS.
En la Tabla 9, ti es un tiempo arbitrario, y ti-1 ocurre un perodo de reloj (de los

datos de mensaje) antes. Como se dijo en el apartado anterior, la tasa del reloj de los
datos del mensaje es de 1187,5 Hz. Se observa entonces que cuando el nivel de
datos en la entrada es 0, la salida no cambia (se conserva el valor del bit de salida
previo), y cuando el nivel de datos en la entrada es 1, la nueva salida ser el
complemento del valor de salida previo. La Tabla 10 presenta las reglas de
decodificacin en el receptor:
Entrada previa
Nueva entrada
Nueva salida
(en t = ti-1)
(en t = ti)
(en t = ti)
Tabla 10. Reglas de decodificacin de los datos en el receptor.
Los datos son decodificados correctamente, an si la seal de datos

demodulada ha sido invertida o no.
30
3.2.1.6.
Modelado del espectro del canal de datos:
La potencia de la seal de datos en y cerca de la subportadora de 57 KHz

se minimiza al codificar cada bit de datos de la fuente como un smbolo bifsico. Esto
se hace para evitar el cross-talk en los decodificadores estreo enganchados en fase
(6). El principio del proceso mediante el cual se generan los smbolos se observa
esquemticamente en la Figura 6. Conceptualmente, cada bit de fuente da lugar a
una pareja de impulsos impar e(t) , de tal manera que un 1 en la fuente genera:
e(t) = (t) - (t td/2)
Por su parte, un 0 genera:
e(t) = - (t) + (t td/2)
Estas parejas de impulsos son posteriormente modeladas por un filtro HT(f),
para obtener el espectro requerido de banda limitada, tal que,
cos(ftd/4)
; si 0 f 2/td
; si f > 2/td
HT(f) =
Donde td tiene un valor de 1 / 1187,5 segundos. La figura 8 ilustra las

respuestas de los filtros pasa-bajo de los transmisores y receptores, segn la
ecuacin previa de HT(f).
31
Figura 8. Respuesta en amplitud del filtro pasa-bajo de un transmisor o un receptor.
El espectro de la seal de radio/datos transmitida, codificada bifsicamente, se

presenta en la Figura 9. La Figura 10 presenta la funcin en el tiempo de un smbolo
bifsico, tal como es transmitido.
Figura 9. Espectro de las seales radio/datos codificadas bifsicamente.
32
Figura 10. Funcin en el tiempo de un smbolo bifsico.
A su vez, la forma de onda de la seal de radio/datos de 57 KHz a la salida

puede observarse en la fotografa de la Figura 11.
Figura 11. Seales radio/datos de 57 KHz.
33
3.2.2. Codificacin en banda base (Capa de Enlace de Datos):
3.2.2.1.
Estructura de la codificacin en banda base:
La figura 12 presenta la estructura de la codificacin en banda base. El

elemento ms grande es llamado grupo, con 104 bits. Cada grupo est compuesto
por 4 bloques de 26 bits cada uno. Cada bloque contiene una palabra de informacin
de 16 bits y una checkword4 (para deteccin y correccin de errores), de 10 bits.
Figura 12. Estructura de la codificacin en banda base.
Todas las palabras de informacin, checkwords, nmeros binarios o valores

de direcciones binarias son enviadas empezando por su bit ms significativo (m.s.b.)
(vase la Figura 13). La transmisin de datos es completamente sncrona y no hay
intervalos entre los bloques.
Ms detalles sobre la checkword en 3.2.2.2.
34
Comentarios de la Figura 13:

1. Cdigo del tipo de grupo = 4 bits
2. Bo = cdigo de la versin = 1 bit
3. Cdigo PI = cdigo de Identificacin del Programa = 16 bits
4. TP = cdigo de identificacin de Programa de Trfico = 1 bit
5. PTY = cdigo del Tipo de Programa = 5 bits
6. Checkword + offset N = 10 bits
7. t1 < t2 : El bloque 1 de cualquier grupo se transmite de primero, y el bloque 4 de ltimo.
Figura 13. Formato y direccionamiento de los mensajes.
3.2.2.2.
Proteccin de errores
Cada bloque transmitido contiene una checkword de 10 bits, cuyo propsito es

permitir al receptor/decodificador detectar y corregir errores que ocurran durante la
transmisin. La checkword es la suma (mdulo 2) de:
a) El residuo tras la multiplicacin por x10, y luego la divisin (mdulo 2) por el
polinomio generador g(x), de la palabra de informacin del bloque, y
b) Una cadena de 10 bits d(x) llamada offset word.
35
El polinomio generador g(x) viene dado por:

g(x) = x10 + x8 + x7 + x5 + x4 + x3 + 1
,y los valores de offset d(x) diferentes para cada bloque se indican en (6).
El objeto de aadir la palabra de offset es proveer al receptor/decodificador de
un sistema de sincronizacin de grupos y bloques. Dado que la adicin de dicho
offset es reversible en el decodificador, las propiedades normales de deteccin y
correccin de errores del cdigo bsico no se ven afectadas.
De acuerdo con (6), el cdigo de proteccin de errores tiene las siguientes
caractersticas en cuanto a deteccin de errores:
a) Detecta todos los errores sencillos y dobles de bits en un bloque.
b) Detecta cualquier burst (rfaga) de error que afecte a 10 bits o menos.
c) Detecta cerca del 99.8 % de las rfagas que afecten a 11 bits, y alrededor del
99.9 % de de todas las rfagas mayores.
El cdigo tambin es ptimo para corregir errores de rfagas (6), y es capaz de
corregir cualquier rfaga que afecte a 5 bits o menos.
3.2.2.3.
Sincronizacin de bloques y grupos:
Los bloques dentro de cada grupo se identifican por las palabras de offset A,
B, C (o C) y D, aadidas a los bloques 1, 2, 3 y 4 respectivamente en cada grupo. El
principio y final de cada bloque son reconocidos por el receptor/decodificador
basndose en que el decodificador (detector de errores) detectar, con bastante
seguridad, fallos de sincronizacin de bloques, as como errores aditivos. Este
sistema de sincronizacin de bloques se torna confiable al aadir las palabras de
offset, las cuales tambin sirven para identificar los bloques dentro del grupo.
36
3.2.3. Formato de los mensajes (Capas de Sesin y Presentacin):

3.2.3.1.
Caractersticas principales:
Observando la Figura 9 se puede sealar que las caractersticas principales

de la estructura de los mensajes son:
a) El primer bloque de cada grupo siempre contiene un cdigo de Identificacin
del Programa (PI).
b) Los primeros cuatro bits del segundo bloque de cada grupo contienen un
cdigo que identifica la aplicacin del grupo, con lo cual hay 16 grupos
posibles, identificados como tipos 0 al 15. Cada grupo tiene dos versiones,
identificadas por el quinto bit (Bo) del bloque 2; a saber:
-
Bo = 0: El cdigo PI slo se inserta en el bloque 1. Esta versin se conoce

como A.
Bo = 1: El cdigo PI se inserta en los bloques 1 y 3. Esta es la versin B.

En general, cualquier combinacin de grupos tipo A y B puede ser
transmitida.
c) Los cdigos del Tipo de Programa (PTY) y de identificacin de Programa de

Trfico (TP) ocupan posiciones fijas en el bloque 3 de cada grupo.
Los cdigos PI, PTY y TP pueden decodificarse sin referenciar a ningn bloque
fuera de aquel en que se encuentra. Esto es fundamental para minimizar los tiempos
de adquisicin y para conservar las ventajas de la pequea longitud de los bloques
(26 bits). Para que esta idea tambin se pueda aplicar a los cdigos PI en los
bloques 3 de los grupos versin B, se ha definido una palabra de offset especial
llamada C , usada slo en los bloques 3 de los grupos versin B.
37
De esta manera, la presencia del offset C en el bloque 3 de cualquier grupo

permite identificar directamente que dicho bloque 3 es un cdigo PI; es decir, no
hace falta conocer el valor del bit Bo del bloque 2.
3.2.3.2.
Tipos de grupos:
Existen, en concordancia con lo explicado en el apartado anterior, 32 grupos

posibles, numerados desde el 0A hasta el 15B. Las aplicaciones de cada uno se
explican en (6); sin embargo, la Tabla 11 describe los grupos 3A y 8A, por ser
relevantes dentro del contexto de este proyecto.
Tipo de Cdigo del tipo de grupo / Versin
Descripcin
Grupo
A3
A2
A1
A0
B0
3A
Identificacin aplicaciones slo ODA
8A
TMC o ODA
Tabla 11. Cdigo de grupo/versin y descripcin de los grupos 3A y 8A.
3.2.3.3.
Aplicaciones de Datos Abiertas (ODA):
Han sido diseadas para hacer al sistema RDS fcilmente ampliable y para
poder implementar servicios de datos adicionales de manera rpida, sin necesidad
de modificar el estndar explcitamente para ello. Por esta misma razn, no estn
especificadas en (6); de hecho, estn sujetas a un proceso de registro, y las
aplicaciones aprobadas se presentan en el Directorio ODA del EBU/RDS Forum.
Las ODAs pueden usar las versiones A y/o B de los grupos, pero no son
diseadas para trabajar con un grupo especfico. El grupo empleado por una ODA en
una transmisin cualquiera debe ser indicado en el campo AID de los grupos tipo 3A.
38
3.2.3.3.1. Estructura de los grupos:

Las ODAs deben usar el formato de la Figura 14 para la versin A de los
grupos, y el de la Figura 15 para la versin B.
Figura 14. Grupos ODA versin A.
Figura 15. Grupos ODA versin B.
El formato y la aplicacin de los bits de mensajes de las ODAs son asignados

libremente por cada operador.
3.2.3.4.
Codificacin de los tipos de grupos5:
3.2.3.4.1. Grupos tipo 3A: Identificacin de ODAs
La Figura 16 presenta el formato de los grupos tipo 3A, empleados para

identificar la ODA en uso.
5
Slo se explicar la codificacin de los grupos tipo 3A y tipo 8A, por ser los concernientes a este
proyecto. Las dems codificaciones pueden ser consultadas en (6).
39
Figura 16. Formato de los grupos 3A / AID para ODAs.
Los grupos 3A suministran a los receptores informacin sobre cul ODA se

enva en una transmisin dada, y en qu grupos se encuentra. El grupo 3A posee
tres elementos: el cdigo del tipo de grupo de la ODA, 16 bits de mensajes propios
de esta, y el cdigo de Identificacin de la Aplicacin (AID). El cdigo del tipo de
Grupo de la Aplicacin indica el tipo de grupo usado, en la transmisin dada, para
portar la ODA especfica. El AID determina cul software necesita usar el receptor.
El AID h0000 se emplea para indicar que el tipo de grupo sealado se est
usando para su propsito normal, segn se especifica en (6). El resto de los AIDs
posibles (h0001 hasta hFFFF) indican las aplicaciones determinadas, especificadas
en el Directorio ODA.
3.2.3.4.2. Grupos tipo 8A: Traffic Message Channel o ODAs:
En la Figura 17 se muestra el formato de los grupos tipo 8A, siendo usados

para TMC (el detalle de los bits de mensaje se presenta en la Figura 3). En caso de
emplearse para ODAs, vase la Figura 14.
40
Figura 17. Formato de los grupos 8A / TMC.
3.2.4. Descripcin de las caractersticas ms importantes del RDS:
3.2.4.1.
Lista de Frecuencias Alternativas (AF):
Las listas de frecuencias alternativas proporcionan informacin sobre los

distintos transmisores que emiten el mismo programa en la misma rea de recepcin
(o en reas adyacentes), y permita los receptores almacenar las listas, para reducir
el tiempo que toma cambiar a otro transmisor.
3.2.4.2.
Hora y Fecha (CT):
Los cdigos de tiempo y fecha utilizan el Tiempo Universal Coordinado (UTC)

y el Da Juliano Modificado (MJD), y son necesarios para actualizar un reloj corriendo
libremente en el receptor. Los detalles de estos cdigos se explican en (6). La
conversin a la hora y fecha locales es hecha por el receptor. El CT es utilizado
como marca de tiempo por varias aplicaciones RDS, por tanto debe ser preciso.
3.2.4.3.
Aplicaciones internas (IH):
Son aquellos datos que deben ser decodificados slo por el operador, tales
como la identificacin del origen de transmisin, llamadas al personal, etc. Las
aplicaciones de la codificacin pueden ser decididas por cada operador.
41
3.2.4.4.
Indicador de Locucin o Msica (MS):
Es una seal de dos estados que indica si se est transmitiendo msica o voz
(habla de los locutores). La seal es til para los receptores equipados con dos
controles de volumen separados uno para msica y uno para locucin , pues el
oyente puede ajustar el balance entre ellos segn sus intereses.
3.2.4.5.
Identificacin del Programa (PI):
Es un cdigo que permite al receptor distinguir entre pases, reas en las

cuales se transmite un mismo programa, y la identificacin propia del programa. El
cdigo es asignado a cada programa de radio, para permitirle ser distinguido de los
dems programas. Una aplicacin importante del PI es el permitir al receptor buscar
automticamente una frecuencia alternativa en caso de que el programa actual tenga
mala recepcin. El criterio para cambiar a otra frecuencia sera conseguir una mejor
seal con el mismo PI.
3.2.4.6.
Nombre del Servicio de Programa (PS):
Es el identificativo del servicio de programa. Consiste en no ms de ocho

caracteres alfanumricos codificados segn (6), y es mostrado por los receptores
para informar al oyente cul servicio de programa est siendo transmitido por la
estacin sintonizada. El PS no ha sido diseado para sintonizaciones automticas, y
no debe ser utilizado para dar informaciones secuenciales.
3.2.4.7.
Tipo de Programa (PTY):
Es un nmero de identificacin transmitido con cada programa, diseado para

especificar el Tipo de Programa actual de entre 31 posibilidades, listadas en (6).
42
Algunas de los tipos existentes son: Noticias, deportes, msica pop, finanzas, el
tiempo, etc. El PTY puede ser utilizado para bsquedas, y ms an, permite a los
receptores apropiados ser configurados para responder solamente a programas del
tipo deseado.
3.2.4.8.
Nombre del Tipo de Programa (PTYN):
El PTYN se utiliza para describir en mayor medida el PTY actual, pues permite
al radiodifusor dar ms detalles libremente sobre aquel, por ejemplo: PTY = 4 :
Deporte y PTYN: Ftbol. El PTYN no est diseado para cambiar los ocho caracteres
de PTY; slo para mostrar detalladamente el tipo de programa una vez sintonizado.
El PTYN tampoco puede ser utilizado para seleccin automtica de PTYs, y no debe
ser utilizado para dar informaciones secuenciales.
3.2.4.9.
Radio Paging (RP):
Tiene por fin ofrecer radio paging (convocatorias va radio, buscapersonas)

usando las transmisiones existentes VHF/FM como mecanismo de transporte,
evitando as la necesidad de una red de transmisores
especializada. Los
subscriptores de este servicio requieren un receptor especial de bolsillo en el que se

almacena la direccin del subscriptor.
3.2.4.10. Radio Text (RT):
Son transmisiones de texto codificado segn (6), dirigidas principalmente a
receptores en hogares, los cuales disponen de mejores caractersticas para su
presentacin. Su utilizacin para receptores dentro de vehculos podra distraer a los
conductores.
43
3.2.4.11. Identificacin de Anuncios de Trfico (TA):

Es una seal de dos estados que indica la presencia de un anuncio de trfico
en el aire. Puede ser usada por los receptores para:
-
Cambiar automticamente de cualquier modo de audio al anuncio de trfico;
Reproducir automticamente el anuncio de trfico cuando el receptor est en

modo de espera y la seal de audio est en silencio.
Cambiar de un programa a otro que contenga un anuncio de trfico.
Tras acabar el anuncio, el receptor vuelve al modo inicial en el que se

encontraba.
3.2.4.12. Identificacin de Programa de Trfico (TP):
Es una seal empleada para indicar que el programa sintonizado emite
anuncios de trfico. Tambin es tomada en cuenta durante sintonizaciones
automticas.
3.3. UECP SPB 490:
El estndar UECP SPB 490 tiene por objeto satisfacer la necesidad de

protocolos de comunicacin de codificadores RDS, que faciliten la interoperabilidad
entre los distintos componentes de los sistemas RDS, tales como servidores RDS,
puentes de datos y codificadores, sin importar el fabricante. Adems, armoniza los
ambientes de red (7) y establece un modelo de codificador, para facilitar el
intercambio de las partes constituyentes de los sistemas de redes RDS. As mismo,
describe un protocolo universal por capas, basado en la recomendacin ISO/OSI,
que aplica a todas las caractersticas actuales de los sistemas RDS.
44
3.3.1. Modelo estructural:
3.3.1.1. Mtodo de direccionamiento:

La
comunicacin
entre
codificadores
RDS
requiere
niveles
de
direccionamiento: a todos los codificadores, a un conjunto especfico de ellos, o a un

codificador en particular. Esto requiere un mtodo apropiado de direccionamiento
lgico. Cada sitio de transmisores tendr una direccin nica, llamada site address
(direccin del sitio), dentro del rango 1-1023. Todos los codificadores en un mismo
sitio de transmisores comparten la misma site address. Un codificador puede tener
una o ms site addresses, una de las cuales debe ser nica al lugar fsico en que se
encuentra (el correspondiente sitio de transmisores). Las dems, abarcarn un rea
o regin definida, e incluso el pas. La Figura 18 ejemplifica esto.
Figura 18. Ejemplo ficticio de direccionamiento a distintos sitios.
Todos los codificadores en Lleida tienen una site address = 123. Esta
direccin est prohibida para otros codificadores. Tambin tienen la site address 267,
correspondiente a todos los codificadores dentro de Catalunya. Los mensajes que
lleguen a Lleida con alguna de estas direcciones sern aceptados. Anlogamente,
los mensajes que lleguen a Barcelona (site address = 452) slo sern aceptados si
tienen esta direccin o la de Catalunya, pero no de la Lleida.
45
En cada sitio de transmisores se instalan varios codificadores RDS, para

distintos servicios de programa. Cada codificador en el sitio necesita ser
individualmente direccionable, por lo que se introduce un segundo nivel de
direccionamiento, la encoder address (direccin del codificador), dentro del rango 163.
Tambin hay que tener presente que todos los codificadores RDS recibirn
muchos mensajes, por lo que se ha definido el nmero global 0 tanto para la site
address como para la encoder address. As, los mensajes que tengan la site address
global sern aceptados en todos los sitios dentro de la red. Por su parte, los
mensajes con la encoder address global sern aceptados por todos los codificadores
en los sitios especificados por la site address respectiva.
3.3.1.2. Modelo del Hardware:
La Figura 19 presenta un modelo simplificado de un codificador RDS.
Figura 19. Modelo de hardware de un codificador RDS.
46
El modelo no incluye componentes elementales, como una fuente de poder o

un panel de control; incluye solamente aquellos bloques necesarios para entender el
protocolo. Estos son:
-
Procesador: La unidad central de procesamiento (CPU) del codificador

(usualmente un microprocesador), con acceso a dispositivos de entrada y
salida, el reloj y la memoria.
Memoria: Incluye las ROM (Read Only Memory) y RAM (Random Access
Memory) necesarias para el propio software del codificador, y las RAM,
NVRAM (Non-volatile RAM) y ROM para datos almacenados.
Reloj: Mantiene la hora y fecha actual. Es usado para generar los grupos tipo
4A (CT).
Interfaz de comunicacin serial: El protocolo establece que los datos se

reciben y envan usando esta interfaz.
Modulador RDS: Produce la seal RDS bifsica.
Oscilador de 57 KHz: La frecuencia y fase estn enganchadas al tercer

armnico de la fuente de referencia seleccionada.
Selector de referencia: Es opcional. Selecciona una fuente de referencia de 19

KHz, de entre un mximo de seis. Cada una de ellas corresponde a un ajuste
especfico de nivel y de fase de la seal de salida producida.
Control de nivel y fase: El nivel de salida puede fijarse en un rango de 0 a

8191 mV, y la fase dentro del rango de 0 a 360, aunque sus valores pueden
depender de la fuente de referencia de 19 KHz.
3.3.1.3. Modos de transmisin:

-
Modo unidireccional: Empleado en enlaces de comunicaciones en un sentido.

Los datos son transmitidos a uno, un grupo o todos los codificadores; no se
requiere respuesta por parte de estos.
47
Modo
bidireccional,
respuesta
solicitada:
Empleado
en
enlaces
de
comunicaciones en ambos sentidos. Los datos son transmitidos a uno, un

grupo o todos los codificadores. Permite al servidor solicitar datos, estado, y
reportes de error a los codificadores.
-
Modo bidireccional, respuesta espontnea: Empleado en enlaces de

comunicaciones en ambos sentidos. El servidor transmite y solicita datos a los
codificadores. Estos tambin pueden generar espontneamente mensajes de
error y de estado.
3.3.2. Descripcin del protocolo:
3.3.2.1. Capa Fsica:

La interfaz con el codificador se realiza mediante una interfaz serial basada en
el estndar RS 232. Es una interfaz full-duplex, con handshaking en el hardware,
capaz de inter-operar con mdems.
3.3.2.1.1. Especificaciones mecnicas:
El codificador est equipado bien con los conectores SUB-D de 25 pines o de

9 pines (preferido). La interfaz se disea como un Equipo Terminal de Datos (DTE),
por lo que todos los conectores deberan ser de tipo macho. Las seales del conector
de 9 pines para el DTE se presentan en la Tabla 12. Las seales del conector de 25
pines, as como su descripcin, se pueden consultar en (7).
Pin
Seal
E/S
Descripcin
DCD
Data Carrier Detect (opcional)
RxD
Received Data
TxD
Transmitted Data
48
DTR
Data Terminal Ready
GND
Signal Ground
DSR
Data Set Ready
RTS
Request to Send
CTS
Clear to Send
RI/+5...+15V
E/S
Ring Indicator (opcional), o Fuente de voltaje

auxiliar (opcional)
Tabla 12. Seales del conector de 9 pines para el DTE.
La funcionalidad de las seales es la siguiente:

-
DCD (Data Carrier Detect): Puede ser evaluada para detectar un mdem
activo.
RxD (Received Data): Datos de un dispositivo externo al decodificador.
TxD (Transmitted Data): Datos del codificador a un dispositivo externo.
DTR (Data Terminal Ready): Cuando est activa, sirve para indicarle a un
dispositivo externo que el codificador est listo para operar. Tambin suele ser
llamada handshake esttico (7).
GND (Signal Ground): Tierra analgica de la circuitera.
DSR (Data Set Ready): Cuando est activa, sirve para indicarle al codificador
que un dispositivo externo est listo para operar. Tambin suele ser llamada
handshake esttico.
RTS (Request to Send): Cuando est inactiva, sirve para indicarle a un

dispositivo externo que pare la transmisin de datos en RxD hasta que RTS se
active nuevamente. Tambin suele ser llamada handshake dinmico (7).
CTS (Clear to Send): Cuando est inactiva, sirve para indicarle al codificador
que pare la transmisin de datos en TxD hasta que CTS se active
nuevamente. Tambin suele ser llamada handshake dinmico.
49
RI (Ring Indicator): Puede ser evaluada para detectar una llamada entrante de
un modem.
+5...+15V (Fuente de voltaje auxiliar): Puede ser usada para dispositivos de

bajo consumo, tales como conversores de nivel o dispositivos de fibra ptica.
Debe ser limitada en corriente.
3.3.2.1.2. Formato de los datos:
Los datos son transmitidos caracter por caracter de manera asncrona. Se

envan caracteres de 8 bits, antecedidos por 1 bit de inicio y luego seguidos por 1 bit
de parada. No se incluye bit de paridad. Cualquiera de las siguientes velocidades de
transmisin estndar son vlidas: 75, 150, 300, 600, 1200, 2400, 4800, 9600 y
19200, 38400, 57600, 115200 bps.
3.3.2.2. Capa de Enlace de Datos:
La informacin est compuesta por un flujo de tramas de datos. A su vez, las
tramas estn compuestas por una serie de bytes, delimitada por dos bytes
reservados, los cuales marcan el inicio y fin de la trama. Cada trama contiene una
direccin de destino (la cual define el conjunto de codificadores a los que se enva la
trama), un contador de secuencia (el cual etiqueta cada trama), el mensaje como tal
(el cual es precedido por un byte que define su longitud), y un cdigo de redundancia
cclica (CRC). La Figura 20 muestra el formato de las tramas6.
Los campos dentro de llaves [ ] son opcionales; su inclusin viene definida por el Message Element
Code.
50
Figura 20. Formato de las tramas SPB.
Los bytes de inicio y fin son nicos, y no pueden ocurrir en ningn otro campo
de la trama. Para prevenir esto, se aplica la tcnica de Byte-stuffing, la cual
transforma cualquier ocurrencia ilegal de los bytes reservados en dos bytes
permitidos. En la recepcin se aplica el proceso contrario: Las tramas a las que se
les ha aplicado Byte-stuffing son convertidas antes de ser procesadas. De esta
manera se consigue usar libremente cualquier byte dentro de los mensajes. Vale
comentar que la longitud de los mensajes se define siempre en su estado ms corto
(antes de aplicar la tcnica).
3.3.2.2.1. Formato general de las tramas:
En la Tabla 13 se presenta el formato de las tramas.
Descripcin del campo
Siglas
Longitud
Start
STA
1 byte
Address
ADD
2 bytes
51
Sequence Counter
SQC
1 byte
Message field length
MFL
1 byte
Message
MSG
0...255 bytes
Cyclic Redundancy Check
CRC
2 bytes
Stop
STP
1 byte
Tabla 13. Detalle del formato de las tramas SPB.
3.3.2.2.2. Start:
Todas las tramas comienzan con el byte de inicio hFE. Tras aplicar la tcnica
de Byte-stuffing, se garantiza que este no ocurrir en ningn otro campo de la trama.
3.3.2.2.3. Address:
Est compuesto por dos elementos: La site address (los 10 bits ms

significativos) y la encoder address (los 6 bits menos significativos).
-
Site address: Indica el sitio o grupo de sitios al que se enva la trama. Se

define as:
Todos los sitios
h1-h3FF
Sitio o grupo de sitios especfico
Encoder address: Indica a cul(es) codificadores, dentro de un sitio especfico,

se le(s) est enviando la trama. Se define as:
0
Todos los codificadores en el sitio
h1-h3FF
Codificador
especfico.
grupo
de
codificadores
52
Cada codificador reconoce una o ms encoder addresses. Una de ellas ser

nica (dentro del sitio determinado); las dems pueden ser comunes a otros
codificadores.
3.3.2.2.4. Sequence Counter:
A cada trama transmitida se le puede asignar un nmero secuencial en el

rango h01-hFF. Por su parte, a las repeticiones de una trama que ocurren con el fin
de aumentar la fiabilidad de los datos en un sistema simples, o por peticin en uno
duplex se les puede asignar el SQC original. Si no es utilizado, se debe fijar en
h00.
3.3.2.2.5. Message Field Lenght:
Indica el nmero de bytes en el campo Message (antes de aplicar Bytestuffing).
3.3.2.2.6. Message:
Puede tener de 0 a 255 bytes de datos, de cualquier valor dentro del rango
h00-hFF (Byte-stuffing se aplica posteriormente). En 3.3.2.3 se detalla mejor este
campo.
3.3.2.2.7. Cyclic Redundancy Check:
Consiste en dos bytes (antes de aplicar Byte-stuffing) que representan el

resultado del clculo de un CRC de 16 bits. El polinomio divisor empleado para
calcular el CRC es el polinomio CCITT x16 + x12 + x5 + 1. El clculo del CRC empieza
53
con el m.s.b. del primer byte del campo Address, y termina con el l.s.b. del campo
Message. Para dicho clculo, el CRC se inicializa en hFFFF, y finalmente los dos
bytes de este campo se forman con el inverso del resultado. Los 8 m.s.b. se colocan
en el primer byte del campo, y los 8 l.s.b. se colocan en el segundo.
3.3.2.2.8. Stop:
Todas las tramas terminan con el byte de final hFF. Tras aplicar la tcnica de
Byte-stuffing, se garantiza que este no ocurrir en ningn otro campo de la trama.
3.3.2.2.9. Tcnica de Byte-stuffing:
Esta tcnica se usa para garantizar que protocolos orientados a bytes como
el SPB 490 preserven ciertos valores nicos para delimitar las tramas, y sin
embargo permitan a los mensajes usar todo el rango de bytes (h00-hFF). A
continuacin se presentan los bytes a los que se le aplica la tcnica, y su resultado
posterior:
Pareja de bytes resultante
Byte
FD
transformado en
FD 00
FE
transformado en
FD 01
FF
transformado en
FD 02
3.3.2.3. Formato del campo Message:
3.3.2.3.1. Estructura del mensaje:
El campo Message consiste en uno o ms elementos de mensaje, cuya

estructura se muestra en la Tabla 14.
54
Descripcin del campo

Message Element Code
Siglas
Longitud
MEC
1 byte
DSN
0...1 byte
Programme Service Number6
PSN
0...1 byte
Message Element data Length
MEL
0...1 byte
Message Element Data
MED
0...254 bytes
Data Set Number
Tabla 14. Estructura de los elementos de mensaje.
El campo Message puede contener varios elementos de mensaje, con tal de

que la longitud del primero no exceda los 255 bytes. Los campos DSN, PSN, MEL e
incluso el propio MED son opcionales; su inclusin viene definida por el respectivo
MEC. La mxima longitud que puede tener un elemento de mensaje es 255 bytes, lo
cual implica que los datos del mensaje podrn tener una longitud mxima de 254
bytes (se ha de tener presente que el campo MEC no es opcional, y requiere un
byte). Si adems tambin se usan los campos DSN, PSN y/o MEL, la longitud
mxima de los datos del mensaje lgicamente disminuir.
3.3.2.3.2. Message Element Code (MEC):
Sirve para identificar cada mensaje. Puede tomar valores dentro del rango
h01-hFD. Los valores h00, hFE y hFF no estn permtidos.
3.3.2.3.3. Message Element data Lenght (MEL):
Indica el nmero de bytes en el campo Message Element Data.
No se explicar en detalle por no ser concerniente a este proyecto. Para ms informacin, consultar
(7).
55
3.3.2.3.4. Message Element Data (MED):
El contenido de este campo son directamente los llamados cdigos de

mensaje. Existen diferentes tipos de cdigos: Remotos, de configuracin, comandos
de mensaje RDS, de ODAs, etc. La lista actual de comandos definidos en (7)
contiene 69 comandos. A continuacin se explicarn slo aquellos de relevancia
dentro del presente proyecto.
3.3.2.3.4.1. ODA Configuration and Short Message Command:

Sirve para establecer el Cdigo del Tipo de Grupo de aplicaciones ODA, as
como el AID, en los grupos tipo 3A. Tambin permite editar los bits de mensaje del
bloque 3 de los grupos tipo 3A. La Figura 21 presenta el formato de este comando.
Figura 21. Formato del comando ODA Configuration and Short Message.
56
El cuarto MED permite configurar el buffer, mediante combinaciones de sus

dos bits menos significativos. Esto es presentado en la Tabla 15.
Bit 1
Bit 0
Configuracin del buffer
La informacin es transmitida una sola vez, y removida

posteriormente
Reservado
Para transmisin cclica, se aaden grupos tipo 3A al buffer

indicado
Remueve todos los grupos tipo 3A del buffer del tipo de grupo de
la aplicacin indicada
Tabla 15. Configuracin del buffer mediante los bits 1 y 0 del cuarto MED del comando ODA
Configuration and Short Message.
3.3.2.3.4.2. ODA free-format group:

Sirve para agregar un grupo al buffer de formato libre para el cdigo del tipo
de grupo de la aplicacin indicado. La Figura 22 presenta el formato de este cdigo.
57
Figura 22. Formato del cdigo ODA Free-format group.
El segundo MED permite configurar el buffer, seleccionar el modo de

transmisin y fijar la prioridad, mediante combinaciones de sus seis bits menos
significativos. Las Tablas 16, 17 y 18 describen el detalle.
Bit 1
Bit 0

posteriormente
Reservado
Para transmisin cclica, se aaden grupos de informacin con

formato libre al buffer indicado
Remueve todos los grupos de informacin con formato libre del

buffer de formato libre indicado
Tabla 16. Configuracin del buffer mediante los bits 1 y 0 del segundo MED del cdigo ODA Freeformat group.
58
Bit 3
Bit 2
Seleccin del modo
Modo normal
Modo rfaga
Modo rueda giratoria
Reservado
Tabla 17. Seleccin del modo de transmisin mediante los bits 3 y 2 del segundo MED del cdigo
ODA Free-format group.
Bit 5
Bit 4
Establecimiento de la prioridad
Normal
Extremadamente urgente
Inmediata
Reservado
Tabla 18. Establecimiento de la prioridad de transmisin mediante los bits 5 y 4 del segundo MED del
cdigo ODA Free-format group.
3.3.2.3.4.3. TMC:
Sirve para editar los datos TMC en los grupos tipo 8A. La Figura 23 presenta
el formato de este cdigo.
59
Figura 23. Formato del cdigo TMC.
El primer MED permite configurar el buffer, mediante combinaciones de sus

bits 5 y 6. Esto es presentado en la Tabla 19.
Bit 6
Bit 5
La informacin es transmitida el nmero de veces especificado, y

posteriormente removida
Reservado
Para transmisin cclica, se aaden grupos de informacin TMC

(37 bits) al buffer TMC
Remueve todos los grupos de informacin TMC del buffer TMC
Tabla 19. Configuracin del buffer mediante los bits 6 y 5 del primer MED del cdigo ODA TMC.
60
3.3.2.3.4.4. Free-format group:

Sirve para agregar un grupo al buffer de formato libre del tipo de grupo
indicado. La Figura 24 presenta el formato de este cdigo.
Figura 24. Formato del cdigo Free-format group.
El segundo MED permite configurar el buffer, mediante combinaciones de sus

bits 5 y 6. Esto es presentado en la Tabla 20.
Bit 6
Bit 5

posteriormente
Reservado
Para transmisin cclica, se aaden grupos de informacin con

formato libre al buffer indicado
Remueve todos los grupos de informacin con formato libre del

buffer de formato libre indicado
Tabla 20. Configuracin del buffer mediante los bits 6 y 5 del segundo MED del cdigo Free-format
group.
61
4. ARQUITECTURA ACTUAL DEL CANAL DE INFORMACIN DE

TRFICO DEL RACC
La informacin relacionada con el estado de las vas, condiciones

meteorolgicas, situacin del trfico e incidentes en general, es conocida como TTI
(Traffic and Traveler Information), y constituye uno de los campos de mayor
relevancia dentro de los ITS, por lo que la automatizacin de todas las etapas
involucradas en el procesamiento de las TTI desde la adquisicin de los datos
hasta su entrega final a los conductores reviste una gran importancia. En tal
sentido, el RACC ha comenzado a dar los primeros pasos en Espaa al incorporar
en sus instalaciones el sistema TIC: Traffic Information Centre.
El TIC es un sistema desarrollado por mdulos lo cual le permite evolucionar
de manera flexible , capaz de recolectar informacin de diversas fuentes (y en
diversos formatos), procesarla, y distribuirla a los usuarios, bien sea directa o
indirectamente. Incluso permite al Proveedor de Servicio crear y difundir
informaciones propias. La configuracin actual del sistema tiene como fuente de
origen de los datos a la Direccin General de Trfico (DGT), y como destino a Radio
Nacional de Espaa (RNE), para su difusin a nivel nacional va RDS/TMC.
4.1. DESCRIPCIN DEL SISTEMA TIC:

El TIC es un sistema diseado para el procesamiento de informacin de
trfico, desarrollado por la empresa alemana GEWI, y que ofrece aplicaciones para
centros de control de trfico, centros de informacin de trfico, servicios de
informacin de viajes, dems. Actualmente es empleado por ms de 50 instituciones
en Europa (8), tales como autoridades gubernamentales (como la Polica del Estado
Alemn), fabricantes de vehculos, estaciones de radio y televisin, clubes
automviles y administradores de autopistas (por ejemplo, en Francia).
62
4.1.1. Principios de diseo:

El sistema presenta una arquitectura Cliente Servidor. La estructura de este
ltimo es esttica, basada en el lenguaje XML. La comunicacin con los canales de
entrada y salida tiene un estilo modular: cada canal requiere un conversor particular
para poder aceptar y/o entregar datos desde y hacia el exterior. De esta manera, se
pueden establecer diversos canales de comunicacin y con distintos formatos sin
tener que modificar el ncleo del sistema. La Figura 25 ilustra la arquitectura del
sistema.
Figura 25. Arquitectura del sistema TIC.
El cliente del sistema es el TIC Editor, el cual ofrece funcionalidades

enfocadas directamente a los usuarios. Por su parte, el servidor del sistema es el TIC
Server, el cual es configurado mediante la herramienta TIC Admin, por lo que es
63
comn que se instalen en la misma mquina. El TIC Server representa el ncleo del
sistema TIC.
El basar el procesamiento de la informacin en el lenguaje XML permite
simplificar la recepcin de datos desde los proveedores o el envo a los clientes,
dada la enorme popularidad de este lenguaje. Sin embargo, no es imperativo que
estos adopten dicho lenguaje; para ello el sistema incorpora conversores dedicados.
Adems, la comunicacin con el exterior se puede realizar mediante variados
estndares: De Internet (comunicaciones IP, FTP, HTTP , formatos de datos
XML, XLS ), de Informacin de Viajes (DATEX, ALERT-C, TPEG), de
Telecomunicaciones (WAP, SMS), de Difusin (RDS/TMC, DVB, DAB, Teletexto) (8).
El requisito bsico, en cuanto a redes de comunicacin, para la operacin del
sistema TIC es una red TCP/IP. La comunicacin entre el TIC Editor y el TIC Server
se realiza mediante sockets IP (9).
4.1.2. El TIC Editor:

El TIC Editor es la aplicacin final dirigida a los operadores del servicio, ya que
les permite crear, modificar, editar, borrar, validar y enviar informacin. Tambin es
posible crear filtros especializados segn el contexto de la informacin, realizar
bsquedas y exportar datos para anlisis posteriores. La informacin es presentada
tanto en formato texto (listas ordenadas) como visualmente (mapas con las
incidencias). El TIC Editor ofrece distintas categoras de eventos, tales como trfico,
obras en las vas, climatologa, y dems.
La Figura 26 presenta una vista general del TIC Editor. En ella se observa a la
izquierda el rea de Trabajo: Una clasificacin de las informaciones segn su
procedencia (DGT Info, RACC Info, etc), ficheros con filtros diseados por el RACC
(Catalunya Info, Favorits mat, etc), y de informacin de sistema (Estat del sistema,
System Messages). En la parte central superior se presenta la List Window (Ventana
64
de Lista), la cual presenta todos los mensajes provenientes del TIC Server, tras
haber realizado la validacin de los mismos (eliminacin de incidencias repetidas,
caducadas, actualizaciones) que se encuentre dentro del fichero seleccionado en el
rea de Trabajo. En este caso, se trata del fichero Tots els missatges (Todos los
mensajes), el cual contiene toda la informacin provista por la DGT, tras ser
procesada. En la parte inferior central se presenta la Detail Window (Ventana de
Detalle), la cual ofrece distintas informaciones (segn la pestaa seleccionada) sobre
cada incidencia marcada en la List Window. A la derecha se encuentra la Map
Window (Ventana de Mapa): los puntos rojos corresponden con aquellas incidencias
que tienen una localizacin vlida dentro de la Tabla de Localizaciones espaola (no
todos los mensajes enviados por la DGT contienen localizaciones listadas). Esto se
observa en la Figura 27: Algunos mensajes son codificables en TMC y otros no.
Figura 26. Vista general del TIC Editor.
65
Figura 27. Detalle de la List Window del TIC Editor, donde se observa que algunos mensajes son
codificables en TMC y otros no.
Las pestaas de la Detail Window ofrecen distintos tipos de informacin:

-
Vista general / Contenido: Se ofrecen detalles adicionales de la informacin,

como la fuente de los datos, el indicador de calidad, los filtros que ha
aprobado la incidencia, y dems.
Historial: Presenta la evolucin (cuando est disponible) de la incidencia

seleccionada durante las ltimas horas.
Relacin: Presenta todas las dems incidencias que guarden relacin con la
seleccionada. Hay distintos tipos de relaciones: inclusin, adyacencia, etc.
Mapa: Presenta la regin en la que tiene lugar la incidencia seleccionada. Un

detalle es presentado en la figura 28.
66
Figura 28. Detalle de la pestaa Mapa, dentro de la Detail Window.
Adicionalmente, el TIC Editor permite al operador monitorear el estado del

sistema y crear mensajes de trfico propios (escogiendo todos los parmetros:
localizaciones, eventos, duracin, etc) y filtros para las informaciones. La Figura 29
presenta la evolucin en el tiempo de un parmetro del estado del sistema (en este
caso, se trata del consumo de memoria virtual). La Figura 30 ofrece una vista general
del TIC Info Wizard la herramienta para crear mensajes propios de trfico , en la
que se observa particularmente la correspondencia entre el mensaje bajo creacin y
el equivalente TMC (esto es, el operador podra crear cualquier tipo de mensaje, pero
no todos cumpliran con el estndar, y por ende no seran codificables). La Figura 31
muestra la definicin inicial del filtro de los mensajes de Catalua. Existen diversos
tipos de filtros: por regin geogrfica, por evento, por fecha, etc. Particularmente este
era del primer tipo, y todos los mensajes que se encontrasen dentro de la regin
definida en rojo seran guardados dentro del fichero Catalunya Info.
67
Figura 29. Evolucin en el tiempo de un parmetro del Estado del Sistema.
68
Figura 30. Vista general del TIC Info Wizard.
69
Figura 31. Definicin inicial del filtro geogrfico para Catalua.
4.1.3. El TIC Server:

Como se dijo anteriormente, el TIC Server constituye el ncleo del sistema. Tal
como se observa en la Figura 25, las tres categoras principales de procesos que
desarrolla son: Recoleccin, Administracin y Distribucin de datos (Collect, Manage
y Distribute). A su vez, cada una conlleva diversos subprocesos (10):
Recoleccin: a) Recibe datos de un proveedor.

b) Convierte los datos del formato del proveedor al formato
interno del sistema.
c) Procesa los datos (verificaciones, autorizaciones, etc.)
Administracin: a) Almacena los datos segn su tipo.
b) Procesa los datos segn corresponda.
70
c) Archiva los datos en una base externa (si aplica).

Distribucin: a) Procesa los datos (filtros, agrupaciones, etc.)
b) Convierte los datos del formato interno del sistema al formato
del destinatario.
c) Enva los datos a su destino.
Por su parte, la herramienta TIC Admin permite administrar tanto el TIC Editor
como el TIC Server:
1. Importacin de informacin de referencia del sistema, como por ejemplo las
Tablas de Eventos y de Localizaciones.
2. Configuracin del sistema, incluyendo cada mdulo (conversor) de entrada y
de salida.
3. Respaldos y restauracin de los datos almacenados en el TIC Server store, y
de sus parmetros de configuracin.
4.1.3.1. El Proceso de Recoleccin:
La informacin es recolectada desde fuentes externas al TIC Server, por lo
que se requieren los TIC Input Modules (Mdulos de Entrada al TIC) para establecer
conexiones con cada fuente y recibir, convertir y procesar los datos. La Figura 32
detalla mejor el proceso de recoleccin de datos.
71
Figura 32. El proceso de Recoleccin de datos.
Los cuatro subprocesos (Recibir, Convertir, Procesar y Monitorear) indican las

opciones disponibles para cada mdulo de entrada. Los datos pueden ser recibidos
desde una red o Internet empleando el sistema de archivos de Windows (llamado
File en la figura), o protocolos FTP, http, e incluso en el cuerpo o como archivo
adjunto de un correo electrnico, si el protocolo de recepcin de correos es POP3.
Posteriormente los datos son convertidos a la representacin interna del TIC Server.
La ltima etapa Procesar contempla el proceso de Actualizacin de datos
activado por tiempo , el cual da lugar a una nueva recepcin de datos. Los datos
convertidos son sometidos luego a otros subprocesos (verificacin, aceptacin,
filtrado, etc.) antes de ser almacenados en el TIC Server.
Adicionalmente, los subprocesos pueden ser monitorizados (por ejemplo,
activando Indicadores de Calidad que monitoricen parmetros como el mximo
intervalo de recepcin desde la ltima conexin, nmero de datos sin procesar,
72
nmero de datos procesados, etc.), los datos recibidos y procesados se pueden

archivar temporalmente, y se pueden guardar logs (registros) de las actividades de
los mdulos.
4.1.3.2. El Proceso de Administracin:
Los distintos tipos de datos (informacin de proveedores, de sensores, de
sistema, de indicadores de calidad, etc.) son almacenados y procesados (si cabe).
Adicionalmente, todos los datos pueden ser opcionalmente archivados en una base
de datos MS SQL externa, bien sea en la misma mquina o en otra distinta. La
Figura 33 detalla mejor el proceso de administracin de datos.
Figura 33. El proceso de Administracin de datos.
El archivo slo tiene funcionalidades como un histrico de datos (10), no como

respaldo y restauracin. Es actualizado constantemente, con cada nueva transaccin
73
de datos almacenada en el TIC Server. Tanto el procesamiento de datos y los

recursos de la mquina del TIC Server, como el procesamiento de los archivos de la
base de datos, pueden ser monitorizados activando diferentes Indicadores de
Calidad, tal como se observa en la Figura 33.
4.1.3.3. El Proceso de Distribucin:
La informacin es distribuida desde el TIC Server hacia destinos externos, por
lo que se requieren los TIC Output Modules (Mdulos de Salida del TIC) para
establecer conexiones con cada destino y procesar, convertir y enviar los datos. La
Figura 34 detalla mejor el proceso de distribucin de datos.
Figura 34. El proceso de Distribucin de datos.
Los cuatro subprocesos (Procesar, Convertir, Enviar y Monitorear) indican las

opciones disponibles para cada mdulo de salida. La primera etapa Procesar
74
opera la funcin de Actualizacin de datos, que puede ser activada por tiempo (para
enviar todos los datos) o por eventos (para enviar todos los datos completo o slo
las diferencias con respecto al ltimo envo diferencial ). Esta etapa tambin
selecciona qu datos son enviados por cada mdulo de salida, mediante la
asignacin de filtros. Posteriormente los datos han de ser convertidos de la
representacin interna del TIC Server al formato externo en particular.
Finalmente, los datos pueden ser enviados por una red o Internet
empleando el sistema de archivos de Windows (llamado File en la figura), o
protocolos FTP, http, e incluso en el cuerpo o como archivo adjunto de un correo
electrnico, si el protocolo de envo de correos es SMTP. Adicionalmente, los
subprocesos pueden ser monitorizados (por ejemplo, activando Indicadores de
Calidad que monitoricen parmetros como el mximo intervalo de envo desde la
ltima transmisin, etc.), los datos procesados y enviados se pueden archivar
temporalmente, y se pueden guardar logs de las actividades de los mdulos.
4.1.4. El Mdulo TIC RDS/TMC:

Consiste en una aplicacin diseada para crear el flujo de datos RDS/TMC
cclico. Aparte de los grupos 3A y 8A necesarios para los datos TMC, datos RDS
como TA, TP, RT, PS y CT pueden ser procesados (11). La informacin codificada
TMC en el TIC Server es enviada mediante el mdulo TIC XML Info a la aplicacin
RDS-TMC, y una vez all insertada en el carrusel al que haba sido asignada. La
prxima informacin TMC a ser enviada es leda cclicamente del carrusel, convertida
en el grupo 8A correspondiente y enviada al codificador RDS mediante la interfaz de
salida. La Figura 35 ilustra un diagrama de bloques del mdulo RDS/TMC.
75
Figura 35. Diagrama de bloques del mdulos RDS/TMC.
De cara a los codificadores RDS, el mdulo RDS/TMC es compatible con

UECP, LINK y FHT; funciona con comunicacin Serial o Ethernet, y general grupos
RDS tipo 3A y 8A.
4.2. ARQUITECTURA ACTUAL DEL SISTEMA TIC DEL RACC:

La arquitectura actual del sistema TIC del RACC tiene una nica fuente
externa8 de entrada de datos: La Direccin General de Trfico (DGT). Como destino
de salida est Radio Nacional de Espaa (RNE), la cual se encarga de la difusin
RDS/TMC. La figura 36 presenta el diagrama de dicha arquitectura.
Se indica as porque, a nivel interno, los operadores siempre pueden crear mensajes propios (no
reportados por la DGT).
76
TIC Editor
DGT
Conversor
DGT - TIC
Formato
XML del
TIC
Servicios TIC
Informacin de trfico
Formato
XML del
TIC
Mdulo
RDS/TMC
RNE
Estado del sistema
Referencia del sistema TIC

Tabla de Eventos: Espaa
Tabla de Localizaciones: Espaa
Lenguaje de interfaz de usuario: Espaol / Ingls
Figura 36. Diagrama de la arquitectura actual del sistema TIC del RACC.
As, la Figura 37 ilustra la plataforma actual del sistema del RACC. Los
detalles respectivos se presentan en 5.3 y 5.4.
Figura 37. Plataforma actual del sistema TIC del RACC.
77
Por su parte, las figuras 38 y 39 son fotografas de las instalaciones en las que
operan el TIC Editor y el TIC Server, respectivamente, dentro del RACC. Se
encuentran en distintas plantas de la Sede Central del RACC, en Barcelona. El TIC
Editor es usado por el Departamento de Infotrnsit, mientras que el TIC Server se
encuentra en la Sala de Servidores del RACC, junto a los dems servidores
existentes.
Figura 38. Departamento de Infotrnsit del RACC.
78
Figura 39. Sala de Servidores del RACC, con detalle de su interior.
4.3. CANAL DE ENTRADA TIC DGT:

La informacin de la DGT es publicada en ficheros planos, de acceso pblico,
cuyos detalles se explican 5.4.1. Segn (12), los ficheros de incidencias activas se
actualizan constantemente cada vez que hay un cambio en la base de datos de la
DGT. Dichos ficheros estn disponibles como pginas de protocolo Web (http) en el
sitio de la DGT, en las siguientes direcciones:
http://www.dgt.es/gsmplus.txt: Contiene todas las incidencias activas.
79
http://www.dgt.es/gsm.txt: Contiene todas las incidencias activas menos las

obras, en cuyo caso slo contiene aquellas que obligan a cortar carreteras
importantes (Autovas, autopistas
o Nacionales). Es el fichero que se
recomienda difundir segn (12), ya que las obras menores no tienen gran
incidencia para el trfico, y si la tienen puntualmente, suele haber una
incidencia de tipo retencin asociada.
El TIC Server est configurado para leer este fichero cada 10 minutos, y
transformarlo de su formato .txt al formato interno del sistema mediante el Conversor
DGT TIC.
4.4. CANAL DE SALIDA TIC RNE:

El servicio RDS/TMC entra en operacin en Espaa en el ao 1999, cuando la
Direccin General de Trfico y Radio Nacional de Espaa inician la difusin de
informacin de trfico, asumiendo los roles de Proveedor de Servicio y Radiodifusor,
respectivamente. La red de emisoras utilizada es RNE 3. Con el fin de poder
posicionar al RACC como un nuevo Proveedor de Servicio, se debieron tener
presentes las siguientes restricciones tcnicas:
Actualmente, las aplicaciones RDS que utilicen informacin ODA slo pueden
ser transmitidas por las redes de RNE 3 y RNE-CLAS de Radio Nacional de Espaa,
ya que son estas las nicas con codificadores RDS posteriores a la incorporacin de
informacin ODA en la normativa RDS. La DGT hace uso de la red RNE 3 para la
difusin de mensajes TMC, mientras que el Instituto Geogrfico Nacional (IGN)
emplea la red RNE-CLAS para la aplicacin Diferential GPS (D-GPS).
Por otra parte, el grupo RDS asignado a los mensajes TMC es el 8A, por lo
que el RACC habra de transmitir sus mensajes a travs de un grupo diferente (pues
evidentemente este ya est siendo usado por la DGT), lo cual puede ser
80
desaconsejable dado que quiz los navegadores actuales existentes en el mercado

no contemplen esto9.
La decisin final fue que el RACC emplease la red RNE-CLAS, en conjunto
con el IGN. Por tanto, con objeto de que el flujo de informacin TMC (RACC) fuese
compatible con la aplicacin D-GPS (IGN), el servidor de datos TMC del RACC haba
de cumplir con las siguientes especificaciones:
La velocidad de datos a la salida del servidor TMC deba poder ser variable,
siendo aconsejable partir con 2400 bps (que es la velocidad de salida del servidor
RDS de RNE). Adems, el servidor RDS de RNE no tiene suficientes puertos de
entrada, por lo que el servidor TMC del RACC haba de transmitir los datos de
manera intermitente, con pausas de 5 segundos. As, se podra multiplexar la
informacin TMC con otras aplicaciones, sin afectar la efectividad proporcionada por
los mensajes TMC (ya que no es imperativo que estos se transmitan en tiempo real).
Por lo tanto, la lnea de datos RACC-RNE contratada a Telefnica tiene las
siguientes caractersticas:
Es una lnea punto a punto, transparente, desde la Sede Central del RACC
(Barcelona) hasta la Central de RNE (Prado del Rey, Madrid).
Tipo de conexin: Permanente (24h), sin marcacin.
Modo unidireccional: RACC RNE.
Velocidad: 2400 bps (con posibilidad de subir a 9600 bps)
Formato N, 8, 1
Interfaz: RS-232
Protocolo UECP-SPB490.
Tcnicamente, es posible transmitir mensajes TMC como una ODA, y usar as cualquier grupo
disponible para ODAs; slo habra que indicar de cul grupo se trata dentro del campo Application
Group Type Code de los grupos tipo 3A. Sin embargo, en la prctica son pocos los navegadores
actuales que ofrecen la opcin de navegacin dinmica en base a informacin RDS/TMC, por lo que
es razonable pensar que quiz estos no incorporen la normativa relacionada con las ODAs, y estn
programados simplemente para obtener los mensajes TMC directa y nicamente de los grupos 8A.
81
Adems, el servidor TMC del RACC deba direccionar las tramas SPB490
segn la localizacin del evento y su repercusin con el fin de no saturar los buffers
de los codificadores RDS , empleando para ello una tabla de direccionamiento SPB.
Este punto se discutir con mayor detalle en el siguiente captulo.
4.5. DISTRIBUCIN RDS REALIZADA POR RNE:
La Figura 40 muestra el esquema de distribucin de los datos RDS de la
Direccin Tcnica de RNE. En su parte inferior se observan los tres mdems,
correspondientes a las lneas punto a punto que tienen el RACC, la DGT y el IGN
con RNE. Se observa que mientras los dos ltimos tienen acceso directo al Servidor
RDS a tasas de 9600 bps, el mdem del RACC est conectado a uno de los seis
puertos del multiplexor RS232, a una tasa de 2400 bps. Dicho multiplexor recibe
tambin datos de los Controles de las redes RNE 3 y RNE-CLAS. Su salida est
conectada al puerto Com 8 del Servidor.
El servidor a su vez tiene 6 lneas ms de entrada de datos de otras fuentes, y
dos lneas de salida a travs de los puertos Com 5 y Com 12 cuya velocidad es
de 2400 bps. Estas son dirigidas hacia un selector, y luego hacia cuatro mdems
satelitales (ComStream). Los dos del medio corresponden a las redes RNE-CLAS y
RNE 3. Finalmente, los datos pasan por el uplink y el transpondedor, y son enviados
al satlite Hispasat.
Las Figuras 41 y 42 son fotos de la visita tcnica realizada a las instalaciones
de Radio Nacional de Espaa (Prado del Rey, Madrid) a finales de octubre del 2006.
La Figura 41 es una toma cercana del mdem TMC asignado al RACC. La Figura 42
es una vista general de una de las oficinas de la Direccin Tcnica de RNE, donde
se observan tres de los dispositivos que intervienen en la distribucin RDS de los
datos provenientes del RACC: el mdem TMC (vase la Figura 41), el multiplexor
RS232 y el servidor RDS.
82
Figura 40. Esquema de distribucin de los datos RDS de la Direccin Tcnica de RNE.
83
Figura 41. Fotografa del mdem TMC asignado al RACC.
84
Servidor RDS
Multiplexor RS232
Mdem TMC
asignado al RACC
Figura 42. Vista general de una de las oficinas de la Direccin Tcnica de RNE. Se observan tres
dispositivos que intervienen en la distribucin RDS de los datos del RACC.
85
5. ANLISIS Y VALIDACIN DEL FUNCIONAMIENTO DEL SISTEMA
En el captulo 3 se introdujeron los conceptos tericos relacionados con TMC,

RDS y UECP SPB 490. A continuacin, se ofrece una descripcin de la situacin de
estos sistemas desde el punto de vista prctico, al analizar las dificultades con las
que tienen que lidiar los actores involucrados en esta seccin de la cadena de
servicio: la DGT, el RACC y RNE.
5.1. SITUACIN ACTUAL DEL DEPARTAMENTO DE INFOTRNSIT:

5.1.1. Metodologa de trabajo actual:
El RACC ofrece desde su Departamento de Informacin de Trfico
Infotrnsit un servicio informativo a travs de las principales emisoras de Catalua.
Cada da se emiten continuamente crnicas de trfico a travs de las principales
cadenas: Catalunya Rdio, Cadena Ser, COM Rdio, Onda Cero - Onda Rambla,
Rdio 4, Ona Catalana, Rac 1, Rdio Flaixbac, Flaix FM, Radioclub 25, Los 40,
Cadena Dial, M-80, Cadena Cope, Rdio Estel, Rdio Salut y Europa FM.
Dicha informacin se obtiene fundamentalmente de la pgina web de
informacin de trfico del Servei Catal de Trnsit (la cual ofrece imgenes en
directo de cmaras en las carreteras y descripciones constantemente actualizadas
del estado del trnsito) y de llamadas a sus colaboradores (contactos en gasolineras,
concesionarios o talleres RACC, el Centro de Control de Autopistas, estaciones de
esqu,
restaurantes,
policas
locales,
etc.).
Estos
contactos
establecen
la
diferenciacin y valor aadido de la informacin del RACC, al permitir actualizar

informaciones de forma ms rpida y fiable. Por ltimo, tambin se obtiene
ocasionalmente informacin de otras cadenas de radio.
86
En la Figura 38 se present una vista general del Departamento de Infotrnsit.

La Figura 43 contiene dos fotografas de los equipos empleados por los locutores
para sus conexiones de radio diarias.
Figura 43. Equipos empleados por los locutores de Infotrnsit para sus conexiones de radio.
87
5.1.2. Justificacin del uso del sistema:

La metodologa de trabajo actual de Infotrnsit tiene como primer
inconveniente que la informacin de trfico del RACC no est en formato digital, es
decir, no existe un registro escrito de la informacin que se difunde. Hasta el 2002
exista una base de datos en Access que el operador de Infotrnsit rellenaba. Esta
era la informacin que se difunda por Internet en la web del RACC. Un segundo
inconveniente es la dependencia que se establece con las emisoras de radio, pues
los boletines de trfico deben ser de duracin limitada y en momentos
predeterminados.
Basndose en lo anterior, el RACC ha detectado una oportunidad, tanto de
difundir su marca, como de posicionarse como proveedor de informacin de trfico
de calidad a nivel nacional: la emisin de informacin RDS-TMC. Sin embargo, las
conexiones diarias de Infotrnsit son tambin uno de los puntos de reconocimiento
del RACC entre el pblico, por lo que este nuevo canal de informacin no pretende
sustituirlas, y tampoco puede ralentizarlas.
Debido al ritmo de trabajo de las conexiones en directo con las radios durante
las horas punta, la aplicacin que requiere Infotrnsit debe ser en extremo sencilla, y
rpida de usar. Por ende, el departamento requiere simultneamente una base de
datos constantemente actualizada, que muestre la informacin de trfico para los
locutores, y que permita enviar mensajes a travs del sistema RDS-TMC. El sistema
TIC cumple con ambos requisitos.
5.2. SITUACIN ACTUAL DEL RDS/TMC EN ESPAA:

Un esquema del funcionamiento del sistema RDS/TMC se presenta en las
Figuras 44 y 45. La informacin concerniente al flujo del trfico, accidentes,
condiciones meteorolgicas, etc. es recabada mediante distintas fuentes, tanto
automatizadas
espiras inductivas en las vas (en la Figura 46 se observa la
88
instalacin de uno de estos dispositivos antes de un semforo), cmaras de

vigilancia e incluso FCD10 como manuales reportes de ayuntamientos, empresas
de asistencia en carretera, cuerpos policiales y de emergencia, llamadas de
particulares, etc. , y colectada en la Central de Informacin de Trfico (TIC) de la
DGT, donde se procesa (filtrado de informaciones repetidas, verificacin de datos,
etc.). Posteriormente se generan los mensajes TMC y se envan a RNE (la emisora
de radio FM del Estado) que los transmite como una seal RDS dentro de sus
transmisiones FM regulares. La informacin TMC es recibida por la antena y radio (o
navegador GPS, smartphone, PDA, etc.) del vehculo, y reconstruida a partir de las
Tablas de Eventos y Localizaciones almacenadas en el dispositivo, para ser
finalmente presentados al conductor. El proceso completo toma unos 30 segundos.
Figura 44. Esquema del funcionamiento del sistema RDS/TMC (datos recolectados manualmente).
10
FCD: Floating Car Data. Es una tecnologa basada en el uso de navegadores GPS instalados en
flotas de vehculos apropiadas, tales como taxis, servicios de mensajera y compaas de transporte
de cargas. La ubicacin de los vehculos es determinada mediante los GPS y enviada a los centros de
procesamiento correspondientes. A partir de ella se pueden realizar extrapolaciones del estado del
trnsito.
89
Figura 45. Esquema del funcionamiento del sistema RDS/TMC (datos recolectados automticamente).
Figura 46. Fotografa de unas espiras inductivas antes de un semforo: Se pueden observar las
marcas que quedaron en el pavimento tras su instalacin.
La Direccin General de Trfico viene difundiendo informacin RDS-TMC de

forma gratuita desde el ao 1999, a travs de la red de emisoras de RNE 3. El
estndar TMC ha sido adoptado por los principales fabricantes de automviles (de
hecho, hoy da todos los radios y sistemas de navegacin incorporados de fbrica
soportan TMC) y de receptores (tanto radios como sistemas GPS: Pioneer,
90
Panasonic, Navigon, etc.). La clave es la simplicidad de transmisin: La informacin

TMC se recibe va la antena normal de radio FM.
Por el momento, la DGT slo transmite mensajes TMC de vas interurbanas, y

la calidad de la informacin requiere an mejoras importantes. El RACC est
dispuesto a difundir informacin de trfico va RDS/TMC como un segundo proveedor
de servicio, de manera que pueda recibirse en los receptores de los vehculos sin
costo adicional para el usuario. Por su parte, RNE podra proporcionar as un mejor
servicio pblico, ofreciendo informacin de otra fuente ms. La difusin se realizara
a travs de la red de emisoras de RNE Clsica.
5.3. EL SISTEMA RDS DE RNE:
Radio Nacional de Espaa emite boletines de trfico por las redes de emisoras
de Radio 1 y de Radio 5 "Todo Noticias"; programas a los que contribuyen, en
determinadas franjas horarias, sus emisoras regionales y locales. Viene utilizando el
sistema RDS desde 1993, y actualmente est implementado en todos sus centros
emisores en Frecuencia Modulada. Particularmente, el sistema RDS de RNE emite la
siguiente informacin (13):
1. Funciones de sintonizacin:
Identificacin y nombre de la red de emisoras (PS).
Lista alternativa de frecuencias (AF).
Identificacin de redes con programas de trfico (TP).
Tipo de programa (PTY).
Informacin sobre otras redes de emisoras (EON).
2. Otras funciones:
Identificacin de informacin sobre el trfico (TA).
Identificacin para el decodificador (PI).
91
Conmutador msica/palabra (MS).

Radiotexto (RT).
Fecha y hora (CT).
Radiopaging (Radiobsqueda) (RP).
Canal de mensajes de trfico codificado (TMC).
Sistema de aviso de emergencia.
Actualmente, el sistema TMC se transmite por la red de emisoras de RNE 3
(identificada con el PI E213 (13)) en toda Espaa utilizando los parmetros descritos
en la Tabla 21. El TMC Forum (mximo organismo de decisiones relacionadas con el
TMC) le asign a la Tabla de Localizaciones espaola el nmero 17; de all el valor
que transmite RNE en el parmetro LTN: Location Table Number (Nmero de Tabla
de Localizaciones). A la DGT le corresponde el SID = 1, por ser el primer proveedor
de informacin TMC en Espaa. El parmetro M se refiere al modo de transmisin
RDS/TMC, segn se explica en la seccin 3.1.4.4.1.2 (M = 0 es el modo bsico). La
redundancia de los mensajes es de 2 (el mnimo para que un mensaje cualquiera sea
considerado como vlido, de ser ambas copias idnticas bit a bit), y el envo de
mensajes multigrupo est permitido.
Parmetro
Valor
AID
CD46 (Alert-C)
LTN
17
SID
AFI
Proveedor
DGT-SCT
Modo
Multigrupo
Redundancia
Tasa 8A
2,4 grupos/seg
92
Tasa 3A
1 grupo/seg. (Variantes 0 y 1)
Tabla 21. Parmetros de la transmisin TMC por la red de emisoras de RNE 3.
5.3.1. El direccionamiento SPB en RNE:

En 3.4.1.1 y 3.4.2.2.3 se introdujo la idea del direccionamiento SPB (definido a
partir de 2 bytes: uno para la site address y otro para la encoder address). RNE ha
definido las direcciones de grupo (redes, zonas, aplicaciones, etc.) y las direcciones
individuales de cada codificador RDS, lo que permite que cada servidor RDS enve
toda la informacin multiplexada en un slo canal de datos.
El direccionamiento SPB se puede indicar tanto en formato hexadecimal como
en formato SPB. La figura 47 muestra la correspondencia entre ambos formatos
mediante un ejemplo. Cabe destacar que las direcciones de la figura son las
correspondientes a Catalua dentro de la red de emisoras RNE-CLAS: SPB 107/02,
o equivalentemente h41C2.
Figura 47. Correspondencia entre las direcciones en formato SPB y en formato hexadecimal.
93
5.4. RELACIN ENTRE LOS FORMATOS DE DATOS DEL SISTEMA TIC Y EL

EXTERIOR:
5.4.1. Formato de los datos provenientes de la DGT:

En 5.3 se indic que los datos de la DGT son escritos en un fichero plano que
se encuentra en lnea. Dicho fichero contiene campos de longitud fija, y cada lnea
corresponde con un registro nuevo. Contiene cuatro tipos de registros diferentes:
retenciones, climatologa, puertos y obras. Para diferenciarlos, cada registro tiene un
primer campo de un slo caracter (el prefijo) que identifica el tipo de incidencia. En
la Tabla 22 se muestra la longitud de los campos del fichero. En cuanto a su tipo,
todos son char (caracteres).
Campo
Prefijo
Provincia
Longitud
Poblac./
puerto
40
Causa
Nivel
Carretera
10
PK
Inicial
4
PK
final
4
Sentido
Hacia
40
Tabla 22. Longitud de los campos del fichero gsmplus.txt.
La Tabla 23 presenta la estructura del fichero. Algunos registros tienen campos

en blanco (por ejemplo, el campo sentido en climatologa), en cuyo caso se rellenan
con espacios.
Prefijo Provincia Poblac./

puerto
Causa
Nivel
Carretera PK
PK
Inicial final
Sentido Hacia
sentido poblacin
Retenciones
Provincia poblacin causa_ret
nivel
carretera
pk
inicial
pk
final
Climatologa
Provincia poblacin causa_cli
nivel
carretera
pk
inicial
pk
final
Puertos
Provincia
nivel
carretera
pk
inicial
pk
final
Obras
Provincia poblacin
nivel
carretera
pk
inicial
pk
final
nombre
puerto
Tabla 23. Estructura del fichero gsmplus.txt.
sentido poblacin
94
A continuacin se darn los detalles de cada tipo de registro, y posteriormente

un ejemplo de su interpretacin.
5.4.1.1. Registros de tipo Retenciones:
Este tipo de registro contiene los siguientes campos:
Prefijo: Indica el tipo de incidencia; en este caso, "R".

Provincia: Cdigo de provincia. Ejemplos: "TO" (TOLEDO), "M " (MADRID).
Poblacin: Poblacin donde se produce la incidencia. Ejemplos: "la pobla de
segur", "artesa de segre", "oleiros".
Causa: Causa de la retencin. Puede tomar los valores indicados en la Tabla
24.
Valor
Significado
Congestin
Circulacin
Accidente
Inundacin
Competicin deportiva
Fiestas
Manifestacin
Desprendimientos
Vehculo averiado
Otras
Tabla 24. Valores y significados del campo Causa de los registros de tipo Retencin.
Nivel: Nivel de servicio de la carretera. Puede tomar los valores indicados en

la Tabla 25.
95
Valor
Significado
Circulacin interrumpida (carretera cortada)
Circulacin saturada (con retenciones)
Circulacin discontinua (lenta con retenciones espordicas)
Circulacin intensa
Tabla 25. Valores y significados del campo Nivel de los registros de tipo Retencin.
Carretera: Cdigo de la carretera. Ejemplo: "B-23", "C-31", "AP-2".

PK-Inicial: Punto kilomtrico de comienzo de la incidencia (truncado a nmero
entero).
PK-Final: Punto kilomtrico de final de la incidencia
(truncado a nmero
entero).
Sentido: Indica el sentido de la incidencia. Puede tomar los valores indicados
en la Tabla 26.
Significado
Valor
+
Sentido creciente de los kilmetros
Sentido decreciente de los kilmetros
Ambos sentidos
Norte
Sur
Este
Oeste
Tabla 26. Valores y significados del campo Sentido de los registros de tipo Retencin.
Hacia: Indica hacia dnde se produce la incidencia, expresando el sentido

hacia donde va la carretera. Por ejemplo, hacia CADIZ.
96
5.4.1.2. Registros de tipo Climatologa:

Este tipo de registro contiene los siguientes campos11:
Prefijo: Indica el tipo de incidencia; en este caso, "C".

Causa: Incidencia meteorolgica. Puede tomar los valores indicados en la
Tabla 27.
Valor Significado
N
Nieve
Niebla
Lluvia
Viento
Hielo
Tabla 27. Valores y significados del campo Causa de los registros de tipo Climatologa.
Sentido: No tiene sentido en este tipo de registros (se llena siempre con
espacios).
Hacia: dem.
5.4.1.3. Registros de tipo Puertos de montaa:
Prefijo: Indica el tipo de incidencia; en este caso, "P".

Puerto: Nombre del puerto donde se produce la incidencia. Ejemplo: "collado
del veleta".
11
Slo se indican aquellos campos cuyo significado vara con respecto a los registros de tipo
Retenciones. Aquellos que no se indiquen existen igualmente, y su significado es el mismo que en
dichos registros.
97
Nivel: Puede tomar los valores indicados en la Tabla 28.

Valor
Significado
Cerrado
Cadenas
Tabla 28. Valores y significados del campo Nivel de los registros de tipo Puertos de montaa.
Sentido: No tiene sentido en este tipo de registros (se llena siempre con
espacios).
Hacia: dem.
5.4.1.4. Registros de tipo Obras:
Prefijo: Indica el tipo de incidencia; en este caso, "O".

Causa: No tiene sentido en este tipo de registros (se llena siempre con
espacios).
5.4.1.5. Ejemplos de interpretacin de los datos del fichero gsmplus.txt:
A continuacin se presentan cuatro lneas extradas de un fichero, seguidas de
sus respectivas interpretaciones.
RM alcobendas
9NM-603
00040004+burgos
Retencin en Alcobendas (Madrid), causa "Otras", nivel Negro, carretera M603 de los kilmetros 4 al 4, sentido creciente hacia Burgos.
98
CM colmenar viejo
FVM-618
00100018+
Meteorologa en Colmenar Viejo (Madrid), causa niebla, nivel verde, carretera

M-603 de los kilmetros 10 al 18.
PGRcollado del veleta
NA-395
00380049
Puerto cerrado, en Collado del Veleta (Granada), carretera A-395, kilmetros

38 al 49.
OA algorfa
NC-3323
00180018-cuenca
Obras en Algorfa (Alicante), nivel negro, carretera C-3323 kilmetro 18 sentido

decreciente hacia Cuenca.
5.4.2. Campos de datos del TIC Editor para la generacin de

mensajes TMC:
Como ya se explic en 3.1, un mensaje TMC est compuesto por cinco
elementos bsicos de informacin: Evento, localizacin, direccin y extensin,
duracin y aviso de desvo. Sin embargo, estos campos de informacin por s solos
no son pueden ser editados directamente por los operadores al momento de crear
mensajes propios, dado que involucran bases de datos excesivamente grandes, por
lo que el TIC Editor presenta una interfaz ms amigable, con diversos mens y
submens de distintas clases (en la Figura se 30 se present una vista del TIC Info
Wizard), a partir de los cuales el sistema crea el mensaje TMC que se adapta a las
selecciones del operador.
99
Los campos de datos incorporados por el TIC Editor para la generacin de

mensajes TMC son:
Carretera + Localizacin 1
Localizacin 2
Evento 1
Evento 2
Evento 3
Recomendacin
Duracin
Desvo
Otros
Administracin
5.4.3. Correspondencia entre los datos de la DGT y los campos

de datos del TIC Editor para la generacin de mensajes
TMC:
Los datos de la DGT son mapeados a los campos de datos del TIC Editor
teniendo presente los formatos de dichos datos (tal como se expusieron en 5.4.1) y
los correspondientes cdigos de las Tablas de Eventos y de Localizaciones:
1. A partir de la Carretera, PK inicial y PK Final del fichero gsmplus.txt, el sistema
TIC determina el punto TMC ms cercano inspeccionando de forma anidada la
Tabla de Localizaciones Espaola.
2. Con respecto a los eventos, el sistema TIC simplemente asigna a los campos
del formato de la DGT que correspondan un valor en base a unas tablas
cortas (que contienen la equivalencia entre los posibles valores que puedan
tomar dichos campos, y los cdigos de la Tabla de Eventos que mejor los
describan), en base a las cuales la empresa GEWI diseo el Conversor DGT
TIC (vase la Figura 36).
100
Las especificaciones de (14) permiten construir la Figura 48, la cual ilustra los
puntos anteriores.
R B OLERDOLA 2 N N-340 1210 1213 * DESVIAMENTS SENYALITZATS
Otros
Por defecto:
Expira en 30 min
Desvo
Recomendacin
Evento 3
Duracin
Por defecto:
hora
Tabla 31
Evento 2
Evento 1
Tabla 30
Localizacin 2
Tabla 29
Localizacin 1
Carretera
Procesado
Tab. Loc ES
Por defecto:
Vaco
Administracin
Por defecto:
Vaco
Registro DGT
Registro TIC
Editor
Figura 48. Correspondencia entre los datos de la DGT y los campos del TIC Editor.
El contenido de las Tablas 29, 30 y 31 se presenta a continuacin.
Retenciones,
Nivel
Obras y
DGT
Climatologa
Significado DGT
Circulacin
Cdigo Tabla
Evento
Eventos ES
(castellano)
133
interrumpida (carretera
Trfico
retenido
cortada)
R
Circulacin
saturada
101
Trfico rojo
115
Trfico
(con retenciones)
A
Circulacin discontinua
(lenta con retenciones
espordicas)
amarillo
101
Circulacin intensa
122
Trfico verde
Cadenas
26
Obligatorio
usar cadenas
Puertos de
montaa
Cerrado
401
Carretera
cortada
Tabla 29. Correspondencia entre el campo Nivel de los registros de la DGT y el Cdigo de Evento
TMC asignado.
Prefijo
Significado DGT
DGT
R
Cdigo Tabla
Evento
Eventos ES
(castellano)
136
Congestin de
Retenciones
trfico
C
Climatologa
--
--
Puertos
--
--
Obras
701
Obras
Tabla 30. Correspondencia entre el campo Prefijo de los registros de la DGT y el Cdigo de Evento
TMC asignado.
Causa DGT
Significado DGT
Retenciones
Cdigo
Evento
Tabla
(castellano)
Eventos ES
0
Congestin
136
Congestin
trfico
Circulacin
--
--
Accidente
201
Accidente
Inundacin
942
Inundacin.
Precaucin
de
102
Competicin
1502
deportiva
Acontecimiento
deportivo
Fiestas
1506
Feria
Manifestacin
1513
Manifestacin
Desprendimientos
946
Desprendimientos.
Precaucin
Climatologa
Vehculo averiado
211
Vehculo averiado
Otras
--
--
Nieve
1012
Nieve en calzada
Niebla
1332
Aviso de niebla
Lluvia
1112
Lluvia
Viento
1205
Vientos fuertes
Hielo
1048
Peligro de placas
de hielo
Tabla 31. Correspondencia entre el campo Causa de los registros de la DGT y el Cdigo de Evento
TMC asignado.
5.4.4. Formato de los datos enviados a RNE:

El sistema TIC permite enviar los mensajes RDS/TMC empleando el protocolo
UECP SPB 490, por lo que el formato de los datos se adapta a lo explicado a partir
de la seccin 3.3.2.2, hasta la seccin 4. En se ilustrarn detalles sobre el formato
de los datos, mediante ejemplos de pruebas realizadas.
5.5. ANLISIS DEL FORMATO DE DATOS INTERNO DEL SISTEMA TIC:

El formato de datos interno del sistema TIC est basado completamente en el
lenguaje XML. Tomando como ejemplo la estructura de algunos mensajes del TIC
Editor en formato xml, fue posible identificar completamente todos los elementos y su
103
funcin, a partir del tag (etiqueta) y el xpath de cada uno, mediante el estudio de (15)
y (16)12.
La Figura 49 presenta dicho anlisis. Debido a su tamao, ha tenido que ser
dividida entre las siguientes dos pginas.
12
La finalidad de analizar la representacin interna xml de los datos hecha por el sistema TIC se
explica en una de las secciones del prximo captulo.
104
105
Figura 49. Identificacin y descripcin de todos los elementos del formato de datos interno del sistema
TIC, a partir del estudio de unos mensajes reales.
5.6. RESULTADOS DE LAS PRUEBAS RDS/TMC ENTRE EL RACC Y RNE:

Durante el proceso de validacin del sistema en conjunto (incluyendo el envo
de las tramas SBP con la informacin RDS/TMC por parte del TIC Server, estabilidad
en la lnea de comunicaciones entre RNE y el RACC, y la correcta recepcin de los
106
datos en la Direccin Tcnica de RNE), el primer problema que se present vino del
propio TIC Server: La configuracin inicial del sistema enviaba la informacin ODA
empleando el MEC:h42 (ODA Free-format group). Esto, aunque vlido, no era
interpretado por algunos de los codificadores de RNE.
Inicialmente, el servidor
estaba enviando lo siguiente:

FE-00-00-00-08-42-10-00-10-04-60-CD-46-01-3E-FF
Se trata de una trama SPB que lgicamente no estaba siendo distribuida
(ntese que emplea las direcciones globales de sites y encoders); tena slo fines de
prueba. El Application Group Type Code es h10, es decir, un grupo 8A (vase la
Tabla 11), y el segundo MED es h00, lo cual quiere decir que la informacin era
transmitida una sola vez (y luego retirada), y con modo y prioridad normales.
Tambin se observa que los 3 MEDs restantes contienen informacin ODA (por
ejemplo, los ltimos dos son el AID del estndar Alert-C). En resumen, se estaba
intentando enviar informacin ODA a travs de un grupo 8A. Para enviarla por un
grupo 3A, habra que cambiar el primer MED a h06. Sin embargo, el MEC:h42 slo
permite que dicho MED est en el rango h07-h1B.
Una propuesta por parte de RNE fue que ellos enviasen la informacin ODA
mediante una trama con un MEC:h40 con un timeout de 3 minutos, y el servidor TIC
enviase una trama con un MEC:h42 cada dos minutos para refrescar dicho timeout.
El minuto adicional se tratara de un margen para compensar las diferencias de
segundos entre dos envos, ya que el servidor RDS transmite por un slo canal de
datos toda la informacin dinmica de todas las redes de RNE, por lo que podra
suceder que los intervalos entre dos tramas entrantes al servidor RDS se
incrementasen a su salida (dependiendo del flujo de datos del resto de las
aplicaciones RDS en el momento). Sin embargo, al final se opt por la idea ms
natural: Enviar la informacin ODA y los mensajes TMC empleando los MECs que
han sido diseados con ese propsito: MEC:h40 (ODA Configuration and Short
Message Command) y MECh:30 (TMC), respectivamente.
107
Una tercera posibilidad hubiera sido emplear el MEC:h24 (Free-format group),

pero se descart desde el comienzo porque dicho MEC no es aceptado por una
aplicacin externa del servidor RDS de RNE. Las Figuras 50 y 51 son imgenes de
dos de las aplicaciones utilizadas por RNE para analizar la informacin emitida por el
TIC Server.
Figura 50. Pantalla del Gestor SPB.
Figura 51. Pantalla del Analizador de Protocolos RDS.
108
Otros inconvenientes que se presentaron fueron:

- Inestabilidad en el flujo de datos (lo cual acarreaba prdidas de informacin).
- Pausas de transmisin menores a los 5 segundos solicitados.
- El servidor no enviaba mensajes TMC, slo informacin TMC (grupo 8A) con las
variantes 4 y 5 con los datos TIC y GEWI, respectivamente como el
Proveedor del Servicio.
- La tasa de transmisin de datos de salida estaba fija en 9600 bps.
- El servidor enviaba informacin ODA (grupo 3) con variantes 0 y 1, pero
transmitiendo siempre AID = 0000, cuando debera haber transmitido AID =
CD46 (correspondiente a Alert-C)
- En la variante 0 del grupo 3A no se especificaba el Message Geographical
Scope (Internacional, Nacional, Regional, Urbano), pues los 4 bits estaban
fijados en 0.
- Inicialmente todas las tramas eran empaquetadas empleando la direccin SPB
000/00, cuando la que haba sido asignada era 000/0B. (correspondiente a toda
la red de emisoras de RNE-CLAS, incluyendo Baleares y Canarias).
- El Identificador del Proveedor de Servicio (SID) era inicialmente 0.
A finales del 2006 se hicieron otras pruebas menores, utilizando esta vez otra
direccin para que la informacin se transmitiese slo en la red de emisoras de RNECLAS de Catalua: 107/02 (formato SPB), o equivalentemente, h41C2. Se crearon y
enviaron varios mensajes desde el TIC Editor, que fueron recibidos por RNE con una
direccin errnea: h01C2.
La Figura 52 es un fragmento de la pantalla del servidor donde se fijan las
direcciones.
109
Figura 52. Fragmento de la pantalla del TIC Admin, donde se fijan, entre otros parmetros, las
direcciones SPB.
Estas se introducen en formato decimal, tal como se especifica en (17). As,

los rangos correspondientes son 0-1023 para la site addres y 0-63 para la encoder
address. Por su parte, los valores h107 y h02 son, en formato decimal, 263 y 2
respectivamente, as que la configuracin presentada en la Figura 52 es correcta.
Otro problema que surgi tuvo que ver con las informaciones recibidas: Los
mensajes se crearon con una tiempo de vigencia de 24 horas, durante las cuales
RNE no recibi ninguna incidencia, pero s la informacin ODA y la de etiquetado del
Proveedor de Servicio. Curiosamente, el registro de salida del da de la prueba del
mdulo RDS/TMC no reflejaba ninguna anomala (excepto por la direccin errnea
h01C2, obviamente): Los mensajes creados se estaban enviando con normalidad,
junto con alguna informacin de sintonizacin peridica. La figura 53 es un extracto
de este registro.
Figura 53. Extracto del registro de salida del mdulo RDS/TMC.
110
En el registro se observa tambin cmo las variantes 0 y 1 del grupo tipo 3A

son emitidas alternadamente, y la informacin es enviada cada 5 segundos.
Finalmente, fue necesario ponerse en contacto con la lnea de soporte del TIC, que
ofreci una simple respuesta al da siguiente: Se trata de un bug (error en el cdigo)
que ya ha sido detectado por GEWI, y que est solventado en su nueva versin del
sistema TIC.
111
6. MEJORAS IDENTIFICADAS
An cuando el sistema TIC constituya el ncleo del presente proyecto, no todo

el trabajo se realiz directamente sobre l. Una parte importante de las actividades
consisti en el diseo de nuevas especificaciones, que permitiesen enriquecer las
fuentes y fiabilidad de la informacin del sistema, as como de darle en un futuro
prximo nuevas aplicaciones al mismo. A grosso modo, las mejoras realizadas al
sistema se pueden agrupar en las cinco categoras que se plantean en las siguientes
secciones.
6.1.
INCORPORACIN DE NUEVAS FUENTES DE DATOS AL SISTEMA:
El objetivo era incorporar datos estticos y dinmicos al sistema TIC. Los

datos seran de distintas procedencias: La DGT, el Servei Catal de Trnsit (SCT), y
estudios de seguridad europeos en los que ha participado el RACC. Se
seleccionaron los campos de inters de cada tipo de fuente, y se iniciaron las
acciones con GEWI para agregar estas informaciones al sistema TIC. La idea inicial
sera poder ver estos datos como Puntos de Inters sobre un mapa. Las fuentes y
sus formatos se explican a continuacin.
6.1.1. Informacin de Radares:

6.1.1.1. Radares de la DGT:
En la Tabla 32 se muestra un ejemplo del formato de los radares de la DGT.
VA
Pk
Direccin
Operativo
M-40
52,785
Descendente
Vel. mxima Longitud Latitud

---
Tabla 32. Ejemplo del formato de los radares de la DGT.
---
---
112
El link a esta informacin es: http://www.dgt.es/trafico/radares/radares.htm

6.1.1.2. Radares del SCT:
En la Tabla 33 se muestra un ejemplo del formato de los radares del SCT.
VA
Direccin Operativo Vel. mxima Longitud
Pk
C-31 186,068
--
--
100
Latitud
419743,25 4569633,88
Tabla 33. Ejemplo del formato de los radares del SCT.
El link a esta informacin es: http://www.gencat.net/transit/docs/radars.txt
6.1.2. Puntos Negros:

Son puntos de las carreteras donde se ha registrado un nmero importante de
accidentes.
6.1.2.1. Puntos negros de la DGT:
En la Tabla 34 se muestra un ejemplo del formato de los puntos negros de la
DGT.
VA
Pk
Longitud de la seccin
Direccin Accidentes con

vctimas
(m)
A-3
6,5
100
Ascendente
Tabla 34. Ejemplo del formato de los puntos negros de la DGT.
113
El link a esta informacin es:

http://www.dgt.es/trafico/puntos_negros/puntos_negros.htm
6.1.2.2. Puntos negros del Pas Vasco:

En la Tabla 35 se muestra un ejemplo del formato de los puntos negros del
Pas Vasco.
VA
A-68 Autopista
Pk
23
Accidentes con vctimas Accidentes con
[99-03]
vctimas [02-03]
11
Bilbao Zaragoza
Tabla 35. Ejemplo del formato de los puntos negros del Pas Vasco.
El link a esta informacin es: http://www.trafikoa.net/index.asp?menu=62&lang=es
6.1.3. EuroRAP:
El European Road Assessment Program (EuroRAP) es un estudio europeo
que tiene por fin evaluar la seguridad de las carreteras. El RACC es uno de los
representantes espaoles. Los datos a incluir seran acordados ms adelante.
6.1.4. EuroTAP:
El European Tunnel Assessment Program (EuroTAP) es un estudio que tiene
por fin evaluar la seguridad de los tneles europeos. Los datos a incluir seran
acordados ms adelante.
114
6.1.5. Cmaras en lnea:

La ltima versin del sistema TIC incorpora pestaas en el TIC Info Wizard
para ver imgenes en tiempo real de las cmaras de trfico. Por el momento, el
RACC estara interesado en tener acceso a las cmaras directamente desde la List
Window del TIC Editor, cuando estuviesen disponibles.
Un link a una cmara de trfico de la DGT es:
http://www.dgt.es/trafico/camaras/tramo_a2_38300_55150.htm
Un link a una cmara de trfico del SCT es:

http://www.gencat.net/transit/marcam_mct.htm
6.2.
INCORPORACIN DE LOS DATOS DINMICOS DEL SATI:

6.2.1. Justificacin e inters:
En este caso, se plantea la incorporacin de datos dinmicos procedentes del
sistema de asistencia del RACC SATI pertenecientes a la categora de servicio

ACCIDENTE al sistema TIC. Esta informacin puede aportar un valor aadido a los
datos de los que dispone el departamento de trfico. De esta manera, la nueva
configuracin de mdulos del sistema sera la descrita en la Figura 54.
115
TIC Editor
Conversor
DGT - TIC
DGT
SATI
Conversor
SATI - TIC
Formato
XML del
TIC
Formato
XML del
TIC
Servicios TIC
Formato
XML del
TIC
Mdulo
RDS/TMC
RNE
Informacin de trfico
Estado del sistema
Formato
XML del
TIC
Mdulo
RDS/TMC
Referencia del sistema TIC

Tabla de Eventos: Espaa
Tabla de Localizaciones: Espaa
Lenguaje de interfaz de usuario: Espaol / Ingls
Figura 54. Diagrama de la arquitectura del sistema TIC del RACC, con la incorporacin de los datos
del SATI.
En la Tabla 36 se presentan los campos de inters13:

CAMPO
N Expediente
TIPO
Entero
N de servicio
Entero
Tipo de incidencia
Char
Avera
Char
Va
Tipo de va
Nmero (urbana) / Km
(interurbana)
Sentido
Ubicacin
Char
Char
Entero
LONGITUD
COMENTARIOS
8
N Expediente y n servicio (campo 2) son
necesarios para identificar cada peticin
de servicio
9
Slo ser de inters el primer servicio de
cada expediente
24
Slo de inters cuando contenga la
palabra ACCIDENTE
24
Actualmente, puede ser ACCIDENTE y
ACCIDENTE CON EXTRACCIN pero
todas las subcategoras del cdigo de
incidente 3 son de valor para el interfaz
50
10
Se informar en entorno urbano
6
Char
Char
20
20
Localidad del incidente

Provincia del incidente
Char
Char
50
40
13
Slo disponible a nivel interurbano

Ejemplo: EXTERIOR, PARKING A PIE DE
CALLE, etc.
En la seccin de Apndices se presentan varias pantallas de la aplicacin del SATI, para poder
comprender la ubicacin de los campos de inters dentro de la interfaz del programa.
116
Lugar del incidente

Fecha del incidente
Char
Char
254
10
Hora del incidente

Char
Observaciones
Char
Descripcin de la compaa
Char
Descripcin Tipo vehculo
Char
Descripcin Marca
Char
Entorno: Urbano (U) / Interurbano Char
(I)
Medio preferente
Char
Estado de la incidencia
Char
5
254
30
30
20
1
Fecha del estado de la incidencia Char
Latitud
Double
Longitud
Double
dd/mm/aaaa (coincidir con la fecha de

peticin del primer servicio)
hh:mm
7
10
Puede ser PETICIN, ANULADO o

CERRADO
10
dd/mm/aaaa (fecha en que se cree o
modifique el estado de la incidencia
campo 21 ).
8 (precisin Puede ser NULL, cuando el usuario teclee
decimal: 2) el nombre de una va que no se pueda
traducir a un punto de la cartografa de
Teleatlas
8 (precisin Puede ser NULL, cuando el usuario teclee
decimal: 2) el nombre de una va que no se pueda
traducir a un punto de la cartografa de
Teleatlas
Tabla 36. Caractersticas de los campos de inters del SATI.
6.2.2. Propuesta:
La representacin fsica de los datos requeridos, as como la correspondencia
con los nodos del documento XML, se muestran en la Tabla 37.
CAMPO SATI
N Expediente
TIPO DATOS
NODO XML
NUMBER(8)
NUM_EXPEDIENTE
N de servicio
NUMBER(2)
SERVICIO/NUM_SERV
Fecha peticin del

servicio
DATE
SERVICIO/FECHA_SERV
Tipo de incidencia
VARCHAR2(30) INCIDENCIA
Avera
VARCHAR2(30) AVERIA
COMENTARIOS
Nmero del expediente que genera la
peticin de servicio
En este caso, siempre ser 1, ya que
slo se transmitirn los primeros
servicios
En formato dd/mm/aaaa hh:mm. En
realidad ser la Fecha de cambio de
estado del servicio
En este caso siempre ser
ACCIDENTE, ya que slo se
transmitirn servicios de tipo
ACCIDENTE
ACCIDENTE CON EXTRACCIN pero
117
Tipo de va
VARCHAR2(2) VIA/TIPO_VIA
Va
VARCHAR2(50) VIA/NOMBRE_VIA
Nmero (urbana)
VARCHAR2(10) VIA/NUM_VIA
Km (interurbana)
NUMBER(7,3) VIA/KM_VIA
Sentido
VARCHAR2(30) VIA/SENTIDO
Ubicacin
VARCHAR2(30) UBICACION
Localidad del
incidente
Provincia del
incidente
Lugar del incidente
VARCHAR2(50) INCIDENTE/LOCALIDAD_I
Fecha del incidente
DATE
INCIDENTE/FECHA_INC
Hora del incidente
DATE
INCIDENTE/HORA_INC
Medio preferente
VARCHAR2(30) INCIDENTE/MEDIO_PREF
Observaciones
VARCHAR2
INCIDENTE/OBSERVACIO
(1000)
NES_INC
VARCHAR2(30) COMPANYIA
NC
VARCHAR2(40) INCIDENTE/PROVINCIA_I
NC
VARCHAR2(80) INCIDENTE/LUGAR_INC
ERENTE
Cdigo de la
compaa
Descripcin Tipo
vehculo
Descripcin Marca
Entorno
VARCHAR2(50) TIPO_VEHICULO
VARCHAR2(20) MARCA_VEHICULO
VARCHAR2(12) ENTORNO
Estado de la
incidencia
VARCHAR2(10) ESTADO
Latitud
NUMBER(8)
LATITUD
Longitud
NUMBER(8)
LONGITUD
todas las subcategoras del cdigo de

incidente 4 son de valor para el interfaz
Contiene el tipo de va dnde se ha
producido el accidente
Contiene el nombre de la va dnde se
ha producido el accidente
Si la va es URBANA, se enva el
nmero de la va en la que se ha
Si la va es INTERURBANA, se enva el
km de la va en la que se ha producido
el accidente
Si la va es INTERURBANA, se enva el
sentido de la va en la que se ha
Contiene la ubicacin del accidente. Ej:
EXTERIOR, PARKING CUBIERTO, etc.
Contiene el nombre de la localidad
dnde se ha producido el accidente
Contiene el nombre de la provncia
Contiene una descripcin del lugar
En formato dd/mm/aaaa. Contiene la
fecha en la qu se ha producido el
accidente (coincide con la fecha de
peticin de servicio)
En formato hh:mm. Contiene la hora en
la qu se ha producido el accidente
Contiene el medio preferente que se ha
asignado para el servicio
Contiene observaciones relacionadas
con el accidente
Contiene la compaa del socio
Contiene una descripcin del tipo de
vehculo
Contiene la marca del vehculo
Contiene la descripcin del entorno en
el que se ha producido el accidente.
Puede ser URBANO o INTERURBANO
Contiene el estado del servicio. Puede
ser PENDIENTE, ASIGNADO (slo
cuando es un nuevo servicio),
ANULADO o CERRADO
Contiene la coordenada Y de la
posicin en la que se ha producido el
accidente
Contiene la coordenada X de la
posicin en la que se ha producido el
accidente
Tabla 37. Representacin fsica de los campos de inters y su correspondencia con los nodos del
documento XML.
118
Se propone enviar la informacin solicitada siempre que se inserte un primer

servicio con una incidencia de tipo ACCIDENTE o se actualice un primer servicio
de nuevo, con una incidencia de tipo ACCIDENTE que provoque un cambio de
estado (a CERRADO o ANULADO)14.
Adems, con objeto de simplificar la conversin entre los datos del SATI y la
estructura interna del TIC, se propone el envo de informacin como una cadena en
formato XML, similar al siguiente ejemplo:
<RACC_SATI>
<ACCIDENTE>
<NUM_EXPEDIENTE>7349434</NUM_EXPEDIENTE>
<SERVICIO>
<NUM_SERV>5</NUM_SERV>
<FECHA_SERV>28/03/03</FECHA_SERV>
</SERVICIO>
<INCIDENCIA>ACCIDENTE</INCIDENCIA>
<AVERIA>ACCIDENTE LEVE</AVERIA>
<VIA>
<TIPO_VIA>AV</TIPO_VIA>
<NOMBRE_VIA>DIAGONAL</NOMBRE_VIA>
<NUM_VIA>651</NUM_VIA>
<KM_VIA/>
<SENTIDO/>
</VIA>
<UBICACION>PRKING CUBIERTO</UBICACION>
<INCIDENTE>
<LOCALIDAD_INC>Esplugues De Llobregat</LOCALIDAD_INC>
<PROVINCIA_INC>BARCELONA</PROVINCIA_INC>
<LUGAR_INC/>
<FECHA_INC>28/03/2003</FECHA_INC>
<HORA_INC>10:41</HORA_INC>
<MEDIO_PREFERENTE>GRA</MEDIO_PREFERENTE>
<OBSERVACIONES_INC/>
</INCIDENTE>
<COMPANYIA>REIAL AUTOMOBIL CLUB CATALUNYA</COMPANYIA>
<TIPO_VEHICULO>TURISMO</TIPO_VEHICULO>
<MARCA_VEHICULO>FORD</MARCA_VEHICULO>
<ENTORNO>URBANO</ENTORNO>
<ESTADO>CERRADO</ESTADO>
<LATITUD>5018067</LATITUD>
<LONGITUD>171957</LONGITUD>
</ACCIDENTE>
</RACC_SATI>
14
Los primeros servicios suelen ser los que aporten informacin potencialmente til para Infotrnsit.
Los siguientes servicios son de carcter ms administratvo.
119
Quedara por definir el protocolo para el traspaso de datos desde el SATI al

TIC.
6.2.3. Carga de Datos Estticos:

Se trata en realidad de una solicitud bastante similar a la planteada en 6.1
(son incluso los mismos datos a cargar). Su formato ser el siguiente:
latitud|longitud|va|punto kilomtrico|tipo|parmetros asociados al tipo...
Los datos sern cargados inicialmente de manera manual en el SATI, pero

slo se dispondr de las siguientes informaciones:
latitud|longitud|
|tipo|parmetros asociados al tipo...
|va|punto kilomtrico|tipo|parmetros asociados al tipo...
(No disponibles)
Por tanto, es necesario disponer de un proceso (o programa) que, al ser

provisto de una carretera y punto kilomtrico, devuelva su latitud-longitud, o
viceversa. De esta manera, los datos de salida del SATI estarn completos, y as
sern cargados en el TIC. La Figura 55 contiene los atributos y formato de los
datos de entrada, as como ejemplos.
Tambin se requiere obtener informacin de puntos de inters (estaciones
de servicio, parkings, restaurantes, etc.) a partir de la cartografa del SATI.
120
Figura 55. Atributos, formatos y ejemplos de los datos de entrada del SATI al sistema TIC.
121
6.3.
EL SISTEMA DE INFORMACIN DE TRFICO RACC TME:
El objetivo es disear y desarrollar un sistema que rena la informacin de

trfico disponible en Espaa gracias al RACC y la ponga a disposicin de los
servicios Movistar a travs de un interfaz SOAP (web services). En el presente
proyecto se definirn:
-
Las entidades que intervienen en la provisin de informacin de trfico:

Requisitos funcionales de las fuentes de informacin, del servidor de
informacin de trfico y del cliente.
Una arquitectura, unos modelos de operacin y un modelo de datos que

defina la integracin entre los actores, basado en modelos estndares
disponibles (DATEX 2).
Unos parmetros de calidad mnimos para cada una de las entidades

participantes.
Actualmente existe un conjunto de especificaciones elaboradas por iniciativa
de la comisin Europea en el proyecto D2 (Datex 2) que describen los

procedimientos de intercambio de informacin de trfico entre centros o servidores
de informacin de trfico, como evolucin al primer estndar Datex especificado.
6.3.1. Requisitos para el intercambio de informacin:

Los requisitos para el intercambio de informacin para el Sistema de
Informacin de Trfico en Tiempo Real de TME (SITTR) son:
-
La comunicacin se basar en http 1.1.
El sistema podr obtener informacin de diversas fuentes de informacin

(DGT, introduccin manual de datos, etc.) y sera deseable que tambin
pudiera integrarse con sistemas de informacin de trfico compatibles con
Datex 2 Low cost profile y Datex 2 Regular Profile.
122
El sistema podr publicar la informacin de manera activa (accesible en

tiempo real) utilizando dos web services: PULL y PUSH.
Se utilizar el modelo de datos compatible con el esquema DATEX 2 para

caracteriza la informacin.
Se establecern procedimientos que garanticen la autorizacin de los

accesos, la integridad de los datos y el correcto intercambio de informacin
(por ejemplo HTTPS, VPN, etc.). Los clientes debern ser capaces de detectar
si el servidor o el enlace est cado y debern ser capaces de sincronizar su
base de datos con la del servidor en cualquier momento.
Se debern garantizar niveles adecuados de disponibilidad de la informacin.

Los clientes debern saber que informacin est disponible en cada momento
y, a ser posible, se marcar la informacin como nueva, actualizada, sin
cambios o invalidada.
El volumen de datos y la latencia de envo deben ser adecuados para la

provisin de servicios mviles: Se deber estudiar si se comprime o no la
informacin.
6.3.2. Arquitectura funcional:

La Figura 56 muestra un esquema bsico de la arquitectura de comunicacin
del SITTR, indicando los actores que intervienen en el acceso al mismo y sus roles:
Fuentes de datos
Proveedores de
informacin.
SITTR
Suscripcin y
acceso a
informacin de
las Fuentes +
Provisin de
informacin
global a
clientes.
Operador
Gestin y Operacin del
Cliente
Suscripcin a SITTR
+ acceso a
informacin de trfico
Figura 56. Esquema bsico de la arquitectura de comunicacin del SITTR.
123
El rol de cada uno de ellos es el siguiente:
Fuentes: Son proveedores de informacin de trfico que ofrecen sus

contenidos a travs de diversos interfaces a sus clientes. En Espaa los
interfaces que utilizan las fuentes de informacin no siguen el estndar
DATEX 2, sino que suelen utilizar interfaces propietarios: webs propietarias
(como la mayora de los ayuntamientos) o simplemente realizando entradas
de datos directas sobre el sistema del cliente, etc. (18) El RACC tambin tiene
un Servidor de informacin de trfico con un interfaz propietario para
intercambiar informacin.
El SITTR se adaptar inicialmente al interfaz propietario del RACC para
comenzar a proveer informacin de trfico a los clientes15. En un futuro sera
deseable que adems pudiera intercambiar informacin con otros centros de
informacin de trfico segn la metodologa descrita en el estndar DATEX 2.
SITTR: El sistema de informacin de trfico en tiempo real de Telefnica ser

capaz de interpretar la informacin servida por las diversas fuentes de
informacin, de modelarla segn el modelo lgico de datos (definido en
DATEX 2) y de proporcionrsela a los clientes segn un protocolo SOAP (web
services). La tendencia de desarrollo ser hacer compatible el SITTR con el
estndar DATEX 2 como centro de intercambio de informacin de trfico.
Operador: Ser el encargado de gestionar las suscripciones (crear, editar y

borrar suscripciones) y operar sobre el sistema SITTR para garantizar la
correcta recepcin de datos desde las fuentes y el correcto acceso a los datos
por parte de los clientes. Tambin evaluar la calidad de la informacin de las
fuentes.
15
Por esta razn, fue necesario comprender en 5.5 la representacin interna que hace el sistema TIC
de los datos.
124
Clientes: Se suscribirn al servicio y recibirn la informacin proporcionada

por el SITTR a travs del protocolo que este proporcione. Un cliente puede ser
otro sistema de informacin de trfico o simplemente un cliente final.
Particularmente, en este proyecto el cliente de la informacin ser el servicio
Ruta Movistar.
6.3.3. Protocolos de comunicacin:

Se tomarn como referencia las metodologas de intercambio de informacin
definida por el estndar DATEX 2 entre los centros de informacin de trfico: LCP
(Low Cost Profile) y RP (Regular Profile). Estas metodologas se basan en una
arquitectura cliente/servidor y utilizan como protocolo de transporte HTTP 1.1 (sobre
el que se puede implementar una capa de seguridad SSL, TSL, etc). La diferencia
entre LCP y RP es que el Regular Profile aade una capa SOAP y el LCP utiliza
HTTP directamente (utilizando GET/RESPONSE).
El SITTR ofrecer dos servicios (web services) para ofrecer la informacin a
los clientes:
-
Pull Service: Servicio basado en peticin del cliente-respuesta del servidor.
Push Service: Servicio de envo de informacin al cliente sin previa peticin

(peridicamente o ante cambios)
Para optimizar los recursos, como norma general los servicios Pull y Push del
SITTR ofrecern informacin al cliente tan slo si se han producido cambios desde la
ltima vez que se envi la informacin al mismo. En caso de que no se hubieran
producido actualizaciones desde el ltimo envo, el servidor indicar este hecho y
enviar la trama sin contenido.
125
6.4.
SELECCIN Y ADQUISICIN DE UN NAVEGADOR GPS:
Una vez solucionados los problemas tcnicos de la provisin del servicio

RDS/TMC, el siguiente paso lgico para el RACC como Proveedor de Servicio ser
validar in situ las informaciones emitidas desde su sede, antes de salir oficialmente al
aire. Para ello, se requiere de un receptor RDS/TMC comercial (para estar en las
mismas condiciones que los usuarios finales); tpicamente se consiguen en radio
reproductores para vehculos. Algunos navegadores GPS tambin ofrecen esta
funcionalidad, pero son la minora.
Por otra parte, las ventajas en trminos de movilidad que ofrecen los
navegadores GPS son muy superiores a las de los radio reproductores, y por ende
ms conveniente para las tareas que suelen tener lugar dentro de la Fundacin
RACC, razn por la cual una de las ltimas tareas desarrolladas durante este
proyecto fue el llevar a cabo un estudio de mercado de estos dispositivos, con el fin
de encontrar el dispositivo ms adecuado.
En la seccin de Apndices se presenta el Estudio completo, incluyendo una
tabla comparativa de los siete modelos seleccionados. Por razones de espacio, slo
se presentarn a continuacin las caractersticas del modelo adquirido, e imgenes
de su desempeo.
6.4.1. Caractersticas del Mio C710:

Cartografa digital: TeleAtlas.
Receptor GPS: SiRF STAR III, de alta sensibilidad (20 canales), compatible
con WAAS.
Pantalla: Display LCD QVGA de 3.5, resolucin de 320 x 240 pixels, 64K
colores, pantalla tctil.
Una brjula aparece en pantalla.
Dimensiones: 110 mm x 70 mm x 20 mm.
126
Peso: 170 grs.

CPU 400 MHz.
RAM 64 MB.
Sistema Operativo Microsoft Windows CE .Net 4.2 Core versin [5].
Batera: Interna, Litio-Ion, con autonoma de 4.5 - 5.5 hrs (segn uso).
Memoria interna de aprox. 2 GB.
Tecnologa Bluetooth para soportar llamadas manos libres.
Avisos de calles por voz: 16 idiomas precargados.
Mapas precargados de toda Europa Occidental.
Permite buscar direcciones y POIs.
Permite buscar contactos Outlook y sincronizarlos con el PC.
Incluye miles de POIs precargados.
Permite cargar POIs personalizados, as como encontrar lugares que ya se
han visitado (historial).
Base de datos de cmaras de seguridad preinstalada.
Permite recibir avisos (visuales y sonoros) al acercarse a cmaras de
seguridad, fijas o mviles.
Ranura para tarjetas de memoria SD.
Receptor de informacin de trfico incorporado (chip GNS-FM4) [5].
Cable Mini USB Active Sync para descargar datos desde el PC, actualizar el
dispositivo y organizar los archivos (canciones, fotos, mapas, etc).
Los lmites de velocidad a lo largo del camino son mostrados en todo
momento.
Reproductor mp3 incorporado.
El dispositivo incorpora un altavoz, para escuchar las instrucciones habladas,
canciones y llamadas manos libres al volumen que se desee.
Micrfono tambin incorporado.
Distintos perfiles de usuario: coche, motocicleta, peatn, etc.
Permite cargar, almacenar y ver fotos.
Calculadora.
127
Planificador de rutas segn distintos criterios: la ms rpida, la ms corta,

evitando autopistas de peaje y carreteras congestionadas.
Replanificacin rpida de ruta: Si se sale de la ruta original, el dispositivo
vuelve a planificar inmediatamente la ruta a partir del lugar donde se
encuentre.
Display informativo: Tiempo y distancias estimados hasta el destino, estado de
la batera y seal.
Las figuras 57 a 63 son imgenes del Mio C710, realizando distintas
actividades.
Figura 57. Determinando una direccin cualquiera: C/Jordi Girona, 31. Barcelona.
128
Figura 58. Pantalla de informacin sobre la seal GPS, y otras informaciones.
Figura 59. Pantalla de ajustes TMC, donde se puede elegir que el dispositivo tenga o no presente los
mensajes TMC al momento de calcular una ruta. En la imagen, el navegador no ha conseguido
todava ninguna estacin de radio que transmita informacin TMC.
129
Figura 60. Se observa que el dispositivo ha conseguido una estacin de radio que transmite
informacin TMC: RNE 3.
Figura 61. Pantalla de mensajes de trfico: Lista todas las incidencias captadas hasta el momento.
130
Figura 62. Clculo de una ruta entre dos puntos sin considerar los mensajes TMC: El dispositivo
simplemente busca la ruta ms directa, sin importar que en ella haya retenciones de trfico. La lnea
roja representa la ruta establecida; la lnea azul la congestin (est cubierta por la roja, pero se ve su
indicativo)
Figura 63. Clculo de una ruta entre dos puntos considerando los mensajes TMC: El dispositivo opta
por rutas alternas (en la medida de lo posible) para evitar las retenciones de trfico. La lnea roja
representa la ruta establecida; la lnea azul la congestin.
131
6.5.
MEJORAS Y AJUSTES REALIZADOS AL SISTEMA TIC:
Durante el desarrollo del proyecto, se le efectuaron varios ajustes al sistema

TIC, en aras de mejorar su desempeo, desde todos los frentes: Directamente en el
TIC Admin, a travs del Explorador de Windows, e incluso desde el Command
Prompt. A continuacin, se explicarn brevemente.
-
Actualizacin de la Tabla de Localizaciones Espaola: Como ya se ha

comentado previamente, el servicio TMC requiere el uso de una Tabla de
Eventos y una Tabla de Localizaciones; ambas aprobadas previamente por el
TMC Forum y la DGT. La versin anterior de la Tabla de Localizaciones
Espaola v. 1.6 , con fecha de enero de 2005, contena 4577 puntos TMC.
La nueva versin v. 2.1 entr en vigor a partir del 2 de octubre del 2006, y
contiene ahora 7763 puntos.
Dada su arquitectura Cliente/Servidor, la Tabla debi de actualizarse en
ambas mquinas. Sin embargo, al verificar el funcionamiento del TIC Editor,
surgi un nuevo problema: La conexin con el servidor estaba bien
establecida, y la Tabla de Localizaciones nueva ya estaba cargada, pero no se
detectaba ningn mensaje con codificacin TMC.
Inclusin del fichero POINTSPK.dat: Una vez aprobadas las Tablas de

Localizaciones, estas suelen ser distribuidas en un fichero comprimido
(generalmente un .zip). Este fichero contiene otros 23 ficheros .dat, los
necesarios para que cada sistema recree toda la jerarqua de las tablas
(Tablas, Lneas y Puntos). Por alguna razn, el fichero zip que tena el RACC
careca de unos datos llamados segn GEWI distance markers (marcadores
de distancia). Fue necesario contactar directamente con la DGT para obtener
dicho fichero. Segn ellos, se trata de un fichero intermedio, que al final no
debe ser incluido en la entrega segn el estndar respectivo. An as fue
132
posible obtenerlo, y una vez incluido en el conjunto, se reinstalaron las Tablas

de Localizaciones y se solvent el problema.
-
Saturacin de los discos: Una de las caractersticas del sistema TIC es que
guarda registros permanentemente de todas sus actividades; ficheros planos
con informacin de todos los mdulos operativos, y con los valores de todos
los QI (Quality Indicators, Indicadores de Calidad) activos. Durante el mes de
octubre el sistema empez a experimentar dificultades, respondiendo ms
lentamente, hasta que en un momento dado dej de funcionar. El TIC Editor
argumentaba que era imposible establecer la conexin con el servidor. Por
otra parte, explorar el contenido de los distintos directorios del TIC mediante el
Explorador de Windows es desaconsejable, pues al intentar abrir una carpeta
de gran tamao, el ordenador se colgar. Por ello, fue necesario revisar el
contenido de los mismos mediante el Command Prompt (y an as el
ordenador tardaba minutos en presentar el contenido de ciertos directorios).
Algunos de los discos tenan logs y QIs del 2005.
La Figura 64 muestra una pantalla del Command Prompt, empleado
para liberar en ese momento unos 435 MB de datos. Tras estas liberaciones
de espacio, el sistema volva a operar con nomalidad.
Figura 64. Liberacin de algo ms de 435 MB de datos antiguos.
133
Filtro de Catalunya: Una de las opciones del sistema es el filtrado de datos,

que puede ser realizado segn diversos criterios, siendo uno de ellos el
regional. Un filtro para Catalunya haba sido definido previamente, pero el
nmero de mensajes perdidos (a pesar de corresponder a zonas dentro de
Catalunya) era considerable, pues el polgono presentaba una forma muy
simplista. Al reformar la forma de dicho polgono, se registr un ligero aumento
en el nmero de mensajes de Catalunya. La Figura 65 muestra una pantalla
del TIC Filter Wizard (herramienta empleada para la creacin y edicin de
filtros), mientras se redefina la forma del polgono.
Figura 65. Redefinicin del filtro geogrfico del rea de Catalunya.

Imagen tomada durante el proceso.
Estimacin de la frecuencia de actualizacin del fichero gsmplus.txt: El da 13

de diciembre del 2006, se tomaron muestras cada minuto, desde las 8h29
134
hasta las 10h06, del fichero gsmplus.txt. En ocasiones se tomaron dos

muestras por minuto. Se recogieron en total 104 muestras. nicamente se
registraron cambios en estos instantes: 8h33, 8h38, 8h42, 8h45, 8h47, 8h52,
8h54, 8h56, 8h58, 9h00, 9h02, 9h06, 9h08, 9h10, 9h12, 9h14, 9h16, 9h18,
9h22, 9h26, 9h27~ 28, 9h32, 9h34, 9h36, 9h40 ~ 41, 9h43, 9h46, 9h51, 9h55,
9h57, 10h02.
Se observa que en varios intervalos la frecuencia es de 2 min. Los
claros bien pueden deberse a errores durante la medicin (por ejemplo,
anticiparse y tomar la muestra unos segundos antes de que efectivamente se
actualice el fichero); sin embargo, en aquellas ocasiones en las que la
actualizacin tardaba ms de dos minutos, se tomaron dos muestras del tercer
minuto (una al incio y otra al final), y tampoco haba variaciones. Esto indica
que las actualizaciones tampoco se realizan con gran rigurosidad, y que los
claros en las muestras no se deben slo a errores humanos, sino que la
propia DGT vara sobre la marcha la frecuencia de actualizacin.
-
Ajuste de la frecuencia de lectura del fichero gsmplus.txt: En base a lo

comentado en el punto anterior, la opcin ms fiable era establecer la
frecuencia de lectura en 2 minutos (el menor intervalo existente), para no
perder incidencias. La figura 66 corresponde a la pantalla del TIC Admin,
donde se configura el tiempo entre actualizaciones del TIC Server.
Inicialmente era de 10 min (600 segundos). Posteriormente se cambi a 2
minutos.
135
Figura 66. Ajuste de la frecuencia de actualizacin del TIC Server.
136
7. CONCLUSIONES
El TIC es un sistema diseado para el procesamiento de informacin de

trfico. Posee una arquitectura Cliente/Servidor, y un formato interno de tipo modular,
donde la representacin de los datos se basa en el lenguaje XML. El sistema cumple
con diversos estndares de comunicaciones, de telecomunicaciones y de difusin
(destacando, particularmente, el RDS/TMC). La arquitectura actual del sistema del
RACC presenta una sola fuente de datos (la Direccin General de Trfico) y un nico
destino (Radio Nacional de Espaa). En ambos casos, es necesario realizar
diferentes conversiones para adaptar los formatos de los datos al formato interno del
TIC.
Se verific el funcionamiento correcto del sistema, desde la generacin de la
informacin, hasta su transmisin y difusin (a travs del estndar RDS/TMC).
Inicialmente, especificaciones impuestas por RNE para incorporar al RACC como
Proveedor de Servicio TMC no se estaban cumpliendo, y distintos parmetros de
transmisin (tanto del estndar RDS/TMC como del UECP SPB 490) estaban
indefinidos, entremezclados o eran errneos. Las fallas mencionadas fueron
corregidas.
Se realiz una parametrizacin ptima del sistema mediante la actualizacin
de la Tabla de Localizaciones Espaola, la definicin del filtro geogrfico de datos
para el rea de Catalua, la estimacin apropiada de la frecuencia de actualizacin
de los datos de la DGT, y la configuracin correspondiente de la frecuencia de
lectura del Servidor del TIC.
Se identificaron los parmetros de inters y se defini el formato de
transmisin para incorporar seis nuevas fuentes de datos de entrada (Radares de la
DGT, Radares del SCT, Puntos Negros, EuroRAP, EuroTAP, y Cmaras del SCT y
de la DGT).
137
Se concibi un proceso a travs del sistema SATI para la integracin y

unificacin de informacin de trfico y movilidad, tanto de carcter esttico como
dinmico. Se incorporaron nicamente los datos pertenecientes a la categora
Accidentes, por ser la nica que podra afectar el estado del trfico en un momento
y locacin dados. Se definieron los parmetros de inters y su correspondiente nodo
XML en la estructura existente del SATI. Con el fin de simplificar la conversin entre
las bases de datos del SATI y del TIC, se decidi enviar la informacin en formato
XML.
Se definieron los requisitos para el intercambio de informacin entre los
servidores del RACC y Movistar, basndolos en estndares y web services actuales
(http 1.1, DATEX 2, Push, Pull), como parte del proyecto existente entre ambas
compaas.
Como trabajo futuro del proyecto RACC-Movistar se pretende desarrollar un
mecanismo que proporcione integridad y seguridad de los datos (https, VPN, etc.) y
compresin de la informacin, para su posterior puesta en marcha. En cuanto a la
incorporacin de datos dinmicos del SATI, se pretende desarrollar un proceso
automatizado para extraer los datos de inters de la estructura XML actual del SATI.
Adicionalmente, se pretende crear e implementar dentro del servidor TIC dos
conversores: El conversor nico de datos para la incorporacin de nuevas fuentes de
entrada y el conversor entre las bases de datos del SATI y del TIC, los cuales
estarn basados en los diseos planteados en este trabajo.
138
8. REFERENCIAS BIBLIOGRFICAS
1. Hendriks, Teun. Uniting Traffic Services Across America: Creating a nationwide dynamic navigation service. Teatownlake. Presentacin realizada en el
TMC Forum Showcase 2006. Londres, octubre 2006.
2. International Standards Organization. Normativa ISO 14819-1: 2003. Traffic
and Travel Information (TTI) - TTI Messages via traffic message coding - Part
1: Coding protocol for Radio Data System - Traffic Message Channel (RDSTMC) 2003.
and Travel Information (TTI) TTI Messages via traffic message coding - Part
2: Event and information codes for Radio Data System Traffic Message
Channel (RDS-TMC). 2003.
4. RDS Forum. RDS Open Data Application Registrations to date. Ginebra,
junio 2006.
and traveller Information (TTI) - TTI Messages via traffic message coding - Part
3: Location Referencing for Radio Data System - Traffic Message Channel
(RDS-TMC). 2003.
6. RDS Forum. The new RDS IEC 62106:1999 standard. Ginebra, diciembre
1999.
7. RDS Forum. RDS Universal Encoder Communication Protocol (UECP) SPB
490. Ginebra, junio 2003.
139
8. GEWI. RACC Bussiness Presentation: TIC Software. Presentacin realizada

en la Sede Central del RACC. Barcelona, enero 2003.
9. GEWI. TIC System Requirements. Especificacin interna. Bernburg, Alemania.
Mayo 2003.
10. GEWI. TIC Server Description Release 11. Especificacin interna. Bernburg,
Alemania. Mayo 2003.
11. GEWI. TIC RDSTMC Product Description Release 6. Especificacin interna.
Bernburg, Alemania. Mayo 2003.
12. Navas Elorza, Jorge. Formato de transferencia de incidencias de trfico via
fichero plano ASCII en Internet. Documento de la DGT. Madrid, sin fecha.
13. Radio Nacional de Espaa. El sistema RDS en RNE. Documento de RNE.
Prado del Rey (Madrid), marzo de 2005.
14. GEWI. TIC RACC Info DGT Specification. Especificacin interna. Bernburg,
Alemania. Febrero 2004.
15. GEWI. TIC XML Info Specification Release 11. Especificacin interna.
Bernburg, Alemania. Octubre 2004.
16. GEWI. TIC Info Specification Release 11. Especificacin interna. Bernburg,
Alemania. Octubre 2004.
17. GEWI. TIC RDS TMC User Manual Release 11. Especificacin interna.
Bernburg, Alemania. Octubre 2004.
140
18. Movistar. Anexo I Acuerdo de colaboracin para la provisin de informacin

en servicios Movistar. Documento confidencial. Madrid, Septiembre 2006.
141
APNDICES
Interfaz SATI TIC (Asistencia - Infotrnsit)

Requerimientos
RACC
Requerimientos SATI
26 Octubre 2006
Pgina 1 de 10
A. Objetivo
Actualmente se dispone en Infotrnsit del sistema TIC Centro de Informacin de Trfico
que permite la recoleccin de informacin relacionada con datos estticos y dinmicos de
trfico.
Dicha informacin se encuentra parametrizada para la gestin ptima de los datos por
parte de diferentes operadores, y el sistema permite la entrada de datos procedentes de
distintas fuentes y con diferentes formatos, as como salidas de datos en diferentes formatos y
segn diversos protocolos de comunicacin.
La siguiente figura muestra los mdulos actuales del sistema:
Editor CIT
Input
Interurb
Convertidor
CIT xml
format
Serveis CIT
Informaci de Sistema
CIT xml
format
Convertidor
Output
TMC
Estat del sistema
CIT referncia
Taula de casustiques
Taula de Localitzaci (urb+interurb)
Llenguatge de comunicaci
En este sentido, se plantea la incorporacin de datos dinmicos procedentes del sistema

de asistencia del RACC SATI pertenecientes a la categora de servicio ACCIDENTE.
Esta informacin puede aportar un valor aadido a la informacin de la que dispone el
departamento de trfico. De esta manera, la nueva configuracin de mdulos del sistema sera
la descrita en la siguiente figura:
Requerimientos SATI
26 Octubre 2006
Pgina 2 de 10
Editor CIT
Input
Accidents
Convertidor
CIT xml
format
Serveis CIT
CIT xml
format
Convertidor
Informaci de Sistema
Input
Interurb
Convertidor
CIT xml
format
Estat del sistema
Output
TMC
CIT xml
format
CIT referncia
Taula de casustiques
Taula de Localitzaci (urb+interurb)
Llenguatge de comunicaci
B. Interfaz TIC SATI

En la siguiente tabla se presentan los campos de inters:
ID CAMPO
1 N Expediente
TIPO
Entero
LONGITUD
8
N de servicio
Entero
Tipo de incidencia
Char
24
Avera
Char
24
5
6
7
8
9
Va
Tipo de va
Nmero (urbana) / Km (interurbana)
Sentido
Ubicacin
Char
Char
Entero
Char
Char
50
10
6
20
20
10
11
12
13
Localidad del incidente

Provincia del incidente
Lugar del incidente
Fecha del incidente
Char
Char
Char
Char
50
40
254
10
14
15
16
17
18
19
Hora del incidente

Observaciones
Descripcin de la compaa
Descripcin Tipo vehculo
Descripcin Marca
Entorno: Urbano (U) / Interurbano (I)
Char
Char
Char
Char
Char
Char
5
254
30
30
20
1
Requerimientos SATI
COMENTARIOS
N Expediente y n servicio (campo 2) son
necesarios para identificar cada peticin de
servicio
Slo ser de inters el primer servicio de cada
expediente
Slo de inters cuando contenga la palabra
ACCIDENTE
ACCIDENTE CON EXTRACCIN pero todas
las subcategoras del cdigo de incidente 3
son de valor para el interfaz
Se informar en entorno urbano
Slo disponible a nivel interurbano
Ejemplo: EXTERIOR, PARKING A PIE DE
CALLE, etc.
dd/mm/aaaa (coincidir con la fecha de

peticin del primer servicio)
hh:mm
26 Octubre 2006
Pgina 3 de 10
20 Medio preferente
21 Estado de la incidencia
Char
Char
7
10
22 Fecha del estado de la incidencia
Char
10
23 Latitud
Double
8 (precisin
decimal: 2)
24 Longitud
Double
8 (precisin
decimal: 2)
Puede ser PETICIN, ANULADO o

CERRADO
dd/mm/aaaa (fecha en que se cree o modifique
el estado de la incidencia campo 21 ).
Puede ser NULL, cuando el usuario teclee el
nombre de una va que no se pueda traducir a
un punto de la cartografa de Teleatlas
Puede ser NULL, cuando el usuario teclee el
nombre de una va que no se pueda traducir a
un punto de la cartografa de Teleatlas
Estos campos sern transmitidos nica y exclusivamente cuando se registre,

dentro del men desplegable Tipo de Incidencia, un %Accidente% (vase la Figura
4).
En la Figura 1 se presenta la ubicacin de los campos dentro de la interfaz del
programa. Vale comentar que son campos comunes a entornos urbanos e interurbanos.
En la Figura 2 se presenta la ubicacin de los campos de entorno urbano dentro de la
interfaz del programa. Por su parte, la Figura 3 presenta la ubicacin de los campos de
entorno interurbano dentro de la interfaz del programa.
Finalmente, la Figura 5 muestra la ubicacin del campo 4.Avera, de inters para
entornos urbanos e interurbanos.
NOTA: De no cerrarse antes, los expedientes se cerrarn automticamente a las 3 horas.
Requerimientos SATI
26 Octubre 2006
Pgina 4 de 10
19
21
16
22
3
9
10
11
15
12
14
13
18
17
20
Figura 1. Campos de inters en la interfaz del programa (entorno urbano e interurbano).
Requerimientos SATI
26 Octubre 2006
Pgina 5 de 10
6 (Urbano)
5 (Urbano)
7 (Urbano)
Figura 2. Campos de inters en la interfaz del programa (entorno urbano).
Requerimientos SATI
26 Octubre 2006
Pgina 6 de 10
5 (Interurbano)
7 (Interurbano)
8 (Interurbano)
Figura 3. Campos de inters en la interfaz del programa (entorno interurbano).
Requerimientos SATI
26 Octubre 2006
Pgina 7 de 10
Figura 4.Incidente Accidente, dentro del men desplegable Tipo de incidencia.
Requerimientos SATI
26 Octubre 2006
Pgina 8 de 10
Figura 5. Campo 4.Avera, de inters para entornos urbanos e interurbanos.
Requerimientos SATI
26 Octubre 2006
Pgina 9 de 10
C. Detalle
Todo registro nuevo debe ser transmitido.
Todo registro modificado debe ser transmitido.
La transmisin de cualquier registro, nuevo o modificado, debe realizarse

inmediatamente (online).
Dicha transmisin se podr realizar mediante un protocolo recomendado, pudiendo ser

de carcter seguro (ftp con password, etc.)
A su vez, sera altamente deseable que los registros fuesen transmitidos en formato
xml. Sin embargo, si esto no fuera posible, tambin valdra que fuesen transmitidos en
un fichero plano, separando los campos con pipelines (|).
Actualmente, el incidente like %Accidente% slo permite dos sub-categoras:

73. Accidente y 908. Accidente con extraccin (vase la Figura 5). Se requiere que
ofrezca tres: XXX. Accidente leve, YYY. Accidente grave y ZZZ. Accidente con
extraccin. Este punto queda pendiente de definicin por parte de Asistencia, con
respecto a si la diferenciacin entre Accidente Grave y Accidente Leve ser incluida en
el campo 4. Tipo de incidente o en el 5. Avera.
El campo 16. Entorno: Urbano (U) / Interurbano (I) ser empleado en el TIC para
filtrar los datos a cargar.
Requerimientos SATI
26 Octubre 2006
Pgina 10 de 10
PND: Personal Navigation Devices

Anlisis de los principales dispositivos en el mercado
Comparativa
Eleccin
ITS Systems RACC
Ricardo Amadoz
Noviembre 2006
NDICE
A. Principales dispositivos en el mercado...........................3
1.
2.
3.
4.
5.
6.
7.
Garmin Nvi 310.4

Garmin Nvi 360.5
Garmin Nvi 660.6
TomTom GO 5107
TomTom GO 710..10
TomTom GO 910..10
Mio C710............................................................................11
B. Comparativa..................................................................13
C. Precios..........................................................................18
D. Eleccin........................................................................19
E. Fuentes.........................................................................21
F. Glosario.........................................................................22
Ricardo Amadoz
Noviembre 2006
A. Principales dispositivos en el mercado

El nmero actual de fabricantes es amplio: TomTom, Navman, Kenwood, Mio,
Garmin, Fujitsu Siemens, Magullan, RoadMate, Airis, entre otros. Tras estudiar la
oferta de dispositivos por parte de cada uno, este informe se enfocar sobre tres
de los ms conocidos Garmin, TomTom y Mio , por ser estos los que presenten
un mayor abanico de dispositivos y puntos de venta en Espaa. Algunos de los
criterios solicitados para realizar la bsqueda fueron:
Receptor RDS-TMC: Incorporado o adicional?

Mapa de Espaa, y de preferencia, de toda Europa.
Bases de datos de cmaras de seguridad y POIs.
Personalizacin de POIs.
Memoria ROM.
Soporte de llamadas manos libres va Bluetooth.
Tamao y resolucin del display.
Cargadores: AC? Para el coche?
Autonoma de la batera.
Precio ~ 800 .
Ricardo Amadoz
Noviembre 2006
1. Garmin Nvi 310:
Algunas de sus caractersticas son:
Cartografa digital: NAVTEQ.

con WAAS [3].
Pantalla: Display QVGA TFT de 3.5, resolucin de 320 x 240 pixels, 64K
colores, luz de fondo blanca, pantalla tctil.
Dimensiones: 98.3 mm x 73.9 mm x 22.1 mm.
Peso: 144.6 grs.
Batera: Interna, Litio-Ion, con autonoma de 4-8 hrs (segn uso).
Incluye el Garmin Lock, un dispositivo antirrobo del fabricante.
Avisos de calles por voz.
Mapas precargados de una regin de Europa.
Permite elegir perspectivas 2D o 3D de los mapas.
Permite cargar POIs personalizados, incluyendo alertas de radares y cmaras
con el POI Loader.
El Kit de Viajes incorporado ofrece: Reproductor mp3, audio-libros, visor de
fotografas, conversor de unidades y monedas, calculadora, y dems.
Interfaz USB para cargar datos.
Memoria interna de aprox. 200 MB.
Compatible con el receptor de informacin de trfico FM TMC GTM 10 y GTM
12 (adicionales).
Ricardo Amadoz
Noviembre 2006
La compra incluye los siguientes:
Receptor Nvi 310.

Mapas precargados City Navigator NT Europe de una de las siguientes
regiones: Reino Unido-Irlanda, Pases Nrdicos, Blgica-Holanda-Luxemburgo,
Francia, Italia-Grecia, Espaa-Portugal, Alemania-Repblica Checa, AustriaSuiza-Italia, Europa Oriental.
Soporte para automvil con ventosa.
Cable adaptador 12/24 V (encendedor de cigarrillos del coche).
Disco para el salpicadero.
Cable interfaz USB.
Funda de transporte.
Manual de instrucciones.
Gua rpida de uso.
2. Garmin Nvi 360:
Presenta las mismas funcionalidades que el Nvi 310, ms las siguientes:
Mapas precargados de Europa y EE.UU.

Permite aadir software opcional, como las Guas de Viaje e Idiomas.
Memoria interna de aprox. 700MB.
Compatible con el receptor de informacin de trfico FM TMC GTM 10 y GTM
12 (adicionales).
Ricardo Amadoz
Noviembre 2006
Receptor Nvi 360.

Mapas precargados City Navigator NT North America o Europe (cobertura
completa).
Cargador AC.
Cable interfaz USB.
Gua rpida de uso.
3. Garmin Nvi 660:
Presenta las mismas funcionalidades que el Nvi 360, ms las siguientes:
Pantalla: Display WQVGA TFT de 4.3, resolucin de 480 x 272 pixels, 64K
colores, luz de fondo blanca, pantalla tctil.
Dimensiones: 124.9 mm x 73.9 mm x 22.9 mm.
Peso: 190 grs.
Batera: Interna, Litio-Ion, con autonoma de 3-7 hrs (segn uso).
Receptor de informacin de trfico FM TMC integrado.
Ricardo Amadoz
Noviembre 2006
Receptor Nvi 660.

Mapas precargados City Navigator NT North America o Europe (cobertura
completa).
Cargador AC.
Cable interfaz USB.
Receptor de informacin de trfico FM TMC.
Gua rpida de uso.
4. TomTom GO 510:
(*)
(*) El diseo exterior de la Familia TomTom GO es igual para cualquiera de sus versiones.

con WAAS..
Pantalla: Display LCD WQVGA de 4, resolucin de 480 x 272 pixels, 64K
colores, grficos 3D ultrantidos, luz de fondo blanca, pantalla tctil. Incorpora
un sensor de luz para adaptarse automticamente a la luz ambiental.
Ricardo Amadoz
Noviembre 2006

Peso: 300 grs.
CPU 400 MHz.
RAM 64 MB.
Batera: Interna, Litio-Ion, con autonoma de 4 hrs.
Avisos de calles por voz: Ms de 36 idiomas con ms de 50 voces diferentes.
Mapas precargados de una regin de Europa en una tarjeta SD.
Permite buscar contactos y enviarles mensajes mientras estn en la carretera.
Permite cargar POIs personalizados.
Permite recibir avisos al acercarse a cmaras de seguridad, fijas o mviles, e
informar a otros.
Receptor de informacin de trfico TomTom RDS/TMC Traffic Receiver
(adicional).
Alerta de aceleracin, para avisar al conductor de que est acelerando. No
requiere que el navegador est conectado.
Control de iPod.
Base domstica para descargar datos desde el PC, actualizar el GO y
organizar los archivos (canciones, fotos, mapas, etc.), al mismo tiempo que se
recarga el dispositivo.
La aplicacin TomTom HOME, conjuntamente con la base domstica, permite
organizar los archivos, bajar actualizaciones, planear y programar con
antelacin viajes en el PC, descargar pronsticos sobre la ubicacin de los
satlites GPS durante las 24 horas siguientes (con lo cual el GO puede
localizar ms rpidamente su ubicacin al encenderse) y dems.
Informacin en tiempo real sobre el trfico y las condiciones de las carreteras
durante 1 mes de prueba gratis, mediante el servicio TomTom PLUS Traffic.
Instrucciones visuales realistas: Las imgenes del GO reproducen las seales
de la carretera.
Volumen acorde con la velocidad: El micrfono interno percibe el ruido
existente en el coche y ajusta el volumen de las instrucciones acordemente.
Aparte de dicho altavoz, el GO se puede conectar al equipo del coche
mediante el cable de audio (incluido), o bien conectarlo al equipo, a auriculares
o a altavoces externos mediante Bluetooth.
Barra de estado personalizable.
Consejos en pantalla para aprovechar mejor las posibilidades del dispositivo.
Ricardo Amadoz
Noviembre 2006
Presentacin inicial: Permite personalizar cmo y dnde se abrir el GO

cuando lo encienda: ltima ubicacin, un pase de imgenes, men preferido.
Unidades configurables: Temperatura (C/F), presin atmosfrica (Pascal/
Mbar), y dems.
evitando autopistas de peaje y carreteras congestionadas, segn la hora de
llegada, etc.
Planificacin de itinerario, para programar las paradas a realizar antes de salir
de casa.
encuentre.
Definicin de destinos segn el formato que se desee: calle y nmero de casa,
cdigo postal (slo Reino Unido y Pases Bajos), contactos del usuario,
coordenadas GPS, centro ciudad o cruce.
Adicionalmente, el TomTom GO 510 permite ofrecer una amplia gama de

servicios TomTom PLUS descargables, tales como mapas (es posible descargar
las zonas que se necesiten: planos urbanos y mapas nacionales y regionales),
voces y dems.
Receptor TomTom GO 510.

Mapas precargados en una tarjeta SD de una de las siguientes regiones:
Blgica-Pases Bajos-Luxemburgo, Francia-Mnaco, Gran Bretaa, AlemaniaAustria-Suiza-Liechtenstein-Polonia-Repblica
Checa-Hungra-Eslovaquia,
Espaa-Portugal, Italia, Suecia-Dinamarca-Finlandia-Noruega.
Base domstica para conectar el dispositivo al PC (carga de archivos, etc.) y
para cargarlo. La base viene acompaada de un cable USB y un cargador
domstico con varios adaptadores internacionales
Micrfono externo (para optimiza la calidad de la voz al hacer llamadas manos
libres).
CD de instrucciones.
Gua rpida de uso.
Folleto de accesorios.
Tarjeta de cdigo del producto (para registrarlo en la web de TomTom).
Ricardo Amadoz
Noviembre 2006
5. TomTom GO 710:
Presenta las mismas funcionalidades que el GO 510; la nica diferencia radica
en la cartografa: Mapas precargados de toda Europa Occidental en una tarjeta SD
de 1 GB (incluida).
6. TomTom GO 910:
Presenta las mismas funcionalidades que el GO 710, ms las siguientes:
Peso: 340 grs.

Lectura de mensajes SMS en mviles compatibles.
Mapas precargados de toda Europa, EE.UU. y Canad en su disco duro.
Mando a distancia para manejar el dispositivo.
Reproductor mp3: Para escuchar msica y audiolibros. Las canciones se
pueden organizar con la aplicacin TomTom Jukebox.
Por otra parte, entre los servicios TomTom PLUS descargables que ofrece
el GO 910, adems de los mismos del GO 710, se tienen tambin: audio-libros.
Receptor TomTom GO 910.

Mando a distancia.
Mapas precargados de toda Europa, EE.UU. y Canad en un disco duro de 20
GB (12 GB libres).
Base domstica para conectar el dispositivo al PC (carga de archivos, etc.) y
para cargarlo. La base viene acompaada de un cable USB y un cargador
domstico con varios adaptadores internacionales
Micrfono externo (para optimiza la calidad de la voz al hacer llamadas manos
libres).
Cable de audio, para conectar el dispositivo al equipo de msica del coche.
Gua rpida de uso.
Folleto de accesorios.
Tarjeta de cdigo del producto (para registrarlo en la web de TomTom).
Ricardo Amadoz
10
Noviembre 2006
7. Mio C710:

con WAAS.
Pantalla: Display LCD QVGA de 3.5, resolucin de 320 x 240 pixels, 64K
colores, pantalla tctil.
Peso: 170 grs.
CPU 400 MHz.
RAM 64 MB.
Sistema Operativo Microsoft Windows CE .Net 4.2 Core versin [5].
Batera: Interna, Litio-Ion, con autonoma de 4.5 - 5.5 hrs (segn uso).
Avisos de calles por voz: 16 idiomas precargados.
Mapas precargados de toda Europa Occidental.
Permite buscar contactos Outlook y sincronizarlos con el PC.
Permite cargar POIs personalizados, as como encontrar lugares que ya se han
visitado (historial).
Permite recibir avisos (visuales y sonoros) al acercarse a cmaras de
seguridad, fijas o mviles.
Ricardo Amadoz
11
Noviembre 2006
Receptor de informacin de trfico incorporado (chip GNS-FM4) [5].

Cable Mini USB Active Sync para descargar datos desde el PC, actualizar el
dispositivo y organizar los archivos (canciones, fotos, mapas, etc).
Los lmites de velocidad a lo largo del camino son mostrados en todo
momento.
Reproductor mp3 incorporado.
Micrfono tambin incorporado.
Distintos perfiles de usuario: coche, motocicleta, peatn, etc.
Calculadora.
evitando autopistas de peaje y carreteras congestionadas.
encuentre.
Display informativo: Tiempo y distancias estimados hasta el destino, estado de
la batera y seal.
Receptor Mio C710.

Cable Mini USB Active Sync.
Adaptador AC Mini USB.
Cable mini USB adaptador 12/24 V (encendedor de cigarrillos del coche).
Mapas y software precargados de Europa Occidental en un DVD (MioMap v3
DVD).
Montura para bicicletas
Audfonos.
Antena TMC
Gua rpida de uso.
Informacin de servicios
Acuerdo de Licencia.
Hoja de garanta.
Ricardo Amadoz
12
Noviembre 2006
B. Comparativa
Las siguientes tres pginas ofrecen una tabla comparativa entre los 7 modelos
propuestos.
Tras analizarla, se deben tener presente adems los siguientes puntos sobre
algunos de los dispositivos:
1. Garmin Nvi 310:
Incorpora una tarjeta SD de 256 MB con mapas de una sola regin de Europa.
Para nuestro caso, la regin de inters sera Espaa-Portugal, aunque, tal como
se indica al principio de este informe, sera altamente deseable adquirir un
dispositivo con los mapas de toda Europa. Estos se pueden adquirir en una tarjeta
SD con el City Navigator NT Europe, cuyo coste es de 349.99$ [1].
Otro inconveniente es que la compra no incluye cargador AC, el cual ser
necesario cuando el PND se use fuera del coche (ej., Sala de Infotrnsit). Comprar
el cargador aparte cuesta 25$ [1]. Adicionalmente, requiere comprar un receptor
de informacin de trfico, pues no viene incorporado.
Es compatible con el Garmin FM TMC GTM 12 o con el Garmin FM TMC GTM
10. El primero incorpora el receptor y la antena, y tiene un coste de 160.70$ [1]. El
segundo es slo un receptor FM que va situado entre el reproductor del coche y su
antena, por lo que requiere instalacin profesional. Su precio es de 214.27$ [1].
2. Garmin Nvi 360:

Al igual que el modelo previo, requiere la compra de los receptores Garmin FM
TMC GTM 12 Garmin o FM TMC GTM 12.
Observacin general sobre los PNDs Garmin: Aparte de los puntos

anteriores, es necesario destacar que los dispositivos slo ofrecen una interfaz e
instrucciones en ingls. Adems, segn opiniones de otros usuarios, la
navegacin carece de fluidez (el recorrido se visualiza por frames), y el hecho de
que el NAVTEQ sea el proveedor de los mapas digitales podra acarrear algunas
inexactitudes1.
Segn distintos reviews, la cartografa de NAVTEQ es recomendable para EE.UU., mientras que
la de TeleAtlas lo es para Europa.
13
Ricardo Amadoz
Noviembre 2006
3. TomTom GO 510:
Incorpora una tarjeta SD con mapas de una sola regin de Europa. El mapa de
Europa completa se puede adquirir en una tarjeta SD adicional, con un costo de
150 [2].
Observacin general sobre los PNDs TomTom: Para recibir informacin de

trfico, es necesario comprar tambin el receptor TomTom RDS/TMC Traffic
Receiver, cuyo costo es de 99.95 [2]. Tambin deben contar con la aplicacin de
software ms reciente (6.1) de TomTom (esto no debe de ser problema con el GO
910, que es el ltimo de los tres TomTom estudiados; para los GO 710 y 510 en
caso de que no la incorporasen bastara con conectarlos al PC y utilizar
TomTom Home para actualizar la aplicacin gratuitamente en la web de TomTom).
4. Mio C710:
Vale la pena comentar que Mio ofrece actualizaciones gratis durante un ao, a
partir del momento de compra, de la base de datos de las cmaras de seguridad
[4]; lo cual en realidad tampoco representa un gran valor aadido, siendo esta
informacin de carcter esttico.
Ricardo Amadoz
14
Noviembre 2006
Ricardo Amadoz
15
Noviembre 2006
Ricardo Amadoz
16
Noviembre 2006
Ricardo Amadoz
17
Noviembre 2006
C. Precios2
Naturalmente, cada proveedor ofrece precios distintos, por lo que la
informacin presentada a continuacin debe considerarse como un referente, y
sujeta a cambios.
1. Garmin Nvi 310:
Activa GPS (tienda online): 414.95 .

FISAC Aviation, S. A. (Madrid): 507.58 .
Electrnica Trepat (Barcelona): 449 .
Aviasport, S. A. (Madrid): 474 .
2. Garmin Nvi 360:
Garmin (web oficial): 857.13 $.

FISAC Aviation, S. A. (Madrid): 657.58 .
Aviasport, S. A. (Madrid): 646 .
3. Garmin Nvi 660:
Garmin (web oficial): 1076.91 $.

Activa GPS (tienda online): 589 .
4. TomTom GO 510:
TomTom (web oficial): 449 .

El Corte Ingls: 449 .
Fnac: 449 .
5. TomTom GO 710:

Fnac: 499 .
6. TomTom GO 910:
Fuentes: [1], [2], [6], [7], [8], [9], [10], [11], [12], [13], [14].
18
Ricardo Amadoz
Noviembre 2006

Fnac: 599 .
7. Mio C710:

Media Markt (Valencia): 499 .
Zona GPS (tienda online): 449 .
Redcoon (tienda online): 439 .
D. Eleccin
Una vez estudiado lo presentado hasta el momento, es factible tomar una
decisin. Teniendo presente los criterios de seleccin especificados por el RACC
con respecto a la cartografa digital (de preferencia, cobertura europea), los
modelos Garmin Nvi 310 y TomTom GO 510 son inmediatamente descartados.
El excesivo coste que supondra comprar las tarjetas SD con estos mapas no
justifica su compra. Adicionalmente, el primero no incluye cargador AC (otro gasto
extra).
Por su parte, el modelo Garmin Nvi 360 requiere la compra de un receptor de
informacin de trfico (cualquiera de los modelos recomendados), lo cual
encarece su precio, por lo que tambin es descartado. El ltimo de los Garmin
estudiados, el Nvi 660, no presenta per se desventajas a priori, ms que las
propias de la marca (interfaz en ingls y malos reviews por parte de otros
usuarios), por lo que tambin se descarta.
Con respecto a los TomTom GO 710 y 910, el hecho de no soportar
informacin RDS/TMC directamente requieren la compra de receptores
adicionales representa una desventaja, al aumentar el precio de compra; sin
mencionar la posibilidad de que no sea tan fcil comprarlos (an cuando TomTom
es uno de los fabricantes ms importantes en el mercado, hay que tener presente
que un receptor de informacin de trfico RDS/TMC es un accesorio muy
especfico, con muy poca demanda por parte del pblico general, por lo que es
posible que los distribuidores y vendedores de productos de la marca no
dispongan de l, o al menos no en stock).
Por tanto, la decisin final de este informe es el dispositivo Mio C710, por
cuanto cumple en mayor o menor forma todos los requisitos especificados: soporta
directamente informacin RDS/TMC (no requiere la compra de extras), incorpora
la cartografa de toda Europa, viene con bases de datos de cmaras de seguridad
y POIs preinstaladas, ofrece actualizaciones gratis de las bases de datos de
cmaras de seguridad (lo cual, como se dijera en lneas anteriores, no es en s
Ricardo Amadoz
19
Noviembre 2006
mismo un gran aporte, pero es interesante tenerlo presente), permite cargar POIs
propios, hacer llamadas manos libres (incorpora Bluetooth), trae cargadores AC y
para el coche, y su batera, memoria ROM y tamao del display estn a la par de
otros modelos.
Con respecto a los dos ltimos puntos, es conveniente destacar que el
TomTom GO 910 le aventaja, pero en general y dado que estos tampoco son
aspectos tcnicamente importantes para los intereses del RACC , el Mio C710
cumple mejor con los criterios de seleccin. En cuanto al resto de los aspectos,
ambos modelos son bastantes similares en su mayora, tal y como lo refleja la
tabla comparativa: mismo receptor GPS, procesadores con la misma velocidad
(400 MHz), etc. En algunos criterios, el GO 910 es superior, pero, nuevamente,
estos no son fundamentales de cara al RACC.
Un ltimo punto, tan o ms importante que los anteriores, es el precio: la oferta
ms cara del Mio es un 23% menor que la ms econmica del TomTom
(considerando tambin la compra del respectivo receptor de informacin de trfico
RDS/TMC).
En vista de todo lo anterior, la decisin final de compra es, en orden de
prioridad:
1. Mio C710
2. TomTom GO 910 + TomTom RDS/TMC Traffic Receiver.
Ricardo Amadoz
20
Noviembre 2006
E. Fuentes
[1] Garmin. Web oficial: http://www.garmin.com/
[2] TomTom. Web oficial: http://www.tomtom.com/
[3] Datasheet del SiRF STAR III GSC3e/LP & GSC3f/LP:
http://www.sirf.com/products/GSC3LPProductInsert.pdf
[4] Mio. Web oficial: http://www.mio-tech.be/
[5] Hoja de especificaciones del Mio C710:
http://www.mio-tech.be/products/images/Detailed_Specs/C710.pdf
[6] ActivaGPS. Direccin web: http://www.activagps.com/#
[7] FISAC Aviation, S. A. (Madrid). Direccin web:
http://www.garmin.com.es/index.htm
[8] Electrnica Trepat (Barcelona). Direccin web: http://www.trepat.com/
[9] Aviasport, S. A. (Madrid). Direccin web: http://www.aviasport.com/
[10] El Corte Ingls (Espaa). Direccin web: http://www.elcorteingles.es
[11] Fnac (Espaa). Direccin web:
http://www.fnac.es/dsp/?servlet=home.HomeServlet
[12] Media Markt (Espaa). Direccin web: http://www.mediamarkt.es/
[13] Zona GPS (tienda online). Direccin web:
http://www.zonagps.com/index.php?option=com_frontpage&Itemid=1
[14] Redcoon (tienda online). Direccin web: http://www.redcoon.es/
Ricardo Amadoz
21
Noviembre 2006
F. Glosario
Audio-libros
Bluetooth
CPU
DVD
GPS
iPod
LCD
MP3
Pixels
PND
Grabaciones de los contenidos de un libro ledas en voz alta,

distribuidas en el contexto de este informe en formato mp3 o
wma.
Estndar de radio y protocolo de comunicaciones diseado para
el intercambio de informacin entre dispositivos (mviles, PNDs,
porttiles, etc.) de manera inalmbrica.
Central Processing Unit: Unidad de un PC encargada de
interpretar instrucciones y procesar datos contenidos en
programas.
Digital Versatile Disc: Formato multimedia de almacenamiento
ptico empleado para guardar en el contexto de este informe
mapas digitales y software.
Global Positioning System: Sistema global de navegacin por
satlite que permite determinar la posicin de un vehculo,
persona, objeto, etc. en cualquier punto de la Tierra.
Reproductor de msica digital con disco duro, o memoria flash,
segn versiones, desarrollado por Apple Computer.
Liquid Crystal Display: Sistema elctrico de presentacin de
datos.
MPEG-1 Audio Layer 3: Formato de audio digital comprimido y
con prdidas.
La menor unidad en la que se descompone una imagen digital.
Personal Navigation Device : Dispositivo electrnico porttil que

combina capacidades de posicionamiento (tales como GPS) y
funciones de navegacin.
POI
Point Of Interest: Puntos de inters para el conductor, tales
como estaciones de gasolina, restaurantes, parkings, etc.
QVGA
Quarter Video Graphics Array: Trmino empleado para referirse
a pantallas de dispositivos con una resolucin de
320 x 240 pxeles.
RAM
Random Access Memory: Memoria de semiconductor, de
carcter voltil, en la que se puede leer y escribir informacin,
utilizada comnmente para almacenar datos intermedios.
RDS
Radio Data System: Estndar europeo para el envo de
pequeas cantidades de informacin digital mediante las
transmisiones de radio FM convencionales.
ROM
Read Only Memory: Memoria de semiconductor, de carcter no
voltil, en la que slo se puede leer informacin, utilizada
comnmente para almacenar la configuracin del sistema o el
programa de arranque del dispositivo.
SD
Secure Digital: Formato de tarjeta de memoria flash.
SMS
Short Message Service: Servicio de telefona mvil que permite
el envo de mensajes cortos entre telfonos mviles, telfonos
fijos y otros dispositivos
22 porttiles.
Ricardo Amadoz
Noviembre 2006
TFT
TMC
USB
WAAS
WQVGA
Ricardo Amadoz
Thin Film Technology: Tipo especial de transistor cuya

aplicacin ms conocida son las pantallas de visualizacin
planas de LCD.
Traffic Message Channel: Tecnologa para enviar informacin
de trfico y viajes a conductores. Tpicamente, se codifica
digitalmente empleando el sistema FM-RDS. Permite que la
informacin se enve de manera silenciosa, en tiempo real, y
en el idioma del conductor. Su integracin dentro de PNDs
permite a estos informar a su vez sobre incidencias en las
vas (trfico, accidentes, etc.) y proponer rutas alternativas
para evitarlas.
Universal Serial Bus: Interfaz que provee un estndar de bus
serie para conectar dispositivos a un ordenador.
Wide Area Augmentation System: Sistema de navegacin
extremadamente preciso (se afirma que la precisin est en
un radio de 3 metros de la posicin real el 95% de las veces)
desarrollado para la aviacin civil. La cobertura de la seal se
limita a Norte Amrica.
Wide Quarter Video Graphics Array.
23
Noviembre 2006
Special Session: Establishing Traffic Information

Services in New Markets.
Jack Opiola, Booz Allen Hamilton (UK)
Brian Smith, Intelematics (Australia)
James Burgess, ERTICO-ITS Europe
Apuntes de la Presentacin
ITS Systems RACC
13th ITS World Congress and Exhibition

Londres, 10 Oct 2006
Ricardo Amadoz
23 Octubre 2006
Pgina 1 de 5
Organiser
ITS Australia
Description of the session
For those countries that do not yet have nationwide traffic and traveller information services, the task of
implementing a solution can be complex. VICS, VMS, RDS, SMS, GPRS? This special session will present
three leading case studies on the lessons learned and a road map for the future, to accelerate the introduction
of and potentially fund consumer centric nationwide traveller information services.
Moderator
Mr. Brent Stafford, Executive Director, ITS Australia, Australia
Speakers
Mr. Jack Opiola, Principal Consultant, Booz Allen Hamilton, UK
Mr. Brian Smith, General Manager, Traffic and Content, Intelematics Australia, Australia
Mr. James Burgess, TMC Forum Coordinator, ERTICO-ITS Europe
Speaker 1: Jack Opiola, Booz Allen Hamilton

VII (Vehicle Infrastructure Integration): Es la versin americana de CVIS.

Se basa en el IEEE 802.11p, estndar de la familia IEEE802.11 que se
caracteriza por su baja latencia (5 msecs), lo cual lo hace idneo para su uso
en aplicaciones de ITS, al permitir establecer enlaces rpidamente
(comunicacin instantnea).
Algunas caractersticas del IEEE 802.11p:

Rango de cobertura: 1 Km.

BW: 75 MHz (5.850 - 5.925 MHz).

7 canales.

Data rates: 3, 4, 5, 6, 9, 12, 18, 24, 27 Mbps.
Permite establecer redes Ad-Hoc con otros vehculos y con la infraestructura.
Opiola prevee que para el ao 2030 se llegar al 70, 80, 90% de la poblacin
de vehculos.
En VII se introducen unos dispositivos llamados MOTES: Pequeos
procesadores (del tamao de 2 bateras AA) que pueden ser usados en los
coches. Por ejemplo, pueden ser ubicados en los neumticos con el fin de
medir la presin de los mismos y comunicarla al ordenador central del vehculo,
u otro externo (ej., una estacin de gasolina).
VII tambin se presenta como una oportunidad de negocios para servicios
privados (ej., al pasar en el coche frente a un Starbucks se le podra avisar al
conductor de alguna oferta en cafs).
Ricardo Amadoz
23 Octubre 2006
Pgina 2 de 5
Speaker 2: Brian Smith, Intelematics

An Urban Traffic Service

Caso australiano: - Alta densidad en las ciudades.

- Trfico interurbano no es significativo.
En Melbourne se presentan congestiones en un rea grande de la ciudad (y no
solamente en el downtown, como ocurre en otras ciudades).
Buscan implementar TMC comercial.
Tienen sensores en muchos sitios 2800 intersecciones = 2800 sensores
(SCATS1) , y no slo en las intersecciones de calles, sino tambin en cruces
de peatones y otros puntos (por ejemplo, en la mitad de algunas calles).
Cmo lo hacen? Extrayendo el patrn de trfico de cada interseccin2:
Y posteriormente con los inductive loops cuentan el nmero de coches, y

segn el patrn de trfico y los delays entre una interseccin y otra, estiman la
velocidad promedio.
Su producto se llama SunaTraffic. He aqu su descripcin: Es un servicio
automovilstico costeable que ayuda a los conductores a evitar congestiones
de trfico inesperadas, permite al sector de cargas y logstica realizar
planificaciones ms eficientes, y lleva la informacin de trfico a pginas web y
servicios de telefona celular.
Es el primer servicio australiano de trfico basado en TMC. Se transmite

usando RDS. Por otra parte, Intelematics ha establecido un convenio con ITIS
(UK), para la codificacin y transmisin del servicio SunaTraffic.
Informacin sobre Intelematics: Provee servicios para seguridad personal y del

vehculo, administracin de flotas y mano de obra, informacin de trfico en
Sydney Coordinated Adaptive Traffic System: Sistema que emplea cmaras y/o inductive loops
para contar el nmero de vehculos en cada interseccin, y adapta la temporizacin a travs de un
ordenador central.
2
La tecnologa para modelar el flujo del trfico fue desarrollada por la compaa australiana
Custom Traffic Pty Ltd.
Ricardo Amadoz
23 Octubre 2006
Pgina 3 de 5
tiempo real y navegacin, y dems informaciones en tiempo real para

conductores. Tambin est trabajando con sus clientes para ofrecer mejores
diagnsticos remotos de vehculos y servicios eCRM (esto es, la aplicacin de
TI para Customer Relationship Management).
Adems, Intelematics es uno de los miembros fundadores de Global
Response una alianza que une las iniciativas telemticas de clubes
automviles lderes en Europa (el ADAC pertenece a esta red), Norte Amrica
y Australia , teniendo as acceso a tecnologa compartida y conocimiento de
las tendencias de consumidores, automovilismo y movilidad. Hoy en da es en
su totalidad una compaa subsidiaria del RACV (Royal Automobile Club of
Victoria).
Contacto: www.intelematics.com.au
agame@intelematics.com.au
Adam Game, CEO
Brian Smith
bsmith@intelematics.com.au
Speaker 3: James Burgess, ERTICO ITS Europe

Bringing TMC to new markets
En su definicin ms estricta, TMC consiste en usar la codificacin Alert-C
para enviar y recibir mensajes de difusin del trfico. Sin embargo, en la
prctica se entiende por TMC a todo el servicio.
ERTICO concluy en enero del presente ao un proyecto piloto de 18 meses
en Beijing, el proyecto Dinasty, empleando ms de 2400 vehculos (taxis) para
obtener FVD, con el fin de demostrar la factibilidad de implementar una cadena
de servicio TMC cuyos mensajes se formasen a partir de dicha informacin
(FVD).
Requisitos para la transmisin va radio:

Transmisor FM (estacin de radio) con buena cobertura (Torre CCTV),
obviamente...

Codificadores RDS...

Buena comunicacin (rpida, banda ancha) entre la entidad Analista
de Datos y el Transmisor...

...

...
Contacto: James Burgess, TMC Forum Coordinator

tmcforum@mail.ertico.com
Ricardo Amadoz
23 Octubre 2006
Pgina 4 de 5
Clausura: Q & A Session

Q: Qu perspectivas se le ven a TMC en el transporte pblico?
A: TMC no est enfocado principalmente para el transporte pblico, pero podra
tener la misma funcionalidad: evitar congestiones, notificar accidentes, etc. De
cara al futuro, TPEG se presenta como una alternativa ms efectiva y
completa, ya que ofrece mucho ms que informacin de trfico; es en realidad
travelling information
Utilidad para el servicio pblico.
Q: TMC no abre la puerta a que, si toda la gente recibe la misma
informacin y las mismas recomendaciones de desvo, se traslade la
congestin a otro sitio?
A: En primer lugar, TMC no da recomendaciones de desvo per se, slo informa
eventos. Las recomendaciones de desvo las proporciona el navegador (debe
haber cooperacin entre ambos). Adems, dado que la informacin es
obtenida y procesada en tiempo real, el estado del trfico va cambiando y por
ende la congestin no es trasladada. Esto es lo que se conoce como dynamic
equalization.
Q: Qu potencial tiene TMC en TPEG?
A: Mucho. Por ejemplo, al tener un mayor ancho de banda, permite ofrecer ms
informacin. Adems, para pases con poca cobertura RDS, podra ser ms
conveniente penetrar directamente con TPEG.
Ricardo Amadoz
23 Octubre 2006
Pgina 5 de 5
Sntesis de la Reunin ITIS Holdings plc

Fundacin RACC
Q&A
ITS Systems RACC
13th ITS World Congress and Exhibition

Londres, 10 Oct 2006
Ricardo Amadoz
23 Octubre 2006
Pgina 1 de 4
Lugar: Stand ITIS Holdings plc (E18), ExCeL Centre.

Participantes: Simon Prato-Scarlett, ITIS Holdings plc.
Ricardo Amadoz, Fundacin RACC.
Q: Qu informacin extrapolan?
A: Tanto FVD (basada en GPS) como CFVD (basada en los registros de los
handovers entre celdas). La fiabilidad de la CFVD se basa en el gran volumen de
informacin del espacio muestral. Por su parte, a pesar de que el volumen de
informacin de la FVD es mucho menor, el hecho de que sea recabada por flotas
especializadas (taxis, autobuses, camiones, etc) es garante de su fiabilidad.
Q: Cunto costara implementarlo? Cunto tardara?
A: La implantacin como tal es una de las alternativas ms econmicas (en
comparacin con otras existentes). Se recomienda empezar con CFVD, y
posteriormente, si vale la pena, implementar FVD (el coste aumenta, debido a la
necesidad de comprar e instalar equipos GPS). La parte ms larga de todo el
proceso es making friends: Llegar a un acuerdo con un operador de telefona
mvil.
Se recomienda que sea el mayor operador del mercado, dado que el
volumen de data ser mayor (ms usuarios), aumentando as la fiabilidad. Por su
parte, tpicamente los operadores se muestran recelosos de proveer a ITIS de
los registros solicitados, por cuanto su imagen podra verse afectada (los usuarios
podran pensar que se les est rastreando, que esto podra suponer una violacin
a su privacidad, podra generarse un debate pblico, etc), a pesar de que ITIS
garantiza plenamente la confidencialidad de esta informacin. De hecho, ellos no
estn interesados ni solicitan en el perfil o datos de las personas; slo
necesitan el registro de los handovers (informacin masiva, genrica, annima).
Desde el punto de vista tcnico, el proceso es bastante rpido y simple:
Una vez hechos los amigos, la implementacin tcnica para un proyecto piloto
tomara unos 6 meses. Si posteriormente se quisiera obtener adems FVD, habra
que tener presente el tiempo que toma instalar los equipos GPS (ellos no hacen
esto, su trabajo es directamente procesar la informacin).
Q: Los mviles han de estar encendidos o apagados?
A: Al estar encendidos, el signalling de los mviles con las estaciones base ocurre
con una frecuencia muy alta, obteniendo as muchos datos, lo cual aumenta la
fiabilidad. Al estar apagados, en cambio, esto ocurre con una frecuencia menor,
pero igualmente vlida.
Ricardo Amadoz
23 Octubre 2006
Pgina 2 de 4
Q: Cuntos mviles se requieren para obtener informacin de calidad?

A: Una vez establecido el convenio con el operador mvil, lo mejor es procesar
toda la informacin (todos los registros). Una de las caractersticas del trfico es
su aleatoriedad, por lo que indicar un porcentaje de mviles requeridos (basados,
por ejemplo, en cada va en particular) es delicado.
Q: Qu compaas tienen su producto?
A: Fabricantes de vehculos de gama media y alta (BMW, Mercedes Benz,
Porsche, Jaguar, Lexus, Renault, Nissan, Ford, entre otros), de sistemas para
vehculos (Pioneer, Panasonic, Kenwood, Alpine, Bose), dispositivos inalmbricos
(Vodafone, Orange, O2, T-Mobile, Virgin Mobile, AA Navigator, ViaMichelin,
TomTom, etc) y autoridades gubernamentales (Department for Transport,
Transport For London, Federal Highway Administration (US), Scottish Executive,
etc).
Q: Slo el suyo? O utilizan tambin otras fuentes?
A: Es decisin de cada cliente. Por ejemplo, las autoridades gubernamentales
deben de usar con toda certeza otras fuentes (propias) adems de ellos. Por otra
parte, el AA (Automobile Association, el club automvil ms grande del Reino
Unido) tiene un servicio llamado SMS Traffic Alerts, basado nicamente en su
producto1.
Q: En qu formato viene la informacin?
A: Pueden transmitirla directamente va RDS, o enviarla en formato xml, pudiendo
luego presentarse de maneras diversas: Representaciones visuales (mapas
dinmicos con el estado de la congestin), Listas (tablas con informacin diversa,
por ejemplo, nmero de vehculos / hora / segmento de va, etc.), Matrices OrigenDestino (donde se observa informacin velocidades medias, retrasos esperados,
etc. de cada tramo entre dos puntos A y B).
Observaciones: Por lo visto siempre estn presentes en la cadena de servicio...

Contacto: Philip Taillieu, Business Development Director Central Europe
ptaillieu@itisholdings.com
Simon Prato-Scarlett, Research & Special Projects Manager
sprato-scarlett@itisholdings.com
Vase http://www.aatrafficalerts.co.uk/
Ricardo Amadoz
23 Octubre 2006
Pgina 3 de 4
www.itisholdings.com (Web corporativa)

www.itisholdings.com/itswc2006
Ricardo Amadoz
(Ilustrativa,
Congreso)
23 Octubre 2006
preparada
para
Pgina 4 de 4
el

La Flora Intestinal

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

La Flora Intestinal

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD SIMN BOLVAR

Decanato de Estudios Profesionales

Anlisis y Mejora del Canal de Informacin de Trfico del

Sartenejas, Febrero de 2007

UNIVERSIDAD SIMN BOLVAR

Anlisis y Mejora del Canal de Informacin de Trfico del

Realizado con la Asesora de

Sartenejas, Febrero de 2007

UNIVERSIDAD SIMN BOLVAR

Anlisis y Mejora del Canal de Informacin de Trfico del

REALIZADO CON LA ASESORIA DE Mnica Karel Huerta

Aprobado con mencin:_______

Hora y Fecha (CT) ..................................................................................... 40

4. ARQUITECTURA ACTUAL DEL CANAL DE INFORMACIN DE TRFICO

5. ANLISIS Y VALIDACIN DEL FUNCIONAMIENTO DEL SISTEMA .......... 85

6. MEJORAS IDENTIFICADAS ........................................................................ 111

7. CONCLUSIONES ......................................................................................... 136

NDICE DE TABLAS Y FIGURAS

Figura 1. Cobertura del TMC en Europa......6

Figura 31. Definicin inicial del filtro geogrfico para Catalua..69

Alternative Frequency Indicator

Advice and Problem Location for European Road Traffic, Version C

Central Processing Unit

Cyclic Redundancy Code/Check

Digital Audio Broadcasting

Data Carrier Detect

Direccin General de Trfico

Data Set Number

Data Set Ready

Data Terminating Equipment

Data Terminal Ready

Digital Video Broadcasting

European Broadcasting Union (Unin de Radiodifusores Europeos)

Conferencia Europea de Ministros de Transportes

Enhanced Other Network

Floating Car Data

File Transfer Protocol

Empresa alemana fabricante del sistema TIC

Global Positioning System

Hypertext Transfer Protocol

Instituto Geogrfico Nacional

Intelligent Transport Systems

Low Cost Profile

Least Significant Bit(s)

Location Table Number

Message Element Code

Message Element Data

Message Element data Length

Message Field Lenght

Message Geographical Scope

Modified Julian Date

Most Significant Bit(s)

Open Data Applications

Post Office Protocol version 3

Programme Service Number

Program Type Name

Real Automvil Club de Catalua

Random Access Memory

Radio Data System

Radio Nacional de Espaa

RNE-CLAS Red de emisoras Clsica de Radio Nacional de Espaa

Read Only Memory

Servicio de Asistencia en carretera del RACC