10 juni 2026
Stel: je hebt een rekentool voor waterstofenergiesystemen, maar die tool werkt alleen voor één specifieke situatie. Je kunt er niets aan aanpassen, niets toevoegen, en als je een andere casus wilt doorrekenen, moet je de broncode zelf opengooien. Dan is de tool eigenlijk geen tool, maar meer een bevroren snapshot van één project. Dat was de situatie waar ik in februari 2026 mee te maken kreeg bij het EnHyCo project bij Entrance, en dat was meteen ook mijn opdracht: verander dat.
De EnHyCo tool (kort voor Entrance Hydrogen Configurator) is een Python-applicatie waarmee je energiesystemen met waterstof kunt simuleren en optimaliseren. De tool was gebouwd als proof-of-concept voor een project in Hoogeveen, met een vaste opstelling van zonnepanelen, windturbines, een elektrolyser, een batterij en waterstofopslag. Al die waarden lagen hard in de code verankerd. Wil je een andere combinatie proberen, of een component weglaten? Dat kon niet zonder handmatig in de code te duiken.
Onderzoekers, studenten en andere partners willen de tool inzetten als startpunt voor nieuwe projecten. Die behoefte was er, maar de tool kon die niet invullen. Mijn opdracht was dus: maak de tool flexibel, zodat gebruikers zelf hun energiesysteem kunnen samenstellen.
Vroeg in het project bekeek ik de code van de originele simulatiemodule. Wat ik aantrof, maakte de opdracht meteen concreet: één functie van meer dan vijfhonderd regels, zonder duidelijke scheiding tussen de verschillende componenten. Zonnepanelen, windturbines, elektrolyser, alles door elkaar en onlosmakelijk verbonden. Als je iets wilde wijzigen, moest je weten hoe de hele functie werkte.
Dat was een leermoment. Niet alleen voor dit project, maar in het algemeen: een goede softwarearchitectuur is geen luxe, het is een voorwaarde voor toekomstige aanpasbaarheid. Dat inzicht stuurde de rest van mijn aanpak.
Op basis van literatuuronderzoek naar softwarearchitectuur koos ik voor een modulaire opzet waarbij elk componenttype een eigen klasse krijgt met een gemeenschappelijke interface. Dat betekent dat een zonnepaneel, een batterij en een elektrolyser elk op dezelfde manier met de rest van het systeem communiceren, maar intern hun eigen berekeningen uitvoeren.
Gebruikers kunnen via de interface componenten selecteren, parameters instellen en vervolgens een simulatie starten. De tool rekent dan uit hoe dat systeem presteert over een volledig jaar, op uurbasis. En omdat de architectuur nu modulair is, is een nieuw componenttype (zoals een warmtepomp of een brandstofcel) toe te voegen zonder dat de rest van de code aangepast hoeft te worden.
Het resultaat van deze twintig weken is een werkende, modulaire versie van EnHyCo. De tool kan nu ingezet worden voor uiteenlopende energieprojecten, zonder dat daar programmeerkennis voor nodig is.
De tool is daarmee niet af in de zin van “klaar en perfect”. Er zijn nog componenten die uitgewerkt kunnen worden, en de interface kan op punten verder worden verbeterd enzovoort. Maar dat is ook precies de bedoeling van een modulaire opzet: andere teamleden kunnen nu voortbouwen op een duidelijke structuur, zonder dat ze eerst door een wirwar van hardcoded code hoeven te werken. Dat voelt voor mij als een goed eindpunt.
Wat ik meeneem? Dat goede software begint bij het nadenken over structuur, voordat je de eerste regel schrijft. En dat de energietransitie niet alleen technische kennis vraagt, maar ook tools die mensen echt kunnen gebruiken.
Een blog door Wouter de Veth, vierdejaarsstudent HBO-ICT
Deelgenomen aan de Learning Community Hydrogen
