SYS-ADR-001 — Arquitectura en cuatro piezas, con InfluxDB como desacople dentro de la Pi¶
| Estado | Aceptada |
| Decisión | progresiva, entre octubre de 2025 y agosto de 2026 |
| Registrada | 2026-09-30 |
| Relacionadas | SYS-ADR-002, SYS-ADR-003, SYS-ADR-007 |
Contexto¶
Hay que llevar datos de un PLC en planta a un dashboard en internet. El enlace entre la planta y la nube es el eslabón menos confiable del sistema: se corta, y mientras está cortado la máquina sigue produciendo.
Además, el proyecto tiene una restricción organizativa: el componente que lee el PLC es una tesis de maestría de un autor externo al equipo, con su propio ciclo de vida y su propio repositorio. No se lo puede tratar como un módulo más.
Decisión¶
Cuatro piezas, en dos ubicaciones físicas:
| Ubicación | Piezas |
|---|---|
| Raspberry Pi, en planta | historian (lee el PLC) e InfluxDB, más el Edge Pi Service (reenvía a la nube) |
| Nube | Cloud API y el frontend con su BFF |
InfluxDB dentro de la Pi es la junta de desacople del sistema. El historian escribe ahí y no sabe que existe una nube; el Edge lee de ahí y no sabe que existe un PLC. Los dos procesos corren en la misma máquina, no comparten código, y la única interfaz entre ellos es el esquema de datos de InfluxDB.
Alternativas consideradas¶
| Alternativa | Por qué no |
|---|---|
| Que el historian envíe directo a la nube | Acopla la tesis externa al contrato del Cloud, y le impone a un autor que no está en el equipo la responsabilidad del buffer offline |
| Un solo proceso en la Pi que lea el PLC y reenvíe | Mismo problema, agravado: obligaría a reescribir el historian en el lenguaje del Edge o viceversa |
| Cola de mensajes en la Pi en lugar de InfluxDB | InfluxDB ya cumple el papel de desacople y además guarda la serie: una cola agregaría una pieza sin reemplazar ninguna |
| Base de series temporales en la nube en vez de en la Pi | Perdería el desacople: sin almacenamiento local no hay tolerancia al corte del enlace |
Consecuencias¶
A favor:
- El corte de enlace no pierde datos: son dos problemas separados, y solo uno depende de la
red. Ver
SYS-ADR-002. - La tesis externa evoluciona sin coordinarse con el equipo, mientras respete el esquema de InfluxDB.
- El historian se puede probar sin nube, y el Edge sin PLC. El Edge tiene incluso un modo scaffold para arrancar sin InfluxDB disponible.
En contra:
- El contrato entre las dos piezas de la Pi es implícito. No hay esquema versionado ni
validación: son los nombres de los tags de InfluxDB. Es el origen del defecto que registra
SYS-ADR-004. - Hay dos series temporales en el sistema, InfluxDB en la Pi y MongoDB en la nube, con datos que se solapan y sin política de retención en ninguna de las dos.
- El despliegue en la Pi requiere los tres repositorios clonados lado a lado, porque el compose usa rutas relativas. Ver despliegue.
Evidencia¶
- Composición del stack en la Pi y requisito de repos lado a lado:
docker-compose.ymlydocs/pi.md - El historian escribe en InfluxDB y no conoce la nube:
src/historian/main.py - El Edge lee de InfluxDB y no conoce el PLC:
internal/platform/influxclient/yinternal/app/forwarder/del Edge - Modo scaffold del Edge:
EDGE-ADR-008