Privado:Trazabilidad completa

Privado: Trazabilidad completa

1. Objeto

Garantizar la trazabilidad completa de cada medición de temperatura desde su origen (sensor) hasta su almacenamiento final en la base de datos, conservando el vínculo inequívoco con el sensor (SN), fecha y hora, ubicación física, versión de firmware/software y configuración vigente en el momento de la medición.

2. Alcance

Aplica a todos los sensores gestionados por PiTemp 2.0 y a los componentes implicados en la cadena de datos:

• Sensores y gateways Zigbee (emisión cifrada).
• Servidor local (broker MQTT cifrado).
• Servidor central y base de datos (Home Assistant / PostgreSQL).
• Registro maestro de sensores y auditoría de configuración.

3. Definición operativa de «trazabilidad completa»

Se considera que una medición tiene trazabilidad completa cuando se puede reconstruir, sin ambigüedades:

1. Quién midió → SN del sensor y su entidad lógica en PiTemp2.0.
2. Cuándo midió → timestamp con sello horario (UTC y local), desvío controlado.
3. Dónde midió → ubicación física (zona/sala/equipo) vigente en ese instante.
4. Con qué midió → modelo, versión de firmware, clase del sensor y estado de verificación/calibración al día.
5. Cómo viajó y se custodió → logs originales firmados (*.log.signed) y encadenados; almacenamiento en BD; política de copias.

4. Fuentes de datos

• Logs firmados (*.log.signed): contienen entity_id textual (con “SN: xxxxxxxx”), state, last_updated_ts y SHA/HMAC.
• Base de datos PiTemp2.0: tablas de histórico y de metadatos de los sensores.
• Registro maestro de sensores.
• Auditoría de configuración.

5. Procedimiento de trazabilidad

• Ingesta y firmado

  Los mensajes de cada sonda se importan y se firman, añadiendo SHA/HMAC canónico que garantiza la trazabilidad al dato original.

• Persistencia en PiTemp2.0

  La lectura llega a la base de datos con la relación a los metadatos de cada uno de los sensores y se persiste de manera inmutable por los usuarios. 

• Vinculación con registro maestro

  Se verifica que el número de serie del sensor exista en el registro maestro con ubicación, instalador, última verificación y firmware vigentes (ver § 7.1).

• Consolidación

  Para auditoría, se genera un fichero de verificación (véase documento de Integridad) y un reporte de trazabilidad con las uniones y campos clave.

6. Validaciones automáticas (diarias)

Ver:

Integridad de datos

7. Datos de soporte (modelo sugerido)

7.1 Registro maestro de sensores (tabla interna)

CREATE TABLE IF NOT EXISTS pitemp_registry (

 sn                  text PRIMARY KEY,
 model               text NOT NULL,
 class               text NOT NULL,              -- p.ej. 'Clase 1'
 firmware_version    text NOT NULL,
 location            text NOT NULL,              -- ubicación física
 installer           text NOT NULL,
 active              boolean NOT NULL DEFAULT true,
 last_verification_date date NOT NULL,          -- verificación UNE-EN 13486
 verification_cert_id text,                     -- referencia a informe interno
 notes               text

);

7.2 Auditoría de configuración (histórico por sensor)

CREATE TABLE IF NOT EXISTS pitemp_sensor_config_audit (

 sn            text NOT NULL,
 valid_from    timestamptz NOT NULL,
 valid_to      timestamptz,
 location      text,
 firmware_version text,
 installer     text,
 change_note   text,
 PRIMARY KEY (sn, valid_from)

);

8. Parámetros del ensayo

Parámetro	Descripción	Valor actual
Ventana temporal de correlación	Búsqueda de lectura HA más cercana	±120 s
Muestras por archivo	Lecturas aleatorias verificadas por día y cliente	5
Retención de datos	Conservación en BD principal	5 años
Tolerancia lógica	SN único y activo en registro maestro	Obligatorio

9. Criterios de aceptación

• 100 % de las muestras con SN válido deben resolverse a una entidad de temperatura en HA.
• 100 % de las muestras correladas deben presentar campos mínimos (state, ts) y enlazar con el registro maestro.
• Ubicación y configuración (firmware) vigentes en la fecha del dato (según auditoría de configuración).
• Las entradas sin SN (sensores de prueba o transitorios) se registran como no conformidad explicable y no bloquean el lote si están documentadas.

10. Evidencias generadas

• Archivos .log.signed.verified con detalle de correlación log ↔ HA (véase Integridad).
• Reporte de trazabilidad (JSON/CSV) con: SN, entity_id, ts_log, ts_ha, location, firmware, verification_cert_id.
• Extractos SQL firmados (hash) de los cruces críticos (muestras del día).
• Logs de proceso con sello temporal.

11. Gestión de no conformidades

• Sin SN en el log → etiquetar como test_or_unidentified_sensor y abrir incidencia si persiste >24 h.
• SN no registrado → alta urgente en pitemp_registry y asociación de ubicación/instalador.
• Verificación caducada (≥12 meses) → bloquear aceptación de lecturas hasta re-verificación o justificar.
• Inconsistencia de ubicación/firmware → registrar cambio retroactivo en pitemp_sensor_config_audit con evidencia.

12. Mantenimiento y revisiones

• Revisión mensual de cobertura (porcentaje de líneas con SN).
• Revisión trimestral del pitemp_registry y certificados de verificación.
• Prueba anual de restore (muestra) para confirmar trazabilidad bajo contingencia.

13. Control de cambios de este documento

Versión	Fecha	Autor	Cambios
1.0	16 diciembre 2025	Responsable SW	Versión inicial del método de trazabilidad completa.