Módulo HMI para antena móvil...

Plan de Proyecto del Trabajo Final de Carrera

de Especialización de Sistemas Embebidos

Ing. Decchi, Alejandro Ramón

Página 1 de 24

Módulo HMI para antena

móvil auto-orientable

Autor


Director del trabajo

Ing. Alejandro Permingeat

Jurado propuesto para el trabajo

- Esp. Ing. Alejandro Furfaro

- Ing. Gustavo Alessandri

- Esp. Ing. Pablo Ridolfi

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 2 de 24

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

14. Gestión de Compras

16. Seguimiento y control

17. Procesos de cierre




Página 3 de 24

Registros de cambios

Revisión Cambios realizados Fecha

1.0 Creación del documento 30/03/2016

1.1 Primeras Correcciones Hasta Punto 6 12/04/2016

1.2 Revisión Correcciones Hasta Punto 6 01/05/2016

1.3 Primeras Correcciones del Punto 7 al Punto 12 01/05/2016

1.4 Restructuración del Alcance, se excluyó del alcance el módulo

de alarmas y módulo de calibraciones y diagnósticos.

04/05/2016

1.5 Revisión Correcciones hasta punto 12, Primeras correcciones

Punto 13 en adelante.

06/05/2016




Página 4 de 24

Acta de Constitución del Proyecto

Buenos Aires, 30 de marzo de 2016

Por medio de la presente se acuerda con el Sr. Alejandro Ramón Decchi que su Proyecto Final de

la Carrera de Especialización en Sistemas Embebidos se titulará “Módulo HMI para una antena móvil auto-

orientable”, consistirá esencialmente en el prototipo preliminar de un sistema embebido que

administrara una antena móvil auto-orientable , 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 Alejandro Permingeat

Director de la CESE-FIUBA Director VSATMOTION




Página 5 de 24

Identificación y análisis de los interesados

Rol Nombre y Apellido Puesto

Auspiciante Alejandro Permingeat Director

Cliente Alejandro Permingeat Director

Responsable Alejandro Decchi Estudiante CESE

Colaboradores Eric Pernía Docente CESE

Orientadores Pablo Gómez Coordinador CESE

Usuario Final Empresas Petroleras

1. Propósito del proyecto

El propósito de este proyecto es el desarrollo de un software embebido que encapsule toda la etapa de

"configuración" y de "control de la operación" de una antena auto-orientable para enlaces satelitales.




Página 6 de 24

2. Alcance del proyecto

Las funcionalidades que debe prestar el HMI (Interfaz Hombre Maquina) son las siguientes:

Obtener de la unidad externa (unidad de control de apuntamiento-CIAA) el estado actual.

Configurar la unidad externa (unidad de control de apuntamiento -CIAA).

Mostrar por pantalla el estado de la unidad externa.

Recibir configuraciones por pantalla táctil.

Permitir el uso de botones, como cursor para la entrada de datos.

Almacenar en forma persistente las configuraciones ingresadas.

Comunicación por la interfaz RS-485 con la unidad externa (unidad de control de apuntamiento-

CIAA).

El presente proyecto no incluye:

Armado, Instalación y puesta en marcha de la unidad externa (unidad de control de

apuntamiento -CIAA).

Armado, instalación y puesta en marcha de la antena auto-orientable.

Mostar por http la información del estado de la antena.

Permitir por http la configuración de la antena.

Permitir configuraciones por SMNP.

Configuración del modem por Ethernet.

Instalación de Web Server.

Configuración de web Server.

Calibraciones y diagnóstico de la unidad externa.

Alarmas de la unidad externa e interna.

3. Supuestos del proyecto

Para el desarrollo del presente proyecto se supone que:

Se contará con una placa Beaglebone Black con procesador AM335x 1GHz ARM® Cortex-A8, para

la instalación del S.O embebido.

Se contará con una pantalla táctil compatible con la Beaglebone Black.

Se contará con un adaptador USB a RS-485, compatible con la Beaglebone Black.

Se contará con una fuente de alimentación.

Se contará con una unidad de rack, de 2 unidades para ensamblar los componentes antes

mencionados.




Página 7 de 24

4. Requerimientos

Los requerimientos que a continuación se enumeran fueron solicitados por el cliente y consensuado con

el responsable del proyecto. Los requerimientos fueron agrupados por afinidad, y al lado de los mismos

se le especifico una prioridad entre paréntesis, siendo: (1): Muy Prioritario; (2): Poco Prioritario.

Configuración de Unidad Externa (unidad de control de apuntamiento -CIAA).

1. Configurar la unidad externa (unidad de control de apuntamiento -CIAA).(1)

1.1.1. Se debe poder configurar el satélite al cual apuntar (longitud y polarización).[REQ001] 1.1.2. Se debe poder configurar el origen de los datos de geolocalización (GPS, GLONASS o

manual). [REQ002] 1.1.3. El software deberá poder informar a la “unidad de control de apuntamiento” que se ha

“enganchado” (bloqueado) a la portadora en la etapa de recepción (esta información el software la obtiene del modem). [REQ003]

1.1.4. El software debe permitir decidir al usuario cuando iniciar el apuntamiento de la antena. [REQ004]

1.1.5. El software debe permitir decidir al usuario cuando iniciar el repliegue de la antena. [REQ005]

1.1.6. El software debe informar a la “unidad de control de apuntamiento” que inicie el apuntamiento de la antena, cuando el usuario haya indicado que se inicie dicha operación. [REQ006]

1.1.7. El software debe informar a la “unidad de control de apuntamiento” que inicie el repliegue de la antena, cuando el usuario haya indicado que se inicie dicha operación. [REQ007]

2. Mostrar por pantalla el estado de la unidad externa.(2)

1.1.8. El software deberá poder mostrar al usuario la geolocalización actual del sistema (latitud, longitud y altura). [REQ008]

1.1.9. El software deberá poder mostrar al usuario el estado del apuntamiento (los estados son: antena replegada, orientado hacia el satélite, conectado al satélite). [REQ009]

1.1.10. El software deberá indicar al usuario el nivel de señal de recepción recibida del satélite (de 0 a 100). [REQ010]

1.1.11. El software deberá poder mostrar al usuario el nombre del satélite al que se está apuntando. [REQ011]

1.1.12. El software deberá poder mostrar al usuario la latitud del satélite al que se está apuntando. [REQ012]

1.1.13. El software deberá poder mostrar al usuario la polarización del enlace satelital que se está utilizando. [REQ013]




Página 8 de 24

Entorno de Ejecución.

1. El software debe ser implementado en lenguaje C o C++.(1) [REQ014]

2. El software debe correr sobre un sistema operativo Linux embebido.(1) [REQ015]

Comunicaciones

1. El software se deberá comunicar con la “Unidad de control de apuntamiento-CIAA”

mediante RS-485. Se construirá un driver capaz de realizar dicha comunicación.(1)

[REQ016]

2. La unidad interna contará con una placa Beaglebone Black con Procesador AM335x 1GHz

ARM® Cortex-A8, la cual tendrá un adaptador USB a RS-485.(1) [REQ017]

3. El driver realizado como interfaz de comunicación, deberá correr sobre el Linux

Embebido.(1) [REQ018]

4. Las configuraciones deben ser ingresadas mediante la pantalla táctil, en caso de falla de la

misma, deberá ser ingresada por teclado standard USB de 104 teclas.(2) [REQ019]




Página 9 de 24

5. Entregables principales del proyecto

Los entregables que se realizaran y se entregaran son los que se listan a continuación:

1. Especificación de requerimiento de software.

2. Documento de diseño.

3. Repositorio con la implementación del software.

4. Manual de usuario.

6. Desglose del trabajo en tareas

1. Análisis de requerimientos. (98 Horas)

1.1.Especificación de requerimientos. (16 HS). (1).

1.2.Análisis de casos de uso, primera fase (Módulo de Comunicación). (40 HS). (1).

1.3.Análisis de casos de uso, segunda fase (Módulo Configuración Unidad Externa. y

Modulo Mostrar por Pantalla estado unidad externa). (42 HS). (1). 2. Entorno de desarrollo. (32 Horas)

2.1.Instalación, Configuración servidor de integración continúa Jenkins. (16 HS). (1).

2.2.Instalación, Configuración servidor de control de versiones. (8 HS). (1).

2.3.Instalar el S.O Embebido en la Placa Beaglebone Black. (8 HS). (1). 3. Arquitectura de software. (54 Horas).

3.1.Definición de la arquitectura del software, para la primera fase. (28 HS). (1).

3.2.Definición de la arquitectura del software, para la segunda fase. (26 HS). (1). 4. Diseño de software. (189 Horas).

4.1.Estudio de aplicaciones similares. (24 HS). (1).

4.2.Desarrollo del diseño para la primera fase. (80 HS). (1).

4.3.Desarrollo del diseño para la segunda fase. (85 HS). (1). 5. Pruebas. (46 Horas).

5.1.Desarrollo de pruebas unitarias, para la primera fase. (8 HS). (1).

5.2.Desarrollo de pruebas de integración, para la primera fase. (4 HS). (1).

5.3.Desarrollo de pruebas unitarias, para la segunda fase. (24 HS). (1).

5.4.Desarrollo de pruebas de integración, para la segunda fase. (10 HS). (1). 6. Implementación. (156 Horas).

6.1 Implementación para la primera fase. (80 HS). (1).

6.2 Implementación para la segunda fase. (76 HS). (1). 7. Entregables. (32 Horas).

7.1.Manual de instrucciones de uso. (24 HS).

7.2.Diagrama esquemático. (8 HS).




Página 10 de 24

8. Especialización de sistemas embebidos. (80 Horas).

8.1.Entrega de avance al jurado. (16 HS).

8.2.Cierre y Redacción del proyecto final de carrera. (8 HS).

8.3.Entrega de su memoria escrita al jurado. (48 HS).

8.4.Presentación pública y defensa ante el jurado. (8 HS). Total Horas/Hombre: 687 Horas.

1. Diagrama de Activity On Node




Página 11 de 24

8. Diagrama de Gantt




Página 12 de 24




Página 13 de 24

9. Matriz de uso de recursos de materiales

Código WBS

Nombre de la tarea Recursos requeridos (horas)

Notebook Placa

Beaglebone Black

Laboratorio

1.1 Especificación de requerimientos 16 N/C N/C

1.2 Análisis de casos de uso, primera fase. 40 N/C N/C

1.3 Análisis de casos de uso, segunda fase. 42 N/C N/C

2.1 Instalación, Configuración servidor de

integración continúa Jenkins. 16 N/C N/C

2.2 Instalación, Configuración servidor de

control de versiones.

8 N/C N/C

2.3 Instalar el S.O Embebido en la Placa

Beaglebone Black. N/C 8 N/C

3.1 Definición de la arquitectura del

software, primera fase.

28 N/C N/C


software, segunda fase.

26 N/C N/C

4.1 Estudio de aplicaciones similares. 24 N/C N/C

4.2 Desarrollo del diseño para la primera

fase. 80 N/C N/C

4.3 Desarrollo del diseño para la segunda

fase. 85 N/C N/C

5.1 Desarrollo de pruebas unitarias para

primera fase. 8 N/C N/C

5.2 Desarrollo de pruebas de integración

para primera fase.

4 N/C N/C

5.3 Desarrollo de pruebas unitarias para

segunda fase.

24 N/C N/C




Página 14 de 24

5.4 Desarrollo de pruebas de integración

para segunda fase.

10 N/C N/C

6.1 Implementación para la primera fase.

72 8 N/C

6.2 Implementación para la segunda fase. 78 8 8

7.1 Manual de instrucciones de uso. 24 N/C N/C

7.2 Diagrama esquemático. 8 N/C N/C

8.1 Entrega de avance. 16 N/C N/C

8.2 Cierre y Redacción del proyecto final

de carrera. 8 N/C N/C

8.3 Entrega de su memoria escrita al

jurado. 48 N/C N/C

8.4 Presentación pública y defensa ante el

jurado. 8 N/C N/C

10. Presupuesto detallado del proyecto

Categoría. Detalle. Costo.

Costo Directo. 687 Hs a 135$/Hs $92.745 Costo Indirecto. 30% del Costo Directo. $28.823,50 Materiales. Provisto por VSATMotion $0 Total. $120.568,50




Página 15 de 24

11. Matriz de asignación de responsabilidades

Código WBS

Título de la tarea Listar todos los nombres y apellidos y el rol definidos en el proyecto

Ing. Alejandro Decchi Responsable del Proyecto.

Ing. Eric Pernía Orientador

Ing. Alejandro Permingeat Director del Proyecto.

VSATMOTION Usuario

1.1 Especificación de requerimientos. P C C,A N/C

1.2 Análisis de casos de uso, primera

fase. P C C,A N/C

1.3 Análisis de casos de uso, segunda

fase. P C C,A N/C

2.1 Instalación, Configuración

servidor de integración continúa

Jenkins.

P C C N/C

2.2 Instalación, Configuración

servidor de control de versiones.

P C C N/C

2.3 Instalar el S.O Embebido en la

Placa Beaglebone Black. P C C,A N/C


software, primera fase. P C C,A N/C


software, segunda fase. P C C,A N/C

4.1 Estudio de aplicaciones similares. P C C N/C

4.2 Desarrollo del diseño para la

primera fase. P C C,A N/C

4.3 Desarrollo del diseño para la

segunda fase. P C C,A N/C

5.1 Desarrollo de pruebas unitarias

para primera fase.

P C C,A N/C




Página 16 de 24

5.2 Desarrollo de pruebas de

integración para primera fase. P C C,A N/C

5.3 Desarrollo de pruebas unitarias

para segunda fase.

P C C,A N/C

5.4 Desarrollo de pruebas de

integración para segunda fase.

P C C,A N/C

6.1 Implementación para la primera

fase. P C C,A I

6.2 Implementación para la segunda

fase. P C C,A I

7.1 Manual de instrucciones de uso. P C C,A N/C

7.2 Diagrama esquemático. P C C,A N/C

8.1 Entrega de avance.

P N/C C,A I

8.2 Cierre y Redacción del proyecto

final de carrera. P N/C A N/C

8.3 Entrega de su memoria escrita al

jurado. P N/C A A

8.4 Presentación pública y defensa

ante el jurado. P N/C A A

Referencias: P = Responsabilidad Primaria. S = Responsabilidad Secundaria. A = Aprobación. I = Informado. C = Consultado. N/C= No Corresponde.




Página 17 de 24

12. Gestión de riesgos

ID Riesgo Descripción O S D RPN Acción Correctiva O S D RPN*

1 Una o mas tareas

llevan mas

tiempo de lo

especificado.

El tiempo

especificado para el

requerimiento es

insuficiente.

5 10 5 250 Reorganizar las

tareas.

Invertir mas

horas.

3 8 5 120

2 Surgen

problemas al

programar las

distintas fases.

La programación

de las distintas

funciones de las

distintas fases no

funcionan como se

esperaba.

8 9 5 360 Involucrar al Director del proyecto y a los orientadores, para remediar la situación.

6 7 5 210

3 No llegar a

cumplir todos los

requerimientos.

Los requerimientos establecidos al principios del proyecto no se logran cumplir.

7 8 6 336 Se involucrara a las partes interesadas para negociar el alcance.

6 7 5 210

4 Extravió de la

placa beaglebone

o de algún

hardware.

Se pierde la placa o algún hardware de relacionado a la misma.

6 7 8 336 Adquirir una nueva placa o hardware extraviado.

4 5 6 120

5 Se extravíen

archivos del

software.

Los archivos fuentes se

dañan o se pierden. 7 9 8 504 Subir los archivos a

GitLab

frecuentemente.

4 6 5 120




Página 18 de 24

Ocurrencia (O): 1 (muy baja) a 10 (muy alta). Severidad (S): 1 (muy baja) a 10 (muy alta).

Detectabilidad (D): 1 (muy alta) a 10 (muy baja).

Nota:

El RPN se calcula como RPN=SxOxD

Los valores marcados con (*) en la tabla corresponden luego de haber aplicado la mitigación.

Criterio adoptado: Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores

a 250.

Plan Mitigación Riesgo 1: Se reorganizaran las tareas de tal modo que se puedan trabajar en tareas

paralelamente e invertir mas horas de la semana.

Severidad(S=8): El cronograma se vería afectado significativamente.

Probabilidad de Ocurrencia(O=3): Este tipo de proyecto lleva mas tiempo del previsto.

Tasa de NO Detección(D=5): Se deberá prestar atención a esta variable, para corregir de

inmediato sobre la marcha del proyecto.

Plan Mitigación Riesgo 2: Se involucrará al director del proyecto y a los orientadores para encontrar una

solución conjunta, para remedir la situación no deseada.

Severidad(S=7):En estos tipos de proyecto, se puede presentar estos tipos de situaciones.

Probabilidad de Ocurrencia(O=6): Al ser un proyecto complejo, este riesgo puede presentarse.

Tasa de NO Detección(D=5): Se detecta siguiendo el GANTT en comparación con la situación

actual.

Plan Mitigación Riesgo 3: Se involucrará a las partes interesadas para redefinir alcances y requerimientos.

Severidad(S=7): Pueden surgir atrasos que ocasione este tipo de riesgo.

Probabilidad de Ocurrencia(O=6): Al ser un proyecto complejo, puedo ocurrir que no se cumplan

en primera fase o segunda fase todos los requerimientos.

Tasa de NO Detección (D=5): Este tipo de riesgo es difícil predecirlos en las primeras fases de

desarrollo.




Página 19 de 24

Plan Mitigación Riesgo 4: Se coordinará con el director para adquirirá una nueva placa o hardware

extraviado.

Severidad(S=5): El proyecto quedara parado si sucede dicho riesgo.

Probabilidad de Ocurrencia(O=4): La placa, tanto como el hardware será utilizado por el

desarrollador del software, se tratara de no trasladar hasta el momento de las pruebas.

Tasa de NO Detección(D=6): Es difícil de detectar. Se coordinara con el Director la posibilidad de

adquirir otra, para la continuidad del proyecto.

Plan Mitigación Riesgo 5: Se creara una cuenta en Gitlab para subir periódicamente los archivos y códigos

del proyecto.

Severidad(S=6): Debido a diversas situaciones los archivos o documentos puede extraviarse o

corromperse.

Probabilidad de Ocurrencia(O=4): Este tipo de riesgo, es complejo de determinarlo ya que no

depende totalmente de nosotros, pueden suceder por fallas externas.

Tasa de no Detección(D=5): Difícil de determinar cuando puede suceder, se realizaran resguardos

periódicos en Gitlab.

http://www.gitlab.com/

http://www.gitlab.com/




Página 20 de 24

13. Gestión de la calidad

1. Configuración de la unidad externa. 1.1.Abarca requerimientos:[REQ001] al [REQ013]

1.2.Verificación: 1.2.1. Responsable de la Verificación: Alejandro Decchi. 1.2.2. Método de Verificación:

Pruebas unitarias. Matriz de trazabilidad entre el diseño y los requerimientos. Matriz de trazabilidad entre módulos de software y módulos de diseño. Documentación del código.

1.3.Validación: 1.3.1. Responsable de la Validación: Alejandro Decchi. 1.3.2. Método de Validación:

Matriz de trazabilidad entre las pruebas de integración y los requerimientos.

2. Entorno de ejecución. 1.1.Abarca los requerimientos: [REQ014] al [REQ015]

1.2.Verificación: 1.2.1 Responsable de la Verificación: Alejandro Decchi. 1.2.2 Método de Verificación:

Pruebas unitarias. Matriz de trazabilidad entre el diseño y los requerimientos. Matriz de trazabilidad entre módulos de software y módulos de diseño. Documentación del código.


Matriz de trazabilidad entre las pruebas de integración y los requerimientos.

3. Comunicaciones. 1.1.Abarca los requerimientos: [REQ016] al [REQ019]

1.2.Verificación: 1.2.1 Responsable de la Verificación: Alejandro Decchi. 1.2.2 Método de Verificación:

Pruebas unitarias. Matriz de trazabilidad entre el diseño y los requerimientos. Matriz de trazabilidad entre módulos de software y módulos de diseño. Documentación del código. Prueba de comunicación con EDU-CIAA.


Matriz de trazabilidad entre las pruebas de integración y los requerimientos. Se probará la correcta comunicación con la EDU-CIAA.




Página 21 de 24

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. Director,

Orientadores y

Jurado.

Evidenciar

la evolución del

proyecto.

Mitad del

Proyecto. Teléfono y/o

correo

electrónico.

Ing. Alejandro

Decchi

Inconvenientes

que afecten el

cronograma

Director y

Orientadores. Definir

requerimientos

de forma

precisa

Cuando sea

requerido. Teléfono y/o

correo

electrónico.

Ing. Alejandro

Decchi

Definir

objetivos,

alcances y

restricciones

Director y

Orientadores. Evaluar como

comenzar el

proyecto.

Acciones

Principales.

Inicio del

Proyecto.

Teléfono y/o

correo

electrónico.

Ing. Alejandro

Decchi

Resolución de

incidentes Director y

Orientadores. Despejar dudas

Técnicas,

bibliográficas que

surjan

durante la

realización del

proyecto.

Cuando surja. Correo

electrónico.

Ing. Alejandro

Decchi

Finalización y

cierre del

proyecto.

Director,

Orientadores y

Jurado.

Presentar

documentación

a los clientes.

Fin del

Proyecto. Correo

electrónico. Ing. Alejandro

Decchi

15. Gestión de Compras No se prevé contratar servicios de terceros. Los materiales utilizados (placa de desarrollo) para la

realización del proyecto serán provistos por VSATMOTION, por lo cual no es necesario un análisis de

gestión de compra.




Página 22 de 24

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 Cantidad Secciones del documento. Grado de descripción de los casos de uso.

Semanalmente, mientras dure esta tarea.

Ing. Alejandro Decchi


Correo Electrónico.

2.1 Tarea Finalizada. Una vez por mes, mientras dure la tarea.












3.1 Cantidad de Módulos.

Una vez por mes, mientras dure la tarea.




3.2 Cantidad de Componentes.









4.2 4.3

Cantidad de Módulos.








Página 23 de 24

5.1 5.2 5.3 5.4

Cantidad de Pruebas.





6.1 6.2

Cantidad de Módulos de Software.





7.1 Cantidad de secciones del documento.









8.1 Tarea Finalizada. Una vez, a la mitad del proyecto.


Dr. Ing. Ariel Lutenberg Ing. Alejandro Permingeat


8.2 Tarea Finalizada. Al finalizar el proyecto.






Dr. Ing. Ariel Lutenberg Ing. Alejandro Permingeat




Ing. Alejandro Permingeat. Jurado.





Página 24 de 24

17. Procesos de cierre Para evaluar el desempeño durante el proyecto, el Ing. Alejandro Decchi realizará las siguientes actividades

Evaluación de alcance: Se realizará una tabla en la cual se indicará si se cumplió con cada una de las tareas pactadas en la WBS y su porcentaje de completitud.

Evaluación del tiempo (cronograma). Se realizará una tabla en la cual se incluirá: el tiempo estimado, el tiempo real y el porcentaje indicando cuanto se desvió la tarea con respecto al tiempo estimado.

Si hubieran quedado objetivos total o parcialmente incompletos, se deberá hacer una evaluación de las causas y factores causantes y proponer acciones futuras para asegurar el éxito de futuros proyectos.

Se archivará toda la documentación de la gestión del proyecto de forma de ser fácilmente reutilizada en la planificación de futuros proyectos.

Durante la presentación y defensa pública del trabajo final de carrera, el Ing. Alejandro Decchi incluirá una sección especial para agradecer a todos los interesados y en especial al equipo de trabajo, colaboradores, miembros del jurado y autoridades del CESE.

Módulo HMI para antena móvil...

Documents

Transcript of Módulo HMI para antena móvil...