Digital gesteuerte Netzteile Vier Fragen gegen die Angst

Der Begriff »Digitalsteuerung von Netzteilen« führt bei vielen Entwicklern, die Stromversorgungen für ihre Applikation zukaufen wollen, zu Unsicherheit. Der folgende Artikel beleuchtet vier zentrale Fragen für ein entsprechendes Lieferantenaudit.

von Andrew Skinner, CTO von TDK-Lambda UK, und Alfred Lorenz, Field Application Engineer und Produktmanager, TDK-Lambda Germany.

Digital gesteuerte Netzteile finden zunehmend Akzeptanz, insbesondere in Rechenzentren. Während des Designprozesses sollte man auf eine umfassende Dokumentation in ausreichender Detailtiefe achten. Zum einen, um das Design komplett und gründlich verifizieren zu können. Zum anderen, und das ist noch wichtiger, um zu gewährleisten, dass ein anderer Entwickler diesen Designprozess anschließend nachvollziehbar wieder aufgreifen kann, damit neue oder verbesserte Features in das Endprodukt einfließen können. Jeder Hersteller mit ISO-9001-Zertifizierung sollte über dokumentierte Abläufe verfügen, die seine kompletten Designprozesse abdecken, sodass ein Ingenieur ihn auditieren kann. Der Designprozess sollte auch die Algorithmen der Digitalsteuerung sowie wichtige Randbedingungen dokumentieren, etwa die Frequenzen der A/D-Wandler oder die PWM-Updateraten und -Laufzeiten in den Berechnungen für die Steuerungsschleife.

Diese Detailtiefe sollte genügen, damit ein Entwickler das System simulieren kann. Dafür eignen sich Mathematik- oder System-Simulationswerkzeuge, aber auch ein Schaltkreis-Simulationstool, das mit Verhaltensmodellierung oder C-Code-Blöcken umgehen kann. Dennoch bleiben vier Fragen offen, die man sich im Rahmen des Lieferantenaudits beantworten lassen sollte.

Lieferantenaudit

  • Wie programmiert der Netzteilhersteller die Steuerung (z. B. über GUI, höhere Programmiersprachen, C-Code-Blöcke)?

Die Werkzeuge, die für Design, Simulation, Build und Test der Steuerung einsetzt wurden, sollten alle inklusive Versionsnummern dokumentiert sein. Dies ist wichtig, denn Abweichungen in der Toolkette können Änderungen im Compiler-Ergebnis des Codes verursachen, was nicht ohne eine Revalidierung geschehen sollte. Auch bei Bibliotheken oder Tools zur Code-Erzeugung von Drittseite darf man eine angemessene Dokumentationstiefe erwarten. Idealerweise liefert der Drittanbieter eine Dokumentation, welche die Qualität seiner Tools und/oder seines Codes belegt.

Eine Mischung verschiedener Werkzeuge ist durchaus gebräuchlich, etwa ein Task-Scheduler von Drittseite zusammen mit der Verwendung von C-Code für übergeordnete »Housekeeping«-Funktionen und Assemblercode für zeitkritische Funktionen, die direkt auf der Hardware des Digitalcontrollers aufsetzen.

  • Welche Designprozesse wurden verwendet?

Auch wenn eine Peer-Review bei der Code-Erstellung zu empfehlen ist, von einer derartige Verifizierung des Designs sollte man nicht ausgehen. Ein Top-down-Designansatz, beginnend mit der Gesamtarchitektur und sollte die Hauptfunktionsblöcke dokumentieren. Dadurch lässt sich das Design hierarchisch überprüfen. Jeder der Funktionsblöcke sollte detailliert dokumentiert sein, z. B. mit Zustandsdiagrammen, welche die Abläufe für das Setzen und Zurücksetzen von Alarmen und Flags zeigen, sowie die Definitionsbereiche für alle Ein- und Ausgänge; dies macht Falldefinitionen und Verifizierung erheblich einfacher. Flussdiagramme sind hilfreich, um weniger komplexe Prozesse darzustellen.

Zum Thema

Digital geregelte Stromversorgungen: »Digital Power« einfach gemacht
Digital Power: Stabil ohne Kompensation
Lebensdauer, MTBF und Zuverlässigkeit: Fit & Forget
Zuverlässigkeit von Stromversorgungen: Keine Glückssache
Digitale Regelung plus 3D-Integration: Weniger Platz, mehr Leistung
Point-of-Load-Wandler: Jenseits aller Marketing-Versprechen
2. Anwenderforum Stromversorgung: Programm ist online
Make or Buy?: »Customized hat eine hohe Berechtigung«