Diferencia entre revisiones de «Privado:Trazabilidad completa»

De PiTemp 2.0
Ir a la navegación Ir a la búsqueda
← Edición anteriorEdición siguiente →
VisualWikitexto
Línea 2: Línea 2:


== 1. Objeto ==
== 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.
Garantizar la trazabilidad completa de cada medición de temperatura desde el sensor hasta su almacenamiento final, conservando el vínculo inequívoco con el número de serie, fecha, ubicación y configuración vigente.


== 2. Alcance ==
== 2. Alcance ==
Aplica a todos los sensores gestionados por PiTemp 2.0 y a los componentes implicados en la cadena de datos:
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).
* Sensores y gateways Zigbee.
* Servidor local (broker MQTT cifrado).
* Servidor local (MQTT cifrado).
* Servidor central y base de datos (Home Assistant / PostgreSQL).
* Servidor central (base de datos PostgreSQL).
* Registro maestro de sensores y auditoría de configuración.
* Sistema de gestión y verificación de sensores de 3innova.


== 3. Definición operativa de «trazabilidad completa» ==
== 3. Descripción general ==
Se considera que una medición tiene trazabilidad completa cuando se puede reconstruir, sin ambigüedades:
Cada medición registrada por PiTemp 2.0 queda asociada a:
# '''Quién''' midió → ''SN'' del sensor y su entidad lógica en PiTemp2.0.
* Un número de serie (SN) único.
# '''Cuándo''' midió → ''timestamp'' con sello horario (UTC y local), desvío controlado.
* Una marca de tiempo exacta (UTC y local).
# '''Dónde''' midió → ''ubicación física'' (zona/sala/equipo) vigente en ese instante.
* La ubicación física declarada del sensor.
# '''Con qué''' midió → ''modelo'', ''versión de firmware'', ''clase del sensor'' y ''estado de verificación/calibración'' al día.
* La versión de firmware o configuración activa.
# '''Cómo viajó y se custodió''' → logs originales firmados (''*.log.signed'') y encadenados; almacenamiento en BD; política de copias.
* El registro original firmado y almacenado en el sistema de logs.


== 4. Fuentes de datos ==
== 4. Procedimiento ==
* '''Logs firmados''' (*.log.signed): contienen ''entity_id'' textual (con “SN: xxxxxxxx”), ''state'', ''last_updated_ts'' y ''SHA''/''HMAC''.
# Cada mensaje emitido por un sensor se almacena con su número de serie, valor medido y sello horario.
* '''Base de datos PiTemp2.0''': tablas de histórico y de metadatos de los sensores.
# El registro se guarda de forma inmutable en el sistema central (firmado con SHA256).
* '''Registro maestro de sensores'''.
# La verificación automática (ver método de integridad) comprueba que el valor registrado coincide con el almacenado.
* '''Auditoría de configuración'''.
# Los metadatos (ubicación, instalador, versión, estado de verificación) se asocian de forma permanente al sensor.
# Cada modificación de configuración o sustitución de sensor genera un nuevo registro de trazabilidad.


== 5. Procedimiento de trazabilidad ==
== 5. Criterios de aceptación ==
* '''Ingesta y firmado'''
* 100 % de las lecturas deben vincularse a un número de serie válido.
  Los mensajes de cada sonda se importan y se firman, añadiendo ''SHA/HMAC'' canónico que garantiza la trazabilidad al dato original.
* 100 % de los sensores activos deben tener registrada su ubicación y configuración vigente.
* '''Persistencia en PiTemp2.0'''
* Las fechas de verificación deben estar dentro del periodo anual establecido.
  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.  
* Las lecturas sin trazabilidad completa (por ejemplo, sensores de prueba) deben quedar documentadas como no conformidades explicables.
* '''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) ==
== 6. Evidencias generadas ==
* Registros firmados (*.log.signed*) con número de serie y sello horario.
* Archivos verificados (*.log.signed.verified*) que confirman la correspondencia log ↔ base de datos.
* Certificados de verificación y calibración de cada sensor emitidos por 3innova.
* Informes automáticos de trazabilidad disponibles para auditoría.


== 7. Gestión de no conformidades ==
* Sensor sin número de serie: clasificado como “sensor de prueba” y excluido del control.
* Sensor no verificado en plazo: debe suspender su validez metrológica hasta nueva verificación.
* Desviaciones o cambios de ubicación no documentados: registro correctivo inmediato.


Ver: 
== 8. Conclusión ==
{| class="wikitable"
El sistema PiTemp 2.0 mantiene trazabilidad completa para cada medición, asegurando la identificación del origen, momento, ubicación y configuración de todos los registros conforme al Apéndice II del Anexo XI de la Orden ICT/155/2020.
|'''[[Privado:Metodo de Ensayo Integridad de Datos|Integridad de datos]]'''
|}
 
== 7. Datos de soporte (modelo sugerido) ==
; 7.1 Registro maestro de sensores (tabla interna)
<code>
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
);
</code>
 
; 7.2 Auditoría de configuración (histórico por sensor)
<code>
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)
);
</code>
 
== 8. Parámetros del ensayo ==
{| class="wikitable"
! 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 ==
{| class="wikitable" style="width:100%; text-align:left;"
! Versión !! Fecha !! Autor !! Cambios
|-
| 1.0 || {{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} || Responsable SW || Versión inicial del método de trazabilidad completa.
|}

Revisión del 15:25 21 oct 2025

Privado: Trazabilidad completa

1. Objeto

Garantizar la trazabilidad completa de cada medición de temperatura desde el sensor hasta su almacenamiento final, conservando el vínculo inequívoco con el número de serie, fecha, ubicación y configuración vigente.

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.
  • Servidor local (MQTT cifrado).
  • Servidor central (base de datos PostgreSQL).
  • Sistema de gestión y verificación de sensores de 3innova.

3. Descripción general

Cada medición registrada por PiTemp 2.0 queda asociada a:

  • Un número de serie (SN) único.
  • Una marca de tiempo exacta (UTC y local).
  • La ubicación física declarada del sensor.
  • La versión de firmware o configuración activa.
  • El registro original firmado y almacenado en el sistema de logs.

4. Procedimiento

  1. Cada mensaje emitido por un sensor se almacena con su número de serie, valor medido y sello horario.
  2. El registro se guarda de forma inmutable en el sistema central (firmado con SHA256).
  3. La verificación automática (ver método de integridad) comprueba que el valor registrado coincide con el almacenado.
  4. Los metadatos (ubicación, instalador, versión, estado de verificación) se asocian de forma permanente al sensor.
  5. Cada modificación de configuración o sustitución de sensor genera un nuevo registro de trazabilidad.

5. Criterios de aceptación

  • 100 % de las lecturas deben vincularse a un número de serie válido.
  • 100 % de los sensores activos deben tener registrada su ubicación y configuración vigente.
  • Las fechas de verificación deben estar dentro del periodo anual establecido.
  • Las lecturas sin trazabilidad completa (por ejemplo, sensores de prueba) deben quedar documentadas como no conformidades explicables.

6. Evidencias generadas

  • Registros firmados (*.log.signed*) con número de serie y sello horario.
  • Archivos verificados (*.log.signed.verified*) que confirman la correspondencia log ↔ base de datos.
  • Certificados de verificación y calibración de cada sensor emitidos por 3innova.
  • Informes automáticos de trazabilidad disponibles para auditoría.

7. Gestión de no conformidades

  • Sensor sin número de serie: clasificado como “sensor de prueba” y excluido del control.
  • Sensor no verificado en plazo: debe suspender su validez metrológica hasta nueva verificación.
  • Desviaciones o cambios de ubicación no documentados: registro correctivo inmediato.

8. Conclusión

El sistema PiTemp 2.0 mantiene trazabilidad completa para cada medición, asegurando la identificación del origen, momento, ubicación y configuración de todos los registros conforme al Apéndice II del Anexo XI de la Orden ICT/155/2020.

Obtenido de «https://clientes.3innova.io/index.php?title=Privado:Trazabilidad_completa&oldid=65»