Die EDE-Datei: die Datenpunktliste,
die sich prüfen lässt

Ihre Anlage kann die Liste all dessen, was sie enthält, selbst schreiben. Diese Datei gibt es seit 2004, sie passt in eine Tabelle, und fast niemand verlangt sie.

Eine Datei, welche die Anlage selbst schreiben kann

EDE, für Engineering Data Exchange, ist eine Tabelle, die sämtliche BACnet-Objekte einer Anlage auflistet: eine Zeile pro Datenpunkt, insgesamt vier Blätter. Daran ist nichts geheimnisvoll, und genau das macht sie brauchbar.

Die BACnet-Empfehlung der KBOB — der Koordinationskonferenz der Bau- und Liegenschaftsorgane der öffentlichen Bauherren, zu der das BBL, armasuisse und der ETH-Bereich gehören — ordnet sie in einem Satz ein, in ihrer Ausgabe vom Juli 2021: Die EDE-Liste «ist nicht auf Normstufe definiert, sondern entspricht einer 2004 von BIG-EU veröffentlichten Empfehlung». Und sie ergänzt das Wesentliche: Diese Listen «können durch automatisches Auslesen der BACnet-Funktionalität eines projektierten BACnet-Geräts erstellt werden».

Automatisches Auslesen. Darum geht es.

Die einer Ausschreibung beigelegte Datenpunktliste ist eine Absichtserklärung: das, was geliefert werden soll. Die aus der Anlage erzeugte EDE-Datei ist eine Aufnahme: das, was tatsächlich vorhanden ist, unter den Namen, die tatsächlich in den Automationsstationen stehen. Zwei Dokumente von gleichem Aussehen und gegensätzlicher Natur. Beide gegeneinanderzuhalten dauert einen halben Tag und verlangt keine Begehung.

Siebzehn Spalten, davon fünf obligatorisch

Die offizielle Vorlage wird von der BACnet Interest Group Europe herausgegeben. Ihre Layout-Version — das Feld heisst Version_Of_Layout im Dateikopf — ist 2.3, datiert vom 16. Januar 2017. Die KBOB empfiehlt, nicht darunter zu gehen: «Es wird empfohlen, mindestens die Version 2.3 der EDE-Dateien von BIG-EU zu verwenden.»

Diese Vorlage sieht siebzehn Spalten vor. Nur fünf sind obligatorisch.

Die Folge ist unmittelbar, und sie ist es, die man sich merken muss: Eine einwandfrei konforme EDE-Datei kann nichts als Nummern enthalten. Fünf Spalten gefüllt, zwölf leer, und das Dokument ist gültig. Es sagt dann weder, was der Punkt misst, noch in welcher Einheit, noch zwischen welchen Grenzen, noch ob er alarmiert ist.

«Einen EDE-Export» zu verlangen, nützt also nichts. Was nützt, ist die optionalen Spalten zu verlangen. Das ist eine Zeile im Pflichtenheft, keine Verhandlung.

Was EDE nicht leistet

Besser gleich gesagt, denn das Format wird zuweilen als universelles Austauschformat dargestellt, das es nicht ist.

Es ist nicht normativ. Es ist die Empfehlung einer Interessengruppe, kein Kapitel der BACnet-Norm. Die letzte Version stammt von 2017 und hat sich seither nicht bewegt.

Es ist von Haus aus unvollständig. Die KBOB ist deutlich: EDE-Listen «enthalten vereinfachte und unvollständige Angaben» und «sind nützlich, wenn keine vollständigeren Angaben verfügbar sind». Es ist eine Aufnahme, keine Dokumentation.

Es beschreibt keine Logik. Nicht die Programme, nicht die Verriegelungen, nicht die Zeitprogramme, nicht die Kurven. Es sagt, was vorhanden ist und wie es heisst — nie, was es tut. Ein vollständig in EDE beschriebenes Gebäude bleibt ein Gebäude, dessen Regelung man nicht kennt.

Es enthält keine Werte. Es ist kein Archiv und ersetzt den Export der Messwerte nicht.

Schliesslich trägt die Vorlage selbst den Warnhinweis ihrer Urheber: Die EDE-Datei «war nie dafür gedacht, ein Austauschformat von Maschine zu Maschine bereitzustellen» — und wird überall genau dafür verwendet. Anders gesagt: Sie funktioniert, aber sie hat nichts versprochen.

Drei Momente, in denen sie etwas ändert

In der Ausschreibung macht sie aus einem Anhang eine Vorlage. Statt die Datenpunktliste in Prosa zu beschreiben, gibt die Bauherrschaft sie im EDE-Format ab, mit den Spalten, deren Ausfüllung sie verlangt. Die Angebote kommen vergleichbar zurück, Zeile für Zeile, ohne Auslegung.

Bei der Integration erspart sie die Neuerfassung. Übliche Leitstationen importieren eine EDE-Datei, um ihre Punkte anzulegen. Bei einer Anlage mit einigen tausend Objekten steht der Unterschied zwischen Import und Handeingabe nicht zur Debatte — und was importiert wird, enthält keine Tippfehler.

Bei der Abnahme wird sie zum einzigen gegenprüfbaren Dokument. Man liest die aus der Anlage exportierte EDE-Datei zurück und vergleicht sie mit jener der Ausschreibung: Fehlende Punkte treten zutage, hinzugekommene ebenso, nicht konforme Namen auch. Diese Prüfung ist mechanisch. Kein anderes Dokument des MSR-Dossiers erlaubt das.

Dort liegt der wirkliche Zeitgewinn. Nicht in der Datei selbst, sondern in den Rückfragen, die sie zwischen Inbetriebnahme und erstem Betriebsjahr erspart.

Die Lücke, die EDE nicht schliesst: die Namen

Ein unangenehmes Detail, das man besser vor der Unterschrift kennt als danach.

Die Empfehlung der KBOB schliesst «die Bezeichnung der Datenpunkte und das Nummerierungskonzept» ausdrücklich aus ihrem Geltungsbereich aus. Und ihr Kapitel zu den Objektnamen sagt es unverblümt: «Für die Vergabe der Objektnamen wird keine Regel vorgeschrieben.»

Übersetzt: Die massgebende Schweizer Empfehlung ordnet das Protokoll, die Geräteprofile und die Zeichenkettenlängen — Object_Name mindestens 64 Zeichen, Description 128 für eine Management- und Bedieneinrichtung, Zeichensatz UTF-8 vorgeschrieben — überlässt die Wahl der Namen aber bewusst dem Projekt.

Schreibt die Bauherrschaft ihre Nomenklatur nicht vor, wendet jeder Integrator seine eigene an. Das Gebäude spricht dann zwei oder drei Sprachen, mit einer tadellosen EDE-Datei, die alle drei dokumentiert.

Die sieben Prüfungen an einer erhaltenen EDE-Datei

1. Alle vier Blätter sind vorhanden: EDE, State-Texts, Unit-Texts, Object-Types. Ein einzelnes geliefertes Blatt ist eine verstümmelte Datei.
2. Der Kopf ist ausgefüllt: Projektname, Version der Referenzdatei, Datum und Verfasser der letzten Änderung, und Version_Of_Layout mindestens 2.3.
3. Die vertraglich verlangten optionalen Spalten sind tatsächlich ausgefüllt — nicht bloss vorhanden. Eine leere Spalte über 4000 Zeilen erkennt man in einer Tabelle in einer Sekunde.
4. Jede referenzierte Einheit und jeder Zustandstext existiert: Jeder im EDE-Blatt verwendete unit-code steht in Unit-Texts, jede state-text-reference in State-Texts. Sonst erzeugt der Import in die Leitstation Punkte ohne Einheit und ohne Text.
5. Die Objektnamen halten die Nomenklatur der Bauherrschaft ein, durchgehend, ohne geduldete Ausnahme «für die paar Punkte des Unternehmers».
6. Die Beschreibungen sind ausgeschrieben und bleiben nicht im Kürzel stecken. Diesen Text liest der Betreiber zwanzig Jahre lang.
7. Die Zeilenzahl entspricht der vertraglichen Datenpunktliste. Die Abweichung, in die eine wie in die andere Richtung, wird schriftlich begründet.

Was wir vor der Prüfung tun

Ein Prüfwerkzeug nützt nichts ohne Regel, die es durchzusetzen gilt. Dort beginnen wir deshalb: Wir schreiben für unsere Kunden ihre Richtlinie zur Bezeichnung der Datenpunkte, auf der Grundlage der BACnet-Empfehlung der KBOB — genau dort, wo diese aufhört.

Das ist keine von Projekt zu Projekt abgeschriebene Vorlage. Eine Bauherrschaft mit vierzig Gebäuden hat achtunddreissig davon bereits benannt, oft auf drei verschiedene Arten, und ihr Betreiber arbeitet seit fünfzehn Jahren mit seinen eigenen Bezeichnungen. Eine Nomenklatur, die rückwirkend alles umzubenennen verlangte, wird nie angewendet: Sie endet als Anhang, den niemand öffnet. Die Richtlinie entsteht deshalb aus dem bestehenden Portfolio — was schon da ist, was übernommen wird, was zurückbleibt und was nur für neue Anlagen gilt.

Einmal geschrieben, sorgen wir dafür, dass sie hält, und dort entscheidet sich das Wesentliche:

• Wir entwickeln die Werkzeuge, die sie prüfen — die EDE-Prüfung unten ist eines davon;
• wir beraten die Bauherrschaft darüber, worauf ihre Entscheide sie festlegen, bevor diese in einer Ausschreibung stehen;
• wir begleiten den Integrator während des Projekts, damit das Gelieferte dem Geschriebenen entspricht — das Ziel ist nicht, einen Integrator bei der Abnahme zu ertappen, sondern dass er keinen Anlass dazu gibt.