Slimmer afwegen van prestaties en kosten in regelsystemen
Om de prestaties van regelaars te garanderen, worden de digitale platforms waarop ze draaien vaak overgedimensioneerd, wat onnodige kosten met zich meebrengt. State-of-the-art modelgebaseerde technieken maken het mogelijk goedkopere regelsystemen te maken, zonder dat de prestaties eronder lijden.
In de regeltechniek monitort een sensor het proces dat moet worden geregeld. Het sensorsignaal y wordt vergeleken met referentiesignaal r (zie Figuur 1). Dat referentiesignaal beschrijft het gewenste systeemgedrag in termen van de output van het proces. In het geval van ASML zou dit de gewenste positie van de waferstage kunnen zijn. De regelaar probeert de fout e (het verschil tussen r en y) te corrigeren door de actuator aan te sturen met het regelsignaal u. Een klassiek voorbeeld is de cruisecontrol van een auto. Hierbij geeft de chauffeur aan hoe snel de auto moet rijden, door middel van het referentiesignaal. Sensoren in de auto meten de snelheid. De fout wordt berekend waarop de regelaar reageert door gas bij te geven of te remmen.

Vaak wordt aangenomen dat de acties tijdens het regelproces – dat wil zeggen het meten door de sensor, het berekenen van het regelsignaal op het platform en het versturen ervan naar de actuator – geen of verwaarloosbare tijd kosten. In vele gevallen is dit echter geen correcte aanname omdat we te maken hebben met een digitaal platform. Om de zoveel milliseconden (de bemonsteringsperiode) wordt het sensorsignaal gemeten. De tijd die het vervolgens kost om het regelproces te verwerken, noemen we de executietijd. Die is vrijwel altijd variabel, aangezien de verwerking geen enkele keer hetzelfde is. Voor een eenvoudig regelsysteem zal de variatie vaak klein zijn maar wanneer meerdere complexere regelsystemen samen op één digitaal platform worden verwerkt, kan de executietijd significant variëren.
Een bepaalde tijd na de bemonstering wordt het regelsignaal uitgestuurd naar de actuator (zie Figuur 2). Deze tijd noemen we de input-outputvertraging. In veel systemen is deze gelijk aan de executietijd en dus ook variabel. Voor het ontwerp en het determinisme van het regelsysteem is het voordeliger om de io-vertraging vast te kiezen (vaak gelijk aan de worst-case-executietijd van het regelproces). Zij is meestal kleiner of gelijk aan de bemonsteringsperiode. Het ligt voor de hand dat we willen voorkomen dat de executietijd langer is dan de io-vertraging. Anders zou de verwerking van het volgende regelsignaal worden vertraagd en zou dit een sneeuwbaleffect tot gevolg kunnen hebben.

Het tijdstip waarop de io-vertraging verstrijkt, kunnen we dus beschouwen als de deadline van het systeem. Als het signaal later komt, heeft de actuator geen (nieuw) regelsignaal. Om ervoor te zorgen dat deze deadline onder alle omstandigheden wordt gehaald, worden platforms vaak overgedimensioneerd zodat het nieuwe regelsignaal al bij de actuatoren is voordat een nieuwe bemonstering plaatsvindt bij de sensor. Dit impliceert dat de bemonsteringsperiode groter dient te zijn dan de maximale executietijd die kan optreden. Een grote maximale executietijd resulteert in een kleinere bemonsteringsfrequentie, wat in het algemeen niet goed is voor de prestaties (lagere bandbreedte) van het regelsysteem. Als deze frequentie te laag blijkt, kan een sneller en dus duurder platform worden aangeschaft zodat de executietijden kleiner worden en hogere bemonsteringsfrequenties en prestaties kunnen worden gerealiseerd. Dit is dan ook een afweging tussen de prestaties en de kosten van het systeem.
Bernoulli
Een alternatieve ontwerpkeuze zou kunnen zijn om toe te staan dat de executietijd van het regelproces soms langer wordt dan de gedefinieerde deadline en daarbij te accepteren dat het regelsignaal voor die bemonsteringsperiode geen update krijgt. Veel ontwerpers zijn huiverig voor deze keuze, terwijl het een goede optie kan zijn en een betere afweging tussen kosten en presentaties kan opleveren. Vragen die dan opkomen: wat voor gevolgen heeft dit voor de systeemprestaties? Hoe vaak achter elkaar mag een deadline worden gemist? Hoe kiezen we de io-vertraging en wat doen we wanneer het nieuwe regelsignaal inderdaad te laat is? Dient het regelsignaal van de vorige periode dan te worden gebruikt? Uiteindelijk zijn we geïnteresseerd in de vraag of we een goedkoper platform kunnen kiezen waarmee we weliswaar af en toe een deadline missen, maar waarmee de prestaties van het regelsysteem behouden blijven.
Deze ontwerpkeuze en de bijbehorende vragen hebben we bestudeerd middels een modelgebaseerde aanpak. Door veelvuldig tijdsmetingen uit te voeren op het regelproces verkrijgen we inzicht in de verdeling van de executietijd. Deze verdeling kan ook modelmatig worden verkregen, zoals met ASML’s Carm 2G. Boven op deze (platformonafhankelijke) verdeling kan een kansverdeling passend worden gemaakt. Gegeven deze kansverdeling van de executietijd en de bemonsteringsperiode kunnen we de maximale io-vertraging specificeren die de deadline vormt voor executie van het regelproces.

Na specificatie kunnen we de kans γ op een gemiste deadline berekenen. Vervolgens kunnen we twee situaties definiëren gerelateerd aan elke bemonstering: i) de situatie waarin het regelsysteem geen deadline heeft gemist, en ii) de situatie waarin het systeem wel een deadline heeft gemist (zie Figuur 3). In het model hebben we dit vastgelegd door een Bernoulli-proces. Dit houdt in dat de kans waarmee we naar situatie i gaan gelijk is aan 1 – γ en de kans waarmee we naar situatie ii gaan gelijk is aan γ. Beide situaties hebben een eigen dynamisch model dat het systeemgedrag in die situatie beschrijft. Doordat we de kans op een gemiste deadline weten, kunnen we middels dit model analytisch het gemiddelde en de standaarddeviatie van het regelsignaal bepalen en hierdoor dus ook het gedrag van het gehele systeem, zowel in het tijdsdomein (Figuur 4) als in het frequentiedomein. Dit model is experimenteel gevalideerd.

Draadloos
Met het bovengenoemde analytische model kunnen we op verschillende manieren inzicht verkrijgen in het systeem. We kunnen bijvoorbeeld de optimale bemonsteringsperiode bepalen, voor het verkrijgen van zo goed mogelijke prestatie van het regelsysteem. Ook kunnen we de kans op een gemiste deadline definiëren als een functie van de io-vertraging of bemonsteringsperiode. Het analytische model kan daarnaast worden gebruikt om een bepaalde kans op een gemiste deadline en io-vertraging, of bemonsteringsperiode, en de daarbij behorende prestatie-index van het regelsysteem te analyseren, bijvoorbeeld de overshoot of settlingtijd. Deze twee resultaten kunnen over elkaar heen worden gelegd (zie Figuur 5). Zodoende kunnen we achterhalen welke kans op een gemiste deadline de kleinste overshoot oplevert voor het platform met de desbetreffende kansfunctie en een keuze maken voor de io-vertraging of bemonsteringsfrequentie.

Ook kunnen we zo de prestaties van meerdere platforms met elkaar vergelijken. Bijvoorbeeld door de kansfunctie van een goedkoper platform en een duurder platform bij elkaar weer te geven en te analyseren of een goedkoper platform – waar het missen van deadlines is toegestaan – dezelfde prestaties kan leveren als het duurdere platform waarbij geen deadlines mogen worden gemist. Naast dat we nu de gevolgen van een gemiste deadline op een platform kunnen kwantificeren, kunnen we dezelfde technieken ook toepassen om bijvoorbeeld inzicht te krijgen in een netwerkgeregeld systeem waarbij er pakketten data verloren kunnen gaan in de draadloze communicatie tussen het platform en het proces.
Andere oplossingsrichtingen om met een goedkoper platform betere of vergelijkbare prestaties van het regelsysteem te verkrijgen, zijn bijvoorbeeld multi-rate of eventgebaseerde regelsystemen. Bij multi-rate systemen kies je ervoor om verschillende regelsystemen op verschillende bemonsteringsperiodes te laten draaien. Zo kan het voordelig zijn om een hogere bemonsteringsperiode te kiezen voor regelsystemen met laagfrequente dynamica en een lagere bemonsteringsperiode bij hoogfrequente dynamica. In het geval van eventgebaseerde regelsystemen wordt het systeem enkel aangestuurd in het geval er een bepaalde gebeurtenis optreedt die aangeeft dat het echt noodzakelijk is om een nieuw regelsignaal te bepalen. In dat geval zal de bemonsteringsperiode in de tijd variëren en zich aanpassen aan de situatie waarin het systeem zich bevindt. Indien er veel verstoringen actief zijn, zal de bemonsteringsperiode kleiner worden en als er weinig verstoringen actief zijn, zal diezelfde periode omhoog gaan om reken- en communicatietijd te besparen.