Facultad de Ciencias de la Ingeniera

Escuela de Ingeniera Civil en Informtica

PROPUESTA DEFRAMEWORK DE DESARROLLO

DE
PROYECTOS IMFORMTICOS PARA LA
FACULTAD DE
CIENCIAS JURDICAS Y SOCIALES DE LA UACh.

Proyecto para optar al ttulo de .

Ingeniero Civil en Informtica

PROFESOR PATROCINANTE:
CHRISTIAN ALEXIS LAZO RAMREZ
DOCTOR EN INGENIERA TELEMTICA
PROFESOR INFORMANTE:
LUIS HERNN VIDAL VIDAL
M.B.A INGENIERO CIVIL EN INFORMTICA
PROFESOR INFORMANTE:
JORGE ANTONIO MORALES VILUGRON
INGENIERO ELECTRNICO
M.B.A., D.E.A. MICROCONTROLADORES

Enzo Edgardo Vera Pagnard

VALDIVIA - CHILE
2015

AGRADECIMIENTOS

Agradezco a mi padre Adolfo, mi madre Carmen Gloria y a mi hermana Catalina por

apoyarme, aguantarme, y educarme con valores como la perseverancia y la humildad,
fundamentales para sacar adelante la carrera.

Agradezco a mis amigos (que son poquitos pero ellos saben quienes son) por todo el
aguante y por estar ah cuando los necesit.

Agradezco a mis compaeros de carrera, con los cuales compart muchos aos y muchas
veces me ayudaron, me ensearon y hasta me salvaron. Espero haberles aportado a ustedes
tambin.

Finalmente, agradezco a todas las personas no mencionadas que conozco, todos aportaron
de alguna forma a mi crecimiento como persona, y por lo tanto tambin hay mucho de
ustedes en esta etapa superada.

NDICE
NDICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NDICE DE TABLAS . . . . . . . . . . . . . . . . . . . . . . . .
NDICE DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . .
RESUMEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 INTRODUCCIN . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Motivacin . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Impactos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1 Objetivo general . . . . . . . . . . . . . . . . . . . . . . .
1.4.2 Objetivos especficos . . . . . . . . . . . . . . . . . . . .
1.5 Organizacin del documento . . . . . . . . . . . . . . . . . . .
2 MARCO TERICO . . . . . . . . . . . . . . . . . . . . . . .
2.1 Qu es un Proyecto? . . . . . . . . . . . . . . . . . . . . . . .
2.2 Ciclo de Vida o Etapas de un Proyecto . . . . . . . . . . . . . .
2.2.1 Requerimientos . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Anlisis . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 Diseo . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.4 Implementacin . . . . . . . . . . . . . . . . . . . . . . .
2.2.5 Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.6 Produccin y Mantenimiento . . . . . . . . . . . . . . . .
2.3 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 Redes inalmbricas de sensores . . . . . . . . . . . . . . . . . .
2.6 Internet de las cosas . . . . . . . . . . . . . . . . . . . . . . . .
2.6.1 Big Data . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.7 Dispositivos mviles . . . . . . . . . . . . . . . . . . . . . . .
2.7.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.8 Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . .
2.8.1 Sistemas similares . . . . . . . . . . . . . . . . . . . . . .
2.8.2 Software relacionado . . . . . . . . . . . . . . . . . . . .
2.8.2.1 Sheep Tracker . . . . . . . . . . . . . . . . . . . . . .
2.8.2.2 EWEBYTE . . . . . . . . . . . . . . . . . . . . . . .
2.8.2.3 Select Sheepware . . . . . . . . . . . . . . . . . . . .
2.8.3 Hardware relacionado . . . . . . . . . . . . . . . . . . . .
2.8.3.1 Arduino . . . . . . . . . . . . . . . . . . . . . . . . .
2.8.3.2 Waspmote . . . . . . . . . . . . . . . . . . . . . . . .
2.8.4 Marco regulatorio . . . . . . . . . . . . . . . . . . . . . .
2.8.4.1 Procedimiento P-PP-IT-007 . . . . . . . . . . . . . .
2.8.4.2 Instructivo I-PP-IT-018 . . . . . . . . . . . . . . . . .
2.8.4.3 DIIO y Registro de Movimiento Animal . . . . . . . .
2.8.4.4 Conclusiones . . . . . . . . . . . . . . . . . . . . . .
3 SOLUCIN PROPUESTA . . . . . . . . . . . . . . . . . . . .
3.1 Definicin de la problemtica . . . . . . . . . . . . . . . . . . .
3.1.1 Sistema de gestin ovina . . . . . . . . . . . . . . . . . .
3.1.2 Monitoreo continuo . . . . . . . . . . . . . . . . . . . . .
3.2 Definicin de la solucin . . . . . . . . . . . . . . . . . . . . .
3.3 Tecnologas a utilizar . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1.1 Nodo de sensores . . . . . . . . . . . . . . . . . . . .
3.3.1.2 Nodo coordinador . . . . . . . . . . . . . . . . . . . .
3.3.1.3 Comunicacin en la red de sensores . . . . . . . . . .
3.3.1.4 Almacenamiento y procesamiento de la informacin .
3.3.1.5 Dispositivos moviles . . . . . . . . . . . . . . . . . .
3.3.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2.1 Libreras para sistemas embebidos, sensores y red . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

i
iii
iv
vi
vii
1
2
3
4
5
5
5
5
7
7
7
9
10
12
15
16
19
21
21
22
24
26
27
29
30
30
31
32
33
35
36
36
37
39
40
41
42
42
43
43
43
44
45
45
46
46
48
48
49
50
50
50

3.3.2.2 Intercambio de datos . . . . . . . . . . . . . . . . . .

3.3.2.3 Base de datos . . . . . . . . . . . . . . . . . . . . . .
3.3.2.4 Servicio de cartografia y notificaciones . . . . . . . .
3.4 Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . .
4 ANLISIS Y DISEO . . . . . . . . . . . . . . . . . . . . . .
4.1 Metodologa de desarrollo de software . . . . . . . . . . . . . .
4.2 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Fase de anlisis . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Descripcin de las actividades del proceso . . . . . . . . .
4.3.2 Actores del sistema . . . . . . . . . . . . . . . . . . . . .
4.3.3 Casos de uso expandidos . . . . . . . . . . . . . . . . . .
4.3.4 Diagramas de secuencia . . . . . . . . . . . . . . . . . . .
4.4 Fase de diseo . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1 Casos de uso real . . . . . . . . . . . . . . . . . . . . . .
4.4.2 Diagrama de clases . . . . . . . . . . . . . . . . . . . . .
4.4.3 Base de datos . . . . . . . . . . . . . . . . . . . . . . . .
5 ELECCIN DE TOPOLOGA DE RED Y ALTERNATIVAS . . . .
5.1 Consideraciones para prueba de concepto . . . . . . . . . . . .
5.2 Alternativas ofrecidas por el equipamiento . . . . . . . . . . . .
5.3 Eleccin de topologa y caractersticas de la implementacin . .
5.3.1 Condiciones de borde . . . . . . . . . . . . . . . . . . . .
5.4 Alternativas de equipamiento y topologas de red . . . . . . . .
5.5 Marco comparativo . . . . . . . . . . . . . . . . . . . . . . . .
6 IMPLEMENTACIN. . . . . . . . . . . . . . . . . . . . . . .
6.1 Configuracin de mdulos XBee-PRO . . . . . . . . . . . . . .
6.2 Nodo de sensores . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Nodo coordinador . . . . . . . . . . . . . . . . . . . . . . . . .
6.4 Equipo central . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5 Dispositivo mvil . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.1 APIs y servicios de Google . . . . . . . . . . . . . . . . .
6.6 Producto de software . . . . . . . . . . . . . . . . . . . . . . .
7 VALIDACIN Y RESULTADOS . . . . . . . . . . . . . . . . .
7.1 Validacin de la prueba de concepto . . . . . . . . . . . . . . .
7.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8 CONCLUSIONES . . . . . . . . . . . . . . . . . . . . . . . .
BIBLIOGRAFA . . . . . . . . . . . . . . . . . . . . . . . . . .
ANEXOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anexo A: Formulario de Movimiento Animal. . . . . . . . . . . . . .
Anexo B: Diagrama de clases. . . . . . . . . . . . . . . . . . . . . .
Anexo C: Sketch nodo de sensores. . . . . . . . . . . . . . . . . . .
Anexo D: Sketch nodo coordinador. . . . . . . . . . . . . . . . . . .
Anexo E: Ray Casting en PHP. . . . . . . . . . . . . . . . . . . . . .
Anexo F: Lista de abreviaciones. . . . . . . . . . . . . . . . . . . . .

ii

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . .
. . . .
. . . .
. . .
. . .
. . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

51
52
52
53
54
54
56
59
59
60
61
62
63
63
66
66
70
70
71
72
73
74
76
79
79
81
81
82
83
83
85
89
89
89
93
95
103
103
104
105
109
115
118

NDICE DE TABLAS

TABLA

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

PGINA

Versiones de Android soportadas por Google en la actualidad [And14a].

Product Backlog del sistema. . . . . . . . . . . . . . . . . . . . . . . .
Sprint 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sprint 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sprint 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Caso de uso expandido Capturar y enviar informacin. . . . . . . . .
Caso de uso expandido Ver informacin de un animal en particular. . .
Caso de uso real Ver informacin de un animal en particular (CU02). .
Diccionario de datos tabla parametros. . . . . . . . . . . . . . . . . .
Diccionario de datos tabla oveja. . . . . . . . . . . . . . . . . . . . .
Diccionario de datos tabla observacion. . . . . . . . . . . . . . . . . .
Diccionario de datos tabla orientacion. . . . . . . . . . . . . . . . . .
Diccionario de datos tabla ubicacion. . . . . . . . . . . . . . . . . . .
Diccionario de datos tabla perimetro. . . . . . . . . . . . . . . . . . .
Diccionario de datos tabla device. . . . . . . . . . . . . . . . . . . .
Diccionario de datos tabla users. . . . . . . . . . . . . . . . . . . . .
Tabla comparativa de topologas de red. . . . . . . . . . . . . . . . . . .
Tabla de compatibilidad entre topologas de red y terreno. . . . . . . . .

iii

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

29
57
58
58
59
61
62
64
67
67
67
68
68
68
68
69
76
78

NDICE DE FIGURAS
FIGURA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

PGINA

Ciclo de vida de un proyecto [Min13]. . . . . . . . . . . . . . . . . . . . .

Ciclo de vida de un proyecto (Extendido) [Min13a]. . . . . . . . . . . . . .
Etapas de bsicas del ciclo de vida del desarrollo de software [Cas]. . . . . .
Anlisis como puente entre la ingeniera y el diseo de software [Pre02]. . .
Artefactos de la etapa de anlisis. [Lar99]. . . . . . . . . . . . . . . . . . .
Un modelo general del proceso de diseo. [Som05b]. . . . . . . . . . . . .
Componentes de un nodo de sensores [Aky13]. . . . . . . . . . . . . . . . .
Red inalmbrica de sensores y servicios relacionados [Ind]. . . . . . . . . .
Internet de las cosas [She09]. . . . . . . . . . . . . . . . . . . . . . . . . .
Crecimiento y prediccin futura de envos de dispositivos mviles [Eng12].
Ingreso de animal en Sheep Tracker. . . . . . . . . . . . . . . . . . . . . .
Ventana principal de Sheep Tracker. . . . . . . . . . . . . . . . . . . . . . .
Ventana principal de EWEBYTE y men de ingreso de datos. . . . . . . . .
Ingreso de nuevo ovino en EWEBYTE. . . . . . . . . . . . . . . . . . . . .
Nuevo usuario en Select Sheepware. . . . . . . . . . . . . . . . . . . . . .
Pantalla principal de Select Sheepware. . . . . . . . . . . . . . . . . . . . .
Arduino Uno R3 [Ard14a]. . . . . . . . . . . . . . . . . . . . . . . . . . .
Waspmote con modulo UMTS + GPS [Lib14a]. . . . . . . . . . . . . . . .
Mdulos sensores para Waspmote [Sen13]. . . . . . . . . . . . . . . . . . .
Placa identificadora de predio PABCO [Sag14c]. . . . . . . . . . . . . . . .
USGlobalSat EM-406A y Honeywell HMC6352. . . . . . . . . . . . . . .
Analog Devices ADXL335. . . . . . . . . . . . . . . . . . . . . . . . . . .
Serie uno de XBee. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arduino XBee Shield [Lib14c]. . . . . . . . . . . . . . . . . . . . . . . . .
Arquitectura del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ciclo incremental iterativo Scrum [Ant14]. . . . . . . . . . . . . . . . . . .
Diagrama de proceso del sistema. . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de Casos de Uso. . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de secuencia de CU Capturar y enviar informacin.. . . . . . .
Diagrama de secuencia de CU Ver informacin de un animal en particular..
Diseo de ventanas 1 y 2 para CU02. . . . . . . . . . . . . . . . . . . . . .
Diseo de ventana 3 para CU02. . . . . . . . . . . . . . . . . . . . . . . .
Modelo de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Topologas de red soportadas por IEEE 802.15.4 [Zei14]. . . . . . . . . . .
Esquema de predio donde operan los nodos de sensores. . . . . . . . . . . .
Mltiples redes de sensores en la topologa estrella. . . . . . . . . . . . . .
Topologas disponibles para implementacin [Rtc13]. . . . . . . . . . . . .
Escenarios posibles a abordar por las topologas. . . . . . . . . . . . . . . .
Versin 6 de Digi XCTU. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Estructura de un paquete XBee en modo API [Ker12]. . . . . . . . . . . . .
Prototipo inicial de nodo sensor. . . . . . . . . . . . . . . . . . . . . . . . .
Prototipo inicial de nodo coordinador. . . . . . . . . . . . . . . . . . . . .
Arquitectura de Google Messaging Service [Ant13a]. . . . . . . . . . . . .
Funcionamiento de Google Play Services [Ant13b]. . . . . . . . . . . . . .
Inicio de sesin en la aplicacin mvil. . . . . . . . . . . . . . . . . . . . .
Pantalla de Alta Ovina en la aplicacin mvil. . . . . . . . . . . . . . . . .
Pantalla principal de la aplicacin mvil. . . . . . . . . . . . . . . . . . . .
Pantalla de informacin ovina en la aplicacin mvil. . . . . . . . . . . . .
Pantalla de observaciones y ruta recorrida de la aplicacin mvil. . . . . . .
Pantallas de permetro, baja ovina y nuevo usuario de la aplicacin mvil. .
Resultados de medicin a 1 kilmetro de distancia entre nodos. . . . . . . .
Resultados de medicin a 900 metros de distancia entre nodos. . . . . . . .
Resultados de medicin a 800 metros de distancia entre nodos. . . . . . . .
Resultados de medicin a 700 metros de distancia entre nodos. . . . . . . .
Resultados de medicin a 600 metros de distancia entre nodos. . . . . . . .
Resultados de medicin a 500 metros de distancia entre nodos. . . . . . . .

iv

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

8
8
8
10
12
13
23
23
25
27
32
33
34
34
35
36
37
38
38
41
47
47
48
49
53
55
59
60
63
63
65
65
66
71
72
74
75
77
79
80
81
81
84
84
85
86
86
87
87
88
90
90
91
91
92
92

RESUMEN

En estos ltimos aos, la conectividad a Internet ha crecido dramticamente, y a un

ritmo que est lejos de detenerse. Y esta conectividad no solo ha involucrado a los
seres humanos, sino tambin a diversos objetos de la vida cotidiana que de forma
autnoma utilizan Internet para realizar sus funciones, obtener informacin relevante para
su operacin e incluso permitiendo el control remoto de los usuarios de este.

En este contexto, la humanidad comienza a convivir con una raza de aparatos que se
encuentran conectados entre si, llamndose este nuevo paradigma el Internet de las
cosas, el que avanza rpidamente en nuestro da a da, mientras usamos nuestro telfono
inteligente, controlamos la iluminacin de nuestro hogar de forma remota, entre muchas
otras aplicaciones actuales y futuras.

Este proyecto de titulacin es un esfuerzo de trasladar este paradigma, aplicando sus

principios, para el estudio de ovinos, siendo estos monitoreados por una red inalmbrica
de sensores, obtenindose informacin en tiempo real de estos animales y de posibles
amenazas que se encuentren enfrentando. Esta red se integra en un marco de trabajo que
muestra toda esta informacin en dispositivos mviles y notifica ante anormalidades en los
animales. Finalmente, se define la mejor forma de implementar este sistema acompaada
de una validacin de esta implementacin.

ABSTRACT

In the last few years, the access to the Internet has grown dramatically, and at a pace that
is far from be over. And this connectivity it is not just for human beings, but also to many
day-to-day objects that use Internet for their own functions, gathering information of their
interest and ever allowing remote access from their users.

In this context, the mankind starts to coexist with a new race of devices that are connected,
marking the beginning of the Internet of Things. This new paradigm is steadly establishing
in the life of the population, while we use our smartphone, while we control our home
appliances, and many others present and future applications.

This proyect is an effort to bring this paradigm and their principles to the studying of
sheep, with the use of a wireless sensor network to gather information of the animals and
possible threats that the sheep could face in real time. Then, this network is integrated in
a framework that shows all the information in mobile devices and notifies of anormalities
detected in the flock. Finally, it is defined the best way to deploy the network and a test is
designed to validate this deployment.

vi

1.

INTRODUCCIN

El desarrollo de la tecnologa en estas ltimas dcadas ha tenido un ritmo vertiginoso,

estando muchas de estas innovaciones de la mano con los avances de las tecnologas de
la informacin y de las telecomunicaciones. Ms aun, estas ltimas dos dcadas estos
avances se han ido acercando ms y ms a la vida cotidiana de las personas, desde la
penetracin del computador personal en los hogares hasta la situacin actual, donde cada
da es ms comn llevar un dispositivo con todas las caractersticas de un computador en
el bolsillo.

Estos dispositivos, adems de sus prestaciones, impensadas hace solo algunos aos, se
encuentran comunicados mediante diversas tecnologas inalmbricas a la red de redes,
Internet. Esta comunicacin no solo permite a las personas mantener el contacto con
su vida, trabajo y amistades, sino tambin permite que estos dispositivos se conecten
con otros de forma independiente, realizando tareas en segundo plano para brindar ms
informacin de inters a las personas, o para otras funciones propias del dispositivo.

En la actualidad, televisores, refrigeradores e incluso ampolletas de luz [Lif14] se

encuentran conectadas a Internet, con lo que se abre paso a un nuevo paradigma
donde dispositivos de cualquier ndole son capaces de conectarse a Internet, siendo
este paradigma llamado el Internet de las Cosas (IoT, the Internet of Things). Este
nuevo concepto contempla la comunicacin de cualquier dispositivo, objeto o animal
con Internet, para obtener de forma rpida informacin sobre l o incluso realizar alguna
accin sobre el de forma remota.

Este paradigma, que contempla una nueva raza de dispositivos baratos, livianos y con un
consumo muy reducido de energa, abre la posibilidad de conocer el estado de objetos de
estudio de una forma que en la antigedad simplemente no era posible. Por ejemplo, a un
animal se le puede colocar uno de estos pequeos dispositivos, con sensores que recopilen
cierta informacin, envindose esta en tiempo real hacia los dispositivos de los usuarios
para conocer su estado en todo momento, e incluso obtener alertas si algo anormal sucede
con el, lo que da paso al almacenamiento de grandes volmenes de informacin, lo que
conocemos como Big Data.

Siguiendo con el ejemplo, esta forma de obtener informacin del animal, o de un conjunto
de animales desde un punto de vista productivo, supone una clara ventaja competitiva
frente a otros sistemas de monitoreo pasivo y ms an frente a sistemas de gestin que no
involucran ningn tipo de tecnologa.

Este proyecto de titulacin es un esfuerzo en crear esta ventaja competitiva en el mbito

productivo de animales ovinos, utilizando el paradigma del Internet de las cosas para
utilizar dispositivos pequeos, livianos, robustos y de bajo costo para ubicarlos en los
animales, y as obtener informacin de forma permanente acerca de su posicin, direccin
y posibles alteraciones de su comportamiento. Todos estos captores formarn una red de
sensores que almacena esta informacin en un equipo central, permitiendo acceder a esta
informacin desde dispositivos mviles a travs de Internet. Se encuentran contempladas
diversas funcionalidades en este proyecto, desde conocer su posicin mostrada en un
mapa, hasta la generacin de alertas a los dispositivos mviles en caso de situaciones
anormales que estn sufriendo los animales, como posibles ataques o robos.

Este proyecto, ademas, abre la puerta al estudio del comportamiento de estos animales,
al existir muy poca informacin para la generacin de modelos de comportamiento o
etolgicos, facilitando la deteccin por ejemplo de enfermedades o etapa de celo, a
diferencia de la situacin de animales bovinos que si cuentan con estos modelos e incluso
con soluciones comerciales disponibles [Tra13] [Mas12] [Hid13].

1.1.

Antecedentes

En el marco local, la Regin de los Ros y sus alrededores histricamente han sido un
lugar privilegiado para la produccin animal, en la cual se producen diversas especies de
animales, especialmente bovinos. Esta regin se caracteriza por su aptitud ganadera, con
183.912,64 hectreas de praderas naturales y mejoradas [Fia09].

Con la creacin de la Regin de los Ros, adems de otras entidades gubernamentales

como la Fundacin para la Innovacin Agraria (FIA), se reconoce la necesidad de
aumentar los factores productivos de las regiones, en la bsqueda de duplicar nuevamente
el ingreso per cpita del pas en los prximos 15 aos [Ben07].

Si bien han existido en el pasado polticas para el desarrollo de la produccin animal

[Fia08], desde el ao 2012 en la Regin de los Ros hay un sostenido inters en potenciar
la produccin animal ovina, canalizndose en diversos proyectos y capacitaciones a
productores, incluso invitando expertos desde Nueva Zelandia para estas capacitaciones
[Viv12].

Los desafos para el crecimiento de esta actividad econmica son diversos, como lo
son el robo de animales conocido como abigeato, el ataque de perros u otros animales
hacia los ovinos, entre otras [Pal13]. Adems, existe una cantidad muy reducida de
tecnologa aplicable al desarrollo de esta actividad, lo que dificulta la generacin de
ventajas competitivas.

Por otro lado, en la actualidad existe una tendencia global de conectividad no solo entre
personas, sino tambin entre dispositivos mviles, sistemas embebidos con sensores y
objetos de la vida diaria. Este nuevo concepto se conoce como el Internet de las Cosas
[Cis11], el cual describe una red de cosas conectadas entre s.

Este nuevo paradigma, permite que se pueda obtener informacin que anteriormente se
obtena de una forma muy costosa y/o de una forma poco practica. Por ejemplo, con un
pequeo y econmico sistema embebido con conexin a Internet, ademas de un captor,
se puede monitorear la temperatura de un saln desde cualquier parte del mundo, y desde
una gran cantidad de dispositivos distintos [Lew04]. Esto permite monitorear, almacenar
y obtener informacin de diversos objetos de estudio de una forma eficiente.

1.2.

Motivacin

La motivacin principal para este proyecto es el uso de tecnologas y paradigmas actuales

para generar una ventaja competitiva en un rubro productivo, como lo es la produccin
animal. En trminos locales, como se expuso en los antecedentes, existe una oportunidad
de aprovechar las condiciones de la zona para hacer crecer esta actividad, existiendo
adems voluntades gubernamentales para generar un crecimiento en el corto, mediano
y largo plazo.

En el aspecto tcnico, la ausencia de soluciones dedicadas al monitoreo activo en ovinos,

ms aun en tiempo real, ofrece el espacio necesario para diferenciar este proyecto de otros
productos utilizando dispositivos de bajo costo y de reducida mantencin, que entregan
valiosa informacin a sus usuarios. As, el proyecto contempla un gran nfasis en la
computacin mvil, pudiendo realizar el trabajo en terreno cmodamente con una tablet o
telfono, adecundose a las condiciones productivas de los predios.

Finalmente, si bien han habido diversas iniciativas de monitoreo ovino para determinar
su comportamiento [San10], ninguna de estas ha llevado al desarrollo de un modelo de
comportamiento, necesario para la generacin de sistemas capaces de detectar condiciones
especficas del animal, como puede ser enfermedades, celo o una disrupcin en el rebao,
todas estas impactando en el aspecto productivo anteriormente sealado.

1.3.

Impactos

El desarrollo de tecnologas que apuntan al paradigma del Internet de las cosas es un rea
poco explorada y con un potencial enorme de utilidad para toda la poblacin. Por ejemplo,
en India se propone un sistema basado en el Internet de las cosas para mejorar el acceso y
reducir el costo de llevar agua potable a los barrios ms pobres de las ciudades [Cis11].

As, la aplicacin de estas tecnologas en este proyecto no solo genera una notable ventaja
competitiva a los productores de ovinos al tener toda la informacin y estado actual de sus
animales en sus bolsillos, sino que tambin aporta un grano de arena ms al conocimiento
e implementacin de estos sistemas, que solo van a seguir aumentando en cantidad,
aplicaciones y alcance en el futuro.

De esta forma adems, se establece una forma de monitorear un objeto de estudio, que
en este caso es un ovino. Sin embargo, esta tecnologa se puede aplicar al monitoreo
en diversos objetos, situaciones o ambientes, como el monitoreo de estructuras, hogares,
maquinaria industrial, seguridad ciudadana, ciudades inteligentes, entre muchos otros.

1.4.

Objetivos

1.4.1.

Objetivo general

Disear y desarrollar un marco de trabajo (framework) para mejorar la gestin y monitoreo

ovino.

1.4.2.

Objetivos especficos

1. Estudiar y analizar los escenarios tpicos donde se aplicar el marco de trabajo,

es decir, tecnologas similares existentes o integrables, y marco regulatorio de la
produccin animal.
2. Obtener, analizar y especificar los requisitos del sistema, ademas de analizar y
disear casos de uso correspondientes con los objetos de diseo necesarios, y
generar mockups de la interfaz para el posterior desarrollo de la aplicacin mvil.
3. Disear una topologa de red y arquitectura de sistema capaz de obtener datos
desde dispositivos mviles y de posibles sensores ubicados en los animales, el
almacenamiento de estos datos en una base de datos remota, y su presentacin en
aplicaciones de diversos tipos.
4. Implementar, con un ciclo de vida iterativo e incremental, el software en base a los
objetivos especficos anteriores, y validar estos incrementos con casos reales.

1.5.

Organizacin del documento

El contenido del documento se encuentra dividido en 8 captulos organizados de la

siguiente manera:
El primer captulo aborda la introduccin del proyecto de titulo.
El segundo captulo, llamado Marco terico, profundiza en los contenidos
relevantes que son tratados a lo largo del documento, referentes a redes de sensores,
el Internet de las cosas, dispositivos mviles y la informacin bsica requerida
para la gestin de rebaos de ovinos, proporcionando definiciones y llevando estas
al contexto del proyecto. Finalmente, se realiza una revisin del estado del arte
pertinente a estos sistemas y contexto, ademas de un anlisis a la normativa nacional
sobre la produccin ovina, de acuerdo al primer objetivo especfico del proyecto.
5

El tercer captulo, llamado Solucin propuesta, define la problemtica que plantea

la gestin ovina y el monitoreo de animales, tomando en cuenta la informacin
recabada en el objetivo uno y se propone una solucin a la situacin expuesta.
Adems, se realiza la seleccin de las herramientas de hardware y de software
a utilizar para la implementacin de un prototipo funcional que abarque la
problemtica definida.
El cuarto captulo, llamado Anlisis y diseo, aborda las tareas necesarias para
modelar la solucin propuesta dada la problemtica definida, y especifica el uso
de las tecnologas seleccionadas en el captulo anterior,todo esto de acuerdo al
segundo objetivo especfico del proyecto.
El quinto captulo, llamado Eleccin de topologa de red y alternativas, es el
captulo en el cual se proponen diversas topologas de red a utilizar por el lado de
los sensores con el equipamiento definido previamente, y se define un escenario
de implementacin basado en escenarios reales donde podra operar esta red.
Finalmente se elige una de estas topologas para la implementacin de la prueba de
concepto de un nodo sensor y se presentan alternativas con equipamiento distinto,
todo esto de acuerdo al tercer objetivo especfico del proyecto.
El sexto captulo, llamado Implementacin, expone la construccin del prototipo
de software de acuerdo con el cuarto objetivo especfico, segn el proceso de
anlisis y diseo llevado a cabo en el cuarto captulo, y utilizando la topologa de
red definida en el captulo anterior.
El sptimo captulo, llamado Validacin y resultados, define un mtodo para
validar la implementacin de la red inalmbrica de sensores propuesta en el quinto
captulo, y se presentan los resultados de la prueba previamente definida.
Finalmente, el octavo captulo aborda las Conclusiones obtenidas del trabajo
realizado, ademas de proyectar posibles mejoras para llevar a cabo en una posible
continuacin de este proyecto.

2.

MARCO TERICO

En el presente captulo, se describen los conceptos y convenciones en torno a los cuales se

desenvuelve el proyecto, sealando que etapas conforman un proyecto y la documentacin
de cada etapa. Ademas se realizara una revisin del estado del arte, donde se describir
las tecnologias de software involucradas y tambien se revisar algunos Framework
relacionados con ambientes academicos on-line y de desarrollo de software que existen
en la actualidad.

2.1.

Qu es un Proyecto?

Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio
o resultado nico.La naturaleza temporal de los proyectos implica que un proyecto tiene
un principio y un final definidos. En general, esta cualidad de temporalidad no se aplica
al producto, servicio o resultado creado por el proyecto; la mayor parte de los proyectos
se emprenden para crear un resultado duradero. Por ejemplo, un proyecto para construir
un puente crear un resultado que se espera perdure durante varios aos. Por otra parte,
los proyectos pueden tener impactos sociales, econmicos y ambientales susceptibles de
perdurar mucho ms que los propios proyectos.

Un proyecto puede generar: un producto, que puede ser un componente de otro elemento,
una mejora de un elemento o un elemento final en s mismo; un servicio o la capacidad de
realizar un servicio, por ejemplo, una funcin de negocio que brinda apoyo a la produccin
o distribucin; una mejora de las lneas de productos o servicios existentes, por ejemplo,
un proyecto Seis Sigma cuyo objetivo es reducir defectos; o un resultado, tal como una
conclusin o un documento, por ejemplo, un proyecto de investigacin que desarrolla
conocimientos que se pueden emplear para determinar si existe una tendencia o si un
nuevo proceso beneficiar a la sociedad [PMI13].

2.2.

Ciclo de Vida o Etapas de un Proyecto

Corresponde a un proceso de transformacin de ideas, surgidas de la deteccin de

necesidades, problemas u oportunidades, en soluciones concretas para la provisin de
bienes o servicios que mejor resuelven dichas necesidades o problemas o aprovechen las

oportunidades [Min13]. Una buena representacin resumida de esto se puede ver en la Fig.
1.

Figura 1. Ciclo de vida de un proyecto [Min13].

Las fases de Pre-invercin, inversin y operacion las podemos desclosar como se muestra
en la siguiente Fig. 2

Figura 2. Ciclo de vida de un proyecto (Extendido) [Min13a].

Extrapolando esto al sector de la ingeniera de software podriamos de representar de
forma bsica un ciclo de vida como el qe se muestra en la Fig. 3. Ya que, implcita o
explcitamente todos los modelos de ciclo de vida cuentan por lo menos con las siguientes
actividades: Requerimientos, Anlisis, Diseo, Implementacin, Pruebas, Produccin y
Mantenimiento [Cas].

Figura 3. Etapas de bsicas del ciclo de vida del desarrollo de software [Cas].
Acontinuacin se describiran brebemente cada una de estas etapas.

2.2.1.

Requerimientos

Los requerimientos para un sistema son la descripcin de los servicios proporcionados por
el sistema y sus restricciones operativas. Estos requerimientos reflejan las nesecidades
de los clientes de un sistema que ayude a resolver algn problema como el control
de in dispocitivo, hacer un pedido o encontrar informacin. El proceso de descubrir,
analizar, documentar y verificar estosservicios y restricciones se denomina Ingeniera de
Requerimientos (RE).

El trmino requerimiento no se utiliza de una forma constante en la insdustria de software.

En algunos casos, un requerimiento es simplemente una declaracin abtracta de alto nivel

de un servicio que debe proporcionar el sistema o una restriccion de este. El otro extremo,
es una definicion detallada y formal de una funcin del sistema.

Podemos distinguir utilizando la denominacin requerimientos del usuario para designar a

los requerimientos de alto nivel y requerimientos del sistema para designar la descripcin
detallada de lo que el sistema debe hacer.

Una descricin de cada uno de estos tipos de requerimientos:

Los Requerimientos del usuario: son declaraciones, en lenguaje natural y en diagramas,
de los servicios que se espera que el sistema proporcione y de las restricciones bajo
las cuales debe funcionar.
Los Requerimientos del sistema: establecen con detalle las funciones, servicios y
restricciones operativas del sistema. El documento de requerimientos del
sistema,algunas veses denominado especificacin funcional, debe ser preciso. Debe
definir exactamente qu es lo que se va a implementar. Puede ser parte del contrato
entre el comprador del sistema y los desarrolladores del software [Som05].
El documento de requerimientos del software, algunas veses denominado especificacin
de requerimientos del software, SRS, por su sigla en ingles, es la declaracin oficial qu
deben implementar los desarrolladores del sistema. Debe incluir tanto los requerimietos
del usuario para el sistema como una especificacin detallada de los requerimientos del
sistema. El documento tiene un conjunto diverso de usuario que va desde los altos cargos
9

de la organizacion que paga por el sistema, hasta los ingenieros responsables de desarrollar
el software. La informacin sobre cambios previstos puede ayudar a los diseadores
del sistema a evitar deciciones de diseo restrictivas y a los ingenieros encargados del
mantenimiento del sistema, quienes tienen que adaptar el sistema a nuevos requerimientos.

El estandar ms ampliamente conocido es el IEEE/ANSI 830-1998. Este estndar suguiere

uan estructura que no es la ideal, pero contiene muchos consejos sobre cmo redactar los
requerimientos y cmo evitar problemas. Es un marco general que se puede adaptar para
definir un estandar ajustado a las nesecidades de una organizacin em particular [Som05a].

2.2.2.

Anlisis

El anlisis de los requerimientos es una tarea de ingeniera del software que cubre el
hueco entre la definicin del software a nivel sistema y el diseo del software, ver Fig.
4. El anlisis de requisitos permite al ingeniero de sistema especificar las caractersticas
operacionales del software, funcin, datos y rendimiento, indica la interfaz del software
con otros elementos del sistema y establece las restricciones que debe cumplir el software.

Figura 4. Anlisis como puente entre la ingeniera y el diseo de software [Pre02].

El anlisis de requerimintos del software puede dividirse en cinco areas de esfuerzo: 1.
Reconocimiento del problema, 2. Evaluacin y sntesis, 3. Modelado, 4. Especificacin
y 5. Revisin. Inicialmente el anlisis estudia la especificacin del sistema o el SRS, si
existe alguna, Es importante entender el software en el contexto de un sistema y revisar
el mbito del software que se emple para la generar estimaciones de la planificacin.
Luego, se debe establecer la comunicacin para el anlisis de manera que nos garantice un
correcto reconocimiento del problema. El objetivo del anlisis es el reconocimietos de los
10

elementos bsicos del problema tal y como los percibe el cliente o usuario.

La evaluacin del problema y la sntesis de la solucin es la siguiente rea principal de

esfuerzo en el anlisis. El anlisis debe definir todos los objetos de datos observables
externamente, evaluar el flujo y contenido de la informacin, definir y elavorar las
funciones del software, entender el conportamiento del software en el contexto de
acontecimientos que afectan al sistema, establecer las caracterstiscas de la interfaz del
sistema y descubrir restricciones adicionales del diseo. Cada una de estas tareas sirve
para describir el problema de manera que se pueda sintetizar un enfoque o solucin global.

Por ejemplo, un mayorista de repuestos de automviles nesecita un sisterma de control

de inventario. El analista averigua que los problemas del sistema manual que se emplea
actualmente, algunos estos problemas son: incapacidad de obtener rpidamente el estado
de un repuesto; dos otres das de media para actualizar un archivo a base de tarjetas;
mltiples rdenes repetidas para el mismo vendedor debido a que no hay manera de asociar
a los vendedores con los repuestos, etc. Una ves que se han identificado los problemas, el
analista determina qu informacin va a producir el nuevo sistema y qu informacin se le
proporcionar al sistema. Por ejemplo, el cliente desea un informe diario que indique qu
piezas se han tomado del inventario y cuntas piezas similares quedan. El cliente indica
que los encargados del inventario registrarn el nmero de identificacin de cada pieza
cuando salga del inventario.

Una vez evaluados los problemas actuales y la informacin deseada, entradas y salidas,
el analista empieza a sintetizar una o ms soluciones. Para empezar se definen en
detalle los datos, las funciones de tratamiento y el comportamiento del sistema. Una
vez que se ha establecido esta informacin, se consideran las arquitecturas bsicas para
la implementacin. Un enfoque Clente/Servideor parecera apropiada. Parece que sera
necesario un sistema de gestin de bases de datos, pero, est justificada la necesidad
de asociacin del cliente? El proceso de evaluacin y sintesis contina hasta que ambos,
el analista y el cliente ,se sienten seguros de que se puede especificar adecuadamente el
software para posteriores fases del desarrollo.

Durante la actividad de evaluacin y sntesis de la solucin, el analista crea modelos del

sistema en un esfuerzo de entender mejor el flujo de datos y de control, el tratamiento
11

funcional y el comportamiento operativo y el contenido de la informacin. El modelo

sirve como fundamento para el diseo del software y como base para la creacin de una
especificacin del software [Pre02a].
En esta fase la documentacin de basa en una serie de artefactos donde los principales son:
Modelo concepcual o de Dominio, Diagramas de secuencia, Diagramas de Caso de Uso y
los Contratos [Lar99]. En la Fig. 5. podemos ver un ejemplo de cada uno de los artefactos.

Figura 5. Artefactos de la etapa de anlisis. [Lar99].

Una descripcin ms detallada de estos se puede encontrar diversa literatura sobre UML
destacando, UML y patrones, introduccin al anlisis y diseo orientado a objetos, de
Craig Larman.

2.2.3.

Diseo

Durante este paso se logra una solucin lgica, su esencia es la elaboracin de diagramas
de interaccin, que muestran graficamente como los objetos se comunicaran entre ellos a
fin de cumplir con los requicitos [Lar99a].

Un diseo de software es una descripcin de la estructura del software que se va a

implementar, los datos que son parte del sistema, las interfaces entre los componentes
del sistema y algunas veses los algoritmos utilizados.

12

El proceso de diseo puede implicar el desarrollo de varios modelos del sistema con
diferentes niveles de abstraccin. Mientras se descompone un diseo, se descubren errores
y omisiones de etapas previas. Esta retroalimentacin permite mejorar los modelos de
diseo previo. La Fig. 6 es un modelo de este proceso que muestra las descripciones de
diseo que pueden producir en varias etapas de diseo. Este diagrama suguiere que las
etapas son secuenciales, en realidad, las actividades del proceso de diseo se entrelazan.
El resultado final del proceso son especificaciones precisas de los algoritmos y estructuras
de datos a implementarse.

Figura 6. Un modelo general del proceso de diseo. [Som05b].

Las actividades especficas del procesode diseo son:
Diseo Arquitectnico: Los grandes sistemas siempre se descomponen en subsistemas
que proporcionan algn conjunto de servicios relacionados. El proceso de diseo
inicial que identifica estos subsistemas y establece un marco para el control y
comunicacin de los subsistemas se llama diseo arquitectnico. El resultado de
este proceso de diseo es una descripcin de la arquitectura de software.
Especificacin Abstracta: Para cada subsistema se produce una especificacin abstracta
de sus servicios y las restrecciones bajo las cuales debe funcionar.
Diseo de Interfaz: Para cada subsistema se disea y documenta su interfaz con otros
subsistemas. Esta especificaciones de la interfaz debe ser inequvoca ya que permite
que el subsistema se utilice sin conocimiento de su funcionamiento.
Diseo de Componentes: Se asignan servicios a los componentes y se disean sus
interfaces.

13

Diseo de la Estructura de Datos: Se disea en detalle y especifica la estructura de

datos utilizada en la implementacin del sistema.
Diseo de Algoritmos: Se disean en detalle y especifican los algoritmos utilizados para
proporcionar los servicios
ste es un modelo general del proceso de diseo, y los procesos reales y prcticos pueden
adaptarlo de diversas maneras. He aqu algunas posibles adaptaciones:
1. Las dos ultimas etapas, diseo de la estructura de datos y de algoritmos, se pueden
retrasar hasta la etapa de implementacin.
2. Si se utiliza un enfoque exploratorio de diseo las interfaces del sistema se pueden
disear despues de que se especifiquen las estructutras de datos.
3. Se puede omitir la etapa de especificacin abstracta, aunque normalmente es una
parte fundamental del diseo de sistemas crticos.
Cada vez ms, cuando se utilizan mtodos giles de desarrollo, las salidas del proceso de
diseo no seran documentos de especificacin separados, sino que estarn representadas en
el cdigo del programa. Una vez diseada la arquitectira del sistema, las etapas posteriores
del diseo son incrementales. Cada incremento se representa como cdigo del programa
en ves de como modelo de diseo.

Lo contrario a este enfoque es dado por los mtodos estructurados que se basan en la
produccin de modelos graficos del sistema y, en muchos casos, cdigo automticamente
generado desde estos modelos.

Un mtodo estructurado incluye un modelo del proceso de diseo, notaciones para

representar el diseo, formatos de informes, reglas y pautas de diseo. los mtodos
estructurados pueden ayudar a alguno o a la totalidad de los siguientes modelos de un
sistema:
1. Un modelo de objetos que muestre las clases de objetos utilizada en el sistema y sus
dependencias.
2. Un modelo de secuencia que muestra cmo interactan los objetos en el sistema
cuando ste se ejecuta.
14

3. Un modelo del estado de transicin que muestra los estados del sistema y los
disparadores de las transiciones desde un estado a otro.
4. Un modelo estructural en el cual se documentan los componentes del sistema y sus
agregaciones.
5. Un modelo de flujo de datos en el que el sistema se modela utilizando la
transfomacin de los datos que tiene lugar cuando se procesan. ste no se
utiliza normalmente en los mtodos orientados a objetos, pero todava se utiliza
frecuentemente en el diseo de sistemas de tiempo real y de negocio.
En la prctica, estos mtodos estructurados son realmente notaciones estndar que
comprenden prcticas aceptables.

Los estudios empricos de los diseadores Bansler y Bodker [Ban93], muestran que stos
raramente siguen los mtodos convencionales, seleccionan y eligen de las pautas segn
circunstancias locales.
2.2.4.

Implementacin

Durante esta etapa se realizan las tareas que comnmente se conocen como programacin;
que consiste, esencialmente, en llevar a cdigo fuente, en el lenguaje de programacin
elegido, todo lo diseado en la fase anterior.

Esta tarea la realiza el programador, siguiendo por completo los lineamientos impuestos
en el diseo y en consideracin siempre a los requisitos especificados en la primera etapa.

Es comn pensar que la etapa de programacin o codificacin, algunos la llaman

implementacin, es la que consume la mayor parte del trabajo de desarrollo del software;
sin embargo, esto puede ser relativo, y generalmente aplicable a sistemas de pequeo porte,
ya que las etapas previas son cruciales, crticas y pueden llevar bastante ms tiempo.
Se suele hacer estimaciones de un 30 % del tiempo total insumido en la programacin,
pero esta cifra no es consistente ya que depende en gran medida de las caractersticas del
sistema, su complejidad y el lenguaje de programacin elegido. En tanto menor es el nivel
del lenguaje mayor ser el tiempo de programacin requerido, as por ejemplo se tardara
ms tiempo en codificar un algoritmo en lenguaje ensamblador que el mismo programado

15

en lenguaje C.

Mientras se programa la aplicacin, sistema, o software en general, se realizan tambin

tareas de depuracin, esto es la labor de ir liberando al cdigo de los errores factibles de
ser hallados en esta fase, de semntica, sintctica y lgica. Hay una suerte de solapamiento
con la fase siguiente, ya que para depurar la lgica es necesario realizar pruebas unitarias,
normalmente con datos de prueba; claro es que no todos los errores sern encontrados
slo en la etapa de programacin, habrn otros que se encontrarn durante las etapas
subsiguientes. La aparicin de algn error funcional, mala respuesta a los requisitos,
eventualmente puede llevar a retornar a la fase de diseo antes de continuar la codificacin.
2.2.5.

Pruebas

Las Pruebas del software son un elemento crtico para la garantia de la calidad del software
y representa una revisin final de las especificaciones, del diseo y la codificacin.
La creciente percepcin del software como un elemento del sistema y la importancia de
los costos asociados a un fallo del propio sistema, estn motivando la creacin de pruebas
minuciosas y bien planificadas. No es raro que una organizacin de desarrollo de software
emplee entre el 30 y el 40 por ciento del esfuerzo total de un proyectoen las pruebas.
En casos extremos, las pruebas del software para actividades crticas como por ejemplo
control de trfico areo, control de reactores nucleares, entre otras, puede costar de tres a
cinco veses ms que el resto de los pasos de la ingeniera del software juntos [Pre02b].

El libro sobre pruebas del software, Glen Myers [Mye11] establece algunas normas que
pueden servir acertadamente como objetivos de las pruebas:
1. Las Pruebas es el proceso de ejecucin de un programa con la intencin de descubrir
un error.
2. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error
no descubierto hasta entonces.
3. Una prueba tiene xito si descubre un error no destectado hasta entonces.
Los objetivos anteriores suponen un cambio dramtico de punto de vista. Nos quita la idea
que, normalmente, tenemos de que una prueba tiene xito si no descubre errores.

16

Nuestro objetivo es disear pruebas que sistemticamente saque a la luz diferentes clases
de errores, hacindolo con la menor cantidad de tiempo y de esfuerzo.

Si la prueba se lleva a cabo con xito, deacuerdo con el objetivo anteriormente establecido,
descubrir errores en el software. Como ventaja secundaria, la prueba demuestra hasta qu
punto las funciones del software parecen funcionar de acuerdo con las especificaciones y
parecen alcanzarse los requisitos de rendimineto. Adems, los datos que se van recogiendo
a medida que se desarrolla la prueba proporcionan una buena indicacin de la fiabilidad del
software y, de alguna manera, indica la calidad del software como un todo. Pero, la prueba
no puede asegurar la ausencia de defectos; slo puede demostrar que existen defectos en
el software.

Para aplicar mejor los metodos de diseo de casos de prueba se requiere comprender
los principios bsicos que guan las pruebas de software. Davis propone un conjunto de
principios de los cuales describiremos un pequeo subconjunto, para major informacion
sobre estos principios, vea [Dav95].

A todas las pruebas se les debera poder hacer un seguimiento hasta los requisitos
del cliente. Como hemos visto, el objetivo de las pruebas del software es descubrir
errores. Se entiende que los defectos ms graves, desde el punto de vista del cliente,
son aquellos que impiden al programa cumplir sus requisitos.
Las Pruebas deberan planificarse mucho antes de que empiecen. La planificacin
de las pruebas pueden empezar tan pronto como est completo el modelo de
requisitos. La definicin detallada de los casos de prueba pueden empezar tan pronto
como el modelo de diseo se ha consolidado. Por tanto, se puede planificar y disear
todas las pruebas antes de generar ningn cdigo.
El Principio de Pareto es aplicable a la prueba del software. Dicho de manera
sencilla, el principio de Pareto implica que al 80 % de todos los errores descubiertos
durante las pruebas se les puede hacer un seguimiento hasta un 20 % de todos
los mdulos del programa. El problema, por supuesto, es aislar estos mdulos
sospechosos y probarlos minuciosamente.
Las pruebas deberan empezar por, lo pequeo, y progresar hacia, lo grande.
Las primeras pruebas planeadas y ejecutadas se centran generalmente en mdulos
17

individuales del programa. A medida que avanzab las pruebas, desplazan su punto
de mira en un intento de encontrar errores en grupos integrados de mdulos y
finalmente en el sistema entero.
No son posibles las pruebas exhaustivas. El nmero de permuntaciones de caminos
para incluso un programa de tamao moderado es excepcionalmente grande. Por
este motivo, es imposible ejecutar todas las combinaciones de caminos durante las
pruebas. Es posible, sin embargo , cubrir adecuadamente la lgica del programa
y asegurarse de que se han aplicado toda las condiciones en el diseo a nivel de
componente.
Para ser ms eficaces, las pruebas debern ser realizadas por un equipo
independiente. Por, ms eficiente, queremos referirnos a pruebas con la ms alta
probabilidad de encontrar errores, el objetivo principal de las pruebas. Por las
razones que se expucieron anteriormente, el ingeniero del software que cre el
sistema no es el ms adecuado para llevar a cabo las pruebas de software.
El principal objetivo del diseo de casos de prueba es obtener un conjunto de pruebas que
tengan la mayor probabilidad de descubrir los defectos del software. Para llevar a cabo
este objetivo, se usan dos categoras diferentes de tcnicas de diseo de casos de prueba:
prueba de caja blanca y prueba de caja negra.

Las pruebas de caja blanca se centran en la estructura de control del programa. Se obtienen
casos de prueba que aseguren que durante la prueba se han ejecutado, por lo menos una
vez, todas las sentencias del programa y que se ejercitan todas las condiciones lgicas. La
prueba del camino bsico, una tcnica de caja blanca, hace uso de grafos de programa, o
matrices de grafos, para obtener el conjunto de pruebas linealmente independientes que
aseguren la total cobertura. La prueba de condiciones y del flujo de datos ejercita ms
an la lgica del programa y la prueba de los bucles complementa a otras tcnicas de
caja blanca, proporcionando un procedimiento para ejercitar bucles de distintos grados de
complejidad.

Heztel [Het88] describe la prueba de caja blanca como, prueba a pequea escala. Esto se
debe a que las pruebas de caja blanca que hemos considerado son tpicamente aplicadas
a pequeos componentes de programas, por ejemplo; mdulos o pequeos grupos de
mdulos. Por otro lado, la prueba de caja negra ampla el enfoque y se puede denominar,
18

prueba a gran escala.

Las pruebas de caja negra son diseadas para validar los requisitos funcionales sin fijarse
en el funcionamiento interno de un programa. Las tcnicas de prueba de caja negra se
centran en el mbito de informacin de un programa, de forma que se proporcione una
cobertura completa de prueba. Los mtodos de prueba basados en grafos exploran las
relaciones entre los objetos del programa y su comportamiento. La particin equivalente
divide el campo de entrada en clases de datos que tienden a ejercitar determinadas
funciones del software. El anlisis de valores lmite prueba la habilidad del programa para
manejar datos que se encuentran en los lmites aceptables. La prueba de la tabla ortogonal
suministra un mtodo sistemtico y eficiente para probar sistemas con un nmero reducido
de parmetros de entrada. Los mtodos de prueba especializados comprenden una amplia
gama de capacidades del software y reas de aplicacin. Las interfaces grficas de usuario,
las arquitecturas la documentacin y facilidades de ayuda, y los sistemas de tiempo real
requieren directrices y tcnicas especializadas para la prueba del software.

A menudo, los desarrolladores de software experimentado dicen que, la prueba nunca

termina, simplemente se transfiere de usted, del ingeniero del software, al cliente: Cada
vez que el cliente usa el programa, lleva a cabo una prueba. Aplicando el diseo de casos
de prueba, el ingeniero del software puede conseguir una prueba ms completa y descubrir
y corregir as el mayor nmero de errores antes de que comiencen las pruebas del cliente.

2.2.6.

Produccin y Mantenimiento

La instalacin del software es el proceso por el cual los programas desarrollados

son transferidos apropiadamente al computador destino, inicializados, y, eventualmente,
configurados; todo ello con el propsito de ser ya utilizados por el usuario final. Constituye
la etapa final en el desarrollo propiamente dicho del software. Luego de sta el producto
entrar en la fase de funcionamiento y produccin, para el que fuera diseado.

La instalacin, dependiendo del sistema desarrollado, puede consistir en una simple

copia al disco rgido destino,casos raros actualmente; o bien, ms comnmente, con una
de complejidad intermedia en la que los distintos archivos componentes del software,
ejecutables, bibliotecas, datos propios, etc; son descomprimidos y copiados a lugares
19

especficos preestablecidos del disco; incluso se crean vnculos con otros productos,
adems del propio sistema operativo. Este ltimo caso, comnmente es un proceso
bastante automtico que es creado y guiado con heramientas software especficas.

Una vez realizada exitosamente la instalacin del software, el mismo pasa a la fase de
produccin, durante la cual cumple las funciones para las que fue desarrollado, es decir,
es finalmente utilizado por el usuario final, produciendo los resultados esperados.

Por otro lado el mantenimiento de software es el proceso de control, mejora y optimizacin

del software ya desarrollado e instalado, que tambin incluye depuracin de errores y
defectos que puedan haberse filtrado de la fase de pruebas. Esta fase es la ltima, segn
el modelo empleado, que se aplica al ciclo de vida del desarrollo de software. La fase de
mantenimiento es la que viene despus de que el software est operativo y en produccin.

De un buen diseo y documentacin del desarrollo depender cmo ser la fase de

mantenimiento, tanto en costo temporal como monetario. Modificaciones realizadas a un
software que fue elaborado con una documentacin indebida o pobre y mal diseo puede
llegar a ser tanto o ms costosa que desarrollar el software desde el inicio. Por ello, es de
fundamental importancia respetar debidamente todas las tareas de las fases del desarrollo
y mantener adecuada y completa la documentacin.

La fase de mantenimiento se centra en el cambio que va asociado a la correccin de errores,

a las adaptaciones requeridas a medida que evoluciona el entorno del software y a cambios
debidos a las mejoras producidas por los requisitos cambiantes del cliente. Durante la fase
de mantenimiento se encuentran cuatro tipos de cambios [Pre02c]:
Correctivo: Incluso llevando a cabo las mejores actividades de garanta de calidad, es
muy probable que el cliente descubra los defectos en el software. El mantenimiento
correctivo cambia el software para corregir los defectos.
Adaptativo: Con el paso del tiempo, es probable que cambie el entorno original, por
ejemplo: CPU, el sistema operativo, lenguaje informtico con el que se ha escrito
la aplicacin o del framework, las reglas de empresa, las caractersticas externas
de productos, para el que se desarroll el software. El mantenimiento adaptativo
produce modificacin en el software para acomodarlo a los cambios de su entorno
20

externo.
Evolutivo: Son los que ms acercan al desarrollo de nuevas funcionalidades, pero con
una gran diferencia: se enfocan en la evolucin de una funcionalidad de software
existente. Dicha evolucin, generalmente se centra en agregar a una funcionalidad
existente, por ejemplo, a la funcionalidad de generacin de cdigos de barra del
sistema de control de stock, una o ms caractersticas adicionales, tendientes a
enriquecer dicha funcionalidad, por ejemplo, que la emisin de cdigos de barra,
guarde un log de cdigos de barra emitidos, que se sume a los reportes de los
productos.
Preventivo: El software de computadora se deteriora debido al cambio, y por esto
el mantenimiento preventivo tambin llamado reingeniera del software, se debe
conducir a permitir que el software sirva para las necesidades de los usuarios
finales. En esencia, el mantenimiento preventivo hace cambios en programas de
computadora a fin de que se puedan corregir, adaptar y mejorar ms fcilmente.

2.3.

Framework

2.4.

IEEE 802.15.4

IEEE 802.15.4 es un estndar que especifica la capa fsica y el control de acceso para redes
inalmbricas de rea personal de baja velocidad (LR-WPAN). Este estndar fue definido
el ao 2003 por el grupo de trabajo IEEE 802.15 [Iee10], revisndose a lo largo del tiempo
en los aos 2006, 2007, 2009 y 2011 [Iee11a].

As, se especifican los niveles de red bsicos para dar servicio a redes inalmbricas de
rea personal o WPAN (Wireless Personal Area Networks), cuyo principal uso radica en
aplicaciones de monitoreo en dispositivos embebidos de bajo costo, reducido consumo de
energa y bajo uso del ancho de banda siendo estos utilizados, por ejemplo, en redes de
sensores inalmbricos o WSN (Wireless Sensor Networks) [Fra11].

La especificacin inicial concede comunicacin a 10 metros de distancia a 250 KB/s,

siendo estas especificaciones reducidas a cambio de ms distancia y/o un consumo
energtico menor, ya que como se menciona anteriormente, el objetivo final de este
estndar es conseguir un costo reducido de manufactura y de operacin, sin sacrificar
flexibilidad. Un ejemplo de esto, son los dispositivos de radio de la familia XBee [Dig14a],
21

los cuales tienen distancias desde algunos metros hasta kilmetros, todo bajo el estndar
IEEE 802.15.4 u otros protocolos que funcionan sobre el.

Este estndar define tres tipos de nodos que se pueden comunicar mediante dos topologas
de red distintas. Los nodos pueden ser del tipo FFD (Full Function Device), los cuales
pueden comportarse tanto como un enrutador de red que canaliza informacin desde
otros nodos, como tambin puede comportarse como un nodo final ordinario, siendo estos
ltimos denominados RFD (Reduced Function Device). Cuando este tipo de nodo es el
encargado de enrutar el trfico de toda la red, pasa a denominarse PAN coordinator. Las
topologas disponibles son del tipo estrella y del tipo punto a punto, profundizndose en
estas mas adelante en el captulo cinco.

2.5.

Redes inalmbricas de sensores

Se denomina red inalmbrica de sensores a un conjunto de dispositivos autnomos

distribuidos en el espacio, que monitorean condiciones del entorno que los rodea, como
puede ser su ubicacin, temperatura, sonido, presin, entre otras, y que la informacin
obtenida sea recolectada, enviada a travs de algn tipo de red, siendo esta finalmente
almacenada en una ubicacin especifica, generalmente remota [Chi09].

Si bien los inicios de estas redes estn documentados para aplicaciones militares,
actualmente se utilizan en innumerables mbitos, siendo las ms importantes los
industriales para monitorear maquinarias, en geoposicionamiento vehicular, medicina a
distancia, por nombrar algunos ejemplos [Lew04].

Una red inalmbrica de sensores se compone de nodos de sensores, nodos coordinadores

y equipos centrales.

Un nodo sensor es un dispositivo ubicado en el extremo de esas redes, que posee cierta
capacidad de proceso y de memoria, capaz de recolectar informacin con los sensores que
posee y que puede enviar esta informacin para su almacenamiento en un equipo remoto.
Un esquema de su composicin se puede apreciar en la Figura 2.

22

Figura 7. Componentes de un nodo de sensores [Aky13].

Estos nodos sensores, dependiendo de la topologa de red utilizada, envan su informacin
a nodos coordinadores, tambin conocidos como gateways. Y finalmente este conjunto de
nodos coordinadores se conectan por algn medio de red a uno o mas equipos centrales,
que son los encargados de almacenar los datos obtenidos de toda la red. La composicin
completa de este tipo de red se puede apreciar en la Figura 3.

Figura 8. Red inalmbrica de sensores y servicios relacionados [Ind].

Otras caractersticas de esta red a considerar en los nodos sensores son sus limitaciones
de consumo energtico en sus nodos, dependiendo muchas veces de bateras o incluso con
la necesidad de obtener o generar su propia energa. Esta problemtica ademas genera
la necesidad que estas redes deban soportar fallas o perdidas de sus nodos. Ademas,
dependiendo del entorno, sus nodos deben ser capaces de resistir condiciones ambientales
desfavorables como humedad, polvo, agua, entre otras.

23

Superadas sus limitaciones, estas redes permiten una amplia gama de aplicaciones en
reas tales como la automatizacin del hogar, edificios, maquinaria industrial, ciudades
inteligentes, monitoreo del estado de salud de personas y animales, gestin de energa,
transporte, seguridad, entre muchas otras.

2.6.

Internet de las cosas

El Internet de las cosas es un concepto que nace en la creciente capacidad de diversos

dispositivos cotidianos de conectarse a Internet, ofreciendo nuevas funcionalidades. Este
trmino fue acuado por primera vez en 1999 por Kevin Ashton [Rfi09], aunque la idea
general se comienza a gestar desde 1991 [Mat10].

Al no existir un estndar definido para identificar este concepto, existen diversas

concepciones de esta. La IEEE1 lo define de la siguiente forma: El Internet de las cosas
es un sistema adaptativo y autoconfigurable, el cual consta de redes de sensores y objetos
inteligentes cuyo propsito es interconectar todas las cosas, desde objetos del da a da
hasta maquinaria industrial, de una manera tal de hacerlos inteligentes, programables y
ms capaces de interaccionar con los humanos. [Iee14].

Mientras que para Cisco Internet Business Solutions Group, el gigante mundial en
infraestructura de red, lo define como simplemente es el punto en el tiempo donde
comenzaron a haber ms cosas u objetos conectadas a Internet que personas [Cis11].

Como se puede apreciar en ambas definiciones, existe en comn la visin de conectar a

Internet objetos de toda ndole, lo que ha ocurrido vertiginosamente en estos ltimos aos,
donde se le ha brindado conectividad a artefactos que nunca la tuvieron.

Tambin, el Internet de las cosas se puede entender como una nueva capa en la forma
y cantidad de dispositivos que conforman la red Internet. Tradicionalmente, se ha
considerado que el Internet est compuesta de las redes y equipos que hacen posible
la interconexin de estas, siendo llamada core Internet, y de una capa exterior de
infraestructura de red local, computadores de escritorio y porttiles llamada en ocasiones
1

Institute of Electrical and Electronics Engineers. Mas informacin en http://www.ieee.org/

index.html.

24

fringe Internet [She09]. El Internet de las cosas sera una tercera capa, donde se encuentran
una vasta cantidad de dispositivos con capacidades y dimensiones menores a los existentes
en la capa anterior, pero con un costo muy reducido y con un objetivo especfico.

La Figura 4 muestra esta visin del Internet de las cosas, donde se est dando el paso
desde la fringe Internet tradicional hacia el Internet de las cosas, y sus aplicaciones ms
conocidas.

Figura 9. Internet de las cosas [She09].

En el contexto, el Internet de las cosas se refiere adems a la conexin de pequeos
dispositivos para monitorear y conocer el estado o condicin del ambiente o de un sistema
en particular, como puede ser la temperatura de un saln, la velocidad de un camin,
etc. Por lo tanto, las redes inalmbricas de sensores que poseen acceso a Internet son las
principales protagonistas del Internet de las cosas.

Todos estos elementos tienen como objetivo la posibilidad de crear entornos, dispositivos
y objetos inteligentes, facilitando su integracin a la vida de las personas. Esto conduce
a mejoras sustanciales de la poblacin, utilizando como ejemplo sus aplicaciones en el
clima, alimentacin, energa, movilidad, sociedad digital, salud, entre otros.

25

2.6.1.

Big Data

La informacin generada por este nuevo paradigma y la pltora de dispositivos conectados

obteniendo informacin, hace necesario considerar el concepto de Big Data. Big Data
es un trmino general para la coleccin de sets de datos tan grande y compleja que se
vuelve difcil su almacenamiento, proceso e interpretacin. Considerando que la capacidad
para guardar informacin per capita se dobla aproximadamente cada 40 meses desde
alrededor de 1980 [Hil11], es una problemtica a considerar dado que la explosin de
estos dispositivos es relativamente reciente.

Big Data es difcil de abordar para la mayora de las bases de datos relacionales y
sus paquetes de visualizacin de datos relacionados, requiriendo software masivamente
paralelo, corriendo en cientos o miles de servidores [Jac09]. Un ejemplo de la cantidad
de datos que se puede obtener en estos contextos es la red de sensores implementada en
el Large Hadron Collider ubicado en Suiza, que contiene 150 millones de sensores
enviando datos 40 millones de veces por segundo. Bajo diversos criterios se descarta el
99,999 % de estos datos por no ser de inters cientfico, lo que significa que existen 100
colisiones de inters por segundo [Lhc08]. Aun as, los datos almacenados alcanzan los
25 PetaBytes anuales sin replicacin ni respaldo, resultando finalmente en 200 PetaBytes
anuales de datos replicados y respaldados. Si se llegara a almacenar toda la informacin
de todos los sensores, se alcanzaran 150 millones de PetaBytes anuales. Poniendo este
numero en perspectiva, para almacenar solo un PetaByte de informacin seria necesario
contar con 150 mil millones de discos duros de 1 TeraByte, lo que supera a todo el
almacenamiento existente en la actualidad en el planeta.

En el contexto del proyecto, otro ejemplo a considerar por el lado de los dispositivos
mviles y su presencia y crecimiento, es que el primer iPhone, fue lanzado el 2007 y
los primeros telfonos inteligentes con sistema operativo Android fueron lanzados el ao
2008, y que solo el ao 2013 se vendieron cerca de mil millones de dispositivos [Gar14],
y la Figura 5 muestra que esta tendencia est lejos de terminar.

26

Figura 10. Crecimiento y prediccin futura de envos de dispositivos mviles [Eng12].

Respecto a las redes de sensores utilizadas en entornos similares al del proyecto, un
sistema de identificacin bovina basado en RFID producida por la start-up holandesa
Sparked2 , genera alrededor de 200 MegaBytes de informacin al ao por cada animal
ingresado al sistema [Eco10], por lo que a gran escala se pueden generar sets de datos lo
suficientemente grandes para requerir tcnicas de almacenamiento y manejo de estos bajo
tecnologa Big Data.

2.7.

Dispositivos mviles

Un dispositivo mvil (tambin conocidos anteriormente como handheld) es un pequeo y

manipulable dispositivo computacional, contando tpicamente con una pantalla tctil para
su manipulacin. Algunos de la gran cantidad de fabricantes que construyen estos equipos
son las compaas Samsung, LG, Motorola, Nokia, HTC, Apple, entre otros.

Estos dispositivos por lo general poseen un sistema operativo [Int13], siendo este capaz
de ejecutar varios tipos de aplicaciones de software, ms conocidas como apps. Muchos
de estos dispositivos estn equipados con tecnologas Wi-Fi3 , Bluetooth4 y GPS5 que los
habilitan a conectarse a otros dispositivos, a Internet y a obtener su posicin cuando
lo necesiten. Tambin es usual encontrar cmaras para capturar fotografas o video,
reproductores de medios, entre otras funcionalidades. Estos dispositivos se denominan
generalmente en la actualidad como telfonos inteligentes o Smartphones [Pcm].
2

http://hello.sparked.com/
Marca comercial de productos basados en el protocolo IEEE 802.11.
4
Tecnologa inalmbrica para transferencia de datos a corta distancia bajo estndar IEEE 802.15.1.
5
Global Positioning System. Mas informacin en http://www8.garmin.com/aboutGPS/.
3

27

A estos dispositivos, que por lo general caben en la palma de la mano, a mediados del 2010
con el lanzamiento del iPad [App10] se les unieron unos dispositivos ms grandes pero
similares, llamados comnmente Tablets [Tec11]. Su uso por lo general es muy similar a
los telfonos inteligentes, diferencindose unicamente en el aspecto fsico ya mencionado.

Estos dispositivos son populares entre las personas que desean tener muchas de las
funcionalidades de un computador convencional en ambientes donde utilizar uno puede
no ser practico, por ejemplo para obtener informacin rpidamente mientras el usuario
se desplaza, o si le fuera necesario realizar trabajo en lugares donde un computador
convencional no puede soportar las condiciones ambientales, como por ejemplo trabajo
en terreno.

Todos estos dispositivos sufren de diversas limitaciones, como el consumo de energa y el

uso de una batera de capacidad limitada, la existencia de redes inalmbricas que soporten
la comunicacin de estos dispositivos, riesgos a la salud al interferir con actividades
cotidianas como lo es el manejo de vehculos [Nht14] y limitaciones ergonmicas en el
uso de estos dispositivos, dado su tamao.

En la actualidad, la mayora de estos dispositivos pertenecen a un ecosistema de software,

que se define como un conjunto de aplicaciones y servicios que se relacionan entre ellos.
Esta relacin se encuentra generalmente ligada a una plataforma comn, que opera a travs
del intercambio de informacin, recursos y artefactos [Bos09].

Los ecosistemas de software en los dispositivos mviles ms importantes son propiedad

de Google6 y Apple7 , basados en los sistemas operativos Android e iOS respectivamente,
donde la suma de ambas participaciones de mercado supera el 90 % [Tec14], obteniendo
Android un porcentaje aproximado de un 80 %. Al ser la plataforma propiedad de Google
la mas popular a nivel global, se profundizar en ella.

6
7

https://www.google.com/intl/es-419/about/
http://www.apple.com/es/

28

2.7.1.

Android

Android es un sistema operativo con una interfaz de usuario basada en la manipulacin

directa por pantalla tctil, diseado para telfonos inteligentes y tablets. El sistema
operativo utiliza el ingreso tactil para simular acciones del mundo real, como arrastrar,
pinchar y presionar para manipular objetos en pantalla, como por ejemplo presionar teclas
en un teclado virtual. A pesar de ser diseado principalmente para su manejo tctil,
tambin es usado en televisores, consolas de juegos, camaras digitales y otros dispositivos.

Desde el ao 2011 Android tiene la mayor cantidad de instalaciones en dispositivos

mviles, y desde el 2013 estos dispositivos se venden mas que todos sus competidores
combinados [Bus14]. En julio del mismo ao su tienda de aplicaciones, Google Play,
alcanzo el milln de aplicaciones publicadas, y mas de 50 mil millones de aplicaciones
descargadas [Pho13]. Una encuesta de desarrolladores realizada entre abril y mayo del
2013 concluy que el 71 % de los desarrolladores de aplicaciones mviles desarrolla para
Android [Dev13].

El 5 de noviembre del 2007 se anunci la creacin de la Open Handset Alliance [Ope07],

un consorcio de compaas tecnolgicas en bsqueda de desarrollar estndares abiertos
para dispositivos mviles. En la Tabla 1 se pueden apreciar las versiones de Android a las
que Google brinda soporte en la actualidad, su nombre clave, su fecha de lanzamiento y
penetracin de mercado en el total de dispositivos al 1 de junio del 2014.

Tabla 1. Versiones de Android soportadas por Google en la actualidad [And14a].

Versin

Nombre Clave

Fecha de
lanzamiento

Distribucin

4.4

KitKat

31 de Octubre, 2013

13.6 %

4.3

Jelly Bean

24 de Julio, 2013

10.3 %

4.2

Jelly Bean

13 de Noviembre, 2012

19.1 %

4.1

Jelly Bean

9 de Julio, 2012

29.0 %

4.0.3 - 4.0.4

Ice Cream Sandwich

16 de Diciembre, 2011

12.3 %

2.3.3 - 2.3.7

Gingerbread

9 de Febrero, 2011

14.9 %

2.2

Froyo

20 de Mayo, 2010

0.8 %

29

En cuanto al desarrollo de aplicaciones de Android, esta se realiza en el lenguaje de

programacin Java, utilizando el Android Software Developer Kit [And14b] (Android
SDK en adelante), aunque tambin existen otras herramientas.

Android SDK es un conjunto de herramientas de desarrollo de aplicaciones para Android.

Esta incluye un debugger, libreras, un emulador de dispositivo, documentacin, cdigo
de ejemplo y tutoriales para apoyar el desarrollo, ademas de incluir en la actualidad el
entorno de desarrollo integrado Eclipse. Estas herramientas se pueden utilizar en sistemas
basados en Microsoft Windows, Mac OSX y Linux.

Google apoya activamente el desarrollo de aplicaciones para su plataforma y comercializa

tambin dispositivos de desarrollo, los cuales vienen completamente libres para instalar
aplicaciones que se encuentren en desarrollo, llamndose esta familia de dispositivos
Nexus [Goo14a].

2.8.

Estado del arte

Llegado este punto, es pertinente revisar las implementaciones de sistemas similares al

que se pretende desarrollar en el proyecto, as como soluciones de hardware y software
que contribuyan de forma parcial a su desarrollo.

El anlisis de estos software y hardware relacionados no son de la totalidad de sus

funciones, sino que se revisan las caractersticas principales y las que a juicio del alumno
son relevantes para considerarlas un aporte al proyecto.

Adems, se realiza un anlisis a la normativa nacional con respecto a la produccin animal,

y si esta pudiera afectar de alguna forma el desarrollo del presente proyecto.

2.8.1.

Sistemas similares

Existen en la actualidad diversos sistemas de monitoreo y gestin animal en el mercado.

Sin embargo, hay muy pocos de estos sistemas diseados especficamente para ovinos, y
el alumno ha sido incapaz de encontrar un sistema que integre la gestin con el monitoreo
de los animales.

30

Para animales bovinos, se pueden encontrar mltiples sistemas de rastreo y deteccin de

celo, como el comercializado por Dairymac Limited llamado Track A Cow [Tra13], el cual
posee, entre otras, las siguientes funcionalidades:

Informacin en tiempo real - cada 4-6 minutos, 24/7/3658 .

Transmisin de radio en onda corta para largas distancias utilizando una poderosa
antena.
Avanzado acelermetro para obtener informacin de movimiento, descanso, etc.
Podmetros de tamao reducido, diseados para ser puestos en las patas o en el
cuello del animal.
Permite al usuario planear el da o la semana de inseminacin ideal con una precisa
deteccin del celo.
Software de gestin de la informacin recibida, el cual genera grficos, reportes,
entre otras funcionalidades.

Tambin existen diversas soluciones individuales de monitoreo de salud [Mas12] e

identificacin [Hid13].

Sin embargo, todas estas soluciones se encuentran especializadas para la produccin

bovina, resultando til solo las funcionalidades de estas como referencia para soluciones
dirigidas al rubro de los ovinos.

2.8.2.

Software relacionado

El alumno ha detectado la existencia de tres soluciones de software que se especializan en

facilitar la gestion de un predio productivo ovino.

Informacin recibida las 24 horas, los 7 das de la semana, los 365 das del ao.

31

2.8.2.1.

Sheep Tracker

Sheep Tracker, segn se define en su sitio web, es una Aplicacin de base de datos de
escritorio diseada para mantener registros detallados de salud, administracin y crianza
de ovejas [She13], no existiendo en su sitio web mayor informacin acerca de sus
desarrolladores. Esta aplicacin se encuentra basada en el framework Adobe AIR, por
lo que puede ser instalada en diversos sistemas operativos, como Windows, Mac OS X y
distribuciones GNU/Linux.

En la Figura 6 se puede apreciar el proceso utilizado en este software para agregar un

animal a la aplicacin, donde se deben ingresar los datos del animal en cuestin.

Figura 11. Ingreso de animal en Sheep Tracker.

Se puede apreciar adems, que se almacena informacin relevante respecto del animal
como su ubicacin, fechas de nacimiento o adquisicin, identificadores, raza, entre otras.
De esta forma, se pueden agregar una cantidad ilimitada de animales, cada uno con
distintas propiedades.

As, desde la pantalla principal de la aplicacin, se pueden visualizar todos los animales
en una lista, con toda su informacin. Tambien se pueden editar sus propiedades, agregar
observaciones y generar reportes. Esta pantalla se puede visualizar en la Figura 7.

32

Figura 12. Ventana principal de Sheep Tracker.

En cuanto a su licenciamiento, Sheep Tracker es un producto comercial, y el costo de la
licencia es de 19.95 dolares, utilizando el modelo de cdigo de activacin de licencia. No
se especifica la cantidad de equipos ni las activaciones mximas soportadas.

2.8.2.2.

EWEBYTE

EWEBYTE es una aplicacin comercial de escritorio cuya primera versin fue lanza a
finales de la dcada de los 80 Por productores para productores [Ewe13], bajo apoyo
de la Universidad de Guelph9 , ubicada en Ontario, Canad. La aplicacin facilita la
recoleccin de datos y la administracin de la produccin ovina, para luego consultar
estos datos de forma eficaz, teniendo la opcin de generar reportes.

Esta aplicacin se ha ido actualizando a travs del tiempo, siendo su ultima versin la 3.0.

Para el anlisis fue utilizada la versin 2.13 ya que es la ultima disponible en modo
de demostracin. Esta versin de prueba es muy limitada, ya que trae por defecto una
cantidad mxima de animales y solo permite agregar nuevos ovinos. En la Figura 8 se
puede apreciar la diversas opciones que posee la aplicacin para ingresar informacin.
9

http://www.uoguelph.ca/

33

Figura 13. Ventana principal de EWEBYTE y men de ingreso de datos.

Utilizando el men contextual mostrado en la Figura 8, se puede ingresar un nuevo ovino
a la aplicacin. Este ingreso se puede apreciar en la Figura 9, destacando la cantidad de
informacin que es posible almacenar del animal en cuestin.

Figura 14. Ingreso de nuevo ovino en EWEBYTE.

En cuanto a su licenciamiento, EWEBYTE posee varios niveles de precios. Para la
versin 3.0 ms un ao de soporte telefnico, el costo de la licencia es de 400 dlares
estadounidenses o canadienses, mientras que si se compran tres o ms licencias el costo
de cada una desciende a 320 dlares. La versin 2.0 an se comercializa, bajo las mismas
condiciones que la versin 3.0, descendiendo el precio a 100 y 80 dlares respectivamente.
34

2.8.2.3.

Select Sheepware

Select Sheepware es parte de una familia de productos desarrollados por TGM Software
Solution Limited, una empresa que desarrolla soluciones de software especficamente para
la agricultura y ganadera, ubicada en Irlanda del Norte [Sel14].

Adems de proveer diversas soluciones de software, tambin lo hace para hardware de

identificacin animal mediante EIDs (Electronic Identification Device), acompaados de
dispositivos mviles para el trabajo en terreno.

En cuanto a su funcionamiento, esta es la nica aplicacin que implementa autentificacion

de usuario para su uso, como se puede apreciar en la Figura 10.

Figura 15. Nuevo usuario en Select Sheepware.

La aplicacin est diseada para mostrar la mayor cantidad de informacin posible en la
pantalla principal, organizando con colores diversas operaciones de la actividad productiva
ovina, como lo son la crianza, registros de animales, alimentacin y salud, administracin
e identificacin, entre otras. Esta organizacin se puede apreciar en la Figura 11. Tambin
es posible ver sus mltiples opciones de filtrado y ordenamiento.

35

Figura 16. Pantalla principal de Select Sheepware.

En cuanto a su licenciamiento, Select Sheepware es un software comercial pero gratuito,
ya que se puede pedir un cdigo de registro sin costo. Sin embargo, la integracin del
software con otros productos de la compaa podra significar una inversin futura.

2.8.3.

Hardware relacionado

El alumno ha detectado la existencia de dos plataformas de hardware con las cuales se

puede implementar una red inalmbrica de sensores.

2.8.3.1.

Arduino

Arduino es una plataforma de prototipado basada en hardware y software libre. Este

proyecto tiene sus inicios el ao 2005, en el instituto IVREA10 ubicado en la ciudad
homnima en Italia, en la bsqueda de reducir costos en la formacin de sus estudiantes
encontrndose el plantel en una crisis econmica [Iee11b].

10

http://interactionivrea.org/en/index.asp.

36

Actualmente es un proyecto muy utilizado en ambientes acadmicos, dada su sencillez

para darle funcionalidad con piezas de hardware complementarias y realizar una solucin
autnoma, sin necesidad de un computador, tales como sensores, dispositivos de red, entre
otros. Para el desarrollo, es habitual conectarlos al computador va USB para la carga de
cdigo.

Existen diversos medios de dispositivos Arduino, los cuales buscan adaptarse a mltiples
escenarios de desarrollo, consumo de energa, espacio, velocidad de procesamiento y
cantidad de memoria, entre otros.

El Arduino ms popular en el mercado es el modelo de tamao medio, llamndose la

ltima versin Arduino Uno, el cual se puede apreciar en la Figura 12.

Figura 17. Arduino Uno R3 [Ard14a].

La plataforma Arduino posee un lenguaje propio de programacin, basado en Wiring11 .
Este lenguaje se utiliza en el software de desarrollo Arduino, el cual se puede utilizar
en sistemas que utilicen Microsoft Windows, Mac OS X y diversas distribuciones de
GNU/Linux.

2.8.3.2.

Waspmote

Waspmote consiste en una plataforma de sensores inalmbricos de cdigo libre,

desarrollado por la start-up espaola Libelium [Lib14a], al detectar la necesidad de
generar una solucin de hardware superior a Arduino en el sentido del ahorro energtico
11

http://wiring.org.co/.

37

y de la certificacin de sus dispositivos de radio para su utilizacin en escenarios reales,

tales como ciudades, fabricas, casas, entre otras aplicaciones. Waspmote es una solucin
de hardware horizontal, modular y de cdigo abierto. Se pueden seleccionar diversas
combinaciones de sensores y equipos de radios, dependiendo de la aplicacin que le quiera
dar el usuario.

Waspmote promueve como sus principales caractersticas sus modos de ultra bajo
consumo, 60 tipos de sensores disponibles agrupados para distintos tipos de aplicaciones, y
ocho tecnologas de radio disponibles para larga, mediana y corta distancia. Un Waspmote
con un mdulo de radio UMTS12 + GPS se puede visualizar en la Figura 13.

Figura 18. Waspmote con modulo UMTS + GPS [Lib14a].

Como se ha mencionado anteriormente, Waspmote tiene un conjunto de sensores
agrupados segn la aplicacin que se le quiere dar, los cuales cubren las necesidades
de deteccin de gases, eventos de emergencia, estacionamiento inteligente de vehculos,
agricultura, cantidad de radiacin, entre otros. Los sensores de gases, estacionamiento
inteligente y de ciudades inteligentes se pueden apreciar respectivamente en la Figura 14.

Figura 19. Mdulos sensores para Waspmote [Sen13].

12

Universal Mobile Telecommunications System, mas informacin en http://www.3gpp.org/

technologies/keywords-acronyms/103-umts.

38

En cuanto al desarrollo, Waspmote cuenta con su propio entorno de desarrollo integrado, el

cual funciona en Microsoft Windows, Mac OS X y distribuciones GNU/Linux. El lenguaje
utilizado para el desarrollo es C++ principalmente, contando adems con una API de
cdigo abierto para sus mdulos y sensores.

Al tratarse de un producto comercial, el soporte de Waspmote es brindado directamente

por Libellium, contndose adems con abundante documentacin y ejemplos de cdigo.

Sobre el licenciamiento, Waspmote es una plataforma cerrada de hardware, as como

tambin lo son sus mdulos de sensores y de radios. Sin embargo todo el software
que utiliza y distribuye la empresa es de cdigo abierto, dando flexibilidad a los
desarrolladores.

2.8.4.

Marco regulatorio

La produccin animal se encuentra regulada por el Servicio Agrcola Ganadero13 (SAG

de aqu en adelante), siendo este el organismo oficial del Estado de Chile encargado de
apoyar el desarrollo de la agricultura, los bosques y la ganadera, a travs de la proteccin
y mejoramiento de la salud de los animales y vegetales [Sag14a].

El trabajo del SAG ha permitido que en los ltimos aos el pas haya logrado un lugar de
privilegio en los mercados internacionales, donde se comercializan productos agrcolas,
ganaderos y forestales producidos en el pas. Varios de ellos, tales como frutas, verduras,
vinos, maderas, cerdos, ovinos, aves, entre otros, se estn exportando a ms de 150 pases
en los cinco continentes.

La produccin animal del pas se regula mediante una normativa general de predios
productores de animales, llamada Programa de Planteles de Animales Bajo Certificacin
Oficial (PABCO de aqu en adelante) [Sag14b]. El programa proporciona garantas a
la produccin animal para la certificacin de productos aptos para consumo humano, y
aquellos requisitos establecidos por los servicios oficiales de los pases o mercados de
destino de las exportaciones, adems de definir qu informacin de los planteles debe
estar disponible para la trazabilidad de los productos de la cadena alimentaria.
13

http://www.sag.cl/

39

A continuacin se detallan las consideraciones para predios PABCO. El SAG define un

procedimiento general para los predios de animales tradicionales y no tradicionales, as
como tambin define un instructivo con las consideraciones generales para los animales
en especfico. El inters del presente proyecto, se basa especficamente en ovinos, y
siendo este un animal de produccin tradicional, se analizarn los documentos P-PP-IT007 correspondiente a animales tradicionales y I-PP-IT-018 correspondiente al instructivo
de planteles ovinos. Ademas, se realiza un anlisis a nuevas iniciativas tecnolgicas del
SAG, implementadas pero aun no obligatorias, como el Dispositivo de Identificacin
Individual Oficial (DIIO) y el registro de movimiento animal.
2.8.4.1.

Procedimiento P-PP-IT-007

El documento P-PP-IT-007 del SAG se encuentra rotulado como un procedimiento,

llamado Planteles de Animales Tradicionales Bajo Certificacin Oficial [Sag14c]. Este
documento describe de forma detallada todo el procedimiento para certificar un predio
productivo como predio PABCO .

Este documento, adems, define roles y responsabilidades asociadas, siendo de especial

inters el Titular del Plantel, el cual es la persona legalmente a cargo del plantel, el
Mdico Veterinario Acreditado (MVA) el cual es un veterinario reconocido por el SAG,
y el Mdico Veterinario Oficial SAG (MVO) el cual es un veterinario funcionario del
SAG.

El programa PABCO consta de una serie de actividades y requisitos que permiten el

ingreso y mantencin del plantel en el Programa. Adems, se incorporan en este manual,
los procedimientos y causas que determinan las sanciones al plantel y al MVA en caso de
faltas o incumplimientos.

El resto del documento indica con detalle las actividades, indicadores de desempeo que
medir el SAG y los formularios necesarios para todo el proceso. Finalmente, al acreditar
al predio como PABCO, es necesario sealarlo con una placa identificadora en la entrada
del previo, tal como se puede apreciar en la Figura 15.

40

Figura 20. Placa identificadora de predio PABCO [Sag14c].

2.8.4.2.

Instructivo I-PP-IT-018

El documento I-PP-IT-018 del SAG se encuentra rotulado como un instructivo, llamado

Planteles de Animales Ovinos Bajo Certificacin Oficial. Este documento describe las
particularidades que un predio PABCO debe poseer para la produccin animal ovina
[Sag14d].

En este documento, la seccin ms extensa corresponde a la descripcin de actividades,

la cual contiene toda la informacin necesaria a las caractersticas que debe presentar el
predio para integrarse al programa PABCO. Tambin se sealan las responsabilidades de
las partes involucradas, siendo muy similar a las especificadas en el documento P-PP-IT007 presentado con anterioridad.

Para el ingreso al programa PABCO ovino, los planteles deben cumplir los siguientes
requisitos:
Cumplir todas las exigencias establecidas en el Procedimiento P-PP-IT-007 e
Instructivo especfico para la especie, ovinas en este caso. Todos los documentos
del Programa PABCO, se encuentran disponibles en el sitio web del SAG.
Contar con al menos 30 das de antigedad de registros solicitados en el presente
Procedimiento P-PP-IT-007 e Instructivo especfico para la especie.
Contar con los servicios profesionales de al menos un MVA para que realice la
verificacin del plantel, a travs del Formulario Pauta de Evaluacin especfico para
la especie.

41

Cada plantel que postule al Programa PABCO debe incorporar todos los predios o
sectores que lo componen. Cada uno de estos predios o sectores, debe poseer un Rol
nico Pecuario (RUP).
Pagar la tarifa de ingreso al Programa PABCO, segn lo establecido en la normativa
tarifaria vigente. Dicho pago podr ser realizado en cualquier Oficina SAG que
cuente con caja receptora.

2.8.4.3.

DIIO y Registro de Movimiento Animal

Una de las iniciativas del SAG que contempla la tecnologa para la gestin de predios
productivos se enmarca bajo el proceso llamado Identificacin Animal Oficial [Sag14e].
Este proceso permite identificar oficialmente a un animal mediante el Dispositivo de
Identificacin Individual Oficial (DIIO en adelante) y vincularlo al establecimiento donde
se realiz esta actividad.

Este dispositivo corresponde a un arete o crotal de material plstico donde se registra

un nmero nico e irrepetible de nueve dgitos, el cual debe permanecer con el animal
durante toda su vida, independientemente del destino que tenga el animal. Tampoco debe
ser alterado, adulterado, copiado ni falsificado, sino har perder la condicin de trazable
al animal respectivo. Es comn que el DIIO se adose a una de las orejas del animal.

Los bovinos, equinos, porcinos, ovinos, caprinos, crvidos, llamas, alpacas, jabales
y bubalinos (bfalos) identificados con un DIIO o por lotes, deben ser registrados
para su traslado hacia otros predios reconocidos por el SAG. El Formulario de
Movimiento Animal [Sag14f] es el nuevo documento oficial que debe acompaar todos
los movimientos de animales de las especies sealadas anteriormente. Este formulario se
puede visualizar en el Anexo A del presente documento.
2.8.4.4.

Conclusiones

Se concluye que ninguna de estas regulaciones impide o interfiere con la implementacin

del sistema, e incluso el desarrollo del mismo puede brindar un apoyo en algunos casos
como el almacenamiento de DIIO, entre otros.
42

3.

SOLUCIN PROPUESTA

En este captulo, se pretende definir la problemtica que el presente proyecto enfrenta de

acuerdo a la realidad nacional, contextualizando esta con la situacin de la produccin
agrcola en general de la regin sudamericana y la integracin de tecnologas en esta
actividad econmica.

Ante esta problemtica, se realiza una propuesta de solucin y se especifican las diversas
tecnologas para la implementacin del proyecto que enfrente lo planteado.

3.1.

Definicin de la problemtica

En la actualidad, Amrica Latina se encuentra en un proceso de crecimiento de la

poblacin que jams ha tenido en toda la historia, y cada da este ritmo de crecimiento
se acelera. Mas an, este crecimiento es casi en su totalidad de poblacin urbana,
mantenindose constante la cantidad de personas que viven o trabajan realizando
actividades agrcolas en el campo. Estas tendencias en mayor o menor medida se aprecian
a nivel global.

Las estadsticas [Fao97], entregadas por la Organizacin de las Naciones Unidas para la
Agricultura y la Alimentacin, van mas all y sealan que, en 1960 exista un trabajador
agropecuario por cada seis habitantes en Sudamrica, y en el ao 2000 esta relacin ya
haba aumentado a 13 habitantes por cada trabajador.

Sumado a esto, la apertura de mercados de un mundo globalizado y formas de transporte

cada vez mas eficientes entre continentes, genera un entorno muy dinmico y competitivo
a las empresas del rubro. As, es imperativa la eficiencia en cada una de las etapas de los
procesos productivos de estas empresas agrcolas.

3.1.1.

Sistema de gestin ovina

La palabra gestin tiene diversas definiciones dependiendo del contexto, en el que se

utiliza en este caso se sealar como la funcin que coordina los esfuerzos de las personas
para alcanzar metas y objetivos utilizando los recursos de forma efectiva y eficiente.

43

En el contexto, y asumiendo que el objetivo principal de la empresa productora es la

rentabilidad, esta debe realizar su operacin de la forma mas eficiente y eficaz posible,
reduciendo sus costos operativos y minimizando sus perdidas.

La tecnologa, histricamente ha permitido una mejora en la eficiencia de las

organizaciones al reducir tiempos y esfuerzos, parmetros que finalmente se traducen
en menores costos. Esto, ha sido particularmente cierto con el almacenamiento, proceso
y obtencin de informacin, por lo que un sistema de gestin ovina, debe manejar
informacin relacionada a la operacin de los animales, como su edad, fertilidad,
informacin de inters para los Mdicos Veterinarios, entre otras.

3.1.2.

Monitoreo continuo

Las mayores perdidas que enfrentan las empresas dedicadas a la produccin de ovinos son
amenazas hacia los animales en s, tales como ataques de perros u otros animales, y el
abigeato [Pal13].

En consecuencia, otra arista para la mejora de la operacin es la reduccin de estas

perdidas mediante el monitoreo continuo. Este puede realizarse de diversas formas para
capturar diversa informacin sobre los animales en conjunto o de forma individual.

Dada la problemtica expuesta que produce perdidas de animales, uno de los parmetros a
monitorear en los animales es su posicin, y si esta corresponde con las inmediaciones de
las instalaciones productivas. Otro parmetro de inters es el comportamiento del animal,
el que puede indicar problemas de salud, amenazas, entre otras.

Este monitoreo se puede implementar de forma paralela con un sistema de informacin de

estos animales para llevar registros, observaciones y la posibilidad de obtener informacin
de forma rpida, adems, de alertas si algunos animales han transmitido algunos de estos
parmetros en forma anmala.

44

3.2.

Definicin de la solucin

Para abordar la problemtica ya definida, se propone una solucin integral de gestin y

monitoreo de animales. Esta solucin se divide en tres partes:
La que concierne al monitoreo animal.
El almacenamiento y manejo de los datos obtenidos.
La presentacin de estos datos al usuario.
As, se propone una red inalmbrica de sensores a implementarse con los animales,
recolectando informacin constantemente sobre su posicin, direccin y comportamiento,
mediante el uso de sistemas embebidos, sensores y una tecnologa de red adecuada
al contexto. El conjunto de estos dispositivos antes nombrados se denomina nodo de
sensores. La informacin recolectada por estos sensores ser enrutada hacia Internet
gracias a un nodo coordinador, que actuar de pasarela proporcionando conectividad a
la red de sensores.

Para el almacenamiento de los datos obtenidos de la red de sensores, su utilizacin y

la generacin de alertas ante anormalidad de la informacin recibida se implementar
un equipo central, el cual contar con una pila de aplicaciones dedicada especialmente
a cumplir los requisitos anteriormente sealados. Este equipo contar con una cantidad
suficiente de velocidad de proceso y de almacenamiento para mantener en funcionamiento
el sistema.

Finalmente, los usuarios podrn acceder a esta informacin y ser alertados de posibles
anormalidades desde la comodidad de sus dispositivos mviles conectados a Internet,
pudiendo acceder cuantas veces ellos deseen a toda la informacin disponible acerca
de los animales y la recolectada por los sensores. Se contempla el uso de mapas para
geoposicionar los animales, y el uso de notificaciones en tiempo real para las alertas.

3.3.

Tecnologas a utilizar

Ya definida la problemtica y la solucin propuesta para afrontarla, se procede a definir

las tecnologas de software y hardware necesarias para la implementacin del proyecto.

45

Esta seccin, tiene relacin con el estado del arte descrito en el captulo 2. Cuando sea
necesario, se explicarn los motivos de la eleccin entre las posibles tecnologas descritas.

3.3.1.

Hardware

El hardware en el presente proyecto tiene un rol fundamental, ya que sus caractersticas

permitirn la obtencin, transmisin y almacenamiento de los datos obtenidos desde los
animales. Se proceder a describir los dispositivos a utilizar, su funcin en el sistema y
posibles limitaciones detectadas para la implementacin en la solucin.

3.3.1.1.

Nodo de sensores

Se utilizar como sistema embebido la plataforma Arduino, en especfico el dispositivo

Arduino Uno [Ard14a]. Este dispositivo posee una relacin optima entre su tamao, su
cantidad de puertos para agregar sensores y su costo, el cual es menor al de la alternativa
presentada en el estado del arte, Waspmote [Lib14b].

Este Arduino es gobernado por el microcontrolador ATmega328, este posee 14 puertos de

entrada/salida digitales y seis puertos analgicos, ademas de un conector ICSP14 . Tambin
posee un puerto USB para la carga de cdigo y alimentacin de 5 Volt, aunque para otras
fuentes se utiliza el conector de energa, que soporta entre 7 y 12 Volt.

La limitacin mas evidente que posee este dispositivo, es su cantidad de memoria. Solo
posee 32 KiloBytes para la carga de cdigo, algo a tener en consideracin a la hora del
desarrollo.

De acuerdo a la definicin del problema y la necesidad de conocer la posicin del animal,

se utilizar el dispositivo de posicionamiento global (GPS) EM-406A desarrollado por
USGlobalSat [Usg14] y el modulo de orientacin o brjula digital HMC6352 desarrollado
por Honeywell [Hon09]. Ambos dispositivos se pueden apreciar en la Figura 16.

14

In Circuit Serial Programming, mas informacin en http://www.embedinc.com/picprg/icsp.

htm.

46

Figura 21. USGlobalSat EM-406A y Honeywell HMC6352.

Con estos dispositivos, se puede obtener la posicin del animal mediante el uso del
sistema de coordenadas geogrficas, especficamente su longitud y latitud, ademas de la
orientacin cardinal del animal en grados con respecto al norte geogrfico.

Para cubrir la necesidad de conocer el comportamiento del animal y detectar anomalas, se

utilizar el acelermetro de tres ejes ADXL335 desarrollado por Analog Devices [Ana10].
Este sensor se puede apreciar en la Figura 17.

Figura 22. Analog Devices ADXL335.

Este sensor entrega informacin acerca de la aceleracin que posee el animal considerando
los ejes coordinados X, Y y Z, pudindose determinar pasado cierto umbral condiciones
anormales en el animal, como saltos o movimientos sbitos que pudieran provocar
amenazas como ataques de perros, intento de robo, entre otras situaciones imprevistas.

Finalmente, el nodo sensor poseer un botn pulsador o interruptor, para inicializar el

sistema.
47

3.3.1.2.

Nodo coordinador

Para la implementacin de los nodos coordinadores, se utilizar al igual que en los nodos
de sensores, sistemas embebidos de la familia Arduino.

Especficamente, se utilizar el dispositivo Arduino Ethernet [Ard14b], el cual tiene las

mismas caractersticas que poseen los Arduino Uno utilizados en la red de sensores, con
la salvedad que como dice su nombre, los Arduino Ethernet poseen una interfaz Ethernet
10/100 MegaBit, necesario para transmitir a travs de una red de rea local (LAN) la
informacin recolectada por los sensores. Si la red local cuenta con acceso a Internet,
entonces la informacin puede ser enviada a cualquier maquina que se encuentre conectada
a la red de redes.

3.3.1.3.

Comunicacin en la red de sensores

Para la comunicacin entre los nodos, se utilizarn dispositivos de red de la familia

XBee, desarrollados por Digi International. Estos dispositivos basados en el estndar IEEE
802.15.4, estn diseados especialmente para sacar partido del estndar ofreciendo una
solucin de conectividad inalmbrica de bajo costo y consumo de energa [Dig14b].

Digi comercializa dos series de XBee, siendo la serie uno la que implementa solamente
el estndar IEEE 802.15.4, y la serie dos que implementa una capa de red adicional sobre
IEEE 802.15.4 llamada ZigBee, que brinda ciertas caractersticas adicionales. Ademas,
dentro de estas series, existe una serie de dispositivos distintos. La Figura 18 muestra
cuatro tipos distintos de XBee serie uno, variando en su tipo de antena y potencia de
transmisin.

images/capitulo2/xbee1.jpg
Figura 23. Serie uno de XBee.
Para la comunicacin de los nodos de sensores, se utilizarn dispositivos de red Digi
48

XBee-PRO con antena incluida de una pulgada (whip antenna), especficamente el modelo
XBP24-AWI-001. Este dispositivo de red alcanza una distancia terica de transmisin
mxima de 1335 metros sin obstculos [Dig12].

Otras caractersticas de estos dispositivos son la posibilidad de configurarlos de forma

local o remota, encriptacin de las transmisiones, y diversos estados de bajo consumo de
energa para prolongar la vida de la fuente de energa.

Para su conexin con la plataforma Arduino, se utilizar un dispositivo intermedio,

llamado XBee Shield [Lib14c], el cual est diseado para ser ubicado sobre el Arduino
comunicandose con el mediante el puerto ICSP. Este dispositivo se puede apreciar en la
Figura 19.

Figura 24. Arduino XBee Shield [Lib14c].

3.3.1.4.

Almacenamiento y procesamiento de la informacin

Para el proceso y almacenamiento de los datos recolectados por la red de sensores, se

utilizar un computador de tamao reducido de la familia BeagleBone, especficamente el
modelo BeagleBone Black [Bea14]. Estos dispositivos son producidos por la fundacin
BeagleBoard.org en asociacin con otros ensambladores.

Este computador, en concordancia con el resto de los dispositivos utilizados, tiene el

tamao de una tarjeta de crdito y posee un reducido consumo de energa. Sin embargo
no sacrifica rendimiento, al poseer un procesador de 1 Ghz de velocidad y 512 MB
de memoria RAM, pudiendo ejecutar diversas distribuciones basadas en GNU/Linux,
otorgando flexibilidad al software a utilizar en el.
49

Este equipo posee ademas, diversos puertos, como una interfaz Ethernet 10/100 Mb para
su conectividad a Internet, puertos USB, entre otros. Resulta de inters para el proyecto
la capacidad de aumentar su cantidad de almacenamiento mediante tarjetas microSD,
soportando hasta 128 GB de capacidad adicional.

3.3.1.5.

Dispositivos moviles

Para la utilizacin del sistema, se utilizarn dispositivos mviles compatibles con el

sistema operativo Android. Para el desarrollo del software se utilizarn dispositivos de
desarrollo de la familia Google Nexus [Goo14a], especficamente la tablet Nexus 7 (2013)
y el telefono inteligente Nexus 4.

Estos dispositivos ejecutan una versin sin modificaciones de Android, por lo que se
garantiza que las aplicaciones probadas en ellos funcionarn correctamente en todos los
dispositivos de los distintos fabricantes.

Para garantizar una correcta experiencia de usuario en el sistema, estos dispositivos

debern ejecutar una versin superior a Android 4.0.3, cumpliendo actualmente
aproximadamente el 80 % de los dispositivos en el mercado esta condicin [And14a].

3.3.2.

Software

Para la realizacin del proyecto, ser necesario utilizar variadas tecnologas de software,
dada la variedad de hardware necesario, y las especializadas funciones que deben cumplir
cada uno. Se proceder a describir las tecnologas de software a utilizar en cada una de las
partes del proyecto.

3.3.2.1.

Libreras para sistemas embebidos, sensores y red

Una de las facilidades que otorga el entorno de desarrollo de Arduino, es la capacidad de

utilizar libreras que se encarguen del manejo de bajo nivel de los sensores, ofreciendo al

50

desarrollador manipularlo desde un nivel mas alto.

Para facilitar el uso del dispositivo de posicionamiento global, se utilizar la librera

TinyGPS, desarrollada por Mikal Hart [Mik13]. Esta librera se encarga de procesar la
informacin en bruto que se obtiene desde el dispositivo, obteniendo de forma transparente
la informacin de posicin de inters, como la latitud y la longitud.

Los otros sensores no requieren libreras adicionales ya que envan su informacin de

manera lo suficientemente legible para ser utilizada.

Para utilizar los dispositivos de red XBee, se utilizar extensivamente la librera xbeearduino, proyecto liderado principalmente por Andrew Rapp [Rap14]. Esta librera
permite la comunicacin entre los XBee de forma sencilla, permitiendo enviar o recibir
paquetes de diversos tipos, ademas de utilizar los dispositivos de forma que se asegure la
transmisin de los datos dentro de la red de sensores, mediante el envo de paquetes de
asentimiento, conocidos como ACK15 .

Finalmente, en los nodos coordinadores que utilizan dispositivos Arduino Ethernet, se

utilizar la librera Ethernet que implementa el protocolo TCP/IP, necesario para la
conexin del dispositivo a Internet. Ademas, implementa algunas funciones simples de
cliente y servidor web, entre otras.

3.3.2.2.

Intercambio de datos

Para la recepcin de datos desde los nodos coordinadores y el envo de datos hacia los
dispositivos mviles que requieran de esta, se utilizar el modelo de cliente-servidor
basado en web, utilizando el servidor web Apache para recibir y responder las peticiones
de los diversos dispositivos.

Para el manejo de estas peticiones, se utilizar el lenguaje de programacin PHP,

encargado de discriminar las distintas solicitudes y realizar acciones acordes a ellas, como
almacenar informacin de un sensor o obtener la posicin de un animal desde la base de
15

Acknowledgement packet, mas informacin en http://packetlife.net/blog/2010/jun/7/

understanding-tcp-sequence-acknowledgment-numbers/.

51

datos.

Si bien los nodos coordinadores utilizarn una peticin simple para enviar informacin
obtenida por un nodo sensor por la sencillez de estos nodos, es necesario utilizar un
formato de intercambio de datos formal entre los equipos centrales y los dispositivos
mviles, dada la cantidad de datos enviados y la necesidad de una estructura.

As, se utilizar el formato de notacin de objetos JavaScript mas conocido como JSON.
Este estndar de formato abierto usa una estructura de texto entendible por un humano
para trasmitir datos consistente en pares atributo-valor, utilizndose principalmente para
transmitir datos entre un servidor y una aplicacin web. El formateo de los datos a este
estndar es realizado por PHP.

3.3.2.3.

Base de datos

Para el almacenamiento de los datos, se utilizar la base de datos relacional MySQL16 .

Esta base de datos de cdigo abierto es una de las mas populares, siendo ampliamente
utilizada en conjuncin con servidores web.

Esta base de datos, ofrece diversas opciones de motores de almacenamiento, que presentan
diversas ventajas y funcionalidades distintas entre ellos. Se utilizar el motor InnoDB, el
cual implementa las propiedades transaccionales de Atomicidad, Consistencia, Aislacin
y Durabilidad mas conocidas por sus siglas en ingles como ACID, garantizando que estas
transacciones se realicen correctamente. Tambin implementa otras funcionalidades como
el soporte de clave fornea, entre otras.

3.3.2.4.

Servicio de cartografia y notificaciones

Google proporciona a los desarrolladores de aplicaciones Android diversos servicios para

implementar funcionalidades y facilitar ciertas tareas. Estos servicios disponibles son
16

http://www.mysql.com/.

52

llamados Google Play Services [Goo14b].

Uno de los servicios ofrecidos por Google Play Services es el servicio de cartografa,
llamado Google Maps API. En este proyecto se utilizar este servicio para la integracin
de mapas en la aplicacin, permitiendo presentar la posicin de los animales en el mapa
al usuario, entre otras funcionalidades que pudieran hacer uso de los mapas. El uso de
este servicio es gratuito siempre que no se haga con fines comerciales y que no supere las
25000 peticiones al da.

Otro servicio a utilizar es el llamado Google Cloud Messaging for Android [Goo14b],
el cual permite enviar informacin directamente desde un servidor hacia dispositivos
Android. Se utilizar este servicio en situaciones donde sea necesario comunicar de forma
directa a los dispositivos cierta informacin, como puede ser una notificacin de peligro
de los animales, agregar un nuevo nodo sensor a la red, entre otros posibles usos.

3.4.

Arquitectura del sistema

Ya definida la solucin propuesta y las tecnologas a utilizar, es posible definir una

arquitectura de sistema, la cual se puede apreciar en la Figura 20. Esta arquitectura se
compone principalmente de la red de sensores, un equipo central que provee diversos
servicios web y de los dispositivos mviles que accedern al sistema.

Figura 25. Arquitectura del sistema.

53

4.

ANLISIS Y DISEO

El presente captulo gira en torno al modelamiento de la solucin propuesta utilizando

los artefactos de software pertinentes para documentar el sistema, y la adopcin de una
metodologa de desarrollo de software, con el fin de implementar el prototipo funcional
que de respuesta al problema expuesto de acuerdo a los objetivos planteados.

Para esto, se har uso de UML (Unified Modeling Language), una notacin esquemtica en
su mayor parte con que se construyen y representan sistemas por medio de conceptos. De
esta forma, con el problema y solucin propuesta ya definidos de forma general, se definen
los requisitos que debe satisfacer el marco de trabajo, dando paso a la etapa de anlisis
donde estos requisitos dan lugar a tareas y descripciones precisas, como la definicin de
actores y los casos de uso.

Finalmente, se disean diversos objetos de software que definen la implementacin del

sistema, dados los requisitos, casos de uso y actores definidos en la etapa de anlisis.

4.1.

Metodologa de desarrollo de software

Una metodologa de desarrollo de software se puede definir como un marco de trabajo

que es usado para estructurar, planear y controlar el proceso de desarrollar un sistema de
informacin. Para esto, se utilizan herramientas de anlisis y diseo UML, siendo normal
el uso de diagramas, entre otros objetos. Una metodologa tambin puede incluir aspectos
de desarrollo asistido por computadora, entornos integrados de desarrollo, entre otras.

Dadas las caractersticas de la problemtica planteada, principalmente la implementacin

de nuevas tecnologas tanto de software como de hardware y la posible deteccin de
nuevas necesidades a lo largo del proyecto, se ha optado por un entorno gil de desarrollo
de software. As, se utilizar el marco de trabajo denominado Scrum.

Scrum es una incremental e iterativa metodologa gil de desarrollo de software para la

gestin de proyectos [Scr13]. Esta metodologa permite la autoorganizacin a los equipos
de trabajo incentivando la interaccin en el mismo lugar o colaboracin online de todos
los miembros del proyecto.

54

Uno de los principios principales de Scrum es la aceptacin que en el transcurso del tiempo
los proyectos son susceptibles a cambios, de acuerdo a deseos del cliente o alternativas
descubiertas durante el desarrollo, y que estas circunstancias no pueden ser abordadas
fcilmente por otras metodologas mas tradicionales. Esto provoca que Scrum se centre en
maximizar la habilidad del equipo en implementar rpidamente y responder a los cambios
que puedan surgir.

En esta linea, una implementacin comn de Scrum rene:

Elementos: pila de producto, pila de sprint e incrementos.
Reuniones: de inicio de sprint, reunin diaria, revisin del sprint y retrospectiva.
Roles: propietario de producto, equipo, scrum master y otros implicados.
La unidad basica de Scrum se llama sprint, el cual es entendido como cada ciclo o iteracin
de trabajo que produce una parte del producto terminada y funcionalmente operativa,
llamada incremento. En la Figura 21 se puede apreciar el ciclo iterativo de Scrum.

Figura 26. Ciclo incremental iterativo Scrum [Ant14].

Considerando los elementos de una implementacin comn de Scrum, es pertinente
definir:
Pila del producto (product backlog): lista de requisitos que a partir de la visin inicial
del producto, crece y evoluciona durante el desarrollo.
Sprint: nombre que recibe cada iteracin de desarrollo, y que por lo general como
mximo tiene una duracin de un mes.
55

Pila de sprint (sprint backlog): lista de los trabajos que debe realizar el equipo
durante un sprint para implementar el incremento previsto.
Incremento: resultado entregable de cada sprint.

4.2.

Requisitos

Mientras que en metodologas de desarrollo de software tradicionales los requisitos del

proyecto suelen especificarse en documentos formales, en las metodologas giles estos se
agrupan de una forma prioritaria, siendo esta llamada pila de producto en Scrum.

La pila de producto representa todo aquello que esperan el cliente, los usuarios y en
general todos los interesados, la cual se encuentra en continuo crecimiento y evolucin.
Esta pila contiene funcionalidades, mejoras, tecnologa y correccin de errores que deben
incorporarse al producto a travs de los sucesivos sprints.

En la Tabla 2 se puede apreciar la pila de producto (product backlog) del proyecto, la cual
contiene un identificador nico por cada tem, prioridad, descripcin (historia de usuario)
y una estimacin inicial del esfuerzo en horas.

56

Tabla 2. Product Backlog del sistema.

ID

Prioridad

Descripcin

Est. (horas)

r1

Muy alta

Instalar ambientes de desarrollo.

r2

Muy Alta

Configurar mdulos XBee-PRO.

r3

Alta

Integrar modulo GPS en Arduino Uno.

r4

Alta

Integrar modulo de orientacin en Arduino Uno.

r5

Alta

Integrar modulo acelerometro en Arduino Uno.

r6

Alta

Integrar botn de inicializacin en Arduino Uno.

r7

Muy alta

Integrar XBee-PRO a Arduino Uno.

r8

Alta

Implementar sketch de nodo coordinador.

r9

Alta

Integrar XBee-PRO a nodo coordinador.

r10

Media

Verificar comunicacin entre nodo sensor y coordinador.

r11

Muy Alta

Preparacin e instalacin de equipo central.

r12

Alta

Implementacin PHP para manejo de solicitudes.

12

r13

Alta

Implementacin JSON Android.

r14

Muy alta

Implementacin Google Cloud Messaging.

r15

Baja

Implementacin ingreso de usuarios.

r16

Media

Implementacin de alta ovina.

10

r17

Baja

Implementacin de baja ovina.

r18

Alta

Integracin de Google Maps API.

r19

Alta

Implementacin de vistas de ovinos en mapas.

16

r20

Media

Implementacin de vista informacin ovina y observ.

10

r21

Muy alta

Implementacin notificaciones de anormalidades.

12

De esta pila de producto, se genera una serie de sprints que son subconjuntos de esta pila
de producto, produciendo como salida incrementos de producto. En la Tabla 3, Tabla 4 y
Tabla 5 se pueden apreciar los sprints a realizar en el proyecto.

57

Tabla 3. Sprint 1.
ID

Tarea

Estimado
(horas)

Real
(horas)

r1

Instalar ambientes de desarrollo.

r2

Configurar mdulos XBee-PRO.

r3

Integrar modulo GPS en Arduino Uno.

r4

Integrar modulo de orientacin en Arduino Uno.

r5

Integrar modulo acelermetro en Arduino Uno.

r6

Integrar botn de inicializacin en Arduino Uno.

r7

Integrar XBee-PRO a Arduino Uno.

r8

Implementar sketch de nodo coordinador.

r9

Integrar XBee-PRO a nodo coordinador.

r10

Verificar comunicacin entre nodo sensor y coordinador.

r11

Preparacin e instalacin de equipo central.

Total

36

34

Tabla 4. Sprint 2.
ID

Tarea

Estimado
(horas)

Real
(horas)

r12

Implementacin PHP para manejo de solicitudes.

12

20

r13

Implementacin JSON Android.

r14

Implementacin Google Cloud Messaging.

10

r15

Implementacin ingreso de usuarios.

r16

Implementacin de alta ovina.

10

12

r17

Implementacin de baja ovina.

Total

38

50

58

Tabla 5. Sprint 3.
ID

Tarea

Estimado
(horas)

Real
(horas)

r18

Integracin de Google Maps API.

r19

Implementacin de vistas de ovinos en mapas.

16

12

r20

Implementacin de vista informacin ovina y observ.

10

10

r21

Implementacin notificaciones de anormalidades.

12

10

Total

40

36

4.3.
4.3.1.

Fase de anlisis
Descripcin de las actividades del proceso

Las actividades principales que realiza el sistema son la captura y envo de informacin
desde los nodos sensores al nodo coordinador, donde este, a su vez lo enva al equipo
central para su almacenamiento. Por otro lado, los dispositivos mviles realizan solicitudes
de esta informacin para proporcionrsela a los usuarios. El proceso que agrupa estas
actividades se puede apreciar en la Figura 22.

Figura 27. Diagrama de proceso del sistema.

59

4.3.2.

Actores del sistema

A partir de las actividades efectuadas por los dispositivos involucrados se proceder a

describir la secuencia de eventos de los actores que utilizan el sistema para completar un
proceso. Los actores identificados que estimulan al sistema con eventos son:
Sensor: hace referencia al dispositivo que alimenta con datos al sistema de Gestin
Ovina.
Usuario: hace referencia a la persona que utiliza el sistema de Gestin Ovina, el cual
podr observar los valores de las variables obtenidas por la red de sensores.
En la Figura 23 se puede apreciar el diagrama de casos de uso del sistema. Por motivos
de dimensin de este documento, solo se detallarn los casos de uso Capturar y enviar
informacin y Ver informacin de un animal en particular, ya que ellos utilizan gran
parte de los otros casos de uso.

Figura 28. Diagrama de Casos de Uso.

60

4.3.3.

Casos de uso expandidos

En la Tabla 6 y Tabla 7 se pueden apreciar los casos de uso expandidos.

Tabla 6. Caso de uso expandido Capturar y enviar informacin.
Caso de uso:

Capturar y enviar informacin (CU01).

Actores:

Sensor.

Propsito:

Capturar y enviar informacin del estado del ovino.

Resumen:

El Nodo Sensor en el ovino captura su posicin geogrfica y

otros parmetros, para luego enviarlos a una maquina central
donde estos se almacenan.

Tipo:

Primario y esencial.

Precondiciones:

El Nodo Sensor se encuentra operativo.

El Nodo Sensor es parte de la red de rea personal (PAN) del
rebao.


Curso normal de los eventos

Accin de los actores

Respuesta del sistema

1. Este caso de uso comienza cuando

el Nodo Sensor activa sus sensores,
donde obtiene la posicin geogrfica,
orientacin y su aceleracin.
2. El Nodo Sensor enva la informacin
obtenida al nodo coordinador.
3. El Nodo Coordinador responde
afirmativamente la recepcin de estos
datos.
4. El Nodo Sensor se pone en reposo por
15 minutos.
5. El Nodo Coordinador enva esta
informacin al Equipo Central.
6. El Equipo Central recibe y almacena
esta informacin.
Cursos alternativos
1. El Nodo Sensor cuenta con alguno de sus sensores inoperativos.
3. El sistema no responde ante el envo de informacin del Nodo Sensor.
5. Falla la comunicacin entre el nodo coordinador y el Equipo Central.
6. Falla el almacenamiento de la informacin en el Equipo Central.
Post condiciones:

Sistema queda en estado de espera para nuevo proceso.

61

Tabla 7. Caso de uso expandido Ver informacin de un animal en particular.

Caso de uso:

Ver informacin de un animal en particular (CU02).

Actores:

Usuario.

Propsito:

Obtener informacin pertinente a un ovino.

Resumen:

El usuario ingresa al sistema de Gestin Ovina y observa

grficamente la informacin que concierne a un ovino en
particular.

Tipo:

Primario y esencial.

Precondiciones:

El Usuario posee credenciales de acceso al sistema.

Existe informacin sobre el animal en particular en el
sistema.


Curso normal de los eventos

Accin de los actores

Respuesta del sistema

1. Este caso de uso comienza cuando el

Usuario inicia sesin.
2. El Sistema despliega un mapa donde
se pueden apreciar todos los animales
con su posicin geogrfica.
3. El usuario presiona sobre el animal de
su inters.
4. El Sistema muestra informacin
bsica del animal.
5. El Usuario presiona sobre
la informacin bsica para acceder a la
informacin detallada del animal.
6. El Sistema muestra la informacin
detallada del animal.
Cursos alternativos
2. El Sistema no puede obtener la informacin de los animales.
Post condiciones:

4.3.4.

Sistema queda en estado de espera para nuevo proceso.

Diagramas de secuencia

Los diagramas de secuencia de la Figura 24 y Figura 25 muestran grficamente los eventos

que fluyen desde los actores al sistema.
62

Figura 29. Diagrama de secuencia de CU Capturar y enviar informacin..

Figura 30. Diagrama de secuencia de CU Ver informacin de un animal en particular..

4.4.
4.4.1.

Fase de diseo
Casos de uso real

El diseo concreto del caso de uso Ver informacin de un animal en particular. es

descrito en la Tabla 8, mientras los mockups que definen la interfaz de la aplicacin mvil
se pueden apreciar en la Figura 26 y Figura 27.
63

Tabla 8. Caso de uso real Ver informacin de un animal en particular (CU02).

Caso de uso:

Ver informacin de un animal en particular (CU02).

Actores:

Usuario.

Propsito:

Obtener informacin pertinente a un ovino.

Resumen:

El usuario ingresa al Sistema de Gestin Ovina y observa

grficamente la informacin que concierne a un ovino en
particular.

Tipo:

Primario y esencial.

Accin de los actores

Respuesta del sistema

1. Este caso de uso comienza cuando el

Usuario inicia sesin.
2. El Sistema despliega un mapa donde
se pueden apreciar todos los animales
con su posicin geogrfica.
3. El Usuario selecciona un animal
presionando (1) en la pantalla del
dispositivo mvil.
4. El Sistema despliega informacin
bsica del animal (2), como su nombre,
ademas de la indicacin si se requiere
informacin adicional.
5. El Usuario presiona el cuadro de
informacin bsica (3) para desplegar
informacin adicional del animal.
6. El Sistema despliega grficamente la
informacin adicional del animal en la
ventana 3.
Cursos alternativos
3. El Usuario selecciona errneamente un animal (1), ante lo cual debe presionar
el animal que desea verificar.

64

Figura 31. Diseo de ventanas 1 y 2 para CU02.

Figura 32. Diseo de ventana 3 para CU02.

65

4.4.2.

Diagrama de clases

Dada la extensin del diagrama de clases, este se encuentra en el Anexo B del presente
documento.
4.4.3.

Base de datos

Para el almacenamiento de los diversos datos obtenidos por los nodos sensores, ademas
de otros parmetros utilizados internamente por el sistema, se presenta en la Figura 28 el
siguiente modelo de datos.

Figura 33. Modelo de datos.

Como se puede apreciar, el modelo de datos est preparado para guardar informacin
de mltiples nodos de sensores ubicados en los ovinos, centralizando la informacin
identificatoria en la tabla oveja. Ademas, es de destacar la seguridad a utilizar en
el almacenamiento de los datos en las credenciales de usuario, utilizando contraseas
cifradas bajo un vector inicial aleatorio llamado salt. Finalmente, se almacenan los
dispositivos mviles que acceden al sistema, siendo su identificador utilizado para el envo
de notificaciones ante anormalidades en los ovinos.

66

En la Tabla 9, Tabla 10, Tabla 11, Tabla 12, Tabla 13, Tabla 14, Tabla 15 y Tabla 16
se puede apreciar el diccionario de datos correspondiente a la base de datos descrita
anteriormente.
Tabla 9. Diccionario de datos tabla parametros.
Columna

Tipo de dato

Descripcin

idparametros

INT(11)

Identificador nico de cada parmetro.

idOveja

INT(11)

Identificador nico de cada ovino.

edad

VARCHAR(45)

Edad del ovino.

numeroParto

VARCHAR(45)

Numero de serie del parto de cada ovino.

fechaEncaste

DATE

Fecha de encaste de un ovino.

dientes

INT(11)

Cantidad de dientes que posee un ovino.

Tabla 10. Diccionario de datos tabla oveja.

Columna

Tipo de dato

Descripcin

idOveja

INT(11)

Identificador nico de cada ovino.

idOreja

VARCHAR(6)

Identificador fsico (tag) de cada ovino.

fechaInicializacion

DATETIME

Fecha de inicio de monitoreo del ovino.

criaDe

VARCHAR(6)

Especifica si el ovino es cra de

otro animal en el sistema.

userName

VARCHAR(50)

Nombre de usuario que aadi

el animal en el sistema.

Tabla 11. Diccionario de datos tabla observacion.

Columna

Tipo de dato

Descripcin

idobservacion

INT(11)

Identificador nico de cada observacin.

idOveja

INT(11)

Identificador nico de cada ovino.

observacion

VARCHAR(10000)

Glosa de observacin.

hora

DATETIME

Hora donde se realiz la observacin.

67

Tabla 12. Diccionario de datos tabla orientacion.

Columna

Tipo de dato

Descripcin

idOrientacion

INT(11)

Identificador nico de cada orientacin.

idOveja

INT(11)

Identificador nico de cada ovino.

grados

INT(11)

Orientacin registrada en grados.

hora

DATETIME

Hora donde se obtuvo la orientacin.

Tabla 13. Diccionario de datos tabla ubicacion.

Columna

Tipo de dato

Descripcin

idUbicacion

INT(11)

Identificador nico de cada ubicacin.

idOveja

INT(11)

Identificador nico de cada ovino.

lon

FLOAT

Componente de longitud de la ubicacin.

lat

FLOAT

Componente de latitud de la ubicacin.

hora

DATETIME

Hora donde se obtuvo la ubicacin.

Tabla 14. Diccionario de datos tabla perimetro.

Columna

Tipo de dato

Descripcin

punto1

VARCHAR(60)

Primer punto geogrfico de permetro de ovinos.

punto2

VARCHAR(60)

Segundo punto geogrfico de permetro de ovinos.

punto3

VARCHAR(60)

Tercer punto geogrfico de permetro de ovinos.

punto4

VARCHAR(60)

Cuarto punto geogrfico de permetro de ovinos.

Tabla 15. Diccionario de datos tabla device.

Columna

Tipo de dato

Descripcin

iddevice

INT(11)

Identificador nico de dispositivo.

register

VARCHAR(250)

Identificador nico de dispositivo para Google.

68

Tabla 16. Diccionario de datos tabla users.

Columna

Tipo de dato

Descripcin

uid

INT(11)

Identificador nico de cada usuario.

unique_id

VARCHAR(23)

Nombre de usuario para acceso.

name

VARCHAR(50)

Nombre real del usuario.

email

VARCHAR(100)

Correo electrnico del usuario.

encrypted_password

VARCHAR(80)

Contrasea cifrada.

salt

VARCHAR(10)

Vector de cifrado de contrasea.

created_at

DATETIME

Fecha de creacin del usuario.

updated_at

DATETIME

Fecha de actualizacin del usuario.

69

5.

ELECCIN DE TOPOLOGA DE RED Y ALTERNATIVAS

En el presente captulo, se realizan los anlisis y la eleccin de una topologa de

red apropiada para la implementacin de la prueba conceptual de la red inalmbrica
de sensores, definindose algunos parmetros de distancia y terreno para el correcto
funcionamiento de la red.

Se define como topologa de red a la forma de conexin de varios elementos (como enlaces
o nodos) de una red, y esto se puede ver desde el punto de vista fsico o lgico [Chi]. El
punto de vista fsico se refiere a la ubicacin de los componentes de la red tales como
dispositivos y cables, mientras que lo lgico trata de la forma en la cual fluyen los datos
entre los dispositivos de la red.

Llevndolo al contexto del proyecto, la eleccin de la topologa de red es critica en una

red inalmbrica de sensores, en la bsqueda del equilibrio entre costos, vida de la batera,
distancia de transmisin, condiciones del terreno, entre otras.

Adems del anlisis y la eleccin antes sealada, se presentan diversas alternativas de

topologas de red y los dispositivos similares que las soportan, finalizando con una
comparacin entre todas estas opciones.

5.1.

Consideraciones para prueba de concepto

Para el anlisis, eleccin e implementacin de la topologa de red a utilizar en la red

inalmbrica de sensores, es necesaria la definicin del marco en el cual el sistema va a
ser insertado, como las propiedades fsicas del lugar simulando predios productivos y las
caractersticas tcnicas de los dispositivos a utilizar.

Para los efectos de la prueba de concepto, se considerar un terreno relativamente plano,

con linea vista aunque se contemplan obstculos menores como arboles y arbustos, lo que
asimilara a un tpico predio productivo cerrado y con terreno sin mayor pendiente, siendo
estos predios caractersticos del sur de Chile [Cas].

70

En cuanto a los dispositivos de comunicaciones a utilizar, los Digi XBee-Pro serie uno
poseen una distancia de transmisin de 1335 metros bajo condiciones similares a las
expuestas en la definicin de terreno anterior [Dig12].

5.2.

Alternativas ofrecidas por el equipamiento

Los dispositivos Digi XBee-PRO implementan a cabalidad el estndar IEEE 802.15.4, la

cual implementa nodos con funcionalidad completa (Full Function Device o FFD) y nodos
de funcionalidad reducida (Reduced Function Device o RFD) agrupados en dos tipos de
topologas distintas, llamadas estrella y punto a punto. Los tipos de nodos constituidos en
estas topologas se pueden visualizar en la Figura 29.

Figura 34. Topologas de red soportadas por IEEE 802.15.4 [Zei14].

Como se puede apreciar en la figura, la topologa punto a punto (Peer to peer) forma
patrones arbitrarios de conexiones, y su extensin solo se encuentra limitada por la
distancia entre cada par de nodos. Esta topologa exige que la mayora de los nodos sean
de funcionalidad completa, dada la ausencia de una capa de red que defina reglas de ruteo
entre nodos de funcionalidad reducida.

Tambin, se puede utilizar una topologa de red mas estructurada del tipo estrella, donde
el coordinador de la red necesariamente debe ser el nodo central. Este tipo de redes
puede utilizarse con un FFD que maneja su propia red de rea personal, eligiendo un
identificador de red nico. Despus de esto, otros dispositivos pueden unirse a la red, la
cual es completamente independiente de otras redes con topologa estrella que pudieran
71

existir cerca. Bajo esta configuracin, se pueden agrupar 65535 dispositivos, a lo que se
suma la direccin utilizada por el nodo coordinador.

5.3.

Eleccin de topologa y caractersticas de la implementacin

Considerando los antecedentes anteriormente expuestos, y especialmente la estructura que

posee, se utilizar para esta prueba de concepto una topologa de red del tipo estrella.
Esta topologa de red presenta ventajas frente a la del tipo punto a punto como lo es su
simplicidad de enrutado, fcil configuracin de los dispositivos, alta de nuevos animales
de forma rpida y tolerancia a fallas de los nodos sensores, y tiene adems algunas
desventajas como la vulnerabilidad de la red en torno al nodo central y la probabilidad
de colisiones cuando existen muchos nodos enviando informacin al nodo coordinador.

As, y considerando una tolerancia a las especificaciones de los Digi XBee-PRO,

se propone una distancia mxima entre nodo de sensores y nodo coordinador de 1
Kilmetro, obteniendo un predio de 2 kilmetros cuadrados donde la red inalmbrica
de sensores debera funcionar sin problemas, actuando los nodos de sensores como
nodos de funcionalidad reducida y los nodos coordinadores de nodos de funcionalidad
completa. Este predio, sus dimensiones y la distancia mxima al nodo coordinador se
puede visualizar en la Figura 30.

Figura 35. Esquema de predio donde operan los nodos de sensores.

72

Este diseo permite planear de forma eficiente la cobertura completa de un predio

productivo, dividindolo en sitios de cobertura uniformes. Tambin permite reducir estos
predios a un rea menor sin afectar el diseo, de acuerdo a las necesidades de los posibles
clientes.

Es preciso sealar que estos predios deben ser cerrados, ya que si bien existe una tolerancia
para salir del permetro, est considerada para la deteccin de fuga y no para un monitoreo
continuo en el borde de la cobertura.

Finalmente, la validacin de estas distancias y areas propuestas se realizarn en el captulo

siete llamado Validacin y Resultados.

5.3.1.

Condiciones de borde

La topologa de red en estrella es propensa a ciertos fenmenos cuando se cumplen algunas

condiciones especificas en la red, las cuales pueden degradar su rendimiento o incluso
provocar la perdida de informacin en ella. Estas condiciones se presentan generalmente
en situaciones de alta carga, por lo que se denominan condiciones de borde.

Cuando los nodos sensores se comunican con el nodo coordinador en una topologa del
tipo estrella, existe la posibilidad que uno de estos sensores transmita informacin al
mismo tiempo que otro nodo, provocndose la perdida de uno o de ambos envos de
informacin, conocindose este fenmeno como colisin.

Existen diversas tcnicas para enfrentar las colisiones, como segmentar los envos en
espacios de tiempo o frecuencia cuando es posible, o la implementacin de un mecanismo
verificador de los datos enviados mediante un paquete que retorna al nodo sensor luego que
el nodo coordinador recibe exitosamente, reenviando la informacin el nodo de sensores si
no recibe el citado paquete. Este ultimo mecanismo, conocido como ACK por la palabra
inglesa acknowledgment, se encuentra implementado en los Digi XBee-PRO cuando se
utiliza el modo de operacin API, por lo que se utilizar este modo para evitar esta
condicin.

73

Otra condicin de borde se presenta cuando se agotan las direcciones disponibles en la

red. El direccionamiento de 16 bit del estndar IEEE 802.15.4 soporta 65536 direcciones
nicas, por lo que cuando se supera este nmero de nodos sensores ya no es posible agregar
nuevos nodos a la red.

La solucin mas simple ante este escenario es simplemente crear una nueva red del tipo
estrella, asignando nodos coordinadores adicionales a los cuales se van a conectar los
nuevos nodos de sensores. Una arquitectura de lo comentado anteriormente se puede
apreciar en la Figura 31.

Figura 36. Mltiples redes de sensores en la topologa estrella.

Tambin es posible cambiar el tipo de direccionamiento hacia uno de 64 bits, siendo
este tipo soportado por los Digi XBee-PRO, contndose as con aproximadamente 1818
direcciones nicas, suficientes para la mayora de las aplicaciones existentes en la
actualidad.

5.4.

Alternativas de equipamiento y topologas de red

Una de las topologas que ha tenido una particular atencin [Aky04] para las redes
inalmbricas de sensores es la topologa del tipo malla (Mesh en ingls), la cual
bsicamente es una red punto a punto entre nodos, con la diferencia que implementa el
reenvo de la informacin en todos los nodos hasta que esta alcanza el nodo destino, y
caractersticas como la autoconfiguracin y la autoregeneracin de la red ante posibles
problemas.

74

Para la implementacin de esta topologa de red, Digi pone a disposicin los XBee
DigiMesh, los cuales implementan una capa de red propietaria sobre IEEE 802.15.4
llamada DigiMeshTM [Dig14c]. As, existen tres posibles topologas de red a utilizar para
la implementacin de la red de sensores con equipamiento adicional, pudiendo visualizarse
estas en la Figura 32.

Figura 37. Topologas disponibles para implementacin [Rtc13].

La topologa en malla es un primer paso hacia la implementacin de redes que presenten
una buena relacin rendimiento/precio y con un ancho de banda dinmico sobre una rea
especifica de cobertura. Tambin presentan importantes desafos, siendo el mas importante
de todos la eficiencia de su enrutado, para lo que hay propuestos una gran cantidad de
protocolos para que estas redes enfrentan este y otros problemas de la capa de enrutado.

Las redes con topologa en malla son relativamente estables exceptuando por la falla
ocasional o la agregacin de nuevos nodos. Los caminos que utiliza el trafico, cuando
existen muchos usuarios en la red, vara infrecuentemente, enrutandose prcticamente todo
el trafico desde o hacia un gateway que realiza la interconexin con otra red como puede
ser Internet [Jun03].

As, esta topologa de red es indicada para predios en los cuales no es factible la
implantacin de infraestructura de red como nodos coordinadores, o el uso de estos sera
ineficaz, como es el caso de predios con importantes accidentes geogrficos tales como
quebradas o montaas, donde las ondas de radio difcilmente se propagan. Sin embargo,
para el monitoreo en tiempo real debe existir algn tipo de red para obtener la informacin
de la red de sensores, como lo puede ser una red de rea amplia (Wide Area Network)
como lo puede ser la red celular, existiendo cada vez mas cobertura en las zonas rurales
del pas [Sub11].

75

5.5.

Marco comparativo

Para finalizar este anlisis, se comparan las tres topologas de acuerdo a parmetros
econmicos, complejidad y de tolerancia a fallos en la red. As tambin, sus atributos
para implementarse en diversas situaciones geogrficas tomando en consideracin los
parmetros anteriores.

Las redes con topologa punto a punto, por la forma uno a uno de su conexin y la baja
cantidad de dispositivos involucrada, presenta un bajo costo y una baja complejidad en su
implementacin, sin embargo si falla alguno de los dispositivos la red pierde ese enlace y
sin capacidad de regeneracin, la red consecuentemente falla en su totalidad.

Las redes con topologa estrella presentan un mayor costo, por la necesidad de
implementar un nodo coordinador y la infraestructura necesaria para su ubicacin y
conectividad a otras redes, pero su operacin, es relativamente sencilla y tolera sin
problemas fallos de los nodos sensores, sin afectar la comunicacin de los otros nodos
operativos.

Finalmente, las redes con topologa de malla no exigen la implementacin de

infraestructura para operar, pero si exigen equipamiento preparado para desplegar esta
topologa, siendo normalmente mas costoso ya que implementan componentes adicionales
para mantener la operacin como distintos protocolos de enrutado, lo que aumenta la
complejidad. Sin embargo, normalmente utilizan mltiples polticas de autoregeneracin,
por lo que estas redes poseen una alta tolerancia a los fallos.

Un resumen comparativo de lo antes descrito se puede apreciar en la Tabla 17, donde se le

otorga a cada parmetro un valor representativo.

Tabla 17. Tabla comparativa de topologas de red.

Punto a Punto

Estrella

Malla

Costo

Bajo

Alto

Medio

Complejidad

Bajo

Medio

Alto

Tolerancia a fallos

Nulo

Medio

Alto

76

Tomando en consideracin esta comparacin, se presentan algunos posibles escenarios

geogrficos donde se podra implementar esta red de sensores. La Figura 33 muestra tres
escenarios de forma combinada, donde se tiene terreno llano, montaoso y de quebrada, y
posibles puntos donde se requiere la comunicacin.

images/capitulo2/terreno1.png

Figura 38. Escenarios posibles a abordar por las topologas.

As, y obviando las distancias de transmisin, los nodos A pueden comunicarse sin
problemas, no importando la topologa utilizada. La red que incorpore a los nodos A,
al estar en terreno llano, posibilita utilizar de forma mas eficiente la topologa estrella por
la facilidad de implementar la infraestructura en este terreno, mientras que para los nodos
B y C es mas complejo implementar esta infraestructura en la red que los agrupe.

Bajo estas condiciones, para implementar una red que agrupe a los nodos B y C se puede
utilizar una red con topologa en malla la que no exige infraestructura. Sin embargo, si las
redes A, B y C no se encuentran conectadas entre si por algn medio, cada una deber
resolver por separado la forma en la cual envan su informacin a otras redes, o a Internet.

Por otro lado, la red B se encuentra en una posicin geogrfica ideal para agrupar todas
las redes independiente de la topologa a utilizar, para lo cual un nodo de la red B debe
actuar como nodo coordinador para la interconexin de todas la redes, aunque este nodo
se expone como nico punto de falla de la red.

Tomando en cuenta todos estos factores, en la Tabla 18 se presenta un resumen

comparativo de las topologas disponibles y que tan aptas son estas para su
implementacin en diversos terrenos, otorgndole un valor representativo a cada topologa.

77

Tabla 18. Tabla de compatibilidad entre topologas de red y terreno.

Punto a Punto

Estrella

Malla

Llano

Bajo

Alto

Medio

Pendientes

Bajo

Alto

Medio

Montaas y

Medio

Bajo

Alto

Quebradas

78

6.

IMPLEMENTACIN

El presente captulo, apoyado en las fases de anlisis y diseo anteriores, expone la

construccin de la prueba de concepto del sistema basado en el hardware y software
seleccionados. De esta manera para lograr los objetivos planteados, fue creado un
escenario con una red IEEE 802.15.4 con un nodo de sensores y un nodo coordinador
comunicados mediante mdulos Digi XBee-PRO con la topologa de red del tipo estrella.
Este nodo coordinador se encuentra conectado a Internet comunicndose con un equipo
central que almacena la informacin recopilada, a la cual pueden acceder dispositivos
mviles basados en la plataforma Android.

6.1.

Configuracin de mdulos XBee-PRO

Como se ha sealado anteriormente, para la implementacin de la prueba de concepto

han sido seleccionados los mdulos Digi XBee-PRO. Estos dispositivos se pueden
utilizar sin configuracin previa (out-of-the-box) para comunicar rpidamente dos sistemas
embebidos, pero para los fines de la prueba de concepto necesitan cierta configuracin
adicional.

Digi provee una herramienta para la configuracin de estos mdulos llamada XCTU. En
la Figura 34 se puede apreciar la herramienta y algunos parmetros de configuracin.

Figura 39. Versin 6 de Digi XCTU.

79

El XBee ubicado en el nodo coordinador tiene los siguientes parmetros de configuracin,

mientras que el resto se mantuvieron por defecto:
ID - PAN ID: 1337.
MY - 16-bit Source Address: 1000.
CE - Coordinator Enable: Coordinator[1].
DD - API Enable: API enabled w/PPP[2].
Mientras que los XBee ubicados en los nodos de sensores tienen los siguientes parmetros
de configuracin:
ID - PAN ID: 1337.
MY - 16-bit Source Address: 1001 hasta el 9999.
CE - Coordinator Enable: End Device[0].
DD - API Enable: API enabled w/PPP[2].
Como se puede apreciar, los XBee fueron configurados para trabajar en modo API, la
cual presenta mltiples ventajas como una confirmacin transparente del envo de datos,
la obtencin de parmetros de seal y la posibilidad de reconfiguracin del modulo sin
necesidad de conectarlo a un computador.

El modo API ademas permite la construccin personalizada de un sector de datos que

tienen los paquetes con los que se comunican los dispositivos. Esta estructura se puede
visualizar en la Figura 35.

Figura 40. Estructura de un paquete XBee en modo API [Ker12].

80

6.2.

Nodo de sensores

La implementacin del nodo de sensores tiene una etapa de construccin fsica, integrando
el dispositivo embebido Arduino Uno con los mdulos sensores GPS, de orientacin y
acelermetro, ademas de un botn para inicializar el sistema.Tambin se realiza una etapa
de implementacin del software requerido para controlar estos dispositivos y enviar la
informacin a travs de la red.

Los sensores tienen diversas interfaces para comunicarse con el Arduino . El modulo GPS
EM-406A utiliza dos puertos digitales para transmisin y recepcin, mientras que los
mdulos de orientacin HMC6352 y el acelermetro ADXL335 utilizan dos y tres puertos
analgicos respectivamente. Finalmente,el modulo XBee-PRO se inserta en el XBee Shield
y este se conecta en el puerto ICSP del Arduino Uno. La Figura 36 muestra el nodo de
sensores desarrollado para la prueba de concepto de la red de sensores.

images/capitulo2/nodosensor2.jpg
Figura 41. Prototipo inicial de nodo sensor.
Para su funcionamiento, se implementa un sketch de Arduino, el cual integra las libreras
xbee-arduino y TinyGPS, las cuales tienen el cdigo necesario para la utilizacin de los
modulos XBee-PRO y GPS respectivamente. Se define adems el inicio de los sensores al
presionar el botn instalado, tomando muestras de informacin cada 15 minutos para ser
enviadas al equipo central. El sketch antes mencionado se puede apreciar en el Anexo C
del presente documento.

6.3.

Nodo coordinador

La implementacin del nodo coordinador es similar a la del nodo de sensores, con la

diferencia que este nodo no cuenta con sensores, debiendo integrarle al Arduino Ethernet
solamente el XBee Shield en su puerto ICSP. La Figura 37 muestra el aspecto de este nodo
coordinador.

images/capitulo2/nodocoord2.jpg
Figura 42. Prototipo inicial de nodo coordinador.
81

Para su funcionamiento, se implementa en el sketch de Arduino el cdigo necesario para

recuperar los datos de los paquetes enviados por los nodos de sensores, y la utilizacin
de la librera Ethernet permite enviar estos datos bajo el protocolo HTTP. La forma de la
solicitud con la cual se inicializa un nodo de sensores que se autoidentifica como 1001 se
puede apreciar en el siguiente extracto de cdigo. El sketch antes mencionado se puede
apreciar en el Anexo D del presente documento.
http://equipocentral/alta.php?addr=1001
As, cuando el nodo 1001 ya se encuentra dado de alta en el sistema, comienza a enviar
informacin de posicin y orientacin. Esta solicitud se puede apreciar en el siguiente
extracto de cdigo.
http://equipocentral/data.php?addr=1001&heading=230
&lon=-73.3432&lat=-32.5344
Finalmente, cuando un nodo de sensores enva un paquete sealando que el animal
monitoreado se encuentra bajo condiciones de peligro detectadas por sus sensores, el nodo
coordinador realiza la solicitud que se puede apreciar en el siguiente extracto de cdigo.
http://equipocentral/alerta.php?addr=1001

6.4.

Equipo central

El equipo central contiene un conjunto de software necesario para recibir las solicitudes
enviadas desde el nodo coordinador, el almacenamiento de estos datos y la capacidad de
proporcionar estos datos cuando sea necesario. Especficamente, el BeagleBone Black
contiene una distribucin de GNU/Linux, Apache, MySQL y PHP, conocindose esta
arquitectura de software por sus iniciales como LAMP.

As, en este equipo se encuentra el cdigo PHP necesario para el manejo de los
datos que se reciben o envan va Apache, realizando las operaciones correspondientes
sobre la base de datos MySQL. Los archivos PHP expuestos para estas tareas son
llamados data.php, alerta.php y alta.php, como se pueden apreciar en las solicitudes
mostradas anteriormente en la seccin 6.1 del presente captulo.

Es de destacar el algoritmo utilizado para la deteccin de fuga de animales, el cual

analiza las coordenadas recibidas desde un nodo de sensores. Este algoritmo implementa
82

una tcnica llamada Ray Casting, la cual teniendo un polgono conocido (el permetro
definido) genera rectas en todas las direcciones desde el punto geogrfico a analizar (la
posicin del animal), evaluando las intersecciones de estas rectas con el polgono. Este
algoritmo se puede apreciar en el Anexo E del presente documento.

6.5.

Dispositivo mvil

El dispositivo mvil presenta todas las funcionalidades de usuario del marco de trabajo,
para lo cual se utiliz JSON como el formato de intercambio de datos entre estos
dispositivos y el equipo central, y utilizando servicios de Google como Google Maps API
y Google Cloud Messaging.

Al ser esta la pieza de software mas compleja del marco de trabajo, se utiliz un entorno
integrado de desarrollo (IDE) llamado Android Studio. Este entorno permite la rpida
integracin de las APIs de Google con el desarrollo del software, ademas de mltiples
herramientas de prueba, validacin y depuracin.

6.5.1.

APIs y servicios de Google

Google, ofrece a los desarrolladores de aplicaciones Android una amplia gama de

servicios y de APIs, las cuales permiten ofrecer diversas funcionalidades adicionales a
las aplicaciones de forma fcil y bajo los lineamientos de la plataforma, siendo algunos de
estos ofrecidos de forma gratuita y otros de pago.

En el desarrollo del marco de trabajo se utilizaron dos de estos servicios, Google Cloud
Messaging y Google Maps API.

Google Cloud Messaging para Android es un servicio que permite enviar datos desde
un servidor a usuarios que posean dispositivos con Android, y tambin permite recibir
mensajes desde los dispositivos bajo la misma conexin. El servicio maneja todos los
aspectos del encolado de mensajes y entrega de estos a la aplicacin objetivo en los
dispositivos. Este servicio es completamente gratis, sin cuotas ni mximos de utilizacin.
La arquitectura de este servicio se puede apreciar en la Figura 38.

83

Figura 43. Arquitectura de Google Messaging Service [Ant13a].

Por otro lado, Google Maps API es un acceso de desarrollador a la plataforma Google
Maps, con el cual se puede obtener mltiples funcionalidades que Google ha puesto a
disposicin de los desarrolladores, como lo son, los mapas (ruteros, hbridos o satelitales),
definicin de caminos y polgonos mediante polilineas, marcadores, entre otros.

Google Maps y Google Cloud Messaging son una parte integral de Google Play Services,
una aplicacin que agrupa la base de todos los servicios de Google en los dispositivos
Android, siendo indispensable su existencia en los dispositivos para disfrutar de estos
servicios. En la Figura 39 se muestra el funcionamiento de estos servicios.

Figura 44. Funcionamiento de Google Play Services [Ant13b].

84

6.6.

Producto de software

El resultado de la implementacin del software es una aplicacin que funciona en cualquier

dispositivo Android cuya versin sea superior a 4.0.4 (API 15), la cual posee mltiples
pantallas y formas de mostrar la informacin e interactuar con el usuario.

As, la pantalla de inicio de la aplicacin es utilizada para autentificar al usuario, ademas

de utilizarla para obtener la direccin a la que responde el equipo central (servidor) se
encuentra. Esta pantalla se puede apreciar en la Figura 40.

Figura 45. Inicio de sesin en la aplicacin mvil.

Si se inicia sesin y la aplicacin detecta que aun no existen animales bajo monitoreo, le
muestra al usuario una pantalla donde le informa la situacin y lo invita a inicializar un
nodo sensor para agregar un animal e iniciar el monitoreo. Esta pantalla se puede apreciar
en la Figura 41.

85

Figura 46. Pantalla de Alta Ovina en la aplicacin mvil.

Cuando ya existen animales bajo monitoreo, se abre una pantalla que geoposiciona a cada
uno de los animales en un mapa, sealndose cada animal con una figura similar a una
oveja. Cuando el usuario presiona esta imagen, se muestra informacin bsica e incita al
usuario a presionar si desea mas informacin. Esta pantalla se puede apreciar en la Figura
42.

Figura 47. Pantalla principal de la aplicacin mvil.

Cuando el usuario presiona el lugar indicado, se despliega la informacin pertinente del
86

animal. Esta pantalla se puede apreciar en la Figura 43.

Figura 48. Pantalla de informacin ovina en la aplicacin mvil.

En esta ventana, los ltimos elementos llevan a dos pantallas distintas, una que muestra y
permite agregar observaciones al animal seleccionado, y otra que muestra los movimientos
del ovino en las ultimas 24 horas. Estas ventanas se pueden apreciar en la Figura 44,
utilizando dos posiciones simuladas para la pantalla del recorrido.

Figura 49. Pantalla de observaciones y ruta recorrida de la aplicacin mvil.

Ademas se muestran en la Figura 45 otras pantallas que contienen funcionalidades de la
aplicacin, como lo son la definicin de un permetro desde donde se deben reportar los
animales, la eliminacin de animales o baja ovina y el ingreso de un nuevo usuario al
87

sistema.

Figura 50. Pantallas de permetro, baja ovina y nuevo usuario de la aplicacin mvil.

88

7.

VALIDACIN Y RESULTADOS

En este captulo se describe el mecanismo con el cual se valid la implementacin de

la prueba de concepto del sistema, sometiendo los dispositivos a una situacin real.
Finalmente se presentan los resultados de esta validacin.

7.1.

Validacin de la prueba de concepto

Para validar la prueba de concepto de la red de sensores, y de acuerdo a la topologa de

red e implementacin diseada en el captulo cinco de este documento, se verifica que la
red funciona correctamente en la distancia mxima de transmisin posible entre el nodo
sensor y el nodo coordinador.

As, para validar el sistema, se utiliza la utilidad Range Test incluida en el software
XCTU proporcionado por Digi Inc., con la que se verifica la comunicacin de un nodo
sensor y el nodo coordinador en una distancia de 1 kilmetro, obteniendo los valores
de fuerza de la seal recibida RSSI17 , ademas de un porcentaje de paquetes enviados y
recibidos de forma exitosa entre los nodos. Tambin se consideran los otros parmetros
definidos, tales como un terreno relativamente llano y sin inclinaciones y obstculos de
reducido tamao.

Esta prueba se realiz el 31 de Julio del 2014, en los primeros kilmetros de la ruta T-35
que une la ciudad de Valdivia con la localidad de Huellelhue, existiendo en esta una recta
de poco mas de 1 kilmetro, donde se realizaron las pruebas.

Es relevante considerar que las pruebas se hicieron con precipitaciones moderadas, 12,9
grados Celcius de temperatura y una humedad relativa de 95 % [Uac14] lo cual ayuda a
consolidar un escenario similar a los cuales el sistema debe estar preparado, como pueden
ser los predios productivos del sur de Chile.

7.2.

Resultados

A la distancia de 1 kilmetro, medida con el cuenta vueltas de un vehculo, se obtuvieron

los resultados que se pueden apreciar en la Figura 46.
17

Received Signal Strength Indication.

89

Figura 51. Resultados de medicin a 1 kilmetro de distancia entre nodos.

Se puede apreciar unos bajos valores RSSI entre los nodos, ademas de un bajo porcentaje
de paquetes intercambiados correctamente, siendo solo de un 29 %.

Ante este escenario, se decide reducir la distancia 100 metros a la vez, hasta lograr cifras
mas altas que aseguren la transmisin.

As, a 900 metros de distancia se obtienen los resultados que se pueden apreciar en la
Figura 47.

Figura 52. Resultados de medicin a 900 metros de distancia entre nodos.

Como se puede apreciar, los resultados no fueron mejores, incluso obtenindose un menor
porcentaje de paquetes intercambiados correctamente, siendo este de solo un 17 %.

90

A 800 metros de distancia se obtienen los resultados que se pueden apreciar en la Figura
48.

Figura 53. Resultados de medicin a 800 metros de distancia entre nodos.

Como se puede apreciar, no hay mayores cambios en la calidad del enlace, reducindose
aun mas el porcentaje de paquetes intercambiados correctamente, siendo este de solo un
7 %.

A 700 metros de distancia se obtienen los resultados que se pueden apreciar en la Figura
49.

Figura 54. Resultados de medicin a 700 metros de distancia entre nodos.

Como se puede apreciar, hay una mejora significativa en todos los parmetros, y aunque
los valores RSSI no son altos, el porcentaje de paquetes intercambiados correctamente
aument considerablemente, alcanzando el 87 %, suficiente para la operacin de la red.

91

Finalmente, se hicieron pruebas a 600 y 500 metros, obtenindose resultados aun mas
favorables, incluso logrndose un 100 % de paquetes intercambiados correctamente a 500
metros de distancia. Estos resultados se pueden apreciar en la Figura 50 y Figura 51.

Figura 55. Resultados de medicin a 600 metros de distancia entre nodos.

Figura 56. Resultados de medicin a 500 metros de distancia entre nodos.

Por lo tanto, se puede concluir que en condiciones de lluvia, ademas del escenario definido
en el captulo cinco, la distancia de transmisin mxima para lograr fiabilidad con los
equipos utilizados no debe ser mayor a 700 metros.

92

8.

CONCLUSIONES

Sin darnos cuenta, vivimos en una poca donde progresivamente se han ido conectando
dispositivos de la vida cotidiana a Internet, fuera del tradicional computador. Televisores,
reproductores de msica, celulares, sistemas de calefaccin e incluso la iluminacin ha
sufrido una evolucin irreversible, con la cual podemos tener el control de estos sin
estar fsicamente presentes abriendo mltiples funcionalidades antes impensadas e incluso
tildadas como imposibles.

Este proyecto de titulacin es solo una muestra de lo que nos depara el futuro, donde
los objetos de estudio que se encuentran conectados a Internet para obtener informacin
pueden ser tan variados como lo puede ser un animal de granja, todo esto bajo el paradigma
del Internet de las cosas, el cual si bien no se encuentra completamente definido, ya
comienza a ser una parte determinante en la vida de las personas.

Existieron diversos desafos superados en el transcurso de este proyecto, principalmente

por la transversalidad de este mismo, debiendo aplicar conocimientos de electrnica y
de programacin de bajo nivel en el lado de los sensores hasta lenguajes de alto nivel,
APIs de desarrollo y entornos integrados de desarrollo muy recientes en el lado de la
aplicacin mvil, lo que llev al alumno a conocer y entender de extremo a extremo las
potencialidades del Internet de las Cosas y como este puede cambiar de forma radical la
manera de ver la tecnologa para el usuario.

En la validacin del sistema se pudo verificar que ante condiciones adversas la red de
sensores logra desempearse correctamente, aunque la propuesta inicial de 1 kilometro
result ser ligeramente optimista. Sin embargo, ante el escenario tradicional de predios
cerrados por hectrea de 100 metros de lado, aun resultan muy positivos los resultados
para cubrir mltiples predios sin dificultad.

Existen aun diversos desafos en el Internet de las cosas y en el presente proyecto de

titulacin, teniendo en comn el desafo de la reduccin del consumo energtico de los
nodos sensores. Es un tema de critica importancia en las redes inalmbricas de sensores,
pero se sale del alcance definido para el proyecto, debiendo ser el principal tema a abordar
ante una eventual continuacin de este proyecto.

93

Finalmente, el marco de trabajo brinda una plataforma tanto para su uso bajo el estado
actual, as tambin como permite su ampliacin en un trabajo futuro multidisciplinario
entre veterinarios, operarios y ingenieros del rea informtica y electrnica. Ademas,
puede proporcionar datos de inters cientfico para el estudio de comportamiento ovino
y la generacin de modelos que permitan determinar comportamientos fuera de lo normal
como enfermedades, amenazas o incluso celo, todas estas de especial inters para el sector
productivo. Todas estas posibilidades de crecimiento muestran los nuevos horizontes que
abren la aplicacin de estos paradigmas tecnolgicos en la industria y en la vida de las
personas.

94

BIBLIOGRAFA
[Aky04] Akyldiz I., Wang X. & Wang W. (2004). Wireless mesh networks: a survey.
Disponible en http://www.ece.gatech.edu/research/labs/bwn/surveys/
mesh.pdf. Consultado el 22 de Julio de 2014.
[Aky13] Akyildiz I. (2013). State-of-the-art in sensor networks research. Disponible en
http://bit.ly/1pffyMm. Consultado el 06 de Junio de 2014.
[Ana10] Analog Devices, Inc. (2010). ADXL335: small, low power, 3-axis g
accelerometer. Disponible en http://www.analog.com/en/mems-sensors/
mems-inertial-sensors/adxl335/products/product.html. Consultado el
16 de Junio de 2014.
[And14a] Android Developers (20014). Dashboards. Disponible en http://
developer.android.com/about/dashboards/index.html. Consultado el 08
de Junio de 2014.
[And14b] Android Developers (2014). Get the Android SDK. Disponible en http:
//developer.android.com/sdk/index.html. Consultado el 09 de Junio de
2014.
[Ant13a] Antonio Hongs Story (2013). Google Play Service Analysis (7) Google
Cloud Messaging. Disponible en http://bit.ly/1mn5MVt. Consultado el 20 de
Agosto de 2014.
[Ant13b] Antonio Hongs Story (2013). Google Play Service Analysis (8) Google In
App Billing. Disponible en http://bit.ly/1AyXYIt. Consultado el 20 de Agosto
de 2014.
[Ant14] Antares Agile Solutions (2014). Scrum: Making Software a Contact Sport.
Disponible en http://bit.ly/XAx70F. Consultado el 20 de Agosto de 2014.
[App10] Apple Inc. (2010). Apple Launches iPad. Disponible en http://www.apple.
com/pr/library/2010/01/27Apple-Launches-iPad.html. Consultado el 08
de Junio de 2014.
[Ard14a] Arduino (2014). Arduino - ArduinoBoardUno. Disponible en http://
arduino.cc/en/Main/arduinoBoardUno. Consultado el 06 de Junio de 2014.
[Ard14b] Arduino (2014). Arduino Ethernet. Disponible en http://arduino.cc/en/
Main/ArduinoBoardEthernet. Consultado el 16 de Junio de 2014.
[Ban93] J. P. Bansler, K. Bodker.(1993) A Reappraisal of Structured Analysis: Design in
an Organisational Context. ACM Transactions on Information Systems Vol. 11, N2
pp. 165-193.
[Bea14] BeagleBone.org Foundation (2014). BeagleBone Black. Disponible en http:
//beagleboard.org/Products/BeagleBone+Black. Consultado el 16 de Junio
de 2014.
[Ben07] Benavente J. (2009). Hacia una estrategia nacional de innovacin para la
competitividad. Disponible en http://www.cepal.org/argentina/noticias/
noticias/2/29782/Sem_ID_BENAVENTE.pdf. Consultado el 06 de Junio de 2014.

95

[Bos09] Bosch J. (2009). From Software Product Lines to Software Ecosystems.

Disponible
en
http://www.janbosch.com/Jan%20Bosch/Composition_
files/SPLC09-SoftwareEcosystems-Accepted.pdf. Consultado el 08 de
Junio de 2014.
[Bus14] Business Insider (2014). This Chart Shows Googles Incredible Domination
Of The Worlds Computing Platforms. Disponible en http://read.bi/1kU8eoO.
Consultado el 08 de Junio de 2014.
[Cas] Rubby Casallas, Andrs Yie Ingeniera de software, Ciclos de vida y metolologias.
Disponible en https://sistemas.uniandes.edu.co/~isis2603/dokuwiki/
lib/exe/fetch.php?media=principal:
isis2603-modelosciclosdevida.pdf. Consultado el 16 de Abril de 2015.
[Cas] Castellano G. (n. d.). Algunos elementos bsicos para el desarrollo de sistemas de
produccion ovina en la zona sur del pas Disponible en http://bit.ly/1nFIoS5.
Consultado el 18 de Julio de 2014.
[Chi] Chiang M. & Yang M. (n. d.). Towards Network X-ities From a Topological Point
of View: Evolvability and Scalability. Disponible en http://www.cs.unm.edu/
~karlinjf/papers/allerton.pdf. Consultado el 21 de Junio de 2014.
[Chi09] Buratti C., Conti A., Dardari D., & Verdone R. (2009). An Overview on Wireless
Sensor Networks Technology and Evolution. Disponible en http://www.mdpi.
com/1424-8220/9/9/6869/pdf. Consultado el 06 de Junio de 2014.
[Cis11]
Cisco Internet Business Solutions Group. (2011).
The Internet of
Things. Disponible en http://www.cisco.com/web/about/ac79/docs/innov/
IoT_IBSG_0411FINAL.pdf. Consultado el 06 de Junio de 2014.
[Dav95] Davis, Alan M. (1995). 201 Principles of Software Development McGraw-Hill,
Inc. New York, NY, USA ISBN 0-07-015840-1.
[Dev13] DeveloperEconomics (2013). Developer Economics Q3 2013. Disponible en
http://www.developereconomics.com/reports/q3-2013/. Consultado el 08
de Junio de 2014.
[Dig12] Digi International Inc. (2012). XBee & Xbee-PRO OEM RF Module
Antenna Considerations.
Disponible en http://ftp1.digi.com/support/
images/XST-AN019a_XBeeAntennas.pdf. Consultado el 18 de Julio de 2014.
[Dig14a] Digi International Inc. (2014). XBee: Connect Devices To The Cloud - Digi
International. Disponible en http://www.digi.com/xbee/. Consultado el 11 de
Junio de 2014.
[Dig14b] Digi International Inc. (2014). XBee 802.15.4. Disponible en http://bit.
ly/1y98FkI. Consultado el 16 de Junio de 2014.
[Dig14c] Digi International Inc. (2014). The DigiMeshTM Networking Protocol.
Disponible en http://www.digi.com/technology/digimesh/. Consultado el
21 de Julio de 2014.
[Eco10] The Economist (2010). Augmented business. Disponible en http://www.
economist.com/node/17388392. Consultado el 09 de Junio de 2014.

96

[Eng12]
Engadget (2012).
IDC: nearly 1 billion smart connected devices
shipped last year. Disponible en http://www.engadget.com/2012/03/28/
idc-1-billion-smart-connected-devices-shipped-2011/. Consultado el
09 de Junio de 2014.
[Ewe13] EWEBYTE (2013). Ewe Byte Story. Disponible en http://ewebyte.com/
EBstory.htm. Consultado el 11 de Junio de 2014.
[Fao97] Organizacin de las Naciones Unidas para la Agricultura y la Alimentacin.
(1997).
Anlisis de sistemas de produccin animal Tomo 1: Las bases
conceptuales.
Disponible en http://www.fao.org/docrep/004/w7451s/
W7451S00.htm#TOC. Consultado el 16 de Junio de 2014.
[Fen11] FENABUS. (2011). SINACH: Historia. Disponible en http://www.fenabus.
cl/?page_id=467. Consultado el 06 de Junio de 2014.
[Fia08] Fundacin para la innovacin agraria (2008). Resultados y lecciones en
produccin de leche y queso de Oveja Latxa. Disponible en http://bit.ly/
1tOp7Su. Consultado el 06 de Junio de 2014.
[Fia09] Fundacin para la innovacin agraria (2009). Agenda de innovacin agraria
territorial Regin de los Ros. Disponible en http://bit.ly/1tOp7Su. Consultado
el 06 de Junio de 2014.
[Fra11] Di Francesco M., Anastasi G., Conti M., Das S., & Neri V. (2011). Reliability
and Energy-efficiency in IEEE 802.15.4/ZigBee Sensor Networks: An Adaptive
and Cross-layer Approach. Disponible en http://www.researchgate.net/
publication/220640039_Reliability_and_Energy-Efficiency_inIEEE_
802.15.4ZigBee_Sensor_Networks_An_Adaptive_and_Cross-Layer_
Approach/file/9c960518ab9a9bb417.pdf. Consultado el 06 de Junio de 2014.
[Gar14] Gartner, Inc. (2014). Gartner Says Annual Smartphone Sales Surpassed Sales of
Feature Phones for the First Time in 2013. Disponible en http://www.gartner.
com/newsroom/id/2665715. Consultado el 06 de Junio de 2014.
[Goo14a] Google Inc. (2014). Nexus - Google. Disponible en http://www.google.
com/intl/all/nexus/. Consultado el 09 de Junio de 2014.
[Goo14b] Google Inc. (2014). Google Play Services. Disponible en http://
developer.android.com/google/play-services/index.html. Consultado
el 16 de Junio de 2014.
[Het88] Hetzel, Bill (1988). The Complete Guide to Software Testing QED Information
Sciences, Inc. Wellesley, MA, USA ISBN 0-89435-242-3, 9780471565673
[Hea14] Heath S. (2003). Embedded Systems Design. Elsevier Science, Burlington.
Consultado el 06 de Junio de 2014.
[Hid13] HID Global Corporation (2013). Animal Identification. Disponible en http:
//bit.ly/1hKnXYl. Consultado el 09 de Junio de 2014.
[Hil11]
Hillbert M. (2011).
The worlds technological capacity to handle
information. Disponible en http://martinhilbert.net/WorldInfoCapacity.
html. Consultado el 06 de Junio de 2014.

97

[Hon09] Honeywell International Inc. (2009). 2-Axis Compass with Algorithms

HMC6352.
Disponible en http://aerospace.honeywell.com/~/media/
UWSAero/common/documents/myaerospacecatalog-documents/
Missiles-Munitions/HMC6352.pdf. Consultado el 16 de Junio de 2014.
[Iee90] The Institute of Electrical and Electronics Engineers, IEEE(1990). IEEE Standard
Glossary of Software Engineering Terminology. Disponible en http://dis.unal.
edu.co/~icasta/ggs/Documentos/Normas/610-12-1990.pdf. Consultado el
21 de Abril de 2015.
[Iee10] IEEE 802 LAN/MAN Standards Committee (2010). IEEE 802.15 WPANTM Task
Group 4 (TG4). Disponible en http://www.ieee802.org/15/pub/TG4.html.
Consultado el 06 de Junio de 2014.
[Iee11a] IEEE LAN/MAN Standards Committee (2011). Part 15.4: Low-Rate Wireless
Personal Area Networks (LR-WPANs). Disponible en http://standards.ieee.
org/getieee802/download/802.15.4-2011.pdf. Consultado el 06 de Junio de
2014.
[Iee11b] IEEE Spectrum (2011). The Making of Arduino. Disponible en http:
//spectrum.ieee.org/geek-life/hands-on/the-making-of-arduino.
Consultado el 11 de Junio de 2014.
[Iee14] IEEE Internet of Things (2014). About | IEEE Internet of Things. Disponible en
http://iot.ieee.org/about.html. Consultado el 06 de Junio de 2014.
[Ind] Industrial ethernet book (n.d.). Bridging Wireless Sensor Networks and Ethernet.
Disponible en http://bit.ly/1kMXfyy. Consultado el 07 de Junio de 2014.
[Int13]
Intermec (2013).
Operating System Strategy for Mobile Computers.
Disponible en http://www.intermec.com/public-files/white-papers/en/
wp-OS-Strategy-for-Mobile-Computers.pdf. Consultado el 08 de Junio de
2014.
[Jac09] Jacobs A. (2009). The patologies of Big Data. Disponible en http://queue.
acm.org/detail.cfm?id=1563874. Consultado el 09 de Junio de 2014.
[Jun03] Jun J. & Sichitiu M.(2003). The Nominal Capacity of Wireless Mesh Networks.
Disponible en http://networking.ncsu.edu/capacityWCM.pdf. Consultado
el 22 de Julio de 2014.
[Ker12] Kerkhove D. (2012). Home Automation System An engineering project (EE5).
Disponible en http://bit.ly/YB5sgl. Consultado el 20 de Agosto de 2014.
[Lar99] Larman Craig. (1999). UML y Patrones, Introduccin al Anlisis y Diseo
Orientado a Objetos. Pearson Educacin S.A. pp. 83-159.
[Lar99a] Larman Craig. (1999). UML y Patrones, Introduccin al Anlisis y Diseo
Orientado a Objetos. Pearson Educacin S.A. pp. 162.
[Lew04] Lewis F. (2004). Wireless Sensor Networks. Disponible en http://210.
32.200.159/download/20100130212654891.pdf. Consultado el 06 de Junio de
2014.
[Lhc08] CERN (2008). LHC: the guide. Disponible en http://cds.cern.ch/record/
1092437?ln=en. Consultado el 09 de Junio de 2014.
98

[Lib14a] Libelium (2012). About. Disponible en http://www.libelium.com/es/

company/. Consultado el 11 de Junio de 2014.
[Lib14b] Libelium Comunicaciones Distribuidas S.L (2014). Waspmote VS Arduino.
Disponible en http://www.cooking-hacks.com/documentation/tutorials/
waspmote#waspmote_vs_arduino. Consultado el 14 de Junio de 2014.
[Lib14c]
Libelium Comunicaciones Distribuidas S.L (2014).
The Shield.
Disponible en http://www.cooking-hacks.com/documentation/tutorials/
arduino-xbee-shield#step1. Consultado el 16 de Junio de 2014.
[Lif14] LIFX Labs (2014). The lightbulb reinvented. Disponible en http://lifx.co/.
Consultado el 11 de Junio de 2014.
[Min13] Ministerio de Desarrollo Social (2013). Ciclo de Vida de los Proyectos,Curso
Preparacin y Evaluacin Social de Proyectos, Sistema Nacional de Inversiones
. Disponible en http://sni.ministeriodesarrollosocial.gob.cl/fotos/
02%20ciclo%20de%20vida%20%202013.pdf. Consultado el 16 de Abril de 2015.
[Min13a]
Ministerio de Desarrollo Social (2013).
Ciclo de Vida de los
Proyectos. Disponible en http://www.munitel.cl/eventos/seminarios/
html/documentos/2012/PREPARACION_Y_EVALUACION_DE_INICIATIVAS_DE_
INVERSION_CON_RECURSOS_PUBLICOS/PPT07.pdf. Consultado el 17 de Abril de
2015.
[Mye11] Myers, Glenford J., Badgett, Tom and Sandler, Corey (2011). The art of
Software Testing, 3rd Edition. John Wiley and Sons.
[Mat10] Mattern F. & Floerkemeier C. (2010). From the Internet of Computers to the
Internet of Things. Disponible en http://www.vs.inf.ethz.ch/publ/papers/
Internet-of-things.pdf. Consultado el 06 de Junio de 2014.
[Mas12] Mashable (2012). Cow collar texts ranchers when animals are sick, in heat.
Disponible en http://on.mash.to/1oEXHPy. Consultado el 09 de Junio de 2014.
[Mik13] Mikal Hart (2014). TinyGPS. Disponible en http://arduiniana.org/
libraries/tinygps/. Consultado el 16 de Junio de 2014.
[Nht14] National Highway Traffic Safety Administration (2014). Distracted Driving |
National Highway Traffic Safety Administration | Texting and Driving. Disponible
en http://www.distraction.gov/. Consultado el 08 de Junio de 2014.
[Ope07] Open Handset Alliance (2007). Alliance FAQ. Disponible en http://www.
openhandsetalliance.com/oha_faq.html. Consultado el 08 de Junio de 2014.
[PMI13] Project Management Institute, (2013). Gua de los fundamentos para la direccin
R
de proyectos (gua del PMBOK ).
Quinta edicin. Newtown Square, Pensilvania
19073-3299 EE.UU. ISBN 978-1-62825-009-1. pp. 3
[Pre02] Pressman Roger S., (2002). Ingeniera del Software, un enfoque prctico. Quinta
edicin. McGraw-Hill/Interamericana de Espaa,S.A.U. Edificio Valrealty, 1era
planta. Basauri,17. 28023 Avarca, Madrid ISBN 84-481-3214-9. pp. 182.
[Pre02a] Pressman Roger S., (2002). Ingeniera del Software, un enfoque prctico. Quinta
edicin. McGraw-Hill/Interamericana de Espaa,S.A.U. Edificio Valrealty, 1era
planta. Basauri,17. 28023 Avarca, Madrid ISBN 84-481-3214-9. pp. 182-218.
99

[Pre02b] Pressman Roger S., (2002). Ingeniera del Software, un enfoque prctico. Quinta
edicin. McGraw-Hill/Interamericana de Espaa,S.A.U. Edificio Valrealty, 1era
planta. Basauri,17. 28023 Avarca, Madrid ISBN 84-481-3214-9. pp. 281.
[Pre02c] Pressman Roger S., (2002). Ingeniera del Software, un enfoque prctico. Quinta
edicin. McGraw-Hill/Interamericana de Espaa,S.A.U. Edificio Valrealty, 1era
planta. Basauri,17. 28023 Avarca, Madrid ISBN 84-481-3214-9. pp. 15.
[Pal13] Palma P. & Carrasco D. (2013). Laboratorios virtuales: manual de manejo y
sanidad ovina. Disponible en http://bit.ly/SgemfA. Consultado el 06 de Junio
de 2014.
[Pcm] PC Magazine (n.d.). Definition of: Smartphone. Disponible en http://
www.pcmag.com/encyclopedia/term/51537/smartphone. Consultado el 08 de
Junio de 2014.
[Pho13] PhoneArena (2013). Androids Google Play beats App Store with over 1 million
apps, now officially largest. Disponible en http://bit.ly/Jim4kT. Consultado el
08 de Junio de 2014.
[Rap14] Andrew Rapp (2014). Arduino library for communicating with XBees
in API mode. Disponible en https://code.google.com/p/xbee-arduino/.
Consultado el 16 de Junio de 2014.
[Rfi09] RFID Journal. (2009). That Internet of Things Thing. Disponible en http:
//www.rfidjournal.com/articles/view?4986. Consultado el 06 de Junio de
2014.
[Rob12a] RoboSavvy (2012). ARIAG25-256: ARM9 Linux Embedded Module.
Disponible en http://bit.ly/SNhobR. Consultado el 11 de Junio de 2014.
[Rtc13] RTC Magazine (2013). Unlocking the Potential of Big Data in LowPower Wireless Sensor Networks. Disponible en http://www.rtcmagazine.com/
articles/view/102975. Consultado el 20 de Agosto de 2014.
[Som05] Sommerville Ian (2005). Ingeniera del Software. Sptima Edicion. Pearson
Educacin S.A Ribera del Loira, 28 28042 Madrid, Espaa ISBN 84-7829-074-5.
pp. 108.
[Som05a] Sommerville Ian (2005). Ingeniera del Software. Sptima Edicion. Pearson
Educacin S.A Ribera del Loira, 28 28042 Madrid, Espaa ISBN 84-7829-074-5.
pp. 124-126.
[Som05b] Sommerville Ian (2005). Ingeniera del Software. Sptima Edicion. Pearson
Educacin S.A Ribera del Loira, 28 28042 Madrid, Espaa ISBN 84-7829-074-5.
pp. 71-73.
[Sag14a] Servicio Agricola y Ganadero (2014). Qu es y qu hace el SAG?. Disponible
en
http://www.sag.cl/quienes-somos/que-es-y-que-hace-el-sag.
Consultado el 11 de Junio de 2014.
[Sag14b] Servicio Agricola y Ganadero (2014). Programa de Planteles Animales
bajo Certificacin Oficial (PABCO). Disponible en http://bit.ly/1oUqqy2.
Consultado el 11 de Junio de 2014.

100

[Sag14c] Servicio Agricola y Ganadero (2014). Planteles de Animales Tradicionales bajo

Certificacin Oficial. Disponible en http://bit.ly/1uY3IIU. Consultado el 11
de Junio de 2014.
[Sag14d] Servicio Agricola y Ganadero (2014). Planteles de Animales Ovinos
bajo Certificacin Oficial. Disponible en http://www.sag.cl/sites/default/
files/I-PP-IT-018_ovinos.pdf. Consultado el 11 de Junio de 2014.
[Sag14e] Servicio Agricola y Ganadero (2014). Identificacin Animal Oficial. Disponible
en http://bit.ly/1mRDcuJ. Consultado el 13 de Junio de 2014.
[Sag14f] Servicio Agricola y Ganadero (2014). Identificacin Animal Oficial. Disponible
en http://bit.ly/1n9I7Z8. Consultado el 13 de Junio de 2014.
[San10] Snchez M., Palacios C., Rodrguez L. & Olmedo S. (2010). Estudio
del comportamiento de ovejas en pastoreo libre utilizando tecnologas GPSGPRS. Disponible en http://www.oviespana.com/extras/servicio_de_
informacion/monograficos/pastoreocontroladogps.pdf. Consultado el 07
de Junio de 2014.
[Scr13] Scrum.org (2014). U.S. English Scrum Guide (July 2013). Disponible en
https://www.scrum.org/Scrum-Guide. Consultado el 3 de Agosto de 2014.
[Sel14] TGM Software Solution Ltd. (2014). About Us. Disponible en http://www.
tgmsoftware.com/about.htm. Consultado el 11 de Junio de 2014.
[Sen13] Sensors Online (2013). The Smart City project in Santander. Disponible en
http://bit.ly/1lgXnS22. Consultado el 11 de Junio de 2014.
[She09] Shelby Z. & Bormann C. (2011). 6LoWPAN:The Wireless Embedded Internet.
Disponible en http://bit.ly/1z2QmeL. Consultado el 06 de Junio de 2014.
[She13] Sheep Tracker (2013). Sheep Tracker | The Future of Flock Management.
Disponible en http://www.sheeptracker.com/. Consultado el 11 de Junio de
2014.
[Sub11] Subsecretara de Telecomunicaciones - Gobierno de Chile (2011). Proyecto
Bicentenario Red de Internet Rural: Todo Chile Comunicado. Disponible en
http://bit.ly/Um6Lxb. Consultado el 22 de Julio de 2014.
[Taf12] Taffernaberry C. (2012). IPv6 for Wireless Sensor Network. Disponible en http:
//www.sase.com.ar/2012/files/2012/09/4-2012-SASE-6lowpan.pdf.
Consultado el 06 de Junio de 2014.
[Tec11] TechTerms (2011). Tablet Definition. Disponible en http://www.techterms.
com/definition/tablet. Consultado el 08 de Junio de 2014.
[Tec14] TechRepublic (2014). Apple v. Google: The goliath deathmatch by the
numbers in 2014. Disponible en http://www.techrepublic.com/article/
apple-v-google-the-goliath-deathmatch-by-the-numbers-in-2014/.
Consultado el 08 de Junio de 2014.
[Tra13] Dairymac Limited (2013). Track a Cow | In-Heat & Cow movement telemetry
system. Disponible en http://www.trackacow.co.uk/. Consultado el 09 de
Junio de 2014.
101

[Uac14] Universidad Austral de Chile (2014). Clima UACh - Miraflores. Disponible en

http://clima.inf.uach.cl. Consultado el 31 de Julio de 2014.
[Usg14] USGlobalSat Inc. (2014). EM-406a (SiRF III). Disponible en http://bit.
ly/1rmXuUY. Consultado el 16 de Junio de 2014.
[Viv12] ViveAgro! (2012). Neozelandeses capacitan a pequeos productores ovinos.
Disponible en http://www.viveagro.cl/index.php/16023/. Consultado el 06
de Junio de 2014.
[Zei14] Optical Zeitgeist Laboratory (2014). Personal Area Networks. Disponible en
http://zeitgeistlab.ca/doc/personal-area-networks.html. Consultado
el 06 de Junio de 2014.

102

Anexo A: Formulario de Movimiento Animal.

Solicitar documento original en cualquier oficina del SAG o unidad de Carabineros de Chile

Programa Oficial de Trazabilidad Animal

FORMULARIO DE MOVIMIENTO ANIMAL (FMA)

FOLIO N

ANTES DE COMPLETAR LEA LAS INSTRUCCIONES AL REVERSO.

USAR LETRAS Y NMEROS LEGIBLES PARA EVITAR CONTRATIEMPOS EN LA FISCALIZACIN
DURANTE EL TRANSPORTE Y/O RECHAZO EN EL ESTABLECIMIENTO DE DESTINO.
USO EXCLUSIVO SAG / CARABINEROS
RUP DEL ESTABLECIMIENTO DE ORIGEN (2)

RUT DEL/LA SOLICITANTE (1)

Nombre, firma y timbre funcionario/a SAG o Carabinero (3)

COMUNA

mi
bl

RUT

ORIGEN DE ANIMALES

Nombre de quien autoriza la salida (4)

APELLIDO PATERNO / APELLIDO MATERNO / NOMBRES

(5)

RUT
Firma

im
pri

APELLIDO PATERNO / APELLIDO MATERNO / NOMBRES

RUT

VEHCULO (patente)

NOMBRE O DIRECCIN DEL ESTABLECIMIENTO DE DESTINO (7)

ACOPLADO (patente)

DESTINO DE ANIMALES

RUP DEL ESTABLECIMIENTO DE DESTINO (8)

COMUNA

no

Nombre de quien recibe (9)

APELLIDO PATERNO / APELLIDO MATERNO / NOMBRES

RUT

(10)

Firma

nto
NOVILLO

BUEY

TORO

OVINOS

CAPRINOS

ALPACAS

JABALES

BUBALINOS

4.
5.
6.
7.
8.

Do

9.

cu

3.

me

PORCINOS

LLAMAS

10.

TERNERO/A
CRVIDOS

Nmero de DIIO (12)

11.

21.

12.

22.

13.

23.

14.

24.

15.

25.

16.

26.

17.

27.

18.

28.

19.

29.

20.

30.

DISEO: DEPARTAMENTO DE CLIENTES Y COMUNICACIONES, SAG.

VAQUILLA

EQUINOS

2.

FECHA DE
LLEGADA
HORA DE
LLEGADA

ESPECIE ANIMAL TRANSPORTADA (11)

BOVINOS:

1.

(1)

ANTECEDENTES DEL TRANSPORTE (6)

Nombre del transportista

VACA

FECHA DE
SALIDA
HORA DE
SALIDA

OBSERVACIONES (13)

CUANDO RECIBA ESTE FORMULARIO DEBE HACERLO

LLEGAR A UNA OFICINA SAG

(14)

(15)

USO EXCLUSIVO DEL SAG

FECHA DE RECEPCIN OFICINA SAG

MARCA, SEAL O TATUAJE

ORIGINAL: OFICINA SAG DE DESTINO

103

Anexo B: Diagrama de clases.

104

Anexo C: Sketch nodo de sensores.

#include <SoftwareSerial.h>
#include <TinyGPS.h>
#include <Wire.h>
#include <XBee.h>

#define RXPIN 3
#define TXPIN 5
#define GPSBAUD 4800

TinyGPS gps;
SoftwareSerial uart_gps(RXPIN, TXPIN);

void getgps(TinyGPS &gps);

int HMC6352SlaveAddress = 0x42;

int HMC6352ReadAddress = 0x41; //"A" in hex, A command is:
float direccion, latitud, longitud = 0;

uint8_t text[10] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0};

uint8_t tramaBoton[2] = { 1, 1 };
XBee xbee = XBee();
Tx16Request tx = Tx16Request(0x1000, text, sizeof(text));
Tx16Request txBoton = Tx16Request(0x1000, tramaBoton, sizeof(tramaBoton));

const int buttonPin = 2;

int botonValue = 0;

int banderaSend = 0;

105

void setup(){
pinMode(buttonPin,INPUT);

HMC6352SlaveAddress = HMC6352SlaveAddress >> 1;

Serial.begin(9600);
uart_gps.begin(GPSBAUD);
Wire.begin();

Serial.println("waiting for signal");

}

void loop(){
botonValue = digitalRead(buttonPin);

// read input value

if (botonValue == HIGH) {
xbee.send(txBoton);
banderaSend = 1;
delay(20000);
}

//Read the serial port to see if GPS data is available

while(uart_gps.available() && banderaSend !=0){
byte c = uart_gps.read();
//If incoming data is GPS data, process it
if(gps.encode(c)){
gps.f_get_position(&latitud, &longitud);
float direccion = compass();
if (latitud != 0 && longitud != 0){
sending(latitud,longitud,direccion);
delay(30000);
}
}
}
}
106

void sending(float lat, float lon, double grados){

double enteraLon, fraccLon, enteraLat, fraccLat;
int banderaSign;

//linda idea para ahorrar un espacio del array

//flag que indica signos de coordenadas y si se pasa de 255o la brujula
//saludos a las limitaciones de los xbee
// (o mas bien a los creadores del protocolo)
//uint8_t = 0 a +255

if (lat < 0 && lon < 0){ // ambos negativos

banderaSign = 0;
} else if (lat > 0 && lon < 0){ // lat pos, lon neg
banderaSign = 1;
} else if (lat < 0 && lon > 0){ // lat neg, lon pos
banderaSign = 2;
} else {

//ambos positivos

banderaSign = 3;
}
int direcc = int(grados);
if (direcc > 255){
banderaSign = banderaSign + 10;
direcc = direcc - 255;
}

fraccLon = modf(lon, &enteraLon);

fraccLat = modf(lat, &enteraLat);

String dLon = String(int(abs(fraccLon*10000)));

String dLat = String(int(abs(fraccLat*10000)));

text[0] = banderaSign;
text[1] = int(abs(enteraLon));
107

text[2] = dLon.substring(0,2).toInt();
text[3] = dLon.substring(2,4).toInt();
text[4] = int(abs(enteraLat));
text[5] = dLat.substring(0,2).toInt();
text[6] = dLat.substring(2,4).toInt();
text[7] = direcc;
xbee.send(tx);
}

float compass(){
//"Get Data. Compensate and Calculate New Heading"
Wire.beginTransmission(HMC6352SlaveAddress);
Wire.write(HMC6352ReadAddress);

// The "Get Data" command

Wire.endTransmission();

//time delays required by HMC6352 upon receipt of the command

//Get Data. Compensate and Calculate New Heading : 6ms
delay(6);

Wire.requestFrom(HMC6352SlaveAddress, 2);

//"The heading output data will be the value in tenths of degrees

//from zero to 3599 and provided in binary format over the two bytes."
byte MSB = Wire.read();
byte LSB = Wire.read();

float headingSum = (MSB << 8) + LSB; //(MSB / LSB sum)

float headingInt = headingSum / 10;

return headingInt;
}

108

Anexo D: Sketch nodo coordinador.

//BASE!!!!
#include <XBee.h>
#include <SPI.h>
#include <Ethernet.h>

byte mac[] = { 0x90, 0xA2, 0xDA, 0x0E, 0xE2, 0x39 };

IPAddress ip(192,168,2,64);
//IPAddress server(192,168,2,254);
char server[] = "diegoz.bounceme.net";
EthernetClient client;

XBee xbee = XBee();

XBeeResponse response = XBeeResponse();
// create reusable response objects for responses we expect to handle
Rx16Response rx16 = Rx16Response();

int signos, grados = 0;

uint16_t addr16 = 0;
String direccion16 = "";
float longitud,latitud;
int largoPkt = 0;

uint8_t text[10] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0};

void setup() {
// put your setup code here, to run once:
109

Serial.begin(9600);
xbee.setSerial(Serial);

if (Ethernet.begin(mac) == 0) {
Serial.println("Failed to configure Ethernet using DHCP");
// no point in carrying on, so do nothing forevermore:
// try to congifure using IP address instead of DHCP:
Ethernet.begin(mac, ip);
}

void loop() {
xbee.readPacket();
// put your main code here, to run repeatedly:
if (xbee.getResponse().isAvailable()) {
if (xbee.getResponse().getApiId() == RX_16_RESPONSE) {
//primero es lo primero, pescar el paquete
xbee.getResponse().getRx16Response(rx16);
largoPkt = rx16.getDataLength();
direccion16 = "";
float longitud,latitud = 0;
int grados = 0;
//direccion del xbee
addr16 = rx16.getRemoteAddress16();
direccion16 = String(addr16, HEX);
Serial.println(largoPkt);
if (largoPkt == 2){

alta(direccion16);

} else if (pargoPkt == 3) {

alerta(direccion16);
110

} else if (largoPkt == 10){

//elemento de signos de mediciones
signos = rx16.getData(0);
//longitud, parte entera
longitud = rx16.getData(1);
//longitud, primeros dos decimales
longitud = longitud + 0.01*(rx16.getData(2));
//longitud, tercer y cuarto decimal
longitud = longitud + 0.0001*(rx16.getData(3));
//latitud, parte entera
latitud = rx16.getData(4);
//latitud, primeros dos decimales
latitud = latitud + 0.01*(rx16.getData(5));
//latitud, tercer y cuarto decimal
latitud = latitud + 0.0001*(rx16.getData(6));
//grados de brujula con respecto al norte
grados = rx16.getData(7);
postproceso(signos,longitud,latitud,grados,direccion16);
}
}
}
}

void alta(String addrFinal){

if(client.connect(server, 80)>0) {

Serial.println("Connectando Alta");
client.print("GET http://diegoz.bounceme.net/alta.php?addr=");
client.print(addrFinal);
client.println(" HTTP/1.1");
client.println("Host: www.server.com");
client.println();
Serial.println();
111

} else {
Serial.println("Connection unsuccesfull");
}
client.stop();
while(client.status() != 0){
delay(5);
}

void alerta(String addrFinal){

if(client.connect(server, 80)>0) {

Serial.println("Connectando Alerta");
client.print("GET http://diegoz.bounceme.net/alerta.php?addr=");
client.print(addrFinal);
client.println(" HTTP/1.1");
client.println("Host: www.server.com");
client.println();
Serial.println();
} else {
Serial.println("Connection unsuccesfull");
}
client.stop();
while(client.status() != 0){
delay(5);
}

void postproceso(int sign,float lon,float lat, int grad, String address){

//si ambos son negativos, grados menor a 255
int flag,gradoFinal = 0;
float lonFinal, latFinal = 0;
112

if (sign > 9){

flag = sign - 10;
gradoFinal = grad + 255;
} else {
flag = sign;
gradoFinal = grad;
}
//parseo de acuerdo a codigo de end device
if (flag == 0){
lonFinal = lon*(-1);
latFinal = lat*(-1);
} else if (flag == 1){
lonFinal = lon*(-1);
latFinal = lat;
} else if (flag == 2){
lonFinal = lon;
latFinal = lat*(-1);
} else if (flag == 3){
lonFinal = lon;
latFinal = lat;
}
sending(gradoFinal,lonFinal,latFinal,address);
}

void sending(int gradFinal, float lonFinal, float latFinal, String addrFinal){

if(client.connect(server, 80)>0) {
Serial.println("Connected Data");
client.print("GET http://diegoz.bounceme.net/data.php?addr=");
client.print(addrFinal);
client.print("&");
client.print("heading=");
client.print(gradFinal);
client.print("&");
113

client.print("lon=");
client.print(lonFinal,HEX);
client.print("&");
client.print("lat=");
client.print(latFinal,HEX);
client.println(" HTTP/1.1");
client.println("Host: www.server.com");
client.println();
Serial.println();
} else {
Serial.println("Connection unsuccesfull");
}
client.stop();
while(client.status() != 0){
delay(5);
}
}

114

Anexo E: Ray Casting en PHP.

<?php
/*
Description: The point-in-polygon algorithm allows you to check
if a point is inside a polygon or outside of it.
Author: Michal Niessen (2009)
Website: http://AssemblySys.com

If you find this script useful, you can show your

appreciation by getting Michal a cup of coffee ;)
PayPal: michael.niessen@assemblysys.com

As long as this notice (including author name and details) is

included and UNALTERED, this code is licensed under the
GNU General Public License version 3:
http://www.gnu.org/licenses/gpl.html
*/

class pointLocation {
var $pointOnVertex = true; // Check if the point sits exactly
on one of the vertices?

function pointLocation() {
}

function pointInPolygon($point, $polygon, $pointOnVertex = true) {

$this->pointOnVertex = $pointOnVertex;

// Transform string coordinates into arrays with x and y values

$point = $this->pointStringToCoordinates($point);
$vertices = array();
foreach ($polygon as $vertex) {
$vertices[] = $this->pointStringToCoordinates($vertex);
115

// Check if the point sits exactly on a vertex

if ($this->pointOnVertex == true and
$this->pointOnVertex($point, $vertices) == true) {
return "vertex";
}

// Check if the point is inside the polygon

or on the boundary
$intersections = 0;
$vertices_count = count($vertices);

for ($i=1; $i < $vertices_count; $i++) {

$vertex1 = $vertices[$i-1];
$vertex2 = $vertices[$i];
if ($vertex1[y] == $vertex2[y] and
$vertex1[y] == $point[y] and
$point[x] > min($vertex1[x], $vertex2[x])
and $point[x] < max($vertex1[x], $vertex2[x])) {
// Check if point is on an horizontal
polygon boundary
return "boundary";
}
if ($point[y] > min($vertex1[y], $vertex2[y])
and $point[y] <= max($vertex1[y], $vertex2[y])
and $point[x] <= max($vertex1[x], $vertex2[x])
and $vertex1[y] != $vertex2[y]) {
$xinters = ($point[y] $vertex1[y]) * ($vertex2[x] $vertex1[x]) / ($vertex2[y]
- $vertex1[y]) + $vertex1[x];
if ($xinters == $point[x]) {
// Check if point is on the
116

polygon boundary (other than horizontal)

return "boundary";
}
if ($vertex1[x] == $vertex2[x]
|| $point[x] <= $xinters) {
$intersections++;
}
}
}
// If the number of edges we passed
through is odd, then its in the polygon.
if ($intersections % 2 != 0) {
return "inside";
} else {
return "outside";
}
}

function pointOnVertex($point, $vertices) {

foreach($vertices as $vertex) {
if ($point == $vertex) {
return true;
}
}

function pointStringToCoordinates($pointString) {
$coordinates = explode(" ", $pointString);
return array("x" => $coordinates[0], "y" => $coordinates[1]);
}

}
?>
117

Anexo F: Lista de abreviaciones.

DER: Diagrama de Entidad-Relacin
DFD: Diagrama de Flujo de Datos
DFD: Diagrama de Flujo de Control
RE: Ingeniera de Requerimientos
SRS: Software Requirements Specification
UML: Unified Modeling Language
ACID: Atomicity, Consistency, Isolation, Durability
ACK: ACKnowledgement packet
API: Application Programming Interface
CPU: Central Processing Unit
DIIO: Dispositivo de Identificacin Individual Oficial
DC: Corriente directa (direct current)
EID: Electronic Identification Device
FFD: Full Function Device
GPS: Global Positioning System
HTML: HyperText Markup Language
HTTP: Hypertext Transfer Protocol
ICSP: In Circuit Serial Programming
IDE: Integrated Development Environment
IEEE: Institute of Electrical and Electronics Engineers
IETF: Internet Engineering Task Force
IoT: Internet of Things
IP: Internet Protocol
JSON: JavaScript Object Notation
LAN: Local Area Network
LAMP: Linux, Apache, MySQL, PHP
LR-WPAN: Low-rate Wireless Personal Area Network
MAC: Media Access Control layer
MVA: Mdico Veterinario Acreditado
MVO: Mdico Veterinario Oficial SAG
NIST: National Institute of Standards and Technology
OECD: Organisation for Economic Co-operation and Development
OS: Operating System
PABCO: Programa de Planteles de Animales Bajo Certificacin Oficial
PAN: Personal Area Network
PHP: PHP Hypertext Pre-processor
POS: Point Of Service
RFD: Reduced Function Device
RFID: Radio Frecuency IDentification
118

RSSI: Received Signal Strength Indicator

RUP: Rol nico Pecuario
SAG: Servicio Agricola Ganadero
SBC: Single Board Computer
SDK: Software Developer Kit
SNAP: Simple Network Access Protocol
TCP: Transmission Control Protocol
UART: Universal Asynchronous Receiver-Transmitter
UDP: User Datagram Protocol
UMTS: Universal Mobile Telecommunications System
USB: Universal Serial Bus
UML: Unified Modeling Language
WAN: Wide Area Network
WLAN: Wireless Local Area Network
WMAN: Wireless Metropolitan Area Network
WPAN: Wireless Personal Area Network
WSN: Wireless Sensor Network
WWAN: Wireless Wide Area Network
XML: eXtensible Markup Language

119