1

UNIVERSIDAD TECNOLGICA EQUINOCCIAL
FACULTAD DE CIENCIAS DE LA INGENIERA

CARRERA DE INGENIERA MECATRNICA

CONTROL GSM PARA EL BLOQUEO Y DESBLOQUEO
REMOTO DE UN VEHCULO MEDIANTE UNA APLICACIN
MVIL PARA DISPOSITIVOS ANDROID

TRABAJO PREVIO A LA OBTENCIN DEL TITULO
DE INGENIERO EN MECATRNICA

WILLIAN ALEJANDRO VELOZ SALAZAR

DIRECTOR: MSC. DANIEL MIDEROS

Quito, Enero 2013

Universidad Tecnolgica Equinoccial. 2013
Reservados todos los derechos de reproduccin

DECLARACIN

Yo WILLIAN ALEJANDRO VELOZ SALAZAR, declaro que el trabajo aqu
descrito es de mi autora; que no ha sido previamente presentado para
ningn grado o calificacin profesional; y, que he consultado las referencias
bibliogrficas que se incluyen en este documento.

La Universidad Tecnolgica Equinoccial puede hacer uso de los derechos
correspondientes a este trabajo, segn lo establecido por la Ley de
Propiedad Intelectual, por su Reglamento y por la normativa institucional
vigente.

Willian Alejandro Veloz Salazar
C.I.: 171789963-5

CERTIFICACIN

Certifico que el presente trabajo que lleva por ttulo Control GSM para el
bloqueo y desbloqueo remoto de un vehculo mediante una aplicacin
mvil para dispositivos Android, que, para aspirar al ttulo de Ingeniero
en Mecatrnica fue desarrollado por Willian Alejandro Veloz Salazar, bajo
mi direccin y supervisin, en la Facultad de Ciencias de la Ingeniera; y
cumple con las condiciones requeridas por el reglamento de Trabajos de
Titulacin artculos 18 y 25.

Msc. Daniel Mideros
DIRECTOR DEL TRABAJO
C.I.: 1713177325

DEDICATORIA

Este logro va dedicado a mis padres, a mis hermanos, dems familia y
amigos cercanos, por depositar su confianza y orgullo en m. Anhelo marcar
un hito en la historia de nuestras vidas, un cambio en la forma de ver el
mundo, y mostrar que con esfuerzo y un objetivo bien plantado en nuestra
mente podemos llegar ms lejos en la bsqueda de das mejores.
Con todo mi corazn dedico este trabajo a mi padre, Luis; aprend mucho
ms con su ejemplo de abnegacin y entrega hacia su familia de lo que se
puede aprender en un aula de clases. Lo logramos!

Willian Veloz S.

AGRADECIMIENTO

Slo un exceso es recomendable en el mundo: el exceso de gratitud
(Jean de la Bruyere)

Habra sido imposible lograr la culminacin de este trabajo sin el apoyo de
muchas personas que creyeron en este proyecto y en mi capacidad para
alcanzarlo, quienes de una u otra manera estuvieron soportando la
realizacin del mismo como una carga propia.
Gracias a Dios primeramente, por la vida, la dicha, y las batallas, que por su
infinita gracia nos ayuda a ganar y alcanzar nuevas metas; toda gloria, honra
y honor sean a l.
A mis padres, Luis y Mnica, gracias a quienes hoy soy lo que soy;
estuvieron dndome su apoyo a lo largo de mi existencia, y lo siguen
haciendo. Muchas gracias!
A mi prima Fanny Tonato y toda su familia, quienes me acogieron durante un
largo tiempo y fueron para m una segunda familia, en cuya casa tuve un
hogar lejos de mi ciudad.
A mis tos Hugo y Zelandia, y a mi mami Elva, a ustedes, que estando lejos
siempre estuvieron cerca, no tengo manera de agradecer cuanto han hecho
por m.
A mi querida May, en tiempos de oscuridad fuiste la motivacin para
continuar, gracias por creer siempre en m y estar a mi lado dicindome:
nimo, tu puedes!... Te amo.
Por ltimo, gracias a la Universidad Tecnolgica Equinoccial, compaeros,
amigos, profesores. All aprend lo que con orgullo hoy s.
i

NDICE DE CONTENIDOS
Pgina
RESUMEN x
ABSTRACT xi
1. INTRODUCCIN 1

2. MARCO TERICO 9
2.1. SISTEMAS DE COMUNICACIN CELULAR 10
2.1.1. COMUNICACIONES MVILES 10
2.1.1.1. Clasificacin de los sistemas de
comunicaciones mviles 10
2.1.2. FUNDAMENTOS DE LOS SISTEMAS CELULARES 13
2.1.2.1. Geometra de las redes celulares 14
2.2. GLOBAL SYSTEM FOR MOBILE COMUNICATIONS, GSM 17
2.2.1. ARQUITECTURA DEL SISTEMA GSM 18
2.2.2. IDENTIFICADORES EN GSM 21
2.2.3. SERVICIOS MEJORADOS DE GSM:
HSCSD, GPRS, EDGE 22
2.2.3.1. HSCSD 22
2.2.3.2. GPRS 23
2.2.3.3. EDGE 25
2.3. DESARROLLO DE APLICACIONES PARA DISPOSITIVOS
MVILES 27
2.3.1. TELEFONOS INTELIGENTES 28
2.3.1.1. Sistemas operativos para dispositivos mviles 29
2.3.2. ANDROID, SISTEMA OPERATIVO PARA
DISPOSITIVOS MVILES 31
2.3.2.1. El Android Stack 32
2.3.3. APLICACIONES 34
2.3.3.1. Tipos de aplicaciones Android 35
2.3.3.2. Componentes de una aplicacin 36
ii

2.3.3.3. Ciclo de vida de las actividades 39
2.3.3.4. El AndroidManifest.xml 41
2.4. COMANDOS AT 42
2.4.1. TIPOS DE COMANDOS AT 42
2.4.2. APLICACIONES DE LOS COMANDOS AT 44
2.5. SISTEMAS DE PROTECCIN ANTIRROBO 45
2.5.1. ALARMAS PARA VEHCULOS 45
2.5.2. ALARMAS OEM 46
2.5.3. PARTES DE UN SISTEMA DE PROTECCIN
ANTIRROBO VEHICULAR 48
2.5.3.1. Central de control 49
2.5.3.2. Sensores 50
2.5.3.3. Dispositivos de alerta 55
2.5.3.4. Llave de activacin y desactivacin remota 56
2.5.3.5. Batera auxiliar 58
2.5.3.6. Inmovilizadores 58

3. METODOLOGA 62
3.1. METODOLOGA MECATRNICA 63
3.1.1. REQUERIMIENTOS DEL PROYECTO 64
3.1.1.1. Acondicionamiento de seales de entrada 65
3.1.1.2. Sistema de control 71
3.1.1.3. Actuadores y dispositivos de salida 75
3.1.2. DISEO MECNICO 78
3.1.2.1. Funcionamiento de un vehculo a gasolina
con motor de combustin interna 78
3.1.3. DISEO ELECTRNICO 80
3.1.3.1. Circuito de adquisicin de seal del sensor 80
3.1.3.2. Circuito de comunicacin con el mdem 82
3.1.3.3. Circuito de salida del rel para el bloqueo
del vehculo 84
3.1.4. DISEO DEL SISTEMA DE CONTROL 85
iii

3.1.4.1. Programa del microcontrolador del PIC16f628a 85
3.1.4.2. Programa de la aplicacin mvil 89
3.1.5. SIMULACIN 92

4. DISEO 95
4.1. DISEO Y SIMULACIN DEL COMPONENTE
ELECTRNICO 96
4.1.1. CIRCUITO DE ASDQUISICIN DE DATOS 97
4.1.2. CIRCUITO DE COMUNICACIN 100
4.1.3. CIRCUITO DE SALIDA 102
4.1.4. DISEO DEL PBC DEL CIRCUITO ELECTRNICO 103
4.2. DISEO Y SIMULACIN DEL COMPONENTE DE CONTROL 104
4.2.1. DISEO DEL PROGRAMA PARA EL PIC16f628a 104
4.2.2. SIMULACIN DEL PROGRAMA DEL PIC16f628a 108
4.2.3. DISEO DE LA APLICACIN MVIL 117
4.2.3.1. Diseo de la interfaz grfica 119
4.2.3.2. Desarrollo del programa de la aplicacin 124
4.2.4. SIMULACIN DE LA APLICACIN MVIL 133

5. RESULTADOS 140

6. CONCLUSIONES Y RECOMENDACIONES 152
6.1. CONCLUSIONES 153
6.2. RECOMENDACIONES 154

BIBLIOGRAFA 156
ANEXOS 161

iv

INDICE DE TABLAS
Pgina
Tabla 1. Costos materiales electrnicos 6
Tabla 2. Costos desarrollo de software 7
Tabla 3. Costos desarrollo del proyecto 8
Tabla 4. Costos de instalacin 8
Tabla 5. Versiones del sistema operativo Android 31
Tabla 6. Comandos AT ms comunes 43
Tabla 7. Precios de paquetes de SMS 67
Tabla 8. Diferencia entre algunos sistemas operativos mviles 68
Tabla 9. Cobertura celular en la provincia de pichincha 69
Tabla 10. Tabla de comparacin entre PIC16f628a y PIC16f877a 72
Tabla 11. Cdigos de activacin 89
Tabla 12. Componentes de Screen1 (pantalla1) 121
Tabla 13. Componentes de Screen2 (pantalla2) 122
Tabla 14. Resultados de la prueba de envo y recepcin de
mensajes desde el telfono mvil hacia el mdem 142
Tabla 15. Resultados de las pruebas de envo y recepcin de
mensajes desde el mdem hacia el telfono mvil 144
Tabla 16. Resultados de las pruebas de envo de mensajes
desde el telfono mvil hacia el mdem en ausencia
de seal celular 146

v

INDICE DE FIGURAS
Pgina
Figura 1. Agrupacin de clulas o clusters 14
Figura 2. Cobertura celular con solape y sin solape 15
Figura 3. Superficies poligonales en funcin de su baricentro 15
Figura 4. Distribucin celular terica con varias clulas adyacentes 16
Figura 5. Ejemplo de una distribucin real de clulas en una
zona urbana 17
Figura 6. Arquitectura del sistema GSM 19
Figura 7. Tarjeta SIM 21
Figura 8. Arquitectura del sistema para soporte HSCSD 23
Figura 9. Arquitectura del sistema GPRS 25
Figura 10. Constelaciones de modulacin espacial
para GSMK y 8-PSK 26
Figura 11. Telfonos inteligentes 29
Figura 12. Cuota del mercado de los sistemas operativos
mviles a nivel mundial 30
Figura 13. El Stack de Android 33
Figura 14. Ciclo de vida de las actividades 40
Figura 15. Ventana de comunicacin entre el hyperterminal
y el mdem 45
Figura 16. Sistema de asistencia remota y control de
medios Chevystar 47
Figura 17. Paquete de sistema de antirrobo vehicular 48
Figura 18. Partes de un sistema antirrobo vehicular 49
Figura 19. Diagrama de bloques de un sensor 50
vi

Figura 20. Sensor de choque 52
Figura 21. Sensor de inclinacin 54
Figura 22. Funcionamiento de un sensor de ultrasonido 55
Figura 23. Sirena instalada en el interior del guardamotor
de un vehculo 56
Figura 24. Control remoto de un sistema de seguridad vehicular 57
Figura 25. Funcionamiento de un inmovilizador con transponder 59
Figura 26. Llave de puerta para vehculo con chip transponder 60
Figura 27. Diagrama de bloques de un inmovilizador con
comando infrarrojo 60
Figura 28. Diagrama de bloques de un inmovilizador con teclado 61
Figura 29. Esquema de la Metodologa del diseo de sistemas
mecatrnicos 64
Figura 30. Sensor de choque 66
Figura 31. Circuito de amplificacin para el sensor de choque 66
Figura 32. Arquitectura del PIC16f628a 73
Figura 33. Telfono mvil Motorola XT316 74
Figura 34. Sistema de encendido e ignicin de un automvil 76
Figura 35. Esquema de interfaz con rel 77
Figura 36. Diagrama de bloques del proyecto 80
Figura 37. Funcionamiento del sensor de impacto 82
Figura 38. Estructura de un dato serial 83
Figura 39. Pines del puerto USART del PIC16f628a 84
Figura 40. Estados del sistema de seguridad vehicular 86
Figura 41. Esquema general del AppInventor 92
Figura 42. Circuito de polarizacin de un transistor NPN 97
vii

Figura 43. Circuito de adquisicin de datos 100
Figura 44. Circuito de comunicacin serial 101
Figura 45. Circuito de salida del rel 103
Figura 46. Diagrama para la simulacin del circuito electrnico 109
Figura 47. Terminal virtual (imagen1) 110
Figura 48. Terminal virtual (imagen 2) 110
Figura 49. Resultados simulacin (imagen1) 112
Figura 50. Resultados simulacin (imagen 2) 113
Figura 54. Diseo del Screen1 de la aplicacin mvil 120
Figura 55. Diseo del Screen2 de la aplicacin mvil 120
Figura 56. Bloques de definicin 125
Figura 57. Bloques de texto 125
Figura 58. Bloques de lista 126
Figura 59. Bloques de control 127
Figura 60. Bloque When Button.Click do 128
Figura 61. Bloque When Texting.MessageReceived do 129
Figura 62. Bloque When Screen.Initialize do 130
Figura 63. Bloque Call Notifier.ShowAlert 130
Figura 64. Bloques Call Notifier.ShowChooseDialog & When
Notifier.AfterChoosing do 131
Figura 65. Bloques Call Notifier.ShowTextDialog & When
Notifier.AfterTextInput do 132
Figura 66. Bloque Call TinyDB.StoreValue 133
viii

Figura 67. Simulacin aplicacin mvil (imagen1) 134
Figura 68. Simulacin aplicacin mvil (imagen 2 y 3) 135
Figura 76. Pruebas de envo de SMS desde telfono a
mdem con buena calidad de seal celular 142
Figura 77. Pruebas de envo de SMS desde mdem a
telfono con buena calidad de seal celular 144
Figura 78. Pruebas de envo de SMS desde telfono a
mdem en ausencia de seal celular 146

ix

INDICE DE ANEXOS
Pgina
ANEXO 1
Circuito electrnico completo del proyecto 162
ANEXO 2
Layout del PBC del proyecto realizado en ARES 163
ANEXO 3
Diagrama de procesos del programa para el PIC16f628a 164
ANEXO 4
Diagrama de procesos del Screen1 de la aplicacin mvil 165
ANEXO 5
Diagrama de procesos del Screen1 de la aplicacin mvil 166
ANEXO 6
Programa del PIC16f628a en Microcode 167
ANEXO 7
Diagrama de bloques del programa para el Screen1 de la
aplicacin mvil 172
ANEXO 8
Diagrama de bloques del programa para el Screen2 173
ANEXO 9
Hoja tcnica del PIC16f628a 176
ANEXO 10
Hoja tcnica del rel CB1a-M-12V 181
ANEXO 11
Fotografas del desarrollo del proyecto 182

x

RESUMEN

El robo de vehculos automotores es uno de los mayores problemas sociales
que afronta nuestro pas actualmente. Los sistemas de proteccin vehicular
comerciales actuales presentan algunas desventajas respecto a su
confiabilidad, ejemplo de ello es que los sistemas con activacin por
radiofrecuencia tienen limitaciones en su alcance de activacin y su alarma
puede ser percibida audiblemente por el usuario hasta una determinada
distancia. A la par de esta temtica se conoce tambin que en la actualidad
el uso de sistemas que involucran tecnologas mviles es cada vez ms
popular en el mundo, debido a las ventajas que representa el control de
sistemas electrnicos mediante aplicaciones instaladas en dispositivos
mviles celulares.
El presente trabajo tiene como objetivo determinar la factibilidad tcnica y
econmica de la realizacin de un sistema de seguridad vehicular que
responda a las necesidades actuales de seguridad mediante el uso de
tecnologas mviles como GSM y desarrollo de aplicaciones para
dispositivos mviles. El sistema propuesto en esta tesis comprende la
creacin de un mdulo electrnico instalado en un vehculo automotor, que
es controlado desde una aplicacin mvil para dispositivos Android cuyo
desarrollo tambin est implcito en este trabajo, el sistema en conjunto tiene
la capacidad de activar y desactivar una alarma, detectar una posible alerta
de robo, enviar una seal de alerta al usuario, y bloquear la movilidad del
vehculo en caso de ser necesario.

xi

ABSTRACT

Motor vehicle theft is one of the biggest social problems facing our country
today. The commercial vehicle protection systems present some
disadvantages regarding their reliability, for example, systems with radio
frequency activation are limited in their reach and alarm activation can be
audibly perceived by the user at a certain distance. Along with this subject is
also known that at present the use of systems involving mobile technologies
is becoming increasingly popular in the world, due to the advantages of
electronic control systems using applications on mobile phones.
This study aims to determine the technical and economic feasibility of the
realization of a vehicle safety system that responds to current safety
requirements through the use of mobile technologies like GSM and
application development for mobile devices. The system proposed in this
thesis involves the creation of an electronic module installed in a motor
vehicle, which is controlled from a mobile application for Android devices
whose development is also implicit in this work, the whole system has the
ability to enable and disable an alarm, detect a possible theft alert, send an
alert signal to the user, and block the mobility of the vehicle if necessary.
0

1. INTRODUCCIN

2

Segn datos presentados por el Observatorio Metropolitano de Seguridad
Ciudadana de la ciudad de Quito, en los ltimos cuatro aos ms de 7 000
unidades vehiculares han sido robadas, lo que representa aproximadamente
el 1.35% del total de unidades del parque automotor de la ciudad; y,
lamentablemente, a pesar de los esfuerzos realizados por organizaciones
gubernamentales y por los usuarios vehiculares, las cifras de robos de
vehculos no han disminuido significativamente, aun cuando la tendencia ha
sido la de instalar alarmas electrnicas que emiten una seal audible de
alarma y, en algn caso, efectuar un bloqueo activado automticamente o
desde un mando a distancia. Es as que, durante el ao 2 012 se reportaron
cerca de 1 690 robos de vehculos, de los cuales unos 1 380 se efectuaron
con el vehculo estacionado, lo que correspondera al 81% del total de
vehculos robados (Tocornal X., Abril M. & Tupiza A, 2008). La mayora de
robos se dieron en la noche, mientras los propietarios descansaban y no
estaban al tanto de la condicin de seguridad de su automvil.
Por otro lado, el robo vehicular se ha convertido en un problema bastante
recurrente, debido al alto inters por parte de los grupos delincuenciales
debido a que un vehculo robado es razonablemente fcil de vender, ya sea
entero o por partes, y que adems, incorpora en s mismo el mtodo de
escape de los infractores. Las alarmas electrnicas estndar actuales se
instalan con el propsito de alertar al propietario del vehculo de un potencial
intento de robo, sin embargo, si la alarma es violentada o si la seal de
alerta no fuera percibida, el vehculo pudiera ser sustrado sin que el usuario
consiguiera evitarlo.
En el mercado local, existen cientos de modelos de alarmas electrnicas,
aunque todas funcionan bajo el mismo principio: una central de control
instalada en el automvil que es manejada desde un mando a distancia y en
la cual se conectan varios sensores que dan alerta al usuario en caso de
robo. El mando a distancia es un control de bolsillo (se puede enganchar a
las llaves del carro) que funciona basndose en el principio de
radiofrecuencia, es decir que posee un emisor de ondas electromagnticas
de corto alcance (100 m aproximadamente) con el cual se puede activar y
3

desactivar la alarma. Hoy en da, existen tambin empresas dedicadas a
proporcionar el servicio de seguridad vehicular con tecnologa GPS, el cual
tiene un costo anual o mensual elevado. Este servicio ofrece la posibilidad
de realizar un rastreo satelital para ubicar la posicin del vehculo y
bloquearlo desde cualquier parte del planeta. Sin embargo, no es un sistema
muy popular debido a la condicin de dependencia de una empresa y los
elevados costos que esto implica.
Por otra parte, los avances tecnolgicos son cada vez ms notorios en el
campo de las comunicaciones mviles; los recursos para el desarrollo de
tecnologas que permitan integrar otras reas de inters con las
comunicaciones mviles estn libremente disponibles, y no son
necesariamente costosos. De ese modo, es cada vez ms comn, y ms
fcil encontrar variadas aplicaciones para dispositivos mviles dedicadas a
resolver problemas cotidianos, y hacer de la vida del ser humano ms
entretenida y llevadera. Adems, no existe actualmente un sistema de
seguridad vehicular que le permita al usuario controlar la condicin de
funcionamiento del mismo desde un dispositivo mvil a travs de una
plataforma de control personalizada.
Por lo tanto, y teniendo en cuenta todo lo anteriormente expuesto, se
propone el desarrollo de un sistema de seguridad vehicular integrado a las
tecnologas de comunicaciones mviles o GSM, que permita al propietario,
tener control sobre la seguridad del vehculo en los lugares con cobertura de
seal proporcionada por una compaa de telefona celular. La
implementacin del sistema de seguridad con las caractersticas
anteriormente mencionadas, se justificara por las siguientes razones:
- Ofrecera una solucin al problema del robo de vehculos en la ciudad
de Quito, mediante la implementacin de un sistema de seguridad de
fcil utilizacin y monitoreo.
- El proyecto presentado posibilitar un gran alcance, limitado
nicamente por la cobertura de seal celular, es decir que en
condiciones ptimas cubrira totalmente la zona urbana de la ciudad.
4

- Se diseara una aplicacin mvil enfocada en la seguridad vehicular
con interaccin visual, para administrar de manera sencilla la
plataforma de control del sistema de alarma.
- Se promovera la realizacin de estudios en el campo de las
tecnologas mviles y desarrollo de aplicaciones, que son escasos en
nuestro medio.

Por estos motivos para la realizacin del presente trabajo de titulacin se
plantearon los siguientes objetivos:

Objetivo General
Disear un control GSM para el bloqueo y desbloqueo remoto de un
vehculo desde una aplicacin mvil para dispositivos Android.

Objetivos Especficos
Los objetivos llevados a cabo para la consecucin final del objetivo general
son los siguientes:
Disear e implementar en un automvil, un sistema de control de
seguridad que incluya un mdulo electrnico que, procese, enve,
reciba y procese informacin a travs de un mdem GSM, y que
permita realizar funciones de bloqueo y desbloqueo del vehculo.
Disear e implementar una aplicacin mvil para dispositivos
Android que permita controlar el sistema de seguridad a travs de la
comunicacin mvil con el modem GSM instalado en el mdulo
elecrtnico en el sistema de seguridad del vehculo.
Construir y validar el prototipo mediante el protocolo de pruebas de
campo.

5

Este proyecto pretende abarcar el diseo y realizacin de un sistema de
seguridad vehicular que comprende las siguientes caractersticas:
- Un mdulo electrnico diseado para ser instalado en el vehculo, el
cual realizar las funciones de: comunicacin con un modem GSM
(instalado juntamente con el mdulo electrnico) a travs de un puerto
serial, lectura de la seal de un sensor de impacto, bloqueo
electrnico del vehculo mediante apertura del sistema elctrico del
mismo.
- Un mdem GSM que realiza las siguientes funciones: comunicarse
con un microcontrolador (mdulo electrnico) mediante cdigos AT a
travs del puerto serial, y enviar y recibir mensajes de texto hacia y
desde un dispositivo mvil (telfono celular).
- Una aplicacin mvil desarrollada para un telfono mvil Motorola
XT316, que ofrece una plataforma de control personalizada del
sistema de seguridad vehicular, desde donde el usuario puede
realizar las siguientes funciones: ingresar mediante una contrasea
nica a la plataforma, encender y apagar la alarma del vehculo,
recibir una alerta de robo, bloquear y desbloquear el vehculo en caso
de robo.
- Este proyecto se aplica solamente a vehculos automotores a gasolina
(no a diesel) con motor de combustin interna.
La integracin de estas partes constituye en s el sistema de seguridad
vehicular cuyo desarrollo se describe en este documento.
Para la implementacin de este sistema de seguridad es necesario plantear
el estudio de factibilidad econmica en el cual se deben tomar en cuenta
factores como que el software utilizado tanto para la programacin del
microcontrolador como para el desarrollo de aplicaciones es software libre, lo
que significa una reduccin del costo final, sin embargo los recursos
utilizados para ello, entre los cuales se incluye tiempo y conocimiento si
implican un costo, aunque este rubro se incluye dentro del mensual de la
persona que lo desarrolla.
6

A continuacin se describe los costos de los materiales utilizados en este
proyecto:

Componente electrnico:
Tabla1. Costos materiales electrnicos
Descripcin Cant. V. Unit. V. Total
Mdem GSM 1 1,00 1,00
Microprocesador (PIC16f628a) 1 3,15 3,15
Circuito integrado (MAX232) 1 2,00 2,00
Regulador de voltaje (LM7805) 1 1,00 1,00
Resistencias 6 0,03 0,18
Capacitores 9 0,15 1,35
Transistor (TIC110) 1 0,50 0,50
Transistor (2n3904) 1 0,35 0,35
Diodos (1N4004) 2 0,10 0,20
Cristal Oscilador 20MHz 1 0,50 0,50
Diodos LED 3 0,20 0,60
Borneras 3 0,50 1,50
Conector DB9 macho 1 1,00 1,00
Cable serial 1 3,00 3,00
Relay automvil 1 5,00 5,00
7

Socket relay 1 1,20 1,20
Bornera de potencia 1 0,50 0,50
Elaboracin de tarjeta electrnica 1 9,10 9,10
Cables 10 0,40 4,00
Case 1 3,00 3,00
Otros 1 5,00 5,00
TOTAL 44,13

Desarrollo de software
Tabla 2. Costos desarrollo de software
Microcode Studio Plus V.3.0.0.5 1 0,00 0,00
PICkit v 2.61 1 0,00 0,00
Programador de PICs 1 24,00 24,00
Proteus 7.7 SP2 1 248,00 248,00
Blocks Editor AppInventor 1 0,00 0,00
Internet 8 23,40 187,20
TOTAL 459,20

8

Tiempo de Desarrollo
Tabla 3. Costos desarrollo de proyecto
Estudiante 8 1200,00 9600,00
Gastos varios 8 120,00 960,00
TOTAL 10560,00

Costos de instalacin:
Tabla 4. Costos de instalacin
Instalacin 1 40,00 40,00
Varios 1 15,00 15,00
TOTAL 55,00

El costo total de desarrollo del proyecto se estima en unos $11118,33.
El precio de una alarma electrnica convencional en el mercado se
encuentra alrededor de unos $50,00; e incluyendo sus costos de instalacin
el precio se eleva a unos $100,00. El producto planteado en este proyecto
supera las caractersticas de los sistemas de seguridad convencionales, por
lo que su precio puede ser ms alto siendo an atractivo para el mercado.
De acuerdo con datos obtenidos en investigaciones realizadas, se estimara
vender de 6 a 10 unidades del sistema de seguridad planteado
mensualmente, cuyo precio en el mercado estara fijado en $240,00 lo que
incluye el costo amortizado del diseo y desarrollo.
1

2. MARCO TERICO

10

2.1. SISTEMAS DE COMUNICACIN CELULAR
2.1.1. COMUNICACIONES MVILES
Para entender el funcionamiento de un sistema de comunicacin celular,
debemos partir del concepto de las comunicaciones mviles, el cual est
definido por la UIT (Unin Internacional de Telecomunicaciones) como un
servicio de telecomunicaciones entre estaciones mviles y estaciones
terrestres fijas, o simplemente entre estaciones mviles.
A travs de los sistemas de telecomunicacin mviles podemos intercambiar
informacin como voz, imgenes, datos, faz, video entre terminales mviles
o fijos. El objetivo de un sistema mvil es aprovechar su carcter de
inalmbrico y movilidad dentro de una determinada zona de cobertura
(Hernando, 2004).

2.1.1.1. Clasificacin de los sistemas de comunicaciones
mviles
Los sistemas de comunicacin mvil se clasifican de acuerdo a algunos
criterios, entre los cuales tenemos:
a. Por el sector de aplicacin
b. Por la tcnica de multi-acceso
c. Por el modo de explotacin

a. Por el sector de aplicacin
Se clasifican en: Sistemas privados, pblicos y de telefona inalmbrica.
Los sistemas de radiotelefona mvil privada, PMR (Private Mobile Radio) y
pblica, PAMR (Public Access Mobile Radio), se caracterizan por su rea de
accin que suele estar limitada y no estn conectados de forma expresa a la
red telefnica pblica conmutada PSTN (Public Switched Telephone
11

Network). Posteriormente las redes mviles se integraron a la PSTN, para
formar una nueva red que posea las ventajas de las redes mviles aplicadas
al sector pblico, esta red se denomin PLMN (Public Land Mobile
Networks)

b. Por la tcnica de multiacceso
Tcnica de multiacceso es la metodologa utilizada por los terminales del
sistema mvil para compartir los recursos comunes de la red a travs de las
estaciones base. Tales tcnicas son:
- Acceso mltiple por divisin de frecuencia: FDMA (Frequency Division
Multiple Access). Suelen ser de un solo canal por portadora y se
utilizaron en las primeras redes mviles tradicionales, donde cada red
utiliza una o ms frecuencias, rgidamente asignadas. Las
transmisiones de diferentes redes o grupos se separan en frecuencia
usando portadoras distintas. Los receptores seleccionan el canal
deseado mediante la sintonizacin manual o automtica.

- Acceso mltiple por divisin de tiempo: TDMA (Time Division Multiple
Access). Permite que varias redes o terminales mviles compartan la
misma frecuencia utilizndola en rfagas temporales y no de forma
permanente. Por ello las transmisiones de los usuarios son
discontinuas, intercalndose en el tiempo las rfagas de cada uno, de
forma que no colisionen ni interfieran entre s. Las tcnicas TDMA
requieren una estricta sincronizacin y que los equipos dispongan de
memorias para almacenar la informacin, a fin de entregar sta de
manera continua a los destinatarios. Por lo tanto el TDMA nicamente
es viable con sistemas de transmisin digital.

- Acceso mltiple por divisin de cdigo: CDMA (Code Division Multiple
Access). En este sistema se superpone a la informacin digital
transmitida por cada usuario un cdigo que le es propio, denominado
12

cdigo de direccin o signatura. Las transmisiones de todos los
usuarios se realizan en la misma frecuencia durante todo el tiempo. A
cada receptor llegan todas las seales presentes en el sistema en un
momento dado. Sin embargo, cada usuario, utilizando su cdigo,
puede recuperar la informacin destinada a l y eliminar las dems.

c. Por el modo de explotacin
Se distinguen tres modos de operacin en comunicaciones mviles:
- Simplex
En este modo un terminal puede ya sea transmitir (pero no recibir)
o recibir (pero no transmitir) informacin desde otro terminal. Es el
sistema de comunicacin ms simple.
- Semiduplex
En modo semiduplex un terminal puede transmitir y recibir
informacin desde otro terminal, sin embargo no lo puede hacer de
forma simultnea; si el equipo est transmitiendo no puede recibir
y viceversa, pero si puede cambiar a modo de recepcin siempre y
cuando el otro terminal se transforme en transmisor.
- Duplex
Este mtodo es el ms completo y complejo a la vez, ya que
puede transmitir y recibir informacin simultneamente con otro
terminal.

(Hernando, 2004).

13

2.1.2. FUNDAMENTOS DE LOS SISTEMAS CELULARES
Hasta ahora hemos estudiado los sistemas de comunicaciones mviles de
una forma general y en su funcionamiento bsico, sin embargo los sistemas
de comunicacin mvil fueron ms all, al implementar un concepto de
comunicacin que resolviera los problemas comunes de las redes PLMN,
tales como, la exigencia de capacidad de trfico. Este concepto denominado
celular fue ideado en 1947 por D. H. Ring, y se basa en las siguientes
declaraciones (Hernando, 2004):
1) La divisin de la zona de cobertura en regiones pequeas, llamadas
clulas, de tamao variable en funcin de la demanda de trfico.
2) La reutilizacin de frecuencias en clulas separadas por una distancia
suficiente para que la interferencia cocanal sea tolerable.

En un sistema de comunicacin celular, las frecuencias se pueden reutilizar,
ya que cada clula utiliza las frecuencias de manera independiente, esto
mejora y aumenta considerablemente el trfico. La nica condicionante es
que las frecuencias no sean las mismas entre clulas adyacentes para que
no existan interferencias. A las clulas que comparten las mismas
frecuencias se les denomina clulas cocanal, y deben estar separadas una
cierta distancia; esto se logra agrupando las clulas cocanal en conjuntos
denominados clusters o agrupaciones, de modo que no sean adyacentes
entre si, sino que estn rodeadas por clulas de otras agrupaciones que
tampoco sean adyacentes entre si.
Evidentemente, cuanto menor sea el tamao de la agrupacin tambin lo
ser el nmero de frecuencias necesarias, por lo que una caracterstica
importante de los sistemas celulares es la determinacin del tamao ptimo
de la agrupacin conjugando los requisitos de capacidad y rendimiento
espectral con los de interferencia.
En la figura 1 se ilustran el concepto celular. La zona de cobertura se
recubre mediante 16 clulas organizadas en 4 agrupaciones de 4 clulas: A,
14

B, C, y D, cada una de las cuales se repite cuatro veces, de forma que una
estacin mvil, cualquiera que sea su situacin dentro de la zona de
cobertura, podr comunicar con alguna clula. La cobertura radioelctrica de
las clulas se realiza desde estaciones base situadas en principio en el
centro de cada clula (Tomasi, 2003) y (Hernando, 2004).

Figura 1: Agrupacin de clulas o clusters
Fuente: (Hernando, 2004)

2.1.2.1. Geometra de las redes celulares
Si en cada clula se utilizan antenas omnidireccionales, la zona de cobertura
sera aproximadamente circular, lo que ocasiona un problema; como se
puede apreciar en la figura 2, las coberturas circulares o no recubren
totalmente el plano o producen solapes, es decir, que para la cobertura de
un mismo punto se emplean dos frecuencias.

15

Figura 2: Coberturas celulares sin solape (izq.) y con solape (der.)

Por esta razn, cuando se disean las redes celulares, se estudian
coberturas tipo poligonal, que recubran el plano sin solape. Existen tres
polgonos regulares que cumplen con esa condicin: el tringulo, el
cuadrado y el hexgono. Suponiendo que se coloca la estacin base en el
baricentro del polgono y que el radio de cobertura R es la distancia del
baricentro a un vrtice, las superficies de los polgonos son:
Tringulo:

Cuadrado:

Hexgono:

Figura 3: Superficies poligonales en funcin de su baricentro
16

Analizando lo anterior, podemos notar que para un radio de cobertura fijo R,
el hexgono es el polgono regular que proporciona mayor superficie de
clula, es por esta razn que se utilizan para el diseo de redes celulares, ya
que se necesitan menor cantidad de clulas para cubrir una determinada
rea. Aunque en la realidad las clulas no poseen exactamente la forma de
un hexgono debido a las irregularidades en la topografa, y cobertura de
necesidades de los usuarios (Hernando, 2004) y (Eberspcher, J., Vgel, H.-
J., Bettstetter C., & Hartmann C., 2009).

Figura 4: Distribucin celular terica, con varias clulas adyacentes

En la figura 4 se observa un modelo regular de una distribucin celular
terica, donde se puede ver cmo se distribuyen las clulas de forma exacta
evitando solapamientos y lugares carentes de cobertura. Sin embargo no es
posible aplicar ste modelo en la realidad, puesto que se deben tomar en
consideracin diversos factores como irregularidades en la topografa,
necesidades de cobertura, trfico, etc. Por ello, los modelos de distribucin
reales suelen tener formas irregulares, tal como se ilustra en la figura 5.

17

Figura 5: Ejemplo de una distribucin real de clulas en una zona urbana
Fuente: (Eberspcher, J., Vgel, H.-J., Bettstetter C., & Hartmann C., 2009)

2.2. GLOBAL SYSTEM FOR MOBILE COMUNICATIONS,
GSM
GSM es el estndar global para telecomunicaciones mviles. La red celular
digital GSM naci como consecuencia de que a pesar que ya existan varias
redes celulares (PLMN) analgicas en Europa, ests eran incompatibles
entre s, por lo que el mbito de servicio se limitaba al espacio territorial de
cada pas, y debido al rgimen monoplico, las operadoras no prestaban
servicios de buena calidad (Eberspcher, J., Vgel, H.-J., Bettstetter C., &
Hartmann C., 2009).
La CEPT (Conference Europeenne des Postes et Telecommunications), cre
el comit tcnico GSM (Groupe Speciale Mobile) con la orden de preparar el
estndar de un sistema de telefona mvil pblico paneuropeo.
Posteriormente las siglas GSM se reservaron para definir a la tecnologa
como Sistema Global para telecomunicaciones Mviles (Global System
Mobile for Telecommunications), entre tanto que el comit que la desarroll
se cambi el nombre a SMG (Special Mobile Group). En este documento se
18

utilizar las siglas GSM para referirse al estndar de telecomunicaciones
mviles, mas no as, para referirse al comit que lo desarroll.
El comit deba desarrollar una norma para una red PLMN con interfaces
bsicas entre las unidades funcionales a fin de que sean compatibles
equipos de diferentes fabricantes. Dentro de los requisitos que el grupo GSM
defini para el nuevo sistema se destacan los siguientes:
- Itinerancia internacional entre los pases de la Comunidad Europea.
- Tecnologa Digital
- Gran capacidad de trfico.
- Utilizacin eficiente del espacio radioelctrico.
- Sistema de sealizacin digital.
- Servicios bsicos de voz y datos.
- Amplia variedad de servicios telemticos
- Seguridad y privacidad en la interfaz radio, con proteccin de la
identidad de los usuarios y encriptacin de sus transmisiones.
- Utilizacin de telfonos porttiles.
- Altas calidades de cobertura, trfico y seal recibida.

2.2.1. ARQUITECTURA DEL SISTEMA GSM
La arquitectura de un sistema GSM posee la misma estructura que la
arquitectura de un sistema de comunicacin mvil; en los sistemas GSM se
observa un esquema ms detallado. Los componentes fundamentales de
una red GSM se pueden observar en la siguiente figura.

19

Figura 6: Arquitectura del sistema GSM


Una Estacin Mvil es el dispositivo que posee el usuario (telfono mvil), el
cual se puede conectar va aire a una Estacin Base, que en GSM se
denomina BTS (Base Transceiver Station), Las BTS contienen todo el
equipo necesario para la transmisin y recepcin, como, antenas,
amplificadores, y unos cuantos equipos necesarios para el procesamiento de
seales. A fin de que las BTS sean equipadas lo ms simplemente posible,
la mayora de equipos electrnicos se encuentran en las BSC (Base Station
Controller). En las BSC se realizan algunas funciones de protocolo, como
por ejemplo, asignaciones de canales, configuracin y manejo de traspasos
(handover), etc. Generalmente una BSC administra varias BTS por conexin
de lnea.
El trfico combinado de los usuarios es conmutado a travs de un switch
llamado MSC (Mobile Switching Center), en l se realizan todas las
funciones de un switch nodo, al igual que en una red telefnica PSTN o
20

ISDN. Una red celular puede contener varios MSC, cada uno de ellos
administrando una parte de la red. Una red PLMN/GSM debe conectarse
adems, con la red telefnica convencional PSTN y para ello emplea un
MSC especial denominado GMSC (Gateway MSC) que sirve como una
puerta de acceso entre ambas redes.
Una red GSM contiene tambin varias tipos de bases de datos; el HLR
(Home Location Register) y el VLR (Visitor Location Register) son dos bases
de datos que registran y almacenan la informacin referente a la ubicacin
de un mvil que se conecta a la red, esto es necesario ya que el MSC debe
conocer la ubicacin del mvil para conectarse con la BTS adecuada.
Adems estas bases de datos contienen informacin sobre el perfil de los
usuarios a fin de administrar su cuenta (recargas, pagos, etc.). Otra de las
bases de datos es el AUC (Autentication Center) que almacena informacin
relacionada a la seguridad del usuario, como claves de autentificacin y
encriptacin. El EIR (Equipment Indentity Register) almacena informacin
relacionada al equipo, ms no informacin del usuario.
Por ltimo, la administracin y mantenimiento de la red se realiza a travs
del OMC (Operation and Maintenance Center). Entre sus funciones estn, la
administracin de usuarios, terminales, configuracin, operacin, monitoreo
y mantenimiento de la red (Eberspcher, J., Vgel, H.-J., Bettstetter C., &
Hartmann C., 2009).
En resumen la arquitectura de un sistema GSM se puede dividir en tres
subsistemas:
- BSS (Base Station Subsystem): Contiene las MS, BTS, BSC.
- NSS (Network Switching Subsystem): Contiene las MSC, GMSC
- OMSS (Opertion and Maintenance Subsystem): Contiene los VLR,
HLR, AUC, EIR.

21

2.2.2. IDENTIFICADORES EN GSM
GSM usa diversos identificadores para obtener informacin sobre los
abonados, cuentas, pagos, recargas, identificacin de equipos, etc. Los
identificadores en GSM son los siguientes:

o IMSI
El International Mobile Subscriber Identity o IMSI se encuentra embebido en
la tarjeta SIM (Subscriber Identity Module), y proporciona la informacin del
abonado, como, ubicacin del usuario, realizacin y terminacin de
llamadas, y cargo de costos de llamadas. Tambin contiene la informacin
que se almacena en el HLR.
Un equipo mvil se convierte en una estacin mvil cuando la tarjeta SIM se
encuentra instalada dentro del equipo (Noldus, 2006).

Figura 7: Tarjeta SIM
Fuente: (Noldus, 2006)

o IMEI
El International Mobile Equipment Identifier o IMEI, es usado para identificar
el equipo mvil, as, todos los equipos mviles del mundo poseen un nmero
de identificacin diferente que no puede ser modificado ya que se encuentra
almacenado en la memoria interna del equipo. Se suele utilizar ste
22

identificador para bloquear los equipos que han sido robados a fin de que no
puedan ser utilizados a partir de entonces por los sustractores (Noldus,
2006).

2.2.3. SERVICIOS MEJORADOS DE GSM: HSCSD, GPRS, EDGE
Los servicios mejorados de GSM se basan en la transmisin de datos, ya
que en un principio GSM solo poda transmitir informacin de voz. Esto
implic aumentar las tasas de transmisin y modificar los mtodos de
transmisin para poder enviar la informacin de datos ya que sta es ms
grande y compleja que la informacin de voz .
Cada una de los mejoramientos del sistema GSM marcaron una etapa
evolutiva, generando as las diferentes fases de la red como las conocemos:
GSM 2 generacin, 2,5GSM o GSM 2+, GSM 3 generacin o 3GSM y
la ms reciente 3,5GSM (Eberspcher, J., Vgel, H.-J., Bettstetter C., &
Hartmann C., 2009).

2.2.3.1. HSCSD
El primer servicio mejorado de GSM fue el High Speed Circuit Switched Data
o HSCSD, que como su nombre lo indica, consista en la conmutacin de
circuitos destinados al envo y recepcin de datos de tasa fija durante la
comunicacin; otro punto a considerar es que la tasa de transmisin en GSM
era de 9,6 kb/s, pero en HSCSD se aument a 76 kb/s. Esta fase de
desarrollo en GSM se conoci como la 2da Generacin de GSM, o GSM2
(Hernando, 2004).
La conmutacin de circuitos es una tcnica que consiste en configurar una
serie de nodos intermedios para propagar los datos del nodo remitente al
nodo receptor. En tal situacin, la lnea de comunicacin se puede comparar
con un canal de comunicacin dedicado.

23

o Arquitectura de HSCSD
La estructura de este sistema no difiere mucho de la estructura GSM, y no
se realizaron modificaciones a nivel fsico. Como vemos en la figura 8, el
sistema HSCSD emplea la totalidad del canal para transmitir datos desde la
MS hasta la BTS, de igual manera para pasar la informacin desde la BTS
hacia la BSC; de este modo no se pueden ocupar esos canales para otros
propsitos. Para lograr esto se deba implementar en los equipos mviles
una nueva funcionalidad llamada TAF (Terminal Adoption Funtion)
(Hernando, 2004) y (Eberspcher, J., Vgel, H.-J., Bettstetter C., &
Hartmann C., 2009).

Figura 8: Arquitectura del sistema para soporte de HCSD

2.2.3.2. GPRS
La transmisin de datos a travs de una red GSM fue posible a partir de la
implementacin de los mtodos de conmutacin de circuitos para canales
dedicados a ste propsito. Sin embargo, sta fase, que se conoci como
GSM2 dio un paso ms al transformarse en GSM2+ o 2.5GSM.
El sistema GPRS (General Packet Radio Services), que fue diseado para
la transmisin de informacin de datos empleaba un sistema de conmutacin
24

de paquetes en lugar del sistema de conmutacin de circuitos. En GPRS la
informacin total se divida en varias partes, cada una de ellas denominada
paquete, las cuales se enrutaban a travs de la red utilizando los mismos
canales que en GSM, y luego se ensamblaban de nuevo para entregar la
informacin total al destinatario, lo que haca ste mtodo ms eficiente, ya
que no era necesario ocupar la totalidad de los canales que enlazaban a la
estacin mvil, la BTS y la BCS. Por contraparte, el proceso de dividir la
informacin en paquetes requera la implementacin de nuevos equipos en
el sistema, y en ocasiones no todos los paquetes llegaban al destinatario,
por lo que tuvo que desarrollarse tambin mtodos de transmisin que
aseguraran la transmisin efectiva de todos los paquetes desde su origen
hasta el destino final (Eberspcher, J., Vgel, H.-J., Bettstetter C., &
Hartmann C., 2009).

o Arquitectura de GPRS
A fin de integrar los sistemas GPRS a las redes GSM existentes fueron
introducidas dos nuevas entidades en el ncleo de red, los nodos de red:
SGSN (Service GPRS Support Node) y GGSN (Gateway GPRS Support
Node).
Ya que un sistema GSM la informacin que se intercambia en forma de
paquetes no es susceptible de ser conmutada y encaminada por los MSC,
esta funcin se realiza, mediante los SGNS, que realiza funciones
competentes a la movilidad del usuario dentro de la red, y encaminamiento
(routing) de los paquetes desde y hacia otros terminales que se encuentren
dentro de la misma rea de servicio.
Los GGSN funcionan como interfaces o pasarelas de intercambio de
informacin entre los terminales (MS) y redes de paquetes externas (ej.
Internet a travs de protocolos IP), ste convierte los paquetes GPRS
provenientes de los SGSN en el formato de PDP (Packet Data Protocol)
apropiado y los enva a las PDN (Packet Data Networks) correspondientes.
En la figura 9 se ilustra un esquema de la arquitectura de un sistema GPRS.
25

Figura 9: Arquitectura del sistema GPRS

2.2.3.3. EDGE
EDGE es el acrnimo de Enhanced Data Rates for GSM, aunque luego fue
cambiado por Enhanced Data Rates for Global, ya que ste sistema se
aplic no slo a redes GSM, sino a otras redes celulares con diferentes
estndares.
Los sistemas HSCSD y GPRS lograron altas tasas de transferencia gracias
a la tcnica de multi-acceso TDMA en la que cada terminal poda usar varios
espacios de tiempo en un periodo determinado para compartir los recursos
de la red. El sistema EDGE fue un paso ms all al mejorar la eficiencia
espectral en la capa fsica y poder usar as un solo espacio de tiempo.
EDGE introduce algunas combinaciones adicionales de modulacin y
esquemas de cdigos mejorados que permiten a los terminales adaptar sus
tasas de datos a sus niveles individuales de calidad de seal. Tcnicamente,
se puede decir que EDGE consiste en un mejoramiento de la interfaz aire,
26

as se ha logrado aumentar las tasas de transmisin de datos y por ende,
aumentar las velocidades de transmisin (Eberspcher, J., Vgel, H.-J.,
Bettstetter C., & Hartmann C., 2009). El esquema de modulacin del sistema
se puede apreciar en la siguiente figura.

Figura 10: Constelaciones de modulacin espacial para GSMK y 8-PSK

A la izquierda se puede observar el esquema de modulacin para GSM que
emplea un bit por smbolo. A la derecha se observa el esquema de
modulacin mejorado denominado 8-PSK que utiliza 3 bit por smbolo, en
otras palabras, con el nuevo esquema de modulacin, el sistema EDGE es
aproximadamente tres veces ms rpido.

27

2.3. DESARROLLO DE APLICACIONES PARA
DISPOSITIVOS MVILES
Con la llegada de las nuevas tecnologas de comunicacin celular como
EDGE, CDMA, WCDMA y ms recientemente UMTS, surgi tambin una
nueva generacin de dispositivos mviles con especificaciones y
caractersticas que hacen de su uso una experiencia de comunicacin que
va ms all de su funcionalidad original: realizar y recibir llamadas
telefnicas. Hoy en da los usuarios pueden a travs de sus telfonos
mviles acceder a una serie de procesos y recursos ya sean o no on-line;
compartir archivos multimedia, conectarse a una red mvil o esttica,
transferir cualquier tipo de informacin (texto, voz, imgenes, video, VoIP,
datos, etc.), grabar voz, imgenes o video con una determinada calidad,
acceder a una gran variedad de aplicaciones es ahora ms fcil con los
dispositivos mviles de gama alta y media alta. A estos dispositivos mviles
se les denomina Smartphones o telfonos inteligentes.
Sin embargo, en los ltimos aos se ha encontrado que este mbito
tecnolgico puede ser ms atractivo para los desarrolladores que para los
propios usuarios. Con la liberacin del software de los telfonos mviles de
algunas marcas fabricantes, son cada vez ms, los programadores que se
encuentran desarrollando aplicaciones para stos dispositivos, ya sea para
uso personal, libre distribucin, o venta de las mismas. Uno de las
plataformas para dispositivos mviles ms conocido y usado ltimamente ha
sido el sistema operativo ANDROID de Google.inc, que corre en
dispositivos de ms de veinte marcas comerciales como: Samsung,
Motorola, Toshiba, Kyocera, Asus, Dell, Asus, etc. Este sistema operativo
que se va a detallar ms adelante es un software libre, por lo que existen
muchas herramientas libres para el desarrollo de aplicaciones para
dispositivos con ste sistema operativo.

28

2.3.1. TELFONOS INTELIGENTES
Tal vez los telfonos inteligentes o Smartphones son considerados como
uno de los mejores inventos del siglo XXI, y su uso hoy en da es tan comn,
a pesar de que esta tecnologa se ha introducido en nuestro pas
recientemente. Segn el INEC (2011), aproximadamente el 46,6% de la
poblacin posee un telfono mvil (celular) activado, y de este porcentaje un
8,4% son smartphones; esto quiere decir que alrededor de ms de medio
milln de personas posee un Smartphone en Ecuador, siendo la mayor
audiencia, personas entre 25 y 34 aos de edad. Sin embargo estas cifras
van aumentando cada vez ms, debido a facilidades a su acceso, como
precios bajos y paquetes de consumo atractivos.
Un Smartphone es bsicamente un dispositivo electrnico que funciona
como un telfono mvil con caractersticas de un ordenador. Permite hacer y
recibir llamadas y enviar mensajes de texto como un mvil convencional,
pero adems posee una serie de caractersticas adicionales que
incrementan su utilidad, tales como:
- Visualizacin de imgenes y animaciones.
- Administracin de contactos.
- Lectura de archivos (*.pdf, *.txt, etc.)
- Reproductor de msica y video.
- Cmara de fotos y video.
- Soporte a correos electrnicos.
- Conectividad a internet.
- Acceso a redes inalmbricas (Wi-fi)
- Conexin Bluetooth.
- Sistema de posicionamiento Global (GPS).
- Instalacin de aplicaciones digitales, etc.
(Baz, A., Ferreira, I., lvarez, M. & Garca, R., 2010).

29

Otra caracterstica destacada de los telfonos inteligentes son sus pantallas
tctiles, aunque no necesariamente disponga de ella, o de todas las
caractersticas anteriormente mencionadas. Una caracterstica esencial a
tomar en cuenta para considerar si un telfono mvil es un Smartphone, es
su avanzada Interfaz de Programacin de Aplicaciones (API), que permite el
desarrollo de aplicaciones sobre su sistema operativo, adems de una
Interfaz de Usuario (UI) amigable y moderna (Wikipedia, Telfono
inteligente).

Figura 11: Telfonos Inteligentes
Fuente: www.poderpda.com

2.3.1.1. Sistemas operativos para dispositivos mviles
Un sistema operativo (OS) para dispositivos mviles (llmese tambin
Sistema Operativo Mvil) no es ms que la plataforma informtica que
establece la interfaz entre el usuario y el hardware del dispositivo mvil, y
sobre la cual se pueden instalar aplicaciones que agregan utilidad al
dispositivo. Entre las funciones ms comunes de un sistema operativo mvil
estn las de administracin de memoria fsica y virtual, control de hardware
(CPU, teclado, pantalla, altavoces, puertos, etc.), lectura y escritura de
archivos, control de procesos multitarea, definicin de la interfaz de usuario
(UI) (Baz, A., Ferreira, I., lvarez, M. & Garca, R., 2010).
Los sistemas operativos mviles ms comunes son:
30

- Android
- Symbian
- Apple iOS
- RIM BlackBerry OS
- Windows Mobile
- Linux

En la figura 12 podemos ver la cuota de mercado de los sistemas operativos
ms comunes hasta Mayo del 2012; como podemos observar, el sistema
operativo Android de Google, ocupa el mayor porcentaje (59%) de sistemas
operativos en el mundo, lo que hace denotar un fuerte crecimiento, ya que
hasta el ao 2010 slo ocupaba un 17%, desplazando a Symbian, el sistema
operativo para telfonos Nokia, que hace un par de aos era lder del
mercado con ms del 50% de la cuota total del mercado.

Figura 12: Cuota del mercado de los sistemas operativos mviles a nivel
mundial
Fuente: (IDC Worldwide Mobile Phone Tracker, May 24, 2012)

31

2.3.2. ANDROID, SISTEMA OPERATIVO PARA DISPOSITIVOS
MVILES
Android es una plataforma diseada para dispositivos mviles que corre
sobre un ncleo Kernel de Linux, un software libre. Fue desarrollado por la
Open Hanset Alliance bajo el mando de Google. Inicialmente fue
desarrollada por Android,Inc, una compaa que en el 2005 fue absorbida
por Google; a partir de entonces se comenz a rumorar que Google entrara
en el mercado de la telefona celular. En 2007 se liber por primera vez la
mayor parte del cdigo fuente del sistema operativo bajo una licencia
Apache. En 2008 fue lanzado el Android SDK (software development kit) 1.0,
una plataforma para el desarrollo de aplicaciones Android. Las aplicaciones
se escriben en lenguaje Java, utilizando libreras escritas en lenguaje C;
luego de compilarse el sistema operativo utiliza una mquina virtual (Dalvik
Virtual Machine) que corre sobre un kernel 2.6 de Linux (Gramlich, 2012).
Varias versiones de Android han sido desarrolladas, siendo una
particularidad que cada versin se denomina con el nombre de un postre. En
la tabla 5 vemos cada las actualizaciones de las versiones del sistema
operativo.
Tabla 5: Versiones del sistema operativo Android
Android version API level Nickname
Android 1.0 1
Android 1.1 2
Android 1.5 3 Cupcake
Android 1.6 4 Donut
Android 2.0 5 Eclair
Android 2.2 8 Froyo (frozen yogurt)
Android 2.3 9 Gingerbread
Android 2.3.3 10 Gingerbread
Android 3.0 11 Honeycomb

Fuente: (Gargenta, 2011)
32

La columna de API (Aplcatin Programming Interface) level representa el
nivel de comucacin de los diferentes mtodos y procesos entre las
aplicaciones que son parte del software del sistema operativo,
evidentemente el API level incrementa con cada actualizacin del software.

2.3.2.1. El Android Stack
La palabra stack puede traducirse como pila, y as es bsicamente la
forma en la que est estructurado el sistema operativo Android. Este sistema
operativo est conformado por varias capas apiladas unas sobre otras, las
cuales est separadas entre s, aunque a veces se pueden filtrar entre capas
si el sistema lo requiere. En este documento no se va a detallar cada uno de
los bloques que conforman cada capa, solamente se tratar el concepto de
cada capa de forma general. La estructura del sistema operativo se ilustra en
la figura 13.

o Kernel de Linux
Es el ncleo del sistema operativo, en l se encuentran instalados los drivers
para el funcionamiento y control del hardware del dispositivo, tales como:
driver de la pantalla, driver de audio, driver de teclado, driver de la cmara,
etc. Tambin se encuentra instalada la aplicacin de administracin de
energa. Al igual que Linux, Android es un sistema operativo de cdigo
abierto.

o Libreras
Esta capa contiene las libreras escritas en C/C++ que pueden usarse para
desarrollar aplicaciones, adems en esta capa se encuentra la DVM (Dalvik
Virtual Machine), que se diferencia de la mquina virtual de Java porque la
Dalvik VM est basada en el uso de registros y no de pila como la Java
VM.
33

Figura 13: El Stack de Android
Fuente: (Gargenta, 2011)

o Framework de aplicaciones
Es el conjunto de aplicaciones base del sistema operativo. Los
desarrolladores tambin pueden acceder a los APIs de las aplicaciones
base para modificar las caractersticas de las mismas. La arquitectura de
esta capa permite que las aplicaciones puedan reusar sus recursos a fin de
optimizar el procesamiento.

34

o Aplicaciones
Esta capa funciona como interfaz entre el usuario y las aplicaciones base.
Las aplicaciones base son: gestor de SMS, calendario, mapas, navegador,
administrador de contactos, asistente de correo, etc. Todas las aplicaciones
estn escritas en Java (Meier, 2009) y (Gargenta, 2011).

2.3.3. APLICACIONES
Generalmente una aplicacin es un programa informtico que se ejecuta
sobre una plataforma y realiza una o varias tareas. En Android, cada una de
las tareas o procesos que se estn ejecutando en el dispositivo mvil son
realizadas por aplicaciones. Por ejemplo, el asistente de pantalla tctil,
administrador de batera, visualizador de imgenes y videos, gestor de
descargas, reloj, calculadora, etc., todos estos procesos son realizados por
aplicaciones instaladas en el dispositivo mvil por el fabricante. Adems,
estn las aplicaciones que el usuario puede instalar en su equipo a fin de
agregar herramientas que potencian la utilidad del mismo, o que
simplemente sirven para entretenimiento, y que pueden ser adquiridas,
descargadas, compradas o desarrolladas por terceros. Google Play es la
pgina web oficial potenciada por Google para descargar aplicaciones para
dispositivos Android, de las cuales dos terceras partes de un total de casi
600.000 aplicaciones son gratis (Wikipedia, Android).
Las aplicaciones Android son escritas en lenguaje de programacin Java. El
Android SDK se encarga de compilar el cdigo y empaquetarlo en un archivo
*.apk el cual se considera ya como una aplicacin y que puede ser instalado
en un dispositivo Android.

35

2.3.3.1. Tipos de aplicaciones
Como vimos anteriormente existen aplicaciones Android que son instaladas
en el dispositivo mvil por defecto y que son indispensables para el correcto
funcionamiento del mismo, ya que contienen los drivers para el enlace entre
software y hardware. Tambin hay aplicaciones que el usuario puede instalar
para aadir herramientas a su dispositivo mvil. Sin embargo, la siguiente
clasificacin de las aplicaciones se basa en la forma en que sus procesos
son llevados a cabo.

- Aplicaciones de primer plano.
Son aplicaciones que son tiles mientras estn en primer plano, y que se
suspenden totalmente cuando no son visibles. Los juegos y navegadores
de mapas son un ejemplo de estas aplicaciones.

- Aplicaciones de fondo.
Son aplicaciones con limitada interaccin, que a excepcin de cuando
son configuradas, pasan la mayor parte de su tiempo ejecutndose de
forma oculta. Ejemplo de ello son las aplicaciones de administracin de
batera, teclado multi-toque, o aplicaciones de auto-respuesta de SMSs.

- Aplicaciones intermitentes.
Son aplicaciones que esperan alguna interactividad, pero hacen parte de
su trabajo en segundo plano. En ocasiones estas aplicaciones se
configuran y ejecutan silenciosamente, notificando a los usuarios cuando
sea necesario. Por ejemplo, el reproductor de msica (Meier, 2009).

36

2.3.3.2. Componentes de una aplicacin
Los componentes de una aplicacin Android son bloques de construccin
esenciales para su funcionamiento; cada componente cumple con un rol
especfico y existe como una propia entidad, aunque no son necesariamente
entradas de interaccin con el usuario.
Existen cuatro tipos de componentes que son los siguientes:

o Actividades (Activities)
Una actividad representa una pantalla individual con una interfaz de usuario
(UI). En el programa cuando llamamos a una actividad estamos dando la
orden de cerrar la pantalla actual y abrir una pantalla nueva. Una aplicacin
puede tener una o ms Actividades. Por ejemplo, una aplicacin de correo
electrnico muestra en una de sus actividades su lista de contactos, y en
otra actividad el rea de texto que se va a enviar.
A continuacin se muestra un ejemplo de la declaracin de una actividad en
el Manifest de Android:
<application ... >
<activity android:name=".ExampleActivity" />
...
</application ... >
(Gramlich, 2012)

37

o Servicios (Services)
Un servicio es un componente que se ejecuta es segundo plano y no provee
de una interfaz de usuario, realiza operaciones de tiempos largos de
ejecucin o tareas para procesos remotos. Un ejemplo de un servicio es
cuando estamos reproduciendo msica con el reproductor de medios
mientras estamos en una aplicacin diferente.
Un ejemplo de la declaracin de un servicio en el Manifest de Android se
muestra a continuacin:
<application ... >
<service android:name=".ExampleService" />
...
</application>
(Gramlich, 2012)

o Proveedores de Contenidos (Content Providers)
Un proveedor de contenidos es un componente que administra la
informacin de una aplicacin Android. La informacin puede guardarse en
el sistema de archivos (file system), una base de datos SQLite, en la web, o
en cualquier lugar de almacenamiento de la informacin persistente.
A continuacin se observa un ejemplo de una porcin de cdigo de una
subclase ContentProvider:
public class ExampleProvider extends ContentProvider {
private static final UriMatcher sUriMatcher;
sUriMatcher.addURI("com.example.app.provider", "table3", 1);
38

sUriMatcher.addURI("com.example.app.provider", "table3/#",2);
}

o Receptores de Transmisin (Broadcast Receivers)
Los receptores de transmisin son componentes que responden a las
transmisiones de avisos del sistema, por ejemplo, a un aviso que indica que
la batera tiene una nivel bajo, o que la pantalla se ha apagado. Cuando
estos avisos se presentan en la interfaz grfica de modo que el usuario lo
pueda notar se denominan aplicaciones.
Los receptores de transmisin son llamados mediante objetos denominados
Intents. A continuacin se explica que es un Intent.

o Intents e Intents Filters
Un objeto Intent es una porcin de informacin que indica lo que otros
componentes intentan realizar e informacin de inters para el sistema
operativo Android. Generalmente las subclases de tres de los componentes
antes mencionados (Actividades, Servicios y Receptores de transmisin)
pueden activarse con la instruccin Intent.
Por otro lado un Intent Filter describe las competencias de los componentes,
es decir el conjunto de Intents que el componente puede recibir. Un
componente puede manejar uno o ms Intents.
new Intent(android.content.Intent.VIEW_ACTION,
ContentURI.create("http://anddev.org"));

(Gramlich, 2012), (Mutual Mobile, 2011) y (Android developers, 2012)
39

2.3.3.3. Ciclo de vida de las actividades
Entender el ciclo de vida de una actividad es muy importante, ya que este
determina cuando una actividad nace y cuando muere, cuando est
ejecutndose en primer plano y cuando se ejecuta en segundo plano. Es de
vital relevancia, debido a que al salir de una actividad, sta puede realizar un
proceso que requiera de cierta informacin, informacin que debe ser
almacenada en algn espacio de memoria del dispositivo, ya sea en la
memoria cach, o de forma persistente.
El ciclo de vida de una actividad se puede apreciar como una forma
piramidal de mtodos que determinan el estado en que se encuentra.
Cuando la actividad se abre por primera vez, es decir desde que
presionamos el cono de lanzamiento de la aplicacin, es llamado el mtodo
onCreate() que crea la actividad, luego la inicializa mediante el mtodo
onStart(), y la actividad comienza a ejecutarse en primer plano, donde recibe
la atencin del usuario. En esta instancia el usuario puede salir de la
aplicacin y cerrarla, o simplemente volver a la pantalla principal y dejar que
la aplicacin se ejecute en segundo plano, asignando menos memoria a la
aplicacin para poder realizar otras tareas. Si el usuario sale de la aplicacin
o cambia a otra actividad se llama al mtodo onStop() que cancela todos los
procesos que estaban siendo realizados por la anterior actividad y almacena
la informacin que necesite. Por otro lado si la actividad pasa a un estado
parcialmente visible, como cuando se abre un cuadro de dialogo, se llama
al mtodo onPause(), durante ste estado, la aplicacin pierde la atencin
del usuario y es capaz de almacenar informacin para su uso en un espacio
de memoria no persistente; una vez que el usuario vuelve a la anterior
actividad se llama al mtodo onResume(). Tambien se puede reabrirr la
actividad desde su estado detenido, mediante el mtodo onRestart().
Finalmente, todo lo que se ha realizado a en esa actividad, puede ser
eliminado mediante el mtodo onDestroy() que cierra totalmente la
aplicacin, y volver a su estado inicial, esperando a ser creada nuevamente
40

(Android developers, 2012). Esto puede entenderse mejor en la siguiente
figura:

Figura 14: Ciclo de vida de las actividades.
Fuente: developer.android.com

De acuerdo a lo analizado anteriormente una actividad puede encontrarse en
3 diferentes estados:
Resumed: En este estado la actividad est ejecutndose en primer plano y el
usuario puede interactuar con ella.
Paused: En este estado la actividad est parcialmente obstruida por otra
actividad. Mientras la actividad que fue pausada se visualiza de forma semi-
transparente o no cubre toda la pantalla y el usuario no puede interactuar
con ella.
Stopped: En este estado la actividad est completamente oculta, pero se
est ejecutando en segundo plano. Durante este estado la actividad detenida
no puede ejecutar ningn cdigo, solo almacenar informacin de su estado.

41

2.3.3.4. El AndroidManifest.xml
El AndroidManifest.xml es un archivo se encuentra en la carpeta raz de la
aplicacin y es requerido para cada aplicacin Android. En l se describen
todos los valores globales del paquete, incluyendo los componentes de la
aplicacin (actividades, servicios, etc.) y la forma en que son lanzados y
ejecutados. Por esta razn podemos decir que ste es el archivo ms
importante de un paquete de aplicacin y que tomar en cuenta al momento
de desarrollar una aplicacin (Gramlich, 2012).
A continuacin se muestra un ejemplo de una porcin de cdigo del Manifest
de Android:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="org.anddev.android.hello_android">
<application android:icon="@drawable/icon">
<activity android:name=".Hello_Android"
android:label="@string/app_name">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
</manifest>
(developer.android.com, 2012)

42

2.4. COMANDOS AT
Los comandos AT son instrucciones codificadas que proveen una interfaz de
comunicacin entre un terminal mdem y otro dispositivo (ordenador,
microcontrolador). Se utilizan principalmente para configurar el mdem y
para acceder a las funciones bsicas del mismo, tales como realizar,
contestar o rechazar una llamada, enviar o recibir un mensaje de texto,
revisar el nivel de batera del dispositivo, etc. En un principio fueron
utilizados por las empresas Microcom y US Robotics para configurar sus
mdems, pero luego el lenguaje fue desarrollndose y extendindose hasta
universalizarlo. Hoy en da todos los dispositivos mviles cuentan con su
juego de instrucciones AT detallado en su documentacin tcnica, los cuales
pueden variar de acuerdo al fabricante, pero los comandos estndar ms
utilizados siguen siendo los mismos.

2.4.1. TIPOS DE COMANDOS AT
Debido a que los comandos AT son estandarizados poseen una estructura
definida que incluye sus formatos de entrada y respuestas. Los tipos de
comando AT ms comunes y detallados segn la marca de dispositivos
mviles ZTE son los siguientes:

Comandos sin parmetros: Son comandos simples que cumplen
con el siguiente formato: AT[+/&]<command>
Por ejemplo: AT+CSQ, AT&W
Comandos de pregunta: Se utilizan para preguntar al modem los
valores actuales de configuracin. Su formato es:
AT[+/&]<command>?
Por ejemplo: AT+CNMI?
43

Comandos de ayuda: Son usados para enlistar los posibles
parmetros del comando. Su formato es: AT[+/&]<command>=?
Por ejemplo: AT+CMGL=?
Comandos de parmetros: Normalmente usados en un formato que
presta una gran flexibilidad. Su formato es:
AT[+/&]<command>=<par1>,<par2>,<par3>
Los valores retornados se describen en la documentacin del
dispositivo. El formato bsico de los valores retornados es el
siguiente:
<CR><LF><Response string><CR><LF>
<CR><LF><OK/ERROR>[ERROR INFO]<CR><LF>

Los comandos AT ms utilizados se describen a continuacin en la siguiente
tabla:
Tabla 6. Comandos AT ms comunes
Comando Descripcin
A/ Sirve para repetir un comando anterior
ATA Sirve para contestar una llamada entrante
ATD Se utiliza para realizar una llamada / marcar a un nmero
ATH Se utiliza para colgar una llamada despus de haber sido
contestada
AT+CPAS Retorna el estado actual del telfono (listo, desconocido,
llamada entrante, llamada en curso)
AT+CFUN Configura el modo de funcionamiento del mdem, puede
configurarlo con todas sus funciones o funciones limitadas.
44

AT+CMGF Configura los SMS en modo texto o modo PDU
AT+CNMI Configura el formato del indicador de SMS
AT+CMGR Sirve para leer un SMS almacenado en alguna posicin de la
memoria del dispositivo
AT+CMGS Este comando es usado para originar un SMS
AT+CMGD Borra los SMS ubicados en alguna posicin de la memoria
del dispositivo
AT+CMGL Crea una lista con los mensajes leidos, no ledos,
almacenados, o todos al mismo tiempo.
AT+IFC Configura el control del flujo de transmisin y recepcin del
dispositivo
AT+IPR Configura la tasa de transferencia o Baud rate
Fuente: (ZTE Command Manual, 2007)

2.4.2. APLICACIONES DE LOS COMANDOS AT
Los comandos AT son usados para establecer comunicacin entre un
dispositivo mvil o mdem y el usuario a travs de un terminal de
comunicacin, el cual puede ser un ordenador o un microcontrolador, o
cualquier equipo con el que podamos transmitir datos en forma serial.
Dependiendo del equipo la comunicacin puede establecerse mediante la
norma RS-232 o simplemente usando seales lgicas TTL. Si usamos un
ordenador, podemos interactuar con el mdem desde una aplicacin
denominada Hiperterminal (como se muestra en la figura 15), que nos
permite enviar y recibir los comandos a travs del puerto serial del
ordenador, desde donde podemos controlar todas las funciones del
dispositivo mvil (ZTE Command Manual, 2007).
45

Figura 15. Ventana de comunicacin entre el hyperterminal y el mdem
Realizado por: William Veloz

2.5. SISTEMAS DE PROTECCIN ANTIRROBO
Un sistema de proteccin antirrobo es un elemento de seguridad pasiva o
activa cuyo propsito es evitar en mayor medida el riesgo de prdida de
propiedad privada mediante robo, dicha propiedad privada puede ser una
casa, un vehculo, un lote de joyas, etc. En este captulo se va a estudiar
especficamente los sistemas de proteccin antirrobo vehicular.

2.5.1. ALARMAS PARA VEHCULOS
Las alarmas para vehculos, o sistemas de proteccin vehiculares son
dispositivos integrados de seguridad pasiva que se instalan en una unidad
vehicular para alertar el robo del vehculo, parte de l, o algn objeto que se
46

encuentre dentro del mismo. Estn compuestas de: varios elementos de
entrada que se encargan de detectar la presencia o intencin del intruso,
una central que se encarga de interpretar las seales de dichas entradas
para tomar decisiones y realizar procesos, y elementos de salida que emiten
una seal de alerta que puede ser audible o visible, o una combinacin de
ambas, y en ciertos tipos de alarmas enviar informacin a un receptor a
distancia indicando el estado de alerta de la alarma.
Una alarma normalmente es un elemento de seguridad pasiva ya que por si
misma no puede evitar que el intruso robe el vehculo, simplemente emite
una alerta sobre el mismo para que alguien mas realice las acciones
necesarias a fin de frustrar el intento de robo. Sin embargo, una simple
alarma puede convertirse en un sistema de seguridad activa al aadir
elementos que funcionan como actuadores del sistema que habilitan o
inhabilitan ciertos sistemas e incrementan el nivel de seguridad del vehculo.
Uno de estos elementos ms comn es el que permite inmovilizar el vehculo
mediante un sistema de bloqueo automtico, o remoto; de este modo el
sistema de proteccin activa un subsistema de bloqueo, el mismo que puede
ser mediante desconexin del sistema elctrico, inhibicin del cerebro, o
inhabilitacin del sistema de bombeo de combustible (La Rosa, 2012) y
(Wikipedia, Car alarm).

2.5.2. ALARMAS OEM
Las alarmas OEM (Original Equipment Manufacturer) son sistemas de
proteccin que vienen instalados en los automotores por el fabricante del
mismo. Por lo general son alarmas estandarizadas y cumplen con el mnimo
de requerimientos para asegurar la integridad del vehculo. En ocasiones
son fabricadas por otra empresa, la cual las vende a la empresa fabricante
de vehculos para que sta los distribuya bajo su marca (Wikipedia, Original
Equipment Manufacturer). Un ejemplo muy comn en nuestro medio es el
sistema Chevystar (figura 16), el cual funciona como una central de
47

seguridad, medios, y servicios web que viene instalado en las unidades
producidas por la marca Chevrolet que el cliente requiera.

Figura 16: Sistema de asistencia remota y control de medios Chevystar
Fuente: www.carrosyclasicos.com

Las alarmas OEM no vienen instaladas en todos los vehculos de fbrica, ya
que se considera como un sistema adicional, y el cliente debe decidir si lo
requiere, lo que consecuentemente tendr un costo adicional al precio
original del automotor. Sin embargo, si un vehculo no cuenta con una
alarma OEM, es posible instalar en su interior una alarma para vehculo que
se consigue en el mercado, o que son instaladas por una empresa dedicada
a ese tipo de servicios, las cuales cuentan con los requerimientos bsicos de
funcionamiento. Un ejemplo de un sistema de alarma comercial se muestra
en la siguiente figura:

48

Figura 17: Paquete de sistema de antirrobo vehicular.
Fuente: www.honorio.com.ar

2.5.3. PARTES DE UN SISTEMA DE PROTECCIN ANTIRROBO
VEHICULAR
Por lo general las partes bsicas que componen un sistema de proteccin
antirrobo son:
- Central de control (cerebro)
- Sensores
- Dispositivos de alerta
- Llave de activacin/desactivacin remota
- Batera auxiliar
- Inmovilizadores

49

Figura 18: Partes de un sistema antirrobo vehicular.

2.5.3.1. Central de control
Es el cerebro del sistema, por lo general, en su forma ms bsica se trata de
un equipo que contiene la circuitera necesaria para controlar todo el sistema
de alarma. El trabajo de la central de control es cerrar los contactos que
activan los dispositivos de alerta (sirena, claxon, luces, etc.) cuando se
accionan los dispositivos de deteccin (sensores).
El cerebro se alimenta a travs de la batera del automvil, pero suele
adems contar con una conexin a una batera de respaldo en caso de que
sea cortada la conexin con la batera del vehculo; de hecho, esto puede
ser indicio de la presencia de un intruso, en dicho caso el cerebro dispara las
seales de alerta (Auto radio Honorio, s.f.).

50

2.5.3.2. Sensores
Son los rganos de percepcin del vehculo. Un sensor convierte una
magnitud fsica o qumica (generalmente no elctrica), en una magnitud
elctrica, a fin de que sta represente o identifique a la magnitud real y
pueda ser interpretada por la central de control para que ella tome las
respectivas decisiones (figura 25) (Mattes, B., Schmidt G., Graumann, D. &
Rudolf, P., 2000).

Figura 19: Diagrama de bloque de un sensor.
Fuente: (Mattes, B., Schmidt G., Graumann, D. & Rudolf, P., 2000).

Existen varios tipos de sensores que se pueden instalar en un vehculo, y
cada uno puede representar un modo de deteccin diferente, y dependiendo
del nivel de confiabilidad y exigencia se pueden encontrar sensores a una
gran variedad de precios. A continuacin describimos algunos de los ms
comunes.

o Sensor de puerta
Es el elemento bsico de un sistema de proteccin antirrobo. Su forma ms
sencilla puede ser un simple interruptor que es presionado o activado
cuando una de las puertas (ya sea de pasajeros, maletero o capot del
vehculo) se cierra (NC), o se abre (NA). En los vehculos ms modernos ya
vienen instalados, y son los que se encargan de detectar cuando una puerta
51

se abre o se cierra, esto ayuda a realizar ciertas acciones como encender la
luz interior de vehculo o encender la seal de que una puerta no est bien
cerrada (Auto radio Honorio, s.f.).
Estos sensores de puerta pueden detectar si un intruso quiere violar la
seguridad del vehculo ingresando por una de las puertas, pero seran
intiles si ste decidiera ingresar por la ventana por ejemplo. Para ello un
sistema de proteccin antirrobo debe contar adems con otro tipo de
sensores que incrementan la seguridad del vehculo.

o Sensores de choque
La idea de funcionamiento de un sensor de choque es sencilla: si alguien
golpea o mueve de alguna manera el vehculo el sensor de choque enva
una seal de alerta dependiendo de la severidad del movimiento. Esto evita
el riesgo de que el automvil sea robado con un remolque (en cuyo caso no
servira de nada un sensor de puerta ya que no habra necesidad de entrar
al vehculo para robarlo).
Un sensor de choque puede ser construido de muchas maneras, tal vez una
forma sencilla de hacerlo sera colocar un contacto metlico flexible y largo
ligeramente separado sobre otro contacto de metal a fin de que cuando haya
una sacudida se unan los dos contactos y se cierre el circuito lo que
disparara la seal de alarma. El nico inconveniente es que la central no
podra diferenciar entre una sacudida leve, de una fuerte, dando como
resultado gran cantidad de falsas alarmas, por lo que en el mercado suelen
encontrarse sensores de choque un poco ms sofisticados que entregan
varias seales dependiendo de la magnitud del movimiento (Lpez, E. &
Moya, V., 2009).
52

Figura 20: Sensor de choque.

El sensor de la figura 20 funciona de la siguiente manera: est compuesto
por un contacto central, una pequea bola metlica, y unos contactos
secundarios. En estado de reposo, la bola metlica est tocando a la vez un
contacto secundario y el contacto central, cerrando as el circuito, e
indicando al cerebro que no hay ningn cambio externo. Cuando el vehculo
recibe una leve sacudida, la bola se separa momentneamente del contacto
central abriendo el circuito advirtiendo al cerebro del leve movimiento. Si el
movimiento es demasiado brusco, la bola se desplazar una distancia mayor
pasando sobre ms contactos secundarios, as, basndose en la cantidad de
contactos secundarios por los que a rodado la bola y el tiempo, el cerebro
puede interpretar que se trata de un golpe mayor y generar un aviso de
alerta ms fuerte.

o Sensores de sonido
Un sensor de sonido es bsicamente un micrfono que ha sido configurado
para responder a ciertos niveles de frecuencia solamente. Un micrfono
53

mide las variaciones en la fluctuacin atmosfrica y convierten este patrn
en variaciones de corriente. Se utilizan para detectar la ruptura de un vidrio,
ya que al romperse ste genera un sonido estridente en cierto rango de
frecuencia, que es detectado por el micrfono, y omite los dems sonidos en
un rango de frecuencia diferente. Se instalan en la parte interior del vehculo
(Lpez, E. & Moya, V., 2009).

o Sensores de inclinacin
Su funcionamiento es similar al de los sensores de choque, con la diferencia
de que ste sensor est enfocado a detectar especficamente la inclinacin
de un vehculo cuando est tratando de ser remolcado.
Uno de los detectores de inclinacin ms comunes son los interruptores de
mercurio. El mercurio es un metal que a temperaturas ambiente se
encuentra en su forma lquida, es decir que fluye como el agua, pero aun as
conduce la electricidad como un metal slido. Su construccin es bsica y la
podemos apreciar en la figura 21.
Como podemos apreciar, ambos contactos del sensor est sumergidos en
mercurio, lo que cierra el circuito. Si el sensor es inclinado en un
determinado ngulo, el mercurio se desplazar y uno de los contactos dejar
de estar sumergido en el metal lquido, lo que abrir el circuito. Basndose
en la lgica de los sensores anteriormente analizados el cerebro de la
alarma ya puede interpretar si hay un estado de alerta o no.

54

Figura 21: Sensor de inclinacin.

o Sensores volumtricos
Este sensor es uno de los ms estables y completos ya que puede detectar
un intento de robo ya sea que el intruso abra la puerta o rompa uno de los
vidrios, y no da falsas alarmas por efectos en el exterior como sonidos a
altas frecuencias que no tienen nada que ver con el intento de robo.
Bsicamente se compone de un transmisor y un receptor de ultrasonido, y
un transductor que transforma esa frecuencia de ultrasonido en un impulso
de corriente elctrica. Se ubican en el interior del vehculo en la parte
superior del parabrisas apuntando en ngulo hacia atrs.
Su funcionamiento se basa en el principio de reflexin de ondas acsticas, y
se puede entender en la figura 22. Cuando un sonido es emitido por una
fuente se produce una fluctuacin en la presin del aire y una forma de
energa denominada onda acstica se desplaza a travs del aire en
direccin opuesta a la fuente que lo origin hasta desvanecerse; pero si un
obstculo fsico se interpone en la direccin de las ondas, ests chocan en
dicho obstculo y rebotan en direccin opuesta, como un espejo (Auto
radio Honorio, s.f.).
55

Figura 22: Funcionamiento de un sensor de ultrasonido.

Este fenmeno puede ser aprovechado por los sensores de ultrasonido, los
cuales producen peridicamente una onda ultrasnica, la cual se desplaza
por el interior del vehculo y rebota en las paredes, vidrios, asientos del
vehculo. Luego el receptor de ultrasonido recibe la seal rebotada y mide
el tiempo que sta demor en ir y volver, con lo cual genera un patrn que
es utilizado para detectar cualquier cambio en el espacio fsico dentro del
vehculo. Este sensor es muy til si se rompe una ventana del vehculo o un
intruso ingresa al interior del vehculo. Aunque en realidad con estos
sensores no es posible medir el volumen real o espacio interior del vehculo
se dice que son volumtricos porque su respuesta depende mucho del
espacio fsico en el interior del automvil.

2.5.3.3. Dispositivos de alerta
Un sistema de proteccin antirrobo debe disparar algn tipo de alerta cuando
uno de los sensores se haya activado para dar aviso al propietario de que su
vehculo est en peligro de ser robado, y adems, para disuadir al intruso de
su intento de robo.
56

Como mnimo la mayora de las alarmas harn sonar el claxon y hacer
destellar las luces cuando se haya detectado el intento de robo, aunque, es
ms comn encontrar alarmas que activan una sirena que emite una
variedad de sonidos, que en algunos casos pueden ser programados para
que el usuario pueda diferenciar el sonido de alerta de su vehculo de los de
otros. Los sistemas ms sofisticados poseen un equipo que reproduce una
voz pregrabada con la intencin de notificar al intruso que ha sido detectado
y que desista de su intento de robo (Auto radio Honorio, s.f.).

Figura 23: Sirena instalada en el interior del guardamotor de un vehculo

2.5.3.4. Llave de activacin y desactivacin remota
La llave de activacin y desactivacin remota o tambin conocido como
control remoto funciona como un transmisor que enva una seal codificada
a un receptor instalado en el interior del vehculo y con cuyo cdigo le
permite al sistema de proteccin saber si el usuario quiere activar la alarma
o desactivarla leyendo y autentificando dicho cdigo, basta simplemente con
presionar un botn para enviar la seal. Normalmente se presentan como un
llavero para la llave de las puertas y encendido del vehculo, como se ilustra
en la figura 24.
57

Adems de encender y apagar la alarma, algunos controles presentan la
opcin de silenciar la sirena en caso de que se dispare la alarma, abrir y
cerrar los seguros de las puertas, o encender la alarma pero desactivando
los sensores. Los sistemas ms sofisticados permiten incluso tener acceso
al cerebro del vehculo y bloquear el encendido del motor.

Figura 24: Control remoto de un sistema de seguridad vehicular.
Fuente: (Lpez, E. & Moya, V., 2009)

Una llave de activacin/desactivacin remota funciona enviando a seal
modulada travs de una radiofrecuencia (generalmente con un alcance de
hasta unos 50m dependiendo del fabricante) con un cdigo que es
interpretado por el receptor; as para una determinada marca de alarmas
deben existir millones de cdigos diferentes a fin de que cada alarma tenga
un cdigo nico y no pueda activar alarmas de otros vehculos cercanos. Sin
embargo ste mtodo no es inviolable, ya que alguien podra usar un
detector de seales radiotransmitidas y grabarlo obteniendo as el cdigo de
desarme original, el cual lo puede usar para desactivar la alarma desde otro
transmisor cualquiera. Para evitar este inconveniente sistemas ms
actualizados utilizan algoritmos de codificacin para hacer que el receptor
genere un nuevo cdigo cada vez que la alarma es activada/desactivada,
ste nuevo cdigo es encriptado y enviado al transmisor, y de ese modo
aunque alguien intente grabar el cdigo de desarme, no ser til puesto que
58

en el siguiente proceso de activacin/desactivacin la alarma requerir un
nuevo cdigo.

2.5.3.5. Bateria auxiliar
O tambin llamada batera de respaldo, es una fuente de alimentacin que
provee el voltaje necesario para abastecer el sistema de proteccin en caso
de que se desconecte la batera principal durante un tiempo razonable para
frustrar el intento de robo. Permanece inactiva mientras el sistema est
siendo alimentado con la batera principal y se carga de sta si su nivel de
voltaje ha disminuido.
Generalmente los sistemas de alarma generan una seal de alerta cuando la
batera principal ha sido desconectada ya que esto es indicio de un intento
de robo.

2.5.3.6. Inmovilizadores
Un inmovilizador es un elemento de seguridad activa de un sistema de
proteccin antirrobo vehicular. Consiste bsicamente en un dispositivo
electrnico que impide el accionamiento del motor de un vehculo cuando se
ha detectado una alerta de robo o simplemente mientras no sea desactivado
con la llave autorizada. Los inmovilizadores son elementos de seguridad
activa porque no simplemente dan alerta de que el vehculo est siendo
robado, sino que realiza una accin a fin de evitar que el hurto se lleve a
cabo. ). Su funcionamiento se basa en el bloqueo de la unidad de mando del
motor, que si no se dan las circunstancias adecuadas, no excita el rel de la
bomba de combustible y no activa ni a los inyectores ni a la etapa de
potencia del encendido (Wikipedia, Immobiliser).
Existen varios tipos de inmovilizadores, y se diferencian bsicamente en el
mtodo que utilizan para activar o desactivar el inmovilizador, y el mtodo
que controla el arranque del motor.
59

o Inmovilizador con llave transponder
El inmovilizador con transponder es un sistema que solo permite el arranque
del vehculo con las llaves autorizadas. Intentarlo con cualquier otra llave
implica que el motor arranca, pero solo funciona durante algunos segundos
(en la mayora de los casos). En la siguiente figura se ilustra el esquema de
funcionamiento de este tipo de inmovilizador.

Figura 25: Funcionamiento de un inmovilizador con transponder.
Fuente: (Sapia, 2002)

En el sistema de inmovilizador con transponder, la llave incorpora un
pequeo chip insertado en el mango de la misma (como se muestra en la
figura 26) y que emite un cdigo por radiofrecuencia en el momento en que
se acciona el contacto. Este cdigo es captado por una antena o unidad
lectora, normalmente ubicada en el conmutador de arranque. Si el cdigo
enviado coincide con el cdigo almacenado por la unidad receptora autoriza
el arranque del motor, caso contrario lo bloquea.

60

Figura 26: Llave de puerta del vehculo con chip transponder.

o Inmovilizador con comando remoto infrarrojo
Este tipo de inmovilizador utiliza un control remoto infrarrojo que al igual que
la llave transponder puede estar incorporado en el mango de la llave. En
este caso no hay antena, solo un emisor infrarrojo y un receptor que puede
estar ubicado en el plafn del espejo retrovisor. La lgica de funcionamiento
es la misma que con las llaves transponder. En el siguiente esquema (figura
27) vemos que el sistema integra el receptor infrarrojo y el receptor a la
central electrnica para habilitar o deshabilitar el accionamiento del motor del
vehculo.

Figura 27: Diagrama de bloques de un inmovilizador con comando infrarrojo.

61

o Inmovilizador con teclado numrico
Este sistema incorpora un teclado numrico cercano a la ubicacin del
conductor, que puede estar en el tablero de comandos, o en la base del
volante. El conductor debe ingresar una clave de 4 dgitos para autorizar o
bloquear el accionamiento del motor del vehculo. En la figura 28 se ilustra el
esquema de este tipo de inmovilizador.

Figura 28: Diagrama de bloques de un inmovilizador con teclado.

Como ventaja de este sistema frente a los otros mencionados anteriormente
es que el usuario no debe portar el control remoto que en caso de perderse
o daarse el sistema quedara inutilizable. Por otra parte la desventaja sera
que el usuario debe recordar la clave de acceso, y en caso de olvidarla
contactarse con el fabricante para poder reactivar el sistema (Sapia, 2002).

1

3. METODOLOGA

63

En este captulo se van a detallar los mtodos y procesos que se debern
llevar a cabo a fin de llegar a la consecucin del sistema propuesto. Para ello
nos basaremos en los principio de la metodologa de desarrollo de sistemas
mecatrnicos. Esta investigacin comienza con el estudio de los comandos
AT para dispositivos mviles y el establecimiento de la comunicacin entre
un mdem GSM previamente seleccionado y un circuito de control cuyo
cerebro es un microcontrolador. El microcontrolador utilizado debe ser capaz
de proveer el nmero suficiente de puertos de entrada necesarios para
recibir la informacin de un sensor de activacin, el mdem GSM y un
indicador de estado de batera auxiliar; y as mismo el nmero de puertos de
salida necesarios para activar las salidas de alarma, bloqueo, y envo de
cdigos al mdem.
Tambin se analizar sobre cul ser el mtodo ms efectivo para realizar el
bloqueo del automvil; uno de los mtodos puede ser la inhabilitacin de la
bomba de combustible, y el otro, des-energizacin del sistema elctrico y de
ignicin, se debe tomar en cuenta factores determinantes como la
inviolabilidad del sistema, la seguridad fsica tanto de los ocupantes del
vehculo como del vehculo mismo y la factibilidad tcnica de los mtodos en
cuestin.
En el plano de control se estudiar el desarrollo de aplicaciones mviles para
dispositivos Android utilizando herramientas de programacin que permitan
una comprensin fcil de la lgica de funcionamiento y adecuados niveles de
seguridad informtica.

3.1. METODOLOGA MECATRNICA
En la figura 29 se muestra un diagrama de la metodologa de diseo de
sistemas mecatrnicos, en donde se puede apreciar los pasos a realizar
desde la modelacin y simulacin de componentes mecnicos, pasando por
el diseo del sistema de control hasta la consecucin de un prototipo final al
64

cual se le deben realizar las pruebas respectivas para valida el producto
final.

Figura 29. Esquema de la Metodologa del diseo de sistemas mecatrnicos
Fuente: (Vargas, 2000)

3.1.1. REQUERIMIENTOS DEL PROYECTO
En esta seccin se describen las caractersticas necesarias para el correcto
funcionamiento del sistema. Aqu se detallan los requerimientos de
acondicionamiento de seal de entrada, tanto GSM como sensores de
activacin; arquitecturas de los dispositivos de control, y actuadores o
dispositivos de salida.

65

3.1.1.1. Acondicionamiento de seales de entrada
Las seales que el sistema debe recibir e interpretar son bsicamente, el
pulso de corriente discreto proveniente del sensor que detecta la posible
alerta de robo; y los cdigos de activacin enviados a travs de mensajes de
texto o SMS entre el mdem instalado en el mdulo del vehculo y el
dispositivo mvil del usuario. A continuacin se va a detallar las condiciones
de operacin de estas seales para el correcto funcionamiento del sistema
en su totalidad.

o Sensores de activacin.
Los sensores de activacin se encargan de activar el estado de alerta de la
alarma, es decir, detectan cuando existe una alerta de robo. Deben ser lo
suficientemente confiables para que sus detecciones se acerquen lo ms
posible a los verdaderos estados de peligro o seguridad, es decir que no
deben dar demasiadas falsas alarmas activndose con la ms mnima
alteracin, ni tampoco permanecer inactivos cuando realmente si exista
peligro de intrusin.
En este proyecto para fines demostrativos se utilizarn sensores de choque
parecidos al de la figura 30, de los que se instalan conjuntamente con las
alarmas convencionales, estos son sensores de tipo discreto, es decir que
su seal solo se interpreta en estados lgicos altos y bajos, por lo que no es
necesario realizar un circuito amplificador de seal, simplemente bastar con
conectar la salida del sensor a la entrada del microcontrolador o a lo mucho
implementar un rel o circuito de conmutacin con un transistor y una
resistencia, tal como se muestra en la figura 31.

66

Figura 30. Sensor de choque
Fuente: www.futurlec.com

Figura 31. Circuito de amplificacin para el sensor de choque

o Red GSM.
Debido a que el sistema se basa en el control de una alarma a travs de la
red GSM de una de las operadoras mviles del pas es importante saber que
sta red provee los requerimientos necesarios para el ptimo funcionamiento
de nuestra alarma.

67

Operadora:
En primer lugar la red celular elegida ser la provista por la operadora
Claro, que es una marca de la empresa Conecel S.A. y que oferta servicios
de telefona celular con tecnologa 3.5G con niveles satisfactorios de calidad
de seal, transmisin de informacin y seguridad.

Servicios:
Este proyecto va a requerir del servicio de envo y recepcin de mensajes
SMS a travs de un dispositivo mvil, y del mdem GSM, los cuales tienen
un costo fijo dependiendo del tipo de contrato. En la siguiente tabla se
detallan los costos de los mensajes.

Tabla 7. Precios de paquetes de SMS.
Ideas SMS
Pospago
Precio
Precio
Final
Precio x
SMS
Adicional *
Precio Final
x SMS
Adicional *
Cantidad
de SMS
Incluidos
Evento $ 0,06 $ 0,07 X x 1
Ideas 30 SMS $ 0,75 $ 0,84 $ 0,06 $ 0,067 30
Ideas 50 SMS $ 1,20 $ 1,34 $ 0,06 $ 0,067 50
Ideas 90 SMS $ 1,50 $ 1,68 $ 0,06 $ 0,067 90
Ideas 160 SMS $ 2,50 $ 2,80 $ 0,06 $ 0,067 160
Ideas 240 SMS $ 3,75 $ 4,20 $ 0,06 $ 0,067 240
Ideas 2800
SMS
$ 11,99 $ 13,43 $ 0,06 $ 0,067 2800
* Precio x SMS adicional aplica una vez terminada la Cantidad de SMS
Incluidos.
Fuente: www.claro.com

68

Dispositivos mviles:
El dispositivo mvil que controla el sistema es parte fundamental del
proyecto, ya que no sera posible en cualquier equipo instalar una aplicacin
con una interfaz grfica y de control. Se utilizar un telfono mvil cuyo
software corra sobre una plataforma Android, debido a la gran acogida y
proyeccin que han mostrado stos dispositivos en los ltimos aos, adems
de ser desarrollados como software libre y presentar caractersticas loables
como su accesibilidad, flexibilidad, velocidad, etc. frente a otras plataformas.
En la siguiente tabla se observan algunas diferencias entre los sistemas
operativos ms utilizados en el mundo.

Tabla 8. Diferencias entre algunos sistemas operativos Mviles.

Plataforma
Windows Phone 7 Windows Mobile 6.5 iPhone OS 1.0 iOS 4.0 Android Symbian Maemo 5
Requerimientos mnimos del sistema Si No Si Si No No No
Tipo de pantalla Capacitiva Cap./Res. Capacitiva Capacitiva Cap./Res. Cap./Res. Resistiva
Fabricante nico? No No Si Si No No No
Tipo de sistema operativo Cerrado Cerrado Cerrado Cerrado Abierto Abierto Abierto
Soporte de memoria externa Si Si No No Si Si Si
Copiar y pegar No Si No Si Si Si Si
Multitarea No Si No Si Si Si Si
Multitctil Si No Si Si Si Si Si
Fragmentacin No Si No No Si No No
Tienda de aplicaciones Marketplace Marketplace No App Store Market Ovi Store Ovi Store
Tono de llamada personalizable No Si No Si Si Si Si
MMS Si Si No Si Si Si No
Soporte Adobe Flash No Si No No Si Si Si
Tethering No Si No Si Si Si Si
Interfaz personalizable Si Si No No Si Si Si
Fuente: www.moviltoday.com

El mdem GSM que va a ser instalado en el vehculo como parte del circuito
electrnico de control del sistema de alarma, debe cumplir con las
especificaciones siguientes:
69

- Tecnologas de soporte: GSM/GPRS
- Banda de frecuencia: 850 MHz
- Baud rate: 115200 bauds
- Tensin de alimentacin: 12 VDC
- Conexin para antena

Tarjeta SIM.
Las tarjetas SIM instaladas tanto en el dispositivo mvil como en el mdem
GSM deben cumplir las siguientes especificaciones:
- Que funcione en la banda 850
- Que tenga AMR (Codificador-descodificador de voz que adapta su
funcionamiento a las condiciones del canal.)
- Que no est reportado como robado
- Y que el modelo y marca del equipo est debidamente registrado
como homologado en la SUPTEL

Cobertura de red.
El proyecto en cuestin ser desarrollado y aplicado en la ciudad de Quito,
por lo que se requiere que el sistema de telefona celular tenga completa
cobertura en la zona urbana de la ciudad y sus alrededores. En la tabla 9 se
muestra la cobertura celular ofertada por la operadora mvil en la provincia
de Pichincha.

Tabla 9. Cobertura celular en la provincia de Pichincha.
PROVINCIA CIUDAD/POBLACIN CANTN 1W 2W
PICHINCHA Alangas Quito 1W
70

PICHINCHA Amaguaa Quito 1W
PICHINCHA ATAHUALPA (HABASPAMBA) Quito 1W
PICHINCHA Cala Cali Quito 1W
PICHINCHA CALDERON (CARAPUNGO) Quito 1W
PICHINCHA Canchacoto Quito 1W
PICHINCHA Chavezpamba Quito 1W
PICHINCHA CHECA (CHILPA) Quito 1W
PICHINCHA Conocoto Quito 1W
PICHINCHA Cumbay Quito 1W
PICHINCHA El Arenal Quito 1W
PICHINCHA El Quinche Quito 1W
PICHINCHA El Vergel Quito 1W
PICHINCHA Gualea Quito 1W
PICHINCHA Guangopolo Quito 1W
PICHINCHA Guayllabamba Quito 1W
PICHINCHA Llano Chico Quito 1W
PICHINCHA Llano Grande Quito 1W
PICHINCHA Lumbisi Quito 1W
PICHINCHA Miravalle Quito 1W
PICHINCHA Nanegalito Quito 1W
PICHINCHA Nayon Quito 1W
PICHINCHA Oyacoto Quito 1W
PICHINCHA Pacto Quito 1W
PICHINCHA Pifo Quito 1W
PICHINCHA Pintag Quito 1W
PICHINCHA Pomasqui Quito 1W
PICHINCHA Puellaro Quito 1W
PICHINCHA Puembo Quito 1W
PICHINCHA Quito Quito 1W
PICHINCHA SAN ANTONIO Quito 1W
PICHINCHA San Jos de Minas Quito 1W
71

PICHINCHA San Pedro de Taboada Quito 1W
PICHINCHA Tababela Quito 1W
PICHINCHA Tumbaco Quito 1W
PICHINCHA Yaruqu Quito 1W
PICHINCHA Zambiza Quito 1W
PICHINCHA La Merced Quito 2W
PICHINCHA Perucho Quito 2W
Cobertura 1W: significa que los niveles de seal en la poblacin indicada son
ptimos y permite que los usuarios tengan muy buena cobertura en cualquier
punto de la poblacin indicada, aun dentro de casas y domicilios.
Cobertura 2W: significa que los niveles de seal en la poblacin indicada son
buenos, por tanto se garantiza cobertura solo en exteriores y lugares abiertos
dentro de la poblacin indicada. Los niveles de seal no permiten garantizar
cobertura dentro de casas y edificios.

3.1.1.2. Sistema de control
o Microcontrolador.
Un microcontrolador es un dispositivo electrnico encapsulado en forma de
chip, el cual puede realizar varias tareas segn sean programadas en su
memoria interna las instrucciones para realizar dichas tareas. Su
arquitectura se asemeja mucho a la de una computadora, solo que en menor
escala de almacenamiento de informacin y procesamiento, ya que
comparte caractersticas como CPU, memorias, ALU, etc., pero no posee
ningn perifrico de entrada o salida.
Un microcontrolador es un elemento muy verstil ya que permite escribir
borrar instrucciones sobre su memoria EEPROM un elevado nmero de
veces sin que ste pierda su capacidad de procesamiento, lo que lo hace
muy til para aplicaciones de prueba y ensayo.
En el proyecto, el microcontrolador ser el cerebro del subsistema
electrnico encargado de leer el estado de los sensores de entrada,
72

establecer comunicacin con el mdem, y controlar las salidas
correspondientes.

Tabla 10. Tabla de comparacin PIC16f628a y PIC16f877a
Caractersticas PIC16f628a PIC16f877a
Mxima frecuencia de operacin (MHz) 20 20
Memoria de programa (words) 1024 8K
Memoria RAM de Datos
(bytes)
224 386
Memoria EEPROM Datos (bytes) 128 256
Interrupciones 10 15
Lnea de E/S 16 Ptos. A, B, C, D, E
Mdulos de comparacin/Captura/PWM
(CCP)
1 2
Comunicacin Serial USART MSSP, USART
Encapsulados 18-pin DIP,
SOIC, 20-
pin
SSOP,
28-pin QFN
40-pin PDIP
44-pin PLCC
44-pin TQFP
44-pin QFN
Fuente: (Hoja tcnica del PIC16f628a, PIC16f877a )

73

Como se observa en la tabla 10 el PIC16f628a cumple con los
requerimientos bsicos para este proyecto, por lo cual va a ser ste el que
se utilice para la construccin del prototipo. En la figura 32 se muestra la
arquitectura interna del PIC16f628a, se puede analizar que posee una
estructura similar a la de una computadora; en se distinguen bloques como
los puertos de entrada/salida, memoria de programa flash, memoria RAM,
temporizadores, comparadores, etc.

Figura 32. Arquitectura del PIC16f628a.
Fuente: (Hoja tcnica del PIC16f628a)

74

o Sistema operativo mvil
Como se mencion anteriormente el sistema operativo del dispositivo mvil
seleccionado ha sido la plataforma Android de Google, por su facilidad de
desarrollo en cuanto a aplicaciones se refiere y por tratarse de un software
totalmente libre. Las caractersticas del dispositivo mvil elegido son las
siguientes:
- Marca: Motorola
- Modelo: XT316
- Versin de Android: 2.3.4 (Gingerbread)
- Versin de ncleo: Apps_2.6.32.9
- Versin de banda base: PR2
- Tipo de red mvil: HSDPA

Figura 33. Telfono mvil Motorola XT316

La figura 13 del captulo anterior muestra la arquitectura del sistema
operativo Android denominada Stack. En ella se puede observar las
75

diferentes capas del sistema operativo. El desarrollo de este proyecto
involucra principalmente a dos de ellas:
- Application layer.- especficamente en la seccin de Developer Apps,
ya que no se realizar ninguna modificacin de las aplicaciones
existentes, solamente se crear una nueva aplicacin.
Application framework.- Se utilizaran algunos de los mtodos e instrucciones
de sta capa para desarrolla nuestra aplicacin.

3.1.1.3. Actuadores y dispositivos de salida
Este proyecto va a tener como funcin determinante la de bloquear el
vehculo en caso de haber una alerta de robo, por lo que sta ser su
principal salida, es decir que el sistema va a disponer de una salida que
determine si el vehculo se bloquea o no. Primeramente se debe determinar
el significado bloqueo, el cual selo puede definir como un mtodo de
seguridad vehicular en el que se inhabilita la movilidad del vehculo por
personas no autorizadas, es decir que al bloquear un automvil, ste no
puede arrancar, o si ya ha arrancado, se apagar el motor y no podr
arrancar nuevamente.
Existen varios mtodos de bloqueo de vehculos, entre ellos est el mtodo
bloqueo por apertura del sistema elctrico y de ignicin, y el mtodo de
bloqueo por corte de flujo de combustible.

o Bloqueo del vehiculo (sistema elctrico)
En la figura 34 se aprecia un esquema simplificado del sistema elctrico de
un vehculo. Las principales partes que componen el sistema elctrico de un
vehculo son:
- Fuente de alimentacin o Batera
- Llave de encendido
76

- Bobina
- Condensador
- Ruptor
- Distribuidor
- Bujas
- Cables de baja y alta tensin

Figura 34. Sistema de encendido e ignicin de un automvil
Fuente: www.automecnico.com

El funcionamiento del sistema de encendido automotriz es sencillo. Se basa
en la produccin alterna de alto voltaje de forma peridica para producir una
chispa en los cilindros del motor de modo que se produzca la explosin que
da lugar al movimiento continuo de los pistones del motor. Una batera de
12V alimenta al circuito primario del sistema que consiste en una bobina, un
ruptor que funciona como un sistema de leva, y un condensador. Cuando la
llave de encendido cierra el circuito, una corriente elctrica circula a travs
del bobinado primario de la bobina, el ruptor se encarga de abrir y cerrar
peridicamente los contactos o platinos que a su vez permiten o cierran el
paso de la corriente a travs de la bobina. La funcin del condensador es de
77

permitir un rpido descenso de la corriente para evitar chispazos en las
platinas del ruptor, lo que ocasiona desgaste de su superficie de contacto.
Cada vez que la bobina se energiza/desenergiza se crea un campo
magntico, el mismo que induce una corriente alta en el bobinado
secundario de la bobina; sta corriente alta se utiliza para producir la chispa
en las bujas del motor a travs del distribuidor, el cual es encargado de
seleccionar a cual buja se debe enviar la corriente de la bobina mediante un
sistema de seleccin rotativo (rotor).
Como se puede notar, el elemento principal del sistema de encendido
elctrico e ignicin es la bobina, por lo que al suprimir la alimentacin de
energa a este elemento es posible bloquear el vehculo. El circuito de
bloqueo se vera como se muestra en la figura 35.

Figura 35. Esquema de interfaz con rel
Fuente: www.ucontrol.com

La seal de datos provendra del microcontrolador y los contactos del rel se
encargaran de abrir el paso de la corriente a travs de la bobina
produciendo as el bloqueo del vehculo.

78

3.1.2. DISEO MECNICO
Evidentemente este proyecto no incurre muy profundamente en el desarrollo
de un componente mecnico debido a que el sistema es controlado
enteramente por los componentes electrnico y de control. Sin embargo al
ser un proyecto de aplicacin en el campo automotriz, es importante conocer
el funcionamiento bsico de un vehculo y los fenmenos fsicos, mecnicos
y elctricos que se llevan a cabo para que ste entre en movimiento, y as
poder determinar los procesos necesarios para realizar el bloqueo y
desbloqueo.

3.1.2.1. Funcionamiento de un vehculo a gasolina con motor de
combustin interna
Un automvil es una mquina de transporte de personas u objetos
autopropulsado gracias a un motor de combustin interna en el caso de los
vehculos que utilizan combustibles fsiles, o por un motor elctrico.
Un vehculo con motor de combustin interna posee los siguientes sistemas:
o Motor
Es el componente principal de un vehculo; es el mecanismo encargado de
proporcionar el movimiento rotatorio que mueve las ruedas del vehculo.
Funciona en base a la combustin de una mezcla de aire y gasolina
producida en una cmara cilndrica, sta explosin impulsa los pistones que
junto con las bielas y el cigeal transforman el movimiento rectilneo
alternativo en un movimiento circular. La gasolina es bombeada desde el
depsito de combustible al motor pasando por un proceso de filtrado, y
depuracin. El proceso cclico de funcionamiento del motor se divide en
cuatro etapas principales que son: admisin, compresin, explosin y
escape; por esta razn a estos motores tambin se los denomina Motores de
cuatro tiempos.

79

o Sistema de ignicin
Tambin llamado sistema elctrico, es encargado de generar la chispa que
enciende la mezcla de aire y combustible en cada uno de los cilindros del
motor. Para ello utiliza una bobina que genera un alto voltaje que se
distribuye de forma sincronizada a cada una de las bujas que producen la
chispa. El dispositivo encargado de distribuir la corriente se denomina
distribuidor o delco, que junto a un ruptor determinan en qu momento se
abren y se cierran los contactos que dan paso a la energa para mover el
pistn indicado. La bobina posee dos bobinados, uno primario y otro
secundario; el primario es de bajo voltaje y se alimenta con la fuente de
voltaje (batera) del vehculo, mientras que el bobinado secundario es el que
produce el alto voltaje mencionado anteriormente. (www.shop-repair.com).

Con base en lo mencionado anteriormente, se observa que el motor de
combustin interna es el elemento principal de un vehculo y sin cuyo
correcto funcionamiento el vehculo resultara incapacitado para moverse por
si mismo. En consecuencia existen dos mtodos convencionales para
realizar el bloqueo del vehculo: Deshabilitar la bobina del sistema de
ignicin, o Deshabilitar la bomba de gasolina. En el primer caso, al des-
energizar la bobina de ignicin, se elimina el alto voltaje que es aplicado a
las bujas que encienden la mezcla, en consecuencia no hay explosin de la
mezcla y el motor del vehculo se apaga ocasionando el paro y bloqueo del
vehculo. En el segundo caso, se deshabilita la bomba de gasolina, lo que
impide la circulacin de gasolina hacia el motor apagndolo en cuestin de
segundos. Cualquiera de las dos opciones es vlida para este proyecto, sin
embargo se ha escogido hacerlo mediante el mtodo de la bobina debido a:
- Es el mtodo convencional ms utilizado en los sistemas de bloqueo
vehicular.
- Facilidad de instalacin, ya que se lo realiza cerca del tablero de
mandos del vehculo, en donde se pueden realizar las respectivas
conexiones.
80

Es ms difcil de detectar y realizar un bypass.

3.1.3. DISEO ELECTRNICO
En esta seccin se analizar el funcionamiento del circuito electrnico y de
control del proyecto. Para entender el funcionamiento de las diferentes
partes del circuito electrnico se ha realizado el siguiente diagrama de
bloques (figura 36) que representa como se encuentra diseado el circuito.

Figura 36. Diagrama de bloques del proyecto.

3.1.3.1. Circuito de adquisicin de seal del sensor
El sensor utilizado para activar la alerta de la alarma es como ya se
mencion anteriormente un sensor de choque, aunque puede ser otro tipo
81

de sensor, dependiendo de lo que se quiere sensar. Estos son sensores
discretos que son alimentados por una fuente fija y a su salida envan un
valor de voltaje que cambia dependiendo de la condicin del entorno que
est siendo sensado, es decir que se basan en la premisa est no est,
para determinar que la salida de voltaje represente uno de los dos estados;
lo ms comn es encontrar sensores con salidas de voltaje en niveles TTL,
esto quiere decir que un estado lgico bajo se representar mediante un
valor de 0V y un estado lgico alto mediante un valor de 5V (aunque
realmente ese valor oscila entre unos 3,5 a 5V).
En este caso se usar un sensor de choque estndar utilizado en las
alarmas marca Nemesis distribuidas en almacenes de accesorios para
autos. Este sensor detecta cualquier vibracin fsica que rompa la inercia en
su entorno, y puede ser regulado para ajustar su sensibilidad. Cuando no
detecta ninguna vibracin el sensor enva a su salida un valor de voltaje de
5V aproximadamente. Al detectar una vibracin en su entorno, ste cambia
el estado de su salida enviando 0V, la figura 37 explica lo anteriormente
expuesto.
82

Figura 37. Funcionamiento del sensor de impacto

Conociendo este comportamiento ya se puede pasar al diseo del circuito de
adquisicin de la seal del sensor de choque, lo cual se va a describir en
detalle en el siguiente captulo.

3.1.3.2. Circuito de comunicacin con el mdem
El cerebro del circuito electrnico es el PIC16f628a. Uno de los principales
sub-sistemas del circuito electrnico es el de la comunicacin serial
microcontrolador -> mdem y viceversa. Existen algunos mtodos para
realizar la comunicacin, como el de la comunicacin paralela, y el de la
comunicacin serial, que son los ms comunes. En este caso se realizar
mediante comunicacin serial utilizando la norma RS-232 ya que es el
mtodo ms utilizado y su ventaja respecto a la comunicacin paralela es
83

que no requiere de muchas lneas de transmisin (una por cada bit),
simplemente se hace la comunicacin a travs de una lnea de transmisin y
una de recepcin, por lo que no ocupa muchos puertos del microcontrolador.
Existen dos tipos de comunicacin serial, la sncrona, y la asncrona, en la
primera se requiere de una seal de reloj que sincronice tanto al receptor
como al transmisor para hacer coincidir el tiempo de duracin de cada bit, a
diferencia de la asncrona, en la cual no existe la seal de reloj sino que se
define previamente en el transmisor y receptor la duracin de cada bit. La
figura 38 muestra un ejemplo de una palabra binaria (8 bits) enviada de
forma serial.

Figura 38. Estructura de un dato serial
Fuente: (Reyes C., 2008)

Debido a que en el programa de instrucciones del microcontrolador se
usarn las instrucciones HSERIN y HSEROUT es preciso usar el puerto
USART (Universal Synchronus/Asynchronus Receiver Transmitter), del
PIC16f628a, que est ubicado en los pines 7 (RB.1) y 8 (RB.2) que vienen a
ser el receptor y el transmisor respectivamente.

84

Figura 39. Pines del puerto USART del PIC16f628a
Fuente: (Hoja tcnica del PIC16f628a)

3.1.3.3. Circuito de salida del rel para bloqueo del vehculo
Esta parte del circuito nos permitir realizar el bloqueo del vehculo mediante
una salida de rel, cuyos contactos actuarn como un interruptor general en
el sistema elctrico de ignicin del vehculo. Bsicamente el rel abrir y
cerrar el paso de corriente a travs del bobinado primario de la bobina de
encendido que se encarga de entregar el alto voltaje para la produccin del
chispeo en las bujas del motor.
Ya que el elemento ms relevante en el sistema elctrico del vehculo es la
bobina, hay que tomar en cuenta las caractersticas de sta al momento de
disear un sistema de corte para sta. El mtodo ms comn es el del uso
de un rel o interruptor electromecnico. En este circuito el microcontrolador
enviar una seal de activacin a un rel; y sus contactos se conectarn en
serie a la bobina de encendido, entonces, es necesario determinar los
parmetros de rel, tanto de la bobina del rel como de sus contactos.

- Tensin de alimentacin del rel: 5V
- Corriente de consumo de la bobina del rel: 200mA
85

Para determinar la corriente mxima que deben soportar los contactos del
rel se debe calcular cual ser la corriente de consumo de la bobina de
encendido.

3.1.4. DISEO DEL SISTEMA DE CONTROL
Se puede definir al sistema de control como el software del proyecto, la parte
encargada de establecer las instrucciones y procedimientos ya sean
secuenciales o simultneos y que definen el comportamiento del hardware
del sistema. En este proyecto van a definirse dos tipos de sistema de control,
uno de ellos ser el conjunto de instrucciones que definir el funcionamiento
del microcontrolador, y el otro, el programa que contiene la lgica de
funcionamiento de la aplicacin Android mvil. Para cada una de ellas se va
a detallar su lgica de programacin, diagrama de flujo y conjunto de
instrucciones.

3.1.4.1. Programa del microcontrolador PIC16f6281
o Funcionamiento
El circuito electrnico que se ensamblar y se instalar dentro de la unidad
vehicular se encargar de controlar el sistema de seguridad detectando
cualquier peligro de robo, intercambiando informacin desde y a travs del
mdem GSM y bloqueando el vehculo en caso de ser requerido. Para ello el
sistema electrnico cuenta con un procesador de informacin capaz de
realizar las tareas anteriormente mencionadas; se trata de un
microcontrolador EEPROM (Electrically Erasable Programmable Read-Only
Memmory) de la familia PIC con determinadas funciones que puede ser
programado con propsitos especficos de cmputo y almacenaje de
informacin.
Para entender mejor el funcionamiento de este proyecto se definirn algunos
conceptos utilizados en la programacin del mismo.
86

Variable de entrada/salida
Corresponde a un espacio fsico dentro de la memoria del microcontrolador
donde se guarda la informacin que ha de ser recibida de un entorno
exterior, o que ha de ser enviada para ser utilizada en otro sistema.

Variable interna
Es un espacio fsico dentro de la memoria del microcontrolador que
almacena informacin que se utiliza en diferentes partes del programa del
mismo para efectos de cmputo, y que no ha de ser enviada o recibida
hacia/de otro sistema.

Estado del sistema de seguridad
El estado del sistema de seguridad vehicular identifica la condicin actual del
mismo informando al sistema en s que variables utilizar y la informacin que
debe esperar para realizar una determinada accin. En el sistema se han
definido cuatro estados posibles que se explican a continuacin.

Figura 40. Estados del sistema de seguridad vehicular
Elaborado por: William Veloz S.
87

Estado: Alarma Apagada. Una vez que el sistema es energizado con la
batera del vehculo, el programa carga en si las variables necesarias,
ejecuta algunas instrucciones para preparar el mdem y luego entra en este
estado. Cuando el sistema se encuentra en este estado no detectar
ninguna alerta de intrusin aunque exista una respuesta del sensor;
solamente estar en espera de un mensaje con el cdigo de activacin
correcto para pasar al siguiente estado (Alarma Encendida), y en caso de
recibir un mensaje con un texto diferente al esperado lo borrar del buzn de
entrada del modem.
El estado Alarma Apagada generalmente se establece cuando no se desea
tener control sobre la seguridad del vehculo, o si el automvil se encuentra
en movimiento, o encendido, o hay personas dentro del mismo.

Estado: Alarma Encendida/Vehculo desbloqueado. El sistema entra en
este estado una vez que ha recibido el mensaje con el cdigo de encendido.
A partir de este estado, el microcontrolador comienza a escuchar los
sensores de activacin, lo que har que el sistema pase al estado de
Alerta, adems est en espera de un mensaje con el cdigo para apagar la
alarma. Tambin puede establecerse este estado cuando se ha
desbloqueado el vehculo posteriormente al estado de bloqueo.
Para establecer este estado, el vehculo debe estar apagado, permanecer
inmvil, y libre de ocupantes, puesto que el estado de alerta se activara
inmediatamente.

Estado: Alerta de robo. Cuando la alarma est encendida sus sensores
estn detectando si existe algn cambio exterior que pueda significar una
alerta de robo, de darse el caso, enviarn una seal al microcontrolador lo
que har que se inicie el estado de alerta, esto implica que el
microcontrolador enviar un mensaje de texto al mvil que contiene instalada
la aplicacin de control, de ese modo la aplicacin indicar al usuario que
88

existe una alerta de robo y as l puede tomar una decisin sobre si bloquear
el vehculo, o simplemente apagar la alarma.
Estado: Vehculo bloqueado. El sistema entra en este estado si una vez
que se ha iniciado el estado de alerta recibe un mensaje con el cdigo de
bloqueo correcto, ya que si recibe un mensaje con un texto diferente al
esperado simplemente lo borrar del buzn de entrada del mdem. Una vez
en este estado, el sistema simplemente esperar un mensaje para
desbloquear el vehculo, procedimiento que debe realizarse solo cuando se
haya recuperado el automvil.
Cuando se realiza el bloqueo desde la aplicacin mvil se debe ingresar una
clave que es la misma con la que se accede al programa principal, y se debe
realizar el mismo procedimiento para el desbloqueo.

Cdigos de activacin.
Los cdigos de activacin son cadenas de caracteres especficas
transmitidas mediante mensajes de texto enviados desde el mvil que tiene
instalada la aplicacin del sistema de seguridad. El propsito de los cdigos
es mantener un carcter secreto acerca de la forma de controlar el sistema
desde la aplicacin mvil, ya que de ese modo se puede evitar el
arme/desarme del sistema por parte de terceras personas desde otros
mviles.
Con fines demostrativos, a continuacin se presentar una lista (tabla 11)
con los cdigos de activacin y su respectivo propsito; claro est, que
organizacionalmente, los cdigos de activacin deben ser administrados
como informacin extra confidencial.

89

Tabla 11. Cdigos de activacin
Cdigo Nombre Descripcin
+01 Encender Enciende la alarma, sus sensores estn a la
espera de algn cambio.
+02 Apagar Apaga la alarma.
+03 Verificar Enva un mensaje al microcontrolador para que
ste enve un mensaje de respuesta con el estado
en que se encuentra.
+07 Bloquear Bloquea el vehculo. La alarma no puede ser
apagada.
+08 Desbloquear Desbloquea el vehculo. El sistema vuelve al
estado de encendido.

3.1.4.2. Programa de la aplicacin mvil
Una aplicacin mvil es un programa instalado en un dispositivo mvil,
diseado para realizar uno o ms trabajos con un propsito especfico. En el
presente proyecto la aplicacin tiene la finalidad de controlar el sistema de
seguridad instalado en el vehculo, estableciendo comunicacin con el
mdem GSM que forma parte de la circuitera del sistema, y avisando al
usuario mediante etiquetas el estado tanto de la alarma como del vehculo.
La aplicacin ha sido diseada para correr en un dispositivo con sistema
operativo Android, por ende, el desarrollo de la misma se ha realizado con
herramientas provistas por los desarrolladores de la firma Android. Existen
varias herramientas para desarrollar aplicaciones Android; una de las ms
comunes es a travs de un entorno Java, obviamente utilizando el lenguaje
de programacin Java, en donde se escribe el programa, se lo compila para
luego ser transformado para ser instalado en un dispositivo Android, uno de
90

los software Java ms comunes y completos para el desarrollo de
aplicaciones es el Eclipse IDE. Como ventajas de este software se puede
decir que presentan ms opciones y caractersticas al momento de
programar, adems de obtenerse aplicaciones ms seguras, flexibles y
estables; como desventaja principal, est su complejidad y costos elevados
en el desarrollo, que cuando se trata de aplicaciones relativamente sencillas
pueden ser sobrevalorados.
En este proyecto se utilizar una herramienta de programacin ms
simplificada, con una interfaz grfica ms amigable para el usuario, con un
juego limitado de instrucciones y caractersticas pero a la vez suficientes
para el desarrollo de aplicaciones de gama alta. Se trata de una herramienta
web denominada AppIventor desarrollada y sustentada por el MIT
(Instituto Tecnolgico de Massachusetts) y potenciada por Google, la
empresa que desarroll el sistema operativo Android para dispositivos
mviles. Para acceder a esta herramienta simplemente basta con entrar a la
pgina del AppInventor que es la siguiente: http://appinventor.mit.edu/, en
ella se encuentra disponible toda la informacin necesaria para iniciar con el
desarrollo de aplicaciones mviles. El procedimiento que se sigue consiste
en ingresar con una cuenta de Google (si no se tiene cuenta se puede crear
una) en la pgina antes mencionada, descargar e instalar algunos
complementos para el desarrollo, y realizar las configuraciones que la
herramienta requiere.
Para comprender el desarrollo de la aplicacin mvil primeramente se
explicarn unos conceptos referentes al tema.

o App Inventor Designer
Es el rea de diseo y trabajo donde se seleccionan los componentes que
van a formar parte de la interfaz grfica de la aplicacin. Dentro de los
componentes ms utilizados se tienen los siguientes:
Botones (button)
91

Etiquetas (label)
Cuadros de texto (texbox)
Pantalla (screen)
Imgenes (image)
Lienzos (canvas)
Camara (camera)
Reproductores de audio (player)
Llamada telefnica (PhoneCall)
Mensaje de texto (texting)
Sensores (sensor)
Base de datos (TinyDB)
Etc.

o App Inventor Blocks Editor
El editor de bloques del AppInventor es un IDE (Integrated Development
Environment) donde los desarrolladores escriben el cdigo de programacin
que definir como se comportan los componentes de una aplicacin. Aqu se
crea el programa mediante el armado de bloques de construccin, tal como
si se tratara de un rompecabezas. Cada bloque representa una instruccin,
variable, evento, procedimiento, etc., que se ensamblan en una estructura
similar a la de un programa en lenguaje C o Java.
Algunos bloques que conforman el editor de bloques son:
Bloques de definicin
Bloques de eventos
Bloques de procedimientos
Bloques de control
Bloques de datos

92

La forma en cmo se relacionan la paleta de diseo y el editor de bloques
del AppInventor se puede apreciar en la figura 41.

Figura 41. Esquema general del AppInventor
Fuente: appinventor.mit.edu/

3.1.5. SIMULACIN
Se puede decir que simulacin es un proceso en el cual mediante un
ordenador se pone a prueba el modelamiento de un sistema real usando
mtodos numricos y modelos matemticos, a fin de tener una estimacin
del comportamiento del sistema en la vida real.
93

En Mecatrnica es muy importante la simulacin, puesto que esto nos
permite observar y analizar los sistemas antes de poner en ejecucin el
proceso de construccin de los mismos. Existen diversos programas para
realizar simulacin de sistemas mecnicos, electrnicos, elctricos,
neumticos, etc. En este proyecto se va a realizar la simulacin del
subsistema electrnico, es decir todo lo que representa la parte electrnica,
incluyendo el funcionamiento del microcontrolador, su comportamiento ante
la reaccin de los sensores de entrada, la comunicacin con el mdem y su
respuesta expresada en los actuadores de salida.
Algunos de los software de simulacin mas utilizados son el Proteus de
Labcenter, el entorno de desarrollo integrado MatLab de MathWorks, o el
Electronics Workbench de National Instruments. A continuacin se
presentan algunas de las caractersticas ms importantes de cada uno de
los software mencionados anteriomente.

o Proteus 7.7
- Disponible para simulaciones con PIC, 8051, MSP430, AVR, HC11,
ARM7/LPC200, y procesadores Basic Stamp.
- Interactuacin del cdigo fuente con hardware simulado en tiempo
real
- Modelos de perifricos interactivos para displays, teclados, etc.
- Ms de 8000 modelos de dispositivos digitales y anlogos.
- Extensas facilidades de depuracin, incluyendo amplios diagnsticos
del sistema.
- Trabaja con los ms populares compiladores y ensambladores.
Fuente: www.labcenter.com

94

o MatLab R2012b
- Entorno para modelado y simulacin de sistemas mecnicos,
elctricos, hidrulicos, trmicos y otros sistemas fsicos de
multidominio.
- Bibliotecas de bloques de modelado fsico y elementos matemticos
para el desarrollo de componentes personalizados.
- Lenguaje SIMSCAPE basado en MatLab, para la creacin basada
en texto de componentes de modelado fsico, dominios y bibliotecas.
- Capacidad para simular modelos que incluyen bloques de productos
relacionados con la modelacin fsica sin tener que comprar esos
productos.
- Soporte para la generacin de cdigo C.
Fuente: www.mathworks.com

o Electronics Workbench
- Cada esquema listo al instante para simulacin
- Caractersticas nicas, facilidad de uso y funcionalidad avanzada
- Disponible como herramientas de diseo autnomas o como parte de
un conjunto integral
- Habilidad para disear mejores circuitos en menos tiempo
- Simulador de circuito interactivo
Fuente: sine.ni.com

El software elegido para realizar la simulacin del circuito electrnico es el
Proteus versin 7.7 debido a que ofrece soporte para simulacin de circuitos
con microcontroladores PIC en tiempo real. Adems no se realizar ninguna
simulacin de algn sistema mecnico o cualquier otro sistema fsico, por lo
que no es necesario utilizar el MatLab. Por otro lado Electrnic Worbench
presta facilidades de uso y funcionalidades mejoradas pero no incluye el
soporte para simulacin de microcontroladores.
1

4. DISEO

96

En este captulo se describir el diseo, simulacin y construccin de cada
uno de los componentes del producto mecatrnico, que como se sabe
consta de tres partes fundamentales. La primera parte es el sistema
mecnico, en la cual se definen las condiciones de operacin del sistema
referentes a los procesos mecnicos que se llevan a cabo en el vehculo en
el cual es instalado el sistema de seguridad aqu propuesto. La segunda
parte es el sistema electrnico que consiste en el diseo de un circuito
electrnico capaz de funcionar como interfaz entre los sistemas mecnico y
de control mediante la utilizacin de un microcontrolador y sus puestos
necesarios. La siguiente parte es la de control, en ella se definen el conjunto
de instrucciones lgicas necesarias para la correcta operacin del
microcontrolador del circuito electrnico y el desarrollo de una aplicacin
mvil que permita al usuario tener control sobre el sistema en conjunto.

ELECTRNICO
El componente de control se disear para que realice las siguientes
funciones: Leer una seal proveniente de un sensor que detecte un cambio
en el entorno del vehculo (cuando est estacionado y con su alarma
activada) que signifique una posible alerta de robo, establecer comunicacin
serial con un mdem GSM, y bloquear electrnicamente el vehculo.
Bsicamente se compone de un circuito electrnico diseado para ser
ensamblado e instalado dentro de un case donde tambin se ubica el
mdem, el rel de bloqueo del sistema elctrico del vehculo y los terminales
para sus conexiones. El circuito electrnico alberga todos los componentes
electrnicos de control necesarios para la comunicacin entre el
microcontrolador y el mdem, incluyendo la etapa de regulacin de voltaje, el
circuito integrado MAX232, los circuitos de entrada de seal proveniente del
sensor y circuitos de salida. A continuacin se describe en detalle el diseo y
simulacin cada uno de los subsistemas del componente electrnico.

97

4.1.1. CIRCUITO DE ADQUISICIN DE DATOS
Este circuito recibe una seal discreta que representa el estado de seguridad
de la alarma; como se describe en el captulo anterior, el sensor de choque
enva a su salida un valor de voltaje entre 5 y 12 voltios (dependiendo de la
marca y tipo de sensor) cuando no detecta ninguna vibracin fsica, y un
valor de 0 voltios cuando ha detectado alguna vibracin externa. Esto implica
que ya sea el circuito de adquisicin de la seal o el programa del
microcontrolador que va a recibir esa seal debe trabajar con una lgica
inversa. En este caso, el circuito de adquisicin de seal va a trabajar
normalmente como un circuito de paso sin invertir la seal, pero en el
programa se va a tomar el 0 lgico como un valor alto y el 1 lgico como un
valor bajo.
El circuito de adquisicin de seal funciona bsicamente con un transistor
NPN comn, configurado como un buffer, en donde se va a tener a la salida
un voltaje cercano a los 5V necesarios para que el microcontrolador lo
detecte como un valor alto cuando en la entrada de seal exista presencia
de voltaje. El circuito propuesto es el siguiente:

Figura 42. Circuito de polarizacin de un transistor NPN

La batera B1 representa el voltaje de alimentacin del circuito electrnico,
provisto por el transistor regulador de voltaje L7805; La fuente de voltaje B2
Q1
2N3904
D5
1N4004
R2
10k
R6
10k
1
2
B1
5V
1
2
B2
12V
98

es el equivalente al voltaje proveniente del sensor que puede estar entre 5 y
12V, para efectos de clculo se tomar el valor de 12V.
El voltaje que se aplicar a las entradas del microcontrolador debe estar
entre los 3,0 y 5,5V (segn hoja tcnica del pic16f628a); El voltaje de salida
del circuito de adquisicin de seal del sensor se calcula como sigue.
La ley de corrientes de Kirchhoff (Boylestad, 2004) expresa que la corriente
que sale de un nodo es igual a la suma de todas las corrientes que entran,
aplicando esa declaracin a un transistor se tiene que:

Dnde:
I
E
es la corriente del emisor, I
B
es la corriente de base e I
C
es la corriente de
colector.
La frmula para calcular la corriente de base del transistor es la siguiente.

Dnde:
B2 es el voltaje de la batera de 12V, V
D
es la cada de voltaje en el diodo
que es 0,7 para diodos de silicio ideales (aunque en la hoja tcnica del diodo
1N4004 ese valor flucta entre 0,6 y 1,1) y V
BE
es el voltaje de ruptura del
transistor (0,7 para transistores de silicio). En este caso se trata de un
transistor 2N3904 cuyo voltaje de saturacin es de 0,65 0,7V.

La corriente de colector se calcula de la siguiente manera.

99

El coeficiente es la ganancia propia del transistor; para el transistor
2N3904 es en condiciones regulares un valor promedio (I
C
= 10mA, V
CE
=
1.0V) de 100.

Remplazando los valores de I
B
e I
C
en la ecuacin de Kirchhoff se tiene.

Ahora se calcula el voltaje en la resistencia del emisor, que es de donde se
toma el voltaje para enviarlo al microcontrolador.

El voltaje aplicado al microcontrolador ser 4,52V.
El circuito de adquisicin de la seal del sensor, tomando en cuenta el
diseo realizado, se muestra en la figura 43.

100

Figura 43. Circuito de adquisicin de datos

4.1.2. CIRCUITO DE COMUNICACIN
Este circuito como su nombre lo indica establece una comunicacin serial
entre el microcontrolador (PIC16f628a) y el mdem GSM. Existen
diferentes mtodos para establecer comunicacin serial usando un
microcontrolador, sin embargo, como se utilizar la norma RS-232 (esto
debido a que el puerto de comunicacin del mdem es un puerto serial tipo
DB9), es necesario implementar un circuito integrado MAX232 que sirve
para cambiar los niveles de voltaje TTL (0V a +5V) del PIC a niveles de
voltaje de la norma RS-232 (+10V a -10V). El MAX232 posee dos juegos de
transmisores y receptores, de los cuales solo es necesario ocupar uno. El
circuito electrnico de la parte de comunicacin serial es un circuito
normalizado, configurado para funcionar en condiciones regulares, para lo
cual requiere de cuatro capacitores electrolticos conectados como se
muestra en la figura 44.

RA7/OSC1/CLKIN
16
RB0/INT
6
RB1/RX/DT
7
RB2/TX/CK
8
RB3/CCP1
9
RB4
10
RB5
11
RB6/T1OSO/T1CKI
12
RB7/T1OSI
13
RA0/AN0
17
RA1/AN1
18
RA2/AN2/VREF
1
RA3/AN3/CMP1
2
RA4/T0CKI/CMP2
3
RA6/OSC2/CLKOUT
15
RA5/MCLR
4
U1
PIC16F628A
Q1
2N3904
1
2
3
J3
TBLOCK-I3
D5
1N4004
R2
10k
R6
10k
1
2
V
101

Figura 44. Circuito de comunicacin serial
Fuente: (Reyes C. 2008)

Los pines del puerto USART utilizados por el PIC16f628a para recibir y
enviar informacin son los terminales RB1 (pin 7) y RB2 (pin 8)
respectivamente. Adems para poder trabajar a las altas velocidades de
transmisin de datos seriales se debe implementar un oscilador de cristal
externo de 20MHz, ya que el oscilador RC interno no provee la suficiente
velocidad de operacin.

RA7/OSC1/CLKIN
16
RB0/INT
6
RB1/RX/DT
7
RB2/TX/CK
8
RB3/CCP1
9
RB4
10
RB5
11
RB6/T1OSO/T1CKI
12
RB7/T1OSI
13
RA0/AN0
17
RA1/AN1
18
RA2/AN2/VREF
1
RA3/AN3/CMP1
2
RA4/T0CKI/CMP2
3
RA6/OSC2/CLKOUT
15
RA5/MCLR
4
U1
PIC16F628A
X1
CRYSTAL
C1
22p
C2
22p
T1IN
11
R1OUT
12
T2IN
10
R2OUT
9
T1OUT
14
R1IN
13
T2OUT
7
R2IN
8
C2+
4
C2-
5
C1+
1
C1-
3
VS+
2
VS-
6
U2
MAX232
C3
10u
C4
10u
C5
10u
C6
10u
1
6
2
7
3
8
4
9
5
J1
CONN-D9M
102

4.1.3. CIRCUITO DE SALIDA
El circuito de salida entrega la tensin de alimentacin necesaria para
accionar un rel que abre o cierra sus contactos para permitir la circulacin o
no circulacin de corriente a travs del bobinado primario de la bobina de
encendido del vehculo. La tensin de alimentacin de la bobina de
encendido es la misma tensin entregada por la batera del vehculo, es
decir 12V, y la resistencia presentada en los terminales del bobinado
primario suele fluctuar entre 0,9 y 4,2 dependiendo del modelo de bobina
(Catalogo de bobinas de encendido BOSCH), por lo que para efectos de
clculo se tomar el menor valor, es decir 0,9, ya que esto da como
resultado la corriente mxima que deben soportar los contactos del rel.

Esto quiere decir que el valor mnimo de corriente que los contactos del rel
deberan soportar es de 13A, sin embargo los rels que normalmente se
consigue en el mercado van desde los 30A hasta los 40A, ejemplo de ello es
el rel para uso automotriz referencia CB1a-M-12V de la marca Nais cuya
corriente mxima es de 40A (hoja tcnica del relay CB1a-M-12V)
El circuito de salida del rel se puede apreciar en la figura 45.

103

Figura 45. Circuito de salida del rel

El diodo D1 que se conecta en paralelo a la bobina del rel funciona como
proteccin al circuito de las corrientes de rebote generadas por el campo
magntico de la bobina.

4.1.4. DISEO DEL PBC DEL CIRCUITO ELECTRNICO
Para realizar el diseo del circuito impreso o PBC (Printed Board Circuit), se
utiliz la herramienta Proteus de Labcenter Electronics partiendo del
diagrama esquemtico de todos los circuitos diseados en los puntos
anteriores. El diagrama esquemtico completo se muestra en anexo 1, el
cual ha sido diseado en el programa ISIS, para ser simulado y luego
transferido al programa ARES, que es una herramienta para el diseo del
PBC. Hay que tomar en cuenta que el tamao del circuito impreso no debe
ser demasiado grande, ya que esto hace que ocupe mucho espacio; ni
demasiado pequeo, porque esto puedo causar conflictos en el diseo y
crear problemas al generar pistas de cobre muy unidas o muy delgadas.
Otro aspecto a tomar en consideracin, es que se debe evitar en lo posible
la creacin de puentes en el circuito impreso, ya que no es un procedimiento
tcnicamente correcto. El diseo del PBC se observa en el anexo 2.
RA7/OSC1/CLKIN
16
RB0/INT
6
RB1/RX/DT
7
RB2/TX/CK
8
RB3/CCP1
9
RB4
10
RB5
11
RB6/T1OSO/T1CKI
12
RB7/T1OSI
13
RA0/AN0
17
RA1/AN1
18
RA2/AN2/VREF
1
RA3/AN3/CMP1
2
RA4/T0CKI/CMP2
3
RA6/OSC2/CLKOUT
15
RA5/MCLR
4
U1
PIC16F628A
R1
4k7
RL1
G2R-1E-DC5
Q1
2N3904
D1
1N4004
104

ELECTRNICO
Se puede definir al componente de control como todo recurso de
programacin utilizado para controlar el sistema de acuerdo a los
requerimientos planteados bajo ciertos estndares de operacin.
Anteriormente se mencion que en este proyecto existen bsicamente dos
componentes de control, uno de ellos es el conjunto de instrucciones
programado en el PIC16f628a que controla todo el circuito electrnico del
sistema; el otro componente de control se encuentra embebido en una
aplicacin desarrollada para dispositivos mviles Android, y es el que se
encarga de definir el comportamiento de la misma, haciendo posible la
comunicacin entre el circuito electrnico y el dispositivo mvil, y procesando
a su vez dicha informacin.

4.2.1. DISEO DEL PROGRAMA PARA EL PIC16f628a
El programa para el PIC16f628a es el conjunto de instrucciones lgicas
escritas en la memoria ROM del microcontrolador utilizando el software
MicroCode Studio de Mecanique como herramienta de desarrollo,
PICBASIC PRO como compilador, y PicKit 2 como programador. En el
programa se define el proceso secuencial necesario para la correcta
interaccin del PIC con sus dispositivos y perifricos de entrada/salida.
En el anexo 3 se muestra el diagrama de procesos correspondiente al
programa que ha sido escrito en el microcontrolador para su funcionamiento,
en l se pueden apreciar cada uno de los estados del sistema y el uso de las
variables internas para almacenamiento temporal de mensajes.
105

En la figura 36 Diagrama de bloques del sistema del captulo anterior, se
observa que el microcontrolador debe estar en capacidad de adquirir la
informacin proveniente del circuito del sensor y del modem GSM,
procesarla y enviarla al circuito de salida del rel y al modem.
Tal vez la parte ms relevante del circuito se encuentra en el sistema de
comunicacin entre el microcontrolador y el mdem, es por eso que a
continuacin se describe en detalle algunas de las instrucciones ms
importantes del programa relativas a dicha comunicacin, y su lgica de
funcionamiento.

o Comunicacin asncrona
Para establecer la comunicacin asncrona entre el microcontrolador y el
mdem se usar el puerto USART del PIC16f628a, el cual establece un
medio por donde se va a transmitir y enviar la informacin; debido a esto no
es necesario definir los pines que se utilizarn para la comunicacin puesto
que ya vienen definidos. Sin embargo se debe configurar el puerto para que
trabaje a la misma velocidad que la del modem. Las instrucciones que
permiten configurar el puerto USART son las siguientes:
DEFINE HSER_RCSTA 90h: Habilita la recepcin de datos
DEFINE HSER_TXSTA 24h: Habilita el registro de transmisin
DEFINE HSER_BAUD 115200: Define la tasa de transferencia en 115200
baudios (es la misma tasa de transferencia del modem)
DEFINE HSER_CLROERR 1: Limpia el sobre flujo de datos
automticamente.

Una vez definida la configuracin del puerto USART en el PIC16f628a se
puede utilizar las declaraciones de envo y recepcin de datos para
comunicacin serial que son HSERIN y HSEROUT. Estas instrucciones se
explicarn analizando el siguiente extracto del programa lnea por lnea.
106

1) inicio:
2) HSERIN 200,inicio,[WAIT("+CMT:"),skip 42,STR
modem\3]
3) HSEROUT["AT+CMGD=1",13]
4) IF modem[0]=cod2[0] THEN
5) GOTO apagar
6) ENDIF

Descripcin del programa lnea por lnea:
1. El subprograma etiquetado como inicio comienza su rutina.
2. La instruccin HSERIN hace que el microcontrolador se encuentre en
espera de algn dato serial (proveniente de un SMS entrante en el
mdem), para ello espera un tiempo de 200 ms, si durante ese tiempo
no recibe ningn dato el programa se dirige hacia el lugar etiquetado
como inicio, es decir regresa a la lnea anterior y se repite el
proceso. Si en el tiempo de espera el microcontrolador recibi algn
dato, lo lee y lo almacena en una variable tipo String denominada
modem, luego pasa a la siguiente lnea de cdigo. El comando
WAIT se utiliza para esperar una porcin especfica en la cadena de
caracteres omitiendo todos los caracteres anteriores a los
especificados. El comando skip sirve para saltarse u omitir una
determinada cantidad de caracteres antes de leer los caracteres que
proporcionan la informacin necesaria para el funcionamiento del
programa.
3. La instruccin HSEROUT enva una cadena de datos (caracteres) de
forma serial. En este caso la cadena enviada es AT+GMGD=1, que
es un comando AT utilizado para borrar un mensaje de texto
almacenado en la primera posicin; esto se hace para evitar que se
llene el buzn de entrada del modem. Los comandos AT utilizados en
el programa sern detallados ms adelante.
4. El programa compara el texto o String almacenado en la variable
modem con un String guardado en una variable interna denominada
107

cod2; si son iguales el programa realiza la instruccin de la lnea 5,
caso contrario se salta ese paso y contina con la lnea 6 que cierra la
instruccin IF.

o Comandos AT
Los comandos AT que se utiliza en el programa permiten configurar el
modem al iniciar el programa, y poder enviar y recibir informacin til entre el
microcontrolador y el mdem GSM. Los comandos AT utilizados son los
siguientes:

Comandos de configuracin del mdem
AT+CMGF=1: Configura los SMSs del mdem en modo texto. Permite leer
los mensajes de texto mediante tus caracteres reales, si no estuviera
configurado de esa manera el microcontrolador recibira informacin que no
podra ser interpretada.
AT+IFC=0,0: Configura la comunicacin con el mdem en modo asncrono.
Aunque ya viene definido de ese modo el programa se asegura de que as
sea.
AT+CNMI=2,2,0,0,0: Configura el modo de lectura y almacenaje de los
mensajes de texto entrantes. Es importante definir este paso, ya que de otro
modo el formato de presentacin de los mensajes ser diferente y habrn
conflictos en la lectura de los mismos.

Comandos de operaciones con SMS
+CMT: Esta es una porcin de la cadena de caracteres que es enviada
desde el mdem hacia el microcontrolador cuando llega un SMS. Es un
indicador de recepcin de un mensaje de texto nuevo.
108

AT+CMGD=1: Este comando borra un SMS ubicado en una posicin de la
memoria del mdem. En este caso se borra el SMS de la primera posicin.
AT+CMGS=xxx: Este comando es usado para generar un mensaje de
texto desde el mdem para luego enviarlo.
AT+CMGL=: Este comando se utiliza para solicitar al mdem que
presente en una lista los mensajes requeridos que estn almacenados en la
memoria del mdem.

Otros comandos AT
+CFUN: 1: Se emplea este comando para avisar al microcontrolador que el
mdem est encendido y con todas sus funciones activadas. Permite al
programa saber cundo debe iniciar con su rutina, ya que si el programa
arranca sin este aviso, es posible que el mdem no reciba las instrucciones
de configuracin.
ATD0XXXXXXXXX: Realizar una llamada telefnica desde el mdem.
AT+CHUP: Colgar una llamada telefnica en curso.

4.2.2. SIMULACIN DEL PROGRAMA DEL PIC16f628a
Para realizar la simulacin del programa desarrollado para el PIC16f628a es
necesario realizarlo en conjunto con el circuito electrnico diseado en el
apartado anterior. A continuacin se presentar el proceso y los resultados
de la simulacin en el programa Proteus, desde la herramienta ISIS. Para
ello se ha acondicionado ciertas partes del circuito para representar los
sistemas fsicos que intervienen en el funcionamiento del sistema en
conjunto, como por ejemplo la seal del sensor de impacto ser
representada mediante un pulsador; adems ya que no se dispone de un
mdem en el simulador, se usar un terminal virtual provisto por el
simulador, donde se podr observar todos los cdigos enviados desde el
circuito hacia el modem y viceversa.
109

El circuito para la simulacin es el siguiente:

Figura 46. Diagrama para la simulacin del circuito electrnico

Es importante que el microcontrolador sea cargado con el archivo
hexadecimal que contiene el programa desarrollado para el PIC16f628a.
Simulacin en proceso
Para realizar la simulacin del componente electrnico junto al de control, se
proceder a explicarlo en varios pasos, cada uno de ellos relacionado al
estado de la alarma.

Paso1:
Una vez iniciada la simulacin se cargan las variables definidas en el
programa, y el microcontrolador est en espera del codigo AT que le indica
110

que el mdem est en lnea y con la totalidad de sus funciones. Ese cdigo
es el siguiente:
+CFUN: 1
El mismo que es ingresado en el terminal virtual de la siguiente manera:

Figura 47. Terminal virtual (imagen1)

Una vez que ese cdigo es recibido, el microcontrolador enva varas lneas
de cdigos de respuesta que permiten configurar el mdem y borrar los
mensajes que estn almacenados en la memoria interna del mdem o en su
tarjeta SIM, tal como se muestra en la figura 48.

Figura 48. Terminal virtual (imagen 2)

111

Paso 2:
Siguiendo con el proceso, el microcontrolador se encuentra en espera del
cdigo que encienda la alarma, el cual viene escrito dentro de un mensaje
de texto enviado desde el dispositivo al mdem. Cuando el mdem recibe un
mensaje entrante, ste mensaje incluye, adems del texto, informacin
referente a su remitente, fecha y hora de envo, etc. La siguiente lnea
muestra la cadena de caracteres completa que el mdem enva al
microcontrolador cuando recibe un SMS:
+CMT: "+593992380846",,"12/10/18,16:55:01-20"??+01
El texto del mensaje solo corresponde a los tres ltmos caracteres de la
cadena, es decir, +01, que es el cdigo de activacin para encender la
alarma; el resto de caracteres son desechados a excepcin del nmero de
remitente.
Como respuesta el microcontrolador enva un cdigo para borrar el mensaje
entrante (figura 61) y asi mantener el buzn de entrada vaco para nuevos
SMS entrantes, adems de enviar un estado lgico alto (HIGH) a una de sus
salidas para encender el led que indica el estado encendido de la alarma
(figura 49).
112

Figura 49. Resultados simulacion (imagen1)

Paso 3:
En este punto, la alarma est encendida y el microcontrolador se encuentra
en espera de un cdigo para apagarla o que el sensor enve una seal de
alerta; para ello se abre el pulsador (que representa la seal del sensor) que
hasta este momento ha permanecido cerrado. Una vez abierto el pulsador el
circuito de adquisicin de datos enviar una seal al microcontrolador que se
interpretar como una posible alerta de robo (figura 50).

113

Figura 50. Resultados simulacin (imagen 2)

Como se observa en el diagrama anterior, el pulsador se encuentra abierto
enviando una seal de estado lgico alto al PIC16f628a, el cual lo interpreta
como una seal de alerta y activa su salida para encender el diodo LED de
alerta (LED amarillo). Adems se enva un SMS a traves del mdem hacia el
dispositivo mvil con un texto de alerta.
Cuando la alarma se encuentra en estado de alerta, est en espera de un
mensaje que apague la alarma en caso de haber sido una falsa alarma, o un
cdigo de activacin para que el microcontrolador realice el bloqueo del
vehculo. Ese cdigo es el siguiente: +07. La cadena entera de caracteres
es como se muestra:
+CMT: +593992380846,,12/10/18,16:55:01-20??+07

114


En respuesta al cdigo de bloqueo recibido por el microcontrolador, ste
envia un comando AT para borrar el SMS entrante del modem, y activa la
salida de bloqueo, la cual enciende el diodo LED rojo y excita al rel para
que este conmute sus contactos (figura 51).

Paso 5:
Con la alarma en estado de bloqueo, el microcontrolador solo est a la
espera de un cdigo de activacin para realizar el desbloqueo. Dicho cdigo
es: +08, que conjuntamente con la cadena de caracteres completa es
como se muestra a continuacin:
+CMT: "+593992380846",,"12/10/18,16:55:01-20"??+08
115


Como resultado el microcontrolador envia el respectivo cdigo AT para el
borrado del SMS entrante y la alarma vuelve a su estado de encendido,
donde solo se encuentra activada la salida del diodo LED de encendido
(LED verde) (figura 52).

Paso 6:
Como ltimo paso de la simulacin se enviar un cdigo para apagar el
sistema de seguridad. Este cdigo es +02. La cadena total de caracteres
es:
+CMT: "+593992380846",,"12/10/18,16:55:01-20"??+02

116

En consecuencia el microcontrolador devuelve el cdigo AT para el borrado
del SMS y la alarma vuele a su estado inicial, es decir al estado de
apagado (figura 53).


Una vez realizado todo el proceso de simulacin en el software PROTEUS,
el componente electrnico junto al componente de control (solamente el
programa para el PIC16f628a), pueden ser puestos a prueba nuevamente ya
que el programa del microcontrolador es cclico, es decir que una vez
terminado el proceso vuelve a su punto de inicio para comenzar un nuevo
ciclo de proceso.

117

4.2.3. DISEO DE LA APLICACIN MVIL
La aplicacin mvil trabaja juntamente con el sistema instalado en el
vehculo, por lo tanto ambos deben mantener una relacin estable sobre el
estado en que se encuentra el sistema en conjunto. El funcionamiento de la
aplicacin es simple en su concepto, pero requiere de una lgica bien
definida para evitar que la aplicacin entre en conflicto con la parte
electrnica del sistema. Adems por tratarse de una aplicacin no se puede
hablar de un programa secuencial, ya que pueden presentarse varios
eventos al mismo tiempo y el sistema puede cambiar de estado en una
forma no secuencial.
Una vez que se ha abierto la aplicacin, se inicia una actividad o activity (se
abre una pantalla) en la que espera que se ingrese una contrasea de
acceso, en caso de ser incorrecta aparecer un mensaje de error; si la
contrasea es correcta se cerrar la actividad actual y se abrir una nueva
actividad.
La siguiente pantalla o actividad muestra en primer plano la informacin
referente al usuario y su vehculo, incluyendo una imagen del automvil. Ms
abajo en la pantalla se muestra un conjunto de botones y etiquetas que
indican al usuario el estado del sistema que inicialmente se encontrar
apagado. Al presionar o hacer click en el botn de encendido las etiquetas
indicarn al usuario el estado de alarma encendida y se enviar un SMS
con el cdigo de activacin al mdem, y si se presiona el botn de apagar el
estado de las etiquetas cambiar a apagado. Sin embargo, cuando la
alarma est encendida, se puede salir de la aplicacin dejndola en segundo
plano, a fin de aprovechar otras funcionalidades del telfono mientras el
sistema est activado; esto no borrar el estado del sistema, que se guarda
antes de salir y se carga siempre que se vuelve a abrir la aplicacin. Si el
sistema electrnico detecta una alerta de robo, enva un mensaje al mvil
que es interpretado por la aplicacin y cambia su estado a alerta.
Siguiendo con el proceso, el usuario puede, a travs de la aplicacin decidir
si desea bloquear el vehculo o no; si lo hace, el sistema cambia las
118

etiquetas indicando el estado bloqueado y se prepara para ser desactivado
cuando el usuario lo decida. Todas las rdenes se envan desde la
aplicacin hacia el mdem mediante SMSs, por lo que el usuario debe
disponer de un paquete de mensajes para asegurar siempre la conexin.
Cabe mencionar que los SMS salientes no son administrados a travs de la
aplicacin de mensajes del mvil, lo que hace que el usuario no pueda
visualizarlos, sin embargo, si puede visualizar los SMS entrantes.
Una caracterstica adicional de la aplicacin, es que cuenta con un botn de
verificacin, el cual permite desde cualquier estado del sistema, enviar un
mensaje al mdem con la instruccin de devolver un mensaje con
informacin del estado real del sistema electrnico en el vehculo.
La aplicacin cuenta adems con un botn de cierre Salir, que cierra
totalmente la aplicacin, y apaga el sistema, si es que no se encuentra
apagado, excepto en el estado bloqueado.
En los anexos 4 y 5 se muestran los diagramas de procesos de los
principales procesos de la aplicacin mvil.

La aplicacin mvil para dispositivos mviles Android se desarroll sobre la
plataforma de desarrollo AppInventor, desde sus sitio web
http://appinventor.mit.edu/. Para acceder a los recursos de este sitio web
para programadores de aplicaciones mviles se debe poseer una cuenta de
Google. Una vez que se ingresa y se haya instalado todo el software
necesario se procede al desarrollo de la aplicacin que consiste en 2 partes
bsicamente:
- Diseo de la interfaz grfica de usuario. Esto se hace a travs del
AppInventor Designer.
- Desarrollo del programa. Se realiza mediante el AppInventor Blocks
Editor.

119

4.2.3.1. Diseo de la interfaz grfica
La interfaz grfica es el conjunto de imgenes y objetos grficos que son
presentados en la pantalla del dispositivo mvil, mediante la cual el usuario
interacta con la aplicacin en curso. En ella se incluyen todos los elementos
que permiten al usuario recibir informacin o ejecutar acciones, como hacer
click en un botn, arrastrar una imagen, visualizar una etiqueta, etc.
Adems una aplicacin puede contener una o varias pantallas que en
lenguaje de programacin de Android se conocen como Activities
(Actividades). Cada una de estas pantallas se debe disear por separado, y
el comportamiento de cada una tambin debe ser programado por separado.
La aplicacin de este proyecto posee por lo pronto dos pantallas o
actividades, una de ellas es la de inicio y la otra la de control. En la pantalla
de inicio se muestra un cuadro para ingresar una contrasea con la que se
accede a la siguiente pantalla; pero si la contrasea es incorrecta la
aplicacin muestra un mensaje de error. Por otra parte la pantalla de control
ofrece algunos elementos de donde el usuario puede operar el sistema de
seguridad de su vehculo, tales como botn de encendido y apagado de la
alarma, botn de bloqueo y desbloqueo del vehculo, etiquetas de
informacin del usuario, etc.
El diseo de las pantallas de la aplicacin mvil de este proyecto son las
ilustradas en las figuras 54 y 55;

120

Figura 54. Diseo del Screen1 de la aplicacin mvil

Figura 55. Diseo del Screen2 de la aplicacin mvil
121

La lista de todos los componentes utilizados en cada una de las pantallas es
la siguiente:
Tabla 12. Componentes de Screen1 (pantalla1)
Nombre de
Componente
Tipo de
Componente
Palette Propsito
Vertical
Arrangement(s)
Vertical-
Arrangement
Screen
Arrangemen
t
Ubican ordenadamente los
componentes en forma vertical
Horizontal
Arrangement(s)
Horizontal-
Arrangement
Screen
Arrangemen
t
Ubican ordenadamente los
componentes en forma horizontal
PasswordLabel Label Basic Muestra el texto: Ingrese la
contrasea
Password1 PasswordTextBo
x
Basic Aqu el usuario ingresa la
contrasea de acceso
EnterButton Button Basic Presenta la contrasea para que
sea
Validada
HelpButton Button Basic Enva al usuario a un sitio de
ayuda y soporte
ErrrorMessage-
Label
Label Basic Muestra un mensaje de error
cuando la contrasea es
incorrecta
Info1Label Label Basic Muestra informacin de contacto
122

Tabla 13. Componentes de Screen2 (pantalla2)
Nombre de
Componente
Tipo de
Componente
Palette Propsito
Vertical
Arrangement(s)
Vertical-
Arrangement
Screen
Arrangemen
t
Ubicar ordenadamente los
componentes en forma vertical
Horizontal
Arrangement(s)
Horizontal-
Arrangement
Screen
Arrangemen
t
Ubicar ordenadamente los
componentes en forma horizontal
Especificacion-
Label
Label Basic Etiqueta de ttulo:
ESPECIFICACIONES DE USUARIO
UsuarioLabel Label Basic Etiqueta de nombre de usuario
ModeloLabel Label Basic Etiqueta de modelo de vehculo
MarcaLabel Label Basic Etiqueta de marca de vehculo
MatriculaLabel Label Basic Etiqueta de matrcula de vehculo
CambiarButton Button Basic Botn para cambiar de vehculo de
usuario (en caso de tener mas de
un vehculo)
CarroImagen Image Basic Imagen del vehculo
ControlSSV-Label Label Basic Etiqueta de ttulo: CONTROL SSV
EstadoAlarmaLab
el
Label Basic Etiqueta con texto: Estado Alarma
VerificarButton Button Basic Botn de verificacin de estado de
la alarma
AlarmaLabel Label Basic Etiqueta que muestra el estado de
la alarma (Encendida/Apagada)
123

AlarmaButton Button Basic Botn para encender/apagar la
alarma
EstadoVehiculoL
abel
Label Basic Etiqueta con texto: Estado
Vehculo
VehiculoLabel Label Basic Etiqueta que muestra el estado
del vehculo
(Desconocido/Protegido/Alerta/Bl
oqueado)
BloquearButton Button Basic Botn para el
bloqueo/desbloqueo del vehculo
HistorialButton Button Basic Botn para acceder al historial de
uso de la alarma
SalirButton Button Basic Botn para salir de la aplicacin
EnviarMensaje Texting Social Enva SMS's al mdem
Mensaje-
Recibido
Texting Social Recibe SMS del mdem
AlertaSound Sound Media Sonido de alerta cuando es
recibido SMS de alerta
ClickSound Sound Media Sonido de click al presionar un
botn
TinyDB1 TinyDB Basic Guarda de forma persistente la
variable del estado de la alarma
Notifier1 Notifier Other Stuff Notificaciones varias
Clock1 Clock Basic Temporizador para retraso de SMS

124

Adems de ubicar los componentes en sus respectivas posiciones y
ordenarlas con los componentes VerticalArrangement y
HorizontalArrangement se debe especificar las propiedades de cada uno de
ellos, como su texto, color de texto, color de fondo (background), hint,
tamao, etc.

4.2.3.2. Desarrollo del programa de la aplicacin
Hasta ahora ha sido diseada la interfaz grfica donde el usuario interacta
con la aplicacin mvil, sin embargo ninguno de los elementos grficos
posee utilidad alguna sino se definen para ellos los comportamientos de los
elementos y las acciones o procedimientos que se deben ejecutar al
interactuar con ellos. Para ello se desarrolla el programa desde un IDE
denominado AppInventor Blocks Editor (Editor de bloques del AppInventor).
A continuacin se describen las partes esenciales del programa. Hay que
tomar en cuenta que cada bloque es una forma grfica de una instruccin de
programacin muy similar al lenguaje C o java.

o Bloques de definicin
Estos bloques permiten crear variables que se utilizan para almacenar datos,
o procedimientos sern utilizados en diferentes partes del programa. Estas
variables pueden ser: texto, nmeros, listas, datos o incluso procedimiento.
En este proyecto se utilizan para almacenar por ejemplo: el nmero de
telfono del mdem, nombre de usuario, estado de la alarma, etc.

125

Figura 56. Bloques de definicin

En la figura 56 se observa algunos ejemplos de los bloques de definicin
utilizados en el programa de este proyecto. All se ve la utilizacin de
variables como GlobalIndex que hace referencia a un nmero que identifica
a un usuario especfico y todas sus caractersticas dentro del programa. Otra
variable, es la utilizada en el bloque de definicin de proceso
EncenderAlarma, la cual nombra un proceso encargado de encender la
alarma del vehculo mediante un SMS.

o Bloques de texto
Los bloques de texto son simplemente cadenas de caracteres que son
usadas por otros bloques para leer, escribir, comparar, editar, etc., la
informacin en forma de texto, aqu se puede escribir la informacin que se
quiere enviar en un mensaje de texto, un ejemplo se muestra en la figura 57.

Figura 57. Bloques de texto

126

o Bloques de listas
Los bloques de listas son espacios de memoria e instrucciones utilizadas
para manipular informacin en forma de listas o vectores. Son tiles para
almacenar la informacin detallada de varios usuarios relacionada entre s
por un nmero de ndice especfico de cada usuario, tales como su nombre
de usuario, su contrasea, su modelo, marca y matrcula del vehculo.

Figura 58. Bloques de lista

o Bloques de control
Los bloques de control son estructuras bsicas que permiten realizar ciertas
operaciones con otros datos como comparaciones, evaluaciones,
repeticiones, etc. Las ms conocidas son las estructuras IF-ELSE, FOR-
EACH, FOR-RANGE, WHILE, y algunas operaciones con pantallas.
127

Figura 59. Bloques de control

o Bloques de los componentes del AppInventor Designer
Cuando se incluye un componente nuevo en el diseo de la pantalla, ya sea
un componente visible, no visible, multimedia o cualquier clase de
componente, se crean automticamente una lista de bloques caractersticos
de dicho componente y que permite realizar acciones respecto a ese
componente dependiendo de la entrada que se proporcione. Por ejemplo, si
se agrega un botn nuevo, este contiene bloques que permiten cambiar su
color, forma, texto, habilitacin, o sino realizar algn procedimiento cuando
se haga click sobre el mismo.
Los bloques de componentes ms relevantes usados en el programa son los
siguientes:

When Button.Click do
Este es un bloque de respuesta que realiza una accin cuando se haya
hecho click sobre un botn; dicha accin est definida por el conjunto de
instrucciones escritas dentro del bloque. Se define como click la accin de
presionar y soltar rpidamente una determinada rea de la pantalla (touch),
128

sin realizar ningn arrastre. En este programa se utilizarn varios botones
con diferentes funciones, por lo que cada botn debe tener su conjunto de
instrucciones, por ejemplo, el botn de encendido y apagado de la alarma.
Un ejemplo de ste bloque se representa en la figura 60.

Figura 60. Bloque When Button.Click do

When Texting.MessageReceived do
En la figura 61 se muestra un ejemplo del bloque When
Texting.MessageReceived do. Este bloque permite programar una accin
cuando un mensaje de texto especfico sea recibido por el dispositivo mvil.
El mensaje debe corresponder a un nmero de mvil de remitente y texto
129

determinado para que las acciones programadas dentro del bloque sean
llevadas a cabo. Cuando un mensaje proveniente del nmero del mdem es
recibido con el texto Alerta de Robo, la aplicacin lo detecta y muestra una
seal de alerta. Si el mensaje recibido muestra un texto diferente a los
especificados, o provienen de otro remitente la aplicacin no realiza ninguna
accin.

Figura 61. Bloque When Texting.MessageReceived do

When Screen.Initialize do
Cuando una aplicacin se ejecuta, se muestra una pantalla o Activity, y
dentro de la misma aplicacin el usuario puede pasar de una Activity a otra.
El bloque When Screenx.Initialize do (figura 61) realiza una accin cuando
una nueva pantalla o Activity se inicia. Esto es til ya que ayuda al programa
a cargar las variables sobre el estado actual de la alarma cada vez que el
usuario abre la aplicacin.
130

Figura 62. Bloque When Screen.Initialize do

Call Notifier.ShowAlert
Este bloque es una llamada a un proceso que muestra en pantalla una
notificacin durante un par de segundos y luego se desvanece, sirve para
hacer conocer al usuario que la aplicacin ha detectado un evento de
importancia, como la deteccin de una alerta de robo. Un ejemplo de este
bloque se observa en la figura 63.

Figura 63. Bloque Call Notifier.ShowAlert
131

Call Notifier.ShowChooseDialog & When Notifier.AfterChoosing do
El bloque Call Notifier.ShowChooseDialog muestra un cuadro de texto con
una notificacin y dos o ms botones para elegir elegir haciendo click. La
accin que se lleve a cabo al presionar cualquiera de los botones del cuadro
de dilogo es definida en el bloque When Notifier.AfterChoosing do. En este
proyecto se utiliza estos bloques para preguntar al usuario si est seguro de
abandonar la aplicacin al presionar el botn Salir; si el usuario acepta
presionando el botn si se cierra la aplicacin borrando todas las variables,
pero si presiona el botn no la aplicacin permanece abierta.

Figura 64. Call Notifier.ShowChooseDialog & When Notifier.AfterChoosing
do

Call Notifier.ShowTextDialog & When Notifier.AfterTextInput
Este par de bloques es similar a los explicados anteriormente. Cuando se
llama al bloque Call Notifier.ShowTextDialog se muestra en pantalla un
cuadro de dialogo con una notificacin, una casilla para ingresar un texto y
dos botones (Aceptar y Cancelar). En la casilla de texto se debe ingresar un
132

texto especfico, que luego de hacer click en el botn Aceptar es
comparado con una cadena de caracteres definidos en el bloque When
Notifier.AfterTextInput do, si ambos textos coinciden se llevan a cabo las
acciones establecidas dentro de este bloque. Esto permite crear una
notificacin a fin de que el usuario ingrese una clave para realizar el
bloqueo/desbloqueo del vehculo, y en caso de ser incorrecta no se
ejecutar ninguna accin.

Figura 65. Bloques Call Notifier.ShowTextDialog & When
Notifier.AfterTextInput do

Call TinyDB.StoreValue
Este bloque es de mucha importancia, ya que se usa para guardar de forma
persistente un dato dentro de una variable como si se tratara de una
pequea base de datos. Luego, esa informacin guardada puede ser
recuperada con el bloque Call TinyDB.GetValue. Esto es muy til ya que
slo as es posible guardar la informacin referente al estado de la alarma
133

como una etiqueta, inclusive despus de haber pasado la aplicacin a un
segundo plano. La informacin guardada permanece de forma persistente en
la memoria ROM del dispositivo mvil aun si ste es apagado y encendido
nuevamente.

Figura 66. Bloque Call TinyDB.StoreValue

El diagrama de bloques completo del programa para la aplicacin mvil se
encuentra en los anexos 7 y 8. All se puede ver la extensin total del
programa y la utilizacin de todos los bloques descritos anteriormente.

4.2.4. SIMULACIN DE LA APLICACIN MVIL
La simulacin de la aplicacin para dispositivos mviles con sistema
operativo Android se realiza desde el Editor de Bloques del AppInventor;
desde all se abre un emulador de telfonos Android. La simulacin se
realiza en varios pasos como sigue:

Paso1:
Se abre la aplicacin desde el men de aplicaciones. Una vez abierto
aparece la siguiente grfica en pantalla:
134

Figura 67. Simulacin aplicacin mvil (imagen 1)

En la pantalla inicial de la aplicacin se puede observar un etiqueta de
instruccin, una casilla de contrasea, un botn (Entrar) para ingresar a la
plataforma de control, un botn de ayuda. Y varias etiquetas de con
informacin de contacto. En la casilla de contrasea el usuario debe ingresar
una clave de 4 dgitos, si la contrasea es incorrecta, aparecer un mensaje
de error, en cambio, si la contrasea ingresada es correcta, se puede
observar un mensaje que expresa la autenticidad de la contrasea (figura
68).

135

Figura 68. Simulacin aplicacin mvil (imagen 2 y 3)

Paso 2:
Una vez autentificada la contrasea, la aplicacin cierra la actividad actual y
abre la siguiente actividad, que corresponde a la plataforma de control del
sistema de seguridad, como se observa en la figura 69.


En la figura anterior se observa los componentes que sirven para el control
del sistema de seguridad. Uno de los botones principal es el de ENCENDER,
136

si se presiona dicho botn la alarma cambiara su estado a ALARMA
ENCENDIDA, consecuentemente un mensaje es enviado con el cdigo de
activacin al mdem para encender la alarma en el vehculo. Las etiquetas
de la plataforma cambian para indicar que la alarma se ha encendido (figura
70).


Paso 3:
Con el sistema en estado encendido, la aplicacin est en espera de una
orden para apagar la alarma, salir de la aplicacin, o en espera de un
mensaje entrante que pueda ser interpretado por la aplicacin como una
seal de alerta. Cuando la aplicacin recibe el mensaje de alerta las
etiquetas de la plataforma cambian al estado de ALERTA, como se muestra
en la figura 71.

137


Paso 4:
Si el sistema est en estado de ALERTA, el usuario puede tomar la decisin
de apagar la alarma, o bloquear el vehculo. En caso de bloquear el
vehculo, la aplicacin muestra una notificacin con un cuadro de dialogo,
donde el usuario debe ingresar una clave de bloqueo. Esto se puede
apreciar en la figura 72. Para realizar el bloqueo se debe presionar el botn
de BLOQUEAR.


Si la clave de bloqueo es incorrecta, la aplicacin no realiza ninguna accin.
Por otra parte, si la clave es correcta, la aplicacin muestra que se ha
enviado el mensaje con el cdigo de bloqueo al mdem y cambia sus
etiquetas para identificar el estado del vehculo bloqueado (figura 73).
138


Paso 5:
Cuando el sistema se encuentra en este punto, solo est en espera de la
orden de desbloqueo. Una vez que se el botn de desbloqueo es
presionado, la aplicacin presenta una notificacin con un cuadro de dialogo
donde el usuario ingresa una contrasea de desbloqueo. La contrasea de
desbloqueo es la misma contrasea que se utiliza para el bloqueo (figura
74).


Si la contrasea ingresada es correcta, la aplicacin enva un SMS al
mdem con el cdigo de desbloqueo y cambia sus etiquetas para indicar que
el vehculo ha sido desbloqueado, pero la alarma no ha sido apagada, esto
se puede apreciar en la figura 75.
139


Paso 6:
Como ltimo paso, se simular el apagado del sistema, lo que se obtiene
presionando el botn APAGAR. Una vez ms, la aplicacin enva un SMS
con el cdigo de activacin necesario para apagar el sistema y cambia sus
etiquetas.

140

5. RESULTADOS

141

Una vez finalizada la construccin del prototipo, este fue sometido a varias
pruebas de funcionamiento para determinar la efectividad del proyecto
planteado en este trabajo de titulacin. Las pruebas se realizaron tanto bajo
condiciones normales de funcionamiento como en escenarios poco
favorables. Como muestra se tom un valor base de 20 mensajes de texto
por cada prueba, los resultados obtenidos de cada una de las pruebas se
describen a continuacin.

o Efectividad de envo y recepcin de mensajes en condiciones
normales, desde el telfono mvil hacia el mdem.
Estas pruebas se realizaron desde diferentes puntos de la ciudad de Quito y
diferentes telfonos celulares, hacia el mdem ubicado en un punto
determinado, bajo condiciones ptimas de seal celular en sectores con
cobertura 1W (segn la compaa de telefona celular). El objetivo de esta
prueba es determinar la efectividad de activacin y desactivacin del sistema
de seguridad mediante las siguientes tareas:
- Determinar la capacidad del mdem de receptar el mensaje entrante
en condiciones normales,
- Determinar la capacidad del circuito electrnico de interpretar y
procesar la informacin compartida por el mdem.
- Determinar el tiempo promedio que tarda en llegar un mensaje
enviado desde el telfono hacia el mdem;
- Comprobar el correcto funcionamiento de la aplicacin mvil respecto
al envo de mensajes de texto.

No se pretende con esta prueba comprobar la eficiencia del servicio de envo
de SMS de la compaa de telefona celular, puesto que esa caracterstica
es inherente solo a la compaa y no est en control del sistema. Se envi
un total de 20 mensajes de texto de prueba.

142

Figura 76. Pruebas de envo de SMS desde telfono a mdem con buena
calidad de seal celular

Resultados
Se obtuvo un 100% de efectividad en el envo de mensajes de texto desde el
telfono mvil hacia el mdem; esto significa que todos los mensajes
enviados fueron recibidos por el mdem y ledos por el circuito electrnico,
con lo cual se puede afirmar que el sistema es capaz de activar y desactivar
la alarma bajo condiciones de funcionamiento normales.
Adems se tom valores de los tiempos de envo de los mensajes y se
calcul el tiempo promedio, el cual es: 4,91 segundos.

Tabla 14. Resultados de la prueba de envo y recepcin de mensajes desde
el telfono mvil hacia el mdem
Mensaje
N Texto
Tiempo de
entrega Lleg
1 +01 5,12 S
2 +02 3,37 S
3 +01 4,01 S
4 +07 4,07 S
5 +08 7,36 S
143

6 +02 6,45 S
7 +01 4,82 S
8 +03 5,01 S
9 +02 4,29 S
10 +03 3,90 S
11 +01 5,61 S
12 +07 7,13 S
13 +03 4,18 S
14 +02 4,25 S
15 +01 5,86 S
16 +08 4,92 S
17 +02 6,14 S
18 +01 3,97 S
19 +02 3,75 S
20 +03 4,05 S
Tiempo promedio: 4,91
Efectividad de envo: 100%

o Efectividad de envo y recepcin de mensajes en condiciones
normales, desde el mdem hacia el telfono.
El objetivo de esta prueba es determinar:
- La eficacia del circuito electrnico para enviar una instruccin de
envo de SMS al mdem.
- La eficacia del mdem para enviar mensajes de texto.
- La capacidad de la aplicacin mvil para interpretar un SMS entrante.
- El tiempo que tarda un mensaje de texto en llegar al dispositivo mvil.
Para esto hay que verificar que la tarjeta SIM del mdem cuente con
respectivo crdito. Las pruebas se realizaron bajo condiciones normales de
funcionamiento, es decir con niveles ptimos de seal celular en sectores de
144

cobertura 1W. Los mensajes de texto se enviaron desde el mdem a un
nmero de telfono nico.

Figura 77. Pruebas de envo de SMS desde mdem a telfono con buena
calidad de seal celular

Resultados:
Se obtuvo como resultado un 100% de efectividad en el envo y recepcin de
mensajes desde el mdem hacia el dispositivo mvil, lo que implica la
efectividad del circuito para enviar las instrucciones de envo hacia el
mdem, y la capacidad de ste para enviar mensajes de texto. Los tiempos
de llegada de los mensajes de texto fueron tomados tambin y su promedio
se calcul en: 5,13 segundos.

Tabla 15. Resultados de las pruebas de envo y recepcin de mensajes
desde el mdem hacia el telfono mvil
Mensaje N Texto Tiempo de entrega Lleg
1 Alerta de robo 4,68 S
145

4 Alarma encendida 4,29 S
5 Alarma apagada 4,17 S
10 Vehculo bloqueado 5,23 S

o Efectividad de envo y recepcin de mensajes en ausencia de
seal celular, desde el dispositivo mvil hacia el mdem.
Estas pruebas se realizaron con el mdem ubicado en un lugar cuyos
niveles de seal ofrecida por la compaa de telefona celular son muy bajos
y en ocasiones nulos. De esta manera se pretende observar el
comportamiento del sistema con el vehculo estacionado en un lugar sin
seal celular, ejemplo de ello puede ser un estacionamiento subterrneo, o
una zona rural. Se realizaron 20 pruebas de envo de mensajes en diferentes
momentos y lugares.
146

Figura 78. Pruebas de envo de SMS desde telfono a mdem en ausencia
de seal celular

Resultados:
Como resultado de estas pruebas, las cuales fueron realizadas en varias
zonas del sur de Quito donde la seal celular es deficiente (partes
subterrneas de casas) se obtuvo que el sistema no responde a las rdenes
enviadas desde el dispositivo mvil hacia el mdem en lugares donde no
existe cobertura de seal celular. Se espera que la efectividad en estas
zonas sea menor al 10%.

Tabla 16. Resultados de las pruebas de envo de mensajes desde el telfono
mvil hacia el mdem en ausencia de seal celular
Mensaje
N Texto
Tiempo de
entrega Lleg
1 +01 --:-- No
2 +01 --:-- No
3 +01 --:-- No
4 +01 --:-- No
147

5 +01 --:-- No
6 +01 7,43 Si
7 +02 --:-- No
8 +01 --:-- No
9 +02 --:-- No
10 +07 --:-- No
11 +08 --:-- No
12 +01 --:-- No
13 +01 --:-- No
14 +01 --:-- No
15 +01 --:-- No
16 +01 --:-- No
17 +02 --:-- No
18 +01 --:-- No
19 +01 --:-- No
20 +01 --:-- No

o Efectividad de respuesta del sensor de impacto
Estas pruebas se realizaron con el objetivo de comprobar la capacidad del
sistema para detectar posibles alertas de robo a travs de la deteccin de
cambios en el entorno, dichos cambios se refieren a golpes en la estructura
fsica del vehculo, o movimientos fuertes que pueden ser causados al
ingresar al vehculo o encenderlo de manera no autorizada. Estas pruebas
permiten determinar:
- La sensibilidad ptima del sensor de impacto.
- La eficacia del circuito de admisin de seal del sensor.
148

Cabe decir que la sensibilidad se ajusta por medio de un potencimetro que
dispone el mismo sensor y es necesario determinar un valor ptimo a fin de
evitar que el sistema sea demasiado sensible como para detectar falsas
alarmas provocadas por movimientos ligeros, ni sea muy poco sensible
como para dejar pasar por alto verdaderas alertas de robo. Los expertos
recomiendan ajustar la sensibilidad del sensor en un valor entre 60 y 75% de
la escala completa aproximadamente, de este modo, no resulta demasiado
sensible ni por el contrario muy poco sensible.

Resultados:
Se realizaron las pruebas pertinentes para determinar la efectividad de
respuesta del circuito del sensor y se obtuvo como resultado que:
Los primeros resultados no eran muy favorables, ya que el circuito activaba
la alerta de la alarma sin presencia de vibracin fsica, es decir que el estado
de alerta se presentaba al momento de encender la alarma debido a la
interferencia electromagntica del mdem al enviar o recibir un mensaje de
texto, lo cual era causado por la demasiada cercana entre el mdulo
electrnico y el sensor, ya que ambos se encontraban en la zona del tablero
de mandos.
Al cambiar la posicin del sensor a la cajuela del vehculo, de modo que se
encontrara lo suficientemente lejos (ms de 1m) como para no activar la
alerta del sistema, los resultados fueron ms favorables. Se ajust la
sensibilidad del sensor para que se active la alerta con un golpe fuerte en
cualquier parte del vehculo. La efectividad de respuesta del circuito del
sensor de impacto fue del 95%

Tabla 17. Resultados de las pruebas de respuesta del sensor de impacto
Prueba N Texto Respuesta de sensor
1 Cap Si
2 Puerta delantera izq. Si
149

3 Puerta delantera der. Si
4 Puerta trasera izq. Si
5 Puerta trasera der. Si
6 Llanta delantera izq. No
7 Llanta delantera izq. Si
8 Llanta delantera der. Si
9 Llanta trasera izq. Si
10 Llanta trasera der. Si
11 Guardachoques delantero Si
12 Guardachoques trasero Si
13 Techo Si
14 Cajuela Si
15 Cajuela Si
16 Techo Si
17 Cap Si
18 Guardachoques delantero Si
19 Guardachoques trasero Si
20 Cajuela Si
Efectividad de respuesta del sensor: 95%

o Efectividad de bloqueo y desbloqueo del vehculo estacionado
Estas pruebas se realizaron con el mdulo electrnico instalado en un
vehculo particular. Como condiciones para realizar el bloqueo se tiene que:
- La alarma est encendida, y ha detectado una alerta a travs del
sensor de impacto.
- El vehculo se encuentra estacionado y apagado antes de realizar el
bloqueo.
- Una vez realizado el bloqueo se intenta encender el vehculo de
manera habitual.
150

- Por ltimo se realiza el desbloqueo.
El objetivo de estas pruebas es determinar la eficacia del circuito electrnico
en cuanto a la realizacin del bloqueo y desbloqueo del vehculo a travs de
su sistema de ignicin.

Resultados:
Como se esperaba al realizar el bloqueo del vehculo e intentar encenderlo
con la llave de encendido, este no responda. Se observ que el motor de
arranque del vehculo si accionaba pero no encenda el motor de combustin
interna debido a la falta de energa que produzca la explosin en los
cilindros. Esto se debe a que el rel de bloqueo solo acta sobre la bobina
de ignicin, permitiendo al resto de sistemas del vehculo seguir siendo
alimentados por la batera del automvil.
Seguidamente se realiz el procedimiento para realizar el desbloqueo, a lo
que se obtuvo como resultado una reactivacin del sistema de ignicin
permitiendo al vehculo recuperar la capacidad de encendido del motor de
combustin interna.
Nota: No es recomendable exagerar en el accionamiento del motor de
arranque cuando est bloqueado, ya que si se lo hace de manera repetitiva y
prolongada se reduce su vida til, incluso puede averiarse totalmente.

o Efectividad de bloqueo del vehculo en movimiento
Estas pruebas tienen como objetivo observar el comportamiento del vehculo
cuando al ser bloqueado, ste se encuentra en movimiento, es decir est
circulando. Para lo cual se tienen que cumplir las siguientes condiciones:
- El sistema ha detectado una alerta de robo.
- El vehculo es encendido y puesto en marcha, comienza a circular por
la va.
151

Con estas condiciones, se procede a realizar el bloqueo y posteriormente el
desbloqueo para analizar el resultado.
Resultado:
El resultado es el esperado, al realizar el bloqueo del vehculo desde el
dispositivo mvil el motor del auto se apaga ocasionando que se detenga
paulatinamente al cabo de unos segundos. Una vez detenido, no es posible
volver a arrancar el vehculo puesto que el sistema de ignicin est
desactivado. La reaccin en el vehculo es parecida a cuando ste se queda
sin combustible.
Seguidamente se realiza el desbloqueo, dando como resultado la
reanudacin del comportamiento normal del vehculo.
Nota: Algunos modelos de vehculos, especialmente modelos ms
modernos, poseen integrado un mecanismo de bloqueo del volante al
desactivar el sistema elctrico del vehculo, lo que hace que al cortar la
energa del sistema elctrico (contacto) el volante se inmoviliza. Es
importante reconocer este esquema, ya que el bloqueo del proyecto
planteado se aplica solo al sistema de ignicin (bobina de ignicin) mas no al
sistema elctrico en s (tablero de control, luces, etc.).

152

6. CONCLUSIONES Y RECOMENDACIONES

153

6.1. CONCLUSIONES
Una vez realizado el diseo, implementacin y pruebas del proyecto
planteado en este trabajo de titulacin se ha podido concluir que:
El sistema de seguridad vehicular con un control remoto mediante una
aplicacin para dispositivos mviles planteado en este trabajo de
titulacin responde a ciertos vacos dejados por los sistemas
convencionales en necesidades de seguridad actual y presenta una
propuesta innovadora, ya que integra las facilidades provistas por las
tecnologas de comunicacin celular a la resolucin de problemas
especficos. Se puede decir que el hecho de controlar la alarma de un
vehculo desde un telfono celular result una opcin atractivamente
cmoda para el usuario, gracias a la posibilidad de monitorear el
sistema en cualquier momentoy, poder administrar el sistema de
seguridad desde cualquier distancia del vehculo.
El mtodo de utilizacin de mensajes de texto (SMS) para enviar las
instrucciones a la alarma tiene sus ventajas y desventajas. Como
principal desventaja se tiene que: es necesario contar con el crdito
suficiente tanto en el telfono mvil como en el mdem GSM, adems
de encontrarse en el rango de cobertura, para el envo de mensajes
de texto entre dispositivos, lo cual opaca un poco el proyecto por los
costos que esto implica, sin embargo el beneficio que se obtiene
puede superar dichas implicaciones. Para obtener un criterio ms
acertado sobre las consecuencias del empleo de mensajes de texto
como mtodo de transmisin de informacin se debe realizar un
anlisis costo/beneficio detallado.
Como ventajas de la utilizacin de mensajes de texto se tiene que,
estos presentan un formato nico, y un medio en el cual se puede
escribir informacin especfica en forma de texto, lo cual ofrece la
posibilidad de desarrollar una amplia serie de cdigos diferentes que
describan distintas instrucciones, adems se aprovecha su carcter
de confidencialidad logrando que ningn usuario final tenga acceso a
154

los cdigos de activacin que son enviados va SMS desde el
dispositivo hacia el mdem, esto ya que la aplicacin utiliza el servicio
de mensajes de texto pero no permite que su contenido sea
visualizado. Otra ventaja de la utilizacin de mensajes de texto es que
son fciles de utilizar, manipular y procesar, y su envo y recepcin
son bastante efectivos.
El sistema propuesto presenta una efectividad en el desempeo de
las funciones descritas dentro de los alcances del proyecto del 100%,
siempre y cuando se presenten ptimas condiciones, Si las
condiciones de cobertura de seal no son favorables el sistema puede
presentar fallos en su funcionamiento, reduciendo su efectividad a no
ms del 10%.

6.2. RECOMENDACIONES
Se recomienda fortalecer el alcance del proyecto utilizando un mdem
GPS/GSM en lugar de un mdem GSM nicamente. Esto
facilitara el desarrollo de aplicaciones con caractersticas de rastreo
satelital haciendo del sistema de seguridad planteado ms fuerte y
efectivo. Adems las herramientas que hoy en da disponemos para la
creacin de sistemas que utilicen el Sistema de Posicionamiento
Global son cada vez ms accesibles y fciles de utilizar.
Utilizar un sensor de encendido, o de puertas en lugar de un sensor
de impacto, o simplemente aadir al sistema la mayor cantidad de
sensores posibles; esto para evitar tanto como sea posible fallas en la
deteccin de alertas de robo, sin necesidad de causar falsas alarmas
por activacin errnea de los sensores.
Tambin es recomendable adentrarse en el desarrollo de aplicaciones
para dispositivos mviles a travs de herramientas de programacin
con ms opciones de desarrollo, como por ejemplo el IDE de
Eclipse, Netbeans, etc. que son suites de desarrollo de
155

aplicaciones con lenguaje Java, que aunque es un lenguaje un poco
ms complejo ofrece caractersticas avanzadas de diseo y desarrollo
de aplicaciones mviles.
Se puede mejorar la aplicacin mvil agregando la caracterstica de
guardar en una lista el historial de procesos realizado en el sistema
mediante un botn de Historial, y la creacin de una pantalla que
muestre el resultado. Para esto es necesario la utilizacin de
instrucciones referentes al almacenamiento de informacin de forma
persistente, o almacenamiento de informacin en bases de datos.
Al momento de realizar la instalacin del sistema en el vehculo se
recomienda tener en claro los conceptos de bloqueo y sobre qu
elementos del automotor se desea realizar el bloqueo; ya que es
posible encontrar en un vehculo moderno el mecanismo de bloqueo
del volante (esto hace que el volante sea truncado) al desactivar el
sistema elctrico, y en vista de que no queremos realizar esa accin,
se debe realizar las conexiones del bloqueo nicamente sobre la
bobina de ignicin.
En cuanto al diseo de la interfaz grfica de la aplicacin mvil, se
recomienda hacer de la plataforma de control una suite bastante
cmoda y ergonmica incluyendo los elementos necesarios para que
el usuario pueda manejar el sistema con completa conformidad, como
por ejemplo, agregar botones grandes y coloridos, con letras
suficientemente legibles y entendibles, y una estructura ordenada
para la fcil comprensin del funcionamiento de la aplicacin.
Para hacer del sistema mucho ms fuerte, ste debe ser
complementado con un sistema de rastreo satelital o GPS, lo cual
permite la localizacin del vehculo una vez que haya sido bloqueado,
de lo contrario, la efectividad del sistema depender solo de cun
rpido se acte en caso de un robo.

156

BIBLIOGRAFA

157

o Libros y publicaciones
Tocornal X., Abril M. & Tupiza A. (2008). Anlisis Comparado del robo de
vehculos en Quito, Guayaquil y Santiago. Programa Estudios de la Ciudad.
Flacso Sede Ecuador. Quito
Hernando, R. (2004). Comunicaciones Mviles (2da ed.) Madrid: Ramn
Areces.
Eberspcher, J., Vgel, H.-J., Bettstetter C., & Hartmann C. (2009). GSM
Architecture, Protocols and Services (3ra ed.). Wiltshire: John Wiley & Sons.
Tomasi, W. (2003). Sistemas de comunicaciones electrnicas (4ta ed.).
Mxico: Pearson Educacin.
Noldus, R. (2006). CAMEL: Intelligent networks for the GSM, GPRS and
UMTS network. John Wiley & Sons.
Gramlich, N. (2012). Andbook! Android programming (release .002).
Germany License (Creative Commons): anddev.org-Community.
Mutual Mobile (2011). Android design guidelines (versin 1.1). Author.
Gargenta, M. (2011). Learning Android (1
st
. ed.). Sebastopol, CA: OReilly.
Jakl, A. (2009). Mobile Operating Systems (version 1.0). FH Hagenberg:
Mobile Computing.
Baz, A., Ferreira, I., lvarez, M. & Garca, R. (2010). Dispositivos Mviles.
Ingeniera de Telecomunicacin, Universidad de Oviedo, Madrid, Espaa.
Meier, R. (2009). Professional Android Application Development.
Indianapolis: Wiley Publishing.
Inec (2011). Reporte anual de estadsticas sobre tecnologas de la
informacin y comunicaciones (TICs) 2011. Ecuador: Author.
Prula, R. (2010). Sistemas Operativos Mviles, Programacin Avanzada.
(Creative Commons).
Lamscheck-Nielsen, R. & Agerskov M. (2010). TA3 Operating Systems.
Metropolitan University College, Denmark.
158

Sapia, J. L. (2002). Inmovilizadores, Manual tcnico (actualizacin nov.
2002). Centro de capacitacin automotriz, Instituto Tecnolgico Superior del
automotor, Buenos Aires, Argentina.
Mattes, B., Schmidt G., Graumann, D. & Rudolf, P. (2000). Sistemas de
seguridad y confort (edicin 2000). Alemania: BOSCH.
Vargas, E. (200). Metodologa Aplicada al Desarrollo de Mquinas
Mecatrnicas, Congreso Latinoamericano de Instrumentacin y Control de
Procesos. Universidad Autnoma de Quertaro. Mxico.
Boylestad, R. (2004). Introduccin al anlisis de circuitos (10ma Ed.)
Pearson Educacin. Mexico.
ZTE Corporation. (2007) AT Command Manual for ZTE Corporations
ME3000 Module (version V2,00),

o Tesis
La Rosa, K. (2012). Diseo de sistema integral de seguridad vehicular:
Seguridad pasiva, seguridad activa y socorro inmediato para conductores y
pasajeros de vehculos automotores. Pontificia Universidad Catlica del
Per, Lima, Per.
Bravo, L. (2011). Diseo e implementacin de alarmas comunitarias a travs
de un operador mvil. Escuela Politcnica del Ejrcito, Sangolqu, Ecuador.
Lpez, E. & Moya, V. (2009). Diseo e instalacin de un sistema de
seguridad y arranque mediante dispositivos de seguridad con sensores
IBUTTON y RFID. Escuela Politcnica del Ejercito, Latacunga, Ecuador.
Paniagua, C. (2008). Control de mdem GSM desde un microcontrolador.
Universitat Rovira i Virgili, Tarragona, Espaa.

159

o Recursos web
Observatorio Metropolitano de Seguridad Ciudadana de Quito. Cubo
estadstico de delitos a la propiedad [En lnea]. Recuperado el 11 de
diciembre del 2012, de
http://www.observatorioseguridaddmq.net/?btnGrafico=&Cubos=DelitosPropi
edad.cub
Wikipedia (2012, septiembre). Telfono inteligente. Wikipedia [En lnea].
Recuperado el 19 de septiembre del 2012, de
http://es.wikipedia.org/wiki/Tel%C3%A9fono_inteligente
Morales Hugo (2012, febrero). Los sistemas operativos mviles ms usados
para navegar en Iberoamrica. Wayerless [En lnea]. Recuperado el 19 de
septiembre del 2012, de http://www.wayerless.com/2012/02/los-sistemas-
operativos-moviles-mas-usados-para-navegar-en-hispanoamerica/
Wikipedia (2012, agosto). Android. Wikipedia [En lnea]. Recuperado el 19
de septiembre del 2012, de http://es.wikipedia.org/wiki/Android
Android Developers (2012, septiembre). Aplications Fundamentals. Android
Developers [En lnea]. Recuperado el 20 de septiembre del 2012, de
http://developer.android.com/guide/components/fundamentals.html
IDC (2012, mayo). Android- and iOS-Powered Smartphones Expand Their
Share of the Market in the First Quarter, According to IDC. IDC [En lnea].
Recuperado el 19 de septiembre del 2012, de
http://www.idc.com/getdoc.jsp?containerId=prUS23503312
Auto radio Honorio (s.f.). Alarmas. Auto radio Honorio [En lnea]. Recuperado
el 19 de septiembre del 2012, de http://www.honorio.com.ar/alarmas.htm
Wikipedia (2012, agosto). Car alarm. Wikipedia [En lnea]. Recuperado el 19
de septiembre del 2012, de http://en.wikipedia.org/wiki/Car_alarm
Wikipedia (2012, agosto). Original Equipment Manufacturer. Wikipedia [En
lnea]. Recuperado el 19 de septiembre del 2012, de
http://es.wikipedia.org/wiki/Original_equipment_manufacturer
160

Wikipedia (2012, agosto). RFID. Wikipedia [En lnea]. Recuperado el 19 de
septiembre del 2012, de http://es.wikipedia.org/wiki/RFID
Wikipedia (2012, agosto). Immobiliser. Wikipedia [En lnea]. Recuperado el
19 de septiembre del 2012, de http://en.wikipedia.org/wiki/Immobiliser

161

ANEXOS

162

Universidad Tecnolgica Equinoccial
Anexo N1
Circuito electrnico completo del
proyecto
Fecha:24/01/13
Escuela: Mecatrnica
Escala: NA Nombre: Willian Veloz Salazar
163

Universidad Tecnolgica Equinoccial
Anexo N2
Layout del PBC del proyecto
realizado en ARES
Fecha:24/01/13
Escuela: Mecatrnica
Escala: NA Nombre: Willian Veloz Salazar
164

Anexo 3. Diagrama de procesos del programa para el PIC16f628a
165

Anexo 4. Diagrama de procesos del SCREEN1 de la aplicacin mvil

166

Anexo 5. Diagramas de procesos del SCREEN2 de la aplicacin mvil

167

Anexo 6. Programa del PIC16f628a en Microcode

'****************************************************************
'* Name : SISTEMA_DE_SEGURIDAD_VEHICULAR_GSM.BAS *
'* Author : Willian Veloz Salazar *
'* Notice : Copyright (c) 2012 *
'* : All Rights Reserved *
'* Date : 02/08/2012 *
'* Version : 1.0 *
'* Notes : Programa para el control de un sistema de *
'* : seguridad vehicular con tecnologa GSM *
'****************************************************************

DEFINE HSER_RCSTA 90h 'Se define la configuracin
DEFINE HSER_TXSTA 24h 'del puerto USART
DEFINE HSER_BAUD 115200 'la tasa de transferencia entre el
DEFINE HSER_CLROERR 1 'PIC y el mdem es de 115200 bauds
DEFINE osc 20 'oscilador de 20MHz

'Configuracin de los switches del PIC16f628a
@ device pic16f628a, hs_osc, wdt_off, pwrt_off, bod_off, lvp_off
@ device pic16f628a, cpd_off, protect_off
@ device mclr_off

trisa=%00100000 'pines de entrada y salida del puerto A
cmcon= 7 'convierte el puerto A en digital

sensor1 VAR portb.4 'Variables de entrada, salida y
led_on VAR portb.6 'variables internas
led_alert VAR portb.5
led_bloq VAR portb.7
modem VAR BYTE[3] 'almacena temporalmente el mensaje de
cod1 VAR BYTE[3] 'texto
cod2 VAR BYTE[3]
cod3 VAR BYTE[3]
cod7 VAR BYTE[3]
cod8 VAR BYTE[3]
numModem VAR BYTE[9]

168

cod1[0]="+" 'estas variables contienen los cdigos
cod1[1]="0" 'de activacin del sistema
cod1[2]="1"

cod2[0]="+"
cod2[1]="0"
cod2[2]="2"

cod3[0]="+"
cod3[1]="0"
cod3[2]="3"

cod7[0]="+"
cod7[1]="0"
cod7[2]="7"

cod8[0]="+"
cod8[1]="0"
cod8[2]="8"

PAUSE 500
HIGH led_on
HIGH led_bloq

HSEROUT["AT+CMGF=1",13] 'Configura el mdem en modo texto
HSEROUT["AT+CMGD=1",13] 'Borra los mensajes del buzn de
HSEROUT["AT+CMGD=2",13] 'entrada, desde la ubicacin 1 a 8
HSEROUT["AT+CMGD=3",13]

HSEROUT["AT+IFC=0,0",13] 'Configura la comunicacin en modo
PAUSE 500 'asncrono

HSEROUT["AT+CNMI=2,2,0,0,0",13] 'Configura el modo de los SMS

HSEROUT["ATD0992380846;",13] 'Realiza una llamada de prueba
PAUSE 10000 'para comprobar la conexin
169

HSEROUT["AT+CHUP",13]

PAUSE 500
LOW led_on
LOW led_bloq

apagado:
HSERIN 200,apagado,[WAIT("+CMT:"),skip 6,STR numModem\9,skip 27,STR
modem\3];Espera un SMS entrante y lo guarda en una variable
HSEROUT["AT+CMGD=1",13];Borra el SMS de la primera posicin del buzn
de entrada
IF modem[0]=cod1[0] AND modem[1]=cod1[1] AND modem[2]=cod1[2]
THEN;Compara el texto del SMS con el cdigo de encendido
HIGH led_on
GOTO encendido
ENDIF
THEN;Compara el texto del SMS con el cdigo de verificacin
HSEROUT["AT+CMGS=",34,"0",STR numModem\9,34,13];Instruccin para
envo de SMS, # de celular, 34(comillas), 13(enter)
HSEROUT["Alarma apagada",26];Enva el mensaje de texto, 26(Ctrl+Z)
GOTO Apagado
ENDIF
GOTO Apagado

encendido:
IF sensor1=1 THEN 'El sensor detecta si hay alguna alerta de robo
HIGH led_alert
HSEROUT["AT+CMGS=",34,"0",STR numModem\9,34,13]
HSEROUT["Alerta de robo",26]
GOTO alerta
ENDIF
HSERIN 200,encendido,[WAIT("+CMT:"),skip 42,STR modem\3]
THEN;Compara el texto del SMS con el cdigo de apagado
LOW led_on
GOTO Apagado
ENDIF
170

HSEROUT["AT+CMGF=1",13]
HSEROUT["Alarma encendida",26]
GOTO encendido
ENDIF
GOTO encendido

alerta:
HSERIN 200,alerta,[WAIT("+CMT:"),skip 42,STR modem\3]
THEN;Compara el texto del SMS con el cdigo de bloqueo
HIGH led_bloq
LOW led_alert
GOTO bloqueado
ENDIF
THEN;Compara el texto del SMS con el cdigo de apagado
LOW led_on
LOW led_alert
GOTO apagado
ENDIF
HSEROUT["Alerta de robo",26]
GOTO alerta
ENDIF
GOTO alerta

bloqueado:
HSERIN 200,bloqueado,[WAIT("+CMT:"),skip 42,STR modem\3]
THEN;Compara el texto del SMS con el cdigo de desbloqueo
LOW led_bloq
GOTO encendido
ENDIF
171

HSEROUT["AT+CMGF=1",13]
HSEROUT["AT+CMGS=",34,"0",str numModem\9,34,13]
HSEROUT["Vehculo bloqueado",26]
GOTO bloqueado
ENDIF
GOTO bloqueado

END

172

Anexo 7. Diagrama de bloques del programa para el Screen1 de la aplicacin
mvil

173

Anexo 8. Diagrama de bloques del programa para el Screen2 de la aplicacin mvil

174

175

176

Anexo 9. Hoja tcnica del PIC16f628a

177

178

179

180

181

Anexo 10. Hoja tcnica del rel CB1a-M-12V

182

Anexo 11. Fotografas del proyecto

Diseo de PBC del circuito electrnico

Pruebas del sistema electrnico en protoboard

183

Circuito electrnico con sus componentes

Tamao del circuito electrnico

184

Componentes del mdulo electrnico

Mdulo electrnico totalmente ensamblado

1

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

1

Caricato da

Copyright:

Formati disponibili

UNIVERSIDAD TECNOLGICA EQUINOCCIAL

FACULTAD DE CIENCIAS DE LA INGENIERA

Potrebbero piacerti anche