UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS … · Los avances tecnológicos mejoran continuamente...
93
UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACION INFRAESTRUCTURA DE TRABAJO COLABORATIVO MOVIL PARA INSPECCION TECNICA DE OBRAS TESIS PARA OPTAR AL GRADO DE MAGISTER EN CIENCIAS, MENCION COMPUTACION MEMORIA PARA OPTAR AL TITULO DE INGENIERO CIVIL EN COMPUTACION JUAN FRANCISCO RODRIGUEZ COVILI SANTIAGO DE CHILE 2011
Transcript of UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS … · Los avances tecnológicos mejoran continuamente...
UNIVERSIDAD DE CHILE
FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS
DEPARTAMENTO DE CIENCIAS DE LA COMPUTACION
INFRAESTRUCTURA DE TRABAJO COLABORATIVO MOVIL PARA
INSPECCION TECNICA DE OBRAS
TESIS PARA OPTAR AL GRADO DE
MAGISTER EN CIENCIAS, MENCION COMPUTACION
MEMORIA PARA OPTAR AL TITULO DE
INGENIERO CIVIL EN COMPUTACION
JUAN FRANCISCO RODRIGUEZ COVILI
SANTIAGO DE CHILE 2011
UNIVERSIDAD DE CHILE
FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS
DEPARTAMENTO DE CIENCIAS DE LA COMPUTACION
INFRAESTRUCTURA DE TRABAJO COLABORATIVO MOVIL PARA
INSPECCION TECNICA DE OBRAS
TESIS PARA OPTAR AL GRADO DE
MAGISTER EN CIENCIAS, MENCION COMPUTACION
MEMORIA PARA OPTAR AL TITULO DE
INGENIERO CIVIL EN COMPUTACION
JUAN FRANCISCO RODRIGUEZ COVILI
PROFESOR GUIA: SERGIO OCHOA DELORENZI
MIEMBROS DE LA COMISION:
CECILIA BASTARRICA PIÑEYRO ALEXANDRE BERGEL
ROSA ALARCON CHOQUE
SANTIAGO DE CHILE MAYO 2011
ii
Resumen
Los avances tecnológicos mejoran continuamente tanto el poder de cómputo de los dispositivos móviles,
como su capacidad de comunicación inalámbrica. Algunas limitaciones identificadas en este ámbito,
como por ejemplo la autonomía eléctrica, tamaño y peso de dispositivos portátiles, son superadas
rápidamente. En esa misma dirección, la disminución de costos y la adopción de estándares en redes
inalámbricas, promueven la inclusión de aplicaciones móviles en variados escenarios, tales como
educación, salud, procesos productivos y seguridad, entre otros.
En este contexto aparece la figura del espacio de trabajo compartido móvil, un concepto que se
encuentra actualmente en investigación. Aplicaciones de software creadas a partir de esta idea, ayudan
a equipos de profesionales de una organización a desarrollar actividades móviles en terreno. Más aún,
proporcionan funcionalidades para ejecutar tareas individuales y autónomas, enriqueciéndolas con
servicios de apoyo a las interacciones grupales y labores cooperativas realizadas por demanda.
La industria de la construcción, y en particular el servicio de inspección técnica de obras, es un área que
se podría beneficiar mucho del uso de los espacios de trabajo compartido móvil. Esta área involucra
personal distribuido que debe trasladarse entre distintas obras y compartir gran cantidad de
documentos y anotaciones informales con otros profesionales y contratistas. Una herramienta de
trabajo colaborativo móvil, podría jugar un rol importante en la comunicación de información de
inspecciones entre los trabajadores involucrados. Además, permitiría organizar actividades y reducir
costos de coordinación y sincronización de dicha información.
El presente trabajo de investigación estudió el impacto que un espacio de trabajo colaborativo móvil
podría tener, como apoyo al proceso de inspección de obras. Para ello se diseñó, implementó y evaluó
un espacio de trabajo compartido móvil para apoyar dicha actividad. La aplicación desarrollada otorga
múltiples funcionalidades a los distintos agentes del proceso, incluyendo: anotaciones sobre planos
digitales, designación de tareas, sincronización de observaciones, colaboración por demanda, y
localización de personal, entre otras. Estos servicios de colaboración surgieron como resultado del
estudio del escenario y la dinámica de la actividad.
Debido a que no existía un diseño de referencia para este tipo de herramienta, se definió una
arquitectura genérica a partir del estudio de sistemas ya probados. La arquitectura permitirá la
reutilización del diseño realizado, en futuros desarrollos de aplicaciones de este tipo.
Además se definió una infraestructura de comunicaciones inalámbrica que es económica, simple y no
requiere la intervención del usuario final. Esta infraestructura hace que las interacciones entre usuarios
móviles sean factibles en un escenario real de trabajo.
Los resultados obtenidos han sido altamente positivos y fortalecen la idea de incluir este tipo de
soluciones en varias otras áreas de trabajo. Al momento de concluir esta tesis, las soluciones propuestas
en comunicaciones y diseño arquitectónico, ya han sido reutilizadas por otros investigadores y
estudiantes de postgrado.
iii
Agradecimientos
Agradezco a:
• Sergio F. Ochoa, profesor asistente del Departamento de Ciencias de la Computación, quién me
ha guiado, incentivado y apoyado enormemente durante mi paso por la Universidad de Chile.
• Luis R. Peña, académico de vasta trayectoria, por sus enseñanzas e información fundamental
para el desarrollo de esta investigación.
• María Dina y Juan Ramón (mis padres), Pablo Andrés, Ana María y Pía Carolina (mis hermanos), a
todos ellos por brindarme apoyo en todos los proyectos en los cuales alguna vez me he
involucrado.
• Juan Daniel Canales y Raúl Aliaga, compañeros de estudio y amigos con quienes he podido
compartir mi tiempo, ideas y sueños.
• A los profesores José Pino Y Nelson Baloian.
• Jesús Favela y René Navarro de CICESE.
Este trabajo de tesis ha sido parcialmente financiado por el Fondo Nacional de Desarrollo Científico y
Tecnológico (Fondecyt) y Latin American and Caribbean Collaborative ICT Research (LACCIR) bajo los
proyectos: Fondecyt grant 11060467, VID ENL 10/10, Universidad de Chile y LACCIR grants
S1009LAC001 y R0308LAC005. Participaciones en escuelas internacionales de investigación han sido
financiadas por German Academic Exchange Service (DAAD).
iv
Publicaciones
Artículos científicos en los cuales se ha reportado parte del trabajo realizado en esta tesis, son los
siguientes:
Artículos de Journals
• Rodríguez-Covili, J., Ochoa, S., Pino, J., Messeguer, R., Medina, E., Royo, D.: “A Communication
Infrastructure to Ease the Development of Mobile Collaborative Applications”. Journal of Network
and Computer Applications, Article in Press, 2011.
• Rodríguez-Covili, J., Ochoa, S., Pino, J.: “High Level MANET Protocol: Enhancing the
Communication Support for Mobile Collaborative Work”. Journal of Network and Computer
Applications, Article in Press, 2011.
• Rodríguez-Covili, J., Ochoa, S., Pino, J., Herskovic, V. Favela, J., Mejía, D., Morán, A.: "Towards a
Reference Architecture for the Design of MSW". Future Generation Computer Systems, Volume
27, Issue 1, January 2011, Pages 109-118.
• Monares, A., Ochoa, S. F., Pino, J.A., Herskovic, V., Rodriguez-Covili, J., Neyem, A.: “Mobile
Computing in Urban Emergency Situations: Improving the Support to Firefighters in the Field”,
Expert Systems with Applications, Volume 38, Issue 2, February 2011, Pages 1255-1267.
• Ochoa, S., Bravo, G., Pino, J., Rodríguez-Covili, J.: “Coordinating Loosely-Coupled Work in
Construction Inspection Activities”. Group Decision and Negotiation, Volume 20, Number 1,
Pages 39-56, 2011.
Artículos en Conferencias Internacionales
• Rodríguez-Covili, J., Ochoa, S., Pino, J.: "Enhancing Mobile Collaboration with HLMP".
Proceedings of the 2010 14th International Conference on Computer Supported Cooperative
Work in Design (CSCWD’10), Shanghai, China, IEEE Press, April 2010.
• Rodríguez-Covili, J., Ochoa, S., Pino, J., Messeguer, R., Medina, E., Royo, D.: "HLMP API: A
Software Library to Support the Development of Mobile Collaborative Applications". Proceedings
of the 2010 14th International Conference on Computer Supported Cooperative Work in Design
(CSCWD’10), Shanghai, China, IEEE Press, April 2010.
• Rodríguez-Covili, J., Ochoa, S., Pino, J., Favela, J., Mejía, D., Morán, A.: "Designing Mobile Shared
Workspaces by Instantiation". Proceedings of the 2009 13th International Conference on
Computer Supported Cooperative Work in Design (CSCWD’09), Santiago, Chile, IEEE Press, 402-
407, April 2009.
• Morán, A., Rodríguez-Covili, J., Mejia, D., Favela, J., Ochoa, S.: “Supporting Informal Interaction in
a Hospital trough Impromptu Social Networking”. 16th CRIWG Conference on Collaboration and
Technology, Lecture Notes in Computer Science, 2010, Volume 6257/2010, 305-320.
v
Participaciones
Parte de este trabajo de tesis ha sido presentado en:
• 13th International Conference on Computer Supported Cooperative Work in Design. Santiago,
Chile, Abril de 2009.
• 14th International Conference on Computer Supported Cooperative Work in Design. Shanghai,
China, Abril de 2010.
• DAAD International School in Computer Science: Interface and Interaction Design for Learning
and Simulation Environments. Universidad de Duisburg-Essen, Duisburg, Alemania, Julio a Agosto
de 2009.
• DAAD International School in Computer Science. Universidad de Waseda, Tokyo, Japón, Febrero
de 2010.
• DAAD International Summer Academy. Universidad de Chile, Santiago, Chile, Agosto a
Septiembre de 2008.
Este trabajo de tesis ha sido desarrollado mayoritariamente en el Departamento de Ciencias de la
Computación de la Universidad de Chile; sin embargo en la formalización y validación de la propuesta
estuvo involucrado personal de las siguientes organizaciones:
• Centro de Investigación Científica y de Educación Superior de Ensenada (CICESE), Ensenada,
México, Marzo a Abril de 2010.
• Zona Franca de Iquique, Inspección Técnica de Obras BAU Ltda. Iquique, Chile, Enero de 2010.
vi
Índice de Contenido
Capítulo I: Introducción .......................................................................................................................................... 1
1.1 Contexto General ................................................................................................................................................. 1
1.2 La Industria de la Construcción ............................................................................................................................ 2
1.2.1 Ámbito de la Construcción en Chile .............................................................................................................. 2
1.2.2 Inspección Técnica de Obras ........................................................................................................................ 4
1.3 Trabajo Colaborativo Móvil .................................................................................................................................. 6
1.3.1 Red Móvil Ad-Hoc ......................................................................................................................................... 6
1.3.2 Escenario de Interacción Multi-Síncrona ...................................................................................................... 7
1.3.3 Espacio de Trabajo Compartido Móvil .......................................................................................................... 8
1.4 Impacto Tecnológico ............................................................................................................................................ 9
1.5 Problema a Resolver ............................................................................................................................................ 9
1.6 Hipótesis ............................................................................................................................................................ 10
1.7 Objetivos de la Tesis ........................................................................................................................................... 10
1.8 Resumen de la Solución Propuesta .................................................................................................................... 11
1.9 Trabajos Relacionados ....................................................................................................................................... 12
1.9.1 Sistemas de Trabajo Colaborativo Móvil .................................................................................................... 12
1.9.2 Sistemas de Redes Móviles Ad-Hoc ............................................................................................................ 13
1.10 Trabajos Previos ............................................................................................................................................... 14
1.10.1 Administrador de Anotaciones sobre Planos Digitales ............................................................................. 14
1.10.2 Sincronizador de Archivos XML distribuidos ............................................................................................ 14
Capítulo II: La ITO Como Trabajo Colaborativo Móvil ............................................................................................15
2.1 Estudio en Terreno ............................................................................................................................................. 15
2.1.1 Ambiente .................................................................................................................................................... 15
2.1.2 Participantes ............................................................................................................................................... 16
2.1.3 Actividades ................................................................................................................................................. 17
2.1.3.1 Supervisor ............................................................................................................................................ 17
2.1.3.2 Inspector Jefe ...................................................................................................................................... 17
2.1.3.3 Inspector Terreno ................................................................................................................................ 18
2.1.3.4 Proyectista ........................................................................................................................................... 18
2.1.3.5 Director de Obra .................................................................................................................................. 18
2.2 Esquema de Colaboración .................................................................................................................................. 18
2.2.1 Interacción entre Supervisor e Inspector Jefe ............................................................................................ 20
2.2.2 Interacción entre Inspector Jefe e Inspectores Terreno ............................................................................. 20
2.2.3 Interacción entre Inspector Jefe y Proyectista ........................................................................................... 20
2.2.4 Interacción entre Inspector Jefe y Director de Obra .................................................................................. 20
Capítulo III: Macro Estructura del Diseño ..............................................................................................................21
3.1 Diseño de MSW en Escenarios Similares ........................................................................................................... 21
3.1.1 Cuidados Médicos en Hospitales ................................................................................................................ 21
vii
3.1.1.1 Contexto .............................................................................................................................................. 22
3.1.1.2 Problema ............................................................................................................................................. 22
3.1.1.3 Solución ............................................................................................................................................... 22
3.1.2 Emergencias Urbanas de Rutina ................................................................................................................. 23
3.1.2.1 Contexto .............................................................................................................................................. 24
3.1.2.2 Problema ............................................................................................................................................. 24
3.1.2.3 Solución ............................................................................................................................................... 25
3.2 Patrón de Diseño de un MSW ............................................................................................................................ 25
3.2.1 Contexto ..................................................................................................................................................... 25
3.2.2 Problema .................................................................................................................................................... 26
3.2.3 Solución ...................................................................................................................................................... 26
3.2.3.1 Espacio de Trabajo .............................................................................................................................. 27
3.2.3.2 Mecanismo de Comunicación ............................................................................................................. 27
3.2.3.3 Mecanismo de Coordinación ............................................................................................................... 27
3.3 Concepción de un MSW para ITO ...................................................................................................................... 28
3.3.1 Espacio de Trabajo ...................................................................................................................................... 28
3.3.1.1 Datos del Dominio ............................................................................................................................... 29
3.3.1.2 Servicios del Dominio .......................................................................................................................... 29
3.3.1.3 Recursos Compartidos ......................................................................................................................... 30
3.3.2 Mecanismo de Comunicación ..................................................................................................................... 30
3.3.2.1 Servicios de Red .................................................................................................................................. 30
3.3.2.2 Mensajería ........................................................................................................................................... 30
3.3.2.3 Servicios de Comunicación .................................................................................................................. 30
3.3.3 Mecanismo de Coordinación ...................................................................................................................... 30
3.3.3.1 Espacio de Interacción......................................................................................................................... 31
3.3.3.2 Administración de Roles y Usuarios .................................................................................................... 31
3.3.3.3 Percepción de Otros Usuarios ............................................................................................................. 31
3.3.3.4 Servicios de Coordinación ................................................................................................................... 31
Capítulo IV: Interfaz Humano-Computador ...........................................................................................................32
4.1 Dispositivo Móvil ................................................................................................................................................ 32
4.1.1 Tablet PC ..................................................................................................................................................... 32
4.1.2 PDA ............................................................................................................................................................. 33
4.2 Espacio de Trabajo ............................................................................................................................................. 33
4.2.1 Administrador de Usuarios ......................................................................................................................... 33
4.2.2 Administrador de Planos ............................................................................................................................ 34
4.2.3 Administrador de Carta Gantt .................................................................................................................... 34
4.2.4 Modulo de Inspección ................................................................................................................................ 34
4.2.4.1 Archivo ................................................................................................................................................ 35
4.2.4.2 Selección de Plano ............................................................................................................................... 35
4.2.4.3 Movimiento de Plano .......................................................................................................................... 35
4.2.4.4 Herramientas de Anotación ................................................................................................................ 35
4.2.4.5 Filtro de Anotaciones .......................................................................................................................... 36
viii
4.2.4.6 Detalle de Anotación ........................................................................................................................... 36
4.2.4.7 Modo de Conexión .............................................................................................................................. 36
4.2.5 Interoperabilidad con Carta Gantt.............................................................................................................. 36
4.2.6 Módulo de Fotografías ............................................................................................................................... 38
4.3 Estructura de Información ................................................................................................................................. 38
4.4 Interfaz de Colaboración .................................................................................................................................... 38
4.4.1 Widget de Modo de Conexión .................................................................................................................... 39
4.4.2 Widget de Usuarios .................................................................................................................................... 39
4.4.3 Posición de Usuarios ................................................................................................................................... 40
4.4.4 Widget de Conversación Grupal ................................................................................................................. 40
4.4.5 Widget de Mensajes ................................................................................................................................... 40
4.4.6 Sincronización ............................................................................................................................................. 41
Capítulo V: Infraestructura de Red y Comunicaciones ...........................................................................................42
5.1 Protocolo de Comunicación ............................................................................................................................... 42
5.2 Revisión de Estándares Usados .......................................................................................................................... 43
5.2.1 IP ................................................................................................................................................................. 43
5.2.2 Wi-Fi ............................................................................................................................................................ 44
5.2.3 WLan Ad-Hoc .............................................................................................................................................. 45
5.2.4 UDP ............................................................................................................................................................. 45
5.2.5 TCP .............................................................................................................................................................. 46
5.3 Rangos de Señal Inalámbrica ............................................................................................................................. 46
5.3.1 Experimento ............................................................................................................................................... 47
5.3.1.1 Observaciones ..................................................................................................................................... 47
5.3.1.2 Conclusiones........................................................................................................................................ 48
5.3.2 Definición de Rango TCP ............................................................................................................................. 48
5.3.3 Definición de Rango UDP ............................................................................................................................ 49
5.3.4 Definición de Rango WLAN ......................................................................................................................... 49
5.4 Proceso de Conexión a la Red ............................................................................................................................ 49
5.4.1 Conexión a WLan Ad-Hoc ........................................................................................................................... 50
5.4.2 Autoconfiguración de Dirección IP ............................................................................................................. 50
5.4.3 Levantamiento de Servicios TCP y UDP ...................................................................................................... 51
5.5 Estructura de Mensajes ..................................................................................................................................... 51
5.6 Transmisión de Mensajes de Multidifusión ....................................................................................................... 53
5.6.1 Algoritmos .................................................................................................................................................. 53
5.6.2 Ejemplo ....................................................................................................................................................... 54
5.6.3 Mecanismo de Detección de Usuarios ....................................................................................................... 54
5.6.4 Calidad de Señal.......................................................................................................................................... 55
5.6.5 Estado del Tráfico ....................................................................................................................................... 56
5.6.6 Límite de la Lista ......................................................................................................................................... 56
5.6.7 Control de Carga de Mensajes .................................................................................................................... 59
5.7 Transmisión de Mensajes de Unidifusión .......................................................................................................... 59
5.7.1 Algoritmos .................................................................................................................................................. 60
ix
5.7.2 Ejemplo ....................................................................................................................................................... 62
5.8 API ...................................................................................................................................................................... 62
5.8.1 Núcleo ......................................................................................................................................................... 63
5.8.1.1 Interoperabilidad ................................................................................................................................. 63
5.8.1.2 Red ...................................................................................................................................................... 63
5.8.1.3 Comunicación ...................................................................................................................................... 63
5.8.2 Módulos Adicionales .................................................................................................................................. 65
5.8.2.1 Subprotocolos ..................................................................................................................................... 66
5.8.2.2 Interfaz ................................................................................................................................................ 66
Capítulo VI: Evaluación ..........................................................................................................................................67
6.1 Pruebas de Comunicación .................................................................................................................................. 67
6.1.1 Prueba del Tráfico de Control ..................................................................................................................... 67
6.1.2 Prueba del Tráfico de Transporte ............................................................................................................... 68
6.1.3 Prueba de Movilidad ................................................................................................................................... 69
6.2 Escenarios de Uso .............................................................................................................................................. 71
6.2.1 Inspección Rutinaria ................................................................................................................................... 71
6.2.2 Solicitud de Instrucción .............................................................................................................................. 72
6.2.3 Consulta a Proyectista ................................................................................................................................ 72
6.3 Tiempos de Trabajo............................................................................................................................................ 73
6.3.1 Inspección en Terreno ................................................................................................................................ 73
6.3.2 Sincronización de la Información ................................................................................................................ 75
Capítulo VII: Observaciones Finales .......................................................................................................................76
7.1 Conclusiones ...................................................................................................................................................... 76
7.2 Trabajo Futuro ................................................................................................................................................... 77
Bibliografía ............................................................................................................................................................79
1
Capítulo I: Introducción
El software de trabajo colaborativo (groupware) refleja un cambio que consiste en pasar de usar el
computador para resolver problemas, a usar el computador para facilitar las interacciones humanas [19].
Los avances en tecnología móvil permiten además, que dichas interacciones se puedan llevar a cabo en
todo momento y en todo lugar [54]. Estos dos términos generales son los pilares fundamentales de este
trabajo de investigación. Como instancia particular, se introduce el escenario de las inspecciones de obras
en proyectos de construcción, la mecánica general del trabajo colaborativo móvil y los distintos aspectos
de diseño, comunicación y sincronización, que en él se requieren.
1.1 Contexto General
El desarrollo de tecnología relacionada con dispositivos móviles tiende a progresar rápidamente. Estos
avances logran disminuir de manera significativa los principales y más recurrentes problemas que dichos
aparatos presentan: cansancio del usuario generado por el peso de los equipos, límite del manejo
continuo debido a baterías de corta duración, acotada capacidad del alcance de las señales de
conectividad inalámbrica, entre varios otros.
La adopción de estándares de transmisión inalámbrica y el nacimiento de nuevos conjuntos de técnicas
en comunicaciones, permiten satisfacer requerimientos para el acceso móvil a internet y aplicaciones.
Ejemplos de estos conceptos son: Wi-Fi, definido en IEEE 802.11 [34]; Bluetooth, precisado en IEEE
802.15 [35], servicios asociados a la tercera generación de telefonía y banda ancha celular (HSDPA: High-
Speed Downlink Packet Access) [38]; y la norma de transmisión por ondas de radio de largo alcance
(WiMAX: Worldwide Interoperability for Microwave Access) [65]. Estas nuevas especificaciones
convienen además, métodos de trasferencia de los servicios cuando la calidad del enlace es insuficiente,
otorgando una mayor movilidad a los usuarios, y abriendo de paso, la posibilidad de implementar
mecanismos de ahorro de energía, avanzada calidad de servicio y bajas latencias para software en
tiempo real.
Por otra parte, la reducción de costos operacionales y precios de los dispositivos, han aumentado la
factibilidad de incluir estas redes en diversos frentes de trabajo. Concretamente, pueden dar soporte a
operadores y puntos de control móviles que se encuentran alejados de las oficinas centrales, y que
necesitan estar permanentemente comunicados, tales como: centros de emergencia, donde es necesario
coordinar y proveer servicios de información a distintos tipos de organismos, que se desplazan dentro
del radio urbano (policías, bomberos, equipos de rescate y/o ambulancias) (figura 1); estaciones de
ámbito marítimo, quienes requieren comunicación y transmisión de datos (armada, productores de
petróleo y/o gas); campus universitarios, donde se debe tanto proveer conectividad a académicos y
estudiantes, como establecer servicios de transferencia de datos entre distintas facultades; compañías
de todo tipo de construcción de obras, para coordinar distintos sitios y faenas; entre varios otros [64].
2
Figura 1: Contexto de tecnología WiMAX en un escenario de control de emergencias
Sin embargo, el desarrollo y la innovación de técnicas e infraestructuras de software que dan soporte al
trabajo móvil en ambientes tradicionales, donde se encuentran grupos de trabajadores nómadas, traen
consigo grandes retos. Variaciones en las formas en las cuales se desarrollan las actividades, los procesos
productivos y de control, el manejo óptimo de tiempos y plazos, y la sincronización y coordinación de los
proyectos, son algunos de ellos. Más aún, dichos desafíos requieren cambios sustanciales al incluir
nuevas metodologías de nivel social, pues crean necesidades de adaptación a los cambios tecnológicos.
1.2 La Industria de la Construcción
La construcción de obras en Chile, constituye una actividad económica relevante para el desarrollo del
país. Es además, un sector que utiliza cuantiosos y variados recursos para materializar proyectos de todo
tipo, y que requiere participación y colaboración de profesionales y especialistas multidisciplinarios.
Muchos de estos trabajadores se encuentran usualmente dispersos en distintos lugares y en constante
movilidad.
Dentro de esta industria, existe una permanente competitividad que busca mejorar la productividad,
entre otras cualidades. Más aún, diversas investigaciones y estudios en tecnología son aplicados
constantemente, con el objetivo de actuar con rapidez ante cualquier problema en terreno, derivado de
una duda, inconsistencia o problema de proyecto.
Todo esto influye en que este ámbito sea el foco de instancia principal de la presente investigación, con
el fin de mejorar sustancialmente la calidad de sus resultados.
1.2.1 Ámbito de la Construcción en Chile
Dentro del panorama económico en Chile, el negocio de la construcción constituye un agente importante
del desarrollo productivo, en términos de inversión y oportunidades de trabajo. Estadísticas de la
3
Cámara Chilena de la Construcción indican que alrededor de 550.000 personas se encontraban
trabajando en esta área en el 2007, cifra que ha estado creciendo desde el año 2003, en contraste a los
índices de cesantía del mismo sector (figura 2) [8].
Figura 2: Gráfico de empleo en la construcción entre los años 2003 a 2007
Por otro lado, las concesiones para infraestructura y desarrollo urbano alcanzaron, a nivel nacional, los
US$4.6 billones entre el 2001 y el 2003. Para el 2004, fueron aprobados nuevos proyectos en concesión,
por un total de US$0.9 billones [61]. Se estima que el Ministerio de Obras Públicas, Telecomunicaciones y
Transporte (MOPTT) habría tenido un gasto en proyectos de infraestructura de uso público de $567.481
millones, en el 2007 [10]. Durante el primer semestre del 2008 se usaron además, $309.735 millones en
la misma área, cifra 49,7% superior, en términos nominales, a la invertida con igual propósito en el
mismo período del año 2007 (38,6% en términos reales) [11]. Durante el año 2008 se potenciaron
además, las inversiones en proyectos de infraestructura, destacando cuantiosos recursos que se
destinaron a la minería, energía e inmobiliarios no habitacionales (oficinas, comercio, turismo). Asimismo
otros proyectos importantes fueron planificados para la ampliación de la red del Metro de Santiago y
diversos servicios sanitarios.
No obstante, y debido a un fuerte impacto en esta área proveniente de la recesión económica mundial,
un importante número de proyectos inmobiliarios se paralizaron durante los primeros meses del año
2009. Este evento arrastró al desempleo una cifra importante de obreros, técnicos y profesionales
estimada en más de 100 mil, influyendo considerablemente en los índices de cesantía (figura 3) [9].
Tan crítica realidad origina diversas iniciativas para atenuar el impacto social. Tal es el caso de entidades
como la Cámara Chilena de la Construcción, que promueve invertir recursos entre sus asociados para
dicho fin. Ejemplo de aquello es la suma de UF 39.000 para implementar programas de capacitación,
amparados en los beneficios tributarios, con el respaldo del Estado. A su vez, el Ministerio de Obras
Públicas y empresas concesionarias privadas se encuentran a finales del año 2009, a cargo de un
importante número de proyectos de construcción en etapas de ejecución y en proceso de estudio para
4
su realización en los próximos años. El objetivo de estas decisiones es impulsar las capacidades
productivas del país a nivel regional que tienen relación con proyectos de vialidad (pavimentación,
mejora y mantención de caminos), infraestructuras públicas (puentes carreteros, defensas fluviales),
ampliación y construcción de nuevos aeropuertos y obras portuarias, entre otros de similar envergadura
[1].
Figura 3: Tabla de empleo en la construcción entre los años 2008 y 2009
En definitiva, todas las iniciativas que contribuyan a mejorar la ocupación y productividad en esta área,
tendrán efectos significativos, dada la importancia del rubro en la economía nacional. Así también, todos
los análisis e investigaciones que se realicen en ella, no sólo traerán adelantos para la construcción
propiamente tal, sino que sus beneficios motivarán el perfeccionamiento de otros sectores productivos,
tales como la manufactura, minería, el comercio, la banca, en educación, salud, trabajos rurales, pesca,
entre otros.
1.2.2 Inspección Técnica de Obras
Uno de los sectores dentro de la construcción, donde se observan diversos tipos de roles y actividades
que realizan profesionales nómadas, es lo que se conoce en la actualidad como Supervisión e Inspección
Técnica de Obras (ITO). Entre sus agentes, es posible encontrar trabajadores pertenecientes a distintas
compañías, que necesitan intercambiar y sincronizar una gran cantidad de información.
La ITO se puede definir como un servicio especializado propio del proceso constructivo, que aparece
cuando un mandante (persona natural o jurídica que encarga un proyecto, aportando los recursos
financieros) necesita ser adecuadamente representado en obra, durante la etapa de ejecución de un
contrato de construcción. Lo anterior ocurre puesto que las empresas inmobiliarias, e inversionistas
tanto del sector privado como público, no siempre disponen de la capacidad técnica o de recursos como
para supervisar los proyectos que contratan [51].
En tal contexto, el rol fundamental de la ITO es fiscalizar que las obras se ejecuten según lo establecido
en los respectivos acuerdos y en sus antecedentes técnicos, tales como planos, especificaciones o
documentos complementarios. Además, debe velar que durante su desarrollo, exista una plena
observancia y conformidad en el cumplimiento de leyes, ordenanzas, reglamentos y normas que regulan
la construcción de las obras en nuestro medio (en la figura 4 se puede apreciar un ejemplo de esta
actividad).
5
Figura 4: Inspector técnico de obras y anotación de inspección
Para este cometido, los profesionales con responsabilidades de ITO, deben desempeñar, entre otras, las
siguientes funciones:
• Manejar las bases técnicas del contrato de construcción, vale decir planos y especificaciones
técnicas de arquitectura, cálculo y especialidades.
• Verificar en todo momento que lo ejecutado por el contratista esté de acuerdo al proyecto,
especificaciones y normativa vigente.
• Verificar que las obras se ejecuten según lo planificado y programado.
• Verificar que los recursos, utilizados por el contratista son los que el proyecto requiere:
materiales, equipos, maquinarias, trabajadores.
• Recibir las obras en los términos convenidos en el contrato de inspección.
• Verificar el término de las obras e informar al mandante de todo hecho relevante de tal suceso.
• Verificar la correcta dimensión y cubicación de los elementos proyectados.
• Informar al mandante de todas las situaciones que ameriten su intervención y que requieran su
decisión: incumplimiento de cláusulas del contrato, calidad de materiales o recursos utilizados en
la construcción, ejecución deficiente, mano de obra no calificada, capacidad de idoneidad de
proveedores y subcontratistas, etc.
En cuanto al proceso de negocio de la ITO y su ejecución tradicional, se pueden observar las siguientes
características:
• Los inspectores deben realizar constantemente observaciones en los avances de las obras en
construcción, mediante visitas presenciales, por lo que usualmente deben estar desplazándose
dentro de sitios que se encuentran en pleno proceso de edificación.
• Existen equipos de inspectores dispersos que trabajan en conjunto para supervisar uno o más
terrenos de construcción, asignando distintas áreas a distintos trabajadores.
6
• Los equipos de inspectores usualmente no pertenecen a la misma compañía que realiza el
trabajo de construcción, por lo que deben interactuar con personal de distintas empresas.
• Los registros de la supervisión, producto de las observaciones hechas en terreno, son escritos a
mano y usualmente almacenados de manera informal.
• Tanto los inspectores como los trabajadores encargados de la construcción, no poseen una
infraestructura de comunicación inalámbrica fija o cableada. Las interacciones y los envíos de
mensajes o avisos se realizan usualmente mediante equipos de radiocomunicación de corto
alcance.
• Los integrantes de los equipos de inspección deben intercambiar y sincronizar gran cantidad de
información, así como también deben compartir estos datos con proyectistas, mandantes y las
propias instalaciones centrales pertenecientes a su compañía.
1.3 Trabajo Colaborativo Móvil
El trabajo colaborativo soportado por computadora (CSCW: Computer Supported Collaborative Work),
ha sido definido como el estudio de los métodos usados por las personas para llevar a cabo tareas en
conjunto, usando la tecnología de pequeñas o grandes organizaciones. Sin embargo, nuevos
requerimientos son descubiertos a medida que la ciencia aplicada evoluciona: el incremento de las redes
inalámbricas y los dispositivos permiten que los usuarios pasen a ser puntos en movimiento [26]. A
continuación se presentan los trabajos relacionados en lo que respecta a soluciones en comunicación,
formas de interacción y software para este tipo de trabajo grupal.
1.3.1 Red Móvil Ad-Hoc
En situaciones donde se aplica tecnología móvil, es frecuente encontrar elementos de infraestructura fija
que dan soporte a las comunicaciones, tales como: antenas de telefonía celular, puntos de acceso a
internet Wi-Fi, puntos de acceso a recursos Bluetooth, repetidoras y amplificadoras de señal, entre otros.
Sin embargo, existen escenarios dentro de los cuales no se puede depender de este tipo de
instalaciones, en tanto los costos son muy altos, o porque los usuarios se encuentran en lugares alejados
o dentro de zonas sin señal que les impiden tener acceso a la red. También es posible que un servicio
colapse durante eventos de catástrofes o conectividad masiva. Como alternativa para solucionar las
dificultades señaladas, es posible conformar una red móvil ad-hoc (MANET: Mobile Ad-hoc Network),
aprovechando el alcance de señal de los dispositivos que la componen.
Una MANET es una malla autónoma de comunicación punto a punto, que está formada por distintos
tipos de dispositivos que se pueden trasladar (instalados en vehículos o naves, transportados por
personas). Estos aparatos están equipados con emisores y receptores de señal de red inalámbrica,
usualmente Wi-Fi o Bluetooth, para comunicarse entre ellos sin hacer uso de la infraestructura de una
red fija [13].
Esta red puede ser modelada como un grafo bidireccional G = (V, E), donde V es el conjunto de nodos
representados por los dispositivos móviles y donde E es el conjunto de arcos representados por el
alcance de comunicación que poseen los dispositivos [52]. La figura 5 muestra cómo un conjunto de
7
dispositivos y sus respectivos rangos de comunicación, se representan en el modelo previamente
mencionado.
Figura 5: Conjunto de dispositivos móviles representados según el modelo de una MANET
Para lograr una eficaz comunicación entre todos los dispositivos de la red, cada nodo debe encontrar
caminos adecuados dentro del grafo de la MANET, por donde transmitir mensajes a usuarios con los
cuales no posee una conexión directa. De esta forma, los dispositivos que se encuentran en el
intermedio deben retransmitir paquetes que no son necesariamente de su propio interés. Los protocolos
que estructuran estos tipos de redes deben considerar además, que la morfología del grafo es dinámica,
es decir que puede cambiar impredeciblemente en cualquier instante de tiempo. Esto se debe a la
movilidad de los usuarios que emplean los dispositivos, los espacios por donde éstos transitan, la
naturaleza de las señales inalámbricas, la variación de intensidad en el borde e interferencias con otras
ondas de radio (microondas, teléfonos, otros equipos o redes que utilicen la misma banda), entre otras
razones.
Distintos estudios muestran la utilidad de este tipo de redes en escenarios de trabajo colaborativo móvil:
asistencia en casos de catástrofes o emergencias ciudadanas, construcción de obras civiles [47],
aplicaciones industriales y comerciales que necesitan intercambio de datos móviles, aplicaciones
militares, búsqueda y rescate [13], entre otras.
1.3.2 Escenario de Interacción Multi-Síncrona
La naturaleza de los cortes de conexión a una red inalámbrica, en un escenario de comunicación móvil
punto a punto, puede ser tanto voluntaria como accidental. Si bien el usuario puede decidir separarse
para aislar su trabajo, también es posible que se produzca de manera inesperada al pasar por zonas de
sombra radial o al terminarse la capacidad de energía de los dispositivos. Lo anterior provoca cortes en
los enlaces que unen a los distintos puntos de la red. De dicho comportamiento se desprenden
diferentes formas posibles de interacción, dentro de un equipo de trabajadores dispersos [15]:
• Interacción síncrona, que se puede dar sólo en ambientes donde la calidad de conexión entre
todos los usuarios es de disposición óptima y constante.
• Interacción asíncrona, cuando el trabajo se realiza en tiempos diferentes, pero donde se
mantienen los resultados de las tareas en un módulo centralizado, que es visto por los usuarios
en cuanto se conectan a la red.
• Interacción multi-síncrona (figura 6), donde el trabajo está dividido según las fases de autonomía
en las que cada usuario realiza sus tareas. En base a esto es necesaria la puesta al día de todos
8
los miembros del equipo, para obtener la totalidad del trabajo. Es así como se lleva a cabo una
etapa en la que cada trabajador incorpora a su espacio los cambios de los demás y presenta sus
propias modificaciones y ajustes hacia la comunidad, al ocurrir un escenario de conexión
favorable.
Figura 6: Modelo de Interacción multi-síncrona
1.3.3 Espacio de Trabajo Compartido Móvil
Uno de los tipos de aplicaciones enfocadas a trabajos grupales multidisciplinarios, que hace uso del
concepto de MANET e Interacción multi-síncrona y que se encuentra actualmente en estudio, es el
espacio de trabajo compartido móvil (MSW: Mobile Shared Workspace) [57].
Se entiende por espacio de trabajo (workspace), a una zona virtual organizada, que contiene un conjunto
de herramientas y/o aplicaciones que facilitan a un usuario la realización de determinadas tareas,
relacionadas con un trabajo.
Por otra parte, el concepto compartido (shared), hace referencia a aquellos elementos que dan soporte a
la ejecución de labores colaborativas. Esto proporciona a los usuarios la posibilidad de interactuar y
tener percepción acerca de las actividades de los demás trabajadores, para comunicar e intercambiar
información relacionada con el objetivo general. Además divide el trabajo general en unidades que
pueden ser realizadas de forma autónoma y luego reintegradas y sincronizadas.
Finalmente, el término móvil (mobile), detalla que el sistema se ejecuta sobre algún tipo de dispositivo
portátil, que hace uso de especificaciones de comunicaciones inalámbricas, permitiendo a los usuarios
desplazarse por distintos lugares e interactuar.
Al formalizar entonces este concepto, un MSW es definido como un ambiente de trabajo colaborativo
interconectado, donde todos los participantes, que pueden estar tanto en distintos lugares como
acceder en distintos tiempos, desarrollan tareas e interactúan entre ellos como si estuvieran dentro del
mismo espacio. Este sistema permite además que trabajadores móviles se adapten a la aplicación
dependiendo del contexto en donde se encuentran [59].
Varios estudios muestran que este tipo de soluciones puede tener un gran impacto en diversos sectores,
aportando mayor asistencia a los trabajadores y mejorando los resultados en términos de calidad y
productividad [3]. Más aún, permite extender la noción de “acceso a la información” para incluir el cómo
se hace uso de ella y cuál es la forma apropiada de visualización [29].
Trabajo Autónomo
Trabajo de Sincronización
Trabajo Colaborativo
9
1.4 Impacto Tecnológico
La evolución de tecnología móvil y las nuevas formas de comunicación han facilitado el acceso a recursos
e información y han promovido además, vínculos de interacción con otras personas que pueden no estar
en los alrededores laborales o sociales usuales. Estas actividades generan nuevas posibilidades de
colaboración y cooperación en ambientes de trabajo [58].
Integrar los espacios tradicionales de responsabilidad con herramientas de información compartida
sincronizada, utilizando estos nuevos mecanismos, abre la posibilidad para diseñar y construir un sistema
de comunicación contextualizado, con un MSW. Sin embargo, estos avances tecnológicos dentro de
áreas como el servicio de ITO, suponen una transición de comunicación tradicional e informal hacia un
ambiente de colaboración mucho más rígido.
Durante la última década se ha presenciado un crecimiento sustancial en herramientas de mensajería
instantánea y comunicación vía texto. Dichas herramientas mejoran las capacidades de comunicación de
los trabajadores móviles, enriqueciéndola con información de presencia y disponibilidad de los usuarios
remotos. Así mismo, otros conjuntos de aplicaciones se han desarrollado para dar soporte a la
transmisión de datos.
Sin embargo, la mayoría de los sistemas existentes, usualmente carecen de real utilidad, al momento de
proveer acceso a los clientes móviles hacia recursos y herramientas que pueden ser relevantes, al no
tener en cuenta un adecuado contexto de colaboración [19]. Un MSW logra resolver tal dificultad,
tomando en cuenta los requerimientos funcionales de los trabajadores móviles, dentro del contexto
específico de colaboración.
En el marco de esta investigación, el éxito del cambio tecnológico radica en emigrar desde un ambiente
de trabajo tradicional, que utiliza los procesos acostumbrados de la ITO, hacia uno de mayor formalidad,
utilizando tecnología móvil y comunicación digital. Por este motivo, es que se precisa cubrir necesidades
sociales fundamentales: inserción de dispositivos móviles adecuados, mecanismo de control adaptable al
ambiente laboral habitual de los inspectores, diseño e implementación de una interfaz que facilite la
transición tecnológica, entre otras. La suma de estos conceptos, transformará el proceso de inspección
hacia un nuevo ambiente de comunicación y tecnología de la información.
1.5 Problema a Resolver
En un proyecto de construcción interviene una gran variedad de personal y especialidades, muchas veces
subcontratados, es decir, que dependen de distintas compañías ajenas a la empresa principal. Estas
personas deben realizar sus actividades en forma paralela, circulando por las instalaciones y faenas en
equipos dispersos.
En la actualidad, los profesionales de la ITO utilizan planos impresos y libros donde se registran
observaciones y anotaciones en terreno. En algunos casos, disponen de medios auxiliares tales como
radios o teléfonos celulares, con una precaria infraestructura de comunicación.
Además, dado que se necesita intercambiar y sincronizar la información que se genera, a fin de lograr
coordinación y entrega de reportes al mandante y a su propia empresa, es que deben llevar a cabo
reuniones presenciales con el resto de los involucrados en el proyecto. Estas interacciones permiten
compartir datos, avances, notificaciones de problemas, consultas técnicas, entre otras.
10
El actual escenario, en el que se realiza este servicio, tiende a crear problemas cuando los proyectos son
de gran tamaño o son motivo de cambios y modificaciones durante el proceso de construcción. Dichas
dificultades poseen su base en las condiciones bajo las cuales se realiza el intercambio y almacenamiento
de los datos, en la validez de la información y en la mayoría de los casos, al tratar de unir distintas piezas
aportadas por distintos trabajadores. Este hecho en particular produce desfases, atrasos y mermas en la
fiscalización, dando origen a una peligrosa descoordinación general, tanto en el manejo de la
información como en la lentitud de la trasmisión de informes y en la recepción de las respuestas. Ello da
origen a cobros adicionales, aumento de plazos y cambios en la secuencia productiva, de nulo provecho
para las partes que intervienen en los proyectos.
La experiencia cotidiana ratifica que tanto la mayoría de los errores detectados en las construcciones,
como los daños que se producen en edificios, por lo general obedecen a una mala, escasa, deficiente o
nula inspección técnica. En tanto, en las obras civiles, los daños derivados por sismos, desbordes o
crecidas de ríos, refuerza la percepción acerca de la necesidad de que la ITO intervenga de manera
adecuada en todas las etapas del proceso.
La inspección adopta una actitud preventiva que permite anticipar errores y conflictos. Sin embargo, el
proceso de fiscalización en los sectores de construcción, se debe realizar de manera sistemática,
ordenada y con transparencia y limpieza de la información. Cabe destacar, que las fallas, deficiencias o
defectos en una edificación deben poder ser además priorizados, coordinados y administrados
correctamente. Se debe dar mayor importancia a los problemas que puedan originar peligro en la vida
de las personas, en la estabilidad de las estructuras o que puedan significar aumento de costos o plazos.
1.6 Hipótesis
La presente investigación abordará el análisis de los beneficios y posibilidades que pueden ofrecer las
aplicaciones del tipo MSW en los trabajos colaborativos existentes en la ITO. En consecuencia, la
hipótesis fundamental recae en que la incorporación de metodologías y herramientas de tecnología
móvil mediante aplicaciones MSW, contribuirán a mejorar la eficiencia y productividad de las empresas y
trabajadores que prestan este tipo de servicios, en proyectos de construcción en general.
Además, la abstracción de aplicaciones MSW obtenida del análisis, uso, y experiencia de este concepto
en otros escenarios, permitirá obtener un patrón de diseño que se pueda instanciar al proceso particular
de ITO. Esta estructura será la base para construir el esquema principal y reusar conocimiento ya
aplicado.
Finalmente, la adaptación y creación de un nuevo protocolo para la formación automática de redes
MANET, que enfrente el problema de movilidad de los trabajadores en terreno y que ofrezca además
servicios de colaboración y trabajo de bajo acoplamiento, aumentará las posibilidades de interacción
entre los inspectores, para que puedan realizar tareas de manera multi-síncrona, coordinar su trabajo, y
visualizar elementos de percepción acerca de las labores que realizan sus compañeros de grupo.
1.7 Objetivos de la Tesis
Los objetivos centrales de este trabajo de tesis son: apoyar las actividades ejecutadas por inspectores de
obras, dar soporte a las tareas colaborativas que desempeñan los equipos de inspección y facilitar la
11
comunicación y la coordinación de la información. A su vez, los objetivos específicos para lograr resolver
el problema planteado son los siguientes:
• Determinar una forma de trabajo colaborativo para los diversos actores involucrados en el
proceso.
• Aplicar una herramienta de trabajo en terreno, que permita realizar anotaciones sobre planos
digitales usando tecnología móvil y que se adecue al ambiente propio de una faena de
construcción.
• Proveer mecanismos de comunicación y coordinación apropiados para llevar a cabo el proceso
de colaboración entre usuarios móviles, incrementando las posibilidades de interacción y
sincronización entre los trabajadores.
• Proveer mecanismos de percepción del trabajo grupal.
• Medir los resultados obtenidos.
Adicionalmente, y a partir de los procedimientos planteados para solucionar los distintos problemas de
colaboración, de la evidencia empírica y de los adelantos tecnológicos en el proceso de inspección, se
tiene como objetivo, encapsular y abstraer los resultados obtenidos, para que sean de utilidad en otros
ámbitos similares. Esto, con el fin de que diseñadores, arquitectos y/o desarrolladores de sistemas
colaborativos móviles, puedan generar nuevas instancias, tomando como herramienta, una respuesta a
un patrón generalizado del problema.
1.8 Resumen de la Solución Propuesta
Este trabajo de tesis ofrece un instrumento de información y colaboración, que permite disminuir en
gran manera los problemas y dificultades que generan las actuales prácticas laborales de la ITO, y que
llevan a situaciones de desaciertos en los resultados de obras de construcción civil.
Esta herramienta tecnológica, basada en investigación y desarrollo de un MSW, permite mejorar la
forma de llevar a cabo el proceso de la ITO, logrando que la información generada por los inspectores
pueda ser ingresada, almacenada y gestionada de una manera limpia y eficaz. Además, establece
procedimientos apropiados con los cuales llevar a cabo la supervisión en terreno, creando instancias de
trabajo grupal colaborativo entre quienes participan en el proceso, consiguiendo maximizar y satisfacer
las oportunidades de comunicación e interacción social.
Los objetivos específicos se alcanzan de la siguiente manera:
• Se estudia, modela y optimiza el proceso de ITO haciendo uso de un MSW. Además, se genera un
recurso abstracto de diseño para el trabajo colaborativo móvil, que permite instanciar un
esquema específico para el trabajo grupal de inspección de obras.
• Se implementa y adapta al contexto una herramienta tecnológica, que provee las
funcionalidades necesarias para realizar tareas de inspección y almacenamiento de información
de manera digital.
12
• Se diseña una arquitectura de MANET y se implementa una interfaz de programación para
aplicaciones (API: Application Programming Interface), que permite establecer comunicación
entre dispositivos móviles diversos y programar sub-protocolos de coordinación.
• Se unen las distintas piezas para construir un MSW, diseñando e implementando interfaces y
funcionalidades de mensajería, percepción de presencia y localización del grupo de trabajo,
entre otras.
• Finalmente, se realizan pruebas de comunicación y uso del MSW en terreno para determinar las
ventajas comparativas.
La materialización de estos conceptos e ideas, permite intensificar la convicción de los resultados
obtenidos del proceso de supervisión de obras. Procura además, que las construcciones se adecuen a las
condiciones contractuales, a las especificaciones técnicas y que además cumplan rigurosamente con las
normas de edificación.
Finalmente, los diversos esquemas y subestructuras de colaboración permiten reutilizar los resultados y
ampliar el campo de investigación a diversos escenarios, tales como: asistencia médica en hospitales,
trabajo de coordinación de bomberos en asistencias a desastres, equipos de búsqueda y rescate,
sistemas de comunicación por voz sin uso de infraestructura, piezas de software para desarrollo de
aplicaciones colaborativas (groupware), entre otros.
1.9 Trabajos Relacionados
A continuación se describen trabajos que tienen relación con los temas abordados en esta investigación.
1.9.1 Sistemas de Trabajo Colaborativo Móvil
Existe un gran número de soluciones colaborativas que han sido propuestas para el trabajo móvil en
actividades específicas, tales como: soporte al intercambio de información geológica [2], coordinación y
sincronización de trabajos científicos [26], edición colaborativa de documentos compartidos [42], gestión
de información distribuida en hospitales [45] y soporte para reuniones presenciales mediante
dispositivos portátiles [68], entre otros. Sin embargo estas propuestas se han mostrado útiles sólo
dentro del contexto para el cual fueron diseñadas y no constituyen una herramienta de trabajo general
que pueda ser totalmente reutilizable. Además, estas alternativas no son aplicables en el marco de esta
investigación, pues no son capaces de enfrentar el problema de colaboración en MANET, ni el trabajo de
bajo acoplamiento [47].
Por otra parte, existen distintas iniciativas de interés en el área de software que otorgan conectividad
entre capas de aplicaciones (middleware) y que proponen funciones reutilizables para dar soporte a la
colaboración en redes punto a punto. LaCOLLA [41] e iClouds [31] son dos ejemplos de ellas. Aunque
estas herramientas tienen capacidad para soportar interacciones entre usuarios e intercambio de
archivos en redes móviles, no proveen sustento para el intercambio de objetos de negocio,
sincronización de archivos o trabajo autónomo sin conectividad a un servidor central.
Existen también, estructuras de software para construcción de aplicaciones (frameworks) que proveen
funcionalidades específicas para dar soporte a la colaboración, tales como YCab [7] y JXTA [40]. En ellos,
cada dispositivo y componente de software es un punto que puede colaborar fácilmente con otros.
13
Aunque estos frameworks han mostrado ser útiles para dar vida a la colaboración en redes punto a
punto, requieren infraestructuras cableadas o redes inalámbricas fijas. Por lo tanto no suelen funcionar
adecuadamente en ambientes MANET.
Finalmente, existen propuestas para compartir información en redes punto a punto [30], y que
consideran el uso de dispositivos móviles en redes MANET [48]. Típicos ejemplos son sistemas
distribuidos que derivan de LINDA [24], tales como: FT-LINDA, JINI, PLinda, T-spaces, Lime, JavaSpaces y
GRACE. Aunque estas implementaciones trabajan directamente en el tipo de redes que requiere un
MSW, hacen uso de piezas centralizadas que proveen un puente entre las distintas componentes del
sistema distribuido.
En resumen, no existen herramientas concretas para ser usadas específicamente en los contextos
planteados, ni en el escenario de ITO, y los actuales frameworks son limitados al momento de dar
soporte a la colaboración móvil y al trabajo autónomo de los usuarios.
1.9.2 Sistemas de Redes Móviles Ad-Hoc
Variados estudios e iniciativas han publicado y continúan actualmente realizando mejoras y nuevos
trabajos de investigación, respecto a especificaciones de protocolos que puedan construir y mejorar las
capacidades de una MANET, tales como OLRS [12], DYMO [14], DSR [39], BATMAN [46] y AODV [53],
entre otros. Sin embargo, la complejidad de estos escenarios y la necesidad de enfrentar requerimientos
de muy bajo nivel, hacen que sean difíciles de implementar. Más aún, la complejidad aumenta al
considerar heterogeneidad en los tipos de dispositivos móviles y distintos sistemas operativos.
Otros trabajos se han enfocado en terminología estándar, definiciones de problemas y soluciones para
topologías de red relacionadas con MANET. Algunos de estos estudios tienen relación con configuración
de direcciones de red [4], diseño y evaluación de protocolos para enfrentar problemas de performance
[13], efectos de la pérdida de conexiones TCP debido a los aspectos de movilidad [33], redundancia y
colisión de paquetes de multidifusión [49] y técnicas de construcción de redes de alto nivel [66], entre
otros. Sin embargo la mayoría de ellos son soluciones específicas para ciertos tipos de protocolos y no
pueden ser utilizados directamente.
Usualmente los protocolos creados para encontrar vías de comunicación dentro de redes de tipo
MANET, han sido divididos en dos grandes familias: proactivos y reactivos. Los protocolos proactivos
implementan y mantienen tablas de direcciones, que son usadas para determinar el mejor camino por el
cual se puede entregar un mensaje. Por otra parte, los protocolos reactivos no preestablecen un camino,
sino que es determinado dinámicamente (en cada salto) mientras los mensajes viajan hacia su destino.
Independientemente del tipo de protocolo, cada solución aborda el problema de la entrega de mensajes
de unidifusión (un solo destino) y multidifusión (muchos destinos).
Dos de los trabajos más sobresalientes en el ámbito unidifusión son DYMO [14] y OLSR [12]. En el
aspecto de entrega multidifusión, algunos de los proyectos más conocidos son: ALMA [23] y PAST-DM
[27]. ALMA crea un árbol de enlaces lógicos entre miembros de un grupo y reconfigura su estructura
ante movilidad o congestión de tráfico. PAST-DM implementa una malla virtual, la que es mantenida
dinámicamente mediante el intercambio de paquetes de datos, que contienen el estado de los enlaces
entre dispositivos.
14
La mayoría de estos protocolos, no se enfocan en dar soporte a sistemas de trabajo colaborativo, sino
que establecen funcionalidades de transporte de datos de bajo nivel. Por dicho motivo, sus
procedimientos no administran usuarios, sino que sólo direcciones de red, así como tampoco proveen
información relevante para implementar mecanismos de percepción acerca de los demás participantes.
1.10 Trabajos Previos
A continuación se describen trabajos que han sido previamente publicados y que han aportado al
desarrollo de la presente investigación.
1.10.1 Administrador de Anotaciones sobre Planos Digitales
Gabriel Bravo, muestra en su trabajo de tesis titulado “Desarrollo de un Workspace Colaborativo Móvil
para Apoyar a los Inspectores de Obra en Escenarios de Construcción”, cómo el uso de una aplicación
móvil de apoyo a las actividades de inspección de obras, permite reducir los tiempos asociados a la
actividad, sin degradar la calidad del producto final [5].
Para ello, se hace uso de un MSW prototipo, con el objetivo de apoyar el trabajo de los inspectores en
terreno, permitiendo estudiar el comportamiento humano, cuando las personas deben utilizar este tipo
de soluciones tecnológicas. La aplicación permite al inspector visualizar los diversos planos asociados a
una obra, en la que se encuentre desempeñando sus funciones. Esto otorga la posibilidad de ingresar
anotaciones y/o comentarios usando la escritura digital.
1.10.2 Sincronizador de Archivos XML distribuidos
Cristhian Moya describe en su trabajo de título “Módulo para la Sincronización Automática de
Documentos XML”, una estrategia para sincronizar información que se encuentre distribuida, entre
usuarios que realizan modificaciones de manera autónoma [44].
Para compartir información entre distintos dispositivos móviles, se utiliza representación de datos en
archivos de tipo Extensible Markup Language (XML). XML es un lenguaje basado en etiquetas, propuesto
como un estándar para el intercambio de información entre diferentes plataformas. Se puede usar en
bases de datos, editores de texto y hojas de cálculo entre varios otros tipos de representación. Además,
tiene un papel muy importante en la actualidad, ya que permite compatibilidad entre distintos sistemas,
de manera segura, confiable y fácil.
Sin embargo, los documentos XML resultantes de una sincronización, pueden llevar a diferencias y/o
ambigüedades. La estrategia sugerida, permite hacer uso de automatización en dichas decisiones, al
momento de sincronizar dos o más archivos. Esta decisión se basa en datos inherentes al sistema de
trabajo colaborativo, tales como roles de usuarios, tiempos de modificación, entre otros.
15
Capítulo II: La ITO Como Trabajo Colaborativo Móvil
El objetivo principal de un sistema de groupware es asistir a grupos de personas, para que ellas puedan
comunicarse, colaborar y coordinar sus actividades. Más aún, su definición se basa en dar soporte a
trabajadores que desean conseguir un objetivo común, mediante el acceso a un ambiente computacional
compartido [19]. No obstante, el gran reto que se debe abordar para que estas aplicaciones sean
exitosas, se cimenta en tener en cuenta un adecuado contexto de trabajo, mediante tres variables
principales: ambiente, participantes y actividades [59].
2.1 Estudio en Terreno
Para contraponer el impacto tecnológico de un MSW, se ha realizado un estudio en terreno del escenario
de la ITO. Esto, con el fin de establecer cuál es el proceso que se lleva a cabo, el ambiente en donde se
desarrolla y la identificación de los distintos participantes, roles y actividades asociadas. El estudio se ha
efectuado en la Zona Franca de Iquique (Zofri), dentro del proyecto denominado “Edificio de
Estacionamientos Zofri S.A.”, que se levanta en la Región de Tarapacá, Chile, con una inversión de 5 mil
millones de pesos. Entre sus propósitos destacan la construcción de una obra de hormigón armado, en
cuatro niveles, que contempla la edificación de estacionamientos para más de 600 vehículos, locales
comerciales, tiendas de gran formato y obras exteriores (figura 7) [63].
Figura 7: Proyecto Edificio de Estacionamientos Zofri S.A.
La investigación contó igualmente, con la colaboración del profesional a cargo de la inspección técnica
del proyecto, el constructor civil Luis Ricardo Peña, académico universitario y Secretario Técnico del
Comité de ITO en la Cámara Chilena de la Construcción. Como resultado, se ha logrado identificar cuáles
son los participantes principales del proceso de ITO, y establecer la importancia y las actividades que son
llevadas a cabo por cada uno de ellos.
2.1.1 Ambiente
La construcción presenta ciertas características, que se deben tener en cuenta, para comprender el
ambiente en el que se lleva a cabo, e identificar las capacidades de quienes intervienen en ella.
16
Usualmente, las obras comprenden una importante cantidad de trabajos a la intemperie, con todas las
dificultades que ello implica. Al mismo tiempo, algunos pasos y decisiones presentan un marcado
carácter de improvisación y prácticas que requieren altas normas de seguridad. Por otra parte, es posible
observar trabajadores y obreros con escasa calificación, y procedimientos que no siempre utilizan una
tecnología adecuada, lo que atenta contra la eficiencia y productividad del sector. Sin embargo, variados
esfuerzos, permiten mejorar los estándares de trabajo, tales como: capacitación permanente de
profesionales, técnicos y trabajadores, adecuado proceso de certificación de sus competencias,
incorporación de métodos constructivos modulares, uso de elementos prefabricados y sistemas
tecnificados, entre otros.
2.1.2 Participantes
La figura 8 muestra a los principales participantes del proceso de inspección y sus interrelaciones.
Figura 8: Relación entre participantes de la ITO y agentes externos
En términos generales, un proceso de construcción consta de tres macro participantes: Mandante,
Empresa Constructora y Empresa ITO. El Mandante es quién desea materializar un plan de construcción,
contratando a una Empresa Constructora que le ejecuta las obras, y a una Empresa ITO que le verifica
que la Empresa Constructora lleve a cabo el proyecto de la manera en que fue acordada.
En el proceso particular de la ITO, es posible encontrar distintos cargos o roles que deben ser
adjudicados a diferentes trabajadores, entre ellos, los más relevantes son: Supervisor, Inspector Jefe e
Inspector Terreno. Cada uno posee especiales atribuciones y responsabilidades, siendo el trabajo
general, la suma y conjunto de las tareas efectuadas colaborativamente por cada uno de ellos. Además,
17
existen relaciones e interacciones con agentes externos a la inspección propiamente tal, como los
Proyectistas del Mandante (arquitectos, calculistas, especialidades) y el Director de Obra de la Empresa
Constructora.
2.1.3 Actividades
A continuación se describen las actividades realizadas por cada uno de los participantes de la ITO y los
agentes externos.
2.1.3.1 Supervisor
El Supervisor es un inspector que tiene a cargo distintos sitios de construcción. Cada faena pertenece
usualmente, a diferentes Mandantes, así como también a distintas Empresas Constructoras que llevan a
cabo cada proyecto. Para cumplir su cometido, el Supervisor debe efectuar visitas periódicas a los sitios,
coordinando reuniones y tomando decisiones en conjunto con los demás profesionales. Las tareas que
debe realizar son, entre otras:
• Supervisar en terreno el desempeño de los Inspectores Jefes residentes.
• Colaborar con los profesionales de terreno en materias relacionadas con la gestión de la ITO.
• Llevar el control global de los aspectos más relevantes, informando al Mandante sobre cualquier
desviación que se produzca en alguno de ellos: plazo, programación y calidad.
• Coordinar las reuniones de trabajo internas, en la que deben participar todos los profesionales
de terreno.
• Participar en las reuniones de obra.
2.1.3.2 Inspector Jefe
El Inspector Jefe es un profesional que se encuentra a cargo de un sitio de construcción. Dentro de la
faena, debe realizar las actividades propias de inspección, junto a un equipo de Inspectores Terreno.
Algunas de las tareas que debe realizar son:
• Permanecer en obra realizando labores de inspección en todos los aspectos técnicos y
administrativos de la ITO, coordinando a un grupo de Inspectores Terreno.
• Verificar que la Empresa Constructora esté cumpliendo rigurosamente con las condiciones y
obligaciones contenidas en los planos, especificaciones técnicas de arquitectura y especialidades,
normas, entre otros.
• Coordinar con el Director de Obra la programación semanal o quincenal del avance.
• Mantener informado, al Supervisor sobre el desarrollo de la obra y sus aspectos más relevantes.
• Recibir, revisar, aprobar o rechazar los trabajos terminados.
• Supervisar la labor de coordinación y concordancia del diseño de las distintas especialidades
(arquitectura, cálculo, instalaciones sanitarias y gas, instalaciones eléctricas y corrientes débiles,
seguridad, calefacción, climatización y extracción de aire, mecánica de suelos, entre varias otras)
que realice el Proyectista.
18
• Coordinar las reuniones de obra, tanto ordinarias como extraordinarias.
2.1.3.3 Inspector Terreno
El Inspector Terreno es un ayudante que colabora en el desempeño de las labores de un Inspector Jefe, a
medida que se le encomiende. Para ello, debe realizar entre otras, las siguientes tareas:
• Participar en la inspección técnica y administrativa, controlando los avances físicos de obra.
• Participar en la revisión del programa de avance semanal, comparando con carta Gantt general
de la obra.
• Verificar el correcto cumplimiento de la Empresa Constructora, respecto del contrato de
construcción, especificaciones técnicas de arquitectura y especialidades, normas,
procedimientos constructivos, buenas prácticas en la construcción, entre otros.
• Controlar la calidad e idoneidad de los recursos presentes en obra, de modo de asegurarse que
éstos estén de acuerdo a las necesidades de la obra y del respectivo programa de avance.
• Efectuar procedimientos de coordinación con los involucrados.
• Colaborar en la coordinación y concordancia del diseño, de las distintas especialidades.
• Colaborar en la preparación de los informes mensuales y finales.
2.1.3.4 Proyectista
Los Proyectistas son profesionales que reciben encargo de parte de un Mandante para diseñar y
especificar la mejor solución posible a sus requerimientos de planta física. Esto se debe efectuar en
estricto rigor a las normativas vigentes y técnicas en áreas como la arquitectura, calculo estructural,
energía, climas artificiales, seguridad, sanitarias, control centralizado, entre otras. Una vez iniciada las
obras de construcción, se suelen presentar dudas en terreno, por defectos u omisiones del proyecto en
los planos y condiciones de contrato. En dichos casos, el Inspector Jefe debe evaluar los problemas
mediante consultas y reuniones con los Proyectistas para establecer una respuesta adecuada y oportuna,
de manera de evitar atrasos y sobrecostos.
2.1.3.5 Director de Obra
El Director de Obra es un profesional asignado por la Empresa Constructora para dirigir y administrar los
recursos financieros, técnicos y humanos que le son dispuestos para materializar el proyecto, dentro de
los mejores términos de plazos, costos y calidad. El Inspector Jefe debe realizar reuniones periódicas con
el Director de Obra, para resolver los conflictos o contingencias encontradas durante el proceso de
inspección, que se generan por una deficiente o errónea ejecución del proyecto. De esta manera, se
deben llegar a acuerdos para reasignar los recursos administrados, junto a cambios en los plazos y
estados de avances.
2.2 Esquema de Colaboración
Desde el punto de vista del proceso de colaboración móvil, es posible caracterizar las interacciones entre
los participantes usando el lenguaje Mobile Collaboration Modeling (MCM) [32]. Este lenguaje gráfico
19
permite entender el escenario de colaboración y determinar los requerimientos de software y usuario,
para que una aplicación pueda otorgar un adecuado soporte de trabajo.
En este tipo de actividades, donde los participantes se deben desplazar por distintos recintos e
instalaciones, corresponde modelar el contexto en términos de tiempo (simultaneidad del trabajo) y
conectividad (alcance entre trabajadores). Dichas variables son fundamentales a la hora de efectuar
tareas de comunicación y/o coordinación.
Se define que dos usuarios “se alcanzan” si son capaces de intercambiar información de alguna manera
preestablecida, aunque ésta sea no presencial. Por otra parte, dos usuarios “son simultáneos” si pueden
trabajar síncronamente. De allí se desprende una clasificación de posibles modalidades de trabajo, entre
usuarios móviles, basada en las dimensiones de simultaneidad y alcance. El lenguaje MCM utiliza esta
clasificación, para establecer los posibles escenarios de labor entre los participantes de un proceso
colaborativo. La figura 9 muestra las cuatro representaciones de las posibles modalidades, que pueden
ser: (a) simultánea con alcance, (b) simultánea sin alcance, (c) no simultánea con alcance, y (d) no
simultánea sin alcance.
Figura 9: Posibles representaciones de trabajo en el lenguaje MCM
La figura 10 muestra el diagrama construido para la ITO. En él se modelan los posibles escenarios de
trabajo entre los participantes y los agentes externos de relevancia en el proceso. Las actividades
realizadas bajo cada modalidad se detallan a continuación.
Figura 10: Diagrama de colaboración de la ITO
20
2.2.1 Interacción entre Supervisor e Inspector Jefe
Las actividades realizadas entre Supervisor e Inspector Jefe son:
• Simultanea con alcance: envío y/o recepción de informes de inspección, coordinación general y
de reuniones, reuniones de obra.
• Simultanea sin alcance: gestión de inspección, control global de plazos y calidad.
2.2.2 Interacción entre Inspector Jefe e Inspectores Terreno
Las actividades realizadas entre Inspector Jefe e Inspectores Terreno son:
• Simultanea con alcance: inspección técnica de obra, sincronización de inspección, coordinación
de grupo de inspección, recepción de trabajos terminados, coordinación de reuniones, reuniones
de obra, revisión de programa de avance semanal.
• Simultanea sin alcance: inspección técnica de obra, recepción de trabajos terminados,
preparación de informes de inspección.
• No simultánea sin alcance: inspección técnica de obra, recepción de trabajos terminados,
preparación de informes de inspección.
2.2.3 Interacción entre Inspector Jefe y Proyectista
Las actividades realizadas entre Inspector Jefe y Proyectista son:
• Simultanea con alcance: coordinación de diseño de distintas especialidades, coordinación de
reuniones, reuniones de obra, resolución de consultas.
• Simultanea sin alcance: resolución de consultas.
2.2.4 Interacción entre Inspector Jefe y Director de Obra
Las actividades realizadas entre Inspector Jefe y Director de Obra son:
• Simultanea con alcance: coordinación de programación semanal de obra, coordinación de
reuniones, reuniones de obra, resolución de consultas.
• Simultanea sin alcance: resolución de consultas.
21
Capítulo III: Macro Estructura del Diseño
Un proceso de diseño en general, es una actividad socio-tecnológica compleja y costosa, pero necesaria
para desarrollar cualquier tipo de sistema computacional o mecánico [17]. La reutilización de
conocimientos de diseño, es identificada como un vehículo para reducir costos, esfuerzos y dificultades,
en la creación de nuevas ideas. Una metodología de reúso conocida, es la utilización de patrones, pues
capturan la esencia abstracta de un problema, permitiendo que nuevas soluciones sean creadas en base
a diseños ya experimentados [6]. Este proceso se realiza examinando tres factores principales: el
contexto, el problema a resolver y la solución de diseño propuesta.
3.1 Diseño de MSW en Escenarios Similares
La definición de diseños reusables representa un reto en escenarios de nuevas aplicaciones, en especial
en el campo de sistemas de trabajo colaborativo móvil, pues el conocimiento para este tipo de dominio
está siendo recientemente fundado. Más aún, su diseño ha sido difícil de concebir, por los poco claros
requerimientos que se deben satisfacer y la baja experiencia de los usuarios. La mayoría de los sistemas
relacionados a este tipo de soluciones, dan cuenta de implementación y uso de sistemas colaborativos
móviles en variados escenarios, pero desafortunadamente, no describen las estrategias esquemáticas
bases, para ser reusadas en éste u otros futuros trabajos.
Con el objetivo de construir una estructura que pueda ser reutilizada y particularmente instanciada en el
servicio de ITO, se han analizado las características comunes que tienen distintos MSW previamente
desarrollados, en busca de un contexto, un problema y una solución. Para ello, se han seleccionado dos
escenarios específicos: cuidados médicos en hospitales [20, 60] y emergencias urbanas de rutina [43].
3.1.1 Cuidados Médicos en Hospitales
Los servicios de cuidado médico, particularmente aquellos que se proveen en los hospitales, dependen
de la colaboración de distintos trabajadores móviles: médicos residentes, terapeutas, enfermeras, entre
otros. Usualmente, ellos deben llevar a cabo registros y sondeos periódicos en los pacientes internados
en el hospital, con el propósito de monitorear su estado de salud. Cuando una ronda de observación ha
concluido, el personal médico debe reportar la información recopilada, a los médicos jefes que se
encuentran de turno y a los servicios informáticos centrales del hospital. Dicha información es usada
posteriormente para evaluar la condición particular de cada paciente y también para estimar la situación
global de la institución.
En algunos casos, un trabajador móvil que se encuentra realizando una ronda, consigue detectar un
problema de relevancia en un paciente. Este tipo de eventos puede generar una serie de acciones, tales
como: localizar al médico a cargo, obtener la ficha clínica con información relevante, coordinar una
reunión con especialistas para analizar el caso, obtener implementos, medicamentos, u otras.
De acuerdo a un estudio realizado en un hospital público, se puede establecer que el personal médico
usa el 53% de su tiempo, fuera de la localidad o sala base. Mientras esto ocurre, otros trabajadores
necesitan frecuentemente localizarlos y contactarlos para solicitarles información (análisis de resultados
de exámenes), o para discutir problemas relacionados con la evaluación de un paciente. En casos de
22
emergencias es importante además, advertir a personal adicional, con el objetivo de proveer una
respuesta inmediata acorde con la situación. Estas notificaciones deben ser entregadas de manera
rápida y efectiva, en tanto la vida de un paciente puede depender de ello.
Un MSW desarrollado para computadoras de bolsillo (PDA: Personal Digital Assistance) es usado por
médicos, terapeutas y enfermeras (figura 11) para examinar y actualizar la ficha clínica de los pacientes,
compartir información relevante, generar alarmas de emergencia, enviar mensajes y encontrar
información de localización de personal.
Figura 11: MSW para cuidados médicos en hospitales
3.1.1.1 Contexto
El trabajo realizado por los profesionales a cargo del cuidado médico en hospitales conserva las
siguientes características:
• Involucra personal distribuido en el hospital, que en conjunto, diagnostican y recolectan
información relevante para el cuidado de los pacientes.
• Los trabajadores necesitan conocer la posición y las actividades que realizan sus colegas para
realizar labores colaborativas.
• El personal no siempre dispone de una infraestructura de comunicación adecuada.
• Los profesionales necesitan compartir información con otros trabajadores, administradores del
hospital y centros de información hospitalaria.
• Existen momentos ocasionales de actividades críticas en términos de tiempo (durante
emergencias o intervenciones quirúrgicas).
3.1.1.2 Problema
Los pacientes se encuentran usualmente distribuidos en diferentes áreas (habitaciones, pisos y edificios),
por lo que existe un amplio espacio en donde puede estar situado el personal. Además, no existe un
tiempo coordinado para tal colaboración, sino que se debe ejecutar en función de la demanda.
3.1.1.3 Solución
Un MSW asiste al personal médico que circula en las diferentes localidades del hospital. Los principales
requerimientos de esta aplicación son:
23
• Autonomía de datos y servicios: no es posible asumir acceso a la información del sistema central
del hospital o a las redes inalámbricas durante los tiempos de actividades críticas. Por lo tanto, el
MSW debe ser lo más autónomo posible en términos de datos y servicios.
• Comunicación ad-hoc: el MSW requiere un servicio de comunicación que no necesariamente
haga uso de una infraestructura, pues no es posible depender de ella en todo tiempo y lugar.
Esto logra incrementar las posibilidades de localización e interacción entre los trabajadores.
• Percepción de la posición y disposición del personal: estos son dos de los servicios más
frecuentemente usados, especialmente durante las emergencias, para que los trabajadores
médicos puedan contactar a sus colegas.
• Mensajería: este servicio básico es requerido para comunicar y coordinar a los trabajadores
móviles, activar alarmas de emergencias y dar soporte al intercambio de información.
• Información compartida: esta funcionalidad simplifica el proceso necesario para compartir
documentos, tales como fichas clínicas o imágenes de laboratorio, y reportar resultados de las
auscultaciones que realizan las enfermeras en los pacientes. Dependiendo del tipo de datos
asociado (texto, imágenes, archivos estructurados) existen mecanismos apropiados para
transferir y/o sincronizar la información.
3.1.2 Emergencias Urbanas de Rutina
Habitualmente, un grupo de bomberos es quién debe liderar una respuesta a emergencias ciudadanas
de rutina, tales como incendios, accidentes automovilísticos, fugas de combustibles, colapsos
estructurales, derrames de agua o productos químicos, entre otros. El tiempo requerido para tomar
control de una emergencia tiene una consecuencia directa en las lesiones que se pueden producir en las
personas, o en los daños que se pueden causar sobre las construcciones.
Al recibir una solicitud de asistencia, un centro de emergencias despacha dos o más carros de bomberos,
que pueden ser de distintas compañías, hacia el sitio de la emergencia. Además, en medida de lo
necesario, convoca a instituciones adicionales tales como personal médico o policial, para mayor
cobertura.
Una vez que bomberos concurre al sitio de la emergencia, se activa un proceso de respuesta, el cual
requiere coordinar las actividades primarias necesarias para tomar control del evento, teniendo como
encargado a un comandante de incidente. Esta persona usualmente debe tomar decisiones generales,
mientras que decisiones particulares son tomadas en paralelo por otros bomberos, que deben enfrentar
situaciones críticas en términos de tiempo: ubicar los carros bomba, encontrar redes de agua de los
edificios, determinar el mejor camino para rescatar a una víctima, entre otras.
Tomar decisiones efectivas a tiempo requiere acceso en demanda a información clave y, algunas veces,
validación de dicha información con compañeros de trabajo. Las decisiones que puedan afectar a otros
equipos de bomberos deben ser oportunamente avisadas. Así, la generación de alarmas y mensajes es
también un importante servicio que debe estar disponible cuando se está atendiendo una emergencia.
Un MSW ha sido propuesto para ser usado en dispositivos PDA o teléfonos móviles inteligentes
(Smartphones), como complemento a los protocolos y sistemas de radio usados por bomberos. Este
espacio de trabajo es usado por quienes deben tomar decisiones (figura 12), permitiéndoles consultar
24
datos relevantes al centro de comando u otros trabajadores que también toman decisiones, tales como:
planos de edificios, planes de emergencia, mapas de las zonas afectadas, rutas de evacuación,
localización de otras unidades, entre otros.
Figura 12: MSW para dar soporte a bomberos en emergencias urbanas de rutina
Este MSW también puede ser usado para gatillar mensajes o alarmas que puedan localizar a personal
clave o recursos especiales necesarios para un procedimiento.
3.1.2.1 Contexto
El proceso de respuesta a emergencias esta caracterizado por:
• Incluye trabajadores geográficamente distribuidos en la zona de emergencia, quienes deben
colaborar para mitigar la situación y reducir el daño que se pueda causar a las vidas humanas y a
las propiedades.
• Los bomberos necesitan información de posición y actividades realizadas por sus colegas para
colaborar en demanda.
• El personal necesita encontrar cantidad y posición de los recursos disponibles para mitigar una
situación.
• Los trabajadores no siempre pueden disponer de una infraestructura fija de comunicación.
• Los bomberos necesitan intercambiar información con otras personas que se encuentran en el
terreno o en el centro de comando.
• En la mayoría de las actividades realizadas, el tiempo es un factor crítico.
3.1.2.2 Problema
Los bomberos deben interactuar entre ellos, independientemente del lugar en donde se encuentren y de
las características físicas del área de la emergencia. Sus vidas, o incluso las vidas de otras personas,
25
dependen de estas interacciones. Más aún, el personal involucrado debe asumir que no es posible
disponer siempre de un sistema fijo de comunicación, por lo que su trabajo debe poder ser llevado a
cabo con autonomía y la colaboración debe ser en demanda.
3.1.2.3 Solución
Un MSW ha demostrado ser una herramienta apropiada para el proceso de toma de decisiones, en el
campo de las emergencias. Los requerimientos más importantes asociados a esta solución son:
• Autonomía de datos y servicios: es deseable que el MSW sea lo más autónomo posible,
considerando el alto número de decisiones que deben ser tomadas en paralelo, durante el
tiempo crítico de una emergencia, y el riesgo representado por la dependencia a una central o a
una infraestructura de comunicación.
• Comunicación ad-hoc: es importante dar soporte a transmisión de datos entre los usuarios, pues
los medios de comunicación basados en una infraestructura pueden no estar disponibles en un
cierto lugar o durante un cierto período de tiempo.
• Percepción de la posición y disposición de bomberos: este servicio ayuda a disminuir el tiempo
requerido para contactar a otros trabajadores en busca de un especialista o un recurso
específico.
• Intercambio de información: es necesario acceder y reportar información acerca del área
afectada (fotografías, mapas, localización de grifos). Este intercambio de información ayuda a
que las decisiones sean más rápidas y efectivas.
• Mensajería: esta funcionalidad es requerida por los bomberos, principalmente para generar
requerimientos o alarmas. Sin embargo, es la base para variados otros servicios, como por
ejemplo la transmisión de archivos con información relevante.
3.2 Patrón de Diseño de un MSW
Las características encontradas en los MSW previamente descritos, pertenecen a cualidades comunes de
un sistema de trabajo colaborativo móvil, que da soporte además a labores autónomas (multi-síncrono).
Por lo tanto, es posible instaurar una estructura de diseño abstracta, que defina a un MSW como un
patrón, que contenga los elementos claves y esenciales de cada escenario y que describa los servicios
requeridos (contexto, problema y solución). De esta manera, un MSW aplicado a un escenario en
particular, como por ejemplo el de la ITO, puede ser diseñado como una instancia particular de la
representación abstracta.
3.2.1 Contexto
La mayor parte de los trabajadores móviles realizan trabajo débilmente acoplado [55]. Este tipo de
trabajo contiene secuencias de tareas autónomas y actividades de colaboración en demanda, las que
pueden ser consumadas de manera multi-síncrona.
Los interesados que participan de este proceso pueden ser: Puntos Móviles (trabajadores en terreno),
Puntos Temporales (oficinas o emplazamientos temporales dentro del área circundante de trabajo) y/o
Puntos Formales (servidores centrales).
26
Usualmente el contexto de trabajo puede incluir elementos del ambiente físico en donde se encuentra el
personal (disponibilidad de comunicación inalámbrica, localización geográfica de personas o recursos).
Sin embargo, ya que los usuarios deben estar desplazándose en diferentes aéreas para realizar sus
tareas, el ambiente físico contextual es dinámico e impredecible.
3.2.2 Problema
Los trabajadores móviles deben ser lo más autónomo posible, en términos de los datos y servicios que
requieren para llevar a cabo sus actividades. Por otra parte, deben maximizar las posibilidades de
interacción con otros trabajadores, para ejecutar labores colaborativas en demanda.
En una situación ideal, un trabajador nómada debe poder detectar la presencia de otros usuarios, para
interactuar con ellos si lo requiere, independientemente del tipo de colaborador, o de su localización.
3.2.3 Solución
La solución propuesta define dos componentes base que dan cimiento al tipo de trabajo requerido
(figura 13), y que corresponden a:
• Dispositivo Móvil: apropiado para desarrollar tareas, dentro del ambiente laboral respectivo
(Tablet PC, PDA, Smartphone, entre otros), junto a una adecuada interfaz humano-computador.
• MSW: provee las funcionalidades necesarias para las actividades autónomas y de colaboración
en demanda. Asimismo, el MSW se divide en tres componentes. El Espacio de Trabajo
comprende los servicios y datos necesarios para realizar las tareas móviles. Los mecanismos de
Comunicación otorgan la conectividad requerida, mientras que los elementos de Coordinación
definen y permiten realizar interacciones avanzadas entre los distintos trabajadores.
La noción de una estructura abstracta que represente finalmente la arquitectura de diseño de un MSW
se obtiene al combinar este patrón con el conjunto de requerimientos comunes, encontrados en los
análisis de los distintos escenarios. Esta definición se precisa a continuación, en el detalle de cada
componente.
Figura 13: Patrón de diseño de un MSW
27
3.2.3.1 Espacio de Trabajo
Esta unidad se define como una “porción de la oficina”, diseñada usualmente para dar soporte a labores
personales y autónomas. Los recursos y herramientas asociadas se dividen en tres grupos (figura 14):
• Datos del Dominio: almacena y actualiza información relacionada con el proceso de trabajo
correspondiente.
• Servicios del Dominio: contiene las funcionalidades requeridas para realizar las actividades
móviles.
• Recursos Compartidos: otorga acceso y manipulación de recursos que son distribuidos en los
distintos usuarios de la red.
Figura 14: Estructura del Espacio de Trabajo
3.2.3.2 Mecanismo de Comunicación
Este módulo especifica la conectividad requerida por los usuarios móviles y establece los requerimientos
operacionales mínimos para dar soporte al trabajo colaborativo multi-síncrono. Tres grupos de
funcionalidades están presentes en este componente (figura 15):
• Servicios de Red: están a cargo de mantener la visibilidad necesaria del usuario hacia los demás
involucrados.
• Mensajería: provee transmisión de información entre los participantes.
• Servicios de Comunicación: usa los dos módulos anteriores para satisfacer requerimientos más
complejos, tales como localización geográfica de recursos, generación de alarmas, transmisión
de archivos, entre otros.
Figura 15: Estructura de los Mecanismos de Comunicación
3.2.3.3 Mecanismo de Coordinación
Este último componente define las funcionalidades que facilitan las interacciones avanzadas entre los
interesados y que dan soporte al trabajo móvil, especificando cuatro subcomponentes (figura 16):
28
• Espacio de Interacción: establece las interacciones que se realizan entre los usuarios, en
términos de tiempos y alcances. Aquí es posible usar el lenguaje MCM para modelar las
relaciones entre Puntos Móviles, Puntos Temporales y Puntos Formales.
• Administración de Roles y Usuarios: facilita la identificación de cada trabajador y su asociación a
grupos, que poseen permisos de acceso a ciertos recursos locales y/o compartidos.
• Percepción de Otros Usuarios: permite obtener información acerca de la localidad y las
actividades que realizan el resto de los trabajadores.
• Servicios de Coordinación: son utilizados para sincronizar información compartida, que ha sido
manipulada.
Figura 16: Estructura de los Mecanismos de Coordinación
3.3 Concepción de un MSW para ITO
A partir de los resultados obtenidos, una instancia de MSW es propuesta para dar soporte al trabajo
colaborativo, realizado por los trabajadores móviles de la ITO. Este diseño se detalla a continuación.
3.3.1 Espacio de Trabajo
La idea fundamental del espacio de trabajo, se sostiene en la capacidad para manejar distintos proyectos
de construcción mediante el uso de dispositivos Tablet PC y/o PDA (figura 17).
Dentro de cada proyecto debe ser posible generar y almacenar anotaciones digitales, sobre las distintas
capas y especificaciones de planos de cada edificación, que den cuenta de las observaciones realizadas
durante una ronda de inspección. Estas anotaciones deben poder ser compartidas y distribuidas entre
los distintos usuarios, además de ser comentadas y resueltas mediante mutua colaboración. Por otra
parte, para gestionar la programación de la obra (total, semanal y/o quincenal), una o más tareas deben
29
poder ser asignadas a las anotaciones, generando los datos correspondientes en la carta Gantt del
proyecto.
Figura 17: MSW para la ITO
3.3.1.1 Datos del Dominio
La información contenida, correspondiente al proceso de la ITO corresponde a:
• Proyectos de construcción.
• Planos.
• Anotaciones.
• Carta Gantt.
3.3.1.2 Servicios del Dominio
Los servicios necesarios para llevar a cabo las tareas de los distintos participantes corresponden a:
• Creación y administración de proyectos.
• Incorporación de planos digitales.
• Navegación por capas y planos.
• Creación y/o modificación de anotaciones.
• Interoperabilidad con carta Gantt.
30
3.3.1.3 Recursos Compartidos
Los recursos e información que se deben compartir y distribuir entre los distintos trabajadores
corresponden a:
• Proyectos de construcción.
• Planos.
• Anotaciones.
• Carta Gantt.
3.3.2 Mecanismo de Comunicación
La forma de comunicación entre los dispositivos móviles debe ser principalmente soportada mediante el
uso de una MANET. La colaboración entre inspectores es efectuada en demanda a medida que exista un
alcance de señal inalámbrica entre los dispositivos. Este tipo de red debe ser creada automáticamente y
debe proveer a los usuarios de información relevante, tales como calidad de señal, trabajadores móviles
conectados y estado del tráfico de mensajes.
3.3.2.1 Servicios de Red
Los servicios de red necesarios para establecer la comunicación entre los usuarios son:
• Formación automática de MANET.
• Detección e inclusión de dispositivos.
3.3.2.2 Mensajería
Las funcionalidades requeridas para el intercambio de mensajes en la MANET de la ITO son:
• Transmisión de mensajes de multidifusión.
• Transmisión de mensajes de unidifusión.
• Retransmisión de mensajes a dispositivos remotos, mediante intermediarios (routing).
3.3.2.3 Servicios de Comunicación
Los servicios necesarios para establecer comunicación a nivel de groupware son:
• Notificaciones del estado de la red.
• Visibilidad de usuarios conectados o desconectados.
• Mensajería de texto grupal y privada.
• Transmisión de mensajes de voz.
• Transmisión de archivos.
3.3.3 Mecanismo de Coordinación
Las interacciones entre los inspectores están principalmente determinadas por el modelo previamente
presentado en la figura 10.
31
3.3.3.1 Espacio de Interacción
Los colaboradores participantes son:
• Puntos Móviles: Supervisor, Inspector Jefe, Inspector Terreno.
• Puntos Temporales: Proyectista, Director de Obra.
3.3.3.2 Administración de Roles y Usuarios
Los servicios asociados al manejo de usuarios son:
• Autenticación distribuida de usuarios.
• Permisos de usuarios.
3.3.3.3 Percepción de Otros Usuarios
Los mecanismos de percepción de otros usuarios corresponden a:
• Calidad de señal de cada usuario.
• Localización del personal en los planos de construcción.
• Disponibilidad para colaboración.
• Roles.
• Tipo de dispositivo.
• Autor de cada anotación.
3.3.3.4 Servicios de Coordinación
Las funcionalidades de coordinación corresponden a:
• Sincronización de anotaciones.
• Sincronización de carta Gantt.
32
Capítulo IV: Interfaz Humano-Computador
La interacción humano-computador es un campo multidisciplinario que recae en las diversas habilidades
de diseñadores industriales, expertos en computación gráfica (tecnologías de visualización, dispositivos
de entrada, técnicas de interacción) y científicos cognitivos (cognición humana, percepción, destrezas
motoras). La mayoría de las investigaciones en interfaces se han concentrado en aquellas de tipo
individual. Los retos de la computación colaborativa deben abordar dicha perspectiva, con el objetivo de
resolver los problemas de interacción humano-computador dentro del contexto multiusuario o interfaces
grupales [19].
4.1 Dispositivo Móvil
El primer paso en el desarrollo de esta herramienta colaborativa para la ITO, ha consistido en elegir y
asignar dispositivos móviles que sean de utilidad y que se puedan adecuar al medio ambiente que se vive
en un proceso de construcción. Dados los requerimientos tecnológicos y funcionales, dos tipos de
unidades han sido seleccionadas: Tablet PC y PDA.
4.1.1 Tablet PC
Tablet PC (figura 18) es un dispositivo móvil que se logra adaptar de manera adecuada a un ambiente de
construcción y por ende a un proceso de inspección técnica en terreno [50].
Figura 18: Tablet PC
Estos instrumentos tienen la versatilidad de una pantalla sensible al tacto, junto al poder de
procesamiento de datos, memoria y comunicación de un computador de escritorio. Más aún, poseen
ciertas características que no se encuentran en equipos portátiles tradicionales, pudiendo ser usados en
distintos modos según la necesidad: modo de pantalla táctil o modo convencional (tipo notebook) [21].
Disponen además, de un lápiz (stylus) que permite realizar anotaciones sobre el visor, tal como si se
tratara de un lápiz que dibuja sobre un papel. El stylus se utiliza también para manejar todas las
funcionalidades de un ambiente de trabajo sin la necesidad de una interfaz adicional como teclado o
mouse.
33
Estos equipos permiten reemplazar el mecanismo de anotación tradicional de los inspectores (escritura a
mano sobre planos impresos), por una funcionalidad digital similar, que goza de las ventajas de
almacenamiento y gestión de información computarizada.
4.1.2 PDA
Dispositivos de tipo PDA (figura 19) han mostrado ser útiles en sistemas que dan soporte a grupos de
trabajo colaborativo, debido a su fácil manejo, sensación de pertenencia a los usuarios, factibilidad de
transporte hacia cualquier lugar, entre otros [68].
Figura 19: PDA
Estos computadores de bolsillo, ofrecen variadas funcionalidades y ventajas que se pueden utilizar para
crear un espacio de trabajo reducido para la ITO: poder de procesamiento adecuado, teclado, stylus,
cámara de foto y video, señal de red inalámbrica, entre otros. Su versatilidad y ligero peso, hacen que
sea más cómodo de manipular, especialmente si se requiere una movilidad más ágil. Permiten además,
que a las observaciones se le adjunte información fotográfica, y que este registro sea integrado a los
planos de la Tablet PC.
4.2 Espacio de Trabajo
La plataforma se establece en la capacidad para manejar distintos proyectos de construcción, en los
cuales es posible generar y almacenar anotaciones sobre planos digitales, que dan cuenta de las
observaciones realizadas sobre alguna parte de la obra. Estas anotaciones pueden generar una o más
tareas en la carta Gantt del proyecto, que resuelven el problema encontrado y que se asignan a una
compañía subcontratada o a un trabajador, usando el tiempo y los recursos que sean necesarios.
4.2.1 Administrador de Usuarios
El acceso a la aplicación está restringido a usuarios que hayan sido previamente registrados. El control se
realiza mediante la solicitud de un nombre y una contraseña, siendo un administrador del sistema el
encargado de agregar, modificar o eliminar usuarios. A cada uno de ellos se le debe asignar un rol que
determina los tipos de permisos que tienen tanto en la aplicación local, como en el acceso hacia los
recursos compartidos. Los roles predefinidos son: Inspector Terreno, Inspector Jefe, Sólo Vista (acceso a
visualizar los proyectos y las anotaciones de inspección) y Administrador (acceso a todas las
funcionalidades del sistema, incluyendo configuración de la aplicación y control de usuarios).
34
4.2.2 Administrador de Planos
Un proyecto puede manejar una gran cantidad de planos con distintas capas de información, tales como:
ascensores, climatización, comunicaciones, control centralizado, estructural, eléctrico, energía, escaleras,
instalaciones sanitarias, mobiliario, obras exteriores, puertas y ventanas, red húmeda, revestimiento,
riego automático, seguridad incendio, terminaciones, entre otros. Los planos pueden ser importados a
partir de imágenes digitales y asociados a los proyectos.
4.2.3 Administrador de Carta Gantt
La carta Gantt es administrada mediante un archivo de Microsoft Project, que es automáticamente
creado cuando un nuevo proyecto es generado. Adicionalmente, es permisible importar un archivo ya
existente para ser asociado a un proyecto.
4.2.4 Modulo de Inspección
El panel principal de la aplicación, implementado para dispositivos de tipo Tablet PC, está dividido en tres
secciones importantes: barra de herramientas superior, barra de herramientas izquierda y marco central
(figura 20).
Figura 20: Interfaz principal de inspección
El marco central se utiliza para el despliegue y navegación de los planos seleccionados y las capas de
información, así como también, para realizar las anotaciones de inspección mediante el stylus. Por otra
parte, las barras superiores e izquierdas se utilizan para dar acceso a funcionalidades de manejo de los
proyectos, planos, anotaciones y funciones colaborativas, y se dividen a su vez en: archivo, selección y
35
movimiento de plano, herramientas de anotación, filtro de anotaciones, detalle de anotación y modo de
conexión.
4.2.4.1 Archivo
Este menú de opciones permite crear, abrir o guardar proyectos en curso.
4.2.4.2 Selección de Plano
Una vez que el usuario ha seleccionado un proyecto en el cual trabajar, esta sección se habilita para
escoger el plano de construcción a inspeccionar y la capa de información que se desea desplegar en el
marco central.
4.2.4.3 Movimiento de Plano
Estas herramientas permiten navegar por el plano desplegado en el marco principal, mediante funciones
de desplazamiento horizontal, vertical y zoom. Se habilita además, una opción para volver a la posición
inicial en caso de que el usuario lo necesite. Estas funciones también pueden ser manipuladas haciendo
uso del stylus, el cual se puede desplazar sobre el plano, para generar un deslizamiento de la vista hacia
la posición deseada, a modo de arrastre.
4.2.4.4 Herramientas de Anotación
Esta funcionalidad permite crear nuevas anotaciones en el plano desplegado. El usuario debe, en primer
lugar, marcar un punto mediante un pincho para luego pasar al modo anotación, en donde puede
escribir o borrar trazos, seleccionar el color del lápiz, guardar y/o cancelar la anotación, entre otros
(figura 21).
Figura 21: Interfaz de anotaciones de inspección sobre un plano
36
4.2.4.5 Filtro de Anotaciones
El filtro de anotaciones otorga al usuario la funcionalidad de desplegar los registros que sean de su
interés, tales como aquellos que tengan tareas asociadas, que su autor sea un determinado usuario, o
que hayan sido ya completados. Las anotaciones ocultas se identifican por un pincho de color rojo, las
anotaciones visibles se despliegan usando un pincho anaranjado y la anotación que se encuentra
seleccionada se marca de color azul, tal como se muestra en la figura 22.
Figura 22: Colores de pinchos en anotaciones sobre un plano
4.2.4.6 Detalle de Anotación
El cuadro de detalle de anotación muestra información asociada a la observación que se encuentra
actualmente seleccionada (pincho de color azul), tal como la fecha de creación, el autor, tarea asociada,
porcentaje de trabajo logrado, entre otros.
4.2.4.7 Modo de Conexión
El modo de conexión establece el nivel de interacciones colaborativas al cual se quiere acceder, siempre
cuando otros usuarios se encuentren cerca o en formación de una MANET. Los posibles estados de
conexión son: autónomo (completamente aislado), colaborativo (disponible para todo tipo de
interacciones) u ocupado (disponible solamente para interacciones de urgencia).
4.2.5 Interoperabilidad con Carta Gantt
Una propiedad importante dentro de las funcionalidades del espacio de trabajo, es la asociación de las
tareas relacionadas a las anotaciones, con una hoja de carta Gantt de Microsoft Project. Este software,
es muy usado y apto en la gestión de proyectos de ingeniería, para asistir a administradores en el
desarrollo de planes, asignación de recursos a tareas y dar seguimiento al progreso de faenas, entre
otras características. Para ello el usuario puede utilizar el botón del stylus, que acciona el despliegue de
un menú adicional al apuntar el pincho de una anotación, permitiéndole asignar una nueva tarea de
37
Microsoft Project. Los datos requeridos para el ingreso de la nueva tarea son: nombre y duración en días
(figura 23).
Figura 23: Ventana de asociación de tarea
Esta interoperabilidad hace posible que la información introducida por los inspectores sea gestionada y
priorizada desde una herramienta diseñada específicamente para controlar los tiempos de trabajo.
Como resultado, se da lugar a una importante mejora en la administración de los proyectos y a un más
eficaz tiempo de respuesta a las decisiones (figura 24).
Figura 24: Interoperabilidad con carta Gantt
38
4.2.6 Módulo de Fotografías
Este mecanismo se encuentra implementado para dispositivos de tipo PDA, permitiendo que los usuarios
tomen un registro fotográfico en una ronda de inspección. Las imágenes recopiladas son almacenadas en
el equipo móvil y asociadas luego a un punto de anotación, dentro del plano correspondiente, mediante
una sincronización.
4.3 Estructura de Información
La información de un proyecto es ordenada y estructurada siguiendo el diseño mostrado en la figura 25.
Cada proyecto es almacenado en archivos separados, que contienen el conjunto de planos y la carta
Gantt de la obra. A su vez, cada plano almacena las imágenes digitales que corresponden a las distintas
capas de información, que son las que finalmente se despliegan en la aplicación. Así mismo, cada
anotación es almacenada en las capas correspondientes donde se generaron, junto a sus datos
específicos y a las tareas de Microsoft Project asociadas.
Figura 25: Estructura de información asociada a un proyecto de ITO
4.4 Interfaz de Colaboración
Cuando un grupo de personas trabaja en conjunto, en algún tipo de relación cara a cara, un gran número
de observaciones y apreciaciones de los demás ayudan a entender y asociar las tareas de cada
integrante. Este tipo de elementos de conciencia dentro de un MSW se denomina workspace awareness,
y ayuda a percibir y entender las interacciones entre los trabajadores dentro del espacio compartido:
quién está presente, en qué lugar está trabajando y qué se está haciendo, son algunos de estos
conceptos [28]. Además, reduce el esfuerzo requerido para coordinar tareas y recursos, ayuda a los
usuarios a moverse entre las labores individuales o grupales, provee un contexto dentro del cual
interpretar los mensajes y permite anticipar las acciones de los demás [29].
Una forma probada de implementar workspace awareness, es mediante componentes visuales de
información (widgets), que faciliten el acceso al estado de participación de los demás usuarios. Los
widgets presentes en la herramienta de ITO, se encuentran al costado derecho del espacio de trabajo y
se activan cuando el usuario pasa a un modo de conexión distinto del autónomo, al momento de acceder
un escenario de comunicación favorable (figura 26).
Algunos ejemplos de la información que se provee son: qué inspectores o trabajadores están presentes,
sobre qué sectores de los planos de la construcción están trabajando, que parte del proyecto están
inspeccionando (obra gruesa, terminaciones finas, instalaciones u otros), estado de sincronización de la
39
información generada, mensajería de conversación grupal, mensajes recibidos sin atender, entre varios
otros.
Figura 26: Widgets de colaboración dentro del MSW
4.4.1 Widget de Modo de Conexión
Esta componente muestra el modo de conexión en el que el usuario local se encuentra participando
(figura 27). Los posibles modos son: autónomo, colaborativo u ocupado.
Figura 27: Diferentes vistas de widget de modo de conexión
4.4.2 Widget de Usuarios
Esta ventana se encarga de entregar información de los usuarios detectados dentro de la MANET,
mediante íconos visuales que permiten establecer:
• Tipo de dispositivo o espacio de trabajo: se visualiza mediante la representación dibujada en el
ícono, la que puede ser un inspector, constructor con PDA, bombero, asistente médico u otras.
• Modo de conexión: se aprecia mediante el color del ícono, el que puede ser verde (para modo
colaborativo) o rojo (para el modo ocupado).
• Calidad de conexión: esta información se obtiene de la intensidad de color con la que se dibuja
cada usuario. A menor intensidad, menor es la calidad de comunicación.
40
• Tipo de interacciones: se aprecian mediante pequeñas figuras dentro de los íconos y sonidos que
representan la interacción que se está llevando a cabo, tales como mensajes recibidos,
sincronización en progreso u otras.
La figura 28 muestra diferentes vistas en el tiempo de un widget de usuarios. Los íconos entregan de
manera visual la información asociada a cada uno de los trabajadores. En el primer cuadro se aprecia a
un usuario de Tablet PC enviando un mensaje (Sergio) y a dos inspectores haciendo uso de PDA
conectados con buena calidad de comunicación (Francisco y Valeria). La segunda ventana despliega a un
inspector que hace uso de Tablet PC en modo ocupado (Sergio), junto a otros usuarios de PDA (Francisco
y Valeria) y a un usuario desconocido (Luis). Finalmente, en el último cuadro se aprecia a un inspector de
Tablet PC (Sergio) con buena calidad de señal y a otros que son usuarios de PDA, teniendo el último de
ellos una menor calidad de comunicación (Isabel).
Figura 28: Diferentes vistas de widget de usuarios
Este widget permite además, generar interacciones privadas con los trabajadores detectados. Al apuntar
un ícono de usuario presionando el botón del stylus, un menú es desplegado con opciones adicionales
que incluyen: envío de mensajes de texto privados, envío de mensajes de voz, sincronización de
anotaciones de inspección y descarga de recursos compartidos.
4.4.3 Posición de Usuarios
La posición de los inspectores se puede visualizar en el plano que se despliega en el panel principal. Si el
usuario así lo requiere, puede activar un atributo opcional que dibuja en el plano, íconos del resto de los
trabajadores en los lugares donde han realizado la última observación.
4.4.4 Widget de Conversación Grupal
En este widget los inspectores pueden enviar mensajes grupales que son recibidos por todos los
trabajadores que se encuentren conectados a la MANET. Un menú de despliegue otorga la posibilidad de
enviar mensajes pre-configurados, para que sean de fácil manejo, al hacer uso del stylus.
4.4.5 Widget de Mensajes
En este cuadro se almacenan los mensajes privados de texto o voz que han sido recibidos. El inspector
puede leer y responder los mensajes que son de su interés, los que son automáticamente marcados
como leídos.
41
4.4.6 Sincronización
Este widget se activa cuando se ha seleccionado la opción de sincronización de datos con otro inspector,
que se encuentre conectado en modo colaborativo a la MANET. Aquí se muestra el progreso de una
sincronización de anotaciones en curso.
42
Capítulo V: Infraestructura de Red y Comunicaciones
La sociedad adquiere gran parte de su carácter en las formas en como los individuos interactúan.
Mientras la tecnología en computación y las formas de comunicación electrónica convergen cada vez
más, las personas siguen relacionándose de nuevas y diferentes maneras. Uno de los retos más comunes,
que debe enfrentar el desarrollo de sistemas de trabajo colaborativo, es la creación de interacciones
distribuidas que sean tan efectivas como las interacciones cara a cara. La forma correcta de visualizar
este desafío es que una relación remota, represente un medio alternativo, al contrario de pretender
reemplazar las formas de interacción humana. Esto, a modo de dar soporte a medios de comunicación,
que pueden ser preferibles en variadas situaciones, donde la interacción grupal logra ser ampliamente
compleja [19]. Usualmente un proceso de trabajo, como el realizado en el transcurso de una
construcción, requiere que las personas colaboren y coordinen tareas e información. Sin embargo,
cuando los involucrados se encuentran dispersos, trasladándose de un lugar a otro, las posibilidades de
interacción, necesarias, usualmente disminuyen.
5.1 Protocolo de Comunicación
Un sistema basado en MANET debe ser consciente del protocolo de transporte de datos y de la topología
de la red. Si sólo se hace uso de estos mecanismos, como si fuesen una caja negra, se puede incurrir en
deficiencias, dada la naturaleza de múltiples saltos del medio de comunicación. En estos casos, es
completamente justificado mover la lógica de transmisión de mensajes y mecanismos de routing a la
capa de aplicación. Más aún, las redes tradicionales punto a punto son un clásico ejemplo de cómo la
lógica de transporte de datos es trasladada a una capa de alto nivel. En esa misma línea, redes de
distribución de contenido o multidifusión de alto nivel, son tecnologías creadas para superar las
limitaciones de las capas de transporte.
En el caso de una MANET, existen variadas razones por las cuales mover estos conceptos a la capa de
aplicación [22]:
• Flexibilidad y ajuste a requerimientos de groupware específicos.
• Facilidad de desarrollo, pruebas e instalación.
• Decisiones se pueden tomar en base a la topología del grafo de la red.
• Intercambio de información se ejecuta mediante un paradigma de alto nivel.
El protocolo de comunicación que se propone en este trabajo de tesis ha sido denominado Protocolo
MANET de Alto Nivel (HLMP: High Level MANET Protocol). Su propósito es establecer procedimientos de
automatización en la conformación de una MANET. De esta forma, dispositivos móviles heterogéneos
pueden entrar a la red y enviar mensajes a cualquier otro nodo presente, haciendo uso de un mecanismo
simple y eficaz, sobre las capas usuales de transporte de datos.
43
El concepto de HLMP consiste en que cada participante debe emitir constantemente un paquete de
datos, que contiene información acerca de él (un nodo) y de los dispositivos con los que posee una
conexión directa (los arcos). De esta manera, todos los usuarios pueden recolectar el conjunto de nodos
y arcos para generar el grafo de la MANET, que representa la visión y el conocimiento que tienen acerca
de ella en un instante de tiempo dado. Haciendo uso de este grafo, es posible determinar cuál es el
mejor vecino por el que se puede enviar un mensaje. Para ello, se calcula una ruta óptima, con un
algoritmo eficiente de búsqueda de caminos dentro un grafo, y se asocian costos a cada camino, que
pueden depender del estado del tráfico y de la calidad de señal de conexión de cada dispositivo.
Debido a que la morfología de la red es susceptible a cambiar impredeciblemente, alterando
rápidamente las propiedades de los caminos, el protocolo re-calcula la ruta a seguir en cada nodo por el
que debe transitar un mensaje. Esto se basa en información que se posee de la red en ese momento, y
no en análisis estadísticos o datos previamente enviados o recibidos.
Por otra parte, la implementación de HLMP se instaura sobre el resultado experimental del alcance de la
señal de red inalámbrica Wi-Fi de los dispositivos. Este alcance determina qué tipo de protocolo
estándar, de más bajo nivel, es factible usar eficientemente para ejecutar funcionalidades de
comunicación entre nodos vecinos, tales como UDP o TCP.
HLMP delega al sistema operativo las funcionalidades de bajo nivel, y sólo se encarga de componer la
arquitectura lógica de alto nivel de la MANET. Para ello se instauran procesos, tales como:
automatización de ingreso de nuevos dispositivos a la red, autoconfiguración de datos de identidad y
dirección de red, estandarización y estructuración de mensajes, detección de presencia, envío de
mensajes de multidifusión y unidifusión, entre otros.
5.2 Revisión de Estándares Usados
5.2.1 IP
Internet Protocol (IP) es un protocolo que fue creado con el propósito de ser usado en la transferencia
de información entre distintas redes interconectadas. Provee procesos e información para transmisión
de paquetes de datos (datagramas) desde el nodo origen hasta el nodo destino. La entrega de
datagramas se basa únicamente en la identificación de los terminales, bajo el uso de una dirección de
red de tamaño fijo. En IP versión 4, la dirección de red se compone de 4 bloques de 32 bytes cada uno
[36].
Este protocolo también provee fragmentación y re-ensamblado de paquetes, si es necesario, para
transmisión de datagramas por redes que admiten tamaños de bloques menores. Sin embargo, IP no
provee mecanismos de entrega confiable de paquetes, control de flujo, secuencias, ni servicios similares.
Hoy en día IP es, a nivel de red, el protocolo estándar fundamental tanto para la comunicación de datos
sobre Internet como para conformación de redes de área local.
En HLMP, IP es usado para establecer la comunicación básica dentro de una red inalámbrica de área
local, formada entre dispositivos que se encuentran en un área favorable, y para asignar una dirección de
red única a cada nodo presente en la MANET.
44
5.2.2 Wi-Fi
Wi-Fi es una marca registrada del grupo Wi-Fi Alliance, que certifica a sistemas que envían datos sobre
redes de ondas de radio frecuencia, basándose en el estándar definido por IEEE 802.11. El objetivo de
este estándar es especificar conectividad inalámbrica, tanto a nivel físico como en la transferencia de
datos, entre variadas máquinas, equipos portátiles o estaciones de trabajo que requieren un rápido
despliegue. Además describe uso y acceso a ondas de radio, según las legislaciones locales de cada zona
o país, usualmente alrededor de las bandas de frecuencias de 2.4 y 5 GHz [34].
Particularmente, el estándar IEEE 802.11 describe funciones y servicios requeridos por un dispositivo
para operar tanto dentro de redes que hacen uso de infraestructura (antenas fijas, puntos de acceso o
routers inalámbricos), como dentro de redes ad-hoc (comunicación directa dispositivo a dispositivo),
incluyendo aspectos de movilidad y transición.
Cabe destacar que esta tecnología no define un área física de cobertura para las señales radiales, puesto
que las características de propagación de ellas son dinámicas e impredecibles. Pequeños cambios en la
posición o dirección pueden resultar en diferencias significativas en la calidad de señal,
independientemente de si el dispositivo se encuentra en un estado estacional o móvil. La figura 29
muestra un mapa de diferencias de intensidad de señal, dentro de una habitación simple que contiene
un escritorio metálico (lado inferior izquierdo) y una puerta abierta (lado superior derecho). Se puede
observar que, aunque el escenario es estático y no considera el tiempo ni el movimiento de los
dispositivos, existen grandes contrastes relativos de señal.
Figura 29: Mapa de diferencias de intensidad de señal Wi-Fi en una habitación
Hoy en día Wi-Fi es soportado y usado para establecer redes de comunicación de manera no cableada,
por casi todos los dispositivos computacionales portátiles, consolas de video juegos, puntos de acceso a
internet, impresoras, teléfonos inteligentes, entre varios otros.
En HLMP, Wi-Fi es usado también como tecnología principal de comunicación inalámbrica, para
establecer una red de área local ad-hoc entre dispositivos que se encuentran en un escenario de
comunicación favorable.
45
5.2.3 WLan Ad-Hoc
Wireless Local Area Network (WLan) es una malla de comunicación inalámbrica que enlaza dos o más
dispositivos computacionales, que se encuentran dentro de una zona o área local que puede ser una
oficina, un edifico, una escuela, un aeropuerto, o lugares de términos similares. Para este fin, se hace uso
de tecnología que se encuentra definida bajo las especificaciones del estándar IEEE 802.11.
Particularmente, una WLan Ad-Hoc es una red de área local inalámbrica donde las estaciones se
comunican exclusivamente bajo un mecanismo descentralizado punto a punto, es decir, usando
comunicación directa entre los dispositivos.
El estándar IEEE 802.11 describe una modalidad de servicio definida como Independent Basic Service Set
(IBSS), que consiste en un enlace directo entre dos dispositivos. La figura 30 muestra la arquitectura
lógica de esta modalidad; en ella se aprecia cómo dos dispositivos (STA1 y STA2) que se encuentran
dentro de un área favorable, pueden utilizar servicios de comunicación (SS) usando las capas físicas (PHY)
y de datos (MAC) definidas.
Figura 30: Arquitectura lógica de un IBSS definido en IEEE 802.11
Más aún, si dos o más dispositivos se encuentran dentro de una zona de comunicación favorable y
configurados bajo la modalidad IBSS, pueden especificar y usar el mismo identificador de red, definido
como Service Set Identifier (SSID), para establecer una red ad-hoc entre ellos sin hacer uso de puntos
fijos de acceso a la red.
En HLMP, una WLan Ad-Hoc es construida cuando dos o más dispositivos se encuentran relativamente
cerca o dentro de un área de comunicación favorable, pudiendo así intercambiar datagramas usando
protocolos basados en IP.
5.2.4 UDP
User Datagram Protocol (UDP) es un protocolo de transporte construido sobre IP, que provee
procedimientos para que las aplicaciones puedan enviar mensajes a través de una red, haciendo uso de
un mecanismo básico. Su funcionalidad es orientada al envío de datagramas, por lo que los
procedimientos de entrega, duplicación u orden en que son recibidos no se encuentran garantizados
[56].
En la actualidad, UDP es usado en aplicaciones sensibles al tiempo, donde es preferible perder un
mensaje que entregarlo de manera atrasada, tales como tráfico de voz o video en tiempo real.
46
En HLMP, UDP es usado para los mecanismos de detección de nodos vecinos, recopilación de la
información de la MANET, control de la calidad de señal de los usuarios (usando la noción de pérdida de
paquetes) y otros.
5.2.5 TCP
Transmission Control Protocol (TCP), al igual que UDP, es un protocolo de transporte construido sobre IP.
La diferencia recae en que provee mecanismos para que las aplicaciones puedan enviar mensajes de
manera confiable. TCP asegura que un mensaje es correctamente entregado al destinatario. Para ello, se
implementan notificaciones de traspaso de datagramas entre receptor y remitente, retransmisión de
paquetes perdidos, control de flujo, entre otros, manteniendo una conexión constante entre los nodos
que participan en la comunicación [37].
TCP es, a nivel de transporte de datos, el núcleo fundamental de las comunicaciones sobre Internet y
redes de área local. Ejemplos típicos de su uso son Email, transferencia de archivos, aplicaciones Web,
entre otros.
En HLMP, TCP es usado para establecer conexiones directas entre dispositivos que se encuentran en
escenarios de comunicación estable, de esta forma es posible contar con un puente de transmisión
confiable entre nodos que pertenecen a una misma vecindad.
5.3 Rangos de Señal Inalámbrica
Diversos estudios han establecido características con respecto al envío y recepción de datagramas entre
dispositivos que se encuentran conectados mediante una red inalámbrica de área local. Dentro de estos
resultados destacan mediciones en cuanto a la efectividad en la propagación de datos [16], identificación
de errores de transmisión [18] y causas de problemas en la performance de TCP y UDP [67]. Algunos de
los múltiples factores que afectan el rendimiento de una WLAN son: tamaño de paquetes enviados, tipo
de interfaz o dispositivo de red inalámbrico, capacidad de procesamiento e implementación del
protocolo en el sistema operativo.
Debido a esto y a las diferentes propiedades físicas del ambiente (un edificio, casa o campo abierto), es
que se dificulta la creación de un modelo específico para protocolos tales como UDP o TCP, que refleje
exactamente un comportamiento esperado. No obstante, es posible encontrar generalidades, tales
como:
• La tasa de transferencia es influenciada por el poder de procesamiento de los dispositivos,
pudiendo uno de mayor rendimiento abrumar a los más lentos, produciendo una mayor pérdida
de datagramas [67].
• La tasa de pérdida de mensajes es baja y estable dentro de un cierto radio, que varía según el
ambiente y el contexto. Fuera de este rango, aumenta proporcionalmente la tasa de pérdida y la
corrupción de paquetes en función del tamaño y la distancia (a mayor tamaño y a mayor
distancia, menor calidad de señal y mayor pérdida) [16].
• Entre los factores ambientales que se consideran como fuentes de error en la entrega de
datagramas se encuentran: atenuación de las ondas electromagnéticas al cruzar distintos
materiales, interferencias con ondas de bandas cercanas, ruido por calor o influencias naturales,
47
dispersión o pérdida del camino por la distancia, movimiento de los transmisores (efecto
Doppler), entre otros [18].
Estos estudios permiten enmarcar el comportamiento general de una WLan, mostrando diferencias
según el ambiente operacional, pero no logran determinan qué tipo de protocolo específicamente es
factible ocupar bajo ciertas condiciones dadas. Sin embargo, es posible instaurar la siguiente hipótesis,
ante la intuición de los resultados previamente mencionados y bajo la definición de TCP y UDP:
“Existe una distancia D1 entre dos dispositivos que se conectan directamente mediante una WLan Ad-
hoc, dentro de la cual es efectivo utilizar el protocolo TCP, y existe además otra distancia D2 dentro de la
cual es efectivo utilizar el protocolo UDP, siendo D1 menor o igual a D2”
5.3.1 Experimento
Para observar cómo afecta la distancia que existe entre dos dispositivos móviles a los protocolos UDP y
TCP, se ha realizado un procedimiento experimental utilizando dos computadores portátiles idénticos en
hardware y sistema operativo. En cada dispositivo se han instalado las siguientes aplicaciones:
• Una aplicación que establece una conexión TCP, para enviar paquetes de datos de 1 Kbyte cada 1
segundo.
• Una aplicación que se suscribe a un grupo de multidifusión UDP, para luego enviar paquetes de
datos de 1 Kbyte cada 1 segundo.
El procedimiento ha consistido en conectar ambos dispositivos mediante una WLan Ad-Hoc, usando
asignación manual de direcciones IP y un SSID común, y ejecutar las aplicaciones para crear un
intercambio de datagramas entre ellos. En un principio se sitúan en un mismo punto, y luego e procede a
aumentar la distancia gradualmente en el tiempo, alejándolos uno del otro.
La figura 31 muestra uno de los lugares en donde se han efectuado las pruebas, los alrededores del piso
y la dirección en la que se alejan los dispositivos.
Figura 31: Escenario de experimento
5.3.1.1 Observaciones
El resultado observado en la recopilación de datos se ha acentuado en los siguientes hechos:
48
• Hasta una distancia D1, tanto la aplicación TCP como la aplicación UDP funcionan
apropiadamente. A partir de una distancia mayor a D1, la aplicación TCP no logra establecer la
comunicación, sin embargo la aplicación UDP sigue funcionando adecuadamente.
• Hasta una distancia D2 mayor a D1, la aplicación UDP funciona apropiadamente. A partir de una
distancia mayor a D2, la aplicación UDP no logra ser mínimamente efectiva, sin embargo los
dispositivos aún siguen estableciendo una WLan Ad-Hoc.
• Hasta una distancia D3 mayor a D2, los dispositivos logran establecer una WLan Ad-Hoc. A partir
de una distancia mayor a D3, se pierde la formación de la WLan Ad-Hoc entre los dispositivos y
ambos se aíslan completamente uno del otro.
5.3.1.2 Conclusiones
La naturaleza de la señal de la red inalámbrica y el comportamiento de los protocolos de comunicación,
comprueban la hipótesis planteada tras los resultados que se han observado. La explicación teórica
consiste en que el proceso usado por TCP para establecer una conexión que garantice la entrega de
paquetes, es mucho más exigente que la aplicación que hace uso de UDP asumiendo una tasa de pérdida
de paquetes razonable. A la vez, la aplicación UDP es más exigente que el protocolo utilizado por el
sistema operativo para establecer la WLan Ad-Hoc. Así, al alejar los dispositivos y disminuir la calidad de
señal inalámbrica entre ellos, aumentando la pérdida de datagramas, la aplicación TCP deja de funcionar,
por ejemplo, antes que la aplicación UDP.
En conclusión, es posible utilizar este resultado para formar rangos de comunicación adecuados en
función de la distancia teórica a la que se encuentren los dispositivos. Precisamente, se pueden
aprovechar las funcionalidades y la confiabilidad de TCP entre dispositivos que se encuentren lo
suficientemente cerca.
Así, HLMP define tres capas o rangos para el alcance de la señal inalámbrica de cada dispositivo: rango
TCP, rango UDP y rango WLan (figura 32).
Figura 32: Modelo de rangos de señal inalámbrica
5.3.2 Definición de Rango TCP
El rango TCP, se define como el alcance máximo que tienen los mensajes enviados mediante el protocolo
TCP, bajo un cierto criterio de efectividad en la transferencia de datagramas (máximo tiempo de espera
para el envío de mensajes). Cuando dos nodos se encuentran dentro del rango TCP, se considera que se
ha establecido una conexión directa entre esos nodos.
49
El conjunto de nodos que se encuentran en conexión directa con un cierto dispositivo, se considera parte
de la vecindad de ese dispositivo. La figura 33 muestra un ejemplo de vecindad (nodos C, H, I) de un
nodo (nodo F) en una MANET.
Figura 33: Vecindad de un nodo en una MANET
5.3.3 Definición de Rango UDP
El rango UDP, se define como el alcance máximo que tienen los mensajes enviados mediante el
protocolo UDP, bajo un cierto criterio de efectividad en la transferencia de datagramas (máxima tasa de
pérdida de datagramas). Cuando dos nodos se encuentran dentro del rango UDP, se considera que se ha
establecido un alcance de comunicación entre esos nodos.
El conjunto de nodos que se encuentran en alcance de comunicación con un cierto dispositivo, se
considera parte del grupo de multidifusión de ese dispositivo.
5.3.4 Definición de Rango WLAN
El rango WLan, se define como el alcance que tiene un nodo para formar una WLan Ad-Hoc con uno o
más dispositivos. Cuando dos nodos se encuentran dentro del rango WLan, se considera que se ha
establecido un alcance de señal entre esos nodos.
El conjunto de nodos que se encuentran en alcance de señal con un cierto dispositivo, se considera que
forma parte de la WLan Ad-Hoc de ese dispositivo.
5.4 Proceso de Conexión a la Red
Cuando un dispositivo desea acceder a la MANET, debe efectuar un proceso de conexión que asegure la
estabilidad básica del sistema. La figura 34 muestra los tres macro componentes de este proceso:
conexión a una WLan Ad-Hoc (sólo si existe un alcance de señal con otros usuarios), autoconfiguración
de dirección IP (incluyendo detección de direcciones duplicadas) y levantamiento de servicios UDP y TCP.
Figura 34: Proceso de conexión a la red
50
5.4.1 Conexión a WLan Ad-Hoc
En la etapa de conexión a la WLan Ad-Hoc, el dispositivo debe emitir constantemente hacia el medio un
perfil de WLan, usando como SSID una palabra común, seleccionada por la aplicación de groupware o las
capas superiores a este protocolo de comunicación. En sistemas operativos Microsoft tales como
Windows XP o Windows Mobile, el perfil de red se configura mediante una especificación en formato
XML. La figura 35 muestra la configuración básica de una WLan Ad-Hoc, usando la modalidad IBSS y el
SSID “MANET”, que un dispositivo puede emitir.
Figura 35: Representación XML de un perfil WLan Ad-Hoc en sistemas operativos Microsoft
Una red ad-hoc es creada sólo si existe al menos un segundo dispositivo con alcance de señal que emita
la misma configuración de red. Si el nodo que intenta conectarse se encuentra completamente aislado
de otros dispositivos, no será posible establecer una estructura de red. Lo anterior ocurre, debido a la
definición de la arquitectura lógica de una modalidad IBSS, por lo que se debe reiterar los intentos de
conexión hasta que otros usuarios sean encontrados.
5.4.2 Autoconfiguración de Dirección IP
Autoconfiguración de dirección IP es un requerimiento deseable en una MANET, pues usualmente los
procesos de comunicación son en demanda y deben permitir que nuevos dispositivos o usuarios puedan
participar en la colaboración.
En redes habituales, la distribución de direcciones IP se realiza mediante Dynamic Host Configuration
Protocol (DHCP), un protocolo que hace uso de un servidor central y que permite a los nodos obtener sus
parámetros de configuración. Una aproximación plausible para establecer un mecanismo similar, sin
hacer uso de un punto de sincronización central, es permitir que los nodos elijan una dirección de red
tentativa, de manera aleatoria, y luego lleven a cabo un proceso de detección de dirección duplicada
(DAD: Duplicate Address Detection) [62].
Este proceso debe contener dos fases: fuerte y débil. En fase fuerte, el dispositivo detecta direcciones
duplicadas dentro de su red de área local. Por otra parte, en fase débil, el dispositivo detecta colisiones
51
con nodos que se encuentran alejados y con los que se logra comunicar sólo mediante routing de
mensajes.
HLMP define el siguiente proceso para la automatización en la configuración de dirección IP:
• El dispositivo debe escoger aleatoriamente dos números enteros entre 1 y 255, X e Y.
• El dispositivo debe configurar como dirección IP, la estructura “170.160.X.Y”.
• El dispositivo debe configurar como máscara de sub-red, la estructura “255.255.0.0”.
La etapa DAD en fase fuerte es delegada al sistema operativo. Este procedimiento detectará
duplicaciones al momento de ingresar a una MANET, analizando los nodos que se encuentren dentro de
la WLan Ad-Hoc del dispositivo.
La etapa DAD en fase débil es manejada por el protocolo, y consiste en verificar constantemente las
direcciones IP de todos los mensajes recibidos o re-direccionados por el dispositivo. Así, se podrá
detectar duplicaciones analizando a nodos que se encuentren en otras redes adyacentes, o en casos
cuando redes distintas se junten y amalgamen en algún instante de tiempo.
Si existe un resultado positivo en el proceso de detección de duplicación, se debe realizar nuevamente la
etapa de configuración de IP.
5.4.3 Levantamiento de Servicios TCP y UDP
Finalmente, el nodo debe levantar los siguientes servicios correspondientes a los rangos TCP y UDP para
dar comienzo a la comunicación:
• Un servicio TCP en la dirección IP previamente configurada, que acepte conexiones y reciba
datagramas mediante el puerto 30001.
• Un servicio UDP que se suscriba al grupo de multidifusión con dirección IP “224.0.0.2” para
recibir datagramas mediante el puerto 30002.
5.5 Estructura de Mensajes
Un Mensaje de Red o datagrama HLMP está compuesto por un encabezado de 4 bytes que indica el
tamaño en número de bytes de los datos embebidos, y un cuerpo que contiene el mensaje en sí, llamado
Mensaje de Comunicación figura 36 (a). Un Mensaje de Comunicación es un paquete organizado de
bytes que contiene datos e información relacionada con un mensaje de alto nivel, y al igual que un
Mensaje de Red, también posee un encabezado y un cuerpo. Los datos agrupados en el encabezado,
dependen de la mecánica requerida para enviar el mensaje. HLMP define cinco tipos generales de
mensajes, llamados metatipos:
• Multicast: representa a mensajes de multidifusión, que son enviados a todos los nodos de la red
usando el rango UDP.
• SafeMulticast: representa a mensajes de multidifusión, pero que son enviados a todos los nodos
de la red usando el rango TCP.
• Unicast: representa a mensajes de unidifusión, que son enviados a un solo usuario en la red,
usando el rango TCP.
52
• SafeUnicast: representa a mensajes de unidifusión, que son enviados a un solo usuario en la red,
usando el rango TCP, pero cuya entrega debe ser además confirmada por el dispositivo receptor.
• FastUnicast: representa a mensajes de unidifusión, que son enviados a un solo usuario en la red,
pero usando el rango UDP. Este tipo de mensaje es útil para transmitir mensajes de video o voz
en tiempo real.
Figura 36: Estructura de mensajes
La figura 36 (b), muestra la definición de los encabezados para los distintos metatipos de mensajes. La
información contenida en ellos corresponde a:
• Metatipo: número entero con el código del metatipo del mensaje. HLMP usa los enteros del 1 al
5 para identificar a los cinco metatipos definidos.
• Tipo: número entero con el código del tipo del mensaje, los que son establecidos por las
funcionalidades requeridas o capas superiores de cada aplicación. HLMP utiliza el número 1 para
identificar a mensajes de tipo I’m Alive y el número 2 para mensajes de tipo Ack.
• Subprotocolo: número entero con el código del subprotocolo que se encarga de atender el
mensaje. Los códigos son, al igual que el tipo del mensaje, establecidos por las capas superiores
de cada aplicación. Por ejemplo, es posible separar la atención de mensajes según distintos
subprotocolos, que pueden ser prueba de velocidad, mensajería instantánea, transferencia de
archivo, transmisión de voz, entre otros.
• Id de Autor: número de identificación del usuario que envía el mensaje.
• IP de Autor: número de dirección IP del usuario que envía el mensaje.
• Id de Mensaje: número de identificación del mensaje. Este código es autogenerado por HLMP de
manera aleatoria y con un algoritmo que garantiza baja probabilidad de colisión.
• Saltos: número de saltos, o cantidad de dispositivos por los cuales ha pasado el mensaje antes de
llegar a su destinatario final.
53
• Id de Destinatario: número de identificación del usuario destinatario del mensaje, para el caso de
mensajes de unidifusión. Los mensajes de multidifusión no necesitan este atributo, pues estos
son distribuidos a todos los destinatarios posibles.
• IP de Destinatario: número de dirección IP del usuario destinatario del mensaje, para el caso de
mensajes de unidifusión.
En último lugar, el cuerpo de un Mensaje de Comunicación corresponde a los datos particulares que se
requieren, para cada funcionalidad de groupware en específico.
5.6 Transmisión de Mensajes de Multidifusión
Este proceso estable las funcionalidades requeridas para enviar y ejecutar procedimientos de routing en
mensajes de multidifusión. Para ser llevado a cabo, los dispositivos no necesitan información acerca de la
topología de la red.
Sin embargo, es necesario disponer de una lista, llamada MessageIdList, para almacenar temporalmente
los números de identificación de cada mensaje recibido o retransmitido. De esta forma, si un paquete es
recogido por dos o más caminos distintos, no se genera un problema de duplicación, al procesar dos
veces el mismo mensaje.
La lista debe estar compuesta de una cola de prioridad First In First Out (FIFO) y una tabla de hash. La
cola permite eliminar a los mensajes más antiguos, al momento de ingresar a los nuevos, cuando se
alcanza el límite máximo. La tabla de hash ayuda a realizar búsquedas en tiempo de orden constante,
con el propósito de verificar si un número identificador de mensaje ha sido previamente registrado.
5.6.1 Algoritmos
El proceso consiste esencialmente en transmitir un datagrama a todos los nodos posibles que se puedan
alcanzar mediante un salto. Al recibir un mensaje de este tipo, todos los nodos deben a la vez
retransmitirlo a todos sus conocidos, a modo de inundar la red.
Para tener un control sobre la inundación, se almacenan temporalmente en la MessageIdList, todos los
números identificadores que pertenezcan a mensajes tanto enviados como recibidos. Esto permite
detectar posibles mensajes duplicados, que provengan de caminos distintos, buscando siempre en la
lista una posible colisión antes de ser atendidos.
El Algoritmo 1 y el Algoritmo 2 detallan los procedimientos usados por el protocolo para enviar y recibir
mensajes de multidifusión usando el rango UDP (Multicast). Para usar el rango TCP (SafeMulticast),
simplemente se debe usar la vecindad en vez del grupo de multidifusión.
Algoritmo 1: Procedimiento para enviar un mensaje de multidifusión
54
Algoritmo 2: Procedimiento para recibir un mensaje de multidifusión
5.6.2 Ejemplo
La figura 37 muestra un ejemplo del proceso de transmisión de mensajes de multidifusión, en una malla
de comunicación MANET simple. El proceso ocurre de la siguiente manera: (a) el nodo A desea enviar un
mensaje de multidifusión M, remitiéndolo a su grupo de multidifusión que corresponde sólo a los nodos
B y C; (b) los nodos B y C reciben el mensaje M, procesándolo y reenviándolo a sus propios grupos de
multidifusión; (c) los nodos A, B y C detectan la duplicación del mensaje M, por lo que lo descartan al
momento de recibirlo, los nodos D y E reciben y procesan el mensaje, reenviándolo hacia los nodos con
los que tienen alcance; (d) los nodos B, C, D y E descartan el mensaje, sólo el nodo F lo recibe, procesa y
reenvía, para que luego, el nodo E detecte la copia del mensaje, lo descarte y finalice el proceso. Al
concluir la transmisión, el mensaje M ha sido propagado por toda la red y todos los nodos lo han
procesado tan sólo una vez.
A DC
E FB
M
A DC
E FB
M M
M
A DC
E FB
M M
M
M
M MA DC
E FB
M M
M
M
M
(a) (b)
(c) (d)
Figura 37: Ejemplo de transmisión de un mensaje de multidifusión
5.6.3 Mecanismo de Detección de Usuarios
Para generar el grafo de la MANET en la memoria de cada nodo presente, se debe enviar y recopilar
información acerca de la topología de la red, mediante un mecanismo de detección de usuarios. Esta
55
metodología se basa en la transmisión de un mensaje de multidifusión (Multicast) llamado I’m Alive. Este
mensaje contiene el conjunto de arcos, que corresponden a las conexiones de la vecindad, creados por
los enlaces activos TCP con otros dispositivos.
Mientras se encuentren conectados a la MANET, cada nodo debe emitir constantemente su
correspondiente mensaje I’m Alive cada 1 segundo. Nuevos nodos deben enviar mensajes con un
conjunto vacío de arcos, mientras que los más antiguos deben enviar su correspondiente vecindad. Para
procesar los mensajes I’m Alive que son recibidos, los dispositivos convienen ejecutar el Algoritmo 3.
Algoritmo 3: Procedimiento para recibir un mensaje de tipo I'm Alive
Cuando un nodo es agregado al grafo de la MANET, al recibir un mensaje I’m Alive, la información y
todos los arcos definidos en él son almacenados. Además, cuando se detecta que el nodo es un posible
candidato para ubicarse dentro de la vecindad, el dispositivo receptor trata de generar una conexión TCP
con el autor del mensaje.
Si el enlace TCP no es logrado, el nodo puede esperar un intervalo de tiempo de 10 segundos antes de
tratar de generar otra conexión, siendo esta pausa un valor determinante en cuán rápido la red
reacciona a cambios en la vecindad. Por otra parte, si una conexión TCP es finalizada, el enlace es
removido del conjunto de arcos que se propagan dentro del mensaje I’m Alive.
El grafo de red obtenido al hacer uso de este mecanismo, es usado mas tarde para enviar mensajes de
unidifusión.
5.6.4 Calidad de Señal
La calidad de señal de cada usuario es medida con el objetivo de detectar información antigua en el grafo
de la MANET, y para detectar dispositivos que han salido de la red o han pasado a un estado de trabajo
autónomo. Porciones del grafo que no hayan sido recientemente actualizadas pueden llevar a malas
decisiones en los procedimientos de routing de mensajes de unidifusión.
Cuando un nodo es agregado al grafo de la MANET, un valor de calidad es configurado en él con el
número 25 y luego reducido en 1 cada 1 segundo. Si la calidad del nodo alcanza el valor 0, se asume que
ha salido de la red o ha pasado a un modo de trabajo autónomo, por lo que todas las conexiones son
terminadas y es removido del grafo. Por otra parte, si la información del nodo es actualizada mediante el
Algoritmo 3, entonces el valor de su calidad es incrementado en 5, con tope máximo el valor inicial.
La calidad de señal es finalmente divida en 3 subconjuntos:
56
• Señal Crítica: si un nodo posee un valor de calidad entre 1 y 10.
• Señal Baja: si un nodo posee un valor de calidad entre 11 y 20.
• Señal Normal: si un nodo posee un valor calidad entre 21 y 25.
Esta medida de calidad de señal representa qué tan actualizada es la información de un nodo específico
dentro del grafo de la MANET, y es además referencia elemental para determinar el procedimiento de
routing al transmitir mensajes de unidifusión.
5.6.5 Estado del Tráfico
El estado de tráfico es una medida local de cada usuario. Un valor de tráfico es configurado y actualizado
en cada dispositivo con el número de mensajes de unidifusión que se han recibido en el último segundo.
El estado del tráfico es también dividido en 3 subconjuntos:
• Tráfico Crítico: si un nodo posee un valor de tráfico mayor a 20.
• Tráfico Sobrecargado: si un nodo posee un valor de tráfico entre 11 y 20.
• Tráfico Normal: si un nodo posee un valor de tráfico entre 0 y 10.
Los valores asignados en los subconjuntos pueden depender del poder de procesamiento de cada
dispositivo y/o el tamaño de los mensajes. El estado es añadido a cada mensaje I’m Alive que es enviado,
y representa cuánto retraso de procesamiento puede tener un mensaje al momento de transitar por el
nodo. Es también información importante al momento de decidir las rutas que deben seguir los
mensajes de unidifusión.
5.6.6 Límite de la Lista
Con el objetivo de determinar un tamaño acotado y eficiente para la MessageIdList, se ha analizado el
siguiente posible escenario, que se desprende de los procedimientos previamente explicados:
• Un mensaje M es recibido y su número de identificación almacenado en MessageIdList.
• Tiempo después, otros mensajes son recogidos y sus propios números de identificación son
guardados también en MessageIdList. Esto provoca que el código de M se mueva hacia las
últimas posiciones. Tiempo después es eliminado, al llegar a un lugar mayor al tamaño máximo
de la lista.
• Finalmente, una copia del mensaje M es recibida. Una búsqueda en la lista arroja que no ha sido
previamente ingresado, pues su número identificador ya ha sido removido, provocando que sea
procesado nuevamente.
Este evento es lo que se conoce como el problema de duplicación de un mensaje. Esto puede generar
que un paquete de datos, duplicado por la diversidad de caminos hacia un nodo destino, sea procesado
erróneamente dos veces. Asentado en ese comportamiento, se instancia la siguiente hipótesis:
“La estimación de la probabilidad para que ocurra el problema de duplicación de un mensaje, permite
determinar un tamaño eficiente de la lista”
Para establecer el tamaño máximo apropiado de MessageIdList, que logre soslayar el problema de
duplicación de un mensaje, se propone analizar un modelo que simplifique el comportamiento de una
57
MANET. El objetivo de este estudio es estimar y minimizar la probabilidad de colisión de dos mensajes
idénticos. Este modelo se describe de la forma siguiente:
• Un usuario cualquiera realiza una observación, por instante de tiempo, a los mensajes que recibe
de la MANET, como si la red fuese un túnel de mensajes (figura 38).
• El usuario estima que en cada observación se encuentran, en promedio, M mensajes en el túnel.
Figura 38: Modelo de recepción de mensajes en una MANET
• El mismo usuario considera, según los remitentes de los mensajes observados, que existe un
total de Z usuarios en la red.
• Cada uno de los Z usuarios ve a la MANET en la misma forma de túnel. Con esta idea es posible
estimar que en toda la red existen, en cada observación, un total de Z*M mensajes (figura 39).
…
Figura 39: Modelo generalizado de una MANET
Sea ahora, el siguiente escenario:
• Un mensaje M es recibido por un usuario y el número de identificación almacenado en
MessageIdList. Una copia del mensaje M se ha generado en algún lugar desconocido de la
MANET.
• El usuario receptor del mensaje M, comienza ahora a procesar mensajes recibidos
secuencialmente.
• La probabilidad de que reciba la copia del mensaje M es 1 sobre el total de mensajes de la
MANET (Ecuación 1).
58
Ecuación 1: Probabilidad de que aparezca el mensaje duplicado
• La probabilidad de que no lo reciba, es la probabilidad de recibir cualquiera del resto de los
mensajes de la MANET (Ecuación 2).
Ecuación 2: Probabilidad de que no aparezca el mensaje duplicado
• El usuario atiende una cantidad de mensajes igual a L, con L el tamaño máximo de la lista. El
número identificador del mensaje original ya ha salido y ninguno de los mensajes recibidos ha
correspondido a la copia, por lo que el problema de duplicación de mensaje puede ocurrir en
cualquier momento a partir de esta situación.
• La probabilidad de que ocurra esta situación es L veces la probabilidad de que no se reciba el
mensaje duplicado (Ecuación 3), lo que satisface la hipótesis planteada.
Ecuación 3: Probabilidad de que ocurra el escenario del problema de duplicación de mensaje
Usando el planteamiento anterior, es posible calcular el tamaño máximo de la lista, en función de la
probabilidad de que ocurra el escenario de duplicación de un mensaje. La idea ahora es minimizar dicha
probabilidad y calcular el tamaño máximo dinámicamente, en función de la cantidad de mensajes que
son recibidos por unidad de tiempo y el total de usuarios en la MANET (Ecuación 4).
Ecuación 4: Fórmula del largo de la lista en función de la probabilidad esperada
La figura 40 muestra un gráfico que despliega el tamaño de la lista calculado para distintas cantidades de
nodos en la red, en donde cada dispositivo debe emitir un mensaje cada 1 segundo y en donde la
probabilidad para el escenario de duplicación es de 1E-100. En él se compara la memoria requerida para
almacenar los números identificadores de mensajes, con una lista de tamaño ilimitada que crece
linealmente en el tiempo. Para redes con cantidades de usuarios menores a 100, la lista limitada
representa un ahorro considerable de memoria para aplicaciones con funcionamiento continuo de entre
10 o más horas.
59
Figura 40: Gráfico de comparación del tamaño de la lista limitada con listas ilimitadas
5.6.7 Control de Carga de Mensajes
Un control de carga de mensajes de multidifusión se lleva a cabo, para aminorar efectos no deseados en
la estrategia de inundación en la red. Una cantidad alta de paquetes que se deben transmitir y
retransmitir a todos los dispositivos puede ser innecesaria en algunos casos. Ejemplo de esto es cuando
el grafo de la MANET presenta esquemas en donde todos los usuarios se encuentran a tan sólo un salto
de cualquier otro nodo, llevando a redundancia y tráfico innecesario de datos [49].
Una forma intuitiva de solventar este problema es mediante un sistema de routing probabilístico.
Cuando un nodo se encuentre en un escenario como el descrito anteriormente, debe retransmitir
mensajes de multidifusión recibidos, con una probabilidad igual a un 50%. Esto reduce aproximadamente
en la mitad la cantidad de datos que se retransmiten sin utilidad, y deja espacio para que una porción de
los mensajes transiten hacia nodos remotos que puedan aparecer y que se encuentren en otras
vecindades.
5.7 Transmisión de Mensajes de Unidifusión
Este proceso establece la funcionalidad requerida para enviar mensajes de unidifusión de manera
confiable (SafeUnicast), con el objetivo de que sean entregados y procesados por sólo un usuario dentro
de la MANET, utilizando los canales TCP. Los dispositivos deben emplear el conocimiento acerca de la
MANET, que obtienen mediante el mecanismo de detección de usuarios, y los valores de calidad de señal
y estado de tráfico para generar una matriz de costos (figura 41). Esta matriz es usada para asignar pesos
a los caminos dentro del grafo de la MANET, las filas indican la calidad de señal de cada dispositivo y las
columnas su estado de tráfico. Cuando se ejecutan los cálculos de búsqueda de un camino óptimo, el
resultado de combinar dichas variables es asignado a todos los caminos adyacentes a cada nodo.
La MessageIdList, utilizada en el proceso de transmisión de mensajes de multidifusión, es usada también
aquí, para enfrentar el problema de duplicación de un mensaje. Asimismo, es requerido un tipo de
0
20
40
60
80
100
120
140
160
180
1 5
10 15
20
25
30 35
40
45
50
55
60
65
70 75
80
85
90
95
100
Me
mo
ria
Ne
ce
sari
a (
MB
)
Cantidad de Nodos
Limitada
Ilimitada 5 Horas
Ilimitada 10 Horas
Ilimitada 15 Horas
60
mensaje llamado Ack (de metatipo Unicast), que transporta el número identificador de un mensaje
recibido, con el propósito de confirmar su entrega.
Los metatipos Unicast y FastUnicast hacen uso de un mecanismo similar, pero sin la confirmación de los
mensajes, usando los canales TCP y UDP respectivamente.
Figura 41: Matriz de costos asignados a los caminos del grafo de la MANET. Las filas establecen la calidad de señal y las
columnas el estado de tráfico.
5.7.1 Algoritmos
El proceso para enviar un mensaje de unidifusión es descrito mediante el Algoritmo 4, y se basa en la
decisión de cuál es el mejor vecino por el que es posible transmitirlo. Para ello, se debe calcular el
camino óptimo dentro del grafo hacia el destinatario, usando el algoritmo de Dijkstra, y usar la conexión
TCP con el primer nodo obtenido, para entregar el datagrama. La ruta computada no es almacenada en
el mensaje, sino que es recalculada en cada nodo, cuando es recibido y se detecte que se debe
retransmitir hacia otro dispositivo.
Algoritmo 4: Procedimiento para enviar un mensaje de unidifusión
Después de efectuar el primer envío, el autor del mensaje debe esperar un intervalo de tiempo, para
reenviarlo en caso de que no reciba la confirmación (Ack). Por otra parte, si el algoritmo de búsqueda de
un trayecto en el grafo de la MANET retorna un conjunto vacío, se asume que no existe una forma
adecuada para alcanzar al nodo destino, por lo que el mensaje debe ser procesado como fallido usando
el Algoritmo 6.
El Algoritmo 5 muestra el procedimiento que un nodo debe ejecutar cuando un mensaje de unidifusión
ha sido recibido. Por una parte, si el nodo verifica que el destinatario final es otro usuario, debe ejecutar
una nueva búsqueda de trayectoria hacia el receptor, con el objetivo de efectuar un mecanismo de
routing. Por otra parte, si el destinatario del mensaje es él, debe usar entonces la MessageIdList para
mantener registro de la recepción, pues el nodo autor del mensaje puede estar enviando copias de él
61
debido a pérdidas, tiempos de espera por sobre tráfico u otros. Finalmente, el nodo receptor debe
acusar la entrega, enviando el Ack correspondiente.
Algoritmo 5: Procedimiento para recibir un mensaje de unidifusión
Si algún nodo detecta que una duplicación de un mensaje ha sido recibida, debe enviar nuevamente la
confirmación mediante el Ack, pues es desconocido qué mensaje ha generado la copia: una pérdida o
retraso en el Ack o una pérdida o retraso en el original.
En último lugar, el Algoritmo 6 describe la manera de procesar un mensaje de unidifusión que ha sido
marcado como fallido. Cuando se ejecuta dicha operación, el nodo debe chequear si el usuario
destinatario del mensaje aún sigue en la red y esperar un intervalo de tiempo, de manera de ofrecer una
oportunidad para que se pueda crear un camino, debido a la movilidad de los usuarios. Si luego de varios
intentos, el mensaje vuelve a ser procesado como fallido, o si se detecta que el destinatario ha salido
completamente de la red, entonces una alerta es entregada al usuario autor del mensaje, o bien es
descartado si se encuentra en algún nodo intermedio.
Algoritmo 6: Procedimiento para atender un mensaje de unidifusión que ha fallado
62
5.7.2 Ejemplo
La figura 42 muestra un ejemplo simple de transmisión de un mensaje de unidifusión en una MANET. Los
costos de cada camino han sido omitidos para ejemplificar el mecanismo principal. Los pasos son: (a) el
nodo A desea enviar el mensaje M al nodo D, calcula la ruta óptima y selecciona al nodo C como el mejor
vecino para enviar el mensaje; (b) el nodo C recibe el mensaje M, recalcula la ruta y selecciona al nodo E
como el mejor vecino, alterando la ruta original debido a un cambio en las conexiones de la red; (c) el
nodo E recibe y retransmite el mensaje hacia el nodo D; (d) el nodo D recibe y procesa el mensaje,
enviando el Ack correspondiente hacia el nodo C; (e) el nodo C recibe el Ack, recalcula la ruta óptima y lo
entrega al nodo A; (f) finalmente, el nodo A recibe la confirmación del mensaje M y el proceso finaliza.
Figura 42: Ejemplo de transmisión de un mensaje de unidifusión
5.8 API
HLMP ha sido implementado en forma de librería, para ser usado en la programación de sistemas
colaborativos móviles. La API contiene dos grandes elementos: Núcleo y Módulos Adicionales (figura 43).
El Núcleo ejecuta los mecanismos que dan soporte a las funcionalidades de comunicación, intercambio
de datos de red, e interoperabilidad con el sistema operativo. Por otra parte, los Módulos Adicionales
definen interfaces que permiten programar subprotocolos avanzados de comunicación y componentes
propias de sistemas colaborativos, usando los servicios que son implementados en el Núcleo.
Figura 43: Estructura de HLMP API
63
5.8.1 Núcleo
El núcleo es la componente base de la implementación de HLMP. En él se configuran los parámetros de
funcionamiento y se ejecutan los procedimientos de conexión, transmisión y routing de mensajes en la
red.
También mantiene control de eventos, reportados mediante mecanismos de percepción, que son útiles
para crear y enriquecer las interacciones de aplicaciones colaborativas, conectadas mediante una
MANET.
La estructura del Núcleo se divide en tres subcomponentes funcionales: Interoperabilidad, Red y
Comunicación.
5.8.1.1 Interoperabilidad
Esta capa está a cargo de procedimientos que son delegados al sistema operativo que tienen relación
con el proceso de conexión a la MANET. Algunos de ellos son: configuración del perfil de WLan Ad-Hoc
en formato XML, control del dispositivo de red inalámbrico, configuración de dirección IP y sub-máscara
de red, DAD en fase fuerte, lectura de notificaciones del sistema operativo, entre otros.
5.8.1.2 Red
Esta componente implementa servicios TCP y UDP, necesarios para el intercambio de datagramas en la
MANET. Al momento de ser recibidos, los mensajes son validados y encolados, para ser luego atendidos
por la capa de Comunicación. Esta capa tiene también la responsabilidad de administrar las conexiones
TCP, con dispositivos remotos que se encuentran dentro de la vecindad del usuario.
5.8.1.3 Comunicación
Este módulo implementa la interfaz que los desarrolladores pueden usar, para dar soporte a la
comunicación en aplicaciones colaborativas móviles. Administra también, los servicios de organización
de mensajes y empaquetamiento de datos, entre otros.
Su funcionamiento radica en atender la cola de datagramas recibidos por la capa de Red, y usar un
módulo de fábrica para transformarlos en mensajes de comunicación de alto nivel. Las posibles acciones
que se ejecutan, en la recepción de un mensaje, incluyen: atención y procesamiento, notificaciones,
asignación de subprotocolo, routing, entre otros.
Esta capa dispone también, de una cola de salida de mensajes. Este conjunto es procesado y
transformado en paquetes de bytes, que son enviados luego hacia los destinatarios, mediante la capa de
Red.
La figura 44 muestra cómo los mensajes de comunicación son organizados. La API usa la especificación
de HLMP para crear un modelo orientado a objetos. La clase principal Message contiene la información
básica de un mensaje: número de identificación, código de metatipo, código de tipo, información acerca
del remitente y la cantidad de dispositivos por los cuales ha transitado. De esta clase se derivan cinco
subclases abstractas, que representan a los cinco metatipos de mensajes definidos por HLMP: Multicast,
SafeMulticast, Unicast, SafeUnicast y FastUnicast.
64
Figura 44: Diagrama de clases de mensajes
Los metatipos implementan distintos mecanismos, que se utilizan para enviar el paquete de datos,
ejecutando llamadas a funcionalidades de la capa de Red, considerando la semántica definida para cada
uno de ellos. Por ejemplo, los mensajes de tipo Multicast son enviados a todos los usuarios de la red,
usando los canales UDP, mientras que los mensajes Unicast son enviados particularmente a un solo
usuario, usando los canales TCP.
Los desarrolladores pueden implementar nuevas clases que deriven de alguno de los metatipos, con el
objetivo de construir mensajes para requerimientos específicos de groupware. Algunos ejemplos son: la
programación interna del mensaje I’m Alive, utilizado en la detección de usuarios; y el mensaje Ack,
usado para notificar la recepción de mensajes SafeUnicast. Cada clase de extensión se encarga de definir
los procedimientos para leer y escribir sus propios paquetes de bytes, dependiendo de la información
que necesitan propagar. Los metatipos usan polimorfismo para invocar esos procedimientos, al
momento de empaquetar un Mensaje de Red para el envío.
65
La figura 45 muestra el diagrama del proceso de comunicación. La clase Communication ofrece la
funcionalidad requerida para conectar o desconectar a un dispositivo de la MANET y también para enviar
cualquier tipo de mensaje.
Figura 45: Diagrama de clases de comunicación
Los usuarios son administrados usando la clase NetUser. Estos objetos poseen propiedades que
identifican a los usuarios mediante un número único, nombre y dirección IP. También mantiene
información acerca de la calidad de señal, estado del tráfico, vecindad y distancia en términos de saltos
de nodos. Habilita además, espacio para otros datos, que pueden ser requeridos por las capas superiores
de colaboración, tales como: grupo al que pertenece el usuario, posición relativa a un sistema de
coordenadas, permisos de sistema o de red, entre otros.
La información del usuario local es mantenida en un objeto de tipo Configuration, junto a los parámetros
que determinan el funcionamiento de la red. El resto de los usuarios son almacenados en un objeto de
tipo NetUserList, que es administrado internamente por la clase Communication.
Eventos de la MANET son comunicados a las aplicaciones colaborativas, para que puedan implementar
mecanismos de percepción: notificaciones acerca del comportamiento interno del sistema, información
o errores en los procedimientos, cambios en el estado de conexión del dispositivo, eventos relacionados
con los usuarios en la MANET, conexiones de nuevos participantes, cambios de estado, mensajes que
han sido recibidos y aceptados, entre otros.
5.8.2 Módulos Adicionales
Esta parte de la API ofrece como complemento opcional, interfaces gráficas de usuarios (GUI: Graphical
User Interface) y una organización estructural para la implementación de subprotocolos (protocolos
específicos para funcionalidades de groupware). Usualmente, estos mecanismos requieren servicios más
66
complejos, tales como mensajería de texto, casillas de correo, transmisión de archivos, mecanismos de
sincronización, entre otros.
La estructura de Módulos Adicionales se compone de dos elementos: Subprotocolos e Interfaz.
5.8.2.1 Subprotocolos
La figura 45 muestra la interfaz SubProtocolI. Una nueva clase de este tipo se debe implementar para
crear un nuevo subprotocolo, escribiendo los métodos en él definidos y procesando los mensajes que le
son asignados. Esta instancia es agregada a una lista de tipo SubProtocolList, que es manejada
internamente por la clase Communication. Cuando un mensaje relacionado a un subprotocolo, es
identificado, la clase Communication lo reasigna al procedimiento correspondiente. HLMP API presenta
además, algunos subprotocolos básicos, tales como: entrega de mensajes de texto para comunicación
privada y grupal, test de velocidad de mensajes, transmisión de archivos, entre otros.
5.8.2.2 Interfaz
GUI genéricas han sido también creadas, para ser utilizadas en funcionalidades de comunicación móvil.
La figura 46 muestra algunos ejemplos: en (a) se aprecia una lista que hace uso de la clase
Communication para manejar la percepción visual de los usuarios; en (b) se despliega un grafo de la
MANET, donde es posible apreciar los enlaces TCP actuales entre los dispositivos móviles; y en (c) se
presenta una interfaz simple correspondiente al subprotocolo de transmisión de archivos, que informa
los recursos descargados o transmitidos y el estado actual de cada uno de ellos.
Figura 46: Interfaces gráficas de usuario en HLMP API
Capítulo VI:
El desarrollo de sistemas de trabajo colaborativo debe ser consciente del potencial efecto de la tecnología
en las personas, su trabajo e interacciones. Un pequeño cambio dentro de esta dimensión puede hacer la
diferencia entre un sistema que es aceptado y
Temas relacionados con amigabilidad, flexibilidad y control tecnológico deben ser considerados durante
los procesos de diseño e implementación. Mucho se puede aprender de una observación en curso y
estudios empíricos de sistemas colaborativos
6.1 Pruebas de Comunicación
Con el objetivo de validar el protocolo de comunicación presentado en este trabajo, se ha llevado
un procedimiento experimental. Estas pruebas abordaron tres escenarios distintos, tanto estacionales
como móviles. En cada una de ellas, la implementación del protocolo HLMP ha sido comparada con una
implementación del protocolo OLSR [12]
mecanismos de routing en MANET actualmente conocidos.
6.1.1 Prueba del Tráfico de Control
En este escenario, dispositivos móviles fueron integrados secuencialmente a una red, a un salto de
distancia. Inicialmente fueron colocados dos nodos para conformar una MANET, luego un tercer nodo
fue agregado, luego un cuarto, y así sucesivamente hasta completar siete nodos (figura 47). En cada paso
se efectuó una medición del tráfico que mantiene el control de cada protocolo (HLMP y OLSR).
Figura 47: Distribución de
La figura 48 compara el tamaño de los mensajes que se deben enviar para mantener la estructura base
de la red. HLMP y OLSR muestran paquetes de tamaño similar. No obstante, el crecimiento
datagramas de HLMP, según el número de vecinos, posee una definición más lineal y con menos
incrementos que la que muestra OLSR.
Por otra parte, la figura 49 muestra el tráfico generado por dichos mensajes, para mantener la red en
funcionamiento. HLMP tiene un incremento de carácter exponencial, según el número de participantes
de la MANET, a diferencia de OLSR que muestra un incremento mucho menor. Sin embargo, la mayor
parte de estos datos son descartados en las capas de alto nivel de HLMP, al momento de
mecanismos de detección de mensajes duplicados y control de carga.
67
Capítulo VI: Evaluación
El desarrollo de sistemas de trabajo colaborativo debe ser consciente del potencial efecto de la tecnología
en las personas, su trabajo e interacciones. Un pequeño cambio dentro de esta dimensión puede hacer la
diferencia entre un sistema que es aceptado y usado en una organización, versus uno que es rechazado.
Temas relacionados con amigabilidad, flexibilidad y control tecnológico deben ser considerados durante
los procesos de diseño e implementación. Mucho se puede aprender de una observación en curso y
studios empíricos de sistemas colaborativos [19].
Pruebas de Comunicación
Con el objetivo de validar el protocolo de comunicación presentado en este trabajo, se ha llevado
un procedimiento experimental. Estas pruebas abordaron tres escenarios distintos, tanto estacionales
cada una de ellas, la implementación del protocolo HLMP ha sido comparada con una
[12]. Este último representa uno de los mejores protocolos para
MANET actualmente conocidos.
En este escenario, dispositivos móviles fueron integrados secuencialmente a una red, a un salto de
distancia. Inicialmente fueron colocados dos nodos para conformar una MANET, luego un tercer nodo
fue agregado, luego un cuarto, y así sucesivamente hasta completar siete nodos (figura 47). En cada paso
se efectuó una medición del tráfico que mantiene el control de cada protocolo (HLMP y OLSR).
: Distribución de nodos en el caso de prueba de tráfico de control
La figura 48 compara el tamaño de los mensajes que se deben enviar para mantener la estructura base
de la red. HLMP y OLSR muestran paquetes de tamaño similar. No obstante, el crecimiento
datagramas de HLMP, según el número de vecinos, posee una definición más lineal y con menos
Por otra parte, la figura 49 muestra el tráfico generado por dichos mensajes, para mantener la red en
e un incremento de carácter exponencial, según el número de participantes
de la MANET, a diferencia de OLSR que muestra un incremento mucho menor. Sin embargo, la mayor
parte de estos datos son descartados en las capas de alto nivel de HLMP, al momento de ejecutar los
mecanismos de detección de mensajes duplicados y control de carga.
El desarrollo de sistemas de trabajo colaborativo debe ser consciente del potencial efecto de la tecnología
en las personas, su trabajo e interacciones. Un pequeño cambio dentro de esta dimensión puede hacer la
usado en una organización, versus uno que es rechazado.
Temas relacionados con amigabilidad, flexibilidad y control tecnológico deben ser considerados durante
los procesos de diseño e implementación. Mucho se puede aprender de una observación en curso y
Con el objetivo de validar el protocolo de comunicación presentado en este trabajo, se ha llevado a cabo
un procedimiento experimental. Estas pruebas abordaron tres escenarios distintos, tanto estacionales
cada una de ellas, la implementación del protocolo HLMP ha sido comparada con una
. Este último representa uno de los mejores protocolos para
En este escenario, dispositivos móviles fueron integrados secuencialmente a una red, a un salto de
distancia. Inicialmente fueron colocados dos nodos para conformar una MANET, luego un tercer nodo
fue agregado, luego un cuarto, y así sucesivamente hasta completar siete nodos (figura 47). En cada paso
La figura 48 compara el tamaño de los mensajes que se deben enviar para mantener la estructura base
de la red. HLMP y OLSR muestran paquetes de tamaño similar. No obstante, el crecimiento de los
datagramas de HLMP, según el número de vecinos, posee una definición más lineal y con menos
Por otra parte, la figura 49 muestra el tráfico generado por dichos mensajes, para mantener la red en
e un incremento de carácter exponencial, según el número de participantes
de la MANET, a diferencia de OLSR que muestra un incremento mucho menor. Sin embargo, la mayor
ejecutar los
68
Figura 48: Gráfico de tamaños de mensajes de control
Figura 49: Gráfico de tráfico de control
6.1.2 Prueba del Tráfico de Transporte
El segundo escenario de prueba, considera la transmisión de un archivo entre dos dispositivos, llamados
Tx y Rx. Inicialmente, la transferencia fue efectuada mediante un salto directo y luego fueron añadidos
nodos intermedios de manera incremental, tal como se muestra en la figura 50. Dos tipos de archivos
han sido usados en este experimento: uno de 993 KB y uno de 2,7 MB.
La figura 51 muestra el tráfico de transporte utilizado en la transferencia, a un salto directo entre dos
nodos, para ambos archivos. Nodos intermedios adicionales no afectaron considerablemente los datos
de transporte en ninguno de los dos protocolos. Se puede apreciar, que el tráfico requerido es
independiente del tamaño de cada archivo y similares entre protocolos, si se comparan
implementaciones en la misma plataforma (Windows). Sin embargo, se aprecia levemente más alto para
OLSR sobre plataforma Linux, puesto que OLSR es un protocolo de bajo nivel y la capa de transporte
depende del sistema operativo. En HLMP, el control de transporte se realiza en capas de alto nivel, de
manera independiente.
0
50
100
150
200
250
2 nodos 3 nodos 4 nodos 5 nodos 6 nodos 7 nodos
pa
cke
t si
ze (
by
tes)
HLMP
OLSRd
0
5
10
15
20
25
30
2 nodos 3 nodos 4 nodos 5 nodos 6 nodos 7 nodos
# p
ack
ets
HLMP
OLSRd
Figura 50: Distribución de nodos en el caso de prueba de tráfico de transporte
Figura 51: Gráfico de tráfico de
6.1.3 Prueba de Movilidad
Este último escenario observa la capacidad de los protocolos para reaccionar a cambios en la red,
producidos por la movilidad de los usuarios. Para ello, se ejecutó una transferencia de archivo entre dos
dispositivos (Tx y Rx), situados en habitaciones dis
otro, tal como se muestra en la figura 52.
Figura 52
0
1
2
3
4
5
6
7
8
9
HLMP Windows
% b
yte
s
69
: Distribución de nodos en el caso de prueba de tráfico de transporte
: Gráfico de tráfico de control para transporte de archivos
Este último escenario observa la capacidad de los protocolos para reaccionar a cambios en la red,
producidos por la movilidad de los usuarios. Para ello, se ejecutó una transferencia de archivo entre dos
dispositivos (Tx y Rx), situados en habitaciones distintas dentro de un mismo edificio, aislados uno del
otro, tal como se muestra en la figura 52.
52: Escenario de prueba de movilidad
OLSRd Windows OLSRd Linux
993 KB
2.7 MB
Este último escenario observa la capacidad de los protocolos para reaccionar a cambios en la red,
producidos por la movilidad de los usuarios. Para ello, se ejecutó una transferencia de archivo entre dos
tintas dentro de un mismo edificio, aislados uno del
Para lograr conectividad entre los nodos transmisores, se procedió a conmutar cinco
Los dispositivos fueron trasladados alternadamente, desde una habitación central, hacia el pasillo que
une las habitaciones de Tx y Rx. De esta manera, se fueron creando rutas activas entre los extremos,
cada 30 segundos (figura 53). En esta prueba se midió el comportamiento de la transmisión de datos y el
impacto de los cambios en la topología de la red.
Figura 53: Distribución de nodos en el caso de prueba de movilidad
El evento observado contiene pausas de
pérdidas y generación de conexiones. La figura 54 presenta una muestra promedio de pausa, en la rutina
ejecutada por OLSR, cuando el sistema se encuentra recalculando las rutas a seguir para la
del archivo. Por otra parte, la figura 55 despliega la misma ventana de tiempo, para el caso de HLMP. En
todas las secuencias similares, OLSR tiene mayores tiempos de inactividad (13
(menores a 10 segundos).
Figura 54: Tiempo de reacción a movilidad en OLSR
Figura 55: Tiempo de reacción a movilidad de HLMP
70
Para lograr conectividad entre los nodos transmisores, se procedió a conmutar cinco usuarios móviles.
Los dispositivos fueron trasladados alternadamente, desde una habitación central, hacia el pasillo que
une las habitaciones de Tx y Rx. De esta manera, se fueron creando rutas activas entre los extremos,
sta prueba se midió el comportamiento de la transmisión de datos y el
impacto de los cambios en la topología de la red.
: Distribución de nodos en el caso de prueba de movilidad
El evento observado contiene pausas de tiempo, que ocurren en cada protocolo, para reaccionar a las
pérdidas y generación de conexiones. La figura 54 presenta una muestra promedio de pausa, en la rutina
ejecutada por OLSR, cuando el sistema se encuentra recalculando las rutas a seguir para la transmisión
del archivo. Por otra parte, la figura 55 despliega la misma ventana de tiempo, para el caso de HLMP. En
todas las secuencias similares, OLSR tiene mayores tiempos de inactividad (13-15 segundos) que HLMP
: Tiempo de reacción a movilidad en OLSR
: Tiempo de reacción a movilidad de HLMP
usuarios móviles.
Los dispositivos fueron trasladados alternadamente, desde una habitación central, hacia el pasillo que
une las habitaciones de Tx y Rx. De esta manera, se fueron creando rutas activas entre los extremos,
sta prueba se midió el comportamiento de la transmisión de datos y el
tiempo, que ocurren en cada protocolo, para reaccionar a las
pérdidas y generación de conexiones. La figura 54 presenta una muestra promedio de pausa, en la rutina
transmisión
del archivo. Por otra parte, la figura 55 despliega la misma ventana de tiempo, para el caso de HLMP. En
15 segundos) que HLMP
71
6.2 Escenarios de Uso
La herramienta de trabajo colaborativo para la ITO desarrollada en el marco de la presente investigación,
ha sido también evaluada mediante pruebas de usabilidad. Estos experimentos consistieron en casos
prácticos dentro de un proyecto real de construcción, así como también, en la validación de sus
funcionalidades, utilidad y apoyo al trabajo colaborativo de los profesionales. Como resultado de este
estudio, se han identificado algunos escenarios, que ejemplifican los beneficios obtenidos.
6.2.1 Inspección Rutinaria
Inspectores Terreno e Inspector Jefe revisan distintas etapas de la obra, que han sido intervenidas
recientemente por la empresa constructora (figura 56). El Inspector Jefe hace uso del Tablet PC para
visualizar la ubicación de sus ayudantes, dentro del plano digital que utiliza para anotar sus
observaciones. A medida que la supervisión avanza, el Inspector Jefe logra coordinar las tareas y enviar a
parte de su equipo hacia los lugares que aún no han sido inspeccionados. Finalmente se ejecuta una
sincronización de la información recopilada, en la oficina de la ITO, creando además las tareas
necesarias, que resuelven los problemas encontrados por los inspectores.
Figura 56: Inspectores revisando distintas partes de una obra
En este escenario, la información respecto de la ubicación de los inspectores, es generada y comunicada
a todos los participantes, basándose en los puntos asignados para anotar las observaciones sobre el
plano digital. Sin esta información, los trabajadores podrían perder coordinación, al no poseer un
elemento de gestión que les permita asignar las áreas de inspección. Además, el Inspector Jefe puede
enviar mensajes, que indiquen los lugares que deben supervisar sus ayudantes, usando la misma
aplicación.
Una vez finalizada la inspección de la obra, es posible convocar a una reunión en la oficina de la ITO, para
proceder a recopilar las anotaciones que ha realizado el grupo. La sincronización de los archivos es
efectuada de manera automática y actualizada en los dispositivos de todos los trabajadores.
72
A partir de esto, es posible generar, entre otras funcionalidades, una versión corregida de la carta Gantt
(reprogramación), ingresando las tareas relacionadas, que resolverán conflictos o deficiencias
detectadas.
6.2.2 Solicitud de Instrucción
Un Inspector Terreno es asignado para revisar los materiales que se han utilizado en la construcción de
una parte de la obra. Durante esta tarea, al trabajador le surge una duda con respecto a las
especificaciones técnicas de esa partida. El inspector hace uso de su PDA para enviar un mensaje privado
al Inspector Jefe, junto a una fotografía del material. Usando el sistema de conversación, los inspectores
acuerdan juntarse para discutir el conflicto y tomar una decisión que pueda resolver el problema (figura
57).
Figura 57: Solicitud de instrucción y reunión cara a cara
En esta situación, la herramienta provee medios para que un integrante del grupo de trabajo envíe
alarmas o mensajes que solucionen un eventual conflicto o duda del proyecto. Esta acción puede estar
influenciada por la posición de los usuarios y los diferentes elementos de percepción visual. Más aún, es
posible adjuntar archivos relacionados con información relevante, tales como documentos de planos
digitales o fotografías.
Esta funcionalidad facilita la coordinación de conversaciones, que pueden tener mayor prioridad y que
necesitan ser resueltas en reuniones presenciales.
6.2.3 Consulta a Proyectista
Una duda en el proyecto, surgida en una ronda de supervisión es discutida y analizada por los
inspectores. Sin embargo, no se logra determinar una solución que satisfaga los requerimientos técnicos
de la obra. Ante esta eventualidad, el inspector se dirige a la oficina, para preparar un archivo digital del
plano, en donde se explique la duda mediante una anotación. Este documento es enviado luego al
Proyectista, a través de correo electrónico. Cuando la respuesta es recibida, se actualizan los planos
digitales, y el inspector se reúne luego con Jefe de Obra, para explicarle los nuevos cambios del proyecto
(figura 58).
73
Figura 58: Consulta a Proyectista, e instrucción a Jefe de Obra
Este escenario ilustra cómo el MSW puede ser utilizado para facilitar las consultas remotas, con agentes
externos que no se encuentran en el terreno de construcción. Un archivo que ilustre eventuales dudas o
conflictos, con anotaciones dentro del plano o información fotográfica, puede ser obtenido para ser
enviado a través de Internet.
Si se resuelve hacer modificaciones en los planos, éstos pueden ser fácilmente actualizados dentro del
MSW de cada trabajador.
6.3 Tiempos de Trabajo
En esta etapa, se efectuaron mediciones de tiempos para comprobar la ventaja que se logra al hacer uso
del MSW. Estos beneficios se compararon con la modalidad convencional de realizar las labores de
inspección en terreno, mediante el empleo de copias impresas de los planos de un proyecto. Para lograr
esta demostración, se contó con la colaboración de cinco voluntarios, docentes y alumnos,
pertenecientes al Departamento de Ciencias de la Computación de la Facultad de Ciencias Físicas y
Matemáticas de la Universidad de Chile.
6.3.1 Inspección en Terreno
En primer lugar, se les capacitó e instruyó, de manera grupal, la mecánica necesaria para realizar una
inspección de rutina, primero utilizando planos impresos, y luego la herramienta colaborativa de
información digital.
Posteriormente se indicaron cinco puntos de conflicto, en distintos sectores del edificio, cada uno de los
cuales fue identificado con una marca que contenía la descripción del supuesto problema que
presentaba el lugar.
Como parte del procedimiento, los participantes, que cumplieron el rol de eventuales “inspectores de
obras”, fueron ubicados en un mismo punto de partida desde el cual iniciaron el recorrido previsto. Esto
permitió simular un proceso real de inspección, avanzando hacia las zonas demarcadas con los
problemas a resolver.
Una vez situados, cada voluntario analizó y buscó el área correspondiente en el plano, con el objetivo de
escribir las observaciones definidas en las marcas ya referidas.
74
Durante este proceso, se midió el tiempo empleado por los participantes para completar el proceso de
inspección. Cada medición se efectuó sobre tres conceptos distintos, a saber:
• Desplazamiento: se midió el tiempo utilizado por cada participante para desplazarse desde el
punto de origen hasta el punto de conflicto.
• Ubicación: una vez posicionado en el punto de conflicto, se midió el tiempo requerido para
ubicar el plano donde se debía realizar la anotación.
• Anotación: finalmente, se midió el tiempo requerido para encontrar el punto en el plano y
escribir la observación.
La figura 59 muestra un gráfico con las medianas de los porcentajes de diferencia, de los tiempos
utilizados para realizar los procesos de desplazamiento, ubicación y anotación. Esta diferencia se obtiene
al comparar el tiempo transcurrido en el ejercicio, para ambas metodologías (con y sin MSW), en los
cinco puntos de conflicto.
El desplazamiento de los usuarios se vio sutilmente favorecido en un principio, con una mediana de
9,51% de ahorro de tiempo al hacer uso de la Tablet PC. Sin embargo a medida que se caminaban
mayores distancias, este beneficio tendió a disminuir a valores incluso negativos, pero cercanos a cero, al
dificultarse levemente el movimiento de los inspectores debido al peso de los equipos.
Con respecto a la ubicación del plano correspondiente, se observó que, al hacer uso del MSW, los
inspectores ahorraron entre un 15% y un 40% del tiempo que se requiere para encontrar un plano
impreso dentro de un conjunto de copias diversas.
Por otra parte, el proceso de anotación de las observaciones, correspondientes a los puntos de conflicto,
se ejecutó entre un 9% y un 24% más rápido en el espacio de trabajo digital, que sobre los planos
impresos.
Como resultado general se obtuvo además que, en promedio, el tiempo requerido por los inspectores
para desplazarse disminuyó en 3,76%. Por otra parte, el tiempo utilizado para ubicar los planos en donde
realizar anotaciones, bajó en promedio un 28,92%, y por último, el proceso de anotación se realizó un
13,76% más rápido.
Figura 59: Gráfico de medianas del porcentaje de ahorro de tiempo en las actividades de inspección, al hacer uso del MSW
-5.00%
0.00%
5.00%
10.00%
15.00%
20.00%
25.00%
30.00%
35.00%
40.00%
45.00%
Punto 1 Punto 2 Punto 3 Punto 4 Punto 5
Me
dia
na
de
l Po
rce
nta
je d
e A
ho
rro
de
Tie
mp
o
Movimiento
Ubicación
Anotacion
75
6.3.2 Sincronización de la Información
Una vez finalizadas las inspecciones, y obtenidos los resultados, se procedió a realizar una sincronización
de la información de cada participante, efectuando dos medidas:
• Ajuste: tiempo necesario para acomodar los planos o configurar las Tablet PC en un lugar que
permitiese realizar este proceso.
• Sincronización por Inspector: tiempo requerido para que los datos de inspección de cada
participante, escritos sobre los planos impresos, fuesen copiados a un plano general. Así también
se midió el tiempo para que las anotaciones hechas en el MSW fueran sincronizadas de manera
automática haciendo uso de la misma aplicación.
La figura 60 muestra el promedio de segundos transcurridos, al realizar los ajustes y las sincronizaciones
de los datos de cada inspector. La última columna muestra el porcentaje correspondiente a la diferencia
de cada metodología. Se puede apreciar que se ahorraron tiempos de trabajo de hasta un 78% por cada
inspector.
Figura 60: Tabla de promedio de segundos utilizados en los procesos de sincronización
76
Capítulo VII: Observaciones Finales
Aunque las perspectivas y las posibilidades de aplicación de sistemas de trabajo colaborativo parecen
prometedoras, se debe tener en cuenta una larga historia de fallas repetitivas y costosas [25]. El uso de
un MSW en actividades nómadas, incrementa la productividad y la calidad de los resultados. Sin
embargo, es un área nueva de investigación que se debe abordar mediante aportes interdisciplinarios,
pues es muy difícil separar aspectos técnicos de asuntos sociales [19]. Para lograr el éxito, los
desarrolladores deben ser conscientes del comportamiento de los usuarios, y de cómo éstos interactúan
con su medio ambiente social y su contexto de trabajo.
7.1 Conclusiones
El presente trabajo de investigación ha detallado una propuesta de diseño genérica que representa la
esencia de un MSW. Dicha estructura fue obtenida luego de analizar y generalizar los distintos
procedimientos y matices que se encuentran detrás de otras herramientas, previamente desarrolladas y
probadas. A partir de este resultado es factible crear y aplicar nuevos sistemas en diversas actividades
grupales colaborativas. Esta práctica reduce el riesgo y la complejidad en la ingeniería de sistemas,
produce un impacto positivo en la calidad del producto final y reduce tiempos y costos invertidos en el
proceso de diseño.
Actualmente, los espacios de trabajo colaborativo no son usualmente usados en la industria de la
construcción. Sin embargo, pueden jugar un rol importante e incrementar la comunicación y la
cooperación entre los trabajadores. Al hacer uso de este concepto, una organización puede trabajar de
forma más eficiente, reducir los costos de coordinación y mantener una visión actualizada y limpia de
cada proyecto.
En particular, se ha estudiado un MSW que da soporte al servicio de inspección técnica de obras. Este
sistema permite que los trabajadores puedan realizar anotaciones sobre planos digitales, de la misma
manera en que lo hacían sobre planos en copias de papel. No obstante, este mecanismo introduce
múltiples beneficios al enriquecer el trabajo con nuevas funcionalidades tales como: creación de tareas
asociadas, asignación de recursos, sincronización automática de la información de los proyectos,
organización de los diferentes roles que participan en el proceso, coordinación de los equipos de trabajo,
colaboración en demanda, intercambio de documentos, planificación de las inspecciones, percepción
acerca de los demás participantes, entorno social, entre varias otras.
La herramienta fue evaluada por el personal de una empresa que presta formalmente los servicios de
ITO, en un proyecto real de construcción. Los trabajadores encontraron que esta aplicación era útil, fácil
de usar y adecuada al contexto laboral. Más aún, se destacaron sus ventajas en cuanto a la organización
del tiempo y la reducción de costos en el proceso.
En definitiva, el uso de este sistema representa una gran contribución para la industria de la
construcción, y no sólo demuestra empíricamente la hipótesis planteada, sino que abre de paso, una
nueva área de estudio que se agrega al dominio de escenarios, en donde estas herramientas aportan un
mayor valor.
77
En el ámbito de las comunicaciones, variados protocolos han sido propuestos en los últimos años para
resolver el problema de routing en redes MANET. Ninguna de estas especificaciones ha sido diseñada
para dar soporte al trabajo colaborativo móvil, pues no proveen los servicios que son habitualmente
requeridos en aplicaciones que facilitan este tipo de actividades.
Durante el transcurso de esta investigación, se ha creado y definido un nuevo protocolo, que ofrece una
base de comunicación significativa para el desarrollo de aplicaciones móviles, sin depender de una
instalación fija para la transmisión de datos. HLMP permite manejar la conectividad de los usuarios
dentro de una MANET, empleando mecanismos automáticos. Este sistema establece además,
metodologías para gatillar notificaciones que permiten implementar mecanismos de percepción,
conciencia de la topología de la red y medición de la calidad de conexión, entre otros. Todos estos
conceptos pueden ser utilizados por cualquier tipo de aplicación colaborativa que lo requiera.
Diversos procedimientos de entrega de mensajes y generación de eventos son soportados por la API de
HLMP. Esta infraestructura de trabajo colaborativo, disuade que desarrolladores de groupware tengan
que resolver detalles de bajo nivel, al implementar un nuevo sistema. La reutilización de los servicios y
operaciones otorgadas, les permite concentrarse en aspectos de diseño de actividades grupales, sin
dejar de lado elementos de flexibilidad y extensibilidad. Por otra parte, la lógica de alto nivel de HLMP,
permite portar sus funcionalidades a diferentes tipos de dispositivos y sistemas operativos, de manera
simple y eficaz.
Los experimentos y pruebas efectuadas han indicado que la implementación de HLMP es robusta, y que
su calidad y ejecución es comparable con los resultados obtenidos por el protocolo OLSR. Si
consideramos que OLSR es uno de los mejores sistemas para MANET actualmente conocidos, es claro
que el uso de HLMP otorga los beneficios demostrados.
7.2 Trabajo Futuro
Actualmente, nuevos MSW se encuentran en progreso de desarrollo. Uno de ellos es un sistema de
trabajo colaborativo para estudiantes de ingeniería. Esta herramienta facilitará a los estudiantes la
ejecución de variadas actividades, tales como la escritura de apuntes sobre material de presentación en
clases, intercambio y sincronización de anotaciones entre estudiantes y profesores, entre otras. Los
autores de este proyecto están usando la estructura abstracta propuesta en este trabajo, para el diseño
de ese sistema. Los futuros resultados de dicha aplicación, permitirán obtener evidencia adicional, de su
utilidad en el proceso de diseño. Los próximos pasos en este campo, incluyen una definición formal de
dominio específico, para una arquitectura de MSW. Esto incrementará la aplicabilidad de esta propuesta.
Por otra parte, otras aplicaciones y funciones que hacen uso de la API de HLMP se encuentran también
en desarrollo, algunas de éstas son: proyección visual de dispositivos móviles en monitores
estacionarios; mecanismos de telefonía de voz en redes MANET; transmisión segura de archivos usando
elementos de encriptación distribuida; redes sociales informales dentro de ambientes laborales; difusión
de posición y actividades en redes con información de localización geo-referenciada; sistemas
educaciones que comparten recursos y conocimientos dentro del aula; entre otras.
Los siguientes pasos en la evolución de HLMP deberán considerar la definición e implementación de
otros mecanismos reusables de coordinación, con el objetivo de ofrecer un mayor conjunto de servicios
para desarrolladores de groupware. Otros planes considerarán incluir módulos de percepción
78
automática del contexto de trabajo, para que los parámetros de ejecución se puedan adaptar a distintas
topologías de la red, con el objetivo incrementar la performance y disminuir el tráfico de control
excesivo.
79
Bibliografía
[1] Ahumada, R., Chacón, R.: "Chile celebrará bicentenario con más de 200 obras". Diario La Nación, pág. 2-3, 3 de Septiembre de 2009.
[2] André, P., Antunes, P.: "SaGISC: A Geo-Collaborative System". Proceedings of CRIWG 2004, Lecture Notes in Computer Science, vol. 3198, pág. 175-191, 2004.
[3] Andriessen, J.H.E., Vartiainen, M.: "Mobile Virtual Work: A New Paradigm?". Springer, 2006.
[4] Bernados, C., Calderon, M., H.Moustafa: "Survey of IP addres autoconfiguration mechanisms for
MANETs". IETF, 2 de Noviembre de 2008.
[5] Bravo, G.: "Desarrollo de un Workspace Colaborativo Móvil para Apoyar a los Inspectores de Obra en
Escenarios de Construcción". Departamento de Ciencias de la Computación, Universidad de Chile, 2008.
[6] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M.: "Pattern-Oriented Software
Architecture: A System of Patterns". John Wiley & Sons, 1995.
[7] Buszko, D., Lee, W.-H., Helal, A.: "Decentralized Ad-Hoc Groupware API and Framework for Mobile
Collaboration". Proceedings of the 2001 International ACM SIGGROUP Conference on Supporting Group Work, vol. Session 1, pág. 5-14, 2001.
[8] Cámara Chilena de la Construcción: "Estadísticas". En Concreto, Revista de la Cámara Chilena de la Construcción, vol. 71, pág. 80-90.
[9] Cámara Chilena de la Construcción: "Estadísticas". En Concreto, Revista de la Cámara Chilena de la Construcción, vol. 82, pág. 74-81.
[10] Cámara Chilena de la Construcción: "Informe MACh Número 22, Macroeconomía y Construcción", Abril de 2008.
[11] Cámara Chilena de la Construcción: "Informe MACh Número 23, Macroeconomía y Construcción", Agosto de 2008.
[12] Clausen, T., Jacquet, P.: "Optimized Link State Routing Protocol (OLSR)". IETF, vol. RFC 3626, Octubre de 2003.
[13] Corson, S., Macker, J.: "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues
and Evaluation Considerations". IETF, vol. RFC 2501, Enero de 1999.
[14] Chakeres, I., Perkins, C.: "Dynamic MANET On-demand (DYMO) Routing". IETF Internet-Draft, Work in Progress, 8 de Marzo de 2009.
[15] Chateigner, L., Chabridon, S., Sabri, N., Bernard, G.: "Service de reconciliation pour la synchronization
de copies". ACM International Conference Proceeding Series, vol. 64, pág. 107-114, 2004.
80
[16] Duchamp, D., Reynolds, N.: "Measured Performance of a Wireless LAN". Proceedings of the 17th IEEE Conference on Local Computer Networks, pág. 494-499, Septiembre de 1992.
[17] Eckert, C., Maier, A., McMahon, C.: "Communication in Design". Design process improvement, a review of current practice, Springer, 2005.
[18] Eckhardt, D., Steenkiste, P.: "Measurement and analysis of the error characteristics of an in-building
wireless network". Conference proceedings on Applications, technologies, architectures, and protocols for computer communications, pág. 243-254, 1996.
[19] Ellis, C., Gibbs, S., Rein, G.: "Groupware: Some Issues and Experiences". Communications of the ACM, vol. 34, núm. 1, pág. 38–58, 1991.
[20] Favela, J., Tentori, M., Castro, L., González, V., Moran, E., Martinez-Garcia, A.: "Activity recognition
for context-aware hospital applications: issues and opportunities for the deployment of pervasive
networks". Mobile Network and Applications, vol. 12, pág. 155-171, 2007.
[21] French, J.: "Beyond the tablet PC: using the tablet PC in a collaborative learning environment". Journal of Computing Sciences in Colleges, vol. 23, núm. 2, pág. 84-89, Diciembre de 2007.
[22] Garcia, P., Gracia, R., Espelt, M., Paris, G., Arrufat, M., Messeguer, R.: "Topology-aware group
communication middleware for MANETs". Proceedings of the Fourth International ICST Conference on COMmunication System softWAre and middlewaRE, núm. 7, Junio de 2009.
[23] Ge, M., Krishnamurthy, S., Faloutsos, M.: "Application versus network layer multicasting in ad hoc
networks: the ALMA routing protocol". Elsevier Ad Hoc Networks Journal, vol. 4, núm. 2, pág. 283-300, 2006.
[24] Gelernter, D.: "Generative Communication in Linda". ACM Transactions on Programming Languages and Systems, vol. 7, núm. 1, pág. 80-112, Enero de 1985.
[25] Grudin, J.: "Why CSCW applications fail: problems in the design and evaluationof organizational
interfaces". Proceedings of the 1988 ACM conference on Computer-supported cooperative work, pág. 85-93, September 26 - 28, 1988.
[26] Guerrero, L., Pino, J., Collazos, C., Inostroza, A., Ochoa, S.: "Mobile Support for Collaborative Work". Proceedings of CRIWG’04, Lecture Notes in Computer Science, vol. 3198, pág. 363-375, Septiembre de 2004.
[27] Gui, C., Mohapatra, P.: "Efficient overlay multicast for mobile ad hoc networks". The Wireless Communications and Networking Conference (WCNC), Marzo de 2003.
[28] Gutwin, C., Greenberg, S.: "The effects of workspace awareness support on the usability of real-time
distributed groupware". ACM Transactions on Computer-Human Interaction (TOCHI), vol. 6, núm. 3, pág. 243-281, Septiembre de 1999.
[29] Gutwin, C., Roseman, M., Greenberg, S.: "A usability study of awareness widgets in a shared
workspace groupware system". Proceedings of the 1996 ACM conference on Computer supported cooperative work, pág. 258-267, 1996.
[30] Hauswirth, M., Podnar, I., Decker, S.: "On P2P Collaboration Infrastructures". WETICE’05, IEEE CS Press, pág. 66-71, Junio de 2005.
81
[31] Heinemann, A., Kangasharju, J., Lyardet, F., Mühlhäuser, M.: "iClouds: Peer to-Peer Information
Sharing in Mobile Environments". Lecture Notes in Computer Science, vol. 2790, pág. 1038-1045, 2003.
[32] Herskovic, V., Ochoa, S., Pino, J.: "Modeling groupware for mobile collaborative work". 13th International Conference on Computer Supported Cooperative Work in Design, pág. 384-389, Abril de 2009.
[33] Holland, G., Vaidya, N.: "Analysis of TCP performance over mobile ad hoc networks". Proc. of the 5th ACM/IEEE international conference on Mobile computing and networking, pág. 219-230, 1999.
[34] IEEE Computer Society: "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications". IEEE Standard for Information technology, Telecommunications and information exchange between systems, Local and metropolitan area networks, Specific requirements, vol. IEEE 802.11, núm. 11, 2007.
[35] IEEE Computer Society: "Wireless medium access control (MAC) and physical layer (PHY)
specifications for wireless personal area networks (WPANs)". IEEE Standard for Information technology, Telecommunications and information exchange between systems, Local and metropolitan area networks, Specific requirements, vol. IEEE 802.15, 2005.
[36] Information Sciences Institute, University of Southern California: "Internet Protocol". IETF, vol. RFC 791, Septiembre de 1981.
[37] Information Sciences Institute, University of Southern California: "Transmission Control Protocol". IETF, vol. RFC 793, Septiembre de 1981.
[38] Institute, E.T.S.: "Universal Mobile Telecommunications System (UMTS); Technical Specifications and
Technical Reports for a UTRAN-based 3GPP system". 3GPP, vol. TS 21.101 version 7.5.0 Release 7.
[39] Johnson, D., Hu, Y., Maltz, D.: "The Dynamic Source Routing Protocol (DSR)". IETF, vol. RFC 4728, Febrero de 2007.
[40] JXTA Project. 2008 2008; Available from: http://jxta.dev.java.net.
[41] Marques, J., Navarro, L.: "LaCOLLA: A Middleware to Support Self-sufficient Collaborative Groups". Computing and Informatics, vol. 25, núm. 6, pág. 571-595, 2006.
[42] Menchaca-Mendez, R., Gutierrez-Arias, E., Favela, J.: "Opportunistic Interaction in P2P Ubiquitous
Environments". Proceedings of CRIWG’04, Lecture Notes in Computer Science, vol. 3198, pág. 349-362, 2004.
[43] Monares, Á., Ochoa, S., Pino, J., Herskovic, V., Neyem, A.: "MobileMap: A Collaborative Application
to Support Emergency Situations in Urban Areas". CSCWD 2009, IEEE Press, pág. 565-570, 2009.
[44] Moya, C.: "Módulo para la Sincronización Automática de Documentos XML". Departamento de Ciencias de la Computación, Universidad de Chile, 2008.
[45] Muñoz, M., Rodriguez, M., Favela, J., Martinez-Garcia, A., Gonzalez, V.: "Context-Aware Mobile
Communication in Hospitals". IEEE Computer, vol. 36, núm. 9, pág. 38-46.
[46] Neumann, A., Aichele, C., Lindner, M., Wunderlich, S.: "Better Approach To Mobile Ad-hoc
Networking (B.A.T.M.A.N.)". IETF, Abril de 2007.
82
[47] Neyem, A., Ochoa, S., Pino, J.: "Integrating Service-Oriented Mobile Units to Support Collaboration in
Ad-hoc Scenarios". Journal of Universal Computer Science, vol. 14, núm. 1, pág. 88-122.
[48] Neyem, A., Ochoa, S., Pino, J., Herskovic, V.: "Sharing Information Resources in Mobile Ad-hoc
Networks". CRIWG 2005, Lecture Notes in Computer Science, vol. 3706, pág. 351-358, 2005.
[49] Ni, S.-Y., Tseng, Y.-C., Chen, Y.-S., Sheu, J.-P.: "The Broadcast Storm Problem in a Mobile Ad Hoc
Network". Proceedings of the 5th annual ACM/IEEE international conference on Mobile computing and networking, pág. 151-162, 1999.
[50] Paulk, R.: "Using a Tablet Computer". Journal Light Construction, Septiembre de 2006.
[51] Peña, L.: "Curso Inspección Técnica de Obras". BAU Ltda., 2008.
[52] Perkins, C.: "Mobile Ad Hoc Networking Terminology". IETF, Noviembre de 1998.
[53] Perkins, C., Belding-Royer, E.: "Ad hoc On-Demand Distance Vector (AODV) Routing". IETF, vol. RFC 3561, Julio de 2003.
[54] Perry, M., O'hara, K., Sellen, A., Brown, B., Harper, R.: "Dealing with mobility: understanding access
anytime, anywhere". ACM Transactions on Computer-Human Interaction (TOCHI), vol. 8, núm. 4, pág. 323-347, Diciembre de 2001.
[55] Pinelle, D., Gutwin, C.: "A Groupware Design Framework for Loosely Coupled Workgroups". ECSCW 2005, Proceedings of the Ninth European Conference on Computer-Supported Cooperative Work, pág. 65-82, Septiembre 2005.
[56] Postel, J.: "User Datagram Protocol". ISI, IETF, vol. RFC 768, 28 de Agosto de 1980.
[57] Schaffers, H., Brodt, T., Pallot, M., Prinz, W.: "The Future Workplace - Perspectives on Mobile and
Collaborative Working". The MOSAIC Consortium, 2006.
[58] Su, N.M., Mark, G.: "Designing for nomadic work". Proceedings of the 7th ACM conference on Designing interactive systems, pág. 305-314, 2008.
[59] Tarasewich, P.: "Designing Mobile Commerce Applications". Communications of the ACM, vol. 46, núm. 12, pág. 57-60, Diciembre de 2003.
[60] Tentori, M., Favela, J.: "Collaboration and Coordination in Hospital Work through Activity-Aware
Computing". Int. Journal on Cooperative Information Systems, vol. 17, núm. 4, pág. 413-442, 2008.
[61] United States of America, Department of Commerce: "Construction Services (Chile)", Enero de 2004.
[62] Vaidya, N.H.: "Weak duplicate address detection in mobile ad hoc networks". Proceedings of the 3rd ACM international symposium on Mobile ad hoc networking & computings, pág. 206-216, 2002.
[63] Vera, F.: "Zofri estrenará edificios y prepara parque industrial para Alto Hospicio". Diario El Mercurio, Economía y Negocios, vol. B4, 28 de Septiembre de 2009.
[64] Westech Communications Inc.: "Can WiMAX Address Your Applications?", 24 de Octubre de 2005.
[65] Wimax Forum: "Mobile WiMAX: The Best Personal Broadband Experience!", Junio de 2006.
83
[66] Wongsaardsakul, T., Kanchanasut, K.: "A Structured Mesh Overlay Network for P2P Applications on
Mobile Ad Hoc Networks". Lecture Notes in Computer Science, vol. 4882, pág. 67-72, 2007.
[67] Xylomenos, G., Polyzos, G.: "TCP and UDP Performance over a Wireless LAN". INFOCOM '99, Eighteenth Annual Joint Conference of the IEEE Computer and Communications Societies, Proceedings, IEEE, vol. 2, pág. 439-446, Marzo de 1999.
[68] Zurita, G., Baloian, N.: "Handheld Electronic Meeting Support". Proceedings of CRIWG 2005, Lecture Notes in Computer Science, vol. 3706, pág. 341-350, 2005.
