Pour la version la plus à jour, voir https://github.com/OpenFactoryLabUsine.
Guide pour l’installation, la configuration et l’utilisation du SDK OpenFactory pour simuler ou connecter des appareils industriels via MTConnect et déployer des applications.
Avant de commencer, il faut s'assurer d’avoir les éléments suivants installés :
- Docker Desktop
Avant de commencer, il faut s'assurer d’avoir les éléments suivants installés :
- Docker Desktop
- WSL v2
- Ubuntu activé dans Docker → Paramètres → Ressources → Intégration WSL → Activer Ubuntu
- Le repo clôné dans le disque dur virtuel Linux
Ajouter les lignes suivantes dans la section features du fichier devcontainer.json si elles ne sont pas déjà là:
"features": {
"ghcr.io/devcontainers/features/docker-in-docker:2": {},
"ghcr.io/openfactoryio/openfactory-sdk/infra": {
"openfactory-version": "main"
}
}
Une notification « Reopen in container » devrait apparaître. Cliquer dessus pour ouvrir le projet dans un container Docker.
Pour démarrer les containers d’infrastructure OpenFactory :
spinup
Il est essentiel de lancer OpenFactory pour pouvoir avoir accès aux commandes pour lancer un device ou une application.
Pour arrêter les containers d’infrastructure OpenFactory :
teardown
Pour effectuer des queries et visualiser l'état de la base de données ksqldb (streams des assets, etc.):
ksql
Pour plus de détails/exemples sur le protocole MTConnect, les adapteurs et les agents, voir https://github.com/camelia-d-e/OpenFactoryAdapters.
Fichiers requis
- Fichier XML : structure de l’appareil (conforme à MTConnect Standard)
- Fichier YML : configuration OpenFactory de l’appareil
devices:
my-device:
uuid: <UUID_DU_APPAREIL>
connector:
type: mtconnect
agent:
port: <PORT_AGENT>
device_xml: <NOM_FICHIER_XML>
adapter:
ip: <IP_ADAPTATEUR>
port: <PORT_MTCONNECT>
Exemple avec le dust-trak pour le protocole opc-ua:
devices:
dust-trak:
uuid: DUSTTRAK
connector:
type: opcua
server:
uri: opc.tcp://${CONTAINER_IP}:4841
variables:
pm1_concentration:
browse_path: 0:Root/0:Objects/2:DUSTTRAK/2:pm1_concentration
tag: DustTrak.pm1_concentration
pm2_5_concentration:
browse_path: 0:Root/0:Objects/2:DUSTTRAK/2:pm2_5_concentration
tag: DustTrak.pm2_5_concentration
pm4_concentration:
browse_path: 0:Root/0:Objects/2:DUSTTRAK/2:pm4_concentration
tag: DustTrak.pm4_concentration
pm10_concentration:
browse_path: 0:Root/0:Objects/2:DUSTTRAK/2:pm10_concentration
tag: DustTrak.pm10_concentration
Le protocole MTConnect est read-only, donc il ne permet pas de retourner des commandes à partir de OpenFactory. Le protocole OPC-UA permet de lire les données et d'envoyer des commandes aux assets/devices.
Il faut s'assurer de lancer le connecteur adéquat avant de lancer le device pour que les données s'acheminent correctement.
$opcua-connector-up
$ofa device up <CHEMIN_VERS_FICHIER_YML>
$ofa device down <CHEMIN_VERS_FICHIER_YML>
Si l’appareil physique iVAC n’est pas disponible, il est possible de simuler l’adaptateur dans
cd openfactory/virtual/<EQUIPEMENT_SIMULÉ>.
docker compose up -d
Il faut s'assurer que l’adresse IP utilisée dans le fichier de configuration .yml de l'équipement (dans openfactory/adapter/device.yml) correspond à celle du conteneur de l'équipement simulé. Cette adresse est définie dans le fichier de configuration .yml de l'adapteur virtuel (dans openfactory/virtual/<EQUIPEMENT_SIMULÉ>/vdevice.yml).
Fichiers requis
- Fichier YML : configuration des applications
- Dockerfile : pour construire l’image
- Code de l’application : doit hériter de la classe OpenFactoryApp
apps:
app_name:
uuid: <UUID_APP>
image: <NOM_IMAGE>
$cd openfactory/apps/<APP>
$docker build -t <NOM_IMAGE> <CHEMIN_VERS_DOCKERFILE>
$ofa apps up <CHEMIN_VERS_FICHIER_YML>
$ofa apps down <CHEMIN_VERS_FICHIER_YML>
Cette application OpenFactory sert de couche de service pour accéder aux données en temps réel à partir des assets déployés sur OpenFactory.
Lorsque OpenFactory lance les openfactory apps, elles ne sont pas mises sur le même réseau que OpenFactory. Comme le dashboard se connecte à factory-net, il faut rouler docker network connect factory-net ofa-api après avoir lancé les ofa apps pour que le dashboard ait accès à ofa-api.
En se connectant au endpoint ws://ofa-api:8000/ws/devices/<device_uuid>, l'app permet à un client WebSocket de recevoir des updates en temps réel pour le device demandé (qui correspond à un asset OpenFactory). L'application s'occupe de créer un stream dérivé dédié à cet asset lors de la connection d'un nouveau client.
{
'asset_uuid': 'IVAC',
'data': {
'ID': 'A2BlastGate',
'VALUE': 'CLOSED',
'TIMESTAMP': '2025-07-21T09:14:49.829000000'
}
}
*ID correspond au dataitem_id
Pour demander la liste des devices disponibles actuellement, il faut accéder au endpoint ws://ofa-api:8000/ws/devices. Ce endpoint sert à l'initialisation du dashboard.
{
'event': 'devices_list',
'timestamp': 1755609624.7116494,
'devices': [{
'device_uuid': 'IVAC',
'dataitems': {
'A2BlastGate': 'CLOSED',
'A2ToolPlus': 'OFF',
'A3BlastGate': 'CLOSED',
'A3ToolPlus': 'OFF',
'avail': 'AVAILABLE',
'ivac_tools_status': 'No more than one connected tool is powered ON'
},
'durations': {}
}]
}
** Ici, le champ "durations" n'est pas toujours présent; il s'agit des données sur le calcul de durée de puissance des dataitems de ce device.
Ce type d'applications sert principalement à créer des streams qui font la vérification de la validité des états de certains outils (Ex.: voir les streams system_health.sql) ou qui font des calculs sur les données reçues (Ex.: voir les streams usage_duration.sql et moving_average.sql).
Pour des calculs plus complexes, il est aussi possible d'implémenter un consumer et un producer Kafka combinés avec des streams pour effectuer le calcul complexe dans l'app Python puis renvoyer le résultat dans un nouveau stream (Ex.: Voir application de calcul de spectrogramme).