CONEXA - Theben Smart Metering · 6 USB-Anschluss für GSM, UMTS, wireless M-Bus Die USB-Schnittstellen sind aktuell nur für den gleichzeitigen Betrieb von einem Amber wM-Bus-Stick

CONEXA Kommunikationsmodul

Projektnummer: 2009 047 - 1 - Version 1.12 vom 23.07.2015

CONEXA

Kommunikationsmodul

Handbuch



Inhaltsverzeichnis

1 Sicherheit ...................................................................................................................................... 4

1.1 Bestimmungsgemäße Verwendung ........................................................................................... 4

1.2 Personalqualifikation .................................................................................................................. 4

1.3 Gefahrenhinweise ...................................................................................................................... 4

1.4 Symbolerklärung ........................................................................................................................ 4

2 Technische Daten ......................................................................................................................... 5

2.1 Elektrische Daten ....................................................................................................................... 5

2.2 Mechanische Daten ................................................................................................................... 5

2.3 Umgebungsbedingungen ........................................................................................................... 5

2.4 Angewendete Normen und Vorschriften .................................................................................... 5

3 Aufbau und Funktionen ................................................................................................................. 6

3.1 Kurzbeschreibung ...................................................................................................................... 6

3.2 Bedienelemente und Anschlüsse Conexa 1.0 ............................................................................ 7

3.3 Bedienelemente und Anschlüsse Conexa 2.0 ............................................................................ 8

3.4 Lieferumfang .............................................................................................................................. 9

3.5 Mechanischer Aufbau Conexa 1.0 ........................................................................................... 10

3.6 Mechanischer Aufbau Conexa 2.0 ........................................................................................... 11

3.7 Blockschaltbild ......................................................................................................................... 12

3.8 Beschreibung der Baugruppen ................................................................................................ 13

3.8.1 MCU-Platine ..................................................................................................................... 13

3.8.2 IO-Platine.......................................................................................................................... 13

3.8.3 Netzteil-Platine ................................................................................................................. 14

3.9 Stromversorgung ..................................................................................................................... 14

3.10 Anzeigen und Bedienelemente ................................................................................................ 15

3.11 Messperiode ............................................................................................................................ 21

3.12 Verhalten bei Spannungsausfall .............................................................................................. 21

3.13 Verhalten bei Spannungswiederkehr ....................................................................................... 21

3.14 Zubehör ................................................................................................................................... 22

4 Software ...................................................................................................................................... 23

4.1 Software-Struktur ..................................................................................................................... 23

4.2 Software zur Bedienung von Hardwareschnittstellen ............................................................... 27

4.2.1 D0-Schnittstelle / eHZ-Schnittstelle (optional) ................................................................... 27

4.2.2 Ethernet-Schnittstelle ........................................................................................................ 28

4.2.3 USB-Schnittstellen ............................................................................................................ 31

4.2.4 Micro-SD-Slot ................................................................................................................... 35



4.2.5 Digitale Ein- und Ausgänge .............................................................................................. 36

4.2.6 Software zur Abfrage von Eingabetasten .......................................................................... 37

4.3 Software zur Bedienung von Software-Schnittstellen ............................................................... 39

4.3.1 Das D-BUS-System .......................................................................................................... 39

4.3.2 Interface des Logsystems ................................................................................................. 40

4.3.3 Interface der Konfigurationsverwaltung ............................................................................. 41

4.3.4 Interface des Update Service ............................................................................................ 41

4.3.5 Interface des Zeitsystems ................................................................................................. 42

4.3.6 Interface des Display-Managers ....................................................................................... 42

4.3.7 Interface des I/O-Abstractionlayer ..................................................................................... 43

4.3.8 Interface der Mandantenverwaltung .................................................................................. 43

4.4 Verwendete Datensätze ........................................................................................................... 44

5 Sicherheitskonzept ...................................................................................................................... 45

5.1 Bedienfehler und falsche Messwertzuordnung ......................................................................... 47

5.2 Schutz gegen direkte Verfälschung von im SMG gespeicherten Messwerten .......................... 47

5.3 Parameter ................................................................................................................................ 48

5.3.1 Hardwaregesicherte Parameter ........................................................................................ 48

5.3.2 Ungesicherte und Log-Buch gesicherte Parameter ........................................................... 49

5.4 Schutz des Programmcodes .................................................................................................... 50

5.5 Schutz von übertragenen und gespeicherten Daten ................................................................ 50

5.6 Fehlererkennung der Zählerdaten ............................................................................................ 52

5.6.1 Umgang mit Zählerdaten die nicht monoton steigend sind ................................................ 52

5.7 Softwareinstallation und Update .............................................................................................. 53

5.8 Auflagen für den Verwender im Sinne der Mess- und Eichverordnung .................................... 57

5.9 Den Messstellenbetreiber betreffende Betriebsbedingungen ................................................... 58

6 Installation und Erstinbetriebnahme............................................................................................. 59

6.1 Anschluss und Montage Conexa 1.0 ........................................................................................ 59

6.2 Anschluss und Montage Conexa 2.0 ........................................................................................ 60

6.3 Erstinbetriebnahme .................................................................................................................. 61

7 Anhang ........................................................................................................................................ 62

7.1 Mit geltende Dokumente .......................................................................................................... 62

7.2 Empfehlungen für ergänzendes Zubehör ................................................................................. 62

8 Dokumentenhistorie .................................................................................................................... 63



1 Sicherheit

1.1 Bestimmungsgemäße Verwendung

Das Gerät ist für die Montage an der Wand vorgesehen oder in einem Zählerschrank untergebracht

und entspricht der Produktnorm EN 62052-11 (Messeinrichtungen) für Wechselstromzähler)

Schutzart IP 51 nach Einbau im entsprechenden Schaltschrank oder für den Wandaufbau im

Innenraum mit einer zusätzlichen Dichtung (Nr. 907 0 719)

1.2 Personalqualifikation

1.3 Gefahrenhinweise

Unsachgemäße Montage, Veränderungen oder falsche Bedienung können Personen und Sachschäden

verursachen.

Bei beschädigter oder entfernter Plombe sind die Daten der CONEXA nicht mehr für die

Abrechnung zugelassen.

Vor der Installation ist das Gerät auf Transportschäden zu überprüfen.

1.4 Symbolerklärung

CE-Kennzeichnung

Schutzisolierung; Gerät der Schutzklasse II



2 Technische Daten

2.1 Elektrische Daten

Betriebsspannung: festgelegter Betriebsbereich 230 V~ 1Ph; -10 % +10 %

erweiterter Betriebsbereich 230 V~ 1Ph; -20 % +15 %

Versorgung über Strombrücken (Jumper) (Conexa 1.0)

Versorgung über Anschlussklemmen (Conexa 2.0)

mit integrierter Feinsicherung 500 mA

Frequenz: 50 Hz

Eigenverbrauch: ca. 3 W (ohne USB)

max. Dauerversorgungsstrom

für USB-Devices: ≤ 200 mA (für beide gemeinsam)

Schutzklasse: II bei bestimmungsgemäßer Montage

Stoßspannungsfest bis 4 kV

ESD-Festigkeit bis 15 kV im Display- und Tastenbereich

2.2 Mechanische Daten

Gehäuseabmessungen (vertikaler Einbau):

Breite 178mm, Höhe 200mm (Conexa 1.0), Höhe 115mm (Conexa 2.0), Einbautiefe 90mm

Die Einbauhöhe eines Verbundsystems aus Q3D-Zähler mit kurzem Klemmendeckel

und CONEXA 1.0 beträgt nur ca. 280mm

Displayfenster ca. 70 x 37 mm

Gewicht vollbestückt ca. 980g

2.3 Umgebungsbedingungen

Festgelegter Betriebsbereich: -10 °C bis +45 °C (Temperaturbereichsklasse 3K5 mod.)

Grenzbereich für den Betrieb: -25 °C bis +55 °C (Temperaturbereichsklasse 3K6)

Grenzbereich für Lagerung und Transport:

-25 °C bis +70 °C ((Temperaturbereichsklasse 3K8H)

Schutzart: IP 51 nach EN60529

nach Einbau im entsprechenden Schaltschrank

oder für den Wandaufbau im Innenraum mit einer

zusätzlichen Dichtung (Nr. 907 0 719)

2.4 Angewendete Normen und Vorschriften

DIN EN 62052-11 Wechselstrom-Elektrizitätszähler

DIN EN 62056-61 Messung der elektrischen Energie Zählerstandsübertragung, Tarif- und Laststeuerung

PTB-A 50.7 mit Anhang 1 und 2

Anforderungen an elektronische und softwaregesteuerte Messgeräte und Zusatzeinrichtungen für Elektrizität, Gas, Wasser und Wärme

PTB-A 20.1 Messgeräte für Elektrizität Elektrizitätszähler und deren Zusatzeinrichtungen



3 Aufbau und Funktionen

3.1 Kurzbeschreibung

CONEXA ist eine Kommunikationseinheit mit PTB Zulassung (Geräteklasse 2 lt. PTB-A 50.7-2).

Die Conexa 1.0 wird mit dem elektronischen Stromzähler der Firma EasyMeter z.B. Q3D verbunden und

von zusätzlichen Zählern (Strom, Gas, Wasser, Wärme) mit deren gemessenen Werten versorgt.

Die Conexa 2.0 wird autark (ohne Versorgung über EasyMeter-Zähler) betrieben und erhält von

verschiedenen Zählern (Strom, Gas, Wasser, Wärme) deren gemessene Werte (Zählerstände).

Die Messwerte werden gesammelt, signiert und gespeichert. Sie werden über Ethernet oder GSM/UMTS

verschlüsselt an eine Datenzentrale bei dem Versorger weitergeleitet, der diese Daten dann zur

Abrechnung mit seinem ERP-System verwendet.

Entsprechend den gesetzlichen Vorschriften des Datenschutzes werden alle Daten sicher übertragen.

Die kryptographisch verschlüsselten Daten werden über eine sichere Weitkommunikationsverbindung an

einen zertifizierten Datenserver übergeben.

Die CONEXA kann an den beiden Befestigungsschrauben der Abdeckung plombiert werden.



3.2 Bedienelemente und Anschlüsse Conexa 1.0

1 Strombrücke (Jumper, bei Theben bestellbar) Typ A: 9070715 (ungezählte/nicht gemessene Energie) (starr)

Typ A: 9070717 (ungezählte/nicht gemessene Energie) (mit Federkontakt)

Typ B: 9070716 (gezählte/gemessene Energie) (starr)

Typ B: 9070718 (gezählte/gemessene Energie) (mit Federkontakt)

2 Haken zur Führung der Datenleitung 3 Micro-SD-Speicherkarte 4 Ethernet 5 Steckklemmen (3 x 2 Steckklemmen, von links nach rechts): Klemmenpaar für einen digitalen Eingang (z. B. zur Erfassung eines Impulses)

nur potenzialfreier Kontakt zulässig!

Klemmenpaar zur Ansteuerung z. B. eines Schaltrelais (bistabil, eine Spule, 10V)

Klemmenpaar für optionalen Anschluss einer 2-Draht-Buskommunikation (nicht realisiert u. nicht bestückt)

6 USB-Anschluss für GSM, UMTS, wireless M-Bus Die USB-Schnittstellen sind aktuell nur für den gleichzeitigen Betrieb von einem Amber wM-Bus-Stick (AMB 8465-

M) und einem Sierra Wireless-Modem (GL6110 USB) geprüft.

7 Taste auf 8 Taste ab 9 Anschluss für Relais Ausgang zur Ansteuerung eines Relais (bistabil, zwei Spulen, 10V) für Steckertyp XH Connector von Firma JST 10 Schrauben (verbunden werden CONEXA 1.0 mit dem elektrischen Zähler EasyMeter Q3B, Q3D)

11 RJ10 Buchse für den Anschluss eines Zählers (eHZ) (optional)

8

7

1

6

10

9

4

3

2

5

11



3.3 Bedienelemente und Anschlüsse Conexa 2.0

1 Haken zur Führung der Datenleitung 2 Micro-SD-Speicherkarte 3 Serielle Schnittstelle RS-232 4 Ethernet 5 3 Steckklemmen (für Drahtdurchmesser 0,5–1,5 mm²):

– linkes Klemmenpaar für Impulseingang (z. B. Erfassung eines Impulses) nur potenzialfreier Kontakt zulässig! – mittleres Klemmenpaar zur Ansteuerung z. B. eines Schaltrelais (bistabil, eine Spule, 10 V) – rechtes Klemmenpaar „nicht bestückt“, aktuell ohne Funktion

6 USB-Anschluss für GSM, UMTS, wireless M-Bus Die USB-Schnittstellen sind aktuell nur für den gleichzeitigen Betrieb von einem Amber wM-Bus-Stick (AMB 8465-M) und einem Sierra Wireless-Modem (GL6110 USB) geprüft.

7 Anschluss für Relais (es handelt sich um einen Ausgang zur Ansteuerung eines Relais (bistabil, 2 Spulen, 10 V) für Steckertyp XH Connector von Firma JST

8 Schrauben 9 Netzanschlussklemme (darf nicht entfernt werden)



3.4 Lieferumfang

1 x Grundgerät CONEXA mit Abdeckung

Installations-Anleitung

1 Beutel mit 2 Schrauben zur Befestigung am Zähler

Optional: 1 Strombrücke zur Spannungsversorgung (Conexa 1.0)



3.5 Mechanischer Aufbau Conexa 1.0

Das Gehäuse besteht aus folgenden Teilen: Gehäuseunterteil fixiert die Netzteilplatine Rahmen wird mit Gehäuseunterteil verschraubt und trägt die I/O-Platte Gehäuseoberteil wird mit Rahmen verschraubt Einleger dient als Typenschild Klarsichtdeckel LCD Abdeckung, wird im Gehäuseoberteil verrastet und fixiert den Einleger Abdeckung wird auf Rahmen verschraubt, wird plombiert und hält die Tastenstößel



3.6 Mechanischer Aufbau Conexa 2.0

Das Gehäuse besteht aus folgenden Teilen: Gehäuseunterteil fixiert die Netzteilplatine Rahmen wird mit Gehäuseunterteil verschraubt und trägt die I/O-Platte Gehäuseoberteil wird mit Rahmen verschraubt Einleger dient als Typenschild Klarsichtdeckel LCD Abdeckung, wird im Gehäuseoberteil verrastet und fixiert den Einleger Abdeckung wird auf Rahmen verschraubt, wird plombiert und hält die Tastenstößel



3.7 Blockschaltbild



3.8 Beschreibung der Baugruppen

Die Hardware der CONEXA besteht aus 3 Leiterplattenbaugruppen:

MCU-Platte, IO-Platte und Netzteilplatte. Die Platinen sind mit Steckverbindern miteinander verbunden.

3.8.1 MCU-Platine

Auf dieser befindet sich der Controller (ATMEL AT91SAM9G20), der RAM-Speicher (64MB SD-

RAM) und der Flash-Speicher (128MB NAND-Flash). Außerdem sind hier die Spannungserzeugung

für den Core (1.0V), der Ethernetbaustein (PHY) und die Takterzeugung (400MHz ) untergebracht.

Zum Flashen des Prozessors ist die JTAG-Schnittstelle auf Testpins herausgeführt.

Die beiden Debug-Pins liegen ebenfalls auf Testpunkten.

Die Leiterplatte ist aus EMV Gründen als 8-lagige Multilayer-Platte ausgeführt.

3.8.2 IO-Platine

Auf dieser Platte sind alle Anschlüsse nach außen und die Spannungserzeugungen der einzelnen

Versorgungsspannungen in der CONEXA enthalten:

Spannungserzeugung für 10V

Diese Spannung geht zur optional bestückbaren RJ10 Buchse. Hier besteht die Möglichkeit einen

eHZ anzuschließen. Zusätzlich dient sie zur Versorgung der extern anschließbaren Relais.

Spannungserzeugung für 5V.

Diese wird für die USB-Versorgung verwendet.

Spannungserzeugung für 3,3V.

Diese dient zur internen Versorgung der MCU-Platte.

LAN-Anschluss mit 10/100Mbit

Der Ethernet-Anschluss wird vom Controller über den PHY (DP8384) und die magnetische Kopplung

auf die LAN-Buchse (RJ45) geleitet.

USB-Anschlüsse

2 USB-Anschlüsse sind auf der IO-Platine herausgeführt. Softwaretechnisch sind es HOST-

Schnittstellen, die Buchsen sind USB-A-Buchsen, die max. Übertagungsrate beträgt Full-Speed

(12MBit/s)

SD-Karte

Es befindet sich ein Halterung für eine Micro-SD-Karte auf der Platine. Die Karte hat eine Kapazität

von ≥ 2 GB und dient zur Speicherung der laufenden Messwerte sowie der LOG- und Konfigurations-

Dateien.

D0-Schnittstelle

Diese Schnittstelle dient zum Empfang der Daten vom Zähler (Easymeter), der direkt unter der

CONEXA befestigt ist. Die Übertragung erfolgt optisch (Infrarot) mit einer Übertragungsrate von 9600

Baud. Es wird nur empfangen.

eHZ-Schnittstelle

Diese Schnittstelle dient zum Empfang der Daten von Zählern, die über die RJ10 Buchse



angeschlossen werden. Die Übertragung erfolgt optisch (Infrarot) mit einer Übertragungsrate von

9600 Baud. Es wird nur empfangen.

LCD

Über eine Steckbuchse wird eine grafische LCD-Anzeige angeschlossen. Die Auflösung beträgt

64x128 Pixel. Im Normalbetrieb werden hier Datum und Uhrzeit im Wechsel mit dem aktuellen

Zählerwert angezeigt. Über die Menütasten lassen sich weitere Werte abrufen

Tasten

Über die 2 vorhandenen Tasten können verschiedene Werte zur Anzeige auf dem LCD-Display

abgerufen werden. Die Tasten dienen ausschließlich zur Navigation in den Anzeigemenüs.

Ausgänge und Eingänge

Auf der Platine befinden sich eine 2pol. Steckklemme (Anschlussquerschnitt max. 1,5mm2) zum

Anschluss von z.B.: einem Relais bistabil mit einer Spule.

Eine weitere 2pol. Steckklemme (Anschlussquerschnitt max. 1,5mm2) dient als Eingang. Hier können

z.B. digitale Signale empfangen werden.

Desweiteren gibt es einen 3pol. Steckverbinder zum Anschluss eines bistabilen Relais mit zwei

Spulen.

Die Leiterplatte ist aus EMV Gründen als 4-lagige Multilayer-Platte ausgeführt.

3.8.3 Netzteil-Platine

Das Netzteil ist ein einphasiges Trafo-Netzteil. Es stellt die grundsätzliche Versorgungsspannung (ca.

24VDC bis 35VDC) für das Gerät zur Verfügung.

3.9 Stromversorgung

Conexa 1.0:

Das Gerät wird über eine Strombrücke (Jumper) vom Zähler mit Netzspannung versorgt.

Die Strombrücken gibt es als Typ A oder Typ B Ausführung.

Bei Typ A wird der von der CONEXA 1.0 verbrauchte Strom nicht über den Zähler geleitet, d.h. der

Versorger trägt diese Stromkosten.

Bei Typ B wird der von der CONEXA 1.0 verbrauchte Strom mitgezählt, d.h. der Kunde trägt diese

Stromkosten.

In den Strombrücken ist eine 500 mA Feinsicherung integriert.

Conexa 2.0:

Das Gerät wird über Anschlussklemmen mit Netzspannung versorgt.

Nach der Anschlussklemme ist eine 500 mA Feinsicherung integriert.



3.10 Anzeigen und Bedienelemente

Generell gilt, alle in dieser Beschreibung verwendeten Zählernummern, Tarife, Hashwerte, IP Adressen,

Softwareversionen, Zertifikatsnummern, Datumsangaben und Zeitangaben dienen nur als Platzhalter. Im

Echtbetrieb können diese Werte von den hier verwendeten abweichen.

Im Normalbetrieb wird auf der grafischen LCD- Anzeige das Datum und die Uhrzeit im Wechsel mit der

Zähler Eigentumsnummer, dem aktuellen Zählerstand, der aktuellen Tarifbezeichnung und des

Tarifhashes angezeigt.

Datum und Uhrzeit werden für 10sec und der Zählerstand für 30sec angezeigt.

Die Zählerdaten sind die des unter der CONEXA befindlichen Easy-Meter Zählers. Sind mehrere

tarifierte Zähler vorhanden, dann wechselt die Anzeige der einzelnen Zähler durch.

Zusätzlich werden der Name und die Prüfsumme (Tarifhash) des aktiven Tarifes angezeigt. Die Anzeige

des Tarifnamens (TN) und des Tarifhashs (TH) wechseln im 5sec Rhythmus.

Durch kurzen Druck auf eine der beiden Tasten kann der Anzeige-Wechsel zwischen Zeitanzeige und

Zähleranzeige erzwungen werden.

Durch das Betätigen der oberen Taste für mehr als 3sec gelangt man in das Menü:

Durch kurzes Betätigen der unteren Taste wird die nächste Zeile ausgewählt (der linke Pfeil bewegt sich

nach unten). Nach der letzten Zeile wird das Menü um eine Zeile nach oben geschoben.

SMG Software

PIN Eingabe >

Netzwerkstatus >

Elek. Typenschild >

CONEXA Status > v

Theben CONEXA

2011-11-14

12:43

ZNr: 1018000046 *

000000584.52 kWh

TN: Happy Strom

ZNr: 1018000046 *

000000584.52 kWh

TH: 164022d4



Durch langes Drücken (> 1s) der unteren Taste gelangt man in das angewählte Untermenü.

1. PIN-Eingabe

Untere Taste kurz drücken bewegt den Pfeil nach unten, dann untere Taste lang drücken führt zur

Eingabe der PIN:

Die 1 blinkt.

Mit oberer/unterer Taste kurz wird die Ziffer hoch/runter gezählt, untere Taste lang geht zur

nächsten Stelle. Wenn alle 4 Stellen eingegeben wurden wird die PIN mit langem Druck auf die

untere Taste übernommen. Ist die PIN falsch, bleibt 0000 als PIN stehen, ist sie richtig, wird ****

angezeigt. Ein langer Druck auf die obere Taste bricht die Eingabe ab. Der Menüpunkt der Pin-

Eingabe hat nur Auswirkung wenn mehrere Mandanten in der Conexa konfiguriert sind. Ist nur

ein Mandant konfiguriert dann hat die PIN keine Bedeutung.

Nach richtig eingegebener PIN:

Nun sollte durch zweimaligem langen Druck der oberen Taste (Escape) in die Standardanzeige

zurückgewechselt werden. Ansonsten wechselt die Anzeige nach 20sek selbstständig in die

Standardanzeige.

SMG Software

CONEXA Status > ^ Konfig Änderungen > ZNr: 1018000051>

Eich-Log-Buch >

PIN Eingabe

PIN:

0000

0000

1

PIN Eingabe

PIN:

****

Abmelden



Hier wird nun im Wechsel mit der Uhrzeit, die dem Mandanten zugeordneten Zähler angezeigt.

Durch kurze Tastenbetätigungen (oben oder unten) können die Zähler und die Zeitanzeige

schneller nacheinander angezeigt werden.

Die Aktivierung der Zähleranzeige für den eingegebenen Mandanten kann über das PIN Menü

durch anwählen von „Abmelden“ und bestätigen durch längeren Druck der unteren Taste (OK)

wieder beendet werden.

Ansonsten bleibt die Zähleranzeige für 3min aktiviert und deaktiviert sich dann selbstständig.

2. Netzwerkstatus:

Ethernet aktiv: GPRS/UMTS aktiv:

Es wird angezeigt, dass (ob) das Ethernet-Netzwerk verbunden ist und welche IP-Adresse die

Conexa erhalten hat. Nach mehrfachem kurzen Druck auf die untere Taste erscheint der Status

der GPRS/UMTS-Verbindung.

3. Elektronisches Typenschild

Nach mehrfachem kurzem Drücken der unter Taste erscheinen weitere Werte:

Netzwerkstatus

Ethernet

verbunden

192.168.23.45

GPRS/UMTS v

Elek. Typenschild

Hardware:

CONEXA 1.0

Seriennummer:

1234236711 v

Netzwerkstatus

192.168.23.45 ^

GPRS/UMTS

nicht vorhanden

- - - - -

Netzwerkstatus

Ethernet

nicht vorhanden

- - - - -

GPRS/UMTS v

Netzwerkstatus

- - - - - ^

GPRS/UMTS

verbunden

dynamisch



4. Status der CONEXA:

Es werden die Eigentumsnummer der CONEXA, das Datum und die Uhrzeit des letzen

Kontaktes (Ping) mit der Datenzentrale sowie Datum und Uhrzeit der letzten gültigen Zähler-

Datenübertragung (Push) angezeigt.

5. Konfig-Änderungen

Bei der Conexa werden Änderungen an der Mandatenverwaltung, der Zählerverwaltung, der I/O

Abstractionlayer, des Displaymanager und der Zähleridentifikationsdatenbank durch eine

Konfiguration vorgenommen.

Bei jeder Veränderung einzelner Werte und damit einer neuen Konfiguration wird über den Inhalt

der Konfigurationsdatei ein Hashwert gebildet. Über diesen ist die Konfigurationsdatei eindeutig

identifizierbar.

Die Hashwerte werden mit Datum und Uhrzeit ihrer Aktivierung im eichtechnischen Logbuch

abgelegt. Dieses kann über die Datenzentrale ausgelesen werden.

Der Endkunde kann über den Menüpunkt Konfig-Änderungen die letzten 6 Konfigurations-Hash

auslesen und damit erkennen, wann welche Konfiguration eingespielt wurde.

Der eigentliche Hashwert ist 40 Zeichen lang. In der Anzeige sind aus Platz und

Übersichtlichkeitsgründen nur die ersten 20 Zeichen zu sehen.

Elek. Typenschild

Softwareversion: ^

1.5.0

Zertifikatsnummer:

DE-15-M-PTB-XXXX

CONEXA Status

Eigentuemer-Nr:

1234236711

DZ-Status:

2011-11-14 12:34 v

CONEXA Status

DZ-Status: ^

2011-11-14 12:34

Zaehlerdaten: 2011-11-14 12:30



In der dargestellten Beispielanzeige ist zu sehen, dass jetzt aktuell die Konfiguration mit dem

Hashwert „bccc2f90ef7861852680…..“ eingestellt ist.

Davor wurde am 18.04.2012 eine Konfiguration mit dem Hashwert „62c169a4d676df31b1fd…“

eingespielt.

6. ZNr: 1018000051 (Abfrage der letzten Tarifeinstellungen)

In diesem Menü werden die Änderungen an den Tarifkonfigurationen mit Datum und Hashwert

Mandanten- und Zählpunktbezogen angezeigt.

Der aktuelle Hashwert wird als erster angezeigt. Anschließend geht es immer weiter in die

Vergangenheit. Insgesamt können die letzten 6 Tarifwechsel abgefragt werden.

ZNr: 1018000051

vom: 09.04.2012

bis: jetzt

4ac406a8

vom: 08.04.2012 v

ZNr: 1018000051

vom: 08.04.2012 ^ bis: 09.04.2012 aff8983c

vom: 07.04.2012 v

ZNr: 1018000051

vom: 07.04.2012 ^ bis: 08.04.2012 4ac406a8

vom: 06.04.2012 v

ZNr: 1018000051

vom: 06.04.2012 ^ bis: 07.04.2012 aff8983c

vom: 05.04.2012 v

Konfig-Änderungen

vom: jetzt ^

bccc2f90ef7861852680

vom: 18.04.2012 62c169a4d676df31b1fd



Sind mehrere tarifierte Zähler vorhanden, dann gibt es für jeden einen eigenen Menüpunkt mit

der jeweiligen Zählpunktbezeichnung.

7. Eichtechnisches Logbuch

In diesem Menü können die neuesten 50 Einträge im eichtechnischen Logbuch abgefragt

werden. In diesem Log-Buch werden alle eichtechnisch relevanten Ereignisse gespeichert.

Hierbei handelt es sich um Einträge des Zeitsystems und um Konfigurationsänderungen von

eichtechnisch relevanten Parametern.

ZNr: 1018000051

vom: 05.04.2012 ^ bis: 06.04.2012 4ac406a8

vom: 05.04.2012 v

ZNr: 1018000051

4ac406a8 ^

vom: 05.04.2012 bis: 05.04.2012 aff8983c

vom: 05.04.2012

Eich-Log-Buch

* 18.04.2012 11:57 update 1 - bccc2f90ef786185 * 18.04.2012 11:54 v

Eich-Log-Buch

* 18.04.2012 11:54 update 1 - 62c169a4d676df31 * 18.04.2012 11:10 v



Die Einträge im Log-Buch werden jeweils mit Datum und Uhrzeit abgelegt.

Zur allgemeinen Beschreibung der Tasten-Funktionen siehe Abschnitt 4.2.6.

3.11 Messperiode

Folgende Messperioden sind konfigurierbar:

15min, 30min, hourly, daily, weekly, monthly, quaterly und yearly.

Der Start der Messperiode (von 15min bis daily) kann auf eine beliebige Uhrzeit konfiguriert werden.

Ab weekly startet die Messperiode immer um 0:00Uhr.

3.12 Verhalten bei Spannungsausfall

Spannungsunterbrechungen <= 20 ms werden überbrückt.

Bei Spannungsunterbrechungen >20 ms schaltet das Gerät ab.

Alle bis dahin gespeicherten Werte bleiben erhalten.

Während des Spannungsausfalls werden keine Messwerte erfasst, gespeichert und zur Datenzentrale

übertragen.

3.13 Verhalten bei Spannungswiederkehr

Bei Spannungswiederkehr führt das Gerät einen Restart durch.

Das Betriebssystem überprüft die Konsistenz der Dateistruktur und repariert sie gegebenenfalls

selbsttätig.

Die interne Systemzeit wird wie unter NTP-Client (Punkt 4.2.2.3) beschrieben gesetzt.

Sobald die Zeit gesetzt ist, werden wieder Zählerdaten erfasst, tarifiert, gespeichert und an die

Datenzentrale übermittelt.

Eich-Log-Buch

* 18.04.2012 11:10 logsystem 1 - Got a valid time * 18.04.2012 11:05 v



3.14 Zubehör

Conexa 1.0:

Folgende Zubehörteile können verwendet werden:

Strombrücke Typ A starr THEBEN Bestellnummer: 907 0 715

Strombrücke Typ A mit Federkontakt THEBEN Bestellnummer: 907 0 717

Strombrücke Typ B starr THEBEN Bestellnummer: 907 0 716

Strombrücke Typ B mit Federkontakt THEBEN Bestellnummer: 907 0 718

Dichtung für Wandaufbau THEBEN Bestellnummer: 907 0 719

Conexa 2.0:

Folgende Zubehörteile können verwendet werden:

Dichtung für Wandaufbau THEBEN Bestellnummer: 907 0 719



4 Software

4.1 Software-Struktur

Die SMG-Software ist vom Design so gestaltet, dass sie ohne Änderungen an eichrechtlich relevanten

Softwarebestandteilen an den Einsatz in unterschiedlichen Umgebungen angepasst werden kann. Sie

untergliedert sich deshalb in zwei getrennte Bereiche: die vorwiegend eichrechtlich relevante

„Basissoftware“, die bei der Produktion unveränderlich in das SMG eingebracht wird und eine

eichrechtlich nicht relevante und austauschbare Anwendungsschicht, die „Zusatzsoftware“. Der

Basissoftware kommen die folgenden Aufgaben zu:

Messwerte von Zählern zu empfangen, zu verarbeiten und persistent sowie fälschungssicher und

nachvollziehbar zu speichern

Messwerte von Zählern und andere eichrechtlich relevante Informationen fälschungssicher auf dem

LCD-Display anzuzeigen

ein sicheres Logbuch für eichrechtlich relevante Vorgänge zu führen

die Integrität der eichrechtlich relevanten Softwarebestandteile und Daten zu wahren und regelmäßig

zu prüfen

Applikationen aus der Anwendungsschicht einen direkten, unbeschränkten Zugriff auf Hardware-

Schnittstellen oder Daten abseits der abgesicherten Möglichkeiten zu verwehren

Applikationen aus der Anwendungsschicht Zugriff auf die fälschungssicher gespeicherten

Messdaten zu gewähren

Applikationen aus der Anwendungsschicht Zugriff auf die Weitverkehrskommunikation zu gewähren,

sofern dies nicht die Sicherheit von Software oder Daten einschränkt

Der Zusatzsoftware aus der Anwendungsschicht kommen die weitergehenden Aufgaben eines

Gateways zu:

Weiterleitung der Messwerte über das Weitverkehrsnetz zum Zwecke der Abrechnung

Anzeige von Zusatzinformationen im nicht eichrechtlich relevanten Abschnitt der LCD-Anzeige

Umsetzung weiterer, nicht näher beschriebener Mehrwertdienstleistungen

Aus dieser Aufteilung der Aufgaben wird ersichtlich, dass Anpassungen zur erfolgreichen Verwendung

des SMG in einer spezifischen Systemumgebung einzig an der nicht eichrechtlich relevanten Software

notwendig sind.



Das Blockschaltbild der Software ist in folgendem Diagramm dargestellt:



Aus diesem Diagramm wird ersichtlich, dass die Software zwei unterschiedliche Arten von Schnittstellen

aufweist: Hardware-Schnittstellen zur Anbindung von Zählern, Schalteinrichtungen und der

Weitverkehrsanbindung sowie Software-Schnittstellen, über die nicht eichpflichtige Zusatzsoftware auf

Bestandteile der eichpflichtigen Software zugreifen kann. Diese Schnittstellen werden in den folgenden

Abschnitten näher beschrieben.

Vom Gateway empfangene und verarbeitete Zählermesswerte werden vor der Langzeitspeicherung zum

Zweck des Manipulationsschutzes digital signiert. Diejenigen Bereiche der Basissoftware, die unsignierte

Zählerdaten verarbeiten, sind auf ein Minimum reduziert und haben kein softwareseitiges Interface zur

Anwendungsschicht. Bei der Verarbeitung der Zählerdaten werden die folgenden Schritte vollzogen:

Empfang der Daten auf der Hardware-Schnittstelle (Physikalische Übertragungsschicht)

Sicherungsschicht (Data Link Layer) und Vermittlungsschicht (Transport Layer) im Busabstraktor:

Ermitteln von Telegrammanfang und -ende, Prüfen von Parität oder Prüfsumme

Ermitteln des Absenders und Weiterleitung an den korrekten Empfänger

Application Layer der Kommunikation im Protokollumsetzer

Dekodierung des Zählerrohdatenformats

Übersetzung in das generische Datenformat für Zählerdaten, wie es von der Basissoftware

definiert ist: Liste von OBIS-Code + (Scaler, Unit, Value)

Weitermelden des Datensatzes an die Zählerverwaltung

Weiterverarbeitung des Datensatzes in der Zählerverwaltung

Zuordnung zu einem Zählpunkt (Informationen aus der Konfigurationsverwaltung)

Extraktion der relevanten Zählerdaten (abzuspeichernde OBIS-Codes) aus dem Datensatz

(Information aus der Konfigurationsverwaltung)

Ergänzung des Datensatzes um Tarifinformationen

a. Tarifmodul ist von der Mandantenverwaltung mit Preisinformationen konfiguriert

b. Tarifmodul erhält aktuellen Zählerstand und liefert zusätzliche OBIS-Codes mit

Tarifinformationen der zurückliegenden Abrechnungsperiode

Signatur und sichere Ablage des Zählerdatensatzes in der Zählerdatenbank



Der Datenverarbeitungspfad für empfangene Zählerdaten bis zur Speicherung ist in folgendem

Diagramm dargestellt. Eine Tarifierung von Zählerdatensätzen findet nur unter den folgenden

Voraussetzungen statt:

der Zählerdatensatz kommt von einem Stromzähler (gezähltes Medium ist elektrische Energie)

in der Mandantenverwaltung ist ein aktueller Tarif für den Zählpunkt hinterlegt, dem der Zähler

zugeordnet ist

der Zähler ist kabelgebunden, über wM-Bus oder optisch (D0-Schnittstelle) an das Gateway

angeschlossen (Information aus dem Busabstraktor)

In jedem anderen Fall wird keine Tarifierung vorgenommen. Die zur Verfügung stehenden

Tarifierungsmodule für die unterstützten Tarifmodelle sind im Developer Manual, Kapitel 3.9

beschrieben.



4.2 Software zur Bedienung von Hardwareschnittstellen

4.2.1 D0-Schnittstelle / eHZ-Schnittstelle (optional)

Einsatzzweck: Kommunikation mit geeichten Zählern, Empfang von Zählerdaten

Typ: Hardware-Schnittstelle

Kommunikationsrichtung: Eingangsschnittstelle

Befehlsinterpreter:

Bus-Abstraktor (abstractor-62056-21d)

Protokollumsetzer (protocol-62056-21d-obis)

Der Busabstraktor „abstractor-62056-21d“ empfängt einen Datenstrom von der D0-Schnittstelle und

filtert vollständige Zählerdatentelegramme nach DIN/EN 62056-21d heraus.

Ein solches Datentelegramm beginnt mit dem Zeichen „/“ und endet mit der Zeichensequenz „!\r\n“.

Hierbei bezeichnet „\r\n“ die zwei ASCII-Zeichen Carriage Return (Wagenrücklauf) und Newline

(Zeilenanfang). Die Zeichen „/“ und „!“ dürfen nicht an anderen Stellen des Telegramms auftauchen.

Die Schnittstelle wird mit den folgenden Parametern betrieben:

7 Datenbits, ein Stopbit, even parity, 9600 Baud.

Die folgenden Konditionen führen im „abstractor-62056-21d“ zur Erkennung einer ungültigen Eingabe:

Zwischen dem Empfang von Telegrammstart und Telegrammende sind mehr als 1.5 Sekunden

vergangen.

Das Telegramm umfasst mehr als 10000 Bytes.

Das Telegramm enthält Paritätsfehler bei mindestens einem Byte.

Gültige Eingaben werden an den Protokollumsetzer weitergereicht.

Der Protokollumsetzer analysiert den Inhalt des empfangenen Telegramms weitergehend und erwartet

die folgende Form eines jeden Telegramms:

/MMMS<Modell> <Version>\r\n

<OBIS-Kennzahl>(<Wert>[*Einheit])\r\n

...

!\r\n

Hierbei bedeuten im Telegrammheader MMM eine dreibuchstabige Herstellerkennung, S ein Zeichen,

das die Schnittstellenparameter der D0-Schnittstelle beschreibt, <Modell> die Modellbezeichnung des

Zählers und <Version> die Versionsnummer der Firmware des Zählers.

Nachfolgend werden Zeilen erwartet, die jeweils eine OBIS-Kennzahl in der Standardschreibweise A-

B:C.D.E*F enthalten. In runden Klammern wird der OBIS-Kennzahl der Datenwert mit optionaler Angabe

der physikalischen Einheit nachgestellt und die Zeile durch „\r\n“ abgeschlossen.

Das Telegramm wird durch ein Ausrufezeichen mit nachfolgendem Zeilenende abgeschlossen.

Entspricht ein Telegramm nicht diesem Format, wird die Eingabe als ungültig betrachtet und verworfen.

Die Anpassung des Protokollumsetzers an die Zähler verschiedener Hersteller, die teilweise voneinander

abweichende OBIS-Kennzahlen oder physikalische Einheiten für wichtige Zählerdaten benutzen,

geschieht per Konfiguration von Transformationsregeln in der Zähleridentifikationsdatenbank. Die

Transformationsregeln beeinflussen die Interpretation auf folgende Weisen:



Übersetzen der eingelesenen OBIS-Kennzahlen. Auf diese Weise kann erreicht werden, dass

herstellerspezifische OBIS-Kennzahlen für das gleiche Datum innerhalb des SMG durch eine

einheitliche OBIS-Kennzahl, etwa 1-0:1.8.0*255 für den Stromzählerstand, repräsentiert werden.

Angabe der Kodierung und der physikalischen Einheit des eingelesenen Wertes. Hier kann der

Protokollumsetzer angewiesen werden, das vom Zähler gemeldete Datum als bestimmten Datentyp

(Hexadezimalzahl, Integer, Fließkommazahl oder Zeichenkette) zu interpretieren. Entspricht der Wert

nicht dem erwarteten Format, wird die Eingabe als fehlerhaft verworfen.

Vorgabe von Zehnerpotenz (Scaler) und physikalischer Einheit (Unit). Diese Angaben werden vom

Protokollumsetzer benutzt, um den eingelesenen Wert in die korrekte physikalische Einheit zu

skalieren und auszugeben. Der abgespeicherte Datenwert errechnet sich dann zu:

<eingelesener Wert> * 10^<Scaler> in <Unit>-Einheiten.

Angaben über die erforderlichen OBIS-Kennzahlen. Mit einfachen booleschen Operatoren kann ein

Regelwerk aufgestellt werden, welche OBIS-Kennzahlen nach der Transformation zwingend im

übersetzten Datensatz enthalten sein müssen, damit die Eingabe nicht als ungültig verworfen wird.

Wird die Eingabe bis hierher als gültig betrachtet, wird sie zur weiteren Verarbeitung und Ablage an die

Zählerverwaltung übergeben.

4.2.2 Ethernet-Schnittstelle

Einsatzzweck: Weitverkehrsnetzkommunikation


Kommunikationsrichtung: bidirektional

Befehlsinterpreter:

1. TCP/IP- sowie UDP/IP-Kommunikationsstack mit Paketfilter „iptables“

2. FTPS-Client

3. NTP-Client

4. DHCP-Client

Die Ethernet-Schnittstelle dient der Weitverkehrsnetzkommunikation des SMG und wird zu den

folgenden Zwecken in der Basissoftware des SMG verwendet:

Durchführen von Updates der fernparametrierbaren Konfigurationsparameter

Durchführen von Updates der nicht-eichpflichtigen Zusatzsoftware auf dem Gateway

Synchronisation der Systemzeit mit dem Zeitserver „pool.ntp.org“

4.2.2.1 Netzwerk-Kommunikationsstack

Als TCP/IP sowie UDP/IP-Kommunikationsstack wird der im Linux-Kernel integrierte Netzwerkstack

verwendet. Zudem findet der Paketfilter „iptables“ Anwendung.

Dieser Paketfilter ist so eingestellt, dass er

auf dem SMG eingehende TCP-Verbindungsanfragen verwirft,

auf dem SMG eingehende TCP-Datenpakete verwirft, wenn sie keiner etablierten TCP-Verbindung

zuzuordnen sind,



auf dem SMG eingehende TCP-Datenpakete an den nächstfolgenden Befehlsinterpreter

(Empfänger) weiterleitet, wenn sie einer etablierten TCP-Verbindung zuzuordnen sind,

vom SMG ausgehende TCP-Verbindungsanfragen verwirft, wenn sie nicht explizit durch im Manifest der anfragenden Applikation festgelegte Regeln erlaubt sind,

auf dem SMG eingehende UDP-Datenpakete verwirft, wenn sie keiner vorher vom SMG ausgehenden UDP-Anfrage zuzuordnen sind,

auf dem SMG eingehende UDP-Datenpakete an den nächstfolgenden Befehlsinterpreter (Empfänger) weiterleitet, wenn sie einer vorher vom SMG ausgehenden UDP-Anfrage zuzuordnen sind,

vom SMG ausgehende UDP-Anfragen verwirft, wenn sie nicht explizit durch im Manifest der anfragenden Applikation festgelegte Regeln erlaubt sind.

DHCP erlaubt.

Punkte 1 und 2 der Paketfilterkonfiguration legen fest, dass das SMG keine auf dem SMG eingehenden

TCP-Verbindungen zulässt. Punkt 3 gestattet den grundsätzlichen Betrieb von bidirektionalen TCP/IP-

Verbindungen. Punkte 4 und 5 der Paketfilterregeln legen dabei aber fest, dass sämtliche SMG-Software

nur TCP/IP-Verbindungen zu solchen Servern im Internet aufbauen darf, die für die anfragende

Applikation beim Erstellen der Software als vertrauenswürdige Gegenstelle des SMG eingeschätzt

wurden.

Beim verbindungslosen UDP-Protokoll ist die Konfigurationsregel 6 notwendig, um den auf UDP

basierenden DNS-Dienst zur Namensauflösung von Servern im Internet sowie DHCP nutzen zu können.

Regel 7 stellt sicher, dass auf dem SMG vorhandene Software nicht beliebige UDP-Dienste im Internet

nutzen darf. Konfigurationsregel 5 stellt sicher, dass das SMG alle anderen UDP-Pakete aus dem

Internet, die nicht als Antwort auf vom SMG initiierten Anfragen zu interpretieren sind, als ungültig

betrachtet und verwirft.

4.2.2.2 FTPS-Client

Der FPTS-Client wird von der Basissoftware dazu benutzt, Konfigurationsupdates für fernparametrier-

bare Einstellungen sowie Software-Updates für Zusatzsoftware von einem Download-Server herunter-

zuladen. Als Befehlsinterpreter wird das Programm „curl“ benutzt, das einen solchen Client (FTP über

SSL) implementiert.

Aus Gründen der Absicherung der Verbindung muss sich der Server im Internet durch ein gültiges

Zertifikat ausweisen, das gegen ein Stammzertifikat geprüft wird, das auf anderem Wege zusammen mit

dem Update-Befehl auf das SMG gelangt ist. Ebenso wird die URL des Updates, der Signaturprüf-

schlüssel sowie eine Prüfsumme mit dem Update-Befehl übertragen. Nach dem Download werden die

heruntergeladenen Dateien auf Integrität (SHA1-Summenprüfung) und Authentizität (digitale Signatur)

geprüft.

Das Format der Konfigurationsupdate-Dateien sowie die Signaturbildungsvorschrift sind im Developer

Manual, Kapitel 2 beschrieben. Entspricht ein Konfigurationsupdate nicht exakt diesem Format, wird die

Eingabe als ungültig betrachtet und verworfen. Nach erfolgreicher Syntax- und Signaturprüfung werden

die einzelnen auf dem Gateway laufenden Applikationen aufgefordert, ihr jeweiliges Konfigurations-

datenfragment auf semantische Korrektheit zu prüfen. Nur wenn das gesamte Konfigurationsupdate

auch semantisch korrekt ist, wird es akzeptiert und aktiviert, ansonsten wird die Eingabe als ungültig

betrachtet und verworfen.

Das Format von Software-Updates für die Zusatzsoftware besteht aus den folgenden Komponenten, die

jeweils in verschiedenen Dateien untergebracht sind:



Paketliste mit referenzierten Software-Paketen, die mit dem Paketmanager „e2pm“ kompatibel sind;

Dateiname: Packages

die digitale Signatur über die Paketliste vom Software-Integrator (Release Manager); Dateiname:

Packages.sig

eine Liste mit den benötigten öffentlichen Signaturprüfschlüsseln der einzelnen Softwarepaket-

Lieferanten; Dateiname: Packages.keys

die digitale Signatur über die Schlüsselliste vom Software-Integrator; Dateiname:

Packages.keys.sig

die von der Paketliste referenzierten Software-Pakete als epk-Dateien mit integrierter digitaler

Signatur; Dateiname: *.epk

Die Dateien werden per FTPS auf das SMG heruntergeladen. Vor der Installation werden die Signaturen

der Paketliste und der Schlüsselliste mit dem Signaturprüfschlüssel des Software-Integrators geprüft,

danach die Signaturen der Softwarepakete mit den in der Schlüsselliste enthaltenen öffentlichen

Schlüsseln der Pakethersteller – bei einem Fehler wird die Installation abgebrochen.

Nachfolgend wird die Paketliste auf Konsistenzfehler geprüft. Nur nach erfolgreicher Prüfung wird die

Installation weiter fortgesetzt. Nach dem Entpacken aller Softwarepakete in eine frisch geleerte Partition,

die ausschließlich für Zusatzsoftware benutzt wird, wird eine Überprüfung aller entpackten Dateien auf

Übereinstimmung mit der in den Paketen enthaltenen signierten Dateiliste durchgeführt.

Wurden Dateien nicht wie erwartet entpackt, bricht die Installation ebenfalls mit einem Fehler ab.

Nur nachdem alle Prüfungen erfolgreich durchgeführt wurden, wird die Partition aktiviert, die nun die

neue Software-Version enthält, und ein Neustart durchgeführt.

Durch das Update der Zusatzsoftware können keine Dateien geändert werden, die zur eichrechtlich

relevanten Software gehören.

4.2.2.3 NTP-Client

Der NTP-Client dient dazu, über das Netzwerk die Systemzeit des SMG mit dem Server „pool.ntp.org“

zu synchronisieren. Dabei kommt die Referenzimplementierung der NTP-Toolsuite des NTP Projekts

(siehe http://www.ntp.org) zum Einsatz.

Bei einem Systemstart wird das Programm „ntpdate“ dazu benutzt, die interne Systemzeit des SMG mit

dem Zeitserver im Internet zu synchronisieren. Danach wird der Dienst „ntpd“ dazu benutzt,

Abweichungen der Systemzeit im laufenden Betrieb zu erkennen und auszugleichen. Ohne gültige

Systemzeit führt die eichpflichtige Basissoftware ihre normale Funktion (Aufnahme, Tarifierung und

Ablage empfangener Messdaten) nicht aus.

Beide Programme unterscheiden gültige von ungültigen Eingaben. Ungültige Eingaben werden von den

Programmen verworfen.

Zur Nachvollziehbarkeit wird die Systemzeit auf dem LCD-Display in Form von Datum und Uhrzeit

dargestellt. Abweichungen von der amtlichen Zeit lassen sich dadurch feststellen.



4.2.2.4 DHCP-Client

Der DHCP-Client dient der automatischen Konfiguration der Parameter der Ethernet-Schnittstelle. Mit

diesem Dienst wird dem Gateway automatisch die Netzwerkkonfiguration mitgeteilt, die für den Betrieb

in dem Netzwerk am Einsatzort notwendig sind. Dazu gehören die IP-Adresse, einer oder mehrere DNS-

Server sowie, falls notwendig, der zum Erreichen des Internet notwendige Routers.

Auf dem SMG wird das Tool „dhclient“ aus der Busybox eingesetzt. Dieses Tool unterscheidet gültige

von ungültigen Eingaben. Ungültige Eingaben werden von diesem Programm verworfen. Der DHCP-

Client hat keinen direkten Einfluss auf die Funktion der Basissoftware.

4.2.3 USB-Schnittstellen

Das SMG ist mit zwei USB-Schnittstellen ausgestattet. Die USB-Schnittstellen dienen dem Anschluss

von einem Wireless M-Bus-Adapter und einem GSM/UMTS-Modem. Alle an den USB-Schnittstellen

angeschlossenen Geräte müssen sich als USB-Seriell-Konverter ausweisen, um erkannt und benutzt zu

werden. Andere USB-Geräte werden nicht vom SMG angesprochen.

4.2.3.1 Betrieb einer USB-Schnittstelle mit GSM/UMTS-Modem

Einsatzzweck: Weitverkehrsnetzkommunikation



Befehlsinterpreter:

USB-Seriell-Konverter-Treiber im Linux-Kernel

Connection Routing-Dienst der Basissoftware

PPP-Dienst

Ein an der USB-Schnittstelle angeschlossenes GSM/UMTS-Modem dient der Verbindung zum

Weitverkehrsnetz für den Fall, dass am Einsatzort des Gateways kein Ethernet-Netzwerk vorhanden ist,

das denselben Zweck erfüllt. Ethernet und GSM/UMTS-Modem können nicht gleichzeitig benutzt

werden.

Der Linux-Kernel-Treiber für das Modem stellt einen Kommunikationskanal zum Modem zur Verfügung,

der einer herkömmlichen seriellen Schnittstelle (RS232) entspricht.

Der Connection Routing-Dienst kommuniziert mit dem Modem über die vom Treiber zur Verfügung

gestellte serielle Schnittstellenemulation und richtet das Modem für die Interneteinwahl ein. Dazu gehört:

Durchführen eines Modem-Reset

Einrichten von Modem-Parametern

Entsperren der SIM-Karte durch Eingabe der PIN

Starten des PPP-Dienstes im on-Demand-Modus



Zum Einrichten des Modems sendet das Connection Routing AT-Kommandos an das Modem und

interpretiert die Reaktion des Modems auf die Befehle. Die Befehle, die an das Modem gesendet

werden, sind:

ATZ Modem-Softreset durchführen

ATH0 laufendes Gespräch beenden (hangup)

ATE0 Echo-Mode im Modem ausschalten

AT+CMEE=1 Erweiterte Fehlermeldungen des Modems aktivieren

AT+CFUN? Abfrage, ob der GSM-Stack des Modems aktiviert ist

AT+CFUN=1 GSM-Stack des Modems aktivieren

AT+CPIN? Abfrage, ob PIN-Eingabe notwendig ist

AT+CPIN=<PIN> PIN-Eingabe zum Entsperren der SIM-Karte

Auf jedes Kommando erwartet der Connection Routing-Dienst eine Antwort vom Modem, die über

Erfolg oder Fehlschlag des Kommandos Auskunft gibt. Die folgenden Antworten werden erkannt und

verarbeitet:

OK Kommando erfolgreich durchgeführt

+CPIN: SIM PIN PIN-Eingabe erforderlich

+CPIN: READY PIN-Eingabe nicht erforderlich

+CFUN: 1 GSM-Stack des Modems aktiv

+CFUN: 0 GSM-Stack des Modems inaktiv

+CME ERROR: ... Erweiterte Fehlermeldung des Modems (Abbruch)

+CMS ERROR: ... Erweiterte Fehlermeldung (Abbruch)

ERROR Fehlermeldung (Abbruch)

Alle anderen Eingaben werden ignoriert. Das Ausbleiben einer erwarteten Antwort des Modems wird als

Fehler gewertet und führt zum Abbruch des Vorgangs.

Wenn das Modem erfolgreich initialisiert ist, wird der PPP-Dienst gestartet. Er wartet darauf, dass eine

Verbindung zum Internet erforderlich ist und führt dann die Einwahl beim Internetprovider durch.

Nach erfolgter Einwahl stellt der PPP-Dienst dem SMG eine neue Netzwerkschnittstelle zur Verfügung,

die nahezu identisch zur Ethernet-Schnittstelle betrieben wird. Der einzige Unterschied ist, dass bei der

Modemeinwahl kein DHCP-Protokoll benötigt wird, da die Netzwerkparameter bereits während der

Einwahl ausgehandelt werden.

Der PPP-Dienst benutzt zur Einwahl beim Internetprovider das PPP-Protokoll.

Die Standardimplementierung PPP (siehe http://www.samba.org/ppp) wird auf dem SMG benutzt.

Die dazu gehörenden Tools erkennen selbsttätig ungültige Eingaben und brechen dann die Internet-

verbindung ab.



4.2.3.2 Betrieb mit wM-Bus-Adapter

Einsatzzweck: Auslesen von drahtlos angebundenen Zählern


Kommunikationsrichtung: Eingangsschnittstelle

Befehlsinterpreter:

USB-Seriell-Konverter-Treiber im Linux-Kernel

Busabstraktor (abstractor-wm-bus)

Protokollumsetzer (protocol-m-bus)

Ein an der USB-Schnittstelle angeschlossener wM-Bus-Adapter meldet sich als USB-Seriell-Konverter

am Gateway an. Der Linux-Kernel-Treiber stellt der Basissoftware die Emulation einer herkömmlichen

seriellen Schnittstelle zur Verfügung, über die die Basissoftware mit dem Adapter Daten austauschen

kann.

Der Busabstraktor „abstractor-wm-bus“ erwartet, dass an der emulierten Schnittstelle ein Modul

AMB8425-M von Amber Wireless angeschlossen ist. Der Busabstraktor stellt die Schnittstellen-

parameter auf 115200 Baud, even parity sowie 1 Stopbit ein und wartet auf empfangene Daten-

telegramme, die im Modus T1/T2 gemäß DIN/EN 13757 übermittelt wurden.

Das Modul AMB8425-M verwirft selbsttätig empfangene Telegramme mit CRC-Fehlern und meldet nur

intakte Telegramme an das SMG weiter.

Der Busabstraktor prüft bei den vom Amber-Modul übertragenen Daten seinerseits die Parität, um

Übertragungsfehler zwischen Amber-Modul und SMG zu erkennen.

Ungültige Eingaben mit Paritätsfehlern werden verworfen. Gültige Eingaben werden an einen

registrierten Protokollumsetzer für das empfange Telegramm weitergemeldet, der anhand der Adresse

des Absenders aus dem im Telegramm enthaltenen Rahmen gemäß EN 60870-5-2 FT3 ermittelt wird.

Der Protokollumsetzer „protocol-m-bus“ interpretiert empfangene Telegramme gemäß DIN/EN 13757-3.

Dabei werden nur die folgenden Telegrammtypen (telegram function and type of coding, CI-Feld im

Header) berücksichtigt:

0x72 – M-Bus Response from Device, 12 Byte Header

0x78 – M-Bus Response from Device, kein Header

0x7a – M-Bus Response from Device, 4 Byte Header

Weitergehend wird die Nachricht anhand des Nachrichtentyps klassifiziert (C-Feld).

Dabei werden im Fall von wireless M-Bus nur die folgenden Nachrichtentypen berücksichtigt:

0x44 – SND_NR (spontaneous / periodical application data without request)

0x46 – SND_IR (transmission of manually initiated installation data)

Andere Telegramm- oder Nachrichtentypen werden als ungültige Eingabe verworfen.

Der Protokollumsetzer unterstützt die Entschlüsselung des übertragenen Telegramms nach Encryption

mode 4 (DES, CBC, statischer Initialisierungsvektor) sowie Encryption mode 5 (128-bit AES, CBC,

dynamischer Initialisierungsvektor).

Der Verschlüsselungsmodus wird, wie die Anzahl der verschlüsselten Datenblocks, aus dem Signatur-

Feld des Telegramms entnommen.

Fehler bei der Entschlüsselung führen zu einem Verwerfen des Telegramms.



Bei Encryption mode 5 und 6 wird dem Signatur-Feld des Telegramms die Content Type-Information

entnommen. Unterstützte Werte sind:

0 – normales Datentelegramm mit variablen Daten (Default bei allen Encryption modes),

1 – vom Zähler signiertes Datentelegramm zu Abrechnungszwecken,

2 – statisches Datentelegramm mit sich selten ändernden Werten.

Andere Content Type-Werte werden als ungültige Eingabe interpretiert und verworfen.

Die weitere Verarbeitung richtet sich danach, ob es sich um ein statisches Datentelegramm oder ein

Telegramm mit variablen Daten handelt.

Statische Datentelegramme werden abgespeichert und die darin enthaltenen Informationen benutzt, um

nachfolgende Telegramme mit variablen Daten mit den statischen Werten zu ergänzen.

Bei einem Telegramm mit variablen Daten werden die folgenden Verarbeitungsschritte durchlaufen:

die Meter-ID wird aus den Informationen Herstellerkennung, Zähleridentifikation, Versionsnummer

und Medientyp gebildet, die im Telegrammheader enthalten sind

der Zählerstatus wird aus dem Telegrammheader extrahiert

die im Telegramm enthaltene Variable Data Blocks wird in das generische Datenformat der

Basissoftware transformiert:

Anhand des Data Record Headers (DIF und VIF, optional mit Extensions) wird eine

Transformationsregel aus der Zähleridentifikationsdatenbank gesucht. Wird keine Regel

gefunden, wird der Variable Data Block ignoriert.

Die Transformationsregel legt die OBIS-Kennzahl des Datums im generischen Datenformat der

Basissoftware fest.

Die Transformationsregel bestimmt, wie der Datenwert zu interpretieren ist. Folgende Typen

werden unterstützt: AS_IS (keine Konvertierung, z.B. für Strings), NUMBER (BCD- oder

Integerzahl), UNSIGNED (vorzeichenlose BCD- oder Integerzahl), DATETIME (Datum und/oder

Uhrzeit). Außer bei AS_IS wird das DIF (Data Information Field) benutzt, um die vorliegende

Kodierung zu ermitteln und in das gewünschte Format umzuwandeln.

Die Transformationsregel bestimmt Scaler und Unit, die in das generische Datenformat der

Basissoftware übernommen werden. Das VIF (Value Information Field) wird nicht benutzt, um an

herstellerspezifische Interpretationen und Ergänzungen des Standards durch Konfiguration

anpassbar zu sein. Der aus dem Data Record so extrahierte und skalierte Datenwert berechnet

sich dann zu:

<eingelesener Wert> * 10^<Scaler> in <Unit> Einheiten

Danach wird der Zählerdatensatz um die Variable Data Blocks des zuletzt gespeicherten statischen

Telegramms ergänzt, wobei die o.g. Transformationsregeln angewendet werden. Bereits im

Zählerdatensatz erfasste OBIS-Kennzahlen werden nicht durch Informationen aus dem statischen

Telegramm überschrieben.

Mittels einfacher Boolescher Regeln, die in der Zähleridentifikationsdatenbank enthalten sind, wird

geprüft, ob der Zählerdatensatz nach der Konvertierung alle notwendigen OBIS-Kennzahlen enthält.

Fehlen einige der notwendigen OBIS-Kennzahlen, wird die Eingabe als ungültig betrachtet und

verworfen.

Zuletzt wird der Datensatz zur Signatur und Speicherung an die Zählerverwaltung übergeben.



4.2.4 Micro-SD-Slot

Einsatzzweck: Anbindung von persistentem Datenspeicher



Befehlsinterpreter: Geräte- und Dateisystemtreiber im Linux-Kernel

Das SMG ist mit einem Slot für µSD-Karten ausgestattet. Dieser Slot dient der Aufnahme eines

Speichermediums. Das Speichermedium muss für einen erfolgreichen Startvorgang des SMG bereits

zum Startzeitpunkt eingelegt sein und darf im laufenden Betrieb nicht entfernt werden. Die µSD-Karte

wird durch einen Siegelaufkleber nach dem Eichen gesichert.

Die folgenden Daten werden auf der µSD-Karte abgelegt.

Zählerdaten: Die von Zählern empfangenen, tarifierten und signierten Zählerdatensätze werden auf

der µSD-Karte gespeichert.

Systemmeldungen: Die SMG-Basissoftware generiert im laufenden Betrieb Systemmeldungen

(syslog), die im Fehlerfall dazu benutzt werden können, Probleme beim Betrieb des SMG zu

analysieren und zu beheben. Hierbei handelt es sich nicht um das eichrechtlich relevante Logbuch

des SMG.

Konfigurationsdaten: Die fernparametrierbaren Konfigurationsparameter werden kryptographisch

gesichert auf der SD-Karte abgelegt. Der Konfigurationsdienst bietet Applikationen ebenfalls die

Möglichkeit, geringe Datenmengen in Form von Schlüssel-Werte-Paaren persistent hier zu

speichern.

Persistenter Datenspeicher für Applikationen: Sofern es im Manifest einer Gateway-Applikation

festgeschrieben ist, bekommt die Applikation einen privaten Bereich auf der µSD-Karte zur

persistenten Ablage größerer Datenmengen zugewiesen. Die Größe dieses Datenbereichs ist im

Manifest vermerkt. Im laufenden Betrieb wird durch Quotas sichergestellt, dass die angegebene

Größe nicht überschritten wird.

Persistenter Zwischenspeicher für Updates der Zusatzsoftware: der Update-Service kann in diesem

Bereich aktuelle Zustandsinformationen sowie heruntergeladene Softwarepakete speichern.

Factory Defaults: eine Partition auf der µSD-Karte ist für die Vorinstallation von Zusatzsoftware für

das Bootstrapping während der Inbetriebnahme reserviert. In dieser Vorinstallation werden vom

Eigentümer des SMG Applikationen hinterlegt, die nach einer Neuinstallation des SMG dazu benutzt

werden, eine initiale Datenverbindung zu einem Server des Eigentümers zu etablieren. Ist diese

Verbindung hergestellt, kann die Inbetriebnahme des SMG durch Installation einer individualisierten

Zusatzsoftware sowie die individuelle Einstellung fernparametrierbarer Konfigurationsparameter

abgeschlossen werden.

Die Auswahl der Informationen, die auf der µSD-Karte abgelegt werden, ist so getroffen worden, dass

(mit Ausnahme des eichrechtlich relevanten Logbuchs sowie der Informationen aus dem „elektronischen

Typenschild“) das SMG durch ein Austauschen der µSD-Karte in den Auslieferungszustand

zurückversetzt werden kann.

Der Linux-Gerätetreiber für SD/MMC-Karten wird zur Ansteuerung der Hardware-Schnittstelle benutzt.

Dieser kann selbsttätig gültige von ungültigen Eingaben unterscheiden. Ungültige Eingaben werden

verworfen. Der Linux-Gerätetreiber für SD/MMC-Karten stellt die eingelegte µSD-Karte als ein

blockorientiertes Speichermedium für Dateisystemtreiber zur Verfügung.



Die Linux-Dateisystemtreiber stellen die auf der µSD-Karte vorhandenen Daten als einzelne Dateien zur

Verfügung. Es kommen die Dateisysteme „ext2“ und „ext3“ zum Einsatz. Die Dateisysteme auf der µSD-

Karte werden beim Starten des SMG auf Konsistenz oder Beschädigung hin untersucht. Bei nicht-

reparablen Fehlern am Dateisystem wird der Boot-Vorgang abgebrochen.

Die Dateisystemtreiber können selbsttätig gültige von ungültigen Eingaben unterscheiden. Beim

Erkennen von ungültigen Eingaben werden die folgenden Schritte unternommen:

Verwerfen der ungültigen Eingabe bei Fehlern mit geringer Schwere und Signalisierung eines Lese-

/Schreibfehlers an die SMG-Software

bei schwerwiegenden Fehlern wird die weitere Benutzung des Dateisystems unterbunden und das

Gateway neu gestartet.

4.2.5 Digitale Ein- und Ausgänge

Einsatzzweck: Abfrage oder Kontrolle binärer Hardware-Zustandsinformationen


Kommunikationsrichtung: unidirektional, Ein- oder Ausgang

Befehlsinterpreter: I/O-Abstractionlayer, Tastaturinterpreter

Das SMG verfügt über digitale Ein- und Ausgänge, die zum Schalten oder Abfragen von Hardware-zuständen dienen. Die Konfiguration, welcher I/O-Pin einer bestimmten Funktion zugeordnet ist, ist fest in die Basissoftware im eichrechtlich relevanten Bereich eingebettet und kann nicht geändert werden.

Die folgenden Ein-/Ausgänge können das Verhalten des SMG oder angeschlossener Geräte beeinflussen:

UP_BUTTON: digitaler Eingang, an den der „UP“-Taster angeschlossen ist

DOWN_BUTTON: digitaler Eingang, an den der „Down“-Taster angeschlossen ist

RELAIS-1: digitaler Ausgang, an den ein Schaltrelais angeschlossen werden kann.

RELAIS-0: digitaler Ausgang, an den ein Schaltrelais angeschlossen werden kann.

IMPULSE-0: digitaler Eingang

Die Taster werden von der Basissoftware allein zum Zweck der Navigation durch die auf dem LCD-Display anzeigbaren Informationen benutzt. Der Eingang wird von der Basissoftware ignoriert.

Die Ausgänge für das Schaltrelais und den Unterbrecher werden der Zusatzsoftware über den Dienst

I/O-Abstractionlayer zugänglich gemacht. Der Dienst bietet eine Software-Schnittstelle, über die die

Zusatzsoftware Schaltbefehle an den I/O-Abstractionlayer übermitteln kann. Diese Befehle werden vom

I/O-Abstractionlayer nur dann ausgeführt, wenn die anfragende Gateway-Applikation per

fernparametrierbarer Konfiguration ausdrücklich die Berechtigung dazu erhalten hat. Unberechtigte

Anfragen von Applikationen, die Schaltkontakte zu betätigen, werden vom I/O-Abstractionlayer als

ungültige Eingabe erkannt und verworfen.



4.2.6 Software zur Abfrage von Eingabetasten

Das SMG ist mit zwei Tastern ausgestattet, die der Navigation der auf dem LCD-Display angezeigten

Informationen dienen. Einer der Taster wird als „UP_BUTTON“ bezeichnet, der andere als

„DOWN_BUTTON“. Aus dem Zustand der Buttons werden vom Programm „CONEXA_keyboard“

Tastatureingaben generiert.

Für beide I/O-Pins werden die folgenden Zustände unterschieden:

Taster gedrückt: Zustand wechselt von logisch „aus“ auf logisch „an“ (flankengetriggerte Erkennung)

Taster losgelassen: Zustand wechselt von logisch „an“ auf logisch „aus“ (flankengetriggerte

Erkennung)

Die Regeln für das Umwandeln der I/O-Pin-Zustände in Tastatureingaben sind wie folgt:

UP_BUTTON-Taster drücken und innerhalb einer Sekunde loslassen: Generierung eines „KEY_UP“-

Events

UP_BUTTON-Taster drücken und länger als eine Sekunde gedrückt halten: Generierung eines

„KEY_ESC“-Events nach einer Sekunde

DOWN_BUTTON-Taster drücken und innerhalb einer Sekunde loslassen: Generierung eines

„KEY_DOWN“-Events

DOWN_BUTTON-Taster drücken und länger als eine Sekunde gedrückt halten: Generierung eines

„KEY_ENTER“-Events nach einer Sekunde

Für die Navigation in der Anzeige werden nur die vier simulierten Tasten KEY_UP, KEY_DOWN,

KEY_ENTER und KEY_ESC benötigt.

Die Displayanzeige wird vollständig von einem Dienst der Basissoftware im eichrechtlich relevanten

Bereich kontrolliert. Dieser Dienst, der „DisplayManager“ ist für die Ansteuerung des LCD-Displays

alleinig zuständig und bietet Gateway-Applikationen über eine Software-Schnittstelle die Möglichkeit,

Informationen für die Anzeige auf dem Display zu übergeben.

Die Displayanzeige ist in zwei getrennte Darstellungszustände geteilt. Im Normalzustand werden auf

zyklisch durchlaufenen Bildschirmen eichrechtlich relevante Informationen angezeigt (Uhrzeit/Datum im

Wechsel mit Zählereigentumsnummer, aktuellem Zählerstand und aktueller Tarifbezeichnung). Daneben

kann eine Menüdarstellung aktiviert werden, in der SMG-Zusatzsoftware Informationen darstellen kann.

Die Menüdarstellung ist optisch eindeutig von der Darstellung eichrechtlich relevanter Informationen

unterscheidbar. Je nach Darstellungszustand unterscheidet sich die Interpretation der Tastatureingaben.

Werden die Bildschirmseiten mit eichrechtlich relevanten Informationen zyklisch durchlaufen, haben die

vier unterschiedlichen Tastatureingaben die folgende Wirkung:

KEY_UP: Zurückspringen zur vorherigen Bildschirmseite

KEY_DOWN: Vorspringen zur nächsten Bildschirmseite

KEY_ENTER: Umschalten zwischen aktivierter und deaktivierter automatischer Umschaltung der

Bildschirmseiten

KEY_ESC: Einsprung in die Menüdarstellung



In der Menüdarstellung haben Gateway-Applikationen, die Bestandteil der Zusatzsoftware auf dem

Gateway sind, die Möglichkeit, eichrechtlich nicht relevante Inhalte darzustellen.

Jeder Applikation wird ein separates Untermenü im Hauptmenü zur Verfügung gestellt. Innerhalb dieses

Untermenüs kann die Applikation einzelne Punkte anzeigen, eine Definition weiterer Untermenüs ist

nicht erlaubt. Damit der Gateway-Applikation der Zugang zum Menüsystem gewährt wird, muss eine

Freischaltung im Manifest der anfragenden Applikation eingetragen sein, die gleichzeitig den Namen des

dargestellten Applikationsmenüs definiert. Dieser Name wird sowohl zur Auswahl im Hauptmenü als

auch als Bildschirmtitel im Applikationsuntermenü dargestellt.

Im Menüsystem werden die Tastatureingaben wie folgt interpretiert:

KEY_UP: vorhergehenden Menüpunkt selektieren

KEY_DOWN: nachfolgenden Menüpunkt selektieren

KEY_ENTER: Menüpunkt aktivieren (im Hauptmenü: Ansprung des Untermenüs der ausgewählten

Applikation, im Untermenü: Rückkehr aus dem Menüsystem)

KEY_ESC: Menü verlassen (im Hauptmenü: Rückkehr aus dem Menüsystem, im Untermenü:

Rücksprung in das Hauptmenü)

Die Navigationsmöglichkeiten sind in folgender Grafik dargestellt:



4.3 Software zur Bedienung von Software-Schnittstellen

Die Basissoftware im eichrechtlich relevanten Bereich bietet die Möglichkeit, nicht eichrechtlich relevante

Zusatzsoftware auf dem SMG über von ihr veröffentlichte Software-Schnittstellen Zugriff auf einige

Funktionen und Daten zu gewähren. Dabei gelten die folgenden Grundsätze:

Für unterschiedliche Aufgaben stehen innerhalb der Basissoftware jeweils unterschiedliche Dienste

(eigene Programme) zur Verfügung, die jeweils eine eigene Schnittstelle anbieten.

Ein Zugriff auf Funktionen und Daten der eichrechtlich relevanten Software abseits der angebotenen

Software-Schnittstellen wird von der Basissoftware unterbunden.

Der Zugriff auf Funktionen und Daten der eichrechtlich relevanten Software mit Hilfe der

angebotenen Software-Schnittstellen unterliegt der Zugriffskontrolle.

Der Zugriff auf einige Funktionen und Daten kann über gesonderte Eintragungen im Manifest

einer Zusatzapplikation gewährt werden.

Der Zugriff auf andere Funktionen und Daten unterliegt einer Freischaltung durch

fernparametrierbare Konfigurationseinstellungen des Dienstes, der die Schnittstelle anbietet.

Dabei muss die Applikations-ID der anfragenden Applikation ausdrücklich in die Freigabeliste des

Dienstes für das angefragte Datum eingetragen werden.

Unberechtigte Zugriffsversuche an einer Schnittstelle werden von dem Dienst, der die

Schnittstelle zur Verfügung stellt, verworfen.

Die Schnittstellen der Dienste aus dem eichrechtlich relevanten Bereich der Basissoftware können

von Zusatzsoftware auf dem Gateway nicht unterdrückt oder ersetzt werden.

Alle Dienste der Basissoftware benutzen das D-Bus-System, um ihre Schnittstellen zur Verfügung

zu stellen.

4.3.1 Das D-BUS-System

Das D-BUS-System ist ein System zur Interprozesskommunikation, mit dem verschiedene Programme

auf demselben Computer untereinander Nachrichten austauschen können. Das D-BUS-System setzt bei

der Kommunikation Prinzipien um, die aus objektorientierten Programmiersprachen bekannt sind.

Zentrale Komponente des D-BUS-Systems ist der D-BUS-Dienst „dbus-daemon“, ein Serverprozess,

der sämtliche Kommunikation über das D-BUS-System koordiniert.

Die folgenden Grundregeln gelten, um eine Schnittstelle auf dem D-BUS zur Verfügung zu stellen:

Der Dienst meldet sich beim dbus-daemon als Client Application an und bekommt eine eindeutige

Teilnehmerkennung.

Der Dienst kann eine zusätzliche Teilnehmerkennung (den Service-Namen) beim dbus-daemon

beantragen. Diese zusätzliche Teilnehmerkennung ist eine Zeichenkette bestimmter Syntax und

wird dazu benutzt, den Dienst anhand seiner logischen Funktion anzusprechen, beispielsweise

„org.emlix.smg.CustomerAdministration“. Der dbus-daemon erlaubt diese zusätzliche

Teilnehmerkennung, sofern derselbe Service-Name nicht bereits von einem anderen Dienst

benutzt wird.



Der Dienst meldet Objekte auf dem D-BUS an. Die Anmeldung und Abmeldung von D-BUS-Objekten

geschieht dynamisch zur Laufzeit. Die Objekte werden unter einem Objektpfad registriert, der als

String eine Syntax wie die von Dateinamen in UNIX-Systemen hat, etwa

„/org/emlix/smg/CustomerAdministration“. Das Objekt muss eines oder mehrere Interfaces anbieten.

Die Interfaces definieren Methoden, Eigenschaften (Properties) und Signale. Hier besteht die

Analogie zu objektorientierten Programmiersprachen mit Mehrfachvererbung: ein D-BUS-Objekt

entspricht einem instanziierten Klassenobjekt, das die Interfaces potentiell mehrerer Oberklassen

erben kann, und der Objektpfad dem Zeiger (oder der Referenz) auf das Klassenobjekt.

Der Dienst muss die angebotenen Objektmethoden geeignet implementieren. Methoden können

überladen sein und können einen oder mehrere Rückgabewerte zurückliefern.

Der Dienst muss in den angebotenen Objektmethoden geeignete Zugriffsbeschränkungen

implementieren. Die anfragende Applikation kann beim D-BUS-System anhand der

Benutzerkennung (User ID) identifiziert werden, die innerhalb des Sicherheitskonzepts des SMG

eindeutig einem Manifest zugeordnet werden kann.

Um eine Anfrage an einen Dienst über D-BUS zu stellen, muss die anfragende Applikation ebenfalls als

Client Application am D-Bus angemeldet sein, den Service-Namen oder die Teilnehmerkennung des

anzusprechenden Dienstes kennen, sowie den Objektpfad zur Instanz des anzusprechenden Objekts,

den Namen des Interfaces, den Methodennamen und die Methodensignatur. Diese Informationen

werden zusammen mit den Methodenargumenten in eine D-BUS-Nachricht kodiert und an den dbus-

daemon verschickt. Der dbus-daemon ist für die Weiterleitung der Nachricht und die Zustellung Antwort

(mit den Rückgabewerten) verantwortlich.

Das D-BUS-System bietet Unterstützung für Introspektion, also die Fähigkeit, zur Laufzeit Informationen

über registrierte Dienste, Objekte, Interfaces und Methoden sowie Properties zu ermitteln. Diese

Informationen werden vom D-BUS-System dazu benutzt, gültige Eingaben von ungültigen Eingaben zu

unterscheiden. Ungültige Eingaben werden vom D-BUS-System verworfen und ein D-BUS-Fehler

(entspricht einer Exception) zurückgemeldet.

Im Rahmen des SMG stellt jeder Dienst der Basissoftware im eichrechtlich relevanten Bereich einen

symbolischen Service-Namen zur Verfügung und definiert pro Dienst einen festen Objektnamen, über

den der Dienst angesprochen werden kann. Je nach Notwendigkeit kann der Dienst weitere D-BUS-

Objekte registrieren. Die Pfade zu diesen Objekten sind über das zentrale D-BUS-Objekt des Dienstes

erfragbar.

4.3.2 Interface des Logsystems

Zweck: Melden und Abfragen von Lognachrichten

Typ: Software-Schnittstelle

Zugriffsberechtigung: über User ID der anfragenden Applikation

Das Logsystem ist für die persistente Ablage sowie für die Abfrage von Lognachrichten zuständig. Unter

Lognachrichten werden hier sowohl Systemereignisse verstanden, die im laufenden Betrieb des

Gateways von der Software gemeldet werden, als auch Eintragungen in das eichtechnische Logbuch

des SMG.



Die Meldung neuer Lognachrichten über diese Schnittstelle ist im Zugriff auf Applikationen beschränkt,

die innerhalb des eichrechtlich relevanten Bereichs laufen. Versuche anderer Applikationen, auf diese

Methoden zuzugreifen, werden als ungültige Eingabe erkannt und verworfen.

Die Abfrage von Lognachrichten kann durch jede Applikation erfolgen.

Das zur Verfügung gestellte Interface (gültige Eingabe) ist in der API-Dokumentation zur SMG-

Basissoftware detailliert beschrieben.

4.3.3 Interface der Konfigurationsverwaltung

Zweck: Verwaltung fernparametrierter sowie SMG-lokaler Einstellungen Typ: Software-Schnittstelle Zugriffsberechtigung: über User ID der anfragenden Applikation Die Konfigurationsverwaltung bietet Gateway-Applikationen einen einheitlichen Zugriff auf Konfigurationswerte. Darunter fallen einerseits die fernparametrierbaren Konfigurationswerte. Andererseits kann der Konfigurationsdienst von Applikationen auch dazu genutzt werden, aktuelle Betriebsdaten in Form von lokalen Konfigurationswerten persistent zu speichern.

Jeder Konfigurationswert (sowohl fernparametrierbare als auch lokale Werte) wird einer bestimmten Gateway-Applikation zugeordnet. Die Konfigurationsverwaltung stellt sicher, dass jede Applikation nur Zugriff auf die ihr zugeordneten Konfigurationswerte hat und die Konfigurationswerte anderer Applikationen weder lesen noch ändern kann. Die User ID einer anfragenden Applikation wird dazu benutzt, den Zugriff auf Konfigurationswerte einzuschränken. Anfragen an Konfigurationswerte anderer Applikationen werden als ungültige Eingabe betrachtet und verworfen.

Weiterhin wird durch die Konfigurationsverwaltung sichergestellt, dass keine Applikation die ihr zugeordneten fernparametrierbaren Konfigurationswerte auf dem SMG verändern kann. Ein solcher Versuch wird als ungültige Eingabe erkannt und verworfen.

Das von der Konfigurationsverwaltung zur Verfügung gestellte Interface (gültige Eingabe) ist in der API-Dokumentation detailliert beschrieben.

4.3.4 Interface des Update Service

Zweck: Management von Konfigurations- und Zusatzsoftwareupdates Typ: Software-Schnittstelle Zugriffsberechtigung: Signaturprüfung Der Update Service hat zur Aufgabe, Updates der fernparametrierbaren Parameter sowie der Zusatzsoftware auf dem SMG durchzuführen sowie Informationen über die aktuell benutzten Konfigurations- und Softwareversionen zur Verfügung zu stellen.

Die Methoden zur Abfrage der aktuellen Versionen sind jeder Gateway-Applikation ohne Einschränkungen zugänglich. Die Methoden zur Beauftragung eines Software- oder Konfigurationsupdates müssen mit einer gültigen digitalen Signatur der Datenzentrale versehen sein, um akzeptiert und ausgeführt zu werden. Updatebefehle ohne gültige Signatur werden als ungültige Eingabe erkannt und verworfen.

Der für die Signaturprüfung notwendige öffentliche Schlüssel der Datenzentrale ist auf dem SMG gespeichert, der private Signaturschlüssel ist nur der Datenzentrale bekannt und wird niemals auf das SMG übertragen. Ein Wechsel der für die Verwaltung des SMG zuständigen Datenzentrale bedingt ebenfalls einen Austausch des auf dem SMG gespeicherten öffentlichen Signaturprüfschlüssels – auch hierzu bietet der Update Service eine Methode an. Der Befehl, einen neuen öffentlichen



Signaturprüfschlüssel einer Datenzentrale zu speichern, muss von einer momentan akzeptierten Datenzentrale digital signiert sein.

Das zur Verfügung gestellte Interface des Update Service (gültige Eingabe) ist in der API-Dokumentation beschrieben.

4.3.5 Interface des Zeitsystems

Zweck: Feststellung gültiger Systemzeit Typ: Software-Schnittstelle Zugangsberechtigung: keine Dem Zeitsystem obliegt die Feststellung, ob die aktuelle Systemzeit gültig ist oder nicht. Die Systemzeit wird dazu benutzt, beim Aufbau SSL-gesicherter Verbindungen die Gültigkeitsdauer des Serverzertifikats des Servers zu prüfen. Ebenfalls wird die Systemzeit für Zeitstempel in Zählerdatensätzen und Logbucheinträgen genutzt. Nach einem Systemstart liegt keine gültige Systemzeit vor. Erst nach der Zeitsynchronisation mit dem NTP-Server nimmt die Basissoftware des SMG ihre normale Funktion auf.

Das D-Bus-Interface des Zeitsystems erlaubt nur die Abfrage, ob die Systemzeit gültig ist oder nicht. Weiterhin werden vom Zeitsystem D-BUS-Signale generiert, wenn sich der Gültigkeitsstatus der Systemzeit ändert.

Das zur Verfügung gestellte Interface des Zeitsystems (gültige Eingabe) ist in der API-Dokumentation beschrieben.

4.3.6 Interface des Display-Managers

Zweck: Zugang zum Menüsystem des SMG


Zugangsberechtigung: über User ID der anfragenden Applikation

Der Display-Manager ist diejenige Komponente, die die Anzeige von Informationen auf dem eingebauten

LCD-Display übernimmt. Das gilt für die eichrechtlich relevanten Informationen, die auf dem LCD-

Display dargestellt werden müssen. Gleichzeitig bietet der Display-Manager berechtigten Gateway-

Applikationen auch die Möglichkeit, eigene Informationen optisch deutlich getrennt in Form eines Menüs

mit Titelzeile darzustellen.

Die Menüdarstellung unterstützt die rudimentäre Eingabe von Informationen (Ja/Nein-Abfragen, Texte,

Zahlen, IPv4-Adressen). Die eingegebenen Daten werden der Applikation weitergereicht, die das Menü

definiert hat, haben aber keinen Einfluss auf andere Funktionen der SMG-Software.

Nur solche Applikationen, die in ihrem Manifest eine Berechtigung dazu erhalten haben, dürfen ein

eigenes Menü innerhalb der LCD-Anzeige definieren. Wenn andere Applikationen versuchen, die

Funktionen des Menüsystems aufzurufen, wird die Eingabe als ungültig erkannt und verworfen. Zur

Identifikation wird die User ID der anfragenden Applikationen auf ein Manifest zurückgeführt und die

Eintragung darin geprüft.

Das zur Verfügung gestellte Interface des Display-Managers (gültige Eingabe) ist in der API-

Dokumentation detailliert beschrieben.



4.3.7 Interface des I/O-Abstractionlayer

Zweck: Verwaltung von Schaltkontakten



Der I/O-Abstractionlayer innerhalb der Basissoftware des SMG hat die Aufgabe, die am SMG

verfügbaren Schaltkontakte für Relais zu verwalten und Applikationen Zugriff darauf zu gewähren. Die

Schnittstelle stellt dazu einfache Schaltkommandos (ein-/aus-/umschalten) zur Verfügung. Der Zugriff

auf diese Funktionen wird nur gewährt, wenn die anfragende Applikation durch fernparametrierbare

Konfigurationseinstellungen dazu ermächtigt ist. Bei fehlender Berechtigung wird die Eingabe als

ungültig erkannt und ein Fehlerwert zurückgegeben.

Das zur Verfügung gestellte Interface des I/O-Abstractionlayer (gültige Eingabe) ist in der API-

Dokumentation detailliert beschrieben.

4.3.8 Interface der Mandantenverwaltung

Zweck: Zugriff auf Zählerdatensätze und Zählerstatusinformationen



Die Mandantenverwaltung (Customer Administration) gewährt Gateway-Applikationen Zugriff auf die

gespeicherten Zählerdaten. Der Gateway verwaltet Mandantenverhältnisse nach Vorgaben aus der

fernparametrisierbaren Konfiguration. Dabei sind die dem SMG bekannten Zählpunkte jeweils einem

(oder keinem) Mandanten zugeordnet und die Speicherung der aufgenommenen Zählwerte von einem

Zählpunkt erfolgt in einer separaten Datenbank für diesen Mandanten. Der Zugriff auf die Zählerdaten

von Zählpunkten ist ebenfalls auf einen jeweiligen Mandanten eingeschränkt. Auf diese Weise kann ein

„Ausspähen“ der Zählerdaten von unterschiedlichen Mandanten vermieden werden.

Die Zugriffsberechtigung erfolgt durch die mandantenbezogene Freischaltung des Zugangs für einzelne

Gateway-Applikationen in der fernparametrierbaren Konfiguration des SMG. Damit kann Applikationen

Zugriff auf die Daten eines Mandanten gewährt, gleichzeitig jedoch der Zugriff auf die Daten eines

anderen Mandanten verwehrt werden.

Die Mandantenverwaltung registriert ein zentrales D-BUS-Objekt für den Zugang zu den allgemeinen

Funktionen der Mandantenverwaltung, sowie für jeden Mandanten und jeden bekannten Zählpunkt ein

weiteres D-BUS-Objekt, über das die jeweiligen spezifischen Funktionen zugänglich sind.

Die Mandantenverwaltung führt bei jedem Aufruf einer Methode eine Berechtigungsprüfung durch und

erkennt unberechtigte Anfragen als ungültige Eingabe, die mit einer Fehlermeldung beantwortet wird.

Das zur Verfügung gestellte Interface der Mandantenverwaltung ist in der API-Dokumentation detailliert

beschrieben.



4.4 Verwendete Datensätze

Die folgenden Datensätze und Datenstrukturen werden von der eichpflichtigen Software verarbeitet:

Zählerdatensatz: diese Datenstruktur sowie die Signaturbildungsvorschrift über die darin enthaltenen

Daten sind im Developer Manual, Kapitel 4.5 beschrieben.

Update-Befehl für Zusatzsoftware und fernparametrierbare Konfigurationsdaten: Dieser Datensatz

sowie die Signaturbildungsvorschrift sind im Developer Manual, Kapitel 7.5 beschrieben.

Update-Befehl zum Installieren eines neuen Datenzentralenschlüssels: Dieser Datensatz sowie die

Signaturbildungsvorschrift sind im Developer Manual, Kapitel 7.5 beschrieben.

Konfigurationsupdate der fernparametrierbaren Konfigurationsparameter: Dieser Datensatz sowie die

Signaturbildungsvorschrift sind im Developer Manual, Kapitel 2.6ff beschrieben.

Zählerrohdaten gemäß DIN/EN 62056-21D sowie DIN/EN 13757 (siehe Punkt 4.2.1 D0-Schnittstelle)

Manifest-Dateien zum Starten von eichpflichtigen und nicht-eichpflichtigen Applikationen: Diese

Dateien sind im Developer Manual, Kapitel 1.5 beschrieben.



5 Sicherheitskonzept

Die Basissoftware des SMG beinhaltet zahlreiche Mechanismen zur Absicherung des Systems sowohl

gegen zufällige und unabsichtliche Informationsveränderungen als auch gegen gezielte Manipulation

und zur Vermeidung von Bedienfehlern.

Die folgenden Grundlagen liegen dem SMG in Form eines Sicherheitskonzepts zugrunde:

Die eichpflichtige Basissoftware ist auf einem Langzeitspeicher gespeichert, der eichtechnisch

gesichert ist.

Die eichpflichtige Basissoftware ist in einem nicht-modifizierbaren Dateisystem gespeichert. Das

verwendete Dateisystem ist designbedingt nicht in der Lage, Schreiboperationen auf dem

Langzeitspeicher durchzuführen und so Programminformationen zu verändern.

Die eichpflichtige Basissoftware ist so im Langzeitspeicher abgelegt, dass jederzeit eine Überprüfung

der Integrität aller Programmbestandteile möglich ist. Die Integritätsprüfung wird bei jedem

Systemstart vor dem Laden der Programme in den Arbeitsspeicher durchgeführt. Zur

Integritätsprüfung wird auf Funktionen des verwendeten Paketmanagementsystems zurückgegriffen,

das digitale Paketsignaturen unterstützt, die nach der Installation der Software-Pakete weiterhin

gültig überprüft werden können. Die zur Signaturprüfung notwendigen kryptografischen Schlüssel

sind auf dem SMG sicher gespeichert. Ist die SMG-Software beim Systemstart nicht integer, wird der

Startvorgang nicht fortgesetzt.

Die auf dem SMG laufenden Programme können sich zur Laufzeit abseits der existierenden

Softwareschnittstellen nicht gegenseitig beeinflussen. Für die unterschiedlichen Programme werden

jeweils separate Betriebsmittel (Arbeitsspeicher, Langzeitspeicher, ...) eingerichtet.

Die Applikationen der SMG-Software benötigen, um ausgeführt zu werden, ein sogenanntes

Manifest. In diesem Manifest können in unveränderlicher Weise notwendige Betriebsmittel der

Applikation festgeschrieben werden. Beim Systemstart werden der Applikation die angegebenen

Betriebsmittel zur Verfügung gestellt und andere Betriebsmittel entzogen.

Die Applikationen der SMG-Software werden jeweils in einer eigenen Sandbox-Umgebung

gestartet (einer sogenannten chroot-Umgebung), in der nur die Programm- und Datendateien

vorhanden sind, die die Applikation zwingend als Betriebsmittel zur Funktion benötigt

(Ausnahme: Init-Prozess und Update Service). Die benötigten Dateien werden aus den

Metadaten des Paketmanagements extrahiert und können durch Einträge in das Manifest

ergänzt werden, wenn die Abhängigkeit nicht im Paketmanagement vermerkt ist. Applikationen

aus dem nicht eichrechtlich relevanten Bereich stehen nicht alle Programm- und Datenfiles zur

Verfügung:

a. Diese Applikationen dürfen nicht auf Programmdateien aus dem eichrechtlich relevanten

Programmspeicher (rootfs) zugreifen.

b. Diese Applikationen dürfen nicht auf wichtige Datenfiles zugreifen (kryptografische

Schlüssel, Zählerdatenbanken, eichrechtlich relevantes Logbuch, ...).

c. Diese Applikationen dürfen nicht auf den internen D-BUS der eichpflichtigen

Basissoftware zugreifen, sondern nur auf die von der eichpflichtigen Basissoftware

exportierten Softwareschnittstellen.



Der Arbeitsspeicher wird der Applikation vom Betriebssystem so zur Verfügung gestellt, dass er

von anderen Programmen nicht beeinflusst werden kann. Das Betriebssystem macht hierzu

Gebrauch von der im Prozessor integrierten Memory Management Unit (MMU). Diese

hardwareunterstützte Speicherzuteilung kann von den Applikationen nicht beeinflusst werden.

Die Applikationen der SMG-Software werden in ihrer Befähigung, betriebssystemnahe

Funktionen zu benutzen, durch eine filigrane Rechteverwaltung mit Hilfe der sogenannten

Capabilities (Befähigungen) eingeschränkt. Das Betriebssystem berücksichtigt die Capabilities,

die einer Applikation zugewiesen wurden, bevor es eine angefragte Funktion ausführt. Alle

Capabilities, die einer Applikation zugeteilt werden, müssen über das Manifest der Applikation

eingestellt werden. Applikationen der Zusatzsoftware steht nur ein eingeschränkter Satz an

Capabilities zur Verfügung, der es verhindert, die eingebauten Sicherheitsmaßnahmen zu

umgehen.

Die Applikationen der SMG-Software werden in der benutzbaren Quantität der Betriebsmittel mit

Hilfe von Ressource Limits und Disk Quotas eingeschränkt. Die Menge der zur Verfügung

gestellten Betriebsmittel wird unveränderbar über das Manifest der Applikation eingestellt.

Jede Applikation bekommt eine eindeutige Kennung (die User ID), über die die Applikation zur

Laufzeit identifizierbar ist. Diese Kennung ist im Manifest der Applikation unveränderbar

festgeschrieben. Durch diese User ID erfolgt im laufenden Betrieb eine zusätzliche Einschränkung

beim Zugriff auf Dateien, Hardware-Schnittstellen und betriebssystemnahe Funktionen durch das

Betriebssystem. Weiterhin wird sie dazu benutzt, durch die fernparametrierbaren Einstellungen

Zugriffsrechte auf Zählerdaten und Schaltkontakte zu gewähren.

Das SMG ist im laufenden Betrieb mit dem Weitverkehrsnetz verbunden. Ein Paketfilter (Firewall)

sichert das System gegen Angriffe aus dem Internet:

Es werden keine aus dem Internet eingehenden Verbindungsanfragen akzeptiert. Alle Internet-

Kommunikation muss vom SMG aus initiiert werden.

Applikationen können keine direkten Verbindungen untereinander aufbauen.

Applikationen können keine direkten Verbindungen zu Servern im Internet aufbauen. Sie müssen

dazu den Connection Routing-Dienst benutzen.

Applikationen werden in der Auswahl der Server, zu denen sie Verbindungen aufbauen können,

durch Einträge im Manifest der Applikation eingeschränkt.

Der nicht eichpflichtigen Zusatzsoftware auf dem SMG ist der Zugang zur Ansteuerung von

Hardware-Schnittstellen abseits der zugelassenen Software-Schnittstellen verwehrt.

Durch die genannten Maßnahmen ist das SMG gegen verschiedene Fehler abgesichert. Dazu gehören:

zufällige, unbeabsichtigte Informationsveränderungen

gezielte, unerkannte Manipulation der Software auf dem Langzeitspeicher

gegenseitige Beeinflussung verschiedener Applikationen mit dem gezielten oder unbeabsichtigten

Effekt der Messwertverfälschung

Angriffe aus dem Internet auf gespeicherte Daten und Programme auf dem SMG.



5.1 Bedienfehler und falsche Messwertzuordnung

Das SMG bietet dem Benutzer keine Möglichkeit, durch falsche Bedienung unabsichtlich eine falsche

Zuordnung eines Messwertes zu einer Messung zu verursachen.

Die eichpflichtige Basissoftware des SMG ist so gestaltet, dass:

alle von Zählern empfangenen Messdaten nur verarbeitet werden, wenn das SMG eine gültige

Uhrzeit kennt,

alle von Zählern empfangenen Messdaten sofort beim Empfang mit einem Zeitstempel und einer

laufenden Sequenznummer versehen, einem Zählplatz zugeordnet, eventuell tarifiert und danach

sofort persistent gespeichert werden,

jeder Zählerdatensatz vor der persistenten Ablage durch Anbringen einer digitalen Signatur vor

unerkannten, nachträglichen Manipulationen geschützt wird,

sich durch die Bedienung des SMG keine Änderung der fernparametrierbaren Konfigurationsdaten

erreichen lässt, die die Zuordnung des Messwertes zu einem Zählpunkt bestimmt,

sowohl die eichpflichtige Basissoftware als auch die fernparametrierbaren Konfigurationsdaten des

SMG so abgespeichert sind, dass beabsichtigte oder unbeabsichtigte Veränderungen daran erkannt

werden.

Die Bedienung des SMG mit den zur Verfügung stehenden Tasten hat keinen Einfluss auf diese

Funktionen der SMG Basissoftware (siehe Punkt 4.2.6 Software zur Abfrage von Eingabetasten).

Das SMG bietet die Möglichkeit, sämtliche gespeicherten Zählerdaten aus dem Langzeitspeicher

auszulesen und per Datenfernübertragung an einen anderen Computer im Internet zu übertragen. Dabei

müssen die vom SMG an die Zählerdaten angebrachten zusätzlichen Informationen (Zeitstempel,

Sequenznummer, Tarifinformationen und digitale Signatur) mit übertragen werden. Die Basissoftware

bietet ebenfalls die Möglichkeit, die aus dem Langzeitspeicher gelesenen Zählerdatensätze für die

Übertragung mit einer zusätzlichen umhüllenden digitalen Signatur auszustatten, sodass das Fehlen

einzelner Datensätze nach der Übertragung bemerkt werden kann. Diese Funktionalität kann dazu

benutzt werden, dem Kunden die auf dem SMG im Langzeitspeicher abgelegten Daten über einen

Server im Internet zur Anzeige zu bringen.

5.2 Schutz gegen direkte Verfälschung von im SMG gespeicherten Messwerten

Bei dem hier vorgestellten Gerät ist kein Betriebssystem mit Bedienoberfläche vorhanden, das einem

Benutzer des Geräts einen direkten Zugriff auf die gespeicherten Daten gewährt.

Das Gerät unterstützt das Laden von Zusatzsoftware durch Softwareupdates. Das von der

eichpflichtigen Basissoftware (die von den Softwareupdates ausgenommen ist) umgesetzte

Sicherheitskonzept verbietet der geladenen Zusatzsoftware einen direkten Zugriff auf die gespeicherten

Daten. Die Daten können nur über die der Zusatzsoftware zur Verfügung gestellten öffentlichen

Software-Schnittstellen erfragt werden. Die Daten sind zudem mit einer digitalen Signatur versehen, die

eine unbemerkte Verfälschung der Daten ausschließt. Der benutzte private Signaturschlüssel ist der

Zusatzsoftware nicht zugänglich – damit kann die Signatur nach erfolgter Verfälschung der Messwerte

nicht neu berechnet werden.

Damit ist der direkte Zugriff auf die gespeicherten Daten nur den implementierten Programmen der

eichpflichtigen Basissoftware möglich.



5.3 Parameter

5.3.1 Hardwaregesicherte Parameter

Das SMG verwaltet die folgenden gesichert parametrierbaren Größen:

die weltweit eindeutige MAC-Adresse der Ethernet-Schnittstelle

Datentyp: 48-bit Binärwert

die Eigentumsnummer des SMG

Datentyp: Zeichenkette

der private Signaturschlüssel des Gateways

Datentyp: PEM-Datei

der öffentliche Signaturprüfschlüssel des Gateways

Datentyp: PEM-Datei

Diese gerätespezifischen Größen werden bei der Produktion in das SMG eingebracht und können

nachträglich nicht ohne Verletzung der eichtechnischen Sicherung verändert werden.

Die Parameter sind im NAND-Speicher des SMG gespeichert und während des Betriebs des SMG vor

einer Manipulation geschützt. Um diese Parameter zu ändern, sind die folgenden Schritte notwendig:

brechen des Eichsiegels, um das Gehäuse zu öffnen und Zugriff auf die MCU-Platte des SMG zu

erhalten

Anschließen von Kabeln an die auf der MCU-Platte vorhandene Debug-Schnittstelle

Zugriff auf den Bootloader des SMG, um dort den automatischen Systemstart zu unterbinden und die

Parameter im NAND-Flash des SMG zu ändern

Ein Zugriff auf die Debug-Schnittstelle, um Kontrolle über den Bootloader des SMG zu erhalten, ist ohne

Bruch des Eichsiegels nicht möglich. Der SMG-Software außerhalb des eichpflichtigen Bereichs ist ein

direkter Zugriff auf den NAND-Flash unmöglich.

Das SMG führt ein eichtechnisches Logbuch. In diesem Logbuch werden eichtechnische Logmeldungen

persistent und nachvollziehbar gespeichert. Jeder Eintrag in diesem Logbuch ist durch eine digitale

Signatur mit dem privaten Signaturschlüssel des SMG vor nachträglicher absichtlicher oder

unbeabsichtigter Verfälschung geschützt. Der Logbuch-Eintrag besteht aus den folgenden

Informationen:

einem Zeitstempel,

dem Namen der Applikation, die die Meldung ausgegeben hat,

einer textuellen Lognachricht, die das eingetretene Ereignis beschreibt,

der digitalen Signatur.



5.3.2 Ungesicherte und Log-Buch gesicherte Parameter

Die Software ist so ausgelegt, dass diese Parameter per Datenfernübertragung geändert werden

(fernparametrierbar). Eine Schnittstelle für die Parametrierung vor Ort ist nicht vorhanden.

Die Parameter werden im Folgenden den einzelnen Modulen der Basissoftware zugeordnet.

Mandantenverwaltung (logbuchgesichert): siehe Kapitel 3.9 im Developer Manual

Zuordnung von Zählerpunkten zu Mandanten

mandantenbezogene Konfiguration von Tarifinformationen an Zählpunkten

Konfiguration der Zugriffsberechtigungen auf Zählerdaten

Zählerverwaltung (logbuchgesichert): siehe Kapitel 4.2 im Developer Manual

Zuordnung von Zählern zu Zählpunkten

Konfiguration der Umsetzung des Zählerrohdatenformats in das generische Format der

Basissoftware

Einstellung von Toleranzen für Fehler bei der Zählerauslesung

Connection Routing (ungesichert): siehe Kapitel 5.3 im Developer Manual

Einstellung, ob Ethernet oder GSM-Modem benutzt werden soll

Konfiguration der PPP-Einwahlparameter

I/O-Abstractionlayer (logbuchgesichert): siehe Kapitel 6.3 im Developer Manual

Zugriffsberechtigungen auf Schaltkontakte

Logsystem (logbuchgesichert): siehe Kapitel 8.1.3 im Developer Manual

Konfiguration der Vorhaltefrist für nicht eichtechnisch relevante Logbucheinträge

Konfiguration des maximalen Speicherverbrauchs für nicht eichtechnisch relevante

Logbucheinträge

DisplayManager (logbuchgesichert): siehe Kapitel 9 im Developer Manual

Anpassung von Bildschirmmeldungen. Hier kann die nur die Überschrift über der Zeitanzeige

firmenspezifisch angepasst werden. Statt Theben kann auch z.B.: SWU angezeigt werden.

Auswahl von darzustellenden Zählerdaten. Dies gilt nur bei Einmandatenbetrieb. Bei

Mehrmandatenbetrieb werden die Zählerdaten nur nach Eingabe der PIN angezeigt.

Zähleridentifikationsdatenbank (logbuchgesichert): siehe Kapitel 11 im Developer Manual

Anpassung der Übersetzung von Zählerrohdaten in das generische Datenformat der

Basissoftware

Regeln zur automatischen Erkennung von Zählertypen



5.4 Schutz des Programmcodes

Die eichpflichtige Basissoftware des SMG ist fest im NAND-Speicher des SMG einprogrammiert und

durch eine Eichplombe eichtechnisch gesichert. Die eichpflichtige Basissoftware umfasst alle Software,

die:

für den Systemstart des SMG notwendig ist

für die eichpflichtigen Funktionen des SMG notwendig ist

für die Sicherung der eichrechtlich relevanten Softwarebestandteile und Daten gegenüber

unbeabsichtigten oder zielgerichteten Verfälschungen notwendig ist

Diese Software-Bestandteile sind mehrfach gegen eine unzulässige und unbemerkte Änderung des

Programmcodes geschützt:

Absicherung durch Software-Signaturen, die beim Systemstart geprüft werden

Speichern der Software in einem nicht-modifizierbaren Dateisystem

im Rahmen des Sicherheitskonzepts die Unterbindung der Möglichkeit für Zusatzsoftware, Zugriff auf

den Datenspeicher zu erlangen

Das SMG unterstützt das Laden von Zusatzsoftware über die Netzwerk-Schnittstelle. Die eichpflichtige

Software des SMG ist für diesen Prozess (Laden über die Netzwerk-Schnittstelle, Installation der

Zusatzsoftware im persistenten Speicher und Ausführen der geladenen Zusatzsoftware) zuständig und

verhindert, dass dadurch eichpflichtige Software-Bestandteile auf unzulässige Weise modifiziert werden.

Der geladenen Zusatzsoftware wird die Möglichkeit, eichrechtlich relevante Software-Bestandteile und

Daten in unzulässiger Weise zu verfälschen, durch das beschriebene Sicherheitskonzept des SMG

entzogen. Ein Zugriff auf die Funktionen der Software sowie die gespeicherten Daten ist nur über die

von der eichpflichtigen Software veröffentlichten Schnittstellen möglich.

Das SMG führt eine automatische, zyklische Prüfung der eichpflichtigen Software im Langzeitspeicher

durch. Diese Prüfung wird einmal täglich durchgeführt und verifiziert die Signaturen der installierten

Software. Dadurch kann eine zufällige Informationsverfälschung im Langzeitspeicher durch

physikalische Effekte zuverlässig erkannt werden.

5.5 Schutz von übertragenen und gespeicherten Daten

Die eichpflichtige Basissoftware fasst die zu einem Messzeitpunkt erfassten, eichtechnisch relevanten

Informationen eines Zählers zu einem Zählerdatensatz zusammen.

Dieser Zählerdatensatz enthält:

einen Zeitstempel sowie eine laufende Nummer,

eine Liste von Kennzeichen-Werte-Paaren in der speziellen Form:

OBIS-Kennzahl => (Wert, Scaler, Einheit),

über diese Liste wird nach dem im Developer Manual beschriebenen Algorithmus eine digitale

Signatur gebildet,



die digitale Signatur.

Die digitale Signatur wird mit dem privaten Signaturschlüssel des SMG berechnet.

Die digitale Signatur wird vor der Langzeitspeicherung der Datensätze angebracht. Somit können von

einem empfangenden Gerät Verfälschungen an den Datensätzen durch Signaturprüfung erkannt

werden, unabhängig davon, ob die Verfälschung auf dem Datenspeicher oder während der

Datenfernübertragung über das Internet erfolgt sind.

Auch der öffentliche Signaturprüfschlüssel ist ein eichtechnisch gesicherter gerätespezifischer

Parameter. Jedes SMG erhält während der Produktion einen eigenen, individuellen Satz aus

Signaturschlüssel und Signaturprüfschlüssel. Neben der Funktion der angebrachten Signatur, die

Integrität der übermittelten Daten überprüfbar zu machen, kann durch die Verwendung individueller und

geheimer Signaturschlüssel gleichzeitig die Authentizität der Daten geprüft werden.

Die Aktualität der Datensätze kann durch den enthaltenen Zeitstempel und die Zählpunktbezeichnung

jederzeit geprüft werden. Wurde der Datensatz bereits einmal für diese Kombination aus Zeitstempel

und Zählpunktbezeichnung empfangen, handelt es sich bei dem empfangenen Datensatz um eine

erneute Übertragung.

Der Zeitstempel wird sofort nach dem Empfang des Zählerdatensatzes durch das Gateway und noch vor

der Signatur/Langzeitspeicherung angebracht. Anhand des Zeitstempels ist somit nachvollziehbar, wann

die Messung erfolgt ist. Eine unberechtigte Verzögerung der Daten ist damit ausgeschlossen.

Da Zusatzsoftware keinen Zugriff auf die Hardware-Schnittstellen erlangen kann, die für die

Messdatenaufnahme von Zählern am SMG zur Verfügung stehen, besteht keine Gefahr von Fehlleitung

oder nicht-autorisiertes Einspeisen von Daten in das System vor Anbringen der Signatur.

Die an den Datensätzen angebrachte Signatur wird mit dem asymmetrischen

Verschlüsselungsverfahren ECDSA (DSA mit Hilfe Elliptischer Kurven) berechnet, unter Zuhilfenahme

des Prüfsummenalgorithmus SHA1.

Im Kontext des SMG wird das spezielle Schlüsselformat „prime256v1“ eingesetzt (X9.62/SECG curve

over a 256 bit prime field). Der verwendete Schlüssel ist 256 Bit lang (entspricht 32 Bytes).

Der öffentliche, individuelle Signaturprüfschlüssel des SMG, der zur Prüfung der Signaturen an den

Datensätzen erforderlich ist, wird während der Produktion aus dem SMG ausgelesen und den

entsprechenden Kunden verfälschungssicher zur Verfügung gestellt.

Die Sicherheit des verwendeten Verschlüsselungsverfahrens beruht auf der Unbekanntheit des privaten

Signaturschlüssels. Der private Signaturschlüssel wird während der Produktion automatisch vom SMG

erzeugt und sicher abgelegt. Er kann nicht einmal vom Hersteller ausgelesen werden.

Nur der eichpflichtigen Basissoftware ist das Lesen des privaten Signaturschlüssels erlaubt. Andere

Software kann nicht auf diesen Schlüssel zugreifen.

Dadurch ist die allgemeine Unbekanntheit des privaten Signaturschlüssels und somit die Sicherheit der

übertragenen Daten hinreichend gewährleistet.

Das SMG führt eine automatische, zyklische Prüfung der Messwerte im Langzeitspeicher durch. Diese

Prüfung wird einmal täglich durchgeführt und verifiziert die Signaturen der gespeicherten Daten.

Dadurch kann eine zufällige Informationsverfälschung im Langzeitspeicher durch physikalische Effekte

zuverlässig erkannt werden.



5.6 Fehlererkennung der Zählerdaten

Funktionsfehler in softwaregesteuerter Hardware, die eine Verfälschung von Messwerten verursachen

könnten, werden vom SMG erkannt. Bei diesen Fehlern handelt es sich um Fehler beim Empfang von

Zählerdaten über die D0-Schnittstelle, die eHZ-Schnittstelle (RS-232) oder die USB-Schnittstelle (mit

wM-Bus-Modul oder MBus Pegelwandler). Bei allen Schnittstellen werden Paritätsprüfungen und, wo

möglich, CRC-Prüfungen der empfangenen Daten vorgenommen, wodurch eine mögliche

Messwertverfälschung erkannt werden kann. Ein Totalausfall der Hardware (kein Empfang von

Messwerten) wird ebenfalls erkannt.

Die folgenden Fehlerfälle werden vom SMG erkannt:

dauerhaft ausbleibender Empfang von Zählerdaten

dauerhaft auftretende Paritäts- oder CRC-Fehler

die Schnittstelle zum Empfang von Zählerdaten ist nicht ansprechbar oder nicht vorhanden

Die empfangenen Messdaten bei Stromzählern sind nicht monoton steigend

Der Gesamtzählerstand entspricht nicht der Summe der Tarifregister

Die zur Tarifierung benötigten Zählerstände (Obis-Kennung 1-0:1.8.0*255 oder 1-0:2.8.0*255) sind

nicht vorhanden

In dieses Fällen wird vom SMG eine Fehlermeldung generiert, die die Funktionsstörung beschreibt.

Diese Fehlermeldung wird der Zusatzsoftware zur Verfügung gestellt und durch diese in die zuständige

Datenzentrale übertragen. Von dort kann eine passende Reaktion auf den Fehler erfolgen:

Anpassung der fernparametrierbaren Konfigurationseinstellungen des SMG,

Behebung des Fehlers vor Ort durch einen Techniker.

5.6.1 Umgang mit Zählerdaten die nicht monoton steigend sind

Beim Einsatz von Zählern ohne Rücklaufsperre (z.B. saldierende Zähler) können im Betrieb nicht

monoton steigende Messwerte vorkommen.

Im Einpreistarif (Fix-Preis) versieht die CONEXA (SMG) den Messwert mit einem Zeitstempel und

versendet den Messwert. Liegt ein nicht monoton steigender Messwert vor, generiert das SMG eine

entsprechende Meldung. Diese Meldung wird der Zusatzsoftware zur Verfügung gestellt und durch diese

in die zuständige Datenzentrale übertragen.

Im Mehrpreistarif verwirft das SMG den nicht monoton steigenden Messwert und generiert eine

entsprechende Meldung. Diese Meldung wird der Zusatzsoftware zur Verfügung gestellt und durch diese

in die zuständige Datenzentrale übertragen. Von dort kann eine entsprechende Reaktion auf die

Meldung seitens des verantwortlichen Messstellenbetreibers erfolgen:

Anpassung der fernparametrierbaren Konfigurationseinstellungen des SMG

Anpassung der Messstelle durch z.B. Verwendung eines geeigneten Zählers



Grundsatz:

Der Messstellenbetreiber muss gewährleisten, dass der ordnungsgemäße Betrieb des SMG mit

Mehrpreistarif gewährleistet ist.

5.7 Softwareinstallation und Update

Die Software-Installationen auf dem SMG sowie die Software-Updates für die Zusatzsoftware setzen auf

dem Paketmanager „e2pm“ auf. Dieser Paketmanager basiert auf dem Debian-DPKG-Paketsystem und

ist um Funktionen zur Softwaresignatur und deren Prüfung erweitert worden.

Ein Software-Update besteht aus mehreren Dateien:

eine Paketliste mit zugehöriger Signatur-Datei (Packages und Packages.sig)

einer Schlüsselliste für die Software-Pakete mit zugehöriger Signatur-Datei (Packages.keys und

Packages.keys.sig)

den von der Paketliste referenzierten Softwarepaketdateien (*.epk) mit eingebetteter Prüfsummen-

datei und deren Signatur

Ein installiertes Software-System besteht ebenfalls aus mehreren Dateien in einem Dateisystem:

eine Liste installierter Pakete mit zugehöriger Signatur-Datei (Packages und Packages.sig), das

Format ist identisch zu dem beim Software-Update

einer Schlüsselliste für die Software-Pakete mit zugehöriger Signatur-Datei (Packages.keys und

Packages.keys.sig), das Format ist identisch zu dem beim Software-Update

eine Prüfsummendatei für jedes Softwarepaket und deren Signatur, das Format ist identisch zu dem

beim Software-Update

den aus den Softwarepaketdateien extrahierten Systemdateien

Die Paketliste ist eine zeilenorientierte Textdatei mit Key-Value-Paaren. Der Key beginnt jeweils am

Anfang einer Zeile und wird durch einen Doppelpunkt vom Wert getrennt, mehrzeilige Werte sind

möglich. Die Paketliste beschreibt eine vollständige Software-Installation und enthält Datensätze von

Metainformationen zu den einzelnen Softwarepaketen, aus denen die Installation besteht.

Einzelne Datensätze sind durch Leerzeilen voneinander getrennt. Die erlaubten Keys in den Metadaten

sind im e2pm Manual, Kapitel 5.2.9 beschrieben. Die Signatur über die Paketliste wird als Signatur über

den Inhalt der Paketlistendatei gebildet und in einer separaten Signaturdatei gespeichert. Wird die

Paketliste zur Beschreibung eines Software-Updates benutzt, wird sie auch Software-Profil genannt. Die

Gesamtheit aller zum Software-Update gehörenden Dateien (Signatur-Dateien, Schlüsselliste,

Paketdateien) heißt Software-Release.

Die Signaturdateien haben alle das gleiche Format. Es handelt sich um eine zeilenbasierte Textdatei. In

der ersten Zeile sind der für die Signaturberechnung benutzte Prüfsummenalgorithmus sowie der

Fingerprint des für die Signaturprüfung notwendigen öffentlichen Signaturprüfschlüssels (hexkodiert)



enthalten. In der zweiten Zeile befinden sich die Signaturdaten ebenfalls hexkodiert.

Hier ist ein Beispiel angegeben:

SHA1:51A512B838D1F5E8208B62C5BF64F37348DD38F8

4A6129F7659EE8C6CE18C2D5D429A682E71491D9521367F6E801AD7805...

Das Format der Schlüsselliste ist eine zeilenbasierte Textdatei, in der die Signaturprüfschlüssel im

standardisierten PEM-Format hintereinander gehängt sind. Die Signatur über die Schlüsselliste wird als

Signatur über den Inhalt der Schlüssellistendatei gebildet und in einer separaten Signaturdatei

gespeichert.

Das Format der e2pm-Paketdateien entspricht dem Debian-Paketformat mit spezifischen Erweiterungen.

Der Aufbau der Paketdateien ist in der folgenden Grafik dargestellt:



Das im Paket eingebettete, komprimierte tar-Archiv „control.tar.gz“ enthält Metainformationen und

(De-)Installationsanweisungen für das Paket. Da auf dem SMG kein Interpreter für Shellskripte

vorhanden ist, ist in diesem Kontext der Gebrauch der (De-)Installationsanweisungen untersagt.

Versuche, ein Paket mit solchen Anweisungen zu installieren, führen auf dem SMG zum Fehlschlag und

Abbruch der Installation.

Das im Paket eingebettete, komprimierte tar-Archiv „data.tar.gz“ enthält die zu installierenden Dateien.

Die darin enthaltenen Dateien werden unmodifiziert auf dem SMG extrahiert und die

Dateimetainformationen (Erstellungsdatum, Modifikationsdatum, Eigentümer und

Zugriffsberechtigungen) bei der Installation wiederhergestellt.

Die Prüfsummendatei „chksums“ enthält eine MD5- oder SHA1-Prüfsumme über alle Dateien, die in den

Archiven „control.tar.gz“ sowie „data.tar.gz“ enthalten sind. Diese Datei ist eine zeilenbasierte Textdatei

mit einer Zeile für jede geprüfte Datei. Die Zeilen sind jeweils in drei Spalten aufgeteilt. Die erste Spalte

enthält die Prüfsumme in Hexkodierung. Die zweite Spalte enthält den Dateinamen der geprüften Datei

(bei Dateien aus dem control-Tarball gilt die Sondernotation control:<filename>). Die dritte Spalte enthält

die folgenden gesicherten Dateimetainformationen (kommaseparierte Liste):

Dateityp (file/directory/symlink/chrdev/blkdev/FIFO)

Dateigröße in Bytes

User und Group (Dateieigentümer) als numerischer Wert

Zugriffsberechtigungen in Oktalschreibweise

Major-/Minornummer bei Gerätedateien

Link-Ziel bei symbolischen Links

Ist für einen Dateityp ein bestimmtes Attribut der Metainformationen nicht verfügbar, wird dies durch

einen Bindestrich „-“ vermerkt.

Die Signatur über diese Prüfsummendatei wird als Signatur über den Dateiinhalt der Prüfsummendatei

berechnet und in einer separaten Datei „chksums.sig.<X>“ gespeichert. Das Paketmanagement erlaubt

die mehrfache Signatur von Paketen mit unterschiedlichen privaten Signaturschlüsseln, weshalb dem

Dateinamen „chksums.sig“ eine laufende Nummer nachgestellt wird.

Bei der Installation werden sämtliche Paketmetadaten mit entpackt. Das Paketmanagement erwartet

eine Datenbank der installierten Pakete (standardmäßig im Verzeichnis /var/lib/e2pm der jeweiligen

Installation), in der die entpackten Paketmetadaten abgelegt sind. Nach erfolgter Installation müssen die

folgenden Dateien dort vorhanden sein:

Packages und Packages.sig

Packages.keys und Packages.keys.sig

<paketname>.control

<paketname>.chksums und <paketname>.chksums.sig.<X>

Das Software-Profil und die Schlüsselliste der Pakethersteller (Packages.keys-Datei) werden nach der

erfolgreichen Installation aller darin referenzierten Software-Pakete in die Datenbank des

Paketmanagements unter Beibehaltung der Signaturen kopiert. Dies ist eine legale Operation, da nach



der Installation aller im Software-Profil referenzierten Pakete das Software-Profil und die Liste

installierter Pakete identisch sind. Zudem liegen die entpackten Paket-Metadaten nach der Installation in

der Paketdatenbank vor.

Unabhängig davon, ob ein Software-Release oder eine Software-Installation vorliegt, gestaltet sich die

Verifikation der Signaturen und Prüfsummen nahezu gleich. Der Unterschied ist lediglich, ob die in der

Installation entpackten Dateien oder die in den epk-Paketen enthaltenen Dateien geprüft werden.

Die folgende Grafik veranschaulicht die Signatur- und Prüfsummenverkettung bei der SMG-Software.

Als Eingabe für die Integritätsprüfung dient der öffentliche Signaturprüfschlüssel des Software-

Integrators. Dann werden die folgenden Schritte durchlaufen:

Integritätsprüfung der Paketliste, Abbruch bei Fehler

Integritätsprüfung der Paketschlüsselliste, Abbruch bei Fehler

bei Software-Releases: Überprüfung der Prüfsummen über die epk-Dateien, Abbruch bei Fehler

für jedes Paket

Verifikation der Prüfsummen über die chksums-Signaturdateien anhand der Einträge in der

Paketliste, Abbruch bei Fehler

Ermitteln der Paketherstellerschlüssel aus der Schlüsselliste anhand des Fingerprints in den

chksums-Signaturdateien, Abbruch bei fehlenden Schlüsseln



Verifikation der Signaturen über die chksums-Datei, Abbruch bei Fehler

Verifikation der Prüfsummen und Dateimetadaten anhand der chksums-Datei, Abbruch bei

Fehler

a. bei Software-Releases: durch Analyse der in den tar-Archiven (control.tar.gz, data.tar.gz)

integrierten Dateien

b. bei Software-Installationen: durch Analyse der entpackten Dateien im Dateisystem

Der Hauptangriffspunkt ist die Integrität des öffentlichen Signaturprüfschlüssels des Software-

Integrators. Dieser Schlüssel ist im Falle der eichpflichtigen Software mit in das Paketmanagement

eingebunden (selbst signiertes Software-Release). Ein Austausch des Schlüssels auf dem SMG ist aus

folgenden Gründen für nicht autorisierte Personen nicht möglich:

Der Schlüssel befindet sich in einem Dateisystem, das prinzipiell keine Schreiboperationen

unterstützt.

Ein korrekter Austausch des Schlüssels bedingt eine Änderung an einem der Software-Pakete und

zieht somit eine Änderung der Paketliste nach sich.

Die Prüfsumme über die Paketliste dient als „Versionsnummer“ zur eindeutigen Identifizierung

der Software-Version der eichpflichtigen Software.

Ein Austausch des Schlüssels abseits des Paketmanagements zieht Integritätsfehler der

eichpflichtigen Software nach sich und verhindert ein Starten des Geräts.

5.8 Auflagen für den Verwender im Sinne der Mess- und Eichverordnung

Die Eichordnung verpflichtet diejenigen, die im Sinne des Eichrechtes Verwender eines Messgerätes

sind, so zu messen und Messgeräte so zu handhaben, dass die Richtigkeit der Messung gewährleistet

ist. Unter Berücksichtigung der Regelung von Marktrollen des Energiewirtschaftsgesetzes gelten in der

Zulassung folgende Festlegungen:

Verwender im Sinne des Eichrechtes sind:

Messgeräteverwender

Messgeräteverwender sind die Messstellenbetreiber im Sinne des EnWG.

Messwertverwender

Messwertverwender sind die, die im Sinne des EnWG Messung und Messwertweitergabe an berechtigte

Dritte durchführen, sowie Abrechnung der Netznutzung und Energielieferung durchführen.

Die Messgeräteverwender trifft die Aufgabe, den Messwertverwendern die Möglichkeit zu verschaffen,

sich über die nachfolgend erläuterten Auflage in Kenntnis zu setzen.

Die Verwendung von Messwerten von saldierenden E-Zählern durch die CONEXA ist nicht

zulässig.



5.9 Den Messstellenbetreiber betreffende Betriebsbedingungen

Bei den hier beschriebenen Geräten gehört zu Gewährleistung richtigen Messens in erheblichem Maße

eine sachkundige, zuverlässige Fernadministration der Geräte. Diese Administration ist Aufgabe des

Messstellenbetreibers und soll nur durch Personal erfolgen, dessen Qualifikation für den Umgang mit

den Geräten durch geeignete Managementmaßnahmen sichergestellt wurde (z.B.

Schulungsnachweise). Zur Administrationsaufgabe gehört die Entgegennahme von

Konfigurationswünschen des Stromlieferanten der Stromkunden, die über die an die CONEXA

angeschlossenen Elektrizitätszähler abgerechnet werden. Zur Administrationsaufgabe gehört

gleichermaßen die Weitergabe der Konfigurationsprotokolle (siehe unten a.4) und die Information über

die Messwertverwenderpflichten.

Die Administration ist ein Bestandteil der richtigen Geräteverwendung im Sinne der Mess- und

Eichverordnung und umfasst insbesondere auch folgende Handlungen:

a) Sicherstellung, dass nur eichrechtlich zulässige Konfigurationen auf das Gerät geladen werden.

Der eichrechtlich geforderte Anwendungsprozess zur Sicherstellung, dass nur eichrechtlich zulässige

Konfiguration auf das Gerät geladen wird besteht aus folgenden Schritten:

a.1) Erzeugung der Konfiguration nach gewünschtem Konfigurationsschema

a.2) Aufspielen der Konfiguration

a.3) Kontrolle des Erfolgs des Konfigurationsvorgangs

a.4) Dokumentation des Konfigurationsprozesses in einem Konfigurationsprotokoll zum Nachweis

gegenüber gegebenenfalls erfolgenden metrologischen Überwachungsmaßnahmen. Das

Protokoll beschreibt mindestens den erfolgreichen Ladeprozess mit allen zugehörigen

Parametern, als da sind: Konfigurationsdateien, deren Hash-Codes, Logbuchinhalt.

b) Kontrolle des eichtechnischen Logbuches des Gerätes

c) Erstellen und Pflegen eines Dokumentes mit der Beschreibung des Durchführungsprozesses

einer Befundprüfung.

d) Gewährleistung einfacher Verfügbarkeit eines CONEXA-Prüfsystems (entsprechend der

Beschreibung „CONEXA-Testsystem Zähler-Emulator und Prüfsoftware“ einschließlich

Testbeschreibung) zur Beistellung zu ggf. beantragten Befundprüfungen.

e) Gewährleistung der Verfügbarkeit der Bedienungsanleitung für Kunden, die über die

betriebenen CONEXA-Geräte abgerechnet werden.



6 Installation und Erstinbetriebnahme

6.1 Anschluss und Montage Conexa 1.0

CONEXA 1.0 wird mit Schutzdeckel ausgeliefert. Der Anschluss erfolgt über die rechte Strombrücke.

Montageanleitung der CONEXA 1.0 auf vormontierten EasyMeter Zähler:

Vor der Montage mit einem Schraubendreher die Schutzkappe der rechten Strombrücke am

Zähler entfernen.

CONEXA 1.0 von vorn nach hinten in die Schlitznute des Zählers schieben.

Strombrücke rechts einstecken.

Verbindungsschrauben für beide Gehäuse eindrehen.

Schutzdeckel bei CONEXA aufsetzen sowie Schrauben festdrehen.

ggf. Plomben anbringen



6.2 Anschluss und Montage Conexa 2.0

CONEXA 2.0 wird mit Schutzdeckel ausgeliefert.



6.3 Erstinbetriebnahme

Nach Anlegen der Versorgungsspannung beginnt das Betriebssystem zu booten und folgende Bilder erscheinen nacheinander auf der LCD-Anzeige:



Solange keine Verbindung zum Internet besteht, wird nach dem Bootvorgang "Kein Zeitsignal“ angezeigt.

Wenn eine Verbindung zu einem Zeitserver (NTP-Server) erreicht wird, wird die Zeit übernommen und die CONEXA beginnt die Zähler auszulesen, die Werte zu tarifieren, zu signieren und zu speichern. Die LCD-Anzeige wechselt dann zur Standardanzeige wie in Punkt 3.8 Anzeigen und Bedienelemente beschrieben.

Die CONEXA versucht nun regelmäßig eine Verbindung mit der Datenzentrale herzustellen und die Zählerdaten zu übertragen. Wie in Punkt 3.8 Anzeigen und Bedienelemente beschrieben, kann über das Menü CONEXA Status im Unterpunkt DZ Status festgestellt werden, ob die Verbindung zur Datenzentrale erfolgreich hergestellt wurde.

7 Anhang

7.1 Mit geltende Dokumente

Entwicklerhandbuch

API Dokumentation

7.2 Empfehlungen für ergänzendes Zubehör

Wireless M-Bus Empfänger:

AMBER Stick AMB 8425-M

GSM Modem:

SIERRA WIRELESS AirLink GL6110 USB



8 Dokumentenhistorie

Version Datum Änderungen Autor

1.0 2011-03-08 Erste Version ge, rxf, hb

1.1 2011-03-11 Seite 26 Abschnitt wireless MBus angepasst lt. kor hb

1.2 2011-11-15 Anzeige und Menü rxf, ge

1.3 2012-04-05 Anzeige und Menü (Tarifhash) ge

1.4 2012-04-10 Verweise korrigiert; ge

1.5 2012-04-24 Anzeige und Menü (Konfig-Änderungen; Eich-Log_Buch); Gesicherte und ungesicherte Parameter überarbeitet; eHZ-Schnittstelle aufgenommen

ge

1.6 2012-11-06 -Zusatzhinweis bei Anzeige und Menü. Angezeigte Werte stellen nur Platzhalter dar. -Beschreibung PIN-Eingabe verbessert. -techn. Daten geändert (USB) -Huawei Modem entfernt - Bedienelemente und Anschlüsse angepasst

ge

1.7 2013-03-13 -„Conexa 1.0“ durch „Conexa“ teilweise ersetzt -Kapitel 3.3 Bedienelemente und Anschlüsse Conexa 2.0 eingefügt. -Bei 2.1 elektrische Daten und 2.2 mechanischen Daten die Besonderheiten für Conexa 2.0 eingefügt. -Kapitel 3.6 Mechanischer Aufbau Conexa 2.0 eingefügt. -In Kapitel 3.9 Stromversorgung den Absatz für Conexa 2.0 eingefügt. -In Kapitel 3.14 Zubehör den Absatz für Conexa 2.0 eingefügt. -Kapitel 6.2 Anschluss und Montage Conexa 2.0 eingefügt. -Im Kapitel 6.3 Erstinbetriebnahme die Bezeichnung 1.0 aus den Bildern entfernt.

ea/ge

1.8 2013-07-16 -In Kapitel 3.1 Bild und die Beschreibung um die Conexa 2.0 erweitert. -Kapitel 3.2 und 3.3 harmonisiert

ge

1.9 2014-02-05 -In Kapitel 5.6 die Schnittstellen und die Liste der erkannten Fehlerfälle ergänzt.

ge

1.10 2014-04-08 - Kapitel 5.6.1 hinzugefügt ge

1.11 2015-05-20 - Anpassung der Bezeichnung Zulassungsnummer in Zertifikatsnummer - Kapitel 5.8 an neues Eichrecht angepasst - Stoßspannungsfestigkeit auf 4 kV angepasst

rst

1.12 2015-07-23 Anpassung der Überschrift von Kap. 5.8 an das neue Eichrecht. Ergänzung Kapitel 5.9

rst

Documents

CONEXA - Theben Smart Metering · 6 USB-Anschluss für GSM, UMTS, wireless M-Bus Die USB-Schnittstellen sind aktuell nur für den gleichzeitigen Betrieb von einem Amber wM-Bus-Stick