SISTEMA DE ACCESO Y ENCENDIDO REMOTO DEL

AUTOMÓVIL MEDIANTE EL USO DE SMARTPHONE

TESIS
PARA OBTENER EL GRADO DE

MAESTRO EN
SISTEMAS INTELIGENTES MULTIMEDIA

PRESENTA

ING. FRANCISCO JAVIER RUVALCABA MOYA

ASESOR: MTRO. CARLOS ENRIQUE DÍAZ GUERRERO
ZAPOPAN, JALISCO, NOVIEMBRE, 2018

I
i
 I. RESUMEN

El presente documento muestra la investigación realizada como trabajo de tesis cuya

finalidad es obtener el grado en Maestría en Sistemas Inteligentes Multimedia. El
prototipo propuesto en este trabajo de investigación introduce una nueva forma de
manejar el acceso a los vehículos mediante el uso de protocolos multimedia existentes
en la gran mayoría de los teléfonos inteligentes actuales.

El objetivo principal de este trabajo de tesis es demostrar la factibilidad del uso de

tecnologías o protocolos de comunicación multimedia como auxiliares para los
sistemas de acceso y encendido de los vehículos, así como crear una alternativa de
bajo costo de producción para los actuales sistemas automotrices. Se pretende lograr
mediante la creación de un vínculo que reemplace o complemente a los actuales
sistemas de Acceso y encendido pasivo (PASE por sus siglas en inglés), permitiendo la
localización y autentificación de la llave de manera automática .

Pretende ser una característica adicional para los sistemas de gama alta sin necesidad
de alterar la arquitectura de los vehículos actuales con la intención de poder ser
ofrecido en el corto plazo a una gran variedad de clientes en el mercado actual. El
sistema contribuye a la industria mostrando la factibilidad de incorporar tecnologías
actuales a un sistema existente sin sacrificar funcionalidad o performance. Esto lo
busca mediante el uso de Bluetooth Low Energy (BLE) combinado en una aplicación
en un Smartphone y su correspondiente conexión con el sistema del vehículo.

La investigación demuestra comparativamente las funcionalidades básicas de una

llave inteligente actual con el sistema desarrollado y pretende determinar si las
tecnologías propuestas sirven para el propósito deseado. Los resultados obtenidos
demuestran que el sistema logró ser funcional al nivel de los actuales con pequeñas
diferencias en ejecución y rangos, destacanado una versatilidad para funcionar en
distintos vehículos sin necesidad de complicadas calibraciones en la programación.

Palabras Clave: Diseño, Bluetooth Low Energy, Keyfob, PASE, Ingeniería y Tecnología,
Tecnología de Vehículos de Motor, Automóviles.

i
 II. ABSTRACT

The following document show the investigation realized as thesis in order to obtain
Master Degree in Multimedia Intelligent Systems. The proposed prototype of this
investigation introduce a new way to handle car access using multimedia protocols
that exists in a great majority of actual Smartphones.

The main objective of this thesis work is to demonstrate factibility on usage of

multimedia communication technologies or protocols like assistant for start and access
vehicle systems, also to create an alternative of low cost of production for actual
automotive systems. This is intended with the cration of a link that could replace or
complement the actual PASE systems, allowing localization and authentification of the
key in automatic way.

It pretends to be an additional characteristic for high end systems without modifying

actual vehicles architecture in order that can be oferred in short term to a wide variety
of customers on actual market. The system contributes to the industry showing factibility
of add actual technologies to an existent system without scarifying functionality neither
performance. This is seeks through the usage of Bluetooth Low Energy combined with an
Smartphone application and their conection with the vehicle system.

The research comparatively demonstrates basic functionalities between a current smart

Keyfob and the development system and aids to determine if the proposed
technologies serve the desired purpose. The results obtained show that the system
managed to be functional to actual systems level with only small differences in range
and execution times, highlighting a versatility to operate in different vehicles without the
need for complicated calibrations in programming.

Keywords: Design, Bluetooth Low Energy, Keyfob, PASE, Engineering and Technology,
Motor Vehicles Technology, Automotive.

ii
III. AGRADECIMIENTOS

A DIOS
Por brindarme la salud y las
capacidades necesarias para dar a
buen término este trabajo de
investigación.

A MIS PADRES
Por su apoyo incondicional y soporte
durante mi vida académica y
profesional y por haberme dado las
herramientas que me permitieron llegar
a este nivel académico.

A MIS MAESTROS
Por enseñarme los conocimientos y
habilidades necesarias para llevar a
cabo la investigación y el desarrollo de
este trabajo.

A MIS COMPAÑEROS DE TRABAJO

Por las facilidades otorgadas para el
desarrollo de este trabajo de tesis y por
todo el apoyo dado a nivel técnico
para resolver mis cuestionamientos y
darme el tiempo necesario para
invertirlo en este trabajo de
investigación.

iii
IV. ÍNDICE DE CONTENIDO

Índice
I. RESUMEN ................................................................................................................................... i
II. ABSTRACT ..................................................................................................................................ii
III. AGRADECIMIENTOS ................................................................................................................ iii
IV. ÍNDICE DE CONTENIDO ......................................................................................................... iv
V. GLOSARIO .............................................................................................................................. vii
1 INTRODUCCIÓN....................................................................................................................... 1
1.1 ANTECEDENTES .................................................................................................................. 1
1.1.1 Uso de Smartphone................................................................................................. 3
1.1.2 Protocolo NFC .......................................................................................................... 5
1.2 DEFINICIÓN DEL PROBLEMA ............................................................................................ 5
1.3 JUSTIFICACIÓN .................................................................................................................. 6
1.4 OBJETIVOS ......................................................................................................................... 7
1.4.1 Objetivo general...................................................................................................... 7
1.4.2 Objetivos específicos .............................................................................................. 7
1.5 METAS ................................................................................................................................. 8
1.6 HIPÓTESIS............................................................................................................................ 8
2 MARCO TEÓRICO O FUNDAMENTOS TEÓRICOS................................................................. 9
2.1 PASE – PASSIVE START AND ENTRY ................................................................................ 10
2.2 SMARTPHONE: OPCIONES Y ARQUITECTURA DE SISTEMAS OPERATIVOS ................ 13
2.2.1 Sistema Operativo iOS .......................................................................................... 14
2.2.1.1 Arquitectura del sistema iOS ............................................................................ 14
2.2.2 Sistema Operativo Android .................................................................................. 16
2.2.2.1 Arquitectura del sistema Android.................................................................... 18
2.3 VENTAJAS Y DESVENTAJAS DE ANDROID SOBRE iOS ................................................. 21
2.3.1 Ventajas de Android vs iOS.................................................................................. 22
2.3.2 Desventajas de Android vs iOS............................................................................ 22
2.3.3 Elección del sistema.............................................................................................. 22
2.4 SMARTPHONE Y NFC: NUEVO CANAL DE COMUNICACIÓN .................................... 23
2.5 REDES DE AYUDA VEHICULAR MEDIANTE SMARTPHONE ........................................... 26

iv
3 PROCEDIMIENTO DE INVESTIGACIÓN ................................................................................ 31
3.1 ACCESO REMOTO SIN LLAVE ........................................................................................ 31
3.2 ACCESO Y ENCENDIDO PASIVO (PASE) ..................................................................... 33
3.3 ALCANCE DEL PROTOTIPO............................................................................................ 34
3.4 MATERIALES Y MÉTODOS ............................................................................................... 35
4 RESULTADOS .......................................................................................................................... 43
4.1 CONCLUSIONES.............................................................................................................. 47
4.2 APORTACIÓN DE LA TESIS ............................................................................................. 48
4.3 RECOMENDACIONES .................................................................................................... 49
5 REFERENCIAS ......................................................................................................................... 51
6 ANEXOS .................................................................................................................................... A
6.1 Anexo A – CSR1010 Datasheet ...................................................................................... A
6.2 Anexo B – BTLE Core Specification 4.2 .......................................................................... B
6.3 Anexo C – LIN Transceiver MCP2021A Datasheet ..................................................... C
6.4 Anexo D – Kinetis KL25Z Datasheet ............................................................................... D

Lista de Tablas
Tabla 1 Frecuencias GSM / LTE / Keyfob según la Unión Internacional de
Telecomunicaciones .................................................................................................................. 28
Tabla 2 Comparación funcional de una llave y el Smartphone ......................................... 48
Lista de Imágenes
Figura 1 Niveles de Seguridad en SW automotriz (1) ............................................................... 2
Figura 2 Penetración de los Smartphone en el Mercado Global.......................................... 4
Figura 3 Sistema PASE para acceso (10) ................................................................................. 11
Figura 4 Sistema PASE para encendido (10) ........................................................................... 12
Figura 5 Arquitectura de iOS ..................................................................................................... 15
Figura 6 Dominio de mercado de Android ............................................................................. 17
Figura 7 Arquitectura del sistema Android .............................................................................. 19
Figura 8 Usos de NFC (14) .......................................................................................................... 24
Figura 9 Renta de vehículo vía NFC (14) ................................................................................. 25
Figura 10 Acceso al Vehículo mediante NFC (14) ................................................................. 26

v
Figura 11 Redes de comunicación entre vehículos (15) ....................................................... 27
Figura 12 Sistema de informes de accidentes (18)................................................................. 29
Figura 13 Caso de Uso Alterno con dispositivo RF intermedio .............................................. 32
Figura 14 Caso de Uso para Remote Keyless Entry ................................................................ 33
Figura 15 Caso de Uso para PASE ............................................................................................. 34
Figura 16 Tarjeta de evaluación CSR1010 ............................................................................... 35
Figura 17 Kit de desarrollo uEnergy CSR101x con programador .......................................... 36
Figura 18 Tarjeta KL25Z de Freescale (NXP) ............................................................................. 36
Figura 19 LIN Transceiver............................................................................................................. 37
Figura 20 Pantalla de Inicio de la aplicación.......................................................................... 38
Figura 21 Botones de RKE en la aplicación ............................................................................. 39
Figura 22 Pantalla para habilitar configuraciones. La información dentro es propiedad
intelectual ..................................................................................................................................... 40
Figura 23 Conexiones en la tarjeta CSR1010 para el receptor ............................................. 41
Figura 24 Tarjeta Kinetis y conexión en caja plástica ............................................................ 42
Figura 25 10 metros, zona no detectada................................................................................. 43
Figura 26 Zona RKE ...................................................................................................................... 44
Figura 27 Zona de PASE - mensaje de RKE en rango ............................................................. 45
Figura 28 Zona PASE - rango de 1 metro.................................................................................. 45
Figura 29 Zona PASE - encendido pasivo posible ................................................................... 46

vi
V. GLOSARIO

BCM: Body Control Module (Módulo de Control de Cuerpo)

LF: Low Frequency (Baja Frecuencia)
RF: Radio Frequency (Radio Frecuencia)
PASE: Passive Start and Entry (Acceso e Inicio Pasivo)
NFC: Near Field Communication (Communicación de Campo Cercano)
RKE: Remote Keyless Entry (Acceso Remoto sin Llave)
BTLE: Bluetooth Low Energy (Bluetooth de Bajo Consumo)
BLE: Bluetooth Low Energy (Bluetooth de Bajo Consumo)
LTE: Long Term Evolution (Evolución a Largo Plazo)
GSM: Global System for Mobile Communicationes (Sistema Global para
Comunicaciones Móviles)
4g: 4th Generation of Mobile Communication (4ta Generación de Comunicaciones
Móviles)
SW: Software
HW: Hardware
MHz: MegaHertz (Unidad de Medición de Frecuencia)
UART: Universal Asynchronous Receiver Transmitter (Transmisor Receptor Asíncrono
Universal)
Smartphone: Teléfono Inteligente

vii
1 INTRODUCCIÓN
1.1 ANTECEDENTES
“La tecnología de la información es el motor detrás de las innovaciones en la industria
automotriz, con alrededor de un 90% de todas las innovaciones en automóviles
basadas en electrónica y software.” [1]

La industria automotriz está en una constante evolución en busca de tecnologías que

permitan desarrollar sistemas más seguros, confortables y que permitan la reducción de
costos de fabricación que se traducen en un incremento de ganancias. Estas
innovaciones pretenden aumentar la eficiencia de una funcionalidad ya establecida o
crear una forma diferente de resolver el mismo problema conservando el nivel de
confiabilidad logrado con sistemas antiguos.
Los sistemas de acceso al vehículo son uno de los mejores ejemplos de la evolución
tecnológica en la industria automotriz. Estos sistemas se han transformado con el paso
de los años desde una llave física hasta las llaves inteligentes de hoy en día, los cuales
no necesitan tener contacto directo con el vehículo para permitir el encendido remoto
utilizando tecnología inalámbrica y protocolos de comunicación en radio frecuencia.
Sin embargo, las llaves inteligentes actuales enfrentan problemas severos debido a la
proliferación de la piratería informática poniendo en riesgo la seguridad del usuario
final y llevarlo a la pérdida del vehículo mediante la copia o réplica del protocolo
usado para dar acceso y permitir el uso del automotor.
Los sistemas actuales han creado diferentes protocolos de seguridad y encriptación
(ver Figura 1) que permiten aminorar estos problemas y darle al usuario un mayor
confort ya que se puede acceder al vehículo de una manera más natural. Dichos
protocolos van desde la simple inclusión de un ‘byte’ extra al final de un mensaje
transmitido que contenga alguna secuencia sólo conocida por el desarrollador del
software y del sistema hasta rutinas complejas que sólo son conocidas por un
desarrollador tercero que se encarga de la definición de esos sistemas. [1]

1
 Figura 1 Niveles de Seguridad en SW automotriz [1]

Los sistemas más básicos de seguridad incorporan el protocolo denominado CRC8 –

por sus siglas en inglés comprobador de redundancia cíclica – el cual se basa en un
cálculo sencillo byte a byte para generar un único resultado posible. Debido a que
este sistema incorpora muy pocos elementos en su cálculo, se considera actualmente
como un protocolo inseguro para una funcionalidad como el acceso al vehículo. Para
incrementar la seguridad, se han implementado protocolos más seguros como la
encriptación AES (por sus siglas en inglés Estándar de Encriptación Avanzado) el cual
utiliza 2 entradas de 128 bits – 8 bytes – para calcular de manera interna y mediante un
algoritmo basado en corrimientos y operaciones lógicas entregando una salida
también de 128 bits [2]. Típicamente una de estas dos entradas no es conocida por los
desarrolladores y se genera de manera aleatoria o siguiendo un procedimiento
definido que permite que tanto la llave como el módulo de control interno del vehículo
puedan intercomunicarse entre ellos mediante el envío de estos 128 bits sin que algún
usuario pueda deducir la otra entrada.
Además, existen sistemas de encriptación más avanzados que incorporan
procedimientos complejos o muy específicos (definidos por el desarrollador o diseñador
del sistema) para calcular las entradas del protocolo AES. En estos sistemas no se
transmiten los 128 bits entre el vehículo y la llave sino sólo uno o dos bytes, los cuales,
fueron introducidos previamente a un procedimiento de encriptación extra que debe
ser realizado a la par por la llave y el vehículo para obtener el mismo dato final. El dato

2
recibido por el vehículo será comparado con el dato calculado y deben coincidir para
garantizar que esa llave puede tener acceso al vehículo.
La creación de protocolos de seguridad avanzados ha dado libertad a los
desarrolladores para incorporar funcionalidades extra que proporcionen al usuario
mejores servicios. Dentro de estos servicios podemos encontrar: apertura y cierre de
cristales de las puertas a distancia, encendido remoto, envío-recepción de datos entre
la llave y el vehículo, indicadores visuales en la llave – como LEDs – para retroalimentar
una respuesta positiva al usuario, etc. Sin embargo, estas funcionalidades extra así
como el uso de protocolos cada vez más fuertes de seguridad han producido otro
problema: el incremento del costo [3].
Algunas llaves inteligentes actuales permiten la combinación de botones en cierta
secuencia de forma que el usuario pueda realizar acciones avanzadas como el
encendido remoto del motor y sistemas de confort (aire acodicionado, radio, etc.).
Esta es una de las funcionalidades más demandas en ciertas zonas debido a su alta
utilidad; en las ciudades cercanas a zonas de baja temperatura, encender de manera
remota para reducir el tiempo en la intemperie es el mejor ejemplo. Otro ejemplo es en
el sentido opuesto, cuando la temperatura es elevada y esperamos que nuestro
vehículo esté encendido y con las condiciones adecuadas de ventilación y
temperatura justo antes de partir. Estas nuevas funcionalidades combinadas con un
Smartphone cada vez más común y de fácil acceso para el grueso poblacional serán
de gran utilidad para el confort y podría el costo adyacente en caso de robo o
extravío.

1.1.1 Uso de Smartphone

Los teléfonos inteligentes o Smartphone han proliferado su uso durante la última

década. De acuerdo a un estudio realizado en el marco del observatorio móvil
latinoamericano, en el 2014 un 33% de los teléfonos celulares en el mercado eran
teléfonos inteligentes. Esta tendencia fue empujada fuertemente por el mercado
estadounidense donde actualmente un aproximado del 60% de los teléfonos celulares
en uso son Smartphone. (Cabello y Phillips, 2012). Esto implica que en 2014 el 37% de los
teléfonos en la escena mundial eran Smartphone. (Ver figura 2)

3
 Figura 2 Penetración de los Smartphone en el Mercado Global

Según un estudio realizado en 2016 por el mismo observatorio móvil, se prevee que
para el 2020 el número de personas que usarán un dispositivo móvil con acceso a
Internet se incrementará un 50%, es decir, habrán 450 millones de usuarios con acceso
a Internet móvil, de los cuales un 90% lo hará mediante un Smartphone.
Esto quiere decir que el Smartphone se ha convertido en un artículo de uso común y de
alta demanda para la mayor parte de la población debido a la versatilidad de
aplicaciones que se pueden encontrar en estos dispositivos. Los Smartphone suelen
tener un uso más versatil que sólo la comunicación al poder utilizarlo como agenda
personal, reloj despertador, reproductor de música, etc., permitiéndonos prescindir de
otros artículos.
Los Smartphone han comenzado a incorporar nuevas tecnologías y protocolos de
comunicación que permitan cubrir las exigencias cada vez mayores del mercado
actual. Uno de esos protocolos es conocido como NFC (por sus siglas en inglés
Comunicación de Campo Cercano).

4
1.1.2 Protocolo NFC

El protocolo NFC surge en 2004 debido a la necesidad de un protocolo de

comunicación que permitiera transmitir datos entre dispositivos de manera inalámbrica.
Este protocolo facilita la comunicación entre dos dispositivos, los cuales usan
tecnología de radiofrecuencia de corto rango para permitir la lectura/escritura de
datos entre ellos con un simple toque o estando a una distancia muy corta. (Entre 5 y
10 cm). [4]
De esta forma, el protocolo NFC permite la programación de tareas sencillas en un
dispositivo o el traspaso de datos de manera segura. Estos datos pueden ser
internamente encriptados para garantizar aún mayor seguridad permitiéndoles
acceso a los usuarios a diversas tareas de manera mucho más sencilla: programar una
alarma en el Smartphone, registrar hora de entrada en una empresa, intercambio de
información entre dispositivos, pago de artículos o servicios, etc. [5].
Actualmente este protocolo es apoyado por empresas líderes en sus ramos como
Master Card, Sony, NXP, Intel, Google, entre otras.
Este protocolo ha comenzado a expandirse lentamente en diferentes ámbitos por lo
cual no es descabellado pensar en incluir funcionalidades del mismo en la industria
automotriz, lo cual no sólo abriría un vínculo para el acceso y encendido sino otras
posibilidades futuras como diagnósticos, actualizaciones de agencia, estatus del
vehículo, etc.
A su vez, si consideramos el creciente uso de los Smartphone, podemos pensar en una
alternativa de alta seguridad que involucre a estos dos tópicos de forma que se pueda
ofrecer una solución innovadora y de mayor confort a los usuarios, así como de
grandes ahorros y ventajas para las manufactureras automotrices.

1.2 DEFINICIÓN DEL PROBLEMA

Actualmente las llaves inteligentes tienden a seguir la tendencia de la comodidad
donde el usuario acceda de manera más sencilla sin necesidad de presionar botones
o abrir cerraduras, de forma que sólo por la acción natural de abrir el vehículo se
pueda ingresar. Esto se ve claramente en las capacidades y funciones actuales de una
llave inteligente:
- Apertura y cierre de seguros a distancia

5
 - Encendido y apagado del motor de manera remota
- Acceso pasivo sin interaccion con la llave mediante localización y
autentificación automática (PASE)
- Encendido de luces al detectar proximidad de la llave al vehículo
Se propone la creación de un sistema alternativo de apertura de seguros y
encendido remoto de un automóvil mediante el uso del Smartphone lo cual
abaratará costos para el usuario final y brindará una ventaja de mercado a las
manufactureras emulando las capacidades de las llaves inteligentes actuales con
el mismo nivel de seguridad existente. Basado en esto, se planea utilizar un
Smartphone (limitado a Android / iOS) para el cual se desarrollará un SW
especializado que pueda ser descargado fácilmente por el usuario y que mediante
acceso NFC sea aprendido solamente con ese vehículo a fin de evitar múltiples
accesos con diferentes Smartphone. De esta manera, un Smartphone previamente
aprendido o “casado” podrá trabajar mediante protocolos de comunicación
inalámbrica para dar acceso al vehículo así como para encenderlo remotamente
como en los actuales sistemas PASE / RKE.

1.3 JUSTIFICACIÓN
El costo de producción de las llaves intelegentes actuales es elevado debido a la gran
cantidad de procesos de homologación, certificación, materiales, pruebas
exhaustivas, etc., provocando que los distribuidores entreguen pocas unidades de
estas llaves inteligentes y encarezcan el producto final para el usuario en caso de
reemplazo. Esto sucede ya que las manufactureras pasan este costo de producción al
usuario final mediante el dinero que debe ser invertido en un reemplazo.
De esta manera, el usuario final pierde interés en esta clase de productos ya que en
muchos mercados – sobre todo en emergentes o países en vías de desarrollo – el
usuario prefiere un vehículo o sistema de bajo costo a uno altamente seguro (en cifras
de la Asociación Mexicana de la industria automotriz el Tsuru y el Aveo representan el
30% de las ventas totales mensuales de vehículos debido a su bajo costo). [6]
El uso de un elemento tan común como el Smartphone permitiría al usuario ahorrar
gastos ya que en caso de robo o extravío no se está comprando un elemento de alto
costo por su uso primordial sino que es una funcionalidad extra y es un objeto más

6
común. De la misma manera los productores pueden incluir esta característica en
vehículos de bajo costo ofreciendo una alternativa a las llaves actuales y cumpliría con
el propósito de ofrecer seguridad con una interfaz sencilla e intuitiva para el usuario
final. Esto puede ser una ventaja competitiva debido a la posibilidad de ofrecer un
extra que no reduce la funcionalidad o seguridad actual pero en cambio incrementa
el atractivo tecnológico además de que establece un puente con las tecnologías
móviles que se encuentran en alta demanda para un gran sector de la población
actualmente.

1.4 OBJETIVOS

1.4.1 Objetivo general

Diseñar un sistema que incluya una aplicación en un Smartphone Android / iOS capaz
de comunicarse directamente con un vehículo y que ejecute las mismas acciones que
las llaves inteligentes actuales como lo son Remote Keyless Entry y PASE.

1.4.2 Objetivos específicos

- Diseñar un sistema de seguridad por SW basado en protocolo de encriptación

AES de 128 bits de forma que el Smartphone y el auto puedan comunicarse vía
UHF (frecuencias actuales de protocolos RKE oscilan los 902 MHz) garantizando
acceso único sin riesgo de comprometer los datos seguros del automóvil y
reduciendo problemas de “hacking”.
- Desarrollar una aplicación basada en algún procolo multimedia disponible en
los Smartphone (NFC, BLE, WiFi) la cual sea capaz de traspasar datos entre el
vehículo y el dispositivo garantizando que sólo pueda darse un acceso a la vez
aun cuando se tenga la aplicación en diferentes equipos.
- Diseñar un módulo de recepción de señales en el vehículo que se comunique
con la computadora central y en conjunto tendrán acceso al teléfono para
escribir datos requeridos por el protocolo de seguridad así como otros datos
importantes en el funcionamiento de las llaves inteligentes: el número de serie
del teléfono o identificador particular, contador de funciones ejecutadas, etc.

7
 - Diseñar una aplicación gráfica en el celular que muestre objetos similares a los
botones vistos en una llave inteligente real y a su vez de manera automática
envíe datos de la localización del dispositivo al vehículo.
- Evaluar la distancia máxima posible de comunicación entre el teléfono y el
automóvil.
La mayoría de estos objetivos se evaluarán comparando contra una llave actual.

1.5 METAS
- Crear un prototipo funcional con la tecnología sugerida de forma que pueda ser
usado para compararse con una llave inteligente actual y arrojar resultados
comparativos en rango, performance y seguridad para una posible producción
en masa a futuro.
- Desarrollar un sistema de llave inteligente en un Smartphone que pueda
complementar o reemplazar los actuales sistemas de acceso y encendido
remoto mediante tecnologías más modernas que las actualmente usadas en los
sistemas automotrices.
- Diseñar un protocolo y un método de demostración mediante el cual el
prototipo pueda ser visto funcionando en un vehículo real por diferentes
fabricantes, marcas y plataformas.

1.6 HIPÓTESIS
El Smartphone puede ser usado como llave de acceso en vehículos existentes y
proporcionar el mismo nivel de seguridad y el mismo rendimiento que las llaves
inteligentes actuales.

8
2 MARCO TEÓRICO O FUNDAMENTOS TEÓRICOS
Los sistemas automotrices han evolucionado constantemente a fin de presentar
opciones seguras, de bajo costo o con un alto grado de innovación para captar la
atención de potenciales nuevos clientes. Con el avance actual de la tecnología, las
funcionalidades que más demanda presentan en la industria automotriz son aquellas
enfocados al confort del usuario así como a nuevos sistemas robustos y complejos en
términos de seguridad acorde a múltiples estudios de mercado realizados en
Norteamérica y Europa. [7]
El uso de un sistema con un alto grado de innovación acarrea nuevos problemas a la
industria ya que el desconocimiento por parte de los manufactureros o proveedores se
compensa con el alto conocimiento que poseen diversos sectores externos
acostumbrados a estos sistemas. Esto ha generado una disyuntiva en la industria ya que
se piensa que al intentar combinar tecnologías y servicios cotidianos en los
automóviles, con la excusa de generar practicidad, cometamos el error de abrir un
canal potencialmente inseguro a nuestro vehículo; además hay que considar que ante
todo debemos garantizar el uso primordial del mismo, el cual es ser un medio de
transporte. Con esta idea siempre en mente, cada vez más personas y compañías
enfocan sus esfuerzos en la creación de sistemas más cómodos para el control de los
automóviles así como en la creación de sustitutos para funcionalidades sencillas,
reemplazando un dispositivo con algún accesorio electrónico de última generación.
Es por ello que en los últimos años, hemos podido notar que existen nuevas
funcionalidades o accesorios que nos ayudan a convertir un Smartphone en un control
universal del vehículo y permitir la conexión a la computadora central del mismo, de
forma que logremos abrir o cerrar los seguros de las puertas, abrir la cajuela, subir o
bajar las ventanas e incluso encender el automóvil a distancia. Estos sistemas cuentan
con un dongle o accesorio conectado al automóvil que crea un vínculo inalámbrico
entre el teléfono y el vehículo, funcionando a la vez como traductor de todos los
protocolos automotrices para indicarle a la computadora central el comando
solicitado [8]. A pesar de la aparente potencia de este sistema, aún es necesario que
exista una llave física ya que nuestro Smartphone sólo se dedica a ser un intérprete de
la señal de este mismo, de forma que replica y almacena algunos de los comandos
necesarios al vehículo.

9
Otra clase de sistemas han ido más allá, al utilizar el Smartphone como un controlador
directo vía inalámbrica. Esto quiere decir que utilizando los sensores del teléfono y una
antena especializada conectada a nuestro vehículo se nos permite utilizar el
Smartphone como una especie de control remoto [9]. Sin embargo, este sistema
presente evidentes fallas de seguridad como la inserción de un componente exterior
que puede o no ser compatible con el sistema original del vehículo, así como dar
acceso total a un aparato que no está exento de fallas.
Como se puede notar, hay distintas variedades persiguiendo un fin común: utilizar el
Smartphone como una alternativa a la llave tradicional o a la llave del sistema PASE
(Passive Start and Entry). Sin embargo, poseen aún una gran debilidad, la cual es
requerir una modificación o adecuación del sistema original del vehículo para
comunicarse inalámbricamente con un sistema que ya contiene suficientes antenas de
baja y radio frecuencia para el funcionamiento de PASE.
Estos trabajos de investigación básicamente tratan de servir como un espejo o etapa
intermedia del sistema PASE, de forma que no interfieren en su protocolo ni tratan de
reproducirlo. Para crear una alternativa realmente innovadora, debemos permitir a un
nuevo dispositivo el interactuar de forma natural con un sistema PASE. Si queremos
interactuar con este sistema, es necesario conocer al menos la base del mismo para
poder interactuar con él y posteriormente reemplazarlo o mejorarlo; así, comenzaremos
analizando la base del sistema PASE mismo para continuar con este trabajo de
investigación.

2.1 PASE – PASSIVE START AND ENTRY

Los sistemas PASE fueron creados por Siemens VDO alrededor de 1998 como una
alternativa de apertura y arranque de vehículos sin necesidad de la interacción directa
con la llave. Estos sistemas basan su funcionamiento en la localización de la llave tanto
dentro como fuera del vehículo mediante la combinación de mensajes encriptados vía
radiofrecuencia y bajas frecuencias.
Existen dos escenarios básicos en estos sistemas, los cuales le dan su nombre: Start and
Entry. En el caso de Entry el usuario posee una llave, previamente autentificada para
usarse solamente con esa computadora central del vehículo, la cual espera una señal
para enviar un mensaje indicando su posición. Por lo general, la señal que se espera se

10
activa al momento de tocar la manija de la puerta (ver figura 3) desatando una serie
de mensajes y protocolos de comunicación entre la llave y el vehículo.

Figura 3 Sistema PASE para acceso [10]

En el caso de Start, el usuario del vehículo solo requiere presionar un botón de

encendido que disparará un algoritmo de búsqueda y detección de la llave dentro del
vehículo. Una vez detectada la llave, se enviará un mensaje a la computadora central
que indicará que el encendido del motor es permitido. Este proceso sucede de
manera automática y en un corto tiempo sin que el usuario se percate de ello (ver
figura 4).
Actualmente, existen sistemas aún más avanzados en los que el vehículo detecta
nuestra llave de manera automática mientras nos acercamos al vehículo, de forma
que los seguros de las puertas se desbloquean de manera automática antes de llegar
al mismo. Al salir, el sistema reconoce que la llave se aleja del vehículo de forma que
activa de nuevo los seguros y alista los sistemas antirrobos [10].

11
 Figura 4 Sistema PASE para encendido [10]

Esta clase de sistemas avanzados de PASE incrementan la seguridad de nuestro

vehículo al mismo tiempo que aumentan el confort del usuario al realizar tareas
automáticas que bien pudieron ser mal ejecutadas o simplemente no llevadas a cabo
por el usuario final. Con esto, podemos demostrar que un sistema novedoso puede ser
capaz de ofrecer una nueva alternativa con un nivel igual o superior de seguridad al
de los sistemas tradicionales.
En base a ello, surge la idea de buscar un reemplazo eficiente y que brinde aún un
mayor confort al usuario. Debido a la complejidad del sistema PASE dentro del vehículo
es que se omite por lo general tratar de modificarlo o agregarle elementos, como ya lo
vimos anteriormente con algunos controles inalámbricos. Por tanto, se puede deducir
que es más sencillo buscar una alternativa en la que modifiquemos o sustituyamos la
contraparte del sistema: la llave.
Las llaves de los automóviles han evolucionado desde la clásica llave mecánica de
combinación hasta las actuales llaves inteligentes, pasando por las llaves RKE y
aquellas que usan “transponder” para autentificarse vía LF con otro dispositivo. Uno de
los problemas más comunes de las llaves es como añadir funcionalidades extra sin
incrementar su tamaño sobremanera; es decir, necesitamos cada vez mayor
capacidad de procesamiento pero sin afectar la practicidad misma de la llave.
Si pensamos en este concepto, se pueden adaptar las funcionalidades de una llave a
un dispositivo poderoso de bolsillo y cada vez de uso más común para la mayoría de
12
las personas, el Smartphone. Los teléfonos inteligentes han cobrado una gran
relevancia en la vida cotidiana y han tenido un avance gigantesco en los últimos años,
pasando de simples aparatos de telecomunicación a medios electrónicos de bolsillo
casi tan potentes como algunas computadoras personales básicas. Considerando que
el concepto de una llave de forma básica es simplemente enviar, recibir, encriptar y
desencriptar datos de una transmisión inalámbrica, el Smartphone tiene la potencia y
el equipo de HW adecuado para estos propósitos. Lo único que nos haría falta sería un
protocolo de comunicación que nos pueda ayudar a garantizar un nivel de seguridad
similar al de las llaves actuales.
De aquí en adelante se analizará la nueva alternativa propuesta para el
funcionamiento con un vehículo: el uso del Smartphone.

2.2 SMARTPHONE: OPCIONES Y ARQUITECTURA DE SISTEMAS OPERATIVOS

Los Smartphone o teléfonos inteligentes son dispositivos electrónicos cuyo uso se ha
diversificado cada vez más entre la población en general. Aunque la definición de un
Smartphone suele ser muy diversa dependiendo del autor de la misma, la convención
mundial acerca del término suele definir a un Smartphone como una computadora
personal de mano que posee un sistema operativo móvil y que integra las
capacidades de comunicación con la red de telefonía celular móvil para transmisión
de voz, SMS y datos [11].
Aunque no es una parte fundamental de su definición, los Smartphones pueden tener
capacidades y conectividades extra como lo son los protocolos de comunicación
multimedia WiFi, BLE, NFC, etc. El uso y la integración de estos protocolos suele darse
más para mostrar una ventaja competitiva entre los diversos proveedores de estos
dispositivos que realmente a una necesidad funcional.
Ya que el objetivo de esta tesis no recae en la elección del Smartphone a usar sino en
explotar sus capacidades de conectividad para asignarle una función extra, no se
ahondará a profundidad entre todos los tipos de Smartphone existentes o en su historia
sino en la parte modular que permite usar sus capacidades: El sistema operativo móvil.
Como ya vimos en su definición, un Smartphone debe poseer un sistema operativo
móvil el cual le permitirá explotar las capacidades de HW existentes en el mismo.
Aunque existe una muy amplía gama de sistemas operativos móviles, usualmente se

13
reconoce solamente a dos como los sistemas dominantes en el mercado: Android
desarrollado por Google Inc. y iOS desarrollado por Apple Inc.

2.2.1 Sistema Operativo iOS

El sistema operativo iOS es desarrollado por Apple Inc y aparece en el mercado como
un sistema exclusivo del primer iPhone en 2007 [12]. De ahí surge su nombre original
(iPhone Operative System) el cual se convertiría con el paso del tiempo en el acrónimo
ya mencionado. Actualmente este sistema operativo está disponible para ser usado en
tabletas, Smartphones, reproductores de música e incluso computadoras portátiles o
laptops siempre y cuando estas posean una arquitectura de MAC o compatibilidad
con la misma.
Es un sistema operativo cerrado desarrollado originalmente en lenguajes C y C++ bajo
un núcleo XNU (X Not Unix) y que a pesar de poseer un kernel libre contiene una
arquitectura que impide acceder a las capas inferiores para extraer datos. Este kernel
fue desarrollado por Darwin y Next como alternativa a los kernel Unix (de ahí el nombre)
para permitir al sistema operativo tener la potencia de un núcleo monolítico de acceso
a memoria pero a su vez permitir la creación de “mininúcleos” dedicados a tareas
específicas que pueden acceder al manejo de datos y memoria de forma más
eficiente pero a su vez gozar de la protección propia del sistema operativo en el
núcleo central.
El kernel y sistema como tal evolucionaron hasta el punto de llegar a crear su propio
lenguaje de programación para permitir al usuario mayor libertad al momento de
usarlo y de desarrollar aplicaciones para el mismo. Para la interfaz gráfica, Apple
decidió crear un lenguaje a bloques denominado Cocoa y para la programación de
las funcionalidades se creo un lenguaje conocido como Swift, ambos desarrollados en
base a Objective C. Estos se integran de manera perfecta en la arquitectura iOS para
permitir al desarrollador explotar al máximo las capacidades del sistema operativo pero
sin dejar huecos de seguridad que permitan hackear o modificar el kernel y la base del
sistema mismo como se observa en la Figura 5.

2.2.1.1 Arquitectura del sistema iOS

La arquitectura del sistema iOS se constituye de 4 capaz básicas: Cocoa Touch, Media,
Core Services y Core OS. La capa de Cocoa Touch es la capa superior, es aquella que
14
los usuarios utilizan para interactuar con sus aplicaciones. Por tanto, esta es una capa
de abstracción y es la capa visible o gráfica donde se visualizan todos los
componentes que conforman la denominada aplicación. Como dato extra, Apple Inc.
siempre maneja el mismo diseño de aplicaciones y todas deben ser compatibles con
este framework o marco gráfico distintivo. El SW para desarrolladores de Apple Inc. ya
cuenta con estos marcos integrados para permitir que el programador se enfoque en
la parte gráfica de lo que quiere representar y no en el modelo de la pantalla en sí.

Figura 5 Arquitectura de iOS [12]

La segunda capa corresponde a Media, la cual contiene todos los accesos a ficheros
multimedia como su nombre lo menciona. Esta capa permite el acceso a ficheros de
audio, video, imágenes, gráficos, etc., dejando claramente asentado uno de los
propósitos principales de las aplicaciones de Apple Inc.: el manejo de elementos
multimedia de manera sencilla para el programador. Apple Inc. se caracteriza por ser
una de las compañías que prefieren el manejo de archivos multimedia como prioridad
sobre otras compañías rivales, es por ello que facilitan al usuario funciones y librerías
para que este manejo sea mucho más sencillo [12].
Un nivel más abajo encontramos los servicios del núcelo o Core Services. En esta capa
se nos provee de utilidades y librerías para permitirnos acceder a servicio básicos
genéricos del sistema que incluyen, pero no se limitan, a acceso Web, Bases de datos
SQLite, BLE, soporte XML, etc. La intención de Apple Inc. al proporcionar esta capa es
que el usuario no pueda acceder a las funcionalidades avanzadas del sistema
operativo más allá de lo que el mismo Apple decida.
Esto nos lleva a la última capa, núcleo del sistema operativo, la cual provee utilidades
para el manejo de memoria, acceso de datos, seguridad, manejo de ficheros, manejo
y administración de procesos e hilos. Esto de nuevo permite el acceso sencillo a esas
15
utilidades pero a su vez limita el manejo directo de HW, hilos y memoria del kernel. Todo
esto se bloquea incluyendo capacidades que el HW ya posea pero Apple Inc. no
desea que sea utilizado. Uno de los más grandes ejemplos de esto es que los iPhone
poseen la capacidad de recibir señales de radiofrecuencia o el traspaso de datos a
través de BLE, sin embargo Apple Inc no provee librerías para este manejo.
De ahí viene una de las más grandes restricciones en el uso de iOS: al no ser un código
libre no se puede desarrollar algo que Apple Inc. no haya decidido que se pueda
utilizar libremente, aún cuando el HW del Smartphone sea capaz de hacerlo. De la
misma forma, todo el acceso a estas librerías y utilidades del sistema operativo es de
pago, y al ser lenguajes, compiladores y linkers exclusivos se requiere del uso de
diversas licencias para poder crear una aplicación de prueba incluso; además, Apple
Inc. se reserva el derecho de conservar la aplicación desarrollada como su propiedad
intelectual si así conviene a sus intereses, todo esto detallado en la política de creación
de aplicaciones del sitio web de Apple [12].
Basandose simplemente en estas restricciones, la creación del prototipo de esta tesis
descarta el uso de este sistema operativo por el momento ya que es una tecnología
nueva que podría ser muy llamativa para los competidores y se requiere de un acceso
más libre a las herramientas de desarrollo. Aunque las grandes marcas automotrices
contemplan este sistema como prioritario, la creación del prototipo se negoció
basándose en estas restricciones y el riesgo de pérdida de propiedad intelectual que
conlleva.
También, desde el punto de vista técnico y al momento de la redacción de esta tesis
Apple Inc. no consideraba entre las opciones de su sistema operativo otros protocolos
multimedia más allá de BLE. Es decir, Apple no permite comunicarse via NFC, WiFi o
incluso establecer una comunicación BLE en modo reposo por motivos de seguridad.
Esta última característica es esencial para el desarrollo del prototipo propuesto por lo
que basado en estos hechos, se procedió al análisis del siguiente sistema operativo con
amplio mercado (Android) teniendo en mente ya las limitantes de iOS.

2.2.2 Sistema Operativo Android

El sistema Android es un sistema operativo basado en Unix y desarrollado en un

principio para cualquier dispositivo móvil que contara con una pantalla táctil. Fue

16
creado por una empresa denominada Android Inc. la cual era respaldada y
financiada por Google Inc. hasta que estos la compraron en 2005.
Es el sistema operativo móvil más usado en el mundo, con más de un 80% de dominio
de mercado ya que se puede encontrar en Smartphones, tabletas, laptops, netbooks e
incluso una versión para computadoras personales. Según datos recientes obtenidos
por la consultora Stat Counter, a partir del año 2017 es también el sistema operativo
más usado en el mundo, sobrepasando a Windows y Mac OS con un 39.7 del mercado
por un 39.3% de su más cercano perseguidor Windows [13].

Figura 6 Dominio de mercado de Android [13]

Por esta razón inicial cobra relevancia su uso en nuestro prototipo ya que abarcaría el
más amplío rango de mercado disponible en cuanto a Smartphone se refiere y al ser
una plataforma genérica se puede extender a los demás dispositivos que utilicen este
sistema operativo, siempre y cuando se cuenten con las capacidades de HW
necesarias para el correcto funcionamiento del mismo. Sin embargo, aún analizaremos
otros aspectos de este sistema operativo como su arquitectura antes de tomar la
decisión final, considerando que ya tenemos una ventaja sobre iOS

17
2.2.2.1 Arquitectura del sistema Android

El sistema operativo Android es un sistema desarrollado en LINUX con el firme propósito

de ser portable a diferentes dispositivos. Además al ser basado y usar el kernel de
LINUX, es un sistema de licencia libre que puede ser modificado y utilizado por
cualquier desarrollador, con ciertas zonas protegidas si así lo deciden los que estén
utilizándolo. Otra ventaja de usar el kernel de LINUX es que cualquier desarrollador o
empresa puede crear su propio HW y explotar las capacidades del mismo proveyendo
un driver para su manejo e integrándolo en el sistema de manera sencilla. Esto da la
libertad a todos los desarrolladores de crear su propio HW con diferentes capacidades
a las de sus competidores y manejarlo libremente sin necesidad de depender de
librerías generadas por Google Inc.
Este tipo de arquitectura permite una amplia versatilidad del sistema operativo para ser
utilizada en diferentes medios, no solo Smartphones sino también tablets, PCs, laptops,
etc. Esto es de amplia utilidad también para los desarrolladores ya que pueden emular
el sistema operativo en diferentes dispositivos y no necesariamente tener una máquina
con la arquitectura y el sistema operativo dedicado al mismo.
El sistema operativo Android también se basa en diseño por capas al igual que iOS (ver
figura 7), sin embargo maneja diferentes niveles de abstracción que permiten al
desarrollador manejar de manera más eficiente los recursos sin depender del sistema
operativo mismo [14]. La capa más baja es el manejo de de energía o Power
Management, la cual se encarga del manejo de batería y su reporte a la aplicación
principal. La razón por la que Google Inc. decidió crear esta capa por separado es
para dejar de manera genérica el uso de batería para diferentes dispositivos y ser
capaz de proporcionar una experiencia generalizada para todos los dispositivos.
El siguiente nivel es el Kernel de Linux que incluye la base del sistema operativo así
como los drivers de funcionamiento básico como el acceso a audio, teclado, los
binders de manejo de memoria, control de display, control básico de cámara, USB,
Bluetooth, WiFi, etc. Todos estos drivers son genéricos para traspaso y manjeo de datos
entre el kernel y el nivel de aplicación pero no es necesario utilizar los que se proveen,
se pueden agregar otros más si es necesario para explotar las capacidades de nuestro
HW.

18
Un nivel más arriba encontramos la capa de abstracción de HW donde podemos ver
los enlaces a nivel aplicación de los dispositivos habilitados en nuestro sistema como lo
son Bluetooth, Audio, cámara, sensores, etc. Aquí los desarrolladores pueden optar por
crear una interfaz con un HW diferente e integrarla al Kernel genérico si es que tienen
por ejemplo una aplicación especial para manejo de Audio, efectos de cámara, etc.
Esto permite al desarrollador y a la marca creadora del Smartphone distinguirse no solo
por sus capacidades técnicas sino por la forma en que maneja los datos para brindar
una mejor experiencia o interfaz de usuario.

Figura 7 Arquitectura del sistema Android [14]

En el siguiente nivel podemos encontrar dos capas en paralelo que trabajan como la
interfaz entre la abstracción de HW y el framework de Java: las librerías nativas de
C/C++ y el Android Runtime. Las librerías nativas están disponibles en Android ya que

19
algunos componentes de HW pueden requerirlos o incluso pueden integrarse
capacidades de sistemas mayores en Android. Esto por ejemplo ha permitido incluir
librerías o funciones gráficas avanzadas en 2D o 3D ya que el sistema tiene la
capacidad de incluir OpenGL, Media Framework o Webkit por mencionar algunos. Esto
ha permitido que los desarrolladores de reproductores de video o videojuegos puedan
crear gráficos de alta calidad en los sistemas Android de manera más intuitiva que en
iOS. Al respecto de la capa del Android Runtime, hay que destacar que esta capa
existe desde la versión 21 de la API (Android 5.0) y que fue creada para permitir un
mejor manejo de los recursos de HW y SW para las aplicaciones. El ART, por sus siglas,
está escrito para permtiir la ejecución de máquinas virtuales en dispositivos con baja
capacidad de memoria ejecutando los denominados archivos DEX que son
compilaciones en un formato de código de bytes diseñado específicamente para
Android y optimizado para ocupar un espacio mínimo en memoria. Esto se logra
basándose en un principio sencillo, cada aplicación ejecuta sus propias instancias del
ART con sus propios procesos que pueden ser compilados en el momento de la
ejecución (compilación just in time o JIT) o precompilados antes para maximizar el
manejo del sistema (compilación ahead of time o AOT). Basado en esos dos sistemas,
Android crea una reserva de memoria momentánea para cada aplicación en
ejecución sin tocar la memoria manejada por el dispositivo; esto representa un avance
significativo con los primeros sistemas Android donde el manejo de memoria podía
provocar un colapso general del sistema si una aplicación falla. Con el nuevo ART, el
sistema no colapsa, solo la sección de memoria dedicada a la aplicación que falló en
su ejecución.
Por último las dos capas más cercanas al usuario, el framework de Java y las
aplicaciones de sistema. El framework de Java es el que provee las utilidades para el
manejo y diseño de las aplicaciones como lo son listas, layouts, marcos, cuadros, etc.,
necesarios para cuadrar nuestra aplicación en las pantallas genéricas de los
Smartphone. A su vez, provee los administradores de recursos, notificaciones,
actividades, etc, que permiten la interacción con la pantalla principal de Andoid y con
el modo background cuando la pantalla se encuentra bloqueada o apagada.
La capa de aplicaciones de sistema provee utilidades genéricas para el manejo de
Smartphone regular como lo son llamadas, SMS, teclado, cámara, calendario, email,

20
etc. La intención de Google Inc. es proveer estas aplicaciones para que el
desarrollador no se preocupe por acceder a interfaces que ya están diseñadas sino
solo cambiar el framework visual de la misma. De ahí radica el hecho de que cada
marca o creador de Smarpthone puede crear su propia interfaz gráfica para el manejo
de mensajes, llamadas, correo, etc., pero en realidad en bajo nivel se encuentran
llamando a la misma aplicación genérica de Android.
Esta arquitectura permite al desarrollador mayor control de lo que decida diseñar y a
su vez un manejo más directo a los recursos. Otra parte importante es que Google Inc.
provee de manera gratuita el ambiente de programación para crear aplicaciones y
que está basado en Eclipse: Android Developer Studio. En caso de no querer utilizar
este IDE, Android provee las utilidades y el SDK para desarrollar en cualquier ambiente
que se desee. Esto da libertad al programador de usar la interfaz en la que se sienta
más cómodo y ya que el compilador principal es GCC no necesita una interfaz de
cross compiling complicada.
Por último, todo esto es gratis al ser un sistema operativo de código abierto. El
ambiente de desarrollo, el SDK, las librerías, etc., pueden ser descargadas de la página
de Android Developers con un sencillo registro gratuito. Incluso, podemos poner nuestro
propio Smartphone en modo depuración y crear nuestras aplicaciones en el mismo sin
costo alguno. El único costo se genera cuando queremos publicar una aplicación
restringida en la Android Store como una versión final.
Conociendo la arquitectura y la forma de desarrollo del sistema Android es momento
de pasar a analizar las ventajas y desventajas de este sistema contra iOS.

2.3 VENTAJAS Y DESVENTAJAS DE ANDROID SOBRE iOS

Ahora que conocemos los dos sistemas, es momento de hablar de una parte primordial
de este trabajo de investigación: la elección de la plataforma basado en el sistema
operativo
Como ya repasamos las características de ambos en cada subcapítulo dedicado a sus
sistemas operativos, nos dedicaremos a enlistar las ventas y desventajas de uno contra
otro desde la perspectiva del de más alto mercado contra el más bajo, es decir desde
Android contra iOS. Hay que notar que estas ventajas están escritas desde la

21
perspectiva de este prototipo solamente y no son generales para todas las
aplicaciones.

2.3.1 Ventajas de Android vs iOS

• Android es un sistema basado en código libre LINUX

• Las herramientas de desarrollo son gratutitas y se pueden correr en cualquier
dispositivo con una máquina virtual
• Está basado en LINUX por lo que la documentación y el soporte de la
comunidad es muy amplio
• Existe cerca de un 80% de penetración en el mercado, lo que implica que
desarrollar para este sistema tiene un mayor alcance para dispositivos en el
mercado
• Permite manejar diferentes dispositivos de HW si somos responsables de integrarlo
en el Kernel no solo lo que el fabricante nos permita
• Basado en los acuerdos de licencia, el código es propietario del desarrollador y
se puede pagar por una licencia restringida para cierta sección de memoria
• Tiene mayor compatibilidad con protocolos multimedia como BLE, NFC, WiFi
direct, etc.
• El diseño de la aplicación corre a cargo del desarrollador, por lo que la
aplicación misma puede tener un framework acorde a lo que Continental
decida para mostrar al público

2.3.2 Desventajas de Android vs iOS

• Es un sistema libre, por lo que no hay seguridad más allá de la que

implementemos nosotros
• Posee un riesgo mayor de hackeo o robo de información ya que el sistema es
muy popular

2.3.3 Elección del sistema

Como podemos ver, hay un mayor número de ventajas de Android sobre iOS siendo 3
las primordiales que nos hacen escoger este sistema. La primera, las herramientas de
desarrollo son gratuitas y el código es libre; esto nos permite desarrollar de manera más

22
sencilla la aplicación para los propósitos de este prototipo y preocuparnos más en el
manejo de datos o en el rendimiento del sistema mismo.
La segunda es que el código es propiedad del desarrollador y se puede pagar por una
licencia para bloquearlo [12] [14]. Esto es primordial ya que el sistema contempla la
posibilidad de ir a producción en masa y por tanto se busca que no sea algo que
pueda salir a la luz pública ya que contiene propiedad intelectual de Continental que
nos posiciona como ventaja de mercado sobre nuestros más cercanos competidores.
Por último y no menos importante, Android tiene una mayor integración a protocolos
multimedia. Esto nos da la libertad de elegir una variedad de sistemas dependiendo de
sus capacidades y además cambiar de protocolo si este no es el que mejor se ajuste a
nuestras necesidades. Uno de los protocolo que pretendemos usar en este prototipo es
NFC, por lo tanto comenzaremos a analizar el mismo.

2.4 SMARTPHONE Y NFC: NUEVO CANAL DE COMUNICACIÓN

El protocolo NFC ha cobrado fuerza en muchas tecnologías a nivel mundial debido a
su practicidad: con un simple toque entre dos equipos comienza una comunicación a
baja frecuencia que permite autentificarlos mutuamente y servir como disparo de otras
funcionalidades. El auge de este protocolo se ve reflejado día a día en cada vez más
rubros, desde el acceso a edificios o zonas controladas mediante una credencial con
una etiqueta NFC hasta servicios de pago sin el uso de una tarjeta de crédito o
efectivo [15].
Este protocolo es apoyado cada día por más compañías, entre ellas muchas de las
grandes manufactureras de teléfonos inteligentes como lo son Samsung, Google,
Motorola, Sony entre otras. Gracias a que los nuevos equipos integran esta interfaz vía
HW, queda solo como tarea pendiente encontrar las posibles nuevas aplicaciones por
parte de los desarrolladores de SW. Es así como encontramos que en ciudades como
Berlín, un toque NFC de nuestro Smartphone con un control maestro de la recepción
de un hotel nos permitirá convertir (por un determinado número de usos o de tiempo) a
nuestro teléfono en la llave de nuestro cuarto, trayendo ahorros en dinero al hotel y en
tiempo al usuario [15].
Gracias a este nuevo canal de comunicación nuestro Smartphone se convierte en una
herramienta que puede englobar más de una funcionalidad, permitiéndonos ahorrar

23
en una serie de complicados dispositivos externos. Es así como muchos investigadores
se han dado a la tarea por ejemplo de diseñar sistemas en los que mediante un toque
NFC podemos obtener acceso a un vehículo sin necesidad de tener una llave física del
mismo, esto pensado de manera inicial en servicios de renta de vehículos o incluso en
compartir nuestro propio automóvil con un familiar o amigo. También, este mismo
acceso nos serviría por ejemplo para cargar gasolina, reservar hoteles y un sinfín de
posibilidades de una manera sencilla, rápida y eficiente (ver figura 8).

Figura 8 Usos de NFC [15]

Este nuevo sistema de comunicación abre un canal no explorado anteriormente para

los sistemas de acceso y encendido, en el que añadiendo un sistema NFC sencillo a
nuestro vehículo podemos enlazar nuestro teléfono al mismo para que emule el
comportamiento de las llaves PASE. Recientes investigaciones [15] han demostrado
que si combinamos la potencia de un procesamiento en la nube con diferentes
dispositivos NFC así como un sistema añadido a los automóviles podemos crear una
solución inteligente y segura para la renta de vehículos.

24
El sistema trabaja de la siguiente manera (ver figura 9):

- El usuario que solicita la renta tiene una tarjeta de identificación o licencia de

manejo, las cuales en una gran cantidad de países contienen información en
una etiqueta NFC ya integrada en la misma. Esta licencia es leída por el servicio
de renta para guardar los datos del usuario.

Figura 9 Renta de vehículo vía NFC [15]

- La etiqueta NFC se asocia al teléfono mediante una aplicación del proveedor

de la renta, de forma que solo ese teléfono pueda ser identificado como válido
por el vehículo. El proveedor de servicio activa en la nube los permisos para que
el automóvil acepte esta etiqueta NFC como válida, convirtiendo a nuestro
Smartphone en una llave emulada.
- Una vez que nuestro teléfono tiene los permisos, nos acercamos al vehículo y
mediante un contacto NFC, el Smartphone emula el comportamiento de una
llave inteligente, dándonos acceso al automóvil y permitiéndonos su encendido
(ver figura 10).

25
 Figura 10 Acceso al Vehículo mediante NFC [15]

De esta manera podemos demostrar como una aplicación NFC que no representa un
cambio drástico en el sistema del automóvil nos permite el uso de un Smartphone
como llave. No obstante, este sistema requiere la interacción de un tercer elemento
que es la programación del usuario y sus permisos mediante el proveedor del servicio.
También, tiene en contra el tiempo requerido para el contacto NFC entre el
Smartphone y el vehículo para garantizar el acceso al mismo.
Sin embargo, el propósito inicial de esa investigación era demostrar que se pueden
conceder permisos a usuarios externos a este sistema sin debilitar la seguridad del
mismo y de una forma eficiente y controlada. Con esta primera etapa en mente,
podemos notar que el protocolo NFC es una poderosa herramienta para lograr nuestro
cometido.
Investigaciones previas [16] han demostrado que una vez abierto este vínculo con el
vehículo podemos expandir los horizontes del sistema de manera que podemos
establecer una red vehicular utilizando los Smartphone como catalizadores de las
mismas.

2.5 REDES DE AYUDA VEHICULAR MEDIANTE SMARTPHONE

Ahora que nuestro Smartphone tiene acceso a la computadora central gracias a la
comunicación NFC, podemos utilizar todo su poder de procesamiento como un
cerebro extra que nos ayude a comunicar diferentes estados del vehículo a redes
cercanas o incluso usar el HW del teléfono como un auxiliar. En la universidad de Seúl
(16) se demostró que combinando el uso de las redes 3g y 4g LTE con los sensores del
teléfono podemos crear algoritmos avanzados por ejemplo para detección de
potenciales peligros en los caminos, tráfico excesivo, fallas mecánicas, etc. Estos
algoritmos trabajarían mediante aplicaciones en el teléfono que utilizarían las redes
26
centrales para enviar la información a un contenedor central o antena que se
encargaría de enviar esta información a todos los equipos en la red que contengan la
misma aplicación (ver figura 11).

Figura 11 Redes de comunicación entre vehículos [16]

Esto quiere decir que podemos manipular la información enviada por las antenas
mismas del teléfono para crear una red de comunicación entre vehículos. Si tomamos
en cuenta que los parámetros de frecuencia de las redes LTE y GSM coinciden con los
usados en las llaves inteligentes automotrices (ver Tabla 1), podemos deducir que es
muy posible emular de manera total la forma en la que una llave se comunica a un
vehículo mediante el uso de una aplicación en el Smartphone.

27
 Tabla 1 Frecuencias GSM / LTE / Keyfob [17]

Combinando esta tecnología con el protocolo NFC, podemos garantizar que desde el
punto de vista teórico es posible darle permiso a un Smartphone para funcionar como
llave del vehículo de forma que una aplicación realice el protocolo de transmisión
necesario y envíe los datos vía redes celulares a nuestro automóvil.
Las aplicaciones posibles a esta combinación de tecnología no se detienen ahí sino
que pueden expandirse ahora que tenemos un canal de comunicación seguro y
estable. En investigaciones conducidas por la universidad de Corea [18] se ha
demostrado que un Smartphone puede servir de control remoto para un vehículo
pequeño y así crear un sistema anti-intrusos. Este sistema consiste en una cámara
instalada en un pequeño vehículo móvil que envía la imagen a través de Internet a
una aplicación en el teléfono. La aplicación nos permite controlar el vehículo a fin de
identificar al posible intruso y tener una imagen clara del mismo.
Si consideramos que ya tenemos un vínculo entre el automóvil y el teléfono o “llave”,
no suena descabellado añadir alguna opción en la que una mini cámara en el auto
monitoree en tiempo real nuestro vehículo y que nos envíe una alerta en caso de un
posible intruso. La aplicación puede permitirnos por ejemplo una retroalimentación de
forma que, en caso de ser necesario, nos permite encender la alarma sonora a
distancia.
Otra clase de aplicaciones añadidas pueden ser tomadas de las investigaciones
conducidas en la Universidad Politécnica de Valencia [19], en las que mediante el uso
de los sensores biométricos del Smartphone podemos determinar el comportamiento
del conductor para darle al mismo posibles consejos para mejorar su conducta al
28
volante así como su forma de manejo. Ahora bien, si contamos ya con el enlace al
automóvil, podemos pasar información en tiempo real del desgaste de las llantas,
estatus del motor, etc., de forma que podemos crear una estadística certera de
nuestros fallos al manejar y de los efectos secundarios que causa esto en nuestro
automóvil. En base a estas estadísticas por ejemplo, podemos deducir que frenamos o
aceleramos bruscamente lo cual a la larga representa un mayor consumo de
combustible.
En Nashville se ha estado trabajando en un sistema [20] que detecte mediante el
acelerómetro y los sensores del Smartphone un posible accidente en las carreteras y
calle e informe usando la infraestructura de la red de telefonía celular de manera
automática a las autoridades pertinentes. De esta manera, se puede reducir el tiempo
de respuesta de las autoridades e incluso informar a los contactos de emergencias (ver
figura 12).

Figura 12 Sistema de informes de accidentes [20]

Combinando los sensores del teléfono mismo con la información recabada del
automóvil (debido al vínculo con la “llave”) podemos potenciar esta tecnología de
forma que no solo sea un indicador de un accidente ya ocurrido sino darnos
advertencias de posibles fallas mecánicas presentes que sean potenciales riesgos. Esto
depende también en gran medida de la información que se envía mediante el
protocolo de comunicación llave – vehículo, sin embargo muchos fabricantes actuales
incluyen información de seguridad en estos mensajes para indicar visualmente en la
llave posibles fallas.
Como se puede notar, los trabajos previos proveen la información suficiente para
permitirnos pensar en que la aplicación deseada en este trabajo es factible al menos
29
de manera teórica. La gran mayoría de los autores consultados hacen referencia a
estos nuevos vínculos de manera individual y sugiriendo algunas pequeñas
modificaciones a la arquitectura de los vehículos. Esto nos ayuda a concluir que
muchos investigadores prefieren hacer funcionar al vehículo con los sistemas modernos
en lugar de utilizar estos sistemas y acoplarlos al modelo de trabajo de los automóviles.
Esta simple diferencia puede facilitar el trabajo así como ahorrar costos, ya que el
trabajo se vuelve puramente un desarrollo de SW y un canal de comunicación entre el
automóvil y el Smartphone. Con el canal resuelto, se pueden añadir muchas otras
funcionalidades como algunas de las ya explicadas en este documento de forma que
se resuelve o mejora un problema básico a la vez que se exploran nuevas áreas de
investigación.

30
3 PROCEDIMIENTO DE INVESTIGACIÓN
El proceso de investigación se basó en el desarrollo de una llave inteligente de acceso
actual. Primero se comenzó a describir un caso de uso así como el protocolo mediante
el cual dicha llave interactuaría con el vehículo para posteriormente comenzar a
desglosar los detalles y la factibilidad de los métodos o tecnologías sugeridos.
Usando este tipo de metodología, similar al desarrollo de una llave inteligente actual,
se pretende robustecer el funcionamiento del producto final ya que afianza las partes
primero, modificando o descartando objetivos secundarios hasta lograr el objetivo
general. Considerando que el objetivo es crear un nuevo sistema de acceso mediante
una aplicación de SW en un Smartphone, se partió definiendo el caso de uso más
sencillo primero: acceso remoto.

3.1 ACCESO REMOTO SIN LLAVE

El acceso remoto sin llave se basa en un par de principios sencillos: el acceso debe ser
seguro y a una distancia considerable. Por lo general, esta distancia es definida por la
marca o manufacturera del vehículo y oscila entre los 10 y 50 metros
aproximadamente.
Partiendo como base en esta distancia se decidió descartar el uso del protocolo NFC
ya que el mismo no funciona en un rango mayor a 5 cm [21] entre los dos dispositivos
que se encuentren comunicándose. Esto provocaría que el traspaso de datos se deba
realizar a escasa distancia de la puerta del vehículo, representando una seria
desventaja considerable contra las llaves actuales.
En el caso del aprendizaje de nuestro dispositivo y el traspaso de los diversos datos de
seguridad y encriptación, se tendría que desarrollar un dispositivo NFC en la consola
central o en el panel del vehículo de forma que se garantice un traspaso seguro de la
información. Esta clase de dispositivo ya existe en los vehículos actuales pero
funcionando a 125 KHz y con una distancia igual a la mencionada de escasos
centímetros. Ya que uno de los objetivos iniciales de esta investigación es reducir costos
en la medida de lo posible, es por ello que también para esta funcionalidad se decidió
descartar el uso de NFC.
Considerando los protocolos de comunicación ya incluidos en un Smartphone se
decantó por el uso de BTLE para reemplazar el protocolo NFC debido a dos razones
básicas: el alcance según el Core de BTLE versión 4.2 [22] establece la distancia óptima

31
de comunicación en 10 metros y además permite una conexión segura punto a punto
para la transmisión de datos. Cabe destacar también que una alta gama de vehículos
ya cuentan con receptores BTLE, por lo que solo es necesario adaptar su uso a nuestras
necesidades.
Gracias al uso de BTLE en lugar de NFC, generamos dos posibilidades para la
transmisión con el vehículo: enviar una trama vía BTLE o comunicarnos con un
dispositivo intermedio que traduzca la señal al protocolo RF propio de la arquitectura
del mismo. Para propósitos prácticos se decidió generar el caso de uso de una
transmisión directa a través de BTLE. La razón primordial de esto es demostrar que no se
requiere un HW “intérprete” sino que con el solo uso del Smartphone podemos acceder
y/o encender nuestro vehículo.

Figura 13 Caso de Uso Alterno con dispositivo RF intermedio

El caso de uso queda entonces de la siguiente manera: el usuario presionará un

botón en la aplicación del Smartphone, la cual se abordará más adelante, generando
una transmisión a través de BTLE que será recibida por alguno de los dispositivos en el
vehículo. Este dispositivo enviará una señal a la computadora central emulando
nuestra llave original, lo cual permite no modificar la arquitectura del vehículo.

32
 Figura 14 Caso de Uso para Remote Keyless Entry

3.2 ACCESO Y ENCENDIDO PASIVO (PASE)

Para el caso de uso de PASE se facilitan las cosas con el uso de BTLE. Los sistemas PASE
tradicionales basan sus algoritmos de localización en la medición de la intensidad de
señal recibida por las antenas o RSSI por sus siglas en inglés. Al recibir estos datos de
diferentes antenas, la llave inteligente envía un paquete de datos a través de RF a fin
de que el vehículo permita su localización y permita el acceso en la zona respectiva.
El mecanismo para el encendido pasivo es muy similar, primero se determina si la llave
inteligente se encuentra dentro del vehículo usando un algoritmo similar al de
localización; posteriormente si las credenciales de seguridad coinciden con nuestro
vehículo se permite el encendido del motor, caso contrario se muestra en la consola
central un mensaje de error.
El protocolo BTLE ya cuenta en la estructura de sus mensajes con la medición de RSSI
por lo que basta con utilizar más de un dispositivo BTLE fijo a manera de antenas y crear
un algoritmo de localización en la aplicación de nuestro Smartphone. El contenido de
dicho algoritmo es una propiedad intelectual que no se describirá, sin embargo se
mostrará la forma en la que la aplicación determina la zona.
De esta forma, el caso de uso para PASE con el Smartphone es exactamente el mismo
de una llave inteligente actual: la llave mide la intensidad de las señales BTLE de las
antenas y envía un paquete por BTLE al receptor en el vehículo. Este recibe el paquete
y decodifica la zona, enviando a la computadora central una señal de apertura o
encendido dependiendo de la función requerida. Esto de manera directa facilita y
reduce el costo de un sistema PASE actual ya que la arquitectura base es igual pero
con una tecnología más novedosa.

33
 Figura 15 Caso de Uso para PASE

Ahora que tenemos definidos los dos casos de uso, se procede a la elección del HW y
al diseño del prototipo. Cabe destacar que este prototipo será la base de un sistema
completo por lo que su complejidad será limitada y definida en partes.

3.3 ALCANCE DEL PROTOTIPO

La intención del prototipo es la de convertirse en la base de un proyecto real a largo
plazo. El primer prototipo solo sirve de base para demostrar que los casos de uso
elegidos así como los objetivos planteados al inicio pueden ser alcanzados.
El prototipo consiste de 4 elementos básicos:
1) Módulos de antenas BTLE
2) Aplicación Android en un Smartphone
3) Módulo receptor BTLE en el vehículo
4) Módulo traductor a protocolo automotriz
Uno de los objetivos del prototipo es no modificar la arquitectura del vehículo que sea
utilizado en pruebas, esto con la finalidad de poder montar el prototipo en un vehículo
real y realizar una demostración a marcas o productores potenciales del mismo. Con
base en este lineamiento se procedió a la búsqueda del HW necesario para el
prototipo.

34
3.4 MATERIALES Y MÉTODOS
La aplicación para el teléfono inteligente fue desarrollada en Android Studio Versión
Para la creación del prototipo se utilizaron los siguientes materiales:
- Smartphone Motorola Nexus 6 con Android 5.0
- Smartphone Sony Xperia Z5 con Android 6.0 (sólo para pruebas en otro HW)
- Tarjeta de desarrollo Kinetis MKL25Z128VLK4 de Freescale
- uEnergy CSR101X Development Kit
- CSR1010 Evaluation Board
Evidentemente para las pruebas finales de la implementación se requirió del acceso a
un vehículo y a una computadora central, BCM, modificada para probar el concepto.
Ya que el diseño de estos está sujeto a la marca productora de los vehículos no se
profundizará en el diseño de este HW.
Las tarjetas de evaluación CSR1010 fueron utilizadas como simulación de antenas para
las pruebas de RSSI y de acceso y encendido pasivo. Estas tarjetas usan un micro
controlador de 16 bits CSR1010 con 64 Kb de RAM y 64 Kb de ROM. Estas tarjetas están
preparadas para trabajar con BTLE 4.1 y 4.2 ya que poseen integrado el código de la
pila de BTLE permitiendo solo modificar los servicios y perfiles que los usuarios requieran.
Estas tarjetas de evaluación cuentan también con integrados para permitir la salida de
datos en comunicación serial así como conexión USB para su alimentación y
programación. Internamente poseen un conversor de SPI a USB para poder ser
programadas con una interface sencilla a través de cualquier computadora.

Figura 16 Tarjeta de evaluación CSR1010

35
Las tarjetas cuentan también con un circuito tanque para maximizar la medición y
transmisión de datos en la funcionalidad de RSSI. Es precisamente esta característica
por la cual se eligieron estas tarjetas de evaluación sobre otras en el mercado, ya que
redujeron drásticamente el esfuerzo a solo desarrollo de SW.
En el caso del kit de desarrollo uEnergy CSR101X utiliza la misma tarjeta de evaluación
con un CSR1010 y añade el módulo para programar la tarjeta por conexión USB. Esta
tarjeta se utilizará como primera interfaz del receptor en el vehículo.

Figura 17 Kit de desarrollo uEnergy CSR101x con programador

Esta tarjeta de desarrollo se utilizó para el módulo receptor en combinación con la

tarjeta Kinetis de Freescale. La tarjeta de desarrollo tiene la capacidad de dar una
salida de datos en UART a diferentes tasas de transferencia que van desde los 9.6 Kbits
por segundo hasta los 112.5 Kbits por segundo. Para este prototipo, se configuró la tasa
en 112.5 Kbits por segundo para usarse como modo de comunicación intermedio
desde el canal BTLE a la computadora central del vehículo. Esta velocidad fue elegida
ya que es necesario presentar un resultado de localización al menos cada 10 ms.

Figura 18 Tarjeta KL25Z de Freescale (NXP)

36
El fin de tener esta tarjeta que se comunique a través de UART radica en la necesidad
de crear un intérprete para la computadora central del vehículo ya que esta se
comunica con los módulos internos a través de CAN o LIN. Debido a que la intención es
no modificar la arquitectura del vehículo, se utilizarán mensajes fijos predefinidos que
correspondan a una llave real ya autentificada.
La tarjeta recibirá mensajes de UART del módulo receptor CSR y los traducirá en
mensajes fijos de K-Line que necesita la computadora central de vehículo. Hay que
destacar que K-Line es una UART en voltajes de protocolo LIN por lo que se necesitó de
un circuito sencillo que eleve los voltajes a los usados por LIN. Para esto se utilizó el
MCP2021 de Microchip el cual eleva los voltajes de 3.3 de una UART sencilla a los 12 V
requeridos por LIN.

Figura 19 LIN Transceiver

La tasa de transferencia de los mensajes que el vehículo necesita recibir es de 20.8
Kbits por segundo, por lo que la tarjeta Kinetis no solo cambia el contenido del mensaje
dependiendo de lo que haya recibido, sino que también transmite en la salida a la
tasa necesaria.
En base a todo el HW ya descrito, la siguiente pieza por describir es la aplicación en el
Smartphone. En el desarrollo del prototipo se decantó por el uso de Android debido a
su mayor sencillez comparado con el desarrollo en iOS; sin embargo, no se descarta a
futuro implementarlo en este otro sistema operativo.
La aplicación se desarrolló mediante Android Development Studio en un formato de
capas:
- La capa baja mide el RSSI y calcula la zona. Esta capa se desarrolló como una
librería de solo lectura ya que el algoritmo es propiedad intelectual protegida.
- La capa de transporte se encarga de recibir y transmitir los datos por BTLE.

37
 - La capa gráfica o framework muestra un vehículo y sus zonas así como los
botones para las acciones remotas.
El ícono de la aplicación refleja el logo de Continental, el cual se muestra nuevamente
al abrir la misma pero en una pantalla visual aún mayor. Bajo este logo se muestra una
imagen 2D de un vehículo con las zonas a su alrededor. Estas zonas se iluminaran
cuando nos acerquemos al vehículo con nuestro Smartphone de forma que nos
indique la posición que está siendo determinada.

Figura 20 Pantalla de Inicio de la aplicación

Como se describirá posteriormente en los resultados, este mapa de dos dimensiones

también se puede sustituir por una simple imagen que cambia de color dependiendo
de la zona en la que se encuentre nuestro Smartphone con respecto al vehículo. Estas
zonas y sus respectivos colores son los siguientes:
- Gris: no detectado vehículo cercano.
- Azul: rango de RKE. Naranja: rango de encendido de luces y acceso pasivo
- Verde: rango para encendido pasivo

38
Para el caso de los comandos RKE, se crearon botones sencillos en la pantalla inicial de
la misma aplicación con cada uno de las posibles acciones remotas que realiza
nuestra llave. Estos botones solo se activan si estamos en la zona de RKE lo cual en el
mapa se activa con un color azul. Si estamos en modo de código de color, los botones
no se muestran en la misma pantalla.

Figura 21 Botones de RKE en la aplicación

La aplicación como tal funciona de una manera muy sencilla. Se deben de introducir
las direcciones MAC de cada uno de los dispositivos BTLE que funcionan como antenas
así como del receptor en el vehículo y seleccionar que posición de antena o receptor
representa cada uno de nuestros dispositivos. Una vez que se han introducido estos
datos, se enciende el protocolo o servicio de conexión en las opciones de la misma
(ver figura 22) y nuestra aplicación comenzará a medir la posición respecto a las

39
antenas mostrando en pantalla ya sea en el código de colores o en el mapa 2D la
posición aproximada.

Figura 22 Pantalla para habilitar configuraciones. La información dentro es propiedad

intelectual

Para el caso de las funcionalidades RKE, primero se debe estar en el rango RKE
(naranja) para que nuestra aplicación habilite los botones y estos se puedan presionar
en la pantalla táctil. Cuando un botón es presionado, un mensaje BTLE se envía a
nuestro receptor en el vehículo el cual lo traducirá a un mensaje UART de 115.2 Kbits
que será enviado a la tarjeta Kinetis. La tarjeta se encargará de interpretar este
mensaje y transformarlo en el correspondiente mensaje de K-Line que será enviado a la
computadora central. Si este mensaje es el correcto, entonces la computadora central
procederá a ejecutar la acción requerida: apertura de seguros, cierre de seguros,
encendido remoto, apertura de cajuela, etc.

40
En el caso de PASE, nuestra aplicación está constantemente midiendo su posición
contra el vehículo pero solo envía esta información a través de BTLE al receptor si es
que se toca la manija de una de las puertas, el botón de la cajuela o el botón de
ignición en la consola central. En todos estos escenarios, la computadora central envía
una petición por K-Line a la tarjeta Kinetis. La tarjeta convierte este mensaje a la tasa
de 115.2 Kbits y se lo envía al receptor BTLE; ya que los aparatos BTLE son de doble vía,
el receptor solicita la información de localización a nuestra aplicación y recibe la
misma mediante otro mensaje BTLE. Si la zona coincide con la petición realizada por la
computadora central, entonces la acción es realizada.
Para poder realizar la prueba final en un vehículo es necesario adaptar la tarjeta
CSR1010 para la comunicación UART así como la Kinetis. Para mayor practicidad todo
esto se puso dentro de una caja de plástico con los conectores externos listos para su
ensamblaje en la línea de K-Line del vehículo.

Figura 23 Conexiones en la tarjeta CSR1010 para el receptor

Este diseño nos permite el poder tener un mayor dinamismo en las pruebas en vehículo
final así como la facilidad de transporte en caso de requerirse una demostración en
otra localidad. Cabe destacar nuevamente que esta implementación en vehículo
funciona en base a un módulo modificado y una conexión que no se mostrará en la
descripción de este trabajo de tesis.

41
 Figura 24 Tarjeta Kinetis y conexión en caja plástica

Ya que los resultados en el prototipo final y en el vehículo no pueden ser mostrados, se

realizó una prueba con los módulos BTLE y la aplicación en un laboratorio. Estos
resultados prueban claramente el funcionamiento de la aplicación así como de todas
las interfaces creadas exceptuando la comunicación final con el vehículo y por ende
del intérprete UART a K-Line. Resultados de esta demostración fueron recabados por la
prensa norteamericana en diversos artículos [23] que pueden ser consultados en la red.
Esta demostración fue llevada a cabo por gerentes así como líderes de proyecto con
clientes potenciales en Estados Unidos.

42
4 RESULTADOS
Se utilizaron 3 módulos BTLE para demostrar el concepto en un ambiente controlado de
laboratorio. Estos módulos se conectaron a diversas computadoras solo con el fin de
preservarlos encendidos durante el desarrollo de la demostración. Primero se procedió
en la aplicación a demostrar que a una distancia de más de 10 metros el código de
color muestra una zona inaccesible.
Para esto, los 3 módulos fueron localizados dentro de un cubículo específico y así
poder caminar a los alrededores como si de un vehículo se tratase. También, este
experimento se realizó sin otros dispositivos BTLE en las cercanías que pudieran mostrar
interferencias.

Figura 25 10 metros, zona no detectada

Previamente introducidos los datos de las antenas en nuestra aplicación así como
encendido el servicio, se procedió a alejarse a una distancia de más de 10 metros.
Como se muestra la figura 25, el código de color efectivamente refleja que estamos en
un rango no detectado mediante la iluminación de nuestra pantalla en gris. Se eligió
mostrar el código de color en esta demostración en lugar del mapa 2D, ya que al no
estar usando módulos calibrados en una posición calculada veríamos zonas
intermitentes o cambiantes incluso sin movernos.

43
El siguiente paso consistió en acercarse a una distancia de 5 metros pero tomando en
cuenta una posición cercana a la cajuela de nuestro vehículo. A esta distancia y
considerando la zona, nuestra aplicación debe reflejar el rango en azul lo cual implica
una zona donde los comandos RKE son permitidos como se muestra en la figura 26. Ya
que se utilizó el modo de código de color en la aplicación, los botones de RKE no son
visibles en esta pantalla.

Figura 26 Zona RKE

Después de pasar esta zona, la aplicación cambiará el código de color pero seguirá
mostrando en pantalla el mensaje de RKE en zona. Esto es debido a que aunque ya
pasemos a las zonas de acceso y encendido pasivo, los comandos RKE aún son
permitidos al igual que en las llaves reales.
Posteriormente nos acercamos a una distancia no mayor a 2 metros pero fuera del
cruce de las antenas. Esto es con la intención de simular que estamos cerca del
vehículo pero no dentro del mismo. Como se observa en las figuras 27 y 28, el código
de color muestra naranja, por lo que estamos en una zona de acceso pasivo permitido
pero el mensaje de RKE permitido se muestra en pantalla como ya se ha explicado con
anterioridad.
44
 Figura 27 Zona de PASE - mensaje de RKE en rango

También como se observa en la figura 28, estamos ya muy cerca de las antenas. Se
guardó una distancia no mayor a un metro demostrando una capacidad de
localización cercana a la de los sistemas PASE actuales.

Figura 28 Zona PASE - rango de 1 metro

45
El módulo que se observa sin conectar a las dos computadoras en la imagen 28 sería el
equivalente a nuestro receptor BTLE. En este módulo se verificó con un osciloscopio que
en los pines de comunicación UART se estuviera realmente enviando mensajes a la tasa
de transferencia deseada. Estos mensajes si estaban siendo enviados y se
decodificaron de manera correcta en el caso de un envío RKE así como de las zonas
de PASE.
Finalmente como se observa en la figura 29, se localizó el Smartphone entre las dos
antenas. Esto simularía que nuestra llave se encuentra dentro del vehículo y por tanto
la zona cambiaría a verde en el código de color. Como se puede notar, de la figura 28
a la 29 solo existe un cambio en la posición en la que se encuentra el Smartphone
ahora localizado entre las dos antenas. Esto demuestra nuevamente que el algoritmo
de localización está funcionando.

Figura 29 Zona PASE - encendido pasivo posible

Con base a estos resultados se procedió a realizar un estudio más exhaustivo en

vehículo. Estos resultados arrojaron que el sistema es altamente confiable en un
ambiente controlado pero que en un vehículo real se observan variaciones en las
zonas y en la distancia debido a las interferencias existentes en el ambiente.
Para incrementar la confiabilidad del sistema, se incrementó evidentemente el número
de antenas. Esto robusteció el algoritmo de localización y lo fortaleció contra ruidos
ambientales. Sin embargo, el sistema presentaba fallas menores en base a la batería
46
restante en el Smartphone así como dependiendo de la línea de vista contra las
antenas y la localización de las mismas.
Todos estos resultados en vehículo llevaron a la conclusión de que el sistema aún es
perfectible y que su comparativa a un sistema PASE actual es de una eficacia
reducida en un 35%. Los datos recabados en la medición en vehículo fueron
restringidos a petición de la marca que permitió el uso del mismo por lo cual solo se
muestra el resultado calculado final.

4.1 CONCLUSIONES
El sistema es funcional por lo que se concluye que un Smartphone si puede ser utilizado
como reemplazo o segunda alternativa de una llave inteligente actual. También se
demuestra que el costo no se dispara al usar elementos sencillos que reemplazarían los
complicados y costosos circuitos de LF actualmente por lo que se concluye que puede
ser un sistema de bajo costo si el rendimiento del algoritmo se incrementa. Esto lo
podemos afirmar ya que el prototipo no incluyo ningún gasto fuerte más allá del
desarrollo mismo del SW, los equipos usados en HW son de un costo similar o menor al
de una llave inteligente.
Se realizó un estudio detallado para corroborar estas cifras, sin embargo debido a su
complejidad y a la información que se presentará con las manufactureras, no se
ofrecerán muchos detalles al respecto más allá de los posibles reportes de prensa.
De la misma forma, se realizó una comparación sencilla de las grandes funcionalidades
de una llave inteligente actual contra las funciones ofecidas por un Smartphone usado
como tal (ver tabla 2). Podemos darnos cuenta de que el sistema presenta en general
el mismo nivel funcional que una llave inteligente y esto basado solo en un desarrollo
de SW en el teléfono mismo.

47
 Funcionalidades Llave Inteligente Smartphone
Acceso Remoto (RKE) Sí Sí
PASE Sí Sí
Luces de bienvenida Sí Sí
Localización Sí Rango Limitado
Rango Clásico 20% de Clásico
Aprendizaje en No Sí
multiples vehículos
Encendido Remoto Sí Sí
Seguridad Sí Sí
Cifrado Sí Sí
Tabla 2 Comparación funcional de una llave y el Smartphone
Sin embargo, se demuestra también que el sistema aún no es igual o más eficaz que los
sistemas PASE actuales a la vez que se ejemplificó que el protocolo NFC o la transmisión
directa en la banda de radio frecuencia usando solo el Smartphone no son factibles.
En el caso de esta última aseveración, sí se intentó transmitir en radio frecuencia
usando la banda GSM-2 y GSM-3 del HW del teléfono pero el acceso a la modificación
de este código está restringido a utilizar el mismo formato de mensajes y datos. Esto
implicaría que la arquitectura del vehículo debe ser modificada o en su defecto gastar
un mensaje SMS o una llamada cada que nuestra aplicación deba transmitir. Para
lograr uno de estos dos propósitos se requeriría del permiso y ayuda explícita de la
manufacturera del Smartphone, volviendo la solución poco portable, o entrar en un
debate legal por el uso de una red de telecomunicaciones para un propósito no
contemplado.

4.2 APORTACIÓN DE LA TESIS

Entre las principales aportaciones de esta tesis podemos listar la creación de un
algoritmo de SW para localización básica en 3D mediante BLE; este algoritmo es la
base de un nuevo producto desarrollado para el mercado automotriz consistente en
una llave virtual para vehículos de renta ya disponible en Estados Unidos. A la vez, esta
tesis aporto un diseño básico de HW con conectividad BLE, NFC, LF y RF que se ha
utilizado en distintas variantes de productos Continental; el diseño ha sido adaptado y
modificado en al menos 4 productos diferentes que se están comercializando para
diferentes marcas y en distintos mercados a nivel mundial.

48
4.3 RECOMENDACIONES
La creación de este prototipo permitió no solo demostrar el concepto del uso de la
tecnología BTLE para el acceso y encendido de nuestro vehículo sino que creó un
nuevo módulo interno para la recepción y transmisiones de señales BTLE. Esto permite
que a futuro se puedan usar otras funionalidades del vehículos más allá de las propias
de acceso y encendido.
Cabe destacar que este prototipo se creó con unidades disponibles de manera
inmediata y no con los microcontroladores más potentes en la industria debido a la
dificultad o precio de los mismos. Una mejora posible es el cambio a
microcontroladores más potentes al menos en la parte de comunicación BTLE.
A su vez, se enfocó la aplicación en dispositivos Android debido al corto tiempo para
implementación y pruebas pero en un futuro se vuelve mandatorio el crear una
variante para dispositivos iOS. De esta forma se creará un dispositivo capaz de
funcionar en la gran mayoría de Smartphones disponibles en el mercado.
En general, se enlistaron mejoras a nivel funcional para una próxima etapa de este
prototipo. Algunas mejoras que se pueden considerar son las siguientes:
- Cambio de microcontrolador en la etapa BTLE
- Aumentar el número de dispositivos BTLE para la medición de posición
- Mejorar el algoritmo de SW que determina la detección del Smartphone y el
posicionamiento del mismo
- Calibración más detallada basado en diversos Smartphone para minimizar el
impacto del cambio de dispositivo
Existen muchas mejoras y variaciones posibles en este dispositivo que ya están en
marcha pero debido a la protección de propiedad intelectual no se puede ahondar
mucho en el tema.
Una de las grandes posibilidades que se abren con este trabajo es el uso de las llaves
compartidas. Con un poco de seguridad y cifrado incluido en los teléfonos y
programas podríamos crear un sistema que funcione por ejemplo para automóviles de
renta o servicios policiales. Para ello es evidentemente necesario que exista soporte de
las marcas y grandes manufactureras automotrices para no infringir leyes o acuerdos
de propiedad intelectual.

49
De la misma manera se pueden crear servicios compartidos con la nube que nos
permitirían manejar todo de forma central y en servidores seguros. Todo esto reduciría
dramáticamente los costos y aumentaría las ganancias ya que no se necesita para
nada de un HW o equipo más allá del Smartphone que es un gasto que corrió por el
usuario mismo. Por tanto, todo el costo de materiales, diseño, homologaciones, estudios
de electrónica, etc., se ahorra completamente.

50
5 REFERENCIAS
[1] Lemke, Kerstin, Paar, Christof y Wolf, Marko. Embedded Security in Cars: Securing Current and
Future Automotive IT Applications. Berlin : Springer-Verlag Berlin Heidelberg, 2006. ISBN 978-3-540-
28384-3.

[2] Bräunl, Thomas. Automotive Systems. Embedded Robotics. Berlín, Alemania : Springer Berlin
Heidelberg, 2008, págs. 415-438.

[3] Scalable Architecture Approach with Platform Products to Implement Advanced Car-Body E&E System
in Emerging markets. Ding, Dayu. Shangai, China : Springer-Verlag Berlin Heidelberg, 2013. Proceeding of
FISITA 2012 World Automotive Congress. págs. 33-42.

[4] NFC Forum. NFC Forum . NFC Forum Web site. [En línea] Junio de 2006. [Citado el: 29 de Agosto de
2013.] http://www.nfc-forum.org/.

[5] Nokia. Nokia Field Force NFC. Nokia NFC technology Web site. [En línea] Junio de 2006. [Citado el: 22
de Agosto de 2013.] http://nokia.com/fieldforce.

[6] Asociación Mexicana de la Industria Automotriz. Asociación Mexicana de la Industria Automotriz -

AMIA. [En línea] AMIA, 11 de Junio de 2017. [Citado el: 10 de Febrero de 2014.]
http://www.amia.com.mx/ventasp.html.

[7] Continental Automotive Corporation. Continental Corporation. [En línea] Continental Automotive
Systems, 11 de Junio de 2017. [Citado el: 6 de Junio de 2016.] https://www.continental-
corporation.com/en/products-and-innovation/innovation/digitalization.

[8] A, COLAN M. Universal keyless entry system for remotely controlling . US2014104771-A1 Estados
Unidos, 17 de Abril de 2014. Automotive Electrics.

[9] GANZ B L, LIEDBLAD B M, THIEMANN H. Remote control system for controlling vehicle.
US2014172197-A1 Estados Unidos, 19 de Junio de 2014. Digital Computers; Aviation, Marine and Radar
Systems.

[10] Continental Automotive. Access Control Systems – Providing Effective Protection and More
Convenient Vehicle Access. [En línea] Continental . [Citado el: 16 de Julio de 2015.] http://www.conti-
online.com/www/automotive_de_en/themes/passenger_cars/interior/body_security/pi_oled_display_e
n.html?page=5.

[11] Taplin, Bruce. Smartphone History: Evolution & Revolution. San Francisco, California : Amazon Digital
Services LLC, 2013.

[12] Apple Inc. Developer Guide for iOS (only registered users). [En línea] [Citado el: 8 de Abril de 2018.]
https://developer.apple.com/iphone/gettingstarted/docs/iphoneosoverview.action.

[13] Stat Counter. Press Release, Android overpass for first time. [En línea] 3 de Abril de 2017. [Citado el:
15 de Abril de 2018.] http://gs.statcounter.com/press/android-overtakes-windows-for-first-time.
51
[14] Google Inc. Android Developers. Android Developers. [En línea] 2002. [Citado el: 15 de Abril de
2018.] https://developer.android.com/topic/libraries/architecture/guide.html.

[15] Kasper, Timo, y otros. Rights Management with NFC Smartphones and Electronic ID Cards: A Proof
of Concept for Modern Car Sharing. Berlin : Springer-Verlag Berlin Heidelberg, 2013.

[16] A Feasibility Study and Development Framework Design for Realizing Smartphone-Based Vehicular
Networking Systems. Park, Yongtae, y otros. 11, Seúl, Corea del Sur : IEEE Transactions, 2014, Vol. 13.

[17] International Telecommunication Union. International Telecommunication Union - Radio

Regulations Navigation Tool. [En línea] ITU, 2016. [Citado el: 22 de October de 2018.]
https://www.itu.int/pub/R-REG-RRX-2016.

[18] Chang-Ju, Ryu. The Design of Remote Control Car Using Smartphone for Intrusion Detection.
Gwangju, Corea : Springer Science+Business Media Dordrecht, 2012.

[19] Meseguer, Javier E., y otros. DrivingStyles: a smartphone application to assess driver behavior.
Valencia : IEEE, 2013.

[20] Thompson, Chris, y otros. Using Smartphones to Detect Car Accidents and Provide Situational
Awareness to Emergency Responders. Nashville : Institute for Computer Sciences, Social Informatics and
Telecommunications Engineering, 2010.

[21] NFC Forum. NFC Forum Organization. [En línea] [Citado el: 29 de Enero de 2017.] http://nfc-
forum.org/what-is-nfc/about-the-technology/.

[22] SIG, Bluetooth. Bluetooth SIG Organization. [En línea] 2 de Diciembre de 2014. [Citado el: 31 de
Enero de 2017.] https://www.bluetooth.com/specifications/adopted-specifications.

[23] Murphy, Tom. Wards Auto. [En línea] 1 de Septiembre de 2016. [Citado el: 30 de Enero de 2017.]
http://wardsauto.com/technology/can-smartphone-replace-key-fob.

52
6 ANEXOS
6.1 Anexo A – CSR1010 Datasheet

A
6.2 Anexo B – BTLE Core Specification 4.2

B
6.3 Anexo C – LIN Transceiver MCP2021A Datasheet

C
6.4 Anexo D – Kinetis KL25Z Datasheet