2014 Integración en TCE pozo fecales de parque Sta Maria

Descripción del proyecto

Plazos y organigrama

Identificación de Tareas

• Determinar cómo leer exactamente siguiendo el protocolo
• Implementar la lectura de los bloques de memoria de la controladora que resulten de interés.
• Comprobar que el software hasta este punto es estable y no se detectan problemas de comunicación con el equipo achacables al mismo (cuelgues de la Mocsa…)
• Implementación de trazas que hagan posible el seguimiento de las lecturas.
• Acudir a la instalación con Sulzer para realizar batería de

• Modificar el software del interfaz de usuario para que pueda albergar las nuevas señales no centralizadas con anterioridad en otras instalaciones
• Asociar el interfaz al nuevo driver
• Ejercitar las señales con el nuevo driver y el nuevo interfaz con simulación de señales
• Ejercitar las señales con el nuevo driver y el nuevo interfaz con señales reales en instalación
• Puesta en marcha.

Modelo de Datos

Eventos

• En la semana del 9/5 Luis Lorido comienza a intentar comunicar sin éxito con el autómata y obtener algún documento con el mapa de memoria.

• El 11 de Mayo se produce la primera reunión de arranque de este proyecto. Llevamos a esta reunión una serie de preguntas técnicas sobre la lectura de las diferentes zonas de memoria:

• 1ª comprobar lecturas y detección de cambios en cualquier zona del mapa de memoria
• 2ª comprobar con interfaz de usuario de TCE que las señales están bien centralizadas.

• 21-5 La controladora está disponible en la red.

• 22,23,24 y 25 de Mayo

• 27-5 Recibimos documento con la lista de señales y su descripción funcional.

• 28-5 Recibimos respuesta de la pregunta sobre los Text-Address.

• 3-6 Se realizan las primeras pruebas conjuntas con Sulzer (Ana y Alejandro). Se intentan leer todos los registros y que nos comenten qué lecturas son interesantes. Descubrimos que hay un bloque que no leemos pero diagnosticamos por qué.

• 4/6 Se revisa el diseño y se planifican las nuevas tareas:

1. 4/6 Corregir lectura del bloque que no se ha conseguido en las pruebas
2. 5/6 a 11/6 Modificar el UI para que incluya las nuevas señales
3. 5/6 a 11/6 Probar implementación del driver para que hable con el ui de forma simulada
4. 12/6 Pruebas de carga de software y de funcionalidad in situ
5. 13/6 Puesta en marcha y comienzo de garantía

• 6/6 Quedamos con Sulzer para probar de nuevo la lectura del bloque que se comprobó incorrecto el día 3. Sulzer nos responde a preguntas sobre eventos que le hicimos el día 3.

• 10/6 Nos reunimos Luis y yo para seguimiento del proyecto. Este es el resumen:

1. Corregir lectura del bloque que no se ha conseguido en las pruebas : Está corregido.
2. 5/6 a 11/6Modificar el UI para que incluya las nuevas señales : Está hecho y valdría para puesta en marcha pero propongo una mejora.
3. 5/6 a 11/6 Probar implementación del driver para que hable con el ui de forma simulada : Se realizará en la jornada de hoy.
4. 12/6 Pruebas de carga de software y de funcionalidad in situ : Se realizarán mañana.

• 12/6

• 13/6 Escribimos un correo a Metro para comunicar que el software está en modo prueba en la instalación y qe faltan los eventos en BDD y que ya diremos cuando podemos fijar una fecha para la puesta en marcha.

1. En la semana del 16 al 20 de junio se procurará recopilar todos los documentos de final de proyecto (Guía del Software, Documentación del software, Manual de usuario...)
2. En la misma semana se conseguirá cerrar y subir la versión primera al git para su almacenamiento.
3. Hacer las anotaciones de Eventos pertinentes a la BDD y comprobar su buen funcionamiento
4. Hacer un pequeño documento que contenga el .h y explique mínimamente como se guardan los datos.
5. Abrir un nuevo proyecto en el doxygen para acomodar los comentarios realizados o por realizar en el software de modo que se obtenga el documento técnico del desarrollo

• 25/6 Está todo terminado a falta de la versión de InformesTCE que permita consultar los eventos del pozo.
• 3/7 Metro nos convoca para una recepción. Llevamos plantilla. Se encuentran los siguientes defectos:

1. Tenemos que documentar cómo ocurren los bloqueos individuales y de las 2 bombas a la vez.
2. Cambiar el texto de NO_AUTO a NO AUTOMÁTICO
3. Cambiar el texto de la alarma asociada al estado NO_AUTO a “Bomba A NO automático”
4. Cambiar texto de No Reconocida a “NO reconocida”
5. Eliminar señal de “Alarma Activa” y eliminar “Nuevo Defecto”
6. Bombas en UI. Hay que poner “Estado : Funcionando o Parada”
7. Modificar la plantilla para incluir la señal de “Sin Comunicación”
8. Necesitamos confirmación expresa de Sulzer de que la posición del selector “Manual” que es cuando el tipo acciona las bombas localmente no pasa por la controladora, es decir, no podemos centralizarla.
9. Recoger eventos de InformesTCE
10. Recoger el log
11. Corregir la detección del estado “Sin Comunicación”
12. Colocar en el UI el panel “Sin Comunicación”

1. Se detecta el error de reseteo total de las alarmas cuando se pulsa el botón rojo (Luis documenta este error)

• 7/7 Todas las tareas derivadas de las pruebas del día 3 están terminadas. Se generan nueva tareas

1. Modificar la plantilla para probar lo que se ha arreglado
2. Volver a probar con Sulzer y quizá después con Metro

• 8/7 Sulzer explica el significado del "error" que se detecto en la controladora y metro llega a la conclusión de que no es tal error y que hay que quitar la señal

• 11/7 Metro convoca la recepción final el 17/7.
• 17/7 Se realizan las pruebas finales y la recepción.

• 21/7 Lo que se anota como pendiente para SICOSOFT en el documento interno de acta está resuelto (tengo correo de Luis).

• 23/7 Recibimos correo de Sulzer dando su conformidad a los trabajos y aceptando la facturación. Nos pide la documentación final.

• 24/7 Enviamos documentación final