Intro

PROFINET is vandaag een van de meest gebruikte industriële Ethernetprotocollen. Het is snel, betrouwbaar en uitstekend geschikt voor automatiseringsprojecten. Toch schuilt er een valkuil in het protocol die ons tijdens een project meerdere uren troubleshooting kostte, terwijl alle klassieke netwerkcontroles foutloos leken.

Het probleem op locatie

Tijdens een project gebruikten we een Siemens PLC uit de S7-1500-reeks en een RIO-eiland (Remote Input Output) voor de aansturing van pompen op een rivier. Deze werden gebruikt om het opwaarts niveau hoog genoeg te houden in tijden van droogte, door water na de sluis terug te pompen naar boven. Alles werd geprogrammeerd, er werd een FAT uitgevoerd, alles werkte zoals het hoort. In onze testopstelling werkte alles perfect. Wat we toen nog niet wisten, was dat het probleem uiteindelijk niets met IP-adressen, PLC-code of toestelconfiguratie te maken zou hebben.

Zodra alles on-site werd geïnstalleerd, met dezelfde toestellen en dezelfde code liepen we tegen problemen aan. Het eiland was onbereikbaar, de PLC stond opwaarts bij de peilmetingen en het RIO-eiland stond afwaarts bij de pompen. Zoals elke engineer begon ik systematisch mogelijke oorzaken uit te sluiten. Ik controleerde IP-adressen, subnetmaskers, gateways en voerde verschillende connectiviteitstesten uit. Alles leek correct.

Hoe we de oorzaak vonden

Na uren zoeken zonder resultaat begon ik vragen te stellen aan de IT-dienst van de klant. Vragen zoals, is uw netwerk juist geconfigureerd. De IT-dienst deed net hetzelfde als ik, IP-adressen controleren, ping-tests, nakijken of de poorten open stonden niet via telnet maar in de firewall. Alles leek correct, met als gevolg dat de klant zijn antwoord was, de fout ligt niet bij ons. Daar sta je dan, op kantoor werkte alles en hier is het verbinden van een simpel RIO-eiland een groter obstakel geworden dan het hoort te zijn.

Na overleg met mijn collega's waren we het eens, het RIO-eiland moest eruit gehaald worden en naast de PLC worden gezet al dan niet via dezelfde switch of liefst nog rechtstreeks zonder apparatuur van de klant ertussen. Op deze manier konden we nakijken of onze configuratie correct was of er toch wijzigingen moesten gebeuren in TIA Portal. Na het verplaatsen van het eiland waren alle foutmeldingen plots verdwenen. Dit bevestigde het voor ons, de fout ligt aan het netwerk. Na aandringen om toch terug contact te krijgen met IT legden we het probleem uit, ze keken naar het verkeer en zagen dat PROFINET-frames werden gefilterd of niet correct doorgestuurd. Na onderzoek aan hun kant hadden ze gevonden dat ze inderdaad de switches moesten configureren voor het PROFINET-protocol.

Na herconfiguratie en herinstallatie van het RIO-eiland waren de problemen verholpen en konden de testen beginnen. We hadden uren verloren om dit opgelost te krijgen. Voor alle duidelijkheid: dit was een standaard RT-opstelling, zonder speciale klokken of synchronisatie tussen toestellen.

Waarom dit gebeurde

Om te begrijpen waarom ping werkte terwijl PROFINET faalde, moeten we eerst kort naar het OSI-model kijken.

OSI-model

Fysiek — de kabel, connectoren, elektrische signalen
Data Link — MAC-adressen, frames, switches
Netwerk — IP-adressen, routering
Transport — TCP/UDP, betrouwbare aflevering
Sessie — beheer van de verbinding
Presentatie — encryptie, encodering
Applicatie — het protocol dat je software effectief gebruikt

PROFINET-communicatiekanalen

PROFINET praat via meerdere kanalen naast elkaar op hetzelfde netwerk: TCP/IP voor configuratie en diagnose, en RT (Real-Time) voor de cyclische data-uitwisseling. Er bestaat ook nog IRT (Isochronous Real-Time), voor toepassingen die extreme synchronisatie vereisen zoals tientallen aandrijfassen die op microseconde-niveau gelijk moeten lopen. Ons project gebruikte geen IRT, dus die valt hier verder buiten scope.

RT werkt al rechtstreeks op laag 2: het frame krijgt een eigen EtherType (0x8892) en gaat meteen van de Ethernet-laag naar de PROFINET-applicatie, zonder om te wegen via TCP/IP. Daarmee haal je in de meeste installaties cyclustijden tussen 250 µs en enkele honderden milliseconden, en dat volstaat voor het grootste deel van de industriële toepassingen, inclusief de onze. Het TCP/IP-kanaal daarentegen doorloopt alle 7 lagen en is daardoor gewoon routeerbaar, net als eender welk ander IP-verkeer.

De onderstaande afbeelding toont waar elk kanaal zich in het OSI-model bevindt. RT slaat laag 3 tot en met 6 bewust over en springt rechtstreeks van laag 2 naar laag 7 — dat is geen bug, het is net de reden waarom het zo snel is: elke laag die je overslaat, is verwerkingstijd die je bespaart. De keerzijde: omdat RT-frames geen IP-adres bevatten, kunnen ze nooit door een laag 3-toestel (een router) heen. En een switch, firewall of beveiligingspolicy die niet voorzien is op PROFINET-verkeer, kan deze frames blokkeren, filteren of niet correct prioriteren. Hoewel ons project geen gebruik maakte van IRT, gelden dezelfde principes voor RT-verkeer: de cyclische communicatie verloopt rechtstreeks via Ethernet en kan dus beïnvloed worden door de configuratie van tussenliggende netwerkapparatuur.

En dat is precies waar het in ons verhaal hierboven fout liep: een switch die niet correct voor PROFINET-verkeer geconfigureerd staat, kan RT-frames verkeerd behandelen, filteren of niet de juiste prioriteit geven.

Communicatie stappen

Voor de cyclische data effectief kan beginnen stromen, moet er eerst een volledige handshake tussen de PLC (IO-Controller) en het toestel (IO-Device) gebeuren. Die opstart verloopt via het TCP/IP-kanaal, met alle 7 lagen van het OSI-model, en pas op het einde daarvan schakelt het systeem over naar het lichtere RT-kanaal voor de effectieve productiedata. Concreet loopt dat zo:

Naamresolutie (DCP Identify). Het toestel kent nog geen IP-adres, enkel zijn MAC-adres en de PROFINET-naam uit TIA Portal. De PLC broadcast een DCP-identify op zoek naar die naam — zonder match vindt hij het toestel niet, ook al hangt het gewoon aan het netwerk.
IP-adres toewijzen (DCP Set). Via DCP Set kent de PLC IP-adres, subnetmasker en gateway toe aan het gevonden toestel (via zijn MAC-adres). Het toestel bevestigt.
ARP. De PLC bevestigt de IP-MAC-koppeling, zoals bij elk Ethernet-toestel.
Verbinding opbouwen (Application Relationship). Via DCE/RPC over UDP bouwt de PLC een Application Relationship (AR) op, met Communication Relationships (CR's) voor parameterdata, cyclische IO-data en alarmen.
Parameters schrijven. De PLC schrijft de toestelparameters (uit het GSD/GSDML-bestand) via deze acyclische verbinding.
Application Ready. Het toestel meldt dat de parameterisatie klaar is en het kan starten met data-uitwisseling.
Overschakelen naar cyclische data. Pas nu switcht de communicatie van het acyclische TCP/IP-kanaal naar het RT-kanaal, rechtstreeks op laag 2, in de afgesproken cyclus.

Bij IRT komt hier nog een extra synchronisatiestap bovenop, met klokafstemming tussen alle switches en toestellen in het domein. Aangezien ons project standaard RT gebruikte, speelde dat in onze situatie geen rol.

Hardware

Nu duidelijk is waarom RT-verkeer buiten de gewone 7 lagen om gaat, blijft de praktische vraag over: hoe zorg je dat je switches dat verkeer ook effectief doorlaten? Elke switch tussen de PLC en je IO-toestellen moet daarvoor correct geconfigureerd zijn — dat gebeurt niet automatisch.

Voor meer info over hoe je de switch moet configureren, verwijzen we naar de Cisco-link onderaan dit artikel.

Layer 2 switch

Een laag 2-switch werkt uitsluitend op MAC-adressen: hij bekijkt het Ethernet-frame, kijkt naar het doel-MAC-adres, en stuurt het frame naar de juiste poort. Hij weet niets van IP-adressen of routering, en dat is precies waarom hij ook RT-verkeer kan doorsturen.

Voor een PROFINET-netwerk is een laag 2-switch dan ook de standaard keuze. Belangrijk: "gewoon een switch" is niet voldoende. Voor optimale prestaties ondersteunt een PROFINET-switch doorgaans IEEE 802.1Q/802.1p-prioritering. IRT vraagt bovendien gespecialiseerde switch-hardware om tijdsloten te bewaken, maar dat was in onze RT-opstelling niet aan de orde. Een standaard, niet-industriële switch die deze functies niet ondersteunt of niet correct geconfigureerd is, kan PROFINET-verkeer vertragen of zelfs laten vallen.

Die denkfout hoor je wel vaker in het veld: "het is een laag 2-switch, dus de hardware klopt." Dat klopt op zich ook, een laag 2-switch is inderdaad het juiste type voor een PROFINET-netwerk. Maar het juiste type switch hebben is niet hetzelfde als een correct geconfigureerde switch hebben. Of een laag 2-switch RT-verkeer effectief doorlaat, hangt af van de configuratie hierboven, niet van de laag waarop hij werkt.

Layer 3 switch

Een laag 3-switch voegt IP-routering toe bovenop wat een laag 2-switch al doet: hij kan naast MAC-adressen ook IP-adressen lezen en op basis daarvan verkeer tussen verschillende subnetten doorsturen, net als een router.

Dat klinkt krachtiger, maar voor PROFINET RT verandert het niets aan het probleem: dit kanaal bevat geen IP-adres en kan dus nooit door een laag 3-routeringsfunctie heen, hoe goed geconfigureerd die ook is. Wil je RT-toestellen met elkaar laten praten, dan moeten ze zich in hetzelfde laag 2-segment bevinden; zodra er een laag 3-grens (dus effectief routering) tussen zit, werkt dat sowieso niet.

PROFINET-troubleshooting checklist

Herken je dit: ping werkt perfect, de juiste poort staat open, en toch krijgt de PLC geen contact met het toestel? Dat was exact de situatie in het verhaal hierboven. Loop deze checklist af voor je verder zoekt in de PLC-code.

De eerste stappen liggen meestal bij jou als automation engineer:

Controleer of het toestel de juiste PROFINET-naam heeft, niet enkel het IP-adres.
Controleer of DCP-discovery werkt, bijvoorbeeld via "Accessible devices" in TIA Portal of via Siemens PRONETA.
Test, indien mogelijk, met een rechtstreekse verbinding tussen PLC en toestel, zonder tussenliggende netwerkapparatuur van de klant. Werkt het nu wel, dan zit het probleem in het netwerk ertussen en niet in je eigen configuratie.

Bevestigt die test een netwerkprobleem, dan liggen de volgende punten meestal bij de IT-dienst, geef ze gerust mee of loop ze samen af:

Controleer of alle switches een laag 2-switch zijn.
Controleer de VLAN- en QoS-configuratie op alle tussenliggende switches.
Controleer of PROFINET-verkeer (EtherType 0x8892) effectief toegelaten is op elke switch tussen PLC en toestel.
Maak een Wireshark-capture om te bevestigen dat PROFINET-frames effectief aankomen bij het toestel.

Een succesvolle ping bevestigt enkel dat laag 3 (IP) werkt. RT draait op laag 2 en kan dus stuk zijn terwijl ping perfect blijft werken, dat is precies de valkuil uit dit artikel.

Conclusie

De les uit dit project is eenvoudig: als PROFINET op de FAT werkt maar op locatie niet, controleer dan niet alleen de PLC-configuratie. Betrek ook vroeg de netwerk- en IT-afdeling. Een succesvolle ping betekent niet dat PROFINET correct kan communiceren, RT draait immers op laag 2, onder IP, en daar kijkt een ping-test nooit naar.

In ons geval zat het probleem niet in de PLC, de code of de configuratie van het RIO-eiland. Het zat in het netwerk ertussen. En precies daarom is "ping werkt" bij PROFINET nooit voldoende bewijs dat alles correct functioneert.

Loop in zo'n situatie de checklist hierboven af voor je verder zoekt in de PLC-code: in de meeste gevallen bespaart dat je exact de uren die wij toen verloren zijn.

Vragen over PROFINET-communicatie of de netwerkopzet van uw automatiseringsproject? Neem gerust contact met ons op.

De PROFINET-valkuil die uren troubleshooting kostte