Capa de recopilación de datos

Estructura y composición de la capa de recopilación de datos

La capa de recopilación de datos es un componente clave de la Plataforma IIoT que proporciona la integración con los dispositivos. Incluye un conjunto de aplicaciones especializadas, cada una diseñada para interactuar con un tipo concreto de dispositivo IoT (contadores, sensores, etc.). Estas aplicaciones funcionan como servicios de red, gestionando las conexiones entrantes a través de puertos dedicados y administrando la transferencia de datos entre los dispositivos y la plataforma. Esta arquitectura garantiza la escalabilidad y la flexibilidad al trabajar con equipos heterogéneos.

A continuación se resume la estructura y composición de las aplicaciones de la capa de recopilación de datos:

flowchart TD
    A(Household energy meters) <-->|Data transfer| B("Data collection daemon (Type-J)")
    C(Industrial energy meters) <-->|Data transfer| D("Data collection daemon (Type-T)")
    E(Smart sensors) <-->|Data transfer| F("Data collection daemon (DDT)")
    subgraph " "
    B("Data collection daemon (Type-J)") <--> I{"Balancer (Pgbouncer)"}
    D("Data collection daemon (Type-T)") <--> I{"Balancer (Pgbouncer)"}
    F("Data collection daemon (DDT)") <--> I{"Balancer (Pgbouncer)"}
    X@{ shape: braces, label: "Data Polling Subsystem" }
    end
    I{"Balancer (Pgbouncer)"} <--> J[(DBMS PostgreSQL)]

Los intercambios con los dispositivos finales se realizan a través de una conexión TCP, y cada demonio de recopilación implementa su propio protocolo de intercambio de aplicación para atender a un tipo concreto de dispositivo IoT.

Estos demonios comparten varias características arquitectónicas comunes, que se describen a continuación.

Características de la arquitectura

• Cada contenedor incluye una aplicación especializada en un protocolo concreto.
• Se utilizan imágenes base ligeras (alpine en la configuración base) para minimizar la sobrecarga. No obstante, es posible compilar imágenes para el sistema operativo del cliente.
• Para gestionar las dependencias entre servicios (como el acceso a la base de datos), se especifican las secciones depends_on y health-check en Docker Compose.
• Los demonios de compose se ejecutan en varias instancias (réplicas) para distribuir la carga. En este caso, cada demonio de recopilación puede atender decenas de miles de conexiones simultáneamente.
• Un balanceador (HAProxy, Nginx Stream) dirige el tráfico a los demonios disponibles mediante los algoritmos Round Robin o Least Connections.
• En entornos en la nube, se puede añadir el escalado automático basado en métricas (CPU, número de conexiones).
• Toda la comunicación con los dispositivos se registra de forma detallada en archivos, de modo que pueda analizarse en caso de detectarse problemas y fallos.

Principios del intercambio de datos

A continuación se muestra un diagrama de una sesión de comunicación entre un dispositivo IoT y el demonio de recopilación:

sequenceDiagram
    autonumber
    participant D as IoT device
    participant I as Data collection <br/>daemon
    Note over I,D: Stages of interaction
    D->>I: Session start, authentication
    I-->>D: Sending request parameters
    D->>I: Data acquisition
    I-->>D: Sending the next session time

Principios de organización del intercambio de datos:

• Inicio de una sesión de comunicación.
  Una sesión de comunicación siempre la inicia el dispositivo IoT. Tras establecer una conexión con el demonio de recopilación de datos, el dispositivo transmite un paquete de identidad.

• Procedimiento de autenticación
  El demonio de recopilación de datos autentica el dispositivo. Si la autenticación es satisfactoria, realiza:

  • La recuperación de la configuración guardada del dispositivo desde la base de datos.
  • El envío de los ajustes de interfaz actuales al dispositivo.

• Transferencia de datos
  En función de la solicitud recibida, el dispositivo transfiere al servidor de recopilación:

  • Las lecturas actuales del dispositivo.
  • Los registros archivados (si los hay).

• Programación de la siguiente sesión
  Una vez completada la recepción de datos, el demonio de recopilación:

  • Genera la marca de tiempo de la siguiente sesión.
  • Transmite la marca de tiempo de la siguiente sesión al dispositivo.
  • Inicia la terminación de la conexión.

• Procesamiento y almacenamiento de datos
  La información recibida se:

  • Agrega en objetos JSON estructurados.
  • Almacena en una base de datos PostgreSQL intermedia.
  • Formatea según la especificación del protocolo de cada demonio.

• Integración con el sistema de control
  Los datos quedan disponibles para el nivel superior del sistema (subsistema de gestión) para:

  • El procesamiento analítico posterior.
  • La visualización en las interfaces de gestión.
  • La generación de informes automatizados.

Interacción con la capa de gestión de la plataforma

Arquitectura de interconexión de los subsistemas

Los demonios de recopilación de datos se integran con el sistema de nivel superior (capa de gestión) a través de una base de datos intermedia. Para habilitar esta interacción, se utiliza un contenedor Docker con un SGBD PostgreSQL desplegado.

Los resultados de la interacción satisfactoria con los dispositivos los guardan automáticamente los demonios en una tabla especializada de la misma base de datos, lo que aporta transparencia a la transferencia de datos entre el nivel de control y los dispositivos.

El esquema de interacción de los subsistemas se muestra a continuación:

flowchart LR
A@{ shape: procs, label: "Data Polling Subsystem"} -->|Readings data| B[(DBMS PostgreSQL)]
B[(DBMS PostgreSQL)] -->|Configuration| A@{ shape: procs, label: "Data Polling Subsystem"}
B[(DBMS PostgreSQL)] -->|Readings data| C@{ shape: procs, label: "Control Subsystem"}
C@{ shape: procs, label: "Control Subsystem"} -->|Configuration| B[(DBMS PostgreSQL)]

Configuración del dispositivo

La configuración del dispositivo incluye la siguiente información:

• Fechas de las últimas lecturas por archivo: por hora, por día y por mes. Estos parámetros indican la fecha a partir de la cual deben leerse los datos del archivo correspondiente.
• Código del dispositivo de medición (para los dispositivos IoT que utilizan el protocolo Type-T). Este parámetro es obligatorio únicamente para los demonios de recopilación que atienden el protocolo Type-T, e indica al servidor de recopilación qué algoritmo utilizar para trabajar con el dispositivo.
• Velocidad del puerto serie (para los dispositivos IoT que ejecutan el protocolo Type-T). Este parámetro indica al dispositivo IoT a qué velocidad debe comunicarse con el contador. El demonio de recopilación lo envía al comienzo de una sesión de intercambio.
• Programación de la comunicación. El subsistema de gestión guarda todas las programaciones en una base de datos intermedia, y el demonio de recopilación calcula la fecha más próxima a partir de las programaciones recibidas y la envía al dispositivo.
• Comandos de control del dispositivo. Según el tipo de dispositivo IoT y sus capacidades, los comandos de gestión incluyen:
  • Un comando para actualizar el software de la parte de telemetría del dispositivo IoT. Al recibir este comando, el dispositivo descarga el nuevo firmware desde el servidor y realiza la actualización.
  • Un comando para releer la configuración del dispositivo de medición.
  • Un comando para cerrar o abrir la válvula (si existe una válvula y el software del dispositivo IoT la admite).
  • Un comando para establecer los parámetros de funcionamiento del dispositivo de medición (depende del modelo).
  • Un comando para reiniciar el dispositivo IoT.

La parte principal de la configuración del dispositivo se almacena en una base de datos intermedia en formato JSON.

A continuación se muestra un ejemplo de la configuración:

{
  "settings": "1",
  "day_event": 1706140800,
  "hour_event": 1706140800,
  "month_event": 1673857740,
  "net_address": 58
}

Aquí day_event, hour_event y month_event son marcas de tiempo en formato unixtime de los registros guardados más recientemente de los archivos diario, horario y mensual, respectivamente.

Las programaciones se almacenan por separado, también en formato JSON. La cadena de programación en sí se construye y se procesa en formato CRON. Este enfoque proporciona flexibilidad a la hora de configurar y procesar cualquier programación.

A continuación se muestra un ejemplo de almacenamiento de varias programaciones para un dispositivo:

[
  { "crontab": "10 * * * *", "schedule_id": 6 },
  { "crontab": "40 * * * *", "schedule_id": 7 }
]

Según estas programaciones, el dispositivo debe conectarse en los minutos 10 y 40 de cada hora. El propio demonio determina la programación más adecuada en el momento de la comunicación con el dispositivo y transmite la más próxima.