Door Andrew Skinner, Chief Technology Officer bij TDK-Lambda EMEA
Digitaal geregelde voedingen in de vermogensklasse van 1 kW of meer zie je in steeds meer toepassingen terug, met name bij data centra. De geavanceerde functionaliteiten en de zeer hoge rendementniveaus die de digitale regeling met zich meebrengt heeft er voor gezorgd dat deze regeltechnologie ook in laagvermogen voedingen wordt toegepast.
Het ontwerpproces moet voldoende gedetailleerd worden gedocumenteerd, niet alleen voor een volledige en grondige evaluatie van het ontwerp, maar ook om andere engineers de mogelijkheid te geven om met het ontwerp aan de slag te gaan om bijvoorbeeld nieuwe functionaliteiten toe te voegen of verbeteringen door te voeren.
Iedere ISO9001-gecertificeerde leverancier moet de ontwerpprocessen dusdanig hebben gedocumenteerd dat een engineer ze kan verifiëren. Daar horen in het geval van de digitaal geregelde voedingen nauwkeurige omschrijvingen bij van de algoritmen die zijn gebruikt voor de digitale regeling en onderscheidende eigenschappen zoals ADC-conversiefrequenties, PWM update snelheden en delays die met de berekeningen van de regelkring samenhangen.
Dit detailniveau moet voldoende zijn voor engineers om het systeem te simuleren met bijvoorbeeld mathematische of systeem simulatietools of met een simulatietool voor de schakeling die mogelijkheden tot modellering heeft of C-codeblokken accepteert.
Er zijn echter nog vier specifieke vragen die ook moeten worden beantwoord voor een adequate beoordeling van de leverancier.
Hoe heeft de fabrikant van de voeding de controller geprogrammeerd? Bijvoorbeeld via een GUI, een high-level programma en/of C?
Alle tools die zijn gebruikt voor het ontwerpen, simuleren, bouwen en testen van code moeten worden gedocumenteerd, inclusief het versienummer. Dit is belangrijk omdat veranderingen in de toolchain kunnen leiden tot veranderingen in de gecompileerde code. Iets wat zonder hervalidatie te allen tijde moet worden vermeden. Waar bijvoorbeeld third party bibliotheken of codegeneratie tools zijn gebruikt, mag je vergelijkbare niveaus van testdetail verwachten. Idealiter zorgt de betreffende software leverancier zelf voor testdocumentatie die de kwaliteit van de code of tools aantoont. Het is niet ongebruikelijk om een mix van gebruikte tools tegen te komen.
Bijvoorbeeld een third party taakplanner, C voor de hogere niveau ‘housekeeping’ functionaliteiten en laagniveau assembler software voor tijdkritische functionaliteit die is geïntegreerd in de hardware van de digitale regelaar.
Welke ontwerpprocessen zijn toegepast?
Met alleen het nauwgezet in kaart brengen van de code heb je nog steeds geen goed beeld van het ontwerp. Hiervoor is een topdown benadering nodig die begint bij het documenteren van de globale architectuur met de belangrijke functionele blokken. Op die manier is een hiërarchische beoordeling van het ontwerp mogelijk.
Elk functioneel blok moet in detail zijn beschreven, met bijvoorbeeld toestandsdiagrammen die de processen voor het instellen en resetten van alarmen of markeringen en de gedefinieerde bereiken van alle in- en uitgangen. Deze benadering maakt de definitie van de testprocedure en de controle op de correcte werking relatief eenvoudig. Ook stroomdiagrammen zijn een handig instrument om minder complexe processen in kaart te brengen.
Welk evaluatieproces is toegepast voor de soft- en hardware elementen in het ontwerp?
De projectstappen voor de soft- en hardware elementen in het ontwerp zijn in de basis identiek. Dit zijn: specificaties, ontwerp, verificatie en validatie. Je mag aan het einde van elk van die stappen reviews verwachten (‘stage gates’) alsmede reguliere team en peer reviews voor zowel de hard- als software elementen.
Welke test- en validatieprocessen zijn gebruikt?
Net als bij ieder ander systeem is de complexiteit bepalend voor de teststrategie. Normaliter wordt iedere softwarefunctie afzonderlijk getest, gevolgd door een geïntegreerde test waarbij de verschillende functies bij elkaar gebracht zijn. Bij deze tests vindt ook validatie van foutcorrectie routines plaats om de systeembetrouwbaarheid te vergroten.
Dit kan een tijdrovende kwestie zijn in gevallen waar DSC/DSP hardware verantwoordelijk is voor de belangrijkste functies en randvoorwaarden: je bent dan niet meer alleen software aan het testen.
De laatste stap is validatie, waarbij de functionaliteit van het volledige systeem zowel qua hardware als software wordt vastgesteld om de compliance met het complete ontwerp te waarborgen.
Gewapend met de antwoorden op deze vragen kunnen engineers digitaal geregelde voedingen vol vertrouwen specificeren en profiteren van de geavanceerde functies en de uitstekende rendementniveaus die digitale regeling bieden.
Ga voor meer informatie over de TDK-Lambda voedingen naar www.nl.tdk-lambda.com.
Ook kan je direct contact opnemen met de auteur van deze white paper via: powersolutions@uk.tdk-lambda.com
