M-Bus via TCP och UDP

M-Bus är en standard som oftast förknippas med seriell kommunikation, men i dagens uppkopplade värld används M-Bus allt mer över Ethernet via TCP och UDP. Det är dock förvånande att standarden saknar riktlinjer för hur dessa meddelanden ska hanteras i nätverksmiljöer, särskilt i kritiska system som SCADA och faktureringssystem. Detta kan leda till kommunikationsproblem, särskilt när TCP inbyggda omsändningsmekanismer krockar med SCADA-systemens timeout-inställningar. Hur kan vi undvika dessa fallgropar och säkerställa en stabil och säker informationsöverföring?

Trots att M-Bus-standarden är etablerad inom seriell kommunikation är det märkligt att den inte ger någon vägledning för hur M-Bus-meddelanden ska hanteras över Ethernet, specifikt via TCP eller UDP. Detta är särskilt relevant eftersom många moderna system, såsom SCADA-system och andra kritiska infrastrukturer för exempelvis fakturering, nu kommunicerar ofta via Ethernet-nätverk.

I dessa system ansluts ofta mätare och och andra givare via någon form av uppsamlare eller gateway som agerar som mellanhand. Dessa gateways samlar inte bara in data från trådbundna M-Bus-enheter, utan även från trådlösa M-Bus-mätare i vissa fall. En fråga som då uppstår är: Hur säker och stabil är den information som samlas in och vidarebefordras?

En av anledningarna till att diskutera detta är att när kommunikationen sker över ett nätverk med varierande stabilitet, framstår TCP som en pålitlig lösning. TCP säkerställer att meddelanden verkligen kommer fram genom att automatiskt omsända dem vid behov. Detta låter bra på papperet, men i praktiken kan det leda till oväntade problem.

SCADA-system har ofta en timeout-inställning på några sekunder för att säkerställa att ett svar returneras inom en rimlig tid. Om svaret inte kommer fram i tid, gör systemet ett eller flera omförsök. Samtidigt kan TCP också omsända meddelanden som inte har levererats. Dessa parallella omsändningsprocesser kan dock komma i otakt, eftersom SCADA-systemet inte alltid kan matcha förfrågningar och svar korrekt. Detta skapar en risk där SCADA-systemet kan ta emot ett föråldrat eller fördröjt svar från TCP som det inte längre förväntar sig, vilket kan leda till felaktiga beslut eller åtgärder.

För att undvika dessa problem är en robust lösning att införa ett transaktions-ID i kommunikationen. Detta gör det möjligt för SCADA-systemet att matcha varje svar med rätt förfrågan, vilket eliminerar risken för att ett gammalt svar tolkas som ett nytt. Denna typ av identifiering är vad som skiljer till exempel Modbus TCP från Modbus RTU.

Utan ett transaktions-ID eller någon annan form av identifiering kan SCADA-systemet inte avgöra om ett svar hör till den aktuella förfrågan eller en tidigare förfrågan som redan har gjort timeout. Detta kan leda till att systemet felaktigt behandlar gamla svar som nya, vilket kan få allvarliga konsekvenser i kritiska system.

Ett alternativ till TCP, när ett transaktions-ID saknas, som i standard M-Bus, är att använda UDP. Till skillnad från TCP är UDP ett kontaktlöst protokoll, vilket innebär att det inte omordnar eller omsänder paket. När man använder UDP kan man i princip återgå till de seriella mekanismerna, eftersom både seriell kommunikation och UDP är kontaktlösa.

För några år sedan började jag titta närmre på dessa problem mer ingående. Jag har sett vad dessa problem kan ställa till med som falsklarm med mera. Under tiden tog jag också fram specifikationen och tabellen som visas ovan.

Skicka gärna ett mail om du har synpunkter, önskemål etc hit.