IEC 61131-3 is één van die normen die in de industriële automatisering als vanzelfsprekend worden gezien. Ontwerpers verwijzen ernaar, system integrators nemen het op in de documentatie, en klanten gaan ervan uit dat een systeem dat “volgens de norm” is gebouwd automatisch correct en onderhoudsvriendelijk is. In de praktijk blijkt dat vaak niet te kloppen. De norm ordent vooral hoe je een PLC-programma formeel vastlegt, maar beschermt niet tegen architectuurfouten. En juist die code-architectuur bepaalt of een installatie na de inbedrijfstelling goed te onderhouden is.
Wat regelt IEC 61131-3 daadwerkelijk?
IEC 61131-3 definieert een formeel programmeermodel voor PLC’s. Het beschrijft wat een resource, een task en een Program Organization Unit (POU) is, en introduceert een uniforme indeling in Program, Function Block en Function. Daarnaast standaardiseert het de programmeertalen en hun semantisch gedrag. Daardoor kunnen projecten beter leesbaar blijven over verschillende platforms en engineeringtools heen, en hoeven engineers niet telkens een volledig nieuw basisconcept aan te leren.
Tegelijkertijd schrijft de norm geen logische structuur voor. Ze zegt niets over hoe je verantwoordelijkheden moet verdelen, waar je processtatus opslaat, hoe je foutafhandeling organiseert of hoe je sequentiële logica ontwerpt. Ze laat zowel doordachte oplossingen toe als oplossingen die alleen “werken” omdat niemand ze nog heeft aangepast. Vanuit de norm gezien zijn beide varianten even correct.
Program, Function Block en Function in echte projecten
De theoretische POU-indeling is elke automation engineer bekend, maar in projecten wordt ze vaak verkeerd gebruikt. Het Program wordt dan één grote container voor alle logica, Function Blocks worden ingezet als procedurele macro’s, en de processtatus raakt verspreid over globale variabelen. Zo’n opzet werkt meestal bij de eerste inbedrijfstelling, maar gaat snel wringen bij wijzigingen en tijdens storingsdiagnose.
In projecten die in de praktijk goed standhouden, is een Function Block een echte representatie van een procesobject. Een klep, aandrijving, as of een deel van een sequentie heeft een eigen toestand, eigen overgangsvoorwaarden en een helder gedefinieerde interface. Het Program is dan niet langer de plek waar alle detail-logica wordt uitgeschreven, maar een coördinerende laag. Een Function blijft bedoeld voor berekeningen en eenvoudige, stateless bewerkingen. Dit staat niet letterlijk zo in de norm, maar zonder zo’n scheiding verliest een PLC-systeem snel zijn leesbaarheid.
Programmeertaal versus onderhoudbaarheid
IEC 61131-3 staat meerdere programmeertalen toe en maakt het mogelijk om ze binnen één project te combineren. In de praktijk komen problemen zelden door de vraag of LD, FBD of ST is gebruikt. Problemen ontstaan vooral wanneer er geen duidelijke regels zijn over waar en waarom je een taal inzet. Sequentiële logica die in ladderdiagrammen wordt “verstopt”, algoritmische stukken verspreid over verschillende POU’s en inconsistente naamgeving maken de code lastig te analyseren.
Bij een storing of tijdens een retrofit moet je in zulke projecten de intentie van de oorspronkelijke bouwer raden, in plaats van technisch te kunnen analyseren wat er gebeurt. De norm laat dit toe, maar beschermt niet tegen de gevolgen. Dat is precies waarom IEC 61131-3-compliance niet hetzelfde is als goede engineering practice.
Waar de norm helpt – en waar ze een vals gevoel van zekerheid geeft
IEC 61131-3 is zeer nuttig als gemeenschappelijke basis voor industriële automatisering. Ze maakt communicatie tussen teams eenvoudiger, standaardiseert kernbegrippen en helpt bij het lezen van projecten van anderen zonder voortdurend te hoeven gokken wat ermee bedoeld is. In die rol doet de norm precies wat ze moet doen.
Het probleem begint wanneer de norm wordt gezien als kwaliteitsgarantie. De norm beoordeelt de software-architectuur niet, dwingt geen beperking van globale variabelen af en schrijft geen aanpak voor foutafhandeling voor. Ze laat projecten toe die formeel correct zijn, maar in de praktijk hoge onderhoudskosten veroorzaken. Zonder aanvullende ontwerpregels geeft de norm vooral een gevoel van “orde”, dat na de eerste grotere wijziging in het systeem snel verdwijnt.
Samenvatting
IEC 61131-3 is een solide basis voor PLC-programmering, maar geen recept voor een goed automatiseringsproject. De norm definieert de talen en het formele model, maar de kwaliteit van een systeem wordt bepaald door de programmastructuur en de manier waarop je de beschikbare mechanismen inzet. In de industriële praktijk is het de code-architectuur – niet de keuze van de taal – die bepaalt of een systeem jarenlang veilig te onderhouden en uit te bouwen is. Is de structuur slecht, dan redt normconformiteit het project niet. Is de structuur goed, dan is de norm gewoon een passend hulpmiddel, geen last aan je been.
