Gateway Ethernet - RS485 para la interconexión de sistemas de …laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final... · 2019-12-26 · Plan de Proyecto del Trabajo Final

Plan de Proyecto del Trabajo Final de Carrera

de Especialización de Sistemas Embebidos

Ing. Ignacio Lombardi

Gateway Ethernet - RS485 para la interconexión de sistemas de automatización

Autor


Director del trabajo

Dr. Ing. Pablo Gómez (FIUBA)

Jurado propuesto para el trabajo

- Esp. Ing. Nombre Apellido (filiación) - Esp. Ing. Nombre Apellido (filiación) - Esp. Ing. Nombre Apellido (filiación)

Este plan de trabajo ha sido realizado en el marco de la asignatura Gestión de

Proyectos entre mayo y junio de 2018.

Página 1 de 29




Tabla de contenido

Registros de cambios 3

Acta de Constitución del Proyecto 4

Descripción técnica-conceptual del Proyecto a realizar 5

Identificación y análisis de los interesados 7

1. Propósito del proyecto 7

2. Alcance del proyecto 7

3. Supuestos del proyecto 8

4. Requerimientos 8

5. Entregables principales del proyecto 9

6. Desglose del trabajo en tareas 9

7. Diagrama de Activity On Node 10

8. Diagrama de Gantt 11

9. Matriz de uso de recursos de materiales 16

10. Presupuesto detallado del proyecto 19

11. Matriz de asignación de responsabilidades 19

12. Gestión de riesgos 22

13. Gestión de la calidad 24

14. Comunicación del proyecto 25

15. Gestión de Compras 26

16. Seguimiento y control 26

17. Procesos de cierre 30

Página 2 de 29




Registros de cambios

Revisión Detalle de los cambios realizados Fecha

1.0 Creación del documento 14/05/2018

2.0 Completado hasta el punto 11 29/05/2018

3.0 Revision y correccion hasta el punto 11 31/05/2018

4.0 Completado hasta el punto 17 04/06/2018

5.0 Revisión y corrección hasta el punto 17 05/06/2018

Página 3 de 29




Acta de Constitución del Proyecto

Buenos Aires, 4 de mayo de 2018

Por medio de la presente se acuerda con el Ing. Ignacio Joaquín Lombardi que su Trabajo Final de

la Carrera de Especialización en Sistemas Embebidos se titulará “Gateway Ethernet - RS485 para la

interconexión de sistemas de automatización”, consistirá esencialmente en el prototipo preliminar de un

Gateway Ethernet - RS485, y tendrá un presupuesto preliminar estimado de 600 hs de trabajo y $3.760,

con fecha de inicio lunes 25 de junio de 2018 y fecha de presentación pública lunes 3 de diciembre de

2018.

Se adjunta a esta acta la planificación inicial.

Ariel Lutenberg Sergio Salvan

Director de la CESE-FIUBA Philips

Nombre y Apellido

Director del Trabajo Final

Nombre y Apellido (1) Nombre y Apellido (2)

Jurado del Trabajo Final Jurado del Trabajo Final

Nombre y Apellido (3)

Página 4 de 29




Jurado del Trabajo Final

Descripción técnica-conceptual del Proyecto a realizar

En este trabajo se realizará la implementación de un equipo controlador, que permita enviar y recibir comandos entre ethernet y RS485. El objetivo es interconectar el sistema Dynalite y el sistema Color Kinetics, que hasta el momento solo se comunican mediante interfaces estándar (contacto seco por ejemplo) y no en forma nativa y bidireccional. De esta manera se espera poder contar con las mejores cosas de cada uno de estos dos sistemas.

El sistema de Color Kinetics está basado sobre ethernet, es un sistema para el control de iluminación en tiempo real. Al estar basado en ethernet permite el envío de grandes cantidades de información como para realizar cambios dinámicos rápidos, a gran escala. Se muestra un esquemático de la arquitectura en la figura 1.

En cambio el sistema Dynalite es un sistema de control distribuido que se utiliza para automatización industrial. Este sistema es completamente modular lo que lo hace muy versátil y escalable. Cuenta con diferentes equipos o módulos que se interconectan entre sí mediante un bus RS485. Cada uno de estos módulos agrega una funcionalidad distinta al sistema, como sensado de presencia, conexión a un servidor, o algún actuador, etc. Todos estos módulos son inteligentes ya que tienen la posibilidad de procesar información, y lo único que se envía por la red RS485 son señales para que sean recibidos por los otros módulos. Un pequeño esquemático de la topología del sistema se puede ver en la figura 2.

Página 5 de 29




Por lo tanto, la propuesta de este trabajo es hacer es un nuevo módulo para agregar a esta red RS485. Lo que va a permitir al sistema original poder contar todos los beneficios de lo que implica ser parte de una sistema de control distribuido, de agregar y quitar funcionalidades simplemente. En la figura 3 se puede ver como el producto se agregaria al sistema.

Página 6 de 29




Identificación y análisis de los interesados

Rol Nombre y Apellido Departamento Puesto

Auspiciante

Cliente Sergio Salvan Finanzas

Impulsor Ing. Anthony Scott Marketing Jefe de Producto

Responsable Ignacio Lombardi Ingeniería Gerente del proyecto

Colaboradores

Orientadores Dr. Ing. Carlos Rodriguez Innovación y desarrollo Arquitecto de

soluciones

Orientadores Director del trabajo -------- ----------

Usuario Final Jefe de mantenimiento -------- ----------

Cliente: se vería favorecido con el desarrollo del producto, aunque sería difícil justificar horas de trabajo

en el desarrollo del proyecto.

Impulsor: al informarle de la idea del proyecto se vio muy interesado. Es la persona que haría que este

producto sea utilizado en proyectos en todo el mundo.

Orientador: Carlos va a poder ayudar mucho con la integración con el sistema de automatización basado

en 485 ya que es uno de los desarrolladores globales.

Usuario final: es el operador / programador del sistema funcionando. Va a disfrutar de los beneficios de

flexibilidad y baja de costos especialmente.

1. Propósito del proyecto

El propósito del proyecto es mostrar los beneficios que se pueden traer optando por una

solución modular y de control distribuido como lo es esta. Con el fin de continuar con el

desarrollo y diseño de soluciones a futuro en esta dirección.

2. Alcance del proyecto

Dentro del alcance del proyecto se incluye el armado de un prototipo funcional del Gateway Ethernet - RS485. El Gateway debe poder poder recibir y almacenar diferentes archivos que contengan la información de cada show. Los shows contienen diferentes comandos de efectos de luces que deben

Página 7 de 29




ser enviados por el puerto Ethernet a las luminarias. Estos shows deberán ser disparados mediante comandos recibidos por el puerto RS485. Se debe poder cargar dentro del Gateway una tabla de equivalencia entre el comando 485 recibido y el show a disparar.

No está incluido dentro del alcance de este proyecto el desarrollo del software de PC necesario para el diseño de los shows que debe disparar. Estos shows se generan con un software que se puede descargar gratuitamente de internet. Al producto se le debe cargar el archivo con formato XML que contiene toda la información del show.

3. Supuestos del proyecto

Para el desarrollo del presente proyecto se supone que se conoce la tecnología necesaria para

desarrollar el producto. Por lo tanto no se requerirá de un proceso de investigación previa ni

desarrollo de nuevas tecnologías.

Si bien el protocolo RS485 que se va a utilizar es abierto y documentado, este no es el caso con el

protocolo basado en ethernet. Por lo tanto se supone que se va a conseguir la documentación de

dicho protocolo. O en su defecto alguna librería para poder enviar y recibir mensajes.

4. Requerimientos

A continuación se enumeran los requerimientos específicos para el proyecto.

1. Requerimientos de interfaz ethernet a. Debe ser posible enviar comando a cada una de las luminarias de la instalación. Debe

poder enviárselo a un mínimo de 170 luminarias (1 universo DMX). b. Se debe poder almacenar al menos 20 shows, con 10 efectos cada uno. c. La comunicación debe tener una latencia menor a 100ms.

2. Requerimientos de interfaz 485 a. Se le debe poder asignar al equipo un ID único que lo identifique en la red. De esta

manera pueda detectar si los comandos recibidos son dirigidos a él o no b. Debe tener un la posibilidad de identificar de los comandos que se le envíen, el inicio

de un show. 3. Configuración

a. La configuración del mapa con todas las luminarias junto con sus direcciones IP y DMX debe ser mediante un XML estándar del software gratuito,

b. La configuración de shows en el dispositivo deben ser mediante un archivo .XML estándar obtenido del software gratuito.

4. Hardware a. El producto debe poder ser instalado en riel DIN estándar para una fácil instalación. b. El producto debe ser alimentado con una fuente de bajo voltaje estándar y externa. De

esta manera evitar procesos de certificación de seguridad eléctrica.

Página 8 de 29




5. Entregables principales del proyecto

Listado de los entregables una vez finalizado el proyecto:

● Guia de uso y configuración ● Hoja de datos del producto ● Diagrama esquemático ● Código fuente ● Diagrama de instalación ● Informe de avance del proyectos ● Informe final ● Presentación de proyecto

6. Desglose del trabajo en tareas

A continuación se divide el proyecto en diferentes tareas. Se indica entre paréntesis la duración en horas de cada tarea.

1. Tareas preliminares (40) a. Revisión detallada de los requerimientos de hardware (8) b. Selección del hardware adecuado (8) c. Preparar entorno de desarrollo (24)

2. Interfaz Ethernet (56) a. Desarrollo de la interfaz para enviar y recibir paquetes (24) b. Envío de comandos a luminarias mediante el protocolo ethernet (8) c. Desarrollo de un módulo para incorporar el proyecto fácilmente (24)

3. Interfaz RS485 (40) a. Desarrollo de la interfaz para enviar y recibir mensajes (16) b. Envío y recepción de comandos de la red de control distribuida (16) c. Implementar en un módulo de para incorporar fácilmente al proyecto (8)

4. Archivo de configuración (120) a. Definir método de carga de archivos de configuración (24) b. Implementar metodo de envio de archivos (48) c. Análisis del mapa de configuración con los componentes de la red Ethernet (24) d. Codificar módulo para incorporar al proyecto (24)

5. Generación de shows (148) a. Análisis de archivos con .xml con shows (24) b. Definición de efectos más usados e imprescindibles para implementar (8) c. Implementar efecto de color fijo (8) d. Implementar efecto de cambio de 2 colores (8) e. Implementar el resto de efectos definidos en el punto 5.b (40) f. Implementar la ejecución de shows (60)

6. Pruebas (56) a. Definir protocolo de pruebas a realizar (16)

Página 9 de 29




b. Armado de una red funcional ethernet y RS485 (16) c. Detección de bugs y fallas (20) d. Definir posibles mejoras a futuro (4)

7. Documentación y cierre (140) a. Informe de avance (8) b. Armar manual de usuario y configuración (22) c. Armado de hoja de datos (14) d. Armado de diagrama de instalación (16) e. Armado de informe final (60) f. Armado de presentación final (20)

Cantidad total de horas: 600

7. Diagrama de Activity On Node A continuación se encuentra el AON de todas las etapas del proyecto. La unidad de tiempo se encuentra definida en horas.

Página 10 de 29




8. Diagrama de Gantt

A continuación se puede ver la tabla con todos los WBS, junto con su duración, su fecha de inicio y de fin. Para obtener las fechas se definió un nuevo calendario de trabajo con las horas reales que se podrán dedicar al desarrollo del trabajo. En este calendario se consideraron horas de trabajo diario, horas de cursada y también de esparcimiento. Por lo tanto quedan libres Martes y Jueves de 19 a 23 hs, y sábados de 10 a 18 hs.

Página 11 de 29




Página 12 de 29




Página 13 de 29




Página 14 de 29




9. Matriz de uso de recursos de materiales

CÓDIGO

WBS

NOMBRE DE LA TAREA

RECURSOS REQUERIDOS (hs)

Laptop PLACA DE

DESARROLLO

EQUIPOS DE

CONTROL 485

LUMINARIAS

ETHERNET

1

Tareas preliminares

1.a Revisión detallada de los

requerimientos de

hardware

8 0 0 0

1.b Selección

del hardware adecuado

8 0 0 0

1.c Preparar

entorno de desarrollo

24 24 0 0

2 Interfaz

Ethernet

2.a Desarrollo de la interfaz

para enviar y recibir paquetes.

24 24 0 24

2.b Envío

de comandos a luminarias

mediante el protocolo ethernet

8 8 0 8

2.c Desarrollo

de un módulo para incorporar el

proyecto fácilmente.

24 24 0 0

3 Interfaz

RS485

3.a Desarrollo de la interfaz

para enviar y recibir mensajes.

16 16 16 0

3.b Envío

y recepción de comandos de la

16 16 16 0

Página 15 de 29




red de control distribuida.

3.c Implementar

en un módulo de para incorporar

fácilmente al proyecto

8 8 0 0

4 Archivo

de configuración

4.a Definir método de carga de

archivos de configuración.

24 24 0 0

4.b Implementar

metodo de envio y

almacenamiento de archivos.

48 48 0 0

4.c Análisis

del mapa de configuración actual

con todos los componentes de la

red

Ethernet.

24 24 0 0

4.d Codificar

módulo para incorporar al

proyecto.

24 24 0 0

5 Generación

de shows

5.a Análisis de archivos con

.xml con shows

24 24 0 0

5.b Definición

de efectos más usados e

imprescindibles para implementar.

8 8 8 0

5.c Implementar

efecto de color fijo

8 8 0 8

5.d Implementar

efecto de cambio de 2 colores.

8 8 0 8

5.e Implementar

el resto de efectos definidos en el

punto 5.b

40 40 0 40

Página 16 de 29




5.f Implementar

la ejecución de shows.

60 60 0 60

6 Pruebas

6.a Definir protocolo de

pruebas a realizar

16 16 16 16

6.b Armado

de una red funcional ethernet y

RS485

16 16 16 16

6.c Detección

de bugs y fallas.

20 20 20 20

6.d Definir

posibles mejoras a futuro.

4 4 4 4

7 Documentación

y cierre

7.a Informe de avance 8 0 0 0

7.b Armar

manual de usuario y

configuración.

22 0 0 0

7.c Armado

de hoja de datos.

14 0 0 0

7.d Armado

de diagrama de instalación.

16 0 0 0

7.e Armado

de informe final

60 0 0 0

7.f Armado

de presentación final

20 0 0 0

Página 17 de 29




10. Presupuesto detallado del proyecto A continuación se realiza una descripción del presupuesto estipulado para el desarrollo del proyecto.

Descripción Cantidad Valor Total

Horas hombre 600 $ 430,00 $ 258.000,00

Placa EduCIAA 2 $ 1.200,00 $ 2.400,00

Cableado eléctrico para testeo 1 $ 400,00 $ 400,00

Transportes 96 $ 10,00 $ 960,00

Costos Indirectos (20%) 1 $ 52.352,00 $ 52.352,00

$ 314.112,00

11. Matriz de asignación de responsabilidades

En la tabla siguiente se establece la matriz de asignación de responsabilidades y manejo de autoridad de cada una de las tareas dentro del proyecto.

Referencias: P = Responsabilidad Primaria S = Responsabilidad Secundaria A = Aprobación I = Informado C = Consultado

Página 18 de 29




WBS

NOMBRE DE LA TAREA

Listar todos los nombres y apellidos y el rol definidos en el

proyecto

Ignacio

Lombardi

Responsable

Ing. Anthony

Scott

Impulsor

Dr. Ing.

Carlos

Rodriguez

Orientador

Esp. Ing

DIRECTOR

1 Tareas preliminares

1.a Revisión detallada de los

requerimientos de hardware

P A

1.b Selección del hardware adecuado P A

1.c Preparar entorno de desarrollo P

2 Interfaz Ethernet

2.a Desarrollo de la interfaz para

enviar y recibir paquetes.

P C I C

2.b Envío de comandos a luminarias

mediante el protocolo ethernet

P C I C

2.c Desarrollo de un módulo para

incorporar el proyecto fácilmente.

P C I A

3 Interfaz RS485

3.a Desarrollo de la interfaz para

enviar y recibir mensajes.

P I C C

3.b Envío y recepción de comandos de

la red de control distribuida.

P I C C

3.c Implementar en un módulo de

para incorporar fácilmente al

proyecto

P I C A

4 Archivo de configuración

4.a Definir método de carga de

archivos de configuración.

P I C C

Página 19 de 29




4.b Implementar metodo de envio y

almacenamiento de archivos.

P I C C

4.c Análisis del mapa de configuración

actual con todos los componentes

de la red Ethernet.

P A C I

4.d Codificar módulo para incorporar

al proyecto.

P I C A

5 Generación de shows

5.a Análisis de archivos con .xml con

shows

P C I

5.b Definición de efectos más usados

e imprescindibles para

implementar.

P C I

5.c Implementar efecto de color fijo P C I

5.d Implementar efecto de cambio de

2 colores.

P C I

5.e Implementar el resto de efectos

definidos en el punto 5.b

P C I

5.f Implementar la ejecución de

shows.

P C I

6 Pruebas

6.a Definir protocolo de pruebas a

realizar

P A I A

6.b Armado de una red funcional

ethernet y RS485

P

6.c Detección de bugs y fallas. P A A

6.d Definir posibles mejoras a futuro. P C C

7 Documentación y cierre

7.a Informe de avance P A

Página 20 de 29




7.b Armar manual de usuario y

configuración.

P A I C

7.c Armado de hoja de datos. P A I C

7.d Armado de diagrama de

instalación.

P A I C

7.e Armado de informe final P I A

7.f Armado de presentación final P I A

12. Gestión de riesgos En la siguiente sección se identifican y se analizan los riesgos de el proyecto, de modo de poder mitigarlos mediante un plan de contingencia.

a) Identificación de los riesgos.

1. Pérdida o rotura de prototipo a. Severidad: ( 7 ) La severidad de esto es alta ya que traería muchísimas demoras que

harían complicada la entrega del trabajo en tiempo y forma. b. Probabilidad de ocurrencia: ( 3 ) La probabilidad de que esto ocurra es baja, ya que no

existe la necesidad de moverlo demasiado. 2. Pérdida o rotura de PC

a. Severidad: ( 8 ) Sería algo tanto o más grave que la rotura del prototipo ya que significaría la pérdida del código y de la documentación.

b. Probabilidad de ocurrencia: ( 6 ) La probabilidad de que esto ocurra es más grande ya que la PC se mueve diariamente.

3. Falta de documentación de protocolos. a. Severidad: ( 8 ) De ocurrir esto se debería hacer un investigación muy ardua de

detección y análisis de las tramas del protocolo. Esto traería muchísimas demoras en la implementación.

b. Probabilidad de ocurrencia: ( 3 ) El protocolo RS485 se encuentra debidamente documentado y adicionalmente se puede detectar en forma sencilla. M

4. Modificación de alguno de estos protocolos a. Severidad: ( 5 ) Los protocolos que vamos a utilizar pueden cambiar debido a que no

están regidos por un estándar internacional. Por lo tanto existe la posibilidad de que esto suceda. De ser así deberíamos realizar modificaciones a nuestro código. Pese a esto, el cambio esperamos que no sea drástico, y que sea compatible hacia atrás.

Página 21 de 29




b. Probabilidad de ocurrencia: (1) Estos protocolos no sufren cambios hace varios años, y no se espera un cambio en el corto plazo.

5. Falta de tiempo para desarrollo a. Severidad: ( 6 ) Debido a viajes, trabajo, o inclusive las otras materias del postgrado

puede ser que no se pueda disponer de todas las horas para este proyecto. Esto puede traer demoras que se trasladen a la fecha de finalización.

b. Probabilidad de ocurrencia: ( 7 ) Tenemos varias causas que puedan generar falta de tiempo, como viajes de trabajo. Por lo tanto, es factible que no sea fácil en todo momento recuperar dichas horas.

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

Riesgo Severidad Ocurrencia RPN Severidad* Ocurrencia* RPN*

1 7 3 21

2 8 6 48 2 6 12

3 8 3 24

4 5 1 5

5 6 7 42 6 4 24

Criterio adoptado: - Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores a 25. 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: 2. Pérdida o rotura de PC

a. Plan de Mitigación: Se utilizará un sistema de control de versiones en la nube, como por ejemplo GIT. Y se generarán alarmas para recordar de generar un guardado en la nube cada una semana.

b. Severidad: ( 2 ) Luego de la mitigación, se reduce muchísimo la severidad ya que únicamente se perdería el trabajo de como máximo una semana.

c. Probabilidad de ocurrencia: ( 6 ) La probabilidad de que esto ocurra permanece igual y es grande ya que la PC se mueve diariamente.

5. Falta de tiempo para desarrollo

a. Plan de mitigación: Se contará con una placa adicional disponible para los viajes y tener movilidad. De esta manera poder continuar con el desarrollo de código y compilación durante

Página 22 de 29




viajes e inclusive en horas libres de trabajo. Este no tiene que ser un prototipo completamente funcional, sino que es suficiente como para compilar código.

c. Severidad: ( 6 ) La severidad permanece igual y no cambia. Debido a viajes, trabajo, o inclusive las otras materias del postgrado puede ser que no se pueda disponer de todas las horas para este proyecto. Esto puede traer demoras que se trasladen a la fecha de finalización.

d. Probabilidad de ocurrencia: ( 4 ) Pudiendo contar con tiempo de desarrollo en los viajes se disminuye la probabilidad de ocurrencia de no poder dedicar el tiempo estipulado en los viajes.

13. Gestión de la calidad Para cada uno de los requerimientos del proyecto indique:

5. Requerimientos de interfaz ethernet a. Debe ser posible enviar comando a cada una de las luminarias de la instalación. Debe

poder enviárselo a un mínimo de 170 luminarias (1 universo DMX). i. Verificación: Se calculara el tiempo de procesamiento y de envío de mensajes

necesario de acuerdo al protocolo para el envio de informacion. ii. Validación: Se validará el correcto funcionamiento con una instalación real.

b. Se debe poder almacenar al menos 20 shows, con 10 efectos cada uno. i. Verificación: Se estimará el tamaño promedio de un show, y se calculará la

memoria de almacenamiento que requiere el sistema. ii. Validación: Se validará el correcto almacenaje con el prototipo funcionando.

c. La comunicación debe tener una latencia menor a 100ms. i. Verificación: Se calculara el tiempo de procesamiento necesario para el envio

de informacion. ii. Validación: se medirá este tiempo con un sniffer de paquetes entre las

luminarias y el prototipo funcional. 6. Requerimientos de interfaz 485

a. Se le debe poder asignar al equipo un ID único que lo identifique en la red. De esta manera pueda detectar si los comandos recibidos son dirigidos a él o no.

i. Verificación: Se elegirá un equipo con memoria para almacenar este parámetro.

ii. Validación: Se validará la correcta asignación con el prototipo funcional. b. Debe tener un la posibilidad de identificar de los comandos que se le envíen, el inicio

de un show. i. Verificación: Se desarrollará una interfaz de interpretación de los mensajes

rS485 ii. Validación; Se validará el disparo de shows con el prototipo funcional.

7. Configuración a. La configuración del mapa con todas las luminarias junto con sus direcciones IP y

DMX debe ser mediante un XML estándar del software gratuito.

Página 23 de 29




i. Verificación: Se elegirá un equipo de hardware con memoria suficiente para almacenar como mínimo un mapa con la información para 170 luminarias.

ii. Validación: Se validara este requerimiento con un el prototipo funcional y 170 luminarias.

b. La configuración de shows en el dispositivo deben ser mediante un archivo .XML estándar obtenido del software gratuito.

i. Verificación: Se analizará previamente el formato de almacenaje de estos shows. Y se seleccionara un hardware con memoria suficiente para su almacenaje.

ii. Validación: Se validara este requerimiento almacenando show en el prototipo funcional.

8. Hardware a. El producto debe poder ser instalado en riel DIN estándar para una fácil instalación.

i. Verificación: Se analizará la posibilidad de montar el hardware seleccionado sobre una carcasa pequeña para montaje en riel DIN.

ii. Validación: Se colocara el prototipo funcional en una carcasa con montaje en riel DIN.

b. El producto debe ser alimentado con una fuente de bajo voltaje estándar y externa. De esta manera evitar procesos de certificación de seguridad eléctrica.

i. Verificación: Se seleccionará un equipo con alimentación por USB a 5 Vcc. ii. Validación: Se revisará el correcto funcionamiento con dicha fuente de

alimentación.

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

Avance del proyecto


Mantener informado, y obtener consejos.

Mensual Email Ignacio Lombardi

Problemas de costos y alcance


Consultar sobre metodo de resolucion de algún inconveniente

Al momento de surgir el problema

Email Ignacio Lombardi

Página 24 de 29




Problemas con interfaz Ethernet

Ing. Anthony Scott

Consultar sobre inconvenientes y posibles soluciones.



Problemas con interfaz RS485

Dr. Ing. Carlos Rodriguez

Consultar sobre inconvenientes y posibles soluciones.



15. Gestión de Compras Únicamente deberemos contar dos placas EduCIAA par el desarrollo del proyecto. Par eso analizaremos el mejor presupuesto para la compra de las mismas. Ya se cuenta con el presupuesto de la placa del proveedor Electrocomponentes.

Pensamos contar con 2 plaquetas, una para el armado del prototipo funcional, y la otra para ser llevada a todos lados únicamente para la compilación y desarrollo de código.

16. Seguimiento y control A continuación se realiza para cada tarea del proyecto una análisis de cómo va a ser medido el avance de cada una. También se define quien va a ser el responsable y quien se informará su estado de avance, así como también la frecuencia en que se va a realizar cada informe.

WBS NOMBRE DE LA TAREA Indicador de Avance

Frecuencia de Reporte

Responsable de Seguimiento

Persona a ser Informada

Método

1 Tareas preliminares

1.a Revisión detallada de los requerimientos de hardware

Cantidad de requerimientos cumplidos

Una vez Ignacio Lombardi

Director Email

1.b Selección del hardware adecuado

Cantidad de equipos revisados


Director Email

Página 25 de 29




1.c Preparar entorno de desarrollo

Cantidad de módulos incorporados


Director Email

2 Interfaz Ethernet

2.a Desarrollo de la interfaz para enviar y recibir paquetes.

Estado de avance de la interfaz (HW, SW, Recepción)


Director, Ing. Anthony Scott, Dr. Ing. Carlos Rodriguez

Email

2.b Envío de comandos a luminarias mediante el protocolo ethernet

Cantidad de tipos de mensajes enviados



Email

2.c Desarrollo de un módulo para incorporar el proyecto fácilmente.

Cantidad de funciones en el módulo



Email

3 Interfaz RS485

3.a Desarrollo de la interfaz para enviar y recibir mensajes.




Email

3.b Envío y recepción de comandos de la red de control distribuida.

Cantidad de tipos de mensajes enviados



Email

3.c Implementar en un módulo de para incorporar fácilmente al proyecto




Email

Página 26 de 29




4 Archivo de configuración

4.a Definir método de carga de archivos de configuración.

Cantidad de métodos propuestos



Email

4.b Implementar metodo de envio y almacenamiento de archivos.


Dos veces

Ignacio Lombardi


Email

4.c Análisis del mapa de configuración actual con todos los componentes de la red Ethernet.

Cantidad de componentes y atributos incorporados



Email

4.d Codificar módulo para incorporar al proyecto.




Email

5 Generación de shows

5.a Análisis de archivos con .xml con shows

Cantidad de componentes y atributos incorporados



Email

5.b Definición de efectos más usados e imprescindibles para implementar.

Cantidad de archivos analizados



Email

5.c Implementar efecto de color fijo

Estado de avance


Director, Ing. Anthony Scott, Dr. Ing. Carlos

Email

Página 27 de 29




Rodriguez

5.d Implementar efecto de cambio de 2 colores.

Estado de avance



Email

5.e Implementar el resto de efectos definidos en el punto 5.b

Cantidad de efectos implementados



Email

5.f Implementar la ejecución de shows.

Cantidad de efectos incorporados

Dos veces

Ignacio Lombardi


Email

6 Pruebas

6.a Definir protocolo de pruebas a realizar

Cantidad de pruebas



Email

6.b Armado de una red funcional ethernet y RS485

Estado de avance


Director Email

6.c Detección de bugs y fallas. Cantidad de bugs y fallas detectadas


Director, Ing. Anthony Scott

Email

6.d Definir posibles mejoras a futuro.

Cantidad de mejoras detectadas



Email

7 Documentación y cierre

7.a Informe de avance Estado de Una vez Ignacio Director Email

Página 28 de 29




avance Lombardi

7.b Armar manual de usuario y configuración.

Cantidad de páginas



Email

7.c Armado de hoja de datos. Cantidad de hojas



Email

7.d Armado de diagrama de instalación.

Estado de avance



Email

7.e Armado de informe final Cantidad de páginas

Dos veces

Ignacio Lombardi

Director Email

7.f Armado de presentación final Cantidad de slides


Director Email

17. Procesos de cierre Para finalizar el proyecto se realizará una reunión final donde se evaluaran las siguientes actividades:

● Analizar si se respetó el Plan de Proyecto Original: ○ Se analizará cada uno de los WBS y su fecha de realización real comparada con la

fecha estimada en el diagrama de GANTT origina. ○ Responsable: Ignacio Lombardi. Se discutirá y se sacarán conclusiones junto con el

director elegido. ● Identificación de las técnicas y procedimientos utiles e inutiles que se utilizaron:

○ Se hará una recopilación de todos los pedidos de ayuda y consejos a todos los involucrados en el proyecto. De esta manera poder hacer una análisis con retrospectiva de cuáles puntos se podrían haber mejorado al respecto.

○ Responsable: Ignacio Lombardi realizará una tabla resumen de cada uno de los problemas. Se realizara un pedido de feedback al director en cada caso.

● Indicar quién organizará acto de agradecimiento: ○ Se realizará un agradecimiento formal a cada uno de los involucrados en el proyecto,

incluyendo una sección especial en toda la documentación. Se realizará una mención especial en la presentación del proyecto.

○ Responsable: Ignacio Lombardi.

Página 29 de 29

Documents

Gateway Ethernet - RS485 para la interconexión de sistemas de …laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final... · 2019-12-26 · Plan de Proyecto del Trabajo Final