Privado: Disponibilidad y continuidad

Privado: Disponibilidad y continuidad

1. Objeto

Garantizar que el sistema PiTemp 2.0 mantiene la disponibilidad, continuidad y recuperación de los datos de medición en caso de incidencias, minimizando la pérdida de información y el tiempo de inactividad.

Este método de ensayo está asociado al punto 5 — Disponibilidad y continuidad del Plan de Ensayos de Software PiTemp 2.0.

2. Alcance

Este ensayo cubre la disponibilidad del sistema desde el punto de vista funcional y de datos:

• Servidores centrales de PiTemp 2.0, alojados en centro de proceso de datos (CPD) con infraestructura redundante.
• Servidores locales instalados en las sedes de los clientes.
• Mecanismos de almacenamiento local y reenvío diferido.
• Copias de seguridad y restauración de datos históricos.

3. Principio del sistema

PiTemp 2.0 está diseñado para mantener la integridad y continuidad de los registros incluso ante fallos temporales de red, gracias a un modelo de operación distribuido:

• Cada instalación cliente dispone de un servidor local que recibe los datos de los sensores y los transmite al servidor central.
• En caso de pérdida de conectividad con el servidor central, el sistema local continúa registrando las mediciones en modo autónomo.
• Una vez restaurada la conexión, los datos pendientes se retransmiten automáticamente sin pérdida de información.
• Los registros incluyen sello temporal y firma digital, garantizando la coherencia de la secuencia incluso tras la retransmisión.

4. Limitaciones operativas

• La continuidad del servicio local depende de la infraestructura del cliente (alimentación eléctrica, red interna, router, etc.).
• PiTemp 2.0 no puede mantener la transmisión de datos durante un corte eléctrico total si el cliente no dispone de alimentación de respaldo (SAI o batería).
• Los clientes son responsables de proporcionar los medios de continuidad mínimos para que el servidor local permanezca operativo.
• En caso de parada completa del servidor local, los sensores conservarán la última medición válida hasta que se restablezca el sistema.

5. Procedimiento de verificación

• Ensayo de pérdida de red

  * Se interrumpe la conexión entre el servidor local y el servidor central durante un periodo definido (60 min).
  * Se comprueba que el sistema local continúa registrando mediciones.
  * Tras la reconexión, se verifica la retransmisión automática de los datos pendientes.

• Ensayo de restauración

  * Se simula una restauración de red y se comparan los valores transmitidos con los registros locales.
  * Coincidencia esperada: 100 % de las mediciones generadas durante la desconexión.

• Verificación de copias de seguridad

  * Se comprueba la existencia de backups automáticos en el servidor central y la capacidad de restauración de un conjunto de datos histórico.

6. Criterios de aceptación

• Disponibilidad del servidor central: 99,9% o superior (CPD redundante con monitorización permanente).
• Retransmisión de datos tras fallo de red: 100% de las mediciones recuperadas.
• Intervalo máximo de reenvío tras reconexión: <60s desde el restablecimiento. <24h para poder consultar los datos en la aplicación.
• Respaldo diario automático del sistema central y retención mínima de 5 años.
• En caso de fallo eléctrico completo en el cliente, la responsabilidad de continuidad recae en los medios de respaldo proporcionados por el propio cliente.

7. Evidencias generadas

• Logs de desconexión/reconexión con marca temporal.
• Informe de verificación de retransmisión automática (por muestra).
• Registro de disponibilidad del servidor central (monitorización CPD).
• Registro de backups automáticos y prueba anual de restauración.
• Declaración del responsable técnico confirmando el cumplimiento de los tiempos de recuperación previstos.
• Archivo backup_status.md que resume fechas, tamaño y verificación SHA-256 de las copias de seguridad.

8. Gestión de no conformidades

• Fallo de red prolongado (> 1 h): comunicación al cliente y registro de incidencia.
• Datos no retransmitidos tras reconexión: investigación y reenvío manual.
• Fallo de backup o restauración: corrección inmediata y repetición del proceso.
• Fallo eléctrico sin respaldo: notificación al cliente y exclusión de la medición afectada del expediente.

9. Periodicidad del ensayo

• Ensayo funcional de pérdida y restauración de red: anual.
• Verificación de backups y restauración: trimestral.
• Revisión de disponibilidad del CPD: continua mediante monitorización.

10. Conclusión

PiTemp 2.0 garantiza la continuidad y disponibilidad de los datos mediante almacenamiento local, retransmisión automática y copias de seguridad redundantes en su servidor central. La continuidad ante fallos eléctricos en la instalación cliente depende de las medidas de respaldo implementadas por cada usuario, quedando así delimitadas las responsabilidades entre 3innova y el cliente.

El sistema cumple los criterios de continuidad y recuperación definidos en los apartados 6.3 y 6.5 de la UNE-EN 12830:2019, garantizando la disponibilidad efectiva de los datos en cualquier condición previsible de fallo.