L'Asset Administration Shell (AAS) est le standard de l'Industrie 4.0 qui donne à chaque actif industriel un jumeau numérique structuré et lisible par les machines. Dans cet article, vous verrez comment une Asset Administration Shell se construit à partir de sous-modèles et d'identifiants sémantiques, en quoi diffèrent les trois types d'AAS, et comment maintenir à jour les valeurs des sous-modèles à partir des données MQTT qui transitent par un broker.
Pour une introduction plus large aux jumeaux, consultez notre guide de la technologie du jumeau numérique.
Qu'est-ce qu'une Asset Administration Shell ?
Une Asset Administration Shell est une représentation numérique normalisée d'un actif : un moteur, un variateur, un robot, une cellule de production entière, voire un logiciel. Elle a été définie au sein de la Plattform Industrie 4.0 en Allemagne et est aujourd'hui maintenue par l'Industrial Digital Twin Association (IDTA), son métamodèle étant normalisé à l'international sous la référence IEC 63278.
L'idée centrale est l'interopérabilité. Un variateur d'un fournisseur et une pompe d'un autre devraient décrire leur plaque signalétique, leurs données techniques, leur documentation et leurs données d'exploitation de la même façon, afin qu'un ingénieur d'usine, un MES ou un outil de maintenance puissent les lire sans intégration spécifique à chaque fournisseur. L'AAS donne à chaque actif la même « enveloppe », et le contenu de celle-ci est organisé en sous-modèles.
La structure d'une AAS
Une AAS repose sur un petit nombre de briques :
| Élément | Rôle |
|---|---|
| Asset Administration Shell | Le jumeau lui-même, avec son propre identifiant, référençant exactement un actif |
| Informations sur l'actif | Identifiant global de l'actif et nature (type ou instance) |
| Sous-modèle | Un aspect autonome de l'actif, comme la plaque signalétique ou les données opérationnelles |
| Élément de sous-modèle | Le contenu réel : propriétés, plages, fichiers, collections, opérations |
| Identifiant sémantique | Une référence vers une définition de dictionnaire qui précise ce que signifie un élément |
| Description de concept | La définition d'un identifiant sémantique, de ses unités et de son type de données |
Les sous-modèles
Les sous-modèles sont le cœur de l'Asset Administration Shell. Chacun couvre un aspect de l'actif et peut être maintenu par un acteur différent. Le fabricant fournit la plaque signalétique numérique et les données techniques ; l'exploitant ajoute les historiques de maintenance et les données opérationnelles en temps réel.
L'IDTA publie des modèles de sous-modèles (submodel templates) pour que les aspects courants se présentent partout de la même manière. Parmi les modèles les plus utilisés figurent Digital Nameplate, Technical Data, Contact Information, Handover Documentation et Time Series Data. C'est l'utilisation d'un modèle, plutôt que l'invention de votre propre structure, qui rend l'AAS interopérable.
Les éléments de sous-modèle
À l'intérieur d'un sous-modèle, le contenu s'exprime sous forme d'éléments typés. Ceux que vous rencontrerez le plus souvent :
- Property : une valeur unique avec un type de données, par exemple
MaxRotationSpeeden double. - MultiLanguageProperty : du texte en plusieurs langues.
- Range : un minimum et un maximum.
- File et Blob : documents, images, fichiers CAO.
- SubmodelElementCollection et SubmodelElementList : regroupement et répétition.
- ReferenceElement et RelationshipElement : liens entre éléments ou entre actifs.
- Operation : une fonction appelable avec des variables d'entrée et de sortie.
Les identifiants sémantiques
Chaque élément peut porter un identifiant sémantique (semantic ID) pointant vers une définition dans un dictionnaire comme ECLASS ou l'IEC Common Data Dictionary. C'est ce qui permet à un logiciel de savoir qu'une propriété nommée NenndrehzahlMax dans une AAS et MaxSpeed dans une autre désignent la même chose. Sans identifiants sémantiques, une AAS n'est qu'un format JSON de plus.
Les trois types d'Asset Administration Shell
| Type d'AAS | Forme | Usage typique |
|---|---|---|
| Type 1 | Un fichier, généralement un paquet AASX | Le fabricant livre les données du jumeau avec le produit |
| Type 2 | Un serveur exposant l'AAS via une API | Les systèmes de l'usine lisent et mettent à jour les jumeaux en exécution |
| Type 3 | Des shells proactives qui interagissent entre elles | Négociation autonome entre actifs, encore émergente |
La plupart des projets industriels utilisent aujourd'hui le Type 1 pour les données d'ingénierie et de remise, et le Type 2 pour les jumeaux en exécution. Des implémentations open source comme Eclipse BaSyx fournissent des serveurs et des registres AAS, et l'AASX Package Explorer est couramment utilisé pour créer et inspecter les fichiers AASX.
La place de MQTT : des données en temps réel pour une Asset Administration Shell
Le standard AAS définit le modèle d'information et les API, mais ne prescrit pas comment arrivent les valeurs en temps réel de l'atelier. En pratique, les données opérationnelles comme les températures, les vitesses et les états circulent déjà via MQTT depuis les automates et les passerelles edge. Le pattern pragmatique consiste à garder MQTT comme transport temps réel et à confier à un adaptateur la mise à jour du sous-modèle AAS concerné.
PLC / sensor -> edge gateway -> MQTT broker -> AAS adapter -> AAS server (Type 2)
|
+-> dashboards, 3D twins, historians
Les consommateurs rapides (tableaux de bord, alarmes, jumeaux 3D en temps réel) restent ainsi sur MQTT, tandis que le serveur AAS détient la vue normalisée et annotée sémantiquement que lisent le MES, l'ERP et les outils d'ingénierie.
Une conception de topics qui se mappe proprement sur les sous-modèles
Choisissez des topics qui rendent le mapping vers l'AAS évident. Un chemin ISA-95 identifie l'actif, et les derniers niveaux identifient le sous-modèle :
acme/plant1/assembly/line3/drive07/operational live values, retained
acme/plant1/assembly/line3/drive07/status online/offline, retained
L'adaptateur conserve une table de correspondance entre les chemins d'actifs MQTT et les identifiants AAS, et entre les champs JSON et les idShorts des éléments de sous-modèle. Les payloads Sparkplug B fonctionnent aussi : ConnectMQ décode Sparkplug B et peut le republier dans des topics ISA-95, ce qui fournit à l'adaptateur un flux JSON simple à consommer.
Un adaptateur MQTT vers AAS minimal
Cet adaptateur Python s'abonne aux données opérationnelles et met à jour (PATCH) les valeurs des propriétés sur un serveur AAS. Le chemin REST suit le style de l'API AAS Part 2 utilisé par des serveurs comme Eclipse BaSyx, où les identifiants sont encodés en base64url ; vérifiez dans la documentation de votre serveur l'endpoint et la version exacts.
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()
Deux remarques de conception. D'abord, n'envoyez pas chaque échantillon à haute fréquence au serveur AAS ; mettez-le à jour à un rythme raisonnable, par exemple une fois par seconde ou sur changement, et conservez les données à pleine fréquence dans un historian. Ensuite, gardez les tables de correspondance dans la configuration, idéalement générées à partir de l'AAS elle-même, pour qu'ajouter un actif ne nécessite pas de modifier le code.
Vous pouvez tester dès maintenant le côté MQTT avec le serveur MQTT public gratuit, réservé aux tests et jamais aux données de production, en utilisant un préfixe unique comme connectmq/demo/c58d/... à la place de acme/..., et en adaptant l'abonnement en conséquence.
Checklist de mise en œuvre d'une Asset Administration Shell
- Définir les actifs du périmètre et leur attribuer des identifiants globaux stables.
- Partir des modèles de sous-modèles IDTA avant de créer des sous-modèles personnalisés.
- Associer des identifiants sémantiques ECLASS ou IEC CDD à chaque propriété exposée.
- Décider quelles données vivent dans des fichiers Type 1 et lesquelles dans un serveur Type 2.
- Concevoir les topics MQTT pour que les chemins d'actifs correspondent un à un aux identifiants AAS.
- Écrire ou déployer un adaptateur qui met à jour les valeurs des sous-modèles à un rythme maîtrisé.
- Sécuriser le chemin MQTT avec TLS et des identifiants par passerelle.
- Versionner les sous-modèles et garder la configuration de mapping sous contrôle de version.
L'AAS comparée aux autres modèles de jumeau
L'AAS excelle pour les actifs industriels qui passent entre les mains de fabricants, d'intégrateurs et d'exploitants, car ses modèles de sous-modèles et ses identifiants sémantiques voyagent avec l'actif. DTDL est plus léger et orienté développeurs, centré sur la télémétrie, les propriétés et les commandes. Eclipse Ditto modélise les jumeaux comme des things avec attributs et features et se connecte nativement à MQTT ; consultez Eclipse Ditto avec MQTT. Beaucoup d'usines les combinent : l'AAS pour la description normalisée des actifs, MQTT et un Unified Namespace pour les données en temps réel, et une couche de jumeau légère pour la visualisation. Notre guide Sparkplug B et Unified Namespace couvre le volet données en temps réel.
Alimentez votre Asset Administration Shell avec ConnectMQ
ConnectMQ fournit la couche temps réel : un broker MQTT managé, exploité comme broker MQTT cloud, compatible MQTT 3.1.1 et 5.0, avec TLS sur le port 8883, détection des topics ISA-95, une vue des appareils organisée par niveaux ISA-95 et le décodage Sparkplug B. Votre serveur AAS et votre adaptateur fonctionnent à ses côtés comme des clients MQTT ordinaires. Inscrivez-vous sur app.connectmq.com, démarrez avec l'offre Serverless gratuite sans carte bancaire, et diffusez les données opérationnelles de votre premier actif dans sa shell.
Questions fréquentes
L'Asset Administration Shell est-elle un produit logiciel ?
Non. C'est un modèle d'information normalisé et une spécification d'API. Des produits et des projets open source comme Eclipse BaSyx l'implémentent.
Qu'est-ce qu'un sous-modèle dans l'AAS ?
Un sous-modèle est un aspect autonome d'un actif, comme sa plaque signalétique, ses données techniques ou ses données opérationnelles, construit à partir d'éléments typés dotés d'identifiants sémantiques.
L'AAS remplace-t-elle MQTT ou OPC UA ?
Non. L'AAS décrit les actifs et les expose via des API ; MQTT et OPC UA transportent les données en temps réel. Un pattern courant associe MQTT pour les flux temps réel à un adaptateur qui met à jour l'AAS.
Qu'est-ce qu'un fichier AASX ?
Un fichier AASX est un format de paquet pour les shells de Type 1 qui regroupe l'AAS, ses sous-modèles et des fichiers complémentaires comme les manuels en un seul fichier destiné à l'échange.
