Diferencia entre revisiones de «Privado:Trazabilidad completa»

De PiTemp 2.0
Ir a la navegación Ir a la búsqueda
← Edición anterior
VisualWikitexto
 
(No se muestran 6 ediciones intermedias del mismo usuario)
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.
 
Se incorpora el control del '''Registro maestro de sensores''', que documenta la correspondencia entre el número de serie físico, la ubicación instalada, la fecha de calibración y el instalador responsable.
 
Este método de ensayo está asociado al punto '''2 — Trazabilidad Completa''' del [[Privado:Plan de Ensayos de Software PiTemp2.0|Plan de Ensayos de Software PiTemp 2.0]].


== 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 puertas de enlace.
* Servidor local (broker MQTT cifrado).
* Servidor local.
* Servidor central y base de datos (Home Assistant / PostgreSQL).
* Servidor central.
* Registro maestro de sensores y auditoría de configuración.
* Sistema de gestión y verificación de sensores de 3innova.
 
* Incluye la base de datos donde se consolida la trazabilidad metrológica (n.º de serie → etiqueta/ubicación → fecha de verificación → certificado → estado).
== 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 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: 
{| class="wikitable"
|'''[[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 ==
== 3. Descripción general ==
{| class="wikitable"
Cada medición registrada por PiTemp 2.0 queda asociada a:
! Parámetro !! Descripción !! Valor actual
* Un número de serie (SN) único.
|-
* Una marca de tiempo exacta (UTC y local).
| Ventana temporal de correlación || Búsqueda de lectura HA más cercana || ±120 s
* La ubicación física declarada del sensor.
|-
* La versión de firmware o configuración activa.
| Muestras por archivo || Lecturas aleatorias verificadas por día y cliente || 5
* El registro original firmado y almacenado en el sistema de logs.
|-
* Cada sensor mantiene su '''histórico de verificaciones y calibraciones'''; las relaciones entre sensores sustituidos o reasignados quedan documentadas en la trazabilidad.
| 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 ==
== 4. Procedimiento ==
* 100 % de las muestras con ''SN'' válido deben resolverse a una '''entidad de temperatura''' en HA.
# Cada mensaje emitido por un sensor se almacena con su número de serie, valor medido y sello horario.
* 100 % de las muestras correladas deben presentar campos mínimos (''state'', ''ts'') y enlazar con el '''registro maestro'''.
# El registro se guarda de forma inmutable en el sistema central (firmado con SHA256).
* Ubicación y configuración (firmware) vigentes en la fecha del dato (según auditoría de configuración).
# La verificación automática (ver [[Privado:Metodo de Ensayo Integridad de Datos|método de integridad]]) comprueba que el valor registrado coincide con el almacenado.
* Las entradas sin ''SN'' (sensores de prueba o transitorios) se registran como '''no conformidad explicable''' y no bloquean el lote si están documentadas.
# 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.
# Mensualmente se ejecuta una '''revisión automática del registro maestro''', comprobando que todos los sensores activos mantienen trazabilidad completa y certificados vigentes.
# Las actualizaciones manuales del maestro quedan restringidas al personal autorizado y registradas en un log de auditoría.


== 10. Evidencias generadas ==
== 5. Criterios de aceptación ==
* Archivos '''.log.signed.verified''' con detalle de correlación log ↔ HA (véase Integridad).
* 100 % de las lecturas deben vincularse a un número de serie válido.
* Reporte de trazabilidad (JSON/CSV) con: ''SN, entity_id, ts_log, ts_ha, location, firmware, verification_cert_id''.
* 100 % de los sensores activos deben tener registrada su ubicación y configuración vigente.
* Extractos SQL firmados (hash) de los cruces críticos (muestras del día). 
* Las fechas de verificación deben estar dentro del periodo anual establecido.
* Logs de proceso con sello temporal.
* Cada sensor debe poseer un registro maestro único con correspondencia exacta entre SN ↔ entidad ↔ ubicación.
* Las lecturas sin trazabilidad completa (por ejemplo, sensores de prueba) deben quedar documentadas como no conformidades explicables.


== 11. Gestión de no conformidades ==
== 6. Evidencias generadas ==
* '''Sin SN''' en el log → etiquetar como ''test_or_unidentified_sensor'' y abrir incidencia si persiste >24 h.
* Registros firmados con número de serie y sello horario.
* '''SN no registrado''' → alta urgente en ''pitemp_registry'' y asociación de ubicación/instalador.
* Archivos verificados que confirman la correspondencia registros ↔ base de datos.
* '''Verificación caducada''' (≥12 meses) → bloquear aceptación de lecturas hasta re-verificación o justificar.
* Certificados de verificación y calibración de cada sensor emitidos por 3innova.
* '''Inconsistencia de ubicación/firmware''' → registrar cambio retroactivo en ''pitemp_sensor_config_audit'' con evidencia.
* Informes automáticos de trazabilidad disponibles para auditoría.
* Exportación del registro maestro con hash SHA-256 firmado y fechado.


== 12. Mantenimiento y revisiones ==
== 7. Gestión de no conformidades ==
* Revisión mensual de cobertura (porcentaje de líneas con SN).
* Sensor sin número de serie: clasificado como “sensor de prueba” y excluido del control.
* Revisión trimestral del ''pitemp_registry'' y certificados de verificación.
* Sensor no verificado en plazo: debe suspender su validez metrológica hasta nueva verificación.
* Prueba anual de restore (muestra) para confirmar trazabilidad bajo contingencia.
* Desviaciones o cambios de ubicación no documentados: registro correctivo inmediato.
* Toda acción correctiva queda registrada en el log de control de trazabilidad y validada en la siguiente verificación periódica.


== 13. Control de cambios de este documento ==
== 8. Conclusión ==
{| class="wikitable" style="width:100%; text-align:left;"
El sistema PiTemp 2.0 mantiene '''trazabilidad metrológica completa y documentada''' para cada medición, asegurando la identificación del origen, momento, ubicación y configuración conforme al '''Apéndice II del Anexo XI de la Orden ICT/155/2020''' y a los requisitos de '''UNE-EN 12830:2019'''.
! Versión !! Fecha !! Autor !! Cambios
|-
| 1.0 || {{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} || Responsable SW || Versión inicial del método de trazabilidad completa.
|}

Revisión actual - 12:55 27 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.

Se incorpora el control del Registro maestro de sensores, que documenta la correspondencia entre el número de serie físico, la ubicación instalada, la fecha de calibración y el instalador responsable.

Este método de ensayo está asociado al punto 2 — Trazabilidad Completa del Plan de Ensayos de Software PiTemp 2.0.

2. Alcance

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

  • Sensores y puertas de enlace.
  • Servidor local.
  • Servidor central.
  • Sistema de gestión y verificación de sensores de 3innova.
  • Incluye la base de datos donde se consolida la trazabilidad metrológica (n.º de serie → etiqueta/ubicación → fecha de verificación → certificado → estado).

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.
  • Cada sensor mantiene su histórico de verificaciones y calibraciones; las relaciones entre sensores sustituidos o reasignados quedan documentadas en la trazabilidad.

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.
  6. Mensualmente se ejecuta una revisión automática del registro maestro, comprobando que todos los sensores activos mantienen trazabilidad completa y certificados vigentes.
  7. Las actualizaciones manuales del maestro quedan restringidas al personal autorizado y registradas en un log de auditoría.

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.
  • Cada sensor debe poseer un registro maestro único con correspondencia exacta entre SN ↔ entidad ↔ ubicación.
  • Las lecturas sin trazabilidad completa (por ejemplo, sensores de prueba) deben quedar documentadas como no conformidades explicables.

6. Evidencias generadas

  • Registros firmados con número de serie y sello horario.
  • Archivos verificados que confirman la correspondencia registros ↔ 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.
  • Exportación del registro maestro con hash SHA-256 firmado y fechado.

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.
  • Toda acción correctiva queda registrada en el log de control de trazabilidad y validada en la siguiente verificación periódica.

8. Conclusión

El sistema PiTemp 2.0 mantiene trazabilidad metrológica completa y documentada para cada medición, asegurando la identificación del origen, momento, ubicación y configuración conforme al Apéndice II del Anexo XI de la Orden ICT/155/2020 y a los requisitos de UNE-EN 12830:2019.

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