Sistema de Monitoreo de Pulso Cardiaco

INSTITUTO POLITÉCNICO NACIONAL
ESCUELA SUPERIOR DE CÓMPUTO
ESCOM
Trabajo Terminal
Prototipo de sistema de alerta y monitoreo de signos vitales de

participantes en carreras deportivas.
No TT: 2014B 004
PRESENTAN:
ALANIS TAMEZ MARIANA DAYANARA
VELÁZQUEZ RODRÍGUEZ JOSÉ LUIS
DIRECTORES
DR. JORGE CORTÉS GALICIA DR. JULIO CÉSAR SOSA SAVEDRA
DICIEMBRE, 2015
1
INSTITUTO POLITÉCNICO NACIONAL
ESCUELA SUPERIOR DE CÓMPUTO
SUBDIRECCIÓN ACADÉMICA
No TT: 2014B 004 DICIEMBRE,2015
Documento técnico
Prototipo de sistema de alerta y monitoreo de signos vitales de

participantes en carreras deportivas.
PRESENTAN:
ALANIS TAMEZ MARIANA DAYANARA 1
VELÁZQUEZ RODRÍGUEZ JOSÉ LUIS 2
DIRECTORES
DR. JORGE CORTÉS GALICIA DR. JULIO CÉSAR SOSA SAVEDRA
1 Correo electrónico: malanist1100@alumno.ipn.mx

2 Correo electrónico: jvelazquezr1105@alumno.ipn.mx
2
RESUMEN
En el presente reporte se propone un prototipo cuya finalidad es prevenir posibles percances de

salud que pudieran suscitarse en carreras deportivas, desarrollando un sistema computacional que
permita el monitoreo de signos vitales de manera frecuente en cada uno de los participantes de
estos eventos, además emitirá alertas preventivas en caso de ser necesario. De esta manera, los
organizadores de estos eventos deportivos tendrán un mejor control de la salud de los
participantes. Este monitoreo se realizará con un dispositivo electrónico que captará los signos
vitales del participante, éste enviará la información obtenida a un dispositivo móvil, estos dos
dispositivos el participante los llevará consigo; la información obtenida se transmitirá de forma
remota a un servidor y este a su vez la enviará a una aplicación de monitoreo donde será posible
observar la información de cada uno de los participantes además de que emitirá una alerta en caso
de que el participante tuviese algún problema de salud.
Palabras clave –signo vital, monitoreo, aplicación móvil, sistema embebido.
3
4
5
Agradecimientos
Le agradezco a Dios por haberme acompañado y guiado a lo largo de mi carrera, por ser mi
fortaleza en los momentos de debilidad y por brindarme una vida llena de aprendizajes,
experiencias y sobre todo felicidad.
Le doy gracias a mi papá Eduardo por su trabajo constante y su dedicación y a mi mamá

Magdalena por siempre estar ahí y apoyarme en todo momento además de ser una excelente
madre y amiga, le agradezco a ambos por los valores que me han inculcado, por haberme dado la
oportunidad de tener una excelente educación en el transcurso de mi vida y, sobre todo, por ser
un excelente ejemplo de vida a seguir y brindarme todo su amor.
A mis hermanas Paola y Sofía por ser parte importante de mi vida, por llenar mi vida de alegrías
y amor cuando más lo he necesitado.
A mi compañero de trabajo terminal, José Luis, por haber sido un excelente compañero y amigo,
por haberme tenido la paciencia necesaria y por motivarme a seguir adelante en los momentos de
desesperación.
A mis directores de trabajo, los doctores Jorge Cortés Galicia y Julio César Sosa Savedra por
creer en José Luis y en mí, y habernos brindado su tiempo y paciencia en el desarrollo de nuestro
trabajo, por todo el apoyo y por darnos la oportunidad de crecer profesionalmente y aprender
cosas nuevas.
Le agradezco la confianza, apoyo y dedicación de tiempo a mis profesores: Víctor Hugo García
Ortega y Miguel Olvera Aldana. Por haber compartido conmigo sus conocimientos y sobre todo
su amistad.
A mis amigos, sobre todo a Alan, Daniel, Claudio, Julio, Sam, Miguel, Gonzalo, Jair, Ricardo,
Nayeli, Jesús, y Oscar por confiar y creer en mí y haber hecho de mi etapa universitaria un
trayecto de vivencias que nunca olvidaré, también quiero agradecer especialmente a mis
compañeros de sala por ayudarnos en lo que llegáramos a necesitar, los quiero mucho.
A mis bebés A&L por hacerme muy feliz y estar ahí cuando más las necesito. Las amo
muchísimo.
6
Al Instituto Politécnico Nacional que me ha formado desde la educación media superior (Cecyt
14) y superior (ESCOM) y me ha abierto las puertas para recibir una educación y formación de la
más alta calidad.
Son muchas las personas que han formado parte de mi vida profesional a las que me
encantaría agradecerles su amistad, consejos, apoyo, ánimo y compañía en los momentos
difíciles. Algunas están aquí conmigo y otras en mis recuerdos y en mi corazón, sin importar en
donde estén quiero darles las gracias por formar parte de mí, por todo lo que me han brindado y
por todas sus bendiciones. Para ellos: Muchas gracias y que Dios los bendiga.
Mariana.
A mi padre Luis Velázquez Soto, por ser la inspiración de todo lo que hago, quien con sus
consejos ha sabido guiarme, para culminar mi carrera profesional. A mi madre, Leonor
Rodríguez Lara, por sus sacrificios, orientación, comprensión y apoyo incondicional en todo
momento de mi formación.
A mi hermana Daniela, a quien quiero mucho, y que siempre ha estado junto a mí, bridándome su
apoyo.
A todos mis familiares y amigos a los que generalizo por no omitir nombres, por todo el apoyo
incondicional que me han brindado y compartir conmigo buenos y malos momentos.
A mis directores de trabajo terminal, Dr. Jorge Cortes Galicia y Dr. Julio Cesar Sosa Savedra por
su esfuerzo y dedicación, quien con sus conocimientos, su experiencia, su paciencia y su
motivación han logrado que Mariana y yo podamos terminar nuestro trabajo con éxito.
A Mariana, mi compañera de trabajo terminal, gracias por tu paciencia, esmero, dedicación y

esfuerzo, que sin ellos no hubiéramos terminado.
También me gustaría agradecer a mis profesores que durante toda mi carrera profesional han
aportado con un granito de arena a mi formación, y en especial a mi Prof. Víctor Hugo García
Ortega y Miguel Olvera Aldana por sus consejos, su enseñanza y más que todo por su
acompañamiento.
Con respeto a nuestra escuela porque en ella formamos nuestra vida profesional.
José Luis
7
Índice General
Agradecimientos ............................................................................................................................................6
Estructura del documento .............................................................................................................................10
CAPÍTULO 1. INTRODUCCIÓN ...........................................................................................................11
1.1. Antecedentes ................................................................................................................................11
1.2. Objetivo general ...........................................................................................................................12
1.3. Objetivos específicos....................................................................................................................12
1.4. Justificación..................................................................................................................................13
1.5. Marco teórico ...............................................................................................................................13
1.5.1. Sistema embebido ................................................................................................................13
1.5.2. Aplicación móvil ..................................................................................................................14
1.5.3. Sistema de posicionamiento global (GPS) ...........................................................................15
1.5.4. Google Maps ........................................................................................................................16
1.5.5. Sistema distribuido ...............................................................................................................16
1.5.6. Instrumentación electrónica .................................................................................................18
1.5.7. Dispositivos programables ...................................................................................................23
1.6. Estado del arte ..............................................................................................................................24

CAPÍTULO 2. ANÁLISIS ........................................................................................................................28
2.1. Metodología .................................................................................................................................28
2.2. Análisis de requerimientos ...........................................................................................................29
2.3. Reglas del negocio .......................................................................................................................32
2.4. Viabilidad técnica y legal .............................................................................................................33
2.5. Análisis de factibilidad .................................................................................................................55
CAPÍTULO 3. DISEÑO ...........................................................................................................................57
3.1. Diagramas de arquitectura ............................................................................................................57
3.2. Diagramas de casos de uso ...........................................................................................................61
3.3. Catálogo de mensajes ...................................................................................................................85
3.4. Diagramas de clases .....................................................................................................................88
3.5. Diagrama Entidad-Relación .........................................................................................................90
3.6. Diccionario de datos .....................................................................................................................91
3.7. Diagramas de secuencia ...............................................................................................................92
3.8. Diagramas de procesos .................................................................................................................94
8
3.9. Diagrama de bloques ....................................................................................................................97
3.10. Diagramas de actividades .......................................................................................................101
3.11. Diagramas de estado...............................................................................................................104
3.12. Diagramas de contexto ...........................................................................................................107
3.13. Diagramas de flujo de datos ...................................................................................................110
3.14. Diagramas electrónicos ..........................................................................................................131
3.15. Interfaz de comunicación .......................................................................................................137
3.16. Avances ..................................................................................................................................138
CAPÍTULO 4. IMPLEMENTACIÓN ....................................................................................................147
4.1. Aplicación web...........................................................................................................................148
4.2. Aplicación móvil ........................................................................................................................155
4.3. Dispositivo electrónico ...............................................................................................................158
CAPÍTULO 5. PRUEBAS ......................................................................................................................170
5.1. Pruebas modulares......................................................................................................................170
5.1.1. Aplicación web.........................................................................................................................170
5.1.2. Aplicación móvil ......................................................................................................................174
5.1.3. Dispositivo electrónico .............................................................................................................177
5.2. Pruebas finales y de integración .................................................................................................183

CAPÍTULO 6. CONCLUSIONES Y TRABAJO A FUTURO .................................................................204
CONCLUSIONES .................................................................................................................................204
TRABAJO A FUTURO .........................................................................................................................206
Referencias .................................................................................................................................................207
Glosario ......................................................................................................................................................213
ANEXOS....................................................................................................................................................216
Anexo 1. Cálculos propuestos ................................................................................................................216
Anexo 2. Hojas de datos.........................................................................................................................218
9
Trabajo Terminal No. 2014B 004
Prototipo de sistema de alerta y monitoreo de signos vitales de participantes en
carreras deportivas.
Estructura del documento
El presente trabajo está estructurado de la siguiente manera.
Capítulo 1. Introducción: Se da una descripción general del prototipo propuesto y sus

antecedentes, además se indican los objetivos generales y específicos, la justificación, el marco
teórico (en dónde se describen los temas más relevantes del prototipo) y finalmente el estado del
arte.
Capítulo 2. Análisis: Se describe la especificación detallada del sistema que sirve como base
para el diseño.
Capítulo 3. Diseño: Se definen detalladamente los componentes del sistema mediante diagramas.
Capítulo 4. Implementación. Se indican las partes fundamentales de la implementación del

prototipo.
Capítulo 5. Pruebas. Se muestran pruebas modulares y de integración del prototipo.
Capítulo 6. Conclusiones y Trabajo a Futuro. Se concluye el trabajo realizado y se proponen

ideas para trabajo a futuro.
Referencias: Lista ordenada de todas las fuentes consultadas que ayudaron al desarrollo del
documento y construcción del prototipo.
Glosario: Lista de términos poco utilizados y conocidos con su respectiva definición.
Anexos. Se indica información adicional de relevancia.
10
CAPÍTULO 1. INTRODUCCIÓN
En este capítulo se presentan una introducción al prototipo propuesto, el cual está integrado por
las secciones de antecedentes, objetivos generales y específicos, justificación del problema,
marco teórico y estado del arte.
1.1. Antecedentes
El atletismo es una buena manera para mantener el cuerpo sano, en forma además de que evita
enfermedades causadas por el sedentarismo, el estrés y el riesgo cardiovascular, fortalece los
músculos para que no se atrofien por falta de actividad, previene a la larga la hipertensión
arterial, ayuda a regular el sobrepeso, a estar en una buena condición física, entre otras cosas [1].
En México, específicamente en el Distrito Federal, el gobierno de este distrito ha organizado
diversas carreras deportivas para fomentar el atletismo en sus habitantes. Como ejemplo de
algunas de estas carreras están: Corriendo con las Estrellas 5k, The Run 2 Ciudad de México 5k y
10k, 30va Carrera del Día del Niño Corredores del Bosque de Tlalpan, Maratón de la Ciudad de
México 2014, entre otras [2].
En 2014, el Instituto Politécnico Nacional (IPN) Canal Once y la Fundación Politécnico A.C.,
organizaron la 7a edición de la carrera IPNONCE K que tiene como objetivo fomentar la
actividad física entre su comunidad, esta carrera se lleva a cabo en distintas ciudades de México
como Cancún, Campeche, Culiacán, Ensenada, Los Mochis, Mazatlán, Morelia, Oaxaca,
Reynosa, Querétaro, Silao Guanajuato, Tampico y Tlaxcala. En la ciudad de México la carrera
inicia en el Casco de Santo Tomás terminando en la unidad Adolfo López Mateos en Zacatenco
completando una ruta de 11 kilómetros, también se realizan carreras de 5 Km, en la que
participan cerca de 10 mil corredores entre los que se rifan 2 automóviles [3].
En el IPN, también se realizan carreras atléticas anuales parecidas a la ONCEK organizadas por
sus unidades académicas, como ejemplo la Escuela Superior de Cómputo (ESCOM) año con año
en el marco de la Semana Cultural y Deportiva se realiza la “Carrera Atlética”, siendo la tercera
vez que se realiza en el año 2014.
Es importante resaltar que para el correcto desenvolvimiento de estas carreras, es de gran

relevancia monitorear frecuentemente el estado físico de los participantes, ya que
11
desafortunadamente se han suscitado percances médicos; por mencionar algunos se tienen los
siguientes: Maratón de la Ciudad de México 2013 en el que el participante Jorge Saldaña
Cerrillo, de 30 años, portador del número 1034 fue atendido por personal del Escuadrón de
Rescate y Urgencias Médicas (ERUM) al sentirse mal, cuando corría por la zona de la colonia
Condesa, falleció en el Hospital Xoco debido a un paro respiratorio con probable infarto al
miocardio, confirmó la Secretaría de Salud local [4]. Por otra parte, la dependencia del Gobierno
del Distrito Federal afirma que brindó dos mil 135 atenciones médicas menores. Entre otros
incidentes de este maratón se mencionan: 2010 en el que se suscitó la muerte de un corredor,
quien se dijo se había ahogado con su goma de mascar y en 2009 murió de un infarto otro
participante; en el Maratón de la Ciudad de México 2012 uno de los participantes, Juan Pablo de
la Mora de 33 años de edad con el número 6072, falleció a consecuencia de un paro cardíaco [5].
Con fundamento en lo anteriormente mencionado, es importante por la seguridad de todos los que
participan en estos eventos tener un control de cada uno de los participantes para así evitar
accidentes o percances fatales, por lo que se propone dar solución a este problema diseñando una
herramienta que permita el monitoreo frecuente de signos vitales del participante y emita alertas
preventivas en caso de ser necesario. De esta forma, los organizadores de dichos eventos
deportivos tendrán un mejor control de la salud de los participantes, y a su vez los participantes
se sientan más seguros de realizar este tipo de actividades.
1.2. Objetivo general
El objetivo general es el siguiente:
 Diseñar e implementar un prototipo de sistema que permita el monitoreo de signos vitales

de un participante en carreras deportivas mediante la aplicación de técnicas
computacionales y electrónicas para el apoyo en la prevención de incidentes de salud
durante la carrera.
1.3. Objetivos específicos
Los objetivos específicos son:
• Diseñar y desarrollar un sistema embebido mediante un dispositivo electrónico para la

obtención de signos vitales del participante.
12
• Implementar una aplicación móvil que visualice la información y que sirva como medio
de comunicación entre el dispositivo electrónico y el participante.
• Desarrollar una aplicación que reciba la información del corredor mediante un servidor.
1.4. Justificación
Las carreras deportivas son una manera sana y divertida de mantener al cuerpo saludable, por lo
que la cantidad de personas interesadas en estas competencias va en aumento. Debido a esto es
difícil para los organizadores de estos eventos mantener un control de cada uno de sus
participantes para evitar cualquier tipo de percance de salud.
Este prototipo será una herramienta de apoyo útil en el monitoreo de cada uno de los
participantes de una carrera. Dicha herramienta está construida mediante un dispositivo
electrónico que el participante llevará consigo, este en conjunto con su teléfono inteligente se
comunicarán inalámbricamente a un servidor, indicando: signos vitales, posición aproximada e
información del participante. Con esta herramienta los organizadores de estos eventos deportivos
podrán tener un mejor control de los participantes. Los participantes, que portarán el dispositivo
electrónico consigo, podrán ir consultando su información en su teléfono inteligente además de
que podrán enviar una alerta ellos mismos si llegasen a necesitarlo.
1.5. Marco teórico
A continuación se abordará la teoría necesaria para fundamentar el prototipo propuesto.
1.5.1. Sistema embebido
Por definición del Instituto Balseiro en Argentina tenemos que: Un sistema embebido consiste en
una electrónica programable especialmente diseñada para aplicaciones específicas,
frecuentemente en tiempo real y con requerimientos de alta confiabilidad.
Lo cual nos da a entender que el nombre de “embebido o empotrado” se deriva del hecho que
forma parte de un sistema mucho más amplio como puede ser un proceso o una máquina de las
que vemos hoy en día.
13
Algunos ejemplos de sistemas embebidos son algunos electrodomésticos, todo tipo de
dispositivos para comunicaciones, equipo de cómputo, motores para auto, tabletas electrónicas
etc.
Los sistemas embebidos son una combinación de hardware y software.
El software de programación puede ser el propio lenguaje ensamblador de la CPU o un lenguaje

de alto nivel con un compilador apropiado o una aplicación visual. Hay disponibles diversos
entornos de desarrollo para la edición, compilación, carga y depuración del software.
La estrecha relación entre hardware y software, nos ha facilitado a nosotros el diseño de

dispositivos muy complejos atendiendo más al proceso de las señales sin tener que involucrarse
en los circuitos electrónicos. De todas maneras un conocimiento más profundo en estos últimos
conduce a obtener una mayor eficiencia. Este tipo de sistemas son los más usados
actualmente [6].
1.5.2. Aplicación móvil
Por definición: Una aplicación móvil (o App como comúnmente se dice) es una aplicación de
software que se instala en dispositivos móviles o tabletas electrónicas para ayudar a los usuarios
en una labor específica, ya sea de carácter profesional o de ocio y entretenimiento.
El objetivo de una aplicación móvil es facilitarnos ciertas tareas que nos llevarían mayor tiempo a
nosotros o asistirnos en operaciones y gestiones del día a día.
Existen infinidad de tipos de aplicaciones: Aplicaciones de noticias, entretenimiento o juegos,

herramientas de comunicación o mensajería, redes sociales, aplicaciones para localizar donde
estamos, promociones comerciales etc., que nos pueden ayudar en el trabajo o intentar hacernos
el día más ameno.
El término App es la abreviatura de “Application” y como tal, siempre se ha utilizado para

denominar a éstas en sus diferentes versiones.
Según el autor, una aplicación siendo una palabra de uso común en el mundo del software, el
término App comenzó a utilizarse especialmente para referirse a las aplicaciones para móviles en
2008, tras la consecución de tres sucesos muy importantes en la historia de las aplicaciones, el
14
lanzamiento del App Store de Apple, la publicación del primer SDK para Android y la posterior
pero casi inmediata inauguración de la tienda de Android para bajar aplicaciones [7].
1.5.3. Sistema de posicionamiento global (GPS)
Según el autor, por definición: El Sistema de Posicionamiento Global (GPS) es un servicio

propiedad de los EE.UU. que proporciona a los usuarios información sobre posicionamiento,
navegación y cronometría. Este sistema está constituido por tres segmentos: el segmento
espacial, el segmento de control y el segmento del usuario. La Fuerza Aérea de los Estados
Unidos desarrolla, mantiene y opera los segmentos espacial y de control.
El GPS se compone principalmente de tres elementos: los satélites en órbita alrededor de la

Tierra, las estaciones terrestres de seguimiento y control, y los receptores del GPS que son los
usuarios que cuentan o hacen uso de este servicio. Desde el espacio, los satélites del GPS
transmiten señales que reciben e identifican los receptores del GPS; ellos, a su vez, proporcionan
por separado sus coordenadas tridimensionales de latitud, longitud y altitud, así como la hora
local precisa (Ver figura 1.1).
Figura 1.1 GPS.
Hoy en día, el sistema GPS está al alcance de todos en el mercado. El usuario puede determinar
con exactitud su ubicación y desplazarse fácilmente al lugar a donde este desee trasladarse, ya sea
caminando, conduciendo, volando o navegando. El GPS es indispensable en todos los sistemas de
transporte del mundo ya que sirve de apoyo a la navegación aérea, terrestre y marítima. Los
servicios de emergencia y socorro en casos de desastre dependen del GPS para la localización y
coordinación de misiones que se encargan de salvar vidas. Actividades cotidianas como
15
operaciones bancarias, de telefonía móvil e incluso de las redes de distribución eléctrica, ganan
en eficiencia gracias a la exactitud que proporciona el GPS.
Muchas personas hoy en día hacen uso de este servicio lo cual los ayuda mucho en sus
actividades diarias [8].
1.5.4. Google Maps
Es un servidor de aplicaciones de mapas en la web que pertenece a Google. Ofrece imágenes de

mapas desplazables, así como fotografías tomadas por medio de un satélite. Desde el 6 de
octubre de 2005, Google Maps (Ver figura 1.2) es parte de Google Local.
Figura 1.2. Logo de Google Maps
Google nos indica lo siguiente: Como todas las demás aplicaciones Google, Maps está
desarrollado principalmente en JavaScript. La carga y el deslizamiento de imagen no podrían
efectuarse sin este código. Es decir, cada cuadrado es almacenado en un fichero cuyo nombre
indica su longitud, su latitud, y el valor del zoom. Recuperar esta información para todos los
cuadrados a colocar, no es sino una cuestión de derivación de los datos conocidos para un solo
cuadrado. Esto podría ser de gran utilidad en el desarrollo del prototipo propuesto para generar
ubicaciones aproximadas [9].
1.5.5. Sistema distribuido
La computación desde sus inicios ha sufrido muchos cambios, ha evolucionado dependiendo de

las necesidades del hombre, desde las grandes computadoras que permitían realizar tareas en
forma limitada y consumo de muchos recursos y de uso exclusivo de organizaciones muy
selectas, hasta las actuales computadoras ya sean personales o portátiles que tienen mayores
capacidades que los primeros, y que están cada vez más introducidos en la vida cotidiana de una
persona.
La definición de un sistema distribuido por el autor Coulouris es la siguiente:

16
Los sistemas distribuidos son sistemas cuyos componentes hardware y software, que están en
ordenadores conectados en red, se comunican y coordinan sus acciones mediante el paso de
mensajes, para el logro de un objetivo. Se establece la comunicación mediante un protocolo
prefijado por un esquema cliente-servidor. [10]
Modelo cliente-servidor
Se puede definir al modelo cliente-servidor como un modelo de comunicación distribuida que

permite a los usuarios finales poder acceder a la información de forma transparente aún en
entornos multiplataforma, esto con el fin de simular un solo sistema homogéneo.
En el modelo cliente-servidor, el cliente envía un mensaje solicitando un determinado servicio a

un servidor (hace una petición), y este envía uno o varios mensajes con la respuesta (provee el
servicio) (Ver Figura 1.3).
En un sistema distribuido, cada máquina puede cumplir el rol de servidor para algunas tareas y el
rol de cliente para otras.
Figura 1.3. Modelo cliente-servidor.
La idea es tratar a una computadora como un instrumento, que por sí sola pueda realizar
muchas tareas, pero con la consideración de que realice aquellas que son más adecuadas a sus
características. Si esto se aplica tanto a clientes como servidores se entiende que la forma más
estándar de aplicación y uso de sistemas cliente-servidor es mediante la explotación de las PC a
través de interfaces gráficas de usuario; mientras que la administración de datos, y su seguridad
e integridad se deja a cargo de computadoras centrales tipo mainframe.
17
Usualmente, la mayoría del trabajo que hace una aplicación se realiza en el servidor y los clientes
sólo se ocupan de la interacción con el usuario (aunque esto puede variar). En otras palabras, el
modelo cliente-servidor es una diferente forma de programar, es una extensión de la
programación modular en la que la base fundamental es separar una gran pieza de software en
módulos y así poder trabajar más eficazmente, esto con el fin de hacer más fácil el desarrollo y
mejorar el mantenimiento de dicho software.
Toda la información es almacenada en el lado del servidor que es el que va a estar obteniendo las
peticiones del cliente, suele tener mayor seguridad que los clientes. Este modelo permite
distribuir físicamente los procesos y los datos en forma más eficiente, lo que en computación
distribuida afecta directamente al tráfico de la red, reduciéndolo grandemente. [11]
1.5.6. Instrumentación electrónica
Por definición: Una computadora está formada por un parte física y otra lógica (hardware &
software), la primera de estas está conformada por los elementos físicos que la conforman
(dispositivos electrónicos y mecánicos), la parte lógica es aquella que determina que procesos se
van a realizar con la información de entrada.
La instrumentación electrónica, que se encarga del diseño y manejo de los aparatos electrónicos,
sobre todo para su uso en mediciones. La instrumentación electrónica se aplica en el uso de un
sensor y el procesamiento de la información proveniente de variables físicas y químicas, a partir
de las cuales realiza el monitoreo y control de procesos industriales, empleando dispositivos,
tecnologías electrónicas e interfaces con sistemas computacionales.
La información de las variables a medir o que se quiera capturar se almacenan en algún tipo de
variable eléctrica, generalmente tensión. Esa variable eléctrica es lo que se denomina señal.
Estas variables se clasifican en analógicas y digitales:
 Variables analógicas: Es aquella que tiene un margen de variación infinito, esto es que
puede tomar infinitos valores.
 Variables digitales: Cuando los datos constituyen un conjunto finito de valores,

normalmente representados en sistema binario.
18
En un sistema de medida se pueden distinguir tres funciones principales: adquisición de datos,
procesamiento de datos y distribución de los datos.
 Adquisición de datos: La información de las variables a medir es adquirida y convertida

en una señal eléctrica.
 Procesamiento de datos: Consiste en el procesamiento, selección y manipulación de los

datos. Esta función suele ser realizada por un procesador digital, microcontrolador,
procesador digital de señales (Digital Signal Processor DSP), etc.
 Distribución de los datos: El valor medido se presenta a un observador (por ejemplo

mediante un display), se almacena (como en un disco o chip de memoria) o se trasmite a
otro sistema.
La adquisición de datos o adquisición de señales, consiste en la toma de muestras del mundo real
(sistema analógico) para generar datos que puedan ser manipulados por un ordenador u otras
electrónicas (sistema digital). Consiste, en tomar un conjunto de señales físicas, convertirlas en
tensiones eléctricas y digitalizarlas.
Se requiere una etapa de acondicionamiento, que adecua la señal del sensor a niveles compatibles
con el elemento que hace la transformación a señal digital (ADC).
La variable del mundo físico es convertida a una señal eléctrica a través de un sensor. Con
frecuencia, la señal procedente del sensor tiene características no aptas para ser procesadas:
señal de muy baja amplitud, espectro grande, baja linealidad, etc. Para ello se necesita la etapa
de acondicionamiento de la señal. El acondicionamiento consiste en la manipulación electrónica
de la señal proveniente directamente del sensor, a través de circuitos acondicionadores, para
obtener rangos de voltajes o corrientes adecuados a las características del diseño
(amplificación, filtrado, liberalización o modulación/demodulación).
 Amplificación: Incrementar el nivel de potencia de la señal.
 Filtrado: Eliminar las componentes de la señal no deseadas.
 Linealización: Obtener una señal de salida que varié linealmente con la variable que se
desea medir.
19
 Modulación / Demodulación: Modificar la forma de la señal a fin de poder transmitirla a
largas distancias o a fin de reducir su sensibilidad frente a interferencias durante el
transporte.
Muchos sensores incluyen toda la circuitería de acondicionamiento, dando lugar a sensores

integrados, que incluso incluyen un conversor A/D que les permite proporcionar una salida
digital.
La conversión analógica-digital (ADC) consiste en la transcripción de señales analógicas en

señales digitales, con el propósito de facilitar su procesamiento (codificación, compresión, etc.) y
hacer la señal resultante (la digital) más inmune al ruido y otras interferencias a las que son más
sensibles las señales analógicas.
El procesamiento es la etapa en la que se realiza una manipulación matemática de una señal

digital. Este está caracterizado por la representación en el dominio del tiempo discreto, en el
dominio frecuencia discreta, u otro dominio discreto de señales por medio de una secuencia de
números o símbolos.
Esto se puede conseguir mediante un procesador o microprocesador que posee un juego de

instrucciones, un hardware y un software optimizados para aplicaciones que requieran
operaciones numéricas a muy alta velocidad. Debido a esto es especialmente útil para el
procesado y representación de señales analógicas en tiempo real: en un sistema que trabaje de
esta forma (tiempo real) se reciben muestras provenientes de un conversor analógico/digital
(ADC). Se puede trabajar con señales analógicas, pero es un sistema digital, por lo tanto
necesitará un conversor analógico/digital a su entrada y digital/analógico en la salida. Como
todo sistema basado en procesador programable necesita una memoria donde almacenar los
datos con los que trabajará y el programa que ejecuta.
La distribución de los datos implica codificar los datos procesados bajo algún principio eléctrico
hacia algún modulo capaz de presentarlos al usuario y/o distribuirlos a otros sistemas de medida
y/o controladores.
Sensores
Como nos dice R. Pallas en su libro titulado Sensores y acondicionadores de señal [12] Un sensor
es un dispositivo capaz de detectar magnitudes físicas o químicas, llamadas variables de
20
instrumentación, y transformarlas en variables eléctricas un sensor a diferencia de un
transductor en que el sensor está siempre en contacto con la variable de instrumentación con lo
que puede decirse también que es un dispositivo que aprovecha una de sus propiedades con el fin
de adaptar la señal que mide para que la pueda interpretar otro dispositivo.
El número de sensores disponibles para distintas magnitudes físicas es tan elevado que existen
diversas clasificaciones de estos.
Los sensores se pueden clasificar de acuerdo a:
 Su aporte de energía
Se pueden dividir en:
o Moduladores o activos: La energía de la señal de salida procede, en su mayor parte

de una fuente auxiliar de energía. La entrada sólo controla la salida.
o Generadores o pasivos: La salida es suministrada solo por la entrada.
 Su modo de funcionamiento
Según su modo de funcionamiento se pueden dividir en sensores de:
o Deflexión: La magnitud medida produce algún efecto físico, que engendra algún
efecto similar, pero opuesto en alguna parte del instrumento, y que está
relacionado con alguna variable útil.
o Comparación: Se intenta mantener nula la deflexión mediante la aplicación de un

efecto bien conocido, opuesto al generado por la magnitud a medir. Hay un
detector de desequilibrio y un medio para restablecerlo.
 Su relación de entrada-salida
Según el tipo de relación entrada-salida, los sensores pueden ser de orden cero, de primer orden,
de segundo orden o de orden superior.
El orden está relacionado con el número de elementos almacenadores de energía independientes

que incluye el sensor, y repercute en su exactitud y velocidad de respuesta. Esta clasificación es
de gran importancia cuando el sensor forma parte de un sistema de control en lazo cerrado.
21
 Su señal de salida
Según la señal de salida los sensores se pueden dividir en:
o Analógicos: La señal varia, a nivel macroscópico, de forma continua. La

información está en la amplitud, se puede incluir a sensores en el dominio
temporal.
o Digitales: La salida varía en forma de saltos o pasos discretos. No requieren

conversión A/D y la transmisión de su salida es muy fácil.
 Su magnitud medida
Para el estudio de un gran número de sensores se suele acudir a su clasificación de acuerdo con la
magnitud medida; temperatura, presión, caudal, humedad, posición velocidad, aceleración fuerza,
par, etc.
Transmisión de datos es la transferencia física de datos (un flujo digital de bits) por un canal de
comunicación punto a punto o punto a multipunto.
• Transmisión analógica: estas señales se caracterizan por el continuo cambio de amplitud

de la señal.
• Transmisión digital: estas señales no cambian continuamente, sino que es transmitida en

paquetes discretos. No es tampoco inmediatamente interpretada, sino que debe ser
primero decodificada por el receptor.[12]
Convertidor analógico-digital
Para procesar señales analógicas por medios digitales es necesario convertirlas a formato
digital, esto es, transformarlas en una secuencia de números. Este procedimiento se denomina
conversión analógico-digital (ADC) [13].
Conceptualmente, se puede ver que la ADC posee un proceso de tres pasos los cuales son (Ver
figura 1.4):
1. Muestreo. Esta es la conversión de una señal en tiempo continuo a una señal en tiempo
discreto obtenida tomando muestras de la señal en tiempo continuo en instantes de tiempo
discreto.
22
2. Cuantificación. Esta es la conversión de una señal en tiempo discreto con valores
continuos a una señal en tiempo discreto con valores discretos (señal digital). El valor de
cada muestra de la señal se representa mediante un valor seleccionado de un conjunto
finito de valores posibles.
3. Codificación. En el proceso de codificación, cada valor discreto se representa mediante

una secuencia binaria de bits.
Figura 1.4. Convertidor Analógico Digital
1.5.7. Dispositivos programables
J. L. H. David A. Patterson [14] nos indica que un dispositivo programable es un elemento capaz
de realizar una tarea específica de procesamiento de información mediante el uso de un lenguaje
de programación para su configuración. Los dispositivos programables de mayor relevancia son
los dispositivos lógicos programables (PLD), microprocesadores y microcontroladores, para
efectos del desarrollo de este prototipo indicaremos las características de un microcontrolador.
Microcontrolador
Es un circuito integrado que contiene un microprocesador de forma interna, con todos los
componentes para poder funcionar de forma autónoma.
Elementos que normalmente integran un microcontrolador:
 Procesador.
 Memoria RAM.
 Memoria de programa ROM/PROM/EPROM.
 Módulos de E/S para comunicarse con el exterior.
23
 Módulos para el control de procesos
 Oscilador interno para generar la señal de reloj
Cada fabricante tiene numerosas variantes de microcontroladores con diferentes prestaciones.
 Temporizadores (Timers).
 Perro guardián (Watchdog).
 Protección frente a fallo de alimentación (Brown-out).
 Estado de bajo consumo.
 Conversores AD y DA.
 Modulador de anchura de pulsos PWM.
 Comparadores Analógicos.
 Puertos de E/S digital.
 Unidad DSP (Procesador digital de señales)
 Interfaces de comunicación: UART, I2C, SPI, CAN, USB.
Algunos microcontroladores cuentan con módulos ADC (Convertidor analógico-digital) para
digitalizar señales que son obtenidas de manera análoga. El voltaje de salida de este sensor es
convertido a valores digitales (0 y 1).
1.6. Estado del arte
En esta sección se abordarán los sistemas similares al prototipo propuesto.
En la actualidad existen diversos sistemas similares al prototipo propuesto, entre los más
destacados se encuentran:
1. Trabajo Terminal “Sistema de Monitoreo de Pulso Cardiaco y Temperatura Corporal para

el Entrenamiento Deportivo”.
Este sistema tiene como finalidad dotar al deporte de una herramienta que permita el
monitoreo de los signos vitales de un atleta para que estos sean un referente en la práctica
deportiva de tal forma que se incremente su rendimiento físico. Los resultados de este
trabajo brindarán al entrenador una mayor eficiencia y efectividad al replantear el
programa de entrenamiento durante la sesión deportiva para dosificar la carga de trabajo
del atleta [15].
24
2. Proyecto de investigación “Vigilancia y Análisis Continuo de Signos Vitales (VACS)” del
Instituto de Ciencias Nucleares (ICN) de la UNAM.
Detectar en tiempo real arritmias cardiacas, temperatura, desplazamientos e incluso caídas
de adultos mayores es posible con un brazalete electrónico, cuyo diseño coordina
Benjamín Alejandro Morales Ruiz en el Instituto de Ciencias Nucleares (ICN) de la
UNAM. Este desarrollo, equivalente a un botón de ayuda inteligente, es parte del
proyecto Vigilancia y Análisis Continuo de Signos Vitales (VACS), que además integra
plataforma de servicios de telemetría y tele-asistencia.
Mediante el monitoreo en tiempo real del pulso cardiaco, la movilidad, geolocalización y
temperatura, el sistema pretende tomar control del estado de salud general del usuario
mediante la generación de una serie de servicios, lo que permitirá ofrecer seguridad y
tranquilidad, tanto a los usuarios como a sus familiares [16].
3. Proyecto de investigación “Sistema Telemétrico De Monitoreo Cardiaco Y Variables
Hombre-Máquina Aplicado Al Ciclismo” de la Facultad de Ingeniería, Escuela de
Ingeniería Electrónica, Universidad Central
Sistema de monitorización mediante telemetrías del ritmo cardiaco y variables hombre-
máquina empleadas en el entrenamiento de ciclistas tanto en ruta como en pista.
Este sistema consta de una unidad remota móvil (URM) acoplada a la bicicleta que
digitaliza, registra, procesa y envía la información por un medio inalámbrico, a una
unidad base móvil (UBM) la cual se conecta a un computador donde se visualizan en
tiempo real las variables monitoreadas en el deportista. Además el equipo tiene la
capacidad de operar con uno u ocho ciclistas al mismo tiempo, almacenar, visualizar,
graficar e imprimir la información adquirida [17].
4. “Podium. Chamarra inteligente para corredores”.
La prenda, llamada Podium, está dirigida a corredores. Cuenta con sensores para medir el
ritmo cardiaco, temperatura corporal, cantidad de calorías quemadas en cada rutina y
hasta puede registrar los recorridos en tiempo real. Puede conectarse a teléfonos y guardar
información en la nube [18].
5. “Simband. Salud Digital de Samsung”.
Samsung tiene su propio diseño de sensores, su Plataforma de Sensores Avanzada. El
sensor se basa en la detección de luz. La luz reflejada proporciona información sobre lo
25
que hay en el cuerpo, y junto con otros sensores, permiten medir de forma continua la
temperatura de la piel, la presión arterial, etc. [19].
6. “Smart Run. El reloj al ritmo de los atletas.”
Adidas, a la vanguardia de la innovación en equipamiento deportivo, diseñó el Smart Run,
un reloj multifuncional que tiene como objetivo optimizar el entrenamiento atlético. Este
dispositivo cuenta con monitoreo cardiaco integrado a través de un sensor óptico, por
medio de un GPS incorporado controla la velocidad, distancia y ruta recorridas, además
de que se conecta por Bluetooth 4.0 a audífonos [20].
A continuación se muestra una tabla comparativa (Tabla 1) entre los sistemas existentes y el
Trabajo Terminal que se propone.
FORMA DE
INTERFAZ DE
SOFTWARE CARACTERÍSTICAS SALIDA DE
COMUNICACIÓN
INFORMACIÓN
Trabajo Terminal Medición del pulso
“Sistema de cardíaco y temperatura
Monitoreo de Pulso corporal de forma Comunicación
Cardiaco y inalámbrica para su uso Interfaz gráfica Serial Mediante
Temperatura Corporal en la sesión de Radiofrecuencia
para el Entrenamiento entrenamiento
Deportivo” deportivo.
Proyecto de
investigación
Monitoreo en tiempo
“Vigilancia y Análisis
real del pulso cardiaco,
Continuo de Signos Conexión de datos
la movilidad, geo- Interfaz gráfica
Vitales (VACS)” del de telefonía móvil.
localización y
Instituto de Ciencias
temperatura.
Nucleares (ICN) de la
UNAM
Proyecto de
investigación
“Sistema Telemétrico
De Monitoreo
Cardiaco Y Variables Monitoreo de ritmo
Hombre-Máquina cardíaco, porcentaje de Radiofrecuencia con
Aplicado Al esfuerzo, velocidad, Interfaz gráfica una banda de 902-
Ciclismo” de la cadencia, metros 928MHz
Facultad de recorridos.
Ingeniería, Escuela de
Ingeniería
Electrónica,
Universidad Central
26
Monitoreo del ritmo
“Podium. Chamarra cardiaco, temperatura
Bluetooth, wi-fi,
inteligente para corporal, calorías Interfaz gráfica
conexión de datos
corredores” quemadas y recorridos
en tiempo real.
Monitoreo de: presión
arterial, su ritmo de
respiración, la
“Simband. Salud
frecuencia cardíaca, el Pantalla LCD WiFi y Bluetooth
Digital de Samsung”
nivel de hidratación y
cantidad de dióxido de
carbono en sangre.
Sensor de ritmo cardíaco
sin correas totalmente
integrado; velocidad,
distancia, cadencia y
“Smart Run. El reloj ruta basadas en el GPS
Pantalla LCD WiFi y Bluetooth
al ritmo de los atletas” Interacción del usuario
con un solo botón
SMART RUN requiere
acceso a Internet con
WLAN para funcionar.
Monitoreo del
participante mediante el
uso de un dispositivo
electrónico que, en
conjunto con un teléfono
inteligente se
comunicarán
Sistema de alerta y Aplicación que
inalámbricamente a un
monitoreo de reciba la Bluetooth, Wifi y
servidor y que indicarán
participantes en información del conexión de datos
en una aplicación que
carreras deportivas. participante, de telefonía móvil
reciba la información
(Solución Propuesta). Aplicación móvil
del atleta: signos vitales,
posición exacta e
información del
participante. Además
emitirá alertas
preventivas en caso de
ser necesario
Tabla 1.1. Resumen de sistemas o productos similares.
27
CAPÍTULO 2. ANÁLISIS
En este capítulo se elaborará un análisis del prototipo propuesto.
2.1. Metodología
Antes que nada, definiremos la metodología que se seguirá durante el desarrollo de este
prototipo. Durante el desarrollo de este proyecto, se pretende en una primera instancia analizar
las características técnicas y operativas del sistema.
Posteriormente se diseñará y desarrollará tanto la parte del hardware como del software que
consta principalmente de: el dispositivo electrónico, la aplicación móvil y la aplicación de web.
Se pretende usar una metodología en V [21] que consiste en 7 fases que se enlistan a
continuación:
• DEFINICIÓN DE ESPECIFICACIONES (Fase 1): Se definirán y documentarán los
diferentes requisitos del sistema a desarrollar, identificando los valores numéricos más
concretos posibles. Entre ellos debe estar la especificación del nivel de integridad, o
SIL, en caso de ser requerido.
• DISEÑO GLOBAL (Fase 2): También llamado diseño de alto nivel. Su objetivo es
obtener un diseño y visión general del sistema.
• DISEÑO EN DETALLE (Fase 3): Consiste en detallar cada bloque de la fase anterior.
• IMPLEMENTACIÓN (Fase 4): Es la fase en la que se materializa el diseño en detalle.
• TEST UNITARIO (Fase 5): En esta fase se verifica cada módulo de hardware y software
de forma unitaria, comprobando su funcionamiento adecuado.
• INTEGRACIÓN (Fase 6): En esta fase se integran los distintos módulos que forman el
sistema. Se comprueba el cumplimiento de los requisitos establecidos.
• TEST OPERACIONAL DEL SISTEMA (Fase 7): Se realizan las últimas pruebas pero
sobre un escenario real, en su ubicación final, anotando una vez más las pruebas
realizadas y los resultados obtenidos.
En la Figura 2.1 se indican las etapas del proceso que sigue esta metodología para el desarrollo
del sistema.
28
Figura 2.1. Modelo en V del ciclo de vida del sistema.
2.2. Análisis de requerimientos
En este punto se hará un análisis de cada una de las aplicaciones que conforman el prototipo
propuesto, indicando también los requerimientos funcionales y no funcionales.
Se dividirá en participante (persona que realizará la carrera) y organizador (organizadores de

carreras deportivas)
Dispositivo electrónico
El dispositivo electrónico se encargará de captar el pulso cardíaco y la temperatura del

participante, a su vez este mediante un módulo bluetooth enviará la información al dispositivo
móvil.
Requerimientos funcionales y no funcionales
Estos requerimientos se indicarán en la tabla 2.1
Requerimientos funcionales Requerimientos no funcionales

Organizador  El organizador podrá encender o apagar el  Los organizadores no podrán
dispositivo además de que deberá ajustarlo en el modificar la estructura física el
participante dependiendo de su complexión dispositivo.
física.
Participante  Los participantes deberán portar el dispositivo  Los participantes no podrán
electrónico en el lugar indicado por el modificar la estructura física el
organizador de manera que sea posible la dispositivo.
medición de los signos vitales.  No podrán retirarlo del lugar
del cuerpo indicado por el
organizador durante la carrera.
Tabla 2.1. Requerimientos funcionales y no funcionales del dispositivo electrónico
29
Aplicación móvil
La aplicación recibirá la información enviada del dispositivo electrónico mediante bluetooth y

esta a su vez la enviará a un servidor, el cual a su vez lo enviará a una aplicación principal para su
procesamiento, también enviará en caso de ser necesario, un mensaje de que el participante envió
una alerta de auxilio y su ubicación aproximada.
En caso de que el participante desee consultar su historial de signos vitales o sus signos vitales
actuales, la aplicación móvil deberá desplegarla en pantalla.
Estos requerimientos se indicarán en la tabla 2.2

Organizador  El organizador otorgará un nombre de usuario y  No podrá registrar varias
contraseña a los participantes para que puedan veces a un participante u
iniciar sesión. Además el registrará nuevos organizador o tener varios
organizadores de ellos con el mismo
 El organizador atenderá las alertas enviadas ya sean identificador.
manuales o las generadas automáticamente de la
aplicación móvil.
Participante  El participante podrá iniciar y cerrar sesión en la  El participante no podrá
aplicación móvil. visualizar los datos de
 Los participantes podrán consultar sus datos alguien más, la aplicación
mediante la aplicación móvil en cualquier momento desplegará la información
durante la carrera. única y exclusivamente de
 La aplicación deberá desplegar: número de manera personal.
participante, nombre, edad, sexo y signos vitales.  El participante no podrá
 Si el participante llegara a necesitar auxilio por modificar su información en
cualquier otra razón podrá enviar una alerta de la aplicación móvil ya que
manera manual mediante un botón en la aplicación esta es únicamente de
móvil. consulta de datos.
 La aplicación generará en un historial los signos  La exitosa comunicación
vitales del participante, esta información será estará sujeta al servicio de
almacenada cada determinado tiempo (este lo datos o servicio de wifi,
determinará el organizador), además agregará al localización del teléfono y
historial las alertas generadas durante la carrera. la batería del mismo.
Este historial podrá ser consultado por el
participante al finalizar su participación.
 La aplicación además de enviar al servidor las
alertas y la información del participante, también
enviará su ubicación aproximada.
Tabla 2.2. Requerimientos funcionales y no funcionales de la aplicación móvil
30
Aplicación Web
La aplicación mandará una petición al servidor para obtener los datos enviados desde la
aplicación móvil.
La aplicación desplegará la información obtenida por el servidor en una interfaz web, a su vez irá
generando un historial de los participantes de la carrera y resaltará a los participantes que
necesiten auxilio.
El servidor contendrá la base de datos donde se podrán insertar, eliminar y actualizar la

información de participantes y organizadores. Podrá recibir peticiones de la aplicación web y de
la aplicación móvil. Enviará la información que les sea requerida por estas aplicaciones.
Se propuso como aplicación que reciba la información del participante a una aplicación web,
estos requerimientos se indicarán en la tabla 2.3.
 Podrá visualizar si algún participante manda una  No podrá registrar varias

alerta. veces a un participante o
 Podrá registrar, eliminar y modificar la información tener varios participantes
de los organizadores, participantes y carreras. con el mismo identificador.
 En caso de que un participante necesite auxilio, el
organizador alertará a las autoridades
correspondientes.
Organizador
 El organizador deberá registrar correctamente la
información proporcionada por el participante.
 El organizador deberá monitorear constantemente la
información enviada a la aplicación.
 Podrán visualizar la información actualizada de los
participantes (signos vitales y ubicación
aproximada) durante una carrera.
 Los participantes deberán proporcionar la  El participante no podrá
información necesaria para el correcto seguimiento visualizar los datos de
de su salud los cuales serán principalmente: alguien más, la información
nombre, edad, sexo y si es necesario algún otro dato única y exclusivamente de
Participante
que se considere de relevancia (se guardará manera personal.
únicamente como observaciones).  El participante no podrá
modificar su información
personalmente.
Tabla 2.3. Requerimientos funcionales y no funcionales de la aplicación web
31
Requerimientos generales del sistema
A continuación se enlistan los requerimientos mínimos generales para el correcto funcionamiento

del sistema.
 El sistema solo requerirá de la presencia de un servidor, independientemente de cual S.O

se esté ejecutando.
 Computadora portátil para pruebas con acceso a internet.
 El Sistema Gestor de Base de Datos que utilizará el sistema será desarrollado en MySQL.
 Android será el sistema operativo móvil en el cual la aplicación móvil se desenvolverá.
 El participante debe tener un teléfono con servicio de datos y que soporte Android.
 Tener instalado un explorador Internet Explorer 7 o equivalente, en adelante.
 1 GB de memoria RAM
 Procesador Intel Atom a 1.66 Ghz o equivalente
2.3. Reglas del negocio
A continuación en la tabla 2.4 se indica un listado de las principales reglas del negocio que rigen
el sistema.
Regla Descripción
RN0 El sistema: El sistema contará con organizadores (organizadores de las carreras) y participantes (atleta o
participante). Además de estar conformado por tres módulos principales (dispositivo electrónico, dispositivo
móvil y aplicación principal)
RN1 Alertas: Las alertas generadas se enviarán directamente al servidor y de ahí a la aplicación principal del
sistema.
RN2 Ubicación: La ubicación enviada desde el dispositivo del participante es aproximada.
RN3 Información: Toda la información enviada entre los diferentes módulos del sistema está sujeta al servicio
de datos con el que cuente el teléfono móvil del participante o el servicio WiFi de la zona.
RN4 Información personal: Toda la información proporcionada por el participante se usará únicamente como
prevención de un accidente.
RN5 Registro de participantes: Los números de participante son únicos y no se podrán duplicar. Solo los
participantes podrán registrar los organizadores.
RN6 Registro de organizadores: El organizador podrá registrar organizadores en la aplicación web y móvil.
RN7 Búsqueda de los datos: El organizador podrá buscar al participante por medio de su número de
participante.
RN8 Evaluación de signos vitales: Los diagnósticos hechos por el sistema no sustituyen a las de un médico, se
utilizarán como base para el diagnóstico los signos vitales mostrados en la tabla 3.
32
RN9 Generación de historiales de signos vitales: El participante y los organizadores podrán usar los historiales
como mejor les convenga.
RN10 El participante: Deberá portar en el lugar indicado por el organizador el dispositivo electrónico, además de
contar con un dispositivo móvil con servicio de datos para el correcto envío de información.
RN11 El participante: Deberá ser mayor de edad (mayor de 18 años) y no deberá sobrepasar la edad de 70 años,
ya que el rango que se considera para hacer el diagnostico no permite a personas que no cumplan con este
requisito.
RN12 Aplicación web. La aplicación web podrá utilizarse sujeto al servicio de internet del área donde se realice la
carrera.
RN13 Carreras: Las carreras deportivas únicamente englobarán a las que el participante no esté en contacto con
ambientes que impliquen agua o humedad, debido a que puede haber fallas en el dispositivo electrónico.
Tabla 2.4. Reglas del negocio

2.4. Viabilidad técnica y legal
A continuación se detallan la viabilidad técnica y legal del prototipo propuesto.
Viabilidad técnica
En esta sección se analizará la viabilidad técnica del prototipo propuesto.

La enciclopedia de la salud de University of Rochester Medical Center [22] nos indica lo
siguiente: Los signos vitales son mediciones de las funciones más básicas del cuerpo. Los cuatro
signos vitales principales que monitorizan de forma rutinaria los profesionales médicos y
proveedores de atención médica son los siguientes: la temperatura corporal; el pulso cardíaco;
la frecuencia respiratoria (ritmo respiratorio); la presión arterial (si bien no se considera a la
presión arterial como un signo vital, por lo general se la controla junto con los signos vitales).
Con base en lo anterior consideramos lo siguiente:
Víctor R.G. [23] nos indica las consideraciones que se deben tomar para la medición de la
presión arterial. Son las siguientes:
 Descansar durante al menos 5 minutos antes de tomarla.
 No tomar la presión arterial cuando esté bajo estrés, haya consumido cafeína o usado un
producto de tabaco en los últimos 30 minutos o haya hecho ejercicio recientemente.
 Permanecer sentado.
Tomando en cuenta lo anterior no será posible tomar la presión arterial en cuenta para la
realización de este prototipo ya que en una carrera deportiva el participante estará constantemente
activo.
33
Los autores de libro Fundamentos de enfermería Vol. 1 y Vol. 2, J.M. Wilkinson.B. Kozier. G.
Erb y K. Blais [24] nos indican que al momento de medir la frecuencia respiratoria, la persona a
evaluar debe permanecer en reposo, no debe estar consiente que su frecuencia respiratoria será
medida y preferentemente debe estar en decúbito supino (acostado boca arriba) por esta razón no
será posible tomar este signo vital en cuenta para la realización de este prototipo ya que el
participante estaría consiente de que su respiración está siendo medida y se va a encontrar
realizando actividad física.
Adicionalmente, un artículo escrito por Gatorade “Sports Science Institute” [25] nos indica que
La evaluación inicial de un deportista que sufre un colapso en el terreno de juego debe de
comenzar con una evaluación rápida del nivel de consciencia del deportista. Si el deportista está
despierto y alerta, la causa del colapso es probablemente benigna. En aquellos con un nivel de
consciencia reducido se debería evaluar si se requiere resucitación cardiorrespiratoria. Los
signos vitales a monitorizar tan pronto como sea posible incluyen la temperatura corporal y la
frecuencia cardiaca. El cerebro es el órgano más delicado del que dispone el ser humano. La
falta de oxígeno ocasionará, en poco tiempo, lesiones irreversibles produciéndose la muerte en 8
- 10 minutos. Por lo tanto cualquier paro cardiaco (fracaso de las funciones cardíaca y/o
respiratoria, con la consiguiente incapacidad para hacer llegar sangre oxigenada a las células)
es una situación de máxima emergencia ya que del tratamiento inmediato dependerá la vida del
paciente, la temperatura corporal alta o el llamado golpe de calor puede conducir a un daño
orgánico serio o incluso a la muerte si no se tratan rápidamente y de manera apropiada. El
lugar donde el deportista sufre el colapso es una pista de la gravedad del episodio, un colapso
tras la competencia es menos importante que si sucede durante ésta.
J.M. Wilkinson.B. Kozier. G. Erb y K. Blais [24] nos indican que el pulso cardíaco de una
persona es la pulsación provocada por la expansión de sus arterias como consecuencia de la
circulación de sangre bombeada por el corazón. Se obtiene por lo general en partes del cuerpo
donde las arterias se encuentran más próximas a la piel. Para la correcta medición del pulso
cardíaco se debe situar el aparato de medición cerca de alguna de estas arterias principales, que
son: arteria carótida (cuello), femoral (pierna) o braquial (brazo). Esta medición puede hacerse en
cualquier momento para evaluar la condición del paciente y en actividad física nos sirve para
saber si el corazón está soportando la actividad que está realizando, así que se podrá incluir en la
realización de este prototipo.
34
Health Information [26] nos indica que la temperatura corporal, para mayor exactitud, debe
medirse en el lóbulo de la oreja, la frente, la axila o el recto, ya que es una medida de la
capacidad del cuerpo para generar y liberarse del calor, se propone que la medición sea en el
lóbulo de la oreja así que podrá incluirse en el prototipo. Cuando se tiene demasiado calor, los
vasos sanguíneos en la superficie de la piel se expanden (dilatan), para llevar el exceso de calor a
la superficie de la piel. En el deporte pueden llegar a suceder los llamados “golpes de calor” o
aumento considerable en la temperatura en los deportistas, el golpe de calor no suele ser la causa
de los colapsos pero cuando lo es, puede ser fatal si no se diagnostica pronto y si no se trata
inmediatamente con inmersión en agua helada hasta enfriar.
Por lo anteriormente mencionado, concluimos que las variables a medir para este prototipo serán:
El pulso cardíaco y la temperatura corporal.
Para efectos de este prototipo, se debe considerar el número de pulsaciones y temperatura

principalmente cuando el participante está activo o realizando actividad física (durante la
carrera). A continuación, en la tabla 2.5 se indican los valores normales de estos dos signos
vitales tomando en cuenta que esto puede variar dependiendo de la edad y sexo según la
Asociación de Alto Rendimiento, ciencia deportiva y fitness [27] y WILMORE, Jack H. y
COSTILL, David L. Fisiología del esfuerzo y del deporte [28].
Hombres Mujeres
Temperatura Temperatura
Pulso Cardíaco Pulso Cardíaco
Corporal Corporal
Edad (mínimo- (mínimo-
(mínimo- (mínimo-
máximo) máximo)
máximo) máximo)
18-20 90-200 35.5 – 39 °C 88-190 35.5 – 39 °C
25 86-196 35.5– 39 °C 86-198 35.5– 39 °C
30 82-192 35.6 – 39 °C 80-195 35.6 – 39 °C
35 77-187 35.9 – 39 °C 76-193 35.9 – 39 °C
40 73-183 36.1 – 39 °C 71-190 36.1 – 39 °C
45 69-179 36.3 – 39 °C 70-185 36.3 – 39 °C
50 65-175 36.7 – 39 °C 65-180 36.7 – 39 °C
55 60-170 36.8 – 39 °C 60-176 36.8 – 39 °C
60 60-166 36.8 – 39 °C 60-170 36.8 – 39 °C
65 60-162 36.9 – 39 °C 60-167 36.9 – 39 °C
70 60-158 36.9 – 39 °C 60-163 36.9 – 39 °C
Tabla 2.5. Signos vitales
35
Es de importancia indicar que los valores manejados en este prototipo varían de acuerdo a edad,
sexo, salud y estilo de vida de cada persona, entre otros factores
Ya definidos los signos vitales a medir y con base a los requerimientos previamente establecidos,
a continuación se muestra un estudio comparativo de los componentes electrónicos principales a
usar, los cuales serán:
1. Medición del pulso cardíaco. (Sensor de pulso cardíaco)

2. Medición de temperatura. (Sensor de temperatura)
3. Módulo Bluetooth (para la comunicación del dispositivo electrónico a la aplicación del
dispositivo móvil)
4. Microcontrolador (para recibir y procesar lo obtenido por los sensores)
5. Fuente de alimentación (para alimentar al dispositivo electrónico)
6. Regulador (Para regular la energía suministrada al dispositivo electrónico)
Como será un dispositivo portable, tomaremos en cuenta para la elección sea de bajo consumo de
energía y el tamaño.
En la tabla 2.6 se muestra un estudio comparativo para el primer componente (sensor de pulso
cardíaco). En esta tabla se indica remarcado el sensor que se eligió y después la justificación del
porqué se eligió.
Interfaz
Corriente
de Bits de Voltaje de
Dispositivo Tipo que Fabricante Precio
comunica- resolución alimentación
consume
ción
PulseSensor Analógi- 25.00
N/A N/A 3V a 5V 4mA pulsesensor.com
[29] co USD
Model 1020
Analógi-
infrared pulse 25.00
co (5-50 N/A N/A 6V a 9V 20mA UFI
plethysmograph USD
mV)
[30]
3V cuando
14.95
RMCM01 [31] Digital detecta N/A 2.5V a 3.4V 60 mA POLAR
USD
latido
Analógi-
Heartbeat Pulse
co SUNROM 22.64
Sensor - Analog N/A N/A 3V a 5.25V 7 mA
(Rango TECHNOLOGIES USD
Out [32]
0-5V)
Tabla 2.6. Estudio Comparativo Sensor de Pulso Cardíaco
36
Justificación: Se eligió el componente PulseSensor como sensor de pulso cardíaco, ya que es el
que consume menor corriente.
¿Cómo medirá PulseSensor el pulso cardíaco? Las arterias principales son las que transportan
oxígeno a todo el cuerpo, cuando en las arterias pasan grandes cantidades de sangre oxigenada
estas cambian de color, es aquí cuando el sensor de pulso cardíaco capta el cambio de color. El
sensor consiste en un emisor infrarrojo y un detector montado a un lado y debe estar presionado
contra la piel. Cuando el corazón bombea, la presión en las arterias (por el transporte de la
sangre) se eleva considerablemente y lo mismo ocurre con la cantidad de luz infrarroja
procedente del emisor que se refleja en el detector. [29] [33].
Al ser este sensor uno de tipo “Analógico” requerirá que el microcontrolador tenga puertos A/D
para convertir la señal analógica obtenida a digital.
Hay que tener en cuenta para la medición del pulso cardíaco lo siguiente:
La frecuencia cardiaca es el número de veces que se contrae el corazón durante un minuto

(latidos por minuto). Para el correcto funcionamiento del organismo es necesario que el corazón
actúe bombeando la sangre hacia todos los órganos. La frecuencia del pulso cardíaco es de
aproximadamente 3.3 Hz (esto tomando en cuenta que la pulsación máxima es de 200 ppm,
queremos obtener cuantas pulsaciones tiene por segundo, es decir 200/60 = 0.3, y siguiendo la
fórmula 1/t para obtener la frecuencia, nos queda que 1/0.3 es de 3.3 Hz).
El corazón tiene dos movimientos:
Uno de contracción llamado sístole y otro de dilatación llamado diástole. Pero la sístole y la
diástole no se realizan a la vez en todo el corazón, se distinguen tres tiempos:
Sístole: se contraen las aurículas y la sangre pasa a los ventrículos que estaban vacíos.
Diástole: Las aurículas y los ventrículos se dilatan, al relajarse la musculatura, y la sangre entra
de nuevo a las aurículas.
Los golpes que se producen en la contracción de los ventrículos originan los latidos [34].
La señal de pulso cardiaco habitual tiene dos principales ondas (Ver figura 2.2):
 Onda P: Representan la despolarización de los dos atrios cardíacos (Sístole).
37
 Onda T: Representa la repolarización ventricular (Diástole).
Figura 2.2. Ondas del pulso cardíaco
Para el procesamiento de esta señal, es decir pasar del dominio del tiempo al dominio de la
frecuencia, proponemos un algoritmo para esto. En la tabla indicamos los diferentes algoritmos
que existen y su grado de complejidad computacional.
Algoritmo Grado de complejidad

computacional
Transformada rápida de Fourier n·log2(n).
Transformada discreta de n2
Fourier
Auto-correlación n
2.7. Algoritmos de procesamiento
El algoritmo de menor complejidad es el de auto-correlación, así que se propone emplearlo para

el procesamiento de la señal de pulso cardíaco.
Adicionalmente, para eliminar las componentes no deseadas de la señal de pulso cardíaco, se

empleará un filtro.
Para elegir el componente encargado del filtrado de la señal, en la tabla 2.7 se indica un estudio
comparativo entre los principales filtros en el mercado, considerando principalmente su tamaño y
que sea de bajo consumo de energía. El filtrado [35] es un proceso por el que el contenido de
frecuencia de una señal es alterado.
38
Los filtros eliminan frecuencias indeseadas. Dependiendo del rango de frecuencia que dejan pasar
o minimizan, se clasifican de la siguiente forma:
 Filtro de paso bajo: Deja pasar frecuencias bajas pero minimiza las altas frecuencias.
 Filtro de paso alto: Deja pasar frecuencias altas pero minimiza las bajas.
 Filtro de paso de banda : Pasan las frecuencias que están dentro de un cierta banda de
frecuencias
 Filtro bandstop: Minimiza las frecuencias de una cierta banda
Voltaje
Corriente
Máxima de Voltaje de
de Preci
Dispositivo Tipo frecuencia Orden alimenta alimentació Fabricante
alimentació o
de corte ción n
n
Dual
MAX295 Pasa 3.92

0.1 - 50 Hz 8vo ±5V 5V 7 – 15 mA MAXIM
[36] bajas USD
MAX7411[ Pasa 0.2µA - 2.13

1 - 50 Hz 5to - 5V MAXIM
37] bajas 1.2mA USD
TEXAS
LMF100 Pasa 0.1 - 100 4.16
2do ±5V 5V 8 -12 mA INSTRUMENT
[38] bajas Hz USD
S
MAX7419 Pasa 0.2µA - 2.13

1 - 50 Hz 5to - 5V MAXIM
[39] bajas 3mA USD
MAX7400 Pasa 3mA- 3.15

1- 10 KHz 8vo ±5V 5V MAXIM
[40] bajas 0.2µA USD
Tabla 2.8. Estudio comparativo de filtros

Con el fin de poder captar con más facilidad la onda T (Diástole) indicada en la figura 2.2, se
propone utilizar un filtro pasa bajas y uno que sea de bajo consumo de energía, es de octavo
orden y el precio es menor a otros con las mismas características, para esto se eligió el
componente MAX295.
El filtro recibirá dos frecuencias, una es la frecuencia cardíaca y otra será nuestra frecuencia de
corte. Para saber la frecuencia de corte tenemos que un Hercio (Hz) es equivalente a un ciclo por
39
segundo. Si tomamos en cuenta los valores indicados en la tabla 2.8, considerando un máximo de
200 latidos por minuto, entonces frecuencia de corte (fc) = 200/60=3.3 (Redondeado a 4). La hoja
de datos del filtro MAX295 elegido en la tabla, nos indica que debemos suministrar 50 veces la
frecuencia máxima de corte. Por lo que se tiene 4x50=200 Hz, estos son los Hertz que se le
suministrarán al filtro. Lo anterior nos servirá para la fase de pruebas.
En la tabla 2.9 se muestra un estudio comparativo para el segundo componente (sensor de

temperatura). En esta tabla se indica remarcado el sensor que se eligió y después la justificación
del porqué se eligió.
Corriente
Interfaz de Bits de Voltaje de Precio
Dispositivo Tipo que Fabricante
comunicación resolución alimentación aproximado
consume
AT30TSE752A 2-Wire I2C y Configurable

Digital 1.7 – 5.5 V 1 – 75 µA ATMEL 1.22 USD
[41] SMBus 9-12 bits
170 – 430
EMC1414 [42] Digital SMBus 8 3.3V Microchip 1.09 USD
µA
0.750 – 1
DS18B20 [43] Digital 1-Wire 12 3.0V – 5.5V MAXIM $50.00 M.N.
mA
1 – 200
MCP9801 [44] Digital 2-Wire 12 2.7V – 5.5V Microchip 1.12 USD
µA
0.1 - 250
TC77 [45] Digital SPI 13 2.7V - 5.5V Microchip 0.92 USD
μA
Tabla 2.9. Estudio Comparativo Sensor de Temperatura
Justificación: Se eligió el componente TC77 como sensor de temperatura por su bajo consumo de
corriente y su costo menor al de los demás componentes considerados. Adicionalmente de los
dos encapsulados disponibles, elegimos el encapsulado SOT-23-5 por ser de menor tamaño a
comparación del SOIC. ¿Cómo medirá TC77 la temperatura? Al aumentar la temperatura
aumenta la conducción en los semiconductores. Al ser el TC77 un diodo (tiene semiconductores)
al aumentar la temperatura, aumenta el voltaje de salida y si baja disminuye el voltaje [45].
En la tabla 2.10 se muestra un estudio comparativo para el tercer componente (módulo

bluetooth). En esta tabla se indica remarcado el módulo que se eligió y después la justificación
del porqué se eligió.
40
Corriente
Interfaz de Voltaje de
Dispositivo Standard Modo que Fabricante Precio
comunicación alimentación
consume
Master
Bluetooth 25 – 65 Roving 26.40
RN-41 [46] and UART 3V a 3.6V
2.1 mA Network USD
Slave
Bluetooth $129.00
HC-06 [47] Slave UART 3V a 4.2V 25-40mA rcscomponents
2.1 M.N.
Master 0.348 - ISSSC
Bluetooth 13.77
BM77 [48] and UART 3.2 a 4.3V 13.073 Techonologies
4 USD
Slave mA Corp.
Master
SPBT2632C1A Bluetooth 0.49-27.7 Life 15.00
and UART 2.0 – 3.6V
[49] 3 mA augmented USD
Slave
Master
Bluetooth 79.55
OBS421 [50] and UART 3.0 – 6.0V 0.6-44 mA u-blox
4 USD
Slave
Tabla 2.10. Estudio Comparativo Módulo Bluetooth
Justificación: Se eligió el componente HC-06 como módulo bluetooth ya que solo se ocupará en
modo esclavo porque no es necesario que el inicie la conexión esto debido a que el que siempre
va a iniciar la conexión es el dispositivo móvil para la recopilación de la información, este
último posee una interfaz de gestión de conexión para ello.
En la tabla 2.11 se muestra un estudio comparativo para el cuarto componente

(microcontrolador). En esta tabla se indica remarcado el microcontrolador que se eligió y después
la justificación del porqué se eligió.
Co-
M No. U Memoria Voltaje
Puer S I rrien-
Micro – I Arquitec Oscila de A de Fabri- de Pre
tos P 2 te que
controlador P tura dor puer R programa cante alimenta cio
A/D I C consu
S tos T (KB) ción
me
30 3.3
PIC24F08K 1 8 Microc 1.8V a nA - 7
Harvard 20 12 1 1 1 8 150
L201 [51] 6 MHz hip 3.6V US
µA D
30 3.3
PIC24F08K 1 8 Microc 1.8V a nA - 7
Harvard 20 12 2 2 2 3
L302 [52] 6 MHz hip 3.6V 150 US
µA D
30 2.5
PIC24F16K 1 Microc 1.8V a nA- 0
Harvard 8MHz 20 12 2 2 2 16
L401 [53] 6 hip 3.6V 150 US
µA D
41
1- 3.0
ATtiny87 1 16MH 1.8V a 100 9
RISC 20 11 1 2 1 8 Atmel
[54] 6 z 5.5V µA US
D
0.1 - 1.5
Texas
MSP430F1 1 1.8V a 200 7
RISC 8MHz 20 6 2 2 0 10 Instrum
10 [55] 6 3.6V µA US
ents
D
Tabla 2.11. Estudio Comparativo Microcontrolador
Justificación: Se eligió el componente PIC24F16KL401 como microcontrolador debido su bajo

consumo de corriente, además que su memoria de programa es mayor al de los demás
componentes lo cual nos ayudará a no estar limitados en la programación del componente.
Adicionalmente, el encapsulado será PDIP 20 pin por ser el de menor tamaño.
En la tabla 2.12 se muestra un estudio comparativo para el sexto componente (regulador). En esta
tabla se indica remarcado el regulador que se eligió y después la justificación del porqué se
eligió.
Corriente de Voltaje de
Dispositivo Voltajes de salida Fabricante Precio
salida entrada
MAX6349TLUT-T Maxim 23.98

1.23, 5.0V, 3.3 V 150 mA 2.5 - 5.5 V
[56] Integrated USD
Analog 1.10
ADP7142 [57] 1.8, 2.5, 3.3, 5.5 200 mA 2.7V - 40V
Devices USD
1.3, 1.8, 2.5, 3.0, Analog 1.19

ADM7171 [58] 1A 2.3 - 6.5 V
3.3, 4.2, 5.0 Devices USD
2.5, 3, 3.3, 3.8, Texas 7.78

LP2980-N [59] 50 mA 2.1 – 16V
4.7, 5 Instruments USD
Texas 2.18
LM2936 [60] 3, 3.3 , 5 50 mA 3.0 – 5.0V
Instruments USD
Tabla 2.12. Estudio Comparativo Regulador
Justificación: Se eligió el componente MAX6349TLUT-T como regulador (limitará el voltaje que

alimenta a todo el dispositivo electrónico) ya que como indica su hoja de datos es el único que
42
incluye un circuito de reset interno que indica cuando la salida del regulador cae por debajo
tolerancias de suministro de microprocesador estándar lo cual nos ayudará a saber cuándo es
necesario cambiar la pila que lo alimentará. Adicionalmente, el encapsulado será el SOT23-6
por ser el de menor tamaño.
El costo que tendrá cada uno de los componentes electrónicos en pesos mexicanos con tipo de
cambio de $15.37 es el siguiente:
 PulseSensor: $ 384.25
 TC77: $14.14
 PIC24F16KL401: $38.43
 HC-06: $129.00
 MAX295: $60.25
 MAX6349TLUT-T: $368.57
Total: $ 994.64
Fuente de alimentación.
Para el dispositivo electrónico, necesitamos definir una fuente de alimentación que satisfaga
correctamente a cada uno de sus componentes principales tanto en modo standby (modo
dormido) como en modo activo. Para esto tenemos que la corriente que consumen cada uno de
ellos y su suma total en la tabla 2.13.
Corriente en standby Corriente en modo

(modo dormido) activo
PulseSensor 4mA 4mA
TC77 0.1A 250A
PIC24F16KL401 30 nA 350μA
HC-06 8mA 25mA
MAX295 7mA 15mA
MAX6349TLUT-T 1A 25μA
Corriente total ~19 mA ~42mA
Tabla 2.13. Corrientes de consumo
Debemos considerar una fuente de alimentación portátil que soporte el consumo del dispositivo
electrónico, además de tener un margen de error en caso de necesitarlo, para esto necesitamos
43
saber la duración de la fuente en relación al consumo del dispositivo para eso utilizaremos la
siguiente ecuación [61]:
Duración de la batería = Capacidad de la batería (mAh)

Consumo del circuito (mA)
En la tabla 2.14 indica las principales marcas de baterías que son de menor tamaño en el
mercado. Consideraremos que el voltaje de alimentación que se va a estar manejando para
todo el dispositivo electrónico será de 3.3 volts. 194,19.025
Total Capacidad de la Duración de la Duración de la

Tipo Medidas Voltaje de batería (mA x batería en modo batería en modo
pilas hr) activo dormido
1.2 cm de
AAA diámetro y 4.44 1.5V 3 1000mAh 23.8 horas 52.63 horas
cm de largo
1.45 cm de
AA diámetro y 5cm 1.5V 3 2000mAh 47.61horas 105.26 horas
de largo
2.6 cm de
C diámetro y 5 cm 1.5V 3 6000mAh 142.85 horas 315.78 horas
de largo
2.6 de largo por
9 voltios 9v 1 500mAh 11.90 horas 26.31 horas
1.75 de ancho
Tipo
Diámetro de 24.5
botón de 3.6V 1 600mAh 14.28 horas 31.57 horas
milímetros
litio
Tabla 2.14. Baterías
Justificación: El prototipo requiere que el dispositivo electrónico no incomode al participante
por lo que se consideró principalmente el tamaño, entre las de menor tamaño se encuentran las
AAA, AA y botón de litio entre ellas la de menor tamaño y la más durable es la AAA (Ver figura
2.3) por lo que se eligió para alimentar al dispositivo electrónico.
Figura 2.3. Batería AAA
44
Terminando con la parte del dispositivo electrónico, ahora seleccionaremos el sistema operativo
móvil en el cual la aplicación se desenvolverá y el cual recopilará la información enviada del
dispositivo electrónico. En la tabla 2.15 se muestra un estudio comparativo entre los diferentes y
más comunes sistemas operativos móviles el cual será el ambiente en donde la aplicación se
desenvuelva, además de ser atractiva para el o los usuarios.
Windows Blackberry
Sistema operativo IOS [62] Android [63]
Mobile [64] OS [65]
Open Handset
Compañía desarrolladora Apple Inc. Microsoft RIM
Alliance/Google
Visual Basic,
Lenguaje de desarrollo Objective-C Java Java
Visual C#
Precio del SDK (Software
$99 USD al
Development Kit-kit de desarrollo Gratis Gratis Gratis
año
software)
Windows, Linux, Mac
Plataformas soportadas por el SDK Mac OS Windows Windows
OS
Tabla 2.15. Sistemas operativos móviles
Para poder elegir adecuadamente un sistema operativo móvil, también nos basamos en las
tendencias del mercado actual, por lo que según un artículo de la CNN titulado “Android dominó
el mercado de los smartphones” en donde se aprecia en la Figura 2.4 [66] el aumento de la
preferencia por Android y afirman seguirá en aumento, y el periódico el Universal en donde se
aprecia la siguiente información:
“…los teléfonos con sistema operativo Android registran la mayor dinámica del mercado
nacional, junto con los dispositivos que vienen de marcas y proveedores muy conocidos…” [67]
45
Figura 2.4. Actividad en el mercado mundial
Concluimos que con base al mercado y la tabla 2.14 hemos decidido que para el desarrollo de
nuestro prototipo, el sistema operativo Android será el sistema operativo en la cual nuestra
aplicación (de prueba) se desenvuelva.
Ahora elegiremos la aplicación principal de monitoreo, la cual recibirá información del

dispositivo móvil. En la tabla 2.16 hacemos una comparación de ventajas y desventajas entre las
dos alternativas para la aplicación las cuales serán aplicación de escritorio y aplicación web [68].
Nombre Ventajas Desventajas
Su acceso se limita a la computadora

Habitualmente su ejecución no requiere comunicación con donde están instaladas.
el exterior, sino que se realiza de forma local. Esto
repercute en mayor velocidad de procesamiento, y por Son dependientes del sistema
tanto en mayores capacidades a la hora de operativo que utilice el ordenador y
programar herramientas más complicadas o funcionales. sus capacidades como video y
Aplicaciones memoria.
de escritorio Suelen ser más robustas y estables que las aplicaciones
Web. Requieren instalación personalizada.
Rendimiento: el tiempo de respuesta es muy rápido. Requieren actualización

personalizada.
Seguridad: pueden ser muy seguras (dependiendo del
desarrollador). Suelen tener requerimientos
especiales de software y librerías.
46
Portabilidad: se ejecutan desde cualquier ordenador con Es necesaria una conexión a Internet.
conexión a internet.
La comunicación constante con el
La información que manejan es accesible a través de servidor que ejecuta la aplicación,
internet, por lo que son especialmente interesantes para establece una dependencia a una
desarrollar aplicaciones multiusuario basadas en buena conexión a internet.
compartir información.
El servidor debe tener las
Son aplicaciones muy ligeras (el Navegador de Internet no prestaciones necesarias para ejecutar
contiene el programa) por lo que el Usuario no necesita la aplicación de manera fluida, no
tener un ordenador de grandes prestaciones para trabajar sólo para un usuario sino para todos
con ellas. los que la utilicen de forma
concurrente.
Consumen muy pocos recursos del equipo en el que están
Aplicaciones instaladas. Se pierde tiempo de desarrollo
web haciéndolas compatibles con los
Son fáciles de actualizar y mantener. distintos navegadores (aunque los
Los usuarios pueden participar en la elaboración de los frameworks ayudan a solventar
contenidos. Se pueden distribuir e instalar en miles de algunos de estos problemas).
equipos sin limitación o restricción alguna. Su tiempo de respuesta es más lento
Su funcionalidad es independiente del sistema operativo que el de las aplicaciones desktop
instalado en el ordenador del usuario. (esto ha mejorado mucho utilizando
tecnologías como AJAX).
No hay problemas de incompatibilidad entre versiones,
porque todos los Usuarios trabajan con la misma versión.
Seguridad.
Pueden ser muy seguras (dependiendo del desarrollador).
Tabla 2.16. Estudio comparativo entre aplicación de escritorio y aplicación web.
Debido a que se requiere que nuestra aplicación pueda correr en múltiples plataformas (por
ejemplo Windows, Mac, Linux), se optó por que la aplicación que reciba la información del
participante sea una aplicación web (de prueba), además de que nos ofrece muchas ventajas como
por mencionar algunas están que las aplicaciones web siempre se mantienen actualizadas y no
requieren que el usuario deba descargar actualizaciones y realizar tareas de instalación, también
no necesitan ser descargadas, instaladas y configuradas. Además pueden los usuarios pueden
acceder a ella desde cualquier computadora conectada a la red.
Pueden funcionar en cualquier equipo que disponga de un navegador web. Esto aplica tanto a
celulares, tabletas electrónicas y otros dispositivos modernos. Otra razón es que con aplicaciones
basadas en web todos utilizan la misma versión, y los bugs pueden ser corregidos tan pronto
como son descubiertos beneficiando inmediatamente a todos los usuarios del sistema.
Por lo tanto con base en lo anterior y en la tabla 2.16 hemos decidido que para el desarrollo de
este prototipo, una aplicación web será la que monitoreará a los participantes.
47
Debido a que se eligió una aplicación web, en la tabla 2.17 se muestra un estudio comparativo
para elegir los lenguajes de programación con el que se desarrollará esta aplicación.
Nombre Ficha Técnica Ventajas Desventajas

Desarrollado por Tim Sencillo que permite describir Lenguaje estático.
Berners-Lee. hipertexto. La interpretación de cada
Última versión es HTML5. Texto presentado de forma navegador puede ser diferente.
Basado en etiquetas. estructurada y agradable. Guarda muchas etiquetas que
Multiplataforma. No necesita grandes pueden convertirse en basura y
HTML Licencia pública. conocimientos cuando se cuenta dificultan la corrección.
[69] con un editor de páginas Web. El diseño es más lento.
Archivos pequeños. Las etiquetas son muy
Despliegue rápido. limitadas.
Lenguaje de fácil aprendizaje.
Lo admiten todos los
exploradores.
Creado por W3C. Con una Hoja de Estilo podemos Si hay problemas de
Última versión CSS 3. modificar la presentación de cada compatibilidades, el navegador
Multiplataforma. elemento sin modificar el código aplicará el formato
Licencia Pública. HTML, ahorrando esfuerzo y predeterminado y nuestro
tiempo de edición. Así, el trabajo de composición habrá
mantenimiento del sitio web se sido inútil.
hace más sencillo. Algunas propiedades de las
El lenguaje CSS ofrece una CSS pueden provocar que una
amplia gama de herramientas de parte del contenido de nuestra
composición más potentes que página resulte inaccesible
CSS [70] HTML. desde algunos navegadores.
Con CSS se evita tener que
recurrir a “trucos” para conseguir
algunos efectos.
Las Hojas de Estilo pueden
usarse con otros lenguajes de
programación (por ejemplo
JavaScript) para conseguir
efectos dinámicos en las páginas.
Se pueden especificar Hojas de
Estilo para distintos navegadores.
JavaScript es el lenguaje Lenguaje interpretado. Código visible.
interpretado orientado a Se ejecuta del lado del cliente. El código debe descargarse
objetos desarrollado por Lenguaje seguro. completamente.
Netscape. Puede poner en riesgo la
JavaScript Última versión ECMAScript seguridad del sitio, con el
[71] 5.1. problema llamado XSS
Multiplataforma. (significa en ingles Cross Site
Licencia pública. scripting renombrado a XSS
por su similitud de hojas de
estilo).
“PHP Hypertext Capacidad de conexión con Se necesita instalar un servidor
Preprocessor”. distintos manejadores de base de web.
Surgió en 1995, desarrollado datos. Todo trabajo es realizado en el
por PHP Group. No requiere definición de tipos de servidor.
PHP [72]
PHP es un lenguaje de script variables. Se puede dificultar la lectura
interpretado en el lado del Es libre, por lo que se presenta del código.
servidor utilizado para la como una alternativa de fácil
generación de páginas web acceso para todos.
48
dinámicas, embebidas en Incluye gran cantidad de
páginas HTML y ejecutadas funciones.
en el servidor. Capacidad de expandir su
Última versión PHP 5.6. potencial utilizando módulos.
Multiplataforma. Es un lenguaje multiplataforma:
Licencia Pública Linux, Windows, entre otros.
Desarrollado por Guido van Rápido de desarrollar. Toda la sintaxis está basada en
Rossum. Sencillez y velocidad. el acomodo de espacios e
Lenguaje de alto nivel. Sus bibliotecas hacen gran parte indentación. Lo cual se presta a
Última versión 5.3. del trabajo. confusiones.
Multiplataforma. Soporta varias bases de datos. Más lento que lenguajes
Licencia libre. compilados o de ensamblador.
Python Conforme se crean
[73] aplicaciones más complejas es
más complicado escribir el
código.
Es problemático distribuir el
trabajo en grupos de trabajo
como lo es con lenguajes de
programación como Java.
Creado por Yukihiro “matz” Es un lenguaje sencillo y fácil de Su uso no está muy extendido.
Matsumoto. leer. No existen muchas
Última versión 2.2.1 Soportado por la mayoría de las
frameworks desarrolladas en
Multiplataforma plataformas web.
Ruby [74] Ruby.
Licencia pública. Se trata de un software libre u
opensource.
Integra comandos de manejo de
bases de datos.
Es un lenguaje para la Ejecución rápida del servlets. Complejo aprendizaje.
creación de sitios web Crear páginas del lado del Poco práctico para pequeños
dinámicos, acrónimo de Java servidor. proyectos.
Server Pages. Está orientado a Código bien estructurado. Tiempos de desarrollo
desarrollar páginas Web en Integridad con los módulos de mayores.
JSP [75] Java. Java.
JSP fue desarrollado por Sun La parte dinámica está escrita en
Microsystems. Java.
Última versión Java EE 7. Permite la utilización se servlets.
Multiplataforma
Licencia pública.
Este es un lenguaje Orientado a objetos. Mayor Consumo de recursos.
comercializado por Microsoft. Separa el diseño del código. Tecnología propietaria.
Última versión 4.5 Fácil mantenimiento. Mayor
Licencia privada. seguridad.
ASP .NET
Mayor velocidad.
[76]
Incremento de velocidad de
respuesta del servidor.
División entre la capa de
aplicación o diseño y el código.
Tabla 2.17. Estudio comparativo lenguajes interpretación web
Con base en la tabla 2.17, se decidió que para este prototipo se utilizarán CSS (para un diseño
cómodo y agradable para los usuarios), HTML (lo admiten todos los exploradores) y finalmente
Javascript principalmente para la localización de los participantes por medio de google maps y
para la parte del servidor, para esto será necesario utilizar un framework (ya que javascript los
49
utiliza). Con base en lo anterior, en la tabla 2.18 se indica un estudio comparativo entre los
principales frameworks [77].

Backbone.js Se trata de un framework ligero Backbone provee de medios Carece de abstracciones fuertes y
[78] para JavaScript que facilita la para gestionar: deja mucho que desear. El
construcción de una potente Modelos: Gestionan los framework enteró es
interfaz de usuario para nuestra datos con los que trabaja la sorprendentemente ligero y da
aplicación web, haciendo ésta aplicación, permitiendo su lugar a que sea repetitivo. Cuanto
más escalable, eficiente y carga, edición y almacenado más grande es una aplicación, más
robusta ante fallos mediante la posterior en el servidor. se hace evidente.
aplicación de un patrón de Colecciones: Son conjuntos
arquitectura de software similar de instancias, que podemos
al MVC. manipular para mantener en
el cliente.
Vistas: No determinan la
estética de la aplicación,
sino que se limitan a ser una
vía de organización para la
interfaz.
Node.js [79] Node.js es un entorno Node es adecuado cuando La API de Node tiene la mala
JavaScript de lado de servidor necesitas hacer muchas costumbre de cambiar en formas
que utiliza un modelo asíncrono cosas al mismo tiempo, que rompen la compatibilidad
y dirigido por eventos. sobre todo muchas hacia atrás de versión en versión,
operaciones I/O (acceso a lo que requiere que apliques
ficheros, bases de datos,…) cambios frecuentes en tu código
a la vez. para mantener todo funcionando
Y es especialmente bueno en las versiones más actuales.
para aplicaciones en un
tiempo más cercano al real,
que necesitan mantener una
conexión persistente con
servidor.
Ember.js Es un framework de Tiene bastantes plantillas Prácticamente nuevo, sin mucha
[80] aplicaciones web basado en el con vistas compuestas y los documentación de él.
modelo-vista-controlador, es un enlaces de la interfaz de
código abierto del lado del usuario.
cliente JavaScript.
Knockout.js Es una biblioteca javascript, que Mucha documentación para Carece de una jerarquía de vistas
[81] nos ayuda a implementar este el uso de este framework, de componente sólido. No es tan
modelo MVVM. Dentro de las además de soporte por parte fácil reutilizar los componentes
características especiales, tal de los creadores. fácilmente.
cual indica en su página
Angular.js Es un framework MVC de Muy bien pensado, con El código base parece ser bastante
[82] JavaScript para el Desarrollo respecto a las plantillas y extenso y no muy modular.
Web Front End que permite diseño del controlador.
crear aplicaciones SPA (Single- Cuenta con un sistema de
Page Applications). Entra inyección de dependencia.
dentro de la familia de Tiene gran soporte de UI-
frameworks como BackboneJS Binding y sin duda su
o EmberJS. sintaxis es muy fácil de
entender
Tabla 2.18. Estudio comparativo de frameworks
50
Con base en la tabla 2.18, se eligió Node.js, ya que es bueno para aplicaciones que pretenden ser
en un tiempo real, que necesitan mantener una conexión persistente con servidor. Además se
eligió Angular.js para que nuestra aplicación web sea más dinámica en cuanto a diseño.
Finalmente, dentro de lo principalmente necesario para el desarrollo de este prototipo, en la tabla

2.19 se muestra un estudio comparativo entre los principales sistemas gestores de base de datos
(SGBD) resaltando sus ventajas y desventajas.

Distribuida bajo Funciona con grandes cantidades Es más lento en inserciones y
licencia BSD. de datos. actualizaciones que mysql.
Última versión 9.4. Alta concurrencia con varios
Postgresql
Escrito en C. usuarios accediendo al mismo
[83]
Multiplataforma. tiempo al mismo sistema.
Ahorro de costos de operación.
Estabilidad.
Desarrollado por Escalabilidad. Solo permite un máximo de 64 GB.
Microsoft. Seguridad. Requiere de un sistema operativo
SQL Server Última versión Estabilidad. Windows.
[84] 2014. No se puede instalar en servidores Linux.
Plataforma para
Microsoft.
Desarrollado por Reduce los costos de No es recomendable utilizarlo con
IBM. administración. aplicaciones que exigen un gran
Última versión 12. Soporta requisitos de rendimiento desde el punto de vista de la
Informix Programado en C y procesamiento de transacción rapidez.
[85] C++. online. No tiene soporte para tipo de datos
Multiplataforma. Maximiza operación de datos para VARCHAR, son datos con una longitud
GPL o uso el grupo de trabajo y para la de 2000 caracteres.
comercial. empresa total.
Desarrollado por Conectividad Segura. La gran principal desventaja de mysql es
Sun Microsystems. Disponibilidad de gran cantidad la gran cantidad de RAM que utiliza para
Última versión 5.6. de plataformas y sistemas. la instalación.
Programado C, Soporte de transacciones.
MySql [86]
C++. Escalabilidad, estabilidad y
Multiplataforma. seguridad.
GPL o uso
comercial.
Diseñado por Aislamiento. El modelo tradicional de utilizar un
dichardhipp. Durabilidad. proceso de servidor ofrece mayor
Lanzamiento 17 de Está incluido en Android, protección ante aplicaciones que utilizan
agosto de 2000. BlackBerry y Google Chrome, ya la base de datos y que pudieran tener
Última versión que su tamaño es pequeño. fallos de programación.
Sqlite [87]
3.8.9. Simplicidad y Sencillez
Programado en C.
Multiplataforma.
Dominio Público.
Desarrollado por Permite agilizar el tiempo de Publicado en la revista VAR, Microsoft

IBM. respuesta de la consulta. SQL Server se anotó un 38%, IBM 10%,
DB2 [88]
Año de lanzamiento Tablas de resumen. Oracle 21%, Informix 9%, Sybase 8%.
de 1982. La mayoría de los que usan
51
Última Versión 10. equipos IBM utilizan DB2 porque
Multiplataforma. es confiable y tiene soporte
Licencia privada. técnico.
Desarrollo por Multiplataforma- Soporta bases Costo de mantenimiento alto.
Oracle Oracle Corporation. de datos de todos los tamaños, Lo maneja personal capacitado de
Database Última versión 12. desde severas cantidades de bytes Oracle.
[89] Multiplataforma. y gigabytes en tamaño.
Licencia privada. Soporta Cliente Servidor.
Tabla 2.19. Estudio comparativo de SGBD
Con base en la tabla 2.19 y debido a su costo (gratuito), velocidad, funcionalidad y portabilidad
seleccionamos como SGBD a Mysql.
Viabilidad Legal
En esta sección se detallan los aspectos legales a considerar para este prototipo, como son los
contratos a los usuarios finales que son los organizadores de carreras deportivas y el aviso de
privacidad simplificado para el tratamiento de datos personales.
 Aviso de privacidad simplificado
El Responsable del tratamiento y protección de tus datos personales son los desarrolladores de
este prototipo (Instituto Politécnico Nacional. Escuela Superior de Cómputo), con domicilio en
Av. Juan de Dios Bátiz esq. Av. Miguel Othón de Mendizábal, Gustavo A. Madero, Lindavista,
07738 Ciudad de México, Distrito Federal. Los datos personales que recabamos los utilizamos
para la siguiente finalidad primaria: El monitoreo de tu estado de salud en una carrera deportiva,
utilizaremos tu información personal para la siguientes finalidades secundarias: Fines
académicos.
En caso de que no desees que tus datos personales sean tratados para las finalidades secundarias,
desde este momento nos puedes comunicar lo anterior al correo electrónico:
malanist1100@alumno.ipn.mx o jvelazquezr1105@alumno.ipn.mx y manifestar tu negativa para
el uso de tus datos personales, para estas finalidades secundarias, no podrá ser un motivo para
impedirte el uso del sistema.
 Contrato de licencia de uso
Términos y condiciones – Contrato de Licencia de uso de software.
LEA CUIDADOSAMENTE LOS TÉRMINOS Y CONDICIONES DEL PRESENTE

DOCUMENTO, ANTES DE LA UTILIZACIÓN DE ESTE PRODUCTO. ESTE CONTIENE
52
SOFTWARE, CUYO USO ES OBJETO DE UNA LICENCIA OTORGADA POR INSTITUTO
POLITECNICO NACIONAL (DE AQUÍ EN ADELANTE DENOMINADA “IPN”) A FAVOR
DE USTED, EL USUARIO FINAL ORIGINAL, PARA SU USO EXCLUSIVO COMO SE
INDICA. SI USTED NO ESTA DE ACUERDO CON LOS TÉRMINOS Y CONDICIONES DE
ESTE CONTRATO, NO UTILICE EL SOFTWARE. EL USO DE CUALQUIER PARTE DEL
SOFTWARE INDICA QUE USTED ACEPTA ESTOS TÉRMINOS.
CLÁUSULA 1. OBJETO. Este acuerdo establece las condiciones de licenciamiento, instalación y

uso del programa adquirido (de aquí en adelante denominado “el software”), programa este
propiedad exclusiva de IPN. La licencia objeto del presente acuerdo es concedida exclusivamente
para el uso del cliente.
CLÁUSULA 2. LICENCIA. IPN le otorga a usted una licencia limitada, exclusiva, para el uso
del software que se acompaña, sujeta a los términos y condiciones recogidos en el presente. No se
le permite el uso del software en ninguna otra manera que no esté expresamente autorizada por
esta Licencia.
El Software es objeto de licencia para su uso en cualquier ordenador personal que disponga el
sistema operativo correspondiente para el software adquirido.
Usted podrá reproducir y usar solo las copias previamente de acuerdo del Software.
CLÁUSULA 3. DERECHOS DE AUTORÍA. El Software es propiedad exclusiva de IPN, y está

protegido por la legislación sobre derechos de autor, tratados internacionales y cualquier
legislación aplicable.
CLÁUSULA 4. INSTALACIÓN. El Software objeto del presente acuerdo será instalado en el

equipo del Cliente.
CLÁUSULA 5. DISPOSICIONES GENERALES. El Cliente no deberá usar o alterar el Software

con ninguna finalidad, ni podrá utilizar el Software para cualquier otro propósito que el señalado
con anterioridad, sin el consentimiento previo por escrito de IPN, el cual podrá ser denegado por
cualquier razón. La modificación, manipulación o alteración en cuanto a ingeniería o recopilación
o desmontaje del software queda expresamente prohibido.
53
El uso del Software por parte de terceros o para el beneficio de cualquier otra persona queda
expresamente prohibido. IPN tiene el derecho de invalidar la Licencia del Software en cualquier
momento, notificándole al Cliente con sólo un día de anticipación; el Cliente no tendrá derecho a
reclamar o solicitar compensación. Igualmente, el Cliente no podrá (a) arrendar o transferir
mediante ningún título, o incluso por causa sin ánimo de lucro, el uso del Software a terceros; (b)
tomar aquellos pasos para, mediante la ingeniería inversa o cualquier otro método, descompilar,
desensamblar, analizar o convertir el Software; (c) transferir el Software a otro Equipo, suyo o
no. El Cliente se compromete a cumplir estrictamente las instrucciones de IPN para el uso
adecuado del Software.
CLÁUSULA 6. CONFIDENCIALIDAD. El Software, como también cualquier documentación e

información relacionada con éste, son propiedad exclusiva de IPN. El Cliente conviene en
mantener en estricta confidencialidad toda información confidencial que surja del Software, ya
que toda la mencionada información es confidencial y propiedad de IPN.
CLÁUSULA 7. PROPIEDAD. El Software es, y seguirá siendo en todo momento, propiedad de

IPN. El Cliente no tendrá ningún derecho, titulo o interés en el Software, y no permitirá que
ninguna obligación o gravamen exista sobre éste, ni permitirá el uso del Software por terceros, ni
realizará ningún acto que pueda modificar los derechos de autor del Software. Por lo tanto, el
CLIENTE no puede vender, arrendar, prestar, revelar, transmitir o transferir ningún título, ni
copiar el Software para terceros.
CLÁUSULA 8. MODIFICACIÓN y ACTUALIZACIÓN DE VERSIONES. IPN podrá

modificar o reinstalar el Software bajo los términos y condiciones incluidos en el presente,
reemplazándolo por versiones actualizadas.
CLÁUSULA 9. RESPONSABILIDAD DEL CLIENTE; RIESGO DE PÉRDIDA. El cliente

deberá asumir todo riesgo de pérdida o daño del Software. Asimismo IPN, no se responsabiliza
de ningún daño o pérdida en su ordenador personal derivada del uso de este Software y de los
manuales de instrucciones.
CLÁUSULA 10. ROBO, PERDIDA, O CAMBIO DE ORDENADOR PERSONAL.
En caso de robo, pérdida o cambio de su ordenador personal, IPN no se responsabiliza, como

tampoco generará ni autorizará ni otorgará otra licencia de uso.
54
CLÁUSULA 11. PLAZO Y TERMINACIÓN este contrato será efectivo hasta que sea
terminado.
Usted podrá terminarlo en cualquier momento, mediante la destrucción en cualquier forma del
software.
También se terminara inmediatamente si usted incumple cualquier termino o condición del

presente sin que esto signifique una renuncia de IPN a su derecho de realizar acciones judiciales
que se deriven del mismo.
CLÁUSULA 12. FACTURACIÓN Y FORMAS DE PAGO. IPN facturará al cliente por los
servicios y/o productos con las tarifas vigentes en cada momento, que serán incrementadas con el
IVA correspondiente. El pago se realizará mediante ingreso o transferencia bancaria, siempre por
anticipado, no realizándose el suministro o prestación del servicio correspondiente hasta la
confirmación efectiva del mismo.
CLÁUSULA 13. CONTRATO INTEGRAL. Este acuerdo de licencia constituye el contrato

completo entre el Cliente e IPN, reemplaza cualquier acuerdo anterior o actual entre las partes.
Este acuerdo no puede ser enmendado, modificado ni ratificado, excepto mediante documento
por escrito firmado por ambas partes.
2.5. Análisis de factibilidad
Con este análisis determinamos si nuestro proyecto se puede realizar, si resultará útil y si tenemos
los medios necesarios para lograr su realización de manera correcta.
También podremos decidir si debemos realizar modificaciones para lograr que se desarrolle con
éxito y si nuestros objetivos sean alcanzables.
Desde el punto de vista operativo, creemos que el impacto del prototipo propuesto en las carreras
deportivas en los cuales será aplicado será positivo, actualmente existen muchas aplicaciones que
tienen un funcionamiento similar al prototipo propuesto, sin embargo, estos no dan soporte a la
salud del participante como enviar alertas y ubicación en caso de alguna emergencia aparte de
que podemos ofrecer una alternativa más económica para los coordinadores de estas carreras en
un futuro, así estos podrán monitorear a los participantes sin necesidad de que compren equipos
muy sofisticados. Al ser este un prototipo no es posible aún hacer un estudio económico del
55
impacto que tendrá, este se considerará en otras versiones del mismo. La idea surge sobre el
cuidado de la salud, ya que para lograrlo es necesario un constante monitoreo de los signos
vitales más importantes sobre todo en actividades que generan un gran impacto en el cuerpo
humano como es el atletismo, y que mejor que en las carreras deportivas donde se ve con más
claridad ese punto.
El sistema consistirá principalmente de un dispositivo electrónico, el cual se comunicará con un

dispositivo móvil que el corredor va a llevar consigo; la información que se esté obteniendo se
transmitirá de forma remota a un servidor donde es posible observar la información de cada uno
de los participantes.
56
CAPÍTULO 3. DISEÑO
En este capítulo se abordará el diseño del prototipo propuesto.
3.1. Diagramas de arquitectura
En la figura 3.1 se observa el diagrama de la arquitectura general del sistema.
Figura 3.1. Arquitectura general del sistema
57
En la figura 3.1 se puede observar que la persona que portará el dispositivo electrónico, el
participante, estará mandando de manera frecuente su información. El dispositivo electrónico
enviará la información captada a un dispositivo móvil que desplegará la información obtenida.
Posteriormente, la aplicación móvil enviará está información a un servidor, para que finalmente
todo esto sea recibido por la aplicación de web y así los encargados de las carreras podrán
monitorear adecuadamente a cada uno de los participantes.
A continuación en las figuras 3.2 a la 3.7 se mostrarán los diagramas de arquitectura de la

dispositivo electrónico, componentes del dispositivo, aplicación móvil, servicio de datos, servidor
y aplicación web respectivamente.
Figura 3.2. Diagrama de arquitectura del dispositivo electrónico
58
Figura 3.3. Diagrama de arquitectura de los componentes del dispositivo electrónico
Figura 3.4. Diagrama de arquitectura de la aplicación móvil
59
Figura 3.5. Diagrama de arquitectura del servicio de datos
Figura 3.6. Diagrama de arquitectura del servidor
Figura 3.7. Diagrama de arquitectura del aplicación web
60
3.2. Diagramas de casos de uso
Un diagrama de casos de uso se hace para resumir quién usa la aplicación o sistema y qué pueden
hacer cada uno de los actores. A continuación en la figura 3.8 se indican los actores que tendrán
contacto con las aplicaciones y dispositivo electrónico además de una descripción.
Módulos: Este prototipo consiste en tres módulos:

“Módulo para el monitoreo de atletas” (Aplicación
web, principal), Módulo de alertas e información de
atletas (Aplicación móvil) y finalmente Módulo de
adquisición de datos (Dispositivo electrónico,
pulsera).
Participante: Los participantes de carreras deportivas
serán nombrados como “participante”. Tendrán acceso
únicamente con la aplicación móvil y usarán consigo
el dispositivo electrónico.
Organizador: Los coordinadores de carreras
deportivas serán nombrados como “organizadores”.
Tendrán acceso a todos los módulos del prototipo.
Figura 3.8. Descripción de actores

En las figuras 3.9 a la 3.15 se muestran los diagramas de caso de uso de la aplicación web,
aplicación móvil, dispositivo electrónico y componentes electrónicos del dispositivo electrónico.
Adicionalmente se indica una descripción de cada diagrama.
61
Figura 3.9. Diagrama caso de uso aplicación web (organizador)
62
En la figura 3.9 se indican las acciones en la aplicación web, la descripción de los casos de uso se
indica de la tabla 3.1 a la 3.21.
Caso de uso 1.0. Iniciar sesión
Actores Organizador
Tipo Básico
Propósito Iniciar sesión en la aplicación web
Resumen El usuario indicará su nombre de usuario y contraseña para poder
acceder a la aplicación web.
Precondiciones El usuario debe estar previamente registrado
Flujo principal No aplica
Excepciones El usuario no podrá acceder si la contraseña no es correcta o si no se
encuentra previamente registrado.
Tabla 3.1. Descripción de caso de uso iniciar sesión
Caso de uso 1.1. Recuperar contraseña
Actores Organizador
Tipo Extend
Propósito Recuperar contraseña para poder iniciar sesión en la aplicación web
Resumen El usuario indicará que desea recuperar su contraseña, y al indicar su
correo electrónico se le enviará la contraseña a él.
Excepciones El usuario no podrá recuperar su contraseña si no se encuentra
previamente registrado o si indica un correo erróneo.
Tabla 3.2. Descripción de caso de uso recuperar contraseña
Caso de uso 2.0. Cerrar sesión
Actores Organizador
Tipo Básico
Propósito Cerrar sesión en la aplicación web
Resumen El usuario indicará que quiere cerrar la sesión en la aplicación web.
Precondiciones El usuario debe haber iniciado sesión previamente
Flujo principal Se requiere que el usuario haya iniciado sesión
Excepciones El usuario no podrá cerrar sesión si no la ha iniciado previamente.
Tabla 3.3. Descripción de caso de uso cerrar sesión
Caso de uso 3.0. Gestionar organizadores
Actores Organizador
Tipo Básico
Propósito Administrar a los organizadores
Resumen El usuario administrará a los organizadores
Precondiciones El usuario debe haber iniciado previamente la sesión.
Excepciones El usuario no podrá gestionar organizadores si no se encuentra
previamente registrado o si no ha iniciado sesión.
Tabla 3.4. Descripción de caso de uso gestionar organizadores
63
Caso de uso 3.1. Crear organizadores
Actores Organizador
Tipo Include
Propósito Crear a los organizadores
Resumen El usuario creará a los organizadores
Flujo principal Se requiere que el usuario haya iniciado sesión y accedido a la opción
de gestionar organizador.
Excepciones El usuario no podrá crear organizadores si no se encuentra
previamente registrado, si no ha iniciado sesión y si no llena el
formulario de datos.
Tabla 3.5. Descripción de caso de uso crear organizadores
Caso de uso 3.2. Modificar organizadores
Actores Organizador
Tipo Include
Propósito Modificar a los organizadores
Resumen El usuario modificará a los organizadores
Precondiciones El usuario debe haber iniciado previamente la sesión y el organizador
a modificar ya debe estar previamente registrado.
de gestionar organizador, además el organizador a modificar ya debe
estar previamente registrado.
Excepciones El usuario no podrá modificar organizadores si este no se encuentra
previamente registrado, si no ha iniciado sesión, si el organizador a
modificar no está previamente registrado y si no llena el formulario de
datos.
Tabla 3.6. Descripción de caso de uso modificar organizadores
Caso de uso 3.3. Eliminar organizadores
Actores Organizador
Tipo Include
Propósito Eliminar a los organizadores
Resumen El usuario eliminará a los organizadores
a eliminar ya debe estar previamente registrado.
de gestionar organizador, además el organizador a eliminar ya debe
Excepciones El usuario no podrá eliminar organizadores si este no se encuentra
modificar no está previamente registrado.
Tabla 3.7. Descripción de caso de uso eliminar organizadores
Caso de uso 3.4. Ver organizadores
Actores Organizador
Tipo Include
64
Propósito Ver a los organizadores
Resumen El usuario verá a los organizadores
a visualizar ya debe estar previamente registrado.
de gestionar organizador, además el organizador a visualizar ya debe
Excepciones El usuario no podrá visualizar organizadores si este no se encuentra
datos.
Tabla 3.8. Descripción de caso de uso ver organizadores
Caso de uso 3.5. Buscar organizadores
Actores Organizador
Tipo Include
Propósito Buscar a los organizadores
Resumen El usuario buscará a los organizadores
a ser buscado ya debe estar previamente registrado.
de gestionar organizador, además el organizador a ser buscado ya debe
Excepciones El usuario no podrá visualizar organizadores si este no se encuentra
previamente registrado, si no ha iniciado sesión, si el organizador a ser
buscado no está previamente registrado y si no llena el formulario de
datos.
Tabla 3.9. Descripción de caso de uso buscar organizadores
Caso de uso 4.0. Gestionar participante
Actores Organizador
Tipo Básico
Propósito Administrar a los participantes
Resumen El usuario administrará a los participantes
Excepciones El usuario no podrá gestionar participantes si no se encuentra
Tabla 3.10. Descripción de caso de uso gestionar participante
Caso de uso 4.1. Crear participante
Actores Organizador
Tipo Include
Propósito Crear a los participantes
Resumen El usuario creará a los participantes
65
de gestionar participante.
Excepciones El usuario no podrá crear participantes si este no se encuentra
Tabla 3.11. Descripción de caso de uso crear participante
Caso de uso 4.2. Modificar participante
Actores Organizador
Tipo Include
Propósito Modificar a los participantes
Resumen El usuario modificará a los participantes
Precondiciones El usuario debe haber iniciado previamente la sesión y el participante
de gestionar participante, además el participante a modificar ya debe
Excepciones El usuario no podrá modificar participantes si este no se encuentra
previamente registrado, si no ha iniciado sesión, si el participante a
datos.
Tabla 3.12. Descripción de caso de uso modificar participante
Caso de uso 4.3. Eliminar participante
Actores Organizador
Tipo Include
Propósito Eliminar a los participantes
Resumen El usuario eliminará a los participantes
de gestionar participante, además el participante a eliminar ya debe
Excepciones El usuario no podrá eliminar participantes si este no se encuentra
Tabla 3.13. Descripción de caso de uso eliminar participante
Caso de uso 4.4. Ver participante
Actores Organizador
Tipo Include
Propósito Ver a los participantes
Resumen El usuario verá a los participantes
de gestionar participante, además el participante a visualizar ya debe
66
Excepciones El usuario no podrá visualizar participantes si este no se encuentra
datos.
Tabla 3.14. Descripción de caso de uso ver participante
Caso de uso 4.5. Buscar participante
Actores Organizador
Tipo Include
Propósito Buscar a los participantes
Resumen El usuario buscará a los participantes
de gestionar participante, además el participante a ser buscado ya debe
previamente registrado, si no ha iniciado sesión, si el participante a ser
datos.
Tabla 3.15. Descripción de caso de uso buscar participante
Caso de uso 5.0. Gestionar carrera
Actores Organizador
Tipo Básico
Propósito Administrar a los carreras
Resumen El usuario administrará a los carreras
Excepciones El usuario no podrá gestionar carreras si no se encuentra previamente
registrado o si no ha iniciado sesión.
Tabla 3.16. Descripción de caso de uso gestionar carrera
Caso de uso 5.1. Crear carrera
Actores Organizador
Tipo Include
Propósito Crear a los carreras
Resumen El usuario creará a los carreras
de gestionar carrera.
Excepciones El usuario no podrá crear carreras si este no se encuentra previamente
registrado, si no ha iniciado sesión y si no llena el formulario de datos.
Tabla 3.17. Descripción de caso de uso crear carrera
Caso de uso 5.2. Modificar carrera
Actores Organizador
Tipo Include
67
Propósito Modificar a los carreras
Resumen El usuario modificará a los carreras
Precondiciones El usuario debe haber iniciado previamente la sesión y el carrera a
modificar ya debe estar previamente registrado.
de gestionar carrera, además el carrera a modificar ya debe estar
previamente registrado.
Excepciones El usuario no podrá modificar carreras si este no se encuentra
previamente registrado, si no ha iniciado sesión, si la carrera a
datos.
Tabla 3.18. Descripción de caso de uso modificar carrera
Caso de uso 5.3. Eliminar carrera
Actores Organizador
Tipo Include
Propósito Eliminar a los carreras
Resumen El usuario eliminará a los carreras
eliminar ya debe estar previamente registrado.
de gestionar carrera, además el carrera a eliminar ya debe estar
Excepciones El usuario no podrá eliminar carreras si este no se encuentra
Tabla 3.19. Descripción de caso de uso eliminar carrera
Caso de uso 5.4. Ver carrera
Actores Organizador
Tipo Include
Propósito Ver a los carreras
Resumen El usuario verá a los carreras
visualizar ya debe estar previamente registrado.
de gestionar carrera, además el carrera a visualizar ya debe estar
Excepciones El usuario no podrá visualizar carreras si este no se encuentra
datos.
Tabla 3.20. Descripción de caso de uso ver carrera
Caso de uso 5.5. Buscar carrera
Actores Organizador
Tipo Include
68
Propósito Buscar a los carreras
Resumen El usuario buscará a los carreras
Precondiciones El usuario debe haber iniciado previamente la sesión y el carrera a ser
buscado ya debe estar previamente registrado.
de gestionar carrera, además el carrera a ser buscado ya debe estar
Excepciones El usuario no podrá visualizar carreras si este no se encuentra
previamente registrado, si no ha iniciado sesión, si la carrera a ser
datos.
Tabla 3.21. Descripción de caso de uso buscar carrera
Figura 3.10. Diagrama caso de uso aplicación web (participante)
En la figura 3.10 se indican las acciones en la aplicación web, la descripción de los casos de uso
se indica de la tabla 3.22 a la 3.30.
Caso de uso 6.0. Iniciar carrera
Actores Participante
Tipo Básico
Propósito Indica que la carrera ha iniciado
Resumen El usuario ha iniciado carrera
Precondiciones El usuario debe estar previamente registrado y asociado a una carrera
69
Flujo principal Se requiere que el organizador haya registrado al participante y este lo
haya asociado a una carrera.
Excepciones El participante no podrá iniciar la carrera si no se encuentra
Tabla 3.22. Descripción de caso de uso iniciar carrera
Caso de uso 6.1. Recibir información del servidor
Actores Aplicación web, participante
Tipo Include
Propósito La aplicación web va a enviar peticiones al servidor
Resumen Se recibirá información solicitada del servidor
Precondiciones El participante debe haber iniciado la carrera, continuar la carrera o
estarla terminando.
Flujo principal Se requiere que el participante ya haya iniciado la carrera.
Excepciones La aplicación no podrá hacer las peticiones si el participante no está
participando en la carrera.
Tabla 3.23. Descripción de caso de uso recibir información del servidor
Caso de uso 6.2. Recibir alerta
Actores Aplicación web, participante
Tipo Extend
Propósito La aplicación web va a recibir las alertas generadas por el participante
en caso de ser necesario.
Resumen Se recibirá alertas en su caso.
estarla terminando.
Flujo principal Se requiere que el participante ya haya iniciado la carrera, este
continuando la carrera o estarla terminando.
Excepciones La aplicación no recibirá alertas si no es el caso.
Tabla 3.24. Descripción de caso de uso recibir alerta
Caso de uso 6.3. Procesar información
Actores Aplicación web, servidor, participante
Tipo Include
Propósito La aplicación web junto con el servidor van a procesar la información
del participante en la carrera.
Resumen Se procesará la información recibida a la aplicación.
estarla terminando.
Flujo principal Se requiere que la aplicación ya haya recibido la información del
participante.
Excepciones La aplicación no podrá hacer las peticiones si el participante no está
Tabla 3.25. Descripción de caso de uso procesar información
Caso de uso 6.4. Generar historial
Tipo Include
70
Propósito La aplicación web va a generar un historial del participante en la
carrera.
Resumen Se generará un historial del desempeño del participante en la carrera.
estarla terminando.
Flujo principal Se requiere que la aplicación ya haya procesado la información del
participante.
Excepciones La aplicación no podrá generar un historial si el participante no está
Tabla 3.26. Descripción de caso de uso generar historial
Caso de uso 6.5. Enviar historial al servidor
Tipo Include
Propósito La aplicación web va a generar un historial del participante en la
carrera, este se almacenará en el servidor.
Resumen Se almacenará el historial del desempeño del participante en la carrera
del lado del servidor.
estarla terminando.
Flujo principal Se requiere que ya se haya generado el historial del participante.
Excepciones No se podrá generar un historial si el participante no está participando
en la carrera.
Tabla 3.27. Descripción de caso de uso enviar historial al servidor
Caso de uso 6.6. Enviar información a la aplicación móvil
Actores Servidor, participante
Tipo Include
Propósito El servidor enviará la información necesaria a la aplicación web
Resumen El servidor enviará información solicitada de la aplicación móvil
estarla terminando.
Flujo principal Se requiere que ya se haya almacenado información en el servidor
además la aplicación móvil debe realizar las peticiones con la
información que este requiera.
Excepciones No se podrá enviar información si es que no está almacenada en el
servidor.
Tabla 3.28. Descripción de caso de uso enviar información a la aplicación móvil
Caso de uso 6.7. Continuar carrera
Tipo Include
Propósito Indica que la carrera continua
Resumen El usuario continua la carrera
Precondiciones El usuario debe haber iniciado la carrera, estar previamente registrado
y asociado a una carrera
71
Excepciones El participante no podrá continuar la carrera si no la ha iniciado y si no
se encuentra previamente registrado.
Tabla 3.29. Descripción de caso de uso continuar carrera
Caso de uso 6.8. Terminar carrera
Tipo Include
Propósito Indica que la carrera ha terminado
Resumen El usuario termina la carrera
Excepciones El participante no podrá terminar la carrera si no la ha iniciado y si no
Tabla 3.30. Descripción de caso de uso terminar carrera
72
Figura 3.11. Diagrama caso de uso aplicación móvil
En la figura 3.11 se indican las acciones en la aplicación móvil, la descripción de los casos de uso
se indica de la tabla 3.31 a la 3.49.
Caso de uso 1.0. Iniciar sesión
Actores Organizador, participante
Tipo Básico
Propósito Iniciar sesión en la aplicación móvil
Resumen El usuario indicará su nombre de usuario y contraseña para poder
acceder a la aplicación móvil
Excepciones El usuario no podrá acceder si la contraseña no es correcta o si no se
encuentra previamente registrado.
Tabla 3.31. Descripción de caso de uso iniciar sesión
73
Caso de uso 1.1. Recuperar contraseña
Tipo Extend
Propósito Recuperar contraseña para poder iniciar sesión en la aplicación móvil
Resumen El usuario indicará que desea recuperar su contraseña, y al indicar su
correo electrónico se le enviará la contraseña a él.
Excepciones El usuario no podrá recuperar su contraseña si no se encuentra
previamente registrado o si indica un correo erróneo.
Tabla 3.32. Descripción de caso de uso recuperar contraseña
Caso de uso 2.0. Cerrar sesión
Tipo Básico
Propósito Cerrar sesión en la aplicación móvil
Resumen El usuario indicará que quiere cerrar la sesión en la aplicación móvil.
Precondiciones El usuario debe haber iniciado sesión previamente
Excepciones El usuario no podrá cerrar sesión si no la ha iniciado previamente.
Tabla 3.33. Descripción de caso de uso cerrar sesión
Caso de uso 3.0. Gestionar participante
Actores Organizador
Tipo Básico
Propósito Administrar a los participantes
Resumen El usuario administrará a los participantes
Excepciones El usuario no podrá gestionar participantes si no se encuentra
Tabla 3.34. Descripción de caso de uso gestionar participante
Caso de uso 3.1. Crear participante
Actores Organizador
Tipo Include
Propósito Crear a los participantes
Resumen El usuario creará a los participantes
de gestionar participante.
Excepciones El usuario no podrá crear participantes si este no se encuentra
Tabla 3.35. Descripción de caso de uso crear participante
Caso de uso 3.2. Modificar participante
Actores Organizador
74
Tipo Include
Propósito Modificar a los participantes
Resumen El usuario modificará a los participantes
de gestionar participante, además el participante a modificar ya debe
Excepciones El usuario no podrá modificar participantes si este no se encuentra
datos.
Tabla 3.36. Descripción de caso de uso modificar participante
Caso de uso 3.3. Eliminar participante
Actores Organizador
Tipo Include
Propósito Eliminar a los participantes
Resumen El usuario eliminará a los participantes
de gestionar participante, además el participante a eliminar ya debe
Excepciones El usuario no podrá eliminar participantes si este no se encuentra
Tabla 3.37. Descripción de caso de uso eliminar participante
Caso de uso 3.4. Ver participante
Actores Organizador
Tipo Include
Propósito Ver a los participantes
Resumen El usuario verá a los participantes
de gestionar participante, además el participante a visualizar ya debe
datos.
Tabla 3.38. Descripción de caso de uso ver participante
Caso de uso 3.5. Buscar participante
Actores Organizador
75
Tipo Include
Propósito Buscar a los participantes
Resumen El usuario buscará a los participantes
de gestionar participante, además el participante a ser buscado ya debe
previamente registrado, si no ha iniciado sesión, si el participante a ser
datos.
Tabla 3.39. Descripción de caso de uso buscar participante
Caso de uso 4.0. Consultar información
Actores Organizador
Tipo Básico
Propósito Consultar la información enviada del dispositivo electrónico
Resumen El participante podrá consultar su información
Precondiciones El usuario debe haber iniciado previamente la sesión y el dispositivo
electrónico debe encontrarse activo.
Flujo principal Se requiere que el usuario haya iniciado sesión.
Excepciones El usuario no podrá visualizar su información si este no se encuentra
previamente registrado, si no ha iniciado sesión.
Tabla 3.40. Descripción de caso de uso consultar información
Caso de uso 4.1. Consultar historial
Actores Organizador
Tipo Extend
Propósito Consultar el historial del participante
Resumen El participante podrá consultar su historial.
Precondiciones El usuario debe haber iniciado previamente la sesión y haber
terminado la carrera. Solo se podrá consultar en ese caso.
Flujo principal Se requiere que el usuario haya iniciado sesión.
Excepciones El usuario no podrá visualizar su información si este no se encuentra
previamente registrado, si no ha iniciado sesión. Solo podrá consultar
el historial si la carrera ha finalizado.
Tabla 3.41. Descripción de caso de uso consultar historial
Tipo Básico
Precondiciones El usuario debe estar previamente registrado y asociado a una carrera
76
Excepciones El participante no podrá iniciar la carrera si no se encuentra
Caso de uso 5.1. Recibir información y signos vitales
Actores Aplicación móvil, dispositivo electrónico, participante
Tipo Include
Propósito La aplicación móvil va a recibir información del dispotivio electrónico
Resumen Se recibirá información y signos vitales
estarla terminando.
Flujo principal Se requiere que el participante ya haya iniciado la carrera.
Excepciones La aplicación no podrá recibir la información si el participante no está
Tabla 3.43. Descripción de caso de uso recibir información del servidor
Caso de uso 5.2. Generar alerta
Actores Aplicación móvil, participante
Tipo Extend
Propósito La aplicación móvil va a enviar las alertas generadas por el
participante en caso de ser necesario.
Resumen Se generarán alertas en su caso.
estarla terminando.
Flujo principal Se requiere que el participante ya haya iniciado la carrera, este
continuando la carrera o estarla terminando.
Excepciones La aplicación no generará alertas si no es el caso.
Tabla 3.44. Descripción de caso de uso recibir alerta
Caso de uso 5.3. Enviar información al servidor
Actores Aplicación móvil, servidor, participante
Tipo Include
Propósito La aplicación móvil va a enviar la información para su
almacenamiento en el servidor.
Resumen Se enviará la información del participante en la carrera del lado del
servidor.
estarla terminando.
Flujo principal Se requiere que ya se haya capturado la información del participante.
Excepciones No se podrá enviar la información si el participante no está
participando en la carrera. Además de que el envío está sujeto a
conectividad.
Tabla 3.45. Descripción de caso de uso enviar información al servidor
Caso de uso 5.4. Enviar información a la aplicación web
Tipo Include
Propósito El servidor va a enviar la información para su despliegue en la
77
aplicación web.
Resumen Se enviará la información del participante para ser desplegado.
estarla terminando.
Flujo principal Se requiere que ya se haya almacenado la información del participante
en el servidor.
conectividad.
Tabla 3.46. Descripción de caso de uso enviar información a la aplicación web
Caso de uso 5.5. Desplegar información
Tipo Include
Propósito La aplicación web recibe la información y la despliega
estarla terminando.
Flujo principal Se requiere que ya se haya almacenado la información del participante
en el servidor y está ya haya sido enviada a la aplicación web.
conectividad.
Tabla 3.47. Descripción de caso de uso desplegar información
Tipo Include
Caso de uso 5.7. Terminar carrera
Tipo Include
78
Excepciones El participante no podrá terminar la carrera si no la ha iniciado y si no
Figura 3.12. Diagrama caso de uso dispositivo electrónico (organizador)
En la figura 3.12 se indican las acciones del dispositivo electrónico, la descripción de los casos de
uso se indica de la tabla 3.50 a la 3.51.
Caso de uso 1.0. Encender el dispositivo
Actores Organizador
Tipo Básico
Propósito El organizador enciende el dispositivo
Resumen Se enciende el dispositivo
Precondiciones El organizador debe encender el dispositivo y colocarlo en los
participantes.
Flujo principal No aplica.
Excepciones No aplica.
Caso de uso 1.0. Apagar el dispositivo
Actores Organizador
Tipo Básico
Propósito El organizador apaga el dispositivo
Resumen Se enciende el dispositivo
Precondiciones El organizador debe apagar el dispositivo y retirarlo de los
participantes.
Flujo principal No aplica.
79
Figura 3.13. Diagrama caso de uso dispositivo electrónico (participante)
En la figura 3.13 se indican las acciones del dispositivo electrónico, la descripción de los casos de
uso se indica de la tabla 3.52 a la 3.57.
Caso de uso 3.0. Usar dispositivo
Actores Participante, dispositivo
Tipo Básico
Propósito El participante usa el dispositivo
Resumen El participante usa el dispositivo
Precondiciones El organizador debe ajustar el dispositivo y retirarlo de los
participantes.
Flujo principal El dispositivo debe estar encendido
Tabla 3.52. Descripción de caso de uso usar dispositivo
Tipo Básico
Precondiciones El usuario debe estar usando el dispositivo
Flujo principal El usuario debe estar usando el dispositivo
Excepciones El participante no podrá iniciar la carrera si no está usando el
dispositivo
Caso de uso 4.1. Captar signos vitales
Actores Participante, dispositivo
Tipo Básico
80
Propósito El dispositivo capta los signos vitales del participante.
Resumen Captar signos vitales del participante
Precondiciones El usuario debe estar usando el dispositivo e iniciado la carrera
Flujo principal El usuario debe estar usando el dispositivo e iniciado la carrera
Excepciones El dispositivo no podrá captar los signos vitales si el participante no
está usando el dispositivo
Tabla 3.54. Descripción de caso de uso captar signos vitales
Actores Aplicación móvil, servidor, participante
Tipo Include
Propósito El dispositivo va a enviar la información para su despliegue en la
aplicación móvil.
estarla terminando y estar usando el dispositivo.
Flujo principal Se requiere que ya se hayan captado los signos vitales
conectividad.
Tabla 3.55. Descripción de caso de uso enviar información al móvil
Tipo Include
Caso de uso 4.4.. Terminar carrera
Tipo Include
81
Figura 3.14. Diagrama de caso de uso de componentes electrónicos (dispositivo electrónico)
En la figura 3.14 se indican las acciones de los componentes del dispositivo electrónico, la
descripción de los casos de uso se indica de la tabla 3.58 a la 3.70.
82
Caso de uso 1.0. Iniciar funcionamiento
Actores Dispositivo electrónico
Tipo Básico
Propósito Indica que el dispositivo ha iniciado el funcionamiento
Resumen El dispositivo ha iniciado el funcionamiento
Precondiciones No aplica
Excepciones Tener problemas para iniciar funcionamiento.
Tabla 3.58. Descripción de caso de uso iniciar funcionamiento
Caso de uso 2.0. Suministrar energía al dispositivo
Actores Fuente de alimentación Pila AAA
Tipo Básico
Propósito Suministra energía al dispositivo
Resumen Suministra energía al dispositivo
Precondiciones La fuente debe tener carga de energía.
Excepciones La fuente no tiene carga de energía
Tabla 3.59. Descripción de caso de uso suministrar energía al dispositivo
Caso de uso 3.0. Regular la energía
Actores Regulador MAX6349
Tipo Básico
Propósito Regula energía del dispositivo
Resumen Regula energía del dispositivo
Precondiciones Se debe suministrar energía al dispositivo
Flujo principal Suministrar energía
Excepciones Tener problemas de funcionamiento.
Tabla 3.60. Descripción de caso de uso regular la energía
Caso de uso 4.0. Captar pulso cardíaco
Actores Pulse Sensor
Tipo Básico
Propósito Capta la señal del pulso cardiaco
Resumen Capta la señal del pulso cardiaco
Precondiciones Estar conectado
Excepciones Tener problemas de funcionamiento.
Tabla 3.61. Descripción de caso de uso captar pulso cardíaco
Caso de uso 5.0. Filtrado de la señal
Actores Filtro MAX295
Tipo Básico
Propósito Elimina las componentes no deseadas del pulso cardíaco
Resumen Elimina las componentes no deseadas del pulso cardíaco
Precondiciones Capta la señal del pulso cardiaco
Flujo principal Capta la señal del pulso cardiaco
Tabla 3.62. Descripción de caso de uso filtrado de la señal
83
Caso de uso 5.1 Enviar al microcontrolador
Actores Filtro MAX295, PICK24F16KL401
Tipo Include
Propósito Envía información al microcontrolador para su conversión A/D y su
procesamiento
Resumen Envía información al microcontrolador para su conversión A/D y su
procesamiento
Precondiciones Captar la señal del pulso cardiaco y filtrarla
Flujo principal Captar la señal del pulso cardiaco y filtrarla
Tabla 3.63. Descripción de caso de uso enviar al microcontrolador
Caso de uso 6.0. Captar temperatura
Actores TC77
Tipo Básico
Propósito Capta la temperatura corporal (la salida es digital)
Resumen Capta la temperatura corporal (la salida es digital)
Precondiciones Que esté previamente conectado
Flujo principal Que esté previamente conectado
Tabla 3.64. Descripción de caso de uso captar temperatura
Caso de uso 6.1 Enviar al microcontrolador
Actores TC77, PICK24F16KL401
Tipo Include
Propósito Envía información al microcontrolador, la salida es digital
Resumen Envía información al microcontrolador, la salida es digital
Tabla 3.65. Descripción de caso de uso enviar al microcontrolador
Caso de uso 7.0 Obtener información de los sensores
Actores PICK24F16KL401
Tipo Básico
Propósito Obtiene información de los sensores
Resumen Obtiene información de los sensores
Tabla 3.66. Descripción de caso de uso obtener información de los sensores
Caso de uso 7.1 Procesar información
Actores PICK24F16KL401
Tipo Include
Propósito Procesar la información obtenida
Resumen Procesar la información obtenida
84
Tabla 3.67. Descripción de caso de uso procesar información
Caso de uso 8.0 Enviar información al módulo bluetooth
Actores PICK24F16KL401, HC-06
Tipo Básico
Propósito Enviar información al módulo bluetooth
Resumen Enviar información al módulo bluetooth
Tabla 3.68. Descripción de caso de uso enviar información al módulo bluetooth
Caso de uso 9.0 Obtener información
Actores HC-06
Tipo Básico
Propósito Obtiene información del microcontrolador (UART)
Resumen Obtiene información del microcontrolador (UART)
Tabla 3.69. Descripción de caso de uso obtener información
Actores HC-06, aplicación móvil
Tipo Include
Propósito Envía la información del HC-06 a la aplicación móvil
Resumen Envía la información del HC-06 a la aplicación móvil
Tabla 3.70. Descripción de caso de uso enviar a la aplicación móvil
3.3. Catálogo de mensajes
En esta sección se muestra un catálogo de los principales mensajes que puedan desplegar las
aplicaciones, estos se indican en la figura 3.15.
Mensaje 1: Error al iniciar sesión

Tipo: Notificación.
Objetivo: Notificar al usuario un error al iniciar sesión.
Redacción: El usuario o la contraseña son incorrectos.
Mensaje 2: Error de conexión con la base de datos:
Objetivo: Notificar al usuario que ocurrió un error con la base de datos.
85
Redacción: Error en la conexión con la base de datos.
Mensaje 3: Campos vacíos
Objetivo: Notificar al usuario que un campo obligatorio (marcado con *) se
encuentra vacío.
Redacción: Los campos “campos vacíos” se encuentran vacíos.
Mensaje 4: Registro inexistente
Objetivo: Indicar al usuario que el registro que desea buscar no existe.
Redacción: El registro “número de registro o identificador” no existe en la base
de datos.
Mensaje 5: Mensaje de confirmación
Objetivo: Indicar al usuario que la acción solicitada fue realizada exitosamente.
Redacción: La operación fue realizada exitosamente.
Mensaje 6: Confirmar acción
Objetivo: Solicitar al usuario la confirmación de una acción.
Redacción: ¿Desea “Acción”?
Mensaje 7: Error de confirmación
Objetivo: Indicar al usuario que la confirmación no se realizó exitosamente,
debido a que algún campo no coincide o, si es el caso, no hay conexión a
internet o red de datos.
Redacción: El/los registros no coinciden. No hay conexión con la red de datos.
Mensaje 8: Datos duplicados
Objetivo: Indicar al usuario que los valores que quiere ingresar y que son
consideradores identificadores están duplicados
Redacción: El registro “número de registro o identificador” ya existe. Por favor
ingrese otro.
Mensaje 9: Mensaje de error
Objetivo: Indicar al usuario que ocurrió un error y no se pudo realizar la acción
solicitada.
Redacción: Error al intentar “Acción solicitada“.
Mensaje 10: Sin resultados
Objetivo: Notificar al usuario que la consulta no devolvió ningún dato.
Redacción: No hubo resultados de tu búsqueda
Mensaje 11: Alerta enviada
Objetivo: Notificar al usuario que su alerta fue enviada
86
Redacción: Se ha enviado su alerta.
Mensaje 12: Alerta recibida
Objetivo: Notificar al organizador que recibió una alerta de un usuario.
Redacción: Ha recibido una alerta del participante “Número de participante“.
Mensaje 13: Sin alertas pendientes
Objetivo: Notificar al organizador que tiene alertas pendientes que atender.
Redacción: No hay alertas pendientes.
Mensaje 14: Excedió el número de participantes registrados
Objetivo: Notificar al organizador que ya no puede registrar más participantes a
una carrera.
Redacción: Excedió el número de participantes registrados.
Mensaje 15: Fecha u hora inválidas
Objetivo: Notificar al organizador que la fecha en la que registra una carrera es
inválida.
Redacción: Fecha u hora inválidos
Mensaje 16: Campo inválido
Objetivo: Notificar al usuario que el campo ingresado no cumple con los
requerimientos de validación de variables (poner letras cuando se requieren
números o viceversa).
Redacción: Campo inválido. Vuelva a intentarlo.
Mensaje 17: Carrera concluida
Objetivo: Notificar al usuario que la carrera ha llegado a su fin.
Redacción: Ha terminado la carrera.
Mensaje 18: El participante llegó a la meta
Objetivo: Confirmar que un participante ya llegó a la meta
Redacción: El participante llegó a la meta
Mensaje 19: La conexión no se ha establecido
Tipo: Notificación
Redacción: La conexión de algún componente no fue exitosa.
Figura 3.15. Catálogo de mensajes
87
3.4. Diagramas de clases
A continuación en la figura 3.16 se muestra el diagrama de clases para la aplicación móvil y la

aplicación web con las clases principales identificadas a partir de los casos de uso.
Figura 3.16. Diagrama de clases
En la figura 3.16 se muestra el diagrama de clases para el prototipo
Clase organizadores: Este va a tener como variables idOrganizador (String), Nombre

(String), Contraseña (String), ApellidoPaterno (String), ApellidoMaterno (String), Email
(String). Y como acciones tendrá: Actualizar, Registrar, Eliminar. Visualizar y Buscar
Organizador (CRUD).
Clase participantes: Este va a tener como variables NumeroParticipante (String), Nombre

(String), Contraseña (String), ApellidoPaterno (String), ApellidoMaterno (String), Email
(String), Edad (Integer), Sexo (Character), Observaciones (String). Y como acciones
tendrá: Actualizar, Registrar, Eliminar. Visualizar y Buscar Participante (CRUD).
88
Clase gestionar carreras: idCarreras (String), Información (String), Distancia (String),
Duración (String), Fecha (String), Hora_inicio (String), Hora_fin (String). Y como
acciones tendrá: Actualizar, Registrar, Eliminar. Visualizar y Buscar Carrera (CRUD).
Clase monitoreo: Este va a tener como variables iDMonitoreo (Integer), Pulso Cardiaco
(Integer), Temperatura (Integer), Hora_monitoreo (String), Ubicación (String). Y como
acciones tendrá: Captar pulso y temperatura.
Clase genera historial: Este va a tener como variables IdHistorial (Integer), Hora_Historial
(String), Alerta (String), Hora_Alerta(la hora en la que se generó la alerta) (String),
Intervalo_genera_historial (El intervalo de tiempo en el que se va a estar almacenando
los datos para generar el historial )(String). Y como acciones tendrá: Guardar
información del participante, guardar pulso y temperatura.
89
3.5. Diagrama Entidad-Relación
A continuación en la figura 3.17 se indica el diagrama entidad-relación de la base de datos que

utilizará el prototipo.
Figura 3.17. Diagrama Entidad-Relación
90
3.6. Diccionario de datos
En las figuras 3.18 a 3.24 se indica el diccionario de datos del diagrama entidad-relación (Ver
figura 25).
Figura 3.18. Tabla organizador
Figura 3.19. Tabla participante
Figura 3.20. Tabla carreras
Figura 3.21. Tabla historial
91
Figura 3.22 Tabla monitoreo
Figura 3.23. Tabla intermedia entre organizador y participante
Figura 3.24. Tabla intermedia entre participante y carreras
3.7. Diagramas de secuencia
A continuación, en la figuras 3.25 y 3.26 se indican los diagramas de secuencia del prototipo
propuesto.
92
Figura 3.25. Diagrama de secuencia del organizador
En la figura 3.25 se indican las acciones del organizador en las aplicaciones con las que tendrá contacto (aplicación móvil y web).
92
Figura 3.26. Diagrama de secuencia participante
En la figura 3.26 se indican las acciones del participante en las aplicaciones con las que tendrá contacto (aplicación móvil).
93
3.8. Diagramas de procesos
A continuación en la figura 3.27, 3.28 y 3.29 se indican los diagramas de procesos de la

aplicación web, móvil y componentes del dispositivo electrónico respectivamente.
Figura 3.27. Diagrama de procesos aplicación web
94
Figura 3.28. Diagrama de procesos aplicación móvil
95
Figura 3.29. Diagrama de procesos del dispositivo electrónico
96
3.9. Diagrama de bloques
A continuación en las figuras 3.30 a la 3.33 se indican los diagramas de bloques del prototipo
propuesto.
Figura 3.30 Diagrama de bloques aplicación web
En la figura 3.30 se puede observar el diagrama de bloques correspondiente a la aplicación web

que consta de lo siguiente:
La aplicación móvil para enviar la información obtenida al servidor, después será enviada a la
aplicación web, esta va a recibir los datos y las alertas si fuese el caso, se va a hacer un
procesamiento de los datos obtenidos y después de iniciar sesión se podrá hacer su consulta.
97
Figura 3.31. Diagrama de bloques aplicación móvil
En la figura 3.31 se puede observar el diagrama de bloques correspondiente a la aplicación móvil

que consta de lo siguiente:
El dispositivo electrónico va a enviar los datos a la aplicación móvil, esta los recibirá y después
de un inicio de sesión se hará un procesamiento y despliegue de la información; inmediatamente
se enviarán esos datos y alertas, si fuese el caso, a un servidor y este enviará la información a la
aplicación web.
98
Figura 3.32 Diagrama de bloques del dispositivo electrónico
En la figura 3.32 se puede observar el primer diagrama de bloques correspondiente al dispositivo
electrónico que consta de lo siguiente:
El pulso cardíaco y la temperatura las estarán obteniendo los sensores correspondientes, el sensor
de pulso cardíaco pasará a una etapa de filtrado para limitar el ancho de banda de la señal y
eliminar las frecuencias no deseadas, inmediatamente el microcontrolador va a procesar la
información obtenida de ambos sensores, se enviará al módulo bluetooth que se encargará de
enviarlo al dispositivo móvil.
99
Figura 3.33. Diagrama de bloques del dispositivo electrónico (componentes)
En la figura 3.33 se puede observar el segundo diagrama de bloques correspondiente al

dispositivo electrónico que consta de lo siguiente:
El sensor de pulso cardíaco va a entrar a una etapa de filtrado, para después entrar al convertidor
analógico-digital. El timer1 (fc) va a fungir como contador para poder medir la frecuencia de la
etapa de filtrado.
El sensor de temperatura para a ser enviado al microcontrolador mediante el bus de
comunicaciones SPI (comunicación síncrona).
El módulo bluetooth va a estar en comunicación con el PIC24FKL401 mediante su interfaz de
comunicación UART (comunicación asíncrona).
100
3.10. Diagramas de actividades
A continuación en las figuras 3.34, 3.35 y 3.36 se indican los diagramas de actividades del
prototipo propuesto.
Figura 3.34. Diagrama de actividades de la aplicación web
101
Figura 3.35. Diagrama de actividades de la aplicación móvil
102
Figura 3.36. Diagrama de actividades del dispositivo electrónico
103
3.11. Diagramas de estado
A continuación en las figuras 3.37, 3.38 y 3.39 se indican los diagramas de estado del prototipo
propuesto.
Figura 3.37. Diagrama de estado de la aplicación web
En la figura 3.37 se indica el diagrama de estado de la aplicación web y consiste en lo siguiente:

Va iniciar estando fuera de línea, se ingresarán los datos, se autentificarán; si los datos son
inválidos se rechazará el inicio de sesión, si los datos son válidos se iniciará sesión y estará en
estado: En línea.
104
Si se ingresando datos nuevos habrá un registro y se solicitará información al servidor para
procesarla, si el acceso al servidor es exitoso se desplegará la información solicitada, no el acceso
es fallido se verificará la conectividad. Si en la verificación la conectividad es correcta se
solicitará nuevamente la información y si es fallida se intentará conectar a la red. Finalmente se
cerrará sesión.
Figura 3.38. Diagrama de estado de la aplicación móvil
105
En la figura 3.38 se indica el diagrama de estado de la aplicación móvil y consiste en lo siguiente:
Va iniciar estando fuera de línea, se ingresarán los datos, se autentificarán; si los datos son
inválidos se rechazará el inicio de sesión, si los datos son válidos se iniciará sesión y estará en
estado: En línea.
Si se ingresando datos nuevos habrá un registro y se solicitará información al dispositivo
electrónico para procesarla, si la recepción es exitosa se desplegará la información solicitada, no
el acceso es fallido se verificará la conectividad. Si en la verificación la conectividad es correcta
se solicitará nuevamente la información y si es fallida se intentará conectar a la red.
Figura 3.39. Diagrama de estado del dispositivo electrónico

106
En la figura 3.39 se indica el diagrama de estado del dispositivo electrónico y consiste en lo
siguiente:
Primero habrá el encendido del dispositivo, inmediatamente habrá inicialización de periféricos,
empezará la adquisición de datos y si no hay datos se verificará la conectividad, ya una vez los
datos obtenidos se enviará al dispositivo móvil; si el envío es fallido se verificará la conectividad,
si este es exitoso verificará si la carrera ha finalizado, si es así volverá a la adquisición de datos,
si la carrera finalizó se podrá apagar el dispositivo (esto lo hará un organizador).
3.12. Diagramas de contexto
A continuación en las figuras 3.40 y 3.41 se indican los diagramas de contexto del prototipo.
CRUD de Organizadores
Verifica datos
Verifica datos CRUD de Participantes
Verifica datos
Inicio de sesión
Verifica datos
Aplicación web CRUD de Carreras
Monitoreo
Historial
Aplicación móvil
Figura 3.40. Diagrama de contexto de la aplicación web

En la figura 3.40 se indica el diagrama de contexto de la aplicación web, que consiste en lo
siguiente:
107
La aplicación web va a tener las siguientes acciones:
Inicio de sesión: Para esta acción habrá una previa verificación de datos, es decir que el
usuario y contraseña existan en la base de datos. Solo los organizadores podrán iniciar
sesión
CRUD Organizadores: Quiere decir que se crearán, leerán, actualizarán y eliminarán los
organizadores, para esta parte se verificará que los datos ingresados sean válidos.
CRUD Participantes: Quiere decir que se crearán, leerán, actualizarán y eliminarán los
participantes, para esta parte se verificará que los datos ingresados sean válidos.
CRUD Carreras: Quiere decir que se crearán, leerán, actualizarán y eliminarán los
carreras, para esta parte se verificará que los datos ingresados sean válidos.
Monitoreo: En esta acción los organizadores podrán monitorear las carreras para poder
verificar el desenvolvimiento en la carrera del participante.
Historial: Se generará un historial del desenvolvimiento del participante durante la

carrera.
Figura 3.41. Diagrama de contexto de la aplicación web

En la figura 3.41 se indica el diagrama de contexto de la aplicación web, que consiste en lo
siguiente:
108
La aplicación web va a tener las siguientes acciones:
Inicio de sesión: Para esta acción habrá una previa verificación de datos, es decir que el
usuario y contraseña existan en la base de datos. Solo los participantes podrán iniciar
sesión
CRUD Participantes: Quiere decir que se crearán, leerán, actualizarán y eliminarán los
participantes, para esta parte se verificará que los datos ingresados sean válidos. Esto lo
hará un organizador.
Monitoreo: En esta acción los participantes podrán visualizar los datos para poder
verificar su desenvolvimiento en la carrera
Historial: Se generará un historial del desenvolvimiento del participante durante la

carrera.
109
3.13. Diagramas de flujo de datos
A continuación de las figuras 3.42 al 3.46 a la se indican los diagramas de flujo de datos de la
aplicación web y móvil. Y en las figuras 3.47 a la 3.53 se indican los diagramas de flujo de datos
de la programación de microcontrolador. Los CRUD’s son en caso de que sea un organizador.
Aplicaciones web y móvil
Inicio
Id=0
Contraseña=0
Ingresa usuario y
Verificando
contraseña
Id=idbase
Servidor contraseña= Volver a
Error=TRUE
contraseñabase intentarlo=TRUE
Acceso
exitoso=TRUE
Seleccione una
opción
CRUD Monitoreo Cerrar sesión Fin
Genera historial
Figura 3.42. Diagrama de flujo de la página web
En la figura 3.42 se indica el diagrama de flujo de la página web.

Que constará de inicialización de variables, ingresar usuario y contraseña (esto lo verificará con
el servidor, si la verificación es exitosa continuará, si no enviará un error). Inmediatamente se
podrá hacer un CRUD, monitorear, generar historial o cerrar sesión.
110
CRUD
Op=0
Nombre
Appaterno
Apmaterno
Email
contraseña
Seleccione una opción.

Op=1 -> Registra
Op=2 -> Visualiza
Op=3 ->Modifica
Op=4-> Eliminar
Op=5 -> Salir
Op=Otro ->Error
Op=1 Op=2 Op=3 Op=4 Op=5 Op=Otro
Reg Nombre id
id
Reg Appaterno id ERROR
Reg Apmaterno
Reg Email
Reg contraseña
Id=idbase
Id=idbase
Error
Id=idbase Error
Error
Base de datos Información

Información
Información Fin
Reg Nombre Base de datos

Reg Appaterno Nombre==NULL
Base de datos Appaterno==NULL
Reg Apmaterno
Reg Email Apmaterno==NULL
Reg contraseña Email==NULL
contraseña==NULL
Figura 3.43. Diagrama de flujo del CRUD organizador
En la figura 3.43 se indica el diagrama de flujo del CRUD organizador

Que constará de inicialización de variables y un menú:
Opción 1: Registro de organizador en la base de datos
Opción 2: Visualiza organizadores
Opción 3: Modifica organizadores con la base de datos
Opción 4: Elimina organizadores con la base de datos
Opción 5: Salir
Opción otro: Error
Fin
111
CRUD
Op=0
Nombre
Appaterno
Apmaterno
Email
contraseña
Edad
Sexo
Dirección
Observaciones
Pulso
Temperatura

Op=1 -> Registra
Op=2 -> Visualiza
Op=3 ->Modifica
Op=4-> Eliminar
Op=5 -> Salir
Op=Otro ->Error
id
id
Reg Nombre
id ERROR
Reg Appaterno
Reg Apmaterno
Reg Email
Reg contraseña Id=idbase
Reg Edad Id=idbase
Error
Reg Sexo Id=idbase Error
Error
Reg Dirección
Reg Observaciones
Reg Pulso
Información
Reg Temperatura Información
Información Fin
Reg Nombre Base de datos

Reg Appaterno Nombre==NULL
Base de datos
Base de datos Reg Apmaterno Appaterno==NULL
Reg Email Apmaterno==NULL
Reg contraseña Email==NULL
Reg Edad contraseña==NULL
Reg Sexo Edad==NULL
Reg Dirección Sexo==NULL
Reg Observaciones Dirección==NULL
Reg Pulso Observaciones==NU
Reg Temperatura LL
Pulso==NULL
Temperatura==NUL
L
Figura 3.44. Diagrama de flujo del CRUD participante
En la figura 3.44 se indica el diagrama del CRUD participante

Opción 1: Registro de participante en la base de datos
Opción 2: Visualiza participante
Opción 3: Modifica participante con la base de datos
Opción 4: Elimina participante con la base de datos
Opción 5: Salir
Opción otro: Error
Fin
112
CRUD
Información
Distancia
Duración
Fecha
Hora de inicio
Hora de fin

Op=1 -> Registra
Op=2 -> Visualiza
Op=3 ->Modifica
Op=4-> Eliminar
Op=5 -> Salir
Op=Otro ->Error
id
id
id ERROR
Reg Información
Reg Distancia
Reg Duración Id=idbase
Id=idbase
Reg Fecha Error
Id=idbase Error
Reg Hora de inicio Error
Reg Hora de fin
Información
Información
Información Fin
Base de datos
Información
Base de datos == NULL
Base de datos
Reg Información Distancia
Reg Distancia == NULL
Reg Duración Duración
Reg Fecha Fecha
Reg Hora de inicio == NULL
Reg Hora de fin Hora de inicio== NULL
Hora de fin== NULL
Figura 3.45. Diagrama de flujo del CRUD carreras
En la figura 3.45 se indica el diagrama de flujo del CRUD carreras

Opción 1: Registro de carreras en la base de datos
Opción 2: Visualiza carreras
Opción 3: Modifica carreras con la base de datos
Opción 4: Elimina carreras con la base de datos
Opción 5: Salir
Opción otro: Error
Fin
113
Monitoreo
id
Id=idbase Error
Número de carrera
Nombre
Temperatura
Ritmo cardíaco
Ubicación
Alerta
Fin
Figura 3.46. Diagrama de flujo del monitoreo

En la figura 3.46 se indica el diagrama de flujo del monitoreo
Que constará en buscar mediante un id al participante, si este coincide con la base de datos
desplegará el número de carrera, nombre, temperatura, ritmo cardíaco, ubicación y alerta (en caso
de ser necesario), si no coincide marcará error.
Fin.
Los siguientes diagramas pertenecen a la programación del microcontrolador, su descripción se
encuentra al final de estos.
114
Figura 3.47. Diagrama de flujo del programa principal
115
Figura 3.48. Diagrama de flujo del sensor de pulso cardíaco
116
Figura 3.49. Diagrama de flujo de la ISR TIMER 1
117
Figura 3.50. Diagrama de flujo del sensor de temperatura
118
Figura 3.51. Diagrama de flujo del envío de datos (1)
119
120
121
Descripción general del diagrama de flujo del microcontrolador
Variables:
A continuación se hace una pequeña descripción de las variables utilizadas en los diagramas de
flujo del microcontrolador.
Variables:
AD1COM1=Buffer de 16 bits que configura en convertidor analógico-digital:
Bit 15: ADON: Modo de operación del A/D.
0 = Convertidor A/D está operando.
1 = Convertidor A/D está apagado.
Bit 14: Se lee como 0.
Bit 13: ADSIDL: A/D para en modo de inicio.
0 = En modo de discontinuidad de operación cuando se está en modo inactivo.
1 = En modo de operación cuando se entra en modo inactivo.
Bit 12-10 Se leen como 0.
Bit 9-8 FORM<1:0>: Formato de salida.
11 = Fracción con signo (sddd dddd dd00 0000)
10 = Fracción sin singo (dddd dddd dd00 0000)
01 = Entero con signo (ssss sssd dddd dddd)
00 = Entero sin signo (0000 00dd dddd dddd)
Bit 7-5 SSRC<2:0>: Conversión.
111 = Al termino del contador interno y empieza la conversión.
110 = Reservado
101 = Reservado
100 = Reservado
011 = Reservado
010 = El comparador del Timer1 termina y empieza la conversión.
001 = Al término de la transacción activo del pin INT0 y empieza la conversión.
Bit 4-3 Se leen como 0.
Bit 2 ASAM: Auto-comienzo.
122
1 = Muestreo comienza inmediatamente después de la última conversión completada.
0 = Muestreo comienza cuando el bit SAMP se establece.
Bit 1 SAMP: Permisos de muestras A/D.
1 = La muestra-y-amplificación es el muestre de entrada.
0 = La muestra-y-amplificación es la amplificación.
Bit 0 DONE: Estado de la conversión.
1 = Conversión es realizada
0 = Conversión no realizada
AD1COM2=Buffer de 16 bits que configura en convertidor analógico-digital:
Bit 15-13 VCFG<2:0>: Modo de operación
VCFG<2:0> VR+ VR-
000 AVDD AVSS
001 Pin VREF+ externo AVSS
010 AVDD Pin VREF- externo
011 Pin VREF+ externo Pin VREF- externo
1xx AVDD AVSS
Bit 12 OFFCAL: Calibración de compensación
1 = Conversiones para obtener el valor de calibración.
0 = Conversiones para obtener el valor de entrada real.
Bit 11 Se lee como 0.
Bit 10 CSCNA: Selección de entrada digitalizada para la entrada del multiplexor MUX A
1 = Entradas digitales.
0 = No entradas digitales.
Bit 9-8 Se lee como 0.
Bit 7 Bit reservado.
Bit 6 Se lee como 0.
Bit 5-2 SMPI<3:4>: Convertir bits de secuencias por interrupción de selección
1111 =
* =
123
* = Reservados
* =
0010 =
0001 = Interrupciones en la terminación de la conversión para cada segunda secuencia de
conversión o muestra.
0000 = Interrupciones en la terminación de la conversión para cada secuencia de conversión o
muestra.
Bit 1 Bit reservado. Siempre mantenerlo como 0
Bit 0 ALTS: Alternativa de selección de la muestra de entrada.
1 = Utiliza el multiplexor MUX A para configurar para la primera muestra, después, alterna
entre los multiplexores MUX B y MUX A para configurar las muestras posteriores.
0 = Siempre utiliza el multiplexor MUX A para configurar.
AD1CON3= Buffer de 16 bits que configura en convertidor analógico-digital:
Bit 15 ADRC: Conversión fuente del reloj
1 = Reloj interno RC
0 = Reloj derivado del sistema del reloj
Bit 14 EXTSAM: Tiempo de muestreo
1 = Convertidor A/D está muestreando aun después de que SAMP = 0
0 = A/D termina el muestreo
Bit 13 PUMPEN: Bomba de carga activada.
1 = Bomba de carga para los interruptores está activado
0 = Bomba de carga para los interruptores está desactivado
Bit 12-8 SAMC<4:0>: Tiempo de Auto-muestra
11111 = 31 TAD
00001 = 1 TAD
00000 = 0 TAD
Bit 7-6 Mantener como 0.
Bit 5-0 ADCS: Selección del tiempo de conversión
11111 = 64 • TCY
11110 = 63 • TCY
124
00001 = 2 • TCY
00000 = TCY
AD1CHS = Buffer de 16 bits que configura en convertidor analógico-digital:
bit 15 CH0NB: Selección de la entrada negativa del canal 0 para la configuración del
multiplexor MUX B
1 = La entrada negativa del canal 0 es AN1
0 = La entrada negativa del canal 0 es VR-
bit 14-12 Se lee como 0.
bit 11-8 CH0SB<3:0>: Selección de la entrada positiva del canal 0 para la configuración
del multiplexor MUX B.
1111 = AN15
1110 = AN14
1101 = AN13
1100 = AN12
1011 = AN11
1010 = AN10
1001 = AN9
1000 = (0.785 * VDD)
0111 = (0.215 * VDD)
0110 = Referencia interna (VBG)
0101 = Reservado
0100 = AN4
0011 = AN3
0010 = AN2
0001 = AN1
0000 = AN0
bit 7 CH0NA: Selección de la entrada negativa del canal 0 para la configuración del
multiplexor MUX A
1 = La entrada negativa del canal 0 es AN1
0 = La entrada negativa del canal 0 es VR-
125
bit 6-4 Leer como 0
bit 3-0 CH0SA<3-0>: Selección de la entrada positiva del canal 0 para la configuración del
multiplexor MUX A. Las combinaciones son idénticas a CH0SB<3:0>.
ADC1BUF0=Buffer de 16 bits que contiene los datos de entrada y salida del convertidor A/D
ADCValue=Buffer de 10 bits
MRx: Registro timer contador de 16 bits
PR1: Registro de periodo de 16 bits asociado con el timer.
T1CON: Registro de control de 16 bits asociado con el timer.
SSP1STAT= Registro de control de 16 bits asociado con el módulo SPI
bit 15-8 Se lee como 0.
bit 7 SMP: Muestra
SPI modo maestro:
1 = Los datos de entrada se muestrea al final del tiempo de salida de datos
0 = Los datos de entrada se muestrea en la mitad del tiempo de salida de datos
SPI modo esclavo:
SMP debe ser 0 cuando SPI está en modo esclavo.
bit 6 CKE: Selección de reloj.
1 = Transmisión se produce en la transición de activo a inactivo del estado del reloj.
0 = Transmisión se produce en la transición de inactivo a activo del estado del reloj.
bit 5-1 Reservados.
bit 0 BF: Estado del buffer
1 = si SSPxBUF está lleno.
0 = si SSPxBUF no está lleno.
SSP1CON1= Registro de control de 16 bits asociado con el módulo SPI
bit 15-8 Se leen como 0.
bit 7 WCOL: Detección de colisiones en la escritura
1= El registro SSPxBUF está escrito cuando todavía está transmitiendo la palabra anterior (debe
ser despejado en el software).
0 = Sin colisión
126
bit 6 SSPOV: MSSPx Recibe Indicador de desbordamiento bits
SPI Slave mode:
1 = Un nuevo byte se recibe mientras que el registro SSPxBUF aún mantiene los datos anteriores.
En caso de desbordamiento, se pierden los datos en SSPxSR. El desbordamiento sólo puede
producirse en el modo esclavo. El usuario debe leer el SSPxBUF, aunque si sólo se transmiten
datos, para evitar el desbordamiento (debe ser aclarado en el software).
0 = Sin desbordamientos
bit 5 SSPEN: Permite MSSPx
1 = Permite puertos seriales y configuraciones SCKx, SDOx, SDIx y SSx
0 = Deshabilita el puerto serial y sus configuraciones
bit 4 CKP: Selección de la polaridad del reloj
1 = Reloj en estado de reposo en alto nivel
0 = Reloj en estado de reposo en bajo nivel
bit 3-0 SSPM<3:0>: Selección de modo MSSPx
1010 = SPI modo maestro, Clock = FOSC/(2 * ([SSPxADD] + 1))
0101 = SPI modo esclavo, Clock = pin SCKx; control del pin SSx esta desactivado, SSx puede
ser usado como I/O.
0100 = SPI modo esclavo, Clock = SCKx pin; SSx pin control esta desactivado
0011 = SPI modo maestro, Clock = TMR2 salida/2
0010 = SPI modo maestro, Clock = FOSC/32
0001 = SPI modo maestro, Clock = FOSC/8
U2MODE= Registro de control de 16 bits asociado con el módulo UART
bit 15 UARTEN: Permitir UARTx
1 = UARTx está activado.
0 = UARTx está desactivado.
bit 14 Se lee como 0.
bit 13 USIDL: UARTx termina el modo inactivo
1 = Módulo discontinuo de operación cuando entra en modo de inactividad.
0 = Módulo continuo de operación en modo inactivo.
bit 12 IREN: IrDA® codificador y decodificador habilitado.
127
1 = IrDA codificador y decodificador habilitado
0 = IrDA codificador y decodificador deshabilitado
bit 11 RTSMD: Modo de selección para pines UxRTS
1 = Pin UxRTS en modo simple.
0 = Pin UxRTS en modo de control de flujo.
bit 10 Se lee como 0
bit 9-8 UEN: UARTx habilitado
11 = Pines UxTX, UxRX y UxBCLK están habilitados y en uso; Pin UxCTS es controlado por
cierres de puertos.
10 = Pines UxTX, UxRX, UxCTS y UxRTS están habilitados y en uso.
01 = Pines UxTX, UxRX y UxRTS están habilitados y en uso. Pin UxCTS es controlado por
cierres de puertos.
00 = Pines UxTX y UxRX están habilitados y en uso.; Pines UxCTS y UxRTS/UxBCLK son
controlado por cierres de puertos.
bit 7 WAKE: Despertar el inicio detección durante el modo dormido habilitado.
1 = UARTx continuará con las muestras del pin UxRX; interrupción se genera en flanco
descendente, se borra en el hardware en flanco ascendente siguiente.
0 = No wake-up is enabled
bit 6 LPBACK: UARTx Selección del modo “Loopback”
1 = Modo “Loopback” habilitado.
0 = Modo “Loopback” deshabilitado.
bit 5 ABAUD: Auto-Baud Habilitado
1 = Permite la medición de la velocidad de transmisión en el siguiente carácter - requiere la
recepción de un campo de sincronización (55h); despejado en hardware sobre la terminación.
0 = Medición de velocidad de transmisión está deshabilitado o completada
bit 4 RXINV: Recibe Polaridad Inversión
1 = Estado inactivo de UxRX es ‘0’
0 = Estado inactivo de UxRX es ‘1’
bit 3 BRGH: Alta velocidad de transmisión activada
1 = BRG genera 4 relojes por período de bits (en modo de alta velocidad)
128
0 = BRG genera 16 relojes por período de bits (modo estdar)
bit 2-1 PDSEL: Paridad y selección de datos.
11 = 9-bit de datos, no paridad.
10 = 8-bit de datos, paridad impar.
01 = 8-bit de datos.
00 = 8-bit de datos, no paridad.
bit 0 STSEL: Para la selección de bits
1 = dos paro por bit
0 = un paro por bit
U2STA= Registro de control de 16 bits asociado con el módulo UART
bit 15,13 UTXISEL: UARTx Interrupción de transmisión en modo de selección
11 = Reservado
10 = Interrumpir cuando el dato es transferido por (TSR), y el resultado de la transmisión resulta
en buffer vacío.
01 = Interrumpir cuando el último carácter se desplaza fuera de la transmisión Shift Register;
todas las operaciones de transmisión se completan
00 = Interrumpir cuando un carácter se transfiere al Registro de desplazamiento de transmisión
(esto implica que hay al menos un carácter abierto en la memoria intermedia de transmisión)
bit 14 UTXINV: IrDA® Codificador de inversión de polaridad
Si IREN = 0:
1 = UxTX desactivado en ‘0’
Si IREN = 1:
bit 12 leer en ‘0’
bit 11 UTXBRK: UARTx Transmisión cortada
1 = Envía sincronización rota en la próxima transmisión - Empieza el bit, seguido de doce '0';
seguido de un Bit de parada; despejado por hardware sobre la terminación
0 = Transmisión de sincronización rota esta discapacitado o completado
129
bit 10 UTXEN: UARTx Transmisión habilitada
1 = Transmisión habilitada.
0 = Transmisión deshabilitada.
bit 9 UTXBF: UARTx Estado del buffer de transmisión (solo lectura)
1 = Buffer lleno
0 = Buffer no está lleno
bit 8 TRMT: Bit de transmisión de registro (Solo lectura)
1 = El registro de transmisión está vacío y el buffer de transmisión está vacía (la última
transmisión ha sido completada).
0 = El registro de transmisión no está vacío.
bit 7-6 URXISEL: UARTx Recibe interrupción del Modo de selección
11 = La interrupción se establece en la transferencia RSR,
10 = Reservado
01 = Reservado
00 = La interrupción se establece cuando se recibe cualquier carácter y se transfiere de la RSR
para el buffer de recepción; buffer de recepción tiene uno o más caracteres.
bit 5 ADDEN: Dirección del carácter detectado bit
1 = Modo detección de dirección habilitad; si el bit 9 no está seleccionada, esto no tiene efecto.
0 = Modo detección de dirección deshabilitad
bit 4 RIDLE: Inactividad recibida(Solo lectura)
1 = Recibir si está inactivo
0 = Receiver si está activo
bit 3 PERR: Paridad del estado de error (Solo lectura)
1 = Error de paridad se ha detectado para el carácter actual
0 = Error de paridad no se ha detectado.
bit 2 FERR: Estado de error(solo lectura)
1 = Error ha sido detectado para el carácter actual
0 = = Error no se ha detectado.
bit 1 OERR: Estado de error del buffer bit (solo lectura)
130
1 = Buffer desbordado
0 = Buffer no está desbordado
bit 0 URXDA: UARTx Recibir datos disponibles del buffer (solo lectura)
1 = El buffer contiene datos.
0 = El buffer no contiene datos.
TRISx= Este registro nos sirve para poder configurar cada pin de E/S como entrada o como
salida. 1 como entrada, 0 como salida.
PORTx = Los datos en los pines de E/S son accedidos a través de este registro.
LATx = Cuando hacemos una lectura a estos registros se regresa el valor contenido en los latch
de salida del puerto en lugar de los pines de E/S.
Temperatura=buffer de 12 bits.
SSP1BUF= buffer del módulo SPI.
Cardiaco1 = buffer de 8 bits.
Cardiaco2 = buffer de 8 bits.
Temp1 = buffer de 8 bits.
Temp2 = buffer de 8 bits.
IFS0 = Bandera de estado de interrupción. Registro de 16 bits.
T1IF = IFS0<3>=Estado de interrupción del Timer1.
1 = La interrupción ha ocurrido.
0 = La interrupción no ha ocurrido.
IEC0 = Registro de control de interrupciones. Registro de 16 bits.
T1IF = IEC0<3>=Interrupción del timer1 habilitado
1 = La interrupción habilitada.
0 = La interrupción no habilitada.
3.14. Diagramas electrónicos
A continuación en la figura 3.54 y 3.55 se indican los diagramas en 3D de la placa del dispositivo
electrónico, en las figuras 3.56 y 3.57 se indica el diseño de la placa, en la figura 3.58 se indica el
131
diagrama esquemático del dispositivo electrónico y en la figura 3.59 el diagrama del
funcionamiento interno del sensor de pulso cardíaco.
Figura 3.54. Imagen de la Placa en 3D (1)
Figura 3.55. Imagen de la Placa en 3D (2)
132
Figura 3.56. Diseño de la placa (1)
Figura 3.57. Diseño de la placa (2)
133
Figura 3.58. Esquemático del dispositivo electrónico
Los cálculos necesarios se encuentran indicados en los anexos (Anexo 1).
134
Figura 3.59. Funcionamiento interno del pulse sensor
135
Figura 3.60. Funcionamiento interno del TC77
136
3.15. Interfaz de comunicación
La información obtenida por el dispositivo electrónico se enviará para su interpretación de la

siguiente manera
El sensor de pulso cardíaco nos dará una salida de 10 bits (el convertidor A/D del
microcontrolador tiene un buffer de 16 bits, en ese buffer cuando convertimos la señal a digital
nos entrega 10 bits de salida).
El sensor de temperatura nos da una salida de 12 bits.
Se dividirá cada una de las salidas del sensor de pulso cardíaco y de temperatura a la mitad (5 bits
y 6 bits respectivamente para su envío y se clasificarán en parte baja o parte alta).
La información será enviada bit a bit (comunicación serial) mediante el módulo UART al módulo
bluetooth como se indica a en la tabla 3.2:
Pulso o Ubicaci VALOR VALOR VALOR VALOR VALOR VALOR
temperat ón OBTENI OBTENI OBTENI OBTENI OBTENI OBTENI
ura DO DO DO DO DO DO
Tabla 3.2. Envío de información por bluetooth
 Si es información del sensor del pulso cardíaco se enviará un 1 de lo contrario se enviará
un 0.
 Si es la parte baja de la división se enviará un 1, de lo contrario se enviará un 0. Ver figura
3.60.
Figura 3.60. División de la información

 En los 6 lugares restantes será la información obtenida (ya sea parte o baja).
 En el caso del pulso cardíaco el bit faltante se tomará como un 0.
137
3.16. Avances
A continuación se indican los avances y pruebas realizadas para Trabajo Terminal 1, hasta junio
2015.
Sensor de pulso cardíaco
En la figura 3.61 se puede apreciar la señal obtenida del pulso cardíaco por medio del
osciloscopio. Para la etapa de trabajo terminal 1, se realizan pruebas en una persona en reposo.
En esta etapa se definio que se utilizaría un filtro para hacer más visible la onda de la diástole (la
más pequeña).
Figura 3.61. Prueba sensor pulso cardiaco con filtro

La señal en la parte de arriba de la imagen es la señal no filtrada y la que está en la parte baja es
la ya filtrada. Se puede observar que está un poco desfasada ya que el filtro siempre genera un
desfase que depende de la frecuencia de corte (Tan-1 (fcorte\f)).
Esto nos ayudará a que la señal digital obtenida tenga una mayor precisión.
138
Adicionalmente, en esta fase se propone utilizar un cristal oscilador para aumentar la frecuencia
con la que trabaja el microcontrolador, que trabaje con los 16 MIPS del microcontrolador y éste.
Además este cristal ayudará a que se tenga una buena sincronización con el modulo bluetooth
(UART) con una mínima probabilidad de error.
Debido a que el microcontrolador admite frecuencias de 8 a 32 MHZ pero a su vez solo trabaja
con una frecuencia interna de la mitad de 16 MHZ, es decir 8MHZ, se propone agregar un cristal
oscilador de 7.3 MHz con 4 PLL, con esto obtenemos 29.2 MHZ (7.3 x 4 = 29.2 MHZ) esto entre
dos nos da un total de frecuencia de procesamiento de 14.6 MHZ, es decir casi el doble de
frecuencia que tendría el microcontrolador sin el cristal.
Adicionalmente, cabe mencionar que para la comunicación entre el teléfono móvil y la aplicación
web será mediante sockets con peticiones HTTP, y como se usará Javascript utilizaremos JSON
(JavaScript Object Notation), ya que es un formato ligero para el intercambio de datos.
Vistas.
En esta sección se indicarán las vistas propuestas para este prototipo tanto de aplicación web
como aplicación móvil
Aplicación web
A continuación en de la figura 3.62 a la 3.65 se indican las vistas preliminares de la aplicación
web.
139
Figura 3.62. Bienvenida
140
Figura 3.63. Monitoreo de la carrera
141
Figura 3.64. Ubicación del participante
142
Figura 3.65. Ver carreras
143
Aplicación móvil
A continuación de la figura 3.66 a la 3.68 se indican las vistas preliminares para la aplicación
móvil.
Figura 3.66. Inicio de sesión
144
Figura 3.67. Monitoreo
145
Figura 3.68. Historial del monitoreo
146
CAPÍTULO 4. IMPLEMENTACIÓN
En el presente capítulo se indican las fases de implementación del prototipo tanto de la aplicación
web, móvil y el dispositivo electrónico.
Con base en el diagrama de la figura 4.1 el cual nos indica que los participantes de la carrera
portarán el dispositivo electrónico para que sus signos vitales sean obtenidos, dicha información
será enviada mediante bluetooth a la aplicación móvil para que sea desplegada, estos dos
dispositivos los llevará consigo el participante durante toda la carrera. La información obtenida
por la aplicación móvil se enviará mediante un servicio de datos o de internet a un servidor para
que la aplicación web pueda hacer las peticiones de información a éste y desplegarlos, con esto
los organizadores podrán consultarlos en cualquier momento. En las siguientes secciones se
explicarán las partes fundamentales de la implementación del prototipo.
Figura 4.1. Diagrama de arquitectura final del prototipo
147
4.1. Aplicación web
A continuación se indica de manera general la implementación de la aplicación y el servidor web.
En la figura 4.2 se muestra el código programado para la conexión de la base de datos del
servidor con el sistema gestor de base de datos, Mysql, indicando el número de host, usuario,
contraseña, el número de puerto y finalmente el nombre de la base de datos. Para esta fase de
implementación primero se desarrolló la aplicación de manera local para finalmente subirla a la
nube y que esté disponible para cualquier usuario, esto con el fin de que el usuario no tenga la
necesidad de tener que instalar la aplicación principal cada vez que la necesite, sino simplemente
consultar la dirección en la que se encuentra hospedada.
Figura 4.2. Conexión con la base de datos

En la figura 4.3 se muestra el código programado para la conexión de la aplicación con el entorno
en la nube, Openshift, indicando la dirección ip y el puerto.
Figura 4.3. Conexión con Openshift

¿Por qué usar Openshift como plataforma en la nube?
OpenShift permite desarrollar aplicaciones en un entorno de nube. Específicamente el concepto
de Plataforma como Servicio (PaaS, Platform as a Service) es una categoría de servicios cloud
que proporciona una plataforma y un entorno que permiten a los desarrolladores crear
aplicaciones y servicios que funcionen a través de internet. Los servicios PaaS se hospedan en la
nube, y los usuarios pueden acceder a ellos simplemente a través de su navegador web.
En la figura 4.4 se muestra el código programado para la inicialización del socket web: obtiene y
redirige a través de un socket los mensajes entre el servidor y la aplicación web.
148
Se indica principalmente el envío y recepción de mensajes del lado del servidor.
4.4. Inicialización del socket web

En la figura 4.5 se muestra el código programado para la recepción de mensajes de la aplicación
web. También se indican varios puntos importantes como la dirección principal en la cual los
usuarios de la aplicación web accederán a esta, y el manejo de alertas que se desplegarán en la
sección de alertas del participante, estas alertas serán las siguientes:
 “Peligro” indica que el participante ha llegado a niveles peligrosos en sus signos vitales
(alerta roja).
 “Alerta” indica que el participante apenas se está acercando a estos valores (alerta
amarilla).
 “Alerta emitida por el participante” cuando el participante envía una alerta manual desde
la aplicación móvil.
149
Figura 4.5. Recepción de mensajes del servidor a la aplicación web
De las figuras 4.6 a la 4.9 se muestra el código programado para generar el historial de cada
participante. El historial se irá generando dependiendo de cada carrera deportiva. El organizador
deberá indicar un intervalo de tiempo para la generación del historial, si el organizador indica
como intervalo “Cada 5 minutos” significa que cada 5 minutos se guardarán los valores de
participante en una tabla que podrá ser consultada al finalizar la carrera.
Figura 4.6. Envío y recepción del historial

150
Figura 4.7. Inserción de la información al historial
Figura 4.8. Consulta de la información para ser guardado en el historial

151
Figura 4.9. Eliminar información del historial
Al terminar la implementación del servidor y de la aplicación web de manera local, se procedió a
subirla a la nube para que pudiera ser consultada en cualquier momento, para esto se realizó lo
siguiente:
Se creó una cuenta en Openshift, la plataforma en la nube mencionada anteriormente. En las
figuras 4.10 y 4.11 se indica que nuestra aplicación ya está totalmente cargada a la nube y el
dominio con el cual podremos consultarla.
152
Figura 4.10. Aplicación Cargada en Openshift
Figura 4.11. Dominio de la aplicación web

En la figura 4.12 se muestra la vista principal de la aplicación web, la cual ya se encuentra
cargada para su consulta.
El dominio de la aplicación quedó como: monitoreo-trabajoterminal.rhcloud.com. Tanto en las
figuras 4.13 y como en la 4.14 se indica cómo acceder directamente a la base de datos con el
usuario y contraseña del administrador, esto en caso de que el administrador principal de la
aplicación necesite hacer algún ajuste.
153
Figura 4.12. Vista principal de la aplicación web
Figura 4.13. Accediendo a phpmyadmin
154
Figura 4.14. Accediendo a la base de datos “monitoreo”
Los códigos completos se podrán consultar en los anexos incluidos en el presente trabajo.
4.2. Aplicación móvil
A continuación en esta sección se indican las partes fundamentales de la implementación de la

aplicación móvil.
En la figura 4.15 se muestra el código programado para las peticiones GET al servidor. El
servidor al ser web opera mediante el protocolo HTTP, de la capa de aplicación del Modelo OSI.
Las peticiones al servidor suelen realizarse mediante HTTP utilizando el método de petición
GET, en el que el recurso se solicita a través de la dirección URL al servidor web.
155
Figura 4.15. Petición GET
En la figura 4.16 se muestra el código programado para la petición POST al servidor. Los datos a
enviar al servidor se incluyen en el cuerpo del código de la misma petición.
Figura 4.16. Petición POST
156
En la figura 4.17 se muestra el código programado para la conexión socket entre el navegador
web y el servidor. Existe una conexión persistente entre el cliente y servidor, y ambas partes
pueden empezar a enviar datos en cualquier momento.
Figura 4.17. Conexión socket

En las figuras 4.18 se muestra el código programado para la conexión con el Bluetooth para la
recepción de las variables a mostrar (ritmo cardíaco y temperatura).
Figura 4.18. Conexión Bluetooth
157
En la figura 4.19 se muestra el código programado para la recepción y conversión de binario a
decimal de las variables a monitorear.
Figura 4.19. Recepción de variables

Los códigos completos se podrán consultar en los anexos incluidos en el presente trabajo.
4.3. Dispositivo electrónico
A continuación en esta sección se indican las partes fundamentales de la implementación del

dispositivo electrónico.
Para la programación del microcontrolador se seleccionó el algoritmo de autocorrelación para el

procesamiento de la señal del pulso cardíaco, esto para obtener la frecuencia fundamental de la
señal y obtener las pulsaciones por minuto tomando en cuenta que nuestra frecuencia de corte es
de 3.3 Hz con 200 pulsaciones por minuto.
Según John G. Proakis la correlación [90] es una operación similar a la convolución que se
utiliza para medir la similitud entre dos secuencias. Por otro lado la función de autocorrelación
158
se define como la correlación cruzada de la señal consigo misma. La función de autocorrelación
resulta de gran utilidad para encontrar patrones repetitivos dentro de una señal, como por ejemplo
identificar la frecuencia fundamental de una señal. Si y(n) = x(n), entonces se obtiene la
autocorrelación de x(n), que se define como la secuencia (Figura 4.20):
Figura 4.20. Autocorrelación de una señal

Se utilizó un módulo FTDI FT232RL USB a 3.3V para capturar cierta cantidad de muestras del
sensor de pulso cardíaco (Pulse Sensor) y poderlas visualizar en la computadora. Para saber la
cantidad de muestras que obtendremos primero revisamos el tamaño del convertidor ADC que es
de 10 bits y de los registros para almacenar las muestras que tienen un tamaño de 16 bits. Ahora
multiplicando 10*10 bits que sería el valor máximo de la señal autocorrelacionada daría un valor
más elevado del tamaño de un registro por lo tanto no se podrá almacenar, para solucionar esto se
hizo un corrimiento a la derecha de 3 bits para disminuir el tamaño de la señal sin perder sus
propiedades y así poder manipularla más fácilmente.
Se obtuvo un total de 200 muestras en 4 segundos, el algoritmo compara cada muestra con el fin
del obtener el segundo valor más alto, es decir, segundo pico más alto de la señal y el valor
obtenido será la frecuencia fundamental de la señal. Se configuró la velocidad de transmisión con
19200 baudios que es el máximo con el que puede trabajar el módulo bluetooth, el baudio es una
unidad de medida utilizada en telecomunicaciones, que representa el número de símbolos por
segundo en un medio de transmisión digital, el módulo ADC se configuró con una velocidad de
transmisión de 19,200 baudios (lo que equivaldría a 1,920 bits por segundo).
En la figura 4.21 se indican las muestras obtenidas graficadas en MATLAB y en la figura 4.22 se
indica la misma señal aplicandole la autocorrelación.
159
Figura 4.21. Señal del pulso cardíaco en MATLAB
Figura 4.22. Señal del pulso cardíaco en MATLAB aplicándole autocorrelación

Con base en la figura 4.22 pudimos observar que el segundo pico más alto tiene un valor de 1.13
lo que sería el valor de la frecuencia fundamental de la señal, este valor equivale a 68 pulsaciones
por minuto.
El PIC24F16KL401 fue programado en ensamblador, lo primero que se hizo fue cargar la
biblioteca del PIC24F16KL401: Este archivo de cabecera define configuraciones, registros y
otros bits de información útiles para el microcontrolador PIC24F16KL401. Se configuró el
oscilador interno (este trabaja a un máximo de 8 MHZ). El oscilador tiene 4 formas de trabajo:
160
1. Oscilador estándar: Habilita el uso de un oscilador externo
Estado: Deshabilitado
2. High speed- oscilador externo
3. Low power- oscilador externo
4. Oscilador primario (Deshabilita el uso de osciladores externos)
Estado: Habilitado
5. Watchdog: Protección usada para volver a reiniciar el programa cuando éste "se pierde".
6. Inicialización de periféricos (entradas y salidas)
Se realizó la configuración del Timer1: Este módulo se utiliza para darle la frecuencia de trabajo
al módulo ADC (Convertidor Analógico Digital). Se configuró esta frecuencia de trabajo a 50 HZ
(50 veces por segundo)
Se manejó un máximo y un mínimo de pulsaciones antes del colapso de un atleta, teniendo como
máximo 200 pulsaciones y un mínimo de 30 pulsaciones antes de un paro cardíaco. Como las
pulsaciones mínimas por minuto antes del colapso en una persona son 30 pulsaciones. Es decir
ocurre 1 pulsación por cada dos segundos en un minuto (para el algoritmo de auto correlación se
necesitan 2 señales que comparar) Así que se obtendrán muestras por 4 segundos (4 segundos por
50 nos da un total de 200 muestras procesar).
Se configuró el UART (comunicación serial), la cual se utilizará para la comunicación entre el
microcontrolador y la PC (para la primera etapa de pruebas) para después implementarlo con el
módulo bluetooth al celular.
En la figura 4.23 se indica el código programado para el procesamiento de la señal del pulso
cardíaco, el algoritmo de autocorrelación.
161
Figura 4.23. Algoritmo de autocorrelación en ensamblador
En la figura 4.24 se muestra el código programado para la obtención de la temperatura mediante
la interfaz de comunicaciones SPI.
162
Figura 4.24. Obtención de la temperatura
En la figura 4.25 se muestra el código programado para el envío del pulso cardíaco al módulo
bluetooth, en la figura 4.26 se indica el envío de la temperatura al módulo bluetooth. El proceso
para la obtención del pulso tarda un aproximado de 6 segundos, mientras que la temperatura tarda
300ms, se programó un retardo para que la temperatura y el pulso sean enviados de manera
simultánea.
Figura 4.25. Envío del pulso al módulo bluetooth
163
Figura 4.26. Envío de la temperatura al módulo bluetooth
Utilizando un módulo FTDI, mencionado anteriormente, se programó una pequeña aplicación de
prueba en java, esto con el fin de visualizar el ritmo cardíaco y temperatura obtenidos. Se armó
un pequeño prototipo en una tablilla de experimentación “Protoboard”, utlizando como
alimentación y programador un PICKIT 3 de Microchip, ver figura 4.27.
Figura 4.27. Primer prototipo armado

164
Una vez hecho esto se enviaron los datos procesados a la PC, en la figura 4.28 se indica la salida
del programa de prueba desarrollado en java.
Figura 4.28. Salida del programa en java

Una vez funcionando esta parte se procedió al diseño de la placa final la cual va a portar el
participante y se dedicará al procesamiento de sus signos vitales. En la figura 4.29 se muestra el
diseño final de la placa.
Figura 4.29. Diseño de la placa final
165
En la figura 4.30 se indica el diagrama esquemático final de la placa.
Figura 4.30. Esquemático final
En la figura 4.31 muestra la placa final para el TC77 sensor de temperatura.
166
Figura 4.31. Diseño de la placa para el sensor de temperatura
En la figura 4.32 se indica el diagrama esquemático final de la placa del sensor de temperatura.
Figura 4.32. Esquemático sensor de temperatura
167
De las figuras 4.33 a la 4.35 se muestran algunas fases de la implementación de la placa final
utilizando la máquina de prototipado para PCB’s ProtoPlace 5
Figura 4.33. Implementación de la placa
168
Figura 4.34. Soldando componentes a la placa
En la figura 4.35 se puede observar la placa final terminada.
Figura 4.35. Placa final

Con esto se finaliza la descripción de las etapas de implementación de cada uno de los módulos
de este prototipo.
169
CAPÍTULO 5. PRUEBAS
En el presente capítulo se indican las fases de pruebas del prototipo tanto modulares, es decir, de
la aplicación web, móvil y el dispositivo electrónico tanto de integración del prototipo completo.
5.1. Pruebas modulares
En esta sección se indican las pruebas realizadas en cada uno de los módulos del prototipo
(aplicación web, aplicación móvil y dispositivo electrónico).
5.1.1. Aplicación web
A continuación muestra el funcionamiento general de la aplicación web.

En la figura 5.1 se indica el inicio de sesión de la aplicación web.
Figura 5.1. Inicio de sesión de la aplicación web
Figura 5.2. Pantalla principal de inicio de sesión como organizador
170
En caso de olvido de contraseña, el organizador puede solicitar que se le envíe a su correo
electrónico (ver figuras 5.3, 5.4 y 5.5).
Figura 5.3. Recuperar contraseña
Figura 5.4. Contraseña enviada
Figura 5.5. Contraseña enviada

Además se podrán consultar los organizadores, participantes y carreras registradas, se podrán
actualizar, agregar y eliminar más de ellos (ver figura 5.6, 5.7 y 5.8).
Figura 5.6. Vista principal de los organizadores

171
Figura 5.7. Vista principal de los participantes
Figura 5.8. Vista principal de las carreras

Se podrán consultar los datos tanto de organizador, participante y carreras registradas (ver figuras
5.9, 5.10 y 5.11).
Figura 5.9. Información del organizador
172
Figura 5.10. Información del participante
Figura 5.11. Información de la carrera

Una vez hecho el registro se podrá asignar o expulsar al participante en la carrera (ver figura
5.12).
Figura 5.12. Asignando al participante a una carrera

173
Se podrán consultar a los participantes asociados a una carrera (ver figura 5.13).
Figura 5.13. Participantes inscritos a una carrera

Con esto se finaliza la etapa de prueba modular de la aplicación web. Para mayor información
consulte el manual de usuario.
5.1.2. Aplicación móvil
A continuación en las siguientes figuras se indica el funcionamiento general de la aplicación

móvil.
En la figura 5.14 se indica la pantalla principal de la aplicación móvil.
Figura 5.14. Pantalla principal aplicación móvil

174
En caso de que el usuario no haya sido registrado en la aplicación web, este no podrá iniciar
sesión en la aplicación móvil (ver figura 5.15).
Figura 5.15. Usuario no encontrado en el servidor

En la figura 5.16 se indica el inicio de sesión del participante en la aplicación móvil, el usuario y
contraseña serán los mismos con los que se registró en la aplicación web.
La aplicación móvil hará las peticiones de esta información al servidor web.
175
Figura 5.16. Inicio de sesión
Después de un inicio de sesión se mostrará la pantalla de bienvenida, ver figura 5.17, después del
mensaje de bienvenida nos indica el estado de conexión entre la aplicación móvil y el dispositivo
electrónico (Dispositivo no conectado). En esta vista nos indica 4 botones principales:
1. Iniciar monitoreo: Deshabilitado cuando el dispositivo electrónico no está conectado a la
aplicación móvil mediante bluetooth).
2. Historial: Se podrá consultar el historial registrado de los signos vitales del participante.
3. Conectar con pulsera: Este botón servirá para conectar la aplicación móvil y el dispositivo
electrónico mediante Bluetooth.
4. Cerrar sesión.
176
Figura 5.17. Vista después del inicio de sesión.
Con esto se finaliza la etapa de prueba modular de la aplicación móvil. Para más detalles de
instalación y uso consulte los manuales adjuntos.
5.1.3. Dispositivo electrónico
En esta sección se indican las pruebas realizadas en el dispositivo electrónico. En la tabla 5.1 se
indican una serie de mediciones de prueba del ritmo cardíaco hechas a personas de ambos sexos
obtenidas del dispositivo electrónico, estas mediciones fueron comparadas contra un dispositivo
comercial (Reloj Polar) y mediciones manuales, esto con el fin de obtener un porcentaje de error
entre dichas mediciones. Las mediciones realizadas fueron hechas a 30 personas tanto del sexo
femenino y masculino ambos de edades entre los 18 y 50 años de edad las mujeres se encuentran
del lado izquierdo de la tabla (rosa) y los hombres del lado derecho (azul). Las mediciones fueron
hechas tanto en reposo como durante la actividad física.
177
No. Edad PPM PPM Error Error Medición Error Error Edad PPM PPM Error Error Medición Error Error
(Dispositivo (Dispositivo absoluto relativo manual absoluto relativo (Dispositi (Dispositi absoluto relativo manual absoluto relativo
electrónico) comercial) vo vo
electrónic comercial
o) )
En Reposo
1 18 76 79 3 3,8% 78 1 1,3% 22 69 72 3 4,2% 71 1 1,4%
2 20 69 71 2 2,8% 71 0 0,0% 23 67 69 2 2,9% 68 1 1,4%
3 22 70 72 2 2,8% 72 0 0,0% 18 68 71 3 4,2% 70 1 1,4%
4 19 75 77 2 2,6% 76 1 1,3% 41 65 67 2 3,0% 66 1 1,5%
5 25 71 73 2 2,7% 73 0 0,0% 35 67 68 1 1,5% 68 0 0,0%
6 24 77 80 3 3,8% 78 2 2,5% 33 64 67 3 4,5% 66 1 1,5%
7 18 74 77 3 3,9% 76 1 1,3% 28 63 65 2 3,1% 65 0 0,0%
8 22 72 75 3 4,0% 74 1 1,3% 50 60 61 1 1,6% 60 1 1,6%
9 22 68 70 2 2,9% 69 1 1,4% 48 61 63 2 3,2% 62 1 1,6%
10 22 66 69 3 4,3% 68 1 1,4% 44 62 63 1 1,6% 62 1 1,6%
11 26 69 72 3 4,2% 71 1 1,4% 40 64 66 2 3,0% 65 1 1,5%
12 28 64 65 1 1,5% 64 1 1,5% 19 75 73 -2 -2,7% 72 1 1,4%
13 45 59 60 1 1,7% 60 0 0,0% 25 72 73 1 1,4% 72 1 1,4%
14 43 61 62 1 1,6% 61 1 1,6% 24 77 78 1 1,3% 77 1 1,3%
15 33 65 67 2 3,0% 66 1 1,5% 22 80 82 2 2,4% 80 2 2,4%
16 19 73 74 1 1,4% 72 2 2,7% 23 71 73 2 2,7% 72 1 1,4%
17 29 68 69 1 1,4% 68 1 1,4% 23 72 73 1 1,4% 72 1 1,4%
18 35 62 64 2 3,1% 63 1 1,6% 22 70 71 1 1,4% 70 1 1,4%
19 39 61 61 0 0,0% 60 1 1,6% 33 65 66 1 1,5% 64 2 3,0%
20 47 59 60 1 1,7% 60 0 0,0% 30 64 65 1 1,5% 65 0 0,0%
21 50 58 60 2 3,3% 58 2 3,3% 29 67 68 1 1,5% 67 1 1,5%
22 50 60 61 1 1,6% 60 1 1,6% 41 61 62 1 1,6% 61 1 1,6%
23 21 77 78 1 1,3% 77 1 1,3% 22 72 73 1 1,4% 71 2 2,7%
24 37 66 68 2 2,9% 67 1 1,5% 21 75 76 1 1,3% 75 1 1,3%
25 28 65 67 2 3,0% 66 1 1,5% 20 70 71 1 1,4% 70 1 1,4%
26 48 78 79 1 1,3% 78 1 1,3% 20 74 75 1 1,3% 73 2 2,7%
178
27 23 70 73 3 4,1% 72 1 1,4% 21 71 72 1 1,4% 71 1 1,4%
28 29 67 70 3 4,3% 68 2 2,9% 19 78 79 1 1,3% 78 1 1,3%
29 37 67 69 2 2,9% 68 1 1,4% 39 61 62 1 1,6% 62 0 0,0%
30 34 61 63 2 3,2% 61 2 3,2% 37 64 64 0 0,0% 63 1 1,6%
Durante una actividad física
1 18 123 125 2 1,6% 124 1 0,8% 22 134 137 3 2,2% 136 1 0,7%
2 20 120 121 1 0,8% 121 0 0,0% 23 133 134 1 0,7% 133 1 0,7%
3 22 126 129 3 2,3% 127 2 1,6% 18 135 136 1 0,7% 135 1 0,7%
4 19 128 131 3 2,3% 129 2 1,5% 41 137 139 2 1,4% 139 0 0,0%
5 25 132 135 3 2,2% 134 1 0,7% 35 139 141 2 1,4% 140 1 0,7%
6 24 131 139 8 5,8% 138 1 0,7% 33 137 139 2 1,4% 138 1 0,7%
7 18 137 141 4 2,8% 141 0 0,0% 28 136 143 7 4,9% 142 1 0,7%
8 22 122 125 3 2,4% 124 1 0,8% 50 130 131 1 0,8% 131 0 0,0%
9 22 117 119 2 1,7% 119 0 0,0% 48 128 130 2 1,5% 129 1 0,8%
10 22 115 118 3 2,5% 116 2 1,7% 44 127 128 1 0,8% 128 0 0,0%
11 26 120 122 2 1,6% 120 2 1,6% 40 111 115 4 3,5% 114 1 0,9%
12 28 127 130 3 2,3% 129 1 0,8% 19 143 145 2 1,4% 144 1 0,7%
13 45 108 111 3 2,7% 110 1 0,9% 25 132 134 2 1,5% 133 1 0,7%
14 43 107 110 3 2,7% 108 2 1,8% 24 120 123 3 2,4% 122 1 0,8%
15 33 120 123 3 2,4% 121 2 1,6% 22 128 130 2 1,5% 128 2 1,5%
16 19 118 120 2 1,7% 118 2 1,7% 23 129 132 3 2,3% 130 2 1,5%
17 29 123 126 3 2,4% 123 3 2,4% 23 134 136 2 1,5% 135 1 0,7%
18 35 115 118 3 2,5% 115 3 2,5% 22 127 130 3 2,3% 130 0 0,0%
19 39 114 117 3 2,6% 115 2 1,7% 33 115 119 4 3,4% 116 3 2,5%
20 47 111 115 4 3,5% 114 1 0,9% 30 116 118 2 1,7% 116 2 1,7%
21 50 119 122 3 2,5% 121 1 0,8% 29 117 119 2 1,7% 118 1 0,8%
22 50 107 110 3 2,7% 109 1 0,9% 41 113 114 1 0,9% 113 1 0,9%
23 21 133 135 2 1,5% 133 2 1,5% 22 135 137 2 1,5% 135 2 1,5%
24 37 132 136 4 2,9% 134 2 1,5% 21 137 139 2 1,4% 138 1 0,7%
25 28 133 137 4 2,9% 135 2 1,5% 20 139 140 1 0,7% 139 1 0,7%
26 48 115 117 2 1,7% 116 1 0,9% 20 135 138 3 2,2% 137 1 0,7%
27 23 122 124 2 1,6% 123 1 0,8% 21 135 137 2 1,5% 135 2 1,5%
28 29 115 119 4 3,4% 118 1 0,8% 19 133 134 1 0,7% 133 1 0,7%
179
29 37 118 121 3 2,5% 119 2 1,7% 39 112 114 2 1,8% 111 3 2,6%
30 34 121 122 1 0,8% 120 2 1,6% 37 110 111 1 0,9% 109 2 1,8%
Tabla 5.1. Mediciones de prueba del ritmo cardíaco
Se puede concluir que las mediciones resultantes entre el dispositivo electrónico y el dispositivo comercial “Polar”, tienen un grado de error
considerablemente pequeño con un máximo de porcentaje de 4.3% en reposo y 2.5% durante una actividad física, al igual que las mediciones
entre el dispositivo electrónico y la medición manual convencional cuyo error máximo en reposo es de 3% y de 1.6% durante una actividad
física.
A continuación en la tabla 5.2, se indican una serie de mediciones de prueba de la temperatura corporal hechas a personas de ambos sexos
obtenidas del dispositivo electrónico, estas mediciones fueron comparadas contra un dispositivo comercial (termómetro digital Citizen), esto
con el fin de obtener un porcentaje de error entre dichas mediciones. Las mediciones realizadas fueron hechas a 30 personas tanto del sexo
femenino y masculino ambos de edades entre los 18 y 50 años de edad las mujeres se encuentran del lado izquierdo de la tabla (rosa) y los
hombres del lado derecho (azul). Las mediciones fueron hechas tanto en reposo como durante la actividad física.
No. De Edad Temperatura Temperatura Error Error Edad Temperatura Temperatura Error Error
medición
corporal corporal absoluto relativo corporal corporal absoluto relativo
(Dispositivo (Dispositivo (Dispositivo (Dispositivo
electrónico) comercial) electrónico) comercial)
En reposo
1 18 35 35,7 0,7 2,0% 22 35 36,0 1,0 2,8%
2 20 35,4 35,6 0,2 0,6% 23 35,4 35,7 0,3 0,8%
3 22 35,6 35,8 0,2 0,6% 18 34,5 34,7 0,2 0,6%
4 19 35,4 36 0,6 1,7% 41 34,5 35,1 0,6 1,7%
5 25 35,5 35,7 0,2 0,6% 35 35,7 35,9 0,2 0,6%
6 24 35,4 35,6 0,2 0,6% 33 35,4 35,6 0,2 0,6%
7 18 34,9 35,8 0,9 2,5% 28 34,9 35,8 0,9 2,5%
8 22 35,7 36 0,3 0,8% 50 35,7 36 0,3 0,8%
180
9 22 34,7 35 0,3 0,9% 48 34,7 35 0,3 0,9%
10 22 34,2 35,1 0,9 2,6% 44 35,1 35,1 0,0 0,0%
11 26 35,2 36,1 0,9 2,5% 40 35,9 36,1 0,2 0,6%
12 28 34,9 35,8 0,9 2,5% 19 35,6 35,8 0,2 0,6%
13 45 35,1 36 0,9 2,5% 25 35,8 36 0,2 0,6%
14 43 34,1 35 0,9 2,6% 24 34,8 35 0,2 0,6%
15 33 34,2 35,1 0,9 2,6% 22 34,9 35,1 0,2 0,6%
16 19 35,2 36,1 0,9 2,5% 23 35,4 36,1 0,7 1,9%
17 29 34,1 35 0,9 2,6% 23 34,5 35 0,5 1,4%
18 35 34,2 35,1 0,9 2,6% 22 34,4 34,9 0,5 1,4%
19 39 35,2 36,1 0,9 2,5% 33 35,2 35,4 0,2 0,6%
20 47 35,1 36 0,9 2,5% 30 34 34,5 0,5 1,4%
21 50 35,1 36 0,9 2,5% 29 36 36 0,0 0,0%
22 50 35,6 35,8 0,2 0,6% 41 35,8 36 0,2 0,6%
23 21 35,2 35,4 0,2 0,6% 22 35,6 35,8 0,2 0,6%
24 37 36,4 36,4 0,0 0,0% 21 35,4 35,4 0,0 0,0%
25 28 36,3 36,6 0,3 0,8% 20 36,1 36,4 0,3 0,8%
26 48 35,8 36 0,2 0,6% 20 36,4 36,6 0,2 0,5%
27 23 35,6 35,8 0,2 0,6% 21 35,8 36 0,2 0,6%
28 29 35,5 35,7 0,2 0,6% 19 35,6 35,8 0,2 0,6%
29 37 35 35,6 0,6 1,7% 39 35,1 35,7 0,6 1,7%
30 34 35,2 35,4 0,2 0,6% 37 35,4 35,6 0,2 0,6%
Durante una actividad física
1 18 35,7 36,6 0,9 2,5% 22 35,6 36,9 1,3 3,5%
2 20 36,1 36,5 0,4 1,1% 23 36,0 36,6 0,6 1,6%
3 22 36,3 36,7 0,4 1,1% 18 35,1 35,6 0,5 1,4%
4 19 36,1 36,9 0,8 2,2% 41 35,1 36,0 0,9 2,5%
5 25 36,2 36,6 0,4 1,1% 35 36,3 36,8 0,5 1,4%
6 24 36,0 36,5 0,5 1,4% 33 36,0 36,5 0,5 1,4%
7 18 35,5 36,7 1,2 3,3% 28 35,5 36,7 1,2 3,3%
8 22 36,3 36,9 0,6 1,6% 50 36,3 36,9 0,6 1,6%
9 22 35,3 35,9 0,6 1,7% 48 35,3 35,9 0,6 1,7%
10 22 34,8 36,0 1,2 3,3% 44 35,7 36,0 0,3 0,8%
181
11 26 35,8 37,0 1,2 3,2% 40 36,5 37,0 0,5 1,4%
12 28 35,5 36,7 1,2 3,3% 19 36,2 36,7 0,5 1,4%
13 45 35,7 36,9 1,2 3,3% 25 36,4 36,9 0,5 1,4%
14 43 34,7 35,9 1,2 3,3% 24 35,4 35,9 0,5 1,4%
15 33 34,8 36,0 1,2 3,3% 22 35,5 36,0 0,5 1,4%
16 19 35,8 37,0 1,2 3,2% 23 36,0 37,0 1,0 2,7%
17 29 34,7 35,9 1,2 3,3% 23 35,1 35,9 0,8 2,2%
18 35 34,8 36,0 1,2 3,3% 22 35,0 35,8 0,8 2,2%
19 39 35,8 37,0 1,2 3,2% 33 35,8 36,3 0,5 1,4%
20 47 35,7 36,9 1,2 3,3% 30 34,6 35,4 0,8 2,3%
21 50 35,7 36,9 1,2 3,3% 29 36,6 36,9 0,3 0,8%
22 50 36,3 36,7 0,4 1,1% 41 36,4 36,9 0,5 1,4%
23 21 35,9 36,3 0,4 1,1% 22 36,2 36,7 0,5 1,4%
24 37 37,1 37,3 0,2 0,5% 21 36,0 36,3 0,3 0,8%
25 28 37,0 37,5 0,5 1,3% 20 36,7 37,3 0,6 1,6%
26 48 36,5 36,9 0,4 1,1% 20 37,0 37,5 0,5 1,3%
27 23 36,3 36,7 0,4 1,1% 21 36,4 36,9 0,5 1,4%
28 29 36,2 36,6 0,4 1,1% 19 36,2 36,7 0,5 1,4%
29 37 35,7 36,5 0,8 2,2% 39 35,7 36,6 0,9 2,5%
30 34 35,9 36,3 0,4 1,1% 37 36,0 36,5 0,5 1,4%
Tabla 5.2. Mediciones de prueba de la temperatura corporal
Se puede concluir que las mediciones resultantes entre el dispositivo electrónico y el dispositivo comercial “Citizen”, tienen un grado de
error considerablemente pequeño con un máximo de porcentaje de 0.81% en reposo y 0.79% durante una actividad física.
182
5.2. Pruebas finales y de integración
A continuación se indica el funcionamiento general de todo el prototipo realizando las pruebas

finales y de integración.
Como se vió en las pruebas modulares, se creo un nuevo participante: José Luis Velázquez
Rodríguez y se asocio a la carrera ESCOM, una vez teniendo esto se procederá a los siguientes
pasos:
1. El organizador colocará el dispositivo electrónico en un lugar adecuado para su medición,
para la medición del pulso cardíaco el sensor se encontrará en el dedo pulgar y el sensor
de temperatura en el brazo del participante.
2. El organizador encenderá el dispositivo electrónico, este se mantendrá encendido durante
toda la carrera o una vez que el participante abandone la competición. La duración total
de las baterías será aproximadamente de 157 horas de uso continuo. Se encenderá un led
de color verde en la tarjeta el cual indicará que no hubo problema con algún componente.
Se encenderá el led del sensor de pulso cardíaco. Y finalmente el módulo bluetooth
encenderá un led (que estará parpadeando hasta que se conecte a la aplicación móvil), ver
figura 5.18.
Figura 5.18. Dispositivo electrónico y componentes

3. El participante iniciará sesión en la aplicación móvil y conectará la aplicación con el
dispositivo electrónico. Al presionar el boton de conectar con pulsera, ver figura 5.19, la
aplicación móvil solicitará permiso de encender el bluetooth, ver figura 5.20, después
183
escanearemos los dispositivos cercanos a la aplicación móvil, ver figura 5.21, hay que
recordar que entre el dispositivo electrónico (pulsera) y el móvil no puede haber una
distancia mayor a 10 metros; una vez encontrado el dispositivo electrónico (de nombre
“Pulse”) presionaremos el botón conectar, ver figura 5.22, se hará una solicitud de
conexión y el ingreso de una contraseña para poderse conectar, ver figura 5.23, una vez
conectado se mostrará la leyenda “Dispositivo conectado” y se habilitará el botón de
“Iniciar Monitoreo”, ver figura 5.24, al presionar el botón de iniciar monitoreo se podrá
visualizar: el ritmo cardíaco, temperatura, se podrá enviar una alerta a la aplicación web
de manera manual, consultar el historial de monitoreo y terminar monitoreo, ver figura
5.25.
184
Figura 5.19. Conectar con pulsera.
185
Figura 5.20. Permiso de encender bluetooth
186
Figura 5.21. Escaneando dispositivos cercanos
187
Figura 5.22. Conectando con el dispositivo electrónico
188
Figura 5.23. Solicitud de conexión
189
Figura 5.24. Dispositivo conectado y boton habilitado (Iniciar monitoreo)
190
Figura 5.25. Monitoreo del ritmo cardíaco y temperatura
191
4. Ahora se ingresará a la aplicación web con la cuenta de “organizador” y en la pestaña
“Gestionar carreras”, accederemos mediante el botón “Monitorear” a la Carrera ESCOM
(ver figura 5.26).
Figura 5.26. Gestionar carreras

5. Una vez hecho lo anterior podremos observar al participante enviando datos de manera
continua a la aplicación web, los datos visualizados dependerán de la velocidad de la red a
la que se este conectado. Los datos se irán actualizando constantemente aproximadamente
cada 6 segundos (tiempo de procesamiento y envío de los signos vitales, ver figura 5.27).
Adicionalmente cabe mencionar que el tiempo inicial en el que el sensor de temperatura
obtiene la temperatura final es de aproximadamente de 1 minuto a 1.5 minutos.
Figura 5.27. Monitoreo del participante.
192
6. El participante mediante la aplicación móvil podrá envíar una alerta manual, esta podrá
ser visualizada en la aplicación web (ver figura 5.11).
Figura 5.28. Alerta emitida por el participante

7. El organizador podrá generar la ubicación aproximada del participante en caso de ser
necesario. Esta función está sujeta a que el móvil del participante tenga activados los
servicios de localización. Ver figura 5.29.
Figura 5.29. Ubicación aproximada por el participante

8. La aplicación maneja 3 tipos de alertas: Alerta emitida por el participante (Ver figura
5.28), Alerta amarilla (en caso de que los valores se acerquen a valores de peligro, ver
figura 5.30) y alerta roja (el participante ya alcanzo niveles muy peligrosos en sus signos
vitales, ver figura 5.31). Para efectos demostrativos se verán las últimas dos alertas para la
variable “temperatura”.
193
Figura 5.30. Alerta amarilla
Figura 5.31. Alerta roja

9. Una vez terminada la carrera o la participación de la persona en la carrera, en la aplicación
móvil se presionará el botón “Terminar monitoreo”, ver figura 5.32.
194
Figura 5.32. Terminar monitoreo.
10. Una vez hecho el punto anterior, el organizador podrá visualizar que el participante
termino el monitoreo cuando este se encuentra resaltado en color azul, ver figura 5.33.
Figura 5.33. Finalizando el monitoreo
195
11. Al terminar el monitoreo tanto el participante como el organizador podrán visualizar el
historial de signos vitales y de alertas del participante, ver figuras 5.34 a 5.39.
Figura 5.34. Ver historial del participante
Figura 5.35. Seleccionar carrera para el despliegue de historial
196
Figura 5.36. Historial del participante
Figura 5.37. Consultando historial en la aplicación móvil
197
Figura 5.38. Seleccionando carrera
198
Figura 5.39. Historial en la aplicación móvil
Para efector de prueba, se desarrolló una pequeña sección para agregar a varios participantes
prueba, esto con el fin de simular que varios participantes se están conectando de manera
simulánea.
En la figura 5.40 se indica la sección en la que se podrá ingresar ‘n’ cantidad de participantes
prueba.
199
Figura 5.40. Ingresar participantes de prueba
Una vez ingresado a esta sección, se podrán indicar el número de participantes a agregar y la
carrera a la que se asignarán (ver figura 5.41).
Figura 5.41. Ingresando participantes de prueba

Una vez ingresados dichos participantes se indicará la pantalla mostrada en la figura 4.42, para
iniciar el monitoreo de prueba se presionará el botón de “Iniciar prueba de monitoreo”, una vez
hecho lo anterior se mostrará lo indicado en la figura 4.43.
200
Figura 5.42. Iniciar prueba de monitoreo
Figura 5.43. Monitoreando

A continuación se ingresará a la sección de gestionar carreras y se monitoreará la carrera a la que
fueron asignados los participantes prueba (ver figura 5.44), los valores ahí indicados son
aleatoríos con fines de prueba.
Figura 5.44. Monitoreo prueba
201
En la parte superior izquierda de la figura 5.44 se muestra el botón “Solo alertas” el cual nos
mostrará solo a los participantes que están emitiendo algún tipo de alerta (ver figura 5.45).
Figura 5.45. Pariticpantes que emitieron alguna alerta

Para volver a visualizar a todos los participantes se podrá presionar el botón “Monitoreo general”
ubicado en la esquina superior izquierda.
Para finalizar esta etapa, se podrá terminar el monitoreo de los participantes prueba (ver figura
5.46).
Figura 5.46. Terminar monitoreo prueba

Las siguientes pruebas mostradas en la tabla 5.3 se hicieron con base en la siguiente información:
 Cada que un usuario hace la conexión al servidor este genera un nuevo hilo que viene
acompañado de 2 MB de memoria. Las pruebas se hicieron sobre un sistema que tiene 8
202
GB de RAM, esto da un número máximo teórico de conexiones concurrentes de cerca de
4.000 usuarios.
 En cada carrera deportiva, existe un promedio de aproximadamente 3,000 participantes.
Para carreras con mayor número de participantes se deberán considerar las características
físicas de la computadora (s) que monitorearán la carrera.
 Es importante mencionar que esto depende de la velocidad de la red a la que se
encuentren conectados los participantes en una carrera real.
No. de Usuarios prueba Tiempo para el Conclusión. El total
prueba conectados de manera despliegue de datos de usuarios
concurrente. (segundos) conectados es:
1 500 6 Ideal
2 1000 6 Ideal
3 1500 6 Ideal
4 2000 6 Ideal
5 2500 6 Ideal
6 3000 6 Ideal
7 3500 6 Ideal
8 4000 10 No recomendable
9 4500 12 No recomendable
10 5000 - No soportado
Figura 5.3. Pruebas usuarios concurrentes
Para finalizar todo, el organizador apagará el dispositivo electrónico y será retirado del
participante.
Con el punto anterior se finaliza la explicación del funcionamiento general del prototipo, para
más información consulte los manuales o el video adjunto de funcionamiento.
203
CAPÍTULO 6. CONCLUSIONES Y TRABAJO A FUTURO
En este capítulo se indicarán las conclusiones a las que se llegó al finalizar este trabajo y lo que
se propone como trabajo a futuro.
CONCLUSIONES
Al finalizar el desarrollo de este prototipo, se llegaron a las siguientes conclusiones:
 Se cumplieron los objetivos tanto el general como específicos al término del desarrollo de
este prototipo.
 Es de gran importancia tener una idea clara además de una investigación previa de los
temas a tratar para que las etapas de análisis y diseño del sistema a realizar sean más
sencillas de llevar a cabo.
 Fue complicada la elección de componentes, ya que el objetivo del presente trabajo es que
fuera lo más eficiente y del menor tamaño posible.
 Para la fase de implementación primero se realizó de manera modular y una vez ya

funcionando cada uno de estos módulos solo se concluyó con la fase de integración y la
comunicación eficiente entre ellos. Para el dispositivo electrónico primero se probó el
diseño en Protoboard y finalmente se realizó la placa cuidando mucho el aspecto de la
alimentación con el fin de no dañar los componentes.
 Para la parte del servidor es necesario tomar en cuenta las características físicas de la
computadora con la que se monitoreará a los participantes (por ejemplo: la memoria
RAM), esto para que soporte la mayor cantidad de usuarios conectados de manera
concurrente.
 Para la fuente de alimentación se propusieron pilas AAA ya que son las más pequeñas y
que nos ofrecen más horas de uso continuo de energía, pero este aspecto está sujeto a
cambios. La alimentación general del PCB es de 3.3 Volts, esta alimentación se mantiene
con la ayuda de un regulador, así que se puede cambiar a cualquier tipo de pilas o fuente
siempre y cuando el voltaje sea igual o mayor a 3.3 Volts.
204
 Los datos serán actualizados para su despliegue en las aplicaciones aproximadamente
cada 6 segundos, la tasa de transferencia fue de 19,200 baudios, es decir, 1,920 bits por
segundo. El tiempo puede variar dependiendo de la velocidad de la red de datos a la que
se encuentran conectados la aplicación móvil y la aplicación web, además de la cantidad
de usuarios conectados de manera concurrente.
 El sensor de pulso cardíaco puede tener problemas de ruido en la señal, esto puede
suceder si el dispositivo se encuentra mal colocado en el participante o los pines se
mueven de su base, como solución se propuso dejar el sensor lo más fijo posible en el
PCB.
 Por otro lado, el sensor de temperatura no tuvo mayores problemas, solamente en la parte
de la configuración del SPI del microcontrolador, pero en cuanto al resultado arrojado fue
el que menor grado de error tuvo con respecto al otro sensor.
 Con base en la figura 6.1 podemos observar las versiones que soporta correctamente la
aplicación móvil, siendo la mínima versión de Android la 2.2 “Froyo” y hasta la versión
actual. La aplicación móvil no puede soportar una versión anterior por el uso del
bluetooth, Wifi o servicio de datos.
Figura 6.1. Versiones soportadas por la aplicación móvil
205
TRABAJO A FUTURO
Al termino de este prototipo se propone los siguientes trabajos a futuro:

 Cambiar aspectos de diseño de la placa como son: tamaño de componentes y tamaño, tipo
o marca de la fuente de alimentación.
 Agregar más variables al monitoreo de signos vitales como son: presión arterial al
finalizar la carrera, respiraciones por minuto, niveles de oxigenación en sangre.
 Almacenar mediante inteligencia artificial los signos vitales del participante en una
matriz, guardando los valores que se consideran normales para cada uno de ellos, es decir,
no usar valores genéricos, lo anterior con el fin de tener un mejor control de la salud de
los participantes con base en sus propios valores de ritmo cardíaco y temperatura.
 Este monitoreo no solamente puede ser dedicado a carreras deportivas sino también puede
aplicarse a: personas de la tercera edad, personas con capacidades diferentes, bebés recién
nacidos, en pacientes de hospitales etc.
 Este sistema también se podrá adaptar con el fin de que no sea necesario tener un
dispositivo móvil para su uso, es decir, se propone que del dispositivo electrónico se
pueda enviar de manera remota la información directamente al servidor y a la aplicación
web para su consulta, esto sería de utilidad para personas que no cuenten o no sepan
manejar un dispositivo móvil.
206
Referencias
[1] Deporte es Salud, «El deporte y sus beneficios en la salud física, mental y psicológica,» 2014. [En
línea]. Available: http://www.deportesalud.com/deporte-salud-el-deporte-y-sus-beneficios-en-la-
salud-fisica-y-mental-y-psicologica-.html. [Último acceso: Marzo 2015].
[2] Corredores del bosque de Tlalpan, «Calendario de Carreras México,» México, D.F., 2014.
[3] Instituto Politécnico Nacional, «Carrera IPN 11K,» México, D.F. , 2014.
[4] La jornada UNAM, «Muere competidor a causa de un infarto,» México D.F. , 2013.
[5] CNN México Noticias, «Muere un corredor del Maratón de la Ciudad de México por paro
respiratorio,» México D.F. , 2013.
[6] Instituto Balseiro, «Sistemas embebidos,» Bariloche, Río Negro, Argentina, 2000. [En línea].
Available: http://www.ib.cnea.gov.ar/~sisemb/apuntes/Modulo1.1.pdf. [Último acceso: Marzo
2015].
[7] Startcapps, «¿Qué es una App?,» Madrid, España , 2010. [En línea]. Available:
http://www.startcapps.com/blog/que-es-una-app/#sthash.9oVChYF8.dpu. [Último acceso: Marzo
2015].
[8] GPS, «Sistema de Posicionamiento Global al Servicio del Mundo,» [En línea]. Available:
http://www.gps.gov/spanish.php. [Último acceso: Marzo 2015].
[9] Google, «Google Maps,» España, 2005. [En línea]. Available:
http://www.googlemaps.es/?page_id=3. [Último acceso: Marzo 2015].
[10] G. Coulouris, Sistemas Distribuido, Tercera ed., Madrid.: Addison Wesley, 2001.
[11] Apache Software Fundation, «Capítulo 5 “Modelo Cliente-Servidor”,» 2014. [En línea].
Available: http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/marquez_a_bm/capitulo5.pdf.
[Último acceso: Marzo 2015].
[12] La información obtenida en esta sección es una recopilación de varias fuentes como son:
R. Pallas, Sensores y acondicionadores de señal, España: Marcombo. ISBN 8426713440., 2005.
Creus, S. A. (1998). Instrumentación industrial. España: Alfaomega. España. ISBN 8426713610.
Pérez, M. A. (2004). Instrumentación electrónica. España: Thompson. ISBN 8497321669.
[13] DICIS - UG, «Procesamiento digital de señales. Teorema de muestreo,» 2013. [En línea].
Available: http://www.ingenierias.ugto.mx/profesores/ljavier/documentos/Lec01%20-
%20Teorema%20de%20Muestreo.pdf. [Último acceso: Mayo 2015].
[14] J. L. H. David A. Patterson, Computer organization and design., Cuarta ed., ISBN-
10:0123744938: The Morgan Kaufmann Series in Computer Architecture and Design, 2008.
[15] M. en C. Rubén Hernández Tovar, M. en C. Víctor Hugo García Ortega., «Sistema de
Monitoreo de Pulso Cardíaco y Temperatura Corporal para Entrenamiento Deportivo,» TT 914,
2005.
[16] Instituto de Ciencias Nucleares (ICN) de la Universidad Nacional Autónoma de México
(UNAM), «Proyecto de investigación: Vigilancia y Análisis Continuo de Signos Vitales
(VACS),» México D.F. , 2013.
[17] Facultad de Ingeniería, Escuela de Ingeniería Electrónica, Universidad Central, «Proyecto de
investigación: Sistema Telemétrico De Monitoreo Cardiaco Y Variables Hombre-Máquina
Aplicado Al Ciclismo,» Bogotá, Colombia, 2005.
207
[18] Laboratorio de Innovación y Desarrollo Móvil de la Facultad de Ingeniería (FI) de la
Universidad Nacional Autónoma de México (UNAM), «Podium. Chamarra inteligente para
corredores,» México, D.F., 2014.
[19] Samsung, «Simband. Salud Digital de Samsung,» Corea del Sur, Seúl, 2014.
[20] Adidas, adidas miCoach, «Smart Run. Un reloj al ritmo de los atletas,» Herzogenaurach,
Alemania, 2014.
[21] Ikerlan S. Coop, , «Una metodología para el desarrollo de hardware y software embebidos en
sistemas críticos de seguridad,» 2006. [En línea]. Available:
www.iiisci.org/journal/CV$/risci/pdfs/C863GM.pdf. [Último acceso: Octubre 2014].
[22] University of Rochester Medical Center, «Enciclopedia Médica-Signos Vitales,» Estados
Unidos de America, Rochester, 2013. [En línea]. Available:
http://www.urmc.rochester.edu/Encyclopedia/Content.aspx?ContentTypeID=85&ContentID=P03
963. [Último acceso: Marzo 2015].
[23] V. RG, «Systemic hypertension: Mechanisms and diagnosis,» de Heart Disease: A Textbook
of Cardiovascular Medicine, Braunwald's , 2008.
[24] J. W. K. G. E. K. Blais, «Medición de signos vitales,» de Fundamentos de enfermería Vol. 1 y

Vol. 2.5, Quinta ed., Mcgran Hill.
[25] Gatorade. Sports Science Institute. Volumen 14, «Colapso en el atleta de fondo,» 2004. [En
línea]. Available: http://www.gssiweb.org/es-mx/Article/sse-95-el-colapso-en-el-atleta-de-fondo.
[Último acceso: Marzo 2015].
[26] H. Information, «Temperatura Corporal,» Wisconsin, 2014. [En línea]. Available:
http://www.uwhealth.org/spanishhealth/topic/medicaltest/temperatura-corporal/hw198785.html.
[Último acceso: Abril 2015].
[27] Fundación de alto rendimiento, ciencia deportiva, entrenamiento y fitness, «Frecuencia
cardiaca máxima (FCM) según deporte.,» España, 2012. [En línea]. Available:
altorendimiento.com/frecuencia-cardiaca-maxima-fcm-segun-deporte-fcm-y-los-tests-del-
esfuerzo-maximo/. [Último acceso: Abril 2015].
[28] J. H. y. C. D. L. WILMORE, de Fisiología del esfuerzo y del deporte, Quinta ed., Madrid:
Paidotribo, 2004, pp. 309-33.
[29] PulseSensor, «Hoja de datos PulseSensor,» 2013. [En línea]. Available:

http://pulsesensor.com/pages/pulse-sensor-amped-arduino-v1dot1. [Último acceso: Abril 2015].
[30] UFI, «Hoja de datos de MODEL 1020 INFRARED PULSE PLETHYSMOGRAPH,» 2013.
[En línea]. Available: http://www.ufiservingscience.com/datasheets/1020manual.pdf. [Último
acceso: Abril 2015].
[31] Polar, «Hoja de datos de RMCM01,» 2013. [En línea]. Available:
https://www.sparkfun.com/datasheets/Wireless/General/RMCM01.pdf. [Último acceso: Abril
2015].
[32] SUNROM TECHNOLOGIES, «Hoja de datos de Heartbeat Pulse Sensor - Analog Out,»
2014. [En línea]. Available: http://www.sunrom.com/media/files/p/258/1260-datasheet.pdf.
208
[33] Melexis Technologies NV, «Hoja de datos de MLX90614ESF-AAA-000-TU-ND,» [En

línea]. Available: http://www.adafruit.com/datasheets/MLX90614.pdf. [Último acceso: Abril
2015].
[34] Anatomía humana, «Conceptos Básicos del Sistema Cardiovascular,» 2001. [En línea].
Available: http://www.anatomiahumana.ucv.cl/efi/modulo24.html. [Último acceso: Mayo 2015].
[35] Universidad de país Vasco, «Filtrado,» 2010. [En línea]. Available:
http://www.ehu.eus/daq_tutorial/Doc/Castellano/Tema%205.htm. [Último acceso: Mayo 2015].
[36] MAXIM, «MAX295,» 2012. [En línea]. Available:
http://datasheet.eeworld.com.cn/pdf/MAXIM/302257_MAX291.pdf. [Último acceso: Mayo
2015].
http://datasheets.maximintegrated.com/en/ds/MAX7408-MAX7415.pdf. [Último acceso: Mayo
2015].
[38] TEXAS INSTRUMENTS, «LMF100,» 2010. [En línea]. Available:
http://www.ti.com/lit/ds/symlink/lmf100.pdf. [Último acceso: Mayo 2015].
http://pdf.datasheetcatalog.com/datasheet/maxim/MAX7418-MAX7425.pdf. [Último acceso:
Mayo 2015].
http://datasheets.maximintegrated.com/en/ds/MAX7400-MAX7407.pdf. [Último acceso: Mayo
2015].
[41] ATMEL, «Hoja de datos de AT30TSE752A,» 2013. [En línea]. Available:
http://www.atmel.com/images/atmel-8854-dts-at30tse752a-754a-758a-datasheet.pdf. [Último
[42] MAXIM, «Hoja de datos de DS18B20,» 2013. [En línea]. Available:
http://datasheets.maximintegrated.com/en/ds/DS18B20.pdf. [Último acceso: Abril 2015].
[43] Microchip, «Hoja de datos de MCP9801,» 2014. [En línea]. Available:
http://ww1.microchip.com/downloads/en/DeviceDoc/21909d.pdf. [Último acceso: Abril 2015].
[44] Microchip, «Hoja de datos de EMC1414,» 2013. [En línea]. Available:
http://ww1.microchip.com/downloads/en/DeviceDoc/20005274A.pdf. [Último acceso: Abril
2015].
[45] Microship. , «Hoja de datos de TC77,» 2014. [En línea]. Available:
http://ww1.microchip.com/downloads/en/devicedoc/20092a.pdf. [Último acceso: Abril 2015].
[46] ROVING NETWORK, «Hoja de datos de RN-41,» 2014. [En línea]. Available:
http://ww1.microchip.com/downloads/en/DeviceDoc/31037b.pdf. [Último acceso: Abril 2015].
[47] RCScomponents , «Hoja de datos de HC-06,» 2014. [En línea]. Available: http://abc-
rc.pl/templates/images/files/995/1425483439-hc-06-datasheet.pdf. [Último acceso: Abril 2015].
[48] ISSSC Techonologies Corp, «Hoja de datos de BM77,» 2014. [En línea]. Available:
http://ww1.microchip.com/downloads/en/DeviceDoc/30009937c.pdf. [Último acceso: Abril
2015].
209
[49] Life augmented, «Hoja de datos de SPBT2632C1A,» 2014. [En línea]. Available:
http://www.atmel.com/Images/Atmel-8265-8-bit-AVR-Microcontroller-tinyAVR-ATtiny87-
ATtiny167_datasheet.pdf. [Último acceso: Abril 2015].
[50] U-blox, «Hoja de datos de OBS421,» 2014. [En línea]. Available:
http://www.ti.com/lit/ds/symlink/msp430f110.pdf. [Último acceso: Abril 2015].
[51] Microchip, «Hoja de datos de PIC24F08KL201,» 2014. [En línea]. Available:

http://pdf1.alldatasheet.es/datasheet-pdf/view/447918/MICROCHIP/PIC24F08KL201.html.
http://ww1.microchip.com/downloads/en/DeviceDoc/30001037c.pdf. [Último acceso: Abril
2015].
http://ww1.microchip.com/downloads/en/DeviceDoc/30001037c.pdf. [Último acceso: Mayo
2015].
[54] Atmel, «Hoja de datos de ATtiny87,» 2014. [En línea]. Available:
http://www.atmel.com/Images/Atmel-8265-8-bit-AVR-Microcontroller-tinyAVR-ATtiny87-
ATtiny167_datasheet.pdf. [Último acceso: Abril 2015].
[55] Texas Instruments, «Hoja de datos de MSP430F110,» 2014. [En línea]. Available:
http://www.xinpian.net/ti/MSP430/MSP430F110.pdf. [Último acceso: Abril 2015].
[56] Maxim Integrated, «Hoja de datos de MAX6349TLUT-T,» 2014. [En línea]. Available:
http://datasheets.maximintegrated.com/en/ds/MAX6329-MAX6349.pdf. [Último acceso: Abril
2015].
[57] Analog Devices, «Hoja de datos de ADP7142,» 2014. [En línea]. Available:
http://www.analog.com/media/en/technical-documentation/data-sheets/ADP7142.pdf. [Último
[58] Analog Devices, «Hoja de datos de ADM7171,» 2014. [En línea]. Available:
http://www.analog.com/media/en/technical-documentation/data-sheets/ADM7172.pdf. [Último
[59] Texas Instruments, «Hoja de datos de LP2980-N,» 2013. [En línea]. Available:
http://www.ti.com/lit/ds/symlink/lp2980-n.pdf. [Último acceso: Abril 2015].
[60] Texas Instruments, «Hoja de datos de LM2936,» 2013. [En línea]. Available:
http://www.ti.com/lit/ds/symlink/lm2936.pdf. [Último acceso: Abril 2015].
[61] Robotica Sunyer, «La batería,» 2014. [En línea]. Available:
http://roboticasunyer.blogspot.mx/2013/02/partes-de-un-robot-la-bateria.html. [Último acceso:
Abril 2015].
[62] Apple, «Apple IOS,» 2015. [En línea]. Available: http: //www.apple.com/mx/ios. [Último
[63] Android, «Sistema Operativo Android,» 2015. [En línea]. Available: http://www.android.com.
[64] Microsoft, «Windows Phone,» 2015. [En línea]. Available:
http://www.windowsphone.com/es-MX. [Último acceso: Abril 2014].
210
[65] BLACKBERRY, «Sistema operativo Blackberry,» 2015. [En línea]. Available:
http://mx.blackberry.com/. [Último acceso: Abril 2015].
[66] CNN, «“Android dominó el mercado de los 'smartphones'”,» 2014. [En línea]. Available:
http://mexico.cnn.com/tecnologia/2013/02/15/android-domino-el-mercado-de-los-smartphones-
en-2012. [Último acceso: Abril 2015].
[67] Notimex, «”México, segundo lugar en ventas de smartphones de América Latina”,» 2014. [En
línea]. Available: http://www.sdpnoticias.com/tecnologia/2011/10/07/mexico-segundo-lugar-en-
ventas-de-smartphones-de-america-latina. [Último acceso: Abril 2015].
[68] Universidad Autónoma De Baja California Sur, «Análisis Y Diseño Del Módulo De Catálogos
Del Sistema Integral De Planeación,» 2013. [En línea]. Available:
http://biblio.uabcs.mx/tesis/te3087.pdf. [Último acceso: Abril 2015].
[69] LibrosWeb, «Capítulo 2. HTML,» 2014. [En línea]. Available:
http://librosweb.es/libro/xhtml/capitulo_2.html. [Último acceso: Abril 2015].
[70] Prosolutions, «Ventajas y desventajas de CSS,» 2014. [En línea]. Available:

http://www.prosolutions.es/blog/ventajas-y-desventajas-de-css/. [Último acceso: Abril 2015].
[71] Mozilla Firefox , «Acerca de Javascript,» 2014. [En línea]. Available:
https://developer.mozilla.org/es/docs/Web/JavaScript/Acerca_de_JavaScript. [Último acceso:
Abril 2015].
[72] PHP, «PHP and Supported versions,» 2015. [En línea]. Available: http://php.net/supported-
versions.php. [Último acceso: Abril 2015].
[73] Python, «About Python,» 2015. [En línea]. Available: https://www.python.org/about/. [Último
[74] Ruby, «Acerca de Ruby,» 2015. [En línea]. Available: https://www.ruby-lang.org/es/. [Último
[75] Desarrollo Web, «JSP’s,» 2013. [En línea]. Available:
http://www.desarrolloweb.com/articulos/831.php. [Último acceso: Abril 2015].
[76] Microsoft, «ASP.NET» 2013. [En línea]. Available: http://www.asp.net/ [Último acceso:
Abril 2015].
[77] CodeJobs, «Los mejores frameworks de javascript,» Abril 2013. [En línea]. Available:
http://www.codejobs.biz/es/blog/2013/04/11/los-5-mejores-frameworks-mvc-de-
javascript#sthash.QWLYHJdc.dpbs. [Último acceso: Mayo 2015].
[78] ¿Qué es Backbone.js?, «Desarrollo Web,» 2013. [En línea]. Available:
http://www.desarrolloweb.com/articulos/que-es-backbonejs.html. [Último acceso: Mayo 2015].
[79] PixeLovers, «Ventajas de node.js,» 2012. [En línea]. Available:

http://www.pixelovers.com/ventajas-utilizar-nodejs-1953900/. [Último acceso: Mayo 2015].
[80] Ember.js, «Ember.js,» 2015. [En línea]. Available: www.emberjs.com. [Último acceso: Mayo
2015].
[81] Knockoutjs, «About Knockoutjs,» 2014. [En línea]. Available: knockoutjs.com. [Último
acceso: Mayo 2015].
[82] Angularjs, «About Angularjs,» 2014. [En línea]. Available: https://angularjs.org. [Último
acceso: Mayo 2015].
211
[83] PostgreSQL, «Sobre PostgreSQL,» 2014. [En línea]. Available: http://www.postgresql.org.es/.
[84] Microsoft, «SQL Server,» 2013. [En línea]. Available: http://www.microsoft.com/es-
es/server-cloud/products/sql-server/. [Último acceso: Abril 2015].
[85] IBM, «Informix,» 2015. [En línea]. Available: http://www-
01.ibm.com/software/data/informix/. [Último acceso: Abril 2015].
[86] Oracle, «MySql,» 2015. [En línea]. Available: https://www.mysql.com/. [Último acceso: Abril
2015].
[87] Sqlite, «Sqlite about,» 2013. [En línea]. Available: http://www.sqlite.org/. [Último acceso:
Abril 2015].
[88] IBM, «DB2,» 2013. [En línea]. Available: http://www-01.ibm.com/software/data/db2/.
[89] Oracle, «Oracle Database,» 2014. [En línea]. Available:
https://www.oracle.com/database/index.html. [Último acceso: Abril 2015].
[90] Proakis, John G.; Manolakis, Dimitris G. Tratamiento Digital de Señales. Principios,
algoritmos y aplicaciones. 3ª Edición. Pearson Prentice Hall 2006.
212
Glosario
A continuación se indican los principales términos poco conocidos.

 Alerta: Situación de vigilancia o atención.
 Analógico: Dicho de un aparato o de un instrumento de medida: Que la representa
mediante variables continuas, análogas a las magnitudes correspondientes.
 Android: Sistema operativo para dispositivos móviles.
 Asíncrono: Se refiere al acceso a información entre usuarios/as de la red de manera no
simultánea, puede ser por texto, sonido, o videoconferencia, la cual incluye imagen y
sonido.
 Atletismo: Conjunto de actividades y normas deportivas que comprenden las pruebas de
velocidad, saltos y lanzamiento.
 Automatización: Área de la ingeniería que estudia sistemas o elementos computarizados y
electromecánicos para controlar maquinarias y/o procesos industriales de manera
autónoma.
 Bluetooth: Es una especificación industrial para redes inalámbricas que posibilita la
transmisión de voz y datos entre diferentes dispositivos.
 CRUD: De la siglas en inglés (Create, Read, Update, Delete) que significa en español
(Crear, Leer, Modificar y Eliminar).
 Control: Área de la ingeniería que estudia sistemas que pueden regular su propia conducta
o la de otro sistema con el fin de lograr un funcionamiento predeterminado, de modo que
se reduzcan las probabilidades de fallos y se obtengan los resultados buscados.
 Corriente: Es el flujo de carga (movimiento de electrones) por unidad de tiempo que
recorre un material. Su unidad de medida es el Ampere (A).
 Cristal oscilador:
 Digitalizar: es convertir cualquier señal de entrada analógica en una serie de valores
numéricos.
 Diodo: Un diodo es un componente electrónico de dos terminales que permite la
circulación de la corriente eléctrica a través de él en un solo sentido.
 Dispositivo móvil: También conocido como computadora de bolsillo.
 Electrónica: La electrónica es la rama de la física y especialización de la ingeniería, que
estudia y emplea sistemas cuyo funcionamiento se basa en la conducción y el control del
flujo de los electrones u otras partículas cargadas eléctricamente.
 Error: Juicio, valoración o resultado que contraviene el criterio que se reconoce como
válido.
 Exactitud: Aproximación con la cual la lectura de un instrumento se acerca al valor real de
la variable medida.
 Framework: Marco de trabajo.
 Frecuencia de corte: es un límite en la respuesta de frecuencia en el que la energía que
fluye a través de un sistema comienza a reducirse en lugar de pasar a través.
213
 Fuente de alimentación: es convertir la tensión alterna en una tensión continua y lo más
estable posible.
 Hardware: Partes físicas de un sistema.
 Instrumentación: Área de la ingeniería que trata de la medición para el control de
procesos, con base en instrumentos de medición.
 Instrumento de medición: Es aquel conjunto de elementos que forman un instrumento,
capaz de convertir una variable física en una señal o indicación a ser interpretada por
sistema externo (usuario) con mayor facilidad.
 Linealidad: Por lo general los instrumentos se diseñan de forma que tengan una respuesta
lo más lineal posible, es decir, que para un determinado incremento del parámetro que
estamos midiendo, el desplazamiento correspondiente del indicador sea siempre el
mismo, independientemente de la posición de éste.
 Medición: Asignar un valor numérico a una magnitud concreta, de acuerdo a una regla
bien definida.
 Muestreo: Tomar distintas mediciones de una variable a tiempos discretos.
 Monitoreo: es el proceso de recolectar, analizar y utilizar información para hacer
seguimiento de algo.
 Modelo Vista-Controlador: o MVC es un patrón que define la organización independiente
del Modelo (Objetos de Negocio), la Vista (interfaz) y el Controlador.
 Precisión: Medida de la reproducibilidad de las mediciones: i.e. dado el valor fijo de la
variable, la precisión es una medida del grado con el cual las mediciones sucesivas
difieren una de otra.
 Prototipo: Ejemplar original o primer molde en que se fabrica una figura u otra cosa.
 Resistencia: Es el grado de oposición que genera un material al paso de la corriente
eléctrica. Su unidad de medida es el Ohm (Ω).
 Resolución: Cambio más pequeño en el valor medido al cual responde el instrumento.
 Requerimientos funcionales y no funcionales
 Salud: Estado en que el ser orgánico ejerce normalmente todas sus funciones
 Síncrono: Se refiere al acceso inmediato, en tiempo real de información u otros datos, por
ejemplo la mensajería instantánea.
 Sensor: Dispositivo capaz de detectar magnitudes físicas o químicas, y transformarlas en
variables eléctricas bien definidas y caracterizadas.
 Sensibilidad: Relación de la señal de salida o respuesta del instrumento respecto al
cambio de la entrada o variable medida.
 Servidor (Computación): Es una aplicación en ejecución (software) capaz de atender las
peticiones de un cliente y devolverle una respuesta en concordancia.
 Signo Vital: Son mediciones de las funciones más básicas del cuerpo
 SPI: “Serial Peripheral Interface”, es un estándar de comunicaciones, usado para la
transferencia de información entre circuitos en equipos electrónicos. El bus de interfaz de
periféricos es un estándar para controlar casi cualquier dispositivo electrónico digital que
acepte flujo de bits
 Software: Equipamiento lógico o soporte lógico de un sistema informático
214
 Transductor: Dispositivo capaz de transformar o convertir un determinado tipo de energía
de entrada, en otra de diferente a la salida.
 Tensión: Es la diferencia de potencial entre dos puntos de un circuito eléctrico. Su unidad
de medida es el Volt.
 UART: Universal Asynchronous Receiver-Transmitter, es el dispositivo que controla los
puertos y dispositivos serie. Se encuentra integrado en la placa base o en la tarjeta
adaptadora del dispositivo.
 Variable analógica: Cuando los datos constituyen matemáticamente un conjunto denso;
i.e. puede tener cualquier valor dentro de un intervalo determinado.
 Variable digital: Cuando los datos constituyen un conjunto finito de valores, normalmente
representados en sistema binario.
 Variable física: Es la magnitud de algo que puede influir en el estado de un sistema físico.
p.g. peso, velocidad, fuerza, etc. Las magnitudes pueden ser escalares o vectoriales.
 Voltaje: También llamada tensión eléctrica o diferencia de potencial, es una magnitud de
la física que mide la diferencia de potencial eléctrico que existe entre dos puntos. El flujo
de electrones circula del punto de menor potencial al punto de mayor potencial. Puede ser
medido con un voltímetro.
 Wifi: Es un mecanismo de conexión de dispositivos electrónicos de forma inalámbrica
215
ANEXOS
En esta sección se indica información adicional para sustentar este trabajo.
Anexo 1. Cálculos propuestos
En esta sección se indican los cálculos necesarios para el diseño del PCB. En la tabla 1, se
indican los valores propuestos para este prototipo:
Componente Valor
R1 10KΩ
R2 10KΩ
R3 330Ω
R4 10 KΩ
R5 180 KΩ
R6 100 KΩ
C1 0.1µF
C2 0.1µF
C3 15pF
C4 15pF
C5 1µF
Tabla 1. Propuesta de valores
El filtro MAX295 opera ya sea con fuentes de alimentación dobles (+-) o individuales (+). Para
trabajar con una fuente de alimentación individual se nos recomienda usar un divisor de voltaje
con resistencias (R1 y R2) de 10KΩ. Esta es la operación del divisor de voltaje mostrado en la
figura 1:
216
Figura 1. Divisor de voltaje.
Como resultado es que nos da exactamente la mitad del voltaje suministrado (3.3v).
La resistencia R3 solo es usada para que no se queme el led.
La resistencia R4 está en una conexión típica con un push botton, para que cuando no este
presionado el push button envié un 0 lógico. Usualmente es de .
Las resistencias R5 y R6 son para la configuración del regulador MAX6349 para obtener un
voltaje de salida de 3.3v. En la hoja de datos nos muestra que debemos hacer la siguiente
operación (Ver figura 2):
Figura 2. MAX6349
La hoja de datos recomienda que R2 debe ser mayor o igual a 100 KΩ para optimizar el consumo
de energía. Así que se propone R2 = 100 KΩ. Entonces nuestra ecuación nos queda así
217
Utilizaremos 180 ya que es un valor comercial.
La hoja de datos del filtro MAX295 nos recomienda usar capacitores de 0.1µF (C1 y C2).
C3 y C4 son conductores de acoplamiento del cristal se recomienda usar 10 y 33 pF. Sirven para
que la salida del oscilador no sea distorsionada.
Para C5 la hoja de datos del regulador MAX6349 recomienda usar un capacitor de 1 µF para
reducir el ruido y mejorar la carga respuesta y la estabilidad de la fuente de alimentación.
Es importante mencionar que para obtener la frecuencia máxima del pulso cardíaco se hizo lo
siguiente:
Las pulsaciones máximas que puede tener una persona son: 200 pulsaciones por minuto,
dividiéndolo entre 60, nos da un total de 3.3 que será la frecuencia máxima del pulso cardíaco
(3.3 HZ)
Para que la señal de pulso cardíaco la podamos ver en frecuencia tenemos que revisar los
milisegundos que esta mide, en el caso de que una onda completa midiese 750 ms, hay que
dividir 60,000 / 750 nos dará 80 (pulsaciones por minuto).
Anexo 2. Hojas de datos
Las hojas de datos correspondientes a los componentes elegidos se encuentran en una carpeta
adjunta llamada “Hojas de datos”.
218

Sistema de Monitoreo de Pulso Cardiaco

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Sistema de Monitoreo de Pulso Cardiaco

Загружено:

Авторское право:

Доступные форматы

INSTITUTO POLITÉCNICO NACIONAL

ESCUELA SUPERIOR DE CÓMPUTO

Prototipo de sistema de alerta y monitoreo de signos vitales de

No TT: 2014B 004

No TT: 2014B 004 DICIEMBRE,2015

Prototipo de sistema de alerta y monitoreo de signos vitales de

1 Correo electrónico: malanist1100@alumno.ipn.mx

En el presente reporte se propone un prototipo cuya finalidad es prevenir posibles percances de

Palabras clave –signo vital, monitoreo, aplicación móvil, sistema embebido.

Le doy gracias a mi papá Eduardo por su trabajo constante y su dedicación y a mi mamá

A Mariana, mi compañera de trabajo terminal, gracias por tu paciencia, esmero, dedicación y

1.5.2. Aplicación móvil ..................................................................................................................14

1.5.3. Sistema de posicionamiento global (GPS) ...........................................................................15

1.5.4. Google Maps ........................................................................................................................16

1.5.5. Sistema distribuido ...............................................................................................................16

1.5.6. Instrumentación electrónica .................................................................................................18

1.5.7. Dispositivos programables ...................................................................................................23

1.6. Estado del arte ..............................................................................................................................24

5.1.2. Aplicación móvil ......................................................................................................................174

5.1.3. Dispositivo electrónico .............................................................................................................177

5.2. Pruebas finales y de integración .................................................................................................183

Estructura del documento

El presente trabajo está estructurado de la siguiente manera.

Capítulo 1. Introducción: Se da una descripción general del prototipo propuesto y sus

Capítulo 4. Implementación. Se indican las partes fundamentales de la implementación del

Capítulo 5. Pruebas. Se muestran pruebas modulares y de integración del prototipo.

Capítulo 6. Conclusiones y Trabajo a Futuro. Se concluye el trabajo realizado y se proponen

Glosario: Lista de términos poco utilizados y conocidos con su respectiva definición.

Anexos. Se indica información adicional de relevancia.

Es importante resaltar que para el correcto desenvolvimiento de estas carreras, es de gran

1.2. Objetivo general

El objetivo general es el siguiente:

 Diseñar e implementar un prototipo de sistema que permita el monitoreo de signos vitales

1.3. Objetivos específicos

Los objetivos específicos son:

• Diseñar y desarrollar un sistema embebido mediante un dispositivo electrónico para la

1.5. Marco teórico

A continuación se abordará la teoría necesaria para fundamentar el prototipo propuesto.

1.5.1. Sistema embebido

Los sistemas embebidos son una combinación de hardware y software.

El software de programación puede ser el propio lenguaje ensamblador de la CPU o un lenguaje

La estrecha relación entre hardware y software, nos ha facilitado a nosotros el diseño de

1.5.2. Aplicación móvil

Existen infinidad de tipos de aplicaciones: Aplicaciones de noticias, entretenimiento o juegos,

El término App es la abreviatura de “Application” y como tal, siempre se ha utilizado para

1.5.3. Sistema de posicionamiento global (GPS)

Según el autor, por definición: El Sistema de Posicionamiento Global (GPS) es un servicio

El GPS se compone principalmente de tres elementos: los satélites en órbita alrededor de la

Figura 1.1 GPS.

1.5.4. Google Maps

Es un servidor de aplicaciones de mapas en la web que pertenece a Google. Ofrece imágenes de

Figura 1.2. Logo de Google Maps

1.5.5. Sistema distribuido

La computación desde sus inicios ha sufrido muchos cambios, ha evolucionado dependiendo de

La definición de un sistema distribuido por el autor Coulouris es la siguiente:

Se puede definir al modelo cliente-servidor como un modelo de comunicación distribuida que

En el modelo cliente-servidor, el cliente envía un mensaje solicitando un determinado servicio a

Figura 1.3. Modelo cliente-servidor.

1.5.6. Instrumentación electrónica

Estas variables se clasifican en analógicas y digitales:

 Variables digitales: Cuando los datos constituyen un conjunto finito de valores,

 Adquisición de datos: La información de las variables a medir es adquirida y convertida

 Procesamiento de datos: Consiste en el procesamiento, selección y manipulación de los

 Distribución de los datos: El valor medido se presenta a un observador (por ejemplo