Modelo de dominio

DeviceChain modela el mundo físico con un pequeño conjunto de conceptos componibles. La decisión definitoria es que el contexto del dispositivo se expresa como un grafo de relaciones tipado (typed relationship graph) en lugar de un registro de asignación fijo — lo que mantiene el modelo abierto a nuevos tipos de entidad con el tiempo.

Entidades principales

• Device (Dispositivo) — la cosa que se conecta e informa; una instancia de un tipo de dispositivo.
• Device Type (Tipo de dispositivo) — la capa de taxonomía/identidad: el nombre de una clase de dispositivo, su apariencia (icono y colores) y su clasificación para agrupar y filtrar. Un tipo de dispositivo hace referencia como máximo a un perfil de dispositivo.
• Device Profile (Perfil de dispositivo) — el contrato de capacidades: un agregado distinto y versionado (borrador → publicar → revertir) que posee las definiciones de métrica, comando y regla de detección de una clase de dispositivo. Muchos tipos de dispositivo pueden compartir un mismo perfil — de modo que la configuración de capacidades se define una vez y se reutiliza — y un dispositivo resuelve sus capacidades a través de device → type → profile. Un tipo de dispositivo sin perfil es válido; simplemente clasifica y muestra sus dispositivos sin otorgar un contrato de capacidades tipado.
• Asset (Activo) — la cosa del mundo real que un dispositivo monitorea (categorizada como Device / Person / Hardware).
• Area (Área) — una ubicación espacial/organizacional, opcionalmente con límites poligonales y zonas; las áreas se anidan en jerarquías.
• Customer (Cliente) — un propietario organizacional; los clientes también se anidan en jerarquías.
• Groups (Grupos) — un grupo de entidades uniforme que agrupa cualquiera de las anteriores. La membresía es estática (una lista explícita de miembros) o dinámica — un selector guardado sobre los atributos de los miembros, resuelto en el momento de la lectura (ver Facetas y grupos dinámicos).

Cada una de estas entidades se direcciona de manera uniforme mediante un tipo de entidad + id, lo que permite que las relaciones, los grupos y la indexación de eventos operen de forma genérica sobre todas ellas.

Relaciones

En lugar de vincular un dispositivo a una única asignación fija (customer, area, asset), DeviceChain conecta las entidades con relaciones tipadas y dirigidas:

• Una relación tiene un origen (source), un destino (target) y un tipo de relación.
• Un tipo de relación lleva un indicador Tracked.

El indicador Tracked es central. Cuando un dispositivo informa un evento, la plataforma registra cada una de las relaciones rastreadas del dispositivo como un anclaje (anchor) en ese evento (una entrada (anchor_type, anchor_id) en el conjunto de anclajes del evento). Un dispositivo puede tener varias relaciones rastreadas — un cliente y un área y un activo — y la lectura entonces se puede consultar por cada una de ellas: "cada lectura de temperatura del Edificio 7" y "…del cliente Acme" encuentran ambas esa lectura. Los anclajes se capturan en el momento de la escritura, de modo que el historial permanece intacto cuando un dispositivo se reasigna más tarde.

La asignación organiza; no bloquea. Un dispositivo que tiene credenciales pero aún no está asignado sigue informando telemetría — sus eventos se resuelven con un anclaje nulo en lugar de descartarse. Asignar el dispositivo más tarde le da a sus eventos posteriores un anclaje de cliente/área/activo. (Ver Gestión de asignaciones de dispositivos.)

Atributos frente a eventos

DeviceChain distingue el estado actual del historial:

• Los eventos son el registro de series temporales de solo anexado (append-only) de todo lo que informa un dispositivo (mediciones, ubicaciones, alertas, invocaciones/respuestas de comandos, cambios de estado). Residen en hypertables de TimescaleDB.
• Los atributos son el estado actual de clave-valor de una entidad, en tres ámbitos:
  • CLIENT — informado por el dispositivo.
  • SERVER — metadatos exclusivos de la plataforma que el dispositivo nunca ve.
  • SHARED — definidos por la plataforma y legibles por el dispositivo (el canal para la configuración remota y los destinos OTA).

Facetas y grupos dinámicos

Los atributos también funcionan como facetas de clasificación — los ejes por los que se navegan y filtran las entidades. Un registro de facetas por inquilino declara qué claves de atributo (para una familia de entidades dada) son facetas, dando a la interfaz de navegación de la consola sus ejes y el autocompletado de valores; declara qué claves son facetas, no los valores (los valores permanecen como atributos en las propias entidades).

Un grupo dinámico convierte un filtro de facetas en una membresía guardada y autoactualizable. Su selector es una expresión booleana sobre los atributos de los miembros — por ejemplo attr["climate"] == "arid" && attr["country"] == "US" — escrita en CEL, el mismo lenguaje de expresiones que usa el motor de detección. La plataforma valida y limita el costo del selector cuando se guarda el grupo, y luego resuelve la membresía en el momento de la lectura, transformando la expresión en una consulta de base de datos indexada (nunca escaneando cada entidad), de modo que un grupo dinámico siempre refleja el estado actual de los atributos sin ninguna caché materializada que mantener sincronizada. Un grupo estático, en cambio, mantiene una lista explícita de miembros. La pantalla Browse (Explorar) de la consola compone un selector a partir de los ejes de facetas, previsualiza el recuento coincidente en vivo, y lo guarda como un grupo dinámico; la pantalla Facets (Facetas) administra el registro.

Comandos

Un perfil de dispositivo declara los comandos que aceptan sus dispositivos, y un comando emitido se persiste y se rastrea a través de un ciclo de vida en lugar de enviarse y olvidarse. Ambos se describen en Comandos.

Identidad y credenciales

Un dispositivo tiene una identidad estable que todo lo demás referencia, mantenida separada de sus credenciales (el material que usa para autenticarse). Las credenciales son conectables (pluggable) — token de acceso, MQTT-basic (usuario + contraseña) y certificado X.509 — de modo que un dispositivo puede rotar o mantener múltiples credenciales sin cambiar su identidad. El secreto de una credencial es de solo escritura — se envía cuando se registra la credencial y nunca se devuelve en una lectura —, pero eso solo cubre la contraseña de MQTT-basic: para un token de acceso o un certificado, el id de la credencial es en sí mismo la prueba de posesión, de modo que leer las credenciales de un dispositivo requiere la autoridad device:write y no device:read. Ver Credenciales de dispositivo.

Un dispositivo también puede llevar un externalId opcional — una clave de negocio propiedad del cliente, como un VIN, número de serie, código GS1 o etiqueta de activo. Es distinto tanto de la identidad interna como de la credencial: es opaco (sin restricciones de formato), único dentro de un inquilino cuando está presente, y nunca se usa para direccionamiento ni autenticación. Su propósito es la búsqueda y la integración — hacer coincidir un dispositivo de DeviceChain con el identificador que tus otros sistemas ya usan para esa misma cosa física.

Eventos

Cada evento registra el dispositivo que lo informa, el tipo de evento, las marcas de tiempo informadas por el dispositivo y recibidas por la plataforma, un id de correlación externo opcional (alternateId) para una ingesta idempotente, y el anclaje de relación resuelto descrito arriba (nulo cuando el dispositivo no está asignado). Las categorías de eventos incluyen mediciones, ubicaciones, alertas, invocaciones y respuestas de comandos, y cambios de estado.

Las mediciones son autodescriptivas: cuando una lectura coincide con una métrica definida en el perfil del dispositivo, la plataforma estampa la unidad y el tipo de dato de esa métrica directamente sobre la lectura persistida (y sobre la proyección de último estado conocido en vivo). Un consumidor que lee una medición obtiene su semántica — 22.4 °C, un DOUBLE — sin una segunda consulta al perfil.