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:
- Quién midió → SN del sensor y su entidad lógica en PiTemp2.0.
- Cuándo midió → timestamp con sello horario (UTC y local), desvío controlado.
- Dónde midió → ubicación física (zona/sala/equipo) vigente en ese instante.
- Con qué midió → modelo, versión de firmware, clase del sensor y estado de verificación/calibración al día.
- 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 sellado
Los mensajes de cada sonda se importan y se sellan en *.log.signed (uno por línea), añadiendo SHA/HMAC canónico.
- 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.
- 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 *.log.signed.verified (véase documento de Integridad) y un reporte de trazabilidad con las uniones y campos clave.
6. Validaciones automáticas (diarias)
- 6.1 Presencia y consistencia de campos mínimos
- • SN extraíble del entity_id del log (regex SN:\s*([A-Za-z0-9]+)).
- • last_updated_ts numérico y convertible a UTC/local.
- • state numérico (temperatura).
- • Existencia de entidad sensor.%SN\_temperature en HA.
- 6.2 Correlación log ↔ HA (muestra aleatoria)
- Para cada muestra (5 por archivo):
-- Parámetros
-- :sn, :ts := last_updated_ts del log (seg), :win := 120
-- 1) Resolver entity_id de temperatura
SELECT entity_id, metadata_id
FROM states_meta
WHERE entity_id ILIKE 'sensor.%' AND entity_id ILIKE '%' || :sn || '\_temperature' ESCAPE '\'
LIMIT 1;
-- 2) Traer la medición más cercana en ±:win
SELECT s.state, s.last_updated_ts
FROM states s
WHERE s.metadata_id = :meta
AND s.last_updated_ts BETWEEN (:ts - :win) AND (:ts + :win)
ORDER BY ABS(s.last_updated_ts - :ts)
LIMIT 1;
- 6.3 Correlación HA ↔ Registro maestro (SN único y vigente)
-
-- El SN debe existir y estar activo
SELECT 1
FROM pitemp_registry
WHERE sn = :sn AND active = TRUE;
-- Ubicación y última verificación dentro de plazo (≤ 12 meses)
SELECT
location, installer, firmware_version, last_verification_date
FROM pitemp_registry
WHERE sn = :sn
AND (now()::date - last_verification_date) <= INTERVAL '365 days';
- 6.4 Coherencia de configuración (histórico)
-
-- Confirmar que en la fecha del log la ubicación/firmware coinciden con lo declarado
SELECT *
FROM pitemp_sensor_config_audit
WHERE sn = :sn
AND valid_from <= to_timestamp(:ts)
AND (valid_to IS NULL OR valid_to >= to_timestamp(:ts))
LIMIT 1;
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. |