Mapper für geparste Datenbestände

Zielsetzung und Anwendungsbereich

Ziel dieses Dokuments ist es, den Leser in die Lage zu versetzen Daten, die grundlegenden Datenverarbeitungsprozesse der EMT Plattform, zu verstehen.

Das Dokument richtet sich gleichermaßen an Entwickler und Endnutzer der EMT Plattform.

Grundlagen

Die EMT Plattform speichert alle Daten im JSON Format. Die Datenhaltung wird daher über eine NoSQL Datenbank realisiert. Das Datenformat ist gleich, egal ob der Zugriff über den Datastore oder den Message Broker der EMT Plattform erfolgt.

Es ist zu beachten, dass einzelne JSON Dokumente innerhalb der EMT Plattform erweitert und nicht ersetzt werden.

Mindestinformationen des Dokumentes

Jedes JSON Dokument enthält mindestens den folgenden Satz an Informationen.

{
  "version": 1,
  "uid" : "CLSCON-7w98437",
  "clsbox" : "AA:BB:CC:DD:EE:FF",
  "ts" : { 
    "device":  1536049997,
    "server" : 1536049998 
  },
  "type": "omsraw",
  "data": {
    "ownernumber": "1122030",
    "raw": {
      "encrypted": "RGF0ZW5mb3JtYXQ="
    }
  }
}

Informationen aus Funkprotokollen

OMS / Wireless M-Bus

Bei OMS Zählern wird neben den verschlüsselten Rohdaten unterhalb von data.encrypted noch die Feldstärke des empfangenen Zählerstands übergeben. Der sogenannte RSSI Wert wird unterhalb von data hinterlegt.

{
  "data": {
     "rssi": -15
  }
}

Dies gilt für Daten bei denen das Feld type den Inhalt "omsraw" besitzt.

LoRaWAN

Für LoRaWAN Daten werden deutlich umfangreichere Informationen vom Gateway geliefert. Diese werden unter einem neuen Objekt data.lora abgelegt. Das RSSI Feld wird gleich zu OMS / Wireless M-Bus Zählern verwendet.

{
   "data": {
     "rssi": -15,
     "lora": {
       "codr": "4/5",
       "datr": "SF12BW125",
       "freq": 868100000,
       "lsnr": -8.5,
       "tmst": 1536049997,
       "chan": 0,
       "rfch": 1
    }
  }
}

Dies gilt für Daten bei denen das Feld type den Inhalt "lora" besitzt.

Verarbeitungsschritte

Parallel zur Speicherung der Daten in der Datenbank finden verschiedene Verarbeitungsschritte statt. Diese umfassen das Anreichern um weiteren Informationen, z.B. Geo-Lokationen, das Entschlüsseln der Rohdaten und das Parsing der entschlüsselten Rohdaten.

Erweiterung um Geo-Lokationen

Für einzelne Gateways, Datensammler und Sensoren können Geo-Lokationen im Inventar hinterlegt werden. Die Suchreihenfolge beginnt beim einzelnen Sensor und geht danach auf das Gateway über.

{
   "geo": {
     "lon": 49.4358807,
     "lat": 8.5271485,
     "alt": 109
  }
}

Erweiterung um Zählpunktbezeichnung

Für Sensoren kann die Zählpunktbezeichnung entweder direkt vom Gateway im Feld kommen oder sie werden nachträglich auf dem Server angehängt. Die Zählpunktbezeichnung wird im Feld zpb gespeichert.

{
   "zpb": "DE010101682190000101"
}

Verarbeitung OMS und M-Bus Rohdaten

OMS / Wireless M-Bus Rohdaten müssen je nach verwendetem EncryptionMode per AES entschlüsselt werden. Danach werden die Daten ebenso wie den Rohdaten von M-Bus Draht Zählern verarbeitet. Anschließend werden die Daten gemäß den Informationen aus den DIF(E) und VIF(E) in das Objekt data.unmapped übertragen.

Das Format für das Parserergebnis besteht aus einzelnen Bestandteilen, welche durch einen Doppelpunkt getrennt sind (es werden die englischen Begriffe aus der OMS Spezifikation verwendet, um eine möglichst einfache Zuordnung zu erreichen):

  • Subunit (dezimal)
  • Storage Number (dezimal)
  • Tariff (dezimal)
  • Oridinal des Function Blocks (hexadezimal)
  • DIF / DIFE (hexadezimal)
  • VIF / VIFE (hexadezimal)

Nach der Verarbeitung aller Daten entsteht das Objekt data.unmapped, hier am Beispiel eines EasyMeter Zählers. Bei OMS gibt es keine Notwendigkeit für jeden Zähler einen eigenen Parser zu nutzen, einzig die Mappingtabellen können sich für einzelne Zähler unterscheiden. Aus diesem Grund legt der Parser einen Hinweis für den passenden Mapper im Element data.hints.mapper ab.

{
   "data": {
     "raw": {
       "decrypted": "Entschlüsselte Rohdaten"
     },
     "hints": {
       "mapper": "ELECTRICTY_METER ESY 7"
     },
     "unmapped": {
       "0:0:0:0:4:a9ff02" : { "u" : 27, "v" : 0 }, 
       "0:0:0:0:4:a9ff03" : { "u" : 27, "v" : 1274.68 }, 
       "0:0:0:0:4:a9ff01" : { "u" : 27, "v" : 0 }, 
       "0:0:0:0:4:29" : { "u" : 27, "v" : 1274.68 }, 
       "0:0:0:0:13:79" : { "u" : 255, "v" : "1ESY1160011775" }
     }
  }
}

Die so entstandenen Daten können für kundenindividuelle Mapper verwendet werden oder werden an den internen Mapper der EMT Plattform weitergegeben.

Verarbeitung von LoRaWAN Rohdaten

Auf Grund eines fehlenden generischen Formats bei der Verarbeitung von LoRaWAN Rohdaten, gestaltet sich die Verarbeitung im Vergleich zum OMS Protokoll, als deutlich komplexer. Jeder Hersteller definiert sein Protokoll auf der LoRaWAN Ebene selbst. Aus diesem Grund muss der Parser bereits vom LoRa Network Server (LNS) einen Hinweis bekommen welcher Parser für die Umwandlung der Rohdaten anzuwenden ist. Da der LNS auch die Entschlüsselung der Rohdaten und die Deduplikation übernimmt, ist dies im selben Prozessschritt zu realisieren.

{
  "data": {
    "raw": {
      "decrypted": "Entschlüsselte Rohdaten"
    },
    "hints": {
      "parser": "LORA WATER_METER ZRI 1"
    }
  }
}

Für Entwickler ist relevant, dass der Inhalt des Feldes data.hints.parser auf der Ebene des MessageBrokers als sogenannter routingKey mit den Namen hints.parser übertragen wird. Dadurch können die notwendigen Verarbeitungsschritte direkt durch das zuständige Modul umgesetzt werden.

Daraufhin wird das JSON Dokument durch den Parser in einzelne Elemente übersetzt, wobei jeder Parser frei in der Deutung der Daten ist. Am Ende der Kette liefert der Parser ein Objekt zurück, welches vergleichbar mit dem des OMS Parsers ist. Die Bedeutung der einzelnen Felder muss über die Dokumentation des Parsers eindeutig beschrieben sein, um den passenden Mapper entwickeln zu können.

Neben den Daten unterhalb von data.unmapped legt der Parser noch einen Hinweis auf den Mapper unterhalb von data.hints.mapper ab und gibt die Information zurück auf den MessageBroker.

{
   "data": {
     "hints": {
       "mapper": "WATER_METER ZRI 1"
     },
     "unmapped": {
       "0:0:0:0:3:11" : { "u" : 255, "v" : 345.2 }
     }
  }
}

Umwandlung der geparsten Daten in OBIS IDs

Die EMT Plattform orientiert sich, wo immer möglich an den OBIS-Kennziffern des Metering Codes. Für die vielen, bereits am Markt verfügbare Zähler existieren daher die passenden Mappings um die Daten direkt in der Marktkommunikation verwenden zu können.

Das Mapping Konzept sieht mehrere Ebenen für die Zuordnung der Daten vor, der String "WATER_METER ZRI 1" innerhalb von data.hints.mapper drückt beispielsweise aus, dass es sich um einen Wasserzähler der Firma ZENNER Internation (ZRI) in der Version 1 handelt. Die Suche nach dem passenden Mapping läuft darauf hin rückwäts zu den angegebenen Elementen, das bedeutet, wird für "WATER_METER ZRI 1" kein Mapping gefunden wird nach "WATER_METER ZRI" gesucht, wird auch hierfür kein Mapping gefunden wird der generische Mapper "WATER_METER" für einen Wasserzähler angewendet. Für OMS funktioniert dieses generische Vorgehen sehr gut, da LoRa Daten - soweit möglich - auf die selbe Struktur gematcht werden, findet das Verfahren auch an dieser Stelle Anwendung.

Die einzelnen Suchschritte nach dem korrekten Mapping ermöglichen ist es spezifische Eigenarten und Protokolländerungen zwischen spezifischen Versionen eines Zählertypen zu korrigieren.

Am Ende werden die gemappten Werte im Element data.obis abgelegt, hier am Beispiel eines Stromzählers mit Leistungsbezug:

{
  "data": {
    "obis" : {
        "0100010800FF" : { "u" : 30, "v" : 478610.9 }
    }
  }
}

Wurde ein anderer Mapper verwendet als der unter data.hints.mapper angegebene, so wird das Feld entsprechend angepasst.

Eine Liste der genutzten OBIS Kennziffern finden sich im Dokument EDI@Energy Codeliste der OBIS-Kennzahlen für den deutschen Energiemarkt der Bundesnetzagentur. Für die Codierung der OBIS Kennziffern wird das COSEM Schema verwendet, dabei kommt die hexadezimale Repräsentation zum Einsatz.