AACN en la Argentina - materias.fi.uba.armaterias.fi.uba.ar/7500/GuillermoDanielPolonsky.pdf · Guillermo D. Polonsky. Padrón 79492 Universidad de Buenos Aires Página 1 AACN en

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


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


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


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


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


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.


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


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.


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.


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.


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


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


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.


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),


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


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.


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]


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.


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.


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.


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


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.


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.


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.


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


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.


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.


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]


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.


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


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


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.


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]


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


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


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


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.


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.


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


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]


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.


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]


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.


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


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.


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


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.


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


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.


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


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]


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)


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.


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,


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.


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.


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.


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.


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.


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


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


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.


Página 63

3.4.6 Estructura de un Mensaje de Alerta CAP


Figura 27 - http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.pdf


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


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


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.


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


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)

http://www.fema.gov/about/programs/disastermanagement/standards/edxl-de.shtm

http://www.fema.gov/about/programs/disastermanagement/standards/edxl-rm.shtm

http://www.fema.gov/about/programs/disastermanagement/standards/edxl-have.shtm

http://www.fema.gov/about/programs/disastermanagement/standards/sitrep.shtm


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,

http://www.fema.gov/about/programs/disastermanagement/standards/edxl-tep.shtm

http://www.fema.gov/about/programs/disastermanagement/standards/cap.shtm


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


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.


Página 72

3.6.3 Estructura del Elemento de Distribución del EDXL


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.


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


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)







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


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


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


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


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


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


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


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.


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.


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


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


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


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.


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


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


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.


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.


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.


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.


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:


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


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.


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.


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


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.


Página 96

C A P Í T U L O 5

5.1 Diagrama de despliegue

Figura 32. Diagrama de despliegue


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


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:


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


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.


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]


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


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.


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


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.


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:


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,


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


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


Página 110

5.11 Flujo de manejo de mensajes UDS

Figura 40. Flujo de manejo de mensajes UDS


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


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


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


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


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


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)


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.


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/


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:


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


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.


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]


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


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

http://www.aaronstannard.com/image.axd?picture=async%20controllers%20asp.net%20mvc.png


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


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.


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

http://code.google.com/p/openintents/wiki/SensorSimulator


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


Página 129

5.33 Diagrama de Base de datos

Figura 50.1. Diagrama de la base de datos


Página 130



Página 131



Página 132



Página 133



Página 134



Página 135



Página 136



Página 137



Página 138



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


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


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


EdsMessageId (PK,

Identity) bigint False Id del mensaje EDS


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


Latitud en grados decimales. (-90° to +90°). 0

significa que la latitud es desconocida.

(WGS84)


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


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


StateProvince varchar True


(depende del país) correspondiente desde


ZipCode varchar False Código postal desde el cual se envió el

mensaje UDS


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


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


Página 144

Nombre: HospitalAdmissions

Descripción: Registros de las internaciones en los hospitales de los accidentados.


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.


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


Página 145

Nombre: Crash

Descripción: Registros con la información de los choques


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


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


Latitud en grados decimales. (-90° to

+90°). 0 significa que la latitud es

desconocida. (WGS84)


Longitud en grados decimales (0 to 360°).

0 significa que la longitud es desconocida

(WGS84)


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.


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


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.


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


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


Página 149

Nombre: Vehicle_Crash

Descripción: Relación entre cada vehículo y el registro del choque


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


InsuranceProviderId bigint True Id de la compañía de seguro


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.


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


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


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


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


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)


Página 153

Nombre: Zone

Descripción: Descripción de la zona


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.


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.


SpeechImpared char(1) False Indica si la persona tiene problemas del habla.



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


Página 155

Nombre: MobilePhoneCallLog

Descripción: Log de las llamadas hechas al celular que reportó el choque (si aplica)


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


Página 156

Nombre: MobilePhone

Descripción: Celulares registrados en el sistema


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


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


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


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


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.


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)


Página 160

Figura 53. Mapa con todos los accidentes del momento, filtrado según se seleccione la gravedad.


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.


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.


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.


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


Página 165

Figura 59. Luego de que el accidente fue resuelto, se procede a cambiar su estado.


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.


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


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


Página 169



Página 170



Página 171


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


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])


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


Página 174

GDPTESIS.CLIENT.APPLICATION

Figura 67. GdpTesis.client.application


Página 175

GDPTESIS.CLIENT.BROADCASTRECEIVERS

Figura 68. GdpTesis.client.broadcastReceivers

GDPTESIS.CLIENT.COMM UNICATION

Figura 69. GdpTesis.client.communication


Página 176

GDPTESIS.CLIENT.CRASH

Figura 70. GdpTesis.client.crash


Página 177

GDPTESIS.CLIENT.DB

Figura 71. GdpTesis.client.db


Página 178

GdpTesis.client.location

Figura 72. GdpTesis.client.location


Página 179

GdpTesis.client.message

Figura 73. GdpTesis.client.message


Página 180

GDPTESIS.CLIENT.SENSORS

Figura 74. GdpTesis.client.sensores

GDPTESIS.CLIENT.UNIT S

Figura 75. GdpTesis.client.units


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


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


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.


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.


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


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


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]


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.


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


Accelerometer 18.38747 15.47272 0.544814 2.451142

Gravity 6.826512 8.065655 -0.15569 1.077625


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


Gravity 7.904022 7.485806 1.198913 1.116802


Accelerometer -10.3651 -4.86246 -10.0518 1.553579

Gravity 8.077127 7.391973 1.386273 1.125404


Gravity 8.20064 7.276434 1.519287 1.128643


Gravity 8.243803 7.118794 1.583753 1.122363


Página 190


Accelerometer -5.81589 0.980665 -4.0861 0.73166

Gravity 8.177501 6.904776 1.567049 1.103006


Gravity 7.981019 6.629053 1.462668 1.068419


Gravity 7.644597 6.293477 1.271391 1.018002


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



Accelerometer 11.52281 0.735499 1.334794 1.185233

Gravity 9.884451 -0.30851 0.590438 1.01022


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


Accelerometer 8.090487 0.40861 -0.95342 0.831753

Gravity 10.84397 -0.17879 0.890911 1.109652


Accelerometer 7.654635 0.054481 -1.56634 0.796749

Gravity 10.88562 -0.13978 0.962414 1.114445


Accelerometer 8.471856 -0.72188 -1.10325 0.874288

Gravity 10.66748 -0.12348 0.886885 1.091605


Accelerometer 8.185829 0.054481 -0.7355 0.838103

Gravity 10.21999 -0.12095 0.636054 1.044238


Accelerometer 10.2425 -0.21793 -0.34051 1.045258

Gravity 9.654664 -0.1296 0.255084 0.984934


Accelerometer 10.51491 -0.17706 0.136203 1.072464

Gravity 9.126377 -0.14625 -0.15564 0.930886



Página 191

Accelerometer 9.234595 0.258787 0.38137 0.942839

Gravity 8.777384 -0.16267 -0.48819 0.896581


Accelerometer 9.711308 -0.38137 0.38137 0.991804

DOBLANDO RÁPIDO CON EL AUTO Y EL CELULAR EN UN HOLDER



Accelerometer 11.52281 0.735499 1.334794 1.185233

Gravity 9.884451 -0.30851 0.590438 1.01022


Accelerometer 10.76008 -0.61292 0.78998 1.101949

Gravity 10.24563 -0.29262 0.623202 1.047119


Accelerometer 8.771504 -0.8036 0.667397 0.900765

Gravity 10.59779 -0.239 0.74874 1.083642


Accelerometer 8.090487 0.40861 -0.95342 0.831753

Gravity 10.84397 -0.17879 0.890911 1.109652


Accelerometer 7.654635 0.054481 -1.56634 0.796749

Gravity 10.88562 -0.13978 0.962414 1.114445


Accelerometer 8.471856 -0.72188 -1.10325 0.874288

Gravity 10.66748 -0.12348 0.886885 1.091605


Accelerometer 8.185829 0.054481 -0.7355 0.838103

Gravity 10.21999 -0.12095 0.636054 1.044238


Accelerometer 10.2425 -0.21793 -0.34051 1.045258

Gravity 9.654664 -0.1296 0.255084 0.984934


Accelerometer 10.51491 -0.17706 0.136203 1.072464

Gravity 9.126377 -0.14625 -0.15564 0.930886


Accelerometer 9.234595 0.258787 0.38137 0.942839

Gravity 8.777384 -0.16267 -0.48819 0.896581


Accelerometer 9.711308 -0.38137 0.38137 0.991804


Página 192

CONDUCCIÓN NORMAL CON EL CELULAR EN UN HOLDER



Accelerometer 0.640156 12.21745 -0.74912 1.249879

Gravity -0.10659 9.936916 0.138546 1.01344


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


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


Accelerometer -1.6072 8.757884 1.57996 0.922152

Gravity 0.137032 10.04205 0.132942 1.024189


Accelerometer 0.640156 11.74074 1.062387 1.203885

Gravity -0.00302 9.886478 0.384009 1.0089


Accelerometer 0.40861 11.48195 -0.76274 1.174153

Gravity -0.21156 9.65608 0.72917 0.987685


Accelerometer -0.58567 10.54215 -0.51757 1.077951

Gravity -0.40452 9.496772 1.045191 0.975121


Accelerometer -0.23155 9.547864 1.225831 0.981887

Gravity -0.51114 9.512614 1.206813 0.97918


Accelerometer -0.53119 9.629586 0.39499 0.984262

CAÍDA LIBRE SOBRE UN SILLÓN


Gravity 8.311835 8.108137 -0.96975 1.188173


Gravity 8.557552 8.450329 -1.11195 1.231605


Gravity 8.729984 8.809717 -1.25846 1.271204


Página 193


Accelerometer 1.688923 -1.7434 -2.24736 0.337317

Gravity 8.823792 9.162176 -1.40122 1.304951


Gravity 8.837637 9.47888 -1.53363 1.330739


Gravity 8.77042 9.731274 -1.65176 1.346436


Accelerometer -6.21088 -4.99867 0.463092 0.814345

Gravity 8.621717 9.893311 -1.754 1.350068


Gravity 8.389978 9.943079 -1.83938 1.339831


Gravity 8.072954 9.864155 -1.90477 1.314217


Accelerometer 13.81103 13.86551 15.71788 2.559567

Gravity 7.676981 9.654806 -1.9423 1.273314


Gravity 7.215972 9.325188 -1.93758 1.21848


Gravity 6.714383 8.899761 -1.87322 1.152765



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


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


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.


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


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


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


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,


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


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


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