aacn en la argentina - materias.fi.uba.armaterias.fi.uba.ar/7500/guillermodanielpolonsky.pdf ·...
TRANSCRIPT
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 1
AACN en la Argentina
Tesis de Grado en Ingeniería en Informática
Tesista: Guillermo D. Polonsky (79492) [email protected]
Directora: Lic. Adriana Echeverría
Facultad de Ingeniería
Universidad de Buenos Aires
Octubre 2012
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 2
A G R A D E C I M I E N T O S
A mis padres, Raquel y Roberto, a quienes admiro profundamente, quienes siempre me han
apoyado en todos los órdenes de la vida y han estado conmigo durante todos mis años de
estudio, dándome la fuerza necesaria para seguir adelante en todo momento.
A Vale, mi novia, por aguantar, por estar a mi lado y por comprender todo el tiempo que
muchas veces debí emplear para la presente tesis.
A mi directora, Adriana Echeverría, por haber escuchado cuál era la motivación por la cual
quería hacer la tesis y haberme ayudado a transitar el camino hacia su realización y
completitud.
A mi hermano Walter, al resto de mi familia y a todos mis amigos que escucharon una y otra
vez excusas para no salir, no juntarme a vernos, etc. para poder estudiar y leer.
Finalmente, a mis compañeros de facultad con quienes compartí tantas horas estudiando y de
manera especial a mis profesores, a quienes admiro profundamente por tener esa vocación de
día tras día y a pesar de todo, presentarse en la facultad para enseñar y transmitir sus
conocimientos a los demás.
A todos ustedes un GRAN GRACIAS DE CORAZON!
Guillermo D. Polonsky
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 3
I N D I C E G E N E R A L
Introducción ...................................................................................................................................................................................................................... 6
1.1 Advanced Automatic Collision Notification (AACN) .............................................................................................................................. 9
1.2 Posibles acciones automáticas ante un choque ..................................................................................................................................... 10
1.3 AACN mediante un celular............................................................................................................................................................................... 13
1.4 Cómo funciona OnStart ..................................................................................................................................................................................... 13
1.5 Cómo funcionará el sistema eCall en Europa ......................................................................................................................................... 16
1.6 Sistemas relacionados en Estados Unidos ............................................................................................................................................... 25
1.6.1 Enhanced 911 o 911 Mejorado (E911) ................................................................................................................................................. 25
1.6.2 Próxima Generación de 9-1-1 (NG911) ................................................................................................................................................. 25
2.1 Navegación Satelital ........................................................................................................................................................................................... 28
2.2 GPS .............................................................................................................................................................................................................................. 29
2.2.1 Datos del mensaje GPS................................................................................................................................................................................... 29
2.3 Sistema de Posicionamiento Global Diferencial (DGPS) ................................................................................................................... 31
2.4 Fuentes de error en GPS ................................................................................................................................................................................... 32
2.4.1 Disponibilidad selectiva o Selective Availability .............................................................................................................................. 32
2.4.2 Geometría de los satélites ............................................................................................................................................................................ 33
2.4.3 Dilución de la precisión (GPS) (más sobre la geometría de los satélites) ............................................................................ 35
2.4.5 Efecto Multipath o Multicamino ................................................................................................................................................................ 37
2.4.6 Efectos Atmosféricos ...................................................................................................................................................................................... 37
2.4.7 Inexactitudes y errores de redondeo de reloj .................................................................................................................................... 39
2.4.8 Los efectos relativistas .................................................................................................................................................................................. 39
2.5 GPS de Alta Sensibilidad ................................................................................................................................................................................... 41
2.6 Localización mediante la red de datos....................................................................................................................................................... 41
2.6.1 Cómo se obtiene y algunas técnicas existentes .................................................................................................................................. 41
2.6.2 Cómo funciona en Android .......................................................................................................................................................................... 44
2.7 GPS Asistido (A-GPS) - Uso del GPS en el celular .................................................................................................................................. 44
2.7.1 Descripción ......................................................................................................................................................................................................... 44
2.7.2 ¿Por qué AGPS? ................................................................................................................................................................................................. 45
2.7.3 Razones de creación del AGPS ................................................................................................................................................................... 46
2.7.4 Ventajas y Desventajas .................................................................................................................................................................................. 47
2.7.5 ¿Cómo hace el GPS Asistido para obtener la ubicación si sólo 2 satélites están disponibles? .................................... 48
2.7.6 Configuraciones A-GPS .................................................................................................................................................................................. 48
3.1 Iniciativas de Estandarización de Datos XML existentes .................................................................................................................. 52
3.2 Model Minimum Uniform Crash Criteria (MMUCC) ............................................................................................................................ 53
3.2.1 ¿Qué es el MMUCC? ......................................................................................................................................................................................... 53
3.2.2 Organización de los Elementos de Datos MMUCC ............................................................................................................................ 54
3.2.3 Composición de los grupos de datos MMUCC por características ............................................................................................ 54
3.3 VEDS - Vehicular Emergency Data Set (2004) ....................................................................................................................................... 57
3.3.1 Descripción ......................................................................................................................................................................................................... 57
3.3.2 Estructura de VEDS ......................................................................................................................................................................................... 58
3.4 CAP - Common Alerting Protocol V1.2 (2010) ...................................................................................................................................... 59
3.4.1 Descripción ......................................................................................................................................................................................................... 59
3.4.2 Estructura de un mensaje de alerta CAP ............................................................................................................................................... 60
3.4.3 Aplicaciones del Mensaje de Alerta CAP ............................................................................................................................................... 61
3.4.4 Beneficios ............................................................................................................................................................................................................. 61
3.4.6 Estructura de un Mensaje de Alerta CAP .............................................................................................................................................. 63
3.5 IEEE 1512 ................................................................................................................................................................................................................ 67
3.5.1 Descripción ......................................................................................................................................................................................................... 67
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 4
3.5.2 La familia de estándares ............................................................................................................................................................................... 67
3.5.3 Beneficios ............................................................................................................................................................................................................. 68
3.6 Emergency Data Exchange Language (EDXL) Distribution Element, v. 1.0............................................................................. 68
3.6.1 Descripción ......................................................................................................................................................................................................... 68
3.6.2 Estructura del Elemento de Distribución EDXL ................................................................................................................................ 69
3.6.3 Estructura de un Mensaje de Alerta EDXL-DE ................................................................................................................................... 72
3.7 Minimum Data Set (MDS) – Usado por eCall .......................................................................................................................................... 73
3.8 Full Set of Data (FSD) ......................................................................................................................................................................................... 80
3.9 Protocolos propuestos ...................................................................................................................................................................................... 83
3.9.1 Urgency Data Set - UDS ................................................................................................................................................................................. 83
3.9.2 Emergency Data Set -EDS ............................................................................................................................................................................. 84
4.1 Sensores en el celular ........................................................................................................................................................................................ 87
4.2 Sistema de coordenadas en Android .......................................................................................................................................................... 88
4.3 Obtención de la fuerza G aplicada en el dispositivo móvil en un choque ................................................................................. 89
4.4 ¿Cómo saber si es un choque?........................................................................................................................................................................ 89
4.5 Evitar falsos positivos ........................................................................................................................................................................................ 92
4.6 Programa para probar los sensores ............................................................................................................................................................ 93
4.7 Velocidad de la toma de muestras ............................................................................................................................................................... 95
5.1 Diagrama de despliegue ................................................................................................................................................................................... 96
5.2 Explicación general del funcionamiento del sistema ......................................................................................................................... 97
5.3 Web Services accedidos desde un celular ................................................................................................................................................ 98
5.4 Tecnologías de comunicación inalámbricas ........................................................................................................................................... 98
5.5 Web Services -Introducción .......................................................................................................................................................................... 102
5.6 Comunicación desde el celular al servidor. ¿Web Services basados en SOAP o en REST? ............................................. 103
5.6.1 SOAP - Simple Object Access Protocol ................................................................................................................................................. 103
5.6.2 REST – Representational State Transfer ............................................................................................................................................. 103
5.7 ¿Qué son los URIs? ............................................................................................................................................................................................ 104
5.8 ¿Cuáles son los principios de REST? ......................................................................................................................................................... 105
5.9 ¿Cómo se manejan los recursos? ................................................................................................................................................................ 105
5.10 Servicios con estado vs. sin estado ........................................................................................................................................................ 105
5.11 Flujo de manejo de mensajes UDS .......................................................................................................................................................... 110
5.12 Diagrama de secuencia del manejo de los mensajes UDS ............................................................................................................ 111
5.13 Diagrama de Secuencia del celular hasta que se detecta el choque........................................................................................ 112
5.14 Diagrama de Secuencia del Celular luego de detectarse un choque ....................................................................................... 113
5.15 Detalle del Diagrama de Despliegue ...................................................................................................................................................... 114
5.16 Jobs de SQL Server .......................................................................................................................................................................................... 114
5.17 Limitantes al usar un celular ..................................................................................................................................................................... 115
5.18 Cada cuánto obtener las coordenadas del celular ........................................................................................................................... 115
5.19 Información que se transmitirá, ¿Qué parte, bajo qué conexión? ........................................................................................... 117
5.20 Consideraciones al usar procesos en background en Android ................................................................................................. 118
5.21 Evitar falsos positivos ................................................................................................................................................................................... 118
5.22 Detección del Accidente ............................................................................................................................................................................... 119
5.23 Logueo de información de los sensores ............................................................................................................................................... 119
5.24 Configuración .................................................................................................................................................................................................... 120
5.25 Long Pooling ...................................................................................................................................................................................................... 120
5.26 Controladores Asíncronos en ASPNET MVC 3 ................................................................................................................................. 123
5.26.1 Cómo se procesan los request desde el pool de threads .......................................................................................................... 123
5.26.2 Procesando requests asíncronos ......................................................................................................................................................... 123
5.26.3 Cómo funcionan los controllers asíncronicos................................................................................................................................ 124
5.27 Elección del tipo de servicio background: Threads, AsyncTask e IntentService.............................................................. 125
5.28 Guardado de ubicaciones y lecturas de los sensores ..................................................................................................................... 126
5.29 Por qué usar ASPNET MVC, Razor y no webforms ......................................................................................................................... 127
5.30 Mapa en el servidor ........................................................................................................................................................................................ 127
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 5
5.31 Location Mock Provider para Android ................................................................................................................................................. 127
5.32 Exactitud de la posición en Android ...................................................................................................................................................... 128
5.33 Diagrama de Base de datos ........................................................................................................................................................................ 129
5.34 Por qué un ORM? Por qué Entity Framework 4? ............................................................................................................................. 158
5.35 Capturas de Pantallas – Servidor ............................................................................................................................................................. 159
5.37 Diagrama de Entity Framework ............................................................................................................................................................... 168
5.38 Creación de un registro Crash ................................................................................................................................................................... 171
5.39 Diagrama de clases de la aplicación Android .................................................................................................................................... 173
6.1 Conclusiones y Líneas de investigación futura .................................................................................................................................... 181
6.2 Algoritmo Urgency ............................................................................................................................................................................................ 183
6.3 Computadoras de abordo .............................................................................................................................................................................. 186
6.3.1 OBD-II .................................................................................................................................................................................................................. 186
6.3.2 EOBD .................................................................................................................................................................................................................... 188
Apendice ........................................................................................................................................................................................................................ 189
Referencias ................................................................................................................................................................................................................... 194
Bibliografía ................................................................................................................................................................................................................... 199
Glosario .......................................................................................................................................................................................................................... 203
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 6
C A P Í T U L O 1
INTRODUCCIÓN
Motivación de la tesis
Este trabajo se orientó a la presentación del marco teórico enfocado a mejoras futuras en
relación con los accidentes en la vía pública, que sirviera para desarrollar un modelo que
posibilitara el desarrollo de algún producto útil a la mayor cantidad de personas, con el objeto
de mejorar la vida de las mismas. Por esta razón, se decidió investigar de qué manera se
podría ayudar al común de la gente, con la tecnología actual, sin tener que incurrir en altos
costos de implementación ni acuerdos gubernamentales. Es así, que el tema de AACN fue el
elegido para la misma.
AACN son las siglas en inglés para Advanced Automatic Collision/Crash Notification, y es una
evolución del ACN que significa Automatic Collision/Crash Notification. Este tipo de sistemas,
ha probado ser la razón por la cual ha disminuido la cantidad de víctimas fatales en los
accidentes de tránsito en EEUU. Básicamente, se trata de que un dispositivo en un automóvil,
camión, etc., pueda recabar información, de manera automatizada, asociada a un accidente
cuando este ocurre (por ejemplo, delta de velocidad, dirección en la que se movía, lugares que
han sido golpeados, si hubo un vuelco del vehículo, si se usaron los cinturones de seguridad,
etc.) y enviar dicha información a una central que pueda analizar el tipo de ayuda necesaria
para el accidente en particular, como ser, cantidad de ambulancias necesarias, envío de una
grúa para remover el/los vehículo/s o no, envío de helicóptero, etc., además de alertar a los
servicios de emergencias y decidir dónde convendría derivar a los afectados sobre la base de
cantidad de camas disponibles, tipo de complejidad que el hospital está preparado para tratar,
etc. y en su versión más avanzada sobre la base de un índice que indica la gravedad que podría
revestir el herido.
En el capítulo uno se ve cómo en países como Estados Unidos, cada vez más automóviles
vienen preparados de fábrica con el hardware necesario para hacer uso de dicho sistema, por
ejemplo muchos automóviles fabricados por General Motors, los cuales se conectan con el
sistema del proveedor OnStar. En Europa el sistema eCall está terminando de desarrollarse y
tiene el mismo fin, sólo que en este caso abarca más de un país. Si bien la arquitectura es
distinta, el objetivo es el mismo: Salvar vidas llegando al lugar del accidente y ofreciendo
ayuda a los lesionados de la manera más rápida posible. Además, se verá cómo un sistema
como este podría haber salvado la vida de muchas personas víctimas de accidentes
automovilísticos en la Argentina, en los cuales no se ha podido llegar a tiempo al lugar del
mismo, dejando pasar la llamada “Golden Hour”, aquella hora posterior al accidente donde se
tienen las mayores posibilidades de ayudar y/o salvar la vida de las víctimas.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 7
Se verá que si bien el sistema ya existe en otras partes del mundo, en Argentina los
automóviles no suelen traer el hardware necesario para hacer uso del AACN y aun cuando
hubieran contado con el mismo, Argentina no ofrece ni la infraestructura ni los proveedores
necesarios para posibilitar el uso de la información correspondiente. Esta es la razón por la
cual se buscará una arquitectura que permita hacer uso del AACN en Argentina y que dicho
uso esté dado por la mayor cantidad de gente, sin que sea necesario tener un automóvil de
alta gama con dicho hardware integrado de fábrica.
Desde la introducción de la navegación satelital en los años ’70, las aplicaciones para el
posicionamiento de datos han crecido más allá de todas las expectativas. Hoy, millones de
pequeños receptores portátiles capaces de recibir señales de satélite son vendidos
anualmente, incluso dentro de celulares.
Actualmente, se observan satélites orbitando la tierra continuamente, estos satélites
transmiten datos que pueden ser procesados por receptores GPS (Global Positioning System).
Estos datos transmitidos por los satélites luego son usados para determinar la ubicación del
receptor con una precisión de metros o incluso menos, dependiendo del tipo de receptor y la
tecnología involucrada.
En el capítulo dos, se hará una introducción acerca de cómo puede comunicarse un dispositivo
móvil con los satélites GPS para obtener su posición y en caso de no contar con GPS, cómo
poder obtener su posición a través de la red celular.
En el capítulo tres se analizará la interoperabilidad del sistema.
Existen muchos celulares distintos, y el despliegue del sistema completo debe tener la menor
complejidad posible así como la mayor posibilidad de uso de la infraestructura existente. La
interoperabilidad es más que comunicación por voz, tanto las organizaciones como los
sistemas no pueden compartir fácilmente información de incidentes si no hay
interoperabilidad clara entre todas las partes involucradas. Finalmente, se proponen dos
protocolos para los envíos de mensajes entre el celular y el servidor.
Para la interacción entre los distintos entes, es vital tener un lenguaje común entre las
distintas aplicaciones, y de esta forma poder crear reportes históricos con información
distribuida entre los distintos sistemas. Esto hace necesaria la creación de protocolos y
estándares comunes a todas las aplicaciones.
Se verá un resumen de los protocolos y estándares existentes en distintas partes del mundo,
en relación a incidentes de tráfico y alertas en general y luego se mostrará una propuesta de
mensajes a ser enviados desde el celular al servidor, de manera que ayuden a disminuir y/o
prevenir los heridos en accidentes viales, así como obtener estadísticas a partir de diversa
información recabada.
En el capítulo cuatro se analiza la detección del choque, una parte fundamental del sistema.
Esto permite alertar a las autoridades y servicios de emergencia la necesidad de enviar la
ayuda de forma inmediata ya que ha ocurrido un siniestro, pero no es todo. Tan importante
como detectar un choque es no detectar e informar un choque cuando, en realidad, no ha
ocurrido. El alerta dispararía la movilización de la policía, ambulancias, potencialmente
bomberos, etc. y falsas alertas provocarían un mal gasto de recursos de todo tipo, por lo cual
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 8
es muy importante tanto la detección como el no informar de un falso accidente, lo cual se
mostrará también.
El capítulo cinco es donde se analiza la propuesta de arquitectura. En este capítulo se hará un
breve repaso de las tecnologías de comunicación celular existentes.
En la arquitectura propuesta, el sistema no sólo transmitirá la mayor cantidad posible de
datos sobre el accidente, sino que también transmitirá la posición en la cual ocurrió el mismo.
Si bien los vehículos que tienen integrado AACN de fabrica pueden acceder a información tal
como si los cinturones de seguridad estaban siendo utilizados, cuántos ocupantes había, en
qué sectores del vehículo se produjeron los choques, etc., lo que se desarrolla en esta tesis, es
encontrar una manera de detectar el choque y enviar la mayor cantidad de información
posible a una central sin tener el sistema integrado en el auto, sino teniendo un celular con
acelerómetros y GPS. Si bien no toda la población cuenta con un celular de estas
características, cada vez se pueden ver más en el mercado, haciéndose más comunes, por lo
que se descarta que en el mediano plazo la mayoría de las personas cuenten con al menos uno
en la familia, el cual pueda ser utilizado a tales efectos.
La central recibirá la información de todos los choques y luego analizará y enviará la
información a quién corresponda. Dependiendo de cuán informatizados estén los entes de
emergencias en Argentina, se podrá saber: cantidad de ambulancias necesarias, a qué centro
de emergencia se podrá derivar a los accidentados, si resulta necesario enviar una grúa, etc. Si
la información acerca de los hospitales, policía y bomberos no se encontrara disponible (por
ejemplo, por no tener un sistema informatizado e interconectado entre los tres entes en
Argentina), se informará al servicio del 911, el cual podrá hacer el despacho del alerta a quien
corresponda, tal como lo hace actualmente mediante un llamado telefónico.
Este tipo de sistemas permitirá también que en el futuro se puedan generar reportes de los
accidentes de tránsito para encontrar cuáles son los puntos que pueden ser mejorados con el
objeto de contar con carreteras y en general, caminos más seguros.
Será extensible de forma que, en principio, se informará al 911, pero luego, si algún ente de
emergencia necesitara recibir esa información, pueda entonces agregarse fácilmente.
Queda fuera del alcance de este trabajo obtener un coeficiente sobre la gravedad de las
lesiones tal como puede hacerlo URGENCY. Este índice sirve principalmente porque en la
actualidad, los autos están hechos para recibir todo el impacto y que no se lesionen los
ocupantes, sin embargo debido a esto los especialistas en emergencias podrían pensar que
alguien no está herido cuando en realidad presenta heridas internas, entonces, de acuerdo a
este índice, se los deriva a un centro de trauma o no.
Queda fuera del alcance de la tesis también los estudios médicos asociados. Para esto se hará
uso de informes y estudios ya realizados por otros entes. También, quedan fuera del alcance
de la tesis un análisis exhaustivo de los posibles métodos de detección de choques, en todo
caso queda abierta la oportunidad para extender este trabajo y posibilitar que alguien con
estudios físicos y/o matemáticos pueda realizar ese trabajo.
Queda fuera del alcance de la tesis la obtención de la posición dentro túneles y demás lugares
donde el GPS no pueda ser utilizado por falta de visualización directa a los satélites.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 9
Finalmente en el capítulo 6 se comentan las posibles futuras investigaciones para extender
este trabajo y así poder mejorar todo el sistema en conjunto y en un futuro poder predecir
mejor los choques, las heridas de las víctimas y mejorar el uso y asignación de los recursos
disponibles.
1.1. Advanced Automatic Collision Notification (AACN)
Este trabajo ha sido inspirado en Advanced Automatic Collision/Crash Notification (AACN), el
cual es una evolución del Automatic Collision/Crash Notification (ACN). Este tipo de sistemas,
ha probado ser la razón de la disminución de víctimas fatales en los accidentes de tránsito en
EEUU. Básicamente, se trata de que un automóvil, camión, etc., pueda recabar información
asociada a un accidente inmediatamente después que este ocurre (por ejemplo, delta de
velocidad, dirección en la que se movía, lugares que han sido golpeados, si ocurrió un vuelco
del automóvil, si se usaron los cinturones de seguridad, etc.). Una vez que se detecta el mismo,
se pone en funcionamiento el mecanismo de alerta, este consiste en hacer una llamada
inalámbrica a una central (si no se cancela el alerta luego de unos pocos segundos), para
enviar la ubicación y los datos relacionados al choque y realizar una comunicación por el canal
de voz al centro de emergencias. AACN agrega a los datos enviados por ACN, los datos de la
severidad del choque recolectados por los sensores dentro del vehículo. Estos datos
permitirán analizar el tipo de ayuda necesaria para el accidente en particular, como ser,
cantidad de ambulancias necesarias, envío de una grúa para remover el/los vehículo/s o no,
envío de helicóptero, etc., además de alertar a los servicios de emergencias y decidir dónde
convendría derivar a los afectados sobre la base de cantidad de camas disponibles, tipo de
complejidad que el hospital está preparado para tratar, etc.
En el caso de un celular, se pueden enviar los datos de los sensores y luego el servidor podría
procesarlos para saber con mejor precisión cómo ocurrió el siniestro.
En países como Estados Unidos, cada vez más automóviles vienen preparados de fábrica con
el hardware necesario para poder hacer uso de dicho sistema, por ejemplo muchos autos
fabricados por General Motors, los cuales se conectan con el sistema del proveedor OnStar.
Un sistema como este podría haber salvado la vida de muchas personas involucradas en
accidentes automovilísticos en Argentina, en los cuales no se ha podido llegar a tiempo al
lugar del mismo, dejando pasar la “Golden Hour”, aquella hora posterior al accidente donde se
tienen las mayores posibilidades de ayudar y/o salvar la vida de las víctimas del mismo.
Si bien el sistema ya existe, en Argentina los automóviles no suelen traer el hardware
necesario para hacer uso del AACN. Tampoco existe un proveedor que pueda hacer uso de la
información correspondiente. Es esta la razón por la cual se buscará un método novedoso que
permita a la mayor cantidad de gente, hacer uso de AACN en nuestro país, sin que sea
necesario tener un auto con dicho hardware embebido en el mismo de fábrica.
Si se dispone de datos adicionales mediante contacto directo verbal con los ocupantes del
vehículo, los mismos deben ser usados para mejorar o modificar el análisis de la situación
inicial recabada mediante los datos de los sensores.
En concreto, conocer el número de ocupantes, edad, género y nivel de conciencia serían
importantes datos adicionales para predecir la gravedad de las lesiones.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 10
Con este sistema se podrían mejorar los resultados en la atención de pacientes accidentados
en siniestros de tránsito:
Disminuyendo los tiempos de respuesta con proveedores de atención pre-hospitalaria.
Asistiendo con el triage1 de las heridas de las personas involucradas en el mismo
momento y las decisiones de transporte necesario.
Disminuyendo los tiempos hasta la atención traumatológica definitiva.
Disminuyendo las muertes y discapacidades producidas como consecuencia de
accidentes de tránsito.
Algunos datos que se pueden intentar obtener en caso de poder establecer una comunicación
con los ocupantes son:
1) Presencia de heridos
2) Número de ocupantes
3) Número de vehículos
4) Edad de los ocupantes
La privacidad de los datos es una cuestión clave.
1.2. Posibles acciones automáticas ante un choque
Hacer sonar un sonido de alarma fuerte a través del celular para ayudar a encontrar el
vehículo fuera de la ruta (posible mejora futura).
Datos de longitud y latitud específicos para asistencia médica aérea.
Mantener conexión de la llamada con los ocupantes hasta que llegue la seguridad
pública.
Comunicar a familiares sobre el accidente.
Alertar a las autoridades para desviar el tráfico.
Enviar fotos a los médicos en camino para poder ir estableciendo un plan de ayuda
médica.
Poner en algún sistema de cartografía como por ejemplo Google Maps o el sistema de
Microsoft la información de choques, tráfico, etc., de manera que los demás autos pudieran
evitar el recorrido sobre el cual se encuentra el siniestro.
Los datos actuales transmitidos de AACN desde el vehículo al proveedor de la telemática
puede mejorar la precisión en la clasificación (triage1) del paciente herido.
Luego, en la central de monitoreo y control de siniestros, se podrían indicar los accidentes en
una pantalla con un mapa.
1 Triage es el proceso con el que se selecciona a las personas a partir de su severidad y necesidad de recibir tratamiento médico
inmediato cuando los recursos disponibles son limitados.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 11
A continuación, se presenta un gráfico que muestra la relación entre la velocidad del choque y
la probabilidad de fatalidad según la escala llamada MAIS2
Figura 1. Relación entre la velocidad del choque y la probabilidad de fatalidad según la escala MAIS2 [1]
Podemos apreciar claramente que luego de 30mph a mayor velocidad la probabilidad
de fatalidad crece de forma brusca.
2 Maximum Abbreviated Injury Scale (MAIS) es una escala creada por la American Association for Automotive Medicine, la cual
clasifica y describe la severidad de las heridas de los individuos.
Código MAIS Heridas
0 Sin heridas
1 Menor
2 Moderado
3 Serio
4 Severo
5 Critico
6 Máximo
9 No Especificado
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 12
Figura 2. Período crítico de lesiones graves en accidentes de tráfico [2]
Sería muy importante poder informatizar hospitales, comisarías, departamentos de
bomberos, etc. de manera de unificar la recopilación y análisis de los datos sobre los distintos
choques que se van produciendo en las calles y rutas. Esto debería estar integrado de la mayor
manera posible con los actuales sistemas nacionales de datos. De esta forma, serviría, entre
otras cosas, para alertar a todos los servicios de emergencias a la vez, sin mediadores como en
la actualidad, donde quizás debe haber alguien que se conecte mediante un Handy para poder
informar de las distintas situaciones.
[3] Se han hecho estudios para correlacionar las características previas al choque y del
choque mismo con el tipo y la gravedad de las lesiones en accidentes automovilísticos y sus
resultados. AACN proporciona una información rápida, precisa y objetiva y métricas que,
cuando son interpretadas por personal médico de emergencia experto, puede ayudar a tomar
decisiones críticas, tales como:
La unidad apropiada de servicios de emergencia requerida (soporte de vital básico versus
avanzado)
El modo de transporte (por tierra versus ambulancia aérea)
La instalación médica correcta (el hospital más cercano o centro regional de trauma)
La movilización de los profesionales especializados (neurocirujanos, ortopedistas, etc.)
La preparación de los recursos médicos (sala de emergencias, quirófano, etc.)
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 13
Algunos de los datos que puede proveer AACN (según el auto), son:
Número del proveedor de servicios como OnStar por ejemplo, al cual llamaría el
PSAP
Horario de recepción
Latitud y Longitud
Diferencia de velocidad anterior y posterior al impacto (Delta V), Dirección de la
fuerza en el choque
Si los airbags fueron activados
Marca, modelo, color año de fabricación, etc. del automóvil.
Información de vuelco (si está presente y disponible)
Si hubo impactos múltiples
Poner en algún sistema de cartografía como por ejemplo Google Maps o el sistema
de Microsoft la información de choques, tráfico, etc., para poder evitarlo.
Sería muy interesante poder sacar fotografías y/o aún mejor que la ambulancia llevase
equipos de rayos X portátiles los cuales pudiesen transmitir al hospital, el resultado del
trauma seleccionado para poder ir haciendo un análisis en caso de necesitar cirugía, por
ejemplo.
1.3 AACN mediante un celular
Al usar un celular para la detección de un choque hay muchos factores de suma importancia,
entre los que se encuentran:
Batería limitada
Velocidad de conexión limitada
Velocidad de muestreo del GPS
Velocidad de muestreo del acelerómetro.
Es por ello que al crear una arquitectura para el mismo deben tenerse en cuenta estos
parámetros.
1.4 Cómo funciona OnStart
1. El diseño de ingeniería y procesos de fabricación integran la tecnología AACN durante
el montaje del vehículo.
2. Un receptor GPS ayuda a localizar el vehículo.
3. Un sistema de comunicación celular de manos libres, ofrece la mayor presencia
geográfica en los EE.UU.
4. El módulo de detección de diagnóstico (Sensing Diagnostic Module) calcula y captura
la información vital de accidentes.
5. Una arquitectura de bus de datos en serie de redes accidente transmite información
de los sensores del vehículo al módulo telemático de OnStar.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 14
6. El módulo telemático de OnStar envía la información que, tras la recepción y
procesamiento electrónico en la base de datos del Call Center de OnStar, aparece en la
pantalla de la computadora de asesores de emergencia de OnStar, especialmente
capacitados.
7. El uso de información de accidentes y métricas generalmente reconocidos se destina a
facilitar el uso de datos por parte de personal de servicio de emergencia.
En el centro de la nueva tecnología de AACN hay sensores conectados a una arquitectura de
red del vehículo de bus de datos en serie (serial data bus vehicle networking architecture).
Las redes o multiplexados de los vehículos permiten una disminución del número de cables
dedicados, costo y peso reducido, al tiempo que aumenta la fiabilidad y capacidad de
servicio. También, permite flexibilidad en términos de contenido y funcionalidad futura.
El módulo de detección de diagnóstico (Sensing Diagnostic Module, SDM) recibe una
perspectiva de 360 grados del choque, de los sensores de choque dedicados a través de la
arquitectura electrónica del vehículo o el bus de comunicaciones en serie (Serial
Communications Bus). El SDM utiliza un sofisticado algoritmo para identificar el tipo y la
gravedad del accidente sufrido por el vehículo. Los acelerómetros internos miden el número,
magnitud y dirección de las fuerzas del impacto en cualquier tipo de choque. Por sobre el
resto de los datos del accidente, la más importantes es la velocidad calculada Delta (Delta V),
una medida de ingeniería de las fuerzas en el accidente. En general, cuanto mayor sea el Delta
V, más grave el accidente.
Los criterios utilizados para seleccionar las métricas de los datos de un choque se basan en el
conocimiento existente entre los principales expertos, de los principales indicadores de la
probabilidad de lesiones corporales. Múltiples fuentes, incluyendo estudios de investigación y
las estadísticas nacionales como el Fatal Accident Reporting System (FARS) del gobierno y el
National Accident Sampling Information System (NASS) apoyaron esta selección.
La salida del módulo de detección de diagnóstico (Sensing Diagnostic Module) se envía al
módulo telemático OnStar del vehículo o la plataforma de comunicaciones de vehículos (VCP),
que alberga el hardware y el software necesario para proporcionar comunicaciones
bidireccionales de voz y datos entre el vehículo y asesores del Call Center de OnStar.
En un choque moderado o grave, el vehículo automáticamente llama a OnStar para pedir
ayuda. Una vez que una conexión celular se ha establecido satisfactoriamente, se produce una
breve transmisión de intercambio de datos entre el módulo de la telemática del vehículo y los
sistemas de Call Center de OnStar.
La información del accidente transmitida resume las métricas clave e incluye:
Ubicación de los vehículos;
Si los airbags frontales y/o laterales fueron desplegados;
Si hubo múltiples impactos;
Si hubo un vuelco (cuando hay disponible un sensor de vuelco),
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 15
El máximo Delta V para el más grave de dos impactos,
Dirección Principal de la fuerza (PDOF) relacionada.
En cuestión de segundos, el sistema cambia de transmisión de datos a modo de voz. Los
asesores se comunican de inmediato con los ocupantes del vehículo a través de la conexión
celular embebida, para recabar información adicional, por ejemplo, saber si el conductor está
consciente y coherente. Entonces, se contacta el Public Safety Answering Point
(PSAPs) adecuado y se le proporciona la ubicación, los datos seleccionados, objetivos y
técnicos y compartidos con los ocupantes del vehículo. Esta información crítica puede
permitir hacer interpretaciones subjetivas tales como la probabilidad de lesiones graves, los
recursos necesarios en el lugar del accidente y el centro médico más adecuado para el
tratamiento de la o las víctimas.
La tecnología AACN está soportando el desarrollo de amplias tecnologías de transmisión de
datos y protocolos de envío. La investigación sobre los incidentes AACN en todo el país
pueden ayudar a los expertos médicos a perfeccionar la tecnología y protocolos existentes,
incluyendo, por ejemplo, el "algoritmo URGENCY", una métrica desarrollada por
investigadores de la William Lehman Injury Research Center de la Universidad de Miami
School of Medicine y la George Washington University, que estima la probabilidad de sufrir
lesiones graves. Se espera que los datos de AACN también ayuden a mejorar las tecnologías de
seguridad de los vehículos.
En la actualidad, la arquitectura abierta de sistemas de OnStar puede transmitir datos a través
de una conexión segura de Internet a un router central o servidor web. Desde allí, los datos
pueden ser transmitidos para su visualización en las computadoras de asistencia de despacho
y monitorización de los servicios de emergencias preparados y autorizados, para que al
instante puedan aprovechar y manejar la información.
A nivel nacional, los Public Safety Answering Points (PSAPs), los servicios médicos de
emergencia y otro personal de respuesta de emergencias comparten sistemas de cartografía
común, protocolos de envío, sistemas abiertos, o estándares y protocolos de transmisión de
datos. El desarrollo eventual de redes y protocolos nacionales que interoperen, reforzaría el
impacto de la tecnología de AACN y permitiría nuevos avances, como la creación de registros
de incidentes seguros y dinámicos, pudiendo actualizarse en tiempo real por las diversas
partes, tan pronto como nueva información de accidentes y lesiones esté disponible.
Luego de un evento de vuelco el Advance Automatic Crash Notification (AACN via OnStar):
Desactiva el sistema HVAC (Heating, Ventilating and Air Conditioning) para limitar
las posibles quemaduras.
Desbloquea las puertas
Enciende las luces
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 16
Un significativo esfuerzo de desarrollo se requiere para desarrollar la electrónica del vehículo,
que incluye:
Colocar sensores electrónicos en el vehículo para recabar datos necesarios para
predecir un vuelco.
Desarrollar el detector de vuelcos - con un algoritmo único para cada vehículo
capaz de identificar una variedad de condiciones de vuelco.
El Módulo de detección y Diagnóstico (SDM) para controlar los sistemas afectados,
como el motor parado, desplegado de airbags, AACN, etc.
1.5 Cómo funcionará el sistema eCall en Europa [4][5][6]
eCall es un sistema automático de servicio de emergencia dentro del vehículo, desarrollado en
la Unión Europea. Un vehículo equipado con eCall cuenta con una terminal capaz de obtener
el posicionamiento mediante satélites, comunicaciones inalámbricas y sensores para la
detección de colisiones, vuelco e incendio.
Cuando ha ocurrido un accidente, el dispositivo móvil marcará el número de un Public Safety
Answering Point (PSAP), ("El 112" centro de respuesta de emergencia en Finlandia). El
dispositivo móvil envía la información de la posición del vehículo y el tipo de accidente y abre
una conexión de voz entre los ocupantes del vehículo y el operador del PSAP.
Una llamada entrante del servicio de eCall se reconoce automáticamente en un PSAP, y el
conjunto de datos incluidos se decodifica. El operador del PSAP recibe la ubicación de
vehículos y detalles de los accidentes visualizados en la pantalla, cuando es recibida una
llamada telefónica.
Inclusive, si los ocupantes del vehículo no pueden hablar, se recibe la información sobre el
accidente. La respuesta emergentológica se inicia y las unidades necesarias de respuesta son
inmediatamente enviadas a la escena del accidente. Cuando el sistema eCall se haya
implementado en toda la Unión Europea, el ahorro anual se estima en al menos 2000 muertes
menos en carretera, y unos 20 mil millones de euros menos sobre los costos sanitarios y
sociales de cada año.
El mensaje enviado dentro de la llamada de emergencia contiene un conjunto mínimo de
datos (MDS): ubicación, velocidad, dirección de conducción, tipo de vehículo, tipo de carga y
un identificador del terminal del vehículo. El terminal puede enviar un conjunto mayor
de datos a través de conexión de datos móviles (GPRS, por ejemplo) a un proveedor
del servicio, que es capaz de desviar el conjunto completo de datos (FDS) para el PSAP
contactado inicialmente.
Las comunicaciones de los vehículos a los PSAPs se implementan utilizando las tecnologías
de comunicaciones, redes y normas existentes.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 17
Figura 3. Arquitectura del sistema eCall [4]
En la Unión Europea ya existe una red GSM que ofrece una forma de mensajería de emergencia.
Finlandia propone codificación DTMF para el envío de MDS. DTMF es soportado por las redes de
telefonía existentes y terminales GSM. La Unión Europea recomienda el uso de UUS-service.
También, se propuso USSD-service.
La mensajería entre el proveedor de servicios y el PSAP es segura y, a la misma vez, permite
una competencia libre en Europa.
Figura 4. Funcionamiento del sistema eCall [4]
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 18
La arquitectura de eCall se basa en un enlace cuasi simultáneo de voz y datos desde un
generador de eCall a un PSAP de primer nivel usando el número de emergencia 112 (Un PSAP
puede ser una autoridad pública o un proveedor de servicios privado, bajo el control de una
autoridad pública)
Figura 5. Funcionamiento de eCall [8]
Funcionamiento de eCall
1. El generador inicia la eCall mediante los sensores y/o manualmente, y se comunica
con el PSAP enviando la información de eCall. El eCall está compuesto por dos
elementos: una llamada de voz pura (audio) basada en el 112 y el Minimum Set of
Data (MSD).
2. El eCall (voz + datos) enviado a través de la red celular, es reconocido por el operador
de la misma como una llamada de emergencia 112, y es atendida en primera instancia
por el operador de la red. Basándose en el manejo de una llamada 112, el operador
“enriquece” la llamada agregando el CLI (Caller Line Identification), y al mismo
tiempo, acorde a las recomendaciones de USD y el E112, agrega la mejor ubicación
disponible (basados en el principio de mejor esfuerzo (best effort principle). Luego de
la manipulación del 112, el operador de telecomunicaciones despacha la llamada del
112 junto al CLI, ubicación y el eCall MSD al PSAP apropiado.
3. El PSAP transmite un ACK al generador del eCall especificando que el MSD se recibió
correctamente.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 19
Protocolo de transporte
Para poder facilitar y garantizar el roaming3, se necesitan interfaces comunes y protocolos
para la transferencia de datos.
Minimum Set of Data (MSD)
El mensaje MSD sólo debe contener los datos esenciales requeridos por el PSAP para ubicar el
vehículo y manipular de forma eficiente, la respuesta a la emergencia.
Hubo una propuesta de Finlandia para la transmisión del mismo. En dicha propuesta, el
mensaje está codificado como 19 bytes para ser enviados en formato DTMF4 mediante una
llamada de teléfono.
Finlandia propuso el uso del siguiente conjunto mínimo de datos de 19 bytes:
Figura 6. El contenido de los datos y el formato final del mensaje MSD está definido en el documento CEN/TS 15722:2009 “Road
transport and traffic telematics – eSafety – ECall minimum set of data (MSD)” [8]
3 En redes inalámbricas, roaming se refiere a la capacidad de cambiar de un área de cobertura a otra sin interrupción en el
servicio o pérdida en conectividad a pesar de que se esté fuera del área en el cual fue contratado el servicio.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 20
Se recomendó que se deje un byte 20 de reserve para uso futuro u opcional.
Los bytes individuales en cada elemento de datos del MDS se convierten en dos señales
DTMF4 usando la siguiente tabla.
Figura 7. Tabla de conversión a DTMF [4]
Mediante el uso de códigos DTMF solo es posible enviar números 0-9, letras A-D, y signos
cómo # y *. La conversión de datos binarios a DTMF se realiza traduciendo 19 bytes a
números hexadecimales y remplazando la E y F con # y * respectivamente.
Full Data Set (FDS)
El sistema eCall está diseñado para que se envíe información adicional a través del proveedor
de servicios en el mensaje FDS.
La terminal del vehículo envía el mensaje Full Data Set (FDS) al proveedor de servicios. El
mensaje está en formato XML y es transmitido por la red IP (GPRS) usando el método HTTP
POST. El proveedor de servicio verifica la validez de la estructura y el contenido del mensaje
usando el XML schema [http://www.w3.org/XML/Schema].
El proveedor de servicio reenvía los mensajes FDS válidos recibidos al PSAP. Luego, el
proveedor de servicio puede proveer información adicional o llenar información que falta.
(Por ejemplo, el proveedor puede incluir una base de datos conteniendo información acerca
4 Dual-Tone Multi-Frequency (DTMF) o Marcación por Tonos. Permitió sustituir el disco de marcar.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 21
del vehículo. La información adicional puede ser enviada como mensajes separados (FDS+)
siguiendo el mensaje original FDS. Todos los mensajes son enviados usando HTTP POST.
Full Data Set (FDS) - Usado por eCall
Los mensajes FDS incluyen la siguiente información:
Contenido
Status
Tipo de Mensaje
Version
Control de Mensaje
Nivel de privilegio
Tipo de vehículo
Cargo
Fabricante del vehículo
Año de fabricación del vehículo
Número de identificación del vehículo
Número de licencia del vehículo
Color del vehículo
Modelo del vehículo
Código MSID del terminal
Fabricante del terminal
Versión de hardware del terminal
Versión de software del terminal
Número de serie del terminal
IP del proveedor de servicio
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 22
Dirección
Número de teléfono del proveedor de servicio
País del proveedor de servicio
Timestamp
Ubicación actual
Dirección de manejo
Velocidad
Ubicación anterior
Cambio de posición
Origen del mensaje
Reconocimiento de accidente
Intensidad del accidente
Número de pasajeros
Más datos del accidente
Otra información
Tabla 2. El contenido del mensaje FDS.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 23
Figura 8. Funcionamiento del sistema eCall [6]
Los datos acerca de la ubicación del vehículo y la dirección en la que iba al momento del
accidente, se obtienen del GPS. La ubicación puede ser determinada dentro de un radio de 10
metros; en el futuro esto será más preciso. Cuando el sistema Galileo5 sea implementado, el
radio será de un metro solamente.
5 Galileo es un sistema global de navegación por satélite (GNSS) desarrollado por la Unión Europea (UE). De esta forma ya se
dependerá de los sistemas GPS y GLONASS (otro GNSS, de Federación Rusa en este caso). Será de uso civil. Se espera que esté en
uso en 2014, después de haber sufrido una serie de reveses técnicos y políticos para su puesta en marcha.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 24
Figura 9. Diagrama de secuencia sobre el funcionamiento de eCall [10]
Qué se espera del sistema
El sistema no disminuirá el número total de accidentes.
El sistema posibilitará la disminución del número de muertes de tránsito debido a que el arribo más rápido de la ayuda podrá prevenir algunas muertes. Por ejemplo, cuando se tardó mucho en encontrar el lugar del accidente o se tardó mucho en denunciar el mismo.
El sistema posibilita la disminución del nivel de severidad de las heridas, en algún grado: el arribo más rápido de la ayuda logra aliviar la gravedad de algunas heridas, entre las victimas.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 25
1.6 Sistemas relacionados en Estados Unidos
1.6.1 Enhanced 911 o 911 Mejorado (E911)
El Enhanced 911 o el servicio E9-1-1 es un sistema norteamericano de telecomunicaciones
basado en satélites que automáticamente asocia una dirección física con el número de
teléfono desde el cual se está llamando, y rutea la llamada al más apropiado Public Safety
Answering Point (PSAP), para esa dirección. La dirección e información de la persona que
llama es provista a quien toma la llamada, inmediatamente con el arribo de la misma. Esto
provee a quienes atienden la emergencia, la dirección de la misma sin la necesidad de que la
persona que llama necesite proveerla. Esto es muy útil en casos de incendios, robos,
secuestros y otros eventos donde comunicar la ubicación de alguien es dificultosa o imposible.
El E911 provee la dirección y la identificación de la persona.
Este sistema funciona sólo en América del Norte, llamando al 911. Las llamadas hechas a otros
números telefónicos, incluso si están listados como de emergencia, podrían no permitir el uso
de esa funcionalidad correctamente.
Fuera de Los Estados Unidos esta funcionalidad se llama Caller’s Location.
1.6.2 Próxima Generación de 9-1-1 (NG911)
La Próxima Generación de 911 (Next Generation 9-1-1 en inglés) (NG9-1-1) se refiere a una
iniciativa destinada a actualizar la infraestructura de servicio 9-1-1 en los Estados Unidos y
Canadá para mejorar los servicios públicos de comunicaciones de emergencia en una sociedad
móvil inalámbrica. Además de llamar al 9-1-1 desde un teléfono, el público podrá transmitir
textos, imágenes, video y datos al centro de 9-1-1 (llamado Public Safety Answering Point, o
PSAP). La iniciativa también contempla otros tipos de comunicaciones de emergencia y
transferencia de datos. Esta infraestructura del NG9-1-1 sustituirá a la de los servicios
actuales en el tiempo. La Natioanl Emergency Number Association (COAN) identificó por
primera vez la necesidad de NG9-1-1 en 2000, y comenzó el desarrollo en 2003, estando cerca
de completar la definición y las normas para NG9-1-1. Desde 2006, el US Department of
Transportation (DOT) ha sido líder en su iniciativa NG9-1-1, un proyecto de investigación y
desarrollo destinado a avanzar con el NG9-1-1.
Propósito e historia
La planificación de NG9-1-1 comenzó en el 2000 y se publicó en el NENA's Future Path Plan
en el 2001. El proyecto NG9-1-1 de NENA se inició en el 2003 y sigue hacia un objetivo final
de establecer planes de estándares e implementaciones nacionales para llevar a cabo sistemas
y servicios avanzados de 9-1-1. Los expertos en seguridad pública de comunicaciones
reconocieron que el actual sistema 9-1-1 de la nación no era capaz de manejar el texto, datos,
imágenes y video que son cada vez más comunes en las comunicaciones personales. El
objetivo declarado del proyecto USDOT es: "Para que el público en general pueda hacer un
llamado 9-1-1" (cualquier comunicación en tiempo real - voz, texto o video) de cualquier
comunicación cableada, inalámbrica, o dispositivo IP, y permitir a la comunidad de los
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 26
servicios de emergencia tomar ventaja de la entrega avanzada de llamadas y otras funciones, a
través de las tecnologías de interconexión basadas en estándares abiertos (open standards).
El proyecto tiene como objetivo en última instancia, el establecimiento de una arquitectura
nacional para un sistema de NG9-1-1 que responda a estos objetivos, y crear un plan de
transición para NG9-1-1.
La fase de la "prueba de concepto" del proyecto del DOT se completó en 2008 y se publicó un
informe sobre los resultados de una demostración de una prueba de concepto realizada en el
transcurso de ese año. Este informe ha servido como el proyecto original para la planificación
y ejecución de estas capacidades. Se espera que la aplicación real de estas capacidades tome
varios años, requiriendo cambios en la infraestructura de comunicaciones existente, así como
cambios en la manera en la que operan los PSAP.
Tecnología
La visión del NG9-1-1 se basa en la Emergency Services IP Network (ESInet) para ofrecer
servicios y “llamadas” de voz, video, texto y datos al PSAP. El protocolo utilizado para la
realización de estas "llamadas" será el Session Initiation Protocol (SIP), o Subsistema
Multimedia IP (IP Multimedia Subsystem, IMS, que incorpora SIP). Los estándares funcionales
y de interfases desarrollados por NENA describen arquitecturas generales de SIP y basadas
en IMS que otorgan flexibilidad a los organismos responsables en el desarrollo de una
infraestructura para soportar las funciones previstas para el NG9-1-1.
El actual 9-1-1 vs Next Generation 9-1-1
En el ambiente actual del 9-1-1, el público puede principalmente hacer solamente llamadas de
emergencia de voz y Teletipo (Teletype) (para sordos o personas con impedimentos de
audición). Sólo un mínimo de datos se entrega con estas llamadas, tales como Número de
Identificación Automático (Automatic Number Identification (ANI), el nombre del abonado y
cuando está disponibles, la Identificación automática de ubicación (Automatic Location
Identification).
En el ambiente de la próxima generación 9-1-1, el público podrá realizar llamadas de
emergencia de voz, texto, video desde cualquier dispositivo de comunicaciones a través de las
redes basadas en el Protocolo de Internet (IP). El PSAP del futuro también será capaz de
recibir los datos de los dispositivos de seguridad personal como los sistemas de Advanced
Automatic Collision Notification, los sistemas médicos de alerta, y sensores de diversos tipos.
La nueva infraestructura prevista por el proyecto NG9-1-1 dará apoyo a los servicios de "larga
distancia" de 9-1-1, así como la transferencia de llamadas de emergencia a otros PSAP -
incluyendo todos los datos de acompañamiento. Además, el PSAP podrá emitir alertas a
dispositivos móviles en un área a través de voz o mensaje de texto, y a los sistemas de alerta
de las carreteras.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 27
Escenarios de ejemplo
Actualmente, las personas sordas o con impedimentos de audición en los EE.UU, a veces usan dispositivos o servicios de interpretación TTY o TDD (Dispositivo de Telecomunicaciones para Sordos o Telecommunications Device for the Deaf) para contactarse con el 9-1-1. Muchas personas sordas utilizan la mensajería de texto y mensajes instantáneos (SMS) para comunicarse con los demás, pero por desgracia, hoy el 9-1-1 no está preparado para aceptar este medio. En ambiente del NG9-1-1, podrán hacer dicha llamada enviando un mensaje de texto desde su teléfono celular. Podrán serán capaces de mantener una conversación de texto con un operador de 9-1-1, e incluso enviar fotos o vídeo cuando resulte necesario.
En el caso de un accidente grande en la carretera, con la participación de varios vehículos,
incluido un vehículo de materiales peligrosos, el centro local de 9-1-1 puede recibir muchas
llamadas de conductores diferentes. Esto puede provocar que el centro esté sobrecargado con
llamadas, lo que lleva a la confusión inicial de los lugares de los múltiples accidentes. La
confusión puede retrasar los tiempos de respuesta de los equipos y servicios necesarios, lo
cual, a su vez, podría costar vidas y volver a retrasar el flujo de tráfico normal. En ambiente
del NG9-1-1, todo el mundo en las proximidades con un dispositivo conectado a Internet
puede ser notificado automáticamente para evitar la zona. Los mensajes de señales en la
autopista, y el sistema 9-1-1 también pueden mostrar las advertencias. Cualquier vehículo
implicado con un sistema de Advanced Automatic Collision Notification enviaría
automáticamente los datos de un choque importante al centro 9-1-1, que puede enviar
helicópteros Medivac incluso, si los pasajeros son incapaces de responder.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 28
C A P Í T U L O 2
2.1 Navegación Satelital
La navegación satelital se compone de constelaciones de satélites. Dichas constelaciones están
compuestas por distinta cantidad de satélites y pertenecen a diferentes países, comunidades,
entes, etc. entre los cuales se encuentran los sistemas GPS (EEUU), GALILEO (Europa),
GLONASS (Rusia), COMPASS (China), etc.
Galileo es el sistema de navegación de Europa, el cual proporciona gran precisión, estando
bajo control civil. Es interoperable con GPS y Glonass, otros dos sistemas de posicionamiento
global.
Glonass es un sistema global de navegación por satélite (GNSS) perteneciente a Rusia y
Compass es el desarrollado por la Republica Popular China.
Existe también una tecnología nueva la cual no se abarcará dentro de la presente tesis pero
que es importante nombrar y esta es la llamada Satellite Based Augmentation System (SBAS)
o Sistema de Aumentación Basado en Satélites. Esta tecnología permite corregir las lecturas
de GPS (o el sistema que sea) recibiendo un “mapa de errores” y calculando la posición
correcta mediante su uso. Esta tecnología requiere de instalaciones en la tierra y un receptor
con la capacidad de leer dichos mapas.
Algunas de los países que las desarrollan son:
WAAS (Wide Area Augmentation System), Departamento de Defensa de los Estados Unidos.
EGNOS (European Geostationary Navigation Overlay Service), Agencia Espacial Europea.
MSAS (Multi-Functional Satellite Augmentation System), Japón. GAGAN (GPS and GEO Augmented Navigation), India.
Figura 10. Distribución mundial de los GNSS - [67]
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 29
2.2 GPS
El sistema de GPS, creado por el Departamento de Defensa de los Estados Unidos a través de
una división de la Fuerza Aérea, usa una constelación de satélites donde cada uno da una
vuelta a la tierra 2 veces al día. Un receptor GPS debe ser capaz de recibir señales de
aproximadamente 10 satélites a la vez, en condiciones ideales, pero pocos pueden ser
tomados con confiabilidad en condiciones del mundo real.
Todos los satélites transmiten constantemente mensajes de navegación sobre el mismo
conjunto de frecuencias.
2.2.1 Datos del mensaje GPS
[11] Cada mensaje de navegación completo transmitido consta de 25 frames de datos, cada
frame de datos consta de 1500 bits. Cada frame se divide en 5 sub-frames. A una velocidad de
transmisión de 50Hz (50 bit/s), o sea, un intervalo de 1500(bits)/50(bits/seg) = 30 segundos
para la transmisión. Recibir un sub-frame (300 bits) toma 6 segundos, o 12.5 minutos recibir
el total de los 25 frames de datos. No siempre se envía el mensaje de navegación completo.
Figura 11. Estructura de los datos de un frame de GPS [12]
[13] Cada Satélite GPS transmite dos señales en el rango de la microondas, designadas como
L1 y L2 (frecuencias ubicadas entre 1000 y 2000 MHz).
Los receptores GPS de uso civil utilizan la frecuencia L1 con 1575.42 MHz. Las frecuencias L1
llevan los datos de navegación así también como el código SPS (Standard Positioning Service).
La frecuencia L2 (1227.60 MHz) sólo lleva el código P y solamente es usada por los receptores
que están diseñados para PPS (Precision Positioning Service), la mayoría de los que pueden
encontrarse en receptores militares.
Los satélites transmiten dos tipos de datos. El Almanac y el Ephemeris. Los datos del Almanac
son parámetros de órbita para todos los satélites. El almanac incluye información acerca de
los parámetros de órbita de todos los satélites, su estado técnico y configuración actual,
número de identificación y otros valores. Estos datos de Almanac no son muy precisos y son
válidos por un lapso de entre 4 y 6 meses. Cada almanac tiene un timestamp, el cual se puede
validar al recibir la hora actual.
Los datos de Ephemeris, en comparación, son correcciones de órbita y tiempo muy precisos
para cada satélite y si es necesario de posicionamiento preciso también. Cada satélite
transmite sólo sus datos de Ephemeris. Estos datos son considerados válidos por alrededor de
30 minutos. Los datos de Ephemeris son trasmitidos por cada satélite cada 30 segundos.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 30
El receptor GPS mide distancias a cuatro o más satélites simultáneamente. Usando
triangulación, el receptor puede determinar su latitud, longitud y altitud, entre otras cosas.
Con la información de cuatro satélites, un receptor GPS puede realizar una triangulación, que
permite que un punto se trace con exactitud con una precisión de 5 a 15 metros (15 a 45 pies).
Aunque geométricamente sólo tres satélites son necesarios, los efectos atmosféricos y otros
problemas introducen pequeños errores de tiempo. Un cuarto satélite permite corregir esos
errores y además provee una hora exacta y corregida así como también provee la elevación.
(Algunas técnicas para ayudar o completar al GPS pueden evitar la necesidad de un cuarto
satélite, o incluso utilizar los datos fragmentados de dos satélites.)
Cada satélite lleva varios relojes atómicos y tiene una hora muy exacta. Sin embargo, los
relojes atómicos de los satélites individuales no están sincronizados con la hora de referencia
GPS, sino que tienen la suya, por lo cual, se necesitan datos de corrección para los relojes de
cada satélite. Más aún, la hora de referencia GPS es diferente de la hora UTC, la cual está
sincronizada con la rotación de la tierra.
Si un satélite no transmite sus datos correctamente o su órbita es inestable, puede ser
marcado como que no está sano por la estación de control. La información es transmitida por
el satélite en su señal. De esta forma, los receptores no toman en cuenta los datos del satélite
afectado para la determinación de la posición.
Una razón típica de por qué los satélites se marcan como defectuosos es la necesidad de una
corrección en su órbita. En este caso se corrige la posición del satélite con sus propulsores y
se quita la marca de defectuoso cuando el satélite se estabiliza en su nueva órbita.
[12] Cuando los datos de ephemeris y almanac son guardados en el receptor GPS, depende del
mismo cuánto se tardará en obtener la primera posición. Si el receptor no tuvo contacto con
ningún satélite por un periodo largo de tiempo, la determinación de la primera posición
tardará más tiempo. Si el contacto sólo se interrumpió por un breve lapso de tiempo (por
ejemplo, al pasar por un túnel), la determinación de la posición se obtiene nuevamente
instantáneamente y se habla de readquisición.
Si la posición y la hora son conocidas y el almanac y ephemeris están actualizados, se habla de
un hot start. Este es el caso cuando el receptor se prende aproximadamente en la misma
posición entre 2 a 6 horas, luego de la última determinación de la posición. En este caso, un
position fix se puede obtener en aproximadamente 15 segundos.
Si los datos del almanac están disponibles y la hora en el receptor es la correcta pero los datos
de ephemeris están desactualizados, se habla de un warm start. En este caso, toma alrededor
de 45 segundos actualizar los datos de ephemeris y obtener una position fix.
Los datos de Ephemeris están desactualizados cuando pasan más de 2 a 6 horas desde que se
obtuvo la última recepción de datos de los satélites que estaban en vista. Cuantos más nuevos,
más se tardará en el warm start.
Si tanto los datos de ephemeris como los datos de almanac como la última ubicación son
desconocidos, se habla de un “cold start”. Luego, en un primer paso todos los datos del
almanac se recolectan de los satélites, Este procedimiento tarda hasta 12,5 minutos. Esto
ocurre cuando el receptor fue apagado por varias semanas, fue guardado sin baterías o se
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 31
viajó aproximadamente 300 km o más desde el último position fix.
2.3 Sistema de Posicionamiento Global Diferencial (DGPS)
[14] Con el DGPS (por sus siglas en inglés de Differential Global Positioning System) existen
estaciones de referencia. Cada una de las estaciones de referencia compara su propia posición
conocida de forma precisa, con la posición calculada de las señales del GPS. La estación
transmite luego esta información en una banda de onda larga (de 150 kHz a 529 kHz LW por
sus siglas en inglés de LongWave) determinada como datos de corrección. Luego, un receptor
DGPS recibe la información de corrección y aplica la corrección a las señales recibidas de los
satélites GPS. Con el incremento de la distancia entre los receptores y las estaciones de
referencia DGPS, la influencia atmosférica en las señales se hace más profunda ya que las
señales de los satélites deben atravesar diferentes partes de la atmósfera, siendo influidas de
distintas formas, lo cual hace que la corrección menos precisa. Si la distancia entre las
estaciones de referencia es grande, las señales de los satélites viajan a través de diferentes
partes de la atmósfera, siendo influidas de distintas formas. Incluso peor, debido a la gran
distancia, el receptor podría recibir información de satélites completamente diferentes donde
no hay información de corrección provista en los datos de corrección. Este efecto, en el que la
estación de referencia no provee datos adecuados para la corrección debido a la gran
distancia al receptor, se llama “spatial decorrelation”. Debido a este fenómeno, el rango típico
para estaciones DGPS es entre 70 – 200 km con buena exactitud.
Figura 12. GPS Diferencial
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 32
2.4 Fuentes de error en GPS
2.4.1 [15] Disponibilidad selectiva o Selective Availability
El factor más relevante para la inexactitud del sistema GPS ya no es un problema. El 2 de mayo
del 2000 a las 5:05 am (MEZ) el llamado Selective Availability (SA) fue puesto fuera de
servicio. La disponibilidad selectiva era una falsificación artificial del tiempo en la frecuencia
L1 de la señal transmitida por el satélite. Para los receptores civiles de GPS que conducen a
una determinación de la posición menos precisa (una fluctuación de aproximadamente 50
metros, durante unos minutos). Además, los datos de ephemerides se transmiten con menor
precisión, lo que significa que la posición de los satélites de transmisión no se ajusta a las
posiciones reales. De esta manera, se puede lograr una imprecisión de la posición de 50 a 150
mts por varias horas. Mientras que en tiempos de la disponibilidad selectiva la determinación
de la posición con los receptores civiles tenía una exactitud de aproximadamente 100 metros,
en la actualidad 20 metros o incluso menos, es lo habitual. Especialmente, la determinación de
las alturas ha mejorado considerablemente desde la desactivación de la SA (habiendo sido
más o menos inútil anteriormente).
Las razones de la existencia de la SA fueron de seguridad. Por ejemplo, los terroristas no
debían contar con la posibilidad de localizar los edificios importantes con armas de
fabricación casera. Paradójicamente, durante la primera guerra del Golfo en 1990, la SA tuvo
que ser desactivada en parte, ya que no había suficientes receptores militares para las tropas
estadounidenses, haciendo posible una orientación muy precisa en el desierto, sin puntos de
referencia. Mientras tanto, la SA se desactivó de forma permanente debido a la amplia
distribución mundial y la amplia utilización del sistema GPS.
Los siguientes dos gráficos muestran la mejora de la determinación de la posición después de
la desactivación de la SA. La longitud de la arista de los diagramas es de 200 mts, los datos
fueron obtenidos entre el 1 de mayo del 2000 y 3 de mayo del 2000 durante un período de 24
horas cada uno. Mientras que con la SA el 95% de todos los puntos están situados en un radio
de 45 m, sin la SA el 95% de todos los puntos están dentro de un radio de 6,3 m.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 33
Figura 13. Gráfica de la determinación de la posición con y sin SA [15]
2.4.2 Geometría de los satélites
Otro factor que influye en la exactitud de la determinación de la posición es la "geometría de
los satélites". Simplificado, la geometría de los satélites describe la posición de los satélites
entre sí desde el punto de vista del receptor.
Si un receptor ve 4 satélites y todos están dispuestos, por ejemplo, en el noroeste, esto
conduce una geometría "mala". En el peor de los casos, la determinación de la posición no es
posible en lo absoluto, cuando todas las determinaciones de distancia apuntan a la misma
dirección. Incluso si se determina una posición, el error de las posiciones pueden ser de hasta
(100 – 150) mts. Si, por otra parte, los 4 satélites están bien distribuidos por todo el cielo la
posición determinada será mucho más precisa. Si se supone que los satélites están
posicionados en el norte, este, sur y oeste a 90°, las distancias se pueden medir en cuatro
direcciones diferentes, que reflejan una "buena" geometría de los satélites. El gráfico siguiente
muestra esto para el caso de dos dimensiones.
Figura 14. Buena alineación geométrica para dos satélites [15]
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 34
Si los dos satélites están en una posición ventajosa, desde el punto de vista del receptor se
pueden ver en un ángulo de 90° entre sí. El tiempo de la señal no se puede determinar de
forma absolutamente precisa como se explicó anteriormente. Las posiciones posibles son, por
lo tanto, marcadas por los círculos grises. El punto de intersección A de los dos círculos es
pequeño, más o menos un campo cuadrado (azul), la posición determinada será bastante
precisa.
Figura 15. Mala alineación geométrica de dos satélites [15]
Si los satélites están posicionados más o menos en una línea desde el punto de vista del
receptor, el plano de intersección de las posibles posiciones es considerablemente más grande
y alargado – La determinación de la posición es menos precisa.
La geometría satelital también es relevante cuando el receptor es usado en vehículos o cerca
de edificios altos. Si algunas de las señales están bloqueadas, el resto de los satélites
determinan la calidad de la determinación de la posición e incluso siquiera si es posible la
obtención de un position fix en lo absoluto.
[16] Cuando un receptor GPS se enciende luego de haber cambiado de posición por cientos de
kilómetros (habiendo estado apagados durante ese trayecto) el almanac queda invalidado,
haciéndolos incapaces de funcionar, triangular o posicionarse hasta que se reciba una señal
clara durante al menos un minuto. Este proceso inicial, denominado primer posicionamiento o
posicionamiento inicial (del inglés TTFF (Time To First Fix) o tiempo para el primer
posicionamiento), suele ser muy largo en general, incluso según las condiciones, de minutos.
Esto se puede observar en los edificios cerca de las ventanas. Si la determinación de una
posición es posible, mayormente no será muy precisa. Cuanto mayor es la parte oculta del
cielo, más difícil se vuelve la determinación de la posición.
La mayoría de los receptores GPS no sólo indican el número de satélites recibidos, sino
también su posición en el cielo. Esto le permite al usuario juzgar si un satélite de referencia
está oculto por un obstáculo, y si el cambio de posición en un par de metros puede mejorar la
precisión. Muchos instrumentos proporcionan la exactitud de los valores medidos, en su
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 35
mayoría basadas en una combinación de diferentes factores (que los fabricantes no revelan en
buena medida).
Para indicar la calidad de la geometría satelital se usan comúnmente los valores DOP (dilution
of precision). (Más adelante se explicará con mayor detalle).
El error en la determinación de la posición causado por la geometría de los satélites también
depende de la latitud del receptor. Esto se muestra a continuación en los dos diagramas. El
diagrama de la izquierda muestra la inexactitud de la altura (en el comienzo de la curva con la
SA), grabado en Wuhan (China). Wuhan se encuentra en 30.5 ° de latitud norte donde se
puede encontrar una constelación satelital ideal todo el tiempo. El gráfico de la derecha
muestra el mismo intervalo registrado por la Estación Casey en la Antártida (66.3 ° de latitud
sur). Debido a la constelación de satélites de vez en cuando el error es mucho mayor. Además,
la falsificación por el efecto de la atmósfera se vuelve más importante cuanto más cerca se
está de la posición de los polos.
Figura 16. Error en la determinación de la altura a diferentes latitudes [15]
2.4.3 Dilución de la precisión (GPS) (más sobre la geometría de los satélites)
La señal de cada satélite GPS tiene un nivel de precisión, dependiendo de la geometría relativa
de los satélites. Estas precisiones se pueden combinar para dar una precisión más
comprimida o amplificada. Cuando los satélites GPS visibles están muy juntos en el cielo, la
geometría se dice que es débil y el valor DOP (siglas en inglés de Dilution of Precision)es alto,
cuando están lejos, la geometría es fuerte y el valor DOP es bajo. Si se consideran dos anillos
superpuestos, de centros diferentes, y se superponen en ángulo recto, la mayor parte de la
superposición es mucho menor que si se superponen en casi paralelo. Así, un valor bajo DOP
representa una mejor precisión de la posición de GPS debido a la separación angular más
amplia entre los satélites utilizados para calcular la posición de una unidad de GPS. Otros
factores que pueden aumentar la Dilution of Precision son obstrucciones, tales como montañas
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 36
o edificios cercanos.
La dilution of precision es más o menos interpretado como la proporción de error de posición
para el rango de error.
Entre los factores que se utilizan para el cálculo de los valores de DOP, se distinguen
diferentes variantes:
GDOP (Geometric Dilution Of Precision); Precisión general; Coordenadas 3D y tiempo PDOP (Positional Dilution Of Precision) ; Precisión de posición; Coordenadas 3D HDOP (Horizontal Dilution Of Precision); Precisión horizontal; Coordenadas 2D VDOP (Vertical Dilution Of Precision); Precisión vertical; altura TDOP (Time Dilution Of Precision); Precisión temporal; tiempo
Los receptores GPS permiten la visualización de estas posiciones, así como los valores de DOP.
Los valores HDOP inferiores a 4 son buenos, por encima de 8 malos. Los valores HDOP
empeoran si los satélites recibidos están altos en el cielo. Los Valores VDOP por el contrario
empeoran cuanto más cerca están los satélites al horizonte y los valores PDOP son los mejores
si un satélite está posicionado verticalmente encima y tres están distribuidos uniformemente
cerca del horizonte. Para una determinación de la posición exacta, el valor GDOP no debe ser
menor que 5. Los valores de PDOP, HDOP y VDOP son parte de los datos NMEA $ GPGSA.
Valor DOP Rating Descripción
1 Ideal El valor de confianza más alto posible para ser usado en aplicaciones que demanden la mayor precisión posible todo el tiempo.
1-2 Excelente En este valor de confianza, las mediciones de posición son consideradas suficientemente exactas para cubrir todas las aplicaciones excepto las más sensibles.
2-5 Bueno Representa un nivel que marca el mínimo apropiado para realizar decisiones de negocio. Las mediciones de posición pueden ser usadas para realizar sugerencias confiables de navegación in-route al usuario
5-10 Moderado Las medidas de posición pueden ser usadas para cálculos, pero la calidad del fix puede ser mejorada. Se recomienda estar en un lugar más abierto.
10-20 Razonable Representa un nivel de confianza bajo. Las medidas de posición deben descartarse o ser usadas sólo para indicar un ubicación estimada muy “por arriba”.
>20 Pobre En este nivel, las mediciones son imprecisas tanto como 300 metros con un aparato de 6 metros de exactitud (50 DOP × 6 metros) y debe descartarse.
Tabla 1. Significado de los valores de DOP
2.4.4 Órbitas de los satélites
Aunque los satélites se colocan en órbitas muy precisas, ligeros cambios de las órbitas son
posibles debido a las fuerzas de gravitación. El Sol y la luna tienen una débil influencia en las
órbitas. Los datos de la órbita son controlados y corregidos periódicamente y se envían a los
receptores en el paquete de datos de ephmerides. Por lo tanto, la influencia en la exactitud de
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 37
la determinación de la posición es más bien baja, siendo el error resultante de no más de 2
mts.
2.4.5 Efecto Multipath o Multicamino
Figura 17. Interferencia causada por la reflexión de las señales [15]
El efecto Multicamino o Multipath, es causado por la reflexión de las señales de satélite (ondas
de radio) en los objetos. Fue el mismo efecto que las imágenes fantasma causadas en la
televisión cuando las antenas en el techo eran todavía más comunes que las antenas actuales,
en muchas casas (satelitales, antenas parabólicas).
Para las señales de GPS, este efecto aparece principalmente en las proximidades de grandes
edificios u otras elevaciones. La señal reflejada tarda más tiempo en alcanzar el receptor que
la señal directa. El error resultante normalmente se encuentra en el rango de unos pocos
metros.
2.4.6 Efectos Atmosféricos
Figura 18. Propagación influida por ondas de radio a través de la atmosfera de la Tierra [15]
Otra fuente de imprecisión es la reducción de la velocidad de propagación en la tropósfera y la
ionósfera. Mientras que las señales de radio viajan a la velocidad de la luz en el espacio
exterior, su propagación en la ionósfera y la tropósfera es más lento.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 38
En la ionósfera a una altura de entre 80 y 400 km un gran número de electrones e iones con
carga positiva se forman por la fuerza ionizante del sol. Los electrones y los iones se
concentran en cuatro capas conductoras en la ionósfera. Estas capas refractan las ondas
electromagnéticas de los satélites, resultando en un runtime más largo de las señales.
Estos errores son corregidos en su mayoría por el receptor mediante cálculos. Las variaciones
típicas de la velocidad al pasar por la ionósfera para frecuencias bajas y altas son bien
conocidas en condiciones normales. Estas variaciones se tienen en cuenta para todos los
cálculos de las posiciones. Sin embargo, los receptores civiles no son capaces de corregir los
cambios imprevistos de runtime, por ejemplo, por los de fuertes vientos solares.
Se sabe que las ondas electromagnéticas se retrasan de forma inversamente proporcional al
cuadrado de su frecuencia (1 / f 2) al pasar por la ionósfera. Esto significa que las ondas
electromagnéticas con frecuencias más bajas se desaceleran más que las ondas
electromagnéticas con frecuencias más altas. Si las señales de frecuencias más altas y bajas
que llegan a un receptor se analizan en relación con sus diferentes tiempos de llegada, el
alargamiento del runtime de la ionósfera se puede calcular. Los receptores militares de GPS
utilizan las señales de ambas frecuencias (L1 y L2), que se ven influidos de manera diferente
por la ionósfera y que son capaces de eliminar otras inexactitudes mediante cálculos.
El efecto de la tropósfera es un factor adicional en el aumento del runtime de las ondas
electromagnéticas por la refracción. Las razones de la refracción son diferentes
concentraciones de vapor de agua en la troposfera, causados por condiciones climáticas
diferentes. El error causado de esa manera es más pequeño que el error de la ionósfera, pero
no puede ser eliminado mediante cálculo. Sólo puede ser aproximado por un modelo de
cálculo general.
Los siguientes dos gráficos visualizan el error de la ionósfera. Los datos de la izquierda fueron
obtenidos con un receptor de frecuencia única sin corrección de la ionósfera, los datos de la
derecha fueron obtenidos con un receptor de dos frecuencias con corrección de la ionósfera.
Ambos diagramas tienen aproximadamente la misma escala (izquierda: latitud -15 m a +10 m,
longitud -10 a +20 m, m, derecha: latitud -12 m a +8 m, longitud -10 m a +20 m). El gráfico de
la derecha muestra claramente menos valores extremos, mientras que la exactitud media de la
posición para el 95% de los datos no es mejorada mucho por la corrección del error de la
ionósfera.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 39
Figura 19. Determinación de la posición con y sin correcciones atmosféricas usando una segunda
frecuencia en un receptor de frecuencia dual [15]
Con la implementación de WAAS y EGNOS es posible establecer “mapas” de las condiciones
atmosféricas de las diferentes regiones. Los datos de corrección son enviados a los receptores,
mejorando la exactitud considerablemente.
2.4.7 Inexactitudes y errores de redondeo de reloj
A pesar de la sincronización del reloj del receptor con la hora del satélite durante la
determinación de la posición, la inexactitud restante del tiempo sigue dando lugar a un error
de unos 2 metros en la determinación de la posición.
El redondeo y el cálculo de errores en el receptor terminan en aproximadamente 1 m.
2.4.8 Los efectos relativistas
La siguiente sección no constituye una explicación exhaustiva de la teoría de la relatividad. En
la vida normal, ignoramos la omnipresencia de la teoría de la relatividad. Sin embargo, tiene
una influencia en muchos procesos, entre ellos el correcto funcionamiento del sistema GPS.
Esta influencia se explica de forma breve en lo que sigue.
El tiempo es un factor relevante en la navegación GPS y debe ser exacto entre 20 a 30
nanosegundos para asegurar la precisión necesaria. Por lo tanto, el movimiento rápido de los
satélites (cerca de 12.000 kmh) debe ser considerado.
Quien ya conoce la teoría de la relatividad, sabe que el tiempo corre más lento en los
movimientos muy rápidos. Para los satélites moviéndose a una velocidad de 3874 m/s, los
relojes funcionan también más lentamente cuando se ven desde la Tierra. Esta dilatación
relativista del tiempo conduce a una inexactitud de tiempo de aproximadamente 7.2
microsegundos al día (1 microsegundo = 10 -6 segundos).
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 40
La teoría de la relatividad también dice que el tiempo se mueve más lento cuanto más fuerte
es el campo de gravedad. Para un observador en la superficie de la tierra el reloj a bordo de un
satélite corre más rápido (ya que el satélite a 20000 km de altura está expuesto a un campo
mucho más débil de gravitación que el observador). Y este efecto secundario es seis veces más
fuerte que la dilatación del tiempo que se ha explicado anteriormente.
En total, los relojes de los satélites parecen correr un poco más rápido. La diferencia de
tiempo para el observador en la Tierra sería de alrededor de 38 milisegundos por día y serían
un error total de aproximadamente 10 km por día. A fin de que los errores no tengan que ser
corregidos constantemente, los relojes de los satélites se fijaron a 10,229999995453 MHz en
lugar de 10,23 MHz, pero son operados como si estuvieran a 10,23 MHz. Mediante este truco,
los efectos relativistas son compensados de una vez y para siempre.
Hay otro efecto relativista, que no se considera para la determinación normal de la posición
por GPS. Se llama Sagnac-Effect y es causada por el movimiento del observador sobre la
superficie de la tierra, que también se mueve con una velocidad de hasta 500 m/s (en el
ecuador), debido a la rotación del planeta. La influencia de este efecto es muy pequeña y
complicada de calcular ya que depende de las direcciones del movimiento. Por lo tanto, se
considera sólo en casos especiales.
Los errores del sistema GPS se resumen en la tabla siguiente. Los valores individuales no son
valores constantes, pero están sujetos a variaciones. Todos los números son valores
aproximados.
Considerando todo lo dicho, la suma da un error de hasta ± 15 metros. Con la SA todavía
activa, el error estuvo en el rango de ± 100 metros. Las correcciones hechas por sistemas
como WAAS y EGNOS, que reducen sobre todo los efectos de la ionósfera, pero también
mejoran los errores de las órbitas y de reloj, el error total se reduce a aproximadamente ± 3 a
5 metros.
Efectos ionosféricos ± 5 metros ± 5 metros
Los cambios en las órbitas de los satélites ± 2.5 metros ± 2,5 metros
Los errores de reloj de los relojes de los satélites ± 2 metros ± 2 metros
Efecto Multipath ± 1 metros ± 1 metro
Efectos de la troposfera ± 0.5 metros ± 0,5 metros
Errores de cálculo y redondeo ± 1 metros ± 1 metro
Tabla 2. Errores en GPS [15]
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 41
2.5 GPS de Alta Sensibilidad
[17] Las señales GPS son ya muy débiles cuando llegan a la superficie de la Tierra. Los
satélites GPS tienen transmisores que sólo entregan 27 W desde una distancia de 20.200
kilómetros en órbita sobre la Tierra. En el momento en que las señales llegan al receptor del
usuario, por lo general son tan débiles como -160 dBW, lo que equivale a una décima parte de
un millonésimo milmillonésima parte de un watt. Esto es muy por debajo del nivel de ruido
térmico en su ancho de banda. Al aire libre, las señales de GPS son normalmente alrededor del
nivel de -155 dBW.
Los GPS de alta sensibilidad pueden proporcionar posicionamiento en muchos, pero no todos,
los interiores. Las señales son muy atenuadas por los materiales de construcción o reflejas
como pasa en Multipath explicado previamente. Dados estos receptores GPS de alta
sensibilidad, los receptores pueden ser hasta 30 dB más sensibles, siendo suficiente para
realizar un seguimiento a través de 3 capas de ladrillos secos, o hasta 20 cm de concreto
reforzado con acero, por ejemplo.
2.6 Localización mediante la red de datos
2.6.1 Cómo se obtiene y algunas técnicas existentes
El GSM Permite una conectividad perfecta y segura entre redes a escala mundial.
La codificación digital se utiliza para la comunicación de voz y los métodos de transmisión de
acceso múltiple por división de tiempo (TDMA) proporcionan un muy eficiente medio para la
transmisión de datos. Mientras que GSM es un estándar en algunos países para la
comunicación de persona a persona, la red de conmutación de circuitos limita la transmisión
de datos. General Packet Radio Service (GPRS) fue desarrollado para aliviar esta limitación.
El GPRS es una capa de comunicación de datos construida sobre el enlace de transmisión
GSM. GPRS utiliza la capacidad sobrante que queda de la comunicación de voz GSM y tiene una
velocidad máxima teórica de 171,2 Kbps por lo que es una opción viable para la transferencia
inalámbrica de datos. Usando un formato de paquete para la transmisión de datos, permite
una compatibilidad total con los servicios de Internet existentes, tales como HTTP, FTP,
correo electrónico, mensajería instantánea, y mucho más.
Luego se creó EDGE, UMTS y la última que se creó fue LTE que viene con las redes 4G o
algunos las llaman 4.5G.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 42
Cómo se ubica la posición de un celular
Figura 20. Seguimiento de un celular[7]
1) El celular envía una señal a las estaciones base cercanas
2) Software de posicionamiento hace los cálculos de triangulación con la información de las
estaciones base.
3) Los datos son convertidos a una ubicación geográfica
Debido a que la ubicación mediante redes celulares provee la ubicación mediante
triangulación y/o la ubicación de la antena mediante la cual el celular se comunica, si no se
activa el GPS en el celular. Se notifica un radio dentro del cual puede estar el celular, siendo
este radio mayor en zonas despobladas, donde la separación entre bases puede llegar a
kilómetros.
[18] Uno de los métodos más precisos para la determinación de la posición es el uso de las
torres de celular debido a que su ubicación es fija y conocida. Observando la fuerza de la señal
del dispositivo móvil, se puede calcular rápidamente cuán lejos se está de la torre celular en
particular. Se puede concluir que el dispositivo móvil está dentro de un radio de la torre.
Figura 21. Radio alrededor de una antena celular [18]
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 43
Si hubiese tres torres captando la señal, entonces se podría reducir a un solo punto en cada
caso; la intersección
de los tres radios.
Figura 22. Radio alrededor de tres antenas celulares [18]
Algunas opciones de los operadores para obtener la posición
Cell ID – Algunas veces llamada Cell Global Identity (CGI). El operador de la red usa cell id
para identificar sobre qué celda se está transmitiendo en un momento determinado. Es un
método muy aproximado. Suele ser complementado con información de timing advanced
(TA). TA es el tiempo medido entre el comienzo de un frame de radio y el data burst. Esta
información ya está embebida en la red y la precisión puede ser aceptable cuando las celdas
son pequeñas. La combinación de los métodos de cell-id y time arrival se suelen llamar CGI-
TA.
E-OTD - Enhanced Observed Time Difference – Es una tecnología hibrida que usa tanto el
dispositivo móvil como la red para determinar la ubicación del dispositivo. La tecnología
compara tiempos de arribo de las señales de celular inalámbricas para obtener su posición. E-
OTD requiere menos actualización del software de la red y se requieren chips E-OTD en los
dispositivos y componentes de hardware (LMU - location mobile unit) son agregados a las
estaciones base de la red.
TDOA - Time Difference on Arrival – una tecnología patentada por True Position, permite
otra forma de deducir la ubicación tomando los tiempos de las señales entre el usuario y las
estaciones base. Esto es preciso y no requiere que se modifique el dispositivo móvil. Sin
embargo, en una red tipo, se debe agregar hardware a decenas de miles de estaciones base.
Agilent's acceSS7 – Usa un conjunto de tecnologías para lograr su meta, y no necesita agregar
modificaciones a los dispositivos móviles, lo cual mantiene bajo el costo.
Cada método tiene sus ventajas y desventajas. Los operadores suelen elegir una variación de
uno o más sistemas, dependiendo qué aplicación encaja mejor en la tecnología con la que ya se
cuenta.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 44
2.6.2 Cómo funciona en Android
Existe algo llamado Network Location Provider o Proveedor de Ubicación por Red, que se
encarga de proveer una buena ubicación sin el uso del GPS.
El saber dónde está el usuario le permite a una aplicación ser más inteligente y entregar mejor
información al usuario. Cuando se crea una aplicación basada en la ubicación para Android, se
puede usar el GPS y el proveedor de Ubicación por Red para obtener la ubicación del usuario.
Aunque el GPS es más preciso, sólo funciona al aire libre, rápidamente se consume energía de
la batería, y no devuelve la posición tan pronto como los usuarios quieren. El proveedor de
Ubicación por Red de Android determina la ubicación del usuario utilizando torres de
telefonía celular y señales Wi-Fi, proporcionando información sobre la ubicación de una
manera que funciona en interiores y al aire libre, responde más rápido y consume menos
energía. Para obtener la ubicación del usuario en una aplicación, se pueden utilizar ambos
proveedores de ubicación, o sólo uno.
Desafíos en la obtención de la ubicación del usuario.
La obtención de la ubicación del usuario desde un dispositivo móvil puede ser
complicada. Hay varias razones por las que una lectura de ubicación (independientemente de
la fuente) puede contener errores y ser inexacta. Algunas fuentes de error en la ubicación del
usuario incluyen:
Multitud de fuentes de ubicación Tanto GPS como Cell-ID como Wi-Fi pueden cada uno proveer pistas sobre la ubicación del usuario. Determinar cuál usar y confiar es una ecuación de balance entre la precisión, velocidad y eficiencia de la batería.
Movimiento del usuario Debido a los cambios de ubicación de los usuarios, se debe tener en cuenta el movimiento, re-estimando, de vez en cuando, la misma.
Precisión variante Las estimaciones de la ubicación que se reciben de cada fuente no son consistentes en cuanto a sus precisiones. Una ubicación obtenida hace 10 segundos de una fuente puede ser más precisa que otra más nueva de otra fuente o la misma.
Estos problemas pueden hacer que sea difícil obtener una lectura fiable de la ubicación del
usuario.
2.7 GPS Asistido (A-GPS) - Uso del GPS en el celular
2.7.1 Descripción
[19] El GPS Asistido (Assisted GPS en inglés) describe un sistema donde fuentes externas,
como un servidor de asistencia y una red de referencia, ayudan al receptor GPS a hacer alguna
tareas requerida para poder tomar una serie de medidas y posicionamiento. El servidor de
asistencia tiene la habilidad de acceder a la información de la red de referencia y también
tiene mucho más poder de cómputo que el receptor de GPS. El servidor de asistencia se
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 45
comunica con el receptor de GPS a través de un enlace inalámbrico. Con la asistencia de la red,
el receptor puede operar de forma más rápida y eficaz que si no estuviese asistido (de ahí
Assisted GPS), esto es debido a que un conjunto de tareas que normalmente haría, las
comparte con el servidor de asistencia. El sistema resultante AGPS, consistente en un receptor
integrado GPS y componentes de red, que en su conjunto, aumentan la performance más allá
del mismo receptor en modo standalone o modo autónomo (cuando sólo se usa el GPS y no la
red para asistirse).
Figura 23. El Assisted-GPS requiere una red mundial que pueda proveer los mensajes de navegación de todos los satélites y hubs
que procesen los datos junto a un servidor que alimente con datos a un Serving Mobile Location Center (SMLC) o un Mobile
Position Center (MPC)6 operado por un proveedor de servicio de red. Los datos son enviados a los celulares usando Hypertext
Transfer Protocol (HTTP) y Short Messaging Service (SMS) [19]
2.7.2 ¿Por qué AGPS?
Las arquitecturas AGPS aumentan la capacidad de conservar batería, posibilita obtener y
seguir más satélites que un receptor standalone. Así, mejora la geometría que se observa y se
incrementa la sensibilidad por sobre la arquitectura GPS convencional. Estas capacidades
mejoradas vienen del conocimiento de la posición de los satélites y la velocidad, la posición
inicial del receptor y el tiempo provisto por el servidor de asistencia.
Las señales de GPS recibidas están desplazadas en frecuencia debido al movimiento relativo
receptor-satélite. Este es el llamado Desplazamiento de Frecuencia Doppler. El receptor debe
encontrar la frecuencia de la señal antes de poder usarla. El conocimiento de la posición del
satélite y los datos de la velocidad y la posición inicial del receptor reduce el número de
frecuencias posibles que deben ser buscadas porque el receptor directamente calcula el
desplazamiento de la frecuencia Doppler en lugar de buscar por todo el rango posible de
frecuencias. La posición del satélite y los datos de la velocidad son calculados de los datos de
6 Serving Mobile Location Center (SMLC) / Mobile Position Center (MPC), es un elemento separado de la red o una funcionalidad
integrada en la Base Station Controller (BSC), contiene la funcionalidad requerida para soportar Servicios de Localización. El
MPC es el equivalente functional a un Gateway Mobile Location Center (GMLC) que es usado en sistemas GSM.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 46
órbita y reloj provistos por el servidor de asistencia. La posición inicial del receptor puede
venir de técnicas de Cell ID o de alguna otra fuente de información. Reducir el número de
frecuencias posibles que deben ser buscadas para obtener la señal reduce el Time-To-First-Fix
(TTFF).
El TTFF es más reducido porque el receptor no tiene más la tarea de decodificar los bits de
datos de navegación, una tarea que toma decenas de segundos. En su lugar, el servidor de
asistencia facilita al receptor los valores de los parámetros de órbita y reloj del satélite. TTFF
más cortos significan menos consumo de energía porque el sistema no necesita esperar a que
el receptor GPS decodifique los datos de navegación para cada satélite visible. Si el satélite
tuviera que decodificar la ephemeris del mensaje transmitido, tomaría un mínimo de 18
segundos luego de obtener la señal (asumiendo que no se perdió ningún bit en el camino). En
la práctica, el rango de TTFF (cuando se decodifican los datos de ephemeris) es de 20-60
segundos para ambientes donde el receptor tiene una vista del cielo que no está obstruida. Si
es un ambiente distinto, como un cañón urbano7 o incluso en interiores, el receptor puede
tardar mucho más en obtener los bits de datos, si es que puede obtenerlos del todo.
Una mayor sensibilidad está directamente relacionada al TTFF y al número de frecuencias que
deben ser buscadas para encontrar una señal de satélite. Debido a que el receptor tiene menos
frecuencias para buscar en una arquitectura AGPS, puede fijarse en cada frecuencia por
periodos de tiempo más largos. Este tiempo adicional aumenta la sensibilidad del receptor, así
puede usar las intensidades de la señal que están debajo de los umbrales convencionales para
tomar medidas de la distribución. Además, cuando se requiere una sensibilidad mayor, sería
muy dificultoso sino imposible, decodificar los bits de datos de navegación. Por lo cual, esta
técnica permite el uso de datos de satélites que de otra forma podrían no estar disponibles.
2.7.3 Razones de creación del AGPS
Aunque las discusiones de TTFF y bits de datos de navegación son importantes para los
ingenieros, la real razón de implementar AGPS es la satisfacción del cliente al usar la ubicación
o los servicios de E-911 (luego se hablará más en detalle). Con AGPS, la posición se puede
obtener más rápido, en el orden de unos pocos segundos. Si la obtención de la posición tomase
minutos, como es común en warm starts de los receptores GPS convencionales, el consumidor
podría quedar frustrado mientras espera y se pregunta si hay algo malo con el dispositivo
móvil. El consumidor típico de celular creció acostumbrado a aplicaciones que trabajan en
unos pocos segundos.
7 Un cañón urbano es un artefacto de un ambiente urbano similar al de un cañon natural. Está formado por calles que atraviesan
una estructura densa de bloques, especialmente rascacielos, los cuales causan el efecto cañon [20].
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 47
2.7.4 Ventajas y Desventajas
Algunos dispositivos móviles que no tienen la posibilidad de usarse como receptores GPS
standalone, pueden no funcionar del todo si no se tiene una suscripción activa con una
empresa celular y se está dentro del rango de esa red.
Muchos celulares tienen embebido un receptor GPS, aunque este difiere de los GPS
standalone. El modo standalone es importante. Significa que no se necesita de la red de la
empresa telefónica en lo absoluto para usar el GPS y usualmente se puede instalar cualquier
software cartográfico.
Ahora bien, el uso de un GPS en un celular tiene como contra que la antena receptora en los
celulares es más chica que en los primeros, pero como ventaja, un GPS embebido en un
celular, cuenta con la ventaja de poder acceder a internet mediante la red celular y usar AGPS.
[21] El uso del A-GPS hace el proceso mucho más rápido. Reducir la espera significa que si uno
etiqueta una foto, ésta será etiquetada instantáneamente con las coordenadas (geotagged), se
pone un pin en un mapa, sobre la posición actual antes de que el mapa en sí termine de
cargarse, y el dispositivo que se usa en un lugar remoto, sabe al instante que está en el medio
de la nada, pudiendo, por ejemplo, Google proveerle de las publicidades basadas en su
ubicación actual, sin ninguna espera tediosa de su parte.
Muy frecuentemente, las antenas de la red celular tienen receptores GPS (o una estación base
cerca) y esos receptores de las torres celulares están constantemente pidiendo y obteniendo
información del satélite. Estos datos son luego enviados al celular (cuando se piden) y actúan
como un “engaño” debido a que los satélites usados por el dispositivo móvil para identificar la
posición en la que se encuentra uno están previamente identificados, y todos los cálculos de
GPS son hechos por computadoras y no por el mismo dispositivo. Este es el resultado de tal
sistema para el usuario final:
Adquisición de la ubicación más rápida. El dispositivo requiere menos poder para el procesamiento Ahorra vida de la batería Adquisición de ubicación en interiores o en condiciones ambientales no óptimas.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 48
Figura 24. Cómo funciona Sprint en USA [21]
2.7.5 ¿Cómo hace el GPS Asistido para obtener la ubicación si sólo 2 satélites están
disponibles?
Los receptores GPS autónomos tienen antenas mucho mejores que los teléfonos celulares y
otros dispositivos móviles.
A medida que los celulares han ganado en inteligencia, así también, la asistencia GPS se ha
modificado y ampliado.
Si sólo 2 satélites son visibles, entonces el celular puede usar la posición que obtiene por
medio de las torres celulares como si fuese un tercer satélite, aunque es menos preciso, ya que
el dispositivo móvil no está realmente donde está la antena.
2.7.6 Configuraciones A-GPS
Tomando como ejemplo Qualcomm (un fabricante de chips AGPS, llamado GPSOne) tiene 4
posibles configuraciones de A-GPS. Cómo está implementado A-GPS en el dispositivo,
aparentemente queda en consideración de los carriers (compañías de celulares).
Las 4 opciones son:
Standalone – El celular no tiene conexión a la red, y sólo usa las señales de los
satélites GPS que recibe en el momento para tratar de establecer una ubicación.
MS Assisted - El celular está conectado a la red, usa las señales de GPS más una señal
de localización, luego retransmite su ‘fix’ al servidor, quien luego usa la fuerza de la
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 49
señal del celular a las torres de la red para obtener su posición. El celular pasa los
datos recibidos a la red; la red geo-localiza el celular y envía las coordenadas de su
localización de vuelta al celular. Se puede mantener comunicación por voz en este
escenario, pero no servicio de internet/red. Por ejemplo Web Browser, IM, streaming
de TV, etc. El celular es como una terminal boba desde la perspectiva de la red. MS
Assisted fue necesario hace un tiempo debido a la performance de los celulares hace
varios años, pero esto cambió y ahora los celulares tienen mucho más poder de
cálculo.
Con MS Assisted es la red la que calcula la posición del celular y luego se la
envía.
No es el método que brinda mayor exactitud.
La localización asistida por MS trabaja mejor donde el dispositivo puede recibir datos
del satélite GPS (por ejemplo, al aire libre), pero puede proveer todavía localización
con una degradada exactitud sin los datos GPS (por ejemplo, en el interior de una
casa).
Actualmente, no hay en EEUU una solución asistida por MS, por lo menos
implementada en el mercado de consumo, o quizás está más extendido en EEUU,
aunque no en el resto del mundo.
Al mismo tiempo, los carriers inicialmente no querían dejar que el celular pudiera
calcular de forma rápida y precisa los datos de GPS porque podrían permitir que un
desarrollador cree LBS’s (Location Based Services) que podrían saltar un flujo de
ingreso para los carriers. Proveer “negocios y publicidad por cercanía” es una de las
ofertas de LBS, así como mapeo y navegación.
MS Assisted es particularmente apropiado para ciertas aplicaciones como E911,
donde hay aplicaciones muy sensibles, donde se quiere la localización tan
rápido como sea posible. En esos casos, definitivamente se requiere tener esa
interacción con el servidor de la red. Con el E911 el usuario no necesita conocer su
posición, sino que es la red la que necesita conocer la posición del usuario al realizarse
una llamada de ese tipo. No es aceptable que no se devuelva una ubicación en una
llamada E911, pero un pedido de localización de la pizzería más cercana puede ser no
devuelto.
Para otros tipos de aplicaciones, donde los usuarios quieren una respuesta inmediata
y la imprecisión es aún más tolerable en pos de una más rápida ubicación, usar la red
para calcular la posición toma demasiado tiempo.
Podría pasar que AGPS no funcione en teléfonos cuando un cliente hace roaming a otra
red similar. Tampoco podría funcionar a nivel internacional, o cuando los parámetros
de funcionamiento específicos no estuviesen disponibles, tales como estaciones base
suficientemente cerca.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 50
En paralelo con la ayuda de MS, un modo separado se desarrolló en la que el teléfono
tenía todas las cartas: MS Based.
MS Based - La red provee un estimativo inicial (via geolocalización basado en el ID de
la celda) de la localización del celular, y el celular hace su propia geolocalización
usando este estimativo inicial y la información recibida por el satélite.
El celular está conectado a la red y utiliza las señales de GPS más una señal de
localización desde la red.
En la operación MS-based, incluso los celulares de baja gama, tienen el poder para
obtener información de un GPS con la información que obtienen de la red
regularmente.
El modo MS-based obtiene datos enviados por sobre el plano del usuario, típicamente
una conexión de red IP regular manejada a través de redes celulares 2G
(GPRS/1xRTT), 2.5G (EDGE), o 3G (EVDO/UMTS/HSPA); o a través de un modo
propietario en el cual el operador de un celular maneja la comunicación desde un
software y hardware en el equipo a través de un servicio que éstos operan para asistir
en obtener una ubicación.
Con MS Based es el celular el que calcula la posición ayudándose de los datos
enviados por la red.
Tarda muy poco en encontrar los satélites.
Mientras que los datos enviados de esta manera no son muchos, sí usa la conexión de
datos. Es posible que algunos sistemas de GPS desacoplados de la red del carrier
incurran en grandes cargos de datos de roaming si se usa alguna aplicación que se
base en GPS mientras se está fuera de la localidad de uno y/o el país.
El modo MS-based puede desacoplar la red del carrier del AGPS por completo,
permitiendo todo tipo de escenarios; un operador móvil puede proveer todavía datos
de AGPS incluso cuando se está haciendo roaming; los dispositivos que soportan AGPS
pero que no son vendidos por el carrier pueden ser usados efectivamente en una red
celular, especialmente en los Estados Unidos, con más carriers sin querer o permitir
que más dispositivos y aplicaciones individuales puedan realizar sus propias
operaciones AGPS, dependiendo de cuán bajo nivel es su acceso a un receptor GPS
integrado o auxiliar. Con la plataforma Android, esta última opción es más probable
que con el iPhone 3G a la fecha de este estudio.
Cómo funciona el modo MS-based
El modo MS-based depende que el celular tenga un almanac almacenado, el
superconjunto de todos los ephemerides de los satélites. Recordar que un ephemeris
es una descripción de la órbita actual y futura de un satélite dado, válido por hasta 4
horas. Un GPS puede usar información de ephemeris cacheada entregada por un
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 51
servidor (en la red del operador o en cualquier parte del mundo), en lugar de recibir
los datos él mismo.
Un celular (e incrementalmente otros dispositivos móviles), pueden tomar un
pequeño subconjunto de datos transmitido por un satélite dado y usar el almanac
almacenado para determinar la posición actual aproximada del satélite. Esto permite
un relativo buen conjunto de resultados desde un segundo a unos pocos segundos,
dependiendo de varios factores de la red, línea de visión, y de la aplicación.
Recordar que mientras que la información completa de cada uno de los de satélite
tiene un ciclo cada 30 segundos, el tiempo actual se envía cada seis segundos. Esto
significa que un sistema AGPS no necesita esperar más de 6 segundos, y en promedio,
menos. Algunos sistemas son incluso más sofisticados, y pueden realizar los cálculos
sin recibir el timestamp completo.
Cuando la recepción es pobre o llena de errores, el GPS puede seguir recuperando
información luego de que obtiene la mínima cantidad de información necesaria, y esto
puede ser utilizado para producir un resultado más exacto luego de pasar desde
segundos a decenas de segundos, lo que depende de la aplicación. La aplicación de
mapas de iPhone (iPhone’s Maps) en un iPhone 3G que tiene GPS, por ejemplo, casi
inmediatamente muestra un perímetro azul oscilante para una ubicación aproximada.
Luego de varios segundos, los perímetros se contraen a un lento punto azul.
El desarrollo de MS-based AGPS ha reemplazado en su mayoría al modo MS-Assisted,
sin embargo, el modo MS-Assisted sigue siendo soportado por razones de
compatibilidad con versiones anteriores.
MS Assisted/Hybrid – Igual al anterior, pero se puede mantener la funcionalidad de
la red, normalmente, en áreas con excepcional cobertura
Figura 25. Arquitectura A-GPS. [22]
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 52
C A P Í T U L O 3
3.1 Iniciativas de Estandarización de Datos XML existentes
La interoperabilidad del sistema es muy importante, ya que existen muchos celulares
distintos, y el despliegue del sistema completo debe tener la menor complejidad posible así
como la mayor posibilidad de uso de la infraestructura existente. La interoperabilidad es más
que comunicación por voz, tanto las organizaciones como los sistemas no pueden compartir
fácilmente información de incidentes si no hay interoperabilidad clara entre todas las partes
involucradas.
Para la interacción entre los distintos entes, es vital tener un idioma común entre las distintas
aplicaciones, y de esta forma poder crear reportes históricos con información distribuida
entre los distintos sistemas. Esto hace necesaria la creación de protocolos y estándares
comunes a todas las aplicaciones.
Aquí se hace un resumen de los protocolos y estándares existentes en distintas partes del
mundo en relación a incidentes de tránsito y alertas en general. Luego, se muestra una
propuesta de mensajes a ser enviados desde el celular al servidor, de forma que ayuden a
disminuir y/o prevenir los heridos en accidentes viales, obtener estadísticas, etc.
Para poder generar interoperabilidad entre todas las partes involucradas, en EEUU se crearon
algunas alternativas para el intercambio de datos en caso de emergencias. Estas alternativas
hacen uso del estándar XML y las más importantes son:
Model Minimum Uniform Crash Criteria (MMUCC)
o Reporte que deben llenar los oficiales en la escena del choque para su
posterior análisis.
o Se actualiza cada 5 años
Vehicular Emergency Data Set (VEDS)
o Creado por el ComCARE Alliance ACN Data Set Working Group (911, EMS,
OnStar/ATX)
o Conjunto de datos que especifican información del accidente para poder ser
enviada de forma electrónica.
Emergency Data Exchange Language (EDXL)
o Iniciativa del DHS Disaster Management E-Gov
o Promueve el compartir la información de incidentes (interoperabilidad de
datos) para todos los peligros a través de la comunidad de respuestas a
emergencias.
EDXL – HAVE (Hospital Availability Exchange o Intercambio de
Disponibilidad de Hospitales)
EDXL – SitRep (Situation Reporting o Reporte de Situación)
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 53
EDXL – TEP (Tracking of Emergency Patients o Seguimiento de
Pacientes de Emergencias)
CAP - Common Alerting Protocol V1.1 (2005)
IEEE 1512
3.2 Model Minimum Uniform Crash Criteria (MMUCC) – 2008 [23]
3.2.1 ¿Qué es el MMUCC?
MMUCC es una guía que presenta un modelo con un mínimo conjunto de variables o
elementos de datos uniformes para la descripción de un accidente de tráfico de un vehículo
motorizado. El propósito del Model Minimum Uniform Crash Criteria (MMUCC) es
proporcionar un conjunto de datos para describir los accidentes de vehículos motorizados en
una carretera que van a generar la información necesaria para mejorar la seguridad en las
carreteras dentro de cada estado (estado en el caso de Estados Unidos, provincia en este caso)
y a nivel nacional. El uso de elementos de MMUCC genera datos que pueden ser empleados
para tomar decisiones más informadas que dan lugar a mejoras en la seguridad y en los
niveles nacional, estatal y local en los Estados Unidos. Algunos datos son opcionales, sin
embargo, se alienta a los estados a adoptar la mayor cantidad posible de elementos de datos
MMUCC recomendados al actualizar sus reportes policiales de accidentes.
Debido a que el MMUCC es un conjunto de datos mínimo, los estados y localidades pueden
elegir el recolectar elementos de datos relacionados al accidente automovilístico adicionales,
si piensan que los datos fueran necesarios para mejorar la toma de decisiones.
El MMUCC no intenta organizar los elementos de datos propuestos y sus valores de atributos
en un formato de reporte. El MMUCC tampoco presenta códigos de valores para los valores de
los elementos. Los estados tienen la opción de diseñar el contenido y el formato de sus
reportes de accidentes así como también el más apropiado sistema para la recolección de
datos y convenciones de códigos para llenar sus necesidades.
La guía MMUCC se actualiza cada cinco años para abordar las nuevas cuestiones de seguridad
en las carreteras, simplificar la lista de elementos de datos recomendados, y aclarar las
definiciones de datos y otros componentes de cada elemento de dato.
La tercera edición de la Guía (2008) contiene 107 elementos de datos MMUCC y la próxima
actualización se prevé que sea en 2013.
MMUCC fue originalmente desarrollado en respuesta a las peticiones de los estados
interesados en la mejora y estandarización de sus datos de accidentes de los estados. La falta
de unificación de los reportes hizo dificultosa la comparación de datos de accidentes de
estado. Diferentes elementos y definiciones resultaron en resultados con datos
incompletos y engañosos.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 54
MMUCC recomienda la aplicación voluntaria de un “conjunto mínimo" de elementos de datos
normalizados para promover la comparación de los datos dentro de la comunidad de la
seguridad vial. Sirve como base para los sistemas de datos de accidentes a nivel estatal.
Para reducir la complejidad de la recopilación de datos, MMUCC recomienda que la policía
recoja 75 de los 107 elementos de datos en el lugar, 10 elementos de datos que se pueden
derivar de los datos recopilados, y 22 elementos de datos a ser obtenidos luego de la
vinculación con la historia del conductor y los datos del inventario vial y de lesiones
Debido a que los conjuntos de datos y los sistemas estatales son difíciles de aplicar o
modificar, sólo se hacen cambios a la guía MMUCC cada cinco años. Durante este período, cada
uno de los elementos de datos y sus atributos se supervisan para determinar su utilidad y
fiabilidad.
3.2.2 Organización de los Elementos de Datos MMUCC
Cada elemento de dato MMUCC incluye:
Una definición,
Un conjunto de atributos especifico y
Una razón por la cuál es necesario.
Los elementos de datos se dividen en cuatro grupos principales que describen distintos
aspectos de un accidente:
Relacionados con los choques,
Relacionados con los vehículos,
Relacionados con las personas y
Relacionados con las carreteras.
MMUCC se compone de elementos de datos que se recomienda que sean capturados en la
escena del accidente, junto con los datos relacionados y los derivados. De la información de la
escena del accidente, se pueden derivar elementos de datos adicionales, lo que disminuye la
carga en la fuerzas de la ley. Se recomiendan elementos informativos adicionales mediante la
vinculación a la historia del conductor, hospital y otros datos de salud/lesiones, y los datos del
inventario vial.
3.2.3 Composición de los grupos de datos MMUCC por características
Los elementos de datos de los choques describen:
Fecha,
Hora,
Ubicación,
El primer y más dañino evento,
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 55
Tipo de choque,
Clima y
Circunstancias contribuyentes.
Los elementos de datos del vehículo describen:
Marca,
Modelo,
Año de fabricación,
Tipo,
Funciones,
Acciones,
Impacto,
Secuencia de eventos y
Áreas dañadas.
Los elementos de datos de personas describen todas las personas involucradas
por:
Edad,
Sexo,
Estado de las lesiones y tipo.
Número de vehículo,
Asiento ocupado
El uso del equipamiento de seguridad se recoge para todos los ocupantes del vehículo.
Elementos de Datos Recolectados en la escena
Elementos de datos del choque
Los elementos de datos de nivel de choque describen las características generales del
accidente.
Elementos de datos del vehículo
Los elementos de datos del vehículo describen las características, eventos, y
consecuencias del/los vehículo/s involucrados en el choque.
Elementos de datos de personas
Los elementos de datos de personas describen las características, acciones, y
consecuencias de las personas involucradas en el choque.
Elementos de Datos derivados y vinculados
Estos elementos de datos deben ser derivados de los datos recogidos en la escena o extraída
de otras bases de datos enlazados con la base de datos del accidente.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 56
Elemento de dato del choque derivado de los datos recolectados
Los elementos de datos derivados del choque están derivados de la
información computarizada, de la escena del choque.
Dependiendo del sistema usado, pueden ser derivados automáticamente por
sistemas de recolección de datos automáticos o pueden ser generados cuando
los datos están computarizados y combinados a nivel local, regional o estatal.
Estos elementos de datos derivados generalmente no están recolectados por
las fuerzas de la ley en la escena.
Elementos de datos de la persona derivados de los datos recopilados
Este dato es fácilmente generado después de la recolección y computarización
de los datos en la escena. Dependiendo del sistema utilizado, pueden ser
derivados automáticamente por los sistemas electrónicos de recopilación de
datos, o pueden ser generados cuando los datos se combinan en los planos
local, regional y/o estatal.
Elementos de Datos de la Persona obtenidos luego de la vinculación con otros
datos
Los elementos de datos de la persona "vinculados" se obtienen después de la
vinculación con el choque, la historia del conductor, las lesiones y/o datos de
otro estado. Cuando un estado no tiene la capacidad de establecer vínculos con
otros datos del estado, se deben recolectar tantos elementos de datos
"vinculados" de la persona como sea posible en la escena.
Elementos de Datos de Carreteras obtenidos luego de la vinculación con otros
datos
Los elementos de datos de carreteras son generados por la vinculación con el
inventario de accidentes viales y datos del hardware. Los elementos de datos
utilizados para la vinculación incluyen ubicación del choque y tantos otros
como sea necesario dependiendo del tipo de sistema de inventario vial
implementado por el estado. Cuando un estado no tiene un inventario de
caminos, se deben recolectar tantos elementos de datos como sea posible en el
lugar.
MMUCC no es un sistema de información sino una recopilación de datos en una lista de
elementos recomendados que deberían ser incluidos en los reportes policiales de choques.
No especifica el formato digital para el intercambio de los datos, no dice que se hará
por XML, podría ser un CSV por ejemplo. Se suele usar XML porque es más estándar y
sería más fácil para los distintos equipos ya existentes poder comunicarse con él.
24 de los 75 elementos de datos recomendados podrían ser provistos por EDRs, siglas
en inglés de Event Data Recorder, dispositivo instalado en algunos autos que graba
información relacionada a choques.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 57
3.3 VEDS - Vehicular Emergency Data Set (2004) [24]
3.3.1 Descripción
El Vehicular Emergency Data Set es un estándar basado en XML para reportar datos útiles y
críticos, tanto médicos como de las colisiones en sí. El estándar fue desarrollado por
ComCARE Alliance, y está destinado a la transmisión de información crítica para facilitar la
respuesta a la emergencia de forma eficaz.
Este conjunto de datos puede ser transmitido automáticamente a un centro de respuesta, el
que puede luego transferirlo a un proveedor de servicios de emergencia.
Es sólo un formato de intercambio de datos recomendado. No es un estándar/protocolo de
transmisión de datos. Cómo los TSPs (Telematics Service Providers) deciden enviar datos, y
cómo los organismos recogen datos, transmiten datos, lo enlazan a la voz, lo manipulan
dentro de varios organismos, etc. son todos temas críticos, pero no los que se abordan con el
VEDS. Sin embargo, este conjunto de datos común permitiría múltiples métodos de
transferencia y manipulación de datos.
El conjunto de datos está diseñado para ser usado por los TSPs (por ejemplo, OnStar, ATX
Techonologies), pero también puede ser utilizado por otras entidades que tengan incidentes
de emergencias vehiculares, incluidas las compañías de materiales peligrosos. Además, el
conjunto de datos está diseñado para permitir que otras entidades más allá del proveedor de
datos original pueda publicar datos en el "sistema" usando el mismo mensaje. El conjunto de
datos permite a un proveedor de datos, tales como TSP, enviar datos a uno o más
organismos sobre un incidente de emergencia. Ese podría ser el final del flujo de datos, o
podría ser el primer mensaje de muchos, dependiendo de cómo las agencias locales decidan
utilizar el conjunto de datos. Por ejemplo, un TSP puede enviar el mensaje original al sistema
y un organismo de respuesta EMS puede agregar datos recogidos en el lugar de la escena al
mismo mensaje y luego añadir más datos al mensaje camino al hospital. Además, otra
compañía del sector privado podría potencialmente agregar datos al mensaje, tal como un
proveedor de datos médicos personales que tiene datos médicos de uno o más ocupantes del
vehículo.
Los esfuerzos de la ComCARE ACN Data Set Working Group no se centraron en los protocolos
específicos de transmisión de datos o la forma óptima para enrutar los datos a los organismos
de seguridad pública. El objetivo del grupo fue determinar todos los campos que podrían ser
útiles en el conjunto de datos, definir cada uno de los elementos y sus formatos únicos,
presentando la información como una recomendación.
El Vehicular Emergency Incident Data Set está diseñado para permitir utilizar múltiples
métodos de transmisión. De hecho, es muy posible que una combinación de dos o más de los
métodos anteriores se puedan utilizar simultáneamente para enrutar los datos a múltiples
organismos de seguridad pública en una determinada región.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 58
3.3.2 Estructura de VEDS
Document Object Model
Figura 26 - VEDS Document Object Model - http://xml.coverpages.org/ComCARE-VEDSv20-2004.pdf
En muchos países, se implementaron tecnologías particulares de alertas públicas para
peligros o amenazas tales como eventos climatológicos o de defensa civil. Desde el punto de
vista de la sociedad de inversiones de alertas públicas, no tiene sentido continuar
construyendo sistemas de alertas públicos separados para cada peligro en particular. Un uso
eficiente de los fondos así como la efectividad de alertas públicas abogan por el uso de
estándares y la combinación de la alerta pública para todos los medios de cobertura con un
requisito de un enfoque para todas las amenazas en conjunto.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 59
3.4 CAP - Common Alerting Protocol V1.2 (2010) [25]
3.4.1 Descripción
CAP fue creado por OASIS (International Organization for the Advancement of Structured
Information Standards) y creó el Standard CAP-V1.2 de Julio de 2010.
El Common Alerting Protocol (CAP) es un formato de datos basado en XML para intercambiar
alertas y emergencias públicas entre distintas tecnologías de alertas. CAP permite que un
mensaje de alerta sea consistentemente diseminado simultáneamente entre muchos sistemas
de alertas y muchas aplicaciones. CAP aumenta la efectividad del alerta y simplifica la tarea de
activar el alerta a los oficiales responsables.
Un solo mensaje CAP puede disparar sirenas, el Sistema de Alerta de Emergencias, radios
climatológicas, sistemas de notificación telefónica y sistemas para gente con necesidades
especiales como sordos, por ejemplo.
Fue adoptado por la ITU (International Telecommunication Union, Telecommunication
Standardization Sector (ITU-T))
CAP es un formato simple pero general para intercambiar todo tipo de alertas de emergencias
de amenazas y alertas públicas sobre todo tipo de redes. Es un formato de datos estándar
abierto, no-propietario que puede ser usado para recoger todo tipo de alertas y/o amenazas y
reportarlas localmente, regionalmente o nacionalmente, como entrada de un gran rango de
sistemas de manejo de información y diseminación de alertas. CAP también facilita la
detección de patrones de emergencias en las alertas locales de varios tipos, tales como las que
pueden indicar una amenaza indetectable o un acto hostil.
A diferencia de MMUCC, CAP es un protocolo que usa XML y está destinado a todo tipo de
emergencias, no sólo vehiculares.
Algunos factores críticos que hacen efectivas a las alertas de emergencias son:
1. Los mensajes de alerta deben estar coordinados entre los distintos sistemas, para
poder llegar al mayor número de personas en riesgo con gran confiabilidad y para
dejar que el público confíe en que ha recibido una alerta legítima y no solo una falsa
alarma de un sistema en particular.
2. Los mensajes de alertas contienen toda la información que la gente en riesgo necesita
para evaluar su situación individual y tomar una acción apropiada. Los elementos
esenciales de una alerta incluyen: ubicación, franja horaria, severidad, probabilidad
que ocurra, junto con información confiable sobre la fuente del alerta y qué puede
hacer la población en riesgo para protegerse, y
3. Las alertas deben enviarse a la población en riesgo y no a aquellos que no serán
afectados; en otras palabras; las alertas eficientes están “dirigidas” a las personas
correctas en el momento correcto.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 60
Los beneficios clave de CAP incluyen la reducción de los costos y la complejidad operativa
eliminando la necesidad de interfases de software personalizadas para cada uno de los
muchos sistemas de alertas y amenazas. El formato del mensaje CAP puede ser convertido
desde y hacia cualquier formato “nativo” de cualquier sensor y tecnología de alerta, formando
una “internet de alerta” nacional e internacional, independiente de la tecnología.
3.4.2 Estructura de un mensaje de alerta CAP
Cada mensaje de alerta CAP consiste en un segmento <alert>, que puede contener uno o más
segmentos <info>, cada uno de los cuales puede contener uno o más segmentos <area>. En la
mayoría de los casos, los mensajes CAP con el valor <msgType> de “Alert” DEBERIA incluir al
menos un elemento <info>.
<alert>
El segmento <alert> provee la información básica sobre el mensaje actual: su propósito, su
fuente y estado, así como un identificador unívoco para el mensaje actual y enlaces (links) a
cualquier otro mensaje relacionado.
Un segmento <alert> puede ser usado sólo para mensajes de confirmación, cancelación o para
funciones de sistema, pero la mayoría de los segmentos <alert> incluyen al menos un
segmento <info>.
<info>
El segmento <info> describe un evento anticipado o actual en término de su emergencia
(tiempo disponible para prepararse), severidad (intensidad del impacto) y certeza (confianza
en la observación o predicción), así como también proveer descripciones de categoría y
textual del evento. También puede contener instrucciones para una respuesta apropiada por
destinatario del mensaje y varios otros detalles (duración del peligro, parámetros técnicos,
información de contacto, links a fuentes de información adicionales, etc.). Múltiples segmentos
<info> pueden ser usados para describir distintos parámetros (por ejemplo, para diferentes
“bandas” de probabilidad o intensidad) o para proveer la información en múltiples lenguajes.
<resource>
El segmento <resource> provee una referencia opcional a información adicional relacionada
al segmento <info> en el cual aparece en la forma de un elemento digital tal como una imagen
o un archivo de sonido.
<area>
El segmento <area> describe un área geográfica que se aplica al segmento <info> en el que
aparece. Descripciones de texto y codificadas (como códigos postales) son soportadas, pero la
representación preferida son formas geoespaciales (polígonos y círculos) y una altitud o
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 61
rango de altitudes, expresadas en términos estándares de latitud / longitud / altura en
concordancia con el datum8 geoespacial8 especificado.
3.4.3 Aplicaciones del Mensaje de Alerta CAP
El principal uso del Mensaje de Alerta CAP es proveer una única entrada para
activar todo sistema de alerta y aviso público.
Esto reduce la carga de trabajo asociada con el uso de múltiples sistemas de
alerta al mismo tiempo que mejora la confiabilidad técnica y la eficacia en la
audiencia
También, ayuda a garantizar la coherencia en la información transmitida a través
de múltiples sistemas de entrega de información, otra clave para la efectividad de
advertencia.
Una segunda aplicación de CAP es normalizar las alertas de varias fuentes para
poder ser agregadas y comparadas en forma tabular o gráfica, como ayuda para
tener conciencia de la situación o para detectar un patrón.
Los dispositivos que pueden reconocer la ubicación pueden usar la información en el Mensaje
de Alerta CAP para determinar, basados en su posición actual, si un mensaje particular es
relevante para sus usuarios o no.
El Mensaje de Alerta CAP también puede ser usado por los sistemas de sensores como
formato para reportar eventos importantes para los sistemas y centros de recopilación y
análisis.
3.4.4 Beneficios
Un beneficio clave del uso de CAP para enviar mensajes de alerta es que el emisor de la misma
puede activar múltiples sistemas de alerta con una sola acción o entrada de datos, esto tiene
los siguientes beneficios:
1. Usar una sola entrada de datos reduce el costo y la complejidad de notificar por
muchos sistemas de alerta.
2. Un sólo mensaje de entrada también provee consistencia en la información entregada
por muchos sistemas.
3. La gente recibe exacta corroboración de la alerta a través de múltiples canales.
8 Un datum geodésico es una referencia de las medidas tomadas. Es un conjunto de puntos de referencia en la superficie terrestre
en base a los cuales las medidas de la posición son tomadas y un modelo asociado de la forma de la tierra (elipsoide de
referencia) para definir el sistema de coordenadas geográfico. Se define como el punto tangente al elipsoide y al geoide, donde
ambos son coincidentes (Más información en Localizaciones Geográficas. El Datum. Ignacio Alonso Fernández-Coppel
(http://www.cartesia.org/data/apuntes/cartografia/cartografia-datum.pdf) y http://es.wikipedia.org/wiki/Datum
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 62
Esto es muy importante ya que investigadores han encontrado que la gente no actúa
típicamente en la primera alerta sino que empiezan a buscar una confirmación. Sólo
cuando se convencen que la alerta no es una falsa alarma, actúan en consecuencia.
3.4.5 Principio de Diseño y Conceptos (no-normativos)
Entre los principios que han guiado el diseño del Mensaje de Alerta CAP fueron:
Interoperabilidad – En primer lugar, el Mensaje de Alerta CAP debe proporcionar un
medio para el intercambio interoperable de alertas y notificaciones entre todo tipo de
sistemas de información de emergencia.
Completitud – El formato del Mensaje de Alerta CAP debe proveer a todos los
elementos de un mensaje de alerta público eficaz.
Implementación Simple – El diseño no debe imponer una carga excesiva sobre los
implementadores técnicos.
XML Simple y estructura portable – Aunque el uso principal previsto del Mensaje de
Alerta CAP es un documento XML, el formato debe permanecer lo suficientemente
abstracto para ser adaptable a otros esquemas de codificación.
Formato multi-uso – Un esquema de mensajes soporta varios tipos de mensajes (por
ejemplo, alert / update / cancellations / acknowledgements / error messages) en
varias aplicaciones (actual / exercise / test / system message.)
Familiaridad – Los elementos de datos y valores de códigos deben ser significativos
para los emisores del alerta y los receptores no expertos por igual.
Utilidad interdisciplinaria e internacional – El diseño debe permitir una amplia
gama de aplicaciones en el manejo de las emergencias y la seguridad pública y sus
aplicaciones aliadas y debe ser aplicable mundialmente.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 63
3.4.6 Estructura de un Mensaje de Alerta CAP
Document Object Model
Figura 27 - http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.pdf
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 64
Estructura
Cada mensaje CAP incluye información que describe el mensaje en sí mismo.
Los mensajes tiene números de identificación unívocos, y pueden referenciar otros
mensajes CAP relacionados.
La identificación de la información sobre los mensajes también incluye el estado y la
fecha de envío, permitiendo que los mensajes sirvan como actualizaciones o
cancelaciones de mensajes previos.
Además, los mensajes son identificados por fuente, y son compatibles con la
encriptación digital y técnicas firmado digital que aseguran la fiabilidad y la
seguridad del mensaje.
La información sobre un evento en un mensaje CAP puede estar contenida en
múltiples segmentos de información.
Cada segmento de información incluye una descripción del evento en términos de su
urgencia, severidad y certeza de que ocurra realmente.
CAP tiene descripciones separadas para cada una de estas tres características.
La urgencia describe cuánto tiempo hay disponible para prepararse.
La severidad describe la intensidad del impacto.
La certeza es una medida de probabilidad en la observación o predicción que se hizo.
El evento puede ser asignado a una categoría (por ejemplo, geofísica, meteorológica,
seguridad, rescate, fuego, salud, ambiente, transporte, infraestructura), y también está
descrita en texto.
CAP también permite la inclusión de imágenes y audio digital asociado. La inclusión de
mensajes de audio, por ejemplo, permite que las alertas sean enviadas directo a la
radio, sin requerir que alguien las lea.
Segmentos de información múltiple permiten que el mensaje sea transmitido en
múltiples lenguajes o a múltiples audiencias.
Debido a que los segmentos están asociados con una descripción geográfica, los
múltiples segmentos pueden ser usados también para transmitir información sobre
bandas de intensidad. Por ejemplo, un incendio industrial podría desarrollar una
explosión grande. La persona a cargo del incidente necesitaría especificar varias cosas:
evacuación en un área de un kilómetro del fuego; instrucciones de refugio; un pedido
para los medios y los aviones de mantenerse a más de cierta cantidad de metros de
altura cerca del incendio. Usado CAP, la persona a cargo del incidente puede enviar un
solo mensaje incluyendo los elementos apropiados del mensaje para cada área. Esta
persona suministraría las descripciones geográficas, expresadas como latitud, longitud
y altura describiendo un polígono mostrado en un mapa mientras completa el mensaje
CAP.
Data Dictionary
A menos que se explicite con el diccionario de datos o el esquema XML, los elementos CAP
pueden contener valores nulos. Los implementadores DEBEN comprobar esta condición ya
que podría afectar la performance de la aplicación
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 65
Está es una diferencia con MMUCC, el que al no ser XML, no habla de proveer todo lo que
sigue, aunque si se implementase con XML seguramente lo tendría.
WGS-84
Las ubicaciones geográficas en CAP están definidas usando el sistema WGS 84 (World Geodetic
System 1984). CAP no asigna responsabilidades por transformaciones de coordenadas desde y
hacia otros sistemas de referencia espacial.
Seguridad
Debido a que CAP es un formato basado en XML, los mecanismos de seguridad de XML se
pueden usar asegurar y autenticar su contenido. Mientras que estos mecanismos están
disponibles para asegurar los Mensajes de Alerta CAP, no deben ser usados
indiscriminadamente.
Dos nuevos tags se agregan aquí: “Signature y “EncryptedData”.
Ambos elementos son hijos del elemento <alert> y son opcionales. Si el elemento
“EncryptedData” existe, ningún otro elemento será visible hasta que el mensaje haya sido
desencriptado. Esto hace que el mensaje CAP más pequeño sea un elemento de <alert> que
encierra un elemento EncryptedData. El mensaje CAP más grande donde el elemento
EncryptedData está presente, será entonces un elemento <alert> que contenga un solo
elemento EncryptedData y un solo elemento Signature.
Firmas Digitales
El elemento alert de un Mensaje de Alerta CAP PUEDE tener una firma digital, tal como se
describe en XML238 Signature and Syntax Processing [XMLSIG]. No se debe usar otro
mecanismo de firma XML en Mensajes de Alerta CAP.
Los procesadores NO DEBEN rechazar un Mensaje de Alerta CAP que contengan dicha firma
simplemente porque no pueden verificarla; DEBEN continuar procesando y PUEDEN informar
al usuario de la falla al intentar validar la firma.
Encriptación
El elemento alert de un Mensaje de Alerta CAP PUEDE estar encriptado, usando los
mecanismos descriptos por XML Encryption Syntax and Processing [XMLENC]. No se debe
usar otro mecanismo de encriptación en Mensajes de Alerta CAP; sin embargo, los
mecanismos de encriptación de la capa de transporte pueden ser usados independientemente
de este requerimiento.
Las alertas pueden ser convertidas automáticamente y de forma segura CAP XML en formas
que sirvan para cada tecnología: Internet, noticias, televisión, radio, teléfonos, Internet, etc.
Las entradas pueden ser manuales o de fuentes automáticas
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 66
Fuentes automáticas - Relays, Gateways y Buffers
Un caso especial de fuente automática es una que no origina el mensaje CAP sino que sólo
reenvia el mensaje recibido a algún otro lado. Dichos dispositivos actúan como destinatarios y
como orígenes y también pueden realizar un procesamiento adicional como filtrado, ruteo o
solo almacenaje.
Una consideración importante en dichos nodos es la integridad de cada mensaje CAP. Un
mensaje CAP que fue modificado no debe presentarse como el mismo mensaje CAP! Un
mensaje CAP modificado debe ser presentado como un nuevo mensaje, con su propio nombre
único de emisor/identificador. Puede (en efecto, probablemente deba) incluir un <reference>
al mensaje/s original/es. Esto es especialmente importante cuando se usan firmas digitales,
ya que cualquier modificación al mensaje original invalida la firma y hace imposible la
autenticación.
Transporte
La especificación CAP no especifica un transporte; esto es, no especifica ni le importa cómo los
mensaje CAP son transmitidos de un lugar a otro, (mientras sean transmitidos
correctamente!), por lo cual una de las primeras preguntas que el diseñador de la aplicación
debe resolver es, “Cómo se moverán los mensajes”
Descripciones geoespaciales (áreas)
CAP permite un manejo de áreas bien específico, las áreas fijadas como dentro de la amenaza
se especifican caso por caso, usando una o más instancias de dos geometrías geoespaciales:
Un círculo definido por la latitud/longitud como centro y un radio a su alrededor.
Un polígono (una forma regular o irregular cerrada) definida por una serie de puntos
que la circundan.
Un simple cálculo geométrico puede luego ser hecho por cada destinatario para determinar si
está dentro de un área determinada, en particular la alerta.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 67
3.5 IEEE 1512
3.5.1 Descripción
Con el incremento de los viajes a través de los Estados Unidos y más allá, los Sistemas
Inteligentes de Transporte (ITS por sus siglas en ingles) son vitales para asegurar seguridad,
proteger el medio ambiente y para aliviar la congestión de tráfico. En un trabajo conjunto
entre el United States Department of Transportation (USDOT) y el Institute of Electrical and
Electronics Engineers, Inc. (IEEE) se desarrolló una familia de estándares conocidos como
1512®.
La familia de estándares [26] IEEE 1512 son conjuntos de mensajes de manejo de eventos e
incidentes de tráfico relacionados. Proveen acciones comunes en respuesta al manejo del
conjunto de los mensajes de incidentes de tráfico, seguridad pública, e incidentes con
materiales peligrosos. El manejo de los incidentes de tráfico consiste en usar los recursos
disponibles de varias disciplinas para mitigar un incidente de una manera apropiada y
eficiente. Así, un conjunto estandarizado de mensajes reduce la duplicación de mensajes entre
las distintas organizaciones y ayuda a los proveedores o servicios a interactuar efectiva y
eficientemente.
La familia IEEE 1512 de estándares incluye:
IEEE 1512 - 2000 (Conjuntos de Mensajes de Gestión Común de Incidentes para ser
usados por Centros de Gestión de Emergencias)
IEEE 1512.1 - 2003 (Gestión del tráfico)
IEEE 1512.2 - 2004 (Seguridad Pública)
IEEE 1512.3 - 2002 (Materiales Peligrosos)
IEEE P1512.4 - (Entidades Externas a los Centros)
3.5.2 La familia de estándares
Gestión Común de Incidentes
El estándar IEEE 1512®-2000, Conjuntos de Mensajes de Gestión Común de Incidentes para
ser usados por Centros de Gestión de Emergencias, es un estándar base para la gestión de
incidentes. Los otros estándares IEEE 1512 deben ser usados a partir de este estándar, que
contiene la información básica — como descripción del incidente — a ser intercambiado por
centros de gestión de emergencias y tráfico para cualquier incidente.
Gestión de Incidentes de Tráfico
El estándar IEEE 1512.1®-2003, Conjuntos de Mensajes de Gestión de Incidentes de Tráfico
para para ser usados por Centro de Gestión de Emergencias, provee el framework para toda la
información necesaria para responder a incidentes relaciones con el tráfico en tiempo real. Un
conjunto de mensajes es una serie de mensajes individuales para intercambiar información
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 68
sobre un tema en particular. Este estándar establece un template o patrón, para construir
conjuntos de mensajes. Por ejemplo, los conjuntos de mensajes definidos en el estándar
abordan cuestiones tales como flujo de tráfico, gestión de los recursos de equipos de control
de tráfico, limpieza y reparación, e identificación de los destinatarios de los mensajes (tales
como el encargado del incidente) por sus funciones específicas en el incidente. Además, este
se aplica cuando se requiere que un centro de gestión de tránsito controle otros dispositivos
en otros centros. Este estándar debe ser usado en conjunto con el Estándar Base.
Seguridad Pública
IEEE P1512.2®, Conjuntos de Mensajes para la Gestión de Incidentes de la Seguridad Pública
para ser usados por los Centros de Gestión de Emergencias, transmite conjuntos de mensajes
para la comunicación y coordinación entre agencias de seguridad pública, incluyendo centros
de gestión de tráfico, servicios médicos de emergencia, fuerza de la ley, bomberos y rescates,
especialmente para gestión de recursos interagencias. Este estándar debe ser aplicado junto al
Estándar Base.
3.5.3 Beneficios
Los beneficios de usar la familia de estándares IEEE 1512 incluye:
Coordinación interjurisdiccional e interagencia
Despacho más rápido
Menos dependencia en la comunicación de voz
Reconciliación de las diferencias entre los procedimientos de respuesta, entre todas
las agencias de seguridad pública.
Acceso en tiempo real a imágenes
Menor necesidad de tipear los datos
3.6 Emergency Data Exchange Language (EDXL) Distribution Element v. 1.0 [27]
3.6.1 Descripción
El Emergency Data Exchange Language (EDXL) o Lenguaje para el intercambio de Datos de
Emergencias es una familia de estándares XML relacionados el intercambio de mensajes e
información en relación a accidentes, emergencias y desastres.
Los estándares EDXL se pueden clasificar en tres categorías:
1. Un estándar que especifica el enrutamiento de los datos para la información de
emergencia, incluyendo:
a. EDXL Distribution Element (EDXL-DE)
2. Un estándar que especifica el contenido, que incluye:
a. EDXL Resource Messaging (EDXL-RM)
b. EDXL Hospital AVailability Exchange (EDXL-HAVE)
c. EDXL Situation Reporting (EDXL-SitRep)
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 69
d. EDXL Tracking of Emergency Patients/Victims (EDXL-TEP/TEV)
3. Un estándar que incluyen ambos enrutamiento y contenido, incluyendo:
a. EDXL Common Alerting Protocol (EDXL-CAP)
La especificación del Elemento de Distribución describe un framework para la distribución de
un mensaje estándar para compartir datos entre sistemas de información de emergencias
usando EDXL (Emergency Data Exchange Language) basado en XML. Este formato puede ser
usado sobre cualquier sistema de transmisión de datos, incluyendo pero no limitándose al
binding SOAP HTTP.
El objetivo principal del Elemento de Distribución es facilitar el enrutamiento de cualquier
mensaje de emergencia XML con un formato correcto a los destinatarios.
El Elemento de Distribución puede ser pensado como un “contenedor”. Provee la información
para enviar conjuntos de mensajes particulares (como alertas o Mensajes de Recursos),
incluyendo información clave de enrutamiento como:
Tipo de Distribución,
Geografía,
Incidente, y
Identificaciones del emisor/destinatario.
3.6.2 Estructura del Elemento de Distribución EDXL
El Elemento de Distribución de EDXL (DE por sus siglas en ingles) comprende un element
<EDXLDistribution> como está descripto luego, elementos opcionales <targetArea>
describiendo un área objetivo geoespacial o política para la entrega del mensaje, y un
conjunto de elementos <contentObject> cada uno conteniendo información especifica en
relación a un ítem de contenido particular. El contenido incluido puede ser cualquier XML u
otro tipo de contenido o una URI para acceder al contenido. El bloque <EDXLDistribution>
puede ser usado sin contenido para formar el cuerpo de una query de enrutamiento para, o en
respuesta de, un servicio de directorio.
<EDXLDistribution>
El elemento <EDXLDistribution> sostiene la intención del autor en cuanto a la difusión del
mensaje o del conjunto de mensajes.
El uso del elemento <EDXLDistribution> no garantiza que todos los enlaces y nodos de las
redes van a implementar la política de difusión afirmada o que no ocurrirá una divulgación
involutaria. Donde hay información sensible que se está transmitiendo por redes no seguras,
se debe usar encriptación en concordancia con el estándar Web Services Security (WSS) [28]
con cualquier actualización y fé de erratas publicada por el OASIS Web Services
Security Technical Committee [29], o algún otro esquema de encriptación que sirva.
<targetArea>
El <targetArea> es un elemento contenedor de una zona geoespacial o política, objetivo del
destinatario del contenido del mensaje. Contiene datos necesarios de la intención del autor,
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 70
basados tanto en la ubicación del objetivo, como en la difusión de ese mensaje particular o
conjunto de mensajes.
<contentObject>
El <contentObject> es un elemento contenedor para mensajes específicos. El elemento
<contentObject> DEBE o bien contener un contendor de contenido <xmlContent> o bien un
contenedor de contenido <nonXMLContent>.
Aplicaciones del Elemento de Distribución del EDXL
El uso primario del Elemento de Distribución del EDXL es identificar y proveer información
para habilitar el enrutamiento de los mensajes encapsulados, llamados Content Objects. Es
usado para proveer un mecanismo común para encapsular la información del contenido.
Requerimientos para el diseño
La especificación del Elemento de Distribución debe:
1. Definir una sola estructura XML (a una estructura equivalente si es transcodificada en
algún otro formato) incluyendo los elementos requeridos y opcionales definidos
debajo
2. Especificar un área geográfica de entrega, expresada en coordenadas geoespaciales o
códigos políticos/administrativos
3. Permitir la habilidad de encapsular el payload (payload serían headers o metadata por
ejemplo) o conjunto de payloads
4. Adoptar un enfoque modular para la enumeración de los valores de los elementos que
puede evolucionar con el tiempo, por ejemplo, haciendo referencia a un esquema
diferente para esas enumeraciones
5. Especificar identificadores únicos de emisor y distribución
6. Especificar la fecha y hora cuando la distribución fue realizada
7. Especificar la acción que puede tener el mensaje de distribución (por ejemplo, mundo
real, prueba, ejercicio)
8. Especificar el tipo funcional del mensaje de distribución (por ejemplo reporte, request,
actualización, cancelación, etc.)
9. Especificar que los siguientes elementos pueden estar presentes en un payload válido:
10. Una especificación del formato del mensaje de distribución (por ejemplo la URI de un
esquema XML para el mensaje)
a. El rol funcional y/o el tipo de emisor del mensaje de la distribución
b. Uno o más roles funcionales y/o el tipo de destinatarios deseados del mensaje
de distribución
c. Una referencia a uno o más mensajes de distribución previos
d. Uno o más tipos de respuesta de las actividades involucradas
e. Una referencia al tipo de incidente
f. Una o más caracterizaciones de la etiología del sujeto del evento o incidente
(por ejemplo terrorismo, natural, bajo investigación, etc.)
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 71
g. El nombre u otra identificación del incidente de uno o más eventos o
incidentes
h. Una referencia a uno o más tipos de respuesta
i. Una o más direcciones de destinatarios específicos (como una URI)
j. Especifica una afirmación del nivel de confidencialidad de los payloads
combinados.
11. Además, el elemento Content Object contenido en el Elemento de Distribución (DE)
DEBE:
a. Permitir la encapsulación de uno o más payloads en cada uno de los elementos
Content Object.
b. Especificar el rol funcional y/o el tipo de emisor de cada payload
c. Especificar uno o más roles funcionales y/o los tipos de destinatarios deseados
de cada payload
d. Especificar una medida del nivel de confidencialidad de cada payload.
12. Proporcionar o hacer referencia a las listas específicas (enumeraciones) de los valores
y sus definiciones para:
a. Tipos de incidentes
b. Tipos de riesgos y/o eventos
c. Tipos de agencias
d. Tipos de actividades de respuesta
e. El rol funcional y/o tipo de emisor
f. Los roles funcionales y/o tipos de destinatarios deseados
g. El nombre u otra identificación del incidente de uno o más eventos o
incidentes
Un ejemplo de uso es el siguiente:
Cuando ocurre un gran accidente que involucra un auto y un camión con líquidos peligrosos
en una carretera. Se envían notificaciones automáticas por separado del auto y del camión
usando Vehicular Emergency Data Set (VEDS), contenidos en el Elemento de Distribución. El
Centro de Gestión de Transporte (TMC por sus siglas en inglés) comparte la información
(relacionada al accidente) con la adyacente TMC, usando el IEEE 1512 Incident Management
Message Set. Este conjunto de mensajes es intercambiado usando el Elemento de Distribución
EDXL.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 72
3.6.3 Estructura del Elemento de Distribución del EDXL
Document Object Model
Figura 28 - http://www.oasis-open.org/committees/download.php/17227/EDXL-DE_Spec_v1.0.html
Diccionario de datos
Nota: A menos que esté explícitamente especificado en el diccionario de datos, los elementos
EDXL-DE PUEDEN tener valores nulos. Los implementadores DEBEN comprobar esta
condición donde puede afectar la performance de la aplicación.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 73
3.7 Minimum Set of Data (MSD) – Usado por eCall
Como ya se vio en el capítulo 1 (AACN) eCall, el sistema en desarrollo para Europa usa un
mensaje llamado MSD (Minimum Set of Data).
A continuación, se muestra la estructura del mismo según el estándar CEN/TS 15722:2009
“Road transport and traffic telematics – eSafety – ECall minimum set of data (MSD)”.
M – Campo de Datos Mandatorio
O – Campo de Datos Opcional (caracteres blancos por omisión)
Número
de
bloque
Nombre Posición del Byte Tipo Uni-
dad
Descripción
Primer
Byte
Último
Byte
1 ID 1 5 String M Secuencia de inicio para
MSD (en presentación
XML)
Ejemplo <MSD>
6 Entero M Versión del formato del
mensaje MSD para
discriminar de futuros
formatos MSD.
7 Entero M Identificador del mensaje,
comenzando con 1 e
incrementándose con cada
retransmisión luego del
accidente.
2 Control 8 Entero M Bit 7: 1 = Activación
automática
0 = Activación manual
Bit 6: 1= Llamada de
prueba
0= Emergencia real
Bit 5: 1= Sin confianza en
la posición
0= La posición es
confiable
Bit 4-0: Codificación del
tipo de vehículo, por
ejemplo
00001 = vehículo de
pasajeros (Clase M1)
00010 = micros y autos
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 74
(Clase M2)
00011 = micros y autos
(Clase M3)
00100 = vehículos
comerciales livianos (Clase
N1)
00101 = vehículos pesados
(Clase N2)
00110 = vehículos pesados
(Clase N3)
00111 = motos (Clase L1e)
01000 = motos (Clase L2e)
01001 = motos (Clase L3e)
01010 = motos (Clase L4e)
01011 = motos (Clase L5e)
01100 = motos (Clase L6e)
01101 = motos (Clase L7e)
Nota 1: Las definiciones de
los vehículos clase M, N de
acuerdo a la Directiva
2007/46/EC; clase L de
acuerdo a la Directiva
2002/24/EC
Nota 2: El bit 5 a ser
configurado si la posición
no está en los límites de
+/- 150m con un 95% de
confianza.
3 Identificaci
ón del
vehículo
9
9
12
18
11
11
17
25
String M Número VIN de acuerdo
con ISO 3779
Índice mundial de
fabricación (WMI)
Descriptor del Tipo de
Vehículo (VDS)
Secuencia de Identificación
del Vehículo. (VIS)
4 Tipo de
almacenam
iento de
26 Entero M Este byte identifica el tipo
de almacenamiento de
energía del vehículo
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 75
propulsión
del vehículo
presente.
0 = indica tipo de
almacenamiento no
presente.
1= indica tipo de
almacenamiento presente
Todos los bits en 0 indican
tipo de almacenamiento de
energía desconocido.
Bit 7: Sin uso
Bit 6: Sin uso
Bit 5: 1 = almacenamiento
de hidrógeno
Bit 4: 1= almacenamiento
de energía eléctrica
Bit 3: 1=Gas propano
liquido (LPG)
Bit 2: 1= Gas natural
comprimido (CNG)
Bit 1: 1= tanque diesel
presente
Bit 0: 1= tanque de
gasolina presente
Nota 3: Esta información
puede ser poco fiable si se
cambió el tipo de
propulsión del vehículo
(por ejemplo de gasolina a
CNG)
Nota 4: Más de un bit
puede ser configurado si
hay más de un
almacenamiento de
energía presente.
5 Timestamp 27 30 Entero UTC
sec
M Fecha y hora del incidente
6 Ubicación
del vehículo
31 34 Entero Miliarc
sec
M Latitud de la posición (ISO
6709)
35 38 Entero Miliarc M Longitud de la posición
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 76
sec (ISO 6709)
Dirección
del vehículo
39 40 Entero 2
grados
M Dirección del recorrido
pasos de 2 grados (desde el
Norte magnético (0 – 356,
en el sentido del reloj)
7 Ubicación
reciente del
vehículo
n – 1
40 40 Entero 100
miliarc
sec
O Delta de latitud (+ para
Norte y – para Sur) con
respecto a la ubicación
actual del vehículo (por
ejemplo 1 unidad = 3mts)
en bloque 6, que será 0 si
no se provee información
41 41 Entero 100
miliarc
sec
O Delta de longitud (+ para
Este y – para Oeste) con
respecto a la ubicación
actual del vehículo, en
bloque 6, que será 0 si no
se provee información
8 Ubicación
reciente del
vehículo
n – 2
42 42 Entero 100
miliarc
sec
O Delta de latitud (+ para
Norte y – para Sur) con
respecto a la ubicación
actual del vehículo (por
ejemplo 1 unidad = 3mts)
en bloque 6, que será 0 si
no se provee información
43 43 Entero 100
miliarc
sec
O Delta de longitud (+ para
Este y – para Oeste) con
respecto a la ubicación
actual del vehículo, en
bloque 6, que será 0 si no
se provee información
9 Nro. de
pasajeros
44 44 Entero O Mínimo número conocido
de cinturones de seguridad
abrochados, será 255 si no
hay información
disponible.
Nota 5: La información es
relevante sólo para
llamadas eCall iniciadas
automáticamente y es sólo
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 77
es indicativa ya que no
siempre se proveerá la
cantidad exacta de
pasajeros (por que los
cinturones no hayan sido
puestos o estén puestos
por otras razones)
10 Proveedor
del servicio
45 60 Entero IPv6 O Dirección IPv6 del
proveedor del servicio en
formato de longitud fija
con ceros a la izquierda.
Si no hay un proveedor de
servicio identificado, se
llena con ceros.
11 Campo de
formato
61 61 Entero M Formato de los siguientes
datos adicionales
opcionales:
0= Sin datos adicionales
opcionales *
1= datos binarios
2= BCD
3= datos codificados XML
4= ASN, 1 dato definido
BER
* Si el valor del campo 11
es 0 (sin datos
adicionales), entonces el
mensaje puede ser
truncado de acuerdo al
bloque 14 debajo.
12 Campo de
control del
frame
62 65 M Protección CRC-32 (ISO
3309) para asegurar los
datos mandatorios del
MSD desde el byte 1 al 61.
MSD almacenado en el byte
62.
13 Datos
adicionales
optativos
66 138 String A
definir
O Los restantes 69 bytes de
datos codificados de
acuerdo al formato del
campo 11 a ser usados por
los proveedores de
servicios. Los bytes sin uso
deben ser llenados con
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 78
ceros.
El formato de dichos
conceptos de datos
opcionales pueden ser
provistos en una versión
futura de la especificación
técnica actual o pueden ser
encontrado en un registro
de datos que cumple EN
ISO 24978
Los datos opcionales
deben estar protegidos por
un CRC apropiado.
14 Delimitador 139 144 String M Delimitador MSD
Ejemplo </MSD>
Donde el byte 61 (campo
de formato) es establecido
a cero (sin datos
adicionales) el delimitador
puede ser enviado
comenzando el byte 66.
Tabla 1 – Estructura del mensaje MSD sin codificar
El mensaje se codifica en el formato DTMF de llamada telefónica.
El sistema eCall está diseñado para que los datos adicionales sean enviados a través del centro
de servicios en el mensaje FDS
Los bytes individuales de cada elemento de datos MDS son convertidos a dos señales DTMF
usando la siguiente tabla.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 79
Tabla 2 – Tabla de conversión de 1 byte MDS a dos señales DTMF - Finnish eCall Experts 6.6.2005 - eCall Discussion Paper
Usando código DTMF es posible enviar sólo los números 0-9, letras A-D, y marcar # y *. La
conversión de datos binarios a DTMF se realiza traduciendo los 19 bytes a números
hexadecimales y reemplazando la E y la F con # y *, respectivamente.
Por ejemplo, los bytes "243 14 6" se codifican como los números hexadecimales que siguen:
"F3 0E 06" y luego del reemplazo la secuencia DTMF resultante "*30#06".)
El contenido de los datos y el formato de los mensajes eCall está basado en el estándar CEN/TS
15722:2009 “Road transport and traffic telematics – eSafety – ECall minimum set of data
(MSD)”.
La transmisión de los datos se puede hacer usando el canal de voz para enviar códigos DTMF
o redes IP (por ejemplo GPRS) usando el método HTTP POST.
A lo largo de la duración de la llamada de emergencia y después de la recepción de los
MSD por el PSAP
Deberá ser posible para el PSAP enviar una confirmación al IVS que se usó el MSD.
Deberá ser posible para el PSAP pedir al IVS que vuelva a enviar su MSD más reciente.
Deberá ser posible para el PSAP encargar al IVS terminar la llamada.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 80
Algunos otros requerimientos y objetivos de rendimientos de eCall
La transmisión de vehículo MSD (140 bytes) de forma simultánea con las llamadas de
voz
La transmisión del MSD debe ser rápida (menos de 4 segundos) y fiables
(acknowledged)
Capacidad de transmisión de MSD cuando se usa roaming en el exterior (utilizando
llamadas gratuitas 112)
No deben hacer falta modificaciones en las redes celulares existentes.
Las transmisiones de SMS se pueden retrasar y no priorizar.
Los canales de datos pueden no estar disponibles en todas partes, por lo general no se
priorizan.
3.8 Full Set of Data (FSD)
Las terminales dentro del vehículo envían el mensaje full data set (FDS) al centro de servicio.
El mensaje está en formato XML y se transmite sobre la red IP (GPRS, o tecnología más veloz)
usando el método HTTP POST. El centro del servicio va a controlar la validez de la estructura y
contenido del mensaje usando el esquema XML [http://www.w3.org/XML/Schema].
El centro de servicio reenvía los mensajes válidos FDS recibidos al PSAP (Centro de recepción
de llamadas de emergencia). Además, el centro de servicio puede proveer información
adicional o completar información faltante. (Por ejemplo, el centro puede incluir una base de
datos conteniendo información sobre el vehículo.) La información adicional puede ser enviada
como un mensaje separado (FDS+) siguiendo el mensaje FDS original. Todos los mensajes se
envían usando HTTP POST.
Este (FDS) aún no ha sido estandarizado pero algunos campos que se sugirieron para
Finlandia, por ejemplo, y se puede encontrar en
http://www.esafetysupport.org/download/eu_member_states/eCall_fds_mds.pdf o en
http://www.ecall.fi/eCall_060519.pdf son:
Full Data Set (FDS) - Usado por eCall
Los mensajes FDS incluyen la siguiente información:
Contenido
Status
Tipo de Mensaje
Version
Control de Mensaje
Nivel de privilegio
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 81
Tipo de vehículo
Cargo
Fabricante del vehículo
Año de fabricación del
vehículo
Número de identificación
del vehículo
Número de licencia del
vehículo
Color del vehículo
Modelo del vehículo
Código MSID del terminal
Fabricante del terminal
Versión de hardware del
terminal
Versión de software del
terminal
Número de serie del
terminal
IP del proveedor de servicio
Dirección
Número de teléfono del
proveedor de servicio
País del proveedor de
servicio
Timestamp
Ubicación actual
Dirección de manejo
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 82
Velocidad
Ubicación anterior
Cambio de posición
Origen del mensaje
Reconocimiento de
accidente
Intensidad del accidente
Número de pasajeros
Más datos del accidente
Otra información
Tabla 2. El contenido del mensaje FDS.
La estructura y semántica del mensaje se describe por un esquema XML que está ubicada en la
siguiente dirección pública:
http://www.ecall.fi/schemas/fds_schema.xsd
La estructura genérica XML del mensaje FDS es como sigue:
<?xml version="1.0" encoding="ISO-8859-1"?>
<fds>
<header>...</header>
<ivs>...</ivs> <setting>...</setting>
<incident>...</incident>
<info>Additional information</info>
</fds>
Un ejemplo del mensaje FDS:
http://www.ecall.fi/examples/fds_example.xml
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 83
3.9 Protocolos propuestos
Luego del análisis de MMUCC, VEDS, EDXL, MDS y FDS, vistos anteriormente, lo que se decidió
en la tesis es la elaboración de un protocolo/esquema corto, mínimo para la comunicación de
la emergencia en sí. Al detectar un choque se enviará primero el UDS (Urgency Data Set) a los
servicios de emergencia, policial, bomberos, etc, luego de recibir el acknowledge de que el
primero se recibió ok, se enviará el segundo (EDS (Extended Data Set)), encargado de
amplificar los datos enviados anteriormente y finalmente, de existir, se enviará un archivo
comprimido conteniendo los archivos con datos de los últimos 60 segundos de los sensores en
el dispositivo móvil. Tanto los primeros datos como los segundos formarán parte de un
conjunto de datos general aplicado a cada accidente, el cual residirá en una base de datos.
3.9.1 Urgency Data Set - UDS
Nombre Tipo de
datos Descripción
CrashDate datetime Fecha UTC de cuando ocurrió el accidente. Viene desde el
dispositivo móvil.
UdsVersion varchar Versión del mensaje EMS. Necesario por si en el futuro cambia
o una máquina debe leerlo en el medio del transporte.
CrashId bigint Foreign key to the Crash record.
Speed int En km/h
Bearing float En grados * 255 / 360 (redondeado al entero más cercano).
Latitude float Latitud WGS84 en grados (decimales) *2^16 (signado -90 90)
Longitude float Longitud WGS84 en grados (decimales) *2^15 (signado -180
180)
Accuracy float Precisión obtenida en la ubicación del choque
Rollover char True si se detectó un vuelco
AutomaticTrigger char True si la activación no fue manual
AirbagDeployed char True si se detectó que el airbag fue activado
CountryId int Id del país desde donde fue enviado el mensaje UDS.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 84
MobileNumber nchar Número de teléfono desde el cual se envió el mensaje UDS.
SubscriberId varchar El id único de suscripción, por ejemplo, el IMSI para un
dispositivo móvil GSM.
RetriesNumber Int En cuántos reintentos se pude enviar. 0 sería que se envió al
primer intento.
isTest Bit True si es un test. Esto sirve para pruebas en ambientes pre-
productivos o productivos.
3.9.2 Emergency Data Set –EDS
Nombre Tipo de
datos Descripción
CrashDate datetime La fecha del choque
EdsVersion varchar La versión del mensaje EDS usada
Speed Float Velocidad registrada antes del choque
Bearing Float Dirección apuntada antes del choque
Latitude Float Latitud donde ocurrió el choque
Longitude Float Longitud donde ocurrió el choque
Accuracy Float Precisión obtenida en la ubicación del choque
Rollover Char True si se detectó un vuelco
AutomaticTrigger Char True si la activación no fue manual
AirbagDeployed Bit True si se detectó que el airbag fue activado
MessageType Nchar MSID (IMEI, IMSI o MSISDN)
VehicleType Nchar Tipo de Vehículo. Camión, Auto, Moto
Cargo Bit True si es un vehículo de carga
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 85
VehicleManufacturer Nchar Marca del vehículo
VehicleManufacturingYear Nchar Año de fabricación
LicensePlate varchar Número de patente del auto
VehicleColor Nchar Color del vehículo
VehicleModel Nchar Modelo del vehículo
ServiceProviderIp Nchar IP del proveedor del servicio que usa el dispositivo
inalámbrico
ServiceProviderCountryId Nchar Id del país del proveedor del servicio que usa el
dispositivo inalámbrico
NumberOfPassengers smallint Número de pasajeros al momento del choque
MobileNumber Nchar Número de teléfono desde el cual se envió el mensaje
UDS.
NetworkType varchar
Constante que indica la tecnología de radio (tipo de
red) en uso en el dispositivo para la transmisión de
datos.
DeviceSoftwareVersion Nchar El número de version de software para el dispositivo,
por ejemplo, el IMEI/SV para celulares GSM.
NetworkCountryIso nchar
El código ISO del país equivalente al MCC (Mobile
Country Code) del operador registrado en el
momento.
NetworkOperator varchar El nombre numerico (MCC+MNC) del operador
registrado en ese momento
NetworkOperatorName varchar El nombre alfabético del operador registrado en ese
momento
PhoneType nchar Constante que indica el tipo de celular (GSM, CDMA,
SIP)
SimContryIso nchar El código de país ISO equivalente para el código de
país del proveedor de la SIM
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 86
SimOperator nchar El MCC+MNC (mobile country code + mobile network
code) del proveedor de la SIM.
SimOperatorName varchar El nombre del proveedor del servicio o Service
Provider Name (SPN).
SimSerialNumber nchar Número de serie de la SIM (si aplica, es decir no es
CDMA por ejemplo)
SimState int
Estado de la SIM (por ejemplo, desconocido, ausente,
se requiere PIN, se requiere PUK, bloqueado por la
red, lista)
SubscriberId varchar El id único de suscripción, por ejemplo, el IMSI para un
dispositivo móvil GSM.
HasIccCard bit True si hay un tarjeta ICC [30] presente
IsNetworkRoaming bit
True si se considera que el dispositivo móvil usa
roaming para comunicarse al momento del choque.
Sólo está disponible cuando el usuario está registrado
en la red.
RetriesNumber int En cuántos reintentos se pudo enviar. 0 es el valor en
caso de que se haya enviado al primer intento.
isTest Bit True si es un test. Esto sirve para pruebas en
ambientes pre-productivos o productivos.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 87
C A P Í T U L O 4
4.1 Sensores en el celular
Actualmente, los teléfonos inteligentes o Smartphones, suelen venir con una cantidad de
sensores que va aumentando con cada nuevo modelo o versión. Ya es común encontrarse con
acelerómetros en la mayoría de los celulares, y poco a poco, están comenzando a encontrarse
giróscopos (para medir la velocidad angular), sensores de proximidad (para bloquear la
pantalla al hablar por teléfono, de manera de, por ejemplo, no se presionen botones con la
oreja sin querer), brújulas electrónicas, etc.
Android, a partir de la versión 2.3 (Gingerbread) fue un paso más allá e incluyó dos nuevos
sensores de fusión, estos permiten obtener la aceleración lineal sobre los 3 ejes y una matriz
de rotación. Usando todos los sensores de un celular con estas características, se podría llegar
a conocer exactamente cómo se está moviendo un celular o, mejor aún, saber cómo se movió
en el pasado. Una característica de este tipo, en un choque, podría significar tener un indicio
(si bien a grandes rasgos), de cómo ocurrió un accidente.
Cuáles son los sensores que nos provee Android:
Acelerómetro – Devuelve la aceleración en los 3 ejes, menos la gravedad en ese eje.
Los valores son devueltos en la unidad (m/s2). Si el celular se encuentra en caída libre,
los valores devueltos serán 0 para los 3 ejes.
Campo Magnético – Todos los valores son devueltos en la unidad micro-Tesla y se
mide el campo magnético en el ambiente en los 3 ejes.
Giróscopo – Devuelve la velocidad angular en cada uno de los 3 ejes. Todos los
valores devueltos están en la unidad radianes/segundo.
Sensor de Luz – Devuelve el nivel de luz en unidades Lux SI
Presión – Devuelve la presión atmosférica en hPa (milibar)
Proximidad – Devuelve la distancia medida en centímetros, aunque algunos sensores
sólo soportan un valor binaria como salida, un valor alto al estar lejos y un valor bajo
al estar cerca (un objeto del sensor).
Gravedad – Devuelve la dirección y magnitud de la gravedad. Todos los valores
devueltos están en la unidad m/s^2. Estando en reposo, los valores deberían ser los
mismos que el acelerómetro.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 88
Aceleración Lineal – Describe la aceleración lineal aplicada sobre el celular sin incluir
la gravedad. Si se ve el código fuente de Android, también se encuentra que aplica un
filtro paso bajo. Esto es para eliminar valores pequeños no deseados que no son
reales, sino que son producto de que el sensor está hecho electrónicamente. Todos los
valores devueltos están en la unidad m/s2.
La salida de los sensores Acelerómetro, Gravedad y Aceleración Lineal deben obedecer
la ecuación: aceleración = gravedad + aceleración lineal
Vector de Rotación – Representa la orientación del dispositivo como una
combinación de ángulo y eje, en el cual el celular ha girado a través de un ángulo θ
alrededor de un eje <x, y, z>.
Los tres elementos del vector de rotación son <x*sen(θ/2), y*sen(θ/2), z*sen(θ/2)>,
tal que la magnitud del vector de rotación es igual al sen(θ/2), y la dirección del vector
de rotación es igual a la dirección del eje de rotación.
Los tres elementos del eje de rotación son iguales a las tres últimas componentes de
una unidad cuaternión (quaternion en inglés) <cos(θ/2), x*sen(θ/2), y*sen(θ/2),
z*sen(θ/2)>.
Los elementos del vector de rotación no tienen unidades.
Orientación – Este sensor ya no debe usarse, sólo existe por compatibilidad hacia
atrás.
Humedad Relativa – Este sensor es de esperarse en futuros modelos, no estando
disponible todavía en los modelos comercializados actualmente.
Temperatura Ambiente - Este sensor es de esperarse en futuros modelos, no
estando disponible todavía en los modelos comercializados actualmente.
4.2 Sistema de coordenadas en Android
El sistema de coordenadas en Android está definido relativo a la pantalla del celular en su
orientación más común. Los ejes no son cambiados cuando se cambia la orientación de la
pantalla del celular.
El eje X es horizontal y apunta a la derecha, el eje Y es vertical y apunta arriba y el eje Z apunta
hacia el exterior de la cara frontal de la pantalla. En este sistema, las coordenadas detrás de la
pantalla tienen valores de Z negativos.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 89
Figura 29 - Sistema de coordenadas en Android [31]
4.3 Obtención de la fuerza G aplicada en el dispositivo móvil, en un choque
Un sistema que estará tomando los valores de los sensores con una velocidad de muestreo
alta, debe tener la capacidad de calcular el valor de la fuerza G con un costo bajo, de forma de
no crear un gasto innecesario de recursos que no dejen volver a calcular rápidamente la
fuerza G para el próximo conjunto de valores medidos.
Con los sensores previamente mencionados, hay varias maneras de obtener la fuerza G, entre
las cuales están:
Obteniendo la raíz cuadrada de la suma de los cuadrados de los valores del
acelerómetro.
Usando el sensor Aceleración Lineal
Un problema del sensor Aceleración Lineal es que es un sensor de fusión, esto es, no devuelve
los datos “en crudo”, tal como fueron obtenidos, sino que realiza algunos cálculos antes de
devolverlos, por lo cual se optó por usar el primer método, ya que el acelerómetro sí devuelve
los datos originales, tal cual son informados por el sensor embebido en el dispositivo móvil.
4.4 ¿Cómo saber si es un choque?
Es sabido que los distintos choques experimentan fuerzas G distintas, en particular, a
velocidades más altas se experimentan fuerzas G más fuertes. Es así que los airbags de los
automóviles están diseñados para ser disparados al detectarse una aceleración de al menos
60G.
La fuerza G es la fuerza de la gravedad (9.81m/seg2 aprox. en la tierra) y se dice que si sólo se
está bajo la influencia de la fuerza de la gravedad (por ejemplo si se está quieto, sin moverse)
se está bajo los efectos de 1G. Luego a medida que uno se mueve, esta fuerza va aumentando.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 90
Un factor fundamental que indica que hubo un choque es un cambio brusco en la aceleración
y/o desaceleración, durante un breve período de tiempo.
Así, podemos obtener (a grandes rasgos), la fuerza G aplicada en una frenada, mediante la
siguiente fórmula:
De la ecuación a = (vf2-vi2)/2*(xf-xi)
Podemos llegar a:
d = v 2/(2*c)
siendo:
d = Desaceleración producida
v = velocidad
c = la distancia de frenada recorrida
Se puede ver que la desaceleración producida es proporcional al cuadrado de la velocidad (v)
(es la diferencia de la velocidad, pero en este caso la final es 0) e inversamente proporcional al
doble de la distancia de frenada recorrida (c).
Por ejemplo:
Un automóvil de 750 kilogramos, que choca contra un obstáculo fijo a 50 km/h, o
lo que es igual a 13,9 m/seg., siendo la distancia de frenado 0,50 m, experimenta aplicando la
fórmula, la siguiente desaceleración:
d = (13,9 m/seg)2 / (2*0,50m) = 193 m2/seg2 / 1 m = 193 m/seg2
Si se divide el valor obtenido por la fuerza de la gravedad, se obtiene la fuerza G resultante:
(193 m/seg2) / (9.8 m/seg2) = 19,7G
Haciendo algunos cálculos, es posible elaborar la siguiente tabla
Desaceleración en un choque para una detención en un metro de distancia 120 km/h 56G 100 km/h 39G 50 km/h 10G
Tabla 1. Fuerzas G recibidas en un choque a distintas velocidades
Para obtener alguna idea de la relación entre las velocidades y la fuerza G experimentada
durante un choque, se puede ver la siguiente tabla:
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 91
Tabla 2. Umbrales de aceleración para detección de Accidentes [32]
De esta forma, si se encuentra una aceleración/desaceleración de hasta 4G se puede no tomar
acción alguna ya que no se debería estar en presencia de un accidente. Si la fuerza G es mayor
a 4, se puede asumir que hay posibilidad de un accidente, mientras que si es mayor a 20G, el
accidente podría ser serio y si es mayor a 40G, el accidente sería grave con posibilidad de
muerte.
Debido a que los distintos celulares están provistos con diferentes marcas de sensores,
algunos son más sensibles que otros, por lo que se recomienda que estos valores sean
calibrados según el celular, es decir que se deje la opción de configurar en una aplicación el
umbral a partir del cual se detectará un choque, siendo este umbral mayor a 4G para evitar la
mayor cantidad posible de falsos positivos.
Si se obligase al usuario a utilizar el celular en una posición determinada al conducir, podría
encontrarse un flujo similar al siguiente para intentar tomar conocimiento sobre el tipo de
choque en particular:
Figura 30. Algoritmo de detección de eCall [33]
Para que este algoritmo sea preciso, el sistema de coordenadas del celular debería ser siempre
el mismo. Sin embargo en un celular con Android si se rota la pantalla y se quiere saber la
magnitud de la fuerza G en un eje particular se deben hacer conversiones para volver al
sistema de referencia original.
Por ejemplo, si se tiene el celular en un bolsillo de la camisa (con la pantalla mirando al
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 92
cuerpo) y se toma que el eje Y es positivo hacia arriba, el eje X es positivo hacia la derecha y el
eje Z es positivo hacia el cuerpo, al detectarse una desaceleración fuerte, se podría decir que si
la mayor desaceleración se produjo sobre el eje Z, se pudo haber producido un choque, pero si
el celular se saca del bolsillo y se deja sobre la guantera, ya no alcanzaría con consultar la
magnitud de la fuerza G en el eje Z, sino que se debería calcular antes para dónde apunta el eje
Z o bien cómo está posicionado el celular para saber qué eje es el que se debe usar. Un
problema incluso mayor sería que un ocupante podría estar atendiendo una llamada con lo
cual, los ejes volverían a rotar. Sin embargo, sí es posible saber si se produjo un accidente o
no, puesto que no hace falta saber la dirección del choque, sino sólo la magnitud de la fuerza G
experimentada.
4.5 Evitar falsos positivos
Es muy importante para un usuario que no se detecten falsos positivos, es decir, por ejemplo,
que ante una frenada fuerte, una caída del celular en el piso del automóvil, pasar por un lomo
de burro rápido, etc., no se accione el mecanismo de alerta ante accidentes. Esto podría
hacerse mediante el uso también de las fuerza G aplicada. Por ejemplo, ante una detección de
la misma, menor al umbral configurado, simplemente podría no tomarse ninguna acción.
Otros mecanismos posibles (complementarios) serían hacer un seguimiento de la velocidad
del automóvil, lo cual podría hacerse fácilmente si el GPS estuviese activado ya que el
software suele permitir la lectura de la misma. Si el GPS estuviese desactivado, la lectura de la
velocidad sería más complicada debido a que habría que hacerlo con los datos del
acelerómetro y se deben tener en cuenta más posibilidades, por ejemplo, si se detecta que se
está detenido con el automóvil y hay una aceleración de unos pocos G seguida de unos
segundos de inactividad, podría ser simplemente que el celular se cayó al piso del automóvil y
no que se produjo un choque. Sería importante detectar un tiempo de inactividad luego de la
caída ya que un choque podría ser provocado por un tercero mientras el vehículo se
encuentra detenido, en cuyo caso no se detectaría dicho período de inactividad, al menos no
de la misma forma que si el celular se cayese al piso del automóvil.
De acuerdo con lo visto hasta el momento, debería ser posible para el usuario decidir si quiere
que se detecten los accidentes que no son tan graves (aumentando la posibilidad de falsos
positivos que deben ser cancelados) o sólo que se detecten accidentes en los cuales la
posibilidad de heridas medias a graves, tenga un porcentaje más elevado, mientras que los
falsos positivos sean una remota posibilidad.
También, podría modificarse el valor del umbral de acuerdo con el medio de transporte
utilizado, por ejemplo, se podría dejar configurar si se viaja en bicicleta. De esta forma, el
umbral será inferior que si se trata de un automóvil.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 93
4.6 Programa para probar los sensores
A fin de poder relevar algunos valores tipo de las fuerzas G aplicadas de forma práctica, se
creó un programa en el celular que permite elegir ciertas situaciones y guardar información
de los sensores ante dichas situaciones, por ejemplo: Pasar por un lomo de burro rápido,
caminar, correr, frenar, doblar, etc.
A continuación, se puede ver una captura de pantalla de la misma
Figura 31. Programa para probar la fuerza G aplicada
En ningún caso se detectó una fuerza G mayor a 4G. Este podría ser un valor umbral de
detección de choque para este celular.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 94
Algunos gráficos de la fuerza G en las pruebas realizadas
Figura 32. Fuerza G registrada por un celular al pasar por lomos de burro con un automóvil
Figura 33. Fuerza G registrada por un celular al correr con el mismo en el bolsillo del pantalón
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 95
4.7 Velocidad de la toma de muestras
Android permite seleccionar una de entre cuatro velocidades de muestreo, aproximadamente:
FASTEST : 100 Hz
GAME : 50 Hz
NORMAL : 5 Hz
UI : 16 Hz
Estos valores dependen de cada celular.
Es importante no usar siempre la tasa de muestreo más rápida ya que esto influirá
directamente en la batería del dispositivo. Se debe elegir la menor frecuencia necesaria que
permita un correcto funcionamiento de la aplicación.
En ese caso, si se produce un choque a alta velocidad, se necesitará un muestreo muy alto
porque la desaceleración se dará en un muy breve lapso de tiempo. Es por ello que se elige la
tasa de muestro mayor, de 100 Hz (100 muestras por segundo) para poder detectar los
choques y poder luego intentar reproducirlo sobre la base de datos almacenados.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 96
C A P Í T U L O 5
5.1 Diagrama de despliegue
Figura 32. Diagrama de despliegue
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 97
5.2 Explicación general del funcionamiento del sistema
Se podría dividir la arquitectura en 3 secciones, la primera, el software que está en el celular y
la obtención de la posición por parte de este, la segunda, el motor que procesa todos los
incidentes y tiene la información necesaria para saber a dónde conviene mandar los heridos y
qué tipo de ayuda conviene enviar y como tercera y última sección, la obtención por parte de
los usuarios comunes y las entidades de emergencias de la información acerca de las
emergencias.
Sección 1 – Obtención de la Posición/Celular
El celular tiene corriendo un programa que detecta cambios bruscos en la velocidad y
movimiento del celular, basado en el cambio y cantidad de fuerza G, los cuales se pueden
obtener a partir de las medidas detectadas por el acelerómetro embebido dentro del celular.
De esta manera, si el celular está en un bolsillo y se cae, o el celular está fijo en un holder y hay
una frenada brusca pero no un choque, no se emite un alerta; sin embargo, si en cambio la
fuerza G es mayor a 4G, entonces en ese caso, sí se emite un alerta de emergencia, con las
siguientes acciones:
1. Se comienza una conexión a un Web Service seguro, la cual transferirá la información de urgencia más necesaria (UDS) recolectada por el celular, como ser posición, velocidad al momento del choque, etc.
2. El servidor envía un email automáticamente a las distintas entidades de emergencia cargadas en la base de datos.
3. Luego que se confirma que el UDS se recibió, se comienza la transmisión del siguiente mensaje (EDS), el cual contiene más datos y es el que potencialmente cambiaría a futuro, de ser necesario, para agregar información, por ejemplo, una foto o una grabación de voz de unos segundos.
4. Se recolectan todos los datos de los sensores, se crea un archivo .zip y se envía al servidor para posterior análisis.
5. Opcionalmente, luego de la llamada se generará algún tipo sonido fuerte para que la ubicación pueda ser establecida más fácilmente cuando el personal se encuentre en el lugar del accidente. (Esto va a depender de cuán rápido se agote la batería del celular)
El celular obtendrá la posición por medio del receptor A-GPS incorporado y/o la red celular
y/o wifi.
Sección 2 - Servidor de incidentes, motor y persistencia
El servidor de incidentes recibirá todos los incidentes y los procesará, de ser posible, teniendo
en cuenta la información de hospitales (camas disponibles, cercanía, etc.), policía (cercanía),
bomberos (cercanía) y enviará la información personalizada al tipo de accidente ocurrido.
Tanto si es posible como si no lo es, se comunicará al 911 y/o cualquier otro servicio de
emergencias sobre el accidente ocurrido.
Actualmente, los hospitales públicos no están informatizados y sólo algunos privados lo están,
como es el caso del Hospital Italiano, el cual tiene las historias clínicas de los pacientes de
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 98
forma digital y hasta las radiografías están informatizadas, las cuales pueden ser vistas a
través del sistema, de manera inmediata.
Luego de haber analizado la información, si se pudiese haber recabado más, ésta será
almacenada en una base de datos.
La base de datos elegida es: SQL Server 2008 Express
Lenguaje de programación del motor: C#
Sección 3 – Intranet entre hospitales, policía y bomberos
Esta sección se encarga de la definición de la intranet que permitirá a los distintos servicios de
emergencias ver las alertas para poder proceder de la manera más rápida y eficiente posible
para la asistencia a los posibles heridos. En principio, habría 2 tipos de usuarios, el común,
hogareño que sólo podrá acceder a cierta parte de la información, o sea, tendrá un acceso
restringido a la aplicación. Por otro lado, estarán las entidades de emergencia que podrán
acceder a mucha más información.
De esta manera, es posible que estén interconectados los principales servicios de emergencia,
de manera de atender rápida y efectivamente, las emergencias.
Se expondrán, en principio, mediante web services los estados de los incidentes y los servicios
de emergencias. Como se dijo anteriormente, cierta información podrá ser consumida por el
público general y otra estará restringida.
5.3 Servicios Web accedidos desde un celular
Los Web Services o Servicios Web son puntos de entrada a distintos servicios. Estos pueden
ser accedidos desde distintos medios: una computadora, una Tablet, un celular, etc. En el caso
de un celular, al tener una capacidad de recursos inferior a una PC (aunque actualmente cada
vez se le acerca más), resulta necesario que el protocolo demande la menor cantidad de
procesamiento posible, así como que los datos que usa la comunicación sean la menor
cantidad posible. En este sentido, los Web Services REST son la mejor respuesta. No sólo
tienen un overhead menor que los servicios SOAP10 sino que además, a través de una URL se
permite estar realizando el pedido de búsqueda de un ítem en particular. Por ejemplo, una
URL como www.unaurl.com/articulos/5 podría estar devolviendo los datos del artículo 5,
sin necesidad de enviar ningún otro dato ni hacer ninguna otra consulta.
Si bien actualmente la prueba de concepto, no consume información externa, sería interesante
que en el futuro lo hiciera, para informar al usuario sobre ciertos eventos informativos.
Por estas razones, se eligió para la comunicación del celular con el servidor central usar Web
Services REST.
5.4 Tecnologías de comunicación inalámbricas
Actualmente, los celulares suelen tener 3 formas de comunicación inalámbrica: Bluetooth,
Wifi y la Red Celular (algunos tienen puerto infrarrojo, pero ya no es muy usado). Dentro de
las redes celulares podemos encontrar varias tecnologías, a saber:
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 99
GPRS - General Packet Radio Service
Es una extensión del Sistema Global para Comunicaciones Móviles (Global System for
Mobile Communications o GSM) para la transmisión de datos no conmutada (o por
paquetes). Permite velocidades de transferencia de 56 a 144 kbps [34].
Una conexión GPRS está establecida mediante un punto de acceso (APN). Con GPRS se
pueden utilizar servicios como Wireless Application Protocol (WAP), servicio de
mensajes cortos (SMS), servicio de mensajería multimedia (MMS), Internet y para los
servicios de comunicación, como el correo electrónico y World Wide Web (WWW).
Para fijar una conexión de GPRS para un módem inalámbrico, un usuario debe
especificar un APN, opcionalmente un nombre y contraseña de usuario, y muy
raramente una dirección IP, todo proporcionado por el operador de red.
EDGE - Enhanced Data Rates GSM of Evolution
Proporciona tasas mejoradas de datos para la evolución de GSM. También, conocida
como EGPRS (Enhanced GPRS).
Esta es una tecnología de la telefonía móvil celular, que actúa como puente entre las
redes 2G y 3G.
EDGE se considera una evolución del GPRS (General Packet Radio Service). Esta
tecnología funciona con redes GSM. Aunque EDGE funciona con cualquier GSM que
tenga implementado GPRS, el operador debe implementar las actualizaciones
necesarias, además no todos los teléfonos móviles soportan esta tecnología.
EDGE, o EGPRS, puede ser usado en cualquier transferencia de datos basada
en conmutación por paquetes, como lo es la conexión a Internet. [35]
UMTS - Universal Mobile Telecommunications System
Es una de las tecnologías usadas por los móviles de tercera generación, sucesora
de GSM.
Sus tres grandes características son las capacidades multimedia, una velocidad de
acceso a Internet elevada, la cual también le permite transmitir audio y video en
tiempo real; y una transmisión de voz con calidad equiparable a la de las redes fijas.
Además, dispone de una variedad de servicios muy extensa.
La principal ventaja de UMTS sobre la segunda generación móvil (2G), es la capacidad
de soportar altas velocidades de transmisión de datos de hasta 144 kbit/s sobre
vehículos a gran velocidad, 384 kbit/s en espacios abiertos de extrarradios y 7.2
Mbit/s con baja movilidad (interior de edificios). Esta capacidad sumada al soporte
inherente del protocolo de Internet (IP), se combinan poderosamente para prestar
servicios multimedia interactivos y nuevas aplicaciones de banda ancha, tales como
servicios de video conferencia y transmisión de audio y video en tiempo real. [36]
HDSPA -High Speed Downlink Packet Access
Es la optimización de la tecnología espectral UMTS/WCDMA, incluida en las
especificaciones de 3GPP release 5 y consiste en un nuevo canal compartido en el
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 100
enlace descendente (downlink) que mejora significativamente la capacidad máxima de
transferencia de información pudiéndose alcanzar tasas de bajada de
hasta 14 Mbps (1,8, 3,6, 7,2 y 14,4 Mbps).
Soporta tasas de throughput promedio cercanas a 1 Mbps.
Actualmente, también está disponible la tecnología HSUPA, con velocidades de subida
de hasta 5,8 Mbps, y HSPA+ con velocidades de hasta 84 Mbps de bajada y 22 Mbps en
la subida. [37]
LTE - Long Term Evolution
Es un nuevo estándar de la norma 3GPP. Para algunos es la evolución de la norma
3GPP UMTS (3G), para otros un nuevo concepto de arquitectura evolutiva (4G). De
hecho LTE será seguramente la clave para el despegue del internet móvil. Servicios
como la transmisión de datos a más de 300 metros y videos de alta definición, gracias
a la tecnología OFDMA (Orthogonal Frecuency Division Multiple Access), serán de uso
corriente en la fase madura del sistema.
Lo novedoso de LTE es la interfaz radioeléctrica basada en OFDMA para el enlace
descendente (DL, Download Link) y SC-FDMA para el enlace ascendente (UL, Upload
Link). La modulación elegida por el estándar 3GPP hace que las diferentes tecnologías
de antenas (MIMO) tengan una mayor facilidad de implementación; esto favorece,
según el medio, hasta cuatro veces la eficacia de transmisión de datos. [38]
Buenos Aires fue una de las pocas ciudades en el mundo donde ya se está probando la
tecnología LTE [38]. Esta nueva tecnología permitirá alcanzar velocidades máximas de
más de 300 Mbps. Todavía está en fase de prueba pero se piensa que en el próximo
año ya empezará a estar disponible.
Comparación de las velocidades entre las distintas tecnologías de comunicación celular
Figura 35. Comparación entre las velocidades de las distintas tecnologías celulares como ejemplo en Rumania [39]
]
Podemos ver que LTE tiene una velocidad muy superior a GPRS, EDGE, e incluso UMTS y
HSPA, por eso será el próximo salto evolutivo en la comunicación y uso de internet celular.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 101
Las siguientes tasas de datos no están garantizadas de acuerdo a las redes, son velocidades
teóricas.
Max velocidad de bajada
(kbit/s)
Max velocidad de subida
(kbit/s)
GPRS 80 40
EDGE 236 118
3G 384 128
3G+ (HSDPA -
HSUPA) 14400 5760
HSPA+ 42000 11520
LTE 320000 170000
Tabla 1. Velocidades de subida y bajada [35][36][37][38]
En Argentina se pueden encontrar las siguientes bandas:
GSM 850, GSM 900, GSM 1800, UMTS 850, UMTS 1900
Figura 36. Uso de frecuencias GSM a nivel mundial [40]
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 102
Wifi: Es una conexión rápida (comparada con GPRS o EDGE por ejemplo), que en el caso de la
norma 802.11g llega a una velocidad máxima de 54Mbps a 2.4Ghz y la norma 802.11n permite
una velocidad máxima de 300Mbps a 5Ghz). Una desventaja de Wifi con respecto a la red
celular es que necesita un elemento cercano, como un router para comunicarse, además que al
existir hoy en día tantos puntos de acceso wifi hay mucha interferencia, lo cual le quita calidad
a la conexión.
La red celular, por otro lado, actúa mediante torres que tienen antenas celulares. Las
velocidades de conexión son muy inferiores, pero permiten que si uno está en una ruta, en
muchos casos se tenga conexión, situación que no se produciría con Wifi.
5.5 Web Services - Introducción
El consorcio W3C define los Servicios Web como sistemas software, diseñados para soportar
una interacción interoperable, máquina a máquina, sobre una red. Los Servicios Web suelen
ser APIs Web que pueden ser accedidas dentro de una red (principalmente Internet) y son
ejecutados en el sistema que los aloja.
La definición de Servicios Web propuesta alberga muchos tipos diferentes de sistemas, pero el
caso común de uso se refiere a clientes y servidores que se comunican mediante mensajes
XML, sujetos al estándar SOAP.
Los Web Services son neutrales en cuanto a la tecnología, y son independientes en cuanto al
hardware, sistema operativo y lenguaje de programación.
Permiten la utilización de servicios que pueden conectar aplicaciones hechas en distintas
ubicaciones, distinto hardware, computadoras, sistemas operativos, lenguajes de
programación, etc.
[41] En los últimos años, se ha popularizado un estilo de arquitectura software conocido como
REST (Representational State Transfer). Este nuevo estilo ha supuesto una nueva opción de
uso de los Servicios Web. A continuación, se listan los tres estilos de usos más comunes:
Remote Procedure Calls (RPC, Llamadas a Procedimientos Remotos) Los Servicios Web basados en RPC presentan una interfaz de llamada a procedimientos y funciones distribuidas, lo cual es familiar a muchos desarrolladores. Típicamente, la unidad básica de este tipo de servicios es la operación WSDL (WSDL es un descriptor del Servicio Web). Las primeras herramientas para Servicios Web estaban centradas en esta visión. Esta es la razón por la que este estilo está muy extendido. Sin embargo, ha sido algunas veces criticado por no ser débilmente acoplado, ya que suele ser implementado por medio del mapeo de servicios directamente a funciones específicas del lenguaje o llamadas a métodos. Muchos especialistas creen que este estilo debe desaparecer.
Arquitectura Orientada a Servicios (Service-oriented Architecture o SOA) Los Servicios Web pueden también ser implementados siguiendo los conceptos de la arquitectura SOA, donde la unidad básica de comunicación es
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 103
el mensaje, más que la operación. Esto es típicamente referenciado como servicios orientados a mensajes. Los Servicios Web basados en SOA son soportados por la mayor parte de desarrolladores de software y analistas. Al contrario que los Servicios Web basados en RPC, este estilo es débilmente acoplado, lo cual es preferible ya que se centra en el “contrato” proporcionado por el documento WSDL, más que en los detalles de implementación subyacentes.
REST (REpresentation State Transfer)
Los Servicios Web basados en REST intentan emular al protocolo HTTP o
protocolos similares mediante la restricción de establecer la interfaz a un
conjunto conocido de operaciones estándar (GET, PUT, POST y DELETE). De
REST se hablará más a continuación.
5.6 Comunicación desde el celular al servidor. ¿Web Services basados en SOAP o en
REST?
Dos de las formas de Web Services más usadas actualmente son SOAP y REST [42]. A
continuación se hará una breve introducción a ambas.
5.6.1 SOAP - Simple Object Access Protocol
Usa XML para la interoperabilidad de los Web Services.
Debido a que está basado en texto y es autodescriptivo, los mensajes SOAP pueden transmitir
información entre servicios en entornos de computación diferentes sin haber problemas de
conversión. Hay varias especificaciones de Web Services. Dos de ellas, basadas en XML, son
WSDL (Web Service Descripción Language) y UDDI (Universal Descripción Discovery and
Integration. WSDL define un método estándar de describir el Web Service y lo que puede
hacer, y UDDI define reglas basadas en XML para publicar información del Web Service. Los
mensajes son intercambiados a través del protocolo SOAP. SOAP funciona intercambiando
información usando GET/POST sobre HTTP. Esto permite intercambiar los datos sin importar
dónde estén los clientes en la red.
Sin embargo, el uso de estos en dispositivos móviles no es lo mejor ya que se incurre en
performance overheads debido a los recursos que se necesitan para codificar y decodificar los
mensajes SOAP. Además, hay una performance muy distinta (todavía) entre comunicaciones
inalámbricas y las que son mediante cable. Tampoco ayudan algunas variables asociadas con
los celulares como velocidad del procesador, vida de la batería limitada y conexión a internet
lenta y no muy confiable. [42]
5.6.2 REST – Representational State Transfer
Comparten muchas características con otros estilos de Web Services como RPC (Remote
Procedure Call) y Web Services basados en documentos que usen SOAP como protocolo, pero
también difieren en formas importantes.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 104
RPC y los Web Services basados en documentos como los Web Services REST, están diseñados
para ser livianos, accesibles vía URIs (explicado más adelante), y típicamente usan HTTP como
protocolo. Tanto los Web Services REST como SOAP son independientes en cuanto a la
plataforma y los lenguajes de programación usados y en ambas arquitecturas, clientes y
servidores están débilmente acoplados. Por esto, los clientes y los servidores pueden
interactuar sin hacer suposiciones unos respecto de los otros.
Los Web Services apuntan a ser simples, y lo logran limitando el tipo de operaciones que se
pueden hacer sobre un recurso. Los fundadores dicen que REST:
Provee un tiempo mejorado de respuesta y carga en el servidor debido al soporte de
caching.
Mejora la escalabilidad del servidor debido a que no se necesita mantener el estado de
la comunicación.
Requiere menos software del lado del cliente que otras formas ya que un browser sólo
puede acceder a cualquier aplicación y cualquier recurso.
Depende menos del proveedor del software que otros mecanismos que usan una capa
adicional de un framework de mensajería sobre HTTP.
Provee funcionalidad equivalente cuando se compara con otras alternativas de
comunicación.
No necesita un mecanismo de recursos de descubrimiento separado pues utiliza
hyperlinks en el contenido.
Provee una mejor compatibilidad a largo plazo y mejor capacidad de evolución que
RPC, debido a la capacidad de evolución de tipos de documentos como HTML, sin
eliminar la compatibilidad hacia atrás o adelante y la habilidad de los recursos de
agregar soporte para nuevos tipos de contenido ya que están definidos sin perder o
reducir soporte para tipos de contenido anteriores (MIME types)
5.7 ¿Qué son los URIs? [43]
Un Identificador de Recursos Uniforme (URI) es una cadena de caracteres corta que identifica
un recurso abstracto o físico (por ejemplo, servicio, página web, documento, dirección de
correo electrónico, enciclopedia, etc.). Un Localizador de Recursos Uniforme (URL) es un tipo
de URI que identifica un recurso por su mecanismo de acceso primario (por ejemplo, su
ubicación).
Los URIs son la forma estándar de nombrar los destinos de los hyperlinks para herramientas
tales como los navegadores web. Por ejemplo "http://www.google.com" es un URL (y
también un URI). Si bien hay muchas personas que llaman indistintamente a un URL y a un
URI, la realidad es que un URL es parte de un URI).
Los URIs se pueden clasificar como localizadores (URLs), como nombres (URNs), o ambos. Un
Nombre de Recurso Uniforme o Uniform Resource Name (URN) en inglés funciona como el
nombre de una persona, mientras que el Localizador de Recursos Uniforme (URL) se asemeja
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 105
a la dirección de la persona. Es decir, el URN define la identidad del ítem, mientras que el URL
provee un método para hallarlo.
5.8 ¿Cuáles son los principios de REST?
Una implementación concreta de un servicio web REST sigue cuatro principios de diseño
fundamentales [41]
Utiliza los métodos HTTP de manera explícita No mantiene estado Expone URIs con forma de directorios Transfiere XML, JavaScript Object Notation (JSON), o ambos
El no mantener estado mejora el rendimiento de los servicios web y simplifica el diseño e
implementación de los componentes del servidor, ya que la ausencia de estado en el servidor
elimina la necesidad de sincronizar los datos de la sesión con una aplicación externa.
5.9 ¿Cómo se manejan los recursos?
El acceso se puede lograr de muchas maneras, recibiendo una representación del recurso
(GET o HEAD), añadiendo o modificando una representación (POST o PUT) y eliminando
algunas o todas las representaciones (DELETE).
HTTP OPERACION CRUD Descripción
POST CREATE Crear un nuevo recurso
GET RETRIEVE Obtener la representación de un recurso
PUT UPDATE Actualizar un recurso
DELETE DELETE Eliminar un recurso
Tabla 2. Operaciones REST
5.10 Servicios con estado vs. sin estado [44]
La siguiente figura nos muestra un servicio con estado, en la cual una aplicación realiza
peticiones para la página siguiente en un conjunto de resultados paginados, asumiendo que el
servicio mantiene información sobre la última página que pidió el cliente. En un diseño con
estado, el servicio incrementa y almacena en algún lugar, una variable paginaAnterior para
poder responder a las peticiones siguientes.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 106
Figura 37. Servicio con estado
Los servicios con estado tienden a volverse complicados. En la plataforma Java Enterprise
Edition (Java EE), un entorno de servicios con estado necesita bastante análisis y diseño desde
el inicio para poder almacenar los datos eficientemente y poder sincronizar la sesión del
cliente dentro de un cluster de servidores o web farms. Además, la sincronización de sesiones
es costosa en procesamiento, lo que impacta negativamente en el rendimiento general del
servidor.
Por otro lado, los servicios sin estado son mucho más simples de diseñar, escribir y distribuir
a través de múltiples servidores. Un servicio sin estado no sólo funciona mejor, sino que
además mueve la responsabilidad de mantener el estado de la aplicación al cliente. En un
servicio web REST, el servidor es responsable de generar las respuestas y proveer una
interfaz que le permita al cliente mantener el estado de la aplicación por su cuenta. Se puede
ver en el ejemplo de la figura 37 una petición de datos de páginas, allí el cliente debería incluir
el número de página a recuperar en vez de pedir "la siguiente", tal como sí pasa y se muestra
en la siguiente figura:
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 107
Figura 38. Servicio sin estado
Un servicio web sin estado genera una respuesta que se enlaza a la siguiente página del
conjunto y le permite al cliente hacer todo lo que necesita para almacenar la página actual.
El estilo de arquitectura subyacente a la Web es el modelo REST. Los objetivos de este estilo
de arquitectura se listan a continuación:
• Escalabilidad de la interacción con los componentes. La Web ha crecido exponencialmente sin degradar su rendimiento. Una prueba de ellos es la variedad de clientes que pueden acceder a través de la Web: estaciones de trabajo, sistemas industriales, dispositivos móviles,…
• Generalidad de interfaces.
Gracias al protocolo HTTP, cualquier cliente puede interactuar con cualquier servidor HTTP sin ninguna configuración especial. Esto no es del todo cierto para otras alternativas, como SOAP para los Servicios Web.
• Puesta en funcionamiento independiente.
Este hecho es una realidad que debe tratarse cuando se trabaja en Internet. Los clientes y servidores pueden ser puestos en funcionamiento durante años. Por tanto, los servidores antiguos deben ser capaces de entenderse con clientes actuales y viceversa. Diseñar un protocolo que permita este tipo de características resulta muy complicado. HTTP permite la extensibilidad mediante el uso de las cabeceras, con las URIs, a través de la habilidad para crear nuevos métodos y tipos de contenido.
• Compatibilidad con componentes intermedios.
Los más populares intermediaros son varios tipos de proxys para Web. Algunos de ellos, las caches, se utilizan para mejorar el rendimiento. Otros permiten reforzar las políticas de seguridad: firewalls. Y por último, otro tipo importante de intermediarios, gateways,
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 108
permiten encapsular sistemas no propiamente Web. Por tanto, la compatibilidad con intermediarios nos permite reducir la latencia de interacción, reforzar la seguridad y encapsular otros sistemas.
REST logra satisfacer estos objetivos aplicando cuatro restricciones:
• Identificación de recursos y manipulación de ellos a través de representaciones. Esto se consigue mediante el uso de URIs. HTTP es un protocolo centrado en URIs. Los recursos son los objetos lógicos a los que se le envían mensajes. Los recursos no pueden ser directamente accedidos o modificados. Más bien, se trabaja con representaciones de ellos. Cuando se utiliza un método PUT para enviar información, se usa como una representación de lo que nos gustaría que el estado del recurso fuera. Internamente el estado del recurso puede ser cualquier cosa desde una base de datos relacional a un fichero de texto.
• Mensajes autodescriptivos.
REST dicta que los mensajes HTTP deberían ser tan descriptivos como sea posible. Esto hace posible que los intermediarios interpreten los mensajes y ejecuten servicios en nombre del usuario. Uno de los modos en que HTTP logra esto es por medio del uso de varios métodos estándares, muchos encabezamientos y un mecanismo de direccionamiento. Por ejemplo, las cachés Web saben que por defecto el comando GET es cacheable (ya que es side-effect-free) en cambio POST no lo es. Además saben cómo consultar las cabeceras para controlar la caducidad de la información. HTTP es un protocolo sin estado y cuando se utiliza adecuadamente, es posible interpretar cada mensaje sin ningún conocimiento de los mensajes precedentes. Por ejemplo, en vez de loguearse del modo en que lo hace el protocolo FTP, HTTP envía esta información en cada mensaje.
• Hipermedia como un mecanismo del estado de la aplicación. El estado actual de una aplicación Web debería ser capturado en uno o más documentos de hipertexto, residiendo tanto en el cliente como en el servidor. El servidor conoce el estado de sus recursos, aunque no intenta seguirle la pista a las sesiones individuales de los clientes. Esta es la misión del navegador que sabe cómo navegar de recurso a recurso, recogiendo información que necesita o modificando estados, en caso necesario.
En la actualidad existen millones de aplicaciones Web que implícitamente heredan estas
restricciones de HTTP. Hay una disciplina detrás del diseño de sitios Web escalables que
puede ser aprendida de los documentos de arquitectura Web o de varios estándares. Por otra
parte, también es verdad que muchos sitios Web comprometen uno más de estos principios,
como por ejemplo, seguir la pista de los usuarios moviéndose a través de un sitio. Esto es
posible dentro de la infraestructura de la Web, pero daña la escalabilidad, volviendo un medio
sin conexión en todo lo contrario.
Los defensores de REST han creído que estas ideas son tan aplicables a los problemas de
integración de aplicaciones como los problemas de integración de hipertexto. REST no es la
cura para todo. Algunas de estas características de diseño no serán apropiadas para otras
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 109
aplicaciones.
Cabe destacar que REST no es un estándar, es solamente un estilo de arquitectura y está
basado en estándares:
• HTTP • URL • Representación de los recursos: XML/HTML/GIF/JPEG/… • Tipos MIME: text/xml, text/HTML.
El concepto central de la Web es un espacio de URIs unificado. Las URIs posibilitan la densa
red de enlaces que permiten que la Web sea tan utilizada. Por tanto, ellos consiguen tejer una
mega-aplicación.
Las URIs identifican recursos, los cuales son objetos conceptuales. La representación de tales
objetos se distribuye por medio de mensajes a través de la Web. Este sistema es
extremadamente desacoplado.
Aquí podemos ver una comparación de tiempos entre el proceso con SOAP y con REST
Figura 39. Tiempo de respuesta del servicio (milisegundos) y tamaño del mensaje (bytes) del servicio de concatenación strings y
el servicio de adición de números flotantes [42]
Por todo esto, para la comunicación entre el celular y el servidor se eligió el uso de Web
Services basados en REST.
Entre los motivos se encuentran:
REST tiene menos overhead que SOAP Se puede usar fácilmente con WCF (.NET) Es extensible Es más simple para procesar por un celular No se necesita que el servidor guarde información de sesión
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 110
5.11 Flujo de manejo de mensajes UDS
Figura 40. Flujo de manejo de mensajes UDS
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 111
5.12 Diagrama de secuencia del manejo de los mensajes UDS
Figura 41.1. Diagrama de secuencia del manejo de los mensajes UDS
Figura 41.2. Diagrama de secuencia del manejo de los mensajes UDS
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 112
5.13 Diagrama de Secuencia del Celular hasta que se detecta un choque
Figura 42. Diagrama de Secuencia del Celular hasta que se detecta un choque
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 113
5.14 Diagrama de Secuencia del Celular luego de detectarse un choque
Figura 43. Diagrama de secuencia del celular luego de detectarse un choque
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 114
5.15 Detalle del Diagrama de Despliegue
Figura 44. Detalle del diagrama de despliegue
Explicación del diagrama
Al detectar un choque, la aplicación en el celular se conecta con el servidor mediante Web
Services basados en REST, luego estos Web Services se encargan de persistir la información
recibida en la base de datos central. Luego, un servicio de Windows consumirá la información
de la base de datos, cada X segundos. Mediante la técnica de Comet, el servidor envía
mediante “push”, los datos de los accidentes a los distintos usuarios en las centrales y luego
mediante los Web Services desarrollados con WCF (Windows Communication Foundation), se
podrán consumir los distintos datos almacenados en el sistema de acuerdo al perfil de cada
usuario.
5.16 Job de SQL Server
Tan pronto como llega un mensaje UDS al Web Service asociado, se guarda la información en
una base de datos de SQL Server 2008. Luego, un SQL Job se encarga de leer registros
ingresados en la tabla y enviarlos vía email a las distintas partes interesadas, por ejemplo
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 115
entidades de emergencia. Se decidió no enviar un email desde un trigger ni que se llame a un
Web Service que lo haga, ya que se busca la menor sobrecarga posible sobre la tabla en el
servidor de base de datos.
Además, dejar que el servidor de base de datos haga una llamada al exterior genera riesgos de
seguridad como así también para usar WCF se deben habilitar librerías que introducen
problemas de estabilidad. Esto es debido a que para que SQL Server pueda acceder a recursos
externos se debe setear la propiedad TRUSTWORTHY de la base de datos en ON. De esta
forma se le dice a SQL Server “que uno sabe lo que está haciendo” y que el código en los
assemblies con acceso externo o no seguro, es seguro para la instancia de SQL Server y bases
de datos en esa instancia. Entonces hay un potencial riesgo de que esos assemblies generen
problemas de seguridad y/o estabilidad.
Por qué no se usó el Microsoft SQL Server Agent
No se usó el SQL Agent debido a que SQL Server Express 2008 no provee una versión gratuita
(está de hecho, pero no se puede usar a menos que se compre una licencia), por eso se optó
por un software similar open source.
Se usó finalmente SQLScheduler que provee funcionalidad similar al Sql Agent y es gratuito.
[45]
5.17 Limitantes al usar un celular
Al usar un celular para la detección de un choque hay muchos factores de suma importancia,
entre los que se encuentran:
Batería limitada Velocidad de conexión limitada Velocidad de muestreo del GPS Velocidad de muestreo del acelerómetro.
5.18 Cada cuánto obtener las coordenadas del celular
Una variable a tener en cuenta es el intervalo entre dos obtenciones de la posición del celular.
El proveedor GPS en Android nos da la posibilidad de pedir una nueva lectura de las
coordenadas imponiendo restricciones, por ejemplo, que cada cierta distancia que se movió
y/o cada cierto tiempo se provea una lectura nueva.
Una posibilidad es hacer una relación entre la velocidad del auto y la velocidad de refresco,
entonces si va muy rápido, tomarlas rápido; si va lento, tomarlas algo más lentamente. Menos
de 10 metros no tendría sentido ya que se estaría pidiendo continuamente nuevas lecturas y
si se reporta el accidente con 10 metros de error igualmente se encontrará el celular que
emitió el alerta.
Se deben tomar coordenadas y el CPU tiene que realizar cálculos por más que la pantalla se
apague, es por esto, que se deben usar Wake Locks. El Wake Lock es un concepto de Android
que permite a una aplicación pedir que la pantalla y/o procesador no se apaguen durante un
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 116
tiempo. Permite tener control sobre el estado de energía del dispositivo.
Un ejemplo que se puede encontrar en el sitio de Android:
(http://developer.android.com/reference/android/os/PowerManager.html)
PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE); PowerManager.WakeLock wl = pm.newWakeLock(PowerManager.SCREEN_DIM_WAKE_LOCK, "My Tag"); wl.acquire(); ..screen will stay on during this section.. wl.release();
Luego de enviar toda la información necesaria se libera el Wake Lock.
En el capítulo 2 ya se mostró cómo hace Android para obtener la posición del celular y elegir
entre usar GPS, Wifi o las redes celulares para saber dónde está de acuerdo a la precisión que
se desea obtener, la energía que se desea gastar, etc.
Aquí se pueden ver algunos datos que sirven de referencia [46]
GPS: 25 seconds (1 GPS fix) * 140 mAh = 1mAh Network: 2 seconds (1 GPS fix) * 180mA = 0.1mAh
Teniendo en cuenta estos valores y si se pudiese saber si el celular está en una ciudad o no, se
podría usar un GPS en la ciudad y celdas celulares en las afueras a fin de gastar la menor
cantidad de batería posible.
Android usa A-GPS (cuando puede). Esto produce que el almanac se traiga más rápido
consumiendo menos energía (porque sino el GPS debería estar mucho tiempo encendido
hasta que lo trae). Esto implica que se gaste más dinero si no se tiene un plan que lo incluya.
Actualmente hay una opción de Google Maps Labs que permite descargar los mapas offline
para luego poder usar el celular en la calle sin tener que estar descargándolos y consumiendo
bytes de nuestro plan de datos. Si no se activa esta funcionalidad, se descargarán las imágenes
del mapa que están alrededor de la posición actual.
Frecuencia de muestreo del acelerómetro
En el capítulo 4 se vieron las distintas posibilidades que brinda Android para tomar datos de
los sensores. En este caso, se pondrá en perspectiva los gastos de energía que supone cada
uno de estos modos:
1. SensorManager.SENSOR_DELAY_FASTEST : El más rápido (90mA) 2. SensorManager.SENSOR_DELAY_GAME : Adecuado para juegos (80mA) 3. SensorManager.SENSOR_DELAY_NORMAL : Para detectar la orientación por
ejemplo (10mA) 4. SensorManager.SENSOR_DELAY_UI : Adecuado para el thread de UI (15mA)
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 117
Se debe usar el SensorManager.SENSOR_DELAY_FASTEST ya que si ocurre un accidente, el
sólo hecho de detectar que hubo uno y tener que cambiar el modo del sensor a
SensorManager.SENSOR_DELAY_FASTEST, haría que se pierdan mediciones muy valiosas para
poder reconstruir el accidente.
Para esto hay que ver cuánto tiempo puede estar el celular sin estar enchufado, sino se puede
emitir una notificación para que se enchufe.
Si está enchufado entonces se puede eliminar algún falso positivo, como si se cae al estar
hablando y no haber arrancado todavía, pero muchas veces, el usuario se olvida el enchufe y
quiere poder utilizarlo igual porque sabe que en el destino lo va a poder cargar. Habría que
ver cuánto aguantará la batería, si se gasta mucho…entonces se deberá imponer que sólo
puede usarse enchufado. Además, al enchufarlo en la casa, no debe arrancar solo, ya que no se
está en un auto.
El celular monitorea la velocidad para saber si está en un auto.
Energía consumida por el celular usando los distintos tipos de tecnologías celulares [46]
Transferencia de datos en lote (Bulk data transfer),por ejemplo una canción de
6MB:
o EDGE (90kbps): 300mA * 9.1 min = 45 mAh
o 3G (300kbps): 210mA * 2.7 min = 9.5 mAh
o WiFi (1Mbps): 330mA * 48 sec = 4.4 mAh
Por lo cual Wifi es mucho más rápido y gasta casi la misma energía (300mA contra 330mA),
pero al ser más rápido la energía total gastada es mucho menor que con 3G y EDGE (un 10%
de la energía gastada con EDGE y un casi 50% de la energía gastada con 3G). Sin embargo en
un auto no tenemos WiFi, por lo cual se debe elegir entre una de la conexiones celulares
disponibles. 3G vemos que gasta menos energía total (9.5 mAh contra 45mAh).
Conviene usar formatos binarios que puedan fácilmente mezclar datos binarios y texto en un
único request y conviene hacer la menor cantidad posible de viajes al servidor para gastar lo
menos posible.
5.19 Información que se transmitirá, ¿Qué parte, bajo qué conexión?
Es imprescindible usar un buen parser de texto, ya que algunos usan demasiada energía.
Quedan descartados los Tree Parsers (como DOM), debido al alto gasto de energía y memoria
que luego debe reciclarse por medio del Garbage Collector (GC). Los mejores son los que usan
Streams.
Debido a que la transmisión de la información es lo que más tiempo tardará, comprimir los
datos a enviar es una opción necesaria en la medida que sea posible, es por esto que si se
puede comprimir el contenido a ser enviado, entonces debe comprimirse. Es por esta razón
que se comprimen los archivos de datos antes de ser enviados (con el compresor GZIP).
El Framework GZIP usa directamente código nativo, y sirve para streams.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 118
5.20 Consideraciones al usar procesos en background en Android
Los servicios deben tener una vida corta. Cada proceso “cuesta” aproximadamente
2MB y tiene el riesgo de ser terminado/reiniciado por Android, si es que alguna
aplicación en background necesita memoria
Si se necesita lanzar un evento en un momento determinado de tiempo por ejemplo,
hacerlo mediante el mecanismo de AlarmManager o con los elementos <receiver> del
archivo manifest
Al finalizar la tarea, llamar stopSelf() para liberar los recursos asociados al proceso.
Luego, si se usa una Alarm se vuelve a crear el proceso aunque se haya llamado a
stop()
Usar setInexactRepeating () en la medida que sea posible para que se “despierte” sólo
una vez el celular y no una vez por aplicación
Usar AlarmManager y <receiver> en vez de servicios que duerman o hagan polling
El envío de información interesante como deportes, noticias, etc (para las cuales el
usuario debería suscribirse), podría ir por push (mediante el servicio C2DM o Cloud to
Device Messaging Framework9)
5.21 Evitar falsos positivos
Los falsos positivos son aquellas situaciones en las cuales se envía un alerta cuando en
realidad no se produjo un incidente, por ejemplo, si se cae el celular al piso del automóvil. Es
imprescindible tratar de evitarlos a fin de evitar que los servicios de emergencia pierdan
tiempo acudiendo a incidentes que en realidad no ocurrieron.
Un filtro posible podría ser chequeando el estado de activación del GPS, si está encendido, se
podría obtener la velocidad y luego si el vehículo está detenido, no generar alertas y sólo
comenzar con la detección de choques una vez que se detectó una velocidad del vehículo
mayor a X km/h y al detectarse que marcha más lento, volver a desactivar la detección. El
problema de esto es que si uno está detenido, también puede sufrir un choque, tanto si está en
un semáforo como si está estacionado, con lo cual debe tenerse esto en cuenta para la
creación del filtro.
Ya que nuestro filtro es de 4G y durante las pruebas de manejo y caída del celular nunca se
pasó de ese registro, es una forma también de filtrar posibles falsas alertas.
9 Cloud to Device Messaging Framework posibilita el uso de tecnología push para los celulares con sistema operativo Android.
Más información en: https://developers.google.com/android/c2dm/
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 119
5.22 Detección del Accidente
Al detectar un accidente se va a construir un mensaje con al menos la siguiente información
(siempre que esté disponible):
Fecha y Hora Ubicación Velocidad previa al accidente IMEI o ID del CHIP si se puede obtener (ya que podría usarse en otro celular) Etc.
Se enviará esta información a los servicios de emergencias y al PSAP o sólo PSAP, quien luego
informará a los servicios de emergencias. Se esperará una confirmación de recepción (ACK)
de parte de la otra parte, si no se recibe, se volverá a intentar enviar la información hasta que
se reciba la confirmación esperando con cada reintento un tiempo mayor que con el intento
anterior.
Luego del ACK se hará lo mismo con el EDS y también se esperará una confirmación de
recepción.
Luego de recibirse el ACK del EDS se creará un archivo comprimido (con GZIP u otro
framework de compresión de datos) con los datos del log de los sensores y GPS (que deberían
estar en la tarjeta SD o en la memoria si no hubiese tarjeta insertada.
Cada vez que arranca la aplicación, podrían borrarse los datos de los logs de anteriores viajes
para no ocupar espacio con datos que ya serían irrelevantes por no haberse detectado
incidentes.
Una posibilidad adicional sería el envío de SMS si es que una comunicación con el Web Service
no puede ser establecida ya sea porque el mismo está caído o cualquier otro motivo (aunque
no debería pasar ya que deberían estar en servidores con un uptime muy alto).
5.23 Logueo de información de los sensores
El logueo de los datos provistos por el acelerómetro y demás sensores debe ser continuo ya
que no se sabe cuándo ocurrirá un accidente, aunque se debe evaluar cada cuánto se puede
guardar información en la tarjeta de memoria porque esa será la tasa de escritura máxima.
Esto no hace que el acelerómetro deba bajar su tasa, pero sí se guardarán menos elementos a
menos que se use otra alternativa si la velocidad de muestreo es superior a la velocidad de
escritura. También, se pueden ir cacheando los datos en memoria e ir bajándolos cada X
lecturas a la tarjeta o a la base de datos, pero se tardará más en enviar el mensaje, pues debe
construirse el mensaje en el momento.
Las siguientes son diferentes posibilidades para gestionar los datos en memoria o en la
tarjeta:
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 120
Logueo de los datos en la memoria cada X segundos, luego se graba en la base de datos
o en un archivo en la tarjeta SD.
Logueo de los datos en la memoria al llegar a cierta cantidad de información, luego se
graba en la base de datos o en un archivo en la tarjeta SD.
Logueo directo en un archivo en la tarjeta SD cada X segundos.
Logueo directo en un archivo en la tarjeta SD al llegar a cierta cantidad de
información.
Cacheo (hay una clase en el framework) y luego pasaje a tarjeta SD.
Grabar en un archivo de texto es más rápido que en una base de datos en el celular dado que
éste debe, además, guardar información transaccional.
El problema de estar cacheando es que si ocurre un accidente no se dispondrá de toda la
información lo más rápido posible. Se debe tomar en cuenta que se está trabajando con
dispositivos electrónicos y no magnéticos, es decir, no hay tiempo de latencia y leer es muy
rápido.
5.24 Configuración
Datos privados como grupo sanguíneo, amigos, etc., podrían guardarse sólo en el servidor por
motivos de seguridad, por ejemplo, ante el robo del celular. Es decir, se configura una vez
desde el celular o al registrarse y queda almacenado. Luego si hay un alerta mediante el IMEI,
el número de línea, etc. se pueden asociar los datos.
5.25 Long Polling
Resolución para poder hacer “push” al navegador web desde el servidor y poder cargar
nuevos accidentes automáticamente en un navegador web. Long polling no es en sí
mismo una tecnología push, pero puede ser usada bajo circunstancias para emularlo
sobre todo donde un push verdadero no es posible.
En esta arquitectura (y en especial en este prototipo) se pretende tener la posibilidad de ver
en una pantalla grande en un centro de comandos la funcionalidad de cargar y mostrar en
pantalla nuevos accidentes de forma automática y a la vez que sea en un navegador web de
forma tal que un usuario en la casa pudiese entrar a la aplicación y, bajo otras restricciones de
seguridad, ver en sus monitores lo mismo.
Para esto se investigó la técnica de Comet o Long Polling (disponible en todos los
navegadores) y el uso Controladores Asíncronos de ASPNET MVC 3.
Mediante este concepto, el navegador realiza una llamada por AJAX al servidor y espera hasta
recibir un mensaje. Los Controllers Asíncronos permiten tener HTTP Requests sin usar
ASPNET threads.
En el servidor, hay dos limitantes de recursos a considerar con IIS y ASPNET:
Limites de HTTP request — en IIS7 el default es 5000 Limites de ASP.Net thread — en IIS7 el default es 12 x el número de CPUs
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 121
Para una aplicación típica de ASPNET (y aplicación ASP.Net MVC), un HTTP request siempre
usa ASPNET threads. Sin embargo se pueden usar Controllers Asíncronos en ASPNET MVC
para liberar al thread ASPNET (pero seguir manteniendo el HTTP request). El uso de
Controladores Asincrónicos es ideal para Comet HTTP requests.
Esta técnica solucionaría el hecho de poner una limitante a la cantidad de personas y centros
que podrían conectarse a la vez al sistema; esta técnica resuelve este problema, quitando la
variable limitante.
A continuación, se hará referencia a estos dos conceptos en más profundidad.
Comet
Tiene distintos nombres:
Comet
Push Ajax
Reverse Ajax
Two-way-web
HTTP Streaming
HTTP server push
Hay algunas librerías creadas como:
PokeIn
WebSync
stream-hub
[47] Comet es un modelo de aplicación web en el cual se usa un HTTP request largo que
permite hacer “push” de datos a un browser desde un servidor web, sin que el browser lo pida
explícitamente. Comet abarca múltiples técnicas para conseguir esta interacción. Todos estos
métodos se basan en funcionalidades incluidas, por defecto, en los navegadores como
JavaScript, a diferencia de otros plugins que no lo traen por defecto. El enfoque de Comet
difiere del modelo original de la web, en el cual un navegador hace un request de una página
web completa en una sola vez.
[48] Una técnica común en Comet involucra una conexión http “Long Polling”. Esto significa
que se llama a una URL que espera por un largo período antes de que algo pase.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 122
Figura 45. Cliente haciendo polling normal, es decir, se conecta y desconecta si no hay información para recibir [49]
Figura 46. Cliente haciendo Long Polling, es decir, se conecta y por más que no haya información para recibir,
queda conectado. [49]
Long polling suele terminar siendo un request XmlHttpRequest desde el navegador. Si un
evento está listo cuando el request llega al servidor, entonces se envía la respuesta, y la
conexión se cierra. Luego el cliente re-abre un request al server para traer más eventos. Si no
hay eventos listos para ser enviados, el servidor mantiene la conexión por un tiempo
especificado, y luego cierra la conexión. El navegador entonces re-abre el request y el ciclo
continúa. La conexión XmlHttpRequest debe ser cerrada inmediatamente luego que el evento
fue enviado al cliente para que éste pueda procesarlos. Debido a que la conexión debe ser
cerrada para procesar un evento inmediatamente, seguido de una reconexión, una conexión
long polling no se puede considerar un mecanismo real de push asincrónico del servidor, pero
permite emularlo. [49]
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 123
5.26 Controladores Asíncronos en ASPNET MVC 3
La clase AsyncController de ASPNET MVC 3, habilita la escritura de action methods10
asincrónicos. Se pueden usar los action methods para requests que duran mucho y que
dependan del procesador. Esto evita bloquear el servidor web mientras los requests son
procesados. [50][51]
5.26.1 Cómo se procesan los request desde el pool de threads
En el servidor web, .NET Framework mantiene un pool de threads que son usados para
atender los requests de ASPNET. Cuando llega un request, un thread del pool se despacha
para procesar ese request. Si el request es procesado de forma sincrónica, el thread que
procesa el request se bloquea mientras el request se está procesando, y ese thread no puede
atender otro request.
Esto puede no ser un problema, porque el pool de threads puede ser suficientemente grande
para manejar muchos threads bloqueados. Sin embargo, el número de threads en el pool es
limitado. En aplicaciones grandes, el tener múltiples procesos corriendo request largos,
puede bloquear los threads. Esta condición es conocida como thread starvation, que sería que
no hay threads en ese momento para procesar nuevos requests. Cuando se llega a esta
condición, el Web server encola requests. Si la cola de requests se llena, el Web server rechaza
los requests con el status HTTP 503 (Server Too Busy).
5.26.2 Procesando requests asíncronos
En las aplicaciones que pueden incurrir en thread starvation, se pueden configurar procesar
acciones de forma asíncrona. El tiempo para procesar un request asincrónico es similar al
tiempo para procesar un request sincrónico. Por ejemplo, si un request hace una llamada a la
red que requiere dos segundos para completarse, el request tarda dos segundos, se haga de
forma síncrona o asíncrona. Sin embargo, durante una llamada asíncrona, el servidor no es
bloqueado para responder a otros requests mientras espera que se complete el primer
request. Así, los request asíncronos evitan que los requests resulten encolados cuando hay
muchos que usan operaciones que tardan mucho.
10 En aplicaciones ASP.NET que no usan el framework MVC, la interacción del usuario se organiza entorno a páginas, y entorno a
levantar y manejar eventos desde la página y desde los controles en la página. En contraste, la interacción del usuario en
aplicaciones ASPNET MVC se organiza entorno a controllers y action methods. El controller define actions methods. Los
controllers pueden incluir muchos action methods. Más información en: http://msdn.microsoft.com/en-
us/library/dd410269(v=vs.98).aspx
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 124
Cuando se invoca una acción asincrónica, ocurren los siguientes pasos [50]
1. El servidor toma un thread del pool de threads (el worker thread) y lo programa para que procese un nuevo request que llegue. Este worker thread comienza una operación asincrónica.
2. Se retorna el worker thread al pool de threads para poder procesar otro web request. 3. Cuando se completa la operación asíncrona, se notifica a ASP.NET. 4. El servidor Web obtiene un worker thread del pool de threads (que puede ser un
thread diferente del cual empezó la operación asíncrona) para procesar el resto del request, incluyendo la creación de la respuesta.
Figura 47. El patrón asíncrono [50]
5.26.3 Cómo funcionan los controllers asincrónicos [53][54]
Figura 48. Funcionamiento de los controllers asincrónicos en ASPNET MVC [53]
1. Un usuario envía un request a un recurso en un server, por ejemplo: GET:
/controller/action
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 125
2. Ya que el action method es parte de un controller asíncrono, el procesamiento del
request es procesado por el worker thread del pool del CLR mientras el thread del IIS
procesa otros requests. Esta es la principal ventaja de los controllers asíncronos, los
limitados threads del IIS quedan fuera de la carga de procesos largos y proceso de
tareas bloqueantes, usándose los “simples” worker threads del CLR, los cuales en
comparación con los del IIS son “poco costosos”, es decir, se liberan los threads del IIS
para poder servir más requests mientras se realiza el trabajo en background.
3. El worker thread del CLR trabaja mientras se recicla el worker threads del IIS.
4. El worker thread del CLR termina su tarea, e invoca al método AsyncManager.Sync y
le pasa devuelta una parte de los datos procesados para ser devueltos al usuario final.
El AsyncManager obtiene el primer thread del IIS disponible y pasa los datos procesados del
worker thread del CLR a un action method especial que retorna los datos al usuario de una
forma consumible por este último, como una View o un JsonResult.
Los controllers asíncronos usan los poco costosos threads del CLR para liberar los costosos
threads del IIS tan pronto como sea posible.
5.27 Elección del tipo de servicio background: Threads, AsyncTask e IntentService
Una premisa de Android es no bloquear nunca el UI Thread, esto es dicho en toda oportunidad
posible por los creadores e ingenieros en los Google I/O, las charlas tecnológicas que ellos
llevan a cabo para enseñar las mejores prácticas al usar Android. Una manera de no bloquear
el UI Thread es mediante el uso de procesos en background, pero hay más de un tipo de
servicio background disponible y cada uno tiene sus pros y sus contras. A continuación se
muestra una tabla en la que se enumeran las características de cada uno:
Service Thread IntentService AsyncTask
Cuándo usarlo?
Un tarea sin UI,
pero que no sea
muy larga. Usar
threads en un
service para
tareas largas.
Tareas largas
en general.
Para tareas en
paralelo usar
múltiples
threads.
Tareas largas
usualmente sin
comunicación con el
thread principal (main
thread).
Si se necesita
comunicación, se puede
usar el handler del main
thread o broadcast
intentes
Cuando se necesitan
callbacks (tareas que se
Tareas largas que
deban comunicarse
con el main thread.
Para tareas en
paralelo usar
múltiples instancias
o Executor (API
Level 11 (Android
3.0))
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 126
lanzan con Intents).
Lanzamiento
Llamada al
método
onStartService()
Método del
Thread start() Intent
Llamada al método
execute()
Lanzado desde
(thread)
Cualquier
thread
Cualquier
Thread
Main Thread (El Intent
se recibe en el main
thread y luego se usa el
worker thread)
Main Thread
Runs On
(thread) Main Thread
Su propio
thread
Un worker thread
separado
Un worker thread.
Sin embargo, los
métodos del Main
thread pueden ser
invocados en el
medio para publicar
progreso.
Limitaciones /
Desventajas
Puede bloquear
el main thread
Manejo
manual del
thread
El código se
puede volver
difícil de leer.
No se pueden correr
tareas en paralelo.
Se encolan múltiples
intentos en el mismo
worker thread.
Una instancia puede
ser ejecutada sólo
una vez (por lo cual
no se puede correr
en un loop)
Debe ser ejecutada y
creada desde el
main thread
Tabla 3. Distintos tipos de servicios disponibles en Android [55]
Debido a que AsyncTask se dispara desde UI Thread, si el sistema operativo necesita recursos
puede destruir el UI thread y la AsyncTask con él. Para que esto no pase, se puede usar el
IntentService.
Threads y Handlers es un poco más eficiente, pero más engorroso de desarrollar ya que debe
hacerse todo manualmente, a diferencia de los otros dos.
En este caso no se necesitaba informar nada a la UI, sólo se informa si un mensaje (tanto UDS
como EDS) fue enviado o no y se puede hacer por medio de Toasts, que son mensajes que se
muestran en pantalla, es por esto que se decidió usar IntentService.
5.28 Guardado de ubicaciones y lecturas de los sensores
La escritura en la base de datos es lenta en comparación a la escritura en un archivo. Esto se
debe a que la base de datos debe estar manteniendo un log para las transacciones, entre otras
cosas, lo que implica más escrituras, lecturas y borrados.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 127
Debido a esto se decidió guardar los datos de los sensores en un archivo de texto.
El nombre del archivo contiene el número de la línea (si está disponible), la fecha y hora del
envío del mismo.
Para la prueba de concepto se debió emular en un principio los sensores ya que no se contaba
con un celular real, para lo cual se usó el simulador provisto por openintents:
http://code.google.com/p/openintents/wiki/SensorSimulator
5.29 Por qué usar ASPNET MVC, Razor y no webforms en la prueba de concepto
Se eligió usar ASPNET MVC ya que provee mayor posibilidad de testing, mejor separación de
capas y además se quería estudiar el framework. Se eligió Razor ya que es un nuevo motor
para las vistas, diseñado desde cero y pensado para que el código quede lo más prolijo y
limpio posible, deja más claro el código y también se quería ver y aprender su funcionamiento.
[56] [57]
5.30 Mapa en el servidor
Uno de los frameworks usados en el mapa del servidor es ClusterMarker:
Este framework permite que si hay una densidad grande de markers en un sector pequeño, se
vea sólo un marker (el cluster) conteniendo el número de markers originales que contiene,
luego al hacer zoom, se modifica el marker cluster por los markers originales y de esta forma
se pueden ver de forma correcta en la pantalla. [58]
Figura 49. Cluster Marker en funcionamiento [58]
5.31 Location Mock Provider para Android
Para poder simular la ubicación de cada choque y tratar de hacerlo lo más real posible (al
azar), se usó un Proveedor de Ubicación Mock, es decir ficticio, y se configuraron 2 puntos al
azar dentro de la capital federal, luego se generan puntos al azar dentro del cuadrado que
queda definido por esos dos puntos (superior izquierdo e inferior derecho). Esto es posible
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 128
gracias a que Android provee el método addTestProvider de la clase LocationManager, el cual
crea un proveedor de ubicación mock y lo agrega a la lista de proveedores activos [59].
5.32 Exactitud de la posición en Android
Cuando se necesita obtener la ubicación del celular y no se cuenta con señal GPS, se le puede
especificar a Android que obtenga una ubicación con una cierta exactitud. Por ejemplo, si se
quiere una precisión de 200 metros, se especifica esto a Android y éste intentará traer una
ubicación con esa exactitud. De no conseguirla, esperará hasta poder obtenerla y sólo en ese
momento devolverá a la aplicación, la ubicación encontrada.
Por lo tanto si se devuelve una posición, uno puede pensar que la posición actual del usuario
está en la ubicación devuelta +/- la precisión. La precisión es el radio dentro del cual puede
estar el usuario.
Cabe destacar que las estimaciones de las ubicaciones que vienen desde distintas fuentes de
ubicación pueden no ser consistentes en cuanto a la precisión. Una ubicación obtenida hace 10
segundos de una fuente puede ser más precisa que una ubicación nueva de otra fuente o la
misma.
Tanto como con Cell Id como con redes Wifi lo que intentará Android es obtener una posición
aproximada cruzando los datos de dónde se encuentran dichos elementos y en la medida de lo
posible intentará usar ambos a la vez para poder ser lo más preciso posible.
Tanto Wifi como GPS corren en un chip aparte, esto quiere decir que consumirán más batería.
En el caso de Wifi sólo se consume batería para obtener una posición cuando se usa para esto
mismo. El GPS consume mucha batería.
Precisión Energía usada Tecnología
6,1 mts Alta GPS Autónomo – Proveedor GPS 1. Usa el chip GPS del móvil. 2. Línea de visión a los satélites. 3. Necesita unos 7 para obtener un fix. 4. Toma un gran tiempo obtener un fix. 5. No funciona alrededor de edificios altos.
61 mts. Media – Baja Assisted GPS (AGPS) – Proveedor: Network 1. Usa el chip GPS en el móvil, así también como asistencia de la red (red
celular) para proveer un fix inicial rápido. 2. Muy poco consumo de energía. 3. Muy preciso. 4. Funciona sin visión directa a los satélites. 5. Depende del que el la empresa celular y el celular soporten esto
(ambos dos, sólo uno no dejaría usarlo).
1615 mts. Baja Cell ID lookup/ Wifi MACID lookup – Provider: Network o Passive11 1. Muy rápido lock y no requiere un chip GPS que esté activo en el móvil. 2. No requiere energía extra. 3. Tiene muy poca precisión: A veces puede tener mejor precisión en
áreas con densa población donde haya muchos Access Points Wifi y personas que compartan con Google su ubicación.
Tabla 4. Energía usada para obtener la posición con distintos métodos [60]
11 Cuando se usa el location provider passive se pueden recibir ubicaciones sin haber iniciado un location fix. Se pueden recibir
actualizaciones de la ubicación cuando otras aplicaciones o servicios las piden, sin que haya que pedirlas de forma explicita
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 129
5.33 Diagrama de Base de datos
Figura 50.1. Diagrama de la base de datos
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 130
Figura 50.2. Diagrama de la base de datos
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 131
Figura 50.3. Diagrama de la base de datos
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 132
Figura 50.4. Diagrama de la base de datos
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 133
Figura 50.5. Diagrama de la base de datos
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 134
Figura 50.6. Diagrama de la base de datos
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 135
Figura 50.7. Diagrama de la base de datos
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 136
Figura 50.8. Diagrama de la base de datos
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 137
Figura 50.9. Diagrama de la base de datos
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 138
Figura 50.10. Diagrama de la base de datos
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 139
Descripción de las tablas principales
Tabla: UdsMessage
Descripción: Los mensajes UDS generados por los dispositivos móviles.
Nombre Tipo ForeignKey Descripción
UdsMessageId (PK, Identity) bigint False Id del UdsMessage
UdsReceptionDate datetime False Fecha y hora UTC en que se recibió el
mensaje UDS
CrashDate datetime False Fecha y hora UTC en que ocurrió el
accidente (viene con el mensaje UDS)
RawData varbinary False El texto del mensaje UDS tal como se
recibió
UdsVersion varchar False
Versión del mensaje UDS. Útil para cuando
cambie alguna información del mensaje,
para parsearlo y para saber cómo leer el
mensaje del campo RawData
CrashId bigint True Foreign key al registro de Crash
Speed Int False Km/h (entero)
Bearing float False En grados decimales.
Latitude float False
Latitud en grados decimales. (-90° to +90°).
0 significa que la latitud es desconocida.
(WGS84)
Longitude float False
Longitud en grados decimales (0 to 360°). 0
significa que la longitud es desconocida
(WGS84)
Accuracy float False Precisión obtenida en la ubicación del
choque (en metros)
Rollover char False Posibles valores: Y, N, U (Unknown). True si
se detectó un vuelco
AutomaticTrigger char False Posibles valores: Y, N, U (Unknown). True si
la activación no fue manual
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 140
AirbagDeployed char False Posibles valores: Y, N, U (Unknown). True si
se detectó que el airbag fue activado
EmailSentToEmergencyEntities bit False
True si ya se ha enviado un email a las
entidades de emergencias luego del
accidente.
UdsMessageStatusId bigint True Id de la Foreign Key al status del mensaje
UDS
AddressOrPointOfInterest varchar False
Dirección del choque (a ser completada por
el servidor y obtenida mediante reverse
geocoding). Si no se encuentra una
dirección, punto de interés o referencia
más cercano.
CountryId int True Foreign key al país correspondiente desde
el cual se envió el mensaje UDS
StateProvince varchar True
Foreign key a la provincia o estado
(depende del país) correspondiente desde
el cual se envió el mensaje UDS
ZipCode varchar False Código postal desde el cual se envió el
mensaje UDS
MobileNumber nchar False Número de línea desde el cual se envió el
mensaje UDS
SubscriberId varchar False El id único de suscripción, por ejemplo, el
IMSI para un dispositivo móvil GSM.
RetriesNumber Int False En cuántos reintentos se pude enviar. 0
sería que se envió al primer intento.
isTest bit False
True si es un test. Esto sirve para pruebas
en ambientes pre-productivos o
productivos.
Nombre: EdsMessage
Descripción: EDS Message
Nombre Tipo ForeignKey Descripción
EdsMessageId (PK,
Identity) bigint False Id del mensaje EDS
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 141
EdsReceptionDate datetime False Fecha y hora UTC en que se recibió el mensaje
EDS
CrashDate datetime False Fecha y hora ETC en que ocurrió el accidente
(viene con el mensaje EDS)
RawData varbinary False El texto del mensaje UDS tal como se recibió
EdsVersion varchar False
Versión del mensaje EDS. Útil para cuando
cambie alguna información del mensaje, para
parsearlo y para saber cómo leer el mensaje
del campo RawData
CrashId bigint True Foreign key al registro de Crash
Speed float False Km/h (entero)
Bearing float False En grados decimales
Latitude float False
Latitud en grados decimales. (-90° to +90°). 0
significa que la latitud es desconocida.
(WGS84)
Longitude float False
Longitud en grados decimales (0 to 360°). 0
significa que la longitud es desconocida
(WGS84)
Accuracy float False Precisión obtenida en la ubicación del choque
(en metros)
EdsMessageStatusId nchar False Id de la Foreign Key al status del mensaje EDS
AddressOrPointOfInterest varchar False
Dirección del choque (a ser completada por
el servidor y obtenida mediante reverse
geocoding). Si no se encuentra una
dirección, punto de interés o referencia más
cercano.
CountryId int True Foreign key al país correspondiente desde
el cual se envió el mensaje UDS
StateProvince varchar True
Foreign key a la provincia o estado
(depende del país) correspondiente desde
el cual se envió el mensaje UDS
ZipCode varchar False Código postal desde el cual se envió el
mensaje UDS
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 142
Rollover char False Posibles valores: Y, N, U (Unknown). True si
se detectó un vuelco
AutomaticTrigger char False Posibles valores: Y, N, U (Unknown). True si la
activación no fue manual
AirbagDeployed bit False Posibles valores: Y, N, U (Unknown). True si
se detectó que el airbag fue activado
MessageType nchar False MSID (IMEI, IMSI or MSISDN)
NumberOfPassengers smallint False Cantidad de pasajeros en el vehículo al
momento del choque.
Parsed bit False El valor de este campo se cambia a true
cuando se parsea el campo RawData.
MobileNumber nchar False Número de línea desde el cual se envió el
mensaje UDS
NetworkType varchar False
Tecnología de radio que se usa en el
dispositivo móvil al momento de enviar el
mensaje EDS (GPRS, EDGE, HSDPA,UMTS,
LTE, etc)
DeviceSoftwareVersion nchar False
Versión de software usado en el dispositivo
móvil, por ejemplo, el IMEI/SV para celulares
GSM.
NetworkCountryIso nchar False
Código de país ISO equivalente al MCC del
operador registrado en ese momento (MCC =
Mobile Country Code).
NetworkOperator varchar False El nombre numérico (MCC+MNC) del
operador registrado en ese momento
NetworkOperatorName varchar False El nombre alfabético del operador registrado
en ese momento
PhoneType nchar False Constante que indica el tipo de celular (GSM,
CDMA, SIP)
SimContryIso nchar False El código de país ISO equivalente para el
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 143
código de país del proveedor de la SIM
SimOperator nchar False El MCC+MNC (mobile country code + mobile
network code) del proveedor de la SIM.
SimOperatorName varchar False El nombre del proveedor del servicio o
Service Provider Name (SPN).
SimSerialNumber nchar False Número de serie de la SIM (si aplica, es decir
no es CDMA por ejemplo)
SimState int False
Estado de la SIM (por ejemplo, desconocido,
ausente, se requiere PIN, se requiere PUK,
bloqueado por la red, lista)
SubscriberId varchar False El id único de suscripción, por ejemplo, el
IMSI para un dispositivo móvil GSM.
HasIccCard bit False True si hay un tarjeta ICC12 presente
IsNetworkRoaming bit False
True si se considera que el dispositivo móvil
usa roaming para comunicarse al momento
del choque.
Sólo está disponible cuando el usuario está
registrado en la red.
12 ICC = Integrated Circuit Card. Más información en http://en.wikipedia.org/wiki/Smart_card
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 144
Nombre: HospitalAdmissions
Descripción: Registros de las internaciones en los hospitales de los accidentados.
Nombre Tipo ForeignKey Descripción
PersonId (PK) bigint True Foreign key a la persona que está ingresando al
hospital
HospitalId
(PK) bigint True
Foreign key al hospital donde la persona está
ingresando
CrashId (PK) bigint True Foreign key al choque en el cual la persona necesita
hospitalizarse
EntryDateTime datetime False Fecha y hora UTC en que la persona ingresó al
hospital
ExitDateTime datetime False Fecha y hora UTC en que la persona egresó del
hospital
Diagnostic varchar False El diagnostico médico realizado en el hospital. Texto
libre
Nombre: MedicalRecords
Descripción: Los registros médicos asociados con una persona.
Nombre Tipo ForeignKey Descripción
MedicalRecordId
(PK) bigint False Id del registro médico
Allergies nvarchar False Alergias de la persona. Texto libre
BloodType nvarchar False Tipo de sangre de la persona
MedicalCareBrand nvarchar False Cobertura social
MedicalCareNumber nvarchar False Número de asociado de la cobertura social
PersonId bigint True Foreign key a la persona a la cual pertenece el
registro médico
Medications varchar False Medicamentos que toma la persona
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 145
Nombre: Crash
Descripción: Registros con la información de los choques
Nombre Tipo ForeignKey Descripción
CrashId (PK, Identity) bigint False Id del registro
EventVerified bit False
Indica si hubo una confirmación verbal del
evento del originador del evento, servicio
de emergencias, etc.
IncidentDateTime datetime False
Fecha y hora UTC del incidente
(correspondiente con la fecha y hora de
latitud y longitud)
IncidentReceivedDateTime datetime False Fecha y hora UTC en que se recibió el
incidente
CountryId bigint True Foreign key al país correspondiente donde
se produjo el incidente
StateProvinceId bigint True
Foreign key a la provincia o estado
(depende del país) donde se produjo el
incidente.
City bigint False Ciudad en la cual se produjo el incidente
Neighborhood bigint False Barrio en el cual se produjo el incidente
TypeOfIntersection bigint True
Tipo de intersección, por ejemplo:
No es intersección, Intersección de cuatro
esquinas, Intersección en forma de T,
Intersección en forma de Y, Rotonda, etc.
Esto sirve para futuros reportes y formas
de identificar potenciales lugares de
incidentes.
Latitude float False
Latitud en grados decimales. (-90° to
+90°). 0 significa que la latitud es
desconocida. (WGS84)
Longitude float False
Longitud en grados decimales (0 to 360°).
0 significa que la longitud es desconocida
(WGS84)
AddressOrPointOfInterest varchar False
Dirección del choque (a ser completada
por el servidor y obtenida mediante
reverse geocoding). Si no se encuentra una
dirección, punto de interés o referencia
más cercano.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 146
Accuracy float False Precisión obtenida en la ubicación del
choque (en metros)
LocationConfidencePercentage bigint False Indica el porcentaje de confianza de que la
ubicación es la correcta
DeviceEventTypeId bigint False
Tipo de dispositivo que causó el alerta. Por
ejemplo:
Airbag CAN, Tensor del cinturón de
seguridad, acelerómetros, celular, llamada
de un testigo del incidente, activación
manual, etc.
WheaterConditionId bigint True
Foreign key a las condiciones atmosféricas
que había en el momento del incidente.
Por ejemplo:
Despejado, nublado, niebla, lluvia, nieve,
granizo, ventoso, polvo, etc.
Este campo sirve para prevención futura y
análisis de accidentes y zonas riesgosas
LightingConditionId bigint True
Foreign key a las condiciones lumínicas en
el momento del incidente. Por ejemplo:
Día, noche, amanecer, atardecer, oscuro,
etc.
HighwaySurfaceConditionId bigint True
Foreign key a las condiciones del asfalto
(si lo hubiese) donde se produjo el
incidente. Por ejemplo:
Mojado, seco, nevado, hielo, arena, polvo,
aceite, etc.
EnvironmentContributing
CircumstanceId bigint True
Foreign key a las aparentes condiciones
ambientales que podrían haber causado el
accidente. Por ejemplo:
Ninguna, condiciones ambientales,
obstrucción física, animales en el camino,
deslumbramiento, etc.
Con estos datos se podría saber, entre
otras cosas, dónde hacen falta más
controles de tránsito
RoadContributingCircumstanceId bigint True
Foreign key a las condiciones del camino
que podrían haber contribuido al
incidente. Por ejemplo:
Ninguna, Condición de superficie del
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 147
camino (mojado, con hielo, barro),
Escombros, Pozos, Zona de Trabajo,
Obstrucción en el camino, Dispositivo de
Control de Tránsito defectuoso, faltante,
etc.
CrashRelationToTrafficwayId bigint True
Foreign key a la ubicación del accidente y
el empalme del camino. Por ejemplo:
Subida/bajada, paso a nivel, línea de
frenado, señal de Parar, banquina,
FirstHarmfulEventId bigint True
Foreign key al primer aparente motivo que
causó el incidente. Por ejemplo:
Explosión, vuelco, inmersión, pérdida de
cargamento/equipaje, atropello a una
persona, animal suelto, choque con
guardarrail, etc.
Con esta información se pueden analizar
causas e identificar posibles medidas para
contrarrestar los choques.
TrafficwayTypeId bigint True
Foreign key al tipo de camino donde se
produjo el incidente. Por ejemplo:
Ruta, Autopista, Ruta sin marcación, Ruta
con doble línea amarilla, Ruta con línea
blanca punteada, Avenida, Calle, etc.
La información obtenida ayudará a
diseñar futuras mejoras en la señalización
y armado de rutas y autopistas
RoadwayTotalLanes Int False
Número total de carriles en la avenida,
ruta, autopista, calle, etc. que hay en las
cuales venía el auto accidentado.
RoadwayAlignmentId bigint True
Foreign key al tipo de inclinación y
geometría del camino donde se produjo el
accidente. Por ejemplo:
Curva a la izquierda/derecha, Curva
peligrosa a la izquierda/derecha, cuesta
arriba/abajo, etc.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 148
Permite saber la relación del vehículo
involucrado con vuelcos, salidas del
camino, etc.
TrafficControlDeviceTypeId bigint True
Foreign key al tipo de dispositivo de
control de tráfico que había en el lugar al
momento del accidente. Por ejemplo:
Sin control, cartel de parar, cartel de
escuela, cartel de obra, señal de paso a
nivel. Para todos opciones de
funcionamiento/faltante/inoperante
HitAndRun bit False True si el conductor que supuestamente
causó el accidente huyó luego del choque.
DataSourceId bigint True Foreign key al tipo de fuente que emitió el
alerta.
DispatcherId bigint True Foreign key al dispatcher que se encargó
del alerta
CrashProfileId bigint True
Foreign key al profile del choque. Por
ejemplo:
Choque lateral, choque frontal, múltiples
impactos, etc.
Nombre: ClinicHistory
Descripción: Historia clínica de las personas
Nombre Tipo ForeignKey Descripción
ClinicHistoryId PK bigint False Id de la historia clínica
SpecialityId bigint False Especialidad médica tratada
Descripción varchar False Descripción del registro de la historia clínica
MedicalRecordId bigint True Foreign key al registro médico que tiene información de
la persona, como cobertura social, tipo de sangre, etc.
LabResults varbinary False Esto puede ser un documento escaneado
HospitalId bigint True Foreign key al hospital donde fue atendida la persona
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 149
Nombre: Vehicle_Crash
Descripción: Relación entre cada vehículo y el registro del choque
Nombre Tipo ForeignKey Descripción
IgnitionStateOn Bit False True si el motor estaba encendido en el momento
del choque. False si estaba apagado.
Bearing bigint False Dirección que llevaba el vehículo al momento del
accidente (en grados de 0 a 359)
OrientationId bigint True
Foreign key a cómo quedó el vehículo luego del
accidente. Por ejemplo: Sobre las cuatro ruedas,
sobre el techo, sobre el lateral, etc.
Fire Bit False True si el vehículo estuvo en llamas luego del
accidente
MultipleImpacts Bit False True si el vehículo sufrió múltiples impactos.
LicensePlateId varchar True Foreign key al registro del vehículo en particular
CrashId (PK) bigint True Foreign key al registro del choque
WaterDetected Bit False True si hubo agua dentro del vehículo luego del
choque
Passengers Int False Número de pasajeros en el vehículo al momento del
accidente.
Rollover char False Posibles valores: Y, N, U (Unknown). True si se
detectó un vuelco
AirbagDeployed bit False Posibles valores: Y, N, U (Unknown). True si se
detectó que el airbag fue activado
Nombre: Vehicle_InsuranceProvider
Descripción: Relación entre la compañía de seguro y el vehículo. Un vehículo puede tener
más de un seguro durante su vida
Nombre Tipo ForeignKey Descripción
InsuranceProviderId bigint True Id de la compañía de seguro
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 150
(PK)
LicensePlateId (PK) varchar True Foreign key al registro del vehículo
PolicyId varchar False
Id de la cobertura en particular del vehículo en
la compañía de seguro. El tipo de datos y largo
depende de la compañía de seguro.
StartDate datetime False Fecha cuando la póliza comenzó a ser válida
EndDate datetime False Fecha cuando la póliza finalizó con la compañía
de seguro
Nombre: Vehicle
Descripción: Los diferentes vehículos registrados en el sistema porque estuvieron implicados
en uno o más incidentes.
Nombre Tipo ForeignKey Descripción
LicensePlateId (PK) varchar False
Id del vehículo,
identificado con la
patente
VehicleBodyTypeId int True
Foreign key al tipo de
vehículo. Por ejemplo:
Vehículo de pasajeros,
Micro, Camión 2 ejes,
Camión 4 ejes, Camión
más de 4 ejes, Camión
con acoplado, Casa
rodante, etc.
BrandId bigint True
Foreign key a la marca
del vehículo. Por
ejemplo: Chevrolet,
General Motors, Fiat,
Ford, BMW, Mercedes.
ModelId bigint True Foreign key al modelo
del automóvil. Por
ejemplo: Prius, Corsa
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 151
Classic, Civic, etc
Year bigint False Año de fabricación del
vehículo
Weight bigint False Peso bruto del vehículo
en kilogramos
CommercialDiplomaticLicensePlate varchar False
Si es un vehículo
comercial o diplomático,
la patente del mismo que
aplica a vehículos
comerciales o
diplomáticos.
EngineSerialNumber bigint False Número de serie del
motor del vehículo
MotorVehicleRegistrationCountryId bigint True
Foreign key al país
donde está registrado el
vehículo
MotorVehicleRegistrationStateProvinceId bigint True
Foreign key a la
provincia o estado
donde está registrado el
vehículo
MotorVehicleRegistrationYear Int False Año de patentamiento
del vehículo
SpecialFunctionOfMotorVehicleInTransportId int False
Si es un vehículo con
funciones especiales,
entonces la Foreign key
al tipo de función. Por
ejemplo:
Vehículo escolar, Taxi,
Ambulancia, Patrullero,
Bomberos, ,etc.
OwnerId bigint True Foreign key al dueño del
vehículo
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 152
Color Int True
Foreign key al color del
vehículo al momento del
accidente.
PowerSource Int True
Foreign key al tipo de
combustible que usa el
vehículo. Por ejemplo:
Nafta, Gasoil, GNC,
Alconafta (Brasil),
eléctrico, híbrido, etc.
HazardoursMaterials bit False
True si el vehículo
transportaba materiales
peligrosos.
Nombre: Waypoint_Zone
Descripción: Relaciona los waypoints con las zonas. La zona debe formar un polígono
cerrado
Nombre Tipo ForeignKey Descripción
WaypointId
(PK) bigint True Id del waypoint
ZoneId bigint True Id de la zona
NextWaypointId bigint True Id del siguiente waypoint (debe formar un polígono
cerrado)
Nombre: Waypoint
Descripción: Waypoints registrados en el sistema. Son puntos de referencia
Nombre Tipo ForeignKey Descripción
WaypointId
(PK) bigint False Id del Waypoint
Latitude float False Latitud en grados decimales. (-90° to +90°). 0 significa que la
latitud es desconocida. (WGS84)
Longitude float False Longitud en grados decimales (0 to 360°). 0 significa que la
longitud es desconocida (WGS84)
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 153
Nombre: Zone
Descripción: Descripción de la zona
Nombre Tipo ForeignKey Descripción
ZoneId (PK) bigint False Id de la zona
Descripción varchar False Descripción de la zona. Puede ser un nombre
Nombre: Person
Descripción: Las personas registradas en el sistema, bien porque hayan estado en un
accidente, bien porque sean dueños de un auto, etc.
Nombre Tipo ForeignKey Descripción
PersonId (PK) bigint False Id de la persona
FirstName varchar False Nombre de la persona
LastName varchar False Apellido de la persona
Age int False Edad de la persona
Gender char(1) False
Sexo de la persona.
M – Masculino, F- Femenino, U – No se sabe
(Unknown)
Address varchar False Dirección donde vive la persona
Email varchar False Email de la persona
LanguageId Int True Lenguaje nativo de la persona
HearingImpared char(1) False Indica si la persona tiene problemas auditivos
T – True, F- False, U – No se sabe (Unknown)
MobilityImpared char(1) False Indica si la persona tiene problemas motrices.
T – True, F- False, U – No se sabe (Unknown)
SpeechImpared char(1) False Indica si la persona tiene problemas del habla.
T – True, F- False, U – No se sabe (Unknown)
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 154
OtherCondition varchar False Indica cualquier otra condición de la persona que
pudiese asociarse a las causas del choque
MedicalHistoryId bigint True Foreign key a la historia médica de la persona
OrganDonor bit False True si es donante de órganos
PreferredHospitalId bigint True Foreign key al hospital donde la persona prefiere
atenderse
LivingWill bit False
Indica si la persona tiene algún documento formal
sobre muerte digna por ejemplo, o en algunos
países "no resucitar" (DNR) o “no hacer
transfusiones de sangre”
Birthdate date False Fecha de nacimiento de la persona
DriverLicenseNumberId bigint False Número licencia de conducir de la persona (si
tiene)
BornStateAndProvinceId bigint False Foreign key a la provincia o estado de nacimiento
de la persona
BornCountryId bigint False Foreign key al país donde nació la persona
StateAndProvinceId bigint False Foreign key a la provincia o estado de residencia
de la persona
ResidenceCountryId bigint False Foreign key al país de residencia de la persona
DocumentTypeId bigint False Foreign key al tipo de documento de la persona en
el lugar de residencia
DocumentNumber bigint False Número de documento correspondiente al tipo de
documento de la persona en el lugar de residencia.
TypeOfPersonId int True Para la generalización en si es ocupante de un
vehículo o no en un choque en particular
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 155
Nombre: MobilePhoneCallLog
Descripción: Log de las llamadas hechas al celular que reportó el choque (si aplica)
Nombre Tipo ForeignKey Descripción
MobilePhoneCallId (PK,
Identity) bigint False Id de la llamada
CrashConfirmed bit False True si el choque fue confirmado por
alguna fuente
CarOnFire bit False True si el vehículo está en llamas
CarOnWater bit False True si el vehículo está bajo el agua o
con agua dentro
CarCanFall bit False True si el vehículo está al borde de un
precipicio y puede caer
AnyoneEnjured bit False True si hay heridos
AnyoneBleeding bit False True si hay ocupantes sangrando
NumberOfPassenger smallint False Número de pasajeros
SpeakerCanMoveArms bit False True si la persona que habla puede
mover los brazos
SpeakerCanMoveLegs bit False True si la persona que habla puede
mover las piernas
SpeakerEntrapped bit False True si la persona que habla está
atrapada
Comments varchar False Comentarios
DispatcherId bigint True Foreign key al despachante que atendió
el alerta
CrashId bigint True Foreign key al registro del choque
UDSMessageId bigint True Foreign key al mensaje UDS asociado
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 156
Nombre: MobilePhone
Descripción: Celulares registrados en el sistema
Nombre Tipo ForeignKey Descripción
MobilePhoneId
(PK, Identity) bigint False Id del registro del celular
IMEI varchar False
IMEI del celular (técnicamente debería ser unívoco,
pero se decide tenerlo con posibilidad de
duplicados para analizar un posible robo, ya que el
IMEI se puede duplicar de forma ilegal)
CrashId bigint False Foreign key al registro del choque
Brand varchar False Marca del dispositivo móvil
Model varchar False Modelo del dispositivo móvil
OS varchar False Sistema operativo del dispositivo móvil
OSVersion Varchar False Versión del sistema operativo del dispositivo móvil
Nombre: MapFilters
Descripción: Filtros que se aplican al mapa que se ve en el servidor
Nombre Tipo ForeignKey Descripción
MapFilterId (PK,
Identity) int False Id del registro
UserId int True Foreign key al registro del usuario
ShowGreenAccidents bit False True muestra accidentes que ya fueron
resueltos
ShowYellowAccidents bit False True muestra accidentes con la ayuda en
camino
ShowRedAccidents bit False
True muestra accidentes que acabaron de
ocurrir y todavía no se llamó al dispositivo
móvil que informó el mismo
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 157
DateFrom datetime False Muestra accidentes desde una fecha en
particular
DateTo datetime False Muestra accidentes hasta una fecha en
particular
Nombre: Hospitals
Descripción: Los hospitales regstrados en el sistema
Nombre Tipo ForeignKey Descripción
HospitalId (PK,
Identity) bigint True Id del hospital
BedsAvailable int False Número de camas disponibles para nuevos
pacientes
TotalBeds int False Número total de camas en el hospital tanto
disponibles como ocupadas
TraumaHospital bit False
True si es un hospital de trauma, es decir, que
está preparado para emergencias y atención de
pacientes con severa complejidad
HasHeliport bit False
True si el hospital cuenta con helipuerto. Esto
indica si se puede trasladar un paciente de forma
aérea para una más rápida atención
AmbulancesAvailable int False Número de ambulancias disponibles
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 158
5.34 ¿Por qué un ORM? ¿Por qué Entity Framework 4?
ORM son las siglas para Object Relational Mapping y sirve básicamente para poder persistir,
entre otras cosas, datos entre un lenguaje de programación orientado a objetos y el utilizado
en una base de datos relacional.
Un ORM permite abstraerse de la base de datos y trabajar sin estar pensando en la
persistencia de los distintos objetos. Permite a su vez, implementar herencia y polimorfismo.
Entity Framework es un framework desarrollado por Microsoft que entre, otras cosas, brinda
un ORM.
Figura 51. Diagrama de interacción con Entity Framework [54]
Algunos beneficios del uso de Entity Framework [54]
Menor tiempo de desarrollo: el framework provee el acceso a la capa de datos, por lo
cual el desarrollador se puede concentrar en la lógica de la aplicación.
Soporta entidades POCO (Persistence Ignorance through Plain Old CLR Objects).
Se puede generar el mapa relacional a partir de una base de datos existente.
No se depende de una base de datos en particular, debido a que soporta un modelo
conceptual que es independiente del modelo físico
Se tiene IntelliSense al soportar Language-Integrated Query (LINQ to Entities) y
validación de sintaxis en tiempo de compilación para escribir queries contra el modelo
conceptual.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 159
5.35 Capturas de Pantallas – Servidor
Figura 52. Operaciones de Alta – Baja – Modificación (En el caso de mensajes UDS sólo modificación)
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 160
Figura 53. Mapa con todos los accidentes del momento, filtrado según se seleccione la gravedad.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 161
Figura 54. Mapa con todos los accidentes del momento, filtrado según se seleccione la gravedad y con un cluster de cuatro
accidentes.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 162
Figura 55 Al hacer doble click sobre un accidente se muestra un mapa satelital y los datos detallando el mismo. Además se
permite llamar al dueño accidentado del celular. A la derecha, la ampliación del cuadro de información del accidente.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 163
Figura 56. Al comprobar que el mensaje UDS no está siendo administrado por ninguna otra persona, se procede a la llamada y
llenado del formulario.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 164
Figura 57. Ampliación del formulario. El mismo permitirá ayudar a los servicios de emergencia en camino a preveer acciones más
adecuadas para el tipo de accidente.
Figura 58. Se guarda la información recabada en la llamada en una base de datos
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 165
Figura 59. Luego de que el accidente fue resuelto, se procede a cambiar su estado.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 166
5.36 Capturas de pantallas – Dispositivo Móvil
Figura 60. Pantallas de inicio de la aplicación Android. Luego de hacer tap en el botón de inicio (verde) comienzan a registrarse
los datos proporcionados por los sensores y el botón cambia de estado pasando a rojo.
Figura 61. Pantalla obtenida mientras se ejecuta la aplicación. El botón ”Crash”, simula un choque.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 167
Figura 62. Al detectar un choque, el celular entra en modo de alerta automáticamente,
con posibilidad de cancelar la misma en caso de un falso positivo
Figura 63. En caso de que la alerta no haya sido cancelada, se procede a enviar los mensajes UDS,
EDS y un archivo comprimido con los datos de los sensores
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 168
5.37 Diagrama de Entity Framework
A continuación se muestra el diagrama de entidades de Entity Framework creado a partir de
la base de datos. Este diagrama fue creado automáticamente en Microsoft Visual Studio 2010
y luego se puede ir corrigiendo para adaptarlo a las necesidades particulares de la aplicación.
Figura 64.1. Diagrama de Entity Framework
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 169
Figura 64.2. Diagrama de Entity Framework
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 170
Figura 64.3. Diagrama de Entity Framework
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 171
Figura 64.4. Diagrama de Entity Framework
5.38 Creación de un registro Crash
Cada vez que llega un mensaje UDS al servidor se intenta ver si no hubo otro que pertenezca a
alguien involucrado en el mismo choque. Para esto se ha creado un trigger el cual calcula la
distancia reportada entre ambos mensajes UDS y el tiempo reportado entre ambos. Si es
menor que un threshold, un umbral, entonces se asume que es el mismo y se les asigna y/o
crea el mismo registro en la tabla Crash, sino se crean dos registros separados.
El trigger tiene el siguiente código T-SQL
USE [GdpTesisDatabase] GO SET ANSI_NULLS ON GO
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 172
SET QUOTED_IDENTIFIER ON GO ALTER TRIGGER [dbo].[ti_UDSMessage] ON [dbo].[UdsMessage] AFTER INSERT AS BEGIN SET NOCOUNT ON; DECLARE @SAME_CRASH_TIME_LIMIT INT SET @SAME_CRASH_TIME_LIMIT = 10 -- if the crash was up to 10 minutes after then it could be the same crash. DECLARE @SAME_CRASH_DISTANCE_LIMIT INT SET @SAME_CRASH_DISTANCE_LIMIT = 50 -- if the crash was up to 50 meters of distance then it could be the same crash. DECLARE @NEW_CRASH_DATE datetime2 DECLARE @NEW_LATITUDE float DECLARE @NEW_LONGITUDE float SELECT @NEW_CRASH_DATE =(SELECT CrashDate FROM INSERTED) SELECT @NEW_LATITUDE =(SELECT Latitude FROM INSERTED) SELECT @NEW_LONGITUDE =(SELECT Longitude FROM INSERTED) SELECT CrashId,IncidentDateTime,Latitude,Longitude into #ExistingCrashData FROM Crash WHERE datediff(mi,Crash.IncidentDateTime,@NEW_CRASH_DATE) < @SAME_CRASH_TIME_LIMIT AND dbo.fs_CalculateDistance (Crash.Latitude,Crash.Longitude,@NEW_LATITUDE,@NEW_LONGITUDE,'Meters') < @SAME_CRASH_DISTANCE_LIMIT DECLARE @count int SELECT @count = count(*) FROM #ExistingCrashData IF (@count > 0) BEGIN UPDATE a SET CrashId = (SELECT CrashId FROM #ExistingCrashData) FROM UDSMessage a INNER JOIN INSERTED b on a.UDSMessageID = b.UDSMessageID END ELSE BEGIN INSERT INTO [dbo].[Crash] ([IncidentDateTime],[IncidentReceivedDateTime],[Latitude],[Longitude], [CrashProfileId])
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 173
VALUES (@NEW_CRASH_DATE,getdate(),@NEW_LATITUDE,@NEW_LONGITUDE,0) UPDATE UDSMessage SET CrashId = @@IDENTITY WHERE UDSMessageID = (SELECT UDSMessageId FROM INSERTED) END END
5.39 Diagramas de la aplicación Android
Paquetes
Figura 65. Paquetes
GdptTesis.client.activities
Figura 66. GdpTesis.client.activities
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 174
GDPTESIS.CLIENT.APPLICATION
Figura 67. GdpTesis.client.application
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 175
GDPTESIS.CLIENT.BROADCASTRECEIVERS
Figura 68. GdpTesis.client.broadcastReceivers
GDPTESIS.CLIENT.COMM UNICATION
Figura 69. GdpTesis.client.communication
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 176
GDPTESIS.CLIENT.CRASH
Figura 70. GdpTesis.client.crash
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 177
GDPTESIS.CLIENT.DB
Figura 71. GdpTesis.client.db
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 178
GdpTesis.client.location
Figura 72. GdpTesis.client.location
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 179
GdpTesis.client.message
Figura 73. GdpTesis.client.message
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 180
GDPTESIS.CLIENT.SENSORS
Figura 74. GdpTesis.client.sensores
GDPTESIS.CLIENT.UNIT S
Figura 75. GdpTesis.client.units
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 181
C A P Í T U L O 6
6.1 Conclusiones y Líneas de investigación futura
Durante el desarrollo de la presente tesis se hizo una introducción acerca de un nuevo
concepto para desarrollar en Argentina, el de la detección automática de choques mediante un
dispositivo móvil e informar instantáneamente a los servicios de emergencias para que estos
puedan llegar lo más rápido posible, posibilitando la ayuda para salvar vidas y mitigar las
heridas. Este pedido de ayuda parte directamente del herido en cuestión, sin necesidad
externa de informar acerca del incidente. Además, casos como el de la familia Pomar [66] en
Argentina, demuestran que si un integrante del automóvil hubiese contado con un celular con
el software instalado y esta arquitectura hubiese estado implementada, se habría ahorrado
mucho tiempo y recursos de todo tipo: económicos, policíacos, bomberos, etc. ya que
estuvieron más de veinte días buscándolos sin saber su paradero cuando se podría haber
sabido en ese mismo instante la posición exacta del accidente, de esta manera, el haber
recibido ayuda médica más rápido podría haberles salvado la vida.
En el capítulo 1 se hizo una introducción a qué es el AACN y cómo funciona en los países que
lo tienen en uso (con proveedores como OnStar en Estados Unidos) y países que lo están
desarrollando, como los pertenecientes a la Unión Europea (con eCall). Luego, en los
siguientes capítulos, se dio una introducción a la navegación satelital, y se explicó cómo puede
hacer un dispositivo móvil para encontrar su propia posición y los errores asociados a la
obtención de la misma para luego poder compartirla con la aplicación.
Se mostraron los distintos estándares que existen con respecto a la estandarización del envío
de alertas y cómo mediante ésta, la posibilidad de crear reportes que lleven a mejoras
sustanciales es posible y no que haya discrepancias y/o incompatibilidades entre las fuentes
de información.
Se analizaron los protocolos necesarios para que los datos sean útiles para otros sistemas y se
puedan compartir y recibir también.
Finalmente, se propuso una arquitectura viable en el presente para poder llevar a cabo cuanto
antes una implementación en Argentina y poder reducir las muertes en las rutas y/o mitigar
las heridas sufridas en accidentes de tránsito.
También se demostró cómo se pueden utilizar los sensores embebidos en los dispositivos
móviles como celulares, tablets, etc. modernos para poder llevar a cabo la detección de un
choque, la tecnología necesaria para obtener la posición del mismo y la tecnología necesaria
para poder realizar una comunicación entre este y el servidor de forma estandarizada. Si se
pudiese llegar en un futuro a crear en el instante un índice que advierta la gravedad de las
personas con los datos obtenidos de los sensores del dispositivo móvil, se podrían optimizar
incluso más los recursos enviando a hospitales de trauma sólo a las personas que revistan
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 182
posibilidad de heridas moderadas o graves y los que sólo tengan heridas leves se pueden
enviar a hospitales que no sean de trauma, optimizando aún más los recursos hospitalarios.
Para esto, sería importante la obtención de la información de la computadora de abordo,
quizás creando una interfaz inalámbrica o usando una existente, para que la información
pueda ser consumida por un dispositivo móvil y así enviar junto a los mensajes UDS y EDS la
información más completa.
Es importante ahondar en estos dos puntos. El primero es un algoritmo similar al Urgency
(explicado debajo) y el segundo la conexión con la computadora de abordo para poder
obtener más datos acerca del choque y el estado del auto en particular (también más
explicado debajo).
El primero consiste asignar un índice de gravedad de las lesiones automáticamente y luego
asignar recursos de ayuda al accidente y derivar a los pacientes a distintos hospitales (por
ejemplo de trauma o uno que no lo sea) de acuerdo a la gravedad que se predijo mediante el
índice. Muchas veces un accidentado puede decir que está bien él u otra persona por no ver
heridas externas, sin embargo, las más peligrosas, las internas, podrían requerir atención
urgente y el índice indicaría la probabilidad de que éstas hayan ocurrido. En USA se usa el
algoritmo Urgency (explicado más adelante), en Argentina se debería analizar (de ser
necesaria) la adaptación del mismo con los datos que se puedan obtener sin los sensores
embebidos de OnStar por ejemplo, o crear uno propio luego de su estudio por profesionales
de la salud y expertos en seguridad vial, entre otros.
El segundo consiste básicamente poder conectar el dispositivo móvil de forma inalámbrica de
ser posible con la computadora de abordo (Ver OBD-II debajo) y de esta forma poder obtener
más datos para enviar al servidor, incluso se podría avisar al ocupante si antes de emprender
un viaje algún elemento del auto no se encuentra en condiciones para poder evitar
emprenderlo sin arreglarlo con anterioridad. Además esto ayudaría a crear un índice como el
Urgency pero adaptado a los datos disponibles meidante los sensores del celular y los datos
obtenidos de la computadora de abordo.
Mediante el estudio e implementación de estos dos conceptos, la identificación de causas y
consecuencias de los accidentes de tráfico podrían ser más precisas, mitigando las heridas
sufridas por los accidentes de tráfico y ayudando a evitar muertes. Esto podría hacerse por
ejemplo mediante el análisis de choques pasados y creando nuevas alternativas en materia de
seguridad vial (desde nuevos carteles hasta desplegar nueva tecnología) para evitarlos.
Sería importante también poder estudiar en conjunto con físicos y matemáticos formas de
mejora del algoritmo que hace uso de los sensores para saber si hubo o no un choque y la
mejor forma de obtener cómo fue el mismo mediante los datos de los sensores que tiene el
dispositivo móvil y son enviados al servidor.
Sería interesante investigar también las redes MANET (Mobile Ad-Hoc Network), las cuales
son redes de dispositivos conectados de forma inalámbrica y que poseen propiedades de
auto-configuración, además de poseer cierta movilidad (es decir se encuentran montados en
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 183
plataformas móviles) [61] y el de las redes VANET (Vehicular Ad-Hoc Network), cuyo objetivo
es desarrollar plataformas de comunicación entre vehículos en movimiento y entre éstos y la
infraestructura vial. Ambas redes tienen sus propios campos de investigación, protocolos, etc.
Mediante la conjunción de este tipo de redes se podría llegar a mitigar las congestiones
vehiculares en gran medida advirtiendo dónde hay más problemas y todo esto se haría de
forma dinámica ya que “las redes Ad-Hoc se caracterizan por no tener una infraestructura,
sino que los mismos nodos se encargan de organizarse para formar una topología de
comunicación”[62], de esta manera, todos los dispositivos móviles podrían comunicarse entre
si para poder recibir al instante una información de choque y así poder evitar lugares
congestionados. Sería interesante luego poder extender esto a otros tipos de alertas.
Por último una investigación profunda sobre cómo reproducir el choque a partir de los datos
de los sensores como acelerómetro, giróscopo, etc. sería muy útil e importante para poder
brindar dispositivos que sean más seguro a partir del análisis de los datos y beneficiar a las
compañías de seguros para que sepan cómo fueron los sucesos.
6.2 Algoritmo Urgency
El algoritmo URGENCY usa los datos del sensor de choque del vehículo en los sistemas
equipados con Automatic Crash Notification para asistir en la identificación instantánea de
choques donde la probabilidad de heridas graves sea más alta y donde el tiempo desde que
ocurre el accidente hasta que se atiende a los accidentados es crítico. El algoritmo también
provee la habilidad de mejorar la identificación de la lesión, usando datos obtenidos de la
escena del choque. El objetivo primario del algoritmo es proveer automáticamente respuesta
médica de emergencia con información objetiva en la severidad del choque para asistir en la
detección del aproximadamente 1% de los choques con lesiones serias que necesitan el
cuidado médico más urgente. El algoritmo calcula el riesgo de lesiones MAIS 3+ (Maximum
Abbreviated Injury Scale) [63] presentes en el vehículo chocado instantáneamente en el
momento del choque. La predicción puede ser actualizada subsecuentemente a medida que se
obtiene más información. El algoritmo estaba basado en un análisis de regresión múltiple
usando datos del National Accident Sampling System/Crashworthiness Data System,
(NASS/CDS) de los años 1988-95. En aquel documento, la exactitud del algoritmo estaba
evaluada para choques laterales aplicándolo retrospectivamente a la población de ocupantes
lesionados en el NASS 1997-2000. URGENCY fue aplicado a la población de ocupantes
lesionados en choques laterales. Usando un criterio de riesgo de lesión del 50%, URGENCY
identificó 69% de los choques con lesiones MAIS 3+. Bajando el criterio de riesgo a 40%,
URGENCY identificó 78% de los choques con lesiones MAIS 3+. Luego cambiando algunas
variables, los choques correctamente identificados se incrementaron de 69% a 81%. Un
examen de la consecuencia de las variables faltantes arrojó que valores desconocidos de peso
y altura de los ocupantes tenían un efecto insignificante sobre la habilidad para captar heridos
MAIS 3+. Sin embargo, la falta de conocimiento de estas variables sí incrementó la magnitud
de los falsos positivos.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 184
Código MAIS Heridas
0 No lesionado
1 Lesiones menores
2 Lesiones moderadas
3 Lesiones serias
4 Lesiones severas
5 Lesiones críticas
6 Máximo
9 No especificado
Tabla 1 - Maximum Abbreviated Injury Scale (MAIS) es una escala creada por la American Association for Automotive Medicine,
la cual clasifica y describe la severidad de las heridas de los individuos
La meta del Urgency es enviar a las personas con lesiones graves a un centro de trauma
mientras se minimiza la subcategorización de una lesión seria y sobre-categorización de la
lesión leve, transportando personas que no tienen lesiones serias a un centro de trauma
innecesariamente.
Intervalos de Tiempos Víctimas % del Intervalo de
Tiempo
Del choque a la notificación al EMS: <1 min. 9,195 22%
>1 min. 15,852 38%
Tiempos Desconocidos + Cuestionables 16,424 40%
Del choque al arribo a la escena del EMS: <10
min.
12,161 29%
>10
min.
14,362 35%
Tiempos Desconocidos + Cuestionables 14,948 36%
Del choque al arribo al Hospital: <45
min.
5,211 13%
>45
min.
3,166 8%
Tiempos no tomados + desconocidos +
Cuestionables
33,094 79%
Tabla 2. Víctimas de choques por Tiempos Reportados por los EMS (1998)
Los tiempos en negrita en la tabla indican víctimas en los cuales los tiempos
transcurridos reportados exceden los benchmarks de un 1 minuto para la
notificación de EMS, 10 minutos para el arribo a escena de los EMS, y 45
minutos para el arribo al hospital en choques fatales.
Las víctimas en cada intervalo de tiempo es igual a 41,471 (100%) y las víctimas no
pueden ser sumadas entre los intervalos de tiempo.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 185
Se estimó que las reducciones en los tiempos promedio de notificación de choques desde 9
minutos a 1 minuto luego del choque podrían salvar potencialmente 3000 vidas por año entre
los choques en caminos rurales en Estados Unidos. Cuando todos los tiempos de notificación
de choques se reducen a 1 minuto, el número de vidas salvadas puede esperarse que sea
mayor.
Benchmarks de la “Golden Hour” para heridos graves
Tiempo desde el choque hasta:
Notificación a EMS: < 1 minuto
Arribo de EMS a la escena: < 10 minutos
Arribo al hospital: < 45 minutos
Cuidado definitivo: < 60 minutos
La performance que se obtuvo en 2002 para los accidentes en Estados Unidos en zonas
rurales fue:
Tiempos Benchmarks Promedio *
Notificación a EMS < 1 minuto 7 minutos
Arribo a la escena < 10 minutos 18 minutos
Arribo al hospital < 45 minutos 53 minutos
Cuidado definitivo < 60 minutos 68 minutos Tabla 3
* Tiempos promedio para choques con tiempos <= 120 minutos
Aquí se ve que era necesario reducir los tiempos promedio en:
Tiempos Benchmarks Necesario
Notificación a EMS < 1 minuto -6 minutos
Arribo a la escena < 10 minutos -8 minutos
Arribo al hospital < 45 minutos -8 minutos
Cuidado definitivo < 60 minutos -8 minutos Tabla 4
Posibles mejoras identificadas para poder llegar a cumplir con las restricciones de tiempos:
Tiempos Reducción necesaria Posible con
Notificación a EMS -6 minutos ACN
Arribo a la escena -8 minutos ACN + URGENCY
Arribo al hospital -8 minutos Servicios Médicos Aéreos
Cuidado definitivo -8 minutos Sistemas de Trauma (AACN+URGENCY+Transporte Aéreo)
Tabla 5. Mejoras posibles
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 186
Figura 76. Usando los datos de FARS 2002, se puede ver que el porcentaje de fatalidades de personas no llevadas para
tratamiento medico se incrementa a medida que se incrementa el tiempo entre el choque y la notificación a los servicios de
emergencia mientras que el porcentaje de los que fueron llevados para tratamiento médico disminuyó [71]
Algunos ejemplos de ítems que modificarían el índice:
Si está atrapado o no –si un ocupante está atrapado en el vehículo, el riesgo de
heridas graves se acerca al triple acercándose al 75% si se asume un choque base que
se asume con un 25% de probabilidades de una herida grave. Debido a esto el que esté
atrapado o no es una alarma de que los ocupantes pueden tener heridas graves.
Expulsión parcial o completa– Si hay una expulsión de un ocupante del vehículo, la
probabilidad de una herida grave se aproxima al doble llegando al 50% de una herida
grave.
6.3 Computadoras de abordo
6.3.1 OBD-II
OBD II es la abreviatura de On Board Diagnostics (Diagnóstico de Abordo) II, la segunda
generación de los requerimientos del equipamiento autodiagnosticable de abordo de los
Estados Unidos. Actualmente se emplean: OBD-I - OBD-II (Estados Unidos), EOBD (Europa), y
JOBD (Japón) que aportan un control casi completo del motor y otros dispositivos del
vehículo. Las características de autodiagnóstico de abordo están incorporadas en el hardware
y el software de la computadora de abordo de un vehículo para monitorear prácticamente
todos los componentes que pueden afectar las emisiones. Cada componente es monitoreado
por una rutina de diagnóstico para verificar si está funcionando perfectamente. Si se detecta
un problema o una falla, el sistema de OBD II ilumina una lámpara de advertencia en el cuadro
de instrumentos para avisarle al conductor. La lámpara de advertencia normalmente lleva la
inscripción "Check Engine" o "Service Engine Soon". El sistema también guarda informaciones
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 187
importantes sobre la falla detectada para que un mecánico pueda encontrar y resolver el
problema.
[64] El sistema OBD-II permite el monitoreo de la mayoría de los sistemas eléctricos del
vehículo. Se puede monitorear, entre otras cosas, velocidad, RPM, voltaje de ignición,
diferentes temperaturas de los elementos.
El sistema también puede informar cuando un cilindro individual tiene un problema.
[65] Los automóviles actuales, incorporan una gran cantidad de sensores, que permiten
conocer a las ECU (Engine Control Unit), cuales son las condiciones externas, y decidir cómo
actuar sobre el motor. En caso de que alguno de los parámetros se salga de los rangos
establecidos, el sistema OBD II, es el encargado de almacenar esta información, y avisar al
conductor de que algo sufre un mal funcionamiento, señalizando con un indicador luminoso
que es recomendable ir al taller a revisar qué error se ha producido.
Luego se pueden encontrar múltiples protocolos, como ser: ISO14230-4, ISO 15756-4, J1850
PWM, ISO 9141-2, ISO CAN, ALDL, etc. Cada fabricante puede usar otro.
Los datos del OBD-II pueden ser obtenidos mediante una interfaz OBD II – Wifi, a
continuación se muestran algunas de las interfaces disponibles actualmente en el mercado.
Figura 77. Distintos adaptadores OBD II a Wifi [68][69]
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 188
Figura 78. Conector OBD-II [70]
6.3.2 EOBD
EOBD es la abreviatura de European On Board Diagnostics (Diagnóstico de a Bordo Europeo),
la variación europea de OBD II. Una de las diferencias es que no se monitorean las
evaporaciones del tanque. Sin embargo, EOBD es un sistema mucho más sofisticado que OBD
II ya que usa "mapas" de las entradas a los sensores basados en las condiciones de operación
del motor, y los componentes se adaptan al sistema calibrándose empíricamente. Esto
significa que los repuestos necesitan ser de alta calidad y específicos para el vehículo y
modelo.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 189
A P E N D I C E
Datos obtenidos en las pruebas
Los siguientes valores fueron tomados con el programa desarrollado en Android y probados
en un celular Samsung Galaxy S2.
Se tomaron conjuntos de valores en cada actividad al azar, pero que contengan el mayor de
los valores de la fuerza G obtenida.
Aquí sólo se tomaron en cuenta los sensores Accelerometer, Gravity y LinearAcceleration ya
que se buscaba obtener el valor de la fuerza G solamente.
CORRIENDO CON EL CELULAR EN EL BOLSILLO DEL PANTALÓN
Sensor Valor X Valor Y Valor Z Fuerza G
Gravity 6.108088 8.135109 -0.80758 1.040615
LinearAcceleration 8.69723 7.50105 13.6107 2.816008
Gravity 6.50587 8.137579 -0.47137 1.063485
LinearAcceleration 10.68301 9.391809 8.289453 2.678813
Accelerometer 18.38747 15.47272 0.544814 2.451142
Gravity 6.826512 8.065655 -0.15569 1.077625
LinearAcceleration 11.56096 7.407061 0.700507 2.401919
Gravity 7.085563 7.948263 0.145645 1.085896
LinearAcceleration 11.91482 2.36234 -1.49406 2.247959
Gravity 7.305421 7.814632 0.436079 1.091753
LinearAcceleration 4.339976 -3.11561 -2.49275 1.601168
Accelerometer -1.79789 -1.62082 -2.87389 0.383157
Gravity 7.508543 7.688008 0.713163 1.098231
LinearAcceleration -9.30643 -9.30883 -3.58706 2.391197
Gravity 7.708671 7.579385 0.970604 1.106816
LinearAcceleration -18.3462 -16.5688 -5.80583 3.589386
Gravity 7.904022 7.485806 1.198913 1.116802
LinearAcceleration -15.6404 -15.5082 -7.47789 3.371897
Accelerometer -10.3651 -4.86246 -10.0518 1.553579
Gravity 8.077127 7.391973 1.386273 1.125404
LinearAcceleration -18.4422 -12.2544 -11.4381 3.541358
Gravity 8.20064 7.276434 1.519287 1.128643
LinearAcceleration -20.0367 -7.39902 -11.5711 3.477105
Gravity 8.243803 7.118794 1.583753 1.122363
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 190
LinearAcceleration -16.8246 -5.70228 -7.99894 2.98666
Accelerometer -5.81589 0.980665 -4.0861 0.73166
Gravity 8.177501 6.904776 1.567049 1.103006
LinearAcceleration -13.9934 -5.92411 -5.65315 2.653287
Gravity 7.981019 6.629053 1.462668 1.068419
LinearAcceleration -12.5166 -5.66201 -4.79965 2.483889
Gravity 7.644597 6.293477 1.271391 1.018002
LinearAcceleration -10.1235 -3.2289 -3.68219 2.14676
Accelerometer 6.959998 9.084772 -0.29965 1.167406
Gravity 7.169039 5.905062 1.000066 0.952575
LinearAcceleration -0.20904 3.17971 -1.29971 1.350929
LOMO DE BURRO CON EL CELULAR EN UN HOLDER
Sensor Valor X Valor Y Valor Z Fuerza G
LinearAcceleration 1.541985 0.061036 0.806323 1.177548
Accelerometer 11.52281 0.735499 1.334794 1.185233
Gravity 9.884451 -0.30851 0.590438 1.01022
LinearAcceleration 1.638363 1.044008 0.744356 1.212146
Accelerometer 10.76008 -0.61292 0.78998 1.101949
Gravity 10.24563 -0.29262 0.623202 1.047119
LinearAcceleration 0.51445 -0.3203 0.166778 1.064093
Accelerometer 8.771504 -0.8036 0.667397 0.900765
Gravity 10.59779 -0.239 0.74874 1.083642
LinearAcceleration -1.82629 -0.5646 -0.08134 1.195102
Accelerometer 8.090487 0.40861 -0.95342 0.831753
Gravity 10.84397 -0.17879 0.890911 1.109652
LinearAcceleration -2.75348 0.587396 -1.84434 1.343211
Accelerometer 7.654635 0.054481 -1.56634 0.796749
Gravity 10.88562 -0.13978 0.962414 1.114445
LinearAcceleration -3.23098 0.194264 -2.52875 1.418849
Accelerometer 8.471856 -0.72188 -1.10325 0.874288
Gravity 10.66748 -0.12348 0.886885 1.091605
LinearAcceleration -2.19562 -0.5984 -1.99013 1.308276
Accelerometer 8.185829 0.054481 -0.7355 0.838103
Gravity 10.21999 -0.12095 0.636054 1.044238
LinearAcceleration -2.03416 0.175435 -1.37155 1.250812
Accelerometer 10.2425 -0.21793 -0.34051 1.045258
Gravity 9.654664 -0.1296 0.255084 0.984934
LinearAcceleration 0.587837 -0.08833 -0.59559 1.085807
Accelerometer 10.51491 -0.17706 0.136203 1.072464
Gravity 9.126377 -0.14625 -0.15564 0.930886
LinearAcceleration 1.388532 -0.03082 0.29184 1.144719
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 191
Accelerometer 9.234595 0.258787 0.38137 0.942839
Gravity 8.777384 -0.16267 -0.48819 0.896581
LinearAcceleration 0.457212 0.421461 0.869557 1.10901
Accelerometer 9.711308 -0.38137 0.38137 0.991804
DOBLANDO RÁPIDO CON EL AUTO Y EL CELULAR EN UN HOLDER
Sensor Valor X Valor Y Valor Z Fuerza G
LinearAcceleration 1.541985 0.061036 0.806323 1.177548
Accelerometer 11.52281 0.735499 1.334794 1.185233
Gravity 9.884451 -0.30851 0.590438 1.01022
LinearAcceleration 1.638363 1.044008 0.744356 1.212146
Accelerometer 10.76008 -0.61292 0.78998 1.101949
Gravity 10.24563 -0.29262 0.623202 1.047119
LinearAcceleration 0.51445 -0.3203 0.166778 1.064093
Accelerometer 8.771504 -0.8036 0.667397 0.900765
Gravity 10.59779 -0.239 0.74874 1.083642
LinearAcceleration -1.82629 -0.5646 -0.08134 1.195102
Accelerometer 8.090487 0.40861 -0.95342 0.831753
Gravity 10.84397 -0.17879 0.890911 1.109652
LinearAcceleration -2.75348 0.587396 -1.84434 1.343211
Accelerometer 7.654635 0.054481 -1.56634 0.796749
Gravity 10.88562 -0.13978 0.962414 1.114445
LinearAcceleration -3.23098 0.194264 -2.52875 1.418849
Accelerometer 8.471856 -0.72188 -1.10325 0.874288
Gravity 10.66748 -0.12348 0.886885 1.091605
LinearAcceleration -2.19562 -0.5984 -1.99013 1.308276
Accelerometer 8.185829 0.054481 -0.7355 0.838103
Gravity 10.21999 -0.12095 0.636054 1.044238
LinearAcceleration -2.03416 0.175435 -1.37155 1.250812
Accelerometer 10.2425 -0.21793 -0.34051 1.045258
Gravity 9.654664 -0.1296 0.255084 0.984934
LinearAcceleration 0.587837 -0.08833 -0.59559 1.085807
Accelerometer 10.51491 -0.17706 0.136203 1.072464
Gravity 9.126377 -0.14625 -0.15564 0.930886
LinearAcceleration 1.388532 -0.03082 0.29184 1.144719
Accelerometer 9.234595 0.258787 0.38137 0.942839
Gravity 8.777384 -0.16267 -0.48819 0.896581
LinearAcceleration 0.457212 0.421461 0.869557 1.10901
Accelerometer 9.711308 -0.38137 0.38137 0.991804
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 192
CONDUCCIÓN NORMAL CON EL CELULAR EN UN HOLDER
Sensor Valor X Valor Y Valor Z Fuerza G
LinearAcceleration 0.307936 -1.72063 -1.75494 1.252577
Accelerometer 0.640156 12.21745 -0.74912 1.249879
Gravity -0.10659 9.936916 0.138546 1.01344
LinearAcceleration 0.746748 2.280536 -0.88766 1.260904
Accelerometer -0.17706 11.29127 1.116869 1.157149
Gravity -0.01889 9.913578 0.097368 1.010954
LinearAcceleration -0.15818 1.37769 1.0195 1.175511
Accelerometer 0.585675 9.534244 -0.44947 0.975133
Gravity 0.068253 9.915038 0.052638 1.011091
LinearAcceleration 0.517422 -0.38079 -0.50211 1.083146
Accelerometer -1.04877 8.267551 1.661682 0.86654
Gravity 0.141651 9.979177 0.013558 1.017696
LinearAcceleration -1.19042 -1.71163 1.648124 1.271004
Accelerometer -1.34841 7.763598 3.187161 0.866757
Gravity 0.17695 10.05566 0.02125 1.025552
LinearAcceleration -1.52536 -2.29206 3.165912 1.427835
Accelerometer -1.6072 8.757884 1.57996 0.922152
Gravity 0.137032 10.04205 0.132942 1.024189
LinearAcceleration -1.74423 -1.28416 1.447019 1.265622
Accelerometer 0.640156 11.74074 1.062387 1.203885
Gravity -0.00302 9.886478 0.384009 1.0089
LinearAcceleration 0.643174 1.854261 0.678378 1.211752
Accelerometer 0.40861 11.48195 -0.76274 1.174153
Gravity -0.21156 9.65608 0.72917 0.987685
LinearAcceleration 0.620171 1.825872 -1.49191 1.248615
Accelerometer -0.58567 10.54215 -0.51757 1.077951
Gravity -0.40452 9.496772 1.045191 0.975121
LinearAcceleration -0.18116 1.045378 -1.56276 1.192612
Accelerometer -0.23155 9.547864 1.225831 0.981887
Gravity -0.51114 9.512614 1.206813 0.97918
LinearAcceleration 0.279591 0.03525 0.019018 1.028801
Accelerometer -0.53119 9.629586 0.39499 0.984262
CAÍDA LIBRE SOBRE UN SILLÓN
Sensor Valor X Valor Y Valor Z Fuerza G
Gravity 8.311835 8.108137 -0.96975 1.188173
LinearAcceleration -3.8035 -2.78258 -1.01883 1.491662
Gravity 8.557552 8.450329 -1.11195 1.231605
LinearAcceleration -4.62127 -8.51843 0.499033 1.989539
Gravity 8.729984 8.809717 -1.25846 1.271204
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 193
LinearAcceleration -6.27832 -9.76314 0.33228 2.18413
Accelerometer 1.688923 -1.7434 -2.24736 0.337317
Gravity 8.823792 9.162176 -1.40122 1.304951
LinearAcceleration -7.13487 -10.9056 -0.84613 2.331712
Gravity 8.837637 9.47888 -1.53363 1.330739
LinearAcceleration -8.98746 -12.203 -1.84422 2.556822
Gravity 8.77042 9.731274 -1.65176 1.346436
LinearAcceleration -12.1483 -13.8855 -0.82714 2.883223
Accelerometer -6.21088 -4.99867 0.463092 0.814345
Gravity 8.621717 9.893311 -1.754 1.350068
LinearAcceleration -14.8326 -14.892 2.217092 3.15518
Gravity 8.389978 9.943079 -1.83938 1.339831
LinearAcceleration -11.8632 -12.7353 6.157028 2.882558
Gravity 8.072954 9.864155 -1.90477 1.314217
LinearAcceleration -0.05057 -1.54212 13.82258 2.418265
Accelerometer 13.81103 13.86551 15.71788 2.559567
Gravity 7.676981 9.654806 -1.9423 1.273314
LinearAcceleration 6.134052 4.210708 17.66018 2.95413
Gravity 7.215972 9.325188 -1.93758 1.21848
LinearAcceleration 4.347703 2.361071 10.27323 2.162729
Gravity 6.714383 8.899761 -1.87322 1.152765
LinearAcceleration -4.14014 -3.87385 7.634631 1.969723
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 194
R E F E R E N C I A S
Verifica que los números de referencias sean correctos(correspondan en el texto con esta
lista)
[1] Telematics Today and Tomorrow – Bob Lange – General Motors.
[2] El Sistema de Llamada de Emergencia (E-CALL) Vol.7, Fundación Instituto Tecnológico
para la Seguridad del Automóvil (FITSA)
[3] Advanced Automatic Crash Notification (AACN), 2005 Computerworld Honors Case Study
[4] eCall Discussion Paper. Finnish eCall Experts 6.6.2005
[5] eCall Communications Test Bench – Structure and Content of MSD, FDS and MDS
Messages, http://www.ecall.fi/eCall_msd_en_052009.pdf
[6] Impacts of an automatic emergency call system on accident consequences, Niina Virtanen,
Anna Schirokoff, Juha Luoma VTT Technical Research Centre of Finland
[7] Tracking a suspect by mobile phone. BBC News.
http://news.bbc.co.uk/2/hi/technology/4738219.stm
[8] Recommendations for the introduction of the pan-European eCall. On behalf of DG eCall
Michael Nielsen Co-Chair – DG eCall. Plenary Meeting of the eSafety Forum 2-3 May 2006
[9] Ministry of Transport and Communications of Finnland -
http://www.lvm.fi/web/en/home
[10] eCall Initiative. Airbiquity
http://docbox.etsi.org/MSG/eCall/MSG_eCall_kickoff/Documents/M-05-026.pdf
[11] EM 1110-1-1003. NAVSTAR GPS Positioning Surveying. Chapter 2 Operational Theory of
NAVSTAR GPS, 28 Feb 11. US Army Corps of Engineers. Army Geospatial Center.
http://140.194.76.129/publications/eng-manuals/EM_1110-1-1003_pfl/ch_02.pdf
[12] http://www.kowoma.de/en/gps/data_composition.htm
[13] Transmitted GPS Signals. http://www.kowoma.de/en/gps/signals.htm
[14] The GPS System. http://www.kowoma.de/en/gps/waas_egnos.htm
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 195
[15] The GPS System. Sources of Errors in GPS. http://www.kowoma.de/en/gps/errors.htm
[16] http://es.wikipedia.org/wiki/GPS_Asistido
[17] http://en.wikipedia.org/wiki/High_Sensitivity_GPS
[18] How Location Services Work on Mobile Devices.
http://anders.com/cms/389
[19] Assisted GPS: A Low-Infrastructure Approach. GPS World The Business and Technology
of Global Navigation and Positioning.
http://www.gpsworld.com/gps/assisted-gps-a-low-infrastructure-approach-734
[20] http://en.wikipedia.org/wiki/Urban_canyon
[21] GPS vs. aGPS: A Quick Tutorial. Wpcentral.
http://www.wpcentral.com/gps-vs-agps-quick-tutorial
[22] http://mobilitysite.com/wp-content/uploads/2007/08/a-gps.jpg
[23] http://www.mmucc.us/dataelements/crash-intro.aspx
[24] VEDS - Vehicular Emergency Data Set (2004), ComCARE Alliance ACN Data Set Working
Group.
http://xml.coverpages.org/ComCARE-VEDSv20-2004.pdf
[25] Common Alerting Protocol Version 1.2, OASIS Standard, 01 July 2010.
http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.pdf
[26] IEEE Incident Management Working Group (1512®)
http://grouper.ieee.org/groups/scc32/imwg/
[27] http://www.oasis-open.org/committees/download.php/17227/EDXL-
DE_Spec_v1.0.html
[28] Web Services Security: SOAP Message Security 1.0 (WS-Security 2004). OASIS.
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-
1.0.pdf
[29] OASIS Web Services Security (WSS) TC
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
[30] ICC = Integrated Circuit Card. Más información en
http://en.wikipedia.org/wiki/Smart_card
[31] Android Developers.
http://developer.android.com/reference/android/hardware/SensorEvent.html
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 196
[32] Feasibility of a 802.11 VANET Based Car Accident Alert System. Scott J. Weiner, Gunar
Schirner. Northeastern University Program: Computer Engineering
http://www.ieee.org/documents/weiner_feasibility_802.11.pdf
[33] ECall-compliant early crash notification service for portable and nomadic devic. Carolina
Pinart, J. Carlos Calvo, Laura Nicholson and José A. Villaverde. Telefónica I+D – Networked
Vehicles Division. Madrid SPAIN. Massachusetts Institute of Technology (MIT)
[34] Servicio general de paquetes vía radio
http://es.wikipedia.org/wiki/Servicio_general_de_paquetes_vía_radio
[35] Enhanced Data Rates for GSM Evolution
http://es.wikipedia.org/wiki/EGPRS
[36] Universal Mobile Telecommunications System
http://es.wikipedia.org/wiki/UMTS
[37] High-Speed Downlink Packet Access
http://es.wikipedia.org/wiki/High-Speed_Downlink_Packet_Access
[38] Long Term Evolution
http://es.wikipedia.org/wiki/Long_Term_Evolution
[39] European Commission.
http://ec.europa.eu/romania/documents/news/lte_informatii_suplimentare.pdf
[40] GSM World Coverage Map and GSM Country List.
http://www.worldtimezone.com/gsm.html
[41] REST Vs Web Services de Rafael Navarro Marset. ELP-DSIC-UPV Modelado, Diseño e
Implementación de Servicios Web 2006-07
[42] Performance Evaluation of RESTful Web Services for Mobile Devices. Hatem Hamad,
Motaz Saad, and Ramzi Abed Computer Engineering Department, Islamic University of Gaza
[43] http://en.wikipedia.org/wiki/Uniform_resource_identifier
[44] http://www.dosideas.com/noticias/java/314-introduccion-a-los-servicios-web-
restful.html
[45] SQL Scheduler. http://www.lazycoding.com/products.aspx
[46] Google I/O 2009, Coding for Life—Battery Life, That Is Jeff Sharkey May 27, 2009
[47] http://en.wikipedia.org/wiki/Comet_%28programming%29
[48] Clarity Consulting. Roll Your Own MVC 3 Long Polling Chat Site. Jacob Gable.
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 197
http://blogs.claritycon.com/blog/2011/04/12/roll-your-own-mvc-3-long-polling-chat-
site
[49] IBM WebSphere Ajax Dev Guide.
http://pic.dhe.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.ajax.
devguide.help/docs/PureAjax_pubsub_clients.html
[50] Microsoft MSDN. Using an Asynchronous Controller in ASP.NET MVC
http://msdn.microsoft.com/en-us/library/ee728598.aspx
[51] Clay Lenhart’s Blog. WebSockets is cool, but what can you do today?
http://clay.lenharts.net/blog/2010/10/19/websockets-is-cool-but-what-can-you-do-
today
[53] How to Use Asynchronous Controllers in ASP.NET MVC2 & MVC3.
http://www.aaronstannard.com/post/2011/01/06/asynchonrous-controllers-ASPNET-
mvc.aspx
[54] Microsoft Data Developer Center. ADO.NET Entity Framework At-a-Glance.
http://msdn.microsoft.com/en-us/data/aa937709
[55] Android Thread Constructs(Part 4): Comparisons
http://techtej.blogspot.com.ar/2011/03/android-thread-constructspart-4.html
[56] Microsoft ASPNET MVC.
http://www.asp.net/mvc
[57] MVC 3 – Razor View Engine.
http://www.asp.net/mvc/videos/mvc-3/mvc-3-razor-view-engine
[58] Google Geo Developers Blog. MarkerClusterer: A Solution to the Too Many Markers
Problem
http://googlegeodevelopers.blogspot.com/2009/04/markerclusterer-solution-to-too-
many.html
[59] Android location provider mock. Pedro Assunção
http://pedroassuncao.com/2009/11/android-location-provider-mock/
[60] Android 10. Android Location Providers - gps, network, passive.
http://android10.org/index.php/articleslocationmaps/226-android-location-providers-
gps-network-passive
[61] Mobile ad hoc network
http://es.wikipedia.org/wiki/Mobile_ad_hoc_network
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 198
[62] Arquitectura de una Plataforma Telemática Integral para el Despliegue de servicios
Ubicuos en el Ambito de los Sistemas Inteligentes de Transporte. José Santa Lozano.
Departamento de Ingeniería de la Información y las Comunicaciones. Universidad de Murcia
[63] Abbreviated Injury Scale
http://en.wikipedia.org/wiki/Abbreviated_Injury_Scale
[64] Real-Time Vehicle Performance Monitoring Using Wireless Networking. William Jenkins,
Ron Lewis, Georgios Lazarou, Joseph Picone and Zachary Rowland Human and Systems
Engineering, Center for Advanced Vehicular Systems Mississippi State University 200
Research Blvd., Mississippi State, Mississippi 39759, USA
[65] OBD II. ETSEIB. Profesor: Juan Manuel Moreno Equilaz Alumno: Pedro Gonzàlez Melis
[66] http://es.wikipedia.org/wiki/Caso_Pomar
[67] http://es.wikipedia.org/wiki/Archivo:SBAS_Service_Areas_2009.png
[68] http://plxdevices.com/product_info.php?id=GSSTWIFI
[69] http://www.wholesale-caraccessories.com/images/l/201205/13367951680.jpg
[70] http://en.wikipedia.org/wiki/EOBD#EOBD
[71] Analisys of Sudden Natural Deaths While Driving wit Forence AutopsyFindings. Yasuki
Motozawa, Honda R&D Co., Ltd./Department of Legal Medicine, Dokkyo University School of
Medicine (Japan), Tomoko Yokoyama Department of Oral and Maxillofacial Surgery, Dokkyo
University School of Medicine (Japan), Masahito Hitosugi, Shogo Tokudome Department of
Legal Medicine, Dokkyo University School of Medicine (Japan). Paper No. 05-0112
http://www-nrd.nhtsa.dot.gov/pdf/esv/esv19/Other/Print%2022.pdf
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 199
B I B L I O G R A F Í A
1. Recommendations from the Expert Panel: Advanced Automatic Collision Notification and
Triage of the Injured Patient. U.S. Department Of Health and Human Services. Centers for
Disease Control and Prevention
2. Advanced Automatic Crash Notification (AACN), 2005 Computerworld Honors Case Study
3. Introduction of the Mazda Advanced Safety Vehicle, Tetsuro Butsuen, Tohru Yoshioka, Ken-
ichi Okuda Technical Research Center, Mazda Motor Corporation
4. Reducing Highway Deaths and Disabilities with Automatic Wireless Transmission of
Serious Injury Probability Ratings from Vehicles in Crashes to EMS. Howard R. Champion,
Research Professor of Surgery, Uniformed Services University of the Health Sciences, Principal
Investigator,
5. ComCARE Alliance Communications for Coordinated Assistance and Response to
Emergencies
6. Telematics Systems Improve Safety on America's Roads
7. http://ec.europa.eu/information_society/activities/esafety/ecall/index_en.htm
8.http://ec.europa.eu/information_society/activities/esafety/doc/ecall/pos_papers_impact_a
ssessm/qualcomm.pdf
9. http://www.esafetysupport.info/en/ecall_toolbox/
10. eCall in Europe, Marie Hansson & Jürgen Bartz Björn Steiger Stiftung, 112 Roundtable
Warsaw, 03.11.2008
11. eCall implementation in Finland, www.ecall.fi
12. 3GPP TS 26.267 V11.0.0. 3rd Generation Partnership Project; Technical Specification
Group Services and System Aspects; eCall Data Transfer; In-band modem solution; General
description (Release 9)
13. European e-Call functional, specifications In Vehicle System, Vehicle Functionality
Working Group (ECIV) (Chair Dr. W. Reinhardt, ACEA)
14. Intelligent Vehicle Safety Systems-eCALL, Cezar Botezatu Faculty of Computer Science for
Business Management, Romanian – American University, Bucharest, Romania and Claudiu
BÂRCĂ Faculty of Computer Science for Business Management, Romanian – American
University, Bucharest, Romania
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 200
15. El Sistema de Llamada de Emergencia (E-CALL) Vol.7, Fundación Instituto Tecnológico
para la Seguridad del Automóvil (FITSA)
16. Tracking a suspect by mobile phone. BBC News.
http://news.bbc.co.uk/2/hi/technology/4738219.stm
17.http://developer.sprint.com/site/global/develop/network_services/lbs/gps_lbs_101/p_lb
s_101.jsp
18. U.S. Coast Guard Navigation Center. http://www.navcen.uscg.gov/
19. Evaluation of Assisted GPS (AGPS) in Weak Signal Environment Using a Hardware
Simulator. M.D. Karunanayake,
20. M.E. Cannon, G. Lachapelle, Position, Location and Navegation (PLAN) group, Department
of Geomatics Engineering, University of Calgary, Canada
21. The NMEA 0183 Protocol
22. Sistema de Posicionamiento Global (GPS): Descripción, Análisis de errores, Aplicaciones y
Futuro. A.Pozo-Ruz*, A.Ribeiro, M.C.García-Alegre, L.García, D.Guinea, F.Sandoval*
23. Using Cors Workshop (Continuously Operating Reference Stations). National Ocenaic and
Atmospheric Administration
24. Assisted GPS for Location Based Services, Joakim Cedergren. Blekinge Institute of
Technology
25. http://www.mmucc.us/dataelements/crash-intro.aspx
26. DD CEN/TS 15722:2009, Road transport and traffic telematics. ESafety. ECall minimum set
of data (MSD)
27. BS EN 15722:2011, Intelligent transport systems. eSafety. eCall minimum set of data
(MSD)
28. http://www.fema.gov/about/programs/disastermanagement/standards/language.shtm
29. http://en.wikipedia.org/wiki/Common_Alerting_Protocol
30. http://www.oasis-open.org/committees/download.php/17227/EDXL-DE_Spec_v1.0.html
31. Professional Android 2 Application Development. Wrox. Reto Meier
Biocinemática del accidente de tráfico, M. R. Jouvencel, Diaz De Santos
32. A Smartphone Based Fall Detector with Online Location Support, Gokhan Remzi Yavuz,
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 201
Mustafa Eray Kocak, Gokberk Ergun, Hande Alemdar, Hulya Yalcin, Ozlem Durmaz Incel, Lale
Akarun, Cem Ersoy, Computer Engineering Department Boğaziçi University, Istanbul, Turkey
33. Motion Processing: The Next Breakthrough Function in Handsets, By Steve Nasiri, Shang-
Hung Lin, David Sachs, and Joseph Jiang InvenSense, Inc.
34. Tegra Android Accelerometer Whitepaper version 5, nVidia
35. Google Tech Talk, August 2, 2010, Sensor Fusion on Android Devices: A Revolution in
Motion Processing, David Sachs, http://www.youtube.com/watch?v=C7JQ7Rpwn2k
36. ECall-compliant early crash notification service for portable and nomadic devic. Carolina
Pinart, J. Carlos Calvo, Laura Nicholson and José A. Villaverde. Telefónica I+D – Networked
Vehicles Division. Madrid SPAIN. Massachusetts Institute of Technology (MIT)
37. Programming Entity Framework Second Edition – O’Reilly - Julia Lerman
38. Professional Android 2 Application Development – Wrox - Reto Meier
39. http://www.gsmarena.com/network-bands.php3?sCountry=ARGENTINA
40. http://www.m2m-module.com/index.php?p=1_2_Technology
41. http://developer.android.com/guide/topics/fundamentals.html
42. http://code.google.com/p/openintents/wiki/SensorSimulator
43. http://developer.android.com
44. http://android-developers.blogspot.com.ar/2011/06/deep-dive-into-location.html
45. http://en.wikipedia.org/wiki/General_Packet_Radio_Service
46. Measuring the Performance of Asynchronous Controllers.
http://blog.stevensanderson.com/2010/01/25/measuring-the-performance-of-
asynchronous-controllers
47. Vehicle Technology Trends in Electronics for the North American Market; Opportunities
for the Taiwanese Automotive Industry. CAR Center for Automotive Research. December 2006
48. Real-Time Vehicle Performance Monitoring Using Wireless Networking. William Jenkins,
Ron Lewis, Georgios Lazarou, Joseph Picone and Zachary Rowland Human and Systems
Engineering, Center for Advanced Vehicular Systems Mississippi State University 200
Research Blvd., Mississippi State, Mississippi 39759, USA
49. http://en.wikipedia.org/wiki/On-board_diagnostics
50. ComCare Alliance. http://www.comcare.org
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 202
51. New Tools to Reduce Deaths and Disabilities by Improving Emergency Care: Urgency
Software, Occult Injury warnings, And Air Medical Services Database. Howard R. Champion,
Research Professor of Surgery, Uniformed Services University of the Health Sciences, Principal
Investigator, Augenstein JS, Professor of Surgery, University of Miami; Blatt AJ, Senior
Scientist, General Dynamics; Cushing B, Surgeon, Maine Medical Center; Digges KH, Professor
of Engineering, George Washington University; Flanigan MC, Physical Scientist, General
Dynamics; Hunt RC, Emergency Physician, CDC; Lombardo LV, Physical Scientist, NHTSA;
Siegel JH, Professor of Surgery, University of Medicine and Dentistry of New Jersey. United
States Paper Number 05-0191
52. Development and Validation of the Urgency Algorithm to Predict Compelling Injuries,
Jeffrey Augenstein, Kennerly Digges, Sandra Ogata, Elana Perdeck, James Stratton. The William
Lehman Injury Research Center. University of Miami School of Medicine, United States of
America. Paper # 352
53. Arquitectura de una Plataforma Telemática Integral para el Despliegue de servicios
Ubicuos en el Ambito de los Sistemas Inteligentes de Transporte. José Santa Lozano.
Departamento de Ingeniería de la Información y las Comunicaciones. Universidad de Murcia
54. WreckWatch: Automatic Traffic Accident Detection and Notification with Smartphones
Jules White, Chris Thompson, Hamilton Turner, Brian Dougherty, and Douglas C. Schmidt.
http://www.dre.vanderbilt.edu/~jules/wreckwatchj.pdf
55. A Roadmap to Emergency Data Standards
http://www.incident.com/cookbook/index.php/A_Roadmap_to_Emergency_Data_Standards
Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires
Página 203
G L O S A R I O SDM = Sensing Diagnostic Module
EDXL = Emergency Data Exchange Language
MAIS = Maximum Abbreviated Injury Scale
NASS = The National Automotive Sampling System
CDS = Crashworthiness Data System
NHTSA = National Highway Traffic Safety Administration
EMS = Emergency Medical Service
CDC = Center for Disease Control and Prevention
Telematics = Combination of telecommunications and computing.
PDOF = Principal Direction of Force
FARS = Fatal Accident Reporting System
NENA = National Emergency Number Association
AIS = Abbreviated Injury Scale
eCall = PanEuropean in-vehicle emergency call
FDS = Full Data Set (for data in an emergency call)
ITS = Intelligent Transport System(s)
MDS = Minimum Data Set (for data in an emergency call)
IVS = The in-vehicle system which includes the eCall data modem, collision detectors, position
location (e.g. GPS) function