A Asset Administration Shell (AAS) é o padrão da Indústria 4.0 para dar a cada ativo industrial um gêmeo digital estruturado e legível por máquina. Neste artigo você vai aprender como uma asset administration shell é construída a partir de submodelos e IDs semânticos, como os três tipos de AAS diferem e como manter os valores de submodelos atualizados a partir de dados MQTT que passam por um broker.
Para uma introdução mais ampla a gêmeos digitais, veja nosso guia sobre a tecnologia de gêmeo digital.
O Que É uma Asset Administration Shell?
Uma asset administration shell é uma representação digital padronizada de um ativo: um motor, um inversor, um robô, uma célula de produção inteira ou até um software. Ela foi definida no âmbito da Plattform Industrie 4.0, na Alemanha, e hoje é mantida pela Industrial Digital Twin Association (IDTA), com seu metamodelo padronizado internacionalmente como IEC 63278.
A ideia central é a interoperabilidade. Um inversor de um fornecedor e uma bomba de outro devem descrever sua placa de identificação, dados técnicos, documentação e dados de operação da mesma forma, para que um engenheiro de uma planta em Joinville, um MES ou uma ferramenta de manutenção consiga lê-los sem integração personalizada para cada fabricante. A AAS dá a cada ativo o mesmo "invólucro", e o conteúdo dentro dele é organizado em submodelos.
A Estrutura de uma AAS
Uma AAS tem poucos blocos de construção:
| Elemento | Finalidade |
|---|---|
| Asset Administration Shell | O gêmeo em si, com seu próprio ID, referenciando exatamente um ativo |
| Asset information | ID global do ativo e tipo (type ou instance) |
| Submodel | Um aspecto autocontido do ativo, como placa de identificação ou dados operacionais |
| Submodel element | O conteúdo real: propriedades, faixas, arquivos, coleções, operações |
| Semantic ID | Uma referência a uma definição de dicionário que diz o que um elemento significa |
| Concept description | A definição de um semantic ID, unidades e tipo de dado |
Submodelos
Os submodelos são o coração da asset administration shell. Cada um cobre um aspecto do ativo e pode ser mantido por uma parte diferente. O fabricante fornece a placa de identificação digital e os dados técnicos; o operador acrescenta registros de manutenção e dados operacionais ao vivo.
A IDTA publica templates de submodelo para que aspectos comuns tenham a mesma aparência em todo lugar. Templates amplamente usados incluem Digital Nameplate, Technical Data, Contact Information, Handover Documentation e Time Series Data. Usar um template em vez de inventar sua própria estrutura é o que torna a AAS interoperável.
Elementos de Submodelo
Dentro de um submodelo, o conteúdo é expresso como elementos tipados. Os que você mais vai encontrar:
- Property: um valor único com tipo de dado, por exemplo
MaxRotationSpeedcomo double. - MultiLanguageProperty: texto em vários idiomas.
- Range: um mínimo e um máximo.
- File e Blob: documentos, imagens, arquivos CAD.
- SubmodelElementCollection e SubmodelElementList: agrupamento e repetição.
- ReferenceElement e RelationshipElement: vínculos entre elementos ou ativos.
- Operation: uma função invocável com variáveis de entrada e saída.
IDs Semânticos
Cada elemento pode ter um semantic ID que aponta para uma definição em um dicionário como o ECLASS ou o IEC Common Data Dictionary. É isso que permite ao software saber que uma propriedade chamada NenndrehzahlMax em uma AAS e MaxSpeed em outra significam a mesma coisa. Sem IDs semânticos, uma AAS é apenas mais um formato JSON.
Os Três Tipos de Asset Administration Shell
| Tipo de AAS | Forma | Uso típico |
|---|---|---|
| Tipo 1 | Um arquivo, geralmente um pacote AASX | O fabricante entrega os dados do gêmeo junto com o produto |
| Tipo 2 | Um servidor que expõe a AAS por meio de uma API | Sistemas da planta leem e atualizam gêmeos em tempo de execução |
| Tipo 3 | Shells proativas que interagem entre si | Negociação autônoma entre ativos, ainda emergente |
A maioria dos projetos industriais hoje trabalha com o Tipo 1 para dados de engenharia e de entrega e com o Tipo 2 para gêmeos em tempo de execução. Implementações open source como o Eclipse BaSyx fornecem servidores e registros AAS, e o AASX Package Explorer é muito usado para criar e inspecionar arquivos AASX.
Onde o MQTT se Encaixa: Dados ao Vivo para uma Asset Administration Shell
O padrão AAS define o modelo de informação e as APIs, mas não prescreve como os valores ao vivo do chão de fábrica chegam. Na prática, dados operacionais como temperaturas, velocidades e estados já fluem via MQTT a partir de CLPs e gateways de borda. O padrão prático é manter o MQTT como transporte em tempo real e deixar um adaptador atualizar o submodelo AAS correspondente.
PLC / sensor -> edge gateway -> MQTT broker -> AAS adapter -> AAS server (Type 2)
|
+-> dashboards, 3D twins, historians
Isso mantém os consumidores rápidos (dashboards, alarmes, gêmeos 3D em tempo real) no MQTT, enquanto o servidor AAS guarda a visão padronizada e anotada semanticamente que MES, ERP e ferramentas de engenharia leem.
Design de Topics que se Mapeia Limpo para Submodelos
Escolha topics que tornem óbvio o mapeamento para a AAS. Um caminho ISA-95 identifica o ativo, e os últimos níveis identificam o submodelo:
acme/plant1/assembly/line3/drive07/operational live values, retained
acme/plant1/assembly/line3/drive07/status online/offline, retained
O adaptador mantém uma tabela de mapeamento dos caminhos de ativos MQTT para IDs AAS e dos campos JSON para os idShorts dos elementos de submodelo. Payloads Sparkplug B também funcionam: o ConnectMQ decodifica Sparkplug B e pode republicá-lo em topics ISA-95, o que entrega ao adaptador um fluxo JSON simples para consumir.
Um Adaptador MQTT-para-AAS Mínimo
Este adaptador Python assina dados operacionais e atualiza valores de propriedades em um servidor AAS. O caminho REST segue o estilo da API AAS Part 2 usado por servidores como o Eclipse BaSyx, em que os identificadores são codificados em base64url; consulte a documentação do seu servidor para o endpoint e a versão exatos.
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()
Duas observações de design. Primeiro, não envie cada amostra de alta frequência para o servidor AAS; atualize-o em uma taxa sensata, por exemplo uma vez por segundo ou na mudança, e mantenha os dados em taxa total em um historiador. Segundo, mantenha as tabelas de mapeamento em configuração, de preferência geradas a partir da própria AAS, para que adicionar um ativo não exija mudanças de código.
Você pode testar o lado MQTT agora mesmo com o servidor MQTT público (gratuito), que serve para testes e protótipos e não para dados de produção, usando um prefixo único como connectmq/demo/c58d/... no lugar de acme/... e ajustando a assinatura de acordo.
Checklist de Implementação da Asset Administration Shell
- Defina os ativos no escopo e atribua IDs globais de ativo estáveis.
- Parta dos templates de submodelo da IDTA antes de criar submodelos personalizados.
- Anexe IDs semânticos do ECLASS ou do IEC CDD a cada propriedade exposta.
- Decida quais dados ficam em arquivos Tipo 1 e quais em um servidor Tipo 2.
- Projete os topics MQTT para que os caminhos de ativos se mapeiem um para um com os IDs AAS.
- Escreva ou implante um adaptador que atualize os valores de submodelo ao vivo em uma taxa controlada.
- Proteja o caminho MQTT com TLS e credenciais por gateway.
- Versione os submodelos e mantenha a configuração de mapeamento sob controle de versão.
AAS Comparada com Outros Modelos de Gêmeo
A AAS é mais forte para ativos industriais que passam entre fabricantes, integradores e operadores, porque seus templates de submodelo e IDs semânticos acompanham o ativo. A DTDL é mais leve e orientada a desenvolvedores, focada em telemetria, propriedades e comandos. O Eclipse Ditto modela gêmeos como things com attributes e features e se conecta nativamente ao MQTT; veja Eclipse Ditto com MQTT. Muitas plantas combinam os três: AAS para a descrição padronizada do ativo, MQTT e um Unified Namespace para dados ao vivo e uma camada de gêmeo leve para visualização. Nosso guia de Sparkplug B e Unified Namespace cobre o lado dos dados ao vivo.
Alimente Sua Asset Administration Shell com o ConnectMQ
O ConnectMQ fornece a camada de tempo real: um broker MQTT gerenciado, ou seja, um broker MQTT na nuvem com MQTT 3.1.1 e 5.0, TLS na porta 8883, detecção de topics ISA-95, uma visão de dispositivos organizada por níveis ISA-95 e decodificação Sparkplug B. Seu servidor AAS e seu adaptador rodam ao lado dele como clientes MQTT comuns. Cadastre-se em app.connectmq.com, comece no plano Serverless gratuito sem cartão de crédito e transmita os dados operacionais do seu primeiro ativo para a respectiva shell.
Perguntas frequentes
A asset administration shell é um produto de software?
Não. Ela é um modelo de informação padronizado e uma especificação de API. Produtos e projetos open source como o Eclipse BaSyx a implementam.
O que é um submodelo na AAS?
Um submodelo é um aspecto autocontido de um ativo, como sua placa de identificação, seus dados técnicos ou seus dados operacionais, construído a partir de elementos tipados com IDs semânticos.
A AAS substitui o MQTT ou o OPC UA?
Não. A AAS descreve ativos e os expõe por meio de APIs; o MQTT e o OPC UA movem dados ao vivo. Um padrão comum é usar MQTT para fluxos em tempo real, com um adaptador atualizando a AAS.
O que é um arquivo AASX?
Um arquivo AASX é um formato de pacote para shells do Tipo 1 que reúne a AAS, seus submodelos e arquivos complementares, como manuais, em um único arquivo para intercâmbio.
