EMS Builder : architecture, modes de fonctionnement et limites

Edge-EMS Builder se situe entre les équipements de terrain et les systèmes supérieurs. Fondé sur l’autonomie en périphérie, il peut s’étendre à la coordination cloud-edge et multinœud. Il organise lecture des données, calcul d’état, évaluation des règles et exécution des actions en une boucle de contrôle continue.

Cet article répond à quatre questions :

1. Comment l’architecture d’Edge-EMS Builder est-elle structurée ?
2. Quels modes de fonctionnement sont possibles ?
3. Comment assembler les capacités pour répondre à un besoin métier ?
4. Jusqu’où les connexions filaires, sans fil et intersites peuvent-elles étendre le système ?

Les modes de fonctionnement désignent ici l’exécution du système, et non la collaboration commerciale. Pour Platform, Solution et Co-create, consultez les modes de service Edge-EMS Builder.

1. Architecture : une boucle entre terrain, périphérie et cloud

Edge-EMS Builder s’exécute en périphérie ; CommBridge masque les différences de protocoles terrain, tandis que MQTT, WebSocket et HTTP relient cloud, interface et systèmes tiers.

Couche	Responsabilités principales	Objets / canaux typiques
Métier et cloud	Supervision unifiée, configuration distante, diffusion de stratégies, analyse d’exploitation et intégration métier tierce	JelinaCloud, cloud client, SCADA, systèmes de dispatching ; MQTT / HTTP
Interaction et intégration	Diffusion temps réel vers l’interface, réception de commandes et accès en lecture/écriture pour les systèmes externes	Interface Web personnalisée, services backend ; WebSocket / HTTP
Moteur edge EMS Builder	Données unifiées, calcul temps réel, décision stratégique, actions, alarmes, partage et extension de configuration	Modèle de données, moteur d’expressions, plans de déclenchement, cibles de partage, UDE
Acquisition CommBridge	Adaptation aux protocoles bas niveau et conversion des points terrain en données reconnues par EMS Builder	Modbus, OPC UA, S7, série, IEC 101/104, CAN, etc.
Équipements de terrain	Données temps réel et exécution finale des commandes	PCS, BMS, compteurs, bornes de recharge, onduleurs photovoltaïques, capteurs, équipements tiers

Pourquoi séparer les couches

• Un changement d’équipement n’impose pas de réécrire la stratégie : protocoles et points sont adaptés dans la couche d’acquisition ; les stratégies utilisent un dataKey uniforme.
• Les évolutions métier ne modifient pas les pilotes de communication : seuils, plages horaires et règles de contrôle sont ajustés dans la couche de stratégie, sans modifier l’implémentation des protocoles.
• L’interface est découplée du moteur de contrôle : Edge-EMS Builder n’impose pas d’interface fixe ; l’interface peut s’abonner aux données et lancer des commandes via des canaux standard.
• Une boucle locale peut subsister sans cloud : les décisions et actions essentielles sont exécutées en périphérie. Les capacités hors ligne dépendent de la configuration et des dépendances externes du projet.

2. Déroulement d’un cycle de contrôle

Toute stratégie métier peut se décomposer en quatre étapes : acquisition → calcul → décision → exécution.

Étape	Rôle d’EMS Builder	Exemple : soutien de capacité d’une zone de distribution
① Acquisition	CommBridge lit les points bruts et les synchronise avec EMS Builder	Lecture de la charge du transformateur, de l’état PCS et du SOC
② Calcul	Le moteur d’expressions calcule états intermédiaires, marges et risques	Calcul du déficit de capacité et de la puissance de décharge disponible
③ Décision	Le plan de déclenchement évalue les conditions et choisit les actions	Activation du soutien lorsque la charge approche de la limite et que le SOC le permet
④ Exécution	Écriture dans les équipements, alarmes, publication MQTT ou diffusion vers l’interface	Envoi de la consigne de puissance au PCS et remontée de l’état d’exécution

La puissance, le SOC et les états après exécution sont acquis à nouveau pour le cycle suivant. Une stratégie stable doit aussi prévoir seuils de démarrage et d’arrêt, filtrage anti-rebond, priorités, anomalies de communication, protections et reprise manuelle, au-delà d’un simple IF / THEN.

Deux mécanismes de soutien de la boucle

• Cibles de partage : les données d’autres nœuds Edge-EMS Builder participent aux expressions et conditions de déclenchement comme les données locales, permettant la coordination entre équipements.
• Extension dynamique des unités d’équipement (UDE) : un modèle est défini une seule fois pour des équipements similaires ; chaque nouvelle instance matérialise automatiquement les configurations d’agrégation, de groupes et de partage, réduisant les tâches répétitives.

3. Trois modes de fonctionnement

Les trois modes utilisent le même moteur Edge-EMS Builder ; ils peuvent fonctionner séparément ou être combinés dans un projet.

1. Autonomie en périphérie

Acquisition, calcul, décision et contrôle sont réalisés sur le site. Ce mode convient aux exigences élevées de réactivité, de continuité et de localisation des données.

Chaîne type : équipements terrain → CommBridge → stratégie Edge-EMS Builder → équipements terrain.

Besoins adaptés : charge/décharge par plage horaire, anti-injection, contrôle de la puissance appelée, interverrouillage et alarmes sur site.

Points de conception : priorité aux protections locales ; prévoir mise en cache, expiration et modes dégradés pour les dépendances externes telles que tarifs, météo ou commandes cloud.

2. Coordination cloud-edge

La périphérie exécute en temps réel ; le cloud assure gestion unifiée, orchestration des stratégies, maintenance distante ou analyses intersites. MQTT fournit publication/abonnement bidirectionnels et réponses. Edge-EMS Builder peut aussi obtenir des informations externes autorisées via HTTP.

Chaîne type : envoi des objectifs/stratégies depuis le cloud → validation et exécution en périphérie → retour des résultats au cloud.

Besoins adaptés : supervision multisite, réglage distant, diffusion de courbes programmées, analyse d’exploitation et alarmes centralisées.

Points de conception : les objectifs cloud ne doivent pas contourner les limites de sécurité du site. En cas de déconnexion, définir explicitement s’il faut poursuivre, conserver la dernière valeur valide ou appliquer une stratégie de sécurité.

3. Coordination multinœud

Plusieurs instances Edge-EMS Builder synchronisent leurs données via les cibles de partage. Le nœud maître peut agréger l’état des esclaves et effectuer un calcul global ; les esclaves peuvent prendre de nouvelles tâches après un changement de rôle.

Chaîne type : partage des données des esclaves → calcul de l’objectif du site par le maître → exécution des allocations par chaque nœud.

Besoins adaptés : répartition de puissance multiéquipement, commande groupée interzone, équilibrage de charge du site, redondance et changement de rôle.

Points de conception : définir relations maître-esclave, périodes de partage, validité des données, états d’anomalie réseau et stratégies locales après perte de communication.

4. Capacités principales et soutien à l’exploitation

Capacité	Problème résolu	Place dans la boucle
Modèle de données	Organisation uniforme des données brutes, par plage horaire, agrégées et partagées	Base de l’acquisition et du calcul
Moteur d’expressions	Sommes, filtrage, évaluation d’état et calculs interéquipement en Lua	Calcul
Plans de déclenchement	Orchestration des règles métier par condition + action	Décision et exécution
Coordination cloud-edge MQTT	Publication, abonnement aux commandes, réponses et communication bidirectionnelle	Connexion cloud-edge
Coordination des équipements et cibles de partage	Partage des données entre nœuds et participation aux calculs mutuels	Coordination distribuée
Extension dynamique des unités d’équipement (UDE)	Modèles, espaces réservés dynamiques et réconciliation des instances existantes	Extension à grande échelle
Cycle de vie des alarmes	Suivi des anomalies, retours à la normale et résolutions manuelles	État et traitement
Historique et archivage	Analyse des tendances, export asynchrone, archivage à plusieurs plans	Conservation des données
Exploitation et maintenance	Capacité, origines de configuration, gel de maintenance et journaux de contrôle	Continuité d’exploitation

La diffusion temps réel et le contrôle direct pour l’interface fournit également un canal WebSocket aux interfaces et systèmes backend, pour s’abonner aux données en temps réel et lancer des commandes dans le respect des droits et contraintes de sécurité.

5. Assembler les capacités selon le besoin

Edge-EMS Builder n’impose pas une stratégie unique à tous les projets ; il applique une même méthode de construction à différents besoins :

Besoin = données requises + règles de calcul + conditions de déclenchement + actions d’exécution + protection et validation

Besoin	Données requises	Calcul et décision	Actions typiques
Écrêtage des pointes / contrôle de la puissance appelée	Puissance au raccordement, SOC, état PCS, objectif de puissance appelée	Déficit de puissance et capacité disponible de charge/décharge	Consigne PCS et enregistrement de l’état de stratégie
Anti-injection	Puissance au raccordement, puissance photovoltaïque, puissance disponible du stockage	Détection de la tendance à l’injection et limitation de la sortie	Absorption par le stockage, limitation photovoltaïque ou alarme
Équilibrage de charge des bornes	Marge du transformateur, besoin et état de chaque borne	Puissance attribuable et répartition selon les règles	Ajustement des plafonds de puissance des bornes
Coordination multiéquipement	SOC, limites de puissance et disponibilité de chaque unité	Répartition de l’objectif du site selon SOC, capacité ou priorité	Envoi de sous-objectifs à plusieurs PCS/nœuds
Plages horaires et courbes programmées	Plage horaire, tarif, SOC, prévision de charge	Correspondance avec la plage courante et vérification des limites de protection	Changement des objectifs de charge/décharge et retour des résultats
Pilotage par informations externes	Tarifs, météo, programme de production, prévisions	Vérification de la validité des données et utilisation pour l’optimisation ou la décision	Ajustement des objectifs, mode dégradé ou alarme

Exemple : traduire un besoin métier en configuration EMS Builder

Besoin :

« Si la puissance au raccordement dépasse 800 kW et que le SOC est supérieur à 20%, le stockage décharge automatiquement ; il cesse lorsque la puissance descend à 760 kW. »

La mise en œuvre nécessite au minimum :

1. Les données de puissance au raccordement, SOC, disponibilité PCS et puissance maximale de décharge.
2. Les expressions de calcul du déficit de capacité et de la puissance cible de décharge.
3. Les deux seuils : démarrage à 800 kW, arrêt à 760 kW.
4. Les actions d’écriture de puissance PCS, la limitation de fréquence et le traitement des échecs.
5. Les protections SOC/température/alarmes, la reprise manuelle et la stratégie en cas d’anomalie de communication.
6. Les tests de fonctionnement normal, aux limites, sans réseau et avec défaillance d’équipement.

Edge-EMS Builder fournit donc l’infrastructure pour exprimer et exécuter les stratégies. Leur sécurité et leur exactitude dépendent toujours de la définition des besoins, des capacités des équipements et de la qualité de la validation.

6. Possibilités des connexions filaires, sans fil et intersites

La logique principale d’Edge-EMS Builder est découplée du support réseau, mais une connectivité disponible ne signifie pas que toute liaison sans fil convient au contrôle temps réel.

Réseau IP de niveau supérieur

MQTT/MQTTS, HTTP et WebSocket fonctionnent sur un réseau IP accessible. Selon le matériel et le réseau, le projet peut utiliser Ethernet, Wi-Fi, 4G/5G ou un réseau privé pour joindre le cloud et d’autres nœuds.

Il s’agit d’une possibilité architecturale, et non d’une promesse de module sans fil intégré au matériel edge Edge-EMS Builder. Les capacités réelles doivent être vérifiées selon le matériel, le réseau opérateur, la couverture du site et les exigences de certification.

Réseau des équipements terrain

La connexion sans fil des PCS, BMS et compteurs dépend des équipements, de la passerelle sans fil et de l’adaptation des protocoles dans CommBridge. Le sans-fil est un moyen de transport ; il ne résout pas automatiquement le mappage des registres, les contraintes temps réel ou les droits de contrôle.

Précautions supplémentaires pour les liaisons sans fil ou étendues

• Latence et gigue : privilégier une boucle locale pour le contrôle à la milliseconde ; les liaisons étendues conviennent davantage aux objectifs, à la remontée de données et à une coordination sans temps réel strict.
• Déconnexion et expiration des données : indiquer la validité des données partagées et définir maintien, mode dégradé ou arrêt après une déconnexion.
• Sécurité : utiliser TLS, authentification, moindre privilège et audit ; éviter d’exposer directement les interfaces de contrôle sur Internet.
• Protections sur site : interverrouillages matériels, protections d’équipements et contrôle local de sécurité ne doivent pas dépendre du cloud ou d’une liaison instable.

Le principe général recommandé est donc :

Conserver le contrôle temps réel en périphérie ; les objectifs d’optimisation peuvent venir du cloud. Le sans-fil assure la connexion ; sécurité et reprise après défaillance assurent la protection.

7. De la connexion sans fil à l’extension des usages

Trois conditions permettent d’évaluer le périmètre d’Edge-EMS Builder :

Condition	Questions à résoudre
Données accessibles	Les états requis peuvent-ils être acquis de façon stable, depuis une source fiable et avec une validité temporelle connue ?
Règles exprimables	Objectifs, contraintes, priorités et chemins d’exception peuvent-ils être décrits et testés explicitement ?
Actions exécutables	L’équipement ou le système fournit-il une interface de contrôle conforme, autorisable et vérifiable ?

Lorsque ces conditions sont réunies, Edge-EMS Builder peut dépasser l’EMS traditionnel pour la commande groupée d’équipements de campus, la modulation de charges flexibles, l’asservissement aux programmes de production ou la coordination environnement-énergie, selon une boucle perception → décision → exécution.

Les limites suivantes restent applicables :

• Edge-EMS Builder ne remplace ni les protections du fabricant, ni les certifications de sécurité, ni les interverrouillages du site.
• Les prévisions externes ou résultats IA nécessitent validation de plage, gestion des délais et limitation de sécurité ; ils ne doivent pas contourner les règles déterministes de contrôle des équipements critiques.
• La coordination multiéquipement dépend des horloges, du réseau, de la qualité des données et de l’algorithme d’allocation des objectifs.
• Toute nouvelle stratégie doit être validée en simulation ou en environnement de test avant une mise en production contrôlée.

8. Dimensionnement : partir des mesures réelles

Le scénario recommandé S3.5 validé sur AFE-E630 comprend une charge d’acquisition configurée de 5,000 points/seconde, 30 calculs agrégés, 90 Trigger/seconde, 20 MQTT/seconde et 10 tâches de coordination/seconde, avec stockage sur changement et enregistrement au plus tard toutes les 10 secondes.

Dans la campagne du 2026-07-29 (rapport v1.3), les latences P95 Trigger / MQTT de ce scénario sont de 56 ms / 77 ms, le P95 CPU de la machine de 71.09% et le P95 de sa mémoire réelle de 41.41%. Pour le dimensionnement initial en production, prévoyez environ 20% de marge d’ingénierie par rapport à cette charge testée.

Ces résultats reposent sur un matériel et un logiciel définis et 2,000 échantillons valides de courte durée. Ils ne démontrent pas une stabilité sur 72 heures et ne peuvent pas être extrapolés directement à d’autres scripts, tailles de messages ou volumes de base. Consultez le rapport AFE-E630.

Liste de vérification avant mise en service

• Liste des points, dimensions physiques, précision, droits de lecture/écriture et valeurs anormales confirmés.
• Démarrage, arrêt, anti-rebond, priorités et résolution des conflits de stratégie définis.
• Modes dégradés prévus pour perte réseau, données expirées, équipements hors ligne et échecs d’écriture.
• Protections d’équipements, interverrouillages matériels, reprise manuelle et audit des droits indépendamment opérationnels.
• Tests de charge réalisés avec scripts réels, tailles de messages, historique de base et matériel cible.
• Gestion des versions de configuration, retour arrière, journaux et surveillance des alarmes en place.

Étapes suivantes

• Pour la valeur produit et les cas d’usage : Présentation d’Edge-EMS Builder.
• Pour comprendre les objets de configuration : Concepts fondamentaux.
• Pour le processus de configuration métier : Renforcement temporaire de capacité ou Équilibrage de charge d’un groupe de bornes.
• Pour l’intégration interface et cloud : Diffusion temps réel et contrôle direct, Coordination cloud-edge MQTT.