La Asset Administration Shell (AAS) es el estándar de Industria 4.0 para dotar a cada activo industrial de un gemelo digital estructurado y legible por máquinas. En este artículo aprenderás cómo se construye una asset administration shell a partir de submodelos e IDs semánticos, en qué se diferencian los tres tipos de AAS y cómo mantener actualizados los valores de los submodelos en vivo a partir de datos MQTT que fluyen por un broker.
Para una introducción más amplia a los gemelos, consulta nuestra guía de tecnología de gemelo digital.
¿Qué es una Asset Administration Shell?
Una asset administration shell es una representación digital estandarizada de un activo: un motor, un variador, un robot, una célula de producción completa e incluso un software. Se definió en la Plattform Industrie 4.0 de Alemania y hoy la mantiene la Industrial Digital Twin Association (IDTA), con su metamodelo estandarizado internacionalmente como IEC 63278.
La idea central es la interoperabilidad. Un variador de un proveedor y una bomba de otro deberían describir su placa de características, sus datos técnicos, su documentación y sus datos operativos de la misma manera, para que un ingeniero de planta, un MES o una herramienta de mantenimiento puedan leerlos sin una integración a medida para cada fabricante. La AAS da a todos los activos el mismo "envoltorio", y el contenido de su interior se organiza en submodelos.
La estructura de una AAS
Una AAS tiene un número reducido de bloques:
| Elemento | Finalidad |
|---|---|
| Asset Administration Shell | El gemelo en sí, con su propio ID, que referencia exactamente un activo |
| Asset information | ID global del activo y su tipo (type o instance) |
| Submodel | Un aspecto autónomo del activo, como la placa de características o los datos operativos |
| Submodel element | El contenido real: propiedades, rangos, archivos, colecciones, operaciones |
| Semantic ID | Una referencia a una definición de diccionario que indica qué significa un elemento |
| Concept description | La definición de un semantic ID, sus unidades y su tipo de dato |
Submodelos
Los submodelos son el corazón de la asset administration shell. Cada uno cubre un aspecto del activo y puede mantenerlo una parte distinta. El fabricante aporta la placa de características digital y los datos técnicos; el operador añade los registros de mantenimiento y los datos operativos en vivo.
La IDTA publica plantillas de submodelo para que los aspectos comunes tengan el mismo aspecto en todas partes. Entre las plantillas más usadas están Digital Nameplate, Technical Data, Contact Information, Handover Documentation y Time Series Data. Usar una plantilla en lugar de inventar tu propia estructura es lo que hace interoperable a la AAS.
Elementos de submodelo
Dentro de un submodelo, el contenido se expresa como elementos tipados. Los que encontrarás con más frecuencia:
- Property: un único valor con un tipo de dato, por ejemplo
MaxRotationSpeedcomo double. - MultiLanguageProperty: texto en varios idiomas.
- Range: un mínimo y un máximo.
- File y Blob: documentos, imágenes, archivos CAD.
- SubmodelElementCollection y SubmodelElementList: agrupación y repetición.
- ReferenceElement y RelationshipElement: enlaces entre elementos o activos.
- Operation: una función invocable con variables de entrada y salida.
IDs semánticos
Cada elemento puede llevar un semantic ID que apunta a una definición en un diccionario como ECLASS o el IEC Common Data Dictionary. Esto es lo que permite al software saber que una propiedad llamada NenndrehzahlMax en una AAS y MaxSpeed en otra significan lo mismo. Sin IDs semánticos, una AAS es solo otro formato JSON más.
Los tres tipos de Asset Administration Shell
| Tipo de AAS | Forma | Uso típico |
|---|---|---|
| Tipo 1 | Un archivo, normalmente un paquete AASX | El fabricante entrega los datos del gemelo con el producto |
| Tipo 2 | Un servidor que expone la AAS mediante una API | Los sistemas de planta leen y actualizan los gemelos en tiempo de ejecución |
| Tipo 3 | Shells proactivas que interactúan entre sí | Negociación autónoma entre activos, todavía emergente |
La mayoría de los proyectos industriales trabajan hoy con el Tipo 1 para los datos de ingeniería y entrega, y con el Tipo 2 para los gemelos en tiempo de ejecución. Implementaciones open source como Eclipse BaSyx ofrecen servidores y registros AAS, y el AASX Package Explorer se usa habitualmente para crear e inspeccionar archivos AASX.
Dónde encaja MQTT: datos en vivo para una Asset Administration Shell
El estándar AAS define el modelo de información y las APIs, pero no prescribe cómo llegan los valores en vivo de planta. En la práctica, los datos operativos como temperaturas, velocidades y estados ya fluyen por MQTT desde los PLC y los gateways edge. El patrón práctico es mantener MQTT como transporte en tiempo real y dejar que un adaptador actualice el submodelo AAS correspondiente.
PLC / sensor -> edge gateway -> MQTT broker -> AAS adapter -> AAS server (Type 2)
|
+-> dashboards, 3D twins, historians
Así, los consumidores rápidos (dashboards, alarmas, gemelos 3D en tiempo real) se quedan en MQTT, mientras que el servidor AAS guarda la vista estandarizada y anotada semánticamente que leen el MES, el ERP y las herramientas de ingeniería. Un gemelo digital 3D en el navegador puede incluso combinar ambas fuentes: los datos de placa de características desde la AAS y los valores en vivo desde MQTT.
Un diseño de topics que se mapea limpiamente a submodelos
Elige topics que hagan evidente el mapeo a la AAS. Una ruta ISA-95 identifica el activo y los últimos niveles identifican el submodelo:
acme/plant1/assembly/line3/drive07/operational live values, retained
acme/plant1/assembly/line3/drive07/status online/offline, retained
El adaptador mantiene una tabla de correspondencias de las rutas de activo MQTT a los IDs AAS y de los campos JSON a los idShort de los elementos de submodelo. Los payloads Sparkplug B también sirven: ConnectMQ decodifica Sparkplug B y puede republicarlo en topics ISA-95, lo que da al adaptador un flujo JSON sencillo que consumir.
Un adaptador mínimo de MQTT a AAS
Este adaptador en Python se suscribe a los datos operativos y actualiza los valores de las propiedades en un servidor AAS. La ruta REST sigue el estilo de la API de AAS Part 2 que usan servidores como Eclipse BaSyx, en la que los identificadores se codifican en base64url; consulta la documentación de tu servidor para el endpoint y la versión exactos.
import base64
import json
import paho.mqtt.client as mqtt
import requests
AAS_SERVER = "http://localhost:8081"
SUBMODEL_IDS = {
"acme/plant1/assembly/line3/drive07": "https://acme.example/ids/sm/drive07-operational",
}
FIELD_TO_IDSHORT = {"speed_rpm": "RotationSpeed", "temp_c": "MotorTemperature", "state": "OperatingState"}
def b64url(value: str) -> str:
return base64.urlsafe_b64encode(value.encode()).decode().rstrip("=")
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe("acme/plant1/+/+/+/operational", qos=1)
def on_message(client, userdata, msg):
asset_path = msg.topic.rsplit("/", 1)[0]
submodel_id = SUBMODEL_IDS.get(asset_path)
if not submodel_id:
return
data = json.loads(msg.payload)
for field, id_short in FIELD_TO_IDSHORT.items():
if field in data:
url = f"{AAS_SERVER}/submodels/{b64url(submodel_id)}/submodel-elements/{id_short}/$value"
requests.patch(url, json=data[field], timeout=5)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID")
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.on_connect = on_connect
client.on_message = on_message
client.connect("YOUR_BROKER_HOST", 8883)
client.loop_forever()
Dos notas de diseño. Primero, no envíes cada muestra de alta frecuencia al servidor AAS; actualízalo a un ritmo razonable, por ejemplo una vez por segundo o cuando cambie el valor, y guarda los datos a frecuencia completa en un historian. Segundo, mantén las tablas de correspondencias en configuración, idealmente generadas a partir de la propia AAS, para que añadir un activo no requiera cambios de código.
Puedes probar ahora mismo la parte MQTT con el servidor MQTT público gratuito, pensado para pruebas y prototipos y no para datos de producción, usando un prefijo único como connectmq/demo/c58d/... en lugar de acme/... y ajustando la suscripción en consecuencia.
Checklist de implementación de la Asset Administration Shell
- Define los activos del alcance y asígnales IDs globales de activo estables.
- Parte de las plantillas de submodelo de la IDTA antes de crear submodelos propios.
- Asocia IDs semánticos de ECLASS o IEC CDD a cada propiedad que expongas.
- Decide qué datos viven en archivos de Tipo 1 y cuáles en un servidor de Tipo 2.
- Diseña los topics MQTT para que las rutas de activo se correspondan uno a uno con los IDs AAS.
- Escribe o despliega un adaptador que actualice los valores de submodelo en vivo a un ritmo controlado.
- Protege la ruta MQTT con TLS y credenciales por gateway.
- Versiona los submodelos y mantén la configuración de correspondencias bajo control de código fuente.
La AAS comparada con otros modelos de gemelo
La AAS es más fuerte en activos industriales que pasan por manos de fabricantes, integradores y operadores, porque sus plantillas de submodelo y sus IDs semánticos viajan con el activo. DTDL es más ligero y orientado a desarrolladores, centrado en telemetría, propiedades y comandos. Eclipse Ditto modela los gemelos como things con atributos y features y se conecta de forma nativa a MQTT; consulta Eclipse Ditto con MQTT. Muchas plantas los combinan: AAS para la descripción estandarizada del activo, MQTT y un Unified Namespace para los datos en vivo, y una capa de gemelo ligera para la visualización. Nuestra guía de Sparkplug B y Unified Namespace cubre la parte de datos en vivo.
Alimenta tu Asset Administration Shell con ConnectMQ
ConnectMQ aporta la capa en tiempo real: un broker MQTT gestionado que funciona como broker MQTT en la nube con MQTT 3.1.1 y 5.0, TLS en el 8883, detección de topics ISA-95, una vista de dispositivos organizada por niveles ISA-95 y decodificación Sparkplug B. Tu servidor AAS y tu adaptador funcionan junto a él como clientes MQTT normales. Regístrate en app.connectmq.com, empieza con el plan Serverless gratuito sin tarjeta de crédito y transmite los datos operativos de tu primer activo a su shell.
Preguntas frecuentes
¿La asset administration shell es un producto de software?
No. Es un modelo de información y una especificación de API estandarizados. Productos y proyectos open source como Eclipse BaSyx la implementan.
¿Qué es un submodelo en la AAS?
Un submodelo es un aspecto autónomo de un activo, como su placa de características, sus datos técnicos o sus datos operativos, construido a partir de elementos tipados con IDs semánticos.
¿La AAS sustituye a MQTT o a OPC UA?
No. La AAS describe los activos y los expone mediante APIs; MQTT y OPC UA transportan los datos en vivo. Un patrón habitual es usar MQTT para los flujos en tiempo real con un adaptador que actualiza la AAS.
¿Qué es un archivo AASX?
Un archivo AASX es un formato de paquete para shells de Tipo 1 que agrupa la AAS, sus submodelos y archivos complementarios como manuales en un único archivo para su intercambio.
