diseño de una red de sensores para la determinación de...

Plan de Proyecto del Trabajo Final de Carrera

de Especialización de Sistemas Embebidos

Ing. Sergio R De Jesús M

Diseño de una red de sensores para la determinación de variables peatonales

Autor


Director del trabajo

PhD. Pablo Fierens

Jurado propuesto para el trabajo

Daniel Parisi Pablo Cossutta Federico Zacchigna

Este plan de trabajo ha sido realizado en el marco de la asignatura Gestión de Proyectos entre abril y mayo de 2016.

Página 1 de 31




Tabla de contenido

Registros de cambios

Acta de Constitución del Proyecto

Identificación y análisis de los interesados

1. Propósito del proyecto

2. Alcance del proyecto

3. Supuestos del proyecto

4. Requerimientos

5. Entregables principales del proyecto

6. Desglose del trabajo en tareas

7. Diagrama de Activity On Node

8. Diagrama de Gantt

9. Matriz de uso de recursos de materiales

10. Presupuesto detallado del proyecto

11. Matriz de asignación de responsabilidades

12. Gestión de riesgos

13. Gestión de la calidad

14. Comunicación del proyecto

15. Gestión de Compras

16. Seguimiento y control

17. Procesos de cierre

Página 2 de 31




Registros de cambios

Revisión Cambios realizados Fecha 1.0 Creación del documento 30/03/2016

1.1 Incorporación de encabezado y alcances 03/04/2016

1.2 Requerimientos y desglose de tareas 06/04/2016

1.3 Incorporación de Gestión de tiempo, Recursos materiales, Calidad y plan de comunicación.

27/04/2016

1.4 Incorporación de comentarios rev. 1.3 29/04/2016

Página 3 de 31




Acta de Constitución del Proyecto

Buenos Aires, 30 de marzo de 2016

Por medio de la presente se acuerda con el Ing. Sergio De Jesús que su Proyecto Final de la

Carrera de Especialización en Sistemas Embebidos se titulará “Diseño de una red de sensores para la

determinación de variables peatonales”, consistirá esencialmente en el prototipo preliminar de un

sensor WiFi que procese y transmita valores de potencia de cada dispositivo móvil identificado a un

módulo central para el posterior cálculo de la ubicación de dichos dispositivos, y tendrá un presupuesto

preliminar estimado de 600 hs de trabajo, con fecha de inicio miércoles 30 de marzo de 2016 y fecha de

presentación pública miércoles 14 de diciembre de 2016.

Se adjunta a esta acta la planificación inicial.

Ariel Lutenberg Pablo Fierens

Director de la CESEFIUBA Laboratorio de optoelectrónica ITBA

Página 4 de 31




Identificación y análisis de los interesados Rol Nombre y Apellido Entidad Puesto

Auspiciante Accionistas de Urbix Accionistas

Cliente Urbix Technologies,

Jurado

Impulsor Herman Moldovan Urbix Technologies Ingeniero

Responsable Sergio De Jesús UBA Estudiante

Colaboradores Personal de seguridad

del ITBA, Equipo de

miembros de

Emebidos32, Comunidad

del hardware

seleccionado.

Orientadores Pablo Fierens ITBA Profesor

Equipo Sergio De Jesús UBA Estudiante

Usuario Final Centros comerciales

Impulsor: Hace un seguimiento periódico del proyecto, reuniones esporádicas.

Cliente: Requiere información oportuna de las desviaciones de la planificación. Tiene interés en

orientar pero es exigente con los tiempos de entrega.

Colaboradores:

Es posible que se tengan que hacer ensayos de laboratorio en la noche o fines de semana, la

colaboración del personal de seguridad del ITBA es fundamental en el avance.

El grupo Embebidos32 contiene problemas resueltas relacionadas con el área de aplicación del

proyecto.

Los foros de colaboradores del hardware que sea seleccionado contendrá aplicaciones parecidas al

proyecto, por lo que tendrá problemas resueltos cercanos a los que se puedan presentar.

Orientadores: Tiene disponibilidad de lunes a viernes en horario de oficina en instalaciones del ITBA.

Página 5 de 31




1. Propósito del proyecto El propósito de este proyecto es diseñar una red de sensores que obtengan valores de potencia de cada

dispositivo WiFi al alcance y los envíen a una estación central que armará un vector de potencias por

cada dispositivo y lo relacionará con una ubicación geográfica mediante el método del fingerprinting.

2. Alcance del proyecto El proyecto incluirá los siguientes aspectos:

Determinar el Hardware y programar el Firmware de sensores WiFi basados enintensidad de señal recibida.

Plantear un sistema de comunicación inalámbrico que envíe los datos sensados a un nodo principal.

Desarrollar un sistema que determine la posición de dispositivos móviles sensados en cada momento en un ambiente interior utilizando el método de fingerprinting.

El proyecto no incluirá:

Versión comercial de los sensores (se limitará a la generación de un prototipo del sistema).

Interfaz gráfica de usuario para el sistema de localización en interiores.

3. Supuestos del proyecto El Hardware seleccionado existe en la Argentina o tendrá un período de importación menor a 3 semanas.

El Hardware seleccionado tiene una amplia comunidad de desarrollo.

El presupuesto requerido para la compra de materiales para el prototipo estará disponible de forma oportuna.

Página 6 de 31




4. Requerimientos 1. Requerimientos asociados a cada sensor

1.1 Deberá funcionar con estándar WiFi (IEEE 802.11) en la banda de 2,4GHz

1.2 Deberá considerar los paquetes provenientes de móviles y descartar los

provenientes de AP.

1.3 Deberá obtener de cada dispositivo móvil la potencia recibida en cada paquete.

1.4 Tendrá una ventana de muestreo de 1 segundo tras el cual deberá promediar

las potencias por dispositivo.

1.5 Deberá enviar un vector de potencias promedio y hora de detección recibidas de

cada dispositivo móvil a una central por un medio inalámbrico.

2. Requerimientos asociados a la red de sensores y la transmisión inalámbrica

2.1 Deberán estar sincronizados con el módulo central para coordinar la hora de

detección.

2.2 Deberán evitar colisiones en el envío de paquetes con los vectores de potencia

recibida.

2.3 Deberán tener un identificador único para el envío de paquetes al módulo

central.

2.4 Los paquetes enviados deberán tener un formato único.

3. Requerimientos asociados al módulo central

3.1 Deberá recibir los vectores de potencia de la red de sensores y organizarlos en

una matriz única.

3.2 Deberá estimar las posiciones de los dispositivos sensados mediante la técnica

de fingerprinting.

3.3 Deberá emitir un archivo con posiciones estimadas de cada dispositivo móvil

sensado.

3.4 Deberá tener una opción de calibración para determinar vectores patrón de

potencia recibida en base a las características del entorno.

3.5 Deberá ofrecer un servicio de sincronización de hora para la red de sensores.

3.6 Deberá tener acceso a la red inalámbrica para recibir información de los

sensores.

5. Entregables principales del proyecto Manual de uso Prototipo del sistema con 3 a 5 sensores Programa de calibración y estimación de dispositivos WiFi por fingerprinting. Informe final

Página 7 de 31




6. Desglose del trabajo en tareas

1. Investigación preliminar (100 hs)

1.1 Lecturas sobre localización en interiores (32 hs)

1.2 Lecturas sobre técnica de fingerprinting (16 hs)

1.3 Introducción al estándar IEEE802.11 (16 hs)

1.4 Lectura sobre comportamiento estadístico de potencia recibida por WiFi (10 hs)

1.5 Investigación sobre otras redes inalámbricas para comunicación (8 hs)

1.6 Investigación de antecedentes (16 hs)

1.7 Reunión de arranque (2 hs)

2. Determinación de Hardware para sensor (110 hs)

2.1 Desarrollo de lista de especificaciones del sensor (16 hs)

2.2 Determinación de red inalámbrica de comunicaciones con módulo central (16 hs)

2.3 Investigación sobre arquitecturas (32 hs)

2.4 Análisis técnico / económico y de factibilidad de las opciones (34 hs)

2.4 Reunión de determinación del hardware para procura (hito 2hs)

2.5 Procura de hardware (10 hs)

3. Desarrollo de firmware para sensores (150 hs)

3.1 Desarrollo de arquitectura del firmware (16 hs)

3.2 Diseño de firmware (32 hs)

3.3 Análisis de riesgos de firmware (10 hs)

3.4 Desarrollo de pruebas para firmware (32 hs)

3.5 Programación del firmware (40 hs)

3.6 Verificación y validación del firmware (10 hs)

3.7 Generación de manual de sensor (8 hs)

3.8 Reunión de entrega de documentación del sensor (hito 2 hs)

4. Desarrollo de software de localización (150 hs)

4.1 Desarrollo de arquitectura del software (16 hs)

4.2 Diseño de software (32 hs)

4.3 Análisis de riesgos de software (10 hs)

4.4 Desarrollo de pruebas para software (32 hs)

4.5 Programación del software (40 hs)

4.6 Verificación y validación del software (10 hs)

4.7 Generación de manual de software de localización (8 hs)

Página 8 de 31




4.8 Reunión de entrega de documentación del software de localización (hito 2 hs)

5. Cierre del proyecto (96 hs)

5.1 Integración de manuales pertenecientes al sistema de localización (32 hs)

5.2 Preparación de informe final (40 hs)

5.3 Preparación de presentación final (20 hs)

5.4 Presentación final del proyecto y entrega de informe final (hito 2 hs)

5.5 Reunión de cierre del proyecto y entrega de documentación (hito 2 hs)

Total de horas invertidas: 606 hs

7. Diagrama de Activity On Node

Página 9 de 31




8. Diagrama de Gantt

Página 10 de 31




9. Matriz de uso de recursos de materiales

Código WBS Nombre de la tarea

Recursos requeridos

Horas Ingeniero

Horas Computador de trabajo

Horas prototipo de

sensor 1.1 Lecturas sobre localización en

interiores. 32 32

1.2 Lecturas sobre técnica de

fingerprinting.

16 16

1.3 Introducción al estándar

IEEE802.11.

16 16

1.4 Lectura sobre comportamiento

estadístico de potencia recibida por

WiFi.

10 10

1.5 Investigación sobre otras redes

inalámbricas para comunicación.

8 8

1.6 Investigación de antecedentes. 18 18

1.7 Reunión de arranque. 2

2.1 Desarrollo de lista de

especificaciones del sensor.

16 16

2.2 Determinación de red inalámbrica

de comunicaciones con módulo

central.

16 16

2.3 Investigación sobre arquitecturas. 32 32

2.4 Análisis técnico / económico y de

factibilidad de las opciones.

34 34

2.5 Reunión de determinación del

hardware para procura.

2

Página 11 de 31




2.6 Procura de hardware (Fuera del

horario regular de trabajo).

10

3.1 Desarrollo de arquitectura del

firmware.

16 16

3.2 Diseño de firmware. 32 32

3.3 Análisis de riesgos de firmware. 10 10

3.4 Desarrollo de pruebas para

firmware.

32 32

3.5 Programación del firmware. 40 40

3.6 Verificación y validación del

firmware.

10 10 10

3.7 Generación de manual de sensor. 8 8

3.8 Reunión de entrega de

documentación del sensor.

2 2

4.1 Desarrollo de arquitectura del

software.

16 16

4.2 Diseño de software. 32 32

4.3 Análisis de riesgos de software. 10 10

4.4 Desarrollo de pruebas para

software.

32 32

4.5 Programación del software. 40 40

4.6 Verificación y validación del

software.

10 10 10

4.7 Generación de manual de software

de localización.

8 8

4.8 Reunión de entrega de

documentación del software de

localización.

2 2

Página 12 de 31




5.1 Integración de manuales

pertenecientes al sistema de

localización

32 32

5.2 Preparación de informe final 40 40

5.3 Preparación de presentación final 20 20 8

5.4 Presentación final del proyecto y

entrega de informe final

2 2 2

5.5 Reunión de cierre del proyecto y

entrega de documentación

2 2

10. Presupuesto detallado del proyecto

Descripción Cantidad UND Costo unitario

Costo total

Horas de ingeniero 606 h $0,00 $0,00

Horas de computador 594 h $0,00 $0,00

Hardware para prototipo 3 UND $500,00 $1500,00

SUBTOTAL $1500,00

Costos indirectos (viáticos) 25 % $1500,00 $375,00

TOTAL $1875,00

Página 13 de 31




11. Matriz de asignación de responsabilidades

Código WBS

Título de la tarea

Involucrados

Sergio De Jesús

Responsable

Pablo Fierens

Orientador

Herman Moldovan Impulsor

1.1 Lecturas sobre localización en interiores. P C

1.2 Lecturas sobre técnica de fingerprinting. P C

1.3 Introducción al estándar IEEE802.11. P C

1.4 Lectura sobre comportamiento estadístico

de potencia recibida por WiFi.

P C

1.5 Investigación sobre otras redes

inalámbricas para comunicación.

P C

1.6 Investigación de antecedentes. P C

1.7 Reunión de arranque. P S S

2.1 Desarrollo de lista de especificaciones del

sensor.

P C A

2.2 Determinación de red inalámbrica de

comunicaciones con módulo central.

P C I

2.3 Investigación sobre arquitecturas. P C I

2.4 Análisis técnico / económico y de

factibilidad de las opciones.

P C A

2.5 Reunión de determinación del hardware

para procura.

P S A

2.6 Procura de hardware (Fuera del horario

regular de trabajo).

P I I

3.1 Desarrollo de arquitectura del firmware. P C A

3.2 Diseño de firmware. P C A

3.3 Análisis de riesgos de firmware. P C A

Página 14 de 31




3.4 Desarrollo de pruebas para firmware. P C A

3.5 Programación del firmware. P C I

3.6 Verificación y validación del firmware. P C I

3.7 Generación de manual de sensor. P C A

3.8 Reunión de entrega de documentación del

sensor.

P S I

4.1 Desarrollo de arquitectura del software. P C A

4.2 Diseño de software. P C A

4.3 Análisis de riesgos de software. P C A

4.4 Desarrollo de pruebas para software. P C A

4.5 Programación del software. P C I

4.6 Verificación y validación del software. P C I

4.7 Generación de manual de software de

localización.

P C A

4.8 Reunión de entrega de documentación del

software de localización.

P S I

5.1 Integración de manuales pertenecientes al

sistema de localización

P C A

5.2 Preparación de informe final P C I

5.3 Preparación de presentación final P C I

5.4 Presentación final del proyecto y entrega

de informe final

P S I

5.5 Reunión de cierre del proyecto y entrega

de documentación

P S S

Referencias: P = Responsabilidad Primaria

S = Responsabilidad Secundaria A = Aprobación I = Informado C = Consultado

Página 15 de 31




12. Gestión de riesgos a) Identificación de los riesgos: Se asigna un valor del 0 al 10 para Severidad, Probabilidad de ocurrencia y Tasa de no detección. Riesgo 1: Daños al prototipo. Severidad (S): 9

Implicaría la fabricación de un nuevo prototipo. Probabilidad de ocurrencia (O): 4

El responsable de su manipulación tiene experiencia en el manejo de materiales. Tasa de no detección (D): 10

Sería consecuencia de un error humano, por lo que es imprevisible . Riesgo 2: Error en la interpretación de los requerimientos.

Severidad (S): 10 Retrasaría los tiempos de entrega de forma creciente con el avance del proyecto.

Probabilidad de ocurrencia (O): 1 Existe un plan de comunicaciones que evita el avance sin la aprobación de cada requerimiento a implementar.

Tasa de no detección (D): 1 Existe un plan de comunicaciones que evita el avance sin la aprobación de cada requerimiento a implementar.

Riesgo 3: Imposibilidad para encontrar un hardware con las especificaciones requeridas en la Argentina.

Severidad (S): 4 Retrasaría los tiempos de procura, pero tienen holgura de 60 días para su uso según el AON.

Probabilidad de ocurrencia (O): 6 Existen requerimientos detallados como disponibilidad de un API en el adaptador de red para modo monitor, que podría ser difícil de encontrar en la Argentina.

Tasa de no detección (D): 1 La etapa de investigación preliminar ocurre mucho antes de la procura, por lo que se podrá coordinar la logística de importación en paralelo al diseño del hardware y así evitar retrasos.

Riesgo 4: Imprevistos académicos o laborales que impidan cumplir con las jornadas previstas en el calendario.

Severidad (S): 8 La tolerancia del tope de entrega del proyecto con respecto al final planificado es de 2 semanas solamente.

Probabilidad de ocurrencia (O): 6 El ritmo de estudio es bastante acelerado por los lapsos bimestrales y todas exigen tiempo de estudio y actividades fuera de clases. El ritmo laboral por el contrario deberá limitarse, por lo general, a lo establecido en contrato.

Tasa de no detección (D): 8

Página 16 de 31




Es impredecible cómo afectarán las actividades fuera de clases al proyecto a lo largo del período de ejecución.

Riesgo 5: Retrasos en el suministro de fondos para la compra de materiales para prototipos.

Severidad (S): 5 Retrasaría los tiempos de procura, pero tienen holgura de 60 días para su uso según el AON.

Probabilidad de ocurrencia: 1 El costo del hardware es sumamente bajo y la empresa tiene solvencia para asumirlo oportunamente.

Tasa de no detección (D): 10 Cualquier causa que produzca un retraso en este suministro no está prevista en el momento por lo que sería inesperada.

b) Tabla de gestión de riesgos: (El RPN se calcula como RPN=SxOxD.)

Riesgo Severidad Ocurren. Detección RPN Severidad* Ocurren.* Detecc * RPN*

1 9 4 10 360 6 4 1 24

2 10 1 1 10

3 4 6 1 24

4 8 6 8 384 6 4 5 120

5 5 1 10 50

Criterio adoptado: Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores a 125 Nota: Los valores marcados con (*) en la tabla corresponden luego de haber aplicado la mitigación. c) Plan de mitigación de los riesgos que originalmente excedían el PRN máximo establecido: Riesgo 1: Se estudiarán con detalle las opciones en base a los requerimientos para procurar y fabricar, de ser necesario, los tres prototipos considerados en los entregables.

Severidad (S): 6 Disminuye el riesgo de retrasos a la mínima expresión pero se mantiene el riesgo de aumento en el presupuesto invertido.

Probabilidad de ocurrencia (O): 4 El número de prototipos no influye en la probabilidad de que alguno se dañe.

Tasa de no detección (D): 1 Al aumentar el número de prototipos se disminuye la probabilidad de quedar sin prototipos a la mínima expresión.

Página 17 de 31




Riesgo 4: Se aumentarán los períodos de trabajo en una hora en cada jornada que sea posible para aumentar la brecha entre la fecha estimada de entrega y la fecha tope y se actualizará cada semana el avance del gantt para detectar desviaciones.

Severidad (S): 6 Al aumentar la brecha de manera aleatoria y no sistemática el riesgo disminuye marginalmente, la posibilidad de sistematizar este aumento de la brecha ante desviaciones contribuye con la disminución.

Probabilidad de ocurrencia (O): 4 El seguimiento y el aumento de la brecha no afectan la probabilidad de ocurrencia de eventos.

Tasa de no detección (D): 5 El seguimiento periódico permitirá tomar acciones para comenzar a aumentar la brecha entre los nuevos tiempos de entrega y la fecha tope de forma sistemática.

13. Gestión de la calidad 1. Requerimientos asociados a cada sensor

1.1 Deberá funcionar con estándar WiFi (IEEE 802.11) en la banda de 2,4GHz

Calidad y grado de calidad: Indicador que permitirá mostrar que se cumplió la calidad requerida: > Impresión del sello de certificación WiFi sobre el chip del adaptador. Indicador que permitirá mostrar que se alcanzó un grado de calidad mayor al

requerido: > Indicación de soporte de estándares b, g y n.

Costos de conformidad y no conformidad: Costos de conformidad asociados a cumplir con la calidad requerida: > $20 por viáticos y 2 h/h para asistir personalmente ante el proveedor y

verificar la existencia de los sellos de certificación del estándar. Costos de no conformidad por no cumplir con la calidad requerida:

> $500 por recompra del hardware. Verificación y validación: Responsable de la verificación: Sergio De Jesús Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Inspección ocular en busca del sello de certificación. Responsable de la validación: Pablo Fierens

Validación a aplicar para medir el cumplimiento de lo requerido: > Inspección ocular en busca del sello de certificación.

Página 18 de 31




1.2 Deberá considerar los paquetes provenientes de móviles y descartar los

provenientes de AP.

Calidad y grado de calidad: Indicador que permitirá mostrar que se cumplió la calidad requerida: > Existencia de móviles y ausencia de APs de una población conocida en la

salida del módulo. Costos de conformidad y no conformidad: Costos de conformidad asociados a cumplir con la calidad requerida: > 4 h/h para pruebas de verificación y validación.

Costos de no conformidad por no cumplir con la calidad requerida: > 20 h/h para la implementación de esta funcionalidad a nivel de

arquitectura, diseño, generación de plan de pruebas y programación. Verificación y validación: Responsable de la verificación: Sergio De Jesús Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Se comprobará que el diseño contenga una etapa de filtrado de paquetes

por tipo de emisor de acuerdo con el tipo de paquetes enviados descartando paquetes cuyo tipo de origen no pueda ser determinado.

Responsable de la validación: Pablo Fierens Validación a aplicar para medir el cumplimiento de lo requerido:

> Se harán pruebas de funcionamiento con una población de AP y móvilesinventariada por número de MAC. Se verificará en el vector de MAC, RSS promedio y hora de detección arrojado por el sensor la ausencia de los primeros y la existencia de los segundos.

1.3 Deberá obtener de cada dispositivo móvil la potencia recibida en cada paquete.

Calidad y grado de calidad:

Indicador que permitirá mostrar que se cumplió la calidad requerida: > Proporcionalidad de RSS promedio con distancia. Costos de conformidad y no conformidad: Costos de conformidad asociados a cumplir con la calidad requerida: > 4 h/h para pruebas de verificación y validación.


arquitectura, diseño, generación de plan de pruebas y programación. Verificación y validación: Responsable de la verificación: Sergio De Jesús Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Se comprobará que el diseño contenga una tarea que obtenga de cada

paquete proveniente de un móvil, su potencia de recepción. Responsable de la validación: Pablo Fierens

Validación a aplicar para medir el cumplimiento de lo requerido:

Página 19 de 31




> Se harán pruebas de funcionamiento alejando un móvil de control con MAC conocido a distancias definidas verificando la proporción de la distancia de alejamiento con la caída de RSS promedio.

1.4 Tendrá una ventana de muestreo de 1s tras el cual deberá promediar las

potencias por dispositivo.

Calidad y grado de calidad: Indicador que permitirá mostrar que se cumplió la calidad requerida: > Tiempo establecido en el código perteneciente al ciclo de muestreo. Costos de conformidad y no conformidad: Costos de conformidad asociados a cumplir con la calidad requerida: > 2 h/h para verificación del código escrito.


arquitectura, diseño, generación de plan de pruebas y programación. Verificación y validación: Responsable de la verificación: Sergio De Jesús

Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Se comprobará que el diseño de la tarea que obtiene las potencias

recibidas de cada paquete, las acumule y cuente las potencias acumuladas y que exista una tarea con ejecución periódica de 1 segundo que promedie estas potencias acumuladas por cada MAC detectado.


> Se hará una verificación exhaustiva del código escrito para el firmware

identificando un ciclo de muestreo donde se acumulan datos en bruto y una

tarea de promediado con período de ejecución de 1 segundo.

1.5 Deberá enviar un vector de potencias promedio y hora de detección recibidas de

cada dispositivo móvil a una central por un medio inalámbrico.

Calidad y grado de calidad: Indicador que permitirá mostrar que se cumplió la calidad requerida: > Recepción de la salida del sensor desde un módulo inalámbrico. Indicador que permitirá mostrar que se alcanzó un grado de calidad mayor al

requerido: > Conexión no cableada del módulo central al sensor.

Costos de conformidad y no conformidad: Costos de conformidad asociados a cumplir con la calidad requerida: > 1 h/h para chequear las conexión del sensor al módulo central y verificar el

contenido del stream de datos recibido. Costos de no conformidad por no cumplir con la calidad requerida:

> $300 por compra del hardware para transmisión inalámbrica + 20 h/h para

Página 20 de 31




la implementación de esta funcionalidad a nivel de arquitectura, diseño, generación de plan de pruebas y programación.

Verificación y validación: Responsable de la verificación: Sergio De Jesús Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Se comprobará que el diseño de hardware contemple una salida

inalámbrica para el reporte de datos obtenidos y una tarea que arme un vector de potencias recibidas y tiempos de detección por cada equipo móvil detectado y lo envíe por este medio.

Responsable de la validación: Pablo Fierens Validación a aplicar para medir el cumplimiento de lo requerido: > Inspección ocular para verificación de la conexión realizada. Revisión del

stream de datos recibido por el módulo central en busca de un formato vectorial que contenga potencias promedio recibidas.

2. Requerimientos asociados a la red de sensores y la transmisión inalámbrica 2.1 Deberán estar sincronizados con el módulo central para coordinar la hora de

detección.

Calidad y grado de calidad: Indicador que permitirá mostrar que se cumplió la calidad requerida: > Reflejo exacto de la hora del módulo central en el sensor una vez hecha la

conexión. Costos de conformidad y no conformidad: Costos de conformidad asociados a cumplir con la calidad requerida: > 30 m/h para conectar el sensor al módulo central y chequear sus horas

internas. Costos de no conformidad por no cumplir con la calidad requerida:

> $300 por compra del hardware para transmisión inalámbrica + 20 h/h para la implementación de esta funcionalidad a nivel de arquitectura, diseño, generación de plan de pruebas y programación.

Verificación y validación: Responsable de la verificación: Sergio De Jesús Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Se comprobará que el diseño de software contemple una solicitud de

sincronización de hora cada vez que se conecte al módulo para reportar datos.

Responsable de la validación: Pablo Fierens Validación a aplicar para medir el cumplimiento de lo requerido: > Se conectará el sensor al módulo y se verificarán sus relojes internos para

comprobar la sincronización entre ambos.

Página 21 de 31




2.2 Deberán evitar colisiones en el envío de paquetes con los vectores de potencia recibida. Calidad y grado de calidad:

Indicador que permitirá mostrar que se cumplió la calidad requerida: > Relación entre paquetes enviados por el sensor y paquetes correctamente

recibidos por el módulo central. Costos de conformidad y no conformidad: Costos de conformidad asociados a cumplir con la calidad requerida: > 1 h/h para realizar pruebas funcionales.

Costos de no conformidad por no cumplir con la calidad requerida: > $300 por compra del hardware con estándar de detección de colisiones

nativa. Verificación y validación: Responsable de la verificación: Sergio De Jesús Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Se comprobará que el diseño de hardware contemple que el dispositivo de

comunicación inalámbrica con el módulo central posea un protocolo que evite la colisión de paquetes de forma nativa.


> Se realizará una prueba con un número controlado de paquetes enviados desde el sensor y se comparará con el número de paquetes recibidos correctamente en en el módulo central.

2.3 Deberán tener un identificador único para el envío de paquetes al módulo

central. Calidad y grado de calidad:

Indicador que permitirá mostrar que se cumplió la calidad requerida: > Identificación correcta del sensor asociado al paquete recibido en el

módulo central. Costos de conformidad y no conformidad: Costos de conformidad asociados a cumplir con la calidad requerida: > 1 h/h para realizar pruebas funcionales.


arquitectura, diseño, generación de plan de pruebas y programación. Verificación y validación: Responsable de la verificación: Sergio De Jesús Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Se comprobará que el diseño de software contenga un formato de

paquete en la capa de aplicación cuya cabecera contenga el identificador del módulo.


Página 22 de 31




> Se realizará una prueba de transmisión de paquetes de forma controlada desde varios sensores y se comprobará que el módulo central sea capaz de identificar el sensor de donde proviene cada paquete.

2.4 Los paquetes enviados deberán tener un formato único. Calidad y grado de calidad:

Indicador que permitirá mostrar que se cumplió la calidad requerida: > Lectura correcta de los paquetes recibidos por el módulo central desde

cada sensor. Costos de conformidad y no conformidad: Costos de conformidad asociados a cumplir con la calidad requerida: > 1 h/h para realizar pruebas funcionales.

Costos de no conformidad por no cumplir con la calidad requerida: > 2 h/h para la comprobación/corrección de la versión de firmware instalada

en cada sensor y su compatibilidad con la versión del software del módulo central.

Verificación y validación: Responsable de la verificación: Sergio De Jesús Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Se comprobará que cada sensor poseerá la misma versión de firmware

que los demás y que el diseño del formato de paquetes está bien implementado tanto en el software como en el firmware.


> Se realizará una prueba de transmisión de paquetes de forma controlada desde varios sensores y se comprobará que el módulo central sea capaz de leer correctamente la información enviada desde cada sensor.

3. Requerimientos asociados al módulo central

3.1 Deberá recibir los vectores de potencia de la red de sensores y organizarlos en una matriz única.

Calidad y grado de calidad:

Indicador que permitirá mostrar que se cumplió la calidad requerida: > Existencia de una salida en forma de matriz con los datos requeridos en el

código. Costos de conformidad y no conformidad: Costos de conformidad asociados a cumplir con la calidad requerida: > 2 h/h para realizar verificación del código implementado.



Página 23 de 31




Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Se comprobará que el diseño del software contemple una tarea de

obtención de vectores por sensor, comparación de horarios de detección y armado de una matriz con identificación del móvil detectado y la potencia ofrecida por cada sensor en el mismo orden que se usó para los patrones de calibración del fingerprinting.


> Se verificará el código generado identificando la tarea de armado de la matriz de potencias obtenidas y su correcta implementación.

3.2 Deberá estimar las posiciones de los dispositivos sensados mediante la técnica de fingerprinting. Calidad y grado de calidad:

Indicador que permitirá mostrar que se cumplió la calidad requerida: > Correspondencia de la ubicación física de un móvil de control y su

ubicación estimada dentro del rango de tolerancia calculado en el diseño del software de fingerprinting para la prueba realizada..

Indicador que permitirá mostrar que se alcanzó un grado de calidad mayor al requerido:

> Existencia de un algoritmo de estimación de posición mediante fingerprinting y no mediante otro método, como triangulación, en el código.

Costos de conformidad y no conformidad: Costos de conformidad asociados a cumplir con la calidad requerida: > 3 h/h para realizar pruebas de funcionamiento y verificación del código

implementado. Costos de no conformidad por no cumplir con la calidad requerida:

> 20 h/h para la implementación de esta funcionalidad a nivel de arquitectura, diseño, generación de plan de pruebas y programación.

Verificación y validación: Responsable de la verificación: Sergio De Jesús Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Se comprobará que el diseño del software contemple una tarea que

estime la posición de cada dispositivo en la matriz comparando la distancia euclideana entre su vector de potencias y cada uno de los vectores de potencias almacenados en la calibración.


> Se harán pruebas de funcionamiento determinando ubicaciones en forma aleatoria y comparando la ubicación estimada por el sistema con la esperada y verificando que el error pertenezca al calculado.

Página 24 de 31




3.3 Deberá emitir un archivo con posiciones estimadas de cada dispositivo móvil sensado. Calidad y grado de calidad:

Indicador que permitirá mostrar que se cumplió la calidad requerida: > Existencia de una salida tipo archivo con un listado de dispositivos y

ubicaciones estimadas y correspondencia de la ubicación física de cada dispositivo móvil de control con la estimada.

Indicador que permitirá mostrar que se alcanzó un grado de calidad mayor al requerido:

> Salida del listado de ubicaciones estimadas en formato archivo y no en otro formato como por ejemplo string de texto en una terminal.

Costos de conformidad y no conformidad: Costos de conformidad asociados a cumplir con la calidad requerida: > 2 h/h para realizar pruebas de funcionamiento.



Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Se comprobará que el diseño del software contemple una tarea que

genere un archivo formateado con el listado de dispositivos y ubicaciones estimadas e identificado con su hora de estimación.


> Se harán pruebas de funcionamiento colocando móviles de control en espacios determinados y haciendo funcionar el sistema, se verificará en esta prueba la salida de un archivo con las características requeridas y la concordancia de las coordenadas estimadas por cada móvil de control con sus coordenadas físicas dentro del error calculado.

3.4 Deberá tener una opción de calibración para determinar vectores patrón de

potencia recibida en base a las características del entorno. Calidad y grado de calidad:

Indicador que permitirá mostrar que se cumplió la calidad requerida: > Existencia de un módulo de calibración en el software.




Página 25 de 31




Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Se comprobará que el diseño del software contemple un módulo de

calibración del sistema que solicite las coordenadas de un móvil control y obtenga su vector de potencias promedio para ese punto y lo almacene en un archivo de vectores y coordenadas patrón. Además deberá permitir repetir esta operación hasta salir del modo calibración.


> Se harán pruebas de funcionamiento del módulo de calibración, ejecutando un ciclo de calibración y luego estimando posiciones para los puntos aleatorios elegidos.

3.5 Deberá ofrecer un servicio de sincronización de hora para la red de sensores.

Calidad y grado de calidad: Indicador que permitirá mostrar que se cumplió la calidad requerida: > Sincronización de la hora de cada sensor al conectarse.




Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Se comprobará que el diseño del software contemple un servicio que, al

recibir conexiones de sensores, les transmita la hora de su reloj interno para sincronización.


> Se harán pruebas de funcionamiento conectando cada sensor, con la hora descalibrada o inicializada en cero, al módulo central y verificando que su reloj interno se ajusta al del módulo central.

3.6 Deberá tener acceso a la red inalámbrica para recibir información de los sensores. Calidad y grado de calidad:

Indicador que permitirá mostrar que se cumplió la calidad requerida: > Recepción efectiva de conexiones de sensores.


Costos de no conformidad por no cumplir con la calidad requerida: > $300 para la compra de un módulo de comunicación inalámbrica

Página 26 de 31




compatible +20 h/h para la implementación de esta funcionalidad a nivel de arquitectura, diseño, generación de plan de pruebas y programación.

Verificación y validación: Responsable de la verificación: Sergio De Jesús

Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Se comprobará que el diseño del hardware y el software contemplen la

comunicación al sistema inalámbrico correspondiente al de comunicación de los sensores con el módulo central.


> Se harán pruebas de conexión de sensores al módulo central para verificar su funcionamiento.

14. Comunicación del proyecto El plan de comunicación del proyecto es el siguiente:

PLAN DE COMUNICACIÓN DEL PROYECTO

¿Qué comunicar?

Audiencia Propósito Frecuencia Método de comunicac.

Responsable

Consultas técnicas

Pablo Fierens Resolución de dudas

Aleatoria Correo electrónico

Sergio De Jesús

Definición de requerimientos y plan de trabajo

Pablo Fierens, Herman Moldovan

Inicio de proyecto

Al culminar investigación preliminar

Reunión presencial

Sergio De Jesús

Selección de componentes


Aprobación y asignación de

recursos monetarios

Al culminar diseño y luego reactiva hasta la aprobación

Correo electrónico

Sergio De Jesús

Culminación de arquitectura o

diseño


Avance a siguiente actividad

Al culminar cada actividad de arquitectura

y diseño

Correo electrónico

Sergio De Jesús

Incorporación de comentarios


Avance a siguiente actividad

Reactiva tras la emisión e

incorporación de comentarios

Correo electrónico

Sergio De Jesús

Página 27 de 31




Culminación de etapa


Avance a siguiente etapa

Al culminar cada etapa y generar su

documentación

Reunión presencial

Sergio De Jesús

Notificación de avances

Pablo Fierens Información periódica

Semanal Correo electrónico

Sergio De Jesús

Culminación de proyecto


Entrega de documentos

y cierre

Al final del proyecto

Reunión presencial

Sergio De Jesús

15. Gestión de Compras Se espera realizar una compra sencilla a un importador especializado en componentes electrónicos por lo que el criterio de selección será el siguiente: Experiencia en el mercado de componentes electrónicos de al menos un año. Garantía de cambio por defectos de fábrica de al menos una semana. Solvencia fiscal para la generación de facturas tipo A o C a nombre de URBIX TECHNOLOGIES SA. Disponibilidad del kit de desarrollo seleccionado cuyo adaptador de red posea certificación WiFi.

16. Seguimiento y control

SEGUIMIENTO DE AVANCE

Tarea del WBS

Indicador de avance

Frecuencia de reporte

Responsable de seguimiento

Persona a ser informada

Método de comunicac.

1.1 % Al finalizar Sergio De Jesús Pablo Fierens Correo electrónico



Página 28 de 31







1.7 Binario Sergio De Jesús Pablo Fierens, Hermán Moldovan

Reunión presencial

2.1 % Al finalizar Sergio De Jesús Pablo Fierens, Hermán Moldovan

Correo electrónico


Correo electrónico



Correo electrónico


Reunión presencial


Correo electrónico


Correo electrónico


Correo electrónico


Correo electrónico

Página 29 de 31




3.4 % Semanal Sergio De Jesús Pablo Fierens Correo electrónico



Correo electrónico



Reunión presencial


Correo electrónico


Correo electrónico


Correo electrónico




Correo electrónico



Reunión presencial


Página 30 de 31






5.4 Binario Sergio De Jesús Pablo Fierens, Hermán

Moldovan y Jurado de evaluación

Exposición pública


Reunión presencial

17. Procesos de cierre Al finalizar el proyecto se realizará una revisión final ejecutando todas las pruebas de calidad requeridas sobre el prototipo y verificando que todo funcione de acuerdo con los requerimientos y se integrarán todos los manuales y documentos relacionados con el diseño y funcionamiento del sistema de localización en interiores. Luego se procederá a la verificación del plan inicial y el plan real ejecutado y se tomarán anotaciones sobre las desviaciones que hubo entre ambos en la bitácora de trabajo. Se llevará a cabo una lectura detallada de la bitácora de trabajo identificando procedimientos utilizados, dificultades y recomendaciones para próximos proyectos y se procederá a la redacción de un informe final, donde se explicará de forma abstracta el funcionamiento del sistema, su diseño y construcción, se incorporarán los comentarios no confidenciales pertenecientes a la documentación recopilada del proyecto y las recomendaciones y agradecimientos recopilados de la bitácora de trabajo. Más adelante se preparará una presentación que simplifique la visualización de los puntos clave y que permita una exposición clara y concisa sobre el proyecto en el que se incursionó, las expectativas y sus resultados. Finalmente se llevará a cabo una reunión de entrega de toda la documentación y el prototipo a la empresa para su archivado y posterior migración a una versión comercial.

Página 31 de 31

diseño de una red de sensores para la determinación de...

Documents