https://github.com/SASE-Space/open-process-library
Open Process Library — Analyse
C'est quoi ?
Une bibliothèque open source (MIT) de blocs d'automatisation industrielle, compatible avec le standard MTP (Module Type Package), conçue pour être cross-vendor — applicable aussi bien aux systèmes legacy (PLC/SCADA) qu'aux nouvelles architectures OPA.
En résumé : c'est une tentative de standardiser les "briques de base" de l'automatisation de procédé, là où chaque intégrateur réinvente la roue depuis 30 ans.
Contexte du problème adressé
Situation actuelle (avant OPL)
────────────────────────────────────────────────────────────
Siemens TIA → bibliothèque Siemens, fermée, propriétaire
Rockwell → bibliothèque Allen-Bradley, idem
DCS Schneider → idem, dialect IEC-61131 propriétaire
Intégrateurs → chacun sa lib maison, non transférable
Résultat : murs propriétaires, coût de migration énorme,
scalabilité nulle, digitalisation bloquée
Le standard MTP a déjà fait le travail de distiller les interfaces communes en industrie de procédé, mais ne fournit aucune bibliothèque — cela reste à la charge des vendeurs et intégrateurs.
Architecture conceptuelle
┌─────────────────────────────────────────────────────┐
│ NIVEAU OPL (Open Process Library) │
│ Specs Markdown → Code Generation (Deno/TypeScript) │
├──────────────────────────┬──────────────────────────┤
│ OPL Block │ OPL Block │
│ (ex: AnalogMeasurement) │ (ex: SolenoidValve) │
│ ↕ wraps │ ↕ wraps │
│ MTP Block (AnaMon) │ MTP Block (MonBinVlv) │
├──────────────────────────┴──────────────────────────┤
│ NIVEAU MTP — interfaces standardisées │
├─────────────────────────────────────────────────────┤
│ Beckhoff TwinCAT │ Siemens │ ...autres targets │
│ (PLCOpenXML export) │
└─────────────────────────────────────────────────────┘
Point clé : OPL a une architecture en couches où ses blocs wrappent les blocs d'interface MTP. Cela permet de supporter à la fois les blocs fournis par les vendeurs et de fournir une alternative open source.
Les 8 blocs prioritaires (80% des cas)
Pipeline de génération de code
Les Function Blocks sont décrits dans des tables Markdown (specs), puis un script Deno lit ces specs + des templates Nunjucks pour générer le code cible pour chaque système.
specs/.md (interfaces + logique)
+
templates/.nunjucks (format cible)
↓
scripts/generate.ts (Deno)
↓
PLCOpenImport.xml → import Beckhoff TwinCAT
(autres cibles à venir)
C'est le vrai apport architectural : SPEC → CODE déterministe, indépendant de l'IA, reproductible.
Maturité / Limites honnêtes
Le projet est actuellement en développement. Le workflow de génération de code pour les blocs PLC est prêt, mais rien n'a encore été fait côté HMI hormis quelques concepts de design.
• 56 stars, 7 forks → très confidentiel, pas encore adopté
• Seul target disponible : Beckhoff TwinCAT
• Pas de releases publiées
• Appel actif à collaboration (experts PLC/DCS, SCADA, system integrators)
Pertinence pour ton contexte
En tant qu'ingénieur process / digital twin, c'est un projet à surveiller :
• Standard MTP : directement lié à la modularisation des procédés industriels, pertinent pour les déploiements OIAnalytics
• Approche spec-first : proche de ta philosophie de documentation formelle des jumeaux numériques
• Limitation actuelle : trop tôt pour usage en production sans revue approfondie — ils le disent eux-mêmes
https://github.com/SASE-Space/open-process-library
Open Process Library — Analyse
C'est quoi ?
Une bibliothèque open source (MIT) de blocs d'automatisation industrielle, compatible avec le standard MTP (Module Type Package), conçue pour être cross-vendor — applicable aussi bien aux systèmes legacy (PLC/SCADA) qu'aux nouvelles architectures OPA.
En résumé : c'est une tentative de standardiser les "briques de base" de l'automatisation de procédé, là où chaque intégrateur réinvente la roue depuis 30 ans.
Contexte du problème adressé
Situation actuelle (avant OPL)
────────────────────────────────────────────────────────────
Siemens TIA → bibliothèque Siemens, fermée, propriétaire
Rockwell → bibliothèque Allen-Bradley, idem
DCS Schneider → idem, dialect IEC-61131 propriétaire
Intégrateurs → chacun sa lib maison, non transférable
Résultat : murs propriétaires, coût de migration énorme,
scalabilité nulle, digitalisation bloquée
Le standard MTP a déjà fait le travail de distiller les interfaces communes en industrie de procédé, mais ne fournit aucune bibliothèque — cela reste à la charge des vendeurs et intégrateurs.
Architecture conceptuelle
┌─────────────────────────────────────────────────────┐
│ NIVEAU OPL (Open Process Library) │
│ Specs Markdown → Code Generation (Deno/TypeScript) │
├──────────────────────────┬──────────────────────────┤
│ OPL Block │ OPL Block │
│ (ex: AnalogMeasurement) │ (ex: SolenoidValve) │
│ ↕ wraps │ ↕ wraps │
│ MTP Block (AnaMon) │ MTP Block (MonBinVlv) │
├──────────────────────────┴──────────────────────────┤
│ NIVEAU MTP — interfaces standardisées │
├─────────────────────────────────────────────────────┤
│ Beckhoff TwinCAT │ Siemens │ ...autres targets │
│ (PLCOpenXML export) │
└─────────────────────────────────────────────────────┘
Point clé : OPL a une architecture en couches où ses blocs wrappent les blocs d'interface MTP. Cela permet de supporter à la fois les blocs fournis par les vendeurs et de fournir une alternative open source.
Les 8 blocs prioritaires (80% des cas)
Pipeline de génération de code
Les Function Blocks sont décrits dans des tables Markdown (specs), puis un script Deno lit ces specs + des templates Nunjucks pour générer le code cible pour chaque système.
specs/.md (interfaces + logique)
+
templates/.nunjucks (format cible)
↓
scripts/generate.ts (Deno)
↓
PLCOpenImport.xml → import Beckhoff TwinCAT
(autres cibles à venir)
C'est le vrai apport architectural : SPEC → CODE déterministe, indépendant de l'IA, reproductible.
Maturité / Limites honnêtes
Le projet est actuellement en développement. Le workflow de génération de code pour les blocs PLC est prêt, mais rien n'a encore été fait côté HMI hormis quelques concepts de design.
• 56 stars, 7 forks → très confidentiel, pas encore adopté
• Seul target disponible : Beckhoff TwinCAT
• Pas de releases publiées
• Appel actif à collaboration (experts PLC/DCS, SCADA, system integrators)
Pertinence pour ton contexte
En tant qu'ingénieur process / digital twin, c'est un projet à surveiller :
• Standard MTP : directement lié à la modularisation des procédés industriels, pertinent pour les déploiements OIAnalytics
• Approche spec-first : proche de ta philosophie de documentation formelle des jumeaux numériques
• Limitation actuelle : trop tôt pour usage en production sans revue approfondie — ils le disent eux-mêmes