Strategie zpracování M-Bus dat pro LoRaWAN a NB-IoT

Truncate, Split, Multiframe nebo MQTT s naparsovaným JSON: jak zvolit přenos podle sítě a parseru na přijímací straně

Klíčové poznatky

• ‍M-Bus parser interpretuje M-Bus telegram a převádí jeho zakódované záznamy na použitelné hodnoty z měřidla.
• Parsování, filtrování a fragmentace jsou tři různé kroky. Parsování data interpretuje, filtrování vybírá, které záznamy zachovat, a fragmentace rozděluje data, která se nevejdou do jedné síťové zprávy.
• Filtrování je na prvním místě. Filtrování podle VIF/DIF může snížit objem požadovaných M-Bus dat pod limit payloadu a zcela odstranit potřebu fragmentace.
• Pro pásmo EU863-870 při DR0 (SF12/125 kHz) je zde uvažovaný maximální aplikační payload přibližně 51 bajtů.
• ACRIOS převodníky nabízejí tři strategie fragmentace pro data, která se stále nevejdou do jednoho uplinku: Truncate, Split a Multiframe.
• Pro NB-IoT se kompletní M-Bus rámec obvykle vejde do jedné zprávy a ACRIOS může alternativně doručit již naparsované hodnoty jako JSON přes MQTT.
• Neexistuje univerzálně nejlepší strategie. Správná volba závisí na požadovaných datech, síti a parseru na přijímací straně.

‍

M-Bus parser čte datový telegram, který měřidlo odesílá přes protokol M-Bus, a extrahuje z něj jednotlivé hodnoty. Pokud musí tento telegram putovat přes LoRaWAN nebo NB-IoT, místo aby zůstal na drátové M-Bus lince, začíná hrát roli jeho velikost a schopnosti přijímací platformy.

Velký telegram nemusí být automaticky rozdělen. Je možné ho nejprve zredukovat na hodnoty, které aplikace skutečně potřebuje. Pokud se ani potom nevejde do dostupného síťového payloadu, vhodná strategie fragmentace závisí na síti a na tom, jak budou data zpracována na přijímací straně.

M-Bus byl navržen s důrazem na interoperabilitu, ne pro přenos dat přes rádiové sítě s omezenou kapacitou. Jediný telegram z tepelného měřidla může snadno přesáhnout 100 bajtů, protože M-Bus telegramy mohou obsahovat řadu různých hodnot a datových záznamů z měřidla. Na drátové sběrnici to funguje bez problémů. Problém nastává, když musí stejná data putovat přes síť, kde se celý rámec nevejde do jednoho uplinku.

ACRIOS převodníky řeší tuto situaci několika způsoby, které lze vybrat přímo v konfiguračním průvodci. Neexistuje univerzálně nejlepší strategie. Ta správná závisí na cílové síti a na parseru nebo platformě na přijímací straně. Strategii je třeba vybrat podle těchto požadavků, ne naopak.

Parsování, filtrování a fragmentace jsou tři různé kroky

Tyto pojmy spolu souvisí, ale řeší různé problémy.

• Parsování znamená interpretaci M-Bus telegramu a převod jeho zakódovaných záznamů na smysluplné hodnoty.
• Filtrování znamená výběr M-Bus záznamů, které je potřeba zachovat a přenést.
• Fragmentace znamená rozdělení dat do více zpráv, pokud se nevejdou do jednoho síťového payloadu.

‍

Toto rozlišení je důležité, protože velký M-Bus telegram nemusí automaticky vyžadovat fragmentaci. Pokud aplikace potřebuje jen část dostupných hodnot, filtrování může rámec zredukovat natolik, aby se vešel do jedné zprávy.

Filtrovat jako první: nejlepší fragmentace je žádná fragmentace

Než se rozhodne, jak rámec rozdělit, je třeba ho nejprve zredukovat. Filtrování podle VIF/DIF probíhá přímo na zařízení, takže jsou k přenosu předány pouze vybrané hodnoty. Ostatní data jsou vyřazena ještě před rádiovým přenosem.

Pro pásmo EU863-870 při DR0 (SF12/125 kHz) je cílem rámec do přibližně 51 bajtů, což typicky odpovídá zhruba čtyřem hodnotám. Přesný počet hodnot závisí na vybraných záznamech, takže rozhodující mírou je velikost rámce v bajtech. Pokud se vše, co aplikace potřebuje, vejde do tohoto limitu, fragmentace není potřeba a není ji nutné dále řešit.

První otázka tedy nezní: Kterou strategii fragmentace použít? Ale: Lze data zredukovat filtrováním natolik, aby se fragmentaci šlo úplně vyhnout? Pokud to není možné, existují tři strategie fragmentace, ze kterých lze vybírat.

Proč LoRaWAN a NB-IoT nejsou stejný problém

Toto rozlišení je důležité hned na začátku, protože zásadně ovlivňuje další volbu strategie.

LoRaWAN

Payload na LoRaWAN závisí na spreading factoru, data rate a regionálních parametrech. V pásmu EU863-870 je při vyšších data rate podstatně více prostoru; při DR0 (SF12/125 kHz) je zde uvažovaný maximální aplikační payload přibližně 51 bajtů na uplink.

Dostupný vysílací čas navíc omezuje duty cycle. Pokud i přefiltrovaný rámec stále přesahuje dostupný payload, fragmentaci se nelze vyhnout a každý další uplink zvyšuje potřebný vysílací čas.

NB-IoT

NB-IoT stejným omezením nepodléhá.nPayloady jsou mnohem větší a neexistuje duty cycle ve smyslu, jak ho známe z LoRaWAN, takže se kompletní M-Bus rámec obvykle vejde do jedné zprávy. V praxi to znamená, že na NB-IoT je rozdělování potřeba jen zřídka. Otevírá se tím také možnost doručení, kterou LoRaWAN nenabízí a která je popsána dále.

Co z toho vyplývá je, že strategie fragmentace nutná na LoRaWAN může být na NB-IoT zbytečná. Volbu je vždy třeba přizpůsobit síti.

Strategie 1: Truncate

Odešlou se jen vybrané VIF/DIF hodnoty a zbytek telegramu nad limit payloadu je odříznut.

• Výhody: nejmenší možné uplinky, nejnižší náklady a vždy jen jedna zpráva.
• Kompromisy: data za hranicí odříznutí jsou nenávratně ztracena. Jde o nevratný krok, takže důležité hodnoty musí s jistotou spadat do limitu. Na přijímací straně dorazí fragment, ne standardní M-Bus telegram, takže obecný parser ho nebude považovat za kompletní rámec.
• Nejvhodnější pro: nasazení, kde je potřeba jen několik klíčových hodnot a prioritou je minimální vysílací čas a náklady na přenos. Jde o rozumnou výchozí volbu pro zařízení na NB-IoT, kde jsou požadované datové body předem známé.

Strategie 2: Split

Celý telegram je rozdělen do číslovaných částí (0103, 0203, 0303 a tak dále) a znovu sestaven na backendu.

První dva bajty označují fragment a další bajt identifikuje měřidlo podle jeho indexu v převodníku, takže lze každý rámec přiřadit ke správnému měřidlu.

• Výhody: nic se nezahazuje, celý telegram je zachován. Overhead zůstává nízký, protože se M-Bus hlavička neopakuje v každém fragmentu.
• Kompromisy: tento přístup je citlivý na ztrátu jednotlivých fragmentů. Pokud se ztratí jediný rámec, původní telegram nelze kompletně sestavit ani zparsovat. Ztrácí se celý odečet, ne jen jedna hodnota. Jde také o nestandardní formát, takže přijímací strana potřebuje parser, který rozumí ACRIOS schématu dělení a doplňování dat. Obecný M-Bus parser nestačí.
• Nejvhodnější pro: případy, kdy je potřeba kompletní telegram, spojení je spolehlivé (na LoRaWAN zde mohou pomoci potvrzované uplinky) a parser na straně platformy je pod přímou kontrolou.

Strategie 3: Multiframe

Každý fragment je odeslán jako kompletní, samostatně platný M-Bus rámec s vlastní hlavičkou (68 2D 2D 68 ... 16).

• Výhody: každý paket je sám o sobě platný M-Bus rámec, takže lze použít obecný standardní M-Bus parser bez potřeby vlastní logiky pro sestavení. Protože je každý rámec samostatně platný, při ztrátě jednoho z nich jsou nedostupné pouze hodnoty obsažené v tomto rámci, nikoli celá zpráva.
• Kompromisy: Multiframe má z těchto tří strategií nejvyšší overhead. M-Bus hlavička se opakuje v každém rámci, takže se celkem odešle více bajtů přes více uplinků, což znamená více vysílacího času a větší využití dostupného duty cycle.
• Nejvhodnější pro: případy, kde je potřeba celý telegram a kompatibilita se standardním parserem. Na LoRaWAN je to výchozí volba vždy, když se ani přefiltrovaný rámec nevejde do jednoho uplinku. Vyšší využití vysílacího času je kompromisem za kompatibilitu se standardním M-Bus parserem.

Split vs Multiframe: co se stane při ztrátě paketu

Jde o jeden z nejdůležitějších praktických rozdílů mezi těmito dvěma strategiemi.

U Split tvoří číslované části společně jeden telegram. Než lze původní telegram sestavit, musí dorazit všechny potřebné fragmenty. Pokud jeden chybí, odečet nelze zparsovat vůbec.

U Multiframe je každý odeslaný rámec samostatně platný. Pokud se jeden rámec ztratí, nejsou dostupné pouze hodnoty z tohoto rámce. Zbývající rámce lze i tak normálně zparsovat.

Rozhodnutí tedy nezávisí jen na počtu přenesených bajtů. Záleží také na tom, jak se má přijímací platforma zachovat v případě, že část přenosu chybí.

Jen pro NB-IoT: MQTT s naparsovanými hodnotami ve formátu JSON

Na NB-IoT existuje čtvrtá možnost, která situaci mění. Zařízení místo odesílání nezpracovaných M-Bus rámců a jejich následného parsování publikuje již naparsované hodnoty jako JSON přes MQTT.

Není tak třeba řešit fragmentaci a na přijímací straně není potřeba M-Bus parser. MQTT navíc umožňuje obousměrnou komunikaci, takže lze konfiguraci upravovat přes downlink. Samotnou MQTT konfiguraci je nutné do zařízení nahrát.

Pro integrace, které již využívají MQTT broker, jde obvykle o nejčistší dostupnou variantu integrace.

Každá větev diagramu odpovídá jednomu ze čtyř řádků tabulky níže. Tabulka navíc doplňuje dvě věci, které diagram neřeší: kolik overheadu daná volba přidává a co potřebuje přijímací strana, aby to uměla zparsovat.

Srovnání strategií fragmentace M-Bus

Praktická logika vychází přímo z platformy: Nejprve filtrovat. Pokud se rámec vejde do přibližně 51 bajtů při EU863-870 DR0 (SF12/125 kHz), typicky kolem čtyř hodnot, žádná ze strategií fragmentace není potřeba.

Na LoRaWAN je Multiframe nejsilnější obecnou volbou, pokud se rámec nevejde, protože vytváří platné M-Bus rámce, které obecný parser přečte bez vlastní logiky pro sestavení. Split je vhodné zvolit, pokud záleží na úspoře vysílacího času a vlastní logika pro sestavení je akceptovatelná. Truncate je vhodné zvolit, pokud je potřeba jen několik klíčových hodnot.

Na NB-IoT je rozdělování obvykle zbytečné. Celý rámec lze odeslat v jedné zprávě nebo použít MQTT s naparsovanými hodnotami ve formátu JSON, pokud integrace již využívá MQTT broker.

Dva implementační detaily, které stojí za zmínku

Podporován je jen první rámec z vícetelegramové M-Bus odpovědi. Vybraná strategie navíc není v okamžiku nasazení fixní. Nastavuje se v konfiguračním průvodci a později ji lze změnit vzdáleně přes downlink. Pokud se požadavky nasazení změní, lze podle nich strategii upravit.

Potřebujete M-Bus parser? Ke stažení je M-Bus Parser (.js) v sekci nástrojů na ACRIOS Wiki, který slouží k přímému dekódování a interpretaci M-Bus zpráv. Lze ho využít při přípravě integrace, kontrole M-Bus telegramu nebo práci s fragmentovanými zprávami.

Slovníček pojmů

• M-Bus: evropský standard (EN 13757) pro vzdálené odečty měřidel, jako jsou měřidla tepla, vody a plynu.
• Telegram / rámec: datový paket, který měřidlo odesílá přes M-Bus a který obsahuje protokolové a hodnotové informace.
• M-Bus parser: software, který interpretuje M-Bus telegram a extrahuje jeho zakódované hodnoty z měřidla.
• VIF/DIF: informace v M-Bus telegramu, které slouží k identifikaci a interpretaci jednotlivých hodnot, které obsahuje.
• Spreading factor (SF): parametr LoRaWAN, který ovlivňuje datovou rychlost a dosah. Vyšší spreading factor, například SF12, znamená nižší datovou rychlost a umožňuje menší payload.
• Duty cycle: regulační omezení určující, kolik vysílacího času může rádiové zařízení využít během daného období.
• Fragmentace: rozdělení dat do více zpráv, protože se nevejdou do jednoho síťového payloadu.
• Truncate: strategie ACRIOS, při které jsou data nad dostupným limitem payloadu odříznuta.
• Split: strategie ACRIOS, při které je telegram rozdělen do číslovaných částí a znovu sestaven na přijímací straně.
• Multiframe: strategie ACRIOS, při které jsou data rozdělena do samostatně platných M-Bus rámců.
• LoRaWAN: protokol nízkopříkonové širokoplošné sítě (LPWAN) používaný pro dálkovou IoT konektivitu.
• NB-IoT: Narrowband IoT, mobilní nízkopříkonová širokoplošná technologie.
• MQTT: lehký komunikační protokol běžně používaný pro komunikaci IoT zařízení.