ES2270436T3 - Terminal telematico para aplicaciones viarias. - Google Patents

Abstract

SE DESVELA UN SISTEMA TELEMATICO DE TRAFICO QUE SE CARACTERIZA POR CONTENER UNO O MAS SUBSISTEMAS, CONCRETAMENTE AL MENOS UN SUBSISTEMA DE COMUNICACION Y/O AL MENOS UN SUBSISTEMA DE NAVEGACION.

Description

Terminal telemático para aplicaciones viarias.

La telemática está llamada a ser un mercado de crecimiento dentro de la comunicación móvil; las previsiones para la próxima década anuncian más de diez millones de clientes. Los fabricantes podrán ofrecer terminales a un precio razonable siempre y cuando existan medios rentables para el desarrollo y la producción. Así pues, la producción en masa crea una base para una fuerte penetración de mercado. El éxito mundial de la comunicación móvil, como el estándar GSM, ha demostrado que es posible penetrar el mercado rápidamente y alcanzar a un gran número de participantes coordinando comisiones de especificaciones. Con el presente documento conjunto, que trata sobre las especificaciones de los terminales, se ha conseguido crear el marco adecuado para preparar técnicamente el mercado de la telemática viaria con todos sus participantes (clientes, proveedores de servicios y fabricantes de
equipos).

Una característica esencial de la especificación es la arquitectura abierta del sistema ya que sólo puede desarrollarse un mercado masivo para una multiplicidad de servicios telemáticos viarios en los sectores de empresas y particulares si se crean especificaciones de interfaz estandarizadas y abiertas.

La movilidad de los usuarios del tráfico cobra cada vez mayor importancia como factor económico. Por ello, es necesario contar con sistemas de orientación viaria flexibles e inteligentes para mantener un flujo de tráfico fluido a medida que aumenta continuamente el número de vehículos en circulación. El objetivo es introducir lo antes posible un sistema telemático viario que sea flexible y abierto para la incorporación de futuros adelantes técnicos. Este sistema debería poseer interfaces estandarizadas que permitiesen ejecutar una serie de operaciones de gestión del tráfico tanto en el sector empresarial como para particulares. Así, podría ser capaz de proporcionar orientación viaria y servicios de información colectivos, por un lado, y servicios personales por otro.

El concepto está basado en la comunicación móvil, por ejemplo, el estándar de comunicación móvil celular y digital GSM y en sistemas de navegación, por ejemplo, el sistema de navegación por satélite GPS, siendo este último el representante por antonomasia del Sistema Global de Navegación por Satélite (el Global Navigation Satellite System o GNSS). Evidentemente, la aplicación del concepto no se limita a estos sistemas de comunicación y navegación en concreto, ya que puede utilizarse cualquier otro tipo de comunicación electromagnética, incluso microondas o infrarrojos. Asimismo, cualquier tipo de navegación encaja dentro del concepto de estándar abierto como, por ejemplo, la navegación autónoma de a bordo mediante sensores u otra clase de sistemas de navegación externos o internos/externos combinados, como la determinación de la posición por medio de difusión electromagnética. En el texto que sigue GSM y GPS se utilizarán únicamente como ejemplos de los distintos tipos de comunicación, en especial, la radio móvil, y medios de navegación, en especial, la navegación por satélite, posibles en este concepto.

El estándar GSM ya se utiliza de forma universal para servicios de voz y datos en Europa y otros lugares. GPS es un procedimiento estandarizado disponible en todo el mundo. La alta cobertura de las redes de GSM significa que ya se han realizado las principales inversiones en infraestructuras, por lo que se garantiza la rápida introducción de la telemática viaria basada en GSM. Cabe hacer hincapié en el hecho de que los terminales de telemática viaria instalados en los vehículos pueden utilizarse de forma transfronteriza. El diseño multifuncional de estos terminales sienta las bases para una amplia variedad de ofertas y servicios adicionales para clientes potenciales.

En el documento de la Pacific Rim TransTech Conference, 1995, Vehicle Navigation and Information Systems Conference proceedings. 6th Internacional VNIS, 30 de julio de 1995 - 2 de agosto de 1995, ISBN 0-7803-2587-7, 1995, Nueva York, NY, Estados Unidos, páginas 442-449; Hong Lo y otros: "A Structured Approach for ITS Architecture Representation and Evaluation" se informa de un sistema telemático viario que comprende un sistema de base con varios subsistemas intercambiables, especialmente un subsistema de comunicaciones, un subsistema de ubicación y un subsistema de entrada/salida que suministran las funciones básicas.

El documento Proceedings of the Vehicular Technology Conference, Estocolmo, 8-10 de junio de 1994, vol. 1, 8 de junio de 1994, Institute of Electrical and Electronics Engineers, páginas 405-409, Wichtel E. y otros: "AVL Subsystem Interfaces" abre el camino hacia un sistema telemático viario e informa sobre una interfaz estándar para la aplicación y de una unidad central que ejecuta las funciones de control del sistema y de enrutamiento.

El documento PHILIPS JOURNAL OF RESEARCH, Vol. 48, n.º 4, enero de 1994, páginas 299-313, XP495036, BIESTERBOS J. W. M. y otros: "SOCRATES: A DYNAMIC CAR NAVIGATION, DRIVER INFORMATION AND FLEET MANAGEMENT SYSTEM" describe un terminal de un sistema telemático viario.

Por todo ello, es objeto del presente invento proporcionar un terminal telemático viario con un concepto fácilmente modificable. De acuerdo con uno de los aspectos del presente invento, se proporciona un terminal telemático viario según la reivindicación 1. De acuerdo con otro aspecto, se proporciona un método para operar un terminal telemático viario según la reivindicación 7. El terminal telemático viario incluye uno o varios subsistemas. Cada subsistema puede estar diseñado para cumplir determinadas tareas especiales dentro del sistema en su conjunto como pueden ser la comunicación, la ubicación, el control de acceso o la entrada/salida. Una posibilidad de disponer los subsistemas consiste en construir un sistema de base al que se asignan uno o varios subsistemas. El sistema completo puede controlarse asignando al sistema de base las funciones básicas y aquellas que sirven para ejecutar y/o controlar uno o varios subsistemas. Se propone diseñar interfaces estandarizadas para el sistema telemático para así facilitar la comunicación y/o la conexión. Un ejemplo especial de una realización de dicho sistema de base, de los subsistemas y de las interfaces se muestra con más detalle en el texto que sigue.

Objeto de la especificación

Como se muestra en la figura 1, esta especificación se centra especialmente en la descripción funcional de la plataforma terminal como enlace de conexión entre las aplicaciones y la producción del terminal. Con este concepto será posible transferir aplicaciones a distintos terminales, lo cual supone la base para que exista disponibilidad de terminales en un mercado de masa. Además, los distintos fabricantes podrán implementar los servicios ya existentes en los terminales, posibilitando así la creación de diseños individualizados.

El terminal telemático viario es un sistema completo que puede integrarse en el vehículo. El terminal de base que especifica este documento se corresponde con el terminal desprovisto de las partes que pertenecen a las aplicaciones. La plataforma del terminal incluye subsistemas que son necesarios para muchas aplicaciones telemáticas viarias, así como para el sistema de control y de enrutamiento y la gestión de prioridades. Con respecto a la arquitectura del terminal de base introducido en el capítulo 1.2, esta especificación establece las funciones básicas para controlar y utilizar los subsistemas de comunicación, ubicación, lector de tarjetas y entrada/salida.

Estas funciones básicas permiten un acceso definido a los subsistemas mientras varias aplicaciones se están ejecutando al mismo tiempo sin que ninguna de ellas bloquee a otra. Las aplicaciones externas adicionales también pueden utilizar estos subsistemas a través de una interfaz estandarizada, la interfaz estándar de comunicaciones (Standard Communications Interface o SCI), y evitar una duplicación del módulo GSM o GPS.

El objetivo consiste en crear un estándar para secuencias de aplicaciones utilizando y recurriendo a las funciones básicas. Las posibles aplicaciones de la telemática viaria se describen en [4], [5], [6] y [9].

Además, la especificación de las funciones básicas no tiene que definir el hardware de la terminal de base multifuncional. No se establecen ni la CPU ni el sistema operativo ni la estructura de buses, por lo que las funciones básicas se incorporarán en una multiplicidad de realizaciones de terminales integradas o modulares. En consecuencia, no es necesario que las empresas desarrollen aplicaciones y servicios para adquirir un conocimiento técnico preciso sobre las tecnologías básicas y la construcción del hardware.

La transferencia de aplicaciones a distintas realizaciones de terminales sólo es posible si se estandarizan las funciones básicas.

Arquitectura funcional

Una parte importante de esta especificación es la configuración de la interfaz entre las aplicaciones y las funciones básicas, preferentemente elegida como interfaz extra, la interfaz de programación de aplicaciones (Application Programming Interface o API) (véase la figura 2). No obstante, en algunos casos puede resultar útil definir únicamente una interfaz común en el sistema. Las funciones básicas incluyen preferentemente los subsistemas de comunicación, ubicación, control de acceso, entrada/salida y la interfaz estándar de comunicaciones (SCI). La conexión entre las aplicaciones y los subsistemas se establece por la función general de control del sistema y enrutamiento. Mientras que el enrutamiento se ocupa únicamente de las tareas, el control del sistema supervisa las funciones y el registro de errores y fallos.

Con la ayuda del subsistema de comunicación pueden establecerse conexiones con la red GSM añadiendo un módulo GSM. Debe destacarse nuevamente que GSM y GPS son sólo ejemplos de los medios de comunicación y navegación ya mencionados que pueden utilizarse dentro de este concepto. Pueden intercambiarse datos con unidades centrales de servicio ubicadas en la red terrestre. En principio, también pueden conectarse otras redes al subsistema de comunicación, siempre y cuando se ajusten los comandos de función. El receptor GPS suministra datos procedentes del sistema GPS de navegación por satélite, lo que permite determinar la posición de un vehículo. A diferencia del lector de tarjetas GSM que se utiliza actualmente, puede implementarse un dispositivo adicional de lectura de tarjetas para ejecutar la función adicional de procesamiento de la tarjeta de chip telemática viaria (véase [8]), la cual puede consistir en una combinación de tarjeta de chip telemática viaria y GSM. La función de la tarjeta de chip consiste fundamentalmente en permitir la ejecución de aplicaciones telemáticas viarias [6]. La unidad de entrada/salida proporciona información al usuario. Además, éste puede introducir información para controlar el terminal de base. La SCI permite que el dispositivo periférico externo acceda a tantas funciones del dispositivo de base como sea
posible.

Determinados subsistemas pueden estar diseñados para incorporar una gestión de prioridades, con lo que las solicitudes de los usuarios de primera prioridad pueden atenderse inmediatamente, es decir, es posible interrumpir otras funciones, como el uso de la pantalla o una conexión GSM.

La determinación de la posición del vehículo puede apoyarse en sensores (por ejemplo, navegación a estima). Puede conseguirse una determinación más precisa utilizando información diferencial en formato RTCM.

Para operar el módulo GSM, puede conectarse directamente la unidad de entrada/salida del propio sistema. Siempre que esté conforme con la norma ETSI GSM 07.07, dicha unidad también puede usarse como unidad de entrada/salida para aplicaciones telemáticas viarias.

La API está conectada con dispositivos externos a través de la SCI (véase la figura 3). A través de esta SCI, las aplicaciones telemáticas viarias externas adicionales también pueden hacer uso de los subsistemas. Además, los servicios de FAX y datos se operarán principalmente mediante esta interfaz. Los sistemas de buses del interior del vehículo pueden conectarse a través de un adaptador (adaptador de bus de vehículo).

El servicio de voz es, aparte de los servicios de datos GSM, una parte opcional del dispositivo de base.

La presente especificación no contiene restricciones sobre la arquitectura de hardware del dispositivo, motivo por el cual pueden implementarse las funciones básicas en un dispositivo telemático viario de base y en un dispositivo compuesto de distintos componentes. La especificación define la interfaz entre una representación de componentes necesarios para la telemática viaria y sus requisitos funcionales, por un lado, y aquellas aplicaciones telemáticas viarias basadas en secuencias funcionales definidas de sus componentes básicos, por otro.

La siguiente descripción ofrece un ejemplo detallado del invento que aquí se reivindica.

2 Ámbito de las funciones básicas 2.1 Resumen de las funciones básicas y de las interfaces externas

Las funciones comunes del dispositivo multifuncional de base se ofrecen como funciones básicas. Éstas poseen una interfaz con las aplicaciones de servicios (interfaz API) y emplean distintos componentes de hardware como GSM, GPS, lector de tarjetas de chip, dispositivos de entrada/salida, etc. Las funciones básicas pueden agruparse bajo los siguientes epígrafes:

Comunicación GSM: La función básica de comunicación GSM más el módulo GSM constituyen el acceso a la red GSM.

Ubicación GPS: La función básica de ubicación GPS más el módulo GSM, que contiene el algoritmo de identificación y determinación de la posición constituyen el subsistema de ubicación.

Aparte del sistema de determinación de la posición GPS, pueden implementarse otros sistemas de posicionamiento GNSS en dicho subsistema de ubicación. Para ello, serían necesarios módulos de ubicación adicionales. Sin embargo, en el primer ejemplo sólo se tendrá en cuenta el módulo GPS.

Es importante diseñar el subsistema de ubicación de tal manera que las aplicaciones de servicio no queden afectadas si se añaden otros procedimientos de ubicación en el futuro. La ubicación GPS puede complementarse con otros procedimientos, como el desencadenamiento GSM a través de Underlay Broadcast Cell. El subsistema de ubicación no sufre modificaciones si la navegación por satélite se apoya en sensores externos e información diferencial. La información diferencial puede suministrarse directamente al subsistema de ubicación o puede solicitarse a través de la API (en caso de fuentes externas, a través de la SCI) y, a continuación, transmitirse al subsistema de
ubicación.

Control de acceso: El subsistema de control de acceso contiene las funciones básicas para la gestión de la tarjeta de chip.

Entrada/salida: Incluye las funciones de entrada/salida para la visualización y la operación de elementos.

Además, se ofrecen funciones generales:

Enrutamiento + control del sistema: El enrutamiento organiza el flujo de información que va desde las aplicaciones a las funciones básicas, desde las funciones básicas a las aplicaciones, entre aplicaciones y entre funciones básicas. El control del sistema ejecuta tareas tales como la inicialización (configuración), control de estados (estado de error), diagnóstico, administración de versiones y supervisión de procesos individuales (perro guardián).

Gestión de prioridades: La gestión de prioridades regula el acceso a las funciones básicas.

2.2 Descripción funcional 2.2.1 Funciones básicas del subsistema de comunicación

Muchas aplicaciones telemáticas viarias tienen en común la necesidad de la comunicación móvil. El sistema global de comunicación móvil (Global System of Mobile Communication o GSM) proporciona la base para el subsistema de comunicación que se emplearía en toda Europa. El subsistema de comunicación se ha diseñado de tal manera que puedan agregarse redes alternativas, dejando así el sistema abierto para redes especiales de comunicación móvil como Inmarsat. La arquitectura funcional es transferible siempre y cuando se modifiquen los comandos de funciones de la forma adecuada.

El subsistema de comunicación ofrece acceso a los servicios de datos (colaboran en el intercambio de información con la unidad central de servicios) y se ocupa del control de las conexiones. Las funciones básicas son libres de elegir su acceso al módulo GSM. Sin embargo, recomendamos la utilización de comandos AT (tal y como se estipula en las recomendaciones GSM 07.05[2] y 07.07[3]). También existe una tabla de servicio de comunicaciones (Communications Service Table o CST) que informa a las aplicaciones sobre la disponibilidad de servicios de
datos.

La función básica "acceso indirecto por comando AT" permite que las aplicaciones accedan al módulo GSM de forma indirecta utilizando determinados comandos AT. Este acceso está restringido a la solicitud de información de estado.

La función básica "gestión de llamadas" contiene un mecanismo de reintento en caso de conexión incorrecta. Esto libera a la aplicación de la tarea de encargarse de volver a marcar y de los errores de conexión.

Para proporcionar asistencia en el uso de los servicios de portadores basados en conexión con TASP4 (protocolo de seguridad de aplicaciones telemáticas, capa 4), se ha definido un protocolo adicional punto a punto para transmitir con seguridad desde el dispositivo de base al centro. El subsistema de comunicación contiene las siguientes funciones básicas:

1.

Transferencia de datos GSM

2.

Acceso indirecto por comando AT

3.

Tabla de servicios de comunicaciones

4.

Gestión de llamadas

5.

Protocolo de punto a punto.

La ilustración 2.2.1-1 muestra la arquitectura funcional de un subsistema de comunicación.

Ilustración 2.2.1-1: Arquitectura funcional del subsistema de comunicación

Se recomiendan determinados servicios de datos para aplicaciones telemáticas viarias para su uso en la red GSM, éstos incluyen Teleservicio 21 (SMS-MT), Teleservicio 22 (SMS-MO), servicio portador 24 (2.400 bit/s) y servicio portador 26 (9.600 bit/s), tanto transparentes como no transparentes. Los servicios futuros incluyen Teleservicio 23 (Cell Broadcast SMS) y GPRS (Servicio general de radio por paquetes) con su variante PDSS.

Los servicios de datos disponibles dependen del país y la red. La aplicación selecciona los servicios de datos (por ejemplo, SMS, BS24 o BS26) y los transmite como parámetro a la función básica junto con el mensaje.

Una aplicación puede elegir entre distintos servicios de datos al comunicarse con su centro. La aplicación del terminal debe recibir del centro la información de los servicios de datos preferibles.

Puesto que no existe garantía de que el servicio de datos preferente esté disponible localmente, el subsistema de comunicación mantiene una tabla de servicios de comunicaciones (CST). La finalidad de la tabla consiste en registrar el éxito (o la ausencia de éxito) de los intentos de contacto con un servicio determinado; por tanto, es capaz de informar a la aplicación de si el servicio GSM solicitado está disponible sin que la aplicación tenga que ponerse en contacto con éste. En caso de duda, se emplea el método de ensayo y error.

La tabla de servicios de comunicaciones también registra qué servicios de datos son compatibles con el dispositivo de base. Así pues, puede informar a la aplicación de los servicios que están implementados y que son, por tanto, preferibles.

Las aplicaciones deciden por sí mismas si desean seguir las sugerencias de la tabla o si prefieren un servicio alternativo.

El mecanismo de gestión de errores está diseñado para tratar con problemas relacionados con el control de las conexiones GSM. El protocolo TASP4 punto a punto se implementa en el subsistema de comunicación, el cual, si se utilizan los servicios portadores (transparentes o no transparentes), garantiza la transferencia segura de los datos entre el dispositivo de base y el centro de servicios (véase la ilustración 2.2.1-2).

\newpage

Ilustración 2.2.1-2: Componentes de la comunicación entre el terminal de base y el centro de servicios

Aparte de utilizar el módulo GSM indirectamente con la ayuda de los comandos de funciones básicas, también existe un acceso directo al módulo. Las aplicaciones telemáticas viarias siempre accederán de modo indirecto utilizando los comandos de funciones básicas pertinentes.

Las aplicaciones de transferencia de datos como PC y FAX, de uso frecuente hoy en día, utilizan el acceso directo; pueden conectarse al dispositivo de base sin alterar el software. El acceso directo es sólo posible a través de la interfaz de comunicación estándar, motivo por el cual la SCI ha de ser capaz de reconocer una solicitud de acceso directo. De lo contrario se produciría un conflicto si, por ejemplo, una aplicación telemática viaria de prioridad máxima (como una llamada de emergencia) se viera bloqueada por la transmisión de un FAX. Estos conflictos se resuelven mediante la función de gestión de llamadas.

2.2.1.1 Transferencia de datos GSM Contacto con el centro de servicios

Se ofrecen varios centros de servicios con distintos números de teléfono. Si debe establecerse una conexión, la aplicación pasa el número al centro de servicios pertinente. Es responsabilidad de la aplicación actualizar el número en caso necesario.

Secuencia de diálogos

Tanto el centro de servicios como la aplicación del terminal pueden iniciar un diálogo. Si, por ejemplo, se deben enviar mensajes o solicitar información a un centro de servicios, la aplicación del terminal comienza el diálogo. La estructura de los diálogos es prácticamente idéntica para todos los servicios de datos GSM, con independencia de que utilice un servicio portador, un servicio de mensajes cortos, el futuro servicio general de radio por paquetes o el servicio de datos empaquetados sobre canales de señales (PDS). La ilustración 2.2.1-3 muestra una secuencia de diálogo para una conexión basada en línea que ha sido iniciada por una aplicación del terminal. Mientras que la secuencia del diálogo del dispositivo de base es invariable, la secuencia del centro de servicios puede cambiar.

Ilustración 2.2.1-3: Secuencia de diálogo GSM de un servicio portador (basado en conexión) iniciada por una aplicación del terminal con una secuencia de ejemplo del centro de servicios.

Las solicitudes y los mensajes individuales se describen en el capítulo 3 (especificación de API). El término "mensaje" se refiere tanto a solicitudes como a mensajes. En sentido estricto, los comandos descritos son "primitivas", tal y como se definen en la tecnología de las comunicaciones, ya que regulan la secuencia de comunicación con el siguiente nivel. Sin embargo, puesto que se trata de comandos y secuencias que conciernen sólo a la relación entre aplicaciones y funciones básicas, en este documento el término "mensajes" se utiliza exhaustivamente.

La ilustración 2.2.1-3: muestra que la secuencia de comunicación consta de tres fases.

La primera fase abre un canal lógico de comunicación para la transferencia de datos entre la aplicación y el subsistema de comunicación. La solicitud de comunicación contiene otros parámetros aparte del número del centro de servicios. La información relativa al servicio de datos GSM preferente y al identificador de servicios de aplicaciones (ASI), por ejemplo, son parámetros importantes. Existe una norma común europea para todos los servicios telemáticos viarios. Si se trata de conexiones basadas en línea, la configuración de la conexión física a través de una interfaz aérea debe confirmarla el centro antes de que la función básica pueda abrir un canal y asignarle un número de canal. Los servicios basados en paquetes, como SMS, no precisan de la confirmación del centro. Como en el caso de estos servicios el centro de SMS facilita una conexión segura, no es necesario utilizar el protocolo TASP4 punto a punto (que se describirá más adelante). A la solicitud de abrir un canal de comunicación le siguen inmediatamente la confirmación de la función básica y la asignación de un número de canal.

La segunda fase permite un intercambio bidireccional de datos (transmisión y recepción). La confirmación de la recepción se trata de forma distinta en el caso de los servicios de línea y los servicios de paquetes. Puesto que los servicios portadores emplean un protocolo punto a punto, éste confirma la recepción al remitente. En cuanto al servicio de mensajes cortos (SMS), el centro de SMS confirma la recepción sin necesidad de transmitir el mensaje al centro telemático viario.

Si es necesario obtener una confirmación de la aplicación por el contenido de los datos transferidos (por ejemplo, seguridad de pago), la aplicación debe incorporarlo en su mensaje de respuesta.

En la tercera fase, se cierra el canal de comunicación existente. Tanto el centro de servicios como el dispositivo de base pueden cerrar la conexión. Generalmente, la conexión la cierra la parte que ha iniciado la comunicación. No obstante, hay excepciones a esta norma, por ejemplo, si se interrumpe una conexión existente (por gestión de prioridades), si varias aplicaciones telemáticas viarias utilizan las conexiones existentes al mismo tiempo o si una conexión es activada por la otra parte o la red (por ejemplo, en caso de sombra). Además, si deja de haber transferencia de datos durante un determinado periodo de tiempo o si la conexión supera la duración máxima predefinida, el hecho queda registrado (perro guardián) y la función básica inicia la desconexión. Si existe una solicitud de cerrar el canal en una comunicación de paquetes, sólo se cerrará el canal entre la aplicación y la función básica. Por este motivo, la función básica puede confirmar la solicitud inmediatamente. Lo mismo es válido para la comunicaciones de conexión: la confirmación de cierre del canal lógico entre la aplicación y la función básica sigue inmediatamente a la finalización de la conexión. El protocolo punto a punto informa al centro sobre la finalización y el centro la confirma.

El diálogo también puede iniciarlo una llamada del centro una vez que ha atravesado la función de gestión de llamadas (véase el capítulo 2.2.1.4). En ese caso, se aplica la imagen especular de la ilustración 2.2.1-3; de nuevo se regula la secuencia de diálogo del dispositivo de base, la secuencia del centro es sólo un ejemplo. La función básica, haciendo uso de los identificadores de servicios de aplicaciones (ASI), informa a la aplicación de la entrada de una llamada enviando el mensaje "gsm_open_indication". El comando de apertura no depende de ningún servicio de datos concreto (servicios portadores o SMS). En la segunda fase, la transferencia de datos se mantiene sin cambios; en la tercera fase, se cierra el canal lógico. Si se utiliza el protocolo punto a punto, la función básica envía el mensaje "gsm_close_ind" sólo si la conexión punto a punto está activada. En el caso de SMS, la gestión de llamadas inicia el mensaje "gsm_close_ind". Esto sucede bien inmediatamente tras la transmisión del paquete de SMS o tras un periodo de espera predefinido en caso de que se espere un mensaje de seguimiento.

Dentro del subsistema, la función de gestión de prioridades es la que regula los requisitos de conflicto de comunicaciones. Para ello se compara la prioridad de cada solicitud nueva de comunicación con las comunicaciones en curso. Si se registra una solicitud de transmisión con una mayor prioridad, se interrumpe la conexión física existente y se informa del hecho a la aplicación cuya comunicación ha sido interrumpida. Sin embargo, la conexión lógica entre la aplicación y la función básica (al igual que el número de canal) no sufren modificaciones. Una vez que se ha completado la comunicación de mayor prioridad (solicitud de conexión, transferencia de datos, finalización de conexión), se reestablece la conexión física y vuelve a enviarse un mensaje a la aplicación (número de canal). A continuación, se repita la comunicación.

En caso de que hayan de enviarse datos de prioridad alta al mismo centro, la transferencia de datos se interrumpe. Se informa del hecho a la aplicación cuya comunicación se ha interrumpido, aunque tanto el canal lógico como la conexión física con el centro se mantienen abiertos. En ese momento se transfieren los datos de alta prioridad; una vez finalizado el proceso se cierra el canal de alta prioridad. Al mismo tiempo, se informará a la aplicación cuya comunicación se ha interrumpido. Se volverá a implementar el protocolo punto a punto y proseguirá la comunicación interrumpida.

La función básica establece mecanismos de seguimiento que garantizan que la transferencia de datos interrumpida pueda proseguir eficientemente. Resulta lógico mantener la conexión abierta si va a seguirse usando el mismo servicio. Si, por ejemplo, se ha establecido una conexión B26 y la aplicación de alta prioridad se transmite por B24, puede utilizarse la conexión existente, siempre que sea compatible con la aplicación. De lo contrario, será necesario finalizar la conexión y realizar un nuevo establecimiento de conexión. En dicho caso se informará a la aplicación afectada sobre la desconexión.

Uso múltiple de una conexión existente

Varias aplicaciones pueden utilizar una misma conexión existente a la vez, siempre que todas empleen el mismo dispositivo y se conecten al mismo centro de servicios. Dentro de una misma conexión, una o varias aplicaciones pueden transmitir o recibir varios mensajes sucesivamente.

Si un mensaje resulta demasiado largo para su envío, podrá dividirse en paquetes. Sin embargo, todos los paquetes que correspondan al mismo mensaje deberán ser enviados, y la transmisión correcta deberá ser confirmada, por el protocolo punto a punto, antes de poder enviar o transmitir otro mensaje. No existirá infraestructura para la transmisión compleja de varios mensajes por parte de una o varias aplicaciones (operación múltiplex).

Para finalizar la comunicación, la aplicación envía un comando a la función básica para que cierre el canal. A continuación, se cerrará el canal lógico de comunicación entre la aplicación y la función básica (como se describe bajo el epígrafe "Secuencia de diálogos"). Si otras aplicaciones siguen usando la misma conexión, la conexión física finalizará sólo cuando dichas aplicaciones hayan terminado sus respectivos diálogos con el centro de servicios.

Función de perro guardián

La función de perro guardián supervisa las conexiones GSM. Esta función tiene la capacidad de interrumpir conexiones si detecta errores del sistema. Se han implementado dos temporizadores para ejecutar esta operación. Uno de los temporizadores determina el periodo de tiempo que debe transcurrir antes de interrumpir una conexión si se detiene el flujo de datos. El otro temporizador determina la duración máxima de una conexión. En cuanto se supera esta duración, se interrumpe la conexión aun cuando quedan datos por transmitirse.

2.2.1.2 Acceso indirecto por comando AT

El acceso indirecto por comando AT permite a las aplicaciones dirigirse al módulo GSM utilizando determinados comandos AT. De este modo puede solicitarse información relativa al estado y la inicialización del módulo GSM. Para acceder al módulo GSM, se recomienda utilizar los comandos AT extendidos, tal y como se describen en las Recomendaciones GSM 07.05[3] y 07.07[2].

La mayoría de los comandos AT posibles están disponibles a través de acceso indirecto, excepto los que son necesarios para el establecimiento de la conexión y la comunicación de diálogos, ya que estas funciones están cubiertas por las funciones básicas especiales.

En el apéndice 2 de este documento se ha incluido una lista de los comandos AT disponibles (véase capítulo 5.2).

2.2.1.3 Acceso a la tabla de servicios de comunicaciones

La aplicación decide qué sistema de datos desea utilizar. No obstante, el subsistema de comunicación proporciona una tabla de servicios de comunicaciones (CST) para documentar la disponibilidad de los servicios solicitados por las aplicaciones.

Las aplicaciones disponen de acceso al contenido de esta tabla a través de un comando de función. Asimismo, éstas pueden modificar el contenido, por ejemplo, incorporando el número de teléfono de un centro telemático viario (identidad de línea llamante o CLI).

Una aplicación puede consultar si determinado servicio de comunicación está implementado en la terminal de base y si el servicio se encuentra disponible en ese momento. Por lo tanto, es importante que la CST tenga la capacidad de incluir tanto servicios reales como servicios potenciales.

Recomendamos la compatibilidad con los siguientes servicios de comunicaciones:

Servicios portadores - BS24, BS26 (transparente y no transparente)

Teleservicios - TS11, TS21, TS22, TS23

más servicios suplementarios

CLIP/CLIR y llamada en espera se consideran servicios suplementarios.

Inicialización

La tabla se guarda en una memoria variable volátil y cada vez que se enciende el dispositivo, la tabla se actualiza de acuerdo con el módulo GSM. Si se implementa o descarga software en el terminal de base o éste se actualiza, los servicios, compatibles con el terminal de base, se introducen en la CST.

Actualización

Los servicios de datos disponibles en la red sólo se actualizan si el módulo GSM está en funcionamiento. Cada vez que se produce o se rechaza una transferencia de datos, se actualiza el estado del servicio de datos solicitado o empleado. La aplicación recibe información sobre si la transferencia se efectuó o si el servicio de datos no estaba disponible. A continuación, la aplicación decide si desea emplear una alternativa.

Como la disponibilidad puede cambiar (por ejemplo, por traslado de la red o error local), las entradas de la tabla son válidas sólo por un periodo de tiempo limitado.

2.2.1.4 Gestión de llamadas

La gestión de llamadas ejecuta dos funciones esenciales. En primer lugar, comprueba las llamadas entrantes y determina si se han sido transmitidas por el centro telemático viario o si va a tener lugar un acceso a una aplicación externa de PC o FAX. En segundo lugar, la gestión de llamadas se encarga de todo tipo de errores de comunicación.

Examen de llamadas entrantes

Una llamada entrante puede dirigirse bien a aplicaciones telemáticas viarias o bien a otras aplicaciones, como aplicaciones de PC, FAX, etc. Si el módulo GSM es compatible con la identidad de líneas llamantes (CLI) y el centro está conectado a la red directamente o mediante RDSI, se informará del número al centro de servicios. Cualquier otra información se integra en paquetes de datos (la llamada "información en banda"). La CLI adecuada se introduce en la CST.

Para toda llamada entrante debe decidirse cómo se desarrollará la secuencia de comunicación subsiguiente y a quién va dirigida la llamada. A continuación, se incluye una descripción de dicho proceso.

(1) Antes que nada debe determinarse si la llamada entrante es un mensaje corto o no.

Si no es un mensaje corto:

(2) La gestión de llamadas determina si se suministra la identidad de línea llamante (CLI). En caso de que se proporcione dicha CLI, debe comprobar si puede asignarse a un centro telemático viario. Si es el caso, se acepta la llamada. (Continuar en (4) aunque el examen de la identificación telemática viaria es opcional.) Si no es así, se desvía a la interfaz estándar de comunicaciones (SCI).

(3) En caso de que no se suministre la CLI, se comprueba el servicio: si es una llamada de FAX, se reenvía a la SCI. De lo contrario, se acepta la llamada (continuar en (4)).

(4) Se acepta la llamada y se comprueba si se ha recibido una identificación telemática viaria (TV) (en forma de información en banda). Si es así, la información recibida se transmite a la aplicación telemática viaria interesada. Si no existe identificación TV, la información se transmite a la SCI.

Si se trata de un mensaje corto:

En caso de recibir un mensaje corto, el procedimiento depende del teleservicio utilizado:

(A) En caso de utilizar TS 21 (SMS MT), la gestión de llamadas comprueba si puede deducir el centro TV del número originario. Si puede determinarlo, el mensaje corto se transmite a las aplicaciones pertinentes. De lo contrario, el mensaje corto se transmite a la SCI.

(B) Si el servicio no es TS 21, el mensaje corto se trata como TS 23 (cell broadcast) y, tras evaluar el identificador, puede transmitirse a la aplicación.

Tratamiento de los errores de comunicación

No siempre es posible acceder al centro de servicios. Existen varios motivos, por ejemplo, la conexión puede verse perturbada o interrumpida, o el centro puede estar comunicando.

Por eso, es necesario implementar otros mecanismos de corrección individual aparte del mecanismo de tratamiento de errores específico de GSM, como son los reintentos cíclicos al establecer la conexión. Las repeticiones de marcado se llevan a cabo en consonancia con la norma GSM. Es posible introducir variaciones en función de la prioridad de la aplicación.

La CST mantiene y gestiona información (contador de reintentos con el correspondiente número de teléfono, sello de tiempo y motivo del rechazo) que necesita el subsistema de comunicación para mantener las restricciones de reintentos de marcado estipuladas en las recomendaciones GSM 02.07. (Anexo "Automatic calling repeat call attempt restrictions"). En el apéndice 1 se han incluido extractos de dichas restricciones.

Tras completar satisfactoriamente la transferencia de datos, la aplicación recibe una confirmación. Si se producen errores que no pueden ser rectificados por la función básica, se informa a la aplicación sobre los motivos. La aplicación decide si transmite o no al usuario la información sobre dichos errores.

Además, la aplicación puede acceder a otra información de error a través de las Causas de liberación de la red (por ejemplo, Causa 63: el participante no está abonado al servicio). Los mecanismos adecuados para el proseguimiento de la llamada y el dispositivo de repetición del marcado, por otro lado, están ubicados en las funciones
básicas.

El apéndice 1 presenta una lista de los posibles mensajes de error (GSM 04.08. Tabla 10.86) que las funciones básicas aceptan, condensan y transmiten a las aplicaciones.

Una vez que se ha establecido la conexión, el procedimiento sigue el protocolo punto a punto descrito en el siguiente capítulo.

2.2.1.5 Protocolo TASP4 punto a punto

El protocolo de seguridad de aplicaciones telemáticas ofrece una seguridad punto a punto y su tarea se corresponde con la del protocolo OSI de nivel 4. Al protocolo se le denomina TASP4. Sólo una de las funciones de TASP4 es necesaria para las aplicaciones telemáticas viarias y éste ejecuta menos funciones que un protocolo de transporte clásico, como TCP.

El protocolo TASP4 está basado en el protocolo LAPB, que puede hallarse en la especificación X.25 [7] (nivel 2). El protocolo LAPB se modificó de acuerdo con los requisitos especiales del nivel 4.

Ilustración 2.2.1-4: Secuencia de diálogo GSM de servicios portadores (basado en conexión) iniciada por una aplicación del terminal con un diálogo de ejemplo en el caso del centro de servicios

La ilustración 2.2.1-4 presenta una secuencia de comunicación que va más allá de la interfaz API (aplica-
ción <-> función básica). Muestra las dependencias implicadas haciendo especial hincapié en el protocolo TASP4 punto a punto. La secuencia de diálogo del terminal de base está definida detenidamente mientras que la secuencia del centro debe entenderse como un ejemplo.

Ámbito de las funciones

Estandarización: TASP4 es un protocolo HDLC modificado en operación dúplex total. Funciona en modo equilibrado.

Aplicación: Sólo pueden emplear el protocolo de transporte TASP4 las aplicaciones que funcionan con transmisiones de conexión (servicios portadores). No puede utilizarse con el servicio de mensajes cortos.

Múltiplex: El múltiplex (varios usuarios con acceso a la misma unidad TASP4 al mismo tiempo) lo ejecuta una función ubicada por encima del nivel de transporte. El encabezado del TASP4, por tanto, no incluye ninguna información de dirección.

Control de conexiones: El control de conexiones incluye aquellos elementos del protocolo que se ocupan del establecimiento y la finalización seguros de la conexión punto a punto.

Transferencia de información con confirmación: El mecanismo de confirmación positiva con control de tiempo garantiza que los paquetes llegan al receptor de forma segura. Los paquetes que no se confirman se envían de nuevo.

Transferencia de información sin confirmación: La transferencia de información sin confirmar a través de datagramas se emplea en broadcast y otros procedimientos simplificados.

Control de flujos: Se asegura por los medios habituales (es decir, ventana, RNR).

Control de errores: CRC-16 se encarga de la protección de la transferencia de datos.

Prioridad: Puesto que sólo hay un usuario, no se ha implementado ninguna capacidad para gestionar la prioridad a nivel de transporte. La gestión de la prioridad se lleva a cabo a nivel de aplicación, por ejemplo, finalizando una conexión (DISC) para establecer otra de mayor prioridad (SABM).

Enlaces de transmisión de línea: La transferencia a través de enlaces de transmisión de línea es posible gracias al ensamblaje de paquetes (indicador de inicio + indicador de longitud).

Transparencia: Los límites de bytes deben cumplirse; no obstante, no se recomienda el abarrote, sino conseguir transparencia con la ayuda del indicador de longitud.

Segmentación: Los mensajes largos pueden dividirse en varios segmentos, transmitirse por separado y el receptor puede volver a recomponerlos. La longitud máxima de un segmento depende del servicio portador.

Orden de los mensajes: Se asume que el orden de los mensajes no variará durante la transmisión. Esto es válido tanto para la transmisión de línea (BS24) como para la transmisión de conexión a través de X.25 [7].

La secuencia de mensajes y las primitivas del servicio del protocolo TASP4 se describen en el apéndice 3.

2.2.2 Funciones básicas del subsistema de ubicación

Una característica común de muchas aplicaciones telemáticas viarias es la necesidad de ubicar el vehículo. El sistema de posicionamiento global (Global Positioning System o GPS) conforma la base técnica del subsistema de ubicación. Sin embargo, el subsistema se ha diseñado de tal manera que permita al usuario utilizar otros procedimientos de ubicación. Esto significa que, si se desarrollan otros sistemas de ubicación en el futuro, éstos podrán implementarse en el sistema. La arquitectura funcional del sistema es transferible a condición de que se añadan comandos de función modificada. Todas las funciones básicas del subsistema de ubicación se basan en una determinación continua de la ubicación por parte del receptor GPS.

En concreto, el subsistema de ubicación comprende las siguientes funciones básicas:

1.

Función básica de datos básicos GPS

2.

Función básica de geometría

3.

Función básica de aproximación

4.

Función básica de waylength

5.

Función básica de waypoint.

La siguiente ilustración 2.2.2-1 muestra la arquitectura funcional del subsistema de ubicación.

Ilustración 2.2.2-1: Arquitectura funcional del subsistema de ubicación

Las funciones básicas descritas en esta parte forman dos grupos: llamada y respuesta. En el caso de las dos funciones de datos básicos GPS y geometría, el resultado sigue a la solicitud de la aplicación de forma inmediata. La función básica de aproximación se ejecuta en segundo plano en caso de que el módulo GPS no devuelva la posición (por ejemplo, por fallo de señal o reflexión) y ésta deba aproximarse. Las otras funciones básicas pueden ejecutar sus operaciones en segundo plano cuando así se les pide. Los resultados se envían a la aplicación que emitió la solicitud en un momento posterior.

El subsistema de ubicación no procesa la información de prioridad contenida en el superframe del mensaje (véase capítulo 3.2.1). Como las funciones básicas de datos básicos GPS y geometría proporcionan resultados inmediatos, una interrupción no sería lógica. Otras funciones básicas que se ejecutan en segundo plano no utilizan el receptor GPS exclusivamente, lo que significa que un procesamiento en paralelo no supone ningún problema.

La localización puede apoyarse en sensores (como navegación a estima, lectura del velocímetro, sensores de aceleración). Con la navegación a estima, la posición puede determinarse aun cuando se produzca un fallo temporal del módulo GPS. De este modo se incrementa la disponibilidad del subsistema de ubicación.

La precisión de la determinación de la posición puede aumentarse utilizando información diferencial. La información diferencial puede transmitirse de dos maneras: directamente al módulo GPS (siempre y cuando sea técnicamente factible) o a través de la API (SCI para fuentes externas). Si una aplicación precisa de datos de posición DGPS corregidos, puede solicitar información diferencial al centro a través del subsistema de comunicación. Los datos corregidos, procedentes del centro, se reenvían al subsistema de ubicación con el mensaje correspondiente.

Puesto que la potencia de procesamiento del sistema es limitada, es importante crear un sistema inteligente de control de recursos. Sin embargo, esto no atañe al objeto de esta especificación.

2.2.2.1 Función básica de datos básicos GPS

La función básica de datos básicos GPS está ubicada justo al lado de la interfaz con el módulo GPS. Suministra datos de posición GPS tanto a aplicaciones TV como a funciones básicas GPS.

La función básica de datos básicos GPS procesa grupos de datos GPS (suministrados en distintos formatos en función del módulo GPS) y los traduce a un conjunto de datos estándar.

Si se solicita, las aplicaciones disponen de los siguientes elementos de datos: fecha y hora (UTC); latitud geográfica; longitud geográfica; altitud (al nivel del mar); dilución de precisión horizontal (HDOP); error de posición estimado en dirección sur-norte (EPE(x)); error de posición estimado en dirección este-oeste (EPE(y)); valor de velocidad horizontal; rumbo; número de satélites (los que teóricamente pueden usares y los que se están utilizando realmente); parámetro necesario para notar un cambio de constelación de los satélites pertinentes; tipo de posición (TOP); datos específicos del receptor; datos de pseudorrango y tasa de pseudorrango.

Siempre hay más elementos de datos de los que una aplicación realmente necesita. Cada aplicación elige los elementos de los que precisa con la ayuda de un mapa de bits y, luego, los coloca en una solicitud que pide únicamente dichos elementos. Si varias aplicaciones TV solicitan distintos elementos de datos, se enviará todo el conjunto de datos a la aplicación. Un mapa de bits indica qué datos contiene el conjunto.

La fecha y la hora de cada punto de medición se determinan directamente a través del dial interno del receptor GPS. Cada cuatro años, las aplicaciones deberán tener en cuenta el segundo intercalar, ya que en ese momento dos conjuntos de datos consecutivos tendrán el mismo sello de tiempo.

La longitud y la latitud geográficas (en referencia a WGS 84) del punto de medición son parámetros clave para la determinación de la posición.

El valor DOP es la relación entre el error de la posición del receptor y el error de la posición del satélite. Permite llegar a conclusiones sobre la constelación geométrica de satélites y, por tanto, sobre la precisión de la posición real. De entre los distintos valores DOP, sólo se proporciona el de dilución de precisión horizontal (HDOP), ya que sólo este valor es relevante para la determinación de la posición sobre el plano.

El error de posición estimado es un valor estadístico de desviación estándar de campana de Gauss e indica el error de posición estimado horizontal utilizando el sistema métrico. Consta de dos valores, el error de posición en dirección sur-norte (EPE(x)) y el error de posición en dirección este-oeste (EPE(y)). Si un receptor sólo puede determinar uno de los valores EPE, los dos errores de posición serán idénticos.

La velocidad se define aquí como el valor de velocidad horizontal. El rumbo es el ángulo (en grados) del vector de velocidad horizontal en dirección norte (es decir, 0 grados significa "norte"). La rotación sigue el sentido de las agujas del reloj. Si la velocidad baja por debajo de determinado valor (velocidad mínima), se registra como 0 m/s y el rumbo se muestra como "no válido". La velocidad mínima depende del tipo de módulo GPS y de la existencia de sensores de apoyo.

Los parámetros que indican un cambio en la constelación del satélite tienen bien el valor 0 ("sin cambio de constelación") o bien 1 ("cambio de constelación"). Este parámetro sirve como indicador de un cambio de posición.

Los datos de pseudorrango contienen información relativa al tiempo de propagación de señal de satélites concretos; con estos datos puede calcularse la posición GPS diferencial retroactivamente.

El tipo de posición (TOP) describe de qué modo se ha de determinar la posición. El TOP es un mapa de bits que contiene los siguientes indicadores: posición no válida (determinación de la posición actual innecesaria); posición autónoma tridimensional; posición autónoma bidimensional; posición diferencial tridimensional; posición diferencial bidimensional; cálculo de la posición bidimensional con altura fija; posición generada por aproximación progresiva; posición generada por aproximación regresiva; posición calculada con apoyo de sensores.

Si a la función básica de datos básicos GPS llega una posición no válida desde el receptor GPS (es decir, no es posible la determinación de la posición actual), la aproximación de la función básica calcula las posiciones aproximadas progresivas y envía estos datos a las aplicaciones. La aproximación se lleva a cabo basándose en las últimas n posiciones válidas (n \geq 2), las cuales deben guardarse a dicho efecto. El requisito mínimo es una aproximación lineal (es decir, n = 2).

En cuanto vuelve a haber posiciones válidas disponibles, la función básica de aproximación realiza una aproximación regresiva para rellenar los espacios blancos. Estos datos se transmiten a la aplicación por solicitud.

Las posiciones aproximadas progresivas y regresivas se indican en el mapa de bits del TOP.

El cálculo de posición bidimensional puede ejecutarse de dos maneras. En un primer caso, si no hay satélites disponibles en determinado momento, el receptor GPS utiliza la última altura válida para determinar la posición. En un segundo caso, una de las aplicaciones puede suministrar una altura, que utiliza el receptor GPS como información adicional para mejorar la precisión de la determinación de la posición.

La altitud puede determinarla una aplicación si conoce la altitud exacta en relación con la longitud y la latitud de su posición actual. Dicha aplicación envía la altitud a la función básica de datos básicos GPS junto con el radio del círculo que rodea a la posición actual, dentro del cual la posición definida sigue siendo correcta. La función básica de datos básicos GPS comprueba si la siguiente posición sigue encontrándose dentro del círculo analizando la velocidad actual y el intervalo de tiempo. Sólo si se cumple lo anterior la aplicación remite la altitud al receptor GPS. Este procedimiento se repite con cada nueva posición. Si el análisis revela que la siguiente posición se encontrará fuera del círculo, la altitud establecida se elimina bien mediante la función básica o mediante la aplicación utilizando el mensaje correspondiente. Todo conflicto de altitudes entre distintas aplicaciones ha de resolverse dentro del terminal de base. Esto puede incluso provocar que ninguna de las altitudes sea utilizable.

2.2.2.2 Función básica de geometría

La función básica de geometría contiene funciones matemáticas básicas a disposición de las otras funciones básicas y de las aplicaciones telemáticas viarias. Los cálculos se ejecutan de acuerdo con WGS 84.

Se han implementado las siguientes funciones matemáticas: cálculo de la distancia radial entre dos posiciones; cálculo de la distancia longitudinal entre dos posiciones; cálculo de la distancia latitudinal entre dos posiciones, y cálculo del ángulo de dirección de una posición respecto a otra.

La llamada de la función puede adoptar dos formas: cálculo de la distancia y del ángulo de dos posiciones que se reenvían durante la llamada, o cálculo de la distancia y el ángulo de la posición actual en relación con otra posición que se determina durante la llamada.

En todos estos cálculos se recomienda utilizar fórmulas de aproximación para distancias y ángulos pequeños, que aun siendo menos exactos, ahorran tiempo de cálculo.

2.2.2.3 Función básica de aproximación

La aproximación de posiciones se utiliza en aquellas situaciones en las que no existen suficientes puntos de medición (por ejemplo, en el caso de sombras o reflexiones del satélite). Basándose en los valores aproximados, puede calcularse la velocidad y el movimiento de dirección para cada posición aproximada.

Existen dos procedimientos de aproximación distintos: la aproximación progresiva en tiempo real y la aproximación regresiva.

La aproximación progresiva en tiempo real se lleva a cabo de forma automática. La posición aproximada obtenida por este método se reenvía a la función básica de datos básicos GPS. Todas las aplicaciones TV que han solicitado posiciones GPS reciben la posición aproximada progresiva si no han efectuado otra solicitud. En cambio, las posiciones aproximadas regresivas se ofrecen a las aplicaciones que lo hayan solicitado expresamente.

Como requisito mínimo, la función básica de aproximación debe poder ejecutar una aproximación lineal. Esto puede hacerse utilizando el procedimiento polinómico, descrito abajo, asumiendo que el grado del polinomio sea 1. La aproximación polinómica debe entenderse como sugerencia para la mejora del procedimiento de aproximación. Sin embargo, el fabricante puede implementar otros procedimientos.

Si la función básica de datos básicos GPS recibe un conjunto de datos no válidos, la función básica de aproximación proporciona una posición estimada.

Antes que nada, se lleva a cabo una aproximación progresiva y se devuelven las posiciones calculadas a la función básica de datos básicos GPS. La función básica sólo puede generar un número limitado de posiciones aproximadas progresivas. Debe determinarse pues un número máximo; una vez que se ha superado ese número máximo, se suministran datos no válidos.

El error de posición estimado (EPE) se calcula para cada posición (también se aplica a posiciones aproximadas). En el caso de aproximaciones progresivas, el valor EPE aumenta con cada aproximación.

Una vez que se suministra la primera posición válida tras una serie de posiciones no válidas, se lleva a cabo una aproximación regresiva para rellenar los blancos de la posición del vehículo. En caso de que una aplicación reconozca la primera posición válida por su TOP, debe solicitar las posiciones aproximadas regresivas a la función básica de aproximación, si es que precisa de dichos datos.

Las aproximaciones regresivas sólo se llevan a cabo si la cantidad de tiempo en la que se han generado posiciones no válidas no supera un límite determinado.

Si el subsistema de ubicación se apoya en sensores, los cuales pueden suministrar posiciones continuas durante un cierto periodo de tiempo en caso de fallo del módulo GPS, durante dicho periodo no se usarán las aproximaciones progresivas y regresivas. Las rutinas de aproximación sólo se emplean después de que se ha suspendido la determinación de la posición por sensores.

La siguiente sugerencia de procedimiento mejorado de aproximación polinómica utiliza funciones polinómicas del mismo grado para la aproximación progresiva y regresiva. El grado de la función polinómica puede utilizarse como parámetro y habrá de definirse. Para una aproximación polinómica de grado m, deben conocerse (m+1) posiciones anteriores al espacio en blanco. Para mantener el cálculo lo más simple posible, se recomienda determinar el grado del polinomio en una escala entre 1 y 5.

a) Aproximación progresiva en tiempo real

Tras un fallo de señal, se llevará a cabo una aproximación progresiva de posiciones a partir del movimiento del vehículo (véase la ilustración 2.2.2-2).

La aproximación progresiva se realizará empleando una función polinómica de grado m. Para resolver la ecuación resultante, las últimas (m+1) posiciones válidas deben estar disponibles.

A continuación se usan a modo de ejemplo ecuaciones para obtener la coordenada latitudinal x (eje x en dirección norte). Puede aplicarse una metodología análoga para obtener la coordenada longitudinal y (eje y en dirección este).

Las últimas (m+1) posiciones válidas ("posiciones antiguas") son:

x_{0} = x(t_{0})

posición en el punto temporal t_{0}

x_{1} = x(t_{1})

posición en el punto temporal t_{1}

{}\hskip0,45cm . . .

x_{m} = x(t_{m})

posición en el punto temporal t_{m}

El receptor GPS se ajusta a un periodo de tiempo determinado y así regula el espacio en blanco entre cada uno de los puntos.

Ilustración 2.2.2-2: Aproximación progresiva polinómica

En caso de fallo de señal del receptor GPS, puede calcularse la primera posición aproximada x_{m-1} en el punto temporal t_{m-1} utilizando la fórmula polinómica siguiente:

x = a_{0} + a_{1}t + a_{2}t^{2} + a_{3}t^{3} + . . . + a_{m}t^{m}

Los coeficientes a_{0}, a_{1}, a_{2},. . ., a_{m} se calculan a partir de las posiciones antiguas:

\vskip1.000000\baselineskip

1

\vskip1.000000\baselineskip

2

\vskip1.000000\baselineskip

3

Las posiciones aproximadas progresivas x_{m+1}, x_{m+2}, x_{m+3}. . . en los distintos puntos temporales t_{m+1}, t_{m+2}, t_{m+3}. . . se determinan utilizando la fórmula siguiente:

x_{i} = a_{0} + a_{1}t_{i} + a_{2}t_{i}^{2} + a_{3}t_{i}^{3} + . . . + a_{m}t_{i}^{m} \hskip0,2cm donde \hskip0,2cm i = m + 1,m + 2,m + 3,. . .

b) Aproximación regresiva

Se llevará a cabo una aproximación regresiva tras un fallo de señal, una vez que esté disponible la primera posición válida tras el espacio en blanco (véase la ilustración 2.2.2-3). La aproximación regresiva se basa en el mismo procedimiento que la aproximación progresiva.

La aproximación regresiva se lleva a cabo con la ayuda de una función polinómica del mismo grado. Para resolver las ecuaciones resultantes, es necesario disponer de las últimas m posiciones válidas antes del espacio en blanco ("posiciones antiguas") y la primera posición válida tras el espacio en blanco ("posición nueva"). El procedimiento de aproximación es el mismo en la aproximación progresiva y en la aproximación regresiva.

Se establecen las siguientes ecuaciones para la coordenada latitudinal x (eje x en dirección norte). El procedimiento es análogo para la coordenada longitudinal y (eje y en dirección este).

Si el número de posiciones faltantes es nhole, las últimas m posiciones válidas antes del espacio en blanco ("posiciones antiguas") y la primera posición válida tras el espacio en blanco ("posición nueva") son:

x_{0} = x(t_{0})

posición antigua en el punto temporal t_{0}

x_{1} = x(t_{1})

posición antigua en el punto temporal t_{1}

{}\hskip0,45cm . . .

x_{m-1} = x(t_{m-1})

posición antigua en el punto temporal t_{m-1}

x_{m+nhole} = x(t_{m+nhole})

posición nueva en el punto temporal t_{m+nhole}

\newpage

Se determina la cantidad de tiempo que transcurre entre estos puntos (normalmente alrededor de un segundo) y se ajusta el receptor GPS en consonancia. La primera posición válida tras el espacio en blanco x_{m+nhole} se sitúa exactamente a (nhole+1) segmentos temporales tras la última posición antes del espacio en blanco x_{m-1}.

Ilustración 2.2.2-3: Aproximación regresiva polinómica

La primera posición aproximada regresiva del espacio en blanco x_{n} puede calcularse a partir de la siguiente fórmula polinómica:

x = a + a t + a_{2}t^{2} + a_{3}t^{3} + . . . + a_{m}t^{m}

Los coeficientes a_{0}, a_{1}, a_{2},. . ., a_{m} se calculan utilizando las posiciones válidas:

4

Al completar la siguiente fórmula, pueden determinarse todas las posiciones aproximadas regresivas del espacio en blanco x_{m}, x_{m+1}, x_{m+2}, . . ., x_{m+nhole-1} en los puntos temporales t_{m}, t_{m+1}, t_{m+2}, . . ., t_{m+nhole-1}:

x_{i} = a_{0} + a_{1}t_{i} + a_{2}t_{i}^{2} + a_{3}t_{i}^{3} + ... + a_{m}t_{i}^{m} \hskip0,2cm donde \hskip0,2cm i = m,m + 1,...,m + nhole - 1

2.2.2.4 Función básica waylength

La función básica waylength contiene funciones que son similares al cuentakilómetros del vehículo. Ésta solicita conjuntos de datos GPS a la función básica de datos básicos GPS y emplea la función básica de geometría para calcular distancias.

Las distancias entre posiciones se calculan utilizando las coordenadas longitudinales y latitudinales de los puntos de medición. El waylength, o distancia de camino, es la suma de las distancias entre las posiciones individuales (conexión aérea). La función básica incluye dos variaciones de waylength: incremento y disminución.

El incremento significa que el contador de waylength se ajusta a cero antes de arrancar. Con cada posición nueva, se calcula la distancia con respecto a la posición precedente (conexión aérea) y se añade. Si la aplicación ha definido alguna marca, cuando se haya pasado dicha marca, se informará correspondientemente a la aplicación. Asimismo, la aplicación puede solicitar la lectura del contador en cualquier momento.

En el caso del incremento, la aplicación puede detener el contador si ya no se necesita. Únicamente en ese momento es cuando puede iniciarse nuevamente el contador. Si no se ha finalizado el contador, la función básica lo desactivará en cuanto supere determinada lectura máxima.

La disminución se realiza como el incremento pero con valores negativos. En este caso, la aplicación determina el waylength que ha de cubrirse como valor negativo. Con cada posición nueva, se añade la distancia a la posición anterior a dicho valor negativo. Una vez que el contador supere la marca del "0", es decir, cuando el vehículo ha completado el waylength predefinido, se envía un mensaje. Una aplicación puede definir determinadas marcas como valores negativos, en cuyo caso se informará inmediatamente de que se ha superado la marca. Además, la aplicación puede solicitar explícitamente la lectura del contador en todo momento.

Por ejemplo, una aplicación solicita un mensaje cuando se ha recorrido un waylength de 2.000 m. Se envían mensajes adicionales cuando quedan por recorrer 200 m, 100 m y 50 m. Para ello, la aplicación debe determinar el waylength global de -2.000 m al igual que las marcas de contador -200 m, -100 m y -50 m. De este modo, la función básica informará a la aplicación cuando se alcancen las lecturas de contador -200 m, -100 m, -50 m y 0 m ("waylength recorrido").

La aplicación detiene el contador de waylength automáticamente cuando se alcanza la marca "0". Es posible detener el contador antes de dicho punto si la aplicación no precisa de más información. Además, la aplicación puede detener cada uno de los contadores por separado o todos a la vez.

En caso de fallo de datos GPS, se calculará la lectura actual del contador con la ayuda de las posiciones calculadas regresivamente durante el tiempo que dure el fallo. Si durante el fallo de señal se han superado una o varias marcas, la aplicación recibirá un mensaje con la lectura del contador actual. Si se ha recorrido todo el waylength durante el fallo, al calcular el waylength con las posiciones durante el fallo, el contador seguirá incrementándose tras superar la marca "0" hasta la lectura del contador actual (por ejemplo, "+200 m" para "todo el waylength recorrido más 200 m"). La función básica informará a la aplicación de dicha lectura de contador y seguidamente detendrá el contador.

Cada aplicación puede inicializar al mismo tiempo varios contadores de waylength, a los que debe asignar ID lógicas. La función básica waylength debe ser capaz de reconocer qué contador pertenece a qué aplicación.

Además de los contadores de waylength que pueden ser inicializados y detenidos por una aplicación, se establecerá un contador de waylength global que se incrementa en segmentos de un metro. Éste se inicia cuando el terminal de base se pone en marcha con un valor fijado en 0 metros y se mantiene activo durante el tiempo que el dispositivo esté encendido. Si el terminal se apaga y se enciende de nuevo, la lectura del contador será la misma. Ni el terminal de base ni las aplicaciones pueden detener ni retroceder a cero este contador de waylength. Las aplicaciones pueden solicitar explícitamente la lectura del contador de waylength global en un determinado momento.

2.2.2.5 Función básica waypoint

La función básica waypoint calcula la distancia entre el vehículo y determinado punto del recorrido (waypoint) determinado por una aplicación. Cada waypoint es una zona con una extensión finita (círculo o rectángulo). El tamaño del waypoint puede ser de un metro o de varios centenares de metros. Cuando el vehículo alcance o abandone esta zona y cuando pase por la línea central (de dirección normal a preferente atravesando el centro del waypoint), se informará a la aplicación de forma correspondiente.

La función básica waypoint utiliza los datos de posición GPS suministrados por la función básica de datos básicos GPS. Los cálculos de distancia necesarios pueden llevarse a cabo utilizando la función básica de geometría.

La primera variante de waypoint, que determina la aplicación telemática viaria, se define fijando un punto central y un radio. La segunda variante es un rectángulo definido por la aplicación fijando el punto central, la longitud y la anchura. El círculo o el rectángulo se rodean de una zona de histéresis para impedir que cambios insignificantes (por ejemplo, drift loops) en la posición liberen un mensaje. La zona de histéresis viene determinada por la aplicación.

Además, la aplicación define una dirección preferente y un ángulo de apertura. Las aplicaciones que no desean determinar una dirección preferente pueden fijar un ángulo de apertura de 360 grados. Si se define un waypoint rectangular, el eje longitudinal del rectángulo se alinea con la dirección preferente (véase la ilustración 2.2.2-4 y la ilustración 2.2.2-5).

Ilustración 2.2.2-4: Geometría del waypoint circular

Ilustración 2.2.2-5: Geometría del waypoint rectangular

Para cada posición, la función básica calcula la distancia con respecto al centro del waypoint y la compara con la extensión del waypoint.

Si el vehículo llega a la zona interna, se envía el mensaje de "status IN" (véase la ilustración 2.2.2-6 y la ilustración 2.2.2-7). En caso de que una posición cambie momentáneamente a la zona de histéresis (es decir, por culpa de drift loops) y luego vuelva a la zona interna, no se envía el mensaje "status IN".

Si el vehículo cruza la línea central (de dirección normal a preferente atravesando el centro), se envía el menaje "status CENTER" (véase la ilustración 2.2.2-6 y la ilustración 2.2.2-7). Además, se informa a la aplicación de si el rumbo del vehículo sigue en el cono de apertura de la dirección preferente. También aparecerá el rumbo actual.

Si el vehículo abandona la zona de histéresis, se enviará el mensaje "status OUT" (véase la ilustración 2.2.2-6 y la ilustración 2.2.2-7). En caso de que el waypoint se desactive por el envío del mensaje correspondiente por parte de la aplicación, el waypoint seguirá activo, es decir, si el vehículo vuelve a llegar al waypoint, se repetirá el procedimiento descrito más arriba.

La observación del waypoint se realizará tanto para posiciones válidas como para posiciones aproximadas (progresivas y regresivas). Se informará a la aplicación -al alcanzar (mensaje IN), cruzar (mensaje CENTER) y abandonar (mensaje OUT) un waypoint- del tipo de posiciones GPS (valor TOP: TOP (x), TOP (y)) en el que se basa el cálculo. En concreto, la aplicación averiguará si el cálculo se basa en posiciones reales medidas o aproximadas.

Si el vehículo llega a un waypoint y/o cruza la línea central y/o abandona el waypoint, se informará a la aplicación posteriormente por medio del mensaje correspondiente.

Los tres mensajes ("IN", "CENTER" y "OUT") también indican a la aplicación el sello de tiempo de la posición GPS que desencadenó el mensaje y la distancia de la posición con respecto a la línea central. Esto sitúa al mensaje en un contexto espacial y temporal, algo que es especialmente importante en el caso de las posiciones aproximadas por progresión o regresión. Si se produce una situación, en la que durante el cálculo de un waypoint tardío con posiciones aproximadas progresivas y regresivas se generan los mensajes "IN" y "CENTER" o "IN", "CENTER" y "OUT" simultáneamente, se proporciona más información, es decir, el valor TOP, el punto lineal aproximado en el tiempo, el rumbo y la distancia de la posición GPS que desencadenó el mensaje CENTER a la línea central.

No se producirá ningún mensaje si el vehículo sólo cruza la línea de histéresis.

Ilustración 2.2.2-6: Ejemplo de vehículo cruzando un círculo

Punto 1:

El vehículo llega a la zona interna, mensaje "status IN"

Punto 2:

El vehículo cruza la dirección de normal a preferente, mensaje "status CENTER" y "rumbo dentro del cono de apertura e la dirección preferente"

Punto 3:

El vehículo sale de la zona de histéresis, mensaje "status OUT".

Ilustración: 2.2.2-7: Ejemplo de vehículo cruzando un rectángulo

Punto 1:

El vehículo llega a la zona interna, mensaje "status IN"

Punto 2:

El vehículo cruza la dirección de normal a preferente, mensaje "status CENTER" y "rumbo dentro del cono de apertura e la dirección preferente"

Punto 3:

El vehículo sale de la zona de histéresis, mensaje "status OUT".

El mensaje IN se genera cuando se activa un waypoint y la posición GPS actual indica que el vehículo está situado dentro del waypoint.

Cada una de las aplicaciones puede determinar varios waypoints (a los que debe asignar una ID lógica) que puedan ser procesados a la vez por la función básica. La función básica reconoce qué waypoint pertenece a qué aplicación. La aplicación puede desactivar cada uno de los waypoints por separado o todos de una vez.

Una aplicación puede establecer waypoints que se activen automáticamente incluso en el caso de que se apague el sistema y vuelva a encenderse de nuevo. Esta característica puede resultar útil para una posible aplicación de "registro de datos de tráfico".

2.2.3 Funciones básicas del subsistema de control de acceso

La tarjeta de chip TV ejecuta varias tareas importantes para garantizar el buen funcionamiento del sistema telemático viario en su conjunto. Entre estas tareas se incluyen el lanzamiento de nuevos servicios telemáticos viarios, la comprobación de la autenticidad de un participante, la seguridad de la vía de comunicación entre el terminal de base y el centro y el cobro de peajes mediante un monedero electrónico local.

Las aplicaciones pueden dirigirse al subsistema de control de acceso (Chipcard Interface Module o CIM) a través de las siguientes funciones básicas:

1.

Apertura de la aplicación de tarjeta de chip

2.

Transferencia transparente de datos y comandos

3.

Cierre de la aplicación de tarjeta de chip.

Las funciones básicas no incluyen funciones adicionales como la activación y la desactivación de la tarjeta de chip.

Las funciones básicas que se enumeran más arriba permiten la comunicación entre las aplicaciones situadas en el terminal y el módulo de interfaz de tarjeta de chip (CIM) sin que las aplicaciones tengan que conocer el sistema operativo de las tarjetas de chip. De ahí se desprende que, por un lado, distintas aplicaciones puedan utilizar su propia tarjeta de chip diseñada específicamente; por otro lado, es posible emplear una tarjeta de chip intraGSM multifuncional que permita acceder a numerosas aplicaciones telemáticas viarias.

En principio, el CIM puede ser utilizado por varias aplicaciones al mismo tiempo.

2.2.3.1 Apertura de la aplicación de tarjeta de chip

Para abrir una aplicación de tarjeta de chip en el CIM, esta función básica necesita un identificador de aplicaciones (aid). Si la aplicación de tarjeta de chip ya está abierta o dicha aplicación no existe, se generará un mensaje de error. Esto también sucede si la tarjeta de chip no se ha insertado.

2.2.3.2 Cierre de la aplicación de tarjeta de chip

Con la ayuda de esta función básica, puede cerrarse una aplicación de tarjeta de chip. La ejecución de esta función tiene el mismo efecto que reiniciar la tarjeta, es decir, todas las condiciones de acceso en uso ("se ejecuta autentificación externa") se reiniciarán. Además, la aplicación del CIM deja de gestionarse.

2.2.3.3 Transferencia transparente de datos y comandos

Mediante esta función de tarjeta de chip, se transfieren datos y comandos (en función del sistema operativo de la tarjeta de chip) de forma transparente a la tarjeta de chip a través del CIM y los datos solicitados se leen a partir de la tarjeta y se transfieren a la aplicación, es decir, el CIM funciona únicamente como explorador de protocolos.

Los hechos inesperados, como la retirada de la tarjeta de chip durante una aplicación se indican por medio de mensajes de error. La información sobre el estado del CIM puede solicitarse en cualquier momento (aun cuando no se esté utilizando ninguna aplicación de tarjeta de chip).

2.2.4 Funciones básicas del subsistema de entrada/salida

Es necesario contar con funciones de entrada/salida para operar el terminal de base. Estas sirven tanto para acceder a las aplicaciones telemáticas viarias como para administrar el terminal de base. Se recomienda que el número de unidades de entrada/salida se mantenga a un mínimo. Además, debe ser posible implementar dispositivos adicionales de entrada/salida, en función de los requisitos de las aplicaciones individuales. Dichos dispositivos externos de entrada/salida pueden conectarse a través de la SCI y pueden ser utilizados tanto por aplicaciones internas como externas.

Asimismo, es deseable que también puedan utilizarse las unidades de entrada/salida ya existentes en el interior del vehículo. Por ejemplo, podrá emplearse una radio con RDS o cualquier otra solución específica del vehículo como dispositivo de entrada/salida. Estos dispositivos se controlan también a través de la SCI, por medio de los comandos de la función API. Los dispositivos de entrada/salida disponibles deben cumplir con los requisitos de la aplicación en cuanto a funcionalidad, ergonomía y adecuación al uso para poder garantizar un funcionamiento correcto de la aplicación.

Los componentes individuales del terminal de base ya pueden estar provisto de por sí de la posibilidad de actuar como entrada y salida, por ejemplo, puede implementarse un teléfono móvil GSM en el terminal. Es deseable utilizar estos módulos como unidades de entrada/salida. Evidentemente, debido a la realidad física del dispositivo, el lugar donde se instale y la ergonomía del usuario, existirán restricciones a la operación.

Deberán suministrarse datos técnicos para que las diferentes aplicaciones puedan acceder a las varias unidades de entrada/salida. Por este motivo, las funciones de entrada/salida se combinan con las funciones básicas y están a disposición de las aplicaciones a través de la API. Por tanto, las aplicaciones telemáticas viarias internas y externas pueden utilizar tanto las unidades de entrada/salida integradas en el terminal como las situadas externa-
mente.

El usuario dispondrá de dos funciones: por un lado la función de salida que permite presentar información en una unidad de visualización (pantalla, luz, altavoz) y, por otro lado, la función de entrada que posibilita la introducción de datos a través de una unidad de entrada (teclado, teclado de flechas, botones de control). Un intérprete interviene para garantizar un direccionamiento unificado de la unidad aun cuando existan unidades de entrada/salida más convenientes que otras. La arquitectura del subsistema de entrada/salida, compuesto de una unidad de entrada/salida y de un intérprete, se muestra en la ilustración 2.2.4-1.

Ilustración: 2.2.4-1: Ilustración de conmutación en bloque del subsistema de entrada/salida con intérprete

Ilustración 2.2.4-2: Realización posible de una unidad de entrada/salida

Como se muestra en la ilustración 2.2.4-2, la unidad de entrada/salida puede estar compuesta por distintos elementos de visualización, altavoces, etc., accesibles todos ellos a través de los comandos API.

Las funciones básicas o las aplicaciones pueden controlar, ya sea directamente o mediante la SCI, una o varias unidades de entrada/salida.

En la siguiente ilustración 2.2.4-2 se muestra la arquitectura funcional del subsistema de entrada/salida.

Ilustración 2.2.4-3: Arquitectura funcional del subsistema de entrada/salida

Existen dos funciones básicas incorporadas en el subsistema de entrada/salida ("visualización de información" y "recepción de datos de entrada"). Estas funciones pueden utilizarse para acceder al dispositivo de entrada/salida (véase la ilustración 2.2.4-3).

2.2.4.1 Función básica "visualización de información"

Cada aplicación telemática viaria posee distintos requisitos en cuanto a la presentación de información. Entre estos se incluye la presentación de gráficos, texto y símbolos, a veces acompañados de señales e información acústica. En función de los requisitos de las aplicaciones, debe ser posible utilizar dispositivos de salida en forma de displays simples de líneas, pantallas gráficas y displays de equipos externos (como es el caso de la radio con RDS, los contadores, etc.). Por tanto, es necesario disponer de una solución universal que permita presentar información en distintos tipos de pantallas. Para ello, ha de definirse un conjunto de varias clases de información. Si ha de visualizarse cierta información, se informa al intérprete del tipo de información y de datos que debe presentarse. Seguidamente, el intérprete decide qué formato se usará para mostrar la información.

Por otro lado, la información puede representarse en cadenas para poder otorgar acceso de visualización a otras aplicaciones futuras que en el momento de desarrollo del intérprete no eran concebibles. Debe tenerse en cuenta que es necesario implementar un display de ocho líneas (por ejemplo, el de una radio con RDS) como requisito mínimo. La cadenas deben presentar un formato de n*8 caracteres para la visualización estática. Delante de la cadena, se colocaré un encabezado que podrá ser utilizado por la aplicación para informar a la unidad de entrada/salida de los requisitos de formato. De nuevo será el intérprete de visualización quien decida el formato de presentación de la cadena. Para la representación de cadenas más largas, el intérprete proporciona una "función de texto corrido"; esta función debe ser compatible con el display ("desplazamiento suave").

Si una aplicación pretende presentar información en el display de la unidad de entrada/salida, transferirá esta información al subsistema de entrada/salida. A este mensaje se agregarán dos temporizadores: el primero indicará el tiempo que se supone que la información debe aparecer en pantalla (t_dur); el segundo determina la cantidad máxima de tiempo tras la cual debe ejecutarse la visualización de información (t_queue).

El subsistema de entrada/salida confirma la recepción del mensaje. Si el display solicitado está disponible y la información puede mostrarse durante un determinado tiempo t_dur, el subsistema de entrada/salida confirmará la ejecución de la solicitud de visualización.

Puesto que hay varias aplicaciones (por ejemplo, aplicaciones internas/externas, equipo periférico e instrucciones del usuario en el caso de que se use la radio con RDS como dispositivo de entrada) que tienen acceso al mismo display, debe ser posible dar prioridad a los mensajes más urgentes. Así pues, se asignan prioridades variables a los distintos tipos de información, que pueden cambiar en función del estado actual del display.

La información de baja prioridad no puede interrumpir la visualización de una información de alta prioridad. En ese caso, la información de baja prioridad espera en la cola. Si el display queda libre en el transcurso de la cantidad máxima de tiempo t_queue permitida para la visualización de la información de baja prioridad, esta información se mostrará en dicho momento; de lo contrario, se rechazará la información y se enviará el mensaje oportuno a la aplicación. Seguidamente la aplicación decide si desea reintentar la solicitud de visualización de la información. En cuyo caso, la aplicación debe almacenar la información más reciente que desee mostrar.

La información de alta prioridad puede interrumpir la visualización de la información de baja prioridad y mostrarse inmediatamente. De nuevo, la información de baja prioridad espera en la cola. Cuando se ha completado la visualización de la información de alta prioridad, se restaura la información interrumpida siempre y cuando no haya transcurrido la cantidad de tiempo máximo t_queue permitida para la visualización de información de baja prioridad. Si no es así, no se recuperará la visualización interrumpida y se informará de ello a la aplicación. Nuevamente la aplicación puede reintentar la solicitud de visualización de la información si así lo decide.

Si es necesario interrumpir una visualización, debe garantizarse no obstante que la información aparezca durante un espacio mínimo de tiempo. La secuencia de eventos precisa se describe en el capítulo 3.2.6 que sigue más adelante.

2.2.4.2 Función básica "recepción de datos de entrada"

La función de entrada también puede utilizarse universalmente con la ayuda de un intérprete dadas las variantes de elementos operativos que se implementan. Al igual que en el caso del medio de visualización, debe hacerse una distinción entre dispositivos de entrada que cumplen los requisitos mínimos y dispositivos de entrada que ofrecen una compatibilidad óptima para aplicaciones complejas. Los requisitos mínimos para el funcionamiento interactivo de la unidad de entrada/salida, en la que puedan introducirse como mínimo letras y números, deberá especificarse en un momento posterior.

Los dispositivos de entrada son necesarios por dos motivos. En primer lugar, las aplicaciones precisan de la introducción de datos ejecutada por el usuario. En este caso, la aplicación le pide al usuario (a través del medio de visualización o por sonido) que introduzca información. En segundo lugar, el usuario puede tomar la iniciativa e introducir él mismo la información (por ejemplo, seleccionando un menú), que la unidad de entrada/salida reenvía a la aplicación correspondiente.

Si ha sido la aplicación la que ha solicitado la introducción de información, el subsistema de entrada/salida puede determinar a qué lugar debe enviar la información desde la dirección del usuario. En caso de que haya sido el usuario quien inició el proceso, la información sólo podrá enviarse a aquellas aplicaciones que conozca el intérprete (por definición o porque se ha registrado la aplicación). En función de la disponibilidad de las unidades de entrada/salida, el subsistema de entrada/salida proporciona una guía de usuario adecuada para la información introducida iniciada por el usuario; también controla las solicitudes del usuario y sigue sus comandos. En función de cómo se hayan implementado efectivamente los dispositivos, el usuario podrá ver todas las aplicaciones disponibles en la pantalla antes de decidirse por un menú.

Si una aplicación recibe el mensaje "menú", transferirá todos los elementos de su menú principal (si están disponibles) al subsistema de entrada/salida. Este procedimiento es necesario porque, de lo contrario, no es posible presentar de forma adecuada en un display grande una selección de elementos de menú. Al igual que el resto de solicitudes de introducción de información, los elementos de menú se transferirán como tipos de información definidos. Además, es posible transferir uno o varios elementos de menú como secuencia de caracteres ASCII. En caso de que el usuario se haya decidido por un elemento, el número del submenú se enviará a la aplicación escogida como resultado de la información introducida. Seguidamente, la aplicación transfiere todos los elementos de menú del submenú (si están disponibles) al subsistema de entrada/salida. Este procedimiento se repite hasta que el usuario ha alcanzado el nivel de menú más bajo, se ha decidido por un elemento de menú o ha solicitado la guía de
menús.

Si una aplicación desea pedir al usuario que introduzca información, ésta debe ocupar el medio de introducción de datos. Si el medio está disponible y no lo ha ocupado ya otra aplicación, lo ocupará el subsistema de entrada/salida por indicación de la aplicación que emitió la solicitud, es decir, dejará de estar disponible para las solicitudes de introducción de información que hagan otras aplicaciones. Seguidamente la aplicación envía una solicitud de introducción de información al subsistema de entrada/salida, que se indica al usuario bien óptica o acústicamente. La introducción de información que realiza el usuario se transfiere a la aplicación. Una vez que se ha completado la interacción entre el usuario y la aplicación, la aplicación libera el medio de introducción de información.

Puede darse una situación en la que el medio de introducción de información ya esté ocupado por la solicitud de una aplicación o por un usuario que esté introduciendo información. Todas las solicitudes de introducción de información tienen la misma prioridad, es decir, una solicitud no puede interrumpir a otra. Si el medio de introducción de información está ocupado, la aplicación recibe un mensaje negativo. En ese momento depende de la aplicación el repetir la solicitud de introducción de información posteriormente.

Las solicitudes de introducción de información pueden interrumpirse por solicitudes de salida de información de una prioridad más alta. Si eso ocurre, el subsistema de entrada/salida es responsable de almacenar, mientras dure la interrupción, la solicitud de introducción de información y la información misma que el usuario ha introducido hasta ese momento. Si la prioridad de la solicitud de salida cambia o disminuye hasta ser inferior a la de la solicitud de introducción, vuelve a presentarse. Las solicitudes de introducción y de salida de información se tratan de forma distinta porque es importante que el procedimiento de introducción pueda interrumpirse si es necesario mostrar información de alta prioridad (por ejemplo, datos de tráfico entrantes), mientras que la interrupción de las solicitudes de introducción de información sólo podrían confundir al usuario. De nuevo, es importante asegurarse de que la información se muestre durante determinado tiempo, incluso en el caso de interrupciones. Además, todo cambio de información debe tener en cuenta la ergonomía y debe ser fácilmente reconocible por el usuario.

La secuencia de eventos precisa se describe en el capítulo 3.2.6 que se incluye más adelante.

2.2.5 Funciones generales de enrutamiento y control del sistema 2.2.5.1 Enrutamiento

El enrutamiento es la función central del terminal de base. Enlaza la interfaz API con las funciones básicas. Ejecuta las tareas de distribución de información en las siguientes direcciones: de las aplicaciones a las funciones básicas; de las funciones básicas a las aplicaciones; entre aplicaciones, y entre funciones básicas.

Las distintas aplicaciones tienen acceso conjunto a las funciones básicas, motivo por el cual debe coordinarse el acceso a las funciones básicas.

Enrutamiento de los servicios de las aplicaciones a las funciones básicas

Todos los mensajes enviados por los servicios de las aplicaciones se transmiten a las funciones básicas correspondientes. La dirección de la función básica se incluye en el encabezamiento del superframe que se transmite a través de la interfaz API (véase el capítulo 3.2.1).

Si una aplicación intenta acceder a un componente defectuoso del Terminal, recibirá un mensaje de error emitido por el control del sistema.

Enrutamiento de las funciones básicas a los servicios de las aplicaciones

La información que ha de transmitirse desde las funciones básicas a los servicios de las aplicaciones incluye: información generada por las propias funciones básicas; información entrante de centros externos (en el subsistema de comunicación); datos introducidos por el usuario o iniciados por la aplicación (en el subsistema de entrada/salida).

El enrutamiento se lleva a cabo mediante una asignación interna de direcciones; su función consiste en evaluar y reenviar direcciones de fuente y destino contenidas en el superframe de un mensaje (véase el capítulo 3.2.1).

Si la función de enrutamiento recibe un mensaje de un centro de servicios a través de un módulo GSM, debe evaluar el identificador de servicios de aplicaciones (ASI) que contiene el mensaje (el ASI es igual para todos los centros de servicios y todas las aplicaciones del terminal) y determinar la dirección de destino adecuada del terminal para reenviar el mensaje. En caso de que se transmita un mensaje desde una aplicación del terminal a un centro de servicios,
el procedimiento es el mismo, es decir, el mensaje del ASI debe evaluarse para reenviar el mensaje al centro correcto.

Enrutamiento entre aplicaciones

Si el encabezado del frame recibido a través de la interfaz API contiene la dirección de un identificador de aplicaciones, el mensaje se transmite a la aplicación a la que va dirigido. En ese caso no pasa por la función básica.

Enrutamiento entre funciones básicas

En un principio es posible intercambiar mensajes entre funciones básicas. Por ejemplo, la información de estado relativa al módulo GSM (por ejemplo, fuerza de la señal) puede transmitirse directamente al subsistema de entrada/
salida.

2.2.5.2 Control del sistema

Para que funcione el terminal de base es necesario contar con funciones que se ejecuten independientemente de las aplicaciones telemáticas viarias. Estas funciones son: inicialización del sistema; inicialización y control de las aplicaciones; orientación y control de estados (hardware y software); test integrado y diagnóstico; gestión de la potencia (arranque en caliente, arranque en frío, apagado, apagado de emergencia); gestión de versiones de software; gestión de errores.

Será el fabricante quien implementará la mayoría de las funciones de acuerdo con la estructura del terminal. Las funciones básicas de este complejo de funciones todavía deben describirse en detalle.

Gestión de errores

La gestión de errores cubre todas las medidas que se toman para reconocer, registrar y corregir errores e informar al usuario. Incluye las solicitudes de estado y el control del estado del hardware, de las funciones básicas y las aplicaciones. Además, una vez que se reconocen los errores, se toman medidas, si es posible, para corregirlas (por ejemplo, reiniciar y restablecer).

El perro guardián supervisa todas las aplicaciones que se han registrado y, si es necesario, las restablece.

Mantenimiento de un protocolo de errores

Es necesario implementar una función básica para registrar los errores que se produzcan en el terminal base.

Si se descubre un error, se informa a la función básica. En ese momento se transfieren parámetros que se archivan en el protocolo de errores.

Los posibles parámetros son: sello de tiempo; código de error; clasificación del error; componente defectuoso (unidad de hardware, módulo de software), y medidas aplicadas para solventar el error.

El libro de registros de errores puede ser leído por un punto de servicio. Los datos se transfieren a través de la SCI (interfaz estándar de comunicaciones).

Los mecanismos y el parámetro del protocolo de errores todavía deben determinarse.

2.2.6 Gestión de prioridades

Se hace necesario contar con una gestión de prioridades cuando son varias las aplicaciones que desean acceder al mismo recurso. Aparte de los recursos internos del sistema, como la memoria y el tiempo de computación, las aplicaciones también deben poder acceder a las funciones básicas. La gestión de los recursos internos la lleva a cabo el sistema operativo, por lo que en la presente especificación no recibirá mayor atención.

El concepto de este sistema se basa en la premisa de que las aplicaciones deberían poseer un acceso independiente a las funciones básicas y que varias aplicaciones deberían poder utilizar estas funciones al mismo tiempo. Para crear un sistema de estas características (por ejemplo, aplicaciones y sistemas multitareas), es necesario que se cumpla una serie de requisitos.

La gestión de prioridades garantiza que, en caso de producirse una llamada a las funciones básicas de alta prioridad, puedan ajustarse las asignaciones de recursos existentes dentro del sistema para que se cumplan las exigencias de la situación actual.

Las funciones básicas que regulan el acceso a los recursos están sujetas a la gestión de prioridades. Los recursos que deben tenerse en cuenta son los siguientes: el subsistema de comunicación; el subsistema de control de acceso; el subsistema de entrada/salida; la interfaz estándar de comunicaciones (SCI).

El subsistema de ubicación no está sujeto a la gestión de prioridades.

El subsistema de prioridades puede implementarse individualmente para cada recurso o centralmente para todas las llamadas a funciones básicas en función de factores tales como el diseño y la realización del software, el sistema operativo, etc. Sin embargo, esto no puede ni debe especificarse en este momento.

Deberán configurarse normas para garantizar que sólo se permita la ejecución de determinadas aplicaciones de alta prioridad. Estas normas las deberán seguir, además, las aplicaciones conectadas a través de SCI.

3 Interfaz de programación de aplicaciones 3.1 Introducción

La interfaz de programación de aplicaciones (API)^{1} es una interfaz abierta, accesible y utilizable para todo proveedor que cumpla con los requisitos de la especificación API. La API permite la implementación de aplicaciones actuales y futuras. Dichas aplicaciones pueden ser específicas de cada fabricante y estar integradas como parte del dispositivo de base IntraGSM para crear un dispositivo rentable. Sin embargo, el dispositivo de base debe estar equipado de una interfaz potente conforme con las especificaciones API para poder servir a otras aplicaciones fabricadas por otros proveedores. La API es compatible con las siguientes interacciones de comunicación:

1. desde los subsistemas del dispositivo de base a los módulos de las aplicaciones

2. desde los módulos de las aplicaciones a los subsistema del dispositivo de base

3. desde los centros de servicio a los módulos de las aplicaciones (a través del subsistema de comunicación)

4. desde los módulos de las aplicaciones a los centros de servicio (a través del subsistema de comunicación)

5. entre módulos de aplicaciones del mismo fabricante y entre módulos de aplicaciones de distintos fabricantes (es decir, algoritmo de waypoint es utilizado conjuntamente por la orientación de rutas dinámicas de los módulos de las aplicaciones y la adquisición de datos flotantes del vehículo).

Aparte de la interfaz del software, se especifica una interfaz de software universal rentable, la interfaz estándar de comunicaciones (SCI). La SCI amplía las capacidades de procesamiento y las funciones de la configuración del dispositivo de base añadiendo servicios extra.

Las funciones básicas de los distintos subsistemas se inicializan por llamadas a la API que se definen en las siguientes secciones como "mensajes". Estas llamadas poseen una estructura de frame especial que se denomina estructura de superframe de API.

3.2 Estructura de frame de API

Los superframes se utilizan para el intercambio de datos entre aplicaciones, entre funciones básicas y entre unas y otras. Los superframes contienen los mensajes que se transmitirán a través de la API. Todos los superframes constan de un encabezado y de un mensaje. Todos los frames tienen la misma estructura de encabezado generada bien por la aplicación o bien por la función básica. Cada mensaje posee una estructura general con un conjunto de parámetros que dependen del tipo de mensaje (messagetype).

\newpage

3.2.1 Estructura de los superframes

Estructura general:

<SRC>, <DEST>, <TRANS_NO>, <PRIO>, <TIME>, <message>

Descripción:

<SRC>: es el identificador de la fuente del superframe. Indica la aplicación o la función básica que inició la transferencia del superframe.

<DEST>: es el identificador del destino del superframe. Indica la aplicación o la función básica que ha de recibir el superframe.

<TRANS_NO>: el número de transacción es un número de serie. Se utiliza dentro de las respuestas como referencia unívoca de un comando recibido previamente. Además, resulta útil cuando varias aplicaciones utilizan una única línea de conexión GSM (acceso múltiple).

<PRIO>: es el indicador de prioridad de un superframe. Debe ser evaluado por la gestión de prioridades para resolver conflictos en caso de un acceso concurrente a la misma función básica. El indicador de prioridad no se evalúa en mensajes enviados desde funciones básicas a aplicaciones. Además, tampoco se evalúa en mensajes relacionados con el subsistema de ubicación.

<TIME>: es el sello de tiempo que se utiliza para el cambio de nivel de prioridad dependiente del tiempo o para la función de perro guardián.

<message>: es el mensaje que debe transmitirse a través de la API y debe procesarse en la aplicación o la función básica a la que esté dirigido. El mensaje posee una estructura específica en función del módulo; dicha estructura se describe en secciones individuales.

Los valores de los superframes se definen en el apéndice 4.

\vskip1.000000\baselineskip

3.2.2 Estructura general de los mensajes

Los mensajes de los superframes tienen una estructura individual.

En términos generales, cada mensaje posee: un nombre (por ejemplo, "cim_data_transfer_req"), un identificador de mensaje y una lista de parámetros (opcional).

Cada nombre de mensaje posee un prefijo característico:

gsm_

para los mensajes relacionados con GSM

gps_

para los mensajes relacionados con GPS

cim_

para los mensajes del módulo de interfaz de tarjeta de chip

io_

para los mensajes relacionados con entrada/salida

Cada mensaje tiene además un sufijo característico:

_req

para las solicitudes

_res

para las respuestas (es decir, las respuestas a una solicitud)

_con

para las confirmaciones (por ejemplo, como respuesta inmediata)

_ack

para los reconocimientos (cuando se ha ejecutado una solicitud)

_ind

para las indicaciones (es decir, indicaciones espontáneas de acontecimientos)

_rej

para los rechazos (por ejemplo, de la gestión de prioridades)

La estructura general del mensaje es:

<msg_id>, [<par_1>, [<par_2,... [<par_n>]]]

Descripción:

<msg_id>: el identificador unívoco del mensaje. Se propone como el valor de bytes.

<par_x>: el parámetro o los parámetros del mensaje, tantos como sean necesarios.

\vskip1.000000\baselineskip

3.2.3 Mensajes relacionados con el subsistema de comunicación

Las siguientes secciones describen los mensajes utilizados para solicitar funciones básicas relacionadas con GSM, sus respuestas y las indicaciones no solicitadas generadas por las funciones básicas o recibidas por el centro de aplicaciones.

Se recomienda utilizar servicios GSM que sigan las directrices de GSM 07.07[2] y GSM 07.05[3].

En la API pueden permitirse un conjunto de comandos que utilicen el conjunto de comandos AT descritos en las Recomendaciones GSM 07.05 y 07.07, aunque no se describan aquí (por ejemplo, el comando +CPIN, que envía una contraseña al módulo GSM), ya que no se hace referencia a dichos comandos en la presente especificación.

Las actividades de GSM se ocupan de entradas de la tabla de servicios de comunicaciones suministradas por el subsistema de comunicaciones. La tabla de servicios muestra qué servicios de datos están disponibles en cada momento y cuáles están implementados en el dispositivo de comunicación.

Todos los mensajes incluyen el prefijo gsm_... para indicar que los parámetros del mensaje son adecuados para el uso de la comunicación GSM. Los mensajes para otros dispositivos de comunicación, como Inmarsat o mobiltex, deben definirse. Pueden utilizar exactamente la misma estructura pero pueden precisar de distintos parámetros de mensaje.

La transferencia de mensajes entre aplicaciones y funciones básicas GSM se controla a través de los siguientes mensajes:

Relacionados con el diálogo GSM con la función básica GSM

- gsm_open_request

- gsm_open_confirmation

- gsm_open_indication

- gsm_open_response

- gsm_data_request

- gsm_data_confirmation

- gsm_data_indication

- gsm_status_indication

- gsm_close_request

- gsm_close_confirmation

- gsm_close_indication

Relacionados con el acceso indirecto por comando AT GSM de la función básica GSM

- gsm_AT_command_request

- gsm_AT_command_response

Relacionados con el acceso a la tabla de servicios de comunicaciones GSM de la función básica GSM

- gsm_write_service_table_request

- gsm_read_service_table_request

- gsm_read_service_table_response

Algunos ejemplos de transferencias de mensajes entre una aplicación y una función básica GSM se describen en los diagramas de secuencia temporal de las siguientes páginas.

Ilustración 3.2.3-1: Diagrama de secuencia temporal relacionado con el diálogo GSM de la función básica GSM

Ilustración 3.2.3-2: Diagrama de secuencia temporal relacionado con el diálogo GSM de la función básica GSM

Ilustración 3.2.3-3: Diagrama de secuencia temporal relacionado con el diálogo GSM de la función básica GSM

Ilustración 3.2.3-4: Diagrama de secuencia temporal relacionado con el diálogo GSM de la función básica GSM

Ilustración 3.2.3-5: Diagrama de secuencia temporal relacionado con el diálogo GSM de la función básica GSM

Ilustración 3.2.3-6: Diagrama de secuencia temporal relacionado con el diálogo GSM de la función básica GSM.

\vskip1.000000\baselineskip

3.2.3.1 Mensaje "gsm_open_request"

Nombre del mensaje:

"gsm_open_request"

Origen:

aplicación

Destino:

diálogo GSM de función básica

Respuesta:

"gsm_open_confirmation"

{}\hskip0,4cm Descripción: \hskip1,4cm Este mensaje lo utiliza la aplicación para iniciar una comunicación con el centro de servicios. En cualquier caso, ya se use un servicio portador, un servicio de mensajería corta o un servicio general de radio por paquetes, este mensaje se emplea antes de enviar datos.

\vskip1.000000\baselineskip

Si el intento de establecer una conexión no produce resultados, la función básica debe evaluar y/o reenviar los motivos del error (por ejemplo, causas de error de red descritas en GSM TS 04.08, tabla 10.86) y reaccionará en consonancia con GSM TS 02.07.

Al recibir la función básica este mensaje, se establece un canal lógico de comunicación entre la aplicación y la función básica. Debe enviarse un mensaje de confirmación con el número del canal lógico o con la causa de error posible a la aplicación solicitante. Si la aplicación desea comunicarse mediante SMS, se genera el mensaje "gsm_open_con" inmediatamente después de recibir el mensaje "gsm_open_req". Si se debe emplear BS2X para la comunicación, debe establecerse la conexión del centro de servicios solicitado antes de poder enviar el mensaje "gsm_open_con" a la aplicación solicitante.

Si se produce un error se envía el mensaje "gsm_status_ind" a la aplicación solicitante.

El mensaje contiene el identificador de mensaje <msg_id>, el identificador de servicio de aplicaciones <asi>, el servicio de comunicaciones <service>, el número marcado <dial_string> y en caso de los servicios portadores, los parámetros <speed>, <name> y >ce>. Los elementos de datos <speed>, <name> y <ce> y sus posibles valores corresponden al capítulo 6.7 de GSM 07.07. En caso de SMS, el mensaje contiene la dirección del centro de SMS <SMS_center_address>.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <asi>, <service>, <dial_string>, <speed>, <name>, <ce>, <SMS_center_address>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<asi>

identificador de servicios de aplicaciones

\quad

Deben definirse los valores de todas las aplicaciones telemáticas viarias posibles. Como mínimo deben definirse los valores de: orientación dinámica de rutas; adquisición de datos flotantes del vehículo; gestión de flotas; información del tráfico; servicios de averías de emergencia; protección antirrobo del vehículo; pago de peajes automatizado

\newpage

<service>

servicio que ha de usarse para la comunicación

\quad

Se recomiendan los valores: 0 - servicio portador (requiere los valores de <dial_string>, <speed>, <name>, <ce>); 1 - SMS (requiere los valores de <dial_string>,

\quad

<SMS_center_address>)

<dial_string>

número de marcado del centro de servicios solicitado

<speed>

selección de la velocidad de transmisión de datos e información

\quad

Los valores recomendados (como se define en el capítulo 6.7 de GSM 07.07) son:

\quad

4 - 2.400 bps (V.22bis)

\quad

7 - 9.600 bps (V.32)

\quad

68 - 2.400 bps (V.110)

\quad

71 - 9.600 bps (V.110)

<name>

selección del nombre del servicio portador

\quad

Los valores recomendados (como se define en el capítulo 6.7 de GSM 07.07) son:

\quad

0 - módem asíncrono

<ce>

selección del elemento de conexión

\quad

Los valores posibles (como se define en el capítulo 6.7 de GSM 07.07) son:

\quad

0 - transparente

\quad

1 - no transparente

<SMS_center_address> número de marcado del centro de SMS solicitado.

\vskip1.000000\baselineskip

3.2.3.2 Mensaje "gsm_open_confirmation"

Nombre del mensaje:

"gsm_open_con"

Origen:

diálogo GSM de función básica

Destino:

aplicación solicitante

{}\hskip0,4cm Descripción: \hskip1,4cm Este mensaje se utiliza para confirmar que se abierto un canal lógico para la aplicación solicitante con el fin de enviar datos al centro de servicios (con un mensaje "gsm_data_req"). El mensaje "gsm_open_con" contiene un número de canal <channel_no>. Este <channel_no> lo utilizan los mensajes siguientes para dirigirse al canal lógico de comunicación.

\vskip1.000000\baselineskip

En caso de que se produzcan problemas sin solución, por ejemplo, no se ha establecido la conexión tras un número determinado de reintentos, la función básica indica el motivo del fallo con un mensaje "gsm_status_ind". Así pues, si no se ha abierto ningún canal lógico, no se envía ningún mensaje "gsm_open_con" a la aplicación.

Sintaxis:

<msg_id>, <channel_no>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<channel_no>

identificador del canal lógico de comunicación de la comunicación solicitada.

\vskip1.000000\baselineskip

3.2.3.3 Mensaje "gsm_open_indication"

Nombre del mensaje:

"gsm_open_ind"

Origen:

diálogo GSM de función básica

Destino:

aplicación

{}\hskip0,4cm Descripción: \hskip1,4cm Este mensaje lo utiliza la función básica para indicarle a la aplicación de destino que un centro de servicios desea enviar datos.

\vskip1.000000\baselineskip

Si el centro de servicios origina una comunicación de conexión, la función básica recibe un identificador para la aplicación de destino. Seguidamente la función básica abre un canal lógico hacia esta aplicación y envía el número de canal. La aplicación debe confirmar el mensaje con el mensaje de respuesta "gsm_open_res", que transfiere la función básica al centro de servicios solicitante.

Si el terminal telemático viario recibe una llamada del centro de servicios a través de SMS, la función básica también establece un canal lógico de comunicación con la aplicación de destino. De nuevo, la aplicación debe dar su confirmación con el mensaje "gsm_open_res" antes de que la función básica indique los datos.

Sintaxis:

<msg_id>, <channel_no>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<channel_no>

identificador del canal lógico de comunicación de la comunicación solicitada.

\vskip1.000000\baselineskip

3.2.3.4 Mensaje "gsm_open_response"

Nombre del mensaje:

"gsm_open_res"

Origen:

aplicación

Destino:

diálogo GSM de función básica

{}\hskip0,4cm Descripción: \hskip1,4cm Este mensaje se utiliza para confirmar a la función básica que la aplicación está preparada para recibir un mensaje del centro de servicios.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <channel_no>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<channel_no>

identificador del canal lógico de comunicación de la comunicación solicitada.

\vskip1.000000\baselineskip

3.2.3.5 Mensaje "gsm_data_request"

Nombre del mensaje:

"gsm_data_req"

Origen:

aplicación

Destino:

diálogo GSM de función básica

Respuesta:

"gsm_data_con"

{}\hskip0,4cm Descripción: \hskip1,4cm Con este mensaje se envían los datos que van a enviarse al centro de servicios a la función básica.

\vskip1.000000\baselineskip

En caso de que la transmisión se complete correctamente, se envía un mensaje "gsm_data_confirmation" a la aplicación.

\newpage

En caso de que los datos no puedan transmitirse correctamente incluso con la ayuda del mecanismo de reintentos, se envía un mensaje "gsm_status_ind" a la aplicación.

Sintaxis:

<msg_id>, <channel_no>, <data_length>, <data>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<channel_no>

identificador del canal lógico de comunicación de la comunicación solicitada

<data_length>

extensión de los datos (<data>) en bytes

<data>

datos que van a enviarse al centro de servicios.

\vskip1.000000\baselineskip

3.2.3.6 Mensaje "gsm_data_confirmation"

Nombre del mensaje:

"gsm_data_con"

Origen:

diálogo GSM de función básica

Destino:

aplicación solicitante

{}\hskip0,4cm Descripción: \hskip1,4cm Este mensaje se utiliza para confirmarle a la aplicación solicitante que los datos se han enviado al centro de servicios.

\vskip1.000000\baselineskip

Si los datos se transmiten por medio de SMS, se envía un mensaje "gsm_data_con" a la aplicación cuando el centro de servicios de SMS reconoce el mensaje transmitido. Si los datos se transmiten por medio de una comunicación de conexión, el protocolo punto a punto se encarga de dar la confirmación de la entrega al centro de servicios.

Sintaxis:

<msg_id>, <channel_no>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<channel_no>

identificador del canal lógico de comunicación de la comunicación solicitada.

\vskip1.000000\baselineskip

3.2.3.7 Mensaje "gsm_data_indication"

Nombre del mensaje:

"gsm_data_ind"

Origen:

diálogo GSM de función básica

Destino:

aplicación

{}\hskip0,4cm Descripción: \hskip1,4cm Con este mensaje se informa a una aplicación de la recepción de un mensaje procedente de un centro de servicios. El centro de servicios es quien ha iniciado la conexión para enviar los datos a una aplica-
ción.

\vskip1.000000\baselineskip

La función básica recibe estos datos del centro de servicios e identifica la aplicación de destino. Si ya hay un canal lógico abierto con esta aplicación, los datos se transmiten a través de dicho canal. Si no hay un canal abierto, la función básica debe establecer un canal. Con este nuevo canal, los datos recibidos se transmiten a la aplicación.

Cuando dentro de una comunicación existente, un centro de servicios envía datos al equipo del terminal, la función básica recibe estos datos e identifica la aplicación de destino a la que debe enviar los datos.

Si dentro de una comunicación existente, la aplicación de destino ya posee un canal de comunicación abierto, este número canal forma parte del mensaje "gsm_data_ind". Si la aplicación de destino no tiene canal de comunicación abierto, la función básica debe generar un canal lógico de comunicación nuevo.

Cuando un centro de servicios origina una comunicación de conexión, la función básica confirma la conexión automáticamente y genera un canal lógico de comunicación hacia la aplicación de destino. Después de que el centro de servicios ha enviado los datos, la función básica envía el mensaje "gsm_data_ind" a la aplicación de destino.

Cuando un centro de servicios origina una comunicación sin conexión, la función básica recibe los datos, genera un canal lógico de comunicación nuevo y envía un mensaje "gsm_data_ind" a la aplicación de destino. A continuación, la aplicación remite un mensaje "gsm_get_data_con" a la función básica a modo de confirmación. La función básica no envía un mensaje de confirmación al centro de servicios. Únicamente la aplicación debe decidir si el centro de servicios precisa de confirmación y, en caso necesario, debe iniciar una nueva comunicación.

El mensaje contiene el identificador de mensaje <msg_id>, el tipo de datos <data_type>, la extensión de los datos <data_length>, los datos propiamente dichos <data> y el número de canal <channel_no>

Sintaxis:

<msg_id>, <channel_no>, <data_length>, <data>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<channel_no>

identificador del canal lógico de comunicación de la comunicación solicitada

<data_length>

extensión de los datos (<data>) en bytes

<data>

datos que van a enviarse al centro de servicios.

\vskip1.000000\baselineskip

3.2.3.8 Mensaje "gsm_status_indication"

Nombre del mensaje:

"gsm_status_ind"

Origen:

diálogo GSM de función básica

Destino:

aplicación

{}\hskip0,4cm Descripción: \hskip1,4cm Este mensaje se utiliza para informar a la aplicación de un error (valores conformes a GSM TS 04.08, tabla 10.86 y GSM TS 07.07 sección 9.2), de que se ha producido una acción inesperada o un cambio de estado en el equipo.

\vskip1.000000\baselineskip

Al recibir el mensaje "gsm_status_ind", la aplicación debe decidir qué acción tomar a partir de ese momento.

El mensaje incluye el identificador de mensaje <msg_id>, la información de estado <status> y el número de canal <channel_no> (si está disponible).

Sintaxis:

<msg_id>, <channel_no>, <status>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<channel_no>

identificador del canal lógico de comunicación de la comunicación solicitada

<status>

información de estado relativa al error, a la acción imprevista o al estado del equipo. Los valores posibles se definen en el apéndice 1: \alm{3} - información de estado.

\vskip1.000000\baselineskip

3.2.3.9 Mensaje "gsm_close_request"

Nombre del mensaje:

"gsm_close_req"

Origen:

aplicación

Destino:

diálogo GSM de función básica

Respuesta:

"gsm_close_con"

\quad

"gsm_status_ind"

{}\hskip0,4cm Descripción: \hskip1,4cm La aplicación utiliza este mensaje para cerrar el canal lógico de comunicación entre la aplicación y la función básica. Si no hay otra vía de comunicación (canal lógico) abierta, la línea de comunicación conectada se desconecta inmediatamente.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <channel_no>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<channel_no>

identificador del canal lógico de comunicación de la comunicación solicitada.

\vskip1.000000\baselineskip

3.2.3.10 Mensaje "gsm_close_confirmation"

Nombre del mensaje:

"gsm_close_con"

Origen:

diálogo GSM de función básica

Destino:

aplicación

{}\hskip0,4cm Descripción: \hskip1,4cm Este mensaje se utiliza para confirmar a la aplicación solicitante que el canal lógico de comunicación entre la aplicación y la función básica se ha cerrado. La comunicación con el centro de servicios se finaliza en caso de que no haya otra vía de comunicación abierta (canal lógico).

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <channel_no>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<channel_no>

identificador del canal lógico de comunicación de la comunicación solicitada

\vskip1.000000\baselineskip

3.2.3.11 Mensaje "gsm_close_indication"

Nombre del mensaje:

"gsm_close_ind"

Origen:

diálogo GSM de función básica

Destino:

aplicación

{}\hskip0,4cm Descripción: \hskip1,4cm La función básica usa este mensaje para indicar a una aplicación que se ha finalizado la comunicación con el centro de servicios identificada por el número de canal lógico correspondiente.

\vskip1.000000\baselineskip

Si un centro de servicios desea desconectar una comunicación basada en conexión, se envía una solicitud de cierre al terminal telemático viario. Cuando el protocolo punto a punto de la función básica recibe dicha solicitud, se envía inmediatamente una confirmación al centro de servicios. Para indicar la desconexión, se envía un mensaje "gsm_close_ind" a la aplicación correspondiente. Seguidamente, se cierra el canal lógico.

Cuando en una comunicación sin conexión no se reciben datos durante un periodo de tiempo determinado "t", también se envía un mensaje "gsm_close_ind" a la aplicación pertinente para cerrar el canal lógico de comunicación.

Sintaxis:

<msg_id>, <channel_no>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<channel_no>

identificador del canal lógico de comunicación de la comunicación solicitada.

\vskip1.000000\baselineskip

3.2.3.12 Mensaje "gsm_AT_command_request"

Nombre del mensaje:

"gsm_AT_command_req"

Origen:

aplicación

Destino:

acceso indirecto por comando AT de la función básica GSM

Respuesta:

"gsm_AT_command_res"

{}\hskip0,4cm Descripción: \hskip1,4cm La aplicación utiliza este mensaje para enviar un comando AT a un función básica GSM de forma transparente. Los comandos AT deben ser conformes a la recomendación GSM 07.05 y 07.07. Para enviar un mensaje gsm_AT_command_req no se solicita ningún canal lógico. El comando puede emplearse en paralelo a otros canales abiertos.

\vskip1.000000\baselineskip

Este comando no permite todos los comandos AT. Por ejemplo, el comando ATD sólo puede generarlo la función básica tras un mensaje gsm_open_request (véase el apéndice 2)^{2}.

Sintaxis:

<msg_id>, <cmd_len>, <AT_command>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<cmd_len>

extensión del comando que sigue

<AT_command>

comando AT que se enviará a la función básica. El conjunto de comandos posibles es el recomendado en el apéndice 2.

\vskip1.000000\baselineskip

3.2.3.13 Mensaje "gsm_AT_command_response"

Nombre del mensaje:

"gsm_AT_command_res"

Origen:

acceso indirecto por comando AT de la función básica GSM

Destino:

aplicación interesada

{}\hskip0,4cm Descripción: \hskip1,4cm Las funciones básicas GSM utilizan este mensaje para enviar de modo transparente la respuesta de un comando AT recibido por el módulo GSM a la aplicación correspondiente.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <data_length>, <data>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<data_length>

extensión de los datos (<data>) en bytes

<data>

datos que va a enviar la función básica.

\vskip1.000000\baselineskip

3.2.3.14 Mensaje "gsm_write_service_table_request"

Nombre del mensaje:

"gsm_write_service_table_req"

Origen:

aplicación

Destino:

acceso a la tabla de servicios de comunicación de la función básica GSM

{}\hskip0,4cm Descripción: \hskip1,4cm Este mensaje se utiliza para escribir/cambiar el contenido de la tabla de servicios de comunicación controlada por la función básica. Para enviar este mensaje no es necesario contar con un canal lógico. El comando puede usarse en paralelo con canales abiertos.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <object>, <service>, <status>, <data>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<object>

selector de <services>. Los valores recomendados son: 1 - red; 2 - módulo GSM; 3 - abonado; 4 - contador de rellamadas; 5 - identidad de línea llamante de la aplicación del centro de servicios

\newpage

<service/dial_string> selector del servicio o de la información de dial_string. Los valores solicitados recomendados son:

\quad

en caso de que el valor <object> sea 1, 2 o 3, se puede establecer la disponibilidad de: BS24; BS26; TS11; TS21; TS22; TS23; GPRS/PDS; CLIP; CLIR; COLP; COLR; llamada en espera

\quad

en caso de que el valor <object> sea 4, el valor de <service> es la cadena de llamada dial_string, para la cual debe establecerse el contador de rellamadas a un valor específico: dial_string para "contador de rellamadas"

\quad

en caso de que el valor de <object> sea 5, el valor de <service> es el identificador application_id, para el que debe establecerse la identidad de línea llamante: application_id para identidad de línea llamante

<data>

los datos que se escribirán en la tabla de servicios de comunicación. Los valores recomendados son:

\quad

en caso de que el valor <object> sea 1, 2 o 3: 0 - desconocido; 1 - disponible; 2 - no disponible

\quad

en caso de que el valor <object> sea 4: # - valor del contador de rellamadas

\quad

en caso de que el valor <object> sea 5: "calling_line_identity" de la aplicación del centro de servicios.

\vskip1.000000\baselineskip

3.2.3.15 Mensaje "gsm_read_service_table_request"

Nombre del mensaje:

"gsm_read_service_table_request"

Origen:

aplicación

Destino:

acceso a la tabla de servicios de comunicación de la función básica GSM

{}\hskip0,4cm Descripción: \hskip1,28cm Este mensaje se utiliza para leer datos de la tabla de servicios de comunicación, que está controlada por la función básica. El resultado se envía a la aplicación solicitante mediante el mensaje "gsm_read_servi- ce_table_ind". Para enviar este mensaje no se necesita canal lógico. El comando puede utilizarse en paralelo con los canales abiertos.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <object>, <service/dial_string>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<object>

selector de <services>. Los valores recomendados son: 1 - red; 2 - módulo GSM; 3 - abonado; 4 - contador de rellamadas; 5 - identidad de línea llamante de la aplicación del centro de servicios

<service/dial_string> selector del servicio o de la información de dial_string. Los valores solicitados recomendados son:

\quad

en caso de que el valor <object> sea 1, 2 o 3, se puede establecer la disponibilidad de: BS24; BS26; TS11; TS21; TS22; TS23; GPRS/PDS; CLIP; CLIR; COLP; COLR; llamada en espera

\quad

en caso de que el valor <object> sea 4, pueden solicitarse los valores de contador de rellamadas para un dial_string específica: dial_string para "contador de rellamadas"

\quad

en caso de que el valor de <object> sea 5, puede solicitarse la identidad de línea llamante de un centro de servicios concreto para una aplicación telemática viaria: application_id para solicitud de identidad de línea llamante.

\vskip1.000000\baselineskip

3.2.3.16 Mensaje "gsm_read_service_table_response"

Nombre del mensaje:

"gsm_read_service_table_res"

Origen:

acceso a la tabla de servicios de comunicación de la función básica GSM

Destino:

aplicación

{}\hskip0,4cm Descripción: \hskip1,2cm Este mensaje se utiliza para enviar el resultado de un mensaje "gsm_read_service_ table_req" a la aplicación solicitante.

\vskip1.000000\baselineskip

El mensaje contiene el identificador de mensaje <msg_id> y el estado del servicio solicitado <status>. Si se solicita el contador de rellamadas de un dial_string, el mensaje también incluirá el valor real del contador <counter>, la hora del último intento <time> y la causa de liberación <reason>. Si se solicita la identidad de línea llamante de un centro de servicios concreto para un aplicación telemática viaria, el mensaje también indicará la identidad de línea llamante <CLI>.

Sintaxis:

<msg_id>, <service>, <counter>, <time>, <reason>, <CLI>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<status>

estado del servicio solicitado. Los valores posibles son: 0 - desconocido; 1 - disponible; 2 - no disponible

<counter>

valor real del contador de rellamadas

<time>

hora del último intento. Los valores posibles son: [hh:mm:ss]

<reason>

causa de la liberación. Los valores posibles son: # - causas de liberación de acuerdo con las recomendaciones GSM 04.08, 07.05 y 07.07

<CLI>

identidad de línea llamante del centro de servicios del servicio telemático viario solicitado.

\vskip1.000000\baselineskip

3.2.4 Mensajes relacionados con el subsistema de ubicación

En este capítulo se describen los mensajes relacionados con las distintas funciones básicas GPS. La transmisión de mensajes entre las aplicaciones y las funciones básicas GPS se efectúa a través de los siguientes mensajes:

\vskip1.000000\baselineskip

Relacionados la función básica GPS de datos básicos GPS:

-

gps_data_start_request

-

gps_data_indication

-

gps_data_stop_request

-

gps_send_dgps_correct_indication

-

gps_data_set_height_request

-

gps_data_del_height_request

\vskip1.000000\baselineskip

Relacionados con la función básica GPS de geometría:

-

gps_geometry_request

-

gps_geometry_indication

\newpage

Relacionados con la función básica GPS de aproximación:

-

gps_approx_data_backward_request

-

gps_approx_data_backward_indication

Relacionados con la función básica GPS de waylength:

-

gps_waylength_start_request

-

gps_waylength_request

-

gps_waylength_indication

-

gps_waylength_stop_request

-

gps_waylength_global_request

-

gps_waylength_global_indication

Relacionados con la función básica GPS de waypoint:

-

gps_waypoint_start_request

-

gps_waypoint_status_indication

-

gps_waypoint_stop_request

En las siguientes páginas se describen algunos ejemplos de transferencias de mensajes entre una aplicación y una función básica GPS en diagramas de secuencia temporal.

Ilustración 3.2.4-1: Diagrama de secuencia temporal relacionado con las funciones básicas GPS de datos básicos GPS y aproximación

Ilustración 3.2.4-2: Diagrama de secuencia temporal relacionado con la función básica GPS de waylength

Ilustración 3.2.4-3: Diagrama de secuencia temporal relacionado con la función básica GPS de waypoint.

\vskip1.000000\baselineskip

3.2.4.1 Mensaje "gps_data_start_request"

Nombre del mensaje:

"gsm_data_start_req"

Origen:

aplicación (u otra función básica)

Destino:

función básica datos básicos GPS

{}\hskip0,4cm Descripción: \hskip1,4cm Este mensaje se utiliza para solicitar conjuntos de datos GPS.

\vskip1.000000\baselineskip

Si el parámetro <par> tiene el valor 0, sólo se solicita el conjunto de datos GPS actual. Si <par> es igual a 1, se solicita el conjunto de datos GPS actual y los siguientes conjuntos cada <time_diff> segundos.

Con el mapa de bits <mask>, la aplicación especifica los elementos de datos concretos de todo el conjunto de datos GPS que se necesitan.

Sintaxis:

<msg_id>, <par>, <time_diff>, <mask>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<par>

0: sólo se solicita el conjunto de datos GPS actual.

\quad

1: se solicita el conjunto de datos GPS actual y los siguientes conjuntos cada <time_diff> segundos.

<time_diff>

diferencia temporal entre dos conjuntos de datos solicitados

\newpage

<mask>

mapa de bits que indica los elementos de datos concretos solicitados por la aplicación. El conjunto de datos básicos completo consta de los siguientes elementos: fecha; hora (UTC); longitud geográfica; latitud geográfica; altitud (al nivel del mar); dilución de precisión horizontal (HDOP); error de posición estimado en dirección sur-norte (EPE(x)); error de posición estimado en dirección este-oeste (EPE(y)); velocidad horizontal absoluta; rumbo (0 grados = norte, sentido de las agujas del reloj); número de satélites teóricamente a la vista; número de satélites considerado para el cálculo de la posición; indicador de cambio de constelación de satélites (0=sin cambio, 1=cambio de constelación); tipo de posición (TOP); datos específicos del receptor; datos de pseudorrango y tasa de pseudorrango.

\vskip1.000000\baselineskip

3.2.4.2 Mensaje "gps_data_indication"

Nombre del mensaje:

"gsm_data_ind"

Origen:

función básica datos básicos GPS

Destino:

aplicación (u otra función básica)

{}\hskip0,4cm Descripción: \hskip1,3cm Este mensaje se utiliza para enviar elementos de datos concretos <data_set> pertenecientes al conjunto de datos GPS actual solicitados por la aplicación o las aplicaciones.

\vskip1.000000\baselineskip

Las posiciones del conjunto de datos GPS actual pueden ser tanto posiciones válidas medidas por el receptor GPS como posiciones aproximadas por progresión de la función básica de aproximación. Los elementos de datos concretos que se envían los elige la aplicación solicitante (véase el mensaje "gps_data_start_req") y se indican por medio del mapa de bits <mask>.

Si los elementos de datos del conjunto de datos GPS los solicita más de una aplicación, todos los elementos de datos solicitados se envían a todas las aplicaciones por medio de este único mensaje. Los elementos de datos concretos que se envían se indican por medio del mapa de bits <mask>. Cada aplicación debe seleccionar aquellos elementos de datos que ha solicitado.

Si el parámetro <par> del mensaje "gps_data_start_req" tiene el valor 1, también se envían los elementos de datos de los siguientes conjuntos de datos GPS, especificados por el mapa de bits <mask>, cada <time_diff> segundos.

Sintaxis:

<msg_id>, <mask>, <data_set>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<mask>

mapa de bits que indica los elementos de datos concretos que se envían

<data_set>

elementos de datos concretos del conjunto de datos GPS completo indicados por el mapa de bits <mask>.

\vskip1.000000\baselineskip

3.2.4.3 Mensaje "gps_data_stop_request"

Nombre del mensaje:

"gsm_data_stop_req"

Origen:

aplicación (u otra función básica)

Destino:

función básica de datos básicos GPS

{}\hskip0,4cm Descripción: \hskip1,3cm Este mensaje se utiliza para detener la transferencia de los conjuntos de datos GPS. Si hay otras aplicaciones que siguen solicitando conjuntos de datos GPS, se les sirve hasta que éstas también envían este mensaje.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>

Valores definidos:

<msg_id> \hskip1,1cm por definir.

\vskip1.000000\baselineskip

3.2.4.4 Mensaje "gps_send_dgps_correct_indication"

Nombre del mensaje:

"gps_send_dgps_correct_ind"

Origen:

aplicación o diálogo GSM de función básica

Destino:

función básica de datos básicos GPS

{}\hskip0,4cm Descripción: \hskip1,3cm Si una aplicación puede suministrar datos correctivos (DGPS), este mensaje se utiliza para enviar los datos diferenciales de las posiciones DGPS (en formato RTCM) a la función básica de datos básicos GPS.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <dgps_data>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<dpgs_data>

datos diferenciales de posiciones DGPS (en formato RTCM).

\vskip1.000000\baselineskip

3.2.4.5 Mensaje "gps_data_set_height_request"

Nombre del mensaje:

"gsm_data_set_height_req"

Origen:

aplicación (u otra función básica)

Destino:

función básica de datos básicos GPS

{}\hskip0,4cm Descripción: \hskip1,3cm Si una aplicación conoce la altura exacta de la posición GPS actual, puede suministrar esta altura exacta a través de este mensaje. Además, la aplicación envía el radio del círculo que rodea la posición actual en el cual la altura fija sigue siendo exacta.

\vskip1.000000\baselineskip

La función básica de datos básicos GPS comprueba, a partir de la evaluación de la velocidad actual y del intervalo temporal, si la posición sigue estando dentro del círculo. Si es así, fija la altura en el receptor GPS, el cual con esta información adicional es ahora capaz de generar una posición GPS más precisa.

Esta comprobación se repite con cada conjunto de datos GPS nuevo. Si la posición siguiente se encuentra fuera del círculo, la función básica elimina la altura fija en el receptor GPS. También la aplicación puede eliminar la altura fija con el mensaje "gps_data_del_height_req".

La altura fija se indica a todas las aplicaciones que soliciten conjuntos de datos GPS con el tipo de posición (TOP).

Sintaxis:

<msg_id>, <height>, <radius>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<height>

altura fijada

<radius>

radio del círculo que rodea la posición actual para la que la altura fija es exacta.

\vskip1.000000\baselineskip

3.2.4.6 Mensaje "gps_data_del_height_request"

Nombre del mensaje:

"gps_data_del_height_req"

Origen:

aplicación (u otra función básica)

Destino:

función básica de datos básicos GPS

{}\hskip0,4cm Descripción: \hskip1,3cm Con este mensaje la aplicación que ha fijado la altura de la posición GPS elimina la altura fija.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <height>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<height>

altura fija que va a eliminarse.

\vskip1.000000\baselineskip

3.2.4.7 Mensaje "gps_geometry_request"

Nombre del mensaje:

"gps_geometry_req"

Origen:

aplicación (u otra función básica)

Destino:

función básica de geometría

{}\hskip0,4cm Descripción: \hskip1,4cm Este mensaje se utiliza para solicitar la distancia o el ángulo entre dos posiciones.

\vskip1.000000\baselineskip

Con el mapa de bits <calc>, puede solicitarse el cálculo de la distancia radial, la distancia longitudinal, la distancia latitudinal y/o el ángulo entre las dos posiciones.

Si el parámetro <pos> tiene el valor 2, las dos posiciones las suministra la aplicación. Si el parámetro <pos> tiene el valor 1, una posición la proporciona la aplicación y la otra es la posición actual.

Sintaxis:

<msg_id>, <cal>, <pos>, <position>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<cal>

mapa de bits que indica los cálculos solicitados. Son posibles los siguientes cálculos: distancia radial; distancia longitudinal; distancia latitudinal; ángulo positivo entre las dos posiciones relativo al norte

<pos>

2 - las dos posiciones suministradas por la aplicación:

<position>

long1 - longitud de la posición 1

\quad

lat1 - latitud de la posición 1

\quad

long2 - longitud de la posición 2

\quad

lat2 - latitud de la posición 2

<pos>

1 - una posición es la suministrada por la aplicación y la otra es la posición actual:

<position>

long1 - longitud de la posición 1

\quad

lat1 - latitud de la posición 1.

\vskip1.000000\baselineskip

3.2.4.8 Mensaje "gps_geometry_indication"

Nombre del mensaje:

"gps_geometry_ind"

Origen:

función básica de geometría

Destino:

aplicación (u otra función básica)

{}\hskip0,4cm Descripción: \hskip1,3cm Este mensaje se utiliza para enviar los resultados del cálculo de la distancia y/o del ángulo entre dos posiciones solicitado por el mensaje "gps_geometry_req".

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <cal>, <result_data>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<cal>

mapa de bits que indica los resultados del cálculo

\newpage

<result_data>

resultado del cálculo de la distancia y/o el ángulo (véase el mensaje "gps_geometry_req").

\vskip1.000000\baselineskip

3.2.4.9 Mensaje "gps_approx_data_backward_request"

Nombre del mensaje:

"gps_approx_data_backward_req"

Origen:

aplicación (u otra función básica)

Destino:

función básica de aproximación

{}\hskip0,4cm Descripción: \hskip1,3cm Tras haber estado recibiendo posiciones no válidas o aproximadas por progresión, al producirse la primera posición válida de nuevo, una aplicación puede solicitar mediante este mensaje las posiciones aproximadas por regresión del espacio en blanco de posiciones.

\vskip1.000000\baselineskip

Con el mapa de bits <mask>, la aplicación especifica los elementos de datos concretos que necesita del conjunto de datos GPS global.

Sintaxis:

<msg_id>, <time_diff>, <mask>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<time_diff>

espacio temporal entre dos conjuntos de datos GPS solicitados

<mask>

mapa de bits que indica los elementos de datos concretos solicitados por la aplicación. El conjunto de datos básicos GPS incluye los siguientes elementos: fecha; hora (UTC); longitud geográfica; latitud geográfica; altitud (al nivel del mar); dilución de precisión horizontal (HDOP); error de posición estimado en dirección sur-norte (EPE(x)); error de posición estimado en dirección este-oeste (EPE(y)); velocidad horizontal absoluta; rumbo (0 grados = norte, sentido de las agujas del reloj); tipo de posición (TOP); datos específicos del receptor.

\vskip1.000000\baselineskip

3.2.4.10 Mensaje "gps_approx_data_backward_indication"

Nombre del mensaje:

"gps_approx_data_backward_ind"

Origen:

función básica de aproximación

Destino:

aplicación (u otra función básica)

{}\hskip0,4cm Descripción: \hskip1,4cm Con este mensaje la función básica de datos básicos GPS envía a la aplicación una serie de N_pos posiciones aproximadas por regresión correspondientes al último espacio en blanco de posiciones.

\vskip1.000000\baselineskip

La aplicación elige los elementos de datos concretos que se envían (véase el mensaje "gps_approx_data_backward_ req") y que especifica el mapa de bits <mask>.

Sintaxis:

<msg_id>, <mask>, <time_diff>, <N_pos>, <data_set_1;data_set_2; ...; data_set_N_pos>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<mask>

mapa de bits que indica los elementos de datos concretos de los conjuntos de datos GPS aproximados por regresión. El mapa de bits es válido para todo los conjuntos de datos.

<time_diff>

espacio temporal entre dos conjuntos de datos GPS solicitados

<N_pos>

número de posiciones aproximadas por regresión que se envían

\newpage

<data_set_1;data_set_2;. . .;data_set_N_pos> conjuntos de datos aproximados por regresión que se envían. Cada conjunto de datos contiene elementos de datos concretos indicados por el mapa de bits <mask>.

\vskip1.000000\baselineskip

3.2.4.11 Mensaje "gps_waylength_start_request"

Nombre del mensaje:

"gps_waylength_start_req"

Origen:

aplicación (u otra función básica)

Destino:

función básica waylength

{}\hskip0,4cm Descripción: \hskip1,3cm Este mensaje se utiliza para reiniciar el contador de waylength al valor "0 metros" en caso de incremento o a un valor de waylength fijo (como valor negativo) que debe recorrerse durante la disminución (equivalente a un incremento pero de valores negativos).

\vskip1.000000\baselineskip

La aplicación selecciona marcas de contador <val_1,val_2,...,val_n> para que se mande una indicación cuando se supere determinada marca.

Es decir, si el waylength fijado que debe recorrerse es de 2.000 m, y ha de enviarse una indicación cuando queden 200 m, 100 m y 50 m del waylength total, la aplicación establece <start_val>=<-2000m> y <val_1,val_2, val_3,val_4>=<-200m,-100m,-50m,0m> en el mensaje para que se dé una indicación a estos puntos.

La aplicación fija una ID de contador. La función básica memoriza qué contador de waylength pertenece a qué aplicación.

La aplicación debe detener el cálculo del waylength con el mensaje "gps_waylength_stop_req". El contador sólo puede restablecerse a cero después de detenerse de este modo.

Si el contador de waylength supera la barrera de los "0 metros", la función básica lo detiene automáticamente. También puede detenerse a un valor máximo predeterminado.

Sintaxis:

<msg_id>, <counter_id>, <start_val>, <n>, <val_1,val_2,...,val_n>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<counter_id>

ID de contador fijada por la aplicación

<start_val>

valor inicial del contador de waylength. Es 0 metros en caso de incremento o un valor negativo fijo en caso de disminución.

<n>

número de marcas del contador

<val_1,val_2,...val_n> marcas del contador.

\vskip1.000000\baselineskip

3.2.4.12 Mensaje "gps_waylength_request"

Nombre del mensaje:

"gps_waylength_req"

Origen:

aplicación (u otra función básica)

Destino:

función básica waylength

{}\hskip0,4cm Descripción: \hskip1,3cm Este mensaje se utiliza para solicitar el valor actual del contador con ID de contador <counter_id>.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <counter_id>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<counter_id>

ID de contador.

\vskip1.000000\baselineskip

3.2.4.13 Mensaje "gps_waylength_indication"

Nombre del mensaje:

"gps_waylength_ind"

Origen:

función básica waylength

Destino:

aplicación (u otra función básica)

{}\hskip0,4cm Descripción: \hskip1,3cm Este mensaje se utiliza para enviar el valor actual del contador con la ID de contador <counter_ID>. El mensaje se envía después de la solicitud "gps_waylength_req" o si el valor actual del contador ha superado las marcas <val_1,val_2,...,val_n> del mensaje "gps_waylength_start_req".

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <counter_id>, <counter_value>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<counter_id>

ID de contador

<counter_value>

el valor actual del contador.

\vskip1.000000\baselineskip

3.2.4.14 Mensaje "gps_waylength_stop_request"

Nombre del mensaje:

"gps_waylength_stop_req"

Origen:

aplicación (u otra función básica)

Destino:

función básica waylength

{}\hskip0,4cm Descripción: \hskip1,3cm Este mensaje se utiliza para detener el contador de waylength. Si el parámetro <par> tiene el valor 1, sólo se detiene el contador de waylength con el ID de contador <counter_id>. Si el parámetro <par> tiene el valor 0, se detienen todos los contadores de waylength fijados por la aplicación.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <par>, (si <par>=1: <counter_id>)

Valores definidos:

<msg_id> \hskip1,1cm por definir

<par>

0 - se detienen todos los contadores de waylength fijados por la aplicación

\quad

1 - se detiene el contador de waylength con la ID <counter_id>

<counter_id>

ID de contador.

\vskip1.000000\baselineskip

3.2.4.15 Mensaje "gps_waylength_global_request"

Nombre del mensaje:

"gps_waylength_global_req"

Origen:

aplicación (u otra función básica)

Destino:

función básica waylength

{}\hskip0,4cm Descripción: \hskip1,4cm Este mensaje se utiliza para solicitar el valor actual del contador de waylength global.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>

Valores definidos:

<msg_id> \hskip1,1cm por definir.

\vskip1.000000\baselineskip

3.2.4.16 Mensaje "gps_waylength_global_indication"

Nombre del mensaje:

"gps_waylength_global_ind"

Origen:

función básica waylength

Destino:

aplicación (u otra función básica)

Descripción:

Este mensaje se utiliza para enviar el valor actual del contador de waylength global.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <global_counter_value>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<global_counter_value> el valor actual del contador de waylength global.

\vskip1.000000\baselineskip

3.2.4.17 Mensaje "gps_waypoint_start_request"

Nombre del mensaje:

"gps_waylength_start_req"

Origen:

aplicación (u otra función básica)

Destino:

función básica waypoint

{}\hskip0,4cm Descripción: \hskip1,3cm Este mensaje se utiliza para iniciar la función básica "gps_waypoint" mediante los datos de waypoint.

\vskip1.000000\baselineskip

Si el parámetro <geom> tiene el valor 1, se envían los datos de un círculo (longitud y latitud del centro del círculo, el radio, la histéresis, la dirección preferente (0 grados = norte, sentido agujas del reloj) y la apertura del ángulo de la dirección preferente).

Si el parámetro <geom> posee el valor 2, se envían los datos de un rectángulo (longitud y latitud del centro del rectángulo, largo y ancho, dirección preferente (0 grados = norte, sentido agujas del reloj) y la apertura del ángulo de la dirección preferente).

La aplicación fija una ID de waypoint. La función básica almacena qué waypoints pertenecen a qué aplicación.

El cálculo de waypoints se detiene a través de la aplicación con el mensaje "gps_waypoint_stop_req".

Con el parámetro <status>, la aplicación puede hacer que el waypoint se mantenga activo incluso cuando el se apague el sistema y se encienda de nuevo.

Sintaxis:

<msg_id>, <wayp_id>, <geom>, <waypoint_data>, <status>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<wayp_id>

ID de waypoint fijada por la aplicación

<geom>

geometría del waypoint: <geom>=1: círculo; <geom>=2: rectángulo

<waypoint_data>

datos del waypoint

\quad

<geom>=1: "círculo": longitud y latitud del centro del círculo, radio, histéresis, dirección preferente (sentido agujas del reloj, 0 grados = norte), ángulo de apertura de la dirección preferente.

\quad

<geom>=2: "rectángulo": longitud y latitud del centro del rectángulo, largo y ancho del rectángulo, histéresis, dirección preferente (0 grados = norte, sentido agujas del reloj) y ángulo de apertura de la dirección preferente.

<status>

0 - el cálculo de waypoints sólo está activo durante la operación actual

\quad

1 - el cálculo de waypoints se mantiene activo aun cuando el sistema se apaga y se enciende de nuevo.

\vskip1.000000\baselineskip

3.2.4.18 Mensaje "gps_waypoint_status_indication"

Nombre del mensaje:

"gps_waypoint_status_ind"

Origen:

función básica waypoint

Destino:

aplicación (u otra función básica)

{}\hskip0,4cm Descripción: \hskip1,3cm En primer lugar, este mensaje se utiliza para indicar la llegada a la zona interna del waypoint (<status>=1).

\vskip1.000000\baselineskip

En segundo lugar, indica que el vehículo cruza la línea central (de dirección normal a dirección preferente atravesando el centro del waypoint) (<status>=2). Con este estado se indica si el rumbo del vehículo sigue la dirección preferente (es decir, que se encuentra dentro de la apertura del cono de la dirección preferente) (<par_heading>=1) o no (es decir, que se encuentra fuera de la apertura del cono de la dirección preferente) (<par_heading>=0). También se envía el rumbo <heading> actual.

En tercer lugar, se indica también la salida de la zona de histéresis en dirección al exterior del waypoint
(<status>=3).

En cuarto lugar, en caso de posiciones aproximadas por regresión se indica que el vehículo ha llegado a la zona interna del waypoint y ha cruzado la línea central (<status>=4). Con este estado se indica si el rumbo del vehículo se encontraba dentro de la apertura del cono de la dirección preferente (<par_heading>=1) o fuera de ésta (<par_heading>=0). También se envía el rumbo <heading> al mismo tiempo.

En quinto lugar, en caso de posiciones aproximadas por regresión se indica que el vehículo ha llegado a la zona interna del waypoint, ha cruzado la línea central y ha abandonado la zona de histéresis con rumbo hacia el exterior del waypoint (<status>=5). Con este estado se indica si el rumbo del vehículo se encontraba dentro de la apertura del cono de la dirección preferente (<par_heading>=1) o fuera de ésta (<par_heading>=0). También se envía el rumbo <heading> al mismo tiempo.

Con el mensaje se envía el tipo de posición (<top(x),top(y)>) de la posición GPS correspondiente, la hora (<time>) de la posición y la distancia (<dist>) de dicha posición con respecto a la línea central (de dirección normal a preferente atravesando el centro del waypoint). En caso de que se produzcan los estados 4 o 5, se envía el TOP (<top(x),top(y)>), la hora (<time>), la distancia a la línea central (<dist>), el parámetro <par_heading> y el rumbo (<heading>) de la posición GPS en la que se basa el mensaje de centro.

Sintaxis:

<msg_id>, <wayp_id>, <status>, <top(x),top(y)>, <time>, <dist>, (si <status>=2, 4, 5: <par_heading>, <heading>)

Valores definidos:

<msg_id> \hskip1,1cm por definir

<wayp_id>

ID del waypoint

<status>

1 - "IN": llegada a la zona interna del waypoint

\quad

2 - "CENTER": el vehículo cruza la línea central (de dirección normal a preferente atravesando el centro del waypoint)

\quad

3 - "OUT": salida del área de histéresis con rumbo hacia el exterior del waypoint

\quad

4 - en caso de posiciones aproximadas por regresión, el vehículo ha llegado a la zona interna del waypoint y ha cruzado la línea central

\quad

5 - en caso de posiciones aproximadas por regresión, el vehículo ha llegado a la zona interna del waypoint, ha cruzado la línea central y ha abandonado la zona de histéresis con rumbo hacia el exterior del waypoint

<top(x),top(y)>

tipo de posición de la posición GPS correspondiente

\quad

top(x) - TOP en dirección sur-norte

\quad

top (y) - TOP en dirección oeste-este

\newpage

<dist>

distancia de la posición GPS relacionada con respecto a la línea central (de dirección normal a preferente atravesando el centro del waypoint)

<time>

hora de la posición GPS relacionada

Si <status>=2, 4, 5

<par_heading>

1 - el rumbo del vehículo ha seguido la dirección preferente (es decir, se encontraba dentro del cono de apertura de la dirección preferente)

\quad

0 - el rumbo del vehículo no ha seguido la dirección preferente (es decir, se encontraba fuera del cono de apertura de la dirección preferente)

<heading>

rumbo de la posición GPS relacionada.

\vskip1.000000\baselineskip

3.2.4.19 Mensaje "gps_waypoint_stop_request"

Nombre del mensaje:

"gps_waypoint_stop_req"

Origen:

aplicación (u otra función básica)

Destino:

función básica waypoint

{}\hskip0,4cm Descripción: \hskip1,3cm Este mensaje se utiliza para detener el cálculo de waypoints. Si el parámetro <par> tiene el valor 1, sólo se detiene el cálculo de waypoints de acuerdo con la ID de waypoint <wayp_id>. Si el parámetro <par> posee el valor 0, se detiene el cálculo del waypoint de todos los waypoints fijados por la aplicación.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <par>, (si <par>=1: <wayp_id>)

Valores definidos:

<msg_id> \hskip1,1cm por definir

<par>

0 - se desactivan todos los waypoints fijados por la aplicación

\quad

1 - se desactiva únicamente el waypoint con la ID <wayp_id>

\quad

si <par>=1

<wayp_id>

ID de waypoint.

\vskip1.000000\baselineskip

3.2.5 Mensajes relacionados con el subsistema de control de acceso

En este capítulo se describen los mensajes relacionados con las distintas funciones básicas del módulo de interfaz de tarjeta de chip (CIM). La transferencia de mensajes entre las aplicaciones y las funciones básicas de CIM se controla mediante los siguientes mensajes:

\vskip1.000000\baselineskip

Relacionados con la función básica CIM de apertura de aplicación CIM:

-

cim_open_application_request

-

cim_open_application_confirmation

\vskip1.000000\baselineskip

Relacionados con la función básica CIM de transferencia de datos de comandos CIM:

-

cim_send_data_request

-

cim_send_data_response

-

cim_status_request

-

cim_status_indication

Relacionados con la función básica CIM de cierre de aplicación CIM:

-

cim_close_application_request

-

cim_close_application_confirmation

En el diagrama de secuencia temporal de la página siguiente se describe un ejemplo de transferencia de mensajes entre una aplicación y una función básica CIM.

Ilustración 3.2.5-1: Diagrama de secuencia temporal relacionado con el subsistema de control de acceso.

\vskip1.000000\baselineskip

3.2.5.1 Mensaje "cim_open_application_request"

Nombre del mensaje:

"cim_open_application_req"

Origen:

aplicación

Destino:

función básica de apertura de aplicación CIM

Respuesta:

"cim_open_application_con" (confirmación de apertura positiva o negativa)

{}\hskip0,4cm Descripción: \hskip1,3cm Éste es un mensaje que utiliza la aplicación para iniciar una comunicación con una aplicación de tarjeta de chip.

\vskip1.000000\baselineskip

Si el intento de establecimiento de conexión no tiene éxito, la función básica debe evaluar y/o reenviar las causas de error (por ejemplo, aplicación desconocida o ausencia de tarjeta de chip).

Al recibir este mensaje, se establece una canal lógico de comunicación entre la aplicación y la función básica. Debe enviarse a la aplicación solicitante un mensaje de confirmación que contenga el número de canal lógico o la posible causa de error.

El mensaje incluye un identificador de mensaje <msg_id> y un identificador de aplicación <aid>.

Sintaxis:

<msg_id>, <aid>

Valores definidos:

<msg_id> por definir

<ai>

por definir.

\vskip1.000000\baselineskip

3.2.5.2 Mensaje "cim_open_application_confirmation"

Nombre del mensaje:

"cim_open_application_con"

Origen:

función básica de apertura de aplicación CIM

Destino:

aplicación solicitante

{}\hskip0,4cm Descripción: \hskip1,3cm Este mensaje se utiliza para confirmar que se ha abierto un canal lógico para la aplicación solicitante para enviar comandos o datos a la tarjeta de chip (con mensajes "cim_send_data_req"). El mensaje "cim_open_application_con" contiene un número de canal <channel_no>. Este <channel_no> es el que utilizan los mensajes subsiguientes para dirigirse al canal lógico de comunicación.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <status>, <channel_no> o <cause>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<status>

ACK (por definir), el siguiente parámetro se interpreta como número de canal <channel_no>

\quad

NAK (por definir), el siguiente parámetro se interpreta como valor de causa

<cause>

por definir

<channel_no> identificador del canal lógico de comunicación de la comunicación
solicitada.

\vskip1.000000\baselineskip

3.2.5.3 Mensaje "cim_send_data_request"

Nombre del mensaje:

"cim_send_data_req"

Origen:

aplicación

Destino:

función básica de transferencia de datos de comandos CIM

Respuesta:

"cim_send_data_res" (respuesta de la tarjeta de chip)

\quad

"cim_status_ind" (se ha producido un error)

{}\hskip0,4cm Descripción: \hskip1,4cm Con este mensaje se envían a la función básica los datos o los comandos que se pretende enviar a la tarjeta de chip.

\vskip1.000000\baselineskip

El mensaje se reconoce mediante la respuesta de la tarjeta de chip (reconocimiento positivo) o mediante un mensaje de estado (reconocimiento negativo).

El mensaje "cim_send_data_req" contiene un identificador de mensaje <msg_id>, un número de canal <channel_
no>, la extensión de los datos <data_length> y los propios datos <data>.

Sintaxis:

<msg_id>, <channel_no>, <data_length>, <data>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<channel_no>

identificador del canal lógico de comunicación para la comunicación solicitada

<data_length>

extensión de los datos <data> en bytes

<data>

datos/comandos que se pretende enviar a la tarjeta de chip.

\vskip1.000000\baselineskip

3.2.5.4 Mensaje "cim_send_data_response"

Nombre del mensaje:

"cim_send_data_res"

Origen:

función básica de transferencia de datos de comandos CIM

Destino:

aplicación

{}\hskip0,4cm Descripción: \hskip1,3cm Con este mensaje se envían los datos de respuesta de la tarjeta de chip a la aplicación solicitante.

\vskip1.000000\baselineskip

El mensaje "cim_send_data_res" contiene un identificador de mensaje <msg_id>, un número de canal <channel_
no>, la extensión de los datos <data_length> y los propios datos <data>.

Sintaxis:

<msg_id>, <channel_no>, <data_length>, <data>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<channel_no>

identificador del canal lógico de comunicación para la comunicación solicitada

<data_length>

extensión de los datos <data> en bytes

<data>

datos/comandos que se pretende enviar a la tarjeta de chip.

\vskip1.000000\baselineskip

3.2.5.5 Mensaje "cim_status_request"

Nombre del mensaje:

"cim_status_req"

Origen:

aplicación

Destino:

función básica de transferencia de datos de comandos CIM

Respuesta:

"cim_status_ind"

{}\hskip0,4cm Descripción: \hskip1,4cm Este mensaje se utiliza para solicitar el estado del CIM.

\vskip1.000000\baselineskip

Sólo incluye el identificador del mensaje <msg_id>.

Sintaxis:

<msg_id>

Valores definidos:

<msg_id> \hskip1,1cm por definir.

\vskip1.000000\baselineskip

3.2.5.6 Mensaje "cim_status_indication"

Nombre del mensaje:

"cim_status_ind"

Origen:

función básica de transferencia de datos de comandos CIM

Destino:

aplicación

{}\hskip0,4cm Descripción: \hskip1,4cm Este mensaje se utiliza para informar a la aplicación de un error o una acción inesperada, o de un cambio de estado en el equipo.

\vskip1.000000\baselineskip

Al recibir el mensaje "cim_status_ind", la aplicación debe decidir qué medidas tomar si se produce un error.

El mensaje contiene un identificador de mensaje <msg_id> y la información de estado <status>.

Sintaxis:

<msg_id>, <status>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<status>

información de estado relativa a un error, una acción inesperada o un cambio de estado en el equipo.

\vskip1.000000\baselineskip

3.2.5.7 Mensaje "cim_close_application_request"

Nombre del mensaje:

"cim_close_application_req"

Origen:

aplicación

Destino:

función básica de cierre de aplicación CIM

{}\hskip0,4cm Descripción: \hskip1,4cm Este mensaje lo utiliza la aplicación para cerrar el canal lógico de comunicación entre la aplicación y la función básica.

\vskip1.000000\baselineskip

El mensaje contiene un identificador de mensaje <msg_id> y un número de canal <channel_no>.

Sintaxis:

<msg_id>, <channel_no>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<channel_no>

identificador del canal lógico de comunicación para la comunicación solicitada.

\vskip1.000000\baselineskip

3.2.5.8 Mensaje "cim_close_application_confirmation"

Nombre del mensaje:

"cim_close_application_con"

Origen:

función básica de cierre de aplicación CIM

Destino:

aplicación

{}\hskip0,4cm Descripción: \hskip1,3cm Este mensaje se utiliza para confirmar a la aplicación solicitante que se ha cerrado el canal lógico de comunicación entre la aplicación y la función básica. Ha finalizado la comunicación con la tarjeta de chip.

\vskip1.000000\baselineskip

El mensaje contiene un identificador de mensaje <msg_id> y un número de canal <channel_no>

Sintaxis:

<msg_id>, <channel_no>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<channel_no>

identificador del canal lógico de comunicación para la comunicación solicitada.

\vskip1.000000\baselineskip

3.2.6 Mensajes relacionados con el subsistema de entrada/salida

En este capítulo se describen los mensajes relacionados con las distintas funciones básicas de entrada/salida (E/S). La transferencia de mensajes entre las aplicaciones y las funciones básicas de E/S se controlan por medio de los siguientes mensajes:

Relacionados con la función básica de E/S de visualización de información E/S:

-

io_display_information_request

-

io_display_information_confirmation

-

io_display_information_acknowledgement

-

io_display_information_interruption

-

io_display_information_rejection

-

io_display_information_finish_request

-

io_display_information_finish_acknowledge

-

io_display_type_request

-

io_display_type_result

Relacionados con la función básica de E/S de introducción de datos E/S:

-

io_input_device_request

-

io_input_device_acknowledge

-

io_input_device_reject

-

io_enter_data_request

-

io_enter_data_confirmation

-

io_enter_data_result

-

io_enter_data_acknowledge

-

io_enter_data_reject

-

io_input_device_type_request

-

io_input_device_type_result

En un gráfico de flujo, que ilustra la interacción general, y los diagramas de secuencia temporal de las páginas siguientes se describen algunos ejemplos de transferencias de mensajes relacionados con las funciones básicas del dispositivo de entrada/salida.

\vskip1.000000\baselineskip

Ilustración 3.2.6-1: Diagrama de fase relativo a la función básica de E/S de visualización de información

Ilustración 3.2.6-2: Diagrama de secuencia temporal relativo a la función básica de E/S de visualización de información

Ilustración 3.2.6-3: Diagrama de secuencia temporal relativo a la función básica de E/S de visualización de información

Ilustración 3.2.6-4: Diagrama de secuencia temporal relativo a la función básica de E/S de visualización de información

Ilustración 3.2.6-5: Diagrama de secuencia temporal relativo a la función básica de E/S de visualización de información

Ilustración 3.2.6-6: Diagrama de secuencia temporal relativo a la función básica de E/S de introducción de datos

Ilustración 3.2.6-7: Diagrama de secuencia temporal relativo a la función básica de E/S de introducción de datos.

\vskip1.000000\baselineskip

3.2.6.1 Mensaje "io_display_information_request"

Nombre del mensaje:

"io_display_information_req"

Origen:

aplicación u otra función básica

Destino:

función básica E/S de visualización de información

Respuesta:

"io_display_information_con" (confirmación de la solicitud)

\quad

"io_display_information_ack" (reconocimiento de la solicitud)

\quad

"io_display_information_int" (interrupción de la solicitud)

\quad

"io_display_information_rej" (rechazo de la solicitud)

{}\hskip0,4cm Descripción: \hskip1,4cm Este mensaje es usado por las aplicaciones y las funciones básicas para mostrar datos en el dispositivo de entrada/salida. La solicitud contiene la información que se desea visualizar y la información de control de la tarea de visualización.

\vskip1.000000\baselineskip

Si una aplicación envía una solicitud de visualización de información a una unidad de visualización que en el momento de la solicitud no se encuentra operativa o para la que la aplicación no posee derechos de acceso, la función básica rechaza la solicitud.

Si la unidad de visualización no está ocupada por otra tarea, se acepta la solicitud de visualización de información y se envía un mensaje "io_display_information_confirmation" al emisor de la solicitud. Cuando la información se visualiza durante un periodo de tiempo <t_dur>, se envía un mensaje "io_display_information_acknowledgement".

Si se produce un mensaje "io_display_information_request" de otra aplicación con una prioridad mayor, se interrumpe la información visualizada en ese momento durante un periodo de tiempo <t_dur> y se envía un mensaje "io_display_information_interruption" al emisor de la aplicación relacionada.

Si la solicitud "io_display_information_request" tiene un prioridad igual o inferior a la de la información visualizada en un momento dado, dicha solicitud se coloca en cola de espera. Si el tiempo de espera en cola es superior a un valor predefinido, se rechaza la solicitud "io_display_information_request".

Sintaxis:

<msg_id>, <io_id>, <info_typ>, <t_dur>, <t_queue>, <session_id>, <finish_typ>, <info_length>, <info>, <adj>, <format>, <font>, <size>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<io_id>

identificador del dispositivo de entrada/salida en el que ha de visualizarse la información

<info_typ>

tipo de información. Los valores posibles son:

\quad

b - mapa de bits

\quad

c - carácter

\quad

p - símbolo/mensaje predefinido

<t_dur>

duración mínima en segundos durante la cual ha de visualizarse la información

<t_queue>

tiempo máximo en cola hasta producirse el rechazo de visualización

<session_id>

identificador de una sesión de visualización/entrada con un número de informaciones que deben visualizarse juntas y de datos que debe introducir el usuario. Las acciones de visualización/entrada forman un todo y no se pueden interrumpir por una solicitud de visualización de igual prioridad.

<finish_typ>

tipo de finalización de la visualización de la información. Los valores posibles son:

\quad

c - visualización continua de información; cuando se supera la duración de visualización <t_dur>, el estado de la unidad de visualización cambia a "accesible", pero ésta mantiene la información antigua hasta que no se solicite la visualización de nueva información

\quad

a - finalización sólo por comando io_display_information_ finish_ request de la aplicación o función básica de origen.

<info_length>

extensión de la información en bytes

<info>

información para visualizar

<adj>

información de ajuste. Los valores posibles son:

\quad

s - estándar

\quad

v - centrado vertical

\quad

h - centrado horizontal

\quad

x - formato especial de la información

\quad

Si <adj> = "x", se incluyen a la estructura los siguientes parámetros adicionales:

<format>

información de formato. Los valores posibles son:

\quad

b - negrita

\quad

i - cursiva

\quad

u - subrayado

<font>

tipo de letra

<size>

tamaño de letra. Valores posibles en puntos (pt).

\vskip1.000000\baselineskip

3.2.6.2 Mensaje "io_display_information_reject"

Nombre del mensaje:

"io_display_information_rej"

Origen:

función básica E/S de visualización de información

Destino:

aplicación o función básica solicitante

Respuesta:

ninguna

{}\hskip0,4cm Descripción: \hskip1,3cm El mensaje io_display_infor-mation_reject se puede enviar por dos motivos: no es posible acceder a la función básica o se ha superado el tiempo t_queue.

\vskip1.000000\baselineskip

Si una aplicación o una función básica envía una solicitud de visualización de información a una unidad de visualización <io_id> que en el momento de la solicitud no está operativa o para la que la aplicación no posee derechos de acceso, la función básica envía el mensaje "io_display_information_reject" a la aplicación o función básica
solicitante.

Si la solicitud "io_display_infor-mation_request" tiene una prioridad igual o inferior a la de la información que se muestra en un momento dado, la solicitud se coloca en cola de espera. Si el tiempo de espera en la cola es superior al valor <t_queue>, se rechaza la solicitud.

Sintaxis:

<msg_id>, <rej_stat>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<rej_stat>

motivo del rechazo. Los valores posibles son:

\quad

na - acceso no permitido

\quad

no - unidad de visualización no operativa

\quad

te - tiempo superado (t_queue).

\vskip1.000000\baselineskip

3.2.6.3 Mensaje "io_display_information_confirmation"

Nombre del mensaje:

"io_display_information_con"

Origen:

función básica E/S de visualización de información

Destino:

aplicación o función básica solicitante

Respuesta:

ninguna

{}\hskip0,4cm Descripción: \hskip1,3cm En caso de que la unidad de visualización esté operativa y la aplicación o la función básica solicitante tenga los accesos pertinentes, se acepta la solicitud "io_display_information_request" y se envía un mensaje "io_display_information_confirmation" al emisor de la solicitud.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <con_status>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<con_status>

estado de confirmación. Los valores posibles son:

\quad

d - información visualizada

\quad

q - solicitud en cola.

\vskip1.000000\baselineskip

3.2.6.4 Mensaje "io_display_information_interruption"

Nombre del mensaje:

"io_display_information_int"

Origen:

función básica E/S de visualización de información

Destino:

aplicación o función básica solicitante

Respuesta:

ninguna

{}\hskip0,4cm Descripción: \hskip1,3cm Si otra aplicación envía una solicitud "io_display_information_request" con una prioridad superior, se interrumpe la visualización de dicha información durante un periodo de tiempo <t_dur> y se envía un mensaje de "io_display_information_interruption" al emisor de la solicitud de visualización de información que se ha interrumpido.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <int_reason>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<int_reason>

motivo de la interrupción. Los valores posibles son:

\quad

nr - nueva solicitud de una aplicación o función básica con prioridad superior

\quad

qr - la prioridad de una "io_display_information_request" en cola es superior a la prioridad de la información que se está visualizando en un momento dado.

\vskip1.000000\baselineskip

3.2.6.5 Mensaje "io_display_information_acknowledge"

Nombre del mensaje:

"io_display_information_ack"

Origen:

función básica E/S de visualización de información

Destino:

aplicación o función básica solicitante

Respuesta:

ninguna

{}\hskip0,4cm Descripción: \hskip1,4cm Cuando la información se muestra durante un periodo de tiempo <t_dur>, se envía este mensaje al emisor de la solicitud. Con éste, se finaliza la tarea de visualización de la información solicitada.

\vskip1.000000\baselineskip

Si <finish_typ>= "c" (parámetro de "io_display_information_request"), el estado de la visualización se establece en "accesible". Con la llegada de cada nueva solicitud "io_display_information_request", se borra el contenido que se está visualizando en un momento dado.

Si <finish_typ>= "a" (parámetro de "io_display_information_request"), el estado se mantiene en "ocupado" hasta que el emisor del mensaje visualizado finaliza la visualización de información con una solicitud "io_display_infor- mation_finish_request".

Sintaxis:

<msg_id>

Valores definidos:

<msg_id> \hskip1,1cm por definir.

\vskip1.000000\baselineskip

3.2.6.6 Mensaje "io_display_information_finish_request"

Nombre del mensaje:

"io_display_information_finish_req"

Origen:

aplicación o función básica solicitante

Destino:

función básica E/S de visualización de información

Respuesta:

"io_display_information_finish_ack"

{}\hskip0,4cm Descripción: \hskip1,4cm Con este mensaje, se inician las siguientes acciones:

\vskip1.000000\baselineskip

Cuando la solicitud "io_display_in-formation_request" ya se ha finalizado, se borra la información visualizada en el dispositivo de entrada/salida.

Cuando la solicitud "io_display_in-formation_request" sigue en la cola a la espera de acceso para ser visualizada, se saca de la cola de espera (aplicación iniciada).

Si la solicitud "io_display_in-formation_request" que ha de finalizarse forma parte de una serie de solicitudes "io_display_information_request" interdependientes (parámetro <session_id> de io_display_informa-tion_request"), con el parámetro <del_session> se define qué medidas se toman con el resto de solicitudes "io_display_in-formation_request de la sesión pertinente.

Sintaxis:

<msg_id>, <io_id>, <del_session>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<io_id>

identificador del dispositivo de entrada/salida donde ha de visualizarse la información

<del_session>

acción para el resto de solicitudes con igual ID de sesión. Los valores posibles son:

\quad

n - no finalización del resto de solicitudes "io_display_in-formation_request" de la misma sesión; sólo se saca de la cola o se borra la solicitud "io_ display_information_request" visualizada.

\quad

y - se sacan de la cola o se borran todas las solicitudes "io_display_ information_re-quest" con la misma sesión y emisor.

\vskip1.000000\baselineskip

3.2.6.7 Mensaje "io_display_information_finish_acknowledge"

Nombre del mensaje:

"io_display_information_finish_ack"

Origen:

función básica E/S de visualización de información

Destino:

aplicación o función básica solicitante

Respuesta:

ninguna

{}\hskip0,4cm Descripción: \hskip1,4cm Cuando se han ejecutado las acciones solicitadas por "io_display_information_finish_ req", se envía el mensaje "io_display_information_finish_ack" al emisor de la solicitud.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>

Valores definidos:

<msg_id> \hskip1,1cm por definir.

\vskip1.000000\baselineskip

3.2.6.8 Mensaje "io_display_type_request"

Nombre del mensaje:

"io_display_type_req"

Origen:

aplicación o función básica solicitante

Destino:

función básica E/S de visualización de información

Respuesta:

"io_display_type_res"

{}\hskip0,4cm Descripción: \hskip1,4cm Con este mensaje la aplicación o función básica solicita la utilización del dispositivo de entrada/salida identificado con la <io_id>. Con el mensaje de respuesta "io_display_type_res", se informa a la aplicación de su derecho de acceso al dispositivo de entrada/salida mencionado.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <io_id>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<io_id>

identificador del dispositivo de entrada/salida donde se mostrará la información.

\vskip1.000000\baselineskip

3.2.6.9 Mensaje "io_display_type_result"

Nombre del mensaje:

"io_display_type_res"

Origen:

función básica E/S de visualización de información

Destino:

aplicación o función básica solicitante

Respuesta:

ninguna

{}\hskip0,4cm Descripción: \hskip1,4cm Con este mensaje la función básica informa a la aplicación o a la función básica solicitante de sus derechos de acceso al dispositivo de entrada/salida correspondiente.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <access_stat>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<access_stat>

estrado de acceso al dispositivo de entrada/salida. Los valores posibles son:

\quad

n - sin acceso

\quad

y - acceso permitido; sólo aplicación solicitante

\quad

c - acceso permitido; uso común del dispositivo de entrada/salida (todas las aplicaciones)

\quad

m - acceso permitido; uso por parte de varias aplicaciones.

\vskip1.000000\baselineskip

3.2.6.10 Mensaje "io_input_device_request"

Nombre del mensaje:

"io_input_device_req"

Origen:

aplicación o función básica solicitante

Destino:

función básica E/S de introducción de datos

Respuesta:

"io_input_device_ack"

\quad

"io_input_device_rej"

{}\hskip0,4cm Descripción: \hskip1,4cm Cuando una aplicación o función básica desea solicitar la introducción de datos, primero debe comprobar si el dispositivo de introducción está disponible o está siendo utilizado por otra aplicación. Se envía una solicitud "io_input_device_req" al dispositivo de introducción.

\vskip1.000000\baselineskip

Si el dispositivo de introducción está accesible, se establece comunicación y se envía un mensaje "io_input_device_ ack" a la aplicación solicitante.

El dispositivo de introducción se bloquea para las solicitudes de otras aplicaciones. Su estado cambia a "ocupado".

Si el dispositivo de introducción está "ocupado", se envía un mensaje "io_input_device_rej" a la aplicación solicitante. El motivo del rechazo se envía de todos modos como parámetro de estado. El estado puede ser "ocupado" o "acceso_no_permitido".

Una aplicación también se desconecta de un dispositivo de introducción mediante un mensaje "io_input_device_req" (<attach>=no).

Sintaxis:

<msg_id>, <in_dev_id>, <attach>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<in_dev_id>

identificador del dispositivo de introducción seleccionado mediante el cual han de introducirse los datos

<attach>

distingue entre conectar y desconectar del dispositivo de introducción. Los valores posibles son:

\quad

yes - conectar al dispositivo

\quad

no - desconectar del dispositivo.

\vskip1.000000\baselineskip

3.2.6.11 Mensaje "io_input_device_acknowledge"

Nombre del mensaje:

"io_input_device_ack"

Origen:

función básica E/S de introducción de datos

Destino:

aplicación o función básica solicitante

Respuesta:

ninguna

{}\hskip0,4cm Descripción: \hskip1,4cm Este mensaje es la respuesta al mensaje "io_input_device_request". En caso de que el dispositivo de introducción sea accesible y la aplicación solicitante tenga derecho a acceder al dispositivo de introducción, se conecta el dispositivo de introducción a la aplicación solicitante. El estado del dispositivo de introducción se establece en "ocupado" y el mensaje "io_input_device_ack" se envía a la aplicación solicitante.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>

Valores definidos:

<msg_id> \hskip1,1cm por definir.

\vskip1.000000\baselineskip

3.2.6.12 Mensaje "io_input_device_reject"

Nombre del mensaje:

"io_input_device_rej"

Origen:

función básica E/S de introducción de datos

Destino:

aplicación o función básica solicitante

Respuesta:

ninguna

{}\hskip0,4cm Descripción: \hskip1,4cm Este mensaje es la respuesta a una solicitud "io_input_device_request". En caso de que el dispositivo esté "ocupado" o la aplicación solicitante no tenga derechos de acceso al dispositivo de introducción, se rechaza la solicitud. Se envía un mensaje "io_input_device_rej" a la aplicación solicitante o a la función básica. El mensaje contiene un parámetro "status" que indica la causa del rechazo.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <status>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<status>

motivo del rechazo. Los valores posibles son:

\quad

busy - el dispositivo está conectado a otra aplicación en ese momento

\quad

na - no se permite el acceso al dispositivo de introducción seleccionado

\quad

no - el dispositivo de introducción no se encuentra disponible en ese momento.

\vskip1.000000\baselineskip

3.2.6.13 Mensaje "io_enter_data_request"

Nombre del mensaje:

"io_enter_data_request"

Origen:

aplicación o función básica solicitante

Destino:

función básica E/S de introducción de datos

Respuesta:

"io_enter_data_con"

\quad

"io_enter_data_res"

\quad

"io_enter_data_rej"

\newpage

{}\hskip0,4cm Descripción: \hskip1,4cm Cuando una aplicación o una función básica necesita la introducción de datos por parte del usuario, debe ejecutar las siguientes acciones:

\vskip1.000000\baselineskip

a - Comprobar si el dispositivo de introducción está accesible para una conexión ("io_input_device_req")

b - Mostrar un "mensaje de introducción de datos" en el dispositivo de introducción ("io_display_information_ req")

c - Generar una "solicitud de introducción de datos" para el dispositivo de entrada/salida ("io_enter_data_req").

La primera acción que debe llevarse a cabo es la conexión con un dispositivo de introducción. en segundo lugar, se debe indicar al usuario que una aplicación precisa de la introducción de datos. Para ello, puede emitirse una señal acústica (pitido o solicitud de voz) o mostrar información en pantalla que describa lo que debe hacer el usuario.

Cuando aparece el "mensaje de introducción de datos" ("io_display_data_con"), la aplicación solicita la introducción de datos. Se envía un mensaje "io_enter_data_req" al dispositivo de introducción seleccionado y éste responde con un mensaje "io_enter_data_con".

Al aceptar el mensaje "io_enter_data_req" ("io_data_req_con"), se activa un perro guardián en el dispositivo de introducción/intérprete. Esto sirve para controlar que el usuario introduzca los datos en un periodo de tiempo máximo. El parámetro de temporizador del perro guardián forma parte de "io_enter_data_req" (<timer>). Si el usuario pulsa una tecla de datos o acontecimientos, el perro guardián siempre se reinicia con el contenido de <timer>. Si el usuario no pulsa ninguna tecla en el espacio de tiempo <timer>, el perro guardián rechaza la solicitud de datos con un mensaje "io_enter_data_rej".

Con el parámetro <type> del mensaje "io_enter_data_req" se determina si la aplicación espera una respuesta de un solo carácter o de una cadena de caracteres. En caso de que la aplicación espere una cadena de caracteres, deben recopilarse todas las introducciones de caracteres en el dispositivo de introducción/intérprete hasta que el usuario pulse una tecla de acontecimiento. Cuando el usuario pulsa la tecla de acontecimiento "intro", los datos recopilados se envían a la aplicación solicitante con el mensaje "io_enter_data_res". Cuando el usuario pulsa la tecla de acontecimiento "cancelar", se borran los datos recopilados y se envía un mensaje "io_enter_data_rej" a la aplicación.

En caso de que la aplicación espere un solo carácter, el dispositivo de introducción envía cada carácter introducido con el correspondiente mensaje "io_enter_data_res" a la aplicación. En ese momento, la aplicación puede comprobar el carácter y decidir si desea enviar un nuevo mensaje de "introducción de datos" (es decir, el carácter posible para la tercera letra de la introducción del nombre de una población dependiente de los dos primeros caracteres que ha introducido el usuario). Esto se repite hasta que se pulsa la tecla de acontecimiento "intro".

Si se pulsa otra tecla de acontecimiento como "menú", el dispositivo de introducción/intérprete envía un mensaje "io_enter_data_ind" a la aplicación solicitante. La aplicación decide qué acción tomar a continuación. Si no existe en ese momento ninguna "solicitud de introducción de datos", las teclas de acontecimientos se controlan por medio de una aplicación especial que interpreta las acciones del usuario e inicia acciones de aplicaciones.

En general, todos los caracteres introducidos por el usuario se muestran en la pantalla pertinente <io_id>. En función del dispositivo de entrada/salida, es posible que se muestren al mismo tiempo el "mensaje de introducción de datos" y los datos introducidos o que se borre el mensaje "io_enter_data" al introducir el primer carácter. En casos especiales, por ejemplo, la introducción de una contraseña, debe inhibirse esta característica <displ_ch>. En tal supuesto, debe aparecer un carácter especial "·" en el dispositivo de entrada/salida.

Cuando un usuario ha introducido los datos solicitados, finaliza su acción de introducción pulsando la tecla de acontecimiento "intro". Cuando se envían los datos introducidos a la aplicación solicitada, la "solicitud de introducción de datos" acaba con el envío de un mensaje "io_enter_data_ack".

Sintaxis:

<msg_id>, <in_dev_id>, <io_id>, <type>, <timer>, <displ_char>, <session_id>, <finish_typ>, <adj>, <format>, <font>, <size>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<in_dev_id>

identificador del dispositivo de introducción seleccionado desde donde han de introducirse los datos

<io_id>

identificador del dispositivo de entrada/salida donde se mostrará la información

<type>

identificador del tipo de introducción de datos esperada. Los valores posibles son:

\quad

c - un carácter

\quad

s - una cadena de caracteres

<timer>

constante del temporizador del perro guardián (en segundos)

<displ_char>

determina si el carácter introducido se muestra o no en el dispositivo de entrada/salida. Los valores posibles son:

\quad

yes - el carácter introducido se muestra en el dispositivo de entrada/salida (predeterminado)

\quad

no - el carácter introducido no se muestra en el dispositivo de entrada/salida, sino que se muestra el carácter "·".

<session_id>

ID de una sesión de visualización/introducción con un número de informaciones deben mostrarse juntas y de datos que deben ser introducidos por el usuario. Las acciones de visualización/introduc- ción forman un todo y no pueden ser interrumpidas por otra solicitud de visualización de igual prioridad.

<finish_typ>

tipo de finalización de la visualización de información. Los valores posibles son:

\quad

a - finalización sólo por comando "io_display_information_ finish_ request" de la aplicación o función básica propietaria de la solicitud "io_display _information_request"

<adj>

ajuste de los datos introducidos. Los valores posibles son:

\quad

s - estándar

\quad

v - centrado vertical

\quad

h - centrado horizontal

\quad

x - formato especial de la información

\quad

Si <adj> = "x", se incluyen a la estructura los siguientes parámetros adicionales:

<format>

información de formato. Los valores posibles son:

\quad

b - negrita

\quad

i - cursiva

\quad

u - subrayado

<font>

tipo de letra

<size>

tamaño de letra. Valores posibles en puntos (pt).

\vskip1.000000\baselineskip

3.2.6.14 Mensaje "io_enter_data_confirmation"

Nombre del mensaje:

"io_enter_data_con"

Origen:

función básica E/S de introducción de datos

Destino:

aplicación o función básica solicitante

Respuesta:

ninguna

{}\hskip0,4cm Descripción: \hskip1,4cm Cuando una aplicación solicita la introducción de datos, se envía un mensaje "io_enter_ data_req" al dispositivo de introducción seleccionado. En caso de confirmación, el dispositivo de introducción responde a la aplicación con un mensaje "io_enter_data_con". En dicho momento, el dispositivo de introducción está listo para recibir la introducción de datos por parte del usuario. Asimismo, se activa la función de perro guardián para controlar la duración entre las acciones individuales de introducción.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>

Valores definidos:

<msg_id> \hskip1,1cm por definir.

\vskip1.000000\baselineskip

3.2.6.15 Mensaje "io_enter_data_acknowledge"

Nombre del mensaje:

"io_enter_data_ack"

Origen:

función básica E/S de introducción de datos

Destino:

aplicación o función básica solicitante

Respuesta:

ninguna

{}\hskip0,4cm Descripción: \hskip1,4cm Cuando un usuario ha introducido los datos solicitados, finaliza la acción de introducción pulsando la tecla de acontecimiento "intro". Cuando los datos introducidos se envían a la aplicación solicitante, se finaliza la "solicitud de introducción de datos" con el envío del mensaje "io_enter_data_ack".

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>

Valores definidos:

<msg_id> \hskip1,1cm por definir.

\vskip1.000000\baselineskip

3.2.6.16 Mensaje "io_enter_data_result"

Nombre del mensaje:

"io_enter_data_res"

Origen:

función básica E/S de introducción de datos

Destino:

aplicación o función básica solicitante

Respuesta:

ninguna

{}\hskip0,4cm Descripción: \hskip1,3cm Con el parámetros <type> de la solicitud "io_enter_data_req" se determina si la aplicación espera una respuesta de un solo carácter o de una cadena de caracteres. Si la aplicación espera una cadena de caracteres, todos los caracteres introducidos se recopilan en el dispositivo de introducción/intérprete hasta que el usuario pulsa una tecla de acontecimiento. Cuando el usuario pulsa la tecla de acontecimiento "intro", los datos recopilados se envían a la aplicación solicitante con el mensaje "io_enter_data_res".

\vskip1.000000\baselineskip

Si la aplicación espera un solo carácter, el dispositivo de introducción envía a la aplicación cada uno de los caracteres introducidos con el correspondiente mensaje "io_enter_data_res". A continuación, la aplicación puede comprobar el carácter y decidir si desea enviar un nuevo mensaje de "introducción de datos" (por ejemplo, el nuevo carácter puede ser el tercer carácter del nombre de una población, el cual depende de los dos primeros caracteres que ha introducido el usuario). Esta acción se repite hasta que se pulsa la tecla "intro".

Sintaxis:

<msg_id>, <data_length>, <data>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<data_length>

extensión de los datos introducidos

<data>

datos introducidos por el usuario.

\vskip1.000000\baselineskip

3.2.6.17 Mensaje "io_enter_data_reject"

Nombre del mensaje:

"io_enter_data_rej"

Origen:

función básica E/S de introducción de datos

Destino:

aplicación o función básica solicitante

Respuesta:

ninguna

{}\hskip0,4cm Descripción: \hskip1,4cm Para que obtener datos introducidos por el usuario, se envía una solicitud "io_ enter_data_request" al dispositivo de introducción. La función básica manda un mensaje "io_enter_data_rej" a la aplicación solicitante si se produce uno de los siguientes casos.

\vskip1.000000\baselineskip

Si una aplicación desea acceder a un dispositivo de introducción y el dispositivo no está operativo o la aplicación no tiene derechos de acceso a dicho dispositivo de introducción (temporal o permanente), se envía un mensaje io_enter_data_rej. La causa del rechazo se incluye en el mensaje <con_status>. Si se produce un error durante la acción de introducción, se envía el mensaje io_enter_data_rej de todos modos.

Si entre dos acciones de introducción (es decir, entre dos pulsaciones de teclas de datos) se supera determinado tiempo límite, la función de perro guardián interrumpe la solicitud "io_enter_data_request" y envía un mensaje "io_enter_data_rej".

Si un usuario interrumpe la introducción de datos pulsando la tecla de acontecimiento <cancelar>, también se envía un mensaje "io_enter_data_rej" a la aplicación solicitante.

Sintaxis:

<msg_id>, <rej_status>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<rej_status>

motivo del rechazo de la solicitud "io_enter_data_re-quest". Los valores posibles son:

\quad

c - cancelación (tecla de acontecimiento) iniciada por el usuario

\quad

t - límite de tiempo superado

\quad

na - acceso no permitido

\quad

no - no operativo.

\vskip1.000000\baselineskip

3.2.6.18 Mensaje "io_enter_data_indication"

Nombre del mensaje:

"io_enter_data_ind"

Origen:

función básica E/S de introducción de datos

Destino:

aplicación o función básica solicitante

Respuesta:

ninguna

{}\hskip0,4cm Descripción: \hskip1,3cm Si el usuario pulsa una tecla de acontecimiento como "menú", el dispositivo de introducción/intérprete envía un mensaje "io_enter_data_ind" a la aplicación solicitante. La aplicación decide qué acción tomar a continuación. Si en dicho momento no existe ninguna "solicitud de introducción de datos", las teclas de acontecimiento se controlan mediante una aplicación especial que interpreta la acción del usuario e se inicia para acciones de la aplicación.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <key_code>, <req_status>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<key_code>

identificador de la tecla que ha introducido el usuario. Los posibles valores son:

\quad

menue - tecla de introducción para el menú

\quad

up - cursor

\quad

down - cursor

\quad

help - ayuda

\newpage

<req_status>

estado del acceso al dispositivo de introducción. Los valores posibles son:

\quad

a - accesible

\quad

b – ocupado.

\vskip1.000000\baselineskip

3.2.6.19 Mensaje "io_input_device_type_request"

Nombre del mensaje:

"io_input_device_type_req"

Origen:

aplicación o función básica solicitante

Destino:

función básica E/S de introducción de datos

Respuesta:

"io_input_device_type_res"

{}\hskip0,4cm Descripción: \hskip1,4cm Con este mensaje la aplicación o la función básica solicita el uso del dispositivo de introducción con <in_dev_id>. Con el mensaje de respuesta "io_input_ device_type_res>" se informa a la aplicación sobre su derecho a acceder al dispositivo de introducción mencionado.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <in_dev_id>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<in_dev_id>

identificador del dispositivo de introducción seleccionado desde donde han de introducirse los datos.

\vskip1.000000\baselineskip

3.2.6.20 Mensaje "io_input_device_type_result"

Nombre del mensaje:

"io_input_device_type_res"

Origen:

función básica E/S de introducción de datos

Destino:

aplicación o función básica solicitante

Respuesta:

ninguna

{}\hskip0,4cm Descripción: \hskip1,4cm Con este mensaje, la función básica informa a la aplicación o función básica solicitante sobre su derecho de acceso al dispositivo de introducción mencionado.

\vskip1.000000\baselineskip

Sintaxis:

<msg_id>, <access_stat>

Valores definidos:

<msg_id> \hskip1,1cm por definir

<access_stat>

estado del acceso al dispositivo de introducción. Los valores posibles son:

\quad

n - sin acceso

\quad

y - acceso permitido; sólo para la aplicación solicitante

\quad

c - acceso permitido; uso común del dispositivo de introducción (todas las aplicaciones)

\quad

m - acceso permitido; uso por varias aplicaciones

4 Interfaz estándar de comunicaciones (SCI)

El dispositivo de base está diseñado para admitir la integración de aplicaciones telemáticas viarias y dispositivos de entrada/salida adecuados, pero también para proporcionar una interfaz estándar de comunicaciones (SCI) para la conexión de dispositivos externos. Esta característica resulta útil para ampliar el dispositivo básico con aplicaciones disponibles en la actualidad o para agregar nuevas aplicaciones o dispositivos a medida que surjan en un futuro.

Al hablar de dispositivos externos, nos referimos tanto a otra aplicación telemática viaria, otro dispositivo de entrada/salida, un terminal de facsímile, un PC o un sistema de bus de vehículo adaptable, por ejemplo, bus CAN.

Algunas aplicaciones basadas en PC pueden utilizar la vía de comunicación directa proporcionada por el módulo GSM. Otras pueden conectarse para que puedan acceder a las unidades internas del dispositivo de base; por ejemplo, para iniciar y controlar las funciones de diagnóstico o para leer el registro de errores (permitido sólo al personal).

El objetivo consiste en proporcionar un acceso al dispositivo de base independiente del fabricante. Por eso, la interfaz estándar de comunicaciones es un bus de serie universal que permite la conexión de varios dispositivos externos. Se propone la utilización de un bus RS485 en este caso.

El dispositivo de base incluye un módulo de interfaz estándar de comunicaciones (módulo SCI) que se utiliza para conectar el bus externo a la API.

4.1 Módulo SCI y vías de comunicación

Todos los dispositivos externos poseen un único acceso común a la API a través del módulo SCI, el cual representa a todos los dispositivos externos en la API. Por eso, el módulo SCI gestiona las conexiones entre los dispositivos externos y las aplicaciones o las funciones básicas integradas.

En principio, existen dos clases de acceso desde un dispositivo externo: acceso a través de la API y acceso directo.

El acceso a través de la API se utiliza para las comunicaciones normales entre dispositivos externos y las aplicaciones o las funciones básicas integradas en el dispositivo de base.

El acceso directo se utiliza para la conexión de datos transparente por GSM entre un dispositivo externo y un usuario externo, por ejemplo, aplicaciones de PC o fax. El acceso directo sólo se proporciona a través de la SCI.

4.2 Tareas del módulo SCI

Es tarea del módulo SCI proporcionar un perfil de conexión API puro o un perfil de acceso directo según los requisitos de las aplicaciones (véase la ilustración 4.2-1). Por este motivo, existe un conmutador que controla la vía de conexión. La posición del conmutador en la ilustración corresponde a la conexión normal a la API. Otra posición se utiliza para permitir que un protocolo asegura la integridad de los datos proporcionando protección contra perturbaciones de la transmisión en el bus externo. La tercera posición del conmutador posibilita el "acceso directo" a través del módulo de comunicación y la API hasta la vía de radio GSM.

Ilustración 4.2-1: Interfaz estándar de comunicaciones (SCI)

El módulo SCI se encarga de gestionar la conmutación según las demandas de las aplicaciones.

Otra tarea del módulo SCI es participar en la gestión de prioridades. Si se envía un comando desde un dispositivo externo a la función básica y éste es rechazado por la gestión de prioridades pertinente, es función del módulo SCI aceptar el mensaje de rechazo y reaccionar en consecuencia. En la otra dirección, si varias aplicaciones o funciones básicas intentan acceder a la vez, por ejemplo, a un dispositivo de entrada/salida externo, el módulo SCI se encarga de resolver el conflicto.

5 Apéndices 5.1 Apéndice 1: Extracto de GSM TS 02.07

Anexo A (normativo)

Restricciones al intento de rellamada automático

Los intentos de establecimiento de llamada mencionados en el presente documento se suponen iniciados desde un equipo periférico o, automáticamente, desde el propio terminal móvil.

El intento de rellamada puede producirse cuando el intento de llamada no tuvo éxito por algunos de los motivos que se enumeran a continuación (tal y como se define en GSM 04.08).

Estos motivos se clasifican en tres categorías principales:

1. "Destino ocupado"

Número de causa

17 \hskip0,2cm Usuario ocupado

\newpage

2. "No se puede alcanzar el destino - temporal"

Número de causa

1 \hskip0,2cm Número no asignado

3

No existe ruta hasta el destino

22

Número cambiado

28

Formato de número no válido (número incompleto)

38

Red fuera de servicio

18

El usuario no responde

19

Aviso al usuario, no hay respuesta

27

Destino fuera de servicio

34

No hay circuito/canal- disponible

41

Fallo temporal

42

Congestión en el equipo de conmutación

44

Circuito/canal solicitado no disponible

47

Recursos no disponibles, sin- especificar

3. "No se puede alcanzar el destino - permanente/largo plazo"

Número de causa

Nota: Opcionalmente se permite implementar el número de cause 27 en la categoría 3, en lugar de la categoría 2, puesto que esto es deseable ya en la fase 1.

\vskip1.000000\baselineskip

La tabla que sigue a continuación describe un patrón de restricción de intento de rellamada para cualquier número B. Este patrón define un número máximo (n) de intentos de rellamada; cunado se alcanza dicho número n, el número B asociado se pasa a la lista negra en el TM hasta que se ejecuta un reinicio manual del TM con respecto al número B. Cuando falla un intento de rellamada a cualquier número B, o se pasa a la lista negra, esto no impide llamar a otros números B.

Para las categorías 1 y 2 mencionadas más arriba, n ha de ser 10; para la categoría 3, n debe ser 1.

	Intento de llamada	Duración mínima entre
	Intento inicial de llamada	intentos de llamada

1r intento de rellamada

5 segundos

2º intento de rellamada

1 minuto

3r intento de rellamada

1 minuto

4º intento de rellamada

1 minuto

5º intento de rellamada

3 minuto

\vskip1.000000\baselineskip

enésimo intento de rellamada

3 minuto

\vskip1.000000\baselineskip

El número de números B que puede guardarse en la lista negra depende de la decisión del fabricante, pero deben ser al menos 8. Sin embargo, cuando la lista negra está llena, el TM debe seguir prohibiendo los intentos de llamada automáticos a cualquier número hasta que la lista negra se borre manualmente con respecto a uno o varios
números B.

\newpage

Cuando se conecta un dispositivo de llamada automática a un TM1 o TM2, o cuando un TMO es capaz de realizar autollamadas, el TM debe procesar las solicitudes de llamada de acuerdo con la secuencia de intentos de rellamada definida más arriba, es decir, el TM debe rechazar todas aquellas solicitudes de intento de rellamada que se produzcan en un intervalo inferior a la duración mínima permitida de intento de rellamada.

Un intento de llamada con éxito a un número sometido a las restricciones de llamada descritas más arriba (es decir, que anteriormente se había producido un intento de establecimiento de llamada infructuoso) debe reiniciar el "contador" de dicho número.

El "contador" del número B al que se ha intentado llamar sin éxito se mantendrá 24 horas o hasta que se apague el TM.

Las restricciones de intento de rellamada automática se aplican a los servicios de voz y datos.

Nota: Las restricciones sólo se aplican a la actividad de control de llamadas sin éxito, no a la gestión de recursos de radio ni a la gestión de movilidad, por lo que este mecanismo no limita los múltiples intentos de acceso a canales de radio.

\vskip1.000000\baselineskip

Causas de liberación definidas en GSM TS 04.08, véase la tabla 5.1-1

Todo el resto de valores comprendidos en el intervalo de 0 a 31 se tratarán como causa 31.

Todo el resto de valores comprendidos en el intervalo de 32 a 47 se tratarán como causa 47.

Todo el resto de valores comprendidos en el intervalo de 48 a 63 se tratarán como causa 63.

Todo el resto de valores comprendidos en el intervalo de 64 a 79 se tratarán como causa 79.

Todo el resto de valores comprendidos en el intervalo de 80 a 95 se tratarán como causa 95.

Todo el resto de valores comprendidos en el intervalo de 96 a 111 se tratarán como causa 111.

Todo el resto de valores comprendidos en el intervalo de 112 a 127 se tratarán como causa 127.

\vskip1.000000\baselineskip

Causas de liberación definidas en las recomendaciones GSM TS 07.07, véase la tabla 5.1-2

El resto de valores entre 128 y 255 quedan reservados.

\vskip1.000000\baselineskip

Causas recomendadas adicionales, véase la tabla 5.1-3 5.2 Apéndice 2: Acceso directo/indirecto al conjunto de comandos AT

Los comandos AT enumerados en la tabla 5.2-1 se han extraído de GSM 07.07, "AT command set for GSM Mobile Equipment (ME)" [2]. Se utilizan en el subsistema de comunicación.

5.3 Apéndice 3: Secuencia de mensajes y primitivas de servicio del protocolo TASP4

A continuación se describen la secuencia de mensajes y las primitivas de servicio del protocolo TASP4, presentados en el capítulo 2.2.1-5.

Secuencia de mensajes, véase la ilustración 2.2.1-5

Ilustración 2.2.1-5: Marco del nivel TASP4.

Indicador de inicio

El indicador de inicio marca el comienzo del frame. Está compuesto por una secuencia de bits 01111110. No existirá indicador de fin. El final del mensaje se indica por medio de un indicador de extensión.

El indicador de inicio normalmente no forma parte del nivel 4; sin embargo, posibilita la transferencia basada en línea en rutas con un protocolo de nivel 2 (canal de datos transparente).

\newpage

Campo de dirección LAPB no necesario

Como sólo un usuario tendrá acceso al protocolo de transporte, no es necesario disponer de un campo de dirección. La tarea del campo de dirección en el protocolo LAPB, es decir, distinguir entre comando y respuesta, la lleva a cabo el bit C/R en el campo de indicador de extensión. El multiplexado de varias conexiones puede ejecutarlo la aplicación que gestiona un campo de dirección dentro del campo de datos (desde el punto de vista del nivel TASP4).

Campo de control

El campo de control está compuesto por un octeto. Existen tres formatos diferentes: formato I, formato S y formato U (véase la ilustración 2.2.1-6).

Ilustración 2.2.1-6: Campo de control

N(S) -

El transmisor envía el número de secuencia

N(R) -

El transmisor recibe el número de secuencia

I -

Frame de información

S -

Frames de supervisión

U -

Frames sin numerar

P/F -

Bit sondeo en caso de comando; bit final en caso de respuesta

\vskip1.000000\baselineskip

La codificación de bits exacta se muestra en la ilustración 2.2.1-7; se corresponde al formato LAPB:

Ilustración 2.2.1-7: Codificación según formato LAPB

I -

Información

RR -

Listo para recepción

RNR -

No listo para recepción

REJ -

Rechazo

SABM -

Establecer modo equilibrado asíncrono

DM -

Desconectar modo

UI -

Información sin numerar

DISC -

Desconectar

UA -

Reconocimiento sin numerar

N(S) -

El transmisor envía el número de secuencia

N(R) -

El transmisor recibe el número de secuencia

P/F -

Bit sondeo en caso de comando; bit final en caso de respuesta

P -

Bit de sondeo

F -

Bit final

El protocolo necesario para utilizar el parámetro de campo de control se describe en la recomendación CCITT X.25 [7] o Q.921.

Definición de parámetros:

tamaño de ventana = 3

\quad

número de repeticiones previo al envío de un mensaje de error al nivel superior = 6; temporizador de repetición = por definir, en función del servicio portador

Campo de indicador de extensión

El campo de indicador de extensión consta de un indicador de extensión, un bit C/R, un bit M y un bit EL (véase la ilustración 2.2.1-8).

Ilustración 2.2.1-8: Campo de indicador de extensión

L -

indicador de extensión

C/R -

bit de comando/respuesta

M -

bit de más datos

EL -

bit de ampliación del campo de indicador de longitud

L - Indicador de extensión

En frames UI e I, el indicador de extensión define la extensión del campo de datos en octetos. Si el indicador de extensión es de 5 bits (véase la ilustración 2.2.1-8), la extensión del campo de datos se situará entre 0 y 31 octetos. Si el campo de datos es mayor que 31 octetos, se ampliará el campo de indicador (véase bit EL).

C/R - Bit de comando/respuesta

El bit C/R se establece en 0 si se envía un comando y en 1, si se envía una respuesta.

M - Bit de más datos

La función del bit de más datos consiste en la segmentación de los mensajes. El bit M con un valor 1 indica que forma parte (segmento) de un mensaje largo coherente.

En cambio, si el bit M tiene el valor 0 y el bit M del mensaje precedente también era 0, el campo de información contiene el mensaje completo.

Si el bit M se establece en 0 y el bit M del mensaje anterior es 1, el campo de información contiene la última parte (segmento) de un mensaje más largo.

El bit M sólo es relevante en el caso de los frames I. Para los otros frames, el bit M se establece en 0.

EL - Bit de ampliación del campo de indicador de extensión

La función del bit EL es ampliar el indicador de extensión. Si se establece en 0, indica el último octeto del indicador de extensión. Si se establece en 1, le sigue otro octeto que pertenece al campo de indicador de extensión.

Si un campo de datos tiene una extensión comprendida entre 0 y 31 octetos, basta con la codificación siguiente del campo de extensión (ilustración 2.2.1-9). En ese caso, el bit EL se establece en 0.

Ilustración 2.2.1-9: Campo de indicador de extensión para un campo de datos con extensión comprendida entre 0 y 31 octetos

Si el campo de datos tiene más de 31 octetos, el campo de indicador de extensión puede ampliarse con la ayuda del bit EL (véase la ilustración 2.2.1-10). En dicho caso, la extensión del campo de datos puede situarse entre 16 y 4.095 octetos.

Ilustración 2.2.1-10: Campo de indicador de extensión ampliado

Campo de información

El campo de información contiene los datos del nivel de la aplicación. Puede alcanzar una extensión de 4.095 octetos.

Campo de secuencia de comprobación de frames

El campo de secuencia de comprobación de frames tiene una extensión de dos octetos.

El polinomio generador es x^{16} + x^{12} + x^{5} + 1.

Primitivas de servicio

Las primitivas de servicio entre el nivel superior y el nivel de transporte son:

T-Connect - Request

T-Connect - Indication

T-Connect - Response

T-Connect - Confirm

T-Data - Request

T-Data - Indication

T-Unitdata - Request

T-Unitdata - Indication

T-Disconnect - Request

T-Disconnect - Indication

T-Disconnect - Confirm

T-Error - Indication

Las primitivas de servicio entre el nivel de transporte y el nivel inferior (capa de red) son:

N-Data - Request

N-Data – Indication.

5.4 Apéndice 4: Definición de los valores de estructuras de superframes

Se definen los siguientes valores para estructuras de superframes. La especificación detallada de dichos valores es objeto de posteriores estudios.

<SRC> y <DEST>^{3}:

\;

0x000 . . . 0x0FFF

funciones básicas

\quad

gsm_........

\quad

gsm_........

\quad

gps_........

\quad

gps_........

\quad

gps_........

\quad

cim_........

\quad

cim_........

\quad

cim_........

\quad

io_.........

\quad

io_.........

\quad

io_.........

0x1000 . . . 0x10FF

aplicaciones para la orientación de rutas dinámicas

\newpage

0x1100 . . . 0x11FF

aplicaciones para la adquisición de datos flotantes del vehículo

0x1200 . . . 0x12FF

aplicaciones para la gestión de flotas

0x1300 . . . 0x13FF

aplicaciones para información viaria

0x1400 . . . 0x14FF

aplicaciones para servicios de averías de emergencia

0x1500 . . . 0x15FF

aplicaciones para protección antirrobo

0x1600 . . . 0x16FF

aplicaciones para pago de peajes automático

0x1700 . . . 0xFFFF

reservado

<TRANS_NO>: módulo 256

<PRIO>:

1 \hskip0,8cm nivel de prioridad máxima

\quad

2

\quad

. . .

\quad

n \hskip0,8cm nivel de prioridad mínima

("n" depende de la definición del capítulo anterior correspondiente)

<TIME>: mm_dd_hh_mm_ss:

mm: mes: 0. . .12

\quad

dd: día: 0. . .31

\quad

hh: hora: 0. . .23

\quad

mm: minuto: 0. . .59

\quad

ss: segundo: 0. . .59

El intervalo de valores de las aplicaciones podría utilizarse también como valores para la ASI.

6. Documentos de referencia [1] ORGA Kartensystem GmbH: "IntraGSM - Basisfunktionen des Chipkarten-Interface-Moduls", Versión 1.00, 20-9-1995 [2] European Telecommunications Standards Institute: "European digital cellular telecommunications system (Phase 2); AT command set for GSM Mobile Equipment (ME), (GSM 07.07)", borrador, noviembre de 1995 [3] European Telecommunications Standards Institute: "European digital cellular telecommunications system (Phase 2); Use of Data Terminal Equipment - Data Circuit Terminating Equipment (DTE - DCE) interlace for Short Message Service (SMS) and Cell Broadcast Service (CBS), (GSM 07.05)", borrador, diciembre de 1995 [4] DeTeMobil: "Intelligente Verkehrstelematik - die Zukunft mit IntraGSM", folleto de DeTeMobil 1995, Bonn [5] Dr. W. Kremer, R. Mertens: "Verkehrstelematik in GSM", en: "Telematik im Stra\betaenverkehr", Springer Verlag, 1995 [6] Dr. W. Kremer: "GSM-based Road Pricing in the Framework of Traffic and Transport Telematics", conferencia ibc Chipcard 1994, Londres [7] The International Telegraph and Telephone Consultative Committee (CCITT): "X.25, Interface between Data Terminal Equipment (DTE) and Data Circuit-Terminating Equipment (DCE) for Terminals Operating in the Packet Mode and Connected to Public Data Networks by Dedicated Circuit", en: "Data Communication Networks: Services and Facilities, Interfaces", volumen VIII, Ginebra 1989 [8] ORGA Kartensysteme GmbH: "Multifunktionale Chipkarte für Verkehrstelematik (IntraGSM-Chipkarte)", versión 1.00, 19-9-1995

[9] F. Zijderhand: "SOCRATES: applications and architecture", pp. 315-334, en: Philips Journal of Research, Edición especial en SOCRATES, volumen 48, n.º 4, 1994.

\newpage

Abreviaturas

API

Interfaz de programación de aplicaciones

ASI

Identificador de servicios de aplicaciones

BS

Servicio portador

CIM

Módulo de interfaz de tarjeta de chip

CLI

Identidad de línea llamante

CLIP

Presentación de la identidad de línea llamante

CLIR

Restricción de la identidad de línea llamante

CPU

Unidad central de procesamiento

CRC

Comprobación de redundancia cíclica

CST

Tabla de servicios de comunicación

DGPS

Sistema de posicionamiento global diferencial

DISC

Mensaje desconectar

E/S

Entrada/salida

EPE

Error estimado de posición

ETSI

European Telecommunications Standards Institute

GPS

Sistema de posicionamiento global

GNSS

Sistema global de navegación por satélite

GPRS

Servicio general de radio por paquetes

GSM

Sistema de global de comunicación móvil

HDLC

Control de enlace de datos de alto nivel

IntraGSM

Sistema global de tráfico internacional para comunicaciones móviles

LAPB

Procedimiento de acceso a línea en canal B

MCC

Código móvil de país

MNC

Código móvil de red

MO

Originado en móvil

MOC

Llamada originada en móvil

MT

Terminado en móvil

MTC

Llamada terminada en móvil

OSI

Interconexión de sistemas abiertos

PDS

Datos en paquete en servicio de canales de señalización

PLMN

Red móvil pública terrestre

RNR

No listo para recibir

RTCM

Radio Technical Comisión for Maritime Services

SABM

Establecer modo equilibrado asíncrono

SCI

Interfaz estándar de comunicaciones

SMS

Servicio de mensajería corta

SMS-MO

Servicio de mensajería corta iniciado en móvil

SMS-MT

Servicio de mensajería corta terminado en móvil

SS

Servicio suplementario

TASP4

Protocolo de seguridad de aplicaciones telemáticas

TCP

Protocolo de comunicaciones de transporte

TOP

Tipo de posición

TS

Teleservicio

TV

Telemática viaria (Verkehrstelematik).

Claims (11)

1. Terminal telemático viario que comprende: un sistema de base con varios subsistemas intercambiables, incluyendo como mínimo un subsistema de comunicación, un subsistema de ubicación, un subsistema de control de acceso y un subsistema de entrada/salida, proporcionando cada subsistema varias funciones básicas, caracterizado por una interfaz de programación de aplicaciones, API, adaptada para permitir la implementación de aplicaciones específicas y adaptada ulteriormente para admitir interacciones de comunicación desde los subsistema del sistema de base a los módulos de aplicaciones, desde los módulos de aplicaciones a los subsistemas del sistema de base, desde centros de servicios a los módulos de aplicaciones y desde los módulos de aplicaciones a centros de servicios a través del subsistema de comunicación, y entre módulos de aplicaciones del mismo fabricante y entre módulos de aplicaciones de distintos fabricantes; y una unidad de enrutamiento y de control de acceso con una parte de control de enrutamiento que enlaza la interfaz de programación de aplicaciones, API, con los subsistemas y las funciones básicas suministradas por el subsistema de comunicación entre las aplicaciones implementadas y las funciones básicas, y una parte de control de sistema para operar las funciones básicas.

2. Terminal telemático viario según la reivindicación 1 caracterizado por el hecho de que el subsistema de comunicación está conectado a una red GSM a través de un módulo GSM.

3. Terminal telemático viario según las reivindicaciones 1 o 2 caracterizado por el hecho de que el subsistema de ubicación comprende una interfaz con un módulo GPS.

4. Terminal telemático viario según cualquiera de las reivindicaciones de la 1 a la 3 caracterizado por el hecho de que el subsistema de control de acceso comprende una interfaz para un lector de tarjetas de chip.

5. Terminal telemático viario según cualquiera de las reivindicaciones de la 1 a la 4 caracterizado por el hecho de que el subsistema de entrada/salida incluye un dispositivo de entrada/salida.

6. Terminal telemático viario según cualquiera de las reivindicaciones de la 1 a la 5 caracterizado por el hecho de que cada subsistema está provisto de una interfaz estándar de comunicaciones, SCI, para el acceso directo o indirecto desde aplicaciones o dispositivos externos o hacia éstos.

7. Método para operar un terminal telemático viario según la definición de las reivindicaciones de la 1 a la 6 en el que las funciones básicas proporcionadas por los subsistemas de comunicación, ubicación, control de acceso, entrada/salida e interfaz estándar de comunicaciones, SCI, se asignan a un sistema de base, dicho método caracterizado por el hecho que las mencionadas funciones básicas se utilizan para hacer funcionar y/o controlar las aplicaciones implementadas a través de una interfaz de programación de aplicaciones, API, en la cual una unidad de enrutamiento y control de sistema interactúa entre las aplicaciones y las funciones básicas, al tiempo que varias aplicaciones pueden hacerse funcionar a la vez compartiendo los mismos subsistemas.

8. Método según la reivindicación 7 caracterizado por el hecho de que se utiliza una interfaz estándar de comunicaciones, SCI, para conectar y comunicar los subsistemas.

9. Método según las reivindicaciones 7 u 8 caracterizado por el hecho de que la conexión entre las aplicaciones y los subsistemas se establece por una función de enrutamiento y control de acceso; mientras que el enrutamiento se limita a dirigir las tareas, el control del sistema se encarga de supervisar las funciones y de registrar fallos y errores.

10. Método según una de las reivindicaciones de la 7 a la 9 caracterizado por el hecho de que pueden establecerse conexiones a la red GSM mediante el subsistema de comunicación.

11. Método según una de las reivindicaciones de la 7 a la 10 caracterizado por el hecho de que el subsistema de ubicación recibe los datos de ubicación mediante un receptor GPS.