Van Windows-panel naar een Linux-HMI

Op heel wat machines zit nog een panel met Windows CE, Windows Embedded of XP Embedded. De operator kent de schermen, de PLC antwoordt en de lijn draait, dus er is weinig reden om eraan te komen. Tot de leverancier stopt, er een security-advisory binnenkomt, een defect panel niet meer te vervangen is of een nieuwe functie niet meer op die oude CPU past. Dan moet het panel vervangen worden, en liefst zo dat de operator zijn machine nog herkent.

Het panel werkt nog, maar het platform niet meer

Windows CE, Windows Embedded en Windows XP Embedded krijgen geen security-updates meer. De hardware eronder is meestal een trage CPU met weinig geheugen, en een update betekent een USB-stick of iemand die ter plaatse gaat. Een koppeling met MES via OPC UA of REST past vaak niet in de runtime die destijds werd meegeleverd. Ook reserveonderdelen worden schaars: panels met CE of XP zijn steeds moeilijker te vinden, en als er een uitvalt, kan een machine wekenlang stilstaan in afwachting van een vervanger.

Met een Linux-image dat je zelf bouwt, valt die beperking weg. Kies Yocto als het image deel is van je product, en Debian als het panel eerder een gewone computer is. Hoe je die keuze maakt, lees je in Yocto, Ubuntu of Debian.

Daar komt de Cyber Resilience Act bij. Artikel 13, lid 8, van Verordening (EU) 2024/2847 legt een ondersteuningsperiode op van minstens vijf jaar, tenzij het toestel aantoonbaar korter gebruikt wordt. Met een besturingssysteem dat geen updates meer krijgt, haal je die periode niet.

Begin bij wat de operator al kent

Operators werken vaak al jaren met dezelfde schermen, knoppen en alarmteksten. Als een nieuwe interface alles een andere naam geeft, voelt het voor hen als een andere machine, en dat merk je aan de fouten in de eerste weken.

Daarom begint de inventaris bij de bediening:

• welke schermen ze het vaakst openen;
• welke handelingen onder tijdsdruk gebeuren, of met handschoenen aan;
• welk alarm de lijn stillegt;
• welke waarden ze echt aflezen, en welke er alleen staan omdat het scherm gevuld moest worden.

De nieuwe HMI neemt die logica en die woorden over. Wat verandert, is de visuele laag, de snelheid en de ruimte om later functies toe te voegen. Een alarm dat “storing transportband” heette, blijft zo heten, en de knop die je onder tijdsdruk indrukt, zit op hetzelfde moment in de handeling, ook al ziet het scherm er anders uit.

Het moment om de UX op orde te zetten

Behouden wat werkt, betekent niet dat alles moet blijven zoals het was. Op een oud panel zijn in de loop der jaren vaak schermen bijgekomen waar niemand nog de logica van kent, met knoppen die te klein zijn voor handschoenen, alarmen zonder duidelijke volgende stap en instellingen die drie menu’s diep zitten. Zolang het panel werkt, raakt niemand daaraan. Een vervanging is dan ook het moment om de UI en de UX grondig op orde te zetten.

Dat begint bij de inventaris hierboven. Wat operators elke dag gebruiken, krijgt een vaste, makkelijk bereikbare plek. Alarmen vertellen wat er misloopt en wat de operator nu moet doen. Instellingen die alleen de servicetechnicus nodig heeft, gaan een niveau dieper, zodat ze het dagelijkse werk niet in de weg zitten. En omdat de nieuwe stack op een huidige GPU draait, kan de interface ook vlotter reageren, met duidelijke grafieken en trends in plaats van kolommen met getallen.

Test die keuzes vroeg, met een klikbaar prototype op de werkvloer, zodat de verbeteringen aansluiten bij hoe er echt gewerkt wordt en de operator de machine nog herkent.

Drie mogelijke routes

Het panel blijft. Je houdt de panel-pc, of je vervangt alleen het display. Op een nieuw Linux-image draait de HMI in Qt/QML, in Avalonia als het team al in C# werkt, in Flutter, of als webinterface in React in een kioskbrowser. Welke het wordt, hangt af van de hardware, de kennis in het team en hoe de HMI later onderhouden wordt. Dat is de kortste route met de laagste hardwarekost, op voorwaarde dat de CPU en het geheugen de nieuwe stack aankunnen. Bij een panel-pc uit de CE-generatie is dat vaak niet het geval. Waar het wel lukt, blijft de besturing gewoon staan. De bediening van een vlasmachine volgde die route: het display bleef, en de interface werd Qt/QML op een Yocto-image.

Een nieuw panel met dezelfde I/O. Je vervangt het volledige panel, maar de PLC blijft, via het protocol dat er al ligt: Modbus, EtherNet/IP of OPC UA. Zo krijg je hardware die nog leverbaar is en een image dat je zelf kunt bijwerken.

De machine gaat opnieuw de markt op. Dan komt er nieuwe hardware, nieuwe software en vaak een koppeling met MES of diagnostiek die het oude panel niet had. Dat is eerder een relaunch van de machine dan de vervanging van een scherm dat moet blijven werken, en het vraagt een ander soort project.

De meeste lijnen komen uit bij de eerste of de tweede route.

Wat blijft en wat verandert

	Windows-panel	Linux-HMI
Besturingssysteem	Windows CE, Embedded of XP Embedded	Yocto of Debian
Interface	.NET Compact, WinForms, of de runtime van de leverancier	Qt/QML, Avalonia, Flutter of een webinterface (React)
Update	USB, vaak ter plaatse	Getekend image, met rollback
Beeld	Wat de oude chipset nog tekent	GPU van een huidige SoC
Levensduur	De support die de leverancier al stopte	De periode die jij vastlegt, omdat je het image zelf bouwt

Plan een getekende update met rollback al in het eerste image, en niet pas in een latere fase. Houd daarbij bij welk serienummer welke versie draait, en zorg dat een update die vastloopt de vorige werkende versie op de machine laat staan.

Begin met één machine

Een volgorde die in de praktijk goed werkt:

1. Breng de bestaande HMI in kaart: de schermen, alarmen en protocollen, de grenzen van de hardware, en wat operators doen als het druk is.
2. Maak een lijst van wat er op het oude panel zit: recepten, setpoints en parameters, gebruikers en hun rechten, en de historiek. Dat staat vaak in een eigen formaat, soms in de runtime van de leverancier, en het is meestal meer werk dan verwacht. Exporteer het en neem het gestructureerd over in de nieuwe HMI, zodat er na de overstap niets opnieuw ingegeven moet worden.
3. Kies het platform: Yocto of Debian, en Qt/QML, Avalonia, Flutter of een webinterface in React, en ga na of de huidige panel-pc de nieuwe stack nog aankan.
4. Bouw een prototype rond de handelingen die er echt toe doen, zoals de stappen die de lijn stilleggen of weer opstarten, en test het op de werkvloer met de mensen die er werken. Verandert er iets aan de manuele bediening of aan functies die met veiligheid te maken hebben, bekijk dan met je veiligheidsadviseur of de risicobeoordeling van de machine moet worden bijgewerkt.
5. Rol uit op één machine of één lijn, en daarna op de rest, met hetzelfde image. Als machinebouwer heb je een tijdlang machines met het oude en met het nieuwe panel in het veld. Leg vast welke HMI-versie bij welk machinetype hoort en hoe je beide ondersteunt tot de laatste oude panels vervangen zijn.
6. Lever updates vanaf de eerste release getekend en met rollback, en houd bij welke machine welke versie draait.

Zo houdt de operator zijn vertrouwde woorden en werkvolgorde, terwijl het panel eronder een platform wordt dat je de komende jaren kunt onderhouden.