SYS-ADR-008 — Servidor AAS resuelto con FA³ST en la Pi, y no en la nube¶
| Estado | Aceptada |
| Decisión | 2026-09, al no incorporarse la capa AAS del Cloud |
| Registrada | 2026-09-30 |
| Relacionadas | SYS-ADR-003, SYS-ADR-004 |
Contexto¶
El estándar Asset Administration Shell es el marco conceptual del proyecto: aporta el vocabulario semántico que el sistema usa de punta a punta, y su adopción es parte del aporte académico.
Servir un modelo AAS —exponerlo por una API conforme al estándar, para que otros sistemas lo consulten— es algo distinto de usar su vocabulario. El sistema necesitaba lo segundo. La pregunta era si además valía la pena lo primero, y dónde.
Hubo dos caminos abiertos en paralelo:
- La tesis del historian ya integraba FA³ST, una implementación del estándar, sirviendo un archivo XML que el propio historian reescribe.
- Una especificación del Cloud proponía persistir los shells y submodelos en MongoDB, con su CRUD, para construir el gemelo digital del lado de la nube.
Decisión¶
El servidor AAS es FA³ST, corre en la Raspberry Pi, y es un override opcional. No forma parte del despliegue base: hay que activarlo explícitamente.
La capa AAS del Cloud no se construyó. La infraestructura de MongoDB que aquella
especificación introdujo terminó usándose para mediciones, no para documentos AAS: ver
SYS-ADR-003.
Lo que sí se adoptó de punta a punta es el vocabulario: submodelo, colección y propiedad son
la identidad de cada variable en los cuatro repositorios, vía SYS-ADR-004.
Alternativas consideradas¶
| Alternativa | Por qué no |
|---|---|
| Servidor AAS en la nube, sobre MongoDB | Está especificado y nunca se implementó. Habría duplicado el modelo: uno en la Pi y otro en la nube, con la sincronización como problema nuevo |
| FA³ST en el despliegue base de la Pi | Su costo de escritura lo desaconseja en hardware de planta. Ver abajo |
| No tener servidor AAS en absoluto | Se pierde la demostración de conformidad con el estándar, que tiene valor académico |
| Consultar FA³ST desde el Edge para resolver el catálogo | Evaluado en la decisión de componente del Edge y dejado como validación cruzada opcional. Agregaría una dependencia de arranque a un servicio opcional |
Consecuencias¶
A favor:
- El modelo AAS vive junto al activo que representa, que es lo que el estándar plantea.
- El despliegue base de la Pi queda más liviano, y el sistema funciona completo sin el servidor AAS.
- Se evita mantener dos representaciones del mismo modelo.
En contra:
- El servidor AAS no tiene hoy ningún consumidor dentro del sistema. Ninguna pieza lo consulta. Es una demostración de conformidad, no una parte del flujo.
- Al ser opcional, no participa del stack que se prueba: queda fuera del despliegue base.
- Se publica con certificado autofirmado, así que cualquier cliente que lo consulte tiene que aceptarlo explícitamente.
- La especificación del Cloud que proponía la capa AAS quedó en el árbol sin marcar como abandonada, y describe colecciones que no existen.
Activar el override tiene un costo que puede destruir la tarjeta de la Pi
Con el override activado, el historian reescribe el archivo XML completo del modelo AAS —unos 548 KB— en cada ciclo de lectura. A un ciclo por segundo eso da del orden de 47 GB de escrituras por día, según la estimación registrada en el propio override.
Sobre una tarjeta microSD, que es el almacenamiento habitual de una Raspberry Pi, ese volumen de escritura sostenido es un problema de vida útil, no de rendimiento.
No activar el override en una instalación de planta sin resolver esto antes. La solución está a la vista —escribir solo lo que cambió, o espaciar la reescritura— pero no está implementada.
Evidencia¶
- FA³ST como override opcional, su publicación con certificado autofirmado y la estimación del
costo de escritura:
docker-compose.aas.yml - El despliegue base no lo levanta:
docker-compose.yml - Reescritura del XML por ciclo:
src/historian/aas_updater.pyysrc/historian/main.py - Ausencia de consumidores: búsqueda en los cinco repositorios
- Capa AAS del Cloud especificada y no implementada:
specs/014-mongo-infra/, en la rama006-mongo-infradel Cloud, contra el árbolinternal/repo/mongo/demain, que solo tienemeasurementsymetrics - FA³ST como validación cruzada opcional para el catálogo:
EDGE-ADR-007