universidad tecnolÓgica...
TRANSCRIPT
UNIVERSIDAD TECNOLÓGICA EQUINOCCIAL
FACULTAD DE CIENCIAS DE LA INGENIERÍA
CARRERA DE INGENIERÍA MECATRÓNICA
CONTROL GSM® PARA EL BLOQUEO Y DESBLOQUEO
REMOTO DE UN VEHÍCULO MEDIANTE UNA APLICACIÓN
MÓVIL PARA DISPOSITIVOS ANDROID®
TRABAJO PREVIO A LA OBTENCIÓN DEL TITULO
DE INGENIERO EN MECATRÓNICA
WILLIAN ALEJANDRO VELOZ SALAZAR
DIRECTOR: MSC. DANIEL MIDEROS
Quito, Enero 2013
© Universidad Tecnológica Equinoccial. 2013
Reservados todos los derechos de reproducción
DECLARACIÓN
Yo WILLIAN ALEJANDRO VELOZ SALAZAR, declaro que el trabajo aquí
descrito es de mi autoría; que no ha sido previamente presentado para
ningún grado o calificación profesional; y, que he consultado las referencias
bibliográficas que se incluyen en este documento.
La Universidad Tecnológica Equinoccial puede hacer uso de los derechos
correspondientes a este trabajo, según 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
CERTIFICACIÓN
Certifico que el presente trabajo que lleva por título “Control GSM® para el
bloqueo y desbloqueo remoto de un vehículo mediante una aplicación
móvil para dispositivos Android®”, que, para aspirar al título de Ingeniero
en Mecatrónica fue desarrollado por Willian Alejandro Veloz Salazar, bajo
mi dirección y supervisión, en la Facultad de Ciencias de la Ingeniería; y
cumple con las condiciones requeridas por el reglamento de Trabajos de
Titulación artículos 18 y 25.
Msc. Daniel Mideros
DIRECTOR DEL TRABAJO
C.I.: 1713177325
DEDICATORIA
Este logro va dedicado a mis padres, a mis hermanos, demás 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 más lejos en la búsqueda de días mejores.
Con todo mi corazón dedico este trabajo a mi padre, Luis; aprendí mucho
más con su ejemplo de abnegación y entrega hacia su familia de lo que se
puede aprender en un aula de clases. ¡Lo logramos!
Willian Veloz S.
AGRADECIMIENTO
“Sólo un exceso es recomendable en el mundo: el exceso de gratitud”
(Jean de la Bruyere)
Habría sido imposible lograr la culminación 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
realización 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 Mónica, gracias a quienes hoy soy lo que soy;
estuvieron dándome 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 tíos 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 motivación para
continuar, gracias por creer siempre en mí y estar a mi lado diciéndome:
¡ánimo, tu puedes!... Te amo.
Por último, gracias a la Universidad Tecnológica Equinoccial, compañeros,
amigos, profesores. Allí aprendí lo que con orgullo hoy sé.
i
ÍNDICE DE CONTENIDOS
Página
RESUMEN x
ABSTRACT xi
1. INTRODUCCIÓN 1
2. MARCO TEÓRICO 9
2.1. SISTEMAS DE COMUNICACIÓN CELULAR 10
2.1.1. COMUNICACIONES MÓVILES 10
2.1.1.1. Clasificación de los sistemas de
comunicaciones móviles 10
2.1.2. FUNDAMENTOS DE LOS SISTEMAS CELULARES 13
2.1.2.1. Geometría 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
MÓVILES 27
2.3.1. TELEFONOS INTELIGENTES 28
2.3.1.1. Sistemas operativos para dispositivos móviles 29
2.3.2. ANDROID®, SISTEMA OPERATIVO PARA
DISPOSITIVOS MÓVILES 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 aplicación 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 PROTECCIÓN ANTIRROBO 45
2.5.1. ALARMAS PARA VEHÍCULOS 45
2.5.2. ALARMAS OEM 46
2.5.3. PARTES DE UN SISTEMA DE PROTECCIÓN
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 activación y desactivación remota 56
2.5.3.5. Batería auxiliar 58
2.5.3.6. Inmovilizadores 58
3. METODOLOGÍA 62
3.1. METODOLOGÍA MECATRÓNICA 63
3.1.1. REQUERIMIENTOS DEL PROYECTO 64
3.1.1.1. Acondicionamiento de señales de entrada 65
3.1.1.2. Sistema de control 71
3.1.1.3. Actuadores y dispositivos de salida 75
3.1.2. DISEÑO MECÁNICO 78
3.1.2.1. Funcionamiento de un vehículo a gasolina
con motor de combustión interna 78
3.1.3. DISEÑO ELECTRÓNICO 80
3.1.3.1. Circuito de adquisición de señal del sensor 80
3.1.3.2. Circuito de comunicación con el módem 82
3.1.3.3. Circuito de salida del relé para el bloqueo
del vehículo 84
3.1.4. DISEÑO DEL SISTEMA DE CONTROL 85
iii
3.1.4.1. Programa del microcontrolador del PIC16f628a 85
3.1.4.2. Programa de la aplicación móvil 89
3.1.5. SIMULACIÓN 92
4. DISEÑO 95
4.1. DISEÑO Y SIMULACIÓN DEL COMPONENTE
ELECTRÓNICO 96
4.1.1. CIRCUITO DE ASDQUISICIÓN DE DATOS 97
4.1.2. CIRCUITO DE COMUNICACIÓN 100
4.1.3. CIRCUITO DE SALIDA 102
4.1.4. DISEÑO DEL PBC DEL CIRCUITO ELECTRÓNICO 103
4.2. DISEÑO Y SIMULACIÓN DEL COMPONENTE DE CONTROL 104
4.2.1. DISEÑO DEL PROGRAMA PARA EL PIC16f628a 104
4.2.2. SIMULACIÓN DEL PROGRAMA DEL PIC16f628a 108
4.2.3. DISEÑO DE LA APLICACIÓN MÓVIL 117
4.2.3.1. Diseño de la interfaz gráfica 119
4.2.3.2. Desarrollo del programa de la aplicación 124
4.2.4. SIMULACIÓN DE LA APLICACIÓN MÓVIL 133
5. RESULTADOS 140
6. CONCLUSIONES Y RECOMENDACIONES 152
6.1. CONCLUSIONES 153
6.2. RECOMENDACIONES 154
BIBLIOGRAFÍA 156
ANEXOS 161
iv
INDICE DE TABLAS
Página
Tabla 1. Costos materiales electrónicos 6
Tabla 2. Costos desarrollo de software 7
Tabla 3. Costos desarrollo del proyecto 8
Tabla 4. Costos de instalación 8
Tabla 5. Versiones del sistema operativo Android® 31
Tabla 6. Comandos AT más comunes 43
Tabla 7. Precios de paquetes de SMS 67
Tabla 8. Diferencia entre algunos sistemas operativos móviles 68
Tabla 9. Cobertura celular en la provincia de pichincha 69
Tabla 10. Tabla de comparación entre PIC16f628a y PIC16f877a 72
Tabla 11. Códigos de activación 89
Tabla 12. Componentes de Screen1 (pantalla1) 121
Tabla 13. Componentes de Screen2 (pantalla2) 122
Tabla 14. Resultados de la prueba de envío y recepción de
mensajes desde el teléfono móvil hacia el módem 142
Tabla 15. Resultados de las pruebas de envío y recepción de
mensajes desde el módem hacia el teléfono móvil 144
Tabla 16. Resultados de las pruebas de envío de mensajes
desde el teléfono móvil hacia el módem en ausencia
de señal celular 146
v
INDICE DE FIGURAS
Página
Figura 1. Agrupación de células o clusters 14
Figura 2. Cobertura celular con solape y sin solape 15
Figura 3. Superficies poligonales en función de su baricentro 15
Figura 4. Distribución celular teórica con varias células adyacentes 16
Figura 5. Ejemplo de una distribución real de células 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 modulación espacial
para GSMK y 8-PSK 26
Figura 11. Teléfonos inteligentes 29
Figura 12. Cuota del mercado de los sistemas operativos
móviles a nivel mundial 30
Figura 13. El Stack de Android 33
Figura 14. Ciclo de vida de las actividades 40
Figura 15. Ventana de comunicación entre el hyperterminal
y el módem 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 inclinación 54
Figura 22. Funcionamiento de un sensor de ultrasonido 55
Figura 23. Sirena instalada en el interior del guardamotor
de un vehículo 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 vehículo 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 Metodología del diseño de sistemas
mecatrónicos 64
Figura 30. Sensor de choque 66
Figura 31. Circuito de amplificación para el sensor de choque 66
Figura 32. Arquitectura del PIC16f628a 73
Figura 33. Teléfono móvil Motorola XT316 74
Figura 34. Sistema de encendido e ignición de un automóvil 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 polarización de un transistor NPN 97
vii
Figura 43. Circuito de adquisición de datos 100
Figura 44. Circuito de comunicación serial 101
Figura 45. Circuito de salida del relé 103
Figura 46. Diagrama para la simulación del circuito electrónico 109
Figura 47. Terminal virtual (imagen1) 110
Figura 48. Terminal virtual (imagen 2) 110
Figura 49. Resultados simulación (imagen1) 112
Figura 50. Resultados simulación (imagen 2) 113
Figura 51. Resultados simulación (imagen 3) 114
Figura 52. Resultados simulación (imagen 4) 115
Figura 53. Resultados simulación (imagen 5) 116
Figura 54. Diseño del Screen1 de la aplicación móvil 120
Figura 55. Diseño del Screen2 de la aplicación móvil 120
Figura 56. Bloques de definición 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. Simulación aplicación móvil (imagen1) 134
Figura 68. Simulación aplicación móvil (imagen 2 y 3) 135
Figura 69. Simulación aplicación móvil (imagen4) 135
Figura 70. Simulación aplicación móvil (imagen5) 136
Figura 71. Simulación aplicación móvil (imagen6) 137
Figura 72. Simulación aplicación móvil (imagen7) 137
Figura 73. Simulación aplicación móvil (imagen8) 138
Figura 74. Simulación aplicación móvil (imagen9) 138
Figura 75. Simulación aplicación móvil (imagen10) 139
Figura 76. Pruebas de envío de SMS desde teléfono a
módem con buena calidad de señal celular 142
Figura 77. Pruebas de envío de SMS desde módem a
teléfono con buena calidad de señal celular 144
Figura 78. Pruebas de envío de SMS desde teléfono a
módem en ausencia de señal celular 146
ix
INDICE DE ANEXOS
Página
ANEXO 1
Circuito electrónico 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 aplicación móvil 165
ANEXO 5
Diagrama de procesos del Screen1 de la aplicación móvil 166
ANEXO 6
Programa del PIC16f628a en Microcode® 167
ANEXO 7
Diagrama de bloques del programa para el Screen1 de la
aplicación móvil 172
ANEXO 8
Diagrama de bloques del programa para el Screen2 173
ANEXO 9
Hoja técnica del PIC16f628a 176
ANEXO 10
Hoja técnica del relé CB1a-M-12V 181
ANEXO 11
Fotografías del desarrollo del proyecto 182
x
RESUMEN
El robo de vehículos automotores es uno de los mayores problemas sociales
que afronta nuestro país actualmente. Los sistemas de protección vehicular
comerciales actuales presentan algunas desventajas respecto a su
confiabilidad, ejemplo de ello es que los sistemas con activación por
radiofrecuencia tienen limitaciones en su alcance de activación y su alarma
puede ser percibida audiblemente por el usuario hasta una determinada
distancia. A la par de esta temática se conoce también que en la actualidad
el uso de sistemas que involucran tecnologías móviles es cada vez más
popular en el mundo, debido a las ventajas que representa el control de
sistemas electrónicos mediante aplicaciones instaladas en dispositivos
móviles celulares.
El presente trabajo tiene como objetivo determinar la factibilidad técnica y
económica de la realización de un sistema de seguridad vehicular que
responda a las necesidades actuales de seguridad mediante el uso de
tecnologías móviles como GSM® y desarrollo de aplicaciones para
dispositivos móviles. El sistema propuesto en esta tesis comprende la
creación de un módulo electrónico instalado en un vehículo automotor, que
es controlado desde una aplicación móvil para dispositivos Android® cuyo
desarrollo también está implícito en este trabajo, el sistema en conjunto tiene
la capacidad de activar y desactivar una alarma, detectar una posible alerta
de robo, enviar una señal de alerta al usuario, y bloquear la movilidad del
vehículo 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. INTRODUCCIÓN
2
Según datos presentados por el Observatorio Metropolitano de Seguridad
Ciudadana de la ciudad de Quito, en los últimos cuatro años más 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
vehículos no han disminuido significativamente, aun cuando la tendencia ha
sido la de instalar alarmas electrónicas que emiten una señal audible de
alarma y, en algún caso, efectuar un bloqueo activado automáticamente o
desde un mando a distancia. Es así que, durante el año 2 012 se reportaron
cerca de 1 690 robos de vehículos, de los cuales unos 1 380 se efectuaron
con el vehículo estacionado, lo que correspondería al 81% del total de
vehículos robados (Tocornal X., Abril M. & Tupiza A, 2008). La mayoría de
robos se dieron en la noche, mientras los propietarios descansaban y no
estaban al tanto de la condición de seguridad de su automóvil.
Por otro lado, el robo vehicular se ha convertido en un problema bastante
recurrente, debido al alto interés por parte de los grupos delincuenciales
debido a que un vehículo robado es razonablemente fácil de vender, ya sea
entero o por partes, y que además, incorpora en sí mismo el método de
escape de los infractores. Las alarmas electrónicas estándar actuales se
instalan con el propósito de alertar al propietario del vehículo de un potencial
intento de robo, sin embargo, si la alarma es violentada o si la señal de
alerta no fuera percibida, el vehículo pudiera ser sustraído sin que el usuario
consiguiera evitarlo.
En el mercado local, existen cientos de modelos de alarmas electrónicas,
aunque todas funcionan bajo el mismo principio: una central de control
instalada en el automóvil 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 basándose en el principio de
radiofrecuencia, es decir que posee un emisor de ondas electromagnéticas
de corto alcance (100 m aproximadamente) con el cual se puede activar y
3
desactivar la alarma. Hoy en día, existen también empresas dedicadas a
proporcionar el servicio de seguridad vehicular con tecnología GPS®, el cual
tiene un costo anual o mensual elevado. Este servicio ofrece la posibilidad
de realizar un rastreo satelital para ubicar la posición del vehículo y
bloquearlo desde cualquier parte del planeta. Sin embargo, no es un sistema
muy popular debido a la condición de dependencia de una empresa y los
elevados costos que esto implica.
Por otra parte, los avances tecnológicos son cada vez más notorios en el
campo de las comunicaciones móviles; los recursos para el desarrollo de
tecnologías que permitan integrar otras áreas de interés con las
comunicaciones móviles están libremente disponibles, y no son
necesariamente costosos. De ese modo, es cada vez más común, y más
fácil encontrar variadas aplicaciones para dispositivos móviles dedicadas a
resolver problemas cotidianos, y hacer de la vida del ser humano más
entretenida y llevadera. Además, no existe actualmente un sistema de
seguridad vehicular que le permita al usuario controlar la condición de
funcionamiento del mismo desde un dispositivo móvil a través 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
tecnologías de comunicaciones móviles o GSM®, que permita al propietario,
tener control sobre la seguridad del vehículo en los lugares con cobertura de
señal proporcionada por una compañía de telefonía celular. La
implementación del sistema de seguridad con las características
anteriormente mencionadas, se justificaría por las siguientes razones:
- Ofrecería una solución al problema del robo de vehículos en la ciudad
de Quito, mediante la implementación de un sistema de seguridad de
fácil utilización y monitoreo.
- El proyecto presentado posibilitará un gran alcance, limitado
únicamente por la cobertura de señal celular, es decir que en
condiciones óptimas cubriría totalmente la zona urbana de la ciudad.
4
- Se diseñaría una aplicación móvil enfocada en la seguridad vehicular
con interacción visual, para administrar de manera sencilla la
plataforma de control del sistema de alarma.
- Se promovería la realización de estudios en el campo de las
tecnologías móviles y desarrollo de aplicaciones, que son escasos en
nuestro medio.
Por estos motivos para la realización del presente trabajo de titulación se
plantearon los siguientes objetivos:
Objetivo General
Diseñar un control GSM® para el bloqueo y desbloqueo remoto de un
vehículo desde una aplicación móvil para dispositivos Android®.
Objetivos Específicos
Los objetivos llevados a cabo para la consecución final del objetivo general
son los siguientes:
Diseñar e implementar en un automóvil, un sistema de control de
seguridad que incluya un módulo electrónico que, procese, envíe,
reciba y procese información a través de un módem GSM®, y que
permita realizar funciones de bloqueo y desbloqueo del vehículo.
Diseñar e implementar una aplicación móvil para dispositivos
Android® que permita controlar el sistema de seguridad a través de la
comunicación móvil con el modem GSM® instalado en el módulo
elecrtónico en el sistema de seguridad del vehículo.
Construir y validar el prototipo mediante el protocolo de pruebas de
campo.
5
Este proyecto pretende abarcar el diseño y realización de un sistema de
seguridad vehicular que comprende las siguientes características:
- Un módulo electrónico diseñado para ser instalado en el vehículo, el
cual realizará las funciones de: comunicación con un modem GSM®
(instalado juntamente con el módulo electrónico) a través de un puerto
serial, lectura de la señal de un sensor de impacto, bloqueo
electrónico del vehículo mediante apertura del sistema eléctrico del
mismo.
- Un módem GSM® que realiza las siguientes funciones: comunicarse
con un microcontrolador (módulo electrónico) mediante códigos AT a
través del puerto serial, y enviar y recibir mensajes de texto hacia y
desde un dispositivo móvil (teléfono celular).
- Una aplicación móvil desarrollada para un teléfono móvil 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 contraseña
única a la plataforma, encender y apagar la alarma del vehículo,
recibir una alerta de robo, bloquear y desbloquear el vehículo en caso
de robo.
- Este proyecto se aplica solamente a vehículos automotores a gasolina
(no a diesel) con motor de combustión interna.
La integración de estas partes constituye en sí el sistema de seguridad
vehicular cuyo desarrollo se describe en este documento.
Para la implementación de este sistema de seguridad es necesario plantear
el estudio de factibilidad económica en el cual se deben tomar en cuenta
factores como que el software utilizado tanto para la programación del
microcontrolador como para el desarrollo de aplicaciones es software libre, lo
que significa una reducción 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 continuación se describe los costos de los materiales utilizados en este
proyecto:
Componente electrónico:
Tabla1. Costos materiales electrónicos
Descripción Cant. V. Unit. V. Total
Módem 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 automóvil 1 5,00 5,00
7
Socket relay 1 1,20 1,20
Bornera de potencia 1 0,50 0,50
Elaboración de tarjeta electrónica 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
Descripción Cant. V. Unit. V. Total
Microcode Studio Plus V.3.0.0.5 1 0,00 0,00
PICkit v 2.61 1 0,00 0,00
Programador de PIC’s 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
Descripción Cant. V. Unit. V. Total
Estudiante 8 1200,00 9600,00
Gastos varios 8 120,00 960,00
TOTAL 10560,00
Costos de instalación:
Tabla 4. Costos de instalación
Descripción Cant. V. Unit. V. Total
Instalación 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 electrónica convencional en el mercado se
encuentra alrededor de unos $50,00; e incluyendo sus costos de instalación
el precio se eleva a unos $100,00. El producto planteado en este proyecto
supera las características de los sistemas de seguridad convencionales, por
lo que su precio puede ser más alto siendo aún atractivo para el mercado.
De acuerdo con datos obtenidos en investigaciones realizadas, se estimaría
vender de 6 a 10 unidades del sistema de seguridad planteado
mensualmente, cuyo precio en el mercado estaría fijado en $240,00 lo que
incluye el costo amortizado del diseño y desarrollo.
1
2. MARCO TEÓRICO
10
2.1. SISTEMAS DE COMUNICACIÓN CELULAR
2.1.1. COMUNICACIONES MÓVILES
Para entender el funcionamiento de un sistema de comunicación celular,
debemos partir del concepto de las comunicaciones móviles, el cual está
definido por la UIT (Unión Internacional de Telecomunicaciones) como un
servicio de telecomunicaciones entre estaciones móviles y estaciones
terrestres fijas, o simplemente entre estaciones móviles.
A través de los sistemas de telecomunicación móviles podemos intercambiar
información como voz, imágenes, datos, faz, video entre terminales móviles
o fijos. El objetivo de un sistema móvil es aprovechar su carácter de
“inalámbrico” y “movilidad” dentro de una determinada zona de cobertura
(Hernando, 2004).
2.1.1.1. Clasificación de los sistemas de comunicaciones
móviles
Los sistemas de comunicación móvil se clasifican de acuerdo a algunos
criterios, entre los cuales tenemos:
a. Por el sector de aplicación
b. Por la técnica de multi-acceso
c. Por el modo de explotación
a. Por el sector de aplicación
Se clasifican en: Sistemas privados, públicos y de telefonía inalámbrica.
Los sistemas de radiotelefonía móvil privada, PMR (Private Mobile Radio) y
pública, PAMR (Public Access Mobile Radio), se caracterizan por su área de
acción que suele estar limitada y no están conectados de forma expresa a la
red telefónica pública conmutada PSTN (Public Switched Telephone
11
Network). Posteriormente las redes móviles se integraron a la PSTN, para
formar una nueva red que posea las ventajas de las redes móviles aplicadas
al sector público, esta red se denominó PLMN (Public Land Mobile
Networks)
b. Por la técnica de multiacceso
Técnica de multiacceso es la metodología utilizada por los terminales del
sistema móvil para compartir los recursos comunes de la red a través de las
estaciones base. Tales técnicas son:
- Acceso múltiple por división de frecuencia: FDMA (Frequency Division
Multiple Access). Suelen ser de un solo canal por portadora y se
utilizaron en las primeras redes móviles tradicionales, donde cada red
utiliza una o más frecuencias, rígidamente asignadas. Las
transmisiones de diferentes redes o grupos se separan en frecuencia
usando portadoras distintas. Los receptores seleccionan el canal
deseado mediante la sintonización manual o automática.
- Acceso múltiple por división de tiempo: TDMA (Time Division Multiple
Access). Permite que varias redes o terminales móviles compartan la
misma frecuencia utilizándola en ráfagas temporales y no de forma
permanente. Por ello las transmisiones de los usuarios son
discontinuas, intercalándose en el tiempo las ráfagas de cada uno, de
forma que no colisionen ni interfieran entre sí. Las técnicas TDMA
requieren una estricta sincronización y que los equipos dispongan de
memorias para almacenar la información, a fin de entregar ésta de
manera continua a los destinatarios. Por lo tanto el TDMA únicamente
es viable con sistemas de transmisión digital.
- Acceso múltiple por división de código: CDMA (Code Division Multiple
Access). En este sistema se superpone a la información digital
transmitida por cada usuario un código que le es propio, denominado
12
código de dirección o signatura. Las transmisiones de todos los
usuarios se realizan en la misma frecuencia durante todo el tiempo. A
cada receptor llegan todas las señales presentes en el sistema en un
momento dado. Sin embargo, cada usuario, utilizando su código,
puede recuperar la información destinada a él y eliminar las demás.
c. Por el modo de explotación
Se distinguen tres modos de operación en comunicaciones móviles:
- Simplex
En este modo un terminal puede ya sea transmitir (pero no recibir)
o recibir (pero no transmitir) información desde otro terminal. Es el
sistema de comunicación más simple.
- Semiduplex
En modo semiduplex un terminal puede transmitir y recibir
información desde otro terminal, sin embargo no lo puede hacer de
forma simultánea; si el equipo está transmitiendo no puede recibir
y viceversa, pero si puede cambiar a modo de recepción siempre y
cuando el otro terminal se transforme en transmisor.
- Duplex
Este método es el más completo y complejo a la vez, ya que
puede transmitir y recibir información simultáneamente con otro
terminal.
(Hernando, 2004).
13
2.1.2. FUNDAMENTOS DE LOS SISTEMAS CELULARES
Hasta ahora hemos estudiado los sistemas de comunicaciones móviles de
una forma general y en su funcionamiento básico, sin embargo los sistemas
de comunicación móvil fueron más allá, al implementar un concepto de
comunicación que resolviera los problemas comunes de las redes PLMN,
tales como, la exigencia de capacidad de tráfico. Este concepto denominado
“celular” fue ideado en 1947 por D. H. Ring, y se basa en las siguientes
declaraciones (Hernando, 2004):
1) La división de la zona de cobertura en regiones pequeñas, llamadas
células, de tamaño variable en función de la demanda de tráfico.
2) La reutilización de frecuencias en células separadas por una distancia
suficiente para que la interferencia cocanal sea tolerable.
En un sistema de comunicación celular, las frecuencias se pueden reutilizar,
ya que cada célula utiliza las frecuencias de manera independiente, esto
mejora y aumenta considerablemente el tráfico. La única condicionante es
que las frecuencias no sean las mismas entre células adyacentes para que
no existan interferencias. A las células que comparten las mismas
frecuencias se les denomina “células cocanal”, y deben estar separadas una
cierta distancia; esto se logra agrupando las células cocanal en conjuntos
denominados clusters o agrupaciones, de modo que no sean adyacentes
entre si, sino que estén rodeadas por células de otras agrupaciones que
tampoco sean adyacentes entre si.
Evidentemente, cuanto menor sea el tamaño de la agrupación también lo
será el número de frecuencias necesarias, por lo que una característica
importante de los sistemas celulares es la determinación del tamaño óptimo
de la agrupación 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 células organizadas en 4 agrupaciones de 4 células: A,
14
B, C, y D, cada una de las cuales se repite cuatro veces, de forma que una
estación móvil, cualquiera que sea su situación dentro de la zona de
cobertura, podrá comunicar con alguna célula. La cobertura radioeléctrica de
las células se realiza desde estaciones base situadas en principio en el
centro de cada célula (Tomasi, 2003) y (Hernando, 2004).
Figura 1: Agrupación de células o clusters
Fuente: (Hernando, 2004)
2.1.2.1. Geometría de las redes celulares
Si en cada célula se utilizan antenas omnidireccionales, la zona de cobertura
sería 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.)
Fuente: (Hernando, 2004)
Por esta razón, cuando se diseñan las redes celulares, se estudian
coberturas tipo poligonal, que recubran el plano sin solape. Existen tres
polígonos regulares que cumplen con esa condición: el triángulo, el
cuadrado y el hexágono. Suponiendo que se coloca la estación base en el
baricentro del polígono y que el radio de cobertura R es la distancia del
baricentro a un vértice, las superficies de los polígonos son:
Triángulo: √
Cuadrado:
Hexágono: √
Figura 3: Superficies poligonales en función de su baricentro
Fuente: (Hernando, 2004)
16
Analizando lo anterior, podemos notar que para un radio de cobertura fijo R,
el hexágono es el polígono regular que proporciona mayor superficie de
célula, es por esta razón que se utilizan para el diseño de redes celulares, ya
que se necesitan menor cantidad de células para cubrir una determinada
área. Aunque en la realidad las células no poseen exactamente la forma de
un hexágono debido a las irregularidades en la topografía, y cobertura de
necesidades de los usuarios (Hernando, 2004) y (Eberspächer, J., Vögel, H.-
J., Bettstetter C., & Hartmann C., 2009).
Figura 4: Distribución celular teórica, con varias células adyacentes
Fuente: (Hernando, 2004)
En la figura 4 se observa un modelo regular de una distribución celular
teórica, donde se puede ver cómo se distribuyen las células 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
consideración diversos factores como irregularidades en la topografía,
necesidades de cobertura, tráfico, etc. Por ello, los modelos de distribución
reales suelen tener formas irregulares, tal como se ilustra en la figura 5.
17
Figura 5: Ejemplo de una distribución real de células en una zona urbana
Fuente: (Eberspächer, J., Vögel, H.-J., Bettstetter C., & Hartmann C., 2009)
2.2. GLOBAL SYSTEM FOR MOBILE COMUNICATIONS,
GSM
GSM es el estándar global para telecomunicaciones móviles. La red celular
digital GSM nació como consecuencia de que a pesar que ya existían varias
redes celulares (PLMN) “analógicas” en Europa, estás eran incompatibles
entre sí, por lo que el ámbito de servicio se limitaba al espacio territorial de
cada país, y debido al régimen monopólico, las operadoras no prestaban
servicios de buena calidad (Eberspächer, J., Vögel, H.-J., Bettstetter C., &
Hartmann C., 2009).
La CEPT (Conference Europeenne des Postes et Telecommunications), creó
el comité técnico GSM (Groupe Speciale Mobile) con la orden de preparar el
estándar de un sistema de telefonía móvil público paneuropeo.
Posteriormente las siglas GSM se reservaron para definir a la tecnología
como Sistema Global para telecomunicaciones Móviles (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 estándar de telecomunicaciones
móviles, mas no así, para referirse al comité que lo desarrolló.
El comité debía desarrollar una norma para una red PLMN con interfaces
básicas 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 países de la Comunidad Europea.
- Tecnología Digital
- Gran capacidad de tráfico.
- Utilización eficiente del espacio radioeléctrico.
- Sistema de señalización digital.
- Servicios básicos de voz y datos.
- Amplia variedad de servicios telemáticos
- Seguridad y privacidad en la interfaz radio, con protección de la
identidad de los usuarios y encriptación de sus transmisiones.
- Utilización de teléfonos portátiles.
- Altas calidades de cobertura, tráfico y señal 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 comunicación móvil; en los sistemas GSM se
observa un esquema más detallado. Los componentes fundamentales de
una red GSM se pueden observar en la siguiente figura.
19
Figura 6: Arquitectura del sistema GSM
Fuente: (Eberspächer, J., Vögel, H.-J., Bettstetter C., & Hartmann C., 2009)
Una Estación Móvil es el dispositivo que posee el usuario (teléfono móvil), el
cual se puede conectar vía aire a una Estación Base, que en GSM se
denomina BTS (Base Transceiver Station), Las BTS contienen todo el
equipo necesario para la transmisión y recepción, como, antenas,
amplificadores, y unos cuantos equipos necesarios para el procesamiento de
señales. A fin de que las BTS sean equipadas lo más simplemente posible,
la mayoría de equipos electrónicos se encuentran en las BSC (Base Station
Controller). En las BSC se realizan algunas funciones de protocolo, como
por ejemplo, asignaciones de canales, configuración y manejo de traspasos
(handover), etc. Generalmente una BSC administra varias BTS por conexión
de línea.
El tráfico combinado de los usuarios es conmutado a través 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 telefónica 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
además, con la red telefónica 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 también 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 información referente a la ubicación
de un móvil que se conecta a la red, esto es necesario ya que el MSC debe
conocer la ubicación del móvil para conectarse con la BTS adecuada.
Además estas bases de datos contienen información 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 información
relacionada a la seguridad del usuario, como claves de autentificación y
encriptación. El EIR (Equipment Indentity Register) almacena información
relacionada al equipo, más no información del usuario.
Por último, la administración y mantenimiento de la red se realiza a través
del OMC (Operation and Maintenance Center). Entre sus funciones están, la
administración de usuarios, terminales, configuración, operación, monitoreo
y mantenimiento de la red (Eberspächer, J., Vögel, 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 información sobre los
abonados, cuentas, pagos, recargas, identificación 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 información del
abonado, como, ubicación del usuario, realización y terminación de
llamadas, y cargo de costos de llamadas. También contiene la información
que se almacena en el HLR.
Un equipo móvil se convierte en una estación móvil 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 móvil, así, todos los equipos móviles del mundo poseen un número
de identificación 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 transmisión de datos, ya
que en un principio GSM solo podía transmitir información de voz. Esto
implicó aumentar las tasas de transmisión y modificar los métodos de
transmisión para poder enviar la información de datos ya que ésta es más
grande y compleja que la información 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ª generación”,” 2,5GSM” o GSM 2+, “GSM 3ª generación” o 3GSM y
la más reciente 3,5GSM (Eberspächer, J., Vögel, 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, consistía en la conmutación de
circuitos destinados al envío y recepción de datos de tasa fija durante la
comunicación; otro punto a considerar es que la tasa de transmisión 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 Generación” de GSM, o GSM2
(Hernando, 2004).
La “conmutación de circuitos” es una técnica que consiste en configurar una
serie de nodos intermedios para propagar los datos del nodo remitente al
nodo receptor. En tal situación, la línea de comunicación se puede comparar
con un canal de comunicación 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 físico. 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 información desde la BTS
hacia la BSC; de este modo no se pueden ocupar esos canales para otros
propósitos. Para lograr esto se debía implementar en los equipos móviles
una nueva funcionalidad llamada TAF (Terminal Adoption Funtion)
(Hernando, 2004) y (Eberspächer, J., Vögel, H.-J., Bettstetter C., &
Hartmann C., 2009).
Figura 8: Arquitectura del sistema para soporte de HCSD
Fuente: (Eberspächer, J., Vögel, H.-J., Bettstetter C., & Hartmann C., 2009)
2.2.3.2. GPRS
La transmisión de datos a través de una red GSM fue posible a partir de la
implementación de los métodos de conmutación de circuitos para canales
dedicados a éste propósito. Sin embargo, ésta fase, que se conoció como
GSM2 dio un paso más al transformarse en GSM2+ o 2.5GSM.
El sistema GPRS (General Packet Radio Services), que fue diseñado para
la transmisión de información de datos empleaba un sistema de conmutación
24
de paquetes en lugar del sistema de conmutación de circuitos. En GPRS la
información total se dividía en varias partes, cada una de ellas denominada
“paquete”, las cuales se enrutaban a través de la red utilizando los mismos
canales que en GSM, y luego se ensamblaban de nuevo para entregar la
información total al destinatario, lo que hacía éste método más eficiente, ya
que no era necesario ocupar la totalidad de los canales que enlazaban a la
estación móvil, la BTS y la BCS. Por contraparte, el proceso de dividir la
información en paquetes requería la implementación de nuevos equipos en
el sistema, y en ocasiones no todos los paquetes llegaban al destinatario,
por lo que tuvo que desarrollarse también métodos de transmisión que
aseguraran la transmisión efectiva de todos los paquetes desde su origen
hasta el destino final (Eberspächer, J., Vögel, 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 núcleo de red, los nodos de red:
SGSN (Service GPRS Support Node) y GGSN (Gateway GPRS Support
Node).
Ya que un sistema GSM la información que se intercambia en forma de
paquetes no es susceptible de ser conmutada y encaminada por los MSC,
esta función 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
información entre los terminales (MS) y redes de paquetes externas (ej.
Internet a través de protocolos IP), éste convierte los paquetes GPRS
provenientes de los SGSN en el formato de PDP (Packet Data Protocol)
apropiado y los envía 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
Fuente: (Eberspächer, J., Vögel, H.-J., Bettstetter C., & Hartmann C., 2009)
2.2.3.3. EDGE
EDGE es el acrónimo de Enhanced Data Rates for GSM, aunque luego fue
cambiado por Enhanced Data Rates for Global, ya que éste sistema se
aplicó no sólo a redes GSM, sino a otras redes celulares con diferentes
estándares.
Los sistemas HSCSD y GPRS lograron altas tasas de transferencia gracias
a la técnica de multi-acceso TDMA en la que cada terminal podía usar varios
espacios de tiempo en un periodo determinado para compartir los recursos
de la red. El sistema EDGE fue un paso más allá al mejorar la eficiencia
espectral en la capa física y poder usar así un solo espacio de tiempo.
EDGE introduce algunas combinaciones adicionales de modulación y
esquemas de códigos mejorados que permiten a los terminales adaptar sus
tasas de datos a sus niveles individuales de calidad de señal. Técnicamente,
se puede decir que EDGE consiste en un mejoramiento de la interfaz aire,
26
así se ha logrado aumentar las tasas de transmisión de datos y por ende,
aumentar las velocidades de transmisión (Eberspächer, J., Vögel, H.-J.,
Bettstetter C., & Hartmann C., 2009). El esquema de modulación del sistema
se puede apreciar en la siguiente figura.
Figura 10: Constelaciones de modulación espacial para GSMK y 8-PSK
Fuente: (Eberspächer, J., Vögel, H.-J., Bettstetter C., & Hartmann C., 2009)
A la izquierda se puede observar el esquema de modulación para GSM que
emplea un bit por símbolo. A la derecha se observa el esquema de
modulación mejorado denominado 8-PSK que utiliza 3 bit por símbolo, en
otras palabras, con el nuevo esquema de modulación, el sistema EDGE es
aproximadamente tres veces más rápido.
27
2.3. DESARROLLO DE APLICACIONES PARA
DISPOSITIVOS MÓVILES
Con la llegada de las nuevas tecnologías de comunicación celular como
EDGE, CDMA, WCDMA y más recientemente UMTS, surgió también una
nueva generación de dispositivos móviles con especificaciones y
características que hacen de su uso una experiencia de comunicación que
va más allá de su funcionalidad original: realizar y recibir llamadas
telefónicas. Hoy en día los usuarios pueden a través de sus teléfonos
móviles acceder a una serie de procesos y recursos ya sean o no “on-line”;
compartir archivos multimedia, conectarse a una red móvil o estática,
transferir cualquier tipo de información (texto, voz, imágenes, video, VoIP,
datos, etc.), grabar voz, imágenes o video con una determinada calidad,
acceder a una gran variedad de aplicaciones es ahora más fácil con los
dispositivos móviles de gama alta y media alta. A estos dispositivos móviles
se les denomina “Smartphones” o teléfonos inteligentes.
Sin embargo, en los últimos años se ha encontrado que este ámbito
tecnológico puede ser más atractivo para los desarrolladores que para los
propios usuarios. Con la liberación del software de los teléfonos móviles de
algunas marcas fabricantes, son cada vez más, los programadores que se
encuentran desarrollando aplicaciones para éstos dispositivos, ya sea para
uso personal, libre distribución, o venta de las mismas. Uno de las
plataformas para dispositivos móviles más conocido y usado últimamente ha
sido el sistema operativo “ANDROID®” de Google.inc, que corre en
dispositivos de más de veinte marcas comerciales como: Samsung,
Motorola, Toshiba, Kyocera, Asus, Dell, Asus, etc. Este sistema operativo
que se va a detallar más 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. TELÉFONOS INTELIGENTES
Tal vez los teléfonos inteligentes o Smartphones son considerados como
uno de los mejores inventos del siglo XXI, y su uso hoy en día es tan común,
a pesar de que esta tecnología se ha introducido en nuestro país
recientemente. Según el INEC (2011), aproximadamente el 46,6% de la
población posee un teléfono móvil (celular) activado, y de este porcentaje un
8,4% son smartphones; esto quiere decir que alrededor de más de medio
millón de personas posee un Smartphone en Ecuador, siendo la mayor
audiencia, personas entre 25 y 34 años de edad. Sin embargo estas cifras
van aumentando cada vez más, debido a facilidades a su acceso, como
precios bajos y paquetes de consumo atractivos.
Un Smartphone es básicamente un dispositivo electrónico que funciona
como un teléfono móvil con características de un ordenador. Permite hacer y
recibir llamadas y enviar mensajes de texto como un móvil convencional,
pero además posee una serie de características adicionales que
incrementan su utilidad, tales como:
- Visualización de imágenes y animaciones.
- Administración de contactos.
- Lectura de archivos (*.pdf, *.txt, etc.)
- Reproductor de música y video.
- Cámara de fotos y video.
- Soporte a correos electrónicos.
- Conectividad a internet.
- Acceso a redes inalámbricas (Wi-fi)
- Conexión Bluetooth.
- Sistema de posicionamiento Global (GPS).
- Instalación de aplicaciones digitales, etc.
(Baz, A., Ferreira, I., Álvarez, M. & García, R., 2010).
29
Otra característica destacada de los teléfonos inteligentes son sus pantallas
táctiles, aunque no necesariamente disponga de ella, o de todas las
características anteriormente mencionadas. Una característica esencial a
tomar en cuenta para considerar si un teléfono móvil es un Smartphone, es
su avanzada Interfaz de Programación de Aplicaciones (API), que permite el
desarrollo de aplicaciones sobre su sistema operativo, además de una
Interfaz de Usuario (UI) amigable y moderna (Wikipedia, Teléfono
inteligente).
Figura 11: Teléfonos Inteligentes
Fuente: www.poderpda.com
2.3.1.1. Sistemas operativos para dispositivos móviles
Un sistema operativo (OS) para dispositivos móviles (llámese también
Sistema Operativo Móvil) no es más que la plataforma informática que
establece la interfaz entre el usuario y el hardware del dispositivo móvil, y
sobre la cual se pueden instalar aplicaciones que agregan utilidad al
dispositivo. Entre las funciones más comunes de un sistema operativo móvil
están las de administración de memoria física y virtual, control de hardware
(CPU, teclado, pantalla, altavoces, puertos, etc.), lectura y escritura de
archivos, control de procesos multitarea, definición de la interfaz de usuario
(UI) (Baz, A., Ferreira, I., Álvarez, M. & García, R., 2010).
Los sistemas operativos móviles más 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
más 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 año 2010 sólo ocupaba un 17%, desplazando a Symbian, el sistema
operativo para teléfonos Nokia, que hace un par de años era líder del
mercado con más del 50% de la cuota total del mercado.
Figura 12: Cuota del mercado de los sistemas operativos móviles a nivel
mundial
Fuente: (IDC Worldwide Mobile Phone Tracker, May 24, 2012)
31
2.3.2. ANDROID, SISTEMA OPERATIVO PARA DISPOSITIVOS
MÓVILES
Android es una plataforma diseñada para dispositivos móviles que corre
sobre un núcleo 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 compañía que en el 2005 fue absorbida
por Google; a partir de entonces se comenzó a rumorar que Google entraría
en el mercado de la telefonía celular. En 2007 se liberó por primera vez la
mayor parte del código 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 librerías escritas en lenguaje C;
luego de compilarse el sistema operativo utiliza una máquina 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 versión 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.01 6 Eclair Android 2.1 7 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 (Aplcatión Programming Interface) level representa el
nivel de comucación de los diferentes métodos y procesos entre las
aplicaciones que son parte del software del sistema operativo,
evidentemente el API level incrementa con cada actualización del software.
2.3.2.1. El Android Stack
La palabra “stack” puede traducirse como “pila”, y así es básicamente 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 núcleo 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 cámara,
etc. También se encuentra instalada la aplicación de administración de
energía. Al igual que Linux, Android es un sistema operativo de código
abierto.
o Librerías
Esta capa contiene las librerías escritas en C/C++ que pueden usarse para
desarrollar aplicaciones, además en esta capa se encuentra la DVM (Dalvik
Virtual Machine), que se diferencia de la máquina 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 también pueden acceder a los API’s de las aplicaciones
base para modificar las características 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
están escritas en Java (Meier, 2009) y (Gargenta, 2011).
2.3.3. APLICACIONES
Generalmente una aplicación es un programa informático que se ejecuta
sobre una plataforma y realiza una o varias tareas. En Android, cada una de
las tareas o procesos que se están ejecutando en el dispositivo móvil son
realizadas por aplicaciones. Por ejemplo, el asistente de pantalla táctil,
administrador de batería, visualizador de imágenes y videos, gestor de
descargas, reloj, calculadora, etc., todos estos procesos son realizados por
aplicaciones instaladas en el dispositivo móvil por el fabricante. Además,
están 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
página 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 programación Java. El
Android SDK se encarga de compilar el código y empaquetarlo en un archivo
*.apk el cual se considera ya como una aplicación 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 móvil por defecto y que son indispensables para el correcto
funcionamiento del mismo, ya que contienen los drivers para el enlace entre
software y hardware. También hay aplicaciones que el usuario puede instalar
para añadir herramientas a su dispositivo móvil. Sin embargo, la siguiente
clasificación 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 están 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 interacción, que a excepción de cuando
son configuradas, pasan la mayor parte de su tiempo ejecutándose de
forma oculta. Ejemplo de ello son las aplicaciones de administración de
batería, teclado multi-toque, o aplicaciones de auto-respuesta de SMS’s.
- 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 música (Meier, 2009).
36
2.3.3.2. Componentes de una aplicación
Los componentes de una aplicación Android son bloques de construcción
esenciales para su funcionamiento; cada componente cumple con un rol
específico y existe como una propia entidad, aunque no son necesariamente
entradas de interacción 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 aplicación
puede tener una o más Actividades. Por ejemplo, una aplicación de correo
electrónico muestra en una de sus actividades su lista de contactos, y en
otra actividad el área de texto que se va a enviar.
A continuación se muestra un ejemplo de la declaración 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
ejecución o tareas para procesos remotos. Un ejemplo de un servicio es
cuando estamos reproduciendo música con el reproductor de medios
mientras estamos en una aplicación diferente.
Un ejemplo de la declaración de un servicio en el Manifest de Android se
muestra a continuación:
<application ... >
<service android:name=".ExampleService" />
...
</application>
(Gramlich, 2012)
o Proveedores de Contenidos (Content Providers)
Un proveedor de contenidos es un componente que administra la
información de una aplicación Android. La información 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 información persistente.
A continuación se observa un ejemplo de una porción de código 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 Transmisión (Broadcast Receivers)
Los receptores de transmisión son componentes que responden a las
transmisiones de avisos del sistema, por ejemplo, a un aviso que indica que
la batería tiene una nivel bajo, o que la pantalla se ha apagado. Cuando
estos avisos se presentan en la interfaz gráfica de modo que el usuario lo
pueda notar se denominan aplicaciones.
Los receptores de transmisión son llamados mediante objetos denominados
Intents. A continuación se explica que es un Intent.
o Intents e Intents Filters
Un objeto Intent es una porción de información que indica lo que otros
componentes “intentan” realizar e información de interés para el sistema
operativo Android. Generalmente las subclases de tres de los componentes
antes mencionados (Actividades, Servicios y Receptores de transmisión)
pueden activarse con la instrucción Intent.
Por otro lado un Intent Filter describe las competencias de los componentes,
es decir el conjunto de Intent’s que el componente puede recibir. Un
componente puede manejar uno o más Intent’s.
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á
ejecutándose 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 información, información que debe ser
almacenada en algún 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 métodos 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 aplicación, es llamado el método
onCreate() que crea la actividad, luego la inicializa mediante el método
onStart(), y la actividad comienza a ejecutarse en primer plano, donde recibe
la atención del usuario. En esta instancia el usuario puede salir de la
aplicación y cerrarla, o simplemente volver a la pantalla principal y dejar que
la aplicación se ejecute en segundo plano, asignando menos memoria a la
aplicación para poder realizar otras tareas. Si el usuario sale de la aplicación
o cambia a otra actividad se llama al método onStop() que cancela todos los
procesos que estaban siendo realizados por la anterior actividad y almacena
la información 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 método onPause(), durante éste estado, la aplicación pierde la atención
del usuario y es capaz de almacenar información para su uso en un espacio
de memoria no persistente; una vez que el usuario vuelve a la anterior
actividad se llama al método onResume(). Tambien se puede reabrirr la
actividad desde su estado “detenido”, mediante el método onRestart().
Finalmente, todo lo que se ha realizado a en esa actividad, puede ser
eliminado mediante el método onDestroy() que cierra totalmente la
aplicación, 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á ejecutándose 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 ningún código, solo almacenar información de su estado.
41
2.3.3.4. El AndroidManifest.xml
El AndroidManifest.xml es un archivo se encuentra en la carpeta raíz de la
aplicación y es requerido para cada aplicación Android. En él se describen
todos los valores globales del paquete, incluyendo los componentes de la
aplicación (actividades, servicios, etc.) y la forma en que son lanzados y
ejecutados. Por esta razón podemos decir que éste es el archivo más
importante de un paquete de aplicación y que tomar en cuenta al momento
de desarrollar una aplicación (Gramlich, 2012).
A continuación se muestra un ejemplo de una porción de código 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
comunicación entre un terminal módem y otro dispositivo (ordenador,
microcontrolador). Se utilizan principalmente para configurar el módem y
para acceder a las funciones básicas del mismo, tales como realizar,
contestar o rechazar una llamada, enviar o recibir un mensaje de texto,
revisar el nivel de batería del dispositivo, etc. En un principio fueron
utilizados por las empresas Microcom y US Robotics para configurar sus
módems, pero luego el lenguaje fue desarrollándose y extendiéndose hasta
universalizarlo. Hoy en día todos los dispositivos móviles cuentan con su
juego de instrucciones AT detallado en su documentación técnica, los cuales
pueden variar de acuerdo al fabricante, pero los comandos estándar más
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 más comunes y detallados según la marca de dispositivos
móviles ZTE son los siguientes:
Comandos sin parámetros: 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 configuración. Su formato es:
AT[+/&]<command>?
Por ejemplo: AT+CNMI?
43
Comandos de ayuda: Son usados para enlistar los posibles
parámetros del comando. Su formato es: AT[+/&]<command>=?
Por ejemplo: AT+CMGL=?
Comandos de parámetros: 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 documentación del
dispositivo. El formato básico de los valores retornados es el
siguiente:
<CR><LF><Response string><CR><LF>
<CR><LF><OK/ERROR>[ERROR INFO]<CR><LF>
Los comandos AT más utilizados se describen a continuación en la siguiente
tabla:
Tabla 6. Comandos AT más comunes
Comando Descripción
A/ Sirve para repetir un comando anterior
ATA Sirve para contestar una llamada entrante
ATD Se utiliza para realizar una llamada / marcar a un número
ATH Se utiliza para colgar una llamada después de haber sido
contestada
AT+CPAS Retorna el estado actual del teléfono (listo, desconocido,
llamada entrante, llamada en curso)
AT+CFUN Configura el modo de funcionamiento del módem, 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 posición de la
memoria del dispositivo
AT+CMGS Este comando es usado para originar un SMS
AT+CMGD Borra los SMS ubicados en alguna posición de la memoria
del dispositivo
AT+CMGL Crea una lista con los mensajes leidos, no leídos,
almacenados, o todos al mismo tiempo.
AT+IFC Configura el control del flujo de transmisión y recepción 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 comunicación entre un
dispositivo móvil o módem y el usuario a través de un terminal de
comunicación, 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 comunicación puede establecerse mediante la
norma RS-232 o simplemente usando señales lógicas TTL. Si usamos un
ordenador, podemos interactuar con el módem desde una aplicación
denominada Hiperterminal (como se muestra en la figura 15), que nos
permite enviar y recibir los comandos a través del puerto serial del
ordenador, desde donde podemos controlar todas las funciones del
dispositivo móvil (ZTE Command Manual, 2007).
45
Figura 15. Ventana de comunicación entre el hyperterminal y el módem
Realizado por: William Veloz
2.5. SISTEMAS DE PROTECCIÓN ANTIRROBO
Un sistema de protección antirrobo es un elemento de seguridad pasiva o
activa cuyo propósito es evitar en mayor medida el riesgo de pérdida de
propiedad privada mediante robo, dicha propiedad privada puede ser una
casa, un vehículo, un lote de joyas, etc. En este capítulo se va a estudiar
específicamente los sistemas de protección antirrobo vehicular.
2.5.1. ALARMAS PARA VEHÍCULOS
Las alarmas para vehículos, o sistemas de protección vehiculares son
dispositivos integrados de seguridad pasiva que se instalan en una unidad
vehicular para alertar el robo del vehículo, parte de él, o algún objeto que se
46
encuentre dentro del mismo. Están compuestas de: varios elementos de
entrada que se encargan de detectar la presencia o intención del intruso,
una central que se encarga de interpretar las señales de dichas entradas
para tomar decisiones y realizar procesos, y elementos de salida que emiten
una señal de alerta que puede ser audible o visible, o una combinación de
ambas, y en ciertos tipos de alarmas enviar información 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 vehículo, 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 añadir
elementos que funcionan como actuadores del sistema que habilitan o
inhabilitan ciertos sistemas e incrementan el nivel de seguridad del vehículo.
Uno de estos elementos más común es el que permite inmovilizar el vehículo
mediante un sistema de bloqueo automático, o remoto; de este modo el
sistema de protección activa un subsistema de bloqueo, el mismo que puede
ser mediante desconexión del sistema eléctrico, inhibición del cerebro, o
inhabilitación 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
protección que vienen instalados en los automotores por el fabricante del
mismo. Por lo general son alarmas estandarizadas y cumplen con el mínimo
de requerimientos para asegurar la integridad del vehículo. En ocasiones
son fabricadas por otra empresa, la cual las vende a la empresa fabricante
de vehículos para que ésta los distribuya bajo su marca (Wikipedia, Original
Equipment Manufacturer). Un ejemplo muy común 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 vehículos de fábrica, 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 vehículo no cuenta con una
alarma OEM, es posible instalar en su interior una alarma para vehículo 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 básicos 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 PROTECCIÓN ANTIRROBO
VEHICULAR
Por lo general las partes básicas que componen un sistema de protección
antirrobo son:
- Central de control (cerebro)
- Sensores
- Dispositivos de alerta
- Llave de activación/desactivación remota
- Batería auxiliar
- Inmovilizadores
49
Figura 18: Partes de un sistema antirrobo vehicular.
Fuente: www.honorio.com.ar
2.5.3.1. Central de control
Es el cerebro del sistema, por lo general, en su forma más básica se trata de
un equipo que contiene la circuitería 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 detección (sensores).
El cerebro se alimenta a través de la batería del automóvil, pero suele
además contar con una conexión a una batería de respaldo en caso de que
sea cortada la conexión con la batería del vehículo; de hecho, esto puede
ser indicio de la presencia de un intruso, en dicho caso el cerebro dispara las
señales de alerta (Auto radio Honorio, s.f.).
50
2.5.3.2. Sensores
Son los órganos de percepción del vehículo. Un sensor convierte una
magnitud física o química (generalmente no eléctrica), en una magnitud
eléctrica, 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 vehículo, y
cada uno puede representar un modo de detección diferente, y dependiendo
del nivel de confiabilidad y exigencia se pueden encontrar sensores a una
gran variedad de precios. A continuación describimos algunos de los más
comunes.
o Sensor de puerta
Es el elemento básico de un sistema de protección antirrobo. Su forma más
sencilla puede ser un simple interruptor que es presionado o activado
cuando una de las puertas (ya sea de pasajeros, maletero o capot del
vehículo) se cierra (NC), o se abre (NA). En los vehículos más 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 vehículo o encender la señal 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 vehículo ingresando por una de las puertas, pero serían
inútiles si éste decidiera ingresar por la ventana por ejemplo. Para ello un
sistema de protección antirrobo debe contar además con otro tipo de
sensores que incrementan la seguridad del vehículo.
o Sensores de choque
La idea de funcionamiento de un sensor de choque es sencilla: si alguien
golpea o mueve de alguna manera el vehículo el sensor de choque envía
una señal de alerta dependiendo de la severidad del movimiento. Esto evita
el riesgo de que el automóvil sea robado con un remolque (en cuyo caso no
serviría de nada un sensor de puerta ya que no habría necesidad de entrar
al vehículo para robarlo).
Un sensor de choque puede ser construido de muchas maneras, tal vez una
forma sencilla de hacerlo sería colocar un contacto metálico 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
dispararía la señal de alarma. El único inconveniente es que la central no
podría 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 más sofisticados que entregan
varias señales dependiendo de la magnitud del movimiento (López, E. &
Moya, V., 2009).
52
Figura 20: Sensor de choque.
Fuente: www.honorio.com.ar
El sensor de la figura 20 funciona de la siguiente manera: está compuesto
por un contacto central, una pequeña bola metálica, y unos contactos
secundarios. En estado de reposo, la bola metálica está tocando a la vez un
contacto secundario y el contacto central, cerrando así el circuito, e
indicando al cerebro que no hay ningún cambio externo. Cuando el vehículo
recibe una leve sacudida, la bola se separa momentáneamente 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 más contactos secundarios, así, basándose 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 más fuerte.
o Sensores de sonido
Un sensor de sonido es básicamente un micrófono que ha sido configurado
para responder a ciertos niveles de frecuencia solamente. Un micrófono
53
mide las variaciones en la fluctuación atmosférica y convierten este patrón
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 micrófono, y omite los demás sonidos en
un rango de frecuencia diferente. Se instalan en la parte interior del vehículo
(López, E. & Moya, V., 2009).
o Sensores de inclinación
Su funcionamiento es similar al de los sensores de choque, con la diferencia
de que éste sensor está enfocado a detectar específicamente la inclinación
de un vehículo cuando está tratando de ser remolcado.
Uno de los detectores de inclinación más comunes son los interruptores de
mercurio. El mercurio es un metal que a temperaturas ambiente se
encuentra en su forma líquida, es decir que fluye como el agua, pero aun así
conduce la electricidad como un metal sólido. Su construcción es básica 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 líquido, lo que abrirá el circuito. Basándose
en la lógica 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 inclinación.
Fuente: www.honorio.com.ar
o Sensores volumétricos
Este sensor es uno de los más 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.
Básicamente se compone de un transmisor y un receptor de ultrasonido, y
un transductor que transforma esa frecuencia de ultrasonido en un impulso
de corriente eléctrica. Se ubican en el interior del vehículo en la parte
superior del parabrisas apuntando en ángulo hacia atrás.
Su funcionamiento se basa en el principio de reflexión de ondas acústicas, y
se puede entender en la figura 22. Cuando un sonido es emitido por una
fuente se produce una fluctuación en la presión del aire y una forma de
energía denominada “onda acústica” se desplaza a través del aire en
dirección opuesta a la fuente que lo originó hasta desvanecerse; pero si un
obstáculo físico se interpone en la dirección de las ondas, estás “chocan” en
dicho obstáculo y “rebotan” en dirección opuesta, como un espejo (Auto
radio Honorio, s.f.).
55
Figura 22: Funcionamiento de un sensor de ultrasonido.
Fuente: www.honorio.com.ar
Este fenómeno puede ser aprovechado por los sensores de ultrasonido, los
cuales producen periódicamente una onda ultrasónica, la cual se desplaza
por el interior del vehículo y rebota en las paredes, vidrios, asientos del
vehículo. Luego el receptor de ultrasonido recibe la señal “rebotada” y mide
el tiempo que ésta demoró en ir y volver, con lo cual genera un patrón que
es utilizado para detectar cualquier cambio en el espacio físico dentro del
vehículo. Este sensor es muy útil si se rompe una ventana del vehículo o un
intruso ingresa al interior del vehículo. Aunque en realidad con estos
sensores no es posible medir el volumen real o espacio interior del vehículo
se dice que son volumétricos porque su respuesta depende mucho del
espacio físico en el interior del automóvil.
2.5.3.3. Dispositivos de alerta
Un sistema de protección antirrobo debe disparar algún tipo de alerta cuando
uno de los sensores se haya activado para dar aviso al propietario de que su
vehículo está en peligro de ser robado, y además, para disuadir al intruso de
su intento de robo.
56
Como mínimo la mayoría de las alarmas harán sonar el claxon y hacer
destellar las luces cuando se haya detectado el intento de robo, aunque, es
más común 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 vehículo de los de
otros. Los sistemas más sofisticados poseen un equipo que reproduce una
voz pregrabada con la intención 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 vehículo
Fuente: www.honorio.com.ar
2.5.3.4. Llave de activación y desactivación remota
La llave de activación y desactivación remota o también conocido como
control remoto funciona como un transmisor que envía una señal codificada
a un receptor instalado en el interior del vehículo y con cuyo código le
permite al sistema de protección saber si el usuario quiere activar la alarma
o desactivarla leyendo y autentificando dicho código, basta simplemente con
presionar un botón para enviar la señal. Normalmente se presentan como un
llavero para la llave de las puertas y encendido del vehículo, como se ilustra
en la figura 24.
57
Además de encender y apagar la alarma, algunos controles presentan la
opción 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 más sofisticados permiten incluso tener acceso
al cerebro del vehículo y bloquear el encendido del motor.
Figura 24: Control remoto de un sistema de seguridad vehicular.
Fuente: (López, E. & Moya, V., 2009)
Una llave de activación/desactivación remota funciona enviando a señal
modulada través de una radiofrecuencia (generalmente con un alcance de
hasta unos 50m dependiendo del fabricante) con un código que es
interpretado por el receptor; así para una determinada marca de alarmas
deben existir millones de códigos diferentes a fin de que cada alarma tenga
un código único y no pueda activar alarmas de otros vehículos cercanos. Sin
embargo éste método no es inviolable, ya que alguien podría usar un
detector de señales radiotransmitidas y grabarlo obteniendo así el código de
desarme original, el cual lo puede usar para desactivar la alarma desde otro
transmisor cualquiera. Para evitar este inconveniente sistemas más
actualizados utilizan algoritmos de codificación para hacer que el receptor
genere un nuevo código cada vez que la alarma es activada/desactivada,
éste nuevo código es encriptado y enviado al transmisor, y de ese modo
aunque alguien intente grabar el código de desarme, no será útil puesto que
58
en el siguiente proceso de activación/desactivación la alarma requerirá un
nuevo código.
2.5.3.5. Bateria auxiliar
O también llamada batería de respaldo, es una fuente de alimentación que
provee el voltaje necesario para abastecer el sistema de protección en caso
de que se desconecte la batería principal durante un tiempo razonable para
frustrar el intento de robo. Permanece inactiva mientras el sistema está
siendo alimentado con la batería principal y se carga de ésta si su nivel de
voltaje ha disminuido.
Generalmente los sistemas de alarma generan una señal de alerta cuando la
batería 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
protección antirrobo vehicular. Consiste básicamente en un dispositivo
electrónico que impide el accionamiento del motor de un vehículo 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 vehículo está siendo
robado, sino que realiza una acción 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 básicamente en el
método que utilizan para activar o desactivar el inmovilizador, y el método
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 vehículo con las llaves autorizadas. Intentarlo con cualquier otra llave
implica que el motor arranca, pero solo funciona durante algunos segundos
(en la mayoría 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
pequeño chip insertado en el mango de la misma (como se muestra en la
figura 26) y que emite un código por radiofrecuencia en el momento en que
se acciona el contacto. Este código es captado por una antena o unidad
lectora, normalmente ubicada en el conmutador de arranque. Si el código
enviado coincide con el código almacenado por la unidad receptora autoriza
el arranque del motor, caso contrario lo bloquea.
60
Figura 26: Llave de puerta del vehículo con chip transponder.
Fuente: (Sapia, 2002)
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 plafón del espejo retrovisor. La lógica 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 electrónica para habilitar o deshabilitar el accionamiento del motor del
vehículo.
Figura 27: Diagrama de bloques de un inmovilizador con comando infrarrojo.
Fuente: (Sapia, 2002)
61
o Inmovilizador con teclado numérico
Este sistema incorpora un teclado numérico cercano a la ubicación del
conductor, que puede estar en el tablero de comandos, o en la base del
volante. El conductor debe ingresar una clave de 4 dígitos para autorizar o
bloquear el accionamiento del motor del vehículo. En la figura 28 se ilustra el
esquema de este tipo de inmovilizador.
Figura 28: Diagrama de bloques de un inmovilizador con teclado.
Fuente: (Sapia, 2002)
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 dañarse el sistema quedaría inutilizable. Por otra parte la desventaja sería
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. METODOLOGÍA
63
En este capítulo se van a detallar los métodos y procesos que se deberán
llevar a cabo a fin de llegar a la consecución del sistema propuesto. Para ello
nos basaremos en los principio de la metodología de desarrollo de sistemas
mecatrónicos. Esta investigación comienza con el estudio de los comandos
AT para dispositivos móviles y el establecimiento de la comunicación entre
un módem GSM previamente seleccionado y un circuito de control cuyo
cerebro es un microcontrolador. El microcontrolador utilizado debe ser capaz
de proveer el número suficiente de puertos de entrada necesarios para
recibir la información de un sensor de activación, el módem GSM y un
indicador de estado de batería auxiliar; y así mismo el número de puertos de
salida necesarios para activar las salidas de alarma, bloqueo, y envío de
códigos al módem.
También se analizará sobre cuál será el método más efectivo para realizar el
bloqueo del automóvil; uno de los métodos puede ser la inhabilitación de la
bomba de combustible, y el otro, des-energización del sistema eléctrico y de
ignición, se debe tomar en cuenta factores determinantes como la
inviolabilidad del sistema, la seguridad física tanto de los ocupantes del
vehículo como del vehículo mismo y la factibilidad técnica de los métodos en
cuestión.
En el plano de control se estudiará el desarrollo de aplicaciones móviles para
dispositivos Android utilizando herramientas de programación que permitan
una comprensión fácil de la lógica de funcionamiento y adecuados niveles de
seguridad informática.
3.1. METODOLOGÍA MECATRÓNICA
En la figura 29 se muestra un diagrama de la metodología de diseño de
sistemas mecatrónicos, en donde se puede apreciar los pasos a realizar
desde la modelación y simulación de componentes mecánicos, pasando por
el diseño del sistema de control hasta la consecución de un prototipo final al
64
cual se le deben realizar las pruebas respectivas para valida el producto
final.
Figura 29. Esquema de la Metodología del diseño de sistemas mecatrónicos
Fuente: (Vargas, 2000)
3.1.1. REQUERIMIENTOS DEL PROYECTO
En esta sección se describen las características necesarias para el correcto
funcionamiento del sistema. Aquí se detallan los requerimientos de
acondicionamiento de señal de entrada, tanto GSM como sensores de
activación; arquitecturas de los dispositivos de control, y actuadores o
dispositivos de salida.
65
3.1.1.1. Acondicionamiento de señales de entrada
Las señales que el sistema debe recibir e interpretar son básicamente, el
pulso de corriente discreto proveniente del sensor que detecta la posible
alerta de robo; y los códigos de activación enviados a través de mensajes de
texto o SMS entre el módem instalado en el módulo del vehículo y el
dispositivo móvil del usuario. A continuación se va a detallar las condiciones
de operación de estas señales para el correcto funcionamiento del sistema
en su totalidad.
o Sensores de activación.
Los sensores de activación 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 más
posible a los verdaderos estados de peligro o seguridad, es decir que no
deben dar demasiadas falsas alarmas activándose con la más mínima
alteración, ni tampoco permanecer inactivos cuando realmente si exista
peligro de intrusión.
En este proyecto para fines demostrativos se utilizarán 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 señal solo se interpreta en estados lógicos altos y bajos, por lo que no es
necesario realizar un circuito amplificador de señal, simplemente bastará con
conectar la salida del sensor a la entrada del microcontrolador o a lo mucho
implementar un relé o circuito de conmutación 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 amplificación para el sensor de choque
o Red GSM.
Debido a que el sistema se basa en el control de una alarma a través de la
red GSM de una de las operadoras móviles del país 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 telefonía celular con tecnología 3.5G con niveles satisfactorios de calidad
de señal, transmisión de información y seguridad.
Servicios:
Este proyecto va a requerir del servicio de envío y recepción de mensajes
SMS a través de un dispositivo móvil, y del módem 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 móviles:
El dispositivo móvil que controla el sistema es parte fundamental del
proyecto, ya que no sería posible en cualquier equipo instalar una aplicación
con una interfaz gráfica y de control. Se utilizará un teléfono móvil cuyo
software corra sobre una plataforma Android, debido a la gran acogida y
proyección que han mostrado éstos dispositivos en los últimos años, además
de ser desarrollados como software libre y presentar características loables
como su accesibilidad, flexibilidad, velocidad, etc. frente a otras plataformas.
En la siguiente tabla se observan algunas diferencias entre los sistemas
operativos más utilizados en el mundo.
Tabla 8. Diferencias entre algunos sistemas operativos Móviles.
Plataforma
Windows Phone 7 Windows Mobile 6.5 iPhone OS 1.0 iOS 4.0 Android Symbian Maemo 5
Requerimientos mínimos 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
Multitáctil Si No Si Si Si Si Si
Fragmentación 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 módem GSM que va a ser instalado en el vehículo como parte del circuito
electrónico de control del sistema de alarma, debe cumplir con las
especificaciones siguientes:
69
- Tecnologías de soporte: GSM/GPRS
- Banda de frecuencia: 850 MHz
- Baud rate: 115200 bauds
- Tensión de alimentación: 12 VDC
- Conexión para antena
Tarjeta SIM.
Las tarjetas SIM instaladas tanto en el dispositivo móvil como en el módem
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
Fuente: www.claro.com
Cobertura de red.
El proyecto en cuestión será desarrollado y aplicado en la ciudad de Quito,
por lo que se requiere que el sistema de telefonía 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 móvil en la provincia
de Pichincha.
Tabla 9. Cobertura celular en la provincia de Pichincha.
PROVINCIA CIUDAD/POBLACIÓN CANTÓN 1W ó 2W
PICHINCHA Alangasí Quito 1W
70
PICHINCHA Amaguaña 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 señal en la población indicada son óptimos y permite que los usuarios tengan muy buena cobertura en cualquier punto de la población indicada, aun dentro de casas y domicilios.
Cobertura 2W: significa que los niveles de señal en la población indicada son buenos, por tanto se garantiza cobertura solo en exteriores y lugares abiertos dentro de la población indicada. Los niveles de señal no permiten garantizar cobertura dentro de casas y edificios.
Fuente: www.claro.com
3.1.1.2. Sistema de control
o Microcontrolador.
Un microcontrolador es un dispositivo electrónico encapsulado en forma de
chip, el cual puede realizar varias tareas según 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 información y procesamiento, ya que
comparte características como CPU, memorias, ALU, etc., pero no posee
ningún periférico de entrada o salida.
Un microcontrolador es un elemento muy versátil ya que permite escribir ý
borrar instrucciones sobre su memoria EEPROM un elevado número 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
electrónico encargado de leer el estado de los sensores de entrada,
72
establecer comunicación con el módem, y controlar las salidas
correspondientes.
Tabla 10. Tabla de comparación PIC16f628a y PIC16f877a
Características PIC16f628a PIC16f877a
Máxima frecuencia de operación (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
Línea de E/S 16 Ptos. A, B, C, D, E
Módulos de comparación/Captura/PWM
(CCP)
1 2
Comunicación 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 técnica del PIC16f628a, PIC16f877a )
73
Como se observa en la tabla 10 el PIC16f628a cumple con los
requerimientos básicos para este proyecto, por lo cual va a ser éste el que
se utilice para la construcción 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 técnica del PIC16f628a)
74
o Sistema operativo móvil
Como se mencionó anteriormente el sistema operativo del dispositivo móvil
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 características del dispositivo móvil elegido son las
siguientes:
- Marca: Motorola
- Modelo: XT316
- Versión de Android: 2.3.4 (Gingerbread)
- Versión de núcleo: Apps_2.6.32.9
- Versión de banda base: PR2
- Tipo de red móvil: HSDPA
Figura 33. Teléfono móvil Motorola XT316
Fuente: www.claro.com
La figura 13 del capítulo 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.- específicamente en la sección de Developer Apps,
ya que no se realizará ninguna modificación de las aplicaciones
existentes, solamente se creará una nueva aplicación.
Application framework.- Se utilizaran algunos de los métodos e instrucciones
de ésta capa para desarrolla nuestra aplicación.
3.1.1.3. Actuadores y dispositivos de salida
Este proyecto va a tener como función determinante la de bloquear el
vehículo 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 vehículo se bloquea o no. Primeramente se debe determinar
el significado “bloqueo”, el cual selo puede definir como un “método de
seguridad vehicular en el que se inhabilita la movilidad del vehículo por
personas no autorizadas”, es decir que al bloquear un automóvil, éste no
puede arrancar, o si ya ha arrancado, se apagará el motor y no podrá
arrancar nuevamente.
Existen varios métodos de bloqueo de vehículos, entre ellos está el método
bloqueo por apertura del sistema eléctrico y de ignición, y el método de
bloqueo por corte de flujo de combustible.
o Bloqueo del vehiculo (sistema eléctrico)
En la figura 34 se aprecia un esquema simplificado del sistema eléctrico de
un vehículo. Las principales partes que componen el sistema eléctrico de un
vehículo son:
- Fuente de alimentación o Batería
- Llave de encendido
76
- Bobina
- Condensador
- Ruptor
- Distribuidor
- Bujías
- Cables de baja y alta tensión
Figura 34. Sistema de encendido e ignición de un automóvil
Fuente: www.automecánico.com
El funcionamiento del sistema de encendido automotriz es sencillo. Se basa
en la producción alterna de alto voltaje de forma periódica para producir una
chispa en los cilindros del motor de modo que se produzca la explosión que
da lugar al movimiento continuo de los pistones del motor. Una batería 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 eléctrica circula a través
del bobinado primario de la bobina, el ruptor se encarga de abrir y cerrar
periódicamente los contactos o platinos que a su vez permiten o cierran el
paso de la corriente a través de la bobina. La función del condensador es de
77
permitir un rápido 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
magnético, 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 bujías del motor a través del distribuidor, el cual es encargado de
seleccionar a cual bujía se debe enviar la corriente de la bobina mediante un
sistema de selección rotativo (rotor).
Como se puede notar, el elemento principal del sistema de encendido
eléctrico e ignición es la bobina, por lo que al suprimir la alimentación de
energía a este elemento es posible bloquear el vehículo. El circuito de
bloqueo se vería como se muestra en la figura 35.
Figura 35. Esquema de interfaz con relé
Fuente: www.ucontrol.com
La señal de datos provendría del microcontrolador y los contactos del relé se
encargarían de abrir el paso de la corriente a través de la bobina
produciendo así el bloqueo del vehículo.
78
3.1.2. DISEÑO MECÁNICO
Evidentemente este proyecto no incurre muy profundamente en el desarrollo
de un componente mecánico debido a que el sistema es controlado
enteramente por los componentes electrónico y de control. Sin embargo al
ser un proyecto de aplicación en el campo automotriz, es importante conocer
el funcionamiento básico de un vehículo y los fenómenos físicos, mecánicos
y eléctricos 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 vehículo a gasolina con motor de
combustión interna
Un automóvil es una máquina de transporte de personas u objetos
autopropulsado gracias a un motor de combustión interna en el caso de los
vehículos que utilizan combustibles fósiles, o por un motor eléctrico.
Un vehículo con motor de combustión interna posee los siguientes sistemas:
o Motor
Es el componente principal de un vehículo; es el mecanismo encargado de
proporcionar el movimiento rotatorio que mueve las ruedas del vehículo.
Funciona en base a la combustión de una mezcla de aire y gasolina
producida en una cámara cilíndrica, ésta explosión impulsa los pistones que
junto con las bielas y el cigüeñal transforman el movimiento rectilíneo
alternativo en un movimiento circular. La gasolina es bombeada desde el
depósito de combustible al motor pasando por un proceso de filtrado, y
depuración. El proceso cíclico de funcionamiento del motor se divide en
cuatro etapas principales que son: admisión, compresión, explosión y
escape; por esta razón a estos motores también se los denomina Motores de
cuatro tiempos.
79
o Sistema de ignición
También llamado sistema eléctrico, 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 bujías 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 energía para mover el
pistón 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 (batería) del vehículo, 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
combustión interna es el elemento principal de un vehículo y sin cuyo
correcto funcionamiento el vehículo resultaría incapacitado para moverse por
si mismo. En consecuencia existen dos métodos convencionales para
realizar el bloqueo del vehículo: Deshabilitar la bobina del sistema de
ignición, o Deshabilitar la bomba de gasolina. En el primer caso, al des-
energizar la bobina de ignición, se elimina el alto voltaje que es aplicado a
las bujías que encienden la mezcla, en consecuencia no hay explosión de la
mezcla y el motor del vehículo se apaga ocasionando el paro y bloqueo del
vehículo. En el segundo caso, se deshabilita la bomba de gasolina, lo que
impide la circulación de gasolina hacia el motor apagándolo en cuestión de
segundos. Cualquiera de las dos opciones es válida para este proyecto, sin
embargo se ha escogido hacerlo mediante el método de la bobina debido a:
- Es el método convencional más utilizado en los sistemas de bloqueo
vehicular.
- Facilidad de instalación, ya que se lo realiza cerca del tablero de
mandos del vehículo, en donde se pueden realizar las respectivas
conexiones.
80
Es más difícil de detectar y realizar un bypass.
3.1.3. DISEÑO ELECTRÓNICO
En esta sección se analizará el funcionamiento del circuito electrónico y de
control del proyecto. Para entender el funcionamiento de las diferentes
partes del circuito electrónico se ha realizado el siguiente diagrama de
bloques (figura 36) que representa como se encuentra diseñado el circuito.
Figura 36. Diagrama de bloques del proyecto.
3.1.3.1. Circuito de adquisición de señal 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 envían un
valor de voltaje que cambia dependiendo de la condición 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 más común es encontrar sensores con salidas de voltaje en niveles TTL,
esto quiere decir que un estado lógico “bajo” se representará mediante un
valor de 0V y un estado lógico “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 estándar utilizado en las
alarmas marca Nemesis® distribuidas en almacenes de accesorios para
autos. Este sensor detecta cualquier vibración física que rompa la inercia en
su entorno, y puede ser regulado para ajustar su sensibilidad. Cuando no
detecta ninguna vibración el sensor envía a su salida un valor de voltaje de
5V aproximadamente. Al detectar una vibración 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 diseño del circuito de
adquisición de la señal del sensor de choque, lo cual se va a describir en
detalle en el siguiente capítulo.
3.1.3.2. Circuito de comunicación con el módem
El cerebro del circuito electrónico es el PIC16f628a. Uno de los principales
sub-sistemas del circuito electrónico es el de la comunicación serial
microcontrolador -> módem y viceversa. Existen algunos métodos para
realizar la comunicación, como el de la comunicación paralela, y el de la
comunicación serial, que son los más comunes. En este caso se realizará
mediante comunicación serial utilizando la norma RS-232 ya que es el
método más utilizado y su ventaja respecto a la comunicación paralela es
83
que no requiere de muchas líneas de transmisión (una por cada bit),
simplemente se hace la comunicación a través de una línea de transmisión y
una de recepción, por lo que no ocupa muchos puertos del microcontrolador.
Existen dos tipos de comunicación serial, la síncrona, y la asíncrona, en la
primera se requiere de una señal de reloj que sincronice tanto al receptor
como al transmisor para hacer coincidir el tiempo de duración de cada bit, a
diferencia de la asíncrona, en la cual no existe la señal de reloj sino que se
define previamente en el transmisor y receptor la duración 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
usarán 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 técnica del PIC16f628a)
3.1.3.3. Circuito de salida del relé para bloqueo del vehículo
Esta parte del circuito nos permitirá realizar el bloqueo del vehículo mediante
una salida de relé, cuyos contactos actuarán como un interruptor general en
el sistema eléctrico de ignición del vehículo. Básicamente el relé abrirá y
cerrará el paso de corriente a través del bobinado primario de la bobina de
encendido que se encarga de entregar el alto voltaje para la producción del
chispeo en las bujías del motor.
Ya que el elemento más relevante en el sistema eléctrico del vehículo es la
bobina, hay que tomar en cuenta las características de ésta al momento de
diseñar un sistema de corte para ésta. El método más común es el del uso
de un relé o interruptor electromecánico. En este circuito el microcontrolador
enviará una señal de activación a un relé; y sus contactos se conectarán en
serie a la bobina de encendido, entonces, es necesario determinar los
parámetros de relé, tanto de la bobina del relé como de sus contactos.
- Tensión de alimentación del relé: 5V
- Corriente de consumo de la bobina del relé: 200mA
85
Para determinar la corriente máxima que deben soportar los contactos del
relé se debe calcular cual será la corriente de consumo de la bobina de
encendido.
3.1.4. DISEÑO 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 simultáneos 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 lógica de
funcionamiento de la aplicación Android móvil. Para cada una de ellas se va
a detallar su lógica de programación, diagrama de flujo y conjunto de
instrucciones.
3.1.4.1. Programa del microcontrolador PIC16f6281
o Funcionamiento
El circuito electrónico 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 información desde y a través del
módem GSM y bloqueando el vehículo en caso de ser requerido. Para ello el
sistema electrónico cuenta con un procesador de información 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 propósitos específicos de cómputo y almacenaje de
información.
Para entender mejor el funcionamiento de este proyecto se definirán algunos
conceptos utilizados en la programación del mismo.
86
Variable de entrada/salida
Corresponde a un espacio físico dentro de la memoria del microcontrolador
donde se guarda la información 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 físico dentro de la memoria del microcontrolador que
almacena información que se utiliza en diferentes partes del programa del
mismo para efectos de cómputo, 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 condición actual del
mismo informando al sistema en sí que variables utilizar y la información que
debe esperar para realizar una determinada acción. En el sistema se han
definido cuatro estados posibles que se explican a continuación.
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
batería del vehículo, el programa carga en si las variables necesarias,
ejecuta algunas instrucciones para preparar el módem y luego entra en este
estado. Cuando el sistema se encuentra en este estado no detectará
ninguna alerta de intrusión aunque exista una respuesta del sensor;
solamente estará en espera de un mensaje con el código de activación
correcto para pasar al siguiente estado (Alarma Encendida), y en caso de
recibir un mensaje con un texto diferente al esperado lo borrará del buzón de
entrada del modem.
El estado “Alarma Apagada” generalmente se establece cuando no se desea
tener control sobre la seguridad del vehículo, o si el automóvil se encuentra
en movimiento, o encendido, o hay personas dentro del mismo.
Estado: Alarma Encendida/Vehículo desbloqueado. El sistema entra en
este estado una vez que ha recibido el mensaje con el código de encendido.
A partir de este estado, el microcontrolador comienza a escuchar los
sensores de activación, lo que hará que el sistema pase al estado de
“Alerta”, además está en espera de un mensaje con el código para apagar la
alarma. También puede establecerse este estado cuando se ha
desbloqueado el vehículo posteriormente al estado de bloqueo.
Para establecer este estado, el vehículo debe estar apagado, permanecer
inmóvil, y libre de ocupantes, puesto que el estado de alerta se activaría
inmediatamente.
Estado: Alerta de robo. Cuando la alarma está encendida sus sensores
están detectando si existe algún cambio exterior que pueda significar una
alerta de robo, de darse el caso, enviarán una señal al microcontrolador lo
que hará que se inicie el estado de “alerta”, esto implica que el
microcontrolador enviará un mensaje de texto al móvil que contiene instalada
la aplicación de control, de ese modo la aplicación indicará al usuario que
88
existe una alerta de robo y así él puede tomar una decisión sobre si bloquear
el vehículo, o simplemente apagar la alarma.
Estado: Vehículo bloqueado. El sistema entra en este estado si una vez
que se ha iniciado el estado de “alerta” recibe un mensaje con el código de
bloqueo correcto, ya que si recibe un mensaje con un texto diferente al
esperado simplemente lo borrará del buzón de entrada del módem. Una vez
en este estado, el sistema simplemente esperará un mensaje para
desbloquear el vehículo, procedimiento que debe realizarse solo cuando se
haya recuperado el automóvil.
Cuando se realiza el bloqueo desde la aplicación móvil 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.
Códigos de activación.
Los códigos de activación son cadenas de caracteres específicas
transmitidas mediante mensajes de texto enviados desde el móvil que tiene
instalada la aplicación del sistema de seguridad. El propósito de los códigos
es mantener un carácter secreto acerca de la forma de controlar el sistema
desde la aplicación móvil, ya que de ese modo se puede evitar el
arme/desarme del sistema por parte de terceras personas desde otros
móviles.
Con fines demostrativos, a continuación se presentará una lista (tabla 11)
con los códigos de activación y su respectivo propósito; claro está, que
organizacionalmente, los códigos de activación deben ser administrados
como información extra confidencial.
89
Tabla 11. Códigos de activación
Código Nombre Descripción
+01 Encender Enciende la alarma, sus sensores están a la
espera de algún cambio.
+02 Apagar Apaga la alarma.
+03 Verificar Envía un mensaje al microcontrolador para que
éste envíe un mensaje de respuesta con el estado
en que se encuentra.
+07 Bloquear Bloquea el vehículo. La alarma no puede ser
apagada.
+08 Desbloquear Desbloquea el vehículo. El sistema vuelve al
estado de encendido.
3.1.4.2. Programa de la aplicación móvil
Una aplicación móvil es un programa instalado en un dispositivo móvil,
diseñado para realizar uno o más trabajos con un propósito específico. En el
presente proyecto la aplicación tiene la finalidad de controlar el sistema de
seguridad instalado en el vehículo, estableciendo comunicación con el
módem GSM que forma parte de la circuitería del sistema, y avisando al
usuario mediante etiquetas el estado tanto de la alarma como del vehículo.
La aplicación ha sido diseñada 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 más
comunes es a través de un entorno Java®, obviamente utilizando el lenguaje
de programación 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 más comunes y completos para el desarrollo de
aplicaciones es el Eclipse IDE®. Como ventajas de este software se puede
decir que presentan más opciones y características al momento de
programar, además de obtenerse aplicaciones más 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 programación más
simplificada, con una interfaz gráfica más amigable para el usuario, con un
juego limitado de instrucciones y características 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 Tecnológico de Massachusetts) y potenciada por Google®, la
empresa que desarrolló el sistema operativo Android para dispositivos
móviles. Para acceder a esta herramienta simplemente basta con entrar a la
página del AppInventor que es la siguiente: http://appinventor.mit.edu/, en
ella se encuentra disponible toda la información necesaria para iniciar con el
desarrollo de aplicaciones móviles. El procedimiento que se sigue consiste
en ingresar con una cuenta de Google (si no se tiene cuenta se puede crear
una) en la página antes mencionada, descargar e instalar algunos
complementos para el desarrollo, y realizar las configuraciones que la
herramienta requiere.
Para comprender el desarrollo de la aplicación móvil primeramente se
explicarán unos conceptos referentes al tema.
o App Inventor Designer
Es el área de diseño y trabajo donde se seleccionan los componentes que
van a formar parte de la interfaz gráfica de la aplicación. Dentro de los
componentes más utilizados se tienen los siguientes:
Botones (button)
91
Etiquetas (label)
Cuadros de texto (texbox)
Pantalla (screen)
Imágenes (image)
Lienzos (canvas)
Camara (camera)
Reproductores de audio (player)
Llamada telefónica (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 código de programación
que definirá como se comportan los componentes de una aplicación. Aquí se
crea el programa mediante el armado de bloques de construcción, tal como
si se tratara de un rompecabezas. Cada bloque representa una instrucción,
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 definición
Bloques de eventos
Bloques de procedimientos
Bloques de control
Bloques de datos
92
La forma en cómo se relacionan la paleta de diseño 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. SIMULACIÓN
Se puede decir que simulación es un proceso en el cual mediante un
ordenador se pone a prueba el modelamiento de un sistema real usando
métodos numéricos y modelos matemáticos, a fin de tener una estimación
del comportamiento del sistema en la vida real.
93
En Mecatrónica es muy importante la simulación, puesto que esto nos
permite observar y analizar los sistemas antes de poner en ejecución el
proceso de construcción de los mismos. Existen diversos programas para
realizar simulación de sistemas mecánicos, electrónicos, eléctricos,
neumáticos, etc. En este proyecto se va a realizar la simulación del
subsistema electrónico, es decir todo lo que representa la parte electrónica,
incluyendo el funcionamiento del microcontrolador, su comportamiento ante
la reacción de los sensores de entrada, la comunicación con el módem y su
respuesta expresada en los actuadores de salida.
Algunos de los software de simulación mas utilizados son el Proteus® de
Labcenter, el entorno de desarrollo integrado MatLab® de MathWorks, o el
Electronics Workbench® de National Instruments. A continuación se
presentan algunas de las características más 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.
- Interactuación del código fuente con hardware simulado en tiempo
real
- Modelos de periféricos interactivos para displays, teclados, etc.
- Más de 8000 modelos de dispositivos digitales y análogos.
- Extensas facilidades de depuración, incluyendo amplios diagnósticos
del sistema.
- Trabaja con los más populares compiladores y ensambladores.
Fuente: www.labcenter.com
94
o MatLab R2012b
- Entorno para modelado y simulación de sistemas mecánicos,
eléctricos, hidráulicos, térmicos y otros sistemas físicos de
multidominio.
- Bibliotecas de bloques de modelado físico y elementos matemáticos
para el desarrollo de componentes personalizados.
- Lenguaje SIMSCAPE basado en MatLab®, para la creación basada
en texto de componentes de modelado físico, dominios y bibliotecas.
- Capacidad para simular modelos que incluyen bloques de productos
relacionados con la modelación física sin tener que comprar esos
productos.
- Soporte para la generación de código C.
Fuente: www.mathworks.com
o Electronics Workbench
- Cada esquema listo al instante para simulación
- Características únicas, facilidad de uso y funcionalidad avanzada
- Disponible como herramientas de diseño autónomas o como parte de
un conjunto integral
- Habilidad para diseñar mejores circuitos en menos tiempo
- Simulador de circuito interactivo
Fuente: sine.ni.com
El software elegido para realizar la simulación del circuito electrónico es el
Proteus versión 7.7 debido a que ofrece soporte para simulación de circuitos
con microcontroladores PIC en tiempo real. Además no se realizará ninguna
simulación de algún sistema mecánico o cualquier otro sistema físico, por lo
que no es necesario utilizar el MatLab. Por otro lado Electrónic Worbench
presta facilidades de uso y funcionalidades mejoradas pero no incluye el
soporte para simulación de microcontroladores.
1
4. DISEÑO
96
En este capítulo se describirá el diseño, simulación y construcción de cada
uno de los componentes del producto mecatrónico, que como se sabe
consta de tres partes fundamentales. La primera parte es el sistema
mecánico, en la cual se definen las condiciones de operación del sistema
referentes a los procesos mecánicos que se llevan a cabo en el vehículo en
el cual es instalado el sistema de seguridad aquí propuesto. La segunda
parte es el sistema electrónico que consiste en el diseño de un circuito
electrónico capaz de funcionar como interfaz entre los sistemas mecánico y
de control mediante la utilización de un microcontrolador y sus puestos
necesarios. La siguiente parte es la de control, en ella se definen el conjunto
de instrucciones lógicas necesarias para la correcta operación del
microcontrolador del circuito electrónico y el desarrollo de una aplicación
móvil que permita al usuario tener control sobre el sistema en conjunto.
4.1. DISEÑO Y SIMULACIÓN DEL COMPONENTE
ELECTRÓNICO
El componente de control se diseñará para que realice las siguientes
funciones: Leer una señal proveniente de un sensor que detecte un cambio
en el entorno del vehículo (cuando esté estacionado y con su alarma
activada) que signifique una posible alerta de robo, establecer comunicación
serial con un módem GSM®, y bloquear electrónicamente el vehículo.
Básicamente se compone de un circuito electrónico diseñado para ser
ensamblado e instalado dentro de un case donde también se ubica el
módem, el relé de bloqueo del sistema eléctrico del vehículo y los terminales
para sus conexiones. El circuito electrónico alberga todos los componentes
electrónicos de control necesarios para la comunicación entre el
microcontrolador y el módem, incluyendo la etapa de regulación de voltaje, el
circuito integrado MAX232, los circuitos de entrada de señal proveniente del
sensor y circuitos de salida. A continuación se describe en detalle el diseño y
simulación cada uno de los subsistemas del componente electrónico.
97
4.1.1. CIRCUITO DE ADQUISICIÓN DE DATOS
Este circuito recibe una señal discreta que representa el estado de seguridad
de la alarma; como se describe en el capítulo anterior, el sensor de choque
envía a su salida un valor de voltaje entre 5 y 12 voltios (dependiendo de la
marca y tipo de sensor) cuando no detecta ninguna vibración física, y un
valor de 0 voltios cuando ha detectado alguna vibración externa. Esto implica
que ya sea el circuito de adquisición de la señal o el programa del
microcontrolador que va a recibir esa señal debe trabajar con una lógica
inversa. En este caso, el circuito de adquisición de señal va a trabajar
normalmente como un circuito de paso sin invertir la señal, pero en el
programa se va a tomar el 0 lógico como un valor “alto” y el 1 lógico como un
valor “bajo”.
El circuito de adquisición de señal funciona básicamente con un transistor
NPN común, 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 señal exista presencia
de voltaje. El circuito propuesto es el siguiente:
Figura 42. Circuito de polarización de un transistor NPN
La batería B1 representa el voltaje de alimentación del circuito electrónico,
provisto por el transistor regulador de voltaje L7805; La fuente de voltaje B2
Q12N3904
D5
1N4004
R2
10k
R610k
12
B15V1
2
B212V
98
es el equivalente al voltaje proveniente del sensor que puede estar entre 5 y
12V, para efectos de cálculo 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 (según hoja técnica del pic16f628a); El voltaje de salida
del circuito de adquisición de señal 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 declaración a un transistor se tiene que:
Dónde:
IE es la corriente del emisor, IB es la corriente de base e IC es la corriente de
colector.
La fórmula para calcular la corriente de base del transistor es la siguiente.
Dónde:
B2 es el voltaje de la batería de 12V, VD es la caída de voltaje en el diodo
que es 0,7 para diodos de silicio ideales (aunque en la hoja técnica del diodo
1N4004 ese valor fluctúa entre 0,6 y 1,1) y VBE 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 saturación 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 (IC = 10mA, VCE =
1.0V) de 100.
(
)
Remplazando los valores de IB e IC en la ecuación 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 adquisición de la señal del sensor, tomando en cuenta el
diseño realizado, se muestra en la figura 43.
100
Figura 43. Circuito de adquisición de datos
4.1.2. CIRCUITO DE COMUNICACIÓN
Este circuito como su nombre lo indica establece una comunicación serial
entre el microcontrolador (PIC16f628a) y el módem GSM®. Existen
diferentes métodos para establecer comunicación serial usando un
microcontrolador, sin embargo, como se utilizará la norma RS-232 (esto
debido a que el puerto de comunicación del módem 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 electrónico de la parte de comunicación serial es un circuito
normalizado, configurado para funcionar en condiciones regulares, para lo
cual requiere de cuatro capacitores electrolíticos conectados como se
muestra en la figura 44.
RA7/OSC1/CLKIN16
RB0/INT6
RB1/RX/DT7
RB2/TX/CK8
RB3/CCP19
RB410
RB511
RB6/T1OSO/T1CKI12
RB7/T1OSI13
RA0/AN017
RA1/AN118
RA2/AN2/VREF1
RA3/AN3/CMP12
RA4/T0CKI/CMP23
RA6/OSC2/CLKOUT15
RA5/MCLR4
U1
PIC16F628A
Q12N3904
1
2
3
J3
TBLOCK-I3
D51N4004
R2
10k
R610k
12V
101
Figura 44. Circuito de comunicación serial
Fuente: (Reyes C. 2008)
Los pines del puerto USART utilizados por el PIC16f628a para recibir y
enviar información son los terminales RB1 (pin 7) y RB2 (pin 8)
respectivamente. Además para poder trabajar a las altas velocidades de
transmisión 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 operación.
RA7/OSC1/CLKIN16
RB0/INT6
RB1/RX/DT7
RB2/TX/CK8
RB3/CCP19
RB410
RB511
RB6/T1OSO/T1CKI12
RB7/T1OSI13
RA0/AN017
RA1/AN118
RA2/AN2/VREF1
RA3/AN3/CMP12
RA4/T0CKI/CMP23
RA6/OSC2/CLKOUT15
RA5/MCLR4
U1
PIC16F628A
X1
CRYSTAL
C122p
C222p
T1IN11
R1OUT12
T2IN10
R2OUT9
T1OUT14
R1IN13
T2OUT7
R2IN8
C2+
4
C2-
5
C1+
1
C1-
3
VS+2
VS-6
U2
MAX232
C310u
C4
10u
C510u
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 tensión de alimentación necesaria para
accionar un relé que abre o cierra sus contactos para permitir la circulación o
no circulación de corriente a través del bobinado primario de la bobina de
encendido del vehículo. La tensión de alimentación de la bobina de
encendido es la misma tensión entregada por la batería del vehículo, 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
cálculo se tomará el menor valor, es decir 0,9Ω, ya que esto da como
resultado la corriente máxima que deben soportar los contactos del relé.
Esto quiere decir que el valor mínimo de corriente que los contactos del relé
deberían soportar es de 13A, sin embargo los relés 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 máxima es de 40A (hoja técnica 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
protección al circuito de las corrientes de rebote generadas por el campo
magnético de la bobina.
4.1.4. DISEÑO DEL PBC DEL CIRCUITO ELECTRÓNICO
Para realizar el diseño del circuito impreso o PBC (Printed Board Circuit), se
utilizó la herramienta Proteus® de Labcenter Electronics partiendo del
diagrama esquemático de todos los circuitos diseñados en los puntos
anteriores. El diagrama esquemático completo se muestra en anexo 1, el
cual ha sido diseñado en el programa ISIS, para ser simulado y luego
transferido al programa ARES, que es una herramienta para el diseño del
PBC. Hay que tomar en cuenta que el tamaño del circuito impreso no debe
ser demasiado grande, ya que esto hace que ocupe mucho espacio; ni
demasiado pequeño, porque esto puedo causar conflictos en el diseño y
crear problemas al generar pistas de cobre muy unidas o muy delgadas.
Otro aspecto a tomar en consideración, es que se debe evitar en lo posible
la creación de puentes en el circuito impreso, ya que no es un procedimiento
técnicamente correcto. El diseño del PBC se observa en el anexo 2.
RA7/OSC1/CLKIN16
RB0/INT6
RB1/RX/DT7
RB2/TX/CK8
RB3/CCP19
RB410
RB511
RB6/T1OSO/T1CKI12
RB7/T1OSI13
RA0/AN017
RA1/AN118
RA2/AN2/VREF1
RA3/AN3/CMP12
RA4/T0CKI/CMP23
RA6/OSC2/CLKOUT15
RA5/MCLR4
U1
PIC16F628A
R1
4k7
RL1G2R-1E-DC5
Q12N3904
D11N4004
104
4.2. DISEÑO Y SIMULACIÓN DEL COMPONENTE
ELECTRÓNICO
Se puede definir al componente de control como todo recurso de
programación utilizado para controlar el sistema de acuerdo a los
requerimientos planteados bajo ciertos estándares de operación.
Anteriormente se mencionó que en este proyecto existen básicamente dos
componentes de control, uno de ellos es el conjunto de instrucciones
programado en el PIC16f628a que controla todo el circuito electrónico del
sistema; el otro componente de control se encuentra embebido en una
aplicación desarrollada para dispositivos móviles Android®, y es el que se
encarga de definir el comportamiento de la misma, haciendo posible la
comunicación entre el circuito electrónico y el dispositivo móvil, y procesando
a su vez dicha información.
4.2.1. DISEÑO DEL PROGRAMA PARA EL PIC16f628a
El programa para el PIC16f628a es el conjunto de instrucciones lógicas
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
interacción del PIC con sus dispositivos y periféricos 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 capítulo anterior, se
observa que el microcontrolador debe estar en capacidad de adquirir la
información 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 más relevante del circuito se encuentra en el sistema de
comunicación entre el microcontrolador y el módem, es por eso que a
continuación se describe en detalle algunas de las instrucciones más
importantes del programa relativas a dicha comunicación, y su lógica de
funcionamiento.
o Comunicación asíncrona
Para establecer la comunicación asíncrona entre el microcontrolador y el
módem se usará el puerto USART del PIC16f628a, el cual establece un
medio por donde se va a transmitir y enviar la información; debido a esto no
es necesario definir los pines que se utilizarán para la comunicación 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 recepción de datos
DEFINE HSER_TXSTA 24h: Habilita el registro de transmisión
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
automáticamente.
Una vez definida la configuración del puerto USART en el PIC16f628a se
puede utilizar las declaraciones de envío y recepción de datos para
comunicación serial que son HSERIN y HSEROUT. Estas instrucciones se
explicarán analizando el siguiente extracto del programa línea por línea.
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
Descripción del programa línea por línea:
1. El subprograma etiquetado como “inicio” comienza su rutina.
2. La instrucción HSERIN hace que el microcontrolador se encuentre en
espera de algún dato serial (proveniente de un SMS entrante en el
módem), para ello espera un tiempo de 200 ms, si durante ese tiempo
no recibe ningún dato el programa se dirige hacia el lugar etiquetado
como “inicio”, es decir regresa a la línea anterior y se repite el
proceso. Si en el tiempo de espera el microcontrolador recibió algún
dato, lo lee y lo almacena en una variable tipo String denominada
“modem”, luego pasa a la siguiente línea de código. El comando
“WAIT” se utiliza para esperar una porción específica 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 información necesaria para el funcionamiento del
programa.
3. La instrucción HSEROUT envía 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 posición; esto se hace para evitar que se
llene el buzón de entrada del modem. Los comandos AT utilizados en
el programa serán detallados más 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 instrucción de la línea 5,
caso contrario se salta ese paso y continúa con la línea 6 que cierra la
instrucción 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 información útil entre el
microcontrolador y el módem GSM®. Los comandos AT utilizados son los
siguientes:
Comandos de configuración del módem
AT+CMGF=1: Configura los SMS’s del módem en modo texto. Permite leer
los mensajes de texto mediante tus caracteres reales, si no estuviera
configurado de esa manera el microcontrolador recibiría información que no
podría ser interpretada.
AT+IFC=0,0: Configura la comunicación con el módem en modo asíncrono.
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 presentación de los mensajes será diferente y habrán
conflictos en la lectura de los mismos.
Comandos de operaciones con SMS
+CMT: Esta es una porción de la cadena de caracteres que es enviada
desde el módem hacia el microcontrolador cuando llega un SMS. Es un
indicador de recepción de un mensaje de texto nuevo.
108
AT+CMGD=1: Este comando borra un SMS ubicado en una posición de la
memoria del módem. En este caso se borra el SMS de la primera posición.
AT+CMGS=”xxx”: Este comando es usado para generar un mensaje de
texto desde el módem para luego enviarlo.
AT+CMGL=…: Este comando se utiliza para solicitar al módem que
presente en una lista los mensajes requeridos que estén almacenados en la
memoria del módem.
Otros comandos AT
+CFUN: 1: Se emplea este comando para avisar al microcontrolador que el
módem está encendido y con todas sus funciones activadas. Permite al
programa saber cuándo debe iniciar con su rutina, ya que si el programa
arranca sin este aviso, es posible que el módem no reciba las instrucciones
de configuración.
ATD0XXXXXXXXX: Realizar una llamada telefónica desde el módem.
AT+CHUP: Colgar una llamada telefónica en curso.
4.2.2. SIMULACIÓN DEL PROGRAMA DEL PIC16f628a
Para realizar la simulación del programa desarrollado para el PIC16f628a es
necesario realizarlo en conjunto con el circuito electrónico diseñado en el
apartado anterior. A continuación se presentará el proceso y los resultados
de la simulación en el programa Proteus, desde la herramienta ISIS. Para
ello se ha acondicionado ciertas partes del circuito para representar los
sistemas físicos que intervienen en el funcionamiento del sistema en
conjunto, como por ejemplo la señal del sensor de impacto será
representada mediante un pulsador; además ya que no se dispone de un
módem en el simulador, se usará un terminal virtual provisto por el
simulador, donde se podrá observar todos los códigos enviados desde el
circuito hacia el modem y viceversa.
109
El circuito para la simulación es el siguiente:
Figura 46. Diagrama para la simulación del circuito electrónico
Es importante que el microcontrolador sea cargado con el archivo
hexadecimal que contiene el programa desarrollado para el PIC16f628a.
Simulación en proceso
Para realizar la simulación del componente electrónico 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 simulación se cargan las variables definidas en el
programa, y el microcontrolador está en espera del codigo AT que le indica
110
que el módem está en línea y con la totalidad de sus funciones. Ese código
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 código es recibido, el microcontrolador envía varías líneas
de códigos de respuesta que permiten configurar el módem y borrar los
mensajes que estén almacenados en la memoria interna del módem 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
código que encienda la alarma, el cual viene escrito dentro de un mensaje
de texto enviado desde el dispositivo al módem. Cuando el módem recibe un
mensaje entrante, éste mensaje incluye, además del texto, información
referente a su remitente, fecha y hora de envío, etc. La siguiente línea
muestra la cadena de caracteres completa que el módem envía 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 código de activación para encender la
alarma; el resto de caracteres son desechados a excepción del número de
remitente.
Como respuesta el microcontrolador envía un código para borrar el mensaje
entrante (figura 61) y asi mantener el buzón de entrada vacío para nuevos
SMS entrantes, además de enviar un estado lógico 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 código para apagarla o que el sensor envíe una señal de
alerta; para ello se abre el pulsador (que representa la señal del sensor) que
hasta este momento ha permanecido cerrado. Una vez abierto el pulsador el
circuito de adquisición de datos enviará una señal al microcontrolador que se
interpretará como una posible alerta de robo (figura 50).
113
Figura 50. Resultados simulación (imagen 2)
Como se observa en el diagrama anterior, el pulsador se encuentra abierto
enviando una señal de estado lógico alto al PIC16f628a, el cual lo interpreta
como una señal de alerta y activa su salida para encender el diodo LED de
alerta (LED amarillo). Además se envía un SMS a traves del módem hacia el
dispositivo móvil 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
código de activación para que el microcontrolador realice el bloqueo del
vehículo. Ese código es el siguiente: “+07”. La cadena entera de caracteres
es como se muestra:
+CMT: “+593992380846”,,”12/10/18,16:55:01-20”??+07
114
Figura 51. Resultados simulación (imagen 3)
En respuesta al código 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 código de activación para realizar el desbloqueo. Dicho código
es: “+08”, que conjuntamente con la cadena de caracteres completa es
como se muestra a continuación:
+CMT: "+593992380846",,"12/10/18,16:55:01-20"??+08
115
Figura 52. Resultados simulación (imagen 4)
Como resultado el microcontrolador envia el respectivo código 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 simulación se enviará un código para apagar el
sistema de seguridad. Este código 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 código AT para el borrado
del SMS y la alarma vuele a su estado inicial, es decir al estado de
“apagado” (figura 53).
Figura 53. Resultados simulación (imagen 5)
Una vez realizado todo el proceso de simulación en el software PROTEUS,
el componente electrónico junto al componente de control (solamente el
programa para el PIC16f628a), pueden ser puestos a prueba nuevamente ya
que el programa del microcontrolador es cíclico, 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. DISEÑO DE LA APLICACIÓN MÓVIL
La aplicación móvil trabaja juntamente con el sistema instalado en el
vehículo, por lo tanto ambos deben mantener una relación estable sobre el
estado en que se encuentra el sistema en conjunto. El funcionamiento de la
aplicación es simple en su concepto, pero requiere de una lógica bien
definida para evitar que la aplicación entre en conflicto con la parte
electrónica del sistema. Además por tratarse de una aplicación 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 aplicación, se inicia una actividad o activity (se
abre una pantalla) en la que espera que se ingrese una contraseña de
acceso, en caso de ser incorrecta aparecerá un mensaje de error; si la
contraseña es correcta se cerrará la actividad actual y se abrirá una nueva
actividad.
La siguiente pantalla o actividad muestra en primer plano la información
referente al usuario y su vehículo, incluyendo una imagen del automóvil. Más
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 botón de encendido las etiquetas
indicarán al usuario el estado de “alarma encendida” y se enviará un SMS
con el código de activación al módem, y si se presiona el botón de apagar el
estado de las etiquetas cambiará a “apagado”. Sin embargo, cuando la
alarma está encendida, se puede salir de la aplicación dejándola en segundo
plano, a fin de aprovechar otras funcionalidades del teléfono 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 aplicación. Si el
sistema electrónico detecta una alerta de robo, envía un mensaje al móvil
que es interpretado por la aplicación y cambia su estado a “alerta”.
Siguiendo con el proceso, el usuario puede, a través de la aplicación decidir
si desea bloquear el vehículo 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 envían desde la
aplicación hacia el módem mediante SMS’s, por lo que el usuario debe
disponer de un paquete de mensajes para asegurar siempre la conexión.
Cabe mencionar que los SMS “salientes” no son administrados a través de la
aplicación de mensajes del móvil, lo que hace que el usuario no pueda
visualizarlos, sin embargo, si puede visualizar los SMS entrantes.
Una característica adicional de la aplicación, es que cuenta con un botón de
verificación, el cual permite desde cualquier estado del sistema, enviar un
mensaje al módem con la instrucción de devolver un mensaje con
información del estado real del sistema electrónico en el vehículo.
La aplicación cuenta además con un botón de cierre “Salir”, que cierra
totalmente la aplicación, 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 aplicación móvil.
La aplicación móvil para dispositivos móviles 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 móviles 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 aplicación que consiste en 2 partes
básicamente:
- Diseño de la interfaz gráfica de usuario. Esto se hace a través del
AppInventor Designer.
- Desarrollo del programa. Se realiza mediante el AppInventor Blocks
Editor.
119
4.2.3.1. Diseño de la interfaz gráfica
La interfaz gráfica es el conjunto de imágenes y objetos gráficos que son
presentados en la pantalla del dispositivo móvil, mediante la cual el usuario
interactúa con la aplicación en curso. En ella se incluyen todos los elementos
que permiten al usuario recibir información o ejecutar acciones, como hacer
click en un botón, arrastrar una imagen, visualizar una etiqueta, etc.
Además una aplicación puede contener una o varias pantallas que en
lenguaje de programación de Android® se conocen como Activities
(Actividades). Cada una de estas pantallas se debe diseñar por separado, y
el comportamiento de cada una también debe ser programado por separado.
La aplicación 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 contraseña con la que se
accede a la siguiente pantalla; pero si la contraseña es incorrecta la
aplicación 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 vehículo, tales como botón de encendido y apagado de la
alarma, botón de bloqueo y desbloqueo del vehículo, etiquetas de
información del usuario, etc.
El diseño de las pantallas de la aplicación móvil de este proyecto son las
ilustradas en las figuras 54 y 55;
120
Figura 54. Diseño del Screen1 de la aplicación móvil
Figura 55. Diseño del Screen2 de la aplicación móvil
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 Propósito
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
contraseña
Password1 PasswordTextBo
x
Basic Aquí el usuario ingresa la
contraseña de acceso
EnterButton Button Basic Presenta la contraseña para que
sea
Validada
HelpButton Button Basic Envía al usuario a un sitio de
ayuda y soporte
ErrrorMessage-
Label
Label Basic Muestra un mensaje de error
cuando la contraseña es
incorrecta
Info1Label Label Basic Muestra información de contacto
Info2Label Label Basic Muestra información de contacto
Info3Label Label Basic Muestra información de contacto
122
Tabla 13. Componentes de Screen2 (pantalla2)
Nombre de
Componente
Tipo de
Componente
Palette Propósito
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 título:
ESPECIFICACIONES DE USUARIO
UsuarioLabel Label Basic Etiqueta de nombre de usuario
ModeloLabel Label Basic Etiqueta de modelo de vehículo
MarcaLabel Label Basic Etiqueta de marca de vehículo
MatriculaLabel Label Basic Etiqueta de matrícula de vehículo
CambiarButton Button Basic Botón para cambiar de vehículo de
usuario (en caso de tener mas de
un vehículo)
CarroImagen Image Basic Imagen del vehículo
ControlSSV-Label Label Basic Etiqueta de título: CONTROL SSV
EstadoAlarmaLab
el
Label Basic Etiqueta con texto: Estado Alarma
VerificarButton Button Basic Botón de verificación de estado de
la alarma
AlarmaLabel Label Basic Etiqueta que muestra el estado de
la alarma (Encendida/Apagada)
123
AlarmaButton Button Basic Botón para encender/apagar la
alarma
EstadoVehiculoL
abel
Label Basic Etiqueta con texto: Estado
Vehículo
VehiculoLabel Label Basic Etiqueta que muestra el estado
del vehículo
(Desconocido/Protegido/Alerta/Bl
oqueado)
BloquearButton Button Basic Botón para el
bloqueo/desbloqueo del vehículo
HistorialButton Button Basic Botón para acceder al historial de
uso de la alarma
SalirButton Button Basic Botón para salir de la aplicación
EnviarMensaje Texting Social Envía SMS's al módem
Mensaje-
Recibido
Texting Social Recibe SMS del módem
AlertaSound Sound Media Sonido de alerta cuando es
recibido SMS de alerta
ClickSound Sound Media Sonido de click al presionar un
botón
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
Además 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,
tamaño, etc.
4.2.3.2. Desarrollo del programa de la aplicación
Hasta ahora ha sido diseñada la interfaz gráfica donde el usuario interactúa
con la aplicación móvil, sin embargo ninguno de los elementos gráficos
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 continuación se describen las partes esenciales del programa. Hay que
tomar en cuenta que cada bloque es una forma gráfica de una instrucción de
programación muy similar al lenguaje C o java.
o Bloques de definición
Estos bloques permiten crear variables que se utilizan para almacenar datos,
o procedimientos serán utilizados en diferentes partes del programa. Estas
variables pueden ser: texto, números, listas, datos o incluso procedimiento.
En este proyecto se utilizan para almacenar por ejemplo: el número de
teléfono del módem, nombre de usuario, estado de la alarma, etc.
125
Figura 56. Bloques de definición
En la figura 56 se observa algunos ejemplos de los bloques de definición
utilizados en el programa de este proyecto. Allí se ve la utilización de
variables como GlobalIndex que hace referencia a un número que identifica
a un usuario específico y todas sus características dentro del programa. Otra
variable, es la utilizada en el bloque de definición de proceso
EncenderAlarma, la cual nombra un proceso encargado de encender la
alarma del vehículo 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
información en forma de texto, aquí se puede escribir la información 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 información en forma de listas o vectores. Son útiles para
almacenar la información detallada de varios usuarios relacionada entre sí
por un número de índice específico de cada usuario, tales como su nombre
de usuario, su contraseña, su modelo, marca y matrícula del vehículo.
Figura 58. Bloques de lista
o Bloques de control
Los bloques de control son estructuras básicas que permiten realizar ciertas
operaciones con otros datos como comparaciones, evaluaciones,
repeticiones, etc. Las más 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 diseño de la pantalla, ya sea
un componente visible, no visible, multimedia o cualquier clase de
componente, se crean automáticamente una lista de bloques característicos
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 botón nuevo, este contiene bloques que permiten cambiar su
color, forma, texto, habilitación, o sino realizar algún procedimiento cuando
se haga click sobre el mismo.
Los bloques de componentes más relevantes usados en el programa son los
siguientes:
When Button.Click do
Este es un bloque de respuesta que realiza una acción cuando se haya
hecho click sobre un botón; dicha acción está definida por el conjunto de
instrucciones escritas dentro del bloque. Se define como “click” la acción de
presionar y soltar rápidamente una determinada área de la pantalla (touch),
128
sin realizar ningún arrastre. En este programa se utilizarán varios botones
con diferentes funciones, por lo que cada botón debe tener su conjunto de
instrucciones, por ejemplo, el botón 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 acción
cuando un mensaje de texto específico sea recibido por el dispositivo móvil.
El mensaje debe corresponder a un número de móvil de remitente y texto
129
determinado para que las acciones programadas dentro del bloque sean
llevadas a cabo. Cuando un mensaje proveniente del número del módem es
recibido con el texto “Alerta de Robo”, la aplicación lo detecta y muestra una
señal de alerta. Si el mensaje recibido muestra un texto diferente a los
especificados, o provienen de otro remitente la aplicación no realiza ninguna
acción.
Figura 61. Bloque When Texting.MessageReceived do
When Screen.Initialize do
Cuando una aplicación se ejecuta, se muestra una pantalla o “Activity”, y
dentro de la misma aplicación el usuario puede pasar de una Activity a otra.
El bloque When Screenx.Initialize do (figura 61) realiza una acción 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 aplicación.
130
Figura 62. Bloque When Screen.Initialize do
Call Notifier.ShowAlert
Este bloque es una llamada a un proceso que muestra en pantalla una
notificación durante un par de segundos y luego se desvanece, sirve para
hacer conocer al usuario que la aplicación ha detectado un evento de
importancia, como la detección 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 notificación y dos o más botones para elegir elegir haciendo click. La
acción que se lleve a cabo al presionar cualquiera de los botones del cuadro
de diálogo 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 aplicación al presionar el botón “Salir”; si el usuario acepta
presionando el botón “si” se cierra la aplicación borrando todas las variables,
pero si presiona el botón “no” la aplicación 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 notificación, una casilla para ingresar un texto y
dos botones (Aceptar y Cancelar). En la casilla de texto se debe ingresar un
132
texto específico, que luego de hacer click en el botón “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
notificación a fin de que el usuario ingrese una clave para realizar el
bloqueo/desbloqueo del vehículo, y en caso de ser incorrecta no se
ejecutará ninguna acción.
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
pequeña base de datos. Luego, esa información guardada puede ser
recuperada con el bloque Call TinyDB.GetValue. Esto es muy útil ya que
sólo así es posible guardar la información referente al estado de la alarma
133
como una etiqueta, inclusive después de haber pasado la aplicación a un
segundo plano. La información guardada permanece de forma persistente en
la memoria ROM del dispositivo móvil aun si éste es apagado y encendido
nuevamente.
Figura 66. Bloque Call TinyDB.StoreValue
El diagrama de bloques completo del programa para la aplicación móvil se
encuentra en los anexos 7 y 8. Allí se puede ver la extensión total del
programa y la utilización de todos los bloques descritos anteriormente.
4.2.4. SIMULACIÓN DE LA APLICACIÓN MÓVIL
La simulación de la aplicación para dispositivos móviles con sistema
operativo Android® se realiza desde el Editor de Bloques del AppInventor®;
desde allí se abre un emulador de teléfonos Android. La simulación se
realiza en varios pasos como sigue:
Paso1:
Se abre la aplicación desde el menú de aplicaciones. Una vez abierto
aparece la siguiente gráfica en pantalla:
134
Figura 67. Simulación aplicación móvil (imagen 1)
En la pantalla inicial de la aplicación se puede observar un etiqueta de
instrucción, una casilla de contraseña, un botón (Entrar) para ingresar a la
plataforma de control, un botón de ayuda. Y varias etiquetas de con
información de contacto. En la casilla de contraseña el usuario debe ingresar
una clave de 4 dígitos, si la contraseña es incorrecta, aparecerá un mensaje
de error, en cambio, si la contraseña ingresada es correcta, se puede
observar un mensaje que expresa la autenticidad de la contraseña (figura
68).
135
Figura 68. Simulación aplicación móvil (imagen 2 y 3)
Paso 2:
Una vez autentificada la contraseña, la aplicación 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.
Figura 69. Simulación aplicación móvil (imagen 4)
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 botón la alarma cambiara su estado a ALARMA
ENCENDIDA, consecuentemente un mensaje es enviado con el código de
activación al módem para encender la alarma en el vehículo. Las etiquetas
de la plataforma cambian para indicar que la alarma se ha encendido (figura
70).
Figura 70. Simulación aplicación móvil (imagen 5)
Paso 3:
Con el sistema en estado “encendido”, la aplicación está en espera de una
orden para “apagar” la alarma, salir de la aplicación, o en espera de un
mensaje entrante que pueda ser interpretado por la aplicación como una
señal de alerta. Cuando la aplicación recibe el mensaje de alerta las
etiquetas de la plataforma cambian al estado de ALERTA, como se muestra
en la figura 71.
137
Figura 71. Simulación aplicación móvil (imagen 6)
Paso 4:
Si el sistema está en estado de ALERTA, el usuario puede tomar la decisión
de apagar la alarma, o bloquear el vehículo. En caso de bloquear el
vehículo, la aplicación muestra una notificación 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 botón
de BLOQUEAR.
Figura 72. Simulación aplicación móvil (imagen 7)
Si la clave de bloqueo es incorrecta, la aplicación no realiza ninguna acción.
Por otra parte, si la clave es correcta, la aplicación muestra que se ha
enviado el mensaje con el código de bloqueo al módem y cambia sus
etiquetas para identificar el estado del vehículo bloqueado (figura 73).
138
Figura 73. Simulación aplicación móvil (imagen 8)
Paso 5:
Cuando el sistema se encuentra en este punto, solo está en espera de la
orden de desbloqueo. Una vez que se el botón de desbloqueo es
presionado, la aplicación presenta una notificación con un cuadro de dialogo
donde el usuario ingresa una contraseña de desbloqueo. La contraseña de
desbloqueo es la misma contraseña que se utiliza para el bloqueo (figura
74).
Figura 74. Simulación aplicación móvil (imagen 9)
Si la contraseña ingresada es correcta, la aplicación envía un SMS al
módem con el código de desbloqueo y cambia sus etiquetas para indicar que
el vehículo ha sido desbloqueado, pero la alarma no ha sido apagada, esto
se puede apreciar en la figura 75.
139
Figura 75. Simulación aplicación móvil (imagen 10)
Paso 6:
Como último paso, se simulará el apagado del sistema, lo que se obtiene
presionando el botón APAGAR. Una vez más, la aplicación envía un SMS
con el código de activación necesario para apagar el sistema y cambia sus
etiquetas.
140
5. RESULTADOS
141
Una vez finalizada la construcción del prototipo, este fue sometido a varias
pruebas de funcionamiento para determinar la efectividad del proyecto
planteado en este trabajo de titulación. 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 continuación.
o Efectividad de envío y recepción de mensajes en condiciones
normales, desde el teléfono móvil hacia el módem.
Estas pruebas se realizaron desde diferentes puntos de la ciudad de Quito y
diferentes teléfonos celulares, hacia el módem ubicado en un punto
determinado, bajo condiciones óptimas de señal celular en sectores con
cobertura 1W (según la compañía de telefonía celular). El objetivo de esta
prueba es determinar la efectividad de activación y desactivación del sistema
de seguridad mediante las siguientes tareas:
- Determinar la capacidad del módem de receptar el mensaje entrante
en condiciones normales,
- Determinar la capacidad del circuito electrónico de interpretar y
procesar la información compartida por el módem.
- Determinar el tiempo promedio que tarda en llegar un mensaje
enviado desde el teléfono hacia el módem;
- Comprobar el correcto funcionamiento de la aplicación móvil respecto
al envío de mensajes de texto.
No se pretende con esta prueba comprobar la eficiencia del servicio de envío
de SMS de la compañía de telefonía celular, puesto que esa característica
es inherente solo a la compañía y no está en control del sistema. Se envió
un total de 20 mensajes de texto de prueba.
142
Figura 76. Pruebas de envío de SMS desde teléfono a módem con buena
calidad de señal celular
Resultados
Se obtuvo un 100% de efectividad en el envío de mensajes de texto desde el
teléfono móvil hacia el módem; esto significa que todos los mensajes
enviados fueron recibidos por el módem y leídos por el circuito electrónico,
con lo cual se puede afirmar que el sistema es capaz de activar y desactivar
la alarma bajo condiciones de funcionamiento normales.
Además se tomó valores de los tiempos de envío de los mensajes y se
calculó el tiempo promedio, el cual es: 4,91 segundos.
Tabla 14. Resultados de la prueba de envío y recepción de mensajes desde
el teléfono móvil hacia el módem
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 envío: 100%
o Efectividad de envío y recepción de mensajes en condiciones
normales, desde el módem hacia el teléfono.
El objetivo de esta prueba es determinar:
- La eficacia del circuito electrónico para enviar una instrucción de
envío de SMS al módem.
- La eficacia del módem para enviar mensajes de texto.
- La capacidad de la aplicación móvil para interpretar un SMS entrante.
- El tiempo que tarda un mensaje de texto en llegar al dispositivo móvil.
Para esto hay que verificar que la tarjeta SIM del módem cuente con
respectivo crédito. Las pruebas se realizaron bajo condiciones normales de
funcionamiento, es decir con niveles óptimos de señal celular en sectores de
144
cobertura 1W. Los mensajes de texto se enviaron desde el módem a un
número de teléfono único.
Figura 77. Pruebas de envío de SMS desde módem a teléfono con buena
calidad de señal celular
Resultados:
Se obtuvo como resultado un 100% de efectividad en el envío y recepción de
mensajes desde el módem hacia el dispositivo móvil, lo que implica la
efectividad del circuito para enviar las instrucciones de envío hacia el
módem, y la capacidad de éste para enviar mensajes de texto. Los tiempos
de llegada de los mensajes de texto fueron tomados también y su promedio
se calculó en: 5,13 segundos.
Tabla 15. Resultados de las pruebas de envío y recepción de mensajes
desde el módem hacia el teléfono móvil
Mensaje Nº Texto Tiempo de entrega Llegó
1 Alerta de robo 4,68 Sí
2 Alerta de robo 5,90 Sí
3 Alerta de robo 6,03 Sí
145
4 Alarma encendida 4,29 Sí
5 Alarma apagada 4,17 Sí
6 Alarma encendida 4,53 Sí
7 Alerta de robo 6,24 Sí
8 Alarma apagada 5,88 Sí
9 Alerta de robo 3,87 Sí
10 Vehículo bloqueado 5,23 Sí
11 Alarma apagada 5,94 Sí
12 Alerta de robo 4,47 Sí
13 Alarma encendida 4,82 Sí
14 Vehículo bloqueado 5,41 Sí
15 Alarma apagada 5,80 Sí
16 Alerta de robo 4,35 Sí
17 Vehículo bloqueado 4,99 Sí
18 Alarma encendida 5,49 Sí
19 Alarma apagada 5,20 Sí
20 Alerta de robo 5,37 Sí
Tiempo promedio: 5,13
Efectividad de envío: 100%
o Efectividad de envío y recepción de mensajes en ausencia de
señal celular, desde el dispositivo móvil hacia el módem.
Estas pruebas se realizaron con el módem ubicado en un lugar cuyos
niveles de señal ofrecida por la compañía de telefonía celular son muy bajos
y en ocasiones nulos. De esta manera se pretende observar el
comportamiento del sistema con el vehículo estacionado en un lugar sin
señal celular, ejemplo de ello puede ser un estacionamiento subterráneo, o
una zona rural. Se realizaron 20 pruebas de envío de mensajes en diferentes
momentos y lugares.
146
Figura 78. Pruebas de envío de SMS desde teléfono a módem en ausencia
de señal celular
Resultados:
Como resultado de estas pruebas, las cuales fueron realizadas en varias
zonas del sur de Quito donde la señal celular es deficiente (partes
subterráneas de casas) se obtuvo que el sistema no responde a las órdenes
enviadas desde el dispositivo móvil hacia el módem en lugares donde no
existe cobertura de señal celular. Se espera que la efectividad en estas
zonas sea menor al 10%.
Tabla 16. Resultados de las pruebas de envío de mensajes desde el teléfono
móvil hacia el módem en ausencia de señal 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
Tiempo promedio: 7,43
Efectividad de envío: 5%
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 través de la detección de
cambios en el entorno, dichos cambios se refieren a golpes en la estructura
física del vehículo, o movimientos fuertes que pueden ser causados al
ingresar al vehículo o encenderlo de manera no autorizada. Estas pruebas
permiten determinar:
- La sensibilidad óptima del sensor de impacto.
- La eficacia del circuito de admisión de señal del sensor.
148
Cabe decir que la sensibilidad se ajusta por medio de un potenciómetro 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 vibración física, es decir que el estado
de alerta se presentaba al momento de encender la alarma debido a la
interferencia electromagnética del módem al enviar o recibir un mensaje de
texto, lo cual era causado por la demasiada cercanía entre el módulo
electrónico y el sensor, ya que ambos se encontraban en la zona del tablero
de mandos.
Al cambiar la posición del sensor a la cajuela del vehículo, de modo que se
encontrara lo suficientemente lejos (más de 1m) como para no activar la
alerta del sistema, los resultados fueron más favorables. Se ajustó la
sensibilidad del sensor para que se active la alerta con un golpe fuerte en
cualquier parte del vehículo. 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 vehículo estacionado
Estas pruebas se realizaron con el módulo electrónico instalado en un
vehículo particular. Como condiciones para realizar el bloqueo se tiene que:
- La alarma está encendida, y ha detectado una alerta a través del
sensor de impacto.
- El vehículo se encuentra estacionado y apagado antes de realizar el
bloqueo.
- Una vez realizado el bloqueo se intenta encender el vehículo de
manera habitual.
150
- Por último se realiza el desbloqueo.
El objetivo de estas pruebas es determinar la eficacia del circuito electrónico
en cuanto a la realización del bloqueo y desbloqueo del vehículo a través de
su sistema de ignición.
Resultados:
Como se esperaba al realizar el bloqueo del vehículo e intentar encenderlo
con la llave de encendido, este no respondía. Se observó que el motor de
arranque del vehículo si accionaba pero no encendía el motor de combustión
interna debido a la falta de energía que produzca la explosión en los
cilindros. Esto se debe a que el relé de bloqueo solo actúa sobre la bobina
de ignición, permitiendo al resto de sistemas del vehículo seguir siendo
alimentados por la batería del automóvil.
Seguidamente se realizó el procedimiento para realizar el desbloqueo, a lo
que se obtuvo como resultado una reactivación del sistema de ignición
permitiendo al vehículo recuperar la capacidad de encendido del motor de
combustión 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 vehículo en movimiento
Estas pruebas tienen como objetivo observar el comportamiento del vehículo
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 vehículo es encendido y puesto en marcha, comienza a circular por
la vía.
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 vehículo desde el
dispositivo móvil 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 vehículo puesto que el sistema de ignición está
desactivado. La reacción en el vehículo es parecida a cuando éste se queda
sin combustible.
Seguidamente se realiza el desbloqueo, dando como resultado la
reanudación del comportamiento normal del vehículo.
Nota: Algunos modelos de vehículos, especialmente modelos más
modernos, poseen integrado un mecanismo de bloqueo del volante al
desactivar el sistema eléctrico del vehículo, lo que hace que al cortar la
energía del sistema eléctrico (contacto) el volante se inmoviliza. Es
importante reconocer este esquema, ya que el bloqueo del proyecto
planteado se aplica solo al sistema de ignición (bobina de ignición) mas no al
sistema eléctrico en sí (tablero de control, luces, etc.).
152
6. CONCLUSIONES Y RECOMENDACIONES
153
6.1. CONCLUSIONES
Una vez realizado el diseño, implementación y pruebas del proyecto
planteado en este trabajo de titulación se ha podido concluir que:
El sistema de seguridad vehicular con un control remoto mediante una
aplicación para dispositivos móviles planteado en este trabajo de
titulación responde a ciertos vacíos dejados por los sistemas
convencionales en necesidades de seguridad actual y presenta una
propuesta innovadora, ya que integra las facilidades provistas por las
tecnologías de comunicación celular a la resolución de problemas
específicos. Se puede decir que el hecho de controlar la alarma de un
vehículo desde un teléfono celular resultó una opción atractivamente
cómoda para el usuario, gracias a la posibilidad de monitorear el
sistema en cualquier momentoy, poder administrar el sistema de
seguridad desde cualquier distancia del vehículo.
El método de utilización 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 crédito
suficiente tanto en el teléfono móvil como en el módem GSM, además
de encontrarse en el rango de cobertura, para el envío 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 más
acertado sobre las consecuencias del empleo de mensajes de texto
como método de transmisión de información se debe realizar un
análisis costo/beneficio detallado.
Como ventajas de la utilización de mensajes de texto se tiene que,
estos presentan un formato único, y un medio en el cual se puede
escribir información específica en forma de texto, lo cual ofrece la
posibilidad de desarrollar una amplia serie de códigos diferentes que
describan distintas instrucciones, además se aprovecha su carácter
de confidencialidad logrando que ningún usuario final tenga acceso a
154
los códigos de activación que son enviados vía SMS desde el
dispositivo hacia el módem, esto ya que la aplicación utiliza el servicio
de mensajes de texto pero no permite que su contenido sea
visualizado. Otra ventaja de la utilización de mensajes de texto es que
son fáciles de utilizar, manipular y procesar, y su envío y recepción
son bastante efectivos.
El sistema propuesto presenta una efectividad en el desempeño 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 señal no son favorables el sistema puede
presentar fallos en su funcionamiento, reduciendo su efectividad a no
más del 10%.
6.2. RECOMENDACIONES
Se recomienda fortalecer el alcance del proyecto utilizando un módem
GPS®/GSM® en lugar de un módem GSM® únicamente. Esto
facilitaría el desarrollo de aplicaciones con características de rastreo
satelital haciendo del sistema de seguridad planteado más fuerte y
efectivo. Además las herramientas que hoy en día disponemos para la
creación de sistemas que utilicen el Sistema de Posicionamiento
Global son cada vez más accesibles y fáciles de utilizar.
Utilizar un sensor de encendido, o de puertas en lugar de un sensor
de impacto, o simplemente añadir al sistema la mayor cantidad de
sensores posibles; esto para evitar tanto como sea posible fallas en la
detección de alertas de robo, sin necesidad de causar falsas alarmas
por activación errónea de los sensores.
También es recomendable adentrarse en el desarrollo de aplicaciones
para dispositivos móviles a través de herramientas de programación
con más 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
más complejo ofrece características avanzadas de diseño y desarrollo
de aplicaciones móviles.
Se puede mejorar la aplicación móvil agregando la característica de
guardar en una lista el historial de procesos realizado en el sistema
mediante un botón de “Historial”, y la creación de una pantalla que
muestre el resultado. Para esto es necesario la utilización de
instrucciones referentes al almacenamiento de información de forma
persistente, o almacenamiento de información en bases de datos.
Al momento de realizar la instalación del sistema en el vehículo 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 vehículo moderno el mecanismo de bloqueo
del volante (esto hace que el volante sea truncado) al desactivar el
sistema eléctrico, y en vista de que no queremos realizar esa acción,
se debe realizar las conexiones del bloqueo únicamente sobre la
bobina de ignición.
En cuanto al diseño de la interfaz gráfica de la aplicación móvil, se
recomienda hacer de la plataforma de control una suite bastante
cómoda y ergonómica 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 fácil comprensión del funcionamiento de la aplicación.
Para hacer del sistema mucho más fuerte, éste debe ser
complementado con un sistema de rastreo satelital o GPS®, lo cual
permite la localización del vehículo una vez que haya sido bloqueado,
de lo contrario, la efectividad del sistema dependerá solo de cuán
rápido se actúe en caso de un robo.
156
BIBLIOGRAFÍA
157
o Libros y publicaciones
Tocornal X., Abril M. & Tupiza A. (2008). Análisis Comparado del robo de
vehículos en Quito, Guayaquil y Santiago. Programa Estudios de la Ciudad.
Flacso Sede Ecuador. Quito
Hernando, R. (2004). Comunicaciones Móviles (2da ed.) Madrid: Ramón
Areces.
Eberspächer, J., Vögel, H.-J., Bettstetter C., & Hartmann C. (2009). GSM –
Architecture, Protocols and Services (3ra ed.). Wiltshire: John Wiley & Sons.
Tomasi, W. (2003). Sistemas de comunicaciones electrónicas (4ta ed.).
México: Pearson Educación.
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 (versión 1.1). Author.
Gargenta, M. (2011). Learning Android (1st. ed.). Sebastopol, CA: O’Reilly.
Jakl, A. (2009). Mobile Operating Systems (version 1.0). FH Hagenberg:
Mobile Computing.
Baz, A., Ferreira, I., Álvarez, M. & García, R. (2010). Dispositivos Móviles.
Ingeniería de Telecomunicación, Universidad de Oviedo, Madrid, España.
Meier, R. (2009). Professional Android™ Application Development.
Indianapolis: Wiley Publishing.
Inec (2011). Reporte anual de estadísticas sobre tecnologías de la
información y comunicaciones (TIC’s) 2011. Ecuador: Author.
Pérula, R. (2010). Sistemas Operativos Móviles, Programación Avanzada.
(Creative Commons).
Lamscheck-Nielsen, R. & Agerskov M. (2010). TA3 – Operating Systems.
Metropolitan University College, Denmark.
158
Sapia, J. L. (2002). Inmovilizadores, Manual técnico (actualización nov.
2002). Centro de capacitación automotriz, Instituto Tecnológico Superior del
automotor, Buenos Aires, Argentina.
Mattes, B., Schmidt G., Graumann, D. & Rudolf, P. (2000). Sistemas de
seguridad y confort (edición 2000). Alemania: BOSCH.
Vargas, E. (200). Metodología Aplicada al Desarrollo de Máquinas
Mecatrónicas, Congreso Latinoamericano de Instrumentación y Control de
Procesos. Universidad Autónoma de Querétaro. México.
Boylestad, R. (2004). Introducción al análisis de circuitos (10ma Ed.)
Pearson Educación. Mexico.
ZTE Corporation. (2007) AT Command Manual for ZTE Corporation’s
ME3000 Module (version V2,00),
o Tesis
La Rosa, K. (2012). Diseño de sistema integral de seguridad vehicular:
Seguridad pasiva, seguridad activa y socorro inmediato para conductores y
pasajeros de vehículos automotores. Pontificia Universidad Católica del
Perú, Lima, Perú.
Bravo, L. (2011). Diseño e implementación de alarmas comunitarias a través
de un operador móvil. Escuela Politécnica del Ejército, Sangolquí, Ecuador.
López, E. & Moya, V. (2009). Diseño e instalación de un sistema de
seguridad y arranque mediante dispositivos de seguridad con sensores
IBUTTON y RFID. Escuela Politécnica del Ejercito, Latacunga, Ecuador.
Paniagua, C. (2008). Control de módem GSM desde un microcontrolador.
Universitat Rovira i Virgili, Tarragona, España.
159
o Recursos web
Observatorio Metropolitano de Seguridad Ciudadana de Quito. Cubo
estadístico de delitos a la propiedad [En línea]. Recuperado el 11 de
diciembre del 2012, de
http://www.observatorioseguridaddmq.net/?btnGrafico=&Cubos=DelitosPropi
edad.cub
Wikipedia (2012, septiembre). Teléfono inteligente. Wikipedia [En línea].
Recuperado el 19 de septiembre del 2012, de
http://es.wikipedia.org/wiki/Tel%C3%A9fono_inteligente
Morales Hugo (2012, febrero). Los sistemas operativos móviles más usados
para navegar en Iberoamérica. Wayerless [En línea]. 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 línea]. Recuperado el 19
de septiembre del 2012, de http://es.wikipedia.org/wiki/Android
Android Developers (2012, septiembre). Aplications Fundamentals. Android
Developers [En línea]. 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 línea].
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 línea]. Recuperado
el 19 de septiembre del 2012, de http://www.honorio.com.ar/alarmas.htm
Wikipedia (2012, agosto). Car alarm. Wikipedia [En línea]. Recuperado el 19
de septiembre del 2012, de http://en.wikipedia.org/wiki/Car_alarm
Wikipedia (2012, agosto). Original Equipment Manufacturer. Wikipedia [En
línea]. Recuperado el 19 de septiembre del 2012, de
http://es.wikipedia.org/wiki/Original_equipment_manufacturer
160
Wikipedia (2012, agosto). RFID. Wikipedia [En línea]. Recuperado el 19 de
septiembre del 2012, de http://es.wikipedia.org/wiki/RFID
Wikipedia (2012, agosto). Immobiliser. Wikipedia [En línea]. Recuperado el
19 de septiembre del 2012, de http://en.wikipedia.org/wiki/Immobiliser
161
ANEXOS
162
Universidad Tecnológica Equinoccial
Anexo Nº1 Circuito electrónico completo del
proyecto Fecha:24/01/13
Escuela: Mecatrónica
Escala: NA Nombre: Willian Veloz Salazar
163
Universidad Tecnológica Equinoccial
Anexo Nº2 Layout del PBC del proyecto
realizado en ARES® Fecha:24/01/13
Escuela: Mecatrónica
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 aplicación móvil
166
Anexo 5. Diagramas de procesos del SCREEN2 de la aplicación móvil
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 tecnología GSM *
'****************************************************************
DEFINE HSER_RCSTA 90h 'Se define la configuración
DEFINE HSER_TXSTA 24h 'del puerto USART
DEFINE HSER_BAUD 115200 'la tasa de transferencia entre el
DEFINE HSER_CLROERR 1 'PIC y el módem es de 115200 bauds
DEFINE osc 20 'oscilador de 20MHz
'Configuración 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 códigos
cod1[1]="0" 'de activación 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 módem en modo texto
HSEROUT["AT+CMGD=1",13] 'Borra los mensajes del buzón de
HSEROUT["AT+CMGD=2",13] 'entrada, desde la ubicación 1 a 8
HSEROUT["AT+CMGD=3",13]
HSEROUT["AT+CMGD=4",13]
HSEROUT["AT+CMGD=5",13]
HSEROUT["AT+CMGD=6",13]
HSEROUT["AT+CMGD=7",13]
HSEROUT["AT+CMGD=8",13]
HSEROUT["AT+IFC=0,0",13] 'Configura la comunicación en modo
PAUSE 500 'asíncrono
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 conexión
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 posición del buzón
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 código de encendido
HIGH led_on
GOTO encendido
ENDIF
IF modem[0]=cod3[0] AND modem[1]=cod3[1] AND modem[2]=cod3[2]
THEN;Compara el texto del SMS con el código de verificación
HSEROUT["AT+CMGS=",34,"0",STR numModem\9,34,13];Instrucción para
envío de SMS, # de celular, 34(comillas), 13(enter)
HSEROUT["Alarma apagada",26];Envía 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]
HSEROUT["AT+CMGD=1",13]
IF modem[0]=cod2[0] AND modem[1]=cod2[1] AND modem[2]=cod2[2]
THEN;Compara el texto del SMS con el código de apagado
LOW led_on
GOTO Apagado
ENDIF
170
IF modem[0]=cod3[0] AND modem[1]=cod3[1] AND modem[2]=cod3[2]
THEN;Compara el texto del SMS con el código de verificación
HSEROUT["AT+CMGF=1",13]
HSEROUT["AT+CMGS=",34,"0",STR numModem\9,34,13]
HSEROUT["Alarma encendida",26]
GOTO encendido
ENDIF
GOTO encendido
alerta:
HSERIN 200,alerta,[WAIT("+CMT:"),skip 42,STR modem\3]
HSEROUT["AT+CMGD=1",13]
IF modem[0]=cod7[0] AND modem[1]=cod7[1] AND modem[2]=cod7[2]
THEN;Compara el texto del SMS con el código de bloqueo
HIGH led_bloq
LOW led_alert
GOTO bloqueado
ENDIF
IF modem[0]=cod2[0] AND modem[1]=cod2[1] AND modem[2]=cod2[2]
THEN;Compara el texto del SMS con el código de apagado
LOW led_on
LOW led_alert
GOTO apagado
ENDIF
IF modem[0]=cod3[0] AND modem[1]=cod3[1] AND modem[2]=cod3[2]
THEN;Compara el texto del SMS con el código de verificación
HSEROUT["AT+CMGS=",34,"0",STR numModem\9,34,13]
HSEROUT["Alerta de robo",26]
GOTO alerta
ENDIF
GOTO alerta
bloqueado:
HSERIN 200,bloqueado,[WAIT("+CMT:"),skip 42,STR modem\3]
HSEROUT["AT+CMGD=1",13]
IF modem[0]=cod8[0] AND modem[1]=cod8[1] AND modem[2]=cod8[2]
THEN;Compara el texto del SMS con el código de desbloqueo
LOW led_bloq
GOTO encendido
ENDIF
171
IF modem[0]=cod3[0] AND modem[1]=cod3[1] AND modem[2]=cod3[2]
THEN;Compara el texto del SMS con el código de verificación
HSEROUT["AT+CMGF=1",13]
HSEROUT["AT+CMGS=",34,"0",str numModem\9,34,13]
HSEROUT["Vehículo bloqueado",26]
GOTO bloqueado
ENDIF
GOTO bloqueado
END
172
Anexo 7. Diagrama de bloques del programa para el Screen1 de la aplicación
móvil
173
Anexo 8. Diagrama de bloques del programa para el Screen2 de la aplicación móvil
174
175
176
Anexo 9. Hoja técnica del PIC16f628a
177
178
179
180
181
Anexo 10. Hoja técnica del relé CB1a-M-12V
182
Anexo 11. Fotografías del proyecto
Diseño de PBC del circuito electrónico
Pruebas del sistema electrónico en protoboard
183
Circuito electrónico con sus componentes
Tamaño del circuito electrónico
184
Componentes del módulo electrónico
Módulo electrónico totalmente ensamblado