Comment ajouter la communication par API à des produits électriques existants

La communication par ligne électrique (PLC) permet aux appareils électriques d’échanger des données via les lignes électriques existantes au lieu de nécessiter un câble de communication séparé. Pour les OEM et les fabricants de produits électriques, cela crée une opportunité d’ajouter à distance des capacités de surveillance, de configuration, de contrôle, de diagnostic et de réseau aux produits existants.

La bonne nouvelle, c’est que l’ajout de communications par API ne signifie pas nécessairement repenser l’ensemble du produit électrique.

Dans de nombreux cas, un module de communication PLC embarqué peut être intégré au MCU ou contrôleur existant du produit via une interface standard telle qu’UART ou SPI. Le module PLC gère la communication par ligne électrique tandis que le contrôleur hôte continue de gérer les principales fonctions applicatives du produit.

Cet article explique une approche pratique pour ajouter la communication des PLC à un produit électrique existant, de l’architecture et de l’intégration matérielle au développement du firmware et aux tests en production.

Que signifie ajouter la communication par API à un produit existant ?

Un produit électrique existant peut déjà contenir :

• Un MCU ou processeur principal
• Alimentation électrique
• Capteurs
• Relais ou MOSFETs
• Interfaces de contrôle
• Interfaces de communication
• Firmware applicatif spécifique au produit

L’ajout de la communication par PLC introduit une autre couche de communication permettant au produit d’échanger des données via sa connexion d’alimentation.

Une architecture typique ressemble à ceci :

Produit électrique existant

→ Hôte MCU
→ Firmware des applications
→ Fonctions de contrôle existantes

Nouvelle couche de communication des API

→ module PLC
→ Circuit de couplage
→ Ligne électrique
→ Réseau PLC

Le MCU hôte communique avec le module PLC, tandis que le module PLC gère la communication physique et au niveau du protocole via la ligne électrique. Pour plus d’informations, consultez IEEE 1901 standard.

Cette architecture permet aux fabricants d’ajouter une connectivité API tout en conservant une grande partie de la conception de leurs produits existants.

Pourquoi utiliser un module API au lieu de concevoir du matériel API à partir de zéro ?

Pour de nombreux projets OEM, développer le circuit de communication complet de l’API depuis le niveau du chipset peut considérablement augmenter le temps d’ingénierie.

Un Module PLC embarqué peut simplifier le processus d’intégration.

Un module PLC typique peut intégrer :

• Modem/SoC PLC
• MCU ou processeur
• PLC PHY
• Conducteur de ligne
• Interface de communication
• Fonctions de communication par ligne électrique
• Composants de soutien

Selon l’architecture du module, le produit hôte peut seulement avoir à fournir :

1. Puissance
2. UART, SPI ou une autre interface prise en charge
3. Couplage ligne électrique
4. Intégration du firmware

Cette approche peut réduire la quantité de développement matériel spécifique aux API requis par l’OEM.

Par exemple, les modules PLC embarqués de MicroNature incluent des modèles conçus pour l’intégration avec des contrôleurs hôtes et fournissent des interfaces telles que UART, PWM, GPIO, ADC, SPI ou I²C, selon le modèle.

Étape 1 : Identifier l’architecture produit existante

Avant de choisir un module PLC, comprenez d’abord le produit électrique existant.

Documentez ce qui suit :

1. Entrée de puissance

Déterminez :

• Entrée AC ou DC
• Tension d’entrée
• Fréquence
• Courant maximal
• Exigences d’isolation
• Topologie de l’alimentation

Par exemple :

• Contrôleur 12 V CC
• Dispositif industriel 24 V
• Équipement 110/120 V AC
• Équipements d’éclairage AC 220/230 V
• Équipements électriques triphasés

Les exigences d’intégration des PLC peuvent varier considérablement selon l’architecture d’alimentation.

2. MCU existant

Identifier :

• Fabricant de MCU
• Famille du MCU
• Architecture CPU
• GPIO disponible
• Interfaces UART
• Interfaces SPI
• Interfaces I²C
• Mémoire disponible
• Architecture du firmware existante

L’interface hôte disponible est particulièrement importante lors du choix d’un module API.

3. Espace disponible sur les circuits imprimés

À vérifier :

• Empreinte des modules
• Emplacement du connecteur
• Exigences d’antenne, le cas échéant
• Distance d’isolation
• Garde de jeu haute tension
• Conditions thermiques
• Limitations des boîtiers mécaniques

Un module PLC doit être traité comme faisant partie intégrante de la conception électrique complète, et non simplement comme un autre CI.

Étape 2 : Sélectionnez le module PLC approprié

Le module PLC doit être sélectionné en fonction des exigences réelles de l’application.

Les paramètres importants incluent :

Paramètre	Questions à considérer
Norme API	Quel protocole ou norme API est requis ?
Débit de données	Quelle quantité de données doit être transmise ?
Interface	UART, SPI, GPIO, etc. ?
Alimentation électrique	Quelle tension le module nécessite-t-il ?
Topologie du réseau	Point-à-point, étoile, maillage ou autre ?
Distance de communication	Jusqu’où les appareils doivent-ils communiquer ?
Environnement sonore	Le réseau électrique est-il bruyant électriquement ?
Bande de fréquences	Est-ce que cela correspond aux exigences de candidature ?
Micrologiciel	Quel protocole/API le module propose-t-il ?
Certification	Quelles exigences régionales s’appliquent ?

Par exemple, un OEM développant un contrôleur intelligent peut prioriser un module PLC compact avec communication UART, tandis qu’un produit industriel peut nécessiter plus d’interfaces et une meilleure immunité au bruit.

L’essentiel est de sélectionner le module basé sur le système complet, plutôt que de simplement choisir le module avec le taux de données théorique le plus élevé.

Étape 3 : Connecter le module PLC au MCU hôte

L’une des architectures les plus simples est :

Circuit de couplage ↔ du module MCU ↔ UART ↔ ↔, ligne électrique

Le MCU existant reste responsable des fonctions principales de l’application.

Le module PLC gère la communication avec d’autres dispositifs API.

Par exemple, le MCU hôte peut envoyer une commande telle que :

Définir l’ID de l’appareil = 1025

Le module PLC transmet ensuite le paquet de communication correspondant via la ligne électrique.

Un appareil distant peut renvoyer des données via le même réseau.

Cette séparation est utile car elle maintient la logique de contrôle existante de l’application relativement indépendante de la couche de communication des API.

Étape 4 : Intégrer le circuit de couplage PLC

Le circuit de couplage relie le circuit de communication de l’API à la ligne électrique.

C’est l’un des aspects les plus importants de la conception du matériel des PLC.

Une architecture simplifiée est la suivante :

PLC Module

↓

Conducteur de ligne

↓

Réseau de couplage

↓

Ligne électrique

Le circuit de couplage doit généralement répondre à plusieurs exigences :

• Injection de signal
• Extraction du signal
• Isolation de tension lorsque nécessaire
• Adaptation d’impédance
• Filtrage
• Protection
• Considérations sur les mensualités
• Protection contre les surtensions

La conception exacte de l’accouplement dépend de :

• Bande de fréquences PLC
• Tension du réseau électrique
• Architecture AC/DC
• Exigences d’isolation
• Distance de communication cible
• Exigences réglementaires
• Environnement sonore

Par conséquent, un circuit de couplage ne devrait pas simplement être copié d’un autre produit sans vérifier si ses conditions électriques sont compatibles.

Pour une explication technique plus approfondie, consultez votre article prévu/lié :

Guide de conception des circuits de couplage PLC pour dispositifs de communication par ligne électrique embarquée

Étape 5 : Considérez l’alimentation électrique et l’isolation

L’ajout d’un module PLC modifie l’architecture électrique du produit.

Le module peut nécessiter une alimentation basse tension dédiée.

Par exemple :

Alimentation secteur

→ Alimentation électrique

→ 12 V / 5 V / 3,3 V

→ module PLC

En même temps, le signal PLC peut devoir être couplé à la ligne électrique.

Les ingénieurs doivent évaluer attentivement :

• Distance de rampe
• Dégagement
• Barrière d’isolement
• Mise au sol
• Bruit en mode commun
• Protection contre les surtensions
• Protection ESD
• Immunité à l’EFT/burst
• Environnement de foudre/surtension

Cela devient particulièrement important pour les produits industriels et extérieurs.

Étape 6 : Intégrer les fonctions API dans le firmware existant

L’intégration matérielle n’est qu’une partie du projet.

Le firmware de l’hôte doit également communiquer avec le module PLC.

Une architecture logicielle pratique est la suivante :

Couche application

↓

PLC Communication API

↓

Pilote UART/SPI

↓

PLC Module

L’application existante peut alors appeler des fonctions simples telles que :

PLC_Send()
PLC_Receive()
PLC_SetAddress()
PLC_GetStatus()
PLC_ReadNode()
PLC_WriteNode()

L’API réelle dépend du module PLC et du protocole de communication.

Une bonne architecture logicielle doit séparer la communication des API de la logique d’application centrale du produit.

Cela facilite la tâche de :

• Débogue du système
• Remplacer le module de communication
• Mise à jour du protocole PLC
• Ajouter de nouvelles commandes
• Maintenir le firmware existant

Étape 7 : Définir le protocole de données

Avant la production de masse, définissez quelles informations le produit électrique doit échanger sur le réseau PLC.

Par exemple, un contrôleur industriel pourrait transmettre :

• ID de l’appareil
• Statut opérationnel
• Tension
• Actuel
• Température
• Consommation d’énergie
• État d’alarme
• Paramètres de configuration

Une structure de communication simple pourrait être :

ID de l’appareil
↓
Commandement
↓
Longueur des données
↓
Données
↓
Somme de contrôle

Pour un contrôleur d’éclairage, les données peuvent inclure :

ID de lampe
Luminosité
Tension
Actuel
Puissance
Énergie
Statut de la faille

Pour un autre produit électrique, la charge utile peut être complètement différente.

Le principe important est que Le PLC fournit le canal de communication ; l’OEM définit les données de l’application.

Étape 8 : Tester la communication des PLC dans un environnement électrique réel

Un module PLC qui communique avec succès sur un banc de développement peut se comporter différemment à l’intérieur du produit final.

Cela s’explique par le fait que le produit électrique réel contient :

• Alimentations électriques à découpage
• Moteurs
• Relais
• Onduleurs
• LED
• Condensateurs
• Filtres
• Transformateurs
• Autres charges électroniques

Ces composants peuvent provoquer un bruit électrique important.

Les tests doivent donc être effectués avec le Matériel produit réel, pas seulement avec un panneau d’essai PLC de laboratoire.

Les tests importants incluent :

Distance de communication

Testez la distance maximale pratique de communication dans des conditions de câblage réalistes.

Perte de paquets

Mesurer la fiabilité de la communication sur des transmissions répétées.

Bruit électrique

Testez pendant que les principaux composants de commutation fonctionnent.

Démarrage et arrêt

Vérifiez si la communication des PLC reste stable pendant :

• Alimentation
• Arrêt de puissance
• Redémarrage
• Commutation de charge

Évolutivité réseau

Testez plusieurs appareils simultanément.

Fonctionnement de longue durée

Faites fonctionner le réseau PLC en continu pour identifier les problèmes de communication intermittents.

Étape 9 : Tester différentes charges

Les charges électriques peuvent fortement influencer la performance de communication des PLC.

Par exemple, testez le système avec :

• Charge normale
• Charge maximale
• Charge minimale
• Charges de commutation
• Charges des moteurs
• Haut-parleurs LED
• Alimentations électriques
• Charges inductives

L’objectif est de vérifier que le signal PLC reste fiable dans les conditions que le produit final connaîtra réellement.

Cela est particulièrement important pour les applications industrielles des PLC.

Étape 10 : Optimiser la disposition du PCB

L’intégration des PLC nécessite également une disposition soignée des PCB.

Gardez les sections haute tension et basse tension séparées correctement.

Faites attention à :

• Chemins de signal PLC
• Composants de couplage
• Traces à fort courant
• Nœuds de commutation
• Plans de masse
• Barrières d’isolation
• Composants de protection
• Circuits sensibles aux EMI

Évitez de placer des circuits PLC sensibles immédiatement à côté des composants de commutation haute fréquence autant que possible.

Le PCB final doit être évalué comme un système EMC complet plutôt que de traiter le module PLC comme un composant isolé.

Exemple d’intégration des API

Considérez un contrôleur d’éclairage industriel existant.

Le design original contient :

Pilote LED → → Lampe du MCU

Le fabricant souhaite ajouter la télécommande et la surveillance.

Au lieu de repenser le contrôleur complet, le fabricant peut ajouter :

Circuit d’accouplement ↔ du module PLC ↔ ↔ MCU Ligne d’alimentation

Le MCU existant peut continuer à contrôler :

• Luminosité LED
• Opération ON/OFF
• Capteurs
• Protection locale

Le module PLC ajoute la communication entre le contrôleur et la passerelle centrale.

L’architecture résultante peut prendre en charge des fonctions telles que :

• Télécommande ON/OFF
• Atténuation
• Adressage des dispositifs
• Surveillance de l’énergie
• Déclaration des défauts
• Configuration à distance
• Contrôle programmé

Cette approche peut être particulièrement utile lorsque le câblage électrique existant est déjà disponible et que l’installation de nouveaux câbles de communication serait coûteuse ou peu pratique.

Peut-on ajouter un API sans changer le MCU existant ?

Parfois, oui.

Si le produit existant dispose déjà d’une interface UART, SPI ou d’une autre compatible disponible, l’intégration peut souvent être relativement simple.

Cependant, si le MCU ne dispose pas d’interface de communication disponible, d’une mémoire limitée ou de ressources de traitement insuffisantes, des modifications matérielles ou de firmware supplémentaires peuvent être nécessaires.

Les approches possibles incluent :

Option 1 : Utiliser un UART existant

Généralement l’architecture la plus simple.

Option 2 : Utiliser SPI

Utile lorsque la communication hôte-module à plus grande vitesse est nécessaire.

Option 3 : Ajouter un MCU secondaire

Cela peut séparer la communication des PLC du régulateur d’application d’origine.

Option 4 : Remplacer la manette existante

Cela peut être nécessaire lorsque le MCU original ne peut pas fournir des ressources suffisantes.

La solution appropriée dépend de l’architecture produit existante.

Défis courants lors de l’ajout de la communication par API

1. Bruit électrique

Le bruit provenant des alimentations à découpage, des moteurs et des pilotes LED peut réduire la fiabilité des communications.

Solution : Évaluer le signal PLC dans des conditions réelles de fonctionnement et optimiser le filtrage, le couplage, la disposition du PCB et les mécanismes de réessai du firmware.

2. Espace insuffisant sur le circuit imprimé

Les produits existants peuvent avoir peu de place pour du matériel supplémentaire.

Solution : Utilisez un module PLC intégré compact et intégrez-le directement dans le circuit imprimé ou via un connecteur compact.

3. Compatibilité du firmware

Le firmware existant n’a peut-être pas été conçu pour le réseau.

Solution : Ajoutez une couche de communication dédiée aux PLC entre l’application et les pilotes matériels.

4. Atténuation des lignes électriques

Des câbles longs et des charges différentes peuvent affaiblir les signaux des PLC.

Solution : Testez le réseau électrique réel et évaluez la topologie du réseau, la conception du couplage et la qualité du signal.

5. EMC et exigences de sécurité

L’ajout de circuits de communication peut affecter les performances de sécurité électromagnétique et d’EMC du produit.

Solution : Inclure les considérations EMC, surtensions, ESD, isolation et sécurité dès le début du processus d’intégration.

Liste de contrôle pour l’intégration des PLC pour les ingénieurs OEM

Si vous êtes un nouvel utilisateur, vous pouvez d’abord consulter cet article Liste de contrôle de conception de modules PLC pour le développement OEM | Matériel et tests. Avant de passer à la production de masse, vérifiez :

Matériel

• Module PLC sélectionné
• Interface MCU de l’hôte confirmée
• Alimentation du module vérifiée
• Circuit de couplage conçu
• Circuit de protection évalué
• Vérification du dégagement et de l’isolement des circuits imprimés
• Exigences thermiques vérifiées

Micrologiciel

• Pilote API intégré
• Protocole de communication défini
• Mise en œuvre de l’adressage des dispositifs
• Gestion des erreurs implémentée
• Mécanisme de timeout/réessai implémenté
• Commandes de configuration implémentées
• Diagnostic à distance implémenté si nécessaire

Essais

• Distance de communication testée
• Perte de paquets mesurée
• Plusieurs nœuds testés
• Charge électrique maximale testée
• Test de bruit de commutation
• Essais de cycle de puissance terminés
• Communication longue durée testée
• Essais EMC planifiés/achevés
• Procédure de test de production définie

Module PLC vs. Développement de matériel API à partir de zéro

Approche	PLC Module	Développer à partir de zéro
Temps de développement	Généralement plus courts	Généralement plus longues
Complexité matérielle	Lower	Plus haut
Effort initial d’ingénierie	Lower	Plus haut
Personnalisation	Cela dépend du module	Très haut
Travail sur le firmware	Intégration module/API	Développement complet des PLC
Conception de circuits imprimés	Plus simple	Plus complexe
Exigences de test	Réduit	Étendu
Mieux adapté à	Intégration OEM	Plateformes API à grand volume/personnalisées

Pour les fabricants qui ont besoin d’une solution API personnalisée mais ne souhaitent pas développer eux-mêmes l’ensemble de la pile de communication des PLC, un module PLC embarqué configurable peut constituer un compromis entre une puce de communication standard et une conception entièrement personnalisée des PLC.

Quand faut-il ajouter la communication par PLC à un produit existant ?

L’intégration des PLC peut être envisagée lorsqu’un produit a besoin de communication, mais l’installation de nouveaux câbles de communication est difficile ou coûteuse.

Les applications typiques incluent :

• Contrôleurs d’éclairage intelligents
• Équipements de contrôle industriel
• Compteurs d’énergie
• Éclairage d’urgence
• Équipements de distribution d’énergie
• Équipement de recharge pour VE
• Équipements d’énergie solaire
• Dispositifs d’automatisation des bâtiments
• Contrôleurs moteurs
• Capteurs industriels
• Contrôleurs de pompe et de climatisation
• Armoires électriques intelligentes

Le cas d’application le plus fort est souvent un système où Le câblage électrique existe déjà et peut aussi servir de support de communication.

Comment MicroNature prend en charge l’intégration API OEM

Pour les OEM développant des produits électriques compatibles PLC, MicroNature fournit des modules de communication PLC embarqués et du matériel associé pour intégrer la communication par ligne électrique dans les produits existants.

L’approche d’intégration peut être adaptée à différentes architectures produit, notamment :

• MCU hôte + module API
• Intégration des PLC basée sur l’AURT
• Intégration des PLC basée sur SPI
• Circuits de couplage PLC
• Passerelles PLC et concentrateurs
• Contrôleurs API monopériphériques
• Systèmes de communication industriels PLC
• Contrôleurs d’éclairage intelligents

Par exemple, le Module PLC MN-L80C est conçu pour des applications embarquées et peut fournir des capacités de communication PLC via des interfaces hôtes telles que UART, PWM et GPIO.

Pour les projets nécessitant du matériel ou un firmware personnalisé, un processus d’intégration OEM peut inclure :

Revue de l’architecture produit → sélection des modules PLC → intégration matérielle → conception de couplage → intégration firmware/API → prototype → tests de communication → validation EMC → production de masse

Cette approche permet aux fabricants d’ajouter la communication par API tout en préservant autant que possible leur architecture de produit électrique existante.