Sistema de enclavamiento en FPGA con altos niveles de...

Plan de Proyecto del Trabajo Final de la

Maestría de Sistemas Embebidos

Esp. Ing. Martín Nicolás Menéndez

Sistema de enclavamiento en FPGA con altos niveles de desempeño RAMS

Autor


Director del trabajo

Dr. Ing. Ariel Lutenberg (FIUBA,CONICET)

CoDirector del trabajo

Mg. Ing. Facundo Larosa (UTN-FRH, FIUBA)

Jurado propuesto para el trabajo

- Mg. Ing. Nicolás Dassieu Blanchet (FIUBA)

- Esp. Ing. Pedro Martos (FIUBA)

- Esp. Ing. Nicolás Álvarez (UNSAM,FIUBA)

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

Tecnología y la Innovación entre marzo y abril de 2019.

Página 1 de 35




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 6

1. Propósito del proyecto 7

2. Alcance del proyecto 7

3. Supuestos del proyecto 7

4. Requerimientos 7

5. Entregables principales del proyecto 8

6. Desglose del trabajo en tareas 8

7. Diagrama de Activity On Node 9

8. Diagrama de Gantt 9

9. Matriz de uso de recursos de materiales 10

10. Presupuesto detallado del proyecto 10

11. Matriz de asignación de responsabilidades 11

12. Gestión de riesgos 11

13. Gestión de la calidad 13

14. Comunicación del proyecto 13

15. Gestión de Compras 13

16. Seguimiento y control 14

17. Procesos de cierre 14

Página 2 de 35




Registros de cambios

Revisión Detalle de los cambios realizados Fecha

1.0 Creación del documento 09/03/2019

1.1 Completados primeros puntos 08/04/2019

1.2 Agregados requerimientos y completados todos los puntos 12/04/2019

Página 3 de 35




Acta de Constitución del Proyecto

Buenos Aires, 3 de marzo de 2017

Por medio de la presente se acuerda con el Esp. Ing. Martín Nicolás Menéndez que su Proyecto

Final de la Maestría en Sistemas Embebidos se titulará “Sistema de enclavamiento en FPGA con altos

niveles de desempeño RAMS”, consistirá esencialmente en el prototipo preliminar del sistema de

enclavamiento sobre kit de desarrollo FPGA, y tendrá un presupuesto preliminar estimado de 600 hs de

trabajo y $10.000, con fecha de inicio sábado 9 de marzo de 2019 y fecha de presentación pública lunes 4

de diciembre de 2019.

Se adjunta a esta acta la planificación inicial.

Ariel Lutenberg Martín Nicolás Menéndez

Director de la MSE-FIUBA CONICET-GICSAFe.

Ariel Lutenberg Facundo Larosa

Director del Trabajo Final

Co-director del Trabajo Final

Esp. Ing. Pedro Martos Esp. Ing. Nicolás Álvarez

Jurado del Trabajo Final Jurado del Trabajo Final

Esp. Ing Nicolás Dassieu Blanchet

Jurado del Trabajo Final

Página 4 de 35




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

Un enclavamiento es un sistema ferroviario que controla en forma automática que los cambios de

vías se produzcan en forma segura, evitando descarrilamientos y choques de trenes. En Argentina los

enclavamientos tienen entre 40 y 100 años de antigüedad, por lo que muchos han agotado su vida útil y

deben ser reemplazados.

En Argentina cada día tres millones de personas viajan en tren o subte y el 10% del PBI se moviliza por ferrocarril. Sin embargo, todos los sistemas electrónicos para la seguridad vial de trenes y subtes son importados y muy costosos.

Así, en muchos ferrocarriles, no hay sistemas de seguridad para pasajeros, conductores, peatones y

automovilistas y en otros, se siguen usando tecnologías de hace más de 50 años, que en los países con alto desarrollo tecnológico han sido reemplazadas hace mucho tiempo.

Esta situación ha favorecido que ocurran importantes accidentes y ha urgido al Estado a adquirir en el exterior trenes y sistemas de seguridad ferroviaria, implicando enormes gastos en dólares y la dependencia de tecnología extranjera .

Los accidentes implican pérdidas de vidas humanas y/o pérdidas económicas significativas. Incluso,

cuando los enclavamientos no son fiables, las formaciones aminoran la marcha en las inmediaciones de un cambio de vía, demorando el trayecto y encareciendo la logística.

En la Tabla 1 se presentan ejemplos de accidentes relativos a descarrilamientos. Las fallas en la

asignación de las vías se deben al enclavamiento, por falta de mantenimiento y/o actualización.

Tabla 1. Ejemplo de accidentes ferroviarios por descarrilamiento País Año Fallecidos Heridos Razón

Italia 2018 3 +100 Rotura de enclavamiento

España 2006 41 47 Desconocido

EE.UU. 2017 3 +100 Falla en enclavamiento

México 1982 30 50 Falla en enclavamiento

EE.UU. 2018 2 +100 Desconocido

India 2017 23 150 Falla en enclavamiento

En la Tabla 2 se presentan algunos de los más importantes accidentes ferroviarios que se han

producido en Argentina. Se observa que todos se podrían haber evitado mediante el uso de sistemas electrónicos apropiados, que hoy en día son habituales en países con alto desarrollo tecnológico. Sin embargo en la actualidad estos sistemas no se desarrollan en la Argentina.

Página 5 de 35




Tabla 2. Ejemplo de algunos accidentes ferroviarios en Argentina

Ciudad Año Fallecidos Heridos Descripción ¿Evitable?

Palermo 1949 18 80 Choque de trenes Evitable

Benavidez 1970 236 400 Choque de trenes Evitable

Brandsen 1978 34 74 Choque de trenes Evitable

Quilmes 1982 30 50 Choque de trenes Evitable

Castelar 2013 3 315 Choque de trenes Evitable

En consecuencia, existen tres alternativas posibles para actualizar los sistemas de seguridad viales:

1. Comprar soluciones cerradas a firmas extranjeras, lo que crea una fuerte dependencia tecnológica y

un gasto muy considerable, del orden de cientos de millones de dólares anuales. 2. Continuar operando los sistemas ferroviarios bajo condiciones de seguridad deficientes. 3. Realizar el desarrollo de sistemas nacionales para mejorar la seguridad ferroviaria.

En los sistemas críticos una falla puede poner en peligro cientos de vidas humanas y/o costosas

inversiones. Por lo tanto se deben cumplir estrictos parámetros de fiabilidad, disponibilidad, mantenibilidad y seguridad (RAMS) durante todo el ciclo de vida. Las normas EN-50126/8/9 detallan los procedimientos para especificar y demostrar el cumplimiento de los parámetros RAMS ferroviarios.

Desde 2004 la comunidad europea ha establecido normas ferroviarias relacionadas con los

parámetros RAMS, haciendo especial hincapié en la seguridad.

En este sentido las tres normas principales son la EN-50126 (ciclo de vida), la EN-50128 (técnicas de software) y EN-50129 (técnicas de hardware). Entre otras cuestiones se busca asegurar la integridad de la seguridad, considerando para eso por ejemplo:

1. Fallos Sistemáticos: causados por errores humanos durante el diseño, fabricación, verificación, validación o mantenimiento

2. Fallos Aleatorios: causados por la fatiga, deterioro por el tiempo de vida, etc. Se manifiestan como fallos del hardware.

Algunas técnicas para minimizar los fallos son las siguientes:

1. Fallos sistemáticos: Utilizar un adecuado ciclo de vida y técnicas de software y hardware adecuadas para el diseño y desarrollo del producto.

2. Fallos Aleatorios: Uso de componentes adecuados, diversidad y redundancias.

Actualmente los enclavamientos más modernos son electrónicos, y están implementados mediante una combinación de microcontroladores con FPGAs o solamente FPGAs. Algunas de las razones para utilizarlos en sistemas críticos son las siguientes:

1. Flexibilidad 2. Integridad

Página 6 de 35




3. Variedad de productos 4. Performance 5. Herramientas y metodologías 6. Certificaciones 7. Riesgo de obsolescencia reducido

Para esto se utilizan diversas tecnologías de FPGA, como se ilustra en la Tabla 3.

Tabla 3. Tecnologías FPGA disponibles FPGA Fallas Costo

Antifuse FPGA Sin fallas detectadas Muy Alto

Flash FPGA Sin fallas detectadas Alto

SRAM FPGA 500-2.500 FITs Medio

El término FIT (failure in time) está definido como la tasa de falla cada un billón de horas. Es una

forma de cuantificar la fiabilidad de un sistema. Debido a su menor tasa de fallas las FPGA Flash y Antifuse son más fiables para utilizarse en

sistemas críticos. Sin embargo, para poder alcanzar los niveles más altos de seguridad no alcanza con elegir una tecnología segura, también es importante usar estrategias para asegurar su desempeño.

Por ejemplo, la redundancia es obligatoria en sistemas críticos para obtener un sistema tolerante a

fallas, pudiendo operar ante eventos no previstos u erróneos. La diversidad de plataformas de hardware, por ejemplo utilizando diferentes proveedores de un mismo aparato, es otra técnica muy utilizada.

Los estándares además sugieren la aplicación de un diseño en V, inspirado en el ciclo de vida en V

de la ingeniería de software.

Existen antecedentes de enclavamientos electrónicos utilizando FPGAs que han alcanzado un

elevado rendimiento RAMS. Sin embargo, en Argentina y en la Latinoamérica no hay antecedentes de

desarrollo tecnológico en la temática y es casi nulo el uso de enclavamientos electrónicos.

El proyecto beneficiará a las más de 14 millones de personas que residen en el Área Metropolitana de

Buenos Aires (AMBA) y utilizan los trenes diariamente. Estas personas realizan más de 500 millones de

viajes al año, lo que implica un enorme impacto social. Además de repercutir directamente en el

presupuesto de Trenes Argentinos al modernizar la infraestructura, reducir la dependencia de productos

internacionales y potenciar el desarrollo de tecnología nacional.

Como toda innovación, el proyecto aborda un proceso iterativo que irá aportando en cada paso un

grado de avance mayor en el producto y en los procedimientos de uso y validación. Buscando generar un

nuevo valor agregado a un área de escasa explotación nacional pero de altísima y urgente necesidad para el

país.

Página 7 de 35




Dentro del universo tecnológico al que tenemos acceso, los sistemas de enclavamientos en FPGA o

microcontroladores redundados no son una rareza. Diversas naciones han abordado especialmente éste

último enfoque, por lo que estaríamos ante una innovación moderada o incremental.

No obstante, si el eje de la discusión pasara por romper la inercia de dependencia de desarrollos

importados, por priorizar un desarrollo nacional por sobre la adaptación a un producto privado cual caja

negra, por apostar por un diseño de la mano de múltiples universidades públicas a lo ancho y largo del país;

entonces y solo entonces podemos afirmar sin ninguna duda que nos encontramos frente a una innovación

radical cual punto de inflexión en nuestra tradición ferroviaria de abrazarse a tecnologías de considerable

antigüedad o desembolsar gran cantidad de dinero para importar diseños ajenos a nuestras necesidades y

lejanos en presupuesto a lo que podemos abordar.

La necesidad de un nuevo y moderno sistema de enclavamiento ferroviario surgió de la mano de

Trenes Argentinos. Por lo tanto, aunque no podríamos afirmar que los mismos pueden ser englobados

dentro de la categoría de “el mercado”, si podemos decir que es nuestro cliente quien demanda el

producto/servicio ante una necesidad diaria a la que se enfrentan. Es por eso que consideramos que el

modelo de innovación al que debemos atenernos corresponde al de 2da generación: Demand Pull Models.

En un modelo de innovación de 2da generación es el mercado quien demanda un bien o servicio,

ante lo cual se inicia el proceso de desarrollo o diseño, seguido de su fabricación y finalmente su venta. Solo

que en nuestro caso se trata de un desarrollo de un grupo de investigación (GICSAFe) en el marco de una

institución científica estatal (CONICET) para una empresa sociedad del estado nacional (Trenes Argentinos),

hecho por el cual no hay una “venta” propiamente dicha, siendo todos actores del mismo estado.

Página 8 de 35




Identificación y análisis de los interesados

Tabla 4. Identificación de Stakeholders

Rol Nombre y Apellido Departamento Puesto

Auspiciante Pablo Gomez GICSAFe(CONICET) Co-director posgrado

Cliente Ariel Lutenberg CONICET-GICSAFe Director

Impulsor Ariel Lutenberg GICSAFe(CONICET) Director Trabajo final /

posgrado

Responsable Martín Nicolás Menéndez GICSAFe(CONICET) Investigador

Colaboradores Facundo Larosa GICSAFe(CONICET) Co-director Trabajo Final

Ramiro GICSAFe(CONICET) Desarrollador front-end

Orientadores Ariel Lutenberg GICSAFe(CONICET) Director Trabajo final /

posgrado

Equipo Martín Nicolás Menéndez GICSAFe(CONICET) Investigador

Opositores

Usuario Final Profesionales I+D CONICET-GICSAFe Director

Usuario final: La gerencia de Trenes Argentinos suele presentar demoras en las respuestas, lo que

repercutirá negativamente en el desarrollo del trabajo. Acudir al cliente que hará de nexo entre GICSAFe y

Trenes Argentinos.

1. Propósito del proyecto

El propósito de este proyecto es el diseño, implementación y realización de pruebas funcionales de un prototipo de sistema electrónico de enclavamiento, realizando todo este trabajo sobre un kit de desarrollo FPGA. Procurando estudiar las normas y tecnologías para implementar metodologías orientadas a mejorar los niveles RAMS del sistema a desarrollar de acuerdo al estado del arte en sistemas ferroviarios altamente críticos.

2. Alcance del proyecto

El proyecto incluye:

1. Estudio de las normas aplicables y requisitos RAMS

2. Diseño de máquina de estados del sistema principal y subsistemas

3. Evaluación de diferentes tecnologías para la implementación

Página 9 de 35




4. Diseño de la arquitectura del sistema

5. Diseño del sistema en Verilog/VHDL

6. Simulación de la solución mediante software apropiado 7. Análisis preliminar de rendimiento RAMS de la solución a implementar 8. Ensayos unitarios, de integración, funcionales, de aceptación y de integración contínua 9. Análisis de rendimiento RAMS de la solución implementada 10. Documentación del sistema y subsistemas.

Exclusiones:

1. No se realizará una maqueta ferroviaria

2. No se realizará la parte mecánica del cambio de vías ni nada relacionado

3. No se realizarán los módulos de conversión de potencia

4. No se actuará sobre vías reales

5. No se realizarán prototipos que actúen como interfaces

3. Supuestos del proyecto

Supuestos del proyecto Para el desarrollo del presente proyecto se supone que:

1. El desarrollo es alcanzable con los conocimientos actuales y los que se obtendrán a los largo de las

materias de la especialización

2. El tiempo estipulado será suficiente para alcanzar los objetivos

3. Los materiales a utilizar se dominarán en el tiempo requerido

4. Los materiales a utilizar estarán disponibles para su uso

5. Los imprevistos que puedan ocurrir no demorarán más que los tiempos disponibles para resolver

los mismos

6. La dificultad del proyecto será incremental, pero también aumentarán las herramientas para

abordarlo

7. Se asume que se dispondrá de una conexión resuelta entre la capa lógica y la capa de

infraestructura.

8. Se asume que se dispondrá de una conexión resuelta entre la capa lógica y la capa logística.

9. Se utilizará una única conexión de Ethernet / Profibus a una notebook para realizar ensayos.

4. Requerimientos

1.1. Componentes de HW

1. Placa de desarrollo FPGA (cantidad: 1) [XXXXX-RZV-ER-01-REQ0001]

2. Fuente de alimentación SIL 4 [XXXXX-RZV-ER-01-REQ0002]

Página 10 de 35




3. Notebook (cantidad: 1) [XXXXX-RZV-ER-01-REQ0003]

4. Cable conexión ethernet / profibus (cantidad: 1) [XXXXXRZV-ER-01-REQ0004]

1.2. Funciones

1.2.1. Interfaces E/S

1. Leer las señales de forma redundada.[XXXXX-RZV-ER-01-REQ0005]

2. Validar por votación las señales redundadas. [XXXXX-RZV-ER-01-REQ0006]

3. Cambiar el estado de los actuadores de campo. [XXXXX-RZV-ER-01-REQ0007]

4. Comprobar el correcto cambio de estado de los actuadores de campo.

[XXXXX-RZV-ER-01-REQ0008]

1.2.2. Unidad Central de Enclavamiento (UCE)

1. Posición de las formaciones:

1. Cada entrada de ocupación corresponde unívocamente al estado de un circuito de

vía.[XXXXX-RZV-ER-01-REQ0009]

2. Los estados energizados de ocupación corresponden a la ausencia de formaciones

ferroviarias en el correspondiente circuito de vía.[XXXXX-RZV-ER-01-REQ0010]

3. Los estados desenergizados de ocupación corresponden a la presencia de una formación

ferroviaria en el correspondiente circuito de vía.[XXXXX-RZV-ER-01-REQ00011]

4. Las entradas impares de ocupación corresponden a circuitos de vía ascendentes.


5. Las entradas pares de ocupación corresponden a circuitos de vía descendentes.


6. Cada circuito de vía solo puede ser ocupado por una formación a la vez.


7. Una misma formación puede ocupar dos circuitos de vía en la transición de uno a otro.


2. Semáforos ferroviarios:

1. Cada circuito de vía debe ser protegido por un semáforo. [XXXXX-RZV-ER-01-REQ0016]

2. Se tienen dos tipos de semáforos: de circulación directa y de maniobra.


3. Los semáforos de circulación directa presentan 3 aspectos. [XXXXX-RZV-ER-01-REQ0018]

Página 11 de 35




4. Los semáforos de maniobra (cambio de vía) presentan 2 aspectos.


5. Los semáforos de maniobra (cambio de vía) no pueden tener aspecto verde.


6. Los semáforos correspondientes a la vía ascendente se enumeran de forma impar.


7. Los semáforos correspondientes a la vía descendente se enumeran de forma par.


8. Los semáforos de maniobra se enumeran asumiendo que pertenecen al sentido al cual

permiten transitar. [XXXXX-RZV-ER-01-REQ0022]

9. Los estados desenergizados corresponden al aspecto rojo del semáforo correspondiente.


10. Los estados energizados positivamente corresponden al aspecto verde del semáforo

correspondiente. [XXXXX-RZV-ER-01-REQ0024]

11. Los estados energizados negativamente corresponden al aspecto amarillo/naranja del

semáforo correspondiente. [XXXXX-RZV-ER-01-REQ0025]

12. Los semáforos de circulación directa deberán presentar un aspecto rojo si el circuito de

vía al que deben proteger se encuentra ocupado por una formación ferroviaria.


13. Los semáforos de circulación directa deberán presentar un aspecto rojo si el circuito de

vía posterior al que deben proteger se encuentra ocupado. [XXXXX-RZV-ER-01-REQ0027]

14. Los semáforos de circulación directa deberán presentar un aspecto amarillo/naranja si

el circuito de vía posterior al que deben proteger se encuentra desocupado y el semáforo

correspondiente a este último presenta un aspecto rojo. [XXXXX-RZV-ER-01-REQ0028]

15. Los semáforos de maniobra deberán presentar un aspecto rojo si la máquina de cambios

se encuentra en posición directa. [XXXXX-RZV-ER-01-REQ0029]

16. Los semáforos de maniobra deberán presentar un aspecto amarillo/naranja si la

máquina de cambios se encuentra en posición inversa, si el modo de funcionamiento es

semiautomático y si [TBD] circuitos de vía adyacentes al destino se encuentran desocupados.


3. Pasos a nivel:

1. Los pasos a nivel ocupan los metros finales de un circuito de vía.

Página 12 de 35





2. Los pasos a nivel tienen dos estados: barrera alta y barrera baja.


3. El estado desenergizado de la señal corresponde a barrera baja.


4. El estado energizado de la señal corresponde a barrera alta. [XXXXX-RZV-ER-01-REQ0034]

5. Los pasos a nivel se enumeran en el sentido de la vía ascendente.


6. Los pasos a nivel consideran fuertemente el sentido de circulación.


7. En el sentido de circulación ascendente las formaciones circulan sobre circuitos de vía de

numeración impar creciente. [XXXXX-RZV-ER-01-REQ0037]

8. En el sentido de circulación descendente las formaciones circulan sobre circuitos de vía de

numeración par decreciente. [XXXXX-RZV-ER-01-REQ0038]

9. El estado de barrera baja se dispara si se detecta una ocupación dos [TBD] circuitos de vías

anteriores al circuitos de vía al cual pertenece el paso a nivel, sin importar si se detecta en la

vía ascendente o la vía descendente. [XXXXX-RZV-ER-01-REQ0039]

10. El estado de barrera alta se dispara al tener libres simultáneamente los 3 [TBD] circuitos

de vías anteriores al cual pertenece el paso a nivel, en ambos sentidos de circulación

simultáneamente. [XXXXX-RZV-ER-01-REQ0040]

4. Cambios de vías y máquinas de cambios.

1. Un cambio de vías se sitúa entre el final de un circuito de vías ascendente y el final de otro

circuito de vías descendente, constituyendo una conexión entre ambos.


2. Un cambio de vías se realiza sólo en modo semiautomático. [XXXXX-RZV-ER-01-REQ0042]

3. Un cambio de vías se encuentra protegido por un semáforo de maniobra de dos aspectos.


4. El semáforo de maniobra que protege el cambio de vías solo tiene aspectos rojo y amarillo.


5. Las formaciones que deban cruzar al otro sentido deberán pasar el cruce de vía y tomar el

cambio en reversa. [XXXXX-RZV-ER-01-REQ0045]

6. La máquina de cambios estará siempre en posición normal durante el modo automático,

Página 13 de 35




para permitir la circulación directa. [XXXXX-RZV-ER-01-REQ0046]

7. Solo en modo semiautomático se puede pasar la máquina de cambios a posición invertida o

reversa. [XXXXX-RZV-ER-01-REQ0047]

5. Precedencia

1. Lo primero que debe verificarse es el modo de funcionamiento. [XXXXX-RZV-ER-01-REQ0048]

2. Lo segundo que debe verificarse es el estado de la máquina de cambios.


3. Lo tercero que debe verificarse es el estado de los PANs. [XXXXX-RZV-ER-01-REQ0050]

4. Lo cuarto que debe verificarse es el estado de los semáforos. [XXXXX-RZV-ER-01-REQ0050]

5. Si el PAN no se encuentra con la barrera baja, no se puede habilitar el paso a ninguna

formación sobre el circuito de vía al que pertenece el mismo. [XXXXX-RZV-ER-01-REQ0051]

6. Ante cada orden de escritura debe verificarse que se realizó correctamente con una

posterior lectura antes de proceder al próximo elemento de señalamiento.


6. Tiempos

1. En modo semiautomático, al ingresar un pedido de ruta y ser aprobada, se tiene X segundos

[TBD] para cancelar la operación. [XXXXX-RZV-ER-01-REQ0053]

2. Cada escritura debe ser acompañada de una lectura a los X segundos [TBD], para contemplar

el tiempo que demora el accionamiento en actuar sobre el señalamiento.


3. El tiempo de subida y bajada de las barreras es de entre 7 y 8 segundos.


4. El tiempo que lleva pasar a modo normal o invertido una máquina de cambios es de X

segundos [TBD]. [XXXXX-RZV-ER-01-REQ0056]

5. El tiempo que lleva a un semáforo en campo en cambiar de aspecto es de X segundos [TBD].


6. Las operaciones de control pueden suponerse instantáneas [TBC].


7. Modo automático

1. Los semáforos son controlados por la posición de las formaciones, solo restringidos por el

estado del resto del señalamiento. [XXXXX-RZV-ER-01-REQ0059]

Página 14 de 35




2. En el caso de que el señalamiento lo permita, se presenta hacia adelante de cada formación

solo semáforos en aspecto verde y hacia atrás el doble recubrimiento.


3. No se pueden realizar cambios de vías, la posición de la máquina de cambios debe ser

normal en todo momento. [XXXXX-RZV-ER-01-REQ0061]

4. Se ignoran todos los pedidos de rutas del operador. [XXXXX-RZV-ER-01-REQ0062]

5. Solo admite circulación directa de las formaciones. [XXXXX-RZV-ER-01-REQ0063]

6. Solo se puede cambiar a modo automático si se tienen X [TBD] circuitos de vías adyacentes

al cambio desocupados y el mismo se encuentra en posición normal.


8. Modo semiautomático

1. El único modo que admite que las formaciones crucen a la vía contraria.


2. Un cambio de vías se realiza sólo si X [TBD] circuitos de vías adyacentes al cambio se

encuentran desocupados y el operador solicita la acción. [XXXXX-RZV-ER-01-REQ0066]

3. Puede pasarse a modo semiautomático en todo momento. [XXXXX-RZV-ER-01-REQ0067]

4. Los semáforos posteriores a las formaciones se encuentran en rojo a la espera de la

aceptación de la ruta. [XXXXX-RZV-ER-01-REQ0068]

5. El doble recubrimiento se mantiene para proteger la formación hacia atrás.


6. Admite recepción de rutas, que pueden ser aceptadas o rechazadas según el estado actual

del señalamiento. [XXXXX-RZV-ER-01-REQ0070]

7. Admite cancelación de rutas en un tiempo determinado, posterior al cual se continúa la

ejecución de las mismas. [XXXXX-RZV-ER-01-REQ0071]

9. Solicitud de rutas

1. Solo pueden solicitarse rutas en modo semiautomático. [XXXXX-RZV-ER-01-REQ0072]

2. Las peticiones de rutas en modo automático son desechadas. [XXXXX-RZV-ER-01-REQ0073]

3. Las rutas se piden de un semáforo inicial a otro semáforo final en el mismo sentido de

circulación, siempre posterior, sea consecutivo o no. [XXXXX-RZV-ER-01-REQ0074]

4. Las rutas para cambio de vía son compuestas: primero se solicita la ruta hasta el semáforo

inmediatamente posterior al cruce y luego desde el semáforo de maniobras hasta el próximo

Página 15 de 35




semáforo de la vía opuesta. [XXXXX-RZV-ER-01-REQ0075]

5. Toda ruta puede ser rechazada si el estado actual del señalamiento no admite una

configuración segura que satisfaga el pedido. [XXXXX-RZV-ER-01-REQ0076]

6. Toda ruta aprobada tiene un tiempo de cancelación de X segundos [TBD] en el cual el

operador puede solicitar la anulación de la misma. [XXXXX-RZV-ER-01-REQ0077]

7. La anulación de una ruta implica que todos los semáforos de hasta X [TBD] circuitos de vías

adyacentes sean puestos en aspecto rojo, para contemplar la deriva de la formación.


Página 16 de 35




5. Entregables principales del proyecto

Se entregará la documentación del sistema y subsistemas que incluya:

1. Documentación de la ingeniería conceptual e ingeniería básica.

2. Diagrama de arquitectura y relación entre subsistemas.

3. Reporte de ensayos de subsistemas y del sistema en general.

4. Generador automático de código en VHDL.

5. Prototipo en plataforma de desarrollo FPGA.

6. Paper en formato IEEE para ser presentado en un congreso de la especialidad.

6. Desglose del trabajo en tareas

1. Investigación de estado del arte (60 hs)

1.1. Investigar y relevar sistemas de enclavamientos (20 hs)

1.2. Generar análisis comparativo entre empresas (20 hs)

1.3. Generar análisis comparativo entre tecnologías (20 hs)

2. Ingeniería conceptual (70 hs)

2.1. Identificar y caracterizar elementos de cada subsistema (10 hs)

2.2. Describir la interacción entre los subsistemas (10 hs)

2.3. Desarrollar un diagrama de bloques de los aspectos más importantes (10 hs)

2.4. Identificar y desarrollar los aspectos de normativa y regulaciones relacionadas (10 hs)

2.5. Listas posibles materiales para la construcción del sistema (10 hs)

2.6. Listar posibles ensayos para la prueba de cada subsistema (10 hs)

2.7. Indicar los recursos humanos disponibles para abordar el proyecto (10 hs)

3. Ingeniería básica y requerimientos (20 hs)

3.1. Elaboración de propósito (1 h)

3.2. Definiciones de acrónimos (1 h)

3.3. Perspectiva del producto(1 h)

3.4. Funciones del producto (1 h)

3.5. Características de los usuarios (1 h)

3.6. Restricciones de diseño (1 h)

3.7. Suposiciones y dependencias (1 h)

3.8. Requisitos futuros (1 h)

3.9. Requisitos específicos (10 hs)

3.9.1. Componentes de hardware (5 hs)

3.9.2. Funciones (5 hs)

3.10. Requisitos de rendimiento, seguridad y otros (2 hs)

4. Ingeniería de la arquitectura del sistema (40 hs)

4.1. Diseño de la capa de lógica (20 hs)

4.1.1. Selección de variables: Tipo, tamaño, orden. (6 hs)

4.1.2. Relación y funciones entre las variables. (4 hs)

4.1.3. Abstracción del hardware (10 hs)

4.2. Diseño de la interfaz entre capa lógica y capa logística (10 hs)

4.3. Diseño de la interfaz entre capa lógica y capa de infraestructura (10 hs)

Página 17 de 35




5. Desarrollo de librería ferroviaria para VHDL (80 hs)

5.1. Diseño de tipos de objetos y tipos de datos (5 hs)

5.2. Diagrama de clases (5 hs)

5.3. Desarrollo de funciones (70 hs)

5.3.1. Funciones de evaluación (10 hs)

5.3.2. Funciones de lectura de tabla de enclavamientos (10 hs)

5.3.3. Funciones de enclavamiento (30 hs)

5.3.4. Funciones de generación de código VHDL (20 hs)

6. Desarrollo de los subsistemas (80 hs)

6.1. Desarrollo de módulo de ocupación (20 hs)

6.2. Desarrollo de módulo de semáforos (20 hs)

6.3. Desarrollo de módulo de pasos a nivel y barreras (20 hs)

6.4. Desarrollo de módulo de máquinas de cambios (20 hs)

7. Desarrollo de las interfaces de comunicaciones (40 hs)

7.1. Desarrollo de interface a capa de infraestructura (20 hs)

7.2. Desarrollo de interface a capa logística (20 hs)

8. Desarrollo de los testbenchs (160 hs)

8.1. Desarrollo de prueba de lectura a capa de infraestructura (10 hs)

8.2. Desarrollo de prueba de lectura a capa logística (10hs)

8.3. Desarrollo de prueba de escritura a capa de infraestructura (10 hs)

8.4. Desarrollo de prueba de escritura a capa logística (10 hs)

8.5. Desarrollo de prueba de ocupación (10 hs)

8.6. Desarrollo de prueba de semáforo en ocupación simple (10 hs)

8.7. Desarrollo de prueba de doble recubrimiento simple (10 hs)

8.8. Desarrollo de prueba de semáforos en ocupación compuesta (10 hs)

8.9. Desarrollo de prueba de doble recubrimiento compuesto (10 hs)

8.10. Desarrollo de prueba de barreras automáticas (10 hs)

8.11. Desarrollo de prueba de máquinas de cambios (10 hs)

8.12. Desarrollo de prueba de modo automático (10 hs)

8.13. Desarrollo de prueba de modo semiautomático (10 hs)

8.14. Desarrollo de prueba de recepción de ruta (10 hs)

8.15. Desarrollo de prueba de cancelación de ruta (10 hs)

8.16. Desarrollo de prueba de maniobra corta (10 hs)

9. Verificación y validación (20 hs)

9.1. Prueba general con todos los testbenchs (10 hs)

9.2. Cálculo de parámetros RAMS (10 hs)

10. Cierre del proyecto (80 hs)

10.1. Redacción de documentación técnica (15 hs)

10.2. Redacción de memoria final (40 hs)

10.3. Entregar memoria final (0 hs)

10.4. Elaborar diapositiva de exposición final (5 hs)

10.5. Entregar diapositiva final (0 hs)

10.6. Redacción de paper para publicación (20 hs)

Página 18 de 35




10.7. Publicar resultados (0 hs)

Cantidad total de horas: 650 hs

7. Diagrama de Activity On Node

Figura 1. Activity-on-node

Todas los tiempos se expresan en horas. Al ser un trabajo de tareas secuenciales, el único camino

visible es el camino crítico.

8. Diagrama de Gantt

Para definir la hoja de ruta del presente proyecto se hizo un estudio exhaustivo del estado del arte

de los enclavamientos electrónicos en el mundo que fue determinante para seleccionar qué

tecnologías y arquitecturas se usan actualmente y sobre qué temas se investiga. Esto abre la

puerta, también, a poder redactar papers académicos sobre el área de aplicación.

Tabla 5. Desglose de tareas EDT Nombre Duración Inicio Fin

1 Sistema de enclavamiento 650hs 03/04 12/05

1.1 Investigación de estado del arte 60hs 03/04 03/15

Página 19 de 35




1.1.1 Investigar y relevar sistemas de enclavamientos 20hs 03/04 03/07

1.1.2 Generar análisis comparativo entre empresas 20hs 03/08 03/11

1.1.3 Generar análisis comparativo entre tecnologías 20hs 03/12 03/15

1.2 Ingeniería conceptual 70hs 04/01 04/13

1.2.1 Identificar y caracterizar elementos de cada subsistema 10hs 04/01 04/02

1.2.2 Describir la interacción entre los subsistemas 10hs 04/03 04/04

1.2.3 Desarrollar un diagrama de bloques 10hs 04/05 04/06

1.2.4 Identificar aspectos de normativa y regulaciones 10hs 04/07 04/08

1.2.5 Listas posibles materiales para la construcción del sistema 10hs 04/09 04/10

1.2.6 Listar posibles ensayos para la prueba de cada subsistema 10hs 04/11 04/12

1.2.7 Indicar los recursos humanos disponibles 10hs 04/12 04/13

1.3 Ingeniería básica y requerimientos 20hs 04/13 04/17

1.3.1 Elaboración de propósito 1h 04/13 04/13

1.3.2 Definiciones de acrónimos 1h 04/13 04/13

1.3.3 Perspectiva del producto 1h 04/13 04/13

1.3.4 Funciones del producto 1h 04/13 04/13

1.3.5 Características de los usuarios 1h 04/14 04/14

1.3.6 Restricciones de diseño 1h 04/14 04/14

1.3.7 Suposiciones y dependencias 1h 04/14 04/14

1.3.8 Requisitos futuros 1h 04/14 04/14

1.3.9 Requisitos específicos 10hs 04/14 04/16

1.3.9.1 Componentes de hardware 5hs 04/14 04/15

1.3.9.2 Funciones 5hs 04/15 04/16

1.3.10 Requisitos de rendimiento, seguridad y otros 2hs 04/16 04/17

1.4 Ingeniería de la arquitectura del sistema 40hs 05/01 05/08

1.4.1 Diseño de la capa de lógica 20hs 05/01 05/04

1.4.1.1 Selección de variables: Tipo, tamaño, orden 6hs 05/01 05/02

1.4.1.2 Relación y funciones entre las variables 4hs 05/02 05/02

1.4.1.3 Abstracción del hardware 10hs 05/03 05/04

1.4.2 Diseño de la interfaz entre capa lógica y capa logística 10hs 05/05 05/06

Página 20 de 35




1.4.3

Diseño de la interfaz entre capa lógica y capa de

infraestructura 10hs 05/07 05/08

1.5 Desarrollo de librería ferroviaria para VHDL 80hs 05/13 05/28

1.5.1 Diseño de tipos de objetos y tipos de datos 5hs 05/13 05/13

1.5.2 Diagrama de clases 5hs 05/14 05/14

1.5.3 Desarrollo de funciones 70hs 05/15 05/28

1.5.3.1 Funciones de evaluación 10hs 05/15 05/16

1.5.3.2 Funciones de lectura de tabla de enclavamientos 10hs 05/17 05/18

1.5.3.3 Funciones de enclavamiento 30hs 05/19 05/24

1.5.3.4 Funciones de generación de código VHDL 20hs 05/25 05/28

1.6 Desarrollo de los subsistemas 40hs 06/10 06/17

1.6.1 Desarrollo de módulo de ocupación 10hs 06/10 06/11

1.6.2 Desarrollo de módulo de semáforos 10hs 06/12 06/13

1.6.3 Desarrollo de módulo de pasos a nivel y barreras 10hs 06/14 06/15

1.6.4 Desarrollo de módulo de máquinas de cambios 10hs 06/16 06/17

1.7 Desarrollo de las interfaces de comunicaciones 20hs 07/01 07/04

1.7.1 Desarrollo de interface a capa de infraestructura 10hs 07/01 07/02

1.7.2 Desarrollo de interface a capa logística 10hs 07/03 07/04

1.8 Desarrollo de los testbenchs 80hs 08/01 08/16

1.8.1 Desarrollo de prueba de lectura a capa de infraestructura 5hs 08/01 08/01

1.8.2 Desarrollo de prueba de lectura a capa logística 5hs 08/02 08/02

1.8.3 Desarrollo de prueba de escritura a capa de infraestructura 5hs 08/03 08/03

1.8.4 Desarrollo de prueba de escritura a capa logística 5hs 08/04 08/04

1.8.5 Desarrollo de prueba de ocupación 5hs 08/05 08/05

1.8.6 Desarrollo de prueba de semáforo en ocupación simple 5hs 08/06 08/06

1.8.7 Desarrollo de prueba de doble recubrimiento simple 5hs 08/07 08/07

1.8.8

Desarrollo de prueba de semáforos en ocupación

compuesta 5hs 08/08 08/08

1.8.9 Desarrollo de prueba de doble recubrimiento compuesto 5hs 08/09 08/09

1.8.10 Desarrollo de prueba de barreras automáticas 5hs 08/10 08/10

1.8.11 Desarrollo de prueba de máquinas de cambios 5hs 08/11 08/11

Página 21 de 35




1.8.12 Desarrollo de prueba de modo automático 5hs 08/12 08/12

1.8.13 Desarrollo de prueba de modo semiautomático 5hs 08/13 08/13

1.8.14 Desarrollo de prueba de recepción de ruta 5hs 08/14 08/14

1.8.15 Desarrollo de prueba de cancelación de ruta 5hs 08/15 08/15

1.8.16 Desarrollo de prueba de maniobra corta 5hs 08/16 08/16

1.9 Verificación y validación 20hs 09/01 09/04

1.9.1 Prueba general con todos los testbenchs 10hs 09/01 09/02

1.9.2 Cálculo de parámetros RAMS 10hs 09/03 09/04

1.10 Cierre del proyecto 330hs 10/01 12/05

1.10.1 Redacción de documentación técnica 15hs 10/01 10/03

1.10.2 Redacción de memoria final 40hs 11/01 11/08

1.10.3 Entregar memoria final 0h 11/08 11/08

1.10.4 Elaborar diapositiva de exposición final 5hs 12/01 12/01

1.10.5 Entregar diapositiva final 0h 12/01 12/01

1.10.6 Redacción de paper para publicación 20hs 12/02 12/05

1.10.7 Publicar resultados 0h 12/05 12/05

Figura 2. Diagrama de Gantt (Etapa I)

Página 22 de 35




Figura 3. Diagrama de Gantt (Etapa II)

Figura 4. Diagrama de Gantt (Etapa III)

Página 23 de 35




Figura 5. Diagrama de Gantt (Etapa IV)

Figura 6. Diagrama de Gantt (Etapa V)

Página 24 de 35




Figura 7. Diagrama de Gantt (Etapa VI)

Figura 8. Diagrama de Gantt (Etapa VII)

Página 25 de 35




Figura 9. Diagrama de Gantt (Etapa VIII)

Página 26 de 35




Figura 10. Diagrama de Gantt (Etapa IX)

Figura 11. Diagrama de Gantt (Etapa X)

Página 27 de 35




9. Matriz de uso de recursos de materiales

Tabla 6. Gestión de recursos materiales

Código WBS

Nombre de la tarea

Recursos requeridos (% referido a las horas de cada etapa)

FPGA Computadora Libros

1.1 Investigación de estado del arte

0% 100% 100%

1.2 Ingeniería conceptual

0% 100% 50%

1.3 Ingeniería básica y requerimientos

0% 100% 50%

1.4 Ingeniería de la arquitectura del sistema

0% 100% 50%

1.5 Desarrollo de librería ferroviaria para VHDL

50% 100% 0%

1.6 Desarrollo de los subsistemas

100% 100% 0%

1.7 Desarrollo de las interfaces de comunicaciones

100% 100% 0%

1.8 Desarrollo de los testbenchs

100% 100% 0%

1.9 Verificación y validación

100% 100% 50%

1.10 Cierre del proyecto

100% 100% 50%

10. Presupuesto detallado del proyecto Tabla 7. Presupuesto detallado del proyecto

# Descripción

Costos directos Costos indirectos

Costo unitario

Cantidad Total (+30% costo directo)

1 FPGA $8.000 1 unidad $8.000 $8.000

2 EDU-CIAA $2.000 1 unidad $2.000 $2.000

3 Mano de obra 1000$/h 650 hs $650.000 $650.000

Sub totales $660.000 $660.000

Total $660.000

Página 28 de 35




La inversión inicial del proyecto es cientos de veces inferior a los 7 millones de dólares que se

requieren para equipar una estación ferroviaria completa según licitaciones de productos

internacionales de marcas reconocidas. Además de otorgar la documentación completa a Trenes

Argentinos, lo que repercutirá a futuro en la evolución constante del proyecto, atado a las

necesidades nacionales.

11. Matriz de asignación de responsabilidades

Tabla 8. Matriz de asignación de responsabilidades

Código WBS

Título de la tarea

Usuario Final Responsable Orientador Impulsor / Orientador/ Cliente

Trenes Argentinos

Martín N. Menéndez

Facundo Larosa

Ariel Lutenberg

1.1 Investigación de estado

del arte

I P A I

1.2 Ingeniería conceptual

I P A I

1.3 Ingeniería básica y

requerimientos

I P A I

1.4 Ingeniería de la

arquitectura del

sistema

I P A I

1.5 Desarrollo de librería

ferroviaria para VHDL

I P A I

1.6 Desarrollo de los

subsistemas

I P A I

1.7 Desarrollo de las

interfaces de

comunicaciones

I P A I

1.8 Desarrollo de los

testbenchs

I P A I

1.9 Verificación y

validación

I P A I

1.10 Cierre del proyecto I P A A

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

Página 29 de 35




C = Consultado

12. Gestión de riesgos Riesgo 1: Pérdida o rotura del kit de desarrollo

● Severidad(S): 9(nueve) ○ Severidad alta, no se podría realizar ninguna prueba.

● Ocurrencia(O): 2(dos) ○ Ocurrencia baja, el kit estará en el domicilio del desarrollador

Riesgo 2: Capacidad o potencia insuficiente para cumplir los requerimientos

● Severidad(S): 7(siete) ○ Severidad alta, algunos requerimientos pueden ser vitales para el éxito del proyecto

● Ocurrencia(O): 6(seis) ○ Ocurrencia media, debido al poco conocimiento sobre FPGAs

Riesgo 3: Imposibilidad de cumplir los plazos planteados

● Severidad(S): 7(siete) ○ Severidad alta, pero pueden refinarse los resultados en una nueva iteración


Riesgo 4: Imposibilidad de alcanzar los requerimientos de seguridad

● Severidad(S): 7(siete) ○ Severidad alta, pero pueden refinarse los resultados en una nueva iteración


Riesgo 5: Falta de recursos humanos y/o tiempo para desarrollo

● Severidad(S): 7(siete) ○ Severidad alta, la falta de tiempo puede repercutir en el recorte de las funcionalidades

● Ocurrencia(O): 3(tres) ○ Ocurrencia baja, utilizando el diagrama de Gantt se pueden visualizar los desvíos en las

tareas con facilidad y evitarlos. Riesgo 6: Pérdida de comunicación con interesados del proyecto

● Severidad(S): 7(siete) ○ Severidad alta, la comunicación con los interesados es necesaria para cumplir todos los

requerimientos establecidos. ● Ocurrencia(O): 5(cinco)

○ Ocurrencia media, con gran parte de los interesados ya se tiene un vínculo previo. Riesgo 7: Imposibilidad de sintetizar el circuito óptimo

● Severidad(S): 8(ocho) ○ Severidad alta, el tener que generar el circuito lógico a mano (aún cuando no sea en su

totalidad) puede repercutir negativamente en la performance ● Ocurrencia(O): 2(dos)

Página 30 de 35




○ Ocurrencia baja, los circuitos a generar son simples, gran parte de la seguridad radica en la redundancia que el programa anulará, pero puede replicarse manualmente.

Riesgo 8: Falta de tiempo para adquirir los conocimientos necesarios

● Severidad(S): 7(siete) ○ Severidad alta, puede repercutir en un bajo cumplimiento de los requerimientos

● Ocurrencia(O): 2(dos) ○ Ocurrencia baja, por experiencias anteriores se puede afirmar que se dominarán las

herramientas en el tiempo establecido Riesgo 9: Impracticabilidad de las metodologías para alcanzar elevados niveles de seguridad

● Severidad(S): 9(nueve) ○ Severidad alta, puede repercutir negativamente en el trabajo para la maestría

● Ocurrencia(O): 3(tres) ○ Ocurrencia baja, se tienen las pautas para desarrollar correctamente bajo la metodología

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

Tabla 9. Matriz de gestión de riesgos

Riesgo Severidad Ocurrencia RPN Severidad* Ocurrencia* RPN*

1 9 2 18

2 7 6 42 6 5 30

3 7 6 42 6 5 30

4 7 6 42 6 5 30

5 7 3 21

6 7 5 35

7 8 2 16

8 7 2 14

9 9 3 27

Criterio adoptado: Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores a 40 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 2: Capacidad o potencia insuficiente para cumplir los requerimientos Medida de mitigación: Conseguir un kit de desarrollo más potente.

● Severidad(S): 6(seis) ○ Severidad media, algunos requerimientos pueden ser vitales para el éxito del proyecto

● Ocurrencia(O): 5(cinco)

Página 31 de 35




○ Ocurrencia media, debido al poco conocimiento sobre FPGAs

Riesgo 3: Imposibilidad de cumplir los plazos planteados Medida de mitigación: Consultar a otros profesionales, monitorear con frecuencia las horas empleadas y las definidas en el diagrama de Gantt, incrementar la cantidad de horas laborales.

● Severidad(S): 6(seis) ○ Severidad media, pero pueden refinarse los resultados en una nueva iteración

● Ocurrencia(O): 5(cinco) ○ Ocurrencia media, debido al poco conocimiento sobre FPGAs

Riesgo 4: Imposibilidad de alcanzar los requerimientos de seguridad Medida de mitigación: Conseguir a otros profesionales, asesorarse en la temática de seguridad ferroviaria, seguir metodologías probadas y adoptar una arquitectura con mayor fiabilidad y escalable.

● Severidad(S): 6(seis) ○ Severidad media, pero pueden refinarse los resultados en una nueva iteración

● Ocurrencia(O): 5(cinco) ○ Ocurrencia media, debido al poco conocimiento sobre FPGAs

13. Gestión de la calidad

13.1 Verificación

El plan de verificación estará compuesto por el conjunto de pruebas unitarias para cada módulo, previstas en la etapa VIII: del proyecto “Desarrollo de los testbenchs”, presentado en la Tabla 10. La responsabilidad de definir y realizar las pruebas será de Martín Menéndez, con la asistencia y aprobación de su codirector Facundo Larosa.

Tabla 10. Etapa de verificación 1.8 Desarrollo de los testbenchs 80hs

1.8.1 Desarrollo de prueba de lectura a capa de infraestructura 5hs

1.8.2 Desarrollo de prueba de lectura a capa logística 5hs

1.8.3 Desarrollo de prueba de escritura a capa de infraestructura 5hs

1.8.4 Desarrollo de prueba de escritura a capa logística 5hs

1.8.5 Desarrollo de prueba de ocupación 5hs

1.8.6 Desarrollo de prueba de semáforo en ocupación simple 5hs

1.8.7 Desarrollo de prueba de doble recubrimiento simple 5hs

13.2 Validación

El plan de validación estará compuesto por el conjunto de pruebas de integración para cada módulo, previstas en la etapa IX homónima del proyecto, como se presenta en la Tabla 11.

Página 32 de 35




Tabla 11. Etapa de validación 1.9 Verificación y validación 20hs

1.9.1 Prueba general con todos los testbenchs 10hs

1.9.2 Cálculo de parámetros RAMS 10hs

14. Comunicación del proyecto El plan de comunicación del proyecto es el presentado en la Tabla 12:

Tabla 12. Plan de comunicación del proyecto

PLAN DE COMUNICACIÓN DEL PROYECTO

¿Qué comunicar?

Audiencia Propósito Frecuencia Método de comunicación

Responsable

Plan de proyecto

Curso MSE,jurado de tesis,director de proyecto

Dar a conocer la temática del proyecto,

los alcances y estrategias abordadas

Una vez Presentación en clase

Martín Menéndez

Informe de avance

Jurado de tesis,director de proyecto

Dar a conocer el estado actual del desarrollo del

proyecto

Una vez Email Martín Menéndez

Memoria de proyecto final

Jurado de tesis,director de proyecto

Dar a conocer la memoria final del

proyecto

Una vez Email Martín Menéndez

Presentación de proyecto

final

Audiencia pública

Dar a conocer a los asistentes el estado

final del proyecto para la especialización

Una vez Audiencia pública Martín Menéndez

15. Gestión de Compras Al ya disponer de los elementos necesarios como computadora, EDU-CIAA y el kit de desarrollo FPGA; el presente proyecto no presentará un plan de compras.

16. Seguimiento y control El grado de avance se indicará según las escalas del Microsoft Project Studio:

1. 0%: Tarea sin comenzar 2. 25%: Tarea iniciada 3. 50%: Tarea avanzada en fase de depuración 4. 75%: Tarea completada sin documentación 5. 100%: Tarea finalizada

Página 33 de 35




Tabla 13. Plan de seguimiento de avance

SEGUIMIENTO DE AVANCE

Tarea del WBS

Indicador de avance

Frecuencia de reporte

Responsable de seguimiento

Persona a ser informada

Método de comunicación

Fase I Porcentaje Cada 1 semana

Martín Menéndez

Ariel Lutenberg, Facundo Larosa

email

Fase II Porcentaje Cada 2 semanas

Martín Menéndez


email

Fase III Porcentaje Cada 2 semanas

Martín Menéndez


email

Fase IV Porcentaje Cada 2 semanas

Martín Menéndez


email

Fase V Porcentaje Cada 2 semanas

Martín Menéndez


email

Fase VI Porcentaje Cada 2 semanas

Martín Menéndez


email

Fase VII Porcentaje Cada 2 semanas

Martín Menéndez


email

Fase VIII Porcentaje Cada 2 semanas

Martín Menéndez


email

Fase IX Porcentaje Cada 2 semanas

Martín Menéndez


email

Fase X Porcentaje Cada 2 semanas

Martín Menéndez


email

17. Procesos de cierre Se realizarán las comparaciones entre el resultado obtenido y lo inicialmente proyectado, entre ellas:

1. Grado de complimiento de los requerimientos 2. Grado de acierto entre las horas definidas por tarea y las que realmente se emplearon 3. Riesgos previstos que fueron sorteados 4. Riesgos no previstos a considerar en próximas actualizaciones 5. Efectividad de la estrategia de comunicación 6. Tareas secuenciales que pudieron ser paralelizables

Página 34 de 35




7. Rediseños por un mal planteo inicial de las estrategias 8. Rediseños por malas interpretaciones de las normas 9. Aprendizaje final en base a los errores cometidos

Se guardarán los documentos utilizados (normas, artículos consultados) , así como la documentación intermedia o final generada de forma de facilitar su mantenibilidad a futuro. Se resguardará la misma por medio de una copia de seguridad física y en la nube.

Página 35 de 35

Date post:	15-Feb-2021
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Sistema de enclavamiento en FPGA con altos niveles de...

Documents