Couche d’abstraction d’alimentation : une interface logicielle pour votre système

10 septembre 2026

Un pilote de capteur devrait pouvoir demander une alimentation sans connaître le GPIO qui l’active. Une application devrait pouvoir détecter le défaut d’un rail sans décoder le registre d’état d’un régulateur précis. Une couche d’abstraction d’alimentation, ou PAL, fournit une interface commune pour ces opérations.

L’idée consiste à décrire le système selon les besoins de l’application : quelles charges demandent une alimentation, quelles sources elles partagent, quand ces sources sont prêtes et comment réagir après un défaut. Le code propre à la carte traduit ces demandes en commandes que le matériel prend réellement en charge.

Partir des interfaces existantes

Cette approche s’appuie sur des mécanismes établis. Le cadre de régulation de Linux permet à un consommateur de demander une alimentation par son nom. Un régulateur partagé reste activé tant que son compteur de références d’activation n’est pas revenu à zéro. Zephyr offre des opérations sur les tensions prises en charge, les limites de courant et les indicateurs de défaut. Sa gestion d’alimentation à l’exécution suit l’utilisation des périphériques pour décider de leur suspension ou de leur reprise. Une PAL devrait réutiliser ces fonctions lorsqu’elles existent sur la plateforme. Interface des consommateurs de régulateurs Linux, API de régulation de Zephyr, Gestion d’alimentation à l’exécution de Zephyr (en anglais).

L’ajout proposé est un contrat à l’échelle du produit. Au lieu de disperser les noms de rails, les hypothèses de temporisation et les règles de redémarrage dans les pilotes, regroupez-les dans une description du comportement d’alimentation du système.

Séparer la demande de la mesure

Pour cette conception, conservez au moins trois informations distinctes :

• État demandé : un client a besoin du rail ou a libéré sa demande.
• État et éléments de confirmation : arrêt, démarrage, prêt, défaut ou inconnu, avec une distinction explicite entre une transition déduite d’une commande et un état confirmé par rétroaction ou par une garantie documentée du pilote.
• Capacités : la carte peut commuter le rail, signaler son état, mesurer sa tension ou régler une consigne. Chaque capacité est explicite.

Appliquer un niveau à une broche d’activation ne prouve pas à lui seul que le rail est prêt. Une API de pilote peut garantir une alimentation stable lorsque son opération d’activation réussit ; la PAL doit conserver cette garantie documentée. Une broche d’état n’identifie pas nécessairement tous les défauts, et une tension configurée n’est pas une mesure. Si la carte ne mesure pas la tension, l’interface doit indiquer cette limite. Une opération non prise en charge doit retourner une erreur. API de régulation de Zephyr (en anglais).

Pseudocode illustratif, étape par étape :

1. requete = alimentation.demander("rail_capteur"). Si la demande échoue, consignez son erreur et retournez.
2. En cas de succès, conservez demande = requete.jeton. Seul un jeton acquis doit être libéré.
3. Dans un bloc essayer, appelez resultat = alimentation.attendre_pret(demande, echeance).
4. Si le résultat est PRET, appelez capteur.prendre_mesure(). Sinon, consignez le problème d’alimentation.
5. Dans le bloc finalement, appelez alimentation.liberer(demande) exactement une fois, y compris après un délai dépassé ou une erreur de l’application.

Dans ce contrat proposé, chaque demande acquise avec succès fournit un jeton propre à un client. Ce jeton est libéré exactement une fois, y compris après un délai dépassé ou une erreur de l’application. Une libération ordinaire ne doit pas demander l’arrêt d’un rail partagé dont un autre client a encore besoin. La protection électrique peut toutefois forcer la coupure malgré des demandes actives. L’adaptateur associe les états logiques aux polarités des broches et aux interfaces électriques réelles. L’application ne suppose jamais qu’un niveau haut signifie toujours « activé » ou « sans défaut ».

Les rails partagés exigent aussi un arbitrage des consignes. Définissez les combinaisons compatibles de tensions demandées et de limites, puis refusez les demandes incompatibles ou résolvez-les selon une règle explicite. Le dernier client ne doit pas écraser silencieusement les besoins d’alimentation d’un autre.

Définir les transitions et les défauts

Décrivez les préalables au démarrage, la confirmation de disponibilité, les délais d’attente et l’ordre d’arrêt de chaque charge. Précisez la réaction à un défaut pendant le démarrage ou à une perte de communication avec un contrôleur d’alimentation. Une confirmation tardive peut mettre à jour l’état observé du rail, mais ne doit pas réactiver une demande expirée. Conservez un historique des défauts distinct de l’état courant pour permettre l’analyse d’un événement bref.

Vérifiez que le graphe des dépendances ne contient aucun cycle. Traitez les échecs et les délais dépassés à chaque préalable, afin qu’une alimentation amont absente ne laisse pas une demande aval en attente indéfiniment.

La reprise exige aussi une règle. Dans cette conception, une nouvelle tentative est une action explicite et limitée, après évaluation de la cause. Un défaut verrouillé le reste jusqu’à ce que la règle autorise un réarmement. Évitez de cacher des cycles d’alimentation répétés dans une commande générique d’activation.

Conserver la protection électrique dans le matériel

L’interface logicielle coordonne le système sans modifier les limites de ses circuits de protection. Par exemple, Protect+ emploie une protection matérielle sans microcontrôleur embarqué et offre des interfaces isolées Sleep et de défaut. C’est un point de commande possible pour un contrôleur externe, sans pour autant constituer une API de réglage des seuils. PN Labs Protect+.

La sélection d’une source comporte aussi des exigences électriques. Le guide de multiplexage d’alimentation de TI distingue les commandes manuelles, automatiques et combinées, et traite du blocage inverse et des transitions entre sources. Une demande logicielle de changement de source dépend toujours d’un circuit conçu pour cette transition. TI, Basics of Power MUX (en anglais).

Tenez aussi compte de l’alimentation du contrôleur. Si la coupure d’un rail prive d’alimentation le contrôleur chargé de le réactiver, la conception exige un mécanisme matériel de reprise ou une alimentation indépendante pour ce contrôleur. Précisez le comportement des broches de commande au démarrage, pendant une réinitialisation et lors d’une perte d’alimentation du contrôleur. Un logiciel qui ne s’exécute plus ne peut pas appliquer une règle de reprise.

Rendre l’interface vérifiable

Avant de relier ce contrat à une carte, testez un adaptateur simulé : disponibilité retardée, défaut pendant le démarrage, perte du signal d’état et deux clients partageant un rail. Vérifiez ensuite les mêmes transitions sur le matériel, y compris le démarrage et la réinitialisation du contrôleur. Consignez la révision de la carte et les temporisations mesurées avec la configuration de l’adaptateur.

Vous obtenez un endroit où se rejoignent les demandes de l’application, la rétroaction électrique et les règles de reprise. Un changement de carte possède alors une frontière définie à réviser, et le reste de l’application dispose d’une façon cohérente de demander une alimentation et de réagir lorsqu’elle est indisponible.

Pour le côté matériel de cette interface, lisez Qu’est-ce qu’un PSOM (Power System On Module) ?. Cet article décrit l’architecture du module ; le présent article définit le contrat logiciel qui l’entoure.